From nobody Wed Oct 1 18:51:13 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F5C31A8891 for ; Wed, 1 Oct 2014 18:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.987 X-Spam-Level: X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0PgkqFKx1gi for ; Wed, 1 Oct 2014 18:51:09 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F2B21A888A for ; Wed, 1 Oct 2014 18:51:09 -0700 (PDT) X-AuditID: 12074425-f79e46d000002583-89-542caf8cb07e Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 25.2B.09603.C8FAC245; Wed, 1 Oct 2014 21:51:08 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id s921p7fb006232 for ; Wed, 1 Oct 2014 21:51:08 -0400 Received: from localhost (sarnath.mit.edu [18.18.1.190]) (authenticated bits=0) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s921p6Lu027045 for ; Wed, 1 Oct 2014 21:51:07 -0400 From: Tom Yu To: oauth@ietf.org References: <20140930222521.16786.76707.idtracker@ietfa.amsl.com> Date: Wed, 01 Oct 2014 21:51:06 -0400 In-Reply-To: <20140930222521.16786.76707.idtracker@ietfa.amsl.com> (internet-drafts@ietf.org's message of "Tue, 30 Sep 2014 15:25:21 -0700") Message-ID: Lines: 39 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDIsWRmVeSWpSXmKPExsUixCmqrduzXifEYPFpQYuTb1+xOTB6LFny kymAMYrLJiU1J7MstUjfLoEr486JtWwFjbwVT7ddZW1g7OLqYuTkkBAwkfg44SkjhC0mceHe erYuRi4OIYHZTBKd07YyQjhHGSW6jy2GchqYJC69PcUM0sImIC1x/PIuJhBbREBI4vnOPjBb WCBQ4sn7o+wgtpCAo8TfG7/B4iwCqhLbf60FW8EpMIFRYuO9y2C7eQV0JfaeWs0KYvMIcEp0 Tuxih4gLSpyc+YQFxGYW0JK48e8l0wRG/llIUrOQpBYwMq1ilE3JrdLNTczMKU5N1i1OTszL Sy3StdDLzSzRS00p3cQICjR2F9UdjBMOKR1iFOBgVOLhzWjQCRFiTSwrrsw9xCjJwaQkynt3 FVCILyk/pTIjsTgjvqg0J7X4EKMEB7OSCO+qyUA53pTEyqrUonyYlDQHi5I476YffCFCAumJ JanZqakFqUUwWRkODiUJ3lPrgBoFi1LTUyvSMnNKENJMHJwgw3mAhh8CqeEtLkjMLc5Mh8if YlSUEuddCpIQAElklObB9cISwStGcaBXhHmPgVTxAJMIXPcroMFMQIOT12iDDC5JREhJNTBe 1jeIm5vfvlX+fm7TIgPjCGOxKlfh6Yfn15Q8/76vbvXHtwFPpU/s7eG833Yp4N7WLLEQ86s+ IqcmzvFMLb61slvvn43q250/V91t9V5yUtyq5uD82FxGoczG68Y3j+wvUbW482TBnE1v5QWm 271dsfbc61I/XeY69X+H7A/8/X/Z97n+y/oNSizFGYmGWsxFxYkAxF5Rdt8CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/St4GBUEo8tSNa-0MmxaNuGLl0ME Subject: Re: [OAUTH-WG] New Version Notification for draft-yu-oauth-token-translation-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 01:51:11 -0000 I uploaded this draft about a service for translating Kerberos tickets to JWTs. This allows sites to leverage existing Kerberos infrastructures to support authentication to OAuth services. Among other things, it specifies a generally useful mapping between Kerberos tickets and JWT, which could be used bidirectionally. The draft currently focuses on proof of possession tokens, but could be readily modified to support bearer tokens as well. Is there interest in making progress on this draft or in related work? writes: > A new version of I-D, draft-yu-oauth-token-translation-00.txt > has been successfully submitted by Tom Yu and posted to the > IETF repository. > > Name: draft-yu-oauth-token-translation > Revision: 00 > Title: A Kerberos Token Translation Service for OAuth > Document date: 2014-09-30 > Group: Individual Submission > Pages: 5 > URL: http://www.ietf.org/internet-drafts/draft-yu-oauth-token-translation-00.txt > Status: https://datatracker.ietf.org/doc/draft-yu-oauth-token-translation/ > Htmlized: http://tools.ietf.org/html/draft-yu-oauth-token-translation-00 > > > Abstract: > This document describes a Token Translation Service that allows a > site to use an existing Kerberos infrastructure to provide > authentication in an OAuth 2.0 web service environment. > > > > > 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 Wed Oct 1 19:57:12 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFDEB1A0037; Wed, 1 Oct 2014 19:57:07 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MlPaxgLfNplI; Wed, 1 Oct 2014 19:57:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A7C331A0033; Wed, 1 Oct 2014 19:57:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Richard Barnes" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141002025706.19368.2507.idtracker@ietfa.amsl.com> Date: Wed, 01 Oct 2014 19:57:06 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/TYANOKHXUG69qB7xRWwc4dllPLk Cc: oauth-chairs@tools.ietf.org, oauth@ietf.org, draft-ietf-oauth-json-web-token@tools.ietf.org Subject: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 02:57:08 -0000 Richard Barnes has entered the following ballot position for draft-ietf-oauth-json-web-token-27: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Section 7. In order to prevent confusion between secured and Unsecured JWTs, the validation steps here need to call for the application to specify which is required. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Abstract. Welsh is the only language I know of in which "w" is a vowel. According to Wikipedia, then, "JWT" should pronounced "joot" :) Section 2. It seems like "Unsecured JWT" should simply be defined as "A JWT carried in an Unsigned JWS." Section 4.1. I'm a little surprised not to see a "jwk" claim, which would basically enable JWTs to sub in for certificates for many use cases. Did the WG consider this possibility? From nobody Thu Oct 2 08:15:25 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABF741A19E9; Thu, 2 Oct 2014 08:15:22 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uukVflykFZUT; Thu, 2 Oct 2014 08:15:20 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0728.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:728]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B07131A19FE; Thu, 2 Oct 2014 08:15:19 -0700 (PDT) Received: from DM2PR0301MB1213.namprd03.prod.outlook.com (25.160.219.154) by DM2PR0301MB0605.namprd03.prod.outlook.com (25.160.95.21) with Microsoft SMTP Server (TLS) id 15.0.1044.10; Thu, 2 Oct 2014 15:14:51 +0000 Received: from DM2PR03CA0040.namprd03.prod.outlook.com (10.141.96.39) by DM2PR0301MB1213.namprd03.prod.outlook.com (25.160.219.154) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Thu, 2 Oct 2014 15:14:55 +0000 Received: from BN1AFFO11FD056.protection.gbl (2a01:111:f400:7c10::108) by DM2PR03CA0040.outlook.office365.com (2a01:111:e400:2428::39) with Microsoft SMTP Server (TLS) id 15.0.1039.15 via Frontend Transport; Thu, 2 Oct 2014 15:14:55 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD056.mail.protection.outlook.com (10.58.53.71) with Microsoft SMTP Server (TLS) id 15.0.1029.15 via Frontend Transport; Thu, 2 Oct 2014 15:14:54 +0000 Received: from TK5EX14MBXC288.redmond.corp.microsoft.com ([169.254.3.218]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.03.0195.002; Thu, 2 Oct 2014 15:14:48 +0000 From: Mike Jones To: Alissa Cooper , The IESG Thread-Topic: Alissa Cooper's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS) Thread-Index: AQHP3a1dXWSzXOmjaU+9pDgxxC1sm5wc6tPw Date: Thu, 2 Oct 2014 15:14:46 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439BAB371E@TK5EX14MBXC288.redmond.corp.microsoft.com> References: <20141001192433.1934.82385.idtracker@ietfa.amsl.com> In-Reply-To: <20141001192433.1934.82385.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439BAB371ETK5EX14MBXC288r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(438002)(377454003)(13464003)(189002)(52044002)(199003)(84326002)(46102003)(64706001)(15202345003)(87936001)(99396003)(80022003)(15975445006)(85852003)(54356999)(55846006)(20776003)(26826002)(76176999)(120916001)(16236675004)(92566001)(50986999)(2656002)(86362001)(86612001)(19625215002)(76482002)(85306004)(19580395003)(68736004)(4396001)(69596002)(6806004)(92726001)(66066001)(19580405001)(44976005)(31966008)(512874002)(71186001)(21056001)(107046002)(19617315012)(33656002)(84676001)(106116001)(19300405004)(10300001)(95666004)(97736003)(106466001)(81156004)(104016003)(230783001)(77096002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB1213; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:;UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB1213; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 03524FBD26 Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0605; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/1jwPvzylyvmz3FQ7bqUV6onmeMs Cc: "oauth-chairs@tools.ietf.org" , "draft-ietf-oauth-json-web-token@tools.ietf.org" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Alissa Cooper's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 15:15:22 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439BAB371ETK5EX14MBXC288r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmVzcG9uZGluZyB0byB0aGUgRElTQ1VTUyBiZWxvd+KApg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IEFsaXNzYSBDb29wZXIgW21haWx0bzphbGlzc2FAY29vcGVydy5p bl0NClNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAwMSwgMjAxNCAxMjoyNSBQTQ0KVG86IFRoZSBJ RVNHDQpDYzogb2F1dGgtY2hhaXJzQHRvb2xzLmlldGYub3JnOyBkcmFmdC1pZXRmLW9hdXRoLWpz b24td2ViLXRva2VuQHRvb2xzLmlldGYub3JnDQpTdWJqZWN0OiBBbGlzc2EgQ29vcGVyJ3MgRGlz Y3VzcyBvbiBkcmFmdC1pZXRmLW9hdXRoLWpzb24td2ViLXRva2VuLTI3OiAod2l0aCBESVNDVVNT KQ0KDQoNCg0KQWxpc3NhIENvb3BlciBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBw b3NpdGlvbiBmb3INCg0KZHJhZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi10b2tlbi0yNzogRGlzY3Vz cw0KDQoNCg0KV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGlu dGFjdCBhbmQgcmVwbHkgdG8gYWxsIGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8g YW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzIGludHJvZHVjdG9yeSBwYXJhZ3Jh cGgsIGhvd2V2ZXIuKQ0KDQoNCg0KDQoNClBsZWFzZSByZWZlciB0byBodHRwOi8vd3d3LmlldGYu b3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KDQpmb3IgbW9yZSBpbmZv cm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KDQoNCg0K DQoNClRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4g YmUgZm91bmQgaGVyZToNCg0KaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1p ZXRmLW9hdXRoLWpzb24td2ViLXRva2VuLw0KDQoNCg0KDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoN CkRJU0NVU1M6DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQoNCj09IFNlY3Rpb24gMTIgPT0NCg0KDQoN CiJBIEpXVCBtYXkgY29udGFpbiBwcml2YWN5LXNlbnNpdGl2ZSBpbmZvcm1hdGlvbi4gIFdoZW4g dGhpcyBpcyB0aGUNCg0KICAgY2FzZSwgbWVhc3VyZXMgbXVzdCBiZSB0YWtlbiB0byBwcmV2ZW50 IGRpc2Nsb3N1cmUgb2YgdGhpcw0KDQogICBpbmZvcm1hdGlvbiB0byB1bmludGVuZGVkIHBhcnRp ZXMuIg0KDQoNCg0KSXQgc2VlbXMgdG8gbWUgdGhhdCB0aGlzIHNob3VsZCBiZSBhIG5vcm1hdGl2 ZSBNVVNULCBwYXJ0aWN1bGFybHkgaW4gbGlnaHQgb2YgdGhlIGZhY3QgdGhhdCBjbGFpbXMgYXJl IGJlaW5nIGRlZmluZWQgdGhhdCBhcmUgbWVhbnQgdG8gZGlyZWN0bHkgaWRlbnRpZnkgdXNlcnMg KGUuZy4sIHN1YikgYW5kIG90aGVyIGNsYWltcyBkZWZpbmVkIGhlcmUgb3IgbGF0ZXIgY291bGQg ZG8gc28gYXMgd2VsbC4NCg0KDQoNClRoZXJlIHNlZW1zIHRvIGJlIGRlYmF0ZSB3aGV0aGVyIGEg MjExOSBsYW5ndWFnZSBzaG91bGQgYmUgdXNlZCBvdGhlciB0aGFuIHdoZW4gZGVzY3JpYmluZyBw cm90b2NvbCByZXF1aXJlbWVudHMuICBKaW0gU2NoYWFkICh0aGUgSk9TRSBjaGFpcikgYmVsaWV2 ZXMgdGhhdCB0aGV5IHNob3VsZG7igJl0IGFuZCB0aGVzZSBkb2N1bWVudHMgaGF2ZSBmb2xsb3dl ZCB0aGF0IGNvbnZlbnRpb24uDQoNCg0KDQoiT25lIHdheSB0byBhY2hpZXZlIHRoaXMgaXMgdG8g dXNlDQoNCiAgIGFuIGVuY3J5cHRlZCBKV1QuICBBbm90aGVyIHdheSBpcyB0byBlbnN1cmUgdGhh dCBKV1RzIGNvbnRhaW5pbmcNCg0KICAgdW5lbmNyeXB0ZWQgcHJpdmFjeS1zZW5zaXRpdmUgaW5m b3JtYXRpb24gYXJlIG9ubHkgdHJhbnNtaXR0ZWQgb3Zlcg0KDQogICBlbmNyeXB0ZWQgY2hhbm5l bHMgb3IgcHJvdG9jb2xzLCBzdWNoIGFzIFRMUy4iDQoNCg0KDQpTaW5jZSBzZW5zaXRpdmUgSldU cyBzaG91bGQgYmUgcHJvdGVjdGVkIGZyb20gYm90aCBpbnRlcm1lZGlhcnkgb2JzZXJ2YXRpb24g YW5kIGZyb20gYmVpbmcgc2VudCB0byB1bmludGVuZGVkIHJlY2lwaWVudHMsIEkgd291bGQNCg0K c3VnZ2VzdDoNCg0KDQoNCk9uZSB3YXkgdG8gYWNoaWV2ZSB0aGlzIGlzIHRvIHVzZSBhbiBlbmNy eXB0ZWQgSldUIGFuZCBhdXRoZW50aWNhdGUgdGhlIHJlY2lwaWVudC4gQW5vdGhlciB3YXkgaXMg dG8gZW5zdXJlIHRoYXQgSldUcyBjb250YWluaW5nIHVuZW5jcnlwdGVkIHByaXZhY3ktc2Vuc2l0 aXZlIGluZm9ybWF0aW9uIGFyZSBvbmx5IHRyYW5zbWl0dGVkIG92ZXIgZW5jcnlwdGVkIGNoYW5u ZWxzIG9yIHByb3RvY29scyB0aGF0IGFsc28gc3VwcG9ydCBlbmRwb2ludCBhdXRoZW50aWNhdGlv biwgc3VjaCBhcyBUTFMuDQoNCg0KDQpUaGFua3MgZm9yIHRoaXMgc3VnZ2VzdGVkIGxhbmd1YWdl LiAgV2UgY2FuIGluY29ycG9yYXRlIHNvbWV0aGluZyBsaWtlIHRoYXQuDQoNCg0K --_000_4E1F6AAD24975D4BA5B16804296739439BAB371ETK5EX14MBXC288r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQphOmxp bmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpi bHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5 cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxh aW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJQbGFp biBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi UGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWlu IDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1V UyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcwQzAiPlJl c3BvbmRpbmcgdG8gdGhlIERJU0NVU1MgYmVsb3figKY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+LS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9tOiBBbGlzc2EgQ29vcGVyIFttYWlsdG86YWxpc3Nh QGNvb3BlcncuaW5dIDxicj4NClNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAwMSwgMjAxNCAxMjoy NSBQTTxicj4NClRvOiBUaGUgSUVTRzxicj4NCkNjOiBvYXV0aC1jaGFpcnNAdG9vbHMuaWV0Zi5v cmc7IGRyYWZ0LWlldGYtb2F1dGgtanNvbi13ZWItdG9rZW5AdG9vbHMuaWV0Zi5vcmc8YnI+DQpT dWJqZWN0OiBBbGlzc2EgQ29vcGVyJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLW9hdXRoLWpzb24t d2ViLXRva2VuLTI3OiAod2l0aCBESVNDVVNTKTwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+QWxpc3NhIENv b3BlciBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3I8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPmRyYWZ0LWlldGYtb2F1dGgtanNvbi13 ZWItdG9rZW4tMjc6IERpc2N1c3M8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+V2hlbiBy ZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkg dG8gYWxsIGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAo RmVlbCBmcmVlIHRvIGN1dCB0aGlzIGludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKTxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPlBsZWFzZSByZWZlciB0byA8YSBocmVmPSJodHRwOi8vd3d3Lmll dGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbCI+DQo8c3BhbiBzdHls ZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cDovL3d3dy5pZXRm Lm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWw8L3NwYW4+PC9hPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Zm9yIG1vcmUgaW5mb3JtYXRpb24g YWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij5UaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2Fu IGJlIGZvdW5kIGhlcmU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 YSBocmVmPSJodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtb2F1dGgt anNvbi13ZWItdG9rZW4vIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29y YXRpb246bm9uZSI+aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9h dXRoLWpzb24td2ViLXRva2VuLzwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5ESVNDVVNTOjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij49PSBTZWN0aW9uIDEyID09PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZxdW90O0EgSldUIG1heSBjb250YWluIHByaXZhY3ktc2Vuc2l0aXZlIGluZm9ybWF0 aW9uLiZuYnNwOyBXaGVuIHRoaXMgaXMgdGhlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgY2FzZSwgbWVhc3VyZXMgbXVzdCBiZSB0YWtlbiB0byBw cmV2ZW50IGRpc2Nsb3N1cmUgb2YgdGhpczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jm5ic3A7Jm5ic3A7IGluZm9ybWF0aW9uIHRvIHVuaW50ZW5kZWQgcGFydGllcy4m cXVvdDsmbmJzcDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkl0IHNlZW1zIHRvIG1l IHRoYXQgdGhpcyBzaG91bGQgYmUgYSBub3JtYXRpdmUgTVVTVCwgcGFydGljdWxhcmx5IGluIGxp Z2h0IG9mIHRoZSBmYWN0IHRoYXQgY2xhaW1zIGFyZSBiZWluZyBkZWZpbmVkIHRoYXQgYXJlIG1l YW50IHRvIGRpcmVjdGx5IGlkZW50aWZ5IHVzZXJzIChlLmcuLCBzdWIpIGFuZCBvdGhlciBjbGFp bXMgZGVmaW5lZCBoZXJlIG9yIGxhdGVyIGNvdWxkIGRvIHNvIGFzIHdlbGwuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMwMDcwQzAiPlRoZXJlIHNlZW1zIHRvIGJlIGRlYmF0ZSB3aGV0aGVy IGEgMjExOSBsYW5ndWFnZSBzaG91bGQgYmUgdXNlZCBvdGhlciB0aGFuIHdoZW4gZGVzY3JpYmlu ZyBwcm90b2NvbCByZXF1aXJlbWVudHMuJm5ic3A7IEppbSBTY2hhYWQgKHRoZSBKT1NFIGNoYWly KSBiZWxpZXZlcyB0aGF0IHRoZXkgc2hvdWxkbuKAmXQgYW5kIHRoZXNlIGRvY3VtZW50cyBoYXZl IGZvbGxvd2VkDQogdGhhdCBjb252ZW50aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mcXVvdDtPbmUgd2F5 IHRvIGFjaGlldmUgdGhpcyBpcyB0byB1c2U8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZuYnNwOyZuYnNwOyBhbiBlbmNyeXB0ZWQgSldULiZuYnNwOyBBbm90aGVyIHdh eSBpcyB0byBlbnN1cmUgdGhhdCBKV1RzIGNvbnRhaW5pbmc8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyB1bmVuY3J5cHRlZCBwcml2YWN5LXNlbnNp dGl2ZSBpbmZvcm1hdGlvbiBhcmUgb25seSB0cmFuc21pdHRlZCBvdmVyPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgZW5jcnlwdGVkIGNoYW5uZWxz IG9yIHByb3RvY29scywgc3VjaCBhcyBUTFMuJnF1b3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPlNpbmNlIHNlbnNpdGl2ZSBKV1RzIHNob3VsZCBiZSBwcm90ZWN0ZWQgZnJvbSBib3Ro IGludGVybWVkaWFyeSBvYnNlcnZhdGlvbiBhbmQgZnJvbSBiZWluZyBzZW50IHRvIHVuaW50ZW5k ZWQgcmVjaXBpZW50cywgSSB3b3VsZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+c3VnZ2VzdDo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+T25lIHdheSB0byBh Y2hpZXZlIHRoaXMgaXMgdG8gdXNlIGFuIGVuY3J5cHRlZCBKV1QgYW5kIGF1dGhlbnRpY2F0ZSB0 aGUgcmVjaXBpZW50LiBBbm90aGVyIHdheSBpcyB0byBlbnN1cmUgdGhhdCBKV1RzIGNvbnRhaW5p bmcgdW5lbmNyeXB0ZWQgcHJpdmFjeS1zZW5zaXRpdmUgaW5mb3JtYXRpb24gYXJlIG9ubHkgdHJh bnNtaXR0ZWQgb3ZlciBlbmNyeXB0ZWQgY2hhbm5lbHMgb3IgcHJvdG9jb2xzIHRoYXQNCiBhbHNv IHN1cHBvcnQgZW5kcG9pbnQgYXV0aGVudGljYXRpb24sIHN1Y2ggYXMgVExTLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcwQzAi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj5UaGFua3MgZm9yIHRoaXMgc3VnZ2VzdGVkIGxhbmd1 YWdlLiZuYnNwOyBXZSBjYW4gaW5jb3Jwb3JhdGUgc29tZXRoaW5nIGxpa2UgdGhhdC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29s b3I6IzAwNzBDMCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_4E1F6AAD24975D4BA5B16804296739439BAB371ETK5EX14MBXC288r_-- From nobody Thu Oct 2 08:21:37 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6FB61A1B42; Thu, 2 Oct 2014 08:21: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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0vJCuIysQ_bH; Thu, 2 Oct 2014 08:21:31 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7A271A01F6; Thu, 2 Oct 2014 08:21:30 -0700 (PDT) Received: by mail-lb0-f179.google.com with SMTP id l4so2459881lbv.10 for ; Thu, 02 Oct 2014 08:21:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8dw5yBPm+/Qzz8w4x9kdMDYO0ld/OffhxJHl3evV2Ts=; b=MnYCz1U1MTOsoeiEA6dI+wOYXoDKsDz6VEaF8/a0dNs2TVPNPQBKimxchbx3r3585q pBT5st6iAZoEUHp6KEyDC/6BPezuDqHBulNSwEgvQM459iUmbENci41GlQw+/E5hFHNo xjzpiHhQMaFuFi6ERYK9Nn+mwypMWxAWFi0rIAHHjrHksjk0T0yJ6G7Ii42Hy/Fioj1h WkSvJ6VTj9J7F0CTADAojh52EXHmOiZr8VbxzD5HBNpyIT4czbuKUPTgea9KOZ9NfabX lNzPFinkEPlWBn17pOjdoo3AuFfu3FFKlk+DCR9/DJGfCAhOArg4878xrOukhVN0fOVF 1k7g== MIME-Version: 1.0 X-Received: by 10.112.156.227 with SMTP id wh3mr4124557lbb.23.1412263288974; Thu, 02 Oct 2014 08:21:28 -0700 (PDT) Received: by 10.112.95.36 with HTTP; Thu, 2 Oct 2014 08:21:28 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439BAB371E@TK5EX14MBXC288.redmond.corp.microsoft.com> References: <20141001192433.1934.82385.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739439BAB371E@TK5EX14MBXC288.redmond.corp.microsoft.com> Date: Thu, 2 Oct 2014 11:21:28 -0400 Message-ID: From: Kathleen Moriarty To: Mike Jones Content-Type: multipart/alternative; boundary=001a11c34408ab32c90504722ba8 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/zWAxwkRmQTcyeNsQI3VJXIlEjCE Cc: "oauth-chairs@tools.ietf.org" , "oauth@ietf.org" , Alissa Cooper , The IESG , "draft-ietf-oauth-json-web-token@tools.ietf.org" Subject: Re: [OAUTH-WG] Alissa Cooper's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 15:21:34 -0000 --001a11c34408ab32c90504722ba8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Oct 2, 2014 at 11:14 AM, Mike Jones wrote: > Responding to the DISCUSS below=E2=80=A6 > > > > -----Original Message----- > From: Alissa Cooper [mailto:alissa@cooperw.in] > Sent: Wednesday, October 01, 2014 12:25 PM > To: The IESG > Cc: oauth-chairs@tools.ietf.org; > draft-ietf-oauth-json-web-token@tools.ietf.org > Subject: Alissa Cooper's Discuss on draft-ietf-oauth-json-web-token-27: > (with DISCUSS) > > > > Alissa Cooper has entered the following ballot position for > > draft-ietf-oauth-json-web-token-27: Discuss > > > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > http://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > =3D=3D Section 12 =3D=3D > > > > "A JWT may contain privacy-sensitive information. When this is the > > case, measures must be taken to prevent disclosure of this > > information to unintended parties." > > > > It seems to me that this should be a normative MUST, particularly in ligh= t > of the fact that claims are being defined that are meant to directly > identify users (e.g., sub) and other claims defined here or later could d= o > so as well. > > > > There seems to be debate whether a 2119 language should be used other tha= n > when describing protocol requirements. Jim Schaad (the JOSE chair) > believes that they shouldn=E2=80=99t and these documents have followed th= at > convention. > > With other documents, there is RFC2119 language used for security & privacy considerations. At some point there was a trend to have a separate "Security Requirements" section from "Security Considerations", but I don't think there was any requirement for this, just a preference. I agree that this should be a MUST, but with Stephen as well that you should discourage putting in privacy related information to begin with. > > > "One way to achieve this is to use > > an encrypted JWT. Another way is to ensure that JWTs containing > > unencrypted privacy-sensitive information are only transmitted over > > encrypted channels or protocols, such as TLS." > > > > Since sensitive JWTs should be protected from both intermediary > observation and from being sent to unintended recipients, I would > > suggest: > > > > One way to achieve this is to use an encrypted JWT and authenticate the > recipient. Another way is to ensure that JWTs containing unencrypted > privacy-sensitive information are only transmitted over encrypted channel= s > or protocols that also support endpoint authentication, such as TLS. > > > > Thanks for this suggested language. We can incorporate something like > that. > OK, this makes sense and will feed into Pete's discuss on where TLS should be required. Thanks! > > --=20 Best regards, Kathleen --001a11c34408ab32c90504722ba8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Oct 2, 2014 at 11:14 AM, Mike Jones <Michael.Jones@m= icrosoft.com> wrote:

Responding to the DISCUSS below=E2=80=A6

=C2=A0

-----Original Message-----
From: Alissa Cooper [mailto:alissa@cooperw.in]
Sent: Wednesday, October 01, 2014 12:25 PM
To: The IESG
Cc: oauth-= chairs@tools.ietf.org; draft-ietf-oauth-json-web-token@tools.i= etf.org
Subject: Alissa Cooper's Discuss on draft-ietf-oauth-json-web-token-27:= (with DISCUSS)

=C2=A0

Alissa Cooper has entered the following ballot position for

draft-ietf-oauth-json-web-token-27: Discuss

=C2=A0

When responding, please keep the subject line intact and reply to all em= ail addresses included in the To and CC lines. (Feel free to cut this intro= ductory paragraph, however.)

=C2=A0

=C2=A0

Please refer to http://www.ietf.org/i= esg/statement/discuss-criteria.html

for more information about IESG DISCUSS and COMMENT positions.=

=C2=A0

=C2=A0

The document, along with other ballot positions, can be found here:

http://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/

=C2=A0

=C2=A0

=C2=A0

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

DISCUSS:

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

=C2=A0

=3D=3D Section 12 =3D=3D

=C2=A0

"A JWT may contain privacy-sensitive information.=C2=A0 When this i= s the

=C2=A0=C2=A0 case, measures must be taken to prevent disclosure of this<= u>

=C2=A0=C2=A0 information to unintended parties."=C2=A0

=C2=A0

It seems to me that this should be a normative MUST, particularly in lig= ht of the fact that claims are being defined that are meant to directly ide= ntify users (e.g., sub) and other claims defined here or later could do so = as well.

=C2=A0

There seems to be debate whether a = 2119 language should be used other than when describing protocol requiremen= ts.=C2=A0 Jim Schaad (the JOSE chair) believes that they shouldn=E2=80=99t = and these documents have followed that convention.

=C2=A0

"One way to achieve this is to use

=C2=A0=C2=A0 an encrypted JWT.=C2=A0 Another way is to ensure that JWTs = containing

=C2=A0=C2=A0 unencrypted privacy-sensitive information are only transmit= ted over

=C2=A0=C2=A0 encrypted channels or protocols, such as TLS."<= u>

=C2=A0

Since sensitive JWTs should be protected from both intermediary observat= ion and from being sent to unintended recipients, I would

suggest:

=C2=A0

One way to achieve this is to use an encrypted JWT and authenticate the = recipient. Another way is to ensure that JWTs containing unencrypted privac= y-sensitive information are only transmitted over encrypted channels or pro= tocols that also support endpoint authentication, such as TLS.

=C2=A0

Thanks for this suggested language.= =C2=A0 We can incorporate something like that.


=C2=A0




--

Best regards,
Kathleen
--001a11c34408ab32c90504722ba8-- From nobody Thu Oct 2 08:48:58 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 476451A873C; Thu, 2 Oct 2014 08:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3JvWrWQg7aF; Thu, 2 Oct 2014 08:48:54 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id B9C9B1A03A0; Thu, 2 Oct 2014 08:48:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id AADFEBE83; Thu, 2 Oct 2014 16:48:52 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ppcb8oDAEOfK; Thu, 2 Oct 2014 16:48:51 +0100 (IST) Received: from [10.87.48.10] (unknown [86.42.29.169]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id F3A78BE80; Thu, 2 Oct 2014 16:48:50 +0100 (IST) Message-ID: <542D73E2.6080406@cs.tcd.ie> Date: Thu, 02 Oct 2014 16:48:50 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Mike Jones , Alissa Cooper , The IESG References: <20141001192433.1934.82385.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739439BAB371E@TK5EX14MBXC288.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439BAB371E@TK5EX14MBXC288.redmond.corp.microsoft.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/r-gvMIx7u2rztUB7Gs2--T94CB4 Cc: "oauth-chairs@tools.ietf.org" , "draft-ietf-oauth-json-web-token@tools.ietf.org" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Alissa Cooper's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 15:48:56 -0000 Mike, I cannot tell which is your text and which not. Can you please use a better quoting style? These docs are going to be a total PITA to handle otherwise. Thanks, S. On 02/10/14 16:14, Mike Jones wrote: > Responding to the DISCUSS below… > > > > -----Original Message----- > From: Alissa Cooper [mailto:alissa@cooperw.in] > Sent: Wednesday, October 01, 2014 12:25 PM > To: The IESG > Cc: oauth-chairs@tools.ietf.org; draft-ietf-oauth-json-web-token@tools.ietf.org > Subject: Alissa Cooper's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS) > > > > Alissa Cooper has entered the following ballot position for > > draft-ietf-oauth-json-web-token-27: Discuss > > > > When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) > > > > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > http://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > == Section 12 == > > > > "A JWT may contain privacy-sensitive information. When this is the > > case, measures must be taken to prevent disclosure of this > > information to unintended parties." > > > > It seems to me that this should be a normative MUST, particularly in light of the fact that claims are being defined that are meant to directly identify users (e.g., sub) and other claims defined here or later could do so as well. > > > > There seems to be debate whether a 2119 language should be used other than when describing protocol requirements. Jim Schaad (the JOSE chair) believes that they shouldn’t and these documents have followed that convention. > > > > "One way to achieve this is to use > > an encrypted JWT. Another way is to ensure that JWTs containing > > unencrypted privacy-sensitive information are only transmitted over > > encrypted channels or protocols, such as TLS." > > > > Since sensitive JWTs should be protected from both intermediary observation and from being sent to unintended recipients, I would > > suggest: > > > > One way to achieve this is to use an encrypted JWT and authenticate the recipient. Another way is to ensure that JWTs containing unencrypted privacy-sensitive information are only transmitted over encrypted channels or protocols that also support endpoint authentication, such as TLS. > > > > Thanks for this suggested language. We can incorporate something like that. > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From nobody Thu Oct 2 09:26:52 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F24F1A87E1; Thu, 2 Oct 2014 09:26:34 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1_7q09Q0e7MW; Thu, 2 Oct 2014 09:26:31 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0124.outbound.protection.outlook.com [65.55.169.124]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37D431A8834; Thu, 2 Oct 2014 09:26:31 -0700 (PDT) Received: from BY2PR03CA062.namprd03.prod.outlook.com (10.141.249.35) by BY1PR0301MB1206.namprd03.prod.outlook.com (25.161.203.155) with Microsoft SMTP Server (TLS) id 15.0.1044.10; Thu, 2 Oct 2014 16:26:29 +0000 Received: from BN1AFFO11FD048.protection.gbl (2a01:111:f400:7c10::172) by BY2PR03CA062.outlook.office365.com (2a01:111:e400:2c5d::35) with Microsoft SMTP Server (TLS) id 15.0.1044.10 via Frontend Transport; Thu, 2 Oct 2014 16:26:29 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD048.mail.protection.outlook.com (10.58.53.63) with Microsoft SMTP Server (TLS) id 15.0.1029.15 via Frontend Transport; Thu, 2 Oct 2014 16:26:28 +0000 Received: from TK5EX14MBXC288.redmond.corp.microsoft.com ([169.254.3.218]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.03.0195.002; Thu, 2 Oct 2014 16:25:48 +0000 From: Mike Jones To: Stephen Farrell , Alissa Cooper , The IESG Thread-Topic: [OAUTH-WG] Alissa Cooper's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS) Thread-Index: AQHP3a1dXWSzXOmjaU+9pDgxxC1sm5wc6tPwgAAKigCAAAo8gA== Date: Thu, 2 Oct 2014 16:25:46 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439BAB3E04@TK5EX14MBXC288.redmond.corp.microsoft.com> References: <20141001192433.1934.82385.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739439BAB371E@TK5EX14MBXC288.redmond.corp.microsoft.com> <542D73E2.6080406@cs.tcd.ie> In-Reply-To: <542D73E2.6080406@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(24454002)(479174003)(199003)(189002)(377454003)(164054003)(52044002)(13464003)(51704005)(106466001)(120916001)(106116001)(76482002)(81156004)(84676001)(31966008)(10300001)(77096002)(2656002)(46102003)(20776003)(85852003)(54356999)(99396003)(47776003)(87936001)(66066001)(107046002)(15202345003)(76176999)(50986999)(85306004)(64706001)(230783001)(86612001)(104016003)(23676002)(86362001)(68736004)(80022003)(55846006)(4396001)(95666004)(69596002)(50466002)(92566001)(21056001)(15975445006)(19580395003)(26826002)(6806004)(97736003)(19580405001)(44976005)(33656002)(92726001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0301MB1206; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BY1PR0301MB1206; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 03524FBD26 Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/42qnxy6CnCYyXLydR_KtlhJYEHY Cc: "oauth-chairs@tools.ietf.org" , "draft-ietf-oauth-json-web-token@tools.ietf.org" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Alissa Cooper's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 16:26:35 -0000 T0sgLSBJJ2xsIHN0YXJ0IHByZWZpeGluZyBteSB0ZXh0IHdpdGggIk1pa2U+ICIuDQoNCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBTdGVwaGVuIEZhcnJlbGwgW21haWx0bzpzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllXSANClNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDAyLCAyMDE0 IDg6NDkgQU0NClRvOiBNaWtlIEpvbmVzOyBBbGlzc2EgQ29vcGVyOyBUaGUgSUVTRw0KQ2M6IG9h dXRoLWNoYWlyc0B0b29scy5pZXRmLm9yZzsgZHJhZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi10b2tl bkB0b29scy5pZXRmLm9yZzsgb2F1dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0dd IEFsaXNzYSBDb29wZXIncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtb2F1dGgtanNvbi13ZWItdG9r ZW4tMjc6ICh3aXRoIERJU0NVU1MpDQoNCg0KTWlrZSwNCg0KSSBjYW5ub3QgdGVsbCB3aGljaCBp cyB5b3VyIHRleHQgYW5kIHdoaWNoIG5vdC4NCg0KQ2FuIHlvdSBwbGVhc2UgdXNlIGEgYmV0dGVy IHF1b3Rpbmcgc3R5bGU/IFRoZXNlIGRvY3MgYXJlIGdvaW5nIHRvIGJlIGEgdG90YWwgUElUQSB0 byBoYW5kbGUgb3RoZXJ3aXNlLg0KDQpUaGFua3MsDQpTLg0KDQoNCk9uIDAyLzEwLzE0IDE2OjE0 LCBNaWtlIEpvbmVzIHdyb3RlOg0KPiBSZXNwb25kaW5nIHRvIHRoZSBESVNDVVNTIGJlbG934oCm DQo+IA0KPiANCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEFsaXNz YSBDb29wZXIgW21haWx0bzphbGlzc2FAY29vcGVydy5pbl0NCj4gU2VudDogV2VkbmVzZGF5LCBP Y3RvYmVyIDAxLCAyMDE0IDEyOjI1IFBNDQo+IFRvOiBUaGUgSUVTRw0KPiBDYzogb2F1dGgtY2hh aXJzQHRvb2xzLmlldGYub3JnOyANCj4gZHJhZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi10b2tlbkB0 b29scy5pZXRmLm9yZw0KPiBTdWJqZWN0OiBBbGlzc2EgQ29vcGVyJ3MgRGlzY3VzcyBvbiANCj4g ZHJhZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi10b2tlbi0yNzogKHdpdGggRElTQ1VTUykNCj4gDQo+ IA0KPiANCj4gQWxpc3NhIENvb3BlciBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBw b3NpdGlvbiBmb3INCj4gDQo+IGRyYWZ0LWlldGYtb2F1dGgtanNvbi13ZWItdG9rZW4tMjc6IERp c2N1c3MNCj4gDQo+IA0KPiANCj4gV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3Vi amVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsIA0KPiBlbWFpbCBhZGRyZXNzZXMgaW5j bHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgDQo+IHRoaXMg aW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+IA0KPiANCj4gDQo+IA0KPiANCj4g UGxlYXNlIHJlZmVyIHRvIA0KPiBodHRwOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rp c2N1c3MtY3JpdGVyaWEuaHRtbA0KPiANCj4gZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVT RyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCj4gDQo+IA0KPiANCj4gDQo+IA0KPiBU aGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZv dW5kIGhlcmU6DQo+IA0KPiBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtb2F1dGgtanNvbi13ZWItdG9rZW4vDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQo+IA0KPiBESVNDVVNTOg0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4g DQo+IA0KPiA9PSBTZWN0aW9uIDEyID09DQo+IA0KPiANCj4gDQo+ICJBIEpXVCBtYXkgY29udGFp biBwcml2YWN5LXNlbnNpdGl2ZSBpbmZvcm1hdGlvbi4gIFdoZW4gdGhpcyBpcyB0aGUNCj4gDQo+ ICAgIGNhc2UsIG1lYXN1cmVzIG11c3QgYmUgdGFrZW4gdG8gcHJldmVudCBkaXNjbG9zdXJlIG9m IHRoaXMNCj4gDQo+ICAgIGluZm9ybWF0aW9uIHRvIHVuaW50ZW5kZWQgcGFydGllcy4iDQo+IA0K PiANCj4gDQo+IEl0IHNlZW1zIHRvIG1lIHRoYXQgdGhpcyBzaG91bGQgYmUgYSBub3JtYXRpdmUg TVVTVCwgcGFydGljdWxhcmx5IGluIGxpZ2h0IG9mIHRoZSBmYWN0IHRoYXQgY2xhaW1zIGFyZSBi ZWluZyBkZWZpbmVkIHRoYXQgYXJlIG1lYW50IHRvIGRpcmVjdGx5IGlkZW50aWZ5IHVzZXJzIChl LmcuLCBzdWIpIGFuZCBvdGhlciBjbGFpbXMgZGVmaW5lZCBoZXJlIG9yIGxhdGVyIGNvdWxkIGRv IHNvIGFzIHdlbGwuDQo+IA0KPiANCj4gDQo+IFRoZXJlIHNlZW1zIHRvIGJlIGRlYmF0ZSB3aGV0 aGVyIGEgMjExOSBsYW5ndWFnZSBzaG91bGQgYmUgdXNlZCBvdGhlciB0aGFuIHdoZW4gZGVzY3Jp YmluZyBwcm90b2NvbCByZXF1aXJlbWVudHMuICBKaW0gU2NoYWFkICh0aGUgSk9TRSBjaGFpcikg YmVsaWV2ZXMgdGhhdCB0aGV5IHNob3VsZG7igJl0IGFuZCB0aGVzZSBkb2N1bWVudHMgaGF2ZSBm b2xsb3dlZCB0aGF0IGNvbnZlbnRpb24uDQo+IA0KPiANCj4gDQo+ICJPbmUgd2F5IHRvIGFjaGll dmUgdGhpcyBpcyB0byB1c2UNCj4gDQo+ICAgIGFuIGVuY3J5cHRlZCBKV1QuICBBbm90aGVyIHdh eSBpcyB0byBlbnN1cmUgdGhhdCBKV1RzIGNvbnRhaW5pbmcNCj4gDQo+ICAgIHVuZW5jcnlwdGVk IHByaXZhY3ktc2Vuc2l0aXZlIGluZm9ybWF0aW9uIGFyZSBvbmx5IHRyYW5zbWl0dGVkIG92ZXIN Cj4gDQo+ICAgIGVuY3J5cHRlZCBjaGFubmVscyBvciBwcm90b2NvbHMsIHN1Y2ggYXMgVExTLiIN Cj4gDQo+IA0KPiANCj4gU2luY2Ugc2Vuc2l0aXZlIEpXVHMgc2hvdWxkIGJlIHByb3RlY3RlZCBm cm9tIGJvdGggaW50ZXJtZWRpYXJ5IA0KPiBvYnNlcnZhdGlvbiBhbmQgZnJvbSBiZWluZyBzZW50 IHRvIHVuaW50ZW5kZWQgcmVjaXBpZW50cywgSSB3b3VsZA0KPiANCj4gc3VnZ2VzdDoNCj4gDQo+ IA0KPiANCj4gT25lIHdheSB0byBhY2hpZXZlIHRoaXMgaXMgdG8gdXNlIGFuIGVuY3J5cHRlZCBK V1QgYW5kIGF1dGhlbnRpY2F0ZSB0aGUgcmVjaXBpZW50LiBBbm90aGVyIHdheSBpcyB0byBlbnN1 cmUgdGhhdCBKV1RzIGNvbnRhaW5pbmcgdW5lbmNyeXB0ZWQgcHJpdmFjeS1zZW5zaXRpdmUgaW5m b3JtYXRpb24gYXJlIG9ubHkgdHJhbnNtaXR0ZWQgb3ZlciBlbmNyeXB0ZWQgY2hhbm5lbHMgb3Ig cHJvdG9jb2xzIHRoYXQgYWxzbyBzdXBwb3J0IGVuZHBvaW50IGF1dGhlbnRpY2F0aW9uLCBzdWNo IGFzIFRMUy4NCj4gDQo+IA0KPiANCj4gVGhhbmtzIGZvciB0aGlzIHN1Z2dlc3RlZCBsYW5ndWFn ZS4gIFdlIGNhbiBpbmNvcnBvcmF0ZSBzb21ldGhpbmcgbGlrZSB0aGF0Lg0KPiANCj4gDQo+IA0K PiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g T0F1dGggbWFpbGluZyBsaXN0DQo+IE9BdXRoQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCj4gDQo= From nobody Thu Oct 2 09:38:49 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2D5C1A88BF for ; Thu, 2 Oct 2014 09:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21plYbDWIAmC for ; Thu, 2 Oct 2014 09:38:47 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D82F11A88C9 for ; Thu, 2 Oct 2014 09:38:46 -0700 (PDT) Received: from [192.168.10.172] ([8.25.222.10]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MQR3s-1Xf7DE2fSG-00ThxS for ; Thu, 02 Oct 2014 18:38:45 +0200 Message-ID: <542D7F91.90408@gmx.net> Date: Thu, 02 Oct 2014 18:38:41 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: "oauth@ietf.org" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="HOhFGm9pfT36jFBnwUxkMT8WN5LBr4BLv" X-Provags-ID: V03:K0:oSt/59kccKWgfVeXKPtfcrNqZQnqCO6LPjoIxnJvYH5cB4uXHkh uNSGGIfgdH7r7joVjBBzSTvmrS3SIZBjKRpxiprPYqIdS9PPbGluyXScJczP7luwP0Cm5Z8 C0MB01k1u8Nu5TCWQ4BxsgJcTftOCuTWBmamZCLygwNKmd3oKExRQSagYkuT4l/SZ9KF2s+ rUp3FLizbaOlpCPVY74fA== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/GN_mvEv1n__15tFAdcmgzLqjX78 Subject: [OAUTH-WG] OAuth & Authentication: Conference Calls Scheduled X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 16:38:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HOhFGm9pfT36jFBnwUxkMT8WN5LBr4BLv Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, based on the availability of those who expressed interest in the "OAuth & authentication" conference call we have selected two dates, namely * Monday, October 13, 2014: 8:00 am | Pacific Daylight Time (San Francisco, GMT-07:00) * Thursday, October 16, 2014: 8:00 am | Pacific Daylight Time (San Francisco, GMT-07:00) We picked the two most popular dates since we might need additional time (in case we cannot solve all problems in the first discussion hour). [I guess we will need both slots.] Ciao Hannes & Derek ------------------------ * Monday, October 13, 2014: 8:00 am | Pacific Daylight Time (San Francisco, GMT-07:00) Meeting number: 642 251 152 Meeting password: security Audio connection: +1-877-668-4493 Call-in toll free number (US/Canada) +1-650-479-3208 Call-in toll number (US/Canada) Access code: 642 251 152 Meeting link: https://ietf.webex.com/ietf/j.php?MTID=3Dm2004a736e4054b7603d61deb8dc18cc= d -------- * Thursday, October 16, 2014: 8:00 am | Pacific Daylight Time (San Francisco, GMT-07:00) Meeting number: 640 895 208 Meeting password: security Audio connection: +1-877-668-4493 Call-in toll free number (US/Canada) +1-650-479-3208 Call-in toll number (US/Canada) Access code: 640 895 208 Meeting Link: https://ietf.webex.com/ietf/j.php?MTID=3Dm6ec7bf384355cb22169a149f372ccc9= d --HOhFGm9pfT36jFBnwUxkMT8WN5LBr4BLv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJULX+RAAoJEGhJURNOOiAtVFQH/AyiO43o1Ra992XcyBiLvM/e aXupGW+FpmFjXKSk0N4yiUhWlLmncFzblU5rI3qsvVGfURrD0yRy6H2yMoOlVWPu lAoIurknaRix0z3sHeKSGNTHX/uYy+02rVRDjy5JuCjaOlKxABXyAIqTAPKYJ81d vm5kuLvBoG/rkKROR0J4RURrYwbDTqtdEn4a1yKnD9Kp7s6XJVAlNnOYZJVCQsDx bHVJVEmNOqJAH2MPq9Vt5/c3Ncyh3/isx4DLObnnv0LxkLwgM+DLTS6PoRBNiJ+F FPHUGhtupjx176C4hEdd6252379Pyygz2sWMdu84l+w38+6TYrWBn4P+sgVDwYk= =gFJm -----END PGP SIGNATURE----- --HOhFGm9pfT36jFBnwUxkMT8WN5LBr4BLv-- From nobody Thu Oct 2 09:45:00 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 603921A8852 for ; Thu, 2 Oct 2014 09:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.987 X-Spam-Level: X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZGiBgCNi9Qi for ; Thu, 2 Oct 2014 09:44:58 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D3C21A1A47 for ; Thu, 2 Oct 2014 09:44:58 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s92GirAb010659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 2 Oct 2014 16:44:54 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s92GipSe003132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 2 Oct 2014 16:44:52 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s92GiphI017099; Thu, 2 Oct 2014 16:44:51 GMT Received: from [192.168.1.7] (/24.86.14.216) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 02 Oct 2014 09:44:50 -0700 References: <542D7F91.90408@gmx.net> Mime-Version: 1.0 (1.0) In-Reply-To: <542D7F91.90408@gmx.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <1EDD3C1B-7BD7-4106-8BD6-E6869D5DD925@oracle.com> X-Mailer: iPhone Mail (11D257) From: Phil Hunt Date: Thu, 2 Oct 2014 09:44:48 -0700 To: Hannes Tschofenig X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/H0zOHJ8eamNSH963gT6ifSKQQYs Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth & Authentication: Conference Calls Scheduled X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 16:44:59 -0000 Monday is Canadian Thanksgiving holiday. Apologies if I marked that as yes i= n the survey.=20 I will try to attend monday anyway if thursday is no good.=20 Phil > On Oct 2, 2014, at 9:38, Hannes Tschofenig wro= te: >=20 > Hi all, >=20 > based on the availability of those who expressed interest in the "OAuth > & authentication" conference call we have selected two dates, namely >=20 > * Monday, October 13, 2014: 8:00 am | Pacific Daylight Time (San > Francisco, GMT-07:00) >=20 > * Thursday, October 16, 2014: 8:00 am | Pacific Daylight Time (San > Francisco, GMT-07:00) >=20 > We picked the two most popular dates since we might need additional time > (in case we cannot solve all problems in the first discussion hour). [I > guess we will need both slots.] >=20 > Ciao > Hannes & Derek >=20 > ------------------------ >=20 > * Monday, October 13, 2014: 8:00 am | Pacific Daylight Time (San > Francisco, GMT-07:00) >=20 > Meeting number: 642 251 152 > Meeting password: security >=20 > Audio connection: > +1-877-668-4493 Call-in toll free number (US/Canada) > +1-650-479-3208 Call-in toll number (US/Canada) >=20 > Access code: 642 251 152 >=20 > Meeting link: > https://ietf.webex.com/ietf/j.php?MTID=3Dm2004a736e4054b7603d61deb8dc18ccd= >=20 > -------- >=20 > * Thursday, October 16, 2014: 8:00 am | Pacific Daylight Time (San > Francisco, GMT-07:00) >=20 > Meeting number: 640 895 208 > Meeting password: security >=20 > Audio connection: > +1-877-668-4493 Call-in toll free number (US/Canada) > +1-650-479-3208 Call-in toll number (US/Canada) >=20 > Access code: 640 895 208 >=20 > Meeting Link: > https://ietf.webex.com/ietf/j.php?MTID=3Dm6ec7bf384355cb22169a149f372ccc9d= >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Thu Oct 2 10:00:01 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 883261A005D; Thu, 2 Oct 2014 09:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2IjDu3-4iRh; Thu, 2 Oct 2014 09:59:50 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5401A86F8; Thu, 2 Oct 2014 09:59:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C9238BE8A; Thu, 2 Oct 2014 17:59:49 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKvZ-6GleQiw; Thu, 2 Oct 2014 17:59:48 +0100 (IST) Received: from [10.87.48.10] (unknown [86.42.29.169]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 08314BE7D; Thu, 2 Oct 2014 17:59:48 +0100 (IST) Message-ID: <542D8483.4030207@cs.tcd.ie> Date: Thu, 02 Oct 2014 17:59:47 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Mike Jones , Alissa Cooper , The IESG References: <20141001192433.1934.82385.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739439BAB371E@TK5EX14MBXC288.redmond.corp.microsoft.com> <542D73E2.6080406@cs.tcd.ie> <4E1F6AAD24975D4BA5B16804296739439BAB3E04@TK5EX14MBXC288.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439BAB3E04@TK5EX14MBXC288.redmond.corp.microsoft.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Hj8N341iphRw9b14Z7wBFIQftqQ Cc: "oauth-chairs@tools.ietf.org" , "draft-ietf-oauth-json-web-token@tools.ietf.org" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Alissa Cooper's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 16:59:57 -0000 On 02/10/14 17:25, Mike Jones wrote: > OK - I'll start prefixing my text with "Mike> ". Many thanks. S > > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Thursday, October 02, 2014 8:49 AM > To: Mike Jones; Alissa Cooper; The IESG > Cc: oauth-chairs@tools.ietf.org; draft-ietf-oauth-json-web-token@tools.ietf.org; oauth@ietf.org > Subject: Re: [OAUTH-WG] Alissa Cooper's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS) > > > Mike, > > I cannot tell which is your text and which not. > > Can you please use a better quoting style? These docs are going to be a total PITA to handle otherwise. > > Thanks, > S. > > > On 02/10/14 16:14, Mike Jones wrote: >> Responding to the DISCUSS below… >> >> >> >> -----Original Message----- >> From: Alissa Cooper [mailto:alissa@cooperw.in] >> Sent: Wednesday, October 01, 2014 12:25 PM >> To: The IESG >> Cc: oauth-chairs@tools.ietf.org; >> draft-ietf-oauth-json-web-token@tools.ietf.org >> Subject: Alissa Cooper's Discuss on >> draft-ietf-oauth-json-web-token-27: (with DISCUSS) >> >> >> >> Alissa Cooper has entered the following ballot position for >> >> draft-ietf-oauth-json-web-token-27: Discuss >> >> >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut >> this introductory paragraph, however.) >> >> >> >> >> >> Please refer to >> http://www.ietf.org/iesg/statement/discuss-criteria.html >> >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> >> >> >> The document, along with other ballot positions, can be found here: >> >> http://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/ >> >> >> >> >> >> >> >> ---------------------------------------------------------------------- >> >> DISCUSS: >> >> ---------------------------------------------------------------------- >> >> >> >> == Section 12 == >> >> >> >> "A JWT may contain privacy-sensitive information. When this is the >> >> case, measures must be taken to prevent disclosure of this >> >> information to unintended parties." >> >> >> >> It seems to me that this should be a normative MUST, particularly in light of the fact that claims are being defined that are meant to directly identify users (e.g., sub) and other claims defined here or later could do so as well. >> >> >> >> There seems to be debate whether a 2119 language should be used other than when describing protocol requirements. Jim Schaad (the JOSE chair) believes that they shouldn’t and these documents have followed that convention. >> >> >> >> "One way to achieve this is to use >> >> an encrypted JWT. Another way is to ensure that JWTs containing >> >> unencrypted privacy-sensitive information are only transmitted over >> >> encrypted channels or protocols, such as TLS." >> >> >> >> Since sensitive JWTs should be protected from both intermediary >> observation and from being sent to unintended recipients, I would >> >> suggest: >> >> >> >> One way to achieve this is to use an encrypted JWT and authenticate the recipient. Another way is to ensure that JWTs containing unencrypted privacy-sensitive information are only transmitted over encrypted channels or protocols that also support endpoint authentication, such as TLS. >> >> >> >> Thanks for this suggested language. We can incorporate something like that. >> >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> From nobody Thu Oct 2 10:01:33 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA271A0687 for ; Thu, 2 Oct 2014 10:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 4AfBRzQ3fuCh for ; Thu, 2 Oct 2014 10:01:20 -0700 (PDT) Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) by ietfa.amsl.com (Postfix) with SMTP id BD4021A005D for ; Thu, 2 Oct 2014 10:01:19 -0700 (PDT) Received: (qmail 13222 invoked by uid 0); 2 Oct 2014 17:01:11 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy1.mail.unifiedlayer.com with SMTP; 2 Oct 2014 17:01:11 -0000 Received: from box320.bluehost.com ([69.89.31.120]) by CMOut01 with id yH0y1o01B2bWBD901H11MC; Thu, 02 Oct 2014 11:01:02 -0600 X-Authority-Analysis: v=2.1 cv=LbyvtFvi c=1 sm=1 tr=0 a=6lV6tj8ir7tGSl/9xQZNPA==:117 a=6lV6tj8ir7tGSl/9xQZNPA==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=ekOJvlQLSnQA:10 a=TFpiKACsOTAA:10 a=8nJEP1OIZ-IA:10 a=ybLvy4ZQAAAA:8 a=5NP8F5kPYUUA:10 a=Omq5qJSqaZAA:10 a=VVlED5B4AAAA:8 a=NojvYFcnAAAA:8 a=48vgC7mUAAAA:8 a=ckPAkEYshELDdqfM49oA:9 a=SHKYJV05F9t965G3:21 a=1qngh2CU2DuWiWUk:21 a=wPNLvfGTeEIA:10 a=NU7HZUQD-k8A:10 a=T8E0iRN_syYA:10 a=9uUzcS5Nrb8A:10 a=BFDKbZatV3MA:10 a=lZB815dzVvQA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=jkemp.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=q+wu/Yamr/rPVIzO/JRJTng6GRY5+JOtgHR9bYvSgO0=; b=LDo0pzaMyS/tZN5ayu+LILANMUbAUvtVAEa+f11c4V1+dKoGBnMVSg9PnkGYwSi2yoAKqzkG+d1hDDB7+bMoqmJa3aFBQNbucBDO8JoaD412+L7dsU8a87xd7i6YAtIE; Received: from [208.105.152.92] (port=47234 helo=[10.0.0.198]) by box320.bluehost.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XZjkR-0005y2-O1; Thu, 02 Oct 2014 11:00:59 -0600 Message-ID: <542D84C7.1090203@jkemp.net> Date: Thu, 02 Oct 2014 13:00:55 -0400 From: John Kemp User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Phil Hunt , Hannes Tschofenig References: <542D7F91.90408@gmx.net> <1EDD3C1B-7BD7-4106-8BD6-E6869D5DD925@oracle.com> In-Reply-To: <1EDD3C1B-7BD7-4106-8BD6-E6869D5DD925@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {1122:box320.bluehost.com:jkempnet:jkemp.net} {sentby:smtp auth 208.105.152.92 authed with john+jkemp.net} Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/FZNw1BIF_18PTnOORscRar9Sh2M Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth & Authentication: Conference Calls Scheduled X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 17:01:23 -0000 Monday is also Columbus Day in the US, and thus many people there are also off work on that day. Regards, - johnk On 10/02/2014 12:44 PM, Phil Hunt wrote: > Monday is Canadian Thanksgiving holiday. Apologies if I marked that as yes in the survey. > > I will try to attend monday anyway if thursday is no good. > > Phil > >> On Oct 2, 2014, at 9:38, Hannes Tschofenig wrote: >> >> Hi all, >> >> based on the availability of those who expressed interest in the "OAuth >> & authentication" conference call we have selected two dates, namely >> >> * Monday, October 13, 2014: 8:00 am | Pacific Daylight Time (San >> Francisco, GMT-07:00) >> >> * Thursday, October 16, 2014: 8:00 am | Pacific Daylight Time (San >> Francisco, GMT-07:00) >> >> We picked the two most popular dates since we might need additional time >> (in case we cannot solve all problems in the first discussion hour). [I >> guess we will need both slots.] >> >> Ciao >> Hannes & Derek >> >> ------------------------ >> >> * Monday, October 13, 2014: 8:00 am | Pacific Daylight Time (San >> Francisco, GMT-07:00) >> >> Meeting number: 642 251 152 >> Meeting password: security >> >> Audio connection: >> +1-877-668-4493 Call-in toll free number (US/Canada) >> +1-650-479-3208 Call-in toll number (US/Canada) >> >> Access code: 642 251 152 >> >> Meeting link: >> https://ietf.webex.com/ietf/j.php?MTID=m2004a736e4054b7603d61deb8dc18ccd >> >> -------- >> >> * Thursday, October 16, 2014: 8:00 am | Pacific Daylight Time (San >> Francisco, GMT-07:00) >> >> Meeting number: 640 895 208 >> Meeting password: security >> >> Audio connection: >> +1-877-668-4493 Call-in toll free number (US/Canada) >> +1-650-479-3208 Call-in toll number (US/Canada) >> >> Access code: 640 895 208 >> >> Meeting Link: >> https://ietf.webex.com/ietf/j.php?MTID=m6ec7bf384355cb22169a149f372ccc9d >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From nobody Thu Oct 2 13:19:53 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 746BE1A86EC for ; Thu, 2 Oct 2014 13:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.566 X-Spam-Level: X-Spam-Status: No, score=-1.566 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=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 SBjR4z4g_18R for ; Thu, 2 Oct 2014 13:19:38 -0700 (PDT) Received: from mx0a-0019e102.pphosted.com (mx0a-0019e102.pphosted.com [67.231.149.242]) (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 1A06D1A02DE for ; Thu, 2 Oct 2014 13:19:35 -0700 (PDT) Received: from pps.filterd (m0074411.ppops.net [127.0.0.1]) by mx0a-0019e102.pphosted.com (8.14.7/8.14.7) with SMTP id s92KJYfu002643 for ; Thu, 2 Oct 2014 15:19:35 -0500 Received: from il06msg01 ([129.188.136.17]) by mx0a-0019e102.pphosted.com with ESMTP id 1psc3404dt-1 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 02 Oct 2014 15:19:35 -0500 Received: from il06msg01 (il06vts02.mot.com [129.188.137.142]) by il06msg01 (8.14.3/8.14.3) with ESMTP id s92KJQni029900 for ; Thu, 2 Oct 2014 15:19:26 -0500 (CDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0190.outbound.protection.outlook.com [207.46.163.190]) by il06msg01 (8.14.3/8.14.3) with ESMTP id s92KJPaK029892 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 2 Oct 2014 15:19:26 -0500 (CDT) Received: from DM2PR04MB735.namprd04.prod.outlook.com (10.141.177.17) by DM2PR04MB735.namprd04.prod.outlook.com (10.141.177.17) with Microsoft SMTP Server (TLS) id 15.0.1044.10; Thu, 2 Oct 2014 20:19:24 +0000 Received: from DM2PR04MB735.namprd04.prod.outlook.com ([10.141.177.17]) by DM2PR04MB735.namprd04.prod.outlook.com ([10.141.177.17]) with mapi id 15.00.1044.008; Thu, 2 Oct 2014 20:19:24 +0000 From: Lewis Adam-CAL022 To: "oauth@ietf.org" Thread-Topic: Definition of additional client profiles Thread-Index: Ac/efif286mdd+gZQsiEK8NyldR6SA== Date: Thu, 2 Oct 2014 20:19:24 +0000 Message-ID: <2e05cf8c68364a3b94aca4b370af344d@DM2PR04MB735.namprd04.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [73.44.116.7] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR04MB735; x-forefront-prvs: 03524FBD26 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(54356999)(50986999)(110136001)(76482002)(4396001)(108616004)(66066001)(106356001)(229853001)(33646002)(85306004)(99396003)(120916001)(16236675004)(95666004)(107046002)(18717965001)(107886001)(99286002)(105586002)(2351001)(76576001)(10300001)(19625215002)(15202345003)(92566001)(20776003)(74316001)(80022003)(64706001)(19300405004)(85852003)(19580395003)(21056001)(87936001)(97736003)(86362001)(46102003)(15975445006)(31966008)(2501002)(2656002)(101416001)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR04MB735; H:DM2PR04MB735.namprd04.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_2e05cf8c68364a3b94aca4b370af344dDM2PR04MB735namprd04pro_" MIME-Version: 1.0 X-OriginatorOrg: motorolasolutions.com X-CFilter-Loop: Reflected X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1410020199 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/M9-Y00Kypo2EXCvA5bSdRhVLWvk Subject: [OAUTH-WG] Definition of additional client profiles X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 20:19:39 -0000 --_000_2e05cf8c68364a3b94aca4b370af344dDM2PR04MB735namprd04pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, 6749 defines three client profiles which are mapped to either confidential = or public client types. Have any new client profiles since been defined? And is there a process or= place to put those additional profiles? For example I'm thinking about additional confidential client types, maybe = a legacy WS-* WSC accessing a WS-* WSP, and that WSP is acting as a confide= ntial client to a RESTful RS. Just curious if further definitions are being collected anywhere. I'm not = sure if it really matters, maybe confidential is confidential, regardless o= f if it's a web server or a WS-* WSP, but since the spec went as far as to = define the client profiles then maybe there is a place to define more. Tx! adam --_000_2e05cf8c68364a3b94aca4b370af344dDM2PR04MB735namprd04pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

6749 defines three client profiles which are mapped = to either confidential or public client types.

 

Have any new client profiles since been defined?&nbs= p; And is there a process or place to put those additional profiles?

 

For example I’m thinking about additional conf= idential client types, maybe a legacy WS-* WSC accessing a WS-* WSP, and th= at WSP is acting as a confidential client to a RESTful RS.

 

Just curious if further definitions are being collec= ted anywhere.  I’m not sure if it really matters, maybe confiden= tial is confidential, regardless of if it’s a web server or a WS-* WS= P, but since the spec went as far as to define the client profiles then maybe there is a place to define more.

 

 

 

Tx!
adam

 

 

--_000_2e05cf8c68364a3b94aca4b370af344dDM2PR04MB735namprd04pro_-- From nobody Thu Oct 2 13:26:02 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FB061A6F38 for ; Thu, 2 Oct 2014 13:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.685 X-Spam-Level: X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1oZVFJNrjy4O for ; Thu, 2 Oct 2014 13:25:59 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5021A02DE for ; Thu, 2 Oct 2014 13:25:59 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D3BF4B2E176; Thu, 2 Oct 2014 16:25:58 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id C7EFFB2E063; Thu, 2 Oct 2014 16:25:58 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.195]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.03.0174.001; Thu, 2 Oct 2014 16:25:58 -0400 From: "Richer, Justin P." To: Lewis Adam-CAL022 Thread-Topic: [OAUTH-WG] Definition of additional client profiles Thread-Index: Ac/efif286mdd+gZQsiEK8NyldR6SAAInI4A Date: Thu, 2 Oct 2014 20:25:57 +0000 Message-ID: References: <2e05cf8c68364a3b94aca4b370af344d@DM2PR04MB735.namprd04.prod.outlook.com> In-Reply-To: <2e05cf8c68364a3b94aca4b370af344d@DM2PR04MB735.namprd04.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.4.54] Content-Type: multipart/alternative; boundary="_000_B68414D7583B47C983398F19A7458F12mitreorg_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/kwqGNjFc6I7xTqXtubgxlhefCVU Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Definition of additional client profiles X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 20:26:01 -0000 --_000_B68414D7583B47C983398F19A7458F12mitreorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable In BlueButton+ REST, we defined a matrix of client types based on whether t= he client could keep a configuration-time secret (the "registration_jwt", p= redecessor to the "software_statement") and a particular kind of runtime se= cret (the client secret) in addition to the token. That matrix is defined h= ere: http://bluebuttontoolkit.healthit.gov/blue-button-plus-pull/ I've seen other attempts to categorize clients on similar lines: what can t= he client connect to, what can it keep secret, and from whom. -- Justin On Oct 2, 2014, at 4:19 PM, Lewis Adam-CAL022 > wrote: Hi, 6749 defines three client profiles which are mapped to either confidential = or public client types. Have any new client profiles since been defined? And is there a process or= place to put those additional profiles? For example I=92m thinking about additional confidential client types, mayb= e a legacy WS-* WSC accessing a WS-* WSP, and that WSP is acting as a confi= dential client to a RESTful RS. Just curious if further definitions are being collected anywhere. I=92m no= t sure if it really matters, maybe confidential is confidential, regardless= of if it=92s a web server or a WS-* WSP, but since the spec went as far as= to define the client profiles then maybe there is a place to define more. Tx! adam _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_B68414D7583B47C983398F19A7458F12mitreorg_ Content-Type: text/html; charset="Windows-1252" Content-ID: <7E31B29BE913F641B9FA55CAC8F5F2B2@imc.mitre.org> Content-Transfer-Encoding: quoted-printable In BlueButton+ REST, we defined a matrix of client types based on wheth= er the client could keep a configuration-time secret (the "registratio= n_jwt", predecessor to the "software_statement") and a parti= cular kind of runtime secret (the client secret) in addition to the token. That matrix is defined here:


I've seen other attempts to categorize clients on similar lines: what = can the client connect to, what can it keep secret, and from whom.

 -- Justin

On Oct 2, 2014, at 4:19 PM, Lewis Adam-CAL022 <Adam.Lewis@motorolasolutions.com> wr= ote:

Hi,

 

6749 defines three client profiles which are mapped = to either confidential or public client types.

 

Have any new client profiles since been defined?&nbs= p; And is there a process or place to put those additional profiles?

 

For example I=92m thinking about additional confiden= tial client types, maybe a legacy WS-* WSC accessing a WS-* WSP, and that W= SP is acting as a confidential client to a RESTful RS.

 

Just curious if further definitions are being collec= ted anywhere.  I=92m not sure if it really matters, maybe confidential= is confidential, regardless of if it=92s a web server or a WS-* WSP, but s= ince the spec went as far as to define the client profiles then maybe there is a place to define more.

 

 

 

Tx!
adam

 

 

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

--_000_B68414D7583B47C983398F19A7458F12mitreorg_-- From nobody Thu Oct 2 14:49:01 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBE741ACE2A for ; Thu, 2 Oct 2014 14:48:48 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k0FGfN2XuEQe for ; Thu, 2 Oct 2014 14:48:42 -0700 (PDT) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51A651ACE20 for ; Thu, 2 Oct 2014 14:48:42 -0700 (PDT) Received: by mail-qa0-f54.google.com with SMTP id i13so471qae.41 for ; Thu, 02 Oct 2014 14:48:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=3YA1a9w1A7JbGPOsvLkt6obAWuuty5nIY5aH5K6+lcg=; b=dpHpRA8HQC9BgVnmrv65ltbOTJwREkVu96CKarrtAGDvfPWTnCTnlsPokkMcKoqT17 eBZwgX/+IbOETDkWwkD4EDHnspbedqqoqGopwi5n6rSbCl723ligJIUw6fO5/VO8jbsf y84MNoixWbcHT5Gyb6UKI8TQRSZHTS/Qxj4Uek/HJ5ADvkSenI/Ezhjft5VMpVAYH7Yl BaypafAyxdWBG0YQP5frGukAvmmBU8dQHRhGmgcsQSp86LLpE3AMBo/DGGAXH9hZujZU 7vpzrFOrN1cVSjwmQ1x4tHUNAxPSzH83ZwtpN2YMDZ7q3ShC6F1vmvoInWkz5/gOHnks XoCQ== X-Gm-Message-State: ALoCoQlFQEXDpBS9kjelxL7o82efPtx7r5XIG02nlzpUq5M0tk4cZFUJtESkxOMqpJNee6J6fZQo X-Received: by 10.140.85.227 with SMTP id n90mr2002511qgd.89.1412286521277; Thu, 02 Oct 2014 14:48:41 -0700 (PDT) Received: from [192.168.1.216] (186-106-131-109.baf.movistar.cl. [186.106.131.109]) by mx.google.com with ESMTPSA id g5sm4224794qaz.39.2014.10.02.14.48.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 Oct 2014 14:48:40 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_7CF43E30-A42E-4F15-A8B1-CD8E2BD7882C"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Bradley In-Reply-To: <2e05cf8c68364a3b94aca4b370af344d@DM2PR04MB735.namprd04.prod.outlook.com> Date: Thu, 2 Oct 2014 18:48:54 -0300 Message-Id: <948F628D-93B9-49B5-B725-603B09B90882@ve7jtb.com> References: <2e05cf8c68364a3b94aca4b370af344d@DM2PR04MB735.namprd04.prod.outlook.com> To: Adam Lewis X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/pji6VGOU2tpqiBS9OW4rDUXR6Po Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Definition of additional client profiles X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 21:48:48 -0000 --Apple-Mail=_7CF43E30-A42E-4F15-A8B1-CD8E2BD7882C Content-Type: multipart/alternative; boundary="Apple-Mail=_1965D153-2F8C-4CE8-9C03-F3F0DFD36ACD" --Apple-Mail=_1965D153-2F8C-4CE8-9C03-F3F0DFD36ACD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Additional authentication types have been defined have been defined for = confidential clients, such as SAML and JWT assertion. = http://tools.ietf.org/html/draft-ietf-oauth-assertions There will likely be more of that, but I don't think there are likely to = be other client types beyond the two.=20 John B. On Oct 2, 2014, at 5:19 PM, Lewis Adam-CAL022 = wrote: > Hi, > =20 > 6749 defines three client profiles which are mapped to either = confidential or public client types. > =20 > Have any new client profiles since been defined? And is there a = process or place to put those additional profiles? > =20 > For example I=92m thinking about additional confidential client types, = maybe a legacy WS-* WSC accessing a WS-* WSP, and that WSP is acting as = a confidential client to a RESTful RS. > =20 > Just curious if further definitions are being collected anywhere. I=92m= not sure if it really matters, maybe confidential is confidential, = regardless of if it=92s a web server or a WS-* WSP, but since the spec = went as far as to define the client profiles then maybe there is a place = to define more. > =20 > =20 > =20 > Tx! > adam > =20 > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_1965D153-2F8C-4CE8-9C03-F3F0DFD36ACD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Additional authentication types have been defined = have been defined for confidential clients, such as SAML and JWT = assertion.  http://too= ls.ietf.org/html/draft-ietf-oauth-assertions

There = will likely be more of that, but I don't think there are likely to be = other client types beyond the two. 

John = B.

On Oct 2, 2014, at 5:19 PM, Lewis Adam-CAL022 = <Adam.Lewis@motorolasoluti= ons.com> wrote:

Hi,
 
6749 = defines three client profiles which are mapped to either confidential or = public client types.
 
Have any = new client profiles since been defined?  And is there a process or = place to put those additional profiles?
 
For = example I=92m thinking about additional confidential client types, maybe = a legacy WS-* WSC accessing a WS-* WSP, and that WSP is acting as a = confidential client to a RESTful RS.
 
Just = curious if further definitions are being collected anywhere.  I=92m = not sure if it really matters, maybe confidential is confidential, = regardless of if it=92s a web server or a WS-* WSP, but since the spec = went as far as to define the client profiles then maybe there is a place = to define more.
 
 
 
Tx!
adam
 
 
________________________________= _______________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_1965D153-2F8C-4CE8-9C03-F3F0DFD36ACD-- --Apple-Mail=_7CF43E30-A42E-4F15-A8B1-CD8E2BD7882C Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNDEwMDIyMTQ4NTRaMCMGCSqGSIb3DQEJBDEWBBQ4Kkes75K7qb3A083kETDb jU1OOTCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQCcp436cuMCvS6ErRRPYWrnJA51+swBt94DwnK5PRTW7yJwrYrnMrT7 8MLpRatffVvTnFiZAojWXSmJsAcl+IL0dZHwYR8/9JayueXL9MlvQ4DOpUpHhJrRuMufgWPHamjA BoW5scIxq49T2YHHkUYWt52PPvzo07X9SDNlB0HACuem9njE2wE3kf3g8ArCQZ2jZQP1QFW5rKWw SZTcMFg99cA5Im1vtMD6gg1xLVwkLLqKaWsi++XrRUH8l4PF14mqEcIN6AkoEyOhHibp33gzT1vW VdgiNK6VkR+RWfU4TSLnlbF26Zu7XV63H3pwxdXHFjDcfo8VY3PI+x+tvVFlAAAAAAAA --Apple-Mail=_7CF43E30-A42E-4F15-A8B1-CD8E2BD7882C-- From nobody Sat Oct 4 17:18:01 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 199A41A0332; Sat, 4 Oct 2014 17:17:59 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Mw12NEr-Rc9; Sat, 4 Oct 2014 17:17:55 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0723.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::723]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 966EC1A031A; Sat, 4 Oct 2014 17:17:55 -0700 (PDT) Received: from CO2PR03CA0033.namprd03.prod.outlook.com (10.141.194.160) by BN3PR0301MB1203.namprd03.prod.outlook.com (25.161.207.156) with Microsoft SMTP Server (TLS) id 15.0.1044.10; Sun, 5 Oct 2014 00:17:29 +0000 Received: from BL2FFO11FD029.protection.gbl (2a01:111:f400:7c09::165) by CO2PR03CA0033.outlook.office365.com (2a01:111:e400:1414::32) with Microsoft SMTP Server (TLS) id 15.0.1044.10 via Frontend Transport; Sun, 5 Oct 2014 00:17:28 +0000 Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD029.mail.protection.outlook.com (10.173.160.69) with Microsoft SMTP Server (TLS) id 15.0.1039.16 via Frontend Transport; Sun, 5 Oct 2014 00:17:27 +0000 Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.93]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.193]) with mapi id 14.03.0210.003; Sun, 5 Oct 2014 00:17:02 +0000 From: Mike Jones To: Barry Leiba , The IESG Thread-Topic: Barry Leiba's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) Thread-Index: AQHP3Y/7ZwPSkFMFnEGZknpDTwtaYJwgpBqA Date: Sun, 5 Oct 2014 00:17:01 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439BAE9ADF@TK5EX14MBXC286.redmond.corp.microsoft.com> References: <20141001155414.3543.53089.idtracker@ietfa.amsl.com> In-Reply-To: <20141001155414.3543.53089.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(979002)(6009001)(438002)(377454003)(51704005)(199003)(189002)(50854003)(13464003)(51914003)(52044002)(77096002)(85306004)(19580395003)(15975445006)(31966008)(85852003)(87936001)(33656002)(104016003)(86612001)(26826002)(15202345003)(230783001)(50986999)(76176999)(6806004)(54356999)(84676001)(92726001)(92566001)(2656002)(85806002)(19580405001)(44976005)(86362001)(69596002)(55846006)(97736003)(68736004)(23676002)(106466001)(81156004)(66066001)(107046002)(64706001)(21056001)(50466002)(4396001)(95666004)(47776003)(20776003)(99396003)(46102003)(106116001)(76482002)(80022003)(120916001)(10300001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1203; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1203; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0355F3A3AE Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/gk_sdUL82N1ku94ZE9JPuZoKxT8 Cc: "oauth-chairs@tools.ietf.org" , "draft-ietf-oauth-json-web-token@tools.ietf.org" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Barry Leiba's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2014 00:17:59 -0000 VGhhbmtzIGZvciB5b3VyIHJldmlldywgQmFycnkuICBJJ20gYWRkaW5nIHRoZSB3b3JraW5nIGdy b3VwIHNvIHRoZXnigJlyZSBhd2FyZSBvZiB0aGVzZSBjb21tZW50cy4gIEF0IFN0ZXBoZW4gRmFy cmVsbCdzIHJlcXVlc3QsIEknbSByZXNwb25kaW5nIHdpdGggIj4gIiBsaW5lIHByZWZpeGVzIG9u IHByZXZpb3VzIHRocmVhZCBjb250ZW50LiAgSSdtIGFsc28gcmVwZWF0aW5nIChhbmQgaW4gdGhl IGZpcnN0IGNhc2UsIGF1Z21lbnRpbmcpIG15IHByZXZpb3VzIHJlc3BvbnNlcyB0byB0aGUgRElT Q1VTUyBjb21tZW50cyBpbiB0aGlzIGNvbnNvbGlkYXRlZCBtZXNzYWdlLg0KDQo+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEJhcnJ5IExlaWJhIFttYWlsdG86YmFycnlsZWli YUBjb21wdXRlci5vcmddDQo+IFNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAwMSwgMjAxNCA4OjU0 IEFNDQo+IFRvOiBUaGUgSUVTRw0KPiBDYzogb2F1dGgtY2hhaXJzQHRvb2xzLmlldGYub3JnOyBk cmFmdC1pZXRmLW9hdXRoLWpzb24td2ViLQ0KPiB0b2tlbkB0b29scy5pZXRmLm9yZw0KPiBTdWJq ZWN0OiBCYXJyeSBMZWliYSdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi10 b2tlbi0yNzogKHdpdGgNCj4gRElTQ1VTUyBhbmQgQ09NTUVOVCkNCj4gDQo+IEJhcnJ5IExlaWJh IGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPiBkcmFmdC1p ZXRmLW9hdXRoLWpzb24td2ViLXRva2VuLTI3OiBEaXNjdXNzDQo+IA0KPiBXaGVuIHJlc3BvbmRp bmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwg ZW1haWwNCj4gYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVs IGZyZWUgdG8gY3V0IHRoaXMgaW50cm9kdWN0b3J5DQo+IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+ IA0KPiANCj4gUGxlYXNlIHJlZmVyIHRvIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1l bnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQo+IGZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElF U0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQo+IA0KPiANCj4gVGhlIGRvY3VtZW50 LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0K PiBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtb2F1dGgtanNvbi13 ZWItdG9rZW4vDQo+IA0KPiANCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gRElTQ1VTUzoNCj4gLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KPiANCj4gSSBoYXZlIHR3byBwb2ludHMgdGhhdCBJJ2QgbGlrZSB0byBnZXQg cmVzb2x2ZWQgYmVmb3JlIGhhcHBpbHkgYXBwcm92aW5nIHRoaXMgZmluZQ0KPiBkb2N1bWVudDoN Cj4gDQo+IC0tIFNlY3Rpb24gNy4xIC0tDQo+IA0KPiBUaGUgY29tcGFyaXNvbiB5b3Ugc3BlY2lm eSBpcyBhcyBzcGVjaWZpZWQgaW4gUkZDIDcxNTksIFNlY3Rpb24gOC4zLCB3aGljaCBpcyB0bw0K PiAidHJhbnNmb3JtIHRoZSB0ZXh0dWFsIHJlcHJlc2VudGF0aW9uIGludG8gc2VxdWVuY2VzIG9m IFVuaWNvZGUgY29kZSB1bml0cyBhbmQNCj4gdGhlbiBwZXJmb3JtIHRoZSBjb21wYXJpc29uIG51 bWVyaWNhbGx5LCBjb2RlIHVuaXQgYnkgY29kZSB1bml0Ii4gIFRoaXMgaGFzIG5vDQo+IHJlZ2Fy ZCBmb3IgdGV4dCBjYXNlLCBhbmQgc28gaXQncyBhIGNhc2Utc2Vuc2l0aXZlIGNvbXBhcmlzb24u DQo+IA0KPiBBbmQsIHlldCwgU2VjdGlvbnMgNS4xIGFuZCA1LjIgc3BlY2lmeSB0aGF0IHRoZSB2 YWx1ZXMgb2YgdHlwIGFuZCBjdHkgYXJlIGNhc2UtDQo+IGluc2Vuc2l0aXZlLCBhbmQgc3BlY2lm eSB1c2luZyB1cHBlciBjYXNlIGFzIGEgU0hPVUxELCBmb3IgImNvbXBhdGliaWxpdHkgd2l0aA0K PiBsZWdhY3kgaW1wbGVtZW50YXRpb25zIi4NCj4gDQo+IEl0IGRvZXNuJ3Qgc2VlbSB0aGF0ICJs ZWdhY3kiIGhhcyBhbnl0aGluZyB0byBkbyB3aXRoIHRoaXM6IHNvbWVvbmUgY29uZm9ybWluZw0K PiB0byAqdGhpcyogc3BlY2lmaWNhdGlvbiB3aWxsIGNvbXBhcmUgdGhlIHZhbHVlcyBvZiB0eXAg YW5kIGN0eSBVbmljb2RlLWNoYXJhY3Rlcg0KPiBieSBVbmljb2RlLWNoYXJhY3RlciwgYW5kIHdp bGwgZmFpbCB0byBtYXRjaCAiSldUIiB3aXRoICJqd3QiLg0KPiANCj4gSXMgdGhlcmUgbm90IGEg cHJvYmxlbSBoZXJlPw0KDQpXZSBjYW4gdXBkYXRlIHRoZSB0ZXh0IHRvIGNsYXJpZnkgdGhhdCBN SU1FIHR5cGUgY29tcGFyaXNvbnMgYXJlIGFuIGV4Y2VwdGlvbiB0byB0aGUg4oCcY29kZSB1bml0 IGJ5IGNvZGUgdW5pdOKAnSBjb21wYXJpc29uIHJ1bGUuICBUaGUgZHJhZnRzIHdpbGwgYWxzbyBi ZSBzY3J1dGluaXplZCBmb3Igb3RoZXIgcG9zc2libGUgb2NjdXJyZW5jZXMgb2YgZXhjZXB0aW9u cyB0byB0aGUgZGVmYXVsdCBzdHJpbmcgY29tcGFyaXNvbiBpbnN0cnVjdGlvbnMuICBGaW5hbGx5 LCB3ZSBjYW4gYWRkIGxhbmd1YWdlIHRvIDcuMSBhYm91dCAidW5sZXNzIG90aGVyd2lzZSBub3Rl ZCBmb3IgYSBwYXJ0aWN1bGFyIGtpbmQgb2Ygc3RyaW5nIiBzbyB0aGF0IGl0J3MgY2xlYXIgdGhh dCB0aGVyZSBhcmUgZXhjZXB0aW9ucyB0byB0aGUgcnVsZS4NCg0KPiAtLSBTZWN0aW9uIDEwLjMu MSAtLQ0KPiANCj4gTmljZSB0aGF0IHlvdSBjaXRlIDIwNDYgZm9yIG1lZGlhIHR5cGVzLCBidXQg dGhlICpyZWdpc3RyYXRpb24qIG9mIG1lZGlhIHR5cGVzIGlzDQo+IGRvY3VtZW50ZWQgaW4gUkZD IDY4MzgsIGFuZCB0aGlzIGRvY3VtZW50IGRvZXNuJ3QgcXVpdGUgY29uZm9ybSB0byB0aGF0LiAg VGhlDQo+IG9ubHkgdGhpbmcgbWlzc2luZyBpbiB0aGUgZG9jIGlzICJGcmFnbWVudCBpZGVudGlm aWVyIGNvbnNpZGVyYXRpb25zIiBpbiB0aGUNCj4gcmVnaXN0cmF0aW9uIHRlbXBsYXRlLCBidXQg NjgzOCBhbHNvIHN0cm9uZ2x5IHN1Z2dlc3RzIHJldmlldyBvZiB0aGUgbWVkaWEtdHlwZQ0KPiBy ZWdpc3RyYXRpb24gb24gdGhlIG1lZGlhLXR5cGVzIG1haWxpbmcgbGlzdC4gIEdpdmVuIHRoYXQg dGhpcyB3aWxsIG5vdCBnZXQgZXhwZXJ0DQo+IHJldmlldyAoYmVjYXVzZSBpdCdzIGFuIElFVEYt c3RyZWFtIFJGQyksIEknZCBsaWtlIHRvIGFzayBmb3IgYW4gZXhwbGljaXQgcmV2aWV3IG9uDQo+ IHRoZSBtZWRpYS10eXBlcyBsaXN0IHRvIG1ha2Ugc3VyZSB0aGF0IHRoZSByZWdpc3RyYXRpb24g aW5mb3JtYXRpb24gaXMgY29tcGxldGUNCj4gYW5kIG1ha2VzIHNlbnNlLg0KDQpUaGFua3MgZm9y IHRoZSA2ODMzIHJlZmVyZW5jZS4gIFdl4oCZbGwgdXNlIHRoYXQuICBJIGtub3cgdGhhdCBLYXRo bGVlbiBhbHJlYWR5IGluaXRpYXRlZCB0aGUgcmV2aWV3IG9uIHRoZSBtZWRpYS10eXBlcyBsaXN0 Lg0KIA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IENPTU1FTlQ6DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+ IC0tIEFic3RyYWN0IC0tDQo+IA0KPiAgICBUaGUgc3VnZ2VzdGVkIHByb251bmNpYXRpb24gb2Yg SldUIGlzIHRoZSBzYW1lIGFzIHRoZSBFbmdsaXNoIHdvcmQNCj4gICAgImpvdCIuDQo+IA0KPiBJ IGhhdmUgbm8gb2JqZWN0aW9uICh3ZWxsLCBJIGRvLCBidXQgaXQncyBub3QgZm9yIG1lIHRvIHNh eSBob3cgeW91IHdhbnQgdG8NCj4gcHJvbm91bmNlIGl0KSB0byBoYXZpbmcgdGhpcyBzZW50ZW5j ZSBpbiB0aGUgSW50cm9kdWN0aW9uLCBidXQgaXQgc2VlbXMgb3V0IG9mDQo+IHBsYWNlIGluIHRo ZSBBYnN0cmFjdCwgd2hpY2ggaXMgbWVhbnQgdG8gYmUgY29uY2lzZS4NCg0KT0sgLSBXZSBjYW4g cmVtb3ZlIGl0IGZyb20gdGhlIEFic3RyYWN0Lg0KDQo+IC0tIFNlY3Rpb24gNC4xIC0tDQo+IA0K PiBJdCBhcHBlYXJzIHRoYXQgYWxsIGNsYWltcyBkZWZpbmVkIGhlcmUgYXJlIE9QVElPTkFMLCBh bmQgZWFjaCBvbmUgc2F5cyBzbyBpbiBpdHMNCj4gc3Vic2VjdGlvbi4gIEdpdmVuIHRoYXQgdGhl eSAqYWxsKiBhcmUsIGl0IG1pZ2h0IGJlIHVzZWZ1bCB0byBzYXkgdGhhdCB1cCBmcm9udCwNCj4g bWF5YmUgd2l0aCBhIHNlbnRlbmNlIHRoYXQgc2F5cywgIkFsbCBjbGFpbXMgZGVmaW5lZCBpbiB0 aGlzIHNlY3Rpb24gYXJlDQo+IE9QVElPTkFMIHRvIHVzZS4iICAoSSBkb24ndCBmZWVsIHN0cm9u Z2x5IGFib3V0IHRoaXM7IGl0J3MganVzdCBhIHN1Z2dlc3Rpb24sIHNvIGRvDQo+IHdpdGggaXQg YXMgeW91IHNlZSBiZXN0LikgIFNlZSBhbHNvIG15IGNvbW1lbnQgb24gMTAuMS4xLCBiZWxvdy4N Cg0KRWRpdG9yaWFsbHksIHdlIGRlY2lkZWQgdG8gZGVzY3JpYmUgdGhlIG9wdGlvbmFsaXR5IG9m IGVhY2ggY2xhaW0gaW4gdGhlIGNsYWltIGRlZmluaXRpb24gc28gdGhhdCB3aGVuIHVzZWQgYXMg YSByZWZlcmVuY2Ugd2l0aG91dCByZWFkaW5nIHRoZSB3aG9sZSB0aGluZywgdGhlIG9wdGlvbmFs aXR5IHdpbGwgc3RpbGwgYmUgb2J2aW91cyB0byB0aGUgcmVhZGVyLg0KDQo+IC0tIFNlY3Rpb24g NC4xLjIgLS0NCj4gDQo+ICAgIFRoZSBzdWJqZWN0IHZhbHVlIE1BWSBiZSBzY29wZWQgdG8gYmUg bG9jYWxseQ0KPiAgICB1bmlxdWUgaW4gdGhlIGNvbnRleHQgb2YgdGhlIGlzc3VlciBvciBNQVkg YmUgZ2xvYmFsbHkgdW5pcXVlLg0KPiANCj4gT3IgaXQgTUFZIGJlIGFueXRoaW5nIGVsc2UsIGlu Y2x1ZGluZyBub3QgdW5pcXVlIGF0IGFsbC4gIElzIHRoYXQgd2hhdCB5b3UgbWVhbj8NCj4gT3Ig YXJlIHRoZXNlIG1lYW50IHRvIGJlIHR3byBvcHRpb25zLCBvbmUgb2Ygd2hpY2ggaGFzIHRvIGJl IHRydWU/ICBJZiBzbywgeW91DQo+IG5lZWQgdG8gcmUtZG8gdGhpcywgcGVyaGFwcyBsaWtlIHRo aXM6DQo+IA0KPiBORVcNCj4gICBUaGUgc3ViamVjdCB2YWx1ZSBNVVNUIGVpdGhlciBiZSBnbG9i YWxseSB1bmlxdWUsIG9yIGJlIHNjb3BlZA0KPiAgIHRvIGJlIGxvY2FsbHkgdW5pcXVlIGluIHRo ZSBjb250ZXh0IG9mIHRoZSBpc3N1ZXIuDQo+IEVORA0KDQpZb3VyIG5ldyBsYW5ndWFnZSBtYXRj aGVzIHRoZSBpbnRlbnQuICBJJ2xsIHBsYW4gdG8gcmV2aXNlIGFjY29yZGluZ2x5Lg0KDQo+IC0t IFNlY3Rpb24gMTAuMS4xIC0tDQo+IA0KPiBHaXZlbiB0aGF0IHRoZSBkZXNjcmlwdGlvbnMgb2Yg dGhlIGNsYWltcyBpbmNsdWRlIGEgc3RhdGVtZW50IHRoYXQgdGhlaXIgdXNlIGlzDQo+IE9QVElP TkFMLCBzaG91bGQgdGhlcmUgbm90IGJlIGFuIGVudHJ5IGluIHRoZSB0YWJsZSB0aGF0IHNheXMg d2hldGhlciB0aGUgY2xhaW0NCj4gaXMgT1BUSU9OQUwgb3IgUkVRVUlSRUQgPyAgT3IgaXMgaXQg dGhlIGludGVudCB0aGF0DQo+ICphbGwqIG9mIHRoZW0gYWx3YXlzIGJlIE9QVElPTkFMID8gIE9y IGlzIGl0IHN1ZmZpY2llbnQgdG8gaGF2ZSB0aGF0IGluZGljYXRpb24gaW4NCj4gdGhlIHJlZmVy ZW5jZSBkb2N1bWVudGF0aW9uID8NCg0KV2hhdCBjbGFpbXMgYXJlIHJlcXVpcmVkIGJ5IGFwcGxp Y2F0aW9ucyB3aWxsIGJlIHNwZWNpZmllZCBieSBhcHBsaWNhdGlvbnMuICBGb3IgaW5zdGFuY2Us IHNvbWUgYXBwbGljYXRpb25zIHVzaW5nIEpXVHMgcmVxdWlyZSB0aGF0IHRoZSBpc3N1ZXIsIHN1 YmplY3QsIGFuZCBhdWRpZW5jZSBiZSBwcmVzZW50LiAgVGhlcmVmb3JlLCBJIGRvbid0IHRoaW5r IHRoYXQgYWRkaW5nIGEgdGFibGUgZW50cnkgd291bGQgaGVscCBhIGdyZWF0IGRlYWwsIGFuZCBp dCBjb3VsZCBldmVuIGNvbmZ1c2Ugc29tZSBkZXZlbG9wZXJzLg0KDQoJCQkJLS0gTWlrZQ0KDQo= From nobody Sun Oct 5 16:00:07 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 818D31A00F5; Sun, 5 Oct 2014 16:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 scHmH21SiBvr; Sun, 5 Oct 2014 16:00:04 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED0EF1A00ED; Sun, 5 Oct 2014 16:00:03 -0700 (PDT) Received: by mail-la0-f48.google.com with SMTP id gi9so3489618lab.35 for ; Sun, 05 Oct 2014 16:00:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=exfApcFpapsMTo8Y31lCPMK+e482F/psWHbUBRWZOBw=; b=yFfyEk+wBhqcL8CTqAoypyt/L8o10UueM+ust1eRkv9RBz/aYwzLn38vvuOgscEf6M YPDSEh47AmN+HtI9YjVxfITMP8hbKJHAJhksaxvU6zkmdMPpl+f1NNg1Oqoy5uXd660p cVKfwov6SncQwup283ihAghiUGEdNyv9pSFkGqqH/yHGKmoTExggAbGg8gHkUW/JUagG 9QGg5oFCVxMUWlcpQmbS/5tjaZIs7q9vGq4N4T34wq+Op6+dnpdMDWmRPVHHMKz0oO1x Bx0Zg0PYUgOz3B3Jf3Nro209u5hd4p47+/1TiMxKwvKBlzDHr/b8Yb1YmsUIEOYozzn/ D24w== MIME-Version: 1.0 X-Received: by 10.112.118.227 with SMTP id kp3mr19609900lbb.75.1412550002093; Sun, 05 Oct 2014 16:00:02 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.1.193 with HTTP; Sun, 5 Oct 2014 16:00:02 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439BAE9ADF@TK5EX14MBXC286.redmond.corp.microsoft.com> References: <20141001155414.3543.53089.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739439BAE9ADF@TK5EX14MBXC286.redmond.corp.microsoft.com> Date: Sun, 5 Oct 2014 19:00:02 -0400 X-Google-Sender-Auth: prY08ojZPYTVmJ9KZ2RClELBRvU Message-ID: From: Barry Leiba To: Mike Jones Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/RU7guSKlzimviHamFJ-eEK-hkFE Cc: "oauth-chairs@tools.ietf.org" , "oauth@ietf.org" , The IESG , "draft-ietf-oauth-json-web-token@tools.ietf.org" Subject: Re: [OAUTH-WG] Barry Leiba's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2014 23:00:05 -0000 > At Stephen Farrell's request, I'm responding with "> " line prefixes > on previous thread content. Yeh, Outlook (and certain other clients, such as Lotus Notes) are particularly bad at cooperating with the Internet-style quoting, and it can get to be quite a mess as people with all different kinds of mail clients start intermixing responses. Waddyagonnado. Maybe we oughta make a standard...... > We can update the text to clarify that MIME type comparisons > are an exception to the "code unit by code unit" comparison rule. > The drafts will also be scrutinized for other possible occurrences > of exceptions to the default string comparison instructions. Finally, > we can add language to 7.1 about "unless otherwise noted for a > particular kind of string" so that it's clear that there are exceptions > to the rule. That should work, and I'll have a look at the final result. I'll note that Ted Lemon (I think it was he) suggested that the documents might leave the comparison text as is, and instead modify each place where case-insensitive comparisons are needed by requiring that those items be normalized to lower case (upper case would, of course, work as well). You might consider that, because it gets you out of the business of trying to specify how to do the comparisons. At some point, you might have other normalization and canonicalization issues, though I don't see any right now. If, for example, you might ever have a field value containing something like "k=FChl", you'll have to deal with two ways to represent the "=FC" (as a single character, and as two (a "u" plus a combining umlaut)). It might be that that's never going to be an issue for the JW* stuff. But if it ever is (if there are ever such strings that might be typed in by users), it could be a problem. Barry From nobody Mon Oct 6 00:54:27 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFF711A1B46; Mon, 6 Oct 2014 00:54:25 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ODLbiVWFiq8; Mon, 6 Oct 2014 00:54:23 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0102.outbound.protection.outlook.com [207.46.100.102]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FC3C1A1B45; Mon, 6 Oct 2014 00:54:23 -0700 (PDT) Received: from BN3PR0301CA0083.namprd03.prod.outlook.com (25.160.152.179) by BN3PR0301MB1202.namprd03.prod.outlook.com (25.161.207.155) with Microsoft SMTP Server (TLS) id 15.0.1044.10; Mon, 6 Oct 2014 07:54:22 +0000 Received: from BY2FFO11FD007.protection.gbl (2a01:111:f400:7c0c::129) by BN3PR0301CA0083.outlook.office365.com (2a01:111:e400:401e::51) with Microsoft SMTP Server (TLS) id 15.0.1044.10 via Frontend Transport; Mon, 6 Oct 2014 07:54:21 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD007.mail.protection.outlook.com (10.1.14.128) with Microsoft SMTP Server (TLS) id 15.0.1039.16 via Frontend Transport; Mon, 6 Oct 2014 07:54:20 +0000 Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.93]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.03.0210.003; Mon, 6 Oct 2014 07:54:14 +0000 From: Mike Jones To: Stephen Farrell , The IESG Thread-Topic: Stephen Farrell's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) Thread-Index: AQHP3jjwXNtLGJwBq0euviBV//YhCJwiQ55Q Date: Mon, 6 Oct 2014 07:54:14 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439BAF0C2A@TK5EX14MBXC286.redmond.corp.microsoft.com> References: <20141002120308.9386.79961.idtracker@ietfa.amsl.com> In-Reply-To: <20141002120308.9386.79961.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(189002)(51704005)(52044002)(377454003)(43784003)(13464003)(199003)(77096002)(81156004)(76482002)(47776003)(87936001)(23676002)(66066001)(31966008)(21056001)(50466002)(97736003)(95666004)(86612001)(4396001)(85306004)(106116001)(106466001)(80022003)(85852003)(44976005)(85806002)(68736004)(19580395003)(107046002)(92726001)(84676001)(69596002)(6806004)(10300001)(76176999)(230783001)(19580405001)(2656002)(20776003)(33656002)(99396003)(55846006)(86362001)(92566001)(120916001)(64706001)(15202345003)(50986999)(15975445006)(46102003)(54356999)(104016003)(26826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1202; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1202; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 03569407CC Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/vQ7L_euUe33tKBJEBDRyc7DWqzo Cc: "oauth-chairs@tools.ietf.org" , "draft-ietf-oauth-json-web-token@tools.ietf.org" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 07:54:26 -0000 VGhhbmtzIGZvciB5b3VyIHJldmlldywgU3RlcGhlbi4gIEkndmUgYWRkZWQgdGhlIHdvcmtpbmcg Z3JvdXAgdG8gdGhlIHRocmVhZCBzbyB0aGV5J3JlIGF3YXJlIG9mIHlvdXIgY29tbWVudHMuDQoN Cj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogU3RlcGhlbiBGYXJyZWxsIFtt YWlsdG86c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZV0NCj4gU2VudDogVGh1cnNkYXksIE9jdG9i ZXIgMDIsIDIwMTQgNTowMyBBTQ0KPiBUbzogVGhlIElFU0cNCj4gQ2M6IG9hdXRoLWNoYWlyc0B0 b29scy5pZXRmLm9yZzsgZHJhZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi0NCj4gdG9rZW5AdG9vbHMu aWV0Zi5vcmcNCj4gU3ViamVjdDogU3RlcGhlbiBGYXJyZWxsJ3MgRGlzY3VzcyBvbiBkcmFmdC1p ZXRmLW9hdXRoLWpzb24td2ViLXRva2VuLTI3OiAod2l0aA0KPiBESVNDVVNTIGFuZCBDT01NRU5U KQ0KPiANCj4gU3RlcGhlbiBGYXJyZWxsIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90 IHBvc2l0aW9uIGZvcg0KPiBkcmFmdC1pZXRmLW9hdXRoLWpzb24td2ViLXRva2VuLTI3OiBEaXNj dXNzDQo+IA0KPiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUg aW50YWN0IGFuZCByZXBseSB0byBhbGwgZW1haWwNCj4gYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRo ZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMgaW50cm9kdWN0b3J5DQo+ IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+IA0KPiANCj4gUGxlYXNlIHJlZmVyIHRvIGh0dHA6Ly93 d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQo+IGZvciBt b3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMu DQo+IA0KPiANCj4gVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlv bnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KPiBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWlldGYtb2F1dGgtanNvbi13ZWItdG9rZW4vDQo+IA0KPiANCj4gDQo+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCj4gRElTQ1VTUzoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gDQo+ICgxKSA0LjEuMSBh bmQgZWxzZXdoZXJlIHlvdSBzYXkgY2FzZS1zZW5zaXRpdmU6IHRoZSBzYW1lIHRoaW5nIEkgcmFp c2VkIHdydCBETlMNCj4gbmFtZXMgZm9yIGFub3RoZXIgSk9TRSBzcGVjIC0gZG8geW91IG5lZWQg dG8gc2F5IHRob3NlIFNIT1VMRCBiZQ0KPiBbdXBwZXJ8bG93ZXJdY2FzZWQgd2hlbiB1c2VkIGlu IHRoZXNlPw0KDQpJIGJlbGlldmUgdGhhdCBzb21ld2hlcmUgd2Ugc2hvdWxkIHNheSB0aGF0IGlm IGNhc2UtaW5zZW5zaXRpdmUgdmFsdWVzLCBzdWNoIGFzIEROUyBuYW1lcywgYXJlIHVzZWQgd2hl biBjb25zdHJ1Y3RpbmcgImtpZCIgdmFsdWVzLCB0aGF0IHRoZSBhcHBsaWNhdGlvbiBkb2luZyBz byBuZWVkcyB0byBkZWZpbmUgYSBjb252ZW50aW9uIG9uIHRoZSBjYW5vbmljYWwgY2FzZSB0byB1 c2UgZm9yIHRoZSBjYXNlLWluc2Vuc2l0aXZlIHBvcnRpb25zLCBzdWNoIGFzIGxvd2VyY2FzaW5n IHRoZW0uDQoNCj4gKDIpIFNlY3Rpb24gODogV2h5IGlzICJub25lIiBNVEk/IFRoYXQgc2VlbXMg Ym90aCBicm9rZW4gYW5kIGdvaW5nIGluIHRoZQ0KPiBvcHBvc3RpdGUgZGlyZWN0aW9uIGZyb20g b3RoZXIgV0dzIGFuZCBzbyBzaG91bGQgYmUgZXhwbGljaXRseSBqdXNpZmllZCBJIHRoaW5rLiAo SWYNCj4gYSBnb29kIGVub3VnaCBqdXN0aWZpY2F0aW9uIGV4aXN0cyB0aGF0IGlzLikNCg0KSXQg aXMgTVRJIGJlY2F1c2UgdGhlcmUgYXJlIHNldmVyYWwgZXhpc3RpbmcgYXBwbGljYXRpb25zIG9m IEpXVHMgaW4gd2hpY2ggYm90aCB1bnNpZ25lZCBhbmQgc2lnbmVkIHJlcHJlc2VudGF0aW9ucyBv ZiB0aGUgSldUcyBhcmUgcmVxdWlyZW1lbnRzLiAgVGhlc2UgaW5jbHVkZSBkcmFmdC1pZXRmLW9h dXRoLXRva2VuLWV4Y2hhbmdlLCBkcmFmdC1odW50LW9hdXRoLXYyLXVzZXItYTRjLCBhbmQgT3Bl bklEIENvbm5lY3QuICBUaGlzIGlzIGEgcHJldHR5IGNvbW1vbiBwYXR0ZXJuIHdoZXJlIHlvdSBz aWduIHNvbWV0aGluZyBpZiB0aGUgcmVjaXBpZW50IGNhcmVzIHdobyBtYWRlIHRoZSBzdGF0ZW1l bnRzIGFuZCB3aGVyZSB5b3UgZG9uJ3QgaGF2ZSB0byBzaWduIGl0IGVpdGhlciBpZiB0aGUgcmVj aXBpZW50IGRvZXNuJ3QgY2FyZSB3aG8gbWFkZSB0aGUgc3RhdGVtZW50cyBvciBpZiBpdCBjYW4g dGVsbCBmcm9tIGFub3RoZXIgc2VjdXJlZCBhc3BlY3Qgb2YgdGhlIGFwcGxpY2F0aW9uIHByb3Rv Y29sICh0eXBpY2FsbHkgdGhyb3VnaCB0aGUgdXNlIG9mIFRMUykgd2hvIG1hZGUgdGhlIHN0YXRl bWVudHMuICBJbiB0aGUgVExTIGNhc2UsIHRoZSBzZXJ2ZXIgYXV0aGVudGljYXRpb24gc3RlcCBt YWtlcyBhIHNpZ25hdHVyZSBzdGVwIHVubmVjZXNzYXJ5LCBzbyBhbiBVbnNlY3VyZWQgSldUIGlz IGZpbmUgdGhlcmUuDQoNCj4gKDMpIFNlY3Rpb24gMTI6IGFub3RoZXIgd2F5IHRvIGhhbmRsZSBw cml2YWN5IGlzIHRvIG5vdCBpbmNsdWRlIHNlbnNpdGl2ZSBkYXRhIC0gSQ0KPiB0aGluayB5b3Ug b3VnaHQgbWVudGlvbiB0aGF0IGFzIGEgYml0IG9mIHRob3VnaHQgYWxvbmcgdGhvc2UgbGluZXMg Y2FuIGJlIG11Y2gNCj4gc2ltcGxlciB0aGFuIHB1dHRpbmcgaW4gcGxhY2UgdGhlIGtleSBtYW5h Z2VtZW50IHRvIGhhbmRsZSB0aG91Z2h0bGVzc2x5DQo+IGluY2x1ZGVkIFBJSS4NCg0KV2UgY2Fu IGluY2x1ZGUgYSBkaXNjdXNzaW9uIG9mIHRoYXQgcG9pbnQsIGJ1dCBzb21ldGltZXMgdGhlIHZl cnkgcG9pbnQgb2YgYSBKV1QgaXMgdG8gc2VjdXJlbHkgZGVsaXZlciBQSUkgZnJvbSBhIHZlcmlm aWFibGUgcGFydHkgdG8gYW4gaW50ZW5kZWQgcGFydHkgd2l0aCBhcHByb3ByaWF0ZSByaWdodHMg dG8gcmVjZWl2ZSBpdC4NCg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IENPTU1FTlQ6DQo+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCj4gDQo+IA0KPiAtIGFic3RyYWN0OiAybmQgc2VudGVuY2UgaXNuJ3QgbmVlZGVkIGhl cmUsIGluIGludHJvIHdvdWxkIGJlIGZpbmUuDQoNCkkgZG9uJ3Qga25vdyAtIEkgdGhpbmsgaXQn cyBhIGJpZyBkZWFsIHRoYXQgdGhlIGNsYWltcyBjYW4gYmUgZGlnaXRhbGx5IHNpZ25lZCBvciBN QUNlZCBhbmQvb3IgZW5jcnlwdGVkLiAgVGhhdCdzIHRoZSByZWFzb24gd2UgaGF2ZSBKV1RzLCBy YXRoZXIgdGhhbiBqdXN0IEpTT04uDQoNCj4gLSA0LjEuNzogbWF5YmUgd29ydGggYWRkaW5nIHRo YXQganRpK2lzcyBiZWluZyB1bmlxdWUgZW5vdWdoIGlzIG5vdCBzdWZmaWNpZW50IGFuZA0KPiBq dGkgYWxvbmUgaGFzIHRvIG1lZXQgdGhhdCBuZWVkLiBJbg0KPiBYLjUwOSB0aGUgaXNzdWVyL3Nl cmlhbCBoYXMgdGhlIGVxdWl2YWxlbnQgcHJvcGVydHkgc28gc29tZW9uZSBtaWdodCBhc3N1bWUN Cj4gc2VxdWVudGlhbCBqdGkgdmFsdWVzIHN0YXJ0aW5nIGF0IDAgYXJlIG9rLg0KDQpNYWtlcyBz ZW5zZSB0byBhZGQgYSB3YXJuaW5nIG9mIHNvbWUga2luZCBhbG9uZyB0aGVzZSBsaW5lcy4gIEkg dGhpbmsgSSBrbm93IHRoZSByZWFzb25zIHlvdSBzYXkgdGhhdCwgYnV0IGNhbiB5b3UgZXhwYW5k IG9uIHRoYXQgdGhvdWdodCBhIGJpdCBiZWZvcmUgSSB0YWtlIGEgc3RhYiBvbiB3cml0aW5nIHRo aXMgdXA/ICBGb3IgaW5zdGFuY2UsIHdoaWxlIG5vcm1hbGx5IHRydWUsIEkgZG9uJ3QgdGhpbmsg eW91ciBvYnNlcnZhdGlvbiBpcyB0cnVlIGlmIGEgcmVseWluZyBwYXJ0eSB3aWxsIG9ubHkgYWNj ZXB0IHRva2VucyBmcm9tIGEgc2luZ2xlIGlzc3Vlci4NCg0KPiAtIHNlY3Rpb24gNjogeXVrDQo+ IA0KPiAtIGFnYWluIEkgdGhpbmsgdGhlIHNlY2RpciBjb21tZW50cyBhcmUgYmVpbmcgaGFuZGxl ZCBieSBLYXRobGVlbiBhbmQgdGhlDQo+IGF1dGhvcnMuDQoNCkFnYWluLCB0aGlzIGlzIHRoZXJl IGJlY2F1c2UgbXVsdGlwbGUgYXBwbGljYXRpb25zIGFza2VkIGZvciB0aGUgYWJpbGl0eSB0byBy ZXByZXNlbnQgY29udGVudCB0aGF0IGlzIG9wdGlvbmFsbHkgc2lnbmVkLCBzb21ldGltZXMgc2Vj dXJpbmcgaXQgYW5vdGhlciB3YXksIHN1Y2ggYXMgd2l0aCBUTFMuICBKV1RzIGFyZSB1c2VkIHNw ZWNpZmljIGFwcGxpY2F0aW9uIHByb3RvY29sIGNvbnRleHRzIC0gbm90IGluIGlzb2xhdGlvbi4N Cg0KCQkJCVRoYW5rcyBhZ2FpbiwNCgkJCQktLSBNaWtlDQoNCg== From nobody Mon Oct 6 00:55:29 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A0461A1B69; Mon, 6 Oct 2014 00:55:00 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZaIkb0NL3t-d; Mon, 6 Oct 2014 00:54:56 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0144.outbound.protection.outlook.com [207.46.100.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 000361A1B6F; Mon, 6 Oct 2014 00:54:52 -0700 (PDT) Received: from CH1PR03CA003.namprd03.prod.outlook.com (10.255.156.148) by BY1PR0301MB1207.namprd03.prod.outlook.com (25.161.203.156) with Microsoft SMTP Server (TLS) id 15.0.1044.10; Mon, 6 Oct 2014 07:54:51 +0000 Received: from BN1AFFO11FD043.protection.gbl (10.255.156.132) by CH1PR03CA003.outlook.office365.com (10.255.156.148) with Microsoft SMTP Server (TLS) id 15.0.1044.10 via Frontend Transport; Mon, 6 Oct 2014 07:54:51 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD043.mail.protection.outlook.com (10.58.52.190) with Microsoft SMTP Server (TLS) id 15.0.1039.16 via Frontend Transport; Mon, 6 Oct 2014 07:54:50 +0000 Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.93]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.03.0210.003; Mon, 6 Oct 2014 07:54:22 +0000 From: Mike Jones To: Tom Taylor , "ops-dir@ietf.org" , "draft-ietf-oauth-saml2-bearer.all@tools.ietf.org" Thread-Topic: Last Call review of draft-ietf-oauth-saml2-bearer-21 Thread-Index: AQHP25Ysy2PPss3gq0KvSQVbAfg7Ypwii1ww Date: Mon, 6 Oct 2014 07:54:21 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439BAF0C5E@TK5EX14MBXC286.redmond.corp.microsoft.com> References: <5428D303.80804@gmail.com> In-Reply-To: <5428D303.80804@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(13464003)(199003)(43784003)(51704005)(189002)(377454003)(87936001)(85852003)(46102003)(85806002)(106116001)(76176999)(2656002)(33656002)(106466001)(50986999)(86362001)(81156004)(95666004)(92726001)(26826002)(19580395003)(80022003)(55846006)(46406003)(54356999)(23726002)(4396001)(104016003)(92566001)(47776003)(68736004)(69596002)(20776003)(97756001)(85306004)(230783001)(10300001)(2201001)(86612001)(64706001)(31966008)(77096002)(21056001)(120916001)(107046002)(50466002)(6806004)(99396003)(97736003)(19580405001)(44976005)(66066001)(76482002)(84676001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0301MB1207; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BY1PR0301MB1207; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 03569407CC Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/H_y43LJLAMyI4Br1un94TCYN6gA Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Last Call review of draft-ietf-oauth-saml2-bearer-21 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 07:55:00 -0000 Thanks for your review, Tom. I've added the working group to this thread s= o they're aware of your comment. > -----Original Message----- > From: Tom Taylor [mailto:tom.taylor.stds@gmail.com] > Sent: Sunday, September 28, 2014 8:33 PM > To: ops-dir@ietf.org; draft-ietf-oauth-saml2-bearer.all@tools.ietf.org > Subject: Last Call review of draft-ietf-oauth-saml2-bearer-21 >=20 > I have reviewed this document as part of the Operational directorate's on= going > effort to review all IETF documents being processed by the IESG. These > comments were written primarily for the benefit of the operational area > directors. Document editors and WG chairs should treat these comments ju= st > like any other last call comments. >=20 > Tom Taylor >=20 > Summary: Process issue: IDnits complains of a normative reference to > Informational document RFC 6755. This was NOT noted in the Last Call > announcement (but was noted in the Shepherd writeup). No operational issu= e > identified beyond what is already covered by the Interoperability Conside= rations > section. 6755 defines a registry that this specification uses. > Editorial Nits: >=20 > S2.2: The paragraph before the actual example uses terminology inconsiste= nt > with RFC 6749: >=20 > s/authorization code grant/authorization grant/ Actually, RFC 6749 uses both terms. Authorization grant is the generic ter= m. Authorization Code Grant (defined in Section 4.1 of 6749) is a specific= kind of authorization grant. Thanks again, -- Mike From nobody Mon Oct 6 00:55:31 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6DD1A1B69; Mon, 6 Oct 2014 00:55:00 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9_oCQeAyNrIy; Mon, 6 Oct 2014 00:54:57 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0122.outbound.protection.outlook.com [207.46.100.122]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 128A41A1B70; Mon, 6 Oct 2014 00:54:53 -0700 (PDT) Received: from BN3PR0301CA0011.namprd03.prod.outlook.com (25.160.180.149) by CY1PR0301MB1212.namprd03.prod.outlook.com (25.161.212.146) with Microsoft SMTP Server (TLS) id 15.0.1044.10; Mon, 6 Oct 2014 07:54:51 +0000 Received: from BN1AFFO11FD041.protection.gbl (2a01:111:f400:7c10::199) by BN3PR0301CA0011.outlook.office365.com (2a01:111:e400:4000::21) with Microsoft SMTP Server (TLS) id 15.0.1044.10 via Frontend Transport; Mon, 6 Oct 2014 07:54:51 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD041.mail.protection.outlook.com (10.58.52.252) with Microsoft SMTP Server (TLS) id 15.0.1039.16 via Frontend Transport; Mon, 6 Oct 2014 07:54:50 +0000 Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.93]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.03.0210.003; Mon, 6 Oct 2014 07:54:17 +0000 From: Mike Jones To: Ted Lemon , The IESG Thread-Topic: Ted Lemon's No Objection on draft-ietf-oauth-json-web-token-27: (with COMMENT) Thread-Index: AQHP3kj4EDDmiynllUmOKg/KYNPHJpwiUwtQ Date: Mon, 6 Oct 2014 07:54:17 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439BAF0C41@TK5EX14MBXC286.redmond.corp.microsoft.com> References: <20141002135827.27947.4504.idtracker@ietfa.amsl.com> In-Reply-To: <20141002135827.27947.4504.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(377454003)(51704005)(13464003)(199003)(43784003)(189002)(52044002)(69596002)(68736004)(54356999)(50986999)(87936001)(15202345003)(21056001)(120916001)(2656002)(84676001)(76482002)(230783001)(55846006)(99396003)(85806002)(33656002)(19580405001)(44976005)(10300001)(6806004)(15975445006)(85852003)(19580395003)(26826002)(4396001)(66066001)(80022003)(46102003)(23676002)(86612001)(107046002)(81156004)(106116001)(106466001)(95666004)(85306004)(92566001)(50466002)(92726001)(76176999)(97736003)(20776003)(47776003)(104016003)(77096002)(86362001)(64706001)(31966008); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB1212; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB1212; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 03569407CC Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/cKI6zns60Qc7hAXvPaB5BjafaVc Cc: "oauth-chairs@tools.ietf.org" , "draft-ietf-oauth-json-web-token@tools.ietf.org" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Ted Lemon's No Objection on draft-ietf-oauth-json-web-token-27: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 07:55:00 -0000 VGhhbmtzIGZvciB5b3VyIHJldmlldywgVGVkLiAgSSdtIGFkZGluZyB0aGUgd29ya2luZyBncm91 cCB0byB0aGUgdGhyZWFkIHNvIHRoZXkncmUgYXdhcmUgb2YgeW91ciBjb21tZW50cy4NCg0KPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBUZWQgTGVtb24gW21haWx0bzp0ZWQu bGVtb25Abm9taW51bS5jb21dDQo+IFNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDAyLCAyMDE0IDY6 NTggQU0NCj4gVG86IFRoZSBJRVNHDQo+IENjOiBvYXV0aC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc7 IGRyYWZ0LWlldGYtb2F1dGgtanNvbi13ZWItDQo+IHRva2VuQHRvb2xzLmlldGYub3JnDQo+IFN1 YmplY3Q6IFRlZCBMZW1vbidzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRmLW9hdXRoLWpzb24t d2ViLXRva2VuLTI3Og0KPiAod2l0aCBDT01NRU5UKQ0KPiANCj4gVGVkIExlbW9uIGhhcyBlbnRl cmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPiBkcmFmdC1pZXRmLW9hdXRo LWpzb24td2ViLXRva2VuLTI3OiBObyBPYmplY3Rpb24NCj4gDQo+IFdoZW4gcmVzcG9uZGluZywg cGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbCBlbWFp bA0KPiBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJl ZSB0byBjdXQgdGhpcyBpbnRyb2R1Y3RvcnkNCj4gcGFyYWdyYXBoLCBob3dldmVyLikNCj4gDQo+ IA0KPiBQbGVhc2UgcmVmZXIgdG8gaHR0cDovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9k aXNjdXNzLWNyaXRlcmlhLmh0bWwNCj4gZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBE SVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCj4gDQo+IA0KPiBUaGUgZG9jdW1lbnQsIGFs b25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQo+IGh0 dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi10 b2tlbi8NCj4gDQo+IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBDT01NRU5UOg0KPiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQo+IA0KPiAgICBUaGUgc3VnZ2VzdGVkIHByb251bmNpYXRpb24gb2YgSldUIGlzIHRo ZSBzYW1lIGFzIHRoZSBFbmdsaXNoIHdvcmQNCj4gICAgImpvdCIuDQo+IA0KPiBJIHdvdWxkIGhh dmUgZ29uZSB3aXRoICJqdXRlIi4gICA6KSAgIEFsc28sIHRoaXMgZG9lc24ndCBiZWxvbmcgaW4g dGhlDQo+IGFic3RyYWN0LiBJdCBhcHBlYXJzIHRvIGhhdmUgY3JlcHQgaW4gYXMgYSByZXN1bHQg b2YgY3V0dGluZyBhbmQgcGFzdGluZyB0aGUNCj4gaW50cm9kdWN0aW9uIGludG8gdGhlIGFic3Ry YWN0Lg0KDQpZb3UncmUgbm90IHRoZSBmaXJzdCBwZXJzb24gd2l0aCBrbm93bGVkZ2Ugb2YgV2Vs c2ggdG8gbWFrZSB0aGUgc2FtZSBjb21tZW50LiA6LSkgIChBbmQgdGhpcyBpcyBhIEpvbmVzIHJl c3BvbmRpbmcuLi4pDQoNCkknbGwgcGxhbiB0byByZW1vdmUgdGhlIHNlbnRlbmNlIGZyb20gdGhl IGFic3RyYWN0Lg0KDQo+IElzIHRoZXJlIGFueSByZWFzb24gbm90IHRvIGp1c3QgcmVxdWlyZSB0 aGlzOg0KPiANCj4gICAgV2hpbGUgc3ludGFjdGljYWxseSB0aGUgc2lnbmluZyBhbmQgZW5jcnlw dGlvbiBvcGVyYXRpb25zIGZvciBOZXN0ZWQNCj4gICAgSldUcyBtYXkgYmUgYXBwbGllZCBpbiBh bnkgb3JkZXIsIG5vcm1hbGx5IHNlbmRlcnMgc2hvdWxkIHNpZ24gdGhlDQo+ICAgIG1lc3NhZ2Ug YW5kIHRoZW4gZW5jcnlwdCB0aGUgcmVzdWx0ICh0aHVzIGVuY3J5cHRpbmcgdGhlIHNpZ25hdHVy ZSkuDQo+ICAgIFRoaXMgcHJldmVudHMgYXR0YWNrcyBpbiB3aGljaCB0aGUgc2lnbmF0dXJlIGlz IHN0cmlwcGVkLCBsZWF2aW5nDQo+ICAgIGp1c3QgYW4gZW5jcnlwdGVkIG1lc3NhZ2UsIGFzIHdl bGwgYXMgcHJvdmlkaW5nIHByaXZhY3kgZm9yIHRoZQ0KPiAgICBzaWduZXIuICBGdXJ0aGVybW9y ZSwgc2lnbmF0dXJlcyBvdmVyIGVuY3J5cHRlZCB0ZXh0IGFyZSBub3QNCj4gICAgY29uc2lkZXJl ZCB2YWxpZCBpbiBtYW55IGp1cmlzZGljdGlvbnMuDQo+IA0KPiBXaGVuIGRvZXMgaXQgbWFrZSBz ZW5zZSBub3QgdG8gZG8gaXQgdGhpcyB3YXk/DQoNClNvbWV0aW1lcyBhdXRoZW50aWNhdGVkIGVu Y3J5cHRpb24gYWxvbmUgaXMgZ29vZCBlbm91Z2ggd2l0aG91dCByZXF1aXJpbmcgYSBzaWduYXR1 cmUuICBEaWZmZXJlbnQgYXBwbGljYXRpb25zIHdpbGwgaGF2ZSBkaWZmZXJlbnQgcmVxdWlyZW1l bnRzLiAgU28gd2hpbGUgdGhpcyBzZWN0aW9uIGRpc2N1c3Npb24gdGhlIGFwcGxpY2FibGUgY29u c2lkZXJhdGlvbnMsIHRoZSB3b3JraW5nIGdyb3VwIGZlbHQgdGhhdCBpdCB3YXMgZ29pbmcgdG9v IGZhciB0byBtYWtlIHRoaXMgcHJlc2NyaXB0aXZlLg0KDQoJCQkJVGhhbmtzIGFnYWluLA0KCQkJ CS0tIE1pa2UNCg0K From nobody Mon Oct 6 00:55:46 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 831521A1B68; Mon, 6 Oct 2014 00:55:15 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ryzPh3OYmcxo; Mon, 6 Oct 2014 00:55:11 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0784.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:784]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2A5C1A1B61; Mon, 6 Oct 2014 00:55:10 -0700 (PDT) Received: from BY1PR0301MB1208.namprd03.prod.outlook.com (25.161.203.16) by BY1PR0301MB1205.namprd03.prod.outlook.com (25.161.203.154) with Microsoft SMTP Server (TLS) id 15.0.1044.10; Mon, 6 Oct 2014 07:54:49 +0000 Received: from BY2PR03CA057.namprd03.prod.outlook.com (10.141.249.30) by BY1PR0301MB1208.namprd03.prod.outlook.com (25.161.203.16) with Microsoft SMTP Server (TLS) id 15.0.1044.10; Mon, 6 Oct 2014 07:54:47 +0000 Received: from BY2FFO11FD022.protection.gbl (2a01:111:f400:7c0c::104) by BY2PR03CA057.outlook.office365.com (2a01:111:e400:2c5d::30) with Microsoft SMTP Server (TLS) id 15.0.1044.10 via Frontend Transport; Mon, 6 Oct 2014 07:54:47 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD022.mail.protection.outlook.com (10.1.15.211) with Microsoft SMTP Server (TLS) id 15.0.1039.16 via Frontend Transport; Mon, 6 Oct 2014 07:54:47 +0000 Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.93]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.03.0210.003; Mon, 6 Oct 2014 07:54:20 +0000 From: Mike Jones To: Richard Barnes , The IESG Thread-Topic: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) Thread-Index: AQHP3eyTOy20E1mLIki2fp/mr+WNhZwiXvCA Date: Mon, 6 Oct 2014 07:54:19 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439BAF0C4E@TK5EX14MBXC286.redmond.corp.microsoft.com> References: <20141002025706.19368.2507.idtracker@ietfa.amsl.com> In-Reply-To: <20141002025706.19368.2507.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(13464003)(189002)(199003)(51704005)(377454003)(52044002)(43784003)(6806004)(107046002)(87936001)(21056001)(92566001)(26826002)(20776003)(64706001)(31966008)(86362001)(97756001)(33656002)(106466001)(92726001)(85806002)(2656002)(97736003)(104016003)(81156004)(66066001)(54356999)(44976005)(86612001)(76176999)(50986999)(69596002)(85852003)(84676001)(68736004)(106116001)(230783001)(47776003)(77096002)(99396003)(4396001)(85306004)(15975445006)(23726002)(46406003)(55846006)(19580405001)(80022003)(15202345003)(19580395003)(46102003)(10300001)(95666004)(76482002)(50466002)(120916001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0301MB1208; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:;UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BY1PR0301MB1208; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 03569407CC Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BY1PR0301MB1205; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/7oICJCbV0OMuJe4ASo3sJWM-CbY Cc: "oauth-chairs@tools.ietf.org" , "oauth@ietf.org" , "draft-ietf-oauth-json-web-token@tools.ietf.org" Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 07:55:15 -0000 Thanks for your review, Richard. My responses are inline below... > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Richard Barnes > Sent: Wednesday, October 01, 2014 7:57 PM > To: The IESG > Cc: oauth-chairs@tools.ietf.org; oauth@ietf.org; draft-ietf-oauth-json-we= b- > token@tools.ietf.org > Subject: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-json-web- > token-27: (with DISCUSS and COMMENT) >=20 > Richard Barnes has entered the following ballot position for > draft-ietf-oauth-json-web-token-27: Discuss >=20 > When responding, please keep the subject line intact and reply to all ema= il > addresses included in the To and CC lines. (Feel free to cut this introdu= ctory > paragraph, however.) >=20 >=20 > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > Section 7. > In order to prevent confusion between secured and Unsecured JWTs, the > validation steps here need to call for the application to specify which i= s required. Per my response on your JWS comments, this is already handed in a more gene= ral way in the JWS validation steps. Specifically, the last paragraph of S= ection 5.2 is: "Finally, note that it is an application decision which algorithms are acce= ptable in a given context. Even if a JWS can be successfully validated, unl= ess the algorithm(s) used in the JWS are acceptable to the application, it = SHOULD reject the JWS." I would therefore request that you likewise withdraw this DISCUSS on that b= asis. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Abstract. > Welsh is the only language I know of in which "w" is a vowel. According = to > Wikipedia, then, "JWT" should pronounced "joot" :) You're not the only person with knowledge of Welsh to have made this commen= t. And this is a Jones responding to you... ;-) > Section 2. > It seems like "Unsecured JWT" should simply be defined as "A JWT carried = in an > Unsigned JWS." It's been useful in other specifications that are applications of JWTs to h= ave a name for this kind of JWT, since it occurs frequently. > Section 4.1. > I'm a little surprised not to see a "jwk" claim, which would basically en= able JWTs > to sub in for certificates for many use cases. Did the WG consider this > possibility? Not to my knowledge. However, I know of several applications in which JWKs= and JWK Sets are carried as claims in JWTs of various kinds - just using c= laim names that are informed by the context of the particular application. = For instance, draft-ietf-oauth-dyn-reg uses a "jwks_uri" claim to pass a J= WK Set by reference and a "jwks" claim to pass a JWK Set by value. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth Thanks again, -- Mike From nobody Mon Oct 6 00:55:52 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 856B91A1B75; Mon, 6 Oct 2014 00:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.388 X-Spam-Level: X-Spam-Status: No, score=-0.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] autolearn=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 CSsp5wihz_V2; Mon, 6 Oct 2014 00:55:15 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0706.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::706]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A18BB1A1B60; Mon, 6 Oct 2014 00:55:14 -0700 (PDT) Received: from BN3PR0301CA0049.namprd03.prod.outlook.com (25.160.152.145) by CY1PR0301MB1210.namprd03.prod.outlook.com (25.161.212.144) with Microsoft SMTP Server (TLS) id 15.0.1044.10; Mon, 6 Oct 2014 07:55:00 +0000 Received: from BN1AFFO11FD032.protection.gbl (2a01:111:f400:7c10::106) by BN3PR0301CA0049.outlook.office365.com (2a01:111:e400:401e::17) with Microsoft SMTP Server (TLS) id 15.0.1044.10 via Frontend Transport; Mon, 6 Oct 2014 07:55:00 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD032.mail.protection.outlook.com (10.58.52.186) with Microsoft SMTP Server (TLS) id 15.0.1039.16 via Frontend Transport; Mon, 6 Oct 2014 07:54:59 +0000 Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.93]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.03.0210.003; Mon, 6 Oct 2014 07:54:23 +0000 From: Mike Jones To: Meral Shirazipour , "draft-ietf-oauth-saml2-bearer.all@tools.ietf.org" , "gen-art@ietf.org" Thread-Topic: Gen-ART Last Call review of draft-ietf-oauth-saml2-bearer-21 Thread-Index: Ac/buIZkeRYqVO9qSXuXGlBtXSseFgFajrKQ Date: Mon, 6 Oct 2014 07:54:22 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439BAF0C63@TK5EX14MBXC286.redmond.corp.microsoft.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(51704005)(377424004)(43784003)(189002)(377454003)(199003)(106466001)(46406003)(2201001)(92726001)(33656002)(92566001)(50466002)(95666004)(97736003)(47776003)(80022003)(20776003)(64706001)(46102003)(87936001)(86612001)(66066001)(26826002)(81156004)(107046002)(21056001)(86362001)(77096002)(55846006)(2656002)(76482002)(85306004)(6806004)(120916001)(4396001)(15975445006)(69596002)(84676001)(230783001)(104016003)(15202345003)(68736004)(19580405001)(97756001)(31966008)(23726002)(99396003)(10300001)(19580395003)(44976005)(85852003)(50986999)(76176999)(54356999)(85806002)(15974865002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB1210; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB1210; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 03569407CC Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/pKeaLLgbEOzHlY11UD-arpxrVvo Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Gen-ART Last Call review of draft-ietf-oauth-saml2-bearer-21 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 07:55:16 -0000 Thanks for your review, Meral. I've added the working group to this thread= so that they're aware of your comments. > From: Meral Shirazipour [mailto:meral.shirazipour@ericsson.com]=20 > Sent: Monday, September 29, 2014 12:40 AM > To: draft-ietf-oauth-saml2-bearer.all@tools.ietf.org; gen-art@ietf.org > Subject: Gen-ART Last Call review of draft-ietf-oauth-saml2-bearer-21 >=20 > I am the assigned Gen-ART reviewer for this draft. For background on Gen-= ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/Ge= nArtfaq.=20 >=20 > Please resolve these comments along with any other Last Call comments you= may receive. >=20 > Document: draft-ietf-oauth-saml2-bearer-21 > Reviewer: Meral Shirazipour > Review Date: 2014-09-29 > IETF LC End Date: 2014-09-29 > IESG Telechat date: NA >=20 >=20 > Summary: > This draft is ready to be published as Standards Track RFC . >=20 >=20 > Nits/editorial comments: > Nits: > -Abstract, please consider smelling out Security Assertion Markup Languag= e Agreed > -[Page 4] Section 2.1 ",use an access ..", it would be clearer to name th= e entity (AS?) who would have to "use and access token...". Agreed. I propose we say that the client does this. > -[Page 5] Section 2.2 ", use the following parameter", same comment as ab= ove. Agreed. I propose we say that the client does this. > Best Regards, > Meral > --- > Meral Shirazipour > Ericsson > Research > www.ericsson.com Thanks again, -- Mike From nobody Mon Oct 6 00:56:00 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 468141A1B81; Mon, 6 Oct 2014 00:55:24 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nD6I3F_PUvLu; Mon, 6 Oct 2014 00:55:22 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0732.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:732]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A59121A1B7E; Mon, 6 Oct 2014 00:55:21 -0700 (PDT) Received: from CO2PR03CA0034.namprd03.prod.outlook.com (10.141.194.161) by BN3PR0301MB1204.namprd03.prod.outlook.com (25.161.207.16) with Microsoft SMTP Server (TLS) id 15.0.1044.10; Mon, 6 Oct 2014 07:54:57 +0000 Received: from BN1AFFO11FD054.protection.gbl (2a01:111:f400:7c10::114) by CO2PR03CA0034.outlook.office365.com (2a01:111:e400:1414::33) with Microsoft SMTP Server (TLS) id 15.0.1044.10 via Frontend Transport; Mon, 6 Oct 2014 07:54:57 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD054.mail.protection.outlook.com (10.58.53.69) with Microsoft SMTP Server (TLS) id 15.0.1039.16 via Frontend Transport; Mon, 6 Oct 2014 07:54:56 +0000 Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.93]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.03.0210.003; Mon, 6 Oct 2014 07:54:24 +0000 From: Mike Jones To: Radia Perlman , "secdir@ietf.org" , The IESG , "draft-ietf-oauth-jwt-bearer.all@tools.ietf.org" Thread-Topic: Secdir Review of draft-ietf-oauth-jwt-bearer-10 Thread-Index: AQHP3D+wgXfaR8YiJ0mShlpRYjLXaJwijqng Date: Mon, 6 Oct 2014 07:54:24 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439BAF0C6A@TK5EX14MBXC286.redmond.corp.microsoft.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(51704005)(43784003)(199003)(377454003)(189002)(85806002)(2656002)(87936001)(20776003)(85852003)(33656002)(86362001)(26826002)(21056001)(23676002)(31966008)(95666004)(104016003)(55846006)(86612001)(85306004)(107046002)(66066001)(4396001)(19580405001)(69596002)(50986999)(46102003)(44976005)(68736004)(80022003)(120916001)(76482002)(99396003)(84676001)(47776003)(2501002)(92726001)(64706001)(76176999)(10300001)(6806004)(106116001)(92566001)(97736003)(50466002)(77096002)(106466001)(230783001)(54356999)(81156004)(19580395003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1204; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1204; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 03569407CC Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/gl45wf0loqhXLAjEVaGv7_Ux190 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Secdir Review of draft-ietf-oauth-jwt-bearer-10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 07:55:24 -0000 VGhhbmtzIGZvciB5b3VyIHJldmlldywgUmFkaWEuICBJJ3ZlIGFkZGVkIHRoZSB3b3JraW5nIGdy b3VwIHRvIHRoZSB0aHJlYWQgc28gdGhhdCB0aGV5J3JlIGF3YXJlIG9mIHlvdXIgY29tbWVudHMu DQoNCj4gRnJvbTogUmFkaWEgUGVybG1hbiBbbWFpbHRvOnJhZGlhcGVybG1hbkBnbWFpbC5jb21d IA0KPiBTZW50OiBNb25kYXksIFNlcHRlbWJlciAyOSwgMjAxNCA0OjQ2IFBNDQo+IFRvOiBzZWNk aXJAaWV0Zi5vcmc7IFRoZSBJRVNHOyBkcmFmdC1pZXRmLW9hdXRoLWp3dC1iZWFyZXIuYWxsQHRv b2xzLmlldGYub3JnDQo+IFN1YmplY3Q6IFNlY2RpciBSZXZpZXcgb2YgZHJhZnQtaWV0Zi1vYXV0 aC1qd3QtYmVhcmVyLTEwDQo+IA0KPiBJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBw YXJ0IG9mIHRoZSBzZWN1cml0eSBkaXJlY3RvcmF0ZSdzDQo+IG9uZ29pbmcgZWZmb3J0IHRvIHJl dmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZQ0KPiBJRVNHLiAg VGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2Yg dGhlDQo+IHNlY3VyaXR5IGFyZWEgZGlyZWN0b3JzLiAgRG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cg Y2hhaXJzIHNob3VsZCB0cmVhdA0KPiB0aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55IG90aGVy IGxhc3QgY2FsbCBjb21tZW50cy4NCj4gIA0KPiBUaGlzIGRvY3VtZW50IGlzIG9uZSBvZiBhIHNl dCBvZiBkb2N1bWVudHMgc3BlY2lmeWluZyBob3cgdG8gdXNlIEpTT04gZm9ybWF0dGVkIE9BdXRo IGJlYXJlciB0b2tlbnMgaW4gdGhlIGNvbnRleHQgb2YgSFRUUCByZXF1ZXN0cy4NCj4gIA0KPiBJ dCBzcGVjaWZpZXMgdHdvIGNvbnRleHRzIGluIHdoaWNoIHRoZXNlIEpTT04gdG9rZW5zIGNhbiBi ZSB1c2VkOiBhcyBBdXRob3JpemF0aW9uIEdyYW50cyBvciBmb3IgQ2xpZW50IEF1dGhlbnRpY2F0 aW9uLiBJdCBzcGVjaWZpZXMgdGhlIHRvLWJlLUlBTkEtcmVnaXN0ZXJlZCBwYXJhbWV0ZXJzIHVz ZWQgdG8gc3BlY2lmeSB0aGF0IHRoZSB0eXBlIG9mIHRva2VuIHByZXNlbnRlZCBpcyBhIEpTT04g dG9rZW4gKHdpdGhpbiB0aGUgSFRUUCBoZWFkZXIpLiBJdCBhbHNvIHNwZWNpZmllcyB0aGUgY2hl Y2tzIHRvIGJlIGRvbmUgdG8gdmFsaWRhdGUgdGhhdCB0aGUgSlNPTiB0b2tlbiBpcyB2YWxpZCAo dGhvdWdoIEkgd291bGQgZXhwZWN0IHRoaXMgaW5mb3JtYXRpb24gd291bGQgYWxzbyBiZSBzcGVj aWZpZWQgaW4gdGhlIEpTT04gdG9rZW4gc3BlY2lmaWNhdGlvbiBpdHNlbGYpLg0KDQpZb3UncmUg cmlnaHQgdGhhdCBzb21lIG9mIHRoZSB2YWxpZGF0aW9uIHJ1bGVzIGFyZSBpbiBkcmFmdC1pZXRm LW9hdXRoLWpzb24td2ViLXRva2VuLCB3aGljaCBkZWZpbmVzIHRoZSBiYXNpYyBKV1QgdG9rZW4g Zm9ybWF0LCBob3dldmVyIHRoaXMgc3BlY2lmaWNhdGlvbiBhZGRzIHNvbWUgYWRkaXRpb25hbCB2 YWxpZGF0aW9uIHJ1bGVzIGJlY2F1c2UgaXQgcmVxdWlyZXMgdGhhdCBzb21lIGZpZWxkcyBiZSBw cmVzZW50IHRoYXQgYXJlIG9wdGlvbmFsIGluIHRoZSBKV1Qgc3BlYywgYW5kIGl0IHNwZWNpZmll cyB0aGF0IHRoZXkgYmUgdXNlZCBpbiBhIHBhcnRpY3VsYXIgd2F5Lg0KDQo+IFRoZXJlIGFyZSBz ZWN1cml0eSBjb25zaWRlcmF0aW9ucyBhbmQgcHJpdmFjeSBjb25zaWRlcmF0aW9ucyBzZWN0aW9u cywgYnV0IHRoZXkgYXJlIHZlcnkgbGlnaHQuICBUaGF0IGlzIGJlY2F1c2UgaXQgcmVmZXJzIHRv IGRyYWZ0LWlldGYtb2F1dGgtYXNzZXJ0aW9ucy0xNywgd2hpY2ggaGFzIGEgbW9yZSBjb21wbGV0 ZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uLiAgSSBndWVzcyBpdCdzIGFwcHJvcHJp YXRlIHRvIGhhdmUgbW9yZSBkZXRhaWxlZCBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyB0aGVyZSwg c2luY2UgYWxsIHRoaXMgc3BlY2lmaWNhdGlvbiBhZGRzIGlzIHNvbWUgbGFiZWxzLiAgDQoNClll cywgdGhpcyB3YXMgdGhlIGludGVudC4gIE1vc3Qgb2YgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRp b25zIGFyZSBpbmRlcGVuZGVudCBvZiB0aGUgdG9rZW4gdHlwZS4NCg0KPiBXb3VsZCBpdCBtYWtl IHNlbnNlIHRvIG1lcmdlIHRoaXMgZG9jdW1lbnQgd2l0aCB0aGUgb3RoZXIgc3BlY3MsIHJhdGhl ciB0aGFuIGhhdmluZyB0aGlzIGJlIHNvIHJlZHVuZGFudCB3aXRoIHRoZSBvdGhlcnM/DQoNCk5v LCBiZWNhdXNlIHdoaWxlIHRoZXJlJ3Mgc2VtYW50aWMgY29tbW9uYWxpdHksIHRoZSBzeW50YXgg b2YgdGhlIFNBTUwgcHJvZmlsZSBhbmQgdGhlIEpXVCBwcm9maWxlIGFyZSBkaWZmZXJlbnQuICBN ZXJnaW5nIHRoZW0gd291bGQgbWFrZSBpdCBtdWNoIGhhcmRlciB0byByZWFkIGJlY2F1c2UgaXQg d291bGQgYmUgZnVsbCBvZiBjb25kaXRpb25hbHMgZGVwZW5kaW5nIHVwb24gd2hpY2ggdG9rZW4g Zm9ybWF0IHdhcyBiZWluZyBkZXNjcmliZWQuDQoNCj4gU29tZSBkZXRhaWxzOg0KPiAgDQo+IE9u IHBhZ2UgMyBwYXJhIDIsIGl0IHNheXMg4oCcVGhlIGZvcm1hdCBhbmQgcHJvY2Vzc2luZyBydWxl cyBmb3IgdGhlIEpXVCBkZWZpbmVkIGluIHRoaXMgc3BlY2lmaWNhdGlvbiBhcmUgaW50ZW50aW9u YWxseSBzaW1pbGFyLCB0aG91Z2ggbm90IGlkZW50aWNhbCwgdG8gdGhvc2UgaW4gdGhlIGNsb3Nl bHkgcmVsYXRlZCBTQU1MIDIuMCBQcm9maWxlIGZvciBPQXV0aC7igJ0gSXQgd291bGQgYmUgZ29v ZCBpZiB0aGV5IHNwZWNpZmllZCB3aGF0IHRoZSBkaWZmZXJlbmNlcyBhcmUsIGFuZCB3aHkgdGhl eSBjb3VsZG4ndCBiZSBpZGVudGljYWwuDQoNClRoYXQncyBhIGZhaXIgcG9pbnQuICBJJ2xsIGxv b2sgaW50byB0aGlzIHdpdGggdGhlIG90aGVyIGVkaXRvcnMgYW5kIHRoZSB3b3JraW5nIGdyb3Vw LiAgVGhlIGZvbGxvd2luZyBjb21tZW50cyBpbiB0aGUgSldUIHByb2ZpbGUgc3BlYyByZWNvcmQg U0FNTCBmZWF0dXJlcyB1c2VkIGZvciB3aGljaCBubyBlcXVpdmFsZW50IEpXVCBmZWF0dXJlIGV4 aXN0cy4gIFRoaXMgbWlnaHQgYmUgZ29vZCBtYXRlcmlhbCB0byBwdXQgaW50byBhbiBhcHBlbmRp eC4NCg0KICA8IS0tIE5vIGVxdWl2YWxlbnQgdG8gU3ViamVjdENvbmZpcm1hdGlvbiBNZXRob2Qg InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDpjbTpiZWFyZXIgYXQgcHJlc2VudCAtLT4NCiAg PCEtLSBObyBlcXVpdmFsZW50IHRvIFN1YmplY3RDb25maXJtYXRpb25EYXRhIFJlY2lwaWVudCBh dCBwcmVzZW50IC0tPg0KICA8IS0tIE5vIGVxdWl2YWxlbnQgdG8gU3ViamVjdENvbmZpcm1hdGlv bkRhdGEgQWRkcmVzcyBhdCBwcmVzZW50IC0tPg0KICA8IS0tIE5vIGVxdWl2YWxlbnQgdG8gQXV0 aG5TdGF0ZW1lbnQgYXQgcHJlc2VudCAtLT4NCg0KPiBTb21lIGJhY2tncm91bmQgZ3VpZGFuY2Ug b24gd2hlbiB5b3Ugd291bGQgd2FudCB0byB1c2UgYSB0b2tlbiBmb3IgY2xpZW50IGF1dGhlbnRp Y2F0aW9uIHZzLiB3aGVuIHlvdSB3b3VsZCB3YW50IHRvIHVzZSBvbmUgZm9yIGFuIGF1dGhvcml6 YXRpb24gZ3JhbnQgd291bGQgYmUgdXNlZnVsLiBJbiBwcmFjdGljZSwgdGhlIGRpc3RpbmN0aW9u IGJldHdlZW4gdGhlIHR3byBpcyBzdWJ0bGUuIEl0IGlzIGNvbW1vbiBmb3IgYSB0b2tlbiB0byBj b250YWluIHRoZSBjYWxsZXLigJlzIGlkZW50aXR5IGFzIHdlbGwgYXMgZ3JvdXAgbWVtYmVyc2hp cHMgYW5kIHBlcmhhcHMgcm9sZXMuIEkgc3VzcGVjdCB0aGUgcmVhbGl0eSBpcyB0aGF0IHRoZSBj bGllbnQgaGFzIHRvIGZpZ3VyZSBvdXQgd2hpY2ggcHJvdG9jb2wgc2xvdCB0aGUgc2VydmVyIHdh bnRzIHRvIGdldCB0aGUgdG9rZW4gaW4gYW5kIHByb3ZpZGUgaXQgdGhlcmUsIHdoZXJlIHNlcnZp Y2UgZGVzaWduZXJzIG1ha2UgdGhlIGRlY2lzaW9uIG1vcmUgb3IgbGVzcyBhcmJpdHJhcmlseS4N Cg0KVGhpcyBndWlkYW5jZSByZWFsbHkgYmVsb25ncyBpbiB0aGUgZ2VuZXJpYyBhc3NlcnRpb25z IHNwZWNpZmljYXRpb24gZHJhZnQtaWV0Zi1vYXV0aC1hc3NlcnRpb25zLiAgSSdsbCBwbGFuIG9u IHJldmlld2luZyB0aGF0IHNwZWMgd2l0aCB0aGUgb3RoZXIgZWRpdG9ycyBhbmQgdGhlIHdvcmtp bmcgZ3JvdXAgdG8gc2VlIHdoZXRoZXIgdGhlIGd1aWRhbmNlIHByb3ZpZGVkIHRoZXJlIG5lZWRz IHRvIGJlIGltcHJvdmVkLg0KDQo+IFBhZ2UgNiBpdGVtIDQ6IOKAnFRoZSBhdXRob3JpemF0aW9u IHNlcnZlciBNQVkgcmVqZWN0IEpXVHMgd2l0aCBhbiDigJxleHBpcmF0aW9u4oCdIGNsYWltIHRo YXQgaXMgdW5yZWFzb25hYmx5IGZhciBpbiB0aGUgZnV0dXJlLuKAnSBUaGlzIGlzIHNheWluZyB0 aGF0IHRoZSB2YWxpZGF0b3Igb2YgdGhlIHRva2VuIG1pZ2h0IGNob29zZSB0byByZWplY3QgdG9r ZW5zIHRoYXQgYXJlIGxvbmcgbGl2ZWQuIEl04oCZcyBub3QgY2xlYXIgd2hhdCB0aGUgdXNlciBv ZiB0aGlzIHNwZWMgY2FuIGRvIHdpdGggdGhpcyBpbmZvcm1hdGlvbi4gSXQgY2FsbHMgZm9yIHNv bWUgb3V0LW9mLWJhbmQgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIHRoZSB0b2tlbiBpc3N1ZXIgYW5k IHRoZSB0b2tlbiB2YWxpZGF0b3Igb24gd2hhdCBpcyBhbiBhY2NlcHRhYmxlIGV4cGlyYXRpb24g cGVyaW9kLiBVbmxlc3MgdGhlIHByb3RvY29sIGhhcyBzb21lIHdheSBvZiByZXBvcnRpbmcgdGhp cyBiYWNrIHNvIHRoYXQgdGhlIGNhbGxlciBjYW4gZ2V0IGEgc2hvcnRlci1saXZlZCB0b2tlbiwg aXQgc2VlbXMgbGlrZSBhIGZyYWdpbGUgZGVzaWduLg0KDQpXaGF0IHlvdSB3cml0ZSBpcyB0cnVl LCBidXQgaXQnIGFsc28gYSBjb25zZXF1ZW5jZSBvZiB0aGUgZmFjdCB0aGF0IGFwcGxpY2F0aW9u cyBhcmUgZnJlZSB0byBpbXBvc2UgYWRkaXRpb25hbCByZXF1aXJlbWVudHMgb24gdGhlIHVzYWdl IG9mIHRoaXMgc3BlY2lmaWNhdGlvbiwgcHJvdmlkZWQgdGhlaXIgdXNhZ2UgaXMgc3RpbGwgY29u Zm9ybWluZy4gIEkgYmVsaWV2ZSB0aGF0IHRoZSB0ZXh0IGFib3ZlIHNob3VsZCBiZSBtb2RpZmll ZCB0byBiZWdpbiAiTm90ZSB0aGF0IC4uLiIgdG8gbWFrZSBpdCBjbGVhciB0aGF0IHRoaXMgaXMg aW5mb3JtYXRpdmUsIGFuZCBub3Qgbm9ybWF0aXZlIHRleHQuDQoNCj4gUmFkaWENCg0KCQkJCVRo YW5rcyBhZ2FpbiwNCgkJCQktLSBNaWtlDQoNCg== From nobody Mon Oct 6 12:49:03 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF661A1B7F; Mon, 6 Oct 2014 12:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8C6bwzz55CXg; Mon, 6 Oct 2014 12:48:47 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6232B1A1A34; Mon, 6 Oct 2014 12:48:47 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 792CE1B81AB; Mon, 6 Oct 2014 12:48:46 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 4D31D53E070; Mon, 6 Oct 2014 12:48:46 -0700 (PDT) Received: from [10.0.10.40] (71.233.43.215) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 6 Oct 2014 12:48:46 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439BAF0C41@TK5EX14MBXC286.redmond.corp.microsoft.com> Date: Mon, 6 Oct 2014 15:48:44 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <0DB7566C-CEFD-49E3-AD23-83E4EE5C1D01@nominum.com> References: <20141002135827.27947.4504.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739439BAF0C41@TK5EX14MBXC286.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/PoG_oHvSHoG5mUBe4xKlRtJ4CFU Cc: "oauth-chairs@tools.ietf.org" , "oauth@ietf.org" , The IESG , "draft-ietf-oauth-json-web-token@tools.ietf.org" Subject: Re: [OAUTH-WG] Ted Lemon's No Objection on draft-ietf-oauth-json-web-token-27: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 19:48:53 -0000 On Oct 6, 2014, at 3:54 AM, Mike Jones = wrote: > Sometimes authenticated encryption alone is good enough without = requiring a signature. Different applications will have different = requirements. So while this section discussion the applicable = considerations, the working group felt that it was going too far to make = this prescriptive. But if you don't need to sign the message, why sign it? From nobody Mon Oct 6 14:42:52 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA4801A6FD6; Mon, 6 Oct 2014 14:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GWWehuMA5a1E; Mon, 6 Oct 2014 14:42:48 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id D31F21A1A19; Mon, 6 Oct 2014 14:42:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 35363BE0F; Mon, 6 Oct 2014 22:42:47 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbQ7D1FaHMQn; Mon, 6 Oct 2014 22:42:45 +0100 (IST) Received: from [10.87.48.8] (unknown [86.41.57.167]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5197BBE07; Mon, 6 Oct 2014 22:42:45 +0100 (IST) Message-ID: <54330CD5.8090807@cs.tcd.ie> Date: Mon, 06 Oct 2014 22:42:45 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Mike Jones , The IESG References: <20141002120308.9386.79961.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739439BAF0C2A@TK5EX14MBXC286.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439BAF0C2A@TK5EX14MBXC286.redmond.corp.microsoft.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/oEzlqiJwgLsOTbGGeemJIRNxOzI Cc: "oauth-chairs@tools.ietf.org" , "draft-ietf-oauth-json-web-token@tools.ietf.org" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 21:42:49 -0000 Hi Mike, On 06/10/14 08:54, Mike Jones wrote: > Thanks for your review, Stephen. I've added the working group to the > thread so they're aware of your comments. > >> -----Original Message----- From: Stephen Farrell >> [mailto:stephen.farrell@cs.tcd.ie] Sent: Thursday, October 02, 2014 >> 5:03 AM To: The IESG Cc: oauth-chairs@tools.ietf.org; >> draft-ietf-oauth-json-web- token@tools.ietf.org Subject: Stephen >> Farrell's Discuss on draft-ietf-oauth-json-web-token-27: (with >> DISCUSS and COMMENT) >> >> Stephen Farrell has entered the following ballot position for >> draft-ietf-oauth-json-web-token-27: Discuss >> >> When responding, please keep the subject line intact and reply to >> all email addresses included in the To and CC lines. (Feel free to >> cut this introductory paragraph, however.) >> >> >> Please refer to >> http://www.ietf.org/iesg/statement/discuss-criteria.html for more >> information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found >> here: >> http://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/ >> >> >> >> ---------------------------------------------------------------------- >> >> DISCUSS: >> ---------------------------------------------------------------------- >> >> >> >> (1) 4.1.1 and elsewhere you say case-sensitive: the same thing I raised wrt DNS >> names for another JOSE spec - do you need to say those SHOULD be >> [upper|lower]cased when used in these? > > I believe that somewhere we should say that if case-insensitive > values, such as DNS names, are used when constructing "kid" values, > that the application doing so needs to define a convention on the > canonical case to use for the case-insensitive portions, such as > lowercasing them. As that discussion's happening on the key draft, I'll clear it here and trust you to fix if a change is the end result. > >> (2) Section 8: Why is "none" MTI? That seems both broken and going >> in the oppostite direction from other WGs and so should be >> explicitly jusified I think. (If a good enough justification exists >> that is.) > > It is MTI because there are several existing applications of JWTs in > which both unsigned and signed representations of the JWTs are > requirements. These include draft-ietf-oauth-token-exchange, > draft-hunt-oauth-v2-user-a4c, and OpenID Connect. This is a pretty > common pattern where you sign something if the recipient cares who > made the statements and where you don't have to sign it either if the > recipient doesn't care who made the statements I don't see how (non-)signers can divine non-verifier's wishes that way. (Absent negotiation or a directory.) > or if it can tell from > another secured aspect of the application protocol (typically through > the use of TLS) who made the statements. In the TLS case, the server > authentication step makes a signature step unnecessary, so an > Unsecured JWT is fine there. That's arguable IMO. I think I'll look back over the wg thread and either hold my nose or > >> (3) Section 12: another way to handle privacy is to not include >> sensitive data - I think you ought mention that as a bit of thought >> along those lines can be much simpler than putting in place the key >> management to handle thoughtlessly included PII. > > We can include a discussion of that point, Great. "Just say no" is workable here:-) I'll clear when we get such text. > but sometimes the very > point of a JWT is to securely deliver PII from a verifiable party to > an intended party with appropriate rights to receive it. Hmm. Its a moot point (so let's not argue it) but I wonder how often PII is really needed for authorization with oauth. My guess would be that its needed far less often than its found to be profitable perhaps, or that carelessness plays a big role in using PII for such purposes. S. > >> ---------------------------------------------------------------------- >> >> COMMENT: >> ---------------------------------------------------------------------- >> >> >> >> - abstract: 2nd sentence isn't needed here, in intro would be fine. > > I don't know - I think it's a big deal that the claims can be > digitally signed or MACed and/or encrypted. That's the reason we > have JWTs, rather than just JSON. > >> - 4.1.7: maybe worth adding that jti+iss being unique enough is not >> sufficient and jti alone has to meet that need. In X.509 the >> issuer/serial has the equivalent property so someone might assume >> sequential jti values starting at 0 are ok. > > Makes sense to add a warning of some kind along these lines. I think > I know the reasons you say that, but can you expand on that thought a > bit before I take a stab on writing this up? For instance, while > normally true, I don't think your observation is true if a relying > party will only accept tokens from a single issuer. > >> - section 6: yuk >> >> - again I think the secdir comments are being handled by Kathleen >> and the authors. > > Again, this is there because multiple applications asked for the > ability to represent content that is optionally signed, sometimes > securing it another way, such as with TLS. JWTs are used specific > application protocol contexts - not in isolation. > > Thanks again, -- Mike > From nobody Mon Oct 6 15:48:17 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB291A889E for ; Mon, 6 Oct 2014 15:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.831 X-Spam-Level: X-Spam-Status: No, score=-1.831 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SQLeYCiJ-3HH for ; Mon, 6 Oct 2014 15:48:13 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93A561A6F84 for ; Mon, 6 Oct 2014 15:48:13 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id k15so4199546qaq.10 for ; Mon, 06 Oct 2014 15:48:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=LVlWbdxjlKNROgSPW6M15Sra9DWu6wBCMdYHWmgxdVA=; b=gQJxlHatjqD8pG2Gjy+gPynS3ahnvIUndEC3cDt8NoMFQFsBZ4jrnHUwYWe3R99KhD E4NCGB8LrlfMXVPvqtT5GKZznq0TO7hTSG8BryHYLSs8gph4tpuzWi4QOusnxoORGTU0 z7HF87xW3fTTGKeXc8cl9jdKFs7dC4SxsFKs1LCbDDjNJ4Aux9clTfcqeXnQd8KcvvsV H9uhxSK+nrMh6seyT4p5lRdlVX7XSlAX0hCStvQCNfM0wXjUYCyeRG05TVnZiEntQBhh IsyWA9iBU9+KtJDxBXWpXJ8ynd9jN9CUYUV32QuBDxsI5X9wvb23KdELiN9KGJNzRBz2 rvXA== X-Gm-Message-State: ALoCoQnvokB466aiFTxE/7i77S556FyIXikSYB+hmFQpblH4qy6wI3RFz0Sur3IESjj9rC3rU0/d X-Received: by 10.140.85.17 with SMTP id m17mr31780407qgd.50.1412635692650; Mon, 06 Oct 2014 15:48:12 -0700 (PDT) Received: from [192.168.8.100] ([186.65.202.239]) by mx.google.com with ESMTPSA id s49sm13666178qge.15.2014.10.06.15.48.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 06 Oct 2014 15:48:12 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Bradley In-Reply-To: <54330CD5.8090807@cs.tcd.ie> Date: Mon, 6 Oct 2014 19:48:09 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <92001C85-19DC-4F09-9AD7-74307B0CDE9D@ve7jtb.com> References: <20141002120308.9386.79961.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739439BAF0C2A@TK5EX14MBXC286.redmond.corp.microsoft.com> <54330CD5.8090807@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/N939q8i9Y0wrtBZsdK_eweGDw7A Cc: "oauth-chairs@tools.ietf.org" , "oauth@ietf.org" , The IESG , "draft-ietf-oauth-json-web-token@tools.ietf.org" Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 22:48:15 -0000 While my personal preference is to not release PII as part of = authentication, We do have people demanding attributes in SAML and = Connect at LoA 2+ for identity resolution at the relying party. = https://www.idmanagement.gov/sites/default/files/documents/FICAM_TFS_ATOS.= pdf (see Appendix A) JWT is used in much more than just OAuth these days. John B. On Oct 6, 2014, at 6:42 PM, Stephen Farrell = wrote: >>=20 >> but sometimes the very >> point of a JWT is to securely deliver PII from a verifiable party to >> an intended party with appropriate rights to receive it. >=20 > Hmm. Its a moot point (so let's not argue it) but I wonder how > often PII is really needed for authorization with oauth. My guess > would be that its needed far less often than its found to be > profitable perhaps, or that carelessness plays a big role in > using PII for such purposes. From nobody Mon Oct 6 19:20:11 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83E2A1A9112; Mon, 6 Oct 2014 19:20:02 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ATOrxktPC_xw; Mon, 6 Oct 2014 19:19:59 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0117.outbound.protection.outlook.com [207.46.100.117]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43F531A9108; Mon, 6 Oct 2014 19:19:59 -0700 (PDT) Received: from CO2PR03CA0040.namprd03.prod.outlook.com (10.141.194.167) by BN3PR0301MB1204.namprd03.prod.outlook.com (25.161.207.16) with Microsoft SMTP Server (TLS) id 15.0.1044.10; Tue, 7 Oct 2014 02:19:56 +0000 Received: from BY2FFO11FD021.protection.gbl (2a01:111:f400:7c0c::184) by CO2PR03CA0040.outlook.office365.com (2a01:111:e400:1414::39) with Microsoft SMTP Server (TLS) id 15.0.1044.10 via Frontend Transport; Tue, 7 Oct 2014 02:19:56 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD021.mail.protection.outlook.com (10.1.15.210) with Microsoft SMTP Server (TLS) id 15.0.1039.16 via Frontend Transport; Tue, 7 Oct 2014 02:19:56 +0000 Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.93]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.03.0210.003; Tue, 7 Oct 2014 02:19:46 +0000 From: Mike Jones To: Stephen Farrell , The IESG Thread-Topic: Stephen Farrell's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) Thread-Index: AQHP3jjwXNtLGJwBq0euviBV//YhCJwiQ55QgAFc3YCAADr1EA== Date: Tue, 7 Oct 2014 02:19:45 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439BAF318F@TK5EX14MBXC286.redmond.corp.microsoft.com> References: <20141002120308.9386.79961.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739439BAF0C2A@TK5EX14MBXC286.redmond.corp.microsoft.com> <54330CD5.8090807@cs.tcd.ie> In-Reply-To: <54330CD5.8090807@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(51704005)(52604005)(43784003)(199003)(13464003)(24454002)(52044002)(479174003)(377454003)(189002)(85806002)(21056001)(20776003)(87936001)(2656002)(85852003)(86362001)(33656002)(26826002)(31966008)(23676002)(95666004)(55846006)(86612001)(104016003)(85306004)(107046002)(66066001)(4396001)(19580405001)(69596002)(46102003)(44976005)(68736004)(50986999)(76482002)(80022003)(120916001)(84676001)(99396003)(47776003)(92726001)(64706001)(97736003)(6806004)(92566001)(106116001)(76176999)(15975445006)(106466001)(54356999)(230783001)(50466002)(19580395003)(15202345003)(77096002)(81156004); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1204; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1204; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 035748864E Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/QTHHZQ49MKYkX-I8swv0DkYvKjw Cc: "oauth-chairs@tools.ietf.org" , "draft-ietf-oauth-json-web-token@tools.ietf.org" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 02:20:02 -0000 VGhhbmtzIGZvciB0cmFja2luZyBhbGwgb2YgdGhpcyBTdGVwaGVuLiAgUmVzcG9uc2VzIGlubGlu ZSBiZWxvdy4uLg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFN0ZXBo ZW4gRmFycmVsbCBbbWFpbHRvOnN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWVdDQo+IFNlbnQ6IE1v bmRheSwgT2N0b2JlciAwNiwgMjAxNCAyOjQzIFBNDQo+IFRvOiBNaWtlIEpvbmVzOyBUaGUgSUVT Rw0KPiBDYzogb2F1dGgtY2hhaXJzQHRvb2xzLmlldGYub3JnOyBkcmFmdC1pZXRmLW9hdXRoLWpz b24td2ViLQ0KPiB0b2tlbkB0b29scy5pZXRmLm9yZzsgb2F1dGhAaWV0Zi5vcmcNCj4gU3ViamVj dDogUmU6IFN0ZXBoZW4gRmFycmVsbCdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1vYXV0aC1qc29u LXdlYi10b2tlbi0yNzoNCj4gKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCj4gDQo+IA0KPiBI aSBNaWtlLA0KPiANCj4gT24gMDYvMTAvMTQgMDg6NTQsIE1pa2UgSm9uZXMgd3JvdGU6DQo+ID4g VGhhbmtzIGZvciB5b3VyIHJldmlldywgU3RlcGhlbi4gIEkndmUgYWRkZWQgdGhlIHdvcmtpbmcg Z3JvdXAgdG8gdGhlDQo+ID4gdGhyZWFkIHNvIHRoZXkncmUgYXdhcmUgb2YgeW91ciBjb21tZW50 cy4NCj4gPg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSBGcm9tOiBTdGVwaGVuIEZh cnJlbGwNCj4gPj4gW21haWx0bzpzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllXSBTZW50OiBUaHVy c2RheSwgT2N0b2JlciAwMiwgMjAxNA0KPiA+PiA1OjAzIEFNIFRvOiBUaGUgSUVTRyBDYzogb2F1 dGgtY2hhaXJzQHRvb2xzLmlldGYub3JnOw0KPiA+PiBkcmFmdC1pZXRmLW9hdXRoLWpzb24td2Vi LSB0b2tlbkB0b29scy5pZXRmLm9yZyBTdWJqZWN0OiBTdGVwaGVuDQo+ID4+IEZhcnJlbGwncyBE aXNjdXNzIG9uIGRyYWZ0LWlldGYtb2F1dGgtanNvbi13ZWItdG9rZW4tMjc6ICh3aXRoDQo+ID4+ IERJU0NVU1MgYW5kIENPTU1FTlQpDQo+ID4+DQo+ID4+IFN0ZXBoZW4gRmFycmVsbCBoYXMgZW50 ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCj4gPj4gZHJhZnQtaWV0Zi1v YXV0aC1qc29uLXdlYi10b2tlbi0yNzogRGlzY3Vzcw0KPiA+Pg0KPiA+PiBXaGVuIHJlc3BvbmRp bmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwN Cj4gPj4gZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChG ZWVsIGZyZWUgdG8gY3V0DQo+ID4+IHRoaXMgaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZl ci4pDQo+ID4+DQo+ID4+DQo+ID4+IFBsZWFzZSByZWZlciB0bw0KPiA+PiBodHRwOi8vd3d3Lmll dGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbCBmb3IgbW9yZQ0KPiA+ PiBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0K PiA+Pg0KPiA+Pg0KPiA+PiBUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBv c2l0aW9ucywgY2FuIGJlIGZvdW5kDQo+ID4+IGhlcmU6DQo+ID4+IGh0dHA6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi10b2tlbi8NCj4gPj4NCj4g Pj4NCj4gPj4NCj4gPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+IC0NCj4gPj4NCj4gPj4NCj4gRElTQ1VT UzoNCj4gPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+IC0NCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4NCj4g KDEpIDQuMS4xIGFuZCBlbHNld2hlcmUgeW91IHNheSBjYXNlLXNlbnNpdGl2ZTogdGhlIHNhbWUg dGhpbmcgSSByYWlzZWQgd3J0IEROUw0KPiA+PiBuYW1lcyBmb3IgYW5vdGhlciBKT1NFIHNwZWMg LSBkbyB5b3UgbmVlZCB0byBzYXkgdGhvc2UgU0hPVUxEIGJlDQo+ID4+IFt1cHBlcnxsb3dlcl1j YXNlZCB3aGVuIHVzZWQgaW4gdGhlc2U/DQo+ID4NCj4gPiBJIGJlbGlldmUgdGhhdCBzb21ld2hl cmUgd2Ugc2hvdWxkIHNheSB0aGF0IGlmIGNhc2UtaW5zZW5zaXRpdmUNCj4gPiB2YWx1ZXMsIHN1 Y2ggYXMgRE5TIG5hbWVzLCBhcmUgdXNlZCB3aGVuIGNvbnN0cnVjdGluZyAia2lkIiB2YWx1ZXMs DQo+ID4gdGhhdCB0aGUgYXBwbGljYXRpb24gZG9pbmcgc28gbmVlZHMgdG8gZGVmaW5lIGEgY29u dmVudGlvbiBvbiB0aGUNCj4gPiBjYW5vbmljYWwgY2FzZSB0byB1c2UgZm9yIHRoZSBjYXNlLWlu c2Vuc2l0aXZlIHBvcnRpb25zLCBzdWNoIGFzDQo+ID4gbG93ZXJjYXNpbmcgdGhlbS4NCj4gDQo+ IEFzIHRoYXQgZGlzY3Vzc2lvbidzIGhhcHBlbmluZyBvbiB0aGUga2V5IGRyYWZ0LCBJJ2xsIGNs ZWFyIGl0IGhlcmUgYW5kIHRydXN0IHlvdSB0bw0KPiBmaXggaWYgYSBjaGFuZ2UgaXMgdGhlIGVu ZCByZXN1bHQuDQoNClRoYW5rcw0KDQo+ID4+ICgyKSBTZWN0aW9uIDg6IFdoeSBpcyAibm9uZSIg TVRJPyBUaGF0IHNlZW1zIGJvdGggYnJva2VuIGFuZCBnb2luZyBpbg0KPiA+PiB0aGUgb3Bwb3N0 aXRlIGRpcmVjdGlvbiBmcm9tIG90aGVyIFdHcyBhbmQgc28gc2hvdWxkIGJlIGV4cGxpY2l0bHkN Cj4gPj4ganVzaWZpZWQgSSB0aGluay4gKElmIGEgZ29vZCBlbm91Z2gganVzdGlmaWNhdGlvbiBl eGlzdHMgdGhhdCBpcy4pDQo+ID4NCj4gPiBJdCBpcyBNVEkgYmVjYXVzZSB0aGVyZSBhcmUgc2V2 ZXJhbCBleGlzdGluZyBhcHBsaWNhdGlvbnMgb2YgSldUcyBpbg0KPiA+IHdoaWNoIGJvdGggdW5z aWduZWQgYW5kIHNpZ25lZCByZXByZXNlbnRhdGlvbnMgb2YgdGhlIEpXVHMgYXJlDQo+ID4gcmVx dWlyZW1lbnRzLiAgVGhlc2UgaW5jbHVkZSBkcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdl LA0KPiA+IGRyYWZ0LWh1bnQtb2F1dGgtdjItdXNlci1hNGMsIGFuZCBPcGVuSUQgQ29ubmVjdC4g IFRoaXMgaXMgYSBwcmV0dHkNCj4gPiBjb21tb24gcGF0dGVybiB3aGVyZSB5b3Ugc2lnbiBzb21l dGhpbmcgaWYgdGhlIHJlY2lwaWVudCBjYXJlcyB3aG8NCj4gPiBtYWRlIHRoZSBzdGF0ZW1lbnRz IGFuZCB3aGVyZSB5b3UgZG9uJ3QgaGF2ZSB0byBzaWduIGl0IGVpdGhlciBpZiB0aGUNCj4gPiBy ZWNpcGllbnQgZG9lc24ndCBjYXJlIHdobyBtYWRlIHRoZSBzdGF0ZW1lbnRzDQo+IA0KPiBJIGRv bid0IHNlZSBob3cgKG5vbi0pc2lnbmVycyBjYW4gZGl2aW5lIG5vbi12ZXJpZmllcidzIHdpc2hl cyB0aGF0IHdheS4gKEFic2VudA0KPiBuZWdvdGlhdGlvbiBvciBhIGRpcmVjdG9yeS4pDQoNClNv bWV0aW1lcyBpdCBkb2VzIG9jY3VyIHZpYSBuZWdvdGlhdGlvbi4gIEZvciBpbnN0YW5jZSwgaW4g c29tZSBwcm90b2NvbHMsIGF0IHJlZ2lzdHJhdGlvbiB0aW1lLCByZWx5aW5nIHBhcnRpZXMgZXhw bGljaXRseSB0ZWxsIGlkZW50aXR5IHByb3ZpZGVycyB3aGF0IGFsZ29yaXRobXMgYXJlIGFjY2Vw dGFibGUgdG8gdGhlbSwgd2hpY2ggbWF5IGluY2x1ZGUgIm5vbmUiLiAgTm8gZGl2aW5hdGlvbiAt IGV4cGxpY2l0IGNvbW11bmljYXRpb24uDQoNCj4gPiBvciBpZiBpdCBjYW4gdGVsbCBmcm9tDQo+ ID4gYW5vdGhlciBzZWN1cmVkIGFzcGVjdCBvZiB0aGUgYXBwbGljYXRpb24gcHJvdG9jb2wgKHR5 cGljYWxseSB0aHJvdWdoDQo+ID4gdGhlIHVzZSBvZiBUTFMpIHdobyBtYWRlIHRoZSBzdGF0ZW1l bnRzLiAgSW4gdGhlIFRMUyBjYXNlLCB0aGUgc2VydmVyDQo+ID4gYXV0aGVudGljYXRpb24gc3Rl cCBtYWtlcyBhIHNpZ25hdHVyZSBzdGVwIHVubmVjZXNzYXJ5LCBzbyBhbg0KPiA+IFVuc2VjdXJl ZCBKV1QgaXMgZmluZSB0aGVyZS4NCj4gDQo+IFRoYXQncyBhcmd1YWJsZSBJTU8uDQoNCkkgYWdy ZWUgdGhhdCBpdCdzIGFwcGxpY2F0aW9uIGFuZCBjb250ZXh0LWRlcGVuZGVudCB3aGV0aGVyIGl0 J3MgT0sgb3Igbm90LiAgVGhlIHBvaW50IGlzIHRoYXQgdGhlcmUgZXhpc3Qgc29tZSBjaXJjdW1z dGFuY2VzIGluIHdoaWNoIGl0IGlzIE9LLCBhbmQgdGhpcyBmZWF0dXJlIGlzIGJlaW5nIHVzZWQg aW4gc29tZSBvZiB0aG9zZSBjYXNlcy4NCg0KPiBJIHRoaW5rIEknbGwgbG9vayBiYWNrIG92ZXIg dGhlIHdnIHRocmVhZCBhbmQgZWl0aGVyIGhvbGQgbXkgbm9zZSBvcg0KDQpUaGlzIGlzc3VlIHdh cyB0cmFja2VkIGFzIGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL2pvc2UvdHJhYy90aWNr ZXQvMzYuICBLYXJlbiBPJ0Rvbm9naHVlIHJlY29yZGVkIHRoaXMgY29uY2x1c2lvbiBpbiB0aGUg dHJhY2tlciAiTm90ZTogVGhlcmUgd2FzIGV4dGVuc2l2ZSBkaXNjdXNzaW9uIG9uIHRoZSBtYWls aW5nIGxpc3QsIGFuZCB0aGUgcm91Z2ggIGNvbnNlbnN1cyBvZiB0aGUgd29ya2luZyBncm91cCB3 YXMgdG8gbGVhdmUgIm5vbmUiIGluIHRoZSBkb2N1bWVudC4iDQoNCkRpc2N1c3Npb24gdGhyZWFk cyBvbiB0aGlzIHRvcGljIGluY2x1ZGU6DQpbam9zZV0gIzM2OiBBbGdvcml0aG0gIm5vbmUiIHNo b3VsZCBiZSByZW1vdmVkIGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9qb3Nl L2N1cnJlbnQvbXNnMDI5MTEuaHRtbCAtIEJlZ2FuIEp1bCAzMSwgMjAxMyAgKDkxIG1lc3NhZ2Vz KQ0KW2pvc2VdIFRleHQgYWJvdXQgYXBwbGljYXRpb25zIGFuZCAiYWxnIjoibm9uZSIgaHR0cDov L3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2pvc2UvY3VycmVudC9tc2cwMzMyMS5odG1s IC0gQmVnYW4gU2VwIDMsIDIwMTMgKDUgbWVzc2FnZXMpDQoNClRoaXMgaXNzdWUgd2FzIGEgdG9w aWMgb2YgYSBzcGVjaWFsIHdvcmtpbmcgZ3JvdXAgY2FsbCBvbiBBdWcgMTksIDIwMTMuICBUaGUg dGV4dCBkaXNjdXNzZWQgaW4gdGhlIGxhc3QgdGhyZWFkIGFuZCBwdWJsaXNoZWQgYXQgaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1hbGdvcml0aG1z LTMzI3NlY3Rpb24tOC41IChVbnNlY3VyZWQgSldTIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zKSB3 YXMgdGhlIHJlc3VsdCBvZiB0aGUgd29ya2luZyBncm91cCdzIGRlY2lzaW9ucyByZXN1bHRpbmcg ZnJvbSBhbGwgb2YgdGhpcyBkaXNjdXNzaW9uLg0KDQo+ID4+ICgzKSBTZWN0aW9uIDEyOiBhbm90 aGVyIHdheSB0byBoYW5kbGUgcHJpdmFjeSBpcyB0byBub3QgaW5jbHVkZQ0KPiA+PiBzZW5zaXRp dmUgZGF0YSAtIEkgdGhpbmsgeW91IG91Z2h0IG1lbnRpb24gdGhhdCBhcyBhIGJpdCBvZiB0aG91 Z2h0DQo+ID4+IGFsb25nIHRob3NlIGxpbmVzIGNhbiBiZSBtdWNoIHNpbXBsZXIgdGhhbiBwdXR0 aW5nIGluIHBsYWNlIHRoZSBrZXkNCj4gPj4gbWFuYWdlbWVudCB0byBoYW5kbGUgdGhvdWdodGxl c3NseSBpbmNsdWRlZCBQSUkuDQo+ID4NCj4gPiBXZSBjYW4gaW5jbHVkZSBhIGRpc2N1c3Npb24g b2YgdGhhdCBwb2ludCwNCj4gDQo+IEdyZWF0LiAiSnVzdCBzYXkgbm8iIGlzIHdvcmthYmxlIGhl cmU6LSkgSSdsbCBjbGVhciB3aGVuIHdlIGdldCBzdWNoIHRleHQuDQo+IA0KPiA+IGJ1dCBzb21l dGltZXMgdGhlIHZlcnkNCj4gPiBwb2ludCBvZiBhIEpXVCBpcyB0byBzZWN1cmVseSBkZWxpdmVy IFBJSSBmcm9tIGEgdmVyaWZpYWJsZSBwYXJ0eSB0bw0KPiA+IGFuIGludGVuZGVkIHBhcnR5IHdp dGggYXBwcm9wcmlhdGUgcmlnaHRzIHRvIHJlY2VpdmUgaXQuDQo+IA0KPiBIbW0uIEl0cyBhIG1v b3QgcG9pbnQgKHNvIGxldCdzIG5vdCBhcmd1ZSBpdCkgYnV0IEkgd29uZGVyIGhvdyBvZnRlbiBQ SUkgaXMgcmVhbGx5DQo+IG5lZWRlZCBmb3IgYXV0aG9yaXphdGlvbiB3aXRoIG9hdXRoLiBNeSBn dWVzcyB3b3VsZCBiZSB0aGF0IGl0cyBuZWVkZWQgZmFyIGxlc3MNCj4gb2Z0ZW4gdGhhbiBpdHMg Zm91bmQgdG8gYmUgcHJvZml0YWJsZSBwZXJoYXBzLCBvciB0aGF0IGNhcmVsZXNzbmVzcyBwbGF5 cyBhIGJpZw0KPiByb2xlIGluIHVzaW5nIFBJSSBmb3Igc3VjaCBwdXJwb3Nlcy4NCj4gDQo+IFMu DQo+IA0KPiANCj4gDQo+ID4NCj4gPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+IC0NCj4gPj4NCj4gPj4N Cj4gQ09NTUVOVDoNCj4gPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+IC0NCj4gPj4NCj4gPj4NCj4gPj4N Cj4gPj4NCj4gLSBhYnN0cmFjdDogMm5kIHNlbnRlbmNlIGlzbid0IG5lZWRlZCBoZXJlLCBpbiBp bnRybyB3b3VsZCBiZSBmaW5lLg0KPiA+DQo+ID4gSSBkb24ndCBrbm93IC0gSSB0aGluayBpdCdz IGEgYmlnIGRlYWwgdGhhdCB0aGUgY2xhaW1zIGNhbiBiZQ0KPiA+IGRpZ2l0YWxseSBzaWduZWQg b3IgTUFDZWQgYW5kL29yIGVuY3J5cHRlZC4gIFRoYXQncyB0aGUgcmVhc29uIHdlIGhhdmUNCj4g PiBKV1RzLCByYXRoZXIgdGhhbiBqdXN0IEpTT04uDQo+ID4NCj4gPj4gLSA0LjEuNzogbWF5YmUg d29ydGggYWRkaW5nIHRoYXQganRpK2lzcyBiZWluZyB1bmlxdWUgZW5vdWdoIGlzIG5vdA0KPiA+ PiBzdWZmaWNpZW50IGFuZCBqdGkgYWxvbmUgaGFzIHRvIG1lZXQgdGhhdCBuZWVkLiBJbiBYLjUw OSB0aGUNCj4gPj4gaXNzdWVyL3NlcmlhbCBoYXMgdGhlIGVxdWl2YWxlbnQgcHJvcGVydHkgc28g c29tZW9uZSBtaWdodCBhc3N1bWUNCj4gPj4gc2VxdWVudGlhbCBqdGkgdmFsdWVzIHN0YXJ0aW5n IGF0IDAgYXJlIG9rLg0KPiA+DQo+ID4gTWFrZXMgc2Vuc2UgdG8gYWRkIGEgd2FybmluZyBvZiBz b21lIGtpbmQgYWxvbmcgdGhlc2UgbGluZXMuICBJIHRoaW5rDQo+ID4gSSBrbm93IHRoZSByZWFz b25zIHlvdSBzYXkgdGhhdCwgYnV0IGNhbiB5b3UgZXhwYW5kIG9uIHRoYXQgdGhvdWdodCBhDQo+ ID4gYml0IGJlZm9yZSBJIHRha2UgYSBzdGFiIG9uIHdyaXRpbmcgdGhpcyB1cD8gIEZvciBpbnN0 YW5jZSwgd2hpbGUNCj4gPiBub3JtYWxseSB0cnVlLCBJIGRvbid0IHRoaW5rIHlvdXIgb2JzZXJ2 YXRpb24gaXMgdHJ1ZSBpZiBhIHJlbHlpbmcNCj4gPiBwYXJ0eSB3aWxsIG9ubHkgYWNjZXB0IHRv a2VucyBmcm9tIGEgc2luZ2xlIGlzc3Vlci4NCj4gPg0KPiA+PiAtIHNlY3Rpb24gNjogeXVrDQo+ ID4+DQo+ID4+IC0gYWdhaW4gSSB0aGluayB0aGUgc2VjZGlyIGNvbW1lbnRzIGFyZSBiZWluZyBo YW5kbGVkIGJ5IEthdGhsZWVuIGFuZA0KPiA+PiB0aGUgYXV0aG9ycy4NCj4gPg0KPiA+IEFnYWlu LCB0aGlzIGlzIHRoZXJlIGJlY2F1c2UgbXVsdGlwbGUgYXBwbGljYXRpb25zIGFza2VkIGZvciB0 aGUNCj4gPiBhYmlsaXR5IHRvIHJlcHJlc2VudCBjb250ZW50IHRoYXQgaXMgb3B0aW9uYWxseSBz aWduZWQsIHNvbWV0aW1lcw0KPiA+IHNlY3VyaW5nIGl0IGFub3RoZXIgd2F5LCBzdWNoIGFzIHdp dGggVExTLiAgSldUcyBhcmUgdXNlZCBzcGVjaWZpYw0KPiA+IGFwcGxpY2F0aW9uIHByb3RvY29s IGNvbnRleHRzIC0gbm90IGluIGlzb2xhdGlvbi4NCj4gPg0KPiA+IFRoYW5rcyBhZ2FpbiwgLS0g TWlrZQ0KPiA+DQo= From nobody Mon Oct 6 22:30:50 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 747D21A8BB0; Mon, 6 Oct 2014 22:30: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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kyV_WlCC9XAG; Mon, 6 Oct 2014 22:30:46 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0759.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:759]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB3081A9126; Mon, 6 Oct 2014 22:30:46 -0700 (PDT) Received: from BY2PR03CA045.namprd03.prod.outlook.com (10.141.249.18) by BN3PR0301MB1202.namprd03.prod.outlook.com (25.161.207.155) with Microsoft SMTP Server (TLS) id 15.0.1044.10; Tue, 7 Oct 2014 05:30:23 +0000 Received: from BL2FFO11FD011.protection.gbl (2a01:111:f400:7c09::137) by BY2PR03CA045.outlook.office365.com (2a01:111:e400:2c5d::18) with Microsoft SMTP Server (TLS) id 15.0.1044.10 via Frontend Transport; Tue, 7 Oct 2014 05:30:22 +0000 Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD011.mail.protection.outlook.com (10.173.161.17) with Microsoft SMTP Server (TLS) id 15.0.1039.16 via Frontend Transport; Tue, 7 Oct 2014 05:30:22 +0000 Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.93]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.03.0210.003; Tue, 7 Oct 2014 05:29:44 +0000 From: Mike Jones To: Ted Lemon Thread-Topic: Ted Lemon's No Objection on draft-ietf-oauth-json-web-token-27: (with COMMENT) Thread-Index: AQHP3kj4EDDmiynllUmOKg/KYNPHJpwiUwtQgAEtdQCAAKFaoA== Date: Tue, 7 Oct 2014 05:29:42 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439BAF362F@TK5EX14MBXC286.redmond.corp.microsoft.com> References: <20141002135827.27947.4504.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739439BAF0C41@TK5EX14MBXC286.redmond.corp.microsoft.com> <0DB7566C-CEFD-49E3-AD23-83E4EE5C1D01@nominum.com> In-Reply-To: <0DB7566C-CEFD-49E3-AD23-83E4EE5C1D01@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(189002)(51704005)(377454003)(24454002)(13464003)(199003)(77096002)(47776003)(106466001)(76482002)(87936001)(81156004)(97756001)(66066001)(21056001)(95666004)(85306004)(50466002)(106116001)(31966008)(4396001)(97736003)(86612001)(85852003)(110136001)(80022003)(44976005)(85806002)(46406003)(68736004)(19580395003)(107046002)(84676001)(92726001)(230783001)(69596002)(6806004)(76176999)(19580405001)(23726002)(2656002)(99396003)(33656002)(20776003)(86362001)(55846006)(92566001)(50986999)(64706001)(54356999)(46102003)(26826002)(120916001)(104016003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1202; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1202; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 035748864E Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/9FxvCC86qQ9oGyjXH8xSt96EVqI Cc: "oauth-chairs@tools.ietf.org" , "oauth@ietf.org" , The IESG , "draft-ietf-oauth-json-web-token@tools.ietf.org" Subject: Re: [OAUTH-WG] Ted Lemon's No Objection on draft-ietf-oauth-json-web-token-27: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 05:30:48 -0000 > -----Original Message----- > From: Ted Lemon [mailto:Ted.Lemon@nominum.com] > Sent: Monday, October 06, 2014 12:49 PM > To: Mike Jones > Cc: The IESG; oauth-chairs@tools.ietf.org; draft-ietf-oauth-json-web- > token@tools.ietf.org; oauth@ietf.org > Subject: Re: Ted Lemon's No Objection on draft-ietf-oauth-json-web-token-= 27: > (with COMMENT) >=20 > On Oct 6, 2014, at 3:54 AM, Mike Jones > wrote: > > Sometimes authenticated encryption alone is good enough without requiri= ng a > signature. Different applications will have different requirements. So = while this > section discussion the applicable considerations, the working group felt = that it > was going too far to make this prescriptive. >=20 > But if you don't need to sign the message, why sign it? The working group isn't advocating signing the token if it's not necessary.= The clause we're discussing is just intended to provide guidance to appli= cation architects in the case that both signing and encryption are necessar= y. I propose that we add language about "If both signing and encryption are ne= cessary" in order to make the context of this advice clear. Would that res= olution be acceptable to you, Ted? -- Mike From nobody Tue Oct 7 07:27:12 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0741ACDBE; Tue, 7 Oct 2014 07:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FYQhoM0w7DM0; Tue, 7 Oct 2014 07:27:09 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D48BE1A6F86; Tue, 7 Oct 2014 07:26:49 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 744091B8184; Tue, 7 Oct 2014 07:26:49 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 59D4653E070; Tue, 7 Oct 2014 07:26:49 -0700 (PDT) Received: from [10.0.10.40] (71.233.43.215) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 7 Oct 2014 07:26:49 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439BAF362F@TK5EX14MBXC286.redmond.corp.microsoft.com> Date: Tue, 7 Oct 2014 10:26:46 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <055A0022-9C9D-4D15-865F-0379BD75E938@nominum.com> References: <20141002135827.27947.4504.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739439BAF0C41@TK5EX14MBXC286.redmond.corp.microsoft.com> <0DB7566C-CEFD-49E3-AD23-83E4EE5C1D01@nominum.com> <4E1F6AAD24975D4BA5B16804296739439BAF362F@TK5EX14MBXC286.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/uy9GlqWy7f4WFcsXm_vRf-19eTc Cc: "oauth-chairs@tools.ietf.org" , "oauth@ietf.org" , The IESG , "draft-ietf-oauth-json-web-token@tools.ietf.org" Subject: Re: [OAUTH-WG] Ted Lemon's No Objection on draft-ietf-oauth-json-web-token-27: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 14:27:11 -0000 On Oct 7, 2014, at 1:29 AM, Mike Jones = wrote: > I propose that we add language about "If both signing and encryption = are necessary" in order to make the context of this advice clear. Would = that resolution be acceptable to you, Ted? So you're saying that if signing and encryption are necessary, signing = before encrypting is RECOMMENDED because of the attacks you described? = I guess I'm okay with that. From nobody Tue Oct 7 07:57:17 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 506361ACDFB for ; Tue, 7 Oct 2014 07:57:13 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uy-hDm9bjejA for ; Tue, 7 Oct 2014 07:57:11 -0700 (PDT) Received: from mail-qc0-f178.google.com (mail-qc0-f178.google.com [209.85.216.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BA2B1ACDF8 for ; Tue, 7 Oct 2014 07:57:11 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id c9so5774689qcz.23 for ; Tue, 07 Oct 2014 07:57:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=KFLN9rwiVbQEnPcTWqN9tvJOB52Z+ZCmC0sBJzgxfjk=; b=aLeSQSptNrkIUa9ehMcewyLAC87U33aLzkIGdXkySez5rsufem/UkPMkVxcoyUZqsF eom/XxkcObU2TYv6IvDNQXtSJunTx8caJDTvuHSrDJazH9BTJkCdHwV2XcNWglqUm5rD +2zAJxJnpwYYE7ncs17mSbQgj3ry00TQ5qFdP3Vo1mdhiHNQqDORnH/X3KkjVvrI57/b QqiPOOckUEduf6LGcgOe/3TENZuw+748X4iZ6m5k9YLm8GRPnVTinuZ1JScIEPX4mG/r qwy6/kXSJfdllPhvP0w/4VcPFcLg8wVSB2YeAfy9FYINo41lkc4y88ZC6Yvy/QnhbSfk szaQ== X-Gm-Message-State: ALoCoQkfdk10+UsqOS2grQ6dHz7tzu2dLzwOpQciuz9a2ToyL7ytV/va9VxanmI9PPTAyKLJ+xGY X-Received: by 10.229.236.8 with SMTP id ki8mr4976987qcb.12.1412693830507; Tue, 07 Oct 2014 07:57:10 -0700 (PDT) Received: from [192.168.1.216] (186-79-68-234.baf.movistar.cl. [186.79.68.234]) by mx.google.com with ESMTPSA id l5sm14985895qai.20.2014.10.07.07.57.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 Oct 2014 07:57:09 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Bradley In-Reply-To: <055A0022-9C9D-4D15-865F-0379BD75E938@nominum.com> Date: Tue, 7 Oct 2014 11:57:04 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <9CEAAB3D-211B-4401-8C7A-F7BCAFA1E9D7@ve7jtb.com> References: <20141002135827.27947.4504.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739439BAF0C41@TK5EX14MBXC286.redmond.corp.microsoft.com> <0DB7566C-CEFD-49E3-AD23-83E4EE5C1D01@nominum.com> <4E1F6AAD24975D4BA5B16804296739439BAF362F@TK5EX14MBXC286.redmond.corp.microsoft.com> <055A0022-9C9D-4D15-865F-0379BD75E938@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/LQk8e4JMSMsxkNjstPSFv57iPJk Cc: "oauth-chairs@tools.ietf.org" , "oauth@ietf.org" , The IESG , "draft-ietf-oauth-json-web-token@tools.ietf.org" Subject: Re: [OAUTH-WG] Ted Lemon's No Objection on draft-ietf-oauth-json-web-token-27: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 14:57:13 -0000 In XMLdsig if you are using a non AEAD encryption algorithm, you may = well need to sign over the encrypted information to protect it from = modification. In SAML some people sign the assertion, encrypt the assertion, and then = sign the message. The main reason for signing inside the encryption, tends to be legal in = that a signature over something you can't see is not considered = enforceable most places. So if you are signing for non repudiation then inside the encryption is = typically required. As JOSE only supports AEAD encryption over-signing to protect the = encrypted message from tampering is not required. So if you require both signing to identify the sender and encryption for = confidentiality then sign and then encrypt is the best bet.=20 On the other hand we can't preclude other valid use cases if someone = needs to encrypt and then sign so that perhaps intermediate hops can = validate the signature. That is why it is should and not must. Regards John B. On Oct 7, 2014, at 11:26 AM, Ted Lemon wrote: > On Oct 7, 2014, at 1:29 AM, Mike Jones = wrote: >> I propose that we add language about "If both signing and encryption = are necessary" in order to make the context of this advice clear. Would = that resolution be acceptable to you, Ted? >=20 > So you're saying that if signing and encryption are necessary, signing = before encrypting is RECOMMENDED because of the attacks you described? = I guess I'm okay with that. >=20 From nobody Tue Oct 7 09:13:31 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 872481A6F0D; Tue, 7 Oct 2014 09:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TuWXj8U5NwkZ; Tue, 7 Oct 2014 09:13:26 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CEF61A0299; Tue, 7 Oct 2014 09:13:26 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id DECAD1B81B7; Tue, 7 Oct 2014 09:13:25 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id BAFBD53E070; Tue, 7 Oct 2014 09:13:25 -0700 (PDT) Received: from [10.0.10.40] (71.233.43.215) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 7 Oct 2014 09:13:25 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <9CEAAB3D-211B-4401-8C7A-F7BCAFA1E9D7@ve7jtb.com> Date: Tue, 7 Oct 2014 12:13:22 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <0F38FF48-E749-427A-BBDB-4048FC9A3AEA@nominum.com> References: <20141002135827.27947.4504.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739439BAF0C41@TK5EX14MBXC286.redmond.corp.microsoft.com> <0DB7566C-CEFD-49E3-AD23-83E4EE5C1D01@nominum.com> <4E1F6AAD24975D4BA5B16804296739439BAF362F@TK5EX14MBXC286.redmond.corp.microsoft.com> <055A0022-9C9D-4D15-865F-0379BD75E938@nominum.com> <9CEAAB3D-211B-4401-8C7A-F7BCAFA1E9D7@ve7jtb.com> To: John Bradley X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/QLE8IYd9Kv6McbJo3fXGkY721yU Cc: The IESG , "draft-ietf-oauth-json-web-token@tools.ietf.org" , "oauth-chairs@tools.ietf.org" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Ted Lemon's No Objection on draft-ietf-oauth-json-web-token-27: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 16:13:27 -0000 On Oct 7, 2014, at 10:57 AM, John Bradley wrote: > The main reason for signing inside the encryption, tends to be legal = in that a signature over something you can't see is not considered = enforceable most places. > So if you are signing for non repudiation then inside the encryption = is typically required. The document currently warns that if the signature is not encrypted, it = would be possible to encrypt the message, sign it, and then an MiTM = could strip the signature. This seems to contradict what you are = saying here. Not being an expert, I am probably missing something, but = what you actually recommend should be consistent; if in fact in the = scenario you are talking about the stripping of the signature wouldn't = buy the attacker anything, you should say so. To be clear, what I am asking for is just that the document make sense = to someone who doesn't know all the properties of all the crypto = algorithms. Based on what I've heard so far, I'm not suggesting that = you need to add any new requirements. And I'm just asking, so if I'm = really talking through my hat, you are free to just ignore me! :) From nobody Tue Oct 7 10:15:24 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4119D1A7014 for ; Tue, 7 Oct 2014 10:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.254 X-Spam-Level: X-Spam-Status: No, score=-1.254 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 INzYLMuzETWk for ; Tue, 7 Oct 2014 10:15:21 -0700 (PDT) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E43C51A7017 for ; Tue, 7 Oct 2014 10:15:09 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id i17so6086121qcy.41 for ; Tue, 07 Oct 2014 10:15:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=YJY1Lo95zBrPTkSpv3VedpNL/R2ZfY7x53TeyGeXAoA=; b=k33HetsvMbnUndGSG1GX56PdCb+g/Yu23YD9yO8IaLmYhrSmkEwRcxaaMTDLaBG3rv xBUoPCjLFuI85MWvTv0f5niRUKWgHlfKpb7Erw7r7vGWGYcxYeYA8NmOCiZ5ZymaIUQY ACKVCfmDrQgaswo4oixbq0sneKRY1XLPwH+IKxGMC1In3xTZmEtPSQpC1pCWb2RkfWQO 59mLtWOlAh45SraDtratGKE25FaOQX2fPy0SUL/Xlb+Fx8aHFG0CDUfh5LV0u8jkliSN MlqfwzikNmra6tM8qh+OXvkk9bHY1Hx7oKltn9DFntZc6gJWz70BE9OUx6M5tVLJviEU AMPQ== X-Gm-Message-State: ALoCoQmo5w6I3Z+HKywfask5a6+h1fzp8o7zPztAttZZeF6YQ4ZKS9A8gFsEktIqbO9d5dKc54Rv X-Received: by 10.224.79.67 with SMTP id o3mr4778801qak.103.1412702109014; Tue, 07 Oct 2014 10:15:09 -0700 (PDT) Received: from [192.168.1.216] (186-106-128-238.baf.movistar.cl. [186.106.128.238]) by mx.google.com with ESMTPSA id g5sm15200587qaz.39.2014.10.07.10.14.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 Oct 2014 10:15:08 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Bradley In-Reply-To: <0F38FF48-E749-427A-BBDB-4048FC9A3AEA@nominum.com> Date: Tue, 7 Oct 2014 14:14:48 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <99D20D7F-0EEE-41B3-9FF3-C75F85BEED56@ve7jtb.com> References: <20141002135827.27947.4504.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739439BAF0C41@TK5EX14MBXC286.redmond.corp.microsoft.com> <0DB7566C-CEFD-49E3-AD23-83E4EE5C1D01@nominum.com> <4E1F6AAD24975D4BA5B16804296739439BAF362F@TK5EX14MBXC286.redmond.corp.microsoft.com> <055A0022-9C9D-4D15-865F-0379BD75E938@nominum.com> <9CEAAB3D-211B-4401-8C7A-F7BCAFA1E9D7@ve7jtb.com> <0F38FF48-E749-427A-BBDB-4048FC9A3AEA@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/2dVgml5K6OuKaLG3tOUr6RU4aF4 Cc: The IESG , "draft-ietf-oauth-json-web-token@tools.ietf.org" , "oauth-chairs@tools.ietf.org" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Ted Lemon's No Objection on draft-ietf-oauth-json-web-token-27: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 17:15:22 -0000 Section 11.2 makes both points. Encrypting and then signing is likely only a special case used by some = applications that are configured to understand what is going on. =20 If you are going to do it in that order you would want to be certain = that you don't accept a JWT that has no signature. Stripping a signature shouldn't buy an attacker anything with a properly = configured recipient. However it might possibly confuse some = application logic. We are making a best practice recommendation in 11.2 but there are = circumstances where it might make sense for a application to do = something else. John B. In general any asymmetric On Oct 7, 2014, at 1:13 PM, Ted Lemon = wrote: > On Oct 7, 2014, at 10:57 AM, John Bradley wrote: >> The main reason for signing inside the encryption, tends to be legal = in that a signature over something you can't see is not considered = enforceable most places. >> So if you are signing for non repudiation then inside the encryption = is typically required. >=20 > The document currently warns that if the signature is not encrypted, = it would be possible to encrypt the message, sign it, and then an MiTM = could strip the signature. This seems to contradict what you are = saying here. Not being an expert, I am probably missing something, but = what you actually recommend should be consistent; if in fact in the = scenario you are talking about the stripping of the signature wouldn't = buy the attacker anything, you should say so. >=20 > To be clear, what I am asking for is just that the document make sense = to someone who doesn't know all the properties of all the crypto = algorithms. Based on what I've heard so far, I'm not suggesting that = you need to add any new requirements. And I'm just asking, so if I'm = really talking through my hat, you are free to just ignore me! :) >=20 From nobody Tue Oct 7 10:30:07 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 374391A7028; Tue, 7 Oct 2014 10:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27-70br9PDr3; Tue, 7 Oct 2014 10:30:03 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 905861A7002; Tue, 7 Oct 2014 10:30:03 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 642F31B81BA; Tue, 7 Oct 2014 10:30:03 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 4133B53E070; Tue, 7 Oct 2014 10:30:03 -0700 (PDT) Received: from [10.0.10.40] (71.233.43.215) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 7 Oct 2014 10:30:02 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <99D20D7F-0EEE-41B3-9FF3-C75F85BEED56@ve7jtb.com> Date: Tue, 7 Oct 2014 13:30:00 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <48C989BE-6EAB-4EFE-A354-1F56F51B6F24@nominum.com> References: <20141002135827.27947.4504.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739439BAF0C41@TK5EX14MBXC286.redmond.corp.microsoft.com> <0DB7566C-CEFD-49E3-AD23-83E4EE5C1D01@nominum.com> <4E1F6AAD24975D4BA5B16804296739439BAF362F@TK5EX14MBXC286.redmond.corp.microsoft.com> <055A0022-9C9D-4D15-865F-0379BD75E938@nominum.com> <9CEAAB3D-211B-4401-8C7A-F7BCAFA1E9D7@ve7jtb.com> <0F38FF48-E749-427A-BBDB-4048FC9A3AEA@nominum.com> <99D20D7F-0EEE-41B3-9FF3-C75F85BEED56@ve7jtb.com> To: John Bradley X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/wh7rNtL2M5wZSQrBa9jXE4bRr9U Cc: "oauth-chairs@tools.ietf.org" , "oauth@ietf.org" , The IESG , "draft-ietf-oauth-json-web-token@tools.ietf.org" Subject: Re: [OAUTH-WG] Ted Lemon's No Objection on draft-ietf-oauth-json-web-token-27: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 17:30:05 -0000 On Oct 7, 2014, at 1:14 PM, John Bradley wrote: > Encrypting and then signing is likely only a special case used by some = applications that are configured to understand what is going on.=20 This isn't really responsive to what I said. As I said, I'm just = asking you to be consistent, not to change the requirements. I don't = think that text in the security considerations section addresses the = inconsistency I'm talking about in a different section. That said, = please don't continue to talk to me about this. If you think there's = an action to take, take it. If not, no need to continue trying to = explain. I'm okay with it either way. From nobody Tue Oct 7 18:07:23 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73B7F1A8AD3; Tue, 7 Oct 2014 18:07:18 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L02DVYQNdbSM; Tue, 7 Oct 2014 18:07:16 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0145.outbound.protection.outlook.com [207.46.100.145]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 170361A8AD6; Tue, 7 Oct 2014 18:07:16 -0700 (PDT) Received: from DM2PR03CA0034.namprd03.prod.outlook.com (10.141.96.33) by DM2PR0301MB1213.namprd03.prod.outlook.com (25.160.219.154) with Microsoft SMTP Server (TLS) id 15.0.1044.10; Wed, 8 Oct 2014 01:07:15 +0000 Received: from BL2FFO11FD053.protection.gbl (2a01:111:f400:7c09::185) by DM2PR03CA0034.outlook.office365.com (2a01:111:e400:2428::33) with Microsoft SMTP Server (TLS) id 15.0.1044.10 via Frontend Transport; Wed, 8 Oct 2014 01:07:15 +0000 Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD053.mail.protection.outlook.com (10.173.161.181) with Microsoft SMTP Server (TLS) id 15.0.1039.16 via Frontend Transport; Wed, 8 Oct 2014 01:07:14 +0000 Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.93]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.03.0210.003; Wed, 8 Oct 2014 01:06:07 +0000 From: Mike Jones To: Ted Lemon , John Bradley Thread-Topic: Ted Lemon's No Objection on draft-ietf-oauth-json-web-token-27: (with COMMENT) Thread-Index: AQHP3kj4EDDmiynllUmOKg/KYNPHJpwiUwtQgAEtdQCAAKFaoIAAlwYAgAAIdwCAABVSAIAAESoAgAAEPwCAAH73EA== Date: Wed, 8 Oct 2014 01:06:06 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439BAF5BE4@TK5EX14MBXC286.redmond.corp.microsoft.com> References: <20141002135827.27947.4504.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739439BAF0C41@TK5EX14MBXC286.redmond.corp.microsoft.com> <0DB7566C-CEFD-49E3-AD23-83E4EE5C1D01@nominum.com> <4E1F6AAD24975D4BA5B16804296739439BAF362F@TK5EX14MBXC286.redmond.corp.microsoft.com> <055A0022-9C9D-4D15-865F-0379BD75E938@nominum.com> <9CEAAB3D-211B-4401-8C7A-F7BCAFA1E9D7@ve7jtb.com> <0F38FF48-E749-427A-BBDB-4048FC9A3AEA@nominum.com> <99D20D7F-0EEE-41B3-9FF3-C75F85BEED56@ve7jtb.com> <48C989BE-6EAB-4EFE-A354-1F56F51B6F24@nominum.com> In-Reply-To: <48C989BE-6EAB-4EFE-A354-1F56F51B6F24@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(51704005)(189002)(377454003)(43784003)(199003)(13464003)(24454002)(104016003)(77096002)(2656002)(87936001)(85806002)(97736003)(46406003)(92726001)(31966008)(66066001)(76176999)(54356999)(46102003)(92566001)(85852003)(80022003)(97756001)(84676001)(55846006)(86362001)(20776003)(50986999)(44976005)(47776003)(6806004)(68736004)(19580395003)(69596002)(33656002)(86612001)(23726002)(4396001)(106466001)(120916001)(106116001)(26826002)(21056001)(99396003)(19580405001)(107046002)(64706001)(95666004)(85306004)(76482002)(81156004)(93886004)(50466002)(230783001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB1213; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB1213; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0358535363 Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/a-ARACgX4aeInATtqTaJOeHC69g Cc: "oauth-chairs@tools.ietf.org" , "oauth@ietf.org" , The IESG , "draft-ietf-oauth-json-web-token@tools.ietf.org" Subject: Re: [OAUTH-WG] Ted Lemon's No Objection on draft-ietf-oauth-json-web-token-27: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 01:07:18 -0000 > -----Original Message----- > From: Ted Lemon [mailto:Ted.Lemon@nominum.com] > Sent: Tuesday, October 07, 2014 10:30 AM > To: John Bradley > Cc: The IESG; Mike Jones; draft-ietf-oauth-json-web-token@tools.ietf.org; > oauth-chairs@tools.ietf.org; oauth@ietf.org > Subject: Re: Ted Lemon's No Objection on draft-ietf-oauth-json-web-token-= 27: > (with COMMENT) >=20 > On Oct 7, 2014, at 1:14 PM, John Bradley wrote: > > Encrypting and then signing is likely only a special case used by some > applications that are configured to understand what is going on. >=20 > This isn't really responsive to what I said. As I said, I'm just asking= you to be > consistent, not to change the requirements. I don't think that text in = the > security considerations section addresses the inconsistency I'm talking a= bout in a > different section. That said, please don't continue to talk to me about= this. If > you think there's an action to take, take it. If not, no need to contin= ue trying to > explain. I'm okay with it either way. I'll plan to take the action described yesterday that you said you were OK = with - adding language about "If both signing and encryption are necessary"= in order to make the context of this advice clear. I believe that that wi= ll improve the understanding of this guidance by many readers. Thanks again for the discussion, Ted. -- Mike From nobody Tue Oct 7 18:26:03 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79E631A8AE0; Tue, 7 Oct 2014 18:25: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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vtzR-EVJeghT; Tue, 7 Oct 2014 18:25:56 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B2361A88CF; Tue, 7 Oct 2014 18:25:55 -0700 (PDT) Received: by mail-la0-f48.google.com with SMTP id gi9so7353912lab.7 for ; Tue, 07 Oct 2014 18:25:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Mxv0b/Exsxo5kAXPAEx/xoR0nIBbJUz5x7bbslnfeic=; b=zim7ziESkKWgFO7DDe7cHgYctWUPhy/1BilJFOK5+D90szVsBiT+ZrDvNIcapM7Fe4 Ux1xOdXHQJSsv7jm95y9KEtHwdK+DmiHj8ktMYV3ha7HkEYwZ2b3Uz5ePbpq4fOVNkuE ggp4qCXz9dr6QWv74GoI/VBg5NSRsjY44mbsiU8GaO5/ra+qbtBOEMdnozrPmgDI+Dh5 GU4jl/Mh8no8Add+COPFSUCard9FAZewxM3KuOe1yW5n7dspPcCyJCdnUmVdzaJXvg3g Mjf1XKcoIpKZ8+qos0kE3qUHPOeYeTs9ZQ9anCSucie3lRCsKsMfXhJRQ+Kx3MAx1dBB OpkQ== MIME-Version: 1.0 X-Received: by 10.112.83.235 with SMTP id t11mr75629lby.101.1412731554380; Tue, 07 Oct 2014 18:25:54 -0700 (PDT) Received: by 10.112.95.36 with HTTP; Tue, 7 Oct 2014 18:25:54 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439BAF5BE4@TK5EX14MBXC286.redmond.corp.microsoft.com> References: <20141002135827.27947.4504.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739439BAF0C41@TK5EX14MBXC286.redmond.corp.microsoft.com> <0DB7566C-CEFD-49E3-AD23-83E4EE5C1D01@nominum.com> <4E1F6AAD24975D4BA5B16804296739439BAF362F@TK5EX14MBXC286.redmond.corp.microsoft.com> <055A0022-9C9D-4D15-865F-0379BD75E938@nominum.com> <9CEAAB3D-211B-4401-8C7A-F7BCAFA1E9D7@ve7jtb.com> <0F38FF48-E749-427A-BBDB-4048FC9A3AEA@nominum.com> <99D20D7F-0EEE-41B3-9FF3-C75F85BEED56@ve7jtb.com> <48C989BE-6EAB-4EFE-A354-1F56F51B6F24@nominum.com> <4E1F6AAD24975D4BA5B16804296739439BAF5BE4@TK5EX14MBXC286.redmond.corp.microsoft.com> Date: Tue, 7 Oct 2014 21:25:54 -0400 Message-ID: From: Kathleen Moriarty To: Mike Jones Content-Type: multipart/alternative; boundary=001a113460ce763fdd0504df3296 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/AlIebwKr-4J45NxApHVfvkNYFes Cc: Ted Lemon , "oauth-chairs@tools.ietf.org" , "draft-ietf-oauth-json-web-token@tools.ietf.org" , "oauth@ietf.org" , The IESG Subject: Re: [OAUTH-WG] Ted Lemon's No Objection on draft-ietf-oauth-json-web-token-27: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 01:25:59 -0000 --001a113460ce763fdd0504df3296 Content-Type: text/plain; charset=UTF-8 Thank you, both! I'm glad to see this one resolved. FYI - I'll be at the Grace Hopper Celebration through Friday evening and may be slow to respond, but will be following along. On Tue, Oct 7, 2014 at 9:06 PM, Mike Jones wrote: > > -----Original Message----- > > From: Ted Lemon [mailto:Ted.Lemon@nominum.com] > > Sent: Tuesday, October 07, 2014 10:30 AM > > To: John Bradley > > Cc: The IESG; Mike Jones; draft-ietf-oauth-json-web-token@tools.ietf.org > ; > > oauth-chairs@tools.ietf.org; oauth@ietf.org > > Subject: Re: Ted Lemon's No Objection on > draft-ietf-oauth-json-web-token-27: > > (with COMMENT) > > > > On Oct 7, 2014, at 1:14 PM, John Bradley wrote: > > > Encrypting and then signing is likely only a special case used by some > > applications that are configured to understand what is going on. > > > > This isn't really responsive to what I said. As I said, I'm just > asking you to be > > consistent, not to change the requirements. I don't think that text in > the > > security considerations section addresses the inconsistency I'm talking > about in a > > different section. That said, please don't continue to talk to me > about this. If > > you think there's an action to take, take it. If not, no need to > continue trying to > > explain. I'm okay with it either way. > > I'll plan to take the action described yesterday that you said you were OK > with - adding language about "If both signing and encryption are necessary" > in order to make the context of this advice clear. I believe that that > will improve the understanding of this guidance by many readers. > > Thanks again for the discussion, Ted. > > -- Mike > > -- Best regards, Kathleen --001a113460ce763fdd0504df3296 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you, both! I'm glad to see this one resolved.
FYI - I'll be at the Grace Hopper Celebration through = Friday evening and may be slow to respond, but will be following along.

On Tue, O= ct 7, 2014 at 9:06 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
>= ; -----Original Message-----
> From: Ted Lemon [mailto:Ted.L= emon@nominum.com]
> Sent: Tuesday, October 07, 2014 10:30 AM
> To: John Bradley
> Cc: The IESG; Mike Jones; draft-ietf-oauth-json-web-token@tools.ietf.org; > oauth-chairs@tools.ietf= .org; oauth@ietf.org
> Subject: Re: Ted Lemon's No Objection on draft-ietf-oauth-json-web= -token-27:
> (with COMMENT)
>
> On Oct 7, 2014, at 1:14 PM, John Bradley= <ve7jtb@ve7jtb.com> wrote:<= br> > > Encrypting and then signing is likely only a special case used by= some
> applications that are configured to understand what is going on.
>
> This isn't really responsive to what I said.=C2=A0 =C2=A0As I said= , I'm just asking you to be
> consistent, not to change the requirements.=C2=A0 =C2=A0I don't th= ink that text in the
> security considerations section addresses the inconsistency I'm ta= lking about in a
> different section.=C2=A0 =C2=A0That said, please don't continue to= talk to me about this.=C2=A0 =C2=A0If
> you think there's an action to take, take it.=C2=A0 =C2=A0If not, = no need to continue trying to
> explain.=C2=A0 =C2=A0I'm okay with it either way.

I'll plan to take the action described yesterday that you s= aid you were OK with - adding language about "If both signing and encr= yption are necessary" in order to make the context of this advice clea= r.=C2=A0 I believe that that will improve the understanding of this guidanc= e by many readers.

Thanks again for the discussion, Ted.

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




--

Best regards,
Kathleen
--001a113460ce763fdd0504df3296-- From nobody Tue Oct 7 18:30:52 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 814741A8AE5; Tue, 7 Oct 2014 18:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uK6VfOoQeSlp; Tue, 7 Oct 2014 18:30:50 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FE7B1A8AE1; Tue, 7 Oct 2014 18:30:50 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 66C0C1B81B4; Tue, 7 Oct 2014 18:30:50 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 5A02C53E070; Tue, 7 Oct 2014 18:30:50 -0700 (PDT) Received: from [10.0.10.40] (71.233.43.215) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 7 Oct 2014 18:30:38 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439BAF5BE4@TK5EX14MBXC286.redmond.corp.microsoft.com> Date: Tue, 7 Oct 2014 21:30:34 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <0F067F91-8088-4E49-872C-E9A365BEE717@nominum.com> References: <20141002135827.27947.4504.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739439BAF0C41@TK5EX14MBXC286.redmond.corp.microsoft.com> <0DB7566C-CEFD-49E3-AD23-83E4EE5C1D01@nominum.com> <4E1F6AAD24975D4BA5B16804296739439BAF362F@TK5EX14MBXC286.redmond.corp.microsoft.com> <055A0022-9C9D-4D15-865F-0379BD75E938@nominum.com> <9CEAAB3D-211B-4401-8C7A-F7BCAFA1E9D7@ve7jtb.com> <0F38FF48-E749-427A-BBDB-4048FC9A3AEA@nominum.com> <99D20D7F-0EEE-41B3-9FF3-C75F85BEED56@ve7jtb.com> <48C989BE-6EAB-4EFE-A354-1F56F51B6F24@nominum.com> <4E1F6AAD24975D4BA5B16804296739439BAF5BE4@TK5EX14MBXC286.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/3ylKLpXgjXnKjGnGmjcKg2dxtug Cc: "oauth-chairs@tools.ietf.org" , "oauth@ietf.org" , The IESG , "draft-ietf-oauth-json-web-token@tools.ietf.org" Subject: Re: [OAUTH-WG] Ted Lemon's No Objection on draft-ietf-oauth-json-web-token-27: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 01:30:51 -0000 On Oct 7, 2014, at 9:06 PM, Mike Jones = wrote: > I'll plan to take the action described yesterday that you said you = were OK with - adding language about "If both signing and encryption are = necessary" in order to make the context of this advice clear. I believe = that that will improve the understanding of this guidance by many = readers. Sounds good, thanks! It's hard to keep track of the discussion once = the review is done... :) From nobody Thu Oct 9 06:35:40 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B1B91ACE77 for ; Thu, 9 Oct 2014 06:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.553 X-Spam-Level: X-Spam-Status: No, score=0.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 eim_7QiYY38g for ; Thu, 9 Oct 2014 06:35:23 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0615.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:615]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 981E01ACE6A for ; Thu, 9 Oct 2014 06:35:22 -0700 (PDT) Received: from CO1PR02MB206.namprd02.prod.outlook.com (10.242.165.144) by CO1PR02MB207.namprd02.prod.outlook.com (10.242.165.145) with Microsoft SMTP Server (TLS) id 15.0.1044.10; Thu, 9 Oct 2014 13:34:58 +0000 Received: from CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.31]) by CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.217]) with mapi id 15.00.1044.008; Thu, 9 Oct 2014 13:34:58 +0000 From: Antonio Sanso To: "oauth@ietf.org" Thread-Topic: [OAUTH-WG] open redirect in rfc6749 Thread-Index: AQHPx43Iqm72AKs/tk+aoXIbGajW5JvvlAWAgAABL4CAAAjogIAAAV6AgAABUQCAAAP4AIAAARkAgAAHYQCAAAO5AIAAwV0AgAAbbICAAAwBgIAAAPwAgABUVwCAAAJ4AIAAA+OAgBGs+4CAAAiDgIAABXsAgAAL1wCAAAKvgIAABlQAgAALdQCAALv0gIAAXHgAgCQT1QA= Date: Thu, 9 Oct 2014 13:34:58 +0000 Message-ID: References: <756EEB25-89E8-4445-9DA0-5522787D51AB@adobe.com> <25055629-26A9-478D-AE7A-3C295E3166EE@adobe.com> <54074B7A.7080907@pingidentity.com> <43A8E8A6-BA9B-4501-8CA3-28943236EADB@adobe.com> <54075296.9090007@pingidentity.com> <848F15BD-894D-48C6-B901-B5565BDE4C08@adobe.com> <05C25C09-598C-4D7F-A07A-C93DEC17D10B@adobe.com> <255386B5-79A1-4CD7-90E6-F3F6E23F51F8@mitre.org> <540818FD.1010202@pingidentity.com> <809F7DAB-021D-4770-9D7B-E996D0D32D45@adobe.com> <54086090.8080703@redhat.com> <342B1A81-7333-43D5-A8BC-5CBB31F7D354@adobe.com> <540865E5.5010808@pingidentity.com> <8B89E66C-B82B-41CB-819C-3E1C9B65A7BA@oracle.com> <5E650C1B-A3EC-49E0-9EC0-362B4957ECC1@ve7jtb.com> <100DA4A7-0E88-4BAC-AD2A-EF29A9C6A950@adobe.com> <29F9628D-EBD4-4C32-BD8B-4FC520ADAED0@ve7jtb.com> <54184BCC.6000101@redhat.com> In-Reply-To: <54184BCC.6000101@redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.147.117.11] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR02MB207; x-forefront-prvs: 0359162B6D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(51704005)(52604005)(24454002)(479174003)(189002)(51444003)(377454003)(199003)(80022003)(83716003)(31966008)(66066001)(2656002)(4396001)(46102003)(20776003)(82746002)(54356999)(64706001)(15975445006)(50986999)(19580405001)(122556002)(15974865002)(15202345003)(19580395003)(87936001)(110136001)(40100002)(107046002)(95666004)(99286002)(101416001)(2351001)(105586002)(107886001)(85306004)(106356001)(106116001)(93886004)(2501002)(77096002)(21056001)(85852003)(76482002)(97736003)(15395725005)(76176999)(587094003)(99396003)(16601075003)(92726001)(120916001)(33656002)(86362001)(92566001)(36756003)(104396001)(579004)(559001)(579124003); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR02MB207; H:CO1PR02MB206.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="Windows-1252" Content-ID: <8636F91C0FAA274BBD02DC945F94CDC7@namprd02.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/7lh7JqYr_bVYechDI1ohtSY0tMg Subject: Re: [OAUTH-WG] open redirect in rfc6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 13:35:27 -0000 hi again *, apologies to bother you again with this :), just wasn=92t really clear to = me if this is considered like =91solved=92 (namely the discussion is over, = no action to be taken) or we need still to discuss about this topic in orde= r to reach some sort of consensus :) regards antonio =20 On Sep 16, 2014, at 4:40 PM, Bill Burke wrote: > I'll reiterate what convinced me if it helps. >=20 > The danger was a matter of expectations. In Antonio's scenario, the user= is more likely to be expecting a login screen and thus more likely to be f= ooled by a login-screen spoof. Antonio's suggested changes don't break any= compatibility either, it just requires the AS to display an error page on = *any* parameter error instead of redirecting back. Something the spec alrea= dy requires for a bad client id. >=20 > On 9/16/2014 5:08 AM, Antonio Sanso wrote: >> Hi John, >>=20 >> agree that there are at two different things (as you pointed out below) = where we could spend some word and provide some advice. >>=20 >> To summarize: >>=20 >> - one is the 'open redirect=92 issue (net of semantic :), pointed by me,= where nothing is leaked >> - one is the leakage, pointed by John >>=20 >> Those two scenarios are different and might deserve to be discussed inde= pendently=85 :) >>=20 >=20 >> On Sep 15, 2014, at 11:56 PM, John Bradley wrote: >>=20 >>> Something might get leaked by the browser, the fragment may be leaked b= y the browser if the redirect URI doesn't contain a fragment in some browse= rs. >>>=20 >>> A simple security consideration might be to add a fragment to the redir= ect_uri in the error case. >>>=20 >>> The other way that information may leak is via the referrer. If there= is only one redirect by the AS the URI that was sent to the AS including a= ll the parameters would still be available to the target. >>> A simple fix is to redirect to a intermediate page before redirecting t= o the registered client, this clears the referrer. >>>=20 >>> It is true that nothing is leaked in the redirect_uri itself but there = are side channels in the browser that need to be considered. >>>=20 >>> The fixes are quite simple implementation issues and don't break anythi= ng. >>>=20 >>> Yes if the client is trusted then this is probably unnecessary but woul= dn't hurt anything. >>>=20 >>> John B. >>>=20 >>> PS for OAuth this would really only be exploitable if exact redirect_ur= i matching is not happening. >>>=20 >>> As I am a inherently bad person, I could hypothetically use this to att= ack a AS that is doing domain level pattern matching of redirect URI and ha= s a public client in the same domain as the AS. >>>=20 >>> I should also note that domains using pattern matching are also vulnera= ble if they allow other sorts of user hosted content like blog posts that p= ull in images and leak the referrer. >>=20 >> if somebody is curios about some real world attack this is one I perform= ed to Facebook that does exactly what John describes here http://intothesym= metry.blogspot.ch/2014/04/oauth-2-how-i-have-hacked-facebook.html >>=20 >> regards >>=20 >> antonio >>=20 >>>=20 >>> So we do probably need to provide some advice. >>>=20 >>> John B. >>>=20 >>> On Sep 15, 2014, at 6:15 PM, Richer, Justin P. wrot= e: >>>=20 >>>> As we discussed before: This isn't really an open redirection in the c= lassical sense since nothing gets leaked and the URI is tied back to a know= n (albeit malicious) client registration. And I thought the clear solution = was to have an AS not automatically redirect to an untrusted client in erro= r conditions, where "untrusted" is defined by the AS with guidance. If anyt= hing this is a security considerations addendum. >>>>=20 >>>> -- Justin >>>>=20 >>>> On Sep 15, 2014, at 4:52 PM, Antonio Sanso wrote: >>>>=20 >>>>> The problem is that a malicious client can register a malicious redir= ect uri and https://tools.ietf.org/html/rfc6749#section-4.1.2.1 does the re= st (as previously discussed) >>>>>=20 >>>>> regards >>>>>=20 >>>>> antonio >>>>>=20 >>>>> On Sep 15, 2014, at 10:43 PM, Phil Hunt wrote: >>>>>=20 >>>>>> If a server accepts a URL from a client to be used as a redirect tha= t the server doesn=92t recognize or is not registered, that is an open redi= rect. >>>>>>=20 >>>>>> The specification does no allow open-redirects, it considers this a = mis-configuration. >>>>>>=20 >>>>>> Take a look at sections 3.1.2.2 and 10.15 of RFC6749. >>>>>>=20 >>>>>> Phil >>>>>>=20 >>>>>> @independentid >>>>>> www.independentid.com >>>>>> phil.hunt@oracle.com >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On Sep 15, 2014, at 1:00 PM, John Bradley wrote: >>>>>>=20 >>>>>>> There may be a problem with semantics in this discussion. >>>>>>>=20 >>>>>>> There is a redirect performed by athe authorization endpoint to a f= ixed uri that is pre registered with the authorization server without user = prompting. >>>>>>>=20 >>>>>>> That probably doesn't fit the strict definition of a open redirecto= r. >>>>>>>=20 >>>>>>> It may however create similar security issues in situations with re= latively open registration of clients. >>>>>>>=20 >>>>>>> The largest issues are that the browser might leak information acro= ss the redirect in the fragment or referrer. That has been used in attacks= against Facebook in the past. >>>>>>>=20 >>>>>>> This is no where near the end of the world, however we need to loo= k at the security considerations and see if we can provide better advice to= implementors. In some cases returning a error to the browser may be best. >>>>>>>=20 >>>>>>> I don't think we need to go so far as not returning any error to th= e client under any circumstance. >>>>>>>=20 >>>>>>> John B. >>>>>>>=20 >>>>>>> Sent from my iPhone >>>>>>>=20 >>>>>>>> On Sep 15, 2014, at 4:41 PM, Phil Hunt wrot= e: >>>>>>>>=20 >>>>>>>> Simply not true. >>>>>>>>=20 >>>>>>>> Phil >>>>>>>>=20 >>>>>>>> @independentid >>>>>>>> www.independentid.com >>>>>>>> phil.hunt@oracle.com >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> On Sep 15, 2014, at 12:10 PM, Antonio Sanso wr= ote: >>>>>>>>>=20 >>>>>>>>> hi *, >>>>>>>>>=20 >>>>>>>>> my understanding is that there is a rough consensus that if an OA= uth Provider follows rfc6749 verbatim will end up having an open redirector= . >>>>>>>>> My next question would be now, is there anything we can do to rai= se some awareness about this issue? >>>>>>>>>=20 >>>>>>>>> regards >>>>>>>>>=20 >>>>>>>>> antonio >>>>>>>>>=20 >>>>>>>>>> On Sep 4, 2014, at 3:15 PM, Hans Zandbelt wrote: >>>>>>>>>>=20 >>>>>>>>>> I am convinced about the issue in the use case Antonio provided = but I hope not to close the door on returning errors to known and trusted c= lients. Not sure anymore if that's possible though because the distinction = can't be "registered"... >>>>>>>>>>=20 >>>>>>>>>> Hans. >>>>>>>>>>=20 >>>>>>>>>>> On 9/4/14, 3:01 PM, Antonio Sanso wrote: >>>>>>>>>>> hi Bill >>>>>>>>>>>> On Sep 4, 2014, at 2:52 PM, Bill Burke wro= te: >>>>>>>>>>>>=20 >>>>>>>>>>>> FWIW, Antonio convinced me and I'm going to change this in our= IDM project. Thanks Antonio. What convinced me was that the user is prob= ably expecting a login screen. Since there is this expectation, it might m= ake it a little easier for the attacker to convince the user that a spoofed= login screen is real. I know this issue can only happen with unrestricted= registration, but, IMO, this proposed change doesn't really have much of a= n effect on usability and is even backward compatible with the current RFC. >>>>>>>>>>>>=20 >>>>>>>>>>>> Wouldn't it better though to never do a redirect on an invalid= request and just display an error page? >>>>>>>>>>>=20 >>>>>>>>>>> thanks for sharing your thoughts :). Display an error 400 is wh= at Google does :) >>>>>>>>>>>=20 >>>>>>>>>>> regards >>>>>>>>>>>=20 >>>>>>>>>>> antonio >>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>> On 9/4/2014 3:50 AM, Antonio Sanso wrote: >>>>>>>>>>>>> Hi Hans, >>>>>>>>>>>>>=20 >>>>>>>>>>>>> I really fail to see how this can be addressed at registratio= n time for cases where registration is unrestricted (namely all the big Pro= viders) >>>>>>>>>>>>>=20 >>>>>>>>>>>>> regards >>>>>>>>>>>>>=20 >>>>>>>>>>>>> antonio >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On Sep 4, 2014, at 9:47 AM, Hans Zandbelt wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Classifying like this must also mean that consent should not= be stored until the client is considered (admin) trusted, and admin policy= would interfere with user policy. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> IMHO the security consideration would apply only to dynamica= lly registered clients where registration is unrestricted; any other form w= ould involve some form of admin/user approval at registration time, overcom= ing the concern at authorization time: there's no auto-redirect flow possib= le for unknown clients. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Hans. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> On 9/4/14, 9:04 AM, Richer, Justin P. wrote: >>>>>>>>>>>>>>> I think this advice isn't a bad idea, though it's of course= up to the AS >>>>>>>>>>>>>>> what an "untrusted" client really is. In practice, this is = something >>>>>>>>>>>>>>> that was registered by a non-sysadmin type person, either a= dynamically >>>>>>>>>>>>>>> registered client or something available through self-servi= ce >>>>>>>>>>>>>>> registration of some type. It's also reasonable that a clie= nt, even >>>>>>>>>>>>>>> dynamically registered, would be considered "trusted" if en= ough time has >>>>>>>>>>>>>>> passed and enough users have used it without things blowing= up. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> -- Justin >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> On Sep 4, 2014, at 1:26 AM, Antonio Sanso >>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> hi again *, >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> after thinking a bit further IMHO an alternative for the u= ntrusted >>>>>>>>>>>>>>>> clients can also be to always present the consent screen (= at least >>>>>>>>>>>>>>>> once) before any redirect. >>>>>>>>>>>>>>>> Namely all providers I have seen show the consent screen i= f all the >>>>>>>>>>>>>>>> request parameters are correct and if the user accepts the= redirect >>>>>>>>>>>>>>>> happens. >>>>>>>>>>>>>>>> If one of the parameter (with the exclusion of the client= id and >>>>>>>>>>>>>>>> redirect uri that are handled differently as for spec) is = wrong though >>>>>>>>>>>>>>>> the redirect happens without the consent screen being show= n.. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> WDYT? >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> regards >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> antonio >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> On Sep 3, 2014, at 7:54 PM, Antonio Sanso >>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> Well, >>>>>>>>>>>>>>>>> I do not know if this is only dynamic registration... >>>>>>>>>>>>>>>>> let=92s talk about real use cases, namely e.g. Google , F= acebook , >>>>>>>>>>>>>>>>> etc.. is that dynamic client registration? I do not know= =85 :) >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> Said that what the other guys think? :) >>>>>>>>>>>>>>>>> Would this deserve some =93spec adjustment=94 ? I mean th= ere is a reason >>>>>>>>>>>>>>>>> if Google is by choice =93violating=94 the spec right? (I= assume to avoid >>>>>>>>>>>>>>>>> open redirect=85) >>>>>>>>>>>>>>>>> But other implementers do follow the spec hence they have= this open >>>>>>>>>>>>>>>>> redirector=85 and this is not nice IMHO... >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> On Sep 3, 2014, at 7:40 PM, Hans Zandbelt >>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> On 9/3/14, 7:14 PM, Antonio Sanso wrote: >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt >>>>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> Is your concern clients that were registered using dyn= amic client >>>>>>>>>>>>>>>>>>>> registration? >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> yes >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> I think your issue is then with the trust model of dynam= ic client >>>>>>>>>>>>>>>>>> registration; that is left out of scope of the dynreg sp= ec (and the >>>>>>>>>>>>>>>>>> concept is not even part of the core spec), but unless y= ou want >>>>>>>>>>>>>>>>>> everything to be open (which typically would not be the = case), then >>>>>>>>>>>>>>>>>> it would involve approval somewhere in the process befor= e the client >>>>>>>>>>>>>>>>>> is registered. Without dynamic client registration that = approval is >>>>>>>>>>>>>>>>>> admin based or resource owner based, depending on use ca= se. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> Otherwise the positive case is returning a response to= a valid URL >>>>>>>>>>>>>>>>>>>> that belongs to a client that was registered explicitl= y by the >>>>>>>>>>>>>>>>>>>> resource owner >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> well AFAIK the resource owner doesn=92t register client= s=85 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> roles can collapse in use cases especially when using dy= namic client >>>>>>>>>>>>>>>>>> registration >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> and the negative case is returning an error to that sa= me URL. >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> the difference is the consent screen=85 in the positive= case you need >>>>>>>>>>>>>>>>>>> to approve an app.. for the error case no approval is n= eeded,,, >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> I fail to see the open redirect. >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> why? >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> because the client and thus the fixed URL are explicitly= approved at >>>>>>>>>>>>>>>>>> some point >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> Hans. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> Hans. >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> On 9/3/14, 6:56 PM, Antonio Sanso wrote: >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> On Sep 3, 2014, at 6:51 PM, Hans Zandbelt >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> Let me try and approach this from a different angle:= why would you >>>>>>>>>>>>>>>>>>>>>> call it an open redirect when an invalid scope is pr= ovided and >>>>>>>>>>>>>>>>>>>>>> call it >>>>>>>>>>>>>>>>>>>>>> correct protocol behavior (hopefully) when a valid s= cope is >>>>>>>>>>>>>>>>>>>>>> provided? >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> as specified below in the positive case (namely when = the correct >>>>>>>>>>>>>>>>>>>>> scope >>>>>>>>>>>>>>>>>>>>> is provided) the resource owner MUST approve the app = via the consent >>>>>>>>>>>>>>>>>>>>> screen (at least once). >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> Hans. >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>> On 9/3/14, 6:46 PM, Antonio Sanso wrote: >>>>>>>>>>>>>>>>>>>>>>> hi John, >>>>>>>>>>>>>>>>>>>>>>> On Sep 3, 2014, at 6:14 PM, John Bradley >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>> In the example the redirect_uri is vlid for the at= tacker. >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>> The issue is that the AS may be allowing client re= gistrations with >>>>>>>>>>>>>>>>>>>>>>>> arbitrary redirect_uri. >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>> In the spec it is unspecified how a AS validates t= hat a client >>>>>>>>>>>>>>>>>>>>>>>> controls the redirect_uri it is registering. >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>> I think that if anything it may be the registratio= n step that >>>>>>>>>>>>>>>>>>>>>>>> needs >>>>>>>>>>>>>>>>>>>>>>>> the security consideration. >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>> (this is the first time :p) but I do disagree with = you. It would be >>>>>>>>>>>>>>>>>>>>>>> pretty unpractical to block this at registration ti= me=85. >>>>>>>>>>>>>>>>>>>>>>> IMHO the best approach is the one taken from Google= , namely >>>>>>>>>>>>>>>>>>>>>>> returning >>>>>>>>>>>>>>>>>>>>>>> 400 with the cause of the error.. >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>> *400.* That=92s an error. >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>> *Error: invalid_scope* >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>> Some requested scopes were invalid. {invalid=3D[l]} >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>> said that I hope you all agree this is an issue in = the spec so >>>>>>>>>>>>>>>>>>>>>>> far=85. >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>> regards >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>> antonio >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>> John B. >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>> On Sep 3, 2014, at 12:10 PM, Bill Burke >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>> I don't understand. The redirect uri has to be v= alid in >>>>>>>>>>>>>>>>>>>>>>>>> order for a >>>>>>>>>>>>>>>>>>>>>>>>> redirect to happen. The spec explicitly states t= his. >>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>> On 9/3/2014 11:43 AM, Antonio Sanso wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> hi *, >>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>> IMHO providers that strictly follow rfc6749 are = vulnerable >>>>>>>>>>>>>>>>>>>>>>>>>> to open >>>>>>>>>>>>>>>>>>>>>>>>>> redirect. >>>>>>>>>>>>>>>>>>>>>>>>>> Let me explain, reading [0] >>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>> If the request fails due to a missing, invalid, = or mismatching >>>>>>>>>>>>>>>>>>>>>>>>>> redirection URI, or if the client identifier is = missing or >>>>>>>>>>>>>>>>>>>>>>>>>> invalid, >>>>>>>>>>>>>>>>>>>>>>>>>> the authorization server SHOULD inform the resou= rce owner of the >>>>>>>>>>>>>>>>>>>>>>>>>> error and MUST NOT automatically redirect the us= er-agent to the >>>>>>>>>>>>>>>>>>>>>>>>>> invalid redirection URI. >>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>> If the resource owner denies the access request = or if the >>>>>>>>>>>>>>>>>>>>>>>>>> request >>>>>>>>>>>>>>>>>>>>>>>>>> fails for reasons other than a missing or invali= d >>>>>>>>>>>>>>>>>>>>>>>>>> redirection URI, >>>>>>>>>>>>>>>>>>>>>>>>>> the authorization server informs the client by a= dding the >>>>>>>>>>>>>>>>>>>>>>>>>> following >>>>>>>>>>>>>>>>>>>>>>>>>> parameters to the query component of the redirec= tion URI >>>>>>>>>>>>>>>>>>>>>>>>>> using the >>>>>>>>>>>>>>>>>>>>>>>>>> "application/x-www-form-urlencoded" format, perA= ppendix B >>>>>>>>>>>>>>>>>>>>>>>>>> = : >>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>> Now let=92s assume this. >>>>>>>>>>>>>>>>>>>>>>>>>> I am registering a new client to thevictim.com >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> provider. >>>>>>>>>>>>>>>>>>>>>>>>>> I register redirect uriattacker.com >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >. >>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>> According to [0] if I pass e.g. the wrong scope = I am redirected >>>>>>>>>>>>>>>>>>>>>>>>>> back to >>>>>>>>>>>>>>>>>>>>>>>>>> attacker.com >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> >. >>>>>>>>>>>>>>>>>>>>>>>>>> Namely I prepare a url that is in this form: >>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>> http://victim.com/authorize?response_type=3Dcode= &client_id=3Dbc88FitX1298KPj2WS259BBMa9_KCfL3&scope=3DWRONG_SCOPE&redirect_= uri=3Dhttp://attacker.com >>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>> and this is works as an open redirector. >>>>>>>>>>>>>>>>>>>>>>>>>> Of course in the positive case if all the parame= ters are >>>>>>>>>>>>>>>>>>>>>>>>>> fine this >>>>>>>>>>>>>>>>>>>>>>>>>> doesn=92t apply since the resource owner MUST ap= prove the app >>>>>>>>>>>>>>>>>>>>>>>>>> via the >>>>>>>>>>>>>>>>>>>>>>>>>> consent screen (at least once). >>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>> A solution would be to return error 400 rather t= han redirect >>>>>>>>>>>>>>>>>>>>>>>>>> to the >>>>>>>>>>>>>>>>>>>>>>>>>> redirect URI (as some provider e.g. Google do) >>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>> WDYT? >>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>> regards >>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>> antonio >>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>> [0] https://tools.ietf.org/html/rfc6749#section-= 4.1.2.1 >>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>>>>> Bill Burke >>>>>>>>>>>>>>>>>>>>>>>>> JBoss, a division of Red Hat >>>>>>>>>>>>>>>>>>>>>>>>> http://bill.burkecentral.com >>>>>>>>>>>>>>>>>>>>>>>>>=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 >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>>>>>>>>>>> hzandbelt@pingidentity.com >>>>>>>>>>>>>>>>>>>>>> | Ping >>>>>>>>>>>>>>>>>>>>>> Identity >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>>>>>>>>> hzandbelt@pingidentity.com | >>>>>>>>>>>>>>>>>>>> Ping Identity >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>>>>>>> hzandbelt@pingidentity.com | Ping >>>>>>>>>>>>>>>>>> Identity >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>>> hzandbelt@pingidentity.com | Ping Identity >>>>>>>>>>>>>=20 >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>=20 >>>>>>>>>>>> -- >>>>>>>>>>>> Bill Burke >>>>>>>>>>>> JBoss, a division of Red Hat >>>>>>>>>>>> http://bill.burkecentral.com >>>>>>>>>>>>=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 >>>>>>>>>> -- >>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>> hzandbelt@pingidentity.com | Ping Identity >>>>>>>>>=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 >>>>>=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 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 > --=20 > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Fri Oct 10 14:37:16 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1D711AD430 for ; Fri, 10 Oct 2014 14:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VEN8Hg_zkMoC for ; Fri, 10 Oct 2014 14:37:12 -0700 (PDT) Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B0FA1A88B0 for ; Fri, 10 Oct 2014 14:37:12 -0700 (PDT) Received: by mail-vc0-f178.google.com with SMTP id hq12so3425904vcb.9 for ; Fri, 10 Oct 2014 14:37:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5zZfSuoIrCvWM62il/AIZiq0XssF3KSzPBMpDcp/PdY=; b=LcKFCreKzHsqE5An60ywtb5Zf7EpSjhMFuPJ/qeS1goB9/sEhZTZjinaKby+/XpYD2 AnjHZrrGo3Zee0emYaalGfrbF8RjrnmFj36lms+WhQTiTZoEwm45Z1dxPKbtwvM3gJaB QbfOL5c2iJPzFTAN/nOONlq064vZrkMkIltcHVmdHMdCcd/dTFV3RFPvFegClDIAaCpv qEp+/9ANgqbQ/fdOs6GUn17pQE6qE5clhqRFP0JHsGHyqOlh0CcLBedILQHLtYx15DzC O1rTbVYaYCO/2t592hNjVMBc6yCaX4qtzEc4iNWK5ELsHjdfYw6/i7KIS1xqBJdXtvTs Djbw== X-Gm-Message-State: ALoCoQlnGVBPQ8opvjc5RJbX0eipXEK4KmiqfkxC/a2kBUbN7dCkcDCFYjw9Ybk48AYw0fKqjOlm MIME-Version: 1.0 X-Received: by 10.221.34.73 with SMTP id sr9mr4604687vcb.45.1412977031580; Fri, 10 Oct 2014 14:37:11 -0700 (PDT) Received: by 10.31.134.17 with HTTP; Fri, 10 Oct 2014 14:37:11 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439BAF0C4E@TK5EX14MBXC286.redmond.corp.microsoft.com> References: <20141002025706.19368.2507.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739439BAF0C4E@TK5EX14MBXC286.redmond.corp.microsoft.com> Date: Fri, 10 Oct 2014 17:37:11 -0400 Message-ID: From: Richard Barnes To: Mike Jones Content-Type: multipart/alternative; boundary=001a113654800b20af0505185a6c Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/AnXHdHFVlhm4tSm9kFcupLvN33I Cc: "draft-ietf-oauth-json-web-token@tools.ietf.org" , "oauth-chairs@tools.ietf.org" , The IESG , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 21:37:14 -0000 --001a113654800b20af0505185a6c Content-Type: text/plain; charset=UTF-8 On Mon, Oct 6, 2014 at 3:54 AM, Mike Jones wrote: > Thanks for your review, Richard. My responses are inline below... > > > -----Original Message----- > > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Richard Barnes > > Sent: Wednesday, October 01, 2014 7:57 PM > > To: The IESG > > Cc: oauth-chairs@tools.ietf.org; oauth@ietf.org; > draft-ietf-oauth-json-web- > > token@tools.ietf.org > > Subject: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-json-web- > > token-27: (with DISCUSS and COMMENT) > > > > Richard Barnes has entered the following ballot position for > > draft-ietf-oauth-json-web-token-27: Discuss > > > > When responding, please keep the subject line intact and reply to all > email > > addresses included in the To and CC lines. (Feel free to cut this > introductory > > paragraph, however.) > > > > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > http://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > Section 7. > > In order to prevent confusion between secured and Unsecured JWTs, the > > validation steps here need to call for the application to specify which > is required. > > Per my response on your JWS comments, this is already handed in a more > general way in the JWS validation steps. Specifically, the last paragraph > of Section 5.2 is: > > "Finally, note that it is an application decision which algorithms are > acceptable in a given context. Even if a JWS can be successfully validated, > unless the algorithm(s) used in the JWS are acceptable to the application, > it SHOULD reject the JWS." > I've cleared this DISCUSS in the interest of having this fight over in JWS thread. But I also added the following COMMENT: "It would be good for this document to pass on the note from JWS about selecting which algorithms are acceptable, and in particular, whether unsecured JWTs are acceptable." --Richard > I would therefore request that you likewise withdraw this DISCUSS on that > basis. > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Abstract. > > Welsh is the only language I know of in which "w" is a vowel. According > to > > Wikipedia, then, "JWT" should pronounced "joot" :) > > You're not the only person with knowledge of Welsh to have made this > comment. And this is a Jones responding to you... ;-) > > > Section 2. > > It seems like "Unsecured JWT" should simply be defined as "A JWT carried > in an > > Unsigned JWS." > > It's been useful in other specifications that are applications of JWTs to > have a name for this kind of JWT, since it occurs frequently. > > > Section 4.1. > > I'm a little surprised not to see a "jwk" claim, which would basically > enable JWTs > > to sub in for certificates for many use cases. Did the WG consider this > > possibility? > > Not to my knowledge. However, I know of several applications in which > JWKs and JWK Sets are carried as claims in JWTs of various kinds - just > using claim names that are informed by the context of the particular > application. For instance, draft-ietf-oauth-dyn-reg uses a "jwks_uri" > claim to pass a JWK Set by reference and a "jwks" claim to pass a JWK Set > by value. > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > Thanks again, > -- Mike > > --001a113654800b20af0505185a6c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Oct 6, 2014 at 3:54 AM, Mike Jones <Michael.Jones@mi= crosoft.com> wrote:
Thanks for your review, Richard.=C2=A0 My responses are inline = below...

> -----Original Message-----
> From: OAuth [mailto:oauth-bo= unces@ietf.org] On Behalf Of Richard Barnes
> Sent: Wednesday, October 01, 2014 7:57 PM
> To: The IESG
> Cc: oauth-chairs@tools.= ietf.org; oauth@ietf.org; draft-i= etf-oauth-json-web-
> token@tools.ietf.org
> Subject: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-js= on-web-
> token-27: (with DISCUSS and COMMENT)
>
> Richard Barnes has entered the following ballot position for
> draft-ietf-oauth-json-web-token-27: Discuss
>
> When responding, please keep the subject line intact and reply to all = email
> addresses included in the To and CC lines. (Feel free to cut this intr= oductory
> paragraph, however.)
>
>
> Please refer to http://www.ietf.org/iesg/statement/discuss= -criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-oauth-j= son-web-token/
>
>
>
> ----------------------------------------------------------------------=
> DISCUSS:
> ----------------------------------------------------------------------=
>
> Section 7.
> In order to prevent confusion between secured and Unsecured JWTs, the<= br> > validation steps here need to call for the application to specify whic= h is required.

Per my response on your JWS comments, this is already handed in a mo= re general way in the JWS validation steps.=C2=A0 Specifically, the last pa= ragraph of Section 5.2 is:

"Finally, note that it is an application decision which algorithms are= acceptable in a given context. Even if a JWS can be successfully validated= , unless the algorithm(s) used in the JWS are acceptable to the application= , it SHOULD reject the JWS."

I'= ;ve cleared this DISCUSS in the interest of having this fight over in JWS t= hread.=C2=A0 But I also added the following COMMENT:
"It would be g= ood for this document to pass on the note from JWS about selecting which al= gorithms are acceptable, and in particular, whether unsecured JWTs are acce= ptable."

--Richard

=C2=A0
I would therefore request that you likewise withdraw this DISCUSS on that b= asis.
> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
> Abstract.
> Welsh is the only language I know of in which "w" is a vowel= .=C2=A0 According to
> Wikipedia, then, "JWT" should pronounced "joot" :)=

You're not the only person with knowledge of Welsh to have made = this comment.=C2=A0 And this is a Jones responding to you... ;-)

> Section 2.
> It seems like "Unsecured JWT" should simply be defined as &q= uot;A JWT carried in an
> Unsigned JWS."

It's been useful in other specifications that are applications o= f JWTs to have a name for this kind of JWT, since it occurs frequently.

> Section 4.1.
> I'm a little surprised not to see a "jwk" claim, which w= ould basically enable JWTs
> to sub in for certificates for many use cases.=C2=A0 Did the WG consid= er this
> possibility?

Not to my knowledge.=C2=A0 However, I know of several applications i= n which JWKs and JWK Sets are carried as claims in JWTs of various kinds - = just using claim names that are informed by the context of the particular a= pplication.=C2=A0 For instance, draft-ietf-oauth-dyn-reg uses a "jwks_= uri" claim to pass a JWK Set by reference and a "jwks" claim= to pass a JWK Set by value.

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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks again,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =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


--001a113654800b20af0505185a6c-- From nobody Sat Oct 11 04:33:31 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E2431A036A for ; Sat, 11 Oct 2014 04:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 r3swGKgQk_jH for ; Sat, 11 Oct 2014 04:33:12 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.31]) (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 786C41A0366 for ; Sat, 11 Oct 2014 04:33:11 -0700 (PDT) Received: from [79.253.15.72] (helo=[192.168.71.80]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1Xcuv7-0001v6-7J for oauth@ietf.org; Sat, 11 Oct 2014 13:33:09 +0200 Message-ID: <54391575.9080707@lodderstedt.net> Date: Sat, 11 Oct 2014 13:33:09 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "oauth@ietf.org WG" References: <543914E8.8070507@lodderstedt.net> In-Reply-To: <543914E8.8070507@lodderstedt.net> X-Forwarded-Message-Id: <543914E8.8070507@lodderstedt.net> Content-Type: multipart/alternative; boundary="------------050106060409040204020206" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/egldlJyT3BXUHbkBfevPn3YvzWs Subject: [OAUTH-WG] Fwd: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-16.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2014 11:33:18 -0000 This is a multi-part message in MIME format. --------------050106060409040204020206 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all, there is some discussion going on in the KITTEN WG regarding the SASL/Oauth mechanism that might be of interest for the OAuth WG as well. kind regards, Torsten. -------- Original-Nachricht -------- Betreff: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-16.txt Datum: Sat, 11 Oct 2014 13:30:48 +0200 Von: Torsten Lodderstedt An: Kitten@ietf.org Kopie (CC): tjs@psaux.com Hi all, as one of the proposers (beside Hannes) of the change, I would like to explain the rationale. > -16 is submitted, and there is one suggested change (which I was supposed to have added in already and blew it), which is to replace section 3.2.2 with the text (farther) below. My comments on the suggested text: > #1) I don't think the dynamic registration stuff is baked enough to want to pull that in to the "oauth-configuration" definition. I don't want to pull it in because I don't think dynamic registration is required for SASL/OAUTH (as evidenced by the Google and Outlook.com implementations. Existing implementations at Google and Outlook.com are no evidence against dynamic client registration. They demonstrate that it is possible to implement the server side. But we are talking about clients (more precisely about generic clients). I'm not aware of any generic client implementing the SASL mechanisms in the moment. I recommend taking a look at https://bugzilla.mozilla.org/show_bug.cgi?id=849540. Before I dive into the registration details, I would like to give my personal summary why this SASL profile is needed. In my opinion, one of the main purposes of this mechanism is to allow generic clients to authorize access to standard protocols, such as IMAP, using OAuth Access Tokens. This offers the following advantages: - multi-factor authn: An increasing number of service providers (e.g. Google, Yahoo, Apple) offer 2-factor authentication to their users, but only for apps and web sites. Why? It currently does not work in conjunction with IMAP and the like. Instead, application-specific passwords must be used, which offer a terrible user experience and therefore are a significant burden for better Internet security. Using OAuth access tokens allows to decouple service access and authentication/authorization process. So the authorization server can choose the appropriate/available mechanisms to authenticate at its discretion. This also allows to use any kind of (provider-specific) multi-factor authentication methods also in the context of IMAP and the like. - Furthermore, using OAuth also allows to use refresh tokens as persistent credential for service login, that way eleminating the need to store user passwords on devices. So basically, the SASL OAuth profile can (at least in my opinion) be a major leap forward in Internet security. Why does this require dynamic registration? Well, OAuth requires any client to possess a client_id (and client_secret) with the particular authorization server. Nowadays developers typically register with the authz server's provider out of band and bake the credentials into the software package. This works for clients, which are directly programmed against a certain deployment/API, such as Facebook, but is inappropriate (if not unfeasible) for generic clients using standardized protocols, e.g. Thunderbird. Or do you want to register the Thunderbird deveopers with every e-Mail/Calendar-provider in the world up-front? I don't think so. That's why the OAuth WG came up with the specification for dynamic client registration, which allows the client to dynamically obtain client credentials from the authorization server. It basically solves the client credential challenge for generic clients, but it does integrate the registration step into an overall process. That's why I think we must define a way for a generic SASL client to, based on user-provided data, find the appropriate authorization server and register with it. I think the SASL mechanism should specify how those mechanisms are used in concert in order to authorize service access using OAuth. Otherwise, the SASL mechanism can only be used for point to point integrations among partners but never for generic clients. So I think true interoperability calls for addition of registration as well. Regarding state of dynamic client registration: It's not ratified yet but already sent to IESG for publication. Beside that it is already implement in existing OpenId Connect deployments. > #2) I didn't really want to make all of the OpenID elements required but I don't have a strong opinion here, my initial intent was to use the OpenID Discovery format as an existing format to be re-used here but leave it flexible. Agreed. Using the format as specified by OpenID Connect makes sense. As generic OAuth differs from OpenID Connect, the WG should (probably in cooperation with the OAuth WG) discuss, which elements are really needed. > #3) I am against recommending scope names at all in any way. I would not include the last sentence of paragraph 5 below and strike the scope names. Given there is already a response parameter scope, which intructs the client on what scope to use in the authz request, I tend to agree. I'm not yet fully convinced whether this approach will work. But let's give it a try. kind regards, Torsten. > New text for 3.2.2: > ----------------------- > 3.2.2. Server Response to Failed Authentication > > > For a failed authentication the server returns a JSON [RFC4627] > formatted error result, and fails the authentication. The error > result consists of the following values: > > > status (REQUIRED): The authorization error code. Valid error > codes are defined in the IANA "OAuth Extensions Error Registry" > specified in the OAuth 2 core specification. > > > scope (OPTIONAL): An OAuth scope which is valid to access the > service. This may be empty which implies that unscoped tokens > are required, or a scope value. If a scope is specified then a > single scope is preferred, use of a space separated list of > scopes is NOT RECOMMENDED. > > > oauth-configuration (OPTIONAL): The URL for a document following > the OpenID Provider Configuration Information schema, as > described in Section 3 of the OpenID Connect Discovery > [OpenID.Discovery], that is appropriate for the user. The > server MAY return different URLs for users from different > domains and a client MUST NOT cache a single returned value and > assume it applies for all users/domains that the server > suports. The returned discovery document MUST have all data > elements required by the OpenID Connect Discovery specification > populated. In addition, the discovery document MUST contain > the 'registration_endpoint' element to learn about the endpoint > to be used with the Dynamic Client Registration protocol > [I-D.ietf-oauth-dyn-reg] to obtain the minimum number of > parameters necessary for the OAuth protocol exchange to > function. Authorization servers MUST implement the > authorization code grant and other grant types MAY be > supported. Furthermore, authorization servers MUST implement > the ability to issue refresh tokens for use with native > applications to benefit from an abbreviated protocol exchange. > The use of the 'offline_access' scope, as defined in > [OpenID.Core] is RECOMMENDED to give clients the capability to > explicitly request a refresh token. > > > If the resource server provides a scope (as part of the element of > the configuration payload) then the client MUST always request > scoped tokens from the token endpoint. This specification > RECOMMMENDs the use of the following scopes: > > imap: The 'imap' scope value is used to interact with IMAP mail > servers. > > pop3: The 'pop3' scope value is used to interact with POP3 mail > servers. > > xmpp: The 'xmpp' scope value is used to interact with XMPP servers. > > > > If the resource server provides no scope to the client then the > client SHOULD presume an empty scope (unscoped token) is needed. > > > Since clients may interact with a number of application servers, > such as email servers and XMPP servers, they need to have a way > to determine whether dynamic client registration has been performed > already and whether an already available refresh token can be > re-used to obtain an access token for the desired resource server. > This specification RECOMMENDs that a client uses the information in > the 'issue' element to make this determination. > ----------------------- > > > I think we're getting very close :) > > -bill _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten --------------050106060409040204020206 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi all,

there is some discussion going on in the KITTEN WG regarding the SASL/Oauth mechanism that might be of interest for the OAuth WG as well.

kind regards,
Torsten.


-------- Original-Nachricht --------
Betreff: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-16.txt
Datum: Sat, 11 Oct 2014 13:30:48 +0200
Von: Torsten Lodderstedt <torsten@lodderstedt.net>
An: Kitten@ietf.org
Kopie (CC): tjs@psaux.com <tjs@psaux.com> 


Hi all,

as one of the proposers (beside Hannes) of the change, I would like to explain the rationale.

> -16 is submitted, and there is one suggested change (which I was supposed to have added in already and blew it), which is to replace section 3.2.2 with the text (farther) below. My comments on the suggested text:

> #1)  I don't think the dynamic registration stuff is baked enough to want to pull that in to the "oauth-configuration" definition. I don't want to pull it in because I don't think dynamic registration is required for SASL/OAUTH (as evidenced by the Google and Outlook.com implementations.


Existing implementations at Google and Outlook.com are no evidence against dynamic client registration. They demonstrate that it is possible
to implement the server side. But we are talking about clients (more precisely about generic clients). I'm not aware of any generic
client implementing the SASL mechanisms in the moment. I recommend taking a look at https://bugzilla.mozilla.org/show_bug.cgi?id=849540.

Before I dive into the registration details, I would like to give my personal summary why this SASL profile is needed.
 
In my opinion, one of the main purposes of this mechanism is to allow generic clients to authorize access to standard protocols, such as IMAP,
using OAuth Access Tokens. This offers the following advantages:

- multi-factor authn: An increasing number of service providers (e.g. Google, Yahoo, Apple) offer 2-factor authentication to their users,
but only for apps and web sites. Why? It currently does not work in conjunction with IMAP and the like. Instead, application-specific passwords
must be used, which offer a terrible user experience and therefore are a significant burden for better Internet security. Using OAuth access tokens
allows to decouple service access and authentication/authorization process. So the authorization server can choose the appropriate/available
mechanisms to authenticate at its discretion. This also allows to use any kind of (provider-specific) multi-factor authentication methods also
in the context of IMAP and the like.

- Furthermore, using OAuth also allows to use refresh tokens as persistent credential for service login, that way eleminating the need to store user
passwords on devices.
 
So basically, the SASL OAuth profile can (at least in my opinion) be a major leap forward in Internet security.

Why does this require dynamic registration?

Well, OAuth requires any client to possess a client_id (and client_secret) with the particular authorization server. Nowadays developers typically
register with the authz server's provider out of band and bake the credentials into the software package. This works for clients, which
are directly programmed against a certain deployment/API, such as Facebook, but is inappropriate (if not unfeasible) for generic
clients using standardized protocols, e.g. Thunderbird.

Or do you want to register the Thunderbird deveopers with every e-Mail/Calendar-provider in the world up-front?

I don't think so. That's why the OAuth WG came up with the specification for dynamic client registration, which allows
the client to dynamically obtain client credentials from the authorization server. It basically solves the client credential challenge for generic
clients, but it does integrate the registration step into an overall process.

That's why I think we must define a way for a generic SASL client to, based on user-provided data, find the appropriate authorization server and
register with it. I think the SASL mechanism should specify how those mechanisms are used in concert in order to authorize service access using OAuth.
Otherwise, the SASL mechanism can only be used for point to point integrations among partners but never for generic clients.

So I think true interoperability calls for addition of registration as well.

Regarding state of dynamic client registration: It's not ratified yet but already sent to IESG for publication.
Beside that it is already implement in existing OpenId Connect deployments.

> #2)  I didn't really want to make all of the OpenID elements required but I don't have a strong opinion here, my initial intent was to use the OpenID Discovery format as an existing format to be re-used here but leave it flexible.

Agreed. Using the format as specified by OpenID Connect makes sense. As generic OAuth differs from OpenID Connect, the WG should (probably in cooperation with
the OAuth WG) discuss, which elements are really needed.

> #3)  I am against recommending scope names at all in any way.  I would not include the last sentence of paragraph 5 below and strike the scope names.


Given there is already a response parameter scope, which intructs the client on what scope to use in the authz request, I tend to agree. I'm not yet fully
convinced whether this approach will work. But let's give it a try.

kind regards,
Torsten.



>   New text for 3.2.2:
> -----------------------
> 3.2.2.  Server Response to Failed Authentication
>
>
> For a failed authentication the server returns a JSON [RFC4627]
> formatted error result, and fails the authentication.  The error
> result consists of the following values:
>
>
> status (REQUIRED):  The authorization error code.  Valid error
> codes are defined in the IANA "OAuth Extensions Error Registry"
> specified in the OAuth 2 core specification.
>
>
> scope (OPTIONAL):  An OAuth scope which is valid to access the
> service.  This may be empty which implies that unscoped tokens
> are required, or a scope value.  If a scope is specified then a
> single scope is preferred, use of a space separated list of
> scopes is NOT RECOMMENDED.
>
>
> oauth-configuration (OPTIONAL):  The URL for a document following
> the OpenID Provider Configuration Information schema, as
> described in Section 3 of the OpenID Connect Discovery
> [OpenID.Discovery], that is appropriate for the user.  The
> server MAY return different URLs for users from different
> domains and a client MUST NOT cache a single returned value and
> assume it applies for all users/domains that the server
> suports.  The returned discovery document MUST have all data
> elements required by the OpenID Connect Discovery specification
> populated.  In addition, the discovery document MUST contain
> the 'registration_endpoint' element to learn about the endpoint
> to be used with the Dynamic Client Registration protocol
> [I-D.ietf-oauth-dyn-reg] to obtain the minimum number of
> parameters necessary for the OAuth protocol exchange to
> function.  Authorization servers MUST implement the
> authorization code grant and other grant types MAY be
> supported.  Furthermore, authorization servers MUST implement
> the ability to issue refresh tokens for use with native
> applications to benefit from an abbreviated protocol exchange.
> The use of the 'offline_access' scope, as defined in
> [OpenID.Core] is RECOMMENDED to give clients the capability to
> explicitly request a refresh token.
>
>
> If the resource server provides a scope (as part of the element of
> the configuration payload) then the client MUST always request
> scoped tokens from the token endpoint.  This specification
> RECOMMMENDs the use of the following scopes:
>
> imap:  The 'imap' scope value is used to interact with IMAP mail
> servers.
>
> pop3:  The 'pop3' scope value is used to interact with POP3 mail
> servers.
>
> xmpp:  The 'xmpp' scope value is used to interact with XMPP servers.
>
>
>
> If the resource server provides no scope to the client then the
> client SHOULD presume an empty scope (unscoped token) is needed.
>
>
> Since clients may interact with a number of application servers,
> such as email servers and XMPP servers, they need to have a way
> to determine whether dynamic client registration has been performed
> already and whether an already available refresh token can be
> re-used to obtain an access token for the desired resource server.
> This specification RECOMMENDs that a client uses the information in
> the 'issue' element to make this determination.
> -----------------------
>
>
> I think we're getting very close :)
>
> -bill




_______________________________________________
Kitten mailing list
Kitten@ietf.org
https://www.ietf.org/mailman/listinfo/kitten


--------------050106060409040204020206-- From nobody Sat Oct 11 12:55:26 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6845A1A8787; Sat, 11 Oct 2014 12:55:25 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TL_KNqc60Jz3; Sat, 11 Oct 2014 12:55:23 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0789.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:789]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C26BD1A877D; Sat, 11 Oct 2014 12:55:22 -0700 (PDT) Received: from BY2PR03CA047.namprd03.prod.outlook.com (10.141.249.20) by BN3PR0301MB1202.namprd03.prod.outlook.com (25.161.207.155) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Sat, 11 Oct 2014 19:55:00 +0000 Received: from BL2FFO11FD033.protection.gbl (2a01:111:f400:7c09::130) by BY2PR03CA047.outlook.office365.com (2a01:111:e400:2c5d::20) with Microsoft SMTP Server (TLS) id 15.0.1049.19 via Frontend Transport; Sat, 11 Oct 2014 19:54:59 +0000 Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD033.mail.protection.outlook.com (10.173.161.129) with Microsoft SMTP Server (TLS) id 15.0.1039.16 via Frontend Transport; Sat, 11 Oct 2014 19:54:59 +0000 Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.93]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.03.0210.003; Sat, 11 Oct 2014 19:54:21 +0000 From: Mike Jones To: Richard Barnes Thread-Topic: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) Thread-Index: AQHP3eyTOy20E1mLIki2fp/mr+WNhZwiXvCAgAeJ6YCAAXQIkA== Date: Sat, 11 Oct 2014 19:54:20 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439BAFABFB@TK5EX14MBXC286.redmond.corp.microsoft.com> References: <20141002025706.19368.2507.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739439BAF0C4E@TK5EX14MBXC286.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(51704005)(52604005)(24454002)(13464003)(52044002)(199003)(189002)(377454003)(23676002)(104016003)(21056001)(76482002)(50466002)(20776003)(55846006)(26826002)(4396001)(19580405001)(15202345003)(110136001)(84676001)(81156004)(33656002)(6806004)(19580395003)(15975445006)(69596002)(68736004)(77096002)(47776003)(44976005)(230783001)(54356999)(85306004)(106116001)(50986999)(66066001)(64706001)(80022003)(95666004)(99396003)(2656002)(87936001)(92726001)(120916001)(46102003)(107046002)(85852003)(31966008)(106466001)(76176999)(86362001)(85806002)(92566001)(97736003)(86612001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1202; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1202; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0361212EA8 Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/6novhYfkRWLvldF6DEwDGiztjPI Cc: "draft-ietf-oauth-json-web-token@tools.ietf.org" , "oauth-chairs@tools.ietf.org" , The IESG , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2014 19:55:25 -0000 PiBGcm9tOiBSaWNoYXJkIEJhcm5lcyBbbWFpbHRvOnJsYkBpcHYuc3hdIA0KPiBTZW50OiBGcmlk YXksIE9jdG9iZXIgMTAsIDIwMTQgMjozNyBQTQ0KPiBUbzogTWlrZSBKb25lcw0KPiBDYzogVGhl IElFU0c7IG9hdXRoLWNoYWlyc0B0b29scy5pZXRmLm9yZzsgb2F1dGhAaWV0Zi5vcmc7IGRyYWZ0 LWlldGYtb2F1dGgtanNvbi13ZWItdG9rZW5AdG9vbHMuaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6 IFtPQVVUSC1XR10gUmljaGFyZCBCYXJuZXMnIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1vYXV0aC1q c29uLXdlYi10b2tlbi0yNzogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCj4gDQo+IE9uIE1v biwgT2N0IDYsIDIwMTQgYXQgMzo1NCBBTSwgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNy b3NvZnQuY29tPiB3cm90ZToNCj4gVGhhbmtzIGZvciB5b3VyIHJldmlldywgUmljaGFyZC4gIE15 IHJlc3BvbnNlcyBhcmUgaW5saW5lIGJlbG93Li4uDQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+ID4gRnJvbTogT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgUmljaGFyZCBCYXJuZXMNCj4gPiBTZW50OiBXZWRuZXNkYXksIE9jdG9i ZXIgMDEsIDIwMTQgNzo1NyBQTQ0KPiA+IFRvOiBUaGUgSUVTRw0KPiA+IENjOiBvYXV0aC1jaGFp cnNAdG9vbHMuaWV0Zi5vcmc7IG9hdXRoQGlldGYub3JnOyBkcmFmdC1pZXRmLW9hdXRoLWpzb24t d2ViLQ0KPiA+IHRva2VuQHRvb2xzLmlldGYub3JnDQo+ID4gU3ViamVjdDogW09BVVRILVdHXSBS aWNoYXJkIEJhcm5lcycgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLW9hdXRoLWpzb24td2ViLQ0KPiA+ IHRva2VuLTI3OiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KPiA+DQo+ID4gUmljaGFyZCBC YXJuZXMgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQo+ID4g ZHJhZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi10b2tlbi0yNzogRGlzY3Vzcw0KPiA+DQo+ID4gV2hl biByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVw bHkgdG8gYWxsIGVtYWlsDQo+ID4gYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0Mg bGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMgaW50cm9kdWN0b3J5DQo+ID4gcGFyYWdyYXBo LCBob3dldmVyLikNCj4gPg0KPiA+DQo+ID4gUGxlYXNlIHJlZmVyIHRvIGh0dHA6Ly93d3cuaWV0 Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQo+ID4gZm9yIG1vcmUg aW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCj4g Pg0KPiA+DQo+ID4gVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlv bnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KPiA+IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi10b2tlbi8NCj4gPg0KPiA+DQo+ID4NCj4gPiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQo+ID4gRElTQ1VTUzoNCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4NCj4gPiBT ZWN0aW9uIDcuDQo+ID4gSW4gb3JkZXIgdG8gcHJldmVudCBjb25mdXNpb24gYmV0d2VlbiBzZWN1 cmVkIGFuZCBVbnNlY3VyZWQgSldUcywgdGhlDQo+ID4gdmFsaWRhdGlvbiBzdGVwcyBoZXJlIG5l ZWQgdG8gY2FsbCBmb3IgdGhlIGFwcGxpY2F0aW9uIHRvIHNwZWNpZnkgd2hpY2ggaXMgcmVxdWly ZWQuDQo+IA0KPiBQZXIgbXkgcmVzcG9uc2Ugb24geW91ciBKV1MgY29tbWVudHMsIHRoaXMgaXMg YWxyZWFkeSBoYW5kZWQgaW4gYSBtb3JlIGdlbmVyYWwgd2F5IGluIHRoZSBKV1MgdmFsaWRhdGlv biBzdGVwcy4gIFNwZWNpZmljYWxseSwgdGhlIGxhc3QgcGFyYWdyYXBoIG9mIFNlY3Rpb24gNS4y IGlzOg0KPiANCj4gIkZpbmFsbHksIG5vdGUgdGhhdCBpdCBpcyBhbiBhcHBsaWNhdGlvbiBkZWNp c2lvbiB3aGljaCBhbGdvcml0aG1zIGFyZSBhY2NlcHRhYmxlIGluIGEgZ2l2ZW4gY29udGV4dC4g RXZlbiBpZiBhIEpXUyBjYW4gYmUgc3VjY2Vzc2Z1bGx5IHZhbGlkYXRlZCwgdW5sZXNzIHRoZSBh bGdvcml0aG0ocykgdXNlZCBpbiB0aGUgSldTIGFyZSBhY2NlcHRhYmxlIHRvIHRoZSBhcHBsaWNh dGlvbiwgaXQgU0hPVUxEIHJlamVjdCB0aGUgSldTLiINCj4gDQo+IEkndmUgY2xlYXJlZCB0aGlz IERJU0NVU1MgaW4gdGhlIGludGVyZXN0IG9mIGhhdmluZyB0aGlzIGZpZ2h0IG92ZXIgaW4gSldT IHRocmVhZC4gIEJ1dCBJIGFsc28gYWRkZWQgdGhlIGZvbGxvd2luZyBDT01NRU5UOg0KPiAiSXQg d291bGQgYmUgZ29vZCBmb3IgdGhpcyBkb2N1bWVudCB0byBwYXNzIG9uIHRoZSBub3RlIGZyb20g SldTIGFib3V0IHNlbGVjdGluZyB3aGljaCBhbGdvcml0aG1zIGFyZSBhY2NlcHRhYmxlLCBhbmQg aW4gcGFydGljdWxhciwgd2hldGhlciB1bnNlY3VyZWQgSldUcyBhcmUgYWNjZXB0YWJsZS4iDQoN ClRoYW5rcyBmb3IgY2xlYXJpbmcgdGhlIERJU0NVU1MuICBJJ20gZmluZSByZXBlYXRpbmcgdGhl IG5vdGUgYWJvdXQgYWNjZXB0YWJsZSBhbGdvcml0aG1zIGluIHRoZSBKV1Qgc3BlYywgYXNzdW1p bmcgb3RoZXJzIGFyZS4NCiANCj4gSSB3b3VsZCB0aGVyZWZvcmUgcmVxdWVzdCB0aGF0IHlvdSBs aWtld2lzZSB3aXRoZHJhdyB0aGlzIERJU0NVU1Mgb24gdGhhdCBiYXNpcy4NCg0KCQkJCS0tIE1p a2UNCg0K From nobody Sat Oct 11 14:42:19 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB8A1A87E9; Sat, 11 Oct 2014 14:42:17 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYsKwEquXRqn; Sat, 11 Oct 2014 14:42:15 -0700 (PDT) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA10C1A87E8; Sat, 11 Oct 2014 14:42:14 -0700 (PDT) Received: by mail-qg0-f52.google.com with SMTP id q108so5458295qgd.11 for ; Sat, 11 Oct 2014 14:42:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=cMspEQhuFFK8lhpCP/igBmwSpwpUORJiGqZ2+R1UhZw=; b=iEAsf4sO86b4LBhrpANV2LTnfK9OyNSnkDLHXJE5Q/W5/DC51lC3ngigXgFzbTTARn SAjAv19727CpGzEQMuz6KgmrLWzbLlLOOEZPiqUYDnx5QqtG5jnWHjs2OnfcJW6XopsZ PLJ21NAwymcqiZ/lGIFNijXSxnL0DI/VjjzVOk54t9d2mGzTYD5qaDs3mPLmZrvNYbqD +FSIIBb9GlyrvEEEUG2HCql9uoCliRojSQc8e8J4Twg1159uweumNzxYQu5gR73y65Z2 hKWHG2GWXRJWc/ccOoBYOndL5CMxaOvm5uWYhC3eY4UnDtlT2IEqSjCneooy8nFN3UND m6+w== X-Received: by 10.224.14.139 with SMTP id g11mr24537692qaa.57.1413063734152; Sat, 11 Oct 2014 14:42:14 -0700 (PDT) Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by mx.google.com with ESMTPSA id d8sm8431754qam.46.2014.10.11.14.42.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 11 Oct 2014 14:42:12 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439BAFABFB@TK5EX14MBXC286.redmond.corp.microsoft.com> Date: Sat, 11 Oct 2014 17:42:12 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2081B766-1A49-48FC-8AC5-E364B6741E13@gmail.com> References: <20141002025706.19368.2507.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739439BAF0C4E@TK5EX14MBXC286.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439BAFABFB@TK5EX14MBXC286.redmond.corp.microsoft.com> To: Mike Jones Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/OCY2Hzn0jqV_Fm5dqd0L2c200x0 Cc: Richard Barnes , "oauth-chairs@tools.ietf.org" , "oauth@ietf.org" , "draft-ietf-oauth-json-web-token@tools.ietf.org" , The IESG Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2014 21:42:17 -0000 Mike, Are you about ready to post an update so we can clear some of the discusses a= nd comments that have been agreed to (like the comment added below when the d= iscuss of Richard's was removed)? It will help ADs if we are able to reduce and work on the rest. I find soon= er rather than later to be easier so they don't need to figure out the issue= s again to clear things that have been agreed upon. It doesn't need to be over the weekend :-) Thank you! Kathleen Sent from my iPhone On Oct 11, 2014, at 3:54 PM, Mike Jones wrote:= >> From: Richard Barnes [mailto:rlb@ipv.sx]=20 >> Sent: Friday, October 10, 2014 2:37 PM >> To: Mike Jones >> Cc: The IESG; oauth-chairs@tools.ietf.org; oauth@ietf.org; draft-ietf-oau= th-json-web-token@tools.ietf.org >> Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-json-= web-token-27: (with DISCUSS and COMMENT) >>=20 >> On Mon, Oct 6, 2014 at 3:54 AM, Mike Jones w= rote: >> Thanks for your review, Richard. My responses are inline below... >>=20 >>> -----Original Message----- >>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Richard Barnes >>> Sent: Wednesday, October 01, 2014 7:57 PM >>> To: The IESG >>> Cc: oauth-chairs@tools.ietf.org; oauth@ietf.org; draft-ietf-oauth-json-w= eb- >>> token@tools.ietf.org >>> Subject: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-json-web= - >>> token-27: (with DISCUSS and COMMENT) >>>=20 >>> Richard Barnes has entered the following ballot position for >>> draft-ietf-oauth-json-web-token-27: Discuss >>>=20 >>> When responding, please keep the subject line intact and reply to all em= ail >>> addresses included in the To and CC lines. (Feel free to cut this introd= uctory >>> paragraph, however.) >>>=20 >>>=20 >>> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html= >>> for more information about IESG DISCUSS and COMMENT positions. >>>=20 >>>=20 >>> The document, along with other ballot positions, can be found here: >>> http://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/ >>>=20 >>>=20 >>>=20 >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>>=20 >>> Section 7. >>> In order to prevent confusion between secured and Unsecured JWTs, the >>> validation steps here need to call for the application to specify which i= s required. >>=20 >> Per my response on your JWS comments, this is already handed in a more ge= neral way in the JWS validation steps. Specifically, the last paragraph of S= ection 5.2 is: >>=20 >> "Finally, note that it is an application decision which algorithms are ac= ceptable in a given context. Even if a JWS can be successfully validated, un= less the algorithm(s) used in the JWS are acceptable to the application, it S= HOULD reject the JWS." >>=20 >> I've cleared this DISCUSS in the interest of having this fight over in JW= S thread. But I also added the following COMMENT: >> "It would be good for this document to pass on the note from JWS about se= lecting which algorithms are acceptable, and in particular, whether unsecure= d JWTs are acceptable." >=20 > Thanks for clearing the DISCUSS. I'm fine repeating the note about accept= able algorithms in the JWT spec, assuming others are. >=20 >> I would therefore request that you likewise withdraw this DISCUSS on that= basis. >=20 > -- Mike >=20 From nobody Sat Oct 11 15:24:24 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C093F1A880E; Sat, 11 Oct 2014 15:24:22 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jd-o0nKi2edr; Sat, 11 Oct 2014 15:24:20 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0754.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:754]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 764131A882F; Sat, 11 Oct 2014 15:24:20 -0700 (PDT) Received: from BN3PR0301CA0062.namprd03.prod.outlook.com (25.160.152.158) by CY1PR0301MB1212.namprd03.prod.outlook.com (25.161.212.146) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Sat, 11 Oct 2014 22:23:56 +0000 Received: from BY2FFO11FD033.protection.gbl (2a01:111:f400:7c0c::182) by BN3PR0301CA0062.outlook.office365.com (2a01:111:e400:401e::30) with Microsoft SMTP Server (TLS) id 15.0.1049.19 via Frontend Transport; Sat, 11 Oct 2014 22:23:56 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD033.mail.protection.outlook.com (10.1.14.218) with Microsoft SMTP Server (TLS) id 15.0.1039.16 via Frontend Transport; Sat, 11 Oct 2014 22:23:55 +0000 Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.93]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.03.0210.003; Sat, 11 Oct 2014 22:23:53 +0000 From: Mike Jones To: Kathleen Moriarty Thread-Topic: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) Thread-Index: AQHP3eyTOy20E1mLIki2fp/mr+WNhZwiXvCAgAeJ6YCAAXQIkIAAH7QAgAALTYA= Date: Sat, 11 Oct 2014 22:23:52 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439BAFAEB1@TK5EX14MBXC286.redmond.corp.microsoft.com> References: <20141002025706.19368.2507.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739439BAF0C4E@TK5EX14MBXC286.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439BAFABFB@TK5EX14MBXC286.redmond.corp.microsoft.com> <2081B766-1A49-48FC-8AC5-E364B6741E13@gmail.com> In-Reply-To: <2081B766-1A49-48FC-8AC5-E364B6741E13@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(51704005)(199003)(13464003)(52604005)(377454003)(189002)(52044002)(24454002)(97756001)(23726002)(4396001)(110136001)(6806004)(44976005)(2656002)(77096002)(230783001)(19580405001)(97736003)(19580395003)(15975445006)(87936001)(76176999)(50986999)(85806002)(54356999)(68736004)(69596002)(84676001)(33656002)(26826002)(104016003)(46406003)(120916001)(55846006)(21056001)(99396003)(95666004)(31966008)(81156004)(50466002)(15202345003)(106116001)(106466001)(76482002)(46102003)(80022003)(86362001)(86612001)(85852003)(64706001)(66066001)(107046002)(47776003)(20776003)(85306004)(92566001)(93886004)(92726001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB1212; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB1212; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0361212EA8 Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/9CptbdpvmutGUz_lAbmaXbzZFgk Cc: Richard Barnes , "oauth-chairs@tools.ietf.org" , "oauth@ietf.org" , "draft-ietf-oauth-json-web-token@tools.ietf.org" , The IESG Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2014 22:24:23 -0000 I hope to be ready to post updated drafts incorporating the proposed resolu= tions on Monday or Tuesday. -- Mike -----Original Message----- From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com]=20 Sent: Saturday, October 11, 2014 2:42 PM To: Mike Jones Cc: Richard Barnes; draft-ietf-oauth-json-web-token@tools.ietf.org; oauth-c= hairs@tools.ietf.org; The IESG; oauth@ietf.org Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-json-we= b-token-27: (with DISCUSS and COMMENT) Mike, Are you about ready to post an update so we can clear some of the discusses= and comments that have been agreed to (like the comment added below when t= he discuss of Richard's was removed)? It will help ADs if we are able to reduce and work on the rest. I find soo= ner rather than later to be easier so they don't need to figure out the iss= ues again to clear things that have been agreed upon. It doesn't need to be over the weekend :-) Thank you! Kathleen Sent from my iPhone On Oct 11, 2014, at 3:54 PM, Mike Jones wrote= : >> From: Richard Barnes [mailto:rlb@ipv.sx] >> Sent: Friday, October 10, 2014 2:37 PM >> To: Mike Jones >> Cc: The IESG; oauth-chairs@tools.ietf.org; oauth@ietf.org;=20 >> draft-ietf-oauth-json-web-token@tools.ietf.org >> Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on=20 >> draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) >>=20 >> On Mon, Oct 6, 2014 at 3:54 AM, Mike Jones = wrote: >> Thanks for your review, Richard. My responses are inline below... >>=20 >>> -----Original Message----- >>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Richard=20 >>> Barnes >>> Sent: Wednesday, October 01, 2014 7:57 PM >>> To: The IESG >>> Cc: oauth-chairs@tools.ietf.org; oauth@ietf.org;=20 >>> draft-ietf-oauth-json-web- token@tools.ietf.org >>> Subject: [OAUTH-WG] Richard Barnes' Discuss on=20 >>> draft-ietf-oauth-json-web- >>> token-27: (with DISCUSS and COMMENT) >>>=20 >>> Richard Barnes has entered the following ballot position for >>> draft-ietf-oauth-json-web-token-27: Discuss >>>=20 >>> When responding, please keep the subject line intact and reply to=20 >>> all email addresses included in the To and CC lines. (Feel free to=20 >>> cut this introductory paragraph, however.) >>>=20 >>>=20 >>> Please refer to=20 >>> http://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>>=20 >>>=20 >>> The document, along with other ballot positions, can be found here: >>> http://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/ >>>=20 >>>=20 >>>=20 >>> -------------------------------------------------------------------- >>> -- >>> DISCUSS: >>> -------------------------------------------------------------------- >>> -- >>>=20 >>> Section 7. >>> In order to prevent confusion between secured and Unsecured JWTs,=20 >>> the validation steps here need to call for the application to specify w= hich is required. >>=20 >> Per my response on your JWS comments, this is already handed in a more g= eneral way in the JWS validation steps. Specifically, the last paragraph o= f Section 5.2 is: >>=20 >> "Finally, note that it is an application decision which algorithms are a= cceptable in a given context. Even if a JWS can be successfully validated, = unless the algorithm(s) used in the JWS are acceptable to the application, = it SHOULD reject the JWS." >>=20 >> I've cleared this DISCUSS in the interest of having this fight over in J= WS thread. But I also added the following COMMENT: >> "It would be good for this document to pass on the note from JWS about s= electing which algorithms are acceptable, and in particular, whether unsecu= red JWTs are acceptable." >=20 > Thanks for clearing the DISCUSS. I'm fine repeating the note about accep= table algorithms in the JWT spec, assuming others are. >=20 >> I would therefore request that you likewise withdraw this DISCUSS on tha= t basis. >=20 > -- Mike >=20 From nobody Sun Oct 12 17:37:42 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B66211A7017; Sun, 12 Oct 2014 17:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6dhz53MVWVZ; Sun, 12 Oct 2014 17:37:36 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 983031A6FAD; Sun, 12 Oct 2014 17:37:36 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s9D0bY4X002970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 13 Oct 2014 00:37:35 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s9D0bXbF023761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 13 Oct 2014 00:37:34 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s9D0bXtm023746; Mon, 13 Oct 2014 00:37:33 GMT Received: from [192.168.1.133] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 12 Oct 2014 17:37:33 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_A8A05EEF-F0DF-45A4-8663-03CB27B78FAA" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: <54391575.9080707@lodderstedt.net> Date: Sun, 12 Oct 2014 17:37:31 -0700 Message-Id: <11F6D8A7-003C-45B7-8B2D-98D8CB0EA285@oracle.com> References: <543914E8.8070507@lodderstedt.net> <54391575.9080707@lodderstedt.net> To: Torsten Lodderstadt X-Mailer: Apple Mail (2.1878.6) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/WEKSrf8BogU-KCKSWzGiBKINVxA Cc: kitten@ietf.org, "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-16.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 00:37:40 -0000 --Apple-Mail=_A8A05EEF-F0DF-45A4-8663-03CB27B78FAA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Torsten, Big +1 to your comments. I think the SASL-OAuth work is very important work and it is the = *classic* use case for OAuth Dynamic Registration. SASL clients are typically developed independently of server = implementation and are meant to work with any server. This means that = having a pre-negotiated client_id is pretty much impossible without dyn = reg or some equivalent solution =97 and why do another? There may be simpler profiles you can develop specific to SASL, but I = think OAuth Dyn Reg should work well for this use case. Phil @independentid www.independentid.com phil.hunt@oracle.com On Oct 11, 2014, at 4:33 AM, Torsten Lodderstedt = wrote: > Hi all, >=20 > there is some discussion going on in the KITTEN WG regarding the = SASL/Oauth mechanism that might be of interest for the OAuth WG as well. >=20 > kind regards, > Torsten. >=20 >=20 > -------- Original-Nachricht -------- > Betreff: Re: [kitten] I-D Action: = draft-ietf-kitten-sasl-oauth-16.txt > Datum: Sat, 11 Oct 2014 13:30:48 +0200 > Von: Torsten Lodderstedt > An: Kitten@ietf.org > Kopie (CC): tjs@psaux.com >=20 > Hi all, >=20 > as one of the proposers (beside Hannes) of the change, I would like to = explain the rationale. >=20 > > -16 is submitted, and there is one suggested change (which I was = supposed to have added in already and blew it), which is to replace = section 3.2.2 with the text (farther) below. My comments on the = suggested text: >=20 > > #1) I don't think the dynamic registration stuff is baked enough to = want to pull that in to the "oauth-configuration" definition. I don't = want to pull it in because I don't think dynamic registration is = required for SASL/OAUTH (as evidenced by the Google and Outlook.com = implementations. >=20 >=20 > Existing implementations at Google and Outlook.com are no evidence = against dynamic client registration. They demonstrate that it is = possible > to implement the server side. But we are talking about clients (more = precisely about generic clients). I'm not aware of any generic > client implementing the SASL mechanisms in the moment. I recommend = taking a look at https://bugzilla.mozilla.org/show_bug.cgi?id=3D849540. >=20 > Before I dive into the registration details, I would like to give my = personal summary why this SASL profile is needed. > =20 > In my opinion, one of the main purposes of this mechanism is to allow = generic clients to authorize access to standard protocols, such as IMAP, > using OAuth Access Tokens. This offers the following advantages: >=20 > - multi-factor authn: An increasing number of service providers (e.g. = Google, Yahoo, Apple) offer 2-factor authentication to their users, > but only for apps and web sites. Why? It currently does not work in = conjunction with IMAP and the like. Instead, application-specific = passwords > must be used, which offer a terrible user experience and therefore are = a significant burden for better Internet security. Using OAuth access = tokens > allows to decouple service access and authentication/authorization = process. So the authorization server can choose the = appropriate/available > mechanisms to authenticate at its discretion. This also allows to use = any kind of (provider-specific) multi-factor authentication methods also > in the context of IMAP and the like. >=20 > - Furthermore, using OAuth also allows to use refresh tokens as = persistent credential for service login, that way eleminating the need = to store user > passwords on devices. > =20 > So basically, the SASL OAuth profile can (at least in my opinion) be a = major leap forward in Internet security. >=20 > Why does this require dynamic registration? >=20 > Well, OAuth requires any client to possess a client_id (and = client_secret) with the particular authorization server. Nowadays = developers typically > register with the authz server's provider out of band and bake the = credentials into the software package. This works for clients, which > are directly programmed against a certain deployment/API, such as = Facebook, but is inappropriate (if not unfeasible) for generic > clients using standardized protocols, e.g. Thunderbird. >=20 > Or do you want to register the Thunderbird deveopers with every = e-Mail/Calendar-provider in the world up-front? >=20 > I don't think so. That's why the OAuth WG came up with the = specification for dynamic client registration, which allows > the client to dynamically obtain client credentials from the = authorization server. It basically solves the client credential = challenge for generic > clients, but it does integrate the registration step into an overall = process. >=20 > That's why I think we must define a way for a generic SASL client to, = based on user-provided data, find the appropriate authorization server = and > register with it. I think the SASL mechanism should specify how those = mechanisms are used in concert in order to authorize service access = using OAuth. > Otherwise, the SASL mechanism can only be used for point to point = integrations among partners but never for generic clients. >=20 > So I think true interoperability calls for addition of registration as = well. >=20 > Regarding state of dynamic client registration: It's not ratified yet = but already sent to IESG for publication. > Beside that it is already implement in existing OpenId Connect = deployments. >=20 > > #2) I didn't really want to make all of the OpenID elements = required but I don't have a strong opinion here, my initial intent was = to use the OpenID Discovery format as an existing format to be re-used = here but leave it flexible. >=20 > Agreed. Using the format as specified by OpenID Connect makes sense. = As generic OAuth differs from OpenID Connect, the WG should (probably in = cooperation with > the OAuth WG) discuss, which elements are really needed. >=20 > > #3) I am against recommending scope names at all in any way. I = would not include the last sentence of paragraph 5 below and strike the = scope names. >=20 >=20 > Given there is already a response parameter scope, which intructs the = client on what scope to use in the authz request, I tend to agree. I'm = not yet fully > convinced whether this approach will work. But let's give it a try. >=20 > kind regards, > Torsten. >=20 >=20 >=20 > > New text for 3.2.2: > > ----------------------- > > 3.2.2. Server Response to Failed Authentication > > > > > > For a failed authentication the server returns a JSON [RFC4627] > > formatted error result, and fails the authentication. The error > > result consists of the following values: > > > > > > status (REQUIRED): The authorization error code. Valid error > > codes are defined in the IANA "OAuth Extensions Error Registry" > > specified in the OAuth 2 core specification. > > > > > > scope (OPTIONAL): An OAuth scope which is valid to access the > > service. This may be empty which implies that unscoped tokens > > are required, or a scope value. If a scope is specified then a > > single scope is preferred, use of a space separated list of > > scopes is NOT RECOMMENDED. > > > > > > oauth-configuration (OPTIONAL): The URL for a document following > > the OpenID Provider Configuration Information schema, as > > described in Section 3 of the OpenID Connect Discovery > > [OpenID.Discovery], that is appropriate for the user. The > > server MAY return different URLs for users from different > > domains and a client MUST NOT cache a single returned value and > > assume it applies for all users/domains that the server > > suports. The returned discovery document MUST have all data > > elements required by the OpenID Connect Discovery specification > > populated. In addition, the discovery document MUST contain > > the 'registration_endpoint' element to learn about the endpoint > > to be used with the Dynamic Client Registration protocol > > [I-D.ietf-oauth-dyn-reg] to obtain the minimum number of > > parameters necessary for the OAuth protocol exchange to > > function. Authorization servers MUST implement the > > authorization code grant and other grant types MAY be > > supported. Furthermore, authorization servers MUST implement > > the ability to issue refresh tokens for use with native > > applications to benefit from an abbreviated protocol exchange. > > The use of the 'offline_access' scope, as defined in > > [OpenID.Core] is RECOMMENDED to give clients the capability to > > explicitly request a refresh token. > > > > > > If the resource server provides a scope (as part of the element of > > the configuration payload) then the client MUST always request > > scoped tokens from the token endpoint. This specification > > RECOMMMENDs the use of the following scopes: > > > > imap: The 'imap' scope value is used to interact with IMAP mail > > servers. > > > > pop3: The 'pop3' scope value is used to interact with POP3 mail > > servers. > > > > xmpp: The 'xmpp' scope value is used to interact with XMPP servers. > > > > > > > > If the resource server provides no scope to the client then the > > client SHOULD presume an empty scope (unscoped token) is needed. > > > > > > Since clients may interact with a number of application servers, > > such as email servers and XMPP servers, they need to have a way > > to determine whether dynamic client registration has been performed > > already and whether an already available refresh token can be > > re-used to obtain an access token for the desired resource server. > > This specification RECOMMENDs that a client uses the information in > > the 'issue' element to make this determination. > > ----------------------- > > > > > > I think we're getting very close :) > > > > -bill >=20 >=20 >=20 >=20 > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_A8A05EEF-F0DF-45A4-8663-03CB27B78FAA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Torsten,

Big +1 to your = comments.

I think the SASL-OAuth work is very = important work and it is the *classic* use case for OAuth Dynamic = Registration.

SASL clients are typically = developed independently of server implementation and are meant to work = with any server.  This means that having a pre-negotiated client_id = is pretty much impossible without dyn reg or some equivalent solution =97 = and why do another?

There may be simpler = profiles you can develop specific to SASL, but I think OAuth Dyn Reg = should work well for this use case.

Phil

On Oct 11, 2014, at 4:33 AM, Torsten Lodderstedt <torsten@lodderstedt.net> = wrote:

=20 =20
Hi all,

there is some discussion going on in the KITTEN WG regarding the SASL/Oauth mechanism that might be of interest for the OAuth WG as well.

kind regards,
Torsten.


-------- Original-Nachricht --------
Betreff: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-16.txt
Datum: Sat, 11 Oct 2014 13:30:48 +0200
Von:= Torsten Lodderstedt <torsten@lodderstedt.net>
An: = Kitten@ietf.org
Kopie (CC): tjs@psaux.com <tjs@psaux.com> 


Hi all,

as one of the proposers (beside Hannes) of the change, I would like to =
explain the rationale.

> -16 is submitted, and there is one suggested change (which I was =
supposed to have added in already and blew it), which is to replace =
section 3.2.2 with the text (farther) below. My comments on the =
suggested text:

> #1)  I don't think the dynamic registration stuff is baked enough =
to want to pull that in to the "oauth-configuration" definition. I don't =
want to pull it in because I don't think dynamic registration is =
required for SASL/OAUTH (as evidenced by the Google and Outlook.com implementations.


Existing implementations at Google and Outlook.com are no evidence against =
dynamic client registration. They demonstrate that it is possible
to implement the server side. But we are talking about clients (more =
precisely about generic clients). I'm not aware of any generic
client implementing the SASL mechanisms in the moment. I recommend =
taking a look at https://bug=
zilla.mozilla.org/show_bug.cgi?id=3D849540.

Before I dive into the registration details, I would like to give my =
personal summary why this SASL profile is needed.
=20
In my opinion, one of the main purposes of this mechanism is to allow =
generic clients to authorize access to standard protocols, such as IMAP,
using OAuth Access Tokens. This offers the following advantages:

- multi-factor authn: An increasing number of service providers (e.g. =
Google, Yahoo, Apple) offer 2-factor authentication to their users,
but only for apps and web sites. Why? It currently does not work in =
conjunction with IMAP and the like. Instead, application-specific =
passwords
must be used, which offer a terrible user experience and therefore are a =
significant burden for better Internet security. Using OAuth access =
tokens
allows to decouple service access and authentication/authorization =
process. So the authorization server can choose the =
appropriate/available
mechanisms to authenticate at its discretion. This also allows to use =
any kind of (provider-specific) multi-factor authentication methods also
in the context of IMAP and the like.

- Furthermore, using OAuth also allows to use refresh tokens as =
persistent credential for service login, that way eleminating the need =
to store user
passwords on devices.
=20
So basically, the SASL OAuth profile can (at least in my opinion) be a =
major leap forward in Internet security.

Why does this require dynamic registration?

Well, OAuth requires any client to possess a client_id (and =
client_secret) with the particular authorization server. Nowadays =
developers typically
register with the authz server's provider out of band and bake the =
credentials into the software package. This works for clients, which
are directly programmed against a certain deployment/API, such as =
Facebook, but is inappropriate (if not unfeasible) for generic
clients using standardized protocols, e.g. Thunderbird.

Or do you want to register the Thunderbird deveopers with every =
e-Mail/Calendar-provider in the world up-front?

I don't think so. That's why the OAuth WG came up with the specification =
for dynamic client registration, which allows
the client to dynamically obtain client credentials from the =
authorization server. It basically solves the client credential =
challenge for generic
clients, but it does integrate the registration step into an overall =
process.

That's why I think we must define a way for a generic SASL client to, =
based on user-provided data, find the appropriate authorization server =
and
register with it. I think the SASL mechanism should specify how those =
mechanisms are used in concert in order to authorize service access =
using OAuth.
Otherwise, the SASL mechanism can only be used for point to point =
integrations among partners but never for generic clients.

So I think true interoperability calls for addition of registration as =
well.

Regarding state of dynamic client registration: It's not ratified yet =
but already sent to IESG for publication.
Beside that it is already implement in existing OpenId Connect =
deployments.

> #2)  I didn't really want to make all of the OpenID elements =
required but I don't have a strong opinion here, my initial intent was =
to use the OpenID Discovery format as an existing format to be re-used =
here but leave it flexible.

Agreed. Using the format as specified by OpenID Connect makes sense. As =
generic OAuth differs from OpenID Connect, the WG should (probably in =
cooperation with
the OAuth WG) discuss, which elements are really needed.

> #3)  I am against recommending scope names at all in any way.  I =
would not include the last sentence of paragraph 5 below and strike the =
scope names.


Given there is already a response parameter scope, which intructs the =
client on what scope to use in the authz request, I tend to agree. I'm =
not yet fully
convinced whether this approach will work. But let's give it a try.

kind regards,
Torsten.



>   New text for 3.2.2:
> -----------------------
> 3.2.2.  Server Response to Failed Authentication
>
>
> For a failed authentication the server returns a JSON [RFC4627]
> formatted error result, and fails the authentication.  The error
> result consists of the following values:
>
>
> status (REQUIRED):  The authorization error code.  Valid error
> codes are defined in the IANA "OAuth Extensions Error Registry"
> specified in the OAuth 2 core specification.
>
>
> scope (OPTIONAL):  An OAuth scope which is valid to access the
> service.  This may be empty which implies that unscoped tokens
> are required, or a scope value.  If a scope is specified then a
> single scope is preferred, use of a space separated list of
> scopes is NOT RECOMMENDED.
>
>
> oauth-configuration (OPTIONAL):  The URL for a document following
> the OpenID Provider Configuration Information schema, as
> described in Section 3 of the OpenID Connect Discovery
> [OpenID.Discovery], that is appropriate for the user.  The
> server MAY return different URLs for users from different
> domains and a client MUST NOT cache a single returned value and
> assume it applies for all users/domains that the server
> suports.  The returned discovery document MUST have all data
> elements required by the OpenID Connect Discovery specification
> populated.  In addition, the discovery document MUST contain
> the 'registration_endpoint' element to learn about the endpoint
> to be used with the Dynamic Client Registration protocol
> [I-D.ietf-oauth-dyn-reg] to obtain the minimum number of
> parameters necessary for the OAuth protocol exchange to
> function.  Authorization servers MUST implement the
> authorization code grant and other grant types MAY be
> supported.  Furthermore, authorization servers MUST implement
> the ability to issue refresh tokens for use with native
> applications to benefit from an abbreviated protocol exchange.
> The use of the 'offline_access' scope, as defined in
> [OpenID.Core] is RECOMMENDED to give clients the capability to
> explicitly request a refresh token.
>
>
> If the resource server provides a scope (as part of the element of
> the configuration payload) then the client MUST always request
> scoped tokens from the token endpoint.  This specification
> RECOMMMENDs the use of the following scopes:
>
> imap:  The 'imap' scope value is used to interact with IMAP mail
> servers.
>
> pop3:  The 'pop3' scope value is used to interact with POP3 mail
> servers.
>
> xmpp:  The 'xmpp' scope value is used to interact with XMPP =
servers.
>
>
>
> If the resource server provides no scope to the client then the
> client SHOULD presume an empty scope (unscoped token) is needed.
>
>
> Since clients may interact with a number of application servers,
> such as email servers and XMPP servers, they need to have a way
> to determine whether dynamic client registration has been performed
> already and whether an already available refresh token can be
> re-used to obtain an access token for the desired resource server.
> This specification RECOMMENDs that a client uses the information in
> the 'issue' element to make this determination.
> -----------------------
>
>
> I think we're getting very close :)
>
> -bill




_______________________________________________
Kitten mailing list
Kitten@ietf.org
https://www.ietf.org=
/mailman/listinfo/kitten


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

= --Apple-Mail=_A8A05EEF-F0DF-45A4-8663-03CB27B78FAA-- From nobody Mon Oct 13 03:33:35 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40A431A1B8D for ; Mon, 13 Oct 2014 03:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQIlIvtubAjB for ; Mon, 13 Oct 2014 03:33:25 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7BBE1A02E1 for ; Mon, 13 Oct 2014 03:33:24 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id em10so7011022wid.7 for ; Mon, 13 Oct 2014 03:33:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=tsaFFiJItmZb7N8a1nz+og1G64Rhf1it5iH8zAG4C00=; b=P1YnTKoI1tJNYA59EL+p4Lm8x7x66frJwm8HeNZvmcdhJqMmTLnlB1bIQ/2/5Vu1v+ R7Onawoz7lYal1Qn4JXmHYYlwnPfZumtsR7zuMPgoe1TXMv6I9j2nSW/3VNG0r2rF20W aYWTUKGXf7/5NnMDrR5LJqZX0E9uVFCHACDMlsqqK0Y5r39Vawv+Z3j+cQ83bIFEt6vh /prx52xvWtKylByji3K7tfzTTR2TB+13e0wx9rzfAIcTvgtlj+7ycXhtDg+U764Uvlk1 YdW0rdWmaWa/hoNHbZLjdAciIDCo1y8W2xgGlPZOTZh953UsdKoLtMiUh+EJm0bNga0O YlZg== X-Received: by 10.180.206.230 with SMTP id lr6mr19570281wic.82.1413196403405; Mon, 13 Oct 2014 03:33:23 -0700 (PDT) Received: from [10.36.226.2] ([80.169.137.63]) by mx.google.com with ESMTPSA id bc5sm14202254wjb.14.2014.10.13.03.33.22 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Oct 2014 03:33:22 -0700 (PDT) Message-ID: <543BAA71.8040707@gmail.com> Date: Mon, 13 Oct 2014 11:33:21 +0100 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: oauth@ietf.org References: <201407221830.s6MIUYrf031075@outgoing.mit.edu> <2cc10b23a4238ec0c76087b09d1d290a@lodderstedt.net> <6859A770-F6D2-4481-BD5F-2E73779BC745@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739439ADDE116@TK5EX14MBXC294.redmond.corp.microsoft.com> <1E5B5066-E619-4965-B941-62C2CD72A37E@ve7jtb.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/W9H2dvhH4eJ9pCyI-jswOdsUeao Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 10:33:32 -0000 Hi We've had a user asserting that "OAuth2 == OpenidConnect", referring to the fact that the 'only' thing OIC adds on top of the authorization code flow is the client specifying few extra scopes like 'openid' and 'profile' and the authorization service returning an extra property, the id_token which can be sufficient in order to get the authenticated user's info. My understanding "OAuth2 != OpenidConnect", the latter utilizes the former and is an authentication mechanism which is not what OAuth2 is (may be except for the client credentials). But I don't feel like it is a convincing enough argument. I thought this thread was relevant, sorry if not, would have no problems starting a new one. Basically, I wonder what is the proper line of argument for a position such as "OAuth2 != OpenidConnect" and also what was the action to the list of options suggested by John below. Is having an OID profile where no access token is returned would be the cleanest action as far as breaking the ambiguity/confusion is concerned ? Cheers, Sergey On 24/07/14 15:25, John Bradley wrote: > I am not against discussion in the WG. > > I happen to agree with Phil's fundamental premise that some developers > are using OAuth in a insecure way to do authentication. > > That raises the question of how to best educate them, and or address > technical barriers. > > It is on the second point that people's opinions seem to divide. > > Some people thing that if we have a OAuth flow that eliminates the > access token (primarily to avoid asking for consent as I understand it) > and just return a id_token from the token endpoint that can be done in a > spec short enough to het people to read. The subtext of this is that > the Connect specification is too large that it scare people, and they > don't find the spec in the first place because it is not a RFC. > > An other common possession is that if you don't want to prompt the user > for consent then don't ask for scopes. Twisting the OAuth spec to not > return an access token is not OAuth, yes you could use a different > endpoint rather than the token endpoint, but that is not OAuth. > Connect was careful not to break the OAuth spec. As long as you are > willing to take a access token with no scopes (the client needs to > understand that there are no attributes one way or another anyway or it > will break) then you don't need to change OAuth. You can publish a > profile of connect that satisfies the use case. > > I think Mike has largely done that but it might be better being less > stingy on references back to the larger spec. > > The questions are do we modify OAuth to not return an access token, and > if so how, and if we do is it still OAuth. > > The other largely separable question is do we create confusion in the > market and slow the the adoption of identity federation on top of OAuth, > or find a way to make this look like a positive alignment of interests > around a subset of Connect. > > There are a number of options. > 1: We can do a profile in the OIDF and publish it as a IETF document. > Perhaps the cleanest from an IPR point of view.However > 2:We can do a profile in the OAuth WG referencing connect. > 3:We can do a AD sponsored profile that is not in the OAuth WG. > 4:We can do a small spec in OAuth to add response_type to the token > endpoint. in combination with 1, 2, or 3 > > I agree that stoping developers doing insecure things needs to be > addressed somehow. > I am not personally convinced that Oauth without access tokens is sensible. > > Looking forward to the meeting:) > > John B. > On Jul 24, 2014, at 6:52 AM, Brian Campbell > wrote: > >> I'd note that the reaction at the conference to Ian's statement was >> overwhelmingly positive. There was a wide range of industry people >> here - implementers, practitioners, deployers, strategists, etc. - and >> it seems pretty clear that the "rough consensus" of the industry at >> large is that a4c is not wanted or needed. >> >> >> On Thu, Jul 24, 2014 at 5:29 AM, Nat Sakimura > > wrote: >> >> And here is a quote from Ian's blog. >> >> And although the authentication wheel is round, that doesn’t >> mean it isn’t without its lumps. First, we do see some >> reinventing the wheel just to reinvent the wheel. OAuth A4C is >> simply not a fruitful activity and should be put down. >> >> (Source) >> http://www.tuesdaynight.org/2014/07/23/do-we-have-a-round-wheel-yet-musings-on-identity-standards-part-1.html >> >> >> >> 2014-07-23 16:53 GMT-04:00 John Bradley > >: >> >> I thought I did post this to the list. >> >> I guess I hit the wrong reply on my phone. >> John B. >> Sent from my iPhone >> >> On Jul 23, 2014, at 4:50 PM, torsten@lodderstedt.net >> wrote: >> >>> we are two, at least :-) >>> >>> Why didn't you post this on the list? >>> >>> When will be be arriving? >>> >>> Am 23.07.2014 16:39, schrieb John Bradley: >>> >>>> Ian Glazer mentioned this in his keynote at CIS yesterday. >>>> His advice was please stop, we are creating confusion and >>>> uncertainty. >>>> We are becoming our own wort enemy. ( my view though Ian may >>>> share it) >>>> Returning just an id_ token from the token endpoint has >>>> little real value. >>>> Something really useful to do would be sorting out >>>> channel_id so we can do PoP for id tokens to make them and >>>> other cookies secure in the front channel. I think that is >>>> a better use of time. >>>> I may be in the minority opinion on that, it won't be the >>>> first time. >>>> >>>> >>>> John B. >>>> Sent from my iPhone >>>> >>>> On Jul 23, 2014, at 4:04 PM, Torsten Lodderstedt >>>> > >>>> wrote: >>>> >>>>> You are right from a theoretical perspective. Practically >>>>> this was caused by editorial decisions during the creation >>>>> of the RFC. As far as I remember, there was a definition of >>>>> the (one) token endpoint response in early versions. No one >>>>> every considered to NOT respond with an access token from >>>>> the token endpoint. So one might call it an implicit >>>>> assumption. >>>>> I'm worried that people get totally confused if an >>>>> exception is introduced now given the broad adoption of >>>>> OAuth based on this assumption. >>>>> regards, >>>>> Torsten. >>>>> >>>>> Am 23.07.2014 um 15:41 schrieb Thomas Broyer >>>>> >: >>>>> >>>>>> Is it said anywhere that ALL grant types MUST use Section >>>>>> 5.1 responses? Each grant type references Section 5.1, and >>>>>> "access token request" is only defined in the context of >>>>>> the defined grant types. Section 2.2 doesn't talk about >>>>>> the request or response format. >>>>>> >>>>>> Le 23 juil. 2014 21:32, "Nat Sakimura" >>>>> > a écrit : >>>>>> >>>>>> Is it? Apart from the implicit grant that does not use >>>>>> token endpoint, all other grant references section 5.1 >>>>>> for the response, i.e., all shares the same response. >>>>>> >>>>>> >>>>>> 2014-07-23 15:18 GMT-04:00 Thomas Broyer >>>>>> >: >>>>>> >>>>>> I hadn't realized the JSON response that requires >>>>>> the access_token field is defined per grant_type, >>>>>> so I'd be OK to "extend the semantics" as in the >>>>>> current draft. >>>>>> That was actually my main concern: that the token >>>>>> endpoint mandates access_token; but its actually >>>>>> not the case. >>>>>> >>>>>> Le 23 juil. 2014 20:46, "Nat Sakimura" >>>>>> > a >>>>>> écrit : >>>>>> >>>>>> I agree with John that overloading >>>>>> response_type @ authz endpoint is a bad idea. >>>>>> It completely changes the semantics of this >>>>>> parameter. NOTE: what I was proposing was not >>>>>> this parameter, but a new parameter >>>>>> response_type @ token endpoint. >>>>>> I also think overloading grant_type is a bad >>>>>> idea since it changes its semantics. I quote >>>>>> the definition here again: >>>>>> grant >>>>>> credential representing the resource >>>>>> owner's authorization >>>>>> grant_type >>>>>> type of grant sent to the token endpoint to >>>>>> obtain the access token >>>>>> It is not about controlling what is to be >>>>>> returned from the token endpoint, but the hint >>>>>> to the token endpoint describing the type of >>>>>> credential the endpoint has received. It seems >>>>>> the "control of what is being returned from >>>>>> token endpoint" is just a side effect. >>>>>> I am somewhat ambivalent[1] in changing the >>>>>> semantics of token endpoint, but in as much as >>>>>> "text is the king" for a spec., we probably >>>>>> should not change the semantics of it as >>>>>> Torsten points out. If it is ok to change this >>>>>> semantics, I believe defining a new parameter >>>>>> to this endpoint to control the response would >>>>>> be the best way to go. This is what I have >>>>>> described previously. >>>>>> Defining a new endpoint to send code to get ID >>>>>> Token and forbidding the use of it against >>>>>> token endpoint would not change the semantics >>>>>> of any existing parameter or endpoint, which >>>>>> is good. However, I doubt if it is not worth >>>>>> doing. What's the point of avoiding access >>>>>> token scoped to UserInfo endpoint after all? >>>>>> Defining a new endpoint for just avoiding the >>>>>> access token for userinfo endpoint seems way >>>>>> too much the heavy wait way and it breaks >>>>>> interoperabiliy: it defeats the purpose of >>>>>> standardization. >>>>>> I have started feeling that no change is the >>>>>> best way out. >>>>>> Nat >>>>>> [1] If instead of saying "Token endpoint - >>>>>> used by the client to exchange an >>>>>> authorization grant for an access token, >>>>>> typically with client authentication", it were >>>>>> saying "Token endpoint - used by the client to >>>>>> exchange an authorization grant for tokens, >>>>>> typically with client authentication", then it >>>>>> would have been OK. It is an expansion of the >>>>>> capability rather than changing the semantics. >>>>>> >>>>>> >>>>>> 2014-07-23 13:39 GMT-04:00 Mike Jones >>>>>> >>>>> >: >>>>>> >>>>>> You need the alternative response_type >>>>>> value ("code_for_id_token" in the A4C >>>>>> draft) to tell the Authorization Server to >>>>>> return a code to be used with the new >>>>>> grant type, rather than one to use with >>>>>> the "authorization_code" grant type (which >>>>>> is what response_type=code does). >>>>>> >>>>>> >>>>>> *From:*OAuth >>>>>> [mailto:oauth-bounces@ietf.org >>>>>> ] *On >>>>>> Behalf Of *John Bradley >>>>>> *Sent:* Wednesday, July 23, 2014 10:33 AM >>>>>> *To:* torsten@lodderstedt.net >>>>>> >>>>>> >>>>>> >>>>>> *Cc:* oauth@ietf.org >>>>>> *Subject:* Re: [OAUTH-WG] New Version >>>>>> Notification for >>>>>> draft-hunt-oauth-v2-user-a4c-05.txt >>>>>> >>>>>> >>>>>> If we use the token endpoint then a new >>>>>> grant_type is the best way. >>>>>> >>>>>> >>>>>> It sort of overloads code, but that is >>>>>> better than messing with response_type for >>>>>> the authorization endpoint to change the >>>>>> response from the token_endpoint. That is >>>>>> in my opinion a champion bad idea. >>>>>> >>>>>> >>>>>> In discussions developing Connect we >>>>>> decided not to open this can of worms >>>>>> because no good would come of it. >>>>>> >>>>>> >>>>>> The token_endpoint returns a access token. >>>>>> Nothing requires scope to be associates >>>>>> with the token. >>>>>> >>>>>> >>>>>> That is the best solution. No change >>>>>> required. Better interoperability in my >>>>>> opinion. >>>>>> >>>>>> >>>>>> Still on my way to TO, getting in later >>>>>> today. >>>>>> >>>>>> >>>>>> John B. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Sent from my iPhone >>>>>> >>>>>> >>>>>> On Jul 23, 2014, at 12:15 PM, >>>>>> torsten@lodderstedt.net >>>>>> wrote: >>>>>> >>>>>> The "response type" of the token >>>>>> endpoint is controlled by the value of >>>>>> the parameter "grant_type". So there >>>>>> is no need to introduce a new parameter. >>>>>> >>>>>> wrt to a potential "no_access_token" >>>>>> grant type. I do not consider this a >>>>>> good idea as it changes the semantics >>>>>> of the token endpoint (as already >>>>>> pointed out by Thomas). This endpoint >>>>>> ALWAYS responds with an access token >>>>>> to any grant type. I therefore would >>>>>> prefer to use another endpoint for the >>>>>> intended purpose. >>>>>> >>>>>> regards, >>>>>> Torsten. >>>>>> >>>>>> >>>>>> Am 23.07.2014 13:04, schrieb Nat Sakimura: >>>>>> >>>>>> IMHO, changing the semantics of >>>>>> "response_type" @ authz endpoint >>>>>> this way is not a good thing. >>>>>> >>>>>> >>>>>> Instead, defining a new parameter >>>>>> "response_type" @ token endpoint, >>>>>> as I described in my previous >>>>>> message, >>>>>> >>>>>> probably is better. At least, it >>>>>> does not change the semantics of >>>>>> the parameters of RFC6749. >>>>>> >>>>>> >>>>>> Nat >>>>>> >>>>>> >>>>>> 2014-07-23 12:48 GMT-04:00 Thomas >>>>>> Broyer >>>>> >: >>>>>> >>>>>> No, I mean response_type=none and >>>>>> response_type=id_token don't >>>>>> generate a code or access token so >>>>>> you don't use the Token Endpoint >>>>>> (which is not the same as the >>>>>> Authentication Endpoint BTW). >>>>>> >>>>>> With >>>>>> response_type=code_for_id_token, >>>>>> you get a code and exchange it for >>>>>> an id_token only, rather than an >>>>>> access_token, so you're changing >>>>>> the semantics of the Token Endpoint. >>>>>> >>>>>> >>>>>> I'm not saying it's a bad thing, >>>>>> just that you can't really compare >>>>>> none and id_token with >>>>>> code_for_id_token. >>>>>> >>>>>> >>>>>> On Wed, Jul 23, 2014 at 6:45 PM, >>>>>> Richer, Justin P. >>>>>> >>>>> > wrote: >>>>>> >>>>>> It's only "not using the token >>>>>> endpoint" because the token >>>>>> endpoint copy-pasted and renamed >>>>>> the authentication endpoint. >>>>>> >>>>>> >>>>>> -- Justin >>>>>> >>>>>> >>>>>> On Jul 23, 2014, at 9:30 AM, >>>>>> Thomas Broyer >>>>> > wrote: >>>>>> >>>>>> >>>>>> >>>>>> Except that these are about not >>>>>> using the Token Endpoint at all, >>>>>> whereas the current proposal is >>>>>> about the Token Endpoint not >>>>>> returning an access_token field in >>>>>> the JSON. >>>>>> >>>>>> >>>>>> On Wed, Jul 23, 2014 at 4:26 PM, >>>>>> Mike Jones >>>>>> >>>>> > >>>>>> wrote: >>>>>> >>>>>> The response_type "none" is >>>>>> already used in practice, which >>>>>> returns no access token. It was >>>>>> accepted by the designated experts >>>>>> and registered in the IANA OAuth >>>>>> Authorization Endpoint Response >>>>>> Types registry at >>>>>> http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#endpoint >>>>>> . >>>>>> The registered "id_token" response >>>>>> type also returns no access token. >>>>>> >>>>>> >>>>>> So I think the question of whether >>>>>> response types that result in no >>>>>> access token being returned are >>>>>> acceptable within OAuth 2.0 is >>>>>> already settled, as a practical >>>>>> matter. Lots of OAuth >>>>>> implementations are already using >>>>>> such response types. >>>>>> >>>>>> >>>>>> >>>>>> -- Mike >>>>>> >>>>>> >>>>>> *From:*OAuth >>>>>> [mailto:oauth-bounces@ietf.org >>>>>> ] >>>>>> *On Behalf Of *Phil Hunt >>>>>> *Sent:* Wednesday, July 23, 2014 >>>>>> 7:09 AM >>>>>> *To:* Nat Sakimura >>>>>> *Cc:* >>>>> > >>>>>> *Subject:* Re: [OAUTH-WG] New >>>>>> Version Notification for >>>>>> draft-hunt-oauth-v2-user-a4c-05.txt >>>>>> >>>>>> >>>>>> Yes. This is why it has to be >>>>>> discussed in the IETF. >>>>>> >>>>>> >>>>>> Phil >>>>>> >>>>>> >>>>>> @independentid >>>>>> >>>>>> www.independentid.com >>>>>> >>>>>> >>>>>> phil.hunt@oracle.com >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Jul 23, 2014, at 9:43 AM, Nat >>>>>> Sakimura >>>>> > wrote: >>>>>> >>>>>> >>>>>> Reading back the RFC6749, I am not >>>>>> sure if there is a good way of >>>>>> suppressing access token from the >>>>>> response and still be OAuth. It >>>>>> will break whole bunch of implicit >>>>>> definitions like: >>>>>> >>>>>> >>>>>> authorization server >>>>>> The server issuing access >>>>>> tokens to the client after >>>>>> successfully >>>>>> authenticating the resource >>>>>> owner and obtaining authorization. >>>>>> >>>>>> >>>>>> After all, OAuth is all about >>>>>> issuing access tokens. >>>>>> >>>>>> >>>>>> Also, I take back my statement on >>>>>> the grant type in my previous mail. >>>>>> >>>>>> >>>>>> The definition of grant and >>>>>> grant_type are respectively: >>>>>> >>>>>> >>>>>> grant >>>>>> >>>>>> credential representing the >>>>>> resource owner's authorization >>>>>> >>>>>> >>>>>> grant_type >>>>>> >>>>>> (string representing the) type >>>>>> of grant sent to the token >>>>>> endpoint to obtain the access token >>>>>> >>>>>> >>>>>> Thus, the grant sent to the token >>>>>> endpoint in this case is still >>>>>> 'code'. >>>>>> >>>>>> >>>>>> Response type on the other hand is >>>>>> not so well defined in RFC6749, >>>>>> but it seems it is representing >>>>>> what is to be returned from the >>>>>> authorization endpoint. To express >>>>>> what is to be returned from token >>>>>> endpoint, perhaps defining a new >>>>>> parameter to the token endpoint, >>>>>> which is a parallel to the >>>>>> response_type to the Authorization >>>>>> Endpoint seems to be a more >>>>>> symmetric way, though I am not >>>>>> sure at all if that is going to be >>>>>> OAuth any more. One straw-man is >>>>>> to define a new parameter called >>>>>> response_type to the token >>>>>> endpoint such as: >>>>>> >>>>>> >>>>>> response_type >>>>>> >>>>>> OPTIONAL. A string >>>>>> representing what is to be >>>>>> returned from the token endpoint. >>>>>> >>>>>> >>>>>> Then define the behavior of the >>>>>> endpoint according to the values >>>>>> as the parallel to the >>>>>> multi-response type spec. >>>>>> >>>>>> http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html >>>>>> >>>>>> >>>>>> Nat >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 2014-07-23 7:21 GMT-04:00 Phil >>>>>> Hunt >>>>> >: >>>>>> >>>>>> The draft is very clear. >>>>>> >>>>>> Phil >>>>>> >>>>>> >>>>>> On Jul 23, 2014, at 0:46, Nat >>>>>> Sakimura >>>>> > wrote: >>>>>> >>>>>> The new grant type that I was >>>>>> talking about was >>>>>> >>>>>> "authorization_code_but_do_not_return_access_nor_refresh_token", >>>>>> so to speak. >>>>>> >>>>>> It does not return anything >>>>>> per se, but an extension can >>>>>> define something on top of it. >>>>>> >>>>>> >>>>>> Then, OIDC can define a >>>>>> binding to it so that the >>>>>> binding only returns ID Token. >>>>>> >>>>>> This binding work should be >>>>>> done in OIDF. Should there be >>>>>> such a grant type, >>>>>> >>>>>> it will be an extremely short >>>>>> spec. >>>>>> >>>>>> >>>>>> At the same time, if any other >>>>>> specification wanted to define >>>>>> >>>>>> other type of tokens and have >>>>>> it returned from the token >>>>>> endpoint, >>>>>> >>>>>> it can also use this grant type. >>>>>> >>>>>> >>>>>> If what you want is to define >>>>>> a new grant type that returns >>>>>> ID Token only, >>>>>> >>>>>> then, I am with Justin. Since >>>>>> "other response than ID Token" >>>>>> is only >>>>>> >>>>>> theoretical, this is a more >>>>>> plausible way forward, I suppose. >>>>>> >>>>>> >>>>>> Nat >>>>>> >>>>>> >>>>>> 2014-07-22 14:30 GMT-04:00 >>>>>> Justin Richer >>>>> >: >>>>>> >>>>>> So the draft would literally >>>>>> turn into: >>>>>> >>>>>> "The a4c response type and >>>>>> grant type return an id_token >>>>>> from the token endpoint with >>>>>> no access token. All >>>>>> parameters and values are >>>>>> defined in OIDC." >>>>>> >>>>>> Seems like the perfect mini >>>>>> extension draft for OIDF to do. >>>>>> >>>>>> --Justin >>>>>> >>>>>> /sent from my phone/ >>>>>> >>>>>> >>>>>> On Jul 22, 2014 10:29 AM, Nat >>>>>> Sakimura >>>>> > >>>>>> wrote: >>>>>> > >>>>>> > What about just defining a >>>>>> new grant type in this WG? >>>>>> > >>>>>> > >>>>>> > 2014-07-22 12:56 GMT-04:00 >>>>>> Phil Hunt >>>>>> >>>>> >: >>>>>> >> >>>>>> >> That would be nice. However >>>>>> oidc still needs the new grant >>>>>> type in order to implement the >>>>>> same flow. >>>>>> >> >>>>>> >> Phil >>>>>> >> >>>>>> >> On Jul 22, 2014, at 11:35, >>>>>> Nat Sakimura >>>>>> >>>>> > >>>>>> wrote: >>>>>> >> >>>>>> >>> +1 to Justin. >>>>>> >>> >>>>>> >>> >>>>>> >>> 2014-07-22 9:54 GMT-04:00 >>>>>> Richer, Justin P. >>>>>> >>>>> >: >>>>>> >>>> >>>>>> >>>> Errors like these make it >>>>>> clear to me that it would make >>>>>> much more sense to develop >>>>>> this document in the OpenID >>>>>> Foundation. It should be >>>>>> something that directly >>>>>> references OpenID Connect Core >>>>>> for all of these terms instead >>>>>> of redefining them. It's doing >>>>>> authentication, which is >>>>>> fundamentally what OpenID >>>>>> Connect does on top of OAuth, >>>>>> and I don't see a good >>>>>> argument for doing this work >>>>>> in this working group. >>>>>> >>>> >>>>>> >>>> -- Justin >>>>>> >>>> >>>>>> >>>> On Jul 22, 2014, at 4:30 >>>>>> AM, Thomas Broyer >>>>>> >>>>> > >>>>>> wrote: >>>>>> >>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> On Mon, Jul 21, 2014 at >>>>>> 11:52 PM, Mike Jones >>>>>> >>>>> > >>>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> Thanks for your review, >>>>>> Thomas. The "prompt=consent" >>>>>> definition being missing is an >>>>>> editorial error. It should be: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> consent >>>>>> >>>>>> >>>>>> >>>>>> The Authorization >>>>>> Server SHOULD prompt the >>>>>> End-User for consent before >>>>>> returning information to the >>>>>> Client. If it cannot obtain >>>>>> consent, it MUST return an >>>>>> error, typically consent_required. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> I'll plan to add it in >>>>>> the next draft. >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> It looks like the >>>>>> consent_required error needs >>>>>> to be defined too, and you >>>>>> might have forgotten to also >>>>>> import >>>>>> account_selection_required >>>>>> from OpenID Connect. >>>>>> >>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> I agree that there's no >>>>>> difference between a response >>>>>> with multiple "amr" values >>>>>> that includes "mfa" and one >>>>>> that doesn't. Unless a clear >>>>>> use case for why "mfa" is >>>>>> needed can be identified, we >>>>>> can delete it in the next draft. >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> Thanks. >>>>>> >>>>> >>>>>> >>>>> How about "pwd" then? I >>>>>> fully understand that I should >>>>>> return "pwd" if the user >>>>>> authenticated using a >>>>>> password, but what "the >>>>>> service if a client secret is >>>>>> used" means in the definition >>>>>> for the "pwd" value? >>>>>> >>>>> >>>>>> >>>>> (Nota: I know you're at >>>>>> IETF-90, I'm ready to wait >>>>>> 'til you come back ;-) ) >>>>>> >>>>> >>>>>> >>>>> -- >>>>>> >>>>> Thomas Broyer >>>>>> >>>>> /tɔ.ma.bʁwa.je/ >>>>>> >>>>>> >>>>> >>>>>> _______________________________________________ >>>>>> >>>>> 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 >>>>>> >>>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> -- >>>>>> >>> Nat Sakimura (=nat) >>>>>> >>> Chairman, OpenID Foundation >>>>>> >>> http://nat.sakimura.org/ >>>>>> >>> @_nat_en >>>>>> >>> >>>>>> >>> >>>>>> _______________________________________________ >>>>>> >>> OAuth mailing list >>>>>> >>> OAuth@ietf.org >>>>>> >>>>>> >>> >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > -- >>>>>> > Nat Sakimura (=nat) >>>>>> > Chairman, OpenID Foundation >>>>>> > http://nat.sakimura.org/ >>>>>> > @_nat_en >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Nat Sakimura (=nat) >>>>>> >>>>>> Chairman, OpenID Foundation >>>>>> http://nat.sakimura.org/ >>>>>> @_nat_en >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Nat Sakimura (=nat) >>>>>> >>>>>> Chairman, OpenID Foundation >>>>>> http://nat.sakimura.org/ >>>>>> @_nat_en >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Thomas Broyer >>>>>> /tɔ.ma.bʁwa.je/ >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Thomas Broyer >>>>>> /tɔ.ma.bʁwa.je/ >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Nat Sakimura (=nat) >>>>>> >>>>>> Chairman, OpenID Foundation >>>>>> http://nat.sakimura.org/ >>>>>> @_nat_en >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> >>>>>> 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 >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Nat Sakimura (=nat) >>>>>> Chairman, OpenID Foundation >>>>>> http://nat.sakimura.org/ >>>>>> @_nat_en >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Nat Sakimura (=nat) >>>>>> Chairman, OpenID Foundation >>>>>> http://nat.sakimura.org/ >>>>>> @_nat_en >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >> >> >> >> >> -- >> Nat Sakimura (=nat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >> >> _______________________________________________ >> 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 Oct 13 03:34:30 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF891A01E1 for ; Mon, 13 Oct 2014 03:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.573 X-Spam-Level: *** X-Spam-Status: No, score=3.573 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, MISSING_SUBJECT=1.799, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 l1ik-qglWWAi for ; Mon, 13 Oct 2014 03:34:25 -0700 (PDT) Received: from BLU004-OMC1S13.hotmail.com (blu004-omc1s13.hotmail.com [65.55.116.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 675D21A1B11 for ; Mon, 13 Oct 2014 03:34:25 -0700 (PDT) Received: from BLU406-EAS94 ([65.55.116.9]) by BLU004-OMC1S13.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Mon, 13 Oct 2014 03:34:24 -0700 X-TMN: [4WMKwzRumxyxakOBiN4P2Inwtd6NFZ0a] X-Originating-Email: [panca70@outlook.com] Message-ID: Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Client-ID: 1200 X-Mailer: BlackBerry Email (10.2.1.3247) Date: Mon, 13 Oct 2014 17:34:23 +0700 From: Panca Panca.blogspot.com To: oauth@ietf.org X-OriginalArrivalTime: 13 Oct 2014 10:34:24.0913 (UTC) FILETIME=[42224810:01CFE6D1] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Fpm6BT1vL8HBp-E6NWZmcJJichA Subject: [OAUTH-WG] (no subject) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 10:34:26 -0000 body { font-family: "Calibri","Slate Pro","sans-serif"; color:#262626 }= <= div>

Dikirim dari ponsel cerdas BlackBerry 10 = saya dengan jaringan Telkomsel.
From nobody Mon Oct 13 04:03:03 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52E651A0282 for ; Mon, 13 Oct 2014 04:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.553 X-Spam-Level: X-Spam-Status: No, score=0.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 rauQJsIjcNGi for ; Mon, 13 Oct 2014 04:02:56 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0654.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:654]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8243E1A0191 for ; Mon, 13 Oct 2014 04:02:55 -0700 (PDT) Received: from CO1PR02MB206.namprd02.prod.outlook.com (10.242.165.144) by CO1PR02MB206.namprd02.prod.outlook.com (10.242.165.144) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Mon, 13 Oct 2014 11:02:31 +0000 Received: from CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.15]) by CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.15]) with mapi id 15.00.1049.012; Mon, 13 Oct 2014 11:02:31 +0000 From: Antonio Sanso To: "oauth@ietf.org" Thread-Topic: [OAUTH-WG] open redirect in rfc6749 Thread-Index: AQHPx43Iqm72AKs/tk+aoXIbGajW5JvvlAWAgAABL4CAAAjogIAAAV6AgAABUQCAAAP4AIAAARkAgAAHYQCAAAO5AIAAwV0AgAAbbICAAAwBgIAAAPwAgABUVwCAAAJ4AIAAA+OAgBGs+4CAAAiDgIAABXsAgAAL1wCAAAKvgIAABlQAgAALdQCAALv0gIAAXHgAgCQT1QCABh7KgA== Date: Mon, 13 Oct 2014 11:02:31 +0000 Message-ID: <2FBAAA24-57E0-4F60-B0B1-6D10E6151C0C@adobe.com> References: <756EEB25-89E8-4445-9DA0-5522787D51AB@adobe.com> <25055629-26A9-478D-AE7A-3C295E3166EE@adobe.com> <54074B7A.7080907@pingidentity.com> <43A8E8A6-BA9B-4501-8CA3-28943236EADB@adobe.com> <54075296.9090007@pingidentity.com> <848F15BD-894D-48C6-B901-B5565BDE4C08@adobe.com> <05C25C09-598C-4D7F-A07A-C93DEC17D10B@adobe.com> <255386B5-79A1-4CD7-90E6-F3F6E23F51F8@mitre.org> <540818FD.1010202@pingidentity.com> <809F7DAB-021D-4770-9D7B-E996D0D32D45@adobe.com> <54086090.8080703@redhat.com> <342B1A81-7333-43D5-A8BC-5CBB31F7D354@adobe.com> <540865E5.5010808@pingidentity.com> <8B89E66C-B82B-41CB-819C-3E1C9B65A7BA@oracle.com> <5E650C1B-A3EC-49E0-9EC0-362B4957ECC1@ve7jtb.com> <100DA4A7-0E88-4BAC-AD2A-EF29A9C6A950@adobe.com> <29F9628D-EBD4-4C32-BD8B-4FC520ADAED0@ve7jtb.com> <54184BCC.6000101@redhat.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.147.117.11] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR02MB206; x-forefront-prvs: 03630A6A4A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(6009001)(51704005)(199003)(52604005)(479174003)(377454003)(189002)(51444003)(24454002)(15395725005)(4396001)(2656002)(110136001)(77096002)(15974865002)(2501002)(19580405001)(16601075003)(19580395003)(76176999)(97736003)(40100003)(87936001)(587094004)(54356999)(50986999)(15975445006)(33656002)(101416001)(105586002)(83716003)(106356001)(82746002)(120916001)(99286002)(21056001)(99396003)(95666004)(31966008)(122556002)(106116001)(46102003)(86362001)(15202345003)(36756003)(80022003)(76482002)(64706001)(85852003)(66066001)(2351001)(107046002)(107886001)(20776003)(92566001)(93886004)(15188555004)(85306004)(92726001)(104396001)(559001)(579004)(387795003)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR02MB206; H:CO1PR02MB206.namprd02.prod.outlook.com; FPR:; MLV:ovrnspm; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="Windows-1252" Content-ID: <8DE1480A63F2F74EB2A8602B4D4D3851@namprd02.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/VI4WnZcG3q_--2dviY9b7hf3xQ8 Subject: Re: [OAUTH-WG] open redirect in rfc6749 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 11:03:00 -0000 just sharing with you how this very =93issue=94 has been lately used in a r= eal life attack: http://andrisatteka.blogspot.ch/2014/09/how-microsoft-is-giving-your-data-t= o.html regards antonio On Oct 9, 2014, at 3:34 PM, Antonio Sanso wrote: > hi again *, >=20 > apologies to bother you again with this :), just wasn=92t really clear t= o me if this is considered like =91solved=92 (namely the discussion is over= , no action to be taken) or we need still to discuss about this topic in or= der to reach some sort of consensus :) >=20 > regards >=20 > antonio >=20 > On Sep 16, 2014, at 4:40 PM, Bill Burke wrote: >=20 >> I'll reiterate what convinced me if it helps. >>=20 >> The danger was a matter of expectations. In Antonio's scenario, the use= r is more likely to be expecting a login screen and thus more likely to be = fooled by a login-screen spoof. Antonio's suggested changes don't break an= y compatibility either, it just requires the AS to display an error page on= *any* parameter error instead of redirecting back. Something the spec alre= ady requires for a bad client id. >>=20 >> On 9/16/2014 5:08 AM, Antonio Sanso wrote: >>> Hi John, >>>=20 >>> agree that there are at two different things (as you pointed out below)= where we could spend some word and provide some advice. >>>=20 >>> To summarize: >>>=20 >>> - one is the 'open redirect=92 issue (net of semantic :), pointed by me= , where nothing is leaked >>> - one is the leakage, pointed by John >>>=20 >>> Those two scenarios are different and might deserve to be discussed ind= ependently=85 :) >>>=20 >>=20 >>> On Sep 15, 2014, at 11:56 PM, John Bradley wrote: >>>=20 >>>> Something might get leaked by the browser, the fragment may be leaked = by the browser if the redirect URI doesn't contain a fragment in some brows= ers. >>>>=20 >>>> A simple security consideration might be to add a fragment to the redi= rect_uri in the error case. >>>>=20 >>>> The other way that information may leak is via the referrer. If ther= e is only one redirect by the AS the URI that was sent to the AS including = all the parameters would still be available to the target. >>>> A simple fix is to redirect to a intermediate page before redirecting = to the registered client, this clears the referrer. >>>>=20 >>>> It is true that nothing is leaked in the redirect_uri itself but there= are side channels in the browser that need to be considered. >>>>=20 >>>> The fixes are quite simple implementation issues and don't break anyth= ing. >>>>=20 >>>> Yes if the client is trusted then this is probably unnecessary but wou= ldn't hurt anything. >>>>=20 >>>> John B. >>>>=20 >>>> PS for OAuth this would really only be exploitable if exact redirect_u= ri matching is not happening. >>>>=20 >>>> As I am a inherently bad person, I could hypothetically use this to at= tack a AS that is doing domain level pattern matching of redirect URI and h= as a public client in the same domain as the AS. >>>>=20 >>>> I should also note that domains using pattern matching are also vulner= able if they allow other sorts of user hosted content like blog posts that = pull in images and leak the referrer. >>>=20 >>> if somebody is curios about some real world attack this is one I perfor= med to Facebook that does exactly what John describes here http://intothesy= mmetry.blogspot.ch/2014/04/oauth-2-how-i-have-hacked-facebook.html >>>=20 >>> regards >>>=20 >>> antonio >>>=20 >>>>=20 >>>> So we do probably need to provide some advice. >>>>=20 >>>> John B. >>>>=20 >>>> On Sep 15, 2014, at 6:15 PM, Richer, Justin P. wro= te: >>>>=20 >>>>> As we discussed before: This isn't really an open redirection in the = classical sense since nothing gets leaked and the URI is tied back to a kno= wn (albeit malicious) client registration. And I thought the clear solution= was to have an AS not automatically redirect to an untrusted client in err= or conditions, where "untrusted" is defined by the AS with guidance. If any= thing this is a security considerations addendum. >>>>>=20 >>>>> -- Justin >>>>>=20 >>>>> On Sep 15, 2014, at 4:52 PM, Antonio Sanso wrote: >>>>>=20 >>>>>> The problem is that a malicious client can register a malicious redi= rect uri and https://tools.ietf.org/html/rfc6749#section-4.1.2.1 does the r= est (as previously discussed) >>>>>>=20 >>>>>> regards >>>>>>=20 >>>>>> antonio >>>>>>=20 >>>>>> On Sep 15, 2014, at 10:43 PM, Phil Hunt wrote= : >>>>>>=20 >>>>>>> If a server accepts a URL from a client to be used as a redirect th= at the server doesn=92t recognize or is not registered, that is an open red= irect. >>>>>>>=20 >>>>>>> The specification does no allow open-redirects, it considers this a= mis-configuration. >>>>>>>=20 >>>>>>> Take a look at sections 3.1.2.2 and 10.15 of RFC6749. >>>>>>>=20 >>>>>>> Phil >>>>>>>=20 >>>>>>> @independentid >>>>>>> www.independentid.com >>>>>>> phil.hunt@oracle.com >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On Sep 15, 2014, at 1:00 PM, John Bradley wrote= : >>>>>>>=20 >>>>>>>> There may be a problem with semantics in this discussion. >>>>>>>>=20 >>>>>>>> There is a redirect performed by athe authorization endpoint to a = fixed uri that is pre registered with the authorization server without user= prompting. >>>>>>>>=20 >>>>>>>> That probably doesn't fit the strict definition of a open redirect= or. >>>>>>>>=20 >>>>>>>> It may however create similar security issues in situations with r= elatively open registration of clients. >>>>>>>>=20 >>>>>>>> The largest issues are that the browser might leak information acr= oss the redirect in the fragment or referrer. That has been used in attack= s against Facebook in the past. >>>>>>>>=20 >>>>>>>> This is no where near the end of the world, however we need to lo= ok at the security considerations and see if we can provide better advice t= o implementors. In some cases returning a error to the browser may be best= . >>>>>>>>=20 >>>>>>>> I don't think we need to go so far as not returning any error to t= he client under any circumstance. >>>>>>>>=20 >>>>>>>> John B. >>>>>>>>=20 >>>>>>>> Sent from my iPhone >>>>>>>>=20 >>>>>>>>> On Sep 15, 2014, at 4:41 PM, Phil Hunt wro= te: >>>>>>>>>=20 >>>>>>>>> Simply not true. >>>>>>>>>=20 >>>>>>>>> Phil >>>>>>>>>=20 >>>>>>>>> @independentid >>>>>>>>> www.independentid.com >>>>>>>>> phil.hunt@oracle.com >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> On Sep 15, 2014, at 12:10 PM, Antonio Sanso w= rote: >>>>>>>>>>=20 >>>>>>>>>> hi *, >>>>>>>>>>=20 >>>>>>>>>> my understanding is that there is a rough consensus that if an O= Auth Provider follows rfc6749 verbatim will end up having an open redirecto= r. >>>>>>>>>> My next question would be now, is there anything we can do to ra= ise some awareness about this issue? >>>>>>>>>>=20 >>>>>>>>>> regards >>>>>>>>>>=20 >>>>>>>>>> antonio >>>>>>>>>>=20 >>>>>>>>>>> On Sep 4, 2014, at 3:15 PM, Hans Zandbelt wrote: >>>>>>>>>>>=20 >>>>>>>>>>> I am convinced about the issue in the use case Antonio provided= but I hope not to close the door on returning errors to known and trusted = clients. Not sure anymore if that's possible though because the distinction= can't be "registered"... >>>>>>>>>>>=20 >>>>>>>>>>> Hans. >>>>>>>>>>>=20 >>>>>>>>>>>> On 9/4/14, 3:01 PM, Antonio Sanso wrote: >>>>>>>>>>>> hi Bill >>>>>>>>>>>>> On Sep 4, 2014, at 2:52 PM, Bill Burke wr= ote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> FWIW, Antonio convinced me and I'm going to change this in ou= r IDM project. Thanks Antonio. What convinced me was that the user is pro= bably expecting a login screen. Since there is this expectation, it might = make it a little easier for the attacker to convince the user that a spoofe= d login screen is real. I know this issue can only happen with unrestricte= d registration, but, IMO, this proposed change doesn't really have much of = an effect on usability and is even backward compatible with the current RFC= . >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Wouldn't it better though to never do a redirect on an invali= d request and just display an error page? >>>>>>>>>>>>=20 >>>>>>>>>>>> thanks for sharing your thoughts :). Display an error 400 is w= hat Google does :) >>>>>>>>>>>>=20 >>>>>>>>>>>> regards >>>>>>>>>>>>=20 >>>>>>>>>>>> antonio >>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On 9/4/2014 3:50 AM, Antonio Sanso wrote: >>>>>>>>>>>>>> Hi Hans, >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I really fail to see how this can be addressed at registrati= on time for cases where registration is unrestricted (namely all the big Pr= oviders) >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> regards >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> antonio >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> On Sep 4, 2014, at 9:47 AM, Hans Zandbelt wrote: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Classifying like this must also mean that consent should no= t be stored until the client is considered (admin) trusted, and admin polic= y would interfere with user policy. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> IMHO the security consideration would apply only to dynamic= ally registered clients where registration is unrestricted; any other form = would involve some form of admin/user approval at registration time, overco= ming the concern at authorization time: there's no auto-redirect flow possi= ble for unknown clients. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Hans. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> On 9/4/14, 9:04 AM, Richer, Justin P. wrote: >>>>>>>>>>>>>>>> I think this advice isn't a bad idea, though it's of cours= e up to the AS >>>>>>>>>>>>>>>> what an "untrusted" client really is. In practice, this is= something >>>>>>>>>>>>>>>> that was registered by a non-sysadmin type person, either = a dynamically >>>>>>>>>>>>>>>> registered client or something available through self-serv= ice >>>>>>>>>>>>>>>> registration of some type. It's also reasonable that a cli= ent, even >>>>>>>>>>>>>>>> dynamically registered, would be considered "trusted" if e= nough time has >>>>>>>>>>>>>>>> passed and enough users have used it without things blowin= g up. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> -- Justin >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> On Sep 4, 2014, at 1:26 AM, Antonio Sanso >>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> hi again *, >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> after thinking a bit further IMHO an alternative for the = untrusted >>>>>>>>>>>>>>>>> clients can also be to always present the consent screen = (at least >>>>>>>>>>>>>>>>> once) before any redirect. >>>>>>>>>>>>>>>>> Namely all providers I have seen show the consent screen = if all the >>>>>>>>>>>>>>>>> request parameters are correct and if the user accepts th= e redirect >>>>>>>>>>>>>>>>> happens. >>>>>>>>>>>>>>>>> If one of the parameter (with the exclusion of the clien= t id and >>>>>>>>>>>>>>>>> redirect uri that are handled differently as for spec) is= wrong though >>>>>>>>>>>>>>>>> the redirect happens without the consent screen being sho= wn.. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> WDYT? >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> regards >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> antonio >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> On Sep 3, 2014, at 7:54 PM, Antonio Sanso >>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> Well, >>>>>>>>>>>>>>>>>> I do not know if this is only dynamic registration... >>>>>>>>>>>>>>>>>> let=92s talk about real use cases, namely e.g. Google , = Facebook , >>>>>>>>>>>>>>>>>> etc.. is that dynamic client registration? I do not know= =85 :) >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> Said that what the other guys think? :) >>>>>>>>>>>>>>>>>> Would this deserve some =93spec adjustment=94 ? I mean t= here is a reason >>>>>>>>>>>>>>>>>> if Google is by choice =93violating=94 the spec right? (= I assume to avoid >>>>>>>>>>>>>>>>>> open redirect=85) >>>>>>>>>>>>>>>>>> But other implementers do follow the spec hence they hav= e this open >>>>>>>>>>>>>>>>>> redirector=85 and this is not nice IMHO... >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> On Sep 3, 2014, at 7:40 PM, Hans Zandbelt >>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> On 9/3/14, 7:14 PM, Antonio Sanso wrote: >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt >>>>>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> Is your concern clients that were registered using dy= namic client >>>>>>>>>>>>>>>>>>>>> registration? >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> yes >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> I think your issue is then with the trust model of dyna= mic client >>>>>>>>>>>>>>>>>>> registration; that is left out of scope of the dynreg s= pec (and the >>>>>>>>>>>>>>>>>>> concept is not even part of the core spec), but unless = you want >>>>>>>>>>>>>>>>>>> everything to be open (which typically would not be the= case), then >>>>>>>>>>>>>>>>>>> it would involve approval somewhere in the process befo= re the client >>>>>>>>>>>>>>>>>>> is registered. Without dynamic client registration that= approval is >>>>>>>>>>>>>>>>>>> admin based or resource owner based, depending on use c= ase. >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> Otherwise the positive case is returning a response t= o a valid URL >>>>>>>>>>>>>>>>>>>>> that belongs to a client that was registered explicit= ly by the >>>>>>>>>>>>>>>>>>>>> resource owner >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> well AFAIK the resource owner doesn=92t register clien= ts=85 >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> roles can collapse in use cases especially when using d= ynamic client >>>>>>>>>>>>>>>>>>> registration >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> and the negative case is returning an error to that s= ame URL. >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> the difference is the consent screen=85 in the positiv= e case you need >>>>>>>>>>>>>>>>>>>> to approve an app.. for the error case no approval is = needed,,, >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> I fail to see the open redirect. >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> why? >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> because the client and thus the fixed URL are explicitl= y approved at >>>>>>>>>>>>>>>>>>> some point >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> Hans. >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> Hans. >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> On 9/3/14, 6:56 PM, Antonio Sanso wrote: >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> On Sep 3, 2014, at 6:51 PM, Hans Zandbelt >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>> Let me try and approach this from a different angle= : why would you >>>>>>>>>>>>>>>>>>>>>>> call it an open redirect when an invalid scope is p= rovided and >>>>>>>>>>>>>>>>>>>>>>> call it >>>>>>>>>>>>>>>>>>>>>>> correct protocol behavior (hopefully) when a valid = scope is >>>>>>>>>>>>>>>>>>>>>>> provided? >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> as specified below in the positive case (namely when= the correct >>>>>>>>>>>>>>>>>>>>>> scope >>>>>>>>>>>>>>>>>>>>>> is provided) the resource owner MUST approve the app= via the consent >>>>>>>>>>>>>>>>>>>>>> screen (at least once). >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>> Hans. >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>> On 9/3/14, 6:46 PM, Antonio Sanso wrote: >>>>>>>>>>>>>>>>>>>>>>>> hi John, >>>>>>>>>>>>>>>>>>>>>>>> On Sep 3, 2014, at 6:14 PM, John Bradley >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>> In the example the redirect_uri is vlid for the a= ttacker. >>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>> The issue is that the AS may be allowing client r= egistrations with >>>>>>>>>>>>>>>>>>>>>>>>> arbitrary redirect_uri. >>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>> In the spec it is unspecified how a AS validates = that a client >>>>>>>>>>>>>>>>>>>>>>>>> controls the redirect_uri it is registering. >>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>> I think that if anything it may be the registrati= on step that >>>>>>>>>>>>>>>>>>>>>>>>> needs >>>>>>>>>>>>>>>>>>>>>>>>> the security consideration. >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>> (this is the first time :p) but I do disagree with= you. It would be >>>>>>>>>>>>>>>>>>>>>>>> pretty unpractical to block this at registration t= ime=85. >>>>>>>>>>>>>>>>>>>>>>>> IMHO the best approach is the one taken from Googl= e, namely >>>>>>>>>>>>>>>>>>>>>>>> returning >>>>>>>>>>>>>>>>>>>>>>>> 400 with the cause of the error.. >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>> *400.* That=92s an error. >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>> *Error: invalid_scope* >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>> Some requested scopes were invalid. {invalid=3D[l]= } >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>> said that I hope you all agree this is an issue in= the spec so >>>>>>>>>>>>>>>>>>>>>>>> far=85. >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>> regards >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>> antonio >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>> John B. >>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>> On Sep 3, 2014, at 12:10 PM, Bill Burke >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>> I don't understand. The redirect uri has to be = valid in >>>>>>>>>>>>>>>>>>>>>>>>>> order for a >>>>>>>>>>>>>>>>>>>>>>>>>> redirect to happen. The spec explicitly states = this. >>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>> On 9/3/2014 11:43 AM, Antonio Sanso wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> hi *, >>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>> IMHO providers that strictly follow rfc6749 are= vulnerable >>>>>>>>>>>>>>>>>>>>>>>>>>> to open >>>>>>>>>>>>>>>>>>>>>>>>>>> redirect. >>>>>>>>>>>>>>>>>>>>>>>>>>> Let me explain, reading [0] >>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>> If the request fails due to a missing, invalid,= or mismatching >>>>>>>>>>>>>>>>>>>>>>>>>>> redirection URI, or if the client identifier is= missing or >>>>>>>>>>>>>>>>>>>>>>>>>>> invalid, >>>>>>>>>>>>>>>>>>>>>>>>>>> the authorization server SHOULD inform the reso= urce owner of the >>>>>>>>>>>>>>>>>>>>>>>>>>> error and MUST NOT automatically redirect the u= ser-agent to the >>>>>>>>>>>>>>>>>>>>>>>>>>> invalid redirection URI. >>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>> If the resource owner denies the access request= or if the >>>>>>>>>>>>>>>>>>>>>>>>>>> request >>>>>>>>>>>>>>>>>>>>>>>>>>> fails for reasons other than a missing or inval= id >>>>>>>>>>>>>>>>>>>>>>>>>>> redirection URI, >>>>>>>>>>>>>>>>>>>>>>>>>>> the authorization server informs the client by = adding the >>>>>>>>>>>>>>>>>>>>>>>>>>> following >>>>>>>>>>>>>>>>>>>>>>>>>>> parameters to the query component of the redire= ction URI >>>>>>>>>>>>>>>>>>>>>>>>>>> using the >>>>>>>>>>>>>>>>>>>>>>>>>>> "application/x-www-form-urlencoded" format, per= Appendix B >>>>>>>>>>>>>>>>>>>>>>>>>>> : >>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>> Now let=92s assume this. >>>>>>>>>>>>>>>>>>>>>>>>>>> I am registering a new client to thevictim.com >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> provider. >>>>>>>>>>>>>>>>>>>>>>>>>>> I register redirect uriattacker.com >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >. >>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>> According to [0] if I pass e.g. the wrong scope= I am redirected >>>>>>>>>>>>>>>>>>>>>>>>>>> back to >>>>>>>>>>>>>>>>>>>>>>>>>>> attacker.com >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> >. >>>>>>>>>>>>>>>>>>>>>>>>>>> Namely I prepare a url that is in this form: >>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>> http://victim.com/authorize?response_type=3Dcod= e&client_id=3Dbc88FitX1298KPj2WS259BBMa9_KCfL3&scope=3DWRONG_SCOPE&redirect= _uri=3Dhttp://attacker.com >>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>> and this is works as an open redirector. >>>>>>>>>>>>>>>>>>>>>>>>>>> Of course in the positive case if all the param= eters are >>>>>>>>>>>>>>>>>>>>>>>>>>> fine this >>>>>>>>>>>>>>>>>>>>>>>>>>> doesn=92t apply since the resource owner MUST a= pprove the app >>>>>>>>>>>>>>>>>>>>>>>>>>> via the >>>>>>>>>>>>>>>>>>>>>>>>>>> consent screen (at least once). >>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>> A solution would be to return error 400 rather = than redirect >>>>>>>>>>>>>>>>>>>>>>>>>>> to the >>>>>>>>>>>>>>>>>>>>>>>>>>> redirect URI (as some provider e.g. Google do) >>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>> WDYT? >>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>> regards >>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>> antonio >>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>> [0] https://tools.ietf.org/html/rfc6749#section= -4.1.2.1 >>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>>>>>> Bill Burke >>>>>>>>>>>>>>>>>>>>>>>>>> JBoss, a division of Red Hat >>>>>>>>>>>>>>>>>>>>>>>>>> http://bill.burkecentral.com >>>>>>>>>>>>>>>>>>>>>>>>>>=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 >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architec= t >>>>>>>>>>>>>>>>>>>>>>> hzandbelt@pingidentity.com >>>>>>>>>>>>>>>>>>>>>>> | Ping >>>>>>>>>>>>>>>>>>>>>>> Identity >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>>>>>>>>>> hzandbelt@pingidentity.com | >>>>>>>>>>>>>>>>>>>>> Ping Identity >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>>>>>>>> hzandbelt@pingidentity.com | Ping >>>>>>>>>>>>>>>>>>> Identity >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>>>> hzandbelt@pingidentity.com | Ping Identity >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>=20 >>>>>>>>>>>>> -- >>>>>>>>>>>>> Bill Burke >>>>>>>>>>>>> JBoss, a division of Red Hat >>>>>>>>>>>>> http://bill.burkecentral.com >>>>>>>>>>>>>=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 >>>>>>>>>>> -- >>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>> hzandbelt@pingidentity.com | Ping Identity >>>>>>>>>>=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 >>>>>>=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 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>=20 >> --=20 >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 From nobody Mon Oct 13 04:19:07 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9DE41A035A for ; Mon, 13 Oct 2014 04:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1I5jjmT6mAA4 for ; Mon, 13 Oct 2014 04:18:42 -0700 (PDT) Received: from na3sys009aog124.obsmtp.com (na3sys009aog124.obsmtp.com [74.125.149.151]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E56BC1A1A47 for ; Mon, 13 Oct 2014 04:18:41 -0700 (PDT) Received: from mail-ig0-f177.google.com ([209.85.213.177]) (using TLSv1) by na3sys009aob124.postini.com ([74.125.148.12]) with SMTP ID DSNKVDu1EW/wYA5KDEKlGIdSRl/W8eZtSgl7@postini.com; Mon, 13 Oct 2014 04:18:41 PDT Received: by mail-ig0-f177.google.com with SMTP id a13so10022592igq.4 for ; Mon, 13 Oct 2014 04:18:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=okmGGVLsH5tPmofYoqLwMkASprRo3KB+GUAcFmxUMsc=; b=l/OvGE01uQFl1sLz0mu/jlgoRldPzc0hwat5/4cEBP3TFyts4i2i03UMR986DqkWOO uYosj1dBSIUvTKgBieo63SoAUe6utjAOaDf4B4nAL0KxKBwTuHmVXwqYH4SUKfzbudMc zKC/EefmChPYZQ7MIRIuyo5VpcTY1Nes5oYLLpJvvl7HqCbonBv9uDYdR/unqVW5lAmw 9DH5R8MRSXMVJpzy4zY9L1kPiDqs1Ofm1KMHQKUiiQ2tXHP5s9zVrlgmbGMiu58pojrZ 32QIsUz5mCnY0sWac7eIlrmxKJYQgO9QAvZ7+W1i4IjKT7+lodpAHyI/WNsdEwm63B5E bV5w== X-Gm-Message-State: ALoCoQkEWQMR+I7oofCkyQ2FW8FaYF7oTVa2mhMjchY9lWAWw/PWb0SkPVS7yu0MVqSh7bEKrFMWTJTQ5OfjQu/X9qY+LOvs9pAr8Jf2H1QJ+bBS6trZORk54us3/ol/5bzy0tMV43LQ X-Received: by 10.50.143.65 with SMTP id sc1mr314259igb.27.1413199121112; Mon, 13 Oct 2014 04:18:41 -0700 (PDT) X-Received: by 10.50.143.65 with SMTP id sc1mr314237igb.27.1413199120995; Mon, 13 Oct 2014 04:18:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.12.137 with HTTP; Mon, 13 Oct 2014 04:18:10 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439BAFABFB@TK5EX14MBXC286.redmond.corp.microsoft.com> References: <20141002025706.19368.2507.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739439BAF0C4E@TK5EX14MBXC286.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739439BAFABFB@TK5EX14MBXC286.redmond.corp.microsoft.com> From: Brian Campbell Date: Mon, 13 Oct 2014 05:18:10 -0600 Message-ID: To: Mike Jones Content-Type: multipart/alternative; boundary=001a1135fdaa9ad99105054c0f7c Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/CHbE_oCc_bWzuqXBIgpycV9-2Gw Cc: Richard Barnes , "oauth-chairs@tools.ietf.org" , "oauth@ietf.org" , "draft-ietf-oauth-json-web-token@tools.ietf.org" , The IESG Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 11:18:47 -0000 --001a1135fdaa9ad99105054c0f7c Content-Type: text/plain; charset=UTF-8 Repeating the note about acceptable algorithms in the JWT spec sounds fine. On Sat, Oct 11, 2014 at 1:54 PM, Mike Jones wrote: > > From: Richard Barnes [mailto:rlb@ipv.sx] > > Sent: Friday, October 10, 2014 2:37 PM > > To: Mike Jones > > Cc: The IESG; oauth-chairs@tools.ietf.org; oauth@ietf.org; > draft-ietf-oauth-json-web-token@tools.ietf.org > > Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on > draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) > > > > On Mon, Oct 6, 2014 at 3:54 AM, Mike Jones > wrote: > > Thanks for your review, Richard. My responses are inline below... > > > > > -----Original Message----- > > > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Richard > Barnes > > > Sent: Wednesday, October 01, 2014 7:57 PM > > > To: The IESG > > > Cc: oauth-chairs@tools.ietf.org; oauth@ietf.org; > draft-ietf-oauth-json-web- > > > token@tools.ietf.org > > > Subject: [OAUTH-WG] Richard Barnes' Discuss on > draft-ietf-oauth-json-web- > > > token-27: (with DISCUSS and COMMENT) > > > > > > Richard Barnes has entered the following ballot position for > > > draft-ietf-oauth-json-web-token-27: Discuss > > > > > > When responding, please keep the subject line intact and reply to all > email > > > addresses included in the To and CC lines. (Feel free to cut this > introductory > > > paragraph, however.) > > > > > > > > > Please refer to > http://www.ietf.org/iesg/statement/discuss-criteria.html > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > The document, along with other ballot positions, can be found here: > > > http://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/ > > > > > > > > > > > > ---------------------------------------------------------------------- > > > DISCUSS: > > > ---------------------------------------------------------------------- > > > > > > Section 7. > > > In order to prevent confusion between secured and Unsecured JWTs, the > > > validation steps here need to call for the application to specify > which is required. > > > > Per my response on your JWS comments, this is already handed in a more > general way in the JWS validation steps. Specifically, the last paragraph > of Section 5.2 is: > > > > "Finally, note that it is an application decision which algorithms are > acceptable in a given context. Even if a JWS can be successfully validated, > unless the algorithm(s) used in the JWS are acceptable to the application, > it SHOULD reject the JWS." > > > > I've cleared this DISCUSS in the interest of having this fight over in > JWS thread. But I also added the following COMMENT: > > "It would be good for this document to pass on the note from JWS about > selecting which algorithms are acceptable, and in particular, whether > unsecured JWTs are acceptable." > > Thanks for clearing the DISCUSS. I'm fine repeating the note about > acceptable algorithms in the JWT spec, assuming others are. > > > I would therefore request that you likewise withdraw this DISCUSS on > that basis. > > -- Mike > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001a1135fdaa9ad99105054c0f7c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Repeating the note about acceptable algorithms in the JWT = spec sounds fine.

On Sat, Oct 11, 2014 at 1:54 PM, Mike Jones <Michael.Jones@m= icrosoft.com> wrote:
> From: Richard Barnes [mailto:rlb@ipv.sx]
> Sent: Friday, October 10, 2014 2:37 PM
> To: Mike Jones
> Cc: The IESG; oauth-chairs@tools.ietf.org; oauth@ietf.org; draft-ietf-oauth-json-web-t= oken@tools.ietf.org
> Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oaut= h-json-web-token-27: (with DISCUSS and COMMENT)
>
> On Mon, Oct 6, 2014 at 3:54 AM, Mike Jones <Michael.Jones@microsoft.com&g= t; wrote:
> Thanks for your review, Richard.=C2=A0 My responses are inline below..= .
>
> > -----Original Message-----
> > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Richard Barnes
> > Sent: Wednesday, October 01, 2014 7:57 PM
> > To: The IESG
> > Cc: oauth-chairs@tools.ietf.org; oauth@ietf.org; draft-ietf-oauth-json-web-
> > token@t= ools.ietf.org
> > Subject: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oau= th-json-web-
> > token-27: (with DISCUSS and COMMENT)
> >
> > Richard Barnes has entered the following ballot position for
> > draft-ietf-oauth-json-web-token-27: Discuss
> >
> > When responding, please keep the subject line intact and reply to= all email
> > addresses included in the To and CC lines. (Feel free to cut this= introductory
> > paragraph, however.)
> >
> >
> > Please refer to http://www.ietf.org/iesg/statement/di= scuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions. > >
> >
> > The document, along with other ballot positions, can be found her= e:
> > http://datatracker.ietf.org/doc/draft-ietf-oa= uth-json-web-token/
> >
> >
> >
> > -----------------------------------------------------------------= -----
> > DISCUSS:
> > -----------------------------------------------------------------= -----
> >
> > Section 7.
> > In order to prevent confusion between secured and Unsecured JWTs,= the
> > validation steps here need to call for the application to specify= which is required.
>
> Per my response on your JWS comments, this is already handed in a more= general way in the JWS validation steps.=C2=A0 Specifically, the last para= graph of Section 5.2 is:
>
> "Finally, note that it is an application decision which algorithm= s are acceptable in a given context. Even if a JWS can be successfully vali= dated, unless the algorithm(s) used in the JWS are acceptable to the applic= ation, it SHOULD reject the JWS."
>
> I've cleared this DISCUSS in the interest of having this fight ove= r in JWS thread.=C2=A0 But I also added the following COMMENT:
> "It would be good for this document to pass on the note from JWS = about selecting which algorithms are acceptable, and in particular, whether= unsecured JWTs are acceptable."

Thanks for clearing the DISCUSS.=C2=A0 I'm fine repeating t= he note about acceptable algorithms in the JWT spec, assuming others are.
> I would therefore request that you likewise withdraw this DISCUSS on t= hat basis.

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

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

--001a1135fdaa9ad99105054c0f7c-- From nobody Mon Oct 13 04:54:12 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8C901A899B for ; Mon, 13 Oct 2014 04:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.329 X-Spam-Level: X-Spam-Status: No, score=-3.329 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.157, MIME_BAD_LINEBREAK=0.5, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xWo0DqGDuZMh for ; Mon, 13 Oct 2014 04:54:00 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF1B61A8998 for ; Mon, 13 Oct 2014 04:53:58 -0700 (PDT) X-AuditID: 1209190c-f795e6d000006c66-87-543bbd550f92 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id DA.2F.27750.55DBB345; Mon, 13 Oct 2014 07:53:57 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id s9DBrugA005424; Mon, 13 Oct 2014 07:53:56 -0400 Received: from [IPv6:2607:fb90:290e:a269:c9f6:dc58:6e6a:2a61] ([172.56.23.220]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s9DBrU95023278 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 13 Oct 2014 07:53:40 -0400 Date: Mon, 13 Oct 2014 07:53:24 -0400 Message-ID: Importance: normal From: Justin Richer To: Sergey Beryozkin , oauth@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.android.email_447835122614160" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJIsWRmVeSWpSXmKPExsUixG6nrhu61zrEoP+LiMXJt6/YLP4ttXdg 8tg56y67x5IlP5kCmKK4bFJSczLLUov07RK4MvpeZRVsXy1YserEBpYGxpWfBLoYOTkkBEwk tv+dygJhi0lcuLeerYuRi0NIYDaTxKaH7xghnI2MEm/PrWGFcA4ySfya+4YVpIVFQFVi9ZVl QFUcHMICtRIv91WDmLwCbhL/JieBmJwCQhJduyRAitmAiqevaWECsUUErCVuPJ7OCGLzCghK nJz5BOwGZoEQic/bXjBPYOSdhSQ1C0kKwlaX+DPvEpStKDGl+yH7LKBtzAJqEstalZCFFzCy rWKUTcmt0s1NzMwpTk3WLU5OzMtLLdI11MvNLNFLTSndxAgKUU5Jnh2Mbw4qHWIU4GBU4uGV KLMOEWJNLCuuzD3EKMnBpCTK678JKMSXlJ9SmZFYnBFfVJqTWnyIUYKDWUmEN2INUI43JbGy KrUoHyYlzcGiJM676QdfiJBAemJJanZqakFqEUxWhoNDSYK3dw9Qo2BRanpqRVpmTglCmomD E2Q4D9DwsyA1vMUFibnFmekQ+VOMilLivCt3AyUEQBIZpXlwvbAU8opRHOgVYd4ZIO08wPQD 1/0KaDAT0ODXxWCDSxIRUlINjLUH951z3Bo2/YjRCq9H8Xd+RxScmajDsNla/8Ieo/c8NqkJ kxL0tiupiAUVuOuw6U6Z+1hwoXIOB1cIJ9sZlyNH6ss2f95mv+P2lTl8es//ZkV9Y2JmbHhy Kyous9Bs+jl9xTCt+Tej3ymUGHReuVDG9PqCdrvLdOHINUExVgfyg269+r6lVomlOCPRUIu5 qDgRAAW4QyD8AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/HRXrN2yVcVCRCkVfheTk8Yl0bxA Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 11:54:10 -0000 ----_com.android.email_447835122614160 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 WW91IGFyZSBjb3JyZWN0IGluIHRoYXQgT0F1dGggMiBhbmQgT3BlbklEIENvbm5lY3QgYXJlIG5v dCB0aGUgc2FtZSB0aGluZywgYnV0IHlvdXIgdXNlciBpcyBjb3JyZWN0IHRoYXQgT0lEQyBhZGRz IGEgZmV3IHBpZWNlcyBvbiB0b3Agb2YgT0F1dGggdG8gYWRkIGF1dGhlbnRpY2F0aW9uIGNhcGFi aWxpdGllcy4gT0lEQyB3YXMgZGVzaWduZWQgdmVyeSBleHBsaWNpdGx5IHRvIGJlIGNvbXBhdGli bGUgd2l0aCB2YW5pbGxhIE9BdXRoLCBwYXJ0aWFsbHkgZG8gdGhhdCBwZW9wbGUgd291bGQgYmUg YWJsZSB0byBkZXBsb3kgaXQgb24gdG9wIG9mIGV4aXN0aW5nIE9BdXRoIGluZnJhc3RydWN0dXJl IGFuZCBjb2RlLiBCdXQgdGhlIHZlcnkgZmFjdCB0aGF0IE9JREMgYWRkcyBhIGZldyB0aGluZ3Mg b24gdG9wIG9mIE9BdXRoIHRvIGdpdmUgbW9yZSBmdW5jdGlvbmFsaXR5IHNob3VsZCBiZSBzdWZm aWNpZW50IGV2aWRlbmNlIHRoYXQgdGhleSdyZSBub3QgZXF1aXZhbGVudC7CoAoKSXQncyBtb3Jl IHByb3BlciB0byBzYXkgdGhhdCBPcGVuSUQgQ29ubmVjdCBpcyBhbiBleHRlbnNpb24gYW5kIGFw cGxpY2F0aW9uIG9mIE9BdXRoLiBPbmUgdGhhdCBwcm92aWRlcyBhbiBhdXRoZW50aWNhdGlvbiBh bmQgaWRlbnRpdHkgQVBJLsKgCgpUaGUgd2F5IEkgbGlrZSB0byBleHBsYWluIGl0ICh3aGljaCBJ IHN0b2xlIGZyb20gc29tZW9uZSBlbHNlKSBpcyB0aGF0IE9BdXRoIGlzIGxpa2UgY2hvY29sYXRl IGFuZCBhdXRoZW50aWNhdGlvbiBpcyBsaWtlIGZ1ZGdlLiBUaGV5IGFyZSBub3QgdGhlIHNhbWUg dGhpbmcuIFlvdSBjYW4gbWFrZSBjaG9jb2xhdGUgaW50byBmdWRnZSBvdXQgeW91IGNhbiBtYWtl IGl0IGludG8gc29tZXRoaW5nIGVsc2Ugb3IgeW91IGNhbiBqdXN0IGhhdmUgaXQgb24gaXRzIG93 bi4gWW91IGNhbiBtYWtlIGZ1ZGdlIHdpdGggY2hvY29sYXRlIG9yIHlvdSBjYW4gbWFrZSBpdCB3 aXRoIHBlYW51dCBidXR0ZXIgb3IgeW91IGNhbiBtYWtlIGl0IHdpdGggcG90YXRvZXMgaWYgeW91 IHdhbnQgdG8sIGJ1dCBpdCBuZWVkcyBhIGNvdXBsZSBpbmdyZWRpZW50cyBhbmQgYSB2ZXJ5IGNv bW1vbiBvbmUgaXMgY2hvY29sYXRlLiBPcGVuSUQgQ29ubmVjdCBpcyBhIHJlY2lwZSBmb3IgY2hv Y29sYXRlIGZ1ZGdlIHRoYXQgYSBsb3Qgb2YgcGVvcGxlIGxpa2UuIEFuZCBpdCBtYWtlcyBteSBm dWRnZSBjb21wYXRpYmxlIHdpdGggeW91ciBmdWRnZSwgd2hpY2ggaXMgd2hlcmUgdGhlIG1ldGFw aG9yIGJyZWFrcyBkb3duLiA6LSkKCgotLSBKdXN0aW4KCi8gU2VudCBmcm9tIG15IHBob25lIC8K CgotLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tCkZyb206IFNlcmdleSBCZXJ5b3pr aW4gPHNiZXJ5b3praW5AZ21haWwuY29tPiAKRGF0ZToxMC8xMy8yMDE0ICA2OjMzIEFNICAoR01U LTA1OjAwKSAKVG86IG9hdXRoQGlldGYub3JnIApDYzogIApTdWJqZWN0OiBSZTogW09BVVRILVdH XSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDSAgZHJhZnQtaHVudC1vYXV0aC12Mi11c2Vy LWE0Yy0wNS50eHQgCgpIaQoKV2UndmUgaGFkIGEgdXNlciBhc3NlcnRpbmcgdGhhdCAiT0F1dGgy ID09IE9wZW5pZENvbm5lY3QiLCByZWZlcnJpbmcgdG8gCnRoZSBmYWN0IHRoYXQgdGhlICdvbmx5 JyB0aGluZyBPSUMgYWRkcyBvbiB0b3Agb2YgdGhlIGF1dGhvcml6YXRpb24gY29kZSAKZmxvdyBp cyB0aGUgY2xpZW50IHNwZWNpZnlpbmcgZmV3IGV4dHJhIHNjb3BlcyBsaWtlICdvcGVuaWQnIGFu ZCAKJ3Byb2ZpbGUnIGFuZCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2aWNlIHJldHVybmluZyBhbiBl eHRyYSBwcm9wZXJ0eSwgdGhlIAppZF90b2tlbiB3aGljaCBjYW4gYmUgc3VmZmljaWVudCBpbiBv cmRlciB0byBnZXQgdGhlIGF1dGhlbnRpY2F0ZWQgCnVzZXIncyBpbmZvLgoKTXkgdW5kZXJzdGFu ZGluZyAiT0F1dGgyICE9IE9wZW5pZENvbm5lY3QiLCB0aGUgbGF0dGVyIHV0aWxpemVzIHRoZSAK Zm9ybWVyIGFuZCBpcyBhbiBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc20gd2hpY2ggaXMgbm90IHdo YXQgT0F1dGgyIGlzIAoobWF5IGJlIGV4Y2VwdCBmb3IgdGhlIGNsaWVudCBjcmVkZW50aWFscyku IEJ1dCBJIGRvbid0IGZlZWwgbGlrZSBpdCBpcyAKYSBjb252aW5jaW5nIGVub3VnaCBhcmd1bWVu dC4KCkkgdGhvdWdodCB0aGlzIHRocmVhZCB3YXMgcmVsZXZhbnQsIHNvcnJ5IGlmIG5vdCwgd291 bGQgaGF2ZSBubyBwcm9ibGVtcyAKc3RhcnRpbmcgYSBuZXcgb25lLgoKQmFzaWNhbGx5LCBJIHdv bmRlciB3aGF0IGlzIHRoZSBwcm9wZXIgbGluZSBvZiBhcmd1bWVudCBmb3IgYSBwb3NpdGlvbiAK c3VjaCBhcyAiT0F1dGgyICE9IE9wZW5pZENvbm5lY3QiIGFuZCBhbHNvIHdoYXQgd2FzIHRoZSBh Y3Rpb24gdG8gdGhlIApsaXN0IG9mIG9wdGlvbnMgc3VnZ2VzdGVkIGJ5IEpvaG4gYmVsb3cuIElz IGhhdmluZyBhbiBPSUQgcHJvZmlsZSB3aGVyZSAKbm8gYWNjZXNzIHRva2VuIGlzIHJldHVybmVk IHdvdWxkIGJlIHRoZSBjbGVhbmVzdCBhY3Rpb24gYXMgZmFyIGFzIApicmVha2luZyB0aGUgYW1i aWd1aXR5L2NvbmZ1c2lvbiBpcyBjb25jZXJuZWQgPwoKQ2hlZXJzLCBTZXJnZXkKCk9uIDI0LzA3 LzE0IDE1OjI1LCBKb2huIEJyYWRsZXkgd3JvdGU6Cj4gSSBhbSBub3QgYWdhaW5zdCBkaXNjdXNz aW9uIGluIHRoZSBXRy4KPgo+IEkgaGFwcGVuIHRvIGFncmVlIHdpdGggUGhpbCdzIGZ1bmRhbWVu dGFsIHByZW1pc2UgdGhhdCBzb21lIGRldmVsb3BlcnMKPiBhcmUgdXNpbmcgT0F1dGggaW4gYSBp bnNlY3VyZSB3YXkgdG8gZG8gYXV0aGVudGljYXRpb24uCj4KPiBUaGF0IHJhaXNlcyB0aGUgcXVl c3Rpb24gb2YgaG93IHRvIGJlc3QgZWR1Y2F0ZSB0aGVtLCBhbmQgb3IgYWRkcmVzcwo+IHRlY2hu aWNhbCBiYXJyaWVycy4KPgo+IEl0IGlzIG9uIHRoZSBzZWNvbmQgcG9pbnQgdGhhdCBwZW9wbGUn cyBvcGluaW9ucyBzZWVtIHRvIGRpdmlkZS4KPgo+IFNvbWUgcGVvcGxlIHRoaW5nIHRoYXQgaWYg d2UgaGF2ZSBhIE9BdXRoIGZsb3cgdGhhdCBlbGltaW5hdGVzIHRoZQo+IGFjY2VzcyB0b2tlbiAo cHJpbWFyaWx5IHRvIGF2b2lkIGFza2luZyBmb3IgY29uc2VudCBhcyBJIHVuZGVyc3RhbmQgaXQp Cj4gYW5kIGp1c3QgcmV0dXJuIGEgaWRfdG9rZW4gZnJvbSB0aGUgdG9rZW4gZW5kcG9pbnQgdGhh dCBjYW4gYmUgZG9uZSBpbiBhCj4gc3BlYyBzaG9ydCBlbm91Z2ggdG8gaGV0IHBlb3BsZSB0byBy ZWFkLiAgIFRoZSBzdWJ0ZXh0IG9mIHRoaXMgaXMgdGhhdAo+IHRoZSBDb25uZWN0IHNwZWNpZmlj YXRpb24gaXMgdG9vIGxhcmdlIHRoYXQgaXQgc2NhcmUgcGVvcGxlLCAgYW5kIHRoZXkKPiBkb24n dCBmaW5kIHRoZSBzcGVjIGluIHRoZSBmaXJzdCBwbGFjZSBiZWNhdXNlIGl0IGlzIG5vdCBhIFJG Qy4KPgo+IEFuIG90aGVyIGNvbW1vbiBwb3NzZXNzaW9uIGlzIHRoYXQgaWYgeW91IGRvbid0IHdh bnQgdG8gcHJvbXB0IHRoZSB1c2VyCj4gZm9yIGNvbnNlbnQgdGhlbiBkb24ndCBhc2sgZm9yIHNj b3Blcy4gIFR3aXN0aW5nIHRoZSBPQXV0aCBzcGVjIHRvIG5vdAo+IHJldHVybiBhbiBhY2Nlc3Mg dG9rZW4gaXMgbm90IE9BdXRoLCAgeWVzIHlvdSBjb3VsZCB1c2UgYSBkaWZmZXJlbnQKPiBlbmRw b2ludCByYXRoZXIgdGhhbiB0aGUgdG9rZW4gZW5kcG9pbnQsIGJ1dCB0aGF0IGlzIG5vdCBPQXV0 aC4KPiBDb25uZWN0IHdhcyBjYXJlZnVsIG5vdCB0byBicmVhayB0aGUgT0F1dGggc3BlYy4gICAg QXMgbG9uZyBhcyB5b3UgYXJlCj4gd2lsbGluZyB0byB0YWtlIGEgYWNjZXNzIHRva2VuIHdpdGgg bm8gc2NvcGVzICh0aGUgY2xpZW50IG5lZWRzIHRvCj4gdW5kZXJzdGFuZCB0aGF0IHRoZXJlIGFy ZSBubyBhdHRyaWJ1dGVzIG9uZSB3YXkgb3IgYW5vdGhlciBhbnl3YXkgb3IgaXQKPiB3aWxsIGJy ZWFrKSB0aGVuIHlvdSBkb24ndCBuZWVkIHRvIGNoYW5nZSBPQXV0aC4gICBZb3UgY2FuIHB1Ymxp c2ggYQo+IHByb2ZpbGUgb2YgY29ubmVjdCB0aGF0IHNhdGlzZmllcyB0aGUgdXNlIGNhc2UuCj4K PiBJIHRoaW5rIE1pa2UgaGFzIGxhcmdlbHkgZG9uZSB0aGF0IGJ1dCBpdCBtaWdodCBiZSBiZXR0 ZXIgYmVpbmcgbGVzcwo+IHN0aW5neSBvbiByZWZlcmVuY2VzIGJhY2sgdG8gdGhlIGxhcmdlciBz cGVjLgo+Cj4gVGhlIHF1ZXN0aW9ucyBhcmUgZG8gd2UgbW9kaWZ5IE9BdXRoIHRvIG5vdCByZXR1 cm4gYW4gYWNjZXNzIHRva2VuLCBhbmQKPiBpZiBzbyBob3csICBhbmQgaWYgd2UgZG8gaXMgaXQg c3RpbGwgT0F1dGguCj4KPiBUaGUgb3RoZXIgbGFyZ2VseSBzZXBhcmFibGUgcXVlc3Rpb24gaXMg ZG8gd2UgY3JlYXRlIGNvbmZ1c2lvbiBpbiB0aGUKPiBtYXJrZXQgYW5kIHNsb3cgdGhlIHRoZSBh ZG9wdGlvbiBvZiBpZGVudGl0eSBmZWRlcmF0aW9uIG9uIHRvcCBvZiBPQXV0aCwKPiBvciBmaW5k IGEgd2F5IHRvIG1ha2UgdGhpcyBsb29rIGxpa2UgYSBwb3NpdGl2ZSBhbGlnbm1lbnQgb2YgaW50 ZXJlc3RzCj4gYXJvdW5kIGEgc3Vic2V0IG9mIENvbm5lY3QuCj4KPiBUaGVyZSBhcmUgYSBudW1i ZXIgb2Ygb3B0aW9ucy4KPiAxOiBXZSBjYW4gZG8gYSBwcm9maWxlIGluIHRoZSBPSURGIGFuZCBw dWJsaXNoIGl0IGFzIGEgSUVURiBkb2N1bWVudC4KPiBQZXJoYXBzIHRoZSBjbGVhbmVzdCBmcm9t IGFuIElQUiBwb2ludCBvZiB2aWV3Lkhvd2V2ZXIKPiAyOldlIGNhbiBkbyBhIHByb2ZpbGUgaW4g dGhlIE9BdXRoIFdHIHJlZmVyZW5jaW5nIGNvbm5lY3QuCj4gMzpXZSBjYW4gZG8gYSBBRCBzcG9u c29yZWQgcHJvZmlsZSB0aGF0IGlzIG5vdCBpbiB0aGUgT0F1dGggV0cuCj4gNDpXZSBjYW4gZG8g YSBzbWFsbCBzcGVjIGluIE9BdXRoIHRvIGFkZCByZXNwb25zZV90eXBlIHRvIHRoZSB0b2tlbgo+ IGVuZHBvaW50LiAgaW4gY29tYmluYXRpb24gd2l0aCAxLCAyLCBvciAzCj4KPiBJIGFncmVlIHRo YXQgc3RvcGluZyBkZXZlbG9wZXJzIGRvaW5nIGluc2VjdXJlIHRoaW5ncyBuZWVkcyB0byBiZQo+ IGFkZHJlc3NlZCBzb21laG93Lgo+IEkgYW0gbm90IHBlcnNvbmFsbHkgY29udmluY2VkIHRoYXQg T2F1dGggd2l0aG91dCBhY2Nlc3MgdG9rZW5zIGlzIHNlbnNpYmxlLgo+Cj4gTG9va2luZyBmb3J3 YXJkIHRvIHRoZSBtZWV0aW5nOikKPgo+IEpvaG4gQi4KPiBPbiBKdWwgMjQsIDIwMTQsIGF0IDY6 NTIgQU0sIEJyaWFuIENhbXBiZWxsIDxiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbQo+IDxtYWls dG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20+PiB3cm90ZToKPgo+PiBJJ2Qgbm90ZSB0aGF0 IHRoZSByZWFjdGlvbiBhdCB0aGUgY29uZmVyZW5jZSB0byBJYW4ncyBzdGF0ZW1lbnQgd2FzCj4+ IG92ZXJ3aGVsbWluZ2x5IHBvc2l0aXZlLiBUaGVyZSB3YXMgYSB3aWRlIHJhbmdlIG9mIGluZHVz dHJ5IHBlb3BsZQo+PiBoZXJlIC0gaW1wbGVtZW50ZXJzLCBwcmFjdGl0aW9uZXJzLCBkZXBsb3ll cnMsIHN0cmF0ZWdpc3RzLCBldGMuIC0gYW5kCj4+IGl0IHNlZW1zIHByZXR0eSBjbGVhciB0aGF0 IHRoZSAicm91Z2ggY29uc2Vuc3VzIiBvZiB0aGUgaW5kdXN0cnkgYXQKPj4gbGFyZ2UgaXMgdGhh dCBhNGMgaXMgbm90IHdhbnRlZCBvciBuZWVkZWQuCj4+Cj4+Cj4+IE9uIFRodSwgSnVsIDI0LCAy MDE0IGF0IDU6MjkgQU0sIE5hdCBTYWtpbXVyYSA8c2FraW11cmFAZ21haWwuY29tCj4+IDxtYWls dG86c2FraW11cmFAZ21haWwuY29tPj4gd3JvdGU6Cj4+Cj4+ICAgICBBbmQgaGVyZSBpcyBhIHF1 b3RlIGZyb20gSWFuJ3MgYmxvZy4KPj4KPj4gICAgICAgICBBbmQgYWx0aG91Z2ggdGhlIGF1dGhl bnRpY2F0aW9uIHdoZWVsIGlzIHJvdW5kLCB0aGF0IGRvZXNu4oCZdAo+PiAgICAgICAgIG1lYW4g aXQgaXNu4oCZdCB3aXRob3V0IGl0cyBsdW1wcy4gRmlyc3QsIHdlIGRvIHNlZSBzb21lCj4+ICAg ICAgICAgcmVpbnZlbnRpbmcgdGhlIHdoZWVsIGp1c3QgdG8gcmVpbnZlbnQgdGhlIHdoZWVsLiBP QXV0aCBBNEMgaXMKPj4gICAgICAgICBzaW1wbHkgbm90IGEgZnJ1aXRmdWwgYWN0aXZpdHkgYW5k IHNob3VsZCBiZSBwdXQgZG93bi4KPj4KPj4gICAgICAgICAoU291cmNlKQo+PiAgICAgICAgIGh0 dHA6Ly93d3cudHVlc2RheW5pZ2h0Lm9yZy8yMDE0LzA3LzIzL2RvLXdlLWhhdmUtYS1yb3VuZC13 aGVlbC15ZXQtbXVzaW5ncy1vbi1pZGVudGl0eS1zdGFuZGFyZHMtcGFydC0xLmh0bWwKPj4KPj4K Pj4KPj4gICAgIDIwMTQtMDctMjMgMTY6NTMgR01ULTA0OjAwIEpvaG4gQnJhZGxleSA8dmU3anRi QHZlN2p0Yi5jb20KPj4gICAgIDxtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20+PjoKPj4KPj4gICAg ICAgICBJIHRob3VnaHQgSSBkaWQgcG9zdCB0aGlzIHRvIHRoZSBsaXN0Lgo+Pgo+PiAgICAgICAg IEkgZ3Vlc3MgSSBoaXQgdGhlIHdyb25nIHJlcGx5IG9uIG15IHBob25lLgo+PiAgICAgICAgIEpv aG4gQi4KPj4gICAgICAgICBTZW50IGZyb20gbXkgaVBob25lCj4+Cj4+ICAgICAgICAgT24gSnVs IDIzLCAyMDE0LCBhdCA0OjUwIFBNLCB0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldAo+PiAgICAgICAg IDxtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+IHdyb3RlOgo+Pgo+Pj4gICAgICAgICB3 ZSBhcmUgdHdvLCBhdCBsZWFzdCA6LSkKPj4+Cj4+PiAgICAgICAgIFdoeSBkaWRuJ3QgeW91IHBv c3QgdGhpcyBvbiB0aGUgbGlzdD8KPj4+Cj4+PiAgICAgICAgIFdoZW4gd2lsbCBiZSBiZSBhcnJp dmluZz8KPj4+Cj4+PiAgICAgICAgIEFtIDIzLjA3LjIwMTQgMTY6MzksIHNjaHJpZWIgSm9obiBC cmFkbGV5Ogo+Pj4KPj4+PiAgICAgICAgIElhbiBHbGF6ZXIgbWVudGlvbmVkIHRoaXMgaW4gaGlz IGtleW5vdGUgYXQgQ0lTIHllc3RlcmRheS4KPj4+PiAgICAgICAgIEhpcyBhZHZpY2Ugd2FzIHBs ZWFzZSBzdG9wLCAgd2UgYXJlIGNyZWF0aW5nIGNvbmZ1c2lvbiBhbmQKPj4+PiAgICAgICAgIHVu Y2VydGFpbnR5Lgo+Pj4+ICAgICAgICAgV2UgYXJlIGJlY29taW5nIG91ciBvd24gd29ydCBlbmVt eS4gKCBteSB2aWV3IHRob3VnaCBJYW4gbWF5Cj4+Pj4gICAgICAgICBzaGFyZSBpdCkKPj4+PiAg ICAgICAgIFJldHVybmluZyBqdXN0IGFuIGlkXyB0b2tlbiBmcm9tIHRoZSB0b2tlbiBlbmRwb2lu dCBoYXMKPj4+PiAgICAgICAgIGxpdHRsZSByZWFsIHZhbHVlLgo+Pj4+ICAgICAgICAgU29tZXRo aW5nIHJlYWxseSB1c2VmdWwgdG8gZG8gd291bGQgYmUgc29ydGluZyBvdXQKPj4+PiAgICAgICAg IGNoYW5uZWxfaWQgc28gd2UgY2FuIGRvIFBvUCBmb3IgaWQgdG9rZW5zIHRvIG1ha2UgdGhlbSBh bmQKPj4+PiAgICAgICAgIG90aGVyIGNvb2tpZXMgc2VjdXJlIGluIHRoZSBmcm9udCBjaGFubmVs LiAgIEkgdGhpbmsgdGhhdCBpcwo+Pj4+ICAgICAgICAgYSBiZXR0ZXIgdXNlIG9mIHRpbWUuCj4+ Pj4gICAgICAgICBJIG1heSBiZSBpbiB0aGUgbWlub3JpdHkgb3BpbmlvbiBvbiB0aGF0LCAgaXQg d29uJ3QgYmUgdGhlCj4+Pj4gICAgICAgICBmaXJzdCB0aW1lLgo+Pj4+Cj4+Pj4KPj4+PiAgICAg ICAgIEpvaG4gQi4KPj4+PiAgICAgICAgIFNlbnQgZnJvbSBteSBpUGhvbmUKPj4+Pgo+Pj4+ICAg ICAgICAgT24gSnVsIDIzLCAyMDE0LCBhdCA0OjA0IFBNLCBUb3JzdGVuIExvZGRlcnN0ZWR0Cj4+ Pj4gICAgICAgICA8dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQgPG1haWx0bzp0b3JzdGVuQGxvZGRl cnN0ZWR0Lm5ldD4+Cj4+Pj4gICAgICAgICB3cm90ZToKPj4+Pgo+Pj4+PiAgICAgICAgIFlvdSBh cmUgcmlnaHQgZnJvbSBhIHRoZW9yZXRpY2FsIHBlcnNwZWN0aXZlLiBQcmFjdGljYWxseQo+Pj4+ PiAgICAgICAgIHRoaXMgd2FzIGNhdXNlZCBieSBlZGl0b3JpYWwgZGVjaXNpb25zIGR1cmluZyB0 aGUgY3JlYXRpb24KPj4+Pj4gICAgICAgICBvZiB0aGUgUkZDLiBBcyBmYXIgYXMgSSByZW1lbWJl ciwgdGhlcmUgd2FzIGEgZGVmaW5pdGlvbiBvZgo+Pj4+PiAgICAgICAgIHRoZSAob25lKSB0b2tl biBlbmRwb2ludCByZXNwb25zZSBpbiBlYXJseSB2ZXJzaW9ucy4gTm8gb25lCj4+Pj4+ICAgICAg ICAgZXZlcnkgY29uc2lkZXJlZCB0byBOT1QgcmVzcG9uZCB3aXRoIGFuIGFjY2VzcyB0b2tlbiBm cm9tCj4+Pj4+ICAgICAgICAgdGhlIHRva2VuIGVuZHBvaW50LiBTbyBvbmUgbWlnaHQgY2FsbCBp dCBhbiBpbXBsaWNpdAo+Pj4+PiAgICAgICAgIGFzc3VtcHRpb24uCj4+Pj4+ICAgICAgICAgSSdt IHdvcnJpZWQgdGhhdCBwZW9wbGUgZ2V0IHRvdGFsbHkgY29uZnVzZWQgaWYgYW4KPj4+Pj4gICAg ICAgICBleGNlcHRpb24gaXMgaW50cm9kdWNlZCBub3cgZ2l2ZW4gdGhlIGJyb2FkIGFkb3B0aW9u IG9mCj4+Pj4+ICAgICAgICAgT0F1dGggYmFzZWQgb24gdGhpcyBhc3N1bXB0aW9uLgo+Pj4+PiAg ICAgICAgIHJlZ2FyZHMsCj4+Pj4+ICAgICAgICAgVG9yc3Rlbi4KPj4+Pj4KPj4+Pj4gICAgICAg ICBBbSAyMy4wNy4yMDE0IHVtIDE1OjQxIHNjaHJpZWIgVGhvbWFzIEJyb3llcgo+Pj4+PiAgICAg ICAgIDx0LmJyb3llckBnbWFpbC5jb20gPG1haWx0bzp0LmJyb3llckBnbWFpbC5jb20+PjoKPj4+ Pj4KPj4+Pj4+ICAgICAgICAgSXMgaXQgc2FpZCBhbnl3aGVyZSB0aGF0IEFMTCBncmFudCB0eXBl cyBNVVNUIHVzZSBTZWN0aW9uCj4+Pj4+PiAgICAgICAgIDUuMSByZXNwb25zZXM/IEVhY2ggZ3Jh bnQgdHlwZSByZWZlcmVuY2VzIFNlY3Rpb24gNS4xLCBhbmQKPj4+Pj4+ICAgICAgICAgImFjY2Vz cyB0b2tlbiByZXF1ZXN0IiBpcyBvbmx5IGRlZmluZWQgaW4gdGhlIGNvbnRleHQgb2YKPj4+Pj4+ ICAgICAgICAgdGhlIGRlZmluZWQgZ3JhbnQgdHlwZXMuIFNlY3Rpb24gMi4yIGRvZXNuJ3QgdGFs ayBhYm91dAo+Pj4+Pj4gICAgICAgICB0aGUgcmVxdWVzdCBvciByZXNwb25zZSBmb3JtYXQuCj4+ Pj4+Pgo+Pj4+Pj4gICAgICAgICBMZSAyMyBqdWlsLiAyMDE0IDIxOjMyLCAiTmF0IFNha2ltdXJh IiA8c2FraW11cmFAZ21haWwuY29tCj4+Pj4+PiAgICAgICAgIDxtYWlsdG86c2FraW11cmFAZ21h aWwuY29tPj4gYSDDqWNyaXQgOgo+Pj4+Pj4KPj4+Pj4+ICAgICAgICAgICAgIElzIGl0PyBBcGFy dCBmcm9tIHRoZSBpbXBsaWNpdCBncmFudCB0aGF0IGRvZXMgbm90IHVzZQo+Pj4+Pj4gICAgICAg ICAgICAgdG9rZW4gZW5kcG9pbnQsIGFsbCBvdGhlciBncmFudCByZWZlcmVuY2VzIHNlY3Rpb24g NS4xCj4+Pj4+PiAgICAgICAgICAgICBmb3IgdGhlIHJlc3BvbnNlLCBpLmUuLCBhbGwgc2hhcmVz IHRoZSBzYW1lIHJlc3BvbnNlLgo+Pj4+Pj4KPj4+Pj4+Cj4+Pj4+PiAgICAgICAgICAgICAyMDE0 LTA3LTIzIDE1OjE4IEdNVC0wNDowMCBUaG9tYXMgQnJveWVyCj4+Pj4+PiAgICAgICAgICAgICA8 dC5icm95ZXJAZ21haWwuY29tIDxtYWlsdG86dC5icm95ZXJAZ21haWwuY29tPj46Cj4+Pj4+Pgo+ Pj4+Pj4gICAgICAgICAgICAgICAgIEkgaGFkbid0IHJlYWxpemVkIHRoZSBKU09OIHJlc3BvbnNl IHRoYXQgcmVxdWlyZXMKPj4+Pj4+ICAgICAgICAgICAgICAgICB0aGUgYWNjZXNzX3Rva2VuIGZp ZWxkIGlzIGRlZmluZWQgcGVyIGdyYW50X3R5cGUsCj4+Pj4+PiAgICAgICAgICAgICAgICAgc28g SSdkIGJlIE9LIHRvICJleHRlbmQgdGhlIHNlbWFudGljcyIgYXMgaW4gdGhlCj4+Pj4+PiAgICAg ICAgICAgICAgICAgY3VycmVudCBkcmFmdC4KPj4+Pj4+ICAgICAgICAgICAgICAgICBUaGF0IHdh cyBhY3R1YWxseSBteSBtYWluIGNvbmNlcm46IHRoYXQgdGhlIHRva2VuCj4+Pj4+PiAgICAgICAg ICAgICAgICAgZW5kcG9pbnQgbWFuZGF0ZXMgYWNjZXNzX3Rva2VuOyBidXQgaXRzIGFjdHVhbGx5 Cj4+Pj4+PiAgICAgICAgICAgICAgICAgbm90IHRoZSBjYXNlLgo+Pj4+Pj4KPj4+Pj4+ICAgICAg ICAgICAgICAgICBMZSAyMyBqdWlsLiAyMDE0IDIwOjQ2LCAiTmF0IFNha2ltdXJhIgo+Pj4+Pj4g ICAgICAgICAgICAgICAgIDxzYWtpbXVyYUBnbWFpbC5jb20gPG1haWx0bzpzYWtpbXVyYUBnbWFp bC5jb20+PiBhCj4+Pj4+PiAgICAgICAgICAgICAgICAgw6ljcml0IDoKPj4+Pj4+Cj4+Pj4+PiAg ICAgICAgICAgICAgICAgICAgIEkgYWdyZWUgd2l0aCBKb2huIHRoYXQgb3ZlcmxvYWRpbmcKPj4+ Pj4+ICAgICAgICAgICAgICAgICAgICAgcmVzcG9uc2VfdHlwZSBAIGF1dGh6IGVuZHBvaW50IGlz IGEgYmFkIGlkZWEuCj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgIEl0IGNvbXBsZXRlbHkgY2hh bmdlcyB0aGUgc2VtYW50aWNzIG9mIHRoaXMKPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgcGFy YW1ldGVyLiBOT1RFOiB3aGF0IEkgd2FzIHByb3Bvc2luZyB3YXMgbm90Cj4+Pj4+PiAgICAgICAg ICAgICAgICAgICAgIHRoaXMgcGFyYW1ldGVyLCBidXQgYSBuZXcgcGFyYW1ldGVyCj4+Pj4+PiAg ICAgICAgICAgICAgICAgICAgIHJlc3BvbnNlX3R5cGUgQCB0b2tlbiBlbmRwb2ludC4KPj4+Pj4+ ICAgICAgICAgICAgICAgICAgICAgSSBhbHNvIHRoaW5rIG92ZXJsb2FkaW5nIGdyYW50X3R5cGUg aXMgYSBiYWQKPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgaWRlYSBzaW5jZSBpdCBjaGFuZ2Vz IGl0cyBzZW1hbnRpY3MuIEkgcXVvdGUKPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgdGhlIGRl ZmluaXRpb24gaGVyZSBhZ2FpbjoKPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgZ3JhbnQKPj4+ Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgIGNyZWRlbnRpYWwgcmVwcmVzZW50aW5nIHRoZSBy ZXNvdXJjZQo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICBvd25lcidzIGF1dGhvcml6YXRpb24K Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgZ3JhbnRfdHlwZQo+Pj4+Pj4gICAgICAgICAgICAg ICAgICAgICB0eXBlIG9mIGdyYW50IHNlbnQgdG8gdGhlIHRva2VuIGVuZHBvaW50IHRvCj4+Pj4+ PiAgICAgICAgICAgICAgICAgICAgIG9idGFpbiB0aGUgYWNjZXNzIHRva2VuCj4+Pj4+PiAgICAg ICAgICAgICAgICAgICAgIEl0IGlzIG5vdCBhYm91dCBjb250cm9sbGluZyB3aGF0IGlzIHRvIGJl Cj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgIHJldHVybmVkIGZyb20gdGhlIHRva2VuIGVuZHBv aW50LCBidXQgdGhlIGhpbnQKPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgdG8gdGhlIHRva2Vu IGVuZHBvaW50IGRlc2NyaWJpbmcgdGhlIHR5cGUgb2YKPj4+Pj4+ICAgICAgICAgICAgICAgICAg ICAgY3JlZGVudGlhbCB0aGUgZW5kcG9pbnQgaGFzIHJlY2VpdmVkLiBJdCBzZWVtcwo+Pj4+Pj4g ICAgICAgICAgICAgICAgICAgICB0aGUgImNvbnRyb2wgb2Ygd2hhdCBpcyBiZWluZyByZXR1cm5l ZCBmcm9tCj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgIHRva2VuIGVuZHBvaW50IiAgaXMganVz dCBhIHNpZGUgZWZmZWN0Lgo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICBJIGFtIHNvbWV3aGF0 IGFtYml2YWxlbnRbMV0gaW4gY2hhbmdpbmcgdGhlCj4+Pj4+PiAgICAgICAgICAgICAgICAgICAg IHNlbWFudGljcyBvZiB0b2tlbiBlbmRwb2ludCwgYnV0IGluIGFzIG11Y2ggYXMKPj4+Pj4+ICAg ICAgICAgICAgICAgICAgICAgInRleHQgaXMgdGhlIGtpbmciIGZvciBhIHNwZWMuLCB3ZSBwcm9i YWJseQo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICBzaG91bGQgbm90IGNoYW5nZSB0aGUgc2Vt YW50aWNzIG9mIGl0IGFzCj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgIFRvcnN0ZW4gcG9pbnRz IG91dC4gSWYgaXQgaXMgb2sgdG8gY2hhbmdlIHRoaXMKPj4+Pj4+ICAgICAgICAgICAgICAgICAg ICAgc2VtYW50aWNzLCBJIGJlbGlldmUgZGVmaW5pbmcgYSBuZXcgcGFyYW1ldGVyCj4+Pj4+PiAg ICAgICAgICAgICAgICAgICAgIHRvIHRoaXMgZW5kcG9pbnQgdG8gY29udHJvbCB0aGUgcmVzcG9u c2Ugd291bGQKPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgYmUgdGhlIGJlc3Qgd2F5IHRvIGdv LiBUaGlzIGlzIHdoYXQgSSBoYXZlCj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgIGRlc2NyaWJl ZCBwcmV2aW91c2x5Lgo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICBEZWZpbmluZyBhIG5ldyBl bmRwb2ludCB0byBzZW5kIGNvZGUgdG8gZ2V0IElECj4+Pj4+PiAgICAgICAgICAgICAgICAgICAg IFRva2VuIGFuZCBmb3JiaWRkaW5nIHRoZSB1c2Ugb2YgaXQgYWdhaW5zdAo+Pj4+Pj4gICAgICAg ICAgICAgICAgICAgICB0b2tlbiBlbmRwb2ludCB3b3VsZCBub3QgY2hhbmdlIHRoZSBzZW1hbnRp Y3MKPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgb2YgYW55IGV4aXN0aW5nIHBhcmFtZXRlciBv ciBlbmRwb2ludCwgd2hpY2gKPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgaXMgZ29vZC4gSG93 ZXZlciwgSSBkb3VidCBpZiBpdCBpcyBub3Qgd29ydGgKPj4+Pj4+ICAgICAgICAgICAgICAgICAg ICAgZG9pbmcuIFdoYXQncyB0aGUgcG9pbnQgb2YgYXZvaWRpbmcgYWNjZXNzCj4+Pj4+PiAgICAg ICAgICAgICAgICAgICAgIHRva2VuIHNjb3BlZCB0byBVc2VySW5mbyBlbmRwb2ludCBhZnRlciBh bGw/Cj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgIERlZmluaW5nIGEgbmV3IGVuZHBvaW50IGZv ciBqdXN0IGF2b2lkaW5nIHRoZQo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICBhY2Nlc3MgdG9r ZW4gZm9yIHVzZXJpbmZvIGVuZHBvaW50IHNlZW1zIHdheQo+Pj4+Pj4gICAgICAgICAgICAgICAg ICAgICB0b28gbXVjaCB0aGUgaGVhdnkgd2FpdCB3YXkgYW5kIGl0IGJyZWFrcwo+Pj4+Pj4gICAg ICAgICAgICAgICAgICAgICBpbnRlcm9wZXJhYmlsaXk6IGl0IGRlZmVhdHMgdGhlIHB1cnBvc2Ug b2YKPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgc3RhbmRhcmRpemF0aW9uLgo+Pj4+Pj4gICAg ICAgICAgICAgICAgICAgICBJIGhhdmUgc3RhcnRlZCBmZWVsaW5nIHRoYXQgbm8gY2hhbmdlIGlz IHRoZQo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICBiZXN0IHdheSBvdXQuCj4+Pj4+PiAgICAg ICAgICAgICAgICAgICAgIE5hdAo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICBbMV0gIElmIGlu c3RlYWQgb2Ygc2F5aW5nICJUb2tlbiBlbmRwb2ludCAtCj4+Pj4+PiAgICAgICAgICAgICAgICAg ICAgIHVzZWQgYnkgdGhlIGNsaWVudCB0byBleGNoYW5nZSBhbgo+Pj4+Pj4gICAgICAgICAgICAg ICAgICAgICBhdXRob3JpemF0aW9uIGdyYW50IGZvciBhbiBhY2Nlc3MgdG9rZW4sCj4+Pj4+PiAg ICAgICAgICAgICAgICAgICAgIHR5cGljYWxseSB3aXRoIGNsaWVudCBhdXRoZW50aWNhdGlvbiIs IGl0IHdlcmUKPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgc2F5aW5nICJUb2tlbiBlbmRwb2lu dCAtIHVzZWQgYnkgdGhlIGNsaWVudCB0bwo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICBleGNo YW5nZSBhbiBhdXRob3JpemF0aW9uIGdyYW50IGZvciB0b2tlbnMsCj4+Pj4+PiAgICAgICAgICAg ICAgICAgICAgIHR5cGljYWxseSB3aXRoIGNsaWVudCBhdXRoZW50aWNhdGlvbiIsIHRoZW4gaXQK Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgd291bGQgaGF2ZSBiZWVuIE9LLiBJdCBpcyBhbiBl eHBhbnNpb24gb2YgdGhlCj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgIGNhcGFiaWxpdHkgcmF0 aGVyIHRoYW4gY2hhbmdpbmcgdGhlIHNlbWFudGljcy4KPj4+Pj4+Cj4+Pj4+Pgo+Pj4+Pj4gICAg ICAgICAgICAgICAgICAgICAyMDE0LTA3LTIzIDEzOjM5IEdNVC0wNDowMCBNaWtlIEpvbmVzCj4+ Pj4+PiAgICAgICAgICAgICAgICAgICAgIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20KPj4+ Pj4+ICAgICAgICAgICAgICAgICAgICAgPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5j b20+PjoKPj4+Pj4+Cj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICBZb3UgbmVlZCB0aGUg YWx0ZXJuYXRpdmUgcmVzcG9uc2VfdHlwZQo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAg dmFsdWUgKCJjb2RlX2Zvcl9pZF90b2tlbiIgaW4gdGhlIEE0Qwo+Pj4+Pj4gICAgICAgICAgICAg ICAgICAgICAgICAgZHJhZnQpIHRvIHRlbGwgdGhlIEF1dGhvcml6YXRpb24gU2VydmVyIHRvCj4+ Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICByZXR1cm4gYSBjb2RlIHRvIGJlIHVzZWQgd2l0 aCB0aGUgbmV3Cj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICBncmFudCB0eXBlLCByYXRo ZXIgdGhhbiBvbmUgdG8gdXNlIHdpdGgKPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgIHRo ZSAiYXV0aG9yaXphdGlvbl9jb2RlIiBncmFudCB0eXBlICh3aGljaAo+Pj4+Pj4gICAgICAgICAg ICAgICAgICAgICAgICAgaXMgd2hhdCByZXNwb25zZV90eXBlPWNvZGUgZG9lcykuCj4+Pj4+Pgo+ Pj4+Pj4KPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICpGcm9tOipPQXV0aAo+Pj4+Pj4g ICAgICAgICAgICAgICAgICAgICAgICAgW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnCj4+ Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICA8bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5v cmc+XSAqT24KPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgIEJlaGFsZiBPZiAqSm9obiBC cmFkbGV5Cj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAqU2VudDoqIFdlZG5lc2RheSwg SnVseSAyMywgMjAxNCAxMDozMyBBTQo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgKlRv OiogdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQKPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAg IDxtYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+Cj4+Pj4+Pgo+Pj4+Pj4KPj4+Pj4+ICAg ICAgICAgICAgICAgICAgICAgICAgICpDYzoqIG9hdXRoQGlldGYub3JnIDxtYWlsdG86b2F1dGhA aWV0Zi5vcmc+Cj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAqU3ViamVjdDoqIFJlOiBb T0FVVEgtV0ddIE5ldyBWZXJzaW9uCj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICBOb3Rp ZmljYXRpb24gZm9yCj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICBkcmFmdC1odW50LW9h dXRoLXYyLXVzZXItYTRjLTA1LnR4dAo+Pj4+Pj4KPj4+Pj4+Cj4+Pj4+PiAgICAgICAgICAgICAg ICAgICAgICAgICBJZiB3ZSB1c2UgdGhlIHRva2VuIGVuZHBvaW50IHRoZW4gYSBuZXcKPj4+Pj4+ ICAgICAgICAgICAgICAgICAgICAgICAgIGdyYW50X3R5cGUgaXMgdGhlIGJlc3Qgd2F5Lgo+Pj4+ Pj4KPj4+Pj4+Cj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICBJdCBzb3J0IG9mIG92ZXJs b2FkcyBjb2RlLCBidXQgdGhhdCBpcwo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgYmV0 dGVyIHRoYW4gbWVzc2luZyB3aXRoIHJlc3BvbnNlX3R5cGUgZm9yCj4+Pj4+PiAgICAgICAgICAg ICAgICAgICAgICAgICB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCB0byBjaGFuZ2UgdGhlCj4+ Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICByZXNwb25zZSBmcm9tIHRoZSB0b2tlbl9lbmRw b2ludC4gIFRoYXQgaXMKPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgIGluIG15IG9waW5p b24gYSBjaGFtcGlvbiBiYWQgaWRlYS4KPj4+Pj4+Cj4+Pj4+Pgo+Pj4+Pj4gICAgICAgICAgICAg ICAgICAgICAgICAgSW4gZGlzY3Vzc2lvbnMgZGV2ZWxvcGluZyBDb25uZWN0IHdlCj4+Pj4+PiAg ICAgICAgICAgICAgICAgICAgICAgICBkZWNpZGVkIG5vdCB0byBvcGVuIHRoaXMgY2FuIG9mIHdv cm1zCj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICBiZWNhdXNlIG5vIGdvb2Qgd291bGQg Y29tZSBvZiBpdC4KPj4+Pj4+Cj4+Pj4+Pgo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAg VGhlIHRva2VuX2VuZHBvaW50IHJldHVybnMgYSBhY2Nlc3MgdG9rZW4uCj4+Pj4+PiAgICAgICAg ICAgICAgICAgICAgICAgICAgTm90aGluZyByZXF1aXJlcyBzY29wZSB0byBiZSBhc3NvY2lhdGVz Cj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICB3aXRoIHRoZSB0b2tlbi4KPj4+Pj4+Cj4+ Pj4+Pgo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgVGhhdCBpcyB0aGUgYmVzdCBzb2x1 dGlvbi4gIE5vIGNoYW5nZQo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgcmVxdWlyZWQu ICBCZXR0ZXIgaW50ZXJvcGVyYWJpbGl0eSBpbiBteQo+Pj4+Pj4gICAgICAgICAgICAgICAgICAg ICAgICAgb3Bpbmlvbi4KPj4+Pj4+Cj4+Pj4+Pgo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAg ICAgU3RpbGwgb24gbXkgd2F5IHRvIFRPLCBnZXR0aW5nIGluIGxhdGVyCj4+Pj4+PiAgICAgICAg ICAgICAgICAgICAgICAgICB0b2RheS4KPj4+Pj4+Cj4+Pj4+Pgo+Pj4+Pj4gICAgICAgICAgICAg ICAgICAgICAgICAgSm9obiBCLgo+Pj4+Pj4KPj4+Pj4+Cj4+Pj4+Pgo+Pj4+Pj4KPj4+Pj4+ICAg ICAgICAgICAgICAgICAgICAgICAgIFNlbnQgZnJvbSBteSBpUGhvbmUKPj4+Pj4+Cj4+Pj4+Pgo+ Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgT24gSnVsIDIzLCAyMDE0LCBhdCAxMjoxNSBQ TSwKPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgIHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0 Cj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICA8bWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3Rl ZHQubmV0PiB3cm90ZToKPj4+Pj4+Cj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg VGhlICJyZXNwb25zZSB0eXBlIiBvZiB0aGUgdG9rZW4KPj4+Pj4+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBlbmRwb2ludCBpcyBjb250cm9sbGVkIGJ5IHRoZSB2YWx1ZSBvZgo+Pj4+Pj4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoZSBwYXJhbWV0ZXIgImdyYW50X3R5cGUiLiBT byB0aGVyZQo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIGlzIG5vIG5lZWQgdG8g aW50cm9kdWNlIGEgbmV3IHBhcmFtZXRlci4KPj4+Pj4+Cj4+Pj4+PiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgd3J0IHRvIGEgcG90ZW50aWFsICJub19hY2Nlc3NfdG9rZW4iCj4+Pj4+PiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgZ3JhbnQgdHlwZS4gSSBkbyBub3QgY29uc2lkZXIg dGhpcyBhCj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZ29vZCBpZGVhIGFzIGl0 IGNoYW5nZXMgdGhlIHNlbWFudGljcwo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAg IG9mIHRoZSB0b2tlbiBlbmRwb2ludCAoYXMgYWxyZWFkeQo+Pj4+Pj4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHBvaW50ZWQgb3V0IGJ5IFRob21hcykuIFRoaXMgZW5kcG9pbnQKPj4+Pj4+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBTFdBWVMgcmVzcG9uZHMgd2l0aCBhbiBhY2Nl c3MgdG9rZW4KPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0byBhbnkgZ3JhbnQg dHlwZS4gSSB0aGVyZWZvcmUgd291bGQKPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBwcmVmZXIgdG8gdXNlIGFub3RoZXIgZW5kcG9pbnQgZm9yIHRoZQo+Pj4+Pj4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgIGludGVuZGVkIHB1cnBvc2UuCj4+Pj4+Pgo+Pj4+Pj4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHJlZ2FyZHMsCj4+Pj4+PiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgVG9yc3Rlbi4KPj4+Pj4+Cj4+Pj4+Pgo+Pj4+Pj4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgIEFtIDIzLjA3LjIwMTQgMTM6MDQsIHNjaHJpZWIgTmF0IFNha2ltdXJhOgo+Pj4+ Pj4KPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSU1ITywgY2hhbmdpbmcg dGhlIHNlbWFudGljcyBvZgo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAi cmVzcG9uc2VfdHlwZSIgQCBhdXRoeiBlbmRwb2ludAo+Pj4+Pj4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB0aGlzIHdheSBpcyBub3QgYSBnb29kIHRoaW5nLgo+Pj4+Pj4KPj4+Pj4+ Cj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEluc3RlYWQsIGRlZmluaW5n IGEgbmV3IHBhcmFtZXRlcgo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAi cmVzcG9uc2VfdHlwZSIgQCB0b2tlbiBlbmRwb2ludCwKPj4+Pj4+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgYXMgSSBkZXNjcmliZWQgaW4gbXkgcHJldmlvdXMKPj4+Pj4+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgbWVzc2FnZSwKPj4+Pj4+Cj4+Pj4+PiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHByb2JhYmx5IGlzIGJldHRlci4gQXQgbGVhc3QsIGl0 Cj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGRvZXMgbm90IGNoYW5nZSB0 aGUgc2VtYW50aWNzIG9mCj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRo ZSBwYXJhbWV0ZXJzIG9mIFJGQzY3NDkuCj4+Pj4+Pgo+Pj4+Pj4KPj4+Pj4+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIE5hdAo+Pj4+Pj4KPj4+Pj4+Cj4+Pj4+PiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIDIwMTQtMDctMjMgMTI6NDggR01ULTA0OjAwIFRob21hcwo+ Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBCcm95ZXIgPHQuYnJveWVyQGdt YWlsLmNvbQo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8bWFpbHRvOnQu YnJveWVyQGdtYWlsLmNvbT4+Ogo+Pj4+Pj4KPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgTm8sIEkgbWVhbiByZXNwb25zZV90eXBlPW5vbmUgYW5kCj4+Pj4+PiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHJlc3BvbnNlX3R5cGU9aWRfdG9rZW4gZG9uJ3QKPj4+ Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZ2VuZXJhdGUgYSBjb2RlIG9yIGFj Y2VzcyB0b2tlbiBzbwo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB5b3Ug ZG9uJ3QgdXNlIHRoZSBUb2tlbiBFbmRwb2ludAo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAod2hpY2ggaXMgbm90IHRoZSBzYW1lIGFzIHRoZQo+Pj4+Pj4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBBdXRoZW50aWNhdGlvbiBFbmRwb2ludCBCVFcpLgo+Pj4+ Pj4KPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgV2l0aAo+Pj4+Pj4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICByZXNwb25zZV90eXBlPWNvZGVfZm9yX2lkX3Rv a2VuLAo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB5b3UgZ2V0IGEgY29k ZSBhbmQgZXhjaGFuZ2UgaXQgZm9yCj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIGFuIGlkX3Rva2VuIG9ubHksIHJhdGhlciB0aGFuIGFuCj4+Pj4+PiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIGFjY2Vzc190b2tlbiwgc28geW91J3JlIGNoYW5naW5nCj4+Pj4+ PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoZSBzZW1hbnRpY3Mgb2YgdGhlIFRv a2VuIEVuZHBvaW50Lgo+Pj4+Pj4KPj4+Pj4+Cj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIEknbSBub3Qgc2F5aW5nIGl0J3MgYSBiYWQgdGhpbmcsCj4+Pj4+PiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIGp1c3QgdGhhdCB5b3UgY2FuJ3QgcmVhbGx5IGNvbXBh cmUKPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbm9uZSBhbmQgaWRfdG9r ZW4gd2l0aAo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb2RlX2Zvcl9p ZF90b2tlbi4KPj4+Pj4+Cj4+Pj4+Pgo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBPbiBXZWQsIEp1bCAyMywgMjAxNCBhdCA2OjQ1IFBNLAo+Pj4+Pj4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBSaWNoZXIsIEp1c3RpbiBQLgo+Pj4+Pj4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICA8anJpY2hlckBtaXRyZS5vcmcKPj4+Pj4+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgPG1haWx0bzpqcmljaGVyQG1pdHJlLm9yZz4+IHdyb3RlOgo+ Pj4+Pj4KPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSXQncyBvbmx5ICJu b3QgdXNpbmcgdGhlIHRva2VuCj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IGVuZHBvaW50IiBiZWNhdXNlIHRoZSB0b2tlbgo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBlbmRwb2ludCBjb3B5LXBhc3RlZCBhbmQgcmVuYW1lZAo+Pj4+Pj4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB0aGUgYXV0aGVudGljYXRpb24gZW5kcG9pbnQuCj4+ Pj4+Pgo+Pj4+Pj4KPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIEp1 c3Rpbgo+Pj4+Pj4KPj4+Pj4+Cj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IE9uIEp1bCAyMywgMjAxNCwgYXQgOTozMCBBTSwKPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgVGhvbWFzIEJyb3llciA8dC5icm95ZXJAZ21haWwuY29tCj4+Pj4+PiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxtYWlsdG86dC5icm95ZXJAZ21haWwuY29tPj4g d3JvdGU6Cj4+Pj4+Pgo+Pj4+Pj4KPj4+Pj4+Cj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIEV4Y2VwdCB0aGF0IHRoZXNlIGFyZSBhYm91dCBub3QKPj4+Pj4+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgdXNpbmcgdGhlIFRva2VuIEVuZHBvaW50IGF0IGFsbCwK Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgd2hlcmVhcyB0aGUgY3VycmVu dCBwcm9wb3NhbCBpcwo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhYm91 dCB0aGUgVG9rZW4gRW5kcG9pbnQgbm90Cj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHJldHVybmluZyBhbiBhY2Nlc3NfdG9rZW4gZmllbGQgaW4KPj4+Pj4+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgdGhlIEpTT04uCj4+Pj4+Pgo+Pj4+Pj4KPj4+Pj4+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgT24gV2VkLCBKdWwgMjMsIDIwMTQgYXQgNDoy NiBQTSwKPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTWlrZSBKb25lcwo+ Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8TWljaGFlbC5Kb25lc0BtaWNy b3NvZnQuY29tCj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxtYWlsdG86 TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4KPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgd3JvdGU6Cj4+Pj4+Pgo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBUaGUgcmVzcG9uc2VfdHlwZSAibm9uZSIgaXMKPj4+Pj4+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgYWxyZWFkeSB1c2VkIGluIHByYWN0aWNlLCB3aGljaAo+Pj4+Pj4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICByZXR1cm5zIG5vIGFjY2VzcyB0b2tlbi4g IEl0IHdhcwo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhY2NlcHRlZCBi eSB0aGUgZGVzaWduYXRlZCBleHBlcnRzCj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIGFuZCByZWdpc3RlcmVkIGluIHRoZSBJQU5BIE9BdXRoCj4+Pj4+PiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIEF1dGhvcml6YXRpb24gRW5kcG9pbnQgUmVzcG9uc2UKPj4+ Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVHlwZXMgcmVnaXN0cnkgYXQKPj4+ Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaHR0cDovL3d3dy5pYW5hLm9yZy9h c3NpZ25tZW50cy9vYXV0aC1wYXJhbWV0ZXJzL29hdXRoLXBhcmFtZXRlcnMueG1sI2VuZHBvaW50 Cj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxodHRwOi8vd3d3LmlhbmEu b3JnL2Fzc2lnbm1lbnRzL29hdXRoLXBhcmFtZXRlcnMvb2F1dGgtcGFyYW1ldGVycy54bWwjZW5k cG9pbnQ+Lgo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBUaGUgcmVnaXN0 ZXJlZCAiaWRfdG9rZW4iIHJlc3BvbnNlCj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHR5cGUgYWxzbyByZXR1cm5zIG5vIGFjY2VzcyB0b2tlbi4KPj4+Pj4+Cj4+Pj4+Pgo+ Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTbyBJIHRoaW5rIHRoZSBxdWVz dGlvbiBvZiB3aGV0aGVyCj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJl c3BvbnNlIHR5cGVzIHRoYXQgcmVzdWx0IGluIG5vCj4+Pj4+PiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIGFjY2VzcyB0b2tlbiBiZWluZyByZXR1cm5lZCBhcmUKPj4+Pj4+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgYWNjZXB0YWJsZSB3aXRoaW4gT0F1dGggMi4wIGlz Cj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFscmVhZHkgc2V0dGxlZCwg YXMgYSBwcmFjdGljYWwKPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbWF0 dGVyLiAgTG90cyBvZiBPQXV0aAo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBpbXBsZW1lbnRhdGlvbnMgYXJlIGFscmVhZHkgdXNpbmcKPj4+Pj4+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgc3VjaCByZXNwb25zZSB0eXBlcy4KPj4+Pj4+Cj4+Pj4+Pgo+Pj4+ Pj4KPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQo+Pj4+Pj4K Pj4+Pj4+Cj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICpGcm9tOipPQXV0 aAo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbbWFpbHRvOm9hdXRoLWJv dW5jZXNAaWV0Zi5vcmcKPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPG1h aWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPl0KPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgKk9uIEJlaGFsZiBPZiAqUGhpbCBIdW50Cj4+Pj4+PiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICpTZW50OiogV2VkbmVzZGF5LCBKdWx5IDIzLCAyMDE0Cj4+Pj4+ PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDc6MDkgQU0KPj4+Pj4+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgKlRvOiogTmF0IFNha2ltdXJhCj4+Pj4+PiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICpDYzoqIDxvYXV0aEBpZXRmLm9yZwo+Pj4+Pj4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4KPj4+ Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKlN1YmplY3Q6KiBSZTogW09BVVRI LVdHXSBOZXcKPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVmVyc2lvbiBO b3RpZmljYXRpb24gZm9yCj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGRy YWZ0LWh1bnQtb2F1dGgtdjItdXNlci1hNGMtMDUudHh0Cj4+Pj4+Pgo+Pj4+Pj4KPj4+Pj4+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgWWVzLiBUaGlzIGlzIHdoeSBpdCBoYXMgdG8g YmUKPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZGlzY3Vzc2VkIGluIHRo ZSBJRVRGLgo+Pj4+Pj4KPj4+Pj4+Cj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIFBoaWwKPj4+Pj4+Cj4+Pj4+Pgo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBAaW5kZXBlbmRlbnRpZAo+Pj4+Pj4KPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgd3d3LmluZGVwZW5kZW50aWQuY29tCj4+Pj4+PiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIDxodHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29tLz4KPj4+Pj4+Cj4+Pj4+ PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHBoaWwuaHVudEBvcmFjbGUuY29tCj4+ Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxtYWlsdG86cGhpbC5odW50QG9y YWNsZS5jb20+Cj4+Pj4+Pgo+Pj4+Pj4KPj4+Pj4+Cj4+Pj4+Pgo+Pj4+Pj4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBPbiBKdWwgMjMsIDIwMTQsIGF0IDk6NDMgQU0sIE5hdAo+Pj4+ Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTYWtpbXVyYSA8c2FraW11cmFAZ21h aWwuY29tCj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxtYWlsdG86c2Fr aW11cmFAZ21haWwuY29tPj4gd3JvdGU6Cj4+Pj4+Pgo+Pj4+Pj4KPj4+Pj4+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgUmVhZGluZyBiYWNrIHRoZSBSRkM2NzQ5LCBJIGFtIG5vdAo+ Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdXJlIGlmIHRoZXJlIGlzIGEg Z29vZCB3YXkgb2YKPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3VwcHJl c3NpbmcgYWNjZXNzIHRva2VuIGZyb20gdGhlCj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHJlc3BvbnNlIGFuZCBzdGlsbCBiZSBPQXV0aC4gSXQKPj4+Pj4+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgd2lsbCBicmVhayB3aG9sZSBidW5jaCBvZiBpbXBsaWNp dAo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkZWZpbml0aW9ucyBsaWtl Ogo+Pj4+Pj4KPj4+Pj4+Cj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGF1 dGhvcml6YXRpb24gc2VydmVyCj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFRoZSBzZXJ2ZXIgaXNzdWluZyBhY2Nlc3MKPj4+Pj4+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgdG9rZW5zIHRvIHRoZSBjbGllbnQgYWZ0ZXIKPj4+Pj4+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgc3VjY2Vzc2Z1bGx5Cj4+Pj4+PiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIGF1dGhlbnRpY2F0aW5nIHRoZSByZXNvdXJjZQo+Pj4+ Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBvd25lciBhbmQgb2J0YWluaW5nIGF1 dGhvcml6YXRpb24uCj4+Pj4+Pgo+Pj4+Pj4KPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgQWZ0ZXIgYWxsLCBPQXV0aCBpcyBhbGwgYWJvdXQKPj4+Pj4+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgaXNzdWluZyBhY2Nlc3MgdG9rZW5zLgo+Pj4+Pj4KPj4+Pj4+ Cj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFsc28sIEkgdGFrZSBiYWNr IG15IHN0YXRlbWVudCBvbgo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0 aGUgZ3JhbnQgdHlwZSBpbiBteSBwcmV2aW91cyBtYWlsLgo+Pj4+Pj4KPj4+Pj4+Cj4+Pj4+PiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRoZSBkZWZpbml0aW9uIG9mIGdyYW50IGFu ZAo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBncmFudF90eXBlIGFyZSBy ZXNwZWN0aXZlbHk6Cj4+Pj4+Pgo+Pj4+Pj4KPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgZ3JhbnQKPj4+Pj4+Cj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBjcmVkZW50aWFsIHJlcHJlc2VudGluZyB0aGUKPj4+Pj4+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgcmVzb3VyY2Ugb3duZXIncyBhdXRob3JpemF0aW9uCj4+Pj4+Pgo+ Pj4+Pj4KPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZ3JhbnRfdHlwZQo+ Pj4+Pj4KPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChzdHJpbmcg cmVwcmVzZW50aW5nIHRoZSkgdHlwZQo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBvZiBncmFudCBzZW50IHRvIHRoZSB0b2tlbgo+Pj4+Pj4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBlbmRwb2ludCB0byBvYnRhaW4gdGhlIGFjY2VzcyB0b2tlbgo+Pj4+Pj4K Pj4+Pj4+Cj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRodXMsIHRoZSBn cmFudCBzZW50IHRvIHRoZSB0b2tlbgo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBlbmRwb2ludCBpbiB0aGlzIGNhc2UgaXMgc3RpbGwKPj4+Pj4+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgJ2NvZGUnLgo+Pj4+Pj4KPj4+Pj4+Cj4+Pj4+PiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFJlc3BvbnNlIHR5cGUgb24gdGhlIG90aGVyIGhhbmQgaXMK Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbm90IHNvIHdlbGwgZGVmaW5l ZCBpbiBSRkM2NzQ5LAo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBidXQg aXQgc2VlbXMgaXQgaXMgcmVwcmVzZW50aW5nCj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHdoYXQgaXMgdG8gYmUgcmV0dXJuZWQgZnJvbSB0aGUKPj4+Pj4+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgYXV0aG9yaXphdGlvbiBlbmRwb2ludC4gVG8gZXhwcmVz cwo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB3aGF0IGlzIHRvIGJlIHJl dHVybmVkIGZyb20gdG9rZW4KPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ZW5kcG9pbnQsIHBlcmhhcHMgZGVmaW5pbmcgYSBuZXcKPj4+Pj4+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgcGFyYW1ldGVyIHRvIHRoZSB0b2tlbiBlbmRwb2ludCwKPj4+Pj4+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgd2hpY2ggaXMgYSBwYXJhbGxlbCB0byB0aGUK Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcmVzcG9uc2VfdHlwZSB0byB0 aGUgQXV0aG9yaXphdGlvbgo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBF bmRwb2ludCBzZWVtcyB0byBiZSBhIG1vcmUKPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgc3ltbWV0cmljIHdheSwgdGhvdWdoIEkgYW0gbm90Cj4+Pj4+PiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHN1cmUgYXQgYWxsIGlmIHRoYXQgaXMgZ29pbmcgdG8gYmUK Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgT0F1dGggYW55IG1vcmUuIE9u ZSBzdHJhdy1tYW4gaXMKPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdG8g ZGVmaW5lIGEgbmV3IHBhcmFtZXRlciBjYWxsZWQKPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgcmVzcG9uc2VfdHlwZSB0byB0aGUgdG9rZW4KPj4+Pj4+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgZW5kcG9pbnQgc3VjaCBhczoKPj4+Pj4+Cj4+Pj4+Pgo+Pj4+ Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICByZXNwb25zZV90eXBlCj4+Pj4+Pgo+ Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgT1BUSU9OQUwuIEEgc3Ry aW5nCj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJlcHJlc2VudGluZyB3 aGF0IGlzIHRvIGJlCj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJldHVy bmVkIGZyb20gdGhlIHRva2VuIGVuZHBvaW50Lgo+Pj4+Pj4KPj4+Pj4+Cj4+Pj4+PiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFRoZW4gZGVmaW5lIHRoZSBiZWhhdmlvciBvZiB0aGUK Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZW5kcG9pbnQgYWNjb3JkaW5n IHRvIHRoZSB2YWx1ZXMKPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYXMg dGhlIHBhcmFsbGVsIHRvIHRoZQo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBtdWx0aS1yZXNwb25zZSB0eXBlIHNwZWMuCj4+Pj4+Pgo+Pj4+Pj4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBodHRwOi8vb3BlbmlkLm5ldC9zcGVjcy9vYXV0aC12Mi1tdWx0aXBs ZS1yZXNwb25zZS10eXBlcy0xXzAuaHRtbAo+Pj4+Pj4KPj4+Pj4+Cj4+Pj4+PiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIE5hdAo+Pj4+Pj4KPj4+Pj4+Cj4+Pj4+Pgo+Pj4+Pj4KPj4+ Pj4+Cj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDIwMTQtMDctMjMgNzoy MSBHTVQtMDQ6MDAgUGhpbAo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBI dW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbQo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICA8bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj46Cj4+Pj4+Pgo+Pj4+Pj4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBUaGUgZHJhZnQgaXMgdmVyeSBjbGVhci4KPj4+ Pj4+Cj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFBoaWwKPj4+Pj4+Cj4+ Pj4+Pgo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBPbiBKdWwgMjMsIDIw MTQsIGF0IDA6NDYsIE5hdAo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBT YWtpbXVyYSA8c2FraW11cmFAZ21haWwuY29tCj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDxtYWlsdG86c2FraW11cmFAZ21haWwuY29tPj4gd3JvdGU6Cj4+Pj4+Pgo+Pj4+ Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVGhlIG5ldyBncmFudCB0eXBl IHRoYXQgSSB3YXMKPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRh bGtpbmcgYWJvdXQgd2FzCj4+Pj4+Pgo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgImF1dGhvcml6YXRpb25fY29kZV9idXRfZG9fbm90X3JldHVybl9hY2Nlc3Nfbm9y X3JlZnJlc2hfdG9rZW4iLAo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgc28gdG8gc3BlYWsuCj4+Pj4+Pgo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgSXQgZG9lcyBub3QgcmV0dXJuIGFueXRoaW5nCj4+Pj4+PiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBwZXIgc2UsIGJ1dCBhbiBleHRlbnNpb24gY2FuCj4+Pj4+ PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkZWZpbmUgc29tZXRoaW5nIG9u IHRvcCBvZiBpdC4KPj4+Pj4+Cj4+Pj4+Pgo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgVGhlbiwgT0lEQyBjYW4gZGVmaW5lIGEKPj4+Pj4+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIGJpbmRpbmcgdG8gaXQgc28gdGhhdCB0aGUKPj4+Pj4+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGJpbmRpbmcgb25seSByZXR1cm5zIElE IFRva2VuLgo+Pj4+Pj4KPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IFRoaXMgYmluZGluZyB3b3JrIHNob3VsZCBiZQo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgZG9uZSBpbiBPSURGLiBTaG91bGQgdGhlcmUgYmUKPj4+Pj4+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN1Y2ggYSBncmFudCB0eXBlLAo+Pj4+Pj4K Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGl0IHdpbGwgYmUgYW4g ZXh0cmVtZWx5IHNob3J0Cj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBzcGVjLgo+Pj4+Pj4KPj4+Pj4+Cj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBBdCB0aGUgc2FtZSB0aW1lLCBpZiBhbnkgb3RoZXIKPj4+Pj4+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHNwZWNpZmljYXRpb24gd2FudGVkIHRvIGRlZmluZQo+ Pj4+Pj4KPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG90aGVyIHR5 cGUgb2YgdG9rZW5zIGFuZCBoYXZlCj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBpdCByZXR1cm5lZCBmcm9tIHRoZSB0b2tlbgo+Pj4+Pj4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgZW5kcG9pbnQsCj4+Pj4+Pgo+Pj4+Pj4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgaXQgY2FuIGFsc28gdXNlIHRoaXMgZ3JhbnQgdHlwZS4K Pj4+Pj4+Cj4+Pj4+Pgo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg SWYgd2hhdCB5b3Ugd2FudCBpcyB0byBkZWZpbmUKPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIGEgbmV3IGdyYW50IHR5cGUgdGhhdCByZXR1cm5zCj4+Pj4+PiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJRCBUb2tlbiBvbmx5LAo+Pj4+Pj4KPj4+ Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoZW4sIEkgYW0gd2l0aCBK dXN0aW4uIFNpbmNlCj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAi b3RoZXIgcmVzcG9uc2UgdGhhbiBJRCBUb2tlbiIKPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIGlzIG9ubHkKPj4+Pj4+Cj4+Pj4+PiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB0aGVvcmV0aWNhbCwgdGhpcyBpcyBhIG1vcmUKPj4+Pj4+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHBsYXVzaWJsZSB3YXkgZm9yd2FyZCwgSSBz dXBwb3NlLgo+Pj4+Pj4KPj4+Pj4+Cj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBOYXQKPj4+Pj4+Cj4+Pj4+Pgo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgMjAxNC0wNy0yMiAxNDozMCBHTVQtMDQ6MDAKPj4+Pj4+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdQo+ Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPG1haWx0bzpqcmljaGVy QG1pdC5lZHU+PjoKPj4+Pj4+Cj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBTbyB0aGUgZHJhZnQgd291bGQgbGl0ZXJhbGx5Cj4+Pj4+PiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB0dXJuIGludG86Cj4+Pj4+Pgo+Pj4+Pj4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIlRoZSBhNGMgcmVzcG9uc2UgdHlwZSBhbmQKPj4+Pj4+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGdyYW50IHR5cGUgcmV0dXJuIGFu IGlkX3Rva2VuCj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBmcm9t IHRoZSB0b2tlbiBlbmRwb2ludCB3aXRoCj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBubyBhY2Nlc3MgdG9rZW4uIEFsbAo+Pj4+Pj4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgcGFyYW1ldGVycyBhbmQgdmFsdWVzIGFyZQo+Pj4+Pj4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZGVmaW5lZCBpbiBPSURDLiIKPj4+Pj4+Cj4+ Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTZWVtcyBsaWtlIHRoZSBw ZXJmZWN0IG1pbmkKPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGV4 dGVuc2lvbiBkcmFmdCBmb3IgT0lERiB0byBkby4KPj4+Pj4+Cj4+Pj4+PiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAtLUp1c3Rpbgo+Pj4+Pj4KPj4+Pj4+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIC9zZW50IGZyb20gbXkgcGhvbmUvCj4+Pj4+Pgo+Pj4+ Pj4KPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE9uIEp1bCAyMiwg MjAxNCAxMDoyOSBBTSwgTmF0Cj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBTYWtpbXVyYSA8c2FraW11cmFAZ21haWwuY29tCj4+Pj4+PiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICA8bWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbT4+Cj4+Pj4+PiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB3cm90ZToKPj4+Pj4+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgID4KPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgID4gV2hhdCBhYm91dCBqdXN0IGRlZmluaW5nIGEKPj4+Pj4+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG5ldyBncmFudCB0eXBlIGluIHRoaXMgV0c/ Cj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA+Cj4+Pj4+PiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA+Cj4+Pj4+PiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICA+IDIwMTQtMDctMjIgMTI6NTYgR01ULTA0OjAwCj4+Pj4+PiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBQaGlsIEh1bnQKPj4+Pj4+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxwaGlsLmh1bnRAb3JhY2xlLmNvbQo+Pj4+ Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPG1haWx0bzpwaGlsLmh1bnRA b3JhY2xlLmNvbT4+Ogo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Pj4KPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgID4+IFRoYXQgd291 bGQgYmUgbmljZS4gSG93ZXZlcgo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgb2lkYyBzdGlsbCBuZWVkcyB0aGUgbmV3IGdyYW50Cj4+Pj4+PiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB0eXBlIGluIG9yZGVyIHRvIGltcGxlbWVudCB0aGUKPj4+ Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNhbWUgZmxvdy4KPj4+Pj4+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgID4+Cj4+Pj4+PiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA+PiBQaGlsCj4+Pj4+PiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICA+Pgo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgPj4gT24gSnVsIDIyLCAyMDE0LCBhdCAxMTozNSwKPj4+Pj4+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIE5hdCBTYWtpbXVyYQo+Pj4+Pj4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgPHNha2ltdXJhQGdtYWlsLmNvbQo+Pj4+Pj4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPG1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20+ Pgo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgd3JvdGU6Cj4+Pj4+ PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA+Pgo+Pj4+Pj4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgPj4+ICsxIHRvIEp1c3Rpbi4KPj4+Pj4+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgID4+Pgo+Pj4+Pj4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgPj4+Cj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICA+Pj4gMjAxNC0wNy0yMiA5OjU0IEdNVC0wNDowMAo+Pj4+Pj4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgUmljaGVyLCBKdXN0aW4gUC4KPj4+Pj4+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxqcmljaGVyQG1pdHJlLm9yZwo+Pj4+Pj4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPG1haWx0bzpqcmljaGVyQG1pdHJl Lm9yZz4+Ogo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPj4+Pgo+ Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPj4+PiBFcnJvcnMgbGlr ZSB0aGVzZSBtYWtlIGl0Cj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBjbGVhciB0byBtZSB0aGF0IGl0IHdvdWxkIG1ha2UKPj4+Pj4+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIG11Y2ggbW9yZSBzZW5zZSB0byBkZXZlbG9wCj4+Pj4+PiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGlzIGRvY3VtZW50IGluIHRoZSBPcGVu SUQKPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZvdW5kYXRpb24u IEl0IHNob3VsZCBiZQo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg c29tZXRoaW5nIHRoYXQgZGlyZWN0bHkKPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHJlZmVyZW5jZXMgT3BlbklEIENvbm5lY3QgQ29yZQo+Pj4+Pj4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgZm9yIGFsbCBvZiB0aGVzZSB0ZXJtcyBpbnN0ZWFk Cj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBvZiByZWRlZmluaW5n IHRoZW0uIEl0J3MgZG9pbmcKPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIGF1dGhlbnRpY2F0aW9uLCB3aGljaCBpcwo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgZnVuZGFtZW50YWxseSB3aGF0IE9wZW5JRAo+Pj4+Pj4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgQ29ubmVjdCBkb2VzIG9uIHRvcCBvZiBPQXV0aCwK Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFuZCBJIGRvbid0IHNl ZSBhIGdvb2QKPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFyZ3Vt ZW50IGZvciBkb2luZyB0aGlzIHdvcmsKPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGluIHRoaXMgd29ya2luZyBncm91cC4KPj4+Pj4+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgID4+Pj4KPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgID4+Pj4gIC0tIEp1c3Rpbgo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgPj4+Pgo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgPj4+PiBPbiBKdWwgMjIsIDIwMTQsIGF0IDQ6MzAKPj4+Pj4+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIEFNLCBUaG9tYXMgQnJveWVyCj4+Pj4+PiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA8dC5icm95ZXJAZ21haWwuY29tCj4+Pj4+PiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8bWFpbHRvOnQuYnJveWVyQGdtYWlsLmNvbT4+ Cj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB3cm90ZToKPj4+Pj4+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgID4+Pj4KPj4+Pj4+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgID4+Pj4+Cj4+Pj4+PiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICA+Pj4+Pgo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgPj4+Pj4KPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgID4+Pj4+IE9uIE1vbiwgSnVsIDIxLCAyMDE0IGF0Cj4+Pj4+PiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAxMTo1MiBQTSwgTWlrZSBKb25lcwo+Pj4+Pj4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbQo+ Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPG1haWx0bzpNaWNoYWVs LkpvbmVzQG1pY3Jvc29mdC5jb20+Pgo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgd3JvdGU6Cj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICA+Pj4+Pj4KPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgID4+Pj4+ PiBUaGFua3MgZm9yIHlvdXIgcmV2aWV3LAo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgVGhvbWFzLiAgVGhlICJwcm9tcHQ9Y29uc2VudCIKPj4+Pj4+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGRlZmluaXRpb24gYmVpbmcgbWlzc2luZyBpcyBh bgo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZWRpdG9yaWFsIGVy cm9yLiAgSXQgc2hvdWxkIGJlOgo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgPj4+Pj4+Cj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA+ Pj4+Pj4KPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgID4+Pj4+Pgo+ Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPj4+Pj4+IGNvbnNlbnQK Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgID4+Pj4+Pgo+Pj4+Pj4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPj4+Pj4+IFRoZSBBdXRob3JpemF0 aW9uCj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTZXJ2ZXIgU0hP VUxEIHByb21wdCB0aGUKPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IEVuZC1Vc2VyIGZvciBjb25zZW50IGJlZm9yZQo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgcmV0dXJuaW5nIGluZm9ybWF0aW9uIHRvIHRoZQo+Pj4+Pj4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQ2xpZW50LiBJZiBpdCBjYW5ub3Qgb2J0YWlu Cj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zZW50LCBpdCBN VVNUIHJldHVybiBhbgo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ZXJyb3IsIHR5cGljYWxseSBjb25zZW50X3JlcXVpcmVkLgo+Pj4+Pj4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgPj4+Pj4+Cj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICA+Pj4+Pj4KPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgID4+Pj4+Pgo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Pj4+Pj4+IEknbGwgcGxhbiB0byBhZGQgaXQgaW4KPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHRoZSBuZXh0IGRyYWZ0Lgo+Pj4+Pj4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgPj4+Pj4KPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgID4+Pj4+Cj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICA+Pj4+PiBJdCBsb29rcyBsaWtlIHRoZQo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgY29uc2VudF9yZXF1aXJlZCBlcnJvciBuZWVkcwo+Pj4+Pj4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgdG8gYmUgZGVmaW5lZCB0b28sIGFuZCB5b3UKPj4+ Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1pZ2h0IGhhdmUgZm9yZ290 dGVuIHRvIGFsc28KPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGlt cG9ydAo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYWNjb3VudF9z ZWxlY3Rpb25fcmVxdWlyZWQKPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIGZyb20gT3BlbklEIENvbm5lY3QuCj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICA+Pj4+Pgo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgPj4+Pj4+Cj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA+Pj4+ Pj4KPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgID4+Pj4+Pgo+Pj4+ Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPj4+Pj4+IEkgYWdyZWUgdGhh dCB0aGVyZSdzIG5vCj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBk aWZmZXJlbmNlIGJldHdlZW4gYSByZXNwb25zZQo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgd2l0aCBtdWx0aXBsZSAiYW1yIiB2YWx1ZXMKPj4+Pj4+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoYXQgaW5jbHVkZXMgIm1mYSIgYW5kIG9uZQo+ Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhhdCBkb2Vzbid0LiAg VW5sZXNzIGEgY2xlYXIKPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHVzZSBjYXNlIGZvciB3aHkgIm1mYSIgaXMKPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIG5lZWRlZCBjYW4gYmUgaWRlbnRpZmllZCwgd2UKPj4+Pj4+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNhbiBkZWxldGUgaXQgaW4gdGhlIG5leHQgZHJh ZnQuCj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA+Pj4+Pgo+Pj4+ Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPj4+Pj4KPj4+Pj4+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgID4+Pj4+IFRoYW5rcy4KPj4+Pj4+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgID4+Pj4+Cj4+Pj4+PiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA+Pj4+PiBIb3cgYWJvdXQgInB3ZCIgdGhlbj8gSQo+Pj4+ Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZnVsbHkgdW5kZXJzdGFuZCB0 aGF0IEkgc2hvdWxkCj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBy ZXR1cm4gInB3ZCIgaWYgdGhlIHVzZXIKPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGF1dGhlbnRpY2F0ZWQgdXNpbmcgYQo+Pj4+Pj4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgcGFzc3dvcmQsIGJ1dCB3aGF0ICJ0aGUKPj4+Pj4+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNlcnZpY2UgaWYgYSBjbGllbnQgc2VjcmV0IGlz Cj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1c2VkIiBtZWFucyBp biB0aGUgZGVmaW5pdGlvbgo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgZm9yIHRoZSAicHdkIiB2YWx1ZT8KPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgID4+Pj4+Cj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICA+Pj4+PiAoTm90YTogSSBrbm93IHlvdSdyZSBhdAo+Pj4+Pj4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgSUVURi05MCwgSSdtIHJlYWR5IHRvIHdhaXQKPj4+Pj4+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICd0aWwgeW91IGNvbWUgYmFjayA7LSkgKQo+ Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPj4+Pj4KPj4+Pj4+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgID4+Pj4+IC0tCj4+Pj4+PiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA+Pj4+PiBUaG9tYXMgQnJveWVyCj4+Pj4+PiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA+Pj4+PiAvdMmULm1hLmLKgXdhLmpl Lwo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGh0dHA6Ly94bi0t bm5hLm1hLnhuLS1id2EteHhiLmplLz4KPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgID4+Pj4+Cj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+Pj4+Pj4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPj4+Pj4gT0F1dGggbWFpbGluZyBs aXN0Cj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA+Pj4+PiBPQXV0 aEBpZXRmLm9yZwo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPG1h aWx0bzpPQXV0aEBpZXRmLm9yZz4KPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgID4+Pj4+Cj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoCj4+Pj4+PiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA+Pj4+Cj4+Pj4+PiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICA+Pj4+Cj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICA+Pj4+Cj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICA+Pj4+Cj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+Pj4+Pj4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgPj4+PiBPQXV0aCBtYWlsaW5nIGxpc3QKPj4+Pj4+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgID4+Pj4gT0F1dGhAaWV0Zi5vcmcK Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxtYWlsdG86T0F1dGhA aWV0Zi5vcmc+Cj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA+Pj4+ Cj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoCj4+Pj4+PiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICA+Pj4+Cj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICA+Pj4KPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgID4+ Pgo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPj4+Cj4+Pj4+PiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA+Pj4gLS0KPj4+Pj4+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgID4+PiBOYXQgU2FraW11cmEgKD1uYXQpCj4+Pj4+ PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA+Pj4gQ2hhaXJtYW4sIE9wZW5J RCBGb3VuZGF0aW9uCj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA+ Pj4gaHR0cDovL25hdC5zYWtpbXVyYS5vcmcvCj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICA+Pj4gQF9uYXRfZW4KPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgID4+Pgo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgPj4+Cj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+Pj4+Pj4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgPj4+IE9BdXRoIG1haWxpbmcgbGlzdAo+Pj4+Pj4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPj4+IE9BdXRoQGlldGYub3JnCj4+ Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8bWFpbHRvOk9BdXRoQGll dGYub3JnPgo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPj4+Cj4+ Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoCj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICA+Cj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICA+Cj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA+Cj4+Pj4+PiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA+Cj4+Pj4+PiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA+IC0tCj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICA+IE5hdCBTYWtpbXVyYSAoPW5hdCkKPj4+Pj4+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgID4gQ2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uCj4+Pj4+ PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA+IGh0dHA6Ly9uYXQuc2FraW11 cmEub3JnLwo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPiBAX25h dF9lbgo+Pj4+Pj4KPj4+Pj4+Cj4+Pj4+Pgo+Pj4+Pj4KPj4+Pj4+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIC0tCj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBOYXQgU2FraW11cmEgKD1uYXQpCj4+Pj4+Pgo+Pj4+Pj4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgQ2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uCj4+Pj4+PiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBodHRwOi8vbmF0LnNha2ltdXJhLm9y Zy8KPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEBfbmF0X2VuCj4+ Pj4+Pgo+Pj4+Pj4KPj4+Pj4+Cj4+Pj4+Pgo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAtLQo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBOYXQgU2Fr aW11cmEgKD1uYXQpCj4+Pj4+Pgo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBDaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb24KPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgaHR0cDovL25hdC5zYWtpbXVyYS5vcmcvCj4+Pj4+PiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIEBfbmF0X2VuCj4+Pj4+Pgo+Pj4+Pj4KPj4+Pj4+Cj4+Pj4+PiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIE9BdXRoIG1haWxpbmcgbGlzdAo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBPQXV0aEBpZXRmLm9yZyA8bWFpbHRvOk9BdXRoQGlldGYub3JnPgo+Pj4+Pj4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL29hdXRoCj4+Pj4+Pgo+Pj4+Pj4KPj4+Pj4+Cj4+Pj4+Pgo+Pj4+Pj4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAtLQo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBUaG9tYXMgQnJveWVyCj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIC90yZQubWEuYsqBd2EuamUvCj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDxodHRwOi8veG4tLW5uYS5tYS54bi0tYndhLXh4Yi5qZS8+Cj4+Pj4+Pgo+Pj4+Pj4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXwo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBPQXV0aCBtYWlsaW5nIGxpc3QKPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgT0F1dGhAaWV0Zi5vcmcgPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4KPj4+Pj4+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9vYXV0aAo+Pj4+Pj4KPj4+Pj4+Cj4+Pj4+Pgo+Pj4+Pj4KPj4+Pj4+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgLS0KPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgVGhvbWFzIEJyb3llcgo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAvdMmULm1hLmLKgXdhLmplLwo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICA8aHR0cDovL3huLS1ubmEubWEueG4tLWJ3YS14eGIuamUvPgo+Pj4+Pj4KPj4+Pj4+Cj4+Pj4+ PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fCj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIE9BdXRoIG1haWxpbmcgbGlzdAo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBPQXV0aEBpZXRmLm9yZyA8bWFpbHRvOk9BdXRoQGlldGYub3JnPgo+Pj4+Pj4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL29hdXRoCj4+Pj4+Pgo+Pj4+Pj4KPj4+Pj4+Cj4+Pj4+Pgo+Pj4+Pj4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAtLQo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBOYXQgU2FraW11cmEgKD1uYXQpCj4+Pj4+Pgo+Pj4+Pj4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBDaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb24KPj4+Pj4+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaHR0cDovL25hdC5zYWtpbXVyYS5vcmcvCj4+ Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEBfbmF0X2VuCj4+Pj4+Pgo+Pj4+ Pj4KPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPj4+Pj4+Cj4+Pj4+PiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIE9BdXRoIG1haWxpbmcgbGlzdAo+Pj4+Pj4KPj4+Pj4+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgT0F1dGhAaWV0Zi5vcmcgIDxtYWlsdG86T0F1 dGhAaWV0Zi5vcmc+Cj4+Pj4+Pgo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoCj4+Pj4+Pgo+Pj4+ Pj4KPj4+Pj4+Cj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPj4+Pj4+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBPQXV0aCBtYWlsaW5nIGxpc3QKPj4+Pj4+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBPQXV0aEBpZXRmLm9yZyA8bWFpbHRvOk9BdXRoQGlldGYub3JnPgo+Pj4+Pj4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vb2F1dGgKPj4+Pj4+Cj4+Pj4+Pgo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAg ICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPj4+Pj4+ ICAgICAgICAgICAgICAgICAgICAgICAgIE9BdXRoIG1haWxpbmcgbGlzdAo+Pj4+Pj4gICAgICAg ICAgICAgICAgICAgICAgICAgT0F1dGhAaWV0Zi5vcmcgPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4K Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vb2F1dGgKPj4+Pj4+Cj4+Pj4+Pgo+Pj4+Pj4KPj4+Pj4+ICAgICAgICAgICAg ICAgICAgICAgLS0KPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgTmF0IFNha2ltdXJhICg9bmF0 KQo+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICBDaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb24K Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgaHR0cDovL25hdC5zYWtpbXVyYS5vcmcvCj4+Pj4+ PiAgICAgICAgICAgICAgICAgICAgIEBfbmF0X2VuCj4+Pj4+Pgo+Pj4+Pj4gICAgICAgICAgICAg ICAgICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+ Pj4+Pj4gICAgICAgICAgICAgICAgICAgICBPQXV0aCBtYWlsaW5nIGxpc3QKPj4+Pj4+ICAgICAg ICAgICAgICAgICAgICAgT0F1dGhAaWV0Zi5vcmcgPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4KPj4+ Pj4+ICAgICAgICAgICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9vYXV0aAo+Pj4+Pj4KPj4+Pj4+Cj4+Pj4+Pgo+Pj4+Pj4gICAgICAgICAgICAgLS0KPj4+ Pj4+ICAgICAgICAgICAgIE5hdCBTYWtpbXVyYSAoPW5hdCkKPj4+Pj4+ICAgICAgICAgICAgIENo YWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbgo+Pj4+Pj4gICAgICAgICAgICAgaHR0cDovL25hdC5z YWtpbXVyYS5vcmcvCj4+Pj4+PiAgICAgICAgICAgICBAX25hdF9lbgo+Pj4+Pj4KPj4+Pj4+ICAg ICAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPj4+ Pj4+ICAgICAgICAgT0F1dGggbWFpbGluZyBsaXN0Cj4+Pj4+PiAgICAgICAgIE9BdXRoQGlldGYu b3JnIDxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+Cj4+Pj4+PiAgICAgICAgIGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgKPj4+Pj4gICAgICAgICBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+Pj4+PiAgICAgICAgIE9BdXRoIG1h aWxpbmcgbGlzdAo+Pj4+PiAgICAgICAgIE9BdXRoQGlldGYub3JnIDxtYWlsdG86T0F1dGhAaWV0 Zi5vcmc+Cj4+Pj4+ICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vYXV0aAo+Pj4KPj4KPj4gICAgICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXwo+PiAgICAgICAgIE9BdXRoIG1haWxpbmcgbGlzdAo+PiAgICAgICAg IE9BdXRoQGlldGYub3JnIDxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+Cj4+ICAgICAgICAgaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aAo+Pgo+Pgo+Pgo+Pgo+PiAgICAg LS0KPj4gICAgIE5hdCBTYWtpbXVyYSAoPW5hdCkKPj4gICAgIENoYWlybWFuLCBPcGVuSUQgRm91 bmRhdGlvbgo+PiAgICAgaHR0cDovL25hdC5zYWtpbXVyYS5vcmcvCj4+ICAgICBAX25hdF9lbgo+ Pgo+PiAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K Pj4gICAgIE9BdXRoIG1haWxpbmcgbGlzdAo+PiAgICAgT0F1dGhAaWV0Zi5vcmcgPG1haWx0bzpP QXV0aEBpZXRmLm9yZz4KPj4gICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vb2F1dGgKPj4KPj4KPgo+Cj4KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXwo+IE9BdXRoIG1haWxpbmcgbGlzdAo+IE9BdXRoQGlldGYub3JnCj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aAo+CgoKX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KT0F1dGggbWFpbGluZyBsaXN0Ck9B dXRoQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgK ----_com.android.email_447835122614160 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+PGRpdj5Zb3UgYXJlIGNvcnJlY3Qg aW4gdGhhdCBPQXV0aCAyIGFuZCBPcGVuSUQgQ29ubmVjdCBhcmUgbm90IHRoZSBzYW1lIHRoaW5n LCBidXQgeW91ciB1c2VyIGlzIGNvcnJlY3QgdGhhdCBPSURDIGFkZHMgYSBmZXcgcGllY2VzIG9u IHRvcCBvZiBPQXV0aCB0byBhZGQgYXV0aGVudGljYXRpb24gY2FwYWJpbGl0aWVzLiBPSURDIHdh cyBkZXNpZ25lZCB2ZXJ5IGV4cGxpY2l0bHkgdG8gYmUgY29tcGF0aWJsZSB3aXRoIHZhbmlsbGEg T0F1dGgsIHBhcnRpYWxseSBkbyB0aGF0IHBlb3BsZSB3b3VsZCBiZSBhYmxlIHRvIGRlcGxveSBp dCBvbiB0b3Agb2YgZXhpc3RpbmcgT0F1dGggaW5mcmFzdHJ1Y3R1cmUgYW5kIGNvZGUuIEJ1dCB0 aGUgdmVyeSBmYWN0IHRoYXQgT0lEQyBhZGRzIGEgZmV3IHRoaW5ncyBvbiB0b3Agb2YgT0F1dGgg dG8gZ2l2ZSBtb3JlIGZ1bmN0aW9uYWxpdHkgc2hvdWxkIGJlIHN1ZmZpY2llbnQgZXZpZGVuY2Ug dGhhdCB0aGV5J3JlIG5vdCBlcXVpdmFsZW50LiZuYnNwOzwvZGl2PjxkaXY+PGJyPjwvZGl2Pjxk aXY+SXQncyBtb3JlIHByb3BlciB0byBzYXkgdGhhdCBPcGVuSUQgQ29ubmVjdCBpcyBhbiBleHRl bnNpb24gYW5kIGFwcGxpY2F0aW9uIG9mIE9BdXRoLiBPbmUgdGhhdCBwcm92aWRlcyBhbiBhdXRo ZW50aWNhdGlvbiBhbmQgaWRlbnRpdHkgQVBJLiZuYnNwOzwvZGl2PjxkaXY+PGJyPjwvZGl2Pjxk aXY+VGhlIHdheSBJIGxpa2UgdG8gZXhwbGFpbiBpdCAod2hpY2ggSSBzdG9sZSBmcm9tIHNvbWVv bmUgZWxzZSkgaXMgdGhhdCBPQXV0aCBpcyBsaWtlIGNob2NvbGF0ZSBhbmQgYXV0aGVudGljYXRp b24gaXMgbGlrZSBmdWRnZS4gVGhleSBhcmUgbm90IHRoZSBzYW1lIHRoaW5nLiBZb3UgY2FuIG1h a2UgY2hvY29sYXRlIGludG8gZnVkZ2Ugb3V0IHlvdSBjYW4gbWFrZSBpdCBpbnRvIHNvbWV0aGlu ZyBlbHNlIG9yIHlvdSBjYW4ganVzdCBoYXZlIGl0IG9uIGl0cyBvd24uIFlvdSBjYW4gbWFrZSBm dWRnZSB3aXRoIGNob2NvbGF0ZSBvciB5b3UgY2FuIG1ha2UgaXQgd2l0aCBwZWFudXQgYnV0dGVy IG9yIHlvdSBjYW4gbWFrZSBpdCB3aXRoIHBvdGF0b2VzIGlmIHlvdSB3YW50IHRvLCBidXQgaXQg bmVlZHMgYSBjb3VwbGUgaW5ncmVkaWVudHMgYW5kIGEgdmVyeSBjb21tb24gb25lIGlzIGNob2Nv bGF0ZS4gT3BlbklEIENvbm5lY3QgaXMgYSByZWNpcGUgZm9yIGNob2NvbGF0ZSBmdWRnZSB0aGF0 IGEgbG90IG9mIHBlb3BsZSBsaWtlLiBBbmQgaXQgbWFrZXMgbXkgZnVkZ2UgY29tcGF0aWJsZSB3 aXRoIHlvdXIgZnVkZ2UsIHdoaWNoIGlzIHdoZXJlIHRoZSBtZXRhcGhvciBicmVha3MgZG93bi4g Oi0pPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1z aXplOjlweCI+PGRpdiBzdHlsZT0iZm9udC1zaXplOiA5cHg7ICI+LS0gSnVzdGluPC9kaXY+PGRp diBzdHlsZT0iZm9udC1zaXplOiA5cHg7ICI+PGJyPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtc2l6 ZTogOXB4OyAiPi8gU2VudCBmcm9tIG15IHBob25lIC88L2Rpdj48L2Rpdj48ZGl2PjwvZGl2Pjxk aXY+PC9kaXY+PGJyPjxicj4tLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tPGJyPkZy b206IFNlcmdleSBCZXJ5b3praW4gJmx0O3NiZXJ5b3praW5AZ21haWwuY29tJmd0OyA8YnI+RGF0 ZToxMC8xMy8yMDE0ICA2OjMzIEFNICAoR01ULTA1OjAwKSA8YnI+VG86IG9hdXRoQGlldGYub3Jn IDxicj5DYzogIDxicj5TdWJqZWN0OiBSZTogW09BVVRILVdHXSBOZXcgVmVyc2lvbiBOb3RpZmlj YXRpb24gZm9yDSAgZHJhZnQtaHVudC1vYXV0aC12Mi11c2VyLWE0Yy0wNS50eHQgPGJyPjxicj5I aTxicj48YnI+V2UndmUgaGFkIGEgdXNlciBhc3NlcnRpbmcgdGhhdCAiT0F1dGgyID09IE9wZW5p ZENvbm5lY3QiLCByZWZlcnJpbmcgdG8gPGJyPnRoZSBmYWN0IHRoYXQgdGhlICdvbmx5JyB0aGlu ZyBPSUMgYWRkcyBvbiB0b3Agb2YgdGhlIGF1dGhvcml6YXRpb24gY29kZSA8YnI+ZmxvdyBpcyB0 aGUgY2xpZW50IHNwZWNpZnlpbmcgZmV3IGV4dHJhIHNjb3BlcyBsaWtlICdvcGVuaWQnIGFuZCA8 YnI+J3Byb2ZpbGUnIGFuZCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2aWNlIHJldHVybmluZyBhbiBl eHRyYSBwcm9wZXJ0eSwgdGhlIDxicj5pZF90b2tlbiB3aGljaCBjYW4gYmUgc3VmZmljaWVudCBp biBvcmRlciB0byBnZXQgdGhlIGF1dGhlbnRpY2F0ZWQgPGJyPnVzZXIncyBpbmZvLjxicj48YnI+ TXkgdW5kZXJzdGFuZGluZyAiT0F1dGgyICE9IE9wZW5pZENvbm5lY3QiLCB0aGUgbGF0dGVyIHV0 aWxpemVzIHRoZSA8YnI+Zm9ybWVyIGFuZCBpcyBhbiBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc20g d2hpY2ggaXMgbm90IHdoYXQgT0F1dGgyIGlzIDxicj4obWF5IGJlIGV4Y2VwdCBmb3IgdGhlIGNs aWVudCBjcmVkZW50aWFscykuIEJ1dCBJIGRvbid0IGZlZWwgbGlrZSBpdCBpcyA8YnI+YSBjb252 aW5jaW5nIGVub3VnaCBhcmd1bWVudC48YnI+PGJyPkkgdGhvdWdodCB0aGlzIHRocmVhZCB3YXMg cmVsZXZhbnQsIHNvcnJ5IGlmIG5vdCwgd291bGQgaGF2ZSBubyBwcm9ibGVtcyA8YnI+c3RhcnRp bmcgYSBuZXcgb25lLjxicj48YnI+QmFzaWNhbGx5LCBJIHdvbmRlciB3aGF0IGlzIHRoZSBwcm9w ZXIgbGluZSBvZiBhcmd1bWVudCBmb3IgYSBwb3NpdGlvbiA8YnI+c3VjaCBhcyAiT0F1dGgyICE9 IE9wZW5pZENvbm5lY3QiIGFuZCBhbHNvIHdoYXQgd2FzIHRoZSBhY3Rpb24gdG8gdGhlIDxicj5s aXN0IG9mIG9wdGlvbnMgc3VnZ2VzdGVkIGJ5IEpvaG4gYmVsb3cuIElzIGhhdmluZyBhbiBPSUQg cHJvZmlsZSB3aGVyZSA8YnI+bm8gYWNjZXNzIHRva2VuIGlzIHJldHVybmVkIHdvdWxkIGJlIHRo ZSBjbGVhbmVzdCBhY3Rpb24gYXMgZmFyIGFzIDxicj5icmVha2luZyB0aGUgYW1iaWd1aXR5L2Nv bmZ1c2lvbiBpcyBjb25jZXJuZWQgPzxicj48YnI+Q2hlZXJzLCBTZXJnZXk8YnI+PGJyPk9uIDI0 LzA3LzE0IDE1OjI1LCBKb2huIEJyYWRsZXkgd3JvdGU6PGJyPiZndDsgSSBhbSBub3QgYWdhaW5z dCBkaXNjdXNzaW9uIGluIHRoZSBXRy48YnI+Jmd0Ozxicj4mZ3Q7IEkgaGFwcGVuIHRvIGFncmVl IHdpdGggUGhpbCdzIGZ1bmRhbWVudGFsIHByZW1pc2UgdGhhdCBzb21lIGRldmVsb3BlcnM8YnI+ Jmd0OyBhcmUgdXNpbmcgT0F1dGggaW4gYSBpbnNlY3VyZSB3YXkgdG8gZG8gYXV0aGVudGljYXRp b24uPGJyPiZndDs8YnI+Jmd0OyBUaGF0IHJhaXNlcyB0aGUgcXVlc3Rpb24gb2YgaG93IHRvIGJl c3QgZWR1Y2F0ZSB0aGVtLCBhbmQgb3IgYWRkcmVzczxicj4mZ3Q7IHRlY2huaWNhbCBiYXJyaWVy cy48YnI+Jmd0Ozxicj4mZ3Q7IEl0IGlzIG9uIHRoZSBzZWNvbmQgcG9pbnQgdGhhdCBwZW9wbGUn cyBvcGluaW9ucyBzZWVtIHRvIGRpdmlkZS48YnI+Jmd0Ozxicj4mZ3Q7IFNvbWUgcGVvcGxlIHRo aW5nIHRoYXQgaWYgd2UgaGF2ZSBhIE9BdXRoIGZsb3cgdGhhdCBlbGltaW5hdGVzIHRoZTxicj4m Z3Q7IGFjY2VzcyB0b2tlbiAocHJpbWFyaWx5IHRvIGF2b2lkIGFza2luZyBmb3IgY29uc2VudCBh cyBJIHVuZGVyc3RhbmQgaXQpPGJyPiZndDsgYW5kIGp1c3QgcmV0dXJuIGEgaWRfdG9rZW4gZnJv bSB0aGUgdG9rZW4gZW5kcG9pbnQgdGhhdCBjYW4gYmUgZG9uZSBpbiBhPGJyPiZndDsgc3BlYyBz aG9ydCBlbm91Z2ggdG8gaGV0IHBlb3BsZSB0byByZWFkLiZuYnNwOyZuYnNwOyBUaGUgc3VidGV4 dCBvZiB0aGlzIGlzIHRoYXQ8YnI+Jmd0OyB0aGUgQ29ubmVjdCBzcGVjaWZpY2F0aW9uIGlzIHRv byBsYXJnZSB0aGF0IGl0IHNjYXJlIHBlb3BsZSwmbmJzcDsgYW5kIHRoZXk8YnI+Jmd0OyBkb24n dCBmaW5kIHRoZSBzcGVjIGluIHRoZSBmaXJzdCBwbGFjZSBiZWNhdXNlIGl0IGlzIG5vdCBhIFJG Qy48YnI+Jmd0Ozxicj4mZ3Q7IEFuIG90aGVyIGNvbW1vbiBwb3NzZXNzaW9uIGlzIHRoYXQgaWYg eW91IGRvbid0IHdhbnQgdG8gcHJvbXB0IHRoZSB1c2VyPGJyPiZndDsgZm9yIGNvbnNlbnQgdGhl biBkb24ndCBhc2sgZm9yIHNjb3Blcy4mbmJzcDsgVHdpc3RpbmcgdGhlIE9BdXRoIHNwZWMgdG8g bm90PGJyPiZndDsgcmV0dXJuIGFuIGFjY2VzcyB0b2tlbiBpcyBub3QgT0F1dGgsJm5ic3A7IHll cyB5b3UgY291bGQgdXNlIGEgZGlmZmVyZW50PGJyPiZndDsgZW5kcG9pbnQgcmF0aGVyIHRoYW4g dGhlIHRva2VuIGVuZHBvaW50LCBidXQgdGhhdCBpcyBub3QgT0F1dGguPGJyPiZndDsgQ29ubmVj dCB3YXMgY2FyZWZ1bCBub3QgdG8gYnJlYWsgdGhlIE9BdXRoIHNwZWMuJm5ic3A7Jm5ic3A7Jm5i c3A7IEFzIGxvbmcgYXMgeW91IGFyZTxicj4mZ3Q7IHdpbGxpbmcgdG8gdGFrZSBhIGFjY2VzcyB0 b2tlbiB3aXRoIG5vIHNjb3BlcyAodGhlIGNsaWVudCBuZWVkcyB0bzxicj4mZ3Q7IHVuZGVyc3Rh bmQgdGhhdCB0aGVyZSBhcmUgbm8gYXR0cmlidXRlcyBvbmUgd2F5IG9yIGFub3RoZXIgYW55d2F5 IG9yIGl0PGJyPiZndDsgd2lsbCBicmVhaykgdGhlbiB5b3UgZG9uJ3QgbmVlZCB0byBjaGFuZ2Ug T0F1dGguJm5ic3A7Jm5ic3A7IFlvdSBjYW4gcHVibGlzaCBhPGJyPiZndDsgcHJvZmlsZSBvZiBj b25uZWN0IHRoYXQgc2F0aXNmaWVzIHRoZSB1c2UgY2FzZS48YnI+Jmd0Ozxicj4mZ3Q7IEkgdGhp bmsgTWlrZSBoYXMgbGFyZ2VseSBkb25lIHRoYXQgYnV0IGl0IG1pZ2h0IGJlIGJldHRlciBiZWlu ZyBsZXNzPGJyPiZndDsgc3Rpbmd5IG9uIHJlZmVyZW5jZXMgYmFjayB0byB0aGUgbGFyZ2VyIHNw ZWMuPGJyPiZndDs8YnI+Jmd0OyBUaGUgcXVlc3Rpb25zIGFyZSBkbyB3ZSBtb2RpZnkgT0F1dGgg dG8gbm90IHJldHVybiBhbiBhY2Nlc3MgdG9rZW4sIGFuZDxicj4mZ3Q7IGlmIHNvIGhvdywmbmJz cDsgYW5kIGlmIHdlIGRvIGlzIGl0IHN0aWxsIE9BdXRoLjxicj4mZ3Q7PGJyPiZndDsgVGhlIG90 aGVyIGxhcmdlbHkgc2VwYXJhYmxlIHF1ZXN0aW9uIGlzIGRvIHdlIGNyZWF0ZSBjb25mdXNpb24g aW4gdGhlPGJyPiZndDsgbWFya2V0IGFuZCBzbG93IHRoZSB0aGUgYWRvcHRpb24gb2YgaWRlbnRp dHkgZmVkZXJhdGlvbiBvbiB0b3Agb2YgT0F1dGgsPGJyPiZndDsgb3IgZmluZCBhIHdheSB0byBt YWtlIHRoaXMgbG9vayBsaWtlIGEgcG9zaXRpdmUgYWxpZ25tZW50IG9mIGludGVyZXN0czxicj4m Z3Q7IGFyb3VuZCBhIHN1YnNldCBvZiBDb25uZWN0Ljxicj4mZ3Q7PGJyPiZndDsgVGhlcmUgYXJl IGEgbnVtYmVyIG9mIG9wdGlvbnMuPGJyPiZndDsgMTogV2UgY2FuIGRvIGEgcHJvZmlsZSBpbiB0 aGUgT0lERiBhbmQgcHVibGlzaCBpdCBhcyBhIElFVEYgZG9jdW1lbnQuPGJyPiZndDsgUGVyaGFw cyB0aGUgY2xlYW5lc3QgZnJvbSBhbiBJUFIgcG9pbnQgb2Ygdmlldy5Ib3dldmVyPGJyPiZndDsg MjpXZSBjYW4gZG8gYSBwcm9maWxlIGluIHRoZSBPQXV0aCBXRyByZWZlcmVuY2luZyBjb25uZWN0 Ljxicj4mZ3Q7IDM6V2UgY2FuIGRvIGEgQUQgc3BvbnNvcmVkIHByb2ZpbGUgdGhhdCBpcyBub3Qg aW4gdGhlIE9BdXRoIFdHLjxicj4mZ3Q7IDQ6V2UgY2FuIGRvIGEgc21hbGwgc3BlYyBpbiBPQXV0 aCB0byBhZGQgcmVzcG9uc2VfdHlwZSB0byB0aGUgdG9rZW48YnI+Jmd0OyBlbmRwb2ludC4mbmJz cDsgaW4gY29tYmluYXRpb24gd2l0aCAxLCAyLCBvciAzPGJyPiZndDs8YnI+Jmd0OyBJIGFncmVl IHRoYXQgc3RvcGluZyBkZXZlbG9wZXJzIGRvaW5nIGluc2VjdXJlIHRoaW5ncyBuZWVkcyB0byBi ZTxicj4mZ3Q7IGFkZHJlc3NlZCBzb21laG93Ljxicj4mZ3Q7IEkgYW0gbm90IHBlcnNvbmFsbHkg Y29udmluY2VkIHRoYXQgT2F1dGggd2l0aG91dCBhY2Nlc3MgdG9rZW5zIGlzIHNlbnNpYmxlLjxi cj4mZ3Q7PGJyPiZndDsgTG9va2luZyBmb3J3YXJkIHRvIHRoZSBtZWV0aW5nOik8YnI+Jmd0Ozxi cj4mZ3Q7IEpvaG4gQi48YnI+Jmd0OyBPbiBKdWwgMjQsIDIwMTQsIGF0IDY6NTIgQU0sIEJyaWFu IENhbXBiZWxsICZsdDtiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTxicj4mZ3Q7ICZsdDttYWls dG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20mZ3Q7Jmd0OyB3cm90ZTo8YnI+Jmd0Ozxicj4m Z3Q7Jmd0OyBJJ2Qgbm90ZSB0aGF0IHRoZSByZWFjdGlvbiBhdCB0aGUgY29uZmVyZW5jZSB0byBJ YW4ncyBzdGF0ZW1lbnQgd2FzPGJyPiZndDsmZ3Q7IG92ZXJ3aGVsbWluZ2x5IHBvc2l0aXZlLiBU aGVyZSB3YXMgYSB3aWRlIHJhbmdlIG9mIGluZHVzdHJ5IHBlb3BsZTxicj4mZ3Q7Jmd0OyBoZXJl IC0gaW1wbGVtZW50ZXJzLCBwcmFjdGl0aW9uZXJzLCBkZXBsb3llcnMsIHN0cmF0ZWdpc3RzLCBl dGMuIC0gYW5kPGJyPiZndDsmZ3Q7IGl0IHNlZW1zIHByZXR0eSBjbGVhciB0aGF0IHRoZSAicm91 Z2ggY29uc2Vuc3VzIiBvZiB0aGUgaW5kdXN0cnkgYXQ8YnI+Jmd0OyZndDsgbGFyZ2UgaXMgdGhh dCBhNGMgaXMgbm90IHdhbnRlZCBvciBuZWVkZWQuPGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7PGJy PiZndDsmZ3Q7IE9uIFRodSwgSnVsIDI0LCAyMDE0IGF0IDU6MjkgQU0sIE5hdCBTYWtpbXVyYSAm bHQ7c2FraW11cmFAZ21haWwuY29tPGJyPiZndDsmZ3Q7ICZsdDttYWlsdG86c2FraW11cmFAZ21h aWwuY29tJmd0OyZndDsgd3JvdGU6PGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IEFuZCBoZXJlIGlzIGEgcXVvdGUgZnJvbSBJYW4ncyBibG9nLjxicj4mZ3Q7 Jmd0Ozxicj4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBBbmQgYWx0aG91Z2ggdGhlIGF1dGhlbnRpY2F0aW9uIHdoZWVsIGlzIHJvdW5kLCB0 aGF0IGRvZXNu4oCZdDxicj4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBtZWFuIGl0IGlzbuKAmXQgd2l0aG91dCBpdHMgbHVtcHMuIEZpcnN0 LCB3ZSBkbyBzZWUgc29tZTxicj4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyByZWludmVudGluZyB0aGUgd2hlZWwganVzdCB0byByZWludmVu dCB0aGUgd2hlZWwuIE9BdXRoIEE0QyBpczxicj4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzaW1wbHkgbm90IGEgZnJ1aXRmdWwgYWN0aXZp dHkgYW5kIHNob3VsZCBiZSBwdXQgZG93bi48YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKFNvdXJjZSk8YnI+Jmd0 OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaHR0 cDovL3d3dy50dWVzZGF5bmlnaHQub3JnLzIwMTQvMDcvMjMvZG8td2UtaGF2ZS1hLXJvdW5kLXdo ZWVsLXlldC1tdXNpbmdzLW9uLWlkZW50aXR5LXN0YW5kYXJkcy1wYXJ0LTEuaHRtbDxicj4mZ3Q7 Jmd0Ozxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAyMDE0LTA3LTIzIDE2OjUzIEdNVC0wNDowMCBKb2huIEJyYWRsZXkgJmx0O3ZlN2p0 YkB2ZTdqdGIuY29tPGJyPiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDttYWls dG86dmU3anRiQHZlN2p0Yi5jb20mZ3Q7Jmd0Ozo8YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSSB0aG91Z2h0IEkg ZGlkIHBvc3QgdGhpcyB0byB0aGUgbGlzdC48YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSSBndWVzcyBJIGhpdCB0 aGUgd3JvbmcgcmVwbHkgb24gbXkgcGhvbmUuPGJyPiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEpvaG4gQi48YnI+Jmd0OyZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU2VudCBmcm9tIG15IGlQ aG9uZTxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBPbiBKdWwgMjMsIDIwMTQsIGF0IDQ6NTAgUE0sIHRvcnN0ZW5A bG9kZGVyc3RlZHQubmV0PGJyPiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDttYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQmZ3Q7 IHdyb3RlOjxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgd2UgYXJlIHR3bywgYXQgbGVhc3QgOi0pPGJyPiZn dDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgV2h5IGRpZG4ndCB5b3UgcG9zdCB0aGlzIG9uIHRoZSBsaXN0Pzxi cj4mZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFdoZW4gd2lsbCBiZSBiZSBhcnJpdmluZz88YnI+Jmd0OyZn dDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBBbSAyMy4wNy4yMDE0IDE2OjM5LCBzY2hyaWViIEpvaG4gQnJhZGxleTo8 YnI+Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSWFuIEdsYXplciBtZW50aW9uZWQgdGhpcyBpbiBo aXMga2V5bm90ZSBhdCBDSVMgeWVzdGVyZGF5Ljxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEhpcyBhZHZpY2Ugd2FzIHBs ZWFzZSBzdG9wLCZuYnNwOyB3ZSBhcmUgY3JlYXRpbmcgY29uZnVzaW9uIGFuZDxicj4mZ3Q7Jmd0 OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHVuY2VydGFpbnR5Ljxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFdlIGFyZSBiZWNvbWluZyBvdXIgb3duIHdvcnQgZW5l bXkuICggbXkgdmlldyB0aG91Z2ggSWFuIG1heTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNoYXJlIGl0KTxicj4mZ3Q7 Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IFJldHVybmluZyBqdXN0IGFuIGlkXyB0b2tlbiBmcm9tIHRoZSB0b2tlbiBlbmRwb2ludCBo YXM8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBsaXR0bGUgcmVhbCB2YWx1ZS48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTb21ldGhpbmcgcmVh bGx5IHVzZWZ1bCB0byBkbyB3b3VsZCBiZSBzb3J0aW5nIG91dDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNoYW5uZWxf aWQgc28gd2UgY2FuIGRvIFBvUCBmb3IgaWQgdG9rZW5zIHRvIG1ha2UgdGhlbSBhbmQ8YnI+Jmd0 OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBvdGhlciBjb29raWVzIHNlY3VyZSBpbiB0aGUgZnJvbnQgY2hhbm5lbC4mbmJzcDsmbmJz cDsgSSB0aGluayB0aGF0IGlzPGJyPiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYSBiZXR0ZXIgdXNlIG9mIHRpbWUuPGJyPiZn dDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgSSBtYXkgYmUgaW4gdGhlIG1pbm9yaXR5IG9waW5pb24gb24gdGhhdCwmbmJzcDsgaXQg d29uJ3QgYmUgdGhlPGJyPiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZmlyc3QgdGltZS48YnI+Jmd0OyZndDsmZ3Q7Jmd0Ozxi cj4mZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSm9obiBCLjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNlbnQgZnJv bSBteSBpUGhvbmU8YnI+Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9uIEp1bCAyMywgMjAx NCwgYXQgNDowNCBQTSwgVG9yc3RlbiBMb2RkZXJzdGVkdDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDt0b3JzdGVu QGxvZGRlcnN0ZWR0Lm5ldCAmbHQ7bWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Jmd0OyZn dDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB3cm90ZTo8YnI+Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBZ b3UgYXJlIHJpZ2h0IGZyb20gYSB0aGVvcmV0aWNhbCBwZXJzcGVjdGl2ZS4gUHJhY3RpY2FsbHk8 YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgdGhpcyB3YXMgY2F1c2VkIGJ5IGVkaXRvcmlhbCBkZWNpc2lvbnMgZHVy aW5nIHRoZSBjcmVhdGlvbjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBvZiB0aGUgUkZDLiBBcyBmYXIgYXMgSSBy ZW1lbWJlciwgdGhlcmUgd2FzIGEgZGVmaW5pdGlvbiBvZjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGUgKG9u ZSkgdG9rZW4gZW5kcG9pbnQgcmVzcG9uc2UgaW4gZWFybHkgdmVyc2lvbnMuIE5vIG9uZTxicj4m Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBldmVyeSBjb25zaWRlcmVkIHRvIE5PVCByZXNwb25kIHdpdGggYW4gYWNjZXNz IHRva2VuIGZyb208YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhlIHRva2VuIGVuZHBvaW50LiBTbyBvbmUgbWln aHQgY2FsbCBpdCBhbiBpbXBsaWNpdDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhc3N1bXB0aW9uLjxicj4mZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBJJ20gd29ycmllZCB0aGF0IHBlb3BsZSBnZXQgdG90YWxseSBjb25mdXNlZCBpZiBh bjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBleGNlcHRpb24gaXMgaW50cm9kdWNlZCBub3cgZ2l2ZW4gdGhlIGJy b2FkIGFkb3B0aW9uIG9mPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9BdXRoIGJhc2VkIG9uIHRoaXMgYXNzdW1w dGlvbi48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgcmVnYXJkcyw8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVG9yc3Rlbi48YnI+ Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQW0gMjMuMDcuMjAxNCB1bSAxNTo0 MSBzY2hyaWViIFRob21hcyBCcm95ZXI8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O3QuYnJveWVyQGdtYWls LmNvbSAmbHQ7bWFpbHRvOnQuYnJveWVyQGdtYWlsLmNvbSZndDsmZ3Q7Ojxicj4mZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSXMgaXQgc2FpZCBhbnl3aGVyZSB0aGF0IEFM TCBncmFudCB0eXBlcyBNVVNUIHVzZSBTZWN0aW9uPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA1LjEgcmVz cG9uc2VzPyBFYWNoIGdyYW50IHR5cGUgcmVmZXJlbmNlcyBTZWN0aW9uIDUuMSwgYW5kPGJyPiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAiYWNjZXNzIHRva2VuIHJlcXVlc3QiIGlzIG9ubHkgZGVmaW5lZCBpbiB0 aGUgY29udGV4dCBvZjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhlIGRlZmluZWQgZ3JhbnQgdHlwZXMu IFNlY3Rpb24gMi4yIGRvZXNuJ3QgdGFsayBhYm91dDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhlIHJl cXVlc3Qgb3IgcmVzcG9uc2UgZm9ybWF0Ljxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+ Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IExlIDIzIGp1aWwuIDIwMTQgMjE6MzIsICJOYXQgU2FraW11cmEiICZs dDtzYWtpbXVyYUBnbWFpbC5jb208YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDttYWlsdG86c2FraW11 cmFAZ21haWwuY29tJmd0OyZndDsgYSDDqWNyaXQgOjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IElzIGl0PyBBcGFy dCBmcm9tIHRoZSBpbXBsaWNpdCBncmFudCB0aGF0IGRvZXMgbm90IHVzZTxicj4mZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdG9rZW4gZW5kcG9pbnQsIGFsbCBvdGhlciBn cmFudCByZWZlcmVuY2VzIHNlY3Rpb24gNS4xPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBmb3IgdGhlIHJlc3BvbnNlLCBpLmUuLCBhbGwgc2hhcmVzIHRoZSBzYW1l IHJlc3BvbnNlLjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAyMDE0 LTA3LTIzIDE1OjE4IEdNVC0wNDowMCBUaG9tYXMgQnJveWVyPGJyPiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7dC5icm95ZXJAZ21haWwuY29tICZsdDttYWlsdG86 dC5icm95ZXJAZ21haWwuY29tJmd0OyZndDs6PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxi cj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgSSBoYWRuJ3QgcmVhbGl6ZWQgdGhlIEpTT04gcmVzcG9uc2UgdGhhdCByZXF1aXJl czxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgdGhlIGFjY2Vzc190b2tlbiBmaWVsZCBpcyBkZWZpbmVkIHBlciBncmFudF90 eXBlLDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgc28gSSdkIGJlIE9LIHRvICJleHRlbmQgdGhlIHNlbWFudGljcyIgYXMg aW4gdGhlPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBjdXJyZW50IGRyYWZ0Ljxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhhdCB3YXMgYWN0dWFs bHkgbXkgbWFpbiBjb25jZXJuOiB0aGF0IHRoZSB0b2tlbjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZW5kcG9pbnQgbWFu ZGF0ZXMgYWNjZXNzX3Rva2VuOyBidXQgaXRzIGFjdHVhbGx5PGJyPiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBub3QgdGhlIGNh c2UuPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTGUgMjMganVpbC4gMjAx NCAyMDo0NiwgIk5hdCBTYWtpbXVyYSI8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDtzYWtpbXVyYUBnbWFpbC5jb20g Jmx0O21haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20mZ3Q7Jmd0OyBhPGJyPiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyDDqWNyaXQg Ojxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IEkgYWdyZWUgd2l0aCBKb2huIHRoYXQgb3ZlcmxvYWRpbmc8YnI+Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJlc3BvbnNlX3R5cGUgQCBhdXRoeiBlbmRwb2ludCBpcyBhIGJh ZCBpZGVhLjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSXQgY29tcGxldGVseSBj aGFuZ2VzIHRoZSBzZW1hbnRpY3Mgb2YgdGhpczxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgcGFyYW1ldGVyLiBOT1RFOiB3aGF0IEkgd2FzIHByb3Bvc2luZyB3YXMgbm90PGJyPiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGlzIHBhcmFtZXRlciwgYnV0IGEgbmV3IHBh cmFtZXRlcjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcmVzcG9uc2VfdHlwZSBA IHRva2VuIGVuZHBvaW50Ljxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSSBhbHNv IHRoaW5rIG92ZXJsb2FkaW5nIGdyYW50X3R5cGUgaXMgYSBiYWQ8YnI+Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IGlkZWEgc2luY2UgaXQgY2hhbmdlcyBpdHMgc2VtYW50aWNzLiBJIHF1 b3RlPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGUgZGVmaW5pdGlvbiBoZXJl IGFnYWluOjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZ3JhbnQ8YnI+Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNyZWRlbnRp YWwgcmVwcmVzZW50aW5nIHRoZSByZXNvdXJjZTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgb3duZXIncyBhdXRob3JpemF0aW9uPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBncmFudF90eXBlPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0eXBlIG9m IGdyYW50IHNlbnQgdG8gdGhlIHRva2VuIGVuZHBvaW50IHRvPGJyPiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBvYnRhaW4gdGhlIGFjY2VzcyB0b2tlbjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgSXQgaXMgbm90IGFib3V0IGNvbnRyb2xsaW5nIHdoYXQgaXMgdG8gYmU8 YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJldHVybmVkIGZyb20gdGhlIHRva2Vu IGVuZHBvaW50LCBidXQgdGhlIGhpbnQ8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHRvIHRoZSB0b2tlbiBlbmRwb2ludCBkZXNjcmliaW5nIHRoZSB0eXBlIG9mPGJyPiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjcmVkZW50aWFsIHRoZSBlbmRwb2ludCBoYXMgcmVjZWl2 ZWQuIEl0IHNlZW1zPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGUgImNvbnRy b2wgb2Ygd2hhdCBpcyBiZWluZyByZXR1cm5lZCBmcm9tPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB0b2tlbiBlbmRwb2ludCImbmJzcDsgaXMganVzdCBhIHNpZGUgZWZmZWN0Ljxi cj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSSBhbSBzb21ld2hhdCBhbWJpdmFsZW50 WzFdIGluIGNoYW5naW5nIHRoZTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc2Vt YW50aWNzIG9mIHRva2VuIGVuZHBvaW50LCBidXQgaW4gYXMgbXVjaCBhczxicj4mZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgInRleHQgaXMgdGhlIGtpbmciIGZvciBhIHNwZWMuLCB3ZSBw cm9iYWJseTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc2hvdWxkIG5vdCBjaGFu Z2UgdGhlIHNlbWFudGljcyBvZiBpdCBhczxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgVG9yc3RlbiBwb2ludHMgb3V0LiBJZiBpdCBpcyBvayB0byBjaGFuZ2UgdGhpczxicj4mZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc2VtYW50aWNzLCBJIGJlbGlldmUgZGVmaW5pbmcg YSBuZXcgcGFyYW1ldGVyPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0byB0aGlz IGVuZHBvaW50IHRvIGNvbnRyb2wgdGhlIHJlc3BvbnNlIHdvdWxkPGJyPiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBiZSB0aGUgYmVzdCB3YXkgdG8gZ28uIFRoaXMgaXMgd2hhdCBJIGhh dmU8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRlc2NyaWJlZCBwcmV2aW91c2x5 Ljxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRGVmaW5pbmcgYSBuZXcgZW5kcG9p bnQgdG8gc2VuZCBjb2RlIHRvIGdldCBJRDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgVG9rZW4gYW5kIGZvcmJpZGRpbmcgdGhlIHVzZSBvZiBpdCBhZ2FpbnN0PGJyPiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0b2tlbiBlbmRwb2ludCB3b3VsZCBub3QgY2hhbmdlIHRo ZSBzZW1hbnRpY3M8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9mIGFueSBleGlz dGluZyBwYXJhbWV0ZXIgb3IgZW5kcG9pbnQsIHdoaWNoPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBpcyBnb29kLiBIb3dldmVyLCBJIGRvdWJ0IGlmIGl0IGlzIG5vdCB3b3J0aDxi cj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZG9pbmcuIFdoYXQncyB0aGUgcG9pbnQg b2YgYXZvaWRpbmcgYWNjZXNzPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0b2tl biBzY29wZWQgdG8gVXNlckluZm8gZW5kcG9pbnQgYWZ0ZXIgYWxsPzxicj4mZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgRGVmaW5pbmcgYSBuZXcgZW5kcG9pbnQgZm9yIGp1c3QgYXZvaWRp bmcgdGhlPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhY2Nlc3MgdG9rZW4gZm9y IHVzZXJpbmZvIGVuZHBvaW50IHNlZW1zIHdheTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgdG9vIG11Y2ggdGhlIGhlYXZ5IHdhaXQgd2F5IGFuZCBpdCBicmVha3M8YnI+Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGludGVyb3BlcmFiaWxpeTogaXQgZGVmZWF0cyB0aGUg cHVycG9zZSBvZjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc3RhbmRhcmRpemF0 aW9uLjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSSBoYXZlIHN0YXJ0ZWQgZmVl bGluZyB0aGF0IG5vIGNoYW5nZSBpcyB0aGU8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IGJlc3Qgd2F5IG91dC48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE5hdDxi cj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgWzFdJm5ic3A7IElmIGluc3RlYWQgb2Yg c2F5aW5nICJUb2tlbiBlbmRwb2ludCAtPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB1c2VkIGJ5IHRoZSBjbGllbnQgdG8gZXhjaGFuZ2UgYW48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IGF1dGhvcml6YXRpb24gZ3JhbnQgZm9yIGFuIGFjY2VzcyB0b2tlbiw8YnI+ Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHR5cGljYWxseSB3aXRoIGNsaWVudCBhdXRo ZW50aWNhdGlvbiIsIGl0IHdlcmU8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNh eWluZyAiVG9rZW4gZW5kcG9pbnQgLSB1c2VkIGJ5IHRoZSBjbGllbnQgdG88YnI+Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGV4Y2hhbmdlIGFuIGF1dGhvcml6YXRpb24gZ3JhbnQgZm9y IHRva2Vucyw8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHR5cGljYWxseSB3aXRo IGNsaWVudCBhdXRoZW50aWNhdGlvbiIsIHRoZW4gaXQ8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHdvdWxkIGhhdmUgYmVlbiBPSy4gSXQgaXMgYW4gZXhwYW5zaW9uIG9mIHRoZTxi cj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY2FwYWJpbGl0eSByYXRoZXIgdGhhbiBj aGFuZ2luZyB0aGUgc2VtYW50aWNzLjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAy MDE0LTA3LTIzIDEzOjM5IEdNVC0wNDowMCBNaWtlIEpvbmVzPGJyPiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmbHQ7TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPGJyPiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0 LmNvbSZndDsmZ3Q7Ojxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFlvdSBuZWVkIHRoZSBh bHRlcm5hdGl2ZSByZXNwb25zZV90eXBlPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB2YWx1ZSAoImNvZGVfZm9yX2lkX3Rva2VuIiBpbiB0 aGUgQTRDPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBkcmFmdCkgdG8gdGVsbCB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgdG88YnI+Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJldHVy biBhIGNvZGUgdG8gYmUgdXNlZCB3aXRoIHRoZSBuZXc8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGdyYW50IHR5cGUsIHJhdGhlciB0aGFu IG9uZSB0byB1c2Ugd2l0aDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgdGhlICJhdXRob3JpemF0aW9uX2NvZGUiIGdyYW50IHR5cGUgKHdo aWNoPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBpcyB3aGF0IHJlc3BvbnNlX3R5cGU9Y29kZSBkb2VzKS48YnI+Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKkZyb206Kk9BdXRoPGJyPiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBbbWFp bHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRm Lm9yZyZndDtdICpPbjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgQmVoYWxmIE9mICpKb2huIEJyYWRsZXk8YnI+Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICpTZW50OiogV2VkbmVzZGF5 LCBKdWx5IDIzLCAyMDE0IDEwOjMzIEFNPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAqVG86KiB0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDxi cj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmx0O21haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldCZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKkNjOiogb2F1dGhAaWV0Zi5v cmcgJmx0O21haWx0bzpvYXV0aEBpZXRmLm9yZyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICpTdWJqZWN0OiogUmU6IFtPQVVUSC1X R10gTmV3IFZlcnNpb248YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IE5vdGlmaWNhdGlvbiBmb3I8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRyYWZ0LWh1bnQtb2F1dGgtdjItdXNl ci1hNGMtMDUudHh0PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IElmIHdlIHVzZSB0aGUgdG9rZW4gZW5kcG9pbnQgdGhlbiBhIG5ldzxicj4m Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZ3Jh bnRfdHlwZSBpcyB0aGUgYmVzdCB3YXkuPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4m Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEl0IHNvcnQgb2Ygb3ZlcmxvYWRzIGNvZGUsIGJ1dCB0 aGF0IGlzPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBiZXR0ZXIgdGhhbiBtZXNzaW5nIHdpdGggcmVzcG9uc2VfdHlwZSBmb3I8YnI+Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZSBh dXRob3JpemF0aW9uIGVuZHBvaW50IHRvIGNoYW5nZSB0aGU8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJlc3BvbnNlIGZyb20gdGhlIHRv a2VuX2VuZHBvaW50LiZuYnNwOyBUaGF0IGlzPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpbiBteSBvcGluaW9uIGEgY2hhbXBpb24gYmFk IGlkZWEuPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IEluIGRpc2N1c3Npb25zIGRldmVsb3BpbmcgQ29ubmVjdCB3ZTxicj4mZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZGVjaWRlZCBub3Qg dG8gb3BlbiB0aGlzIGNhbiBvZiB3b3Jtczxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYmVjYXVzZSBubyBnb29kIHdvdWxkIGNvbWUgb2Yg aXQuPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IFRoZSB0b2tlbl9lbmRwb2ludCByZXR1cm5zIGEgYWNjZXNzIHRva2VuLjxicj4mZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTm90 aGluZyByZXF1aXJlcyBzY29wZSB0byBiZSBhc3NvY2lhdGVzPGJyPiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB3aXRoIHRoZSB0b2tlbi48YnI+ Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4m Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhh dCBpcyB0aGUgYmVzdCBzb2x1dGlvbi4mbmJzcDsgTm8gY2hhbmdlPGJyPiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyByZXF1aXJlZC4mbmJzcDsg QmV0dGVyIGludGVyb3BlcmFiaWxpdHkgaW4gbXk8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9waW5pb24uPGJyPiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFN0aWxsIG9uIG15IHdheSB0 byBUTywgZ2V0dGluZyBpbiBsYXRlcjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdG9kYXkuPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEpvaG4gQi48YnI+Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTZW50IGZyb20gbXkgaVBob25l PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8 YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IE9uIEp1bCAyMywgMjAxNCwgYXQgMTI6MTUgUE0sPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDxi cj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmx0O21haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldCZndDsgd3JvdGU6PGJyPiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhlICJyZXNwb25zZSB0 eXBlIiBvZiB0aGUgdG9rZW48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGVuZHBvaW50IGlzIGNv bnRyb2xsZWQgYnkgdGhlIHZhbHVlIG9mPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGUgcGFy YW1ldGVyICJncmFudF90eXBlIi4gU28gdGhlcmU8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGlz IG5vIG5lZWQgdG8gaW50cm9kdWNlIGEgbmV3IHBhcmFtZXRlci48YnI+Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB3cnQgdG8gYSBwb3RlbnRpYWwgIm5v X2FjY2Vzc190b2tlbiI8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGdyYW50IHR5cGUuIEkgZG8g bm90IGNvbnNpZGVyIHRoaXMgYTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZ29vZCBpZGVhIGFz IGl0IGNoYW5nZXMgdGhlIHNlbWFudGljczxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgb2YgdGhl IHRva2VuIGVuZHBvaW50IChhcyBhbHJlYWR5PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBwb2lu dGVkIG91dCBieSBUaG9tYXMpLiBUaGlzIGVuZHBvaW50PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBBTFdBWVMgcmVzcG9uZHMgd2l0aCBhbiBhY2Nlc3MgdG9rZW48YnI+Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHRvIGFueSBncmFudCB0eXBlLiBJIHRoZXJlZm9yZSB3b3VsZDxicj4mZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgcHJlZmVyIHRvIHVzZSBhbm90aGVyIGVuZHBvaW50IGZvciB0aGU8YnI+Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IGludGVuZGVkIHB1cnBvc2UuPGJyPiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcmVnYXJkcyw8YnI+Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IFRvcnN0ZW4uPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFtIDIzLjA3LjIwMTQg MTM6MDQsIHNjaHJpZWIgTmF0IFNha2ltdXJhOjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8 YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IElNSE8sIGNo YW5naW5nIHRoZSBzZW1hbnRpY3Mgb2Y8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICJyZXNwb25zZV90eXBlIiBAIGF1dGh6IGVuZHBvaW50PGJyPiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGlzIHdheSBpcyBub3Qg YSBnb29kIHRoaW5nLjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBJbnN0ZWFkLCBkZWZpbmluZyBhIG5ldyBwYXJhbWV0ZXI8YnI+Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICJyZXNwb25zZV90eXBlIiBAIHRva2VuIGVu ZHBvaW50LDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg YXMgSSBkZXNjcmliZWQgaW4gbXkgcHJldmlvdXM8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG1lc3NhZ2UsPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcHJvYmFi bHkgaXMgYmV0dGVyLiBBdCBsZWFzdCwgaXQ8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRvZXMgbm90IGNoYW5nZSB0aGUgc2VtYW50aWNzIG9mPGJyPiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGUgcGFyYW1ldGVy cyBvZiBSRkM2NzQ5Ljxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBOYXQ8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgMjAxNC0wNy0yMyAxMjo0OCBHTVQtMDQ6MDAgVGhvbWFzPGJyPiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBCcm95ZXIgJmx0O3QuYnJveWVyQGdtYWls LmNvbTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0 O21haWx0bzp0LmJyb3llckBnbWFpbC5jb20mZ3Q7Jmd0Ozo8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBO bywgSSBtZWFuIHJlc3BvbnNlX3R5cGU9bm9uZSBhbmQ8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJlc3BvbnNlX3R5cGU9aWRfdG9rZW4gZG9uJ3Q8YnI+ Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGdlbmVyYXRlIGEg Y29kZSBvciBhY2Nlc3MgdG9rZW4gc288YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHlvdSBkb24ndCB1c2UgdGhlIFRva2VuIEVuZHBvaW50PGJyPiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAod2hpY2ggaXMgbm90IHRo ZSBzYW1lIGFzIHRoZTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgQXV0aGVudGljYXRpb24gRW5kcG9pbnQgQlRXKS48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBX aXRoPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyByZXNw b25zZV90eXBlPWNvZGVfZm9yX2lkX3Rva2VuLDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgeW91IGdldCBhIGNvZGUgYW5kIGV4Y2hhbmdlIGl0IGZvcjxi cj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYW4gaWRfdG9r ZW4gb25seSwgcmF0aGVyIHRoYW4gYW48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IGFjY2Vzc190b2tlbiwgc28geW91J3JlIGNoYW5naW5nPGJyPiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGUgc2VtYW50aWNzIG9m IHRoZSBUb2tlbiBFbmRwb2ludC48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgSSdtIG5vdCBzYXlpbmcgaXQncyBhIGJhZCB0aGluZyw8YnI+Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGp1c3QgdGhhdCB5b3UgY2FuJ3Qg cmVhbGx5IGNvbXBhcmU8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IG5vbmUgYW5kIGlkX3Rva2VuIHdpdGg8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNvZGVfZm9yX2lkX3Rva2VuLjxicj4mZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBPbiBXZWQsIEp1bCAyMywgMjAxNCBhdCA2 OjQ1IFBNLDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg UmljaGVyLCBKdXN0aW4gUC48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZsdDtqcmljaGVyQG1pdHJlLm9yZzxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O21haWx0bzpqcmljaGVyQG1pdHJlLm9yZyZndDsm Z3Q7IHdyb3RlOjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEl0J3Mgb25seSAibm90IHVzaW5nIHRoZSB0 b2tlbjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZW5k cG9pbnQiIGJlY2F1c2UgdGhlIHRva2VuPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBlbmRwb2ludCBjb3B5LXBhc3RlZCBhbmQgcmVuYW1lZDxicj4mZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhlIGF1dGhlbnRpY2F0 aW9uIGVuZHBvaW50Ljxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAtLSBKdXN0aW48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgT24gSnVsIDIzLCAyMDE0LCBhdCA5OjMwIEFNLDxicj4mZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhvbWFzIEJyb3llciAmbHQ7dC5icm95 ZXJAZ21haWwuY29tPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmbHQ7bWFpbHRvOnQuYnJveWVyQGdtYWlsLmNvbSZndDsmZ3Q7IHdyb3RlOjxicj4mZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgRXhjZXB0IHRoYXQgdGhlc2UgYXJlIGFib3V0IG5vdDxicj4mZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdXNpbmcgdGhlIFRva2VuIEVuZHBv aW50IGF0IGFsbCw8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHdoZXJlYXMgdGhlIGN1cnJlbnQgcHJvcG9zYWwgaXM8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFib3V0IHRoZSBUb2tlbiBFbmRwb2ludCBub3Q8 YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJldHVybmlu ZyBhbiBhY2Nlc3NfdG9rZW4gZmllbGQgaW48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZSBKU09OLjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8 YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBPbiBXZWQsIEp1bCAyMywgMjAxNCBhdCA0OjI2IFBNLDxicj4m Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTWlrZSBKb25lczxi cj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O01pY2hh ZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmx0O21haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20mZ3Q7 Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgd3Jv dGU6PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhlIHJlc3BvbnNlX3R5cGUgIm5vbmUiIGlzPGJyPiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhbHJlYWR5IHVzZWQg aW4gcHJhY3RpY2UsIHdoaWNoPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyByZXR1cm5zIG5vIGFjY2VzcyB0b2tlbi4mbmJzcDsgSXQgd2FzPGJyPiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhY2NlcHRlZCBieSB0aGUg ZGVzaWduYXRlZCBleHBlcnRzPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBhbmQgcmVnaXN0ZXJlZCBpbiB0aGUgSUFOQSBPQXV0aDxicj4mZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQXV0aG9yaXphdGlvbiBFbmRwb2lu dCBSZXNwb25zZTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgVHlwZXMgcmVnaXN0cnkgYXQ8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IGh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvb2F1dGgtcGFyYW1l dGVycy9vYXV0aC1wYXJhbWV0ZXJzLnhtbCNlbmRwb2ludDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O2h0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdu bWVudHMvb2F1dGgtcGFyYW1ldGVycy9vYXV0aC1wYXJhbWV0ZXJzLnhtbCNlbmRwb2ludCZndDsu PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGUgcmVn aXN0ZXJlZCAiaWRfdG9rZW4iIHJlc3BvbnNlPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB0eXBlIGFsc28gcmV0dXJucyBubyBhY2Nlc3MgdG9rZW4uPGJy PiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+ Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNvIEkgdGhpbmsg dGhlIHF1ZXN0aW9uIG9mIHdoZXRoZXI8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHJlc3BvbnNlIHR5cGVzIHRoYXQgcmVzdWx0IGluIG5vPGJyPiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhY2Nlc3MgdG9rZW4gYmVp bmcgcmV0dXJuZWQgYXJlPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBhY2NlcHRhYmxlIHdpdGhpbiBPQXV0aCAyLjAgaXM8YnI+Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFscmVhZHkgc2V0dGxlZCwgYXMgYSBwcmFj dGljYWw8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG1h dHRlci4mbmJzcDsgTG90cyBvZiBPQXV0aDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgaW1wbGVtZW50YXRpb25zIGFyZSBhbHJlYWR5IHVzaW5nPGJyPiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzdWNoIHJlc3BvbnNl IHR5cGVzLjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAqRnJvbToqT0F1dGg8YnI+Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRm Lm9yZzxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0 O21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnJmd0O108YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICpPbiBCZWhhbGYgT2YgKlBoaWwgSHVudDxicj4m Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKlNlbnQ6KiBXZWRu ZXNkYXksIEp1bHkgMjMsIDIwMTQ8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IDc6MDkgQU08YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICpUbzoqIE5hdCBTYWtpbXVyYTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKkNjOiogJmx0O29hdXRoQGlldGYub3JnPGJyPiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7bWFpbHRvOm9hdXRo QGlldGYub3JnJmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICpTdWJqZWN0OiogUmU6IFtPQVVUSC1XR10gTmV3PGJyPiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3I8 YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRyYWZ0LWh1 bnQtb2F1dGgtdjItdXNlci1hNGMtMDUudHh0PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxi cj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IFllcy4gVGhpcyBpcyB3aHkgaXQgaGFzIHRvIGJlPGJyPiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkaXNjdXNzZWQgaW4gdGhl IElFVEYuPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFBo aWw8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQGluZGVw ZW5kZW50aWQ8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB3d3cuaW5kZXBlbmRlbnRpZC5jb208YnI+Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDtodHRwOi8vd3d3 LmluZGVwZW5kZW50aWQuY29tLyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBwaGlsLmh1bnRAb3Jh Y2xlLmNvbTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmx0O21haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBPbiBKdWwgMjMsIDIwMTQsIGF0IDk6NDMgQU0sIE5h dDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU2FraW11 cmEgJmx0O3Nha2ltdXJhQGdtYWlsLmNvbTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmx0O21haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20mZ3Q7Jmd0OyB3 cm90ZTo8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUmVh ZGluZyBiYWNrIHRoZSBSRkM2NzQ5LCBJIGFtIG5vdDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc3VyZSBpZiB0aGVyZSBpcyBhIGdvb2Qgd2F5IG9mPGJy PiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzdXBwcmVzc2lu ZyBhY2Nlc3MgdG9rZW4gZnJvbSB0aGU8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHJlc3BvbnNlIGFuZCBzdGlsbCBiZSBPQXV0aC4gSXQ8YnI+Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHdpbGwgYnJlYWsgd2hvbGUg YnVuY2ggb2YgaW1wbGljaXQ8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IGRlZmluaXRpb25zIGxpa2U6PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxi cj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IGF1dGhvcml6YXRpb24gc2VydmVyPGJyPiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBUaGUgc2VydmVyIGlzc3VpbmcgYWNjZXNzPGJyPiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0b2tlbnMgdG8gdGhlIGNsaWVudCBhZnRlcjxi cj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc3VjY2Vzc2Z1 bGx5PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhdXRoZW50aWNhdGluZyB0aGUgcmVzb3Vy Y2U8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG93bmVy IGFuZCBvYnRhaW5pbmcgYXV0aG9yaXphdGlvbi48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgQWZ0ZXIgYWxsLCBPQXV0aCBpcyBhbGwgYWJvdXQ8YnI+Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGlzc3VpbmcgYWNjZXNz IHRva2Vucy48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg QWxzbywgSSB0YWtlIGJhY2sgbXkgc3RhdGVtZW50IG9uPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGUgZ3JhbnQgdHlwZSBpbiBteSBwcmV2aW91cyBt YWlsLjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGUg ZGVmaW5pdGlvbiBvZiBncmFudCBhbmQ8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IGdyYW50X3R5cGUgYXJlIHJlc3BlY3RpdmVseTo8YnI+Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZ3JhbnQ8YnI+Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjcmVkZW50aWFsIHJlcHJlc2VudGluZyB0aGU8 YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJlc291cmNl IG93bmVyJ3MgYXV0aG9yaXphdGlvbjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBncmFudF90eXBlPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4m Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgKHN0cmluZyByZXByZXNlbnRpbmcgdGhlKSB0eXBlPGJyPiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBvZiBncmFudCBzZW50IHRvIHRoZSB0 b2tlbjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZW5k cG9pbnQgdG8gb2J0YWluIHRoZSBhY2Nlc3MgdG9rZW48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGh1cywgdGhlIGdyYW50IHNlbnQgdG8gdGhlIHRva2Vu PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBlbmRwb2lu dCBpbiB0aGlzIGNhc2UgaXMgc3RpbGw8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICdjb2RlJy48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgUmVzcG9uc2UgdHlwZSBvbiB0aGUgb3RoZXIgaGFuZCBpczxicj4mZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbm90IHNvIHdlbGwgZGVm aW5lZCBpbiBSRkM2NzQ5LDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgYnV0IGl0IHNlZW1zIGl0IGlzIHJlcHJlc2VudGluZzxicj4mZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgd2hhdCBpcyB0byBiZSByZXR1cm5lZCBm cm9tIHRoZTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg YXV0aG9yaXphdGlvbiBlbmRwb2ludC4gVG8gZXhwcmVzczxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgd2hhdCBpcyB0byBiZSByZXR1cm5lZCBmcm9tIHRv a2VuPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBlbmRw b2ludCwgcGVyaGFwcyBkZWZpbmluZyBhIG5ldzxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgcGFyYW1ldGVyIHRvIHRoZSB0b2tlbiBlbmRwb2ludCw8YnI+ Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHdoaWNoIGlzIGEg cGFyYWxsZWwgdG8gdGhlPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyByZXNwb25zZV90eXBlIHRvIHRoZSBBdXRob3JpemF0aW9uPGJyPiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBFbmRwb2ludCBzZWVtcyB0byBiZSBh IG1vcmU8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHN5 bW1ldHJpYyB3YXksIHRob3VnaCBJIGFtIG5vdDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgc3VyZSBhdCBhbGwgaWYgdGhhdCBpcyBnb2luZyB0byBiZTxi cj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgT0F1dGggYW55 IG1vcmUuIE9uZSBzdHJhdy1tYW4gaXM8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHRvIGRlZmluZSBhIG5ldyBwYXJhbWV0ZXIgY2FsbGVkPGJyPiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyByZXNwb25zZV90eXBlIHRv IHRoZSB0b2tlbjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgZW5kcG9pbnQgc3VjaCBhczo8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgcmVzcG9uc2VfdHlwZTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+ Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IE9QVElPTkFMLiBBIHN0cmluZzxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcmVwcmVzZW50aW5nIHdoYXQgaXMgdG8gYmU8YnI+Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJldHVybmVkIGZyb20g dGhlIHRva2VuIGVuZHBvaW50Ljxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBUaGVuIGRlZmluZSB0aGUgYmVoYXZpb3Igb2YgdGhlPGJyPiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBlbmRwb2ludCBhY2NvcmRpbmcgdG8g dGhlIHZhbHVlczxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgYXMgdGhlIHBhcmFsbGVsIHRvIHRoZTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgbXVsdGktcmVzcG9uc2UgdHlwZSBzcGVjLjxicj4mZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGh0dHA6Ly9vcGVuaWQubmV0L3NwZWNzL29hdXRoLXYyLW11bHRpcGxlLXJlc3BvbnNl LXR5cGVzLTFfMC5odG1sPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IE5hdDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAyMDE0LTA3LTIzIDc6MjEgR01ULTA0OjAwIFBo aWw8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEh1bnQg Jmx0O3BoaWwuaHVudEBvcmFjbGUuY29tPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmbHQ7bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tJmd0OyZndDs6 PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhlIGRyYWZ0IGlzIHZlcnkgY2xlYXIuPGJyPiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgUGhpbDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBPbiBKdWwgMjMsIDIwMTQsIGF0IDA6NDYsIE5hdDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU2FraW11cmEgJmx0O3Nha2ltdXJhQGdtYWlsLmNv bTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O21h aWx0bzpzYWtpbXVyYUBnbWFpbC5jb20mZ3Q7Jmd0OyB3cm90ZTo8YnI+Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGUgbmV3IGdyYW50IHR5cGUgdGhhdCBJIHdhczxi cj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgdGFsa2luZyBhYm91dCB3YXM8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAiYXV0aG9yaXphdGlvbl9jb2RlX2J1dF9kb19ub3RfcmV0dXJu X2FjY2Vzc19ub3JfcmVmcmVzaF90b2tlbiIsPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzbyB0byBzcGVhay48 YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJdCBkb2VzIG5vdCBy ZXR1cm4gYW55dGhpbmc8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHBlciBzZSwgYnV0IGFuIGV4dGVuc2lvbiBj YW48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRlZmluZSBzb21ldGhpbmcgb24gdG9wIG9mIGl0Ljxicj4mZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBUaGVuLCBPSURDIGNhbiBkZWZpbmUgYTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYmluZGluZyB0 byBpdCBzbyB0aGF0IHRoZTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYmluZGluZyBvbmx5IHJldHVybnMgSUQg VG9rZW4uPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhpcyBi aW5kaW5nIHdvcmsgc2hvdWxkIGJlPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkb25lIGluIE9JREYuIFNob3Vs ZCB0aGVyZSBiZTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc3VjaCBhIGdyYW50IHR5cGUsPGJyPiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaXQgd2lsbCBiZSBhbiBleHRyZW1lbHkg c2hvcnQ8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNwZWMuPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxi cj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEF0IHRoZSBzYW1lIHRp bWUsIGlmIGFueSBvdGhlcjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc3BlY2lmaWNhdGlvbiB3YW50ZWQgdG8g ZGVmaW5lPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgb3RoZXIg dHlwZSBvZiB0b2tlbnMgYW5kIGhhdmU8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGl0IHJldHVybmVkIGZyb20g dGhlIHRva2VuPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBlbmRwb2ludCw8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpdCBjYW4gYWxzbyB1c2UgdGhpcyBncmFudCB0eXBlLjxi cj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJy PiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBJZiB3aGF0IHlvdSB3YW50IGlzIHRvIGRlZmluZTxicj4mZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgYSBuZXcgZ3JhbnQgdHlwZSB0aGF0IHJldHVybnM8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IElEIFRva2Vu IG9ubHksPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhlbiwg SSBhbSB3aXRoIEp1c3Rpbi4gU2luY2U8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICJvdGhlciByZXNwb25zZSB0 aGFuIElEIFRva2VuIjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaXMgb25seTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZW9yZXRpY2FsLCB0aGlzIGlzIGEgbW9yZTxicj4m Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgcGxhdXNpYmxlIHdheSBmb3J3YXJkLCBJIHN1cHBvc2UuPGJyPiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IE5hdDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAyMDE0LTA3LTIyIDE0OjMwIEdNVC0wNDowMDxicj4mZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgSnVzdGluIFJpY2hlciAmbHQ7anJpY2hlckBtaXQuZWR1PGJyPiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmbHQ7bWFpbHRvOmpyaWNoZXJAbWl0LmVkdSZndDsmZ3Q7Ojxicj4mZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNvIHRoZSBkcmFmdCB3b3VsZCBsaXRlcmFsbHk8YnI+ Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHR1cm4gaW50bzo8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAiVGhlIGE0YyByZXNwb25zZSB0eXBlIGFuZDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZ3Jh bnQgdHlwZSByZXR1cm4gYW4gaWRfdG9rZW48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGZyb20gdGhlIHRva2Vu IGVuZHBvaW50IHdpdGg8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG5vIGFjY2VzcyB0b2tlbi4gQWxsPGJyPiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBwYXJhbWV0ZXJzIGFuZCB2YWx1ZXMgYXJlPGJyPiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkZWZp bmVkIGluIE9JREMuIjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IFNlZW1zIGxpa2UgdGhlIHBlcmZlY3QgbWluaTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZXh0ZW5zaW9uIGRy YWZ0IGZvciBPSURGIHRvIGRvLjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IC0tSnVzdGluPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgL3NlbnQgZnJvbSBteSBwaG9uZS88YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgT24gSnVsIDIyLCAyMDE0IDEw OjI5IEFNLCBOYXQ8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNha2ltdXJhICZsdDtzYWtpbXVyYUBnbWFpbC5j b208YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDttYWlsdG86c2FraW11cmFAZ21haWwuY29tJmd0OyZndDs8 YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHdyb3RlOjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0Ozxicj4mZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJmd0OyBXaGF0IGFib3V0IGp1c3QgZGVmaW5pbmcgYTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbmV3IGdy YW50IHR5cGUgaW4gdGhpcyBXRz88YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8YnI+Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgMjAxNC0wNy0yMiAxMjo1NiBHTVQtMDQ6MDA8YnI+ Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IFBoaWwgSHVudDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O3BoaWwuaHVudEBvcmFj bGUuY29tPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tJmd0 OyZndDs6PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsg VGhhdCB3b3VsZCBiZSBuaWNlLiBIb3dldmVyPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBvaWRjIHN0aWxsIG5l ZWRzIHRoZSBuZXcgZ3JhbnQ8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHR5cGUgaW4gb3JkZXIgdG8gaW1wbGVt ZW50IHRoZTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc2FtZSBmbG93Ljxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZn dDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7IFBoaWw8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7 PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyBPbiBKdWwgMjIsIDIwMTQsIGF0IDExOjM1LDxicj4m Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgTmF0IFNha2ltdXJhPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7c2FraW11cmFAZ21h aWwuY29tPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7bWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbSZndDsm Z3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB3cm90ZTo8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7PGJyPiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsgKzEgdG8gSnVzdGluLjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0 OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZn dDsmZ3Q7Jmd0OyAyMDE0LTA3LTIyIDk6NTQgR01ULTA0OjAwPGJyPiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSaWNo ZXIsIEp1c3RpbiBQLjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O2pyaWNoZXJAbWl0cmUub3JnPGJyPiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmbHQ7bWFpbHRvOmpyaWNoZXJAbWl0cmUub3JnJmd0OyZndDs6PGJyPiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7 IEVycm9ycyBsaWtlIHRoZXNlIG1ha2UgaXQ8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNsZWFyIHRvIG1lIHRo YXQgaXQgd291bGQgbWFrZTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbXVjaCBtb3JlIHNlbnNlIHRvIGRldmVs b3A8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoaXMgZG9jdW1lbnQgaW4gdGhlIE9wZW5JRDxicj4mZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgRm91bmRhdGlvbi4gSXQgc2hvdWxkIGJlPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzb21ldGhpbmcg dGhhdCBkaXJlY3RseTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcmVmZXJlbmNlcyBPcGVuSUQgQ29ubmVjdCBD b3JlPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBmb3IgYWxsIG9mIHRoZXNlIHRlcm1zIGluc3RlYWQ8YnI+Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IG9mIHJlZGVmaW5pbmcgdGhlbS4gSXQncyBkb2luZzxicj4mZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg YXV0aGVudGljYXRpb24sIHdoaWNoIGlzPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBmdW5kYW1lbnRhbGx5IHdo YXQgT3BlbklEPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBDb25uZWN0IGRvZXMgb24gdG9wIG9mIE9BdXRoLDxi cj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgYW5kIEkgZG9uJ3Qgc2VlIGEgZ29vZDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXJn dW1lbnQgZm9yIGRvaW5nIHRoaXMgd29yazxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW4gdGhpcyB3b3JraW5n IGdyb3VwLjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyAtLSBKdXN0aW48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7 Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsgT24gSnVsIDIyLCAyMDE0 LCBhdCA0OjMwPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBTSwgVGhvbWFzIEJyb3llcjxicj4mZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJmx0O3QuYnJveWVyQGdtYWlsLmNvbTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O21haWx0bzp0LmJy b3llckBnbWFpbC5jb20mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgd3JvdGU6PGJyPiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBP biBNb24sIEp1bCAyMSwgMjAxNCBhdDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMTE6NTIgUE0sIE1pa2UgSm9u ZXM8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDtNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208YnI+Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZsdDttYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tJmd0OyZndDs8 YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHdyb3RlOjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhhbmtzIGZv ciB5b3VyIHJldmlldyw8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRob21hcy4mbmJzcDsgVGhlICJwcm9tcHQ9 Y29uc2VudCI8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRlZmluaXRpb24gYmVpbmcgbWlzc2luZyBpcyBhbjxi cj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgZWRpdG9yaWFsIGVycm9yLiZuYnNwOyBJdCBzaG91bGQgYmU6PGJyPiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgY29uc2VudDxicj4m Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhlIEF1dGhvcml6YXRpb248YnI+Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNl cnZlciBTSE9VTEQgcHJvbXB0IHRoZTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRW5kLVVzZXIgZm9yIGNvbnNl bnQgYmVmb3JlPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyByZXR1cm5pbmcgaW5mb3JtYXRpb24gdG8gdGhlPGJy PiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBDbGllbnQuIElmIGl0IGNhbm5vdCBvYnRhaW48YnI+Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGNvbnNlbnQsIGl0IE1VU1QgcmV0dXJuIGFuPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBlcnJvciwgdHlwaWNh bGx5IGNvbnNlbnRfcmVxdWlyZWQuPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgSSdsbCBwbGFuIHRvIGFkZCBpdCBpbjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhl IG5leHQgZHJhZnQuPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IEl0IGxvb2tzIGxpa2UgdGhlPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjb25zZW50X3JlcXVp cmVkIGVycm9yIG5lZWRzPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0byBiZSBkZWZpbmVkIHRvbywgYW5kIHlv dTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgbWlnaHQgaGF2ZSBmb3Jnb3R0ZW4gdG8gYWxzbzxicj4mZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgaW1wb3J0PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhY2NvdW50X3NlbGVjdGlvbl9yZXF1aXJlZDxi cj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgZnJvbSBPcGVuSUQgQ29ubmVjdC48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8 YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgSSBhZ3JlZSB0aGF0IHRoZXJlJ3Mgbm88YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRpZmZlcmVu Y2UgYmV0d2VlbiBhIHJlc3BvbnNlPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB3aXRoIG11bHRpcGxlICJhbXIi IHZhbHVlczxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhhdCBpbmNsdWRlcyAibWZhIiBhbmQgb25lPGJyPiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB0aGF0IGRvZXNuJ3QuJm5ic3A7IFVubGVzcyBhIGNsZWFyPGJyPiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB1c2UgY2FzZSBmb3Igd2h5ICJtZmEiIGlzPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBuZWVkZWQgY2Fu IGJlIGlkZW50aWZpZWQsIHdlPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjYW4gZGVsZXRlIGl0IGluIHRoZSBu ZXh0IGRyYWZ0Ljxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBUaGFua3MuPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4m Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgSG93IGFib3V0ICJwd2QiIHRoZW4/IEk8 YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IGZ1bGx5IHVuZGVyc3RhbmQgdGhhdCBJIHNob3VsZDxicj4mZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgcmV0dXJuICJwd2QiIGlmIHRoZSB1c2VyPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhdXRoZW50aWNh dGVkIHVzaW5nIGE8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHBhc3N3b3JkLCBidXQgd2hhdCAidGhlPGJyPiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBzZXJ2aWNlIGlmIGEgY2xpZW50IHNlY3JldCBpczxicj4mZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg dXNlZCIgbWVhbnMgaW4gdGhlIGRlZmluaXRpb248YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGZvciB0aGUgInB3 ZCIgdmFsdWU/PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgKE5vdGE6IEkga25vdyB5b3UncmUgYXQ8YnI+Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IElFVEYtOTAsIEknbSByZWFkeSB0byB3YWl0PGJyPiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAndGls IHlvdSBjb21lIGJhY2sgOy0pICk8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAtLTxicj4mZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhvbWFzIEJyb3llcjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsgL3TJlC5tYS5iyoF3YS5qZS88YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDtodHRw Oi8veG4tLW5uYS5tYS54bi0tYndhLXh4Yi5qZS8mZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IE9BdXRoIG1haWxpbmcgbGlzdDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsg T0F1dGhAaWV0Zi5vcmc8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDttYWlsdG86T0F1dGhAaWV0Zi5vcmcm Z3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxicj4mZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4m Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7 Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsgT0F1dGggbWFpbGlu ZyBsaXN0PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7IE9BdXRoQGlldGYub3JnPGJy PiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmbHQ7bWFpbHRvOk9BdXRoQGlldGYub3JnJmd0Ozxicj4mZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vYXV0aDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0Ozxi cj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDs8 YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7 IC0tPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsgTmF0IFNha2ltdXJhICg9bmF0KTxicj4m Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7IENoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbjxicj4m Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7IGh0dHA6Ly9uYXQuc2FraW11cmEub3JnLzxicj4mZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJmd0OyZndDsmZ3Q7IEBfbmF0X2VuPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZn dDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZn dDsmZ3Q7Jmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0 OyBPQXV0aEBpZXRmLm9yZzxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O21haWx0bzpPQXV0aEBpZXRmLm9y ZyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0 Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0Ozxicj4mZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAtLTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBOYXQg U2FraW11cmEgKD1uYXQpPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IENoYWlybWFuLCBPcGVuSUQgRm91 bmRhdGlvbjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBodHRwOi8vbmF0LnNha2ltdXJhLm9yZy88YnI+ Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZndDsgQF9uYXRfZW48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJy PiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+ Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLTxicj4mZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgTmF0IFNha2ltdXJhICg9bmF0KTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IENoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaHR0 cDovL25hdC5zYWtpbXVyYS5vcmcvPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBAX25hdF9lbjxicj4mZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tPGJyPiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBOYXQgU2FraW11cmEgKD1uYXQpPGJyPiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgQ2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uPGJyPiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBodHRwOi8vbmF0LnNha2ltdXJhLm9y Zy88YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEBfbmF0 X2VuPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBPQXV0aEBpZXRmLm9yZyAmbHQ7bWFpbHRvOk9BdXRoQGlldGYub3Jn Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxicj4mZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaG9tYXMgQnJveWVyPGJyPiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAvdMmULm1hLmLKgXdhLmplLzxicj4mZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O2h0dHA6Ly94bi0t bm5hLm1hLnhuLS1id2EteHhiLmplLyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJy PiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4mZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBPQXV0aEBpZXRmLm9yZyAm bHQ7bWFpbHRvOk9BdXRoQGlldGYub3JnJmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vYXV0aDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0t PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaG9tYXMg QnJveWVyPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAv dMmULm1hLmLKgXdhLmplLzxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJmx0O2h0dHA6Ly94bi0tbm5hLm1hLnhuLS1id2EteHhiLmplLyZndDs8YnI+Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4mZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgT0F1dGhAaWV0Zi5vcmcgJmx0O21h aWx0bzpPQXV0aEBpZXRmLm9yZyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1 dGg8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLTxicj4m Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTmF0IFNha2ltdXJh ICg9bmF0KTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IENoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbjxi cj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaHR0cDovL25h dC5zYWtpbXVyYS5vcmcvPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBAX25hdF9lbjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IE9BdXRoQGlldGYub3JnJm5ic3A7ICZsdDttYWlsdG86T0F1dGhAaWV0Zi5vcmcmZ3Q7PGJyPiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0 aDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg T0F1dGhAaWV0Zi5vcmcgJmx0O21haWx0bzpPQXV0aEBpZXRmLm9yZyZndDs8YnI+Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8 YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxi cj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9BdXRoIG1h aWxpbmcgbGlzdDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgT0F1dGhAaWV0Zi5vcmcgJmx0O21haWx0bzpPQXV0aEBpZXRmLm9yZyZndDs8 YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8YnI+Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tPGJyPiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBOYXQgU2FraW11cmEgKD1uYXQpPGJyPiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBDaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb248YnI+ Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGh0dHA6Ly9uYXQuc2FraW11cmEub3JnLzxi cj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQF9uYXRfZW48YnI+Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4mZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBPQXV0aEBpZXRmLm9yZyAmbHQ7bWFpbHRvOk9BdXRoQGlldGYub3JnJmd0Ozxi cj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9vYXV0aDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS08YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE5hdCBTYWtpbXVyYSAoPW5hdCk8YnI+Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IENoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbjxi cj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaHR0cDovL25hdC5zYWtp bXVyYS5vcmcvPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBAX25h dF9lbjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9BdXRoQGlldGYub3Jn ICZsdDttYWlsdG86T0F1dGhAaWV0Zi5vcmcmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGJyPiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IE9BdXRoIG1haWxpbmcgbGlzdDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBPQXV0aEBpZXRmLm9yZyAmbHQ7bWFp bHRvOk9BdXRoQGlldGYub3JnJmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGJyPiZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0Ozxicj4m Z3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4mZ3Q7Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBPQXV0aCBt YWlsaW5nIGxpc3Q8YnI+Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgT0F1dGhAaWV0Zi5vcmcgJmx0O21haWx0bzpPQXV0aEBpZXRmLm9yZyZn dDs8YnI+Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxicj4mZ3Q7 Jmd0Ozxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAtLTxicj4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBOYXQgU2FraW11cmEgKD1uYXQpPGJyPiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IENoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbjxicj4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBodHRwOi8vbmF0LnNha2ltdXJhLm9yZy88YnI+Jmd0OyZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgQF9uYXRfZW48YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgT0F1dGggbWFpbGluZyBsaXN0 PGJyPiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9BdXRoQGlldGYub3JnICZsdDtt YWlsdG86T0F1dGhAaWV0Zi5vcmcmZ3Q7PGJyPiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8YnI+Jmd0OyZn dDs8YnI+Jmd0OyZndDs8YnI+Jmd0Ozxicj4mZ3Q7PGJyPiZndDs8YnI+Jmd0OyBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4mZ3Q7IE9BdXRoIG1haWxp bmcgbGlzdDxicj4mZ3Q7IE9BdXRoQGlldGYub3JnPGJyPiZndDsgaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxicj4mZ3Q7PGJyPjxicj48YnI+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+T0F1dGggbWFpbGluZyBsaXN0 PGJyPk9BdXRoQGlldGYub3JnPGJyPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vb2F1dGg8YnI+PC9ib2R5PjwvaHRtbD4= ----_com.android.email_447835122614160-- From nobody Mon Oct 13 06:01:07 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EB771A8A6D for ; Mon, 13 Oct 2014 06:01:04 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHuG4GeW3VHx for ; Mon, 13 Oct 2014 06:00:58 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08A1C1A033E for ; Mon, 13 Oct 2014 06:00:57 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id m15so8473050wgh.4 for ; Mon, 13 Oct 2014 06:00:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=1Gd4XgQi2tyKgaAfUY+OS+QarqSLb3pnJbuVQxOAJKE=; b=yTHv4GEIxgEk6Z1d4kNYq8ymW6lxQKXk/kgBCpucO5iXG/QpKcLXukMuPBFuSw6TYO 9xF76oHRSRrSnIVEdVyqT/60X/O4SV3vmNJdvX5PZOBgz1SNAPlZAl7S19RO+++YqLvB FWVZiweILre4Gv0Uywjz4Y67e0Nmn6opzgxGnNHHBqwz/v+/j5B+y5RYGwIDvoCn6euE e0bjODPyZ9WayMIjGYypOaU4u9ioqo5jwfoTaCz8XHbFiA8LX58R2vd+ICcAybp3oXvd M67RK6oda3uoF4P9uhCZ5LoyoEk5xJbhE1X+k/u+6jN1jEQGvB8y5Dvrpbc5xmTnOnMA PG/g== X-Received: by 10.194.142.179 with SMTP id rx19mr2326001wjb.114.1413205256045; Mon, 13 Oct 2014 06:00:56 -0700 (PDT) Received: from [10.36.226.2] ([80.169.137.63]) by mx.google.com with ESMTPSA id h9sm16590373wjf.20.2014.10.13.06.00.54 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Oct 2014 06:00:55 -0700 (PDT) Message-ID: <543BCD06.6070705@gmail.com> Date: Mon, 13 Oct 2014 14:00:54 +0100 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Justin Richer , oauth@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/t8QhzZTafvAK7Fz6E2AD363mds0 Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 13:01:04 -0000 Hi Justin, On 13/10/14 12:53, Justin Richer wrote: > You are correct in that OAuth 2 and OpenID Connect are not the same > thing, but your user is correct that OIDC adds a few pieces on top of > OAuth to add authentication capabilities. OIDC was designed very > explicitly to be compatible with vanilla OAuth, partially do that people > would be able to deploy it on top of existing OAuth infrastructure and > code. But the very fact that OIDC adds a few things on top of OAuth to > give more functionality should be sufficient evidence that they're not > equivalent. > > It's more proper to say that OpenID Connect is an extension and > application of OAuth. One that provides an authentication and identity API. > I agree and this is more or less how I answered. Though the 'borders' can be blurred, one can claim that if a user actually logs on into a confidential OAuth2 client web application which redirects this user to AS requesting a code with some scopes such as "a b" then when it uses "a b openid profile" it is basically does a pure OAuth2 code flow where the client requests 'a b' plus also a scope allowing it later to query the identity system on behalf of a user. I like the "The extension and application of OAuth2" characteristic of OIDC. IMHO it's becoming more obvious if OIDC is used to support SSO into non-OAuth2 servers, when it is the case then there's no 'feeling' that OIDC is just a case of the confidential client adding the extra scopes and getting the extra (authentication) info back. A standalone OIDC RP protecting such non OAuth2 servers is very much about the authentication/identity. I also thought that having some OID profile (as opposed updating OAuth2 to support no access tokens) where no access but only id token was returned (as suggested in this thread) would probably make sense too. > The way I like to explain it (which I stole from someone else) is that > OAuth is like chocolate and authentication is like fudge. They are not > the same thing. You can make chocolate into fudge out you can make it > into something else or you can just have it on its own. You can make > fudge with chocolate or you can make it with peanut butter or you can > make it with potatoes if you want to, but it needs a couple ingredients > and a very common one is chocolate. OpenID Connect is a recipe for > chocolate fudge that a lot of people like. And it makes my fudge > compatible with your fudge, which is where the metaphor breaks down. :-) > Thanks for sharing this colourful explanation :-). Perhaps I should borrow it :-), Cheers, Sergey > > -- Justin > > / Sent from my phone / > > > -------- Original message -------- > From: Sergey Beryozkin > Date:10/13/2014 6:33 AM (GMT-05:00) > To: oauth@ietf.org > Cc: > Subject: Re: [OAUTH-WG] New Version Notification for > draft-hunt-oauth-v2-user-a4c-05.txt > > Hi > > We've had a user asserting that "OAuth2 == OpenidConnect", referring to > the fact that the 'only' thing OIC adds on top of the authorization code > flow is the client specifying few extra scopes like 'openid' and > 'profile' and the authorization service returning an extra property, the > id_token which can be sufficient in order to get the authenticated > user's info. > > My understanding "OAuth2 != OpenidConnect", the latter utilizes the > former and is an authentication mechanism which is not what OAuth2 is > (may be except for the client credentials). But I don't feel like it is > a convincing enough argument. > > I thought this thread was relevant, sorry if not, would have no problems > starting a new one. > > Basically, I wonder what is the proper line of argument for a position > such as "OAuth2 != OpenidConnect" and also what was the action to the > list of options suggested by John below. Is having an OID profile where > no access token is returned would be the cleanest action as far as > breaking the ambiguity/confusion is concerned ? > > Cheers, Sergey > > On 24/07/14 15:25, John Bradley wrote: > > I am not against discussion in the WG. > > > > I happen to agree with Phil's fundamental premise that some developers > > are using OAuth in a insecure way to do authentication. > > > > That raises the question of how to best educate them, and or address > > technical barriers. > > > > It is on the second point that people's opinions seem to divide. > > > > Some people thing that if we have a OAuth flow that eliminates the > > access token (primarily to avoid asking for consent as I understand it) > > and just return a id_token from the token endpoint that can be done in a > > spec short enough to het people to read. The subtext of this is that > > the Connect specification is too large that it scare people, and they > > don't find the spec in the first place because it is not a RFC. > > > > An other common possession is that if you don't want to prompt the user > > for consent then don't ask for scopes. Twisting the OAuth spec to not > > return an access token is not OAuth, yes you could use a different > > endpoint rather than the token endpoint, but that is not OAuth. > > Connect was careful not to break the OAuth spec. As long as you are > > willing to take a access token with no scopes (the client needs to > > understand that there are no attributes one way or another anyway or it > > will break) then you don't need to change OAuth. You can publish a > > profile of connect that satisfies the use case. > > > > I think Mike has largely done that but it might be better being less > > stingy on references back to the larger spec. > > > > The questions are do we modify OAuth to not return an access token, and > > if so how, and if we do is it still OAuth. > > > > The other largely separable question is do we create confusion in the > > market and slow the the adoption of identity federation on top of OAuth, > > or find a way to make this look like a positive alignment of interests > > around a subset of Connect. > > > > There are a number of options. > > 1: We can do a profile in the OIDF and publish it as a IETF document. > > Perhaps the cleanest from an IPR point of view.However > > 2:We can do a profile in the OAuth WG referencing connect. > > 3:We can do a AD sponsored profile that is not in the OAuth WG. > > 4:We can do a small spec in OAuth to add response_type to the token > > endpoint. in combination with 1, 2, or 3 > > > > I agree that stoping developers doing insecure things needs to be > > addressed somehow. > > I am not personally convinced that Oauth without access tokens is > sensible. > > > > Looking forward to the meeting:) > > > > John B. > > On Jul 24, 2014, at 6:52 AM, Brian Campbell > > wrote: > > > >> I'd note that the reaction at the conference to Ian's statement was > >> overwhelmingly positive. There was a wide range of industry people > >> here - implementers, practitioners, deployers, strategists, etc. - and > >> it seems pretty clear that the "rough consensus" of the industry at > >> large is that a4c is not wanted or needed. > >> > >> > >> On Thu, Jul 24, 2014 at 5:29 AM, Nat Sakimura >> > wrote: > >> > >> And here is a quote from Ian's blog. > >> > >> And although the authentication wheel is round, that doesn’t > >> mean it isn’t without its lumps. First, we do see some > >> reinventing the wheel just to reinvent the wheel. OAuth A4C is > >> simply not a fruitful activity and should be put down. > >> > >> (Source) > >> > http://www.tuesdaynight.org/2014/07/23/do-we-have-a-round-wheel-yet-musings-on-identity-standards-part-1.html > >> > >> > >> > >> 2014-07-23 16:53 GMT-04:00 John Bradley >> >: > >> > >> I thought I did post this to the list. > >> > >> I guess I hit the wrong reply on my phone. > >> John B. > >> Sent from my iPhone > >> > >> On Jul 23, 2014, at 4:50 PM, torsten@lodderstedt.net > >> wrote: > >> > >>> we are two, at least :-) > >>> > >>> Why didn't you post this on the list? > >>> > >>> When will be be arriving? > >>> > >>> Am 23.07.2014 16:39, schrieb John Bradley: > >>> > >>>> Ian Glazer mentioned this in his keynote at CIS yesterday. > >>>> His advice was please stop, we are creating confusion and > >>>> uncertainty. > >>>> We are becoming our own wort enemy. ( my view though Ian may > >>>> share it) > >>>> Returning just an id_ token from the token endpoint has > >>>> little real value. > >>>> Something really useful to do would be sorting out > >>>> channel_id so we can do PoP for id tokens to make them and > >>>> other cookies secure in the front channel. I think that is > >>>> a better use of time. > >>>> I may be in the minority opinion on that, it won't be the > >>>> first time. > >>>> > >>>> > >>>> John B. > >>>> Sent from my iPhone > >>>> > >>>> On Jul 23, 2014, at 4:04 PM, Torsten Lodderstedt > >>>> > > >>>> wrote: > >>>> > >>>>> You are right from a theoretical perspective. Practically > >>>>> this was caused by editorial decisions during the creation > >>>>> of the RFC. As far as I remember, there was a definition of > >>>>> the (one) token endpoint response in early versions. No one > >>>>> every considered to NOT respond with an access token from > >>>>> the token endpoint. So one might call it an implicit > >>>>> assumption. > >>>>> I'm worried that people get totally confused if an > >>>>> exception is introduced now given the broad adoption of > >>>>> OAuth based on this assumption. > >>>>> regards, > >>>>> Torsten. > >>>>> > >>>>> Am 23.07.2014 um 15:41 schrieb Thomas Broyer > >>>>> >: > >>>>> > >>>>>> Is it said anywhere that ALL grant types MUST use Section > >>>>>> 5.1 responses? Each grant type references Section 5.1, and > >>>>>> "access token request" is only defined in the context of > >>>>>> the defined grant types. Section 2.2 doesn't talk about > >>>>>> the request or response format. > >>>>>> > >>>>>> Le 23 juil. 2014 21:32, "Nat Sakimura" >>>>>> > a écrit : > >>>>>> > >>>>>> Is it? Apart from the implicit grant that does not use > >>>>>> token endpoint, all other grant references section 5.1 > >>>>>> for the response, i.e., all shares the same response. > >>>>>> > >>>>>> > >>>>>> 2014-07-23 15:18 GMT-04:00 Thomas Broyer > >>>>>> >: > >>>>>> > >>>>>> I hadn't realized the JSON response that requires > >>>>>> the access_token field is defined per grant_type, > >>>>>> so I'd be OK to "extend the semantics" as in the > >>>>>> current draft. > >>>>>> That was actually my main concern: that the token > >>>>>> endpoint mandates access_token; but its actually > >>>>>> not the case. > >>>>>> > >>>>>> Le 23 juil. 2014 20:46, "Nat Sakimura" > >>>>>> > a > >>>>>> écrit : > >>>>>> > >>>>>> I agree with John that overloading > >>>>>> response_type @ authz endpoint is a bad idea. > >>>>>> It completely changes the semantics of this > >>>>>> parameter. NOTE: what I was proposing was not > >>>>>> this parameter, but a new parameter > >>>>>> response_type @ token endpoint. > >>>>>> I also think overloading grant_type is a bad > >>>>>> idea since it changes its semantics. I quote > >>>>>> the definition here again: > >>>>>> grant > >>>>>> credential representing the resource > >>>>>> owner's authorization > >>>>>> grant_type > >>>>>> type of grant sent to the token endpoint to > >>>>>> obtain the access token > >>>>>> It is not about controlling what is to be > >>>>>> returned from the token endpoint, but the hint > >>>>>> to the token endpoint describing the type of > >>>>>> credential the endpoint has received. It seems > >>>>>> the "control of what is being returned from > >>>>>> token endpoint" is just a side effect. > >>>>>> I am somewhat ambivalent[1] in changing the > >>>>>> semantics of token endpoint, but in as much as > >>>>>> "text is the king" for a spec., we probably > >>>>>> should not change the semantics of it as > >>>>>> Torsten points out. If it is ok to change this > >>>>>> semantics, I believe defining a new parameter > >>>>>> to this endpoint to control the response would > >>>>>> be the best way to go. This is what I have > >>>>>> described previously. > >>>>>> Defining a new endpoint to send code to get ID > >>>>>> Token and forbidding the use of it against > >>>>>> token endpoint would not change the semantics > >>>>>> of any existing parameter or endpoint, which > >>>>>> is good. However, I doubt if it is not worth > >>>>>> doing. What's the point of avoiding access > >>>>>> token scoped to UserInfo endpoint after all? > >>>>>> Defining a new endpoint for just avoiding the > >>>>>> access token for userinfo endpoint seems way > >>>>>> too much the heavy wait way and it breaks > >>>>>> interoperabiliy: it defeats the purpose of > >>>>>> standardization. > >>>>>> I have started feeling that no change is the > >>>>>> best way out. > >>>>>> Nat > >>>>>> [1] If instead of saying "Token endpoint - > >>>>>> used by the client to exchange an > >>>>>> authorization grant for an access token, > >>>>>> typically with client authentication", it were > >>>>>> saying "Token endpoint - used by the client to > >>>>>> exchange an authorization grant for tokens, > >>>>>> typically with client authentication", then it > >>>>>> would have been OK. It is an expansion of the > >>>>>> capability rather than changing the semantics. > >>>>>> > >>>>>> > >>>>>> 2014-07-23 13:39 GMT-04:00 Mike Jones > >>>>>> >>>>>> >: > >>>>>> > >>>>>> You need the alternative response_type > >>>>>> value ("code_for_id_token" in the A4C > >>>>>> draft) to tell the Authorization Server to > >>>>>> return a code to be used with the new > >>>>>> grant type, rather than one to use with > >>>>>> the "authorization_code" grant type (which > >>>>>> is what response_type=code does). > >>>>>> > >>>>>> > >>>>>> *From:*OAuth > >>>>>> [mailto:oauth-bounces@ietf.org > >>>>>> ] *On > >>>>>> Behalf Of *John Bradley > >>>>>> *Sent:* Wednesday, July 23, 2014 10:33 AM > >>>>>> *To:* torsten@lodderstedt.net > >>>>>> > >>>>>> > >>>>>> > >>>>>> *Cc:* oauth@ietf.org > >>>>>> *Subject:* Re: [OAUTH-WG] New Version > >>>>>> Notification for > >>>>>> draft-hunt-oauth-v2-user-a4c-05.txt > >>>>>> > >>>>>> > >>>>>> If we use the token endpoint then a new > >>>>>> grant_type is the best way. > >>>>>> > >>>>>> > >>>>>> It sort of overloads code, but that is > >>>>>> better than messing with response_type for > >>>>>> the authorization endpoint to change the > >>>>>> response from the token_endpoint. That is > >>>>>> in my opinion a champion bad idea. > >>>>>> > >>>>>> > >>>>>> In discussions developing Connect we > >>>>>> decided not to open this can of worms > >>>>>> because no good would come of it. > >>>>>> > >>>>>> > >>>>>> The token_endpoint returns a access token. > >>>>>> Nothing requires scope to be associates > >>>>>> with the token. > >>>>>> > >>>>>> > >>>>>> That is the best solution. No change > >>>>>> required. Better interoperability in my > >>>>>> opinion. > >>>>>> > >>>>>> > >>>>>> Still on my way to TO, getting in later > >>>>>> today. > >>>>>> > >>>>>> > >>>>>> John B. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> Sent from my iPhone > >>>>>> > >>>>>> > >>>>>> On Jul 23, 2014, at 12:15 PM, > >>>>>> torsten@lodderstedt.net > >>>>>> wrote: > >>>>>> > >>>>>> The "response type" of the token > >>>>>> endpoint is controlled by the value of > >>>>>> the parameter "grant_type". So there > >>>>>> is no need to introduce a new parameter. > >>>>>> > >>>>>> wrt to a potential "no_access_token" > >>>>>> grant type. I do not consider this a > >>>>>> good idea as it changes the semantics > >>>>>> of the token endpoint (as already > >>>>>> pointed out by Thomas). This endpoint > >>>>>> ALWAYS responds with an access token > >>>>>> to any grant type. I therefore would > >>>>>> prefer to use another endpoint for the > >>>>>> intended purpose. > >>>>>> > >>>>>> regards, > >>>>>> Torsten. > >>>>>> > >>>>>> > >>>>>> Am 23.07.2014 13:04, schrieb Nat > Sakimura: > >>>>>> > >>>>>> IMHO, changing the semantics of > >>>>>> "response_type" @ authz endpoint > >>>>>> this way is not a good thing. > >>>>>> > >>>>>> > >>>>>> Instead, defining a new parameter > >>>>>> "response_type" @ token endpoint, > >>>>>> as I described in my previous > >>>>>> message, > >>>>>> > >>>>>> probably is better. At least, it > >>>>>> does not change the semantics of > >>>>>> the parameters of RFC6749. > >>>>>> > >>>>>> > >>>>>> Nat > >>>>>> > >>>>>> > >>>>>> 2014-07-23 12:48 GMT-04:00 Thomas > >>>>>> Broyer >>>>>> >: > >>>>>> > >>>>>> No, I mean response_type=none and > >>>>>> response_type=id_token don't > >>>>>> generate a code or access token so > >>>>>> you don't use the Token Endpoint > >>>>>> (which is not the same as the > >>>>>> Authentication Endpoint BTW). > >>>>>> > >>>>>> With > >>>>>> response_type=code_for_id_token, > >>>>>> you get a code and exchange it for > >>>>>> an id_token only, rather than an > >>>>>> access_token, so you're changing > >>>>>> the semantics of the Token Endpoint. > >>>>>> > >>>>>> > >>>>>> I'm not saying it's a bad thing, > >>>>>> just that you can't really compare > >>>>>> none and id_token with > >>>>>> code_for_id_token. > >>>>>> > >>>>>> > >>>>>> On Wed, Jul 23, 2014 at 6:45 PM, > >>>>>> Richer, Justin P. > >>>>>> >>>>>> > wrote: > >>>>>> > >>>>>> It's only "not using the token > >>>>>> endpoint" because the token > >>>>>> endpoint copy-pasted and renamed > >>>>>> the authentication endpoint. > >>>>>> > >>>>>> > >>>>>> -- Justin > >>>>>> > >>>>>> > >>>>>> On Jul 23, 2014, at 9:30 AM, > >>>>>> Thomas Broyer >>>>>> > wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>> Except that these are about not > >>>>>> using the Token Endpoint at all, > >>>>>> whereas the current proposal is > >>>>>> about the Token Endpoint not > >>>>>> returning an access_token field in > >>>>>> the JSON. > >>>>>> > >>>>>> > >>>>>> On Wed, Jul 23, 2014 at 4:26 PM, > >>>>>> Mike Jones > >>>>>> >>>>>> > > > >>>>>> wrote: > >>>>>> > >>>>>> The response_type "none" is > >>>>>> already used in practice, which > >>>>>> returns no access token. It was > >>>>>> accepted by the designated experts > >>>>>> and registered in the IANA OAuth > >>>>>> Authorization Endpoint Response > >>>>>> Types registry at > >>>>>> > http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#endpoint > >>>>>> > . > >>>>>> The registered "id_token" response > >>>>>> type also returns no access token. > >>>>>> > >>>>>> > >>>>>> So I think the question of whether > >>>>>> response types that result in no > >>>>>> access token being returned are > >>>>>> acceptable within OAuth 2.0 is > >>>>>> already settled, as a practical > >>>>>> matter. Lots of OAuth > >>>>>> implementations are already using > >>>>>> such response types. > >>>>>> > >>>>>> > >>>>>> > >>>>>> -- Mike > >>>>>> > >>>>>> > >>>>>> *From:*OAuth > >>>>>> [mailto:oauth-bounces@ietf.org > >>>>>> ] > >>>>>> *On Behalf Of *Phil Hunt > >>>>>> *Sent:* Wednesday, July 23, 2014 > >>>>>> 7:09 AM > >>>>>> *To:* Nat Sakimura > >>>>>> *Cc:* >>>>>> > > >>>>>> *Subject:* Re: [OAUTH-WG] New > >>>>>> Version Notification for > >>>>>> draft-hunt-oauth-v2-user-a4c-05.txt > >>>>>> > >>>>>> > >>>>>> Yes. This is why it has to be > >>>>>> discussed in the IETF. > >>>>>> > >>>>>> > >>>>>> Phil > >>>>>> > >>>>>> > >>>>>> @independentid > >>>>>> > >>>>>> www.independentid.com > >>>>>> > >>>>>> > >>>>>> phil.hunt@oracle.com > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> On Jul 23, 2014, at 9:43 AM, Nat > >>>>>> Sakimura >>>>>> > wrote: > >>>>>> > >>>>>> > >>>>>> Reading back the RFC6749, I am not > >>>>>> sure if there is a good way of > >>>>>> suppressing access token from the > >>>>>> response and still be OAuth. It > >>>>>> will break whole bunch of implicit > >>>>>> definitions like: > >>>>>> > >>>>>> > >>>>>> authorization server > >>>>>> The server issuing access > >>>>>> tokens to the client after > >>>>>> successfully > >>>>>> authenticating the resource > >>>>>> owner and obtaining authorization. > >>>>>> > >>>>>> > >>>>>> After all, OAuth is all about > >>>>>> issuing access tokens. > >>>>>> > >>>>>> > >>>>>> Also, I take back my statement on > >>>>>> the grant type in my previous mail. > >>>>>> > >>>>>> > >>>>>> The definition of grant and > >>>>>> grant_type are respectively: > >>>>>> > >>>>>> > >>>>>> grant > >>>>>> > >>>>>> credential representing the > >>>>>> resource owner's authorization > >>>>>> > >>>>>> > >>>>>> grant_type > >>>>>> > >>>>>> (string representing the) type > >>>>>> of grant sent to the token > >>>>>> endpoint to obtain the access token > >>>>>> > >>>>>> > >>>>>> Thus, the grant sent to the token > >>>>>> endpoint in this case is still > >>>>>> 'code'. > >>>>>> > >>>>>> > >>>>>> Response type on the other hand is > >>>>>> not so well defined in RFC6749, > >>>>>> but it seems it is representing > >>>>>> what is to be returned from the > >>>>>> authorization endpoint. To express > >>>>>> what is to be returned from token > >>>>>> endpoint, perhaps defining a new > >>>>>> parameter to the token endpoint, > >>>>>> which is a parallel to the > >>>>>> response_type to the Authorization > >>>>>> Endpoint seems to be a more > >>>>>> symmetric way, though I am not > >>>>>> sure at all if that is going to be > >>>>>> OAuth any more. One straw-man is > >>>>>> to define a new parameter called > >>>>>> response_type to the token > >>>>>> endpoint such as: > >>>>>> > >>>>>> > >>>>>> response_type > >>>>>> > >>>>>> OPTIONAL. A string > >>>>>> representing what is to be > >>>>>> returned from the token endpoint. > >>>>>> > >>>>>> > >>>>>> Then define the behavior of the > >>>>>> endpoint according to the values > >>>>>> as the parallel to the > >>>>>> multi-response type spec. > >>>>>> > >>>>>> > http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html > >>>>>> > >>>>>> > >>>>>> Nat > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> 2014-07-23 7:21 GMT-04:00 Phil > >>>>>> Hunt >>>>>> >: > >>>>>> > >>>>>> The draft is very clear. > >>>>>> > >>>>>> Phil > >>>>>> > >>>>>> > >>>>>> On Jul 23, 2014, at 0:46, Nat > >>>>>> Sakimura >>>>>> > wrote: > >>>>>> > >>>>>> The new grant type that I was > >>>>>> talking about was > >>>>>> > >>>>>> > "authorization_code_but_do_not_return_access_nor_refresh_token", > >>>>>> so to speak. > >>>>>> > >>>>>> It does not return anything > >>>>>> per se, but an extension can > >>>>>> define something on top of it. > >>>>>> > >>>>>> > >>>>>> Then, OIDC can define a > >>>>>> binding to it so that the > >>>>>> binding only returns ID Token. > >>>>>> > >>>>>> This binding work should be > >>>>>> done in OIDF. Should there be > >>>>>> such a grant type, > >>>>>> > >>>>>> it will be an extremely short > >>>>>> spec. > >>>>>> > >>>>>> > >>>>>> At the same time, if any other > >>>>>> specification wanted to define > >>>>>> > >>>>>> other type of tokens and have > >>>>>> it returned from the token > >>>>>> endpoint, > >>>>>> > >>>>>> it can also use this grant type. > >>>>>> > >>>>>> > >>>>>> If what you want is to define > >>>>>> a new grant type that returns > >>>>>> ID Token only, > >>>>>> > >>>>>> then, I am with Justin. Since > >>>>>> "other response than ID Token" > >>>>>> is only > >>>>>> > >>>>>> theoretical, this is a more > >>>>>> plausible way forward, I > suppose. > >>>>>> > >>>>>> > >>>>>> Nat > >>>>>> > >>>>>> > >>>>>> 2014-07-22 14:30 GMT-04:00 > >>>>>> Justin Richer >>>>>> >: > >>>>>> > >>>>>> So the draft would literally > >>>>>> turn into: > >>>>>> > >>>>>> "The a4c response type and > >>>>>> grant type return an id_token > >>>>>> from the token endpoint with > >>>>>> no access token. All > >>>>>> parameters and values are > >>>>>> defined in OIDC." > >>>>>> > >>>>>> Seems like the perfect mini > >>>>>> extension draft for OIDF to do. > >>>>>> > >>>>>> --Justin > >>>>>> > >>>>>> /sent from my phone/ > >>>>>> > >>>>>> > >>>>>> On Jul 22, 2014 10:29 AM, Nat > >>>>>> Sakimura >>>>>> > > >>>>>> wrote: > >>>>>> > > >>>>>> > What about just defining a > >>>>>> new grant type in this WG? > >>>>>> > > >>>>>> > > >>>>>> > 2014-07-22 12:56 GMT-04:00 > >>>>>> Phil Hunt > >>>>>> >>>>>> >: > >>>>>> >> > >>>>>> >> That would be nice. However > >>>>>> oidc still needs the new grant > >>>>>> type in order to implement the > >>>>>> same flow. > >>>>>> >> > >>>>>> >> Phil > >>>>>> >> > >>>>>> >> On Jul 22, 2014, at 11:35, > >>>>>> Nat Sakimura > >>>>>> >>>>>> > > >>>>>> wrote: > >>>>>> >> > >>>>>> >>> +1 to Justin. > >>>>>> >>> > >>>>>> >>> > >>>>>> >>> 2014-07-22 9:54 GMT-04:00 > >>>>>> Richer, Justin P. > >>>>>> >>>>>> >: > >>>>>> >>>> > >>>>>> >>>> Errors like these make it > >>>>>> clear to me that it would make > >>>>>> much more sense to develop > >>>>>> this document in the OpenID > >>>>>> Foundation. It should be > >>>>>> something that directly > >>>>>> references OpenID Connect Core > >>>>>> for all of these terms instead > >>>>>> of redefining them. It's doing > >>>>>> authentication, which is > >>>>>> fundamentally what OpenID > >>>>>> Connect does on top of OAuth, > >>>>>> and I don't see a good > >>>>>> argument for doing this work > >>>>>> in this working group. > >>>>>> >>>> > >>>>>> >>>> -- Justin > >>>>>> >>>> > >>>>>> >>>> On Jul 22, 2014, at 4:30 > >>>>>> AM, Thomas Broyer > >>>>>> >>>>>> > > >>>>>> wrote: > >>>>>> >>>> > >>>>>> >>>>> > >>>>>> >>>>> > >>>>>> >>>>> > >>>>>> >>>>> On Mon, Jul 21, 2014 at > >>>>>> 11:52 PM, Mike Jones > >>>>>> >>>>>> > > > >>>>>> wrote: > >>>>>> >>>>>> > >>>>>> >>>>>> Thanks for your review, > >>>>>> Thomas. The "prompt=consent" > >>>>>> definition being missing is an > >>>>>> editorial error. It should be: > >>>>>> >>>>>> > >>>>>> >>>>>> > >>>>>> >>>>>> > >>>>>> >>>>>> consent > >>>>>> >>>>>> > >>>>>> >>>>>> The Authorization > >>>>>> Server SHOULD prompt the > >>>>>> End-User for consent before > >>>>>> returning information to the > >>>>>> Client. If it cannot obtain > >>>>>> consent, it MUST return an > >>>>>> error, typically > consent_required. > >>>>>> >>>>>> > >>>>>> >>>>>> > >>>>>> >>>>>> > >>>>>> >>>>>> I'll plan to add it in > >>>>>> the next draft. > >>>>>> >>>>> > >>>>>> >>>>> > >>>>>> >>>>> It looks like the > >>>>>> consent_required error needs > >>>>>> to be defined too, and you > >>>>>> might have forgotten to also > >>>>>> import > >>>>>> account_selection_required > >>>>>> from OpenID Connect. > >>>>>> >>>>> > >>>>>> >>>>>> > >>>>>> >>>>>> > >>>>>> >>>>>> > >>>>>> >>>>>> I agree that there's no > >>>>>> difference between a response > >>>>>> with multiple "amr" values > >>>>>> that includes "mfa" and one > >>>>>> that doesn't. Unless a clear > >>>>>> use case for why "mfa" is > >>>>>> needed can be identified, we > >>>>>> can delete it in the next draft. > >>>>>> >>>>> > >>>>>> >>>>> > >>>>>> >>>>> Thanks. > >>>>>> >>>>> > >>>>>> >>>>> How about "pwd" then? I > >>>>>> fully understand that I should > >>>>>> return "pwd" if the user > >>>>>> authenticated using a > >>>>>> password, but what "the > >>>>>> service if a client secret is > >>>>>> used" means in the definition > >>>>>> for the "pwd" value? > >>>>>> >>>>> > >>>>>> >>>>> (Nota: I know you're at > >>>>>> IETF-90, I'm ready to wait > >>>>>> 'til you come back ;-) ) > >>>>>> >>>>> > >>>>>> >>>>> -- > >>>>>> >>>>> Thomas Broyer > >>>>>> >>>>> /tɔ.ma.bʁwa.je/ > >>>>>> > > >>>>>> >>>>> > >>>>>> > _______________________________________________ > >>>>>> >>>>> 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 > >>>>>> >>>> > >>>>>> >>> > >>>>>> >>> > >>>>>> >>> > >>>>>> >>> -- > >>>>>> >>> Nat Sakimura (=nat) > >>>>>> >>> Chairman, OpenID Foundation > >>>>>> >>> http://nat.sakimura.org/ > >>>>>> >>> @_nat_en > >>>>>> >>> > >>>>>> >>> > >>>>>> > _______________________________________________ > >>>>>> >>> OAuth mailing list > >>>>>> >>> OAuth@ietf.org > >>>>>> > >>>>>> >>> > >>>>>> > https://www.ietf.org/mailman/listinfo/oauth > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > -- > >>>>>> > Nat Sakimura (=nat) > >>>>>> > Chairman, OpenID Foundation > >>>>>> > http://nat.sakimura.org/ > >>>>>> > @_nat_en > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> Nat Sakimura (=nat) > >>>>>> > >>>>>> Chairman, OpenID Foundation > >>>>>> http://nat.sakimura.org/ > >>>>>> @_nat_en > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> Nat Sakimura (=nat) > >>>>>> > >>>>>> Chairman, OpenID Foundation > >>>>>> http://nat.sakimura.org/ > >>>>>> @_nat_en > >>>>>> > >>>>>> > >>>>>> > >>>>>> > _______________________________________________ > >>>>>> OAuth mailing list > >>>>>> OAuth@ietf.org > > >>>>>> > https://www.ietf.org/mailman/listinfo/oauth > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> Thomas Broyer > >>>>>> /tɔ.ma.bʁwa.je/ > >>>>>> > >>>>>> > >>>>>> > _______________________________________________ > >>>>>> OAuth mailing list > >>>>>> OAuth@ietf.org > > >>>>>> > https://www.ietf.org/mailman/listinfo/oauth > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> Thomas Broyer > >>>>>> /tɔ.ma.bʁwa.je/ > >>>>>> > >>>>>> > >>>>>> > >>>>>> > _______________________________________________ > >>>>>> OAuth mailing list > >>>>>> OAuth@ietf.org > > >>>>>> > https://www.ietf.org/mailman/listinfo/oauth > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> Nat Sakimura (=nat) > >>>>>> > >>>>>> Chairman, OpenID Foundation > >>>>>> http://nat.sakimura.org/ > >>>>>> @_nat_en > >>>>>> > >>>>>> > >>>>>> > _______________________________________________ > >>>>>> > >>>>>> 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 > >>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> Nat Sakimura (=nat) > >>>>>> Chairman, OpenID Foundation > >>>>>> http://nat.sakimura.org/ > >>>>>> @_nat_en > >>>>>> > >>>>>> _______________________________________________ > >>>>>> OAuth mailing list > >>>>>> OAuth@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> Nat Sakimura (=nat) > >>>>>> Chairman, OpenID Foundation > >>>>>> http://nat.sakimura.org/ > >>>>>> @_nat_en > >>>>>> > >>>>>> _______________________________________________ > >>>>>> 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 > >> > >> > >> > >> > >> -- > >> Nat Sakimura (=nat) > >> Chairman, OpenID Foundation > >> http://nat.sakimura.org/ > >> @_nat_en > >> > >> _______________________________________________ > >> 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 From nobody Mon Oct 13 07:14:23 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A70251A8AEA; Mon, 13 Oct 2014 07:14:17 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVMc3F4Ly_66; Mon, 13 Oct 2014 07:14:15 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0121.outbound.protection.outlook.com [65.55.169.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 224471A1B8A; Mon, 13 Oct 2014 07:14:15 -0700 (PDT) Received: from CO2PR03CA0026.namprd03.prod.outlook.com (10.141.194.153) by BN3PR0301MB1204.namprd03.prod.outlook.com (25.161.207.16) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Mon, 13 Oct 2014 14:14:12 +0000 Received: from BY2FFO11FD009.protection.gbl (2a01:111:f400:7c0c::168) by CO2PR03CA0026.outlook.office365.com (2a01:111:e400:1414::25) with Microsoft SMTP Server (TLS) id 15.0.1049.19 via Frontend Transport; Mon, 13 Oct 2014 14:14:11 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD009.mail.protection.outlook.com (10.1.14.73) with Microsoft SMTP Server (TLS) id 15.0.1039.16 via Frontend Transport; Mon, 13 Oct 2014 14:14:10 +0000 Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.93]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.193]) with mapi id 14.03.0210.003; Mon, 13 Oct 2014 14:13:32 +0000 From: Mike Jones To: Benoit Claise , The IESG Thread-Topic: Benoit Claise's Discuss on draft-ietf-oauth-saml2-bearer-21: (with DISCUSS and COMMENT) Thread-Index: AQHP5upYt4FwAncw40+o/Wr7Rt3tppwuEGdg Date: Mon, 13 Oct 2014 14:13:31 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439BAFCE22@TK5EX14MBXC286.redmond.corp.microsoft.com> References: <20141013133343.28609.70075.idtracker@ietfa.amsl.com> In-Reply-To: <20141013133343.28609.70075.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(979002)(6009001)(438002)(189002)(52044002)(13464003)(51704005)(43784003)(199003)(377454003)(6806004)(21056001)(44976005)(19580405001)(19580395003)(77096002)(120916001)(76176999)(76482002)(54356999)(99396003)(50986999)(46102003)(80022003)(15202345003)(85306004)(230783001)(87936001)(104016003)(85806002)(2656002)(33656002)(26826002)(55846006)(31966008)(85852003)(4396001)(84676001)(69596002)(68736004)(15975445006)(47776003)(20776003)(64706001)(66066001)(50466002)(97736003)(86612001)(92726001)(92566001)(86362001)(81156004)(106116001)(106466001)(95666004)(23676002)(107046002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1204; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1204; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 03630A6A4A Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/ixdSaU_RrLgnQWd4ffx_CSSmrVk Cc: "oauth-chairs@tools.ietf.org" , "draft-ietf-oauth-saml2-bearer@tools.ietf.org" , "oauth@ietf.org" , Tom Taylor Subject: Re: [OAUTH-WG] Benoit Claise's Discuss on draft-ietf-oauth-saml2-bearer-21: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 14:14:17 -0000 VGhhbmtzIGZvciB5b3VyIHJldmlldyBCZW5vaXQuICBJJ20gYWRkaW5nIHRoZSB3b3JraW5nIGdy b3VwIHRvIHRoZSB0aHJlYWQgc28gdGhleSdyZSBhd2FyZSBvZiB5b3VyIGNvbW1lbnRzLiAgUmVw bGllcyBpbmxpbmUgYmVsb3cuLi4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBG cm9tOiBCZW5vaXQgQ2xhaXNlIFttYWlsdG86YmNsYWlzZUBjaXNjby5jb21dDQo+IFNlbnQ6IE1v bmRheSwgT2N0b2JlciAxMywgMjAxNCA2OjM0IEFNDQo+IFRvOiBUaGUgSUVTRw0KPiBDYzogVG9t IFRheWxvcjsgb2F1dGgtY2hhaXJzQHRvb2xzLmlldGYub3JnOyBkcmFmdC1pZXRmLW9hdXRoLXNh bWwyLQ0KPiBiZWFyZXJAdG9vbHMuaWV0Zi5vcmcNCj4gU3ViamVjdDogQmVub2l0IENsYWlzZSdz IERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1vYXV0aC1zYW1sMi1iZWFyZXItMjE6ICh3aXRoDQo+IERJ U0NVU1MgYW5kIENPTU1FTlQpDQo+IA0KPiBCZW5vaXQgQ2xhaXNlIGhhcyBlbnRlcmVkIHRoZSBm b2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPiBkcmFmdC1pZXRmLW9hdXRoLXNhbWwyLWJl YXJlci0yMTogRGlzY3Vzcw0KPiANCj4gV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUg c3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsIGVtYWlsDQo+IGFkZHJlc3NlcyBp bmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzIGlu dHJvZHVjdG9yeQ0KPiBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPiANCj4gDQo+IFBsZWFzZSByZWZl ciB0byBodHRwOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEu aHRtbA0KPiBmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1F TlQgcG9zaXRpb25zLg0KPiANCj4gDQo+IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBi YWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCj4gaHR0cDovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9hdXRoLXNhbWwyLWJlYXJlci8NCj4gDQo+IA0KPiAN Cj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KPiBESVNDVVNTOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiBObyBv YmplY3Rpb24gb24gdGhlIGRvY3VtZW50IGl0c2VsZiwgYnV0LCBhcyByaWdodGx5IG5vdGVkIGJ5 IFRvbSBUYXlsb3IgaW4gdGhlDQo+IE9QUy1ESVIgcmV2aWV3Og0KPiBQcm9jZXNzIGlzc3VlOiBJ RG5pdHMgY29tcGxhaW5zIG9mIGEgbm9ybWF0aXZlIHJlZmVyZW5jZSB0byBJbmZvcm1hdGlvbmFs DQo+IGRvY3VtZW50IFJGQyA2NzU1LiBUaGlzIHdhcyBOT1Qgbm90ZWQgaW4gdGhlIExhc3QgQ2Fs bCBhbm5vdW5jZW1lbnQgKGJ1dA0KPiB3YXMgbm90ZWQgaW4gdGhlIFNoZXBoZXJkIHdyaXRldXAp LiBObyBvcGVyYXRpb25hbCBpc3N1ZSBpZGVudGlmaWVkIGJleW9uZA0KPiB3aGF0IGlzIGFscmVh ZHkgY292ZXJlZCBieSB0aGUgSW50ZXJvcGVyYWJpbGl0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9u Lg0KPiANCj4gQXMgYW4gZXhhbXBsZSwgaW4gdGhlIGNhc2Ugb2YNCj4gaHR0cDovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9yZmM3MzE3L2hpc3RvcnkvLCBJIGhhZCB0byByZWRvIHRoZSBJRVRG IExDIHdpdGgNCj4gdGhlIGFwcHJvcHJpYXRlIHN0YXRlbWVudCAoYmFzZWQgb24gYSBESVNDVVNT IGZyb20gbXkgZmVsbG93LUFEKS4NCj4gV2Ugc2hvdWxkIGJlIGNvbnNpc3RlbnQgaGVyZS4NCg0K QmFycnkgTGVpYmEgaGFkIHdyaXR0ZW4gaW4gcmVzcG9uc2UgdG8gdGhpcyAiSSB0aGluayB0aGUg cmlnaHQgYW5zd2VyIGhlcmUgaXMgdG8gbWFrZSA2NzU1IGFuIGluZm9ybWF0aXZlIHJlZmVyZW5j ZTogaXQncyBub3QgbmVlZGVkIHRvIHVuZGVyc3RhbmQgdGhpcyBkb2N1bWVudCwgYW5kIGlzIG9u bHkgdXNlZCBhcyBhIHJlZmVyZW5jZSB0byB0aGUgZG9jdW1lbnQgd2hlcmUgdGhlIG5hbWVzcGFj ZSB3YXMgY3JlYXRlZC4iICBJIGFncmVlIHRoYXQgdGhpcyByZXNvbHV0aW9uIHdvdWxkIGJlIGZp bmUuDQoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBDT01NRU5UOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0K PiBFZGl0b3JpYWwgTml0czoNCj4gDQo+IFMyLjI6IFRoZSBwYXJhZ3JhcGggYmVmb3JlIHRoZSBh Y3R1YWwgZXhhbXBsZSB1c2VzIHRlcm1pbm9sb2d5IGluY29uc2lzdGVudA0KPiB3aXRoIFJGQyA2 NzQ5Og0KPiANCj4gIHMvYXV0aG9yaXphdGlvbiBjb2RlIGdyYW50L2F1dGhvcml6YXRpb24gZ3Jh bnQvDQoNClBlciBteSByZXBseSBvbiBPY3RvYmVyIDYgdG8gVG9tIFRheWxvcidzIHJldmlldyB3 aGljaCBtYWRlIHRoZSBzYW1lIGNvbW1lbnQsIGFjdHVhbGx5LCBSRkMgNjc0OSB1c2VzIGJvdGgg dGVybXMuICBBdXRob3JpemF0aW9uIGdyYW50IGlzIHRoZSBnZW5lcmljIHRlcm0uICBBdXRob3Jp emF0aW9uIENvZGUgR3JhbnQgKGRlZmluZWQgaW4gU2VjdGlvbiA0LjEgb2YgNjc0OSkgaXMgYSBz cGVjaWZpYyBraW5kIG9mIGF1dGhvcml6YXRpb24gZ3JhbnQuICBUaGUgdGV4dCBpcyBjb3JyZWN0 IGFzLWlzLg0KDQoJCQkJVGhhbmtzIGFnYWluLA0KCQkJCS0tIE1pa2UNCg0K From nobody Mon Oct 13 07:18:31 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A9E91A0024 for ; Mon, 13 Oct 2014 07:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.829 X-Spam-Level: X-Spam-Status: No, score=-3.829 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.157, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id moNSfTVJUJ0h for ; Mon, 13 Oct 2014 07:18:01 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA9A51A0019 for ; Mon, 13 Oct 2014 07:18:00 -0700 (PDT) X-AuditID: 12074424-f79346d000004923-d1-543bdf170666 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 3A.8B.18723.71FDB345; Mon, 13 Oct 2014 10:17:59 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s9DEHwUn007587; Mon, 13 Oct 2014 10:17:59 -0400 Received: from [IPv6:2607:fb90:180e:d43a:918c:ef47:9a91:ea3e] ([172.56.3.211]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s9DEHoQT023417 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 13 Oct 2014 10:17:52 -0400 Date: Mon, 13 Oct 2014 10:17:50 -0400 Message-ID: Importance: normal From: Justin Richer To: Sergey Beryozkin , oauth@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.android.email_486516192215700" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFIsWRmVeSWpSXmKPExsUixCmqrCt+3zrE4EeXosXJt6/YLP4ttXdg 8tg56y67x5IlP5kCmKK4bFJSczLLUov07RK4Mlbc6GMruPlWsGJ5zyrmBsaPmwS7GDk5JARM JFZNXcUKYYtJXLi3nq2LkYtDSGA2k8SrOcdZIZyNjBLr5v1khHAOMEnsedTICNLCIqAq0XB2 HnsXIweHsEC0xM450SAmr4CbxK5nNiAmp4CQRNcuCZBiNqDi6WtamEBsEQFriRuPp4MN4RUQ lDg58wkLiM0sECJx59cOpgmMvLOQpGYhSUHY6hJ/5l1ihrAVJaZ0P2SfBbSNWUBNYlmrErLw Aka2VYyyKblVurmJmTnFqcm6xcmJeXmpRbrmermZJXqpKaWbGEFByu6isoOx+ZDSIUYBDkYl Ht4HP61ChFgTy4orcw8xSnIwKYnyHrxlHSLEl5SfUpmRWJwRX1Sak1p8iFGCg1lJhFf0ElCO NyWxsiq1KB8mJc3BoiTOu+kHX4iQQHpiSWp2ampBahFMVoaDQ0mC9+FdoEbBotT01Iq0zJwS hDQTByfIcB6g4Yr3QIYXFyTmFmemQ+RPMSpKifMuBWkWAElklObB9cKSyCtGcaBXhHk/g1Tx ABMQXPcroMFMQINfF4MNLklESEk1MLYffv9pg8TmqV8r7789ZeI3++LPr1z+9QtjTjvPOHyQ pf7u/qYWd/6MUzPfyp29GPz4rsn5t0sbry48N4VZ9hv7rDrnuPjpH84xVoa3qj3yED5w8dkc lstrJrRf6RKdoX8y60BE3OKCq+2cAb1f7VSvf/nZbF9+/Fnkg6BPPckPjgpaBFy9kb9ViaU4 I9FQi7moOBEAFfWT1P0CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/veIzH3UNeeMpOwlNxf5p5I7Tbiw Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 14:18:17 -0000 ----_com.android.email_486516192215700 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 WW91IGNlcnRhaW5seSBjYW4gZG8gYXV0aGVudGljYXRpb24gd2l0aG91dCB1c2luZyBhbiBhY2Nl c3MgdG9rZW4sIGJ1dCB0aGVuIEkgd291bGQgYXJndWUgdGhhdCdzIG5vIGxvbmdlciBPQXV0aC4g QmFzaWNhbGx5IHlvdSdyZSBtYWtpbmcgdG9mdSBjYXJvYiBmdWRnZS4KCgotLSBKdXN0aW4KCi8g U2VudCBmcm9tIG15IHBob25lIC8KCgotLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0t CkZyb206IFNlcmdleSBCZXJ5b3praW4gPHNiZXJ5b3praW5AZ21haWwuY29tPiAKRGF0ZToxMC8x My8yMDE0ICA5OjAwIEFNICAoR01ULTA1OjAwKSAKVG86IEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJA bWl0LmVkdT4sIG9hdXRoQGlldGYub3JnIApDYzogIApTdWJqZWN0OiBSZTogW09BVVRILVdHXSBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yICBkcmFmdC1odW50LW9hdXRoLXYyLXVzZXItYTRj LTA1LnR4dCAKCkhpIEp1c3RpbiwKT24gMTMvMTAvMTQgMTI6NTMsIEp1c3RpbiBSaWNoZXIgd3Jv dGU6Cj4gWW91IGFyZSBjb3JyZWN0IGluIHRoYXQgT0F1dGggMiBhbmQgT3BlbklEIENvbm5lY3Qg YXJlIG5vdCB0aGUgc2FtZQo+IHRoaW5nLCBidXQgeW91ciB1c2VyIGlzIGNvcnJlY3QgdGhhdCBP SURDIGFkZHMgYSBmZXcgcGllY2VzIG9uIHRvcCBvZgo+IE9BdXRoIHRvIGFkZCBhdXRoZW50aWNh dGlvbiBjYXBhYmlsaXRpZXMuIE9JREMgd2FzIGRlc2lnbmVkIHZlcnkKPiBleHBsaWNpdGx5IHRv IGJlIGNvbXBhdGlibGUgd2l0aCB2YW5pbGxhIE9BdXRoLCBwYXJ0aWFsbHkgZG8gdGhhdCBwZW9w bGUKPiB3b3VsZCBiZSBhYmxlIHRvIGRlcGxveSBpdCBvbiB0b3Agb2YgZXhpc3RpbmcgT0F1dGgg aW5mcmFzdHJ1Y3R1cmUgYW5kCj4gY29kZS4gQnV0IHRoZSB2ZXJ5IGZhY3QgdGhhdCBPSURDIGFk ZHMgYSBmZXcgdGhpbmdzIG9uIHRvcCBvZiBPQXV0aCB0bwo+IGdpdmUgbW9yZSBmdW5jdGlvbmFs aXR5IHNob3VsZCBiZSBzdWZmaWNpZW50IGV2aWRlbmNlIHRoYXQgdGhleSdyZSBub3QKPiBlcXVp dmFsZW50Lgo+Cj4gSXQncyBtb3JlIHByb3BlciB0byBzYXkgdGhhdCBPcGVuSUQgQ29ubmVjdCBp cyBhbiBleHRlbnNpb24gYW5kCj4gYXBwbGljYXRpb24gb2YgT0F1dGguIE9uZSB0aGF0IHByb3Zp ZGVzIGFuIGF1dGhlbnRpY2F0aW9uIGFuZCBpZGVudGl0eSBBUEkuCj4KSSBhZ3JlZSBhbmQgdGhp cyBpcyBtb3JlIG9yIGxlc3MgaG93IEkgYW5zd2VyZWQuCgpUaG91Z2ggdGhlICdib3JkZXJzJyBj YW4gYmUgYmx1cnJlZCwgb25lIGNhbiBjbGFpbSB0aGF0IGlmIGEgdXNlciAKYWN0dWFsbHkgbG9n cyBvbiBpbnRvIGEgY29uZmlkZW50aWFsIE9BdXRoMiBjbGllbnQgd2ViIGFwcGxpY2F0aW9uIHdo aWNoIApyZWRpcmVjdHMgdGhpcyB1c2VyIHRvIEFTIHJlcXVlc3RpbmcgYSBjb2RlIHdpdGggc29t ZSBzY29wZXMgc3VjaCBhcyAiYSAKYiIgdGhlbiB3aGVuIGl0IHVzZXMgImEgYiBvcGVuaWQgcHJv ZmlsZSIgaXQgaXMgYmFzaWNhbGx5IGRvZXMgYSBwdXJlIApPQXV0aDIgY29kZSBmbG93IHdoZXJl IHRoZSBjbGllbnQgcmVxdWVzdHMgJ2EgYicgcGx1cyBhbHNvIGEgc2NvcGUgCmFsbG93aW5nIGl0 IGxhdGVyIHRvIHF1ZXJ5IHRoZSBpZGVudGl0eSBzeXN0ZW0gb24gYmVoYWxmIG9mIGEgdXNlci4K CkkgbGlrZSB0aGUgIlRoZSBleHRlbnNpb24gYW5kIGFwcGxpY2F0aW9uIG9mIE9BdXRoMiIgY2hh cmFjdGVyaXN0aWMgb2YgCk9JREMuIElNSE8gaXQncyBiZWNvbWluZyBtb3JlIG9idmlvdXMgaWYg T0lEQyBpcyB1c2VkIHRvIHN1cHBvcnQgU1NPIAppbnRvIG5vbi1PQXV0aDIgc2VydmVycywgd2hl biBpdCBpcyB0aGUgY2FzZSB0aGVuIHRoZXJlJ3Mgbm8gJ2ZlZWxpbmcnIAp0aGF0IE9JREMgaXMg anVzdCBhIGNhc2Ugb2YgdGhlIGNvbmZpZGVudGlhbCBjbGllbnQgYWRkaW5nIHRoZSBleHRyYSAK c2NvcGVzIGFuZCBnZXR0aW5nIHRoZSBleHRyYSAoYXV0aGVudGljYXRpb24pIGluZm8gYmFjay4g QSBzdGFuZGFsb25lIApPSURDIFJQIHByb3RlY3Rpbmcgc3VjaCBub24gT0F1dGgyIHNlcnZlcnMg aXMgdmVyeSBtdWNoIGFib3V0IHRoZSAKYXV0aGVudGljYXRpb24vaWRlbnRpdHkuCgpJIGFsc28g dGhvdWdodCB0aGF0IGhhdmluZyBzb21lIE9JRCBwcm9maWxlIChhcyBvcHBvc2VkIHVwZGF0aW5n IE9BdXRoMiAKdG8gc3VwcG9ydCBubyBhY2Nlc3MgdG9rZW5zKSB3aGVyZSBubyBhY2Nlc3MgYnV0 IG9ubHkgaWQgdG9rZW4gd2FzIApyZXR1cm5lZCAoYXMgc3VnZ2VzdGVkIGluIHRoaXMgdGhyZWFk KSB3b3VsZCBwcm9iYWJseSBtYWtlIHNlbnNlIHRvby4KCj4gVGhlIHdheSBJIGxpa2UgdG8gZXhw bGFpbiBpdCAod2hpY2ggSSBzdG9sZSBmcm9tIHNvbWVvbmUgZWxzZSkgaXMgdGhhdAo+IE9BdXRo IGlzIGxpa2UgY2hvY29sYXRlIGFuZCBhdXRoZW50aWNhdGlvbiBpcyBsaWtlIGZ1ZGdlLiBUaGV5 IGFyZSBub3QKPiB0aGUgc2FtZSB0aGluZy4gWW91IGNhbiBtYWtlIGNob2NvbGF0ZSBpbnRvIGZ1 ZGdlIG91dCB5b3UgY2FuIG1ha2UgaXQKPiBpbnRvIHNvbWV0aGluZyBlbHNlIG9yIHlvdSBjYW4g anVzdCBoYXZlIGl0IG9uIGl0cyBvd24uIFlvdSBjYW4gbWFrZQo+IGZ1ZGdlIHdpdGggY2hvY29s YXRlIG9yIHlvdSBjYW4gbWFrZSBpdCB3aXRoIHBlYW51dCBidXR0ZXIgb3IgeW91IGNhbgo+IG1h a2UgaXQgd2l0aCBwb3RhdG9lcyBpZiB5b3Ugd2FudCB0bywgYnV0IGl0IG5lZWRzIGEgY291cGxl IGluZ3JlZGllbnRzCj4gYW5kIGEgdmVyeSBjb21tb24gb25lIGlzIGNob2NvbGF0ZS4gT3BlbklE IENvbm5lY3QgaXMgYSByZWNpcGUgZm9yCj4gY2hvY29sYXRlIGZ1ZGdlIHRoYXQgYSBsb3Qgb2Yg cGVvcGxlIGxpa2UuIEFuZCBpdCBtYWtlcyBteSBmdWRnZQo+IGNvbXBhdGlibGUgd2l0aCB5b3Vy IGZ1ZGdlLCB3aGljaCBpcyB3aGVyZSB0aGUgbWV0YXBob3IgYnJlYWtzIGRvd24uIDotKQo+ClRo YW5rcyBmb3Igc2hhcmluZyB0aGlzIGNvbG91cmZ1bCBleHBsYW5hdGlvbiA6LSkuIFBlcmhhcHMg SSBzaG91bGQgCmJvcnJvdyBpdCA6LSksCkNoZWVycywgU2VyZ2V5CgoKPgo+IC0tIEp1c3Rpbgo+ Cj4gLyBTZW50IGZyb20gbXkgcGhvbmUgLwo+Cj4KPiAtLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdl IC0tLS0tLS0tCj4gRnJvbTogU2VyZ2V5IEJlcnlvemtpbiA8c2JlcnlvemtpbkBnbWFpbC5jb20+ Cj4gRGF0ZToxMC8xMy8yMDE0IDY6MzMgQU0gKEdNVC0wNTowMCkKPiBUbzogb2F1dGhAaWV0Zi5v cmcKPiBDYzoKPiBTdWJqZWN0OiBSZTogW09BVVRILVdHXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yCj4gZHJhZnQtaHVudC1vYXV0aC12Mi11c2VyLWE0Yy0wNS50eHQKPgo+IEhpCj4KPiBX ZSd2ZSBoYWQgYSB1c2VyIGFzc2VydGluZyB0aGF0ICJPQXV0aDIgPT0gT3BlbmlkQ29ubmVjdCIs IHJlZmVycmluZyB0bwo+IHRoZSBmYWN0IHRoYXQgdGhlICdvbmx5JyB0aGluZyBPSUMgYWRkcyBv biB0b3Agb2YgdGhlIGF1dGhvcml6YXRpb24gY29kZQo+IGZsb3cgaXMgdGhlIGNsaWVudCBzcGVj aWZ5aW5nIGZldyBleHRyYSBzY29wZXMgbGlrZSAnb3BlbmlkJyBhbmQKPiAncHJvZmlsZScgYW5k IHRoZSBhdXRob3JpemF0aW9uIHNlcnZpY2UgcmV0dXJuaW5nIGFuIGV4dHJhIHByb3BlcnR5LCB0 aGUKPiBpZF90b2tlbiB3aGljaCBjYW4gYmUgc3VmZmljaWVudCBpbiBvcmRlciB0byBnZXQgdGhl IGF1dGhlbnRpY2F0ZWQKPiB1c2VyJ3MgaW5mby4KPgo+IE15IHVuZGVyc3RhbmRpbmcgIk9BdXRo MiAhPSBPcGVuaWRDb25uZWN0IiwgdGhlIGxhdHRlciB1dGlsaXplcyB0aGUKPiBmb3JtZXIgYW5k IGlzIGFuIGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbSB3aGljaCBpcyBub3Qgd2hhdCBPQXV0aDIg aXMKPiAobWF5IGJlIGV4Y2VwdCBmb3IgdGhlIGNsaWVudCBjcmVkZW50aWFscykuIEJ1dCBJIGRv bid0IGZlZWwgbGlrZSBpdCBpcwo+IGEgY29udmluY2luZyBlbm91Z2ggYXJndW1lbnQuCj4KPiBJ IHRob3VnaHQgdGhpcyB0aHJlYWQgd2FzIHJlbGV2YW50LCBzb3JyeSBpZiBub3QsIHdvdWxkIGhh dmUgbm8gcHJvYmxlbXMKPiBzdGFydGluZyBhIG5ldyBvbmUuCj4KPiBCYXNpY2FsbHksIEkgd29u ZGVyIHdoYXQgaXMgdGhlIHByb3BlciBsaW5lIG9mIGFyZ3VtZW50IGZvciBhIHBvc2l0aW9uCj4g c3VjaCBhcyAiT0F1dGgyICE9IE9wZW5pZENvbm5lY3QiIGFuZCBhbHNvIHdoYXQgd2FzIHRoZSBh Y3Rpb24gdG8gdGhlCj4gbGlzdCBvZiBvcHRpb25zIHN1Z2dlc3RlZCBieSBKb2huIGJlbG93LiBJ cyBoYXZpbmcgYW4gT0lEIHByb2ZpbGUgd2hlcmUKPiBubyBhY2Nlc3MgdG9rZW4gaXMgcmV0dXJu ZWQgd291bGQgYmUgdGhlIGNsZWFuZXN0IGFjdGlvbiBhcyBmYXIgYXMKPiBicmVha2luZyB0aGUg YW1iaWd1aXR5L2NvbmZ1c2lvbiBpcyBjb25jZXJuZWQgPwo+Cj4gQ2hlZXJzLCBTZXJnZXkKPgo+ IE9uIDI0LzA3LzE0IDE1OjI1LCBKb2huIEJyYWRsZXkgd3JvdGU6Cj4gID4gSSBhbSBub3QgYWdh aW5zdCBkaXNjdXNzaW9uIGluIHRoZSBXRy4KPiAgPgo+ICA+IEkgaGFwcGVuIHRvIGFncmVlIHdp dGggUGhpbCdzIGZ1bmRhbWVudGFsIHByZW1pc2UgdGhhdCBzb21lIGRldmVsb3BlcnMKPiAgPiBh cmUgdXNpbmcgT0F1dGggaW4gYSBpbnNlY3VyZSB3YXkgdG8gZG8gYXV0aGVudGljYXRpb24uCj4g ID4KPiAgPiBUaGF0IHJhaXNlcyB0aGUgcXVlc3Rpb24gb2YgaG93IHRvIGJlc3QgZWR1Y2F0ZSB0 aGVtLCBhbmQgb3IgYWRkcmVzcwo+ICA+IHRlY2huaWNhbCBiYXJyaWVycy4KPiAgPgo+ICA+IEl0 IGlzIG9uIHRoZSBzZWNvbmQgcG9pbnQgdGhhdCBwZW9wbGUncyBvcGluaW9ucyBzZWVtIHRvIGRp dmlkZS4KPiAgPgo+ICA+IFNvbWUgcGVvcGxlIHRoaW5nIHRoYXQgaWYgd2UgaGF2ZSBhIE9BdXRo IGZsb3cgdGhhdCBlbGltaW5hdGVzIHRoZQo+ICA+IGFjY2VzcyB0b2tlbiAocHJpbWFyaWx5IHRv IGF2b2lkIGFza2luZyBmb3IgY29uc2VudCBhcyBJIHVuZGVyc3RhbmQgaXQpCj4gID4gYW5kIGp1 c3QgcmV0dXJuIGEgaWRfdG9rZW4gZnJvbSB0aGUgdG9rZW4gZW5kcG9pbnQgdGhhdCBjYW4gYmUg ZG9uZSBpbiBhCj4gID4gc3BlYyBzaG9ydCBlbm91Z2ggdG8gaGV0IHBlb3BsZSB0byByZWFkLiAg IFRoZSBzdWJ0ZXh0IG9mIHRoaXMgaXMgdGhhdAo+ICA+IHRoZSBDb25uZWN0IHNwZWNpZmljYXRp b24gaXMgdG9vIGxhcmdlIHRoYXQgaXQgc2NhcmUgcGVvcGxlLCAgYW5kIHRoZXkKPiAgPiBkb24n dCBmaW5kIHRoZSBzcGVjIGluIHRoZSBmaXJzdCBwbGFjZSBiZWNhdXNlIGl0IGlzIG5vdCBhIFJG Qy4KPiAgPgo+ICA+IEFuIG90aGVyIGNvbW1vbiBwb3NzZXNzaW9uIGlzIHRoYXQgaWYgeW91IGRv bid0IHdhbnQgdG8gcHJvbXB0IHRoZSB1c2VyCj4gID4gZm9yIGNvbnNlbnQgdGhlbiBkb24ndCBh c2sgZm9yIHNjb3Blcy4gIFR3aXN0aW5nIHRoZSBPQXV0aCBzcGVjIHRvIG5vdAo+ICA+IHJldHVy biBhbiBhY2Nlc3MgdG9rZW4gaXMgbm90IE9BdXRoLCAgeWVzIHlvdSBjb3VsZCB1c2UgYSBkaWZm ZXJlbnQKPiAgPiBlbmRwb2ludCByYXRoZXIgdGhhbiB0aGUgdG9rZW4gZW5kcG9pbnQsIGJ1dCB0 aGF0IGlzIG5vdCBPQXV0aC4KPiAgPiBDb25uZWN0IHdhcyBjYXJlZnVsIG5vdCB0byBicmVhayB0 aGUgT0F1dGggc3BlYy4gICAgQXMgbG9uZyBhcyB5b3UgYXJlCj4gID4gd2lsbGluZyB0byB0YWtl IGEgYWNjZXNzIHRva2VuIHdpdGggbm8gc2NvcGVzICh0aGUgY2xpZW50IG5lZWRzIHRvCj4gID4g dW5kZXJzdGFuZCB0aGF0IHRoZXJlIGFyZSBubyBhdHRyaWJ1dGVzIG9uZSB3YXkgb3IgYW5vdGhl ciBhbnl3YXkgb3IgaXQKPiAgPiB3aWxsIGJyZWFrKSB0aGVuIHlvdSBkb24ndCBuZWVkIHRvIGNo YW5nZSBPQXV0aC4gICBZb3UgY2FuIHB1Ymxpc2ggYQo+ICA+IHByb2ZpbGUgb2YgY29ubmVjdCB0 aGF0IHNhdGlzZmllcyB0aGUgdXNlIGNhc2UuCj4gID4KPiAgPiBJIHRoaW5rIE1pa2UgaGFzIGxh cmdlbHkgZG9uZSB0aGF0IGJ1dCBpdCBtaWdodCBiZSBiZXR0ZXIgYmVpbmcgbGVzcwo+ICA+IHN0 aW5neSBvbiByZWZlcmVuY2VzIGJhY2sgdG8gdGhlIGxhcmdlciBzcGVjLgo+ICA+Cj4gID4gVGhl IHF1ZXN0aW9ucyBhcmUgZG8gd2UgbW9kaWZ5IE9BdXRoIHRvIG5vdCByZXR1cm4gYW4gYWNjZXNz IHRva2VuLCBhbmQKPiAgPiBpZiBzbyBob3csICBhbmQgaWYgd2UgZG8gaXMgaXQgc3RpbGwgT0F1 dGguCj4gID4KPiAgPiBUaGUgb3RoZXIgbGFyZ2VseSBzZXBhcmFibGUgcXVlc3Rpb24gaXMgZG8g d2UgY3JlYXRlIGNvbmZ1c2lvbiBpbiB0aGUKPiAgPiBtYXJrZXQgYW5kIHNsb3cgdGhlIHRoZSBh ZG9wdGlvbiBvZiBpZGVudGl0eSBmZWRlcmF0aW9uIG9uIHRvcCBvZiBPQXV0aCwKPiAgPiBvciBm aW5kIGEgd2F5IHRvIG1ha2UgdGhpcyBsb29rIGxpa2UgYSBwb3NpdGl2ZSBhbGlnbm1lbnQgb2Yg aW50ZXJlc3RzCj4gID4gYXJvdW5kIGEgc3Vic2V0IG9mIENvbm5lY3QuCj4gID4KPiAgPiBUaGVy ZSBhcmUgYSBudW1iZXIgb2Ygb3B0aW9ucy4KPiAgPiAxOiBXZSBjYW4gZG8gYSBwcm9maWxlIGlu IHRoZSBPSURGIGFuZCBwdWJsaXNoIGl0IGFzIGEgSUVURiBkb2N1bWVudC4KPiAgPiBQZXJoYXBz IHRoZSBjbGVhbmVzdCBmcm9tIGFuIElQUiBwb2ludCBvZiB2aWV3Lkhvd2V2ZXIKPiAgPiAyOldl IGNhbiBkbyBhIHByb2ZpbGUgaW4gdGhlIE9BdXRoIFdHIHJlZmVyZW5jaW5nIGNvbm5lY3QuCj4g ID4gMzpXZSBjYW4gZG8gYSBBRCBzcG9uc29yZWQgcHJvZmlsZSB0aGF0IGlzIG5vdCBpbiB0aGUg T0F1dGggV0cuCj4gID4gNDpXZSBjYW4gZG8gYSBzbWFsbCBzcGVjIGluIE9BdXRoIHRvIGFkZCBy ZXNwb25zZV90eXBlIHRvIHRoZSB0b2tlbgo+ICA+IGVuZHBvaW50LiAgaW4gY29tYmluYXRpb24g d2l0aCAxLCAyLCBvciAzCj4gID4KPiAgPiBJIGFncmVlIHRoYXQgc3RvcGluZyBkZXZlbG9wZXJz IGRvaW5nIGluc2VjdXJlIHRoaW5ncyBuZWVkcyB0byBiZQo+ICA+IGFkZHJlc3NlZCBzb21laG93 Lgo+ICA+IEkgYW0gbm90IHBlcnNvbmFsbHkgY29udmluY2VkIHRoYXQgT2F1dGggd2l0aG91dCBh Y2Nlc3MgdG9rZW5zIGlzCj4gc2Vuc2libGUuCj4gID4KPiAgPiBMb29raW5nIGZvcndhcmQgdG8g dGhlIG1lZXRpbmc6KQo+ICA+Cj4gID4gSm9obiBCLgo+ICA+IE9uIEp1bCAyNCwgMjAxNCwgYXQg Njo1MiBBTSwgQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tCj4gID4g PG1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbT4+IHdyb3RlOgo+ICA+Cj4gID4+IEkn ZCBub3RlIHRoYXQgdGhlIHJlYWN0aW9uIGF0IHRoZSBjb25mZXJlbmNlIHRvIElhbidzIHN0YXRl bWVudCB3YXMKPiAgPj4gb3ZlcndoZWxtaW5nbHkgcG9zaXRpdmUuIFRoZXJlIHdhcyBhIHdpZGUg cmFuZ2Ugb2YgaW5kdXN0cnkgcGVvcGxlCj4gID4+IGhlcmUgLSBpbXBsZW1lbnRlcnMsIHByYWN0 aXRpb25lcnMsIGRlcGxveWVycywgc3RyYXRlZ2lzdHMsIGV0Yy4gLSBhbmQKPiAgPj4gaXQgc2Vl bXMgcHJldHR5IGNsZWFyIHRoYXQgdGhlICJyb3VnaCBjb25zZW5zdXMiIG9mIHRoZSBpbmR1c3Ry eSBhdAo+ICA+PiBsYXJnZSBpcyB0aGF0IGE0YyBpcyBub3Qgd2FudGVkIG9yIG5lZWRlZC4KPiAg Pj4KPiAgPj4KPiAgPj4gT24gVGh1LCBKdWwgMjQsIDIwMTQgYXQgNToyOSBBTSwgTmF0IFNha2lt dXJhIDxzYWtpbXVyYUBnbWFpbC5jb20KPiAgPj4gPG1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20+ PiB3cm90ZToKPiAgPj4KPiAgPj4gICAgIEFuZCBoZXJlIGlzIGEgcXVvdGUgZnJvbSBJYW4ncyBi bG9nLgo+ICA+Pgo+ICA+PiAgICAgICAgIEFuZCBhbHRob3VnaCB0aGUgYXV0aGVudGljYXRpb24g d2hlZWwgaXMgcm91bmQsIHRoYXQgZG9lc27igJl0Cj4gID4+ICAgICAgICAgbWVhbiBpdCBpc27i gJl0IHdpdGhvdXQgaXRzIGx1bXBzLiBGaXJzdCwgd2UgZG8gc2VlIHNvbWUKPiAgPj4gICAgICAg ICByZWludmVudGluZyB0aGUgd2hlZWwganVzdCB0byByZWludmVudCB0aGUgd2hlZWwuIE9BdXRo IEE0QyBpcwo+ICA+PiAgICAgICAgIHNpbXBseSBub3QgYSBmcnVpdGZ1bCBhY3Rpdml0eSBhbmQg c2hvdWxkIGJlIHB1dCBkb3duLgo+ICA+Pgo+ICA+PiAgICAgICAgIChTb3VyY2UpCj4gID4+Cj4g aHR0cDovL3d3dy50dWVzZGF5bmlnaHQub3JnLzIwMTQvMDcvMjMvZG8td2UtaGF2ZS1hLXJvdW5k LXdoZWVsLXlldC1tdXNpbmdzLW9uLWlkZW50aXR5LXN0YW5kYXJkcy1wYXJ0LTEuaHRtbAo+ICA+ Pgo+ICA+Pgo+ICA+Pgo+ICA+PiAgICAgMjAxNC0wNy0yMyAxNjo1MyBHTVQtMDQ6MDAgSm9obiBC cmFkbGV5IDx2ZTdqdGJAdmU3anRiLmNvbQo+ICA+PiAgICAgPG1haWx0bzp2ZTdqdGJAdmU3anRi LmNvbT4+Ogo+ICA+Pgo+ICA+PiAgICAgICAgIEkgdGhvdWdodCBJIGRpZCBwb3N0IHRoaXMgdG8g dGhlIGxpc3QuCj4gID4+Cj4gID4+ICAgICAgICAgSSBndWVzcyBJIGhpdCB0aGUgd3JvbmcgcmVw bHkgb24gbXkgcGhvbmUuCj4gID4+ICAgICAgICAgSm9obiBCLgo+ICA+PiAgICAgICAgIFNlbnQg ZnJvbSBteSBpUGhvbmUKPiAgPj4KPiAgPj4gICAgICAgICBPbiBKdWwgMjMsIDIwMTQsIGF0IDQ6 NTAgUE0sIHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Cj4gID4+ICAgICAgICAgPG1haWx0bzp0b3Jz dGVuQGxvZGRlcnN0ZWR0Lm5ldD4gd3JvdGU6Cj4gID4+Cj4gID4+PiAgICAgICAgIHdlIGFyZSB0 d28sIGF0IGxlYXN0IDotKQo+ICA+Pj4KPiAgPj4+ICAgICAgICAgV2h5IGRpZG4ndCB5b3UgcG9z dCB0aGlzIG9uIHRoZSBsaXN0Pwo+ICA+Pj4KPiAgPj4+ICAgICAgICAgV2hlbiB3aWxsIGJlIGJl IGFycml2aW5nPwo+ICA+Pj4KPiAgPj4+ICAgICAgICAgQW0gMjMuMDcuMjAxNCAxNjozOSwgc2No cmllYiBKb2huIEJyYWRsZXk6Cj4gID4+Pgo+ICA+Pj4+ICAgICAgICAgSWFuIEdsYXplciBtZW50 aW9uZWQgdGhpcyBpbiBoaXMga2V5bm90ZSBhdCBDSVMgeWVzdGVyZGF5Lgo+ICA+Pj4+ICAgICAg ICAgSGlzIGFkdmljZSB3YXMgcGxlYXNlIHN0b3AsICB3ZSBhcmUgY3JlYXRpbmcgY29uZnVzaW9u IGFuZAo+ICA+Pj4+ICAgICAgICAgdW5jZXJ0YWludHkuCj4gID4+Pj4gICAgICAgICBXZSBhcmUg YmVjb21pbmcgb3VyIG93biB3b3J0IGVuZW15LiAoIG15IHZpZXcgdGhvdWdoIElhbiBtYXkKPiAg Pj4+PiAgICAgICAgIHNoYXJlIGl0KQo+ICA+Pj4+ICAgICAgICAgUmV0dXJuaW5nIGp1c3QgYW4g aWRfIHRva2VuIGZyb20gdGhlIHRva2VuIGVuZHBvaW50IGhhcwo+ICA+Pj4+ICAgICAgICAgbGl0 dGxlIHJlYWwgdmFsdWUuCj4gID4+Pj4gICAgICAgICBTb21ldGhpbmcgcmVhbGx5IHVzZWZ1bCB0 byBkbyB3b3VsZCBiZSBzb3J0aW5nIG91dAo+ICA+Pj4+ICAgICAgICAgY2hhbm5lbF9pZCBzbyB3 ZSBjYW4gZG8gUG9QIGZvciBpZCB0b2tlbnMgdG8gbWFrZSB0aGVtIGFuZAo+ICA+Pj4+ICAgICAg ICAgb3RoZXIgY29va2llcyBzZWN1cmUgaW4gdGhlIGZyb250IGNoYW5uZWwuICAgSSB0aGluayB0 aGF0IGlzCj4gID4+Pj4gICAgICAgICBhIGJldHRlciB1c2Ugb2YgdGltZS4KPiAgPj4+PiAgICAg ICAgIEkgbWF5IGJlIGluIHRoZSBtaW5vcml0eSBvcGluaW9uIG9uIHRoYXQsICBpdCB3b24ndCBi ZSB0aGUKPiAgPj4+PiAgICAgICAgIGZpcnN0IHRpbWUuCj4gID4+Pj4KPiAgPj4+Pgo+ICA+Pj4+ ICAgICAgICAgSm9obiBCLgo+ICA+Pj4+ICAgICAgICAgU2VudCBmcm9tIG15IGlQaG9uZQo+ICA+ Pj4+Cj4gID4+Pj4gICAgICAgICBPbiBKdWwgMjMsIDIwMTQsIGF0IDQ6MDQgUE0sIFRvcnN0ZW4g TG9kZGVyc3RlZHQKPiAgPj4+PiAgICAgICAgIDx0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldCA8bWFp bHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Pj4KPiAgPj4+PiAgICAgICAgIHdyb3RlOgo+ICA+ Pj4+Cj4gID4+Pj4+ICAgICAgICAgWW91IGFyZSByaWdodCBmcm9tIGEgdGhlb3JldGljYWwgcGVy c3BlY3RpdmUuIFByYWN0aWNhbGx5Cj4gID4+Pj4+ICAgICAgICAgdGhpcyB3YXMgY2F1c2VkIGJ5 IGVkaXRvcmlhbCBkZWNpc2lvbnMgZHVyaW5nIHRoZSBjcmVhdGlvbgo+ICA+Pj4+PiAgICAgICAg IG9mIHRoZSBSRkMuIEFzIGZhciBhcyBJIHJlbWVtYmVyLCB0aGVyZSB3YXMgYSBkZWZpbml0aW9u IG9mCj4gID4+Pj4+ICAgICAgICAgdGhlIChvbmUpIHRva2VuIGVuZHBvaW50IHJlc3BvbnNlIGlu IGVhcmx5IHZlcnNpb25zLiBObyBvbmUKPiAgPj4+Pj4gICAgICAgICBldmVyeSBjb25zaWRlcmVk IHRvIE5PVCByZXNwb25kIHdpdGggYW4gYWNjZXNzIHRva2VuIGZyb20KPiAgPj4+Pj4gICAgICAg ICB0aGUgdG9rZW4gZW5kcG9pbnQuIFNvIG9uZSBtaWdodCBjYWxsIGl0IGFuIGltcGxpY2l0Cj4g ID4+Pj4+ICAgICAgICAgYXNzdW1wdGlvbi4KPiAgPj4+Pj4gICAgICAgICBJJ20gd29ycmllZCB0 aGF0IHBlb3BsZSBnZXQgdG90YWxseSBjb25mdXNlZCBpZiBhbgo+ICA+Pj4+PiAgICAgICAgIGV4 Y2VwdGlvbiBpcyBpbnRyb2R1Y2VkIG5vdyBnaXZlbiB0aGUgYnJvYWQgYWRvcHRpb24gb2YKPiAg Pj4+Pj4gICAgICAgICBPQXV0aCBiYXNlZCBvbiB0aGlzIGFzc3VtcHRpb24uCj4gID4+Pj4+ICAg ICAgICAgcmVnYXJkcywKPiAgPj4+Pj4gICAgICAgICBUb3JzdGVuLgo+ICA+Pj4+Pgo+ICA+Pj4+ PiAgICAgICAgIEFtIDIzLjA3LjIwMTQgdW0gMTU6NDEgc2NocmllYiBUaG9tYXMgQnJveWVyCj4g ID4+Pj4+ICAgICAgICAgPHQuYnJveWVyQGdtYWlsLmNvbSA8bWFpbHRvOnQuYnJveWVyQGdtYWls LmNvbT4+Ogo+ICA+Pj4+Pgo+ICA+Pj4+Pj4gICAgICAgICBJcyBpdCBzYWlkIGFueXdoZXJlIHRo YXQgQUxMIGdyYW50IHR5cGVzIE1VU1QgdXNlIFNlY3Rpb24KPiAgPj4+Pj4+ICAgICAgICAgNS4x IHJlc3BvbnNlcz8gRWFjaCBncmFudCB0eXBlIHJlZmVyZW5jZXMgU2VjdGlvbiA1LjEsIGFuZAo+ ICA+Pj4+Pj4gICAgICAgICAiYWNjZXNzIHRva2VuIHJlcXVlc3QiIGlzIG9ubHkgZGVmaW5lZCBp biB0aGUgY29udGV4dCBvZgo+ICA+Pj4+Pj4gICAgICAgICB0aGUgZGVmaW5lZCBncmFudCB0eXBl cy4gU2VjdGlvbiAyLjIgZG9lc24ndCB0YWxrIGFib3V0Cj4gID4+Pj4+PiAgICAgICAgIHRoZSBy ZXF1ZXN0IG9yIHJlc3BvbnNlIGZvcm1hdC4KPiAgPj4+Pj4+Cj4gID4+Pj4+PiAgICAgICAgIExl IDIzIGp1aWwuIDIwMTQgMjE6MzIsICJOYXQgU2FraW11cmEiIDxzYWtpbXVyYUBnbWFpbC5jb20K PiAgPj4+Pj4+ICAgICAgICAgPG1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20+PiBhIMOpY3JpdCA6 Cj4gID4+Pj4+Pgo+ICA+Pj4+Pj4gICAgICAgICAgICAgSXMgaXQ/IEFwYXJ0IGZyb20gdGhlIGlt cGxpY2l0IGdyYW50IHRoYXQgZG9lcyBub3QgdXNlCj4gID4+Pj4+PiAgICAgICAgICAgICB0b2tl biBlbmRwb2ludCwgYWxsIG90aGVyIGdyYW50IHJlZmVyZW5jZXMgc2VjdGlvbiA1LjEKPiAgPj4+ Pj4+ICAgICAgICAgICAgIGZvciB0aGUgcmVzcG9uc2UsIGkuZS4sIGFsbCBzaGFyZXMgdGhlIHNh bWUgcmVzcG9uc2UuCj4gID4+Pj4+Pgo+ICA+Pj4+Pj4KPiAgPj4+Pj4+ICAgICAgICAgICAgIDIw MTQtMDctMjMgMTU6MTggR01ULTA0OjAwIFRob21hcyBCcm95ZXIKPiAgPj4+Pj4+ICAgICAgICAg ICAgIDx0LmJyb3llckBnbWFpbC5jb20gPG1haWx0bzp0LmJyb3llckBnbWFpbC5jb20+PjoKPiAg Pj4+Pj4+Cj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgSSBoYWRuJ3QgcmVhbGl6ZWQgdGhlIEpT T04gcmVzcG9uc2UgdGhhdCByZXF1aXJlcwo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgIHRoZSBh Y2Nlc3NfdG9rZW4gZmllbGQgaXMgZGVmaW5lZCBwZXIgZ3JhbnRfdHlwZSwKPiAgPj4+Pj4+ICAg ICAgICAgICAgICAgICBzbyBJJ2QgYmUgT0sgdG8gImV4dGVuZCB0aGUgc2VtYW50aWNzIiBhcyBp biB0aGUKPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICBjdXJyZW50IGRyYWZ0Lgo+ICA+Pj4+Pj4g ICAgICAgICAgICAgICAgIFRoYXQgd2FzIGFjdHVhbGx5IG15IG1haW4gY29uY2VybjogdGhhdCB0 aGUgdG9rZW4KPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICBlbmRwb2ludCBtYW5kYXRlcyBhY2Nl c3NfdG9rZW47IGJ1dCBpdHMgYWN0dWFsbHkKPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICBub3Qg dGhlIGNhc2UuCj4gID4+Pj4+Pgo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgIExlIDIzIGp1aWwu IDIwMTQgMjA6NDYsICJOYXQgU2FraW11cmEiCj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgPHNh a2ltdXJhQGdtYWlsLmNvbSA8bWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbT4+IGEKPiAgPj4+Pj4+ ICAgICAgICAgICAgICAgICDDqWNyaXQgOgo+ICA+Pj4+Pj4KPiAgPj4+Pj4+ICAgICAgICAgICAg ICAgICAgICAgSSBhZ3JlZSB3aXRoIEpvaG4gdGhhdCBvdmVybG9hZGluZwo+ICA+Pj4+Pj4gICAg ICAgICAgICAgICAgICAgICByZXNwb25zZV90eXBlIEAgYXV0aHogZW5kcG9pbnQgaXMgYSBiYWQg aWRlYS4KPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgSXQgY29tcGxldGVseSBjaGFuZ2Vz IHRoZSBzZW1hbnRpY3Mgb2YgdGhpcwo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICBwYXJh bWV0ZXIuIE5PVEU6IHdoYXQgSSB3YXMgcHJvcG9zaW5nIHdhcyBub3QKPiAgPj4+Pj4+ICAgICAg ICAgICAgICAgICAgICAgdGhpcyBwYXJhbWV0ZXIsIGJ1dCBhIG5ldyBwYXJhbWV0ZXIKPiAgPj4+ Pj4+ICAgICAgICAgICAgICAgICAgICAgcmVzcG9uc2VfdHlwZSBAIHRva2VuIGVuZHBvaW50Lgo+ ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICBJIGFsc28gdGhpbmsgb3ZlcmxvYWRpbmcgZ3Jh bnRfdHlwZSBpcyBhIGJhZAo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICBpZGVhIHNpbmNl IGl0IGNoYW5nZXMgaXRzIHNlbWFudGljcy4gSSBxdW90ZQo+ICA+Pj4+Pj4gICAgICAgICAgICAg ICAgICAgICB0aGUgZGVmaW5pdGlvbiBoZXJlIGFnYWluOgo+ICA+Pj4+Pj4gICAgICAgICAgICAg ICAgICAgICBncmFudAo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgY3JlZGVudGlh bCByZXByZXNlbnRpbmcgdGhlIHJlc291cmNlCj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAg IG93bmVyJ3MgYXV0aG9yaXphdGlvbgo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICBncmFu dF90eXBlCj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgIHR5cGUgb2YgZ3JhbnQgc2VudCB0 byB0aGUgdG9rZW4gZW5kcG9pbnQgdG8KPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgb2J0 YWluIHRoZSBhY2Nlc3MgdG9rZW4KPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgSXQgaXMg bm90IGFib3V0IGNvbnRyb2xsaW5nIHdoYXQgaXMgdG8gYmUKPiAgPj4+Pj4+ICAgICAgICAgICAg ICAgICAgICAgcmV0dXJuZWQgZnJvbSB0aGUgdG9rZW4gZW5kcG9pbnQsIGJ1dCB0aGUgaGludAo+ ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICB0byB0aGUgdG9rZW4gZW5kcG9pbnQgZGVzY3Jp YmluZyB0aGUgdHlwZSBvZgo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICBjcmVkZW50aWFs IHRoZSBlbmRwb2ludCBoYXMgcmVjZWl2ZWQuIEl0IHNlZW1zCj4gID4+Pj4+PiAgICAgICAgICAg ICAgICAgICAgIHRoZSAiY29udHJvbCBvZiB3aGF0IGlzIGJlaW5nIHJldHVybmVkIGZyb20KPiAg Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgdG9rZW4gZW5kcG9pbnQiICBpcyBqdXN0IGEgc2lk ZSBlZmZlY3QuCj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgIEkgYW0gc29tZXdoYXQgYW1i aXZhbGVudFsxXSBpbiBjaGFuZ2luZyB0aGUKPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAg c2VtYW50aWNzIG9mIHRva2VuIGVuZHBvaW50LCBidXQgaW4gYXMgbXVjaCBhcwo+ICA+Pj4+Pj4g ICAgICAgICAgICAgICAgICAgICAidGV4dCBpcyB0aGUga2luZyIgZm9yIGEgc3BlYy4sIHdlIHBy b2JhYmx5Cj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgIHNob3VsZCBub3QgY2hhbmdlIHRo ZSBzZW1hbnRpY3Mgb2YgaXQgYXMKPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgVG9yc3Rl biBwb2ludHMgb3V0LiBJZiBpdCBpcyBvayB0byBjaGFuZ2UgdGhpcwo+ICA+Pj4+Pj4gICAgICAg ICAgICAgICAgICAgICBzZW1hbnRpY3MsIEkgYmVsaWV2ZSBkZWZpbmluZyBhIG5ldyBwYXJhbWV0 ZXIKPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgdG8gdGhpcyBlbmRwb2ludCB0byBjb250 cm9sIHRoZSByZXNwb25zZSB3b3VsZAo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICBiZSB0 aGUgYmVzdCB3YXkgdG8gZ28uIFRoaXMgaXMgd2hhdCBJIGhhdmUKPiAgPj4+Pj4+ICAgICAgICAg ICAgICAgICAgICAgZGVzY3JpYmVkIHByZXZpb3VzbHkuCj4gID4+Pj4+PiAgICAgICAgICAgICAg ICAgICAgIERlZmluaW5nIGEgbmV3IGVuZHBvaW50IHRvIHNlbmQgY29kZSB0byBnZXQgSUQKPiAg Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgVG9rZW4gYW5kIGZvcmJpZGRpbmcgdGhlIHVzZSBv ZiBpdCBhZ2FpbnN0Cj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgIHRva2VuIGVuZHBvaW50 IHdvdWxkIG5vdCBjaGFuZ2UgdGhlIHNlbWFudGljcwo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAg ICAgICBvZiBhbnkgZXhpc3RpbmcgcGFyYW1ldGVyIG9yIGVuZHBvaW50LCB3aGljaAo+ICA+Pj4+ Pj4gICAgICAgICAgICAgICAgICAgICBpcyBnb29kLiBIb3dldmVyLCBJIGRvdWJ0IGlmIGl0IGlz IG5vdCB3b3J0aAo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICBkb2luZy4gV2hhdCdzIHRo ZSBwb2ludCBvZiBhdm9pZGluZyBhY2Nlc3MKPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAg dG9rZW4gc2NvcGVkIHRvIFVzZXJJbmZvIGVuZHBvaW50IGFmdGVyIGFsbD8KPiAgPj4+Pj4+ICAg ICAgICAgICAgICAgICAgICAgRGVmaW5pbmcgYSBuZXcgZW5kcG9pbnQgZm9yIGp1c3QgYXZvaWRp bmcgdGhlCj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgIGFjY2VzcyB0b2tlbiBmb3IgdXNl cmluZm8gZW5kcG9pbnQgc2VlbXMgd2F5Cj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgIHRv byBtdWNoIHRoZSBoZWF2eSB3YWl0IHdheSBhbmQgaXQgYnJlYWtzCj4gID4+Pj4+PiAgICAgICAg ICAgICAgICAgICAgIGludGVyb3BlcmFiaWxpeTogaXQgZGVmZWF0cyB0aGUgcHVycG9zZSBvZgo+ ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICBzdGFuZGFyZGl6YXRpb24uCj4gID4+Pj4+PiAg ICAgICAgICAgICAgICAgICAgIEkgaGF2ZSBzdGFydGVkIGZlZWxpbmcgdGhhdCBubyBjaGFuZ2Ug aXMgdGhlCj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgIGJlc3Qgd2F5IG91dC4KPiAgPj4+ Pj4+ICAgICAgICAgICAgICAgICAgICAgTmF0Cj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAg IFsxXSAgSWYgaW5zdGVhZCBvZiBzYXlpbmcgIlRva2VuIGVuZHBvaW50IC0KPiAgPj4+Pj4+ICAg ICAgICAgICAgICAgICAgICAgdXNlZCBieSB0aGUgY2xpZW50IHRvIGV4Y2hhbmdlIGFuCj4gID4+ Pj4+PiAgICAgICAgICAgICAgICAgICAgIGF1dGhvcml6YXRpb24gZ3JhbnQgZm9yIGFuIGFjY2Vz cyB0b2tlbiwKPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgdHlwaWNhbGx5IHdpdGggY2xp ZW50IGF1dGhlbnRpY2F0aW9uIiwgaXQgd2VyZQo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAg ICBzYXlpbmcgIlRva2VuIGVuZHBvaW50IC0gdXNlZCBieSB0aGUgY2xpZW50IHRvCj4gID4+Pj4+ PiAgICAgICAgICAgICAgICAgICAgIGV4Y2hhbmdlIGFuIGF1dGhvcml6YXRpb24gZ3JhbnQgZm9y IHRva2VucywKPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgdHlwaWNhbGx5IHdpdGggY2xp ZW50IGF1dGhlbnRpY2F0aW9uIiwgdGhlbiBpdAo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAg ICB3b3VsZCBoYXZlIGJlZW4gT0suIEl0IGlzIGFuIGV4cGFuc2lvbiBvZiB0aGUKPiAgPj4+Pj4+ ICAgICAgICAgICAgICAgICAgICAgY2FwYWJpbGl0eSByYXRoZXIgdGhhbiBjaGFuZ2luZyB0aGUg c2VtYW50aWNzLgo+ICA+Pj4+Pj4KPiAgPj4+Pj4+Cj4gID4+Pj4+PiAgICAgICAgICAgICAgICAg ICAgIDIwMTQtMDctMjMgMTM6MzkgR01ULTA0OjAwIE1pa2UgSm9uZXMKPiAgPj4+Pj4+ICAgICAg ICAgICAgICAgICAgICAgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbQo+ICA+Pj4+Pj4gICAg ICAgICAgICAgICAgICAgICA8bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+Ogo+ ICA+Pj4+Pj4KPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgIFlvdSBuZWVkIHRoZSBh bHRlcm5hdGl2ZSByZXNwb25zZV90eXBlCj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAg ICB2YWx1ZSAoImNvZGVfZm9yX2lkX3Rva2VuIiBpbiB0aGUgQTRDCj4gID4+Pj4+PiAgICAgICAg ICAgICAgICAgICAgICAgICBkcmFmdCkgdG8gdGVsbCB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIg dG8KPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgIHJldHVybiBhIGNvZGUgdG8gYmUg dXNlZCB3aXRoIHRoZSBuZXcKPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgIGdyYW50 IHR5cGUsIHJhdGhlciB0aGFuIG9uZSB0byB1c2Ugd2l0aAo+ICA+Pj4+Pj4gICAgICAgICAgICAg ICAgICAgICAgICAgdGhlICJhdXRob3JpemF0aW9uX2NvZGUiIGdyYW50IHR5cGUgKHdoaWNoCj4g ID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICBpcyB3aGF0IHJlc3BvbnNlX3R5cGU9Y29k ZSBkb2VzKS4KPiAgPj4+Pj4+Cj4gID4+Pj4+Pgo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAg ICAgICAgKkZyb206Kk9BdXRoCj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICBbbWFp bHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcKPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAg ICAgIDxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZz5dICpPbgo+ICA+Pj4+Pj4gICAgICAg ICAgICAgICAgICAgICAgICAgQmVoYWxmIE9mICpKb2huIEJyYWRsZXkKPiAgPj4+Pj4+ICAgICAg ICAgICAgICAgICAgICAgICAgICpTZW50OiogV2VkbmVzZGF5LCBKdWx5IDIzLCAyMDE0IDEwOjMz IEFNCj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAqVG86KiB0b3JzdGVuQGxvZGRl cnN0ZWR0Lm5ldAo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgPG1haWx0bzp0b3Jz dGVuQGxvZGRlcnN0ZWR0Lm5ldD4KPiAgPj4+Pj4+Cj4gID4+Pj4+Pgo+ICA+Pj4+Pj4gICAgICAg ICAgICAgICAgICAgICAgICAgKkNjOiogb2F1dGhAaWV0Zi5vcmcgPG1haWx0bzpvYXV0aEBpZXRm Lm9yZz4KPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICpTdWJqZWN0OiogUmU6IFtP QVVUSC1XR10gTmV3IFZlcnNpb24KPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgIE5v dGlmaWNhdGlvbiBmb3IKPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgIGRyYWZ0LWh1 bnQtb2F1dGgtdjItdXNlci1hNGMtMDUudHh0Cj4gID4+Pj4+Pgo+ICA+Pj4+Pj4KPiAgPj4+Pj4+ ICAgICAgICAgICAgICAgICAgICAgICAgIElmIHdlIHVzZSB0aGUgdG9rZW4gZW5kcG9pbnQgdGhl biBhIG5ldwo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgZ3JhbnRfdHlwZSBpcyB0 aGUgYmVzdCB3YXkuCj4gID4+Pj4+Pgo+ICA+Pj4+Pj4KPiAgPj4+Pj4+ICAgICAgICAgICAgICAg ICAgICAgICAgIEl0IHNvcnQgb2Ygb3ZlcmxvYWRzIGNvZGUsIGJ1dCB0aGF0IGlzCj4gID4+Pj4+ PiAgICAgICAgICAgICAgICAgICAgICAgICBiZXR0ZXIgdGhhbiBtZXNzaW5nIHdpdGggcmVzcG9u c2VfdHlwZSBmb3IKPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgIHRoZSBhdXRob3Jp emF0aW9uIGVuZHBvaW50IHRvIGNoYW5nZSB0aGUKPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAg ICAgICAgIHJlc3BvbnNlIGZyb20gdGhlIHRva2VuX2VuZHBvaW50LiAgVGhhdCBpcwo+ICA+Pj4+ Pj4gICAgICAgICAgICAgICAgICAgICAgICAgaW4gbXkgb3BpbmlvbiBhIGNoYW1waW9uIGJhZCBp ZGVhLgo+ICA+Pj4+Pj4KPiAgPj4+Pj4+Cj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAg ICBJbiBkaXNjdXNzaW9ucyBkZXZlbG9waW5nIENvbm5lY3Qgd2UKPiAgPj4+Pj4+ICAgICAgICAg ICAgICAgICAgICAgICAgIGRlY2lkZWQgbm90IHRvIG9wZW4gdGhpcyBjYW4gb2Ygd29ybXMKPiAg Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgIGJlY2F1c2Ugbm8gZ29vZCB3b3VsZCBjb21l IG9mIGl0Lgo+ICA+Pj4+Pj4KPiAgPj4+Pj4+Cj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAg ICAgICBUaGUgdG9rZW5fZW5kcG9pbnQgcmV0dXJucyBhIGFjY2VzcyB0b2tlbi4KPiAgPj4+Pj4+ ICAgICAgICAgICAgICAgICAgICAgICAgICBOb3RoaW5nIHJlcXVpcmVzIHNjb3BlIHRvIGJlIGFz c29jaWF0ZXMKPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgIHdpdGggdGhlIHRva2Vu Lgo+ICA+Pj4+Pj4KPiAgPj4+Pj4+Cj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICBU aGF0IGlzIHRoZSBiZXN0IHNvbHV0aW9uLiAgTm8gY2hhbmdlCj4gID4+Pj4+PiAgICAgICAgICAg ICAgICAgICAgICAgICByZXF1aXJlZC4gIEJldHRlciBpbnRlcm9wZXJhYmlsaXR5IGluIG15Cj4g ID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICBvcGluaW9uLgo+ICA+Pj4+Pj4KPiAgPj4+ Pj4+Cj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICBTdGlsbCBvbiBteSB3YXkgdG8g VE8sIGdldHRpbmcgaW4gbGF0ZXIKPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgIHRv ZGF5Lgo+ICA+Pj4+Pj4KPiAgPj4+Pj4+Cj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAg ICBKb2huIEIuCj4gID4+Pj4+Pgo+ICA+Pj4+Pj4KPiAgPj4+Pj4+Cj4gID4+Pj4+Pgo+ICA+Pj4+ Pj4gICAgICAgICAgICAgICAgICAgICAgICAgU2VudCBmcm9tIG15IGlQaG9uZQo+ICA+Pj4+Pj4K PiAgPj4+Pj4+Cj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICBPbiBKdWwgMjMsIDIw MTQsIGF0IDEyOjE1IFBNLAo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgdG9yc3Rl bkBsb2RkZXJzdGVkdC5uZXQKPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgIDxtYWls dG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+IHdyb3RlOgo+ICA+Pj4+Pj4KPiAgPj4+Pj4+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBUaGUgInJlc3BvbnNlIHR5cGUiIG9mIHRoZSB0b2tl bgo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIGVuZHBvaW50IGlzIGNvbnRy b2xsZWQgYnkgdGhlIHZhbHVlIG9mCj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgdGhlIHBhcmFtZXRlciAiZ3JhbnRfdHlwZSIuIFNvIHRoZXJlCj4gID4+Pj4+PiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgaXMgbm8gbmVlZCB0byBpbnRyb2R1Y2UgYSBuZXcgcGFyYW1l dGVyLgo+ICA+Pj4+Pj4KPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB3cnQg dG8gYSBwb3RlbnRpYWwgIm5vX2FjY2Vzc190b2tlbiIKPiAgPj4+Pj4+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBncmFudCB0eXBlLiBJIGRvIG5vdCBjb25zaWRlciB0aGlzIGEKPiAgPj4+ Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBnb29kIGlkZWEgYXMgaXQgY2hhbmdlcyB0 aGUgc2VtYW50aWNzCj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgb2YgdGhl IHRva2VuIGVuZHBvaW50IChhcyBhbHJlYWR5Cj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgcG9pbnRlZCBvdXQgYnkgVGhvbWFzKS4gVGhpcyBlbmRwb2ludAo+ICA+Pj4+Pj4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFMV0FZUyByZXNwb25kcyB3aXRoIGFuIGFjY2Vz cyB0b2tlbgo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRvIGFueSBncmFu dCB0eXBlLiBJIHRoZXJlZm9yZSB3b3VsZAo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHByZWZlciB0byB1c2UgYW5vdGhlciBlbmRwb2ludCBmb3IgdGhlCj4gID4+Pj4+PiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgaW50ZW5kZWQgcHVycG9zZS4KPiAgPj4+Pj4+Cj4g ID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcmVnYXJkcywKPiAgPj4+Pj4+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBUb3JzdGVuLgo+ICA+Pj4+Pj4KPiAgPj4+Pj4+Cj4g ID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQW0gMjMuMDcuMjAxNCAxMzowNCwg c2NocmllYiBOYXQKPiBTYWtpbXVyYToKPiAgPj4+Pj4+Cj4gID4+Pj4+PiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIElNSE8sIGNoYW5naW5nIHRoZSBzZW1hbnRpY3Mgb2YKPiAgPj4+ Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgInJlc3BvbnNlX3R5cGUiIEAgYXV0 aHogZW5kcG9pbnQKPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhp cyB3YXkgaXMgbm90IGEgZ29vZCB0aGluZy4KPiAgPj4+Pj4+Cj4gID4+Pj4+Pgo+ICA+Pj4+Pj4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJbnN0ZWFkLCBkZWZpbmluZyBhIG5ldyBw YXJhbWV0ZXIKPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgInJlc3Bv bnNlX3R5cGUiIEAgdG9rZW4gZW5kcG9pbnQsCj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIGFzIEkgZGVzY3JpYmVkIGluIG15IHByZXZpb3VzCj4gID4+Pj4+PiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1lc3NhZ2UsCj4gID4+Pj4+Pgo+ICA+Pj4+Pj4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBwcm9iYWJseSBpcyBiZXR0ZXIuIEF0IGxl YXN0LCBpdAo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkb2VzIG5v dCBjaGFuZ2UgdGhlIHNlbWFudGljcyBvZgo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB0aGUgcGFyYW1ldGVycyBvZiBSRkM2NzQ5Lgo+ICA+Pj4+Pj4KPiAgPj4+Pj4+ Cj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBOYXQKPiAgPj4+Pj4+ Cj4gID4+Pj4+Pgo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAyMDE0 LTA3LTIzIDEyOjQ4IEdNVC0wNDowMCBUaG9tYXMKPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgQnJveWVyIDx0LmJyb3llckBnbWFpbC5jb20KPiAgPj4+Pj4+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgPG1haWx0bzp0LmJyb3llckBnbWFpbC5jb20+PjoK PiAgPj4+Pj4+Cj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE5vLCBJ IG1lYW4gcmVzcG9uc2VfdHlwZT1ub25lIGFuZAo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICByZXNwb25zZV90eXBlPWlkX3Rva2VuIGRvbid0Cj4gID4+Pj4+PiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGdlbmVyYXRlIGEgY29kZSBvciBhY2Nlc3MgdG9r ZW4gc28KPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgeW91IGRvbid0 IHVzZSB0aGUgVG9rZW4gRW5kcG9pbnQKPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgKHdoaWNoIGlzIG5vdCB0aGUgc2FtZSBhcyB0aGUKPiAgPj4+Pj4+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgQXV0aGVudGljYXRpb24gRW5kcG9pbnQgQlRXKS4KPiAg Pj4+Pj4+Cj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFdpdGgKPiAg Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcmVzcG9uc2VfdHlwZT1jb2Rl X2Zvcl9pZF90b2tlbiwKPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg eW91IGdldCBhIGNvZGUgYW5kIGV4Y2hhbmdlIGl0IGZvcgo+ICA+Pj4+Pj4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBhbiBpZF90b2tlbiBvbmx5LCByYXRoZXIgdGhhbiBhbgo+ICA+ Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhY2Nlc3NfdG9rZW4sIHNvIHlv dSdyZSBjaGFuZ2luZwo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0 aGUgc2VtYW50aWNzIG9mIHRoZSBUb2tlbiBFbmRwb2ludC4KPiAgPj4+Pj4+Cj4gID4+Pj4+Pgo+ ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJJ20gbm90IHNheWluZyBp dCdzIGEgYmFkIHRoaW5nLAo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBqdXN0IHRoYXQgeW91IGNhbid0IHJlYWxseSBjb21wYXJlCj4gID4+Pj4+PiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIG5vbmUgYW5kIGlkX3Rva2VuIHdpdGgKPiAgPj4+Pj4+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29kZV9mb3JfaWRfdG9rZW4uCj4gID4+Pj4+ Pgo+ICA+Pj4+Pj4KPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgT24g V2VkLCBKdWwgMjMsIDIwMTQgYXQgNjo0NSBQTSwKPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgUmljaGVyLCBKdXN0aW4gUC4KPiAgPj4+Pj4+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgPGpyaWNoZXJAbWl0cmUub3JnCj4gID4+Pj4+PiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIDxtYWlsdG86anJpY2hlckBtaXRyZS5vcmc+PiB3cm90ZToK PiAgPj4+Pj4+Cj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEl0J3Mg b25seSAibm90IHVzaW5nIHRoZSB0b2tlbgo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBlbmRwb2ludCIgYmVjYXVzZSB0aGUgdG9rZW4KPiAgPj4+Pj4+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgZW5kcG9pbnQgY29weS1wYXN0ZWQgYW5kIHJlbmFtZWQK PiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhlIGF1dGhlbnRpY2F0 aW9uIGVuZHBvaW50Lgo+ICA+Pj4+Pj4KPiAgPj4+Pj4+Cj4gID4+Pj4+PiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAtLSBKdXN0aW4KPiAgPj4+Pj4+Cj4gID4+Pj4+Pgo+ICA+Pj4+ Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBPbiBKdWwgMjMsIDIwMTQsIGF0IDk6 MzAgQU0sCj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRob21hcyBC cm95ZXIgPHQuYnJveWVyQGdtYWlsLmNvbQo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICA8bWFpbHRvOnQuYnJveWVyQGdtYWlsLmNvbT4+IHdyb3RlOgo+ICA+Pj4+Pj4K PiAgPj4+Pj4+Cj4gID4+Pj4+Pgo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBFeGNlcHQgdGhhdCB0aGVzZSBhcmUgYWJvdXQgbm90Cj4gID4+Pj4+PiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHVzaW5nIHRoZSBUb2tlbiBFbmRwb2ludCBhdCBhbGwsCj4g ID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdoZXJlYXMgdGhlIGN1cnJl bnQgcHJvcG9zYWwgaXMKPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg YWJvdXQgdGhlIFRva2VuIEVuZHBvaW50IG5vdAo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICByZXR1cm5pbmcgYW4gYWNjZXNzX3Rva2VuIGZpZWxkIGluCj4gID4+Pj4+ PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoZSBKU09OLgo+ICA+Pj4+Pj4KPiAg Pj4+Pj4+Cj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE9uIFdlZCwg SnVsIDIzLCAyMDE0IGF0IDQ6MjYgUE0sCj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIE1pa2UgSm9uZXMKPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbQo+ICA+Pj4+Pj4KPiA8bWFpbHRvOk1p Y2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+Cj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHdyb3RlOgo+ICA+Pj4+Pj4KPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgVGhlIHJlc3BvbnNlX3R5cGUgIm5vbmUiIGlzCj4gID4+Pj4+PiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFscmVhZHkgdXNlZCBpbiBwcmFjdGljZSwgd2hp Y2gKPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcmV0dXJucyBubyBh Y2Nlc3MgdG9rZW4uICBJdCB3YXMKPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgYWNjZXB0ZWQgYnkgdGhlIGRlc2lnbmF0ZWQgZXhwZXJ0cwo+ICA+Pj4+Pj4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBhbmQgcmVnaXN0ZXJlZCBpbiB0aGUgSUFOQSBPQXV0 aAo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBdXRob3JpemF0aW9u IEVuZHBvaW50IFJlc3BvbnNlCj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIFR5cGVzIHJlZ2lzdHJ5IGF0Cj4gID4+Pj4+Pgo+IGh0dHA6Ly93d3cuaWFuYS5vcmcvYXNz aWdubWVudHMvb2F1dGgtcGFyYW1ldGVycy9vYXV0aC1wYXJhbWV0ZXJzLnhtbCNlbmRwb2ludAo+ ICA+Pj4+Pj4KPiA8aHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9vYXV0aC1wYXJhbWV0 ZXJzL29hdXRoLXBhcmFtZXRlcnMueG1sI2VuZHBvaW50Pi4KPiAgPj4+Pj4+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgVGhlIHJlZ2lzdGVyZWQgImlkX3Rva2VuIiByZXNwb25zZQo+ ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0eXBlIGFsc28gcmV0dXJu cyBubyBhY2Nlc3MgdG9rZW4uCj4gID4+Pj4+Pgo+ICA+Pj4+Pj4KPiAgPj4+Pj4+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgU28gSSB0aGluayB0aGUgcXVlc3Rpb24gb2Ygd2hldGhl cgo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICByZXNwb25zZSB0eXBl cyB0aGF0IHJlc3VsdCBpbiBubwo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBhY2Nlc3MgdG9rZW4gYmVpbmcgcmV0dXJuZWQgYXJlCj4gID4+Pj4+PiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIGFjY2VwdGFibGUgd2l0aGluIE9BdXRoIDIuMCBpcwo+ICA+ Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhbHJlYWR5IHNldHRsZWQsIGFz IGEgcHJhY3RpY2FsCj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1h dHRlci4gIExvdHMgb2YgT0F1dGgKPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgaW1wbGVtZW50YXRpb25zIGFyZSBhbHJlYWR5IHVzaW5nCj4gID4+Pj4+PiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHN1Y2ggcmVzcG9uc2UgdHlwZXMuCj4gID4+Pj4+Pgo+ ICA+Pj4+Pj4KPiAgPj4+Pj4+Cj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIC0tIE1pa2UKPiAgPj4+Pj4+Cj4gID4+Pj4+Pgo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAqRnJvbToqT0F1dGgKPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnCj4gID4+Pj4+PiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRm Lm9yZz5dCj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICpPbiBCZWhh bGYgT2YgKlBoaWwgSHVudAo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAqU2VudDoqIFdlZG5lc2RheSwgSnVseSAyMywgMjAxNAo+ICA+Pj4+Pj4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICA3OjA5IEFNCj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICpUbzoqIE5hdCBTYWtpbXVyYQo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAqQ2M6KiA8b2F1dGhAaWV0Zi5vcmcKPiAgPj4+Pj4+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+Cj4gID4+Pj4+ PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICpTdWJqZWN0OiogUmU6IFtPQVVUSC1X R10gTmV3Cj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFZlcnNpb24g Tm90aWZpY2F0aW9uIGZvcgo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBkcmFmdC1odW50LW9hdXRoLXYyLXVzZXItYTRjLTA1LnR4dAo+ICA+Pj4+Pj4KPiAgPj4+Pj4+ Cj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFllcy4gVGhpcyBpcyB3 aHkgaXQgaGFzIHRvIGJlCj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IGRpc2N1c3NlZCBpbiB0aGUgSUVURi4KPiAgPj4+Pj4+Cj4gID4+Pj4+Pgo+ICA+Pj4+Pj4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBQaGlsCj4gID4+Pj4+Pgo+ICA+Pj4+Pj4KPiAg Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQGluZGVwZW5kZW50aWQKPiAg Pj4+Pj4+Cj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHd3dy5pbmRl cGVuZGVudGlkLmNvbQo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8 aHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNvbS8+Cj4gID4+Pj4+Pgo+ICA+Pj4+Pj4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBwaGlsLmh1bnRAb3JhY2xlLmNvbQo+ICA+Pj4+Pj4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUu Y29tPgo+ICA+Pj4+Pj4KPiAgPj4+Pj4+Cj4gID4+Pj4+Pgo+ICA+Pj4+Pj4KPiAgPj4+Pj4+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgT24gSnVsIDIzLCAyMDE0LCBhdCA5OjQzIEFN LCBOYXQKPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU2FraW11cmEg PHNha2ltdXJhQGdtYWlsLmNvbQo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICA8bWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbT4+IHdyb3RlOgo+ICA+Pj4+Pj4KPiAgPj4+ Pj4+Cj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJlYWRpbmcgYmFj ayB0aGUgUkZDNjc0OSwgSSBhbSBub3QKPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgc3VyZSBpZiB0aGVyZSBpcyBhIGdvb2Qgd2F5IG9mCj4gID4+Pj4+PiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHN1cHByZXNzaW5nIGFjY2VzcyB0b2tlbiBmcm9tIHRo ZQo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICByZXNwb25zZSBhbmQg c3RpbGwgYmUgT0F1dGguIEl0Cj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHdpbGwgYnJlYWsgd2hvbGUgYnVuY2ggb2YgaW1wbGljaXQKPiAgPj4+Pj4+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgZGVmaW5pdGlvbnMgbGlrZToKPiAgPj4+Pj4+Cj4gID4+ Pj4+Pgo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhdXRob3JpemF0 aW9uIHNlcnZlcgo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBUaGUgc2VydmVyIGlzc3VpbmcgYWNjZXNzCj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHRva2VucyB0byB0aGUgY2xpZW50IGFmdGVyCj4gID4+Pj4+PiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHN1Y2Nlc3NmdWxseQo+ICA+Pj4+Pj4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhdXRoZW50aWNhdGluZyB0aGUgcmVzb3VyY2UK PiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgb3duZXIgYW5kIG9idGFp bmluZyBhdXRob3JpemF0aW9uLgo+ICA+Pj4+Pj4KPiAgPj4+Pj4+Cj4gID4+Pj4+PiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIEFmdGVyIGFsbCwgT0F1dGggaXMgYWxsIGFib3V0Cj4g ID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGlzc3VpbmcgYWNjZXNzIHRv a2Vucy4KPiAgPj4+Pj4+Cj4gID4+Pj4+Pgo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBBbHNvLCBJIHRha2UgYmFjayBteSBzdGF0ZW1lbnQgb24KPiAgPj4+Pj4+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhlIGdyYW50IHR5cGUgaW4gbXkgcHJldmlv dXMgbWFpbC4KPiAgPj4+Pj4+Cj4gID4+Pj4+Pgo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBUaGUgZGVmaW5pdGlvbiBvZiBncmFudCBhbmQKPiAgPj4+Pj4+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgZ3JhbnRfdHlwZSBhcmUgcmVzcGVjdGl2ZWx5Ogo+ ICA+Pj4+Pj4KPiAgPj4+Pj4+Cj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIGdyYW50Cj4gID4+Pj4+Pgo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgY3JlZGVudGlhbCByZXByZXNlbnRpbmcgdGhlCj4gID4+Pj4+PiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHJlc291cmNlIG93bmVyJ3MgYXV0aG9yaXphdGlvbgo+ICA+ Pj4+Pj4KPiAgPj4+Pj4+Cj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IGdyYW50X3R5cGUKPiAgPj4+Pj4+Cj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAoc3RyaW5nIHJlcHJlc2VudGluZyB0aGUpIHR5cGUKPiAgPj4+Pj4+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgb2YgZ3JhbnQgc2VudCB0byB0aGUgdG9rZW4KPiAg Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZW5kcG9pbnQgdG8gb2J0YWlu IHRoZSBhY2Nlc3MgdG9rZW4KPiAgPj4+Pj4+Cj4gID4+Pj4+Pgo+ICA+Pj4+Pj4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBUaHVzLCB0aGUgZ3JhbnQgc2VudCB0byB0aGUgdG9rZW4K PiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZW5kcG9pbnQgaW4gdGhp cyBjYXNlIGlzIHN0aWxsCj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICdjb2RlJy4KPiAgPj4+Pj4+Cj4gID4+Pj4+Pgo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBSZXNwb25zZSB0eXBlIG9uIHRoZSBvdGhlciBoYW5kIGlzCj4gID4+Pj4+ PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG5vdCBzbyB3ZWxsIGRlZmluZWQgaW4g UkZDNjc0OSwKPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYnV0IGl0 IHNlZW1zIGl0IGlzIHJlcHJlc2VudGluZwo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB3aGF0IGlzIHRvIGJlIHJldHVybmVkIGZyb20gdGhlCj4gID4+Pj4+PiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGF1dGhvcml6YXRpb24gZW5kcG9pbnQuIFRvIGV4 cHJlc3MKPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgd2hhdCBpcyB0 byBiZSByZXR1cm5lZCBmcm9tIHRva2VuCj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGVuZHBvaW50LCBwZXJoYXBzIGRlZmluaW5nIGEgbmV3Cj4gID4+Pj4+PiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHBhcmFtZXRlciB0byB0aGUgdG9rZW4gZW5kcG9p bnQsCj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdoaWNoIGlzIGEg cGFyYWxsZWwgdG8gdGhlCj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHJlc3BvbnNlX3R5cGUgdG8gdGhlIEF1dGhvcml6YXRpb24KPiAgPj4+Pj4+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgRW5kcG9pbnQgc2VlbXMgdG8gYmUgYSBtb3JlCj4gID4+Pj4+ PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN5bW1ldHJpYyB3YXksIHRob3VnaCBJ IGFtIG5vdAo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdXJlIGF0 IGFsbCBpZiB0aGF0IGlzIGdvaW5nIHRvIGJlCj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIE9BdXRoIGFueSBtb3JlLiBPbmUgc3RyYXctbWFuIGlzCj4gID4+Pj4+PiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRvIGRlZmluZSBhIG5ldyBwYXJhbWV0ZXIg Y2FsbGVkCj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJlc3BvbnNl X3R5cGUgdG8gdGhlIHRva2VuCj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIGVuZHBvaW50IHN1Y2ggYXM6Cj4gID4+Pj4+Pgo+ICA+Pj4+Pj4KPiAgPj4+Pj4+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgcmVzcG9uc2VfdHlwZQo+ICA+Pj4+Pj4KPiAgPj4+ Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE9QVElPTkFMLiBBIHN0cmlu Zwo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICByZXByZXNlbnRpbmcg d2hhdCBpcyB0byBiZQo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBy ZXR1cm5lZCBmcm9tIHRoZSB0b2tlbiBlbmRwb2ludC4KPiAgPj4+Pj4+Cj4gID4+Pj4+Pgo+ICA+ Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBUaGVuIGRlZmluZSB0aGUgYmVo YXZpb3Igb2YgdGhlCj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGVu ZHBvaW50IGFjY29yZGluZyB0byB0aGUgdmFsdWVzCj4gID4+Pj4+PiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIGFzIHRoZSBwYXJhbGxlbCB0byB0aGUKPiAgPj4+Pj4+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgbXVsdGktcmVzcG9uc2UgdHlwZSBzcGVjLgo+ICA+Pj4+ Pj4KPiAgPj4+Pj4+Cj4gaHR0cDovL29wZW5pZC5uZXQvc3BlY3Mvb2F1dGgtdjItbXVsdGlwbGUt cmVzcG9uc2UtdHlwZXMtMV8wLmh0bWwKPiAgPj4+Pj4+Cj4gID4+Pj4+Pgo+ICA+Pj4+Pj4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBOYXQKPiAgPj4+Pj4+Cj4gID4+Pj4+Pgo+ICA+ Pj4+Pj4KPiAgPj4+Pj4+Cj4gID4+Pj4+Pgo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAyMDE0LTA3LTIzIDc6MjEgR01ULTA0OjAwIFBoaWwKPiAgPj4+Pj4+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgSHVudCA8cGhpbC5odW50QG9yYWNsZS5jb20KPiAg Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPG1haWx0bzpwaGlsLmh1bnRA b3JhY2xlLmNvbT4+Ogo+ICA+Pj4+Pj4KPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgVGhlIGRyYWZ0IGlzIHZlcnkgY2xlYXIuCj4gID4+Pj4+Pgo+ICA+Pj4+Pj4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBQaGlsCj4gID4+Pj4+Pgo+ICA+Pj4+Pj4KPiAg Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgT24gSnVsIDIzLCAyMDE0LCBh dCAwOjQ2LCBOYXQKPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU2Fr aW11cmEgPHNha2ltdXJhQGdtYWlsLmNvbQo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICA8bWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbT4+IHdyb3RlOgo+ICA+Pj4+Pj4K PiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRoZSBuZXcgZ3Jh bnQgdHlwZSB0aGF0IEkgd2FzCj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB0YWxraW5nIGFib3V0IHdhcwo+ICA+Pj4+Pj4KPiAgPj4+Pj4+Cj4gImF1dGhvcml6 YXRpb25fY29kZV9idXRfZG9fbm90X3JldHVybl9hY2Nlc3Nfbm9yX3JlZnJlc2hfdG9rZW4iLAo+ ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc28gdG8gc3BlYWsu Cj4gID4+Pj4+Pgo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg SXQgZG9lcyBub3QgcmV0dXJuIGFueXRoaW5nCj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBwZXIgc2UsIGJ1dCBhbiBleHRlbnNpb24gY2FuCj4gID4+Pj4+PiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkZWZpbmUgc29tZXRoaW5nIG9uIHRv cCBvZiBpdC4KPiAgPj4+Pj4+Cj4gID4+Pj4+Pgo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgVGhlbiwgT0lEQyBjYW4gZGVmaW5lIGEKPiAgPj4+Pj4+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGJpbmRpbmcgdG8gaXQgc28gdGhhdCB0aGUK PiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGJpbmRpbmcgb25s eSByZXR1cm5zIElEIFRva2VuLgo+ICA+Pj4+Pj4KPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIFRoaXMgYmluZGluZyB3b3JrIHNob3VsZCBiZQo+ICA+Pj4+Pj4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZG9uZSBpbiBPSURGLiBTaG91bGQg dGhlcmUgYmUKPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN1 Y2ggYSBncmFudCB0eXBlLAo+ICA+Pj4+Pj4KPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIGl0IHdpbGwgYmUgYW4gZXh0cmVtZWx5IHNob3J0Cj4gID4+Pj4+PiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzcGVjLgo+ICA+Pj4+Pj4KPiAgPj4+ Pj4+Cj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBdCB0aGUg c2FtZSB0aW1lLCBpZiBhbnkgb3RoZXIKPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHNwZWNpZmljYXRpb24gd2FudGVkIHRvIGRlZmluZQo+ICA+Pj4+Pj4KPiAg Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG90aGVyIHR5cGUgb2Yg dG9rZW5zIGFuZCBoYXZlCj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBpdCByZXR1cm5lZCBmcm9tIHRoZSB0b2tlbgo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgZW5kcG9pbnQsCj4gID4+Pj4+Pgo+ICA+Pj4+Pj4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaXQgY2FuIGFsc28gdXNlIHRoaXMgZ3JhbnQg dHlwZS4KPiAgPj4+Pj4+Cj4gID4+Pj4+Pgo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgSWYgd2hhdCB5b3Ugd2FudCBpcyB0byBkZWZpbmUKPiAgPj4+Pj4+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGEgbmV3IGdyYW50IHR5cGUgdGhhdCBy ZXR1cm5zCj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJRCBU b2tlbiBvbmx5LAo+ICA+Pj4+Pj4KPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHRoZW4sIEkgYW0gd2l0aCBKdXN0aW4uIFNpbmNlCj4gID4+Pj4+PiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAib3RoZXIgcmVzcG9uc2UgdGhhbiBJRCBUb2tl biIKPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGlzIG9ubHkK PiAgPj4+Pj4+Cj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0 aGVvcmV0aWNhbCwgdGhpcyBpcyBhIG1vcmUKPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHBsYXVzaWJsZSB3YXkgZm9yd2FyZCwgSQo+IHN1cHBvc2UuCj4gID4+ Pj4+Pgo+ICA+Pj4+Pj4KPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIE5hdAo+ICA+Pj4+Pj4KPiAgPj4+Pj4+Cj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAyMDE0LTA3LTIyIDE0OjMwIEdNVC0wNDowMAo+ICA+Pj4+Pj4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSnVzdGluIFJpY2hlciA8anJpY2hlckBt aXQuZWR1Cj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8bWFp bHRvOmpyaWNoZXJAbWl0LmVkdT4+Ogo+ICA+Pj4+Pj4KPiAgPj4+Pj4+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFNvIHRoZSBkcmFmdCB3b3VsZCBsaXRlcmFsbHkKPiAgPj4+ Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHR1cm4gaW50bzoKPiAgPj4+ Pj4+Cj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAiVGhlIGE0 YyByZXNwb25zZSB0eXBlIGFuZAo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgZ3JhbnQgdHlwZSByZXR1cm4gYW4gaWRfdG9rZW4KPiAgPj4+Pj4+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZyb20gdGhlIHRva2VuIGVuZHBvaW50IHdpdGgK PiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG5vIGFjY2VzcyB0 b2tlbi4gQWxsCj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBw YXJhbWV0ZXJzIGFuZCB2YWx1ZXMgYXJlCj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBkZWZpbmVkIGluIE9JREMuIgo+ICA+Pj4+Pj4KPiAgPj4+Pj4+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFNlZW1zIGxpa2UgdGhlIHBlcmZlY3QgbWlu aQo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZXh0ZW5zaW9u IGRyYWZ0IGZvciBPSURGIHRvIGRvLgo+ICA+Pj4+Pj4KPiAgPj4+Pj4+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIC0tSnVzdGluCj4gID4+Pj4+Pgo+ICA+Pj4+Pj4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgL3NlbnQgZnJvbSBteSBwaG9uZS8KPiAgPj4+ Pj4+Cj4gID4+Pj4+Pgo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgT24gSnVsIDIyLCAyMDE0IDEwOjI5IEFNLCBOYXQKPiAgPj4+Pj4+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFNha2ltdXJhIDxzYWtpbXVyYUBnbWFpbC5jb20KPiAgPj4+ Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxtYWlsdG86c2FraW11cmFA Z21haWwuY29tPj4KPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHdyb3RlOgo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPgo+ ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPiBXaGF0IGFib3V0 IGp1c3QgZGVmaW5pbmcgYQo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgbmV3IGdyYW50IHR5cGUgaW4gdGhpcyBXRz8KPiAgPj4+Pj4+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgID4KPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgID4KPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgID4gMjAxNC0wNy0yMiAxMjo1NiBHTVQtMDQ6MDAKPiAgPj4+Pj4+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFBoaWwgSHVudAo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgPHBoaWwuaHVudEBvcmFjbGUuY29tCj4gID4+Pj4+PiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUu Y29tPj46Cj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA+Pgo+ ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPj4gVGhhdCB3b3Vs ZCBiZSBuaWNlLiBIb3dldmVyCj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBvaWRjIHN0aWxsIG5lZWRzIHRoZSBuZXcgZ3JhbnQKPiAgPj4+Pj4+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHR5cGUgaW4gb3JkZXIgdG8gaW1wbGVtZW50IHRo ZQo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc2FtZSBmbG93 Lgo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPj4KPiAgPj4+ Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgID4+IFBoaWwKPiAgPj4+Pj4+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgID4+Cj4gID4+Pj4+PiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA+PiBPbiBKdWwgMjIsIDIwMTQsIGF0IDExOjM1 LAo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTmF0IFNha2lt dXJhCj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8c2FraW11 cmFAZ21haWwuY29tCj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICA8bWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbT4+Cj4gID4+Pj4+PiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB3cm90ZToKPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgID4+Cj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICA+Pj4gKzEgdG8gSnVzdGluLgo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgPj4+Cj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICA+Pj4KPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ID4+PiAyMDE0LTA3LTIyIDk6NTQgR01ULTA0OjAwCj4gID4+Pj4+PiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBSaWNoZXIsIEp1c3RpbiBQLgo+ICA+Pj4+Pj4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgPGpyaWNoZXJAbWl0cmUub3JnCj4gID4+Pj4+PiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8bWFpbHRvOmpyaWNoZXJAbWl0cmUu b3JnPj46Cj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA+Pj4+ Cj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA+Pj4+IEVycm9y cyBsaWtlIHRoZXNlIG1ha2UgaXQKPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGNsZWFyIHRvIG1lIHRoYXQgaXQgd291bGQgbWFrZQo+ICA+Pj4+Pj4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbXVjaCBtb3JlIHNlbnNlIHRvIGRldmVsb3AK PiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoaXMgZG9jdW1l bnQgaW4gdGhlIE9wZW5JRAo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgRm91bmRhdGlvbi4gSXQgc2hvdWxkIGJlCj4gID4+Pj4+PiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBzb21ldGhpbmcgdGhhdCBkaXJlY3RseQo+ICA+Pj4+Pj4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcmVmZXJlbmNlcyBPcGVuSUQgQ29ubmVj dCBDb3JlCj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBmb3Ig YWxsIG9mIHRoZXNlIHRlcm1zIGluc3RlYWQKPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIG9mIHJlZGVmaW5pbmcgdGhlbS4gSXQncyBkb2luZwo+ICA+Pj4+Pj4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYXV0aGVudGljYXRpb24sIHdoaWNo IGlzCj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBmdW5kYW1l bnRhbGx5IHdoYXQgT3BlbklECj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBDb25uZWN0IGRvZXMgb24gdG9wIG9mIE9BdXRoLAo+ICA+Pj4+Pj4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgYW5kIEkgZG9uJ3Qgc2VlIGEgZ29vZAo+ICA+Pj4+ Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYXJndW1lbnQgZm9yIGRvaW5n IHRoaXMgd29yawo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg aW4gdGhpcyB3b3JraW5nIGdyb3VwLgo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgPj4+Pgo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgPj4+PiAgLS0gSnVzdGluCj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICA+Pj4+Cj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICA+Pj4+IE9uIEp1bCAyMiwgMjAxNCwgYXQgNDozMAo+ICA+Pj4+Pj4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgQU0sIFRob21hcyBCcm95ZXIKPiAgPj4+Pj4+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDx0LmJyb3llckBnbWFpbC5jb20KPiAgPj4+ Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxtYWlsdG86dC5icm95ZXJA Z21haWwuY29tPj4KPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHdyb3RlOgo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPj4+ Pgo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPj4+Pj4KPiAg Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgID4+Pj4+Cj4gID4+Pj4+ PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA+Pj4+Pgo+ICA+Pj4+Pj4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPj4+Pj4gT24gTW9uLCBKdWwgMjEsIDIw MTQgYXQKPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDExOjUy IFBNLCBNaWtlIEpvbmVzCj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tCj4gID4+Pj4+Pgo+IDxtYWlsdG86TWlj aGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4KPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHdyb3RlOgo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgPj4+Pj4+Cj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICA+Pj4+Pj4gVGhhbmtzIGZvciB5b3VyIHJldmlldywKPiAgPj4+Pj4+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRob21hcy4gIFRoZSAicHJvbXB0PWNvbnNlbnQi Cj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkZWZpbml0aW9u IGJlaW5nIG1pc3NpbmcgaXMgYW4KPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGVkaXRvcmlhbCBlcnJvci4gIEl0IHNob3VsZCBiZToKPiAgPj4+Pj4+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgID4+Pj4+Pgo+ICA+Pj4+Pj4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgPj4+Pj4+Cj4gID4+Pj4+PiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA+Pj4+Pj4KPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgID4+Pj4+PiBjb25zZW50Cj4gID4+Pj4+PiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA+Pj4+Pj4KPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgID4+Pj4+PiBUaGUgQXV0aG9yaXphdGlvbgo+ICA+Pj4+Pj4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU2VydmVyIFNIT1VMRCBwcm9tcHQgdGhl Cj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBFbmQtVXNlciBm b3IgY29uc2VudCBiZWZvcmUKPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHJldHVybmluZyBpbmZvcm1hdGlvbiB0byB0aGUKPiAgPj4+Pj4+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIENsaWVudC4gSWYgaXQgY2Fubm90IG9idGFpbgo+ICA+ Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc2VudCwgaXQgTVVT VCByZXR1cm4gYW4KPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IGVycm9yLCB0eXBpY2FsbHkKPiBjb25zZW50X3JlcXVpcmVkLgo+ICA+Pj4+Pj4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgPj4+Pj4+Cj4gID4+Pj4+PiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA+Pj4+Pj4KPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgID4+Pj4+Pgo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgPj4+Pj4+IEknbGwgcGxhbiB0byBhZGQgaXQgaW4KPiAgPj4+Pj4+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoZSBuZXh0IGRyYWZ0Lgo+ICA+Pj4+ Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPj4+Pj4KPiAgPj4+Pj4+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgID4+Pj4+Cj4gID4+Pj4+PiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA+Pj4+PiBJdCBsb29rcyBsaWtlIHRoZQo+ICA+ Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc2VudF9yZXF1aXJl ZCBlcnJvciBuZWVkcwo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgdG8gYmUgZGVmaW5lZCB0b28sIGFuZCB5b3UKPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIG1pZ2h0IGhhdmUgZm9yZ290dGVuIHRvIGFsc28KPiAgPj4+Pj4+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGltcG9ydAo+ICA+Pj4+Pj4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYWNjb3VudF9zZWxlY3Rpb25fcmVxdWly ZWQKPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZyb20gT3Bl bklEIENvbm5lY3QuCj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICA+Pj4+Pgo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPj4+ Pj4+Cj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA+Pj4+Pj4K PiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgID4+Pj4+Pgo+ICA+ Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPj4+Pj4+IEkgYWdyZWUg dGhhdCB0aGVyZSdzIG5vCj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBkaWZmZXJlbmNlIGJldHdlZW4gYSByZXNwb25zZQo+ICA+Pj4+Pj4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgd2l0aCBtdWx0aXBsZSAiYW1yIiB2YWx1ZXMKPiAgPj4+ Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoYXQgaW5jbHVkZXMgIm1m YSIgYW5kIG9uZQo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg dGhhdCBkb2Vzbid0LiAgVW5sZXNzIGEgY2xlYXIKPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHVzZSBjYXNlIGZvciB3aHkgIm1mYSIgaXMKPiAgPj4+Pj4+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG5lZWRlZCBjYW4gYmUgaWRlbnRpZmll ZCwgd2UKPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNhbiBk ZWxldGUgaXQgaW4gdGhlIG5leHQgZHJhZnQuCj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICA+Pj4+Pgo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgPj4+Pj4KPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgID4+Pj4+IFRoYW5rcy4KPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgID4+Pj4+Cj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICA+Pj4+PiBIb3cgYWJvdXQgInB3ZCIgdGhlbj8gSQo+ICA+Pj4+Pj4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgZnVsbHkgdW5kZXJzdGFuZCB0aGF0IEkgc2hvdWxkCj4g ID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICByZXR1cm4gInB3ZCIg aWYgdGhlIHVzZXIKPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IGF1dGhlbnRpY2F0ZWQgdXNpbmcgYQo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgcGFzc3dvcmQsIGJ1dCB3aGF0ICJ0aGUKPiAgPj4+Pj4+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHNlcnZpY2UgaWYgYSBjbGllbnQgc2VjcmV0IGlzCj4g ID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1c2VkIiBtZWFucyBp biB0aGUgZGVmaW5pdGlvbgo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgZm9yIHRoZSAicHdkIiB2YWx1ZT8KPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgID4+Pj4+Cj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICA+Pj4+PiAoTm90YTogSSBrbm93IHlvdSdyZSBhdAo+ICA+Pj4+Pj4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSUVURi05MCwgSSdtIHJlYWR5IHRvIHdhaXQK PiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICd0aWwgeW91IGNv bWUgYmFjayA7LSkgKQo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgPj4+Pj4KPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgID4+ Pj4+IC0tCj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA+Pj4+ PiBUaG9tYXMgQnJveWVyCj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICA+Pj4+PiAvdMmULm1hLmLKgXdhLmplLwo+ICA+Pj4+Pj4KPiA8aHR0cDovL3huLS1ubmEu bWEueG4tLWJ3YS14eGIuamUvPgo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgPj4+Pj4KPiAgPj4+Pj4+Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18KPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgID4+Pj4+IE9BdXRoIG1haWxpbmcgbGlzdAo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgPj4+Pj4gT0F1dGhAaWV0Zi5vcmcKPiAgPj4+Pj4+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+Cj4g ID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA+Pj4+Pgo+ICA+Pj4+ Pj4KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoCj4gID4+Pj4+ PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA+Pj4+Cj4gID4+Pj4+PiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA+Pj4+Cj4gID4+Pj4+PiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA+Pj4+Cj4gID4+Pj4+PiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICA+Pj4+Cj4gID4+Pj4+Pgo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICA+Pj4+IE9BdXRoIG1haWxpbmcgbGlzdAo+ICA+Pj4+Pj4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPj4+PiBPQXV0aEBpZXRmLm9yZwo+ICA+Pj4+ Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPG1haWx0bzpPQXV0aEBpZXRm Lm9yZz4KPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgID4+Pj4K PiAgPj4+Pj4+Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aAo+ ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPj4+Pgo+ICA+Pj4+ Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPj4+Cj4gID4+Pj4+PiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA+Pj4KPiAgPj4+Pj4+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgID4+Pgo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgPj4+IC0tCj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICA+Pj4gTmF0IFNha2ltdXJhICg9bmF0KQo+ICA+Pj4+Pj4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgPj4+IENoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlv bgo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPj4+IGh0dHA6 Ly9uYXQuc2FraW11cmEub3JnLwo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgPj4+IEBfbmF0X2VuCj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICA+Pj4KPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgID4+Pgo+ICA+Pj4+Pj4KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXwo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Pj4+IE9BdXRoIG1haWxpbmcgbGlzdAo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgPj4+IE9BdXRoQGlldGYub3JnCj4gID4+Pj4+PiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICA8bWFpbHRvOk9BdXRoQGlldGYub3JnPgo+ICA+Pj4+Pj4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPj4+Cj4gID4+Pj4+Pgo+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgKPiAgPj4+Pj4+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgID4KPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgID4KPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgID4KPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgID4K PiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgID4gLS0KPiAgPj4+ Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgID4gTmF0IFNha2ltdXJhICg9 bmF0KQo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPiBDaGFp cm1hbiwgT3BlbklEIEZvdW5kYXRpb24KPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgID4gaHR0cDovL25hdC5zYWtpbXVyYS5vcmcvCj4gID4+Pj4+PiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA+IEBfbmF0X2VuCj4gID4+Pj4+Pgo+ICA+Pj4+ Pj4KPiAgPj4+Pj4+Cj4gID4+Pj4+Pgo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgLS0KPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIE5hdCBTYWtpbXVyYSAoPW5hdCkKPiAgPj4+Pj4+Cj4gID4+Pj4+PiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBDaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb24KPiAgPj4+ Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGh0dHA6Ly9uYXQuc2FraW11 cmEub3JnLwo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQF9u YXRfZW4KPiAgPj4+Pj4+Cj4gID4+Pj4+Pgo+ICA+Pj4+Pj4KPiAgPj4+Pj4+Cj4gID4+Pj4+PiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tCj4gID4+Pj4+PiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIE5hdCBTYWtpbXVyYSAoPW5hdCkKPiAgPj4+Pj4+Cj4gID4+Pj4+ PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIENoYWlybWFuLCBPcGVuSUQgRm91bmRh dGlvbgo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBodHRwOi8vbmF0 LnNha2ltdXJhLm9yZy8KPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg QF9uYXRfZW4KPiAgPj4+Pj4+Cj4gID4+Pj4+Pgo+ICA+Pj4+Pj4KPiAgPj4+Pj4+Cj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiAgPj4+Pj4+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgT0F1dGggbWFpbGluZyBsaXN0Cj4gID4+Pj4+PiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE9BdXRoQGlldGYub3JnCj4gPG1haWx0bzpP QXV0aEBpZXRmLm9yZz4KPiAgPj4+Pj4+Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9vYXV0aAo+ICA+Pj4+Pj4KPiAgPj4+Pj4+Cj4gID4+Pj4+Pgo+ICA+Pj4+Pj4KPiAg Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0KPiAgPj4+Pj4+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgVGhvbWFzIEJyb3llcgo+ICA+Pj4+Pj4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAvdMmULm1hLmLKgXdhLmplLwo+ICA+Pj4+Pj4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8aHR0cDovL3huLS1ubmEubWEueG4tLWJ3YS14 eGIuamUvPgo+ICA+Pj4+Pj4KPiAgPj4+Pj4+Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgT0F1dGggbWFpbGluZyBsaXN0Cj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIE9BdXRoQGlldGYub3JnCj4gPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4KPiAgPj4+ Pj4+Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aAo+ICA+Pj4+ Pj4KPiAgPj4+Pj4+Cj4gID4+Pj4+Pgo+ICA+Pj4+Pj4KPiAgPj4+Pj4+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgLS0KPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgVGhvbWFzIEJyb3llcgo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAvdMmULm1hLmLKgXdhLmplLwo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICA8aHR0cDovL3huLS1ubmEubWEueG4tLWJ3YS14eGIuamUvPgo+ICA+Pj4+Pj4KPiAg Pj4+Pj4+Cj4gID4+Pj4+Pgo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fCj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE9BdXRo IG1haWxpbmcgbGlzdAo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBP QXV0aEBpZXRmLm9yZwo+IDxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+Cj4gID4+Pj4+Pgo+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgKPiAgPj4+Pj4+Cj4gID4+Pj4+ Pgo+ICA+Pj4+Pj4KPiAgPj4+Pj4+Cj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIC0tCj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE5hdCBT YWtpbXVyYSAoPW5hdCkKPiAgPj4+Pj4+Cj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIENoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbgo+ICA+Pj4+Pj4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBodHRwOi8vbmF0LnNha2ltdXJhLm9yZy8KPiAgPj4+Pj4+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQF9uYXRfZW4KPiAgPj4+Pj4+Cj4gID4+ Pj4+Pgo+ICA+Pj4+Pj4KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXwo+ICA+Pj4+Pj4KPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgT0F1dGggbWFpbGluZyBsaXN0Cj4gID4+Pj4+Pgo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBPQXV0aEBpZXRmLm9yZwo+IDxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+ Cj4gID4+Pj4+Pgo+ICA+Pj4+Pj4KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29hdXRoCj4gID4+Pj4+Pgo+ICA+Pj4+Pj4KPiAgPj4+Pj4+Cj4gID4+Pj4+Pgo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gID4+Pj4+PiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgT0F1dGggbWFpbGluZyBsaXN0Cj4gID4+Pj4+PiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgT0F1dGhAaWV0Zi5vcmcgPG1haWx0bzpPQXV0aEBpZXRm Lm9yZz4KPiAgPj4+Pj4+Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v YXV0aAo+ICA+Pj4+Pj4KPiAgPj4+Pj4+Cj4gID4+Pj4+Pgo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAg ICAgICBPQXV0aCBtYWlsaW5nIGxpc3QKPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAg IE9BdXRoQGlldGYub3JnIDxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+Cj4gID4+Pj4+PiAgICAgICAg ICAgICAgICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h dXRoCj4gID4+Pj4+Pgo+ICA+Pj4+Pj4KPiAgPj4+Pj4+Cj4gID4+Pj4+PiAgICAgICAgICAgICAg ICAgICAgIC0tCj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgIE5hdCBTYWtpbXVyYSAoPW5h dCkKPiAgPj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgQ2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0 aW9uCj4gID4+Pj4+PiAgICAgICAgICAgICAgICAgICAgIGh0dHA6Ly9uYXQuc2FraW11cmEub3Jn Lwo+ICA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICBAX25hdF9lbgo+ICA+Pj4+Pj4KPiAgPj4+ Pj4+ICAgICAgICAgICAgICAgICAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18KPiAgPj4+Pj4+ICAgICAgICAgIA== ----_com.android.email_486516192215700 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+PGRpdj5Zb3UgY2VydGFpbmx5IGNh biBkbyBhdXRoZW50aWNhdGlvbiB3aXRob3V0IHVzaW5nIGFuIGFjY2VzcyB0b2tlbiwgYnV0IHRo ZW4gSSB3b3VsZCBhcmd1ZSB0aGF0J3Mgbm8gbG9uZ2VyIE9BdXRoLiBCYXNpY2FsbHkgeW91J3Jl IG1ha2luZyB0b2Z1IGNhcm9iIGZ1ZGdlLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwv ZGl2PjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTo5cHgiPjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTogOXB4 OyAiPi0tIEp1c3RpbjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTogOXB4OyAiPjxicj48L2Rp dj48ZGl2IHN0eWxlPSJmb250LXNpemU6IDlweDsgIj4vIFNlbnQgZnJvbSBteSBwaG9uZSAvPC9k aXY+PC9kaXY+PGRpdj48L2Rpdj48ZGl2PjwvZGl2Pjxicj48YnI+LS0tLS0tLS0gT3JpZ2luYWwg bWVzc2FnZSAtLS0tLS0tLTxicj5Gcm9tOiBTZXJnZXkgQmVyeW96a2luICZsdDtzYmVyeW96a2lu QGdtYWlsLmNvbSZndDsgPGJyPkRhdGU6MTAvMTMvMjAxNCAgOTowMCBBTSAgKEdNVC0wNTowMCkg PGJyPlRvOiBKdXN0aW4gUmljaGVyICZsdDtqcmljaGVyQG1pdC5lZHUmZ3Q7LCBvYXV0aEBpZXRm Lm9yZyA8YnI+Q2M6ICA8YnI+U3ViamVjdDogUmU6IFtPQVVUSC1XR10gTmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvciAgZHJhZnQtaHVudC1vYXV0aC12Mi11c2VyLWE0Yy0wNS50eHQgPGJyPjxi cj5IaSBKdXN0aW4sPGJyPk9uIDEzLzEwLzE0IDEyOjUzLCBKdXN0aW4gUmljaGVyIHdyb3RlOjxi cj4mZ3Q7IFlvdSBhcmUgY29ycmVjdCBpbiB0aGF0IE9BdXRoIDIgYW5kIE9wZW5JRCBDb25uZWN0 IGFyZSBub3QgdGhlIHNhbWU8YnI+Jmd0OyB0aGluZywgYnV0IHlvdXIgdXNlciBpcyBjb3JyZWN0 IHRoYXQgT0lEQyBhZGRzIGEgZmV3IHBpZWNlcyBvbiB0b3Agb2Y8YnI+Jmd0OyBPQXV0aCB0byBh ZGQgYXV0aGVudGljYXRpb24gY2FwYWJpbGl0aWVzLiBPSURDIHdhcyBkZXNpZ25lZCB2ZXJ5PGJy PiZndDsgZXhwbGljaXRseSB0byBiZSBjb21wYXRpYmxlIHdpdGggdmFuaWxsYSBPQXV0aCwgcGFy dGlhbGx5IGRvIHRoYXQgcGVvcGxlPGJyPiZndDsgd291bGQgYmUgYWJsZSB0byBkZXBsb3kgaXQg b24gdG9wIG9mIGV4aXN0aW5nIE9BdXRoIGluZnJhc3RydWN0dXJlIGFuZDxicj4mZ3Q7IGNvZGUu IEJ1dCB0aGUgdmVyeSBmYWN0IHRoYXQgT0lEQyBhZGRzIGEgZmV3IHRoaW5ncyBvbiB0b3Agb2Yg T0F1dGggdG88YnI+Jmd0OyBnaXZlIG1vcmUgZnVuY3Rpb25hbGl0eSBzaG91bGQgYmUgc3VmZmlj aWVudCBldmlkZW5jZSB0aGF0IHRoZXkncmUgbm90PGJyPiZndDsgZXF1aXZhbGVudC48YnI+Jmd0 Ozxicj4mZ3Q7IEl0J3MgbW9yZSBwcm9wZXIgdG8gc2F5IHRoYXQgT3BlbklEIENvbm5lY3QgaXMg YW4gZXh0ZW5zaW9uIGFuZDxicj4mZ3Q7IGFwcGxpY2F0aW9uIG9mIE9BdXRoLiBPbmUgdGhhdCBw cm92aWRlcyBhbiBhdXRoZW50aWNhdGlvbiBhbmQgaWRlbnRpdHkgQVBJLjxicj4mZ3Q7PGJyPkkg YWdyZWUgYW5kIHRoaXMgaXMgbW9yZSBvciBsZXNzIGhvdyBJIGFuc3dlcmVkLjxicj48YnI+VGhv dWdoIHRoZSAnYm9yZGVycycgY2FuIGJlIGJsdXJyZWQsIG9uZSBjYW4gY2xhaW0gdGhhdCBpZiBh IHVzZXIgPGJyPmFjdHVhbGx5IGxvZ3Mgb24gaW50byBhIGNvbmZpZGVudGlhbCBPQXV0aDIgY2xp ZW50IHdlYiBhcHBsaWNhdGlvbiB3aGljaCA8YnI+cmVkaXJlY3RzIHRoaXMgdXNlciB0byBBUyBy ZXF1ZXN0aW5nIGEgY29kZSB3aXRoIHNvbWUgc2NvcGVzIHN1Y2ggYXMgImEgPGJyPmIiIHRoZW4g d2hlbiBpdCB1c2VzICJhIGIgb3BlbmlkIHByb2ZpbGUiIGl0IGlzIGJhc2ljYWxseSBkb2VzIGEg cHVyZSA8YnI+T0F1dGgyIGNvZGUgZmxvdyB3aGVyZSB0aGUgY2xpZW50IHJlcXVlc3RzICdhIGIn IHBsdXMgYWxzbyBhIHNjb3BlIDxicj5hbGxvd2luZyBpdCBsYXRlciB0byBxdWVyeSB0aGUgaWRl bnRpdHkgc3lzdGVtIG9uIGJlaGFsZiBvZiBhIHVzZXIuPGJyPjxicj5JIGxpa2UgdGhlICJUaGUg ZXh0ZW5zaW9uIGFuZCBhcHBsaWNhdGlvbiBvZiBPQXV0aDIiIGNoYXJhY3RlcmlzdGljIG9mIDxi cj5PSURDLiBJTUhPIGl0J3MgYmVjb21pbmcgbW9yZSBvYnZpb3VzIGlmIE9JREMgaXMgdXNlZCB0 byBzdXBwb3J0IFNTTyA8YnI+aW50byBub24tT0F1dGgyIHNlcnZlcnMsIHdoZW4gaXQgaXMgdGhl IGNhc2UgdGhlbiB0aGVyZSdzIG5vICdmZWVsaW5nJyA8YnI+dGhhdCBPSURDIGlzIGp1c3QgYSBj YXNlIG9mIHRoZSBjb25maWRlbnRpYWwgY2xpZW50IGFkZGluZyB0aGUgZXh0cmEgPGJyPnNjb3Bl cyBhbmQgZ2V0dGluZyB0aGUgZXh0cmEgKGF1dGhlbnRpY2F0aW9uKSBpbmZvIGJhY2suIEEgc3Rh bmRhbG9uZSA8YnI+T0lEQyBSUCBwcm90ZWN0aW5nIHN1Y2ggbm9uIE9BdXRoMiBzZXJ2ZXJzIGlz IHZlcnkgbXVjaCBhYm91dCB0aGUgPGJyPmF1dGhlbnRpY2F0aW9uL2lkZW50aXR5Ljxicj48YnI+ SSBhbHNvIHRob3VnaHQgdGhhdCBoYXZpbmcgc29tZSBPSUQgcHJvZmlsZSAoYXMgb3Bwb3NlZCB1 cGRhdGluZyBPQXV0aDIgPGJyPnRvIHN1cHBvcnQgbm8gYWNjZXNzIHRva2Vucykgd2hlcmUgbm8g YWNjZXNzIGJ1dCBvbmx5IGlkIHRva2VuIHdhcyA8YnI+cmV0dXJuZWQgKGFzIHN1Z2dlc3RlZCBp biB0aGlzIHRocmVhZCkgd291bGQgcHJvYmFibHkgbWFrZSBzZW5zZSB0b28uPGJyPjxicj4mZ3Q7 IFRoZSB3YXkgSSBsaWtlIHRvIGV4cGxhaW4gaXQgKHdoaWNoIEkgc3RvbGUgZnJvbSBzb21lb25l IGVsc2UpIGlzIHRoYXQ8YnI+Jmd0OyBPQXV0aCBpcyBsaWtlIGNob2NvbGF0ZSBhbmQgYXV0aGVu dGljYXRpb24gaXMgbGlrZSBmdWRnZS4gVGhleSBhcmUgbm90PGJyPiZndDsgdGhlIHNhbWUgdGhp bmcuIFlvdSBjYW4gbWFrZSBjaG9jb2xhdGUgaW50byBmdWRnZSBvdXQgeW91IGNhbiBtYWtlIGl0 PGJyPiZndDsgaW50byBzb21ldGhpbmcgZWxzZSBvciB5b3UgY2FuIGp1c3QgaGF2ZSBpdCBvbiBp dHMgb3duLiBZb3UgY2FuIG1ha2U8YnI+Jmd0OyBmdWRnZSB3aXRoIGNob2NvbGF0ZSBvciB5b3Ug Y2FuIG1ha2UgaXQgd2l0aCBwZWFudXQgYnV0dGVyIG9yIHlvdSBjYW48YnI+Jmd0OyBtYWtlIGl0 IHdpdGggcG90YXRvZXMgaWYgeW91IHdhbnQgdG8sIGJ1dCBpdCBuZWVkcyBhIGNvdXBsZSBpbmdy ZWRpZW50czxicj4mZ3Q7IGFuZCBhIHZlcnkgY29tbW9uIG9uZSBpcyBjaG9jb2xhdGUuIE9wZW5J RCBDb25uZWN0IGlzIGEgcmVjaXBlIGZvcjxicj4mZ3Q7IGNob2NvbGF0ZSBmdWRnZSB0aGF0IGEg bG90IG9mIHBlb3BsZSBsaWtlLiBBbmQgaXQgbWFrZXMgbXkgZnVkZ2U8YnI+Jmd0OyBjb21wYXRp YmxlIHdpdGggeW91ciBmdWRnZSwgd2hpY2ggaXMgd2hlcmUgdGhlIG1ldGFwaG9yIGJyZWFrcyBk b3duLiA6LSk8YnI+Jmd0Ozxicj5UaGFua3MgZm9yIHNoYXJpbmcgdGhpcyBjb2xvdXJmdWwgZXhw bGFuYXRpb24gOi0pLiBQZXJoYXBzIEkgc2hvdWxkIDxicj5ib3Jyb3cgaXQgOi0pLDxicj5DaGVl cnMsIFNlcmdleTxicj48YnI+PGJyPiZndDs8YnI+Jmd0OyAtLSBKdXN0aW48YnI+Jmd0Ozxicj4m Z3Q7IC8gU2VudCBmcm9tIG15IHBob25lIC88YnI+Jmd0Ozxicj4mZ3Q7PGJyPiZndDsgLS0tLS0t LS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLTxicj4mZ3Q7IEZyb206IFNlcmdleSBCZXJ5b3pr aW4gJmx0O3NiZXJ5b3praW5AZ21haWwuY29tJmd0Ozxicj4mZ3Q7IERhdGU6MTAvMTMvMjAxNCA2 OjMzIEFNIChHTVQtMDU6MDApPGJyPiZndDsgVG86IG9hdXRoQGlldGYub3JnPGJyPiZndDsgQ2M6 PGJyPiZndDsgU3ViamVjdDogUmU6IFtPQVVUSC1XR10gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9u IGZvcjxicj4mZ3Q7IGRyYWZ0LWh1bnQtb2F1dGgtdjItdXNlci1hNGMtMDUudHh0PGJyPiZndDs8 YnI+Jmd0OyBIaTxicj4mZ3Q7PGJyPiZndDsgV2UndmUgaGFkIGEgdXNlciBhc3NlcnRpbmcgdGhh dCAiT0F1dGgyID09IE9wZW5pZENvbm5lY3QiLCByZWZlcnJpbmcgdG88YnI+Jmd0OyB0aGUgZmFj dCB0aGF0IHRoZSAnb25seScgdGhpbmcgT0lDIGFkZHMgb24gdG9wIG9mIHRoZSBhdXRob3JpemF0 aW9uIGNvZGU8YnI+Jmd0OyBmbG93IGlzIHRoZSBjbGllbnQgc3BlY2lmeWluZyBmZXcgZXh0cmEg c2NvcGVzIGxpa2UgJ29wZW5pZCcgYW5kPGJyPiZndDsgJ3Byb2ZpbGUnIGFuZCB0aGUgYXV0aG9y aXphdGlvbiBzZXJ2aWNlIHJldHVybmluZyBhbiBleHRyYSBwcm9wZXJ0eSwgdGhlPGJyPiZndDsg aWRfdG9rZW4gd2hpY2ggY2FuIGJlIHN1ZmZpY2llbnQgaW4gb3JkZXIgdG8gZ2V0IHRoZSBhdXRo ZW50aWNhdGVkPGJyPiZndDsgdXNlcidzIGluZm8uPGJyPiZndDs8YnI+Jmd0OyBNeSB1bmRlcnN0 YW5kaW5nICJPQXV0aDIgIT0gT3BlbmlkQ29ubmVjdCIsIHRoZSBsYXR0ZXIgdXRpbGl6ZXMgdGhl PGJyPiZndDsgZm9ybWVyIGFuZCBpcyBhbiBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc20gd2hpY2gg aXMgbm90IHdoYXQgT0F1dGgyIGlzPGJyPiZndDsgKG1heSBiZSBleGNlcHQgZm9yIHRoZSBjbGll bnQgY3JlZGVudGlhbHMpLiBCdXQgSSBkb24ndCBmZWVsIGxpa2UgaXQgaXM8YnI+Jmd0OyBhIGNv bnZpbmNpbmcgZW5vdWdoIGFyZ3VtZW50Ljxicj4mZ3Q7PGJyPiZndDsgSSB0aG91Z2h0IHRoaXMg dGhyZWFkIHdhcyByZWxldmFudCwgc29ycnkgaWYgbm90LCB3b3VsZCBoYXZlIG5vIHByb2JsZW1z PGJyPiZndDsgc3RhcnRpbmcgYSBuZXcgb25lLjxicj4mZ3Q7PGJyPiZndDsgQmFzaWNhbGx5LCBJ IHdvbmRlciB3aGF0IGlzIHRoZSBwcm9wZXIgbGluZSBvZiBhcmd1bWVudCBmb3IgYSBwb3NpdGlv bjxicj4mZ3Q7IHN1Y2ggYXMgIk9BdXRoMiAhPSBPcGVuaWRDb25uZWN0IiBhbmQgYWxzbyB3aGF0 IHdhcyB0aGUgYWN0aW9uIHRvIHRoZTxicj4mZ3Q7IGxpc3Qgb2Ygb3B0aW9ucyBzdWdnZXN0ZWQg YnkgSm9obiBiZWxvdy4gSXMgaGF2aW5nIGFuIE9JRCBwcm9maWxlIHdoZXJlPGJyPiZndDsgbm8g YWNjZXNzIHRva2VuIGlzIHJldHVybmVkIHdvdWxkIGJlIHRoZSBjbGVhbmVzdCBhY3Rpb24gYXMg ZmFyIGFzPGJyPiZndDsgYnJlYWtpbmcgdGhlIGFtYmlndWl0eS9jb25mdXNpb24gaXMgY29uY2Vy bmVkID88YnI+Jmd0Ozxicj4mZ3Q7IENoZWVycywgU2VyZ2V5PGJyPiZndDs8YnI+Jmd0OyBPbiAy NC8wNy8xNCAxNToyNSwgSm9obiBCcmFkbGV5IHdyb3RlOjxicj4mZ3Q7Jm5ic3A7ICZndDsgSSBh bSBub3QgYWdhaW5zdCBkaXNjdXNzaW9uIGluIHRoZSBXRy48YnI+Jmd0OyZuYnNwOyAmZ3Q7PGJy PiZndDsmbmJzcDsgJmd0OyBJIGhhcHBlbiB0byBhZ3JlZSB3aXRoIFBoaWwncyBmdW5kYW1lbnRh bCBwcmVtaXNlIHRoYXQgc29tZSBkZXZlbG9wZXJzPGJyPiZndDsmbmJzcDsgJmd0OyBhcmUgdXNp bmcgT0F1dGggaW4gYSBpbnNlY3VyZSB3YXkgdG8gZG8gYXV0aGVudGljYXRpb24uPGJyPiZndDsm bmJzcDsgJmd0Ozxicj4mZ3Q7Jm5ic3A7ICZndDsgVGhhdCByYWlzZXMgdGhlIHF1ZXN0aW9uIG9m IGhvdyB0byBiZXN0IGVkdWNhdGUgdGhlbSwgYW5kIG9yIGFkZHJlc3M8YnI+Jmd0OyZuYnNwOyAm Z3Q7IHRlY2huaWNhbCBiYXJyaWVycy48YnI+Jmd0OyZuYnNwOyAmZ3Q7PGJyPiZndDsmbmJzcDsg Jmd0OyBJdCBpcyBvbiB0aGUgc2Vjb25kIHBvaW50IHRoYXQgcGVvcGxlJ3Mgb3BpbmlvbnMgc2Vl bSB0byBkaXZpZGUuPGJyPiZndDsmbmJzcDsgJmd0Ozxicj4mZ3Q7Jm5ic3A7ICZndDsgU29tZSBw ZW9wbGUgdGhpbmcgdGhhdCBpZiB3ZSBoYXZlIGEgT0F1dGggZmxvdyB0aGF0IGVsaW1pbmF0ZXMg dGhlPGJyPiZndDsmbmJzcDsgJmd0OyBhY2Nlc3MgdG9rZW4gKHByaW1hcmlseSB0byBhdm9pZCBh c2tpbmcgZm9yIGNvbnNlbnQgYXMgSSB1bmRlcnN0YW5kIGl0KTxicj4mZ3Q7Jm5ic3A7ICZndDsg YW5kIGp1c3QgcmV0dXJuIGEgaWRfdG9rZW4gZnJvbSB0aGUgdG9rZW4gZW5kcG9pbnQgdGhhdCBj YW4gYmUgZG9uZSBpbiBhPGJyPiZndDsmbmJzcDsgJmd0OyBzcGVjIHNob3J0IGVub3VnaCB0byBo ZXQgcGVvcGxlIHRvIHJlYWQuJm5ic3A7Jm5ic3A7IFRoZSBzdWJ0ZXh0IG9mIHRoaXMgaXMgdGhh dDxicj4mZ3Q7Jm5ic3A7ICZndDsgdGhlIENvbm5lY3Qgc3BlY2lmaWNhdGlvbiBpcyB0b28gbGFy Z2UgdGhhdCBpdCBzY2FyZSBwZW9wbGUsJm5ic3A7IGFuZCB0aGV5PGJyPiZndDsmbmJzcDsgJmd0 OyBkb24ndCBmaW5kIHRoZSBzcGVjIGluIHRoZSBmaXJzdCBwbGFjZSBiZWNhdXNlIGl0IGlzIG5v dCBhIFJGQy48YnI+Jmd0OyZuYnNwOyAmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyBBbiBvdGhlciBj b21tb24gcG9zc2Vzc2lvbiBpcyB0aGF0IGlmIHlvdSBkb24ndCB3YW50IHRvIHByb21wdCB0aGUg dXNlcjxicj4mZ3Q7Jm5ic3A7ICZndDsgZm9yIGNvbnNlbnQgdGhlbiBkb24ndCBhc2sgZm9yIHNj b3Blcy4mbmJzcDsgVHdpc3RpbmcgdGhlIE9BdXRoIHNwZWMgdG8gbm90PGJyPiZndDsmbmJzcDsg Jmd0OyByZXR1cm4gYW4gYWNjZXNzIHRva2VuIGlzIG5vdCBPQXV0aCwmbmJzcDsgeWVzIHlvdSBj b3VsZCB1c2UgYSBkaWZmZXJlbnQ8YnI+Jmd0OyZuYnNwOyAmZ3Q7IGVuZHBvaW50IHJhdGhlciB0 aGFuIHRoZSB0b2tlbiBlbmRwb2ludCwgYnV0IHRoYXQgaXMgbm90IE9BdXRoLjxicj4mZ3Q7Jm5i c3A7ICZndDsgQ29ubmVjdCB3YXMgY2FyZWZ1bCBub3QgdG8gYnJlYWsgdGhlIE9BdXRoIHNwZWMu Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFzIGxvbmcgYXMgeW91IGFyZTxicj4mZ3Q7Jm5ic3A7ICZndDsg d2lsbGluZyB0byB0YWtlIGEgYWNjZXNzIHRva2VuIHdpdGggbm8gc2NvcGVzICh0aGUgY2xpZW50 IG5lZWRzIHRvPGJyPiZndDsmbmJzcDsgJmd0OyB1bmRlcnN0YW5kIHRoYXQgdGhlcmUgYXJlIG5v IGF0dHJpYnV0ZXMgb25lIHdheSBvciBhbm90aGVyIGFueXdheSBvciBpdDxicj4mZ3Q7Jm5ic3A7 ICZndDsgd2lsbCBicmVhaykgdGhlbiB5b3UgZG9uJ3QgbmVlZCB0byBjaGFuZ2UgT0F1dGguJm5i c3A7Jm5ic3A7IFlvdSBjYW4gcHVibGlzaCBhPGJyPiZndDsmbmJzcDsgJmd0OyBwcm9maWxlIG9m IGNvbm5lY3QgdGhhdCBzYXRpc2ZpZXMgdGhlIHVzZSBjYXNlLjxicj4mZ3Q7Jm5ic3A7ICZndDs8 YnI+Jmd0OyZuYnNwOyAmZ3Q7IEkgdGhpbmsgTWlrZSBoYXMgbGFyZ2VseSBkb25lIHRoYXQgYnV0 IGl0IG1pZ2h0IGJlIGJldHRlciBiZWluZyBsZXNzPGJyPiZndDsmbmJzcDsgJmd0OyBzdGluZ3kg b24gcmVmZXJlbmNlcyBiYWNrIHRvIHRoZSBsYXJnZXIgc3BlYy48YnI+Jmd0OyZuYnNwOyAmZ3Q7 PGJyPiZndDsmbmJzcDsgJmd0OyBUaGUgcXVlc3Rpb25zIGFyZSBkbyB3ZSBtb2RpZnkgT0F1dGgg dG8gbm90IHJldHVybiBhbiBhY2Nlc3MgdG9rZW4sIGFuZDxicj4mZ3Q7Jm5ic3A7ICZndDsgaWYg c28gaG93LCZuYnNwOyBhbmQgaWYgd2UgZG8gaXMgaXQgc3RpbGwgT0F1dGguPGJyPiZndDsmbmJz cDsgJmd0Ozxicj4mZ3Q7Jm5ic3A7ICZndDsgVGhlIG90aGVyIGxhcmdlbHkgc2VwYXJhYmxlIHF1 ZXN0aW9uIGlzIGRvIHdlIGNyZWF0ZSBjb25mdXNpb24gaW4gdGhlPGJyPiZndDsmbmJzcDsgJmd0 OyBtYXJrZXQgYW5kIHNsb3cgdGhlIHRoZSBhZG9wdGlvbiBvZiBpZGVudGl0eSBmZWRlcmF0aW9u IG9uIHRvcCBvZiBPQXV0aCw8YnI+Jmd0OyZuYnNwOyAmZ3Q7IG9yIGZpbmQgYSB3YXkgdG8gbWFr ZSB0aGlzIGxvb2sgbGlrZSBhIHBvc2l0aXZlIGFsaWdubWVudCBvZiBpbnRlcmVzdHM8YnI+Jmd0 OyZuYnNwOyAmZ3Q7IGFyb3VuZCBhIHN1YnNldCBvZiBDb25uZWN0Ljxicj4mZ3Q7Jm5ic3A7ICZn dDs8YnI+Jmd0OyZuYnNwOyAmZ3Q7IFRoZXJlIGFyZSBhIG51bWJlciBvZiBvcHRpb25zLjxicj4m Z3Q7Jm5ic3A7ICZndDsgMTogV2UgY2FuIGRvIGEgcHJvZmlsZSBpbiB0aGUgT0lERiBhbmQgcHVi bGlzaCBpdCBhcyBhIElFVEYgZG9jdW1lbnQuPGJyPiZndDsmbmJzcDsgJmd0OyBQZXJoYXBzIHRo ZSBjbGVhbmVzdCBmcm9tIGFuIElQUiBwb2ludCBvZiB2aWV3Lkhvd2V2ZXI8YnI+Jmd0OyZuYnNw OyAmZ3Q7IDI6V2UgY2FuIGRvIGEgcHJvZmlsZSBpbiB0aGUgT0F1dGggV0cgcmVmZXJlbmNpbmcg Y29ubmVjdC48YnI+Jmd0OyZuYnNwOyAmZ3Q7IDM6V2UgY2FuIGRvIGEgQUQgc3BvbnNvcmVkIHBy b2ZpbGUgdGhhdCBpcyBub3QgaW4gdGhlIE9BdXRoIFdHLjxicj4mZ3Q7Jm5ic3A7ICZndDsgNDpX ZSBjYW4gZG8gYSBzbWFsbCBzcGVjIGluIE9BdXRoIHRvIGFkZCByZXNwb25zZV90eXBlIHRvIHRo ZSB0b2tlbjxicj4mZ3Q7Jm5ic3A7ICZndDsgZW5kcG9pbnQuJm5ic3A7IGluIGNvbWJpbmF0aW9u IHdpdGggMSwgMiwgb3IgMzxicj4mZ3Q7Jm5ic3A7ICZndDs8YnI+Jmd0OyZuYnNwOyAmZ3Q7IEkg YWdyZWUgdGhhdCBzdG9waW5nIGRldmVsb3BlcnMgZG9pbmcgaW5zZWN1cmUgdGhpbmdzIG5lZWRz IHRvIGJlPGJyPiZndDsmbmJzcDsgJmd0OyBhZGRyZXNzZWQgc29tZWhvdy48YnI+Jmd0OyZuYnNw OyAmZ3Q7IEkgYW0gbm90IHBlcnNvbmFsbHkgY29udmluY2VkIHRoYXQgT2F1dGggd2l0aG91dCBh Y2Nlc3MgdG9rZW5zIGlzPGJyPiZndDsgc2Vuc2libGUuPGJyPiZndDsmbmJzcDsgJmd0Ozxicj4m Z3Q7Jm5ic3A7ICZndDsgTG9va2luZyBmb3J3YXJkIHRvIHRoZSBtZWV0aW5nOik8YnI+Jmd0OyZu YnNwOyAmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyBKb2huIEIuPGJyPiZndDsmbmJzcDsgJmd0OyBP biBKdWwgMjQsIDIwMTQsIGF0IDY6NTIgQU0sIEJyaWFuIENhbXBiZWxsICZsdDtiY2FtcGJlbGxA cGluZ2lkZW50aXR5LmNvbTxicj4mZ3Q7Jm5ic3A7ICZndDsgJmx0O21haWx0bzpiY2FtcGJlbGxA cGluZ2lkZW50aXR5LmNvbSZndDsmZ3Q7IHdyb3RlOjxicj4mZ3Q7Jm5ic3A7ICZndDs8YnI+Jmd0 OyZuYnNwOyAmZ3Q7Jmd0OyBJJ2Qgbm90ZSB0aGF0IHRoZSByZWFjdGlvbiBhdCB0aGUgY29uZmVy ZW5jZSB0byBJYW4ncyBzdGF0ZW1lbnQgd2FzPGJyPiZndDsmbmJzcDsgJmd0OyZndDsgb3Zlcndo ZWxtaW5nbHkgcG9zaXRpdmUuIFRoZXJlIHdhcyBhIHdpZGUgcmFuZ2Ugb2YgaW5kdXN0cnkgcGVv cGxlPGJyPiZndDsmbmJzcDsgJmd0OyZndDsgaGVyZSAtIGltcGxlbWVudGVycywgcHJhY3RpdGlv bmVycywgZGVwbG95ZXJzLCBzdHJhdGVnaXN0cywgZXRjLiAtIGFuZDxicj4mZ3Q7Jm5ic3A7ICZn dDsmZ3Q7IGl0IHNlZW1zIHByZXR0eSBjbGVhciB0aGF0IHRoZSAicm91Z2ggY29uc2Vuc3VzIiBv ZiB0aGUgaW5kdXN0cnkgYXQ8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyBsYXJnZSBpcyB0aGF0IGE0 YyBpcyBub3Qgd2FudGVkIG9yIG5lZWRlZC48YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0Ozxicj4mZ3Q7 Jm5ic3A7ICZndDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsgT24gVGh1LCBKdWwgMjQsIDIw MTQgYXQgNToyOSBBTSwgTmF0IFNha2ltdXJhICZsdDtzYWtpbXVyYUBnbWFpbC5jb208YnI+Jmd0 OyZuYnNwOyAmZ3Q7Jmd0OyAmbHQ7bWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbSZndDsmZ3Q7IHdy b3RlOjxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgQW5kIGhlcmUgaXMgYSBxdW90ZSBmcm9tIElhbidzIGJsb2cuPGJy PiZndDsmbmJzcDsgJmd0OyZndDs8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBbmQgYWx0aG91Z2ggdGhlIGF1dGhl bnRpY2F0aW9uIHdoZWVsIGlzIHJvdW5kLCB0aGF0IGRvZXNu4oCZdDxicj4mZ3Q7Jm5ic3A7ICZn dDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG1l YW4gaXQgaXNu4oCZdCB3aXRob3V0IGl0cyBsdW1wcy4gRmlyc3QsIHdlIGRvIHNlZSBzb21lPGJy PiZndDsmbmJzcDsgJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgcmVpbnZlbnRpbmcgdGhlIHdoZWVsIGp1c3QgdG8gcmVpbnZlbnQgdGhlIHdo ZWVsLiBPQXV0aCBBNEMgaXM8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzaW1wbHkgbm90IGEgZnJ1aXRmdWwgYWN0 aXZpdHkgYW5kIHNob3VsZCBiZSBwdXQgZG93bi48YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0Ozxicj4m Z3Q7Jm5ic3A7ICZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IChTb3VyY2UpPGJyPiZndDsmbmJzcDsgJmd0OyZndDs8YnI+Jmd0OyBodHRwOi8v d3d3LnR1ZXNkYXluaWdodC5vcmcvMjAxNC8wNy8yMy9kby13ZS1oYXZlLWEtcm91bmQtd2hlZWwt eWV0LW11c2luZ3Mtb24taWRlbnRpdHktc3RhbmRhcmRzLXBhcnQtMS5odG1sPGJyPiZndDsmbmJz cDsgJmd0OyZndDs8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7 PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMjAxNC0wNy0y MyAxNjo1MyBHTVQtMDQ6MDAgSm9obiBCcmFkbGV5ICZsdDt2ZTdqdGJAdmU3anRiLmNvbTxicj4m Z3Q7Jm5ic3A7ICZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDttYWlsdG86dmU3 anRiQHZlN2p0Yi5jb20mZ3Q7Jmd0Ozo8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5i c3A7ICZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IEkgdGhvdWdodCBJIGRpZCBwb3N0IHRoaXMgdG8gdGhlIGxpc3QuPGJyPiZndDsmbmJzcDsg Jmd0OyZndDs8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJIGd1ZXNzIEkgaGl0IHRoZSB3cm9uZyByZXBseSBvbiBt eSBwaG9uZS48YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBKb2huIEIuPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU2VudCBmcm9tIG15 IGlQaG9uZTxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgT24gSnVsIDIzLCAy MDE0LCBhdCA0OjUwIFBNLCB0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDxicj4mZ3Q7Jm5ic3A7ICZn dDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZs dDttYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQmZ3Q7IHdyb3RlOjxicj4mZ3Q7Jm5ic3A7 ICZndDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHdlIGFyZSB0d28sIGF0IGxlYXN0IDotKTxicj4m Z3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBXaHkgZGlkbid0IHlvdSBw b3N0IHRoaXMgb24gdGhlIGxpc3Q/PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7PGJyPiZndDsm bmJzcDsgJmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IFdoZW4gd2lsbCBiZSBiZSBhcnJpdmluZz88YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0 OyZndDs8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQW0gMjMuMDcuMjAxNCAxNjozOSwgc2NocmllYiBKb2hu IEJyYWRsZXk6PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZn dDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBJYW4gR2xhemVyIG1lbnRpb25lZCB0aGlzIGluIGhpcyBrZXlub3RlIGF0IENJUyB5ZXN0ZXJk YXkuPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBIaXMgYWR2aWNlIHdhcyBwbGVhc2Ugc3RvcCwmbmJz cDsgd2UgYXJlIGNyZWF0aW5nIGNvbmZ1c2lvbiBhbmQ8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVu Y2VydGFpbnR5Ljxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgV2UgYXJlIGJlY29taW5nIG91ciBvd24g d29ydCBlbmVteS4gKCBteSB2aWV3IHRob3VnaCBJYW4gbWF5PGJyPiZndDsmbmJzcDsgJmd0OyZn dDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBzaGFyZSBpdCk8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJldHVybmluZyBqdXN0IGFuIGlkXyB0 b2tlbiBmcm9tIHRoZSB0b2tlbiBlbmRwb2ludCBoYXM8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGxp dHRsZSByZWFsIHZhbHVlLjxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU29tZXRoaW5nIHJlYWxseSB1 c2VmdWwgdG8gZG8gd291bGQgYmUgc29ydGluZyBvdXQ8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNo YW5uZWxfaWQgc28gd2UgY2FuIGRvIFBvUCBmb3IgaWQgdG9rZW5zIHRvIG1ha2UgdGhlbSBhbmQ8 YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG90aGVyIGNvb2tpZXMgc2VjdXJlIGluIHRoZSBmcm9udCBj aGFubmVsLiZuYnNwOyZuYnNwOyBJIHRoaW5rIHRoYXQgaXM8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGEgYmV0dGVyIHVzZSBvZiB0aW1lLjxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSSBtYXkgYmUgaW4g dGhlIG1pbm9yaXR5IG9waW5pb24gb24gdGhhdCwmbmJzcDsgaXQgd29uJ3QgYmUgdGhlPGJyPiZn dDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBmaXJzdCB0aW1lLjxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZn dDs8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsm Z3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBK b2huIEIuPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTZW50IGZyb20gbXkgaVBob25lPGJyPiZndDsm bmJzcDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgT24gSnVsIDIzLCAy MDE0LCBhdCA0OjA0IFBNLCBUb3JzdGVuIExvZGRlcnN0ZWR0PGJyPiZndDsmbmJzcDsgJmd0OyZn dDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmbHQ7dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQgJmx0O21haWx0bzp0b3JzdGVuQGxvZGRlcnN0 ZWR0Lm5ldCZndDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB3cm90ZTo8YnI+Jmd0OyZuYnNw OyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgWW91IGFyZSByaWdo dCBmcm9tIGEgdGhlb3JldGljYWwgcGVyc3BlY3RpdmUuIFByYWN0aWNhbGx5PGJyPiZndDsmbmJz cDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgdGhpcyB3YXMgY2F1c2VkIGJ5IGVkaXRvcmlhbCBkZWNpc2lvbnMgZHVy aW5nIHRoZSBjcmVhdGlvbjxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9mIHRoZSBSRkMuIEFz IGZhciBhcyBJIHJlbWVtYmVyLCB0aGVyZSB3YXMgYSBkZWZpbml0aW9uIG9mPGJyPiZndDsmbmJz cDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgdGhlIChvbmUpIHRva2VuIGVuZHBvaW50IHJlc3BvbnNlIGluIGVhcmx5 IHZlcnNpb25zLiBObyBvbmU8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBldmVyeSBjb25zaWRl cmVkIHRvIE5PVCByZXNwb25kIHdpdGggYW4gYWNjZXNzIHRva2VuIGZyb208YnI+Jmd0OyZuYnNw OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB0aGUgdG9rZW4gZW5kcG9pbnQuIFNvIG9uZSBtaWdodCBjYWxsIGl0IGFu IGltcGxpY2l0PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXNzdW1wdGlvbi48YnI+Jmd0OyZu YnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBJJ20gd29ycmllZCB0aGF0IHBlb3BsZSBnZXQgdG90YWxseSBjb25m dXNlZCBpZiBhbjxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGV4Y2VwdGlvbiBpcyBpbnRyb2R1 Y2VkIG5vdyBnaXZlbiB0aGUgYnJvYWQgYWRvcHRpb24gb2Y8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBPQXV0aCBiYXNlZCBvbiB0aGlzIGFzc3VtcHRpb24uPGJyPiZndDsmbmJzcDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgcmVnYXJkcyw8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUb3JzdGVuLjxicj4mZ3Q7 Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQW0g MjMuMDcuMjAxNCB1bSAxNTo0MSBzY2hyaWViIFRob21hcyBCcm95ZXI8YnI+Jmd0OyZuYnNwOyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmbHQ7dC5icm95ZXJAZ21haWwuY29tICZsdDttYWlsdG86dC5icm95ZXJAZ21h aWwuY29tJmd0OyZndDs6PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0 OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSXMgaXQgc2FpZCBhbnl3aGVyZSB0aGF0IEFMTCBncmFu dCB0eXBlcyBNVVNUIHVzZSBTZWN0aW9uPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDUu MSByZXNwb25zZXM/IEVhY2ggZ3JhbnQgdHlwZSByZWZlcmVuY2VzIFNlY3Rpb24gNS4xLCBhbmQ8 YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgImFjY2VzcyB0b2tlbiByZXF1ZXN0IiBpcyBv bmx5IGRlZmluZWQgaW4gdGhlIGNvbnRleHQgb2Y8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgdGhlIGRlZmluZWQgZ3JhbnQgdHlwZXMuIFNlY3Rpb24gMi4yIGRvZXNuJ3QgdGFsayBhYm91 dDxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGUgcmVxdWVzdCBvciByZXNwb25zZSBm b3JtYXQuPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmbmJz cDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IExlIDIzIGp1aWwuIDIwMTQgMjE6MzIsICJOYXQgU2FraW11cmEi ICZsdDtzYWtpbXVyYUBnbWFpbC5jb208YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0 O21haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20mZ3Q7Jmd0OyBhIMOpY3JpdCA6PGJyPiZndDsmbmJz cDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IElzIGl0PyBBcGFydCBmcm9tIHRoZSBpbXBsaWNpdCBn cmFudCB0aGF0IGRvZXMgbm90IHVzZTxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB0b2tlbiBlbmRwb2ludCwgYWxsIG90aGVyIGdyYW50IHJlZmVy ZW5jZXMgc2VjdGlvbiA1LjE8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgZm9yIHRoZSByZXNwb25zZSwgaS5lLiwgYWxsIHNoYXJlcyB0aGUgc2Ft ZSByZXNwb25zZS48YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0 OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMjAxNC0wNy0yMyAxNToxOCBHTVQtMDQ6MDAg VGhvbWFzIEJyb3llcjxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmbHQ7dC5icm95ZXJAZ21haWwuY29tICZsdDttYWlsdG86dC5icm95ZXJAZ21h aWwuY29tJmd0OyZndDs6PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJy PiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IEkgaGFkbid0IHJlYWxpemVkIHRoZSBKU09OIHJlc3BvbnNlIHRo YXQgcmVxdWlyZXM8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhlIGFjY2Vzc190b2tlbiBmaWVsZCBp cyBkZWZpbmVkIHBlciBncmFudF90eXBlLDxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzbyBJJ2QgYmUg T0sgdG8gImV4dGVuZCB0aGUgc2VtYW50aWNzIiBhcyBpbiB0aGU8YnI+Jmd0OyZuYnNwOyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgY3VycmVudCBkcmFmdC48YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhhdCB3YXMgYWN0dWFsbHkg bXkgbWFpbiBjb25jZXJuOiB0aGF0IHRoZSB0b2tlbjxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBlbmRw b2ludCBtYW5kYXRlcyBhY2Nlc3NfdG9rZW47IGJ1dCBpdHMgYWN0dWFsbHk8YnI+Jmd0OyZuYnNw OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgbm90IHRoZSBjYXNlLjxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0Ozxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBMZSAyMyBqdWlsLiAyMDE0IDIwOjQ2LCAiTmF0IFNh a2ltdXJhIjxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7c2FraW11cmFAZ21haWwuY29tICZsdDtt YWlsdG86c2FraW11cmFAZ21haWwuY29tJmd0OyZndDsgYTxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyDD qWNyaXQgOjxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5i c3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJIGFncmVlIHdpdGggSm9obiB0aGF0 IG92ZXJsb2FkaW5nPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHJlc3BvbnNlX3R5cGUgQCBhdXRoeiBlbmRwb2ludCBpcyBhIGJhZCBpZGVhLjxicj4mZ3Q7Jm5i c3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJdCBjb21wbGV0ZWx5IGNoYW5nZXMg dGhlIHNlbWFudGljcyBvZiB0aGlzPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHBhcmFtZXRlci4gTk9URTogd2hhdCBJIHdhcyBwcm9wb3Npbmcgd2FzIG5vdDxi cj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGlzIHBhcmFtZXRl ciwgYnV0IGEgbmV3IHBhcmFtZXRlcjxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyByZXNwb25zZV90eXBlIEAgdG9rZW4gZW5kcG9pbnQuPGJyPiZndDsmbmJzcDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEkgYWxzbyB0aGluayBvdmVybG9hZGluZyBn cmFudF90eXBlIGlzIGEgYmFkPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGlkZWEgc2luY2UgaXQgY2hhbmdlcyBpdHMgc2VtYW50aWNzLiBJIHF1b3RlPGJyPiZn dDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZSBkZWZpbml0aW9uIGhl cmUgYWdhaW46PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGdy YW50PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IGNyZWRlbnRpYWwgcmVwcmVzZW50aW5nIHRoZSByZXNvdXJjZTxicj4m Z3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBvd25lcidzIGF1dGhvcml6 YXRpb248YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZ3JhbnRf dHlwZTxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0eXBlIG9m IGdyYW50IHNlbnQgdG8gdGhlIHRva2VuIGVuZHBvaW50IHRvPGJyPiZndDsmbmJzcDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9idGFpbiB0aGUgYWNjZXNzIHRva2VuPGJyPiZndDsm bmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEl0IGlzIG5vdCBhYm91dCBjb250 cm9sbGluZyB3aGF0IGlzIHRvIGJlPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHJldHVybmVkIGZyb20gdGhlIHRva2VuIGVuZHBvaW50LCBidXQgdGhlIGhpbnQ8 YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdG8gdGhlIHRva2Vu IGVuZHBvaW50IGRlc2NyaWJpbmcgdGhlIHR5cGUgb2Y8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgY3JlZGVudGlhbCB0aGUgZW5kcG9pbnQgaGFzIHJlY2VpdmVk LiBJdCBzZWVtczxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0 aGUgImNvbnRyb2wgb2Ygd2hhdCBpcyBiZWluZyByZXR1cm5lZCBmcm9tPGJyPiZndDsmbmJzcDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRva2VuIGVuZHBvaW50IiZuYnNwOyBpcyBq dXN0IGEgc2lkZSBlZmZlY3QuPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IEkgYW0gc29tZXdoYXQgYW1iaXZhbGVudFsxXSBpbiBjaGFuZ2luZyB0aGU8YnI+Jmd0 OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc2VtYW50aWNzIG9mIHRva2Vu IGVuZHBvaW50LCBidXQgaW4gYXMgbXVjaCBhczxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAidGV4dCBpcyB0aGUga2luZyIgZm9yIGEgc3BlYy4sIHdlIHByb2Jh Ymx5PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNob3VsZCBu b3QgY2hhbmdlIHRoZSBzZW1hbnRpY3Mgb2YgaXQgYXM8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgVG9yc3RlbiBwb2ludHMgb3V0LiBJZiBpdCBpcyBvayB0byBj aGFuZ2UgdGhpczxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBz ZW1hbnRpY3MsIEkgYmVsaWV2ZSBkZWZpbmluZyBhIG5ldyBwYXJhbWV0ZXI8YnI+Jmd0OyZuYnNw OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdG8gdGhpcyBlbmRwb2ludCB0byBjb250 cm9sIHRoZSByZXNwb25zZSB3b3VsZDxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBiZSB0aGUgYmVzdCB3YXkgdG8gZ28uIFRoaXMgaXMgd2hhdCBJIGhhdmU8YnI+ Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZGVzY3JpYmVkIHByZXZp b3VzbHkuPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IERlZmlu aW5nIGEgbmV3IGVuZHBvaW50IHRvIHNlbmQgY29kZSB0byBnZXQgSUQ8YnI+Jmd0OyZuYnNwOyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVG9rZW4gYW5kIGZvcmJpZGRpbmcgdGhlIHVz ZSBvZiBpdCBhZ2FpbnN0PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHRva2VuIGVuZHBvaW50IHdvdWxkIG5vdCBjaGFuZ2UgdGhlIHNlbWFudGljczxicj4mZ3Q7 Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBvZiBhbnkgZXhpc3RpbmcgcGFy YW1ldGVyIG9yIGVuZHBvaW50LCB3aGljaDxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBpcyBnb29kLiBIb3dldmVyLCBJIGRvdWJ0IGlmIGl0IGlzIG5vdCB3b3J0 aDxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkb2luZy4gV2hh dCdzIHRoZSBwb2ludCBvZiBhdm9pZGluZyBhY2Nlc3M8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgdG9rZW4gc2NvcGVkIHRvIFVzZXJJbmZvIGVuZHBvaW50IGFm dGVyIGFsbD88YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRGVm aW5pbmcgYSBuZXcgZW5kcG9pbnQgZm9yIGp1c3QgYXZvaWRpbmcgdGhlPGJyPiZndDsmbmJzcDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFjY2VzcyB0b2tlbiBmb3IgdXNlcmluZm8g ZW5kcG9pbnQgc2VlbXMgd2F5PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHRvbyBtdWNoIHRoZSBoZWF2eSB3YWl0IHdheSBhbmQgaXQgYnJlYWtzPGJyPiZndDsm bmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGludGVyb3BlcmFiaWxpeTogaXQg ZGVmZWF0cyB0aGUgcHVycG9zZSBvZjxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBzdGFuZGFyZGl6YXRpb24uPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IEkgaGF2ZSBzdGFydGVkIGZlZWxpbmcgdGhhdCBubyBjaGFuZ2UgaXMg dGhlPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJlc3Qgd2F5 IG91dC48YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTmF0PGJy PiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFsxXSZuYnNwOyBJZiBp bnN0ZWFkIG9mIHNheWluZyAiVG9rZW4gZW5kcG9pbnQgLTxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB1c2VkIGJ5IHRoZSBjbGllbnQgdG8gZXhjaGFuZ2UgYW48 YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXV0aG9yaXphdGlv biBncmFudCBmb3IgYW4gYWNjZXNzIHRva2VuLDxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB0eXBpY2FsbHkgd2l0aCBjbGllbnQgYXV0aGVudGljYXRpb24iLCBp dCB3ZXJlPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNheWlu ZyAiVG9rZW4gZW5kcG9pbnQgLSB1c2VkIGJ5IHRoZSBjbGllbnQgdG88YnI+Jmd0OyZuYnNwOyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZXhjaGFuZ2UgYW4gYXV0aG9yaXphdGlvbiBn cmFudCBmb3IgdG9rZW5zLDxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB0eXBpY2FsbHkgd2l0aCBjbGllbnQgYXV0aGVudGljYXRpb24iLCB0aGVuIGl0PGJyPiZn dDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHdvdWxkIGhhdmUgYmVlbiBP Sy4gSXQgaXMgYW4gZXhwYW5zaW9uIG9mIHRoZTxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBjYXBhYmlsaXR5IHJhdGhlciB0aGFuIGNoYW5naW5nIHRoZSBzZW1h bnRpY3MuPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmbmJz cDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IDIwMTQtMDctMjMgMTM6MzkgR01ULTA0OjAwIE1pa2UgSm9uZXM8YnI+ Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O01pY2hhZWwuSm9u ZXNAbWljcm9zb2Z0LmNvbTxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmbHQ7bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSZndDsmZ3Q7Ojxicj4m Z3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBZb3UgbmVlZCB0 aGUgYWx0ZXJuYXRpdmUgcmVzcG9uc2VfdHlwZTxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB2YWx1ZSAoImNvZGVfZm9y X2lkX3Rva2VuIiBpbiB0aGUgQTRDPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRyYWZ0KSB0byB0ZWxsIHRoZSBBdXRo b3JpemF0aW9uIFNlcnZlciB0bzxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyByZXR1cm4gYSBjb2RlIHRvIGJlIHVzZWQg d2l0aCB0aGUgbmV3PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGdyYW50IHR5cGUsIHJhdGhlciB0aGFuIG9uZSB0byB1 c2Ugd2l0aDxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB0aGUgImF1dGhvcml6YXRpb25fY29kZSIgZ3JhbnQgdHlwZSAo d2hpY2g8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgaXMgd2hhdCByZXNwb25zZV90eXBlPWNvZGUgZG9lcykuPGJyPiZn dDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICpGcm9tOipPQXV0aDxicj4mZ3Q7Jm5ic3A7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBbbWFp bHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O21haWx0bzpvYXV0aC1i b3VuY2VzQGlldGYub3JnJmd0O10gKk9uPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEJlaGFsZiBPZiAqSm9obiBCcmFk bGV5PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICpTZW50OiogV2VkbmVzZGF5LCBKdWx5IDIzLCAyMDE0IDEwOjMzIEFN PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICpUbzoqIHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PGJyPiZndDsmbmJzcDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZs dDttYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICpDYzoqIG9hdXRoQGlldGYub3JnICZsdDttYWlsdG86b2F1dGhAaWV0Zi5v cmcmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICpTdWJqZWN0OiogUmU6IFtPQVVUSC1XR10gTmV3IFZlcnNpb248 YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgTm90aWZpY2F0aW9uIGZvcjxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkcmFmdC1odW50LW9hdXRo LXYyLXVzZXItYTRjLTA1LnR4dDxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 Ozxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5ic3A7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJZiB3 ZSB1c2UgdGhlIHRva2VuIGVuZHBvaW50IHRoZW4gYSBuZXc8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZ3JhbnRfdHlw ZSBpcyB0aGUgYmVzdCB3YXkuPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEl0IHNv cnQgb2Ygb3ZlcmxvYWRzIGNvZGUsIGJ1dCB0aGF0IGlzPGJyPiZndDsmbmJzcDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJldHRlciB0aGFu IG1lc3Npbmcgd2l0aCByZXNwb25zZV90eXBlIGZvcjxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGUgYXV0aG9yaXph dGlvbiBlbmRwb2ludCB0byBjaGFuZ2UgdGhlPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJlc3BvbnNlIGZyb20gdGhl IHRva2VuX2VuZHBvaW50LiZuYnNwOyBUaGF0IGlzPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGluIG15IG9waW5pb24g YSBjaGFtcGlvbiBiYWQgaWRlYS48YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDs8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZuYnNwOyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSW4g ZGlzY3Vzc2lvbnMgZGV2ZWxvcGluZyBDb25uZWN0IHdlPGJyPiZndDsmbmJzcDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRlY2lkZWQgbm90 IHRvIG9wZW4gdGhpcyBjYW4gb2Ygd29ybXM8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYmVjYXVzZSBubyBnb29kIHdv dWxkIGNvbWUgb2YgaXQuPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJy PiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZSB0b2tl bl9lbmRwb2ludCByZXR1cm5zIGEgYWNjZXNzIHRva2VuLjxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBOb3Ro aW5nIHJlcXVpcmVzIHNjb3BlIHRvIGJlIGFzc29jaWF0ZXM8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgd2l0aCB0aGUg dG9rZW4uPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmbmJz cDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoYXQgaXMgdGhlIGJlc3Qg c29sdXRpb24uJm5ic3A7IE5vIGNoYW5nZTxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyByZXF1aXJlZC4mbmJzcDsgQmV0 dGVyIGludGVyb3BlcmFiaWxpdHkgaW4gbXk8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgb3Bpbmlvbi48YnI+Jmd0OyZu YnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDs8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU3RpbGwgb24gbXkgd2F5IHRvIFRPLCBnZXR0aW5nIGlu IGxhdGVyPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRvZGF5Ljxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0Ozxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5i c3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBKb2huIEIuPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsm bmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZn dDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IFNlbnQgZnJvbSBteSBpUGhvbmU8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDs8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZu YnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgT24gSnVsIDIzLCAyMDE0LCBhdCAxMjoxNSBQTSw8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdG9yc3RlbkBsb2Rk ZXJzdGVkdC5uZXQ8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O21haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5l dCZndDsgd3JvdGU6PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZn dDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZSAicmVzcG9uc2UgdHlwZSIgb2YgdGhl IHRva2VuPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGVuZHBvaW50IGlzIGNv bnRyb2xsZWQgYnkgdGhlIHZhbHVlIG9mPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHRoZSBwYXJhbWV0ZXIgImdyYW50X3R5cGUiLiBTbyB0aGVyZTxicj4mZ3Q7Jm5ic3A7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBpcyBubyBuZWVkIHRvIGludHJvZHVjZSBhIG5ldyBwYXJhbWV0 ZXIuPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmbmJzcDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHdydCB0byBhIHBvdGVudGlhbCAibm9fYWNjZXNzX3Rva2Vu Ijxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBncmFudCB0eXBlLiBJIGRvIG5v dCBjb25zaWRlciB0aGlzIGE8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZ29v ZCBpZGVhIGFzIGl0IGNoYW5nZXMgdGhlIHNlbWFudGljczxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBvZiB0aGUgdG9rZW4gZW5kcG9pbnQgKGFzIGFscmVhZHk8YnI+Jmd0OyZu YnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcG9pbnRlZCBvdXQgYnkgVGhvbWFzKS4gVGhpcyBl bmRwb2ludDxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBTFdBWVMgcmVzcG9u ZHMgd2l0aCBhbiBhY2Nlc3MgdG9rZW48YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgdG8gYW55IGdyYW50IHR5cGUuIEkgdGhlcmVmb3JlIHdvdWxkPGJyPiZndDsmbmJzcDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHByZWZlciB0byB1c2UgYW5vdGhlciBlbmRwb2ludCBmb3IgdGhl PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGludGVuZGVkIHB1cnBvc2UuPGJy PiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHJlZ2FyZHMsPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IFRvcnN0ZW4uPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZn dDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IEFtIDIzLjA3LjIwMTQgMTM6MDQsIHNjaHJpZWIgTmF0PGJyPiZndDsgU2Fr aW11cmE6PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmbmJz cDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IElNSE8sIGNo YW5naW5nIHRoZSBzZW1hbnRpY3Mgb2Y8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgInJlc3BvbnNlX3R5cGUiIEAgYXV0aHogZW5kcG9p bnQ8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgdGhpcyB3YXkgaXMgbm90IGEgZ29vZCB0aGluZy48YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8 YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgSW5zdGVhZCwgZGVmaW5pbmcgYSBuZXcgcGFyYW1ldGVyPGJyPiZndDsmbmJzcDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICJyZXNwb25zZV90eXBlIiBA IHRva2VuIGVuZHBvaW50LDxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBhcyBJIGRlc2NyaWJlZCBpbiBteSBwcmV2aW91czxicj4mZ3Q7 Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBtZXNz YWdlLDxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5ic3A7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBwcm9iYWJseSBp cyBiZXR0ZXIuIEF0IGxlYXN0LCBpdDxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkb2VzIG5vdCBjaGFuZ2UgdGhlIHNlbWFudGljcyBv Zjxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB0aGUgcGFyYW1ldGVycyBvZiBSRkM2NzQ5Ljxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4m Z3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBOYXQ8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZu YnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMjAxNC0wNy0yMyAxMjo0OCBHTVQtMDQ6 MDAgVGhvbWFzPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IEJyb3llciAmbHQ7dC5icm95ZXJAZ21haWwuY29tPGJyPiZndDsmbmJzcDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDttYWlsdG86 dC5icm95ZXJAZ21haWwuY29tJmd0OyZndDs6PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IE5vLCBJIG1lYW4gcmVzcG9uc2VfdHlwZT1ub25lIGFuZDxicj4mZ3Q7Jm5i c3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyByZXNwb25z ZV90eXBlPWlkX3Rva2VuIGRvbid0PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGdlbmVyYXRlIGEgY29kZSBvciBhY2Nlc3MgdG9rZW4g c288YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgeW91IGRvbid0IHVzZSB0aGUgVG9rZW4gRW5kcG9pbnQ8YnI+Jmd0OyZuYnNwOyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKHdoaWNoIGlzIG5vdCB0 aGUgc2FtZSBhcyB0aGU8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgQXV0aGVudGljYXRpb24gRW5kcG9pbnQgQlRXKS48YnI+Jmd0OyZu YnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgV2l0aDxicj4mZ3Q7Jm5ic3A7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyByZXNwb25zZV90eXBlPWNv ZGVfZm9yX2lkX3Rva2VuLDxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB5b3UgZ2V0IGEgY29kZSBhbmQgZXhjaGFuZ2UgaXQgZm9yPGJy PiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGFuIGlkX3Rva2VuIG9ubHksIHJhdGhlciB0aGFuIGFuPGJyPiZndDsmbmJzcDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFjY2Vzc190b2tlbiwgc28geW91 J3JlIGNoYW5naW5nPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHRoZSBzZW1hbnRpY3Mgb2YgdGhlIFRva2VuIEVuZHBvaW50Ljxicj4m Z3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBJJ20gbm90IHNheWluZyBpdCdzIGEgYmFkIHRoaW5nLDxicj4m Z3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBq dXN0IHRoYXQgeW91IGNhbid0IHJlYWxseSBjb21wYXJlPGJyPiZndDsmbmJzcDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG5vbmUgYW5kIGlkX3Rva2VuIHdp dGg8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgY29kZV9mb3JfaWRfdG9rZW4uPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmbmJz cDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9uIFdlZCwg SnVsIDIzLCAyMDE0IGF0IDY6NDUgUE0sPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJpY2hlciwgSnVzdGluIFAuPGJyPiZndDsmbmJz cDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDtqcmlj aGVyQG1pdHJlLm9yZzxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmbHQ7bWFpbHRvOmpyaWNoZXJAbWl0cmUub3JnJmd0OyZndDsgd3Jv dGU6PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmbmJzcDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEl0J3Mgb25seSAi bm90IHVzaW5nIHRoZSB0b2tlbjxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBlbmRwb2ludCIgYmVjYXVzZSB0aGUgdG9rZW48YnI+Jmd0 OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZW5k cG9pbnQgY29weS1wYXN0ZWQgYW5kIHJlbmFtZWQ8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhlIGF1dGhlbnRpY2F0aW9uIGVuZHBv aW50Ljxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5ic3A7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBKdXN0aW48YnI+Jmd0OyZuYnNw OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDs8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgT24gSnVsIDIzLCAyMDE0LCBhdCA5OjMwIEFNLDxicj4mZ3Q7Jm5ic3A7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaG9tYXMgQnJveWVy ICZsdDt0LmJyb3llckBnbWFpbC5jb208YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O21haWx0bzp0LmJyb3llckBnbWFpbC5jb20m Z3Q7Jmd0OyB3cm90ZTo8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+ Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgRXhjZXB0IHRoYXQgdGhlc2UgYXJlIGFib3V0IG5vdDxicj4m Z3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB1 c2luZyB0aGUgVG9rZW4gRW5kcG9pbnQgYXQgYWxsLDxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB3aGVyZWFzIHRoZSBjdXJyZW50IHBy b3Bvc2FsIGlzPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IGFib3V0IHRoZSBUb2tlbiBFbmRwb2ludCBub3Q8YnI+Jmd0OyZuYnNwOyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcmV0dXJuaW5nIGFu IGFjY2Vzc190b2tlbiBmaWVsZCBpbjxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGUgSlNPTi48YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8 YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgT24gV2VkLCBKdWwgMjMsIDIwMTQgYXQgNDoyNiBQTSw8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTWlrZSBKb25lczxicj4mZ3Q7 Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7 TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyPiZndDsgJmx0O21haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20m Z3Q7Jmd0Ozxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB3cm90ZTo8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8 YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgVGhlIHJlc3BvbnNlX3R5cGUgIm5vbmUiIGlzPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFscmVhZHkgdXNlZCBpbiBwcmFjdGlj ZSwgd2hpY2g8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgcmV0dXJucyBubyBhY2Nlc3MgdG9rZW4uJm5ic3A7IEl0IHdhczxicj4mZ3Q7 Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhY2Nl cHRlZCBieSB0aGUgZGVzaWduYXRlZCBleHBlcnRzPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFuZCByZWdpc3RlcmVkIGluIHRoZSBJ QU5BIE9BdXRoPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IEF1dGhvcml6YXRpb24gRW5kcG9pbnQgUmVzcG9uc2U8YnI+Jmd0OyZuYnNw OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVHlwZXMgcmVn aXN0cnkgYXQ8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyBo dHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL29hdXRoLXBhcmFtZXRlcnMvb2F1dGgtcGFy YW1ldGVycy54bWwjZW5kcG9pbnQ8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDs8YnI+Jmd0OyAmbHQ7aHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9vYXV0aC1wYXJh bWV0ZXJzL29hdXRoLXBhcmFtZXRlcnMueG1sI2VuZHBvaW50Jmd0Oy48YnI+Jmd0OyZuYnNwOyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhlIHJlZ2lzdGVy ZWQgImlkX3Rva2VuIiByZXNwb25zZTxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0eXBlIGFsc28gcmV0dXJucyBubyBhY2Nlc3MgdG9r ZW4uPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmbmJzcDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNvIEkgdGhpbmsgdGhlIHF1ZXN0aW9uIG9mIHdo ZXRoZXI8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgcmVzcG9uc2UgdHlwZXMgdGhhdCByZXN1bHQgaW4gbm88YnI+Jmd0OyZuYnNwOyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYWNjZXNzIHRva2Vu IGJlaW5nIHJldHVybmVkIGFyZTxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhY2NlcHRhYmxlIHdpdGhpbiBPQXV0aCAyLjAgaXM8YnI+ Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg YWxyZWFkeSBzZXR0bGVkLCBhcyBhIHByYWN0aWNhbDxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBtYXR0ZXIuJm5ic3A7IExvdHMgb2Yg T0F1dGg8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgaW1wbGVtZW50YXRpb25zIGFyZSBhbHJlYWR5IHVzaW5nPGJyPiZndDsmbmJzcDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHN1Y2ggcmVzcG9u c2UgdHlwZXMuPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsm bmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDs8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZuYnNw OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKkZyb206Kk9B dXRoPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZzxicj4mZ3Q7Jm5ic3A7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7bWFpbHRvOm9hdXRo LWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7XTxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAqT24gQmVoYWxmIE9mICpQaGlsIEh1bnQ8YnI+Jmd0 OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKlNl bnQ6KiBXZWRuZXNkYXksIEp1bHkgMjMsIDIwMTQ8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgNzowOSBBTTxicj4mZ3Q7Jm5ic3A7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAqVG86KiBOYXQgU2Fr aW11cmE8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgKkNjOiogJmx0O29hdXRoQGlldGYub3JnPGJyPiZndDsmbmJzcDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDttYWlsdG86b2F1dGhAaWV0 Zi5vcmcmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAqU3ViamVjdDoqIFJlOiBbT0FVVEgtV0ddIE5ldzxicj4mZ3Q7Jm5i c3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3I8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgZHJhZnQtaHVudC1vYXV0aC12Mi11c2VyLWE0Yy0wNS50eHQ8 YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZuYnNwOyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgWWVzLiBUaGlzIGlzIHdoeSBpdCBoYXMgdG8gYmU8YnI+ Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg ZGlzY3Vzc2VkIGluIHRoZSBJRVRGLjxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0Ozxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5ic3A7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBQaGlsPGJyPiZn dDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IEBpbmRlcGVuZGVudGlkPGJyPiZndDsmbmJzcDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHd3dy5pbmRlcGVuZGVudGlkLmNvbTxicj4mZ3Q7Jm5ic3A7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7aHR0cDovL3d3 dy5pbmRlcGVuZGVudGlkLmNvbS8mZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHBoaWwuaHVudEBvcmFjbGUuY29tPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDttYWlsdG86cGhpbC5odW50QG9y YWNsZS5jb20mZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZn dDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJy PiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IE9uIEp1bCAyMywgMjAxNCwgYXQgOTo0MyBBTSwgTmF0PGJyPiZndDsmbmJzcDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNha2ltdXJhICZsdDtzYWtpbXVy YUBnbWFpbC5jb208YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmx0O21haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20mZ3Q7Jmd0OyB3cm90 ZTo8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZuYnNwOyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUmVhZGluZyBiYWNrIHRoZSBSRkM2NzQ5LCBJIGFt IG5vdDxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBzdXJlIGlmIHRoZXJlIGlzIGEgZ29vZCB3YXkgb2Y8YnI+Jmd0OyZuYnNwOyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc3VwcHJlc3NpbmcgYWNj ZXNzIHRva2VuIGZyb20gdGhlPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJlc3BvbnNlIGFuZCBzdGlsbCBiZSBPQXV0aC4gSXQ8YnI+ Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg d2lsbCBicmVhayB3aG9sZSBidW5jaCBvZiBpbXBsaWNpdDxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkZWZpbml0aW9ucyBsaWtlOjxi cj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5ic3A7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhdXRob3JpemF0aW9uIHNlcnZlcjxicj4mZ3Q7Jm5ic3A7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGUgc2VydmVyIGlzc3VpbmcgYWNjZXNzPGJyPiZn dDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRv a2VucyB0byB0aGUgY2xpZW50IGFmdGVyPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHN1Y2Nlc3NmdWxseTxicj4mZ3Q7Jm5ic3A7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhdXRoZW50aWNhdGluZyB0aGUgcmVzb3VyY2U8YnI+Jmd0 OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgb3du ZXIgYW5kIG9idGFpbmluZyBhdXRob3JpemF0aW9uLjxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4m Z3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBB ZnRlciBhbGwsIE9BdXRoIGlzIGFsbCBhYm91dDxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpc3N1aW5nIGFjY2VzcyB0b2tlbnMuPGJy PiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFsc28sIEkgdGFrZSBiYWNrIG15IHN0YXRlbWVudCBvbjxi cj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB0aGUgZ3JhbnQgdHlwZSBpbiBteSBwcmV2aW91cyBtYWlsLjxicj4mZ3Q7Jm5ic3A7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 Ozxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBUaGUgZGVmaW5pdGlvbiBvZiBncmFudCBhbmQ8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZ3JhbnRfdHlwZSBhcmUgcmVzcGVj dGl2ZWx5Ojxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5i c3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBncmFudDxicj4mZ3Q7Jm5ic3A7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjcmVkZW50aWFs IHJlcHJlc2VudGluZyB0aGU8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgcmVzb3VyY2Ugb3duZXIncyBhdXRob3JpemF0aW9uPGJyPiZn dDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IGdyYW50X3R5cGU8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDs8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKHN0cmluZyByZXByZXNlbnRp bmcgdGhlKSB0eXBlPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IG9mIGdyYW50IHNlbnQgdG8gdGhlIHRva2VuPGJyPiZndDsmbmJzcDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGVuZHBvaW50IHRv IG9idGFpbiB0aGUgYWNjZXNzIHRva2VuPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmbmJz cDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRodXMsIHRo ZSBncmFudCBzZW50IHRvIHRoZSB0b2tlbjxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBlbmRwb2ludCBpbiB0aGlzIGNhc2UgaXMgc3Rp bGw8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJ2NvZGUnLjxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4m Z3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSZXNwb25zZSB0eXBlIG9uIHRo ZSBvdGhlciBoYW5kIGlzPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IG5vdCBzbyB3ZWxsIGRlZmluZWQgaW4gUkZDNjc0OSw8YnI+Jmd0 OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYnV0 IGl0IHNlZW1zIGl0IGlzIHJlcHJlc2VudGluZzxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB3aGF0IGlzIHRvIGJlIHJldHVybmVkIGZy b20gdGhlPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IGF1dGhvcml6YXRpb24gZW5kcG9pbnQuIFRvIGV4cHJlc3M8YnI+Jmd0OyZuYnNw OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgd2hhdCBpcyB0 byBiZSByZXR1cm5lZCBmcm9tIHRva2VuPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGVuZHBvaW50LCBwZXJoYXBzIGRlZmluaW5nIGEg bmV3PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHBhcmFtZXRlciB0byB0aGUgdG9rZW4gZW5kcG9pbnQsPGJyPiZndDsmbmJzcDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHdoaWNoIGlzIGEgcGFy YWxsZWwgdG8gdGhlPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHJlc3BvbnNlX3R5cGUgdG8gdGhlIEF1dGhvcml6YXRpb248YnI+Jmd0 OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRW5k cG9pbnQgc2VlbXMgdG8gYmUgYSBtb3JlPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHN5bW1ldHJpYyB3YXksIHRob3VnaCBJIGFtIG5v dDxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBzdXJlIGF0IGFsbCBpZiB0aGF0IGlzIGdvaW5nIHRvIGJlPGJyPiZndDsmbmJzcDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9BdXRoIGFueSBtb3Jl LiBPbmUgc3RyYXctbWFuIGlzPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRvIGRlZmluZSBhIG5ldyBwYXJhbWV0ZXIgY2FsbGVkPGJy PiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHJlc3BvbnNlX3R5cGUgdG8gdGhlIHRva2VuPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGVuZHBvaW50IHN1Y2ggYXM6PGJyPiZndDsm bmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHJlc3BvbnNlX3R5cGU8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDs8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgT1BUSU9OQUwuIEEgc3RyaW5n PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHJlcHJlc2VudGluZyB3aGF0IGlzIHRvIGJlPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJldHVybmVkIGZyb20gdGhlIHRva2Vu IGVuZHBvaW50Ljxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7 Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGVuIGRlZmluZSB0aGUgYmVoYXZp b3Igb2YgdGhlPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IGVuZHBvaW50IGFjY29yZGluZyB0byB0aGUgdmFsdWVzPGJyPiZndDsmbmJz cDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFzIHRoZSBw YXJhbGxlbCB0byB0aGU8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgbXVsdGktcmVzcG9uc2UgdHlwZSBzcGVjLjxicj4mZ3Q7Jm5ic3A7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0Ozxicj4mZ3Q7IGh0dHA6Ly9vcGVuaWQubmV0L3NwZWNzL29hdXRoLXYyLW11bHRpcGxl LXJlc3BvbnNlLXR5cGVzLTFfMC5odG1sPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmbmJz cDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE5hdDxicj4m Z3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxi cj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5ic3A7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAyMDE0LTA3LTIzIDc6MjEgR01ULTA0OjAwIFBoaWw8YnI+ Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg SHVudCAmbHQ7cGhpbC5odW50QG9yYWNsZS5jb208YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O21haWx0bzpwaGlsLmh1bnRAb3Jh Y2xlLmNvbSZndDsmZ3Q7Ojxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxi cj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBUaGUgZHJhZnQgaXMgdmVyeSBjbGVhci48YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDs8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgUGhpbDxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxi cj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5ic3A7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBPbiBKdWwgMjMsIDIwMTQs IGF0IDA6NDYsIE5hdDxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBTYWtpbXVyYSAmbHQ7c2FraW11cmFAZ21haWwuY29tPGJyPiZndDsm bmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDtt YWlsdG86c2FraW11cmFAZ21haWwuY29tJmd0OyZndDsgd3JvdGU6PGJyPiZndDsmbmJzcDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZSBuZXcg Z3JhbnQgdHlwZSB0aGF0IEkgd2FzPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRhbGtpbmcg YWJvdXQgd2FzPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsm bmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsgImF1dGhvcml6YXRpb25fY29k ZV9idXRfZG9fbm90X3JldHVybl9hY2Nlc3Nfbm9yX3JlZnJlc2hfdG9rZW4iLDxicj4mZ3Q7Jm5i c3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBzbyB0byBzcGVhay48YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDs8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSXQgZG9lcyBub3QgcmV0dXJu IGFueXRoaW5nPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHBlciBzZSwgYnV0IGFuIGV4dGVu c2lvbiBjYW48YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZGVmaW5lIHNvbWV0aGluZyBvbiB0 b3Agb2YgaXQuPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsm bmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IFRoZW4sIE9JREMgY2FuIGRlZmluZSBhPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJpbmRp bmcgdG8gaXQgc28gdGhhdCB0aGU8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYmluZGluZyBv bmx5IHJldHVybnMgSUQgVG9rZW4uPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoaXMgYmluZGluZyB3b3JrIHNob3VsZCBi ZTxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkb25lIGluIE9JREYuIFNob3VsZCB0aGVyZSBi ZTxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzdWNoIGEgZ3JhbnQgdHlwZSw8YnI+Jmd0OyZu YnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg aXQgd2lsbCBiZSBhbiBleHRyZW1lbHkgc2hvcnQ8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg c3BlYy48YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZuYnNw OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQXQg dGhlIHNhbWUgdGltZSwgaWYgYW55IG90aGVyPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNw ZWNpZmljYXRpb24gd2FudGVkIHRvIGRlZmluZTxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBvdGhlciB0eXBlIG9mIHRva2Vu cyBhbmQgaGF2ZTxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpdCByZXR1cm5lZCBmcm9tIHRo ZSB0b2tlbjxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBlbmRwb2ludCw8YnI+Jmd0OyZuYnNw OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaXQg Y2FuIGFsc28gdXNlIHRoaXMgZ3JhbnQgdHlwZS48YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDs8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0 OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgSWYgd2hhdCB5b3Ugd2FudCBpcyB0byBkZWZpbmU8YnI+Jmd0 OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgYSBuZXcgZ3JhbnQgdHlwZSB0aGF0IHJldHVybnM8YnI+Jmd0 OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgSUQgVG9rZW4gb25seSw8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhlbiwgSSBhbSB3 aXRoIEp1c3Rpbi4gU2luY2U8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgIm90aGVyIHJlc3Bv bnNlIHRoYW4gSUQgVG9rZW4iPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGlzIG9ubHk8YnI+ Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgdGhlb3JldGljYWwsIHRoaXMgaXMgYSBtb3JlPGJyPiZndDsmbmJzcDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHBsYXVzaWJsZSB3YXkgZm9yd2FyZCwgSTxicj4mZ3Q7IHN1cHBvc2UuPGJyPiZndDsmbmJz cDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE5hdDxicj4mZ3Q7Jm5ic3A7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0Ozxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAyMDE0LTA3LTIyIDE0OjMwIEdNVC0wNDow MDxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBKdXN0aW4gUmljaGVyICZsdDtqcmljaGVyQG1p dC5lZHU8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O21haWx0bzpqcmljaGVyQG1pdC5l ZHUmZ3Q7Jmd0Ozo8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0 OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgU28gdGhlIGRyYWZ0IHdvdWxkIGxpdGVyYWxseTxicj4mZ3Q7 Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB0dXJuIGludG86PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICJUaGUgYTRjIHJlc3BvbnNl IHR5cGUgYW5kPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGdyYW50IHR5cGUgcmV0dXJuIGFu IGlkX3Rva2VuPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGZyb20gdGhlIHRva2VuIGVuZHBv aW50IHdpdGg8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbm8gYWNjZXNzIHRva2VuLiBBbGw8 YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcGFyYW1ldGVycyBhbmQgdmFsdWVzIGFyZTxicj4m Z3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkZWZpbmVkIGluIE9JREMuIjxicj4mZ3Q7Jm5ic3A7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTZWVtcyBs aWtlIHRoZSBwZXJmZWN0IG1pbmk8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZXh0ZW5zaW9u IGRyYWZ0IGZvciBPSURGIHRvIGRvLjxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0Ozxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLUp1c3Rpbjxicj4mZ3Q7Jm5ic3A7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAvc2VudCBm cm9tIG15IHBob25lLzxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4m Z3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBPbiBKdWwgMjIsIDIwMTQgMTA6MjkgQU0sIE5hdDxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBTYWtpbXVyYSAmbHQ7c2FraW11cmFAZ21haWwuY29tPGJyPiZndDsmbmJzcDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZsdDttYWlsdG86c2FraW11cmFAZ21haWwuY29tJmd0OyZndDs8YnI+Jmd0OyZuYnNw OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgd3JvdGU6PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8YnI+ Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBXaGF0IGFib3V0IGp1c3QgZGVmaW5pbmcgYTxi cj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBuZXcgZ3JhbnQgdHlwZSBpbiB0aGlzIFdHPzxicj4m Z3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZn dDs8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyAyMDE0LTA3LTIyIDEyOjU2IEdNVC0w NDowMDxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBQaGlsIEh1bnQ8YnI+Jmd0OyZuYnNwOyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmx0O3BoaWwuaHVudEBvcmFjbGUuY29tPGJyPiZndDsmbmJzcDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZsdDttYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20mZ3Q7Jmd0Ozo8YnI+Jmd0OyZu YnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDs8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0 OyZndDsgVGhhdCB3b3VsZCBiZSBuaWNlLiBIb3dldmVyPGJyPiZndDsmbmJzcDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IG9pZGMgc3RpbGwgbmVlZHMgdGhlIG5ldyBncmFudDxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB0eXBlIGluIG9yZGVyIHRvIGltcGxlbWVudCB0aGU8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgc2FtZSBmbG93Ljxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0Ozxicj4m Z3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyBQaGlsPGJyPiZndDsmbmJzcDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7IE9uIEp1 bCAyMiwgMjAxNCwgYXQgMTE6MzUsPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE5hdCBTYWtp bXVyYTxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7c2FraW11cmFAZ21haWwuY29tPGJy PiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDttYWlsdG86c2FraW11cmFAZ21haWwuY29tJmd0 OyZndDs8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgd3JvdGU6PGJyPiZndDsmbmJzcDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0 OyArMSB0byBKdXN0aW4uPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0Ozxi cj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZuYnNwOyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJmd0OyZndDsmZ3Q7IDIwMTQtMDctMjIgOTo1NCBHTVQtMDQ6MDA8YnI+Jmd0OyZu YnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgUmljaGVyLCBKdXN0aW4gUC48YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJmx0O2pyaWNoZXJAbWl0cmUub3JnPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZs dDttYWlsdG86anJpY2hlckBtaXRyZS5vcmcmZ3Q7Jmd0Ozo8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0 OyZndDsmZ3Q7IEVycm9ycyBsaWtlIHRoZXNlIG1ha2UgaXQ8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgY2xlYXIgdG8gbWUgdGhhdCBpdCB3b3VsZCBtYWtlPGJyPiZndDsmbmJzcDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IG11Y2ggbW9yZSBzZW5zZSB0byBkZXZlbG9wPGJyPiZndDsmbmJzcDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHRoaXMgZG9jdW1lbnQgaW4gdGhlIE9wZW5JRDxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBGb3VuZGF0aW9uLiBJdCBzaG91bGQgYmU8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc29t ZXRoaW5nIHRoYXQgZGlyZWN0bHk8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcmVmZXJlbmNl cyBPcGVuSUQgQ29ubmVjdCBDb3JlPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGZvciBhbGwg b2YgdGhlc2UgdGVybXMgaW5zdGVhZDxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBvZiByZWRl ZmluaW5nIHRoZW0uIEl0J3MgZG9pbmc8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXV0aGVu dGljYXRpb24sIHdoaWNoIGlzPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGZ1bmRhbWVudGFs bHkgd2hhdCBPcGVuSUQ8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQ29ubmVjdCBkb2VzIG9u IHRvcCBvZiBPQXV0aCw8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYW5kIEkgZG9uJ3Qgc2Vl IGEgZ29vZDxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhcmd1bWVudCBmb3IgZG9pbmcgdGhp cyB3b3JrPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGluIHRoaXMgd29ya2luZyBncm91cC48 YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5ic3A7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7IC0tIEp1c3Rpbjxicj4mZ3Q7Jm5i c3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsmZ3Q7Jmd0OyZndDsgT24gSnVsIDIyLCAyMDE0LCBhdCA0OjMwPGJyPiZndDsmbmJz cDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IEFNLCBUaG9tYXMgQnJveWVyPGJyPiZndDsmbmJzcDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZsdDt0LmJyb3llckBnbWFpbC5jb208YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0 O21haWx0bzp0LmJyb3llckBnbWFpbC5jb20mZ3Q7Jmd0Ozxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB3cm90ZTo8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0Ozxi cj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5i c3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5ic3A7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPbiBNb24sIEp1bCAyMSwgMjAxNCBhdDxicj4mZ3Q7Jm5ic3A7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAxMTo1MiBQTSwgTWlrZSBKb25lczxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmbHQ7TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPGJyPiZndDsmbmJzcDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsgJmx0O21haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jv c29mdC5jb20mZ3Q7Jmd0Ozxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB3cm90ZTo8YnI+Jmd0 OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmbmJz cDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGFua3MgZm9yIHlvdXIg cmV2aWV3LDxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaG9tYXMuJm5ic3A7IFRoZSAicHJv bXB0PWNvbnNlbnQiPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRlZmluaXRpb24gYmVpbmcg bWlzc2luZyBpcyBhbjxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBlZGl0b3JpYWwgZXJyb3Iu Jm5ic3A7IEl0IHNob3VsZCBiZTo8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDs8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IGNvbnNlbnQ8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBU aGUgQXV0aG9yaXphdGlvbjxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTZXJ2ZXIgU0hPVUxE IHByb21wdCB0aGU8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRW5kLVVzZXIgZm9yIGNvbnNl bnQgYmVmb3JlPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJldHVybmluZyBpbmZvcm1hdGlv biB0byB0aGU8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQ2xpZW50LiBJZiBpdCBjYW5ub3Qg b2J0YWluPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNvbnNlbnQsIGl0IE1VU1QgcmV0dXJu IGFuPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGVycm9yLCB0eXBpY2FsbHk8YnI+Jmd0OyBj b25zZW50X3JlcXVpcmVkLjxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDs8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 Ozxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSSds bCBwbGFuIHRvIGFkZCBpdCBpbjxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGUgbmV4dCBk cmFmdC48YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+ Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZuYnNw OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgSXQgbG9va3MgbGlrZSB0aGU8YnI+ Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY29uc2VudF9yZXF1aXJlZCBlcnJvciBuZWVkczxicj4m Z3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0byBiZSBkZWZpbmVkIHRvbywgYW5kIHlvdTxicj4mZ3Q7 Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBtaWdodCBoYXZlIGZvcmdvdHRlbiB0byBhbHNvPGJyPiZndDsm bmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IGltcG9ydDxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhY2Nv dW50X3NlbGVjdGlvbl9yZXF1aXJlZDxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBmcm9tIE9w ZW5JRCBDb25uZWN0Ljxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0Ozxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8 YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZn dDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5i c3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSSBhZ3JlZSB0aGF0IHRo ZXJlJ3Mgbm88YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZGlmZmVyZW5jZSBiZXR3ZWVuIGEg cmVzcG9uc2U8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgd2l0aCBtdWx0aXBsZSAiYW1yIiB2 YWx1ZXM8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhhdCBpbmNsdWRlcyAibWZhIiBhbmQg b25lPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoYXQgZG9lc24ndC4mbmJzcDsgVW5sZXNz IGEgY2xlYXI8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdXNlIGNhc2UgZm9yIHdoeSAibWZh IiBpczxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBuZWVkZWQgY2FuIGJlIGlkZW50aWZpZWQs IHdlPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNhbiBkZWxldGUgaXQgaW4gdGhlIG5leHQg ZHJhZnQuPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJy PiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmbmJz cDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoYW5rcy48YnI+Jmd0OyZuYnNw OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgSG93IGFib3V0ICJwd2QiIHRoZW4/IEk8YnI+Jmd0 OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgZnVsbHkgdW5kZXJzdGFuZCB0aGF0IEkgc2hvdWxkPGJyPiZn dDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJldHVybiAicHdkIiBpZiB0aGUgdXNlcjxicj4mZ3Q7Jm5i c3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBhdXRoZW50aWNhdGVkIHVzaW5nIGE8YnI+Jmd0OyZuYnNwOyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgcGFzc3dvcmQsIGJ1dCB3aGF0ICJ0aGU8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgc2VydmljZSBpZiBhIGNsaWVudCBzZWNyZXQgaXM8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgdXNlZCIgbWVhbnMgaW4gdGhlIGRlZmluaXRpb248YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgZm9yIHRoZSAicHdkIiB2YWx1ZT88YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsgKE5vdGE6IEkga25vdyB5b3UncmUgYXQ8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg SUVURi05MCwgSSdtIHJlYWR5IHRvIHdhaXQ8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJ3Rp bCB5b3UgY29tZSBiYWNrIDstKSApPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IC0tPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRo b21hcyBCcm95ZXI8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsgL3TJlC5tYS5iyoF3YS5qZS88YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDs8YnI+Jmd0OyAmbHQ7aHR0cDovL3huLS1ubmEubWEueG4tLWJ3YS14eGIuamUvJmd0Ozxicj4m Z3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5ic3A7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPQXV0aEBpZXRmLm9yZzxicj4mZ3Q7Jm5ic3A7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmbHQ7bWFpbHRvOk9BdXRoQGlldGYub3JnJmd0Ozxicj4mZ3Q7Jm5ic3A7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vb2F1dGg8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4m Z3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0 OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4m Z3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPiZn dDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsgT0F1dGggbWFpbGluZyBsaXN0 PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsgT0F1dGhAaWV0Zi5v cmc8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O21haWx0bzpPQXV0aEBpZXRmLm9yZyZn dDs8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5i c3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vb2F1dGg8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZn dDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDs8YnI+Jmd0 OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsg LS08YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7IE5hdCBTYWtpbXVyYSAo PW5hdCk8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7IENoYWlybWFuLCBP cGVuSUQgRm91bmRhdGlvbjxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDsg aHR0cDovL25hdC5zYWtpbXVyYS5vcmcvPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsm Z3Q7Jmd0OyBAX25hdF9lbjxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyZndDs8 YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsm Z3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0 OyZndDsgT0F1dGhAaWV0Zi5vcmc8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O21haWx0 bzpPQXV0aEBpZXRmLm9yZyZndDs8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZndDsm Z3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsgaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxicj4mZ3Q7Jm5ic3A7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8YnI+Jmd0OyZuYnNw OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0Ozxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7PGJyPiZn dDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgLS08YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jmd0OyBOYXQgU2FraW11cmEgKD1uYXQpPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsg Q2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZn dDsgaHR0cDovL25hdC5zYWtpbXVyYS5vcmcvPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZn dDsgQF9uYXRfZW48YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0 OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+ Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS08YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTmF0 IFNha2ltdXJhICg9bmF0KTxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxi cj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBDaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb248YnI+ Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaHR0cDovL25hdC5zYWtpbXVyYS5vcmcvPGJyPiZndDsm bmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IEBfbmF0X2VuPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsm bmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IC0tPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE5hdCBTYWtpbXVyYSAoPW5hdCk8YnI+Jmd0OyZuYnNwOyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQ2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uPGJy PiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGh0dHA6Ly9uYXQuc2FraW11cmEub3JnLzxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBAX25hdF9lbjxicj4mZ3Q7Jm5ic3A7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 Ozxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5ic3A7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4mZ3Q7Jm5ic3A7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBPQXV0aEBpZXRm Lm9yZzxicj4mZ3Q7ICZsdDttYWlsdG86T0F1dGhAaWV0Zi5vcmcmZ3Q7PGJyPiZndDsmbmJzcDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9vYXV0aDxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 Ozxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5ic3A7ICZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0Ozxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAtLTxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBUaG9tYXMgQnJveWVyPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC90yZQubWEuYsqBd2EuamUvPGJyPiZndDsm bmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDto dHRwOi8veG4tLW5uYS5tYS54bi0tYndhLXh4Yi5qZS8mZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 PGJyPiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9BdXRoQGlldGYub3JnPGJyPiZndDsgJmx0O21haWx0 bzpPQXV0aEBpZXRmLm9yZyZndDs8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDs8YnI+Jmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGJy PiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tPGJyPiZndDsmbmJz cDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRob21hcyBC cm95ZXI8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgL3TJlC5tYS5iyoF3YS5qZS88YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O2h0dHA6Ly94bi0tbm5hLm1hLnhuLS1i d2EteHhiLmplLyZndDs8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+ Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+Jmd0OyZuYnNwOyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgT0F1dGhAaWV0Zi5vcmc8 YnI+Jmd0OyAmbHQ7bWFpbHRvOk9BdXRoQGlldGYub3JnJmd0Ozxicj4mZ3Q7Jm5ic3A7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vb2F1dGg8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+ Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8 YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgLS08YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgTmF0IFNha2ltdXJhICg9bmF0KTxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBDaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb248YnI+Jmd0OyZuYnNwOyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaHR0cDovL25hdC5z YWtpbXVyYS5vcmcvPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IEBfbmF0X2VuPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmbmJz cDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsgX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDs8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IE9BdXRoQGlldGYub3JnPGJyPiZndDsgJmx0O21haWx0bzpPQXV0aEBp ZXRmLm9yZyZndDs8YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0 OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsm bmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+Jmd0OyZuYnNwOyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgT0F1dGggbWFp bGluZyBsaXN0PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9BdXRoQGlldGYu b3JnICZsdDttYWlsdG86T0F1dGhAaWV0Zi5vcmcmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9vYXV0aDxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7 Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4mZ3Q7Jm5ic3A7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBP QXV0aEBpZXRmLm9yZyAmbHQ7bWFpbHRvOk9BdXRoQGlldGYub3JnJmd0Ozxicj4mZ3Q7Jm5ic3A7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGJyPiZndDsmbmJzcDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmbmJz cDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tPGJyPiZndDsmbmJzcDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE5hdCBTYWtpbXVyYSAoPW5hdCk8YnI+Jmd0OyZuYnNw OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQ2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0 aW9uPGJyPiZndDsmbmJzcDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGh0dHA6Ly9u YXQuc2FraW11cmEub3JnLzxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBAX25hdF9lbjxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4m Z3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4mZ3Q7Jm5ic3A7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyA8L2JvZHk+PC9odG1sPg== ----_com.android.email_486516192215700-- From nobody Mon Oct 13 07:18:39 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 674B41A0019; Mon, 13 Oct 2014 07:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 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_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5t0NP7YaCwna; Mon, 13 Oct 2014 07:18:17 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9254D1A0049; Mon, 13 Oct 2014 07:18:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2960; q=dns/txt; s=iport; t=1413209891; x=1414419491; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=ZjvozyZbPaNCcnRHR/YRvp994mX1h0aBFFVMLMrs+uY=; b=VHze5dob/pw0NJtbonhplqzN6n8NXD5QBfIUV4CR4lgPpAQp/diCDgcU 2hh7xhs+clX8SeZe7r3AGnSGrOpTb7300pgL9ohWRBMiDYPkRAdOjWEZc wLTDbPzZtRzz6UmKBgkdXKbpSeqF4F034/bicncHz76deqfnoh17iaksn w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqoEAObeO1StJssW/2dsb2JhbABbg2FYgwa+S4lWh00CgTEBfYQCAQEBBCMVQAEMBAsOAwQBAQECAgUWCAMCAgkDAgECATQJCAYBDAEFAgEBBYg1Da9QlQsBAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSyONxEBUAcGgnGBVAEEhi2QDocQgS48gwqCcootg36CNIFFOy8BgQ6BOwEBAQ X-IronPort-AV: E=Sophos;i="5.04,711,1406592000"; d="scan'208";a="209150624" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 13 Oct 2014 14:18:01 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s9DEI0LS023608; Mon, 13 Oct 2014 14:18:00 GMT Message-ID: <543BDF18.7040606@cisco.com> Date: Mon, 13 Oct 2014 16:18:00 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: Mike Jones , The IESG References: <20141013133343.28609.70075.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739439BAFCE22@TK5EX14MBXC286.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439BAFCE22@TK5EX14MBXC286.redmond.corp.microsoft.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/LuFbgeJH6LyBCZ76QfEe7ZP0JXM Cc: "oauth-chairs@tools.ietf.org" , "draft-ietf-oauth-saml2-bearer@tools.ietf.org" , "oauth@ietf.org" , Tom Taylor Subject: Re: [OAUTH-WG] Benoit Claise's Discuss on draft-ietf-oauth-saml2-bearer-21: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 14:18:25 -0000 On 13/10/2014 16:13, Mike Jones wrote: > Thanks for your review Benoit. I'm adding the working group to the thread so they're aware of your comments. Replies inline below... > >> -----Original Message----- >> From: Benoit Claise [mailto:bclaise@cisco.com] >> Sent: Monday, October 13, 2014 6:34 AM >> To: The IESG >> Cc: Tom Taylor; oauth-chairs@tools.ietf.org; draft-ietf-oauth-saml2- >> bearer@tools.ietf.org >> Subject: Benoit Claise's Discuss on draft-ietf-oauth-saml2-bearer-21: (with >> DISCUSS and COMMENT) >> >> Benoit Claise has entered the following ballot position for >> draft-ietf-oauth-saml2-bearer-21: Discuss >> >> When responding, please keep the subject line intact and reply to all email >> addresses included in the To and CC lines. (Feel free to cut this introductory >> paragraph, however.) >> >> >> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> No objection on the document itself, but, as rightly noted by Tom Taylor in the >> OPS-DIR review: >> Process issue: IDnits complains of a normative reference to Informational >> document RFC 6755. This was NOT noted in the Last Call announcement (but >> was noted in the Shepherd writeup). No operational issue identified beyond >> what is already covered by the Interoperability Considerations section. >> >> As an example, in the case of >> http://datatracker.ietf.org/doc/rfc7317/history/, I had to redo the IETF LC with >> the appropriate statement (based on a DISCUSS from my fellow-AD). >> We should be consistent here. > Barry Leiba had written in response to this "I think the right answer here is to make 6755 an informative reference: it's not needed to understand this document, and is only used as a reference to the document where the namespace was created." I agree that this resolution would be fine. Fine with me. Regards, Benoit > >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Editorial Nits: >> >> S2.2: The paragraph before the actual example uses terminology inconsistent >> with RFC 6749: >> >> s/authorization code grant/authorization grant/ > Per my reply on October 6 to Tom Taylor's review which made the same comment, actually, RFC 6749 uses both terms. Authorization grant is the generic term. Authorization Code Grant (defined in Section 4.1 of 6749) is a specific kind of authorization grant. The text is correct as-is. > > Thanks again, > -- Mike > From nobody Mon Oct 13 07:26:23 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21F4C1A000F; Mon, 13 Oct 2014 07:26:21 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awwpbxKjxODe; Mon, 13 Oct 2014 07:26:18 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0148.outbound.protection.outlook.com [65.55.169.148]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B1371A0006; Mon, 13 Oct 2014 07:26:18 -0700 (PDT) Received: from BY2PR03CA060.namprd03.prod.outlook.com (10.141.249.33) by CY1PR0301MB1212.namprd03.prod.outlook.com (25.161.212.146) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Mon, 13 Oct 2014 14:26:16 +0000 Received: from BL2FFO11FD026.protection.gbl (2a01:111:f400:7c09::149) by BY2PR03CA060.outlook.office365.com (2a01:111:e400:2c5d::33) with Microsoft SMTP Server (TLS) id 15.0.1049.19 via Frontend Transport; Mon, 13 Oct 2014 14:26:15 +0000 Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD026.mail.protection.outlook.com (10.173.161.105) with Microsoft SMTP Server (TLS) id 15.0.1039.16 via Frontend Transport; Mon, 13 Oct 2014 14:26:15 +0000 Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.93]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.03.0210.003; Mon, 13 Oct 2014 14:25:40 +0000 From: Mike Jones To: Benoit Claise , Tim Wicinski , "ops-dir@ietf.org" , "draft-ietf-oauth-jwt-bearer.all@tools.ietf.org" , "oauth@ietf.org" Thread-Topic: [OPS-DIR] ops-dir review of draft-ietf-oauth-jwt-bearer-10 Thread-Index: AQHP5uvyNSY5KnmS+kqnJp20MyJqKZwuEkuA Date: Mon, 13 Oct 2014 14:25:39 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439BAFCEC6@TK5EX14MBXC286.redmond.corp.microsoft.com> References: <5423FB05.5030404@gmail.com> <543BD768.70802@cisco.com> In-Reply-To: <543BD768.70802@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(43784003)(377454003)(199003)(189002)(13464003)(46034005)(51704005)(2501002)(97736003)(31966008)(86612001)(76176999)(107886001)(81156004)(23726002)(50466002)(54356999)(50986999)(95666004)(104016003)(64706001)(20776003)(47776003)(85306004)(107046002)(26826002)(106466001)(106116001)(77096002)(66066001)(230783001)(33656002)(80022003)(46102003)(21056001)(2656002)(84676001)(85852003)(19580405001)(97756001)(19580395003)(2201001)(69596002)(44976005)(46406003)(76482002)(6806004)(68736004)(15975445006)(99396003)(87936001)(55846006)(4396001)(92566001)(92726001)(85806002)(86362001)(120916001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB1212; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB1212; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 03630A6A4A Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/XXNPZ0leW6gLiBpUwtQQGMH_kcc Subject: Re: [OAUTH-WG] [OPS-DIR] ops-dir review of draft-ietf-oauth-jwt-bearer-10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 14:26:21 -0000 Thanks for your review, Tim. I've added the working group to the thread so= they're aware of your comments. Replies are inline below... > -----Original Message----- > From: Benoit Claise [mailto:bclaise@cisco.com] > Sent: Monday, October 13, 2014 6:45 AM > To: Tim Wicinski; ops-dir@ietf.org; draft-ietf-oauth-jwt- > bearer.all@tools.ietf.org > Subject: Re: [OPS-DIR] ops-dir review of draft-ietf-oauth-jwt-bearer-10 >=20 > Hi Tim, >=20 > [including draft-ietf-oauth-jwt-bearer.all@tools.ietf.org] >=20 > Thanks for your review. > Note that I-D.ietf-oauth-assertions is on the IESG telechat this Thursday= , along > with I-D.draft-ietf-oauth-jwt-bearer >=20 > Regards, Benoit > > > > I have reviewed this document as part of the Operational directorate's > > ongoing effort to review all IETF documents being processed by the > > IESG. These comments were written primarily for the benefit of the > > operational area directors. Document editors and WG chairs should > > treat these comments just like any other last call comments. > > > > Summary: Ready with some questions > > > > Editorial Nits: > > > > Terminology; there are several terms in the draft which are used, and > > in the Terminology section, the authors refer to 3 different drafts. > > However though documents use this terminology in a standard format (ex > > 'Authorization Grant'), but this document fails to follow this format. It's not clear, at least to me, what the specific ask is or asks are here. = Tom, if you want specific changes, if you were to give specific examples o= f what you'd like to see, that would be helpful in understanding the commen= t. As for there being three drafts, the Assertions draft is the base draft and= the SAML and JWT drafts are specializations of that base draft to specific= token types. Terminology common to all three is defined in the base draft= . > > Editorially, I would think with multiple documents as sources, the > > terminologies should be attributed to specific documents. This may be > > my personal opinion. Again, common terms are defined in the base document, not the token type sp= ecific specialization documents. > > Section 2: The draft is referencing work done on a draft that has not > > been published, I-D.ietf-oauth-assertions but is being the basis for > > this draft. I would think this document should wait until that draft > > has been published, as it could change before publication. > > > > I got hung up on that issue, and while I read the rest of the draft > > and it does appear to be ready for publication with some editorial > > bits, I felt I gave some of the later sections less vigorous approach > > based on my previous blocker. The three documents will proceed to RFC status as a group. The RFC Editor = has a mechanism for keeping such document clusters together. > > tim > > > > _______________________________________________ > > OPS-DIR mailing list > > OPS-DIR@ietf.org > > https://www.ietf.org/mailman/listinfo/ops-dir Thanks again, -- Mike From nobody Mon Oct 13 07:29:04 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 752161A0076 for ; Mon, 13 Oct 2014 07:29:00 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvdqAcsJo_yX for ; Mon, 13 Oct 2014 07:28:53 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CD0F1A0070 for ; Mon, 13 Oct 2014 07:28:53 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id y10so8660121wgg.3 for ; Mon, 13 Oct 2014 07:28:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=oLLzYFDB8L5f+TnvvRukmPuL6WFchDhx6AwOpJgw3Kc=; b=YYtvV4hMeWDmGpphSBatcoZ4fEgZqMfJNovX4cc22fECB1Yyi30qVQZQAtf1g99xX7 AZGyYEiRviMr0+bpo+1LCDoNpbEmhkxF/F2dVDAbPz43MrHvMnGDAixrkgZG7QxqrKCr FPOsKFuCKEAziOIxCWR4RHCx/0406M3VsUz7fcril5Hl/iCO/FJC4Njb8pENn2FPxMhG EGI9ygF25vWqeQjkUAJsbfEvFizzXPD/b4iJhBNsb0GADuLI1/U8G6woz+GA6ZOdZ01k PdoUFkkw9V3fxngjM9JsqCfGlYB3jw5lZ/3QGJFJRbnGtsqtvTxkKsLpNp/F9AXQ0nyq YQBA== X-Received: by 10.194.110.104 with SMTP id hz8mr22058958wjb.12.1413210531803; Mon, 13 Oct 2014 07:28:51 -0700 (PDT) Received: from [10.36.226.2] ([80.169.137.63]) by mx.google.com with ESMTPSA id q5sm12368662wiy.16.2014.10.13.07.28.50 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Oct 2014 07:28:51 -0700 (PDT) Message-ID: <543BE1A1.6020902@gmail.com> Date: Mon, 13 Oct 2014 15:28:49 +0100 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Justin Richer , oauth@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/zR7oD1nbSCRCjkSK1U0tHqCpQnc Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 14:29:01 -0000 On 13/10/14 15:17, Justin Richer wrote: > You certainly can do authentication without using an access token, but > then I would argue that's no longer OAuth. Basically you're making tofu > carob fudge. Right, the access token is there for a client to get to the UserInfo endpoint, as far as OIDC is concerned. What if the info in the id_token is sufficient ? I guess as far as a typical OAuth2 client is concerned, requesting "openid profile" only effectively gives one an access token that can only be used with the UserInfo endpoint. So yes, may be even though OIDC has an access token returned, unless other custom scopes are used, the access token would be pretty much of use in the OIDC context only if a client chooses to work with the UserInfo...I guess the id_token/at_hash is useful on its own Cheers, Sergey > > > -- Justin > > / Sent from my phone / > > > -------- Original message -------- > From: Sergey Beryozkin > Date:10/13/2014 9:00 AM (GMT-05:00) > To: Justin Richer , oauth@ietf.org > Cc: > Subject: Re: [OAUTH-WG] New Version Notification for > draft-hunt-oauth-v2-user-a4c-05.txt > > Hi Justin, > On 13/10/14 12:53, Justin Richer wrote: > > You are correct in that OAuth 2 and OpenID Connect are not the same > > thing, but your user is correct that OIDC adds a few pieces on top of > > OAuth to add authentication capabilities. OIDC was designed very > > explicitly to be compatible with vanilla OAuth, partially do that people > > would be able to deploy it on top of existing OAuth infrastructure and > > code. But the very fact that OIDC adds a few things on top of OAuth to > > give more functionality should be sufficient evidence that they're not > > equivalent. > > > > It's more proper to say that OpenID Connect is an extension and > > application of OAuth. One that provides an authentication and > identity API. > > > I agree and this is more or less how I answered. > > Though the 'borders' can be blurred, one can claim that if a user > actually logs on into a confidential OAuth2 client web application which > redirects this user to AS requesting a code with some scopes such as "a > b" then when it uses "a b openid profile" it is basically does a pure > OAuth2 code flow where the client requests 'a b' plus also a scope > allowing it later to query the identity system on behalf of a user. > > I like the "The extension and application of OAuth2" characteristic of > OIDC. IMHO it's becoming more obvious if OIDC is used to support SSO > into non-OAuth2 servers, when it is the case then there's no 'feeling' > that OIDC is just a case of the confidential client adding the extra > scopes and getting the extra (authentication) info back. A standalone > OIDC RP protecting such non OAuth2 servers is very much about the > authentication/identity. > > I also thought that having some OID profile (as opposed updating OAuth2 > to support no access tokens) where no access but only id token was > returned (as suggested in this thread) would probably make sense too. > > > The way I like to explain it (which I stole from someone else) is that > > OAuth is like chocolate and authentication is like fudge. They are not > > the same thing. You can make chocolate into fudge out you can make it > > into something else or you can just have it on its own. You can make > > fudge with chocolate or you can make it with peanut butter or you can > > make it with potatoes if you want to, but it needs a couple ingredients > > and a very common one is chocolate. OpenID Connect is a recipe for > > chocolate fudge that a lot of people like. And it makes my fudge > > compatible with your fudge, which is where the metaphor breaks down. :-) > > > Thanks for sharing this colourful explanation :-). Perhaps I should > borrow it :-), > Cheers, Sergey > > > > > > -- Justin > > > > / Sent from my phone / > > > > > > -------- Original message -------- > > From: Sergey Beryozkin > > Date:10/13/2014 6:33 AM (GMT-05:00) > > To: oauth@ietf.org > > Cc: > > Subject: Re: [OAUTH-WG] New Version Notification for > > draft-hunt-oauth-v2-user-a4c-05.txt > > > > Hi > > > > We've had a user asserting that "OAuth2 == OpenidConnect", referring to > > the fact that the 'only' thing OIC adds on top of the authorization code > > flow is the client specifying few extra scopes like 'openid' and > > 'profile' and the authorization service returning an extra property, the > > id_token which can be sufficient in order to get the authenticated > > user's info. > > > > My understanding "OAuth2 != OpenidConnect", the latter utilizes the > > former and is an authentication mechanism which is not what OAuth2 is > > (may be except for the client credentials). But I don't feel like it is > > a convincing enough argument. > > > > I thought this thread was relevant, sorry if not, would have no problems > > starting a new one. > > > > Basically, I wonder what is the proper line of argument for a position > > such as "OAuth2 != OpenidConnect" and also what was the action to the > > list of options suggested by John below. Is having an OID profile where > > no access token is returned would be the cleanest action as far as > > breaking the ambiguity/confusion is concerned ? > > > > Cheers, Sergey > > > > On 24/07/14 15:25, John Bradley wrote: > > > I am not against discussion in the WG. > > > > > > I happen to agree with Phil's fundamental premise that some developers > > > are using OAuth in a insecure way to do authentication. > > > > > > That raises the question of how to best educate them, and or address > > > technical barriers. > > > > > > It is on the second point that people's opinions seem to divide. > > > > > > Some people thing that if we have a OAuth flow that eliminates the > > > access token (primarily to avoid asking for consent as I > understand it) > > > and just return a id_token from the token endpoint that can be > done in a > > > spec short enough to het people to read. The subtext of this is that > > > the Connect specification is too large that it scare people, and they > > > don't find the spec in the first place because it is not a RFC. > > > > > > An other common possession is that if you don't want to prompt the > user > > > for consent then don't ask for scopes. Twisting the OAuth spec to not > > > return an access token is not OAuth, yes you could use a different > > > endpoint rather than the token endpoint, but that is not OAuth. > > > Connect was careful not to break the OAuth spec. As long as you are > > > willing to take a access token with no scopes (the client needs to > > > understand that there are no attributes one way or another anyway > or it > > > will break) then you don't need to change OAuth. You can publish a > > > profile of connect that satisfies the use case. > > > > > > I think Mike has largely done that but it might be better being less > > > stingy on references back to the larger spec. > > > > > > The questions are do we modify OAuth to not return an access > token, and > > > if so how, and if we do is it still OAuth. > > > > > > The other largely separable question is do we create confusion in the > > > market and slow the the adoption of identity federation on top of > OAuth, > > > or find a way to make this look like a positive alignment of interests > > > around a subset of Connect. > > > > > > There are a number of options. > > > 1: We can do a profile in the OIDF and publish it as a IETF document. > > > Perhaps the cleanest from an IPR point of view.However > > > 2:We can do a profile in the OAuth WG referencing connect. > > > 3:We can do a AD sponsored profile that is not in the OAuth WG. > > > 4:We can do a small spec in OAuth to add response_type to the token > > > endpoint. in combination with 1, 2, or 3 > > > > > > I agree that stoping developers doing insecure things needs to be > > > addressed somehow. > > > I am not personally convinced that Oauth without access tokens is > > sensible. > > > > > > Looking forward to the meeting:) > > > > > > John B. > > > On Jul 24, 2014, at 6:52 AM, Brian Campbell > > > > wrote: > > > > > >> I'd note that the reaction at the conference to Ian's statement was > > >> overwhelmingly positive. There was a wide range of industry people > > >> here - implementers, practitioners, deployers, strategists, etc. > - and > > >> it seems pretty clear that the "rough consensus" of the industry at > > >> large is that a4c is not wanted or needed. > > >> > > >> > > >> On Thu, Jul 24, 2014 at 5:29 AM, Nat Sakimura > >> > wrote: > > >> > > >> And here is a quote from Ian's blog. > > >> > > >> And although the authentication wheel is round, that doesn’t > > >> mean it isn’t without its lumps. First, we do see some > > >> reinventing the wheel just to reinvent the wheel. OAuth > A4C is > > >> simply not a fruitful activity and should be put down. > > >> > > >> (Source) > > >> > > > http://www.tuesdaynight.org/2014/07/23/do-we-have-a-round-wheel-yet-musings-on-identity-standards-part-1.html > > >> > > >> > > >> > > >> 2014-07-23 16:53 GMT-04:00 John Bradley > >> >: > > >> > > >> I thought I did post this to the list. > > >> > > >> I guess I hit the wrong reply on my phone. > > >> John B. > > >> Sent from my iPhone > > >> > > >> On Jul 23, 2014, at 4:50 PM, torsten@lodderstedt.net > > >> wrote: > > >> > > >>> we are two, at least :-) > > >>> > > >>> Why didn't you post this on the list? > > >>> > > >>> When will be be arriving? > > >>> > > >>> Am 23.07.2014 16:39, schrieb John Bradley: > > >>> > > >>>> Ian Glazer mentioned this in his keynote at CIS yesterday. > > >>>> His advice was please stop, we are creating confusion and > > >>>> uncertainty. > > >>>> We are becoming our own wort enemy. ( my view though > Ian may > > >>>> share it) > > >>>> Returning just an id_ token from the token endpoint has > > >>>> little real value. > > >>>> Something really useful to do would be sorting out > > >>>> channel_id so we can do PoP for id tokens to make them and > > >>>> other cookies secure in the front channel. I think > that is > > >>>> a better use of time. > > >>>> I may be in the minority opinion on that, it won't be the > > >>>> first time. > > >>>> > > >>>> > > >>>> John B. > > >>>> Sent from my iPhone > > >>>> > > >>>> On Jul 23, 2014, at 4:04 PM, Torsten Lodderstedt > > >>>> > > > >>>> wrote: > > >>>> > > >>>>> You are right from a theoretical perspective. Practically > > >>>>> this was caused by editorial decisions during the creation > > >>>>> of the RFC. As far as I remember, there was a > definition of > > >>>>> the (one) token endpoint response in early versions. > No one > > >>>>> every considered to NOT respond with an access token from > > >>>>> the token endpoint. So one might call it an implicit > > >>>>> assumption. > > >>>>> I'm worried that people get totally confused if an > > >>>>> exception is introduced now given the broad adoption of > > >>>>> OAuth based on this assumption. > > >>>>> regards, > > >>>>> Torsten. > > >>>>> > > >>>>> Am 23.07.2014 um 15:41 schrieb Thomas Broyer > > >>>>> >: > > >>>>> > > >>>>>> Is it said anywhere that ALL grant types MUST use Section > > >>>>>> 5.1 responses? Each grant type references Section > 5.1, and > > >>>>>> "access token request" is only defined in the context of > > >>>>>> the defined grant types. Section 2.2 doesn't talk about > > >>>>>> the request or response format. > > >>>>>> > > >>>>>> Le 23 juil. 2014 21:32, "Nat Sakimura" > > >>>>>> > a écrit : > > >>>>>> > > >>>>>> Is it? Apart from the implicit grant that does > not use > > >>>>>> token endpoint, all other grant references > section 5.1 > > >>>>>> for the response, i.e., all shares the same response. > > >>>>>> > > >>>>>> > > >>>>>> 2014-07-23 15:18 GMT-04:00 Thomas Broyer > > >>>>>> >: > > >>>>>> > > >>>>>> I hadn't realized the JSON response that requires > > >>>>>> the access_token field is defined per grant_type, > > >>>>>> so I'd be OK to "extend the semantics" as in the > > >>>>>> current draft. > > >>>>>> That was actually my main concern: that the token > > >>>>>> endpoint mandates access_token; but its actually > > >>>>>> not the case. > > >>>>>> > > >>>>>> Le 23 juil. 2014 20:46, "Nat Sakimura" > > >>>>>> > a > > >>>>>> écrit : > > >>>>>> > > >>>>>> I agree with John that overloading > > >>>>>> response_type @ authz endpoint is a bad idea. > > >>>>>> It completely changes the semantics of this > > >>>>>> parameter. NOTE: what I was proposing was not > > >>>>>> this parameter, but a new parameter > > >>>>>> response_type @ token endpoint. > > >>>>>> I also think overloading grant_type is a bad > > >>>>>> idea since it changes its semantics. I quote > > >>>>>> the definition here again: > > >>>>>> grant > > >>>>>> credential representing the resource > > >>>>>> owner's authorization > > >>>>>> grant_type > > >>>>>> type of grant sent to the token endpoint to > > >>>>>> obtain the access token > > >>>>>> It is not about controlling what is to be > > >>>>>> returned from the token endpoint, but the > hint > > >>>>>> to the token endpoint describing the type of > > >>>>>> credential the endpoint has received. It > seems > > >>>>>> the "control of what is being returned from > > >>>>>> token endpoint" is just a side effect. > > >>>>>> I am somewhat ambivalent[1] in changing the > > >>>>>> semantics of token endpoint, but in as > much as > > >>>>>> "text is the king" for a spec., we probably > > >>>>>> should not change the semantics of it as > > >>>>>> Torsten points out. If it is ok to change > this > > >>>>>> semantics, I believe defining a new parameter > > >>>>>> to this endpoint to control the response > would > > >>>>>> be the best way to go. This is what I have > > >>>>>> described previously. > > >>>>>> Defining a new endpoint to send code to > get ID > > >>>>>> Token and forbidding the use of it against > > >>>>>> token endpoint would not change the semantics > > >>>>>> of any existing parameter or endpoint, which > > >>>>>> is good. However, I doubt if it is not worth > > >>>>>> doing. What's the point of avoiding access > > >>>>>> token scoped to UserInfo endpoint after all? > > >>>>>> Defining a new endpoint for just avoiding the > > >>>>>> access token for userinfo endpoint seems way > > >>>>>> too much the heavy wait way and it breaks > > >>>>>> interoperabiliy: it defeats the purpose of > > >>>>>> standardization. > > >>>>>> I have started feeling that no change is the > > >>>>>> best way out. > > >>>>>> Nat > > >>>>>> [1] If instead of saying "Token endpoint - > > >>>>>> used by the client to exchange an > > >>>>>> authorization grant for an access token, > > >>>>>> typically with client authentication", it > were > > >>>>>> saying "Token endpoint - used by the > client to > > >>>>>> exchange an authorization grant for tokens, > > >>>>>> typically with client authentication", > then it > > >>>>>> would have been OK. It is an expansion of the > > >>>>>> capability rather than changing the > semantics. > > >>>>>> > > >>>>>> > > >>>>>> 2014-07-23 13:39 GMT-04:00 Mike Jones > > >>>>>> > >>>>>> >: > > >>>>>> > > >>>>>> You need the alternative response_type > > >>>>>> value ("code_for_id_token" in the A4C > > >>>>>> draft) to tell the Authorization > Server to > > >>>>>> return a code to be used with the new > > >>>>>> grant type, rather than one to use with > > >>>>>> the "authorization_code" grant type > (which > > >>>>>> is what response_type=code does). > > >>>>>> > > >>>>>> > > >>>>>> *From:*OAuth > > >>>>>> [mailto:oauth-bounces@ietf.org > > >>>>>> ] *On > > >>>>>> Behalf Of *John Bradley > > >>>>>> *Sent:* Wednesday, July 23, 2014 10:33 AM > > >>>>>> *To:* torsten@lodderstedt.net > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> *Cc:* oauth@ietf.org > > > >>>>>> *Subject:* Re: [OAUTH-WG] New Version > > >>>>>> Notification for > > >>>>>> draft-hunt-oauth-v2-user-a4c-05.txt > > >>>>>> > > >>>>>> > > >>>>>> If we use the token endpoint then a new > > >>>>>> grant_type is the best way. > > >>>>>> > > >>>>>> > > >>>>>> It sort of overloads code, but that is > > >>>>>> better than messing with > response_type for > > >>>>>> the authorization endpoint to change the > > >>>>>> response from the token_endpoint. > That is > > >>>>>> in my opinion a champion bad idea. > > >>>>>> > > >>>>>> > > >>>>>> In discussions developing Connect we > > >>>>>> decided not to open this can of worms > > >>>>>> because no good would come of it. > > >>>>>> > > >>>>>> > > >>>>>> The token_endpoint returns a access > token. > > >>>>>> Nothing requires scope to be associates > > >>>>>> with the token. > > >>>>>> > > >>>>>> > > >>>>>> That is the best solution. No change > > >>>>>> required. Better interoperability in my > > >>>>>> opinion. > > >>>>>> > > >>>>>> > > >>>>>> Still on my way to TO, getting in later > > >>>>>> today. > > >>>>>> > > >>>>>> > > >>>>>> John B. > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> Sent from my iPhone > > >>>>>> > > >>>>>> > > >>>>>> On Jul 23, 2014, at 12:15 PM, > > >>>>>> torsten@lodderstedt.net > > >>>>>> wrote: > > >>>>>> > > >>>>>> The "response type" of the token > > >>>>>> endpoint is controlled by the > value of > > >>>>>> the parameter "grant_type". So there > > >>>>>> is no need to introduce a new > parameter. > > >>>>>> > > >>>>>> wrt to a potential "no_access_token" > > >>>>>> grant type. I do not consider this a > > >>>>>> good idea as it changes the semantics > > >>>>>> of the token endpoint (as already > > >>>>>> pointed out by Thomas). This endpoint > > >>>>>> ALWAYS responds with an access token > > >>>>>> to any grant type. I therefore would > > >>>>>> prefer to use another endpoint > for the > > >>>>>> intended purpose. > > >>>>>> > > >>>>>> regards, > > >>>>>> Torsten. > > >>>>>> > > >>>>>> > > >>>>>> Am 23.07.2014 13:04, schrieb Nat > > Sakimura: > > >>>>>> > > >>>>>> IMHO, changing the semantics of > > >>>>>> "response_type" @ authz endpoint > > >>>>>> this way is not a good thing. > > >>>>>> > > >>>>>> > > >>>>>> Instead, defining a new parameter > > >>>>>> "response_type" @ token endpoint, > > >>>>>> as I described in my previous > > >>>>>> message, > > >>>>>> > > >>>>>> probably is better. At least, it > > >>>>>> does not change the semantics of > > >>>>>> the parameters of RFC6749. > > >>>>>> > > >>>>>> > > >>>>>> Nat > > >>>>>> > > >>>>>> > > >>>>>> 2014-07-23 12:48 GMT-04:00 Thomas > > >>>>>> Broyer > >>>>>> >: > > >>>>>> > > >>>>>> No, I mean response_type=none and > > >>>>>> response_type=id_token don't > > >>>>>> generate a code or access > token so > > >>>>>> you don't use the Token Endpoint > > >>>>>> (which is not the same as the > > >>>>>> Authentication Endpoint BTW). > > >>>>>> > > >>>>>> With > > >>>>>> response_type=code_for_id_token, > > >>>>>> you get a code and exchange > it for > > >>>>>> an id_token only, rather than an > > >>>>>> access_token, so you're changing > > >>>>>> the semantics of the Token > Endpoint. > > >>>>>> > > >>>>>> > > >>>>>> I'm not saying it's a bad thing, > > >>>>>> just that you can't really > compare > > >>>>>> none and id_token with > > >>>>>> code_for_id_token. > > >>>>>> > > >>>>>> > > >>>>>> On Wed, Jul 23, 2014 at 6:45 PM, > > >>>>>> Richer, Justin P. > > >>>>>> > >>>>>> > > wrote: > > >>>>>> > > >>>>>> It's only "not using the token > > >>>>>> endpoint" because the token > > >>>>>> endpoint copy-pasted and renamed > > >>>>>> the authentication endpoint. > > >>>>>> > > >>>>>> > > >>>>>> -- Justin > > >>>>>> > > >>>>>> > > >>>>>> On Jul 23, 2014, at 9:30 AM, > > >>>>>> Thomas Broyer > >>>>>> > > wrote: > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> Except that these are about not > > >>>>>> using the Token Endpoint at all, > > >>>>>> whereas the current proposal is > > >>>>>> about the Token Endpoint not > > >>>>>> returning an access_token > field in > > >>>>>> the JSON. > > >>>>>> > > >>>>>> > > >>>>>> On Wed, Jul 23, 2014 at 4:26 PM, > > >>>>>> Mike Jones > > >>>>>> > >>>>>> > > > > > >>>>>> wrote: > > >>>>>> > > >>>>>> The response_type "none" is > > >>>>>> already used in practice, which > > >>>>>> returns no access token. It was > > >>>>>> accepted by the designated > experts > > >>>>>> and registered in the IANA OAuth > > >>>>>> Authorization Endpoint Response > > >>>>>> Types registry at > > >>>>>> > > > http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#endpoint > > >>>>>> > > > . > > >>>>>> The registered "id_token" > response > > >>>>>> type also returns no access > token. > > >>>>>> > > >>>>>> > > >>>>>> So I think the question of > whether > > >>>>>> response types that result in no > > >>>>>> access token being returned are > > >>>>>> acceptable within OAuth 2.0 is > > >>>>>> already settled, as a practical > > >>>>>> matter. Lots of OAuth > > >>>>>> implementations are already using > > >>>>>> such response types. > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> -- Mike > > >>>>>> > > >>>>>> > > >>>>>> *From:*OAuth > > >>>>>> [mailto:oauth-bounces@ietf.org > > >>>>>> ] > > >>>>>> *On Behalf Of *Phil Hunt > > >>>>>> *Sent:* Wednesday, July 23, 2014 > > >>>>>> 7:09 AM > > >>>>>> *To:* Nat Sakimura > > >>>>>> *Cc:* > >>>>>> > > > >>>>>> *Subject:* Re: [OAUTH-WG] New > > >>>>>> Version Notification for > > >>>>>> > draft-hunt-oauth-v2-user-a4c-05.txt > > >>>>>> > > >>>>>> > > >>>>>> Yes. This is why it has to be > > >>>>>> discussed in the IETF. > > >>>>>> > > >>>>>> > > >>>>>> Phil > > >>>>>> > > >>>>>> > > >>>>>> @independentid > > >>>>>> > > >>>>>> www.independentid.com > > >>>>>> > > >>>>>> > > >>>>>> phil.hunt@oracle.com > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> On Jul 23, 2014, at 9:43 AM, Nat > > >>>>>> Sakimura > >>>>>> > > wrote: > > >>>>>> > > >>>>>> > > >>>>>> Reading back the RFC6749, I > am not > > >>>>>> sure if there is a good way of > > >>>>>> suppressing access token from the > > >>>>>> response and still be OAuth. It > > >>>>>> will break whole bunch of > implicit > > >>>>>> definitions like: > > >>>>>> > > >>>>>> > > >>>>>> authorization server > > >>>>>> The server issuing access > > >>>>>> tokens to the client after > > >>>>>> successfully > > >>>>>> authenticating the resource > > >>>>>> owner and obtaining > authorization. > > >>>>>> > > >>>>>> > > >>>>>> After all, OAuth is all about > > >>>>>> issuing access tokens. > > >>>>>> > > >>>>>> > > >>>>>> Also, I take back my statement on > > >>>>>> the grant type in my previous > mail. > > >>>>>> > > >>>>>> > > >>>>>> The definition of grant and > > >>>>>> grant_type are respectively: > > >>>>>> > > >>>>>> > > >>>>>> grant > > >>>>>> > > >>>>>> credential representing the > > >>>>>> resource owner's authorization > > >>>>>> > > >>>>>> > > >>>>>> grant_type > > >>>>>> > > >>>>>> (string representing the) > type > > >>>>>> of grant sent to the token > > >>>>>> endpoint to obtain the access > token > > >>>>>> > > >>>>>> > > >>>>>> Thus, the grant sent to the token > > >>>>>> endpoint in this case is still > > >>>>>> 'code'. > > >>>>>> > > >>>>>> > > >>>>>> Response type on the other > hand is > > >>>>>> not so well defined in RFC6749, > > >>>>>> but it seems it is representing > > >>>>>> what is to be returned from the > > >>>>>> authorization endpoint. To > express > > >>>>>> what is to be returned from token > > >>>>>> endpoint, perhaps defining a new > > >>>>>> parameter to the token endpoint, > > >>>>>> which is a parallel to the > > >>>>>> response_type to the > Authorization > > >>>>>> Endpoint seems to be a more > > >>>>>> symmetric way, though I am not > > >>>>>> sure at all if that is going > to be > > >>>>>> OAuth any more. One straw-man is > > >>>>>> to define a new parameter called > > >>>>>> response_type to the token > > >>>>>> endpoint such as: > > >>>>>> > > >>>>>> > > >>>>>> response_type > > >>>>>> > > >>>>>> OPTIONAL. A string > > >>>>>> representing what is to be > > >>>>>> returned from the token endpoint. > > >>>>>> > > >>>>>> > > >>>>>> Then define the behavior of the > > >>>>>> endpoint according to the values > > >>>>>> as the parallel to the > > >>>>>> multi-response type spec. > > >>>>>> > > >>>>>> > > http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html > > >>>>>> > > >>>>>> > > >>>>>> Nat > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> 2014-07-23 7:21 GMT-04:00 Phil > > >>>>>> Hunt > >>>>>> >: > > >>>>>> > > >>>>>> The draft is very clear. > > >>>>>> > > >>>>>> Phil > > >>>>>> > > >>>>>> > > >>>>>> On Jul 23, 2014, at 0:46, Nat > > >>>>>> Sakimura > >>>>>> > > wrote: > > >>>>>> > > >>>>>> The new grant type that I was > > >>>>>> talking about was > > >>>>>> > > >>>>>> > > "authorization_code_but_do_not_return_access_nor_refresh_token", > > >>>>>> so to speak. > > >>>>>> > > >>>>>> It does not return anything > > >>>>>> per se, but an extension can > > >>>>>> define something on top > of it. > > >>>>>> > > >>>>>> > > >>>>>> Then, OIDC can define a > > >>>>>> binding to it so that the > > >>>>>> binding only returns ID > Token. > > >>>>>> > > >>>>>> This binding work should be > > >>>>>> done in OIDF. Should there be > > >>>>>> such a grant type, > > >>>>>> > > >>>>>> it will be an extremely short > > >>>>>> spec. > > >>>>>> > > >>>>>> > > >>>>>> At the same time, if any > other > > >>>>>> specification wanted to > define > > >>>>>> > > >>>>>> other type of tokens and have > > >>>>>> it returned from the token > > >>>>>> endpoint, > > >>>>>> > > >>>>>> it can also use this > grant type. > > >>>>>> > > >>>>>> > > >>>>>> If what you want is to define > > >>>>>> a new grant type that returns > > >>>>>> ID Token only, > > >>>>>> > > >>>>>> then, I am with Justin. Since > > >>>>>> "other response than ID > Token" > > >>>>>> is only > > >>>>>> > > >>>>>> theoretical, this is a more > > >>>>>> plausible way forward, I > > suppose. > > >>>>>> > > >>>>>> > > >>>>>> Nat > > >>>>>> > > >>>>>> > > >>>>>> 2014-07-22 14:30 GMT-04:00 > > >>>>>> Justin Richer > > >>>>>> >: > > >>>>>> > > >>>>>> So the draft would literally > > >>>>>> turn into: > > >>>>>> > > >>>>>> "The a4c response type and > > >>>>>> grant type return an id_token > > >>>>>> from the token endpoint with > > >>>>>> no access token. All > > >>>>>> parameters and values are > > >>>>>> defined in OIDC." > > >>>>>> > > >>>>>> Seems like the perfect mini > > >>>>>> extension draft for OIDF > to do. > > >>>>>> > > >>>>>> --Justin > > >>>>>> > > >>>>>> /sent from my phone/ > > >>>>>> > > >>>>>> > > >>>>>> On Jul 22, 2014 10:29 AM, Nat > > >>>>>> Sakimura > >>>>>> > > > >>>>>> wrote: > > >>>>>> > > > >>>>>> > What about just defining a > > >>>>>> new grant type in this WG? > > >>>>>> > > > >>>>>> > > > >>>>>> > 2014-07-22 12:56 GMT-04:00 > > >>>>>> Phil Hunt > > >>>>>> > >>>>>> > >: > > >>>>>> >> > > >>>>>> >> That would be nice. > However > > >>>>>> oidc still needs the new > grant > > >>>>>> type in order to > implement the > > >>>>>> same flow. > > >>>>>> >> > > >>>>>> >> Phil > > >>>>>> >> > > >>>>>> >> On Jul 22, 2014, at 11:35, > > >>>>>> Nat Sakimura > > >>>>>> > >>>>>> > > > >>>>>> wrote: > > >>>>>> >> > > >>>>>> >>> +1 to Justin. > > >>>>>> >>> > > >>>>>> >>> > > >>>>>> >>> 2014-07-22 9:54 GMT-04:00 > > >>>>>> Richer, Justin P. > > >>>>>> > >>>>>> >: > > >>>>>> >>>> > > >>>>>> >>>> Errors like these > make it > > >>>>>> clear to me that it would > make > > >>>>>> much more sense to develop > > >>>>>> this document in the OpenID > > >>>>>> Foundation. It should be > > >>>>>> something that directly > > >>>>>> references OpenID Connect > Core > > >>>>>> for all of these terms > instead > > >>>>>> of redefining them. It's > doing > > >>>>>> authentication, which is > > >>>>>> fundamentally what OpenID > > >>>>>> Connect does on top of OAuth, > > >>>>>> and I don't see a good > > >>>>>> argument for doing this work > > >>>>>> in this working group. > > >>>>>> >>>> > > >>>>>> >>>> -- Justin > > >>>>>> >>>> > > >>>>>> >>>> On Jul 22, 2014, at 4:30 > > >>>>>> AM, Thomas Broyer > > >>>>>> > >>>>>> > > > >>>>>> wrote: > > >>>>>> >>>> > > >>>>>> >>>>> > > >>>>>> >>>>> > > >>>>>> >>>>> > > >>>>>> >>>>> On Mon, Jul 21, 2014 at > > >>>>>> 11:52 PM, Mike Jones > > >>>>>> > >>>>>> > > > > > >>>>>> wrote: > > >>>>>> >>>>>> > > >>>>>> >>>>>> Thanks for your > review, > > >>>>>> Thomas. The "prompt=consent" > > >>>>>> definition being missing > is an > > >>>>>> editorial error. It > should be: > > >>>>>> >>>>>> > > >>>>>> >>>>>> > > >>>>>> >>>>>> > > >>>>>> >>>>>> consent > > >>>>>> >>>>>> > > >>>>>> >>>>>> The Authorization > > >>>>>> Server SHOULD prompt the > > >>>>>> End-User for consent before > > >>>>>> returning information to the > > >>>>>> Client. If it cannot obtain > > >>>>>> consent, it MUST return an > > >>>>>> error, typically > > consent_required. > > >>>>>> >>>>>> > > >>>>>> >>>>>> > > >>>>>> >>>>>> > > >>>>>> >>>>>> I'll plan to add it in > > >>>>>> the next draft. > > >>>>>> >>>>> > > >>>>>> >>>>> > > >>>>>> >>>>> It looks like the > > >>>>>> consent_required error needs > > >>>>>> to be defined too, and you > > >>>>>> might have forgotten to also > > >>>>>> import > > >>>>>> account_selection_required > > >>>>>> from OpenID Connect. > > >>>>>> >>>>> > > >>>>>> >>>>>> > > >>>>>> >>>>>> > > >>>>>> >>>>>> > > >>>>>> >>>>>> I agree that > there's no > > >>>>>> difference between a response > > >>>>>> with multiple "amr" values > > >>>>>> that includes "mfa" and one > > >>>>>> that doesn't. Unless a clear > > >>>>>> use case for why "mfa" is > > >>>>>> needed can be identified, we > > >>>>>> can delete it in the next > draft. > > >>>>>> >>>>> > > >>>>>> >>>>> > > >>>>>> >>>>> Thanks. > > >>>>>> >>>>> > > >>>>>> >>>>> How about "pwd" then? I > > >>>>>> fully understand that I > should > > >>>>>> return "pwd" if the user > > >>>>>> authenticated using a > > >>>>>> password, but what "the > > >>>>>> service if a client secret is > > >>>>>> used" means in the definition > > >>>>>> for the "pwd" value? > > >>>>>> >>>>> > > >>>>>> >>>>> (Nota: I know you're at > > >>>>>> IETF-90, I'm ready to wait > > >>>>>> 'til you come back ;-) ) > > >>>>>> >>>>> > > >>>>>> >>>>> -- > > >>>>>> >>>>> Thomas Broyer > > >>>>>> >>>>> /tɔ.ma.bʁwa.je/ > > >>>>>> > > > > >>>>>> >>>>> > > >>>>>> > > _______________________________________________ > > >>>>>> >>>>> 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 > > >>>>>> >>>> > > >>>>>> >>> > > >>>>>> >>> > > >>>>>> >>> > > >>>>>> >>> -- > > >>>>>> >>> Nat Sakimura (=nat) > > >>>>>> >>> Chairman, OpenID > Foundation > > >>>>>> >>> http://nat.sakimura.org/ > > >>>>>> >>> @_nat_en > > >>>>>> >>> > > >>>>>> >>> > > >>>>>> > > _______________________________________________ > > >>>>>> >>> OAuth mailing list > > >>>>>> >>> OAuth@ietf.org > > >>>>>> > > >>>>>> >>> > > >>>>>> > > https://www.ietf.org/mailman/listinfo/oauth > > >>>>>> > > > >>>>>> > > > >>>>>> > > > >>>>>> > > > >>>>>> > -- > > >>>>>> > Nat Sakimura (=nat) > > >>>>>> > Chairman, OpenID Foundation > > >>>>>> > http://nat.sakimura.org/ > > >>>>>> > @_nat_en > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> -- > > >>>>>> Nat Sakimura (=nat) > > >>>>>> > > >>>>>> Chairman, OpenID Foundation > > >>>>>> http://nat.sakimura.org/ > > >>>>>> @_nat_en > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> -- > > >>>>>> Nat Sakimura (=nat) > > >>>>>> > > >>>>>> Chairman, OpenID Foundation > > >>>>>> http://nat.sakimura.org/ > > >>>>>> @_nat_en > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > _______________________________________________ > > >>>>>> OAuth mailing list > > >>>>>> OAuth@ietf.org > > > > >>>>>> > > https://www.ietf.org/mailman/listinfo/oauth > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> -- > > >>>>>> Thomas Broyer > > >>>>>> /tɔ.ma.bʁwa.je/ > > >>>>>> > > > >>>>>> > > >>>>>> > > _______________________________________________ > > >>>>>> OAuth mailing list > > >>>>>> OAuth@ietf.org > > > > >>>>>> > > https://www.ietf.org/mailman/listinfo/oauth > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> -- > > >>>>>> Thomas Broyer > > >>>>>> /tɔ.ma.bʁwa.je/ > > >>>>>> > > > >>>>>> > > >>>>>> > > >>>>>> > > _______________________________________________ > > >>>>>> OAuth mailing list > > >>>>>> OAuth@ietf.org > > > > >>>>>> > > https://www.ietf.org/mailman/listinfo/oauth > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> -- > > >>>>>> Nat Sakimura (=nat) > > >>>>>> > > >>>>>> Chairman, OpenID Foundation > > >>>>>> http://nat.sakimura.org/ > > >>>>>> @_nat_en > > >>>>>> > > >>>>>> > > >>>>>> > > _______________________________________________ > > >>>>>> > > >>>>>> 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 > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> -- > > >>>>>> Nat Sakimura (=nat) > > >>>>>> Chairman, OpenID Foundation > > >>>>>> http://nat.sakimura.org/ > > >>>>>> @_nat_en > > >>>>>> > > >>>>>> > _______________________________________________ > > >>>>>> From nobody Mon Oct 13 07:57:07 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1E221A017E; Mon, 13 Oct 2014 07:57:04 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6fQb1xnN4eyH; Mon, 13 Oct 2014 07:57:03 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0113.outbound.protection.outlook.com [207.46.100.113]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D0421A000A; Mon, 13 Oct 2014 07:57:03 -0700 (PDT) Received: from BY2PR03CA047.namprd03.prod.outlook.com (10.141.249.20) by CY1PR0301MB1211.namprd03.prod.outlook.com (25.161.212.145) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Mon, 13 Oct 2014 14:57:01 +0000 Received: from BL2FFO11FD053.protection.gbl (2a01:111:f400:7c09::165) by BY2PR03CA047.outlook.office365.com (2a01:111:e400:2c5d::20) with Microsoft SMTP Server (TLS) id 15.0.1049.19 via Frontend Transport; Mon, 13 Oct 2014 14:57:01 +0000 Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD053.mail.protection.outlook.com (10.173.161.181) with Microsoft SMTP Server (TLS) id 15.0.1039.16 via Frontend Transport; Mon, 13 Oct 2014 14:57:00 +0000 Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.93]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.03.0210.003; Mon, 13 Oct 2014 14:56:16 +0000 From: Mike Jones To: Brian Campbell , Barry Leiba Thread-Topic: Benoit Claise's Discuss on draft-ietf-oauth-saml2-bearer-21: (with DISCUSS and COMMENT) Thread-Index: AQHP5upYt4FwAncw40+o/Wr7Rt3tppwuDUsAgAAPfQCAAAA3YA== Date: Mon, 13 Oct 2014 14:56:15 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439BAFF7C0@TK5EX14MBXC286.redmond.corp.microsoft.com> References: <20141013133343.28609.70075.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(377454003)(189002)(24454002)(51704005)(199003)(104016003)(230783001)(86612001)(85806002)(86362001)(76482002)(80022003)(46102003)(97736003)(85306004)(64706001)(20776003)(47776003)(66066001)(26826002)(50466002)(31966008)(84676001)(85852003)(68736004)(69596002)(33656002)(19580405001)(19580395003)(44976005)(6806004)(99396003)(2656002)(87936001)(120916001)(55846006)(106116001)(106466001)(81156004)(95666004)(107046002)(21056001)(23676002)(4396001)(92566001)(76176999)(92726001)(50986999)(77096002)(54356999); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB1211; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB1211; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 03630A6A4A Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/6xEXgGBmai7tMqzqir35WDvVbDc Cc: "oauth-chairs@tools.ietf.org" , The IESG , Tom Taylor , Benoit Claise , "draft-ietf-oauth-saml2-bearer@tools.ietf.org" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Benoit Claise's Discuss on draft-ietf-oauth-saml2-bearer-21: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 14:57:05 -0000 SSdtIGFkZGluZyB0aGUgd29ya2luZyBncm91cCB0byB0aGlzIHRocmVhZCBzbyB0aGV5J3JlIGF3 YXJlIG9mIHRoZSBkaXNjdXNzaW9uLiAgUmVwbGllcyBhcmUgaW5saW5lIGJlbG93Li4uDQoNCj4g RnJvbTogQnJpYW4gQ2FtcGJlbGwgW21haWx0bzpicmlhbi5kLmNhbXBiZWxsQGdtYWlsLmNvbV0g DQo+IFNlbnQ6IE1vbmRheSwgT2N0b2JlciAxMywgMjAxNCA3OjUyIEFNDQo+IFRvOiBCYXJyeSBM ZWliYQ0KPiBDYzogQmVub2l0IENsYWlzZTsgVGhlIElFU0c7IG9hdXRoLWNoYWlyc0B0b29scy5p ZXRmLm9yZzsgZHJhZnQtaWV0Zi1vYXV0aC1zYW1sMi1iZWFyZXJAdG9vbHMuaWV0Zi5vcmc7IFRv bSBUYXlsb3INCj4gU3ViamVjdDogUmU6IEJlbm9pdCBDbGFpc2UncyBEaXNjdXNzIG9uIGRyYWZ0 LWlldGYtb2F1dGgtc2FtbDItYmVhcmVyLTIxOiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0K PiANCj4gV29ya3MgZm9yIG1lLiBJJ3ZlIGJlZW4gdW5jZXJ0YWluIGFib3V0IDY3NTUgYXMgaW5m b3JtYXRpdmUgdnMuIG5vcm1hdGl2ZSBhbmQgYW0gbW9yZSB0aGFuIGhhcHB5IHRvIHRha2UgQmFy cnkncyBzdWdnZXN0aW9uIG9mIG1ha2luZyBpdCBpbmZvcm1hdGl2ZS4NCj4gDQo+IEkgZG9uJ3Qg dGhpbmsgaXQncyBiZWVuIHJhaXNlZCBidXQgdGhlIHNhbWUgc2l0dWF0aW9uIHdpdGggNjc1NSBp cyBpbiBkcmFmdC1pZXRmLW9hdXRoLWp3dC1iZWFyZXItMTAgdG9vLiBJIGFzc3VtZSBhIHBhcmFs bGVsIGNoYW5nZSB0aGVyZSBpcyBkZXNpcmFibGU/DQoNClllcywgd2UnZCB3YW50IHRvIG1ha2Ug dGhlIHBhcmFsbGVsIGNoYW5nZS4NCg0KCQkJCS0tIE1pa2UNCg0KPiBPbiBNb24sIE9jdCAxMywg MjAxNCBhdCA3OjU3IEFNLCBCYXJyeSBMZWliYSA8YmFycnlsZWliYUBjb21wdXRlci5vcmc+IHdy b3RlOg0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiBESVNDVVNTOg0KPiA+IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cj4gPg0KPiA+IE5vIG9iamVjdGlvbiBvbiB0aGUgZG9jdW1lbnQgaXRzZWxmLCBidXQsIGFzIHJp Z2h0bHkgbm90ZWQgYnkgVG9tIFRheWxvcg0KPiA+IGluIHRoZSBPUFMtRElSIHJldmlldzoNCj4g PiBQcm9jZXNzIGlzc3VlOiBJRG5pdHMgY29tcGxhaW5zIG9mIGEgbm9ybWF0aXZlIHJlZmVyZW5j ZSB0byBJbmZvcm1hdGlvbmFsDQo+ID4gZG9jdW1lbnQgUkZDIDY3NTUuIFRoaXMgd2FzIE5PVCBu b3RlZCBpbiB0aGUgTGFzdCBDYWxsIGFubm91bmNlbWVudCAoYnV0DQo+ID4gd2FzIG5vdGVkIGlu IHRoZSBTaGVwaGVyZCB3cml0ZXVwKS4gTm8gb3BlcmF0aW9uYWwgaXNzdWUgaWRlbnRpZmllZA0K PiA+IGJleW9uZCB3aGF0IGlzIGFscmVhZHkgY292ZXJlZCBieSB0aGUgSW50ZXJvcGVyYWJpbGl0 eSBDb25zaWRlcmF0aW9ucw0KPiA+IHNlY3Rpb24uDQo+IA0KPiBJIHRoaW5rIHRoZSByaWdodCBh bnN3ZXIgaGVyZSBpcyB0byBtYWtlIDY3NTUgYW4gaW5mb3JtYXRpdmUNCj4gcmVmZXJlbmNlOiBp dCdzIG5vdCBuZWVkZWQgdG8gdW5kZXJzdGFuZCB0aGlzIGRvY3VtZW50LCBhbmQgaXMgb25seQ0K PiB1c2VkIGFzIGEgcmVmZXJlbmNlIHRvIHRoZSBkb2N1bWVudCB3aGVyZSB0aGUgbmFtZXNwYWNl IHdhcyBjcmVhdGVkLg0KPiANCj4gQmFycnkNCg0K From nobody Mon Oct 13 08:14:37 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 949211A01E0; Mon, 13 Oct 2014 08:14:30 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ISPUKKjjwN4m; Mon, 13 Oct 2014 08:14:27 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0780.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::780]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 510551A0195; Mon, 13 Oct 2014 08:14:27 -0700 (PDT) Received: from BN3PR0301CA0026.namprd03.prod.outlook.com (25.160.180.164) by CY1PR0301MB1210.namprd03.prod.outlook.com (25.161.212.144) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Mon, 13 Oct 2014 15:14:04 +0000 Received: from BY2FFO11FD049.protection.gbl (2a01:111:f400:7c0c::133) by BN3PR0301CA0026.outlook.office365.com (2a01:111:e400:4000::36) with Microsoft SMTP Server (TLS) id 15.0.1049.19 via Frontend Transport; Mon, 13 Oct 2014 15:14:03 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD049.mail.protection.outlook.com (10.1.15.186) with Microsoft SMTP Server (TLS) id 15.0.1039.16 via Frontend Transport; Mon, 13 Oct 2014 15:14:03 +0000 Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.93]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.03.0210.003; Mon, 13 Oct 2014 15:13:31 +0000 From: Mike Jones To: Barry Leiba , Brian Campbell Thread-Topic: Benoit Claise's Discuss on draft-ietf-oauth-saml2-bearer-21: (with DISCUSS and COMMENT) Thread-Index: AQHP5upYt4FwAncw40+o/Wr7Rt3tppwuDUsAgAAPfQCAAAHwAIAAA+Ag Date: Mon, 13 Oct 2014 15:13:31 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439BAFF86B@TK5EX14MBXC286.redmond.corp.microsoft.com> References: <20141013133343.28609.70075.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(979002)(6009001)(438002)(13464003)(51704005)(199003)(377454003)(189002)(19580395003)(21056001)(2656002)(104016003)(97736003)(85852003)(85806002)(47776003)(50466002)(4396001)(55846006)(19580405001)(93886004)(230783001)(6806004)(76482002)(44976005)(68736004)(26826002)(64706001)(20776003)(46102003)(85306004)(80022003)(69596002)(84676001)(99396003)(120916001)(66066001)(46406003)(50986999)(23726002)(31966008)(76176999)(95666004)(87936001)(33656002)(77096002)(97756001)(106116001)(81156004)(106466001)(54356999)(86362001)(92566001)(107046002)(86612001)(92726001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB1210; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB1210; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 03630A6A4A Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/FTbLZVPIt8yCe0FVmjHUfHmN72g Cc: "oauth-chairs@tools.ietf.org" , The IESG , Tom Taylor , Benoit Claise , "draft-ietf-oauth-saml2-bearer@tools.ietf.org" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Benoit Claise's Discuss on draft-ietf-oauth-saml2-bearer-21: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 15:14:30 -0000 Re-adding the working group to the thread... > -----Original Message----- > From: barryleiba@gmail.com [mailto:barryleiba@gmail.com] On Behalf Of Bar= ry > Leiba > Sent: Monday, October 13, 2014 7:59 AM > To: Brian Campbell > Cc: Benoit Claise; The IESG; oauth-chairs@tools.ietf.org; draft-ietf-oaut= h- > saml2-bearer@tools.ietf.org; Tom Taylor > Subject: Re: Benoit Claise's Discuss on draft-ietf-oauth-saml2-bearer-21:= (with > DISCUSS and COMMENT) >=20 > > I don't think it's been raised but the same situation with 6755 is in > > draft-ietf-oauth-jwt-bearer-10 too. I assume a parallel change there > > is desirable? >=20 > Yes. >=20 > The reason we make documents such as 6755 Informational is that they only > specify a template and procedure, and have nothing substantive that would > need to be referred to normatively. >=20 > Barry From nobody Mon Oct 13 09:30:38 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2BEE1A1ADA for ; Mon, 13 Oct 2014 09:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TALwbae25Kw7 for ; Mon, 13 Oct 2014 09:30:33 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89A041A1B26 for ; Mon, 13 Oct 2014 09:30:24 -0700 (PDT) Received: from [192.168.10.188] ([195.50.187.121]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0La3c1-1Y2Yc70Hl7-00lnVU for ; Mon, 13 Oct 2014 18:30:22 +0200 Message-ID: <543BFE19.7050800@gmx.net> Date: Mon, 13 Oct 2014 18:30:17 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: "oauth@ietf.org" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="XwgaoNM2NLPj8pSe6cbqfUb5RbsvUmj7v" X-Provags-ID: V03:K0:hq3dqAnoKdtxPeboY7/V1m443DgrzcmstOgQLHVW4UQc2pYKsVJ R9DQTSVHKtKTUncW5ne59j1eGS+Wvby+oshgetrBn/z7CZ9qe/nOnymTvUuHTAIVU1Dx1HM 4t4jj6GJBrTZS7AUniqASf5otJwdFDgBQmfqYklzvKnKRffrrfjEpgTPGNf2S16VxMyxLfC arqIwXbiS9YMZVkcxyAYw== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/NTn8rSJrqzi6x-n_lK2_82V88Fs Subject: [OAUTH-WG] Notes from 1st "OAuth & Authentication" Conference Call X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 16:30:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --XwgaoNM2NLPj8pSe6cbqfUb5RbsvUmj7v Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Note that there is a 2nd conference call schedule for this Thursday: http://www.ietf.org/mail-archive/web/oauth/current/msg13494.html Participants: * Brian Campbell * Mike Jones * William Kim * John Bradley * John Mandel * Justin Richer Notes: The aim of the discussion here is to produce a short write-up about problems seen in real-world deployments where OAuth was used for authentication. It is not a goal to discuss the work on new specification= s. Justin mentioned that we could put the write-up on oauth.net The outcome of such a write-up could be two-fold, namely * to make folks aware about OpenID Connect, and * to give recommendations for those who want to create their own authentication mechanism based on OAuth We discussed the content of the write-up and the conference call participants thought it would be useful to use case studies of what can go wrong and Facebook was repeatedly mentioned as a source for such stories. An example of a common mistake is to assume that receiving an OAuth access token implies that the user was authenticated recently. It turns out that Justin as well as John had written blog posts about this topic already and Justin volunteered to produce a strawman proposal by this Thursday to have text for the group to look at. Hannes encouraged everyone to send him other blog posts and examples of failed attempts to use OAuth for authentication. --XwgaoNM2NLPj8pSe6cbqfUb5RbsvUmj7v Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUO/4aAAoJEGhJURNOOiAtCbsH/iL+vLCK3WGlqnWs6Quctwu2 0sPbEuEdA69KTc+qWUVnOy3WAMY4atb7ZX1bPPvX0fj+J72kovYtM8GSwZX8kWEy tNoeFLoCOrWkuNWlUQ9vuwdXwElA6HAw7+/EbUwMQaVV3CoeTkQ2X/2T304H5Ev3 jDpkAKx09pwyCMul/mmY9QiY11RqIgrPFBBSnVLs4NgojWWQyAQadscyJrP/Xse+ +NVjpfL1ZJubf563GA4NDTIDAz0yOtlNjEX09qzmDIjmV6JNZ3Y+a3aBHsycEk8D 1nNoU2YKH9kbumRIsZ9nV3v7MpQvIdNT8PAAvveRqiVh5uHUG3EzMIoOhNV8f/4= =sc/W -----END PGP SIGNATURE----- --XwgaoNM2NLPj8pSe6cbqfUb5RbsvUmj7v-- From nobody Mon Oct 13 09:35:10 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E0651A1B2A for ; Mon, 13 Oct 2014 09:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iTb8s4yKpDKi for ; Mon, 13 Oct 2014 09:35:06 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 819DB1A1B26 for ; Mon, 13 Oct 2014 09:35:06 -0700 (PDT) Received: from [192.168.10.188] ([195.50.187.121]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LrqNe-1YJoJC3rLS-013dWR for ; Mon, 13 Oct 2014 18:35:05 +0200 Message-ID: <543BFF34.1070307@gmx.net> Date: Mon, 13 Oct 2014 18:35:00 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: "oauth@ietf.org" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ESUg73W46aFbDik95lkoiBVExaUStgRLT" X-Provags-ID: V03:K0:/WftTGZNykCZqnbHvtDYUgkyV2VC7j46lTAzN7gWsvrll2zpeCx TlMulm6CSz7od+8Z0kH2LlCl27N0qCOc2VBrIQRvwKEXE42/I/zO+HINWXAzvQ55Ue4PjtW qpeaZpqMBk1N57vEGvCCjLuUcJfhBm8jGv+/8dNIY3gDdhd0bdaK5u4mbhWAqLTg8qXEMDE 6NxawMqkpyacyli5gZEtw== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/gBfL7kXXaT-eU0KsBg3GDlqU47s Subject: [OAUTH-WG] Blackhat US: OAuth Talk X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 16:35:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ESUg73W46aFbDik95lkoiBVExaUStgRLT Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable During the OAuth conference call today I asked whether someone had looked at this paper published at the recent Blackhat US conference and nobody knew about it. Hence, I am posting it here: * Paper: https://www.blackhat.com/docs/us-14/materials/us-14-Hu-How-To-Leak-A100-M= illion-Node-Social-Graph-In-Just-One-Week-WP.pdf * Slides: https://www.blackhat.com/docs/us-14/materials/us-14-Hu-How-To-Leak-A100-M= illion-Node-Social-Graph-In-Just-One-Week.pdf Ciao Hannes --ESUg73W46aFbDik95lkoiBVExaUStgRLT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUO/80AAoJEGhJURNOOiAtNs0H/j+l5Y6HDf9Zj/K8yTsJN0dK TqEMyZyAox6VHphNU7YIsqc/TecYIclk78f3OBwC/arZSluztA9RO8JN9SxZHYZQ IrKYIPWPgMiXbZ0sK1tM00wpvjYPs1vKuEVfk+dkpGTtoSZZnp86e+Q1WKEHXBJ8 Zyx8VCoy3iwZvjG23eG/TF3x10YXAiAb6ABwuqx6Be3NM+j5oW3gdRU8LR2JBfab 8q04rqb+lads/gOQItsffsC1sBgZVHxEzM73zabQJpXcLOn90tU9FMcTliI7xU9p j0xk2DXSZtmJt11hltiDEssHliyyzrv4kPnWneHpplifzHwCt0Vo6NkgjKewRaI= =l+Rc -----END PGP SIGNATURE----- --ESUg73W46aFbDik95lkoiBVExaUStgRLT-- From nobody Mon Oct 13 12:18:39 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 735C91A8A9C for ; Mon, 13 Oct 2014 12:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.987 X-Spam-Level: X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6DzYNS9neoo for ; Mon, 13 Oct 2014 12:18:30 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 037431A8A84 for ; Mon, 13 Oct 2014 12:18:29 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s9DJIRnG011408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 13 Oct 2014 19:18:27 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s9DJIQ7g019347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 13 Oct 2014 19:18:27 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s9DJIPRV026732; Mon, 13 Oct 2014 19:18:25 GMT Received: from [192.168.1.133] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 13 Oct 2014 12:18:24 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: <543BE1A1.6020902@gmail.com> Date: Mon, 13 Oct 2014 12:18:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <44A3CD9F-9E2E-4746-A5B1-47984BBE973C@oracle.com> References: <543BE1A1.6020902@gmail.com> To: Sergey Beryozkin X-Mailer: Apple Mail (2.1878.6) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/DkwE96vvkYKhckQmKh7XcFUsSdU Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 19:18:35 -0000 The point to be made is if the client=E2=80=99s objective is to = authenticate the User, the base 6749 spec does not guarantee this at = all. It simply authorizes the client to access a resource and nothing more. It turns out that a significant part of the time authentication does = occur, but the client does not have access to that information. Nor can = it specifically request re-authentication. Further, if the client doesn=E2=80=99t wield the access token, its might = not be proof that the token received was actually an authorization.=20 OpenID gives you both authen information and authorization profile = information (as a resource). This thread was more about how to do just authentication ONLY. What are = the requirements for a client to know a User *was* authenticated and = when. While some flows of OpenID can achieve this, its not clear that = it addresses all cases. Furhter there is discussion (as Justin mentions) = that a flow that does not produce an access token is not an = authorization flow and is not OAuth. I agree. It an authentication flow = and should be distinct IMHO. That said, I am in the minority with this opinion and I acknowledge as = being as such. =20 Phil @independentid www.independentid.com phil.hunt@oracle.com On Oct 13, 2014, at 7:28 AM, Sergey Beryozkin = wrote: > On 13/10/14 15:17, Justin Richer wrote: >> You certainly can do authentication without using an access token, = but >> then I would argue that's no longer OAuth. Basically you're making = tofu >> carob fudge. >=20 > Right, the access token is there for a client to get to the UserInfo = endpoint, as far as OIDC is concerned. What if the info in the id_token = is sufficient ? > I guess as far as a typical OAuth2 client is concerned, requesting = "openid profile" only effectively gives one an access token that can = only be used with the UserInfo endpoint. >=20 > So yes, may be even though OIDC has an access token returned, unless = other custom scopes are used, the access token would be pretty much of = use in the OIDC context only if a client chooses to work with the = UserInfo...I guess the id_token/at_hash is useful on its own >=20 >=20 > Cheers, Sergey >=20 >>=20 >>=20 >> -- Justin >>=20 >> / Sent from my phone / >>=20 >>=20 >> -------- Original message -------- >> From: Sergey Beryozkin >> Date:10/13/2014 9:00 AM (GMT-05:00) >> To: Justin Richer , oauth@ietf.org >> Cc: >> Subject: Re: [OAUTH-WG] New Version Notification for >> draft-hunt-oauth-v2-user-a4c-05.txt >>=20 >> Hi Justin, >> On 13/10/14 12:53, Justin Richer wrote: >> > You are correct in that OAuth 2 and OpenID Connect are not the same >> > thing, but your user is correct that OIDC adds a few pieces on top = of >> > OAuth to add authentication capabilities. OIDC was designed very >> > explicitly to be compatible with vanilla OAuth, partially do that = people >> > would be able to deploy it on top of existing OAuth infrastructure = and >> > code. But the very fact that OIDC adds a few things on top of OAuth = to >> > give more functionality should be sufficient evidence that they're = not >> > equivalent. >> > >> > It's more proper to say that OpenID Connect is an extension and >> > application of OAuth. One that provides an authentication and >> identity API. >> > >> I agree and this is more or less how I answered. >>=20 >> Though the 'borders' can be blurred, one can claim that if a user >> actually logs on into a confidential OAuth2 client web application = which >> redirects this user to AS requesting a code with some scopes such as = "a >> b" then when it uses "a b openid profile" it is basically does a pure >> OAuth2 code flow where the client requests 'a b' plus also a scope >> allowing it later to query the identity system on behalf of a user. >>=20 >> I like the "The extension and application of OAuth2" characteristic = of >> OIDC. IMHO it's becoming more obvious if OIDC is used to support SSO >> into non-OAuth2 servers, when it is the case then there's no = 'feeling' >> that OIDC is just a case of the confidential client adding the extra >> scopes and getting the extra (authentication) info back. A standalone >> OIDC RP protecting such non OAuth2 servers is very much about the >> authentication/identity. >>=20 >> I also thought that having some OID profile (as opposed updating = OAuth2 >> to support no access tokens) where no access but only id token was >> returned (as suggested in this thread) would probably make sense too. >>=20 >> > The way I like to explain it (which I stole from someone else) is = that >> > OAuth is like chocolate and authentication is like fudge. They are = not >> > the same thing. You can make chocolate into fudge out you can make = it >> > into something else or you can just have it on its own. You can = make >> > fudge with chocolate or you can make it with peanut butter or you = can >> > make it with potatoes if you want to, but it needs a couple = ingredients >> > and a very common one is chocolate. OpenID Connect is a recipe for >> > chocolate fudge that a lot of people like. And it makes my fudge >> > compatible with your fudge, which is where the metaphor breaks = down. :-) >> > >> Thanks for sharing this colourful explanation :-). Perhaps I should >> borrow it :-), >> Cheers, Sergey >>=20 >>=20 >> > >> > -- Justin >> > >> > / Sent from my phone / >> > >> > >> > -------- Original message -------- >> > From: Sergey Beryozkin >> > Date:10/13/2014 6:33 AM (GMT-05:00) >> > To: oauth@ietf.org >> > Cc: >> > Subject: Re: [OAUTH-WG] New Version Notification for >> > draft-hunt-oauth-v2-user-a4c-05.txt >> > >> > Hi >> > >> > We've had a user asserting that "OAuth2 =3D=3D OpenidConnect", = referring to >> > the fact that the 'only' thing OIC adds on top of the authorization = code >> > flow is the client specifying few extra scopes like 'openid' and >> > 'profile' and the authorization service returning an extra = property, the >> > id_token which can be sufficient in order to get the authenticated >> > user's info. >> > >> > My understanding "OAuth2 !=3D OpenidConnect", the latter utilizes = the >> > former and is an authentication mechanism which is not what OAuth2 = is >> > (may be except for the client credentials). But I don't feel like = it is >> > a convincing enough argument. >> > >> > I thought this thread was relevant, sorry if not, would have no = problems >> > starting a new one. >> > >> > Basically, I wonder what is the proper line of argument for a = position >> > such as "OAuth2 !=3D OpenidConnect" and also what was the action to = the >> > list of options suggested by John below. Is having an OID profile = where >> > no access token is returned would be the cleanest action as far as >> > breaking the ambiguity/confusion is concerned ? >> > >> > Cheers, Sergey >> > >> > On 24/07/14 15:25, John Bradley wrote: >> > > I am not against discussion in the WG. >> > > >> > > I happen to agree with Phil's fundamental premise that some = developers >> > > are using OAuth in a insecure way to do authentication. >> > > >> > > That raises the question of how to best educate them, and or = address >> > > technical barriers. >> > > >> > > It is on the second point that people's opinions seem to divide. >> > > >> > > Some people thing that if we have a OAuth flow that eliminates = the >> > > access token (primarily to avoid asking for consent as I >> understand it) >> > > and just return a id_token from the token endpoint that can be >> done in a >> > > spec short enough to het people to read. The subtext of this = is that >> > > the Connect specification is too large that it scare people, = and they >> > > don't find the spec in the first place because it is not a RFC. >> > > >> > > An other common possession is that if you don't want to prompt = the >> user >> > > for consent then don't ask for scopes. Twisting the OAuth spec = to not >> > > return an access token is not OAuth, yes you could use a = different >> > > endpoint rather than the token endpoint, but that is not OAuth. >> > > Connect was careful not to break the OAuth spec. As long as = you are >> > > willing to take a access token with no scopes (the client needs = to >> > > understand that there are no attributes one way or another = anyway >> or it >> > > will break) then you don't need to change OAuth. You can = publish a >> > > profile of connect that satisfies the use case. >> > > >> > > I think Mike has largely done that but it might be better being = less >> > > stingy on references back to the larger spec. >> > > >> > > The questions are do we modify OAuth to not return an access >> token, and >> > > if so how, and if we do is it still OAuth. >> > > >> > > The other largely separable question is do we create confusion = in the >> > > market and slow the the adoption of identity federation on top = of >> OAuth, >> > > or find a way to make this look like a positive alignment of = interests >> > > around a subset of Connect. >> > > >> > > There are a number of options. >> > > 1: We can do a profile in the OIDF and publish it as a IETF = document. >> > > Perhaps the cleanest from an IPR point of view.However >> > > 2:We can do a profile in the OAuth WG referencing connect. >> > > 3:We can do a AD sponsored profile that is not in the OAuth WG. >> > > 4:We can do a small spec in OAuth to add response_type to the = token >> > > endpoint. in combination with 1, 2, or 3 >> > > >> > > I agree that stoping developers doing insecure things needs to = be >> > > addressed somehow. >> > > I am not personally convinced that Oauth without access tokens = is >> > sensible. >> > > >> > > Looking forward to the meeting:) >> > > >> > > John B. >> > > On Jul 24, 2014, at 6:52 AM, Brian Campbell >> > > > > wrote: >> > > >> > >> I'd note that the reaction at the conference to Ian's statement = was >> > >> overwhelmingly positive. There was a wide range of industry = people >> > >> here - implementers, practitioners, deployers, strategists, = etc. >> - and >> > >> it seems pretty clear that the "rough consensus" of the = industry at >> > >> large is that a4c is not wanted or needed. >> > >> >> > >> >> > >> On Thu, Jul 24, 2014 at 5:29 AM, Nat Sakimura = > > >> > wrote: >> > >> >> > >> And here is a quote from Ian's blog. >> > >> >> > >> And although the authentication wheel is round, that = doesn=E2=80=99t >> > >> mean it isn=E2=80=99t without its lumps. First, we do = see some >> > >> reinventing the wheel just to reinvent the wheel. OAuth >> A4C is >> > >> simply not a fruitful activity and should be put down. >> > >> >> > >> (Source) >> > >> >> > >> = http://www.tuesdaynight.org/2014/07/23/do-we-have-a-round-wheel-yet-musing= s-on-identity-standards-part-1.html >> > >> >> > >> >> > >> >> > >> 2014-07-23 16:53 GMT-04:00 John Bradley > > >> >: >> > >> >> > >> I thought I did post this to the list. >> > >> >> > >> I guess I hit the wrong reply on my phone. >> > >> John B. >> > >> Sent from my iPhone >> > >> >> > >> On Jul 23, 2014, at 4:50 PM, torsten@lodderstedt.net >> > >> wrote: >> > >> >> > >>> we are two, at least :-) >> > >>> >> > >>> Why didn't you post this on the list? >> > >>> >> > >>> When will be be arriving? >> > >>> >> > >>> Am 23.07.2014 16:39, schrieb John Bradley: >> > >>> >> > >>>> Ian Glazer mentioned this in his keynote at CIS = yesterday. >> > >>>> His advice was please stop, we are creating = confusion and >> > >>>> uncertainty. >> > >>>> We are becoming our own wort enemy. ( my view though >> Ian may >> > >>>> share it) >> > >>>> Returning just an id_ token from the token endpoint = has >> > >>>> little real value. >> > >>>> Something really useful to do would be sorting out >> > >>>> channel_id so we can do PoP for id tokens to make = them and >> > >>>> other cookies secure in the front channel. I think >> that is >> > >>>> a better use of time. >> > >>>> I may be in the minority opinion on that, it won't = be the >> > >>>> first time. >> > >>>> >> > >>>> >> > >>>> John B. >> > >>>> Sent from my iPhone >> > >>>> >> > >>>> On Jul 23, 2014, at 4:04 PM, Torsten Lodderstedt >> > >>>> > >> > >>>> wrote: >> > >>>> >> > >>>>> You are right from a theoretical perspective. = Practically >> > >>>>> this was caused by editorial decisions during the = creation >> > >>>>> of the RFC. As far as I remember, there was a >> definition of >> > >>>>> the (one) token endpoint response in early versions. >> No one >> > >>>>> every considered to NOT respond with an access token = from >> > >>>>> the token endpoint. So one might call it an implicit >> > >>>>> assumption. >> > >>>>> I'm worried that people get totally confused if an >> > >>>>> exception is introduced now given the broad adoption = of >> > >>>>> OAuth based on this assumption. >> > >>>>> regards, >> > >>>>> Torsten. >> > >>>>> >> > >>>>> Am 23.07.2014 um 15:41 schrieb Thomas Broyer >> > >>>>> >: >> > >>>>> >> > >>>>>> Is it said anywhere that ALL grant types MUST use = Section >> > >>>>>> 5.1 responses? Each grant type references Section >> 5.1, and >> > >>>>>> "access token request" is only defined in the = context of >> > >>>>>> the defined grant types. Section 2.2 doesn't talk = about >> > >>>>>> the request or response format. >> > >>>>>> >> > >>>>>> Le 23 juil. 2014 21:32, "Nat Sakimura" >> > > >>>>>> > a =C3=A9crit : >> > >>>>>> >> > >>>>>> Is it? Apart from the implicit grant that does >> not use >> > >>>>>> token endpoint, all other grant references >> section 5.1 >> > >>>>>> for the response, i.e., all shares the same = response. >> > >>>>>> >> > >>>>>> >> > >>>>>> 2014-07-23 15:18 GMT-04:00 Thomas Broyer >> > >>>>>> >: >> > >>>>>> >> > >>>>>> I hadn't realized the JSON response that = requires >> > >>>>>> the access_token field is defined per = grant_type, >> > >>>>>> so I'd be OK to "extend the semantics" as = in the >> > >>>>>> current draft. >> > >>>>>> That was actually my main concern: that the = token >> > >>>>>> endpoint mandates access_token; but its = actually >> > >>>>>> not the case. >> > >>>>>> >> > >>>>>> Le 23 juil. 2014 20:46, "Nat Sakimura" >> > >>>>>> > > a >> > >>>>>> =C3=A9crit : >> > >>>>>> >> > >>>>>> I agree with John that overloading >> > >>>>>> response_type @ authz endpoint is a bad = idea. >> > >>>>>> It completely changes the semantics of = this >> > >>>>>> parameter. NOTE: what I was proposing = was not >> > >>>>>> this parameter, but a new parameter >> > >>>>>> response_type @ token endpoint. >> > >>>>>> I also think overloading grant_type is = a bad >> > >>>>>> idea since it changes its semantics. I = quote >> > >>>>>> the definition here again: >> > >>>>>> grant >> > >>>>>> credential representing the = resource >> > >>>>>> owner's authorization >> > >>>>>> grant_type >> > >>>>>> type of grant sent to the token = endpoint to >> > >>>>>> obtain the access token >> > >>>>>> It is not about controlling what is to = be >> > >>>>>> returned from the token endpoint, but = the >> hint >> > >>>>>> to the token endpoint describing the = type of >> > >>>>>> credential the endpoint has received. = It >> seems >> > >>>>>> the "control of what is being returned = from >> > >>>>>> token endpoint" is just a side effect. >> > >>>>>> I am somewhat ambivalent[1] in changing = the >> > >>>>>> semantics of token endpoint, but in as >> much as >> > >>>>>> "text is the king" for a spec., we = probably >> > >>>>>> should not change the semantics of it = as >> > >>>>>> Torsten points out. If it is ok to = change >> this >> > >>>>>> semantics, I believe defining a new = parameter >> > >>>>>> to this endpoint to control the = response >> would >> > >>>>>> be the best way to go. This is what I = have >> > >>>>>> described previously. >> > >>>>>> Defining a new endpoint to send code to >> get ID >> > >>>>>> Token and forbidding the use of it = against >> > >>>>>> token endpoint would not change the = semantics >> > >>>>>> of any existing parameter or endpoint, = which >> > >>>>>> is good. However, I doubt if it is not = worth >> > >>>>>> doing. What's the point of avoiding = access >> > >>>>>> token scoped to UserInfo endpoint after = all? >> > >>>>>> Defining a new endpoint for just = avoiding the >> > >>>>>> access token for userinfo endpoint = seems way >> > >>>>>> too much the heavy wait way and it = breaks >> > >>>>>> interoperabiliy: it defeats the purpose = of >> > >>>>>> standardization. >> > >>>>>> I have started feeling that no change = is the >> > >>>>>> best way out. >> > >>>>>> Nat >> > >>>>>> [1] If instead of saying "Token = endpoint - >> > >>>>>> used by the client to exchange an >> > >>>>>> authorization grant for an access = token, >> > >>>>>> typically with client authentication", = it >> were >> > >>>>>> saying "Token endpoint - used by the >> client to >> > >>>>>> exchange an authorization grant for = tokens, >> > >>>>>> typically with client authentication", >> then it >> > >>>>>> would have been OK. It is an expansion = of the >> > >>>>>> capability rather than changing the >> semantics. >> > >>>>>> >> > >>>>>> >> > >>>>>> 2014-07-23 13:39 GMT-04:00 Mike Jones >> > >>>>>> > > >>>>>> >: >> > >>>>>> >> > >>>>>> You need the alternative = response_type >> > >>>>>> value ("code_for_id_token" in the = A4C >> > >>>>>> draft) to tell the Authorization >> Server to >> > >>>>>> return a code to be used with the = new >> > >>>>>> grant type, rather than one to use = with >> > >>>>>> the "authorization_code" grant type >> (which >> > >>>>>> is what response_type=3Dcode does). >> > >>>>>> >> > >>>>>> >> > >>>>>> *From:*OAuth >> > >>>>>> [mailto:oauth-bounces@ietf.org >> > >>>>>> ] = *On >> > >>>>>> Behalf Of *John Bradley >> > >>>>>> *Sent:* Wednesday, July 23, 2014 = 10:33 AM >> > >>>>>> *To:* torsten@lodderstedt.net >> > >>>>>> >> > >>>>>> >> > >>>>>> >> > >>>>>> *Cc:* oauth@ietf.org >> >> > >>>>>> *Subject:* Re: [OAUTH-WG] New = Version >> > >>>>>> Notification for >> > >>>>>> draft-hunt-oauth-v2-user-a4c-05.txt >> > >>>>>> >> > >>>>>> >> > >>>>>> If we use the token endpoint then a = new >> > >>>>>> grant_type is the best way. >> > >>>>>> >> > >>>>>> >> > >>>>>> It sort of overloads code, but that = is >> > >>>>>> better than messing with >> response_type for >> > >>>>>> the authorization endpoint to = change the >> > >>>>>> response from the token_endpoint. >> That is >> > >>>>>> in my opinion a champion bad idea. >> > >>>>>> >> > >>>>>> >> > >>>>>> In discussions developing Connect = we >> > >>>>>> decided not to open this can of = worms >> > >>>>>> because no good would come of it. >> > >>>>>> >> > >>>>>> >> > >>>>>> The token_endpoint returns a access >> token. >> > >>>>>> Nothing requires scope to be = associates >> > >>>>>> with the token. >> > >>>>>> >> > >>>>>> >> > >>>>>> That is the best solution. No = change >> > >>>>>> required. Better interoperability = in my >> > >>>>>> opinion. >> > >>>>>> >> > >>>>>> >> > >>>>>> Still on my way to TO, getting in = later >> > >>>>>> today. >> > >>>>>> >> > >>>>>> >> > >>>>>> John B. >> > >>>>>> >> > >>>>>> >> > >>>>>> >> > >>>>>> >> > >>>>>> Sent from my iPhone >> > >>>>>> >> > >>>>>> >> > >>>>>> On Jul 23, 2014, at 12:15 PM, >> > >>>>>> torsten@lodderstedt.net >> > >>>>>> = wrote: >> > >>>>>> >> > >>>>>> The "response type" of the = token >> > >>>>>> endpoint is controlled by the >> value of >> > >>>>>> the parameter "grant_type". So = there >> > >>>>>> is no need to introduce a new >> parameter. >> > >>>>>> >> > >>>>>> wrt to a potential = "no_access_token" >> > >>>>>> grant type. I do not consider = this a >> > >>>>>> good idea as it changes the = semantics >> > >>>>>> of the token endpoint (as = already >> > >>>>>> pointed out by Thomas). This = endpoint >> > >>>>>> ALWAYS responds with an access = token >> > >>>>>> to any grant type. I therefore = would >> > >>>>>> prefer to use another endpoint >> for the >> > >>>>>> intended purpose. >> > >>>>>> >> > >>>>>> regards, >> > >>>>>> Torsten. >> > >>>>>> >> > >>>>>> >> > >>>>>> Am 23.07.2014 13:04, schrieb = Nat >> > Sakimura: >> > >>>>>> >> > >>>>>> IMHO, changing the = semantics of >> > >>>>>> "response_type" @ authz = endpoint >> > >>>>>> this way is not a good = thing. >> > >>>>>> >> > >>>>>> >> > >>>>>> Instead, defining a new = parameter >> > >>>>>> "response_type" @ token = endpoint, >> > >>>>>> as I described in my = previous >> > >>>>>> message, >> > >>>>>> >> > >>>>>> probably is better. At = least, it >> > >>>>>> does not change the = semantics of >> > >>>>>> the parameters of RFC6749. >> > >>>>>> >> > >>>>>> >> > >>>>>> Nat >> > >>>>>> >> > >>>>>> >> > >>>>>> 2014-07-23 12:48 GMT-04:00 = Thomas >> > >>>>>> Broyer > > >>>>>> = >: >> > >>>>>> >> > >>>>>> No, I mean = response_type=3Dnone and >> > >>>>>> response_type=3Did_token = don't >> > >>>>>> generate a code or access >> token so >> > >>>>>> you don't use the Token = Endpoint >> > >>>>>> (which is not the same as = the >> > >>>>>> Authentication Endpoint = BTW). >> > >>>>>> >> > >>>>>> With >> > >>>>>> = response_type=3Dcode_for_id_token, >> > >>>>>> you get a code and exchange >> it for >> > >>>>>> an id_token only, rather = than an >> > >>>>>> access_token, so you're = changing >> > >>>>>> the semantics of the Token >> Endpoint. >> > >>>>>> >> > >>>>>> >> > >>>>>> I'm not saying it's a bad = thing, >> > >>>>>> just that you can't really >> compare >> > >>>>>> none and id_token with >> > >>>>>> code_for_id_token. >> > >>>>>> >> > >>>>>> >> > >>>>>> On Wed, Jul 23, 2014 at = 6:45 PM, >> > >>>>>> Richer, Justin P. >> > >>>>>> > > >>>>>> > >> wrote: >> > >>>>>> >> > >>>>>> It's only "not using the = token >> > >>>>>> endpoint" because the token >> > >>>>>> endpoint copy-pasted and = renamed >> > >>>>>> the authentication = endpoint. >> > >>>>>> >> > >>>>>> >> > >>>>>> -- Justin >> > >>>>>> >> > >>>>>> >> > >>>>>> On Jul 23, 2014, at 9:30 = AM, >> > >>>>>> Thomas Broyer = > > >>>>>> = > >> wrote: >> > >>>>>> >> > >>>>>> >> > >>>>>> >> > >>>>>> Except that these are about = not >> > >>>>>> using the Token Endpoint at = all, >> > >>>>>> whereas the current = proposal is >> > >>>>>> about the Token Endpoint = not >> > >>>>>> returning an access_token >> field in >> > >>>>>> the JSON. >> > >>>>>> >> > >>>>>> >> > >>>>>> On Wed, Jul 23, 2014 at = 4:26 PM, >> > >>>>>> Mike Jones >> > >>>>>> = > > >>>>>> >> > > >> > >>>>>> wrote: >> > >>>>>> >> > >>>>>> The response_type "none" is >> > >>>>>> already used in practice, = which >> > >>>>>> returns no access token. = It was >> > >>>>>> accepted by the designated >> experts >> > >>>>>> and registered in the IANA = OAuth >> > >>>>>> Authorization Endpoint = Response >> > >>>>>> Types registry at >> > >>>>>> >> > >> = http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#endp= oint >> > >>>>>> >> > >> = . >> > >>>>>> The registered "id_token" >> response >> > >>>>>> type also returns no access >> token. >> > >>>>>> >> > >>>>>> >> > >>>>>> So I think the question of >> whether >> > >>>>>> response types that result = in no >> > >>>>>> access token being returned = are >> > >>>>>> acceptable within OAuth 2.0 = is >> > >>>>>> already settled, as a = practical >> > >>>>>> matter. Lots of OAuth >> > >>>>>> implementations are already = using >> > >>>>>> such response types. >> > >>>>>> >> > >>>>>> >> > >>>>>> >> > >>>>>> -- Mike >> > >>>>>> >> > >>>>>> >> > >>>>>> *From:*OAuth >> > >>>>>> = [mailto:oauth-bounces@ietf.org >> > >>>>>> = ] >> > >>>>>> *On Behalf Of *Phil Hunt >> > >>>>>> *Sent:* Wednesday, July 23, = 2014 >> > >>>>>> 7:09 AM >> > >>>>>> *To:* Nat Sakimura >> > >>>>>> *Cc:* > > >>>>>> > >> > >>>>>> *Subject:* Re: [OAUTH-WG] = New >> > >>>>>> Version Notification for >> > >>>>>> >> draft-hunt-oauth-v2-user-a4c-05.txt >> > >>>>>> >> > >>>>>> >> > >>>>>> Yes. This is why it has to = be >> > >>>>>> discussed in the IETF. >> > >>>>>> >> > >>>>>> >> > >>>>>> Phil >> > >>>>>> >> > >>>>>> >> > >>>>>> @independentid >> > >>>>>> >> > >>>>>> www.independentid.com >> > >>>>>> = >> > >>>>>> >> > >>>>>> phil.hunt@oracle.com >> > >>>>>> = >> > >>>>>> >> > >>>>>> >> > >>>>>> >> > >>>>>> >> > >>>>>> On Jul 23, 2014, at 9:43 = AM, Nat >> > >>>>>> Sakimura = > > >>>>>> = > >> wrote: >> > >>>>>> >> > >>>>>> >> > >>>>>> Reading back the RFC6749, I >> am not >> > >>>>>> sure if there is a good way = of >> > >>>>>> suppressing access token = from the >> > >>>>>> response and still be = OAuth. It >> > >>>>>> will break whole bunch of >> implicit >> > >>>>>> definitions like: >> > >>>>>> >> > >>>>>> >> > >>>>>> authorization server >> > >>>>>> The server issuing = access >> > >>>>>> tokens to the client after >> > >>>>>> successfully >> > >>>>>> authenticating the = resource >> > >>>>>> owner and obtaining >> authorization. >> > >>>>>> >> > >>>>>> >> > >>>>>> After all, OAuth is all = about >> > >>>>>> issuing access tokens. >> > >>>>>> >> > >>>>>> >> > >>>>>> Also, I take back my = statement on >> > >>>>>> the grant type in my = previous >> mail. >> > >>>>>> >> > >>>>>> >> > >>>>>> The definition of grant and >> > >>>>>> grant_type are = respectively: >> > >>>>>> >> > >>>>>> >> > >>>>>> grant >> > >>>>>> >> > >>>>>> credential representing = the >> > >>>>>> resource owner's = authorization >> > >>>>>> >> > >>>>>> >> > >>>>>> grant_type >> > >>>>>> >> > >>>>>> (string representing = the) >> type >> > >>>>>> of grant sent to the token >> > >>>>>> endpoint to obtain the = access >> token >> > >>>>>> >> > >>>>>> >> > >>>>>> Thus, the grant sent to the = token >> > >>>>>> endpoint in this case is = still >> > >>>>>> 'code'. >> > >>>>>> >> > >>>>>> >> > >>>>>> Response type on the other >> hand is >> > >>>>>> not so well defined in = RFC6749, >> > >>>>>> but it seems it is = representing >> > >>>>>> what is to be returned from = the >> > >>>>>> authorization endpoint. To >> express >> > >>>>>> what is to be returned from = token >> > >>>>>> endpoint, perhaps defining = a new >> > >>>>>> parameter to the token = endpoint, >> > >>>>>> which is a parallel to the >> > >>>>>> response_type to the >> Authorization >> > >>>>>> Endpoint seems to be a more >> > >>>>>> symmetric way, though I am = not >> > >>>>>> sure at all if that is = going >> to be >> > >>>>>> OAuth any more. One = straw-man is >> > >>>>>> to define a new parameter = called >> > >>>>>> response_type to the token >> > >>>>>> endpoint such as: >> > >>>>>> >> > >>>>>> >> > >>>>>> response_type >> > >>>>>> >> > >>>>>> OPTIONAL. A string >> > >>>>>> representing what is to be >> > >>>>>> returned from the token = endpoint. >> > >>>>>> >> > >>>>>> >> > >>>>>> Then define the behavior of = the >> > >>>>>> endpoint according to the = values >> > >>>>>> as the parallel to the >> > >>>>>> multi-response type spec. >> > >>>>>> >> > >>>>>> >> > http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html >> > >>>>>> >> > >>>>>> >> > >>>>>> Nat >> > >>>>>> >> > >>>>>> >> > >>>>>> >> > >>>>>> >> > >>>>>> >> > >>>>>> 2014-07-23 7:21 GMT-04:00 = Phil >> > >>>>>> Hunt > > >>>>>> = >: >> > >>>>>> >> > >>>>>> The draft is very clear. >> > >>>>>> >> > >>>>>> Phil >> > >>>>>> >> > >>>>>> >> > >>>>>> On Jul 23, 2014, at 0:46, = Nat >> > >>>>>> Sakimura = > > >>>>>> = > >> wrote: >> > >>>>>> >> > >>>>>> The new grant type that = I was >> > >>>>>> talking about was >> > >>>>>> >> > >>>>>> >> > "authorization_code_but_do_not_return_access_nor_refresh_token", >> > >>>>>> so to speak. >> > >>>>>> >> > >>>>>> It does not return = anything >> > >>>>>> per se, but an = extension can >> > >>>>>> define something on top >> of it. >> > >>>>>> >> > >>>>>> >> > >>>>>> Then, OIDC can define a >> > >>>>>> binding to it so that = the >> > >>>>>> binding only returns ID >> Token. >> > >>>>>> >> > >>>>>> This binding work = should be >> > >>>>>> done in OIDF. Should = there be >> > >>>>>> such a grant type, >> > >>>>>> >> > >>>>>> it will be an extremely = short >> > >>>>>> spec. >> > >>>>>> >> > >>>>>> >> > >>>>>> At the same time, if = any >> other >> > >>>>>> specification wanted to >> define >> > >>>>>> >> > >>>>>> other type of tokens = and have >> > >>>>>> it returned from the = token >> > >>>>>> endpoint, >> > >>>>>> >> > >>>>>> it can also use this >> grant type. >> > >>>>>> >> > >>>>>> >> > >>>>>> If what you want is to = define >> > >>>>>> a new grant type that = returns >> > >>>>>> ID Token only, >> > >>>>>> >> > >>>>>> then, I am with Justin. = Since >> > >>>>>> "other response than ID >> Token" >> > >>>>>> is only >> > >>>>>> >> > >>>>>> theoretical, this is a = more >> > >>>>>> plausible way forward, = I >> > suppose. >> > >>>>>> >> > >>>>>> >> > >>>>>> Nat >> > >>>>>> >> > >>>>>> >> > >>>>>> 2014-07-22 14:30 = GMT-04:00 >> > >>>>>> Justin Richer >> > > >>>>>> = >: >> > >>>>>> >> > >>>>>> So the draft would = literally >> > >>>>>> turn into: >> > >>>>>> >> > >>>>>> "The a4c response type = and >> > >>>>>> grant type return an = id_token >> > >>>>>> from the token endpoint = with >> > >>>>>> no access token. All >> > >>>>>> parameters and values = are >> > >>>>>> defined in OIDC." >> > >>>>>> >> > >>>>>> Seems like the perfect = mini >> > >>>>>> extension draft for = OIDF >> to do. >> > >>>>>> >> > >>>>>> --Justin >> > >>>>>> >> > >>>>>> /sent from my phone/ >> > >>>>>> >> > >>>>>> >> > >>>>>> On Jul 22, 2014 10:29 = AM, Nat >> > >>>>>> Sakimura = > > >>>>>> = > >> > >>>>>> wrote: >> > >>>>>> > >> > >>>>>> > What about just = defining a >> > >>>>>> new grant type in this = WG? >> > >>>>>> > >> > >>>>>> > >> > >>>>>> > 2014-07-22 12:56 = GMT-04:00 >> > >>>>>> Phil Hunt >> > >>>>>> > > >>>>>> >> >: >> > >>>>>> >> >> > >>>>>> >> That would be nice. >> However >> > >>>>>> oidc still needs the = new >> grant >> > >>>>>> type in order to >> implement the >> > >>>>>> same flow. >> > >>>>>> >> >> > >>>>>> >> Phil >> > >>>>>> >> >> > >>>>>> >> On Jul 22, 2014, at = 11:35, >> > >>>>>> Nat Sakimura >> > >>>>>> > > >>>>>> = > >> > >>>>>> wrote: >> > >>>>>> >> >> > >>>>>> >>> +1 to Justin. >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> >>> 2014-07-22 9:54 = GMT-04:00 >> > >>>>>> Richer, Justin P. >> > >>>>>> > > >>>>>> = >: >> > >>>>>> >>>> >> > >>>>>> >>>> Errors like these >> make it >> > >>>>>> clear to me that it = would >> make >> > >>>>>> much more sense to = develop >> > >>>>>> this document in the = OpenID >> > >>>>>> Foundation. It should = be >> > >>>>>> something that directly >> > >>>>>> references OpenID = Connect >> Core >> > >>>>>> for all of these terms >> instead >> > >>>>>> of redefining them. = It's >> doing >> > >>>>>> authentication, which = is >> > >>>>>> fundamentally what = OpenID >> > >>>>>> Connect does on top of = OAuth, >> > >>>>>> and I don't see a good >> > >>>>>> argument for doing this = work >> > >>>>>> in this working group. >> > >>>>>> >>>> >> > >>>>>> >>>> -- Justin >> > >>>>>> >>>> >> > >>>>>> >>>> On Jul 22, 2014, = at 4:30 >> > >>>>>> AM, Thomas Broyer >> > >>>>>> > > >>>>>> = > >> > >>>>>> wrote: >> > >>>>>> >>>> >> > >>>>>> >>>>> >> > >>>>>> >>>>> >> > >>>>>> >>>>> >> > >>>>>> >>>>> On Mon, Jul 21, = 2014 at >> > >>>>>> 11:52 PM, Mike Jones >> > >>>>>> = > > >>>>>> >> > > >> > >>>>>> wrote: >> > >>>>>> >>>>>> >> > >>>>>> >>>>>> Thanks for your >> review, >> > >>>>>> Thomas. The = "prompt=3Dconsent" >> > >>>>>> definition being = missing >> is an >> > >>>>>> editorial error. It >> should be: >> > >>>>>> >>>>>> >> > >>>>>> >>>>>> >> > >>>>>> >>>>>> >> > >>>>>> >>>>>> consent >> > >>>>>> >>>>>> >> > >>>>>> >>>>>> The = Authorization >> > >>>>>> Server SHOULD prompt = the >> > >>>>>> End-User for consent = before >> > >>>>>> returning information = to the >> > >>>>>> Client. If it cannot = obtain >> > >>>>>> consent, it MUST return = an >> > >>>>>> error, typically >> > consent_required. >> > >>>>>> >>>>>> >> > >>>>>> >>>>>> >> > >>>>>> >>>>>> >> > >>>>>> >>>>>> I'll plan to add = it in >> > >>>>>> the next draft. >> > >>>>>> >>>>> >> > >>>>>> >>>>> >> > >>>>>> >>>>> It looks like the >> > >>>>>> consent_required error = needs >> > >>>>>> to be defined too, and = you >> > >>>>>> might have forgotten to = also >> > >>>>>> import >> > >>>>>> = account_selection_required >> > >>>>>> from OpenID Connect. >> > >>>>>> >>>>> >> > >>>>>> >>>>>> >> > >>>>>> >>>>>> >> > >>>>>> >>>>>> >> > >>>>>> >>>>>> I agree that >> there's no >> > >>>>>> difference between a = response >> > >>>>>> with multiple "amr" = values >> > >>>>>> that includes "mfa" and = one >> > >>>>>> that doesn't. Unless a = clear >> > >>>>>> use case for why "mfa" = is >> > >>>>>> needed can be = identified, we >> > >>>>>> can delete it in the = next >> draft. >> > >>>>>> >>>>> >> > >>>>>> >>>>> >> > >>>>>> >>>>> Thanks. >> > >>>>>> >>>>> >> > >>>>>> >>>>> How about "pwd" = then? I >> > >>>>>> fully understand that I >> should >> > >>>>>> return "pwd" if the = user >> > >>>>>> authenticated using a >> > >>>>>> password, but what "the >> > >>>>>> service if a client = secret is >> > >>>>>> used" means in the = definition >> > >>>>>> for the "pwd" value? >> > >>>>>> >>>>> >> > >>>>>> >>>>> (Nota: I know = you're at >> > >>>>>> IETF-90, I'm ready to = wait >> > >>>>>> 'til you come back ;-) = ) >> > >>>>>> >>>>> >> > >>>>>> >>>>> -- >> > >>>>>> >>>>> Thomas Broyer >> > >>>>>> >>>>> /t=C9=94.ma.b=CA=81= wa.je/ >> > >>>>>> >> > >> > >>>>>> >>>>> >> > >>>>>> >> > _______________________________________________ >> > >>>>>> >>>>> 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 >> > >>>>>> >>>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> >>> -- >> > >>>>>> >>> Nat Sakimura (=3Dnat)= >> > >>>>>> >>> Chairman, OpenID >> Foundation >> > >>>>>> >>> = http://nat.sakimura.org/ >> > >>>>>> >>> @_nat_en >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> >> > _______________________________________________ >> > >>>>>> >>> OAuth mailing list >> > >>>>>> >>> OAuth@ietf.org >> > >>>>>> >> > >>>>>> >>> >> > >>>>>> >> > https://www.ietf.org/mailman/listinfo/oauth >> > >>>>>> > >> > >>>>>> > >> > >>>>>> > >> > >>>>>> > >> > >>>>>> > -- >> > >>>>>> > Nat Sakimura (=3Dnat) >> > >>>>>> > Chairman, OpenID = Foundation >> > >>>>>> > = http://nat.sakimura.org/ >> > >>>>>> > @_nat_en >> > >>>>>> >> > >>>>>> >> > >>>>>> >> > >>>>>> >> > >>>>>> -- >> > >>>>>> Nat Sakimura (=3Dnat) >> > >>>>>> >> > >>>>>> Chairman, OpenID = Foundation >> > >>>>>> = http://nat.sakimura.org/ >> > >>>>>> @_nat_en >> > >>>>>> >> > >>>>>> >> > >>>>>> >> > >>>>>> >> > >>>>>> -- >> > >>>>>> Nat Sakimura (=3Dnat) >> > >>>>>> >> > >>>>>> Chairman, OpenID Foundation >> > >>>>>> http://nat.sakimura.org/ >> > >>>>>> @_nat_en >> > >>>>>> >> > >>>>>> >> > >>>>>> >> > >>>>>> >> > _______________________________________________ >> > >>>>>> 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 >> > >>>>>> >> > >>>>>> >> > >>>>>> >> > >>>>>> >> > >>>>>> -- >> > >>>>>> Thomas Broyer >> > >>>>>> /t=C9=94.ma.b=CA=81wa.je/ >> > >>>>>> >> >> > >>>>>> >> > >>>>>> >> > >>>>>> >> > _______________________________________________ >> > >>>>>> OAuth mailing list >> > >>>>>> OAuth@ietf.org >> > >> > >>>>>> >> > https://www.ietf.org/mailman/listinfo/oauth >> > >>>>>> >> > >>>>>> >> > >>>>>> >> > >>>>>> >> > >>>>>> -- >> > >>>>>> Nat Sakimura (=3Dnat) >> > >>>>>> >> > >>>>>> Chairman, OpenID Foundation >> > >>>>>> http://nat.sakimura.org/ >> > >>>>>> @_nat_en >> > >>>>>> >> > >>>>>> >> > >>>>>> >> > _______________________________________________ >> > >>>>>> >> > >>>>>> 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 >> > >>>>>> >> > >>>>>> >> > >>>>>> >> > >>>>>> -- >> > >>>>>> Nat Sakimura (=3Dnat) >> > >>>>>> Chairman, OpenID Foundation >> > >>>>>> http://nat.sakimura.org/ >> > >>>>>> @_nat_en >> > >>>>>> >> > >>>>>> >> _______________________________________________ >> > >>>>>> >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Mon Oct 13 13:25:12 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3407B1A0056 for ; Mon, 13 Oct 2014 13:25: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RzG-qfvqiuLS for ; Mon, 13 Oct 2014 13:24:56 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E12DF1A006D for ; Mon, 13 Oct 2014 13:24:51 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id y10so9323255wgg.3 for ; Mon, 13 Oct 2014 13:24:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=47AK1BedKphZWtKHc4bYPWM9DNysf2J+xzbXIkQT6lY=; b=yYoRaDFI2DZieQa9A95qLqXTPGz84nM6no9o6D6AgFgyhiivFJWvcfNXzGctcsjzKO wbYL/PcQpoXpdbN90ntMLRvCPrdq1yT6IzpI1CNoOfirF20LtSUTgNSvH4RuCsZEMtsS fGR2POo6CaT1dJM3mT4FFwnpZHGi+/758DuV0mQJ5n+u7iNUeT4JWoiieJbNrGwe0D1Q 1hybr9wlGSTW1PDyZwMVuOxMt4tmnH8yRbyyooZ1mhnfMBSt4IQU6+iKVHb89Z0jVPTl Q9pwzeaDQr7mcXhBtlx3vfUzWC5EH0Bszhpx5NCrrQTO3vgt5qpofdklhJ8DBF2N+8Rv SiwA== X-Received: by 10.180.149.130 with SMTP id ua2mr1169422wib.31.1413231890426; Mon, 13 Oct 2014 13:24:50 -0700 (PDT) Received: from [192.168.2.7] ([109.255.231.6]) by mx.google.com with ESMTPSA id q5sm17778881wja.49.2014.10.13.13.24.48 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Oct 2014 13:24:49 -0700 (PDT) Message-ID: <543C3510.7070201@gmail.com> Date: Mon, 13 Oct 2014 21:24:48 +0100 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Phil Hunt References: <543BE1A1.6020902@gmail.com> <44A3CD9F-9E2E-4746-A5B1-47984BBE973C@oracle.com> In-Reply-To: <44A3CD9F-9E2E-4746-A5B1-47984BBE973C@oracle.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/-WTOJo79XzKiXb2KcfQcknis_co Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 20:25:02 -0000 Hi Phil Thanks for the clarifications, On 13/10/14 20:18, Phil Hunt wrote: > The point to be made is if the client’s objective is to authenticate the User, the base 6749 spec does not guarantee this at all. > > It simply authorizes the client to access a resource and nothing more. > > It turns out that a significant part of the time authentication does occur, but the client does not have access to that information. Nor can it specifically request re-authentication. > > Further, if the client doesn’t wield the access token, its might not be proof that the token received was actually an authorization. > > OpenID gives you both authen information and authorization profile information (as a resource). > Yes, I experimented with it. > This thread was more about how to do just authentication ONLY. What are the requirements for a client to know a User *was* authenticated and when. While some flows of OpenID can achieve this, its not clear that it addresses all cases. Furhter there is discussion (as Justin mentions) that a flow that does not produce an access token is not an authorization flow and is not OAuth. I agree. Sure. > It an authentication flow and should be distinct IMHO. > I guess that is why the idea of having an OIDC profile dedicated to the authentication alone (no access token) which I believe was suggested here caught my attention. But then it is not OAuth2 and hence not OIDC. The chicken in the egg situation :-). As I said in the prev email, having an access token which is really restricted to the OIDC resource (profile) seems like a good compromise... > That said, I am in the minority with this opinion and I acknowledge as being as such. > Sorry if I hijacked this thread and started the off-topic 'flow'...I guess my reasoning here is a bit all over the place, but I'm pretty sure now I see the big picture better Thanks, Sergey > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > On Oct 13, 2014, at 7:28 AM, Sergey Beryozkin wrote: > >> On 13/10/14 15:17, Justin Richer wrote: >>> You certainly can do authentication without using an access token, but >>> then I would argue that's no longer OAuth. Basically you're making tofu >>> carob fudge. >> >> Right, the access token is there for a client to get to the UserInfo endpoint, as far as OIDC is concerned. What if the info in the id_token is sufficient ? >> I guess as far as a typical OAuth2 client is concerned, requesting "openid profile" only effectively gives one an access token that can only be used with the UserInfo endpoint. >> >> So yes, may be even though OIDC has an access token returned, unless other custom scopes are used, the access token would be pretty much of use in the OIDC context only if a client chooses to work with the UserInfo...I guess the id_token/at_hash is useful on its own >> >> >> Cheers, Sergey >> >>> >>> >>> -- Justin >>> >>> / Sent from my phone / >>> >>> >>> -------- Original message -------- >>> From: Sergey Beryozkin >>> Date:10/13/2014 9:00 AM (GMT-05:00) >>> To: Justin Richer , oauth@ietf.org >>> Cc: >>> Subject: Re: [OAUTH-WG] New Version Notification for >>> draft-hunt-oauth-v2-user-a4c-05.txt >>> >>> Hi Justin, >>> On 13/10/14 12:53, Justin Richer wrote: >>>> You are correct in that OAuth 2 and OpenID Connect are not the same >>>> thing, but your user is correct that OIDC adds a few pieces on top of >>>> OAuth to add authentication capabilities. OIDC was designed very >>>> explicitly to be compatible with vanilla OAuth, partially do that people >>>> would be able to deploy it on top of existing OAuth infrastructure and >>>> code. But the very fact that OIDC adds a few things on top of OAuth to >>>> give more functionality should be sufficient evidence that they're not >>>> equivalent. >>>> >>>> It's more proper to say that OpenID Connect is an extension and >>>> application of OAuth. One that provides an authentication and >>> identity API. >>>> >>> I agree and this is more or less how I answered. >>> >>> Though the 'borders' can be blurred, one can claim that if a user >>> actually logs on into a confidential OAuth2 client web application which >>> redirects this user to AS requesting a code with some scopes such as "a >>> b" then when it uses "a b openid profile" it is basically does a pure >>> OAuth2 code flow where the client requests 'a b' plus also a scope >>> allowing it later to query the identity system on behalf of a user. >>> >>> I like the "The extension and application of OAuth2" characteristic of >>> OIDC. IMHO it's becoming more obvious if OIDC is used to support SSO >>> into non-OAuth2 servers, when it is the case then there's no 'feeling' >>> that OIDC is just a case of the confidential client adding the extra >>> scopes and getting the extra (authentication) info back. A standalone >>> OIDC RP protecting such non OAuth2 servers is very much about the >>> authentication/identity. >>> >>> I also thought that having some OID profile (as opposed updating OAuth2 >>> to support no access tokens) where no access but only id token was >>> returned (as suggested in this thread) would probably make sense too. >>> >>>> The way I like to explain it (which I stole from someone else) is that >>>> OAuth is like chocolate and authentication is like fudge. They are not >>>> the same thing. You can make chocolate into fudge out you can make it >>>> into something else or you can just have it on its own. You can make >>>> fudge with chocolate or you can make it with peanut butter or you can >>>> make it with potatoes if you want to, but it needs a couple ingredients >>>> and a very common one is chocolate. OpenID Connect is a recipe for >>>> chocolate fudge that a lot of people like. And it makes my fudge >>>> compatible with your fudge, which is where the metaphor breaks down. :-) >>>> >>> Thanks for sharing this colourful explanation :-). Perhaps I should >>> borrow it :-), >>> Cheers, Sergey >>> >>> >>>> >>>> -- Justin >>>> >>>> / Sent from my phone / >>>> >>>> >>>> -------- Original message -------- >>>> From: Sergey Beryozkin >>>> Date:10/13/2014 6:33 AM (GMT-05:00) >>>> To: oauth@ietf.org >>>> Cc: >>>> Subject: Re: [OAUTH-WG] New Version Notification for >>>> draft-hunt-oauth-v2-user-a4c-05.txt >>>> >>>> Hi >>>> >>>> We've had a user asserting that "OAuth2 == OpenidConnect", referring to >>>> the fact that the 'only' thing OIC adds on top of the authorization code >>>> flow is the client specifying few extra scopes like 'openid' and >>>> 'profile' and the authorization service returning an extra property, the >>>> id_token which can be sufficient in order to get the authenticated >>>> user's info. >>>> >>>> My understanding "OAuth2 != OpenidConnect", the latter utilizes the >>>> former and is an authentication mechanism which is not what OAuth2 is >>>> (may be except for the client credentials). But I don't feel like it is >>>> a convincing enough argument. >>>> >>>> I thought this thread was relevant, sorry if not, would have no problems >>>> starting a new one. >>>> >>>> Basically, I wonder what is the proper line of argument for a position >>>> such as "OAuth2 != OpenidConnect" and also what was the action to the >>>> list of options suggested by John below. Is having an OID profile where >>>> no access token is returned would be the cleanest action as far as >>>> breaking the ambiguity/confusion is concerned ? >>>> >>>> Cheers, Sergey >>>> >>>> On 24/07/14 15:25, John Bradley wrote: >>>> > I am not against discussion in the WG. >>>> > >>>> > I happen to agree with Phil's fundamental premise that some developers >>>> > are using OAuth in a insecure way to do authentication. >>>> > >>>> > That raises the question of how to best educate them, and or address >>>> > technical barriers. >>>> > >>>> > It is on the second point that people's opinions seem to divide. >>>> > >>>> > Some people thing that if we have a OAuth flow that eliminates the >>>> > access token (primarily to avoid asking for consent as I >>> understand it) >>>> > and just return a id_token from the token endpoint that can be >>> done in a >>>> > spec short enough to het people to read. The subtext of this is that >>>> > the Connect specification is too large that it scare people, and they >>>> > don't find the spec in the first place because it is not a RFC. >>>> > >>>> > An other common possession is that if you don't want to prompt the >>> user >>>> > for consent then don't ask for scopes. Twisting the OAuth spec to not >>>> > return an access token is not OAuth, yes you could use a different >>>> > endpoint rather than the token endpoint, but that is not OAuth. >>>> > Connect was careful not to break the OAuth spec. As long as you are >>>> > willing to take a access token with no scopes (the client needs to >>>> > understand that there are no attributes one way or another anyway >>> or it >>>> > will break) then you don't need to change OAuth. You can publish a >>>> > profile of connect that satisfies the use case. >>>> > >>>> > I think Mike has largely done that but it might be better being less >>>> > stingy on references back to the larger spec. >>>> > >>>> > The questions are do we modify OAuth to not return an access >>> token, and >>>> > if so how, and if we do is it still OAuth. >>>> > >>>> > The other largely separable question is do we create confusion in the >>>> > market and slow the the adoption of identity federation on top of >>> OAuth, >>>> > or find a way to make this look like a positive alignment of interests >>>> > around a subset of Connect. >>>> > >>>> > There are a number of options. >>>> > 1: We can do a profile in the OIDF and publish it as a IETF document. >>>> > Perhaps the cleanest from an IPR point of view.However >>>> > 2:We can do a profile in the OAuth WG referencing connect. >>>> > 3:We can do a AD sponsored profile that is not in the OAuth WG. >>>> > 4:We can do a small spec in OAuth to add response_type to the token >>>> > endpoint. in combination with 1, 2, or 3 >>>> > >>>> > I agree that stoping developers doing insecure things needs to be >>>> > addressed somehow. >>>> > I am not personally convinced that Oauth without access tokens is >>>> sensible. >>>> > >>>> > Looking forward to the meeting:) >>>> > >>>> > John B. >>>> > On Jul 24, 2014, at 6:52 AM, Brian Campbell >>> >>> > > wrote: >>>> > >>>> >> I'd note that the reaction at the conference to Ian's statement was >>>> >> overwhelmingly positive. There was a wide range of industry people >>>> >> here - implementers, practitioners, deployers, strategists, etc. >>> - and >>>> >> it seems pretty clear that the "rough consensus" of the industry at >>>> >> large is that a4c is not wanted or needed. >>>> >> >>>> >> >>>> >> On Thu, Jul 24, 2014 at 5:29 AM, Nat Sakimura >>> >> > wrote: >>>> >> >>>> >> And here is a quote from Ian's blog. >>>> >> >>>> >> And although the authentication wheel is round, that doesn’t >>>> >> mean it isn’t without its lumps. First, we do see some >>>> >> reinventing the wheel just to reinvent the wheel. OAuth >>> A4C is >>>> >> simply not a fruitful activity and should be put down. >>>> >> >>>> >> (Source) >>>> >> >>>> >>> http://www.tuesdaynight.org/2014/07/23/do-we-have-a-round-wheel-yet-musings-on-identity-standards-part-1.html >>>> >> >>>> >> >>>> >> >>>> >> 2014-07-23 16:53 GMT-04:00 John Bradley >>> >> >: >>>> >> >>>> >> I thought I did post this to the list. >>>> >> >>>> >> I guess I hit the wrong reply on my phone. >>>> >> John B. >>>> >> Sent from my iPhone >>>> >> >>>> >> On Jul 23, 2014, at 4:50 PM, torsten@lodderstedt.net >>>> >> wrote: >>>> >> >>>> >>> we are two, at least :-) >>>> >>> >>>> >>> Why didn't you post this on the list? >>>> >>> >>>> >>> When will be be arriving? >>>> >>> >>>> >>> Am 23.07.2014 16:39, schrieb John Bradley: >>>> >>> >>>> >>>> Ian Glazer mentioned this in his keynote at CIS yesterday. >>>> >>>> His advice was please stop, we are creating confusion and >>>> >>>> uncertainty. >>>> >>>> We are becoming our own wort enemy. ( my view though >>> Ian may >>>> >>>> share it) >>>> >>>> Returning just an id_ token from the token endpoint has >>>> >>>> little real value. >>>> >>>> Something really useful to do would be sorting out >>>> >>>> channel_id so we can do PoP for id tokens to make them and >>>> >>>> other cookies secure in the front channel. I think >>> that is >>>> >>>> a better use of time. >>>> >>>> I may be in the minority opinion on that, it won't be the >>>> >>>> first time. >>>> >>>> >>>> >>>> >>>> >>>> John B. >>>> >>>> Sent from my iPhone >>>> >>>> >>>> >>>> On Jul 23, 2014, at 4:04 PM, Torsten Lodderstedt >>>> >>>> > >>>> >>>> wrote: >>>> >>>> >>>> >>>>> You are right from a theoretical perspective. Practically >>>> >>>>> this was caused by editorial decisions during the creation >>>> >>>>> of the RFC. As far as I remember, there was a >>> definition of >>>> >>>>> the (one) token endpoint response in early versions. >>> No one >>>> >>>>> every considered to NOT respond with an access token from >>>> >>>>> the token endpoint. So one might call it an implicit >>>> >>>>> assumption. >>>> >>>>> I'm worried that people get totally confused if an >>>> >>>>> exception is introduced now given the broad adoption of >>>> >>>>> OAuth based on this assumption. >>>> >>>>> regards, >>>> >>>>> Torsten. >>>> >>>>> >>>> >>>>> Am 23.07.2014 um 15:41 schrieb Thomas Broyer >>>> >>>>> >: >>>> >>>>> >>>> >>>>>> Is it said anywhere that ALL grant types MUST use Section >>>> >>>>>> 5.1 responses? Each grant type references Section >>> 5.1, and >>>> >>>>>> "access token request" is only defined in the context of >>>> >>>>>> the defined grant types. Section 2.2 doesn't talk about >>>> >>>>>> the request or response format. >>>> >>>>>> >>>> >>>>>> Le 23 juil. 2014 21:32, "Nat Sakimura" >>> >>> >>>>>> > a écrit : >>>> >>>>>> >>>> >>>>>> Is it? Apart from the implicit grant that does >>> not use >>>> >>>>>> token endpoint, all other grant references >>> section 5.1 >>>> >>>>>> for the response, i.e., all shares the same response. >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> 2014-07-23 15:18 GMT-04:00 Thomas Broyer >>>> >>>>>> >: >>>> >>>>>> >>>> >>>>>> I hadn't realized the JSON response that requires >>>> >>>>>> the access_token field is defined per grant_type, >>>> >>>>>> so I'd be OK to "extend the semantics" as in the >>>> >>>>>> current draft. >>>> >>>>>> That was actually my main concern: that the token >>>> >>>>>> endpoint mandates access_token; but its actually >>>> >>>>>> not the case. >>>> >>>>>> >>>> >>>>>> Le 23 juil. 2014 20:46, "Nat Sakimura" >>>> >>>>>> >> > a >>>> >>>>>> écrit : >>>> >>>>>> >>>> >>>>>> I agree with John that overloading >>>> >>>>>> response_type @ authz endpoint is a bad idea. >>>> >>>>>> It completely changes the semantics of this >>>> >>>>>> parameter. NOTE: what I was proposing was not >>>> >>>>>> this parameter, but a new parameter >>>> >>>>>> response_type @ token endpoint. >>>> >>>>>> I also think overloading grant_type is a bad >>>> >>>>>> idea since it changes its semantics. I quote >>>> >>>>>> the definition here again: >>>> >>>>>> grant >>>> >>>>>> credential representing the resource >>>> >>>>>> owner's authorization >>>> >>>>>> grant_type >>>> >>>>>> type of grant sent to the token endpoint to >>>> >>>>>> obtain the access token >>>> >>>>>> It is not about controlling what is to be >>>> >>>>>> returned from the token endpoint, but the >>> hint >>>> >>>>>> to the token endpoint describing the type of >>>> >>>>>> credential the endpoint has received. It >>> seems >>>> >>>>>> the "control of what is being returned from >>>> >>>>>> token endpoint" is just a side effect. >>>> >>>>>> I am somewhat ambivalent[1] in changing the >>>> >>>>>> semantics of token endpoint, but in as >>> much as >>>> >>>>>> "text is the king" for a spec., we probably >>>> >>>>>> should not change the semantics of it as >>>> >>>>>> Torsten points out. If it is ok to change >>> this >>>> >>>>>> semantics, I believe defining a new parameter >>>> >>>>>> to this endpoint to control the response >>> would >>>> >>>>>> be the best way to go. This is what I have >>>> >>>>>> described previously. >>>> >>>>>> Defining a new endpoint to send code to >>> get ID >>>> >>>>>> Token and forbidding the use of it against >>>> >>>>>> token endpoint would not change the semantics >>>> >>>>>> of any existing parameter or endpoint, which >>>> >>>>>> is good. However, I doubt if it is not worth >>>> >>>>>> doing. What's the point of avoiding access >>>> >>>>>> token scoped to UserInfo endpoint after all? >>>> >>>>>> Defining a new endpoint for just avoiding the >>>> >>>>>> access token for userinfo endpoint seems way >>>> >>>>>> too much the heavy wait way and it breaks >>>> >>>>>> interoperabiliy: it defeats the purpose of >>>> >>>>>> standardization. >>>> >>>>>> I have started feeling that no change is the >>>> >>>>>> best way out. >>>> >>>>>> Nat >>>> >>>>>> [1] If instead of saying "Token endpoint - >>>> >>>>>> used by the client to exchange an >>>> >>>>>> authorization grant for an access token, >>>> >>>>>> typically with client authentication", it >>> were >>>> >>>>>> saying "Token endpoint - used by the >>> client to >>>> >>>>>> exchange an authorization grant for tokens, >>>> >>>>>> typically with client authentication", >>> then it >>>> >>>>>> would have been OK. It is an expansion of the >>>> >>>>>> capability rather than changing the >>> semantics. >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> 2014-07-23 13:39 GMT-04:00 Mike Jones >>>> >>>>>> >>> >>>>>> >: >>>> >>>>>> >>>> >>>>>> You need the alternative response_type >>>> >>>>>> value ("code_for_id_token" in the A4C >>>> >>>>>> draft) to tell the Authorization >>> Server to >>>> >>>>>> return a code to be used with the new >>>> >>>>>> grant type, rather than one to use with >>>> >>>>>> the "authorization_code" grant type >>> (which >>>> >>>>>> is what response_type=code does). >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> *From:*OAuth >>>> >>>>>> [mailto:oauth-bounces@ietf.org >>>> >>>>>> ] *On >>>> >>>>>> Behalf Of *John Bradley >>>> >>>>>> *Sent:* Wednesday, July 23, 2014 10:33 AM >>>> >>>>>> *To:* torsten@lodderstedt.net >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> *Cc:* oauth@ietf.org >>> >>>> >>>>>> *Subject:* Re: [OAUTH-WG] New Version >>>> >>>>>> Notification for >>>> >>>>>> draft-hunt-oauth-v2-user-a4c-05.txt >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> If we use the token endpoint then a new >>>> >>>>>> grant_type is the best way. >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> It sort of overloads code, but that is >>>> >>>>>> better than messing with >>> response_type for >>>> >>>>>> the authorization endpoint to change the >>>> >>>>>> response from the token_endpoint. >>> That is >>>> >>>>>> in my opinion a champion bad idea. >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> In discussions developing Connect we >>>> >>>>>> decided not to open this can of worms >>>> >>>>>> because no good would come of it. >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> The token_endpoint returns a access >>> token. >>>> >>>>>> Nothing requires scope to be associates >>>> >>>>>> with the token. >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> That is the best solution. No change >>>> >>>>>> required. Better interoperability in my >>>> >>>>>> opinion. >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> Still on my way to TO, getting in later >>>> >>>>>> today. >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> John B. >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> Sent from my iPhone >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> On Jul 23, 2014, at 12:15 PM, >>>> >>>>>> torsten@lodderstedt.net >>>> >>>>>> wrote: >>>> >>>>>> >>>> >>>>>> The "response type" of the token >>>> >>>>>> endpoint is controlled by the >>> value of >>>> >>>>>> the parameter "grant_type". So there >>>> >>>>>> is no need to introduce a new >>> parameter. >>>> >>>>>> >>>> >>>>>> wrt to a potential "no_access_token" >>>> >>>>>> grant type. I do not consider this a >>>> >>>>>> good idea as it changes the semantics >>>> >>>>>> of the token endpoint (as already >>>> >>>>>> pointed out by Thomas). This endpoint >>>> >>>>>> ALWAYS responds with an access token >>>> >>>>>> to any grant type. I therefore would >>>> >>>>>> prefer to use another endpoint >>> for the >>>> >>>>>> intended purpose. >>>> >>>>>> >>>> >>>>>> regards, >>>> >>>>>> Torsten. >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> Am 23.07.2014 13:04, schrieb Nat >>>> Sakimura: >>>> >>>>>> >>>> >>>>>> IMHO, changing the semantics of >>>> >>>>>> "response_type" @ authz endpoint >>>> >>>>>> this way is not a good thing. >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> Instead, defining a new parameter >>>> >>>>>> "response_type" @ token endpoint, >>>> >>>>>> as I described in my previous >>>> >>>>>> message, >>>> >>>>>> >>>> >>>>>> probably is better. At least, it >>>> >>>>>> does not change the semantics of >>>> >>>>>> the parameters of RFC6749. >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> Nat >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> 2014-07-23 12:48 GMT-04:00 Thomas >>>> >>>>>> Broyer >>> >>>>>> >: >>>> >>>>>> >>>> >>>>>> No, I mean response_type=none and >>>> >>>>>> response_type=id_token don't >>>> >>>>>> generate a code or access >>> token so >>>> >>>>>> you don't use the Token Endpoint >>>> >>>>>> (which is not the same as the >>>> >>>>>> Authentication Endpoint BTW). >>>> >>>>>> >>>> >>>>>> With >>>> >>>>>> response_type=code_for_id_token, >>>> >>>>>> you get a code and exchange >>> it for >>>> >>>>>> an id_token only, rather than an >>>> >>>>>> access_token, so you're changing >>>> >>>>>> the semantics of the Token >>> Endpoint. >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> I'm not saying it's a bad thing, >>>> >>>>>> just that you can't really >>> compare >>>> >>>>>> none and id_token with >>>> >>>>>> code_for_id_token. >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> On Wed, Jul 23, 2014 at 6:45 PM, >>>> >>>>>> Richer, Justin P. >>>> >>>>>> >>> >>>>>> > >>> wrote: >>>> >>>>>> >>>> >>>>>> It's only "not using the token >>>> >>>>>> endpoint" because the token >>>> >>>>>> endpoint copy-pasted and renamed >>>> >>>>>> the authentication endpoint. >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> -- Justin >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> On Jul 23, 2014, at 9:30 AM, >>>> >>>>>> Thomas Broyer >>> >>>>>> > >>> wrote: >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> Except that these are about not >>>> >>>>>> using the Token Endpoint at all, >>>> >>>>>> whereas the current proposal is >>>> >>>>>> about the Token Endpoint not >>>> >>>>>> returning an access_token >>> field in >>>> >>>>>> the JSON. >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> On Wed, Jul 23, 2014 at 4:26 PM, >>>> >>>>>> Mike Jones >>>> >>>>>> >>> >>>>>> >>>> > >>>> >>>>>> wrote: >>>> >>>>>> >>>> >>>>>> The response_type "none" is >>>> >>>>>> already used in practice, which >>>> >>>>>> returns no access token. It was >>>> >>>>>> accepted by the designated >>> experts >>>> >>>>>> and registered in the IANA OAuth >>>> >>>>>> Authorization Endpoint Response >>>> >>>>>> Types registry at >>>> >>>>>> >>>> >>> http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#endpoint >>>> >>>>>> >>>> >>> . >>>> >>>>>> The registered "id_token" >>> response >>>> >>>>>> type also returns no access >>> token. >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> So I think the question of >>> whether >>>> >>>>>> response types that result in no >>>> >>>>>> access token being returned are >>>> >>>>>> acceptable within OAuth 2.0 is >>>> >>>>>> already settled, as a practical >>>> >>>>>> matter. Lots of OAuth >>>> >>>>>> implementations are already using >>>> >>>>>> such response types. >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> -- Mike >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> *From:*OAuth >>>> >>>>>> [mailto:oauth-bounces@ietf.org >>>> >>>>>> ] >>>> >>>>>> *On Behalf Of *Phil Hunt >>>> >>>>>> *Sent:* Wednesday, July 23, 2014 >>>> >>>>>> 7:09 AM >>>> >>>>>> *To:* Nat Sakimura >>>> >>>>>> *Cc:* >>> >>>>>> > >>>> >>>>>> *Subject:* Re: [OAUTH-WG] New >>>> >>>>>> Version Notification for >>>> >>>>>> >>> draft-hunt-oauth-v2-user-a4c-05.txt >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> Yes. This is why it has to be >>>> >>>>>> discussed in the IETF. >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> Phil >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> @independentid >>>> >>>>>> >>>> >>>>>> www.independentid.com >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> phil.hunt@oracle.com >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> On Jul 23, 2014, at 9:43 AM, Nat >>>> >>>>>> Sakimura >>> >>>>>> > >>> wrote: >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> Reading back the RFC6749, I >>> am not >>>> >>>>>> sure if there is a good way of >>>> >>>>>> suppressing access token from the >>>> >>>>>> response and still be OAuth. It >>>> >>>>>> will break whole bunch of >>> implicit >>>> >>>>>> definitions like: >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> authorization server >>>> >>>>>> The server issuing access >>>> >>>>>> tokens to the client after >>>> >>>>>> successfully >>>> >>>>>> authenticating the resource >>>> >>>>>> owner and obtaining >>> authorization. >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> After all, OAuth is all about >>>> >>>>>> issuing access tokens. >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> Also, I take back my statement on >>>> >>>>>> the grant type in my previous >>> mail. >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> The definition of grant and >>>> >>>>>> grant_type are respectively: >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> grant >>>> >>>>>> >>>> >>>>>> credential representing the >>>> >>>>>> resource owner's authorization >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> grant_type >>>> >>>>>> >>>> >>>>>> (string representing the) >>> type >>>> >>>>>> of grant sent to the token >>>> >>>>>> endpoint to obtain the access >>> token >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> Thus, the grant sent to the token >>>> >>>>>> endpoint in this case is still >>>> >>>>>> 'code'. >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> Response type on the other >>> hand is >>>> >>>>>> not so well defined in RFC6749, >>>> >>>>>> but it seems it is representing >>>> >>>>>> what is to be returned from the >>>> >>>>>> authorization endpoint. To >>> express >>>> >>>>>> what is to be returned from token >>>> >>>>>> endpoint, perhaps defining a new >>>> >>>>>> parameter to the token endpoint, >>>> >>>>>> which is a parallel to the >>>> >>>>>> response_type to the >>> Authorization >>>> >>>>>> Endpoint seems to be a more >>>> >>>>>> symmetric way, though I am not >>>> >>>>>> sure at all if that is going >>> to be >>>> >>>>>> OAuth any more. One straw-man is >>>> >>>>>> to define a new parameter called >>>> >>>>>> response_type to the token >>>> >>>>>> endpoint such as: >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> response_type >>>> >>>>>> >>>> >>>>>> OPTIONAL. A string >>>> >>>>>> representing what is to be >>>> >>>>>> returned from the token endpoint. >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> Then define the behavior of the >>>> >>>>>> endpoint according to the values >>>> >>>>>> as the parallel to the >>>> >>>>>> multi-response type spec. >>>> >>>>>> >>>> >>>>>> >>>> http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> Nat >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> 2014-07-23 7:21 GMT-04:00 Phil >>>> >>>>>> Hunt >>> >>>>>> >: >>>> >>>>>> >>>> >>>>>> The draft is very clear. >>>> >>>>>> >>>> >>>>>> Phil >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> On Jul 23, 2014, at 0:46, Nat >>>> >>>>>> Sakimura >>> >>>>>> > >>> wrote: >>>> >>>>>> >>>> >>>>>> The new grant type that I was >>>> >>>>>> talking about was >>>> >>>>>> >>>> >>>>>> >>>> "authorization_code_but_do_not_return_access_nor_refresh_token", >>>> >>>>>> so to speak. >>>> >>>>>> >>>> >>>>>> It does not return anything >>>> >>>>>> per se, but an extension can >>>> >>>>>> define something on top >>> of it. >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> Then, OIDC can define a >>>> >>>>>> binding to it so that the >>>> >>>>>> binding only returns ID >>> Token. >>>> >>>>>> >>>> >>>>>> This binding work should be >>>> >>>>>> done in OIDF. Should there be >>>> >>>>>> such a grant type, >>>> >>>>>> >>>> >>>>>> it will be an extremely short >>>> >>>>>> spec. >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> At the same time, if any >>> other >>>> >>>>>> specification wanted to >>> define >>>> >>>>>> >>>> >>>>>> other type of tokens and have >>>> >>>>>> it returned from the token >>>> >>>>>> endpoint, >>>> >>>>>> >>>> >>>>>> it can also use this >>> grant type. >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> If what you want is to define >>>> >>>>>> a new grant type that returns >>>> >>>>>> ID Token only, >>>> >>>>>> >>>> >>>>>> then, I am with Justin. Since >>>> >>>>>> "other response than ID >>> Token" >>>> >>>>>> is only >>>> >>>>>> >>>> >>>>>> theoretical, this is a more >>>> >>>>>> plausible way forward, I >>>> suppose. >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> Nat >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> 2014-07-22 14:30 GMT-04:00 >>>> >>>>>> Justin Richer >>> >>> >>>>>> >: >>>> >>>>>> >>>> >>>>>> So the draft would literally >>>> >>>>>> turn into: >>>> >>>>>> >>>> >>>>>> "The a4c response type and >>>> >>>>>> grant type return an id_token >>>> >>>>>> from the token endpoint with >>>> >>>>>> no access token. All >>>> >>>>>> parameters and values are >>>> >>>>>> defined in OIDC." >>>> >>>>>> >>>> >>>>>> Seems like the perfect mini >>>> >>>>>> extension draft for OIDF >>> to do. >>>> >>>>>> >>>> >>>>>> --Justin >>>> >>>>>> >>>> >>>>>> /sent from my phone/ >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> On Jul 22, 2014 10:29 AM, Nat >>>> >>>>>> Sakimura >>> >>>>>> > >>>> >>>>>> wrote: >>>> >>>>>> > >>>> >>>>>> > What about just defining a >>>> >>>>>> new grant type in this WG? >>>> >>>>>> > >>>> >>>>>> > >>>> >>>>>> > 2014-07-22 12:56 GMT-04:00 >>>> >>>>>> Phil Hunt >>>> >>>>>> >>> >>>>>> >>> >: >>>> >>>>>> >> >>>> >>>>>> >> That would be nice. >>> However >>>> >>>>>> oidc still needs the new >>> grant >>>> >>>>>> type in order to >>> implement the >>>> >>>>>> same flow. >>>> >>>>>> >> >>>> >>>>>> >> Phil >>>> >>>>>> >> >>>> >>>>>> >> On Jul 22, 2014, at 11:35, >>>> >>>>>> Nat Sakimura >>>> >>>>>> >>> >>>>>> > >>>> >>>>>> wrote: >>>> >>>>>> >> >>>> >>>>>> >>> +1 to Justin. >>>> >>>>>> >>> >>>> >>>>>> >>> >>>> >>>>>> >>> 2014-07-22 9:54 GMT-04:00 >>>> >>>>>> Richer, Justin P. >>>> >>>>>> >>> >>>>>> >: >>>> >>>>>> >>>> >>>> >>>>>> >>>> Errors like these >>> make it >>>> >>>>>> clear to me that it would >>> make >>>> >>>>>> much more sense to develop >>>> >>>>>> this document in the OpenID >>>> >>>>>> Foundation. It should be >>>> >>>>>> something that directly >>>> >>>>>> references OpenID Connect >>> Core >>>> >>>>>> for all of these terms >>> instead >>>> >>>>>> of redefining them. It's >>> doing >>>> >>>>>> authentication, which is >>>> >>>>>> fundamentally what OpenID >>>> >>>>>> Connect does on top of OAuth, >>>> >>>>>> and I don't see a good >>>> >>>>>> argument for doing this work >>>> >>>>>> in this working group. >>>> >>>>>> >>>> >>>> >>>>>> >>>> -- Justin >>>> >>>>>> >>>> >>>> >>>>>> >>>> On Jul 22, 2014, at 4:30 >>>> >>>>>> AM, Thomas Broyer >>>> >>>>>> >>> >>>>>> > >>>> >>>>>> wrote: >>>> >>>>>> >>>> >>>> >>>>>> >>>>> >>>> >>>>>> >>>>> >>>> >>>>>> >>>>> >>>> >>>>>> >>>>> On Mon, Jul 21, 2014 at >>>> >>>>>> 11:52 PM, Mike Jones >>>> >>>>>> >>> >>>>>> >>>> > >>>> >>>>>> wrote: >>>> >>>>>> >>>>>> >>>> >>>>>> >>>>>> Thanks for your >>> review, >>>> >>>>>> Thomas. The "prompt=consent" >>>> >>>>>> definition being missing >>> is an >>>> >>>>>> editorial error. It >>> should be: >>>> >>>>>> >>>>>> >>>> >>>>>> >>>>>> >>>> >>>>>> >>>>>> >>>> >>>>>> >>>>>> consent >>>> >>>>>> >>>>>> >>>> >>>>>> >>>>>> The Authorization >>>> >>>>>> Server SHOULD prompt the >>>> >>>>>> End-User for consent before >>>> >>>>>> returning information to the >>>> >>>>>> Client. If it cannot obtain >>>> >>>>>> consent, it MUST return an >>>> >>>>>> error, typically >>>> consent_required. >>>> >>>>>> >>>>>> >>>> >>>>>> >>>>>> >>>> >>>>>> >>>>>> >>>> >>>>>> >>>>>> I'll plan to add it in >>>> >>>>>> the next draft. >>>> >>>>>> >>>>> >>>> >>>>>> >>>>> >>>> >>>>>> >>>>> It looks like the >>>> >>>>>> consent_required error needs >>>> >>>>>> to be defined too, and you >>>> >>>>>> might have forgotten to also >>>> >>>>>> import >>>> >>>>>> account_selection_required >>>> >>>>>> from OpenID Connect. >>>> >>>>>> >>>>> >>>> >>>>>> >>>>>> >>>> >>>>>> >>>>>> >>>> >>>>>> >>>>>> >>>> >>>>>> >>>>>> I agree that >>> there's no >>>> >>>>>> difference between a response >>>> >>>>>> with multiple "amr" values >>>> >>>>>> that includes "mfa" and one >>>> >>>>>> that doesn't. Unless a clear >>>> >>>>>> use case for why "mfa" is >>>> >>>>>> needed can be identified, we >>>> >>>>>> can delete it in the next >>> draft. >>>> >>>>>> >>>>> >>>> >>>>>> >>>>> >>>> >>>>>> >>>>> Thanks. >>>> >>>>>> >>>>> >>>> >>>>>> >>>>> How about "pwd" then? I >>>> >>>>>> fully understand that I >>> should >>>> >>>>>> return "pwd" if the user >>>> >>>>>> authenticated using a >>>> >>>>>> password, but what "the >>>> >>>>>> service if a client secret is >>>> >>>>>> used" means in the definition >>>> >>>>>> for the "pwd" value? >>>> >>>>>> >>>>> >>>> >>>>>> >>>>> (Nota: I know you're at >>>> >>>>>> IETF-90, I'm ready to wait >>>> >>>>>> 'til you come back ;-) ) >>>> >>>>>> >>>>> >>>> >>>>>> >>>>> -- >>>> >>>>>> >>>>> Thomas Broyer >>>> >>>>>> >>>>> /tɔ.ma.bʁwa.je/ >>>> >>>>>> >>>> >>>> >>>>>> >>>>> >>>> >>>>>> >>>> _______________________________________________ >>>> >>>>>> >>>>> 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 >>>> >>>>>> >>>> >>>> >>>>>> >>> >>>> >>>>>> >>> >>>> >>>>>> >>> >>>> >>>>>> >>> -- >>>> >>>>>> >>> Nat Sakimura (=nat) >>>> >>>>>> >>> Chairman, OpenID >>> Foundation >>>> >>>>>> >>> http://nat.sakimura.org/ >>>> >>>>>> >>> @_nat_en >>>> >>>>>> >>> >>>> >>>>>> >>> >>>> >>>>>> >>>> _______________________________________________ >>>> >>>>>> >>> OAuth mailing list >>>> >>>>>> >>> OAuth@ietf.org >>>> >>>>>> >>>> >>>>>> >>> >>>> >>>>>> >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>>>> > >>>> >>>>>> > >>>> >>>>>> > >>>> >>>>>> > >>>> >>>>>> > -- >>>> >>>>>> > Nat Sakimura (=nat) >>>> >>>>>> > Chairman, OpenID Foundation >>>> >>>>>> > http://nat.sakimura.org/ >>>> >>>>>> > @_nat_en >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> -- >>>> >>>>>> Nat Sakimura (=nat) >>>> >>>>>> >>>> >>>>>> Chairman, OpenID Foundation >>>> >>>>>> http://nat.sakimura.org/ >>>> >>>>>> @_nat_en >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> -- >>>> >>>>>> Nat Sakimura (=nat) >>>> >>>>>> >>>> >>>>>> Chairman, OpenID Foundation >>>> >>>>>> http://nat.sakimura.org/ >>>> >>>>>> @_nat_en >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> _______________________________________________ >>>> >>>>>> OAuth mailing list >>>> >>>>>> OAuth@ietf.org >>>> >>>> >>>>>> >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> -- >>>> >>>>>> Thomas Broyer >>>> >>>>>> /tɔ.ma.bʁwa.je/ >>>> >>>>>> >>> >>>> >>>>>> >>>> >>>>>> >>>> _______________________________________________ >>>> >>>>>> OAuth mailing list >>>> >>>>>> OAuth@ietf.org >>>> >>>> >>>>>> >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> -- >>>> >>>>>> Thomas Broyer >>>> >>>>>> /tɔ.ma.bʁwa.je/ >>>> >>>>>> >>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> _______________________________________________ >>>> >>>>>> OAuth mailing list >>>> >>>>>> OAuth@ietf.org >>>> >>>> >>>>>> >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> -- >>>> >>>>>> Nat Sakimura (=nat) >>>> >>>>>> >>>> >>>>>> Chairman, OpenID Foundation >>>> >>>>>> http://nat.sakimura.org/ >>>> >>>>>> @_nat_en >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> _______________________________________________ >>>> >>>>>> >>>> >>>>>> 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 >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> -- >>>> >>>>>> Nat Sakimura (=nat) >>>> >>>>>> Chairman, OpenID Foundation >>>> >>>>>> http://nat.sakimura.org/ >>>> >>>>>> @_nat_en >>>> >>>>>> >>>> >>>>>> >>> _______________________________________________ >>>> >>>>>> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > From nobody Mon Oct 13 13:57:23 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E258A1A006D for ; Mon, 13 Oct 2014 13:57:20 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7JNFzSx381a1 for ; Mon, 13 Oct 2014 13:57:19 -0700 (PDT) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0330F1A0055 for ; Mon, 13 Oct 2014 13:57:18 -0700 (PDT) Received: by mail-ig0-f171.google.com with SMTP id h15so11982867igd.10 for ; Mon, 13 Oct 2014 13:57:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=jAcpQBauD75FQVTdUI1ifyaLFXk66K9pNCcMN1u0tmQ=; b=D68o5mMztqGet9r32WqKfRoQI4Ah/zIhowhybJWMgXIvINzNujg8eOsDs/6Ik9eRMv QiwbtCRoQvOLWWLg9M7NqBKoTssX2BGcPwSxy1+L2rKLU4/WG7V4QeApW2q54q0O/sJ0 MyFrRXWUudKrpl3wccw4DDLyskpAygG2ONeU6N/oifnL6zzKdAaAEQya24nZIJ0athqm rF+DUw3MUj8j+3JdwMDzLscnc8/crfQmyxaGvbsG3GlfLraGqIQmJzn2ZEksczFWILLx v+YTsrDoS8szfCsmUe5To54RsyaYgoLa3/WRgAtgve1AMHRFzAz34GxHGYTd5OZTP549 OH6w== X-Received: by 10.42.237.80 with SMTP id kn16mr1012256icb.29.1413233838401; Mon, 13 Oct 2014 13:57:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.72.44 with HTTP; Mon, 13 Oct 2014 13:56:58 -0700 (PDT) In-Reply-To: <543BFF34.1070307@gmx.net> References: <543BFF34.1070307@gmx.net> From: Adam Renberg Date: Mon, 13 Oct 2014 22:56:58 +0200 Message-ID: To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=047d7bacb3f2ec30b00505542419 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/9OiRrr8j2E1M5c_35sxTny1ZXo0 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Blackhat US: OAuth Talk X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 20:57:21 -0000 --047d7bacb3f2ec30b00505542419 Content-Type: text/plain; charset=UTF-8 Hi!, I have read through the paper, and what they consider a flaw in OAuth 2 is the fact that for the implicit grant flow the access token is sent to the client through the User Agent, and thus the User Agent can intercept it. What they find is that "social network provider X" allows the implicit grant flow for clients that normally use the authorization code flow. This makes it possible for and attacker to construct an implicit flow request and obtain an access token issued for the client, and this access token might incorrectly be considered as for a confidential client by the provider. But the issue here is with the provider, which treats the same client as both public and private, and not with OAuth 2. The paper also takes issue with the fact that an API that is authorized with OAuth 2 exposes more data than what is normally presented to the user when browsing at provider X. This is not an issue with OAuth 2. They also take issue with the fact that the provider does not throttle API calls, so it is possible to make a crawler, using access tokens issued for a registered client but through the implicit flow, and *authorized by a resource owner complicit with the attackers / crawler builders*, to scrape large amounts of data from the provider. Data that users might not think to be so "publicly accessible". I think that this is dealt with in https://tools.ietf.org/html/rfc6749#section-10.1, https://tools.ietf.org/html/rfc6749#section-10.2, and by RFC 6819 5.2.3.2. Require User Consent for Public Clients without Secret https://tools.ietf.org/html/rfc6819#page-60 Cheers, Adam Renberg (first time poster :)) On Oct 13, 2014 6:35 PM, "Hannes Tschofenig" wrote: > During the OAuth conference call today I asked whether someone had > looked at this paper published at the recent Blackhat US conference and > nobody knew about it. > > Hence, I am posting it here: > > * Paper: > > > https://www.blackhat.com/docs/us-14/materials/us-14-Hu-How-To-Leak-A100-Million-Node-Social-Graph-In-Just-One-Week-WP.pdf > > * Slides: > > https://www.blackhat.com/docs/us-14/materials/us-14-Hu-How-To-Leak-A100-Million-Node-Social-Graph-In-Just-One-Week.pdf > > Ciao > Hannes > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --047d7bacb3f2ec30b00505542419 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi!,

I have read through the paper, a= nd what they consider a flaw in OAuth 2 is the fact that for the implicit g= rant flow the access token is sent to the client through the User Agent, an= d thus the User Agent can intercept it. What they find is that "social= network provider X" allows the implicit grant flow for clients that n= ormally use the authorization code flow. This makes it possible for and att= acker to construct an implicit flow request and obtain an access token issu= ed for the client, and this access token might incorrectly be considered as= for a confidential client by the provider.

But the issue here is wit= h the provider, which treats the same client as both public and private, an= d not with OAuth 2.

The paper also takes issue with the fact that an = API that is authorized with OAuth 2 exposes more data than what is normally= presented to the user when browsing at provider X. This is not an issue wi= th OAuth 2.

They also take issue with the fact that the provider does= not throttle API calls, so it is possible to make a crawler, using access = tokens issued for a registered client but through the implicit flow, and authorized by a resource owner complicit with the attackers / crawler buil= ders, to scrape large amounts of data from the provider. Data that user= s might not think to be so "publicly accessible".

I thi= nk that this is dealt with in

https://tools.ietf.org/html/rfc6749#section-10.1,= https://tools= .ietf.org/html/rfc6749#section-10.2, and by RFC 6819 5.2.3.2.=C2=A0 Req= uire User Consent for Public Clients without Secret https://tools.ietf.org/html/rfc6819#page-6= 0


Cheers,

Adam Renberg (first time poster :))


On Oct 13, 2014 6:35 PM, "Hannes Tschofenig= " <h= annes.tschofenig@gmx.net> wrote:
During the OAuth conference call today I asked whether someone had looked at this paper published at the recent Blackhat US conference and
nobody knew about it.

Hence, I am posting it here:

* Paper:

https://www.blackhat.com/docs/us-14/materials/us-14-Hu-How-To-Leak-A100-M= illion-Node-Social-Graph-In-Just-One-Week-WP.pdf

* Slides:
h= ttps://www.blackhat.com/docs/us-14/materials/us-14-Hu-How-To-Leak-A100-Mill= ion-Node-Social-Graph-In-Just-One-Week.pdf

Ciao
Hannes


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

--047d7bacb3f2ec30b00505542419-- From nobody Mon Oct 13 14:18:05 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80E281A0041 for ; Mon, 13 Oct 2014 14:18:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.987 X-Spam-Level: X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlE4cNx7cLmO for ; Mon, 13 Oct 2014 14:17:55 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DA0A1A0029 for ; Mon, 13 Oct 2014 14:17:55 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s9DLHqwC024123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 13 Oct 2014 21:17:53 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s9DLHpj0022819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 13 Oct 2014 21:17:52 GMT Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s9DLHo2a006640; Mon, 13 Oct 2014 21:17:50 GMT Received: from [192.168.1.133] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 13 Oct 2014 14:17:49 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: <543C3510.7070201@gmail.com> Date: Mon, 13 Oct 2014 14:17:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9C1B0B29-47AB-4057-96B4-BA18E116B5B1@oracle.com> References: <543BE1A1.6020902@gmail.com> <44A3CD9F-9E2E-4746-A5B1-47984BBE973C@oracle.com> <543C3510.7070201@gmail.com> To: Sergey Beryozkin X-Mailer: Apple Mail (2.1878.6) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/PfIepA3XG8j2oN5jyJQTFWCnPes Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 21:18:00 -0000 Sergey, Actually, I think your comments are fine. They add to the discussion on = why A4C is distinct from OIDC=E2=80=99s larger IDP role in an OAuth = style flow and why *both* are needed. Comments in line. Phil @independentid www.independentid.com phil.hunt@oracle.com On Oct 13, 2014, at 1:24 PM, Sergey Beryozkin = wrote: > Hi Phil >=20 > Thanks for the clarifications, > On 13/10/14 20:18, Phil Hunt wrote: >> The point to be made is if the client=E2=80=99s objective is to = authenticate the User, the base 6749 spec does not guarantee this at = all. >>=20 >> It simply authorizes the client to access a resource and nothing = more. >>=20 >> It turns out that a significant part of the time authentication does = occur, but the client does not have access to that information. Nor can = it specifically request re-authentication. >>=20 >> Further, if the client doesn=E2=80=99t wield the access token, its = might not be proof that the token received was actually an = authorization. >>=20 >> OpenID gives you both authen information and authorization profile = information (as a resource). >>=20 > Yes, I experimented with it. >> This thread was more about how to do just authentication ONLY. What = are the requirements for a client to know a User *was* authenticated and = when. While some flows of OpenID can achieve this, its not clear that = it addresses all cases. Furhter there is discussion (as Justin mentions) = that a flow that does not produce an access token is not an = authorization flow and is not OAuth. I agree. > Sure. >> It an authentication flow and should be distinct IMHO. >>=20 > I guess that is why the idea of having an OIDC profile dedicated to = the authentication alone (no access token) which I believe was suggested = here caught my attention. But then it is not OAuth2 and hence not OIDC. = The chicken in the egg situation :-). As I said in the prev email, = having an access token which is really restricted to the OIDC resource = (profile) seems like a good compromise=E2=80=A6 [PH] We discussed this in Toronto and OIDC can=E2=80=99t do this and be = compliant woith OAuth. It wouldn=E2=80=99t be OAuth. Someone also = pointed out that the OAuth WG isn=E2=80=99t chartered to do = authentication and that kind of killed the discussion leaving the issue = hanging unresolved. If you look at draft 00 of the A4C draft you will note that I originally = proposed it as a new end-point. My feeling it should NOT be an OAuth = flow - because as Justin says, if you aren=E2=80=99t returning an access = token, you aren=E2=80=99t doing OAuth. The issue is that the technical = redirect flow for authentication and authorization share the same = security risks and counter-measures. It would be good therefore to build = =E2=80=9Cin-parallel=E2=80=9D or =E2=80=9Cunderneath=E2=80=9D OAuth to = define an authn flow. I would still recommend OIDC as a layer on top of OAuth that defines the = standard way to get profile claims (the full OAuth style IDP = functionality).=20 >=20 >> That said, I am in the minority with this opinion and I acknowledge = as being as such. >>=20 >=20 > Sorry if I hijacked this thread and started the off-topic 'flow'...I = guess my reasoning here is a bit all over the place, but I'm pretty sure = now I see the big picture better >=20 > Thanks, Sergey >=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >> On Oct 13, 2014, at 7:28 AM, Sergey Beryozkin = wrote: >>=20 >>> On 13/10/14 15:17, Justin Richer wrote: >>>> You certainly can do authentication without using an access token, = but >>>> then I would argue that's no longer OAuth. Basically you're making = tofu >>>> carob fudge. >>>=20 >>> Right, the access token is there for a client to get to the UserInfo = endpoint, as far as OIDC is concerned. What if the info in the id_token = is sufficient ? >>> I guess as far as a typical OAuth2 client is concerned, requesting = "openid profile" only effectively gives one an access token that can = only be used with the UserInfo endpoint. >>>=20 >>> So yes, may be even though OIDC has an access token returned, unless = other custom scopes are used, the access token would be pretty much of = use in the OIDC context only if a client chooses to work with the = UserInfo...I guess the id_token/at_hash is useful on its own >>>=20 >>>=20 >>> Cheers, Sergey >>>=20 >>>>=20 >>>>=20 >>>> -- Justin >>>>=20 >>>> / Sent from my phone / >>>>=20 >>>>=20 >>>> -------- Original message -------- >>>> From: Sergey Beryozkin >>>> Date:10/13/2014 9:00 AM (GMT-05:00) >>>> To: Justin Richer , oauth@ietf.org >>>> Cc: >>>> Subject: Re: [OAUTH-WG] New Version Notification for >>>> draft-hunt-oauth-v2-user-a4c-05.txt >>>>=20 >>>> Hi Justin, >>>> On 13/10/14 12:53, Justin Richer wrote: >>>>> You are correct in that OAuth 2 and OpenID Connect are not the = same >>>>> thing, but your user is correct that OIDC adds a few pieces on top = of >>>>> OAuth to add authentication capabilities. OIDC was designed very >>>>> explicitly to be compatible with vanilla OAuth, partially do that = people >>>>> would be able to deploy it on top of existing OAuth infrastructure = and >>>>> code. But the very fact that OIDC adds a few things on top of = OAuth to >>>>> give more functionality should be sufficient evidence that they're = not >>>>> equivalent. >>>>>=20 >>>>> It's more proper to say that OpenID Connect is an extension and >>>>> application of OAuth. One that provides an authentication and >>>> identity API. >>>>>=20 >>>> I agree and this is more or less how I answered. >>>>=20 >>>> Though the 'borders' can be blurred, one can claim that if a user >>>> actually logs on into a confidential OAuth2 client web application = which >>>> redirects this user to AS requesting a code with some scopes such = as "a >>>> b" then when it uses "a b openid profile" it is basically does a = pure >>>> OAuth2 code flow where the client requests 'a b' plus also a scope >>>> allowing it later to query the identity system on behalf of a user. >>>>=20 >>>> I like the "The extension and application of OAuth2" characteristic = of >>>> OIDC. IMHO it's becoming more obvious if OIDC is used to support = SSO >>>> into non-OAuth2 servers, when it is the case then there's no = 'feeling' >>>> that OIDC is just a case of the confidential client adding the = extra >>>> scopes and getting the extra (authentication) info back. A = standalone >>>> OIDC RP protecting such non OAuth2 servers is very much about the >>>> authentication/identity. >>>>=20 >>>> I also thought that having some OID profile (as opposed updating = OAuth2 >>>> to support no access tokens) where no access but only id token was >>>> returned (as suggested in this thread) would probably make sense = too. >>>>=20 >>>>> The way I like to explain it (which I stole from someone else) is = that >>>>> OAuth is like chocolate and authentication is like fudge. They are = not >>>>> the same thing. You can make chocolate into fudge out you can make = it >>>>> into something else or you can just have it on its own. You can = make >>>>> fudge with chocolate or you can make it with peanut butter or you = can >>>>> make it with potatoes if you want to, but it needs a couple = ingredients >>>>> and a very common one is chocolate. OpenID Connect is a recipe for >>>>> chocolate fudge that a lot of people like. And it makes my fudge >>>>> compatible with your fudge, which is where the metaphor breaks = down. :-) >>>>>=20 >>>> Thanks for sharing this colourful explanation :-). Perhaps I should >>>> borrow it :-), >>>> Cheers, Sergey >>>>=20 >>>>=20 >>>>>=20 >>>>> -- Justin >>>>>=20 >>>>> / Sent from my phone / >>>>>=20 >>>>>=20 >>>>> -------- Original message -------- >>>>> From: Sergey Beryozkin >>>>> Date:10/13/2014 6:33 AM (GMT-05:00) >>>>> To: oauth@ietf.org >>>>> Cc: >>>>> Subject: Re: [OAUTH-WG] New Version Notification for >>>>> draft-hunt-oauth-v2-user-a4c-05.txt >>>>>=20 >>>>> Hi >>>>>=20 >>>>> We've had a user asserting that "OAuth2 =3D=3D OpenidConnect", = referring to >>>>> the fact that the 'only' thing OIC adds on top of the = authorization code >>>>> flow is the client specifying few extra scopes like 'openid' and >>>>> 'profile' and the authorization service returning an extra = property, the >>>>> id_token which can be sufficient in order to get the authenticated >>>>> user's info. >>>>>=20 >>>>> My understanding "OAuth2 !=3D OpenidConnect", the latter utilizes = the >>>>> former and is an authentication mechanism which is not what OAuth2 = is >>>>> (may be except for the client credentials). But I don't feel like = it is >>>>> a convincing enough argument. >>>>>=20 >>>>> I thought this thread was relevant, sorry if not, would have no = problems >>>>> starting a new one. >>>>>=20 >>>>> Basically, I wonder what is the proper line of argument for a = position >>>>> such as "OAuth2 !=3D OpenidConnect" and also what was the action = to the >>>>> list of options suggested by John below. Is having an OID profile = where >>>>> no access token is returned would be the cleanest action as far as >>>>> breaking the ambiguity/confusion is concerned ? >>>>>=20 >>>>> Cheers, Sergey >>>>>=20 >>>>> On 24/07/14 15:25, John Bradley wrote: >>>>> > I am not against discussion in the WG. >>>>> > >>>>> > I happen to agree with Phil's fundamental premise that some = developers >>>>> > are using OAuth in a insecure way to do authentication. >>>>> > >>>>> > That raises the question of how to best educate them, and or = address >>>>> > technical barriers. >>>>> > >>>>> > It is on the second point that people's opinions seem to = divide. >>>>> > >>>>> > Some people thing that if we have a OAuth flow that eliminates = the >>>>> > access token (primarily to avoid asking for consent as I >>>> understand it) >>>>> > and just return a id_token from the token endpoint that can be >>>> done in a >>>>> > spec short enough to het people to read. The subtext of this = is that >>>>> > the Connect specification is too large that it scare people, = and they >>>>> > don't find the spec in the first place because it is not a RFC. >>>>> > >>>>> > An other common possession is that if you don't want to prompt = the >>>> user >>>>> > for consent then don't ask for scopes. Twisting the OAuth spec = to not >>>>> > return an access token is not OAuth, yes you could use a = different >>>>> > endpoint rather than the token endpoint, but that is not OAuth. >>>>> > Connect was careful not to break the OAuth spec. As long as = you are >>>>> > willing to take a access token with no scopes (the client needs = to >>>>> > understand that there are no attributes one way or another = anyway >>>> or it >>>>> > will break) then you don't need to change OAuth. You can = publish a >>>>> > profile of connect that satisfies the use case. >>>>> > >>>>> > I think Mike has largely done that but it might be better being = less >>>>> > stingy on references back to the larger spec. >>>>> > >>>>> > The questions are do we modify OAuth to not return an access >>>> token, and >>>>> > if so how, and if we do is it still OAuth. >>>>> > >>>>> > The other largely separable question is do we create confusion = in the >>>>> > market and slow the the adoption of identity federation on top = of >>>> OAuth, >>>>> > or find a way to make this look like a positive alignment of = interests >>>>> > around a subset of Connect. >>>>> > >>>>> > There are a number of options. >>>>> > 1: We can do a profile in the OIDF and publish it as a IETF = document. >>>>> > Perhaps the cleanest from an IPR point of view.However >>>>> > 2:We can do a profile in the OAuth WG referencing connect. >>>>> > 3:We can do a AD sponsored profile that is not in the OAuth WG. >>>>> > 4:We can do a small spec in OAuth to add response_type to the = token >>>>> > endpoint. in combination with 1, 2, or 3 >>>>> > >>>>> > I agree that stoping developers doing insecure things needs to = be >>>>> > addressed somehow. >>>>> > I am not personally convinced that Oauth without access tokens = is >>>>> sensible. >>>>> > >>>>> > Looking forward to the meeting:) >>>>> > >>>>> > John B. >>>>> > On Jul 24, 2014, at 6:52 AM, Brian Campbell >>>> >>>> > > wrote: >>>>> > >>>>> >> I'd note that the reaction at the conference to Ian's = statement was >>>>> >> overwhelmingly positive. There was a wide range of industry = people >>>>> >> here - implementers, practitioners, deployers, strategists, = etc. >>>> - and >>>>> >> it seems pretty clear that the "rough consensus" of the = industry at >>>>> >> large is that a4c is not wanted or needed. >>>>> >> >>>>> >> >>>>> >> On Thu, Jul 24, 2014 at 5:29 AM, Nat Sakimura = >>>> >> > wrote: >>>>> >> >>>>> >> And here is a quote from Ian's blog. >>>>> >> >>>>> >> And although the authentication wheel is round, that = doesn=E2=80=99t >>>>> >> mean it isn=E2=80=99t without its lumps. First, we do = see some >>>>> >> reinventing the wheel just to reinvent the wheel. = OAuth >>>> A4C is >>>>> >> simply not a fruitful activity and should be put down. >>>>> >> >>>>> >> (Source) >>>>> >> >>>>>=20 >>>> = http://www.tuesdaynight.org/2014/07/23/do-we-have-a-round-wheel-yet-musing= s-on-identity-standards-part-1.html >>>>> >> >>>>> >> >>>>> >> >>>>> >> 2014-07-23 16:53 GMT-04:00 John Bradley >>>> >> >: >>>>> >> >>>>> >> I thought I did post this to the list. >>>>> >> >>>>> >> I guess I hit the wrong reply on my phone. >>>>> >> John B. >>>>> >> Sent from my iPhone >>>>> >> >>>>> >> On Jul 23, 2014, at 4:50 PM, torsten@lodderstedt.net >>>>> >> wrote: >>>>> >> >>>>> >>> we are two, at least :-) >>>>> >>> >>>>> >>> Why didn't you post this on the list? >>>>> >>> >>>>> >>> When will be be arriving? >>>>> >>> >>>>> >>> Am 23.07.2014 16:39, schrieb John Bradley: >>>>> >>> >>>>> >>>> Ian Glazer mentioned this in his keynote at CIS = yesterday. >>>>> >>>> His advice was please stop, we are creating = confusion and >>>>> >>>> uncertainty. >>>>> >>>> We are becoming our own wort enemy. ( my view though >>>> Ian may >>>>> >>>> share it) >>>>> >>>> Returning just an id_ token from the token endpoint = has >>>>> >>>> little real value. >>>>> >>>> Something really useful to do would be sorting out >>>>> >>>> channel_id so we can do PoP for id tokens to make = them and >>>>> >>>> other cookies secure in the front channel. I think >>>> that is >>>>> >>>> a better use of time. >>>>> >>>> I may be in the minority opinion on that, it won't = be the >>>>> >>>> first time. >>>>> >>>> >>>>> >>>> >>>>> >>>> John B. >>>>> >>>> Sent from my iPhone >>>>> >>>> >>>>> >>>> On Jul 23, 2014, at 4:04 PM, Torsten Lodderstedt >>>>> >>>> > >>>>> >>>> wrote: >>>>> >>>> >>>>> >>>>> You are right from a theoretical perspective. = Practically >>>>> >>>>> this was caused by editorial decisions during the = creation >>>>> >>>>> of the RFC. As far as I remember, there was a >>>> definition of >>>>> >>>>> the (one) token endpoint response in early = versions. >>>> No one >>>>> >>>>> every considered to NOT respond with an access = token from >>>>> >>>>> the token endpoint. So one might call it an = implicit >>>>> >>>>> assumption. >>>>> >>>>> I'm worried that people get totally confused if an >>>>> >>>>> exception is introduced now given the broad = adoption of >>>>> >>>>> OAuth based on this assumption. >>>>> >>>>> regards, >>>>> >>>>> Torsten. >>>>> >>>>> >>>>> >>>>> Am 23.07.2014 um 15:41 schrieb Thomas Broyer >>>>> >>>>> >: >>>>> >>>>> >>>>> >>>>>> Is it said anywhere that ALL grant types MUST use = Section >>>>> >>>>>> 5.1 responses? Each grant type references Section >>>> 5.1, and >>>>> >>>>>> "access token request" is only defined in the = context of >>>>> >>>>>> the defined grant types. Section 2.2 doesn't talk = about >>>>> >>>>>> the request or response format. >>>>> >>>>>> >>>>> >>>>>> Le 23 juil. 2014 21:32, "Nat Sakimura" >>>> >>>> >>>>>> > a =C3=A9crit : >>>>> >>>>>> >>>>> >>>>>> Is it? Apart from the implicit grant that does >>>> not use >>>>> >>>>>> token endpoint, all other grant references >>>> section 5.1 >>>>> >>>>>> for the response, i.e., all shares the same = response. >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> 2014-07-23 15:18 GMT-04:00 Thomas Broyer >>>>> >>>>>> >: >>>>> >>>>>> >>>>> >>>>>> I hadn't realized the JSON response that = requires >>>>> >>>>>> the access_token field is defined per = grant_type, >>>>> >>>>>> so I'd be OK to "extend the semantics" as = in the >>>>> >>>>>> current draft. >>>>> >>>>>> That was actually my main concern: that = the token >>>>> >>>>>> endpoint mandates access_token; but its = actually >>>>> >>>>>> not the case. >>>>> >>>>>> >>>>> >>>>>> Le 23 juil. 2014 20:46, "Nat Sakimura" >>>>> >>>>>> >>> > a >>>>> >>>>>> =C3=A9crit : >>>>> >>>>>> >>>>> >>>>>> I agree with John that overloading >>>>> >>>>>> response_type @ authz endpoint is a = bad idea. >>>>> >>>>>> It completely changes the semantics of = this >>>>> >>>>>> parameter. NOTE: what I was proposing = was not >>>>> >>>>>> this parameter, but a new parameter >>>>> >>>>>> response_type @ token endpoint. >>>>> >>>>>> I also think overloading grant_type is = a bad >>>>> >>>>>> idea since it changes its semantics. I = quote >>>>> >>>>>> the definition here again: >>>>> >>>>>> grant >>>>> >>>>>> credential representing the = resource >>>>> >>>>>> owner's authorization >>>>> >>>>>> grant_type >>>>> >>>>>> type of grant sent to the token = endpoint to >>>>> >>>>>> obtain the access token >>>>> >>>>>> It is not about controlling what is to = be >>>>> >>>>>> returned from the token endpoint, but = the >>>> hint >>>>> >>>>>> to the token endpoint describing the = type of >>>>> >>>>>> credential the endpoint has received. = It >>>> seems >>>>> >>>>>> the "control of what is being returned = from >>>>> >>>>>> token endpoint" is just a side = effect. >>>>> >>>>>> I am somewhat ambivalent[1] in = changing the >>>>> >>>>>> semantics of token endpoint, but in as >>>> much as >>>>> >>>>>> "text is the king" for a spec., we = probably >>>>> >>>>>> should not change the semantics of it = as >>>>> >>>>>> Torsten points out. If it is ok to = change >>>> this >>>>> >>>>>> semantics, I believe defining a new = parameter >>>>> >>>>>> to this endpoint to control the = response >>>> would >>>>> >>>>>> be the best way to go. This is what I = have >>>>> >>>>>> described previously. >>>>> >>>>>> Defining a new endpoint to send code = to >>>> get ID >>>>> >>>>>> Token and forbidding the use of it = against >>>>> >>>>>> token endpoint would not change the = semantics >>>>> >>>>>> of any existing parameter or endpoint, = which >>>>> >>>>>> is good. However, I doubt if it is not = worth >>>>> >>>>>> doing. What's the point of avoiding = access >>>>> >>>>>> token scoped to UserInfo endpoint = after all? >>>>> >>>>>> Defining a new endpoint for just = avoiding the >>>>> >>>>>> access token for userinfo endpoint = seems way >>>>> >>>>>> too much the heavy wait way and it = breaks >>>>> >>>>>> interoperabiliy: it defeats the = purpose of >>>>> >>>>>> standardization. >>>>> >>>>>> I have started feeling that no change = is the >>>>> >>>>>> best way out. >>>>> >>>>>> Nat >>>>> >>>>>> [1] If instead of saying "Token = endpoint - >>>>> >>>>>> used by the client to exchange an >>>>> >>>>>> authorization grant for an access = token, >>>>> >>>>>> typically with client authentication", = it >>>> were >>>>> >>>>>> saying "Token endpoint - used by the >>>> client to >>>>> >>>>>> exchange an authorization grant for = tokens, >>>>> >>>>>> typically with client authentication", >>>> then it >>>>> >>>>>> would have been OK. It is an expansion = of the >>>>> >>>>>> capability rather than changing the >>>> semantics. >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> 2014-07-23 13:39 GMT-04:00 Mike Jones >>>>> >>>>>> >>>> >>>>>> >: >>>>> >>>>>> >>>>> >>>>>> You need the alternative = response_type >>>>> >>>>>> value ("code_for_id_token" in the = A4C >>>>> >>>>>> draft) to tell the Authorization >>>> Server to >>>>> >>>>>> return a code to be used with the = new >>>>> >>>>>> grant type, rather than one to use = with >>>>> >>>>>> the "authorization_code" grant = type >>>> (which >>>>> >>>>>> is what response_type=3Dcode = does). >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> *From:*OAuth >>>>> >>>>>> [mailto:oauth-bounces@ietf.org >>>>> >>>>>> ] = *On >>>>> >>>>>> Behalf Of *John Bradley >>>>> >>>>>> *Sent:* Wednesday, July 23, 2014 = 10:33 AM >>>>> >>>>>> *To:* torsten@lodderstedt.net >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> *Cc:* oauth@ietf.org >>>> >>>>> >>>>>> *Subject:* Re: [OAUTH-WG] New = Version >>>>> >>>>>> Notification for >>>>> >>>>>> = draft-hunt-oauth-v2-user-a4c-05.txt >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> If we use the token endpoint then = a new >>>>> >>>>>> grant_type is the best way. >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> It sort of overloads code, but = that is >>>>> >>>>>> better than messing with >>>> response_type for >>>>> >>>>>> the authorization endpoint to = change the >>>>> >>>>>> response from the token_endpoint. >>>> That is >>>>> >>>>>> in my opinion a champion bad idea. >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> In discussions developing Connect = we >>>>> >>>>>> decided not to open this can of = worms >>>>> >>>>>> because no good would come of it. >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> The token_endpoint returns a = access >>>> token. >>>>> >>>>>> Nothing requires scope to be = associates >>>>> >>>>>> with the token. >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> That is the best solution. No = change >>>>> >>>>>> required. Better interoperability = in my >>>>> >>>>>> opinion. >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> Still on my way to TO, getting in = later >>>>> >>>>>> today. >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> John B. >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> Sent from my iPhone >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> On Jul 23, 2014, at 12:15 PM, >>>>> >>>>>> torsten@lodderstedt.net >>>>> >>>>>> = wrote: >>>>> >>>>>> >>>>> >>>>>> The "response type" of the = token >>>>> >>>>>> endpoint is controlled by the >>>> value of >>>>> >>>>>> the parameter "grant_type". So = there >>>>> >>>>>> is no need to introduce a new >>>> parameter. >>>>> >>>>>> >>>>> >>>>>> wrt to a potential = "no_access_token" >>>>> >>>>>> grant type. I do not consider = this a >>>>> >>>>>> good idea as it changes the = semantics >>>>> >>>>>> of the token endpoint (as = already >>>>> >>>>>> pointed out by Thomas). This = endpoint >>>>> >>>>>> ALWAYS responds with an access = token >>>>> >>>>>> to any grant type. I therefore = would >>>>> >>>>>> prefer to use another endpoint >>>> for the >>>>> >>>>>> intended purpose. >>>>> >>>>>> >>>>> >>>>>> regards, >>>>> >>>>>> Torsten. >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> Am 23.07.2014 13:04, schrieb = Nat >>>>> Sakimura: >>>>> >>>>>> >>>>> >>>>>> IMHO, changing the = semantics of >>>>> >>>>>> "response_type" @ authz = endpoint >>>>> >>>>>> this way is not a good = thing. >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> Instead, defining a new = parameter >>>>> >>>>>> "response_type" @ token = endpoint, >>>>> >>>>>> as I described in my = previous >>>>> >>>>>> message, >>>>> >>>>>> >>>>> >>>>>> probably is better. At = least, it >>>>> >>>>>> does not change the = semantics of >>>>> >>>>>> the parameters of RFC6749. >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> Nat >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> 2014-07-23 12:48 GMT-04:00 = Thomas >>>>> >>>>>> Broyer >>>> >>>>>> = >: >>>>> >>>>>> >>>>> >>>>>> No, I mean = response_type=3Dnone and >>>>> >>>>>> response_type=3Did_token = don't >>>>> >>>>>> generate a code or access >>>> token so >>>>> >>>>>> you don't use the Token = Endpoint >>>>> >>>>>> (which is not the same as = the >>>>> >>>>>> Authentication Endpoint = BTW). >>>>> >>>>>> >>>>> >>>>>> With >>>>> >>>>>> = response_type=3Dcode_for_id_token, >>>>> >>>>>> you get a code and = exchange >>>> it for >>>>> >>>>>> an id_token only, rather = than an >>>>> >>>>>> access_token, so you're = changing >>>>> >>>>>> the semantics of the Token >>>> Endpoint. >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> I'm not saying it's a bad = thing, >>>>> >>>>>> just that you can't really >>>> compare >>>>> >>>>>> none and id_token with >>>>> >>>>>> code_for_id_token. >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> On Wed, Jul 23, 2014 at = 6:45 PM, >>>>> >>>>>> Richer, Justin P. >>>>> >>>>>> >>>> >>>>>> = > >>>> wrote: >>>>> >>>>>> >>>>> >>>>>> It's only "not using the = token >>>>> >>>>>> endpoint" because the = token >>>>> >>>>>> endpoint copy-pasted and = renamed >>>>> >>>>>> the authentication = endpoint. >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> -- Justin >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> On Jul 23, 2014, at 9:30 = AM, >>>>> >>>>>> Thomas Broyer = >>>> >>>>>> = > >>>> wrote: >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> Except that these are = about not >>>>> >>>>>> using the Token Endpoint = at all, >>>>> >>>>>> whereas the current = proposal is >>>>> >>>>>> about the Token Endpoint = not >>>>> >>>>>> returning an access_token >>>> field in >>>>> >>>>>> the JSON. >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> On Wed, Jul 23, 2014 at = 4:26 PM, >>>>> >>>>>> Mike Jones >>>>> >>>>>> = >>>> >>>>>> >>>>> > >>>>> >>>>>> wrote: >>>>> >>>>>> >>>>> >>>>>> The response_type "none" = is >>>>> >>>>>> already used in practice, = which >>>>> >>>>>> returns no access token. = It was >>>>> >>>>>> accepted by the designated >>>> experts >>>>> >>>>>> and registered in the IANA = OAuth >>>>> >>>>>> Authorization Endpoint = Response >>>>> >>>>>> Types registry at >>>>> >>>>>> >>>>>=20 >>>> = http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#endp= oint >>>>> >>>>>> >>>>>=20 >>>> = . >>>>> >>>>>> The registered "id_token" >>>> response >>>>> >>>>>> type also returns no = access >>>> token. >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> So I think the question of >>>> whether >>>>> >>>>>> response types that result = in no >>>>> >>>>>> access token being = returned are >>>>> >>>>>> acceptable within OAuth = 2.0 is >>>>> >>>>>> already settled, as a = practical >>>>> >>>>>> matter. Lots of OAuth >>>>> >>>>>> implementations are = already using >>>>> >>>>>> such response types. >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> -- Mike >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> *From:*OAuth >>>>> >>>>>> = [mailto:oauth-bounces@ietf.org >>>>> >>>>>> = ] >>>>> >>>>>> *On Behalf Of *Phil Hunt >>>>> >>>>>> *Sent:* Wednesday, July = 23, 2014 >>>>> >>>>>> 7:09 AM >>>>> >>>>>> *To:* Nat Sakimura >>>>> >>>>>> *Cc:* >>>> >>>>>> > >>>>> >>>>>> *Subject:* Re: [OAUTH-WG] = New >>>>> >>>>>> Version Notification for >>>>> >>>>>> >>>> draft-hunt-oauth-v2-user-a4c-05.txt >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> Yes. This is why it has to = be >>>>> >>>>>> discussed in the IETF. >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> Phil >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> @independentid >>>>> >>>>>> >>>>> >>>>>> www.independentid.com >>>>> >>>>>> = >>>>> >>>>>> >>>>> >>>>>> phil.hunt@oracle.com >>>>> >>>>>> = >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> On Jul 23, 2014, at 9:43 = AM, Nat >>>>> >>>>>> Sakimura = >>>> >>>>>> = > >>>> wrote: >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> Reading back the RFC6749, = I >>>> am not >>>>> >>>>>> sure if there is a good = way of >>>>> >>>>>> suppressing access token = from the >>>>> >>>>>> response and still be = OAuth. It >>>>> >>>>>> will break whole bunch of >>>> implicit >>>>> >>>>>> definitions like: >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> authorization server >>>>> >>>>>> The server issuing = access >>>>> >>>>>> tokens to the client after >>>>> >>>>>> successfully >>>>> >>>>>> authenticating the = resource >>>>> >>>>>> owner and obtaining >>>> authorization. >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> After all, OAuth is all = about >>>>> >>>>>> issuing access tokens. >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> Also, I take back my = statement on >>>>> >>>>>> the grant type in my = previous >>>> mail. >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> The definition of grant = and >>>>> >>>>>> grant_type are = respectively: >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> grant >>>>> >>>>>> >>>>> >>>>>> credential = representing the >>>>> >>>>>> resource owner's = authorization >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> grant_type >>>>> >>>>>> >>>>> >>>>>> (string representing = the) >>>> type >>>>> >>>>>> of grant sent to the token >>>>> >>>>>> endpoint to obtain the = access >>>> token >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> Thus, the grant sent to = the token >>>>> >>>>>> endpoint in this case is = still >>>>> >>>>>> 'code'. >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> Response type on the other >>>> hand is >>>>> >>>>>> not so well defined in = RFC6749, >>>>> >>>>>> but it seems it is = representing >>>>> >>>>>> what is to be returned = from the >>>>> >>>>>> authorization endpoint. To >>>> express >>>>> >>>>>> what is to be returned = from token >>>>> >>>>>> endpoint, perhaps defining = a new >>>>> >>>>>> parameter to the token = endpoint, >>>>> >>>>>> which is a parallel to the >>>>> >>>>>> response_type to the >>>> Authorization >>>>> >>>>>> Endpoint seems to be a = more >>>>> >>>>>> symmetric way, though I am = not >>>>> >>>>>> sure at all if that is = going >>>> to be >>>>> >>>>>> OAuth any more. One = straw-man is >>>>> >>>>>> to define a new parameter = called >>>>> >>>>>> response_type to the token >>>>> >>>>>> endpoint such as: >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> response_type >>>>> >>>>>> >>>>> >>>>>> OPTIONAL. A string >>>>> >>>>>> representing what is to be >>>>> >>>>>> returned from the token = endpoint. >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> Then define the behavior = of the >>>>> >>>>>> endpoint according to the = values >>>>> >>>>>> as the parallel to the >>>>> >>>>>> multi-response type spec. >>>>> >>>>>> >>>>> >>>>>> >>>>> http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> Nat >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> 2014-07-23 7:21 GMT-04:00 = Phil >>>>> >>>>>> Hunt >>>> >>>>>> = >: >>>>> >>>>>> >>>>> >>>>>> The draft is very clear. >>>>> >>>>>> >>>>> >>>>>> Phil >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> On Jul 23, 2014, at 0:46, = Nat >>>>> >>>>>> Sakimura = >>>> >>>>>> = > >>>> wrote: >>>>> >>>>>> >>>>> >>>>>> The new grant type = that I was >>>>> >>>>>> talking about was >>>>> >>>>>> >>>>> >>>>>> >>>>> "authorization_code_but_do_not_return_access_nor_refresh_token", >>>>> >>>>>> so to speak. >>>>> >>>>>> >>>>> >>>>>> It does not return = anything >>>>> >>>>>> per se, but an = extension can >>>>> >>>>>> define something on = top >>>> of it. >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> Then, OIDC can define = a >>>>> >>>>>> binding to it so that = the >>>>> >>>>>> binding only returns = ID >>>> Token. >>>>> >>>>>> >>>>> >>>>>> This binding work = should be >>>>> >>>>>> done in OIDF. Should = there be >>>>> >>>>>> such a grant type, >>>>> >>>>>> >>>>> >>>>>> it will be an = extremely short >>>>> >>>>>> spec. >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> At the same time, if = any >>>> other >>>>> >>>>>> specification wanted = to >>>> define >>>>> >>>>>> >>>>> >>>>>> other type of tokens = and have >>>>> >>>>>> it returned from the = token >>>>> >>>>>> endpoint, >>>>> >>>>>> >>>>> >>>>>> it can also use this >>>> grant type. >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> If what you want is to = define >>>>> >>>>>> a new grant type that = returns >>>>> >>>>>> ID Token only, >>>>> >>>>>> >>>>> >>>>>> then, I am with = Justin. Since >>>>> >>>>>> "other response than = ID >>>> Token" >>>>> >>>>>> is only >>>>> >>>>>> >>>>> >>>>>> theoretical, this is a = more >>>>> >>>>>> plausible way forward, = I >>>>> suppose. >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> Nat >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> 2014-07-22 14:30 = GMT-04:00 >>>>> >>>>>> Justin Richer >>>> >>>> >>>>>> = >: >>>>> >>>>>> >>>>> >>>>>> So the draft would = literally >>>>> >>>>>> turn into: >>>>> >>>>>> >>>>> >>>>>> "The a4c response type = and >>>>> >>>>>> grant type return an = id_token >>>>> >>>>>> from the token = endpoint with >>>>> >>>>>> no access token. All >>>>> >>>>>> parameters and values = are >>>>> >>>>>> defined in OIDC." >>>>> >>>>>> >>>>> >>>>>> Seems like the perfect = mini >>>>> >>>>>> extension draft for = OIDF >>>> to do. >>>>> >>>>>> >>>>> >>>>>> --Justin >>>>> >>>>>> >>>>> >>>>>> /sent from my phone/ >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> On Jul 22, 2014 10:29 = AM, Nat >>>>> >>>>>> Sakimura = >>>> >>>>>> = > >>>>> >>>>>> wrote: >>>>> >>>>>> > >>>>> >>>>>> > What about just = defining a >>>>> >>>>>> new grant type in this = WG? >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > 2014-07-22 12:56 = GMT-04:00 >>>>> >>>>>> Phil Hunt >>>>> >>>>>> >>>> >>>>>> >>>> >: >>>>> >>>>>> >> >>>>> >>>>>> >> That would be nice. >>>> However >>>>> >>>>>> oidc still needs the = new >>>> grant >>>>> >>>>>> type in order to >>>> implement the >>>>> >>>>>> same flow. >>>>> >>>>>> >> >>>>> >>>>>> >> Phil >>>>> >>>>>> >> >>>>> >>>>>> >> On Jul 22, 2014, at = 11:35, >>>>> >>>>>> Nat Sakimura >>>>> >>>>>> >>>> >>>>>> = > >>>>> >>>>>> wrote: >>>>> >>>>>> >> >>>>> >>>>>> >>> +1 to Justin. >>>>> >>>>>> >>> >>>>> >>>>>> >>> >>>>> >>>>>> >>> 2014-07-22 9:54 = GMT-04:00 >>>>> >>>>>> Richer, Justin P. >>>>> >>>>>> >>>> >>>>>> = >: >>>>> >>>>>> >>>> >>>>> >>>>>> >>>> Errors like these >>>> make it >>>>> >>>>>> clear to me that it = would >>>> make >>>>> >>>>>> much more sense to = develop >>>>> >>>>>> this document in the = OpenID >>>>> >>>>>> Foundation. It should = be >>>>> >>>>>> something that = directly >>>>> >>>>>> references OpenID = Connect >>>> Core >>>>> >>>>>> for all of these terms >>>> instead >>>>> >>>>>> of redefining them. = It's >>>> doing >>>>> >>>>>> authentication, which = is >>>>> >>>>>> fundamentally what = OpenID >>>>> >>>>>> Connect does on top of = OAuth, >>>>> >>>>>> and I don't see a good >>>>> >>>>>> argument for doing = this work >>>>> >>>>>> in this working group. >>>>> >>>>>> >>>> >>>>> >>>>>> >>>> -- Justin >>>>> >>>>>> >>>> >>>>> >>>>>> >>>> On Jul 22, 2014, = at 4:30 >>>>> >>>>>> AM, Thomas Broyer >>>>> >>>>>> >>>> >>>>>> = > >>>>> >>>>>> wrote: >>>>> >>>>>> >>>> >>>>> >>>>>> >>>>> >>>>> >>>>>> >>>>> >>>>> >>>>>> >>>>> >>>>> >>>>>> >>>>> On Mon, Jul 21, = 2014 at >>>>> >>>>>> 11:52 PM, Mike Jones >>>>> >>>>>> = >>>> >>>>>> >>>>> > >>>>> >>>>>> wrote: >>>>> >>>>>> >>>>>> >>>>> >>>>>> >>>>>> Thanks for your >>>> review, >>>>> >>>>>> Thomas. The = "prompt=3Dconsent" >>>>> >>>>>> definition being = missing >>>> is an >>>>> >>>>>> editorial error. It >>>> should be: >>>>> >>>>>> >>>>>> >>>>> >>>>>> >>>>>> >>>>> >>>>>> >>>>>> >>>>> >>>>>> >>>>>> consent >>>>> >>>>>> >>>>>> >>>>> >>>>>> >>>>>> The = Authorization >>>>> >>>>>> Server SHOULD prompt = the >>>>> >>>>>> End-User for consent = before >>>>> >>>>>> returning information = to the >>>>> >>>>>> Client. If it cannot = obtain >>>>> >>>>>> consent, it MUST = return an >>>>> >>>>>> error, typically >>>>> consent_required. >>>>> >>>>>> >>>>>> >>>>> >>>>>> >>>>>> >>>>> >>>>>> >>>>>> >>>>> >>>>>> >>>>>> I'll plan to = add it in >>>>> >>>>>> the next draft. >>>>> >>>>>> >>>>> >>>>> >>>>>> >>>>> >>>>> >>>>>> >>>>> It looks like = the >>>>> >>>>>> consent_required error = needs >>>>> >>>>>> to be defined too, and = you >>>>> >>>>>> might have forgotten = to also >>>>> >>>>>> import >>>>> >>>>>> = account_selection_required >>>>> >>>>>> from OpenID Connect. >>>>> >>>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>> >>>>>> >>>>>> >>>>> >>>>>> >>>>>> >>>>> >>>>>> >>>>>> I agree that >>>> there's no >>>>> >>>>>> difference between a = response >>>>> >>>>>> with multiple "amr" = values >>>>> >>>>>> that includes "mfa" = and one >>>>> >>>>>> that doesn't. Unless = a clear >>>>> >>>>>> use case for why "mfa" = is >>>>> >>>>>> needed can be = identified, we >>>>> >>>>>> can delete it in the = next >>>> draft. >>>>> >>>>>> >>>>> >>>>> >>>>>> >>>>> >>>>> >>>>>> >>>>> Thanks. >>>>> >>>>>> >>>>> >>>>> >>>>>> >>>>> How about "pwd" = then? I >>>>> >>>>>> fully understand that = I >>>> should >>>>> >>>>>> return "pwd" if the = user >>>>> >>>>>> authenticated using a >>>>> >>>>>> password, but what = "the >>>>> >>>>>> service if a client = secret is >>>>> >>>>>> used" means in the = definition >>>>> >>>>>> for the "pwd" value? >>>>> >>>>>> >>>>> >>>>> >>>>>> >>>>> (Nota: I know = you're at >>>>> >>>>>> IETF-90, I'm ready to = wait >>>>> >>>>>> 'til you come back ;-) = ) >>>>> >>>>>> >>>>> >>>>> >>>>>> >>>>> -- >>>>> >>>>>> >>>>> Thomas Broyer >>>>> >>>>>> >>>>> = /t=C9=94.ma.b=CA=81wa.je/ >>>>> >>>>>> >>>>> >>>>> >>>>>> >>>>> >>>>> >>>>>> >>>>> _______________________________________________ >>>>> >>>>>> >>>>> 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 >>>>> >>>>>> >>>> >>>>> >>>>>> >>> >>>>> >>>>>> >>> >>>>> >>>>>> >>> >>>>> >>>>>> >>> -- >>>>> >>>>>> >>> Nat Sakimura = (=3Dnat) >>>>> >>>>>> >>> Chairman, OpenID >>>> Foundation >>>>> >>>>>> >>> = http://nat.sakimura.org/ >>>>> >>>>>> >>> @_nat_en >>>>> >>>>>> >>> >>>>> >>>>>> >>> >>>>> >>>>>> >>>>> _______________________________________________ >>>>> >>>>>> >>> OAuth mailing list >>>>> >>>>>> >>> OAuth@ietf.org >>>>> >>>>>> = >>>>> >>>>>> >>> >>>>> >>>>>> >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > -- >>>>> >>>>>> > Nat Sakimura (=3Dnat) >>>>> >>>>>> > Chairman, OpenID = Foundation >>>>> >>>>>> > = http://nat.sakimura.org/ >>>>> >>>>>> > @_nat_en >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> -- >>>>> >>>>>> Nat Sakimura (=3Dnat) >>>>> >>>>>> >>>>> >>>>>> Chairman, OpenID = Foundation >>>>> >>>>>> = http://nat.sakimura.org/ >>>>> >>>>>> @_nat_en >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> -- >>>>> >>>>>> Nat Sakimura (=3Dnat) >>>>> >>>>>> >>>>> >>>>>> Chairman, OpenID = Foundation >>>>> >>>>>> http://nat.sakimura.org/ >>>>> >>>>>> @_nat_en >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> _______________________________________________ >>>>> >>>>>> 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 >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> -- >>>>> >>>>>> Thomas Broyer >>>>> >>>>>> /t=C9=94.ma.b=CA=81wa.je/ >>>>> >>>>>> >>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> _______________________________________________ >>>>> >>>>>> OAuth mailing list >>>>> >>>>>> OAuth@ietf.org >>>>> >>>>> >>>>>> >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> -- >>>>> >>>>>> Nat Sakimura (=3Dnat) >>>>> >>>>>> >>>>> >>>>>> Chairman, OpenID = Foundation >>>>> >>>>>> http://nat.sakimura.org/ >>>>> >>>>>> @_nat_en >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> _______________________________________________ >>>>> >>>>>> >>>>> >>>>>> 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 >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> -- >>>>> >>>>>> Nat Sakimura (=3Dnat) >>>>> >>>>>> Chairman, OpenID Foundation >>>>> >>>>>> http://nat.sakimura.org/ >>>>> >>>>>> @_nat_en >>>>> >>>>>> >>>>> >>>>>> >>>> _______________________________________________ >>>>> >>>>>> >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 >=20 From nobody Tue Oct 14 02:12:35 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 793D11A6FDB for ; Tue, 14 Oct 2014 02:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.308 X-Spam-Level: **** X-Spam-Status: No, score=4.308 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FSL_HELO_BARE_IP_2=1, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, SPF_PASS=-0.001] autolearn=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 seyu8pOEfXYL for ; Tue, 14 Oct 2014 02:12:31 -0700 (PDT) Received: from nrifs04.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id E796B1A6FF7 for ; Tue, 14 Oct 2014 02:12:30 -0700 (PDT) Received: from nriea03.index.or.jp (unknown [172.19.246.38]) by nrifs04.index.or.jp (Postfix) with SMTP id 6F759472EE0; Tue, 14 Oct 2014 18:12:29 +0900 (JST) Received: from nrims00a.nri.co.jp ([192.50.135.11]) by nriea03.index.or.jp (unknown) with ESMTP id s9E9CTi8030350; Tue, 14 Oct 2014 18:12:29 +0900 Received: from nrims00a.nri.co.jp (localhost.localdomain [127.0.0.1]) by nrims00a.nri.co.jp (Switch-3.3.3/Switch-3.3.3) with ESMTP id s9E9CSNs009321; Tue, 14 Oct 2014 18:12:29 +0900 Received: (from mailnull@localhost) by nrims00a.nri.co.jp (Switch-3.3.3/Switch-3.3.0/Submit) id s9E9CSON009317; Tue, 14 Oct 2014 18:12:28 +0900 X-Authentication-Warning: nrims00a.nri.co.jp: mailnull set sender to n-sakimura@nri.co.jp using -f Received: from nrizmf11a.index.or.jp ([172.100.25.17]) by nrims00a.nri.co.jp (Switch-3.3.3/Switch-3.3.3) with ESMTP id s9E9CSk6009313; Tue, 14 Oct 2014 18:12:28 +0900 Received: from 127.0.0.1 (127.0.0.1) by m-FILTER with ESMTP; Tue, 14 Oct 2014 18:12:28 +0900 Date: Tue, 14 Oct 2014 18:12:18 +0900 From: Nat Sakimura To: Eduardo Gueiros Message-Id: <20141014181218.9fc331f5c016a2a6fdd9b67a@nri.co.jp> In-Reply-To: <5406C9EB.1020701@jive.com> References: <5406C9EB.1020701@jive.com> X-Mailer: Sylpheed 3.4.2 (GTK+ 2.10.14; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-MailAdviser: Ver1.5.1 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/bVy31G8nSjIj1payUdklcmHgy8U Cc: oauth@ietf.org, draft-ietf-oauth-spop@tools.ietf.org Subject: Re: [OAUTH-WG] Review draft-ietf-oauth-spop-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 09:12:33 -0000 Hi Eduardo, I have accepted all the "Suggestions" in the forthcoming version. You can see my private editing copy at https://bitbucket.org/Nat/oauth-spop/commits/f0f8599 to see how it has been incorporated. Best, Nat On Wed, 03 Sep 2014 01:57:31 -0600 Eduardo Gueiros wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Review of draft-ietf-oauth-spop-00 > > Gentleman, here are some notes on the OAuth SPOP Draft. > > > Review Summary > > A few grammar errors, no major flaws, some suggestions that could > possibly make some passages clearer. Some questions as well. > Also, providing a flow diagram would help clarify some of the > interactions. > > Abstract > > > The OAuth 2.0 public client utilizing authorization code grant is > > susceptible to the code interception attack. > > Suggestion for clearer reading: > OAuth 2.0 public clients utilizing Authorization Code Grant (RFC 6749 > - - 4.1) are susceptible to an interception attack. > > Introduction > > Suggestion for clearer reading: > > Public clients in OAuth 2.0 [RFC6749] is susceptible to the "code" > > interception attack. The "code" interception attack is an attack > > that a malicious client intercepts the "code" returned from the > > authorization endpoint and uses it to obtain the access token. > > Public clients utilizing OAuth 2.0 are susceptible to authorization > code interception attack. A malicious client intercepts the > authorization code returned from the authorization endpoint and uses > it to obtain the access token. > > Suggestion for clearer reading: > > This is especially true on some smartphone platform in which the > "code" is > > returned to a redirect URI with a custom scheme as there can be > > multiple apps that can register the same scheme. > > This is especially true on smartphones applications where the > authorization code can be returned > through custom URL Schemes where the same scheme can be registered by > multiple applications. > > Insert article before $B!F(Bdynamic$B!G(B > > To mitigate this attack, this extension utilizes dynamically > > created cryptographically random key called 'code verifier'. > > To mitigate this attack, this extension utilizes a dynamically created > cryptographically random key called 'code verifier'. > > Missing commas for context > > The code verifier is created for every authorization request and > > its transformed value called code challenge is sent to the > > authorization server to obtain the authorization code. > > The code verifier is created for every authorization request and its > transformed value, called code challenge, is sent to the authorization > server to obtain the authorization code. > > 2 Terminology > 2.1 > Question > Random String: What constitutes $B!F(Bbig enough entropy$B!G(B? Shouldn$B!G(Bt > minimum length be specified (e.g. 32 characters)? > > 3 Protocol > 3.1 > Question > This paragraph states that the client must, through some mechanism, > verify if the server supports this specification. Shouldn$B!G(Bt this > mechanism be part of OAuth and therefore have an specification > document on how to implement and perform the aforementioned > verification? > > Suggestion: Change MUST to SHOULD > > The client that wishes to use this specification MUST stop > > proceeding if the server does not support this extension. > > I think a client can use this mechanism to implement a more secure > transaction, but by verifying it, the client can be configured to > continue performing the regular authorization grant if it chooses so. > Hence, SHOULD instead of MUST. > > > 3.3 > Question > Goes with question on 2.1, why less than 128 bytes? > > Suggestion > > string of length less than 128 bytes > string of length no less than 128 bytes > > > Eduardo Gueiros > Software Developer | Jive.com > Jive Communications, Inc | egueiros at jive.com > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > Comment: GPGTools - https://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQEcBAEBCgAGBQJUBsnrAAoJEInLDRowktwYn6sH+wUGGCimGSRaSfy4LeN9ug9e > VN5R/N4eWhEKl5iydMZskeMovYsH4PhEP19m56mWGhRn53CxMB5dlHkTw56JX4mS > qnPu96Ot6HoCzzCVj8PtGyAZUwWFyd57Ff7uUuSQaVghhIfLXzggFfciiErJpV5H > wwQo+eFp98fx6uGEeCr4Olr6PsJ8Ajn5SnaCA/dPr7YWAUrnpSb55NCB4twtp4y6 > 36EqjcuvafudTEuYJOoGqYJppfpcZ+Da6uKZNRTahkN1ivv1C+PdNRWkfHbB47mu > IF4u3b6tDhiymPNFjCABZ6gB5ZbXmUbVrkhVKwJpf/87/fiaScGmZG+6rRZLP5s= > =XQSw > -----END PGP SIGNATURE----- > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth -- Nat Sakimura (n-sakimura@nri.co.jp) Nomura Research Institute, Ltd. $BK\%a!<%k$K4^$^$l$k>pJs$O5!L)>pJs$G$"$j!"08@h$K5-:\$5$l$F$$$kJ}$N$_$KAw?.(B $B$9$k$3$H$r0U?^$7$F$*$j$^$9!#0U?^$5$l$?pJs$N(B $B3+<(!"J#@=!":FG[I[$dE>Aw$J$I0l@Z$NMxMQ$,6X;_$5$l$F$$$^$9!#8m$C$FK\%a!<%k(B $B$rl9g$O!"?=$7Lu$4$6$$$^$;$s$,!"Aw?. X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FDE51A6FEF for ; Tue, 14 Oct 2014 02:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.308 X-Spam-Level: **** X-Spam-Status: No, score=4.308 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FSL_HELO_BARE_IP_2=1, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, SPF_PASS=-0.001] autolearn=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 w1AgMYv5SCmK for ; Tue, 14 Oct 2014 02:19:41 -0700 (PDT) Received: from nrifs03.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57D111A6FEC for ; Tue, 14 Oct 2014 02:19:41 -0700 (PDT) Received: from nriea05.index.or.jp (unknown [172.19.246.40]) by nrifs03.index.or.jp (Postfix) with SMTP id D98EA17EA43; Tue, 14 Oct 2014 18:19:40 +0900 (JST) Received: from nrims00a.nri.co.jp ([192.50.135.11]) by nriea05.index.or.jp (unknown) with ESMTP id s9E9Je6P015370; Tue, 14 Oct 2014 18:19:40 +0900 Received: from nrims00a.nri.co.jp (localhost.localdomain [127.0.0.1]) by nrims00a.nri.co.jp (Switch-3.3.3/Switch-3.3.3) with ESMTP id s9E9JeIe026813; Tue, 14 Oct 2014 18:19:40 +0900 Received: (from mailnull@localhost) by nrims00a.nri.co.jp (Switch-3.3.3/Switch-3.3.0/Submit) id s9E9Jekn026812; Tue, 14 Oct 2014 18:19:40 +0900 X-Authentication-Warning: nrims00a.nri.co.jp: mailnull set sender to n-sakimura@nri.co.jp using -f Received: from nrizmf11a.index.or.jp ([172.100.25.17]) by nrims00a.nri.co.jp (Switch-3.3.3/Switch-3.3.3) with ESMTP id s9E9JeHm026808; Tue, 14 Oct 2014 18:19:40 +0900 Received: from 127.0.0.1 (127.0.0.1) by m-FILTER with ESMTP; Tue, 14 Oct 2014 18:19:40 +0900 Date: Tue, 14 Oct 2014 18:19:31 +0900 From: Nat Sakimura To: "oauth@ietf.org" Message-Id: <20141014181931.2011201bddc3f13e114ff42c@nri.co.jp> In-Reply-To: References: <54002809.2020101@gmx.net> X-Mailer: Sylpheed 3.4.2 (GTK+ 2.10.14; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-MailAdviser: Ver1.5.1 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/VNLV3WCoQE6c3_06nHrnpDd5hAc Subject: [OAUTH-WG] Define a server capaiblity discovery parameter? (was: Re: OAuth SPOP Detailed Review) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 09:19:43 -0000 In his mail, Hannes suggested to include more explicit reference to a feature in the OpenID Connect Discovery spec in section 3.1. My response to it was that we could define a parameter here and ask the implementers to implement it. Questions remains whether we want to define it here or leave it to be out of scope. So, my questions are: (1) Do we want it? (y or n) (2) if y, then adding the following text at the end of 3.1 be adequate? When the server supports OpenID Connect Discovery 1.0, the server MUST advertise its capability with a parameter oauth_spop_supported_alg. The value of it is a JSON array of JSON strings representing "alg" (Algorithm) Header Parameter Values for JWS as defined in JSON Web Algorithms. Nat On Wed, 3 Sep 2014 02:28:57 +0900 Nat Sakimura wrote: > Hi. Thanks for the detailed comments. > > Here are the responses to the questions raised in [1] > > [1] > http://www.tschofenig.priv.at/oauth/draft-ietf-oauth-spop-00-hannes.doc > > 3.1 [Question: Would it make sense to provide some information also > in the > > Dynamic Client Registration specification? I am a bit unhappy about > > not specifying at least one mechanism for learning this information > > since it is important for the overall security -- to avoid > > downgrading attacks.] > > > I would have included it if OAuth has defined a discovery document. n > fact, it may be a good starting point to discuss whether we should > have a discovery document for OAuth. > > If the client does the per client registration, then it will not be a > public client so spop would not be needed. > The clients as a class may register itself, but then each client > instance would not know if the server knows that it is using spop, > and assuming it without verifying is not very safe. > > 3.1 [Hannes: Can we make a more explicit reference to a feature in the > > OpenID Connect Discovery specification?] > > > It will be an extension to section 3 of OpenID Connect Discovery. This > specification may define a JSON name for such a parameter. Then, one > can include it in the metadata. > > A candidate for such name would be: > > oauth_spop_supported_alg: > > and the value would be the strings representing supported algorithms. > It could be drawn from JWA algs. > > A simpler alternative would be: > > oauth_spop_support: > > and the value would be true or false. > > However, we have no good place to advertise them as of now. > > 3.2 [Hannes: Do we really need this flexibility here?] > > > It is there as an extension point. John has a draft that uses > aymmetric algo. An early draft had HMAC as well. > > We could however drop it. I suppose we can add other algorithms later > without breaking this one. > > [Hannes: The term 'front channel' is not defined anywhere.] > > > Will define if this section survives. > > 3.7 [Hannes: Why is there a SHOULD rather than a MUST?] > > > The server may have other considerations before returning successful > response. > > 5. [Hannes: Which request channel are you talking about? There are two > > types of request channels here, namely the Access Token > > Request/Response and the Authorization Request / Response channel. > > What do you mean by adequately protected here? How likely is it > > that this can be accomplished? If it is rather unlikely then it > > would be better to define a different transformation algorithm!] > > > This is referring to the authorization request. > > On iOS as of the time of writing, not Jailbreaking seems to be > adequate. For Android, only presenting the intended browser as the > options to handle the request seems adequate. Similar considerations > would be there per platform. > > Note: Authors do think that using other algorithms is better. > However, it proved to be rather unpopular among the developers that > they were in touch with and believe that we do need to provide this > "no-transform" capability. > > For other "corrections", I am still working on to prepare comments as > word comments. > Most of editorial changes will be accepted. Some proposed technical > changes seems to be due to the clauses being unclear, so I will try > to propose a clarification rather than just accepting them. > > Best, > > Nat > > 2014-08-29 16:13 GMT+09:00 Hannes Tschofenig > : > > > > Hi John, Hi Nat, > > > > I went through the document in detail and suggest some changes > > (most of them editorial): > > http://www.tschofenig.priv.at/oauth/draft-ietf-oauth-spop-00-hannes.doc > > http://www.tschofenig.priv.at/oauth/draft-ietf-oauth-spop-00-hannes.pdf > > > > My main concern at the moment are some optional features in the spec > > that make it less interoperable, such as the feature discovery, and > > the transformation function. The latter might go away depending on > > your answer to my question raised at > > http://www.ietf.org/mail-archive/web/oauth/current/msg13354.html > > but the former requires some specification work. > > > > Ciao > > Hannes > > > > PS: I agree with James that the title of the document is a bit > > misleading when compared with the other work we are doing in the > > group. > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > -- > Nat Sakimura (=nat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en -- Nat Sakimura (n-sakimura@nri.co.jp) Nomura Research Institute, Ltd. $BK\%a!<%k$K4^$^$l$k>pJs$O5!L)>pJs$G$"$j!"08@h$K5-:\$5$l$F$$$kJ}$N$_$KAw?.(B $B$9$k$3$H$r0U?^$7$F$*$j$^$9!#0U?^$5$l$?pJs$N(B $B3+<(!"J#@=!":FG[I[$dE>Aw$J$I0l@Z$NMxMQ$,6X;_$5$l$F$$$^$9!#8m$C$FK\%a!<%k(B $B$rl9g$O!"?=$7Lu$4$6$$$^$;$s$,!"Aw?. X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 148CD1A6FEF for ; Tue, 14 Oct 2014 02:25:23 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UGX6i6V5pODR for ; Tue, 14 Oct 2014 02:25:16 -0700 (PDT) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A93E1A6FEC for ; Tue, 14 Oct 2014 02:25:15 -0700 (PDT) Received: by mail-la0-f52.google.com with SMTP id hz20so8002947lab.39 for ; Tue, 14 Oct 2014 02:25:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=AfppBjvC63but2x4UFH376C/5qFCbmzVevgrc2aFFDQ=; b=vf0xsH5KLxpuA3KY7TFOpwTbiZtztnNVZ80/HwJIdXMLNivBipL8W8xsccnYTMPkl8 3OmTOSXOjBOUssOaPgd5XB67a4utNnBWb59wVgtlKCDMqnupXOUgSnQzaj6FJS7qf+YB gvc8HNoIJv1yYZBLUDkXvDwVQau7UMI3015YfaGAJiTCr0Tg0osHyrMySIar9fUURdGh DW3lFWIF3qYhXnOPWZ1ycaJt875WK24bR6C3u/VSkovdgIYKmFkclp2wCyTXqzJTeXqk +tdvSsEQjQ07XyJnxjsIT0msmOBf9oXOYB8CP0bkSyVqGWWq56l6yijjlvaWwZXnMdoG 8LSg== X-Received: by 10.152.206.105 with SMTP id ln9mr4193298lac.8.1413278713421; Tue, 14 Oct 2014 02:25:13 -0700 (PDT) Received: from [10.36.226.2] ([80.169.137.63]) by mx.google.com with ESMTPSA id z1sm4592939lad.40.2014.10.14.02.25.11 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Oct 2014 02:25:12 -0700 (PDT) Message-ID: <543CEBF6.4090407@gmail.com> Date: Tue, 14 Oct 2014 10:25:10 +0100 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Phil Hunt References: <543BE1A1.6020902@gmail.com> <44A3CD9F-9E2E-4746-A5B1-47984BBE973C@oracle.com> <543C3510.7070201@gmail.com> <9C1B0B29-47AB-4057-96B4-BA18E116B5B1@oracle.com> In-Reply-To: <9C1B0B29-47AB-4057-96B4-BA18E116B5B1@oracle.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/500eHFO895a9-tTf3wA3QHvJzBI Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 09:25:23 -0000 Hi Phil, All, Thanks for your positive feedback and further comments below. My goal was really about trying to make a clear picture in my mind about what OIDC is with respect to OAuth2, and specifically supporting the point about OIDC not being just OAuth2. As such, the idea of a specific OIDC profile where no access token was used appealed to me but really in light of supporting the same point that OIDC being not just OAuth2. I understand it 'breaks' the clean OIDC OAuth2-based model. Hence I also tried to suggest that even though OIDC does return an access token, this token does not have to be a full-powered token that a client can use to access something else but a user profile endpoint (unless custom scopes are also used). So the access token is there but it's only usable in the OAuth2 world. I respect the effort done in the a4c draft - I'm just not sure really it has to be a separate effort (as opposed to it being an OIDC 'exception' light weight profile - can be simpler for users like me to have it all comprehended when it is a single family of docs) should the experts like yourself and others really like the idea of having a pure authentication flow supported. But I'll be watching with the interest how it all evolves now :-) Thanks, Sergey On 13/10/14 22:17, Phil Hunt wrote: > Sergey, > > Actually, I think your comments are fine. They add to the discussion on why A4C is distinct from OIDC’s larger IDP role in an OAuth style flow and why *both* are needed. > > Comments in line. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > On Oct 13, 2014, at 1:24 PM, Sergey Beryozkin wrote: > >> Hi Phil >> >> Thanks for the clarifications, >> On 13/10/14 20:18, Phil Hunt wrote: >>> The point to be made is if the client’s objective is to authenticate the User, the base 6749 spec does not guarantee this at all. >>> >>> It simply authorizes the client to access a resource and nothing more. >>> >>> It turns out that a significant part of the time authentication does occur, but the client does not have access to that information. Nor can it specifically request re-authentication. >>> >>> Further, if the client doesn’t wield the access token, its might not be proof that the token received was actually an authorization. >>> >>> OpenID gives you both authen information and authorization profile information (as a resource). >>> >> Yes, I experimented with it. >>> This thread was more about how to do just authentication ONLY. What are the requirements for a client to know a User *was* authenticated and when. While some flows of OpenID can achieve this, its not clear that it addresses all cases. Furhter there is discussion (as Justin mentions) that a flow that does not produce an access token is not an authorization flow and is not OAuth. I agree. >> Sure. >>> It an authentication flow and should be distinct IMHO. >>> >> I guess that is why the idea of having an OIDC profile dedicated to the authentication alone (no access token) which I believe was suggested here caught my attention. But then it is not OAuth2 and hence not OIDC. The chicken in the egg situation :-). As I said in the prev email, having an access token which is really restricted to the OIDC resource (profile) seems like a good compromise… > > [PH] We discussed this in Toronto and OIDC can’t do this and be compliant woith OAuth. It wouldn’t be OAuth. Someone also pointed out that the OAuth WG isn’t chartered to do authentication and that kind of killed the discussion leaving the issue hanging unresolved. > > If you look at draft 00 of the A4C draft you will note that I originally proposed it as a new end-point. My feeling it should NOT be an OAuth flow - because as Justin says, if you aren’t returning an access token, you aren’t doing OAuth. The issue is that the technical redirect flow for authentication and authorization share the same security risks and counter-measures. It would be good therefore to build “in-parallel” or “underneath” OAuth to define an authn flow. > > I would still recommend OIDC as a layer on top of OAuth that defines the standard way to get profile claims (the full OAuth style IDP functionality). > >> >>> That said, I am in the minority with this opinion and I acknowledge as being as such. >>> >> >> Sorry if I hijacked this thread and started the off-topic 'flow'...I guess my reasoning here is a bit all over the place, but I'm pretty sure now I see the big picture better >> >> Thanks, Sergey >> >>> Phil >>> >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>> >>> >>> >>> On Oct 13, 2014, at 7:28 AM, Sergey Beryozkin wrote: >>> >>>> On 13/10/14 15:17, Justin Richer wrote: >>>>> You certainly can do authentication without using an access token, but >>>>> then I would argue that's no longer OAuth. Basically you're making tofu >>>>> carob fudge. >>>> >>>> Right, the access token is there for a client to get to the UserInfo endpoint, as far as OIDC is concerned. What if the info in the id_token is sufficient ? >>>> I guess as far as a typical OAuth2 client is concerned, requesting "openid profile" only effectively gives one an access token that can only be used with the UserInfo endpoint. >>>> >>>> So yes, may be even though OIDC has an access token returned, unless other custom scopes are used, the access token would be pretty much of use in the OIDC context only if a client chooses to work with the UserInfo...I guess the id_token/at_hash is useful on its own >>>> >>>> >>>> Cheers, Sergey >>>> >>>>> >>>>> >>>>> -- Justin >>>>> >>>>> / Sent from my phone / >>>>> >>>>> >>>>> -------- Original message -------- >>>>> From: Sergey Beryozkin >>>>> Date:10/13/2014 9:00 AM (GMT-05:00) >>>>> To: Justin Richer , oauth@ietf.org >>>>> Cc: >>>>> Subject: Re: [OAUTH-WG] New Version Notification for >>>>> draft-hunt-oauth-v2-user-a4c-05.txt >>>>> >>>>> Hi Justin, >>>>> On 13/10/14 12:53, Justin Richer wrote: >>>>>> You are correct in that OAuth 2 and OpenID Connect are not the same >>>>>> thing, but your user is correct that OIDC adds a few pieces on top of >>>>>> OAuth to add authentication capabilities. OIDC was designed very >>>>>> explicitly to be compatible with vanilla OAuth, partially do that people >>>>>> would be able to deploy it on top of existing OAuth infrastructure and >>>>>> code. But the very fact that OIDC adds a few things on top of OAuth to >>>>>> give more functionality should be sufficient evidence that they're not >>>>>> equivalent. >>>>>> >>>>>> It's more proper to say that OpenID Connect is an extension and >>>>>> application of OAuth. One that provides an authentication and >>>>> identity API. >>>>>> >>>>> I agree and this is more or less how I answered. >>>>> >>>>> Though the 'borders' can be blurred, one can claim that if a user >>>>> actually logs on into a confidential OAuth2 client web application which >>>>> redirects this user to AS requesting a code with some scopes such as "a >>>>> b" then when it uses "a b openid profile" it is basically does a pure >>>>> OAuth2 code flow where the client requests 'a b' plus also a scope >>>>> allowing it later to query the identity system on behalf of a user. >>>>> >>>>> I like the "The extension and application of OAuth2" characteristic of >>>>> OIDC. IMHO it's becoming more obvious if OIDC is used to support SSO >>>>> into non-OAuth2 servers, when it is the case then there's no 'feeling' >>>>> that OIDC is just a case of the confidential client adding the extra >>>>> scopes and getting the extra (authentication) info back. A standalone >>>>> OIDC RP protecting such non OAuth2 servers is very much about the >>>>> authentication/identity. >>>>> >>>>> I also thought that having some OID profile (as opposed updating OAuth2 >>>>> to support no access tokens) where no access but only id token was >>>>> returned (as suggested in this thread) would probably make sense too. >>>>> >>>>>> The way I like to explain it (which I stole from someone else) is that >>>>>> OAuth is like chocolate and authentication is like fudge. They are not >>>>>> the same thing. You can make chocolate into fudge out you can make it >>>>>> into something else or you can just have it on its own. You can make >>>>>> fudge with chocolate or you can make it with peanut butter or you can >>>>>> make it with potatoes if you want to, but it needs a couple ingredients >>>>>> and a very common one is chocolate. OpenID Connect is a recipe for >>>>>> chocolate fudge that a lot of people like. And it makes my fudge >>>>>> compatible with your fudge, which is where the metaphor breaks down. :-) >>>>>> >>>>> Thanks for sharing this colourful explanation :-). Perhaps I should >>>>> borrow it :-), >>>>> Cheers, Sergey >>>>> >>>>> >>>>>> >>>>>> -- Justin >>>>>> >>>>>> / Sent from my phone / >>>>>> >>>>>> >>>>>> -------- Original message -------- >>>>>> From: Sergey Beryozkin >>>>>> Date:10/13/2014 6:33 AM (GMT-05:00) >>>>>> To: oauth@ietf.org >>>>>> Cc: >>>>>> Subject: Re: [OAUTH-WG] New Version Notification for >>>>>> draft-hunt-oauth-v2-user-a4c-05.txt >>>>>> >>>>>> Hi >>>>>> >>>>>> We've had a user asserting that "OAuth2 == OpenidConnect", referring to >>>>>> the fact that the 'only' thing OIC adds on top of the authorization code >>>>>> flow is the client specifying few extra scopes like 'openid' and >>>>>> 'profile' and the authorization service returning an extra property, the >>>>>> id_token which can be sufficient in order to get the authenticated >>>>>> user's info. >>>>>> >>>>>> My understanding "OAuth2 != OpenidConnect", the latter utilizes the >>>>>> former and is an authentication mechanism which is not what OAuth2 is >>>>>> (may be except for the client credentials). But I don't feel like it is >>>>>> a convincing enough argument. >>>>>> >>>>>> I thought this thread was relevant, sorry if not, would have no problems >>>>>> starting a new one. >>>>>> >>>>>> Basically, I wonder what is the proper line of argument for a position >>>>>> such as "OAuth2 != OpenidConnect" and also what was the action to the >>>>>> list of options suggested by John below. Is having an OID profile where >>>>>> no access token is returned would be the cleanest action as far as >>>>>> breaking the ambiguity/confusion is concerned ? >>>>>> >>>>>> Cheers, Sergey >>>>>> >>>>>> On 24/07/14 15:25, John Bradley wrote: >>>>>> > I am not against discussion in the WG. >>>>>> > >>>>>> > I happen to agree with Phil's fundamental premise that some developers >>>>>> > are using OAuth in a insecure way to do authentication. >>>>>> > >>>>>> > That raises the question of how to best educate them, and or address >>>>>> > technical barriers. >>>>>> > >>>>>> > It is on the second point that people's opinions seem to divide. >>>>>> > >>>>>> > Some people thing that if we have a OAuth flow that eliminates the >>>>>> > access token (primarily to avoid asking for consent as I >>>>> understand it) >>>>>> > and just return a id_token from the token endpoint that can be >>>>> done in a >>>>>> > spec short enough to het people to read. The subtext of this is that >>>>>> > the Connect specification is too large that it scare people, and they >>>>>> > don't find the spec in the first place because it is not a RFC. >>>>>> > >>>>>> > An other common possession is that if you don't want to prompt the >>>>> user >>>>>> > for consent then don't ask for scopes. Twisting the OAuth spec to not >>>>>> > return an access token is not OAuth, yes you could use a different >>>>>> > endpoint rather than the token endpoint, but that is not OAuth. >>>>>> > Connect was careful not to break the OAuth spec. As long as you are >>>>>> > willing to take a access token with no scopes (the client needs to >>>>>> > understand that there are no attributes one way or another anyway >>>>> or it >>>>>> > will break) then you don't need to change OAuth. You can publish a >>>>>> > profile of connect that satisfies the use case. >>>>>> > >>>>>> > I think Mike has largely done that but it might be better being less >>>>>> > stingy on references back to the larger spec. >>>>>> > >>>>>> > The questions are do we modify OAuth to not return an access >>>>> token, and >>>>>> > if so how, and if we do is it still OAuth. >>>>>> > >>>>>> > The other largely separable question is do we create confusion in the >>>>>> > market and slow the the adoption of identity federation on top of >>>>> OAuth, >>>>>> > or find a way to make this look like a positive alignment of interests >>>>>> > around a subset of Connect. >>>>>> > >>>>>> > There are a number of options. >>>>>> > 1: We can do a profile in the OIDF and publish it as a IETF document. >>>>>> > Perhaps the cleanest from an IPR point of view.However >>>>>> > 2:We can do a profile in the OAuth WG referencing connect. >>>>>> > 3:We can do a AD sponsored profile that is not in the OAuth WG. >>>>>> > 4:We can do a small spec in OAuth to add response_type to the token >>>>>> > endpoint. in combination with 1, 2, or 3 >>>>>> > >>>>>> > I agree that stoping developers doing insecure things needs to be >>>>>> > addressed somehow. >>>>>> > I am not personally convinced that Oauth without access tokens is >>>>>> sensible. >>>>>> > >>>>>> > Looking forward to the meeting:) >>>>>> > >>>>>> > John B. >>>>>> > On Jul 24, 2014, at 6:52 AM, Brian Campbell >>>>> >>>>> > > wrote: >>>>>> > >>>>>> >> I'd note that the reaction at the conference to Ian's statement was >>>>>> >> overwhelmingly positive. There was a wide range of industry people >>>>>> >> here - implementers, practitioners, deployers, strategists, etc. >>>>> - and >>>>>> >> it seems pretty clear that the "rough consensus" of the industry at >>>>>> >> large is that a4c is not wanted or needed. >>>>>> >> >>>>>> >> >>>>>> >> On Thu, Jul 24, 2014 at 5:29 AM, Nat Sakimura >>>>> >> > wrote: >>>>>> >> >>>>>> >> And here is a quote from Ian's blog. >>>>>> >> >>>>>> >> And although the authentication wheel is round, that doesn’t >>>>>> >> mean it isn’t without its lumps. First, we do see some >>>>>> >> reinventing the wheel just to reinvent the wheel. OAuth >>>>> A4C is >>>>>> >> simply not a fruitful activity and should be put down. >>>>>> >> >>>>>> >> (Source) >>>>>> >> >>>>>> >>>>> http://www.tuesdaynight.org/2014/07/23/do-we-have-a-round-wheel-yet-musings-on-identity-standards-part-1.html >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> 2014-07-23 16:53 GMT-04:00 John Bradley >>>>> >> >: >>>>>> >> >>>>>> >> I thought I did post this to the list. >>>>>> >> >>>>>> >> I guess I hit the wrong reply on my phone. >>>>>> >> John B. >>>>>> >> Sent from my iPhone >>>>>> >> >>>>>> >> On Jul 23, 2014, at 4:50 PM, torsten@lodderstedt.net >>>>>> >> wrote: >>>>>> >> >>>>>> >>> we are two, at least :-) >>>>>> >>> >>>>>> >>> Why didn't you post this on the list? >>>>>> >>> >>>>>> >>> When will be be arriving? >>>>>> >>> >>>>>> >>> Am 23.07.2014 16:39, schrieb John Bradley: >>>>>> >>> >>>>>> >>>> Ian Glazer mentioned this in his keynote at CIS yesterday. >>>>>> >>>> His advice was please stop, we are creating confusion and >>>>>> >>>> uncertainty. >>>>>> >>>> We are becoming our own wort enemy. ( my view though >>>>> Ian may >>>>>> >>>> share it) >>>>>> >>>> Returning just an id_ token from the token endpoint has >>>>>> >>>> little real value. >>>>>> >>>> Something really useful to do would be sorting out >>>>>> >>>> channel_id so we can do PoP for id tokens to make them and >>>>>> >>>> other cookies secure in the front channel. I think >>>>> that is >>>>>> >>>> a better use of time. >>>>>> >>>> I may be in the minority opinion on that, it won't be the >>>>>> >>>> first time. >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> John B. >>>>>> >>>> Sent from my iPhone >>>>>> >>>> >>>>>> >>>> On Jul 23, 2014, at 4:04 PM, Torsten Lodderstedt >>>>>> >>>> > >>>>>> >>>> wrote: >>>>>> >>>> >>>>>> >>>>> You are right from a theoretical perspective. Practically >>>>>> >>>>> this was caused by editorial decisions during the creation >>>>>> >>>>> of the RFC. As far as I remember, there was a >>>>> definition of >>>>>> >>>>> the (one) token endpoint response in early versions. >>>>> No one >>>>>> >>>>> every considered to NOT respond with an access token from >>>>>> >>>>> the token endpoint. So one might call it an implicit >>>>>> >>>>> assumption. >>>>>> >>>>> I'm worried that people get totally confused if an >>>>>> >>>>> exception is introduced now given the broad adoption of >>>>>> >>>>> OAuth based on this assumption. >>>>>> >>>>> regards, >>>>>> >>>>> Torsten. >>>>>> >>>>> >>>>>> >>>>> Am 23.07.2014 um 15:41 schrieb Thomas Broyer >>>>>> >>>>> >: >>>>>> >>>>> >>>>>> >>>>>> Is it said anywhere that ALL grant types MUST use Section >>>>>> >>>>>> 5.1 responses? Each grant type references Section >>>>> 5.1, and >>>>>> >>>>>> "access token request" is only defined in the context of >>>>>> >>>>>> the defined grant types. Section 2.2 doesn't talk about >>>>>> >>>>>> the request or response format. >>>>>> >>>>>> >>>>>> >>>>>> Le 23 juil. 2014 21:32, "Nat Sakimura" >>>>> >>>>> >>>>>> > a écrit : >>>>>> >>>>>> >>>>>> >>>>>> Is it? Apart from the implicit grant that does >>>>> not use >>>>>> >>>>>> token endpoint, all other grant references >>>>> section 5.1 >>>>>> >>>>>> for the response, i.e., all shares the same response. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 2014-07-23 15:18 GMT-04:00 Thomas Broyer >>>>>> >>>>>> >: >>>>>> >>>>>> >>>>>> >>>>>> I hadn't realized the JSON response that requires >>>>>> >>>>>> the access_token field is defined per grant_type, >>>>>> >>>>>> so I'd be OK to "extend the semantics" as in the >>>>>> >>>>>> current draft. >>>>>> >>>>>> That was actually my main concern: that the token >>>>>> >>>>>> endpoint mandates access_token; but its actually >>>>>> >>>>>> not the case. >>>>>> >>>>>> >>>>>> >>>>>> Le 23 juil. 2014 20:46, "Nat Sakimura" >>>>>> >>>>>> >>>> > a >>>>>> >>>>>> écrit : >>>>>> >>>>>> >>>>>> >>>>>> I agree with John that overloading >>>>>> >>>>>> response_type @ authz endpoint is a bad idea. >>>>>> >>>>>> It completely changes the semantics of this >>>>>> >>>>>> parameter. NOTE: what I was proposing was not >>>>>> >>>>>> this parameter, but a new parameter >>>>>> >>>>>> response_type @ token endpoint. >>>>>> >>>>>> I also think overloading grant_type is a bad >>>>>> >>>>>> idea since it changes its semantics. I quote >>>>>> >>>>>> the definition here again: >>>>>> >>>>>> grant >>>>>> >>>>>> credential representing the resource >>>>>> >>>>>> owner's authorization >>>>>> >>>>>> grant_type >>>>>> >>>>>> type of grant sent to the token endpoint to >>>>>> >>>>>> obtain the access token >>>>>> >>>>>> It is not about controlling what is to be >>>>>> >>>>>> returned from the token endpoint, but the >>>>> hint >>>>>> >>>>>> to the token endpoint describing the type of >>>>>> >>>>>> credential the endpoint has received. It >>>>> seems >>>>>> >>>>>> the "control of what is being returned from >>>>>> >>>>>> token endpoint" is just a side effect. >>>>>> >>>>>> I am somewhat ambivalent[1] in changing the >>>>>> >>>>>> semantics of token endpoint, but in as >>>>> much as >>>>>> >>>>>> "text is the king" for a spec., we probably >>>>>> >>>>>> should not change the semantics of it as >>>>>> >>>>>> Torsten points out. If it is ok to change >>>>> this >>>>>> >>>>>> semantics, I believe defining a new parameter >>>>>> >>>>>> to this endpoint to control the response >>>>> would >>>>>> >>>>>> be the best way to go. This is what I have >>>>>> >>>>>> described previously. >>>>>> >>>>>> Defining a new endpoint to send code to >>>>> get ID >>>>>> >>>>>> Token and forbidding the use of it against >>>>>> >>>>>> token endpoint would not change the semantics >>>>>> >>>>>> of any existing parameter or endpoint, which >>>>>> >>>>>> is good. However, I doubt if it is not worth >>>>>> >>>>>> doing. What's the point of avoiding access >>>>>> >>>>>> token scoped to UserInfo endpoint after all? >>>>>> >>>>>> Defining a new endpoint for just avoiding the >>>>>> >>>>>> access token for userinfo endpoint seems way >>>>>> >>>>>> too much the heavy wait way and it breaks >>>>>> >>>>>> interoperabiliy: it defeats the purpose of >>>>>> >>>>>> standardization. >>>>>> >>>>>> I have started feeling that no change is the >>>>>> >>>>>> best way out. >>>>>> >>>>>> Nat >>>>>> >>>>>> [1] If instead of saying "Token endpoint - >>>>>> >>>>>> used by the client to exchange an >>>>>> >>>>>> authorization grant for an access token, >>>>>> >>>>>> typically with client authentication", it >>>>> were >>>>>> >>>>>> saying "Token endpoint - used by the >>>>> client to >>>>>> >>>>>> exchange an authorization grant for tokens, >>>>>> >>>>>> typically with client authentication", >>>>> then it >>>>>> >>>>>> would have been OK. It is an expansion of the >>>>>> >>>>>> capability rather than changing the >>>>> semantics. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 2014-07-23 13:39 GMT-04:00 Mike Jones >>>>>> >>>>>> >>>>> >>>>>> >: >>>>>> >>>>>> >>>>>> >>>>>> You need the alternative response_type >>>>>> >>>>>> value ("code_for_id_token" in the A4C >>>>>> >>>>>> draft) to tell the Authorization >>>>> Server to >>>>>> >>>>>> return a code to be used with the new >>>>>> >>>>>> grant type, rather than one to use with >>>>>> >>>>>> the "authorization_code" grant type >>>>> (which >>>>>> >>>>>> is what response_type=code does). >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> *From:*OAuth >>>>>> >>>>>> [mailto:oauth-bounces@ietf.org >>>>>> >>>>>> ] *On >>>>>> >>>>>> Behalf Of *John Bradley >>>>>> >>>>>> *Sent:* Wednesday, July 23, 2014 10:33 AM >>>>>> >>>>>> *To:* torsten@lodderstedt.net >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> *Cc:* oauth@ietf.org >>>>> >>>>>> >>>>>> *Subject:* Re: [OAUTH-WG] New Version >>>>>> >>>>>> Notification for >>>>>> >>>>>> draft-hunt-oauth-v2-user-a4c-05.txt >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> If we use the token endpoint then a new >>>>>> >>>>>> grant_type is the best way. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> It sort of overloads code, but that is >>>>>> >>>>>> better than messing with >>>>> response_type for >>>>>> >>>>>> the authorization endpoint to change the >>>>>> >>>>>> response from the token_endpoint. >>>>> That is >>>>>> >>>>>> in my opinion a champion bad idea. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> In discussions developing Connect we >>>>>> >>>>>> decided not to open this can of worms >>>>>> >>>>>> because no good would come of it. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> The token_endpoint returns a access >>>>> token. >>>>>> >>>>>> Nothing requires scope to be associates >>>>>> >>>>>> with the token. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> That is the best solution. No change >>>>>> >>>>>> required. Better interoperability in my >>>>>> >>>>>> opinion. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Still on my way to TO, getting in later >>>>>> >>>>>> today. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> John B. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Sent from my iPhone >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Jul 23, 2014, at 12:15 PM, >>>>>> >>>>>> torsten@lodderstedt.net >>>>>> >>>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> The "response type" of the token >>>>>> >>>>>> endpoint is controlled by the >>>>> value of >>>>>> >>>>>> the parameter "grant_type". So there >>>>>> >>>>>> is no need to introduce a new >>>>> parameter. >>>>>> >>>>>> >>>>>> >>>>>> wrt to a potential "no_access_token" >>>>>> >>>>>> grant type. I do not consider this a >>>>>> >>>>>> good idea as it changes the semantics >>>>>> >>>>>> of the token endpoint (as already >>>>>> >>>>>> pointed out by Thomas). This endpoint >>>>>> >>>>>> ALWAYS responds with an access token >>>>>> >>>>>> to any grant type. I therefore would >>>>>> >>>>>> prefer to use another endpoint >>>>> for the >>>>>> >>>>>> intended purpose. >>>>>> >>>>>> >>>>>> >>>>>> regards, >>>>>> >>>>>> Torsten. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Am 23.07.2014 13:04, schrieb Nat >>>>>> Sakimura: >>>>>> >>>>>> >>>>>> >>>>>> IMHO, changing the semantics of >>>>>> >>>>>> "response_type" @ authz endpoint >>>>>> >>>>>> this way is not a good thing. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Instead, defining a new parameter >>>>>> >>>>>> "response_type" @ token endpoint, >>>>>> >>>>>> as I described in my previous >>>>>> >>>>>> message, >>>>>> >>>>>> >>>>>> >>>>>> probably is better. At least, it >>>>>> >>>>>> does not change the semantics of >>>>>> >>>>>> the parameters of RFC6749. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Nat >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 2014-07-23 12:48 GMT-04:00 Thomas >>>>>> >>>>>> Broyer >>>>> >>>>>> >: >>>>>> >>>>>> >>>>>> >>>>>> No, I mean response_type=none and >>>>>> >>>>>> response_type=id_token don't >>>>>> >>>>>> generate a code or access >>>>> token so >>>>>> >>>>>> you don't use the Token Endpoint >>>>>> >>>>>> (which is not the same as the >>>>>> >>>>>> Authentication Endpoint BTW). >>>>>> >>>>>> >>>>>> >>>>>> With >>>>>> >>>>>> response_type=code_for_id_token, >>>>>> >>>>>> you get a code and exchange >>>>> it for >>>>>> >>>>>> an id_token only, rather than an >>>>>> >>>>>> access_token, so you're changing >>>>>> >>>>>> the semantics of the Token >>>>> Endpoint. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> I'm not saying it's a bad thing, >>>>>> >>>>>> just that you can't really >>>>> compare >>>>>> >>>>>> none and id_token with >>>>>> >>>>>> code_for_id_token. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Jul 23, 2014 at 6:45 PM, >>>>>> >>>>>> Richer, Justin P. >>>>>> >>>>>> >>>>> >>>>>> > >>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> It's only "not using the token >>>>>> >>>>>> endpoint" because the token >>>>>> >>>>>> endpoint copy-pasted and renamed >>>>>> >>>>>> the authentication endpoint. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- Justin >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Jul 23, 2014, at 9:30 AM, >>>>>> >>>>>> Thomas Broyer >>>>> >>>>>> > >>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Except that these are about not >>>>>> >>>>>> using the Token Endpoint at all, >>>>>> >>>>>> whereas the current proposal is >>>>>> >>>>>> about the Token Endpoint not >>>>>> >>>>>> returning an access_token >>>>> field in >>>>>> >>>>>> the JSON. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Jul 23, 2014 at 4:26 PM, >>>>>> >>>>>> Mike Jones >>>>>> >>>>>> >>>>> >>>>>> >>>>>> > >>>>>> >>>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> The response_type "none" is >>>>>> >>>>>> already used in practice, which >>>>>> >>>>>> returns no access token. It was >>>>>> >>>>>> accepted by the designated >>>>> experts >>>>>> >>>>>> and registered in the IANA OAuth >>>>>> >>>>>> Authorization Endpoint Response >>>>>> >>>>>> Types registry at >>>>>> >>>>>> >>>>>> >>>>> http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#endpoint >>>>>> >>>>>> >>>>>> >>>>> . >>>>>> >>>>>> The registered "id_token" >>>>> response >>>>>> >>>>>> type also returns no access >>>>> token. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> So I think the question of >>>>> whether >>>>>> >>>>>> response types that result in no >>>>>> >>>>>> access token being returned are >>>>>> >>>>>> acceptable within OAuth 2.0 is >>>>>> >>>>>> already settled, as a practical >>>>>> >>>>>> matter. Lots of OAuth >>>>>> >>>>>> implementations are already using >>>>>> >>>>>> such response types. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- Mike >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> *From:*OAuth >>>>>> >>>>>> [mailto:oauth-bounces@ietf.org >>>>>> >>>>>> ] >>>>>> >>>>>> *On Behalf Of *Phil Hunt >>>>>> >>>>>> *Sent:* Wednesday, July 23, 2014 >>>>>> >>>>>> 7:09 AM >>>>>> >>>>>> *To:* Nat Sakimura >>>>>> >>>>>> *Cc:* >>>>> >>>>>> > >>>>>> >>>>>> *Subject:* Re: [OAUTH-WG] New >>>>>> >>>>>> Version Notification for >>>>>> >>>>>> >>>>> draft-hunt-oauth-v2-user-a4c-05.txt >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Yes. This is why it has to be >>>>>> >>>>>> discussed in the IETF. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Phil >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> @independentid >>>>>> >>>>>> >>>>>> >>>>>> www.independentid.com >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> phil.hunt@oracle.com >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Jul 23, 2014, at 9:43 AM, Nat >>>>>> >>>>>> Sakimura >>>>> >>>>>> > >>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Reading back the RFC6749, I >>>>> am not >>>>>> >>>>>> sure if there is a good way of >>>>>> >>>>>> suppressing access token from the >>>>>> >>>>>> response and still be OAuth. It >>>>>> >>>>>> will break whole bunch of >>>>> implicit >>>>>> >>>>>> definitions like: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> authorization server >>>>>> >>>>>> The server issuing access >>>>>> >>>>>> tokens to the client after >>>>>> >>>>>> successfully >>>>>> >>>>>> authenticating the resource >>>>>> >>>>>> owner and obtaining >>>>> authorization. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> After all, OAuth is all about >>>>>> >>>>>> issuing access tokens. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Also, I take back my statement on >>>>>> >>>>>> the grant type in my previous >>>>> mail. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> The definition of grant and >>>>>> >>>>>> grant_type are respectively: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> grant >>>>>> >>>>>> >>>>>> >>>>>> credential representing the >>>>>> >>>>>> resource owner's authorization >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> grant_type >>>>>> >>>>>> >>>>>> >>>>>> (string representing the) >>>>> type >>>>>> >>>>>> of grant sent to the token >>>>>> >>>>>> endpoint to obtain the access >>>>> token >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Thus, the grant sent to the token >>>>>> >>>>>> endpoint in this case is still >>>>>> >>>>>> 'code'. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Response type on the other >>>>> hand is >>>>>> >>>>>> not so well defined in RFC6749, >>>>>> >>>>>> but it seems it is representing >>>>>> >>>>>> what is to be returned from the >>>>>> >>>>>> authorization endpoint. To >>>>> express >>>>>> >>>>>> what is to be returned from token >>>>>> >>>>>> endpoint, perhaps defining a new >>>>>> >>>>>> parameter to the token endpoint, >>>>>> >>>>>> which is a parallel to the >>>>>> >>>>>> response_type to the >>>>> Authorization >>>>>> >>>>>> Endpoint seems to be a more >>>>>> >>>>>> symmetric way, though I am not >>>>>> >>>>>> sure at all if that is going >>>>> to be >>>>>> >>>>>> OAuth any more. One straw-man is >>>>>> >>>>>> to define a new parameter called >>>>>> >>>>>> response_type to the token >>>>>> >>>>>> endpoint such as: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> response_type >>>>>> >>>>>> >>>>>> >>>>>> OPTIONAL. A string >>>>>> >>>>>> representing what is to be >>>>>> >>>>>> returned from the token endpoint. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Then define the behavior of the >>>>>> >>>>>> endpoint according to the values >>>>>> >>>>>> as the parallel to the >>>>>> >>>>>> multi-response type spec. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Nat >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 2014-07-23 7:21 GMT-04:00 Phil >>>>>> >>>>>> Hunt >>>>> >>>>>> >: >>>>>> >>>>>> >>>>>> >>>>>> The draft is very clear. >>>>>> >>>>>> >>>>>> >>>>>> Phil >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Jul 23, 2014, at 0:46, Nat >>>>>> >>>>>> Sakimura >>>>> >>>>>> > >>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> The new grant type that I was >>>>>> >>>>>> talking about was >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> "authorization_code_but_do_not_return_access_nor_refresh_token", >>>>>> >>>>>> so to speak. >>>>>> >>>>>> >>>>>> >>>>>> It does not return anything >>>>>> >>>>>> per se, but an extension can >>>>>> >>>>>> define something on top >>>>> of it. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Then, OIDC can define a >>>>>> >>>>>> binding to it so that the >>>>>> >>>>>> binding only returns ID >>>>> Token. >>>>>> >>>>>> >>>>>> >>>>>> This binding work should be >>>>>> >>>>>> done in OIDF. Should there be >>>>>> >>>>>> such a grant type, >>>>>> >>>>>> >>>>>> >>>>>> it will be an extremely short >>>>>> >>>>>> spec. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> At the same time, if any >>>>> other >>>>>> >>>>>> specification wanted to >>>>> define >>>>>> >>>>>> >>>>>> >>>>>> other type of tokens and have >>>>>> >>>>>> it returned from the token >>>>>> >>>>>> endpoint, >>>>>> >>>>>> >>>>>> >>>>>> it can also use this >>>>> grant type. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> If what you want is to define >>>>>> >>>>>> a new grant type that returns >>>>>> >>>>>> ID Token only, >>>>>> >>>>>> >>>>>> >>>>>> then, I am with Justin. Since >>>>>> >>>>>> "other response than ID >>>>> Token" >>>>>> >>>>>> is only >>>>>> >>>>>> >>>>>> >>>>>> theoretical, this is a more >>>>>> >>>>>> plausible way forward, I >>>>>> suppose. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Nat >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 2014-07-22 14:30 GMT-04:00 >>>>>> >>>>>> Justin Richer >>>>> >>>>> >>>>>> >: >>>>>> >>>>>> >>>>>> >>>>>> So the draft would literally >>>>>> >>>>>> turn into: >>>>>> >>>>>> >>>>>> >>>>>> "The a4c response type and >>>>>> >>>>>> grant type return an id_token >>>>>> >>>>>> from the token endpoint with >>>>>> >>>>>> no access token. All >>>>>> >>>>>> parameters and values are >>>>>> >>>>>> defined in OIDC." >>>>>> >>>>>> >>>>>> >>>>>> Seems like the perfect mini >>>>>> >>>>>> extension draft for OIDF >>>>> to do. >>>>>> >>>>>> >>>>>> >>>>>> --Justin >>>>>> >>>>>> >>>>>> >>>>>> /sent from my phone/ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Jul 22, 2014 10:29 AM, Nat >>>>>> >>>>>> Sakimura >>>>> >>>>>> > >>>>>> >>>>>> wrote: >>>>>> >>>>>> > >>>>>> >>>>>> > What about just defining a >>>>>> >>>>>> new grant type in this WG? >>>>>> >>>>>> > >>>>>> >>>>>> > >>>>>> >>>>>> > 2014-07-22 12:56 GMT-04:00 >>>>>> >>>>>> Phil Hunt >>>>>> >>>>>> >>>>> >>>>>> >>>>> >: >>>>>> >>>>>> >> >>>>>> >>>>>> >> That would be nice. >>>>> However >>>>>> >>>>>> oidc still needs the new >>>>> grant >>>>>> >>>>>> type in order to >>>>> implement the >>>>>> >>>>>> same flow. >>>>>> >>>>>> >> >>>>>> >>>>>> >> Phil >>>>>> >>>>>> >> >>>>>> >>>>>> >> On Jul 22, 2014, at 11:35, >>>>>> >>>>>> Nat Sakimura >>>>>> >>>>>> >>>>> >>>>>> > >>>>>> >>>>>> wrote: >>>>>> >>>>>> >> >>>>>> >>>>>> >>> +1 to Justin. >>>>>> >>>>>> >>> >>>>>> >>>>>> >>> >>>>>> >>>>>> >>> 2014-07-22 9:54 GMT-04:00 >>>>>> >>>>>> Richer, Justin P. >>>>>> >>>>>> >>>>> >>>>>> >: >>>>>> >>>>>> >>>> >>>>>> >>>>>> >>>> Errors like these >>>>> make it >>>>>> >>>>>> clear to me that it would >>>>> make >>>>>> >>>>>> much more sense to develop >>>>>> >>>>>> this document in the OpenID >>>>>> >>>>>> Foundation. It should be >>>>>> >>>>>> something that directly >>>>>> >>>>>> references OpenID Connect >>>>> Core >>>>>> >>>>>> for all of these terms >>>>> instead >>>>>> >>>>>> of redefining them. It's >>>>> doing >>>>>> >>>>>> authentication, which is >>>>>> >>>>>> fundamentally what OpenID >>>>>> >>>>>> Connect does on top of OAuth, >>>>>> >>>>>> and I don't see a good >>>>>> >>>>>> argument for doing this work >>>>>> >>>>>> in this working group. >>>>>> >>>>>> >>>> >>>>>> >>>>>> >>>> -- Justin >>>>>> >>>>>> >>>> >>>>>> >>>>>> >>>> On Jul 22, 2014, at 4:30 >>>>>> >>>>>> AM, Thomas Broyer >>>>>> >>>>>> >>>>> >>>>>> > >>>>>> >>>>>> wrote: >>>>>> >>>>>> >>>> >>>>>> >>>>>> >>>>> >>>>>> >>>>>> >>>>> >>>>>> >>>>>> >>>>> >>>>>> >>>>>> >>>>> On Mon, Jul 21, 2014 at >>>>>> >>>>>> 11:52 PM, Mike Jones >>>>>> >>>>>> >>>>> >>>>>> >>>>>> > >>>>>> >>>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Thanks for your >>>>> review, >>>>>> >>>>>> Thomas. The "prompt=consent" >>>>>> >>>>>> definition being missing >>>>> is an >>>>>> >>>>>> editorial error. It >>>>> should be: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> consent >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> The Authorization >>>>>> >>>>>> Server SHOULD prompt the >>>>>> >>>>>> End-User for consent before >>>>>> >>>>>> returning information to the >>>>>> >>>>>> Client. If it cannot obtain >>>>>> >>>>>> consent, it MUST return an >>>>>> >>>>>> error, typically >>>>>> consent_required. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> I'll plan to add it in >>>>>> >>>>>> the next draft. >>>>>> >>>>>> >>>>> >>>>>> >>>>>> >>>>> >>>>>> >>>>>> >>>>> It looks like the >>>>>> >>>>>> consent_required error needs >>>>>> >>>>>> to be defined too, and you >>>>>> >>>>>> might have forgotten to also >>>>>> >>>>>> import >>>>>> >>>>>> account_selection_required >>>>>> >>>>>> from OpenID Connect. >>>>>> >>>>>> >>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> I agree that >>>>> there's no >>>>>> >>>>>> difference between a response >>>>>> >>>>>> with multiple "amr" values >>>>>> >>>>>> that includes "mfa" and one >>>>>> >>>>>> that doesn't. Unless a clear >>>>>> >>>>>> use case for why "mfa" is >>>>>> >>>>>> needed can be identified, we >>>>>> >>>>>> can delete it in the next >>>>> draft. >>>>>> >>>>>> >>>>> >>>>>> >>>>>> >>>>> >>>>>> >>>>>> >>>>> Thanks. >>>>>> >>>>>> >>>>> >>>>>> >>>>>> >>>>> How about "pwd" then? I >>>>>> >>>>>> fully understand that I >>>>> should >>>>>> >>>>>> return "pwd" if the user >>>>>> >>>>>> authenticated using a >>>>>> >>>>>> password, but what "the >>>>>> >>>>>> service if a client secret is >>>>>> >>>>>> used" means in the definition >>>>>> >>>>>> for the "pwd" value? >>>>>> >>>>>> >>>>> >>>>>> >>>>>> >>>>> (Nota: I know you're at >>>>>> >>>>>> IETF-90, I'm ready to wait >>>>>> >>>>>> 'til you come back ;-) ) >>>>>> >>>>>> >>>>> >>>>>> >>>>>> >>>>> -- >>>>>> >>>>>> >>>>> Thomas Broyer >>>>>> >>>>>> >>>>> /tɔ.ma.bʁwa.je/ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> >>>>>> >>>>> 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 >>>>>> >>>>>> >>>> >>>>>> >>>>>> >>> >>>>>> >>>>>> >>> >>>>>> >>>>>> >>> >>>>>> >>>>>> >>> -- >>>>>> >>>>>> >>> Nat Sakimura (=nat) >>>>>> >>>>>> >>> Chairman, OpenID >>>>> Foundation >>>>>> >>>>>> >>> http://nat.sakimura.org/ >>>>>> >>>>>> >>> @_nat_en >>>>>> >>>>>> >>> >>>>>> >>>>>> >>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> >>>>>> >>> OAuth mailing list >>>>>> >>>>>> >>> OAuth@ietf.org >>>>>> >>>>>> >>>>>> >>>>>> >>> >>>>>> >>>>>> >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> > >>>>>> >>>>>> > >>>>>> >>>>>> > >>>>>> >>>>>> > >>>>>> >>>>>> > -- >>>>>> >>>>>> > Nat Sakimura (=nat) >>>>>> >>>>>> > Chairman, OpenID Foundation >>>>>> >>>>>> > http://nat.sakimura.org/ >>>>>> >>>>>> > @_nat_en >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Nat Sakimura (=nat) >>>>>> >>>>>> >>>>>> >>>>>> Chairman, OpenID Foundation >>>>>> >>>>>> http://nat.sakimura.org/ >>>>>> >>>>>> @_nat_en >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Nat Sakimura (=nat) >>>>>> >>>>>> >>>>>> >>>>>> Chairman, OpenID Foundation >>>>>> >>>>>> http://nat.sakimura.org/ >>>>>> >>>>>> @_nat_en >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> >>>>>> OAuth mailing list >>>>>> >>>>>> OAuth@ietf.org >>>>>> >>>>>> >>>>>> >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Thomas Broyer >>>>>> >>>>>> /tɔ.ma.bʁwa.je/ >>>>>> >>>>>> >>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> >>>>>> OAuth mailing list >>>>>> >>>>>> OAuth@ietf.org >>>>>> >>>>>> >>>>>> >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Thomas Broyer >>>>>> >>>>>> /tɔ.ma.bʁwa.je/ >>>>>> >>>>>> >>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> >>>>>> OAuth mailing list >>>>>> >>>>>> OAuth@ietf.org >>>>>> >>>>>> >>>>>> >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Nat Sakimura (=nat) >>>>>> >>>>>> >>>>>> >>>>>> Chairman, OpenID Foundation >>>>>> >>>>>> http://nat.sakimura.org/ >>>>>> >>>>>> @_nat_en >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> >>>>>> >>>>>> >>>>>> 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 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Nat Sakimura (=nat) >>>>>> >>>>>> Chairman, OpenID Foundation >>>>>> >>>>>> http://nat.sakimura.org/ >>>>>> >>>>>> @_nat_en >>>>>> >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>>> >>>>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>> >> >> > From nobody Tue Oct 14 02:26:26 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B3D61A6FEF for ; Tue, 14 Oct 2014 02:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.308 X-Spam-Level: **** X-Spam-Status: No, score=4.308 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FSL_HELO_BARE_IP_2=1, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, SPF_PASS=-0.001] autolearn=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 3CqHkBnZwPnj for ; Tue, 14 Oct 2014 02:26:18 -0700 (PDT) Received: from nrifs03.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81A031A6FEC for ; Tue, 14 Oct 2014 02:26:18 -0700 (PDT) Received: from nriea05.index.or.jp (unknown [172.19.246.40]) by nrifs03.index.or.jp (Postfix) with SMTP id 1B8D517EA43 for ; Tue, 14 Oct 2014 18:26:18 +0900 (JST) Received: from nrims00a.nri.co.jp ([192.50.135.11]) by nriea05.index.or.jp (unknown) with ESMTP id s9E9QHAE020423 for ; Tue, 14 Oct 2014 18:26:17 +0900 Received: from nrims00a.nri.co.jp (localhost.localdomain [127.0.0.1]) by nrims00a.nri.co.jp (Switch-3.3.3/Switch-3.3.3) with ESMTP id s9E9QHmQ010241; Tue, 14 Oct 2014 18:26:17 +0900 Received: (from mailnull@localhost) by nrims00a.nri.co.jp (Switch-3.3.3/Switch-3.3.0/Submit) id s9E9QHMu010238; Tue, 14 Oct 2014 18:26:17 +0900 X-Authentication-Warning: nrims00a.nri.co.jp: mailnull set sender to n-sakimura@nri.co.jp using -f Received: from nrizmf11b.index.or.jp ([172.100.25.18]) by nrims00a.nri.co.jp (Switch-3.3.3/Switch-3.3.3) with ESMTP id s9E9QHr4010234 for ; Tue, 14 Oct 2014 18:26:17 +0900 Received: from 127.0.0.1 (127.0.0.1) by m-FILTER with ESMTP; Tue, 14 Oct 2014 18:26:17 +0900 Date: Tue, 14 Oct 2014 18:26:11 +0900 From: Nat Sakimura To: oauth@ietf.org Message-Id: <20141014182611.dd6598cc163e9c640d4167fd@nri.co.jp> X-Mailer: Sylpheed 3.4.2 (GTK+ 2.10.14; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MailAdviser: Ver1.5.1 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/q13T48BhXmXwI5pIBd_zPYAy9pw Subject: [OAUTH-WG] SPOP - code verifier requirements X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 09:26:22 -0000 In his mail, Mike asked whether code verifier is a value that is sendable without trnasformation as a http parameter value, or if it needs to be % encoded when it is being sent. We have several options here: 1) Require that the code verifier to be a base64url encoded string of a binary random value. 2) Let code verifier to be a binary string and require it to be either % encoded or base64url encoded when it is sent. In this case, which encoding should we use? 3) require the code verifier to be conform to the following ABNF: code_verifier = 16*128unreserved unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" Which one do you guys prefer? Nat -- Nat Sakimura (n-sakimura@nri.co.jp) Nomura Research Institute, Ltd. PLEASE READ: The information contained in this e-mail is confidential and intended for the named recipient(s) only. If you are not an intended recipient of this e-mail, you are hereby notified that any review, dissemination, distribution or duplication of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete your copy from your system. From nobody Tue Oct 14 02:27:11 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B4611A6FFF for ; Tue, 14 Oct 2014 02:27:08 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8E7rj_Hrfz0s for ; Tue, 14 Oct 2014 02:27:01 -0700 (PDT) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12D831A6FEC for ; Tue, 14 Oct 2014 02:26:59 -0700 (PDT) Received: by mail-lb0-f176.google.com with SMTP id p9so7687026lbv.21 for ; Tue, 14 Oct 2014 02:26:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=jl+SN2PFbh/dkxHP1yRsSOyp09+buvhvg4XMphnNnrA=; b=Wa04gMMw5GDJXt4m5LjrswmBZD1mPWYjqnH5xit6SKWcMnXsQQlYDBEoorQdsDeWWQ d4RyhVoHfTaZl7P1WO3wQyjEob0YyesW+PC/iuTfZsgnWEcJQ/T6opQxcig/KJoPsgoI UK1q89dQcsktt30O7wiCvA5ug1WWBaMqOLprwMKRNTT35kpubenULr6Lq45ozuRKcTD1 hR6Hk93bN+OpD8jy3rXOYHK4K8/lBaKHfaswKGbhPHFhvu/8eso5bstgqsh1oa+ArCb/ YbkJpf+cQYYSYtOiLfcvZjuROTxKPhnyb5GQBbgFpR7hZj3ZsBBTe6Plk38Y/qeVS8XW GD+Q== X-Received: by 10.152.7.7 with SMTP id f7mr3926939laa.57.1413278818161; Tue, 14 Oct 2014 02:26:58 -0700 (PDT) Received: from [10.36.226.2] ([80.169.137.63]) by mx.google.com with ESMTPSA id s8sm5390376las.29.2014.10.14.02.26.56 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Oct 2014 02:26:57 -0700 (PDT) Message-ID: <543CEC5F.6010100@gmail.com> Date: Tue, 14 Oct 2014 10:26:55 +0100 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Phil Hunt References: <543BE1A1.6020902@gmail.com> <44A3CD9F-9E2E-4746-A5B1-47984BBE973C@oracle.com> <543C3510.7070201@gmail.com> <9C1B0B29-47AB-4057-96B4-BA18E116B5B1@oracle.com> <543CEBF6.4090407@gmail.com> In-Reply-To: <543CEBF6.4090407@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/JKPnju6GgRPBVFb1rp-zqdYVgco Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-v2-user-a4c-05.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 09:27:08 -0000 Sorry for the noise, On 14/10/14 10:25, Sergey Beryozkin wrote: > Hi Phil, All, > > Thanks for your positive feedback and further comments below. > My goal was really about trying to make a clear picture in my mind about > what OIDC is with respect to OAuth2, and specifically supporting the > point about OIDC not being just OAuth2. > > As such, the idea of a specific OIDC profile where no access token was > used appealed to me but really in light of supporting the same point > that OIDC being not just OAuth2. I understand it 'breaks' the clean OIDC > OAuth2-based model. Hence I also tried to suggest that even though OIDC > does return an access token, this token does not have to be a > full-powered token that a client can use to access something else but a > user profile endpoint (unless custom scopes are also used). So the > access token is there but it's only usable in the OAuth2 world. > meant to say in the OIDC world and as such it is a limited token > I respect the effort done in the a4c draft - I'm just not sure really it > has to be a separate effort (as opposed to it being an OIDC 'exception' > light weight profile - can be simpler for users like me to have it all > comprehended when it is a single family of docs) should the experts like > yourself and others really like the idea of having a pure authentication > flow supported. > > But I'll be watching with the interest how it all evolves now :-) > > Thanks, Sergey > > On 13/10/14 22:17, Phil Hunt wrote: >> Sergey, >> >> Actually, I think your comments are fine. They add to the discussion >> on why A4C is distinct from OIDC’s larger IDP role in an OAuth style >> flow and why *both* are needed. >> >> Comments in line. >> >> Phil >> >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> >> >> >> On Oct 13, 2014, at 1:24 PM, Sergey Beryozkin >> wrote: >> >>> Hi Phil >>> >>> Thanks for the clarifications, >>> On 13/10/14 20:18, Phil Hunt wrote: >>>> The point to be made is if the client’s objective is to authenticate >>>> the User, the base 6749 spec does not guarantee this at all. >>>> >>>> It simply authorizes the client to access a resource and nothing more. >>>> >>>> It turns out that a significant part of the time authentication does >>>> occur, but the client does not have access to that information. Nor >>>> can it specifically request re-authentication. >>>> >>>> Further, if the client doesn’t wield the access token, its might not >>>> be proof that the token received was actually an authorization. >>>> >>>> OpenID gives you both authen information and authorization profile >>>> information (as a resource). >>>> >>> Yes, I experimented with it. >>>> This thread was more about how to do just authentication ONLY. What >>>> are the requirements for a client to know a User *was* authenticated >>>> and when. While some flows of OpenID can achieve this, its not >>>> clear that it addresses all cases. Furhter there is discussion (as >>>> Justin mentions) that a flow that does not produce an access token >>>> is not an authorization flow and is not OAuth. I agree. >>> Sure. >>>> It an authentication flow and should be distinct IMHO. >>>> >>> I guess that is why the idea of having an OIDC profile dedicated to >>> the authentication alone (no access token) which I believe was >>> suggested here caught my attention. But then it is not OAuth2 and >>> hence not OIDC. The chicken in the egg situation :-). As I said in >>> the prev email, having an access token which is really restricted to >>> the OIDC resource (profile) seems like a good compromise… >> >> [PH] We discussed this in Toronto and OIDC can’t do this and be >> compliant woith OAuth. It wouldn’t be OAuth. Someone also pointed out >> that the OAuth WG isn’t chartered to do authentication and that kind >> of killed the discussion leaving the issue hanging unresolved. >> >> If you look at draft 00 of the A4C draft you will note that I >> originally proposed it as a new end-point. My feeling it should NOT be >> an OAuth flow - because as Justin says, if you aren’t returning an >> access token, you aren’t doing OAuth. The issue is that the technical >> redirect flow for authentication and authorization share the same >> security risks and counter-measures. It would be good therefore to >> build “in-parallel” or “underneath” OAuth to define an authn flow. >> >> I would still recommend OIDC as a layer on top of OAuth that defines >> the standard way to get profile claims (the full OAuth style IDP >> functionality). >> >>> >>>> That said, I am in the minority with this opinion and I acknowledge >>>> as being as such. >>>> >>> >>> Sorry if I hijacked this thread and started the off-topic 'flow'...I >>> guess my reasoning here is a bit all over the place, but I'm pretty >>> sure now I see the big picture better >>> >>> Thanks, Sergey >>> >>>> Phil >>>> >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>> >>>> >>>> >>>> On Oct 13, 2014, at 7:28 AM, Sergey Beryozkin >>>> wrote: >>>> >>>>> On 13/10/14 15:17, Justin Richer wrote: >>>>>> You certainly can do authentication without using an access token, >>>>>> but >>>>>> then I would argue that's no longer OAuth. Basically you're making >>>>>> tofu >>>>>> carob fudge. >>>>> >>>>> Right, the access token is there for a client to get to the >>>>> UserInfo endpoint, as far as OIDC is concerned. What if the info in >>>>> the id_token is sufficient ? >>>>> I guess as far as a typical OAuth2 client is concerned, requesting >>>>> "openid profile" only effectively gives one an access token that >>>>> can only be used with the UserInfo endpoint. >>>>> >>>>> So yes, may be even though OIDC has an access token returned, >>>>> unless other custom scopes are used, the access token would be >>>>> pretty much of use in the OIDC context only if a client chooses to >>>>> work with the UserInfo...I guess the id_token/at_hash is useful on >>>>> its own >>>>> >>>>> >>>>> Cheers, Sergey >>>>> >>>>>> >>>>>> >>>>>> -- Justin >>>>>> >>>>>> / Sent from my phone / >>>>>> >>>>>> >>>>>> -------- Original message -------- >>>>>> From: Sergey Beryozkin >>>>>> Date:10/13/2014 9:00 AM (GMT-05:00) >>>>>> To: Justin Richer , oauth@ietf.org >>>>>> Cc: >>>>>> Subject: Re: [OAUTH-WG] New Version Notification for >>>>>> draft-hunt-oauth-v2-user-a4c-05.txt >>>>>> >>>>>> Hi Justin, >>>>>> On 13/10/14 12:53, Justin Richer wrote: >>>>>>> You are correct in that OAuth 2 and OpenID Connect are not the same >>>>>>> thing, but your user is correct that OIDC adds a few pieces on >>>>>>> top of >>>>>>> OAuth to add authentication capabilities. OIDC was designed very >>>>>>> explicitly to be compatible with vanilla OAuth, partially do that >>>>>>> people >>>>>>> would be able to deploy it on top of existing OAuth >>>>>>> infrastructure and >>>>>>> code. But the very fact that OIDC adds a few things on top of >>>>>>> OAuth to >>>>>>> give more functionality should be sufficient evidence that >>>>>>> they're not >>>>>>> equivalent. >>>>>>> >>>>>>> It's more proper to say that OpenID Connect is an extension and >>>>>>> application of OAuth. One that provides an authentication and >>>>>> identity API. >>>>>>> >>>>>> I agree and this is more or less how I answered. >>>>>> >>>>>> Though the 'borders' can be blurred, one can claim that if a user >>>>>> actually logs on into a confidential OAuth2 client web application >>>>>> which >>>>>> redirects this user to AS requesting a code with some scopes such >>>>>> as "a >>>>>> b" then when it uses "a b openid profile" it is basically does a pure >>>>>> OAuth2 code flow where the client requests 'a b' plus also a scope >>>>>> allowing it later to query the identity system on behalf of a user. >>>>>> >>>>>> I like the "The extension and application of OAuth2" >>>>>> characteristic of >>>>>> OIDC. IMHO it's becoming more obvious if OIDC is used to support SSO >>>>>> into non-OAuth2 servers, when it is the case then there's no >>>>>> 'feeling' >>>>>> that OIDC is just a case of the confidential client adding the extra >>>>>> scopes and getting the extra (authentication) info back. A standalone >>>>>> OIDC RP protecting such non OAuth2 servers is very much about the >>>>>> authentication/identity. >>>>>> >>>>>> I also thought that having some OID profile (as opposed updating >>>>>> OAuth2 >>>>>> to support no access tokens) where no access but only id token was >>>>>> returned (as suggested in this thread) would probably make sense too. >>>>>> >>>>>>> The way I like to explain it (which I stole from someone else) is >>>>>>> that >>>>>>> OAuth is like chocolate and authentication is like fudge. They >>>>>>> are not >>>>>>> the same thing. You can make chocolate into fudge out you can >>>>>>> make it >>>>>>> into something else or you can just have it on its own. You can make >>>>>>> fudge with chocolate or you can make it with peanut butter or you >>>>>>> can >>>>>>> make it with potatoes if you want to, but it needs a couple >>>>>>> ingredients >>>>>>> and a very common one is chocolate. OpenID Connect is a recipe for >>>>>>> chocolate fudge that a lot of people like. And it makes my fudge >>>>>>> compatible with your fudge, which is where the metaphor breaks >>>>>>> down. :-) >>>>>>> >>>>>> Thanks for sharing this colourful explanation :-). Perhaps I should >>>>>> borrow it :-), >>>>>> Cheers, Sergey >>>>>> >>>>>> >>>>>>> >>>>>>> -- Justin >>>>>>> >>>>>>> / Sent from my phone / >>>>>>> >>>>>>> >>>>>>> -------- Original message -------- >>>>>>> From: Sergey Beryozkin >>>>>>> Date:10/13/2014 6:33 AM (GMT-05:00) >>>>>>> To: oauth@ietf.org >>>>>>> Cc: >>>>>>> Subject: Re: [OAUTH-WG] New Version Notification for >>>>>>> draft-hunt-oauth-v2-user-a4c-05.txt >>>>>>> >>>>>>> Hi >>>>>>> >>>>>>> We've had a user asserting that "OAuth2 == OpenidConnect", >>>>>>> referring to >>>>>>> the fact that the 'only' thing OIC adds on top of the >>>>>>> authorization code >>>>>>> flow is the client specifying few extra scopes like 'openid' and >>>>>>> 'profile' and the authorization service returning an extra >>>>>>> property, the >>>>>>> id_token which can be sufficient in order to get the authenticated >>>>>>> user's info. >>>>>>> >>>>>>> My understanding "OAuth2 != OpenidConnect", the latter utilizes the >>>>>>> former and is an authentication mechanism which is not what >>>>>>> OAuth2 is >>>>>>> (may be except for the client credentials). But I don't feel like >>>>>>> it is >>>>>>> a convincing enough argument. >>>>>>> >>>>>>> I thought this thread was relevant, sorry if not, would have no >>>>>>> problems >>>>>>> starting a new one. >>>>>>> >>>>>>> Basically, I wonder what is the proper line of argument for a >>>>>>> position >>>>>>> such as "OAuth2 != OpenidConnect" and also what was the action to >>>>>>> the >>>>>>> list of options suggested by John below. Is having an OID profile >>>>>>> where >>>>>>> no access token is returned would be the cleanest action as far as >>>>>>> breaking the ambiguity/confusion is concerned ? >>>>>>> >>>>>>> Cheers, Sergey >>>>>>> >>>>>>> On 24/07/14 15:25, John Bradley wrote: >>>>>>> > I am not against discussion in the WG. >>>>>>> > >>>>>>> > I happen to agree with Phil's fundamental premise that some >>>>>>> developers >>>>>>> > are using OAuth in a insecure way to do authentication. >>>>>>> > >>>>>>> > That raises the question of how to best educate them, and or >>>>>>> address >>>>>>> > technical barriers. >>>>>>> > >>>>>>> > It is on the second point that people's opinions seem to divide. >>>>>>> > >>>>>>> > Some people thing that if we have a OAuth flow that >>>>>>> eliminates the >>>>>>> > access token (primarily to avoid asking for consent as I >>>>>> understand it) >>>>>>> > and just return a id_token from the token endpoint that can be >>>>>> done in a >>>>>>> > spec short enough to het people to read. The subtext of >>>>>>> this is that >>>>>>> > the Connect specification is too large that it scare people, >>>>>>> and they >>>>>>> > don't find the spec in the first place because it is not a RFC. >>>>>>> > >>>>>>> > An other common possession is that if you don't want to >>>>>>> prompt the >>>>>> user >>>>>>> > for consent then don't ask for scopes. Twisting the OAuth >>>>>>> spec to not >>>>>>> > return an access token is not OAuth, yes you could use a >>>>>>> different >>>>>>> > endpoint rather than the token endpoint, but that is not OAuth. >>>>>>> > Connect was careful not to break the OAuth spec. As long >>>>>>> as you are >>>>>>> > willing to take a access token with no scopes (the client >>>>>>> needs to >>>>>>> > understand that there are no attributes one way or another >>>>>>> anyway >>>>>> or it >>>>>>> > will break) then you don't need to change OAuth. You can >>>>>>> publish a >>>>>>> > profile of connect that satisfies the use case. >>>>>>> > >>>>>>> > I think Mike has largely done that but it might be better >>>>>>> being less >>>>>>> > stingy on references back to the larger spec. >>>>>>> > >>>>>>> > The questions are do we modify OAuth to not return an access >>>>>> token, and >>>>>>> > if so how, and if we do is it still OAuth. >>>>>>> > >>>>>>> > The other largely separable question is do we create >>>>>>> confusion in the >>>>>>> > market and slow the the adoption of identity federation on >>>>>>> top of >>>>>> OAuth, >>>>>>> > or find a way to make this look like a positive alignment of >>>>>>> interests >>>>>>> > around a subset of Connect. >>>>>>> > >>>>>>> > There are a number of options. >>>>>>> > 1: We can do a profile in the OIDF and publish it as a IETF >>>>>>> document. >>>>>>> > Perhaps the cleanest from an IPR point of view.However >>>>>>> > 2:We can do a profile in the OAuth WG referencing connect. >>>>>>> > 3:We can do a AD sponsored profile that is not in the OAuth WG. >>>>>>> > 4:We can do a small spec in OAuth to add response_type to the >>>>>>> token >>>>>>> > endpoint. in combination with 1, 2, or 3 >>>>>>> > >>>>>>> > I agree that stoping developers doing insecure things needs >>>>>>> to be >>>>>>> > addressed somehow. >>>>>>> > I am not personally convinced that Oauth without access >>>>>>> tokens is >>>>>>> sensible. >>>>>>> > >>>>>>> > Looking forward to the meeting:) >>>>>>> > >>>>>>> > John B. >>>>>>> > On Jul 24, 2014, at 6:52 AM, Brian Campbell >>>>>> >>>>>> > > wrote: >>>>>>> > >>>>>>> >> I'd note that the reaction at the conference to Ian's >>>>>>> statement was >>>>>>> >> overwhelmingly positive. There was a wide range of industry >>>>>>> people >>>>>>> >> here - implementers, practitioners, deployers, strategists, >>>>>>> etc. >>>>>> - and >>>>>>> >> it seems pretty clear that the "rough consensus" of the >>>>>>> industry at >>>>>>> >> large is that a4c is not wanted or needed. >>>>>>> >> >>>>>>> >> >>>>>>> >> On Thu, Jul 24, 2014 at 5:29 AM, Nat Sakimura >>>>>>> >>>>>> >> > wrote: >>>>>>> >> >>>>>>> >> And here is a quote from Ian's blog. >>>>>>> >> >>>>>>> >> And although the authentication wheel is round, that >>>>>>> doesn’t >>>>>>> >> mean it isn’t without its lumps. First, we do see some >>>>>>> >> reinventing the wheel just to reinvent the wheel. OAuth >>>>>> A4C is >>>>>>> >> simply not a fruitful activity and should be put down. >>>>>>> >> >>>>>>> >> (Source) >>>>>>> >> >>>>>>> >>>>>> http://www.tuesdaynight.org/2014/07/23/do-we-have-a-round-wheel-yet-musings-on-identity-standards-part-1.html >>>>>> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> >> 2014-07-23 16:53 GMT-04:00 John Bradley >>>>>> >> >: >>>>>>> >> >>>>>>> >> I thought I did post this to the list. >>>>>>> >> >>>>>>> >> I guess I hit the wrong reply on my phone. >>>>>>> >> John B. >>>>>>> >> Sent from my iPhone >>>>>>> >> >>>>>>> >> On Jul 23, 2014, at 4:50 PM, torsten@lodderstedt.net >>>>>>> >> wrote: >>>>>>> >> >>>>>>> >>> we are two, at least :-) >>>>>>> >>> >>>>>>> >>> Why didn't you post this on the list? >>>>>>> >>> >>>>>>> >>> When will be be arriving? >>>>>>> >>> >>>>>>> >>> Am 23.07.2014 16:39, schrieb John Bradley: >>>>>>> >>> >>>>>>> >>>> Ian Glazer mentioned this in his keynote at CIS >>>>>>> yesterday. >>>>>>> >>>> His advice was please stop, we are creating >>>>>>> confusion and >>>>>>> >>>> uncertainty. >>>>>>> >>>> We are becoming our own wort enemy. ( my view though >>>>>> Ian may >>>>>>> >>>> share it) >>>>>>> >>>> Returning just an id_ token from the token >>>>>>> endpoint has >>>>>>> >>>> little real value. >>>>>>> >>>> Something really useful to do would be sorting out >>>>>>> >>>> channel_id so we can do PoP for id tokens to make >>>>>>> them and >>>>>>> >>>> other cookies secure in the front channel. I think >>>>>> that is >>>>>>> >>>> a better use of time. >>>>>>> >>>> I may be in the minority opinion on that, it >>>>>>> won't be the >>>>>>> >>>> first time. >>>>>>> >>>> >>>>>>> >>>> >>>>>>> >>>> John B. >>>>>>> >>>> Sent from my iPhone >>>>>>> >>>> >>>>>>> >>>> On Jul 23, 2014, at 4:04 PM, Torsten Lodderstedt >>>>>>> >>>> >>>>>> > >>>>>>> >>>> wrote: >>>>>>> >>>> >>>>>>> >>>>> You are right from a theoretical perspective. >>>>>>> Practically >>>>>>> >>>>> this was caused by editorial decisions during the >>>>>>> creation >>>>>>> >>>>> of the RFC. As far as I remember, there was a >>>>>> definition of >>>>>>> >>>>> the (one) token endpoint response in early versions. >>>>>> No one >>>>>>> >>>>> every considered to NOT respond with an access >>>>>>> token from >>>>>>> >>>>> the token endpoint. So one might call it an implicit >>>>>>> >>>>> assumption. >>>>>>> >>>>> I'm worried that people get totally confused if an >>>>>>> >>>>> exception is introduced now given the broad >>>>>>> adoption of >>>>>>> >>>>> OAuth based on this assumption. >>>>>>> >>>>> regards, >>>>>>> >>>>> Torsten. >>>>>>> >>>>> >>>>>>> >>>>> Am 23.07.2014 um 15:41 schrieb Thomas Broyer >>>>>>> >>>>> >: >>>>>>> >>>>> >>>>>>> >>>>>> Is it said anywhere that ALL grant types MUST >>>>>>> use Section >>>>>>> >>>>>> 5.1 responses? Each grant type references Section >>>>>> 5.1, and >>>>>>> >>>>>> "access token request" is only defined in the >>>>>>> context of >>>>>>> >>>>>> the defined grant types. Section 2.2 doesn't >>>>>>> talk about >>>>>>> >>>>>> the request or response format. >>>>>>> >>>>>> >>>>>>> >>>>>> Le 23 juil. 2014 21:32, "Nat Sakimura" >>>>>> >>>>>> >>>>>> > a écrit : >>>>>>> >>>>>> >>>>>>> >>>>>> Is it? Apart from the implicit grant that does >>>>>> not use >>>>>>> >>>>>> token endpoint, all other grant references >>>>>> section 5.1 >>>>>>> >>>>>> for the response, i.e., all shares the same >>>>>>> response. >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> 2014-07-23 15:18 GMT-04:00 Thomas Broyer >>>>>>> >>>>>> >>>>>> >: >>>>>>> >>>>>> >>>>>>> >>>>>> I hadn't realized the JSON response that >>>>>>> requires >>>>>>> >>>>>> the access_token field is defined per >>>>>>> grant_type, >>>>>>> >>>>>> so I'd be OK to "extend the semantics" >>>>>>> as in the >>>>>>> >>>>>> current draft. >>>>>>> >>>>>> That was actually my main concern: that >>>>>>> the token >>>>>>> >>>>>> endpoint mandates access_token; but its >>>>>>> actually >>>>>>> >>>>>> not the case. >>>>>>> >>>>>> >>>>>>> >>>>>> Le 23 juil. 2014 20:46, "Nat Sakimura" >>>>>>> >>>>>> >>>>> > a >>>>>>> >>>>>> écrit : >>>>>>> >>>>>> >>>>>>> >>>>>> I agree with John that overloading >>>>>>> >>>>>> response_type @ authz endpoint is a >>>>>>> bad idea. >>>>>>> >>>>>> It completely changes the semantics >>>>>>> of this >>>>>>> >>>>>> parameter. NOTE: what I was >>>>>>> proposing was not >>>>>>> >>>>>> this parameter, but a new parameter >>>>>>> >>>>>> response_type @ token endpoint. >>>>>>> >>>>>> I also think overloading grant_type >>>>>>> is a bad >>>>>>> >>>>>> idea since it changes its semantics. >>>>>>> I quote >>>>>>> >>>>>> the definition here again: >>>>>>> >>>>>> grant >>>>>>> >>>>>> credential representing the >>>>>>> resource >>>>>>> >>>>>> owner's authorization >>>>>>> >>>>>> grant_type >>>>>>> >>>>>> type of grant sent to the token >>>>>>> endpoint to >>>>>>> >>>>>> obtain the access token >>>>>>> >>>>>> It is not about controlling what is >>>>>>> to be >>>>>>> >>>>>> returned from the token endpoint, >>>>>>> but the >>>>>> hint >>>>>>> >>>>>> to the token endpoint describing the >>>>>>> type of >>>>>>> >>>>>> credential the endpoint has >>>>>>> received. It >>>>>> seems >>>>>>> >>>>>> the "control of what is being >>>>>>> returned from >>>>>>> >>>>>> token endpoint" is just a side effect. >>>>>>> >>>>>> I am somewhat ambivalent[1] in >>>>>>> changing the >>>>>>> >>>>>> semantics of token endpoint, but in as >>>>>> much as >>>>>>> >>>>>> "text is the king" for a spec., we >>>>>>> probably >>>>>>> >>>>>> should not change the semantics of >>>>>>> it as >>>>>>> >>>>>> Torsten points out. If it is ok to >>>>>>> change >>>>>> this >>>>>>> >>>>>> semantics, I believe defining a new >>>>>>> parameter >>>>>>> >>>>>> to this endpoint to control the >>>>>>> response >>>>>> would >>>>>>> >>>>>> be the best way to go. This is what >>>>>>> I have >>>>>>> >>>>>> described previously. >>>>>>> >>>>>> Defining a new endpoint to send code to >>>>>> get ID >>>>>>> >>>>>> Token and forbidding the use of it >>>>>>> against >>>>>>> >>>>>> token endpoint would not change the >>>>>>> semantics >>>>>>> >>>>>> of any existing parameter or >>>>>>> endpoint, which >>>>>>> >>>>>> is good. However, I doubt if it is >>>>>>> not worth >>>>>>> >>>>>> doing. What's the point of avoiding >>>>>>> access >>>>>>> >>>>>> token scoped to UserInfo endpoint >>>>>>> after all? >>>>>>> >>>>>> Defining a new endpoint for just >>>>>>> avoiding the >>>>>>> >>>>>> access token for userinfo endpoint >>>>>>> seems way >>>>>>> >>>>>> too much the heavy wait way and it >>>>>>> breaks >>>>>>> >>>>>> interoperabiliy: it defeats the >>>>>>> purpose of >>>>>>> >>>>>> standardization. >>>>>>> >>>>>> I have started feeling that no >>>>>>> change is the >>>>>>> >>>>>> best way out. >>>>>>> >>>>>> Nat >>>>>>> >>>>>> [1] If instead of saying "Token >>>>>>> endpoint - >>>>>>> >>>>>> used by the client to exchange an >>>>>>> >>>>>> authorization grant for an access >>>>>>> token, >>>>>>> >>>>>> typically with client >>>>>>> authentication", it >>>>>> were >>>>>>> >>>>>> saying "Token endpoint - used by the >>>>>> client to >>>>>>> >>>>>> exchange an authorization grant for >>>>>>> tokens, >>>>>>> >>>>>> typically with client authentication", >>>>>> then it >>>>>>> >>>>>> would have been OK. It is an >>>>>>> expansion of the >>>>>>> >>>>>> capability rather than changing the >>>>>> semantics. >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> 2014-07-23 13:39 GMT-04:00 Mike Jones >>>>>>> >>>>>> >>>>>> >>>>>> >: >>>>>>> >>>>>> >>>>>>> >>>>>> You need the alternative >>>>>>> response_type >>>>>>> >>>>>> value ("code_for_id_token" in >>>>>>> the A4C >>>>>>> >>>>>> draft) to tell the Authorization >>>>>> Server to >>>>>>> >>>>>> return a code to be used with >>>>>>> the new >>>>>>> >>>>>> grant type, rather than one to >>>>>>> use with >>>>>>> >>>>>> the "authorization_code" grant type >>>>>> (which >>>>>>> >>>>>> is what response_type=code does). >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> *From:*OAuth >>>>>>> >>>>>> [mailto:oauth-bounces@ietf.org >>>>>>> >>>>>> ] >>>>>>> *On >>>>>>> >>>>>> Behalf Of *John Bradley >>>>>>> >>>>>> *Sent:* Wednesday, July 23, 2014 >>>>>>> 10:33 AM >>>>>>> >>>>>> *To:* torsten@lodderstedt.net >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> *Cc:* oauth@ietf.org >>>>>> >>>>>>> >>>>>> *Subject:* Re: [OAUTH-WG] New >>>>>>> Version >>>>>>> >>>>>> Notification for >>>>>>> >>>>>> draft-hunt-oauth-v2-user-a4c-05.txt >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> If we use the token endpoint >>>>>>> then a new >>>>>>> >>>>>> grant_type is the best way. >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> It sort of overloads code, but >>>>>>> that is >>>>>>> >>>>>> better than messing with >>>>>> response_type for >>>>>>> >>>>>> the authorization endpoint to >>>>>>> change the >>>>>>> >>>>>> response from the token_endpoint. >>>>>> That is >>>>>>> >>>>>> in my opinion a champion bad idea. >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> In discussions developing >>>>>>> Connect we >>>>>>> >>>>>> decided not to open this can of >>>>>>> worms >>>>>>> >>>>>> because no good would come of it. >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> The token_endpoint returns a access >>>>>> token. >>>>>>> >>>>>> Nothing requires scope to be >>>>>>> associates >>>>>>> >>>>>> with the token. >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> That is the best solution. No >>>>>>> change >>>>>>> >>>>>> required. Better >>>>>>> interoperability in my >>>>>>> >>>>>> opinion. >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> Still on my way to TO, getting >>>>>>> in later >>>>>>> >>>>>> today. >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> John B. >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> Sent from my iPhone >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> On Jul 23, 2014, at 12:15 PM, >>>>>>> >>>>>> torsten@lodderstedt.net >>>>>>> >>>>>> >>>>>>> wrote: >>>>>>> >>>>>> >>>>>>> >>>>>> The "response type" of the >>>>>>> token >>>>>>> >>>>>> endpoint is controlled by the >>>>>> value of >>>>>>> >>>>>> the parameter "grant_type". >>>>>>> So there >>>>>>> >>>>>> is no need to introduce a new >>>>>> parameter. >>>>>>> >>>>>> >>>>>>> >>>>>> wrt to a potential >>>>>>> "no_access_token" >>>>>>> >>>>>> grant type. I do not >>>>>>> consider this a >>>>>>> >>>>>> good idea as it changes the >>>>>>> semantics >>>>>>> >>>>>> of the token endpoint (as >>>>>>> already >>>>>>> >>>>>> pointed out by Thomas). This >>>>>>> endpoint >>>>>>> >>>>>> ALWAYS responds with an >>>>>>> access token >>>>>>> >>>>>> to any grant type. I >>>>>>> therefore would >>>>>>> >>>>>> prefer to use another endpoint >>>>>> for the >>>>>>> >>>>>> intended purpose. >>>>>>> >>>>>> >>>>>>> >>>>>> regards, >>>>>>> >>>>>> Torsten. >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> Am 23.07.2014 13:04, schrieb >>>>>>> Nat >>>>>>> Sakimura: >>>>>>> >>>>>> >>>>>>> >>>>>> IMHO, changing the >>>>>>> semantics of >>>>>>> >>>>>> "response_type" @ authz >>>>>>> endpoint >>>>>>> >>>>>> this way is not a good >>>>>>> thing. >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> Instead, defining a new >>>>>>> parameter >>>>>>> >>>>>> "response_type" @ token >>>>>>> endpoint, >>>>>>> >>>>>> as I described in my >>>>>>> previous >>>>>>> >>>>>> message, >>>>>>> >>>>>> >>>>>>> >>>>>> probably is better. At >>>>>>> least, it >>>>>>> >>>>>> does not change the >>>>>>> semantics of >>>>>>> >>>>>> the parameters of RFC6749. >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> Nat >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> 2014-07-23 12:48 >>>>>>> GMT-04:00 Thomas >>>>>>> >>>>>> Broyer >>>>>> >>>>>> >>>>>>> >: >>>>>>> >>>>>> >>>>>>> >>>>>> No, I mean >>>>>>> response_type=none and >>>>>>> >>>>>> response_type=id_token >>>>>>> don't >>>>>>> >>>>>> generate a code or access >>>>>> token so >>>>>>> >>>>>> you don't use the Token >>>>>>> Endpoint >>>>>>> >>>>>> (which is not the same >>>>>>> as the >>>>>>> >>>>>> Authentication Endpoint >>>>>>> BTW). >>>>>>> >>>>>> >>>>>>> >>>>>> With >>>>>>> >>>>>> >>>>>>> response_type=code_for_id_token, >>>>>>> >>>>>> you get a code and exchange >>>>>> it for >>>>>>> >>>>>> an id_token only, rather >>>>>>> than an >>>>>>> >>>>>> access_token, so you're >>>>>>> changing >>>>>>> >>>>>> the semantics of the Token >>>>>> Endpoint. >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> I'm not saying it's a >>>>>>> bad thing, >>>>>>> >>>>>> just that you can't really >>>>>> compare >>>>>>> >>>>>> none and id_token with >>>>>>> >>>>>> code_for_id_token. >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> On Wed, Jul 23, 2014 at >>>>>>> 6:45 PM, >>>>>>> >>>>>> Richer, Justin P. >>>>>>> >>>>>> >>>>>> >>>>>> > >>>>>> wrote: >>>>>>> >>>>>> >>>>>>> >>>>>> It's only "not using the >>>>>>> token >>>>>>> >>>>>> endpoint" because the token >>>>>>> >>>>>> endpoint copy-pasted and >>>>>>> renamed >>>>>>> >>>>>> the authentication >>>>>>> endpoint. >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> -- Justin >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> On Jul 23, 2014, at 9:30 >>>>>>> AM, >>>>>>> >>>>>> Thomas Broyer >>>>>>> >>>>>> >>>>>> >>>>>>> > >>>>>> wrote: >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> Except that these are >>>>>>> about not >>>>>>> >>>>>> using the Token Endpoint >>>>>>> at all, >>>>>>> >>>>>> whereas the current >>>>>>> proposal is >>>>>>> >>>>>> about the Token Endpoint >>>>>>> not >>>>>>> >>>>>> returning an access_token >>>>>> field in >>>>>>> >>>>>> the JSON. >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> On Wed, Jul 23, 2014 at >>>>>>> 4:26 PM, >>>>>>> >>>>>> Mike Jones >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>> >>>>>>> > >>>>>>> >>>>>> wrote: >>>>>>> >>>>>> >>>>>>> >>>>>> The response_type "none" is >>>>>>> >>>>>> already used in >>>>>>> practice, which >>>>>>> >>>>>> returns no access >>>>>>> token. It was >>>>>>> >>>>>> accepted by the designated >>>>>> experts >>>>>>> >>>>>> and registered in the >>>>>>> IANA OAuth >>>>>>> >>>>>> Authorization Endpoint >>>>>>> Response >>>>>>> >>>>>> Types registry at >>>>>>> >>>>>> >>>>>>> >>>>>> http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml#endpoint >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> . >>>>>> >>>>>>> >>>>>> The registered "id_token" >>>>>> response >>>>>>> >>>>>> type also returns no access >>>>>> token. >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> So I think the question of >>>>>> whether >>>>>>> >>>>>> response types that >>>>>>> result in no >>>>>>> >>>>>> access token being >>>>>>> returned are >>>>>>> >>>>>> acceptable within OAuth >>>>>>> 2.0 is >>>>>>> >>>>>> already settled, as a >>>>>>> practical >>>>>>> >>>>>> matter. Lots of OAuth >>>>>>> >>>>>> implementations are >>>>>>> already using >>>>>>> >>>>>> such response types. >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> -- Mike >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> *From:*OAuth >>>>>>> >>>>>> >>>>>>> [mailto:oauth-bounces@ietf.org >>>>>>> >>>>>> >>>>>>> ] >>>>>>> >>>>>> *On Behalf Of *Phil Hunt >>>>>>> >>>>>> *Sent:* Wednesday, July >>>>>>> 23, 2014 >>>>>>> >>>>>> 7:09 AM >>>>>>> >>>>>> *To:* Nat Sakimura >>>>>>> >>>>>> *Cc:* >>>>>> >>>>>> > >>>>>>> >>>>>> *Subject:* Re: >>>>>>> [OAUTH-WG] New >>>>>>> >>>>>> Version Notification for >>>>>>> >>>>>> >>>>>> draft-hunt-oauth-v2-user-a4c-05.txt >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> Yes. This is why it has >>>>>>> to be >>>>>>> >>>>>> discussed in the IETF. >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> Phil >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> @independentid >>>>>>> >>>>>> >>>>>>> >>>>>> www.independentid.com >>>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> phil.hunt@oracle.com >>>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> On Jul 23, 2014, at 9:43 >>>>>>> AM, Nat >>>>>>> >>>>>> Sakimura >>>>>>> >>>>>> >>>>>> >>>>>>> > >>>>>> wrote: >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> Reading back the RFC6749, I >>>>>> am not >>>>>>> >>>>>> sure if there is a good >>>>>>> way of >>>>>>> >>>>>> suppressing access token >>>>>>> from the >>>>>>> >>>>>> response and still be >>>>>>> OAuth. It >>>>>>> >>>>>> will break whole bunch of >>>>>> implicit >>>>>>> >>>>>> definitions like: >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> authorization server >>>>>>> >>>>>> The server issuing >>>>>>> access >>>>>>> >>>>>> tokens to the client after >>>>>>> >>>>>> successfully >>>>>>> >>>>>> authenticating the >>>>>>> resource >>>>>>> >>>>>> owner and obtaining >>>>>> authorization. >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> After all, OAuth is all >>>>>>> about >>>>>>> >>>>>> issuing access tokens. >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> Also, I take back my >>>>>>> statement on >>>>>>> >>>>>> the grant type in my >>>>>>> previous >>>>>> mail. >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> The definition of grant and >>>>>>> >>>>>> grant_type are >>>>>>> respectively: >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> grant >>>>>>> >>>>>> >>>>>>> >>>>>> credential >>>>>>> representing the >>>>>>> >>>>>> resource owner's >>>>>>> authorization >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> grant_type >>>>>>> >>>>>> >>>>>>> >>>>>> (string representing >>>>>>> the) >>>>>> type >>>>>>> >>>>>> of grant sent to the token >>>>>>> >>>>>> endpoint to obtain the >>>>>>> access >>>>>> token >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> Thus, the grant sent to >>>>>>> the token >>>>>>> >>>>>> endpoint in this case is >>>>>>> still >>>>>>> >>>>>> 'code'. >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> Response type on the other >>>>>> hand is >>>>>>> >>>>>> not so well defined in >>>>>>> RFC6749, >>>>>>> >>>>>> but it seems it is >>>>>>> representing >>>>>>> >>>>>> what is to be returned >>>>>>> from the >>>>>>> >>>>>> authorization endpoint. To >>>>>> express >>>>>>> >>>>>> what is to be returned >>>>>>> from token >>>>>>> >>>>>> endpoint, perhaps >>>>>>> defining a new >>>>>>> >>>>>> parameter to the token >>>>>>> endpoint, >>>>>>> >>>>>> which is a parallel to the >>>>>>> >>>>>> response_type to the >>>>>> Authorization >>>>>>> >>>>>> Endpoint seems to be a more >>>>>>> >>>>>> symmetric way, though I >>>>>>> am not >>>>>>> >>>>>> sure at all if that is >>>>>>> going >>>>>> to be >>>>>>> >>>>>> OAuth any more. One >>>>>>> straw-man is >>>>>>> >>>>>> to define a new >>>>>>> parameter called >>>>>>> >>>>>> response_type to the token >>>>>>> >>>>>> endpoint such as: >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> response_type >>>>>>> >>>>>> >>>>>>> >>>>>> OPTIONAL. A string >>>>>>> >>>>>> representing what is to be >>>>>>> >>>>>> returned from the token >>>>>>> endpoint. >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> Then define the behavior >>>>>>> of the >>>>>>> >>>>>> endpoint according to >>>>>>> the values >>>>>>> >>>>>> as the parallel to the >>>>>>> >>>>>> multi-response type spec. >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> Nat >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> 2014-07-23 7:21 >>>>>>> GMT-04:00 Phil >>>>>>> >>>>>> Hunt >>>>>> >>>>>> >>>>>>> >: >>>>>>> >>>>>> >>>>>>> >>>>>> The draft is very clear. >>>>>>> >>>>>> >>>>>>> >>>>>> Phil >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> On Jul 23, 2014, at >>>>>>> 0:46, Nat >>>>>>> >>>>>> Sakimura >>>>>>> >>>>>> >>>>>> >>>>>>> > >>>>>> wrote: >>>>>>> >>>>>> >>>>>>> >>>>>> The new grant type >>>>>>> that I was >>>>>>> >>>>>> talking about was >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> "authorization_code_but_do_not_return_access_nor_refresh_token", >>>>>>> >>>>>> so to speak. >>>>>>> >>>>>> >>>>>>> >>>>>> It does not return >>>>>>> anything >>>>>>> >>>>>> per se, but an >>>>>>> extension can >>>>>>> >>>>>> define something on top >>>>>> of it. >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> Then, OIDC can define a >>>>>>> >>>>>> binding to it so >>>>>>> that the >>>>>>> >>>>>> binding only returns ID >>>>>> Token. >>>>>>> >>>>>> >>>>>>> >>>>>> This binding work >>>>>>> should be >>>>>>> >>>>>> done in OIDF. Should >>>>>>> there be >>>>>>> >>>>>> such a grant type, >>>>>>> >>>>>> >>>>>>> >>>>>> it will be an >>>>>>> extremely short >>>>>>> >>>>>> spec. >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> At the same time, if >>>>>>> any >>>>>> other >>>>>>> >>>>>> specification wanted to >>>>>> define >>>>>>> >>>>>> >>>>>>> >>>>>> other type of tokens >>>>>>> and have >>>>>>> >>>>>> it returned from the >>>>>>> token >>>>>>> >>>>>> endpoint, >>>>>>> >>>>>> >>>>>>> >>>>>> it can also use this >>>>>> grant type. >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> If what you want is >>>>>>> to define >>>>>>> >>>>>> a new grant type >>>>>>> that returns >>>>>>> >>>>>> ID Token only, >>>>>>> >>>>>> >>>>>>> >>>>>> then, I am with >>>>>>> Justin. Since >>>>>>> >>>>>> "other response than ID >>>>>> Token" >>>>>>> >>>>>> is only >>>>>>> >>>>>> >>>>>>> >>>>>> theoretical, this is >>>>>>> a more >>>>>>> >>>>>> plausible way >>>>>>> forward, I >>>>>>> suppose. >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> Nat >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> 2014-07-22 14:30 >>>>>>> GMT-04:00 >>>>>>> >>>>>> Justin Richer >>>>>> >>>>>> >>>>>> >>>>>>> >: >>>>>>> >>>>>> >>>>>>> >>>>>> So the draft would >>>>>>> literally >>>>>>> >>>>>> turn into: >>>>>>> >>>>>> >>>>>>> >>>>>> "The a4c response >>>>>>> type and >>>>>>> >>>>>> grant type return an >>>>>>> id_token >>>>>>> >>>>>> from the token >>>>>>> endpoint with >>>>>>> >>>>>> no access token. All >>>>>>> >>>>>> parameters and >>>>>>> values are >>>>>>> >>>>>> defined in OIDC." >>>>>>> >>>>>> >>>>>>> >>>>>> Seems like the >>>>>>> perfect mini >>>>>>> >>>>>> extension draft for >>>>>>> OIDF >>>>>> to do. >>>>>>> >>>>>> >>>>>>> >>>>>> --Justin >>>>>>> >>>>>> >>>>>>> >>>>>> /sent from my phone/ >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> On Jul 22, 2014 >>>>>>> 10:29 AM, Nat >>>>>>> >>>>>> Sakimura >>>>>>> >>>>>> >>>>>> >>>>>>> > >>>>>>> >>>>>> wrote: >>>>>>> >>>>>> > >>>>>>> >>>>>> > What about just >>>>>>> defining a >>>>>>> >>>>>> new grant type in >>>>>>> this WG? >>>>>>> >>>>>> > >>>>>>> >>>>>> > >>>>>>> >>>>>> > 2014-07-22 12:56 >>>>>>> GMT-04:00 >>>>>>> >>>>>> Phil Hunt >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >: >>>>>>> >>>>>> >> >>>>>>> >>>>>> >> That would be nice. >>>>>> However >>>>>>> >>>>>> oidc still needs the >>>>>>> new >>>>>> grant >>>>>>> >>>>>> type in order to >>>>>> implement the >>>>>>> >>>>>> same flow. >>>>>>> >>>>>> >> >>>>>>> >>>>>> >> Phil >>>>>>> >>>>>> >> >>>>>>> >>>>>> >> On Jul 22, 2014, >>>>>>> at 11:35, >>>>>>> >>>>>> Nat Sakimura >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> > >>>>>>> >>>>>> wrote: >>>>>>> >>>>>> >> >>>>>>> >>>>>> >>> +1 to Justin. >>>>>>> >>>>>> >>> >>>>>>> >>>>>> >>> >>>>>>> >>>>>> >>> 2014-07-22 9:54 >>>>>>> GMT-04:00 >>>>>>> >>>>>> Richer, Justin P. >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> >: >>>>>>> >>>>>> >>>> >>>>>>> >>>>>> >>>> Errors like these >>>>>> make it >>>>>>> >>>>>> clear to me that it >>>>>>> would >>>>>> make >>>>>>> >>>>>> much more sense to >>>>>>> develop >>>>>>> >>>>>> this document in the >>>>>>> OpenID >>>>>>> >>>>>> Foundation. It >>>>>>> should be >>>>>>> >>>>>> something that directly >>>>>>> >>>>>> references OpenID >>>>>>> Connect >>>>>> Core >>>>>>> >>>>>> for all of these terms >>>>>> instead >>>>>>> >>>>>> of redefining them. >>>>>>> It's >>>>>> doing >>>>>>> >>>>>> authentication, >>>>>>> which is >>>>>>> >>>>>> fundamentally what >>>>>>> OpenID >>>>>>> >>>>>> Connect does on top >>>>>>> of OAuth, >>>>>>> >>>>>> and I don't see a good >>>>>>> >>>>>> argument for doing >>>>>>> this work >>>>>>> >>>>>> in this working group. >>>>>>> >>>>>> >>>> >>>>>>> >>>>>> >>>> -- Justin >>>>>>> >>>>>> >>>> >>>>>>> >>>>>> >>>> On Jul 22, >>>>>>> 2014, at 4:30 >>>>>>> >>>>>> AM, Thomas Broyer >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> > >>>>>>> >>>>>> wrote: >>>>>>> >>>>>> >>>> >>>>>>> >>>>>> >>>>> >>>>>>> >>>>>> >>>>> >>>>>>> >>>>>> >>>>> >>>>>>> >>>>>> >>>>> On Mon, Jul >>>>>>> 21, 2014 at >>>>>>> >>>>>> 11:52 PM, Mike Jones >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>> >>>>>>> > >>>>>>> >>>>>> wrote: >>>>>>> >>>>>> >>>>>> >>>>>>> >>>>>> >>>>>> Thanks for your >>>>>> review, >>>>>>> >>>>>> Thomas. The >>>>>>> "prompt=consent" >>>>>>> >>>>>> definition being >>>>>>> missing >>>>>> is an >>>>>>> >>>>>> editorial error. It >>>>>> should be: >>>>>>> >>>>>> >>>>>> >>>>>>> >>>>>> >>>>>> >>>>>>> >>>>>> >>>>>> >>>>>>> >>>>>> >>>>>> consent >>>>>>> >>>>>> >>>>>> >>>>>>> >>>>>> >>>>>> The >>>>>>> Authorization >>>>>>> >>>>>> Server SHOULD prompt >>>>>>> the >>>>>>> >>>>>> End-User for consent >>>>>>> before >>>>>>> >>>>>> returning >>>>>>> information to the >>>>>>> >>>>>> Client. If it cannot >>>>>>> obtain >>>>>>> >>>>>> consent, it MUST >>>>>>> return an >>>>>>> >>>>>> error, typically >>>>>>> consent_required. >>>>>>> >>>>>> >>>>>> >>>>>>> >>>>>> >>>>>> >>>>>>> >>>>>> >>>>>> >>>>>>> >>>>>> >>>>>> I'll plan to >>>>>>> add it in >>>>>>> >>>>>> the next draft. >>>>>>> >>>>>> >>>>> >>>>>>> >>>>>> >>>>> >>>>>>> >>>>>> >>>>> It looks like the >>>>>>> >>>>>> consent_required >>>>>>> error needs >>>>>>> >>>>>> to be defined too, >>>>>>> and you >>>>>>> >>>>>> might have forgotten >>>>>>> to also >>>>>>> >>>>>> import >>>>>>> >>>>>> >>>>>>> account_selection_required >>>>>>> >>>>>> from OpenID Connect. >>>>>>> >>>>>> >>>>> >>>>>>> >>>>>> >>>>>> >>>>>>> >>>>>> >>>>>> >>>>>>> >>>>>> >>>>>> >>>>>>> >>>>>> >>>>>> I agree that >>>>>> there's no >>>>>>> >>>>>> difference between a >>>>>>> response >>>>>>> >>>>>> with multiple "amr" >>>>>>> values >>>>>>> >>>>>> that includes "mfa" >>>>>>> and one >>>>>>> >>>>>> that doesn't. >>>>>>> Unless a clear >>>>>>> >>>>>> use case for why >>>>>>> "mfa" is >>>>>>> >>>>>> needed can be >>>>>>> identified, we >>>>>>> >>>>>> can delete it in the >>>>>>> next >>>>>> draft. >>>>>>> >>>>>> >>>>> >>>>>>> >>>>>> >>>>> >>>>>>> >>>>>> >>>>> Thanks. >>>>>>> >>>>>> >>>>> >>>>>>> >>>>>> >>>>> How about >>>>>>> "pwd" then? I >>>>>>> >>>>>> fully understand that I >>>>>> should >>>>>>> >>>>>> return "pwd" if the >>>>>>> user >>>>>>> >>>>>> authenticated using a >>>>>>> >>>>>> password, but what "the >>>>>>> >>>>>> service if a client >>>>>>> secret is >>>>>>> >>>>>> used" means in the >>>>>>> definition >>>>>>> >>>>>> for the "pwd" value? >>>>>>> >>>>>> >>>>> >>>>>>> >>>>>> >>>>> (Nota: I know >>>>>>> you're at >>>>>>> >>>>>> IETF-90, I'm ready >>>>>>> to wait >>>>>>> >>>>>> 'til you come back >>>>>>> ;-) ) >>>>>>> >>>>>> >>>>> >>>>>>> >>>>>> >>>>> -- >>>>>>> >>>>>> >>>>> Thomas Broyer >>>>>>> >>>>>> >>>>> /tɔ.ma.bʁwa.je/ >>>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>>>> >>>>>> >>>>>>> _______________________________________________ >>>>>>> >>>>>> >>>>> 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 >>>>>>> >>>>>> >>>> >>>>>>> >>>>>> >>> >>>>>>> >>>>>> >>> >>>>>>> >>>>>> >>> >>>>>>> >>>>>> >>> -- >>>>>>> >>>>>> >>> Nat Sakimura (=nat) >>>>>>> >>>>>> >>> Chairman, OpenID >>>>>> Foundation >>>>>>> >>>>>> >>> >>>>>>> http://nat.sakimura.org/ >>>>>>> >>>>>> >>> @_nat_en >>>>>>> >>>>>> >>> >>>>>>> >>>>>> >>> >>>>>>> >>>>>> >>>>>>> _______________________________________________ >>>>>>> >>>>>> >>> OAuth mailing list >>>>>>> >>>>>> >>> OAuth@ietf.org >>>>>>> >>>>>> >>>>>>> >>>>>> >>> >>>>>>> >>>>>> >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >>>>>> > >>>>>>> >>>>>> > >>>>>>> >>>>>> > >>>>>>> >>>>>> > >>>>>>> >>>>>> > -- >>>>>>> >>>>>> > Nat Sakimura (=nat) >>>>>>> >>>>>> > Chairman, OpenID >>>>>>> Foundation >>>>>>> >>>>>> > >>>>>>> http://nat.sakimura.org/ >>>>>>> >>>>>> > @_nat_en >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> -- >>>>>>> >>>>>> Nat Sakimura (=nat) >>>>>>> >>>>>> >>>>>>> >>>>>> Chairman, OpenID >>>>>>> Foundation >>>>>>> >>>>>> >>>>>>> http://nat.sakimura.org/ >>>>>>> >>>>>> @_nat_en >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> -- >>>>>>> >>>>>> Nat Sakimura (=nat) >>>>>>> >>>>>> >>>>>>> >>>>>> Chairman, OpenID Foundation >>>>>>> >>>>>> http://nat.sakimura.org/ >>>>>>> >>>>>> @_nat_en >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> _______________________________________________ >>>>>>> >>>>>> OAuth mailing list >>>>>>> >>>>>> OAuth@ietf.org >>>>>>> >>>>>>> >>>>>> >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> -- >>>>>>> >>>>>> Thomas Broyer >>>>>>> >>>>>> /tɔ.ma.bʁwa.je/ >>>>>>> >>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> _______________________________________________ >>>>>>> >>>>>> OAuth mailing list >>>>>>> >>>>>> OAuth@ietf.org >>>>>>> >>>>>>> >>>>>> >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> -- >>>>>>> >>>>>> Thomas Broyer >>>>>>> >>>>>> /tɔ.ma.bʁwa.je/ >>>>>>> >>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> _______________________________________________ >>>>>>> >>>>>> OAuth mailing list >>>>>>> >>>>>> OAuth@ietf.org >>>>>>> >>>>>>> >>>>>> >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> -- >>>>>>> >>>>>> Nat Sakimura (=nat) >>>>>>> >>>>>> >>>>>>> >>>>>> Chairman, OpenID Foundation >>>>>>> >>>>>> http://nat.sakimura.org/ >>>>>>> >>>>>> @_nat_en >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> _______________________________________________ >>>>>>> >>>>>> >>>>>>> >>>>>> 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 >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> -- >>>>>>> >>>>>> Nat Sakimura (=nat) >>>>>>> >>>>>> Chairman, OpenID Foundation >>>>>>> >>>>>> http://nat.sakimura.org/ >>>>>>> >>>>>> @_nat_en >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> >>> >> > -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com From nobody Tue Oct 14 02:54:03 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D89C61A700A for ; Tue, 14 Oct 2014 02:54:02 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cXP08c0QuRtX for ; Tue, 14 Oct 2014 02:54:01 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0693.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::693]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C84EC1A7007 for ; Tue, 14 Oct 2014 02:54:00 -0700 (PDT) Received: from CO1PR02MB206.namprd02.prod.outlook.com (10.242.165.144) by CO1PR02MB206.namprd02.prod.outlook.com (10.242.165.144) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Tue, 14 Oct 2014 09:53:31 +0000 Received: from CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.15]) by CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.15]) with mapi id 15.00.1049.012; Tue, 14 Oct 2014 09:53:31 +0000 From: Antonio Sanso To: Hannes Tschofenig Thread-Topic: [OAUTH-WG] Blackhat US: OAuth Talk Thread-Index: AQHP5wPGtIE0dTJwlk+gRWfn/A3/xZwvW+YA Date: Tue, 14 Oct 2014 09:53:31 +0000 Message-ID: <26AB3ED9-1DC0-4F69-B98D-6EBCF3A159FD@adobe.com> References: <543BFF34.1070307@gmx.net> In-Reply-To: <543BFF34.1070307@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [193.104.215.11] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR02MB206; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 03648EFF89 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(6009001)(189002)(51914003)(24454002)(51704005)(199003)(377454003)(99396003)(95666004)(21056001)(86362001)(31966008)(82746002)(83716003)(120916001)(99286002)(20776003)(92726001)(92566001)(106116001)(85306004)(107046002)(80022003)(76482002)(122556002)(46102003)(66066001)(85852003)(64706001)(110136001)(36756003)(77096002)(2656002)(19580395003)(97736003)(54356999)(19580405001)(76176999)(4396001)(15975445006)(33656002)(50986999)(105586002)(106356001)(101416001)(87936001)(40100003)(104396001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR02MB206; H:CO1PR02MB206.namprd02.prod.outlook.com; FPR:; MLV:ovrnspm; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="Windows-1252" Content-ID: <05C9CD9A30C11B48A0EAD526BD2F3947@namprd02.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Blnprse2nqYIKNF33A8Rn2sGu_4 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Blackhat US: OAuth Talk X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 09:54:03 -0000 hi Hannes, thanks for the link. It is interesting. Said that I think the attack shown there are a bit =93academic=94 and do no= t reflect the real life situation. Moreover it still mention the MAC flow w= hen AFAIK the OAuth working group decided to deviate from it. IMHO the majority of real life attacks (and I can provide many many example= s taken from blog posts of people that hacked big providers such Google,Fac= ebook, Github etc) are actually targeting two things: - weak/incorrect validation of the redirect_uri parameter - leak of the access token . authorization code from the referrer just my 0.02 cents :) regards antonio On Oct 13, 2014, at 6:35 PM, Hannes Tschofenig = wrote: > During the OAuth conference call today I asked whether someone had > looked at this paper published at the recent Blackhat US conference and > nobody knew about it. >=20 > Hence, I am posting it here: >=20 > * Paper: >=20 > https://www.blackhat.com/docs/us-14/materials/us-14-Hu-How-To-Leak-A100-M= illion-Node-Social-Graph-In-Just-One-Week-WP.pdf >=20 > * Slides: > https://www.blackhat.com/docs/us-14/materials/us-14-Hu-How-To-Leak-A100-M= illion-Node-Social-Graph-In-Just-One-Week.pdf >=20 > Ciao > Hannes >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Tue Oct 14 05:27:00 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D32E31A8749; Tue, 14 Oct 2014 05:26: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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZK_EIfgdqRU; Tue, 14 Oct 2014 05:26:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 03CD91A8769; Tue, 14 Oct 2014 05:26:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141014122651.25776.65811.idtracker@ietfa.amsl.com> Date: Tue, 14 Oct 2014 05:26:51 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/lwK9LcnTL_GFRG59bG3FG1kuLHU Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-json-web-token-28.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 12:26:56 -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 Working Group of the IETF. Title : JSON Web Token (JWT) Authors : Michael B. Jones John Bradley Nat Sakimura Filename : draft-ietf-oauth-json-web-token-28.txt Pages : 34 Date : 2014-10-14 Abstract: JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JavaScript Object Notation (JSON) object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or MACed and/or encrypted. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-28 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-json-web-token-28 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 Oct 14 05:40:27 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 845361A879C for ; Tue, 14 Oct 2014 05:40:20 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QlvW3QyR3eOK for ; Tue, 14 Oct 2014 05:40:18 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0142.outbound.protection.outlook.com [207.46.100.142]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED2361A8797 for ; Tue, 14 Oct 2014 05:40:17 -0700 (PDT) Received: from CO2PR03CA0018.namprd03.prod.outlook.com (10.141.194.145) by BN3PR0301MB1202.namprd03.prod.outlook.com (25.161.207.155) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Tue, 14 Oct 2014 12:40:16 +0000 Received: from BN1AFFO11FD037.protection.gbl (2a01:111:f400:7c10::145) by CO2PR03CA0018.outlook.office365.com (2a01:111:e400:1414::17) with Microsoft SMTP Server (TLS) id 15.0.1054.13 via Frontend Transport; Tue, 14 Oct 2014 12:40:15 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD037.mail.protection.outlook.com (10.58.52.241) with Microsoft SMTP Server (TLS) id 15.0.1039.16 via Frontend Transport; Tue, 14 Oct 2014 12:40:15 +0000 Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.93]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.03.0210.003; Tue, 14 Oct 2014 12:39:34 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: JOSE -34 and JWT -28 drafts addressing IESG review comments Thread-Index: Ac/nq9tUA/c8pqIbSdqFmKhSVvB8WAAAAfmA Date: Tue, 14 Oct 2014 12:39:33 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439BB0D098@TK5EX14MBXC286.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439BB0D098TK5EX14MBXC286r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(438002)(199003)(189002)(377454003)(84676001)(66066001)(71186001)(110136001)(16297215004)(21056001)(106466001)(15202345003)(81156004)(77096002)(20776003)(80022003)(107886001)(2351001)(64706001)(46102003)(99396003)(107046002)(95666004)(85806002)(2656002)(31966008)(84326002)(19580405001)(44976005)(19580395003)(97736003)(87936001)(6806004)(50986999)(120916001)(54356999)(76482002)(19617315012)(33656002)(2501002)(55846006)(16236675004)(85852003)(104016003)(15975445006)(69596002)(68736004)(512954002)(26826002)(86612001)(92566001)(4396001)(19300405004)(85306004)(92726001)(86362001)(19625215002)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1202; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1202; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 03648EFF89 Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/jtmd9W-Xk_9GCiBTuUPGsUyiPhU Subject: [OAUTH-WG] FW: JOSE -34 and JWT -28 drafts addressing IESG review comments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 12:40:20 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439BB0D098TK5EX14MBXC286r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Mike Jones Sent: Tuesday, October 14, 2014 5:39 AM To: jose@ietf.org Subject: JOSE -34 and JWT -28 drafts addressing IESG review comments Updated JOSE and JWT specifications have been published that address the IE= SG review comments received. The one set of normative changes was to chang= e the implementation requirements for RSAES-PKCS1-V1_5 from Required to Rec= ommended- and for RSA-OAEP from Optional to Recommended+. Thanks to Richar= d Barnes, Alissa Cooper, Stephen Farrell, Brian Haberman, Ted Lemon, Barry = Leiba, and Pete Resnick for their IESG review comments, plus thanks to Scot= t Brim and Russ Housley for additional Gen-ART review comments, and thanks = to the working group members who helped respond to them. Many valuable cla= rifications resulted from your thorough reviews. The specifications are available at: * http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-34 * http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-34 * http://tools.ietf.org/html/draft-ietf-jose-json-web-key-34 * http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-34 * http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-28 HTML formatted versions are available at: * http://self-issued.info/docs/draft-ietf-jose-json-web-signature-34= .html * http://self-issued.info/docs/draft-ietf-jose-json-web-encryption-3= 4.html * http://self-issued.info/docs/draft-ietf-jose-json-web-key-34.html * http://self-issued.info/docs/draft-ietf-jose-json-web-algorithms-3= 4.html * http://self-issued.info/docs/draft-ietf-oauth-json-web-token-28.ht= ml -- Mike P.S. I also published this note at http://self-issued.info/?p=3D1291 and a= s @selfissued. --_000_4E1F6AAD24975D4BA5B16804296739439BB0D098TK5EX14MBXC286r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From: Mike Jon= es
Sent: Tuesday, October 14, 2014 5:39 AM
To: jose@ietf.org
Subject: JOSE -34 and JWT -28 drafts addressing IESG review comments=

 

Updated JOSE and JWT specifications have been publis= hed that address the IESG review comments received.  The one set of no= rmative changes was to change the implementation requirements for RSAES-PKC= S1-V1_5 from Required to Recommended- and for RSA-OAEP from Optional to Recommended+.  Thanks to Richard Ba= rnes, Alissa Cooper, Stephen Farrell, Brian Haberman, Ted Lemon, Barry Leib= a, and Pete Resnick for their IESG review comments, plus thanks to Scott Br= im and Russ Housley for additional Gen-ART review comments, and thanks to the working group members who helped respon= d to them.  Many valuable clarifications resulted from your thorough r= eviews.

 

The specifications are available at:

·        http://tools.ietf.org/html/draft-ietf-jose= -json-web-signature-34

·        http://tools.ietf.org/html/draft-ietf-jos= e-json-web-encryption-34

·        http://tools.ietf.org/html/draft-ietf-jose-json-= web-key-34

·        http://tools.ietf.org/html/draft-ietf-jos= e-json-web-algorithms-34

·        http://tools.ietf.org/html/draft-ietf-oauth-j= son-web-token-28

 

HTML formatted versions are available at:=

·        http://self-issued.info/docs/draft-= ietf-jose-json-web-signature-34.html

·        http://self-issued.info/docs/draft= -ietf-jose-json-web-encryption-34.html

·        http://self-issued.info/docs/draft-ietf-j= ose-json-web-key-34.html

·        http://self-issued.info/docs/draft= -ietf-jose-json-web-algorithms-34.html

·        http://self-issued.info/docs/draft-iet= f-oauth-json-web-token-28.html

 

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

 

P.S.  I also published this note at http://self-issued.info/?p=3D1291 and as @selfissued.

 

--_000_4E1F6AAD24975D4BA5B16804296739439BB0D098TK5EX14MBXC286r_-- From nobody Tue Oct 14 05:46:11 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 673161A879D; Tue, 14 Oct 2014 05:45:52 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GbJ8-Qe0y99G; Tue, 14 Oct 2014 05:45:44 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0718.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:718]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1A661A87AC; Tue, 14 Oct 2014 05:45:41 -0700 (PDT) Received: from BN3PR0301CA0027.namprd03.prod.outlook.com (25.160.180.165) by DM2PR0301MB1216.namprd03.prod.outlook.com (25.160.219.17) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Tue, 14 Oct 2014 12:45:18 +0000 Received: from BN1BFFO11FD053.protection.gbl (2a01:111:f400:7c10::1:175) by BN3PR0301CA0027.outlook.office365.com (2a01:111:e400:4000::37) with Microsoft SMTP Server (TLS) id 15.0.1049.19 via Frontend Transport; Tue, 14 Oct 2014 12:45:18 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1BFFO11FD053.mail.protection.outlook.com (10.58.145.8) with Microsoft SMTP Server (TLS) id 15.0.1039.16 via Frontend Transport; Tue, 14 Oct 2014 12:45:18 +0000 Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.93]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.03.0210.003; Tue, 14 Oct 2014 12:44:40 +0000 From: Mike Jones To: Alissa Cooper Thread-Topic: Alissa Cooper's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS) Thread-Index: Ac/nrJyfHkI5GysgQ5uS6ZQxTKLtDg== Date: Tue, 14 Oct 2014 12:44:40 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439BB0D28C@TK5EX14MBXC286.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439BB0D28CTK5EX14MBXC286r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(438002)(24454002)(377454003)(52044002)(43784003)(13464003)(189002)(199003)(41574002)(86362001)(16236675004)(15975445006)(92726001)(19580395003)(44976005)(6806004)(106466001)(81156004)(84676001)(21056001)(19580405001)(19625215002)(69596002)(68736004)(26826002)(33656002)(86612001)(77096002)(55846006)(76482002)(85852003)(85806002)(84326002)(2656002)(80022003)(120916001)(46102003)(87936001)(104016003)(31966008)(110136001)(85306004)(512874002)(19617315012)(19300405004)(230783001)(54356999)(50986999)(97736003)(4396001)(107046002)(99396003)(92566001)(95666004)(64706001)(20776003)(15202345003)(71186001)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB1216; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB1216; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 03648EFF89 Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/OLEJDK2gVOX-P_nrpH7wPe6tacU Cc: "oauth-chairs@tools.ietf.org" , "oauth@ietf.org" , The IESG , "draft-ietf-oauth-json-web-token@tools.ietf.org" Subject: Re: [OAUTH-WG] Alissa Cooper's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 12:45:52 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439BB0D28CTK5EX14MBXC286r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlc2UgcmVzb2x1dGlvbnMgaGF2ZSBiZWVuIGluY29ycG9yYXRlZCBpbiB0aGUgLTI4IGRyYWZ0 LiAgVGhhbmtzIGFnYWluIGZvciB5b3VyIHJldmlldy4NCg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBL YXRobGVlbiBNb3JpYXJ0eSBbbWFpbHRvOmthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29t XQ0KU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMDIsIDIwMTQgODoyMSBBTQ0KVG86IE1pa2UgSm9u ZXMNCkNjOiBBbGlzc2EgQ29vcGVyOyBUaGUgSUVTRzsgb2F1dGgtY2hhaXJzQHRvb2xzLmlldGYu b3JnPG1haWx0bzpvYXV0aC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+OyBkcmFmdC1pZXRmLW9hdXRo LWpzb24td2ViLXRva2VuQHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLW9hdXRoLWpz b24td2ViLXRva2VuQHRvb2xzLmlldGYub3JnPjsgb2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRo QGlldGYub3JnPg0KU3ViamVjdDogUmU6IEFsaXNzYSBDb29wZXIncyBEaXNjdXNzIG9uIGRyYWZ0 LWlldGYtb2F1dGgtanNvbi13ZWItdG9rZW4tMjc6ICh3aXRoIERJU0NVU1MpDQoNCg0KDQpPbiBU aHUsIE9jdCAyLCAyMDE0IGF0IDExOjE0IEFNLCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1p Y3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0K DQpSZXNwb25kaW5nIHRvIHRoZSBESVNDVVNTIGJlbG934oCmDQoNCg0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogQWxpc3NhIENvb3BlciBbbWFpbHRvOmFsaXNzYUBjb29wZXJ3 LmluPG1haWx0bzphbGlzc2FAY29vcGVydy5pbj5dDQpTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIg MDEsIDIwMTQgMTI6MjUgUE0NClRvOiBUaGUgSUVTRw0KQ2M6IG9hdXRoLWNoYWlyc0B0b29scy5p ZXRmLm9yZzxtYWlsdG86b2F1dGgtY2hhaXJzQHRvb2xzLmlldGYub3JnPjsgZHJhZnQtaWV0Zi1v YXV0aC1qc29uLXdlYi10b2tlbkB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1vYXV0 aC1qc29uLXdlYi10b2tlbkB0b29scy5pZXRmLm9yZz4NClN1YmplY3Q6IEFsaXNzYSBDb29wZXIn cyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtb2F1dGgtanNvbi13ZWItdG9rZW4tMjc6ICh3aXRoIERJ U0NVU1MpDQoNCg0KDQpBbGlzc2EgQ29vcGVyIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFs bG90IHBvc2l0aW9uIGZvcg0KDQpkcmFmdC1pZXRmLW9hdXRoLWpzb24td2ViLXRva2VuLTI3OiBE aXNjdXNzDQoNCg0KDQpXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxp bmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwgZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRo ZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMgaW50cm9kdWN0b3J5IHBh cmFncmFwaCwgaG93ZXZlci4pDQoNCg0KDQoNCg0KUGxlYXNlIHJlZmVyIHRvIGh0dHA6Ly93d3cu aWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQoNCmZvciBtb3Jl IGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQoN Cg0KDQoNCg0KVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMs IGNhbiBiZSBmb3VuZCBoZXJlOg0KDQpodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWlldGYtb2F1dGgtanNvbi13ZWItdG9rZW4vDQoNCg0KDQoNCg0KDQoNCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCg0KRElTQ1VTUzoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCg0KPT0gU2VjdGlvbiAxMiA9PQ0K DQoNCg0KIkEgSldUIG1heSBjb250YWluIHByaXZhY3ktc2Vuc2l0aXZlIGluZm9ybWF0aW9uLiAg V2hlbiB0aGlzIGlzIHRoZQ0KDQogICBjYXNlLCBtZWFzdXJlcyBtdXN0IGJlIHRha2VuIHRvIHBy ZXZlbnQgZGlzY2xvc3VyZSBvZiB0aGlzDQoNCiAgIGluZm9ybWF0aW9uIHRvIHVuaW50ZW5kZWQg cGFydGllcy4iDQoNCg0KDQpJdCBzZWVtcyB0byBtZSB0aGF0IHRoaXMgc2hvdWxkIGJlIGEgbm9y bWF0aXZlIE1VU1QsIHBhcnRpY3VsYXJseSBpbiBsaWdodCBvZiB0aGUgZmFjdCB0aGF0IGNsYWlt cyBhcmUgYmVpbmcgZGVmaW5lZCB0aGF0IGFyZSBtZWFudCB0byBkaXJlY3RseSBpZGVudGlmeSB1 c2VycyAoZS5nLiwgc3ViKSBhbmQgb3RoZXIgY2xhaW1zIGRlZmluZWQgaGVyZSBvciBsYXRlciBj b3VsZCBkbyBzbyBhcyB3ZWxsLg0KDQoNCg0KVGhlcmUgc2VlbXMgdG8gYmUgZGViYXRlIHdoZXRo ZXIgYSAyMTE5IGxhbmd1YWdlIHNob3VsZCBiZSB1c2VkIG90aGVyIHRoYW4gd2hlbiBkZXNjcmli aW5nIHByb3RvY29sIHJlcXVpcmVtZW50cy4gIEppbSBTY2hhYWQgKHRoZSBKT1NFIGNoYWlyKSBi ZWxpZXZlcyB0aGF0IHRoZXkgc2hvdWxkbuKAmXQgYW5kIHRoZXNlIGRvY3VtZW50cyBoYXZlIGZv bGxvd2VkIHRoYXQgY29udmVudGlvbi4NCldpdGggb3RoZXIgZG9jdW1lbnRzLCB0aGVyZSBpcyBS RkMyMTE5IGxhbmd1YWdlIHVzZWQgZm9yIHNlY3VyaXR5ICYgcHJpdmFjeSBjb25zaWRlcmF0aW9u cy4gIEF0IHNvbWUgcG9pbnQgdGhlcmUgd2FzIGEgdHJlbmQgdG8gaGF2ZSBhIHNlcGFyYXRlICJT ZWN1cml0eSBSZXF1aXJlbWVudHMiIHNlY3Rpb24gZnJvbSAiU2VjdXJpdHkgQ29uc2lkZXJhdGlv bnMiLCBidXQgSSBkb24ndCB0aGluayB0aGVyZSB3YXMgYW55IHJlcXVpcmVtZW50IGZvciB0aGlz LCBqdXN0IGEgcHJlZmVyZW5jZS4gIEkgYWdyZWUgdGhhdCB0aGlzIHNob3VsZCBiZSBhIE1VU1Qs IGJ1dCB3aXRoIFN0ZXBoZW4gYXMgd2VsbCB0aGF0IHlvdSBzaG91bGQgZGlzY291cmFnZSBwdXR0 aW5nIGluIHByaXZhY3kgcmVsYXRlZCBpbmZvcm1hdGlvbiB0byBiZWdpbiB3aXRoLg0KDQoNCg0K Ik9uZSB3YXkgdG8gYWNoaWV2ZSB0aGlzIGlzIHRvIHVzZQ0KDQogICBhbiBlbmNyeXB0ZWQgSldU LiAgQW5vdGhlciB3YXkgaXMgdG8gZW5zdXJlIHRoYXQgSldUcyBjb250YWluaW5nDQoNCiAgIHVu ZW5jcnlwdGVkIHByaXZhY3ktc2Vuc2l0aXZlIGluZm9ybWF0aW9uIGFyZSBvbmx5IHRyYW5zbWl0 dGVkIG92ZXINCg0KICAgZW5jcnlwdGVkIGNoYW5uZWxzIG9yIHByb3RvY29scywgc3VjaCBhcyBU TFMuIg0KDQoNCg0KU2luY2Ugc2Vuc2l0aXZlIEpXVHMgc2hvdWxkIGJlIHByb3RlY3RlZCBmcm9t IGJvdGggaW50ZXJtZWRpYXJ5IG9ic2VydmF0aW9uIGFuZCBmcm9tIGJlaW5nIHNlbnQgdG8gdW5p bnRlbmRlZCByZWNpcGllbnRzLCBJIHdvdWxkDQoNCnN1Z2dlc3Q6DQoNCg0KDQpPbmUgd2F5IHRv IGFjaGlldmUgdGhpcyBpcyB0byB1c2UgYW4gZW5jcnlwdGVkIEpXVCBhbmQgYXV0aGVudGljYXRl IHRoZSByZWNpcGllbnQuIEFub3RoZXIgd2F5IGlzIHRvIGVuc3VyZSB0aGF0IEpXVHMgY29udGFp bmluZyB1bmVuY3J5cHRlZCBwcml2YWN5LXNlbnNpdGl2ZSBpbmZvcm1hdGlvbiBhcmUgb25seSB0 cmFuc21pdHRlZCBvdmVyIGVuY3J5cHRlZCBjaGFubmVscyBvciBwcm90b2NvbHMgdGhhdCBhbHNv IHN1cHBvcnQgZW5kcG9pbnQgYXV0aGVudGljYXRpb24sIHN1Y2ggYXMgVExTLg0KDQoNCg0KVGhh bmtzIGZvciB0aGlzIHN1Z2dlc3RlZCBsYW5ndWFnZS4gIFdlIGNhbiBpbmNvcnBvcmF0ZSBzb21l dGhpbmcgbGlrZSB0aGF0Lg0KT0ssIHRoaXMgbWFrZXMgc2Vuc2UgYW5kIHdpbGwgZmVlZCBpbnRv IFBldGUncyBkaXNjdXNzIG9uIHdoZXJlIFRMUyBzaG91bGQgYmUgcmVxdWlyZWQuDQoNClRoYW5r cyENCg0KDQoNCg0KDQotLQ0KDQpCZXN0IHJlZ2FyZHMsDQpLYXRobGVlbg0K --_000_4E1F6AAD24975D4BA5B16804296739439BB0D28CTK5EX14MBXC286r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvQWNl dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5 bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt cmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0 OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEu MGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGVzZSByZXNvbHV0aW9u cyBoYXZlIGJlZW4gaW5jb3Jwb3JhdGVkIGluIHRoZSAtMjggZHJhZnQuJm5ic3A7IFRoYW5rcyBh Z2FpbiBmb3IgeW91ciByZXZpZXcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gS2F0aGxlZW4gTW9yaWFydHkg WzxhIGhyZWY9Im1haWx0bzprYXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbSI+bWFpbHRv OmthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9i PiBUaHVyc2RheSwgT2N0b2JlciAwMiwgMjAxNCA4OjIxIEFNPGJyPg0KPGI+VG86PC9iPiBNaWtl IEpvbmVzPGJyPg0KPGI+Q2M6PC9iPiBBbGlzc2EgQ29vcGVyOyBUaGUgSUVTRzsgPGEgaHJlZj0i bWFpbHRvOm9hdXRoLWNoYWlyc0B0b29scy5pZXRmLm9yZyI+DQpvYXV0aC1jaGFpcnNAdG9vbHMu aWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi10 b2tlbkB0b29scy5pZXRmLm9yZyI+DQpkcmFmdC1pZXRmLW9hdXRoLWpzb24td2ViLXRva2VuQHRv b2xzLmlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj4NCm9hdXRo QGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogQWxpc3NhIENvb3BlcidzIERp c2N1c3Mgb24gZHJhZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi10b2tlbi0yNzogKHdpdGggRElTQ1VT Uyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIE9jdCAyLCAyMDE0IGF0IDExOjE0 IEFNLCBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3Nv ZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwPjxzcGFuIHN0eWxlPSJj b2xvcjojMDA3MEMwIj5SZXNwb25kaW5nIHRvIHRoZSBESVNDVVNTIGJlbG934oCmPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcwQzAiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJv bTogQWxpc3NhIENvb3BlciBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzphbGlzc2FAY29vcGVydy5p biIgdGFyZ2V0PSJfYmxhbmsiPmFsaXNzYUBjb29wZXJ3LmluPC9hPl0NCjxicj4NClNlbnQ6IFdl ZG5lc2RheSwgT2N0b2JlciAwMSwgMjAxNCAxMjoyNSBQTTxicj4NClRvOiBUaGUgSUVTRzxicj4N CkNjOiA8YSBocmVmPSJtYWlsdG86b2F1dGgtY2hhaXJzQHRvb2xzLmlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+b2F1dGgtY2hhaXJzQHRvb2xzLmlldGYub3JnPC9hPjsNCjxhIGhyZWY9Im1haWx0 bzpkcmFmdC1pZXRmLW9hdXRoLWpzb24td2ViLXRva2VuQHRvb2xzLmlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+ZHJhZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi10b2tlbkB0b29scy5pZXRmLm9yZzwv YT48YnI+DQpTdWJqZWN0OiBBbGlzc2EgQ29vcGVyJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLW9h dXRoLWpzb24td2ViLXRva2VuLTI3OiAod2l0aCBESVNDVVNTKTxvOnA+PC9vOnA+PC9wPg0KPHA+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8cD5BbGlzc2EgQ29vcGVyIGhhcyBlbnRlcmVkIHRoZSBm b2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcjxvOnA+PC9vOnA+PC9wPg0KPHA+ZHJhZnQtaWV0 Zi1vYXV0aC1qc29uLXdlYi10b2tlbi0yNzogRGlzY3VzczxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cD5XaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBz dWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwgZW1haWwgYWRkcmVzc2VzIGluY2x1 ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMgaW50cm9k dWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pPG86cD48L286cD48L3A+DQo8cD4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+UGxlYXNlIHJlZmVyIHRv IDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0 ZXJpYS5odG1sIiB0YXJnZXQ9Il9ibGFuayI+DQo8c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4 dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cDovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVu dC9kaXNjdXNzLWNyaXRlcmlhLmh0bWw8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHA+Zm9y IG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9u cy48bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cD5UaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBv c2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6PG86cD48L286cD48L3A+DQo8cD48YSBocmVmPSJo dHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtb2F1dGgtanNvbi13ZWIt dG9rZW4vIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4 dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt aWV0Zi1vYXV0aC1qc29uLXdlYi10b2tlbi88L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHA+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHA+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9wPg0KPHA+RElT Q1VTUzo8bzpwPjwvbzpwPjwvcD4NCjxwPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvcD4NCjxw PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+PT0gU2VjdGlvbiAxMiA9PTxvOnA+PC9vOnA+PC9w Pg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cD4mcXVvdDtBIEpXVCBtYXkgY29udGFpbiBw cml2YWN5LXNlbnNpdGl2ZSBpbmZvcm1hdGlvbi4mbmJzcDsgV2hlbiB0aGlzIGlzIHRoZTxvOnA+ PC9vOnA+PC9wPg0KPHA+Jm5ic3A7Jm5ic3A7IGNhc2UsIG1lYXN1cmVzIG11c3QgYmUgdGFrZW4g dG8gcHJldmVudCBkaXNjbG9zdXJlIG9mIHRoaXM8bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOyZu YnNwOyBpbmZvcm1hdGlvbiB0byB1bmludGVuZGVkIHBhcnRpZXMuJnF1b3Q7Jm5ic3A7IDxvOnA+ PC9vOnA+PC9wPg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cD5JdCBzZWVtcyB0byBtZSB0 aGF0IHRoaXMgc2hvdWxkIGJlIGEgbm9ybWF0aXZlIE1VU1QsIHBhcnRpY3VsYXJseSBpbiBsaWdo dCBvZiB0aGUgZmFjdCB0aGF0IGNsYWltcyBhcmUgYmVpbmcgZGVmaW5lZCB0aGF0IGFyZSBtZWFu dCB0byBkaXJlY3RseSBpZGVudGlmeSB1c2VycyAoZS5nLiwgc3ViKSBhbmQgb3RoZXIgY2xhaW1z IGRlZmluZWQgaGVyZSBvciBsYXRlciBjb3VsZCBkbyBzbyBhcyB3ZWxsLjxvOnA+PC9vOnA+PC9w Pg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcwQzAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj5UaGVyZSBzZWVtcyB0byBiZSBk ZWJhdGUgd2hldGhlciBhIDIxMTkgbGFuZ3VhZ2Ugc2hvdWxkIGJlIHVzZWQgb3RoZXIgdGhhbiB3 aGVuIGRlc2NyaWJpbmcgcHJvdG9jb2wgcmVxdWlyZW1lbnRzLiZuYnNwOyBKaW0gU2NoYWFkICh0 aGUgSk9TRSBjaGFpcikgYmVsaWV2ZXMgdGhhdCB0aGV5IHNob3VsZG7igJl0IGFuZCB0aGVzZSBk b2N1bWVudHMgaGF2ZSBmb2xsb3dlZCB0aGF0IGNvbnZlbnRpb24uPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaXRoIG90 aGVyIGRvY3VtZW50cywgdGhlcmUgaXMgUkZDMjExOSBsYW5ndWFnZSB1c2VkIGZvciBzZWN1cml0 eSAmYW1wOyBwcml2YWN5IGNvbnNpZGVyYXRpb25zLiZuYnNwOyBBdCBzb21lIHBvaW50IHRoZXJl IHdhcyBhIHRyZW5kIHRvIGhhdmUgYSBzZXBhcmF0ZSAmcXVvdDtTZWN1cml0eSBSZXF1aXJlbWVu dHMmcXVvdDsgc2VjdGlvbiBmcm9tICZxdW90O1NlY3VyaXR5IENvbnNpZGVyYXRpb25zJnF1b3Q7 LCBidXQgSSBkb24ndCB0aGluayB0aGVyZSB3YXMNCiBhbnkgcmVxdWlyZW1lbnQgZm9yIHRoaXMs IGp1c3QgYSBwcmVmZXJlbmNlLiZuYnNwOyBJIGFncmVlIHRoYXQgdGhpcyBzaG91bGQgYmUgYSBN VVNULCBidXQgd2l0aCBTdGVwaGVuIGFzIHdlbGwgdGhhdCB5b3Ugc2hvdWxkIGRpc2NvdXJhZ2Ug cHV0dGluZyBpbiBwcml2YWN5IHJlbGF0ZWQgaW5mb3JtYXRpb24gdG8gYmVnaW4gd2l0aC48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMw Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD4mcXVvdDtPbmUgd2F5IHRvIGFjaGll dmUgdGhpcyBpcyB0byB1c2U8bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOyZuYnNwOyBhbiBlbmNy eXB0ZWQgSldULiZuYnNwOyBBbm90aGVyIHdheSBpcyB0byBlbnN1cmUgdGhhdCBKV1RzIGNvbnRh aW5pbmc8bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOyZuYnNwOyB1bmVuY3J5cHRlZCBwcml2YWN5 LXNlbnNpdGl2ZSBpbmZvcm1hdGlvbiBhcmUgb25seSB0cmFuc21pdHRlZCBvdmVyPG86cD48L286 cD48L3A+DQo8cD4mbmJzcDsmbmJzcDsgZW5jcnlwdGVkIGNoYW5uZWxzIG9yIHByb3RvY29scywg c3VjaCBhcyBUTFMuJnF1b3Q7PG86cD48L286cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwPlNpbmNlIHNlbnNpdGl2ZSBKV1RzIHNob3VsZCBiZSBwcm90ZWN0ZWQgZnJvbSBib3Ro IGludGVybWVkaWFyeSBvYnNlcnZhdGlvbiBhbmQgZnJvbSBiZWluZyBzZW50IHRvIHVuaW50ZW5k ZWQgcmVjaXBpZW50cywgSSB3b3VsZDxvOnA+PC9vOnA+PC9wPg0KPHA+c3VnZ2VzdDo8bzpwPjwv bzpwPjwvcD4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+T25lIHdheSB0byBhY2hpZXZl IHRoaXMgaXMgdG8gdXNlIGFuIGVuY3J5cHRlZCBKV1QgYW5kIGF1dGhlbnRpY2F0ZSB0aGUgcmVj aXBpZW50LiBBbm90aGVyIHdheSBpcyB0byBlbnN1cmUgdGhhdCBKV1RzIGNvbnRhaW5pbmcgdW5l bmNyeXB0ZWQgcHJpdmFjeS1zZW5zaXRpdmUgaW5mb3JtYXRpb24gYXJlIG9ubHkgdHJhbnNtaXR0 ZWQgb3ZlciBlbmNyeXB0ZWQgY2hhbm5lbHMgb3IgcHJvdG9jb2xzIHRoYXQgYWxzbyBzdXBwb3J0 IGVuZHBvaW50DQogYXV0aGVudGljYXRpb24sIHN1Y2ggYXMgVExTLjxvOnA+PC9vOnA+PC9wPg0K PHA+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcwQzAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj5UaGFua3MgZm9yIHRoaXMgc3VnZ2Vz dGVkIGxhbmd1YWdlLiZuYnNwOyBXZSBjYW4gaW5jb3Jwb3JhdGUgc29tZXRoaW5nIGxpa2UgdGhh dC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9LLCB0aGlzIG1ha2VzIHNlbnNlIGFuZCB3aWxs IGZlZWQgaW50byBQZXRlJ3MgZGlzY3VzcyBvbiB3aGVyZSBUTFMgc2hvdWxkIGJlIHJlcXVpcmVk LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U aGFua3MhJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmln aHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cD48c3BhbiBzdHls ZT0iY29sb3I6IzAwNzBDMCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0K PGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pi0tIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlc3QgcmVnYXJkcyw8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkthdGhs ZWVuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_4E1F6AAD24975D4BA5B16804296739439BB0D28CTK5EX14MBXC286r_-- From nobody Tue Oct 14 05:48:38 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91E011A87C1; Tue, 14 Oct 2014 05:48:32 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qsFuusQIOCoG; Tue, 14 Oct 2014 05:48:26 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0794.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:794]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E0911A87A0; Tue, 14 Oct 2014 05:48:26 -0700 (PDT) Received: from DM2PR03CA0008.namprd03.prod.outlook.com (10.141.96.18) by DM2PR0301MB1216.namprd03.prod.outlook.com (25.160.219.17) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Tue, 14 Oct 2014 12:48:03 +0000 Received: from BL2FFO11FD045.protection.gbl (2a01:111:f400:7c09::153) by DM2PR03CA0008.outlook.office365.com (2a01:111:e400:2428::18) with Microsoft SMTP Server (TLS) id 15.0.1054.13 via Frontend Transport; Tue, 14 Oct 2014 12:48:03 +0000 Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD045.mail.protection.outlook.com (10.173.161.207) with Microsoft SMTP Server (TLS) id 15.0.1039.16 via Frontend Transport; Tue, 14 Oct 2014 12:48:03 +0000 Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.93]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.03.0210.003; Tue, 14 Oct 2014 12:47:26 +0000 From: Mike Jones To: Barry Leiba , The IESG Thread-Topic: Barry Leiba's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) Thread-Index: Ac/nrPscpwn+lU95TEyXOragiNkBcg== Date: Tue, 14 Oct 2014 12:47:25 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439BB0D351@TK5EX14MBXC286.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(13464003)(189002)(52044002)(50854003)(43784003)(199003)(51704005)(51914003)(377454003)(31966008)(85306004)(54356999)(50986999)(230783001)(46102003)(87936001)(85806002)(2656002)(120916001)(80022003)(104016003)(20776003)(64706001)(66066001)(47776003)(15202345003)(4396001)(97736003)(99396003)(107046002)(95666004)(92566001)(6806004)(106466001)(84676001)(81156004)(92726001)(15975445006)(44976005)(19580395003)(19580405001)(21056001)(86362001)(50466002)(86612001)(55846006)(76482002)(77096002)(85852003)(69596002)(68736004)(33656002)(23676002)(26826002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB1216; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB1216; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 03648EFF89 Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/mRDuvY7Kf6TmatYkWTJdOvL21us Cc: "oauth-chairs@tools.ietf.org" , "draft-ietf-oauth-json-web-token@tools.ietf.org" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Barry Leiba's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 12:48:33 -0000 VGhlIHByb3Bvc2VkIHJlc29sdXRpb25zIGhhdmUgYmVlbiBhcHBsaWVkIHRvIHRoZSAtMjggZHJh ZnQuICBIb3BlZnVsbHkgdGhpcyB3aWxsIGVuYWJsZSB0byBjbGVhciB5b3VyIERJU0NVU1Nlcy4g IFRoYW5rcyBhZ2FpbiBmb3IgdGhlIGNhcmVmdWwgcmVhZCENCg0KCQkJCS0tIE1pa2UNCg0KPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNaWtlIEpvbmVzDQo+IFNlbnQ6IFNhdHVyZGF5 LCBPY3RvYmVyIDA0LCAyMDE0IDU6MTcgUE0NCj4gVG86IEJhcnJ5IExlaWJhOyBUaGUgSUVTRw0K PiBDYzogb2F1dGgtY2hhaXJzQHRvb2xzLmlldGYub3JnOyBkcmFmdC1pZXRmLW9hdXRoLWpzb24t d2ViLQ0KPiB0b2tlbkB0b29scy5pZXRmLm9yZzsgb2F1dGhAaWV0Zi5vcmcNCj4gU3ViamVjdDog UmU6IFtPQVVUSC1XR10gQmFycnkgTGVpYmEncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtb2F1dGgt anNvbi13ZWItDQo+IHRva2VuLTI3OiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KPiANCj4g VGhhbmtzIGZvciB5b3VyIHJldmlldywgQmFycnkuICBJJ20gYWRkaW5nIHRoZSB3b3JraW5nIGdy b3VwIHNvIHRoZXnigJlyZSBhd2FyZQ0KPiBvZiB0aGVzZSBjb21tZW50cy4gIEF0IFN0ZXBoZW4g RmFycmVsbCdzIHJlcXVlc3QsIEknbSByZXNwb25kaW5nIHdpdGggIj4gIiBsaW5lDQo+IHByZWZp eGVzIG9uIHByZXZpb3VzIHRocmVhZCBjb250ZW50LiAgSSdtIGFsc28gcmVwZWF0aW5nIChhbmQg aW4gdGhlIGZpcnN0IGNhc2UsDQo+IGF1Z21lbnRpbmcpIG15IHByZXZpb3VzIHJlc3BvbnNlcyB0 byB0aGUgRElTQ1VTUyBjb21tZW50cyBpbiB0aGlzDQo+IGNvbnNvbGlkYXRlZCBtZXNzYWdlLg0K PiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IEJhcnJ5IExlaWJh IFttYWlsdG86YmFycnlsZWliYUBjb21wdXRlci5vcmddDQo+ID4gU2VudDogV2VkbmVzZGF5LCBP Y3RvYmVyIDAxLCAyMDE0IDg6NTQgQU0NCj4gPiBUbzogVGhlIElFU0cNCj4gPiBDYzogb2F1dGgt Y2hhaXJzQHRvb2xzLmlldGYub3JnOyBkcmFmdC1pZXRmLW9hdXRoLWpzb24td2ViLQ0KPiA+IHRv a2VuQHRvb2xzLmlldGYub3JnDQo+ID4gU3ViamVjdDogQmFycnkgTGVpYmEncyBEaXNjdXNzIG9u IGRyYWZ0LWlldGYtb2F1dGgtanNvbi13ZWItdG9rZW4tMjc6DQo+ID4gKHdpdGggRElTQ1VTUyBh bmQgQ09NTUVOVCkNCj4gPg0KPiA+IEJhcnJ5IExlaWJhIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dp bmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPiA+IGRyYWZ0LWlldGYtb2F1dGgtanNvbi13ZWItdG9r ZW4tMjc6IERpc2N1c3MNCj4gPg0KPiA+IFdoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhl IHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbA0KPiA+IGVtYWlsIGFkZHJlc3Nl cyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dA0KPiA+ IHRoaXMgaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+ID4NCj4gPg0KPiA+IFBs ZWFzZSByZWZlciB0bw0KPiA+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlz Y3Vzcy1jcml0ZXJpYS5odG1sDQo+ID4gZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBE SVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCj4gPg0KPiA+DQo+ID4gVGhlIGRvY3VtZW50 LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0K PiA+IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vYXV0aC1qc29u LXdlYi10b2tlbi8NCj4gPg0KPiA+DQo+ID4NCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gRElTQ1VT UzoNCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4NCj4gPiBJIGhhdmUgdHdvIHBvaW50cyB0aGF0IEkn ZCBsaWtlIHRvIGdldCByZXNvbHZlZCBiZWZvcmUgaGFwcGlseQ0KPiA+IGFwcHJvdmluZyB0aGlz IGZpbmUNCj4gPiBkb2N1bWVudDoNCj4gPg0KPiA+IC0tIFNlY3Rpb24gNy4xIC0tDQo+ID4NCj4g PiBUaGUgY29tcGFyaXNvbiB5b3Ugc3BlY2lmeSBpcyBhcyBzcGVjaWZpZWQgaW4gUkZDIDcxNTks IFNlY3Rpb24gOC4zLA0KPiA+IHdoaWNoIGlzIHRvICJ0cmFuc2Zvcm0gdGhlIHRleHR1YWwgcmVw cmVzZW50YXRpb24gaW50byBzZXF1ZW5jZXMgb2YNCj4gPiBVbmljb2RlIGNvZGUgdW5pdHMgYW5k IHRoZW4gcGVyZm9ybSB0aGUgY29tcGFyaXNvbiBudW1lcmljYWxseSwgY29kZQ0KPiA+IHVuaXQg YnkgY29kZSB1bml0Ii4gIFRoaXMgaGFzIG5vIHJlZ2FyZCBmb3IgdGV4dCBjYXNlLCBhbmQgc28g aXQncyBhIGNhc2Utc2Vuc2l0aXZlDQo+IGNvbXBhcmlzb24uDQo+ID4NCj4gPiBBbmQsIHlldCwg U2VjdGlvbnMgNS4xIGFuZCA1LjIgc3BlY2lmeSB0aGF0IHRoZSB2YWx1ZXMgb2YgdHlwIGFuZCBj dHkNCj4gPiBhcmUgY2FzZS0gaW5zZW5zaXRpdmUsIGFuZCBzcGVjaWZ5IHVzaW5nIHVwcGVyIGNh c2UgYXMgYSBTSE9VTEQsIGZvcg0KPiA+ICJjb21wYXRpYmlsaXR5IHdpdGggbGVnYWN5IGltcGxl bWVudGF0aW9ucyIuDQo+ID4NCj4gPiBJdCBkb2Vzbid0IHNlZW0gdGhhdCAibGVnYWN5IiBoYXMg YW55dGhpbmcgdG8gZG8gd2l0aCB0aGlzOiBzb21lb25lDQo+ID4gY29uZm9ybWluZyB0byAqdGhp cyogc3BlY2lmaWNhdGlvbiB3aWxsIGNvbXBhcmUgdGhlIHZhbHVlcyBvZiB0eXAgYW5kDQo+ID4g Y3R5IFVuaWNvZGUtY2hhcmFjdGVyIGJ5IFVuaWNvZGUtY2hhcmFjdGVyLCBhbmQgd2lsbCBmYWls IHRvIG1hdGNoICJKV1QiIHdpdGgNCj4gImp3dCIuDQo+ID4NCj4gPiBJcyB0aGVyZSBub3QgYSBw cm9ibGVtIGhlcmU/DQo+IA0KPiBXZSBjYW4gdXBkYXRlIHRoZSB0ZXh0IHRvIGNsYXJpZnkgdGhh dCBNSU1FIHR5cGUgY29tcGFyaXNvbnMgYXJlIGFuIGV4Y2VwdGlvbg0KPiB0byB0aGUg4oCcY29k ZSB1bml0IGJ5IGNvZGUgdW5pdOKAnSBjb21wYXJpc29uIHJ1bGUuICBUaGUgZHJhZnRzIHdpbGwg YWxzbyBiZQ0KPiBzY3J1dGluaXplZCBmb3Igb3RoZXIgcG9zc2libGUgb2NjdXJyZW5jZXMgb2Yg ZXhjZXB0aW9ucyB0byB0aGUgZGVmYXVsdCBzdHJpbmcNCj4gY29tcGFyaXNvbiBpbnN0cnVjdGlv bnMuICBGaW5hbGx5LCB3ZSBjYW4gYWRkIGxhbmd1YWdlIHRvIDcuMSBhYm91dCAidW5sZXNzDQo+ IG90aGVyd2lzZSBub3RlZCBmb3IgYSBwYXJ0aWN1bGFyIGtpbmQgb2Ygc3RyaW5nIiBzbyB0aGF0 IGl0J3MgY2xlYXIgdGhhdCB0aGVyZSBhcmUNCj4gZXhjZXB0aW9ucyB0byB0aGUgcnVsZS4NCj4g DQo+ID4gLS0gU2VjdGlvbiAxMC4zLjEgLS0NCj4gPg0KPiA+IE5pY2UgdGhhdCB5b3UgY2l0ZSAy MDQ2IGZvciBtZWRpYSB0eXBlcywgYnV0IHRoZSAqcmVnaXN0cmF0aW9uKiBvZg0KPiA+IG1lZGlh IHR5cGVzIGlzIGRvY3VtZW50ZWQgaW4gUkZDIDY4MzgsIGFuZCB0aGlzIGRvY3VtZW50IGRvZXNu J3QgcXVpdGUNCj4gPiBjb25mb3JtIHRvIHRoYXQuICBUaGUgb25seSB0aGluZyBtaXNzaW5nIGlu IHRoZSBkb2MgaXMgIkZyYWdtZW50DQo+ID4gaWRlbnRpZmllciBjb25zaWRlcmF0aW9ucyIgaW4g dGhlIHJlZ2lzdHJhdGlvbiB0ZW1wbGF0ZSwgYnV0IDY4MzggYWxzbw0KPiA+IHN0cm9uZ2x5IHN1 Z2dlc3RzIHJldmlldyBvZiB0aGUgbWVkaWEtdHlwZSByZWdpc3RyYXRpb24gb24gdGhlDQo+ID4g bWVkaWEtdHlwZXMgbWFpbGluZyBsaXN0LiAgR2l2ZW4gdGhhdCB0aGlzIHdpbGwgbm90IGdldCBl eHBlcnQgcmV2aWV3DQo+ID4gKGJlY2F1c2UgaXQncyBhbiBJRVRGLXN0cmVhbSBSRkMpLCBJJ2Qg bGlrZSB0byBhc2sgZm9yIGFuIGV4cGxpY2l0DQo+ID4gcmV2aWV3IG9uIHRoZSBtZWRpYS10eXBl cyBsaXN0IHRvIG1ha2Ugc3VyZSB0aGF0IHRoZSByZWdpc3RyYXRpb24gaW5mb3JtYXRpb24gaXMN Cj4gY29tcGxldGUgYW5kIG1ha2VzIHNlbnNlLg0KPiANCj4gVGhhbmtzIGZvciB0aGUgNjgzMyBy ZWZlcmVuY2UuICBXZeKAmWxsIHVzZSB0aGF0LiAgSSBrbm93IHRoYXQgS2F0aGxlZW4gYWxyZWFk eQ0KPiBpbml0aWF0ZWQgdGhlIHJldmlldyBvbiB0aGUgbWVkaWEtdHlwZXMgbGlzdC4NCj4gDQo+ ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KPiA+IENPTU1FTlQ6DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+DQo+ ID4gLS0gQWJzdHJhY3QgLS0NCj4gPg0KPiA+ICAgIFRoZSBzdWdnZXN0ZWQgcHJvbnVuY2lhdGlv biBvZiBKV1QgaXMgdGhlIHNhbWUgYXMgdGhlIEVuZ2xpc2ggd29yZA0KPiA+ICAgICJqb3QiLg0K PiA+DQo+ID4gSSBoYXZlIG5vIG9iamVjdGlvbiAod2VsbCwgSSBkbywgYnV0IGl0J3Mgbm90IGZv ciBtZSB0byBzYXkgaG93IHlvdQ0KPiA+IHdhbnQgdG8gcHJvbm91bmNlIGl0KSB0byBoYXZpbmcg dGhpcyBzZW50ZW5jZSBpbiB0aGUgSW50cm9kdWN0aW9uLCBidXQNCj4gPiBpdCBzZWVtcyBvdXQg b2YgcGxhY2UgaW4gdGhlIEFic3RyYWN0LCB3aGljaCBpcyBtZWFudCB0byBiZSBjb25jaXNlLg0K PiANCj4gT0sgLSBXZSBjYW4gcmVtb3ZlIGl0IGZyb20gdGhlIEFic3RyYWN0Lg0KPiANCj4gPiAt LSBTZWN0aW9uIDQuMSAtLQ0KPiA+DQo+ID4gSXQgYXBwZWFycyB0aGF0IGFsbCBjbGFpbXMgZGVm aW5lZCBoZXJlIGFyZSBPUFRJT05BTCwgYW5kIGVhY2ggb25lDQo+ID4gc2F5cyBzbyBpbiBpdHMg c3Vic2VjdGlvbi4gIEdpdmVuIHRoYXQgdGhleSAqYWxsKiBhcmUsIGl0IG1pZ2h0IGJlDQo+ID4g dXNlZnVsIHRvIHNheSB0aGF0IHVwIGZyb250LCBtYXliZSB3aXRoIGEgc2VudGVuY2UgdGhhdCBz YXlzLCAiQWxsDQo+ID4gY2xhaW1zIGRlZmluZWQgaW4gdGhpcyBzZWN0aW9uIGFyZSBPUFRJT05B TCB0byB1c2UuIiAgKEkgZG9uJ3QgZmVlbA0KPiA+IHN0cm9uZ2x5IGFib3V0IHRoaXM7IGl0J3Mg anVzdCBhIHN1Z2dlc3Rpb24sIHNvIGRvIHdpdGggaXQgYXMgeW91IHNlZSBiZXN0LikgIFNlZQ0K PiBhbHNvIG15IGNvbW1lbnQgb24gMTAuMS4xLCBiZWxvdy4NCj4gDQo+IEVkaXRvcmlhbGx5LCB3 ZSBkZWNpZGVkIHRvIGRlc2NyaWJlIHRoZSBvcHRpb25hbGl0eSBvZiBlYWNoIGNsYWltIGluIHRo ZSBjbGFpbQ0KPiBkZWZpbml0aW9uIHNvIHRoYXQgd2hlbiB1c2VkIGFzIGEgcmVmZXJlbmNlIHdp dGhvdXQgcmVhZGluZyB0aGUgd2hvbGUgdGhpbmcsIHRoZQ0KPiBvcHRpb25hbGl0eSB3aWxsIHN0 aWxsIGJlIG9idmlvdXMgdG8gdGhlIHJlYWRlci4NCj4gDQo+ID4gLS0gU2VjdGlvbiA0LjEuMiAt LQ0KPiA+DQo+ID4gICAgVGhlIHN1YmplY3QgdmFsdWUgTUFZIGJlIHNjb3BlZCB0byBiZSBsb2Nh bGx5DQo+ID4gICAgdW5pcXVlIGluIHRoZSBjb250ZXh0IG9mIHRoZSBpc3N1ZXIgb3IgTUFZIGJl IGdsb2JhbGx5IHVuaXF1ZS4NCj4gPg0KPiA+IE9yIGl0IE1BWSBiZSBhbnl0aGluZyBlbHNlLCBp bmNsdWRpbmcgbm90IHVuaXF1ZSBhdCBhbGwuICBJcyB0aGF0IHdoYXQgeW91IG1lYW4/DQo+ID4g T3IgYXJlIHRoZXNlIG1lYW50IHRvIGJlIHR3byBvcHRpb25zLCBvbmUgb2Ygd2hpY2ggaGFzIHRv IGJlIHRydWU/ICBJZg0KPiA+IHNvLCB5b3UgbmVlZCB0byByZS1kbyB0aGlzLCBwZXJoYXBzIGxp a2UgdGhpczoNCj4gPg0KPiA+IE5FVw0KPiA+ICAgVGhlIHN1YmplY3QgdmFsdWUgTVVTVCBlaXRo ZXIgYmUgZ2xvYmFsbHkgdW5pcXVlLCBvciBiZSBzY29wZWQNCj4gPiAgIHRvIGJlIGxvY2FsbHkg dW5pcXVlIGluIHRoZSBjb250ZXh0IG9mIHRoZSBpc3N1ZXIuDQo+ID4gRU5EDQo+IA0KPiBZb3Vy IG5ldyBsYW5ndWFnZSBtYXRjaGVzIHRoZSBpbnRlbnQuICBJJ2xsIHBsYW4gdG8gcmV2aXNlIGFj Y29yZGluZ2x5Lg0KPiANCj4gPiAtLSBTZWN0aW9uIDEwLjEuMSAtLQ0KPiA+DQo+ID4gR2l2ZW4g dGhhdCB0aGUgZGVzY3JpcHRpb25zIG9mIHRoZSBjbGFpbXMgaW5jbHVkZSBhIHN0YXRlbWVudCB0 aGF0DQo+ID4gdGhlaXIgdXNlIGlzIE9QVElPTkFMLCBzaG91bGQgdGhlcmUgbm90IGJlIGFuIGVu dHJ5IGluIHRoZSB0YWJsZSB0aGF0DQo+ID4gc2F5cyB3aGV0aGVyIHRoZSBjbGFpbSBpcyBPUFRJ T05BTCBvciBSRVFVSVJFRCA/ICBPciBpcyBpdCB0aGUgaW50ZW50DQo+ID4gdGhhdA0KPiA+ICph bGwqIG9mIHRoZW0gYWx3YXlzIGJlIE9QVElPTkFMID8gIE9yIGlzIGl0IHN1ZmZpY2llbnQgdG8g aGF2ZSB0aGF0DQo+ID4gaW5kaWNhdGlvbiBpbiB0aGUgcmVmZXJlbmNlIGRvY3VtZW50YXRpb24g Pw0KPiANCj4gV2hhdCBjbGFpbXMgYXJlIHJlcXVpcmVkIGJ5IGFwcGxpY2F0aW9ucyB3aWxsIGJl IHNwZWNpZmllZCBieSBhcHBsaWNhdGlvbnMuICBGb3INCj4gaW5zdGFuY2UsIHNvbWUgYXBwbGlj YXRpb25zIHVzaW5nIEpXVHMgcmVxdWlyZSB0aGF0IHRoZSBpc3N1ZXIsIHN1YmplY3QsIGFuZA0K PiBhdWRpZW5jZSBiZSBwcmVzZW50LiAgVGhlcmVmb3JlLCBJIGRvbid0IHRoaW5rIHRoYXQgYWRk aW5nIGEgdGFibGUgZW50cnkgd291bGQNCj4gaGVscCBhIGdyZWF0IGRlYWwsIGFuZCBpdCBjb3Vs ZCBldmVuIGNvbmZ1c2Ugc29tZSBkZXZlbG9wZXJzLg0KPiANCj4gCQkJCS0tIE1pa2UNCj4gDQo+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IE9BdXRo IG1haWxpbmcgbGlzdA0KPiBPQXV0aEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29hdXRoDQo= From nobody Tue Oct 14 05:51:08 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D7B11A87C2; Tue, 14 Oct 2014 05:50:54 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id spAPxJ-zbnlB; Tue, 14 Oct 2014 05:50:49 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0138.outbound.protection.outlook.com [65.55.169.138]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C72DA1A87A1; Tue, 14 Oct 2014 05:50:48 -0700 (PDT) Received: from BN3PR0301CA0073.namprd03.prod.outlook.com (25.160.152.169) by BY1PR0301MB1205.namprd03.prod.outlook.com (25.161.203.154) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Tue, 14 Oct 2014 12:50:46 +0000 Received: from BN1AFFO11FD037.protection.gbl (2a01:111:f400:7c10::185) by BN3PR0301CA0073.outlook.office365.com (2a01:111:e400:401e::41) with Microsoft SMTP Server (TLS) id 15.0.1054.13 via Frontend Transport; Tue, 14 Oct 2014 12:50:45 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD037.mail.protection.outlook.com (10.58.52.241) with Microsoft SMTP Server (TLS) id 15.0.1039.16 via Frontend Transport; Tue, 14 Oct 2014 12:50:45 +0000 Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.93]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.03.0210.003; Tue, 14 Oct 2014 12:50:02 +0000 From: Mike Jones To: Stephen Farrell , The IESG Thread-Topic: Stephen Farrell's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) Thread-Index: Ac/nrVqJNYn7F8cTQOmeM7+Js5FUrw== Date: Tue, 14 Oct 2014 12:50:01 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439BB0D3F3@TK5EX14MBXC286.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(979002)(6009001)(438002)(479174003)(189002)(43784003)(377454003)(24454002)(13464003)(52044002)(199003)(51704005)(52604005)(31966008)(84676001)(85806002)(47776003)(20776003)(86612001)(64706001)(4396001)(23726002)(107046002)(2656002)(87936001)(50986999)(95666004)(21056001)(50466002)(230783001)(120916001)(66066001)(46406003)(33656002)(86362001)(15975445006)(99396003)(85306004)(76482002)(44976005)(19580405001)(68736004)(69596002)(92566001)(15202345003)(92726001)(97736003)(46102003)(80022003)(6806004)(97756001)(19580395003)(54356999)(85852003)(81156004)(77096002)(106466001)(55846006)(104016003)(26826002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0301MB1205; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BY1PR0301MB1205; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 03648EFF89 Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/20FueDUsgRs4EHjF5HqwbD9QCFE Cc: "oauth-chairs@tools.ietf.org" , "draft-ietf-oauth-json-web-token@tools.ietf.org" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 12:50:54 -0000 The proposed resolutions below have been included in the -28 draft. Hopefu= lly you'll be able to clear your DISCUSSes on that basis. The String Comparison Rules in Section 7.3 have been expanded to talk about= when the application may need canonicalization rules. Thanks again, -- Mike > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones > Sent: Monday, October 06, 2014 7:20 PM > To: Stephen Farrell; The IESG > Cc: oauth-chairs@tools.ietf.org; draft-ietf-oauth-json-web- > token@tools.ietf.org; oauth@ietf.org > Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-jso= n- > web-token-27: (with DISCUSS and COMMENT) >=20 > Thanks for tracking all of this Stephen. Responses inline below... >=20 > > -----Original Message----- > > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > > Sent: Monday, October 06, 2014 2:43 PM > > To: Mike Jones; The IESG > > Cc: oauth-chairs@tools.ietf.org; draft-ietf-oauth-json-web- > > token@tools.ietf.org; oauth@ietf.org > > Subject: Re: Stephen Farrell's Discuss on draft-ietf-oauth-json-web-tok= en-27: > > (with DISCUSS and COMMENT) > > > > > > Hi Mike, > > > > On 06/10/14 08:54, Mike Jones wrote: > > > Thanks for your review, Stephen. I've added the working group to > > > the thread so they're aware of your comments. > > > > > >> -----Original Message----- From: Stephen Farrell > > >> [mailto:stephen.farrell@cs.tcd.ie] Sent: Thursday, October 02, 2014 > > >> 5:03 AM To: The IESG Cc: oauth-chairs@tools.ietf.org; > > >> draft-ietf-oauth-json-web- token@tools.ietf.org Subject: Stephen > > >> Farrell's Discuss on draft-ietf-oauth-json-web-token-27: (with > > >> DISCUSS and COMMENT) > > >> > > >> Stephen Farrell has entered the following ballot position for > > >> draft-ietf-oauth-json-web-token-27: Discuss > > >> > > >> When responding, please keep the subject line intact and reply to > > >> all email addresses included in the To and CC lines. (Feel free to > > >> cut this introductory paragraph, however.) > > >> > > >> > > >> Please refer to > > >> http://www.ietf.org/iesg/statement/discuss-criteria.html for more > > >> information about IESG DISCUSS and COMMENT positions. > > >> > > >> > > >> The document, along with other ballot positions, can be found > > >> here: > > >> http://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/ > > >> > > >> > > >> > > >> ------------------------------------------------------------------- > > >> -- > > >> - > > >> > > >> > > DISCUSS: > > >> ------------------------------------------------------------------- > > >> -- > > >> - > > >> > > >> > > >> > > >> > > (1) 4.1.1 and elsewhere you say case-sensitive: the same thing I > > raised wrt DNS > > >> names for another JOSE spec - do you need to say those SHOULD be > > >> [upper|lower]cased when used in these? > > > > > > I believe that somewhere we should say that if case-insensitive > > > values, such as DNS names, are used when constructing "kid" values, > > > that the application doing so needs to define a convention on the > > > canonical case to use for the case-insensitive portions, such as > > > lowercasing them. > > > > As that discussion's happening on the key draft, I'll clear it here > > and trust you to fix if a change is the end result. >=20 > Thanks >=20 > > >> (2) Section 8: Why is "none" MTI? That seems both broken and going > > >> in the oppostite direction from other WGs and so should be > > >> explicitly jusified I think. (If a good enough justification exists > > >> that is.) > > > > > > It is MTI because there are several existing applications of JWTs in > > > which both unsigned and signed representations of the JWTs are > > > requirements. These include draft-ietf-oauth-token-exchange, > > > draft-hunt-oauth-v2-user-a4c, and OpenID Connect. This is a pretty > > > common pattern where you sign something if the recipient cares who > > > made the statements and where you don't have to sign it either if > > > the recipient doesn't care who made the statements > > > > I don't see how (non-)signers can divine non-verifier's wishes that > > way. (Absent negotiation or a directory.) >=20 > Sometimes it does occur via negotiation. For instance, in some protocols= , at > registration time, relying parties explicitly tell identity providers wha= t algorithms > are acceptable to them, which may include "none". No divination - explic= it > communication. >=20 > > > or if it can tell from > > > another secured aspect of the application protocol (typically > > > through the use of TLS) who made the statements. In the TLS case, > > > the server authentication step makes a signature step unnecessary, > > > so an Unsecured JWT is fine there. > > > > That's arguable IMO. >=20 > I agree that it's application and context-dependent whether it's OK or no= t. The > point is that there exist some circumstances in which it is OK, and this = feature is > being used in some of those cases. >=20 > > I think I'll look back over the wg thread and either hold my nose or >=20 > This issue was tracked as http://trac.tools.ietf.org/wg/jose/trac/ticket/= 36. > Karen O'Donoghue recorded this conclusion in the tracker "Note: There was > extensive discussion on the mailing list, and the rough consensus of the= working > group was to leave "none" in the document." >=20 > Discussion threads on this topic include: > [jose] #36: Algorithm "none" should be removed http://www.ietf.org/mail- > archive/web/jose/current/msg02911.html - Began Jul 31, 2013 (91 messages= ) > [jose] Text about applications and "alg":"none" http://www.ietf.org/mail- > archive/web/jose/current/msg03321.html - Began Sep 3, 2013 (5 messages) >=20 > This issue was a topic of a special working group call on Aug 19, 2013. = The text > discussed in the last thread and published at https://tools.ietf.org/html= /draft- > ietf-jose-json-web-algorithms-33#section-8.5 (Unsecured JWS Security > Considerations) was the result of the working group's decisions resulting= from all > of this discussion. >=20 > > >> (3) Section 12: another way to handle privacy is to not include > > >> sensitive data - I think you ought mention that as a bit of thought > > >> along those lines can be much simpler than putting in place the key > > >> management to handle thoughtlessly included PII. > > > > > > We can include a discussion of that point, > > > > Great. "Just say no" is workable here:-) I'll clear when we get such te= xt. > > > > > but sometimes the very > > > point of a JWT is to securely deliver PII from a verifiable party to > > > an intended party with appropriate rights to receive it. > > > > Hmm. Its a moot point (so let's not argue it) but I wonder how often > > PII is really needed for authorization with oauth. My guess would be > > that its needed far less often than its found to be profitable > > perhaps, or that carelessness plays a big role in using PII for such pu= rposes. > > > > S. > > > > > > > > > > > >> ------------------------------------------------------------------- > > >> -- > > >> - > > >> > > >> > > COMMENT: > > >> ------------------------------------------------------------------- > > >> -- > > >> - > > >> > > >> > > >> > > >> > > - abstract: 2nd sentence isn't needed here, in intro would be fine. > > > > > > I don't know - I think it's a big deal that the claims can be > > > digitally signed or MACed and/or encrypted. That's the reason we > > > have JWTs, rather than just JSON. > > > > > >> - 4.1.7: maybe worth adding that jti+iss being unique enough is not > > >> sufficient and jti alone has to meet that need. In X.509 the > > >> issuer/serial has the equivalent property so someone might assume > > >> sequential jti values starting at 0 are ok. > > > > > > Makes sense to add a warning of some kind along these lines. I > > > think I know the reasons you say that, but can you expand on that > > > thought a bit before I take a stab on writing this up? For > > > instance, while normally true, I don't think your observation is > > > true if a relying party will only accept tokens from a single issuer. > > > > > >> - section 6: yuk > > >> > > >> - again I think the secdir comments are being handled by Kathleen > > >> and the authors. > > > > > > Again, this is there because multiple applications asked for the > > > ability to represent content that is optionally signed, sometimes > > > securing it another way, such as with TLS. JWTs are used specific > > > application protocol contexts - not in isolation. > > > > > > Thanks again, -- Mike > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Tue Oct 14 05:54:49 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7BD41A87BB; Tue, 14 Oct 2014 05:54:37 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JsgT2fhAax-o; Tue, 14 Oct 2014 05:54:29 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0705.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:705]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 534E21A87C9; Tue, 14 Oct 2014 05:54:29 -0700 (PDT) Received: from DM2PR03CA0008.namprd03.prod.outlook.com (10.141.96.18) by BN3PR0301MB1204.namprd03.prod.outlook.com (25.161.207.16) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Tue, 14 Oct 2014 12:54:06 +0000 Received: from BN1BFFO11FD019.protection.gbl (2a01:111:f400:7c10::1:117) by DM2PR03CA0008.outlook.office365.com (2a01:111:e400:2428::18) with Microsoft SMTP Server (TLS) id 15.0.1054.13 via Frontend Transport; Tue, 14 Oct 2014 12:54:05 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1BFFO11FD019.mail.protection.outlook.com (10.58.144.82) with Microsoft SMTP Server (TLS) id 15.0.1039.16 via Frontend Transport; Tue, 14 Oct 2014 12:54:05 +0000 Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.93]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.193]) with mapi id 14.03.0210.003; Tue, 14 Oct 2014 12:53:34 +0000 From: Mike Jones To: Richard Barnes Thread-Topic: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) Thread-Index: Ac/nrdrrKqWsGWBcRRGbxY+GM1AWMw== Date: Tue, 14 Oct 2014 12:53:33 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439BB0D5A7@TK5EX14MBXC286.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(52604005)(24454002)(189002)(52044002)(13464003)(51704005)(43784003)(199003)(377454003)(77096002)(19580405001)(19580395003)(6806004)(44976005)(21056001)(120916001)(80022003)(46102003)(46406003)(50986999)(15202345003)(110136001)(104016003)(2656002)(85306004)(87936001)(85806002)(33656002)(55846006)(230783001)(31966008)(85852003)(4396001)(26826002)(76482002)(84676001)(68736004)(69596002)(15975445006)(47776003)(20776003)(64706001)(66066001)(50466002)(97736003)(86612001)(92726001)(92566001)(86362001)(23726002)(106466001)(54356999)(97756001)(99396003)(95666004)(107046002)(81156004); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1204; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1204; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 03648EFF89 Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/SK6TQFS43AZ7uUSlkv1m7kFK0ic Cc: "oauth-chairs@tools.ietf.org" , "oauth@ietf.org" , "draft-ietf-oauth-json-web-token@tools.ietf.org" , The IESG Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 12:54:38 -0000 The proposed resolution below has been incorporated in the -28 draft. Hope= fully you can clear your DISCUSS on that basis. Thanks again, -- Mike > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones > Sent: Saturday, October 11, 2014 12:54 PM > To: Richard Barnes > Cc: draft-ietf-oauth-json-web-token@tools.ietf.org; oauth- > chairs@tools.ietf.org; The IESG; oauth@ietf.org > Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-json-= web- > token-27: (with DISCUSS and COMMENT) >=20 > > From: Richard Barnes [mailto:rlb@ipv.sx] > > Sent: Friday, October 10, 2014 2:37 PM > > To: Mike Jones > > Cc: The IESG; oauth-chairs@tools.ietf.org; oauth@ietf.org; > > draft-ietf-oauth-json-web-token@tools.ietf.org > > Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on > > draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) > > > > On Mon, Oct 6, 2014 at 3:54 AM, Mike Jones > wrote: > > Thanks for your review, Richard. My responses are inline below... > > > > > -----Original Message----- > > > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Richard > > > Barnes > > > Sent: Wednesday, October 01, 2014 7:57 PM > > > To: The IESG > > > Cc: oauth-chairs@tools.ietf.org; oauth@ietf.org; > > > draft-ietf-oauth-json-web- token@tools.ietf.org > > > Subject: [OAUTH-WG] Richard Barnes' Discuss on > > > draft-ietf-oauth-json-web- > > > token-27: (with DISCUSS and COMMENT) > > > > > > Richard Barnes has entered the following ballot position for > > > draft-ietf-oauth-json-web-token-27: Discuss > > > > > > When responding, please keep the subject line intact and reply to > > > all email addresses included in the To and CC lines. (Feel free to > > > cut this introductory paragraph, however.) > > > > > > > > > Please refer to > > > http://www.ietf.org/iesg/statement/discuss-criteria.html > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > The document, along with other ballot positions, can be found here: > > > http://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/ > > > > > > > > > > > > -------------------------------------------------------------------- > > > -- > > > DISCUSS: > > > -------------------------------------------------------------------- > > > -- > > > > > > Section 7. > > > In order to prevent confusion between secured and Unsecured JWTs, > > > the validation steps here need to call for the application to specify= which is > required. > > > > Per my response on your JWS comments, this is already handed in a more > general way in the JWS validation steps. Specifically, the last paragrap= h of > Section 5.2 is: > > > > "Finally, note that it is an application decision which algorithms are = acceptable > in a given context. Even if a JWS can be successfully validated, unless t= he > algorithm(s) used in the JWS are acceptable to the application, it SHOULD= reject > the JWS." > > > > I've cleared this DISCUSS in the interest of having this fight over in = JWS thread. > But I also added the following COMMENT: > > "It would be good for this document to pass on the note from JWS about > selecting which algorithms are acceptable, and in particular, whether uns= ecured > JWTs are acceptable." >=20 > Thanks for clearing the DISCUSS. I'm fine repeating the note about accep= table > algorithms in the JWT spec, assuming others are. >=20 > > I would therefore request that you likewise withdraw this DISCUSS on th= at > basis. >=20 > -- Mike >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Tue Oct 14 05:55:00 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D71921A87BB; Tue, 14 Oct 2014 05:54:41 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EvBqlIA6lKSB; Tue, 14 Oct 2014 05:54:30 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0702.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:702]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C3141A87CA; Tue, 14 Oct 2014 05:54:29 -0700 (PDT) Received: from BN3PR0301CA0067.namprd03.prod.outlook.com (25.160.152.163) by DM2PR0301MB1216.namprd03.prod.outlook.com (25.160.219.17) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Tue, 14 Oct 2014 12:54:06 +0000 Received: from BY2FFO11FD045.protection.gbl (2a01:111:f400:7c0c::147) by BN3PR0301CA0067.outlook.office365.com (2a01:111:e400:401e::35) with Microsoft SMTP Server (TLS) id 15.0.1049.19 via Frontend Transport; Tue, 14 Oct 2014 12:54:06 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD045.mail.protection.outlook.com (10.1.15.177) with Microsoft SMTP Server (TLS) id 15.0.1039.16 via Frontend Transport; Tue, 14 Oct 2014 12:54:05 +0000 Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.93]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.03.0210.003; Tue, 14 Oct 2014 12:53:27 +0000 From: Mike Jones To: Ted Lemon , John Bradley Thread-Topic: Ted Lemon's No Objection on draft-ietf-oauth-json-web-token-27: (with COMMENT) Thread-Index: Ac/nrdghljtsJxvvTAasWMq+smkawA== Date: Tue, 14 Oct 2014 12:53:26 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439BB0D59F@TK5EX14MBXC286.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(13464003)(189002)(43784003)(199003)(51704005)(24454002)(377454003)(97756001)(31966008)(85306004)(54356999)(50986999)(230783001)(46102003)(87936001)(85806002)(2656002)(120916001)(80022003)(104016003)(20776003)(64706001)(66066001)(47776003)(4396001)(97736003)(99396003)(107046002)(95666004)(92566001)(6806004)(106466001)(84676001)(81156004)(92726001)(15975445006)(44976005)(19580395003)(19580405001)(21056001)(86362001)(50466002)(86612001)(55846006)(76482002)(77096002)(85852003)(69596002)(68736004)(23726002)(33656002)(46406003)(26826002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB1216; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB1216; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 03648EFF89 Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/KF040EpmpHEOsCAdsBFxq2EwAcs Cc: "draft-ietf-oauth-json-web-token@tools.ietf.org" , "oauth-chairs@tools.ietf.org" , "oauth@ietf.org" , The IESG Subject: Re: [OAUTH-WG] Ted Lemon's No Objection on draft-ietf-oauth-json-web-token-27: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 12:54:42 -0000 The proposed resolution below has been applied to the -28 draft. Thanks again, -- Mike > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones > Sent: Tuesday, October 07, 2014 6:06 PM > To: Ted Lemon; John Bradley > Cc: oauth-chairs@tools.ietf.org; oauth@ietf.org; The IESG; draft-ietf-oau= th- > json-web-token@tools.ietf.org > Subject: Re: [OAUTH-WG] Ted Lemon's No Objection on draft-ietf-oauth-json= - > web-token-27: (with COMMENT) >=20 > > -----Original Message----- > > From: Ted Lemon [mailto:Ted.Lemon@nominum.com] > > Sent: Tuesday, October 07, 2014 10:30 AM > > To: John Bradley > > Cc: The IESG; Mike Jones; draft-ietf-oauth-json-web-token@tools.ietf.or= g; > > oauth-chairs@tools.ietf.org; oauth@ietf.org > > Subject: Re: Ted Lemon's No Objection on draft-ietf-oauth-json-web-toke= n- > 27: > > (with COMMENT) > > > > On Oct 7, 2014, at 1:14 PM, John Bradley wrote: > > > Encrypting and then signing is likely only a special case used by som= e > > applications that are configured to understand what is going on. > > > > This isn't really responsive to what I said. As I said, I'm just aski= ng you to be > > consistent, not to change the requirements. I don't think that text i= n the > > security considerations section addresses the inconsistency I'm talking= about in > a > > different section. That said, please don't continue to talk to me abo= ut this. If > > you think there's an action to take, take it. If not, no need to cont= inue trying > to > > explain. I'm okay with it either way. >=20 > I'll plan to take the action described yesterday that you said you were O= K with - > adding language about "If both signing and encryption are necessary" in o= rder to > make the context of this advice clear. I believe that that will improve = the > understanding of this guidance by many readers. >=20 > Thanks again for the discussion, Ted. >=20 > -- Mike >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Tue Oct 14 06:36:55 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E8241A8862; Tue, 14 Oct 2014 06:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.186 X-Spam-Level: X-Spam-Status: No, score=-1.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IXHASH_X1=1.5, RP_MATCHES_RCVD=-0.786] autolearn=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 qH2-Pt05kei5; Tue, 14 Oct 2014 06:36:50 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C770B1A8704; Tue, 14 Oct 2014 06:36:50 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id AB1621B83DA; Tue, 14 Oct 2014 06:36:50 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id A012853E079; Tue, 14 Oct 2014 06:36:50 -0700 (PDT) Received: from [192.168.1.63] (71.201.198.58) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 14 Oct 2014 06:36:50 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439BB0D59F@TK5EX14MBXC286.redmond.corp.microsoft.com> Date: Tue, 14 Oct 2014 08:36:47 -0500 Content-Transfer-Encoding: 7bit Message-ID: <92E14912-EF3B-4365-BC91-2AEC51A46511@nominum.com> References: <4E1F6AAD24975D4BA5B16804296739439BB0D59F@TK5EX14MBXC286.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.201.198.58] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/TNiz35JUQPYNkp6VSsx_FfI5Zck Cc: "oauth-chairs@tools.ietf.org" , "draft-ietf-oauth-json-web-token@tools.ietf.org" , "oauth@ietf.org" , The IESG Subject: Re: [OAUTH-WG] Ted Lemon's No Objection on draft-ietf-oauth-json-web-token-27: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 13:36:51 -0000 On Oct 14, 2014, at 7:53 AM, Mike Jones wrote: > The proposed resolution below has been applied to the -28 draft. Thanks! From nobody Tue Oct 14 09:54:17 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1CE1A8AE9; Tue, 14 Oct 2014 09:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.685 X-Spam-Level: X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yy4zMIfj3DFs; Tue, 14 Oct 2014 09:54:09 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id 3A9701A8AB2; Tue, 14 Oct 2014 09:54:09 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id CA60172E165; Tue, 14 Oct 2014 12:54:08 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id 8A81E72E154; Tue, 14 Oct 2014 12:54:08 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.195]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.03.0174.001; Tue, 14 Oct 2014 12:54:07 -0400 From: "Richer, Justin P." To: Phil Hunt Thread-Topic: [OAUTH-WG] [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-16.txt Thread-Index: AQHP5n3sqUqcR0TG3kyoHDqfoyksfZwwFQAA Date: Tue, 14 Oct 2014 16:54:06 +0000 Message-ID: References: <543914E8.8070507@lodderstedt.net> <54391575.9080707@lodderstedt.net> <11F6D8A7-003C-45B7-8B2D-98D8CB0EA285@oracle.com> In-Reply-To: <11F6D8A7-003C-45B7-8B2D-98D8CB0EA285@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.15.56] Content-Type: multipart/alternative; boundary="_000_ECC1233B12834CBD89E10568E03968C1mitreorg_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/y0iIBPTwG7oE5OmJN1xBN-OZAZs Cc: "kitten@ietf.org" , "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-16.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 16:54:14 -0000 --_000_ECC1233B12834CBD89E10568E03968C1mitreorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I agree with Phil on this one (hey, it happens!): this is a classic example= of having one piece of software and many instances of it talking to many d= ifferent service providers. Each of those pairings is going to need to agre= e on a client ID, and one would hope a client secret or equivalent. It's no= t feasible to pre-pack these even with a single authorization service (and = Google and MS are setting a bad example here), let alone every server ever.= Classical OAuth has a strong relationship between the client developer and= the protected resource provider, but this relationship starts to dissolve = when you're talking about common APIs. OpenID Connect is one such common AP= I that we're seeing in the web space (and SCIM will likely be another), but= the SASL work is going to open up a whole slew of "common" protected APIs = that could use OAuth. As such, dynamic registration is going to be essential for this to be inter= operable and scale beyond a single provider / consumer-app pair, and it mak= es perfect sense for Kitten to adopt it here. -- Justin On Oct 12, 2014, at 8:37 PM, Phil Hunt > wrote: Torsten, Big +1 to your comments. I think the SASL-OAuth work is very important work and it is the *classic* = use case for OAuth Dynamic Registration. SASL clients are typically developed independently of server implementation= and are meant to work with any server. This means that having a pre-negot= iated client_id is pretty much impossible without dyn reg or some equivalen= t solution =97 and why do another? There may be simpler profiles you can develop specific to SASL, but I think= OAuth Dyn Reg should work well for this use case. Phil @independentid www.independentid.com phil.hunt@oracle.com On Oct 11, 2014, at 4:33 AM, Torsten Lodderstedt > wrote: Hi all, there is some discussion going on in the KITTEN WG regarding the SASL/Oauth= mechanism that might be of interest for the OAuth WG as well. kind regards, Torsten. -------- Original-Nachricht -------- Betreff: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-16.tx= t Datum: Sat, 11 Oct 2014 13:30:48 +0200 Von: Torsten Lodderstedt An: Kitten@ietf.org Kopie (CC): tjs@psaux.com Hi all, as one of the proposers (beside Hannes) of the change, I would like to expl= ain the rationale. > -16 is submitted, and there is one suggested change (which I was supposed= to have added in already and blew it), which is to replace section 3.2.2 w= ith the text (farther) below. My comments on the suggested text: > #1) I don't think the dynamic registration stuff is baked enough to want= to pull that in to the "oauth-configuration" definition. I don't want to p= ull it in because I don't think dynamic registration is required for SASL/O= AUTH (as evidenced by the Google and Outlook.com imple= mentations. Existing implementations at Google and Outlook.com are= no evidence against dynamic client registration. They demonstrate that it = is possible to implement the server side. But we are talking about clients (more precis= ely about generic clients). I'm not aware of any generic client implementing the SASL mechanisms in the moment. I recommend taking a= look at https://bugzilla.mozilla.org/show_bug.cgi?id=3D849540. Before I dive into the registration details, I would like to give my person= al summary why this SASL profile is needed. In my opinion, one of the main purposes of this mechanism is to allow gener= ic clients to authorize access to standard protocols, such as IMAP, using OAuth Access Tokens. This offers the following advantages: - multi-factor authn: An increasing number of service providers (e.g. Googl= e, Yahoo, Apple) offer 2-factor authentication to their users, but only for apps and web sites. Why? It currently does not work in conjunc= tion with IMAP and the like. Instead, application-specific passwords must be used, which offer a terrible user experience and therefore are a si= gnificant burden for better Internet security. Using OAuth access tokens allows to decouple service access and authentication/authorization process.= So the authorization server can choose the appropriate/available mechanisms to authenticate at its discretion. This also allows to use any k= ind of (provider-specific) multi-factor authentication methods also in the context of IMAP and the like. - Furthermore, using OAuth also allows to use refresh tokens as persistent = credential for service login, that way eleminating the need to store user passwords on devices. So basically, the SASL OAuth profile can (at least in my opinion) be a majo= r leap forward in Internet security. Why does this require dynamic registration? Well, OAuth requires any client to possess a client_id (and client_secret) = with the particular authorization server. Nowadays developers typically register with the authz server's provider out of band and bake the credenti= als into the software package. This works for clients, which are directly programmed against a certain deployment/API, such as Facebook,= but is inappropriate (if not unfeasible) for generic clients using standardized protocols, e.g. Thunderbird. Or do you want to register the Thunderbird deveopers with every e-Mail/Cale= ndar-provider in the world up-front? I don't think so. That's why the OAuth WG came up with the specification fo= r dynamic client registration, which allows the client to dynamically obtain client credentials from the authorization = server. It basically solves the client credential challenge for generic clients, but it does integrate the registration step into an overall proces= s. That's why I think we must define a way for a generic SASL client to, based= on user-provided data, find the appropriate authorization server and register with it. I think the SASL mechanism should specify how those mecha= nisms are used in concert in order to authorize service access using OAuth. Otherwise, the SASL mechanism can only be used for point to point integrati= ons among partners but never for generic clients. So I think true interoperability calls for addition of registration as well= . Regarding state of dynamic client registration: It's not ratified yet but a= lready sent to IESG for publication. Beside that it is already implement in existing OpenId Connect deployments. > #2) I didn't really want to make all of the OpenID elements required but= I don't have a strong opinion here, my initial intent was to use the OpenI= D Discovery format as an existing format to be re-used here but leave it fl= exible. Agreed. Using the format as specified by OpenID Connect makes sense. As gen= eric OAuth differs from OpenID Connect, the WG should (probably in cooperat= ion with the OAuth WG) discuss, which elements are really needed. > #3) I am against recommending scope names at all in any way. I would no= t include the last sentence of paragraph 5 below and strike the scope names= . Given there is already a response parameter scope, which intructs the clien= t on what scope to use in the authz request, I tend to agree. I'm not yet f= ully convinced whether this approach will work. But let's give it a try. kind regards, Torsten. > New text for 3.2.2: > ----------------------- > 3.2.2. Server Response to Failed Authentication > > > For a failed authentication the server returns a JSON [RFC4627] > formatted error result, and fails the authentication. The error > result consists of the following values: > > > status (REQUIRED): The authorization error code. Valid error > codes are defined in the IANA "OAuth Extensions Error Registry" > specified in the OAuth 2 core specification. > > > scope (OPTIONAL): An OAuth scope which is valid to access the > service. This may be empty which implies that unscoped tokens > are required, or a scope value. If a scope is specified then a > single scope is preferred, use of a space separated list of > scopes is NOT RECOMMENDED. > > > oauth-configuration (OPTIONAL): The URL for a document following > the OpenID Provider Configuration Information schema, as > described in Section 3 of the OpenID Connect Discovery > [OpenID.Discovery], that is appropriate for the user. The > server MAY return different URLs for users from different > domains and a client MUST NOT cache a single returned value and > assume it applies for all users/domains that the server > suports. The returned discovery document MUST have all data > elements required by the OpenID Connect Discovery specification > populated. In addition, the discovery document MUST contain > the 'registration_endpoint' element to learn about the endpoint > to be used with the Dynamic Client Registration protocol > [I-D.ietf-oauth-dyn-reg] to obtain the minimum number of > parameters necessary for the OAuth protocol exchange to > function. Authorization servers MUST implement the > authorization code grant and other grant types MAY be > supported. Furthermore, authorization servers MUST implement > the ability to issue refresh tokens for use with native > applications to benefit from an abbreviated protocol exchange. > The use of the 'offline_access' scope, as defined in > [OpenID.Core] is RECOMMENDED to give clients the capability to > explicitly request a refresh token. > > > If the resource server provides a scope (as part of the element of > the configuration payload) then the client MUST always request > scoped tokens from the token endpoint. This specification > RECOMMMENDs the use of the following scopes: > > imap: The 'imap' scope value is used to interact with IMAP mail > servers. > > pop3: The 'pop3' scope value is used to interact with POP3 mail > servers. > > xmpp: The 'xmpp' scope value is used to interact with XMPP servers. > > > > If the resource server provides no scope to the client then the > client SHOULD presume an empty scope (unscoped token) is needed. > > > Since clients may interact with a number of application servers, > such as email servers and XMPP servers, they need to have a way > to determine whether dynamic client registration has been performed > already and whether an already available refresh token can be > re-used to obtain an access token for the desired resource server. > This specification RECOMMENDs that a client uses the information in > the 'issue' element to make this determination. > ----------------------- > > > I think we're getting very close :) > > -bill _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_ECC1233B12834CBD89E10568E03968C1mitreorg_ Content-Type: text/html; charset="Windows-1252" Content-ID: <29D9299A6747334FB827DE3D32F32DF2@imc.mitre.org> Content-Transfer-Encoding: quoted-printable I agree with Phil on this one (hey, it happens!): this is a classic example= of having one piece of software and many instances of it talking to many d= ifferent service providers. Each of those pairings is going to need to agre= e on a client ID, and one would hope a client secret or equivalent. It's not feasible to pre-pack these ev= en with a single authorization service (and Google and MS are setting a bad= example here), let alone every server ever. Classical OAuth has a strong r= elationship between the client developer and the protected resource provider, but this relationship starts to disso= lve when you're talking about common APIs. OpenID Connect is one such commo= n API that we're seeing in the web space (and SCIM will likely be another),= but the SASL work is going to open up a whole slew of "common" protected APIs that could use OAuth.

As such, dynamic registration is going to be essential for this to be = interoperable and scale beyond a single provider / consumer-app pair, and i= t makes perfect sense for Kitten to adopt it here.

 -- Justin

On Oct 12, 2014, at 8:37 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Torsten,

Big +1 to your comments.

I think the SASL-OAuth work is very important work and it is the *clas= sic* use case for OAuth Dynamic Registration.

SASL clients are typically developed independently of server implement= ation and are meant to work with any server.  This means that having a= pre-negotiated client_id is pretty much impossible without dyn reg or some= equivalent solution =97 and why do another?

There may be simpler profiles you can develop specific to SASL, but I = think OAuth Dyn Reg should work well for this use case.

Phil<= /span>

On Oct 11, 2014, at 4:33 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Hi all,

there is some discussion going on in the KITTEN WG regarding the SASL/Oauth= mechanism that might be of interest for the OAuth WG as well.

kind regards,
Torsten.


-------- Original-Nachricht --------
Betreff: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-16.txt
Datum: Sat, 11 Oct 2014 13:30:48 +0200
Von: Torsten Lodderstedt <torsten@lodderstedt.net>
An: K= itten@ietf.org
Kopie (CC): tjs= @psaux.com <tjs@ps= aux.com> 


Hi all,

as one of the proposers (beside Hannes) of the change, I would like to expl=
ain the rationale.

> -16 is submitted, and there is one suggested change (which I was suppo=
sed to have added in already and blew it), which is to replace section 3.2.=
2 with the text (farther) below. My comments on the suggested text:

> #1)  I don't think the dynamic registration stuff is baked enough to w=
ant to pull that in to the "oauth-configuration" definition. I do=
n't want to pull it in because I don't think dynamic registration is requir=
ed for SASL/OAUTH (as evidenced by the Google and Outlook.com implementations.


Existing implementations at Google and Outl=
ook.com are no evidence against dynamic client registration. They demon=
strate that it is possible
to implement the server side. But we are talking about clients (more precis=
ely about generic clients). I'm not aware of any generic
client implementing the SASL mechanisms in the moment. I recommend taking a=
 look at https://bugzilla.mozilla.org/show_bug.cgi?i=
d=3D849540.

Before I dive into the registration details, I would like to give my person=
al summary why this SASL profile is needed.
=20
In my opinion, one of the main purposes of this mechanism is to allow gener=
ic clients to authorize access to standard protocols, such as IMAP,
using OAuth Access Tokens. This offers the following advantages:

- multi-factor authn: An increasing number of service providers (e.g. Googl=
e, Yahoo, Apple) offer 2-factor authentication to their users,
but only for apps and web sites. Why? It currently does not work in conjunc=
tion with IMAP and the like. Instead, application-specific passwords
must be used, which offer a terrible user experience and therefore are a si=
gnificant burden for better Internet security. Using OAuth access tokens
allows to decouple service access and authentication/authorization process.=
 So the authorization server can choose the appropriate/available
mechanisms to authenticate at its discretion. This also allows to use any k=
ind of (provider-specific) multi-factor authentication methods also
in the context of IMAP and the like.

- Furthermore, using OAuth also allows to use refresh tokens as persistent =
credential for service login, that way eleminating the need to store user
passwords on devices.
=20
So basically, the SASL OAuth profile can (at least in my opinion) be a majo=
r leap forward in Internet security.

Why does this require dynamic registration?

Well, OAuth requires any client to possess a client_id (and client_secret) =
with the particular authorization server. Nowadays developers typically
register with the authz server's provider out of band and bake the credenti=
als into the software package. This works for clients, which
are directly programmed against a certain deployment/API, such as Facebook,=
 but is inappropriate (if not unfeasible) for generic
clients using standardized protocols, e.g. Thunderbird.

Or do you want to register the Thunderbird deveopers with every e-Mail/Cale=
ndar-provider in the world up-front?

I don't think so. That's why the OAuth WG came up with the specification fo=
r dynamic client registration, which allows
the client to dynamically obtain client credentials from the authorization =
server. It basically solves the client credential challenge for generic
clients, but it does integrate the registration step into an overall proces=
s.

That's why I think we must define a way for a generic SASL client to, based=
 on user-provided data, find the appropriate authorization server and
register with it. I think the SASL mechanism should specify how those mecha=
nisms are used in concert in order to authorize service access using OAuth.
Otherwise, the SASL mechanism can only be used for point to point integrati=
ons among partners but never for generic clients.

So I think true interoperability calls for addition of registration as well=
.

Regarding state of dynamic client registration: It's not ratified yet but a=
lready sent to IESG for publication.
Beside that it is already implement in existing OpenId Connect deployments.

> #2)  I didn't really want to make all of the OpenID elements required =
but I don't have a strong opinion here, my initial intent was to use the Op=
enID Discovery format as an existing format to be re-used here but leave it=
 flexible.

Agreed. Using the format as specified by OpenID Connect makes sense. As gen=
eric OAuth differs from OpenID Connect, the WG should (probably in cooperat=
ion with
the OAuth WG) discuss, which elements are really needed.

> #3)  I am against recommending scope names at all in any way.  I would=
 not include the last sentence of paragraph 5 below and strike the scope na=
mes.


Given there is already a response parameter scope, which intructs the clien=
t on what scope to use in the authz request, I tend to agree. I'm not yet f=
ully
convinced whether this approach will work. But let's give it a try.

kind regards,
Torsten.



>   New text for 3.2.2:
> -----------------------
> 3.2.2.  Server Response to Failed Authentication
>
>
> For a failed authentication the server returns a JSON [RFC4627]
> formatted error result, and fails the authentication.  The error
> result consists of the following values:
>
>
> status (REQUIRED):  The authorization error code.  Valid error
> codes are defined in the IANA "OAuth Extensions Error Registry&qu=
ot;
> specified in the OAuth 2 core specification.
>
>
> scope (OPTIONAL):  An OAuth scope which is valid to access the
> service.  This may be empty which implies that unscoped tokens
> are required, or a scope value.  If a scope is specified then a
> single scope is preferred, use of a space separated list of
> scopes is NOT RECOMMENDED.
>
>
> oauth-configuration (OPTIONAL):  The URL for a document following
> the OpenID Provider Configuration Information schema, as
> described in Section 3 of the OpenID Connect Discovery
> [OpenID.Discovery], that is appropriate for the user.  The
> server MAY return different URLs for users from different
> domains and a client MUST NOT cache a single returned value and
> assume it applies for all users/domains that the server
> suports.  The returned discovery document MUST have all data
> elements required by the OpenID Connect Discovery specification
> populated.  In addition, the discovery document MUST contain
> the 'registration_endpoint' element to learn about the endpoint
> to be used with the Dynamic Client Registration protocol
> [I-D.ietf-oauth-dyn-reg] to obtain the minimum number of
> parameters necessary for the OAuth protocol exchange to
> function.  Authorization servers MUST implement the
> authorization code grant and other grant types MAY be
> supported.  Furthermore, authorization servers MUST implement
> the ability to issue refresh tokens for use with native
> applications to benefit from an abbreviated protocol exchange.
> The use of the 'offline_access' scope, as defined in
> [OpenID.Core] is RECOMMENDED to give clients the capability to
> explicitly request a refresh token.
>
>
> If the resource server provides a scope (as part of the element of
> the configuration payload) then the client MUST always request
> scoped tokens from the token endpoint.  This specification
> RECOMMMENDs the use of the following scopes:
>
> imap:  The 'imap' scope value is used to interact with IMAP mail
> servers.
>
> pop3:  The 'pop3' scope value is used to interact with POP3 mail
> servers.
>
> xmpp:  The 'xmpp' scope value is used to interact with XMPP servers.
>
>
>
> If the resource server provides no scope to the client then the
> client SHOULD presume an empty scope (unscoped token) is needed.
>
>
> Since clients may interact with a number of application servers,
> such as email servers and XMPP servers, they need to have a way
> to determine whether dynamic client registration has been performed
> already and whether an already available refresh token can be
> re-used to obtain an access token for the desired resource server.
> This specification RECOMMENDs that a client uses the information in
> the 'issue' element to make this determination.
> -----------------------
>
>
> I think we're getting very close :)
>
> -bill




_______________________________________________
Kitten mailing list
Kitte=
n@ietf.org
https://www.ietf.org/mailman/listinfo/kitten


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

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

--_000_ECC1233B12834CBD89E10568E03968C1mitreorg_-- From nobody Tue Oct 14 13:42:22 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF3B1ACE82; Tue, 14 Oct 2014 13:42:15 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3j5SwCOYzbG; Tue, 14 Oct 2014 13:42:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 873821A9139; Tue, 14 Oct 2014 13:42:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Pete Resnick" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141014204213.15568.37128.idtracker@ietfa.amsl.com> Date: Tue, 14 Oct 2014 13:42:13 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/q3pEqtzXZpdHdJ_XQAl9Yt2SFLg Cc: draft-ietf-oauth-assertions@tools.ietf.org, oauth-chairs@tools.ietf.org, oauth@ietf.org Subject: [OAUTH-WG] Pete Resnick's No Objection on draft-ietf-oauth-assertions-17: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 20:42:15 -0000 Pete Resnick has entered the following ballot position for draft-ietf-oauth-assertions-17: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 3 - Assertions used in the protocol exchanges defined by this specification MUST always be protected against tampering using a digital signature or a keyed message digest applied by the issuer. Why is that? Aren't you using assertions over a protected channel (as required by the spec) and therefore not need to sign the assertions? Indeed, why would a self-issued Bearer Assertion need to be signed at all? Does that even make sense? 4.1 - grant_type REQUIRED. The format of the assertion as defined by the authorization server. The value MUST be an absolute URI. That MUST is unnecessary. It's just definitional from 6749, 4.5 (which, as it happens, doesn't use 2119 language for this). s/MUST/will assertion REQUIRED. The assertion being used as an authorization grant. Specific serialization of the assertion is defined by profile documents. The serialization MUST be encoded for transport within HTTP forms. It is RECOMMENDED that base64url be used. The MUST seems weird here. Are you saying that the profile could not possibly have a serialization for an assertion that did not require further encoding? But the RECOMMENDED seems downright wrong: Either an implementer *needs* to know the encoding independently of the profile, and therefore this needs to be a MUST, or the profile is going to describe the encoding, which could be base64url or could be something else, and the implementation will do whatever the profile says. If you really want to say something here, I suggest replacing the last two sentences with: If the assertion is going to be transported within HTTP forms, the profile document needs to describe what (if any) encoding will be needed to do so. The base64url encoding is widely implemented and therefore suggested. scope [...] As such, the requested scope MUST be equal or lesser than the scope originally granted to the authorized accessor. s/MUST/will (unless you explain whether it's the server or the client that's supposed to be obeying that MUST, and for what reason) If the scope parameter and/or value are omitted, the scope MUST be treated as equal to the scope originally granted to the authorized accessor. The Authorization Server MUST limit the scope of the issued access token to be equal or lesser than the scope originally granted to the authorized accessor. In the first sentence, is this MUST for the server? (That is, shouldn't it be, "If the scope parameter and/or value are omitted, the server MUST use the value of the scope originally granted to the authorized accessor."?) And anyway, don't these two sentences contradict 6749, which says: The authorization server MAY fully or partially ignore the scope requested by the client, based on the authorization server policy or the resource owner's instructions. [...] If the client omits the scope parameter when requesting authorization, the authorization server MUST either process the request using a pre-defined default value or fail the request indicating an invalid scope. Here and throughout: s/non-normative example/example (As far as I know, there are no other kinds in IETF documents.) 4.1.1 - s/MUST construct/constructs 4.2, client_assertion_type and client_assertion: See comments from 4.1 regarding grant_type and assertion. 4.2.1 - s/MUST construct/constructs 5.2 - s/MUST identify/identifies For clarification: OLD Assertions that do not identify the Authorization Server as an intended audience MUST be rejected. NEW The Authorization Server MUST reject any assertion that does not contain the its own identity as the intended audience. END From nobody Tue Oct 14 18:56:14 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9D3A1A0119; Tue, 14 Oct 2014 18:56:10 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gSoxGkSSeTFJ; Tue, 14 Oct 2014 18:56:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 705BB1A0115; Tue, 14 Oct 2014 18:56:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Pete Resnick" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141015015609.5671.70479.idtracker@ietfa.amsl.com> Date: Tue, 14 Oct 2014 18:56:09 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/O_4rbQKn6ybEWb8ovUznEWnwyqs Cc: oauth-chairs@tools.ietf.org, draft-ietf-oauth-saml2-bearer@tools.ietf.org, oauth@ietf.org Subject: [OAUTH-WG] Pete Resnick's No Objection on draft-ietf-oauth-saml2-bearer-21: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 01:56:11 -0000 Pete Resnick has entered the following ballot position for draft-ietf-oauth-saml2-bearer-21: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 2.1/2.2 - This paragraph shows why I don't like haphazard use of 2119. The first "MUST be" is obviously silly and should simply be "is". But the second one buries what *might* be a proper and important use of MUST (you MUST NOT try to stick in two SAML Assertions) with a simple definitional one. (And that assumes that it's even plausible to try to use more than one SAML Assertion. If you simply can't, it's just s/MUST contain/contains.) The base64url encoding MUST is fine, because you don't want people sticking in raw XML, but the SHOULD NOTs for line wrapping and pad I am curious about: Isn't a parser going to have to check for line wrapping and pad anyway and undo it (because it's not a MUST NOT), and therefore this SHOULD NOT really isn't about interoperability so much as neatness (in which case they SHOULD NOTs are not appropriate)? 3 - Subpoint 2: Just for clarification, I like the non-passive sentence better: "The Authorization Server MUST reject any assertion that does not contain its own identity as the intended audience." Subpoint 5: OLD The element MUST contain a element, unless the Assertion has a suitable NotOnOrAfter attribute on the element, in which case the element MAY be omitted. That one's sure to get misquoted somewhere and confuse someone. Instead: NEW If the Assertion does not have a suitable NonOnOrAfter attribute on the element, the element MUST contain a element. Subpoint 6: OLD The authorization server MUST verify that the NotOnOrAfter instant has not passed, subject to allowable clock skew between systems. An invalid NotOnOrAfter instant on the element invalidates the entire Assertion. An invalid NotOnOrAfter instant on a element only invalidates the individual . NEW The authorization server MUST reject the entire Assertion if the NotOnOrAfter instant on the element has passed (subject to allowable clock skew between systems). The authorization server MUST reject the (but MAY still use the rest of the Assertion) if the NotOnOrAfter instant on the has passed (subject to allowable clock skew). Subpoint 7: Are you sure those SHOULDs and SHOULD NOTs are not conflicting? Can you not have an authenticated subject with an autonomously acting client? Subpoint 9: As I asked in the -assertions document, is this really a requirement? Subpoint 11: Again, it would be better to put the MUST on the action (e.g., "MUST reject") to make it clear who is doing what. 3.1/3.2 - s/MUST construct/constructs 4 - s/Though non-normative// 9 - Seems like OASIS.saml-deleg-cs and OASIS.saml-sec-consider-2.0-os are Normative, not Informative. From nobody Tue Oct 14 19:05:14 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 130DC1A012D; Tue, 14 Oct 2014 19:05:11 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IxyR5ahNOJym; Tue, 14 Oct 2014 19:05:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A93A41A004C; Tue, 14 Oct 2014 19:05:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Pete Resnick" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141015020509.5671.13432.idtracker@ietfa.amsl.com> Date: Tue, 14 Oct 2014 19:05:09 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/2SmeS_npJtG8bq8-NAf415shIYw Cc: oauth-chairs@tools.ietf.org, draft-ietf-oauth-jwt-bearer@tools.ietf.org, oauth@ietf.org Subject: [OAUTH-WG] Pete Resnick's No Objection on draft-ietf-oauth-jwt-bearer-10: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 02:05:11 -0000 Pete Resnick has entered the following ballot position for draft-ietf-oauth-jwt-bearer-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm not going to repeat stuff that is identical to draft-ietf-oauth-saml2-bearer (and I did find that using was very helpful). Please refer to my comments on that document. From nobody Tue Oct 14 21:34:11 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39D0D1A0204; Tue, 14 Oct 2014 21:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5t0jk8BgPKh8; Tue, 14 Oct 2014 21:33:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 39BFB1A0262; Tue, 14 Oct 2014 21:33:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141015043339.3055.38661.idtracker@ietfa.amsl.com> Date: Tue, 14 Oct 2014 21:33:39 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/dbVY-SJjlECar_ZIPQi1G7-Inek Cc: draft-ietf-oauth-assertions@tools.ietf.org, oauth-chairs@tools.ietf.org, oauth@ietf.org Subject: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-assertions-17: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 04:34:01 -0000 Barry Leiba has entered the following ballot position for draft-ietf-oauth-assertions-17: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Pete did a nice job on the 2119 key words, so I have nothing to add there. -- Section 6.1 -- The example in Section 4.2 that shows a client authenticating using an assertion during an Access Token Request. Is "that" an extra word that should be removed? (Also in Section 6.3.) From nobody Wed Oct 15 06:44:23 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EDF11A6FD4 for ; Wed, 15 Oct 2014 06:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oMLnoExpODUO for ; Wed, 15 Oct 2014 06:44:18 -0700 (PDT) Received: from na3sys009aog102.obsmtp.com (na3sys009aog102.obsmtp.com [74.125.149.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDB341A6FCF for ; Wed, 15 Oct 2014 06:44:16 -0700 (PDT) Received: from mail-ig0-f177.google.com ([209.85.213.177]) (using TLSv1) by na3sys009aob102.postini.com ([74.125.148.12]) with SMTP ID DSNKVD56MBMPvXBrhDYJec09UWWBL8OVYtC0@postini.com; Wed, 15 Oct 2014 06:44:16 PDT Received: by mail-ig0-f177.google.com with SMTP id a13so1412331igq.4 for ; Wed, 15 Oct 2014 06:44:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=N04x3PadiC2NHSw8yOo2Qy9bYpUAVTQBjXXnwPKFzMU=; b=PhijaMTzYWloBc31uZTY8oP+itu9mkXdQDHudAqjrMK61+D2HuoMMbDZPGS3pOzSO0 qMRW0kriqNRbKD3g1wlp69nslQh6/AjNkAFMhUX2ul8DI625Q38SJ3Ew8zEGAkhLweSB vBdz+yDE8/voHn/9Rky5O1uGBgZVmJuQjLsGLEzPQvJ8Uvp2oDvj33k95nMimpkSwdTT 9GO5LK2Sd6W832DhvawHCyUVaEd1u43TrtinB2X5T+hMiCejYJVO2CwEq95TmL4vZeZA XQBZ8vsNWmT3aX7gYzc6dSatGzdVz5/gvXGBeSxo3MuVZ7Rt8hcEPb6c7zgMirriJq5P 11vQ== X-Gm-Message-State: ALoCoQkHH2P4y2BmvH5nAGhHE+Ihk5r46koGJovLpB2Ks3hKQTAngGl6KMZ/Sv7wpuiIjDzgSnQ+3dxFyhaviyh8zhPugTqxbPShNYZBmMFE3UgPckTFt2d34ORJEWn8rT9CWKlrTf7X X-Received: by 10.43.76.199 with SMTP id zf7mr2648575icb.57.1413380656147; Wed, 15 Oct 2014 06:44:16 -0700 (PDT) X-Received: by 10.43.76.199 with SMTP id zf7mr2648551icb.57.1413380655903; Wed, 15 Oct 2014 06:44:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.12.137 with HTTP; Wed, 15 Oct 2014 06:43:45 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Wed, 15 Oct 2014 07:43:45 -0600 Message-ID: To: The IESG , "secdir@ietf.org" , draft-ietf-oauth-saml2-bearer@tools.ietf.org, Vincent Roca , oauth Content-Type: multipart/alternative; boundary=001a11c3b252ed93960505765399 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/STs8Ob3aq6yHYxmZ-jiSmw2ChOw Subject: Re: [OAUTH-WG] Secdir review of draft-ietf-oauth-saml2-bearer-21 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 13:44:21 -0000 --001a11c3b252ed93960505765399 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for your review and feedback, Vincent. I'm adding the working group to the thread so they=E2=80=99re aware of the comments. Replies are inline = below... From: Vincent Roca > Date: Tue, Oct 14, 2014 at 9:10 AM > Subject: Secdir review of draft-ietf-oauth-saml2-bearer-21 > To: IESG , secdir@ietf.org, > draft-ietf-oauth-saml2-bearer@tools.ietf.org > Cc: Vincent Roca > > > Hello, > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > IMHO, the document is *almost ready*. I just have minor comments: > > SAML and OAUTH are already covered by extensive, detailed security and > privacy > considerations sections. > > I agree with the authors there is no need to duplicate text in the presen= t > document. > However I have two comments: > > 1- it is mentioned that replay attack protection is not mandatory, but > there is no > justification. On the opposite, protection against replay attacks is > mentioned at > several places in [OASIS.saml-sec-consider-2.0-os] (e.g., 6.1.2, 6.4.5, > 6.5.2, 6.5.6, > 7.1.1.4). I don=E2=80=99t know to what extent the situation differs, but = I=E2=80=99m > curious to know > why it is so. > In the SAML 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants the client is not passive (like a web browser in the case of many SAML profiles/bindings) but rather an active client which either creates the assertion itself or obtains it from a trusted 3rd party system like a security token service. In that sense, it's most analogous to 6.1.2 of OASIS.saml-sec-consider-2.0-os which discusses replay in the context of the SOAP binding and says there "is little vulnerability to replay attacks" and that "the best way to prevent replay attacks is to prevent the message capture in the first place" going on to say that TLS does this for point to point communication. The general Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants, which the SAML document is a concrete profile of, discusses replay some in section 8.2 ( https://tools.ietf.org/html/draft-ietf-oauth-assertions-17#section-8.2 ) and says similar things. In my own personal view, I think tracking assertion ids and rejecting those that have been seen before does more harm to interoperability and deployment at scale than good in mitigating a threat that's already reasonably mitigated by other means. Others have wanted to have the option in the documents, however, which is (as I recall) where the optionality of it comes from. > > 2- [OASIS.saml-sec-consider-2.0-os] reference does not include any URL. > It=E2=80=99s probably > worth to add it. > http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pd= f > > Perhaps you can help me with the tool usage here? In the source XML I've got in the references and http://xml.resource.org/public/rfc/bibxml2/reference.OASIS.saml-sec-conside= r-2.0-os.xml has that URL via but the URL doesn't show up in the rendered document. The situation is the same for all the SAML references, FWIW. --001a11c3b252ed93960505765399 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for your review and feedback, Vincent.= =C2=A0 I'm adding the working group to the thread so they=E2=80=99re aw= are of the comments. Replies are inline below...


From: Vincent Roca <vincent.roca@inria.fr>
Date: Tue, Oct 14, 2014 at 9:10 AM
Subject: Secdir revi= ew of draft-ietf-oauth-saml2-bearer-21
To: IESG <iesg@ietf.org>, secdir@ietf.org, draft-ietf-oaut= h-saml2-bearer@tools.ietf.org
Cc: Vincent Roca <vincent.roca@inria.fr>
=

Hello,

I have revie= wed this document as part of the security directorate's
ongoing effo= rt to review all IETF documents being processed by the
IESG.=C2=A0 These= comments were written primarily for the benefit of the
security area di= rectors. Document editors and WG chairs should treat
these comments just= like any other last call comments.

IMHO, the document is almost = ready. I just have minor comments:

SAML and OA= UTH are already covered by extensive, detailed security and privacy=C2=A0
considerations sections.

I agree with the= authors there is no need to duplicate text in the present document.
<= div>However I have two comments:

1- it is mentione= d that replay attack protection is not mandatory, but there is no
justification. On the opposite, protection against replay attacks is menti= oned at
several places in [OASIS.saml-sec-consider-2.0-os] (e.g.,= 6.1.2, 6.4.5, 6.5.2, 6.5.6,
7.1.1.4). I don=E2=80=99t know to wh= at extent the situation differs, but I=E2=80=99m curious to know
= why it is so.


In the SAML = 2.0 Profile for OAuth 2.0 Client Authentication and=20 Authorization Grants the client is not passive (like a web browser in the c= ase of many SAML profiles/bindings) but rather an active client which eithe= r creates the assertion itself or obtains it from a trusted 3rd party syste= m like a security token service. In that sense, it's most analogous to = 6.1.2 of OASIS.saml-sec-consider-2.0-os which discusses replay in the conte= xt of the SOAP binding and says there "is little vulnerability to repl= ay attacks" and that "the best way to prevent replay attacks is t= o prevent the message capture in the first place" going on to say that= TLS does this for point to point communication.=C2=A0

The general = Assertion Framework for OAuth 2.0 Client Authentication and Authorization G= rants, which the SAML document is a concrete profile of, discusses replay s= ome in section 8.2 ( https://tools.ietf.org/html/= draft-ietf-oauth-assertions-17#section-8.2 ) and says similar things.
In my own personal view, I think tracking assertion ids an= d rejecting those that have been seen before does more harm to interoperabi= lity and deployment at scale than good in mitigating a threat that's al= ready reasonably mitigated by other means. Others have wanted to have the o= ption in the documents, however, which is (as I recall) where the optionali= ty of it comes from.


=C2=A0

2- [OASIS= .saml-sec-consider-2.0-os] reference does not include any URL. It=E2=80=99s= probably
worth to add it.



Perhaps you can help me = with the tool usage here?

In the source XML I've got = <?rfc include=3D'http://x= ml.resource.org/public/rfc/bibxml2/reference.OASIS.saml-sec-consider-2.0-os= .xml' ?> in the references and http://xml.resource.org/public/rfc/bibxml2/reference.OASIS.saml= -sec-consider-2.0-os.xml has that URL via <format type=3D"PDF&q= uot; target=3D"http://docs.oasis-open.or= g/security/saml/v2.0/saml-sec-consider-2.0-os.pdf"/> but the UR= L doesn't show up in the rendered document.

The situa= tion is the same for all the SAML references, FWIW.


=
--001a11c3b252ed93960505765399-- From nobody Wed Oct 15 08:27:37 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8AD81A87C5 for ; Wed, 15 Oct 2014 08:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.578 X-Spam-Level: X-Spam-Status: No, score=-0.578 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8YHF_pArUjB for ; Wed, 15 Oct 2014 08:27:33 -0700 (PDT) Received: from mail-oi0-f43.google.com (mail-oi0-f43.google.com [209.85.218.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA6B31A87C3 for ; Wed, 15 Oct 2014 08:27:33 -0700 (PDT) Received: by mail-oi0-f43.google.com with SMTP id u20so1146737oif.16 for ; Wed, 15 Oct 2014 08:27:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WP6528nv8m5hvr5GTj7DEHQi9Vf5gcHp/iwykwGtaVw=; b=NX6N4zMZG015iMPikdGf+NSHfhxAf2dO8teQ6s30G+/Rw8u0g4m0UkNwYYqYj2Tk8V yNlQ6wRkwsMP8woHl5toeES6oJJI4c8d52dYU7xyFvEaFk9M0vug210plJSEOEl1J8SJ gDz+X1p93Gh6nB7rRYyRT70NRvO55AxWiBH+d3cvROzxaO2PpvR+lL1HPZ3629UeQ9F1 d2Q47tq+UoYcWtLgAh/uuPIn9WJuKSB8hJlyQeRRvPShxcC6eqwo2uLKNKRlCVr2IOei WD+DlJcaCOhfLQB5zt7WA8V40TZzDIb95tlmCvCDbWxPh8jqwgfspMTPl3Q7ug1FpbwW YE0Q== X-Gm-Message-State: ALoCoQmh6VRP3fSCI+RFUIJPZQX/6MrNQh6b0sdzV6gLWZOnNLCZIOj9WhywBKL9xuB5g2Ta74qs MIME-Version: 1.0 X-Received: by 10.202.225.212 with SMTP id y203mr10834166oig.16.1413386851840; Wed, 15 Oct 2014 08:27:31 -0700 (PDT) Received: by 10.76.175.234 with HTTP; Wed, 15 Oct 2014 08:27:31 -0700 (PDT) In-Reply-To: <20141014182611.dd6598cc163e9c640d4167fd@nri.co.jp> References: <20141014182611.dd6598cc163e9c640d4167fd@nri.co.jp> Date: Wed, 15 Oct 2014 08:27:31 -0700 Message-ID: From: Chuck Mortimore To: Nat Sakimura Content-Type: multipart/alternative; boundary=001a113d2dfe3c29c3050577c531 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/qMsMCfZeS5AXqZXuE8nUKZb1CD0 Cc: OAuth WG Subject: Re: [OAUTH-WG] SPOP - code verifier requirements X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 15:27:35 -0000 --001a113d2dfe3c29c3050577c531 Content-Type: text/plain; charset=UTF-8 We went with base64url in our implementation On Tue, Oct 14, 2014 at 2:26 AM, Nat Sakimura wrote: > In his mail, Mike asked whether code verifier is > a value that is sendable without trnasformation > as a http parameter value, or if it needs to be > % encoded when it is being sent. > > We have several options here: > > 1) Require that the code verifier to be a base64url encoded string of a > binary random value. > > 2) Let code verifier to be a binary string and require it to be > either % encoded or base64url encoded when it is sent. > In this case, which encoding should we use? > > 3) require the code verifier to be conform to the following ABNF: > code_verifier = 16*128unreserved > unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" > > Which one do you guys prefer? > > Nat > > -- > Nat Sakimura (n-sakimura@nri.co.jp) > Nomura Research Institute, Ltd. > > PLEASE READ: > The information contained in this e-mail is confidential and intended for > the named recipient(s) only. > If you are not an intended recipient of this e-mail, you are hereby > notified that any review, dissemination, distribution or duplication of > this message is strictly prohibited. If you have received this message in > error, please notify the sender immediately and delete your copy from your > system. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001a113d2dfe3c29c3050577c531 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We went with base64url in our implementation

On Tue, Oct 14, 2014 at 2= :26 AM, Nat Sakimura <n-sakimura@nri.co.jp> wrote:
In his mail, Mike asked whether code verifier i= s
a value that is sendable without trnasformation
as a http parameter value, or if it needs to be
% encoded when it is being sent.

We have several options here:

1) Require that the code verifier to be a base64url encoded string of a bin= ary random value.

2) Let code verifier to be a binary string and require it to be
either % encoded or base64url encoded when it is sent.
In this case, which encoding should we use?

3) require the code verifier to be conform to the following ABNF:
code_verifier =3D 16*128unreserved
unreserved=C2=A0 =C2=A0 =3D ALPHA / DIGIT / "-" / "." /= "_" / "~"

Which one do you guys prefer?

Nat

--
Nat Sakimura (n-sakimura@nri.co.jp<= /a>)
Nomura Research Institute, Ltd.

PLEASE READ:
The information contained in this e-mail is confidential and intended for t= he named recipient(s) only.
If you are not an intended recipient of this e-mail, you are hereby notifie= d that any review, dissemination, distribution or duplication of this messa= ge is strictly prohibited. If you have received this message in error, plea= se notify the sender immediately and delete your copy from your system.

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

--001a113d2dfe3c29c3050577c531-- From nobody Wed Oct 15 08:32:19 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C81D1A1AA9 for ; Wed, 15 Oct 2014 08:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.452 X-Spam-Level: X-Spam-Status: No, score=0.452 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, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YQ5KUcvuJIyc for ; Wed, 15 Oct 2014 08:32:07 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0FB51A1A15 for ; Wed, 15 Oct 2014 08:32:07 -0700 (PDT) Received: by mail-pa0-f51.google.com with SMTP id lj1so1499777pab.38 for ; Wed, 15 Oct 2014 08:32:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zrb8v8xop08+gbyhS/Hy6Uw27iIBxRUe4GvdM+mxvRw=; b=Yp9awcjL+bCBYeWsQu2PXPYf1kQGQoagCD8odG/6XTv3VD24Y+vOqq1BBNU53eS01v P5gy0woog9oWY2NOcN0RR3IbsSRcg/37cV6ZNB/Dgi57NM84AqA6qwBR9IeZsOAC9x9v BXhsc/9B6MahbMt4MdYuqY6xvrJtIaynibfFiHa2Rw4D2dRE1T7w6YCEuXgnuZ7Y/7yr gJqIiF/d7kEoUp82U407Fu9ot4tMFsoTR6ktf0jkN4V1PrSAvva3wB5nfGzPcCaBMMYD K9kyvyFYkV3ADGiDjdDF8UNsbquRtJ49MIdaZyJwKLGdlCrSvZT263gsjkFs2kuIIkZ2 m6kA== X-Received: by 10.68.102.100 with SMTP id fn4mr13790931pbb.48.1413387127432; Wed, 15 Oct 2014 08:32:07 -0700 (PDT) Received: from [192.168.0.5] (i223-219-73-251.s42.a013.ap.plala.or.jp. [223.219.73.251]) by mx.google.com with ESMTPSA id g13sm17535025pat.45.2014.10.15.08.32.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 15 Oct 2014 08:32:05 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-E8E1A97D-A2B8-4807-8124-0DBF58C0D263 Mime-Version: 1.0 (1.0) From: Nat Sakimura X-Mailer: iPhone Mail (12A402) In-Reply-To: Date: Thu, 16 Oct 2014 00:32:04 +0900 Content-Transfer-Encoding: 7bit Message-Id: References: <20141014182611.dd6598cc163e9c640d4167fd@nri.co.jp> To: Chuck Mortimore Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Nz9OlLMmyZD_GrLvpzTuUUN9Ehw Cc: OAuth WG Subject: Re: [OAUTH-WG] SPOP - code verifier requirements X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 15:32:11 -0000 --Apple-Mail-E8E1A97D-A2B8-4807-8124-0DBF58C0D263 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: quoted-printable Thanks.=20 So, to be clear, are you base64url encoding when sending it over the wire or= is your code verifier is created by base64url encoding the binary value so t= hat you do not need to encode it when sending it over?=20 =3Dnat via iPhone Oct 16, 2014 00:27=1B$B!"=1B(BChuck Mortimore =1B= $B$N%a%C%;!<%8=1B(B: > We went with base64url in our implementation >=20 >> On Tue, Oct 14, 2014 at 2:26 AM, Nat Sakimura wrot= e: >> In his mail, Mike asked whether code verifier is >> a value that is sendable without trnasformation >> as a http parameter value, or if it needs to be >> % encoded when it is being sent. >>=20 >> We have several options here: >>=20 >> 1) Require that the code verifier to be a base64url encoded string of a b= inary random value. >>=20 >> 2) Let code verifier to be a binary string and require it to be >> either % encoded or base64url encoded when it is sent. >> In this case, which encoding should we use? >>=20 >> 3) require the code verifier to be conform to the following ABNF: >> code_verifier =3D 16*128unreserved >> unreserved =3D ALPHA / DIGIT / "-" / "." / "_" / "~" >>=20 >> Which one do you guys prefer? >>=20 >> Nat >>=20 >> -- >> Nat Sakimura (n-sakimura@nri.co.jp) >> Nomura Research Institute, Ltd. >>=20 >> PLEASE READ: >> The information contained in this e-mail is confidential and intended for= the named recipient(s) only. >> If you are not an intended recipient of this e-mail, you are hereby notif= ied that any review, dissemination, distribution or duplication of this mess= age is strictly prohibited. If you have received this message in error, plea= se notify the sender immediately and delete your copy from your system. >>=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-E8E1A97D-A2B8-4807-8124-0DBF58C0D263 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Thanks. 

So, to be clear, are you base64url encoding when sending it over the wire o= r is your code verifier is created by base64url encoding the binary value so= that you do not need to encode it when sending it over? 

=3Dnat= via iPhone

Oct 16, 2014 00:27=E3=80=81Chuck Mortimore <cmortimore@salesforce.com> =E3= =81=AE=E3=83=A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8:

We went with base64url in our implemen= tation

On Tue= , Oct 14, 2014 at 2:26 AM, Nat Sakimura <n-sakimura@nri.co.jp> wrote:
In his mail, Mike asked whether c= ode verifier is
a value that is sendable without trnasformation
as a http parameter value, or if it needs to be
% encoded when it is being sent.

We have several options here:

1) Require that the code verifier to be a base64url encoded string of a bina= ry random value.

2) Let code verifier to be a binary string and require it to be
either % encoded or base64url encoded when it is sent.
In this case, which encoding should we use?

3) require the code verifier to be conform to the following ABNF:
code_verifier =3D 16*128unreserved
unreserved    =3D ALPHA / DIGIT / "-" / "." / "_" / "~"

Which one do you guys prefer?

Nat

--
Nat Sakimura (n-sakimura@nri.co.jp)
Nomura Research Institute, Ltd.

PLEASE READ:
The information contained in this e-mail is confidential and intended for th= e named recipient(s) only.
If you are not an intended recipient of this e-mail, you are hereby notified= that any review, dissemination, distribution or duplication of this message= is strictly prohibited. If you have received this message in error, please n= otify the sender immediately and delete your copy from your system.

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

____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-E8E1A97D-A2B8-4807-8124-0DBF58C0D263-- From nobody Wed Oct 15 11:48:55 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79FEC1A1B19 for ; Wed, 15 Oct 2014 11:48:52 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23cBIgSQ8cSD for ; Wed, 15 Oct 2014 11:48:50 -0700 (PDT) Received: from mail-ob0-f179.google.com (mail-ob0-f179.google.com [209.85.214.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BDE11A90E1 for ; Wed, 15 Oct 2014 11:48:48 -0700 (PDT) Received: by mail-ob0-f179.google.com with SMTP id wp4so1598846obc.10 for ; Wed, 15 Oct 2014 11:48:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:references:in-reply-to:date :message-id:subject:to:cc:content-type; bh=juA99J16l5EbSqgyDt60YRG2oOA43VF7ilJHp/etrjI=; b=b4U96+AElgnsc2r05sItRK1hbvYDCGHtybID0HmpS1CzpKaXaWH9c8QrThnuArLc9G HNoHJKN5HvbrgquwDcgfedtmK78MybOl3eP+pGGKXjY/CDzbZmu7N81Iv58+61h6AVgC p8kq4L5csLJ1Jn1KCnqs56DPB75lM9Nm5ydV74moGf+dVC3irVyd/ukP/RiuMuVHSdP2 gu9Howcw4pTW2/ZLaBeZuhh1p8ZXZ+iyA6yAx/6C0i/qnrYuQAXxijv1YFya7WMSkQtf JrfbYsx2fk5O+97HzvjoO+jhth/ojFgdbIT/nH8449YY893cBXGtsgjciEL6AGmW8coR FmJg== X-Gm-Message-State: ALoCoQnJdJoCQ4qhp7g/GsYZohl7MQiRQ0gMnqi+7WulWW8frYf5nlGPpj9+RD/TPNxfgqhvaDDD X-Received: by 10.202.191.194 with SMTP id p185mr3957150oif.63.1413398928376; Wed, 15 Oct 2014 11:48:48 -0700 (PDT) From: Chuck Mortimore Mime-Version: 1.0 (1.0) References: <20141014182611.dd6598cc163e9c640d4167fd@nri.co.jp> In-Reply-To: Date: Wed, 15 Oct 2014 11:48:47 -0700 Message-ID: <-1123724406662361791@unknownmsgid> To: Nat Sakimura Content-Type: multipart/alternative; boundary=001a113d6a520d5f6105057a95ef Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/GZA-81du4LHeaGAAE2xffHEzOoU Cc: OAuth WG Subject: Re: [OAUTH-WG] SPOP - code verifier requirements X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 18:48:52 -0000 --001a113d6a520d5f6105057a95ef Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable We're actually debating it internally. It seems easiest to just encode the binary code up front. Any issue with that? - cmort On Oct 15, 2014, at 8:32 AM, Nat Sakimura wrote: Thanks. So, to be clear, are you base64url encoding when sending it over the wire or is your code verifier is created by base64url encoding the binary value so that you do not need to encode it when sending it over? =3Dnat via iPhone Oct 16, 2014 00:27=E3=80=81Chuck Mortimore =E3= =81=AE=E3=83=A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8: We went with base64url in our implementation On Tue, Oct 14, 2014 at 2:26 AM, Nat Sakimura wrote: > In his mail, Mike asked whether code verifier is > a value that is sendable without trnasformation > as a http parameter value, or if it needs to be > % encoded when it is being sent. > > We have several options here: > > 1) Require that the code verifier to be a base64url encoded string of a > binary random value. > > 2) Let code verifier to be a binary string and require it to be > either % encoded or base64url encoded when it is sent. > In this case, which encoding should we use? > > 3) require the code verifier to be conform to the following ABNF: > code_verifier =3D 16*128unreserved > unreserved =3D ALPHA / DIGIT / "-" / "." / "_" / "~" > > Which one do you guys prefer? > > Nat > > -- > Nat Sakimura (n-sakimura@nri.co.jp) > Nomura Research Institute, Ltd. > > PLEASE READ: > The information contained in this e-mail is confidential and intended for > the named recipient(s) only. > If you are not an intended recipient of this e-mail, you are hereby > notified that any review, dissemination, distribution or duplication of > this message is strictly prohibited. If you have received this message in > error, please notify the sender immediately and delete your copy from you= r > system. > > _______________________________________________ > 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 --001a113d6a520d5f6105057a95ef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We're actually debating it int= ernally. =C2=A0 It seems easiest to just encode the binary code up front. = =C2=A0 Any issue with that?

- cmort

On Oct 15, 2014, a= t 8:32 AM, Nat Sakimura <sakimura@= gmail.com> wrote:

Tha= nks.=C2=A0

So, to be clear, are you base64url enco= ding when sending it over the wire or is your code verifier is created by b= ase64url encoding the binary value so that you do not need to encode it whe= n sending it over?=C2=A0

=3Dnat via iPhone

Oct 16, 201= 4 00:27=E3=80=81Chuck Mortimore <cmortimore@salesforce.com> =E3=81=AE=E3=83=A1=E3=83=83=E3=82= =BB=E3=83=BC=E3=82=B8:

We went with base64url in our implementation

On Tue, Oct 14, 2014 at 2:26 AM, = Nat Sakimura <n-sakimura@nri.co.jp> wrote:
In his mail, Mike asked whether code verifier is
a value that is sendable without trnasformation
as a http parameter value, or if it needs to be
% encoded when it is being sent.

We have several options here:

1) Require that the code verifier to be a base64url encoded string of a bin= ary random value.

2) Let code verifier to be a binary string and require it to be
either % encoded or base64url encoded when it is sent.
In this case, which encoding should we use?

3) require the code verifier to be conform to the following ABNF:
code_verifier =3D 16*128unreserved
unreserved=C2=A0 =C2=A0 =3D ALPHA / DIGIT / "-" / "." /= "_" / "~"

Which one do you guys prefer?

Nat

--
Nat Sakimura (n-sakimura@nri.co.jp<= /a>)
Nomura Research Institute, Ltd.

PLEASE READ:
The information contained in this e-mail is confidential and intended for t= he named recipient(s) only.
If you are not an intended recipient of this e-mail, you are hereby notifie= d that any review, dissemination, distribution or duplication of this messa= ge is strictly prohibited. If you have received this message in error, plea= se notify the sender immediately and delete your copy from your system.

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

___________________= ____________________________
OAuth mailing list
<= span>OAuth@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/oauth">https://www.ietf.org= /mailman/listinfo/oauth
--001a113d6a520d5f6105057a95ef-- From nobody Wed Oct 15 13:12:15 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 902991A893E for ; Wed, 15 Oct 2014 13:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 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, FREEMAIL_REPLY=1, SPF_PASS=-0.001] autolearn=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 4tf2-YG5EqeJ for ; Wed, 15 Oct 2014 13:12:13 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E19EC1A8895 for ; Wed, 15 Oct 2014 13:12:12 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id z12so2171861wgg.13 for ; Wed, 15 Oct 2014 13:12:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=4R7r98/gs6TPxOAHr9SRKLbQKoK7pqDmGzwZ4DL2z5Y=; b=ZOKqb93PVdd82YLBWtZzTapYzAIH1JJ2+HjjtvlSGW199ERRAnbRNUzsnRDTHBb0TI 2FvuV0dd45THKt2hPI1mDEdJyL3idrk09UcHXfNvA8zECVqQjr5ZfkJ1x06QzTtqt8or dTDnROtbKea45r63evF1XeL+vVVPCn5FQp0SRMEKAqYkfatoCY1hAcap9ROWv1mlqGwp /TZPm0ymVPdV8P6R5nXIPTMzKgJBsnipmYXOiQHSfiZlzInxKA1Absc9EfMhaTr3Klv+ v2suKv9i5r/RRnl2vrBHGnYhfp3Sz4uFEK9O2uRRKDnbpFySAFz3ILloWyCqPQJNcqIn LQhw== X-Received: by 10.194.243.131 with SMTP id wy3mr5166292wjc.129.1413403931483; Wed, 15 Oct 2014 13:12:11 -0700 (PDT) Received: from [192.168.2.7] ([109.255.231.6]) by mx.google.com with ESMTPSA id o1sm25000254wja.25.2014.10.15.13.12.10 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Oct 2014 13:12:10 -0700 (PDT) Message-ID: <543ED519.3080902@gmail.com> Date: Wed, 15 Oct 2014 21:12:09 +0100 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: oauth@ietf.org References: <20141014182611.dd6598cc163e9c640d4167fd@nri.co.jp> <-1123724406662361791@unknownmsgid> In-Reply-To: <-1123724406662361791@unknownmsgid> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/noHTttmoFOjFq5XIHCcFTh8_G30 Subject: Re: [OAUTH-WG] SPOP - code verifier requirements X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 20:12:14 -0000 Hi, in our project we ship a transformer implementation that assumes that a code verifier represents a base64url encoded SHA-256 hash of the code challenge Cheers, Sergey On 15/10/14 19:48, Chuck Mortimore wrote: > We're actually debating it internally. It seems easiest to just encode > the binary code up front. Any issue with that? > > - cmort > > On Oct 15, 2014, at 8:32 AM, Nat Sakimura > wrote: > >> Thanks. >> >> So, to be clear, are you base64url encoding when sending it over the >> wire or is your code verifier is created by base64url encoding the >> binary value so that you do not need to encode it when sending it over? >> >> =nat via iPhone >> >> Oct 16, 2014 00:27、Chuck Mortimore > > のメッセージ: >> >>> We went with base64url in our implementation >>> >>> On Tue, Oct 14, 2014 at 2:26 AM, Nat Sakimura >> > wrote: >>> >>> In his mail, Mike asked whether code verifier is >>> a value that is sendable without trnasformation >>> as a http parameter value, or if it needs to be >>> % encoded when it is being sent. >>> >>> We have several options here: >>> >>> 1) Require that the code verifier to be a base64url encoded >>> string of a binary random value. >>> >>> 2) Let code verifier to be a binary string and require it to be >>> either % encoded or base64url encoded when it is sent. >>> In this case, which encoding should we use? >>> >>> 3) require the code verifier to be conform to the following ABNF: >>> code_verifier = 16*128unreserved >>> unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" >>> >>> Which one do you guys prefer? >>> >>> Nat >>> >>> -- >>> Nat Sakimura (n-sakimura@nri.co.jp ) >>> Nomura Research Institute, Ltd. >>> >>> PLEASE READ: >>> The information contained in this e-mail is confidential and >>> intended for the named recipient(s) only. >>> If you are not an intended recipient of this e-mail, you are >>> hereby notified that any review, dissemination, distribution or >>> duplication of this message is strictly prohibited. If you have >>> received this message in error, please notify the sender >>> immediately and delete your copy from your system. >>> >>> _______________________________________________ >>> 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 > From nobody Wed Oct 15 16:07:42 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D334B1ACDD8 for ; Wed, 15 Oct 2014 16:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q0hyYI52TgIM for ; Wed, 15 Oct 2014 16:07:24 -0700 (PDT) Received: from na6sys009bog003.obsmtp.com (na6sys009bog003.obsmtp.com [74.125.150.46]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92C241A87CE for ; Wed, 15 Oct 2014 16:07:23 -0700 (PDT) Received: from mail-ie0-f175.google.com ([209.85.223.175]) (using TLSv1) by na6sys009bob003.postini.com ([74.125.148.12]) with SMTP ID DSNKVD7+Kt7mwOlQD0KyLl5gxJsYGKnn2cXq@postini.com; Wed, 15 Oct 2014 16:07:23 PDT Received: by mail-ie0-f175.google.com with SMTP id x19so2327471ier.34 for ; Wed, 15 Oct 2014 16:07:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=2fZUNfpbVzUOet4DtjOl7kNbLd5WlLFrUSrLBoXY0vE=; b=IzmjGU9zqUuyl8vfiJpfDFisnas88FxURGebXdTQxHa0uDSLaSPL98oPgpUPEdschs hmLObsO4Dti7koY0LcWCKkdUb7Ay+0wqJD4GCnQ9pg5sPO4puzp34i9VUyDX+Fi21YvX HA9P+lufHqcihNsMSBGK9KnYetWEiK2lQZegjS4EYYo2k5q8rFITJz4YFI6vupi2cka4 fmf0L4ncpVbFuUNh6exO4rD22dCpVRopjAf5GKIj3/LqJUhsQzYLLh70hhJcAEjbkq57 9/58Hj4Ch0vo6Phcjw/q+ox/KrxTC5aOtdDGZF4I/Fw4D+HcqPdzWAOwOaCuC6EfCn9Y Onow== X-Gm-Message-State: ALoCoQlGU5XrejLuVpF105xs7Vs0EhNuqnTdMw5Y6IwAeWs2SiphDHOp6OZKUT4aeEwg1NuTCtkZdtbE5Hwsx7LhrSZKbmh1thUOTgJH3wA0266SL4Hkp3V5gl/JnVBlBg8JaR8oNp/v X-Received: by 10.43.87.79 with SMTP id av15mr805794icc.44.1413414442431; Wed, 15 Oct 2014 16:07:22 -0700 (PDT) X-Received: by 10.43.87.79 with SMTP id av15mr805776icc.44.1413414442240; Wed, 15 Oct 2014 16:07:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.12.137 with HTTP; Wed, 15 Oct 2014 16:06:52 -0700 (PDT) In-Reply-To: <20141014204213.15568.37128.idtracker@ietfa.amsl.com> References: <20141014204213.15568.37128.idtracker@ietfa.amsl.com> From: Brian Campbell Date: Wed, 15 Oct 2014 17:06:52 -0600 Message-ID: To: Pete Resnick Content-Type: multipart/alternative; boundary=001a11339758c0250005057e312d Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/O47-RBkXq0ZpLkhzitI6qDpU33s Cc: "draft-ietf-oauth-assertions@tools.ietf.org" , "oauth-chairs@tools.ietf.org" , The IESG , oauth Subject: Re: [OAUTH-WG] Pete Resnick's No Objection on draft-ietf-oauth-assertions-17: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 23:07:38 -0000 --001a11339758c0250005057e312d Content-Type: text/plain; charset=UTF-8 Thanks for your review and feedback, Pete. Replies are inline below... On Tue, Oct 14, 2014 at 2:42 PM, Pete Resnick wrote: > Pete Resnick has entered the following ballot position for > draft-ietf-oauth-assertions-17: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > 3 - > > Assertions used in the protocol exchanges defined by this > specification MUST always be protected against tampering using a > digital signature or a keyed message digest applied by the issuer. > > Why is that? Aren't you using assertions over a protected channel (as > required by the spec) and therefore not need to sign the assertions? > Indeed, why would a self-issued Bearer Assertion need to be signed at > all? Does that even make sense? > > Yes, assertions are sent over a protected channel, which does provide integrity protection for the transport form client to AS and also gives server authentication. But it doesn't provide client authentication, which is kind of the point of the Client Authentication part of this draft. And for authorization the signing or MACing is what authenticates the issuer of the assertion - sometimes the issuer is the client but often the issuer will be a 3rd party system. I do agree with you in one specific case that, if the client is trusted to be the assertion issuer and the client is properly authenticated, then an unsigned assertion could be reasonably used as an authorization grant. But it's a fairly rare and very specific case. And one that can be accommodated in other ways. So it's not worth introducing the complexity and potential security problems that having the signature be option would bring. > 4.1 - > > grant_type > REQUIRED. The format of the assertion as defined by the > authorization server. The value MUST be an absolute URI. > > That MUST is unnecessary. It's just definitional from 6749, 4.5 (which, > as it happens, doesn't use 2119 language for this). s/MUST/will > Makes sense. > > assertion > REQUIRED. The assertion being used as an authorization grant. > Specific serialization of the assertion is defined by profile > documents. The serialization MUST be encoded for transport within > HTTP forms. It is RECOMMENDED that base64url be used. > > The MUST seems weird here. Are you saying that the profile could not > possibly have a serialization for an assertion that did not require > further encoding? But the RECOMMENDED seems downright wrong: Either an > implementer *needs* to know the encoding independently of the profile, > and therefore this needs to be a MUST, or the profile is going to > describe the encoding, which could be base64url or could be something > else, and the implementation will do whatever the profile says. If you > really want to say something here, I suggest replacing the last two > sentences with: > > If the assertion is going to be transported within HTTP forms, the > profile document needs to describe what (if any) encoding will be > needed to do so. The base64url encoding is widely implemented and > therefore suggested. > > In reading it again, I agree with you that it's weird and not appropriate here. In fact the JWT profile itself does not require any further encoding. Barring any objection, I suggest that the last two sentences just be removed. So it would just be, "assertion REQUIRED. The assertion being used as an authorization grant. Specific serialization of the assertion is defined by profile documents." > scope > [...] > As such, the > requested scope MUST be equal or lesser than the scope originally > granted to the authorized accessor. > > s/MUST/will (unless you explain whether it's the server or the client > that's supposed to be obeying that MUST, and for what reason) > They are both supposed to obey it - the client shouldn't ask for more and the server will reject the request, if it does. Is "will" more appropriate than "MUST" here? Or maybe a non 2119 "should"? > > If the scope parameter and/or > value are omitted, the scope MUST be treated as equal to the scope > originally granted to the authorized accessor. The Authorization > Server MUST limit the scope of the issued access token to be equal > or lesser than the scope originally granted to the authorized > accessor. > > In the first sentence, is this MUST for the server? (That is, shouldn't > it be, "If the scope parameter and/or value are omitted, the server MUST > use the value of the scope originally granted to the authorized > accessor."?) And anyway, don't these two sentences contradict 6749, which > says: > > The authorization server MAY fully or partially ignore the scope > requested by the client, based on the authorization server policy or > the resource owner's instructions. > [...] > If the client omits the scope parameter when requesting > authorization, the authorization server MUST either process the > request using a pre-defined default value or fail the request > indicating an invalid scope. > > Yes, I think you're correct that there is a contradiction with 6749. And, honestly, I'm surprised at the text there as I read it again. I don't think that was the intent. I'd propose that the sentence, " If the scope parameter and/or value are omitted, the scope MUST be treated as equal to the scope originally granted to the authorized accessor." be removed. Here and throughout: s/non-normative example/example (As far as I know, > there are no other kinds in IETF documents.) > I thought I picked that language up from some other draft or RFC but I'm now not sure where it came from and can't easily find other examples of the same thing. So I am happy to remove the "non-normative" throughout, if it is already understood and/or not customary to say so. > > 4.1.1 - s/MUST construct/constructs > OK > > 4.2, client_assertion_type and client_assertion: See comments from 4.1 > regarding grant_type and assertion. > Agree and same answer. > > 4.2.1 - s/MUST construct/constructs > OK > > 5.2 - > > s/MUST identify/identifies > OK > > For clarification: > OLD > Assertions that do > not identify the Authorization Server as an intended audience MUST > be rejected. > NEW > The Authorization Server MUST reject any assertion that does not > contain the its own identity as the intended audience. > END > OK, I agree that reads better. --001a11339758c0250005057e312d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for your review and feedback, Pete.=20 Replies are inline below...

On Tue, Oct 14, 2014 at 2:42 PM, Pete Resnick <presnick@qti.qualcomm.com> wrote:
Pete Resnick has entered the following ballot= position for
draft-ietf-oauth-assertions-17: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-crit= eria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions= /



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

3 -

=C2=A0 =C2=A0Assertions used in the protocol exchanges defined by this
=C2=A0 =C2=A0specification MUST always be protected against tampering using= a
=C2=A0 =C2=A0digital signature or a keyed message digest applied by the iss= uer.

Why is that? Aren't you using assertions over a protected channel (as required by the spec) and therefore not need to sign the assertions?
Indeed, why would a self-issued Bearer Assertion need to be signed at
all? Does that even make sense?


Yes, assertions are sent over a protec= ted channel, which does provide integrity protection for the transport form= client to AS and also gives server authentication. But it doesn't prov= ide client authentication, which is kind of the point of the Client Authent= ication part of this draft. And for authorization the signing or MACing is = what authenticates the issuer of the assertion - sometimes the issuer is th= e client but often the issuer will be a 3rd party system.

I do agree with you in one specific case that, if the client is trusted t= o be the assertion issuer and the client is properly authenticated, then an= unsigned assertion could be reasonably used as an authorization grant. But= it's a fairly rare and very specific case. And one that can be accommo= dated in other ways. So it's not worth introducing the complexity and p= otential security problems that having the signature be option would bring.=


=C2=A0
4.1 -

=C2=A0 =C2=A0grant_type
=C2=A0 =C2=A0 =C2=A0 REQUIRED.=C2=A0 The format of the assertion as defined= by the
=C2=A0 =C2=A0 =C2=A0 authorization server.=C2=A0 The value MUST be an absol= ute URI.

That MUST is unnecessary. It's just definitional from 6749, 4.5 (which,=
as it happens, doesn't use 2119 language for this). s/MUST/will

Makes sense.
=C2=A0

=C2=A0 =C2=A0assertion
=C2=A0 =C2=A0 =C2=A0 REQUIRED.=C2=A0 The assertion being used as an authori= zation grant.
=C2=A0 =C2=A0 =C2=A0 Specific serialization of the assertion is defined by = profile
=C2=A0 =C2=A0 =C2=A0 documents.=C2=A0 The serialization MUST be encoded for= transport within
=C2=A0 =C2=A0 =C2=A0 HTTP forms.=C2=A0 It is RECOMMENDED that base64url be = used.

The MUST seems weird here. Are you saying that the profile could not
possibly have a serialization for an assertion that did not require
further encoding? But the RECOMMENDED seems downright wrong: Either an
implementer *needs* to know the encoding independently of the profile,
and therefore this needs to be a MUST, or the profile is going to
describe the encoding, which could be base64url or could be something
else, and the implementation will do whatever the profile says. If you
really want to say something here, I suggest replacing the last two
sentences with:

=C2=A0 =C2=A0 =C2=A0 If the assertion is going to be transported within HTT= P forms, the
=C2=A0 =C2=A0 =C2=A0 profile document needs to describe what (if any) encod= ing will be
=C2=A0 =C2=A0 =C2=A0 needed to do so. The base64url encoding is widely impl= emented and
=C2=A0 =C2=A0 =C2=A0 therefore suggested.


In reading it again, I agree with you = that it's weird and not appropriate here. In fact the JWT profile itsel= f does not require any further encoding.

Barring any obj= ection, I suggest that the last two sentences just be removed. So it would = just be,

=C2=A0 "assertion
=C2=A0 =C2=A0 =C2=A0 REQUIRED.=C2=A0 The assertion being used as an authori= zation grant.
=C2=A0 =C2=A0 =C2=A0 Specific serialization of the assertion is defined by = profile
=C2=A0 =C2=A0 =C2=A0 documents."

=C2=A0
=C2=A0 =C2=A0 scope
=C2=A0 =C2=A0 [...]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0As such, the
=C2=A0 =C2=A0 =C2=A0 requested scope MUST be equal or lesser than the scope= originally
=C2=A0 =C2=A0 =C2=A0 granted to the authorized accessor.

s/MUST/will (unless you explain whether it's the server or the client that's supposed to be obeying that MUST, and for what reason)

They are both supposed to obey it - the client s= houldn't ask for more and the server will reject the request, if it doe= s.

Is "will" more appropriate than "MUST&q= uot; here? Or maybe a non 2119 "should"?
=C2=A0

=C2=A0 =C2=A0 =C2=A0 If the scope parameter and/or
=C2=A0 =C2=A0 =C2=A0 value are omitted, the scope MUST be treated as equal = to the scope
=C2=A0 =C2=A0 =C2=A0 originally granted to the authorized accessor.=C2=A0 T= he Authorization
=C2=A0 =C2=A0 =C2=A0 Server MUST limit the scope of the issued access token= to be equal
=C2=A0 =C2=A0 =C2=A0 or lesser than the scope originally granted to the aut= horized
=C2=A0 =C2=A0 =C2=A0 accessor.

In the first sentence, is this MUST for the server? (That is, shouldn't=
it be, "If the scope parameter and/or value are omitted, the server MU= ST
use the value of the scope originally granted to the authorized
accessor."?) And anyway, don't these two sentences contradict 6749= , which
says:

=C2=A0 =C2=A0The authorization server MAY fully or partially ignore the sco= pe
=C2=A0 =C2=A0requested by the client, based on the authorization server pol= icy or
=C2=A0 =C2=A0the resource owner's instructions.
=C2=A0 =C2=A0[...]
=C2=A0 =C2=A0If the client omits the scope parameter when requesting
=C2=A0 =C2=A0authorization, the authorization server MUST either process th= e
=C2=A0 =C2=A0request using a pre-defined default value or fail the request<= br> =C2=A0 =C2=A0indicating an invalid scope.


Yes, I think you're correct that t= here is a contradiction with 6749. And, honestly, I'm surprised at the = text there as I read it again. I don't think that was the intent.
<= br>
I'd propose that the sentence, " If the scope parame= ter and/or
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 value are omitted, the scope M= UST be treated as equal to the scope
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 orig= inally granted to the authorized accessor." be removed.

=C2=A0

Here and throughout: s/non-normative example/example (As far as I know,
there are no other kinds in IETF documents.)

I thought I picked that language up from some other draft or RFC but = I'm now not sure where it came from and can't easily find other exa= mples of the same thing.=C2=A0 So I am happy to remove the "non-normat= ive" throughout, if it is already understood and/or not customary to s= ay so.

=C2=A0

4.1.1 - s/MUST construct/constructs

OK<= br>
=C2=A0

4.2, client_assertion_type and client_assertion: See comments from 4.1
regarding grant_type and assertion.

Agr= ee and same answer.
=C2=A0

4.2.1 - s/MUST construct/constructs

OK<= br>
=C2=A0

5.2 -

s/MUST identify/identifies

OK
=
=C2=A0

For clarification:
OLD
=C2=A0 =C2=A0 =C2=A0 Assertions that do
=C2=A0 =C2=A0 =C2=A0 not identify the Authorization Server as an intended a= udience MUST
=C2=A0 =C2=A0 =C2=A0 be rejected.
NEW
=C2=A0 =C2=A0 =C2=A0 The Authorization Server MUST reject any assertion tha= t does not
=C2=A0 =C2=A0 =C2=A0 contain the its own identity as the intended audience.=
END

OK, I agree that reads better.
<= /div>
=C2=A0

--001a11339758c0250005057e312d-- From nobody Wed Oct 15 16:18:34 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 312601ACE00; Wed, 15 Oct 2014 16:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 rE7rXNjXKzfQ; Wed, 15 Oct 2014 16:18:27 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 795431ACE03; Wed, 15 Oct 2014 16:18:26 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id gi9so1941275lab.19 for ; Wed, 15 Oct 2014 16:18:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=hhXDA5Q8lHMZ86F7fw0b0YrmtS4bT7/JAzNK1e620aA=; b=qzARYfXDHnKtvkq4WvJFIA+3QO8FgfH49tXULES9Lsv9tEzJNvIxQ5RlbkipxkECuX 20A8ymm5Ddf8uueEAzNb5z5T18N7oVpbGOPUaIZVf+B1G8H71m2PGVbvovEO4mgM/x7l HaGULa0ThVyT7FzFPWqupF+2NuODePxBPy+Xuur9kxp1i9un+ARnKMARKk7zYv5VTYPz qNsYBXxOg9WYDmlrZMnRb84ApP0DEwsKwhiAHJG4KYopqY2seNsRgNEfBFKphEJX8erj uYOIo+u3Qf/G5BBgwu+Xgo5oUgNztd9RZifeW+hk5tIHqkWVTzusKpuO1ip27oScOc72 T2Xg== MIME-Version: 1.0 X-Received: by 10.112.166.130 with SMTP id zg2mr15555882lbb.3.1413415104757; Wed, 15 Oct 2014 16:18:24 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.8.103 with HTTP; Wed, 15 Oct 2014 16:18:24 -0700 (PDT) In-Reply-To: References: <20141014204213.15568.37128.idtracker@ietfa.amsl.com> Date: Wed, 15 Oct 2014 19:18:24 -0400 X-Google-Sender-Auth: LVmMCBqaqNk5A9I4HVu1nKndql0 Message-ID: From: Barry Leiba To: Brian Campbell Content-Type: multipart/alternative; boundary=001a1134891e3d479d05057e5943 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/YdjEv6quLkdAA0_VBbhkLoMn8Uo Cc: "draft-ietf-oauth-assertions@tools.ietf.org" , Pete Resnick , oauth , "oauth-chairs@tools.ietf.org" , The IESG Subject: Re: [OAUTH-WG] Pete Resnick's No Objection on draft-ietf-oauth-assertions-17: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 23:18:28 -0000 --001a1134891e3d479d05057e5943 Content-Type: text/plain; charset=ISO-8859-1 > > >> Assertions used in the protocol exchanges defined by this >> specification MUST always be protected against tampering using a >> digital signature or a keyed message digest applied by the issuer. >> >> Why is that? Aren't you using assertions over a protected channel (as >> required by the spec) and therefore not need to sign the assertions? >> Indeed, why would a self-issued Bearer Assertion need to be signed at >> all? Does that even make sense? >> >> > Yes, assertions are sent over a protected channel, which does provide > integrity protection for the transport form client to AS and also gives > server authentication. But it doesn't provide client authentication, which > is kind of the point of the Client Authentication part of this draft. And > for authorization the signing or MACing is what authenticates the issuer of > the assertion - sometimes the issuer is the client but often the issuer > will be a 3rd party system. > > I do agree with you in one specific case that, if the client is trusted to > be the assertion issuer and the client is properly authenticated, then an > unsigned assertion could be reasonably used as an authorization grant. But > it's a fairly rare and very specific case. And one that can be accommodated > in other ways. So it's not worth introducing the complexity and potential > security problems that having the signature be option would bring. > In other words, the assertion must be protected against tampering *by the party that presents the assertion*. That is a significant point, and you should say it. Barry --001a1134891e3d479d05057e5943 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
=
, Pete Resnick , oauth , "oauth-chairs@tools.ietf.org" , The IESG Subject: Re: [OAUTH-WG] Pete Resnick's No Objection on draft-ietf-oauth-assertions-17: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Oct 2014 23:35:55 -0000 --001a11c312c49a3da705057e9780 Content-Type: text/plain; charset=UTF-8 Fair point. I'll add some text saying that in the next revision. On Wed, Oct 15, 2014 at 5:18 PM, Barry Leiba wrote: > >>> Assertions used in the protocol exchanges defined by this >>> specification MUST always be protected against tampering using a >>> digital signature or a keyed message digest applied by the issuer. >>> >>> Why is that? Aren't you using assertions over a protected channel (as >>> required by the spec) and therefore not need to sign the assertions? >>> Indeed, why would a self-issued Bearer Assertion need to be signed at >>> all? Does that even make sense? >>> >>> >> Yes, assertions are sent over a protected channel, which does provide >> integrity protection for the transport form client to AS and also gives >> server authentication. But it doesn't provide client authentication, which >> is kind of the point of the Client Authentication part of this draft. And >> for authorization the signing or MACing is what authenticates the issuer of >> the assertion - sometimes the issuer is the client but often the issuer >> will be a 3rd party system. >> >> I do agree with you in one specific case that, if the client is trusted >> to be the assertion issuer and the client is properly authenticated, then >> an unsigned assertion could be reasonably used as an authorization grant. >> But it's a fairly rare and very specific case. And one that can be >> accommodated in other ways. So it's not worth introducing the complexity >> and potential security problems that having the signature be option would >> bring. >> > > In other words, the assertion must be protected against tampering *by the > party that presents the assertion*. That is a significant point, and you > should say it. > > Barry > --001a11c312c49a3da705057e9780 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Fair point. I'll add some text saying that in the next= revision.

On Wed, Oct 15, 2014 at 5:18 PM, Barry Leiba <barryleiba@compute= r.org> wrote:

=C2=A0 =C2=A0Assertions used in the protocol exchanges defined by this
=C2=A0 =C2=A0specification MUST always be protected against tampering using= a
=C2=A0 =C2=A0digital signature or a keyed message digest applied by the iss= uer.

Why is that? Aren't you using assertions over a protected channel (as required by the spec) and therefore not need to sign the assertions?
Indeed, why would a self-issued Bearer Assertion need to be signed at
all? Does that even make sense?


Yes, assertions are sent over a protec= ted channel, which does provide integrity protection for the transport form= client to AS and also gives server authentication. But it doesn't prov= ide client authentication, which is kind of the point of the Client Authent= ication part of this draft. And for authorization the signing or MACing is = what authenticates the issuer of the assertion - sometimes the issuer is th= e client but often the issuer will be a 3rd party system.

I do agree with you in one specific case that, if the client is trusted t= o be the assertion issuer and the client is properly authenticated, then an= unsigned assertion could be reasonably used as an authorization grant. But= it's a fairly rare and very specific case. And one that can be accommo= dated in other ways. So it's not worth introducing the complexity and p= otential security problems that having the signature be option would bring.=

In other wo= rds, the assertion must be protected against tampering *by the party that p= resents the assertion*.=C2=A0 That is a significant point, and you should s= ay it.

<= div>Barry=C2=A0

--001a11c312c49a3da705057e9780-- From nobody Wed Oct 15 19:30:35 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 712621ACECC; Wed, 15 Oct 2014 19:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id na-Lh603Mbl9; Wed, 15 Oct 2014 19:30:32 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6D411ACEC3; Wed, 15 Oct 2014 19:30:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1413426632; x=1444962632; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=Plwlyq7oEqHb4pnBlVe+vf3r1ikKQ2TuEBfF5zZkR8k=; b=BhYMTaPiGbcakMqT0rq51Xr2suT/NdRW8oT/JPAmmE9HZrIoO6YSPnlH WgFqtBtydhNLJFrf7iMcRTP3t3WtuEBlr6pgO6G1bmYhwaCsY/EB/TMEa upIWfUeeDuTGa2wtDEFm7WaKxm9V/C1nKCHo+TqY01atQhRgyqX/4P22Q 8=; X-IronPort-AV: E=McAfee;i="5600,1067,7592"; a="166915669" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Oct 2014 19:30:31 -0700 X-IronPort-AV: E=Sophos;i="5.04,729,1406617200"; d="scan'208,217";a="825343355" Received: from nasanexhc12.na.qualcomm.com ([172.30.39.187]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 15 Oct 2014 19:30:29 -0700 Received: from NASANEXM01F.na.qualcomm.com (10.46.201.192) by nasanexhc12.na.qualcomm.com (172.30.39.187) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 15 Oct 2014 19:30:29 -0700 Received: from presnick-mac.local (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.46.201.192) with Microsoft SMTP Server (TLS) id 15.0.913.22; Wed, 15 Oct 2014 19:30:28 -0700 Message-ID: <543F2DC2.1050300@qti.qualcomm.com> Date: Wed, 15 Oct 2014 21:30:26 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Brian Campbell References: <20141014204213.15568.37128.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050404020701020406050802" X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01E.na.qualcomm.com (10.46.201.191) To NASANEXM01F.na.qualcomm.com (10.46.201.192) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/36ruP6SQGEDBLY8WwwvVdUEgGzs Cc: "draft-ietf-oauth-assertions@tools.ietf.org" , "oauth-chairs@tools.ietf.org" , The IESG , oauth Subject: Re: [OAUTH-WG] Pete Resnick's No Objection on draft-ietf-oauth-assertions-17: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 02:30:34 -0000 --------------050404020701020406050802 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit On 10/15/14 6:06 PM, Brian Campbell wrote: > Thanks for your review and feedback, Pete. Replies are inline below... Thanks for addressing the comments, including Barry's followup. Just on the questions: > On Tue, Oct 14, 2014 at 2:42 PM, Pete Resnick > > wrote: > > scope > [...] > As such, the > requested scope MUST be equal or lesser than the scope > originally > granted to the authorized accessor. > > s/MUST/will (unless you explain whether it's the server or the client > that's supposed to be obeying that MUST, and for what reason) > > > They are both supposed to obey it - the client shouldn't ask for more > and the server will reject the request, if it does. > > Is "will" more appropriate than "MUST" here? Or maybe a non 2119 "should"? Ah, so you're saying that a client could conceivably (either purposely or accidentally) try to sneak through a larger scope than it should, and the client MUST NOT do that, and the server MUST reject if it gets one. OK, that makes sense. (I do tend to like active MUSTs -- the foo MUST do X or the bar MUST NOT do Y -- but this is probably OK as is.) > Here and throughout: s/non-normative example/example (As far as I > know, > there are no other kinds in IETF documents.) > > > I thought I picked that language up from some other draft or RFC but > I'm now not sure where it came from and can't easily find other > examples of the same thing. So I am happy to remove the > "non-normative" throughout, if it is already understood and/or not > customary to say so. Yeah, we've seen other RFCs with such language. I've whined about it in the past. Some authors roll their eyes at me. You are welcome to roll your eyes if you like, but I find such text silly. :-) Thanks for the rest of the planned changes. Looks good. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 --------------050404020701020406050802 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit On 10/15/14 6:06 PM, Brian Campbell wrote:
Thanks for your review and feedback, Pete. Replies are inline below...

Thanks for addressing the comments, including Barry's followup. Just on the questions:

On Tue, Oct 14, 2014 at 2:42 PM, Pete Resnick <presnick@qti.qualcomm.com> wrote:

 
    scope
    [...]
                                                   As such, the
      requested scope MUST be equal or lesser than the scope originally
      granted to the authorized accessor.

s/MUST/will (unless you explain whether it's the server or the client
that's supposed to be obeying that MUST, and for what reason)

They are both supposed to obey it - the client shouldn't ask for more and the server will reject the request, if it does.

Is "will" more appropriate than "MUST" here? Or maybe a non 2119 "should"?

Ah, so you're saying that a client could conceivably (either purposely or accidentally) try to sneak through a larger scope than it should, and the client MUST NOT do that, and the server MUST reject if it gets one. OK, that makes sense. (I do tend to like active MUSTs -- the foo MUST do X or the bar MUST NOT do Y -- but this is probably OK as is.)

Here and throughout: s/non-normative example/example (As far as I know,
there are no other kinds in IETF documents.)

I thought I picked that language up from some other draft or RFC but I'm now not sure where it came from and can't easily find other examples of the same thing.  So I am happy to remove the "non-normative" throughout, if it is already understood and/or not customary to say so.

Yeah, we've seen other RFCs with such language. I've whined about it in the past. Some authors roll their eyes at me. You are welcome to roll your eyes if you like, but I find such text silly. :-)

Thanks for the rest of the planned changes. Looks good.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
--------------050404020701020406050802-- From nobody Wed Oct 15 20:47:40 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7BFC1A0151; Wed, 15 Oct 2014 20:47:36 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rT8fxFl8NTSQ; Wed, 15 Oct 2014 20:47:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D4551A0149; Wed, 15 Oct 2014 20:47:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Richard Barnes" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141016034735.18695.61014.idtracker@ietfa.amsl.com> Date: Wed, 15 Oct 2014 20:47:35 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/MrdoWzUruBX3ox4-OB9jCVAzz5Y Cc: draft-ietf-oauth-assertions@tools.ietf.org, oauth-chairs@tools.ietf.org, oauth@ietf.org Subject: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 03:47:37 -0000 Richard Barnes has entered the following ballot position for draft-ietf-oauth-assertions-17: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- "The assertion MUST contain an Audience that identifies the Authorization Server as the intended audience. Assertions that do not identify the Authorization Server as an intended audience MUST be rejected." Could you please identify the threat model within which this "MUST" is required? This requirement doesn't follow from any of the threats elaborated in Section 8. The Audience is only necessary if the Issuer wishes to constrain the set of Authorization Servers with which an assertion may be used. So ISTM that this should be "MAY contain..." ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- "keyed message digest" -> "Message Authentication Code" That's the proper terminology [RFC4949], especially since there are MACs that are not based on digests. "This mechanism provides additional security properties." -- Please delete this or elaborate on what security properties it provides. Section 8.2 should note that "Holder-of-Key Assertions" are also a mitigation for this risk. From nobody Wed Oct 15 20:56:45 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D14951A0164; Wed, 15 Oct 2014 20:56:41 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y04Qqc4IVwAY; Wed, 15 Oct 2014 20:56:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7659D1A0149; Wed, 15 Oct 2014 20:56:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Richard Barnes" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141016035640.25108.27277.idtracker@ietfa.amsl.com> Date: Wed, 15 Oct 2014 20:56:40 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/HdKGFQyjFe9RpEyrbCc0WTIfCjk Cc: oauth-chairs@tools.ietf.org, draft-ietf-oauth-saml2-bearer@tools.ietf.org, oauth@ietf.org Subject: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-saml2-bearer-21: (with DISCUSS) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 03:56:42 -0000 Richard Barnes has entered the following ballot position for draft-ietf-oauth-saml2-bearer-21: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- As with draft-ietf-oauth-assertions, the requirement for an element seems entirely unnecessary. Holding this DISCUSS point pending that discussion and its reflection in this document. "Assertions that do not identify the Authorization Server as an intended audience MUST be rejected." -- What does it mean for an assertion to "identify the Authorization Server"? Does the specified need to match the entire URL of the relevant OAuth endpoint? Just the origin? Just the domain? Does the URL need to be canonicalized? From nobody Wed Oct 15 21:01:27 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE451A0149; Wed, 15 Oct 2014 21:01:24 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DEHkLVCQAGOU; Wed, 15 Oct 2014 21:01:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B71E1A0054; Wed, 15 Oct 2014 21:01:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Richard Barnes" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141016040122.32277.7067.idtracker@ietfa.amsl.com> Date: Wed, 15 Oct 2014 21:01:22 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/mmZaobYDOeq146oKOxA428oHtgA Cc: oauth-chairs@tools.ietf.org, draft-ietf-oauth-jwt-bearer@tools.ietf.org, oauth@ietf.org Subject: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-jwt-bearer-10: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 04:01:24 -0000 Richard Barnes has entered the following ballot position for draft-ietf-oauth-jwt-bearer-10: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- As with draft-ietf-oauth-assertions, the requirement for an "aud" claim seems entirely unnecessary. Holding this DISCUSS point pending that discussion and its reflection in this document. "Assertions that do not identify the Authorization Server as an intended audience MUST be rejected." -- What does it mean for an assertion to "identify the Authorization Server"? Does the specified need to match the entire URL of the relevant OAuth endpoint? Just the origin? Just the domain? Does the URL need to be canonicalized? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- "keyed message digest" -> "MAC" Both this and the SAML document could save a lot of bits by just being subsections of the -assertions document. From nobody Thu Oct 16 04:20:59 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D943E1AD048; Thu, 16 Oct 2014 04:20:38 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bqA71uph2XA; Thu, 16 Oct 2014 04:20:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 52F1C1AD050; Thu, 16 Oct 2014 04:20:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141016112032.13008.86094.idtracker@ietfa.amsl.com> Date: Thu, 16 Oct 2014 04:20:32 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/nPle8PZn8uHgDV_o870JiYSkluU Cc: oauth-chairs@tools.ietf.org, draft-ietf-oauth-saml2-bearer@tools.ietf.org, oauth@ietf.org Subject: [OAUTH-WG] Stephen Farrell's No Objection on draft-ietf-oauth-saml2-bearer-21: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 11:20:39 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-oauth-saml2-bearer-21: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - intro para2: might be nice (no more) to add some refs to other protocols that use SAML. - 2.2: What are "padding bits" in 4648? I don't recall such. (But may be misremembering.) - section 3, list item 2: This doesn't quite say that the token endpoint URL MUST (in the absence of another profile) be in an Audience element. Why not? The text seems to me to allow for the AS to map the token endpoint URL to any value in an Audience element that the AS finds ok. I suspect that might be unwise, but it at least needs to be clear. Is that the text being ambiguous or me being paranoid/wrong? Same point seems to apply elsewhere too: = in item 3.A where it says "typically identifies" but does not say how. = in item 5 "or an acceptable alias" - section 3, item 7: How might an AS know that "the Assertion was issued with the intention that the client act autonomously on behalf of the subject"? From nobody Thu Oct 16 04:22:23 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C7641A1A7C; Thu, 16 Oct 2014 04:22:20 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8oSZgNWSRLB; Thu, 16 Oct 2014 04:22:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 54E3C1AD04C; Thu, 16 Oct 2014 04:22:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141016112213.10005.54238.idtracker@ietfa.amsl.com> Date: Thu, 16 Oct 2014 04:22:13 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/5YIyuzgefx1cKuIuTcJx4840QCk Cc: draft-ietf-oauth-assertions@tools.ietf.org, oauth-chairs@tools.ietf.org, oauth@ietf.org Subject: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 11:22:21 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-oauth-assertions-17: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Putting one discuss here rather than one on each of the other docs. We can fix that as appropriate after we chat. Where are the MTI signature and mac algs for these specified? If those can be tracked back via the SAML and jose docs that's fine, but I'm not sure if they are. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - general: What prevents/detects conflicts between the oauth scope parameter and the saml or jwt equivalent? Are there other bits of replicated data that could be the basis for a vulnerability? (The comment below applies for both saml and jwt so putting it here.) - The no replay protection issue was debated in the WG wasn't it? (I think I recall it, not sure.) Seems like a bad plan to me to not require at least implementation of replay protection in the AS so that it can be turned on. Can you point me at where that was discussed on the list? From nobody Thu Oct 16 04:22:57 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 537061AD04C; Thu, 16 Oct 2014 04:22:47 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EEk-tWhtNOiO; Thu, 16 Oct 2014 04:22:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D0EC41AD055; Thu, 16 Oct 2014 04:22:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141016112244.8382.80012.idtracker@ietfa.amsl.com> Date: Thu, 16 Oct 2014 04:22:44 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/qzV3CSVFCmcBHCs5FfqZwXCZquE Cc: oauth-chairs@tools.ietf.org, draft-ietf-oauth-jwt-bearer@tools.ietf.org, oauth@ietf.org Subject: [OAUTH-WG] Stephen Farrell's No Objection on draft-ietf-oauth-jwt-bearer-10: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 11:22:47 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-oauth-jwt-bearer-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - 2.1, assertion parameter: How come this one does not talk about base64url whereas the saml one does? From nobody Thu Oct 16 04:37:08 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16DF31A1A43 for ; Thu, 16 Oct 2014 04:37:02 -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, SPF_PASS=-0.001] autolearn=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 BSNexA-ooFcU for ; Thu, 16 Oct 2014 04:36:57 -0700 (PDT) Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16F9E1A1A37 for ; Thu, 16 Oct 2014 04:36:57 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id hy4so2511537vcb.28 for ; Thu, 16 Oct 2014 04:36:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=x0oecetJSQgq8xT10C3DTkocQpMwnvLWv4Rz20mvA44=; b=l6MOcwF3Qkan1k2Nq3TqFfT+4s1mOMneMQm0UQAXT3axQCAK5ofjJtsrffbq9xxvoe PfDAnh5Oio7ZURys7b9HUlW5SS+wm0dqQTigcp4whCe9dcCJWuiZAo2JNNntdeViSlw0 8OfvUKoOQF1+0z3dL5lhHxpdD1I4ORmmAf5LGCXHAmr2wm1+f7JQJaZTBgQgopyPxV6x yqTKAFsKPsGkKY52DLcYjD4wKI7yMN2kJZ2ocqAvoccBvZPhWa30aXnYPTvZEEG8OI5q W5yYf0OTvCIldoL9BFBsQ4RmC0a1t1eNRlnO9LVef+0UDoJyM4uC3I7088lQrfyKtF47 3GOg== MIME-Version: 1.0 X-Received: by 10.220.158.137 with SMTP id f9mr429805vcx.34.1413459415909; Thu, 16 Oct 2014 04:36:55 -0700 (PDT) Received: by 10.220.162.68 with HTTP; Thu, 16 Oct 2014 04:36:55 -0700 (PDT) Received: by 10.220.162.68 with HTTP; Thu, 16 Oct 2014 04:36:55 -0700 (PDT) In-Reply-To: References: Date: Thu, 16 Oct 2014 04:36:55 -0700 Message-ID: From: GHOST SPY To: oauth@ietf.org Content-Type: multipart/alternative; boundary=001a11c28b1663c862050588aa9e Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/5ddsLPj5ssHpmnK5jwjtN7-7C_I Subject: Re: [OAUTH-WG] OAuth Digest, Vol 72, Issue 31 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 11:37:02 -0000 --001a11c28b1663c862050588aa9e Content-Type: text/plain; charset=UTF-8 Ghostcharmer13@gmail.com On Oct 16, 2014 4:21 AM, wrote: > Send OAuth mailing list submissions to > oauth@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/oauth > or, via email, send a message with subject or body 'help' to > oauth-request@ietf.org > > You can reach the person managing the list at > oauth-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OAuth digest..." > > > Today's Topics: > > 1. Re: Pete Resnick's No Objection on > draft-ietf-oauth-assertions-17: (with COMMENT) (Brian Campbell) > 2. Re: Pete Resnick's No Objection on > draft-ietf-oauth-assertions-17: (with COMMENT) (Pete Resnick) > 3. Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: > (with DISCUSS and COMMENT) (Richard Barnes) > 4. Richard Barnes' Discuss on draft-ietf-oauth-saml2-bearer-21: > (with DISCUSS) (Richard Barnes) > 5. Richard Barnes' Discuss on draft-ietf-oauth-jwt-bearer-10: > (with DISCUSS and COMMENT) (Richard Barnes) > 6. Stephen Farrell's No Objection on > draft-ietf-oauth-saml2-bearer-21: (with COMMENT) (Stephen Farrell) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 15 Oct 2014 17:35:19 -0600 > From: Brian Campbell > To: Barry Leiba > Cc: "draft-ietf-oauth-assertions@tools.ietf.org" > , Pete Resnick > , oauth , > "oauth-chairs@tools.ietf.org" , The > IESG > > Subject: Re: [OAUTH-WG] Pete Resnick's No Objection on > draft-ietf-oauth-assertions-17: (with COMMENT) > Message-ID: > < > CA+k3eCTRRyK-oW_SaQVckgh3Hinbs_igiU8TBt4iPkASXaQNJQ@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Fair point. I'll add some text saying that in the next revision. > > On Wed, Oct 15, 2014 at 5:18 PM, Barry Leiba > wrote: > > > > >>> Assertions used in the protocol exchanges defined by this > >>> specification MUST always be protected against tampering using a > >>> digital signature or a keyed message digest applied by the issuer. > >>> > >>> Why is that? Aren't you using assertions over a protected channel (as > >>> required by the spec) and therefore not need to sign the assertions? > >>> Indeed, why would a self-issued Bearer Assertion need to be signed at > >>> all? Does that even make sense? > >>> > >>> > >> Yes, assertions are sent over a protected channel, which does provide > >> integrity protection for the transport form client to AS and also gives > >> server authentication. But it doesn't provide client authentication, > which > >> is kind of the point of the Client Authentication part of this draft. > And > >> for authorization the signing or MACing is what authenticates the > issuer of > >> the assertion - sometimes the issuer is the client but often the issuer > >> will be a 3rd party system. > >> > >> I do agree with you in one specific case that, if the client is trusted > >> to be the assertion issuer and the client is properly authenticated, > then > >> an unsigned assertion could be reasonably used as an authorization > grant. > >> But it's a fairly rare and very specific case. And one that can be > >> accommodated in other ways. So it's not worth introducing the complexity > >> and potential security problems that having the signature be option > would > >> bring. > >> > > > > In other words, the assertion must be protected against tampering *by the > > party that presents the assertion*. That is a significant point, and you > > should say it. > > > > Barry > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://www.ietf.org/mail-archive/web/oauth/attachments/20141015/27bf1330/attachment.html > > > > ------------------------------ > > Message: 2 > Date: Wed, 15 Oct 2014 21:30:26 -0500 > From: Pete Resnick > To: Brian Campbell > Cc: "draft-ietf-oauth-assertions@tools.ietf.org" > , > "oauth-chairs@tools.ietf.org" , The > IESG > , oauth > Subject: Re: [OAUTH-WG] Pete Resnick's No Objection on > draft-ietf-oauth-assertions-17: (with COMMENT) > Message-ID: <543F2DC2.1050300@qti.qualcomm.com> > Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" > > On 10/15/14 6:06 PM, Brian Campbell wrote: > > Thanks for your review and feedback, Pete. Replies are inline below... > > Thanks for addressing the comments, including Barry's followup. Just on > the questions: > > > On Tue, Oct 14, 2014 at 2:42 PM, Pete Resnick > > > wrote: > > > > scope > > [...] > > As such, the > > requested scope MUST be equal or lesser than the scope > > originally > > granted to the authorized accessor. > > > > s/MUST/will (unless you explain whether it's the server or the client > > that's supposed to be obeying that MUST, and for what reason) > > > > > > They are both supposed to obey it - the client shouldn't ask for more > > and the server will reject the request, if it does. > > > > Is "will" more appropriate than "MUST" here? Or maybe a non 2119 > "should"? > > Ah, so you're saying that a client could conceivably (either purposely > or accidentally) try to sneak through a larger scope than it should, and > the client MUST NOT do that, and the server MUST reject if it gets one. > OK, that makes sense. (I do tend to like active MUSTs -- the foo MUST do > X or the bar MUST NOT do Y -- but this is probably OK as is.) > > > Here and throughout: s/non-normative example/example (As far as I > > know, > > there are no other kinds in IETF documents.) > > > > > > I thought I picked that language up from some other draft or RFC but > > I'm now not sure where it came from and can't easily find other > > examples of the same thing. So I am happy to remove the > > "non-normative" throughout, if it is already understood and/or not > > customary to say so. > > Yeah, we've seen other RFCs with such language. I've whined about it in > the past. Some authors roll their eyes at me. You are welcome to roll > your eyes if you like, but I find such text silly. :-) > > Thanks for the rest of the planned changes. Looks good. > > pr > > -- > Pete Resnick > Qualcomm Technologies, Inc. - +1 (858)651-4478 > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://www.ietf.org/mail-archive/web/oauth/attachments/20141015/d746e674/attachment.html > > > > ------------------------------ > > Message: 3 > Date: Wed, 15 Oct 2014 20:47:35 -0700 > From: "Richard Barnes" > To: The IESG > Cc: draft-ietf-oauth-assertions@tools.ietf.org, > oauth-chairs@tools.ietf.org, oauth@ietf.org > Subject: [OAUTH-WG] Richard Barnes' Discuss on > draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT) > Message-ID: <20141016034735.18695.61014.idtracker@ietfa.amsl.com> > Content-Type: text/plain; charset="utf-8" > > Richard Barnes has entered the following ballot position for > draft-ietf-oauth-assertions-17: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > "The assertion MUST contain an Audience that identifies the Authorization > Server as the intended audience. Assertions that do not identify the > Authorization Server as an intended audience MUST be rejected." > > Could you please identify the threat model within which this "MUST" is > required? This requirement doesn't follow from any of the threats > elaborated in Section 8. > > The Audience is only necessary if the Issuer wishes to constrain the set > of Authorization Servers with which an assertion may be used. So ISTM > that this should be "MAY contain..." > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > "keyed message digest" -> "Message Authentication Code" > > That's the proper terminology [RFC4949], especially since there are MACs > that are not based on digests. > > "This mechanism provides additional security properties." -- Please > delete this or elaborate on what security properties it provides. > > Section 8.2 should note that "Holder-of-Key Assertions" are also a > mitigation for this risk. > > > > > ------------------------------ > > Message: 4 > Date: Wed, 15 Oct 2014 20:56:40 -0700 > From: "Richard Barnes" > To: The IESG > Cc: oauth-chairs@tools.ietf.org, > draft-ietf-oauth-saml2-bearer@tools.ietf.org, oauth@ietf.org > Subject: [OAUTH-WG] Richard Barnes' Discuss on > draft-ietf-oauth-saml2-bearer-21: (with DISCUSS) > Message-ID: <20141016035640.25108.27277.idtracker@ietfa.amsl.com> > Content-Type: text/plain; charset="utf-8" > > Richard Barnes has entered the following ballot position for > draft-ietf-oauth-saml2-bearer-21: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > As with draft-ietf-oauth-assertions, the requirement for an > element seems entirely unnecessary. Holding this DISCUSS point pending > that discussion and its reflection in this document. > > "Assertions that do not identify the Authorization Server as an intended > audience MUST be rejected." -- What does it mean for an assertion to > "identify the Authorization Server"? Does the specified need > to match the entire URL of the relevant OAuth endpoint? Just the origin? > Just the domain? Does the URL need to be canonicalized? > > > > > > > ------------------------------ > > Message: 5 > Date: Wed, 15 Oct 2014 21:01:22 -0700 > From: "Richard Barnes" > To: The IESG > Cc: oauth-chairs@tools.ietf.org, > draft-ietf-oauth-jwt-bearer@tools.ietf.org, oauth@ietf.org > Subject: [OAUTH-WG] Richard Barnes' Discuss on > draft-ietf-oauth-jwt-bearer-10: (with DISCUSS and COMMENT) > Message-ID: <20141016040122.32277.7067.idtracker@ietfa.amsl.com> > Content-Type: text/plain; charset="utf-8" > > Richard Barnes has entered the following ballot position for > draft-ietf-oauth-jwt-bearer-10: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > As with draft-ietf-oauth-assertions, the requirement for an "aud" claim > seems entirely unnecessary. Holding this DISCUSS point pending that > discussion > and its reflection in this document. > > "Assertions that do not identify the Authorization Server as an intended > audience MUST be rejected." -- What does it mean for an assertion to > "identify > the Authorization Server"? Does the specified need to match > the > entire URL of the relevant OAuth endpoint? Just the origin? Just the > domain? > Does the URL need to be canonicalized? > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > "keyed message digest" -> "MAC" > > Both this and the SAML document could save a lot of bits by just being > subsections of the -assertions document. > > > > > ------------------------------ > > Message: 6 > Date: Thu, 16 Oct 2014 04:20:32 -0700 > From: "Stephen Farrell" > To: The IESG > Cc: oauth-chairs@tools.ietf.org, > draft-ietf-oauth-saml2-bearer@tools.ietf.org, oauth@ietf.org > Subject: [OAUTH-WG] Stephen Farrell's No Objection on > draft-ietf-oauth-saml2-bearer-21: (with COMMENT) > Message-ID: <20141016112032.13008.86094.idtracker@ietfa.amsl.com> > Content-Type: text/plain; charset="utf-8" > > Stephen Farrell has entered the following ballot position for > draft-ietf-oauth-saml2-bearer-21: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > - intro para2: might be nice (no more) to add some refs to > other protocols that use SAML. > > - 2.2: What are "padding bits" in 4648? I don't recall such. > (But may be misremembering.) > > - section 3, list item 2: This doesn't quite say that the > token endpoint URL MUST (in the absence of another profile) be > in an Audience element. Why not? The text seems to me to allow > for the AS to map the token endpoint URL to any value in an > Audience element that the AS finds ok. I suspect that might be > unwise, but it at least needs to be clear. Is that the text > being ambiguous or me being paranoid/wrong? Same point seems > to apply elsewhere too: > = in item 3.A where it says "typically identifies" but > does not say how. > = in item 5 "or an acceptable alias" > > - section 3, item 7: How might an AS know that "the Assertion > was issued with the intention that the client act autonomously > on behalf of the subject"? > > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > ------------------------------ > > End of OAuth Digest, Vol 72, Issue 31 > ************************************* > --001a11c28b1663c862050588aa9e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Ghostcharmer13@g= mail.com

On Oct 16, 2014 4:21 AM, <oauth-request@ietf.org> wrote:
Send OAuth mailing list submissio= ns to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth@ietf.or= g

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

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

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


Today's Topics:

=C2=A0 =C2=A01. Re: Pete Resnick's No Objection on
=C2=A0 =C2=A0 =C2=A0 draft-ietf-oauth-assertions-17: (with COMMENT) (Brian = Campbell)
=C2=A0 =C2=A02. Re: Pete Resnick's No Objection on
=C2=A0 =C2=A0 =C2=A0 draft-ietf-oauth-assertions-17: (with COMMENT) (Pete R= esnick)
=C2=A0 =C2=A03. Richard Barnes' Discuss on draft-ietf-oauth-assertions-= 17:
=C2=A0 =C2=A0 =C2=A0 (with DISCUSS and COMMENT) (Richard Barnes)
=C2=A0 =C2=A04. Richard Barnes' Discuss on draft-ietf-oauth-saml2-beare= r-21:
=C2=A0 =C2=A0 =C2=A0 (with DISCUSS) (Richard Barnes)
=C2=A0 =C2=A05. Richard Barnes' Discuss on draft-ietf-oauth-jwt-bearer-= 10:
=C2=A0 =C2=A0 =C2=A0 (with DISCUSS and COMMENT) (Richard Barnes)
=C2=A0 =C2=A06. Stephen Farrell's No Objection on
=C2=A0 =C2=A0 =C2=A0 draft-ietf-oauth-saml2-bearer-21: (with COMMENT) (Step= hen Farrell)


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

Message: 1
Date: Wed, 15 Oct 2014 17:35:19 -0600
From: Brian Campbell <bcam= pbell@pingidentity.com>
To: Barry Leiba <barryleiba@c= omputer.org>
Cc: "dra= ft-ietf-oauth-assertions@tools.ietf.org"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <draft-ietf-oauth-assertions@tools.ietf.org>, Pete= Resnick
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <presnick@qti.qualcomm.com>, oauth <oauth@ietf.org>,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "oauth-chairs@tools.ietf.org" <oauth-chairs@tools.ietf.org>, The IESG
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <iesg@ietf.= org>
Subject: Re: [OAUTH-WG] Pete Resnick's No Objection on
=C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-ietf-oauth-assertions-17: (with COMMENT)<= br> Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <CA+k3eCTRRyK-oW_SaQVckgh3Hinbs= _igiU8TBt4iPkASXaQNJQ@mail.gmail.com>
Content-Type: text/plain; charset=3D"utf-8"

Fair point. I'll add some text saying that in the next revision.

On Wed, Oct 15, 2014 at 5:18 PM, Barry Leiba <barryleiba@computer.org>
wrote:

>
>>>=C2=A0 =C2=A0 Assertions used in the protocol exchanges defined= by this
>>>=C2=A0 =C2=A0 specification MUST always be protected against ta= mpering using a
>>>=C2=A0 =C2=A0 digital signature or a keyed message digest appli= ed by the issuer.
>>>
>>> Why is that? Aren't you using assertions over a protected = channel (as
>>> required by the spec) and therefore not need to sign the asser= tions?
>>> Indeed, why would a self-issued Bearer Assertion need to be si= gned at
>>> all? Does that even make sense?
>>>
>>>
>> Yes, assertions are sent over a protected channel, which does prov= ide
>> integrity protection for the transport form client to AS and also = gives
>> server authentication. But it doesn't provide client authentic= ation, which
>> is kind of the point of the Client Authentication part of this dra= ft. And
>> for authorization the signing or MACing is what authenticates the = issuer of
>> the assertion - sometimes the issuer is the client but often the i= ssuer
>> will be a 3rd party system.
>>
>> I do agree with you in one specific case that, if the client is tr= usted
>> to be the assertion issuer and the client is properly authenticate= d, then
>> an unsigned assertion could be reasonably used as an authorization= grant.
>> But it's a fairly rare and very specific case. And one that ca= n be
>> accommodated in other ways. So it's not worth introducing the = complexity
>> and potential security problems that having the signature be optio= n would
>> bring.
>>
>
> In other words, the assertion must be protected against tampering *by = the
> party that presents the assertion*.=C2=A0 That is a significant point,= and you
> should say it.
>
> Barry
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/ma= il-archive/web/oauth/attachments/20141015/27bf1330/attachment.html><= br>
------------------------------

Message: 2
Date: Wed, 15 Oct 2014 21:30:26 -0500
From: Pete Resnick <presnic= k@qti.qualcomm.com>
To: Brian Campbell <bcampb= ell@pingidentity.com>
Cc: "dra= ft-ietf-oauth-assertions@tools.ietf.org"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <draft-ietf-oauth-assertions@tools.ietf.org>,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "oauth-chairs@tools.ietf.org" <oauth-chairs@tools.ietf.org>, The IESG
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <iesg@ietf.= org>, oauth <oauth@ietf.org= >
Subject: Re: [OAUTH-WG] Pete Resnick's No Objection on
=C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-ietf-oauth-assertions-17: (with COMMENT)<= br> Message-ID: <543F2D= C2.1050300@qti.qualcomm.com>
Content-Type: text/plain; charset=3D"iso-8859-1"; Format=3D"= flowed"

On 10/15/14 6:06 PM, Brian Campbell wrote:
> Thanks for your review and feedback, Pete. Replies are inline below...=

Thanks for addressing the comments, including Barry's followup. Just on=
the questions:

> On Tue, Oct 14, 2014 at 2:42 PM, Pete Resnick
> <presnick@qti.qualcomm= .com <mailto:presnick@q= ti.qualcomm.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0scope
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[...]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 As such, the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0requested scope MUST be equal = or lesser than the scope
>=C2=A0 =C2=A0 =C2=A0originally
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0granted to the authorized acce= ssor.
>
>=C2=A0 =C2=A0 =C2=A0s/MUST/will (unless you explain whether it's th= e server or the client
>=C2=A0 =C2=A0 =C2=A0that's supposed to be obeying that MUST, and fo= r what reason)
>
>
> They are both supposed to obey it - the client shouldn't ask for m= ore
> and the server will reject the request, if it does.
>
> Is "will" more appropriate than "MUST" here? Or ma= ybe a non 2119 "should"?

Ah, so you're saying that a client could conceivably (either purposely<= br> or accidentally) try to sneak through a larger scope than it should, and the client MUST NOT do that, and the server MUST reject if it gets one.
OK, that makes sense. (I do tend to like active MUSTs -- the foo MUST do X or the bar MUST NOT do Y -- but this is probably OK as is.)

>=C2=A0 =C2=A0 =C2=A0Here and throughout: s/non-normative example/exampl= e (As far as I
>=C2=A0 =C2=A0 =C2=A0know,
>=C2=A0 =C2=A0 =C2=A0there are no other kinds in IETF documents.)
>
>
> I thought I picked that language up from some other draft or RFC but > I'm now not sure where it came from and can't easily find othe= r
> examples of the same thing.=C2=A0 So I am happy to remove the
> "non-normative" throughout, if it is already understood and/= or not
> customary to say so.

Yeah, we've seen other RFCs with such language. I've whined about i= t in
the past. Some authors roll their eyes at me. You are welcome to roll
your eyes if you like, but I find such text silly. :-)

Thanks for the rest of the planned changes. Looks good.

pr

--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/ma= il-archive/web/oauth/attachments/20141015/d746e674/attachment.html><= br>
------------------------------

Message: 3
Date: Wed, 15 Oct 2014 20:47:35 -0700
From: "Richard Barnes" <rlb@ipv.sx>
To: The IESG <iesg@ietf.org>
Cc: draft-iet= f-oauth-assertions@tools.ietf.org,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = oauth-chairs@tools.ietf.org, oauth@ie= tf.org
Subject: [OAUTH-WG] Richard Barnes' Discuss on
=C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-ietf-oauth-assertions-17: (with DISCUSS a= nd COMMENT)
Message-ID: <20141016034735.18695.61014.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=3D"utf-8"

Richard Barnes has entered the following ballot position for
draft-ietf-oauth-assertions-17: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-crit= eria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions= /



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

"The assertion MUST contain an Audience that identifies the Authorizat= ion
Server as the intended audience.=C2=A0 Assertions that do not identify the<= br> Authorization Server as an intended audience MUST be rejected."

Could you please identify the threat model within which this "MUST&quo= t; is
required?=C2=A0 This requirement doesn't follow from any of the threats=
elaborated in Section 8.

The Audience is only necessary if the Issuer wishes to constrain the set of Authorization Servers with which an assertion may be used.=C2=A0 So ISTM=
that this should be "MAY contain..."


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

"keyed message digest" -> "Message Authentication Code&qu= ot;

That's the proper terminology [RFC4949], especially since there are MAC= s
that are not based on digests.

"This mechanism provides additional security properties." -- Plea= se
delete this or elaborate on what security properties it provides.

Section 8.2 should note that "Holder-of-Key Assertions" are also = a
mitigation for this risk.




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

Message: 4
Date: Wed, 15 Oct 2014 20:56:40 -0700
From: "Richard Barnes" <rlb@ipv.sx>
To: The IESG <iesg@ietf.org>
Cc: oauth-chairs@tools.ietf.= org,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-ietf-oauth-saml2-bearer@tools.ietf.org, oauth@ietf.org
Subject: [OAUTH-WG] Richard Barnes' Discuss on
=C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-ietf-oauth-saml2-bearer-21: (with DISCUSS= )
Message-ID: <20141016035640.25108.27277.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=3D"utf-8"

Richard Barnes has entered the following ballot position for
draft-ietf-oauth-saml2-bearer-21: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-crit= eria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-be= arer/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

As with draft-ietf-oauth-assertions, the requirement for an <Audience>= ;
element seems entirely unnecessary.=C2=A0 Holding this DISCUSS point pendin= g
that discussion and its reflection in this document.

"Assertions that do not identify the Authorization Server as an intend= ed
audience MUST be rejected." -- What does it mean for an assertion to "identify the Authorization Server"?=C2=A0 Does the specified <= ;Audience> need
to match the entire URL of the relevant OAuth endpoint?=C2=A0 Just the orig= in?
=C2=A0Just the domain?=C2=A0 Does the URL need to be canonicalized?






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

Message: 5
Date: Wed, 15 Oct 2014 21:01:22 -0700
From: "Richard Barnes" <rlb@ipv.sx>
To: The IESG <iesg@ietf.org>
Cc: oauth-chairs@tools.ietf.= org,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-ietf-oauth-jwt-bearer@tools.ietf.org, oauth@ietf.org
Subject: [OAUTH-WG] Richard Barnes' Discuss on
=C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-ietf-oauth-jwt-bearer-10: (with DISCUSS a= nd COMMENT)
Message-ID: <20141016040122.32277.7067.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=3D"utf-8"

Richard Barnes has entered the following ballot position for
draft-ietf-oauth-jwt-bearer-10: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-crit= eria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer= /



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

As with draft-ietf-oauth-assertions, the requirement for an "aud"= claim
seems entirely unnecessary.=C2=A0 Holding this DISCUSS point pending that discussion
and its reflection in this document.

"Assertions that do not identify the Authorization Server as an intend= ed
audience MUST be rejected." -- What does it mean for an assertion to "identify
the Authorization Server"?=C2=A0 Does the specified <Audience> n= eed to match
the
entire URL of the relevant OAuth endpoint?=C2=A0 Just the origin?=C2=A0 Jus= t the
domain?
Does the URL need to be canonicalized?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

"keyed message digest" -> "MAC"

Both this and the SAML document could save a lot of bits by just being
subsections of the -assertions document.




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

Message: 6
Date: Thu, 16 Oct 2014 04:20:32 -0700
From: "Stephen Farrell" <stephen.farrell@cs.tcd.ie>
To: The IESG <iesg@ietf.org>
Cc: oauth-chairs@tools.ietf.= org,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-ietf-oauth-saml2-bearer@tools.ietf.org, oauth@ietf.org
Subject: [OAUTH-WG] Stephen Farrell's No Objection on
=C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-ietf-oauth-saml2-bearer-21: (with COMMENT= )
Message-ID: <20141016112032.13008.86094.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=3D"utf-8"

Stephen Farrell has entered the following ballot position for
draft-ietf-oauth-saml2-bearer-21: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-crit= eria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-be= arer/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


- intro para2: might be nice (no more) to add some refs to
other protocols that use SAML.

- 2.2: What are "padding bits" in 4648? I don't recall such.<= br> (But may be misremembering.)

- section 3, list item 2: This doesn't quite say that the
token endpoint URL MUST (in the absence of another profile) be
in an Audience element. Why not? The text seems to me to allow
for the AS to map the token endpoint URL to any value in an
Audience element that the AS finds ok. I suspect that might be
unwise, but it at least needs to be clear. Is that the text
being ambiguous or me being paranoid/wrong? Same point seems
to apply elsewhere too:
=C2=A0 =C2=A0=3D in item 3.A where it says "typically identifies"= but
=C2=A0 =C2=A0does not say how.
=C2=A0 =C2=A0=3D in item 5 "or an acceptable alias"

- section 3, item 7: How might an AS know that "the Assertion
was issued with the intention that the client act autonomously
on behalf of the subject"?




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

Subject: Digest Footer

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


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

End of OAuth Digest, Vol 72, Issue 31
*************************************
--001a11c28b1663c862050588aa9e-- From nobody Thu Oct 16 04:38:36 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 349541AD065 for ; Thu, 16 Oct 2014 04:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 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, SPF_PASS=-0.001, TVD_SPACE_RATIO=0.001] autolearn=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 1Z-rwrFvvxQ9 for ; Thu, 16 Oct 2014 04:38:31 -0700 (PDT) Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5FE91AD062 for ; Thu, 16 Oct 2014 04:38:30 -0700 (PDT) Received: by mail-vc0-f179.google.com with SMTP id im17so2526545vcb.10 for ; Thu, 16 Oct 2014 04:38:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=ZXHvo9pNLDDL+v1vO+PFeqrH9wpVdl7mOOMd2QX8eVc=; b=vK3DFqwROQE05NYRmlTqhLZx63LMuSUUn5u2uuTcJrlj5H9zXz0nYdOclR0yU/z7Rn 4iotOlBTMGMZpMuMblnDdnshN0py/+68i7iJgSlpYOZzrVRNHaz9lyYWKdlgI9ZjsI1G +JshyLYJpDZWoi63zwP+CaovI4T1tB6+1916JFl6dWE4RLF6/16UpTKGAsPrbLvf9XHY mNX4UVTMcr+7LqfIkLdTDC94tEQLfGV9jsCL6qkZijjgRdzLhBU241EWFlt5vWB/8Et2 hW866Prt0JCf5RfvvMOqqIyurxx3o4BB40uVHhRQf2spmq/Mui+fsC04l/3lB5Qt0Xgx a4gg== MIME-Version: 1.0 X-Received: by 10.52.242.198 with SMTP id ws6mr335064vdc.21.1413459509169; Thu, 16 Oct 2014 04:38:29 -0700 (PDT) Received: by 10.220.162.68 with HTTP; Thu, 16 Oct 2014 04:38:29 -0700 (PDT) Received: by 10.220.162.68 with HTTP; Thu, 16 Oct 2014 04:38:29 -0700 (PDT) Date: Thu, 16 Oct 2014 04:38:29 -0700 Message-ID: From: GHOST SPY To: OAuth@ietf.org Content-Type: multipart/alternative; boundary=001a1135e382f2d366050588af09 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/tyo6cJkG0Uut0U5NBjsCwMsDtRY Subject: [OAUTH-WG] (no subject) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 11:38:32 -0000 --001a1135e382f2d366050588af09 Content-Type: text/plain; charset=UTF-8 Ghostcharmer13@gmail.com --001a1135e382f2d366050588af09 Content-Type: text/html; charset=UTF-8

Ghostcharmer13@gmail.com

--001a1135e382f2d366050588af09-- From nobody Thu Oct 16 05:33:46 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CAE51A1AA6; Thu, 16 Oct 2014 05:33: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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Wc6GcqufMY8; Thu, 16 Oct 2014 05:33:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 13B831A0360; Thu, 16 Oct 2014 05:33:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141016123342.13816.96049.idtracker@ietfa.amsl.com> Date: Thu, 16 Oct 2014 05:33:42 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/8OblV4tDVox4WzyubdllP-_wFWc Cc: oauth-chairs@tools.ietf.org, draft-ietf-oauth-saml2-bearer@tools.ietf.org, oauth@ietf.org Subject: [OAUTH-WG] Benoit Claise's No Objection on draft-ietf-oauth-saml2-bearer-21: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 12:33:43 -0000 Benoit Claise has entered the following ballot position for draft-ietf-oauth-saml2-bearer-21: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I cleared my DISCUSS on the basis that RFC 6755 will be moved to an informative reference in response to this process issue: IDnits complains of a normative reference to Informational document RFC 6755, which was not noted in the Last Call announcement. Editorial Nits: S2.2: The paragraph before the actual example uses terminology inconsistent with RFC 6749: s/authorization code grant/authorization grant/ From nobody Thu Oct 16 05:57:29 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5851D1A1B3A for ; Thu, 16 Oct 2014 05:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ul-TYiIBIt8C for ; Thu, 16 Oct 2014 05:57:23 -0700 (PDT) Received: from na3sys009aog119.obsmtp.com (na3sys009aog119.obsmtp.com [74.125.149.246]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 517461A1B2B for ; Thu, 16 Oct 2014 05:57:23 -0700 (PDT) Received: from mail-ig0-f169.google.com ([209.85.213.169]) (using TLSv1) by na3sys009aob119.postini.com ([74.125.148.12]) with SMTP ID DSNKVD/Asn7AwEgkf2e/n2ckvZ7TIEfcXi96@postini.com; Thu, 16 Oct 2014 05:57:23 PDT Received: by mail-ig0-f169.google.com with SMTP id uq10so981235igb.2 for ; Thu, 16 Oct 2014 05:57:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=iifF6nqlUrhh25pNbuz1y6VT2pmaJOM8W8SPPKPQOVA=; b=DqLNc7gn28e2Pi6rWRqhsv6GKNCMqjdkrt4b3CojcJepAewKl3vSzpLp52Y6y9HviH BIOY+mM5PSEZjGaY8SBisFyfJwrM8ejeaexL5FFzdpGzeLAhPX8lh+g1VOJot5e/Gevo 2QLcIKlzO5yFDP/A3p40K/609qXem+mG/Wxmge7yuLt+tIgqeFIEIXMjEhye8dtyB2fA 6ZUYpBcwU0stFaGq4p8HFAUDzamlIDwTMnmiinM8JHBNRpKg9CAP4+DDM65yLxryZlLa ZuobhKkWjrohciUHDltpQ+uYIUmGqDSKAdU+EvuT9RccxVidOYTucyHO0+JlX+lmQA2A Gvvw== X-Gm-Message-State: ALoCoQm/22skTHFPE3X8TIcpVhk+0WZqguntcTTbLRRNiN7RrrMUNh7BopN076MW30MahVloaQU6MF8jMja4Y4yI+kOJSj33xUHdC62QdVU7B85J6+hQF9H+XuTcWMFz3eFSIFMKuIDU X-Received: by 10.43.76.199 with SMTP id zf7mr3810386icb.57.1413464242494; Thu, 16 Oct 2014 05:57:22 -0700 (PDT) X-Received: by 10.43.76.199 with SMTP id zf7mr3810370icb.57.1413464242351; Thu, 16 Oct 2014 05:57:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.12.137 with HTTP; Thu, 16 Oct 2014 05:56:52 -0700 (PDT) In-Reply-To: <20141015015609.5671.70479.idtracker@ietfa.amsl.com> References: <20141015015609.5671.70479.idtracker@ietfa.amsl.com> From: Brian Campbell Date: Thu, 16 Oct 2014 06:56:52 -0600 Message-ID: To: Pete Resnick Content-Type: multipart/alternative; boundary=001a11c3b252119baa050589caea Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/G637ru6Pz9NBvwGwd8kJi4NLpu4 Cc: "oauth-chairs@tools.ietf.org" , draft-ietf-oauth-saml2-bearer@tools.ietf.org, The IESG , oauth Subject: Re: [OAUTH-WG] Pete Resnick's No Objection on draft-ietf-oauth-saml2-bearer-21: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 12:57:27 -0000 --001a11c3b252119baa050589caea Content-Type: text/plain; charset=UTF-8 Thanks for your review and feedback on this one too, Pete. Replies are inline below... On Tue, Oct 14, 2014 at 7:56 PM, Pete Resnick wrote: > Pete Resnick has entered the following ballot position for > draft-ietf-oauth-saml2-bearer-21: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > 2.1/2.2 - This paragraph shows why I don't like haphazard use of 2119. > Apologies for any haphazardness. This particular document was born out of my first I-D and, while I was and still am a little green on this stuff, I've endeavored to use 2119 language appropriately but it's not always easy for mere mortals such as myself. The "MUST be" that you mention below, for example, always felt somewhat silly to me too but I was trying to follow from the examples in RFC 6749 -> see grant_type in http://tools.ietf.org/html/rfc6749#section-4.1.3 for one such example. > The first "MUST be" is obviously silly and should simply be "is". OK > But the > second one buries what *might* be a proper and important use of MUST (you > MUST NOT try to stick in two SAML Assertions) with a simple definitional > one. (And that assumes that it's even plausible to try to use more than > one SAML Assertion. If you simply can't, it's just s/MUST > contain/contains.) It's intended to be both definitional and restrictive - that it contains an assertion but not more than one. The Response document in SAML Web SSO allows for multiple assertions and it has turned out to be quite a pain to deal with in practice while not adding any real value. While it's not entirely clear how one might try and stick more than one assertion in this parameter given the serialization, I still wanted to explicitly preclude it. Given that explanation of the intent, would you suggest an alternative wording of that sentence? Or is it okay as is? > The base64url encoding MUST is fine, because you don't > want people sticking in raw XML, but the SHOULD NOTs for line wrapping > and pad I am curious about: Isn't a parser going to have to check for > line wrapping and pad anyway and undo it (because it's not a MUST NOT), > and therefore this SHOULD NOT really isn't about interoperability so much > as neatness (in which case they SHOULD NOTs are not appropriate)? > Yes, the base64 decoder still has to be prepared to deal with line wrapping and padding. In my experience most decoders are very capable of it. And stripping the white-space and "="s prior to decoding is easy enough for those using a decoder that can't. The SHOULD NOT is about neatness but also in a way about interop in that it's intended to help avoid common implementation problems that can arise with urlencoding the parameter value (either not encoding or double encoding, etc.). Base64url without line wraps and padding dosn't need urlencoding and doesn't change if urlencoding is applied. That was the thinking behind the SHOULD NOTs there. As I try and articulate the reasoning, it does feel like maybe it should have been a MUST NOT. I guess I was looking to channel Postel a bit in being somewhat liberal in what is accepted with padding/no padding and line wraps/no line wraps while using the SHOULD NOTs to suggest that clients be conservative in what they send. Thoughts about what to do with it, given that reasoning? > > 3 - Subpoint 2: Just for clarification, I like the non-passive sentence > better: "The Authorization Server MUST reject any assertion that does not > contain its own identity as the intended audience." > Yes, on seeing it written that way, I also like it better. Just to make sure I'm on the same page. The sentence you suggest would replace the second to last sentence in #2 that currently says, "Assertions that do not identify [...] MUST be rejected."? > > Subpoint 5: > OLD > The element MUST contain a > element, unless the Assertion has a > suitable NotOnOrAfter attribute on the element, in > which case the element MAY be omitted. > > That one's sure to get misquoted somewhere and confuse someone. Instead: > NEW > If the Assertion does not have a suitable NonOnOrAfter attribute > on the element, the element > MUST contain a element. > OK > > Subpoint 6: > OLD > The authorization server MUST verify that the NotOnOrAfter > instant has not passed, subject to allowable clock skew between > systems. An invalid NotOnOrAfter instant on the > element invalidates the entire Assertion. An invalid > NotOnOrAfter instant on a element only > invalidates the individual . > NEW > The authorization server MUST reject the entire Assertion if > the NotOnOrAfter instant on the element has passed > (subject to allowable clock skew between systems). The > authorization server MUST reject the (but > MAY still use the rest of the Assertion) if the NotOnOrAfter > instant on the has passed (subject to > allowable clock skew). > OK > > Subpoint 7: Are you sure those SHOULDs and SHOULD NOTs are not > conflicting? Can you not have an authenticated subject with an > autonomously acting client? > Perhaps I've misused the words but, yes, that's the idea. An autonomously acting client is meant to describe a client that's acting without the user being present. The act of direct user authentication with the assertion issuer seems like the way to differentiate between the user being present for things and the client doing things "in the background" for the user. Both are valid use cases. Item 7 is looking to provide the AS with some clue as to which is happening. I'm open to suggestions to clarify the text but I do believe there's no conflict. > > Subpoint 9: As I asked in the -assertions document, is this really a > requirement? > Short answer, yes it is. Longer answer, see the answer in that thread. > > Subpoint 11: Again, it would be better to put the MUST on the action > (e.g., "MUST reject") to make it clear who is doing what. > OK > > 3.1/3.2 - s/MUST construct/constructs > OK > > 4 - s/Though non-normative// > OK > > 9 - Seems like OASIS.saml-deleg-cs and OASIS.saml-sec-consider-2.0-os are > Normative, not Informative. > > OK. I wasn't sure but will change them to Normative unless someone yells otherwise about it. --001a11c3b252119baa050589caea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for your review and feedback on this o= ne too, Pete.=20 Replies are inline below...

On Tue, Oct 14, 2014 at 7:56 PM, Pete Resnick <presnick@qti.qualcomm.com> wrote:
Pete Resnick has entered the following ballot= position for
draft-ietf-oauth-saml2-bearer-21: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-crit= eria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-be= arer/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

2.1/2.2 - This paragraph shows why I don't like haphazard use of 2119.<= br>
=C2=A0

Apologies for any haph= azardness. This particular document was born out of my first I-D and, while= I was and still am a little green on this stuff, I've endeavored to us= e 2119 language appropriately but it's not always easy for mere mortals= such as myself.=C2=A0 The "MUST be" that you mention below, for = example, always felt somewhat silly to me too but I was trying to follow fr= om the examples in RFC 6749 -> see grant_type in http://tools.ietf.org/html/rfc6749#se= ction-4.1.3 for one such example.

=C2=A0<= /div>
The first "MUST be" is obviously silly and should simply be "= ;is".
=C2=A0

OK

=C2=A0
But th= e
second one buries what *might* be a proper and important use of MUST (you MUST NOT try to stick in two SAML Assertions) with a simple definitional one. (And that assumes that it's even plausible to try to use more than=
one SAML Assertion. If you simply can't, it's just s/MUST
contain/contains.)
=C2=A0

It'= s intended to be both definitional and restrictive - that it contains an as= sertion but not more than one.

The Response document in S= AML Web SSO allows for multiple assertions and it has turned out to be quit= e a pain to deal with in practice while not adding any real value. While it= 's not entirely clear how one might try and stick more than one asserti= on in this parameter given the serialization, I still wanted to explicitly = preclude it.

Given that explanation of the in= tent, would you suggest an alternative wording of that sentence? Or is it o= kay as is?

=C2=A0
The base64url encoding MUST is fine, because you don't=
want people sticking in raw XML, but the SHOULD NOTs for line wrapping
and pad I am curious about: Isn't a parser going to have to check for line wrapping and pad anyway and undo it (because it's not a MUST NOT),=
and therefore this SHOULD NOT really isn't about interoperability so mu= ch
as neatness (in which case they SHOULD NOTs are not appropriate)?


Yes, the base64 decoder still has to be prep= ared to deal with line wrapping and padding. In my experience most decoders= are very capable of it. And stripping the white-space and "=3D"s= prior to decoding is easy enough for those using a decoder that can't.=

The SHOULD NOT is about neatness but also in a way about= interop in that it's intended to help avoid common implementation prob= lems that can arise with urlencoding the parameter value (either not encodi= ng or double encoding, etc.).=C2=A0 Base64url without line wraps and paddin= g dosn't need urlencoding and doesn't change if urlencoding is appl= ied.

That was the thinking behind the SHOULD NOTs there.=

As I try and articulate the reasoning, it does feel like= maybe it should have been a MUST NOT. I guess I was looking to channel Pos= tel a bit in being somewhat liberal in what is accepted with padding/no pad= ding and line wraps/no line wraps while using the SHOULD NOTs to suggest th= at clients be conservative in what they send.=C2=A0

Thou= ghts about what to do with it, given that reasoning?

=C2= =A0

3 - Subpoint 2: Just for clarification, I like the non-passive sentence
better: "The Authorization Server MUST reject any assertion that does = not
contain its own identity as the intended audience."


Yes, on seeing it written that way, I also like it be= tter.

Just to make sure I'm on the same page. The sen= tence you suggest would replace the second to last sentence in #2 that curr= ently says, "Assertions that do not identify [...] MUST be rejected.&q= uot;?

=C2=A0

Subpoint 5:
OLD
=C2=A0 =C2=A0 =C2=A0 =C2=A0 The <SubjectConfirmation> element MUST co= ntain a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <SubjectConfirmationData> element, unless= the Assertion has a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 suitable NotOnOrAfter attribute on the <Cond= itions> element, in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 which case the <SubjectConfirmationData> = element MAY be omitted.

That one's sure to get misquoted somewhere and confuse someone. Instead= :
NEW
=C2=A0 =C2=A0 =C2=A0 =C2=A0 If the Assertion does not have a suitable NonOn= OrAfter attribute
=C2=A0 =C2=A0 =C2=A0 =C2=A0 on the <Conditions> element, the <Subj= ectConfirmation> element
=C2=A0 =C2=A0 =C2=A0 =C2=A0 MUST contain a <SubjectConfirmationData> = element.


OK
=C2=A0

Subpoint 6:
OLD
=C2=A0 =C2=A0 =C2=A0 =C2=A0 The authorization server MUST verify that the N= otOnOrAfter
=C2=A0 =C2=A0 =C2=A0 =C2=A0 instant has not passed, subject to allowable cl= ock skew between
=C2=A0 =C2=A0 =C2=A0 =C2=A0 systems.=C2=A0 An invalid NotOnOrAfter instant = on the <Conditions>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 element invalidates the entire Assertion.=C2=A0= An invalid
=C2=A0 =C2=A0 =C2=A0 =C2=A0 NotOnOrAfter instant on a <SubjectConfirmati= onData> element only
=C2=A0 =C2=A0 =C2=A0 =C2=A0 invalidates the individual <SubjectConfirmat= ion>.
NEW
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The authorization server MUST reject the = entire Assertion if
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the NotOnOrAfter instant on the <Condi= tions> element has passed
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(subject to allowable clock skew between = systems). The
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0authorization server MUST reject the <= SubjectConfirmation> (but
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MAY still use the rest of the Assertion) = if the NotOnOrAfter
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0instant on the <SubjectConfirmationDat= a> has passed (subject to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0allowable clock skew).


OK

=C2=A0

Subpoint 7: Are you sure those SHOULDs and SHOULD NOTs are not
conflicting? Can you not have an authenticated subject with an
autonomously acting client?


Perhaps= I've misused the words but, yes, that's the idea. An autonomously = acting client is meant to describe a client that's acting without the u= ser being present. The act of direct user authentication with the assertion= issuer seems like the way to differentiate between the user being present = for things and the client doing things "in the background" for th= e user. Both are valid use cases. Item 7 is looking to provide the AS with = some clue as to which is happening.

I'm open to sugge= stions to clarify the text but I do believe there's no conflict.
=C2=A0

Subpoint 9: As I asked in the -assertions document, is this really a
requirement?

Short answer, yes it is. L= onger answer, see the answer in that thread.
=C2=A0

Subpoint 11: Again, it would be better to put the MUST on the action
(e.g., "MUST reject") to make it clear who is doing what.

OK
=C2=A0

3.1/3.2 - s/MUST construct/constructs

O= K
=C2=A0

4 - s/Though non-normative//

OK
=C2=A0

9 - Seems like OASIS.saml-deleg-cs and OASIS.saml-sec-consider-2.0-os are Normative, not Informative.


OK. I wasn't sure but will change = them to Normative unless someone yells otherwise about it.
--001a11c3b252119baa050589caea-- From nobody Thu Oct 16 06:00:16 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8975F1A1B37 for ; Thu, 16 Oct 2014 06:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gfFB4zmX4Q9O for ; Thu, 16 Oct 2014 06:00:08 -0700 (PDT) Received: from na3sys009aog130.obsmtp.com (na3sys009aog130.obsmtp.com [74.125.149.143]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9E801A1B3C for ; Thu, 16 Oct 2014 06:00:06 -0700 (PDT) Received: from mail-ig0-f182.google.com ([209.85.213.182]) (using TLSv1) by na3sys009aob130.postini.com ([74.125.148.12]) with SMTP ID DSNKVD/BVgWDKs3SkkKTVpH+4eHDDUqzSZbQ@postini.com; Thu, 16 Oct 2014 06:00:06 PDT Received: by mail-ig0-f182.google.com with SMTP id hn15so3351300igb.9 for ; Thu, 16 Oct 2014 06:00:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=/eLiMkLoNcQDV/NfPoWgnKL+4CmDUe7jaaSlSTOzDMI=; b=aqyetZoAJqRxAbAoHBIQH7996hkYiWDFw5s7lAHpPK6xqFoWhxKclqAzfZ80uEMwZs Io/AM7ax7i+amlwdPxHxeCLVW/28lJ+3VqPS0cxXjQXXdEQz5psuECVPmKeG360hekcO HDYG9LdHaunHNxJalnMJkaiu1PTQUDfnEvKv76ihDZ0na0dzKpIRnQyxjYu5QrOHehHd /SjJpHs5FXVjroPtn5Rqz64nHVj3siBHFM6Dp46UFS/YDIL0rDICBs5U7O5TRGhuDPpC RolJA52CIUm3950POKBybBKPtLV2QLxoMXRGfL372BzV7wOsYQcM1oJmT/G+iuB88ubO WuQw== X-Gm-Message-State: ALoCoQkA3kt37EVHTFm2fvNHWIVys8koPxSZKG8BM6xcKAN+TLHPogYvHT/GMhXsPToGvIReCvM+VSS249u2y0YlMScpy+C1AXX9pPFjTg5vaX+AqQ9Z8ECUMZ1lnppcG/Esw9pFHkS1 X-Received: by 10.50.117.73 with SMTP id kc9mr21632460igb.43.1413464406078; Thu, 16 Oct 2014 06:00:06 -0700 (PDT) X-Received: by 10.50.117.73 with SMTP id kc9mr21632442igb.43.1413464405950; Thu, 16 Oct 2014 06:00:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.12.137 with HTTP; Thu, 16 Oct 2014 05:59:35 -0700 (PDT) In-Reply-To: <20141015020509.5671.13432.idtracker@ietfa.amsl.com> References: <20141015020509.5671.13432.idtracker@ietfa.amsl.com> From: Brian Campbell Date: Thu, 16 Oct 2014 06:59:35 -0600 Message-ID: To: Pete Resnick Content-Type: multipart/alternative; boundary=089e0139fb6ed20303050589d303 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/YJGKkj58JY4gDkDDY6Dsblewf-4 Cc: "oauth-chairs@tools.ietf.org" , oauth , The IESG , draft-ietf-oauth-jwt-bearer@tools.ietf.org Subject: Re: [OAUTH-WG] Pete Resnick's No Objection on draft-ietf-oauth-jwt-bearer-10: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 13:00:10 -0000 --089e0139fb6ed20303050589d303 Content-Type: text/plain; charset=UTF-8 Likewise, I will not repeat stuff here but will apply appropriate changes from your comments on draft-ietf-oauth-saml2-bearer as they apply here to draft-ietf-oauth-jwt-bearer. On Tue, Oct 14, 2014 at 8:05 PM, Pete Resnick wrote: > Pete Resnick has entered the following ballot position for > draft-ietf-oauth-jwt-bearer-10: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I'm not going to repeat stuff that is identical to > draft-ietf-oauth-saml2-bearer (and I did find that using > < > https://www.ietf.org/rfcdiff?url1=draft-ietf-oauth-saml2-bearer-21&difftype=--html&submit=Go%21&url2=draft-ietf-oauth-jwt-bearer-10 > > > was very helpful). Please refer to my comments on that document. > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --089e0139fb6ed20303050589d303 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Likewise, I will not repeat stuff here but will apply appr= opriate changes from your comments on draft-ietf-oauth-saml2-bearer as they= apply here to draft-ietf-oauth-jwt-bearer.

On Tue, Oct 14, 2014 at 8:05 PM, Pete = Resnick <presnick@qti.qualcomm.com> wrote:
Pete Resnick has entered the following ballot posi= tion for
draft-ietf-oauth-jwt-bearer-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-crit= eria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer= /



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I'm not going to repeat stuff that is identical to
draft-ietf-oauth-saml2-bearer (and I did find that using
<https://www.ietf.org/rfcdiff?url1=3Ddra= ft-ietf-oauth-saml2-bearer-21&difftype=3D--html&submit=3DGo%21&= url2=3Ddraft-ietf-oauth-jwt-bearer-10>
was very helpful). Please refer to my comments on that document.


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

--089e0139fb6ed20303050589d303-- From nobody Thu Oct 16 06:08:01 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05B181A1B4D; Thu, 16 Oct 2014 06:08:00 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YFqBZAuwIZYZ; Thu, 16 Oct 2014 06:07:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CD7061A1A38; Thu, 16 Oct 2014 06:07:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ted Lemon" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141016130758.20410.20976.idtracker@ietfa.amsl.com> Date: Thu, 16 Oct 2014 06:07:58 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/xuMh6TUccFgtBxFElUpQEDWzY5g Cc: draft-ietf-oauth-assertions@tools.ietf.org, oauth-chairs@tools.ietf.org, oauth@ietf.org Subject: [OAUTH-WG] Ted Lemon's Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 13:08:00 -0000 Ted Lemon has entered the following ballot position for draft-ietf-oauth-assertions-17: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This has probably already been considered and addressed by the working group, but coming into this as a neophyte it seems like a glaring omission that the security considerations of bearer assertions are not discussed here. Isn't it the case that the use of bearer assertions requires a trust relationship between the client and relying party such that the client can be assured that the relying party will not misuse the assertion to authenticate with some other entity? I realize that this sort of assertion will likely only be used in cases where the assertion only works to authenticate to a specific relying party, but I think this bears mentioning in the security considerations. From nobody Thu Oct 16 06:11:35 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDAEE1A1B8D for ; Thu, 16 Oct 2014 06:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9eOX1sUCjFaM for ; Thu, 16 Oct 2014 06:11:28 -0700 (PDT) Received: from na3sys009aog104.obsmtp.com (na3sys009aog104.obsmtp.com [74.125.149.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30DD11A1B8A for ; Thu, 16 Oct 2014 06:11:27 -0700 (PDT) Received: from mail-ig0-f177.google.com ([209.85.213.177]) (using TLSv1) by na3sys009aob104.postini.com ([74.125.148.12]) with SMTP ID DSNKVD/D/qHCvuF0YTCpbHBAGUZAv/in9fsF@postini.com; Thu, 16 Oct 2014 06:11:27 PDT Received: by mail-ig0-f177.google.com with SMTP id a13so3392776igq.4 for ; Thu, 16 Oct 2014 06:11:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=rczIARToTol6GiBwtlJBPYeEAneFlrbotScPJIsf09k=; b=CQE3LHr3R3mFiUJfmr8oYrLX8LDDtaEUu/IKm2G5G0+oY3VbmhewbBSClcN0hZCv7M SZjTxE29tJ5l29sgabBE12WL5FMFhrldGE3HUvumGjniIleh2skvTAgpjewvhrna5vOY mmP9r3Kztl46Bs0e/yqC+SIahr5e17AtfqgUB3Hw5HhOUyakMGF6eTlOR9lptqHH1FZd vc1Czqn0TlQsP8MKcDCiNMGdH2RiwcXM390aTW52w2i0NMetADWWDHlUK5ceiAMmsYdU 3dd+pcBheJzeqTsZUOB2sHx79Y+Rmeh2Lb7yn18QaE0HrdO8SeNi6lrQBzjKPSJwAaFz 2QjQ== X-Gm-Message-State: ALoCoQmjca8GgxTID3qM4hC+JR7F1IcrkD0yzxvGjftxNUSIH6l0yoKNKK5niIgpANkax93ah1RQJdODl9iIP+WfIXT9V4+NkTIxS8ZQEFBGF2LQ5Zmptj6/ca5iEpmj/0+7ge4/JYdN X-Received: by 10.50.66.179 with SMTP id g19mr22031362igt.40.1413465086551; Thu, 16 Oct 2014 06:11:26 -0700 (PDT) X-Received: by 10.50.66.179 with SMTP id g19mr22031334igt.40.1413465086381; Thu, 16 Oct 2014 06:11:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.12.137 with HTTP; Thu, 16 Oct 2014 06:10:56 -0700 (PDT) In-Reply-To: <20141016112244.8382.80012.idtracker@ietfa.amsl.com> References: <20141016112244.8382.80012.idtracker@ietfa.amsl.com> From: Brian Campbell Date: Thu, 16 Oct 2014 07:10:56 -0600 Message-ID: To: Stephen Farrell Content-Type: multipart/alternative; boundary=047d7bdc15b2606b19050589fc0e Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/WU6aDLJ07vGQq439OyrqipB3R88 Cc: "oauth-chairs@tools.ietf.org" , oauth , The IESG , draft-ietf-oauth-jwt-bearer@tools.ietf.org Subject: Re: [OAUTH-WG] Stephen Farrell's No Objection on draft-ietf-oauth-jwt-bearer-10: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 13:11:31 -0000 --047d7bdc15b2606b19050589fc0e Content-Type: text/plain; charset=UTF-8 A JWT, by it's very definition, is a set of base64url pieces concatenated together with dot "." characters (which is also URL safe). So no additional encoding or serialization of the JWT is needed. On Thu, Oct 16, 2014 at 5:22 AM, Stephen Farrell wrote: > Stephen Farrell has entered the following ballot position for > draft-ietf-oauth-jwt-bearer-10: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > - 2.1, assertion parameter: How come this one does not talk > about base64url whereas the saml one does? > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --047d7bdc15b2606b19050589fc0e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
A JWT, by it's very definition, is a set of base64url = pieces concatenated together with dot "." characters (which is al= so URL safe). So no additional encoding or serialization of the JWT is need= ed.

On Thu, O= ct 16, 2014 at 5:22 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie= > wrote:
Stephen Farrell ha= s entered the following ballot position for
draft-ietf-oauth-jwt-bearer-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-crit= eria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer= /



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


- 2.1, assertion parameter: How come this one does not talk
about base64url whereas the saml one does?


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

--047d7bdc15b2606b19050589fc0e-- From nobody Thu Oct 16 06:49:29 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 502E81A0545; Thu, 16 Oct 2014 06:49:23 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YtLOXn8fenM4; Thu, 16 Oct 2014 06:49:21 -0700 (PDT) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE93C1A03AB; Thu, 16 Oct 2014 06:49:20 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id o8so2813380qcw.3 for ; Thu, 16 Oct 2014 06:49:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=18vbsX1Bee0VrmmsgwHI33MPewaM0csqOrCD1ab19Q4=; b=yFWE9h21BRe2Z3CtUz4/fjdmjRoeznrTqQNS4qiZu/RUR09CuxerB3wmYvzEmjstUf 9HPra3a7CmKTtn+vfkKKJcDvBz3LsLAIPUErL3YzwC+QI529JeLA3BY40FK7actcXvLS mT6FJBeWipd1fCtGWy5KCxtD8g0pC4enJ3tpWitMQYNOCGfJR2uSZTus4wXj1zOQE8Ll Zv039JQAUs0wj1RRKRUej83fnR2e5Ws5ThXQJ78GvLIualCBZsNcieJLse+duHT3pAio G6r1uhiMMLpAvg455/4oM7RL3XnJ0ECnppvtiLuEoHHSN1m49JkBjHsrgmZyUmDAinvp Lr9w== X-Received: by 10.229.173.193 with SMTP id q1mr2404270qcz.10.1413467360159; Thu, 16 Oct 2014 06:49:20 -0700 (PDT) Received: from [10.226.30.159] (mobile-107-107-63-39.mycingular.net. [107.107.63.39]) by mx.google.com with ESMTPSA id w8sm21468495qag.2.2014.10.16.06.49.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 16 Oct 2014 06:49:18 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: <20141016123342.13816.96049.idtracker@ietfa.amsl.com> Date: Thu, 16 Oct 2014 09:49:18 -0400 Content-Transfer-Encoding: 7bit Message-Id: <8141B7DB-364F-41C2-8FFD-63110CCD98C3@gmail.com> References: <20141016123342.13816.96049.idtracker@ietfa.amsl.com> To: Benoit Claise Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Mdo2oNN7EFm2YBObEB7PaRRPoJ8 Cc: "oauth-chairs@tools.ietf.org" , "draft-ietf-oauth-saml2-bearer@tools.ietf.org" , The IESG , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Benoit Claise's No Objection on draft-ietf-oauth-saml2-bearer-21: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 13:49:23 -0000 Thanks, Benoit. I'll double check this before the draft progresses. Thanks, Kathleen Sent from my iPhone > On Oct 16, 2014, at 8:33 AM, "Benoit Claise" wrote: > > Benoit Claise has entered the following ballot position for > draft-ietf-oauth-saml2-bearer-21: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I cleared my DISCUSS on the basis that RFC 6755 will be moved to an > informative reference in response to this process issue: IDnits complains > of a normative reference to Informational document RFC 6755, which was > not noted in the Last Call announcement. > > > Editorial Nits: > > S2.2: The paragraph before the actual example uses terminology > inconsistent with RFC 6749: > > s/authorization code grant/authorization grant/ > > From nobody Thu Oct 16 07:41:01 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A55E1A1A75; Thu, 16 Oct 2014 07:41:00 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s0FfKKvMFhAL; Thu, 16 Oct 2014 07:40:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AEE441A1B61; Thu, 16 Oct 2014 07:40:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ted Lemon" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141016144058.2977.30317.idtracker@ietfa.amsl.com> Date: Thu, 16 Oct 2014 07:40:58 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/929Tf1qYbZUZV9Np0TOvb6aHzjw Cc: draft-ietf-oauth-assertions@tools.ietf.org, oauth-chairs@tools.ietf.org, oauth@ietf.org Subject: [OAUTH-WG] Ted Lemon's No Objection on draft-ietf-oauth-assertions-17: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 14:41:00 -0000 Ted Lemon has entered the following ballot position for draft-ietf-oauth-assertions-17: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Brian Campbell has explained what's going on sufficiently that I think my DISCUSS no longer applies. Thanks, Brian! From nobody Thu Oct 16 08:00:39 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF4D11A1BC7 for ; Thu, 16 Oct 2014 08:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43RyZYPPGkIh for ; Thu, 16 Oct 2014 08:00:33 -0700 (PDT) Received: from na3sys009aog117.obsmtp.com (na3sys009aog117.obsmtp.com [74.125.149.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF0C11A1A75 for ; Thu, 16 Oct 2014 08:00:32 -0700 (PDT) Received: from mail-ie0-f175.google.com ([209.85.223.175]) (using TLSv1) by na3sys009aob117.postini.com ([74.125.148.12]) with SMTP ID DSNKVD/djlU1Rz6i/sCe+XfYC7UKbIZIpwQ2@postini.com; Thu, 16 Oct 2014 08:00:32 PDT Received: by mail-ie0-f175.google.com with SMTP id x19so3506245ier.6 for ; Thu, 16 Oct 2014 08:00:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=aJZnZkhva8qw7/Vm1W06YcVQ/O9teBJTP6CPCxKp07o=; b=lxyVvzo/erreLMFXVboeM/HLmPVUKTUGj30vgFkNpdv6rQWJvS4IE4n9YA4M1upKPu ASMSUacWYfsAeG2ynajpqlgjTFDa8sEzJm/s6L/otYhrKQX0eyY2LfRZM2VxhacK4CSj J6jc/aZVb8pH3wo4xMbTzMJJGJN5Qc2/EO/m2UxJ3HXtxaNC6KjDJ7JQ6NmQQhbFJsqN FbGUpmaGZYCARZMSVPhKS1g/1knsT9EDx61lnVv5Mxn+z4+AC6MNX01GJWI5FF03wscc qK7zfXFzpRVtJ8WoCrEmE8Qa0YMc/uYPqvzcsM2x6tsUz18r8i5YzF9AejLp8Ed9viAY 8S5A== X-Gm-Message-State: ALoCoQkrMEuPv0IirHmpPyUvH3fDmgOqaw3yKRwJf+EET58in4hBun9DmhuEOAt5biNTVC8BDsZMvbkSgBlt6/ZnJVtF+6SjRVDVL2ccXYjClQCtsce9/EDZMVJC+cbZtqETp+FY+mzn X-Received: by 10.50.66.179 with SMTP id g19mr22760424igt.40.1413471629947; Thu, 16 Oct 2014 08:00:29 -0700 (PDT) X-Received: by 10.50.66.179 with SMTP id g19mr22760402igt.40.1413471629727; Thu, 16 Oct 2014 08:00:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.12.137 with HTTP; Thu, 16 Oct 2014 07:59:59 -0700 (PDT) In-Reply-To: References: <20141016130758.20410.20976.idtracker@ietfa.amsl.com> <21BD317F-7AEC-46BF-A31A-7002653F9430@nominum.com> From: Brian Campbell Date: Thu, 16 Oct 2014 08:59:59 -0600 Message-ID: To: The IESG , "draft-ietf-oauth-assertions@tools.ietf.org" , "oauth-chairs@tools.ietf.org" , oauth Content-Type: multipart/alternative; boundary=047d7bdc15b264131805058b8202 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/tv4-OI3BCUFpkeHnLkal2UH2h60 Subject: [OAUTH-WG] Fwd: Ted Lemon's Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 15:00:34 -0000 --047d7bdc15b264131805058b8202 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I realized that I'd accidentally replied only to Ted in this thread (email is hard!). So I wanted to send our discussion to the original cc list so it'd be more on the record and also because I believe this discussion is related to, and may help inform, some other comments that came in this morning. ---------- Forwarded message ---------- From: Brian Campbell Date: Thu, Oct 16, 2014 at 8:34 AM Subject: Re: [OAUTH-WG] Ted Lemon's Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS) To: Ted Lemon On Thu, Oct 16, 2014 at 7:42 AM, Ted Lemon wrote: > On Oct 16, 2014, at 8:37 AM, Brian Campbell > wrote: > > It's a good question Ted, thanks for your review. The concern is > mitigated by the requirement in =C2=A75.2 (third bullet > https://tools.ietf.org/html/draft-ietf-oauth-assertions-17#section-5.2) > which requires that these bearer assertions be audience restricted. > Assertions with audience restrictions can only be used at the specific > relying party(s) to whom they were addressed. > > > > So I think the concern is addressed in processing rules of the draft. > But do you think it should also be mentioned in the security consideratio= ns? > > Hm, interesting. I didn't connect that, because I assumed that while a > bearer assertion could be issued for a particular relying party, other > assertions might be issued for other relying parties using the same token= . > This could be either because of some policy on the client, or because th= e > end-user just types in the same token in several places, as is > unfortunately common practice with user passwords. > > So I guess I think a bit more discussion is warranted, but it may be that > my concern is based on a misunderstanding of how bearer assertions are > generated, in which case the discussion may not be necessary. So I gues= s > the question is, am I misunderstanding something here that makes this > concern not an issue? > > Typically an assertion will be issued for use at a specific relying party in a specific context (like one of these profiles or for web single sign-on) . And it will be time limited to something on the order of minutes or maybe hours but not longer. The assertion is the token. It carries information about the user and how they authenticated (how is not dictated here but the assertion can describe it to the relying party) with the assertion issuer. But it's not something that the user would ever type in or even see or be aware of in most cases. The audience restriction let's the issuer say specifically what relying party is allowed to consume the assertion, which ensures that the client can't use it somewhere that it wasn't intended and that the relying party that receives the assertion can't turn around and use it to access some other service. Is this helping your understanding or just confusing matters? --047d7bdc15b264131805058b8202 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I realized that I'd accidentally re= plied only to Ted in this thread (email is hard!). So I wanted to send our = discussion to the original cc list so it'd be more on the record and al= so because I believe this discussion is related to, and may help inform, so= me other comments that came in this morning.

---------- Forwarded message ----------
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Thu, Oct 16, 2014 at 8:34 AM
Subject: Re: [OAUTH-W= G] Ted Lemon's Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS= )
To: Ted Lemon <Ted.Lemon@nominum.com>


=
On Thu, Oct 16, 2= 014 at 7:42 AM, Ted Lemon <Ted.Lemon@nominum.com> wrote:=
On Oct 16, 2014= , at 8:37 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:
> It's a good question Ted, thanks for your review. The= concern is mitigated by the requirement in =C2=A75.2 (third bullet https://tools.ietf.org/html/draft-ietf-oauth-assertions-= 17#section-5.2) which requires that these bearer assertions be audience= restricted. Assertions with audience restrictions can only be used at the = specific relying party(s) to whom they were addressed.
>
> So I think the concern is addressed in processing rules of the draft. = But do you think it should also be mentioned in the security considerations= ?

Hm, interesting.=C2=A0 =C2=A0I didn't connect that, because I as= sumed that while a bearer assertion could be issued for a particular relyin= g party, other assertions might be issued for other relying parties using t= he same token.=C2=A0 =C2=A0This could be either because of some policy on t= he client, or because the end-user just types in the same token in several = places, as is unfortunately common practice with user passwords.

So I guess I think a bit more discussion is warranted, but it may be that m= y concern is based on a misunderstanding of how bearer assertions are gener= ated, in which case the discussion may not be necessary.=C2=A0 =C2=A0So I g= uess the question is, am I misunderstanding something here that makes this = concern not an issue?


Typical= ly an assertion will be issued for use at a specific relying party in a spe= cific context (like one of these profiles or for web single sign-on) . And = it will be time limited to something on the order of minutes or maybe hours= but not longer. The assertion is the token. It carries information about t= he user and how they authenticated (how is not dictated here but the assert= ion can describe it to the relying party) with the assertion issuer. But it= 's not something that the user would ever type in or even see or be awa= re of in most cases. The audience restriction let's the issuer sa= y specifically what relying party is allowed to consume the assertion, whic= h ensures that the client can't use it somewhere that it wasn't int= ended and that the relying party that receives the assertion can't turn= around and use it to access some other service.

Is this helping your understanding or just confu= sing matters?



--047d7bdc15b264131805058b8202-- From nobody Thu Oct 16 08:30:32 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B1A81A1BD6; Thu, 16 Oct 2014 08:30:26 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9KOOoT7pJ6Vj; Thu, 16 Oct 2014 08:30:24 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0749.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::749]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E70091A1BD1; Thu, 16 Oct 2014 08:30:23 -0700 (PDT) Received: from CO2PR03CA0043.namprd03.prod.outlook.com (10.141.194.170) by DM2PR03MB399.namprd03.prod.outlook.com (10.141.84.148) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Thu, 16 Oct 2014 15:30:01 +0000 Received: from BN1AFFO11FD005.protection.gbl (2a01:111:f400:7c10::153) by CO2PR03CA0043.outlook.office365.com (2a01:111:e400:1414::42) with Microsoft SMTP Server (TLS) id 15.0.1054.13 via Frontend Transport; Thu, 16 Oct 2014 15:30:00 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD005.mail.protection.outlook.com (10.58.52.65) with Microsoft SMTP Server (TLS) id 15.0.1039.16 via Frontend Transport; Thu, 16 Oct 2014 15:29:59 +0000 Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.93]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.03.0210.003; Thu, 16 Oct 2014 15:29:45 +0000 From: Mike Jones To: Richard Barnes , The IESG Thread-Topic: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT) Thread-Index: AQHP6PPyEQ0Qm5p8FUevm57Q8TXNpZwy2Jrw Date: Thu, 16 Oct 2014 15:29:44 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439BB13261@TK5EX14MBXC286.redmond.corp.microsoft.com> References: <20141016034735.18695.61014.idtracker@ietfa.amsl.com> In-Reply-To: <20141016034735.18695.61014.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(189002)(199003)(13464003)(377454003)(51704005)(52044002)(76482002)(80022003)(46102003)(97736003)(230783001)(85806002)(77096002)(2656002)(26826002)(92726001)(86362001)(85306004)(23726002)(86612001)(21056001)(33656002)(66066001)(15202345003)(46406003)(87936001)(4396001)(85852003)(81156004)(106466001)(107046002)(106116001)(95666004)(15975445006)(68736004)(69596002)(84676001)(97756001)(120916001)(92566001)(50466002)(76176999)(54356999)(55846006)(19580395003)(47776003)(20776003)(99396003)(31966008)(64706001)(50986999)(104016003)(44976005)(6806004)(19580405001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR03MB399; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR03MB399; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 036614DD9C Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/kQsUDEe1xURo-fbs9zzpiGWmQos Cc: "draft-ietf-oauth-assertions@tools.ietf.org" , "oauth-chairs@tools.ietf.org" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 15:30:26 -0000 Thanks for your review, Richard. I'm replying to your DISCUSS about the au= dience being required below... -- Mike > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Richard Barnes > Sent: Wednesday, October 15, 2014 8:48 PM > To: The IESG > Cc: draft-ietf-oauth-assertions@tools.ietf.org; oauth-chairs@tools.ietf.o= rg; > oauth@ietf.org > Subject: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertion= s-17: > (with DISCUSS and COMMENT) >=20 > Richard Barnes has entered the following ballot position for > draft-ietf-oauth-assertions-17: Discuss >=20 > When responding, please keep the subject line intact and reply to all ema= il > addresses included in the To and CC lines. (Feel free to cut this introdu= ctory > paragraph, however.) >=20 >=20 > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > "The assertion MUST contain an Audience that identifies the Authorization > Server as the intended audience. Assertions that do not identify the > Authorization Server as an intended audience MUST be rejected." >=20 > Could you please identify the threat model within which this "MUST" is re= quired? > This requirement doesn't follow from any of the threats elaborated in Sec= tion 8. Sure, this is to prevent a legitimate assertion intended for one authorizat= ion server being captured by the attacker and sent to a different authoriza= tion server. Unless there's an audience for the authorization server to ch= eck, there's no way for the authorization server to reject assertions inten= ded to be used by a different server. Using the audience is the normal way= to prevent this attack. > The Audience is only necessary if the Issuer wishes to constrain the set = of > Authorization Servers with which an assertion may be used. So ISTM that = this > should be "MAY contain..." Constraining the set to the intended server is basic to the security guaran= tees. If I can take a server intended for server1 and get server2 to accep= t it, all security bets are off. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > "keyed message digest" -> "Message Authentication Code" >=20 > That's the proper terminology [RFC4949], especially since there are MACs = that > are not based on digests. >=20 > "This mechanism provides additional security properties." -- Please delet= e this or > elaborate on what security properties it provides. >=20 > Section 8.2 should note that "Holder-of-Key Assertions" are also a mitiga= tion for > this risk. >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Thu Oct 16 08:39:40 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4007B1A6EF8 for ; Thu, 16 Oct 2014 08:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHEWRoJoHnpj for ; Thu, 16 Oct 2014 08:39:30 -0700 (PDT) Received: from mail-vc0-f173.google.com (mail-vc0-f173.google.com [209.85.220.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24A861A6EE0 for ; Thu, 16 Oct 2014 08:39:30 -0700 (PDT) Received: by mail-vc0-f173.google.com with SMTP id ij19so2870610vcb.32 for ; Thu, 16 Oct 2014 08:39:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=FZXOPRG9YAdvFtEcmXotsI/SOsicCiS67pItvzcUd2A=; b=TjBY4D8t5Ggj2Gkn7Q5B/jr0d81cGdLdCeZkMxoDe7UJ0+uLzHN+C/nBj9WIc/sDms QMn5N6ftp3tn6UmNYrf1DSEppdp0+9Lqr0hbR93hypPjoLREfPfuDiIFJoE7KQJGVpCX aYES1ALKTQ0sN0Dq7JXNfj8rSawqtTRXE6dupN6o1mgx6oEDuVzjDl3D4g7ZXVBE026c aGtfxuwSYceGeCVYur+SHSXaXDrsBsvRXf+LjkbDwlYYSm2Y5GgRX6DK3Bntj+2WNFQk nKRWav/Xi+T+4kyZ2Y/Hv9Oq+Uy4JfklEm2Hxu+FeGbQ9yLGRjLD1i0whaf0akP9xHF8 sRqg== X-Gm-Message-State: ALoCoQmY0fDopYHn9B+jLFc/mEKgTULnqGMDzUgFZLPdcoIRT42mwcSWaR5gKlWNiAuExPVcsHix MIME-Version: 1.0 X-Received: by 10.52.36.113 with SMTP id p17mr1361050vdj.81.1413473969278; Thu, 16 Oct 2014 08:39:29 -0700 (PDT) Received: by 10.31.149.205 with HTTP; Thu, 16 Oct 2014 08:39:29 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439BB13261@TK5EX14MBXC286.redmond.corp.microsoft.com> References: <20141016034735.18695.61014.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739439BB13261@TK5EX14MBXC286.redmond.corp.microsoft.com> Date: Thu, 16 Oct 2014 08:39:29 -0700 Message-ID: From: Richard Barnes To: Mike Jones Content-Type: multipart/alternative; boundary=20cf307c9b60d6a58305058c0dfa Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/uqQd6F_VhK-Wgb0dTfecNRuRZww Cc: "draft-ietf-oauth-assertions@tools.ietf.org" , "oauth-chairs@tools.ietf.org" , The IESG , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 15:39:33 -0000 --20cf307c9b60d6a58305058c0dfa Content-Type: text/plain; charset=UTF-8 On Thu, Oct 16, 2014 at 8:29 AM, Mike Jones wrote: > Thanks for your review, Richard. I'm replying to your DISCUSS about the > audience being required below... > > -- Mike > > > -----Original Message----- > > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Richard Barnes > > Sent: Wednesday, October 15, 2014 8:48 PM > > To: The IESG > > Cc: draft-ietf-oauth-assertions@tools.ietf.org; > oauth-chairs@tools.ietf.org; > > oauth@ietf.org > > Subject: [OAUTH-WG] Richard Barnes' Discuss on > draft-ietf-oauth-assertions-17: > > (with DISCUSS and COMMENT) > > > > Richard Barnes has entered the following ballot position for > > draft-ietf-oauth-assertions-17: Discuss > > > > When responding, please keep the subject line intact and reply to all > email > > addresses included in the To and CC lines. (Feel free to cut this > introductory > > paragraph, however.) > > > > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > "The assertion MUST contain an Audience that identifies the Authorization > > Server as the intended audience. Assertions that do not identify the > > Authorization Server as an intended audience MUST be rejected." > > > > Could you please identify the threat model within which this "MUST" is > required? > > This requirement doesn't follow from any of the threats elaborated in > Section 8. > > Sure, this is to prevent a legitimate assertion intended for one > authorization server being captured by the attacker and sent to a different > authorization server. Unless there's an audience for the authorization > server to check, there's no way for the authorization server to reject > assertions intended to be used by a different server. Using the audience > is the normal way to prevent this attack. > That all assumes that the issuer of the assertion intends to limit it to a specific authorization server. That is not the case with many assertion systems today, e.g., PKIX. > > The Audience is only necessary if the Issuer wishes to constrain the set > of > > Authorization Servers with which an assertion may be used. So ISTM that > this > > should be "MAY contain..." > > Constraining the set to the intended server is basic to the security > guarantees. If I can take a server intended for server1 and get server2 to > accept it, all security bets are off. > That's dramatically overstating things. The only security bet that is off in that case is that the assertion is not limited to one authorization server. Which may or may not be the issuer's intent. The only thing I could see justifying this requirement is something in the overall OAuth architecture that requires authorizations to be scoped to a specific authorization server. If that exists, add a citation and I'll clear. Otherwise, this needs to be un-MUST-ed. --Richard > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > "keyed message digest" -> "Message Authentication Code" > > > > That's the proper terminology [RFC4949], especially since there are MACs > that > > are not based on digests. > > > > "This mechanism provides additional security properties." -- Please > delete this or > > elaborate on what security properties it provides. > > > > Section 8.2 should note that "Holder-of-Key Assertions" are also a > mitigation for > > this risk. > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > --20cf307c9b60d6a58305058c0dfa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Oct 16, 2014 at 8:29 AM, Mike Jones <Mi= chael.Jones@microsoft.com> wrote:
Thanks for you= r review, Richard.=C2=A0 I'm replying to your DISCUSS about the audienc= e being required below...

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =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 [mailto:oauth-bo= unces@ietf.org] On Behalf Of Richard Barnes
> Sent: Wednesday, October 15, 2014 8:48 PM
> To: The IESG
> Cc: draf= t-ietf-oauth-assertions@tools.ietf.org; oauth-chairs@tools.ietf.org;
> oauth@ietf.org
> Subject: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-as= sertions-17:
> (with DISCUSS and COMMENT)
>
> Richard Barnes has entered the following ballot position for
> draft-ietf-oauth-assertions-17: Discuss
>
> When responding, please keep the subject line intact and reply to all = email
> addresses included in the To and CC lines. (Feel free to cut this intr= oductory
> paragraph, however.)
>
>
> Please refer to http://www.ietf.org/iesg/statement/discuss= -criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-oauth-asser= tions/
>
>
>
> ----------------------------------------------------------------------=
> DISCUSS:
> ----------------------------------------------------------------------=
>
> "The assertion MUST contain an Audience that identifies the Autho= rization
> Server as the intended audience.=C2=A0 Assertions that do not identify= the
> Authorization Server as an intended audience MUST be rejected." >
> Could you please identify the threat model within which this "MUS= T" is required?
> This requirement doesn't follow from any of the threats elaborated= in Section 8.

Sure, this is to prevent a legitimate assertion intended for on= e authorization server being captured by the attacker and sent to a differe= nt authorization server.=C2=A0 Unless there's an audience for the autho= rization server to check, there's no way for the authorization server t= o reject assertions intended to be used by a different server.=C2=A0 Using = the audience is the normal way to prevent this attack.
=

That all assumes that the issuer of= the assertion intends to limit it to a specific authorization server.=C2= =A0 That is not the case with many assertion systems today, e.g., PKIX.
=

=C2=A0
> The Audience is only necessary if the Issuer wishes to constrain the s= et of
> Authorization Servers with which an assertion may be used.=C2=A0 So IS= TM that this
> should be "MAY contain..."

Constraining the set to the intended server is basic to the security= guarantees.=C2=A0 If I can take a server intended for server1 and get serv= er2 to accept it, all security bets are off.

That's dramatically overstating things.=C2=A0 The only security b= et that is off in that case is that the assertion is not limited to one aut= horization server.=C2=A0 Which may or may not be the issuer's intent.
The only thing I could see justifying this requirement is = something in the overall OAuth architecture that requires authorizations to= be scoped to a specific authorization server.=C2=A0 If that exists, add a = citation and I'll clear.=C2=A0 Otherwise, this needs to be un-MUST-ed.<= br>

--Richard


=C2=A0

> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
> "keyed message digest" -> "Message Authentication Co= de"
>
> That's the proper terminology [RFC4949], especially since there ar= e MACs that
> are not based on digests.
>
> "This mechanism provides additional security properties." --= Please delete this or
> elaborate on what security properties it provides.
>
> Section 8.2 should note that "Holder-of-Key Assertions" are = also a mitigation for
> this risk.
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--20cf307c9b60d6a58305058c0dfa-- From nobody Thu Oct 16 08:44:18 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D2631A6F0D for ; Thu, 16 Oct 2014 08:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8uB52HWnF66j for ; Thu, 16 Oct 2014 08:44:10 -0700 (PDT) Received: from na3sys009aog126.obsmtp.com (na3sys009aog126.obsmtp.com [74.125.149.155]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 148EE1A6EDE for ; Thu, 16 Oct 2014 08:44:10 -0700 (PDT) Received: from mail-ig0-f175.google.com ([209.85.213.175]) (using TLSv1) by na3sys009aob126.postini.com ([74.125.148.12]) with SMTP ID DSNKVD/nyK2S9FC2BD8QGDMUkvj1k1zlOXv8@postini.com; Thu, 16 Oct 2014 08:44:10 PDT Received: by mail-ig0-f175.google.com with SMTP id uq10so19701408igb.2 for ; Thu, 16 Oct 2014 08:44:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=dnWUcz7XG11Nq+6fI+fF4+9v4fww112Vxo6qpjnTItQ=; b=nIRq/7LU2BLB/h+5gQb163oYwRzMyML8VXR8to3bLPLamSlbhqT1ayhuqlorW7T2ev /1XmdUWRbPik+hitUaJm7twcZEgXIPIPsE6gG/i7lgzr3EoySeKBSgLLut+WwhV+qc9f 5XrYFypSe5aiEWP3sbA43WUN5KeDz0br+SzPIT6ZMfM0M3DFPHP5QDktDbiBYglA0Twv kCxm/s3kNkzNR+58IE1MKwoM5bk/sBOII6lbsxvceslhBrxTMJp/MhWJrUC4X5ObjOpI cX6/o0vpJiDWCCYU96Z59/hxEUXQA2qPtUMk+cXuNeZQltHNAMLH/+3smoyCdnJeQB0R P1xQ== X-Gm-Message-State: ALoCoQlkU5TiRZlFPaHG9QuO0It6JhIgKP+BqW9TYSMYHPaKWa5cxNlhK/SPgNlTi51/Ju8BA0BHA/I2Qn2DJ1+f1JZ4PGYEqWyUE5pxaXaSl/psSZHml6twf0MuBxjw16qWBDNW3Hni X-Received: by 10.50.66.179 with SMTP id g19mr23062694igt.40.1413474248626; Thu, 16 Oct 2014 08:44:08 -0700 (PDT) X-Received: by 10.50.66.179 with SMTP id g19mr23062676igt.40.1413474248472; Thu, 16 Oct 2014 08:44:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.12.137 with HTTP; Thu, 16 Oct 2014 08:43:38 -0700 (PDT) In-Reply-To: <20141016034735.18695.61014.idtracker@ietfa.amsl.com> References: <20141016034735.18695.61014.idtracker@ietfa.amsl.com> From: Brian Campbell Date: Thu, 16 Oct 2014 09:43:38 -0600 Message-ID: To: Richard Barnes Content-Type: multipart/alternative; boundary=047d7bdc15b27aefe305058c1e8f Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/xKZT7dkeu39KPiIsz2JskVIaOAY Cc: "draft-ietf-oauth-assertions@tools.ietf.org" , "oauth-chairs@tools.ietf.org" , The IESG , oauth Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 15:44:13 -0000 --047d7bdc15b27aefe305058c1e8f Content-Type: text/plain; charset=UTF-8 Thanks for your review and feedback, Richard. Replies are inline below... On Wed, Oct 15, 2014 at 9:47 PM, Richard Barnes wrote: > Richard Barnes has entered the following ballot position for > draft-ietf-oauth-assertions-17: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > "The assertion MUST contain an Audience that identifies the Authorization > Server as the intended audience. Assertions that do not identify the > Authorization Server as an intended audience MUST be rejected." > > Could you please identify the threat model within which this "MUST" is > required? This requirement doesn't follow from any of the threats > elaborated in Section 8. > > The Audience is only necessary if the Issuer wishes to constrain the set > of Authorization Servers with which an assertion may be used. So ISTM > that this should be "MAY contain..." > > The audience restriction let's the issuer say specifically what relying party is allowed to consume the assertion, which ensures that the client can't use it somewhere else that it wasn't intended and that the relying party that receives the assertion can't turn around and use it to access some other service. Strictly speaking, you are right that the audience is only necessary if the Issuer wishes to constrain the set of Authorization Servers with which an assertion may be used. But the Issuer really really really should make that constraint and fully understanding the implications of not doing so is difficult and unlikely. There was a vulnerability in Google apps SAML a few years back that demonstrates how important audience restriction is and how it can be difficult for even very sophisticated providers to get it all right. I haven't had time to read it again to make sure but I think that this is the paper http://www.ai-lab.it/armando/pub/fmse9-armando.pdf I don't see what value allowing audience to be omitted brings other than that it is academically a possibility. But requiring it (hopefully, if the requirement is followed) helps reduce the possibility of a whole bunch of security problems that folks likely won't foresee. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > "keyed message digest" -> "Message Authentication Code" > > That's the proper terminology [RFC4949], especially since there are MACs > that are not based on digests. > OK > > "This mechanism provides additional security properties." -- Please > delete this or elaborate on what security properties it provides. > Will delete. > > Section 8.2 should note that "Holder-of-Key Assertions" are also a > mitigation for this risk. > > OK > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --047d7bdc15b27aefe305058c1e8f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for your review and feedback, Richard.= =20 Replies are inline below...

On Wed, Oct 15, 2014 at 9:47 PM, Richard Barnes <rlb@ipv.s= x> wrote:
http://www.ietf.org/iesg/statement/discuss-crit= eria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions= /



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

"The assertion MUST contain an Audience that identifies the Authorizat= ion
Server as the intended audience.=C2=A0 Assertions that do not identify the<= br> Authorization Server as an intended audience MUST be rejected."

Could you please identify the threat model within which this "MUST&quo= t; is
required?=C2=A0 This requirement doesn't follow from any of the threats=
elaborated in Section 8.

The Audience is only necessary if the Issuer wishes to constrain the set of Authorization Servers with which an assertion may be used.=C2=A0 So ISTM=
that this should be "MAY contain..."



The audience restriction let's= the issuer say specifically what=20 relying party is allowed to consume the assertion, which ensures that=20 the client can't use it somewhere else that it wasn't intended and = that the=20 relying party that receives the assertion can't turn around and use it= =20 to access some other service.

Strictly speaking,= you are right that the audience is only necessary if the Issuer wishes to = constrain the set of Authorization Servers with which an assertion may be u= sed. But the Issuer really really really should make that constraint and fu= lly understanding the implications of not doing so is difficult and unlikel= y.

There was a vulnerability in Google apps SAML a few y= ears back that demonstrates how important audience restriction is and= how it can be difficult for even very sophisticated providers to get it al= l right. I haven't had time to read it again to make sure but I think t= hat this is the paper http://www.ai-lab.it/armando/pub/fmse9-armando.pdf

I don't see what value allowing audience to be omi= tted brings other than that it is academically a possibility. But requiring= it (hopefully, if the requirement is followed) helps reduce the possibilit= y of a whole bunch of security problems that folks likely won't foresee= .

=C2=A0
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

"keyed message digest" -> "Message Authentication Code&qu= ot;

That's the proper terminology [RFC4949], especially since there are MAC= s
that are not based on digests.

OK
=C2=A0

"This mechanism provides additional security properties." -- Plea= se
delete this or elaborate on what security properties it provides.

Will delete.
=C2=A0

Section 8.2 should note that "Holder-of-Key Assertions" are also = a
mitigation for this risk.


OK
=C2=A0
=C2= =A0
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--047d7bdc15b27aefe305058c1e8f-- From nobody Thu Oct 16 09:10:29 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD201A1B98; Thu, 16 Oct 2014 09:10:17 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvaKBC_JV_R9; Thu, 16 Oct 2014 09:10:13 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0139.outbound.protection.outlook.com [207.46.100.139]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F2A21A1C00; Thu, 16 Oct 2014 09:10:13 -0700 (PDT) Received: from BN3PR0301CA0008.namprd03.prod.outlook.com (25.160.180.146) by BL2PR03MB388.namprd03.prod.outlook.com (10.141.91.153) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Thu, 16 Oct 2014 16:10:12 +0000 Received: from BL2FFO11FD041.protection.gbl (2a01:111:f400:7c09::121) by BN3PR0301CA0008.outlook.office365.com (2a01:111:e400:4000::18) with Microsoft SMTP Server (TLS) id 15.0.1054.13 via Frontend Transport; Thu, 16 Oct 2014 16:10:12 +0000 Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD041.mail.protection.outlook.com (10.173.161.137) with Microsoft SMTP Server (TLS) id 15.0.1039.16 via Frontend Transport; Thu, 16 Oct 2014 16:10:11 +0000 Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.93]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.03.0210.003; Thu, 16 Oct 2014 16:09:29 +0000 From: Mike Jones To: Benoit Claise , The IESG Thread-Topic: [OAUTH-WG] Benoit Claise's No Objection on draft-ietf-oauth-saml2-bearer-21: (with COMMENT) Thread-Index: AQHP6T1xv1eI3RlOlkekRDlalvyxOZwy47mA Date: Thu, 16 Oct 2014 16:09:28 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439BB134F4@TK5EX14MBXC286.redmond.corp.microsoft.com> References: <20141016123342.13816.96049.idtracker@ietfa.amsl.com> In-Reply-To: <20141016123342.13816.96049.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(199003)(51704005)(377454003)(52044002)(13464003)(189002)(21056001)(15975445006)(20776003)(47776003)(85306004)(92566001)(64706001)(69596002)(2656002)(92726001)(68736004)(86362001)(50466002)(46406003)(15202345003)(106466001)(77096002)(104016003)(107046002)(55846006)(95666004)(120916001)(66066001)(106116001)(81156004)(99396003)(26826002)(97736003)(50986999)(19580395003)(80022003)(46102003)(76176999)(76482002)(84676001)(85806002)(31966008)(87936001)(85852003)(23726002)(33656002)(19580405001)(6806004)(86612001)(230783001)(4396001)(97756001)(44976005)(54356999); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB388; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB388; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Exchange-Antispam-Report-Test: UriScan:; X-Forefront-PRVS: 036614DD9C Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Aek2UUugDlnlOQbRsOviUS1Fdjk Cc: "oauth-chairs@tools.ietf.org" , "draft-ietf-oauth-saml2-bearer@tools.ietf.org" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Benoit Claise's No Objection on draft-ietf-oauth-saml2-bearer-21: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 16:10:17 -0000 Thanks for your review, Benoit. Replies are inline below... > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Benoit Claise > Sent: Thursday, October 16, 2014 5:34 AM > To: The IESG > Cc: oauth-chairs@tools.ietf.org; draft-ietf-oauth-saml2-bearer@tools.ietf= .org; > oauth@ietf.org > Subject: [OAUTH-WG] Benoit Claise's No Objection on draft-ietf-oauth-saml= 2- > bearer-21: (with COMMENT) >=20 > Benoit Claise has entered the following ballot position for > draft-ietf-oauth-saml2-bearer-21: No Objection >=20 > When responding, please keep the subject line intact and reply to all ema= il > addresses included in the To and CC lines. (Feel free to cut this introdu= ctory > paragraph, however.) >=20 >=20 > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I cleared my DISCUSS on the basis that RFC 6755 will be moved to an infor= mative > reference in response to this process issue: IDnits complains of a normat= ive > reference to Informational document RFC 6755, which was not noted in the = Last > Call announcement. Yes, I agree with this becoming informational. For what it's worth, I just= made this change to the related JWT draft. > Editorial Nits: >=20 > S2.2: The paragraph before the actual example uses terminology inconsiste= nt > with RFC 6749: >=20 > s/authorization code grant/authorization grant/ Per my reply on October 6 to Tom Taylor's review which made the same commen= t, actually, RFC 6749 uses both terms. Authorization Grant is the generic = term. Authorization Code Grant (defined in Section 4.1 of 6749) is a speci= fic kind of authorization grant. The text is correct as-is. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Thu Oct 16 09:11:04 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB79A1A86E4 for ; Thu, 16 Oct 2014 09:11:02 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pyGytsrw48Xj for ; Thu, 16 Oct 2014 09:10:57 -0700 (PDT) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7827B1A3BA4 for ; Thu, 16 Oct 2014 09:10:53 -0700 (PDT) Received: by mail-qa0-f42.google.com with SMTP id j7so2612070qaq.15 for ; Thu, 16 Oct 2014 09:10:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=ZZ8xiT5CNiGqNY5q5HNLA7TUsqZbb1l6ba8GgpT/oLo=; b=hG2oKSG+34gSDT4FXfAIiTnn616pIJBNoKieDHSdrGHnA8SUJaQ7BLZor1hNhdQ2qG Jd8w59rBaMBMi0h1wdkgODmYJ9h59q7M9cdJPFDMU6Sac7i5IFJX9OsiDwAfOPSw95/q 25exgSvo+Ek6smNGAVauVxLgGy1vzPsqKyitb7CzRnbm2iz597Db510PbScY8+pILYGQ JeadlOLB6hvRp5k5LrqJkP9caLoaPObxp/CM+WzIoq/vYQ6HstzOKJnghUexiTpIYCYH mfMNoYJWSYyAtDO1sNEUVLHzzJ+ohVvQXh+KmXKAsNucJvQ799FU2eVluwIkTQxYxydL D9/A== X-Gm-Message-State: ALoCoQnmbBvUIS3MvfuGBY8x9bbibUAm5udsdQNFH6S+dbgVTI20wFMnP7cH7fCxka6B9fTtm3wt X-Received: by 10.140.38.176 with SMTP id t45mr3291306qgt.3.1413475852689; Thu, 16 Oct 2014 09:10:52 -0700 (PDT) Received: from [192.168.8.100] ([201.189.87.10]) by mx.google.com with ESMTPSA id 18sm8204640qgl.5.2014.10.16.09.10.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 16 Oct 2014 09:10:52 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_1395E981-AFA3-44A5-BBC8-FAF7C5B63DCB" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Bradley In-Reply-To: Date: Thu, 16 Oct 2014 13:10:51 -0300 Message-Id: <5BA73F24-B14A-4A7F-980A-B589A217712C@ve7jtb.com> References: <20141016034735.18695.61014.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739439BB13261@TK5EX14MBXC286.redmond.corp.microsoft.com> To: Richard Barnes X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/4QweYzG4Dq0Gk0nchfeXSdASBiI Cc: "draft-ietf-oauth-assertions@tools.ietf.org" , "oauth@ietf.org" , "oauth-chairs@tools.ietf.org" , The IESG Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 16:11:03 -0000 --Apple-Mail=_1395E981-AFA3-44A5-BBC8-FAF7C5B63DCB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Having an audience is an important part of keeping the assertions from = being reused inappropriately. I think the difference between this and PKIX is that a certificate = references a private key so is in a sense only usable by the holder of = that key. If we were talking about holder of key /Proof of Possession JWT and SAML = assertions then perhaps there is a corner case for not specifying an = audience. Using bearer assertions, I don't think the hypothetical flexibility gain = is worth the inevitable security issues caused by not having an issuer, = and people, not understanding the consequences of that. John B. On Oct 16, 2014, at 12:39 PM, Richard Barnes wrote: > On Thu, Oct 16, 2014 at 8:29 AM, Mike Jones = wrote: > Thanks for your review, Richard. I'm replying to your DISCUSS about = the audience being required below... >=20 > -- Mike >=20 > > -----Original Message----- > > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Richard = Barnes > > Sent: Wednesday, October 15, 2014 8:48 PM > > To: The IESG > > Cc: draft-ietf-oauth-assertions@tools.ietf.org; = oauth-chairs@tools.ietf.org; > > oauth@ietf.org > > Subject: [OAUTH-WG] Richard Barnes' Discuss on = draft-ietf-oauth-assertions-17: > > (with DISCUSS and COMMENT) > > > > Richard Barnes has entered the following ballot position for > > draft-ietf-oauth-assertions-17: Discuss > > > > When responding, please keep the subject line intact and reply to = all email > > addresses included in the To and CC lines. (Feel free to cut this = introductory > > paragraph, however.) > > > > > > Please refer to = http://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ > > > > > > > > = ---------------------------------------------------------------------- > > DISCUSS: > > = ---------------------------------------------------------------------- > > > > "The assertion MUST contain an Audience that identifies the = Authorization > > Server as the intended audience. Assertions that do not identify = the > > Authorization Server as an intended audience MUST be rejected." > > > > Could you please identify the threat model within which this "MUST" = is required? > > This requirement doesn't follow from any of the threats elaborated = in Section 8. >=20 > Sure, this is to prevent a legitimate assertion intended for one = authorization server being captured by the attacker and sent to a = different authorization server. Unless there's an audience for the = authorization server to check, there's no way for the authorization = server to reject assertions intended to be used by a different server. = Using the audience is the normal way to prevent this attack. >=20 > That all assumes that the issuer of the assertion intends to limit it = to a specific authorization server. That is not the case with many = assertion systems today, e.g., PKIX. >=20 > =20 > > The Audience is only necessary if the Issuer wishes to constrain the = set of > > Authorization Servers with which an assertion may be used. So ISTM = that this > > should be "MAY contain..." >=20 > Constraining the set to the intended server is basic to the security = guarantees. If I can take a server intended for server1 and get server2 = to accept it, all security bets are off. >=20 > That's dramatically overstating things. The only security bet that is = off in that case is that the assertion is not limited to one = authorization server. Which may or may not be the issuer's intent. >=20 > The only thing I could see justifying this requirement is something in = the overall OAuth architecture that requires authorizations to be scoped = to a specific authorization server. If that exists, add a citation and = I'll clear. Otherwise, this needs to be un-MUST-ed. >=20 > --Richard >=20 >=20 > =20 >=20 > > = ---------------------------------------------------------------------- > > COMMENT: > > = ---------------------------------------------------------------------- > > > > "keyed message digest" -> "Message Authentication Code" > > > > That's the proper terminology [RFC4949], especially since there are = MACs that > > are not based on digests. > > > > "This mechanism provides additional security properties." -- Please = delete this or > > elaborate on what security properties it provides. > > > > Section 8.2 should note that "Holder-of-Key Assertions" are also a = mitigation for > > this risk. > > > > > > _______________________________________________ > > 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=_1395E981-AFA3-44A5-BBC8-FAF7C5B63DCB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Having = an audience is an important part of keeping the assertions from being = reused inappropriately.

I think the difference = between this and PKIX is that a certificate references a private key so = is in a sense only usable by the holder of that = key.

If we were talking about holder of key = /Proof of Possession JWT and SAML assertions then perhaps there is a = corner case for not specifying an = audience.

Using bearer assertions, I don't = think the hypothetical flexibility gain is worth the inevitable security = issues caused by not having an issuer, and people, not understanding the = consequences of that.

John = B.

On Oct 16, 2014, at 12:39 PM, Richard Barnes = <rlb@ipv.sx> wrote:

On Thu, Oct 16, = 2014 at 8:29 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:
Thanks for your review, Richard.  I'm replying to your = DISCUSS about the audience being required below...

    =                     =         -- Mike

> -----Original Message-----
> From: OAuth = [mailto:oauth-bounces@ietf.org] On = Behalf Of Richard Barnes
> Sent: Wednesday, October 15, 2014 8:48 = PM
> To: The IESG
> Cc: draft-ietf-oaut= h-assertions@tools.ietf.org; oauth-chairs@tools.ietf.org;
> oauth@ietf.org
> Subject: = [OAUTH-WG] Richard Barnes' Discuss on = draft-ietf-oauth-assertions-17:
> (with DISCUSS and = COMMENT)
>
> Richard Barnes has entered the following ballot = position for
> draft-ietf-oauth-assertions-17: = Discuss
>
> When responding, please keep the subject line = intact and reply to all email
> addresses included in the To and = CC lines. (Feel free to cut this introductory
> paragraph, = however.)
>
>
> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html=
> for more information about IESG DISCUSS and COMMENT = positions.
>
>
> The document, along with other ballot = positions, can be found here:
> http://datatracker.ietf.org/doc/draft-ietf-oauth-asserti= ons/
>
>
>
> = ----------------------------------------------------------------------
= > DISCUSS:
> = ----------------------------------------------------------------------
= >
> "The assertion MUST contain an Audience that identifies the = Authorization
> Server as the intended audience.  Assertions = that do not identify the
> Authorization Server as an intended = audience MUST be rejected."
>
> Could you please identify = the threat model within which this "MUST" is required?
> This = requirement doesn't follow from any of the threats elaborated in Section = 8.

Sure, this is to prevent a legitimate assertion = intended for one authorization server being captured by the attacker and = sent to a different authorization server.  Unless there's an = audience for the authorization server to check, there's no way for the = authorization server to reject assertions intended to be used by a = different server.  Using the audience is the normal way to prevent = this attack.

That all assumes = that the issuer of the assertion intends to limit it to a specific = authorization server.  That is not the case with many assertion = systems today, e.g., PKIX.

 
> The = Audience is only necessary if the Issuer wishes to constrain the set = of
> Authorization Servers with which an assertion may be = used.  So ISTM that this
> should be "MAY = contain..."

Constraining the set to the intended server is = basic to the security guarantees.  If I can take a server intended = for server1 and get server2 to accept it, all security bets are = off.

That's dramatically overstating = things.  The only security bet that is off in that case is that the = assertion is not limited to one authorization server.  Which may or = may not be the issuer's intent.

The only thing I could = see justifying this requirement is something in the overall OAuth = architecture that requires authorizations to be scoped to a specific = authorization server.  If that exists, add a citation and I'll = clear.  Otherwise, this needs to be = un-MUST-ed.

--Richard


&= nbsp;

> = ----------------------------------------------------------------------
= > COMMENT:
> = ----------------------------------------------------------------------
= >
> "keyed message digest" -> "Message Authentication = Code"
>
> That's the proper terminology [RFC4949], = especially since there are MACs that
> are not based on = digests.
>
> "This mechanism provides additional security = properties." -- Please delete this or
> elaborate on what security = properties it provides.
>
> Section 8.2 should note that = "Holder-of-Key Assertions" are also a mitigation for
> this = risk.
>
>
> = _______________________________________________
> 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=_1395E981-AFA3-44A5-BBC8-FAF7C5B63DCB-- From nobody Thu Oct 16 09:55:02 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45E651A0111 for ; Thu, 16 Oct 2014 09:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.202 X-Spam-Level: ** X-Spam-Status: No, score=2.202 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, HTML_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FREEMAIL_DOC_PDF=0.01, T_HTML_ATTACH=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=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 p4qLuXMsRUgd for ; Thu, 16 Oct 2014 09:54:50 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA6D31A01A8 for ; Thu, 16 Oct 2014 09:54:46 -0700 (PDT) Received: from [192.168.10.193] ([80.92.119.18]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Lq9Ma-1Y9SEs26AS-00djtP for ; Thu, 16 Oct 2014 18:54:44 +0200 Message-ID: <543FF850.6070409@gmx.net> Date: Thu, 16 Oct 2014 18:54:40 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: "oauth@ietf.org" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Psg3BoFlgbsoAelCCDaT4d5kS6MiO8dim" X-Provags-ID: V03:K0:Wocvh8qmbRfyxd4NsW31NuTXRAcGUJJKP3o97AXwpBP5oqqRvyN gB/gvqvoXI4D9Jl4c4RYPv8GtYndW6uMvnxX3Jgpi7QOCDnOL8Dcbg5fvWpmX6I2Rh2HOKD vP5e+ttdgYryyOYj6WCPzfz1HrX78vfSDVa113OGRiqzW6I8kbyULq77ZXGkYvzXBPANuPj oYQWhLD7NLSkkO2TaH8Eg== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/ro_kbf34_DtGj7a6X9nj2aAs6nQ Subject: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference Call X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 16:54:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Psg3BoFlgbsoAelCCDaT4d5kS6MiO8dim Content-Type: multipart/mixed; boundary="------------080201090208040905040500" This is a multi-part message in MIME format. --------------080201090208040905040500 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Participants: * Brian Campbell * John Bradley * Derek Atkins * Phil Hunt * William Kim * Josh Mandel * Hannes Tschofenig Notes: Justin distributed a draft writeup and explained the reasoning behind it. The intended purpose is to put the write-up (after enough review) on oauth.net. See attachments. Justin solicited feedback from the conference call participants and from the working group. One discussion item was specifically related to the concept of audience restrictions, which comes in two flavours: (a) restriction of the access token regarding the resource server and (b) restriction of the id token regarding the client. Obviously, it is necessary to have both of these audience restrictions in place and to actually check them. The group then went into a discussion about the use of pseudonyms in authentication and the problems deployments ran into when they used pseudonyms together with a wide range of attributes that identified users nevertheless. Phil suggested to produce a write-up about this topic= =2E Finally, the group started a discussion about potential actions for the OAuth working groups. Two activities were mentioned, namely to produce an IETF draft of the write-up Justin has prepared as a "formal" response to the problems with authentication using OAuth and, as a second topic, potential re-chartering of the OAuth working group to work on some solutions in this area. Hannes suggested to postpone these discussions and to first finish the write-up Justin had distributed. Ciao Hannes & Derek --------------080201090208040905040500 Content-Type: application/msword; name="Authentication with OAuth 2.doc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Authentication with OAuth 2.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAUwAAAAAA AAAAEAAAVQAAAAEAAAD+////AAAAAFIAAAD///////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////spcEAKWALBAAA8BK/AAAAAAAAEAAAAAAABgAA SUUAAA4AYmpiaoARgBEAAAAAAAAAAAAAAAAAAAAAAAAJBBYALlQAAOJ7AADiewAAST0AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAD//w8A AAAAAAAAAAAAAAAAAAAAAKQAAAAAALAFAAAAAAAAsAUAALAFAAAAAAAAsAUAAAAAAACwBQAA AAAAALAFAAAAAAAAsAUAABQAAAAAAAAAAAAAAMQFAAAAAAAAzBAAAAAAAADMEAAAAAAAAMwQ AAAAAAAAzBAAACQAAADwEAAAFAAAAMQFAAAAAAAA/RgAAG4BAAAQEQAAcAAAAIARAAAAAAAA gBEAAAAAAACAEQAAAAAAAIARAAAAAAAAgBEAAAAAAACAEQAAAAAAAIARAAAAAAAAfBgAAAIA AAB+GAAAAAAAAH4YAAAAAAAAfhgAAAAAAAB+GAAAAAAAAH4YAAAAAAAAfhgAACQAAABrGgAA aAIAANMcAAB8AAAAohgAABUAAAAAAAAAAAAAAAAAAAAAAAAAsAUAAAAAAACAEQAAAAAAAAAA AAAAAAAAAAAAAAAAAACAEQAAAAAAAIARAAAAAAAAgBEAAAAAAACAEQAAAAAAAKIYAAAAAAAA AAAAAAAAAACwBQAAAAAAALAFAAAAAAAAgBEAAAAAAAAAAAAAAAAAAIARAAAAAAAAtxgAABYA AADUEgAAAAAAANQSAAAAAAAA1BIAAAAAAACAEQAA3AAAALAFAAAAAAAAgBEAAAAAAACwBQAA AAAAAIARAAAAAAAAfBgAAAAAAAAAAAAAAAAAANQSAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgBEAAAAAAAB8GAAAAAAAAAAAAAAAAAAA 1BIAAAAAAADUEgAAOgAAAAwYAAAsAAAAsAUAAAAAAACwBQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAATBgAAAAAAACAEQAA AAAAAAQRAAAMAAAAgAtIolvpzwEAAAAAAAAAAMwQAAAAAAAAXBIAAEwAAAA4GAAACgAAAAAA AAAAAAAAfBgAAAAAAADNGAAAMAAAAP0YAAAAAAAAQhgAAAoAAABPHQAAAAAAAKgSAAAiAAAA Tx0AABQAAABMGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABMGAAAFAAAAE8dAAAAAAAAAAAAAAAAAACwBQAA AAAAAGAYAAAcAAAAgBEAAAAAAACAEQAAAAAAANQSAAAAAAAAgBEAAAAAAACAEQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgBEAAAAAAACAEQAAAAAAAIARAAAAAAAA ohgAAAAAAACiGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAyhIAAAoA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIARAAAAAAAAgBEAAAAAAACAEQAA AAAAAP0YAAAAAAAAgBEAAAAAAACAEQAAAAAAAIARAAAAAAAAgBEAAAAAAAAAAAAAAAAAAMQF AAAAAAAAxAUAAAAAAADEBQAAhAUAAEgLAACEBQAAxAUAAAAAAADEBQAAAAAAAMQFAAAAAAAA SAsAAAAAAADEBQAAAAAAAMQFAAAAAAAAxAUAAAAAAACwBQAAAAAAALAFAAAAAAAAsAUAAAAA AACwBQAAAAAAALAFAAAAAAAAsAUAAAAAAAD/////AAAAAAIADAEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAEF1dGhlbnRpY2F0aW9uIHdpdGggT0F1dGggMi4wDVRo ZaATIEhZUEVSTElOSyAiaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjc0OSIgFE9B dXRoIDIuMBWgc3BlY2lmaWNhdGlvbiBkZWZpbmVzIGGgZGVsZWdhdGlvbqBwcm90b2NvbCB0 aGF0IGlzIHVzZWZ1bCBmb3IgY29udmV5aW5noGF1dGhvcml6YXRpb24gZGVjaXNpb25zoGFj cm9zcyBhIG5ldHdvcmsgb2Ygd2ViLWVuYWJsZWQgYXBwbGljYXRpb25zIGFuZCBBUElzLiBP QXV0aCBpcyB1c2VkIGluIGEgd2lkZSB2YXJpZXR5IG9mIGFwcGxpY2F0aW9ucywgaW5jbHVk aW5nIHByb3ZpZGluZyBtZWNoYW5pc21zIGZvciB1c2VyIGF1dGhlbnRpY2F0aW9uLiBUaGlz IGhhcyBsZWFkIG1hbnkgZGV2ZWxvcGVycyB0byBpbmNvcnJlY3RseSBjb25jbHVkZSB0aGF0 IE9BdXRoIGlzIGl0c2VsZiBhbqBhdXRoZW50aWNhdGlvbqBwcm90b2NvbCBhbmQgdG8gbWlz dGFrZW5seSB1c2UgaXQgYXMgc3VjaC4gTGV0J3Mgc2F5IHRoYXQgYWdhaW4sIHRvIGJlIGNs ZWFyOg1PQXV0aCAyLjAgaXMgbm90IGFuIGF1dGhlbnRpY2F0aW9uIHByb3RvY29sLg1NdWNo IG9mIHRoZSBjb25mdXNpb24gY29tZXMgZnJvbSB0aGUgZmFjdCB0aGF0IE9BdXRoIGlzIHVz ZWSgaW5zaWRloG9mIGF1dGhlbnRpY2F0aW9uIHByb3RvY29scywgYW5kIGRldmVsb3BlcnMg d2lsbCBzZWUgdGhlIE9BdXRoIGNvbXBvbmVudHMgYW5kIGludGVyYWN0IHdpdGggdGhlIE9B dXRoIGZsb3cgYW5kIGFzc3VtZSB0aGF0IGJ5IHNpbXBseSB1c2luZyBPQXV0aCwgdGhleSBj YW4gYWNjb21wbGlzaCB1c2VyIGF1dGhlbnRpY2F0aW9uLg1XaGF0IGlzIGF1dGhlbnRpY2F0 aW9uPw1BdXRoZW50aWNhdGlvbqB0ZWxscyBhbiBhcHBsaWNhdGlvbqB3aG8gdGhlIGN1cnJl bnQgdXNlciBpc6BhbmQgd2hldGhlciBvciBub3QgdGhleSdyZSBwcmVzZW50LiBBIGZ1bGwg YXV0aGVudGljYXRpb24gcHJvdG9jb2wgd2lsbCBwcm9iYWJseSBhbHNvIHRlbGwgeW91IGEg bnVtYmVyIG9moGF0dHJpYnV0ZXOgYWJvdXQgdGhpcyB1c2VyLCBzdWNoIGFzIGEgdW5pcXVl IGlkZW50aWZpZXIsIGFuIGVtYWlsIGFkZHJlc3MsIGFuZCB3aGF0IHRvIGNhbGwgdGhlbSB3 aGVuIHRoZSBhcHBsaWNhdGlvbiBzYXlzICJHb29kIE1vcm5pbmciLiBBdXRoZW50aWNhdGlv biBpcyBhbGwgYWJvdXQgdGhlIHVzZXIgYW5kIHRoZWlyIHByZXNlbmNlIHdpdGggdGhlIGFw cGxpY2F0aW9uLCBhbmQgYW4gaW50ZXJuZXQtc2NhbGUgYXV0aGVudGljYXRpb24gcHJvdG9j b2wgbmVlZHMgdG8gYmUgYWJsZSB0byBkbyB0aGlzIGFjcm9zcyBuZXR3b3JrIGFuZCBzZWN1 cml0eSBib3VuZGFyaWVzLg1Ib3dldmVyLCBPQXV0aCB0ZWxscyB0aGUgYXBwbGljYXRpb24g bm9uZSBvZiB0aGF0LiBPQXV0aCBzYXlzIGFic29sdXRlbHkgbm90aGluZyBhYm91dCB0aGUg dXNlciwgbm9yIGRvZXMgaXQgc2F5IGhvdyB0aGUgdXNlciBwcm92ZWQgdGhlaXIgcHJlc2Vu Y2Ugb3IgZXZlbiBpZiB0aGV5J3JlIHN0aWxsIHRoZXJlLiBBcyBmYXIgYXMgYW4gT0F1dGgg Y2xpZW50IGlzIGNvbmNlcm5lZCwgaXQgYXNrZWQgZm9yIGEgdG9rZW4sIGdvdCBhIHRva2Vu LCBhbmQgZXZlbnR1YWxseSB1c2VkIHRoYXQgdG9rZW4gdG8gYWNjZXNzIHNvbWUgQVBJLiBJ dCBkb2Vzbid0IGtub3cgYW55dGhpbmcgYWJvdXQgd2hvIGF1dGhvcml6ZWQgdGhlIGFwcGxp Y2F0aW9uIG9yIGlmIHRoZXJlIHdhcyBldmVuIGEgdXNlciB0aGVyZSBhdCBhbGwuIEluIGZh Y3QsIG11Y2ggb2YgdGhlIHBvaW50IG9mIE9BdXRoIGlzIGFib3V0IGdpdmluZyB0aGlzIGRl bGVnYXRlZCBhY2Nlc3MgZm9yIHVzZSBpbiBzaXR1YXRpb25zIHdoZXJlIHRoZaB1c2VyIGlz IG5vdCBwcmVzZW50oG9uIHRoZSBjb25uZWN0aW9uIGJldHdlZW4gdGhlIGNsaWVudCBhbmQg dGhlIHJlc291cmNlIGJlaW5nIGFjY2Vzc2VkLiBUaGlzIGlzIGdyZWF0IGZvciBjbGllbnQg YXV0aG9yaXphdGlvbiwgYnV0IGl0J3MgcmVhbGx5IGJhZCBmb3IgYXV0aGVudGljYXRpb24g d2hlcmUgdGhlIHdob2xlIHBvaW50IGlzIGZpZ3VyaW5nIG91dCBpZiB0aGUgdXNlciBpcyB0 aGVyZSBvciBub3QgKGFuZCB3aG8gdGhleSBhcmUpLg1BcyBpdCB0dXJucyBvdXQsIHRob3Vn aCwgdGhlcmUgYXJlIGEgaGFuZGZ1bCBvZiB0aGluZ3MgdGhhdCBjYW4gYmUgdXNlZCBhbG9u ZyB3aXRoIE9BdXRoIHRvoGNyZWF0ZaBhbiBhdXRoZW50aWNhdGlvbiBhbmQgaWRlbnRpdHkg cHJvdG9jb2wgb24gdG9wIG9mIHRoaXMgZGVsZWdhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiBw cm90b2NvbC4gSW4gbmVhcmx5IGFsbCBvZiB0aGVzZSBjYXNlcywgdGhlIGNvcmUgZnVuY3Rp b25hbGl0eSBvZiBPQXV0aCByZW1haW5zIGFuZCB3aGF0J3MgaGFwcGVuaW5nIGlzIHRoYXQg dGhlIHVzZXIgaXOgZGVsZWdhdGluZyBhY2Nlc3MgdG8gdGhlaXIgaWRlbnRpdHmgdG8gdGhl IGFwcGxpY2F0aW9uLiBUaGUgY2xpZW50IGFwcGxpY2F0aW9uIHRoZW4gYmVjb21lcyBhIGNv bnN1bWVyIG9mIHRoZSBpZGVudGl0eSBBUEksIHRoZXJlYnkgZmluZGluZyBvdXQgd2hvIGF1 dGhlbnRpY2F0ZWQgdGhlIGNsaWVudCBpbiB0aGUgZmlyc3QgcGxhY2UuIE9uZSBtYWpvciBi ZW5lZml0IG9mIHRoaXMgYXBwcm9hY2ggaXMgdGhhdCB0aGUgdXNlciBjYW4gZGVsZWdhdGUg YWNjZXNzIHRvIG90aGVyIHByb3RlY3RlZCBBUElzoGFsb25nIHNpZGWgdGhlaXIgaWRlbnRp dHkgYXQgdGhlIHNhbWUgdGltZSwgbWFraW5nIGl0IG11Y2ggc2ltcGxlciBmb3IgYm90aCBh cHBsaWNhdGlvbiBkZXZlbG9wZXJzIGFuZCBlbmQgdXNlcnMgdG8gbWFuYWdlLiBXaXRoIG9u ZSBjYWxsLCBhbiBhcHBsaWNhdGlvbiBjYW4gZmluZCBvdXQgaWYgYSB1c2VyIGlzIGxvZ2dl ZCBpbiwgd2hhdCB0aGUgYXBwIHNob3VsZCBjYWxsIHRoZSB1c2VyLCBkb3dubG9hZCBwaG90 b3MgZm9yIHByaW50aW5nLCBhbmQgcG9zdCB1cGRhdGVzIHRvIHRoZWlyIG1lc3NhZ2Ugc3Ry ZWFtLiBUaGlzIHNpbXBsaWNpdHkgaXMgdmVyeSBjb21wZWxsaW5nLCBidXQgYnkgZG9pbmcg Ym90aCBhdCB0aGUgc2FtZSB0aW1lLCBtYW55IGRldmVsb3BlcnMgY29uZmxhdGUgdGhlIHR3 byBmdW5jdGlvbnMuDUF1dGhlbnRpY2F0aW9uIHZzLiBBdXRob3JpemF0aW9uOiBhIG1ldGFw aG9yDVRvIGhlbHAgY2xlYXIgdGhpbmdzIHVwLCBpdCBtYXkgYmUgaGVscGZ1bCB0byB0aGlu ayBvZiB0aGUgcHJvYmxlbSBpbiB0ZXJtcyBvZiBhIG1ldGFwaG9yOiBjaG9jb2xhdGUgdnMu IGZ1ZGdlLiBGcm9tIHRoZSBzdGFydCwgdGhlIG5hdHVyZSBvZiB0aGVzZSB0d28gdGhpbmdz IGlzIHF1aXRlIGRpZmZlcmVudDogY2hvY29sYXRlIGlzIGFuIGluZ3JlZGllbnQsIGZ1ZGdl IGlzIGEgY29uZmVjdGlvbi4gQ2hvY29sYXRlIGNhbiBiZSB1c2VkIHRvIG1ha2UgbWFueSBk aWZmZXJlbnQgdGhpbmdzLCBhbmQgaXQgY2FuIGV2ZW4gYmUgdXNlZCBvbiBpdHMgb3duLiBG dWRnZSBjYW4gYmUgbWFkZSBvdXQgb2YgbWFueSBkaWZmZXJlbnQgdGhpbmdzLCBhbmQgb25l IG9mIHRob3NlIHRoaW5nc6BtaWdodKBiZSBjaG9jb2xhdGUsIGJ1dCBpdCB0YWtlcyBtb3Jl IHRoYW4gb25lIGluZ3JlZGllbnQgdG8gbWFrZSBmdWRnZSBoYXBwZW4gYW5kIGl0IG1pZ2h0 IG5vdCBldmVuIGludm9sdmUgY2hvY29sYXRlLiBBcyBzdWNoLCBpdCdzIGluY29ycmVjdCB0 byBzYXkgdGhhdKBjaG9jb2xhdGWgZXF1YWxzoGZ1ZGdlLCBvciBldmVuIHRvIHNheSB0aGF0 Y2hvY29sYXRloGVxdWFsc6BjaG9jb2xhdGUgZnVkZ2UuDU9BdXRoLCBpbiB0aGlzIG1ldGFw aG9yLCBpcyBjaG9jb2xhdGUuIEl0J3MgYSB2ZXJzYXRpbGUgaW5ncmVkaWVudCB0aGF0IGlz IGZ1bmRhbWVudGFsIHRvIGEgbnVtYmVyIG9mIGRpZmZlcmVudCB0aGluZ3MgYW5kIGNhbiBl dmVuIGJlIHVzZWQgb24gaXRzIG93biB0byBncmVhdCBlZmZlY3QuIEF1dGhlbnRpY2F0aW9u IGlzIG1vcmUgbGlrZSBmdWRnZS4gVGhlcmUgYXJlIGF0IGxlYXN0IGEgZmV3IGluZ3JlZGll bnRzIHRoYXQgbXVzdCBicm91Z2h0IHRvZ2V0aGVyIGluIHRoZSByaWdodCB3YXkgdG8gbWFr ZSBpdCB3b3JrLCBhbmQgT0F1dGggY2FuIGJlIG9uZSBvZiB0aGVzZSBpbmdyZWRpZW50cyAo cGVyaGFwcyB0aGUgbWFpbiBpbmdyZWRpZW50KSBidXQgaXQgZG9lc24ndCBoYXZlIHRvIGJl IGludm9sdmVkIGF0IGFsbC4gWW91IG5lZWQgYSByZWNpcGUgdGhhdCBzYXlzIHdoYXQgdG8g Y29tYmluZSBhbmQgaG93IHRvIGNvbWJpbmUgdGhlbSwgYW5kIHRoZXJlIGFyZSBhIGxhcmdl IG51bWJlciBvZiBkaWZmZXJlbnQgcmVjaXBlcyB0aGF0IHNheSBob3cgdGhhdCBjYW4gYmUg YWNjb21wbGlzaGVkLg1BbmQgaW4gZmFjdCwgdGhlcmUgYXJlIGEgbnVtYmVyIG9mIHdlbGwt a25vd24gcmVjaXBlcyBvdXQgdGhlcmUgZm9yIGRvaW5nIHRoaXMgd2l0aCBzcGVjaWZpYyBw cm92aWRlcnMsIGxpa2UgRmFjZWJvb2sgQ29ubmVjdCwgU2lnbiBJbiBXaXRoIFR3aXR0ZXIs IGFuZCBPcGVuSUQgQ29ubmVjdCAod2hpY2ggcG93ZXJzIEdvb2dsZSdzIHNpZ24taW4gc3lz dGVtLCBhbW9uZyBvdGhlcnMpLiBUaGVzZSByZWNpcGVzIGVhY2ggYWRkIGEgbnVtYmVyIG9m IGl0ZW1zLCBzdWNoIGFzIGEgY29tbW9uIHByb2ZpbGUgQVBJLCB0byBPQXV0aCB0byBjcmVh dGUgYW4gYXV0aG9yaXphdGlvbiBwcm90b2NvbC4NQ29tbW9uIHBpdGZhbGxzIGZvciBhdXRo ZW50aWNhdGlvbiB1c2luZyBPQXV0aA1FdmVuIHRob3VnaCBpdCdzIHZlcnkgcG9zc2libGUg dG8gdXNlIE9BdXRoIHRvIGJ1aWxkIGFuIGF1dGhlbnRpY2F0aW9uIHByb3RvY29sLCB0aGVy ZSBhcmUgYSBudW1iZXIgb2YgdGhpbmdzIHRoYXQgdGVuZCB0byB0cmlwIHVwIHRob3NlIHdo byB3aG8gZG8gc28sIGVpdGhlciBvbiB0aGUgc2lkZSBvZiB0aGUgaWRlbnRpdHkgcHJvdmlk ZXIgb3Igb24gdGhlIHNpZGUgb2YgdGhlIGlkZW50aXR5IGNvbnN1bWVyLg1BY2Nlc3MgdG9r ZW5zIGFzIHByb29mIG9mIGF1dGhlbnRpY2F0aW9uDVNpbmNlIHRoZSBhY2Nlc3MgdG9rZW4g Y2FuIGJlIHRyYWRlZCBmb3IgYSBzZXQgb2YgdXNlciBhdHRyaWJ1dGVzLCBpdCBpcyB0ZW1w dGluZyB0byB0aGluayB0aGF0IHBvc2Vzc2lvbiBvZiBhIHZhbGlkIGFjY2VzcyB0b2tlbiBp cyBlbm91Z2ggdG8gcHJvdmUgdGhhdCBhIHVzZXIgaXMgYXV0aGVudGljYXRlZC4gVGhpcyBh c3N1bXB0aW9uIHR1cm5zIG91dCB0byBiZSB0cnVlIGluIHNvbWUgY2FzZXMsIHdoZXJlIHRo ZSB0b2tlbiB3YXMgZnJlc2hseSBtaW50ZWQgaW4gdGhlIGNvbnRleHQgb2YgYSB1c2VyIGJl aW5nIGF1dGhlbnRpY2F0ZWQgYXQgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLiBIb3dldmVy LCB0aGF0J3Mgbm90IHRoZSBvbmx5IHdheSB0byBnZXQgYW4gYWNjZXNzIHRva2VuIGluIE9B dXRoLiBSZWZyZXNoIHRva2VucyBhbmQgYXNzZXJ0aW9ucyBjYW4gYmUgdXNlZCB0byBnZXQg YWNjZXNzIHRva2VucyB3aXRob3V0IHRoZSB1c2VyIGJlaW5nIHByZXNlbnQsIGFuZCBpbiBz b21lIGNhc2VzIGFjY2VzcyBncmFudHMgY2FuIG9jY3VyIHdpdGhvdXQgdGhlIHVzZXIgaGF2 aW5nIHRvIGF1dGhlbnRpY2F0ZSBhdCBhbGwuIEZ1cnRoZXJtb3JlLCB0aGUgYWNjZXNzIHRv a2VuIHdpbGwgZ2VuZXJhbGx5IGJlIHVzYWJsZSBsb25nIGFmdGVyIHRoZSB1c2VyIGlzIG5v IGxvbmdlciBwcmVzZW50LiBUaGlzIG1lYW5zIHRoYXQgaWYgYSBjbGllbnQgd2FudHMgdG8g bWFrZSBzdXJlIHRoYXQgYW4gYXV0aGVudGljYXRpb24gaXMgc3RpbGwgdmFsaWQsIGl0J3Mg bm90IHN1ZmZpY2llbnQgdG8gc2ltcGx5IHRyYWRlIHRoZSB0b2tlbiBmb3IgdGhlIHVzZXIn cyBhdHRyaWJ1dGVzIGFnYWluIGJlY2F1c2UgdGhlIE9BdXRoIHByb3RlY3RlZCByZXNvdXJj ZSwgdGhlIGlkZW50aXR5IEFQSSwgaGFzIG5vIHdheSBvZiByZS1hdXRoZW50aWNhdGluZyB0 aGUgdXNlci4NVGhpcyBwcm9ibGVtIHN0ZW1zIGZyb20gdGhlIGZhY3QgdGhhdCB0aGUgY2xp ZW50IGlzIG5vdCB0aGWgYXVkaWVuY2Wgb2YgdGhlIE9BdXRoIGFjY2VzcyB0b2tlbi4gSW5z dGVhZCwgaXQgaXMgdGhloGF1dGhvcml6ZWQgcHJlc2VudGVyoG9mIHRoYXQgdG9rZW4sIGFu ZCB0aGWgYXVkaWVuY2WgaXMgaW4gZmFjdCB0aGUgcHJvdGVjdGVkIHJlc291cmNlLiBUaGUg cHJvdGVjdGVkIHJlc291cmNlIGlzIG5vdCBnZW5lcmFsbHkgZ29pbmcgdG8gYmUgaW4gYSBw b3NpdGlvbiB0byB0ZWxsIGlmIHRoZSB1c2VyIGlzIHN0aWxsIHByZXNlbnQgYnkgdGhlIHRv a2VuIGFsb25lLCBzaW5jZSBieSB0aGUgdmVyeSBuYXR1cmUgYW5kIGRlc2lnbiBvZiB0aGUg T0F1dGggcHJvdG9jb2wgdGhlIHVzZXIgd2lsbCBub3QgYmUgYXZhaWxhYmxlIG9uIHRoZSBj b25uZWN0aW9uIGJldHdlZW4gdGhlIGNsaWVudCBhbmQgcHJvdGVjdGVkIHJlc291cmNlLiBU byBjb3VudGVyIHRoaXMsIHRoZXJlIG5lZWRzIHRvIGJlIGFuIGFydGlmYWN0IHRoYXQgaXMg ZGlyZWN0ZWQgYXQgdGhlIGNsaWVudCBpdHNlbGYuIFRoaXMgY291bGQgYmUgZG9uZSBieSBk dWFsLXB1cnBvc2luZyB0aGUgYWNjZXNzIHRva2VuLCBkZWZpbmluZyBhIGZvcm1hdCB0aGF0 IHRoZSBjbGllbnQgY291bGQgcGFyc2UgYW5kIHVuZGVyc3RhbmQuIEhvd2V2ZXIsIHNpbmNl IGdlbmVyYWwgT0F1dGggZG9lcyBub3QgZGVmaW5lIGEgc3BlY2lmaWMgZm9ybWF0IG9yIHN0 cnVjdHVyZSBmb3IgdGhlIGFjY2VzcyB0b2tlbiBpdHNlbGYsIHByb3RvY29scyBsaWtlIE9w ZW5JRCBDb25uZWN0IGFuZCBGYWNlYm9vayBDb25uZWN0IHByb3ZpZGUgYSBzZWNvbmRhcnkg dG9rZW4gYWxvbmcgc2lkZSB0aGUgYWNjZXNzIHRva2VuIHRoYXQgY29tbXVuaWNhdGVzIHRo ZSBhdXRoZW50aWNhdGlvbiBpbmZvcm1hdGlvbiBkaXJlY3RseSB0byB0aGUgY2xpZW50LiBU aGlzIGFsbG93cyB0aGUgcHJpbWFyeSBhY2Nlc3MgdG9rZW4gdG8gcmVtYWluIG9wYXF1ZSB0 byB0aGUgY2xpZW50LCBqdXN0IGxpa2UgaW4gcmVndWxhciBPQXV0aC4NTGFjayBvZiBhdWRp ZW5jZSByZXN0cmljdGlvbg1Bbm90aGVyIHByb2JsZW0gd2l0aCB0cmFkaW5nIHRoZSBhY2Nl c3MgdG9rZW4gZm9yIGEgc2V0IG9mIGF0dHJpYnV0ZXMgdG8gZ2V0IHRoZSBjdXJyZW50IHVz ZXIgaXMgdGhhdCBtb3N0IE9BdXRoIEFQSXMgZG8gbm90IHByb3ZpZGUgYW55IG1lY2hhbmlz bSBvZiBhdWRpZW5jZSByZXN0cmljdGlvbiBmb3IgdGhlIHJldHVybmVkIGluZm9ybWF0aW9u LiBJbiBvdGhlciB3b3JkcywgaXQgaXMgdmVyeSBwb3NzaWJsZSB0byB0YWtlIGEgbmFpdmUg Y2xpZW50LCBoYW5kIGl0IHRoZSAodmFsaWQpIHRva2VuIGZyb20gYW5vdGhlciBjbGllbnQs IGFuZCBoYXZlIHRoZSBuYWl2ZSBjbGllbnQgdHJlYXQgdGhpcyBhcyBhICJsb2cgaW4iIGV2 ZW4uIEFmdGVyIGFsbCwgdGhlIHRva2VuIGlzIHZhbGlkIGFuZCBpdCB3aWxsIHJldHVybiB2 YWxpZCB1c2VyIGluZm9ybWF0aW9uLiBUaGUgcHJvYmxlbSBpcyBvZiBjb3Vyc2UgdGhhdCB0 aGUgdXNlciBoYXNuJ3QgZG9uZSBhbnl0aGluZyB0byBwcm92ZSB0aGF0IHRoZXkncmUgcHJl c2VudCwgYW5kIGluIHRoaXMgY2FzZSB0aGV5IGhhdmVuJ3QgZXZlbiBhdXRob3JpemVkIHRo ZSBuYWl2ZSBjbGllbnQuDVRoaXMgcHJvYmxlbSBjYW4gYmUgbWl0aWdhdGVkIGJ5IGNvbW11 bmljYXRpbmcgdGhlIGF1dGhlbnRpY2F0aW9uIGluZm9ybWF0aW9uIHRvIGEgY2xpZW50IGFs b25nIHdpdGggYW4gaWRlbnRpZmllciB0aGF0IHRoZSBjbGllbnQgY2FuIHJlY29nbml6ZSBh bmQgdmFsaWRhdGUsIGFsbG93aW5nIHRoZSBjbGllbnQgdG8gZGlmZmVyZW50aWF0ZSBiZXR3 ZWVuIGFuIGF1dGhlbnRpY2F0aW9uIGZvciBpdHNlbGYgdmVyc3VzIGFuIGF1dGhlbnRpY2F0 aW9uIGZvciBhbm90aGVyIGFwcGxpY2F0aW9uLiBJdCBpcyBhbHNvIG1pdGlnYXRlZCBieSBw YXNzaW5nIHRoZSBzZXQgb2YgYXV0aGVudGljYXRpb24gaW5mb3JtYXRpb24gZGlyZWN0bHkg dG8gdGhlIGNsaWVudCBkdXJpbmcgdGhlIE9BdXRoIHByb2Nlc3MgaW5zdGVhZCBvZiB0aHJv dWdoIGEgc2Vjb25kYXJ5IG1lY2hhbmlzbSBzdWNoIGFzIGFuIE9BdXRoIHByb3RlY3RlZCBB UEksIHByZXZlbnRpbmcgYSBjbGllbnQgZnJvbSBoYXZpbmcgYW4gdW5rbm93biBhbmQgdW50 cnVzdGVkIHNldCBvZiBpbmZvcm1hdGlvbiBpbmplY3RlZCBsYXRlciBpbiB0aGUgcHJvY2Vz cy4NSW5qZWN0aW9uIG9mIGludmFsaWQgdXNlciBpbmZvcm1hdGlvbg1JZiBhbiBhdHRhY2tl ciBpcyBhYmxlIHRvIGludGVyY2VwdCBvciBjb29wdCBvbmUgb2YgdGhlIGNhbGxzIGZyb20g dGhlIGNsaWVudCwgaXQgY291bGQgYWx0ZXIgdGhlIGNvbnRlbnQgb2YgdGhlIHJldHVybmVk IHVzZXIgaW5mb3JtYXRpb24gd2l0aG91dCB0aGUgY2xpZW50IGJlaW5nIGFibGUgdG8ga25v dyBhbnl0aGluZyB3YXMgYW1pc3MuIFRoaXMgd291bGQgYWxsb3cgYW4gYXR0YWNrZXIgdG8g aW1wZXJzb25hdGUgYSB1c2VyIGF0IGEgbmFpdmUgY2xpZW50IGJ5IHNpbXBseSBzd2FwcGlu ZyBvdXQgYSB1c2VyIGlkZW50aWZpZXIgaW4gdGhlIHJpZ2h0IGNhbGwgc2VxdWVuY2UuIFRo aXMgY2FuIGJlIG1pdGlnYXRlZCBieSBnZXR0aW5nIHRoZSBhdXRoZW50aWNhdGlvbiBpbmZv cm1hdGlvbiBkaXJlY3RseSBmcm9tIHRoZSBpZGVudGl0eSBwcm92aWRlciBkdXJpbmcgdGhl IGF1dGhlbnRpY2F0aW9uIHByb3RvY29sIHByb2Nlc3MgKHN1Y2ggYXMgYWxvbmcgc2lkZSB0 aGUgT0F1dGggdG9rZW4pIGFuZCBieSBwcm90ZWN0aW5nIHRoZSBhdXRoZW50aWNhdGlvbiBp bmZvcm1hdGlvbiB3aXRoIGEgdmVyaWZpYWJsZSBzaWduYXR1cmUuDURpZmZlcmVudCBwcm90 b2NvbHMgZm9yIGV2ZXJ5IHBvdGVudGlhbCBpZGVudGl0eSBwcm92aWRlcg1PbmUgb2YgdGhl IGJpZ2dlc3QgcHJvYmxlbXMgd2l0aCBPQXV0aC1iYXNlZCBpZGVudGl0eSBBUElzIGlzIHRo YXQgZXZlbiB3aGVuIHVzaW5nIGEgZnVsbHkgc3RhbmRhcmRzLWNvbXBsaWFudCBPQXV0aCBt ZWNoYW5pc20sIGRpZmZlcmVudCBwcm92aWRlcnMgd2lsbCBpbmV2aXRhYmx5IGltcGxlbWVu dCB0aGUgZGV0YWlscyBvZiB0aGUgYWN0dWFsIGlkZW50aXR5IEFQSSBkaWZmZXJlbnRseS4g Rm9yIGV4YW1wbGUsIGEgdXNlcidzIGlkZW50aWZpZXIgbWlnaHQgYmUgZm91bmQgaW4gYaB1 c2VyX2lkoGZpZWxkIGluIG9uZSBwcm92aWRlciBidXQgaW4gdGhloHN1YmplY3SgZmllbGQg aW4gYW5vdGhlciBwcm92aWRlci4gRXZlbiB0aG91Z2ggdGhlc2UgYXJlIHNlbWFudGljYWxs eSBlcXVpdmFsZW50LCB0aGV5IHdvdWxkIHJlcXVpcmUgdHdvIHNlcGFyYXRlIGNvZGUgcGF0 aHMgdG8gcHJvY2Vzcy4gSW4gb3RoZXIgd29yZHMsIHdoaWxlIHRoZSBhdXRob3JpemF0aW9u IG1heSBoYXBwZW4gdGhlIHNhbWUgd2F5IGF0IGVhY2ggcHJvdmlkZXIsIHRoZSBjb252ZXlh bmNlIG9mIHRoZSBhdXRoZW50aWNhdGlvbiBpbmZvcm1hdGlvbiBjb3VsZCBiZSBkaWZmZXJl bnQuIFRoaXMgcHJvYmxlbSBjYW4gYmUgbWl0aWdhdGVkIGJ5IHByb3ZpZGVycyB1c2luZyBh IHN0YW5kYXJkoGF1dGhlbnRpY2F0aW9uIHByb3RvY29soGJ1aWx0IG9uIHRvcCBvZiBPQXV0 aCBzbyB0aGF0IG5vIG1hdHRlciB3aGVyZSB0aGUgaWRlbnRpdHkgaW5mb3JtYXRpb24gaXMg Y29taW5nIGZyb20sIGl0IGlzIHRyYW5zbWl0dGVkIGluIHRoZSBzYW1lIHdheS4NQSBzdGFu ZGFyZCBmb3IgYXV0aGVudGljYXRpb24gdXNpbmcgT0F1dGg6IE9wZW5JRCBDb25uZWN0DRMg SFlQRVJMSU5LICJodHRwOi8vb3BlbmlkLm5ldC9jb25uZWN0LyIgFE9wZW5JRCBDb25uZWN0 FaBpcyBhbiBvcGVuIHN0YW5kYXJkIHB1Ymxpc2hlZCBpbiBlYXJseSAyMDE0IHRoYXQgZGVm aW5lcyBhbiBpbnRlcm9wZXJhYmxlIHdheSB0byB1c2UgT0F1dGggMi4wIHRvIHBlcmZvcm0g dXNlciBhdXRoZW50aWNhdGlvbi4gSW4gZXNzZW5jZSwgaXQgaXMgYSB3aWRlbHkgcHVibGlz aGVkIHJlY2lwZSBmb3KgY2hvY29sYXRlIGZ1ZGdloHRoYXQgaGFzIGJlZW4gdHJpZWQgYW5k IHRlc3RlZCBieSBhIHdpZGUgbnVtYmVyIGFuZCB2YXJpZXR5IG9mIGV4cGVydHMuIEluc3Rl YWQgb2YgYnVpbGRpbmcgYSBkaWZmZXJlbnQgcHJvdG9jb2wgdG8gZWFjaCBwb3RlbnRpYWwg aWRlbnRpdHkgcHJvdmlkZXIsIGFuIGFwcGxpY2F0aW9uIGNhbiBzcGVhayBvbmUgcHJvdG9j b2wgdG8gYXMgbWFueSBwcm92aWRlcnMgYXMgdGhleSB3YW50IHRvIHdvcmsgd2l0aC4gU2lu Y2UgaXQncyBhbiBvcGVuIHN0YW5kYXJkLCBPcGVuSUQgQ29ubmVjdCBjYW4gYmUgaW1wbGVt ZW50ZWQgYnkgYW55b25lIHdpdGhvdXQgcmVzdHJpY3Rpb24gb3IgaW50ZWxsZWN0dWFsIHBy b3BlcnR5IGNvbmNlcm5zLg1PcGVuSUQgQ29ubmVjdCBpcyBidWlsdCBkaXJlY3RseSBvbiBP QXV0aCAyLjAgYW5kIGluIG1vc3QgY2FzZXMgaXMgZGVwbG95ZWQgcmlnaHQgYWxvbmcgd2l0 aCAob3Igb24gdG9wIG9mKSBhbiBPQXV0aCBpbmZyYXN0cnVjdHVyZS4gT3BlbklEIENvbm5l Y3QgYWxzbyB1c2VzIHRoZSBKU09OIE9iamVjdCBTaWduaW5nIEFuZCBFbmNyeXB0aW9uIChK T1NFKSBzdWl0ZSBvZiBzcGVjaWZpY2F0aW9ucyBmb3IgY2Fycnlpbmcgc2lnbmVkIGFuZCBl bmNyeXB0ZWQgaW5mb3JtYXRpb24gYXJvdW5kIGluIGRpZmZlcmVudCBwbGFjZXMuIEluIGZh Y3QsIGFuIE9BdXRoIDIuMCBkZXBsb3ltZW50IHdpdGggSk9TRSBjYXBhYmlsaXRpZXMgaXMg YWxyZWFkeSBhIGxvbmcgd2F5IHRvIGRlZmluaW5nIGEgZnVsbHkgY29tcGxpYW50IE9wZW5J RCBDb25uZWN0IHN5c3RlbSwgYW5kIHRoZSBkZWx0YSBiZXR3ZWVuIHRoZSB0d28gaXMgcmVs YXRpdmVseSBzbWFsbC4gQnV0IHRoYXQgZGVsdGEgbWFrZXMgYSBiaWcgZGlmZmVyZW5jZSwg YW5kIE9wZW5JRCBDb25uZWN0IG1hbmFnZXMgdG8gYXZvaWQgbWFueSBvZiB0aGUgcGl0ZmFs bHMgZGlzY3Vzc2VkIGFib3ZlIGJ5IGFkZGluZyBzZXZlcmFsIGtleSBjb21wb25lbnRzIHRv IHRoZSBPQXV0aCBiYXNlOg1JRCBUb2tlbnMNVGhlIE9wZW5JRCBDb25uZWN0IElEIFRva2Vu IGlzIGEgc2lnbmVkIEpTT04gV2ViIFRva2VuIChKV1QpIHRoYXQgaXMgZ2l2ZW4gdG8gdGhl IGNsaWVudCBhcHBsaWNhdGlvbiBhbG9uZyBzaWRlIHRoZSByZWd1bGFyIE9BdXRoIGFjY2Vz cyB0b2tlbi4gVGhlIElEIFRva2VuIGNvbnRhaW5zIGEgc2V0IG9mIGNsYWltcyBhYm91dCB0 aGUgYXV0aGVudGljYXRpb24gc2Vzc2lvbiwgaW5jbHVkaW5nIGFuIGlkZW50aWZpZXIgZm9y IHRoZSB1c2VyIChzdWIpLCB0aGUgaWRlbnRpZmllciBmb3IgdGhlIGlkZW50aXR5IHByb3Zp ZGVyIHdobyBpc3N1ZWQgdGhlIHRva2VuIChpc3MpLCBhbmQgdGhlIGlkZW50aWZpZXIgb2Yg dGhlIGNsaWVudCBmb3Igd2hpY2ggdGhpcyB0b2tlbiB3YXMgY3JlYXRlZCAoYXVkKS4gQWRk aXRpb25hbGx5LCB0aGUgSUQgVG9rZW4gY29udGFpbnMgaW5mb3JtYXRpb24gYWJvdXQgdGhl IHRva2VuJ3MgdmFsaWQgKGFuZCB1c3VhbGx5IHNob3J0KSBsaWZldGltZSBhcyB3ZWxsIGFz IGFueSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgYXV0aGVudGljYXRpb24gY29udGV4dCB0byBi ZSBjb252ZXllZCB0byB0aGUgY2xpZW50LCBzdWNoIGFzIGhvdyBsb25nIGFnbyB0aGUgdXNl ciB3YXMgcHJlc2VudGVkIHdpdGggYSBwcmltYXJ5IGF1dGhlbnRpY2F0aW9uIG1lY2VoYW5p c20uIFNpbmNlIHRoZSBmb3JtYXQgb2YgdGhlIElEIFRva2VuIGlzIGtub3duIGJ5IHRoZSBj bGllbnQsIGl0IGlzIGFibGUgdG8gcGFyc2UgdGhlIGNvbnRlbnQgb2YgdGhlIHRva2VuIGRp cmVjdGx5IGFuZCBvYnRhaW4gdGhpcyBpbmZvcm1hdGlvbiB3aXRob3V0IHJlbHlpbmcgb24g YW4gZXh0ZXJuYWwgc2VydmljZSB0byBkbyBzby4gRnVydGhlcm1vcmUsIGl0IGlzIGlzc3Vl ZCBpbiBhZGRpdGlvbiB0byAoYW5kIG5vdCBpbiBsaWV1IG9mKSBhbiBhY2Nlc3MgdG9rZW4s IGFsbG93aW5nIHRoZSBhY2Nlc3MgdG9rZW4gdG8gcmVtYWluIG9wYXF1ZSB0byB0aGUgY2xp ZW50IGFzIGl0IGlzIGRlZmluZWQgaW4gcmVndWxhciBPQXV0aC4gRmluYWxseSwgdGhlIHRv a2VuIGl0c2VsZiBpcyBzaWduZWQgYnkgdGhlIGlkZW50aXR5IHByb3ZpZGVyJ3MgcHVibGlj IGtleSwgYWRkaW5nIGFuIGFkZGl0aW9uYWwgbGF5ZXIgb2YgcHJvdGVjdGlvbiB0byB0aGUg Y2xhaW1zIGluc2lkZSBvZiBpdCBpbiBhZGRpdGlvbiB0byB0aGUgVExTIHRyYW5zcG9ydCBw cm90ZWN0aW9uIHRoYXQgd2FzIHVzZWQgdG8gZ2V0IHRoZSB0b2tlbiBpbiB0aGUgZmlyc3Qg cGxhY2UsIHByZXZlbnRpbmcgYSBjbGFzcyBvZiBpbXBlcnNvbmF0aW9uIGF0dGFja3MuIEJ5 IGFwcGx5aW5nIGEgZmV3IHNpbXBsZSBjaGVja3MgdG8gdGhpcyBJRCB0b2tlbiwgYSBjbGll bnQgY2FuIHByb3RlY3QgaXRzZWxmIGZyb20gYSBsYXJnZSBudW1iZXIgb2YgY29tbW9uIGF0 dGFja3MuDVVzZXJJbmZvIEVuZHBvaW50DUluIGFkZGl0aW9uIHRvIHRoZSBjbGFpbXMgaW4g dGhlIElEIFRva2VuLCBPcGVuSUQgQ29ubmVjdCBkZWZpbmVzIGEgc3RhbmRhcmQgcHJvdGVj dGVkIHJlc291cmNlIHRoYXQgY29udGFpbnMgY2xhaW1zIGFib3V0IHRoZSBjdXJyZW50IHVz ZXIuIFRoZSBjbGFpbXMgaGVyZSBhcmUgbm90IHBhcnQgb2YgdGhlIGF1dGhlbnRpY2F0aW9u IHByb2Nlc3MsIGFzIGRpc2N1c3NlZCBhYm92ZSwgYnV0IGluc3RlYWQgcHJvdmlkZSBidW5k bGVkIGlkZW50aXR5IGF0dHJpYnV0ZXMgdGhhdCBtYWtlIHRoZSBhdXRoZW50aWNhdGlvbiBw cm90b2NvbCBtb3JlIHZhbHVhYmxlIHRvIGFwcGxpY2F0aW9uIGRldmVsb3BlcnMuIEFmdGVy IGFsbCwgaXQncyBwcmVmZXJhYmxlIHRvIHNheSAiR29vZCBNb3JuaW5nLCBKYW5lIERvZSIg aW5zdGVhZCBvZiAiR29vZCBNb3JuaW5nLCA5WEUzLUpJMzQtMDAxMzJBIi4gT3BlbklEIENv bm5lY3QgZGVmaW5lcyBzZXQgb2Ygc3RhbmRhcmRpemVkIE9BdXRoIHNjb3BlcyB0aGF0IG1h cCB0byBzdWJzZXRzIG9mIHRoZXNlIGF0dHJpYnV0ZXMsIGFsbG93aW5nIHBsYWluIE9BdXRo IGF1dGhvcml6YXRpb24gcmVxdWVzdCB0byBjYXJyeSB0aGUgbmVjZXNzYXJ5IGluZm9ybWF0 aW9uIGZvciBhIHJlcXVlc3QuIEluIHBhcnRpY3VsYXIsIHRoZSBPcGVuSUQgQ29ubmVjdCBk ZWZpbmVzIGEgc3BlY2lhbKBvcGVuaWSgc2NvcGUgdGhhdCBzd2l0Y2hlcyBvbiB0aGUgaXNz dWFuY2Ugb2YgdGhlIElEIHRva2VuIGFzIHdlbGwgYXMgYWNjZXNzIHRvIHRoZSBVc2VySW5m byBFbmRwb2ludCBieSB0aGUgYWNjZXNzIHRva2VuLiBUaGUgT3BlbklEIENvbm5lY3Qgc2Nv cGVzIGNhbiBiZSB1c2VkIGFsb25nIHNpZGUgbW9yZSBwbGFpbiBPQXV0aCBzY29wZXMgd2l0 aG91dCBpc3N1ZS4NRHluYW1pYyBzZXJ2ZXIgZGlzY292ZXJ5IGFuZCBjbGllbnQgcmVnaXN0 cmF0aW9uDU9BdXRoIDIuMCB3YXMgd3JpdHRlbiB0byBhbGxvdyBhIHZhcmlldHkgb2YgZGlm ZmVyZW50IGRlcGxveW1lbnRzLCBidXQgYnkgZGVzaWduIGRvZXMgbm90IHNwZWNpZnkgaG93 IHRoZXNlIGRlcGxveW1lbnRzIGNvbWUgdG8gYmUgc2V0IHVwIG9yIGhvdyB0aGUgY29tcG9u ZW50cyBrbm93IGFib3V0IGVhY2ggb3RoZXIuIFRoaXMgaXMgT0sgaW4gdGhlIHJlZ3VsYXIg T0F1dGggd29ybGQgd2hlcmUgb25lIGF1dGhvcml6YXRvaW4gc2VydmVyIHByb3RlY3RzIGEg c3BlY2lmaWMgQVBJLCBhbmQgdGhlIHR3byBhcmUgY2xvc2VseSBjb3VwbGVkLiBXaXRoIE9w ZW5JRCBDb25uZWN0LCBhIGNvbW1vbiBwcm90ZWN0ZWQgQVBJIGlzIGRlcGxveWVkIGFjcm9z cyBhIHdpZGUgdmFyaWV0eSBvZiBjbGllbnRzIGFuZCBwcm92aWRlcnMsIGFsbCBvZiB3aGlj aCBuZWVkIHRvIGtub3cgYWJvdXQgZWFjaCBvdGhlciB0byBvcGVyYXRlLiBJdCB3b3VsZCBu b3QgYmUgc2NhbGFibGUgZm9yIGVhY2ggY2xpZW50IHRvIGhhdmUgdG8ga25vdyBhaGVhZCBv ZiB0aW1lIGFib3V0IGVhY2ggcHJvdmlkZXIsIGFuZCBpdCB3b3VsZCBiZSBldmVuIG1vcmUg dW5zY2FsYWJsZSB0byByZXF1aXJlIGVhY2ggcHJvdmlkZXIgdG8ga25vdyBhYm91dCBlYWNo IHBvdGVudGlhbCBjbGllbnQuDVRvIGNvdW50ZXJhY3QgdGhpcywgT3BlbklEIENvbm5lY3Qg ZGVmaW5lcyBhoBMgSFlQRVJMSU5LICJodHRwOi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQt Y29ubmVjdC1kaXNjb3ZlcnktMV8wLmh0bWwiIBRkaXNjb3ZlcnkVoHByb3RvY29sIHRoYXQg YWxsb3dzIGNsaWVudHMgdG8gZWFzaWx5IGZldGNoIGluZm9ybWF0aW9uIG9uIGhvdyB0byBp bnRlcmFjdCB3aXRoIGEgc3BlY2lmaWMgaWRlbnRpdHkgcHJvdmlkZXIuIE9uIHRoZSBvdGhl ciBzaWRlIG9mIHRoZSB0cmFuc2FjdGlvbiwgT3BlbklEIENvbm5lY3QgZGVmaW5lcyBhoBMg SFlQRVJMSU5LICJodHRwOi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQtY29ubmVjdC1yZWdp c3RyYXRpb24tMV8wLmh0bWwiIBRjbGllbnQgcmVnaXN0cmF0aW9uFaBwcm90b2NvbCB0aGF0 IGFsbG93cyBjbGllbnRzIHRvIGJlIGludHJvZHVjZWQgdG8gbmV3IGlkZW50aXR5IHByb3Zp ZGVycy4gQnkgdXNpbmcgdGhlc2UgdHdvIG1lY2hhbmlzbXMgYW5kIGEgY29tbW9uIGlkZW50 aXR5IEFQSSwgT3BlbklEIENvbm5lY3QgY2FuIGZ1bmN0aW9uIGF0IGludGVybmV0IHNjYWxl LCB3aGVyZSBubyBwYXJ0aWVzIGhhdmUgdG8ga25vdyBhYm91dCBlYWNoIG90aGVyIGFoZWFk IG9mIHRpbWUuDUFkdmFuY2VkIGNhcGFiaWxpdGllcw1PcGVuSUQgQ29ubmVjdCBhbHNvIGRl ZmluZXMgYSBudW1iZXIgb2YgYWR2YW5jZWQgY2FwYWJpbGl0aWVzIGJleW9uZCBzdGFuZGFy ZCBPQXV0aCB0aGF0IGFyZSBzdWl0YWJsZSBmb3IgaGlnaGVyIHNlY3VyaXR5IHByb2ZpbGVz IGFuZCBkZXBsb3ltZW50cywgaW5jbHVkaW5nIChhbW9uZyBvdGhlcnMpOg1QdWJsaWMga2V5 IGNsaWVudCBhdXRoZW50aWNhdGlvbg1TZWxlY3RpbmcgYW5kIHJldHJpZXZpbmcgc3BlY2lm aWMgY2xhaW1zIGFuZCB2YWx1ZXMgZnJvbSB0aGUgaWRlbnRpdHkgcHJvdmlkZXINU2lnbmlu ZyBhbmQgZW5jcnlwdGluZyBPQXV0aCByZXF1ZXN0cw1TZXNzaW9uIG1hbmFnZW1lbnQgb3Zl ciB0aW1lDUZ1cnRoZXIgUmVhZGluZw1JbiB0aGUgYXJ0aWNsZaATIEhZUEVSTElOSyAiaHR0 cDovL3d3dy5jbG91ZGlkZW50aXR5LmNvbS9ibG9nLzIwMTMvMDEvMDIvb2F1dGgtMi0wLWFu ZC1zaWduLWluLTQvIiAUT0F1dGggMi4wIGFuZCBTaWduLWluFSwgVml0dG9yaW8gQmVydG9j Y2kgcHJvdmlkZXMgZGV0YWlsIG9uIHRoZSBzZWN1cml0eSBib3VuZGFyaWVzIGJldHdlZW4g cGFydGllcyBhbmQgd2h5IHRoZSBhdXRob3JpemF0aW9uIGxheWVyIG1ha2VzIHNlbnNlIGFz IHRoZSBsb3dlciBsYXllciB0byBidWlsZCBvbiB0b3Agb2YuDUp1c3RpbiBSaWNoZXIgcHJl c2VudGVkIGEgZGV0YWlsZWQgb3ZlcnZpZXcgb2YgdGhlIHRlY2hub2xvZ2llcyB0YWxrZWQg YWJvdXQgaGVyZSBpbqATIEhZUEVSTElOSyAiaHR0cDovL3d3dy5zbGlkZXNoYXJlLm5ldC96 ZXJvbmluZTEvYXV0aC1pbi10aGUtZXh0ZW5kZWQtZW50ZXJwcmlzZS1taXQtaGFja2F0aG9u LTIwMTMiIBRBdXRoKiBJbiB0aGUgRXh0ZW5kZWQgRW50ZXJwcmlzZRWgYXQgTUlULg0NAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAYAAB4IAAAhCAAAIggAACMIAABTCAAAVAgAAF0IAABeCAAA XwgAAHYIAAB3CAAAgQgAAIIIAACnCAAAqAgAAL8IAADACAAArQkAAK4JAAC8CQAAvQkAAAsK AAA3CgAAdAoAAHUKAAB7CgAAfAoAAE8LAABdCwAAXgsAAHILAABzCwAAigsAAIsLAAD1CwAA 9gsAAAAMAAABDAAARA8AAEUPAABYDwAAWQ8AAJ8QAACgEAAAphAAAKcQAABzEQAAdBEAAPDd yLfdt6a3yN3IkMjdyJDI3ciQyN163ciQyN16yN3IkMjdyJDI3ciQyN3IkMjdyCsVaMpm4AAW aMpm4AA1CIFCKgFDShsAXAiBYUobAG1ICQhwaAAAAABzSAkIKxVoymbgABZoymbgADYIgUIq AUNKGwBdCIFhShsAbUgJCHBoAAAAAHNICQggFWjKZuAAFmjKZuAAMEoRAENKGwBhShsAbUgJ CHNICQgAIANqAAAAABZoymbgAEIqAUNKGwBVCAFhShsAcGgAAAAAACkVaMpm4AAWaMpm4AAw ShAAQioBQ0obAGFKGwBtSAkIcGgAAAAAc0gJCCUVaMpm4AAWaMpm4ABCKgFDShsAYUobAG1I CQhwaAAAAABzSAkIHRVoymbgABZoymbgAEIqAW1ICQhwaAAAAABzSAkIADAABgAAHggAAAsK AAA4CgAANwsAAE8LAABBDQAARBAAADMUAABgFAAA0BYAAA4ZAABiGgAAkRoAAH4bAACnGwAA XR8AAIAjAACdIwAA7iUAADMoAABZKAAAqioAAOQqAAASLgAATC4AALEwAAA5MwAA+gAAAAAA AAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPAAAAAAAAAA AAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAADwAAAAAAAAAAAA AAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAA APUAAAAAAAAAAAAAAADwAAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAADw AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAADwAAAAAAAAAAAAAAAA9QAA AAAAAAAAAAAAAPAAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAPUAAAAA AAAAAAAAAAD1AAAAAAAAAAAAAAAAAAAAAAAAAAAEAwBnZMpm4AAABAQAZ2TKZuAAAAQPAGdk ymbgAAAEAgBnZMpm4AAAGwAGAABJRQAA/gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAQEBdBEAAJcRAACYEQAA lBIAAJUSAACfEgAAoBIAAOYVAADnFQAA7BUAAO0VAACCFgAAgxYAAIwWAACNFgAAkxYAAJQW AACZFgAArhYAALcWAAC4FgAAvhYAAL8WAADOFgAAYhoAAJEaAACYHwAAmR8AAKEfAACiHwAA zx8AANAfAADkHwAA5R8AAPsfAAD8HwAABCAAAAUgAAD6KwAA+ysAAAIsAAADLAAAIywAACQs AAArLAAALCwAAH8tAACALQAAly0AAJgtAAASLgAATC4AAE0uAAB1LgAAdi4AAOnUwdTp1MHU 6dTB1OnUwdTpwenUwdTpwbLB1OnUwdTp1MHU6dTB1KHUwdSh1MHU6dTBspDBkAAAAAAAAAAA AAAAAAAAIANqAAAAABZoymbgAEIqAUNKGwBVCAFhShsAcGgAAAAAACEVaMpm4AAWaMpm4AAw ShIAQioBbUgJCHBoAAAAAHNICQgdFWjKZuAAFmjKZuAAQioBbUgJCHBoAAAAAHNICQglFWjK ZuAAFmjKZuAAQioBQ0obAGFKGwBtSAkIcGgAAAAAc0gJCCkVaMpm4AAWaMpm4AAwShAAQioB Q0obAGFKGwBtSAkIcGgAAAAAc0gJCCsVaMpm4AAWaMpm4AA2CIFCKgFDShsAXQiBYUobAG1I CQhwaAAAAABzSAkIADZ2LgAAhC4AAIUuAACGLgAANC8AADUvAABELwAARS8AAEE0AABENAAA hjQAAIk0AADPNAAA0jQAAKg7AACpOwAArzsAALA7AABtPwAAbj8AAG8/AAC2PwAAtz8AAMA/ AADBPwAAwj8AAG9AAABwQAAAcUAAALtAAAC8QAAAz0AAANBAAADRQAAAhEIAADdDAABHQwAA VUMAAFZDAABXQwAAqkMAAKtDAADv3sm2yaDJto+2j7aPtsmPybbJ3rbe797Jtsnett7v3sm2 g3uDbd6D3gAAAAAAAAAAABsWaMpm4AAwShAAQioBQ0obAGFKGwBwaAAAAAAPFmjKZuAAQioB cGgAAAAAFxZoymbgAEIqAUNKGwBhShsAcGgAAAAAIRVoymbgABZoymbgADBKEgBCKgFtSAkI cGgAAAAAc0gJCCsVaMpm4AAWaMpm4AA2CIFCKgFDShsAXQiBYUobAG1ICQhwaAAAAABzSAkI JRVoymbgABZoymbgAEIqAUNKGwBhShsAbUgJCHBoAAAAAHNICQgpFWjKZuAAFmjKZuAAMEoQ AEIqAUNKGwBhShsAbUgJCHBoAAAAAHNICQggA2oAAAAAFmjKZuAAQioBQ0obAFUIAWFKGwBw aAAAAAAAIBVoymbgABZoymbgADBKEQBDShsAYUobAG1ICQhzSAkIKTkzAABDMwAA4TgAAPM4 AAB8PAAArTwAAEE/AADAQQAA1kEAAIRCAAClQgAA9EIAABpDAAA3QwAAR0MAAGNEAABIRQAA SUUAAPoAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPUAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA 9QAAAAAAAAAAAAAAAOYAAAAAAAAAAAAAAADmAAAAAAAAAAAAAAAA5gAAAAAAAAAAAAAAAOYA AAAAAAAAAAAAAADhAAAAAAAAAAAAAAAA0gAAAAAAAAAAAAAAANIAAAAAAAAAAAAAAADQAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAA8AAAomAAtGAgATpGQAFKRkAFskAVwkAWdk ymbgAAAEAwBnZMpm4AAPAAAKJgALRgEAE6RkABSkZABbJAFcJAFnZMpm4AAABA8AZ2TKZuAA AAQEAGdkymbgAAARq0MAAMBDAADBQwAAt0QAALhEAAC5RAAAHUUAAB5FAAA+RQAAP0UAAEBF AABIRQAASUUAAPbl2cvl2eX25cvZxwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGFmjKZuAAABsWaMpm4AAwShAAQioB Q0obAGFKGwBwaAAAAAAXFmjKZuAAQioBQ0obAGFKGwBwaAAAAAAgA2oAAAAAFmjKZuAAQioB Q0obAFUIAWFKGwBwaAAAAAAAEhZoymbgADBKEQBDShsAYUobAAwsADGQaAEfsIIuILDGQSGw bgQisG4EI5CJBSSQiQUlsAAAF7DEAhiwxAIMkMQCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AACGAhMAEgABAJwADwAEAAAAAwAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AABEAABg8f8CAEQADAQAAAAAAAAAAAYATgBvAHIAbQBhAGwAAAACAAAAHABDShgAX0gBBGFK GABtSAkEbkgSBHNICQR0SBIEAABWAAJgAQAiAFYADAAAAMpm4AAAAAkASABlAGEAZABpAG4A ZwAgADIAAAATAAIAE6RkABSkZABAJgFbJAFcJAEAFgA1CIFDSiQAXAiBYUokAG1ICwRzSAsE VgADYAEAMgBWAAwAAADKZuAAAAAJAEgAZQBhAGQAaQBuAGcAIAAzAAAAEwADABOkZAAUpGQA QCYCWyQBXCQBABYANQiBQ0obAFwIgWFKGwBtSAsEc0gLBE4ABGABAEIATgAMAAAAymbgAAAA CQBIAGUAYQBkAGkAbgBnACAANAAAABMABAATpGQAFKRkAEAmA1skAVwkAQAOADUIgVwIgW1I CwRzSAsEAAAAAAAAAAAAAEQAQUDy/6EARAAMBQAAAAAAAAAAFgBEAGUAZgBhAHUAbAB0ACAA UABhAHIAYQBnAHIAYQBwAGgAIABGAG8AbgB0AAAAAABWAGkA8/+zAFYADAUAAAAAAAAAAAwA VABhAGIAbABlACAATgBvAHIAbQBhAGwAAAAgADpWCwAX9gMAADTWBgABBQMAADTWBgABCgNs AGH2AwAAAgALAAAAKABrAPT/wQAoAAAFAAAAAAAAAAAHAE4AbwAgAEwAaQBzAHQAAAACAAwA AAAAAEoAXmABAPIASgAMAAAAymbgAAAADABOAG8AcgBtAGEAbAAgACgAVwBlAGIAKQAAABAA DwATpGQAFKRkAFskAVwkAQgAbUgLBHNICwRCAP5vogABAUIADAAAAMpm4AAAABUAYQBwAHAA bABlAC0AYwBvAG4AdgBlAHIAdABlAGQALQBzAHAAYQBjAGUAAAAAADQAVWCiABEBNAAMAAAA ymbgAAAACQBIAHkAcABlAHIAbABpAG4AawAAAAkAPioBcGgAAP8AAEIAYmCiACEBQgAMAAAA ymbgAAAACQBIAFQATQBMACAAQwBvAGQAZQAAABgAQ0oUAE9KBABQSgMAUUoEAF5KBABhShQA AAAAAEk9AAAFAABUAAAAAP////8AAAAAHgAAAAsCAAA4AgAANwMAAE8DAABBBQAARAgAADMM AABgDAAA0A4AAA4RAABiEgAAkRIAAH4TAACnEwAAXRcAAIAbAACdGwAA7h0AADMgAABZIAAA qiIAAOQiAAASJgAATCYAALEoAAA5KwAAQysAAOEwAADzMAAAfDQAAK00AABBNwAAwDkAANY5 AACEOgAApToAAPQ6AAAaOwAANzsAAEc7AABjPAAASD0AAEs9AADI0QAwAAAAAAAAAAABAAAA AAAAAAAAAAAAAAAByNEAMAEAAAAAAAAAAQAAAAMAAAAAAAAAAACAAcjRADABAAAAAAAAAAEA AAADAAAAAAAAAAAAgAHI0QAwAQAAAAAAAAABAAAAAwAAAAAAAAAAAIAByNEAMAEAAAAAAAAA AQAAAAMAAAAAAAAAAACAAcjRADABAAAAAAAAAAEAAAADAAAAAAAAAAAAgAHI0QAwAQAAAAAA AAABAAAAAwAAAAAAAAAAAIAByNEAMAEAAAAAAAAAAQAAAAMAAAAAAAAAAACAAcjRADABAAAA AAAAAAEAAAADAAAAAAAAAAAAgAHI0QAwAQAAAAAAAAABAAAAAwAAAAAAAAAAAIAByNEAMAEA AAAAAAAAAQAAAAMAAAAAAAAAAACAAcjRADABAAAAAAAAAAEAAAADAAAAAAAAAAAAgAHI0QAw AQAAAAAAAAABAAAAAwAAAAAAAAAAAIAByNEAMAEAAAAAAAAAAQAAAAMAAAAAAAAAAACAAcjR ADABAAAAAAAAAAEAAAADAAAAAAAAAAAAgAHI0QAwAQAAAAAAAAABAAAAAwAAAAAAAAAAAIAB yNEAMAEAAAAAAAAAAQAAAAMAAAAAAAAAAACAAcjRADABAAAAAAAAAAEAAAADAAAAAAAAAAAA gAHI0QAwAQAAAAAAAAABAAAAAwAAAAAAAAAAAIAByNEAMAEAAAAAAAAAAQAAAAMAAAAAAAAA AACAAcjRADABAAAAAAAAAAEAAAADAAAAAAAAAAAAgAHI0QAwAQAAAAAAAAABAAAAAwAAAAAA AAAAAIAByNEAMAEAAAAAAAAAAQAAAAMAAAAAAAAAAACAAcjRADABAAAAAAAAAAEAAAADAAAA AAAAAAAAgAHI0QAwAQAAAAAAAAABAAAAAwAAAAAAAAAAAIAByNEAMAEAAAAAAAAAAQAAAAMA AAAAAAAAAACAAcjRADABAAAAAAAAAAEAAAADAAAAAAAAAAAAgAHI0QAwAQAAAAAAAAABAAAA AwAAAAAAAAAAAIAByNEAMAEAAAAAAAAAAQAAAAMAAAAAAAAAAACAAcjRADABAAAAAAAAAAEA AAADAAAAAAAAAAAAgAHI0QAwAQAAAAAAAAABAAAAAwAAAAAAAAAAAIAByNEAMAEAAAAAAAAA AQAAAAMAAAAAAAAAAACAAcjRADABAAAAAAAAAAEAAAADAAAAAAAAAAAAgAHI0QAwAQAAAAAA AAABAAAAAwAAAAAAAAAAAIAByNEAMAEAAAAAAAAAAQAAAAMAAAAAAAAAAACAAcjRADABAAAA AAAAAAEAAAADAAAAAAAAAAAAgAHI0QAwAQAAAAAAAAABAAAAAwAAAAAAAAAAAIAByNEAMAEA AAAAAAAAAQAAAAMAAAAAAAAAAACAAcjRADABAAAAAAAAAAEAAAADAAAAAAAAAAAAgAHI0QAw AQAAAAAAAAABAAAAAwAAAAAAAAAAAIAByNEAMAEAAAAAAAAAAQAAAAMAAAAAAAAAAACAAcjR ADABAAAAAAAAAAEAAAADAAAAAAAAAAAAgAHI0QAwAQAAAAAAAAACAAAAAQAAAAAAAAAAAIAB yJEAMAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAQAAAAAeAAAACwIAADgCAAA3AwAATwMAAEEF AABECAAAMwwAAGAMAADQDgAADhEAAGISAACREgAAfhMAAKcTAABdFwAAgBsAAJ0bAADuHQAA MyAAAFkgAACqIgAA5CIAABImAABMJgAAsSgAADkrAABDKwAA4TAAAPMwAAB8NAAArTQAAEE3 AADAOQAA1jkAAIQ6AAClOgAA9DoAABo7AAA3OwAARzsAAGM8AABIPQAASz0AAMrRADAAAAAA AAAAAAEAAAAAAAAAAAAAAAAAfQfK0QAwAAAAAAAAAAABAAAAAAAAAAAAAAAAAH0HytEAMAAA AAAAAAAAAQAAAAAAAAAAAAAAAAB9B8rRADAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAfQfK0QAw AAAAAAAAAAABAAAAAAAAAAAAAAAAAH0HytEAMAAAAAAAAAAAAQAAAAAAAAAAAAAAAAB9B8rR ADAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAfQfK0QAwAAAAAAAAAAABAAAAAAAAAAAAAAAAAH0H ytEAMAAAAAAAAAAAAQAAAAAAAAAAAAAAAAB9B8rRADAAAAAAAAAAAAEAAAAAAAAAAAAAAAAA fQfK0QAwAAAAAAAAAAABAAAAAAAAAAAAAAAAAH0HytEAMAAAAAAAAAAAAQAAAAAAAAAAAAAA AAB9B8rRADAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAfQfK0QAwAAAAAAAAAAABAAAAAAAAAAAA AAAAAH0HytEAMAAAAAAAAAAAAQAAAAAAAAAAAAAAAAB9B8rRADAAAAAAAAAAAAEAAAAAAAAA AAAAAAAAfQfK0QAwAAAAAAAAAAABAAAAAAAAAAAAAAAAAH0HytEAMAAAAAAAAAAAAQAAAAAA AAAAAAAAAAB9B8rRADAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAfQfK0QAwAAAAAAAAAAABAAAA AAAAAAAAAAAAAH0HytEAMAAAAAAAAAAAAQAAAAAAAAAAAAAAAAB9B8rRADAAAAAAAAAAAAEA AAAAAAAAAAAAAAAAfQfK0QAwAAAAAAAAAAABAAAAAAAAAAAAAAAAAH0HytEAMAAAAAAAAAAA AQAAAAAAAAAAAAAAAAB9B8rRADAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAfQfK0QAwAAAAAAAA AAABAAAAAAAAAAAAAAAAAH0HytEAMAAAAAAAAAAAAQAAAAAAAAAAAAAAAAB9B8rRADAAAAAA AAAAAAEAAAAAAAAAAAAAAAAAfQfK0QAwAAAAAAAAAAABAAAAAAAAAAAAAAAAAH0HytEAMAAA AAAAAAAAAQAAAAAAAAAAAAAAAAB9B8rRADAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAfQfK0QAw AAAAAAAAAAABAAAAAAAAAAAAAAAAAH0HytEAMAAAAAAAAAAAAQAAAAAAAAAAAAAAAAB9B8rR ADAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAfQfK0QAwAAAAAAAAAAABAAAAAAAAAAAAAAAAAH0H ytEAMAAAAAAAAAAAAQAAAAAAAAAAAAAAAAB9B8rRADAAAAAAAAAAAAEAAAAAAAAAAAAAAAAA fQfK0QAwAAAAAAAAAAABAAAAAAAAAAAAAAAAAH0HytEAMAAAAAAAAAAAAQAAAAAAAAAAAAAA AAB9B8rRADAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAfQfI0QAwAAAAAAAAAAABAAAAAAAAAAAA AAAAAAAByNEAMAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAcjRADAAAAAAAAAAAAEAAAAAAAAA AAAAAAAAAAEIAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAAAAAABAAYAAHQRAAB2LgAAq0MAAElF AAAjAAAAJgAAACcAAAApAAAAAAYAADkzAABJRQAAJAAAACgAAAAABgAASUUAACUAAAAiAAAA UwAAAF0AAABMJgAAdSYAAIQmAABuNwAAtjcAAMA3AABwOAAAuzgAAM84AABWOwAAqjsAAMA7 AAC4PAAAHT0AAD49AABJPQAAE1gU/xWME1gU/xWME1gU/xWME1gU/xWME1gU/xWME1gU/xWM AAAAACIAAAAjAAAAUwAAAFQAAABdAAAAXgAAAEwmAABNJgAAdSYAAHYmAACEJgAAhSYAAG43 AABvNwAAtjcAALc3AADANwAAwTcAAHA4AABxOAAAuzgAALw4AADPOAAA0DgAAIQ6AAALOwAA EDsAADc7AABGOwAAqzsAALA7AADDOwAAyzsAAMw7AADUOwAASz0AAAQABwAEAAcABAAHAAQA BwAEAAcABAAHAAQABwAEAAcABAAHAAQABwAEAAcABAAHAAQABwAcAAcABQAHABwABwAcAAcA HAAHAAAAAAAeAAAA9wAAAEwmAAAFJwAAQTcAABo5AACEOgAANzsAAEY7AAAePQAAJj0AAEs9 AAAEAAcABAAHAAQABwAEAAcABQAHADMABwAAAAAAhDoAAKU6AAD0OgAARzsAAEs9AAAHAAUA BwAFAAcAAAAAAEs9AAAHAAIAwSpbYSyDEL3/D/8P/w//D/8P/w//D/8P/w8AALxwLWNgBgRj /w//D/8P/w//D/8P/w//D/8PAAABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4TQAhGE mP4VxgUAAdACBl6E0AJghJj+Q0oUAE9KAQBRSgEAbygAAQC38AEAAAAXgAAAAAAAAAAAAAAA AAAAAAAAAA8YAAAPhKAFEYSY/hXGBQABoAUGXoSgBWCEmP5DShQAT0oEAFFKBABvKAABAG8A AQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EcAgRhJj+FcYFAAFwCAZehHAIYISY/kNK FABPSgUAUUoFAG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4RACxGEmP4V xgUAAUALBl6EQAtghJj+Q0oUAE9KBQBRSgUAbygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAA AAAAAA8YAAAPhBAOEYSY/hXGBQABEA4GXoQQDmCEmP5DShQAT0oFAFFKBQBvKAABAKfwAQAA ABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+E4BARhJj+FcYFAAHgEAZehOAQYISY/kNKFABP SgUAUUoFAG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4SwExGEmP4VxgUA AbATBl6EsBNghJj+Q0oUAE9KBQBRSgUAbygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAA AA8YAAAPhIAWEYSY/hXGBQABgBYGXoSAFmCEmP5DShQAT0oFAFFKBQBvKAABAKfwAQAAABeA AAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EUBkRhJj+FcYFAAFQGQZehFAZYISY/kNKFABPSgUA UUoFAG8oAAEAp/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4TQAhGEmP4VxgUAAdAC Bl6E0AJghJj+Q0oUAE9KAQBRSgEAbygAAQC38AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAA8Y AAAPhKAFEYSY/hXGBQABoAUGXoSgBWCEmP5DShQAT0oEAFFKBABvKAABAG8AAQAAABeAAAAA AAAAAAAAAAAAAAAAAAAADxgAAA+EcAgRhJj+FcYFAAFwCAZehHAIYISY/kNKFABPSgUAUUoF AG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4RACxGEmP4VxgUAAUALBl6E QAtghJj+Q0oUAE9KBQBRSgUAbygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAP hBAOEYSY/hXGBQABEA4GXoQQDmCEmP5DShQAT0oFAFFKBQBvKAABAKfwAQAAABeAAAAAAAAA AAAAAAAAAAAAAAAADxgAAA+E4BARhJj+FcYFAAHgEAZehOAQYISY/kNKFABPSgUAUUoFAG8o AAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4SwExGEmP4VxgUAAbATBl6EsBNg hJj+Q0oUAE9KBQBRSgUAbygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhIAW EYSY/hXGBQABgBYGXoSAFmCEmP5DShQAT0oFAFFKBQBvKAABAKfwAQAAABeAAAAAAAAAAAAA AAAAAAAAAAAADxgAAA+EUBkRhJj+FcYFAAFQGQZehFAZYISY/kNKFABPSgUAUUoFAG8oAAEA p/ACAAAAwSpbYQAAAAAAAAAAAAAAALxwLWMAAAAAAAAAAAAAAAD/////////////AgAAAAAA AAD//wIAAAAAAAAAAQCsD9t5AAAAAAAAAAAAAQIAAgABAAAABAAAAAgAAADlAAAAAAAAAAAA AADKZuAA/0ADgAEASD0AAEg9AAAEYAIFAQABAEg9AAAAAAAASD0AAAAAAAACEAAAAAAAAABJ PQAAUAAAEABAAAD//wEAAAAHAFUAbgBrAG4AbwB3AG4A//8BAAgAAAAAAAAAAAAAAP//AQAA AAAA//8AAAIA//8AAAAA//8AAAIA//8AAAAABgAAAEcWkAEAAAICBgMFBAUCAwT/OgDgQXgA wAkAAAAAAAAA/wEAAAAAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAADUWkAEC AAUFAQIBBwYCBQcAAAAAAAAAEAAAAAAAAAAAAAAAgAAAAABTAHkAbQBiAG8AbAAAADMmkAEA AAILBgQCAgICAgT/OgDgQ3gAwAkAAAAAAAAA/wEAAAAAAABBAHIAaQBhAGwAAAA7FpABgQcC AwYAAAEBAQEBrwIAsPt812kwAAAAAAAAAJ8ACAAAAAAAQgBhAHQAYQBuAGcAAAAUvNXQAAA/ NZABAAACBwMJAgIFAgQE/zoA4EN4AMAJAAAAAAAAAP8BAAAAAAAAQwBvAHUAcgBpAGUAcgAg AE4AZQB3AAAAOwaQAQIABQAAAAAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAAACAAAAAAFcAaQBu AGcAZABpAG4AZwBzAAAAIgAEAHEIiBgA8BgFAACpAQAAAAB7hCqHiYQqhwAAAAABAAoAAAC8 BgAAjTYAAAEAHwAAAAQAAxB0AAAAvAYAAI02AAABAB8AAAB0AAAAAAAAACEDAPAQAAAAAQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAG4EiQW0ALQAgYEyNAAAAAAA AAAAAAAAAAAAKj0AACo9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAAATKDEQDwEAAI3AMAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAABIWAAAAAAp8P8PAQABPwAA5AQAAP///3////9/////f////3// //9/////f////3/KZuAAAAAAADIAAAAAAAAAAAAAAAAAAAAAAP//EgAAAAAAAAAbAEEAdQB0 AGgAZQBuAHQAaQBjAGEAdABpAG8AbgAgAHcAaQB0AGgAIABPAEEAdQB0AGgAIAAyAAAAAAAA AAcAVABzAGMAaABvAGYAZQAHAFQAcwBjAGgAbwBmAGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAU AAAABgAAAAIAAAAAAAwAAQAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAD+/wAABgECAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCrkQgA Kyez2TAAAACAAQAAEQAAAAEAAACQAAAAAgAAAJgAAAADAAAAvAAAAAQAAADIAAAABQAAANgA AAAGAAAA5AAAAAcAAADwAAAACAAAAAABAAAJAAAAEAEAABIAAAAcAQAACgAAADwBAAAMAAAA SAEAAA0AAABUAQAADgAAAGABAAAPAAAAaAEAABAAAABwAQAAEwAAAHgBAAACAAAA5AQAAB4A AAAcAAAAQXV0aGVudGljYXRpb24gd2l0aCBPQXV0aCAyAB4AAAAEAAAAAAAAAB4AAAAIAAAA VHNjaG9mZQAeAAAABAAAAAAAAAAeAAAABAAAAAAAAAAeAAAACAAAAE5vcm1hbAAAHgAAAAgA AABUc2Nob2ZlAB4AAAAEAAAAMQAAAB4AAAAYAAAATWljcm9zb2Z0IE9mZmljZSBXb3JkAAAA QAAAAAC8oGUBAAAAQAAAAAD6bRla6c8BQAAAAAC2Dn9b6c8BAwAAAAEAAAADAAAAvAYAAAMA AACNNgAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA/v8AAAYBAgAAAAAAAAAAAAAAAAAAAAAAAgAAAALVzdWcLhsQk5cIACss+a5EAAAA BdXN1ZwuGxCTlwgAKyz5rkgBAAAEAQAADAAAAAEAAABoAAAADwAAAHAAAAAFAAAAfAAAAAYA AACEAAAAEQAAAIwAAAAXAAAAlAAAAAsAAACcAAAAEAAAAKQAAAATAAAArAAAABYAAAC0AAAA DQAAALwAAAAMAAAA5AAAAAIAAADkBAAAHgAAAAQAAAAAAAAAAwAAAHQAAAADAAAAHwAAAAMA AAAqPQAAAwAAAA8nCwALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAABAAAA HAAAAEF1dGhlbnRpY2F0aW9uIHdpdGggT0F1dGggMgAMEAAAAgAAAB4AAAAGAAAAVGl0bGUA AwAAAAEAAAAAADAEAAADAAAAAAAAACAAAAABAAAAOAAAAAIAAABAAAAAAQAAAAIAAAAMAAAA X1BJRF9ITElOS1MAAgAAAOQEAABBAAAA6AMAACQAAAADAAAAfQA2AAMAAAAPAAAAAwAAAAAA AAADAAAABQAAAB8AAABXAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAHMAbABpAGQAZQBzAGgA YQByAGUALgBuAGUAdAAvAHoAZQByAG8AbgBpAG4AZQAxAC8AYQB1AHQAaAAtAGkAbgAtAHQA aABlAC0AZQB4AHQAZQBuAGQAZQBkAC0AZQBuAHQAZQByAHAAcgBpAHMAZQAtAG0AaQB0AC0A aABhAGMAawBhAHQAaABvAG4ALQAyADAAMQAzAAAAAAAfAAAAAQAAAAAAEQoDAAAAGgBNAAMA AAAMAAAAAwAAAAAAAAADAAAABQAAAB8AAABGAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGMA bABvAHUAZABpAGQAZQBuAHQAaQB0AHkALgBjAG8AbQAvAGIAbABvAGcALwAyADAAMQAzAC8A MAAxAC8AMAAyAC8AbwBhAHUAdABoAC0AMgAtADAALQBhAG4AZAAtAHMAaQBnAG4ALQBpAG4A LQA0AC8AAAAfAAAAAQAAAAAAEQoDAAAAFwA9AAMAAAAJAAAAAwAAAAAAAAADAAAABQAAAB8A AAA9AAAAaAB0AHQAcAA6AC8ALwBvAHAAZQBuAGkAZAAuAG4AZQB0AC8AcwBwAGUAYwBzAC8A bwBwAGUAbgBpAGQALQBjAG8AbgBuAGUAYwB0AC0AcgBlAGcAaQBzAHQAcgBhAHQAaQBvAG4A LQAxAF8AMAAuAGgAdABtAGwAAAAAAB8AAAABAAAAAAARCgMAAAArABYAAwAAAAYAAAADAAAA AAAAAAMAAAAFAAAAHwAAADoAAABoAHQAdABwADoALwAvAG8AcABlAG4AaQBkAC4AbgBlAHQA LwBzAHAAZQBjAHMALwBvAHAAZQBuAGkAZAAtAGMAbwBuAG4AZQBjAHQALQBkAGkAcwBjAG8A dgBlAHIAeQAtADEAXwAwAC4AaAB0AG0AbAAAAB8AAAABAAAAAAARCgMAAAB1AGEAAwAAAAMA AAADAAAAAAAAAAMAAAAFAAAAHwAAABsAAABoAHQAdABwADoALwAvAG8AcABlAG4AaQBkAC4A bgBlAHQALwBjAG8AbgBuAGUAYwB0AC8AAAAAAB8AAAABAAAAAAARCgMAAABhACoAAwAAAAAA AAADAAAAAAAAAAMAAAAFAAAAHwAAACMAAABoAHQAdABwADoALwAvAHQAbwBvAGwAcwAuAGkA ZQB0AGYALgBvAHIAZwAvAGgAdABtAGwALwByAGYAYwA2ADcANAA5AAAAAAAfAAAAAQAAAAAA EQoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEA AAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0AAAAOAAAA DwAAABAAAAARAAAAEgAAABMAAAAUAAAAFQAAABYAAAAXAAAAGAAAABkAAAAaAAAAGwAAABwA AAAdAAAAHgAAAB8AAAAgAAAAIQAAACIAAAAjAAAAJAAAACUAAAAmAAAAJwAAACgAAAApAAAA KgAAAP7///8sAAAALQAAAC4AAAAvAAAAMAAAADEAAAAyAAAA/v///zQAAAA1AAAANgAAADcA AAA4AAAAOQAAADoAAAA7AAAAPAAAAD0AAAA+AAAAPwAAAEAAAABBAAAA/v///0MAAABEAAAA RQAAAEYAAABHAAAASAAAAEkAAAD+////SwAAAEwAAABNAAAATgAAAE8AAABQAAAAUQAAAP7/ ///9////VAAAAP7////+/////v////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////UgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYABQH//////////wMAAAAGCQIA AAAAAMAAAAAAAABGAAAAAAAAAAAAAAAAAJdQolvpzwFWAAAAgAAAAAAAAABEAGEAdABhAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA CgACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACsA AAAAEAAAAAAAADEAVABhAGIAbABlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAOAAIBAQAAAAYAAAD/////AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAMwAAAGMdAAAAAAAAVwBvAHIAZABEAG8AYwB1AG0AZQBuAHQA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAgECAAAABQAAAP// //8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALlQAAAAAAAAFAFMA dQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAKAACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAEIAAAAAEAAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYA bwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIBBAAAAP//////////AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASgAAAAAQAAAAAAAAAQBDAG8AbQBwAE8AYgBqAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgD///// //////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAD+//////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////AQD+/wMK AAD/////BgkCAAAAAADAAAAAAAAARh8AAABNaWNyb3NvZnQgT2ZmaWNlIFdvcmQgRG9jdW1l bnQACgAAAE1TV29yZERvYwAQAAAAV29yZC5Eb2N1bWVudC44APQ5snEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAA= --------------080201090208040905040500 Content-Type: text/html; name="Authentication with OAuth 2.html" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Authentication with OAuth 2.html" CjwhLS0gc2F2ZWQgZnJvbSB1cmw9KDAwMzApZmlsZTovLy9GOi9hdXRoZW50aWNhdGlvbi5o dG1sIC0tPgo8aHRtbD48aGVhZD48bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNv bnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1JU08tODg1OS0xIj48L2hlYWQ+PGJvZHkgY2xh c3M9IiZsdDs/cGhwIGVjaG8gJHBhZ2Vfc2VjdGlvbjsgPyZndDsiPgogICAgPGRpdiBjbGFz cz0iY29udGFpbmVyIj4KICAgICAgICA8ZGl2IGlkPSJoZWFkZXIiIGNsYXNzPSJjb2x1bW4g Zmlyc3QgbGFzdCBzcGFuLTIwIj4KICAgICAgICAgICAgPGgxIGlkPSJzaXRlLW5hbWUiIGNs YXNzPSJjb2x1bW4gZmlyc3Qgc3Bhbi01IHByZXBlbmQtMSBhcHBlbmQtMSI+PGEgaHJlZj0i ZmlsZTovLy9GOi8iPk9BdXRoPC9hPjwvaDE+CiAgICAgICAgICAgIDxkaXYgaWQ9InByaW1h cnkiIGNsYXNzPSJjb2x1bW4gc3Bhbi0xMyBsYXN0Ij4KCiAgICAgICAgICAgICAgICA8IS0t P3BocCByZXF1aXJlKCcuLi9pbmNsdWRlcy9fbmF2X3ByaW1hcnkucGhwJyk7ID8tLT4KCiAg ICAgICAgICAgIDwvZGl2PgogICAgICAgICAgICA8ZGl2IGlkPSJzZWNvbmRhcnkiIGNsYXNz PSJjb2x1bW4gc3Bhbi0xOCBhcHBlbmQtMSBwcmVwZW5kLTEgZmlyc3QgbGFzdCI+CgogICAg ICAgICAgICA8L2Rpdj4KICAgICAgICA8L2Rpdj4KCiAgICAgICAgPGRpdiBpZD0ibWFpbiIg Y2xhc3M9ImNvbHVtbiBmaXJzdCBsYXN0IHNwYW4tMTggcHJlcGVuZC0xIGFwcGVuZC0xIj4K ICAgICAgICAgICAgPGgyIGlkPSJvYXV0aC0yLjAtYXV0aGVudGljYXRpb24iPkF1dGhlbnRp Y2F0aW9uIHdpdGggT0F1dGggMi4wPC9oMj4KCQkJCiAgICAgICAgICAgIDxwPlRoZSA8YSBo cmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2NzQ5Ij5PQXV0aCAyLjA8L2E+ IHNwZWNpZmljYXRpb24gZGVmaW5lcyBhIDxpPmRlbGVnYXRpb248L2k+IHByb3RvY29sIHRo YXQgaXMgdXNlZnVsIGZvciBjb252ZXlpbmcgPGk+YXV0aG9yaXphdGlvbiBkZWNpc2lvbnM8 L2k+IGFjcm9zcyBhIG5ldHdvcmsgb2Ygd2ViLWVuYWJsZWQgYXBwbGljYXRpb25zIGFuZCBB UElzLiBPQXV0aCBpcyB1c2VkIGluIGEgd2lkZSB2YXJpZXR5IG9mIGFwcGxpY2F0aW9ucywg aW5jbHVkaW5nIHByb3ZpZGluZyBtZWNoYW5pc21zIGZvciB1c2VyIGF1dGhlbnRpY2F0aW9u LiBUaGlzIGhhcyBsZWFkIG1hbnkgZGV2ZWxvcGVycyB0byBpbmNvcnJlY3RseSBjb25jbHVk ZSB0aGF0IE9BdXRoIGlzIGl0c2VsZiBhbiA8aT5hdXRoZW50aWNhdGlvbjwvaT4gcHJvdG9j b2wgYW5kIHRvIG1pc3Rha2VubHkgdXNlIGl0IGFzIHN1Y2guIExldCdzIHNheSB0aGF0IGFn YWluLCB0byBiZSBjbGVhcjo8L3A+CgkJCQoJCQk8cD48Yj5PQXV0aCAyLjAgaXMgbm90IGFu IGF1dGhlbnRpY2F0aW9uIHByb3RvY29sLjwvYj48L3A+CgkJCQoJCQk8cD5NdWNoIG9mIHRo ZSBjb25mdXNpb24gY29tZXMgZnJvbSB0aGUgZmFjdCB0aGF0IE9BdXRoIGlzIHVzZWQgPGk+ aW5zaWRlPC9pPiBvZiBhdXRoZW50aWNhdGlvbiBwcm90b2NvbHMsIGFuZCBkZXZlbG9wZXJz IHdpbGwgc2VlIHRoZSBPQXV0aCBjb21wb25lbnRzIGFuZCBpbnRlcmFjdCB3aXRoIHRoZSBP QXV0aCBmbG93IGFuZCBhc3N1bWUgdGhhdCBieSBzaW1wbHkgdXNpbmcgT0F1dGgsIHRoZXkg Y2FuIGFjY29tcGxpc2ggdXNlciBhdXRoZW50aWNhdGlvbi48L3A+CgoKCQkJPGg0IGlkPSJ3 aGF0LWlzLWF1dGhuIj5XaGF0IGlzIGF1dGhlbnRpY2F0aW9uPzwvaDQ+CgkJCQoJCQk8cD48 Yj5BdXRoZW50aWNhdGlvbjwvYj4gdGVsbHMgYW4gYXBwbGljYXRpb24gPGk+d2hvIHRoZSBj dXJyZW50IHVzZXIgaXM8L2k+IGFuZCB3aGV0aGVyIG9yIG5vdCB0aGV5J3JlIHByZXNlbnQu IEEgZnVsbCBhdXRoZW50aWNhdGlvbiBwcm90b2NvbCB3aWxsIHByb2JhYmx5IGFsc28gdGVs bCB5b3UgYSBudW1iZXIgb2YgPGk+YXR0cmlidXRlczwvaT4gYWJvdXQgdGhpcyB1c2VyLCBz dWNoIGFzIGEgdW5pcXVlIGlkZW50aWZpZXIsIGFuIGVtYWlsIGFkZHJlc3MsIGFuZCB3aGF0 IHRvIGNhbGwgdGhlbSB3aGVuIHRoZSBhcHBsaWNhdGlvbiBzYXlzICJHb29kIE1vcm5pbmci LiBBdXRoZW50aWNhdGlvbiBpcyBhbGwgYWJvdXQgdGhlIHVzZXIgYW5kIHRoZWlyIHByZXNl bmNlIHdpdGggdGhlIGFwcGxpY2F0aW9uLCBhbmQgYW4gaW50ZXJuZXQtc2NhbGUgYXV0aGVu dGljYXRpb24gcHJvdG9jb2wgbmVlZHMgdG8gYmUgYWJsZSB0byBkbyB0aGlzIGFjcm9zcyBu ZXR3b3JrIGFuZCBzZWN1cml0eSBib3VuZGFyaWVzLjwvcD4KCQkJCgkJCTxwPkhvd2V2ZXIs IE9BdXRoIHRlbGxzIHRoZSBhcHBsaWNhdGlvbiBub25lIG9mIHRoYXQuIE9BdXRoIHNheXMg YWJzb2x1dGVseSBub3RoaW5nIGFib3V0IHRoZSB1c2VyLCBub3IgZG9lcyBpdCBzYXkgaG93 IHRoZSB1c2VyIHByb3ZlZCB0aGVpciBwcmVzZW5jZSBvciBldmVuIGlmIHRoZXkncmUgc3Rp bGwgdGhlcmUuIEFzIGZhciBhcyBhbiBPQXV0aCBjbGllbnQgaXMgY29uY2VybmVkLCBpdCBh c2tlZCBmb3IgYSB0b2tlbiwgZ290IGEgdG9rZW4sIGFuZCBldmVudHVhbGx5IHVzZWQgdGhh dCB0b2tlbiB0byBhY2Nlc3Mgc29tZSBBUEkuIEl0IGRvZXNuJ3Qga25vdyBhbnl0aGluZyBh Ym91dCB3aG8gYXV0aG9yaXplZCB0aGUgYXBwbGljYXRpb24gb3IgaWYgdGhlcmUgd2FzIGV2 ZW4gYSB1c2VyIHRoZXJlIGF0IGFsbC4gSW4gZmFjdCwgbXVjaCBvZiB0aGUgcG9pbnQgb2Yg T0F1dGggaXMgYWJvdXQgZ2l2aW5nIHRoaXMgZGVsZWdhdGVkIGFjY2VzcyBmb3IgdXNlIGlu IHNpdHVhdGlvbnMgd2hlcmUgdGhlIDxpPnVzZXIgaXMgbm90IHByZXNlbnQ8L2k+IG9uIHRo ZSBjb25uZWN0aW9uIGJldHdlZW4gdGhlIGNsaWVudCBhbmQgdGhlIHJlc291cmNlIGJlaW5n IGFjY2Vzc2VkLiBUaGlzIGlzIGdyZWF0IGZvciBjbGllbnQgYXV0aG9yaXphdGlvbiwgYnV0 IGl0J3MgcmVhbGx5IGJhZCBmb3IgYXV0aGVudGljYXRpb24gd2hlcmUgdGhlIHdob2xlIHBv aW50IGlzIGZpZ3VyaW5nIG91dCBpZiB0aGUgdXNlciBpcyB0aGVyZSBvciBub3QgKGFuZCB3 aG8gdGhleSBhcmUpLjwvcD4KCQkJCgkJCTxwPkFzIGl0IHR1cm5zIG91dCwgdGhvdWdoLCB0 aGVyZSBhcmUgYSBoYW5kZnVsIG9mIHRoaW5ncyB0aGF0IGNhbiBiZSB1c2VkIGFsb25nIHdp dGggT0F1dGggdG8gPGk+Y3JlYXRlPC9pPiBhbiBhdXRoZW50aWNhdGlvbiBhbmQgaWRlbnRp dHkgcHJvdG9jb2wgb24gdG9wIG9mIHRoaXMgZGVsZWdhdGlvbiBhbmQgYXV0aG9yaXphdGlv biBwcm90b2NvbC4gSW4gbmVhcmx5IGFsbCBvZiB0aGVzZSBjYXNlcywgdGhlIGNvcmUgZnVu Y3Rpb25hbGl0eSBvZiBPQXV0aCByZW1haW5zIGFuZCB3aGF0J3MgaGFwcGVuaW5nIGlzIHRo YXQgdGhlIHVzZXIgaXMgPGk+ZGVsZWdhdGluZyBhY2Nlc3MgdG8gdGhlaXIgaWRlbnRpdHk8 L2k+IHRvIHRoZSBhcHBsaWNhdGlvbi4gVGhlIGNsaWVudCBhcHBsaWNhdGlvbiB0aGVuIGJl Y29tZXMgYSBjb25zdW1lciBvZiB0aGUgaWRlbnRpdHkgQVBJLCB0aGVyZWJ5IGZpbmRpbmcg b3V0IHdobyBhdXRoZW50aWNhdGVkIHRoZSBjbGllbnQgaW4gdGhlIGZpcnN0IHBsYWNlLiBP bmUgbWFqb3IgYmVuZWZpdCBvZiB0aGlzIGFwcHJvYWNoIGlzIHRoYXQgdGhlIHVzZXIgY2Fu IGRlbGVnYXRlIGFjY2VzcyB0byBvdGhlciBwcm90ZWN0ZWQgQVBJcyA8aT5hbG9uZyBzaWRl PC9pPiB0aGVpciBpZGVudGl0eSBhdCB0aGUgc2FtZSB0aW1lLCBtYWtpbmcgaXQgbXVjaCBz aW1wbGVyIGZvciBib3RoIGFwcGxpY2F0aW9uIGRldmVsb3BlcnMgYW5kIGVuZCB1c2VycyB0 byBtYW5hZ2UuIFdpdGggb25lIGNhbGwsIGFuIGFwcGxpY2F0aW9uIGNhbiBmaW5kIG91dCBp ZiBhIHVzZXIgaXMgbG9nZ2VkIGluLCB3aGF0IHRoZSBhcHAgc2hvdWxkIGNhbGwgdGhlIHVz ZXIsIGRvd25sb2FkIHBob3RvcyBmb3IgcHJpbnRpbmcsIGFuZCBwb3N0IHVwZGF0ZXMgdG8g dGhlaXIgbWVzc2FnZSBzdHJlYW0uIFRoaXMgc2ltcGxpY2l0eSBpcyB2ZXJ5IGNvbXBlbGxp bmcsIGJ1dCBieSBkb2luZyBib3RoIGF0IHRoZSBzYW1lIHRpbWUsIG1hbnkgZGV2ZWxvcGVy cyBjb25mbGF0ZSB0aGUgdHdvIGZ1bmN0aW9ucy48L3A+CgoKICAgICAgICAgICAgPGg0IGlk PSJjaG9jb2xhdGUtdnMtZnVkZ2UiPkF1dGhlbnRpY2F0aW9uIHZzLiBBdXRob3JpemF0aW9u OiBhIG1ldGFwaG9yPC9oND4KCQkJCgkJCTxwPlRvIGhlbHAgY2xlYXIgdGhpbmdzIHVwLCBp dCBtYXkgYmUgaGVscGZ1bCB0byB0aGluayBvZiB0aGUgcHJvYmxlbSBpbiB0ZXJtcyBvZiBh IG1ldGFwaG9yOiBjaG9jb2xhdGUgdnMuIGZ1ZGdlLiBGcm9tIHRoZSBzdGFydCwgdGhlIG5h dHVyZSBvZiB0aGVzZSB0d28gdGhpbmdzIGlzIHF1aXRlIGRpZmZlcmVudDogY2hvY29sYXRl IGlzIGFuIGluZ3JlZGllbnQsIGZ1ZGdlIGlzIGEgY29uZmVjdGlvbi4gQ2hvY29sYXRlIGNh biBiZSB1c2VkIHRvIG1ha2UgbWFueSBkaWZmZXJlbnQgdGhpbmdzLCBhbmQgaXQgY2FuIGV2 ZW4gYmUgdXNlZCBvbiBpdHMgb3duLiBGdWRnZSBjYW4gYmUgbWFkZSBvdXQgb2YgbWFueSBk aWZmZXJlbnQgdGhpbmdzLCBhbmQgb25lIG9mIHRob3NlIHRoaW5ncyA8aT5taWdodDwvaT4g YmUgY2hvY29sYXRlLCBidXQgaXQgdGFrZXMgbW9yZSB0aGFuIG9uZSBpbmdyZWRpZW50IHRv IG1ha2UgZnVkZ2UgaGFwcGVuIGFuZCBpdCBtaWdodCBub3QgZXZlbiBpbnZvbHZlIGNob2Nv bGF0ZS4gQXMgc3VjaCwgaXQncyBpbmNvcnJlY3QgdG8gc2F5IHRoYXQgPGk+Y2hvY29sYXRl PC9pPiBlcXVhbHMgPGk+ZnVkZ2U8L2k+LCBvciBldmVuIHRvIHNheSB0aGF0IDxpPmNob2Nv bGF0ZTwvaT4gZXF1YWxzIDxpPmNob2NvbGF0ZSBmdWRnZTwvaT4uPC9wPgoJCQkKCQkJPHA+ T0F1dGgsIGluIHRoaXMgbWV0YXBob3IsIGlzIGNob2NvbGF0ZS4gSXQncyBhIHZlcnNhdGls ZSBpbmdyZWRpZW50IHRoYXQgaXMgZnVuZGFtZW50YWwgdG8gYSBudW1iZXIgb2YgZGlmZmVy ZW50IHRoaW5ncyBhbmQgY2FuIGV2ZW4gYmUgdXNlZCBvbiBpdHMgb3duIHRvIGdyZWF0IGVm ZmVjdC4gQXV0aGVudGljYXRpb24gaXMgbW9yZSBsaWtlIGZ1ZGdlLiBUaGVyZSBhcmUgYXQg bGVhc3QgYSBmZXcgaW5ncmVkaWVudHMgdGhhdCBtdXN0IGJyb3VnaHQgdG9nZXRoZXIgaW4g dGhlIHJpZ2h0IHdheSB0byBtYWtlIGl0IHdvcmssIGFuZCBPQXV0aCBjYW4gYmUgb25lIG9m IHRoZXNlIGluZ3JlZGllbnRzIChwZXJoYXBzIHRoZSBtYWluIGluZ3JlZGllbnQpIGJ1dCBp dCBkb2Vzbid0IGhhdmUgdG8gYmUgaW52b2x2ZWQgYXQgYWxsLiBZb3UgbmVlZCBhIHJlY2lw ZSB0aGF0IHNheXMgd2hhdCB0byBjb21iaW5lIGFuZCBob3cgdG8gY29tYmluZSB0aGVtLCBh bmQgdGhlcmUgYXJlIGEgbGFyZ2UgbnVtYmVyIG9mIGRpZmZlcmVudCByZWNpcGVzIHRoYXQg c2F5IGhvdyB0aGF0IGNhbiBiZSBhY2NvbXBsaXNoZWQuPC9wPgoJCQkKCQkJPHA+QW5kIGlu IGZhY3QsIHRoZXJlIGFyZSBhIG51bWJlciBvZiB3ZWxsLWtub3duIHJlY2lwZXMgb3V0IHRo ZXJlIGZvciBkb2luZyB0aGlzIHdpdGggc3BlY2lmaWMgcHJvdmlkZXJzLCBsaWtlIEZhY2Vi b29rIENvbm5lY3QsIFNpZ24gSW4gV2l0aCBUd2l0dGVyLCBhbmQgT3BlbklEIENvbm5lY3Qg KHdoaWNoIHBvd2VycyBHb29nbGUncyBzaWduLWluIHN5c3RlbSwgYW1vbmcgb3RoZXJzKS4g VGhlc2UgcmVjaXBlcyBlYWNoIGFkZCBhIG51bWJlciBvZiBpdGVtcywgc3VjaCBhcyBhIGNv bW1vbiBwcm9maWxlIEFQSSwgdG8gT0F1dGggdG8gY3JlYXRlIGFuIGF1dGhvcml6YXRpb24g cHJvdG9jb2wuPC9wPgoJCQkKCQkJCiAgICAgICAgICAgIDxoMyBpZD0iY29tbW9uLXBpdGZh bGxzIj5Db21tb24gcGl0ZmFsbHMgZm9yIGF1dGhlbnRpY2F0aW9uIHVzaW5nIE9BdXRoPC9o Mz4KCQkJCgkJCTxwPkV2ZW4gdGhvdWdoIGl0J3MgdmVyeSBwb3NzaWJsZSB0byB1c2UgT0F1 dGggdG8gYnVpbGQgYW4gYXV0aGVudGljYXRpb24gcHJvdG9jb2wsIHRoZXJlIGFyZSBhIG51 bWJlciBvZiB0aGluZ3MgdGhhdCB0ZW5kIHRvIHRyaXAgdXAgdGhvc2Ugd2hvIHdobyBkbyBz bywgZWl0aGVyIG9uIHRoZSBzaWRlIG9mIHRoZSBpZGVudGl0eSBwcm92aWRlciBvciBvbiB0 aGUgc2lkZSBvZiB0aGUgaWRlbnRpdHkgY29uc3VtZXIuPC9wPgoJCQkKCQkJPGg0IGlkPSJh Y2Nlc3MtdG9rZW5zIj5BY2Nlc3MgdG9rZW5zIGFzIHByb29mIG9mIGF1dGhlbnRpY2F0aW9u PC9oND4KCQkJCgkJCTxwPlNpbmNlIHRoZSBhY2Nlc3MgdG9rZW4gY2FuIGJlIHRyYWRlZCBm b3IgYSBzZXQgb2YgdXNlciBhdHRyaWJ1dGVzLCBpdCBpcyB0ZW1wdGluZyB0byB0aGluayB0 aGF0IHBvc2Vzc2lvbiBvZiBhIHZhbGlkIGFjY2VzcyB0b2tlbiBpcyBlbm91Z2ggdG8gcHJv dmUgdGhhdCBhIHVzZXIgaXMgYXV0aGVudGljYXRlZC4gVGhpcyBhc3N1bXB0aW9uIHR1cm5z IG91dCB0byBiZSB0cnVlIGluIHNvbWUgY2FzZXMsIHdoZXJlIHRoZSB0b2tlbiB3YXMgZnJl c2hseSBtaW50ZWQgaW4gdGhlIGNvbnRleHQgb2YgYSB1c2VyIGJlaW5nIGF1dGhlbnRpY2F0 ZWQgYXQgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLiBIb3dldmVyLCB0aGF0J3Mgbm90IHRo ZSBvbmx5IHdheSB0byBnZXQgYW4gYWNjZXNzIHRva2VuIGluIE9BdXRoLiBSZWZyZXNoIHRv a2VucyBhbmQgYXNzZXJ0aW9ucyBjYW4gYmUgdXNlZCB0byBnZXQgYWNjZXNzIHRva2VucyB3 aXRob3V0IHRoZSB1c2VyIGJlaW5nIHByZXNlbnQsIGFuZCBpbiBzb21lIGNhc2VzIGFjY2Vz cyBncmFudHMgY2FuIG9jY3VyIHdpdGhvdXQgdGhlIHVzZXIgaGF2aW5nIHRvIGF1dGhlbnRp Y2F0ZSBhdCBhbGwuIEZ1cnRoZXJtb3JlLCB0aGUgYWNjZXNzIHRva2VuIHdpbGwgZ2VuZXJh bGx5IGJlIHVzYWJsZSBsb25nIGFmdGVyIHRoZSB1c2VyIGlzIG5vIGxvbmdlciBwcmVzZW50 LiBUaGlzIG1lYW5zIHRoYXQgaWYgYSBjbGllbnQgd2FudHMgdG8gbWFrZSBzdXJlIHRoYXQg YW4gYXV0aGVudGljYXRpb24gaXMgc3RpbGwgdmFsaWQsIGl0J3Mgbm90IHN1ZmZpY2llbnQg dG8gc2ltcGx5IHRyYWRlIHRoZSB0b2tlbiBmb3IgdGhlIHVzZXIncyBhdHRyaWJ1dGVzIGFn YWluIGJlY2F1c2UgdGhlIE9BdXRoIHByb3RlY3RlZCByZXNvdXJjZSwgdGhlIGlkZW50aXR5 IEFQSSwgaGFzIG5vIHdheSBvZiByZS1hdXRoZW50aWNhdGluZyB0aGUgdXNlci48L3A+CgkJ CQoJCQk8cD5UaGlzIHByb2JsZW0gc3RlbXMgZnJvbSB0aGUgZmFjdCB0aGF0IHRoZSBjbGll bnQgaXMgbm90IHRoZSA8aT5hdWRpZW5jZTwvaT4gb2YgdGhlIE9BdXRoIGFjY2VzcyB0b2tl bi4gSW5zdGVhZCwgaXQgaXMgdGhlIDxpPmF1dGhvcml6ZWQgcHJlc2VudGVyPC9pPiBvZiB0 aGF0IHRva2VuLCBhbmQgdGhlIDxpPmF1ZGllbmNlPC9pPiBpcyBpbiBmYWN0IHRoZSBwcm90 ZWN0ZWQgcmVzb3VyY2UuIFRoZSBwcm90ZWN0ZWQgcmVzb3VyY2UgaXMgbm90IGdlbmVyYWxs eSBnb2luZyB0byBiZSBpbiBhIHBvc2l0aW9uIHRvIHRlbGwgaWYgdGhlIHVzZXIgaXMgc3Rp bGwgcHJlc2VudCBieSB0aGUgdG9rZW4gYWxvbmUsIHNpbmNlIGJ5IHRoZSB2ZXJ5IG5hdHVy ZSBhbmQgZGVzaWduIG9mIHRoZSBPQXV0aCBwcm90b2NvbCB0aGUgdXNlciB3aWxsIG5vdCBi ZSBhdmFpbGFibGUgb24gdGhlIGNvbm5lY3Rpb24gYmV0d2VlbiB0aGUgY2xpZW50IGFuZCBw cm90ZWN0ZWQgcmVzb3VyY2UuIFRvIGNvdW50ZXIgdGhpcywgdGhlcmUgbmVlZHMgdG8gYmUg YW4gYXJ0aWZhY3QgdGhhdCBpcyBkaXJlY3RlZCBhdCB0aGUgY2xpZW50IGl0c2VsZi4gVGhp cyBjb3VsZCBiZSBkb25lIGJ5IGR1YWwtcHVycG9zaW5nIHRoZSBhY2Nlc3MgdG9rZW4sIGRl ZmluaW5nIGEgZm9ybWF0IHRoYXQgdGhlIGNsaWVudCBjb3VsZCBwYXJzZSBhbmQgdW5kZXJz dGFuZC4gSG93ZXZlciwgc2luY2UgZ2VuZXJhbCBPQXV0aCBkb2VzIG5vdCBkZWZpbmUgYSBz cGVjaWZpYyBmb3JtYXQgb3Igc3RydWN0dXJlIGZvciB0aGUgYWNjZXNzIHRva2VuIGl0c2Vs ZiwgcHJvdG9jb2xzIGxpa2UgT3BlbklEIENvbm5lY3QgYW5kIEZhY2Vib29rIENvbm5lY3Qg cHJvdmlkZSBhIHNlY29uZGFyeSB0b2tlbiBhbG9uZyBzaWRlIHRoZSBhY2Nlc3MgdG9rZW4g dGhhdCBjb21tdW5pY2F0ZXMgdGhlIGF1dGhlbnRpY2F0aW9uIGluZm9ybWF0aW9uIGRpcmVj dGx5IHRvIHRoZSBjbGllbnQuIFRoaXMgYWxsb3dzIHRoZSBwcmltYXJ5IGFjY2VzcyB0b2tl biB0byByZW1haW4gb3BhcXVlIHRvIHRoZSBjbGllbnQsIGp1c3QgbGlrZSBpbiByZWd1bGFy IE9BdXRoLjwvcD4KCQkJCgkJCTxoNCBpZD0iYXVkaWVuY2UtcmVzdHJpY3Rpb24iPkxhY2sg b2YgYXVkaWVuY2UgcmVzdHJpY3Rpb248L2g0PgoJCQkKCQkJPHA+QW5vdGhlciBwcm9ibGVt IHdpdGggdHJhZGluZyB0aGUgYWNjZXNzIHRva2VuIGZvciBhIHNldCBvZiBhdHRyaWJ1dGVz IHRvIGdldCB0aGUgY3VycmVudCB1c2VyIGlzIHRoYXQgbW9zdCBPQXV0aCBBUElzIGRvIG5v dCBwcm92aWRlIGFueSBtZWNoYW5pc20gb2YgYXVkaWVuY2UgcmVzdHJpY3Rpb24gZm9yIHRo ZSByZXR1cm5lZCBpbmZvcm1hdGlvbi4gSW4gb3RoZXIgd29yZHMsIGl0IGlzIHZlcnkgcG9z c2libGUgdG8gdGFrZSBhIG5haXZlIGNsaWVudCwgaGFuZCBpdCB0aGUgKHZhbGlkKSB0b2tl biBmcm9tIGFub3RoZXIgY2xpZW50LCBhbmQgaGF2ZSB0aGUgbmFpdmUgY2xpZW50IHRyZWF0 IHRoaXMgYXMgYSAibG9nIGluIiBldmVuLiBBZnRlciBhbGwsIHRoZSB0b2tlbiBpcyB2YWxp ZCBhbmQgaXQgd2lsbCByZXR1cm4gdmFsaWQgdXNlciBpbmZvcm1hdGlvbi4gVGhlIHByb2Js ZW0gaXMgb2YgY291cnNlIHRoYXQgdGhlIHVzZXIgaGFzbid0IGRvbmUgYW55dGhpbmcgdG8g cHJvdmUgdGhhdCB0aGV5J3JlIHByZXNlbnQsIGFuZCBpbiB0aGlzIGNhc2UgdGhleSBoYXZl bid0IGV2ZW4gYXV0aG9yaXplZCB0aGUgbmFpdmUgY2xpZW50LjwvcD4KCQkJCgkJCTxwPlRo aXMgcHJvYmxlbSBjYW4gYmUgbWl0aWdhdGVkIGJ5IGNvbW11bmljYXRpbmcgdGhlIGF1dGhl bnRpY2F0aW9uIGluZm9ybWF0aW9uIHRvIGEgY2xpZW50IGFsb25nIHdpdGggYW4gaWRlbnRp ZmllciB0aGF0IHRoZSBjbGllbnQgY2FuIHJlY29nbml6ZSBhbmQgdmFsaWRhdGUsIGFsbG93 aW5nIHRoZSBjbGllbnQgdG8gZGlmZmVyZW50aWF0ZSBiZXR3ZWVuIGFuIGF1dGhlbnRpY2F0 aW9uIGZvciBpdHNlbGYgdmVyc3VzIGFuIGF1dGhlbnRpY2F0aW9uIGZvciBhbm90aGVyIGFw cGxpY2F0aW9uLiBJdCBpcyBhbHNvIG1pdGlnYXRlZCBieSBwYXNzaW5nIHRoZSBzZXQgb2Yg YXV0aGVudGljYXRpb24gaW5mb3JtYXRpb24gZGlyZWN0bHkgdG8gdGhlIGNsaWVudCBkdXJp bmcgdGhlIE9BdXRoIHByb2Nlc3MgaW5zdGVhZCBvZiB0aHJvdWdoIGEgc2Vjb25kYXJ5IG1l Y2hhbmlzbSBzdWNoIGFzIGFuIE9BdXRoIHByb3RlY3RlZCBBUEksIHByZXZlbnRpbmcgYSBj bGllbnQgZnJvbSBoYXZpbmcgYW4gdW5rbm93biBhbmQgdW50cnVzdGVkIHNldCBvZiBpbmZv cm1hdGlvbiBpbmplY3RlZCBsYXRlciBpbiB0aGUgcHJvY2Vzcy48L3A+CgkJCQoJCQk8aDQg aWQ9ImltcGVyc29uYXRpb24iPkluamVjdGlvbiBvZiBpbnZhbGlkIHVzZXIgaW5mb3JtYXRp b248L2g0PgoJCQkKCQkJPHA+SWYgYW4gYXR0YWNrZXIgaXMgYWJsZSB0byBpbnRlcmNlcHQg b3IgY29vcHQgb25lIG9mIHRoZSBjYWxscyBmcm9tIHRoZSBjbGllbnQsIGl0IGNvdWxkIGFs dGVyIHRoZSBjb250ZW50IG9mIHRoZSByZXR1cm5lZCB1c2VyIGluZm9ybWF0aW9uIHdpdGhv dXQgdGhlIGNsaWVudCBiZWluZyBhYmxlIHRvIGtub3cgYW55dGhpbmcgd2FzIGFtaXNzLiBU aGlzIHdvdWxkIGFsbG93IGFuIGF0dGFja2VyIHRvIGltcGVyc29uYXRlIGEgdXNlciBhdCBh IG5haXZlIGNsaWVudCBieSBzaW1wbHkgc3dhcHBpbmcgb3V0IGEgdXNlciBpZGVudGlmaWVy IGluIHRoZSByaWdodCBjYWxsIHNlcXVlbmNlLiBUaGlzIGNhbiBiZSBtaXRpZ2F0ZWQgYnkg Z2V0dGluZyB0aGUgYXV0aGVudGljYXRpb24gaW5mb3JtYXRpb24gZGlyZWN0bHkgZnJvbSB0 aGUgaWRlbnRpdHkgcHJvdmlkZXIgZHVyaW5nIHRoZSBhdXRoZW50aWNhdGlvbiBwcm90b2Nv bCBwcm9jZXNzIChzdWNoIGFzIGFsb25nIHNpZGUgdGhlIE9BdXRoIHRva2VuKSBhbmQgYnkg cHJvdGVjdGluZyB0aGUgYXV0aGVudGljYXRpb24gaW5mb3JtYXRpb24gd2l0aCBhIHZlcmlm aWFibGUgc2lnbmF0dXJlLjwvcD4KCQkJCgkJCTxoNCBpZD0ic3BlY2lhbC1zbm93Zmxha2Vz Ij5EaWZmZXJlbnQgcHJvdG9jb2xzIGZvciBldmVyeSBwb3RlbnRpYWwgaWRlbnRpdHkgcHJv dmlkZXI8L2g0PgoJCQkKCQkJPHA+T25lIG9mIHRoZSBiaWdnZXN0IHByb2JsZW1zIHdpdGgg T0F1dGgtYmFzZWQgaWRlbnRpdHkgQVBJcyBpcyB0aGF0IGV2ZW4gd2hlbiB1c2luZyBhIGZ1 bGx5IHN0YW5kYXJkcy1jb21wbGlhbnQgT0F1dGggbWVjaGFuaXNtLCBkaWZmZXJlbnQgcHJv dmlkZXJzIHdpbGwgaW5ldml0YWJseSBpbXBsZW1lbnQgdGhlIGRldGFpbHMgb2YgdGhlIGFj dHVhbCBpZGVudGl0eSBBUEkgZGlmZmVyZW50bHkuIEZvciBleGFtcGxlLCBhIHVzZXIncyBp ZGVudGlmaWVyIG1pZ2h0IGJlIGZvdW5kIGluIGEgPGNvZGU+dXNlcl9pZDwvY29kZT4gZmll bGQgaW4gb25lIHByb3ZpZGVyIGJ1dCBpbiB0aGUgPGNvZGU+c3ViamVjdDwvY29kZT4gZmll bGQgaW4gYW5vdGhlciBwcm92aWRlci4gRXZlbiB0aG91Z2ggdGhlc2UgYXJlIHNlbWFudGlj YWxseSBlcXVpdmFsZW50LCB0aGV5IHdvdWxkIHJlcXVpcmUgdHdvIHNlcGFyYXRlIGNvZGUg cGF0aHMgdG8gcHJvY2Vzcy4gSW4gb3RoZXIgd29yZHMsIHdoaWxlIHRoZSBhdXRob3JpemF0 aW9uIG1heSBoYXBwZW4gdGhlIHNhbWUgd2F5IGF0IGVhY2ggcHJvdmlkZXIsIHRoZSBjb252 ZXlhbmNlIG9mIHRoZSBhdXRoZW50aWNhdGlvbiBpbmZvcm1hdGlvbiBjb3VsZCBiZSBkaWZm ZXJlbnQuIFRoaXMgcHJvYmxlbSBjYW4gYmUgbWl0aWdhdGVkIGJ5IHByb3ZpZGVycyB1c2lu ZyBhIHN0YW5kYXJkIDxpPmF1dGhlbnRpY2F0aW9uIHByb3RvY29sPC9pPiBidWlsdCBvbiB0 b3Agb2YgT0F1dGggc28gdGhhdCBubyBtYXR0ZXIgd2hlcmUgdGhlIGlkZW50aXR5IGluZm9y bWF0aW9uIGlzIGNvbWluZyBmcm9tLCBpdCBpcyB0cmFuc21pdHRlZCBpbiB0aGUgc2FtZSB3 YXkuPC9wPgoKICAgICAgICAgICAgPGgzIGlkPSJvcGVuaWQtY29ubmVjdCI+QSBzdGFuZGFy ZCBmb3IgYXV0aGVudGljYXRpb24gdXNpbmcgT0F1dGg6IE9wZW5JRCBDb25uZWN0PC9oMz4K CQkJCgkJCTxwPjxhIGhyZWY9Imh0dHA6Ly9vcGVuaWQubmV0L2Nvbm5lY3QvIj5PcGVuSUQg Q29ubmVjdDwvYT4gaXMgYW4gb3BlbiBzdGFuZGFyZCBwdWJsaXNoZWQgaW4gZWFybHkgMjAx NCB0aGF0IGRlZmluZXMgYW4gaW50ZXJvcGVyYWJsZSB3YXkgdG8gdXNlIE9BdXRoIDIuMCB0 byBwZXJmb3JtIHVzZXIgYXV0aGVudGljYXRpb24uIEluIGVzc2VuY2UsIGl0IGlzIGEgd2lk ZWx5IHB1Ymxpc2hlZCByZWNpcGUgZm9yIDxpPmNob2NvbGF0ZSBmdWRnZTwvaT4gdGhhdCBo YXMgYmVlbiB0cmllZCBhbmQgdGVzdGVkIGJ5IGEgd2lkZSBudW1iZXIgYW5kIHZhcmlldHkg b2YgZXhwZXJ0cy4gSW5zdGVhZCBvZiBidWlsZGluZyBhIGRpZmZlcmVudCBwcm90b2NvbCB0 byBlYWNoIHBvdGVudGlhbCBpZGVudGl0eSBwcm92aWRlciwgYW4gYXBwbGljYXRpb24gY2Fu IHNwZWFrIG9uZSBwcm90b2NvbCB0byBhcyBtYW55IHByb3ZpZGVycyBhcyB0aGV5IHdhbnQg dG8gd29yayB3aXRoLiBTaW5jZSBpdCdzIGFuIG9wZW4gc3RhbmRhcmQsIE9wZW5JRCBDb25u ZWN0IGNhbiBiZSBpbXBsZW1lbnRlZCBieSBhbnlvbmUgd2l0aG91dCByZXN0cmljdGlvbiBv ciBpbnRlbGxlY3R1YWwgcHJvcGVydHkgY29uY2VybnMuPC9wPgoJCQkKCQkJPHA+T3BlbklE IENvbm5lY3QgaXMgYnVpbHQgZGlyZWN0bHkgb24gT0F1dGggMi4wIGFuZCBpbiBtb3N0IGNh c2VzIGlzIGRlcGxveWVkIHJpZ2h0IGFsb25nIHdpdGggKG9yIG9uIHRvcCBvZikgYW4gT0F1 dGggaW5mcmFzdHJ1Y3R1cmUuIE9wZW5JRCBDb25uZWN0IGFsc28gdXNlcyB0aGUgSlNPTiBP YmplY3QgU2lnbmluZyBBbmQgRW5jcnlwdGlvbiAoSk9TRSkgc3VpdGUgb2Ygc3BlY2lmaWNh dGlvbnMgZm9yIGNhcnJ5aW5nIHNpZ25lZCBhbmQgZW5jcnlwdGVkIGluZm9ybWF0aW9uIGFy b3VuZCBpbiBkaWZmZXJlbnQgcGxhY2VzLiBJbiBmYWN0LCBhbiBPQXV0aCAyLjAgZGVwbG95 bWVudCB3aXRoIEpPU0UgY2FwYWJpbGl0aWVzIGlzIGFscmVhZHkgYSBsb25nIHdheSB0byBk ZWZpbmluZyBhIGZ1bGx5IGNvbXBsaWFudCBPcGVuSUQgQ29ubmVjdCBzeXN0ZW0sIGFuZCB0 aGUgZGVsdGEgYmV0d2VlbiB0aGUgdHdvIGlzIHJlbGF0aXZlbHkgc21hbGwuIEJ1dCB0aGF0 IGRlbHRhIG1ha2VzIGEgYmlnIGRpZmZlcmVuY2UsIGFuZCBPcGVuSUQgQ29ubmVjdCBtYW5h Z2VzIHRvIGF2b2lkIG1hbnkgb2YgdGhlIHBpdGZhbGxzIGRpc2N1c3NlZCBhYm92ZSBieSBh ZGRpbmcgc2V2ZXJhbCBrZXkgY29tcG9uZW50cyB0byB0aGUgT0F1dGggYmFzZTo8L3A+CgoJ CQk8aDQgaWQ9ImlkLXRva2VucyI+SUQgVG9rZW5zPC9oND4KCQkJCgkJCTxwPlRoZSBPcGVu SUQgQ29ubmVjdCBJRCBUb2tlbiBpcyBhIHNpZ25lZCBKU09OIFdlYiBUb2tlbiAoSldUKSB0 aGF0IGlzIGdpdmVuIHRvIHRoZSBjbGllbnQgYXBwbGljYXRpb24gYWxvbmcgc2lkZSB0aGUg cmVndWxhciBPQXV0aCBhY2Nlc3MgdG9rZW4uIFRoZSBJRCBUb2tlbiBjb250YWlucyBhIHNl dCBvZiBjbGFpbXMgYWJvdXQgdGhlIGF1dGhlbnRpY2F0aW9uIHNlc3Npb24sIGluY2x1ZGlu ZyBhbiBpZGVudGlmaWVyIGZvciB0aGUgdXNlciAoPGNvZGU+c3ViPC9jb2RlPiksIHRoZSBp ZGVudGlmaWVyIGZvciB0aGUgaWRlbnRpdHkgcHJvdmlkZXIgd2hvIGlzc3VlZCB0aGUgdG9r ZW4gKDxjb2RlPmlzczwvY29kZT4pLCBhbmQgdGhlIGlkZW50aWZpZXIgb2YgdGhlIGNsaWVu dCBmb3Igd2hpY2ggdGhpcyB0b2tlbiB3YXMgY3JlYXRlZCAoPGNvZGU+YXVkPC9jb2RlPiku IEFkZGl0aW9uYWxseSwgdGhlIElEIFRva2VuIGNvbnRhaW5zIGluZm9ybWF0aW9uIGFib3V0 IHRoZSB0b2tlbidzIHZhbGlkIChhbmQgdXN1YWxseSBzaG9ydCkgbGlmZXRpbWUgYXMgd2Vs bCBhcyBhbnkgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGF1dGhlbnRpY2F0aW9uIGNvbnRleHQg dG8gYmUgY29udmV5ZWQgdG8gdGhlIGNsaWVudCwgc3VjaCBhcyBob3cgbG9uZyBhZ28gdGhl IHVzZXIgd2FzIHByZXNlbnRlZCB3aXRoIGEgcHJpbWFyeSBhdXRoZW50aWNhdGlvbiBtZWNl aGFuaXNtLiBTaW5jZSB0aGUgZm9ybWF0IG9mIHRoZSBJRCBUb2tlbiBpcyBrbm93biBieSB0 aGUgY2xpZW50LCBpdCBpcyBhYmxlIHRvIHBhcnNlIHRoZSBjb250ZW50IG9mIHRoZSB0b2tl biBkaXJlY3RseSBhbmQgb2J0YWluIHRoaXMgaW5mb3JtYXRpb24gd2l0aG91dCByZWx5aW5n IG9uIGFuIGV4dGVybmFsIHNlcnZpY2UgdG8gZG8gc28uIEZ1cnRoZXJtb3JlLCBpdCBpcyBp c3N1ZWQgaW4gYWRkaXRpb24gdG8gKGFuZCBub3QgaW4gbGlldSBvZikgYW4gYWNjZXNzIHRv a2VuLCBhbGxvd2luZyB0aGUgYWNjZXNzIHRva2VuIHRvIHJlbWFpbiBvcGFxdWUgdG8gdGhl IGNsaWVudCBhcyBpdCBpcyBkZWZpbmVkIGluIHJlZ3VsYXIgT0F1dGguIEZpbmFsbHksIHRo ZSB0b2tlbiBpdHNlbGYgaXMgc2lnbmVkIGJ5IHRoZSBpZGVudGl0eSBwcm92aWRlcidzIHB1 YmxpYyBrZXksIGFkZGluZyBhbiBhZGRpdGlvbmFsIGxheWVyIG9mIHByb3RlY3Rpb24gdG8g dGhlIGNsYWltcyBpbnNpZGUgb2YgaXQgaW4gYWRkaXRpb24gdG8gdGhlIFRMUyB0cmFuc3Bv cnQgcHJvdGVjdGlvbiB0aGF0IHdhcyB1c2VkIHRvIGdldCB0aGUgdG9rZW4gaW4gdGhlIGZp cnN0IHBsYWNlLCBwcmV2ZW50aW5nIGEgY2xhc3Mgb2YgaW1wZXJzb25hdGlvbiBhdHRhY2tz LiBCeSBhcHBseWluZyBhIGZldyBzaW1wbGUgY2hlY2tzIHRvIHRoaXMgSUQgdG9rZW4sIGEg Y2xpZW50IGNhbiBwcm90ZWN0IGl0c2VsZiBmcm9tIGEgbGFyZ2UgbnVtYmVyIG9mIGNvbW1v biBhdHRhY2tzLjwvcD4KCQkJCgkJCTxoNCBpZD0idXNlcmluZm8tZW5kcG9pbnQiPlVzZXJJ bmZvIEVuZHBvaW50PC9oND4KCQkJCgkJCTxwPkluIGFkZGl0aW9uIHRvIHRoZSBjbGFpbXMg aW4gdGhlIElEIFRva2VuLCBPcGVuSUQgQ29ubmVjdCBkZWZpbmVzIGEgc3RhbmRhcmQgcHJv dGVjdGVkIHJlc291cmNlIHRoYXQgY29udGFpbnMgY2xhaW1zIGFib3V0IHRoZSBjdXJyZW50 IHVzZXIuIFRoZSBjbGFpbXMgaGVyZSBhcmUgbm90IHBhcnQgb2YgdGhlIGF1dGhlbnRpY2F0 aW9uIHByb2Nlc3MsIGFzIGRpc2N1c3NlZCBhYm92ZSwgYnV0IGluc3RlYWQgcHJvdmlkZSBi dW5kbGVkIGlkZW50aXR5IGF0dHJpYnV0ZXMgdGhhdCBtYWtlIHRoZSBhdXRoZW50aWNhdGlv biBwcm90b2NvbCBtb3JlIHZhbHVhYmxlIHRvIGFwcGxpY2F0aW9uIGRldmVsb3BlcnMuIEFm dGVyIGFsbCwgaXQncyBwcmVmZXJhYmxlIHRvIHNheSAiR29vZCBNb3JuaW5nLCBKYW5lIERv ZSIgaW5zdGVhZCBvZiAiR29vZCBNb3JuaW5nLCA5WEUzLUpJMzQtMDAxMzJBIi4gT3BlbklE IENvbm5lY3QgZGVmaW5lcyBzZXQgb2Ygc3RhbmRhcmRpemVkIE9BdXRoIHNjb3BlcyB0aGF0 IG1hcCB0byBzdWJzZXRzIG9mIHRoZXNlIGF0dHJpYnV0ZXMsIGFsbG93aW5nIHBsYWluIE9B dXRoIGF1dGhvcml6YXRpb24gcmVxdWVzdCB0byBjYXJyeSB0aGUgbmVjZXNzYXJ5IGluZm9y bWF0aW9uIGZvciBhIHJlcXVlc3QuIEluIHBhcnRpY3VsYXIsIHRoZSBPcGVuSUQgQ29ubmVj dCBkZWZpbmVzIGEgc3BlY2lhbCA8Y29kZT5vcGVuaWQ8L2NvZGU+IHNjb3BlIHRoYXQgc3dp dGNoZXMgb24gdGhlIGlzc3VhbmNlIG9mIHRoZSBJRCB0b2tlbiBhcyB3ZWxsIGFzIGFjY2Vz cyB0byB0aGUgVXNlckluZm8gRW5kcG9pbnQgYnkgdGhlIGFjY2VzcyB0b2tlbi4gVGhlIE9w ZW5JRCBDb25uZWN0IHNjb3BlcyBjYW4gYmUgdXNlZCBhbG9uZyBzaWRlIG1vcmUgcGxhaW4g T0F1dGggc2NvcGVzIHdpdGhvdXQgaXNzdWUuPC9wPgoJCQkKCQkJPGg0IGlkPSJkaXNjb3Zl cnktcmVnaXN0cmF0aW9uIj5EeW5hbWljIHNlcnZlciBkaXNjb3ZlcnkgYW5kIGNsaWVudCBy ZWdpc3RyYXRpb248L2g0PgoJCQkKCQkJPHA+T0F1dGggMi4wIHdhcyB3cml0dGVuIHRvIGFs bG93IGEgdmFyaWV0eSBvZiBkaWZmZXJlbnQgZGVwbG95bWVudHMsIGJ1dCBieSBkZXNpZ24g ZG9lcyBub3Qgc3BlY2lmeSBob3cgdGhlc2UgZGVwbG95bWVudHMgY29tZSB0byBiZSBzZXQg dXAgb3IgaG93IHRoZSBjb21wb25lbnRzIGtub3cgYWJvdXQgZWFjaCBvdGhlci4gVGhpcyBp cyBPSyBpbiB0aGUgcmVndWxhciBPQXV0aCB3b3JsZCB3aGVyZSBvbmUgYXV0aG9yaXphdG9p biBzZXJ2ZXIgcHJvdGVjdHMgYSBzcGVjaWZpYyBBUEksIGFuZCB0aGUgdHdvIGFyZSBjbG9z ZWx5IGNvdXBsZWQuIFdpdGggT3BlbklEIENvbm5lY3QsIGEgY29tbW9uIHByb3RlY3RlZCBB UEkgaXMgZGVwbG95ZWQgYWNyb3NzIGEgd2lkZSB2YXJpZXR5IG9mIGNsaWVudHMgYW5kIHBy b3ZpZGVycywgYWxsIG9mIHdoaWNoIG5lZWQgdG8ga25vdyBhYm91dCBlYWNoIG90aGVyIHRv IG9wZXJhdGUuIEl0IHdvdWxkIG5vdCBiZSBzY2FsYWJsZSBmb3IgZWFjaCBjbGllbnQgdG8g aGF2ZSB0byBrbm93IGFoZWFkIG9mIHRpbWUgYWJvdXQgZWFjaCBwcm92aWRlciwgYW5kIGl0 IHdvdWxkIGJlIGV2ZW4gbW9yZSB1bnNjYWxhYmxlIHRvIHJlcXVpcmUgZWFjaCBwcm92aWRl ciB0byBrbm93IGFib3V0IGVhY2ggcG90ZW50aWFsIGNsaWVudC48L3A+CgkJCQoJCQk8cD5U byBjb3VudGVyYWN0IHRoaXMsIE9wZW5JRCBDb25uZWN0IGRlZmluZXMgYSA8YSBocmVmPSJo dHRwOi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQtY29ubmVjdC1kaXNjb3ZlcnktMV8wLmh0 bWwiPmRpc2NvdmVyeTwvYT4gcHJvdG9jb2wgdGhhdCBhbGxvd3MgY2xpZW50cyB0byBlYXNp bHkgZmV0Y2ggaW5mb3JtYXRpb24gb24gaG93IHRvIGludGVyYWN0IHdpdGggYSBzcGVjaWZp YyBpZGVudGl0eSBwcm92aWRlci4gT24gdGhlIG90aGVyIHNpZGUgb2YgdGhlIHRyYW5zYWN0 aW9uLCBPcGVuSUQgQ29ubmVjdCBkZWZpbmVzIGEgPGEgaHJlZj0iaHR0cDovL29wZW5pZC5u ZXQvc3BlY3Mvb3BlbmlkLWNvbm5lY3QtcmVnaXN0cmF0aW9uLTFfMC5odG1sIj5jbGllbnQg cmVnaXN0cmF0aW9uPC9hPiBwcm90b2NvbCB0aGF0IGFsbG93cyBjbGllbnRzIHRvIGJlIGlu dHJvZHVjZWQgdG8gbmV3IGlkZW50aXR5IHByb3ZpZGVycy4gQnkgdXNpbmcgdGhlc2UgdHdv IG1lY2hhbmlzbXMgYW5kIGEgY29tbW9uIGlkZW50aXR5IEFQSSwgT3BlbklEIENvbm5lY3Qg Y2FuIGZ1bmN0aW9uIGF0IGludGVybmV0IHNjYWxlLCB3aGVyZSBubyBwYXJ0aWVzIGhhdmUg dG8ga25vdyBhYm91dCBlYWNoIG90aGVyIGFoZWFkIG9mIHRpbWUuPC9wPiAgCgkJCQoJCQk8 aDQgaWQ9ImFkdmFuY2VkLW9pZGMiPkFkdmFuY2VkIGNhcGFiaWxpdGllczwvaDQ+CgkJCQoJ CQk8cD5PcGVuSUQgQ29ubmVjdCBhbHNvIGRlZmluZXMgYSBudW1iZXIgb2YgYWR2YW5jZWQg Y2FwYWJpbGl0aWVzIGJleW9uZCBzdGFuZGFyZCBPQXV0aCB0aGF0IGFyZSBzdWl0YWJsZSBm b3IgaGlnaGVyIHNlY3VyaXR5IHByb2ZpbGVzIGFuZCBkZXBsb3ltZW50cywgaW5jbHVkaW5n IChhbW9uZyBvdGhlcnMpOgoJCQkJCgkJCQk8L3A+PHVsPgoJCQkJCTxsaT5QdWJsaWMga2V5 IGNsaWVudCBhdXRoZW50aWNhdGlvbjwvbGk+CgkJCQkJPGxpPlNlbGVjdGluZyBhbmQgcmV0 cmlldmluZyBzcGVjaWZpYyBjbGFpbXMgYW5kIHZhbHVlcyBmcm9tIHRoZSBpZGVudGl0eSBw cm92aWRlcjwvbGk+CgkJCQkJPGxpPlNpZ25pbmcgYW5kIGVuY3J5cHRpbmcgT0F1dGggcmVx dWVzdHM8L2xpPgoJCQkJCTxsaT5TZXNzaW9uIG1hbmFnZW1lbnQgb3ZlciB0aW1lPC9saT4K CQkJCTwvdWw+CgkJCTxwPjwvcD4KCiAgICAgICAgICAgIDxoMyBpZD0iZnVydGhlci1yZWFk aW5nIj5GdXJ0aGVyIFJlYWRpbmc8L2gzPgoKCQkJPHVsPgoJCQkJPGxpPkluIHRoZSBhcnRp Y2xlIDxhIGhyZWY9Imh0dHA6Ly93d3cuY2xvdWRpZGVudGl0eS5jb20vYmxvZy8yMDEzLzAx LzAyL29hdXRoLTItMC1hbmQtc2lnbi1pbi00LyI+T0F1dGggMi4wIGFuZCBTaWduLWluPC9h PiwgVml0dG9yaW8gQmVydG9jY2kgcHJvdmlkZXMgZGV0YWlsIG9uIHRoZSBzZWN1cml0eSBi b3VuZGFyaWVzIGJldHdlZW4gcGFydGllcyBhbmQgd2h5IHRoZSBhdXRob3JpemF0aW9uIGxh eWVyIG1ha2VzIHNlbnNlIGFzIHRoZSBsb3dlciBsYXllciB0byBidWlsZCBvbiB0b3Agb2Yu PC9saT4KCQkJCTxsaT5KdXN0aW4gUmljaGVyIHByZXNlbnRlZCBhIGRldGFpbGVkIG92ZXJ2 aWV3IG9mIHRoZSB0ZWNobm9sb2dpZXMgdGFsa2VkIGFib3V0IGhlcmUgaW4gPGEgaHJlZj0i aHR0cDovL3d3dy5zbGlkZXNoYXJlLm5ldC96ZXJvbmluZTEvYXV0aC1pbi10aGUtZXh0ZW5k ZWQtZW50ZXJwcmlzZS1taXQtaGFja2F0aG9uLTIwMTMiPkF1dGgqIEluIHRoZSBFeHRlbmRl ZCBFbnRlcnByaXNlPC9hPiBhdCBNSVQuPC9saT4KCQkJPC91bD4KCQkJCiAgICAgICAgICAg IDwhLS0/cGhwIGluY2x1ZGUoJy4uL2luY2x1ZGVzL19lZGl0X2Jhbm5lci5waHAnKTsgPy0t PgoKICAgICAgICA8L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1sPg== --------------080201090208040905040500 Content-Type: application/pdf; name="Authentication with OAuth 2.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Authentication with OAuth 2.pdf" JVBERi0xLjcKJeLjz9MKNDggMCBvYmoNCjw8L01ldGFkYXRhIDQ2IDAgUi9QYWdlcyAzIDAg Ui9UeXBlL0NhdGFsb2c+Pg0KZW5kb2JqDQozIDAgb2JqDQo8PC9Db3VudCA1L0tpZHNbNCAw IFIgMTYgMCBSIDIxIDAgUiAyOCAwIFIgMzMgMCBSXS9UeXBlL1BhZ2VzPj4NCmVuZG9iag0K MzMgMCBvYmoNCjw8L0NvbnRlbnRzIDM0IDAgUi9NZWRpYUJveFswIDAgNTk1LjI4MDAyOTMg ODQxLjg5MDAxNDddL1BhcmVudCAzIDAgUi9SZXNvdXJjZXM8PC9FeHRHU3RhdGUgMzYgMCBS L0ZvbnQgMzcgMCBSL1Byb2NTZXRbL1BERiAvVGV4dF0+Pi9Sb3RhdGUgMC9UeXBlL1BhZ2U+ Pg0KZW5kb2JqDQozNyAwIG9iag0KPDwvUjEwIDEwIDAgUi9SOCA4IDAgUj4+DQplbmRvYmoN CjggMCBvYmoNCjw8L0Jhc2VGb250L0pUUktXVCtMaWJlcmF0aW9uU2VyaWYtQm9sZC9GaXJz dENoYXIgMzIvRm9udERlc2NyaXB0b3IgOSAwIFIvTGFzdENoYXIgMTIyL1N1YnR5cGUvVHJ1 ZVR5cGUvVG9Vbmljb2RlIDQ0IDAgUi9UeXBlL0ZvbnQvV2lkdGhzWzI1MCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDI1MCAwIDUwMCAwIDUwMCAwIDAgMCAwIDAgMCAwIDMzMyAwIDAg MCAwIDUwMCAwIDcyMiAwIDcyMiA3MjIgNjY3IDYxMSAwIDAgMzg5IDAgMCA2NjcgMCAwIDc3 OCAwIDAgNzIyIDAgNjY3IDcyMiAwIDEwMDAgMCAwIDAgMCAwIDAgMCAwIDAgNTAwIDU1NiA0 NDQgNTU2IDQ0NCAzMzMgNTAwIDU1NiAyNzggMzMzIDU1NiAyNzggODMzIDU1NiA1MDAgNTU2 IDAgNDQ0IDM4OSAzMzMgNTU2IDUwMCA3MjIgMCA1MDAgNDQ0XT4+DQplbmRvYmoNCjQ0IDAg b2JqDQo8PC9MZW5ndGggMjY1L0ZpbHRlciAvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KeJxdkTFu wzAMRXefQjewbMkWAhhakiVDi6LtBRSZCjxEFhRn6O37SScdOnzCzxT5ha/2eD6d87Kp9qOu 8Ys2lZY8V7qvjxpJXei65Kbr1bzE7UlS4y2Upj2+hfL9U0jhAKWd38ON2k9r5U+3z8R1pnsJ kWrIV2omrf2Ukm8oz/9andsnLul5tMdRltaoQPIiIAENOka6hrum9yJgzxi8CBgYkxcB4T3Z zou0RgUa4ChoGA9eBDwwRi8CRkassbLK8qoBnoP4Duw7WOAgaBmdFwEdcISnkzuP7Osw56Tr eNbB08md8cUBvZLgrDj0V8YqPmqlvMnLSPKc+JLp7/HKWnhKQc0vJ0mHKg0KZW5kc3RyZWFt DQplbmRvYmoNCjkgMCBvYmoNCjw8L0FzY2VudCA3MDQvQ2FwSGVpZ2h0IDY2Mi9EZXNjZW50 IC0yMjAvRmxhZ3MgNi9Gb250QkJveFstNyAtMjIwIDk4NCA3MDRdL0ZvbnRGaWxlMiA0MCAw IFIvRm9udE5hbWUvSlRSS1dUK0xpYmVyYXRpb25TZXJpZi1Cb2xkL0l0YWxpY0FuZ2xlIDAv TWlzc2luZ1dpZHRoIDM2NS9TdGVtViAxNjIvVHlwZS9Gb250RGVzY3JpcHRvci9YSGVpZ2h0 IDUxMz4+DQplbmRvYmoNCjQwIDAgb2JqDQo8PC9MZW5ndGggMTI0NTkvRmlsdGVyIC9GbGF0 ZURlY29kZS9MZW5ndGgxIDE3NzA0Pj5zdHJlYW0NCnicvbwLfBTHlS9cp7rn/ep59TxamodG rZE0EiM0SEIMoEboMUIgBiFAEggJW7yMQeJhDH6h7GJshB8kZolZNg7rOA6OSRgwsfF6ExOH +N5sgs1uiDd+rUnW13d9bV1I4vjGxhrdUz0jEE72ft/3+32/20jdVaeqTlWdOnXqf6pKECCE WMgI4Uh68dJ4NVGf+b/A1/JbN68ZzsXnnSEErt66c0dI2TL3KBLeIYRq1w2v37z9l5EMht8n RKdZf/vudbn85hFCZryzYe2aQe6vxYcJabqKxNoNSLCe0WKNho8xXrxh845dufxNxfg6cfvQ rWvy9a3CV/fmNbuG+d9pf0OIUcB4aMuazWvz7XsKXyXDQ9t35MtfZOnD29YOf/2vvteE+auw TYs0DxM3GdLMIbb8+6aHO0F85DQhE6wtU97ZhROfk/8fH736BgeEyU/JZ5AASu4BJ+klg2SI 3ENGITE1NyRhIabdixIeJFvIw6D7y1whDCVgQQ69ar57yQXy27+YcSv5Ebl6cx1IO0yeIicY HVqQ1yH4CSyEQeTBOC/E16q/xIrehq9H8XcXvjdTyFOvkF+QX5NV9EeoBQfJ9/Pts5KPAUcC 2rGFL+QZtJOlf8b0LLbCSNaT3WQfllYfzZwv3iKGiT8grwXkx0hoI3eTh6+X+BOodXBGMnGd tuJ6GwfpAXBCCXmC/Ik0aeyAmqs093Qv61rauSS9uGPRwvYFbanWluam+Y3zlIa5c2YnZ9XP rKutmV4Vn1ZZURotkYsjReGg12UXbFaLyWjQ67QansPeVjRHWgZCmZKBDF8SSaUqWTyyBglr phAGMiEktdycJxMaULOFbs6pYM51X8qp5HIq13OCEJpNZldWhJojocyFpkjoLPQu6cbww02R nlBmTA0vUsN8iRqxYCQcxhKhZu+GplAGBkLNmZadG0abB5qQ3ymTcX5k/lpjZQU5ZTRh0ISh TGlk+BSUzgU1QEubZ52iRG9h1WY4uXnNYCa9pLu5SQqHeyor2jLWSJOaROarLDPa+RmdyjK0 kTWdHAidqjg3+tBZgdwyEDMPRgbXrOrOcGuw7CjXPDr6QMYey5RFmjJld73vxZ6vzVREmpoz Mca1vfN6Pe03qoSMRhYiodE/EuxOZOzjmylr8hStLPyRsGALind0tCUSahkdGF1zdmLklkhI iIyeMptHh5tRwiTdjaXOTvzDASnT8lBPRhjYALPynW3pbM84l6zszlC5JbRhDVLwpyESnimF 7T2TedL/WTJBQaA4UKbhMOv4gbMKuQUjmZEl3bl4iNwinSZKPNaToQMs5dxkinsZSxmZTLle fCCCo9m+tHs0w8ttg5FmlPGBNZmRW1CfbmNDEREy1k+lcGTUYQ/Vx3vUvCFsVdvgxlBGU4Ji wVJTC6CmsCKjghqxfpr7jElYQYndEaqPIBvGpznSPJD/2bnBiwxClRWZVCw39F3dGaUJA8qa /Bg1n6qKY4k1AzhEG5vU4cvEI8MZV6Tx+niyZjVvXNqtFskXy7jmZ8jArflSmXhzE6s51Dw6 0JRrAuMVWdL9IklMXD41IyQ9lyAzSE8TyyzOR70qaR7tHlyXCQ5IgzjT1oW6pXBG6cEB7ol0 r+1hioYSKruM1YXVGjN0fld3+9JI+5Le7pn5huQSGDtebv4Sm0i3lGODKpfRy/pQN5W4Hswo ICHUgoFI42x8Z3SyHn8FFLhKZaraODvUDRKZzI3NyJSFmtc25fOx+E1MNUyd5qcmuWlZFPnM T0nhnnDuqaygmBzKV4wl9EyoqckkTkZLgDSKbFQSk6WX6XyoO7I20hPZEMoo6W7WNyYeVcp5 Yagyz49V102xKcJCMZEwJk9GmDAzLTFpqnAzrWr8ejT1peS2yeTQqD7SvnSUMY/kGRJseVuG MBVWZtoldfaz+RxpWYOTGGe0Op9HTykKm8sb2LQdjbQNjkaWds9Wc6MFuVe6i9XlIO3Q3tVY WYHGrPFUBB5cckqBB5f2dr+IeCL0YFf3aQp0/kBjz6liTOt+MYRrhUqljMqILBJiEcapEyN6 Nb/0okLIiJrKqwQ1futZICpNP0kDcutZmqMJkzSKND5HU1Qae3CUvBtQxmi/m0ODbHzu6dkw OtDDdJyIKBH8gQxE5qJ0InNPAdWaM8bI2saMKdLI6A2M3pCjaxldh5oBIlRW3DUqNEf+6K1U F2VEaeFsM1lhoNkD2Uf03yfwpdU4plJi0Em6yDDRYGMFEscVnHAT/MeIEaky3fDbyzXB9xLv Lvu3xDvLqt5NvzvybuZd/l3glr3DicGhX0L/L6/8ki7+JTS8AsFX3nuFnp04p3zrnNHSkn55 4OXhl7kftZYHyVmIv9D/wqMvnHzhvRc0Q9cg+PmVz+nQ53s+p8rnMPQDsJ0JnqFDZyD43OLn Jp7jvn+iMWg7vuc4PXkcho9Dw3EQHg89XvU4N/w4fP1wQTD+Nw1/Q796/2Dw5CPw0OJgkNw/ cD89eD8c/Gv4K4wKd4TuoDsGJoLb+yeCw1j/EP5uaZ0I+hLeZboEt0zLTQRZO09mpyVazt0C l9fAQP+MYD+WDX4R/+KbX3AnvwCyGpTVBkvLnlWPrvrmKm5lbywY7wXSO9BLD/Ze7aXBXnAm HMs0KAoeedq4INfALeaGuEc5rX7pgnAwjeyGOvZ0PNrBLWqNBBe0hoK2FCgpk62lBRtkaw22 0oKUtExMuJfZwbZMSNiWIfBYhvBtWdw2YaM2W79tj42zkQZCR0TQwFk4eKpraSzWflY3geuW Lr0yAw9m5KXsrSzpzWgfzJBlvSu7TwE80nP/ww+TxsL2TPXS7sxAYU97ZhADCguMYEAoPCWS xp7t23fE1Ae2x2I7YgR/Y6u3q/HtO+7A2A4E3bHY9u1qHvzFyA7AOFK3x7ZjaAfZzphsh+07 WGA72Y7pZDv73YG0O1hpVtS7WgVspImhNs0y1C4dmXYKSHz2aR1PxqpPaTXvzD7NUQySUxwj axj5tE4LX8w+DYyesIftctgebqKhbDE8nt2gWfb5s038BZWvC5HkWU0Kcb+DvKzcldJ16+gK LZRoW7SU17q01G61CTYbrxEcFrNg7jaDVgedZkErmHt1WpdOp20XgAiCQIlO0FEeXwLPcXq9 S3CFXIor7RpxHXRlXLoq1zAGj7kuui67tJzFOuCw20HQ8Dazju83goM0JMaqq6sbEo76OIYg 3rfVnog7PPW+uDce7+vre0CICeTHD2hiwnnoEx44d84OCXvCG8fQ9CrADH2yO1xTh5jfw75c mAMuDCeyGwbhXSiCt9eNP3t0ZHz8bvjKu3Cmra1N4t+/ViDhF1Zmv837x0+qcz848d/52ej1 FJDTyl/P9KQ8dKaYEmm3foN+l56bpV+gp5xB79OX6TneBwZfK+FdYHS5CgPFAVgZAD7gCtD6 HYG9gfOBSwE+HQAqBKoCSoBLBwYCmcDlwNWAJhiA4cAxjJ0L8PEA2FqvGCeMFB04IzX6Ogrc blOHx2pzdBKNyMTCJNMwhhLpG+vr27p1W/+2basxYEdJre5LjK3um17V168KwMpFiqbRGnu0 Jmx3iYnqOjWE8qA/Di7o7K6sH2guWQ17WhsXLlwOd67KPtYplITcgcbb2ulyb+P4nV2ri+jL 3sYvvu9tRFmEJz6mf89/hUhkhVK/gYNZ3AKul+NMnMTFOI6IkBZBFM1Cq2FEA0QjaEKaixpe oyko1NoWmwxmm8e5hGAPxhINiQtj1XYH1OOosmHGD7a5r0+jtjZS0wAJd8IdUdtcW+e2cvB8 +6am0N1fvePwq6/WVhTNL7TWzmt1FTesSNBN86K/+tWG8e/MazRqlxldNqM6bui78V3oy8rk H14klomLSqFBSB1xPuN80ck5Q2Yh5eQFMAitvNvlpn43M2O3Gi0ptztaHIWVUeCjriiOW3Rv 9Hz0UpRPR4FWRZUoTUcHopno5ejVqCYYheHoMYydi/LxKMwINAVogBS0krAQPhe+GObDRR0y KXAL4Y6g2+n2dWrQI2fD16AqNhtADPRNHUIcwdjqPhzBRAwHMQYuK9XN5RLVAeq2q1psn1ES KdLlwziWcAYohWB7V09uLLOVXepgZitXDcBXuE9tZRVltskxHf+ut7HRS+M4quPzWJB/E8eV kpaJMa6b+wkpJKVks9Jxp+8BH91p2meituJgMRWEg1rQtoSKq4qV4mPFmeJzxdri4vJ4eUN5 f/lQ+Z7yk+Uvl79efqXcENG1XpRA0i4uLiZ2yxJRDCzGlbBhrGH8AnYs198+DKHa4oizAQfs WSGE3ThH8gOt6uuMWk+RlboTM6ZR+J9L961OZJ2m6Wt7ksMJT8vSVZW7T2yu/uU/FU+TjG9p nKXcT0rX/P3uTmH+3f0zHaZF1gK3Rbnv7K5Pf7+2fOGW+fO3LCxn+lDH9IH7KQkxfdBP6oP1 GeuLVs7K9MHKm8BgauUFl0D9wqQ+CEJRcRGsLAK+yFWE+lC0t+h80aUiPl2E+lCkFNF00UBR puhy0dUiTbAIhouOYexcER8vghm+Jh/1EU8rKRAKzhVcLOALCjuCNo9gKujwu61uF07n/6/6 8H/WhdM35vQUPVgFm7ne/1QF6J9QBVAHEOpQCeeLAbVgh7LEtSBtPGikF41g1PFeHngPAJBW NqkvajiNJhBUgukgHQgeC2aCXDAImeC54OUgFw82BB8NcjZfEPu+1Ea0HQYb0XRwblQD7GLD WB+o/bOralDdl+izJy5t3TY2vUq+0Y8Zc6naTdR+pg5wZn3WsQ7VOfsrb/nMUGhmmddbxr7l 3t7JLkBqKhmzsTFnet2LYx4l9Up4ZwHsNIPL6YyWnSx7vexKGRdsNfoXK84RmxAtXsIs6/ir Df5f+HEcxvqE16rjCaahkyZUbZPosUei05CAyplXWa7XO29RZ+m+H+2auWDP8b7lRxpT5UKw OFYQXZAs9sxa1zFvT0W9s8BpnH/f8zu+8tKuerc1+z++bbabNJV9XxvsGr2lRrAw+TdOfMz9 hvsxzsAa8qyyu0wEo+gX6QK0kQ4od4DJITloLdfCUZ5zccUc5zdqW4drRmooqRFqDtZcrOEN NTWuOlIH7ek61HelLl03UDdSd7lOq6gBrigSIXEhTuOtriLFYEkVFQXKOvx+Ur3EaBNxoNyB jtx0ZQuMHScs0z4mjEQ80bcV9TG3wGwdS6iSyT0wqY/RG4JqgBqmmlobRGrmck6dlXPnDDkt WvRXq2eszj4tOhONndWdQ02Bpu1Hlt/V1Fq3srykcdrS5f27uyqUmHt2VVVTiPuxf85g2/g3 vI0pS6jAWd6+fvaaHQ0uyu1fuiLovuPfdWajNuvhqCu+cNaytNuq4pcOlONpHHM7Wv79yrT9 AjxgBu4BPTzIAY/ohhpIK+9wOYodnMnhiPKqgecamJGnUZz1z9XPSbGvUl4aS11Gq0/Q6g+g ib8Y1XwzCkoUCloVY9p40cgZPYttQngx05yx3OxF1e7fGouhqFRJ5VZithRDXpXzaqRBw3ZD ieZS7vT0276zc+jJjdXVt317+3v/nH3bHJpZWVFbaDQW1lZUzgyZ4e1dZ++bp9z34q47X7hH +ex3a752S1XVLV9bc8tjg9XVg4/l/BTtxMeaf0Ss4uKSygsbXKC1i3aqFUSBrrACIjWD2Wem +02w3gjdWvDx4ONgJwEDOi5AJowGlxF/odNkNC12unCmuPTQib7eYp0ecZ3eDJ0Op2ORxeyy WMwGPRCX0WR2Uodlh3Ovk651gskpOY86uXLjLCM1GSXjUSNn2AQHgPYCOlXAOY0ARidn0epK dNSoEy1viB+I9LwIT4vPi/SQCPsQPqCbqjT98U+pWhGKRaCiQ6SfiPBbEc6Ll0T6vAhPirBX PCTSbSI0iV3ioMiViLUifZXxOiI+I1KtKIr0n0U2hhO/ejOF/LHUUyr3JsxOS0TwicAzwmHx aZEV1GwUYbkIbQy+IC+DCG+IsF+EnSKUiW0iNYmSSI+Jyt8+kbomwocivC3Cz0T4nvhDkR4V 4VER7hZhswg9IiwSoR49SBEMok+kn7GsH4n0GfFF8Wcid1Tlukm8W6RtYo9IJTEmJkUO60O2 b4ofivQl8ecsN4gjm4ZSyIjloBYR1quljorPii+JjOM1Ud+PuZRlK1OisnBpqkFcLFJRmdeW +mauggMi1y8q5eASZ4gUoVkdE9ol8RORTzM5QEgVwRnxvPi+yB1TBX9O8UjBVBWjwrMiHETx EzEkUp2aFjDbUg4dtXQwgKWCec7l4m02p95gAjPDpezBd7wvkRDYiga4dDEYujWGBp89q1WL EWMzZFs/i8T61NUu/2y76Ynlct+cpBKnFoip5LjwKlonT/2ceDzOaswVtSeq7YlE7ucBrxB7 IHb+L37y3sJ1iyYBLkJuHURMEMkFJeBue/P5LTA9lT2/+1/f2J19rgX+efif3uI6xj+kEq5B ri8OU9v477h1GPaP/3fqUW3RIM7HX2kWEieuQC3KtDtLYIcMu0JwVwHTrMDKHMA3lsXLGsoo WWlzBV3UpemPOG39Pv6GUVGXyrzFhbzFqMlbEM0MR21xopoXHW4X1fKRouISCpmirodvu+2h rqKiroduu+3hrqLsmVWngTv+JNAzAwNnstknn8xmfzBAjz30zuPp9OPvPHTgrUMdHYfeOoD+ 4fF0+ng2e/p09tp3ly79LmiYXVlOCHcc+1FE1iqK3g4PmmCdFlq1K7S0VgsOZ1GRf4tBuWKY MFBiEAzUaXAaisNVVKFpepDy1BB2jFi3e3Q0fCd4sV/1DWP+XzjqsXPo3NUzZ86PChO3Ty4r ZVAzV5PrIVtD7HMBbSaiAV4X5o5/8f3lX7tz1ZxQqKYlOndBMLYifaT33Y9K2m5/+MQg/doP V3313q27R7vnrJwT8PtfgekO3/PH01/Zdvuuh3pUG9k78e/wNMRxTBqUgp32fXa607LPQnfr 9uvobm4/R22HhzUjGqphOm9CBKjRuF3Goyz/mOqwxCbHQnPdnuegCpDI7Eq/v3J2pGgO+84p nBIuYmnX1ydNJ7GQMOn8gTlkEVLGsxOXn8OvFr9KGQY4RiW4FlMyFLJWWanVGvEOKfq0/qCe 0zu3m3SF2zW+6wqSQ9QID9negotaIVJE7YIjUe2AP1tnam5/euulX//6nUvvZN+2FtWVl9cE zOZATXl5HWZ76nj2i1MrYRC6YBGsyX4re/LAW4c7Og6/deChd490dh55F+U3F33Aj3B9TZLv KTVrZ8HyWcDPcs0qnsUZw/5weZgzFvoLyws5DXVTmXLdtRtqaYsEZaWK4EqVlpIUc7We8xWq X2WmQUSXKzjHNgfic07OoXMU7LnZZKpO2YIwFNwTpMFqtybeoZSNFAuODmXEfNBMzSNsyfX/ os8/puI11CG2OzCGMCWW84JjMVSnGKoT6evLz+3JFThqT3gCiKJrmX4hlpsEdu4csNMyUWEG +lFl3yNrqm7parA0ltgqaueGVyzz1S6dVTXQHq9ZdU9ry8ONjSFL6fRaX6q5sH5JTd0tbeVQ vmBnZ4XZbkfnd6+t0GttnxWaVhxy2CpTty1q2tAqO0y/22LxOkzJRHhacUCwx1tvUe2EP7uQ D6FMg4jCn1TKvIXg9SPidnnoPhOgW8Jr92op0YNB30pCQigUGg6NhDSOEJNgJapoKBQncWDY LhTnkun4xTitiivxdHw4fiyeiZ+L68qI2HoFXTPVyBusKamgI2CTxA6vFEsLFlFOT7oi+JPb W4ipvgia7Bs+yCToU70QMYfOS6IBrhCmQHd10ursDO7BEbGmYeG08y8nbntyqHbDTOAARsev rFsP98JgQVVDJLEivKS7dzl3j01ymj/407aX7m+zWE0lsTLbBdU7PeFtzM7Y/NVlEVEYT7pf JXk/jlvD/RPxkm8oTlzH9biaO0HvBI3gFiinPztxVbEYzCn9Xt0lHdXp/H7W5+LpM1IDfqCC X/Gn/dyAf9h/0J/xn/Nf9GuJrZWtZ9TFFLOwKMW+itchplzuDq/N5upwILScMIBB0Y1oUUr+ C/4Lfcxfy8mJCUqFfYiY+1DlYv2TQkoCegs4raa6aBf8i1aur6mdmQx3LGz1f338tbvuggP0 w8KOlqrsM/cJUlgY/+kNtwz7W4oKIqp+Wb8SOULhCIDnJk/MaFJMaRMdMB0zZUyciTW+EHsb NEHGdM502cTFTQ2mR02ctkNPpnhioK7LeT8MR3bbtikO2Mm8w9V7fZNAbUvhxG90lzVziIve qvx8vw1W2KDEBndZR6202Ap1FlhhvtPMdHaFCepNsFwLHm1USx/UQI9mo4bO0oAefUlqqOWg lUItXU7pOoASDggHZt5s4cBmgk6NVtNrNrnMZhOFTqvN2osIn+OoQBRcC2zAibZaG9WawaIl Zs5GbJxZq9Hp0MOQVEgz/pKK9kwIrBADJcVN+GGo6SNRi6kzxL0Iebhc1p9n1KwqvHGf+wmD Pog5XWKxiiufEjVqypmzL6VMIiQRcyHC+vZxBFzHvpWKsyrg6IQIOUDGnZyCuyCGSUimxYi+ BsUdIt+Fr6cY+kqqdWDRTZdYUVZ/MlfyWeTC8yIDbNwZRGUMWbLSeyebm/xIhEuM9yaR7hXP iFQR0yKNsRYDIjxaJWbEc+Jl8Wq+4RGbgzVzxAYjKC2OWMFqFUxE2+906Dmbmaegcd6AbQyx qdiNmcxYX/8kwpqEYdcB3CQawwgqP1MihsJWT6ZgQHjVnojn0Jg3jn4QQ4H2xANTMZe6V8sW fLI6b6JX933pMUDEMAnADJAApxralN12d/Z09gd3Z5vuoL3fgADMuheSY8/Aaf6tazou+cVP +c/8bW3+L37DCV/8nivEsGpj75n4d26fisUSZKvSurbqjir6l5d/TcLlFt0a/BctaL1cebWS VtbIq0hUQAcxoYiiSx4JLy7n86Bg/LUcmIn7L7C1WPg3th4jprEnhAvVwiRs+zJWcEa4urnc X4A41Abww8icCp+vYk4kjydM6+v7S5oSAW+io66qrSDWs+joqt/8t+IFw+0r/gxiwLeg3mcM z+5rabm1ocDreAWiLs+p0/PvGmx3e9WzrImPeXaLx0qyytyZZphpghJDrYHKuhpmLhGkydoa LdVpPVraTWED7ALKAXMEObrIoHcZDHojEQ1PG6iBwRarPUWYrqVM1hSHRsrAcRreet5KjVbh qPCS8LbA8UKx0CQMCnsFDZ8PPCWcF94XdHUzMHye5XAheQfLoW68lUSiqWsCsFx0QEAvRAgJ ipAWeJ3GqCdch1ljM6BryHQ3d0gA8ZynEWO7FFu3Cufz3gBqH6ropOoBqlv/VPWaBPfsw/1j 9sHd2Tsb4TfDv3tzCyS45V8czsP5/6B+/OZsMTeAsvPQjUpMtJZYl1s5jRU4xH50kcXqslgt iltKWSzM99so7hb3ixoM+tjC8sVEysd82+mfXkvt9MGgDzp90OKDGT4QfSU+Sn3wqQ/O+M77 3vdxT/vgkA/2+WCHD1jp5997P/VJLqjY33wn9ZQPDvvA5Sv2zfBxKlvhl2+ktD547X0fvOL7 Fx9ViYvP/yzV6cttRJaw/IC1IJ83fB/46HkfnPYBHGOV7PUd8nEDPmjydflolQ+KfSD4gPfB VR+c911iTTqWr/6RJ7+TCrE0l48+cZG1GJ71wYjao7cxj/LIYylk/ajadsmX9NGf+z7yXfNx vI9xH/Q95Tvj02454/vER4+xNuWorAVa9rqECfxK1hQsDe2+lb4Dvmd9P/dpUFCT9c6c5MWr op1emxPtUlQbxuIpHzfM+jAjl4f44H1W2899cBAlMOwb8dEG32IfJT7BF/JxeqMRJ93L8DpQ AK+FdhjMNrB2RHFhILhYVvehv5IYq0eLxQ4rmDnLebX4qFs9+XDO9KnU695ubIq32n/dj1Wt ZUx1f2M3ubexmPDa6j5Erg/EHriXuaVYT6IGGIJnNiLsBgbiG1A5SyGzqaBueokxmKJvZdOH pTn10201KamSkzUGi/4oeKd/8Z7ObDe9mX0id154HP2eP3DnVF/09heJPHH1OcGdCjO4ZMWA JODLw172s7kkC0sqxYCOUTn2itgO+xjqoBpNWanraEBgJvBYGRwsQwuuuiO5Ix2ckzlvhD1f Nn3cl92mRV8yd5Evxf/MxtGv5nJV+nyVuVw5XKh9ADF0PRdWFtZVt1bTuumt0+nG6O4onRlN Rbuj3MaS3SV0ZkmqpLuEi8p1cqvMRYvriluLuY2e3R7q0aMNY7OWiiy0XFgn7BQ4gTllEwZL arlunW6njuP02ogYoYZIa2lpjbe13glap+ikojNZkgRfEkxJ+PxaEj5IwovJnyXp00lIKlf+ kGpPgiFZlqxPcm8mP0vS80l4Pgkbk7uTR5LcclawLNmW5H6W/DBJX0rCM0k4moT9Sbg7CeuS UJ+EGCvvS9J/+jAJbyfhQhIw277k4SRlTGh7cmWS1rO6zpxNIWfGl25KQl8S2tVmfchqfZfV +mqSHsGMI393LKVyfBxbez75fpIeTj6dfD7J7U3CTtY06EpCYxJmJKEkqUwAn4QzyfPJS0lu J+ajt6jpJcnaZEuSwz6/n/yEdfbV5BtJ7ghrGSYPJnckuRa1eiy94fcsF7Ac9BDr1j61xVqU G0X6G4w/oLhy9Q8mAcVSnJyRpKIqzVcm01l/96tCa0pCbV4sM5HDvyQBziXhqeSZJD2QhAFW vCnZdaN5F1lHIZOEZ5MwzNrUhE3kLiVZKZpODidHkpkk35AEkgQ9qWplG+vn2MZ6Ta3i7Zhp qyqNeJ01HbKYcBd06i1CRecUrykHoK4f4+StxE07W/2TYOqmXa/Jyb/65pQpO2Grp+6TxbZ9 Of+NErFJuvAOvtUtfDQnbNGLqf+u73CpDpznzw+TtLoA3Bz/0unSisqOHYHQ0pUDFfWr5xez U6Z5jcXLohpNLigvkm86caqf54wVe28+d/I43dOlG1HRPt5yw+EBdc8shjgtSu5Wutb7YZcb duthnR5262AXB+s52E1hHQXbKqs1vOrloteLaFEZKYPhMoiXgXelTRNE++TsP2wDm5H/IAz/ Gob7w9AS3hmm4cJ+dR8nwYTQkOib3LNnoC0RH7txqIF4rXga1OT21kSPMxKdBlMOfZgFtnJc /Jns/zq7Zs0LYHjm0T+s0fYWNDyxfOPT22fPHv7W+q3PVIVWamN33P+Ia9X3rz1xBvTf6yrz Z3/0Siw+56HfPv21Xz/SOrvsnewJe8BjVX0rGxrpH2meJBE4oUy0FkFrGDRB0Gu9WmrgTDJM XJPhjHxeppJ8QD4qczYZ3pc/kendGHlW5rpkSMrwrPySTA+xYLtMedkl09d+Ll+T6VPyGZma sCB9XwaWn3bJg4wVfCTDefmSTCdLxmTgMcvP5bflj2TukPyUTGPySvluLMurDK/IE4zVphwp hhUdxbzXZE1QBmzmxk9yta+UOVkZGEzFZWCRTWqjNbLS1Z1qkIHa5KDcLw/Je+STsrb+igyy 0tyWuijDyzIQ+bmDMpUZ2GiMTUu9zio8JsMeGQbkEfkq63oQ2y4JNr8t0MpdjEAkUhyIdITd pHAx57e50opNCApxtN0jBpjcKFKvTFSri3g1u3CQwHWqLz+f2Crez5btqX7M5ASb6gZNTky2 F9KvrvbOSE3d5Gqm7iGpelII7PKCOnW+8cgjM9Y83CPGK0usSqEh6BFlv+3ll4+MX17HNTVH 1976N7dWcxodf3mzwSbNWdOyf8O4yOYDQk1Sm53NfcxLZCZpI8vImPKdWC3srtpfRbsroKyi vqKtgjNW+CvozpJ9JVTrEl0lLs7A+/gynisD8AOYAJa2UmmmzewnPCUOwUEdrYuK66lic6Ye XQSpRRBaVLWIpuuB1Av1oXqOzlxUX79oJuVXhFbAHJsSVKiSShybBtP8BF1GnWfxgkTVbJgd ti0ILogv4N4LQzo8EKYLwgvCuuZ0WUF6sS53hmjP7ez2CRf60A9COM62e8f6qrc6PJiASdsY AhIuCGMMq7PvlPmHNqrkuljrPMws5bebdAEuCZO7TzkkUTeNqwE0V2ErTG50AtvfK1G380SA 0/W3f+PWUGN9hfE3kW3B4MxN31hb2hn0gitU4X/726en7/rZ49ueXD9dqppX4pheEaQvNM7J /qQs7prR07x424JI9t0FjfPamxvmwsr2t9K7O8u1OgM3FHuy5La5S+7uKtdpFtoKPNaRB+fe t06JzE5XFFZPi4m6cKKpLPvDeFVgQZlnWrEHmdN127dv37wZX/n7KcOah4mP/qPSrnOCzuFx RB0cGlx71M5ttEBUD0a9X09NzbplOvptgFbdCvTQrDatzqq1WXVt0IOAVSfENaDVaDWCwQJm zmJg0+YuhC8GySWBVoLsJxK8IX0g0TMSPCnBXumQRJdL66SdEtckgSjVSvRV6Q3pU4nDDCUY bZH2SU9LmkvS+9InEve09Lz0qsQdkmAn0mmT1CUNSpyWFXvtiPSM9KH0mcSzQtQg+SSqbjDO fO75VL3UJtFcCxh72iNtlI5IXFJqZznLJHrkTSxJ9+XY75Bgnbo7OaLcN/pwSiuJEv1MgsOs 5G41rYs1Dmv5AFtKL0nwigTYXtZSioVrJdYlzscYY40bPpXgKQlYTw5LnEsqlmawNgOr61O1 M+tynVE7jO0B1g36L/kmHGiYn9opwS0SgCKlJcrnGNQxgdCLrOLzEj0gwbAEg1hESkqUSIBy vizBIekp6ZLEDUsjEqVpaUCiDRIQNWmxNCTtkR6VeCIJUpXE6WxEaCVuwX3OfdHNu91+scNH BIve3UFsvMnpBm0Hb1M369gpSe6KiGq/MJg/BuufihRy+yyxmwDEl/HGDYgwaftuWLkpfIRX Y9Vo33JT2FHPLmnYHaS+/gENu1tH+mDr5HaNQXWe0X/K3bHTuafeTBoahHW3X4b5XdnZdf+4 vS9b1jMAX4GfwEFPY6P48fjvmZ2DtvRnN3YZgUQI0RDNHCKQhBLQrdI7qhyKY9hxzMHTXjNY +m2cuV/RjdABo4OwnRc/27BWb2z8GxoQ0NnD1bV1zgSXbwV983Ww3/tEoLO35FrbiWfpD/hP /NcOWrXgyW5qk/id/jb0jZZOfMyvwrlYQGLkoFLg8YPBtN9ER7Vg0LIrfS5CZEEeljm/uiq1 ojcgy5WkEkilUBmq5JLpyouVtKpSqUxXDlceq8xUnqvUkUIobLXpgR3bXNRzevUeX4eHlC22 WYSi9I2rfPljnK2IRG5styOcnF6lyli9gJI3hp5p3BzI3+CD/AUUO1tytPRdT2Vd87SLv6je +PdDm4courIo6/XZw9l9gURjJLGopCxV2TtYw3bar/xp29m/apFMpZUVtv/pbfz8grcR3t7y WE+J10nPm4w/VfFIM+KRX+M4mMh8pZL0ajRmy2ULhCxVFsUybDln0YxYMvjh+i3ASNSk7ddz RNPPOXL7y9VsUy+3v3zT5R63jlacGN984gR97MSgf8ECP38Hu3PJfNSJK9mFtAzHwYnjcJ8S ChREyY1rSP4yMJRBmauVRCETvZi7raEIBiEVjVawwThXebmSVqpH1VZ7KocDl9pI6eKYrSit kEKhMFTIFY74JLaFzyCBehtp8sSInR/19bGrSMIvEDLffGEjQLn88lOT8ARUL1y9U0nLvOUz g/kbR6EgfvVzb3skXdkrKzGjyymWh11Pw3/hP5maA7+fv3rb1wcqjPrfbNObpNlrWrlHi9Q7 WMUTX2huVXW/hKxS5j7gg11eKHXtctHdTrjfCndzUMrBXRTElUEC77HdPIGEECiQUl1vEHFQ cb92oISL9JsHwmwYsIOoWdvUA0L1jtX1xXXGNBoDOzsHY2slP7m8Mqo6TLwnue34lgXeaDRW OLivM5IdfRI0Z29d+OS1k/X37doU/QDH74lv/Ove+mvfopSDeaO/4hLNfzf+4lPZ7/fiqpSf WUyPXNkW7mPuBInQsBLw2cBrgRJjrZGqm44rdOt1VKNDnWjSIP+Jq88bzKkmHni29zAfw7h4 pwiIOtDptERPdFro1C5CpgDEYPVZqVWHVDAQ9NcsgoUaLbLB7/OX+Tkz5/f5tKBeAjHbUqCV S+QWeZ/8qqwR1eByeR1Gn0bCB7JBi4Q3ZO6Xy+XD7GuQy2T6mQqOX5R/xsAx7Jb3y3STDG1y D0PEYJB9MsX0n8lvylRF1GoOhnRpmVwvt8mcxHLBkx/Kn8n0bRmekRkv7qgM6+SdWDXi48cO pxAyvymzLNwFGXL4/VEZsKLFKkqOy+prMULlRxEqvy5fkfXbgnIDguc98jfll+X3ZN2N4ISs lZW1wylmrRSZqxthYDqkeFgEAzLDz8fkc/JlRNF6nWrLxMLSFAqxOJD2Owssei10mIw8uyqf SOSvX4/ZMciucmxVHdGtq/tyy07/5GryZc9VXUpY9ngskYgncB1htzOq7fW4oCQS7Np2TDgv PKDPrSR9UzxTzdQNWR3kLpTdmHJ18Fr2QbZB++5Pt0CiKftwqHHJhuaCMlkWZ8esEV/ZnOqY t5AbUjdt/0SN6r2Moc6H1s9CHdP8/j6Tuby1vwZ1MoRrTB3OMzfpVxr1/YZHDdTg7KWWtHnE fMx81cybBQqUih7iETxVHsXDh/CV9gx7RjwHPec8Vz16BzdgMRg5J+0nOYPHxAU5W9L3Tt8F YRxf06uY0cvv8IfZ1UHAWedxQ+2vEn/9t7K0UuNZJcnf2zn9Vzhhhsz6z+DO7P7P9MZrj0lt 6h3miTHNIWxnmHQpM5eH1oXoThtspNBLwdw3oBlmG3GRqogSSUeGI8cimsJemwhDIogFJq2n X+/jyBo783cnN8nZGjPlMok8acbcOvukuZuMosVr6bxzUfEZ+K+PT9/5Xw8/dPFA8+N0z4mS jt13TV9xVxvnVg9Z/tBz4sGl8+/7wTZOo8bHFt69Ik7y6zg/prZ9uzLf7lrl1K3SOvGfJ7Aq GOmK7IgcinBKBGgIO0Btnl6w28UBm8tls/GegXAwCP1hh3WAJ2zq036eY257vE8YYx+BbW2w T3UcV/5qBntw9VePXYQxgW0+NoB60Z2d6aPEw3UJDIbtk7un4ciJE/zOlaHQytVdnovQH+zp CWb/fnzulu4GW/1K57W2nP3KPvsmr+Ug6zqUHXx8/BqHkT9lR9l5PeKFEK5TAiknf6tEdxXD vhDsDYInGA1S9Nrv54AUgaGoNWefh8kI0TjUY5LpRkuKkApSAaRCqAhVIHSouFhBqyqUinTF cMWxikzFuQqd29BqK4cr5RPltFzd8jdYU+XmxVHRq0kXCvYOJ1E9rETunH7r2H92Tj95GJ+b PipwcGkn75PnFzR6zV/dNq2ktzC0rLR2Qdw1vgdxg0YjzmldENl4qL+iftv3dgz88X743br9 SyN2+/h0vb52499y3/HMy35H3lDlKHCb6ndkdm374f6F0cL8uH8Fx72A/DflWa+0KuMHvx/M q2ymuIkaTIFM4GKABgPxQEOgP7AnoDkZeC9AhUAoUBUYDhwMaK4GwBYIYurLAb7u9cCVAA0o c5RUVSCN6SNYnP2xhA3Ls9KvY+GJgO4KvqjK+GQACPJSAgMqN61OhF5tyAteLxkQJSku9otD IieKWveAYcgMZrOu38CBtp/PoxZVxdgUyWlXH1OvHFrO7RKoWwPCv63OX7phQOHGDhlTN77o ur5R43vjrd88wa9eHXLPa1/cOsu2G1qZqtHZ2VJpUse+PsbxPNDxt7+bnX0CdYvh3zdRfj7E AHuVpbuL9xfTjT7oyx99pLwbvNTmDrppjwtaXeBzu9zjXp/L6/V5RVfY32uzgVhaVXqxlIax 6z4XGQiH+dAA6yd6FP1ePv+HNQgNGDRjZgH1R/hp7r5v7qjs3qlX4qZ0MK82Ogb2DXkMwTSL mk6M7/7mCfqV4799cFZBw/qFsO6r2Y7sKOhCLVsWPfTVxZvnF9KZ2YrJTtfdOrq0YdvAAk9W kNroTHgovX62d/xfQ8235/6eroKcgVlwkJbQx7lS7mvcf/APaYwao/ZfdLW6v9O9o5+t/8Bw j+ET4yzT4+YC8z9YvdYHhduF/7D/3nHZdbvraXeV+zb3/xC7PE94fu9Ne3/kW+j72L9FPQXJ /eWei0EmNFJ+/NX+2d/W/9ljuimGXhux5sM+9hKRqxSJlhG0dSTI/l8INAtyCa4uk4+hVB/S FBTyuqKAy69Fx8Vp56jHTIq9/8+V/994ePKG+uaZfK7eNTGB7xB7Y5wnXxbAzQ/7/yHY/zNh /RLddz0kqnwIkVC3o6RMpYXVd1B9W9R3Of7KqPNkitxuPAZSikAvhK5hASnENulIEQngOPqJ lhhxBSboM9jZX1oSDzFjrJh41VodSKEY0rK/a1u48Za129bs2Di0ZenabRvXVTYO3T6Yaxsc RM7/bx/9zdGr5OrETYTJ/+HhY9Kk+S/ExW8nQfpdEsZvgnuYtOC3jtaTSjVMSCP+drAmYl6t tp4MYnw5xnsZnSskczG/H/OyMqVYdSHS72GDgrRS5Htc+11Sh2UHMWxDei2rR7OcRPC7FMs3 0+9OXMX0YkxzIT2E4cl0P//vJILxSG4+/B8e1iewf3Qqc/If+m2z/0iCOSG8NvouTH6zB8Yf 039fL2BevSpzfP430ZtnxA0KZW5kc3RyZWFtDQplbmRvYmoNCjEwIDAgb2JqDQo8PC9CYXNl Rm9udC9KSFVKVEorTGliZXJhdGlvblNlcmlmL0ZpcnN0Q2hhciAzMi9Gb250RGVzY3JpcHRv ciAxMSAwIFIvTGFzdENoYXIgMTQ5L1N1YnR5cGUvVHJ1ZVR5cGUvVG9Vbmljb2RlIDQ1IDAg Ui9UeXBlL0ZvbnQvV2lkdGhzWzI1MCAwIDQwOCAwIDAgMCAwIDE4MCAzMzMgMzMzIDUwMCAw IDI1MCAzMzMgMjUwIDAgNTAwIDUwMCA1MDAgNTAwIDUwMCAwIDAgMCAwIDUwMCAyNzggMCAw IDAgMCAwIDAgNzIyIDY2NyA2NjcgNzIyIDYxMSA1NTYgNzIyIDcyMiAzMzMgMzg5IDcyMiA2 MTEgODg5IDcyMiA3MjIgNTU2IDAgNjY3IDU1NiA2MTEgNzIyIDcyMiA5NDQgNzIyIDcyMiAw IDAgMCAwIDAgMCAwIDQ0NCA1MDAgNDQ0IDUwMCA0NDQgMzMzIDUwMCA1MDAgMjc4IDI3OCA1 MDAgMjc4IDc3OCA1MDAgNTAwIDUwMCA1MDAgMzMzIDM4OSAyNzggNTAwIDUwMCA3MjIgNTAw IDUwMCA0NDQgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDM1MF0+Pg0KZW5kb2JqDQo0NSAwIG9iag0KPDwvTGVuZ3RoIDIyOC9GaWx0ZXIg L0ZsYXRlRGVjb2RlPj5zdHJlYW0NCnicXZBBbsMgEEX3nIIbGGMTyxJik2yyaFW1vQAZDxGL YEScRW/fmXHSRReDeMz/A/zueD6dS95099FW+MJNp1yWhvf10QD1Ba+5qN7qJcP2JFnhFqvq jm+xfv9U1CTAtPN7vGH3OTo56XcPrAveawRssVxReWOCTykoLMu/Vm92xyU9pZakXMbQSmiD FKFlnAij4MQIhCgIhAP5hpFxYO8wE4qYdsqPffBOJtNOeUdT3czoePKBupOID9ydXZCyci+9 +/VA/gJn8fq6hkdrWDYJTALhIHLBv0zrWtmlqdQv+2hvsw0KZW5kc3RyZWFtDQplbmRvYmoN CjExIDAgb2JqDQo8PC9Bc2NlbnQgNzA0L0NhcEhlaWdodCA3MDQvRGVzY2VudCAtMjE1L0Zs YWdzIDQvRm9udEJCb3hbLTI4IC0yMTUgOTQxIDcwNF0vRm9udEZpbGUyIDQxIDAgUi9Gb250 TmFtZS9KSFVKVEorTGliZXJhdGlvblNlcmlmL0l0YWxpY0FuZ2xlIDAvTWlzc2luZ1dpZHRo IDM2NS9TdGVtViAxNDEvVHlwZS9Gb250RGVzY3JpcHRvcj4+DQplbmRvYmoNCjQxIDAgb2Jq DQo8PC9MZW5ndGggMTg3ODQvRmlsdGVyIC9GbGF0ZURlY29kZS9MZW5ndGgxIDI2MzY0Pj5z dHJlYW0NCnicrLx7fFTVuTC8nrX2ntlz33Pbk5nJZGaYmVxmEiZkEkIImWxCLhuCMkDAkBgy YEAQlXD1VksUEAU9xIqIYIV6OGiVHodLrda2pP3QU3/WSt+ipx61pj3YnvMplVqOb18xk2+t vSdcbPt9/3zzS2av+17rWeu5P2sQIIQsaAgRlJm3MFmD1M+KGfRr8U23LRvU8ssvIIRLb9q8 MZRukb+kBR/QvLRy8ObbNvw6kqPpiwjp+ZtvvWul1t58EqFFuVUrlg3g89INCK08TQunrqIF 1iD/CEKGr2g+uuq2jXcW3rcHIRBvXXvTssL7BujXztuW3TnIS0IjQsYQzYduX3bbikL7IvoV Hly7YaOWX3mY1Q+uXzEoH1jyM9pepnPaSN/kRgrfhGxoUP2+5kOOIi97jn967Xd+7viX6P/H j6A99qEj6CR6BL2H+goV7SiDVqNNtOTqz0/Rr2gp+2RQD3oe7fwHwx5FL9N6rV0W7UZP/oN2 GfQEOoH+7Zq3ZNBt6B46l++j92AKeoPCfi36HAR0H3qNjvo5Lbvu7w2FrfRL2+GVV5W+jw7g XWgOPkczT7IanMQiOo2egqV05I10nY9cXvGMvxl0B7qXfi9Eq9BmmlY/fNNX/4EM43+hq7oX zUH3o5no1qt6/AgOEiPdvy50kML0p2pZcqJSr5Bb8EsYjz1GM4+im+n/MqBrx4+QmaiVtwM9 mXLbku5FXQsXzM/Mu/66uZ1zZisd7W2ts1pmys3pphmN0xum1U+tm1KdnFxVWV5WGotGJoWD RS67aLNaTEaDoNfxHMGAKtsi7dlQrjSb40ojilLF8pFltGDZVQXZXIgWtV/bJhfKqs1C17aU acuVX2spay3lyy1BDM1AM6oqQ22RUO6t1kjoZeiZ303Tj7RGloRy59X0dWqaK1UzFpoJh2mP UFvRqtZQDrKhtlz75lU727KtdLxjJuOsyKwVxqpKdMxookkTTeXKI4PHoDwNagKXt00/hpFg Ya/NkVjbsoFcZn53W6s/HF5SVTk7Z420qlVoljpkTjcrp1eHDK1mU0e7QscqR3Y+/LKIlmcT 5oHIwLIbu3NkGe27k7Tt3LkjZ0/kKiKtuYq7zxXRla/IVUZa23IJNmrngsvv6bzySsjxMTES 2vk/iC4ncv7Ta0uWFUp0MfF/EEu2U/Du3NkeCbXvzO5c9vL40PJISIzsPGY27xxsoxBGmW7a 6+XxH+7y59ofXpITs6tgemGx7Qs6c875vd05HGsPrVpGS+hfcyQ8zR+2L5lok/lH1YgCgoKD wjQcZgvf9bKMltNMbmh+t5YPoeX+40hOJpbkcJbVjEzUuBexmqGJmsvdsxG6m50Lu3fmuNjs gUgbhfGuZbmh5fQ83cK2IiLmrF/4w5GdDnuoIblEbRuis5o9sDqU40spWGivqzvQk8K67BTV jPUL7XHeT19QaneEGiJ0GDZOW6QtW/jbvKqIDhCqqswpCW3ru7pzcitNyMsKe9R2rDpJeyzL 0i1a3apuXy4ZGcy5Ii2X95NNq231wm61S6FbzjUrh7I3FXrlkm2t7M2htp3ZVm0KbKzI/O5X UGp89FhtyH8ihWrRklbWWJpFz1Vp287ugZW5YNY/QDFtZajbH87JS+gGL4l0r1jCDhqFUMUo fV1YfWMOz+rq7lwY6Zzf0z2tMBGtgg3Hxdq+Nkyk268NQ49cTogJoW7sJ0toQ5EWhNppItIy g37n9DGB/osU4GopO6otM0Ld4EcTrek0chWhthWthXYsf82gPDtOs5SJ0XQsS8eZpfjDS8La p6oS0+pQ4cW0h8CAqkxUkRilBLQM02HUIgbLInbmQ92RFZElkVWhnJzpZmtj4FGhXACGCvPC XnVdk7sKWBRMKEyrJzIMmLn2hP9q4OY61PzlrPK16tkT1aGdQqRz4U42eKQwIKIzn51D7AjL 0+x+FfsZPkfal1Ekphit4vPOY7LMcHkVQ9udkdkDOyMLu2eorSkFudd/N3uXA3VCZ1dLVSUl Zi3HIvDg/GMyPLiwp/sVkYoPD3Z1H8eAZ2VblhyL0rruV0KUV6ilmJWyQpYJsQwbaQHNCGp7 /ysyQkNqLacWqPmbXgaklgkTZYBuehlrZeJEGaZlnFYmq2XsQ3epaBWFMaXfbaEBtj/fWLJq Z3YJO+NIohChf5CDSJpCJ5I+BlhnzhkjK1pypkgLK29m5c1auY6V6+nJAAmqKu/eKbZF/qeo ijFLKvvpw/k2dIOwJr83v0+wspJrPq1qSSssQF2UF/N0siLltVTu4Ey6Bioz4mOG7E9AT1s1 q9+ngJOXwOgYvD0GoTHYcgkyl2Do8+HP8Z8vVARfvHDqAp73Wf9nL35Gqj8D22dU5jgvns+c z54fPH/ovM5o+xTM6BOw/+fotOBHqQ8X/Tb1wSL0IczIfDj0Ye5D8vL4iNzzoWBq/xDIog+I FBRHQiPVI4MjQyNnRkZHLowIQz8Z/gn+8Y+SQduPgj/CwRPzTmw5QbLPge254HM4cyB7AA8/ Bbangk8lnyL7n5wcfLKjJPjE3rLg6N4LezEbvm6vxd7e/zhs+dbub+HBB4YeGH6ADG0f3o5f 3HxqM96QqQiuvT0RvL0jHvSmihbpU2SRjowHWc/W5bHy9my/HOynjXp7qoM9HRVBZ8qxiKeT 5WhDGwmSZjKPrCW7ySmiFxZkSoLz6f9o5kIG2+YF5yXn0RWOyss6w3SgOYNzhuaQ2e0VQaVj WtDWEexIdrzd8VHHZx26/g44SP/aX2w/1U7k9opku9xeEm4vVvyLpJR7kZiyLaLiySJIoUVJ 27gN22z9ti02YkPNCA9JwMPLMHysa2Ei0fmyfpxyNyHTm4MHc7GF7Fue35PTPZhDi3p6u48B /NOS7Y88gloCnbmahd25bGBJZ26AJmSWGKIJMXBMQi1LNmzYmGAfSCRochP9RolNtGjpBq0Q JSaqUWIDbNiANmyABKtTk7QEbUiwYlbC+gDtuXQDYl+sNqG2YqkNG4qW0lPYSiW6AX4RPYF6 NPkYoOSM43pOOF9zTMd/MOM4wTSJjhFWzLPi43qd4asZx4GVp+xheyxsD7fiUD4K+/Kr+EVf vtDKvaXiQ4ye7J9SXcEDf5bHeYvbErMQo+ATsMHmhbzNO8/b793i3e095f3IO+4VLnhht/eg 920vGfSCzRuk9eRtWvWZl+S8cNALQ14IepO0E0Fe+OVa74u052deLsNaJ73NXjLuhTNeOOWF Q15opt23eEnIC1vooKfosONePuuFeV6oZh3g25+prZPetbTdi15OZD3fpgOOe7lh7yEv3uKF LGvZ7MWjbLyJyfIhtf8aOt+31Vft9sKVGWuldML9dGC2Hq7aK3uxvCPoBTrtj9gycl7cz3LV XtxI5zw60YUBZLeXVLPMqPeCl2gjq21DtDUbnA4wokJj0DvkxUFt4XTgjHnInDOPmDkz7jfs NpwyvG3gDO4ebEEGMBhcJGskbtyPHKj5fA39SyX7UpAc+0Wf+Iu+wmcd+6xXP0sv5/+25HKu 73L90isD0PSUapoP19XbI5N0NojQExIpm0wSYPe4ofGd1NbjMf8s7qlWv6Nj6drpU96p83NP mIVfQWP+tV9xOp5cWuOv0+ipi+olH1O9sxzlXkEWShUSgqhUuBpcuMgFBvbn7rCJIInxQ3FA cTE+Eh+Ncw2H4hfiOM6oiCtRrSTjIMYhE4fB+FB8OE5YxYngJEVtkHBKCgp2DEUBRcVoKDoS PRMdjeqEaCxTjoJuMZpxTnKX8Lx3gVGkgEvZU82p8zU1FICQXNq37nxNItFHAZCgq14nfrC0 73wNA8WU6gS4rFifJqmaEuym62bQqC2NTKKFhVxZXRjaAQguztxwQ3Rqz8zY+vyae+cvKm5O T3VsyQ/c8TDUkC+s5YlyixgtcZa03NI5ttdbVeXFSxcu0QkmbszJcjxWmQ9GmfFPSTt5DQVR HG2Uqx5ywT4nmJy7nFjyl/qxochbVFH0ZBEnlCpBkylYiSohPVR5qPJCJalkEJk1R2FP2ROf rMRAeVACCWViMV0o4xV18+0SXX3zeUdDki68jy173dI+8Zc1SfG8utv0A25XCU7VpHG920oi kybjutqpbPkBALpsd7h2MgbO3by+r6SlJe3zzLy+u2rTdwYqf3mqc+vyhvwT0+bXeeFb9oQC 7zlmP3BzEy8YddNsfskif/OHd33xefnSpzcvgKeSi++ZO/eexaqCilHX+Kf8Bn4ucqIydKt8 3ZLY6hheHF4Zxjr/Yv9KPzF4lnhWe4hRD0YL8ASowmoy9qIS8JRUoApoDlXIFRj1VrtkF7a5 gq6ki7j4/ojT1u/l1PXStfadZyv9Ld3aiYWytRaWWkcXpW5qrSMNdLHgcLuwFejqAUMsvvLo /fcfvTkev5k9V8Z/dcORi08/+Zfne3qe/8uTT37+fA8+9PDvD91ww6HfP7xr9NtdXd8e3UWJ 6nOZzHP5/PHj+UvPL1z4PDApgeIB/zKvIBvF3v+WFZ0d7FabaDM4wGEx62CBWTT36HUuPdWl YQGtyHK8i+N4v0jVW7NdEUXuoB5kfUaPU3ogepfLBedc4GLbXt2tsKdsS0xWzrgAZ11nXBco GFhdKKrWnfCVaG1KRafS74KpHHAWa9Zho9OgABU7RSyIVIs36zlbvxEogdFQJJVa2kcPTB/N MThSZtTXv44enPXiL/opDO0NTcnEuh1FYmJH4nThIY6MQJ+4g31PqY4xPIEUqPhCwgRIGN7K d+yDN34C7z8/9sbJ7WMXdsCuP8Cv6+ooDfnrJcFPn7A1fy+3amwTox9+ihMfkqMogPbJSzwy JR5mwwwDNgszBCzYdB0202cm7DIFDwUBBcXgSHA0yDWgYChYHZRpmpeD2eBgMBfkQmpiiDbM BXWoI6cxKjziPePFXpXQCCbFq/dlDAGbjiywuSRTxupmR4guvlkFAKUT6873rbtCKNTjROmE lKqZqpIDRhjKCqijkoeGzkXT7pz2T5C6I/8nIZC5oTs6tbs5cieUgHnhEpuI/+it+mq/t2qu OKnYUdKyuhOv9FZpdHP8U1zF3Ye86Aa5AU8T7Aqngxf9MOKHZv88PzZaO0jGlXVhl0uPiEhC hAiEM2cMssGqGPQmm9s+HzGMp9Tulwk2+6V9KcowxPM1fX3rp1T3JfhJpXX2SF0zpNwpd8Su LYLiPVyf7b/n3hXN//7vjdWx2UHblMYW1/qb8WNVZe+80zW2ZWaLUTfT6LIZNfpOJV+ym+Lv JLRFXhQrAd77uBcLZkexY4ZjroN7yAZxDlwubFjrmzTJF0VROYrlaDZ6iNJorjbcGsbhairm Y2zwhHc7ADlEB3Y4zBt2eMCjw+HNUKQyu77zdO59dkcDPYYpyqU0umVvSE6pRhSX++g+VEBd mq/TKDRjWQybJbfLyunDZPdXb6747o4Vs8KbHyhpnJp0RFrmPrb4gw8TmY17jg3g448tffy+ zUN7+u5/0GBzGg8Ddnh/8OyCh++794Eneukad4z/J9yF3mE0SvaivcgIyCgaLxhJ4SEYbQd4 JyowlPWUysQo69DoZxozAgp3OUNVXl9lyOkMVfq8VSHnjd7KsNMZrvSyDK1ktPB6etaP8wuQ BYXRsu8HRZNN8b88fkFuMtuUxe6VbmwXaeoOM9xlhDt1cAcB61oUQRE5guVINnIoMhrhitbK wrBwSCCCc4NJH9jAeyeoID254m/p3BjxS1BUBo3M0UEdqRoHKZDBCQ5AjtfdemTd2d/85oOz H7zsbbxp9pz+qW731P45s29q9OLDz+W/OtYLA9AF18Gy/D/nXxz+/YH58w/8fnj444OLFh38 WD0blLbjX1N+Voe+I0fn1Oyswd9wP+zG06U50t3STonj6cmLpcgM31zfN3wP+ziqb/xG9hgs SkmRwazEZNGtxGLOdlQfqod6hqLVJWFlXn1//Yv1pKq92GQqdlbx8Uy4trS1FJeWhkUxw9ea Wk2HTSRkApOJp+efHRvxfLN68h0N9Pik6LnpSzBQpJIJyuUTfUhjB9qOldWlPCX05EylfEGn bZ/kcVPhh4JKR4Gjw78u69q+NNl7/XRL1ZTg8pa+FfHWG3pvaI1PXrihrfX+Gcm4ryc1f1G8 rfvG7rY4CM2rOytMNpH/49bi8vmLamZWBkpKZ/TMkgdaI07zW7d5ijKtkxsrSigfu5GdgXB+ LslRmIVRNRqWV6xO3pXEugBss++xY8o0tpn2mDAxgaADMExSrDVyDaCaoRrcQBOZmsGa4Zoz NRdqeC1B5tVAQuKKO1BYDIfCZ8KcEA4XZ0r8kzNOKV42nzOIKMPUII3I0XOi0glG+vtUOrde PTFL+wpc00lJmqcgEanwKi0rIQGNuoN6gHR6uwq9fWtAwO6Gljml3Q8vT9Wu+vbq1LoUEIDD efkOPDBp5tLG6ttK4ytT2+4klOTVOwJuc/qe72/e8MrWdpPJHAwXG/JFyWQRuX7lcG/cLo7Z BcP77EwxHLmewqcM3SaXCfoH9ViwPGjBggHAS2EScDrLmFyQliuGKg5VnKm4UMFXsKMTjFcp /RUvVuDFgZUBHFDuMj5kxMaijMsmlk2az06KSuVVPOmbkIwocVnaB+ryYxMCkXYi7NqJuIIv 9eR6n7JgSfzu791eO+vOf1k+f1+6PhFb3TDzprZIydz7bprUMavR0+AMOI2zhl7ZNPTKHdOc 5vyXR9y+5MD+NT2PrpzGG8x6uv8JeggcqjwUQE/JC9Eck/GA8QUj+cR4yYi3GcHo7TC5Ei7c 6ep1HXBdcnEs1+h6wfWq6xOXTnTJDU2KK8gFXUHccDEIw0HAGZXnjQS5YZrATDU/UVWtqM8i v/qURYuo8AttnC8TsLm8GY9b0zAo3WAsf10/Uw/EDxKMuo2dpUeDHgr4GokjV2Tie+wl5ZJU VmK3l5RJUnmJ3fidvPfQdkhwH11dSltdms8EYKrgVbG9baZrf55/BoXhRdli0Hl1FToimCIw FmFzXPrXS8quCNRGWiMDEbItcjZyLnIxwg1GwEWLumghx742Rk6qFTpTxB/Bv7gQgdNqU6L2 ZfXk8ERfrT1L8uorjLkTitrtKTVr3ndAORCBjZFtEawWTHnoEeWFCLBu2yLEHwEuAhcj8GoE 2DhqUSKCaeEa1mBPhKi9hlesUjon2r4QeTWC90QgEellLV0RzErejBCWZsvYGOGnX4rASTpH fCgC0Qhb8EZ1OJ0YAYwiEIpURzKRochwJEdJ/oWIIEZCNDtCqb/FUtxBNGwfYtheHM4E3ciX IV6bI2Pot4LVagCkkUMN51WMrzlfk6yhm9s/oScWtMLEVVpigmaX9qm60kQTtYTRB2ekrv5r xNJKtQYmV6jH4nfPPJOYv2k2JdpTqsTS4kilz/jll2/muV2ke0pZyy3fuW2aSXjrHqMpOHOg /amur74IV1WFNf1Aofi+jvyUakRT0RNyeE0p+D0JD7ZKaQk7QpRDBhxVDmx2gMUOwIFqLwoY 7AqlNUKxcWqHbtrQNOifBvI0oIkpHa4ylRoYrUpZ2TwqQJeWTkpkiovR1NR8o03SZQzuSRkk qjyTwYdKGExjYlJHMiEy4W+9+AGlj2zRCY2TUt4xoSGWXSYSXDNoigXTnuvS4NRbidvFJCz4 lXx7pmpTPu+0pZT+6a1904pKps5e1F/9iDU8LV69PDZp2sxd725tXDyteHfrTTXkp0XTb+oc 2+6tWmorjxTFO2+eke5Nl0kCcI/F22qKfe5Nb1nd+RIOOydn0rlg0YQcQWmkiWqSD8szthn3 GDFvhF3CAQEbBdjFHeCwgYNteA/GOgyCWaHshp4YLIarw5nwaJhjOTlMGsMMWNLMOcrBMAyG QQ5n6bE6FOayYVCrrLHJikSVmYxB9GeIVBA1zmsKNaMWBf5xWediPENVKiX93wgc7/6eiRvv /sdJX9PA7DnZaZI0LTtn9kCTD97/bBzl//ynr/73X5Y9ubq+fvWTy5bvX9PQsGa/JoNSVZL8 jq43gl56BQn0AMQNosIJINhEKkfYxA6T6RMTlkyxwzHgYq7Y6di5GNdwOHYxhmNsFUWJaiUR A1cMRmKUXMZgMDYUG46RWMHMoDaqYmYGX8cQJaSYaRohmjhDNQydEAxlIjafaApmrAG3FyHX Av4fGxr6rzU1JNSDBP9fVobW4uu6uq62MKRn1Dm25G9Ztw7MJPs140L3wv4rxgWNtmI0h56J P/KPIB+qQN+Q61aWby7H+wQwCA8J+CkOHuHAzIHgQJEOTwIloIP+y4mhxEiChBJZNcElGBiK qZLpV+bxwHsyPrczI6GyjFGMIBSar+5/SnxDxR2VkyZUIeIywqifGBU6Q/YCrZhMmqCgNmn6 OFWjVEkL/7py65L8ltQtz6xNbajDGOBpaN2Y/2s+GGvNNs64JRa/PbV9S3ukHn636dWtbWaT iULSdrGo6stXvFXw1urhJWUeql0Jhnfp+aigANhHz0cRWnOCM4IqZiYNNsUZhLWwhUklhg5k Fa0h64j1jHXUqhOsQV+/D8s+WOxc6cROUqSawtlpwrhItGUcNoM1Y57gkow0vJHqg3XrVeEp 2UdXm+gDSgiv3UYmOuF9ienFstwofSffcscd4DB4Mn19UfJa/nbB4jCOtUzs2SbnlMqSwtxF um8GtEMu5zsSCEwIpveiNegedABxftSLXkVvIo7lXkAEmU5TyZed2+Z2xaRu2LRGZdhE+YZJ NGVMh0w504hJN0wTF0zEVJAF1IZmKgNQ+ocQnyGFlYHG/BMJSvQ0vZfpNleO5VrG1w9Be/tV ZizmHxn/lGPRJFbwyyU9xluMO42kB92C8CJhhYAXkRUEEx0nUSKkp+T6BKU/usITXh7/+QkK ZQMj41GaMMICQNBpMLoMBiOGBYJB6CDYRQg9EgYDlKgNHRa7YjAQown5qfxEJiFRpAv6gZJV kAgdLC3by9uVURFOiqfFsyI5JIJaWheYpIhiSKwWCSfCYVqJh0TAWXFQxAJBgpGQjJm3yQbg DSsM+H8MYADMlIoU5X4UuT2Uedb09TNemGAckqKy+EvKTVW7CNO3rzWNUKGJ2fyXsh59fQaI sLPv1hvUBzmS3zEnf28WXnocHKB7HG4kt3x1P7mbgtY/dgfeRZ8Mtt58O/krhe0k8uAryK9B zceAYKEJqai0CGOKx9zL42fkySa7QkViO5EkT6CkRINkoMQVCJRIsKA4UNzhkVwejwSSEICS ABtknHLOQMBTYqDnDlcgORBWUHRJdHX0rijpjII3WhFtiBJTFP76SfRSFD8Z/W70jSjZFYXF UaD1UfmP/7fySRReicILUbgr+lAU90bXRHFT9Loo9kcTUfxu9A/RL6Lku1E4EIVHonBPFNjw WIoCHfXnl6JwnnV/I4pf0GoeUl9siML/iQId+b0ovDkx/uZC30S0MdoZJd4ovEvHVieF74nu imIDq91HO74f/SSK34jCSdZpb/RIlMyOwtQouKLRKNYV+tE57ZW3R2FjdFsUL46ujGIchc+j cDZ6Lopfir4exQ+xSshEs1FcE22J4onuq9T+x6M/i+LDUfhWYYiVUeiKQnsUHNFJ0Zoo4aJw kb3qD1F8Mno6io+oTbdFYUF0eXR9lNRGWxkcSqM4+vL4kJxpU5TXo3A4ejKKJ4ZkLbHarpRN Hui7p33BZgjqy7dF90QPR8n6KFx+dw3dFDYDAHVQQ6xcUV8eZcd/EVWnM1FQB6RTOxMFPBgd ig5Hc9GRKG+LzotiIWSuNstmYjYXI0/Ig2VPxpP1EOQRPdjgaQqAKQCO6sBIAKNAKFAdILMD bORJ8iyFD0BbYFFgRWB7gAMpQCKouIR4MiGvTZxv1hUzE6OKQnYPxSYmLFAGoRlQaigJpZkC XiU0ofQqF4b6Saxbd41z49rar9Vc7Qu5Ur702tZMwp0oFX+Z+Md4vEMYoajcT7Gdmf8SBtDE PmY6kJgo0wwaYvs1xN6bfzTUMn9Vm69s0iR3MhysT7Q3Vku+/P4snNyT/+IxWEoxvXf+wzc3 Yl7Hv5n1lLYtbVDIoIr5a/FjKuZTEQd1U9x/j5L8WtSBlsAjsueuNlg8ZeUUPCVEkV+Z0j1l 1ZQHp3BT2A4YaAkuEkxKDeN2VkFUouW0qIwVWRiqLxZsisT6BacJFiVUTlvoOybVTNZFOLRI iU2SvQElxr4mxSbFinZQzaG9TvYFlLq6ToVyoVcRcMiFsAH1dvWC3Au1vRDqhV72bseSrDLU Cxt7IdsLJ3tP92K12H9dl3KoF7heaOZ6t/Ue7iWHad3Z3nO9HKs/MVNR1Gddk/ZMJNWn7KTH 9PILcKi3ujDeZJtPaUjPDlQXQZEuUpPk4iSjBKZRnSCoJBVyyASKSTHNymTi4qyMs7jg/WhI MovQWzXiebtHtSZSIayvn+1+ghm22Y72TZwF5jOgPI/y9/N9as8E1QEcngbmMdH8t8yP2wcJ JtrqmDlEXwKpsGp2vKwc108mdfWlE2qyp95D2xAq4oWZRqDJvqCamy6Lw2Tlz16qWFjcTJSp IO17rO6OkYfX7F0a91alo45kvPjpp2uX/VNP8fRUqeHDyK5J4Yr2jvwed8Rr9TQsn9OzdXFF /sRtve7k3Kn1102RpOq5eOszRwy6rfaSbRtn3rusMZJeUB1urK/16fzx+knH57w37675FTq9 gaxNDJdu+OqHDbIjWVvnjTbGiyLNi3HDvVua+2aUlMzoa27ubw4yHoTHP+V/QnmQCz6UxTWY 7klFlXKLeLe4X2QixX/JHqtd6eR7ebycX8/fz5Nn+OP8z3jCM660ibZ9hP82j2/h7+ZxNw+k 1AVeXIFn4yWYk6yl1nbrYiunM0rGUiOR9KV6TJmYqHEvm+iy2UQqB1ht1oIcYIEFHOE6zRaX 2WKGBSbe1KEzu3Q6M8+ZrRaCwTbVBjZ24o10Vnqbx4YF88vjLx8vns0essk+e6MZFplXmDHN PycvscxOmUFnlszYYCY2GzETnYikqNQqdUlElICT4KR0UcKHJGiVNkrbpD0SVy1BVIIuaYBm DksckqChSzpHWxFZAhZicIZyWXamKyoV9pST/qBySoJBaUg6JJF+CUISFex0og7rLMRKZTUK gYxDsAHmzDaemac8KZVaJlMpemhrVAo4YZm57NMVf0mpKaVZyaR6jPsSqsJuT6W0P418nd1R dDUtuyyaaKSwv09DgAQlsFRCMU0IKX5IaeSMX5x/7fr/+nhO/tW1cOqpj/6z6/fv7IeVTFbB t47tKcgr2/GKsSfwfQWZpQwhDlEZ1gs3yOJW/WN6PM/Wb8PzUD/CDnpeThgsip3t0JM0YSmn 29Ro7jT3mkmjqdPUayJ+AwzoN+r36InqAOP0tXo8gEGvF6xWi01ns9IzYOkQ9C5B0Fv1ehFe 1J3Sva0jOp1lrQCiEBKqBWKj+qDgl/1ZPz7kB+QP0XTGP+If9euaRH/Oj0V/NS3I+s/4L/h1 iCYH/cO0fIQW6P1s75b0KerzukXas65BfcrOxBTFhsSOrBuQW3SH3ERwq5K3w624pYwXCRaR uDM2ZNVzxOR060CzudY0pygtoXvKlKWEqiHWJFR723pVdX6L7SzjhSlHgz21Q6TE57RIeY/K fSa4IKVAqixZkCQ1U+zVqmM33Lcc5m7KX4Tulfkti/P5ewbyW+7YBVPgNTjor6ry5P809icP ld/h8R35z6/xRyPVH/EIElEc7ZZFU4RC0FZkw1ZC9U1cwhjLdMpOkKIPeUJYDFXKlYAqhypx g1g5XInlyizNDFfmKkcqRyv1ITU7Usn5TB0fxUH13Tsp/4lbMzHJZzTy8wOiPeNCKp2uYWok 87idr5kwRKvuW5Rg9lhmlZ1w22r2ZlWLVP31Ba+PZszH+Vjbssai+qk1jvitqZ3fGNv1ECSB anxV910/8lbtrf+yrvqmbE8pXFi5a3GMM5iFMY8g/IabXFSVzzmn1NUVRRL//ekdpx5QTA6v TdVt5sJenMVJyo2XyS7MV/PQym/kt/GH+ZM8v4eqxapBYXGvMsRTnYuHhhH+Ao9lfpAfUgng yIlGWVEbmSJlyhaeakuvwI9U31Gfxn/6VRub+Msp1U66p3OxC/Y++aS6H40Uj8J8EzKjMDos 33vYftKO+SBs9z3uw7x3uxcLRuzD2GosMtsU1FMcsUWSkbWRLZHdET4ZaY7Mo5mDkVORjyJ6 W6SfZt6myfGIbhorwqzxFlrL2SJB2ngLbfpiREcxqifjBKeQtVjsfNbVLxGrs99eCEFhHjgt mmDpxKllBp9EwWPANikBdpXFXTmSE94D0hOZN7R0+aqlW64L5a9/Z+zNg0fhy0d+vL46ufaH O0kus7EzOra9quvu/Av5FuYW5p721TWtGV64YN/GdnUv5lCgLKfwMKGfyPWox8VH6Q4c5jmO 7scenlj4QcuQZdhCWi1dlgELES0hC+YsMGq5YMEnLactZy3EoiJ0holEI/INrbOVrIV1Urvg agtwFpclaiGNnKXW0koH2WjZpnY8ZzGcsYxaMGaDVlsylqzlkCVnGbEIQ+rjjIUz6fqpDsn3 k4lwHVCtP0s1tNWE0OTXVWq3Hl46OvZfR4/ioqOZiUXX+TS9+vr8a7AF/Rp5UNNJwz70hHqM woJd4ameK2aZJ1v3bf65tYYtht0GYsg6B51DTuJEzGV68Tz0JftOJ8YK3kl9XZpZKLlChAds Cc/euLB3kaskUuJqrSuuLSua0rh26dyi6wJd9Q6v0+GNFU9tcFc0sXkkENJ5yWtoBnlV3s7V wbm6i3WYr3PXxeoIVwvnai/WYr7WXRurJaYy+KTsUhk+VfZ2GS4LUUnTVA6flF8qx6fK3y7H 5ayEK4VzpRdLMV/qLo2VEi4G55hpjo+5Y7EYMXngE88lDz7leduDPeoIEnwiXZLwKeltCUus RP/y+M9lk7FEAZ1dF9YRkZGmM1SiJXYQiBDtqKiYVtShc+51YqMz3Z7enMYVaXClQZeGv55L w/9Kw8n06TR+Jg170nB/GjamYXkaulgDKV1Ke3Cfp+F0+mz6XJocT8PhNExNL06vpAPtTfPR NEhp4NJwMQ3vpv+QxqfTsDf9UhpvS8PmNCxJQ226NY1L0+BQm/38C+11Z9PkiPrCB9KwPg0D acikoSUN0TSVFbWmtOXv03A2Da+nIc0UOM+Lx5UF6eVp3MqmQJuqM8Rq3fjhZ5Vn0sfT+Ooh FxfG02a4j83vizQ5nGYTIHvTsI012ayOV5qemsY47UhjupA/aOvFL7Eme9KYrXdzmky88As2 q3Np/LoKjL0quNj06TDV7E2udDRNVl0otNpIX4dlVs7mQujw76chlx5J44H0tvThNMlos2xN E3ECkmfYBOCFNAyrk2xMr0njkDY0nqaOmk0fSmO6RzLbSrpEuXcPXdS59MU0N8Q2b6P6zto0 +NUx6T6PpAGL6Ux6MD2UzqV5WxoElOoYnAZoGkxryMywOYuiFSl+WqZMmupmrtIFFhHV1FRp Bl2VJ7GvVKrAtBnLnlBUryiWX9dCry7u/zsVf0etTVyr117d4G87T6isZymHZPS4Zko1001R X4IpJuvYv/Z3bU41Okuev2t6lv5fAt6Kr1vQFW3bFAj1LOsvZdEsd+UXPdy5yNfW1uy2P5Jv 2bVoUXFTY53jkfziO+4Ap2aerm1wlIVc1xiplwhGCzd15pW8arT2XjZag8rvVlH6LiIqvPN6 tx4biOBwsLNenR1QdA7JUepodyx2rHToLjrgDw4464CVjs2OI46XHK87+C4HsHr8rgPUTg0z 2xRWjVsdXQ5c4wAIOcDFgk6gweWodQw49jjOOs45Ljr0tAgPOkB2ZByDDuJgXCJWrqhPqgM7 VPHO6VFwT8Y8ShUHsPRTRaHfmGFCJskaGcnXfGxq4NT5K17UKxK2uoUJxufpblGRLVwztd6Z IgU44zveBuHep0vSMx2XPqbsYAYv+C6tsurAk9+icQWNJywmN4KfwojA868gnrlkLo0rZ/lz /EWe/EwVR4Zkw+dfKIv5lTxmuROffqbKHyf++Ikmhxh//7EywMNirfEPPvhI0fHwPku/9O5/ KFrxyIlfvaO1Nr/5tlLLt/J4ktb+xMjpwjCvnlI28vBuQQRa+P1XlNM8HOFf4jEVi1bzMJVv 5zHj0ZiO/88NtJ184GmFlx/fp/yB/4LHq/m7eGzgvfwr/Bs8N8jLW+5X6GgP8U/y3+XJ5sK4 xuUr2LgvaW9/aXGPsrIww/mLtIlYO+cpUSp88Q4qd2lzbGxWq16aOl05UxjHXF1L06NUOCNY 7R6Mat293oBi41/kT/FEgCerEbuPQDVOTCW+5rf62GZS3Er0r0usp9+q/YfhLDMXMBF+XSJx GVfpJieY0zSh+U2ZrM4QO0EFuxSJLH4tPYdvygfp8M+M/yc8Rn6qxkA+84PaitaKrgqiRi1Y ZrUrqEKswDPOVgAreYlZ87WkXFJVrYxWwMmK0xVnK0h1BZ0jbRqqIIcqchVYbeKwiIoL7S0Z NA4Zh40kZwQjW2u4VDGq4rfkVw6yaCYQjN4DEbEQxqQ5rNjK1qvWkXWqeUR1WyX6/ja4yf71 YKfHnKHKK8FO2vOa/NeDn/Cvr9SqFdrZpviv+x0920Xou3IIisx2BRWZ7IoHASCLRSiyenqq HQxFicPnY+txU5Sc54N15vvMj5rJLPNC801mYmYWialUTzFjTG7MCkMCFu63fMuCzZZiC7bo sL2IGPqtZhMhDg8R+hHYIAhYcIOOxUGmllIFmtF7leo7GvrUM1CTrGGe34T4AYuWcVCdO5Vi QXWJcOQqSdcAVKArZMnSSN59Ml9/9CjshZPwAQwdPTo2epK779LbE3LeVxz5qs53abman6L5 v+fk55L3yXvIS3WwrXKPybbLdsBGVlRsqsA+AiYXmHQgRL1ID2F9B76igWUqQdO/DlVyVzQv 5U77g3Y8zw728gxIoikaDc63Slif4f0FIZWxNy1m9nIA0NK+y+471AepCc4wtZ6Fj5VOuP0n 4mkLDjxS1b4qv+4+Tle1vee1H9Wu/s6tqTvq8olIy7J00bR6qo7dnto2RN778ocsygf40hvi kepLn2545b42sykfW/loX4KpY/g88+AxOGwhN+LXGJ1DevSO/OARw0sGvMSw2oA7DcAZ4F3D HwxfUJlXnt+lSIZSw1QD+W8DvG6AjQZYaYAFBkrrDdUG2UA4g8uAp58xwEnDaQMeMgwbcK1h wLDRQER1pI2Gw4aThnOGiwY+Y4CoodbQaiBnDaC2xFnDoAE3G/oNmLaGJ5Eabm2lB5N/EnEi F+KIwOkZueAYvah5q08LqPogcb5vQk64zLI1WYCSBJanKj0lCuwfI0oZ8i0F8gC/ywcLsXT8 Dn4uqkAfyZPv4lkIoM4u2Uvt7XYuVgy83+2P+UlMAt7j9sQ8hMLCBnGbLdKjztHLNMJEaaI9 sTKxOcF9kYD/lQAYoRICq+2e2apkEsAloonaRGuCa+ASoCX3JE4mTifOJS4mBDEBOJSQE9nE YGI0wXt7qwWZopJMMUuoiPbbSoOlB0tJaWmJq98kiiaupJ+oxIQF3LEYYi2C9jyztWpWVgYO 8bcJyihZEEn/BNmMqcHXuE5E4b8baKWpSTy38cvhg+Mns7AMFt3/yS2z/G0/XbPpB9+cdf32 F5dNWbaoxXkUPtvaXlp7wwtf/QtkoS9UnB89MqVu5rfOv/C9P+6cbnEVmeBe39Spvsu0ht9F z5cfDcsVFPcFFwgWEMyUMko9vXaotbfasT3QGhgInA6QaKCWJgnzdZyY3qSoPo/JZXFlNAA4 ExgMHAqcCXAGb08Gj2KMi7IGel5MAum38MQr2XG/i93hqNFCrNn35aB8pv2z8OoP+ibCi/v6 UhOqoT1ceGoYyNzmjVQ08B7FdzB9kemNYw8dndAZx/6Mbeyp0RNcN/bmxJ2MenZXnByleuRZ 2cm5Xe6om5gMfkPCQKy8FayMYPoo5zBicOAimmAGV4u1A7ALAKv2y5tESZEkbPHu1u61yOx+ D9U/P9KyGe+gd9jLz1Br6d+wl12G4VjxEM2MqDdj9PPUWsEKRuNBALDgjNlgMNvAmkGShNwU QvTo1KgHqEaNwLGnGEDWaTZP1dxZk0zsuOxbZexpKYMXFGKAKbAgrDpkUqQecx8W108pNQaT +KWxr8Dpb2qYYkslvVUkyRsswo4vp3z1jt5sN72W/xGLa87Pxav4RyiM2uSiMjfUuFpc+E4b 3GkCVfwp48GpV3mo0aro0ee7LWBhqGBxIIHS0mb1rP8iUaPF26rXDTiPezKmXJKqdmqctV/w VM25tfOB17bK8tbXHli3rc0Jf+p69uDjW9clujqefR+Kf/xj8P/HkY6uma98+AWdUwudU0ad 03VyXaPUKfVKpFHsFHtF0uZZ5MFzbD02TCxIplNCzs+pMIqRwMyfssAJghUhbWLMxDSmTg31 s9jpPqcaOM0cWCVYu/3Q0nnrnCqP4Gzbtm7762x6r+fndiXWbX384LNd3/ziw1dmdnUc+Y/8 xz/+cf7c+88y+jz+Wn4uFdVY3GI5VMi/pIq6SUFz1hjvMWKjXBJWuqjoURztWONiPMvpipvi /jjOn42fi+M18Xviu+IkGocX4u/H8QvxV+OX4mRPHExx+GUiviaO4/Lx7ytx+dnnlQFW6o8n 4uTpT2grfDp+No798U42QC9rWhtvjWM2AN6mDnCb2qwz3qu+5ECcj8u9/Uotq7snzl71fvyT uK7xUJwSN3YBKRSvjufiI/EzcV0mno0P0gyn3UOi0pYtDgILk4xlym3hTMDrV52YTF7SAuP6 mQlMcyL1TVyqKgiEWo5ZMdeN/eIsFRlVY+bfBFEWomo1T+JU7Q7BQyxg0qMFTnpYAKUxMe+2 lko5lvSHaxpnPAKpv4mr/PLcLU9kK43Cv91W/M2HyUjhTgEe/53+IUrjXPht+bjeBh4r3GOB bgskLLCKhyIMPIBAeFhgMpt6dLxLp+M198qNzL1itmiOlx7N8QKwQLSJNyJw0bEfMIPeXGau N99h5gw32G624am2dhtm7pYyGzFOOFKQ9IYEr0rwXQkOSPCQBKXSYmmzRN6V/iDhk9JpCR9R i++RYCXzp0C7BAbJK1VI5Pcq3bn1vd8qzMWCH5BgAXO61EqtEpEkSpbgcwnOSfCuBIclNhS5 S3pIwnSACgkkqZS+5gHpJYk3SPD8f0v/R8KS/C/PKW9K77PU/m8r9JWr2fsWS7hUmkpbEtVh M/yY5rCJ7diluCTQSfCFBGclYKO9LpElEnSyUol2IevVHmvWFlw8K1crr0hwvwQwKMEA63VO wrukA9ILEhnUvEVYlsAlsVWob5Mrqby/SwJZykiYo6W44SKD15ss55L2SMQlbVQXd1bi1Q51 Lo/ilxKUFhAdkSPlSlK9UUv8BCwEiGwuUiro02KxWkUT0vU7BGIzm1XVgDYuOPddZsDsT9We rEVKrbmV6rQcPQ5OJgCnUn0JVQOYCGirSaaSKdVSkWBW64nbg4kJs0Q/U3ou3ydMqA009eHa +4iJr1tKxNevuK8YJf+a2/3rHqvLIgOLpbkqnCZVcIe48nPq8ofzB+ryrZuoVAXNsLoKboTq X8GPuD99+Rfy1FcDvIWxyK/mkWe+WkqO0XRBFuAqKJ740O/kOezGa52FuM0xc52ZeN1t7kVu TNweD5hMIJiKNxZvK95TTLLF0FrcVYzPFcOZYuiixSeLTxdzcjFEi2uLca4YilVukW5TULFY HComjRztd7iYqOWN9dOVkWJg7VzQk9GN6rCumZ1blHVVe8HrTbr6XWtdxOXSObMGZAazWd9v IKDr5wrm5cINB8Ym2SWfpKamrGOK6tIJe4PqIqT6TEMy1U+1GsabrtJWJq54hutTNAnPfTT2 04NHyZ9aQqHepV2e92FXsKkpiHvGvpjQV/Kn3uN0BMZ+dSg/8Iwmo3IfUx6QQKtk94picAdi gRUB4i6KFa0oIjEPi0FRnX3M6SeX0YQollbJVeDrreZlHvOMgfLufiNi19KMXGlpsB85VVOK FrGsCZBaZH5CDb/lJ0UnA2WpU6Oqc935dWmRcX4rIbrD+fFjN/YdA3yk7e61A0ldS0n7K1km LrZ848T69Lpl1/liM3XxW+9+wHXjv156+iQI3+syWB3G/Pv/mkjKj57/3r7fPT5HLI65fp5/ zexxFO4+eajM+Bijp2ifvJqITjEiEmE1FaCYP7Kn4I9EPXq9YEMu0RVyySxcX0ISNGekrIRF qZo+CMP2rDQkDUs56YKkt2wRdgsHWfgZCILF5qIqqR5ZCWc3XrXdBc+hqqdrHrJC4FnyfIPm KQQ1MHtie6+ONNOT9nfGHn8nX/EErj8J98Htz8PJx7CYl9W7dz/E51Tp8XG8RvM8AHpo/FNy ke5rI/pYfsYVjAZrg8TkhAQ0AvYBGGt9tXhbEh6YDO7JdZPxzDhwRa4iLFQ4weigaGIFM3Pn Y1tJsASLJSXmnilNqAmmjTZdaMKo6UwTrm6S6YOU97gpYN3VbtmdcXOCe2U5dJXD1krYXAld lQOVOFYJUiU8JMIc8W4Rm8XKcs6n758KMNUZ6fehIASDPu5yeHtSDda4TGPUK3BJUVNs1fs/ TO9AfaqzqkBKVL+qM+UpIYW7obq/d+NDd9nBuGtmxNm68MbKuYOzo003fXP7N29qmrHxu7fe dLxzZqRyKDNnTfukppu2bN9yU1PDhu9tSt95S08YVn+/KBF2VijLpytLZ1ZNnrZ4S9/1W5ZU ++z5/z4ciofqOxMzFzdVJht7t2b79q5pMLt8Fs0W0Dj+Fb9JtYeWojvlrk1e2OQEk9VvXWMl feQ2ghvIbIJNlPhjgx+Dgf4hsKJeeuA8UjkVzJrlcgiVw2D5ofLRcqLvyURGIzgS7ddlS0mk 35z1s8NFxZnCdbGCwHKegekKhDSfngYgqOFKgAIDOAaNBKiEhDu84MnfbD9Z0j6nM7rl+xvr x/76LFh+cnPX8/mxFxt23L+p7ChVWp7b8+8Pt166B2MCnY//llS0P/3VDw7n/7UHMBTMmxod vpeuN4yG5IV8wB3AvOAWNlE9SrdWt0VHHDqHzhOMyJFMZFC9/cbbPD0ZGKVjNDMKImVt1S5w uWw2zpMNl5RAf9hhzXJID3o97ufIFSNtSrtMeA3ppBhlV6OF2OKb4W8pZNg+oVuEqRp2FaG8 JSjLwfxeENK3dzfbGlqcl351LcG8yAjm2IeEZv6af1qlJQ6qk/2R6mR++Ik8abNrrwvz/u1+ fIvvbt9+H+F9oLq+VG8X3XSHGi9biJqw0ITRstOCDVRbNRRqBFZTzbxrrAthX34n0ll5vU/v ciKLlTe7zX6acupo2kpVj+1OcDK6/HBphTKHh508EL6Ipt2wgPbpNLupBOimsiHt0mHlXVYr 757jA5/PRce10IF5NR7MiAIBedmAwgVcAaypyQOBbYHDVGs+GzgXMLDyKC1kRSdp4bnAxYCx gZXWBjYG9qil+lr6dZZWcKqCHQhrCnatzaNkqIItBuQAdi5nd1n0yCyaQ2YimJ1uH7FmdBa/ izN6RBvi9cScIUY3ataMd1foZSqVXDehZzOPdUL8BaOcjoYG9k8rUzuuljMg0c+8JuvYlWbt n0VgXI7D0AJ6VStwQjWQab5ckxaJYbg6EFAP5K7b84vvfS9/X/5fb4O6/IW18Py93z9zHyy4 Nf/XFndVlQeuyx+jTxH2waMskCb/OYj06c4/X/D/8wspPngp/v+zfIvRudOJD3MnOaze5HjA vteOV8VgfzGsKn6wGLMf68CCtwgWuF1eV1GP2+ViibCt2g1ut6/HVi6Wg1w+WH6mnISZzAE6 F8omw2vDOBzWBbNMvnBTjlPEFa6DU7owYcdh6MEuwlCEYUDbkRDRT3fwlOtQiEwIZajvb33+ egYWw9VhAc+9OfbOwaN4FvP7V80dmAprHs2fyu8AY+n8LT0vHLvxm9dPwnPz3ITIUdO3beF1 d93YJI79l78Oz4V7M7e2FI/9X+GO2ykOnaQ4tJ1XkBGl5bhozphxxjxozpkvmDl0uyzygKiU keEP8TmeF3j9kFGH+A1Eu2Dse0uNPfVRsjelOsbTecfsfF0shTeAYywJzvyfYUet5pFvX1b3 W5Uel9P3jfKt9H1WdJ8smqdJAaVO16ZbpCOLKTTZ1V2H00eFnIyIM+KgmBMviJyF4dgUya9Y ONnlVTijUYDbrTqERRzCMs7gQXwI57AgYIG3bkKEgEmvY7eg6RmmFIrug3aIaSKZTKQSbL70 i+qS9og9XAcpe8pNReEwiR8dex7v3vBS/mk+H4KPoSz/HpRtJ/u+Wr+b1Iz1MT/++Kf4c9W+ /qxc7BSMFgUZRAN9NUe1QAgLGASAeFGPjmHfjWabovPZfEHfPN8W324fH/QlfW/7xn2cjSZ2 +w76XvR95NPNaPat9Z3yfebjTtFa7JMXLlYO+WCLD0I+6PcB8tETLWUtQUeSXfS2OHnUj4km 06ginvi6qg0kJsJJEtoFIvUvoeGR3WXlCloyC/6pg/1HMbdv0rTZ118fnrk61lLibI8/zP1J lex/1rtzYFa5KFov7vL4fnLF1rePrtuJDsnJIn23HtfrwUHJnKDvcTpcTofeeaMai2fWuZGb ck03hNxwyD3qZuFqP5cbBFFxCIYbM5QEMY5E589Tvarfge3EYO1/xwlbnYBZ+AWe74RZTog5 65zYqTer/oSCG/h8waPQr3GbmsRlfjtWs0MlPOxHSAoLvtqpANzWk/DG0WVfvVbwJuDj2lov ObiXLu2/7EwIqjHDjeNfcp+rMUMBuu7zsm8/hl3GA0a8X4S7/Tv9+/3kbttO234bKWMcQ6ES ODcV9k8GfjIIk/Wot0K22pWKipTe1RMK5UI4VGEBSy9KianqlJzKpHIpnTnVVN003IQH6deh phyV5PgmdmSU7ICSbPqsCduaoA41hWirbNNIEz9dbMowwW+Yyn9EpulB2u1M02iTbrIje4hx 54g3O80RpnJJhIT6SxyqT4r+URa97nwDqJDSLC2qfNLHAEjrEpQ+LWVQ067mXR1+5NSSknpg KNm5liqVkMJ15gj5SeT6b/S8/X7f3R2BFVX9e1dfmFyTWJVaev/86FdFVGxZ8ciP1ldXzF45 44ZHltc1fvP1hwd/u5T8tbG7MZDnyzoGxk63r5wVHvsFpiJI/Lrb8/+m7UViwabZzavm1VkM tQvXt9/w6M0NOkY/WqhcfZTK1eVoGjog31bPwrYeKoP9QSgpp8nGEmCqPb7Fcrdlv4UYS32l 8VJSG15rnC5Oz0zHmemD03PTL0znKtcil2st2sKuj9fWTtloiD4UfTJKotGK4g32oJSUmpmJ xO6t2KDjH+D38oQSP9RMAdd8WWlkjh/VxCpqPxPAjIOqMMz8lk7NOsV+GeUK4qnyX71mqwf1 arx6fYvCuWXG4KGB9UduqytrX7Zxa1v37lYqJCdTdd72u3rq+Zb9S7oeXlEPx++7K9zc29iy LV08Yzk5fPPBNfWZZ/P5Y/e9uf+21qDd/l/DBquJb9z2632x6tSKvfDDE99dsL4jVOx97KPH OzU8rqJ4/Ayz2cOjcssaP8zzwyIXzHFBxgK1Fpite0WHV/gh7pvum+Mjr3rh1SKY4wanC+LO 6U5sEv0iNtn8Nhy3TrdiNRr4mNmipMwQM0PGBHWmNhPOGIHDLnarxgVYcJndfr2PUg6L2a3T +3gqCFmYIEXTeissoBVZ3urieauesl2zu4cKWz5as8Z5DyUATpfFr+P0vn43+FmsKJjdgWCg P4BtgebAvMCWwIuBzwK6jwLj7DaFHBgM5AJcoxyAUGAoMBwgKJBVXQsjgTOB0YDevEd/WI/1 L48/KEdtdmUhwxvE88Vmq5Po+/06l4UjooEgKhjx/UXEca0kZIdUkv0eSKKgPjJa+wvGulkE MYs5vUYI+gfCzxVP9+UPmvDiXC3/fC08FZqO5OfsgZ/n73kCVzwPEtQfgR/soUz/rX1j//58 /pDKZvFSLDOqll8OqjsjbxzrVssFde+XU9zJUdyZgXInHqiHWka8NlDilQgZLMrDDjCyJ09A aJzeOR1P9z9QB3VrQ/3+tX68JbQ7hCv9oZC/khjcazejByjipKnMwOKFWFDRaJorOAsN0/0b iotrRJQQEziRiG2o0YsbeOZNxzYjGI3s1zUKvzBRkIWo/s28pxSH+tgFg6R62+B8n72hT7sy zK4LFIy85Co1EycpSUrDxC0A9fdLSCGSld0XyMl3HVt30w87TS1VjumzOkr67mjzVV53c+Pu 3etu9U/vm1XSNK3aEWmJtM/tmvLr9ycpa+e+dBRu6919U22RE3w/MrpshskLN7Ref3NzgAgL DLqh+2cuk0OFXzsxiCb9M88139bVYHI/q8kF/FMUr4LoSTmxCqDO0GbAdUKbgKdb5lCZshhM JHgjp3MxDhnmwtCs/ZALE9bjSUW9GTwtFFVClFeFXWF8IUy5YXgonAuPhEfDvLvHingX5ZeU XXb4bqBCQlZgpjSBMhqTEzUnGEkv3K47T1mlakK8/ANOBaPfZUkAR0LRuoJfbOInnbgdjENO 3vjG/vz/5P83842VLdqRXb13WVVBKvjoxu89sODPH5JaNff+gh3Z2tqlD8wvyAbHmYwNM+XM RtM2E24lXeQcIfVCh3CDQIwAsSIQKHobsL6HIy6OI3d7dnr2e4gHE8HAQpSwoQQDMVL1WyBU waWdOM7FYTPHAFNvcyic/7Afhv3Q5R/wb/OTRj9wfrjgh5P+c358wA+1/lZas9HPnfHDHtr2 tJ+okeZLZjQrIdbY5ccNe1gUu+zHOOSvps9B/5AarT7qv+A3ZPyH/GdokpOMPRnbqA3b3HR2 Yv8mabv0sUQ2GbYbsGSweB10arZ+vWVCwqciZgMVTTwFEb8QspQo/CyceiXmF3R7tIPN/Eh2 B2poEHfwIyOUoPRRmiFoSoC2RwWUvzoene4S3Tp+9oH8VNz0aP7lsb98f2Ts15oX8/7tfBNF dHlsEpXtjzyab7wSADv2IL5TtQlsgOO4h+xHTnheLja5YfxN9yfuS26yx33SjYfcMODe6MYZ quEweEU//bPyiRtG3HCYVQ+7oYtWb3MTKtFF3bVuLBYaBn7zofLClc617lY3pvT5rW3uPW6s tjD82y+UNe57Cjnzj0aUM25odXdNVJ94WUm4Gwu5vue+p9CXYXYdAD+F3EPuQ+6cm5PdF9iw OfeIm9yK3CHV0DWk5kfdAqKZQbXpBbdOM4JlC3UX3ELjME2doWmOveHEwcOK+vynR7Xn/Q9q z7vvVZ9y4+0blbVuEOkgdEFD7mE3SaosR1Rta2fcHJKNGaMWF8RXG69kdGpkkMFgU4x8sw1s KNlHVSMqar1V+MUH9lk/Ee6thqurUU2Xfyvi8sW8iet0f/tbIbintGVJKtXdUlra0p1KLWkp xUfYt1qqPVX76vjvqKrWhKwgy0c6TDBg3GjcZiTtHNzN7eQops0m+C7yEMErCMwiQGCB2WS+ ERPKrYnJaFhg7OE5yos5zkgrGS7vMZGVJuBM7EeCukycycSbD2K4Cz+EcRZDEZ6GMcNaLAbF fhHbxGZxnrhFfFH8TNR9JI6LGImyqsZxjYfo94hIQuKQOCwSJJ4RR5lyx24Vn6hMKupTdKlP 2WayKsa1PPC8m8e8Tb10HS1XL12/RDXGwoVt2W6h5I9go5mya6uecCx6Qrvz42hQf69J/CXl zhP3Q9QrAhrA1WuKLE6gT73hQxHwmks961i0J0XFq68b87nHxj5OjX30BC45CXvh8RxDvC// UvCGxMj7Kq4N4OvJ0xT+djC/gux0iiHBqggy/ap1QqkTHE7gnHDRCe86/+DEJ1X70Yh8ZN4C JeOEGmeLE7ucUSfWOeFzJ5x1nnPiB5wvOV93kvVOgIwz68S1zlYnFp0hJ6YDTTvpPO286CTD Ttjo3ObEagvOydqQk7QC0wpcrQW1/z+tHVtIVFFwzn3uy929e/eh62vXdV13V10f+VzN2yol IhIkEpKEmwYuUqZ+hB8V/USBKUR+CUVERB9l4E8WEUn1Y+FnCEaYH0F+yFJ/tduce9dgjayP 5nLOnDszZ+4wh8udOXvO2XF5UX4hr8mcjjcyZkkA/SVxDqMhE2edhVv4Pc8BVmEZzMoMVr3R rJN4RgSBmOlsUbWJNdHJv9VBugEQc+nVwdqN2lU18lHXuu1Zrru7IFdbphMOy408W8f6XTlE 9Ms+mQ/4hxUSDS9ESJuSWiI9SmolshBOvVJIFxecfUmOpJ48n4kPzTxLPSVdK7On1HOEK0gP 2WRO4LXGjrGfuVbuIbfJd/NbwpSwJcZ1Y3pBf8FgNVw3bBsPG7/mJC0N1l4pJC1JSdu0LSk3 OBKO784ProRrO3c8dyfvttvpvu9O5isFtsJ7RbGi5eKq4qQn4fnoTZZcLln2uX3zpabSdf90 2flAWeBu+VQwEQqF3oM2s6ydcmzHfJEGV3TSX9j7twS/A0c3dgH4whUd4Ck0gLFRf7CJUlpL NQEhWl13IFIeLG5WSvwtfBE01JL2WFVbTUaBVGC2s9Y8xlKZ7/TKtpwyh0knutz1uaE/P/TQ 3+36b8ARE63xQv/s3EynsfbQGu85lQOaC1TwQRgqoANbHsy16U9ERmgEPUaWTb9kWqE06wkC xhvVQE9rj2AWGMSIqxkUKAE/tAAPRSjRALXqyUgxqII2qIFskKAAzOq4WSEPx9GCOVE+OMGL iYgN34EycGDmrwMRXOCGesiFfVy7D2hep7PUDN0XhnZbAHpG4yMTQ1OjZ88cG5kYPa1JAJlD y/8VdNm3O7CTziJkTt9mtqGT+wR+dLidnYGj1AT+DfRhsSMNgyEVDyD9CuJethD6EHtRthd5 YeYBtGO7i/KwRLB0Iy2IvGBmIPOwHEd9DOIApSG/h5uEKOJu1NsroB60IUrOQT/2uyMWQpTq YTvhYsaWKD6jEeUHsMSY5vRrcQb1oQ6+X+W7sH2VylE92NeGdIqXsJSjzWHKy9Bi2K5EHEes 0pm3MKnqABjW3tN9gPqNSF8eLz5aPmlp/QbFmqPfXdsguzg1/+OGziyuq6PAaN1+AnjkM8AN CmVuZHN0cmVhbQ0KZW5kb2JqDQozNiAwIG9iag0KPDwvUjcgNyAwIFI+Pg0KZW5kb2JqDQo3 IDAgb2JqDQo8PC9CTS9Ob3JtYWwvVEsgdHJ1ZS9UeXBlL0V4dEdTdGF0ZT4+DQplbmRvYmoN CjM0IDAgb2JqDQo8PC9MZW5ndGggMTU3Ni9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj5zdHJlYW0N CnictVjbjts2EH33V/CRCmJHFG9S35I2BTZo0TY1+pL0wV75sti15Ci2U+c/+r8dkjJnKMtp A6TYh6UlXoYz55yZ0QeWzwTL3V///343efHWss3HiX/Kus3kw0SEcf/vfsdezWEW/BSSzdeT sFIwbWaFZtbAXorNd5N3/CHLZ6UUlTa8XrmxspWoeHPIJIyFMnTGAYdnlsFmuZCKv4SnwpR5 KfivbqgLIUp+l03lrKqkLvlz9gtO2dNT7n7AF+x7GFeV0KXlbdOEaWUJ6++dLdqqghrA7v0E U5V8kSl4KmHUsPWxuceVZD65RtuwhdtSqrJKtiRzggMKKy1fxYO6Bsf+vZQ5GP7R37oykpOj /Qla2Io/4a4r79VcF+CTT/7qVsC1tuSyHR7BmpbtF+RVsDXPbdlfR8IdYFPlQqW5t8MIncPS bVinRV7wU5ihC83ZAde17LFpgxW6MIqz7M/5m4lQM83mP03mz97xsIdVmi/bY1hZqAIctQoe zzWZEqKkteJb1hKvbvHSHVtg8LcECIvozJq1azYeth31Y3TKzFv94m15gXqF9hNk1ojM06Jx 2ITF0vQRc/avov1kbo+yYOQeny+W2bSAFxWAlZj4RA2/4OfwMDTcbxeilWtThQtEsjrLRwgD Jl74Yo0oLnwpIHbIF7/zOF+I658iudEIgEMdXJCXmq8pFa6MDhDzQVPwA4B6JMFZEsK4aC7i z/qEY6Cp8odVhGA1QxTh1P0iPlz+q7NHobOKHkGusiVB0bltauCxhMsVUeg8SwiPmhqVpqt7 UavgxUsPhiK3hh/J0u01oygvSEBQbRkSqsPAB9MsrOPHcT1exBsuR/WGrdsumypQ7AJQz7Zk l03CUIIIjAtq7bG7lQ/2Xbsej07wfiWp84msged75Dm13JOF7TnhvBOxCjSiIefils8T+fbo UlZIasixfkAFbTbsPSdm7GJKaOFVS+O4Qgx0hAHvs+/idsjhwqtQyaZBiWpIsn/DtLyyRhs5 4DrMy8MckjqPywTacUi0iD2GmJWVBdeTF57ahRrCfyyxU0U4HuK6LYa9Sdjk1hWK07x7oeWt PJsN3DL9er/8jn5Z0WuOXS5IijK3DIK4Ik8Adh1ZS1Z04647BReowmMHgbdPShUHOymTrLC+ iqGfG7TOI45cZxG5OJ76Eg5dMA53IdJKEb+KikUWrruW7MjSZB2rj7Q0jG4jxCBswnLJK8GJ 1Cc1pc+3RQRVsWYYaMR8zZAtDSFLd97fBEpQd1+evcThkfqKkVrtwxFFFD09FCqvG/8XJ/BY ouFp2buLUaLuCZwARdiQ3XZREFL1QNi0JwRX9zU1W1qwTaWh9//Rr4DGAXQQr9kRom599WZy KzhmyC4rHJksZ2+zWDrRCpMUdTTQ+HQzhGaIy3+Pyl0zwqSg1sTb3ZWmOkFJFJy4TAinEJC+ M4AJVHu5oqUhqW9TYBaznJRdgP9bnJkSnjauPqjKqjSQS7Mid7UC/yNzzaItyxt9IPK+pbLZ sleZq06lMn1lbXwYycqWSCHmFO8S4WwgMkLbUy8jtAwN2uTr0KRsc3AojaKd0hPqFWtdtC62 0wasV3ZrgclB9qSxVLcvJVCve3H3cyj3XJkH7ZIrFjHot1oAqOo0+PZSi2Ix6Jn3aRTKJD+z UBpf+fbqOG94KCLBVp6CIxzjCtntmV13br7CxwV9qaA13yYh/4wH4eRDDGcqRMOE51PLmTYO O/RxSIlVJfhjcpsYJlK5kwlNEsjYAS/Gtwi3kibtxhmBTIt+Qsd0GPTkTjFaZ+yVE5Fs2fJ4 VS4XJVT4dcAmztxDFzX7BonzTUgLIBYkQQzlSOoSkrxX0b65DI+tpSIVoOFyRgc8de0PaJMt xtNRcL6SaeVOuz7sq1hNP7EQh14mfKnFcCCqfV6KODpdUcE9Jt9eBt8bkuAjemkrFD9zNC3t VTbJSZdehSoV+XyD8vSEAhJqev+0pjCNH1+Ccm1J2qXW0t4mMxAQ3zlGeN5KFs/YFxLX65CN lSn5X4ehu1271tCvhjWd3wzn+0q369ECpVgSS4oW4a5nkqQ3UBSnPuznuORunlnh6m7Rfw56 PZ/8Bn//AJcLucwNCmVuZHN0cmVhbQ0KZW5kb2JqDQozNSAwIG9iag0KMTU3Ng0KZW5kb2Jq DQoyOCAwIG9iag0KPDwvQ29udGVudHMgMjkgMCBSL01lZGlhQm94WzAgMCA1OTUuMjgwMDI5 MyA4NDEuODkwMDE0N10vUGFyZW50IDMgMCBSL1Jlc291cmNlczw8L0V4dEdTdGF0ZSAzMSAw IFIvRm9udCAzMiAwIFIvUHJvY1NldFsvUERGIC9UZXh0XT4+L1JvdGF0ZSAwL1R5cGUvUGFn ZT4+DQplbmRvYmoNCjMyIDAgb2JqDQo8PC9SMTAgMTAgMCBSL1IyNCAyNCAwIFIvUjggOCAw IFI+Pg0KZW5kb2JqDQoyNCAwIG9iag0KPDwvQmFzZUZvbnQvVlNTSkhBK0xpYmVyYXRpb25N b25vL0ZpcnN0Q2hhciA5NS9Gb250RGVzY3JpcHRvciAyNSAwIFIvTGFzdENoYXIgMTE3L1N1 YnR5cGUvVHJ1ZVR5cGUvVG9Vbmljb2RlIDQzIDAgUi9UeXBlL0ZvbnQvV2lkdGhzWzYwMCAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgMCAwIDAgNjAwIDYwMCAwIDAgMCA2MDAgNjAwIDYwMCAw IDYwMCA2MDAgNjAwIDYwMF0+Pg0KZW5kb2JqDQo0MyAwIG9iag0KPDwvTGVuZ3RoIDE5My9G aWx0ZXIgL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCnicXZDBDoMgDIbvPAVvALqpMSFctouHLcu2 F0AohoNIUA97+xXUHXZo0w/607+wS3ftvFsoe8RJv2Ch1nkTYZ7WqIH2MDhPipIap5edctaj CoRdbiq8PwEoNoDd+K5GYM/zKZ8Um0ZPBuagNETlByCCcymslQS8+buqNkFv987KyhycYyai LqSoq4RYIbaIKmObEKRoeEZAbErE3IxVmnW8msYm/4ddqtcYwS95ybxEMu88/P4hTCGpKAb5 As18YIMNCmVuZHN0cmVhbQ0KZW5kb2JqDQoyNSAwIG9iag0KPDwvQXNjZW50IDcyNC9DYXBI ZWlnaHQgNzI0L0Rlc2NlbnQgLTIwNy9GbGFncyA0L0ZvbnRCQm94Wy0xIC0yMDcgNjAyIDcy NF0vRm9udEZpbGUyIDM5IDAgUi9Gb250TmFtZS9WU1NKSEErTGliZXJhdGlvbk1vbm8vSXRh bGljQW5nbGUgMC9NaXNzaW5nV2lkdGggNjAwL1N0ZW1WIDkwL1R5cGUvRm9udERlc2NyaXB0 b3IvWEhlaWdodCA1Mzk+Pg0KZW5kb2JqDQozOSAwIG9iag0KPDwvTGVuZ3RoIDU0MjgvRmls dGVyIC9GbGF0ZURlY29kZS9MZW5ndGgxIDc3MDQ+PnN0cmVhbQ0KeJzFOWtYG9eV994ZSSAJ aQRIyAwwIwaJhwBhZGzeGkAawOAgDHIkOzYCixj8AgdIYudh1YkTW37RxmunGzfJ5tHmWQ92 vMGJ49DN7ve52yZNH7vfPuy1281mu5s4zmabtLut0Z4ZRGKnm377o9+3F82dc86999zzuuce CYQRQhkojigU7OnzVCO15fuhW7Nx2+D4As6eQwiPbLxzkl9l23AGCBcRIo23j2/aNvFTQUaI siOk02zauvP2hfmmdxEyXhgZHoyhz6xlwO8KEJePAMEQIcMI6XnAi0a2Td6d2u8EdIVbxzYO pvZ7VMG3Dd49Tv2G/hDmK/Lw2we3DafmFyn4+NjEZAqfU/E7hsf//tFfH4X5MYTozZofan6I 7tMEkBVF1f6mRtejbHQXQskPFeyLfv5W9EdtaQuvV9Ab6AX0JLoA0N7U0D50P3oWzd00/U30 ffQiOojOocfQoT/A9izwuVeFjqKBr56Gn0Nj6G70DOz7APB7HW3ACUyhKJpEX0OzsHeQnqHf mu9GH+BT6C2cju7BbnIMZDj2FQy/gZ5DW6B/FfrHFAL5BH2DNKPt5FkqgPaDhlHSDeS3YO9b 0DN4HdoA0TUKUiCARm7i5aJWoofRPQBN3Tii2UO8yJD8FUi8Hx0BSUbRDrQOrU4NnyIU9Ico DrT5Ljqj0g4srtU+T42TcyTt+jfR1+FvFfzFUAx/DT2BnpsfmT+BHsMBHEDT85+hHLRLEyCr kDH5keZRcgBtR91oCEnol8ivsYiBSDjU37e6N9hzy6rurpWdHe1SwN/W2iL6mpsaG+rralcs r1la5amsKC8pdjmLhEIHZ8+2MGZThkGfnqbTamiKYFQeEKQoL7uiMu0SOjoqFFwYBMLgDYSo zANJunmOzEfVafzNM0WYefuXZooLM8XPZ2KGb0SNFeV8QODlt/0CP4vX9oYBPuQXIrx8VYVX qTDtUpEMQBwOWMEH7CN+XsZRPiBLd44kAlE/8Jsx6NuEtmF9RTma0RsANAAklwjjM7ikGasA KQnUzxCUlqFsK1POwGBMDvaGA37W4YhUlHfKJsGvDqE2laWsbZN1Kkt+VBEdHeBnyucSB2cZ NBR1G2NCbPC2sEwNwtoEFUgkHpYtbrlU8Mulu96zg+bDcrngD8huhWvX6s/36fpiSyxrnIzA Jz5FoI5w9cObKYMpitbJfIoUUALzJhKSwEuJaGJwNhkfEnhGSMwYjYnxAFgYBcOwajb52gFW lg5GZCY6gutTykqru+Ss3nVhmTglfmQQKPDxCY5a1mGJLM4JftUwAkOAOcCmDoei+IFZEQ0B Isd7wws4j4bYU0j0uCMyiSojc4sj1pAyEl8c+Xx5VABvdvWFEzLt7IwJAbDxgUE5PgTxtFlx hcDIps9Yh5DItPB1nog6lwepOmOjvKxxgVlg1Y0LIFKUJQlGRUyfLbyusrCBy5LJ1wnARuET EALR1OfOETsw4CvK5Q73guv7w7LoB0AcTPkoMFPlgRWDUXDRqF91n+wRxuVsofVzfypiBUb7 wuqS1DI5u01G0Y2pVbIn4Fd25gOJqH9BBIWX0Bs+i7zJKzPLePa0Fy1DEb8y2dYGceUKJMKx 22UuysbgpN3Oh1mHLEbAwREhPBxRAg0sVHoFtnOoO8qkrT/c1Sd09a4N16YEWRhQ2NHOwJfY CGF2gQ2EnJzmTOPDhKUiMJEBAi8BILQ2Qi/rnGnwMGBwlaqEamsjH8YsWpwNYsilfGDYn5qn 4Dcx1Sjh1NaxyE2roMCnrYN1RBwLraKcwDCf2hhWpClG7VgcopyQCYBGgI1KUmxpV2KeDwvD QkQY4WUxGFZ0U8yjWjllDNXmKV/134TdYCwwE3LA8CKiGFOW3OyNxpXbVfxztONLw52Lw3wi TejqSyjMhRRDBJJ3ykgJYbHWwqqnXznPgjQIhxhOtHqeEzOiqJzlEeXYJoTOWELoCzeqsyGD 3MfuUvbKRF24q7+1ohySWeuMgPf1zoh4X9/a8FkGSox9/eFTBJO2aGtkpgjGwmd5hESVShSq QlQQXkEUTqsBSVPns2dFhOLqKK0SVHzjLEYqLW2RhtHGWbJAYxZpBGj0Ak1UaUoDL9lHwMaQ vwN8TPHPvZGRRDSixDiygUXgg2UsNIN1hOYZTLRGWS8Mt8oGoVWh+xS6b4GuVeg6iAxswxXl uxJMQPjUXqEWEMqdCrcpot9OvpP8iL6sUG4uMVQKgwtRB9z0GhCWQR60FqrCCioH6koixtIp +jr+NFjCfSKVcP8hlXEfSzXcgY8e++jFj6gt1w5cI69fw89cw+y1dde2XKPoD/0fEv0HUpL7 1/dc3PvvNXH/8l4B98+/kDjDL7D4C8nG/fyKxL1+5QdX/vEKJV7xLpeuSHbuHM5GzTgThXCW aGyiQpebLoX+qeli6PWWdGwDEfuhj8FDknPYdtpok+BWtJ3CBJ0DIqMMYOupi03cLLaIG6kk x1ziL4mXgpfil+RLWv5i8GL8onyRNl/E71q93MCFsQu7L1ADb429tfst6s2/wN8Lurjx85g/ X3V+7jw1fj5+npjPceeI55zv3Ni5k+cun9OcfdnF8bNVs8HZ8dn4rGY2OSfmzWaVSsyrmH81 +Gr8VflVOn5GPkPMp32nr52mZnGG6H6hg4vL0zKR5Tn5XZnynPSdJE++LL9M5l5+92Xiecn3 EnniRTz3wrsvkBYzNqNqbEIh8IkJVDIhHp5xeGhkxoxoxcET0RPjJ6hvHnNxj0ouruq4eJyA HKeP2fIkRZ6yYyaL9CdskjMfPXn0zaOUeDR/qSQetbHQGc2S+RHPI75Hdj9y7RGN+TVsRGPY KPLkG4dc3Nf7ktzlaVw1jblpzzQZm949TdAR5gh/hFL48kfseRJ/uOow6Tk0cGjsEFV1EJsP cgc9BynxIJMlMW9iAwhrQFXwUOAgw6kcXjqrAGKQyZYO7HFx+1c2cvsebuIefrCRe2hlknti L2Ye5B+sepCqegDv3oPFPelGaQLcMAaxtR2eXGwPLfHaQzovFdKCQ6MwNgDP2eQVrDvFuSQV ELmsPGnD2g7uNmkptw7ea+GdVZ0Z0mAqRFdToVmcdoZt5MwUPouXYPupGk6chVdOiTSL9aIT GK4Osty13mQvEXtraiWx11ki/SiIL3fjbimf65I6uOAsZsW1eCWYvBME64CnHZ6TEr4sXZNI XMK2amvIgs0hptocgrIxBGeK48w+84B5t5k2mz3mHvOY+Yj5sjlp1vmAds1MjSHcg/CTNqzB s3h6pr/P7e6a1SWhEkkPrpPxPtnZp/Ri71pZu09GobXrwjMYH47sPXQIteZ3ydV9YTmaH+mS YwCIChAHgMmfsaHWyMTkxOSUW2k4BUwgt3tyEt4qoo7Ag9yLDSsIdk9MTk6kKLACsEn3lNq7 JybUhVhdjWADYA3f35QFk+4JPIGUF6xQNoSVeBIBriyaGJhQd1b3gPeGCXVbDACCCZMTC4JM 2Ac2KF9HEHxXJDFNCDKPDlXOYORpPKWj865Wz2g1FxtPUQRANEMpZI1CPqXT5v+uERIBwF6L w+J0WBx+ws8X4UfnRzSh/37RT7+tZrmzyQ9pDr41OlFALN9deKSQ3OM44CB6R66jzEHV5eEl JslgKMYSKooXkaIl2iBny7YakRn5qn2+q17sWX81s85z1bu0Cq2Hhi3ZBcRb3UxqLF4FzBEq qRrBRAmFlUDC23JqQj5xU2fxGUwIfgETilC5zas3S2v39BfT9ddX92xuYStC9/WSid+9XNjV VqXTlNc1ZHu6a/LLb/t6jPxYkfk7IHMR3YVq0V4xvNWOd+bszyFbc/Dm5Xhi6QNLSfvSW5eS ohW4LB/rqVyKaHgrT0o6i4tRh9XK1Rs69XpPB+Ki3DgX52jOY9VUBAv5kukSUlJSyDBBjcGg sSGf18NchW49AwrWKXp6PVctiq7VnqspbRcazjYRRb/iFQWUqvoygEHtZcu91WABXSVob1Vs UUDRRQ3jT49uOH7HqswnjDVdQ3X1GztKveGd7eL9G5t+9v2exNZO01O6yrb+yk/dt2xtadm/ oxPXdO8KVbLNm7q5FS2FBktpS1V1U1lBlqWkJbbqkW/n+zYGsitqHcbjlXUu1sKUSduUeNkL NpLoWxCP3GhaHI4V4RiFO0sjpaOlVGdRpIhM5e/NJ3flPZxH7jbtM5FdGYkM4if9JEao4naO M3T+SH9Zn9RTSM/oo3pKr69woXZkvWIlVhR0uTSOYC6jCTKX9df0JK7Hej2jmmw9mMunRoRi sWoA1q+/2WBYMdhCjKzISQXGsmaimCof40IT0TkqKdzq6t6xcsX6ldXGxxlx86MjE39+f1vP QyejD5y5wzvvrBxe00CRjrRlq4bwr0NHNtUtKW8qqqhY1+npOPw3h078bE9t//Gfxe34J/kr dw9tuL+bV2P9E7jvrWATDkmi+27tPi2hc7NzCb0kewnhOIctXdIzDKcf0+/WH9HTehu1Oo9h zOlW5EtFuvdej51RlVpQB1diAQS2WgSL4nJvAZXjbYYQsOXQVs+m5v6Hblv6ipHJ1L6oM5v0 RJPXHJpcXbu1jDqWZvBPnQjP0+SN2slNq+325jZ/fnNMcul1IGfyt8ki+sfJB+Gsm16hEHod TjtYE/bU1TisGvpvL0ajak44AvoMa36I0lEGEsVCnU5D0xrDSqMRYyQ9qcEajcms7zMgXTDN jOggBYpcrfaBeyyZuM6zA9wCjrF4Pao+TofVUQNZosZRXOO1kn/D9/6uDH97/nv4Py9cOHz4 MFVw+Cdzc+pPIyiRfJ9eAvtyyIu2iF3+wv7CWCHVVb2ueks1VY83Y1KjxxqdVTel26uj9XQu vYtO0HSWVIaCmXg688lMkplZw7cjLdbmWjORJ2hIY5xBRCkRdFX5+FJpZf0Or/eL0HGawNzE wjjAwN5lrmWuG3PMYkwph09xCrVh6VM7//o83rfz6aUE41eUfPMSpily/ef5TdG2wJZOp7Nj c0CM+vjvjg5AhWgny9cMacqqK9Lx07/NKu5odKfTRdX1uXjr+JMjS6tGn7t78lvRssrbn1Zt cBrOVyvYgIdvYINi6y6SIMTv7ffGvFSXsE7YIlD1GlyThzWclZvi9nI0ao86sMOx3K3NllBW PItkuYK5BUwWyrBWBbUp1X3QqedGPThfaI4Z0MlVLECi0QnNlKq3VqfVeZuxtzqTSqlsTZmA bv3BG5MvVBFCUfi7it6vYGh01fNTb/3lawW+gdbWzZ0lJZ2jLb6o6CCF8+/Nv79mKHdFpYNO dzd2FNNX5yP5dbbcnNGB+Q/mfz7+Z5uWVmx6/t67Hh8oVrQnaGr+VsoPui9B+XBrlExl7c0i aqK12/XW3JX5+UhCVmy1FnD63D4W5QTtZkiqLFJCzwf6WVTlqheyqaqjZjGD1qQy6GIcUv72 O0+sKV3d3WK3NXb0lNQOdpTOj5KuCxfyth0fKNMZzekHNUa9Lq9poI36KzVEMdoDvqmFc+5E 3xJXx2w4xuCdBfsLSCwX+639VtJlWWchU2l704ihXa/Pa/exPewR9gn2JKv5EXuZTbJUlMUs W5zVrmSNcRYjlmGj7DgbZ+dYLavWuGxBB8vagw6bKajhDLsNRwyUQQQiXB2Mkgfdah5U3jsW Y3n9jhsTIaTBrFTagxsCf+G/5YtZcc+aQ68MDP3pmJQxx8TvXDMFWbl9KrT1sOV8uv+Ox2P7 37xrOSl4+u/iNdW33uk3rRtdMfpYLPbE9vrN24xt926oW3P8bZD+fPJj6r80/YhFYXH5Zvsu e8JO2UvSTR1abWZmviZdyp1WgoPkipnOjlzRYOpAuTjXGMyxpaEgpigNlN8+r3IVViuuW+92 e9UrUQlQr+I89/qsGm8W1BhWhyXbpmZ1qyI/HM7zL9TfjeX5YGiwJNQTsNukW29f/tRT1EuH ce78+4evT/Z06/RGzX4tY9LvP0qeUM9VHHy3D3xXjVrQs6IvUYR3FSQKyGjTzqb9TZRzec1y ksWnGzu0ObYckp9ekd6UTmkqrBUEUSBtlcQae2oHakltrbXN1V48m/yNWDFXjIuLfe1KSNb1 sqy33OziXMTjOuJKuiiXyxEsZ7zBTNSr0xkzbaqyVxd8t36HZfEiA6RWDdf1kJCqPesXvOhW sxJ4zKpkJghfYUFz8KsPLyYiXbF6JVjBOk6wThPWmShrto1eZS4wFba5vJ2Vdkqb5w/fsfLx J3viT/d/yK7or63urXdqz+lXxI5vufD9suv/0Lert+T8irFIbWSMpsbT0tgVvcuX9TfwLx3b sv8WDtMNbRvqWXNxm9cibrnF/frMfGWwV+uLTtZEaGyuWte9Oga2Vc5FJ9jWjAQUEZtihVgq XFNIYnlYyluTR7bYcac9YidbMnFnZiSToPaTDEYMw0QZimGcue0IrnlrMIPhgkp5pB7lVJa+ sR5arIZqmMz/LTd1tt1/5o5tM/f5r//yVx+94V61WWzZ3lPh6RmtaxkLVpCCwz89GPAf/OkR nIOXzP/7/Pv3PzNUXLrxmXvuf3aopHjo22runb+VbqWDqAQ1omHRH2vAUsOaBrLFjTvdETfR umyuO10PuehlDtyQhndS+ynQJVqKS0ubvQUWCWXG4QKqDBYUMXazha0N6jV/OPveUOEJBdQN t71Vve0LiO73EnDJbce2r4itacvRKKdLLXZPQnxS9BJfMNa8/dhtJa/ZGwY7G0ZWVcAt5O8c alhCCu9591gou1yqJlxlff58REOVrGwoS6ecyxpzl3UvzQk+8s59sRNbap2DLz088a3Bsrrt Ty38UnEa6oAlar5rEl3jhfFCQjuyHZOOBx20U0KoeIlRQhnxDJKhVO9MljkDWW+o3hVlF3R1 WBb1+H0VrRYq5mgIVjVsWlX+yhe1u70ltLm1L35rBXk1uKnJrlTu1w9RfV+u3KeHr3sWflcp Rw9hO34Kf0b0RCIXKIk6RufRk5pCzUNakzaGFiqMhV9jshGlKpgLj/Yr/nPzx2saZEzT65Qd tenQmTNMiCaGL/8u9P/ZaHSL2tOKfT6eSiahH1B6wGmkaICQEaUhPXxHpFJrtCg9BZmhSjSp 6wkyqBbGKBNgos6Cke7RoeE7BidHx7avGts+pszA0yrP/1tLuxn9GH2cvImQsiR87/Sjs+g7 aC/6JPk7qGETEL9TaA86j+LQn1ai+XPpv6qp0ls+mJFPvjZgbvwUcQubv5O49Pk7+c71b9KX tc+rkpGFZf8DYpwVnA0KZW5kc3RyZWFtDQplbmRvYmoNCjMxIDAgb2JqDQo8PC9SNyA3IDAg Uj4+DQplbmRvYmoNCjI5IDAgb2JqDQo8PC9MZW5ndGggNDkyMC9GaWx0ZXIgL0ZsYXRlRGVj b2RlPj5zdHJlYW0NCnicvVxbb+y2EX73ryD6Em1hb3S/9C1p0uKcpk2bOEiBnD54V7bXsC1u dHadbH99eRE531DU2ictigSIIksUybl9881wfxbpOhOp/mf67/b54vPvGnH/8cLcFeP9xc8X mb2e/rN9Fl9eq6fU/2aFuL67sG9moqrXeSWaWo1Viuvni5+Sb1fqum7TNkv2t+q6LZuySoZ3 X5n7TZ3lifijuu66vMrrRA7D9FSXdcl2Vazbqinz5KBvFllX1Yl4pusb/8BwQ6/d35rbZZ18 NF9Jq7pLBAwhxc2qXLd1mrfJi3ygP/QLg5+EvMMBdnaSbVu1idjDAAf9TlG2XXJ3Q4880QNw aSZXdXWRiP7BvFekGdzd0gDHj+rvaiF1C3+HOfR2QWVRNMlGvuDsNidhF1LUTdL3dq6FmmMy 3As7WNNUeWL2rGjrMsHXR7uKKktzNXW3NrH61/X7i6xcV+L6m4vr3/+UPJJsT8KKrUqbRMJ2 7uVgvlGm6mvDIdiHmJDMZuYl7beRrgCV+sJqUaZkdETxiA3sPu2dHaXu2uQP/mG9ks+/a50i d7Smd3ZeWfIVfVCsslbrapNcr7pSXak1PppNzLPMfcBMc6C7tED7MW82+ivXZiZdV7R+lWoT xXm7sXOxdpNVbTOzG60MZZExu3nH19Gs01Rp0fWq7rSxFGohtD+DeEABqQ2sslzt/Y1/wupO nVVpmxjtzbOmTO4HGqMX783Ol2WZfE+78e3qKldPaJn9jcRnNjZN1aM/rlqtJVkN4tqIVZ6p P1eVnm+rJqZ9BZvvh+S9t4wf/f1pd0sl/A+rSbvStFF7bYyiVNs37ZExiWnV5glYn7i3Kyzq nFnHMKmovi8FjDNJ0pjN3Fi2Xp7WG+SlWo35gtoVt2wjbjt8lRZu5/Xd/X56re0qeG1L8r9x /g/ED/KUw+QuOqXcT3h/8gjWGNEv3prn64yb6I4EIEa6vj8aV5F1rXai7u446bQR96Lhgt1a N9I5R6jHsI69qkpwgygndB+Pt95fDWulP+k6VcEGFII58ck4VAwqJ+PIyiZiHJPct96lygHk Dt7SCiZXbhYnSFqH9gPaQgqlQ45RnUWVMUJUQaNCUYHHtY6vLnLUno2cNtyoj1Vgoz/Mx3oN OnJxx/w3fJwCNoRj9ui0KUoFMZDpt7Kmi0uVae6leCCxkmKAFh972vp7cFiDfTNXPqQHxxGb 3R18EoOhuJPj6qpUjqhTKihmW2PCpzjGJTsqF7WyASAvNZJSAUAponIL6rJXUEm/lnZNXanl H+F6Q9dB/Mha9+6H1eV5/3NVZrn61JX1Q/oVbt4Ut0gj4In5jmhdMhsScQhWh85+wGAdBpz8 5UnsR/nC33YKMopfzOZ2amE7yYMUUx1zdcRgdPA+Cd1W4DGMQU3xJBRW3lUkrAcQ0Mf49Vlh gZ8b+sgWWtE9+Dn36H7ISQCcu4PYxZTWQ1cb+NDrbb3WPtFAbBwPgTFKWo0qssJo1KRPxjZy BUjSXPmVXwhr7JiDcLqzY4sO8G8EDU7uvGmUbGBw8DOAp8kPjaB55AtIBVFD5iLPmtoJ7WbB Ovs3CVwFoCrTe9Ng6HNwPLQAkKocrJfv6nwhjTitah2tsuRyKTS7ZMvjLDWPchH4bX2M/bTQ BmozKF14jr4KA1pv3BQ6hE4alXUleqhY0NJxbyloUb7gVmQdzmd6lk2loQToyMuNDyRP4dZP yeAHVC9lpjYNa9T0kyMpExPLtDMnCG87OYJgFAyNf+6OhBAPrs/eWEG2NxFEBD7yFmbpths+ D+ExCvJV4gsTiIrVOJKDWzfTXAGCNxKcHjofqTTcIcmj3He3HvB8Gv5wasExMABmCVEPNOdX epVnphtUu62PGnJ4oQ0/EVjtw7w2wA1mxmIbyKpiuI5BlmkjL0HLjkAX7IAOALXYSVIMEeB+ EOb9lHnrL7BoMbEQeYiK7KgGOrO0m3yDF+x+JPQwefpslvAUWVbAzR70OaRaVEpS+azBimM/ xtGwNfeqVTHhhC8c514ToqwJvqGGGQiM0SQKcJ9ReO6tWC6zA4OLpt0w0lpAKo22CeK3X2t1 1hhH78LF6rZT3nrJUztr9fhhbrBTZDEKZRN4yygEGfqUNFESHdWNx0FCYB80c7UELbde9nFf euvTW3QUlyIebu3EyjJvGfqwrjVtVfh5wqEBOzphiz3kuSFDR88axcbIPI+1gbrg3XMc5BzG GuMfBCKMEd4gPSQ1Bww4kYYm2qjAJzevIQGmIoxF8TnoxIM4FiQaWKa81pn+In9hFcUgmhn7 que8k2jWAlEgQqcH7xOUC/QBy+Igss9fDzHxjwNCALeH0bR2fJlB4MlQuX6YEaToJYwi1+JP ZPHHMY7xMC5LlPMl4rJFpkujGnXp7pongBsGcz0a5aqUt1d+GcnkOc1FYnQ410g3ml/KgYfI EHkN8uBFxSAJB1MO4oC4j8psFOZCydL11unvb6aY3GYMl+I8IpRxlVV6N/PRdZEyaEZe4lOn acTLpol2Kp1dGFtmYcAhYyZhuSen8PMR3Y/34W/HOZbLcvTmnF4IuAiM2NanFFWy7M+DIFpk SreRhEA+YypLqFjoVXrSLTQkTWoGWEJvkGY1NZ+tQOIyq+lMuOg6pvXDGZXR3l+ldpUK0iZ0 LeR2FIMC9n5CkGGdhTwTpP02/1giv8ERgDpopr80CbnGtz5WnwH1n0Q4LfBBhrSc+CAdmUeb 29VVkSPS3R83cWAAmF9MdE/d6n3WtRwNqEkife83MeARKec6n8BPns0m8FXLsnYRapOxjRN4 dB3u9wqmFZq3VsuTUYCAcZw7wgmFMnvnPJDDSAJC0hM9cePzGhD7c1xHCNohJwAK1QNBisT2 OURmXPkg/ps4cvDjMPxoq0llheWAb8zf01KFwe9tiQpyVYufMCbBMvcswdfaOgMMVNAwXmMR 18B8A7ZK6yHCnjDTsop/DOFHJP28J+3BaS94a9SfRxLiwIM/Vyz/8h08NIIfQSCyZyrHN8uM wtBMNJN8YRmk1xBiT70BQ/qgqxuhEZpNgRwAdlbeYWx4Jm+0t+vtimmF9k05nMkPdeLC0CY8 4R16LP4/0oTW4kt1u2u6sktOMJSrDgLAnZVCBHBNoFJiZrrEO5nq7h4yBLBnZB7sZujCGNx9 BNEvlkzjSYPKMH14jcMMRvVdCiqKIcETosSQ6RmA6YkVUoeoVU/Fdn9JIH4BmdDCkJiDEHw3 YssEimyGPvTWj75SeQ+YYDg+O4+xCQIKhQv8DlzKKbyZbPgQXQTVjhdEvF4tN1X8sPIZfoT/ Gb3R++YL6KO4M8EwVTYnxdcr3zMET/R0uTd6oxRRpVAIueiJwyrSjvEuFm/m4d3lIvN4E3Wi TBOdooFHCq3NqCdyEQyWHlwl5CzJn2Zq4AWS/3KqxWviZg/3kc+JdZdYb1Qa8MWimICS6hxb m5gHvpQaktDlQAxB8gFiwtiTGYZ1LtBFCqKsRWqWoMa4SHkcKT+ZFRcstxDllkM6mZtLWKUf ULhbJ09m46AcTiNYbZ/vppnZhrMeXBkDtKcldRyha4NRTVEcMfoa1hrLSB5BzUuLhoScraru WoKo8TVBPR2TMKwoYO7q+AGD2PaoMaAscSITEljipv4v9QelyqAzoGs2Z20ZG3kZlmrqTPeI oIPCzkG3eccoO0AEcQ/DmsZBJ+tLsWG6xHXXRbEoMUZ5Qx+p5NOeb45DD9iPPAUjliBxwHIk Y7WcuZ+wjHEIntC6McLAbn2hI6Ea39xjoEWFErY0RVhwMIjykTuSwCotWFmuSPyPdQ7jFThN Ce2diAeY+b3EKE8ohXKi3KlB2HrrntZQdRLMb6uwoDq9EPIElCr34EjAAnQ9XmMJNf0vfMi7 s/0LhVJ/0DQYANULNBe+h+1JMMZnRpPUUtZp02G/DyuCXLkHoAaOac4dACWojc+KExiw6kbv OTgSqmqcxO/U7TzNFVJM/rzyuEzKXvyVXpAjFqWG+0tBjZbYxUK+QwAUkSAi+FzEn+QcY8X9 iXLhs0lr0fk5W858ok10O+nAOp4vRffPla9Wfm2+kRXKcIsrn1y8d1jgXVFepWlW5F8YLKmU Pcc1rGNNuiaZiHTp8u52n9WFbIDoKTkPcBQ4KB8mgygdgna9XfQIwySOZnb4ymQIGE3+7W9b 6JDpQuysg1PvPW/gBK3eUoCe7NB0Pi7Q1DvCMUgPAOFEPNme01pedB7GHTeQXTh2N+RC9V/n RTW9M3nGaIBZv4WKNgvJ0Qg8JYugloPvXGFlHtWffF6MpfnFqgHm4tQixPKEN0iLPs/uy5Fp gpNchJLi4QWDhasQGPl7SIOixRqFCMOYhW/jKaCWKBYNlF+FtW8TBUDNIDelBlw1dIyF/PRa pO6BRHYJi41uEwDXpQUbay1UyhmBrHHm2kjKRmpdSwbbXRWdzo275VIBS/kcDTUwgiXM+dwh mSjLLHoK8ed9lSV+bvxH0UnsQUvsuYUqr5BxDk+gGIwfNuoph0m9mXJF7Xl7uL6F6wGusZdz uZ2v8K2AZ3ycm78L6GXGm25fB5DeM0EvRJyFoER8x5SMKEvHJ+eUnM1ac0kpwS8BpBvoMAno UrQVYc5DRHi6qRfkxgWVV9vW/AhPPsSxXIiCCTU9kb4Sd3obe4fOBr2Jx/nBz5CdnCLbfTdM JFVrhgGAMfR7iS2S6Ag3pyi1GXTkuzyA+Ak6aDVjMix77fPEQBAOYgxnE/nZcasYyLGCjpFF QOPrJgj0HJiqOh8j91EJCRoBa3Aba2tNFhY9/Jf7KVbrN2OHXMzzDx5zsNQUQAdPgPbhyRZz G6pf4GVtzDVA84i8QwSukEidE9H2RiDlVV+w46c6qMwQLWYcCROd42oBxZ6AN7151iqu86R2 HqCszpBTAY0ZHZn+wm7mJk3R4YQ+EbIadgFAXttsT+mNZqX8YCr/t/PU9+1wpuTOWitjwRUs giZxsJZca4pu1BXDVnt2UtL7aK/eYSS9uDkwpOCHjvDO80ON+mgsB2v5Op23vpO5WDIRHhjj uhIvY2DtUSKeIcJ6AZdiVjx1VRvVGx/CDwEvY8tTOo5g0nG3yjSKKXyua73qAkkJnLO1y1yl WYk8RRsvZydOjSUQzeU9cU9RPF7Kvh9EL4kVQF81IDk9p4+8QcORTgqvuA8n36xrk8iFqBBr 6WB9LlgM1BuzXPrybZnuBIXffkkFwLDxRGcAvhs6PBV6G3X9x71QeJm1Ii8gCSKCZseIPeai XmgUg+8ktcf5QD9dG7pRcwE6RiUJ1kftXbVckMC4qqp1mhVFhBM3Z3rjrmyOwBoVOjHW/gWk H1R/orsVnL/0zxjcoLxu+bZWJQBhcoRheuw92MWNU0iM/Dy3dBlLmFpyARhOGrEKIiauW85G R3ZcPdYxM7F4PMswWQv8fZaoWFuah+pXTTd62kkoNZn23Ij07xRm3lE0vUS/O/RLB+Bhg8BH SEiwGGYJzhWYY08yCpmevKGfsFJ83Edp3R40/sdVqR/P2yV8gmTEHjOBCIxUcLmyMLLAA8BQ 29POip2hwwO50MiIOA7I76hGGG2K8r59WB46K8gyrZLZwUSD4qCUwf0yRakeNcC3qYwy3pOC rEMcIvZEuyF5Pw/NvBP8RL0C4Q9YhKjJnsSNBlf4lY3hbCloxIB8vo1WTwyOgIJ/YH4bHRFR Qj2nDYMwcaaBOTh/RjUZeoQSzZ0IgoUT7shzTInp1MjYgAC/aLtai3cYRsFNH5mbHvDjQWh2 ZTuybWpljFZpN37fYRzNdyE77658M/VuCW/PxhqotY1JZgekz8uskBQXH3iDHfFbcLeHaM7o i/h5oQm+nD09P1MEZra7BZ132ZDu0ShqpvJDzzuHnNZD8A3kvUFXT+uGg2j6JJLDaiwwHIfw x2a8StTaoUW7414/C8NJYLDQcTbVkO8lL4575+rAXiXGhYZzfoII3aM/fmjoRxCD7/CC9FV9 m/d6vVKBpboENvgSfD3jPfFstaWDrReCLBxaeKB1Xh6x05GmODJFjLkUPAgfB6eXkWC9WNhi wXq5JfntZDH1tFhhra4cyHit2UGC0o+neK3bAJonthvkqi1WzpualSliBDSWmMEJzXir4Fkw hvjR+lmjpF1YPFOJp6fsFNcspkENmVHJoPzQNktn+pt8dpYy7CDmVRH172IKK/Eb0ZrviGFl Yorn4W9+/ssvfScooQC+D6Hn1tPFZ+G7dVdU1n/tx0MYv3EO9OgOhE5FGF9I1tE8bKWmGUg4 8MpSnvj5jJ5iAWu4X+KXqQQBvQWDB683HIvHf9hFvy19c+Gb6uKLlHH4q2+/ocFQUw9C/15L 1zYdFrHeer6aHwCKeh8SyjjrPZpbxSqr1WTaMjwkEDTieAUQ9Htyu3hrk6DuCDB8GAKIFnQu 2yDKn3VPpnml0ueFS9a8EnFUU91rehgqXxtyPAJOccDpn1H2x3hD3JQJ28xV4C+doYOZpz2m wBmXBTaNvS0z0Q33XmNP7Fd+4CeJIsf56FBBmG9PCb5OuBHg8ZPj3C6s/c8OjFPbPBwYP0Ns DP0nZ89Gsl9fX/xD/fMf6mJPdQ0KZW5kc3RyZWFtDQplbmRvYmoNCjMwIDAgb2JqDQo0OTIw DQplbmRvYmoNCjIxIDAgb2JqDQo8PC9Db250ZW50cyAyMiAwIFIvTWVkaWFCb3hbMCAwIDU5 NS4yODAwMjkzIDg0MS44OTAwMTQ3XS9QYXJlbnQgMyAwIFIvUmVzb3VyY2VzPDwvRXh0R1N0 YXRlIDI2IDAgUi9Gb250IDI3IDAgUi9Qcm9jU2V0Wy9QREYgL1RleHRdPj4vUm90YXRlIDAv VHlwZS9QYWdlPj4NCmVuZG9iag0KMjcgMCBvYmoNCjw8L1IxMCAxMCAwIFIvUjEyIDEyIDAg Ui9SMjQgMjQgMCBSL1I4IDggMCBSPj4NCmVuZG9iag0KMTIgMCBvYmoNCjw8L0Jhc2VGb250 L05ESkdWSitMaWJlcmF0aW9uU2VyaWYtSXRhbGljL0ZpcnN0Q2hhciAzMi9Gb250RGVzY3Jp cHRvciAxMyAwIFIvTGFzdENoYXIgMTIyL1N1YnR5cGUvVHJ1ZVR5cGUvVG9Vbmljb2RlIDQy IDAgUi9UeXBlL0ZvbnQvV2lkdGhzWzI1MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDUwMCA1MDAg NDQ0IDUwMCA0NDQgMjc4IDUwMCA1MDAgMjc4IDAgMCAyNzggNzIyIDUwMCA1MDAgNTAwIDAg Mzg5IDM4OSAyNzggNTAwIDAgNjY3IDAgNDQ0IDM4OV0+Pg0KZW5kb2JqDQo0MiAwIG9iag0K PDwvTGVuZ3RoIDE5OS9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCnicXZA9DsMgDIV3 TsEN8qM2KBJiSZcMraq2FyBgIoYCImTo7WtI0qGDLX/YT/ajGsbL6Gyi1T169YREjXU6wuLX qIBOMFtHmpZqq9JOJau3DKQarjK8PgEoDoDZ+CbfUD1O20uzaZTXsASpIEo3A+F1LbgxgoDT f61uE0xmn2xxMkddYya8awTv+oxYISrBWeliRThrEc8ZsUJkogQiy4g6Jgv2ZfWxJF+R7RzX U7XGCC4Vz8VT9mId/L4l+JBVFIN8AX7cYv0NCmVuZHN0cmVhbQ0KZW5kb2JqDQoxMyAwIG9i ag0KPDwvQXNjZW50IDcwNC9DYXBIZWlnaHQgNzA0L0Rlc2NlbnQgLTIxNS9GbGFncyA0L0Zv bnRCQm94Wy04MyAtMjE1IDY4MCA3MDRdL0ZvbnRGaWxlMiAzOCAwIFIvRm9udE5hbWUvTkRK R1ZKK0xpYmVyYXRpb25TZXJpZi1JdGFsaWMvSXRhbGljQW5nbGUgMC9NaXNzaW5nV2lkdGgg MzY1L1N0ZW1WIDEwMi9UeXBlL0ZvbnREZXNjcmlwdG9yL1hIZWlnaHQgNDcxPj4NCmVuZG9i ag0KMzggMCBvYmoNCjw8L0xlbmd0aCA2OTA1L0ZpbHRlciAvRmxhdGVEZWNvZGUvTGVuZ3Ro MSA5OTY4Pj5zdHJlYW0NCnicrXoLeFvVle5e++gtWQ9bT8vykXws2bIsy5b8jm0pfkiKHZAs 20E2GNuJ7dghwU7sAAFKUkgbMA2Q8rjhNQkw7XQKJHLIpU7plECh0965HeDra+a2GZgpM9MU 3GbuHXrnUmLN2kdyHtDO3O+bbvucs9faz/Wvx17bCQFCSAE5QDiSTAwEgkQs7vfxtWXbron5 HC38T0LgwrZbFp3922IvI+PnhNDI9Pz2XQs/FDKEcCWEyKXbd+6bzvXXbibElJyZmpjkHjVv IcSzgszGGWRo/0H6HUJU5UiXz+xavC3X39OGrxt2zm2byK/3FL5qd03cNi85KXsa+8eRdt48 sWsqv79v4atyfm5hMT/+KGuf3zM1/73z8p3Yfwb39L70MDERIm0nOjInbZduJlcV7gViY9/s h1e+136xtjn7MfkjFsV65avkJHmY/C35bp6OkiSZJZ9DzpXlNfI97HcrtiXJCPn6H5z2BbKC 7awkyTi5mzz+B/r9FWkiP8U+T5LTl3jfJ3eQXeQwrpzEXaQhCFHyv8kpsoP8L/Im1q7Jdcv+ gjxFfkS1ZC1HI5KE5DQ8Tc7Sn12a7yg9Tnops5nHsSUp8jpJJ3yNPAXHcIUHLknc9pn9fY7c h+8UmSG3kEP5dTqpRZqiKnIXjkRtklayhXST7WSe03LMXv8c9sP9+M2Qr+Rn2UJq1jav/Rqt MM7toC9TevFh5B7BMUfIBCDC9DC3kXWkgawepXqD1GbJ2va1NHwffoLoRckvYQ8idDM5vPYU 2QFflxrgdKRnOD00OJDqTyauvWZzX++meCza093VuTES7mhv29Da0tzU2FBXG6jxV1dWeNzl QpmLtxoNep22QK1SKuQyqYSjQKp7hOi4M+MZz0g8QjzuZ7QwgYyJKxjjGSeyolf3yTjHxW7O q3tGsOf0p3pGcj0jl3qC3tlG2vzVzh7BmflBt+BcgZH+NNYPdwvDzsyqWL9GrEs8IlGAhMuF I5w91pluZwbGnT2Z6C0zSz3j3TjfslrVJXRNqfzVZFmlxqoaa5lKYX4ZKjtArNDKntZlShQF bNkM5+6ZmMwk+9M93XaXa9hfvSmjFbrFJtIlTpmRdWXk4pTOWbZ1cr9zufrs0pdW9GTruE8z KUxO3JDOcBM4donrWVo6lDH4Ml6hO+O9/X0rSj6VqRa6ezI+Nmtf6tI6fZeXhIzUrRecSx8R FEdY/fBqzkSeI3PrPyKsGkV4l5aigjO6NL40sZI9sFVw6oWlZY1mab4HESbJNI5ayX7zfnsm +qXhjH58BlrzwkZTfZmi/uvTGeqOOmcmkIO/YcHVbHcZhtf7JP9QM0EgEA7E1OVigt+/EiFb kcgc6E/naCfZaj9FIgHfcIaOs5az6y2mIdZyYL3l0vBxAbXZN5BeykjcmyaFHsT4/onMga1o TzuYKgR9Rvtbu0tYKjQ4WwLDYl8n7mrT5KwzI/UgLDjqygFoKWzIkl4ktL/NfVbtuIDHUOhs EXAaNk+P0DOe/71lxooTOP3Vmbgvp/rBdCbSjZXIRF5HPcu1ARwxMY4qmu0W1ZcJCPMZo9B5 SZ9sWz2zA2lxSH5YxtiVIePb8qMygZ5utrKzZ2m8O7cFNpfQnz5DQtn3luud9pdCpJ4Md7PO 5i60K0/PUnpyOsOP2yfR06adabsrExlGBQ8L6alhZmiIkPc9XM4lrpihXYPpvgGhr38k3Zzf SK6BTSdx93xqGiFtz02DJpdRuBXONLVzw9hRjwxnFCtCZxu+M3K3Ah89Ai5ymal2tjnTYCfr vXEbGa+zZ6o734/RV00qZebUFV+fTcZInKcrbncNu3LFX02x2ZlfGEcoGKjx9SbOjZEAeRSn EVkMSyuzeWdamBKGhRlnJpJMM9kYPCLKeTBEzPO6GryKugIshIm4sHmdYGBmoj77leBmYiJ9 iYx/qnnTerNzSSH0DSyxyYX8hAR3vilDmAlHmg120fuZPwvRCXRi9GjRn5eWIxHmyzPMbZeE TZNLwkC6TeyNEeRz9tvZWoWkD/oGO/3VGMw6lwW4t385AvcOjKTP6DHNuHcwfYoC7RrvHF4u x7b0GSchEZFLGZcxGeFkBJsphYRC7G8/EyHkgNgqERkivW0FiMhTrPOAbFuhOZ5+nUeRJ8nx IiKPFdSSdQYxxvjd45xk+rlzeGZpfJjZODEjIvgLGRA6EB2hYxmoTJNRCVOdGbXQyfhhxg/n +DLGl6NlgBn81bcv6XuEj6x+dmjimSt3rfWQ6xQ3rT22dlRxmkwSx1WnuIX1IRZIkUGyj0hx s3oSYPkJ947kGOaW9FWSBDl2CojvkyCJGODti/DqRdBfhLnfQeR38G8roIsUevn/a8/yv01W 8h8l2/h/udDGn4EiKIwcbON/vdrGfxjL8r9Mevl/xuef3m/j/zHZwL+Pz9+fDvHvnS7mf3U+ xL97LsT/HRfiA+fHzu8/f/K8RIeVk+ez5yVKcg7aAufC5/afe/WchFUS505i9a1z2XNy3Tn4 OY76m2QJ/1N8foLPj5NZ/vvfa+e/l2jjv5Pw4lbUuT0GXofw6w++Tl97Jsu/iltZgYJTsUL8 aL6BnG/f6OV1K6CKKOGVF+v5b76Y5VeyZyOhM+WV0TPJcj78DXgZB716GnQnx07OnTx2UjJ/ 4sCJh05wzhO1JyIn3j7x3okLJ2QvYp9vgYG0g54Mgf6UvQ0X0EZqvNyQ7jkIPAsPPgvZZ2H8 2flnDzzL/Xlhlv8al+WPhwqHnsKRTw608X/a2yaubHrGVR499szJZ+gTuMvHe7P8Y9jyLXCA hXgJD9aXBrx8+JtIJcAS6aWPPtLG6x7Z/whVPpxs57+MzxFE4qEvtfMPHvbyDxxu58lh2KA7 DF/CRQ7d7eUP3t3Gz9994G56y942/sJeWFyo4hdEXEwR+7yXn7vZx98cq+KL1fYhW8g6JA9x QzLc7LegGIziFmwvjYX4yAoYT5VXRHHPL034atk3opng0YvHIvwYmw8ZT4wWl0ZviDn560dq +ZGYlzdC4VARSi0FbkiCE+u4ABfmxrj93ElONj4wP3BggEv1B/h+nOC95IUk1SX4RCDB9cVC fC/isSnWxsdjzbwuxscCsbdi78Z+E5MdiyE69qGSuH3IHDINGUA3pA/phjCfG4IQGQrosjqq 043p9us4HQkTesAMUliBh5YHB3y+vhV5FtMBZfL6DNybcQ+wd6R/JCO7N0OGRq5PLwM8MPyF w4dJp6MvExxIZ8Ydw32ZSaxEWOUAVvSOZTPpHF5YWPTlCizsZR+yFxkLCyJHpH2XC+ToRezL KntvXMjx8buQa11YH4Dz7hVb8QMLxCfWF/IT4JpwaWLseePCjeI2YH202JrvssAK4GNFr+/G DHtSOoQeLyc1y+jubafkkn9aDS7LpD9vO8VRrJJljrGljH1KLiv9pO0UMH7I4DK4XQZXN3Wu lcPRtRnp0MfPd0t+wJJ20pH9QCLF+xxPguTLkZbuusG6yTpuS8V0BXV74BY3GJ1KTVythrQS YkpQquKN8qicymVpGciCTi1pL4CnC6CA2U8l9iwoqA/Xn6x/tf6teklVfM6830zNQtKh1wZS BrMqUWCSJfDeFl5lP8HwKgRGV3cbQgHf6O4QK6OG0OhqcHS0rnbUN4oFOrgwVDS5OIvc1aQF oayGNtR3SEJBs6UGKa3EZCyloWBjE6cDmULO+Z5QQPeF3Yq1XzgGn4i1bY1WeKLb7jySDPar hd6GxhuT4WpLiX8D33xPO/eixl9Xo/tXq//jMzb/U+nhmuvuSmx57qFbr6vVLFiKaxI7br87 Eh5uKd7UiTiFsx+i4b9JPCRE9kW8i8GDQbpYd7COtjhBbbPbfDZuC52mtIfCmGHOQA0GEt9f DdUMF4+yIF5d3fB2A1Qo4nN2sEsTFRXmQLJMn9CP6ef0nF5f0G82IyqhwGh4tbAlIOISzAGz GgwwOMQCRi2Va2FdaIuWu4xIKUWwGuo9iArlxlJP//OjwBXVpsIjRzsdzi1T861Ddw1WVcYn 997THZmKui8+vetPdzW2t26YGWil/7ZxcTSsUnqK626I+9orquytgdK6kbv7h587vJDy8019 ayuKhmvGQs3xvlseFs+tXWg8GrQbOUlEVLwSiBJ+owTpSvY9NIOCuFQyLAGJnMR5MWRwv+Gy HNVzTq6W4zhJQkZIgppEM0BJR3ejkaLm0Qh219W6UdVFqHLgn1asnVn9vAJ8UZtfGmcnJiWw tpl7g3uDGMlGcjQyvakDWpphKrA3QAcDQGr0NdQRQTPcroUtWnAXwF4NVPviG03Sn8ngtAye k8E+2X0yOiMDrl4GggwokellVCbrGm+ExkZ9nG/rr3M1QVNTnV2d9OhNJFXMNIO2Gkbt6HG/ TEuomdGxUfaLBe12NZhTkWi0o+5gB20qquGYKpiu3FfrycLl6IqmkKUUQqwzPFsW62633mz1 uKvsyXu3NZmqIsAbe7ZM1HZO95RX9m6/60iibMvIkOtrRZvmn5punL6ux1ToLy9fSPVu73Ir Z2yVQSvdIVPJuBuOfnc2uCVc3mzuaKmsS9/RO/yVI7duCcjVOsUnnTsfH6/Wmmzq9+8Sqn2b JhrFGNCe/YB7CTEtRdveFanMx4DtFbClAjAILLpBxYKAAqCUxEO8pJ2DpzngmGk7kM9xDd74 nGa/hmoc+vJkkV5Sk5KbSYLLKZghx8z5kpeLWOWB+qxbNzZ1QFNjU0h+GT4RIc607tUtW+Ne T2zyzi8nO+dCnIRTSFWaxleKytze4sFDNwbRvZ2uzvCG4qjo1b7Bz6W2PHdk33V1ZiPlqEwi V91aUKiRbnv69XHm3ZaKoB3teST7Id0q+TzGwZsi3ZOWRctBC1cQURriOhfvovtdv3FRebIY dMVQXFxiIzGdWWc0FtXqwKUDhc6KR1ZRSdJmtZptOpmM61flvDkcCgX0q0Fm42glAUMIiSCa zmhoFC3dN+o2mnN+nIegsalICNOQPCQXOC2Awi/44m5TaN81VRGfSSXbdofiC/dF3D/V/3RC oTrh92NULQ/Za7sqHb1l1O+v+PGPBy/+zBtlOt2DTvo76Wb0TzvpjTh0Dt4RcHDHHKDoLSxE v5ToOJ6jx5hbiorUM0UWDFgk6Jy6S7pj7smUhv4ZWB29wjmLMBDltUbF0FPOnPVx5qwdhtJK s7mi1GAorTCbK0sNqAdu2uaH0JVM7JS3vQ+572Bc1RGB7IzUHCyDxjL4ogtkDrOD3m+FFivc ZwFlka2I3qKF8gJ0X/BJ4YsU+LiCbdyG0UahcB93A4nPmfabqEmdLNZzSb15PbysMm/1ra7H 0HwpYtB30HzALLpCFhPKtjp7Y8/+iQ2zW7vvGm/9dv+hiYa++797Z/4Lg4ceHDjyl3uXHkwd +f6aq3H6yzfs/clzE+tfMT5uwgz9eZSrgmw/Qyy4TyPaEm+LlR0ncB0BronEUPqV7ErErd7E kSJCKSFenVahjKmTKlDxiTKTTsGljHp1QqtTojpEX8odmaiPYBCFGkM3whAkepQPcpLIOYEp SN7BrcsiZ4dnUQdH/09tfVU6FbXe/NXHb1GA2e4ZGB6trelrcEgVCkn6HsXaD6clCrmEfuhv ruhIVFxc4rbb/Gfrks28tT7ZpPHWhsxrYPXTqLm2xoMyTmd/yb3MvYAy7ooUWpxKfVytiqEI 9ynhNkwVmHasaFZKpbeMxPikDWZst9nutXH9NrCtZN+OmFUFcSXW+YRLp0NRzSiqSanLiypK imGCWZ8YO9bjrM+dU11TUSiXFqwHV+SwVEHLgYZJ2h+1zjFJ1351haRypSQ9pwCbKOlr/mZP +7UV9LZPnrD5X6tLtqCgiWZNZW3IAmtW/8VXREFFffYyfeJ5V032nyEGlKwY9RnjIE3AVhQr OV4G15WhVstiZbSMadWAWi0rKqO0rKymSsn5YsCOxhI0VsCsHEgSc4Nqky1RYlK6U1o9ehy5 MlqKx+Hv0TKeMJCT8fcouOGSBUATKtiZlqiUSlqWHBkPfVbL6wh9hZ2sa0Wm5nqf3J9oLfs9 qtbkYLp4CPc9gDgIaNdm0hVxcJw1a4VCg1oT00YKkgW0QJvQ6wpMhbIUwVTg7MuofakUb6zh YMCHoS982XqZT9bVAgZ8uVBxldnSHxlr1dU+T3U6tdl5k2iqJr5yeOR67k0p99v95e1J/8Wj LKD8qG2kFS/LkD2Pe6JohyZyb0SvhRQFGivQGgsKtAUaI7PCdjRNlVFlJBqNBchgwSLulCbV TlWt6iHVcVVGJX1L9a6K1qLfqdQ6NdjBB9fDHXjv0CZJEROkyBwvKsIFcoK0jLJcYHQ3q0Eg hKIUtrQEAj5D6JDed8j3Rl2t0MSyU6oDAWXCI74xDGisSlr/qL0lWKlpCvjppOLiX7/ZvEPY HIj7uYBUWaA49HHdJz+2mR9mf25nNsdyzlsRay/ZHonJSs2lnlJOrbArfApO/NOB0wxms++4 Dw743vZRV3wO91+SNDxg/RPrr61rVgmxgtVq0Ce8Y945L+f1evql60km274+FxxZljkayuWY n0lUhAoxzaaX0myZ7ZqJPe2D+wer/NfO3vb5iCe1eaPZ36R3pFpi90y2Oxo3B4Ye2fiApbmu LDR64NqpFw/v7PUodUXKtY9POMqSR/7Hvu6JDkdrFRPAhmfuuyhfgKxEwos1B2voov+gn077 QF1sL/YVc3eY7zfTzWbYYAa1yW7ymbhNRthgBAkYoRw4EjN4Y9aHDMcx3WZqjii1cWvEZI0b rAarzBkpLI47nXWv4kXF4OU8ScfPXVDvApfLodckOZAb5Lvln5dLXPIj8mfknFzOITiIA2o1 Dw8qFcRUz5dTrw95+qvPETDKhDLP5USuob5GkjtHRMNm4MkQOwk9ffY7Iw/Uev2G4rE2f7Kt bEN6e3pD0+i+rvgXO9wBbcl1odTWDSPbRzaA8b8d8Zr+4b6S6kJvT6g+2hTcONLdt6Oz1KR9 Z6eN70vUdTY1dI8x/OqyH0pjaPd2iEWOGFFMTGqVPjQCKoGUQqmISSVGqVTiUYNcDWoNpICq KcQ0aqNGo67CCTT/qoRXlLCoPKik40oYUEK3EtxKMCtBooQLFH5E36d4q4HrKHholFIrBTmF +zWvaOigZlFDOzXg1YBKg+tSjYYqOan1Sf3zeqrXOxwr2QMRY21rfNIBSQeUO+od3Q5O7wAH U5Xa6Y2PO4Am87TbUhJ/RQrHpCellEhBalcBoaBRUpWEGKUJhU7CAcaccJCdgKFCSwtCz5Iq 3+6x3b49WHzMin9gsLTYAoHA2OjvK3i1PGTV+/TktUNSn/4NGBVJdFcDsHDL9CoVOBA4VGcR hOzQARhRkSjFC5dMzh3svHPt9ejz04qP7oGGvtvfLLVXWRXfVhrcNUZ608VHudtt/ovtdPji c/CFtus97mq5X1Fmcs4MinnOZvTl18V7di05GDEmApD2zHiozw1Kt81NvWYwsANCiRGzKD5W CZUMlSakKiuDJKgP1gYjwWRQWqtMY+btjFdAE8QAMRlmZwkPvJAsNit9nzpJ8gcJu1EHc7fJ 3ass7RQt99PHiCR3JVm349xRAnVfUEB1L6dUq6Xu/lTK0zrVW+WJTt31yIC7fyDlfsGRCg7c t61p9Fq+s3NjqXiWxIyhhlChZ2Ot/XLurTQ6LT6r9cbH35yev8PkCZYiJtl78S73Ovq/QFrx Tq2a9YOvGu7wgRll/+8oujVey1BowWptbdu+Vmgt1xNZbJ8GNLNqGFRDg7pHTUXztqip2pvk zfqGVJFek9DpZOqE0p6/t+WhEK9qo+zwCa5nhAwKzB90gAdoGHIHEFyJR1MpwtOBLl1DRTzO g0QiherjirVOxb6fbVdgZjp0TLyRuKN4I0kZA4EqVaHPX13YsjXZ7jXZazY4i8NdXaVUw7tK lGvWQMAq+aHNf3TL9ZfB4WSKm7VFakkgtXPfgTZ2KTGWh5ziGZAdWotyD6CPe8npyO0yL8QK oXA7QAVzZohVVhgrKyvs1Ec3UHRB+H8UnqTP0w/wokMrtSdlb7Gbra+0pOR05fuV9GQlPFkJ pFJfSSsLIzRJqZGW03rKHaCwiIdmRUWVq9/S4bjWcaPj7xy/dkgdDktJZQJdUcc8L38BRuhC ePbtDuUgDYnnH7oeeh5j530KRoPsRClyfdqN4PLdV8ziwsBV1AM58oGLz7lTWd3a4obZ2YWe 4gqXs8jt19tafP2bwjb/N+a5Fy6Ww2OtE5eca3bg4tTk8fk2KpVJ/2rcEkyM+1PciC2Xr0l3 o21tJPedIRuz772M6ZoSLSWXhRniLlIW874swJ8J8JgAgtCg0MYtWQOIB4kXLc5g6BrvgkAX tLaE6mONDa3VqbC+MdFsaDAJJm3CYCLFKak+b2G5jBVTATG1Ea2LpTmFLeLFD5nM1HzAfM38 2YxNwpKfq4j1BN7MzbquTQ15Byckcpa8Kdd+uJ0lb1V+S3NrU41Tuu2rmMwppNUBS/OGlgCj xdS+xHXt4JA3PUF/FUhucN00pauqDZrXqA0TOlMdS+iarN7Gtojj4tnPMFhm9TobNSfmIBb0 Ubf0WVJM7o4k+hSYUJzUvKp5S8MlNeOaeQ2n0ZToSo6V0GwJjJXMlewvebckWyKNlECxhcSk 1A0N0INxihYnpRadIams1Ua0Se3b2ve0Ui2DWlnqimu1SsBrajjMYGOnr3hjZsk+Yrl7j0G8 MAeYNQnsesw8VDxdPbkUCy/Lf/HVv39W8XVN5V884+8uFuqKHE1Cndte4HhH+87aZqmmrqLz 3XfUijf2mPiNk9GnWESuJmchDgdpDc1wVm4n9zeSXslZabf0AenH0o9lO+Qq+XuKHYpPlEdV baqviREcxH+PMRJOdMxifGSf+T8Xnyna/7zLf1ykhTqgZolajjmuSakoIhq9TEUMxFjwX535 j1Mk5CfiW8LwuXB7NotvJ3sjLSF/BAD+y0VKCjF+YTqB+YOEqIlc5HKYzCuJAi/ehGjwhiIj KqwZCNMwgxZwFMUfgi1mQjbPbp3aM7E4O3fzwNSe2Wn/psWJnbPbmMzwEK7w/1sUV5MXyIXs VYycjRH6IelG8Dq4wyRMW8gurAM+7VgfwWcPq+OzCZ9pfHo5BxngHNlfse2yMUjbpFtIHbZt lpDsfdzh7BbpX5JeHGvJ2e9/UNgewPDBcubkN8d0bR8RPrfpv146B+vftccuPqw4Lf9bxEch YoTl3wFyQrfrDQplbmRzdHJlYW0NCmVuZG9iag0KMjYgMCBvYmoNCjw8L1I3IDcgMCBSPj4N CmVuZG9iag0KMjIgMCBvYmoNCjw8L0xlbmd0aCA0OTUzL0ZpbHRlciAvRmxhdGVEZWNvZGU+ PnN0cmVhbQ0KeJy1XNly48YVfddXdPklYEqisS95GydOlVypOLH15kmlSEIUNTMCODChmPn6 9ILue26jQUnjiefBFAg0gLuce+7S/CzidSJi9W/6/+7p6tufKvHw65U+KoaHq89Xifk8/W/3 JL67k2fJP5NM3O2vzJWJKMp1WoiqlGvl4u7p6pdouF/F6zqv8iI6qU9Z0hRlNA4dHW/FI33T 7fvhif7cmLOapMHLH1eZ/JjFSdR3a3HbiR6+PJiV67qoo0H8R/6RlFWSp1E/rG7SdVM3VR21 v6rjRVNm0TXeHtYR+i5pUUR0rni+VweLpGqi4SyOPX2lP5VJEdcRrLf9RJ/NpY1cBe7S4x8b fUYln/WjeYmyqSNhjhZFHolu4w6bp8vKNHqGFxY7fXJWVpG5c1Zn+fRAcSxf/N7dojvRCdfi oO+S1WUedVYh+qsTXSsfVd2zyiomZLH6190PV0m+LsTd367u/vhL9D563jj1fkK9uY/t+xUT w0cnnU7sjaKauJJKA2MQYA1drx8mT3KncX18kBJwf3zyTCZpaqUGK8LuZDV8LUiw8vUPJPJn UAQ3slxJSB1mSnFnPMMZO3eC/0R5mgcfCO81gKzpVif3Quy54Al+lWckZZmlVnB6BWOxVVXo w/IR8yKV9/tGHk7jVN4cDad/EGA73TdqRWns8p7wTJNPKJuT3qiNQRnBO+0QdVwn0R6ekOlq E9QVfLw2NpcVdcrU7NuOFnVcSONhAlBPEBelPP/Z2HdVLdmjIOfr2iVIADQBF/mkVVFx9QpU G4c+8Uxq1NfmeVrzhxkJWO6dYw4+UK5uMoln8r+IQaZaMZb6PQXfVEHmKk3WUqV5dKcfJMnI i4oklpZxHPot2AG8ypM1WwQJNKp+TzawcyjQj8OkjiQi6J+0myRZdGBQr9wgL0rf50j/o7bu Is4KblG4DMmw+4P6WBUKX8yKad3I27d9p21HonYTIQacuU9Nr9w9cOiWUmLgixdp3ypKrgbv dazBnc3jlYX01QEA54g2hBbhAYaKAtfo5M6Cjd8aMas3OCwobeeMjEGFApDUOS2+pF4YUPBM Sj8Q9k/QUMRVSAV56oBkOtnCUYfIMKLQ+gFM+b8OG8AG2hBOS2j4v+D02sS+hmKf9qisabLa A+PJ+MG1kjip8MmfXHjFIGZwSTpoJ7boAU/+I6pQGHb5BwP0jbz9DInV+7Rie5a3tHLAmAsf x+7RPSBJikJl+N7cZyZ9FHWJ7jaGI2sXXnHn/MaLhkohDOiYEzhiqY1/Q2AHPMgIUrI4dTEc 7wWcD5J6C8ea0ySfI2mH6KXApjBTJql9opLByIExIUHqb8FAuPTsGftH3wAm4OTYxaFYx6c5 dukg8xanIRwkEQLoCsC+HVH8h853eX3jIEOWwMeC6/yB2oDR0FLXsNaMkWjl9kY5TZyiyp2V a1UbG9bgP4lHQyes4snHgDaBObc9h6wtCGK/kqgTJ3kW7QlCIdtacJ6N02eYkymMsYgJZ5iX 1mQOTr537tJxi3SYNYaN5vd79sR+4jhVCVWYrhEBvg+ZxF4AuR8ovI6Qyk0UOZOQ1301wJoo oVU2hGR8sVzKmsX0ni7hOa6zDwKU4xEghbyf+NjGBeZllniLVMlgf1wzVu3x2DQt2fc9D1Kg I8vveJAKEFcvSB03Ttgvpd7aJRWI5JLbHQAt4PR7p10EJ8lgQe5zE9YrLuraRlo04TkM9V24 6qHRgZkJYAbaSUuxClniDuOafVYIU2fkbwAtSzx759AgnDfNYp0RYTsOIQ6gTWkivnEtrepH whXIF5nIFWGiGBMkxFCgcUWbjg6evMcFnmsMSyoc7zj048MBbFsg9VbqrWS+Qo/Udy0FjeEs gGVASgVxwOQGuYLNMB2HFQSR8BGXmCBWJd0crtwNO0s4LN2YyVoTjJmsw3GBXtcwgipuOOle FbnKRRvU4z9UHUdah+TCt9dybSrrwKVTjqAI7iKDJP76JbWUPRT+WD3pQDp+xiQPOcnYfewg 5ndemjV2lMIOGDnAzcBm2xn6aCxDmmjzZ2SKQajQ2E6Qv4TjgoCi++B5gkZbyDWY7q3jtwIk PaOGKqwwIonP6pEii0fk0loopDRt7JW8FlzapFjf/lTbWjMkW7erKavq9OlpktTRB+JA+GaP JLMezpbiNsZRSINmz07nPG8Wakb6FCkimbCNdLqfqBu5qJKLDDXJ0k1U3HcSedqcdG1HLtJw bboLjFBcBV5LYz85mCrokWFYOuYF+2DdGST20fnlsFRUA2PYfnJWtlSmgzyl8yFZG+IQtIkj C80DAEDfH42TN+qF+w5ivIfo5h51nCF+XGD69KYmquwHhhvzpVU9zEemS0TffX8t3BkIAlSP 6UeI3i0C/KfAhVgs5L7nLpujC1TpOijNQFXVY0dLZGGAPyhxpGaPiRQjmBAQ8Be7QEEqpW4g MW5WmPVN/NCPKN8Zf8dk7U3BZUtHAzFLoztvApEiXFWuFyzGsCh+RjUClNsqgboAzkcyEMgL IHKQN7ralPugKsSxRBKJ1ZfrWRoGIDm01spq6tSN8l2sh0v9DDLX4JO/ErKU/CfE0jTMRx73 B5jVEZp55Ox9N6PfgFNK9kgNx2A2MYjwGnhl51ggr0a6E76wzCSzJKCSjw4QgFQeAaCgcOvU D1rBlJLbt3IoVxsC3fHehXpFFfWYe18sU+l67rxMNeW6AXaB1XRVDMDM4+HAq05upY2XHPmW KULFg88jWViHOYk9KP0mqVUEzq3f5GXAb0xQYU9jrb1DQBGQE4bCBBjDrMTr5x86fX4IUs6T dxdd4Z1VtLwAwnFlhLhxCAeOCwURr+kTquEuh4XgcICt4WLFbJ4m8z4qaP98OeK7ZaZ0U/GP Nlzp9NQ2ra4aR3N/mEx8IXdGPZibU/t2XFBV50IMJJpQItiEzAGsqu9I2Tw17IE0oNs4Zg8F QoUQEC/ABd7j8REuPEwvV9o23oWCk6qY05pcrBb8lorXJifWvOGdC6c8JfY6zU7J71deKrg9 B9NnU82+LGdbq5rPVlAEfaOOA/0838+nOpTT8O/KMpcYmH0O1rMQlPSjrSPqk6Yn+qRrR4Ty QY0/dDTGwnruINJ5Pml58F8o7OFDTVlV7Xp1qtC+SlOlgAKOTblZUUtJi6MufWRpU02pn3LT /oTO0fu5xmTjKhO0VwiIlCAzJxtpciuXQvYnME86fDL15LJkqSTmtCw204WYssByqN7z9KJF rVrX9KLPl1bUdN+t7SWymN5DxQrmxS5lIFs0hgcKRCBfJATQi3UUr0yTFFninOlS72eWZbwC UG62ZNo+U0q8abjWTznIzf1bSx5XlOs4kc7/jp5hqsCVUmy3rErqvZ5JGObzC2ouAgUGuAON 8w4Ew6CJ0WOAJ50e2bx5jxnunJlipuoYqp8JZHUiKUtLODW0oLcb9DpMAD6FOAfmIVTjelWp Gtb2W5kaA6GwGJguhKuvxazX1zRJbnt9hiks9FYvkQuwgTBgMzasnrusOD5AleU5xEkJgLes 7QDRjuYcjrMZI203bsZooWgC8yyzOUTdJ/WHTqcgZtEg/L4wL3cBYcA6dtZnMdSwkTZnPMvJ jz3lbV7tEPXW1AlzRWZC7eH6NSaDzHdVlnI9KeS1+CuEloGCiKBFfqMaGncrDqma6l97abMS dp5jVWUwI0J5WeRRGKxabhC28A7IsmcJMr04T6Xc6So/dGm9zLyUBeV5vC6SSsTirr1S4XiU 5G519+Hqxn5zYzCpveKciTGciWWkuRqalnFN8oXCLPlLpIrFcVOVxdS7sp/v4fMAn/8Nnx/h c0ufvSiap/ZeYmHig9VpKPHuXB3VvEYYTEzBbovgJ6ge5yfmTuu+TJLSiQTFgOLZwucPC6La wefTl4kE5jOYSHSnF/tB3qS5jYCD7W6ZJtMzmFgLwDasCuWtEozW4nt9WI9ePrOYiTxfdyK1 2G7SKpEWBKa3gFCzwci8iKADACMiIliIfXJuNQuEfqRkU2qBPjHLqAkJPo9Y8aK2/6xMynnP 9UISd2ZD/rwACYDH7opTliBvXIh1fW1MO5IpDMGqtONxWN7pWxqRFsdwRnYwekvSxpv+cRm1 Ng/z2pILIHGDep/eDuECYWBfxNSlw5ot40rX+NUhHCmZ8By54VEyNADkDW86MVAxbjG9JM5A Yj/joP7xCDazNKpPKgUlmKVl3MH38ovr5n6GFKdVGSDFpqVkb8V69QSiWtWMka2yRsXV1Jk3 Nkt16SI0Td3BZO0ZWn07Jw/URrgbJlPTxTHbN5fwXhzCXC7g+UVyVsCDbh/37C2o1SM+lYRY yeJeQXxUvbZRzd8qUK/VusL0iLJFn17MJnfJrM2+CFvV9YjqpfEotRofj3KqmnXe9S6qbaiu aDU9YBo7BosnbPDB1L+LLKl4ruWk2JKtD62N7Ek6Bds0rtdZ4iLuZgwzgktDVFklPXKzCAgy 3ubJOsmrJArUJbXBkL34NYY0WctsyvGB7TjDOa1hUoTw5oGPyqdMRlikpSLnptwTZ7xOh62Y adrqRrrVOk2rpVAe1LPo2CxdcFTO71Vp72RIz0LAQpuewThttAu0bEJtiSnW/y6XX+qWuI54 2Guk+fKi/eWNffqtYH04YcC6LgCAS0uB3YEoyFrYwM/CRgzEA5rxYmEJkMZBnYOOYI9OZm+F KhRUF6dm3ikWmlRV6RhgEp02UOJrVbKnanrygQbSOxTydJFSrik1ImW3gekXqDYe6ChaDzvX jt4ssMoTG3qE+wfnbcKTNQ/aUafjUJTTLptnMmc4mCpZLsPAn/Dko/8Cfi301t3a1I41cxR/ 1sulChfwmTtzQ3WKVxyatk8ERnqg6HSESvPtdDs1wCdvp1r1aaEnmzB5oxgtBV2ukzrNmkDt z3ZWMo25KgM8orqANJ0cU+KBwHXdW3EcsaAadGXDP8osLr2tv4I4PdBslkSksYRtjpYB6igw 59pj3ZFm0PjUpCXVFn3M2WyGzyGqFY8hFuCxC+RgXsYM+y4fWfC76GbPzGuKkOk69rapQdJu xsuReCztNVwegYbobXunPjP0lBhqiE5bt18Y6IUhh1DD/YXN2wqMF8ZjZ7V8m6wHhi7OZNZe lxwWx8J368/eQtZNLB5GEo+UN+57mJOdESuJ3HlRNJa6YMu039mkCztLG0YL3Bjtno6O7QP5 u4dBdbrOk8bdLrBLiEaCVS0fDqLctzQas5ClYWZITtpi6aUVgQ07bOJ2nsdpVgwb6MNFb0zI RDc+OTaCrH1gY1mt3VGsHnMACwIrOKEF2bHemyQr1nVVIv0j4/jtSHndAOKByazbLtzMAsx2 WK5H2wPs1rz1ZH+qr+oaMgoEv7yQLIJDAqYGgv1Gqhr0LHu2eiJXl8lzH1B7cMTCHw4oilDx ONRM86kcZlIWF6x0ZMauKuQyq+Nbbi/t7/sK23GEv7NkFp2PNG0FZ3zUBd0JGN6mH2XavQh7 NBVNcNf0pXIxcG1SdJiAQ/WDFfdQ3Hya06UPAOsWRzN5n48zuJ8ou1vksBY/64eJuVV0rPgm BVzmaow4NDQBbzBt6I7d7qQ4meZ1ijp/mWKpsRbUcuvqaUN7LUmA5peq58OWueUkVLHCpKgr wwqzadIRJ59I4eH9mFsKtEsjlKwqaGkKa4NaNtDNsAoA2nWSz7b9YMDYaE2n2GFPPUxjiGZf wXy/vM68Qc0DaH8XaF/y4ad+CE/HBFPtcOGbYi55OzQlx2DhXPkRqhZDwRk3h/em4qfbLng+ 7H6ab1H/akkF0i0/VOmkQoUe2zeA12NUncjUhQE9na2zTEBq5xXDW4oLMwrB8o0nGyZ6dED0 CgtDCILzxiUC46MDRsA2JBjT0IHaxtmfWaUAbdMOrhqA86dVp3z44WJqsTSi8l4iI9WzTCA4 un0wUsmRG22b4Ok1WQeWOfY6xwgGDiJpA+5nCwxrqQvXqGNMu0JYl+VlQcbqxu5m5Xr/x1dS VFXvTXQHui3zX8AoYzUD/QOdQpHkR2eYfzclwkaBKR3dfqDFmPnbiIZm4LDIrK+rCpBEsI3y yjh0s1FGK1CadAHdeDSV7g6gZDgfF7nH++gHJyEwhp+pogGLSusBaY1hM4RWi6SojMTY4gBB wMKI4M55xUs9CNzKw7YQQZ1hOHPpsSF68suOuSxErhZT2Y5+h8vJdT6R/XUmLzeuWj7oUQUG cfPWSF2W7icDoBA8p/Js158NMqEkHGKNyuj3JNQg2cDfWHg1iAOTxAfrz08Oo5eGhRaYn7Wd AzoulPSNj2WS6U/GXRVNsBlH3P1I2tpO813S+8L1sFkC44VwE2ey4uWCHayPRX1A8HaiWLq+ gNKj3xrx6LVXjDJlEb1BAR3Qwxu43g31+XToLAja+gUiSYwAQjftuHohJOgdVD775cAK9MVu sna+fvaDlTYS1utzRnTN/d+r+Sw1Vdr7EOXzJxr1M7Jf/KERjKVf43DCwt/V4n2ewBL9QscF gMGHAn/AGuc5goT4DBBPHhv8pRYXlNfiO9LiSCWDF4tQLT74ZDXBJqZwHR069jGEa8y0t/TT iw8WX83smSmVpE2oVGLDgoN/t3FUWZGeO8uqdRpn09zZNHP2/d3VP+W//wEt37SJDQplbmRz dHJlYW0NCmVuZG9iag0KMjMgMCBvYmoNCjQ5NTMNCmVuZG9iag0KMTYgMCBvYmoNCjw8L0Nv bnRlbnRzIDE3IDAgUi9NZWRpYUJveFswIDAgNTk1LjI4MDAyOTMgODQxLjg5MDAxNDddL1Bh cmVudCAzIDAgUi9SZXNvdXJjZXM8PC9FeHRHU3RhdGUgMTkgMCBSL0ZvbnQgMjAgMCBSL1By b2NTZXRbL1BERiAvVGV4dF0+Pi9Sb3RhdGUgMC9UeXBlL1BhZ2U+Pg0KZW5kb2JqDQoyMCAw IG9iag0KPDwvUjEwIDEwIDAgUi9SMTIgMTIgMCBSL1I4IDggMCBSPj4NCmVuZG9iag0KMTkg MCBvYmoNCjw8L1I3IDcgMCBSPj4NCmVuZG9iag0KMTcgMCBvYmoNCjw8L0xlbmd0aCA0OTU2 L0ZpbHRlciAvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KeJy1XFtz67YRfvevwFupjqzyfnlM07Q9 ncwkTT3T6fT0QTYtybFNKox5UufXFxcC+y0Ays5JOnmIDgUBIHb3228v8A8i3WUiVf8t/797 vvrDd404/niln4rpePXDVWY+L/+7exZ/vJGj5D+zQtwcrswvM1HVu7wSTS3nKsXN89W/k4dN umuLrKvqZDhO9+pfZVNWSQ9f3G8K+bFq82R4oacCPo/iWY3Jm6JJ9maOLuuSR/3LqpSDD3N/ vKdvxAmGnc9mhSLNkkGYL+quTYZePOhpqyrBhZ/p84Nb9njCIcOI/zLbaMo8+XRPs9Pkw6fx iYbDGHG3KdXG5MfTeKcft23VJsvwNG1a+b52iFmyaIsyMVNUWZonO7Gpql3XtUXyhXya1Z18 +KP6VDVNlSdCf66zKm2TGdY4bZcNFnWOU/9ODW/ypqkT+KXY/Ofmb1dZuavEzddXN7/nkr2j wx4nkDI8f9FryR94gjVrpFXdmTetOrmHVxyDotSzlJmSuN6Q1MHc6mBa7eSLST286aXiwdLq aBc9QTnsYQ0nkmVSq9hVuivl0dtJBYnuh3lPZ/lkJW3OvauLcH9FtytrN9OB1naaGy6ft7uu peW3YpyWLehlmba9OB1fDlVvAzb5aobkWVPaM62dVqmdBAea7Ur5kR1ovaiqOs+qKu2Bas1Z DlRrLe3yXSeqN2iPVKv1k7O8QAv5oXaNJ3Oj3csei7q5sEepb2UnT8zMe11m9a7OMnFt9HxN TkqpIoJqGrOPZLe5+f7qenl0nXV2rm/0i7Rpmy2W2tRZnsyo6som1b/yMq+1TOkrsLcf5atl ZVdmDKsA/shMEAZP47SRB5ZmaZfYhZb5nA0KfWxFW5cOkZTImd14gMQNSOLRB3hu0KSspaqA bez1/qRMEwE6PPlqa9RT7SfLCgScJ1zYCTHma7QyhM6mbLtVZ3PauylxxAMpDmrkYR56UNtn Nz2sP7w4oGWg4SY0llnm0p4EjDBqqcB2mEHQtyDpSYwHge932GSN9AZVcsBR8Hn1tbU3KMtc 7veIGsEcJlkVPBZGCI0UEoOk23uHE2Im4aJkxGj9pIIl2A5oy/iT82sDdx5Wymq5vVNc7pqd aA6bPN2lqfSTB9jBHQ14cbJTPrWQY8sWfOoM0HEKpKu1+YGABuaNenBQJ3cEUbRT4gfhj+Be BdjBgyNRj8iDPF4kXyzPJAIUyY3+aSddkn2ZQFPEfvW5WkvCFzvqqFGSlsCLkR8C5RIHkqUR eJNJRvVeq1YLSgkMcRV6IVSLeb7E8EtlgKCn+P3tNM6WAmr5CdCG8agVvey6DEV8unerTgJU YxArmiQm0Aq+mlOFn8iJ7J0ivEbIslbIOFmGg8N3hKnH6XGL4peWH3gvsAkDIIL8BRmjRgEn 43EASJDIhT+Hg0CscJ7iV8A7aMLH5Aw/nU4At2ftV+ucgNGK0Zky6Qn8jmj0QHL6/MDn40bc zqHnyduuWixHYUM/gkXS+w3G4VaSRjPZLk6tkAiD8QdTm9t7B1TssP3oxQY7vfDctGLA8Ax+ 9WSPTQKQoiCp/PivTdftslZSoHEWA22KNAQXEAD1d47qwjbPKCbnT1G+5IUxJgLn/QoKQD7n BCPWAIDkfuckPRrU1lTu9sExsgHwe+9eVRrYaQQD5JLB+IqM+xaFxIRqX54ePlv5bLk/5wZo xY/WBeNBBAuFk4sIRg3dUONsJQAc4UeKxiz7AFRADqOPU3KYWgY+bck89cR9LpGnKe7OHxwG nQNoMZExKcSKmjipLnyIY+6qwIyxScPm+ApSXChBWhE+gmtVIA2DKXoFHnD2fT+xBw0ECKf9 zkTvnY3dv6B96yQIqZE47HFh9xHeYysovLhAHayJrjEKqwx6kK8NP22uczUwxcjCRdnw6teP A6OH0+a6SDyk0AYWIoUhJdLgqyyX2xkZ5nK7sIjH7OIwqsUkmcqLXOExevgjc/Fxdme2XeV1 ibwRf4cwdSZOBWEuGg0jn9YLhnmb8zR+gsPoCY4g/tpyauk+PtJZiD/r0XmWtUlcZwyeNJLm 3Y7jo/hSftN1uXxhyXgH4kbEGpiS/YOmhzc7DuKD9LJZq6Yqkn9uSvXjvE3inOZk+G4q93Cz qTtlRgWyy/ivWKJNqXqbFhLRCglKnYx8PAj9xqkfKNbw4U/u8fLmWdU27s31EYIgAXQ+Jkb7 81Ji1CmQqiaxhExnBCFflgqxxF/o+3E8MpbuRAWsAUM/UogHp1HH4ZoBBox/jXJn875y5mcU r/EfaZWz4EYazrhiejT3x41kEdZDhHHMOoMMHYUS1YNDIQYMZKhmE1nTgX+7cxHvCSP2vl8Q XEXIwkbtWnq3wE80xsWNHrb47FIfsJttxCnNRDrUbtTOyiKj7xns3rnv0Z0wIQiJEYe1dAvN tKlqxeQydCffatWtJO1JPmw5iSE7+YIMkAcQEdLj8Q5Sm2jySVCsjZl+tso4wav97PQ6wmUf /ENByreSrt8tKcrWZlE7gt4vwRKfnzfXpUImxekGwjpxNq7PR6fD/ikqEAhtlEOSy8lNSQe2 n2nOF+2n0lqa6ImeYk5IPy0kuqmxubSsOmUJtzt37PsXdip6s0WjtB0WRNwgqKDvj1oZFuVH bWB7lseTqae0Zy/rqs70K2P/XeHS4coMeOpUhe6CEiRBejLAPUxKvorzSO8Doyjsu2UGYk+K a/PsIZLG8cUm9LuvBdU8RJvjZtkDnnqKv+gyxAIYbD5YGu/F7pozsXFRU9ACNKl2nf3AVPvW S3NESRTEVhMGcGTHIYO5nAwNc+Y6cl5ympAO0oSMF5eQ/1mKi2bSL78stTBgPELKWcxnrn4A 38QnBNCQ04jx5ijJJLjecQtlJ0ZY5FSZNFWU7aQSqmvpJcN2W0aoejx1d3yYv9I0kv/CJXfi CU14+gpMZZ14qrrWOESyQRrTmc3h761BX8gkCf4LVWCsq9wzAX6kWi9ewf2MA5ZQn13yEk59 UyksL7qL8A9ukhw2fTK7y13dNUUP/jI++sitTdnDXJuyx3+caYzxD0WXSyZ4kKemsb5Lmzzi L7pOnkToL2jVz3IXF5A8IPymCIYHZD/ZYmfJk9cr0XOp+V+HloyArlI+We3hNSbRB1umT1lC 1dU3NNdDMEBCSKfWKwfNyju+Syi8kpOUUbxsMrHMG1dfBeYIRyyXyBiyfPFGGimvBfLEY5hX QIAgIACeewb0oQlcRGw8hhceuy+GxzdTd4s7cOHs6IyE9IOE6r7kDkyeLHLiT1SQjMe9vdh7 4TfPzHyGakGPiHpbOGHMc2nqQvWSUbneT4hvPO1knQtKEXKoM+U70GX4pWC/SDuvZMMHJ6to lMrk58RNWcZ+twTy6RLGlVlROq8dVFoDHrAHeTvAtEeOHOHsEx6tktzhzNOAoLmaDRoXq5de 0bP6ecXtDIJMbQzq9V4bULRedu9y95ihAcYAwlzTDQpifWUk3giMBGSHEcZ07z/XmdQT0L5X AWDg1HuIwkZ/qSzmEk2x3Poyn3YR9w6d/+uhJ9r4DOKlnMDE0q+saLMYgJLzHGcmvv77vi+G 0aD+cRCPpu+hUnAplnWy2TvmtsrhjanUMlAH7fnkc5qsKJKd+CspBmRbw04k45w2RevIv8EM VkFZ3s6EXnVV8G61ASMLTyPkydVprsuITOF+UXH0SMLnKOnHTxzhWV5zeQYaFThIZ16lVuNa Yz1gwtuR3058t3F5QzLfw2QoV9cgJQO0YP4CnQ2CKZUDB9RDGGL0I61xlWlNm+D17xyNBQzh XGlm2OZUw0ZXys1rOa26f47+S5I/bRiZts9iZFpHTq2iwYznwVuAJvnxgW6ROb2nXOBhDjlc KHc8uCSfRJxziK+OHaocBYYtXhaakBZDR+ZuXNYhFutHeSbpACxGNRWah4TLNIjM+oikeKA4 C3WStczY+SRXg0ybIfNVLjnJFDX7lTKALy0rfxY9MK5tk6QTayX+xD0EA5a9i0fnQB0MsMSt 587pyxsOY8VfUKokniHcYaVmnkJXZlA70mOkVtqGul0Xaf0+hXCKFSoEZS+sDS5AES+LQYb1 ibISiBED6SDqGvthzGdY/6/CytlhBGXRb1ey308uQzRqruC+Ofi1D00hpkiG4jIxibPyYcTS nFyahYWXAERPizqo6Hen4vyOVVHi6wKpMxrZ1aiwzLm80WecEFgdWDwMAEBCfsCF3fdEvYAH 79n37mfB1kyjJbwRtSuhLsYqLdh9F4ZedZ2/h1R4+OBaAd6HD9BOXwasbqWrlxpb4mtQtzUo lwqLrfRcAw8GxV7iwE4RMLtFcfFk6Iv54Kq5B/bWTg5+n1+QwYvcKKCipUp+r/RN2I54telI 0gZaibQmsrwiloIe76HqpNsCbOlCDlM6VFbprmoz26cOjYG283wZAJ3nhEWQKF2pVxAXeonV x2LpIJ0UN5CZtlVkNiX1I8EgI68YM0VzY4ErVUxzLb/7jsKgKzj4WSzDNkve9Ys5twk58pL+ HucJ1Gvd1y09pV4OOYJB8VLuq6mQZq7GpV7xW30wqv/tg8myKke3FZjs4uEQwzeLBK8qunXw BKB0TaoQCVptA3ixXMW5ELb6FRFoYDuGlMAUvFborkmO54nfhbQ4HVW6C5yO5ulS6tb7plmD 3peug2F1wHe8RdOg6aOOHybkxqvVgwOIhZpq1ph//OLASmxAXMn1NTGgc56VPN0aI6Du5jUT C+7NpOmu7iwe7eegK9U4LeRz9hy8zH1Z78qyy919nqCEREjq23nQVC/809aUhZnqG2GGQdOi bHZZ0SGarub2d+LDwFTILguDXFnB93jIaEA0CmaKLAA8ZyfB1bVcDmsbEgdP8XB/puX8M8Ar uS1pMJsykw7CbX81kThE4XJyQz0pZ2m967KIlK3iu00EcZa2GJaH2PK+13eqbJYpTcuYztqs AIYBdEPlks52ReqmwiQkKhMd9+ABgdNpnqvy6rFAIq+LTskFNTLm0mJ3JvWM9LXzaEuxQWWW 5Qzk05YUlftoWX4W65UyEUhsK67JyW9j/VznGppI2/qsEHqFB+hGDsI5P8R9FceROtT8wBw7 rzBPgqGH7fHQko/ei+UXdog4joh3ROwg2MSLXqBqh7CicSFEVAeWFlgEDSNEJPtVlVarZB8+ 2oSWCx2piOU78oHu4onb1zVwWy11RfMUIzSubwWVp/jtYjs5aFOwAZcl4c07QzQCnXkru81Y SjTq4xUOUonj8Ot8HPZD4FlBcQNjsBeXVXpPrgo6Ry8I3BAnbnpeF7o9TQgB/XCRbsGob28d i4GTDXo6nJCwuwLuBEV7gZ3JjuwykWttgrIVCA9VjxSXQTO5CrBWsHNia5hOEHC5qfdaoUAV /OZewPHFW8f4uyO/hOdl5cG5ZAtdKyejjmZ+Q2Tmzt2GZzwDFceOSLZP93WxsiK7q2PDr36l ArIk/g07xTujxAFWqgqhy3VSN4gVMhAasE6Xe3Lr8X5g//BUCNiLgOJ4F3d/C8ViLVSRDDnJ 48mkFcpqV5TuTwooT6/u/trbne8op18vUwAvARyaze51kbV318OkKone4rbBCwnG/exYMl7P OM8Ttk+ups9PPh5DqwXPMUeJLRQq1vzPVvSEP5hpGvyqL8nxMGJa3PckQPsil4h+vY7YU2A6 AuRTyWeZGcDkTBmAKZJC4t5uHnqQ4xSPpakRZOhtLdg0MQdXD9ThRGrBcQWgThEQ/pGcAeDM 5GUidavUe7pn7TVJpy+xZOTSGKjum4VX6mw/KknOsdczww8rTqR4IE/wB6RXy1948dTGSHqc Iglo1nBCpvri0s8sQ21zkakMP1aj0f9/tRvG+LRF3aAAvDhsRZQWYZu9D+hEafhFJadS7IKO U+VLF3QIdbgPxzvrJtrsl+Jayq8EU/YCVGS5BVVI750VsJKnP6gD72ieZU0uTjXvI0Id7V+q MMb+6svOlqpYrQKCF1XnijJ0aHJ8q3vlLURXMF6W5QUNo5j8Lf8PHNNdOwU4nwdmnbzI4rUd xIMCxH6Edqpe/6adc8iDvS5IhC0HLtpvY2kgxrLkXIYRmaoj0xv3kf62kFc9AZ4XEn2VOEBi +hR5FT+6VDLy2wIv1iX1WeuKdDw1MEJ0wAuB/nbVRUWJPrBM4PuNT3v1a9+ajq7WvuHeSLC0 hUxd0eIdsngdIihVeoVRGZKeKSr5gXUiYqHq/RkHqurEG2IDBqufbsX3YF/UYYbONnpvmf3N ElZqQo08GsKjIylEspAIhCWkS435X2v4z1Ml58UIM7mnjeua0K3yhb6t5V2t6qO3tTDBTGP9 q7E6bhKTuqHaqpYWP/9iLlJOTq+oVQhNM+yvV435kf56vPQ9RuSuU0pQcvFeBMslF7qjzK2a SDu8nqT3AwCvtvoLvcUv4f/QfU+3SqC9yrvwRO2jflqbNv2+NnvPXZh8+Fp721peiTqE5wnq y5j4hllWGuymi3/Fz+uP0zZw8t2H9inLX0HRvS/xkCG0SK0snJtvJNaHV0cbGTF8wHRmPzq6 buKpOBeCv0qha1ev4d9Go5y2/ouLkI0IctOK4TyvakNYLzOJ51hDnFjpmQZJTz4RUZ5xNfWs 9HhNTbR8v7q5+rv873/ZB7StDQplbmRzdHJlYW0NCmVuZG9iag0KMTggMCBvYmoNCjQ5NTYN CmVuZG9iag0KNCAwIG9iag0KPDwvQ29udGVudHMgNSAwIFIvTWVkaWFCb3hbMCAwIDU5NS4y ODAwMjkzIDg0MS44OTAwMTQ3XS9QYXJlbnQgMyAwIFIvUmVzb3VyY2VzPDwvRXh0R1N0YXRl IDE0IDAgUi9Gb250IDE1IDAgUi9Qcm9jU2V0Wy9QREYgL1RleHRdPj4vUm90YXRlIDAvVHlw ZS9QYWdlPj4NCmVuZG9iag0KMTUgMCBvYmoNCjw8L1IxMCAxMCAwIFIvUjEyIDEyIDAgUi9S OCA4IDAgUj4+DQplbmRvYmoNCjE0IDAgb2JqDQo8PC9SNyA3IDAgUj4+DQplbmRvYmoNCjUg MCBvYmoNCjw8L0xlbmd0aCA0OTY5L0ZpbHRlciAvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KeJzN XEtvJLmRvvevIHxxypDS+X7MxRgb+2jDxngXAnyw91BStqrarcqsyVH2oObXL9/xBclUq3cb u8YcuibFYpKMiC++eLB+FEVeikL9Z/99PL/77X/24vjTO/1UrMd3P74rzWf7z+NZ/P5ejhpE OYj7p3fmi6Vou7xqRd+2edeI+/O7v2Xf38hpu35o+mxTH9uqasbs5USfP8iP8s99mc3mYTsM 2ctH9bSuyrLOHv2AAz5eYLj42bymLYYMhtjXlGOZiR/M415+Nmvqhmq0a6qrrnOD9WdR5cXN f93/UW5R7ris1R6rIm/F/Z/e3f/mb9m9nmwc6yE72fU3bSZu7uq8KMY2+0G/YSgG97K+K6ts e9FfK8e2y076FXdDPg6DXKn4SQ8r2m7MLh9u6nyQW2nd1sdytNvS332Cz49qbN0OVXagsS/q YdXIP8PIZRaTWWs3DmyOWb+wboYx08tox06uyMw3DK08XncWlT+LQr1Ayvx+kkKGeZ9p2g83 jfxYy4fHA+ycLSk85LbJm6Yp3cTisi7w1eWR1rTAmwQe7EG9tqnrPoOnAt76k9ytFH9dZWKj /X6gqZ82M3ctzyQTT8tq9n9XSb2uukHclY1SBbXARy/8Zf5s5NYWfXbF0z1Gx9f2edPXbpMH phfLSprwUcul77Nf6Bk/Svt3kq2Wv1aKtu76jG3bbZVJwCheKdUtEEVZlXk9ehlbfVAyNtO3 bZOtC81KE+FYYZSr7ZsK5WHttZRPl/WTWJ6k6XgrVk9BHA93pF4zaOXDs97+0DUZDZjku93m LxeQo9l0UfRu/WpFMJuxmbqr7Ej9JXs8bd+3VWZm1u+bJ3HT1vk4ys/GwMeiyv5yc1fJiSXK ZO/hNHKrPmU/5EPXo/q8BScsnjUVitBqrlEJfcJdJb85oZ7PZsFNodb+M70JhqDSiM9muFx0 tsKYD3hG/ulVygzE7I4a1JKgWw04eJ3ZgwIyy1u2C5pDy7upmmybuH1JlPiMu+J/PXvJwlbI RE6gBDNoiV5PW0oncSaFQHVQwLCBnGF2ixhG0MZlHDxSWPFqiZ4sSBZtNqcPJlTW1wBealo5 Sq2UQG49VNNJDxWCgNEacTp4vcHHDMEtvsCrJ3GmMzp4iJ+v6F0cFEpxw3TLhUasoMuI8MIo T12UKPllXemr9PjFKQS85Crga3IKt0AYstmVtqU0WuEnOSXRQPzg7duYaFtJo7cy1DrhTNRq DaEgAMlLoFdN3zaoMM/+fU9GdbjKzJELKdu8Lca0C9E6JeX6Fp16q2Pum3ysy27fMatDHIqa +2UCIImYTMzn5HuNzdUl8900ySdwBEzkGxkrDUEU8UIGzEJRGfAppLVspD6nXPxJ/09ZN9YY 9BZhbb9Wc/SdZI0IzvTx4L90FagyB1LAcGlaH47kxUCL5lsBirSIBy3pZpTGIh5RmfwY4mAw +fqdH2CkPFgh342FpF9FJ13UiC7KbvZ78iGWy5elMhXp9UZp7FLz6Kmit2IHeGYaJpVIc+Zy lM8P8Adx2LQ3bRQZkNRce9am7TPwWGZ4IY/uhSm39zkvXKVp8ouer5Onv95ImjPIKEIuZY9e 5qExmNMxuP5ns7HSKY4y15NyjtwinWcVQOmX+QndOOfqj/4rC9jKB28LoG5PqxbBWEtMwcEi AgWjKk+gCwim+EX5mnIcOqepHm0lB3aQqHkasZ8UawmIJ+fbyvnUhXTXEbjV1SCJtifI6M6T LBbwPJBUXeRjR6jlOYve+wbGdAIwnmn7YHyPnv0xP+Fn+OjseLFofVe3Y15VIxK+ZDyjw4dn PDAJRr2MeCUTAs8rIXQyflWi0Wewg8DFOkKxos2l+d9z8qMIpNSWPcPVSK00wLxFK8A1g55e FhuBamr9ktQcxr1RIWA4qfgaabiFWi9NeyBqieC9iQswtKbVvYUNPFlIkyKA+GP5mca/xg5n F8GoOPInBy7+w3YO9ivdeBQAc54oIVSOeLiKNNacHcm7hC6VLM2f/fENUr4NFMSJ/CpCE9KO XFBoQOpBISZTlDDIqPq6By05BXzc+d71/8TqnZsYvJdw0v0rOMaD9Xh9GWYlrISV59OJqEJ6 O+v5mnFIeD7jfiPXp0ekfJ+e8XdG98CD7bp1FeBKX4NufWcNRAHevhr1zQCtBzmLhBIP18y2 Ae6cUj9Hx6ex7uA0ekb4VCEqD/FDuuChbI8Uxyy8aPLas/Cf5fzjUEqVPC07NiAoINlWr7fr TSM/NiOiLAJbmt+upOomaqqk0yBrCDmLFHk9JLI5EnAIC08s2ndh/ImFtjLsnRcwgQAq/cir IcdV33fZCs+ddyy6vC+5c6RcqjcHejTTgnJMv7TKW8p3CJe3i/wZaMH24hOmJ1TmMKum9Qs1 2DneXd1IRUTac7KICFJckR/WJ6iVVH5t0DHWA893AT6TAJ89bhESLtx2HIbtnM912cSB+OG8 QcbjAWLlIK2RSTp182tmD41yfJUPS2ER8HH1mR44goctXLEOUMmuA31uxnyU8UCg0FpWD8tG CRJmiDsBiTGvrm4RZuQqx1x68VGyMDrYDWKEk3VdSsghVdEPxTbDG3/cWGxq/cbETN4y7J1k P5rhTT14emj8KOVcwGVS8JymfXa16qinCa0UMl3gU29hPAcOFtESzXqhMAZDVApvmeoTphiM 6KSRy90hSMS4qqV1JqYDVJeZeIK39n2ThT7if4sDlMck4Vwx1/Ar+bkqKino7N8IDZZlEn8m +11Rc+YjfEdhX5urHN/39O0tPhZHavh+dGYt8HlNX9b7+0mmZ5BQkVvFsgnog7NHneSInYVJ w0UuznobmGeeKDe2owYks1XCpwmLi6rN0LEo8TRNw7jMoxMrJsTTMRMLaF78meIqhNeSQKGA dTi0xfg6UD3NKm+5qyayPO+HQc5C1zmdvL8jtEqpAssAe8QiepRQNoIvteqvpVcmnQUu1ERM JgUyjqVzoUazZlAbCj8nNLEwS+bDt0Ru1bpVnY6n4JlnK6clcCMs9vC0023VSLepS1cgMyPA R8ygLVFZTGucKothZWKKonIeMW1rWkevQprfPOnTb2X4uVfbodnzKEL4d1iWJTCqTgV7+EwG Zj1TVNoyAUZgPQlFo6reDr2Ps1pdOSZhnEdoX1OMkgx3hoxZkM6LQkGTJoxj4xibBaipWcZY W/cQld0fKCuNBoABLNk6DLhyfg7qKuN3nN/xJF3n2APmKFexJbi5IUuqZeFWvnyVBgPKgcKL cvI6KQojwGmK0wIGkXDf7dDt1fBXXRTEunCUj9UKAOsxHkPF5tVYg0KGHkNjHSUoACLlxsMa mKlk4bbDzLBf8hWKCStKAFQmWaUGZX/2ot6TJ3I8RSU6ud92hFwOK3Fi1SAFnpC18Jg3v8n2 sawb2GA1jG1Gls0i4R0G/+hHLzOwNZ8uZZ5wuhVprLSZA94I84lyoJOq+Zpcx9jzNgd0F5/I K0n3fVz4G+ArzsljXesWXfwkYNm2qKpI8wzC3Q4BYIY6cQ2yYuqkVMFj+nJFytq+s/xgk0Sf BCUaFwRiT6uYTJyo0q4Rni5nDxHIrm7aRrVNjahcf7nx2aj3JnNVawV/j4fvUClweLMxvKbj DkF8mhcKcGwtU7GR+boTU2p4dYCs0ZUmg8D/tCAKb4SDp2UFs/6FJILKi8UZzKp8274XsSR6 GL6AYtoRQDscgDfohOH5qmmP8werKSxnx8Hdk6rUu3XIzs/D2ZTZ4ihVPsyaqFgbC33i/fzl 6tit6ShpmopXi+Oinzf1y/LRC43BmfxKWFGAfPrr7QWJCEsnx8QRJPkZvizVE+f1xAgn9Rg/ kSCTBPlITuAl9ffpyzhgn6VhgLprwLUbpWA9Tqyo4QwJjnijDMh+55F/K8uEWnbGtGpHwFGD ZDPkfdu67NQOR/H0bqdcOjPXIdlJU+nGVUZOeL1D+ylQsSBrNkrkrFpKAy/zLu+jTPUyo/ek zin4Jo/jbIK3qfNuYBnehw8ppWEhhRah79UyzS8+L8aCbK9U6RCbqPEcufhESwqbmifCLF4t 2woZLBD+AzG90Bm4MXSYBBhEQpNNlFS+mlRf16AyGc2rfV1GacD4zdK7UWECbimZc9AWl+4i gSlNb1FRDYyDIBZRrmfXnZEr3VOhW/FgYxPNZT0qpXmbJc6FP0BFSFcQqMk9dMNOAlzGyJAG 9SRvLPoqLB6gvnzDzj1GDxAivlx2Z8QiSt0Y1FL+hxSTklY7uIM55yNLLEilXjD+RN/0FECJ g4lEUVaJfuWaSkHHGwIXz06UTnCU/DuvpWMyOFWU00K5uuRWQQRGPf/7TZwLAc5JurYTTlji IbVoW2cMVxg15PXyZTtGFXQNBGO/x29QSQ6eu0Pnzjyx0lhIVJh8WV+mM8BTGjEI1bAO8UDA thOcTzZaVFEItkhI7YIuiXT75Ok1wmRHRMSVJfOiIm6dNyPdOaCeHOlvSxUXDOCMDtYXFTU9 DHuOynxsqSrMWngoM7zFItZO6RtgCe8ZenOliSUNX7144WrNRB/MqMsrmoUkczLwNfqSQZAC PIa54gTHYHWoKJzSAc0r/scPTzZ9eArTtHnTDF/dwKXjiJn5HxcwrIkibtjE9exL1OmQApJq gKnQXchznKluLnqWwBqTKsfuawCYp21ORkUffZC1zIkoa0/PEgFQImkKSReAEWrsB4FivEMl pSCVDigTdX3rGCrq6zWuyfucEzmZy4Xu/fCi3c6loy/3aqWhIbjz4dF/x4lHMNf0+dC3yTtb VkhogalqlKK0qR6tZDhCyWteS4nzsD1vhqC+GEGdZ18DXm5k2AHTN3mf7i4KV+UT/6AcrxUV gpr2HmhJHl+VqvfL8njTWB5EXY4fpXM4UVRj+LeNuKoq7/pK4ZVtwAAthSg+qmwrx+aVeLcm AnyAJf8efCiPzc1n751C1HKFDpfPYTc2QIO2s/c0qO77aRbeEuwgd8el0m6u4WUujUD2Nlcn z+Z9qqUx5OcPV8ab5wkb9w1t9tgKaYYllVb/pleE4PjDiNdXO0FwyQ4I3irlZuaZmLRhs0NZ WSmDiCRWycMy6ugLTepZDu5iBtGfPXTT9/8B2ruKB0AQY+HSYT7tMPe38RhPti+SFqRbjk9x PD4ELXPJzHsUShnFie+bYWOWUqKURdPtUJ3Niwisu24SVER5R4PTFVCVVNcE5jKUAyi7KoDa Ja0ovmFDu/klWgdPoyT/PJnWmHGouSGHpYGG35+IkndVn1c9Xa7C/nppyanGaHJP4YVm+b42 5XIAt7wzWQMEI8oStfGoGhUjUl+jRawG7b+WvCeJrRR+ndAeSLPeulvSQxneemD9aF5TPhG8 cK6Ehnj2KL2B4p1CIVRVN2Q7neJwLUD15rvEjoIEpoopZx9Drbtc/qW+neA6ZKK3Zu86JF3D 9fU/2/wTJVI0l0dQ5Z0vICdz11PZAF6hPlKWBnKMf1XtyINynXshOGuOeBV60gk31kaYatJu wmP3IwiIdnlK0h/OgXf2ORhDoMiq2BWhOIGRptz29Ck0Xo5HxKWPjrLOtyxhl+4kib20BFl2 d/FyERCXnJaNmvCmr+qzjDgd27aenSrG603dKZ7UO2PXhSJs0sBrmQvxmUlcTgu0gmIuzGdb K13j2Glqg86A+XiLxVg5N/wKAZ7idpmoNs4chgup9i4hx9GAsl3WK8Lu4fiDC7xfL/8OSHGE zFhyyTxJ744LzNjd8O5ZALFTIAQZ0pV8mCwKaLQegPakbkZd99K2XiGwF8zdxtYZEsRnz8DS AIEtS6YWQGKVRHtaeKD9sIAeiyQ0wz1voI3MEzpoj0TL2zXY3amEl7kVkb/r/A15x1+gNSl1 fc+7BCtKYJTL/AS2nL6VBOWBvfKe3w7FIhCK+CwPlepioKV7ivHVp3+K60WZ+AxIk7vGEb4k HeX19cBuGetfYcGeYu2RfvEy233jd7qDrKxUoucgziTll4O5dNz0Bbsobd8UM0fzO0PdqFak LnSckMIXLjq8uCR80ca51MBhrnsxjc36u9sQl93+qLPPTGKbHib8T6jX1uddePVhF2lxRZ+S V6j1fWF9LyZd6MLLz+TRWY0bo6adH/bgt4Rtt0fFfq+BksxIGk8LXK2Puqfgfri9HaQI0sJC X+eYdqKwzyaCLGp1DeBpm47wx1z8K2mVamR87S64j86Tboi85rpbp0K2MFN3MXZe8IrdXtYm 6PBB1NJD8aeCEupi8yusAO4cJzz8cWNc1u0PVzhhLfOmKlQ/a509xdkeDMn06O9o6rj29A3E ToFSut98FhQEzUesYOJP4VAdcWZSJT0y55BOJx+IhmK67gmDc1dW3nMYufjDjboi2ao7hQtM 46Ei6bpBL1L1jRlTOzvMlfU6LvwnbJwtfMJDSNYWpAsn2ovNcIqUFWXjtSXohJs5D9nFYOVO 5aKia//kgXj1NYHxc6KrTneMJg4pDCQnwa/7vKAi+PLFAgY5M9AJ9AhlRUfofrREEa2YKGlc BpoURGkSRJjo/t8lY3+5QOXAQoRbwsjR5VMcOu3W3eNf21MkwOejznT+2Kdx2m36qsa8GeiH 3FARqIbzP7LHkJon0+viJSll6JJGpgvyXRKddyYBQf5m1iKgUfrs/uX+3X/I//4b5Ll4fg0K ZW5kc3RyZWFtDQplbmRvYmoNCjYgMCBvYmoNCjQ5NjkNCmVuZG9iag0KNDYgMCBvYmoNCjw8 L0xlbmd0aCAxNTcyL1N1YnR5cGUvWE1ML1R5cGUvTWV0YWRhdGE+PnN0cmVhbQ0KPD94cGFj a2V0IGJlZ2luPSfvu78nIGlkPSdXNU0wTXBDZWhpSHpyZVN6TlRjemtjOWQnPz4KPD9hZG9i ZS14YXAtZmlsdGVycyBlc2M9IkNSTEYiPz4KPHg6eG1wbWV0YSB4bWxuczp4PSdhZG9iZTpu czptZXRhLycgeDp4bXB0az0nWE1QIHRvb2xraXQgMi45LjEtMTMsIGZyYW1ld29yayAxLjYn Pgo8cmRmOlJERiB4bWxuczpyZGY9J2h0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRm LXN5bnRheC1ucyMnIHhtbG5zOmlYPSdodHRwOi8vbnMuYWRvYmUuY29tL2lYLzEuMC8nPgo8 cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0ndXVpZDo1ZDFjMzBmYi01N2FmLTExZTQtMDAw MC03ZmRmMzJhNGMxYWYnIHhtbG5zOnBkZj0naHR0cDovL25zLmFkb2JlLmNvbS9wZGYvMS4z Lyc+PHBkZjpQcm9kdWNlcj5HUEwgR2hvc3RzY3JpcHQgOS4wNzwvcGRmOlByb2R1Y2VyPgo8 cGRmOktleXdvcmRzPigpPC9wZGY6S2V5d29yZHM+CjwvcmRmOkRlc2NyaXB0aW9uPgo8cmRm OkRlc2NyaXB0aW9uIHJkZjphYm91dD0ndXVpZDo1ZDFjMzBmYi01N2FmLTExZTQtMDAwMC03 ZmRmMzJhNGMxYWYnIHhtbG5zOnhtcD0naHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wLyc+ PHhtcDpNb2RpZnlEYXRlPjIwMTQtMTAtMTZUMTg6NDU6MzErMDI6MDA8L3htcDpNb2RpZnlE YXRlPgo8eG1wOkNyZWF0ZURhdGU+MjAxNC0xMC0xNlQxODo0NTozMSswMjowMDwveG1wOkNy ZWF0ZURhdGU+Cjx4bXA6Q3JlYXRvclRvb2w+Y2Fpcm8gMS4xMy4xIChodHRwOi8vY2Fpcm9n cmFwaGljcy5vcmcpPC94bXA6Q3JlYXRvclRvb2w+PC9yZGY6RGVzY3JpcHRpb24+CjxyZGY6 RGVzY3JpcHRpb24gcmRmOmFib3V0PSd1dWlkOjVkMWMzMGZiLTU3YWYtMTFlNC0wMDAwLTdm ZGYzMmE0YzFhZicgeG1sbnM6eGFwTU09J2h0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9t bS8nIHhhcE1NOkRvY3VtZW50SUQ9J3V1aWQ6NWQxYzMwZmItNTdhZi0xMWU0LTAwMDAtN2Zk ZjMyYTRjMWFmJy8+CjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSd1dWlkOjVkMWMzMGZi LTU3YWYtMTFlNC0wMDAwLTdmZGYzMmE0YzFhZicgeG1sbnM6ZGM9J2h0dHA6Ly9wdXJsLm9y Zy9kYy9lbGVtZW50cy8xLjEvJyBkYzpmb3JtYXQ9J2FwcGxpY2F0aW9uL3BkZic+PGRjOnRp dGxlPjxyZGY6QWx0PjxyZGY6bGkgeG1sOmxhbmc9J3gtZGVmYXVsdCc+YWJpd29yZCBqb2Ig IzE8L3JkZjpsaT48L3JkZjpBbHQ+PC9kYzp0aXRsZT48ZGM6Y3JlYXRvcj48cmRmOlNlcT48 cmRmOmxpPmhhbm5lczwvcmRmOmxpPjwvcmRmOlNlcT48L2RjOmNyZWF0b3I+PGRjOmRlc2Ny aXB0aW9uPjxyZGY6U2VxPjxyZGY6bGk+KCk8L3JkZjpsaT48L3JkZjpTZXE+PC9kYzpkZXNj cmlwdGlvbj48L3JkZjpEZXNjcmlwdGlvbj4KPC9yZGY6UkRGPgo8L3g6eG1wbWV0YT4KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAo8P3hwYWNrZXQgZW5kPSd3Jz8+ DQplbmRzdHJlYW0NCmVuZG9iag0KMiAwIG9iag0KPDwvQXV0aG9yKGhhbm5lcykvQ3JlYXRp b25EYXRlKEQ6MjAxNDEwMTYxODQ1MzErMDInMDAnKS9DcmVhdG9yKFBERiBBcmNoaXRlY3Qp L01vZERhdGUoRDoyMDE0MTAxNjE4NDYwNCswMicwMCcpL1Byb2R1Y2VyKFBERiBBcmNoaXRl Y3QpL1RpdGxlKGFiaXdvcmQgam9iICMxKT4+DQplbmRvYmoNCnhyZWYNCjAgMQ0KMDAwMDAw MDAwMCA2NTUzNSBmDQoyIDQ1DQowMDAwMDcyNTk3IDAwMDAwIG4NCjAwMDAwMDAwODAgMDAw MDAgbg0KMDAwMDA2NTYxOSAwMDAwMCBuDQowMDAwMDY1ODc4IDAwMDAwIG4NCjAwMDAwNzA5 MjEgMDAwMDAgbg0KMDAwMDAzMzg1NyAwMDAwMCBuDQowMDAwMDAwMzc5IDAwMDAwIG4NCjAw MDAwMDExNDQgMDAwMDAgbg0KMDAwMDAxMzkxNSAwMDAwMCBuDQowMDAwMDE0NzQzIDAwMDAw IG4NCjAwMDAwNDczMzcgMDAwMDAgbg0KMDAwMDA0Nzk5OSAwMDAwMCBuDQowMDAwMDY1ODQ1 IDAwMDAwIG4NCjAwMDAwNjU3OTAgMDAwMDAgbg0KMDAwMDA2MDMwMyAwMDAwMCBuDQowMDAw MDYwNTY0IDAwMDAwIG4NCjAwMDAwNjU1OTUgMDAwMDAgbg0KMDAwMDA2MDUzMSAwMDAwMCBu DQowMDAwMDYwNDc2IDAwMDAwIG4NCjAwMDAwNDcwOTggMDAwMDAgbg0KMDAwMDA1NTI1MSAw MDAwMCBuDQowMDAwMDYwMjc5IDAwMDAwIG4NCjAwMDAwMzU4MTYgMDAwMDAgbg0KMDAwMDAz NjMxNCAwMDAwMCBuDQowMDAwMDU1MjE4IDAwMDAwIG4NCjAwMDAwNDcyNzEgMDAwMDAgbg0K MDAwMDAzNTU4OCAwMDAwMCBuDQowMDAwMDQyMDc5IDAwMDAwIG4NCjAwMDAwNDcwNzQgMDAw MDAgbg0KMDAwMDA0MjA0NiAwMDAwMCBuDQowMDAwMDM1NzYxIDAwMDAwIG4NCjAwMDAwMDAx NjIgMDAwMDAgbg0KMDAwMDAzMzkxMyAwMDAwMCBuDQowMDAwMDM1NTY0IDAwMDAwIG4NCjAw MDAwMzM4MjQgMDAwMDAgbg0KMDAwMDAwMDMzNSAwMDAwMCBuDQowMDAwMDQ4MjI1IDAwMDAw IG4NCjAwMDAwMzY1MzAgMDAwMDAgbg0KMDAwMDAwMTM2NiAwMDAwMCBuDQowMDAwMDE0OTUw IDAwMDAwIG4NCjAwMDAwNDc3MjYgMDAwMDAgbg0KMDAwMDAzNjA0NyAwMDAwMCBuDQowMDAw MDAwODA1IDAwMDAwIG4NCjAwMDAwMTQ0NDEgMDAwMDAgbg0KMDAwMDA3MDk0NCAwMDAwMCBu DQo0OCAxDQowMDAwMDAwMDE1IDAwMDAwIG4NCnRyYWlsZXIKPDwvSURbPGJlNDc3YjFmMDU3 YWYyMGUwMjY1ODRiYTViNWYwMTQwPiA8YmU0NzdiMWYwNTdhZjIwZTAyNjU4NGJhNWI1ZjAx NDA+XS9JbmZvIDIgMCBSL1Jvb3QgNDggMCBSL1NpemUgNDk+PgpzdGFydHhyZWYKNzI3NzUK JSVFT0Y= --------------080201090208040905040500-- --Psg3BoFlgbsoAelCCDaT4d5kS6MiO8dim Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUP/hQAAoJEGhJURNOOiAt4j4H/23tRNMSixpIQWX4F8bGWqKp eEk9cAYy2XYGE0mnoUOXrEbsejKppXEVfR94py2FadDwIPBDO2TZMCLPdasC8nkZ DxHRcBqoi5qF8O23RUxkUlZUMCnQUtfhw27jrOU11w1JnLGv37sMsWYXh3lhpZwv 3CJEeam0CT0hUeH0ljxaKfoZfjYmnMQL8S8ruoQ+au/ENzdWPUAwZp905HftIKYP +3SLpoPYX3G/2B30ZpdO39lUKN4y98RFJcWx+de1XPNpPlhorwIZP9wd7ul07JBB e19nfGeQ0b9h+iJaBusLKKabSnzYoKbgAsx1ps5UBzoLSDwGiz5JyDHlQnUfpOQ= =k+L2 -----END PGP SIGNATURE----- --Psg3BoFlgbsoAelCCDaT4d5kS6MiO8dim-- From nobody Thu Oct 16 09:57:43 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47B091A0195; Thu, 16 Oct 2014 09:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQOQinjX8pk4; Thu, 16 Oct 2014 09:57:27 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B81EE1A00E9; Thu, 16 Oct 2014 09:57:10 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s9GGv8qp000916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 16 Oct 2014 16:57:09 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s9GGv73x014817 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Oct 2014 16:57:08 GMT Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s9GGv7Zv002171; Thu, 16 Oct 2014 16:57:07 GMT Received: from [192.168.1.133] (/24.87.24.131) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 16 Oct 2014 09:57:07 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_5AFC13B7-50E7-4EB6-B5E3-11BC40117701" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: Date: Thu, 16 Oct 2014 09:57:05 -0700 Message-Id: References: <20141016034735.18695.61014.idtracker@ietfa.amsl.com> To: Brian Campbell X-Mailer: Apple Mail (2.1878.6) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Y6ztw4E__NmLr_-A7wO8V2RlI8k Cc: Richard Barnes , "draft-ietf-oauth-assertions@tools.ietf.org" , "oauth-chairs@tools.ietf.org" , The IESG , oauth Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 16:57:33 -0000 --Apple-Mail=_5AFC13B7-50E7-4EB6-B5E3-11BC40117701 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii It is also important for a non-protocol purpose. Liability. If a 3rd party uses an assertion that was not intended for it, it cannot = obviously hold the asserting party responsible. =20 Phil @independentid www.independentid.com phil.hunt@oracle.com On Oct 16, 2014, at 8:43 AM, Brian Campbell = wrote: > Thanks for your review and feedback, Richard. Replies are inline = below... >=20 > On Wed, Oct 15, 2014 at 9:47 PM, Richard Barnes wrote: > Richard Barnes has entered the following ballot position for > draft-ietf-oauth-assertions-17: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > "The assertion MUST contain an Audience that identifies the = Authorization > Server as the intended audience. Assertions that do not identify the > Authorization Server as an intended audience MUST be rejected." >=20 > Could you please identify the threat model within which this "MUST" is > required? This requirement doesn't follow from any of the threats > elaborated in Section 8. >=20 > The Audience is only necessary if the Issuer wishes to constrain the = set > of Authorization Servers with which an assertion may be used. So ISTM > that this should be "MAY contain..." >=20 >=20 >=20 > The audience restriction let's the issuer say specifically what = relying party is allowed to consume the assertion, which ensures that = the client can't use it somewhere else that it wasn't intended and that = the relying party that receives the assertion can't turn around and use = it to access some other service. >=20 > Strictly speaking, you are right that the audience is only necessary = if the Issuer wishes to constrain the set of Authorization Servers with = which an assertion may be used. But the Issuer really really really = should make that constraint and fully understanding the implications of = not doing so is difficult and unlikely.=20 >=20 > There was a vulnerability in Google apps SAML a few years back that = demonstrates how important audience restriction is and how it can be = difficult for even very sophisticated providers to get it all right. I = haven't had time to read it again to make sure but I think that this is = the paper http://www.ai-lab.it/armando/pub/fmse9-armando.pdf >=20 > I don't see what value allowing audience to be omitted brings other = than that it is academically a possibility. But requiring it (hopefully, = if the requirement is followed) helps reduce the possibility of a whole = bunch of security problems that folks likely won't foresee. >=20 > =20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > "keyed message digest" -> "Message Authentication Code" >=20 > That's the proper terminology [RFC4949], especially since there are = MACs > that are not based on digests. >=20 > OK > =20 >=20 > "This mechanism provides additional security properties." -- Please > delete this or elaborate on what security properties it provides. >=20 > Will delete. > =20 >=20 > Section 8.2 should note that "Holder-of-Key Assertions" are also a > mitigation for this risk. >=20 >=20 > OK > =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=_5AFC13B7-50E7-4EB6-B5E3-11BC40117701 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii It is = also important for a non-protocol purpose. = Liability.

If a 3rd party uses an assertion that was = not intended for it, it cannot obviously hold the asserting party = responsible.  


On Oct 16, 2014, at 8:43 AM, Brian Campbell <bcampbell@pingidentity.com&= gt; wrote:

Thanks for your review and = feedback, Richard.=20 Replies are inline below...

On Wed, Oct 15, = 2014 at 9:47 PM, Richard Barnes <rlb@ipv.sx> = wrote:
Richard = Barnes has entered the following ballot position for
draft-ietf-oauth-assertions-17: Discuss

When responding, please keep the subject line intact and reply to = all
email addresses included in the To and CC lines. (Feel free to cut = this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html=
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-oauth-asserti= ons/



= ----------------------------------------------------------------------
= DISCUSS:
= ----------------------------------------------------------------------
=
"The assertion MUST contain an Audience that identifies the = Authorization
Server as the intended audience.  Assertions that do not identify = the
Authorization Server as an intended audience MUST be rejected."

Could you please identify the threat model within which this "MUST" = is
required?  This requirement doesn't follow from any of the = threats
elaborated in Section 8.

The Audience is only necessary if the Issuer wishes to constrain the = set
of Authorization Servers with which an assertion may be used.  So = ISTM
that this should be "MAY contain..."



The audience restriction let's = the issuer say specifically what=20 relying party is allowed to consume the assertion, which ensures that=20 the client can't use it somewhere else that it wasn't intended and that = the=20 relying party that receives the assertion can't turn around and use it=20= to access some other service.

Strictly = speaking, you are right that the audience is only necessary if the = Issuer wishes to constrain the set of Authorization Servers with which = an assertion may be used. But the Issuer really really really should = make that constraint and fully understanding the implications of not = doing so is difficult and unlikely.

There was a = vulnerability in Google apps SAML a few years back that demonstrates how = important audience restriction is and how it can be difficult for = even very sophisticated providers to get it all right. I haven't had = time to read it again to make sure but I think that this is the paper http://www.ai-= lab.it/armando/pub/fmse9-armando.pdf

I = don't see what value allowing audience to be omitted brings other than = that it is academically a possibility. But requiring it (hopefully, if = the requirement is followed) helps reduce the possibility of a whole = bunch of security problems that folks likely won't = foresee.

 
= ----------------------------------------------------------------------
= COMMENT:
= ----------------------------------------------------------------------
=
"keyed message digest" -> "Message Authentication Code"

That's the proper terminology [RFC4949], especially since there are = MACs
that are not based on = digests.

OK
 
=

"This mechanism provides additional security properties." -- Please
delete this or elaborate on what security properties it = provides.

Will = delete.
 

Section 8.2 should note that "Holder-of-Key Assertions" are also a
mitigation for this risk.
=

OK
 
&nb= sp;
_______________________________________________
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=_5AFC13B7-50E7-4EB6-B5E3-11BC40117701-- From nobody Thu Oct 16 09:57:55 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA771A00E9; Thu, 16 Oct 2014 09:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aa6o9gRBJZiz; Thu, 16 Oct 2014 09:57:33 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54DCE1A01A5; Thu, 16 Oct 2014 09:57:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1413478639; x=1445014639; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=ZJQUNN73O22zNbfimx1+PrEXDNJNWFaWoIbEYBy1Jt0=; b=ugIofNpAwdohCqnWEwphWq33l76L65sYl1txEKpshqoepIxiZZpnoqUM X1zIgQJCDBeSGBo4/YET7NMLlLoHGRQdr8B1DTJ8SOza7lgxQ8mfr9AZl VNgelxc5aW2Z/cSVgD1B4hGNUz/Wxva9WDIwJHFoCGSygfg2ULP8QljT1 8=; X-IronPort-AV: E=McAfee;i="5600,1067,7593"; a="167122386" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Oct 2014 09:57:18 -0700 X-IronPort-AV: E=Sophos;i="5.04,733,1406617200"; d="scan'208,217";a="825771581" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 16 Oct 2014 09:57:16 -0700 Received: from NASANEXM01F.na.qualcomm.com (10.46.201.192) by nasanexhc07.na.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 16 Oct 2014 09:57:15 -0700 Received: from presnick-mac.local (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.46.201.192) with Microsoft SMTP Server (TLS) id 15.0.913.22; Thu, 16 Oct 2014 09:57:15 -0700 Message-ID: <543FF8E9.4050400@qti.qualcomm.com> Date: Thu, 16 Oct 2014 11:57:13 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Brian Campbell References: <20141015015609.5671.70479.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010204090507080606020503" X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanexm01a.na.qualcomm.com (129.46.53.228) To NASANEXM01F.na.qualcomm.com (10.46.201.192) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/wk08-QNtMwrYHqO5N1W20W-OyRY Cc: "oauth-chairs@tools.ietf.org" , draft-ietf-oauth-saml2-bearer@tools.ietf.org, The IESG , oauth Subject: Re: [OAUTH-WG] Pete Resnick's No Objection on draft-ietf-oauth-saml2-bearer-21: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 16:57:36 -0000 --------------010204090507080606020503 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit On 10/16/14 7:56 AM, Brian Campbell wrote: > Thanks for your review and feedback on this one too, Pete. Replies are > inline below... > > On Tue, Oct 14, 2014 at 7:56 PM, Pete Resnick > > wrote: > > 2.1/2.2 - This paragraph shows why I don't like haphazard use of 2119. > > > Apologies for any haphazardness. No worries. As you've discovered, throughout the organization we're pretty bad about consistent use of it, so if you use other RFCs for examples, you get weird results. I'm very happy to see that you're trying to get this right. > But the > second one buries what *might* be a proper and important use of > MUST (you > MUST NOT try to stick in two SAML Assertions) with a simple > definitional > one. (And that assumes that it's even plausible to try to use more > than > one SAML Assertion. If you simply can't, it's just s/MUST > contain/contains.) > > > It's intended to be both definitional and restrictive - that it > contains an assertion but not more than one. > > The Response document in SAML Web SSO allows for multiple assertions > and it has turned out to be quite a pain to deal with in practice > while not adding any real value. While it's not entirely clear how one > might try and stick more than one assertion in this parameter given > the serialization, I still wanted to explicitly preclude it. Ah, good. Then some sort of MUST is appropriate. > Given that explanation of the intent, would you suggest an alternative > wording of that sentence? Or is it okay as is? I think it's OK as is, but would be better if you had the requirement on the right thing: The value of the "assertion" parameter contains a single SAML 2.0 Assertion. It MUST NOT contain more than one SAML 2.0 assertion. That makes it clear that you're not simply saying "Put the SAML 2.0 Assertion in here." You're saying, "Don't try to squeeze in more than one." > > The base64url encoding MUST is fine, because you don't > want people sticking in raw XML, but the SHOULD NOTs for line wrapping > and pad I am curious about: Isn't a parser going to have to check for > line wrapping and pad anyway and undo it (because it's not a MUST > NOT), > and therefore this SHOULD NOT really isn't about interoperability > so much > as neatness (in which case they SHOULD NOTs are not appropriate)? > > > > Yes, the base64 decoder still has to be prepared to deal with line > wrapping and padding. In my experience most decoders are very capable > of it. And stripping the white-space and "="s prior to decoding is > easy enough for those using a decoder that can't. > > The SHOULD NOT is about neatness but also in a way about interop in > that it's intended to help avoid common implementation problems that > can arise with urlencoding the parameter value (either not encoding or > double encoding, etc.). Base64url without line wraps and padding > dosn't need urlencoding and doesn't change if urlencoding is applied. > > That was the thinking behind the SHOULD NOTs there. > > As I try and articulate the reasoning, it does feel like maybe it > should have been a MUST NOT. I guess I was looking to channel Postel a > bit in being somewhat liberal in what is accepted with padding/no > padding and line wraps/no line wraps while using the SHOULD NOTs to > suggest that clients be conservative in what they send. > > Thoughts about what to do with it, given that reasoning? I agree with your gut: If implementations are going to bump into other implementations that fail to encode properly or double encode when encountering line wraps and padding, then you should say MUST NOT. You might even want to say, "Due to some poor implementations, you MUST NOT use line wrapping or padding when you create these things, but you MUST decode them if you receive them". > 3 - Subpoint 2: Just for clarification, I like the non-passive > sentence > better: "The Authorization Server MUST reject any assertion that > does not > contain its own identity as the intended audience." > > > > Yes, on seeing it written that way, I also like it better. > > Just to make sure I'm on the same page. The sentence you suggest would > replace the second to last sentence in #2 that currently says, > "Assertions that do not identify [...] MUST be rejected."? Correct. > Subpoint 7: Are you sure those SHOULDs and SHOULD NOTs are not > conflicting? Can you not have an authenticated subject with an > autonomously acting client? > > > > Perhaps I've misused the words but, yes, that's the idea. An > autonomously acting client is meant to describe a client that's acting > without the user being present. The act of direct user authentication > with the assertion issuer seems like the way to differentiate between > the user being present for things and the client doing things "in the > background" for the user. Both are valid use cases. Item 7 is looking > to provide the AS with some clue as to which is happening. Ah, so what you mean by "the Assertion issuer authenticated the subject" is specifically that there was user interaction and *not* an autonomously acting client. I didn't read the first sentence that way. > I'm open to suggestions to clarify the text but I do believe there's > no conflict. Maybe just saying "directly authenticated" in the first sentence or something like that. But this may be obvious to someone who's implementing, so entirely up to you. Thanks for the rest. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 --------------010204090507080606020503 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit On 10/16/14 7:56 AM, Brian Campbell wrote:
Thanks for your review and feedback on this one too, Pete. Replies are inline below...

On Tue, Oct 14, 2014 at 7:56 PM, Pete Resnick <presnick@qti.qualcomm.com> wrote:

2.1/2.2 - This paragraph shows why I don't like haphazard use of 2119.
 

Apologies for any haphazardness.

No worries. As you've discovered, throughout the organization we're pretty bad about consistent use of it, so if you use other RFCs for examples, you get weird results. I'm very happy to see that you're trying to get this right.

But the
second one buries what *might* be a proper and important use of MUST (you
MUST NOT try to stick in two SAML Assertions) with a simple definitional
one. (And that assumes that it's even plausible to try to use more than
one SAML Assertion. If you simply can't, it's just s/MUST
contain/contains.)
 

It's intended to be both definitional and restrictive - that it contains an assertion but not more than one.

The Response document in SAML Web SSO allows for multiple assertions and it has turned out to be quite a pain to deal with in practice while not adding any real value. While it's not entirely clear how one might try and stick more than one assertion in this parameter given the serialization, I still wanted to explicitly preclude it.

Ah, good. Then some sort of MUST is appropriate.

Given that explanation of the intent, would you suggest an alternative wording of that sentence? Or is it okay as is?

I think it's OK as is, but would be better if you had the requirement on the right thing:

   The value of the "assertion" parameter contains a single SAML 2.0
   Assertion. It MUST NOT contain more than one SAML 2.0 assertion.

That makes it clear that you're not simply saying "Put the SAML 2.0 Assertion in here." You're saying, "Don't try to squeeze in more than one."
 
The base64url encoding MUST is fine, because you don't
want people sticking in raw XML, but the SHOULD NOTs for line wrapping
and pad I am curious about: Isn't a parser going to have to check for
line wrapping and pad anyway and undo it (because it's not a MUST NOT),
and therefore this SHOULD NOT really isn't about interoperability so much
as neatness (in which case they SHOULD NOTs are not appropriate)?


Yes, the base64 decoder still has to be prepared to deal with line wrapping and padding. In my experience most decoders are very capable of it. And stripping the white-space and "="s prior to decoding is easy enough for those using a decoder that can't.

The SHOULD NOT is about neatness but also in a way about interop in that it's intended to help avoid common implementation problems that can arise with urlencoding the parameter value (either not encoding or double encoding, etc.).  Base64url without line wraps and padding dosn't need urlencoding and doesn't change if urlencoding is applied.

That was the thinking behind the SHOULD NOTs there.

As I try and articulate the reasoning, it does feel like maybe it should have been a MUST NOT. I guess I was looking to channel Postel a bit in being somewhat liberal in what is accepted with padding/no padding and line wraps/no line wraps while using the SHOULD NOTs to suggest that clients be conservative in what they send. 

Thoughts about what to do with it, given that reasoning?

I agree with your gut: If implementations are going to bump into other implementations that fail to encode properly or double encode when encountering line wraps and padding, then you should say MUST NOT. You might even want to say, "Due to some poor implementations, you MUST NOT use line wrapping or padding when you create these things, but you MUST decode them if you receive them".

3 - Subpoint 2: Just for clarification, I like the non-passive sentence
better: "The Authorization Server MUST reject any assertion that does not
contain its own identity as the intended audience."


Yes, on seeing it written that way, I also like it better.

Just to make sure I'm on the same page. The sentence you suggest would replace the second to last sentence in #2 that currently says, "Assertions that do not identify [...] MUST be rejected."?

Correct.

Subpoint 7: Are you sure those SHOULDs and SHOULD NOTs are not
conflicting? Can you not have an authenticated subject with an
autonomously acting client?


Perhaps I've misused the words but, yes, that's the idea. An autonomously acting client is meant to describe a client that's acting without the user being present. The act of direct user authentication with the assertion issuer seems like the way to differentiate between the user being present for things and the client doing things "in the background" for the user. Both are valid use cases. Item 7 is looking to provide the AS with some clue as to which is happening.

Ah, so what you mean by "the Assertion issuer authenticated the subject" is specifically that there was user interaction and *not* an autonomously acting client. I didn't read the first sentence that way.
I'm open to suggestions to clarify the text but I do believe there's no conflict.

Maybe just saying "directly authenticated" in the first sentence or something like that. But this may be obvious to someone who's implementing, so entirely up to you.

Thanks for the rest.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
--------------010204090507080606020503-- From nobody Thu Oct 16 10:14:48 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE1241A026C for ; Thu, 16 Oct 2014 10:14:42 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f5wtl5qULBXy for ; Thu, 16 Oct 2014 10:14:40 -0700 (PDT) Received: from na3sys009aog134.obsmtp.com (na3sys009aog134.obsmtp.com [74.125.149.83]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 947BD1A0384 for ; Thu, 16 Oct 2014 10:14:39 -0700 (PDT) Received: from mail-wg0-f52.google.com ([74.125.82.52]) (using TLSv1) by na3sys009aob134.postini.com ([74.125.148.12]) with SMTP ID DSNKVD/8/+YraKs8lGPCoE8EJqQpldTIczeZ@postini.com; Thu, 16 Oct 2014 10:14:39 PDT Received: by mail-wg0-f52.google.com with SMTP id a1so4241786wgh.23 for ; Thu, 16 Oct 2014 10:14:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=65C16y0fBuyu+yHaJlyQZg1a9cIUIxIuMtahXnNStTM=; b=MSQKgTBGSJx6yNuMUxcucvfQ2dPyPp0q242RvNVyitTIPPduGRvVoUEtB1ZtDNs8eN NPJPjBAZACHWDTu6kP85/dY4l4HJVp4zS4M1Mv+DvOp9+ocM9xDhpBK2xS0q+SzI+fAg 3/tmdqfqBiHJFULa+oX8A5cXqCEwGf0PwwJwVa09mMildu2aKCcd/J1cX1ljyXV8g0bh IMq0dXKE3H3LiGmju/X79b+rFheAAYID9Wl7d+OuEjSxNhMJFH6kj9LO2pyWm1iXahuN XQ8N3tmacUp0rMLJ4EtUKTgkSpGaDsecywYf5+zi+6vFmxVBduAc+OW6LqlyXmJFwllO x4xg== X-Received: by 10.194.108.104 with SMTP id hj8mr3926856wjb.28.1413479190027; Thu, 16 Oct 2014 10:06:30 -0700 (PDT) X-Gm-Message-State: ALoCoQmMWKPWs08qK15pJyW5JbHF7pw68NbBOpuF0WGJCy3ENy9815EOSHEG1y7hOo3VyDDNdgljRHtmj1InsqiD0gd8jtWHpX1RHx+n0EeZ8Y2ZVgfmM9DYy9Zw0qqVT4eZRd5BS7Zm X-Received: by 10.194.108.104 with SMTP id hj8mr3926833wjb.28.1413479189877; Thu, 16 Oct 2014 10:06:29 -0700 (PDT) Received: from [192.168.99.228] (fw-obester.ippark.hu. [93.189.112.82]) by mx.google.com with ESMTPSA id td9sm2651521wic.15.2014.10.16.10.06.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 16 Oct 2014 10:06:29 -0700 (PDT) Message-ID: <543FFB13.2060903@pingidentity.com> Date: Thu, 16 Oct 2014 19:06:27 +0200 From: Hans Zandbelt User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Hannes Tschofenig , "oauth@ietf.org" References: <543FF850.6070409@gmx.net> In-Reply-To: <543FF850.6070409@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/oPVmyqpMcU8YwlLj7xo8WFIxv2U Subject: Re: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference Call X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 17:14:43 -0000 About the write-up: at the end of the metaphor section it says: "These recipes each add a number of items, such as a common profile API, to OAuth to create an authorization protocol." whereas I believe that should read "to create an authentication protocol" Hans. On 10/16/14, 6:54 PM, Hannes Tschofenig wrote: > Participants: > > * Brian Campbell > * John Bradley > * Derek Atkins > * Phil Hunt > * William Kim > * Josh Mandel > * Hannes Tschofenig > > > Notes: > > Justin distributed a draft writeup and explained the reasoning behind > it. The intended purpose is to put the write-up (after enough review) on > oauth.net. See attachments. Justin solicited feedback from the > conference call participants and from the working group. > > One discussion item was specifically related to the concept of audience > restrictions, which comes in two flavours: (a) restriction of the access > token regarding the resource server and (b) restriction of the id token > regarding the client. Obviously, it is necessary to have both of these > audience restrictions in place and to actually check them. > > The group then went into a discussion about the use of pseudonyms in > authentication and the problems deployments ran into when they used > pseudonyms together with a wide range of attributes that identified > users nevertheless. Phil suggested to produce a write-up about this topic. > > Finally, the group started a discussion about potential actions for the > OAuth working groups. Two activities were mentioned, namely to produce > an IETF draft of the write-up Justin has prepared as a "formal" response > to the problems with authentication using OAuth and, as a second topic, > potential re-chartering of the OAuth working group to work on some > solutions in this area. Hannes suggested to postpone these discussions > and to first finish the write-up Justin had distributed. > > Ciao > Hannes & Derek > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Hans Zandbelt | Sr. Technical Architect hzandbelt@pingidentity.com | Ping Identity From nobody Thu Oct 16 10:18:43 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6241A1A53 for ; Thu, 16 Oct 2014 10:18:41 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bcfEB4zwFIsy for ; Thu, 16 Oct 2014 10:18:39 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0738.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::738]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 372021A0262 for ; Thu, 16 Oct 2014 10:18:39 -0700 (PDT) Received: from CO2PR03CA0037.namprd03.prod.outlook.com (10.141.194.164) by BN3PR0301MB1203.namprd03.prod.outlook.com (25.161.207.156) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Thu, 16 Oct 2014 17:18:16 +0000 Received: from BN1AFFO11FD043.protection.gbl (2a01:111:f400:7c10::159) by CO2PR03CA0037.outlook.office365.com (2a01:111:e400:1414::36) with Microsoft SMTP Server (TLS) id 15.0.1054.13 via Frontend Transport; Thu, 16 Oct 2014 17:18:15 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD043.mail.protection.outlook.com (10.58.52.190) with Microsoft SMTP Server (TLS) id 15.0.1039.16 via Frontend Transport; Thu, 16 Oct 2014 17:18:14 +0000 Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.93]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.03.0210.003; Thu, 16 Oct 2014 17:17:20 +0000 From: Mike Jones To: Hannes Tschofenig , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference Call Thread-Index: AQHP6WHyCnqSTU0UXUu4rbcrj4fKYZwy9S7A Date: Thu, 16 Oct 2014 17:17:20 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439BB13AB8@TK5EX14MBXC286.redmond.corp.microsoft.com> References: <543FF850.6070409@gmx.net> In-Reply-To: <543FF850.6070409@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(199003)(189002)(13464003)(30513003)(377454003)(120916001)(31966008)(85306004)(76482002)(104016003)(99396003)(33656002)(2656002)(87936001)(4396001)(86362001)(85852003)(97736003)(92566001)(92726001)(66066001)(85806002)(47776003)(20776003)(64706001)(46102003)(80022003)(86612001)(50466002)(23676002)(84676001)(2501002)(19580395003)(19580405001)(69596002)(6806004)(44976005)(68736004)(21056001)(55846006)(95666004)(107046002)(107886001)(106466001)(50986999)(81156004)(54356999)(76176999)(106116001)(77096002)(26826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1203; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1203; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 036614DD9C Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/H4jucBQLfEEAyrnxljLBrGULIDE Subject: Re: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference Call X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 17:18:41 -0000 Rm9yIHdoYXQgaXQncyB3b3J0aCwgSSB3YXMgb24gdGhlIGNhbGwgdG9vIC0gdW50aWwgSSBhbmQg QnJpYW4gbGVmdCB0byBqb2luIHRoZSB0ZWxlY2hhdCBmb3IgdGhlIE9BdXRoIGFzc2VydGlvbnMg ZHJhZnRzLg0KDQoJCQkJLS0gTWlrZQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSGFu bmVzIFRzY2hvZmVuaWcNClNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDE2LCAyMDE0IDk6NTUgQU0N ClRvOiBvYXV0aEBpZXRmLm9yZw0KU3ViamVjdDogW09BVVRILVdHXSBOb3RlcyBmcm9tIDJuZCAi T0F1dGggJiBBdXRoZW50aWNhdGlvbiIgQ29uZmVyZW5jZSBDYWxsDQoNClBhcnRpY2lwYW50czoN Cg0KICogQnJpYW4gQ2FtcGJlbGwNCiAqIEpvaG4gQnJhZGxleQ0KICogRGVyZWsgQXRraW5zDQog KiBQaGlsIEh1bnQNCiAqIFdpbGxpYW0gS2ltDQogKiBKb3NoIE1hbmRlbA0KICogSGFubmVzIFRz Y2hvZmVuaWcNCg0KDQpOb3RlczoNCg0KSnVzdGluIGRpc3RyaWJ1dGVkIGEgZHJhZnQgd3JpdGV1 cCBhbmQgZXhwbGFpbmVkIHRoZSByZWFzb25pbmcgYmVoaW5kIGl0LiBUaGUgaW50ZW5kZWQgcHVy cG9zZSBpcyB0byBwdXQgdGhlIHdyaXRlLXVwIChhZnRlciBlbm91Z2ggcmV2aWV3KSBvbiBvYXV0 aC5uZXQuIFNlZSBhdHRhY2htZW50cy4gSnVzdGluIHNvbGljaXRlZCBmZWVkYmFjayBmcm9tIHRo ZSBjb25mZXJlbmNlIGNhbGwgcGFydGljaXBhbnRzIGFuZCBmcm9tIHRoZSB3b3JraW5nIGdyb3Vw Lg0KDQpPbmUgZGlzY3Vzc2lvbiBpdGVtIHdhcyBzcGVjaWZpY2FsbHkgcmVsYXRlZCB0byB0aGUg Y29uY2VwdCBvZiBhdWRpZW5jZSByZXN0cmljdGlvbnMsIHdoaWNoIGNvbWVzIGluIHR3byBmbGF2 b3VyczogKGEpIHJlc3RyaWN0aW9uIG9mIHRoZSBhY2Nlc3MgdG9rZW4gcmVnYXJkaW5nIHRoZSBy ZXNvdXJjZSBzZXJ2ZXIgYW5kIChiKSByZXN0cmljdGlvbiBvZiB0aGUgaWQgdG9rZW4gcmVnYXJk aW5nIHRoZSBjbGllbnQuIE9idmlvdXNseSwgaXQgaXMgbmVjZXNzYXJ5IHRvIGhhdmUgYm90aCBv ZiB0aGVzZSBhdWRpZW5jZSByZXN0cmljdGlvbnMgaW4gcGxhY2UgYW5kIHRvIGFjdHVhbGx5IGNo ZWNrIHRoZW0uDQoNClRoZSBncm91cCB0aGVuIHdlbnQgaW50byBhIGRpc2N1c3Npb24gYWJvdXQg dGhlIHVzZSBvZiBwc2V1ZG9ueW1zIGluIGF1dGhlbnRpY2F0aW9uIGFuZCB0aGUgcHJvYmxlbXMg ZGVwbG95bWVudHMgcmFuIGludG8gd2hlbiB0aGV5IHVzZWQgcHNldWRvbnltcyB0b2dldGhlciB3 aXRoIGEgd2lkZSByYW5nZSBvZiBhdHRyaWJ1dGVzIHRoYXQgaWRlbnRpZmllZCB1c2VycyBuZXZl cnRoZWxlc3MuIFBoaWwgc3VnZ2VzdGVkIHRvIHByb2R1Y2UgYSB3cml0ZS11cCBhYm91dCB0aGlz IHRvcGljLg0KDQpGaW5hbGx5LCB0aGUgZ3JvdXAgc3RhcnRlZCBhIGRpc2N1c3Npb24gYWJvdXQg cG90ZW50aWFsIGFjdGlvbnMgZm9yIHRoZSBPQXV0aCB3b3JraW5nIGdyb3Vwcy4gVHdvIGFjdGl2 aXRpZXMgd2VyZSBtZW50aW9uZWQsIG5hbWVseSB0byBwcm9kdWNlIGFuIElFVEYgZHJhZnQgb2Yg dGhlIHdyaXRlLXVwIEp1c3RpbiBoYXMgcHJlcGFyZWQgYXMgYSAiZm9ybWFsIiByZXNwb25zZSB0 byB0aGUgcHJvYmxlbXMgd2l0aCBhdXRoZW50aWNhdGlvbiB1c2luZyBPQXV0aCBhbmQsIGFzIGEg c2Vjb25kIHRvcGljLCBwb3RlbnRpYWwgcmUtY2hhcnRlcmluZyBvZiB0aGUgT0F1dGggd29ya2lu ZyBncm91cCB0byB3b3JrIG9uIHNvbWUgc29sdXRpb25zIGluIHRoaXMgYXJlYS4gSGFubmVzIHN1 Z2dlc3RlZCB0byBwb3N0cG9uZSB0aGVzZSBkaXNjdXNzaW9ucyBhbmQgdG8gZmlyc3QgZmluaXNo IHRoZSB3cml0ZS11cCBKdXN0aW4gaGFkIGRpc3RyaWJ1dGVkLg0KDQpDaWFvDQpIYW5uZXMgJiBE ZXJlaw0K From nobody Thu Oct 16 10:27:09 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B32B1A01F0 for ; Thu, 16 Oct 2014 10:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1LCVCTnM14T for ; Thu, 16 Oct 2014 10:27:04 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id C4A6C1A0171 for ; Thu, 16 Oct 2014 10:27:04 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 5E0D752E217; Thu, 16 Oct 2014 13:27:04 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id F2E5252E267; Thu, 16 Oct 2014 13:27:03 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.195]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.03.0174.001; Thu, 16 Oct 2014 13:27:03 -0400 From: "Richer, Justin P." To: Hans Zandbelt Thread-Topic: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference Call Thread-Index: AQHP6WZlO/nGGvgIwEWGX+qJtsnt/g== Date: Thu, 16 Oct 2014 17:27:02 +0000 Message-ID: References: <543FF850.6070409@gmx.net> <543FFB13.2060903@pingidentity.com> In-Reply-To: <543FFB13.2060903@pingidentity.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.15.56] Content-Type: text/plain; charset="us-ascii" Content-ID: <52123633CFB58C4880F644A654482268@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/I8p_pglPgY53F6JoEqMpRX4G5jI Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference Call X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 17:27:07 -0000 Ah yes, good catch! If only someone would put up a webpage describing the d= ifference between authorization and authentication and why people need to s= top confusing the two. Oh wait... On Oct 16, 2014, at 1:06 PM, Hans Zandbelt wro= te: > About the write-up: at the end of the metaphor section it says: > "These recipes each add a number of items, such as a common profile API, = to OAuth to create an authorization protocol." >=20 > whereas I believe that should read "to create an authentication protocol" >=20 > Hans. >=20 > On 10/16/14, 6:54 PM, Hannes Tschofenig wrote: >> Participants: >>=20 >> * Brian Campbell >> * John Bradley >> * Derek Atkins >> * Phil Hunt >> * William Kim >> * Josh Mandel >> * Hannes Tschofenig >>=20 >>=20 >> Notes: >>=20 >> Justin distributed a draft writeup and explained the reasoning behind >> it. The intended purpose is to put the write-up (after enough review) on >> oauth.net. See attachments. Justin solicited feedback from the >> conference call participants and from the working group. >>=20 >> One discussion item was specifically related to the concept of audience >> restrictions, which comes in two flavours: (a) restriction of the access >> token regarding the resource server and (b) restriction of the id token >> regarding the client. Obviously, it is necessary to have both of these >> audience restrictions in place and to actually check them. >>=20 >> The group then went into a discussion about the use of pseudonyms in >> authentication and the problems deployments ran into when they used >> pseudonyms together with a wide range of attributes that identified >> users nevertheless. Phil suggested to produce a write-up about this topi= c. >>=20 >> Finally, the group started a discussion about potential actions for the >> OAuth working groups. Two activities were mentioned, namely to produce >> an IETF draft of the write-up Justin has prepared as a "formal" response >> to the problems with authentication using OAuth and, as a second topic, >> potential re-chartering of the OAuth working group to work on some >> solutions in this area. Hannes suggested to postpone these discussions >> and to first finish the write-up Justin had distributed. >>=20 >> Ciao >> Hannes & Derek >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 > --=20 > Hans Zandbelt | Sr. Technical Architect > hzandbelt@pingidentity.com | Ping Identity >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Thu Oct 16 10:30:41 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A35C61A1A3E for ; Thu, 16 Oct 2014 10:30:40 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qAGr7jfW0BXb for ; Thu, 16 Oct 2014 10:30:36 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0101.outbound.protection.outlook.com [207.46.100.101]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13AFC1A037C for ; Thu, 16 Oct 2014 10:30:35 -0700 (PDT) Received: from BLUPR03MB309.namprd03.prod.outlook.com (10.141.48.22) by BLUPR03MB312.namprd03.prod.outlook.com (10.141.48.28) with Microsoft SMTP Server (TLS) id 15.0.1049.13; Thu, 16 Oct 2014 17:30:34 +0000 Received: from BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) by BLUPR03MB309.namprd03.prod.outlook.com ([10.141.48.22]) with mapi id 15.00.1049.020; Thu, 16 Oct 2014 17:30:34 +0000 From: Anthony Nadalin To: Mike Jones , Hannes Tschofenig , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference Call Thread-Index: AQHP6WVAUAvZkMSPKUa1thYjKTPkJ5wy+tCQ Date: Thu, 16 Oct 2014 17:30:34 +0000 Message-ID: References: <543FF850.6070409@gmx.net> <4E1F6AAD24975D4BA5B16804296739439BB13AB8@TK5EX14MBXC286.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439BB13AB8@TK5EX14MBXC286.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [2001:4898:80e8:ed31::2] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB312; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 036614DD9C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(30513003)(199003)(189002)(13464003)(19580405001)(2561002)(19580395003)(99396003)(86612001)(120916001)(74316001)(86362001)(108616004)(4396001)(95666004)(99286002)(105586002)(106356001)(106116001)(92566001)(76482002)(31966008)(21056001)(50986999)(2656002)(87936001)(76576001)(33646002)(107886001)(107046002)(97736003)(54356999)(76176999)(85306004)(46102003)(80022003)(40100003)(2501002)(122556002)(15975445006)(2421001)(20776003)(101416001)(64706001)(1511001)(85852003)(3826002)(24736002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB312; H:BLUPR03MB309.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/udXok4s6b2rHev1OQ2ICJX9PpUQ Subject: Re: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference Call X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 17:30:40 -0000 Same here -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones Sent: Thursday, October 16, 2014 10:17 AM To: Hannes Tschofenig; oauth@ietf.org Subject: Re: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference = Call For what it's worth, I was on the call too - until I and Brian left to join= the telechat for the OAuth assertions drafts. -- Mike -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Thursday, October 16, 2014 9:55 AM To: oauth@ietf.org Subject: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference Call Participants: * Brian Campbell * John Bradley * Derek Atkins * Phil Hunt * William Kim * Josh Mandel * Hannes Tschofenig Notes: Justin distributed a draft writeup and explained the reasoning behind it. T= he intended purpose is to put the write-up (after enough review) on oauth.n= et. See attachments. Justin solicited feedback from the conference call par= ticipants and from the working group. One discussion item was specifically related to the concept of audience res= trictions, which comes in two flavours: (a) restriction of the access token= regarding the resource server and (b) restriction of the id token regardin= g the client. Obviously, it is necessary to have both of these audience res= trictions in place and to actually check them. The group then went into a discussion about the use of pseudonyms in authen= tication and the problems deployments ran into when they used pseudonyms to= gether with a wide range of attributes that identified users nevertheless. = Phil suggested to produce a write-up about this topic. Finally, the group started a discussion about potential actions for the OAu= th working groups. Two activities were mentioned, namely to produce an IETF= draft of the write-up Justin has prepared as a "formal" response to the pr= oblems with authentication using OAuth and, as a second topic, potential re= -chartering of the OAuth working group to work on some solutions in this ar= ea. Hannes suggested to postpone these discussions and to first finish the = write-up Justin had distributed. Ciao Hannes & Derek _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From nobody Thu Oct 16 12:13:55 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31DDD1A8828; Thu, 16 Oct 2014 12:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qStbLlI8Dgux; Thu, 16 Oct 2014 12:13:38 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id D1B101A8827; Thu, 16 Oct 2014 12:13:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9DCF7BEE5; Thu, 16 Oct 2014 20:13:36 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2MavQ-MiWMik; Thu, 16 Oct 2014 20:13:35 +0100 (IST) Received: from [10.87.48.12] (unknown [86.46.21.146]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1ACF2BE97; Thu, 16 Oct 2014 20:13:35 +0100 (IST) Message-ID: <544018DE.6030309@cs.tcd.ie> Date: Thu, 16 Oct 2014 20:13:34 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Brian Campbell References: <20141016112244.8382.80012.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/uxpxO5T8Au6LEQodWHLS00fM5a0 Cc: "oauth-chairs@tools.ietf.org" , draft-ietf-oauth-jwt-bearer@tools.ietf.org, oauth , The IESG Subject: Re: [OAUTH-WG] Stephen Farrell's No Objection on draft-ietf-oauth-jwt-bearer-10: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 19:13:47 -0000 Ah fair enough, forgot that. S. On 16/10/14 14:10, Brian Campbell wrote: > A JWT, by it's very definition, is a set of base64url pieces concatenated > together with dot "." characters (which is also URL safe). So no additional > encoding or serialization of the JWT is needed. > > On Thu, Oct 16, 2014 at 5:22 AM, Stephen Farrell > wrote: > >> Stephen Farrell has entered the following ballot position for >> draft-ietf-oauth-jwt-bearer-10: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> http://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> >> - 2.1, assertion parameter: How come this one does not talk >> about base64url whereas the saml one does? >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > From nobody Thu Oct 16 12:29:46 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8BFE1A8881 for ; Thu, 16 Oct 2014 12:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9SrkbkefV3gi for ; Thu, 16 Oct 2014 12:29:35 -0700 (PDT) Received: from na3sys009aog110.obsmtp.com (na3sys009aog110.obsmtp.com [74.125.149.203]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76DA81A887F for ; Thu, 16 Oct 2014 12:29:29 -0700 (PDT) Received: from mail-ig0-f177.google.com ([209.85.213.177]) (using TLSv1) by na3sys009aob110.postini.com ([74.125.148.12]) with SMTP ID DSNKVEAcljfAupLg26DzYj+ybVrF+kW/FrqR@postini.com; Thu, 16 Oct 2014 12:29:29 PDT Received: by mail-ig0-f177.google.com with SMTP id a13so248092igq.10 for ; Thu, 16 Oct 2014 12:29:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Iu62RvAtkvq/pXVAig1yowuRcs+rLTPoKNJGXu3z/is=; b=AIViS+TmCbX62MzYQubXLIXztM+20X+gplpj+ZY4bBqmMQUxMZjCt+X9HtbO9xrFsO dGxP7aXskaEv6N0yjqiGuwzpT2vFVYIUxGbZJLtrXuVIPNCLOWMgrPDNUDfIw5O/G2gl IXWI47pr6goH5r5y2x0X0TizCspCP3Oemz5t1ZdqxeMVw4tdQcxhyhYi1oUtJgPjq75c eaQsW2hkJqydTeTUsqzsHtteq4T0k2nB2GXFIAHpSm5OQ2755R0v7wPKUm6ysng8Ndfg IwkbUSUTIPftNVMmxoMI0HmxLSCYz72ziqcGNWJSybRcGyEFZjr40zeEryGX3bdqIBCP wTig== X-Gm-Message-State: ALoCoQmVfJFy0SWe/e4+taD06ofuJL0Grp2Okm2Gmww+wmpsb76TEnblHqblPy/icdRwe+MQDWFzJV8diow8stIQfCIFFZ4xHGoOwBF+tOmtAzj9ennRnrsJcwZS5RHBNX/TPLVsd4U8 X-Received: by 10.107.7.229 with SMTP id g98mr3933560ioi.58.1413487761084; Thu, 16 Oct 2014 12:29:21 -0700 (PDT) X-Received: by 10.107.7.229 with SMTP id g98mr3933536ioi.58.1413487760914; Thu, 16 Oct 2014 12:29:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.12.137 with HTTP; Thu, 16 Oct 2014 12:28:50 -0700 (PDT) In-Reply-To: <20141016112032.13008.86094.idtracker@ietfa.amsl.com> References: <20141016112032.13008.86094.idtracker@ietfa.amsl.com> From: Brian Campbell Date: Thu, 16 Oct 2014 13:28:50 -0600 Message-ID: To: Stephen Farrell , Peter Saint-Andre Content-Type: multipart/alternative; boundary=001a113f9b00e256ca05058f437b Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/AMxcOGFSs-25DFYkjDlQjX6CjIk Cc: "oauth-chairs@tools.ietf.org" , draft-ietf-oauth-saml2-bearer@tools.ietf.org, The IESG , oauth Subject: Re: [OAUTH-WG] Stephen Farrell's No Objection on draft-ietf-oauth-saml2-bearer-21: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 19:29:38 -0000 --001a113f9b00e256ca05058f437b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for your review and feedback, Stephen. Replies are inline below... On Thu, Oct 16, 2014 at 5:20 AM, Stephen Farrell wrote: > Stephen Farrell has entered the following ballot position for > draft-ietf-oauth-saml2-bearer-21: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > - intro para2: might be nice (no more) to add some refs to > other protocols that use SAML. > OK > - 2.2: What are "padding bits" in 4648? I don't recall such. > (But may be misremembering.) > FWIW, that exact wording was suggested to me by Peter Saint-Andre (cc'd) so, trusting in him, I just took the text without question. But I believe it means and is basically just restating what is said near the middle/end of =C2=A74 in 4648, "When fewer than 24 input bits are avai= lable in an input group, bits with value zero are added (on the right) to form an integral number of 6-bit groups." - https://tools.ietf.org/html/rfc4648#section-4 Are you saying Peter is wrong? ;) - section 3, list item 2: This doesn't quite say that the > token endpoint URL MUST (in the absence of another profile) be > in an Audience element. Why not? The text seems to me to allow > for the AS to map the token endpoint URL to any value in an > Audience element that the AS finds ok. I suspect that might be > unwise, but it at least needs to be clear. Is that the text > being ambiguous or me being paranoid/wrong? You are not wrong. But it's intentionally that way to allow for how this will actually be used and deployed (and currently is). It accommodates how SAML defines audience (SAML core 2.5.1.4 referenced in item 2 there) as well as providing the token endpoint URL as a means of identifying the AS as an audience for deployments that wouldn't otherwise have a SAML 2.0 entity id to use. This profile is just a small piece of a bigger picture and, as such, needs to fit into the larger picture. Oftentimes it will be deployed as a complement to existing SAML deployments where trust has already been established and keys and identifiers have already been exchanged, in which case the existing SAML 2.0 entity ID of the AS who is a SAML SP in that context should be used as the audience. But I couldn't presume that would always be the case so needed to provide some guidance for what to use as the audience in the absence of a larger SAML deployment. OAuth doesn't have any kind of discovery or metadata, only endpoints to identify an AS, and this draft isn't going to address that. So the token endpoint is really the only option. I understand the desire to have something neat and tidy here but it's just not feasible to do so and reconcile with the way this kind of software is actually deployed and used. Some stuff needs to be exchanged out-of-band for this to work. Entity/issuer/audience identifiers are part of that. This need is discussed in the Interoperability Considerations at https://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-21#section-5 > Same point seems > to apply elsewhere too: > =3D in item 3.A where it says "typically identifies" but > does not say how. > Could be an email, a username, a guid, a distinguished name, a certificate, a persistent pseudonymous id, a transient pseudonymous id, etc. Like all cross domain identity systems, part of the deployment is determining how identities will be conveyed. Nailing that down any more is way beyond the scope of this draft. It's also mentioned in the Interoperability Considerations. https://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-21#section-5 > =3D in item 5 "or an acceptable alias" > To give the AS some flexibility in what it accepts as identifying itself. > > - section 3, item 7: How might an AS know that "the Assertion > was issued with the intention that the client act autonomously > on behalf of the subject"? > > Item 7 is intended to provide a way to single that to the AS - and it's really about if the user directly authenticated or not. The issuer of the assertion will know (usually) if the user authenticated directly or if the assertion is being issued about the subject based on some other trust relationship with the client. The same section was discussed in Pete Resnick's review, near the end of http://www.ietf.org/mail-archive/web/oauth/current/msg13599.html with the suggestion of saying "directly authenticated" in the first sentence to be more clear about it. But I'm open to additional clarification, if you have a suggestion. --001a113f9b00e256ca05058f437b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for your review and feedback, Stephen.= =20 Replies are inline below...

On Thu, Oct 16, 2014 at 5:20 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
Stephen Farrell has entered the following = ballot position for
draft-ietf-oauth-saml2-bearer-21: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-crit= eria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-be= arer/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


- intro para2: might be nice (no more) to add some refs to
other protocols that use SAML.


OK <= br>

=C2=A0
- 2.2: What are "padding bits" in 4648? I don't recall such.<= br> (But may be misremembering.)


=C2=A0= FWIW, that exact wording was suggested to me by Peter Saint-Andre (cc'd= ) so, trusting in him, I just took the text without question.

=
But I believe it means and is basically just restating what is said ne= ar the middle/end of =C2=A74 in 4648, "When fewer than 24 input=C2=A0 = bits are available in an input group, bits with value zero are added (on th= e right) to form an integral number of 6-bit groups." - https://tools.ietf.org/html/rfc= 4648#section-4

Are you saying Peter is wrong? ;)
=


- section 3, list item 2: This doesn't quite say that the
token endpoint URL MUST (in the absence of another profile) be
in an Audience element. Why not? The text seems to me to allow
for the AS to map the token endpoint URL to any value in an
Audience element that the AS finds ok. I suspect that might be
unwise, but it at least needs to be clear. Is that the text
being ambiguous or me being paranoid/wrong?


=
You are not wrong. But it's intentionally that way to allow for ho= w this will actually be used and deployed (and currently is). It accommodat= es how SAML defines audience (SAML core 2.5.1.4 referenced in item 2 there)= as well as providing the token endpoint URL as a means of identifying the = AS as an audience for deployments that wouldn't otherwise have a SAML 2= .0 entity id to use.

This profile is just a s= mall piece of a bigger picture and, as such, needs to fit into the larger p= icture. Oftentimes it will be deployed as a complement to existing SAML dep= loyments where trust has already been established and keys and identifiers = have already been exchanged, in which case the existing SAML 2.0 entity ID = of the AS who is a SAML SP in that context should be used as the audience. = But I couldn't presume that would always be the case so needed to provi= de some guidance for what to use as the audience in the absence of a larger= SAML deployment. OAuth doesn't have any kind of discovery or metadata,= only endpoints to identify an AS, and this draft isn't going to addres= s that. So the token endpoint is really the only option.

= I understand the desire to have something neat and tidy here but it's j= ust not feasible to do so and reconcile with the way this kind of software = is actually deployed and used.

Some stuff needs to be ex= changed out-of-band for this to work. Entity/issuer/audience identifiers ar= e part of that. This need is discussed in the Interoperability Consideratio= ns at https://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-21#= section-5

=C2=A0
Same point seems
to apply elsewhere too:
=C2=A0 =C2=A0=3D in item 3.A where it says "typically identifies"= but
=C2=A0 =C2=A0does not say how.

Could be= an email, a username, a guid, a distinguished name, a certificate, a persi= stent pseudonymous id, a transient pseudonymous id, etc.

Like all cross domain identity systems, part of the deployment is determin= ing how identities will be conveyed. Nailing that down any more is way beyo= nd the scope of this draft. It's also mentioned in the Interoperability= Considerations. https://tools.ietf.org/html/draft-ietf-oauth-saml= 2-bearer-21#section-5
=C2=A0
=C2=A0 =C2=A0=3D in item 5 "or an acceptable alias"

To give the AS some flexibility in what it accepts a= s identifying itself.

=C2=A0

- section 3, item 7: How might an AS know that "the Assertion
was issued with the intention that the client act autonomously
on behalf of the subject"?


Item 7 is intended to provide a way to= single that to the AS - and it's really about if the user directly aut= henticated or not. The issuer of the assertion will know (usually) if the u= ser authenticated directly or if the assertion is being issued about the su= bject based on some other trust relationship with the client.

--001a113f9b00e256ca05058f437b-- From nobody Thu Oct 16 12:58:54 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8CD1A8909 for ; Thu, 16 Oct 2014 12:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mx-TKZqK2FXJ for ; Thu, 16 Oct 2014 12:58:50 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id D06A61A8904 for ; Thu, 16 Oct 2014 12:58:49 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 81EE0B2E7D8; Thu, 16 Oct 2014 15:58:49 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id 77301B2E7D2; Thu, 16 Oct 2014 15:58:49 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.195]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.03.0174.001; Thu, 16 Oct 2014 15:58:49 -0400 From: "Richer, Justin P." To: Hannes Tschofenig Thread-Topic: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference Call Thread-Index: AQHP6WH0YS2nwhanoUuAVD8y2Huse5wzZ3wA Date: Thu, 16 Oct 2014 19:58:49 +0000 Message-ID: <5AA1E738-7AC3-41AF-9E5B-5364447EA160@mitre.org> References: <543FF850.6070409@gmx.net> In-Reply-To: <543FF850.6070409@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.15.56] Content-Type: text/plain; charset="us-ascii" Content-ID: <84925F37A6E12947A2239E73283BD8CC@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/f-vJyYslzR3Z1aAWM1EqI53U-Gs Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference Call X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 19:58:51 -0000 Those interested in helping edit the text directly can follow along on this= GitHub fork: https://github.com/jricher/oauth.net/tree/authentication Once a reasonable number of eyes have seen that page, we'll get it publishe= d onto oauth.net. Aaron Parecki has offered to add a "Draft" banner to the = article page, inviting comments and edits via GitHub. -- Justin On Oct 16, 2014, at 12:54 PM, Hannes Tschofenig = wrote: > Participants: >=20 > * Brian Campbell > * John Bradley > * Derek Atkins > * Phil Hunt > * William Kim > * Josh Mandel > * Hannes Tschofenig >=20 >=20 > Notes: >=20 > Justin distributed a draft writeup and explained the reasoning behind > it. The intended purpose is to put the write-up (after enough review) on > oauth.net. See attachments. Justin solicited feedback from the > conference call participants and from the working group. >=20 > One discussion item was specifically related to the concept of audience > restrictions, which comes in two flavours: (a) restriction of the access > token regarding the resource server and (b) restriction of the id token > regarding the client. Obviously, it is necessary to have both of these > audience restrictions in place and to actually check them. >=20 > The group then went into a discussion about the use of pseudonyms in > authentication and the problems deployments ran into when they used > pseudonyms together with a wide range of attributes that identified > users nevertheless. Phil suggested to produce a write-up about this topic= . >=20 > Finally, the group started a discussion about potential actions for the > OAuth working groups. Two activities were mentioned, namely to produce > an IETF draft of the write-up Justin has prepared as a "formal" response > to the problems with authentication using OAuth and, as a second topic, > potential re-chartering of the OAuth working group to work on some > solutions in this area. Hannes suggested to postpone these discussions > and to first finish the write-up Justin had distributed. >=20 > Ciao > Hannes & Derek > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Thu Oct 16 13:07:06 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCD4D1A88CA for ; Thu, 16 Oct 2014 13:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mJrEhIGsqqA for ; Thu, 16 Oct 2014 13:06:57 -0700 (PDT) Received: from na3sys009aog132.obsmtp.com (na3sys009aog132.obsmtp.com [74.125.149.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBF9D1A8862 for ; Thu, 16 Oct 2014 13:06:56 -0700 (PDT) Received: from mail-ig0-f178.google.com ([209.85.213.178]) (using TLSv1) by na3sys009aob132.postini.com ([74.125.148.12]) with SMTP ID DSNKVEAlX+1TNRKMmRkP9GXvB26AZ6VkxXzc@postini.com; Thu, 16 Oct 2014 13:06:56 PDT Received: by mail-ig0-f178.google.com with SMTP id h3so294785igd.17 for ; Thu, 16 Oct 2014 13:06:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Us/I524thRm9Vh+LYikVttZi9Ruh8fO6rWP84l7sKGI=; b=Q7JuLs9am6QXyzWRfQQdr7vTDb9iuVzQsj4Eihn3IqQR+Ldo1CudDT3Qk0TsEzYRMo I7yzMfJNzxtnm9iY8N1LQKzT7bvdMnWCTpmDAxltnu+/YVAWU0OVROC9nYFWLnfDaeHI xyRXVm6BFseQBXgEDNC3oKRWlBlnx7VrfqP8DEA6qbAMAncV/8YQURVpVWF1odBXwyw1 ShO/IOADWLk3F9q24zi/mpEv6w+zbyXGYmv44hBrnvxYusmsdjB/vJoGcwxfUwitZwqG UZAiC7ystTQ4eEL/YcaoxGUNAdQielCtLS5SL7L+Ns5n4RrSixubGc5wBbdpMiv5uVgd PuXw== X-Gm-Message-State: ALoCoQk2be7WS4dilnYFGmpdMBpx3Ief1YMrmCMKVOp+z5HzMk+r3o/hd0VvHjlGrF+u1ALUKWjJiSeSzfcXOibzrtnk0C5ce5kCrgqE3+8lPpNEeJyxH88yz8kq74/k7l3bRdHcalB0 X-Received: by 10.42.86.142 with SMTP id u14mr4219871icl.77.1413490015357; Thu, 16 Oct 2014 13:06:55 -0700 (PDT) X-Received: by 10.42.86.142 with SMTP id u14mr4219853icl.77.1413490015201; Thu, 16 Oct 2014 13:06:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.12.137 with HTTP; Thu, 16 Oct 2014 13:06:24 -0700 (PDT) In-Reply-To: <20141016112213.10005.54238.idtracker@ietfa.amsl.com> References: <20141016112213.10005.54238.idtracker@ietfa.amsl.com> From: Brian Campbell Date: Thu, 16 Oct 2014 14:06:24 -0600 Message-ID: To: Stephen Farrell Content-Type: multipart/alternative; boundary=20cf301cbd404003e305058fca5e Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/mcpalMyvmkuAdwC6lsXB5ta3ONo Cc: "draft-ietf-oauth-assertions@tools.ietf.org" , "oauth-chairs@tools.ietf.org" , The IESG , oauth Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 20:06:59 -0000 --20cf301cbd404003e305058fca5e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for your review and feedback on this one too, Stephen. Replies are inline below... On Thu, Oct 16, 2014 at 5:22 AM, Stephen Farrell wrote: > Stephen Farrell has entered the following ballot position for > draft-ietf-oauth-assertions-17: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > > Putting one discuss here rather than one on each of the other > docs. We can fix that as appropriate after we chat. Where are > the MTI signature and mac algs for these specified? If those > can be tracked back via the SAML and jose docs that's fine, > but I'm not sure if they are. > > I believe they can be. JOSE Implementation Requirements for JWS are in the table in JWA =C2=A73.1 https://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-34#section-= 3.1 And there's =C2=A75 SAML and XML Signature Syntax and Processing http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > - general: What prevents/detects conflicts between the oauth > scope parameter and the saml or jwt equivalent? Are there > other bits of replicated data that could be the basis for a > vulnerability? > > (The comment below applies for both saml and jwt so > putting it here.) > Scope is not represented inside the assertion (JWT or SAML) so there's no potential for conflict. > > - The no replay protection issue was debated in the > WG wasn't it? (I think I recall it, not sure.) Seems like a > bad plan to me to not require at least implementation of > replay protection in the AS so that it can be turned on. Can > you point me at where that was discussed on the list? > > I described my recollection and justification of the optionality of one particular type of replay protection in a message yesterday: http://www.ietf.org/mail-archive/web/oauth/current/msg13567.html It's worth mentioning that there are different ideas of what replay is and what to protect against. The one particular type mentioned above is pretty narrow - checking to see if the same token is used again at the same relying party. There are other kinds of more sinister replay which are prevented by properly audience restricting the assertions. The audience restriction let's the issuer say specifically what relying party is allowed to consume the assertion, which ensures that the client can't use it somewhere where it wasn't intended and that the relying party that receives the assertion can't turn around and use it to access some other service. --20cf301cbd404003e305058fca5e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for your review and feedback on this o= ne too, Stephen.=20 Replies are inline below...

On Thu, Oct 16, 2014 at 5:22 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
Stephen Farrell has entered the following = ballot position for
draft-ietf-oauth-assertions-17: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-crit= eria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions= /



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------


Putting one discuss here rather than one on each of the other
docs. We can fix that as appropriate after we chat.=C2=A0 Where are
the MTI signature and mac algs for these specified? If those
can be tracked back via the SAML and jose docs that's fine,
but I'm not sure if they are.

=C2=A0

I believe they can be.
<= br>JOSE Implementation Requirements for JWS are in the table in JWA =C2=A73= .1

=C2=A0<= /div>
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


- general: What prevents/detects conflicts between the oauth
scope parameter and the saml or jwt equivalent?=C2=A0 Are there
other bits of replicated data that could be the basis for a
vulnerability?

(The comment below applies for both saml and jwt so
putting it here.)

Scope is not represen= ted inside the assertion (JWT or SAML) so there's no potential for conf= lict.
=C2=A0

- The no replay protection issue was debated in the
WG wasn't it? (I think I recall it, not sure.) Seems like a
bad plan to me to not require at least implementation of
replay protection in the AS so that it can be turned on. Can
you point me at where that was discussed on the list?


I described my recollection and justif= ication of the optionality of one particular type of replay protection in a= message yesterday: http://www.ietf.org/mail-archive/web/oauth/current/ms= g13567.html

It's worth mentioning that there are= different ideas of what replay is and what to protect against. The one par= ticular type mentioned above is pretty narrow - checking to see if the same= token is used again at the same relying party.

There are= other kinds of more sinister replay which are prevented by properly audien= ce restricting the assertions. The audience restriction let's the= issuer say specifically what=20 relying party is allowed to consume the assertion, which ensures that=20 the client can't use it somewhere where it wasn't intended and that= the=20 relying party that receives the assertion can't turn around and use it= =20 to access some other service.
--20cf301cbd404003e305058fca5e-- From nobody Thu Oct 16 13:44:55 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83EA31A89A2 for ; Thu, 16 Oct 2014 13:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4T7H6TUR4_gH for ; Thu, 16 Oct 2014 13:44:47 -0700 (PDT) Received: from na3sys009aog120.obsmtp.com (na3sys009aog120.obsmtp.com [74.125.149.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A66E41A897A for ; Thu, 16 Oct 2014 13:44:47 -0700 (PDT) Received: from mail-ig0-f172.google.com ([209.85.213.172]) (using TLSv1) by na3sys009aob120.postini.com ([74.125.148.12]) with SMTP ID DSNKVEAuP5m6mOrks3JWMuuWlF0n+bUUZ538@postini.com; Thu, 16 Oct 2014 13:44:47 PDT Received: by mail-ig0-f172.google.com with SMTP id r2so377189igi.11 for ; Thu, 16 Oct 2014 13:44:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=+E8tBIVaVFGi8HDMUIwcBOFKBUX78c9d30GKdZOAiwo=; b=AaUV8d3lsV27FavzV7AwUqNRkhkql6v4dFXR4qLbOOralwA7SwsbMl6Ft6UQUyKC7G Ion5d2sDRCERAEpEQ3Du1+3leiogV25uoOjg8r6g+P3fN1Ag39po8X89R30EWWbOA5Bh APpxdlR8f9iEgqeSn22ZUeaPpZGSU7RujLpzqVekGIpXYlfh+UDehB5a/zAzGxjMVOVd SpNS3kKBr7OEoWmVzZqLVVYMxdZrcXmWPwcWNIIW1ZkszG+4vCo2sy1oxcsL34xDh4Zx MEqH69rjuigSdZsqqs8Js3faOmBb3AGflq1QdV43lR0qVXvp4fJ3QnOn3g4eoRoCyljK HeVQ== X-Gm-Message-State: ALoCoQn6X0+bsphRHcIIgQtOhQelbKqUQ2N3nJy/giuRRjwC6ZAA2UHPlkFPD6yFaCb9eg/1Azf5re/q2qfgQccgqI2Zy4TM/m7+hEuIUOBVD4ohYkXb9OJbH5RzoXTvMUiQ8y5oY0eA X-Received: by 10.107.163.142 with SMTP id m136mr4382356ioe.32.1413492286921; Thu, 16 Oct 2014 13:44:46 -0700 (PDT) X-Received: by 10.107.163.142 with SMTP id m136mr4382337ioe.32.1413492286741; Thu, 16 Oct 2014 13:44:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.12.137 with HTTP; Thu, 16 Oct 2014 13:44:16 -0700 (PDT) In-Reply-To: <20141016040122.32277.7067.idtracker@ietfa.amsl.com> References: <20141016040122.32277.7067.idtracker@ietfa.amsl.com> From: Brian Campbell Date: Thu, 16 Oct 2014 14:44:16 -0600 Message-ID: To: Richard Barnes Content-Type: multipart/alternative; boundary=001a11403ff8a51e200505905114 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/CJfWEmAd8G-y8c2ZiNpcb6hxIYM Cc: "oauth-chairs@tools.ietf.org" , oauth , The IESG , draft-ietf-oauth-jwt-bearer@tools.ietf.org Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-jwt-bearer-10: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 20:44:50 -0000 --001a11403ff8a51e200505905114 Content-Type: text/plain; charset=UTF-8 Thanks for your review and feedback on this one too, Richard. Replies are inline below... On Wed, Oct 15, 2014 at 10:01 PM, Richard Barnes wrote: > Richard Barnes has entered the following ballot position for > draft-ietf-oauth-jwt-bearer-10: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > As with draft-ietf-oauth-assertions, the requirement for an "aud" claim > seems entirely unnecessary. Holding this DISCUSS point pending that > discussion > and its reflection in this document. > > "Assertions that do not identify the Authorization Server as an intended > audience MUST be rejected." -- What does it mean for an assertion to > "identify > the Authorization Server"? Does the specified need to match > the > entire URL of the relevant OAuth endpoint? Just the origin? Just the > domain? > Does the URL need to be canonicalized? > > No c14n, as it says, "... compare the audience values using the Simple String Comparison method defined in Section 6.2.1 of RFC 3986." Basically the AS is at liberty to determine how it identifies itself. Some guidance on using the token endpoint is provided but it's ultimately up to the AS (or the larger deployment in which the AS exists). The acceptable value is one of a few bits of information that must be exchanged for this profile, which is discussed in the Interoperability Considerations https://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-10#section-5 Some more explanation/discussion of it is in the middle(ish) of this reply to a similar comment from Stephen Farrell http://www.ietf.org/mail-archive/web/oauth/current/msg13605.html > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > "keyed message digest" -> "MAC" > Yep. > > Both this and the SAML document could save a lot of bits by just being > subsections of the -assertions document. > The structure and relationship of the documents was decided on by the WG nearly three years ago. There is some duplication but it's believed to be more approachable this way - particularly for those implementing just one assertion type. --001a11403ff8a51e200505905114 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for your review and feedback on this o= ne too, Richard.=20 Replies are inline below...

On Wed, Oct 15, 2014 at 10:01 PM, Richard Barnes <rlb@ipv.= sx> wrote:
Richard Barnes has entered the following ballot position for
draft-ietf-oauth-jwt-bearer-10: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-crit= eria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer= /



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

As with draft-ietf-oauth-assertions, the requirement for an "aud"= claim
seems entirely unnecessary.=C2=A0 Holding this DISCUSS point pending that discussion
and its reflection in this document.

"Assertions that do not identify the Authorization Server as an intend= ed
audience MUST be rejected." -- What does it mean for an assertion to "identify
the Authorization Server"?=C2=A0 Does the specified <Audience> n= eed to match
the
entire URL of the relevant OAuth endpoint?=C2=A0 Just the origin?=C2=A0 Jus= t the
domain?
Does the URL need to be canonicalized?



No c14n, as it says, "...=C2= =A0 compare the audience values using the Simple String Comparison method d= efined in Section 6.2.1 of RFC 3986."

Basically the= AS is at liberty to determine how it identifies itself. Some guidance on u= sing the token endpoint is provided but it's ultimately up to the AS (o= r the larger deployment in which the AS exists). The acceptable value is on= e of a few bits of information that must be exchanged for this profile, whi= ch is discussed in the Interoperability Considerations https://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-10#section-5

Some more explanation/discussion of it is in the middle= (ish) of this reply to a similar comment from Stephen Farrell http://www.= ietf.org/mail-archive/web/oauth/current/msg13605.html



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

"keyed message digest" -> "MAC"

Yep.
=C2=A0

Both this and the SAML document could save a lot of bits by just being
subsections of the -assertions document.

The structure and relationship of the documents was decided on by the WG = nearly three years ago. There is some duplication but it's believed to = be more approachable this way - particularly for those implementing just on= e assertion type.
--001a11403ff8a51e200505905114-- From nobody Thu Oct 16 13:54:30 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECD0F1A8A4D; Thu, 16 Oct 2014 13:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQiymHq0YX0C; Thu, 16 Oct 2014 13:54:24 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id B87D51A89B0; Thu, 16 Oct 2014 13:54:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 29027BEA4; Thu, 16 Oct 2014 21:54:23 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rd1P-RkT2plt; Thu, 16 Oct 2014 21:54:21 +0100 (IST) Received: from [10.87.48.12] (unknown [86.46.21.146]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C5F24BEB6; Thu, 16 Oct 2014 21:54:20 +0100 (IST) Message-ID: <5440307C.6070600@cs.tcd.ie> Date: Thu, 16 Oct 2014 21:54:20 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Brian Campbell , Peter Saint-Andre References: <20141016112032.13008.86094.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/F3aX5LrCRbFXO--qZ2l2A4TjYIw Cc: "oauth-chairs@tools.ietf.org" , draft-ietf-oauth-saml2-bearer@tools.ietf.org, The IESG , oauth Subject: Re: [OAUTH-WG] Stephen Farrell's No Objection on draft-ietf-oauth-saml2-bearer-21: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 20:54:27 -0000 Hiya, Mostly fine just a couple of notes. On 16/10/14 20:28, Brian Campbell wrote: > Thanks for your review and feedback, Stephen. Replies are inline below... > > On Thu, Oct 16, 2014 at 5:20 AM, Stephen Farrell > wrote: > >> Stephen Farrell has entered the following ballot position for >> draft-ietf-oauth-saml2-bearer-21: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> >> - intro para2: might be nice (no more) to add some refs to >> other protocols that use SAML. >> > > > OK > > > >> - 2.2: What are "padding bits" in 4648? I don't recall such. >> (But may be misremembering.) >> > > > FWIW, that exact wording was suggested to me by Peter Saint-Andre (cc'd) > so, trusting in him, I just took the text without question. > > But I believe it means and is basically just restating what is said near > the middle/end of §4 in 4648, "When fewer than 24 input bits are available > in an input group, bits with value zero are added (on the right) to form an > integral number of 6-bit groups." - > https://tools.ietf.org/html/rfc4648#section-4 > > Are you saying Peter is wrong? ;) Heh. > > > - section 3, list item 2: This doesn't quite say that the >> token endpoint URL MUST (in the absence of another profile) be >> in an Audience element. Why not? The text seems to me to allow >> for the AS to map the token endpoint URL to any value in an >> Audience element that the AS finds ok. I suspect that might be >> unwise, but it at least needs to be clear. Is that the text >> being ambiguous or me being paranoid/wrong? > > > > You are not wrong. But it's intentionally that way to allow for how this > will actually be used and deployed (and currently is). It accommodates how > SAML defines audience (SAML core 2.5.1.4 referenced in item 2 there) as > well as providing the token endpoint URL as a means of identifying the AS > as an audience for deployments that wouldn't otherwise have a SAML 2.0 > entity id to use. > > This profile is just a small piece of a bigger picture and, as such, needs > to fit into the larger picture. Oftentimes it will be deployed as a > complement to existing SAML deployments where trust has already been > established and keys and identifiers have already been exchanged, in which > case the existing SAML 2.0 entity ID of the AS who is a SAML SP in that > context should be used as the audience. But I couldn't presume that would > always be the case so needed to provide some guidance for what to use as > the audience in the absence of a larger SAML deployment. OAuth doesn't have > any kind of discovery or metadata, only endpoints to identify an AS, and > this draft isn't going to address that. So the token endpoint is really the > only option. > > I understand the desire to have something neat and tidy here but it's just > not feasible to do so and reconcile with the way this kind of software is > actually deployed and used. > > Some stuff needs to be exchanged out-of-band for this to work. > Entity/issuer/audience identifiers are part of that. This need is discussed > in the Interoperability Considerations at > https://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-21#section-5 So I think it'd be good to explicitly call out that these mappings are basically required and that they can be fraught (e.g. if someone uses wildcards badly, which they do). Cheers, S. > > > >> Same point seems >> to apply elsewhere too: >> = in item 3.A where it says "typically identifies" but >> does not say how. >> > > Could be an email, a username, a guid, a distinguished name, a certificate, > a persistent pseudonymous id, a transient pseudonymous id, etc. > > Like all cross domain identity systems, part of the deployment is > determining how identities will be conveyed. Nailing that down any more is > way beyond the scope of this draft. It's also mentioned in the > Interoperability Considerations. > https://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-21#section-5 > > >> = in item 5 "or an acceptable alias" >> > > To give the AS some flexibility in what it accepts as identifying itself. > > > >> >> - section 3, item 7: How might an AS know that "the Assertion >> was issued with the intention that the client act autonomously >> on behalf of the subject"? >> >> > Item 7 is intended to provide a way to single that to the AS - and it's > really about if the user directly authenticated or not. The issuer of the > assertion will know (usually) if the user authenticated directly or if the > assertion is being issued about the subject based on some other trust > relationship with the client. > > The same section was discussed in Pete Resnick's review, near the end of > http://www.ietf.org/mail-archive/web/oauth/current/msg13599.html with the > suggestion of saying "directly authenticated" in the first sentence to be > more clear about it. But I'm open to additional clarification, if you have > a suggestion. > From nobody Thu Oct 16 14:01:04 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60A351A8A65; Thu, 16 Oct 2014 14:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9W-LNcoG2aNx; Thu, 16 Oct 2014 14:00:59 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 420AF1A8A45; Thu, 16 Oct 2014 14:00:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9C0B0BEEC; Thu, 16 Oct 2014 22:00:58 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3A8UvW2LhtP; Thu, 16 Oct 2014 22:00:57 +0100 (IST) Received: from [10.87.48.12] (unknown [86.46.21.146]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C8DC4BEEB; Thu, 16 Oct 2014 22:00:56 +0100 (IST) Message-ID: <54403208.6040108@cs.tcd.ie> Date: Thu, 16 Oct 2014 22:00:56 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Brian Campbell References: <20141016112213.10005.54238.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/nofcZ4A8zSM6ANUNiOlznXHXM3Y Cc: "draft-ietf-oauth-assertions@tools.ietf.org" , "oauth-chairs@tools.ietf.org" , The IESG , oauth Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 21:01:02 -0000 Hiya, On 16/10/14 21:06, Brian Campbell wrote: > Thanks for your review and feedback on this one too, Stephen. Replies are > inline below... > > On Thu, Oct 16, 2014 at 5:22 AM, Stephen Farrell > wrote: > >> Stephen Farrell has entered the following ballot position for >> draft-ietf-oauth-assertions-17: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> >> Putting one discuss here rather than one on each of the other >> docs. We can fix that as appropriate after we chat. Where are >> the MTI signature and mac algs for these specified? If those >> can be tracked back via the SAML and jose docs that's fine, >> but I'm not sure if they are. >> >> > > I believe they can be. > > JOSE Implementation Requirements for JWS are in the table in JWA §3.1 > https://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-34#section-3.1 > > And there's §5 SAML and XML Signature Syntax and Processing > http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf Hmm. So the SAML one only seems to have RSA-SHA1 as the MTI and the JOSE one has only H256 as required. Doesn't that seem like one is unacceptably old and the other is not great for this purpose? My suggestion would be to add rsa-sha256 as MTI for these, as an addition to whatever JOSE and SAML make MTI. But I'd be happy to clear if you made any modern signature alg MTI. Cheers, S. PS: Stuff below is fine. > > > > >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> >> - general: What prevents/detects conflicts between the oauth >> scope parameter and the saml or jwt equivalent? Are there >> other bits of replicated data that could be the basis for a >> vulnerability? >> >> (The comment below applies for both saml and jwt so >> putting it here.) >> > > Scope is not represented inside the assertion (JWT or SAML) so there's no > potential for conflict. > > >> >> - The no replay protection issue was debated in the >> WG wasn't it? (I think I recall it, not sure.) Seems like a >> bad plan to me to not require at least implementation of >> replay protection in the AS so that it can be turned on. Can >> you point me at where that was discussed on the list? >> >> > I described my recollection and justification of the optionality of one > particular type of replay protection in a message yesterday: > http://www.ietf.org/mail-archive/web/oauth/current/msg13567.html > > It's worth mentioning that there are different ideas of what replay is and > what to protect against. The one particular type mentioned above is pretty > narrow - checking to see if the same token is used again at the same > relying party. > > There are other kinds of more sinister replay which are prevented by > properly audience restricting the assertions. The audience restriction > let's the issuer say specifically what relying party is allowed to consume > the assertion, which ensures that the client can't use it somewhere where > it wasn't intended and that the relying party that receives the assertion > can't turn around and use it to access some other service. > From nobody Thu Oct 16 14:01:34 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4EC91A8A7B for ; Thu, 16 Oct 2014 14:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCNEvCSvcez2 for ; Thu, 16 Oct 2014 14:01:20 -0700 (PDT) Received: from na3sys009aog136.obsmtp.com (na3sys009aog136.obsmtp.com [74.125.149.85]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A3DB1A8A45 for ; Thu, 16 Oct 2014 14:01:20 -0700 (PDT) Received: from mail-ie0-f175.google.com ([209.85.223.175]) (using TLSv1) by na3sys009aob136.postini.com ([74.125.148.12]) with SMTP ID DSNKVEAyH3QLV6+eiGL3TQHhovWQB+LB/gXI@postini.com; Thu, 16 Oct 2014 14:01:20 PDT Received: by mail-ie0-f175.google.com with SMTP id x19so4344146ier.34 for ; Thu, 16 Oct 2014 14:01:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=0ZFlKQKe9wjNtRF9UmRZD0Dj8BNJ+7VY/mZWryXSoCY=; b=VDnYlu3ZsGC5PhkA6+sNQ8revaAyIS8NVPcxGRcm/X3myJqwT0t3zW0tjNtYEayB71 jqUwAULo15Vn8fijTE5P2A4t6Sh4rUjjSW3MxX/fvXysrngnjARWu7asajAuoU2HjGgz 15RtJcO8ajI4Pjnes9l2Dazf1UJawT/LbFyPtwK/sB1ra70AlNyaqcdix2saSWNsyg85 c030fSj8Yugrms6PLpcGzjK9/4ni0OL1+nmfwjiUpJ3yJWZRvBmqJpQEcHoU15RMF9wb h8BRAFsK+PlZFmvdGDAflMcEejksV7NX3woVoqNJVvBPvXVjp7CHB0NvTWLBA/L/FeE9 lkKw== X-Gm-Message-State: ALoCoQnpSv+OMFW3iCMQe9EgknTvW8lmrD54jlkrfZ8bhcTyXp0cuTvb0t8uL9k5o1VOuHTiqut3YZ1woUg2GWBufXLEe+vwbZD9j3RR3I5R7/yrwmB7x1pGwabqApEAytKhcWT2bQT1 X-Received: by 10.107.163.142 with SMTP id m136mr4464764ioe.32.1413493279527; Thu, 16 Oct 2014 14:01:19 -0700 (PDT) X-Received: by 10.107.163.142 with SMTP id m136mr4464751ioe.32.1413493279404; Thu, 16 Oct 2014 14:01:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.12.137 with HTTP; Thu, 16 Oct 2014 14:00:49 -0700 (PDT) In-Reply-To: <20141016035640.25108.27277.idtracker@ietfa.amsl.com> References: <20141016035640.25108.27277.idtracker@ietfa.amsl.com> From: Brian Campbell Date: Thu, 16 Oct 2014 15:00:49 -0600 Message-ID: To: Richard Barnes Content-Type: multipart/alternative; boundary=001a11403ff8cfc99a0505908c4a Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/b7nKgscLdxmbe9BJ17e4PSXnzYA Cc: "oauth-chairs@tools.ietf.org" , draft-ietf-oauth-saml2-bearer@tools.ietf.org, The IESG , oauth Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-saml2-bearer-21: (with DISCUSS) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 21:01:23 -0000 --001a11403ff8cfc99a0505908c4a Content-Type: text/plain; charset=UTF-8 Basically the same response to the basically same question as from http://www.ietf.org/mail-archive/web/oauth/current/msg13608.html On Wed, Oct 15, 2014 at 9:56 PM, Richard Barnes wrote: > Richard Barnes has entered the following ballot position for > draft-ietf-oauth-saml2-bearer-21: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > As with draft-ietf-oauth-assertions, the requirement for an > element seems entirely unnecessary. Holding this DISCUSS point pending > that discussion and its reflection in this document. > > "Assertions that do not identify the Authorization Server as an intended > audience MUST be rejected." -- What does it mean for an assertion to > "identify the Authorization Server"? Does the specified need > to match the entire URL of the relevant OAuth endpoint? Just the origin? > Just the domain? Does the URL need to be canonicalized? > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001a11403ff8cfc99a0505908c4a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Basically the same response to the basically same question= as from http://www.ietf.org/mail-archive/web/oauth/current/msg13608.html=

On = Wed, Oct 15, 2014 at 9:56 PM, Richard Barnes <rlb@ipv.sx> wrote:
Richard Barnes has entered the following b= allot position for
draft-ietf-oauth-saml2-bearer-21: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-crit= eria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-be= arer/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

As with draft-ietf-oauth-assertions, the requirement for an <Audience>= ;
element seems entirely unnecessary.=C2=A0 Holding this DISCUSS point pendin= g
that discussion and its reflection in this document.

"Assertions that do not identify the Authorization Server as an intend= ed
audience MUST be rejected." -- What does it mean for an assertion to "identify the Authorization Server"?=C2=A0 Does the specified <= ;Audience> need
to match the entire URL of the relevant OAuth endpoint?=C2=A0 Just the orig= in?
=C2=A0Just the domain?=C2=A0 Does the URL need to be canonicalized?




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

--001a11403ff8cfc99a0505908c4a-- From nobody Thu Oct 16 14:21:35 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D27AC1A8AA3 for ; Thu, 16 Oct 2014 14:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8JFne88tVHC for ; Thu, 16 Oct 2014 14:21:26 -0700 (PDT) Received: from na3sys009aog138.obsmtp.com (na3sys009aog138.obsmtp.com [74.125.149.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F1611A8AAC for ; Thu, 16 Oct 2014 14:21:13 -0700 (PDT) Received: from mail-ie0-f177.google.com ([209.85.223.177]) (using TLSv1) by na3sys009aob138.postini.com ([74.125.148.12]) with SMTP ID DSNKVEA2yfOdA3XJDzxF6IWLRhg+SDJgrbSM@postini.com; Thu, 16 Oct 2014 14:21:13 PDT Received: by mail-ie0-f177.google.com with SMTP id rd18so4317751iec.36 for ; Thu, 16 Oct 2014 14:21:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=YOjIoQMvFm6KX9w9va/zUYGBcH19kO8lnoheHuiZRPs=; b=VOPfDQvZxf9AfXh9kJNpjkPXOztpmjdvr9B7Yu5A9osJ2VIeDNJA4dfUhtz+1eHbDI X6/Cj/ovmVpBh//pX9jIRKhXzdWgZAWkWiVxMVyvzLBdQMcSHQDCXOMe8rngEgtwaaAh 8wtlPSP79nqvPDRLZwffZi4koo8Y/hm3nRHeoGuZQJLnkRmuk4U3m3UOVB4XsbtRiZ/s 6FQgex/4dSw32OYpMGV5uZcT6Y9Q8xSrsvY6xDLP0cidQV61aXHz6buy4wWvXyYWB+8C uLNcRbxpt1zqcwNqw6oQDGGvXSnTgUm23Tozm4+ywy54Pisze+qYfPp8VEiLj+UDTFA6 ucoQ== X-Gm-Message-State: ALoCoQkWTBqhq6X7Oc9MA/XHFc5bvqidErpON3RxZQG0+Ah3ATShCNmxFUKzDohOlc3/uyYyrtUf0V5r5kRnWBTAO2K8zBttny/d7N+3Q8Y3ExQC1CHadmtrq1pYJXlAkiK9dU/tWTu9 X-Received: by 10.107.3.133 with SMTP id e5mr4595993ioi.45.1413494472940; Thu, 16 Oct 2014 14:21:12 -0700 (PDT) X-Received: by 10.107.3.133 with SMTP id e5mr4595988ioi.45.1413494472843; Thu, 16 Oct 2014 14:21:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.12.137 with HTTP; Thu, 16 Oct 2014 14:20:42 -0700 (PDT) In-Reply-To: <5440307C.6070600@cs.tcd.ie> References: <20141016112032.13008.86094.idtracker@ietfa.amsl.com> <5440307C.6070600@cs.tcd.ie> From: Brian Campbell Date: Thu, 16 Oct 2014 15:20:42 -0600 Message-ID: To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a113ed420f26934050590d303 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/zxqtYCepF2-VDxlI2AIrQ4I7WO8 Cc: "oauth-chairs@tools.ietf.org" , draft-ietf-oauth-saml2-bearer@tools.ietf.org, The IESG , Peter Saint-Andre , oauth Subject: Re: [OAUTH-WG] Stephen Farrell's No Objection on draft-ietf-oauth-saml2-bearer-21: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 21:21:28 -0000 --001a113ed420f26934050590d303 Content-Type: text/plain; charset=UTF-8 On Thu, Oct 16, 2014 at 2:54 PM, Stephen Farrell wrote: > > > Some stuff needs to be exchanged out-of-band for this to work. > > Entity/issuer/audience identifiers are part of that. This need is > discussed > > in the Interoperability Considerations at > > https://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-21#section-5 > > So I think it'd be good to explicitly call out that these > mappings are basically required and that they can be fraught > (e.g. if someone uses wildcards badly, which they do). > OK, I will add something to that effect in the next revisions. --001a113ed420f26934050590d303 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Thu, Oct 16, 2014 at 2:54 PM, Stephen Farrell <stephen.farrell@= cs.tcd.ie> wrote:

> Some stuff needs to be exchanged out-of-band for this to work.
> Entity/issuer/audience identifiers are part of that. This need is disc= ussed
> in the Interoperability Considerations at
> https://tools.ietf.org/html/draft-ietf-oauth= -saml2-bearer-21#section-5

So I think it'd be good to explicitly call out that these mappings are basically required and that they can be fraught
(e.g. if someone uses wildcards badly, which they do).

OK, I will add something to that effect in the next revisio= ns.
=C2=A0
--001a113ed420f26934050590d303-- From nobody Thu Oct 16 14:23:19 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F2E51A88D4 for ; Thu, 16 Oct 2014 14:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1B3h44A7fZDs for ; Thu, 16 Oct 2014 14:23:15 -0700 (PDT) Received: from na3sys009aog127.obsmtp.com (na3sys009aog127.obsmtp.com [74.125.149.107]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 366B01A8029 for ; Thu, 16 Oct 2014 14:23:15 -0700 (PDT) Received: from mail-wg0-f44.google.com ([74.125.82.44]) (using TLSv1) by na3sys009aob127.postini.com ([74.125.148.12]) with SMTP ID DSNKVEA3Qr+AvacPq+4i7OzG60CU/GHeG7lx@postini.com; Thu, 16 Oct 2014 14:23:15 PDT Received: by mail-wg0-f44.google.com with SMTP id y10so4660408wgg.15 for ; Thu, 16 Oct 2014 14:23:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=qMiK3AIjKqxRXWUiewME6mLiNOG74YYGIL22JxUP00o=; b=ONG7fkXs2l/AZXaasOmqzrnNCu/shWfXJtJ1514fyGm/WllXPQIjBWQB24bpyoX+yb X1qV5X1qFPHYpFCdWMmK6LHwlSe1QRrTs+g1ydn/Ih325HIszLu+g8ZySl0Wh27V3/Eg YRzgoZB3yu+IUAH6N4GIbFZh6lUR+oC9TRA0xDSKkviKqAoBO5KmYDBi2rrAps0XgR78 dw17kLyjEnvSlR44UHzh4pzf2ARsWgyLV12BuExZcHqBFME5vuRfYhXYxyvd1p+OuPXY UYVmDINsi96PoQd4/Xdl/iIaszxjtwDDvWnQjsHxGLMfS1e8v4hK5L0afoKZdn64Yqa3 Yopg== X-Gm-Message-State: ALoCoQmuEtx7ROAl/6Ss/9jgw4gug4yhoeADPKIcaL913Hbo8q67CR1x17TWNbxXZtdiIhNRqtXqw73SA8DDtWXhsEos3H0ff7b+Q0goiCkPMlYp5ugSnifpKpIN/CwOQGA/bsrqfsQ9 X-Received: by 10.180.8.233 with SMTP id u9mr9128768wia.19.1413494593670; Thu, 16 Oct 2014 14:23:13 -0700 (PDT) X-Received: by 10.180.8.233 with SMTP id u9mr9128760wia.19.1413494593577; Thu, 16 Oct 2014 14:23:13 -0700 (PDT) Received: from [192.168.99.228] (fw-obester.inth.hu. [93.189.112.82]) by mx.google.com with ESMTPSA id td9sm3335951wic.15.2014.10.16.14.23.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 16 Oct 2014 14:23:12 -0700 (PDT) Message-ID: <5440373F.9090601@pingidentity.com> Date: Thu, 16 Oct 2014 23:23:11 +0200 From: Hans Zandbelt User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Richer, Justin P." References: <543FF850.6070409@gmx.net> <543FFB13.2060903@pingidentity.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Ip_IU83eGTu_Jj0Z5a0Dg_owlbY Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference Call X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 21:23:17 -0000 a deployment-related question that I have around this topic: it seems that authentication using OAuth 2.0 is possible today for confidential clients using the code flow, with a registered redirect_uri, not consuming/storing/using refresh_tokens, and assuming that there's an API that returns user identity info in JSON format and the claim that uniquely identifies the user is known by the client. The usage/presence of the short-lived code in this scenario/flow guarantees that the user has just authenticated, and the audience issue is covered by the fact that the code (thus the access_token in the token endpoint response) are bound to the confidential client, all as per standard OAuth 2.0 semantics. 2 questions about that: - is this right or am I overlooking some security/semantics issues here - if right, would it make sense to acknowledge that or is that muddying the waters even more (the current text does seem to only implicitly acknowledge this) There may be value in acknowledging this because the majority of OAuth 2.0 OPs exposing a userinfo-like API would adhere to a REST GET+JSON response anyhow [1] thus achieving login semantics with plain OAuth 2.0 and a bit of common practice wrt. the user info API. Thanks for the excellent write-up! Hans. PS: I've been asked this concrete question about Spotify's OAuth 2.0 support and in fact I'm able to configure Spotify as an IDP to my OIDC client with a minor workaround to abstain from expecting an id_token in the token endpoint response, but calling the Spotify specific user info endpoint like it was a standards-compliant OpenID Connect endpoint. (the client has a per-OP configurable unique user id claim name anyhow). On 10/16/14, 7:27 PM, Richer, Justin P. wrote: > Ah yes, good catch! If only someone would put up a webpage describing the difference between authorization and authentication and why people need to stop confusing the two. > > Oh wait... > > > On Oct 16, 2014, at 1:06 PM, Hans Zandbelt wrote: > >> About the write-up: at the end of the metaphor section it says: >> "These recipes each add a number of items, such as a common profile API, to OAuth to create an authorization protocol." >> >> whereas I believe that should read "to create an authentication protocol" >> >> Hans. >> >> On 10/16/14, 6:54 PM, Hannes Tschofenig wrote: >>> Participants: >>> >>> * Brian Campbell >>> * John Bradley >>> * Derek Atkins >>> * Phil Hunt >>> * William Kim >>> * Josh Mandel >>> * Hannes Tschofenig >>> >>> >>> Notes: >>> >>> Justin distributed a draft writeup and explained the reasoning behind >>> it. The intended purpose is to put the write-up (after enough review) on >>> oauth.net. See attachments. Justin solicited feedback from the >>> conference call participants and from the working group. >>> >>> One discussion item was specifically related to the concept of audience >>> restrictions, which comes in two flavours: (a) restriction of the access >>> token regarding the resource server and (b) restriction of the id token >>> regarding the client. Obviously, it is necessary to have both of these >>> audience restrictions in place and to actually check them. >>> >>> The group then went into a discussion about the use of pseudonyms in >>> authentication and the problems deployments ran into when they used >>> pseudonyms together with a wide range of attributes that identified >>> users nevertheless. Phil suggested to produce a write-up about this topic. >>> >>> Finally, the group started a discussion about potential actions for the >>> OAuth working groups. Two activities were mentioned, namely to produce >>> an IETF draft of the write-up Justin has prepared as a "formal" response >>> to the problems with authentication using OAuth and, as a second topic, >>> potential re-chartering of the OAuth working group to work on some >>> solutions in this area. Hannes suggested to postpone these discussions >>> and to first finish the write-up Justin had distributed. >>> >>> Ciao >>> Hannes & Derek >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> >> -- >> Hans Zandbelt | Sr. Technical Architect >> hzandbelt@pingidentity.com | Ping Identity >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > -- Hans Zandbelt | Sr. Technical Architect hzandbelt@pingidentity.com | Ping Identity From nobody Thu Oct 16 14:40:29 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 218E51A8AB9 for ; Thu, 16 Oct 2014 14:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qDqihs6TwogG for ; Thu, 16 Oct 2014 14:40:27 -0700 (PDT) Received: from na3sys009aog109.obsmtp.com (na3sys009aog109.obsmtp.com [74.125.149.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 636901A8AB4 for ; Thu, 16 Oct 2014 14:40:27 -0700 (PDT) Received: from mail-ig0-f181.google.com ([209.85.213.181]) (using TLSv1) by na3sys009aob109.postini.com ([74.125.148.12]) with SMTP ID DSNKVEA7S1lvibAvYgG2jLgife4rrV6J62Vm@postini.com; Thu, 16 Oct 2014 14:40:27 PDT Received: by mail-ig0-f181.google.com with SMTP id r10so478480igi.2 for ; Thu, 16 Oct 2014 14:40:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=E4GJyKpYFruQaGPhtLevrJwfKn9MwPvK1IWgu09X1Do=; b=kj2u7/5dCM7IqAKzPD+4GPfjwbtVpA6ODnCPIsBNBYTbAAY/t84XUHAUbNbAtsino7 Fpwo9IZiBJbhyO4d1kQrw+SU48YPZZGE/08HXowJSNnaraQ8fipP11TGzgPNSy/jk6hJ Zi+FTeINtzLdUtBWnpBctxAtgbWl/d5e8rwRZEgxmXoZQ3R2+N4GWeV0zhCO5lr/tJzJ G08WR1RFG29BBBWZ8bC8i18JpnowJCZhJSnkZp6uaqZrEFgtJ0kBNQ5oLASn7o/1rvHj aMW7I6CW5rpy30itKADnoeAOYnkoZ4Q62qxAwLtSUAxJbijLS15Y7OwML45y1JpB4iQW B7KA== X-Gm-Message-State: ALoCoQlCCN4ihsAI3H0YWvxCwmtT3wVLgrLNY/MhByvF2h6ksqspJ6PxKn8aezp27qnFdpm/wM/vnJ+QviVTl3XtzVDaJo4pq3VMnGRcFeQrFoO/asJF+wAtF4fWsm6ASJm6imhMFpxS X-Received: by 10.107.159.18 with SMTP id i18mr4475844ioe.33.1413495626803; Thu, 16 Oct 2014 14:40:26 -0700 (PDT) X-Received: by 10.107.159.18 with SMTP id i18mr4475832ioe.33.1413495626696; Thu, 16 Oct 2014 14:40:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.12.137 with HTTP; Thu, 16 Oct 2014 14:39:56 -0700 (PDT) In-Reply-To: <54403208.6040108@cs.tcd.ie> References: <20141016112213.10005.54238.idtracker@ietfa.amsl.com> <54403208.6040108@cs.tcd.ie> From: Brian Campbell Date: Thu, 16 Oct 2014 15:39:56 -0600 Message-ID: To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a1140f94eb8a98d05059118e7 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/BAfiPe_gUIQQe0pN5lx6ZqJSHQk Cc: "draft-ietf-oauth-assertions@tools.ietf.org" , "oauth-chairs@tools.ietf.org" , The IESG , oauth Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 21:40:29 -0000 --001a1140f94eb8a98d05059118e7 Content-Type: text/plain; charset=UTF-8 Hiya in return and inline below... On Thu, Oct 16, 2014 at 3:00 PM, Stephen Farrell wrote: > > Hmm. So the SAML one only seems to have RSA-SHA1 as the MTI and the > JOSE one has only H256 as required. > > Doesn't that seem like one is unacceptably old and the other > is not great for this purpose? > Admittedly, I was a little worried you'd say that :) > > My suggestion would be to add rsa-sha256 as MTI for these, as an > addition to whatever JOSE and SAML make MTI. But I'd be happy to > clear if you made any modern signature alg MTI. > > Honestly, in my view, an MIT on these doesn't make a whole lot of sense as I think what's actually implemented/supported will be dictated by the larger deployments of SAML/SAMLP or JWT/JOSE/OpenID Connect. My feeling is that an MIT in these specs would likely be ignored and/or not influence implementers/deployers. So my preference would be to leave MTI out of these. But if you're not swayed by that line of thinking, and I'm guessing you're not, rsa-sha256 is probably the most appropriate choice. Could you give some guidance and/or point to examples of where and how to say that appropriately in the documents? Thanks! > Cheers, > S. > > PS: Stuff below is fine. > > Great, thank you. --001a1140f94eb8a98d05059118e7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hiya in return and inline below...

On Thu, Oct 16, 2014 at 3:0= 0 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wr= ote:

Hmm. So the SAML one only seems to have RSA-SHA1 as the MTI and the
JOSE one has only H256 as required.

Doesn't that seem like one is unacceptably old and the other
is not great for this purpose?

Admitted= ly, I was a little worried you'd say that :)
=C2=A0
=

My suggestion would be to add rsa-sha256 as MTI for these, as an
addition to whatever JOSE and SAML make MTI. But I'd be happy to
clear if you made any modern signature alg MTI.


Honestly, in my view, an MIT on these = doesn't make a whole lot of sense as I think what's actually implem= ented/supported will be dictated by the larger deployments of SAML/SAMLP or= JWT/JOSE/OpenID Connect. My feeling is that an MIT in these specs would li= kely be ignored and/or not influence implementers/deployers. So my preferen= ce would be to leave MTI out of these.

But if you're = not swayed by that line of thinking, and I'm guessing you're not,= =C2=A0rsa-sha256 is probably the most appropriate choice. Could you give so= me guidance and/or point to examples of where and how to say that appropria= tely in the documents? Thanks!

=C2=A0
Cheers,
S.

PS: Stuff below is fine.


Great, thank you= .


--001a1140f94eb8a98d05059118e7-- From nobody Thu Oct 16 14:56:29 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EDBB1A874B; Thu, 16 Oct 2014 14:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6wneDUaeon9; Thu, 16 Oct 2014 14:56:24 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id C2D861A8AB8; Thu, 16 Oct 2014 14:56:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B8824BEA4; Thu, 16 Oct 2014 22:56:22 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1XEBwwgMCPIa; Thu, 16 Oct 2014 22:56:21 +0100 (IST) Received: from [10.87.48.12] (unknown [86.46.21.146]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E8212BE98; Thu, 16 Oct 2014 22:56:20 +0100 (IST) Message-ID: <54403EFF.9000804@cs.tcd.ie> Date: Thu, 16 Oct 2014 22:56:15 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Brian Campbell References: <20141016112213.10005.54238.idtracker@ietfa.amsl.com> <54403208.6040108@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/c_s5XRB8oATtN6Jjh8mB9h92c_0 Cc: "draft-ietf-oauth-assertions@tools.ietf.org" , "oauth-chairs@tools.ietf.org" , The IESG , oauth Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 21:56:27 -0000 On 16/10/14 22:39, Brian Campbell wrote: > Hiya in return and inline below... > > On Thu, Oct 16, 2014 at 3:00 PM, Stephen Farrell > wrote: > >> >> Hmm. So the SAML one only seems to have RSA-SHA1 as the MTI and the >> JOSE one has only H256 as required. >> >> Doesn't that seem like one is unacceptably old and the other >> is not great for this purpose? >> > > Admittedly, I was a little worried you'd say that :) I'm glad we're not surprising one another:-) > > >> >> My suggestion would be to add rsa-sha256 as MTI for these, as an >> addition to whatever JOSE and SAML make MTI. But I'd be happy to >> clear if you made any modern signature alg MTI. >> >> > Honestly, in my view, an MIT on these doesn't make a whole lot of sense as > I think what's actually implemented/supported will be dictated by the > larger deployments of SAML/SAMLP or JWT/JOSE/OpenID Connect. My feeling is > that an MIT in these specs would likely be ignored and/or not influence > implementers/deployers. So my preference would be to leave MTI out of these. > > But if you're not swayed by that line of thinking, and I'm guessing you're > not, rsa-sha256 is probably the most appropriate choice. Could you give > some guidance and/or point to examples of where and how to say that > appropriately in the documents? Thanks! Sure, I'd say probably best is for the jwt one to say that RS256 MUST be supported and for the saml one say that [1] MUST be supported. (Check [2] for rsa-sha256 for some text) A sentence in each is all's needed. Cheers, S. [1] http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 [2] http://www.w3.org/TR/2013/NOTE-xmlsec-algorithms-20130411/ > > > >> Cheers, >> S. >> >> PS: Stuff below is fine. >> >> > Great, thank you. > From nobody Thu Oct 16 14:57:39 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32D401A874B; Thu, 16 Oct 2014 14:57:27 -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, SPF_PASS=-0.001] autolearn=ham Received: 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_4XKphzAhgO; Thu, 16 Oct 2014 14:57:22 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D8001A8AB8; Thu, 16 Oct 2014 14:57:21 -0700 (PDT) Received: by mail-la0-f42.google.com with SMTP id gf13so4065941lab.15 for ; Thu, 16 Oct 2014 14:57:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6J0yekBcrENI4DKCZu/zqk+YfTr4FGBjKnTKaghM/3g=; b=H2oTBSsfZXjGHuHbbIHXL06Vt2gbsn097z26+f2W9DjsDdfoTbN4uPzS137heOOJ+S LJBvem9Wd8Xb7FYazqkX9mKN2kTNjpVzAcDm9I80/lE6cdf2JKJyxK9GmPSMVWn4xLMC W0JIoPCqNMH59zt9xFdy17dSkAnnUbFoLPsLMnQXu9fltr5r2tz2ob/c/ly+VvfHV/bM 7sPDfGH1jE6yYOAlEryANeXrUApzMbokwK/Ev3koFNLGZ4g4cyhY2DNCC9xoz1qYar6R zT5C1ebWPw8rPHO791T8zgkjTo3EFKAwvdP8dWQCCwcmXsTEuyf6nEl/cLsazOKbHrGo 05aw== MIME-Version: 1.0 X-Received: by 10.152.20.199 with SMTP id p7mr4481110lae.49.1413496639891; Thu, 16 Oct 2014 14:57:19 -0700 (PDT) Received: by 10.112.95.36 with HTTP; Thu, 16 Oct 2014 14:57:19 -0700 (PDT) In-Reply-To: References: <20141016112213.10005.54238.idtracker@ietfa.amsl.com> <54403208.6040108@cs.tcd.ie> Date: Thu, 16 Oct 2014 17:57:19 -0400 Message-ID: From: Kathleen Moriarty To: Brian Campbell Content-Type: multipart/alternative; boundary=089e0141a5201caedf050591559a Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/lxd-B-gJE5ERTfXDUiIJzBX8yiM Cc: "draft-ietf-oauth-assertions@tools.ietf.org" , "oauth-chairs@tools.ietf.org" , oauth , The IESG Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 21:57:27 -0000 --089e0141a5201caedf050591559a Content-Type: text/plain; charset=UTF-8 On Thu, Oct 16, 2014 at 5:39 PM, Brian Campbell wrote: > Hiya in return and inline below... > > On Thu, Oct 16, 2014 at 3:00 PM, Stephen Farrell < > stephen.farrell@cs.tcd.ie> wrote: > >> >> Hmm. So the SAML one only seems to have RSA-SHA1 as the MTI and the >> JOSE one has only H256 as required. >> >> Doesn't that seem like one is unacceptably old and the other >> is not great for this purpose? >> > > Admittedly, I was a little worried you'd say that :) > > >> >> My suggestion would be to add rsa-sha256 as MTI for these, as an >> addition to whatever JOSE and SAML make MTI. But I'd be happy to >> clear if you made any modern signature alg MTI. >> >> > Honestly, in my view, an MIT on these doesn't make a whole lot of sense as > I think what's actually implemented/supported will be dictated by the > larger deployments of SAML/SAMLP or JWT/JOSE/OpenID Connect. My feeling is > that an MIT in these specs would likely be ignored and/or not influence > implementers/deployers. So my preference would be to leave MTI out of these. > > But if you're not swayed by that line of thinking, and I'm guessing you're > not, rsa-sha256 is probably the most appropriate choice. Could you give > some guidance and/or point to examples of where and how to say that > appropriately in the documents? Thanks! > I'm going to back Stephen up on this one. It best that we do point out the right thing to do, even if it's not always followed. Some will expect implementations to be complaint to the standard and that will hopefully drive implementations to better choices for algorithms. We have too many issues of deployed code and applications using things they should not (SSLv3). > > >> Cheers, >> S. >> >> PS: Stuff below is fine. >> >> > Great, thank you. > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- Best regards, Kathleen --089e0141a5201caedf050591559a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Oct 16, 2014 at 5:39 PM, Brian Campbell <<= a href=3D"mailto:bcampbell@pingidentity.com" target=3D"_blank">bcampbell@pi= ngidentity.com> wrote:
Hiya in return and inline below...

On Thu, Oct 16= , 2014 at 3:00 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie&= gt; wrote:

Hmm. So the SAML one only seems to have RSA-SHA1 as the MTI and the
JOSE one has only H256 as required.

Doesn't that seem like one is unacceptably old and the other
is not great for this purpose?

A= dmittedly, I was a little worried you'd say that :)
=C2=A0

My suggestion would be to add rsa-sha256 as MTI for these, as an
addition to whatever JOSE and SAML make MTI. But I'd be happy to
clear if you made any modern signature alg MTI.


Honestly, in my view, an MIT on= these doesn't make a whole lot of sense as I think what's actually= implemented/supported will be dictated by the larger deployments of SAML/S= AMLP or JWT/JOSE/OpenID Connect. My feeling is that an MIT in these specs w= ould likely be ignored and/or not influence implementers/deployers. So my p= reference would be to leave MTI out of these.

But if you&= #39;re not swayed by that line of thinking, and I'm guessing you're= not,=C2=A0rsa-sha256 is probably the most appropriate choice. Could you gi= ve some guidance and/or point to examples of where and how to say that appr= opriately in the documents? Thanks!
=

I'm going to back Stephen up on this o= ne.=C2=A0 It best that we do point out the right thing to do, even if it= 9;s not always followed.=C2=A0 Some will expect implementations to be compl= aint to the standard and that will hopefully drive implementations to bette= r choices for algorithms.=C2=A0 We have too many issues of deployed code an= d applications using things they should not (SSLv3).=C2=A0


=C2=A0
Cheers,
S.

PS: Stuff below is fine.


Great, th= ank you.



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




--

Best regards,
Kathleen
--089e0141a5201caedf050591559a-- From nobody Thu Oct 16 15:15:47 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A95211A8ABD for ; Thu, 16 Oct 2014 15:15:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4E-8BDGnmWfQ for ; Thu, 16 Oct 2014 15:15:40 -0700 (PDT) Received: from na3sys009aog120.obsmtp.com (na3sys009aog120.obsmtp.com [74.125.149.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81CCF1A8A45 for ; Thu, 16 Oct 2014 15:15:40 -0700 (PDT) Received: from mail-ig0-f174.google.com ([209.85.213.174]) (using TLSv1) by na3sys009aob120.postini.com ([74.125.148.12]) with SMTP ID DSNKVEBDjGoSH3EGj5/8El8mhGDI/PUtBQ8q@postini.com; Thu, 16 Oct 2014 15:15:40 PDT Received: by mail-ig0-f174.google.com with SMTP id a13so536719igq.1 for ; Thu, 16 Oct 2014 15:15:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=xEeNIRf7TNjaH12TgyuAvwGWS8hLOeTadLg28d9WqKU=; b=mO0vldzFUtdd6CRZoiC/jCfrV1BPT0kvEOsUdSK2k0u0fCaqC5SRhr6NsqX7liVmGh U69k3khJxCt1i8n48b17USkaGKdjYdb0YqqDJCZcifstazJlA18qqt7PtwUaOTHu/7Xu 40Idg6vi76mF+OSrp3fr6ZyPokygK3TJdh85sPE7wxo8JcyxyOAKBa7+LD4NegSXSfF5 EJIP59GweYLpw27f1PUA0fQtC26A2Ma+AVqjCIC50dq3rqxN/Zbk92/jJfY7GGvL0vvy 221sljT1FbRGFZycJZM9inwR77Cw1bAKBnrgW9p0Vq50Dtq/b6mz8RLylcfitXztLLcJ eO3Q== X-Gm-Message-State: ALoCoQlzHFP7SadP1kEM0nbik5mUpbQahw5baa5n4h1jEi2WLmPHsJJa6ZM41WinfSxq0k/UQP8AuvxsQlaCypC9AONkNARMVovXR+njU3hf9PP0TJ8/Bk9d5NodH7/csxQj85UWRNPA X-Received: by 10.107.152.149 with SMTP id a143mr4822510ioe.39.1413497739974; Thu, 16 Oct 2014 15:15:39 -0700 (PDT) X-Received: by 10.107.152.149 with SMTP id a143mr4822493ioe.39.1413497739834; Thu, 16 Oct 2014 15:15:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.12.137 with HTTP; Thu, 16 Oct 2014 15:15:08 -0700 (PDT) In-Reply-To: References: <20141016112213.10005.54238.idtracker@ietfa.amsl.com> <54403208.6040108@cs.tcd.ie> From: Brian Campbell Date: Thu, 16 Oct 2014 16:15:08 -0600 Message-ID: To: Kathleen Moriarty Content-Type: multipart/alternative; boundary=001a1140f504acb0e6050591968a Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/13TzW2f-ZSNIGgzzr25qQgCcaMI Cc: "draft-ietf-oauth-assertions@tools.ietf.org" , "oauth-chairs@tools.ietf.org" , oauth , The IESG Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 22:15:42 -0000 --001a1140f504acb0e6050591968a Content-Type: text/plain; charset=UTF-8 Alright, I'll add RS256 and http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 as mandatory to implement in the next revision of draft-ietf-oauth-jwt-bearer and draft-ietf-oauth-saml2-bearer respectively. Thanks for the pointers, Stephen. On Thu, Oct 16, 2014 at 3:57 PM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > > > On Thu, Oct 16, 2014 at 5:39 PM, Brian Campbell < > bcampbell@pingidentity.com> wrote: > >> Hiya in return and inline below... >> >> On Thu, Oct 16, 2014 at 3:00 PM, Stephen Farrell < >> stephen.farrell@cs.tcd.ie> wrote: >> >>> >>> Hmm. So the SAML one only seems to have RSA-SHA1 as the MTI and the >>> JOSE one has only H256 as required. >>> >>> Doesn't that seem like one is unacceptably old and the other >>> is not great for this purpose? >>> >> >> Admittedly, I was a little worried you'd say that :) >> >> >>> >>> My suggestion would be to add rsa-sha256 as MTI for these, as an >>> addition to whatever JOSE and SAML make MTI. But I'd be happy to >>> clear if you made any modern signature alg MTI. >>> >>> >> Honestly, in my view, an MIT on these doesn't make a whole lot of sense >> as I think what's actually implemented/supported will be dictated by the >> larger deployments of SAML/SAMLP or JWT/JOSE/OpenID Connect. My feeling is >> that an MIT in these specs would likely be ignored and/or not influence >> implementers/deployers. So my preference would be to leave MTI out of these. >> >> But if you're not swayed by that line of thinking, and I'm guessing >> you're not, rsa-sha256 is probably the most appropriate choice. Could you >> give some guidance and/or point to examples of where and how to say that >> appropriately in the documents? Thanks! >> > > I'm going to back Stephen up on this one. It best that we do point out > the right thing to do, even if it's not always followed. Some will expect > implementations to be complaint to the standard and that will hopefully > drive implementations to better choices for algorithms. We have too many > issues of deployed code and applications using things they should not > (SSLv3). > > >> >> >>> Cheers, >>> S. >>> >>> PS: Stuff below is fine. >>> >>> >> Great, thank you. >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > > -- > > Best regards, > Kathleen > --001a1140f504acb0e6050591968a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Alright, I'll add RS256 and http://www.w3.org/200= 1/04/xmldsig-more#rsa-sha256 as mandatory to implement in the next revi= sion of draft-ietf-oauth-jwt-bearer and draft-ietf-oauth-saml2-bearer respe= ctively.

Thanks for the pointers, Stephen.

On Thu, Oct 16, 2014 at 3:57 PM, = Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>= wrote:


On Thu, Oct 16, 2014 at 5:39 PM, Brian Campbell <bcampbell@pingi= dentity.com> wrote:
Hiya in return and inline below...

On Thu, Oct 16, 2014 at 3:00= PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wro= te:

Hmm. So the SAML one only seems to have RSA-SHA1 as the MTI and the
JOSE one has only H256 as required.

Doesn't that seem like one is unacceptably old and the other
is not great for this purpose?

A= dmittedly, I was a little worried you'd say that :)
=C2=A0

My suggestion would be to add rsa-sha256 as MTI for these, as an
addition to whatever JOSE and SAML make MTI. But I'd be happy to
clear if you made any modern signature alg MTI.


Honestly, in my view, an MIT on= these doesn't make a whole lot of sense as I think what's actually= implemented/supported will be dictated by the larger deployments of SAML/S= AMLP or JWT/JOSE/OpenID Connect. My feeling is that an MIT in these specs w= ould likely be ignored and/or not influence implementers/deployers. So my p= reference would be to leave MTI out of these.

But if you&= #39;re not swayed by that line of thinking, and I'm guessing you're= not,=C2=A0rsa-sha256 is probably the most appropriate choice. Could you gi= ve some guidance and/or point to examples of where and how to say that appr= opriately in the documents? Thanks!
=

I'm going to back Stephen = up on this one.=C2=A0 It best that we do point out the right thing to do, e= ven if it's not always followed.=C2=A0 Some will expect implementations= to be complaint to the standard and that will hopefully drive implementati= ons to better choices for algorithms.=C2=A0 We have too many issues of depl= oyed code and applications using things they should not (SSLv3).=C2=A0

=
=C2=A0
Cheers,
S.

PS: Stuff below is fine.


Great, th= ank you.



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




--

Bes= t regards,
Kathleen

--001a1140f504acb0e6050591968a-- From nobody Thu Oct 16 15:20:28 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 380A11A8ABD for ; Thu, 16 Oct 2014 15:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NEXDF1T9uZym for ; Thu, 16 Oct 2014 15:20:23 -0700 (PDT) Received: from mail-vc0-f176.google.com (mail-vc0-f176.google.com [209.85.220.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49B9B1A8AA6 for ; Thu, 16 Oct 2014 15:20:23 -0700 (PDT) Received: by mail-vc0-f176.google.com with SMTP id hq11so3433607vcb.21 for ; Thu, 16 Oct 2014 15:20:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wF2RfFPV2NC7IMVS9L5rsA2LCINNPj4xs7sY+ozIwHA=; b=C3+mrGIGCPTaEZkdFTTpz2GeJni5XOyuEr6Qh9LSnRmZDB4WOLzU+HQ19TSOc52RwT xnwa80vziEsoi+EZXw0u8UkNlys8ZH2umFm/1iges3B5Fup1Bmr031kB4brDELuIzF0l WCKpVS+Cl44vdWt7qN/j33lI1/2OyIe0RQVI+nR+AqfXBvKbUgzczEPCwKg8Taagnb+y m2dHmT+dNQVhG+LHDqtTgAqPFgah//1jVZEGLOGbAO6+A30LafdecLkvY9J/Z4K8mu3w gY31lLEKD2JrG0vlqZWtYt8DJp1Wymd62D2yPU0Iq+dzIOh7y0tDI2xqsbq3LNYpFEqM I02g== X-Gm-Message-State: ALoCoQn1S1GqYY6C2ORj+vCYb4b4gh2oKlrx6O93OFYfqshtiDTThQHh70VDJod03WSGDgvFMGUB MIME-Version: 1.0 X-Received: by 10.221.28.137 with SMTP id ru9mr4120506vcb.19.1413498022300; Thu, 16 Oct 2014 15:20:22 -0700 (PDT) Received: by 10.31.149.205 with HTTP; Thu, 16 Oct 2014 15:20:22 -0700 (PDT) In-Reply-To: References: <20141016034735.18695.61014.idtracker@ietfa.amsl.com> Date: Thu, 16 Oct 2014 15:20:22 -0700 Message-ID: From: Richard Barnes To: Phil Hunt Content-Type: multipart/alternative; boundary=001a1133750282a263050591a7fe Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/YnaE5MakJvTHFHsybvGNf11lhIA Cc: "draft-ietf-oauth-assertions@tools.ietf.org" , "oauth-chairs@tools.ietf.org" , The IESG , oauth Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 22:20:26 -0000 --001a1133750282a263050591a7fe Content-Type: text/plain; charset=UTF-8 You guys are all arguing that having an Audience can be useful. I don't disagree. I disagree that it should be REQUIRED in all cases. The Google vulnerability that Brian raised was an interesting read, but as John points out, it only applies to Bearer Assertions. There's no security requirement at all for holder-of-key assertions to have an audience, since they can't be replayed by someone who doesn't hold the key. I could agree that an audience should be REQUIRED for bearer assertions. Since they are vulnerable to replay, Audience protects against the Authorization Server re-using the token. (It would be good to say this explicitly in the doc, actually.) But for holder-of-key assertions, the Audience should be OPTIONAL. Note that this requires that instance documents define the difference between bearer assertions and holder-of-key assertions, so that implementations can enforce these requirements. So it seems like there are two solutions here: 1. Scope the document to bearer assertions only, and keep the MUST 2. Keep the current scope, make Audience OPTIONAL for holder-of-key assertions, and define the difference in the instance docs. --Richard On Thu, Oct 16, 2014 at 9:57 AM, Phil Hunt wrote: > It is also important for a non-protocol purpose. Liability. > > If a 3rd party uses an assertion that was not intended for it, it cannot > obviously hold the asserting party responsible. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > On Oct 16, 2014, at 8:43 AM, Brian Campbell > wrote: > > Thanks for your review and feedback, Richard. Replies are inline below... > > On Wed, Oct 15, 2014 at 9:47 PM, Richard Barnes wrote: > >> Richard Barnes has entered the following ballot position for >> draft-ietf-oauth-assertions-17: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> "The assertion MUST contain an Audience that identifies the Authorization >> Server as the intended audience. Assertions that do not identify the >> Authorization Server as an intended audience MUST be rejected." >> >> Could you please identify the threat model within which this "MUST" is >> required? This requirement doesn't follow from any of the threats >> elaborated in Section 8. >> >> The Audience is only necessary if the Issuer wishes to constrain the set >> of Authorization Servers with which an assertion may be used. So ISTM >> that this should be "MAY contain..." >> >> > > The audience restriction let's the issuer say specifically what relying > party is allowed to consume the assertion, which ensures that the client > can't use it somewhere else that it wasn't intended and that the relying > party that receives the assertion can't turn around and use it to access > some other service. > > Strictly speaking, you are right that the audience is only necessary if > the Issuer wishes to constrain the set of Authorization Servers with which > an assertion may be used. But the Issuer really really really should make > that constraint and fully understanding the implications of not doing so is > difficult and unlikely. > > There was a vulnerability in Google apps SAML a few years back that > demonstrates how important audience restriction is and how it can be > difficult for even very sophisticated providers to get it all right. I > haven't had time to read it again to make sure but I think that this is the > paper http://www.ai-lab.it/armando/pub/fmse9-armando.pdf > > I don't see what value allowing audience to be omitted brings other than > that it is academically a possibility. But requiring it (hopefully, if the > requirement is followed) helps reduce the possibility of a whole bunch of > security problems that folks likely won't foresee. > > > >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> "keyed message digest" -> "Message Authentication Code" >> >> That's the proper terminology [RFC4949], especially since there are MACs >> that are not based on digests. >> > > OK > > >> >> "This mechanism provides additional security properties." -- Please >> delete this or elaborate on what security properties it provides. >> > > Will delete. > > >> >> Section 8.2 should note that "Holder-of-Key Assertions" are also a >> mitigation for this risk. >> >> > OK > > > >> _______________________________________________ >> 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 > > > --001a1133750282a263050591a7fe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
You guys are all arguing that having an Audience can = be useful.=C2=A0 I don't disagree.=C2=A0 I disagree that it should be R= EQUIRED in all cases.

The Google vulnerability that Brian= raised was an interesting read, but as John points out, it only applies to= Bearer Assertions.=C2=A0 There's no security requirement at all for ho= lder-of-key assertions to have an audience, since they can't be replaye= d by someone who doesn't hold the key.

I could agree = that an audience should be REQUIRED for bearer assertions.=C2=A0 Since they= are vulnerable to replay, Audience protects against the Authorization Serv= er re-using the token.=C2=A0 (It would be good to say this explicitly in th= e doc, actually.)=C2=A0 But for holder-of-key assertions, the Audience shou= ld be OPTIONAL.=C2=A0 Note that this requires that instance documents defin= e the difference between bearer assertions and holder-of-key assertions, so= that implementations can enforce these requirements.

So = it seems like there are two solutions here:
1. Scope the docu= ment to bearer assertions only, and keep the MUST
2. Keep the= current scope, make Audience OPTIONAL for holder-of-key assertions, and de= fine the difference in the instance docs.

--Richard






On Thu, Oct 16, 2014 at 9:57 AM, Phil Hu= nt <phil.hunt@oracle.com> wrote:
It is also important for a no= n-protocol purpose. Liability.

If a 3rd party uses an as= sertion that was not intended for it, it cannot obviously hold the assertin= g party responsible. =C2=A0


On Oct 16, 2014, at 8:43 AM, Brian Campbell <bcampbell@pingidentity.c= om> wrote:

Thanks for your review and feedback, Richard.=20 Replies are inline below...

On Wed, Oct 15, 2014 at 9:47 PM, Richard Barnes <rlb@ipv.s= x> wrote:
http://www.ietf.org/iesg/statement/discuss-crit= eria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions= /



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

"The assertion MUST contain an Audience that identifies the Authorizat= ion
Server as the intended audience.=C2=A0 Assertions that do not identify the<= br> Authorization Server as an intended audience MUST be rejected."

Could you please identify the threat model within which this "MUST&quo= t; is
required?=C2=A0 This requirement doesn't follow from any of the threats=
elaborated in Section 8.

The Audience is only necessary if the Issuer wishes to constrain the set of Authorization Servers with which an assertion may be used.=C2=A0 So ISTM=
that this should be "MAY contain..."



The audience restriction let's= the issuer say specifically what=20 relying party is allowed to consume the assertion, which ensures that=20 the client can't use it somewhere else that it wasn't intended and = that the=20 relying party that receives the assertion can't turn around and use it= =20 to access some other service.

Strictly speaking,= you are right that the audience is only necessary if the Issuer wishes to = constrain the set of Authorization Servers with which an assertion may be u= sed. But the Issuer really really really should make that constraint and fu= lly understanding the implications of not doing so is difficult and unlikel= y.

There was a vulnerability in Google apps SAML a few y= ears back that demonstrates how important audience restriction is and= how it can be difficult for even very sophisticated providers to get it al= l right. I haven't had time to read it again to make sure but I think t= hat this is the paper http://www.ai-lab.it/armando/pub/fmse9-armando.= pdf

I don't see what value allowing = audience to be omitted brings other than that it is academically a possibil= ity. But requiring it (hopefully, if the requirement is followed) helps red= uce the possibility of a whole bunch of security problems that folks likely= won't foresee.

=C2=A0
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

"keyed message digest" -> "Message Authentication Code&qu= ot;

That's the proper terminology [RFC4949], especially since there are MAC= s
that are not based on digests.

OK
=C2=A0

"This mechanism provides additional security properties." -- Plea= se
delete this or elaborate on what security properties it provides.

Will delete.
=C2=A0

Section 8.2 should note that "Holder-of-Key Assertions" are also = a
mitigation for this risk.


OK
=C2=A0
=C2= =A0
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

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


--001a1133750282a263050591a7fe-- From nobody Thu Oct 16 15:32:08 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90C4A1A8AA7 for ; Thu, 16 Oct 2014 15:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFim82UOtTll for ; Thu, 16 Oct 2014 15:32:05 -0700 (PDT) Received: from mail-vc0-f173.google.com (mail-vc0-f173.google.com [209.85.220.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48FE11A8764 for ; Thu, 16 Oct 2014 15:32:05 -0700 (PDT) Received: by mail-vc0-f173.google.com with SMTP id ij19so3492716vcb.4 for ; Thu, 16 Oct 2014 15:32:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=FzfjNxYnMlLRjCKlTTFo9jd6FVCRVL4YGx5Ibw/8dMQ=; b=TjRG3SqqmzPGhqUM0w20dM4dCJgFAjGqtmIF+Oey5sHenmXoBVde3uygyCofm0cRG8 75OshRXESUOt+742KSBip9jboOIQBmhiyfyNDNqOaBae2LZKg8l5QRkkPMB/CdM2c7Eo kXa/Esth53V+DBlz8xJEj/kocNayACszbGhew0IIwbHZkgRfQrKcyXK7uYTI6SS+Ix8+ XNsvrw2j+c0cgFgTQrXFlnZbCuoTV4IA2kvR4HxRrjAc8fjJe0t27lIEXRN86rhQBeV3 Gg7xghobdso4i7Tojk9Cmc/FazfFPpmrKSti8RRucqTmNpUKCoiSVOwYl+86Pjhd+/yS NMCQ== X-Gm-Message-State: ALoCoQlcoZwUrvHdrzJeFRg+yjQW1oEISvp5JeE1DwJh6t3+Ii8fENoKm2NlVvG32jki+2IhrVo1 MIME-Version: 1.0 X-Received: by 10.52.244.110 with SMTP id xf14mr3522687vdc.6.1413498724406; Thu, 16 Oct 2014 15:32:04 -0700 (PDT) Received: by 10.31.149.205 with HTTP; Thu, 16 Oct 2014 15:32:04 -0700 (PDT) In-Reply-To: References: <20141016040122.32277.7067.idtracker@ietfa.amsl.com> Date: Thu, 16 Oct 2014 15:32:04 -0700 Message-ID: From: Richard Barnes To: Brian Campbell Content-Type: multipart/alternative; boundary=001a11c20e165c264d050591d100 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/ip1qaECRdZsckigOR_HK3x-sOJg Cc: "oauth-chairs@tools.ietf.org" , oauth , The IESG , draft-ietf-oauth-jwt-bearer@tools.ietf.org Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-jwt-bearer-10: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 22:32:07 -0000 --001a11c20e165c264d050591d100 Content-Type: text/plain; charset=UTF-8 On Thu, Oct 16, 2014 at 1:44 PM, Brian Campbell wrote: > Thanks for your review and feedback on this one too, Richard. Replies are > inline below... > > On Wed, Oct 15, 2014 at 10:01 PM, Richard Barnes wrote: > >> Richard Barnes has entered the following ballot position for >> draft-ietf-oauth-jwt-bearer-10: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> http://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> As with draft-ietf-oauth-assertions, the requirement for an "aud" claim >> seems entirely unnecessary. Holding this DISCUSS point pending that >> discussion >> and its reflection in this document. >> >> "Assertions that do not identify the Authorization Server as an intended >> audience MUST be rejected." -- What does it mean for an assertion to >> "identify >> the Authorization Server"? Does the specified need to match >> the >> entire URL of the relevant OAuth endpoint? Just the origin? Just the >> domain? >> Does the URL need to be canonicalized? >> >> > > No c14n, as it says, "... compare the audience values using the Simple > String Comparison method defined in Section 6.2.1 of RFC 3986." > > Basically the AS is at liberty to determine how it identifies itself. Some > guidance on using the token endpoint is provided but it's ultimately up to > the AS (or the larger deployment in which the AS exists). The acceptable > value is one of a few bits of information that must be exchanged for this > profile, which is discussed in the Interoperability Considerations > https://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-10#section-5 > Sigh. "Negotiate it out of band" is a terrible, non-scalable, not-in-the-spirit-of-the-Internet answer. But I guess I might clear on this if you could add something like the following: "As noted in Section 5 of [I-D.ietf-oauth-jwt-bearer], the precise strings to be used as the Audience for a given Authorization Server must be configured out-of-band by the Authorization Server and the Issuer of the assertion." But is there seriously no answer that the WG could agree on? This seems like it should be a pretty simple question. Was it even discussed? --Richard > Some more explanation/discussion of it is in the middle(ish) of this reply > to a similar comment from Stephen Farrell > http://www.ietf.org/mail-archive/web/oauth/current/msg13605.html > > > >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> "keyed message digest" -> "MAC" >> > > Yep. > > >> >> Both this and the SAML document could save a lot of bits by just being >> subsections of the -assertions document. >> > > The structure and relationship of the documents was decided on by the WG > nearly three years ago. There is some duplication but it's believed to be > more approachable this way - particularly for those implementing just one > assertion type. > --001a11c20e165c264d050591d100 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Oct 16, 2014 at 1:44 PM, Brian Campbell <<= a href=3D"mailto:bcampbell@pingidentity.com" target=3D"_blank">bcampbell@pi= ngidentity.com> wrote:
Thanks for your review and feedback on this one t= oo, Richard.=20 Replies are inline below...

On Wed, Oct 15, 2014 at 10:01= PM, Richard Barnes <rlb@ipv.sx> wrote:
Richard Barnes has entered the following ballot p= osition for
draft-ietf-oauth-jwt-bearer-10: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-crit= eria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer= /



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

As with draft-ietf-oauth-assertions, the requirement for an "aud"= claim
seems entirely unnecessary.=C2=A0 Holding this DISCUSS point pending that discussion
and its reflection in this document.

"Assertions that do not identify the Authorization Server as an intend= ed
audience MUST be rejected." -- What does it mean for an assertion to "identify
the Authorization Server"?=C2=A0 Does the specified <Audience> n= eed to match
the
entire URL of the relevant OAuth endpoint?=C2=A0 Just the origin?=C2=A0 Jus= t the
domain?
Does the URL need to be canonicalized?



No c14n, as it says, &= quot;...=C2=A0 compare the audience values using the Simple String Comparis= on method defined in Section 6.2.1 of RFC 3986."

Ba= sically the AS is at liberty to determine how it identifies itself. Some gu= idance on using the token endpoint is provided but it's ultimately up t= o the AS (or the larger deployment in which the AS exists). The acceptable = value is one of a few bits of information that must be exchanged for this p= rofile, which is discussed in the Interoperability Considerations https://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-10= #section-5

= Sigh.=C2=A0 "Negotiate it out of band" is a terrible, non-scalabl= e, not-in-the-spirit-of-the-Internet answer.=C2=A0 But I guess I might clea= r on this if you could add something like the following:
&quo= t;As noted in Section 5 of [I-D.ietf-oauth-jwt-bearer], the precise strings= to be used as the Audience for a given Authorization Server must be config= ured out-of-band by the Authorization Server and the Issuer of the assertio= n."

But is there seriously no answer that the WG cou= ld agree on?=C2=A0 This seems like it should be a pretty simple question.= =C2=A0 Was it even discussed?

--Richard
=C2=A0
Some more explanation/discussi= on of it is in the middle(ish) of this reply to a similar comment from Step= hen Farrell http://www.ietf.org/mail-archive/web/oauth/= current/msg13605.html



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

"keyed message digest" -> "MAC"

Yep.
=C2=A0

Both this and the SAML document could save a lot of bits by just being
subsections of the -assertions document.

The structure and relationship of the documents was decided on by = the WG nearly three years ago. There is some duplication but it's belie= ved to be more approachable this way - particularly for those implementing = just one assertion type.

--001a11c20e165c264d050591d100-- From nobody Thu Oct 16 15:37:20 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0321C1A882A for ; Thu, 16 Oct 2014 15:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CH85nK8dRuee for ; Thu, 16 Oct 2014 15:37:15 -0700 (PDT) Received: from mail-vc0-f169.google.com (mail-vc0-f169.google.com [209.85.220.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A5FB1A8ACE for ; Thu, 16 Oct 2014 15:36:52 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id hy4so3501050vcb.14 for ; Thu, 16 Oct 2014 15:36:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=74eFXP+8jmCf0V2mtGgCKKlWTDGPxSexnpozUO6fsc4=; b=ksbOvdLCaN6uvTw+uWq+eD7iQec16U0Uv9bsHSjsR/45fh/XU2Ul3Pfk9S3yEnyrm6 owwSeWwgSiWythEDT+eGJaHZL5WnpQ62PRRWaTzAVC1Hlk33KrkZXqK/Ox3BiKUOpOfX 76x5UX9ZaIfJunzIo77ihsyEEO//HR2KTB1BtJyNu/hAMcvu10irWqZLvAR8uaR+0Qi3 xp2qkBO7HlU7Q+q7dlxbhd3XuixM/0+ACQQMBwKlIa0zLivhgFvQHzBYAUXD5GXDVi8N RF7LtFjTKwacKkmThNZO8XUCHrJUB1htX6jzsJvcl/U+b2qE1JrquIdb5vXxntIuugnq zHwA== X-Gm-Message-State: ALoCoQkuUCNp13QZF8OH2HO9IfoIEqk4+NT7Cy3qQqkShfe/1hf3m/bIVkD2zCrXto5Gy81pJqtA MIME-Version: 1.0 X-Received: by 10.220.77.196 with SMTP id h4mr4201891vck.14.1413499011760; Thu, 16 Oct 2014 15:36:51 -0700 (PDT) Received: by 10.31.149.205 with HTTP; Thu, 16 Oct 2014 15:36:51 -0700 (PDT) In-Reply-To: References: <20141016035640.25108.27277.idtracker@ietfa.amsl.com> Date: Thu, 16 Oct 2014 15:36:51 -0700 Message-ID: From: Richard Barnes To: Brian Campbell Content-Type: multipart/alternative; boundary=047d7b3a911c7c9aba050591e23d Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/p2nd7ub5wSyG3owj_7ZwcjAtUl0 Cc: "oauth-chairs@tools.ietf.org" , draft-ietf-oauth-saml2-bearer@tools.ietf.org, The IESG , oauth Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-saml2-bearer-21: (with DISCUSS) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 22:37:18 -0000 --047d7b3a911c7c9aba050591e23d Content-Type: text/plain; charset=UTF-8 That's what you get for duplicating all the text :) On Thu, Oct 16, 2014 at 2:00 PM, Brian Campbell wrote: > Basically the same response to the basically same question as from > http://www.ietf.org/mail-archive/web/oauth/current/msg13608.html > > On Wed, Oct 15, 2014 at 9:56 PM, Richard Barnes wrote: > >> Richard Barnes has entered the following ballot position for >> draft-ietf-oauth-saml2-bearer-21: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> As with draft-ietf-oauth-assertions, the requirement for an >> element seems entirely unnecessary. Holding this DISCUSS point pending >> that discussion and its reflection in this document. >> >> "Assertions that do not identify the Authorization Server as an intended >> audience MUST be rejected." -- What does it mean for an assertion to >> "identify the Authorization Server"? Does the specified need >> to match the entire URL of the relevant OAuth endpoint? Just the origin? >> Just the domain? Does the URL need to be canonicalized? >> >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > --047d7b3a911c7c9aba050591e23d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
That's what you get for duplicating all the text :)

On Thu, Oc= t 16, 2014 at 2:00 PM, Brian Campbell <bcampbell@pingidentity.com= > wrote:
B= asically the same response to the basically same question as from http://www.ietf.org/mail-archive/web/oauth/current/msg13608.ht= ml

<= div>
On Wed, Oct 15, 2014 at 9:56 PM, Richard Barnes <rlb@ipv.sx= > wrote:
<= div class=3D"h5">Richard Barnes has entered the following ballot position f= or
draft-ietf-oauth-saml2-bearer-21: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-crit= eria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-be= arer/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

As with draft-ietf-oauth-assertions, the requirement for an <Audience>= ;
element seems entirely unnecessary.=C2=A0 Holding this DISCUSS point pendin= g
that discussion and its reflection in this document.

"Assertions that do not identify the Authorization Server as an intend= ed
audience MUST be rejected." -- What does it mean for an assertion to "identify the Authorization Server"?=C2=A0 Does the specified <= ;Audience> need
to match the entire URL of the relevant OAuth endpoint?=C2=A0 Just the orig= in?
=C2=A0Just the domain?=C2=A0 Does the URL need to be canonicalized?




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


--047d7b3a911c7c9aba050591e23d-- From nobody Thu Oct 16 17:04:14 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2C9C1A87E0 for ; Thu, 16 Oct 2014 17:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ejA7EDKJvWx for ; Thu, 16 Oct 2014 17:03:58 -0700 (PDT) Received: from mail-vc0-f171.google.com (mail-vc0-f171.google.com [209.85.220.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DA561A7D83 for ; Thu, 16 Oct 2014 17:03:58 -0700 (PDT) Received: by mail-vc0-f171.google.com with SMTP id hy10so3575673vcb.30 for ; Thu, 16 Oct 2014 17:03:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=doZq152jcDCKwBdX12651DShbUaGQis2KH1yzpZ96fg=; b=UywfN2S9pfzPNoFz8unjoyci1phGXKOavFFIwXYfGoNzZlD4gA1uAClpv3y2to6e2I MJqMJYYRVSgEh8KgXPizkWfbMIu++edU3SrQvMluCtGcswORNwDuYnnn3fHzVgwiS97b qh7jDnIc87vbHi9BjJpIBUr5RJa9ELKK5WT5E1yNInxqOoUr3Cy64fjevuhJ8RmxEIwQ 03Eu/EwGcDfRksDvpwMNq+0B+jUG4pc2Mh/1Xcnt221ylzTKneKMlX1ZBup1w55Ktzy8 lGvrMVPmgHbr1cFo3Nvm2DYzee0/DQfpgJutHYJUQ7JSTRReynaxIsm0pbuGC1bRmTe6 O5vg== X-Gm-Message-State: ALoCoQl436nl6Fdro+BYDtScEcGAcm41093nQa5wa+MAkrUrbgH4om8ywmp7jtDsavzt7ugjZQG2 MIME-Version: 1.0 X-Received: by 10.220.76.71 with SMTP id b7mr18443vck.55.1413504237495; Thu, 16 Oct 2014 17:03:57 -0700 (PDT) Received: by 10.31.149.205 with HTTP; Thu, 16 Oct 2014 17:03:57 -0700 (PDT) In-Reply-To: References: <20141016034735.18695.61014.idtracker@ietfa.amsl.com> Date: Thu, 16 Oct 2014 17:03:57 -0700 Message-ID: From: Richard Barnes To: Phil Hunt Content-Type: multipart/alternative; boundary=001a11c21538f701bf05059319b7 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/afzxXu6BXa-gnCErMbn075CHFnw Cc: "draft-ietf-oauth-assertions@tools.ietf.org" , "oauth-chairs@tools.ietf.org" , The IESG , oauth Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 00:04:02 -0000 --001a11c21538f701bf05059319b7 Content-Type: text/plain; charset=UTF-8 On Thu, Oct 16, 2014 at 3:20 PM, Richard Barnes wrote: > You guys are all arguing that having an Audience can be useful. I don't > disagree. I disagree that it should be REQUIRED in all cases. > > The Google vulnerability that Brian raised was an interesting read, but as > John points out, it only applies to Bearer Assertions. There's no security > requirement at all for holder-of-key assertions to have an audience, since > they can't be replayed by someone who doesn't hold the key. > > I could agree that an audience should be REQUIRED for bearer assertions. > Since they are vulnerable to replay, Audience protects against the > Authorization Server re-using the token. (It would be good to say this > explicitly in the doc, actually.) But for holder-of-key assertions, the > Audience should be OPTIONAL. Note that this requires that instance > documents define the difference between bearer assertions and holder-of-key > assertions, so that implementations can enforce these requirements. > > So it seems like there are two solutions here: > 1. Scope the document to bearer assertions only, and keep the MUST > 2. Keep the current scope, make Audience OPTIONAL for holder-of-key > assertions, and define the difference in the instance docs. > I'll also offer a third resolution: 3. Show me that the WG discussed this question and made the decision to forbid holder-of-key assertions without an Audience parameter. --Richard > --Richard > > > > > > > On Thu, Oct 16, 2014 at 9:57 AM, Phil Hunt wrote: > >> It is also important for a non-protocol purpose. Liability. >> >> If a 3rd party uses an assertion that was not intended for it, it cannot >> obviously hold the asserting party responsible. >> >> Phil >> >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> >> >> >> On Oct 16, 2014, at 8:43 AM, Brian Campbell >> wrote: >> >> Thanks for your review and feedback, Richard. Replies are inline below... >> >> On Wed, Oct 15, 2014 at 9:47 PM, Richard Barnes wrote: >> >>> Richard Barnes has entered the following ballot position for >>> draft-ietf-oauth-assertions-17: Discuss >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>> >>> >>> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> "The assertion MUST contain an Audience that identifies the Authorization >>> Server as the intended audience. Assertions that do not identify the >>> Authorization Server as an intended audience MUST be rejected." >>> >>> Could you please identify the threat model within which this "MUST" is >>> required? This requirement doesn't follow from any of the threats >>> elaborated in Section 8. >>> >>> The Audience is only necessary if the Issuer wishes to constrain the set >>> of Authorization Servers with which an assertion may be used. So ISTM >>> that this should be "MAY contain..." >>> >>> >> >> The audience restriction let's the issuer say specifically what relying >> party is allowed to consume the assertion, which ensures that the client >> can't use it somewhere else that it wasn't intended and that the relying >> party that receives the assertion can't turn around and use it to access >> some other service. >> >> Strictly speaking, you are right that the audience is only necessary if >> the Issuer wishes to constrain the set of Authorization Servers with which >> an assertion may be used. But the Issuer really really really should make >> that constraint and fully understanding the implications of not doing so is >> difficult and unlikely. >> >> There was a vulnerability in Google apps SAML a few years back that >> demonstrates how important audience restriction is and how it can be >> difficult for even very sophisticated providers to get it all right. I >> haven't had time to read it again to make sure but I think that this is the >> paper http://www.ai-lab.it/armando/pub/fmse9-armando.pdf >> >> I don't see what value allowing audience to be omitted brings other than >> that it is academically a possibility. But requiring it (hopefully, if the >> requirement is followed) helps reduce the possibility of a whole bunch of >> security problems that folks likely won't foresee. >> >> >> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> "keyed message digest" -> "Message Authentication Code" >>> >>> That's the proper terminology [RFC4949], especially since there are MACs >>> that are not based on digests. >>> >> >> OK >> >> >>> >>> "This mechanism provides additional security properties." -- Please >>> delete this or elaborate on what security properties it provides. >>> >> >> Will delete. >> >> >>> >>> Section 8.2 should note that "Holder-of-Key Assertions" are also a >>> mitigation for this risk. >>> >>> >> OK >> >> >> >>> _______________________________________________ >>> 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 >> >> >> > --001a11c21538f701bf05059319b7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Oct 16, 2014 at 3:20 PM, Richard Barnes <<= a href=3D"mailto:rlb@ipv.sx" target=3D"_blank">rlb@ipv.sx> wr= ote:
You guys are a= ll arguing that having an Audience can be useful.=C2=A0 I don't disagre= e.=C2=A0 I disagree that it should be REQUIRED in all cases.

<= div>The Google vulnerability that Brian raised was an interesting read, but= as John points out, it only applies to Bearer Assertions.=C2=A0 There'= s no security requirement at all for holder-of-key assertions to have an au= dience, since they can't be replayed by someone who doesn't hold th= e key.

I could agree that an audience should be REQUIRED = for bearer assertions.=C2=A0 Since they are vulnerable to replay, Audience = protects against the Authorization Server re-using the token.=C2=A0 (It wou= ld be good to say this explicitly in the doc, actually.)=C2=A0 But for hold= er-of-key assertions, the Audience should be OPTIONAL.=C2=A0 Note that this= requires that instance documents define the difference between bearer asse= rtions and holder-of-key assertions, so that implementations can enforce th= ese requirements.

So it seems like there are two solution= s here:
1. Scope the document to bearer assertions only, and = keep the MUST
2. Keep the current scope, make Audience OPTION= AL for holder-of-key assertions, and define the difference in the instance = docs.

I'll also offer a third resolut= ion:
3. Show me that the WG discussed this question and made = the decision to forbid holder-of-key assertions without an Audience paramet= er.

--Richard


=C2=A0
--Richard





<= /font>

On Thu, Oct 16, 2014 at 9:57 AM, = Phil Hunt <phil.hunt@oracle.com> wrote:
It is also important f= or a non-protocol purpose. Liability.

If a 3rd party use= s an assertion that was not intended for it, it cannot obviously hold the a= sserting party responsible. =C2=A0


On Oct 16, 2014, at 8:43 AM, Brian Campbell <bcampbell@pingidentity.c= om> wrote:

Thanks for your review and feedback, Richard.=20 Replies are inline below...

On Wed, Oct 15, 2014 at 9:47 PM, Richard Barnes <rlb@ipv.s= x> wrote:
http://www.ietf.org/iesg/statement/discuss-crit= eria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions= /



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

"The assertion MUST contain an Audience that identifies the Authorizat= ion
Server as the intended audience.=C2=A0 Assertions that do not identify the<= br> Authorization Server as an intended audience MUST be rejected."

Could you please identify the threat model within which this "MUST&quo= t; is
required?=C2=A0 This requirement doesn't follow from any of the threats=
elaborated in Section 8.

The Audience is only necessary if the Issuer wishes to constrain the set of Authorization Servers with which an assertion may be used.=C2=A0 So ISTM=
that this should be "MAY contain..."



The audience restriction let's= the issuer say specifically what=20 relying party is allowed to consume the assertion, which ensures that=20 the client can't use it somewhere else that it wasn't intended and = that the=20 relying party that receives the assertion can't turn around and use it= =20 to access some other service.

Strictly speaking,= you are right that the audience is only necessary if the Issuer wishes to = constrain the set of Authorization Servers with which an assertion may be u= sed. But the Issuer really really really should make that constraint and fu= lly understanding the implications of not doing so is difficult and unlikel= y.

There was a vulnerability in Google apps SAML a few y= ears back that demonstrates how important audience restriction is and= how it can be difficult for even very sophisticated providers to get it al= l right. I haven't had time to read it again to make sure but I think t= hat this is the paper http://www.ai-lab.it/armando/pub/fmse9-armando.= pdf

I don't see what value allowing = audience to be omitted brings other than that it is academically a possibil= ity. But requiring it (hopefully, if the requirement is followed) helps red= uce the possibility of a whole bunch of security problems that folks likely= won't foresee.

=C2=A0
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

"keyed message digest" -> "Message Authentication Code&qu= ot;

That's the proper terminology [RFC4949], especially since there are MAC= s
that are not based on digests.

OK
=C2=A0

"This mechanism provides additional security properties." -- Plea= se
delete this or elaborate on what security properties it provides.

Will delete.
=C2=A0

Section 8.2 should note that "Holder-of-Key Assertions" are also = a
mitigation for this risk.


OK
=C2=A0
=C2= =A0
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

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



--001a11c21538f701bf05059319b7-- From nobody Thu Oct 16 17:54:34 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1C4C1A900A for ; Thu, 16 Oct 2014 17:54: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kp9fv8RfrxA9 for ; Thu, 16 Oct 2014 17:54:27 -0700 (PDT) Received: from mail-qc0-f178.google.com (mail-qc0-f178.google.com [209.85.216.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D34D51A89C6 for ; Thu, 16 Oct 2014 17:54:26 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id c9so3711984qcz.23 for ; Thu, 16 Oct 2014 17:54:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=r9BDvycjsE2B7vrf3LprZdO/g3fwnOEauaQFiG3ovbU=; b=bfU6skIcOeajAl6jDThp3iqMq9aKiNLug55lH4AwUkJILzzMKonSzsOqNKiiVX7xhj cdy2r0TJxCzC9osSYotj3UFzdDqcs1Kau+kGuvyAIglYCFms4rpY9ywqJNV0H+fMy9g+ OZ4jzGxhZw4PZSDvyk6hia5eEcSwugb2oT8KUK1vYtK8PQyy7Mv0EOpy3oX+Kke1lS8P c6QNTI+kOEqs70KA8ci4j31Fmi99kpfk+5Vv6zo5cYEv2elVeRWhaFCq66v/ejdCn5Vg lNLLxA8ej6FO4rDoQDtVGnhPHEIKBcaPM2af7QYod4UlfVWpHVI2G+qqaW0klnpL1NuS LfJA== X-Gm-Message-State: ALoCoQlUChgPDcSJ8uC4FB8fv5KZo1G2f6ENUq7JsItHr+pV9yLc26cpSpGS57TEMwxi8fcVnRxh X-Received: by 10.224.167.137 with SMTP id q9mr7606080qay.40.1413507265816; Thu, 16 Oct 2014 17:54:25 -0700 (PDT) Received: from [192.168.8.102] ([201.188.31.214]) by mx.google.com with ESMTPSA id w9sm17561764qaw.9.2014.10.16.17.54.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 16 Oct 2014 17:54:25 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_8DF1C019-5454-4888-893E-2D674FCE7606" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Bradley In-Reply-To: Date: Thu, 16 Oct 2014 21:54:26 -0300 Message-Id: <28A05FEA-9EEA-4E95-9B9F-587120A74BAA@ve7jtb.com> References: <20141016034735.18695.61014.idtracker@ietfa.amsl.com> To: Richard Barnes X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/koCqVekYGqapyPIAqJDJX-D1GTU Cc: "draft-ietf-oauth-assertions@tools.ietf.org" , "oauth-chairs@tools.ietf.org" , oauth , The IESG Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 00:54:31 -0000 --Apple-Mail=_8DF1C019-5454-4888-893E-2D674FCE7606 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Holder of key JWT is still in draft and we don't have a clear way to = present the proof to the token endpoint. Brian and I started discussing that last week as I happen to have a use = case for a PoP JWT assertion flow in some other spec work. I think that there is enough difference between bearer and PoP that = doing a follow on profile for SAML and JWT that can also cover the proof = presentment mechanisms makes the most sense. I would go with restricting this to Bearer and MUST for audience, and = removing the audience requirement explicitly in the PoP profiles. There are people who need the bearer version 6 months ago, I don't want = to do anything to hold it up based on future work. I am happy to help with a SAML PoP/HoK draft as a follow on. The SAML = subject confirmation stuff is relatively clear so it is mostly defining = the presentment mechanisms like mutual TLS and a self signed assertion. = (we need to be careful not to conflate client authentication and token = proof, as they are different and might both be used at the same time. John B. On Oct 16, 2014, at 7:20 PM, Richard Barnes wrote: > You guys are all arguing that having an Audience can be useful. I = don't disagree. I disagree that it should be REQUIRED in all cases. >=20 > The Google vulnerability that Brian raised was an interesting read, = but as John points out, it only applies to Bearer Assertions. There's = no security requirement at all for holder-of-key assertions to have an = audience, since they can't be replayed by someone who doesn't hold the = key. >=20 > I could agree that an audience should be REQUIRED for bearer = assertions. Since they are vulnerable to replay, Audience protects = against the Authorization Server re-using the token. (It would be good = to say this explicitly in the doc, actually.) But for holder-of-key = assertions, the Audience should be OPTIONAL. Note that this requires = that instance documents define the difference between bearer assertions = and holder-of-key assertions, so that implementations can enforce these = requirements. >=20 > So it seems like there are two solutions here: > 1. Scope the document to bearer assertions only, and keep the MUST > 2. Keep the current scope, make Audience OPTIONAL for holder-of-key = assertions, and define the difference in the instance docs. >=20 > --Richard >=20 >=20 >=20 >=20 >=20 >=20 > On Thu, Oct 16, 2014 at 9:57 AM, Phil Hunt = wrote: > It is also important for a non-protocol purpose. Liability. >=20 > If a 3rd party uses an assertion that was not intended for it, it = cannot obviously hold the asserting party responsible. =20 >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 > On Oct 16, 2014, at 8:43 AM, Brian Campbell = wrote: >=20 >> Thanks for your review and feedback, Richard. Replies are inline = below... >>=20 >> On Wed, Oct 15, 2014 at 9:47 PM, Richard Barnes wrote: >> Richard Barnes has entered the following ballot position for >> draft-ietf-oauth-assertions-17: Discuss >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut = this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to = http://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >>=20 >> "The assertion MUST contain an Audience that identifies the = Authorization >> Server as the intended audience. Assertions that do not identify the >> Authorization Server as an intended audience MUST be rejected." >>=20 >> Could you please identify the threat model within which this "MUST" = is >> required? This requirement doesn't follow from any of the threats >> elaborated in Section 8. >>=20 >> The Audience is only necessary if the Issuer wishes to constrain the = set >> of Authorization Servers with which an assertion may be used. So = ISTM >> that this should be "MAY contain..." >>=20 >>=20 >>=20 >> The audience restriction let's the issuer say specifically what = relying party is allowed to consume the assertion, which ensures that = the client can't use it somewhere else that it wasn't intended and that = the relying party that receives the assertion can't turn around and use = it to access some other service. >>=20 >> Strictly speaking, you are right that the audience is only necessary = if the Issuer wishes to constrain the set of Authorization Servers with = which an assertion may be used. But the Issuer really really really = should make that constraint and fully understanding the implications of = not doing so is difficult and unlikely.=20 >>=20 >> There was a vulnerability in Google apps SAML a few years back that = demonstrates how important audience restriction is and how it can be = difficult for even very sophisticated providers to get it all right. I = haven't had time to read it again to make sure but I think that this is = the paper http://www.ai-lab.it/armando/pub/fmse9-armando.pdf >>=20 >> I don't see what value allowing audience to be omitted brings other = than that it is academically a possibility. But requiring it (hopefully, = if the requirement is followed) helps reduce the possibility of a whole = bunch of security problems that folks likely won't foresee. >>=20 >> =20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> "keyed message digest" -> "Message Authentication Code" >>=20 >> That's the proper terminology [RFC4949], especially since there are = MACs >> that are not based on digests. >>=20 >> OK >> =20 >>=20 >> "This mechanism provides additional security properties." -- Please >> delete this or elaborate on what security properties it provides. >>=20 >> Will delete. >> =20 >>=20 >> Section 8.2 should note that "Holder-of-Key Assertions" are also a >> mitigation for this risk. >>=20 >>=20 >> OK >> =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 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_8DF1C019-5454-4888-893E-2D674FCE7606 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Holder = of key JWT is still in draft and we don't have a clear way to present = the proof to the token endpoint.

Brian and I started = discussing that last week as I happen to have a use case for a PoP JWT = assertion flow in some other spec work.

I think = that there is enough difference between bearer and PoP that doing a = follow on profile for SAML and JWT that can also cover the proof = presentment mechanisms makes the most sense.

I = would go with restricting this to Bearer and MUST for audience, =  and removing the audience requirement explicitly in the PoP = profiles.

There are people who need the bearer = version 6 months ago,  I don't want to do anything to hold it up = based on future work.

I am happy to help with a = SAML PoP/HoK draft as a follow on.   The SAML subject confirmation = stuff is relatively clear so it is mostly defining the presentment = mechanisms like mutual TLS and a self signed assertion. (we need to be = careful not to conflate client authentication and token proof, as they = are different and might both be used at the same = time.

John B.

On Oct = 16, 2014, at 7:20 PM, Richard Barnes <rlb@ipv.sx> wrote:

You guys are all arguing that having an Audience can be = useful.  I don't disagree.  I disagree that it should be = REQUIRED in all cases.

The Google vulnerability that = Brian raised was an interesting read, but as John points out, it only = applies to Bearer Assertions.  There's no security requirement at = all for holder-of-key assertions to have an audience, since they can't = be replayed by someone who doesn't hold the key.

I = could agree that an audience should be REQUIRED for bearer = assertions.  Since they are vulnerable to replay, Audience protects = against the Authorization Server re-using the token.  (It would be = good to say this explicitly in the doc, actually.)  But for = holder-of-key assertions, the Audience should be OPTIONAL.  Note = that this requires that instance documents define the difference between = bearer assertions and holder-of-key assertions, so that implementations = can enforce these requirements.

So it seems like there = are two solutions here:
1. Scope the document to bearer = assertions only, and keep the MUST
2. Keep the current = scope, make Audience OPTIONAL for holder-of-key assertions, and define = the difference in the instance = docs.

--Richard





On Thu, Oct 16, 2014 at 9:57 AM, Phil Hunt <phil.hunt@oracle.com> = wrote:
It is also important for a non-protocol = purpose. Liability.

If a 3rd party uses an assertion = that was not intended for it, it cannot obviously hold the asserting = party responsible.  


On Oct 16, 2014, at 8:43 AM, Brian Campbell <bcampbell@pingidentity.com> = wrote:

Thanks for your review and feedback, Richard.=20= Replies are inline below...

On Wed, Oct 15, = 2014 at 9:47 PM, Richard Barnes <rlb@ipv.sx> = wrote:
Richard = Barnes has entered the following ballot position for
draft-ietf-oauth-assertions-17: Discuss

When responding, please keep the subject line intact and reply to = all
email addresses included in the To and CC lines. (Feel free to cut = this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html=
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-oauth-asserti= ons/



= ----------------------------------------------------------------------
= DISCUSS:
= ----------------------------------------------------------------------
=
"The assertion MUST contain an Audience that identifies the = Authorization
Server as the intended audience.  Assertions that do not identify = the
Authorization Server as an intended audience MUST be rejected."

Could you please identify the threat model within which this "MUST" = is
required?  This requirement doesn't follow from any of the = threats
elaborated in Section 8.

The Audience is only necessary if the Issuer wishes to constrain the = set
of Authorization Servers with which an assertion may be used.  So = ISTM
that this should be "MAY contain..."



The audience restriction let's = the issuer say specifically what=20 relying party is allowed to consume the assertion, which ensures that=20 the client can't use it somewhere else that it wasn't intended and that = the=20 relying party that receives the assertion can't turn around and use it=20= to access some other service.

Strictly = speaking, you are right that the audience is only necessary if the = Issuer wishes to constrain the set of Authorization Servers with which = an assertion may be used. But the Issuer really really really should = make that constraint and fully understanding the implications of not = doing so is difficult and unlikely.

There was a = vulnerability in Google apps SAML a few years back that demonstrates how = important audience restriction is and how it can be difficult for = even very sophisticated providers to get it all right. I haven't had = time to read it again to make sure but I think that this is the paper http://www.ai-lab.it/armando/pub/fmse9-armando.pdf
I don't see what value allowing audience = to be omitted brings other than that it is academically a possibility. = But requiring it (hopefully, if the requirement is followed) helps = reduce the possibility of a whole bunch of security problems that folks = likely won't foresee.

 
= ----------------------------------------------------------------------
= COMMENT:
= ----------------------------------------------------------------------
=
"keyed message digest" -> "Message Authentication Code"

That's the proper terminology [RFC4949], especially since there are = MACs
that are not based on = digests.

OK
 
=

"This mechanism provides additional security properties." -- Please
delete this or elaborate on what security properties it = provides.

Will = delete.
 

Section 8.2 should note that "Holder-of-Key Assertions" are also a
mitigation for this risk.
=

OK
 
&nb= sp;
_______________________________________________
OAuth mailing list
OAuth@ietf.org
= https://www.ietf.org/mailman/listinfo/oauth

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


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

= --Apple-Mail=_8DF1C019-5454-4888-893E-2D674FCE7606-- From nobody Thu Oct 16 18:12:40 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58FA91A8991 for ; Thu, 16 Oct 2014 18:12:28 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dzkWZZXwfyAg for ; Thu, 16 Oct 2014 18:12:24 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 200C51A8789 for ; Thu, 16 Oct 2014 18:12:23 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id k15so3144459qaq.24 for ; Thu, 16 Oct 2014 18:12:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=400oXttHkm1tR53qd5OiEppBt7o0pUbK0EyauyQp8Vk=; b=ckoF6KQZgI45SvhP9rPfz1qNgCXpUysQiNNn4k5MeO8CGg1C6FkBwzNws/skTkKied 3Mh9qxAin01PN6GrIJb44iAPWOpXX9QQCVjch2cWpoNHZTRSyH8XT8k7gyX/dse4kg+T aT0BK3GTTfWaObyOpzIrZTx3CNNe3ys1jG1SrQWkPq1Yd/enmEQ631CcDuALyC0oDveP NKV57emx3e1BQLbLddKGztQwl3cnnsxE0E80GSpVco/5Qgl811fyChNRacVBNL52fwJk rwx/E9s1h1uuSy4c+tkTLvDld+ijzm8f4nF1J5pCAhoPYqCx/5jvllUePNDUU++y8Mpq E0Ww== X-Gm-Message-State: ALoCoQl/lI4gT9UbPXnUH2/6Xs37FtP4RYcqGsxbJ11Uh4Y654lpiE5/ImYRQMiiDLe8bUo0LIMl X-Received: by 10.140.107.11 with SMTP id g11mr7273250qgf.38.1413508343192; Thu, 16 Oct 2014 18:12:23 -0700 (PDT) Received: from [192.168.8.102] ([201.188.31.214]) by mx.google.com with ESMTPSA id w8sm22847227qag.2.2014.10.16.18.12.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 16 Oct 2014 18:12:22 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_1A424898-98D7-420A-9569-B878CA77E8AA" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Bradley In-Reply-To: Date: Thu, 16 Oct 2014 22:12:24 -0300 Message-Id: <30D1F2BF-26E1-42FA-89DC-AED2A6A66672@ve7jtb.com> References: <20141016040122.32277.7067.idtracker@ietfa.amsl.com> To: Richard Barnes X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/AHapdvXeB1DgSB5P9UGrAA9bbIc Cc: "oauth-chairs@tools.ietf.org" , draft-ietf-oauth-jwt-bearer@tools.ietf.org, oauth , The IESG Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-jwt-bearer-10: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 01:12:28 -0000 --Apple-Mail=_1A424898-98D7-420A-9569-B878CA77E8AA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii It was discussed. As I recall it was decided that like SAML it is the = responsibility of the protocol using OAuth to define it's naming = convention for entities. In Connect Section 9. we chose to use the URI of the token_endpoint, but = we debated using the logical "iss" identifier for the Authorization = server.=20 There is a argument for using Named vs locations tying a logical name to = a protocol endpoint URI may not always make sense. =20 SAML typically uses entityID as a logical name allowing for endpoints to = be reconfigured without breaking deployments in mysterious ways. Saying that it must always be the uri of the token endpoint may be to = inflexible, though that is the easy answer most of the time. John B. On Oct 16, 2014, at 7:32 PM, Richard Barnes wrote: >=20 >=20 > On Thu, Oct 16, 2014 at 1:44 PM, Brian Campbell = wrote: > Thanks for your review and feedback on this one too, Richard. Replies = are inline below... >=20 > On Wed, Oct 15, 2014 at 10:01 PM, Richard Barnes wrote: > Richard Barnes has entered the following ballot position for > draft-ietf-oauth-jwt-bearer-10: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > As with draft-ietf-oauth-assertions, the requirement for an "aud" = claim > seems entirely unnecessary. Holding this DISCUSS point pending that > discussion > and its reflection in this document. >=20 > "Assertions that do not identify the Authorization Server as an = intended > audience MUST be rejected." -- What does it mean for an assertion to > "identify > the Authorization Server"? Does the specified need to = match > the > entire URL of the relevant OAuth endpoint? Just the origin? Just the > domain? > Does the URL need to be canonicalized? >=20 >=20 >=20 > No c14n, as it says, "... compare the audience values using the = Simple String Comparison method defined in Section 6.2.1 of RFC 3986."=20= >=20 > Basically the AS is at liberty to determine how it identifies itself. = Some guidance on using the token endpoint is provided but it's = ultimately up to the AS (or the larger deployment in which the AS = exists). The acceptable value is one of a few bits of information that = must be exchanged for this profile, which is discussed in the = Interoperability Considerations = https://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-10#section-5 >=20 > Sigh. "Negotiate it out of band" is a terrible, non-scalable, = not-in-the-spirit-of-the-Internet answer. But I guess I might clear on = this if you could add something like the following: > "As noted in Section 5 of [I-D.ietf-oauth-jwt-bearer], the precise = strings to be used as the Audience for a given Authorization Server must = be configured out-of-band by the Authorization Server and the Issuer of = the assertion." >=20 > But is there seriously no answer that the WG could agree on? This = seems like it should be a pretty simple question. Was it even = discussed? >=20 > --Richard >=20 > =20 > Some more explanation/discussion of it is in the middle(ish) of this = reply to a similar comment from Stephen = Farrellhttp://www.ietf.org/mail-archive/web/oauth/current/msg13605.html=20= >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > "keyed message digest" -> "MAC" >=20 > Yep. > =20 >=20 > Both this and the SAML document could save a lot of bits by just being > subsections of the -assertions document. >=20 > The structure and relationship of the documents was decided on by the = WG nearly three years ago. There is some duplication but it's believed = to be more approachable this way - particularly for those implementing = just one assertion type. >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_1A424898-98D7-420A-9569-B878CA77E8AA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii It was = discussed.   As I recall it was decided that like SAML it is the = responsibility of the protocol using OAuth to define it's naming = convention for entities.

In Connect Section 9. we chose to use the URI of the token_endpoint, but = we debated using the logical "iss" identifier for the Authorization = server. 

There is a argument for using = Named vs locations tying a logical name to a protocol endpoint URI may = not always make sense.  

SAML typically = uses entityID as a logical name allowing for endpoints to be = reconfigured without breaking deployments in mysterious = ways.

Saying that it must always be the uri of = the token endpoint may be to inflexible,  though that is the easy = answer most of the time.

John = B.

On Oct 16, 2014, at 7:32 PM, Richard Barnes = <rlb@ipv.sx> wrote:



On Thu, Oct 16, 2014 at 1:44 PM, Brian = Campbell <bcampbell@pingidentity.com> wrote:
Thanks for your review and = feedback on this one too, Richard. Replies are inline below...

On Wed, Oct 15, 2014 at 10:01 PM, Richard Barnes <rlb@ipv.sx> wrote:
Richard Barnes has entered the = following ballot position for
draft-ietf-oauth-jwt-bearer-10: = Discuss

When responding, please keep the subject line intact and = reply to all
email addresses included in the To and CC lines. (Feel = free to cut this
introductory paragraph, however.)


Please = refer to http://www.ietf.org/iesg/statement/discuss-criteria.html=
for more information about IESG DISCUSS and COMMENT = positions.


The document, along with other ballot positions, = can be found here:
http://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bea= rer/



--------------------------------------------------= --------------------
DISCUSS:
--------------------------------------= --------------------------------

As with = draft-ietf-oauth-assertions, the requirement for an "aud" claim
seems = entirely unnecessary.  Holding this DISCUSS point pending = that
discussion
and its reflection in this = document.

"Assertions that do not identify the Authorization = Server as an intended
audience MUST be rejected." -- What does it = mean for an assertion to
"identify
the Authorization = Server"?  Does the specified <Audience> need to = match
the
entire URL of the relevant OAuth endpoint?  Just = the origin?  Just the
domain?
Does the URL need to be = canonicalized?



No = c14n, as it says, "...  compare the audience values using the = Simple String Comparison method defined in Section 6.2.1 of RFC = 3986." 

Basically = the AS is at liberty to determine how it identifies itself. Some = guidance on using the token endpoint is provided but it's ultimately up = to the AS (or the larger deployment in which the AS exists). The = acceptable value is one of a few bits of information that must be = exchanged for this profile, which is discussed in the Interoperability = Considerations https://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-= 10#section-5

Sigh.  "Negotiate it out of band" is a terrible, non-scalable, = not-in-the-spirit-of-the-Internet answer.  But I guess I might = clear on this if you could add something like the = following:
"As noted in Section 5 of = [I-D.ietf-oauth-jwt-bearer], the precise strings to be used as the = Audience for a given Authorization Server must be configured out-of-band = by the Authorization Server and the Issuer of the = assertion."

But is there seriously no answer that the = WG could agree on?  This seems like it should be a pretty simple = question.  Was it even = discussed?

--Richard

 
Some more = explanation/discussion of it is in the middle(ish) of this reply to a = similar comment from Stephen Farrellhttp://www.ietf.org/mail-archive/web/oauth/current/msg13= 605.html 



----------------------------------------------------------------= ------
COMMENT:
----------------------------------------------------= ------------------

"keyed message digest" -> = "MAC"

Yep.
 

Both this and the SAML document could save a lot = of bits by just being
subsections of the -assertions = document.

The structure and = relationship of the documents was decided on by the WG nearly three = years ago. There is some duplication but it's believed to be more = approachable this way - particularly for those implementing just one = assertion = type.

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth
= --Apple-Mail=_1A424898-98D7-420A-9569-B878CA77E8AA-- From nobody Fri Oct 17 05:25:58 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD321ACD35 for ; Fri, 17 Oct 2014 05:25:57 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJUAJ9YxkB9e for ; Fri, 17 Oct 2014 05:25:55 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F27D1ACD34 for ; Fri, 17 Oct 2014 05:25:54 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id gi9so586099lab.5 for ; Fri, 17 Oct 2014 05:25:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=VjVoS6Tuzn626v0722ph8hYo58pgPJdMZT4TrAIn5SE=; b=bJsjnTt+7Eg5NAIW/US/qA2exJ8QcSntfJDPT/txq3wqWu/GBTgzcB5/Jmy3wWdgcR vkrv/l9tb/qeyjjqYIsuVT3FnoQl5Q1sWD/Cg3XoGc6BcCTqkUwyND1kzV+tS09li4qU Bck0ODV9ZHwke0m0px+Ud9a5J9Q2vi0jeADLEbSEert3PgncV6Fp3z6GUYXbrSS1gu5e /1v3baQGxIG8lYF3N9JMy4gs/sjm2bRBYzSxNk3o2QLv9vCNBffRsnP0vA7V//O6EhDS SJfyNkkU8es7zLtsIwAhrHZnkd/NtK2j0u2YT7UmWFPRqFtdGbMdOmnlovXsoeddurt8 JqLg== X-Received: by 10.152.216.167 with SMTP id or7mr2811233lac.93.1413548753149; Fri, 17 Oct 2014 05:25:53 -0700 (PDT) Received: from [10.36.226.2] ([80.169.137.63]) by mx.google.com with ESMTPSA id ki7sm393614lac.38.2014.10.17.05.25.51 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Oct 2014 05:25:52 -0700 (PDT) Message-ID: <54410ACE.5060303@gmail.com> Date: Fri, 17 Oct 2014 13:25:50 +0100 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: oauth@ietf.org References: <543FF850.6070409@gmx.net> In-Reply-To: <543FF850.6070409@gmx.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Jx7FDfKRnltIA_YQTcXClK8vVSA Subject: Re: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference Call X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 12:25:57 -0000 +1. I'm finding this write-up summarizing the "OAuth2 and Authentication" 'situation' perfectly. It does help. Minor suggestions/questions: - might make sense to point out that an id_token can be linked to the access token (via at_hash), thus confirming both tokens came from the same AS - should a 2-way TLS mentioned as a possible approach for mitigating the 'injection of the token' attack ? I guess it won't scale really well but IMHO it is a useful mechanism nonetheless - should a few words be reserved for the client credentials flow - this is of course not a mainstream OAuth2 nor its related to OIDC but it is all about the authentication IMHO, the clients get their tokens by simply getting authenticated, and as far as legacy (code) clients are concerned they 'migrate' from sending the name/password to the resource endpoint on every request ? - IMHO it would be useful to mention that OIDC RP can help non-OAuth2 servers, i.e one does not have to write an OAuth2 client web application to get the benefits of the OIDC-driven auhentication Thanks, Sergey On 16/10/14 17:54, Hannes Tschofenig wrote: > Participants: > > * Brian Campbell > * John Bradley > * Derek Atkins > * Phil Hunt > * William Kim > * Josh Mandel > * Hannes Tschofenig > > > Notes: > > Justin distributed a draft writeup and explained the reasoning behind > it. The intended purpose is to put the write-up (after enough review) on > oauth.net. See attachments. Justin solicited feedback from the > conference call participants and from the working group. > > One discussion item was specifically related to the concept of audience > restrictions, which comes in two flavours: (a) restriction of the access > token regarding the resource server and (b) restriction of the id token > regarding the client. Obviously, it is necessary to have both of these > audience restrictions in place and to actually check them. > > The group then went into a discussion about the use of pseudonyms in > authentication and the problems deployments ran into when they used > pseudonyms together with a wide range of attributes that identified > users nevertheless. Phil suggested to produce a write-up about this topic. > > Finally, the group started a discussion about potential actions for the > OAuth working groups. Two activities were mentioned, namely to produce > an IETF draft of the write-up Justin has prepared as a "formal" response > to the problems with authentication using OAuth and, as a second topic, > potential re-chartering of the OAuth working group to work on some > solutions in this area. Hannes suggested to postpone these discussions > and to first finish the write-up Justin had distributed. > > Ciao > Hannes & Derek > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From nobody Fri Oct 17 06:33:36 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E5AD1ACD96 for ; Fri, 17 Oct 2014 06:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lic3Y1obgLRh for ; Fri, 17 Oct 2014 06:33:26 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id C0AD01ACD1D for ; Fri, 17 Oct 2014 06:33:26 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 5D3CE72E17F; Fri, 17 Oct 2014 09:33:26 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id 52F7C72E17D; Fri, 17 Oct 2014 09:33:26 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.78]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.03.0174.001; Fri, 17 Oct 2014 09:33:26 -0400 From: "Richer, Justin P." To: Sergey Beryozkin Thread-Topic: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference Call Thread-Index: AQHP6g7t82pa7yV3YUG5qBwwuM9T2A== Date: Fri, 17 Oct 2014 13:33:25 +0000 Message-ID: <34A03788-A992-47E7-863A-8F1648ADF3B4@mitre.org> References: <543FF850.6070409@gmx.net> <54410ACE.5060303@gmail.com> In-Reply-To: <54410ACE.5060303@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.15.56] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/hZZeWxjBT2uLFta8JyyG3xKhSfA Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference Call X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 13:33:29 -0000 On Oct 17, 2014, at 8:25 AM, Sergey Beryozkin wrote: > +1. I'm finding this write-up summarizing the "OAuth2 and Authentication"= 'situation' perfectly. It does help. >=20 > Minor suggestions/questions: > - might make sense to point out that an id_token can be linked to the acc= ess token (via at_hash), thus confirming both tokens came from the same AS Seems a reasonable point, I can add that. > - should a 2-way TLS mentioned as a possible approach for mitigating the = 'injection of the token' attack ? I guess it won't scale really well but IM= HO it is a useful mechanism nonetheless It doesn't actually help in this case, since if the client is checking the = server's certs that should be OK (or as OK as TLS can get). The real attack= comes from someone handing the token to an application through a mechanism= other than the return from the token endpoint, and I've seen a handful of = applications that pass around the access token to themselves through inter= nal callback mechanisms that are a bit more exposed than they ought to be.= =20 > - should a few words be reserved for the client credentials flow - this i= s of course not a mainstream OAuth2 nor its related to OIDC but it is all a= bout the authentication IMHO, the clients get their tokens by simply gettin= g authenticated, and as far as legacy (code) clients are concerned they 'mi= grate' from sending the name/password to the resource endpoint on every req= uest ? The client credentials flow has nothing to do with user authentication, whi= ch is why it's left out of OIDC. There might not even be a user in this flo= w (and it's generally assumed that there isn't). > - IMHO it would be useful to mention that OIDC RP can help non-OAuth2 ser= vers, i.e one does not have to write an OAuth2 client web application to ge= t the benefits of the OIDC-driven authentication I don't understand what you're saying here. In order to make an OIDC RP, yo= u need to write an OAuth2 client. That's by design. -- Justin >=20 > Thanks, Sergey > On 16/10/14 17:54, Hannes Tschofenig wrote: >> Participants: >>=20 >> * Brian Campbell >> * John Bradley >> * Derek Atkins >> * Phil Hunt >> * William Kim >> * Josh Mandel >> * Hannes Tschofenig >>=20 >>=20 >> Notes: >>=20 >> Justin distributed a draft writeup and explained the reasoning behind >> it. The intended purpose is to put the write-up (after enough review) on >> oauth.net. See attachments. Justin solicited feedback from the >> conference call participants and from the working group. >>=20 >> One discussion item was specifically related to the concept of audience >> restrictions, which comes in two flavours: (a) restriction of the access >> token regarding the resource server and (b) restriction of the id token >> regarding the client. Obviously, it is necessary to have both of these >> audience restrictions in place and to actually check them. >>=20 >> The group then went into a discussion about the use of pseudonyms in >> authentication and the problems deployments ran into when they used >> pseudonyms together with a wide range of attributes that identified >> users nevertheless. Phil suggested to produce a write-up about this topi= c. >>=20 >> Finally, the group started a discussion about potential actions for the >> OAuth working groups. Two activities were mentioned, namely to produce >> an IETF draft of the write-up Justin has prepared as a "formal" response >> to the problems with authentication using OAuth and, as a second topic, >> potential re-chartering of the OAuth working group to work on some >> solutions in this area. Hannes suggested to postpone these discussions >> and to first finish the write-up Justin had distributed. >>=20 >> Ciao >> Hannes & Derek >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Fri Oct 17 06:51:41 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BB4E1ACE09 for ; Fri, 17 Oct 2014 06:51: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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id har0KZChe-gu for ; Fri, 17 Oct 2014 06:51:35 -0700 (PDT) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AEE11ACE05 for ; Fri, 17 Oct 2014 06:51:35 -0700 (PDT) Received: by mail-lb0-f175.google.com with SMTP id u10so697704lbd.20 for ; Fri, 17 Oct 2014 06:51:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=GGjTHw2ggPEk9ne3tu4NXVmUEMTd8wqGjZ5QN99+NWA=; b=jYy/8t167vkLVJb6NR5SDAYDiQYd/4h47p01Xo727e6Nco30sN8gQ5AN1SfOOeEFSN +NBzqogZxX23DaU/VRYORlnc284sY3thpWu+LWRqCX40MDJZXUe1UXlbyyDRCqaLm0rW dx+Bf7OEZwi6Sv/YeldWY7xJAq9ZI2I54Bl4aJISMdU8NPop/PzfqFaodC0ZF2Ge9mM3 gFQDoObnRc9Mr0MTcX2xSMvM+AzlCjA0WO/3kWnU3gK8R6ZAHpPgNYf3veJUgrihWgCF 4CAi573m7nDwi0sUVUabZJwDXG78v3Yo/MOUcwFSNx4sLazZG4CfK5YpVMtKlsK4gWFi URSw== X-Received: by 10.152.2.41 with SMTP id 9mr8752418lar.47.1413553893599; Fri, 17 Oct 2014 06:51:33 -0700 (PDT) Received: from [10.36.226.2] ([80.169.137.63]) by mx.google.com with ESMTPSA id k3sm461840lam.33.2014.10.17.06.51.32 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Oct 2014 06:51:33 -0700 (PDT) Message-ID: <54411EE4.2080405@gmail.com> Date: Fri, 17 Oct 2014 14:51:32 +0100 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "Richer, Justin P." References: <543FF850.6070409@gmx.net> <54410ACE.5060303@gmail.com> <34A03788-A992-47E7-863A-8F1648ADF3B4@mitre.org> In-Reply-To: <34A03788-A992-47E7-863A-8F1648ADF3B4@mitre.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/8rt3ahNNdfmxI1ixqMQS3K257C0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference Call X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 13:51:39 -0000 Hi, On 17/10/14 14:33, Richer, Justin P. wrote: > On Oct 17, 2014, at 8:25 AM, Sergey Beryozkin wrote: > >> +1. I'm finding this write-up summarizing the "OAuth2 and Authentication" 'situation' perfectly. It does help. >> >> Minor suggestions/questions: >> - might make sense to point out that an id_token can be linked to the access token (via at_hash), thus confirming both tokens came from the same AS > > Seems a reasonable point, I can add that. > >> - should a 2-way TLS mentioned as a possible approach for mitigating the 'injection of the token' attack ? I guess it won't scale really well but IMHO it is a useful mechanism nonetheless > > It doesn't actually help in this case, since if the client is checking the server's certs that should be OK (or as OK as TLS can get). The real attack comes from someone handing the token to an application through a mechanism other than the return from the token endpoint, and I've seen a handful of applications that pass around the access token to themselves through internal callback mechanisms that are a bit more exposed than they ought to be. > OK, I understand >> - should a few words be reserved for the client credentials flow - this is of course not a mainstream OAuth2 nor its related to OIDC but it is all about the authentication IMHO, the clients get their tokens by simply getting authenticated, and as far as legacy (code) clients are concerned they 'migrate' from sending the name/password to the resource endpoint on every request ? > > The client credentials flow has nothing to do with user authentication, which is why it's left out of OIDC. There might not even be a user in this flow (and it's generally assumed that there isn't). > Yes, it is not part of OIDC but it is still the authentication of the client that is effectively a resource owner, no human user is involved but IMHO it's still very much the authentication. Exactly what the coded clients do today in non OAuth2 client-server communications, except that in this case the name/password is offered only once to AS. May be it was not what this flow was envisaged for originally but I do like it for the reasons outlined above, specifically it can help the legacy/traditional clients to 'join' the OAuth2 AS infrastucture >> - IMHO it would be useful to mention that OIDC RP can help non-OAuth2 servers, i.e one does not have to write an OAuth2 client web application to get the benefits of the OIDC-driven authentication > > I don't understand what you're saying here. In order to make an OIDC RP, you need to write an OAuth2 client. That's by design. OIDC RP is a client. But this RP doe snot have to be collocated with the OAuth2 client which actually does some application specific work, right ? I.e OIDC RP facilitates the OAuth2-based authentication mechanism but the server 'protected' by this RP which would work with the authenticated user does not have to be OAuth2 client, do you agree ? If OIDC RP could only be used alongside OAuth2 clients then it would limit its usefulness IMHO Cheers, Sergey > > -- Justin > >> >> Thanks, Sergey >> On 16/10/14 17:54, Hannes Tschofenig wrote: >>> Participants: >>> >>> * Brian Campbell >>> * John Bradley >>> * Derek Atkins >>> * Phil Hunt >>> * William Kim >>> * Josh Mandel >>> * Hannes Tschofenig >>> >>> >>> Notes: >>> >>> Justin distributed a draft writeup and explained the reasoning behind >>> it. The intended purpose is to put the write-up (after enough review) on >>> oauth.net. See attachments. Justin solicited feedback from the >>> conference call participants and from the working group. >>> >>> One discussion item was specifically related to the concept of audience >>> restrictions, which comes in two flavours: (a) restriction of the access >>> token regarding the resource server and (b) restriction of the id token >>> regarding the client. Obviously, it is necessary to have both of these >>> audience restrictions in place and to actually check them. >>> >>> The group then went into a discussion about the use of pseudonyms in >>> authentication and the problems deployments ran into when they used >>> pseudonyms together with a wide range of attributes that identified >>> users nevertheless. Phil suggested to produce a write-up about this topic. >>> >>> Finally, the group started a discussion about potential actions for the >>> OAuth working groups. Two activities were mentioned, namely to produce >>> an IETF draft of the write-up Justin has prepared as a "formal" response >>> to the problems with authentication using OAuth and, as a second topic, >>> potential re-chartering of the OAuth working group to work on some >>> solutions in this area. Hannes suggested to postpone these discussions >>> and to first finish the write-up Justin had distributed. >>> >>> Ciao >>> Hannes & Derek >>> >>> >>> >>> _______________________________________________ >>> 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 Fri Oct 17 07:10:03 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2865E1ACD7E for ; Fri, 17 Oct 2014 07:10:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bm0eQhjktpZJ for ; Fri, 17 Oct 2014 07:09:59 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id 0D2A91ACE0D for ; Fri, 17 Oct 2014 07:09:58 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 70033B2E8D4; Fri, 17 Oct 2014 10:09:58 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id 678A6B2E8CB; Fri, 17 Oct 2014 10:09:58 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.78]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.03.0174.001; Fri, 17 Oct 2014 10:09:57 -0400 From: "Richer, Justin P." To: Sergey Beryozkin Thread-Topic: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference Call Thread-Index: AQHP6g7t82pa7yV3YUG5qBwwuM9T2Jw0kdoAgAAFJAA= Date: Fri, 17 Oct 2014 14:09:56 +0000 Message-ID: References: <543FF850.6070409@gmx.net> <54410ACE.5060303@gmail.com> <34A03788-A992-47E7-863A-8F1648ADF3B4@mitre.org> <54411EE4.2080405@gmail.com> In-Reply-To: <54411EE4.2080405@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.15.56] Content-Type: text/plain; charset="Windows-1252" Content-ID: <4EA984A2A017BF4790DED1589EE56C25@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Z1ujyCBDFN7J0CF0uNUO5Cz1UeE Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference Call X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 14:10:02 -0000 >>> - should a few words be reserved for the client credentials flow - this= is of course not a mainstream OAuth2 nor its related to OIDC but it is all= about the authentication IMHO, the clients get their tokens by simply gett= ing authenticated, and as far as legacy (code) clients are concerned they '= migrate' from sending the name/password to the resource endpoint on every r= equest ? >>=20 >> The client credentials flow has nothing to do with user authentication, = which is why it's left out of OIDC. There might not even be a user in this = flow (and it's generally assumed that there isn't). >>=20 > Yes, it is not part of OIDC but it is still the authentication of the cli= ent that is effectively a resource owner, no human user is involved but IMH= O it's still very much the authentication. Exactly what the coded clients d= o today in non OAuth2 client-server communications, except that in this cas= e the name/password is offered only once to AS. > May be it was not what this flow was envisaged for originally but I do li= ke it for the reasons outlined above, specifically it can help the legacy/t= raditional clients to 'join' the OAuth2 AS infrastructure But it's not authentication of the *user*, which is the whole point. When t= he client authenticates on its own behalf, you have no idea who the user is= or if they exist. It's irrelevant to the user authentication flow. If you'= re looking for pulling legacy clients in, the "password" flow is better for= that, but OIDC didn't profile it because people really shouldn't be using = the password flow except in very limited use cases in the first place.=20 >=20 >>> - IMHO it would be useful to mention that OIDC RP can help non-OAuth2 s= ervers, i.e one does not have to write an OAuth2 client web application to = get the benefits of the OIDC-driven authentication >>=20 >> I don't understand what you're saying here. In order to make an OIDC RP,= you need to write an OAuth2 client. That's by design. > OIDC RP is a client. But this RP doe snot have to be collocated with the = OAuth2 client which actually does some application specific work, right ? > I.e OIDC RP facilitates the OAuth2-based authentication mechanism but the= server 'protected' by this RP which would work with the authenticated user= does not have to be OAuth2 client, do you agree ? > If OIDC RP could only be used alongside OAuth2 clients then it would limi= t its usefulness IMHO But the OIDC RP *is* an OAuth Client, so I still don't get what you're sayi= ng. Sure you can have OAuth clients that *aren't* OIDC clients, but you can= 't have an OIDC client that isn't also an OAuth client because OIDC is buil= t directly on top of OAuth. -- Justin >=20 > Cheers, Sergey >=20 >=20 >>=20 >> -- Justin >>=20 >>>=20 >>> Thanks, Sergey >>> On 16/10/14 17:54, Hannes Tschofenig wrote: >>>> Participants: >>>>=20 >>>> * Brian Campbell >>>> * John Bradley >>>> * Derek Atkins >>>> * Phil Hunt >>>> * William Kim >>>> * Josh Mandel >>>> * Hannes Tschofenig >>>>=20 >>>>=20 >>>> Notes: >>>>=20 >>>> Justin distributed a draft writeup and explained the reasoning behind >>>> it. The intended purpose is to put the write-up (after enough review) = on >>>> oauth.net. See attachments. Justin solicited feedback from the >>>> conference call participants and from the working group. >>>>=20 >>>> One discussion item was specifically related to the concept of audienc= e >>>> restrictions, which comes in two flavours: (a) restriction of the acce= ss >>>> token regarding the resource server and (b) restriction of the id toke= n >>>> regarding the client. Obviously, it is necessary to have both of these >>>> audience restrictions in place and to actually check them. >>>>=20 >>>> The group then went into a discussion about the use of pseudonyms in >>>> authentication and the problems deployments ran into when they used >>>> pseudonyms together with a wide range of attributes that identified >>>> users nevertheless. Phil suggested to produce a write-up about this to= pic. >>>>=20 >>>> Finally, the group started a discussion about potential actions for th= e >>>> OAuth working groups. Two activities were mentioned, namely to produce >>>> an IETF draft of the write-up Justin has prepared as a "formal" respon= se >>>> to the problems with authentication using OAuth and, as a second topic= , >>>> potential re-chartering of the OAuth working group to work on some >>>> solutions in this area. Hannes suggested to postpone these discussions >>>> and to first finish the write-up Justin had distributed. >>>>=20 >>>> Ciao >>>> Hannes & Derek >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 From nobody Fri Oct 17 07:58:13 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6ECC1A0149 for ; Fri, 17 Oct 2014 07:58: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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rIS5LMwa7alB for ; Fri, 17 Oct 2014 07:58:09 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DF1C1A038A for ; Fri, 17 Oct 2014 07:57:39 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id gi9so848220lab.19 for ; Fri, 17 Oct 2014 07:57:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=POM7NzJ0jwAUjjcXuGN3i24bzU5a77bgKNG8/Qsd35Y=; b=mbAMXsL1hqbvYmA2ZBslMri0713oBUSFADmfug+V8d1B8wyjermcvWlXMmGN9L9zQi 9MYgJWfbdddIFl1MEjv7s/gypby/MmtVn8xlqfb41mr8x/VfLM0pqeaPy7TGVYdTptuT mJvlKXjyLFsiCg7Byk55MkDX/tEhJELWnxZzHlTNo9k0D6gPZVFytRfp0t8g/FjJJhtB G1Iw1nApZzfft9XW6V96mSDUxa+okL0s+6NlyMBU90UJUfWIzULDgfn6UGXHfKijzxOi QTmS1dnyZRmGCwfGD0etb/j2BfpNrfE2Dn3P9a6Tr2XBrGbAmD9bbAdLckK9s8vosqvQ 8tYg== X-Received: by 10.112.16.101 with SMTP id f5mr9403272lbd.25.1413557858391; Fri, 17 Oct 2014 07:57:38 -0700 (PDT) Received: from [10.36.226.2] ([80.169.137.63]) by mx.google.com with ESMTPSA id or5sm507483lbb.42.2014.10.17.07.57.36 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Oct 2014 07:57:37 -0700 (PDT) Message-ID: <54412E5F.9000007@gmail.com> Date: Fri, 17 Oct 2014 15:57:35 +0100 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "Richer, Justin P." References: <543FF850.6070409@gmx.net> <54410ACE.5060303@gmail.com> <34A03788-A992-47E7-863A-8F1648ADF3B4@mitre.org> <54411EE4.2080405@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/5fyss9v6y6U6rYJrZYfZ7bG_ug8 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference Call X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 14:58:12 -0000 Hi, On 17/10/14 15:09, Richer, Justin P. wrote: >>>> - should a few words be reserved for the client credentials flow - this is of course not a mainstream OAuth2 nor its related to OIDC but it is all about the authentication IMHO, the clients get their tokens by simply getting authenticated, and as far as legacy (code) clients are concerned they 'migrate' from sending the name/password to the resource endpoint on every request ? >>> >>> The client credentials flow has nothing to do with user authentication, which is why it's left out of OIDC. There might not even be a user in this flow (and it's generally assumed that there isn't). >>> >> Yes, it is not part of OIDC but it is still the authentication of the client that is effectively a resource owner, no human user is involved but IMHO it's still very much the authentication. Exactly what the coded clients do today in non OAuth2 client-server communications, except that in this case the name/password is offered only once to AS. >> May be it was not what this flow was envisaged for originally but I do like it for the reasons outlined above, specifically it can help the legacy/traditional clients to 'join' the OAuth2 AS infrastructure > > But it's not authentication of the *user*, which is the whole point. When the client authenticates on its own behalf, you have no idea who the user is or if they exist. It's irrelevant to the user authentication flow. If you're looking for pulling legacy clients in, the "password" flow is better for that, but OIDC didn't profile it because people really shouldn't be using the password flow except in very limited use cases in the first place. I did get that. See the notes are about "OAuth2 & Authentication", so I thought it would not only be about the human user being authenticated via OIDC. OAuth2 has different flows with some of them requiring no human user being around, and the client_credentials flow is all about authenticating the client giving the token back for it to access its own resources, except that not having to sent name/password every time. This client does not need to be aware of any users because effectively this client is a 'user'. If "OAuth2 & Authentication" implies the human user is involved then may be it would be clearer if the subject was reworded somehow... Either way, if you reckon the client-credentials are out of scope then I'm fine with that, I guess keeping it focused on OIDC will help with the message > >> >>>> - IMHO it would be useful to mention that OIDC RP can help non-OAuth2 servers, i.e one does not have to write an OAuth2 client web application to get the benefits of the OIDC-driven authentication >>> >>> I don't understand what you're saying here. In order to make an OIDC RP, you need to write an OAuth2 client. That's by design. >> OIDC RP is a client. But this RP doe snot have to be collocated with the OAuth2 client which actually does some application specific work, right ? >> I.e OIDC RP facilitates the OAuth2-based authentication mechanism but the server 'protected' by this RP which would work with the authenticated user does not have to be OAuth2 client, do you agree ? >> If OIDC RP could only be used alongside OAuth2 clients then it would limit its usefulness IMHO > > > But the OIDC RP *is* an OAuth Client, so I still don't get what you're saying. Sure you can have OAuth clients that *aren't* OIDC clients, but you can't have an OIDC client that isn't also an OAuth client because OIDC is built directly on top of OAuth. May be it is my language issues. I haven't suggested that OIDC can be implemented without it being OAuth2 client. Consider this: OIDC RP filter <-> non OAuth2 server OIDC RP filter would do the OIDC thing (will act as OAuth2 client, return the user to OIDC IDP, validate the response) and then set the security context and let the user go to the non OAuth2 (client) server, with this server not being even aware that the OIDC flow has happened. Am not making sense at all with the above ? Thanks, Sergey > > -- Justin > > > >> >> Cheers, Sergey >> >> >>> >>> -- Justin >>> >>>> >>>> Thanks, Sergey >>>> On 16/10/14 17:54, Hannes Tschofenig wrote: >>>>> Participants: >>>>> >>>>> * Brian Campbell >>>>> * John Bradley >>>>> * Derek Atkins >>>>> * Phil Hunt >>>>> * William Kim >>>>> * Josh Mandel >>>>> * Hannes Tschofenig >>>>> >>>>> >>>>> Notes: >>>>> >>>>> Justin distributed a draft writeup and explained the reasoning behind >>>>> it. The intended purpose is to put the write-up (after enough review) on >>>>> oauth.net. See attachments. Justin solicited feedback from the >>>>> conference call participants and from the working group. >>>>> >>>>> One discussion item was specifically related to the concept of audience >>>>> restrictions, which comes in two flavours: (a) restriction of the access >>>>> token regarding the resource server and (b) restriction of the id token >>>>> regarding the client. Obviously, it is necessary to have both of these >>>>> audience restrictions in place and to actually check them. >>>>> >>>>> The group then went into a discussion about the use of pseudonyms in >>>>> authentication and the problems deployments ran into when they used >>>>> pseudonyms together with a wide range of attributes that identified >>>>> users nevertheless. Phil suggested to produce a write-up about this topic. >>>>> >>>>> Finally, the group started a discussion about potential actions for the >>>>> OAuth working groups. Two activities were mentioned, namely to produce >>>>> an IETF draft of the write-up Justin has prepared as a "formal" response >>>>> to the problems with authentication using OAuth and, as a second topic, >>>>> potential re-chartering of the OAuth working group to work on some >>>>> solutions in this area. Hannes suggested to postpone these discussions >>>>> and to first finish the write-up Justin had distributed. >>>>> >>>>> Ciao >>>>> Hannes & Derek >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 Fri Oct 17 08:12:00 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AECE1A0107 for ; Fri, 17 Oct 2014 08:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tsd5ZuGPT-fE for ; Fri, 17 Oct 2014 08:11:56 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id CCDD91A003B for ; Fri, 17 Oct 2014 08:11:55 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 7A19752E1D7; Fri, 17 Oct 2014 11:11:55 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id 70FF952E041; Fri, 17 Oct 2014 11:11:55 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.78]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.03.0174.001; Fri, 17 Oct 2014 11:11:55 -0400 From: "Richer, Justin P." To: Sergey Beryozkin Thread-Topic: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference Call Thread-Index: AQHP6g7t82pa7yV3YUG5qBwwuM9T2Jw0kdoAgAAFJACAAA1RgIAABAAA Date: Fri, 17 Oct 2014 15:11:54 +0000 Message-ID: <354CFFC4-6CDA-4984-9003-EBD40476E591@mitre.org> References: <543FF850.6070409@gmx.net> <54410ACE.5060303@gmail.com> <34A03788-A992-47E7-863A-8F1648ADF3B4@mitre.org> <54411EE4.2080405@gmail.com> <54412E5F.9000007@gmail.com> In-Reply-To: <54412E5F.9000007@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.15.56] Content-Type: text/plain; charset="Windows-1252" Content-ID: <1C893B0A90E9FF45B4A823049EAAD984@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/9eCBweDggJBCZl4GkX_m9xX-VO0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference Call X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 15:11:58 -0000 On Oct 17, 2014, at 10:57 AM, Sergey Beryozkin wrote= : > Hi, > On 17/10/14 15:09, Richer, Justin P. wrote: >>>>> - should a few words be reserved for the client credentials flow - th= is is of course not a mainstream OAuth2 nor its related to OIDC but it is a= ll about the authentication IMHO, the clients get their tokens by simply ge= tting authenticated, and as far as legacy (code) clients are concerned they= 'migrate' from sending the name/password to the resource endpoint on every= request ? >>>>=20 >>>> The client credentials flow has nothing to do with user authentication= , which is why it's left out of OIDC. There might not even be a user in thi= s flow (and it's generally assumed that there isn't). >>>>=20 >>> Yes, it is not part of OIDC but it is still the authentication of the c= lient that is effectively a resource owner, no human user is involved but I= MHO it's still very much the authentication. Exactly what the coded clients= do today in non OAuth2 client-server communications, except that in this c= ase the name/password is offered only once to AS. >>> May be it was not what this flow was envisaged for originally but I do = like it for the reasons outlined above, specifically it can help the legacy= /traditional clients to 'join' the OAuth2 AS infrastructure >>=20 >> But it's not authentication of the *user*, which is the whole point. Whe= n the client authenticates on its own behalf, you have no idea who the user= is or if they exist. It's irrelevant to the user authentication flow. If y= ou're looking for pulling legacy clients in, the "password" flow is better = for that, but OIDC didn't profile it because people really shouldn't be usi= ng the password flow except in very limited use cases in the first place. >=20 > I did get that. See the notes are about "OAuth2 & Authentication", so I t= hought it would not only be about the human user being authenticated via OI= DC. > OAuth2 has different flows with some of them requiring no human user bein= g around, and the client_credentials flow is all about authenticating the c= lient giving the token back for it to access its own resources, except that= not having to sent name/password every time. > This client does not need to be aware of any users because effectively th= is client is a 'user'. > If "OAuth2 & Authentication" implies the human user is involved then may = be it would be clearer if the subject was reworded somehow... > Either way, if you reckon the client-credentials are out of scope then I'= m fine with that, I guess keeping it focused on OIDC will help with the mes= sage Interesting, that's a misinterpretation that I didn't anticipate. I think I= 'm going to rename the whole page "OAuth and User Authentication" to avoid = that. >=20 >>=20 >>>=20 >>>>> - IMHO it would be useful to mention that OIDC RP can help non-OAuth2= servers, i.e one does not have to write an OAuth2 client web application t= o get the benefits of the OIDC-driven authentication >>>>=20 >>>> I don't understand what you're saying here. In order to make an OIDC R= P, you need to write an OAuth2 client. That's by design. >>> OIDC RP is a client. But this RP doe snot have to be collocated with th= e OAuth2 client which actually does some application specific work, right ? >>> I.e OIDC RP facilitates the OAuth2-based authentication mechanism but t= he server 'protected' by this RP which would work with the authenticated us= er does not have to be OAuth2 client, do you agree ? >>> If OIDC RP could only be used alongside OAuth2 clients then it would li= mit its usefulness IMHO >>=20 >>=20 >> But the OIDC RP *is* an OAuth Client, so I still don't get what you're s= aying. Sure you can have OAuth clients that *aren't* OIDC clients, but you = can't have an OIDC client that isn't also an OAuth client because OIDC is b= uilt directly on top of OAuth. >=20 > May be it is my language issues. I haven't suggested that OIDC can be imp= lemented without it being OAuth2 client. >=20 > Consider this: >=20 > OIDC RP filter <-> non OAuth2 server >=20 > OIDC RP filter would do the OIDC thing (will act as OAuth2 client, return= the user to OIDC IDP, validate the response) and then set the security con= text and let the user go to the non OAuth2 (client) server, with this serve= r not being even aware that the OIDC flow has happened. >=20 > Am not making sense at all with the above ? I think I see what you're saying now -- you could have a client that authen= ticates the user through OIDC and also accesses some set of non-identity AP= Is through OAuth, and the two parts don't actually have to talk to each oth= er. That's fine, but it's such a deep implementation detail that I don't th= ink it helps the conversation that we're trying to have. Especially conside= ring that the real problem stems from developers who do both authentication= and authorized API access right side by side in the same code and get the = two confused with each other. Is that a bit more clear? Thanks for your input, -- Justin >=20 > Thanks, Sergey >=20 >=20 >=20 >>=20 >> -- Justin >>=20 >>=20 >>=20 >>>=20 >>> Cheers, Sergey >>>=20 >>>=20 >>>>=20 >>>> -- Justin >>>>=20 >>>>>=20 >>>>> Thanks, Sergey >>>>> On 16/10/14 17:54, Hannes Tschofenig wrote: >>>>>> Participants: >>>>>>=20 >>>>>> * Brian Campbell >>>>>> * John Bradley >>>>>> * Derek Atkins >>>>>> * Phil Hunt >>>>>> * William Kim >>>>>> * Josh Mandel >>>>>> * Hannes Tschofenig >>>>>>=20 >>>>>>=20 >>>>>> Notes: >>>>>>=20 >>>>>> Justin distributed a draft writeup and explained the reasoning behin= d >>>>>> it. The intended purpose is to put the write-up (after enough review= ) on >>>>>> oauth.net. See attachments. Justin solicited feedback from the >>>>>> conference call participants and from the working group. >>>>>>=20 >>>>>> One discussion item was specifically related to the concept of audie= nce >>>>>> restrictions, which comes in two flavours: (a) restriction of the ac= cess >>>>>> token regarding the resource server and (b) restriction of the id to= ken >>>>>> regarding the client. Obviously, it is necessary to have both of the= se >>>>>> audience restrictions in place and to actually check them. >>>>>>=20 >>>>>> The group then went into a discussion about the use of pseudonyms in >>>>>> authentication and the problems deployments ran into when they used >>>>>> pseudonyms together with a wide range of attributes that identified >>>>>> users nevertheless. Phil suggested to produce a write-up about this = topic. >>>>>>=20 >>>>>> Finally, the group started a discussion about potential actions for = the >>>>>> OAuth working groups. Two activities were mentioned, namely to produ= ce >>>>>> an IETF draft of the write-up Justin has prepared as a "formal" resp= onse >>>>>> to the problems with authentication using OAuth and, as a second top= ic, >>>>>> potential re-chartering of the OAuth working group to work on some >>>>>> solutions in this area. Hannes suggested to postpone these discussio= ns >>>>>> and to first finish the write-up Justin had distributed. >>>>>>=20 >>>>>> Ciao >>>>>> Hannes & Derek >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>=20 >>=20 >=20 From nobody Fri Oct 17 08:13:57 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48F531A00C6 for ; Fri, 17 Oct 2014 08:13:55 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H4v9pdo8y0Pn for ; Fri, 17 Oct 2014 08:13:52 -0700 (PDT) Received: from mail-qg0-f45.google.com (mail-qg0-f45.google.com [209.85.192.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 015181A003B for ; Fri, 17 Oct 2014 08:13:51 -0700 (PDT) Received: by mail-qg0-f45.google.com with SMTP id q107so664696qgd.32 for ; Fri, 17 Oct 2014 08:13:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=TvFS6lOUXJK2TJBmOblxWmVEOu2I9srGOJkU9Mx5X9E=; b=eMfNT5nwDPEAiSdl0CB2DBLO/uEirs9ke3CqJ2YrAm9X6RkVEq7qiQZYgXcsrU1nPd xdr0IKL6cLYaq+m3Fd5W27N9vbKNQaPJv38BBYgQ2KpjEAqqty9RF2OjwGA2F0ZCRz0t 8nLr/NEMDtFTpyfclmSUfxHC2sIZU9lFVsAihBY0xvHin0rwXZqFB6/YvclOWSc/tS1e 7DInoIBbnT57uldCxmy3f3C/1HhPOTJ8j8NsDyRKIH6jbV4dr6u74u5eQNwBWl1XPbHY rXYjQiHOd9fK0VDr8kAdxdmKZj+rcYH6QG7hhf8sxuu+0oTiAvr4pNQZPVVkqOSmglcY a40g== X-Gm-Message-State: ALoCoQn/9jMC0TqsEE45PXaL9GubtA5AmK8dCymI3kqpJMKUgEGLLCoMVyccP9EwlRBu5InaFGve X-Received: by 10.224.80.70 with SMTP id s6mr12114108qak.8.1413558829208; Fri, 17 Oct 2014 08:13:49 -0700 (PDT) Received: from [192.168.1.39] (186-79-103-56.baf.movistar.cl. [186.79.103.56]) by mx.google.com with ESMTPSA id p45sm1075082qgd.49.2014.10.17.08.13.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 17 Oct 2014 08:13:48 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Bradley In-Reply-To: <54412E5F.9000007@gmail.com> Date: Fri, 17 Oct 2014 12:13:41 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <543FF850.6070409@gmx.net> <54410ACE.5060303@gmail.com> <34A03788-A992-47E7-863A-8F1648ADF3B4@mitre.org> <54411EE4.2080405@gmail.com> <54412E5F.9000007@gmail.com> To: Sergey Beryozkin X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/U3e0EW3x-1WNAKCJbaqiYP3s0xs Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference Call X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 15:13:55 -0000 Are you saying that the OIDC filter/client can set session cookies in a = domain that other web servers can use, so they don't have to have any = direct knowledge of Connect. I suspect that is a common practice in many SSO implementations. It is = true that not every web server needs to implement connect itself for = SSO. John B. On Oct 17, 2014, at 11:57 AM, Sergey Beryozkin = wrote: > Hi, > On 17/10/14 15:09, Richer, Justin P. wrote: >>>>> - should a few words be reserved for the client credentials flow - = this is of course not a mainstream OAuth2 nor its related to OIDC but it = is all about the authentication IMHO, the clients get their tokens by = simply getting authenticated, and as far as legacy (code) clients are = concerned they 'migrate' from sending the name/password to the resource = endpoint on every request ? >>>>=20 >>>> The client credentials flow has nothing to do with user = authentication, which is why it's left out of OIDC. There might not even = be a user in this flow (and it's generally assumed that there isn't). >>>>=20 >>> Yes, it is not part of OIDC but it is still the authentication of = the client that is effectively a resource owner, no human user is = involved but IMHO it's still very much the authentication. Exactly what = the coded clients do today in non OAuth2 client-server communications, = except that in this case the name/password is offered only once to AS. >>> May be it was not what this flow was envisaged for originally but I = do like it for the reasons outlined above, specifically it can help the = legacy/traditional clients to 'join' the OAuth2 AS infrastructure >>=20 >> But it's not authentication of the *user*, which is the whole point. = When the client authenticates on its own behalf, you have no idea who = the user is or if they exist. It's irrelevant to the user authentication = flow. If you're looking for pulling legacy clients in, the "password" = flow is better for that, but OIDC didn't profile it because people = really shouldn't be using the password flow except in very limited use = cases in the first place. >=20 > I did get that. See the notes are about "OAuth2 & Authentication", so = I thought it would not only be about the human user being authenticated = via OIDC. > OAuth2 has different flows with some of them requiring no human user = being around, and the client_credentials flow is all about = authenticating the client giving the token back for it to access its own = resources, except that not having to sent name/password every time. > This client does not need to be aware of any users because effectively = this client is a 'user'. > If "OAuth2 & Authentication" implies the human user is involved then = may be it would be clearer if the subject was reworded somehow... > Either way, if you reckon the client-credentials are out of scope then = I'm fine with that, I guess keeping it focused on OIDC will help with = the message >=20 >>=20 >>>=20 >>>>> - IMHO it would be useful to mention that OIDC RP can help = non-OAuth2 servers, i.e one does not have to write an OAuth2 client web = application to get the benefits of the OIDC-driven authentication >>>>=20 >>>> I don't understand what you're saying here. In order to make an = OIDC RP, you need to write an OAuth2 client. That's by design. >>> OIDC RP is a client. But this RP doe snot have to be collocated with = the OAuth2 client which actually does some application specific work, = right ? >>> I.e OIDC RP facilitates the OAuth2-based authentication mechanism = but the server 'protected' by this RP which would work with the = authenticated user does not have to be OAuth2 client, do you agree ? >>> If OIDC RP could only be used alongside OAuth2 clients then it would = limit its usefulness IMHO >>=20 >>=20 >> But the OIDC RP *is* an OAuth Client, so I still don't get what = you're saying. Sure you can have OAuth clients that *aren't* OIDC = clients, but you can't have an OIDC client that isn't also an OAuth = client because OIDC is built directly on top of OAuth. >=20 > May be it is my language issues. I haven't suggested that OIDC can be = implemented without it being OAuth2 client. >=20 > Consider this: >=20 > OIDC RP filter <-> non OAuth2 server >=20 > OIDC RP filter would do the OIDC thing (will act as OAuth2 client, = return the user to OIDC IDP, validate the response) and then set the = security context and let the user go to the non OAuth2 (client) server, = with this server not being even aware that the OIDC flow has happened. >=20 > Am not making sense at all with the above ? >=20 > Thanks, Sergey >=20 >=20 >=20 >>=20 >> -- Justin >>=20 >>=20 >>=20 >>>=20 >>> Cheers, Sergey >>>=20 >>>=20 >>>>=20 >>>> -- Justin >>>>=20 >>>>>=20 >>>>> Thanks, Sergey >>>>> On 16/10/14 17:54, Hannes Tschofenig wrote: >>>>>> Participants: >>>>>>=20 >>>>>> * Brian Campbell >>>>>> * John Bradley >>>>>> * Derek Atkins >>>>>> * Phil Hunt >>>>>> * William Kim >>>>>> * Josh Mandel >>>>>> * Hannes Tschofenig >>>>>>=20 >>>>>>=20 >>>>>> Notes: >>>>>>=20 >>>>>> Justin distributed a draft writeup and explained the reasoning = behind >>>>>> it. The intended purpose is to put the write-up (after enough = review) on >>>>>> oauth.net. See attachments. Justin solicited feedback from the >>>>>> conference call participants and from the working group. >>>>>>=20 >>>>>> One discussion item was specifically related to the concept of = audience >>>>>> restrictions, which comes in two flavours: (a) restriction of the = access >>>>>> token regarding the resource server and (b) restriction of the id = token >>>>>> regarding the client. Obviously, it is necessary to have both of = these >>>>>> audience restrictions in place and to actually check them. >>>>>>=20 >>>>>> The group then went into a discussion about the use of pseudonyms = in >>>>>> authentication and the problems deployments ran into when they = used >>>>>> pseudonyms together with a wide range of attributes that = identified >>>>>> users nevertheless. Phil suggested to produce a write-up about = this topic. >>>>>>=20 >>>>>> Finally, the group started a discussion about potential actions = for the >>>>>> OAuth working groups. Two activities were mentioned, namely to = produce >>>>>> an IETF draft of the write-up Justin has prepared as a "formal" = response >>>>>> to the problems with authentication using OAuth and, as a second = topic, >>>>>> potential re-chartering of the OAuth working group to work on = some >>>>>> solutions in this area. Hannes suggested to postpone these = discussions >>>>>> and to first finish the write-up Justin had distributed. >>>>>>=20 >>>>>> Ciao >>>>>> Hannes & Derek >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>=20 >>=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Fri Oct 17 08:39:24 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 238361A1B58 for ; Fri, 17 Oct 2014 08:39:22 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZPKQewEAOBo5 for ; Fri, 17 Oct 2014 08:39:19 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D86DF1A1AB0 for ; Fri, 17 Oct 2014 08:39:18 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id hs14so932237lab.3 for ; Fri, 17 Oct 2014 08:39:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=lh/6BkqlmQSBQPS+NxNici+zlWRmhg7L8mMGDOM3rhw=; b=KNDq7ur+OWC/4pnLG3tgi+oPvXwg3YWSkazwqcVTcjXz1OkYK8JFpl3N5pG+/nGNKK RShsRQ21a9RfUY5dVoCjof9mI1W2FoG/xzAYYy5wSkwD7rJPQrWRRXkJdhqhRjcH4XOj f1yVkZZ2HzXhDSLYnVWPrWrP895YSUc0zfR+nAvoXC6jhomyc4wHh6ezHglCfiHRikxC nGkhlpRND4denfxCkpsZR/QKS4CqlXOwEzcvyJzMhq7WkybVDCdUWS9lKc48A0fHolJ1 Q3BsS40S440D4ezOiVSj80D2wGl9ExhnKzV46zgI/EaMtBhhQS7uHlkPTEDbRmIh04bp PfRg== X-Received: by 10.152.36.33 with SMTP id n1mr3942182laj.95.1413560357146; Fri, 17 Oct 2014 08:39:17 -0700 (PDT) Received: from [10.36.226.2] ([80.169.137.63]) by mx.google.com with ESMTPSA id xs6sm548145lbb.13.2014.10.17.08.39.15 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Oct 2014 08:39:16 -0700 (PDT) Message-ID: <54413822.90905@gmail.com> Date: Fri, 17 Oct 2014 16:39:14 +0100 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "Richer, Justin P." References: <543FF850.6070409@gmx.net> <54410ACE.5060303@gmail.com> <34A03788-A992-47E7-863A-8F1648ADF3B4@mitre.org> <54411EE4.2080405@gmail.com> <54412E5F.9000007@gmail.com> <354CFFC4-6CDA-4984-9003-EBD40476E591@mitre.org> In-Reply-To: <354CFFC4-6CDA-4984-9003-EBD40476E591@mitre.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/p0DSNUR20aBv5os-U5uriaLjHs0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference Call X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 15:39:22 -0000 Hi, On 17/10/14 16:11, Richer, Justin P. wrote: > > On Oct 17, 2014, at 10:57 AM, Sergey Beryozkin wrote: > >> Hi, >> On 17/10/14 15:09, Richer, Justin P. wrote: >>>>>> - should a few words be reserved for the client credentials flow - this is of course not a mainstream OAuth2 nor its related to OIDC but it is all about the authentication IMHO, the clients get their tokens by simply getting authenticated, and as far as legacy (code) clients are concerned they 'migrate' from sending the name/password to the resource endpoint on every request ? >>>>> >>>>> The client credentials flow has nothing to do with user authentication, which is why it's left out of OIDC. There might not even be a user in this flow (and it's generally assumed that there isn't). >>>>> >>>> Yes, it is not part of OIDC but it is still the authentication of the client that is effectively a resource owner, no human user is involved but IMHO it's still very much the authentication. Exactly what the coded clients do today in non OAuth2 client-server communications, except that in this case the name/password is offered only once to AS. >>>> May be it was not what this flow was envisaged for originally but I do like it for the reasons outlined above, specifically it can help the legacy/traditional clients to 'join' the OAuth2 AS infrastructure >>> >>> But it's not authentication of the *user*, which is the whole point. When the client authenticates on its own behalf, you have no idea who the user is or if they exist. It's irrelevant to the user authentication flow. If you're looking for pulling legacy clients in, the "password" flow is better for that, but OIDC didn't profile it because people really shouldn't be using the password flow except in very limited use cases in the first place. >> >> I did get that. See the notes are about "OAuth2 & Authentication", so I thought it would not only be about the human user being authenticated via OIDC. >> OAuth2 has different flows with some of them requiring no human user being around, and the client_credentials flow is all about authenticating the client giving the token back for it to access its own resources, except that not having to sent name/password every time. >> This client does not need to be aware of any users because effectively this client is a 'user'. >> If "OAuth2 & Authentication" implies the human user is involved then may be it would be clearer if the subject was reworded somehow... >> Either way, if you reckon the client-credentials are out of scope then I'm fine with that, I guess keeping it focused on OIDC will help with the message > > Interesting, that's a misinterpretation that I didn't anticipate. I think I'm going to rename the whole page "OAuth and User Authentication" to avoid that. > To be clear, the notes did not confuse me :-), it is obvious they are about having the user involved in the authorization code/implicit flows involved, I just thought may be the doc can be enhanced further to cover various OAuth2 situations where the 'authentication' is involved. Yea, "OAuth2 and User Authentication" is a good subject name IMHO >> >>> >>>> >>>>>> - IMHO it would be useful to mention that OIDC RP can help non-OAuth2 servers, i.e one does not have to write an OAuth2 client web application to get the benefits of the OIDC-driven authentication >>>>> >>>>> I don't understand what you're saying here. In order to make an OIDC RP, you need to write an OAuth2 client. That's by design. >>>> OIDC RP is a client. But this RP doe snot have to be collocated with the OAuth2 client which actually does some application specific work, right ? >>>> I.e OIDC RP facilitates the OAuth2-based authentication mechanism but the server 'protected' by this RP which would work with the authenticated user does not have to be OAuth2 client, do you agree ? >>>> If OIDC RP could only be used alongside OAuth2 clients then it would limit its usefulness IMHO >>> >>> >>> But the OIDC RP *is* an OAuth Client, so I still don't get what you're saying. Sure you can have OAuth clients that *aren't* OIDC clients, but you can't have an OIDC client that isn't also an OAuth client because OIDC is built directly on top of OAuth. >> >> May be it is my language issues. I haven't suggested that OIDC can be implemented without it being OAuth2 client. >> >> Consider this: >> >> OIDC RP filter <-> non OAuth2 server >> >> OIDC RP filter would do the OIDC thing (will act as OAuth2 client, return the user to OIDC IDP, validate the response) and then set the security context and let the user go to the non OAuth2 (client) server, with this server not being even aware that the OIDC flow has happened. >> >> Am not making sense at all with the above ? > > I think I see what you're saying now -- you could have a client that authenticates the user through OIDC and also accesses some set of non-identity APIs through OAuth, and the two parts don't actually have to talk to each other. That's fine, but it's such a deep implementation detail that I don't think it helps the conversation that we're trying to have. Especially considering that the real problem stems from developers who do both authentication and authorized API access right side by side in the same code and get the two confused with each other. Is that a bit more clear? > Not quite :-), actually, this is a good point about the OIDC filter being possibly separate from the 'actual' OAuth2 client web app expecting an authenticated user, as it happens I'm wondering right now how I can get it implemented so that a boilerplate client code stays clear of dealing with authenticating the user. But you are right, I do refer to a case of the OIDC filter/RP being 'separate' except that for the purpose of this discussion I'm referring to a case where it protects a non OAuth2 server, i.e, the server which does not know what OAuth2 is. That is, I think OIDC RPs can be used to protect all types of servers, some of them will be OAuth2 clients on their own, some of them will be web apps which do not do OAuth2 at all. Perhaps it is off-topic for the actual notes, might deserve some note elsewhere... When I go to the OIDC site, I see it talks about the evolution from OpenId 2.0. The latter could have been used to log in users into non OAuth2 servers. The OAuth2-centricity of OIDC is its 'implementation detail'. But when I read about it it's all only about OAuth2 which is fair enough, OIDC is perfectly aligned with OAuth2, but if we have developers who have written non-OAuth2 servers protected by 'legacy' IDPs then they should know they won't have to turn their non-OAuth2 servers into OAuth2 client web apps to have the authentication supported by OIDC - a non collocated OIDC RP would help them to migrate to OIDC with their non-OAuth2 servers continuing doing whatever they do unchanged. Sorry I may've lost everyone with my reasoning above :-) Many thanks Sergey > Thanks for your input, > -- Justin > > >> >> Thanks, Sergey >> >> >> >>> >>> -- Justin >>> >>> >>> >>>> >>>> Cheers, Sergey >>>> >>>> >>>>> >>>>> -- Justin >>>>> >>>>>> >>>>>> Thanks, Sergey >>>>>> On 16/10/14 17:54, Hannes Tschofenig wrote: >>>>>>> Participants: >>>>>>> >>>>>>> * Brian Campbell >>>>>>> * John Bradley >>>>>>> * Derek Atkins >>>>>>> * Phil Hunt >>>>>>> * William Kim >>>>>>> * Josh Mandel >>>>>>> * Hannes Tschofenig >>>>>>> >>>>>>> >>>>>>> Notes: >>>>>>> >>>>>>> Justin distributed a draft writeup and explained the reasoning behind >>>>>>> it. The intended purpose is to put the write-up (after enough review) on >>>>>>> oauth.net. See attachments. Justin solicited feedback from the >>>>>>> conference call participants and from the working group. >>>>>>> >>>>>>> One discussion item was specifically related to the concept of audience >>>>>>> restrictions, which comes in two flavours: (a) restriction of the access >>>>>>> token regarding the resource server and (b) restriction of the id token >>>>>>> regarding the client. Obviously, it is necessary to have both of these >>>>>>> audience restrictions in place and to actually check them. >>>>>>> >>>>>>> The group then went into a discussion about the use of pseudonyms in >>>>>>> authentication and the problems deployments ran into when they used >>>>>>> pseudonyms together with a wide range of attributes that identified >>>>>>> users nevertheless. Phil suggested to produce a write-up about this topic. >>>>>>> >>>>>>> Finally, the group started a discussion about potential actions for the >>>>>>> OAuth working groups. Two activities were mentioned, namely to produce >>>>>>> an IETF draft of the write-up Justin has prepared as a "formal" response >>>>>>> to the problems with authentication using OAuth and, as a second topic, >>>>>>> potential re-chartering of the OAuth working group to work on some >>>>>>> solutions in this area. Hannes suggested to postpone these discussions >>>>>>> and to first finish the write-up Justin had distributed. >>>>>>> >>>>>>> Ciao >>>>>>> Hannes & Derek >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 Fri Oct 17 08:42:56 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D46CA1A1B70 for ; Fri, 17 Oct 2014 08:42: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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9nh6LdvRR4ZT for ; Fri, 17 Oct 2014 08:42:50 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81EA71A1B72 for ; Fri, 17 Oct 2014 08:42:49 -0700 (PDT) Received: by mail-lb0-f170.google.com with SMTP id u10so911161lbd.15 for ; Fri, 17 Oct 2014 08:42:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=DWzUjJaJfB1W00Ht/DWeqH5fn57GrJUHdd6OcyMODwc=; b=peJ9qwaOJjrY/NOFSyojW8skj6JE7FQr8Q6HxWNHsfWB6KT3wkOgjaHbDeNA6HlAKQ P/2QMy9+1BSz0VYKMboBQNOJx15QHbKkr5uXLmufUbPSStj1dNxUc4c81fMgOS2rtw+L ffM5KbcjVJenoLE2+cW8y8RpMlM0X/+FV7e5QmJLfTRIqTaWRz1p3+YL/vFIPiooQpjX DC3iw/NSXZSMcCJHT4A3qKmEanX1Q+ZV5sZVv2bv0O2hKDaelQeLsNXnjbosaNiTj2Rt 1Q+1nBA6x7nyApk9hEUG5XbJVOkweTj/WoqXVXclWEy4SY/5ypLmj6EHbPW8Nlv8aRkJ yjNg== X-Received: by 10.112.141.104 with SMTP id rn8mr4092884lbb.87.1413560567626; Fri, 17 Oct 2014 08:42:47 -0700 (PDT) Received: from [10.36.226.2] ([80.169.137.63]) by mx.google.com with ESMTPSA id pw9sm554405lbb.2.2014.10.17.08.42.46 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Oct 2014 08:42:46 -0700 (PDT) Message-ID: <544138F5.9020609@gmail.com> Date: Fri, 17 Oct 2014 16:42:45 +0100 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: John Bradley References: <543FF850.6070409@gmx.net> <54410ACE.5060303@gmail.com> <34A03788-A992-47E7-863A-8F1648ADF3B4@mitre.org> <54411EE4.2080405@gmail.com> <54412E5F.9000007@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/LZlSi6bg-DfdeYctfGU_ht7ovbA Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference Call X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 15:42:54 -0000 Hi On 17/10/14 16:13, John Bradley wrote: > Are you saying that the OIDC filter/client can set session cookies in a domain that other web servers can use, so they don't have to have any direct knowledge of Connect. > Yes. It is a pity I was not able to express myself with a single sentence like you offered above :-) > I suspect that is a common practice in many SSO implementations. It is true that not every web server needs to implement connect itself for SSO. Right; I guess it would make sense to make it a bit more obvious in some docs, may be in Opend id Connect Intro or similar Thanks, Sergey > > John B. > On Oct 17, 2014, at 11:57 AM, Sergey Beryozkin wrote: > >> Hi, >> On 17/10/14 15:09, Richer, Justin P. wrote: >>>>>> - should a few words be reserved for the client credentials flow - this is of course not a mainstream OAuth2 nor its related to OIDC but it is all about the authentication IMHO, the clients get their tokens by simply getting authenticated, and as far as legacy (code) clients are concerned they 'migrate' from sending the name/password to the resource endpoint on every request ? >>>>> >>>>> The client credentials flow has nothing to do with user authentication, which is why it's left out of OIDC. There might not even be a user in this flow (and it's generally assumed that there isn't). >>>>> >>>> Yes, it is not part of OIDC but it is still the authentication of the client that is effectively a resource owner, no human user is involved but IMHO it's still very much the authentication. Exactly what the coded clients do today in non OAuth2 client-server communications, except that in this case the name/password is offered only once to AS. >>>> May be it was not what this flow was envisaged for originally but I do like it for the reasons outlined above, specifically it can help the legacy/traditional clients to 'join' the OAuth2 AS infrastructure >>> >>> But it's not authentication of the *user*, which is the whole point. When the client authenticates on its own behalf, you have no idea who the user is or if they exist. It's irrelevant to the user authentication flow. If you're looking for pulling legacy clients in, the "password" flow is better for that, but OIDC didn't profile it because people really shouldn't be using the password flow except in very limited use cases in the first place. >> >> I did get that. See the notes are about "OAuth2 & Authentication", so I thought it would not only be about the human user being authenticated via OIDC. >> OAuth2 has different flows with some of them requiring no human user being around, and the client_credentials flow is all about authenticating the client giving the token back for it to access its own resources, except that not having to sent name/password every time. >> This client does not need to be aware of any users because effectively this client is a 'user'. >> If "OAuth2 & Authentication" implies the human user is involved then may be it would be clearer if the subject was reworded somehow... >> Either way, if you reckon the client-credentials are out of scope then I'm fine with that, I guess keeping it focused on OIDC will help with the message >> >>> >>>> >>>>>> - IMHO it would be useful to mention that OIDC RP can help non-OAuth2 servers, i.e one does not have to write an OAuth2 client web application to get the benefits of the OIDC-driven authentication >>>>> >>>>> I don't understand what you're saying here. In order to make an OIDC RP, you need to write an OAuth2 client. That's by design. >>>> OIDC RP is a client. But this RP doe snot have to be collocated with the OAuth2 client which actually does some application specific work, right ? >>>> I.e OIDC RP facilitates the OAuth2-based authentication mechanism but the server 'protected' by this RP which would work with the authenticated user does not have to be OAuth2 client, do you agree ? >>>> If OIDC RP could only be used alongside OAuth2 clients then it would limit its usefulness IMHO >>> >>> >>> But the OIDC RP *is* an OAuth Client, so I still don't get what you're saying. Sure you can have OAuth clients that *aren't* OIDC clients, but you can't have an OIDC client that isn't also an OAuth client because OIDC is built directly on top of OAuth. >> >> May be it is my language issues. I haven't suggested that OIDC can be implemented without it being OAuth2 client. >> >> Consider this: >> >> OIDC RP filter <-> non OAuth2 server >> >> OIDC RP filter would do the OIDC thing (will act as OAuth2 client, return the user to OIDC IDP, validate the response) and then set the security context and let the user go to the non OAuth2 (client) server, with this server not being even aware that the OIDC flow has happened. >> >> Am not making sense at all with the above ? >> >> Thanks, Sergey >> >> >> >>> >>> -- Justin >>> >>> >>> >>>> >>>> Cheers, Sergey >>>> >>>> >>>>> >>>>> -- Justin >>>>> >>>>>> >>>>>> Thanks, Sergey >>>>>> On 16/10/14 17:54, Hannes Tschofenig wrote: >>>>>>> Participants: >>>>>>> >>>>>>> * Brian Campbell >>>>>>> * John Bradley >>>>>>> * Derek Atkins >>>>>>> * Phil Hunt >>>>>>> * William Kim >>>>>>> * Josh Mandel >>>>>>> * Hannes Tschofenig >>>>>>> >>>>>>> >>>>>>> Notes: >>>>>>> >>>>>>> Justin distributed a draft writeup and explained the reasoning behind >>>>>>> it. The intended purpose is to put the write-up (after enough review) on >>>>>>> oauth.net. See attachments. Justin solicited feedback from the >>>>>>> conference call participants and from the working group. >>>>>>> >>>>>>> One discussion item was specifically related to the concept of audience >>>>>>> restrictions, which comes in two flavours: (a) restriction of the access >>>>>>> token regarding the resource server and (b) restriction of the id token >>>>>>> regarding the client. Obviously, it is necessary to have both of these >>>>>>> audience restrictions in place and to actually check them. >>>>>>> >>>>>>> The group then went into a discussion about the use of pseudonyms in >>>>>>> authentication and the problems deployments ran into when they used >>>>>>> pseudonyms together with a wide range of attributes that identified >>>>>>> users nevertheless. Phil suggested to produce a write-up about this topic. >>>>>>> >>>>>>> Finally, the group started a discussion about potential actions for the >>>>>>> OAuth working groups. Two activities were mentioned, namely to produce >>>>>>> an IETF draft of the write-up Justin has prepared as a "formal" response >>>>>>> to the problems with authentication using OAuth and, as a second topic, >>>>>>> potential re-chartering of the OAuth working group to work on some >>>>>>> solutions in this area. Hannes suggested to postpone these discussions >>>>>>> and to first finish the write-up Justin had distributed. >>>>>>> >>>>>>> Ciao >>>>>>> Hannes & Derek >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 > From nobody Fri Oct 17 08:56:55 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 006481A1B94 for ; Fri, 17 Oct 2014 08:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w38tfw9icD32 for ; Fri, 17 Oct 2014 08:56:48 -0700 (PDT) Received: from na3sys009aog123.obsmtp.com (na3sys009aog123.obsmtp.com [74.125.149.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36DE01A1BA5 for ; Fri, 17 Oct 2014 08:56:44 -0700 (PDT) Received: from mail-ig0-f170.google.com ([209.85.213.170]) (using TLSv1) by na3sys009aob123.postini.com ([74.125.148.12]) with SMTP ID DSNKVEE8OhTL8QhicTv0G79QMkp/t9+bcXH7@postini.com; Fri, 17 Oct 2014 08:56:44 PDT Received: by mail-ig0-f170.google.com with SMTP id hn15so3095580igb.5 for ; Fri, 17 Oct 2014 08:56:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=GRHai+GU/98tiOqtF+RPweHKHqmAZdDkkT8YEiuFIzo=; b=dzD7WITVnt5s9efpaB2ZFwSEsdIY73QLSYmPKIGF9Wl2hAJE/TCmhNMNUQZw4srW/P 0wj4A+KfRLZWzMIMtLkbaHl+3PjbneizqcTolTIW5uaBTV4UQR8tUYoAnnLTC9rnGlpQ 8CnTIYeOOyIjNBGzN8BEopOMrHCm6622jmhIHMy06RGc18I/B+mG/LMq0RyRZR5sNR8Y co4rqO7B1cGyGSXNbVuM0Hp5eguO3fql8ut3q7HnIv7rHG8clZcDT2GmK0rkAPGQxNRj GP1z11SUPpVCJH/Doc1qymAzp6l5aGqViiC7IgmvnFOAHkpR6J0RCUcKzYeAg6IjrwBK InXQ== X-Gm-Message-State: ALoCoQlOh3E4XXWdDrXp+MhOpMtdyCjuCd4mjT6ZKr06E4R2OQfy2HY7Cj8Ymva6fz9DcprXEL4IuucajzeXrMZdJA+WvMrAaEyYo0hKGFeQuGWeyAl6h3UQltELxLf13ypuGWaau7ta X-Received: by 10.43.76.199 with SMTP id zf7mr3073935icb.57.1413561401536; Fri, 17 Oct 2014 08:56:41 -0700 (PDT) X-Received: by 10.43.76.199 with SMTP id zf7mr3073868icb.57.1413561400901; Fri, 17 Oct 2014 08:56:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.12.137 with HTTP; Fri, 17 Oct 2014 08:56:10 -0700 (PDT) In-Reply-To: <28A05FEA-9EEA-4E95-9B9F-587120A74BAA@ve7jtb.com> References: <20141016034735.18695.61014.idtracker@ietfa.amsl.com> <28A05FEA-9EEA-4E95-9B9F-587120A74BAA@ve7jtb.com> From: Brian Campbell Date: Fri, 17 Oct 2014 09:56:10 -0600 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=001a11c3b2522b82710505a069ec Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/nwbM3nFIDZB5bSlfloCp7MATa6w Cc: Richard Barnes , "draft-ietf-oauth-assertions@tools.ietf.org" , "oauth-chairs@tools.ietf.org" , oauth , The IESG Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 15:56:51 -0000 --001a11c3b2522b82710505a069ec Content-Type: text/plain; charset=UTF-8 These drafts define the use of bearer assertions. The only mention of HoK style assertions is at the end of https://tools.ietf.org/html/draft-ietf-oauth-assertions-17#section-3 which notes that the "rules defined in this document are intended to support a client presenting a bearer assertion to an authorization server. The use of holder-of-key assertions are not precluded by this document, but additional protocol details would need to be specified." The requirement of having audience is for bearer assertions only (and we agree need to be that way for bearer) and not intended to preclude anything for HoK assertions. Does that change your opinion? Is there something that could be added or removed or clarified to allay concerns? On Thu, Oct 16, 2014 at 6:54 PM, John Bradley wrote: > Holder of key JWT is still in draft and we don't have a clear way to > present the proof to the token endpoint. > > Brian and I started discussing that last week as I happen to have a use > case for a PoP JWT assertion flow in some other spec work. > > I think that there is enough difference between bearer and PoP that doing > a follow on profile for SAML and JWT that can also cover the proof > presentment mechanisms makes the most sense. > > I would go with restricting this to Bearer and MUST for audience, and > removing the audience requirement explicitly in the PoP profiles. > > There are people who need the bearer version 6 months ago, I don't want > to do anything to hold it up based on future work. > > I am happy to help with a SAML PoP/HoK draft as a follow on. The SAML > subject confirmation stuff is relatively clear so it is mostly defining the > presentment mechanisms like mutual TLS and a self signed assertion. (we > need to be careful not to conflate client authentication and token proof, > as they are different and might both be used at the same time. > > John B. > > On Oct 16, 2014, at 7:20 PM, Richard Barnes wrote: > > You guys are all arguing that having an Audience can be useful. I don't > disagree. I disagree that it should be REQUIRED in all cases. > > The Google vulnerability that Brian raised was an interesting read, but as > John points out, it only applies to Bearer Assertions. There's no security > requirement at all for holder-of-key assertions to have an audience, since > they can't be replayed by someone who doesn't hold the key. > > I could agree that an audience should be REQUIRED for bearer assertions. > Since they are vulnerable to replay, Audience protects against the > Authorization Server re-using the token. (It would be good to say this > explicitly in the doc, actually.) But for holder-of-key assertions, the > Audience should be OPTIONAL. Note that this requires that instance > documents define the difference between bearer assertions and holder-of-key > assertions, so that implementations can enforce these requirements. > > So it seems like there are two solutions here: > 1. Scope the document to bearer assertions only, and keep the MUST > 2. Keep the current scope, make Audience OPTIONAL for holder-of-key > assertions, and define the difference in the instance docs. > > --Richard > > > > > > > On Thu, Oct 16, 2014 at 9:57 AM, Phil Hunt wrote: > >> It is also important for a non-protocol purpose. Liability. >> >> If a 3rd party uses an assertion that was not intended for it, it cannot >> obviously hold the asserting party responsible. >> >> Phil >> >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> >> >> >> On Oct 16, 2014, at 8:43 AM, Brian Campbell >> wrote: >> >> Thanks for your review and feedback, Richard. Replies are inline below... >> >> On Wed, Oct 15, 2014 at 9:47 PM, Richard Barnes wrote: >> >>> Richard Barnes has entered the following ballot position for >>> draft-ietf-oauth-assertions-17: Discuss >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>> >>> >>> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> "The assertion MUST contain an Audience that identifies the Authorization >>> Server as the intended audience. Assertions that do not identify the >>> Authorization Server as an intended audience MUST be rejected." >>> >>> Could you please identify the threat model within which this "MUST" is >>> required? This requirement doesn't follow from any of the threats >>> elaborated in Section 8. >>> >>> The Audience is only necessary if the Issuer wishes to constrain the set >>> of Authorization Servers with which an assertion may be used. So ISTM >>> that this should be "MAY contain..." >>> >>> >> >> The audience restriction let's the issuer say specifically what relying >> party is allowed to consume the assertion, which ensures that the client >> can't use it somewhere else that it wasn't intended and that the relying >> party that receives the assertion can't turn around and use it to access >> some other service. >> >> Strictly speaking, you are right that the audience is only necessary if >> the Issuer wishes to constrain the set of Authorization Servers with which >> an assertion may be used. But the Issuer really really really should make >> that constraint and fully understanding the implications of not doing so is >> difficult and unlikely. >> >> There was a vulnerability in Google apps SAML a few years back that >> demonstrates how important audience restriction is and how it can be >> difficult for even very sophisticated providers to get it all right. I >> haven't had time to read it again to make sure but I think that this is the >> paper http://www.ai-lab.it/armando/pub/fmse9-armando.pdf >> >> I don't see what value allowing audience to be omitted brings other than >> that it is academically a possibility. But requiring it (hopefully, if the >> requirement is followed) helps reduce the possibility of a whole bunch of >> security problems that folks likely won't foresee. >> >> >> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> "keyed message digest" -> "Message Authentication Code" >>> >>> That's the proper terminology [RFC4949], especially since there are MACs >>> that are not based on digests. >>> >> >> OK >> >> >>> >>> "This mechanism provides additional security properties." -- Please >>> delete this or elaborate on what security properties it provides. >>> >> >> Will delete. >> >> >>> >>> Section 8.2 should note that "Holder-of-Key Assertions" are also a >>> mitigation for this risk. >>> >>> >> OK >> >> >> >>> _______________________________________________ >>> 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 > > --001a11c3b2522b82710505a069ec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Oct 16, 2014 at 6:54 PM, John Bradley <= ;ve7jtb@ve7jtb.com> wrote:
Holder of key JWT is still in draft and we don't have a= clear way to present the proof to the token endpoint.

B= rian and I started discussing that last week as I happen to have a use case= for a PoP JWT assertion flow in some other spec work.

=
I think that there is enough difference between bearer and PoP that do= ing a follow on profile for SAML and JWT that can also cover the proof pres= entment mechanisms makes the most sense.

I would g= o with restricting this to Bearer and MUST for audience, =C2=A0and removing= the audience requirement explicitly in the PoP profiles.

There are people who need the bearer version 6 months ago, =C2=A0I = don't want to do anything to hold it up based on future work.

I am happy to help with a SAML PoP/HoK draft as a follow on= . =C2=A0 The SAML subject confirmation stuff is relatively clear so it is m= ostly defining the presentment mechanisms like mutual TLS and a self signed= assertion. (we need to be careful not to conflate client authentication an= d token proof, as they are different and might both be used at the same tim= e.

John B.


You guys are all arguing that having a= n Audience can be useful.=C2=A0 I don't disagree.=C2=A0 I disagree that= it should be REQUIRED in all cases.

The Google vulnerabi= lity that Brian raised was an interesting read, but as John points out, it = only applies to Bearer Assertions.=C2=A0 There's no security requiremen= t at all for holder-of-key assertions to have an audience, since they can&#= 39;t be replayed by someone who doesn't hold the key.

I could agree that an audience should be REQUIRED for bearer assertions.= =C2=A0 Since they are vulnerable to replay, Audience protects against the A= uthorization Server re-using the token.=C2=A0 (It would be good to say this= explicitly in the doc, actually.)=C2=A0 But for holder-of-key assertions, = the Audience should be OPTIONAL.=C2=A0 Note that this requires that instanc= e documents define the difference between bearer assertions and holder-of-k= ey assertions, so that implementations can enforce these requirements.
<= br>
So it seems like there are two solutions here:
= 1. Scope the document to bearer assertions only, and keep the MUST
2. Keep the current scope, make Audience OPTIONAL for holder-of-key a= ssertions, and define the difference in the instance docs.

--Richard






On Thu, Oct 16, 2014 at= 9:57 AM, Phil Hunt <phil.hunt@oracle.com> wrote:
It is also i= mportant for a non-protocol purpose. Liability.

If a 3rd= party uses an assertion that was not intended for it, it cannot obviously = hold the asserting party responsible. =C2=A0



On Oct 16, 2014, at 8:43 AM, Brian Campbell <bcampbell@pingidentity.c= om> wrote:

Thanks for your review and feedback, Richard.=20 Replies are inline below...

On Wed, Oct 15, 2014 at 9:47 PM, Richard Barnes <rlb@ipv.s= x> wrote:
http://www.ietf.org/iesg/statement/discuss-crit= eria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions= /



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

"The assertion MUST contain an Audience that identifies the Authorizat= ion
Server as the intended audience.=C2=A0 Assertions that do not identify the<= br> Authorization Server as an intended audience MUST be rejected."

Could you please identify the threat model within which this "MUST&quo= t; is
required?=C2=A0 This requirement doesn't follow from any of the threats=
elaborated in Section 8.

The Audience is only necessary if the Issuer wishes to constrain the set of Authorization Servers with which an assertion may be used.=C2=A0 So ISTM=
that this should be "MAY contain..."



The audience restriction let's= the issuer say specifically what=20 relying party is allowed to consume the assertion, which ensures that=20 the client can't use it somewhere else that it wasn't intended and = that the=20 relying party that receives the assertion can't turn around and use it= =20 to access some other service.

Strictly speaking,= you are right that the audience is only necessary if the Issuer wishes to = constrain the set of Authorization Servers with which an assertion may be u= sed. But the Issuer really really really should make that constraint and fu= lly understanding the implications of not doing so is difficult and unlikel= y.

There was a vulnerability in Google apps SAML a few y= ears back that demonstrates how important audience restriction is and= how it can be difficult for even very sophisticated providers to get it al= l right. I haven't had time to read it again to make sure but I think t= hat this is the paper http://www.ai-lab.it/armando/pub/fmse9-armando.= pdf

I don't see what value allowing = audience to be omitted brings other than that it is academically a possibil= ity. But requiring it (hopefully, if the requirement is followed) helps red= uce the possibility of a whole bunch of security problems that folks likely= won't foresee.

=C2=A0
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

"keyed message digest" -> "Message Authentication Code&qu= ot;

That's the proper terminology [RFC4949], especially since there are MAC= s
that are not based on digests.

OK
=C2=A0

"This mechanism provides additional security properties." -- Plea= se
delete this or elaborate on what security properties it provides.

Will delete.
=C2=A0

Section 8.2 should note that "Holder-of-Key Assertions" are also = a
mitigation for this risk.


OK
=C2=A0
=C2= =A0
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://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
http= s://www.ietf.org/mailman/listinfo/oauth


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


--001a11c3b2522b82710505a069ec-- From nobody Fri Oct 17 09:02:30 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9BE81A1B8F for ; Fri, 17 Oct 2014 09:02:24 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GXFGOtehEQ0m for ; Fri, 17 Oct 2014 09:02:17 -0700 (PDT) Received: from mail-qg0-f44.google.com (mail-qg0-f44.google.com [209.85.192.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B90331A1B8A for ; Fri, 17 Oct 2014 09:02:16 -0700 (PDT) Received: by mail-qg0-f44.google.com with SMTP id j5so740781qga.17 for ; Fri, 17 Oct 2014 09:02:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=IhKp4biBv6KrQT56U0xJMXdhz8yzGy4GtjpDbLf3ywU=; b=dKCvB6XADnpRO6PNfm6XW7QY+GiNBU8+NObTKUEfKy/dHzH/jk2CCP6UFrqM1ehHmX HqgO/zkVawLrFW482Vj40imoMyFJUkFR/fP3NVik1mWjDaZpLOhyEYXVq/M3AMC0EmjB vnKqEWNP3Ae7R6yGm16de9RGOQjM6aW4s+jg2JNKfYKlTFQujZlkGB3FbJzo+o6uhFjD wftJ3SZYgFKCgmGGZyCzoKpOlIp3YEj3DwNm94/CBNYPz28rZLiA2wyW+ymDyQ3UgA5+ ODBYAqm77l6BOxBXy0j0hQAAyl9CD4CkLJ4zgF7cxamFEiazetTfAy4It2FyXId4tOtz QPEQ== X-Gm-Message-State: ALoCoQkuphe7Hw1QtgI6I2Pf70Q7dASRI27gI7qs7Eoj8brNK89l1MimsAb7g97CSfitXwnLNPw8 X-Received: by 10.224.26.69 with SMTP id d5mr13528815qac.49.1413561735770; Fri, 17 Oct 2014 09:02:15 -0700 (PDT) Received: from [192.168.8.100] ([201.188.100.219]) by mx.google.com with ESMTPSA id 46sm1193227qgf.21.2014.10.17.09.02.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 17 Oct 2014 09:02:15 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_B8428BDC-2337-4FF9-BCB2-B57DA32216B0" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Bradley In-Reply-To: Date: Fri, 17 Oct 2014 13:01:58 -0300 Message-Id: <19E82AEC-A5DA-41E9-9370-3FF16264DEAE@ve7jtb.com> References: <20141016034735.18695.61014.idtracker@ietfa.amsl.com> <28A05FEA-9EEA-4E95-9B9F-587120A74BAA@ve7jtb.com> To: Brian Campbell X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Y2O2x2ISD6OjOdWT_7tX13AZ9_M Cc: Richard Barnes , "draft-ietf-oauth-assertions@tools.ietf.org" , "oauth-chairs@tools.ietf.org" , oauth , The IESG Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 16:02:25 -0000 --Apple-Mail=_B8428BDC-2337-4FF9-BCB2-B57DA32216B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I am good with it as is. I think we have the flexibility to add HoK = later. =20 I mostly wanted to point out that it is really only in that later HoK = profile where omitting audience is safe. If I had the power to remove the DISCUS I would. John B. On Oct 17, 2014, at 12:56 PM, Brian Campbell = wrote: > These drafts define the use of bearer assertions. The only mention of = HoK style assertions is at the end of = https://tools.ietf.org/html/draft-ietf-oauth-assertions-17#section-3 = which notes that the "rules defined in this document are intended to = support a client presenting a bearer assertion to an authorization = server. The use of holder-of-key assertions are not precluded by this = document, but additional protocol details would need to be specified." >=20 > The requirement of having audience is for bearer assertions only (and = we agree need to be that way for bearer) and not intended to preclude = anything for HoK assertions.=20 >=20 > Does that change your opinion? Is there something that could be added = or removed or clarified to allay concerns? >=20 >=20 >=20 > On Thu, Oct 16, 2014 at 6:54 PM, John Bradley = wrote: > Holder of key JWT is still in draft and we don't have a clear way to = present the proof to the token endpoint. >=20 > Brian and I started discussing that last week as I happen to have a = use case for a PoP JWT assertion flow in some other spec work. >=20 > I think that there is enough difference between bearer and PoP that = doing a follow on profile for SAML and JWT that can also cover the proof = presentment mechanisms makes the most sense. >=20 > I would go with restricting this to Bearer and MUST for audience, and = removing the audience requirement explicitly in the PoP profiles. >=20 > There are people who need the bearer version 6 months ago, I don't = want to do anything to hold it up based on future work. >=20 > I am happy to help with a SAML PoP/HoK draft as a follow on. The = SAML subject confirmation stuff is relatively clear so it is mostly = defining the presentment mechanisms like mutual TLS and a self signed = assertion. (we need to be careful not to conflate client authentication = and token proof, as they are different and might both be used at the = same time. >=20 > John B. >=20 > On Oct 16, 2014, at 7:20 PM, Richard Barnes wrote: >=20 >> You guys are all arguing that having an Audience can be useful. I = don't disagree. I disagree that it should be REQUIRED in all cases. >>=20 >> The Google vulnerability that Brian raised was an interesting read, = but as John points out, it only applies to Bearer Assertions. There's = no security requirement at all for holder-of-key assertions to have an = audience, since they can't be replayed by someone who doesn't hold the = key. >>=20 >> I could agree that an audience should be REQUIRED for bearer = assertions. Since they are vulnerable to replay, Audience protects = against the Authorization Server re-using the token. (It would be good = to say this explicitly in the doc, actually.) But for holder-of-key = assertions, the Audience should be OPTIONAL. Note that this requires = that instance documents define the difference between bearer assertions = and holder-of-key assertions, so that implementations can enforce these = requirements. >>=20 >> So it seems like there are two solutions here: >> 1. Scope the document to bearer assertions only, and keep the MUST >> 2. Keep the current scope, make Audience OPTIONAL for holder-of-key = assertions, and define the difference in the instance docs. >>=20 >> --Richard >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> On Thu, Oct 16, 2014 at 9:57 AM, Phil Hunt = wrote: >> It is also important for a non-protocol purpose. Liability. >>=20 >> If a 3rd party uses an assertion that was not intended for it, it = cannot obviously hold the asserting party responsible. =20 >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >> On Oct 16, 2014, at 8:43 AM, Brian Campbell = wrote: >>=20 >>> Thanks for your review and feedback, Richard. Replies are inline = below... >>>=20 >>> On Wed, Oct 15, 2014 at 9:47 PM, Richard Barnes wrote: >>> Richard Barnes has entered the following ballot position for >>> draft-ietf-oauth-assertions-17: Discuss >>>=20 >>> When responding, please keep the subject line intact and reply to = all >>> email addresses included in the To and CC lines. (Feel free to cut = this >>> introductory paragraph, however.) >>>=20 >>>=20 >>> Please refer to = http://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>>=20 >>>=20 >>> The document, along with other ballot positions, can be found here: >>> http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ >>>=20 >>>=20 >>>=20 >>> = ---------------------------------------------------------------------- >>> DISCUSS: >>> = ---------------------------------------------------------------------- >>>=20 >>> "The assertion MUST contain an Audience that identifies the = Authorization >>> Server as the intended audience. Assertions that do not identify = the >>> Authorization Server as an intended audience MUST be rejected." >>>=20 >>> Could you please identify the threat model within which this "MUST" = is >>> required? This requirement doesn't follow from any of the threats >>> elaborated in Section 8. >>>=20 >>> The Audience is only necessary if the Issuer wishes to constrain the = set >>> of Authorization Servers with which an assertion may be used. So = ISTM >>> that this should be "MAY contain..." >>>=20 >>>=20 >>>=20 >>> The audience restriction let's the issuer say specifically what = relying party is allowed to consume the assertion, which ensures that = the client can't use it somewhere else that it wasn't intended and that = the relying party that receives the assertion can't turn around and use = it to access some other service. >>>=20 >>> Strictly speaking, you are right that the audience is only necessary = if the Issuer wishes to constrain the set of Authorization Servers with = which an assertion may be used. But the Issuer really really really = should make that constraint and fully understanding the implications of = not doing so is difficult and unlikely.=20 >>>=20 >>> There was a vulnerability in Google apps SAML a few years back that = demonstrates how important audience restriction is and how it can be = difficult for even very sophisticated providers to get it all right. I = haven't had time to read it again to make sure but I think that this is = the paper http://www.ai-lab.it/armando/pub/fmse9-armando.pdf >>>=20 >>> I don't see what value allowing audience to be omitted brings other = than that it is academically a possibility. But requiring it (hopefully, = if the requirement is followed) helps reduce the possibility of a whole = bunch of security problems that folks likely won't foresee. >>>=20 >>> =20 >>> = ---------------------------------------------------------------------- >>> COMMENT: >>> = ---------------------------------------------------------------------- >>>=20 >>> "keyed message digest" -> "Message Authentication Code" >>>=20 >>> That's the proper terminology [RFC4949], especially since there are = MACs >>> that are not based on digests. >>>=20 >>> OK >>> =20 >>>=20 >>> "This mechanism provides additional security properties." -- Please >>> delete this or elaborate on what security properties it provides. >>>=20 >>> Will delete. >>> =20 >>>=20 >>> Section 8.2 should note that "Holder-of-Key Assertions" are also a >>> mitigation for this risk. >>>=20 >>>=20 >>> OK >>> =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 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 --Apple-Mail=_B8428BDC-2337-4FF9-BCB2-B57DA32216B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I am = good with it as is.  I think we have the flexibility to add HoK = later.    

I mostly wanted to point out = that it is really only in that later HoK profile where omitting audience = is safe.

If I had the power to remove the = DISCUS I would.

John = B.

On Oct 17, 2014, at 12:56 PM, Brian Campbell = <bcampbell@pingidentity.com&= gt; wrote:

These drafts define the use of = bearer assertions. The only mention of HoK style assertions is at the = end of https://tools.ietf.org/html/draft-ietf-oauth-assertions-= 17#section-3 which notes that the "rules defined in this document = are intended to support a client presenting a bearer assertion to an = authorization server.  The use of holder-of-key assertions are not = precluded by this document, but additional protocol details would need = to be specified."

The requirement of having audience = is for bearer assertions only (and we agree need to be that way = for bearer) and not intended to preclude anything for HoK = assertions.

Does that = change your opinion? Is there something that could be added or removed = or clarified to allay = concerns?



On Thu, Oct 16, = 2014 at 6:54 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
Holder of = key JWT is still in draft and we don't have a clear way to present the = proof to the token endpoint.

Brian and I started = discussing that last week as I happen to have a use case for a PoP JWT = assertion flow in some other spec work.

I think = that there is enough difference between bearer and PoP that doing a = follow on profile for SAML and JWT that can also cover the proof = presentment mechanisms makes the most sense.

I = would go with restricting this to Bearer and MUST for audience, =  and removing the audience requirement explicitly in the PoP = profiles.

There are people who need the bearer = version 6 months ago,  I don't want to do anything to hold it up = based on future work.

I am happy to help with a = SAML PoP/HoK draft as a follow on.   The SAML subject confirmation = stuff is relatively clear so it is mostly defining the presentment = mechanisms like mutual TLS and a self signed assertion. (we need to be = careful not to conflate client authentication and token proof, as they = are different and might both be used at the same = time.

John B.

On Oct 16, 2014, at 7:20 PM, Richard Barnes = <rlb@ipv.sx> = wrote:

You guys = are all arguing that having an Audience can be useful.  I don't = disagree.  I disagree that it should be REQUIRED in all = cases.

The Google vulnerability that Brian raised was = an interesting read, but as John points out, it only applies to Bearer = Assertions.  There's no security requirement at all for = holder-of-key assertions to have an audience, since they can't be = replayed by someone who doesn't hold the key.

I could = agree that an audience should be REQUIRED for bearer assertions.  = Since they are vulnerable to replay, Audience protects against the = Authorization Server re-using the token.  (It would be good to say = this explicitly in the doc, actually.)  But for holder-of-key = assertions, the Audience should be OPTIONAL.  Note that this = requires that instance documents define the difference between bearer = assertions and holder-of-key assertions, so that implementations can = enforce these requirements.

So it seems like there are = two solutions here:
1. Scope the document to bearer = assertions only, and keep the MUST
2. Keep the current = scope, make Audience OPTIONAL for holder-of-key assertions, and define = the difference in the instance = docs.

--Richard





On Thu, Oct 16, 2014 at 9:57 AM, Phil Hunt <phil.hunt@oracle.com> = wrote:
It is also important for a non-protocol = purpose. Liability.

If a 3rd party uses an assertion = that was not intended for it, it cannot obviously hold the asserting = party responsible.  


On Oct 16, 2014, at 8:43 AM, Brian Campbell <bcampbell@pingidentity.com> = wrote:

Thanks for your review and feedback, Richard.=20= Replies are inline below...

On Wed, Oct 15, = 2014 at 9:47 PM, Richard Barnes <rlb@ipv.sx> = wrote:
Richard = Barnes has entered the following ballot position for
draft-ietf-oauth-assertions-17: Discuss

When responding, please keep the subject line intact and reply to = all
email addresses included in the To and CC lines. (Feel free to cut = this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html=
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-oauth-asserti= ons/



= ----------------------------------------------------------------------
= DISCUSS:
= ----------------------------------------------------------------------
=
"The assertion MUST contain an Audience that identifies the = Authorization
Server as the intended audience.  Assertions that do not identify = the
Authorization Server as an intended audience MUST be rejected."

Could you please identify the threat model within which this "MUST" = is
required?  This requirement doesn't follow from any of the = threats
elaborated in Section 8.

The Audience is only necessary if the Issuer wishes to constrain the = set
of Authorization Servers with which an assertion may be used.  So = ISTM
that this should be "MAY contain..."



The audience restriction let's = the issuer say specifically what=20 relying party is allowed to consume the assertion, which ensures that=20 the client can't use it somewhere else that it wasn't intended and that = the=20 relying party that receives the assertion can't turn around and use it=20= to access some other service.

Strictly = speaking, you are right that the audience is only necessary if the = Issuer wishes to constrain the set of Authorization Servers with which = an assertion may be used. But the Issuer really really really should = make that constraint and fully understanding the implications of not = doing so is difficult and unlikely.

There was a = vulnerability in Google apps SAML a few years back that demonstrates how = important audience restriction is and how it can be difficult for = even very sophisticated providers to get it all right. I haven't had = time to read it again to make sure but I think that this is the paper http://www.ai-lab.it/armando/pub/fmse9-armando.pdf
I don't see what value allowing audience = to be omitted brings other than that it is academically a possibility. = But requiring it (hopefully, if the requirement is followed) helps = reduce the possibility of a whole bunch of security problems that folks = likely won't foresee.

 
= ----------------------------------------------------------------------
= COMMENT:
= ----------------------------------------------------------------------
=
"keyed message digest" -> "Message Authentication Code"

That's the proper terminology [RFC4949], especially since there are = MACs
that are not based on = digests.

OK
 
=

"This mechanism provides additional security properties." -- Please
delete this or elaborate on what security properties it = provides.

Will = delete.
 

Section 8.2 should note that "Holder-of-Key Assertions" are also a
mitigation for this risk.
=

OK
 
&nb= sp;
_______________________________________________
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



= --Apple-Mail=_B8428BDC-2337-4FF9-BCB2-B57DA32216B0-- From nobody Fri Oct 17 09:27:52 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 090CB1A1BEE for ; Fri, 17 Oct 2014 09:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DmKx6aYgpbRF for ; Fri, 17 Oct 2014 09:27:40 -0700 (PDT) Received: from na3sys009aog123.obsmtp.com (na3sys009aog123.obsmtp.com [74.125.149.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CFDB1A1BEA for ; Fri, 17 Oct 2014 09:27:39 -0700 (PDT) Received: from mail-ie0-f174.google.com ([209.85.223.174]) (using TLSv1) by na3sys009aob123.postini.com ([74.125.148.12]) with SMTP ID DSNKVEFDenfzNt0fcbOBsL7xyc3CK7/C3IGd@postini.com; Fri, 17 Oct 2014 09:27:39 PDT Received: by mail-ie0-f174.google.com with SMTP id tr6so1045589ieb.5 for ; Fri, 17 Oct 2014 09:27:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=0c+tEjiTlJuy8PZ79q4S5gFg89CEShegLu2UfKwrk10=; b=gdQPdLSGfV/ZXniAO4Xu6N8tK1NKy1snv+7GCk+f1ZI0CBxd4fthdvaqkaeozoRf7d EZiMlwE+jv08hzJa/WeHBs9BVlxDpM6KeOloPfD1q/QiVPxd0NGohooLO7nkTSGyqvWj rZczOSSB5c6jtTT081Y3fvcGk25ZQXiD5odPKnSrY6qmwBO9FQT3jL99O4ZiseYii0/6 jab2FGXg3jPD5UVqvtFPR9yZCRs3m235leFVIY04KUP7g63DvFpskdern2oSroXGAPmE f8A5EOPCT4wGuo8ynCaQjQQCOXsTDsF/C110LU5BpC6zYXOcvyQdYYzvYl2ysZ9A+cmC Qbwg== X-Gm-Message-State: ALoCoQnrzVm51g2FaDrkoOF9CNUc9XkQwjA+nCF5MyCpaRyqX12R7eUOvVgOjqZA79/oYSLOcOr8XAAIFzjRtm83wlxNLcJcNkfeJm7h/oI2R+v5TvyyLwz0k4V+45WxHktE/POn7sI2 X-Received: by 10.50.66.179 with SMTP id g19mr66006igt.40.1413563258300; Fri, 17 Oct 2014 09:27:38 -0700 (PDT) X-Received: by 10.50.66.179 with SMTP id g19mr65987igt.40.1413563258129; Fri, 17 Oct 2014 09:27:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.12.137 with HTTP; Fri, 17 Oct 2014 09:27:07 -0700 (PDT) In-Reply-To: References: <20141016040122.32277.7067.idtracker@ietfa.amsl.com> From: Brian Campbell Date: Fri, 17 Oct 2014 10:27:07 -0600 Message-ID: To: Richard Barnes Content-Type: multipart/alternative; boundary=047d7bdc15b2de825f0505a0d771 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/XXUpF_3aTCWoYgNDZC9NmpG1dOw Cc: "oauth-chairs@tools.ietf.org" , oauth , The IESG , draft-ietf-oauth-jwt-bearer@tools.ietf.org Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-jwt-bearer-10: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 16:27:49 -0000 --047d7bdc15b2de825f0505a0d771 Content-Type: text/plain; charset=UTF-8 On Thu, Oct 16, 2014 at 4:32 PM, Richard Barnes wrote: > > > On Thu, Oct 16, 2014 at 1:44 PM, Brian Campbell < > bcampbell@pingidentity.com> wrote: > >> Thanks for your review and feedback on this one too, Richard. Replies >> are inline below... >> >> On Wed, Oct 15, 2014 at 10:01 PM, Richard Barnes wrote: >> >>> Richard Barnes has entered the following ballot position for >>> draft-ietf-oauth-jwt-bearer-10: Discuss >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>> >>> >>> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> http://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> As with draft-ietf-oauth-assertions, the requirement for an "aud" claim >>> seems entirely unnecessary. Holding this DISCUSS point pending that >>> discussion >>> and its reflection in this document. >>> >>> "Assertions that do not identify the Authorization Server as an intended >>> audience MUST be rejected." -- What does it mean for an assertion to >>> "identify >>> the Authorization Server"? Does the specified need to match >>> the >>> entire URL of the relevant OAuth endpoint? Just the origin? Just the >>> domain? >>> Does the URL need to be canonicalized? >>> >>> >> >> No c14n, as it says, "... compare the audience values using the Simple >> String Comparison method defined in Section 6.2.1 of RFC 3986." >> >> Basically the AS is at liberty to determine how it identifies itself. >> Some guidance on using the token endpoint is provided but it's ultimately >> up to the AS (or the larger deployment in which the AS exists). The >> acceptable value is one of a few bits of information that must be exchanged >> for this profile, which is discussed in the Interoperability Considerations >> https://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-10#section-5 >> > > Sigh. "Negotiate it out of band" is a terrible, non-scalable, > not-in-the-spirit-of-the-Internet answer. But I guess I might clear on > this if you could add something like the following: > "As noted in Section 5 of [I-D.ietf-oauth-jwt-bearer], the precise strings > to be used as the Audience for a given Authorization Server must be > configured out-of-band by the Authorization Server and the Issuer of the > assertion." > I'll add the suggested text. > > But is there seriously no answer that the WG could agree on? This seems > like it should be a pretty simple question. Was it even discussed? > > It was discussed but it's not simple for reasons I've tried to articulate many times. Note that the specific profiling or usage of these specs can constrain or dictate the values of this and other the things that needing out of band negotiation and can be more in the spirit of the Internet to the extent that they define dynamic exchange/discovery/registration/etc. of required information. But these little documents need to fit into such larger contexts not try and define them. > --Richard > > > >> Some more explanation/discussion of it is in the middle(ish) of this >> reply to a similar comment from Stephen Farrell >> http://www.ietf.org/mail-archive/web/oauth/current/msg13605.html >> >> >> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> "keyed message digest" -> "MAC" >>> >> >> Yep. >> >> >>> >>> Both this and the SAML document could save a lot of bits by just being >>> subsections of the -assertions document. >>> >> >> The structure and relationship of the documents was decided on by the WG >> nearly three years ago. There is some duplication but it's believed to be >> more approachable this way - particularly for those implementing just one >> assertion type. >> > > --047d7bdc15b2de825f0505a0d771 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Oct 16, 2014 at 4:32 PM, Richard Barnes = <rlb@ipv.sx> wrote:


On Thu, Oct 16, 2014 at 1:44 PM, Brian Campbell <bcampbell@ping= identity.com> wrote:
Thanks for your review and feedb= ack on this one too, Richard.=20 Replies are inline below...

On Wed, Oct 15, 2014 at 10:01 PM, Richard = Barnes <rlb@ipv.sx> wrote:
Richard Barnes has entered the following ballot position for draft-ietf-oauth-jwt-bearer-10: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-crit= eria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer= /



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

As with draft-ietf-oauth-assertions, the requirement for an "aud"= claim
seems entirely unnecessary.=C2=A0 Holding this DISCUSS point pending that discussion
and its reflection in this document.

"Assertions that do not identify the Authorization Server as an intend= ed
audience MUST be rejected." -- What does it mean for an assertion to "identify
the Authorization Server"?=C2=A0 Does the specified <Audience> n= eed to match
the
entire URL of the relevant OAuth endpoint?=C2=A0 Just the origin?=C2=A0 Jus= t the
domain?
Does the URL need to be canonicalized?



No c14n, as it says, &= quot;...=C2=A0 compare the audience values using the Simple String Comparis= on method defined in Section 6.2.1 of RFC 3986."

Ba= sically the AS is at liberty to determine how it identifies itself. Some gu= idance on using the token endpoint is provided but it's ultimately up t= o the AS (or the larger deployment in which the AS exists). The acceptable = value is one of a few bits of information that must be exchanged for this p= rofile, which is discussed in the Interoperability Considerations https://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-10= #section-5

Sigh.=C2=A0 "Negotiate it out of band" is a terrible,= non-scalable, not-in-the-spirit-of-the-Internet answer.=C2=A0 But I guess = I might clear on this if you could add something like the following:
"As noted in Section 5 of [I-D.ietf-oauth-jwt-bearer], the pre= cise strings to be used as the Audience for a given Authorization Server mu= st be configured out-of-band by the Authorization Server and the Issuer of = the assertion."


<= br>I'll add the suggested text.


=C2=A0

But is there seriously n= o answer that the WG could agree on?=C2=A0 This seems like it should be a p= retty simple question.=C2=A0 Was it even discussed?


<= br>
It was discussed but it's not simple for reasons I= 9;ve tried to articulate many times.

Note that the specif= ic profiling or usage of these specs can constrain or dictate the values of= this and other the things that needing out of band negotiation and can be = more in the spirit of the Internet to the extent that they define dynamic e= xchange/discovery/registration/etc. of required information. But these litt= le documents need to fit into such larger contexts not try and define them.=


=C2=A0
--Richard

=C2= =A0
Some more expla= nation/discussion of it is in the middle(ish) of this reply to a similar co= mment from Stephen Farrell http://www.ietf.org/mail-arc= hive/web/oauth/current/msg13605.html



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

"keyed message digest" -> "MAC"

Yep.
=C2=A0

Both this and the SAML document could save a lot of bits by just being
subsections of the -assertions document.

The structure and relationship of the documents was decided on by = the WG nearly three years ago. There is some duplication but it's belie= ved to be more approachable this way - particularly for those implementing = just one assertion type.


--047d7bdc15b2de825f0505a0d771-- From nobody Fri Oct 17 09:29:58 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAA551A1BED for ; Fri, 17 Oct 2014 09:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2dSStqVzpjqK for ; Fri, 17 Oct 2014 09:29:46 -0700 (PDT) Received: from na3sys009aog138.obsmtp.com (na3sys009aog138.obsmtp.com [74.125.149.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D82E41A1BEF for ; Fri, 17 Oct 2014 09:29:45 -0700 (PDT) Received: from mail-ig0-f171.google.com ([209.85.213.171]) (using TLSv1) by na3sys009aob138.postini.com ([74.125.148.12]) with SMTP ID DSNKVEFD+fIUzXSgFL41PSDWy6h4FtxFKC4z@postini.com; Fri, 17 Oct 2014 09:29:45 PDT Received: by mail-ig0-f171.google.com with SMTP id h15so1878941igd.16 for ; Fri, 17 Oct 2014 09:29:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=DvwHHY9mTVXiyJCyfKSQzfwftS04TgPVULvEFAMheL4=; b=aubo0S0LDJGJAlXGvdcCq6zMGYq06+tL2lBWic1n5fXcHwu9FJ+3kVzliD5GUK7IK+ JAUpScy4rjxg6NmC/Hjw9YZfWa0rxU389VHJiigTAkEmMKB/fWVSLx1DHV2dokJWQhBO wKt0cCYah+h/qoQJ3rNzrbXsl2SMUbgcepWA4it15Z/Ue0cxBHrK87bq7YnvgOQcqJG/ JJ/iPIayZ7UYLt41jmIJArZk+CV+hnEKeaOmIpNjmpiDyFXRxaE0/O2FI+QqxUjqsj2v 6RA4bz8RlNXiXR5yNqNlMPz8A3aVHswe8rdaNZGGNnrty/LrWPmWV4fLJgunG6e03D2d DVeA== X-Gm-Message-State: ALoCoQlHGvWDDEveugGUdeD68s5IOudBHDUwVFTzmgk1VxYwYIdwWGVIeH98PJfPIbQP2leJ8umcFkhlWEQNZb76t2McwevCCsgw/qgB03ONkH6VGNBfyxtRc2F+Hr/0ykkV0kUdLWKl X-Received: by 10.107.163.142 with SMTP id m136mr10041746ioe.32.1413563385294; Fri, 17 Oct 2014 09:29:45 -0700 (PDT) X-Received: by 10.107.163.142 with SMTP id m136mr10041726ioe.32.1413563385134; Fri, 17 Oct 2014 09:29:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.12.137 with HTTP; Fri, 17 Oct 2014 09:29:15 -0700 (PDT) In-Reply-To: References: <20141016035640.25108.27277.idtracker@ietfa.amsl.com> From: Brian Campbell Date: Fri, 17 Oct 2014 10:29:15 -0600 Message-ID: To: Richard Barnes Content-Type: multipart/alternative; boundary=001a11403ff87061aa0505a0df7c Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/ycTFrAY-b-M8l_RGFn3v02fd6QA Cc: "oauth-chairs@tools.ietf.org" , draft-ietf-oauth-saml2-bearer@tools.ietf.org, The IESG , oauth Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-saml2-bearer-21: (with DISCUSS) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 16:29:50 -0000 --001a11403ff87061aa0505a0df7c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Touch=C3=A9... ;) On Thu, Oct 16, 2014 at 4:36 PM, Richard Barnes wrote: > That's what you get for duplicating all the text :) > > On Thu, Oct 16, 2014 at 2:00 PM, Brian Campbell < > bcampbell@pingidentity.com> wrote: > >> Basically the same response to the basically same question as from >> http://www.ietf.org/mail-archive/web/oauth/current/msg13608.html >> >> On Wed, Oct 15, 2014 at 9:56 PM, Richard Barnes wrote: >> >>> Richard Barnes has entered the following ballot position for >>> draft-ietf-oauth-saml2-bearer-21: Discuss >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>> >>> >>> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.htm= l >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> As with draft-ietf-oauth-assertions, the requirement for an >>> element seems entirely unnecessary. Holding this DISCUSS point pending >>> that discussion and its reflection in this document. >>> >>> "Assertions that do not identify the Authorization Server as an intende= d >>> audience MUST be rejected." -- What does it mean for an assertion to >>> "identify the Authorization Server"? Does the specified nee= d >>> to match the entire URL of the relevant OAuth endpoint? Just the origi= n? >>> Just the domain? Does the URL need to be canonicalized? >>> >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> >> > --001a11403ff87061aa0505a0df7c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Touch=C3=A9... ;)

=
On Thu, Oct 16, 2014 at 4:36 PM, Richard Barnes = <rlb@i= pv.sx> wrote:
That's what you get for duplicating all the text :)

On Thu, Oct 16, 2014 at 2:00 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:
Basically the same response to the basically sam= e question as from http://www.ietf.org/mail-archive/web= /oauth/current/msg13608.html

On Wed, Oct 15, 2014 at 9:56 PM, Richard= Barnes <rlb@ipv.sx> wrote:
Richard Barnes has entered the following ballot position f= or
draft-ietf-oauth-saml2-bearer-21: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-crit= eria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-be= arer/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

As with draft-ietf-oauth-assertions, the requirement for an <Audience>= ;
element seems entirely unnecessary.=C2=A0 Holding this DISCUSS point pendin= g
that discussion and its reflection in this document.

"Assertions that do not identify the Authorization Server as an intend= ed
audience MUST be rejected." -- What does it mean for an assertion to "identify the Authorization Server"?=C2=A0 Does the specified <= ;Audience> need
to match the entire URL of the relevant OAuth endpoint?=C2=A0 Just the orig= in?
=C2=A0Just the domain?=C2=A0 Does the URL need to be canonicalized?




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



--001a11403ff87061aa0505a0df7c-- From nobody Fri Oct 17 09:49:59 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68B961A6F0D; Fri, 17 Oct 2014 09:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DyImw2ukTsp3; Fri, 17 Oct 2014 09:49:50 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70A651A6F0B; Fri, 17 Oct 2014 09:49:50 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s9HGnmcp014107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 17 Oct 2014 16:49:49 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s9HGnkBO006781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Oct 2014 16:49:46 GMT Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s9HGniPL028336; Fri, 17 Oct 2014 16:49:45 GMT Received: from [192.168.1.133] (/24.87.24.131) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 17 Oct 2014 09:49:43 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_DE3B1F47-5D19-48A7-A984-A03F9710E159" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: <19E82AEC-A5DA-41E9-9370-3FF16264DEAE@ve7jtb.com> Date: Fri, 17 Oct 2014 09:49:41 -0700 Message-Id: References: <20141016034735.18695.61014.idtracker@ietfa.amsl.com> <28A05FEA-9EEA-4E95-9B9F-587120A74BAA@ve7jtb.com> <19E82AEC-A5DA-41E9-9370-3FF16264DEAE@ve7jtb.com> To: John Bradley X-Mailer: Apple Mail (2.1878.6) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/iRs8I0vR-6s97v5sNtYni7vBS6Y Cc: "draft-ietf-oauth-assertions@tools.ietf.org" , Richard Barnes , "oauth-chairs@tools.ietf.org" , The IESG , oauth Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 16:49:54 -0000 --Apple-Mail=_DE3B1F47-5D19-48A7-A984-A03F9710E159 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I believe that if you make =93aud=94 optional, it only helps the = simplistic deployment scenarios where there is only one RS and one AS. = The optionality itself will cause more confusion. In the simplistic = case, the AS and RS simply have to agree on a URI. In more sophisticated domains where there is more than one RS service, = the =93aud=94 value is expected and is useful to determining who a token = is intended for. Finally, there is the 3rd level case where the AS and the RS are in = separate domains (federated). In this case, we can expect inter-op to be = required between separate vendors as a majority of cases. =20 Making =93aud=94 optional will greatly increase complexity in reality. = Making it a MUST only puts a trivial imposition on the trivial case = (they have to provide a made up URI). We did not really discuss =93aud" much on the list because it is well = known industry practice. I would not want to suggest re-writing = something that works well. Phil @independentid www.independentid.com phil.hunt@oracle.com On Oct 17, 2014, at 9:01 AM, John Bradley wrote: > I am good with it as is. I think we have the flexibility to add HoK = later. =20 >=20 > I mostly wanted to point out that it is really only in that later HoK = profile where omitting audience is safe. >=20 > If I had the power to remove the DISCUS I would. >=20 > John B. >=20 > On Oct 17, 2014, at 12:56 PM, Brian Campbell = wrote: >=20 >> These drafts define the use of bearer assertions. The only mention of = HoK style assertions is at the end of = https://tools.ietf.org/html/draft-ietf-oauth-assertions-17#section-3 = which notes that the "rules defined in this document are intended to = support a client presenting a bearer assertion to an authorization = server. The use of holder-of-key assertions are not precluded by this = document, but additional protocol details would need to be specified." >>=20 >> The requirement of having audience is for bearer assertions only (and = we agree need to be that way for bearer) and not intended to preclude = anything for HoK assertions.=20 >>=20 >> Does that change your opinion? Is there something that could be added = or removed or clarified to allay concerns? >>=20 >>=20 >>=20 >> On Thu, Oct 16, 2014 at 6:54 PM, John Bradley = wrote: >> Holder of key JWT is still in draft and we don't have a clear way to = present the proof to the token endpoint. >>=20 >> Brian and I started discussing that last week as I happen to have a = use case for a PoP JWT assertion flow in some other spec work. >>=20 >> I think that there is enough difference between bearer and PoP that = doing a follow on profile for SAML and JWT that can also cover the proof = presentment mechanisms makes the most sense. >>=20 >> I would go with restricting this to Bearer and MUST for audience, = and removing the audience requirement explicitly in the PoP profiles. >>=20 >> There are people who need the bearer version 6 months ago, I don't = want to do anything to hold it up based on future work. >>=20 >> I am happy to help with a SAML PoP/HoK draft as a follow on. The = SAML subject confirmation stuff is relatively clear so it is mostly = defining the presentment mechanisms like mutual TLS and a self signed = assertion. (we need to be careful not to conflate client authentication = and token proof, as they are different and might both be used at the = same time. >>=20 >> John B. >>=20 >> On Oct 16, 2014, at 7:20 PM, Richard Barnes wrote: >>=20 >>> You guys are all arguing that having an Audience can be useful. I = don't disagree. I disagree that it should be REQUIRED in all cases. >>>=20 >>> The Google vulnerability that Brian raised was an interesting read, = but as John points out, it only applies to Bearer Assertions. There's = no security requirement at all for holder-of-key assertions to have an = audience, since they can't be replayed by someone who doesn't hold the = key. >>>=20 >>> I could agree that an audience should be REQUIRED for bearer = assertions. Since they are vulnerable to replay, Audience protects = against the Authorization Server re-using the token. (It would be good = to say this explicitly in the doc, actually.) But for holder-of-key = assertions, the Audience should be OPTIONAL. Note that this requires = that instance documents define the difference between bearer assertions = and holder-of-key assertions, so that implementations can enforce these = requirements. >>>=20 >>> So it seems like there are two solutions here: >>> 1. Scope the document to bearer assertions only, and keep the MUST >>> 2. Keep the current scope, make Audience OPTIONAL for holder-of-key = assertions, and define the difference in the instance docs. >>>=20 >>> --Richard >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> On Thu, Oct 16, 2014 at 9:57 AM, Phil Hunt = wrote: >>> It is also important for a non-protocol purpose. Liability. >>>=20 >>> If a 3rd party uses an assertion that was not intended for it, it = cannot obviously hold the asserting party responsible. =20 >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>>=20 >>>=20 >>>=20 >>> On Oct 16, 2014, at 8:43 AM, Brian Campbell = wrote: >>>=20 >>>> Thanks for your review and feedback, Richard. Replies are inline = below... >>>>=20 >>>> On Wed, Oct 15, 2014 at 9:47 PM, Richard Barnes wrote: >>>> Richard Barnes has entered the following ballot position for >>>> draft-ietf-oauth-assertions-17: Discuss >>>>=20 >>>> When responding, please keep the subject line intact and reply to = all >>>> email addresses included in the To and CC lines. (Feel free to cut = this >>>> introductory paragraph, however.) >>>>=20 >>>>=20 >>>> Please refer to = http://www.ietf.org/iesg/statement/discuss-criteria.html >>>> for more information about IESG DISCUSS and COMMENT positions. >>>>=20 >>>>=20 >>>> The document, along with other ballot positions, can be found here: >>>> http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ >>>>=20 >>>>=20 >>>>=20 >>>> = ---------------------------------------------------------------------- >>>> DISCUSS: >>>> = ---------------------------------------------------------------------- >>>>=20 >>>> "The assertion MUST contain an Audience that identifies the = Authorization >>>> Server as the intended audience. Assertions that do not identify = the >>>> Authorization Server as an intended audience MUST be rejected." >>>>=20 >>>> Could you please identify the threat model within which this "MUST" = is >>>> required? This requirement doesn't follow from any of the threats >>>> elaborated in Section 8. >>>>=20 >>>> The Audience is only necessary if the Issuer wishes to constrain = the set >>>> of Authorization Servers with which an assertion may be used. So = ISTM >>>> that this should be "MAY contain..." >>>>=20 >>>>=20 >>>>=20 >>>> The audience restriction let's the issuer say specifically what = relying party is allowed to consume the assertion, which ensures that = the client can't use it somewhere else that it wasn't intended and that = the relying party that receives the assertion can't turn around and use = it to access some other service. >>>>=20 >>>> Strictly speaking, you are right that the audience is only = necessary if the Issuer wishes to constrain the set of Authorization = Servers with which an assertion may be used. But the Issuer really = really really should make that constraint and fully understanding the = implications of not doing so is difficult and unlikely.=20 >>>>=20 >>>> There was a vulnerability in Google apps SAML a few years back that = demonstrates how important audience restriction is and how it can be = difficult for even very sophisticated providers to get it all right. I = haven't had time to read it again to make sure but I think that this is = the paper http://www.ai-lab.it/armando/pub/fmse9-armando.pdf >>>>=20 >>>> I don't see what value allowing audience to be omitted brings other = than that it is academically a possibility. But requiring it (hopefully, = if the requirement is followed) helps reduce the possibility of a whole = bunch of security problems that folks likely won't foresee. >>>>=20 >>>> =20 >>>> = ---------------------------------------------------------------------- >>>> COMMENT: >>>> = ---------------------------------------------------------------------- >>>>=20 >>>> "keyed message digest" -> "Message Authentication Code" >>>>=20 >>>> That's the proper terminology [RFC4949], especially since there are = MACs >>>> that are not based on digests. >>>>=20 >>>> OK >>>> =20 >>>>=20 >>>> "This mechanism provides additional security properties." -- Please >>>> delete this or elaborate on what security properties it provides. >>>>=20 >>>> Will delete. >>>> =20 >>>>=20 >>>> Section 8.2 should note that "Holder-of-Key Assertions" are also a >>>> mitigation for this risk. >>>>=20 >>>>=20 >>>> OK >>>> =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 >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=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://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_DE3B1F47-5D19-48A7-A984-A03F9710E159 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I = believe that if you make =93aud=94 optional, it only helps the = simplistic deployment scenarios where there is only one RS and one AS. = The optionality itself will cause more confusion.  In the = simplistic case, the AS and RS simply have to agree on a = URI.

In more sophisticated domains where there is = more than one RS service, the =93aud=94 value is expected and is useful = to determining who a token is intended = for.

Finally, there is the 3rd level case where = the AS and the RS are in separate domains (federated). In this case, we = can expect inter-op to be required between separate vendors as a = majority of cases.  

Making =93aud=94 = optional will greatly increase complexity in reality.  Making it a = MUST only puts a trivial imposition on the trivial case (they have to = provide a made up URI).

We did not really = discuss =93aud" much on the list because it is well known industry = practice. I would not want to suggest re-writing something that works = well.


On Oct 17, 2014, at 9:01 AM, John Bradley <ve7jtb@ve7jtb.com> = wrote:

I am = good with it as is.  I think we have the flexibility to add HoK = later.    

I mostly wanted to point out = that it is really only in that later HoK profile where omitting audience = is safe.

If I had the power to remove the = DISCUS I would.

John = B.

On Oct 17, 2014, at 12:56 PM, Brian Campbell = <bcampbell@pingidentity.com&= gt; wrote:

These drafts define the use of = bearer assertions. The only mention of HoK style assertions is at the = end of https://tools.ietf.org/html/draft-ietf-oauth-assertions-= 17#section-3 which notes that the "rules defined in this document = are intended to support a client presenting a bearer assertion to an = authorization server.  The use of holder-of-key assertions are not = precluded by this document, but additional protocol details would need = to be specified."

The requirement of having audience = is for bearer assertions only (and we agree need to be that way = for bearer) and not intended to preclude anything for HoK = assertions.

Does that = change your opinion? Is there something that could be added or removed = or clarified to allay = concerns?



On Thu, Oct 16, = 2014 at 6:54 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
Holder of = key JWT is still in draft and we don't have a clear way to present the = proof to the token endpoint.

Brian and I started = discussing that last week as I happen to have a use case for a PoP JWT = assertion flow in some other spec work.

I think = that there is enough difference between bearer and PoP that doing a = follow on profile for SAML and JWT that can also cover the proof = presentment mechanisms makes the most sense.

I = would go with restricting this to Bearer and MUST for audience, =  and removing the audience requirement explicitly in the PoP = profiles.

There are people who need the bearer = version 6 months ago,  I don't want to do anything to hold it up = based on future work.

I am happy to help with a = SAML PoP/HoK draft as a follow on.   The SAML subject confirmation = stuff is relatively clear so it is mostly defining the presentment = mechanisms like mutual TLS and a self signed assertion. (we need to be = careful not to conflate client authentication and token proof, as they = are different and might both be used at the same = time.

John B.

On Oct 16, 2014, at 7:20 PM, Richard Barnes = <rlb@ipv.sx> = wrote:

You guys = are all arguing that having an Audience can be useful.  I don't = disagree.  I disagree that it should be REQUIRED in all = cases.

The Google vulnerability that Brian raised was = an interesting read, but as John points out, it only applies to Bearer = Assertions.  There's no security requirement at all for = holder-of-key assertions to have an audience, since they can't be = replayed by someone who doesn't hold the key.

I could = agree that an audience should be REQUIRED for bearer assertions.  = Since they are vulnerable to replay, Audience protects against the = Authorization Server re-using the token.  (It would be good to say = this explicitly in the doc, actually.)  But for holder-of-key = assertions, the Audience should be OPTIONAL.  Note that this = requires that instance documents define the difference between bearer = assertions and holder-of-key assertions, so that implementations can = enforce these requirements.

So it seems like there are = two solutions here:
1. Scope the document to bearer = assertions only, and keep the MUST
2. Keep the current = scope, make Audience OPTIONAL for holder-of-key assertions, and define = the difference in the instance = docs.

--Richard





On Thu, Oct 16, 2014 at 9:57 AM, Phil Hunt <phil.hunt@oracle.com> = wrote:
It is also important for a non-protocol = purpose. Liability.

If a 3rd party uses an assertion = that was not intended for it, it cannot obviously hold the asserting = party responsible.  


On Oct 16, 2014, at 8:43 AM, Brian Campbell <bcampbell@pingidentity.com> = wrote:

Thanks for your review and feedback, Richard.=20= Replies are inline below...

On Wed, Oct 15, = 2014 at 9:47 PM, Richard Barnes <rlb@ipv.sx> = wrote:
Richard = Barnes has entered the following ballot position for
draft-ietf-oauth-assertions-17: Discuss

When responding, please keep the subject line intact and reply to = all
email addresses included in the To and CC lines. (Feel free to cut = this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html=
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-oauth-asserti= ons/



= ----------------------------------------------------------------------
= DISCUSS:
= ----------------------------------------------------------------------
=
"The assertion MUST contain an Audience that identifies the = Authorization
Server as the intended audience.  Assertions that do not identify = the
Authorization Server as an intended audience MUST be rejected."

Could you please identify the threat model within which this "MUST" = is
required?  This requirement doesn't follow from any of the = threats
elaborated in Section 8.

The Audience is only necessary if the Issuer wishes to constrain the = set
of Authorization Servers with which an assertion may be used.  So = ISTM
that this should be "MAY contain..."



The audience restriction let's = the issuer say specifically what=20 relying party is allowed to consume the assertion, which ensures that=20 the client can't use it somewhere else that it wasn't intended and that = the=20 relying party that receives the assertion can't turn around and use it=20= to access some other service.

Strictly = speaking, you are right that the audience is only necessary if the = Issuer wishes to constrain the set of Authorization Servers with which = an assertion may be used. But the Issuer really really really should = make that constraint and fully understanding the implications of not = doing so is difficult and unlikely.

There was a = vulnerability in Google apps SAML a few years back that demonstrates how = important audience restriction is and how it can be difficult for = even very sophisticated providers to get it all right. I haven't had = time to read it again to make sure but I think that this is the paper http://www.ai-lab.it/armando/pub/fmse9-armando.pdf
I don't see what value allowing audience = to be omitted brings other than that it is academically a possibility. = But requiring it (hopefully, if the requirement is followed) helps = reduce the possibility of a whole bunch of security problems that folks = likely won't foresee.

 
= ----------------------------------------------------------------------
= COMMENT:
= ----------------------------------------------------------------------
=
"keyed message digest" -> "Message Authentication Code"

That's the proper terminology [RFC4949], especially since there are = MACs
that are not based on = digests.

OK
 
=

"This mechanism provides additional security properties." -- Please
delete this or elaborate on what security properties it = provides.

Will = delete.
 

Section 8.2 should note that "Holder-of-Key Assertions" are also a
mitigation for this risk.
=

OK
 
&nb= sp;
_______________________________________________
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


=

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

= = --Apple-Mail=_DE3B1F47-5D19-48A7-A984-A03F9710E159-- From nobody Fri Oct 17 10:10:44 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44FD31A1A96; Fri, 17 Oct 2014 10:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8lej8aIR430V; Fri, 17 Oct 2014 10:10:29 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0724.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:724]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57B711A1AEA; Fri, 17 Oct 2014 10:10:29 -0700 (PDT) Received: from CH1PR03CA005.namprd03.prod.outlook.com (10.255.156.150) by BLUPR03MB391.namprd03.prod.outlook.com (10.141.78.21) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Fri, 17 Oct 2014 17:10:04 +0000 Received: from BL2FFO11FD007.protection.gbl (10.255.156.132) by CH1PR03CA005.outlook.office365.com (10.255.156.150) with Microsoft SMTP Server (TLS) id 15.0.1054.13 via Frontend Transport; Fri, 17 Oct 2014 17:10:04 +0000 Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD007.mail.protection.outlook.com (10.173.161.3) with Microsoft SMTP Server (TLS) id 15.0.1039.16 via Frontend Transport; Fri, 17 Oct 2014 17:10:04 +0000 Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.93]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.03.0210.003; Fri, 17 Oct 2014 17:09:21 +0000 From: Mike Jones To: Phil Hunt , John Bradley Thread-Topic: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT) Thread-Index: AQHP6PPyEQ0Qm5p8FUevm57Q8TXNpZwy3f8AgAAUhoCAAFpTAIAAKwwAgAD78QCAAAGeAIAADVWAgAAFSJA= Date: Fri, 17 Oct 2014 17:09:21 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439BB16289@TK5EX14MBXC286.redmond.corp.microsoft.com> References: <20141016034735.18695.61014.idtracker@ietfa.amsl.com> <28A05FEA-9EEA-4E95-9B9F-587120A74BAA@ve7jtb.com> <19E82AEC-A5DA-41E9-9370-3FF16264DEAE@ve7jtb.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.73] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439BB16289TK5EX14MBXC286r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(438002)(52044002)(24454002)(51444003)(189002)(243025005)(377454003)(199003)(120916001)(99396003)(76482002)(33656002)(21056001)(26826002)(95666004)(104016003)(97736003)(19625215002)(66066001)(106116001)(64706001)(106466001)(19300405004)(31966008)(81156004)(20776003)(77096002)(19617315012)(107046002)(512954002)(86362001)(84676001)(85852003)(55846006)(15974865002)(92566001)(92726001)(16601075003)(86612001)(50986999)(93886004)(6806004)(16297215004)(76176999)(2656002)(15202345003)(80022003)(46102003)(230783001)(85306004)(71186001)(54356999)(84326002)(87936001)(69596002)(44976005)(19580405001)(16236675004)(68736004)(85806002)(4396001)(15975445006)(19580395003)(276003); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB391; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB391; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Exchange-Antispam-Report-Test: UriScan:; X-Forefront-PRVS: 0367A50BB1 Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/nL1NnTqwOveh9lZ7uQoHs3q9K8A Cc: Richard Barnes , "draft-ietf-oauth-assertions@tools.ietf.org" , "oauth-chairs@tools.ietf.org" , The IESG , oauth Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 17:10:37 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439BB16289TK5EX14MBXC286r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 This is the standard mitigation for a known set of actual attacks. We shou= ldn't even consider making it optional. -- Mike From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt Sent: Friday, October 17, 2014 9:50 AM To: John Bradley Cc: draft-ietf-oauth-assertions@tools.ietf.org; Richard Barnes; oauth-chair= s@tools.ietf.org; The IESG; oauth Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-asserti= ons-17: (with DISCUSS and COMMENT) I believe that if you make "aud" optional, it only helps the simplistic dep= loyment scenarios where there is only one RS and one AS. The optionality it= self will cause more confusion. In the simplistic case, the AS and RS simp= ly have to agree on a URI. In more sophisticated domains where there is more than one RS service, the = "aud" value is expected and is useful to determining who a token is intende= d for. Finally, there is the 3rd level case where the AS and the RS are in separat= e domains (federated). In this case, we can expect inter-op to be required = between separate vendors as a majority of cases. Making "aud" optional will greatly increase complexity in reality. Making = it a MUST only puts a trivial imposition on the trivial case (they have to = provide a made up URI). We did not really discuss "aud" much on the list because it is well known i= ndustry practice. I would not want to suggest re-writing something that wor= ks well. Phil @independentid www.independentid.com phil.hunt@oracle.com On Oct 17, 2014, at 9:01 AM, John Bradley > wrote: I am good with it as is. I think we have the flexibility to add HoK later. I mostly wanted to point out that it is really only in that later HoK profi= le where omitting audience is safe. If I had the power to remove the DISCUS I would. John B. On Oct 17, 2014, at 12:56 PM, Brian Campbell > wrote: These drafts define the use of bearer assertions. The only mention of HoK s= tyle assertions is at the end of https://tools.ietf.org/html/draft-ietf-oau= th-assertions-17#section-3 which notes that the "rules defined in this docu= ment are intended to support a client presenting a bearer assertion to an a= uthorization server. The use of holder-of-key assertions are not precluded= by this document, but additional protocol details would need to be specifi= ed." The requirement of having audience is for bearer assertions only (and we ag= ree need to be that way for bearer) and not intended to preclude anything f= or HoK assertions. Does that change your opinion? Is there something that could be added or re= moved or clarified to allay concerns? On Thu, Oct 16, 2014 at 6:54 PM, John Bradley > wrote: Holder of key JWT is still in draft and we don't have a clear way to presen= t the proof to the token endpoint. Brian and I started discussing that last week as I happen to have a use cas= e for a PoP JWT assertion flow in some other spec work. I think that there is enough difference between bearer and PoP that doing a= follow on profile for SAML and JWT that can also cover the proof presentme= nt mechanisms makes the most sense. I would go with restricting this to Bearer and MUST for audience, and remo= ving the audience requirement explicitly in the PoP profiles. There are people who need the bearer version 6 months ago, I don't want to= do anything to hold it up based on future work. I am happy to help with a SAML PoP/HoK draft as a follow on. The SAML sub= ject confirmation stuff is relatively clear so it is mostly defining the pr= esentment mechanisms like mutual TLS and a self signed assertion. (we need = to be careful not to conflate client authentication and token proof, as the= y are different and might both be used at the same time. John B. On Oct 16, 2014, at 7:20 PM, Richard Barnes >= wrote: You guys are all arguing that having an Audience can be useful. I don't di= sagree. I disagree that it should be REQUIRED in all cases. The Google vulnerability that Brian raised was an interesting read, but as = John points out, it only applies to Bearer Assertions. There's no security= requirement at all for holder-of-key assertions to have an audience, since= they can't be replayed by someone who doesn't hold the key. I could agree that an audience should be REQUIRED for bearer assertions. S= ince they are vulnerable to replay, Audience protects against the Authoriza= tion Server re-using the token. (It would be good to say this explicitly i= n the doc, actually.) But for holder-of-key assertions, the Audience shoul= d be OPTIONAL. Note that this requires that instance documents define the = difference between bearer assertions and holder-of-key assertions, so that = implementations can enforce these requirements. So it seems like there are two solutions here: 1. Scope the document to bearer assertions only, and keep the MUST 2. Keep the current scope, make Audience OPTIONAL for holder-of-key asserti= ons, and define the difference in the instance docs. --Richard On Thu, Oct 16, 2014 at 9:57 AM, Phil Hunt > wrote: It is also important for a non-protocol purpose. Liability. If a 3rd party uses an assertion that was not intended for it, it cannot ob= viously hold the asserting party responsible. Phil @independentid www.independentid.com phil.hunt@oracle.com On Oct 16, 2014, at 8:43 AM, Brian Campbell > wrote: Thanks for your review and feedback, Richard. Replies are inline below... On Wed, Oct 15, 2014 at 9:47 PM, Richard Barnes > wrote: Richard Barnes has entered the following ballot position for draft-ietf-oauth-assertions-17: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- "The assertion MUST contain an Audience that identifies the Authorization Server as the intended audience. Assertions that do not identify the Authorization Server as an intended audience MUST be rejected." Could you please identify the threat model within which this "MUST" is required? This requirement doesn't follow from any of the threats elaborated in Section 8. The Audience is only necessary if the Issuer wishes to constrain the set of Authorization Servers with which an assertion may be used. So ISTM that this should be "MAY contain..." The audience restriction let's the issuer say specifically what relying par= ty is allowed to consume the assertion, which ensures that the client can't= use it somewhere else that it wasn't intended and that the relying party t= hat receives the assertion can't turn around and use it to access some othe= r service. Strictly speaking, you are right that the audience is only necessary if the= Issuer wishes to constrain the set of Authorization Servers with which an = assertion may be used. But the Issuer really really really should make that= constraint and fully understanding the implications of not doing so is dif= ficult and unlikely. There was a vulnerability in Google apps SAML a few years back that demonst= rates how important audience restriction is and how it can be difficult for= even very sophisticated providers to get it all right. I haven't had time = to read it again to make sure but I think that this is the paper http://www= .ai-lab.it/armando/pub/fmse9-armando.pdf I don't see what value allowing audience to be omitted brings other than th= at it is academically a possibility. But requiring it (hopefully, if the re= quirement is followed) helps reduce the possibility of a whole bunch of sec= urity problems that folks likely won't foresee. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- "keyed message digest" -> "Message Authentication Code" That's the proper terminology [RFC4949], especially since there are MACs that are not based on digests. OK "This mechanism provides additional security properties." -- Please delete this or elaborate on what security properties it provides. Will delete. Section 8.2 should note that "Holder-of-Key Assertions" are also a mitigation for this risk. OK _______________________________________________ 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_4E1F6AAD24975D4BA5B16804296739439BB16289TK5EX14MBXC286r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1<= /p>

 <= /p>

This is the standard miti= gation for a known set of actual attacks.  We shouldn’t even con= sider making it optional.

 <= /p>

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

 <= /p>

From: OAuth [m= ailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Friday, October 17, 2014 9:50 AM
To: John Bradley
Cc: draft-ietf-oauth-assertions@tools.ietf.org; Richard Barnes; oaut= h-chairs@tools.ietf.org; The IESG; oauth
Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-= assertions-17: (with DISCUSS and COMMENT)

 

I believe that if you make “aud” optiona= l, it only helps the simplistic deployment scenarios where there is only on= e RS and one AS. The optionality itself will cause more confusion.  In= the simplistic case, the AS and RS simply have to agree on a URI.

 

In more sophisticated domains where there is more th= an one RS service, the “aud” value is expected and is useful to= determining who a token is intended for.

 

Finally, there is the 3rd level case where the AS an= d the RS are in separate domains (federated). In this case, we can expect i= nter-op to be required between separate vendors as a majority of cases. &nb= sp;

 

Making “aud” optional will greatly incre= ase complexity in reality.  Making it a MUST only puts a trivial impos= ition on the trivial case (they have to provide a made up URI).<= /p>

 

We did not really discuss “aud" much on t= he list because it is well known industry practice. I would not want to sug= gest re-writing something that works well.

 

Phil

 

@independentid<= /span>

ph= il.hunt@oracle.com

 

 

 

On Oct 17, 2014, at 9:01 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:<= /p>



I am good with it as is.  I think we have the f= lexibility to add HoK later.    

 

I mostly wanted to point out that it is really only = in that later HoK profile where omitting audience is safe.

 

If I had the power to remove the DISCUS I would.

 

John B.

 

On Oct 17, 2014, at 12:56 PM, Brian Campbell <bcampbell@pingidentity.com&g= t; wrote:



These drafts define t= he use of bearer assertions. The only mention of HoK style assertions is at= the end of https://tools.ietf.org/html/draft-ietf-oauth-assertions-17#section-3 wh= ich notes that the "rules defined in this document are intended to sup= port a client presenting a bearer assertion to an authorization server.&nbs= p; The use of holder-of-key assertions are not precluded by this document, but additional protocol details would need= to be specified."

The requirement of ha= ving audience is for bearer assertions only (and we agree need to be that w= ay for bearer) and not intended to preclude anything for HoK assertions.

Does that change your opinion? Is there something th= at could be added or removed or clarified to allay concerns?

 

 

On Thu, Oct 16, 2014 at 6:54 PM, John Bradley <ve7jtb@ve7jtb.com&= gt; wrote:

Holder of key JWT is still in draft and we don't hav= e a clear way to present the proof to the token endpoint.

 

Brian and I started discussing that last week as I h= appen to have a use case for a PoP JWT assertion flow in some other spec wo= rk.

 

I think that there is enough difference between bear= er and PoP that doing a follow on profile for SAML and JWT that can also co= ver the proof presentment mechanisms makes the most sense.

 

I would go with restricting this to Bearer and MUST = for audience,  and removing the audience requirement explicitly in the= PoP profiles.

 

There are people who need the bearer version 6 month= s ago,  I don't want to do anything to hold it up based on future work= .

 

I am happy to help with a SAML PoP/HoK draft as a fo= llow on.   The SAML subject confirmation stuff is relatively clear so = it is mostly defining the presentment mechanisms like mutual TLS and a self= signed assertion. (we need to be careful not to conflate client authentication and token proof, as they are differe= nt and might both be used at the same time.

 

John B.

 

On Oct 16, 2014, at 7:20 PM, Richard Barnes <rlb@ipv.sx> wrote:<= /o:p>



You guys are all argu= ing that having an Audience can be useful.  I don't disagree.  I = disagree that it should be REQUIRED in all cases.

The Google vulnerabil= ity that Brian raised was an interesting read, but as John points out, it o= nly applies to Bearer Assertions.  There's no security requirement at = all for holder-of-key assertions to have an audience, since they can't be replayed by someone who doesn't hold the = key.

I could agree that an= audience should be REQUIRED for bearer assertions.  Since they are vu= lnerable to replay, Audience protects against the Authorization Server re-u= sing the token.  (It would be good to say this explicitly in the doc, actually.)  But for holder-of-key asserti= ons, the Audience should be OPTIONAL.  Note that this requires that in= stance documents define the difference between bearer assertions and holder= -of-key assertions, so that implementations can enforce these requirements.

So it seems like there are two solutions here:<= /o:p>

1. Scope the document to bearer assertions only, and= keep the MUST

2. Keep the current s= cope, make Audience OPTIONAL for holder-of-key assertions, and define the d= ifference in the instance docs.

--Richard



 

 

 

On Thu, Oct 16, 2014 at 9:57 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

It is also important for a non-protocol purpose. Lia= bility.

 

If a 3rd party uses an assertion that was not intend= ed for it, it cannot obviously hold the asserting party responsible.  =

 

 

On Oct 16, 2014, at 8:43 AM, Brian Campbell <bcampbell@pingi= dentity.com> wrote:



Thanks for your review and feedback, Richard. Replie= s are inline below...

 

On Wed, Oct 15, 2014 at 9:47 PM, Richard Barnes <= rlb@ipv.sx> wrote:

Richard Barnes has en= tered the following ballot position for
draft-ietf-oauth-assertions-17: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions= /



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

"The assertion MUST contain an Audience that identifies the Authorizat= ion
Server as the intended audience.  Assertions that do not identify the<= br> Authorization Server as an intended audience MUST be rejected."

Could you please identify the threat model within which this "MUST&quo= t; is
required?  This requirement doesn't follow from any of the threats
elaborated in Section 8.

The Audience is only necessary if the Issuer wishes to constrain the set of Authorization Servers with which an assertion may be used.  So ISTM=
that this should be "MAY contain..."

 

The audience restriction let's the issuer say specif= ically what relying party is allowed to consume the assertion, which ensure= s that the client can't use it somewhere else that it wasn't intended and t= hat the relying party that receives the assertion can't turn around and use it to access some other service.

 

Strictly speaking, yo= u are right that the audience is only necessary if the Issuer wishes to con= strain the set of Authorization Servers with which an assertion may be used= . But the Issuer really really really should make that constraint and fully understanding the implications of no= t doing so is difficult and unlikely.

There was a vulnerabi= lity in Google apps SAML a few years back that demonstrates how important a= udience restriction is and how it can be difficult for even very sophistica= ted providers to get it all right. I haven't had time to read it again to make sure but I think that this is th= e paper http://www.ai-lab.it/armando/pub/fmse9-armando.pdf

I don't see what value allowing audience to be omitt= ed brings other than that it is academically a possibility. But requiring i= t (hopefully, if the requirement is followed) helps reduce the possibility = of a whole bunch of security problems that folks likely won't foresee.


 

----------------------------------------------------= ------------------
COMMENT:
----------------------------------------------------------------------

"keyed message digest" -> "Message Authentication Code&qu= ot;

That's the proper terminology [RFC4949], especially since there are MACs that are not based on digests.

 

OK

 


"This mechanism provides additional security properties." -- Plea= se
delete this or elaborate on what security properties it provides.

 

Will delete.

 


Section 8.2 should note that "Holder-of-Key Assertions" are also = a
mitigation for this risk.

 

OK

 

 

_______________________________________________
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

 

 

_______________________________________________
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

 

 

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

 

--_000_4E1F6AAD24975D4BA5B16804296739439BB16289TK5EX14MBXC286r_-- From nobody Fri Oct 17 10:26:08 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B6181A001D; Fri, 17 Oct 2014 10:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4nHzUINKu6wH; Fri, 17 Oct 2014 10:26:00 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D15A61A000F; Fri, 17 Oct 2014 10:25:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1413566760; x=1445102760; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=A/ORKs3J5kVH+rkRHyR2JtaHpA3jkUzfVPVOZdTWEuE=; b=YRijCqjcFi/pwZaL6vx7NndAiky8P1wS8Ffrv3kgT10K4JN+6zTnJPWs LJmfCWKd+GXayddDURSE6tysKlfCZYXysgLSAct5kCb2FLX9eA3MWZwV9 IZ+v9c6Yo/fZxKOJ0KZkkLGxUNnNWjDG6Gl5XqJCjlmCZNm5u6LTV/4tJ 8=; X-IronPort-AV: E=McAfee;i="5600,1067,7594"; a="75706191" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by wolverine01.qualcomm.com with ESMTP; 17 Oct 2014 10:25:58 -0700 X-IronPort-AV: E=Sophos; i="5.04,740,1406617200"; d="scan'208,217"; a="31552499" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 17 Oct 2014 10:25:57 -0700 Received: from NASANEXM01F.na.qualcomm.com (10.46.201.192) by nasanexhc04.na.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 17 Oct 2014 10:25:57 -0700 Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.46.201.192) with Microsoft SMTP Server (TLS) id 15.0.913.22; Fri, 17 Oct 2014 10:25:56 -0700 Message-ID: <54415122.9030902@qti.qualcomm.com> Date: Fri, 17 Oct 2014 12:25:54 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Mike Jones References: <20141016034735.18695.61014.idtracker@ietfa.amsl.com> <28A05FEA-9EEA-4E95-9B9F-587120A74BAA@ve7jtb.com> <19E82AEC-A5DA-41E9-9370-3FF16264DEAE@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739439BB16289@TK5EX14MBXC286.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439BB16289@TK5EX14MBXC286.redmond.corp.microsoft.com> Content-Type: multipart/alternative; boundary="------------040105000000030001020005" X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01C.na.qualcomm.com (129.46.53.236) To NASANEXM01F.na.qualcomm.com (10.46.201.192) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/uyAyumbStSg2AO2rIA2Lsmu5ym0 Cc: "draft-ietf-oauth-assertions@tools.ietf.org" , Richard Barnes , "oauth-chairs@tools.ietf.org" , The IESG , oauth Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 17:26:02 -0000 --------------040105000000030001020005 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit On 10/17/14 12:09 PM, Mike Jones wrote: > > This is the standard mitigation for a known set of actual attacks. We > shouldn't even consider making it optional. > Do you mean you shouldn't consider making it optional for HoK? Again, making it clear that the MUST applies only to bearer assertions, and that future extensions for HoK might have different requirements, is all that is being asked for here. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 --------------040105000000030001020005 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit On 10/17/14 12:09 PM, Mike Jones wrote:

This is the standard mitigation for a known set of actual attacks.  We shouldn’t even consider making it optional.


Do you mean you shouldn't consider making it optional for HoK? Again, making it clear that the MUST applies only to bearer assertions, and that future extensions for HoK might have different requirements, is all that is being asked for here.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
--------------040105000000030001020005-- From nobody Fri Oct 17 10:32:36 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A23491A0063 for ; Fri, 17 Oct 2014 10:32:34 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9v60E4mLmloJ for ; Fri, 17 Oct 2014 10:32:32 -0700 (PDT) Received: from mail-qg0-f44.google.com (mail-qg0-f44.google.com [209.85.192.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E6EF1A004B for ; Fri, 17 Oct 2014 10:32:32 -0700 (PDT) Received: by mail-qg0-f44.google.com with SMTP id j5so899894qga.3 for ; Fri, 17 Oct 2014 10:32:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=pw89O4suV1bHgVbpEHL8MHp3F76u22/usqd4JIVNnr4=; b=b9beOxH3/NzUV9Y7ojqBc7Z7dQrh242RQA5852Y3syU5irP+G6NEnAFS0rtXoAgABT GYbJM9HFC4i7IgLzlGtMSeK+Ntfvb7JRO0hJEjw/+LWyjN+wZ1CxJ19DAI8zLYM+Hn/7 O8fsA8fyPTeT4GK7BnSuaLIDd8jTylVmUYwGSxoSDvbj+P4uAt3eL3dxNEQ7hi69AvOF ArdTUD76SLn7R68gqE0i7h/9prYBgua3vJwlND8f9PElXw6JnY3VxHHJJvLzu1Q8UsV6 3XnWszv5FnacDjGuulQywVMMI9ieQqq5FVkUZJAvgpGvwQi/xn51T1IjeTfJuqEE6sZU 2JUg== X-Gm-Message-State: ALoCoQmSuwdNqVlsylJfl5HuWa2O/rchR5Ne/UQVWyJD4xQaKrNfmWC8cMuEoB+3iFFLOEtNjTh8 X-Received: by 10.140.33.183 with SMTP id j52mr13072873qgj.95.1413567151757; Fri, 17 Oct 2014 10:32:31 -0700 (PDT) Received: from [192.168.8.100] ([201.188.100.219]) by mx.google.com with ESMTPSA id p45sm1343956qgd.49.2014.10.17.10.32.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 17 Oct 2014 10:32:31 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_651E6B2E-70BD-4EBE-839B-83747B4C551E" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Bradley In-Reply-To: <54415122.9030902@qti.qualcomm.com> Date: Fri, 17 Oct 2014 14:32:26 -0300 Message-Id: <3E356AAD-8B64-42DF-8DAF-054DDFC58A30@ve7jtb.com> References: <20141016034735.18695.61014.idtracker@ietfa.amsl.com> <28A05FEA-9EEA-4E95-9B9F-587120A74BAA@ve7jtb.com> <19E82AEC-A5DA-41E9-9370-3FF16264DEAE@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739439BB16289@TK5EX14MBXC286.redmond.corp.microsoft.com> <54415122.9030902@qti.qualcomm.com> To: Pete Resnick X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/RP1bv_SlxLIPcbyt2_v9U49cDIU Cc: "draft-ietf-oauth-assertions@tools.ietf.org" , Richard Barnes , "oauth-chairs@tools.ietf.org" , The IESG , oauth Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 17:32:34 -0000 --Apple-Mail=_651E6B2E-70BD-4EBE-839B-83747B4C551E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I think this part of sec 3 of assertions states that: The protocol parameters and processing rules defined in this document are intended to support a client presenting a bearer assertion to an authorization server. The use of holder-of-key assertions are not precluded by this document, but additional protocol details would need to be specified. As part of defining the additional protocol details for = holder-of-key/PoP we can relax the must for audience in the profile that = defines how to use those assertion types. John B. On Oct 17, 2014, at 2:25 PM, Pete Resnick = wrote: > On 10/17/14 12:09 PM, Mike Jones wrote: >>=20 >> This is the standard mitigation for a known set of actual attacks. = We shouldn=92t even consider making it optional. >>=20 >>=20 >=20 > Do you mean you shouldn't consider making it optional for HoK? Again, = making it clear that the MUST applies only to bearer assertions, and = that future extensions for HoK might have different requirements, is all = that is being asked for here. >=20 > pr > --=20 > Pete Resnick > Qualcomm Technologies, Inc. - +1 (858)651-4478 --Apple-Mail=_651E6B2E-70BD-4EBE-839B-83747B4C551E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I = think this part of sec 3 of assertions states = that:

 The =
protocol parameters and processing rules defined in this document
   are intended to support a client presenting a bearer assertion to an
   authorization server.  The use of holder-of-key assertions are not
   precluded by this document, but additional protocol details would
   need to be specified.


As part = of defining the additional protocol details for holder-of-key/PoP we can = relax the must for audience in the profile that defines how to use those = assertion types.

John = B.

On Oct 17, 2014, at 2:25 PM, Pete = Resnick <presnick@qti.qualcomm.com>= ; wrote:

On 10/17/14 12:09 PM, Mike Jones wrote:

This is the standard mitigation for a known set of actual attacks.  We shouldn=92t even consider making it optional.


Do you mean you shouldn't consider making it optional for HoK? Again, making it clear that the MUST applies only to bearer assertions, and that future extensions for HoK might have different requirements, is all that is being asked for here.

pr
--=20
Pete Resnick <http://www.qualcomm.com/~p=
resnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

= --Apple-Mail=_651E6B2E-70BD-4EBE-839B-83747B4C551E-- From nobody Fri Oct 17 10:40:08 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3041A00AB; Fri, 17 Oct 2014 10:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OioRXoYVUFvr; Fri, 17 Oct 2014 10:40:05 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB76A1A0063; Fri, 17 Oct 2014 10:40:05 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s9HHe4o9009971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 17 Oct 2014 17:40:04 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s9HHe1OR025556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 17 Oct 2014 17:40:02 GMT Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s9HHe1LX029162; Fri, 17 Oct 2014 17:40:01 GMT Received: from [192.168.1.133] (/24.87.24.131) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 17 Oct 2014 10:40:00 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_77E05857-1853-4808-8C20-E78B63BAA0BC" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: <54415122.9030902@qti.qualcomm.com> Date: Fri, 17 Oct 2014 10:39:56 -0700 Message-Id: <33C566F9-C9A3-4E17-AC4E-50F1EAC0687F@oracle.com> References: <20141016034735.18695.61014.idtracker@ietfa.amsl.com> <28A05FEA-9EEA-4E95-9B9F-587120A74BAA@ve7jtb.com> <19E82AEC-A5DA-41E9-9370-3FF16264DEAE@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739439BB16289@TK5EX14MBXC286.redmond.corp.microsoft.com> <54415122.9030902@qti.qualcomm.com> To: Pete Resnick X-Mailer: Apple Mail (2.1878.6) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/YhWi5o37B5-HpEzroiA97-196cA Cc: "draft-ietf-oauth-assertions@tools.ietf.org" , Richard Barnes , "oauth-chairs@tools.ietf.org" , The IESG , oauth Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 17:40:07 -0000 --Apple-Mail=_77E05857-1853-4808-8C20-E78B63BAA0BC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 FWIW=85I was only responding to the question of making aud optional for = bearer tokens. The broader point is that regardless of token type, there is always an = =93aud=94 value =97 whether explicitly declared as a claim, or = implicitly implied (e.g. through encryption so only the audience can = consume it). Phil @independentid www.independentid.com phil.hunt@oracle.com On Oct 17, 2014, at 10:25 AM, Pete Resnick = wrote: > On 10/17/14 12:09 PM, Mike Jones wrote: >>=20 >> This is the standard mitigation for a known set of actual attacks. = We shouldn=92t even consider making it optional. >>=20 >>=20 >=20 > Do you mean you shouldn't consider making it optional for HoK? Again, = making it clear that the MUST applies only to bearer assertions, and = that future extensions for HoK might have different requirements, is all = that is being asked for here. >=20 > pr > --=20 > Pete Resnick > Qualcomm Technologies, Inc. - +1 (858)651-4478 --Apple-Mail=_77E05857-1853-4808-8C20-E78B63BAA0BC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 FWIW=85I= was only responding to the question of making aud optional for bearer = tokens.

The broader point is that regardless of token = type, there is always an =93aud=94 value =97 whether explicitly declared = as a claim, or implicitly implied (e.g. through encryption so only the = audience can consume it).


On Oct 17, 2014, at 10:25 AM, Pete Resnick <presnick@qti.qualcomm.com>= ; wrote:

On 10/17/14 12:09 PM, Mike Jones wrote:

This is the standard mitigation for a known set of actual attacks.  We shouldn=92t even consider making it optional.


Do you mean you shouldn't consider making it optional for HoK? Again, making it clear that the MUST applies only to bearer assertions, and that future extensions for HoK might have different requirements, is all that is being asked for here.

pr
--=20
Pete Resnick <http://www.qualcomm.com/~p=
resnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

= --Apple-Mail=_77E05857-1853-4808-8C20-E78B63BAA0BC-- From nobody Fri Oct 17 10:57:38 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B77B1A010F; Fri, 17 Oct 2014 10:57: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, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FobvMgGnljTp; Fri, 17 Oct 2014 10:57:32 -0700 (PDT) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 287911A0007; Fri, 17 Oct 2014 10:57:32 -0700 (PDT) Received: by mail-qa0-f54.google.com with SMTP id i13so858696qae.13 for ; Fri, 17 Oct 2014 10:57:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HYBYr63npCrxVDnARX9Gn2ypi9rwGmNHdeq3tRNCRns=; b=DpmNHeJquokKjFU7DhOgmq75NuNTHZjfdhACe5ZYQqVODPbrZc2DwVM2LKP9o2zQP5 CCB19BxlVt+YH4RdY76swpzwVc5m0FQor6ZVVlB7sp6+mG8sZWMmjJyHma9wPbf6647V hELNr0NbdaMCW5kinxyxVrk//0yWM9eNgu2AsEDDO9oz6odwA1l1HP/4qWVHj3dFtQRd N3GmDMxibt2CQNT4U3V6vld0PIDG/GlUC77mnRfq6ub8VuxYEjRS47jGYEsALxNRNPqD xT5nbDFSRGjN1DDxvQzX0tsQfj4qSeGFbgtRYMlYKs6fmI0BDAmslpKm8U7rZUiJuUs2 0k4w== X-Received: by 10.140.108.67 with SMTP id i61mr13416313qgf.90.1413568651254; Fri, 17 Oct 2014 10:57:31 -0700 (PDT) Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by mx.google.com with ESMTPSA id i2sm1412471qay.32.2014.10.17.10.57.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 17 Oct 2014 10:57:29 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: multipart/alternative; boundary=Apple-Mail-A0C9A7EB-9CB9-45F4-9FBA-F2CA715DEAB9 Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: Date: Fri, 17 Oct 2014 13:57:30 -0400 Content-Transfer-Encoding: 7bit Message-Id: <371475C1-25C7-4B64-B3AC-539C3701EB7F@gmail.com> References: <20141016034735.18695.61014.idtracker@ietfa.amsl.com> <28A05FEA-9EEA-4E95-9B9F-587120A74BAA@ve7jtb.com> To: Brian Campbell Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/vM0Sg3jzLCOlltw4bDk6ATFryyg Cc: "draft-ietf-oauth-assertions@tools.ietf.org" , Richard Barnes , "oauth-chairs@tools.ietf.org" , The IESG , oauth Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 17:57:36 -0000 --Apple-Mail-A0C9A7EB-9CB9-45F4-9FBA-F2CA715DEAB9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I just caught up on the thread again and think Brian's message below may be t= he most helpful to resolve this discuss. =20 It sounds like we have agreement that a MUST is preferred for bearer tokens a= nd that's what this draft is about. Would a language tweak help when HoK is= mentioned? The WG will have more time to figure out what is needed for tha= t in the draft mentioned that is on development. Thanks, Kathleen=20 Sent from my iPhone > On Oct 17, 2014, at 11:56 AM, Brian Campbell w= rote: >=20 > These drafts define the use of bearer assertions. The only mention of HoK s= tyle assertions is at the end of https://tools.ietf.org/html/draft-ietf-oaut= h-assertions-17#section-3 which notes that the "rules defined in this docume= nt are intended to support a client presenting a bearer assertion to an auth= orization server. The use of holder-of-key assertions are not precluded by t= his document, but additional protocol details would need to be specified." >=20 > The requirement of having audience is for bearer assertions only (and we a= gree need to be that way for bearer) and not intended to preclude anything f= or HoK assertions.=20 >=20 > Does that change your opinion? Is there something that could be added or r= emoved or clarified to allay concerns? >=20 >=20 >=20 >> On Thu, Oct 16, 2014 at 6:54 PM, John Bradley wrote: >> Holder of key JWT is still in draft and we don't have a clear way to pres= ent the proof to the token endpoint. >>=20 >> Brian and I started discussing that last week as I happen to have a use c= ase for a PoP JWT assertion flow in some other spec work. >>=20 >> I think that there is enough difference between bearer and PoP that doing= a follow on profile for SAML and JWT that can also cover the proof presentm= ent mechanisms makes the most sense. >>=20 >> I would go with restricting this to Bearer and MUST for audience, and re= moving the audience requirement explicitly in the PoP profiles. >>=20 >> There are people who need the bearer version 6 months ago, I don't want t= o do anything to hold it up based on future work. >>=20 >> I am happy to help with a SAML PoP/HoK draft as a follow on. The SAML s= ubject confirmation stuff is relatively clear so it is mostly defining the p= resentment mechanisms like mutual TLS and a self signed assertion. (we need t= o be careful not to conflate client authentication and token proof, as they a= re different and might both be used at the same time. >>=20 >> John B. >>=20 >>> On Oct 16, 2014, at 7:20 PM, Richard Barnes wrote: >>>=20 >>> You guys are all arguing that having an Audience can be useful. I don't= disagree. I disagree that it should be REQUIRED in all cases. >>>=20 >>> The Google vulnerability that Brian raised was an interesting read, but a= s John points out, it only applies to Bearer Assertions. There's no securit= y requirement at all for holder-of-key assertions to have an audience, since= they can't be replayed by someone who doesn't hold the key. >>>=20 >>> I could agree that an audience should be REQUIRED for bearer assertions.= Since they are vulnerable to replay, Audience protects against the Authori= zation Server re-using the token. (It would be good to say this explicitly i= n the doc, actually.) But for holder-of-key assertions, the Audience should= be OPTIONAL. Note that this requires that instance documents define the di= fference between bearer assertions and holder-of-key assertions, so that imp= lementations can enforce these requirements. >>>=20 >>> So it seems like there are two solutions here: >>> 1. Scope the document to bearer assertions only, and keep the MUST >>> 2. Keep the current scope, make Audience OPTIONAL for holder-of-key asse= rtions, and define the difference in the instance docs. >>>=20 >>> --Richard >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>> On Thu, Oct 16, 2014 at 9:57 AM, Phil Hunt wrote= : >>>> It is also important for a non-protocol purpose. Liability. >>>>=20 >>>> If a 3rd party uses an assertion that was not intended for it, it canno= t obviously hold the asserting party responsible. =20 >>>>=20 >>>> Phil >>>>=20 >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>>=20 >>>>=20 >>>>=20 >>>>> On Oct 16, 2014, at 8:43 AM, Brian Campbell wrote: >>>>>=20 >>>>> Thanks for your review and feedback, Richard. Replies are inline below= ... >>>>>=20 >>>>>> On Wed, Oct 15, 2014 at 9:47 PM, Richard Barnes wrote: >>>>>> Richard Barnes has entered the following ballot position for >>>>>> draft-ietf-oauth-assertions-17: Discuss >>>>>>=20 >>>>>> When responding, please keep the subject line intact and reply to all= >>>>>> email addresses included in the To and CC lines. (Feel free to cut th= is >>>>>> introductory paragraph, however.) >>>>>>=20 >>>>>>=20 >>>>>> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.h= tml >>>>>> for more information about IESG DISCUSS and COMMENT positions. >>>>>>=20 >>>>>>=20 >>>>>> The document, along with other ballot positions, can be found here: >>>>>> http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> ---------------------------------------------------------------------= - >>>>>> DISCUSS: >>>>>> ---------------------------------------------------------------------= - >>>>>>=20 >>>>>> "The assertion MUST contain an Audience that identifies the Authoriza= tion >>>>>> Server as the intended audience. Assertions that do not identify the= >>>>>> Authorization Server as an intended audience MUST be rejected." >>>>>>=20 >>>>>> Could you please identify the threat model within which this "MUST" i= s >>>>>> required? This requirement doesn't follow from any of the threats >>>>>> elaborated in Section 8. >>>>>>=20 >>>>>> The Audience is only necessary if the Issuer wishes to constrain the s= et >>>>>> of Authorization Servers with which an assertion may be used. So IST= M >>>>>> that this should be "MAY contain..." >>>>>=20 >>>>>=20 >>>>> The audience restriction let's the issuer say specifically what relyin= g party is allowed to consume the assertion, which ensures that the client c= an't use it somewhere else that it wasn't intended and that the relying part= y that receives the assertion can't turn around and use it to access some ot= her service. >>>>>=20 >>>>> Strictly speaking, you are right that the audience is only necessary i= f the Issuer wishes to constrain the set of Authorization Servers with which= an assertion may be used. But the Issuer really really really should make t= hat constraint and fully understanding the implications of not doing so is d= ifficult and unlikely.=20 >>>>>=20 >>>>> There was a vulnerability in Google apps SAML a few years back that de= monstrates how important audience restriction is and how it can be difficult= for even very sophisticated providers to get it all right. I haven't had ti= me to read it again to make sure but I think that this is the paper http://w= ww.ai-lab.it/armando/pub/fmse9-armando.pdf >>>>>=20 >>>>> I don't see what value allowing audience to be omitted brings other th= an that it is academically a possibility. But requiring it (hopefully, if th= e requirement is followed) helps reduce the possibility of a whole bunch of s= ecurity problems that folks likely won't foresee. >>>>>=20 >>>>> =20 >>>>>> ---------------------------------------------------------------------= - >>>>>> COMMENT: >>>>>> ---------------------------------------------------------------------= - >>>>>>=20 >>>>>> "keyed message digest" -> "Message Authentication Code" >>>>>>=20 >>>>>> That's the proper terminology [RFC4949], especially since there are M= ACs >>>>>> that are not based on digests. >>>>>=20 >>>>> OK >>>>> =20 >>>>>>=20 >>>>>> "This mechanism provides additional security properties." -- Please >>>>>> delete this or elaborate on what security properties it provides. >>>>>=20 >>>>> Will delete. >>>>> =20 >>>>>>=20 >>>>>> Section 8.2 should note that "Holder-of-Key Assertions" are also a >>>>>> mitigation for this risk. >>>>>=20 >>>>> OK >>>>> =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 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail-A0C9A7EB-9CB9-45F4-9FBA-F2CA715DEAB9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I just caught up on the thread again a= nd think Brian's message below may be the most helpful to resolve this discu= ss.  

It sounds like we have agreement that a M= UST is preferred for bearer tokens and that's what this draft is about. &nbs= p;Would a language tweak help when HoK is mentioned?  The WG will have m= ore time to figure out what is needed for that in the draft mentioned that i= s on development.

Thanks,
Kathleen <= br>
Sent from my iPhone

On Oct 17, 2014, at 11:56 AM, Brian= Campbell <bcampbell@pingid= entity.com> wrote:

These drafts define the use of bearer assertions. The only m= ention of HoK style assertions is at the end of https= ://tools.ietf.org/html/draft-ietf-oauth-assertions-17#section-3 which no= tes that the "rules defined in this document are intended to support a clien= t presenting a bearer assertion to an authorization server.  The use of= holder-of-key assertions are not precluded by this document, but additional= protocol details would need to be specified."

The require= ment of having audience is for bearer assertions only (and we agree ne= ed to be that way for bearer) and not intended to preclude anything for HoK a= ssertions.

Does that change you= r opinion? Is there something that could be added or removed or clarified to= allay concerns?



On Thu, Oct 16, 2014 at 6= :54 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
Holder of key JWT is s= till in draft and we don't have a clear way to present the proof to the toke= n endpoint.

Brian and I started discussing that last week= as I happen to have a use case for a PoP JWT assertion flow in some other s= pec work.

I think that there is enough difference b= etween bearer and PoP that doing a follow on profile for SAML and JWT that c= an also cover the proof presentment mechanisms makes the most sense.

I would go with restricting this to Bearer and MUST for au= dience,  and removing the audience requirement explicitly in the PoP pr= ofiles.

There are people who need the bearer versio= n 6 months ago,  I don't want to do anything to hold it up based on fut= ure work.

I am happy to help with a SAML PoP/HoK dr= aft as a follow on.   The SAML subject confirmation stuff is relatively= clear so it is mostly defining the presentment mechanisms like mutual TLS a= nd a self signed assertion. (we need to be careful not to conflate client au= thentication and token proof, as they are different and might both be used a= t the same time.

John B.

On Oct 16, 2014, at 7:20 PM, Richard Barnes <rlb@ipv.sx> wrote:

=
You guys are all arguing tha= t having an Audience can be useful.  I don't disagree.  I disagree= that it should be REQUIRED in all cases.

The Google vulne= rability that Brian raised was an interesting read, but as John points out, i= t only applies to Bearer Assertions.  There's no security requirement a= t all for holder-of-key assertions to have an audience, since they can't be r= eplayed by someone who doesn't hold the key.

I could agree= that an audience should be REQUIRED for bearer assertions.  Since they= are vulnerable to replay, Audience protects against the Authorization Serve= r re-using the token.  (It would be good to say this explicitly in the d= oc, actually.)  But for holder-of-key assertions, the Audience should b= e OPTIONAL.  Note that this requires that instance documents define the= difference between bearer assertions and holder-of-key assertions, so that i= mplementations can enforce these requirements.

So it seems= like there are two solutions here:
1. Scope the document to b= earer assertions only, and keep the MUST
2. Keep the current s= cope, make Audience OPTIONAL for holder-of-key assertions, and define the di= fference in the instance docs.

--Richard





On Thu, Oct 16, 2014 at 9:57 AM, Phil Hunt <phil.hun= t@oracle.com> wrote:
It is also important for a non-protocol purpose.= Liability.

If a 3rd party uses an assertion that was not= intended for it, it cannot obviously hold the asserting party responsible. &= nbsp;



On Oct 16, 2014, at 8:43 AM, Brian Campbell <bcampbell@pingidentity.com= > wrote:

Th= anks for your review and feedback, Richard.=20 Replies are inline below...

On Wed, Oct 15, 2014 at 9:47 PM, Richard Barnes <rlb@ipv.sx> wrote:
Rich= ard Barnes has entered the following ballot position for
draft-ietf-oauth-assertions-17: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criter= ia.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/<= /a>



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

"The assertion MUST contain an Audience that identifies the Authorization Server as the intended audience.  Assertions that do not identify the Authorization Server as an intended audience MUST be rejected."

Could you please identify the threat model within which this "MUST" is
required?  This requirement doesn't follow from any of the threats
elaborated in Section 8.

The Audience is only necessary if the Issuer wishes to constrain the set
= of Authorization Servers with which an assertion may be used.  So ISTM<= br> that this should be "MAY contain..."

I don't see what value allowing audience to be omitted= brings other than that it is academically a possibility. But requiring it (= hopefully, if the requirement is followed) helps reduce the possibility of a= whole bunch of security problems that folks likely won't foresee.

 
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

"keyed message digest" -> "Message Authentication Code"

That's the proper terminology [RFC4949], especially since there are MACs
= that are not based on digests.

OK
 

"This mechanism provides additional security properties." -- Please
delete this or elaborate on what security properties it provides.

Will delete.
 

Section 8.2 should note that "Holder-of-Key Assertions" are also a
mitigation for this risk.


OK
 
 = ;
_______________________________________________
OAuth mailing list
OAuth@ietf.org
ht= tps://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
ht= tps://www.ietf.org/mailman/listinfo/oauth


= --Apple-Mail-A0C9A7EB-9CB9-45F4-9FBA-F2CA715DEAB9-- From nobody Fri Oct 17 11:05:01 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 830321A01F9 for ; Fri, 17 Oct 2014 11:05:00 -0700 (PDT) X-Quarantine-ID: <7GPMfD5-JzPA> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains text/plain,.exe X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7GPMfD5-JzPA for ; Fri, 17 Oct 2014 11:04:58 -0700 (PDT) Received: from mail-vc0-f169.google.com (mail-vc0-f169.google.com [209.85.220.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 623261A00F0 for ; Fri, 17 Oct 2014 11:04:58 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id hy4so1016925vcb.0 for ; Fri, 17 Oct 2014 11:04:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=eJHVx7kV+cX7g5gcTi3YsOLM9hva7ehfjQ86W38CJfM=; b=hAT8ZZQZYp3FmE9ycxUddDknI8HVQOssFvRDp8w5fUFLrxWRx7KKwgLGb/NESxrfhQ kEJzMm75fw7ux2B0hhZg6jAZvoOZH8AKRoO2LJOntddmBh1WxVNCgFMuKCXxrcHyOUat w0tOTRLlovhemIK5i4bMxMsD8xRX+TBvBzMXQDf9toowmmWeUKdbN+1vzPwJrzMultVB UtCtowLB0UgMNcnLFNG4jBLi9GVS9zu3e+cElqxvuZKJsCkWXFTGS+CzaNwG3svIB/YU Hlr3EK0sF2HKLMn9R+E4bVqjXCxsnQDpPSg308q02QY+BYunel59SSPp+Wm/EtHWVx3q 6/uA== X-Gm-Message-State: ALoCoQmx7M9Eo/qXfVBPaUbxYfoJz3L6h9fY4VAPZ9l2cFdtJqGDVd1Vx8qy28dY7ISvBIFLAW8i MIME-Version: 1.0 X-Received: by 10.220.190.72 with SMTP id dh8mr8784073vcb.35.1413569097496; Fri, 17 Oct 2014 11:04:57 -0700 (PDT) Received: by 10.31.149.205 with HTTP; Fri, 17 Oct 2014 11:04:57 -0700 (PDT) In-Reply-To: <3E356AAD-8B64-42DF-8DAF-054DDFC58A30@ve7jtb.com> References: <20141016034735.18695.61014.idtracker@ietfa.amsl.com> <28A05FEA-9EEA-4E95-9B9F-587120A74BAA@ve7jtb.com> <19E82AEC-A5DA-41E9-9370-3FF16264DEAE@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739439BB16289@TK5EX14MBXC286.redmond.corp.microsoft.com> <54415122.9030902@qti.qualcomm.com> <3E356AAD-8B64-42DF-8DAF-054DDFC58A30@ve7jtb.com> Date: Fri, 17 Oct 2014 11:04:57 -0700 Message-ID: From: Richard Barnes To: John Bradley Content-Type: multipart/alternative; boundary=001a11c1bc68ec3d0e0505a233b6 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/TgAvXG1z4w4ExJsXqqRxFeSilLk Cc: "draft-ietf-oauth-assertions@tools.ietf.org" , Pete Resnick , oauth , The IESG , "oauth-chairs@tools.ietf.org" Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 18:05:00 -0000 --001a11c1bc68ec3d0e0505a233b6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Oct 17, 2014 at 10:32 AM, John Bradley wrote: > I think this part of sec 3 of assertions states that: > > The protocol parameters and processing rules defined in this document > are intended to support a client presenting a bearer assertion to an > authorization server. The use of holder-of-key assertions are not > precluded by this document, but additional protocol details would > need to be specified. > > > > As part of defining the additional protocol details for holder-of-key/PoP > we can relax the must for audience in the profile that defines how to use > those assertion types. > I think we're on a path to convergence here. Given all this, is there any point to even mentioning HoK credentials here? The entire remainder of the spec is written as if they didn't exist. And as the text above notes, you can't actually use them with this specification. If we're going to keep the mention, could we augment the text above to make it clearer that HoK assertions are out of scope. """ The protocol parameters and processing rules defined in this document are intended to support a client presenting a bearer assertion to an authorization server. They are not suitable for use with holder-of-key assertions. While they could be used as a baseline for a holder-of-key assertion system, there would be a need for additional mechanisms (to support proof of possession of the secret key), and possibly changes to the security model (e.g., to relax the requirement for an Audience). """ --Richard > > John B. > > On Oct 17, 2014, at 2:25 PM, Pete Resnick > wrote: > > On 10/17/14 12:09 PM, Mike Jones wrote: > > This is the standard mitigation for a known set of actual attacks. We > shouldn=E2=80=99t even consider making it optional. > > > Do you mean you shouldn't consider making it optional for HoK? Again, > making it clear that the MUST applies only to bearer assertions, and that > future extensions for HoK might have different requirements, is all that = is > being asked for here. > > pr > > -- > Pete Resnick > Qualcomm Technologies, Inc. - +1 (858)651-4478 > > > --001a11c1bc68ec3d0e0505a233b6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Oct 17, 2014 at 10:32 AM, John Bradley <ve7jtb@= ve7jtb.com> wrote:
I think this part of sec 3 of assertions states= that:

 The protocol parameters and processing rules defined in this =
document
   are intended to support a client presenting a bearer assertion to an
   authorization server.  The use of holder-of-key assertions are not
   precluded by this document, but additional protocol details would
   need to be specified.


As part of= defining the additional protocol details for holder-of-key/PoP we can rela= x the must for audience in the profile that defines how to use those assert= ion types.

I think we'= ;re on a path to convergence here.

Given all t= his, is there any point to even mentioning HoK credentials here?=C2=A0 The = entire remainder of the spec is written as if they didn't exist.=C2=A0 = And as the text above notes, you can't actually use them with this spec= ification.

If we're going to keep the mention, could = we augment the text above to make it clearer that HoK assertions are out of= scope.

"""
The protocol par= ameters and processing rules defined in this document
are intended to su= pport a client presenting a bearer assertion to an
authorization server.= =C2=A0 They are not suitable for use with holder-of-key
assertions.=C2= =A0 While they could be used as a baseline for a holder-of-key
assertion system, there would be a need for additional mechanisms
(to support proof of possession of the secret key), and possibly cha= nges
to the security model (e.g., to relax the requirement for an Audien= ce).
"""

--Richard


=C2=A0
=

John B.
<= div>

On Oct 17, 2014, at 2:25 PM,= Pete Resnick <presnick@qti.qualcomm.com> wrote:

=20
On 10/17/14 12:09 PM, Mike Jones wrote:

This is the standard mitigation for a known set of actual attacks.=C2=A0 We shouldn=E2=80=99t even consider making it optional.


Do you mean you shouldn't consider making it optional for HoK? Again, making it clear that the MUST applies only to bearer assertions, and that future extensions for HoK might have different requirements, is all that is being asked for here.

pr
--=20
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478


--001a11c1bc68ec3d0e0505a233b6-- From nobody Fri Oct 17 11:06:13 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6F381A0258 for ; Fri, 17 Oct 2014 11:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8uqMLxULc4n for ; Fri, 17 Oct 2014 11:06:02 -0700 (PDT) Received: from mail-vc0-f169.google.com (mail-vc0-f169.google.com [209.85.220.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B43791A00F0 for ; Fri, 17 Oct 2014 11:06:01 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id hy4so1018409vcb.0 for ; Fri, 17 Oct 2014 11:06:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=UIcR7ms5l1b3w7fGEKug/83krflfqXhtkUqdRaiSnOo=; b=TmVkEAnSQ7iCQHIVRav00uDFVdFVcxMta/o3E1qMRugXeI0MdAzT71DbA4liQ9QI/N fg6eeIrCf8z5NStWfRS/ru5oktrp24WUK3JfXTNuhAaznRYkB1X7jUH0cVzyovj7cG0F 5BR+qTGWCVsGumQ46kmnDSrIJGgAUGVLauwcpqwKEEqjY9XYSFs8mo1me+JqbIex4rb/ QZOIcYNiaegKy5cmHQCVRGMRHrJ9fEslgIddXhzaY9d0TPc1wGBxRhPjHGnBu67UDYud KMU/4T1Fyk4OxI/EiIP/deehsJLYq6LIRP0HL+zBAoiSt8r4UI946UqyU8LfTtDmnldA +Kew== X-Gm-Message-State: ALoCoQmSBhIF41Jt0DlMBh14Xtd/y7v3Rbwcs0hTIF+09GnT0YfeN/1myBYCBTUYIFJaYqGe8nvr MIME-Version: 1.0 X-Received: by 10.220.12.18 with SMTP id v18mr8775546vcv.24.1413569160863; Fri, 17 Oct 2014 11:06:00 -0700 (PDT) Received: by 10.31.149.205 with HTTP; Fri, 17 Oct 2014 11:06:00 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439BB16289@TK5EX14MBXC286.redmond.corp.microsoft.com> References: <20141016034735.18695.61014.idtracker@ietfa.amsl.com> <28A05FEA-9EEA-4E95-9B9F-587120A74BAA@ve7jtb.com> <19E82AEC-A5DA-41E9-9370-3FF16264DEAE@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739439BB16289@TK5EX14MBXC286.redmond.corp.microsoft.com> Date: Fri, 17 Oct 2014 11:06:00 -0700 Message-ID: From: Richard Barnes To: Mike Jones Content-Type: multipart/alternative; boundary=001a11c3ce16b32dff0505a237af Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/2DlWaDmgOnSlo4q9CGTVuItk1oQ Cc: "draft-ietf-oauth-assertions@tools.ietf.org" , "oauth-chairs@tools.ietf.org" , The IESG , oauth Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 18:06:07 -0000 --001a11c3ce16b32dff0505a237af Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It's a known set of actual attacks ... on bearer assertions. There is no corresponding attack on HoK assertions. We shouldn't consider making it optional for bearer assertions. For HoK, there's no reason for it not to be optional. On Fri, Oct 17, 2014 at 10:09 AM, Mike Jones wrote: > +1 > > > > This is the standard mitigation for a known set of actual attacks. We > shouldn=E2=80=99t even consider making it optional. > > > > -- Mike > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Phil Hunt > *Sent:* Friday, October 17, 2014 9:50 AM > *To:* John Bradley > *Cc:* draft-ietf-oauth-assertions@tools.ietf.org; Richard Barnes; > oauth-chairs@tools.ietf.org; The IESG; oauth > *Subject:* Re: [OAUTH-WG] Richard Barnes' Discuss on > draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT) > > > > I believe that if you make =E2=80=9Caud=E2=80=9D optional, it only helps = the simplistic > deployment scenarios where there is only one RS and one AS. The optionali= ty > itself will cause more confusion. In the simplistic case, the AS and RS > simply have to agree on a URI. > > > > In more sophisticated domains where there is more than one RS service, th= e > =E2=80=9Caud=E2=80=9D value is expected and is useful to determining who = a token is > intended for. > > > > Finally, there is the 3rd level case where the AS and the RS are in > separate domains (federated). In this case, we can expect inter-op to be > required between separate vendors as a majority of cases. > > > > Making =E2=80=9Caud=E2=80=9D optional will greatly increase complexity in= reality. Making > it a MUST only puts a trivial imposition on the trivial case (they have t= o > provide a made up URI). > > > > We did not really discuss =E2=80=9Caud" much on the list because it is we= ll known > industry practice. I would not want to suggest re-writing something that > works well. > > > > Phil > > > > @independentid > > www.independentid.com > > phil.hunt@oracle.com > > > > > > > > On Oct 17, 2014, at 9:01 AM, John Bradley wrote: > > > > I am good with it as is. I think we have the flexibility to add HoK > later. > > > > I mostly wanted to point out that it is really only in that later HoK > profile where omitting audience is safe. > > > > If I had the power to remove the DISCUS I would. > > > > John B. > > > > On Oct 17, 2014, at 12:56 PM, Brian Campbell > wrote: > > > > These drafts define the use of bearer assertions. The only mention of > HoK style assertions is at the end of > https://tools.ietf.org/html/draft-ietf-oauth-assertions-17#section-3 > which notes that the "rules defined in this document are intended to > support a client presenting a bearer assertion to an authorization server= . > The use of holder-of-key assertions are not precluded by this document, b= ut > additional protocol details would need to be specified." > > The requirement of having audience is for bearer assertions only (and we > agree need to be that way for bearer) and not intended to preclude anythi= ng > for HoK assertions. > > Does that change your opinion? Is there something that could be added or > removed or clarified to allay concerns? > > > > > > On Thu, Oct 16, 2014 at 6:54 PM, John Bradley wrote: > > Holder of key JWT is still in draft and we don't have a clear way to > present the proof to the token endpoint. > > > > Brian and I started discussing that last week as I happen to have a use > case for a PoP JWT assertion flow in some other spec work. > > > > I think that there is enough difference between bearer and PoP that doing > a follow on profile for SAML and JWT that can also cover the proof > presentment mechanisms makes the most sense. > > > > I would go with restricting this to Bearer and MUST for audience, and > removing the audience requirement explicitly in the PoP profiles. > > > > There are people who need the bearer version 6 months ago, I don't want > to do anything to hold it up based on future work. > > > > I am happy to help with a SAML PoP/HoK draft as a follow on. The SAML > subject confirmation stuff is relatively clear so it is mostly defining t= he > presentment mechanisms like mutual TLS and a self signed assertion. (we > need to be careful not to conflate client authentication and token proof, > as they are different and might both be used at the same time. > > > > John B. > > > > On Oct 16, 2014, at 7:20 PM, Richard Barnes wrote: > > > > You guys are all arguing that having an Audience can be useful. I > don't disagree. I disagree that it should be REQUIRED in all cases. > > The Google vulnerability that Brian raised was an interesting read, but a= s > John points out, it only applies to Bearer Assertions. There's no securi= ty > requirement at all for holder-of-key assertions to have an audience, sinc= e > they can't be replayed by someone who doesn't hold the key. > > I could agree that an audience should be REQUIRED for bearer assertions. > Since they are vulnerable to replay, Audience protects against the > Authorization Server re-using the token. (It would be good to say this > explicitly in the doc, actually.) But for holder-of-key assertions, the > Audience should be OPTIONAL. Note that this requires that instance > documents define the difference between bearer assertions and holder-of-k= ey > assertions, so that implementations can enforce these requirements. > > So it seems like there are two solutions here: > > 1. Scope the document to bearer assertions only, and keep the MUST > > 2. Keep the current scope, make Audience OPTIONAL for holder-of-key > assertions, and define the difference in the instance docs. > > --Richard > > > > > > > > > > On Thu, Oct 16, 2014 at 9:57 AM, Phil Hunt wrote: > > It is also important for a non-protocol purpose. Liability. > > > > If a 3rd party uses an assertion that was not intended for it, it cannot > obviously hold the asserting party responsible. > > > > Phil > > > > @independentid > > www.independentid.com > > phil.hunt@oracle.com > > > > > > > > On Oct 16, 2014, at 8:43 AM, Brian Campbell > wrote: > > > > Thanks for your review and feedback, Richard. Replies are inline below..= . > > > > On Wed, Oct 15, 2014 at 9:47 PM, Richard Barnes wrote: > > Richard Barnes has entered the following ballot position for > draft-ietf-oauth-assertions-17: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > "The assertion MUST contain an Audience that identifies the Authorization > Server as the intended audience. Assertions that do not identify the > Authorization Server as an intended audience MUST be rejected." > > Could you please identify the threat model within which this "MUST" is > required? This requirement doesn't follow from any of the threats > elaborated in Section 8. > > The Audience is only necessary if the Issuer wishes to constrain the set > of Authorization Servers with which an assertion may be used. So ISTM > that this should be "MAY contain..." > > > > The audience restriction let's the issuer say specifically what relying > party is allowed to consume the assertion, which ensures that the client > can't use it somewhere else that it wasn't intended and that the relying > party that receives the assertion can't turn around and use it to access > some other service. > > > > Strictly speaking, you are right that the audience is only necessary if > the Issuer wishes to constrain the set of Authorization Servers with whic= h > an assertion may be used. But the Issuer really really really should make > that constraint and fully understanding the implications of not doing so = is > difficult and unlikely. > > There was a vulnerability in Google apps SAML a few years back that > demonstrates how important audience restriction is and how it can be > difficult for even very sophisticated providers to get it all right. I > haven't had time to read it again to make sure but I think that this is t= he > paper http://www.ai-lab.it/armando/pub/fmse9-armando.pdf > > I don't see what value allowing audience to be omitted brings other than > that it is academically a possibility. But requiring it (hopefully, if th= e > requirement is followed) helps reduce the possibility of a whole bunch of > security problems that folks likely won't foresee. > > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > "keyed message digest" -> "Message Authentication Code" > > That's the proper terminology [RFC4949], especially since there are MACs > that are not based on digests. > > > > OK > > > > > "This mechanism provides additional security properties." -- Please > delete this or elaborate on what security properties it provides. > > > > Will delete. > > > > > Section 8.2 should note that "Holder-of-Key Assertions" are also a > mitigation for this risk. > > > > OK > > > > > > _______________________________________________ > 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 > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --001a11c3ce16b32dff0505a237af Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It's a known set of actual attacks ... on bearer = assertions.=C2=A0 There is no corresponding attack on HoK assertions.
We shouldn't consider making it optional for bearer assertions.= =C2=A0 For HoK, there's no reason for it not to be optional.
<= div class=3D"gmail_extra">
On Fri, Oct 17, 20= 14 at 10:09 AM, Mike Jones <Michael.Jones@microsoft.com><= /span> wrote:

+1

=C2=A0

This is the standard miti= gation for a known set of actual attacks.=C2=A0 We shouldn=E2=80=99t even c= onsider making it optional.

=C2=A0

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

From: OAuth [m= ailto:oauth-bou= nces@ietf.org] On Behalf Of Phil Hunt
Sent: Friday, October 17, 2014 9:50 AM
To: John Bradley
Cc: draft-ietf-oauth-assertions@tools.ietf.org; Richard Bar= nes; oauth= -chairs@tools.ietf.org; The IESG; oauth
Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oa= uth-assertions-17: (with DISCUSS and COMMENT)

=C2=A0

I believe that if you make =E2=80=9Caud=E2=80=9D opt= ional, it only helps the simplistic deployment scenarios where there is onl= y one RS and one AS. The optionality itself will cause more confusion.=C2= =A0 In the simplistic case, the AS and RS simply have to agree on a URI.

=C2=A0

In more sophisticated domains where there is more th= an one RS service, the =E2=80=9Caud=E2=80=9D value is expected and is usefu= l to determining who a token is intended for.

=C2=A0

Finally, there is the 3rd level case where the AS an= d the RS are in separate domains (federated). In this case, we can expect i= nter-op to be required between separate vendors as a majority of cases. =C2= =A0

=C2=A0

Making =E2=80=9Caud=E2=80=9D optional will greatly i= ncrease complexity in reality.=C2=A0 Making it a MUST only puts a trivial i= mposition on the trivial case (they have to provide a made up URI).<= u>

=C2=A0

We did not really discuss =E2=80=9Caud" much on= the list because it is well known industry practice. I would not want to s= uggest re-writing something that works well.

=C2=A0

Phil<= /p>

=C2=A0

@independentid

phil.hunt@oracle.com

=C2=A0

=C2=A0

=C2=A0

On Oct 17, 2014, at 9:01 AM, John Bradley <ve7jtb@ve7jtb.com> = wrote:



I am good with it as is.=C2=A0 I think we have the f= lexibility to add HoK later. =C2=A0 =C2=A0

=C2=A0

I mostly wanted to point out that it is really only = in that later HoK profile where omitting audience is safe.

=C2=A0

If I had the power to remove the DISCUS I would.<= /u>

=C2=A0

John B.

=C2=A0

On Oct 17, 2014, at 12:56 PM, Brian Campbell <bcampbell@ping= identity.com> wrote:



These drafts define t= he use of bearer assertions. The only mention of HoK style assertions is at= the end of https://tools.ietf.org/html/draft-ietf-oauth-assertions-17#section-3 wh= ich notes that the "rules defined in this document are intended to sup= port a client presenting a bearer assertion to an authorization server.=C2= =A0 The use of holder-of-key assertions are not precluded by this document, but additional protocol details would need= to be specified."

The requirement of ha= ving audience is for bearer assertions only (and we agree need to be that w= ay for bearer) and not intended to preclude anything for HoK assertions.

Does that change your opinion? Is there something th= at could be added or removed or clarified to allay concerns?<= /p>

=C2=A0<= /p>

=C2=A0

On Thu, Oct 16, 2014 at 6:54 PM, John Bradley <ve7jtb@ve7jtb.com&= gt; wrote:

Holder of key JWT is still in draft and we don't= have a clear way to present the proof to the token endpoint.=

=C2=A0

Brian and I started discussing that last week as I h= appen to have a use case for a PoP JWT assertion flow in some other spec wo= rk.

=C2=A0

I think that there is enough difference between bear= er and PoP that doing a follow on profile for SAML and JWT that can also co= ver the proof presentment mechanisms makes the most sense.

=C2=A0

I would go with restricting this to Bearer and MUST = for audience, =C2=A0and removing the audience requirement explicitly in the= PoP profiles.

=C2=A0

There are people who need the bearer version 6 month= s ago, =C2=A0I don't want to do anything to hold it up based on future = work.

=C2=A0

I am happy to help with a SAML PoP/HoK draft as a fo= llow on. =C2=A0 The SAML subject confirmation stuff is relatively clear so = it is mostly defining the presentment mechanisms like mutual TLS and a self= signed assertion. (we need to be careful not to conflate client authentication and token proof, as they are differe= nt and might both be used at the same time.

=C2=A0

John B.

=C2=A0

On Oct 16, 2014, at 7:20 PM, Richard Barnes <rlb@ipv.sx> wrote:



You guys are all argu= ing that having an Audience can be useful.=C2=A0 I don't disagree.=C2= =A0 I disagree that it should be REQUIRED in all cases.

The Google vulnerabil= ity that Brian raised was an interesting read, but as John points out, it o= nly applies to Bearer Assertions.=C2=A0 There's no security requirement= at all for holder-of-key assertions to have an audience, since they can't be replayed by someone who doesn't h= old the key.

I could agree that an= audience should be REQUIRED for bearer assertions.=C2=A0 Since they are vu= lnerable to replay, Audience protects against the Authorization Server re-u= sing the token.=C2=A0 (It would be good to say this explicitly in the doc, actually.)=C2=A0 But for holder-of-key asserti= ons, the Audience should be OPTIONAL.=C2=A0 Note that this requires that in= stance documents define the difference between bearer assertions and holder= -of-key assertions, so that implementations can enforce these requirements.

So it seems like there are two solutions here:

1. Scope the document to bearer assertions only, and= keep the MUST

2. Keep the current s= cope, make Audience OPTIONAL for holder-of-key assertions, and define the d= ifference in the instance docs.

--Richard



=C2=A0

=C2=A0

=C2=A0

On Thu, Oct 16, 2014 at 9:57 AM, Phil Hunt <phil.hunt@oracle.com> wrote:

It is also important for a non-protocol purpose. Lia= bility.

=C2=A0

If a 3rd party uses an assertion that was not intend= ed for it, it cannot obviously hold the asserting party responsible. =C2=A0=

=C2=A0

=C2=A0

On Oct 16, 2014, at 8:43 AM, Brian Campbell <bcampbell@pingi= dentity.com> wrote:



Thanks for your review and feedback, Richard. Replie= s are inline below...

=C2=A0

On Wed, Oct 15, 2014 at 9:47 PM, Richard Barnes <= rlb@ipv.sx> wrote:

Richard Barnes has en= tered the following ballot position for
draft-ietf-oauth-assertions-17: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions= /



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

"The assertion MUST contain an Audience that identifies the Authorizat= ion
Server as the intended audience.=C2=A0 Assertions that do not identify the<= br> Authorization Server as an intended audience MUST be rejected."

Could you please identify the threat model within which this "MUST&quo= t; is
required?=C2=A0 This requirement doesn't follow from any of the threats=
elaborated in Section 8.

The Audience is only necessary if the Issuer wishes to constrain the set of Authorization Servers with which an assertion may be used.=C2=A0 So ISTM=
that this should be "MAY contain..."

=C2=A0<= /p>

The audience restriction let's the issuer say sp= ecifically what relying party is allowed to consume the assertion, which en= sures that the client can't use it somewhere else that it wasn't in= tended and that the relying party that receives the assertion can't turn around and use it to access some other servic= e.

=C2=A0

Strictly speaking, yo= u are right that the audience is only necessary if the Issuer wishes to con= strain the set of Authorization Servers with which an assertion may be used= . But the Issuer really really really should make that constraint and fully understanding the implications of no= t doing so is difficult and unlikely.

There was a vulnerabi= lity in Google apps SAML a few years back that demonstrates how important a= udience restriction is and how it can be difficult for even very sophistica= ted providers to get it all right. I haven't had time to read it again to make sure but I think that this i= s the paper http://www.ai-lab.it/armando/pub/fmse9-armando.pdf<= /p>

I don't see what value allowing audience to be o= mitted brings other than that it is academically a possibility. But requiri= ng it (hopefully, if the requirement is followed) helps reduce the possibil= ity of a whole bunch of security problems that folks likely won't foresee.


=C2=A0

----------------------------------------------------= ------------------
COMMENT:
----------------------------------------------------------------------

"keyed message digest" -> "Message Authentication Code&qu= ot;

That's the proper terminology [RFC4949], especially since there are MAC= s
that are not based on digests.

=C2=A0

OK

=C2=A0


"This mechanism provides additional security properties." -- Plea= se
delete this or elaborate on what security properties it provides.=

=C2=A0

Will delete.

=C2=A0


Section 8.2 should note that "Holder-of-Key Assertions" are also = a
mitigation for this risk.

=C2=A0

OK

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


_______________________________________________
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


--001a11c3ce16b32dff0505a237af-- From nobody Fri Oct 17 11:10:56 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD6DD1A004B for ; Fri, 17 Oct 2014 11:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBEDKr4o8W90 for ; Fri, 17 Oct 2014 11:10:42 -0700 (PDT) Received: from mail-vc0-f176.google.com (mail-vc0-f176.google.com [209.85.220.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04B641A005B for ; Fri, 17 Oct 2014 11:10:23 -0700 (PDT) Received: by mail-vc0-f176.google.com with SMTP id hq11so1006425vcb.35 for ; Fri, 17 Oct 2014 11:10:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8l3XfKda+AYVWr7X8TpNbUpZY7yramXp92u/MTHPHTs=; b=H/pXHxcKlUBRjA6AayYco3SDoN1cVJ2yHVQ7MhwSNBMU1NmD5yVr/3iLqupI+AEGpt 4LyVX0mlXGcP0f71SFv/zPK4nVHa4ReywCKApAtUWqJMJF7PsNYNDx8eT/uMaUHjlLRB 3PQGbx3PG5tilhBCg9cuswMSV6CoxkG5rZYFzTNpCMysZbGrtsOTExhZGtiRoqYTTccn fxswQFzC5dj5199jo1xDG83pkUGPNUWrMQjda1EIk9CHLpy61iDfjUdGaQLnL8C6bIP5 9KT7l0vS/TqytQf3Ini2n7YPif0FifX8c2j1tu+LB+ZphU8X8inLbIaw9XpIjnlFcs9N j+tw== X-Gm-Message-State: ALoCoQmBcXpUUTh6r/EHsVm4OBxJ0RcV6lrT5g3N9wrXlgtNxkdnmsA9268kEfl0WqWums1rkcF8 MIME-Version: 1.0 X-Received: by 10.221.37.195 with SMTP id tf3mr2085171vcb.63.1413569423167; Fri, 17 Oct 2014 11:10:23 -0700 (PDT) Received: by 10.31.149.205 with HTTP; Fri, 17 Oct 2014 11:10:23 -0700 (PDT) In-Reply-To: References: <20141016040122.32277.7067.idtracker@ietfa.amsl.com> Date: Fri, 17 Oct 2014 11:10:23 -0700 Message-ID: From: Richard Barnes To: Brian Campbell Content-Type: multipart/alternative; boundary=001a1133480a556f680505a247da Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/aesHE5kFgCyWkp2hIPLzqZXJFX4 Cc: "oauth-chairs@tools.ietf.org" , oauth , The IESG , draft-ietf-oauth-jwt-bearer@tools.ietf.org Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-jwt-bearer-10: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 18:10:45 -0000 --001a1133480a556f680505a247da Content-Type: text/plain; charset=UTF-8 On Fri, Oct 17, 2014 at 9:27 AM, Brian Campbell wrote: > > > On Thu, Oct 16, 2014 at 4:32 PM, Richard Barnes wrote: > >> >> >> On Thu, Oct 16, 2014 at 1:44 PM, Brian Campbell < >> bcampbell@pingidentity.com> wrote: >> >>> Thanks for your review and feedback on this one too, Richard. Replies >>> are inline below... >>> >>> On Wed, Oct 15, 2014 at 10:01 PM, Richard Barnes wrote: >>> >>>> Richard Barnes has entered the following ballot position for >>>> draft-ietf-oauth-jwt-bearer-10: Discuss >>>> >>>> When responding, please keep the subject line intact and reply to all >>>> email addresses included in the To and CC lines. (Feel free to cut this >>>> introductory paragraph, however.) >>>> >>>> >>>> Please refer to >>>> http://www.ietf.org/iesg/statement/discuss-criteria.html >>>> for more information about IESG DISCUSS and COMMENT positions. >>>> >>>> >>>> The document, along with other ballot positions, can be found here: >>>> http://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/ >>>> >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> DISCUSS: >>>> ---------------------------------------------------------------------- >>>> >>>> As with draft-ietf-oauth-assertions, the requirement for an "aud" claim >>>> seems entirely unnecessary. Holding this DISCUSS point pending that >>>> discussion >>>> and its reflection in this document. >>>> >>>> "Assertions that do not identify the Authorization Server as an intended >>>> audience MUST be rejected." -- What does it mean for an assertion to >>>> "identify >>>> the Authorization Server"? Does the specified need to match >>>> the >>>> entire URL of the relevant OAuth endpoint? Just the origin? Just the >>>> domain? >>>> Does the URL need to be canonicalized? >>>> >>>> >>> >>> No c14n, as it says, "... compare the audience values using the Simple >>> String Comparison method defined in Section 6.2.1 of RFC 3986." >>> >>> Basically the AS is at liberty to determine how it identifies itself. >>> Some guidance on using the token endpoint is provided but it's ultimately >>> up to the AS (or the larger deployment in which the AS exists). The >>> acceptable value is one of a few bits of information that must be exchanged >>> for this profile, which is discussed in the Interoperability Considerations >>> https://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-10#section-5 >>> >> >> Sigh. "Negotiate it out of band" is a terrible, non-scalable, >> not-in-the-spirit-of-the-Internet answer. But I guess I might clear on >> this if you could add something like the following: >> "As noted in Section 5 of [I-D.ietf-oauth-jwt-bearer], the precise >> strings to be used as the Audience for a given Authorization Server must be >> configured out-of-band by the Authorization Server and the Issuer of the >> assertion." >> > > > > I'll add the suggested text. > Great. Let me know when the revised text is posted. --Richard > > > >> >> But is there seriously no answer that the WG could agree on? This seems >> like it should be a pretty simple question. Was it even discussed? >> >> > > > It was discussed but it's not simple for reasons I've tried to articulate > many times. > > Note that the specific profiling or usage of these specs can constrain or > dictate the values of this and other the things that needing out of band > negotiation and can be more in the spirit of the Internet to the extent > that they define dynamic exchange/discovery/registration/etc. of required > information. But these little documents need to fit into such larger > contexts not try and define them. > > > >> --Richard >> >> >> >>> Some more explanation/discussion of it is in the middle(ish) of this >>> reply to a similar comment from Stephen Farrell >>> http://www.ietf.org/mail-archive/web/oauth/current/msg13605.html >>> >>> >>> >>>> ---------------------------------------------------------------------- >>>> COMMENT: >>>> ---------------------------------------------------------------------- >>>> >>>> "keyed message digest" -> "MAC" >>>> >>> >>> Yep. >>> >>> >>>> >>>> Both this and the SAML document could save a lot of bits by just being >>>> subsections of the -assertions document. >>>> >>> >>> The structure and relationship of the documents was decided on by the WG >>> nearly three years ago. There is some duplication but it's believed to be >>> more approachable this way - particularly for those implementing just one >>> assertion type. >>> >> >> > --001a1133480a556f680505a247da Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Oct 17, 2014 at 9:27 AM, Brian Campbell <<= a href=3D"mailto:bcampbell@pingidentity.com" target=3D"_blank">bcampbell@pi= ngidentity.com> wrote:


On Thu, Oct 16, 2014 at 4:32 PM, Richard Barnes= <rlb@= ipv.sx> wrote:


On Thu, Oct 16, 2014 at 1:44 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:
Thanks for y= our review and feedback on this one too, Richard.=20 Replies are inline below...

On Wed, Oct 15, 2014 at 10:01 PM, Richard = Barnes <rlb@ipv.sx> wrote:
Richard Barnes has entered the following ballot position for draft-ietf-oauth-jwt-bearer-10: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-crit= eria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer= /



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

As with draft-ietf-oauth-assertions, the requirement for an "aud"= claim
seems entirely unnecessary.=C2=A0 Holding this DISCUSS point pending that discussion
and its reflection in this document.

"Assertions that do not identify the Authorization Server as an intend= ed
audience MUST be rejected." -- What does it mean for an assertion to "identify
the Authorization Server"?=C2=A0 Does the specified <Audience> n= eed to match
the
entire URL of the relevant OAuth endpoint?=C2=A0 Just the origin?=C2=A0 Jus= t the
domain?
Does the URL need to be canonicalized?



No c14n, as it says, &= quot;...=C2=A0 compare the audience values using the Simple String Comparis= on method defined in Section 6.2.1 of RFC 3986."

Ba= sically the AS is at liberty to determine how it identifies itself. Some gu= idance on using the token endpoint is provided but it's ultimately up t= o the AS (or the larger deployment in which the AS exists). The acceptable = value is one of a few bits of information that must be exchanged for this p= rofile, which is discussed in the Interoperability Considerations https://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-10= #section-5

Sigh.=C2=A0 "Negotiate it out of band" is a terrible,= non-scalable, not-in-the-spirit-of-the-Internet answer.=C2=A0 But I guess = I might clear on this if you could add something like the following:
"As noted in Section 5 of [I-D.ietf-oauth-jwt-bearer], the pre= cise strings to be used as the Audience for a given Authorization Server mu= st be configured out-of-band by the Authorization Server and the Issuer of = the assertion."



I'll add the suggested text.

Great.=C2=A0 Let me know when the r= evised text is posted.=C2=A0

--Richard
=C2=A0

=C2=A0
=

B= ut is there seriously no answer that the WG could agree on?=C2=A0 This seem= s like it should be a pretty simple question.=C2=A0 Was it even discussed?<= span>

=



It was discussed but it'= ;s not simple for reasons I've tried to articulate many times.

<= /div>
Note that the specific profiling or usage of these specs can cons= train or dictate the values of this and other the things that needing out o= f band negotiation and can be more in the spirit of the Internet to the ext= ent that they define dynamic exchange/discovery/registration/etc. of requir= ed information. But these little documents need to fit into such larger con= texts not try and define them.

=C2=A0
<= /font>
--Richard

=C2=A0
Some more explanation/discussion of it is in the middle(ish)= of this reply to a similar comment from Stephen Farrell http://www.ietf.org/mail-archive/web/oauth/current/msg13605.html
=


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

"keyed message digest" -> "MAC"

Yep.
=C2=A0

Both this and the SAML document could save a lot of bits by just being
subsections of the -assertions document.

The structure and relationship of the documents was decided on by = the WG nearly three years ago. There is some duplication but it's belie= ved to be more approachable this way - particularly for those implementing = just one assertion type.



--001a1133480a556f680505a247da-- From nobody Fri Oct 17 11:24:10 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B846A1A01F9 for ; Fri, 17 Oct 2014 11:23:57 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains text/plain,.exe X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZf-ttwGz7G7 for ; Fri, 17 Oct 2014 11:23:52 -0700 (PDT) Received: from na3sys009aog111.obsmtp.com (na3sys009aog111.obsmtp.com [74.125.149.205]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7429A1A01A8 for ; Fri, 17 Oct 2014 11:23:52 -0700 (PDT) Received: from mail-ie0-f171.google.com ([209.85.223.171]) (using TLSv1) by na3sys009aob111.postini.com ([74.125.148.12]) with SMTP ID DSNKVEFeuJIFk/rjG6SxyVhmA9tNDv6Q6Hes@postini.com; Fri, 17 Oct 2014 11:23:52 PDT Received: by mail-ie0-f171.google.com with SMTP id tr6so1286399ieb.2 for ; Fri, 17 Oct 2014 11:23:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Qk/UfDV0YfuxC81vOuMRQzDuaq+Ztruz2/ibYDg4Bw4=; b=hroYRqtamUTcBZxSrJn1ADWnCGic7pUfozofy2HocdFe9ZMkU9wVMRW3nT+otJJ0HT JBSx/fZdDPIjtZQ0jPjVhSsvlJEVLiulZz/IyKqmOt2pkP92bmjo8+Q+kpqr0cDshcxk wLApQEjKwCVDnXANihMQBRXiYPe8iZccqMiROx2g2umgeUOxx0eAygxyn6blXuQIXwFZ vjQq/LqLpLwwpIFpg9NqoyRda0hd0MjVaEkz/EZrw7pstzuNRw911GppiqIw45X/c1As INeEsX8WFX+mHV59dJQcvruSXTMwvTioNG9d3FFgdf2gjD1rLEMyxy4Uea7OqC/orh1C QJ6A== X-Gm-Message-State: ALoCoQkwzxGi0Bn4CpfNBjhrzBVT6VnRZrcelo+M2oEo4+D0TpkM1QcgqIPZtQVfaiaFN4KSc64iEDBLGNwdP3TKEuUPcQjnBzyEf02hcDdN0safzXfPTf1RbhXjknA8nUpuJhXt8yxz X-Received: by 10.42.224.3 with SMTP id im3mr11986446icb.49.1413570231828; Fri, 17 Oct 2014 11:23:51 -0700 (PDT) X-Received: by 10.42.224.3 with SMTP id im3mr11986433icb.49.1413570231656; Fri, 17 Oct 2014 11:23:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.12.137 with HTTP; Fri, 17 Oct 2014 11:23:20 -0700 (PDT) In-Reply-To: References: <20141016034735.18695.61014.idtracker@ietfa.amsl.com> <28A05FEA-9EEA-4E95-9B9F-587120A74BAA@ve7jtb.com> <19E82AEC-A5DA-41E9-9370-3FF16264DEAE@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739439BB16289@TK5EX14MBXC286.redmond.corp.microsoft.com> <54415122.9030902@qti.qualcomm.com> <3E356AAD-8B64-42DF-8DAF-054DDFC58A30@ve7jtb.com> From: Brian Campbell Date: Fri, 17 Oct 2014 12:23:20 -0600 Message-ID: To: Richard Barnes Content-Type: multipart/alternative; boundary=001a113328468609bf0505a27734 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/J8QE3YhyJ9D5LN3RBmRn3hSVlok Cc: "draft-ietf-oauth-assertions@tools.ietf.org" , Pete Resnick , oauth , The IESG , "oauth-chairs@tools.ietf.org" Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 18:23:57 -0000 --001a113328468609bf0505a27734 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable That text works for me, Richard. Thanks. I will go with Richard's text in the next draft, unless I hear objections. FWIW, the mention of HoK was a result of a review and suggestions from Hannes some time ago. http://www.ietf.org/mail-archive/web/oauth/current/msg09437.html https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-assertions-04.txt It could be removed, to your point, but I think your proposed text is very clear about the scope and might help prevent confusion. On Fri, Oct 17, 2014 at 12:04 PM, Richard Barnes wrote: > On Fri, Oct 17, 2014 at 10:32 AM, John Bradley wrote: > >> I think this part of sec 3 of assertions states that: >> >> The protocol parameters and processing rules defined in this document >> are intended to support a client presenting a bearer assertion to an >> authorization server. The use of holder-of-key assertions are not >> precluded by this document, but additional protocol details would >> need to be specified. >> >> >> >> As part of defining the additional protocol details for holder-of-key/Po= P >> we can relax the must for audience in the profile that defines how to us= e >> those assertion types. >> > > I think we're on a path to convergence here. > > Given all this, is there any point to even mentioning HoK credentials > here? The entire remainder of the spec is written as if they didn't > exist. And as the text above notes, you can't actually use them with thi= s > specification. > > If we're going to keep the mention, could we augment the text above to > make it clearer that HoK assertions are out of scope. > > """ > The protocol parameters and processing rules defined in this document > are intended to support a client presenting a bearer assertion to an > authorization server. They are not suitable for use with holder-of-key > assertions. While they could be used as a baseline for a holder-of-key > assertion system, there would be a need for additional mechanisms > (to support proof of possession of the secret key), and possibly changes > to the security model (e.g., to relax the requirement for an Audience). > """ > > --Richard > > > > >> >> John B. >> >> On Oct 17, 2014, at 2:25 PM, Pete Resnick >> wrote: >> >> On 10/17/14 12:09 PM, Mike Jones wrote: >> >> This is the standard mitigation for a known set of actual attacks. We >> shouldn=E2=80=99t even consider making it optional. >> >> >> Do you mean you shouldn't consider making it optional for HoK? Again, >> making it clear that the MUST applies only to bearer assertions, and tha= t >> future extensions for HoK might have different requirements, is all that= is >> being asked for here. >> >> pr >> >> -- >> Pete Resnick >> Qualcomm Technologies, Inc. - +1 (858)651-4478 >> >> >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a113328468609bf0505a27734 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
That text works for me, Richard. Thanks.

I will go with Richard's text in the next draft, unless I hear o= bjections.


FWIW, the mention of HoK was a resul= t of a review and suggestions from Hannes some time ago.

http://ww= w.ietf.org/mail-archive/web/oauth/current/msg09437.html
h= ttps://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-assertions-04.txt=

It could be removed, to your point, but I think you= r proposed text is very clear about the scope and might help prevent confus= ion.


On Fri, Oct 17, 2014 at 12:04 PM, Richard Barnes <rlb@ipv.sx= > wrote:
On Fri, Oct 17, 2014 at 10:32 AM, John B= radley <ve7jtb@ve7jtb.com> wrote:
I think t= his part of sec 3 of assertions states that:

 The protocol parameter=
s and processing rules defined in this document
   are intended to support a client presenting a bearer assertion to an
   authorization server.  The use of holder-of-key assertions are not
   precluded by this document, but additional protocol details would
   need to be specified.


As part of= defining the additional protocol details for holder-of-key/PoP we can rela= x the must for audience in the profile that defines how to use those assert= ion types.

I think= we're on a path to convergence here.

Give= n all this, is there any point to even mentioning HoK credentials here?=C2= =A0 The entire remainder of the spec is written as if they didn't exist= .=C2=A0 And as the text above notes, you can't actually use them with t= his specification.

If we're going to keep the mention= , could we augment the text above to make it clearer that HoK assertions ar= e out of scope.

"""
The protocol parameters and processing rules defined in this docum= ent
are intended to support a client presenting a bearer assertion to an=
authorization server.=C2=A0 They are not suitable for use with h= older-of-key
assertions.=C2=A0 While they could be used as a baseline fo= r a holder-of-key
assertion system, there would be a need for= additional mechanisms
(to support proof of possession of the= secret key), and possibly changes
to the security model (e.g., to relax= the requirement for an Audience).
"""

--Richard


=C2=A0

John B.=

On Oct 17, 2014, at 2:25 PM, Pete = Resnick <= presnick@qti.qualcomm.com> wrote:

=20
On 10/17/14 12:09 PM, Mike Jones wrote:

This is the standard mitigation for a known set of actual attacks.=C2=A0 We shouldn=E2=80=99t even consider making it optional.


Do you mean you shouldn't consider making it optional for HoK? Again, making it clear that the MUST applies only to bearer assertions, and that future extensions for HoK might have different requirements, is all that is being asked for here.

pr
--=20
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478


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


--001a113328468609bf0505a27734-- From nobody Fri Oct 17 11:26:47 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39ABF1A19F2 for ; Fri, 17 Oct 2014 11:26:39 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CyHMN96gm8dt for ; Fri, 17 Oct 2014 11:26:32 -0700 (PDT) Received: from mail-qc0-f171.google.com (mail-qc0-f171.google.com [209.85.216.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24CC21A19F5 for ; Fri, 17 Oct 2014 11:26:29 -0700 (PDT) Received: by mail-qc0-f171.google.com with SMTP id i17so1057335qcy.30 for ; Fri, 17 Oct 2014 11:26:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=yVvEI+OP69ZhVhaLipVnh25E/3UCz3zbacxdPPJ8Ipc=; b=j1d7lgknPsztiOYJ/2wbDe6ySZPgvd1LoO6+kai0tVKigdo1sv5K2IrI92rkdN1af9 PaVVMkhUHhx2JlsK/eF88eUVmSji1vkdq03T7oR3RJuJAJZUdZmQg7i/hAlFOmR9VRaY F9iBfypLhXr5LFuYEUvo1hR/AiHHBZQbztFJr19PQheolTaUnPS7mOHqNrxt9HVhMn7a OWvOOagVN1xrpt9E9lcvh9t3D2nNrPAhC35Mb8BJOdNyRe0HzuFfZHSGwCAOFwbLOmH8 wHaQ8lUfoQPJRsXrop9binNuPdwjiamDBpdJgFLEk9bmewubTbSQ9SkI97sVNDXo9Okm RHww== X-Gm-Message-State: ALoCoQmHn/Tuarreqfue2bXw+wdQq7I8yDxmAAZFmhRQ/M/ul0D4gtQJjUFcGblCHSOLTwg92iuh X-Received: by 10.224.36.200 with SMTP id u8mr14131393qad.47.1413570388252; Fri, 17 Oct 2014 11:26:28 -0700 (PDT) Received: from [192.168.8.100] ([201.188.100.219]) by mx.google.com with ESMTPSA id 11sm1486928qgp.2.2014.10.17.11.26.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 17 Oct 2014 11:26:27 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_F3D98E0A-CF7C-4C65-83E9-5F5975CE2010" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Bradley In-Reply-To: Date: Fri, 17 Oct 2014 15:26:23 -0300 Message-Id: References: <20141016034735.18695.61014.idtracker@ietfa.amsl.com> <28A05FEA-9EEA-4E95-9B9F-587120A74BAA@ve7jtb.com> <19E82AEC-A5DA-41E9-9370-3FF16264DEAE@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739439BB16289@TK5EX14MBXC286.redmond.corp.microsoft.com> <54415122.9030902@qti.qualcomm.com> <3E356AAD-8B64-42DF-8DAF-054DDFC58A30@ve7jtb.com> To: Brian Campbell X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/lyuYbyGISq5JQ37jRf-bK83kUfI Cc: "draft-ietf-oauth-assertions@tools.ietf.org" , Richard Barnes , Pete Resnick , oauth , The IESG , "oauth-chairs@tools.ietf.org" Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 18:26:39 -0000 --Apple-Mail=_F3D98E0A-CF7C-4C65-83E9-5F5975CE2010 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 +1 On Oct 17, 2014, at 3:23 PM, Brian Campbell = wrote: > That text works for me, Richard. Thanks.=20 >=20 > I will go with Richard's text in the next draft, unless I hear = objections. >=20 >=20 > FWIW, the mention of HoK was a result of a review and suggestions from = Hannes some time ago. >=20 > http://www.ietf.org/mail-archive/web/oauth/current/msg09437.html=20 > https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-assertions-04.txt= >=20 > It could be removed, to your point, but I think your proposed text is = very clear about the scope and might help prevent confusion. >=20 >=20 > On Fri, Oct 17, 2014 at 12:04 PM, Richard Barnes wrote: > On Fri, Oct 17, 2014 at 10:32 AM, John Bradley = wrote: > I think this part of sec 3 of assertions states that: >=20 > The protocol parameters and processing rules defined in this document > are intended to support a client presenting a bearer assertion to = an > authorization server. The use of holder-of-key assertions are not > precluded by this document, but additional protocol details would > need to be specified. >=20 >=20 > As part of defining the additional protocol details for = holder-of-key/PoP we can relax the must for audience in the profile that = defines how to use those assertion types. >=20 > I think we're on a path to convergence here. >=20 > Given all this, is there any point to even mentioning HoK credentials = here? The entire remainder of the spec is written as if they didn't = exist. And as the text above notes, you can't actually use them with = this specification. >=20 > If we're going to keep the mention, could we augment the text above to = make it clearer that HoK assertions are out of scope. >=20 > """ > The protocol parameters and processing rules defined in this document > are intended to support a client presenting a bearer assertion to an > authorization server. They are not suitable for use with = holder-of-key > assertions. While they could be used as a baseline for a = holder-of-key > assertion system, there would be a need for additional mechanisms > (to support proof of possession of the secret key), and possibly = changes > to the security model (e.g., to relax the requirement for an = Audience). > """ >=20 > --Richard >=20 >=20 > =20 >=20 > John B. >=20 > On Oct 17, 2014, at 2:25 PM, Pete Resnick = wrote: >=20 >> On 10/17/14 12:09 PM, Mike Jones wrote: >>>=20 >>> This is the standard mitigation for a known set of actual attacks. = We shouldn=92t even consider making it optional. >>>=20 >>>=20 >>=20 >> Do you mean you shouldn't consider making it optional for HoK? Again, = making it clear that the MUST applies only to bearer assertions, and = that future extensions for HoK might have different requirements, is all = that is being asked for here. >>=20 >> pr >> --=20 >> Pete Resnick >> Qualcomm Technologies, Inc. - +1 (858)651-4478 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 --Apple-Mail=_F3D98E0A-CF7C-4C65-83E9-5F5975CE2010 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 +1
On Oct 17, 2014, at 3:23 = PM, Brian Campbell <bcampbell@pingidentity.com&= gt; wrote:

That text works for me, Richard. = Thanks.

I will go with Richard's text in the next = draft, unless I hear objections.


FWIW, the = mention of HoK was a result of a review and suggestions from Hannes some = time ago.

= http://www.ietf.org/mail-archive/web/oauth/current/msg09437.html =
https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-assertions-= 04.txt

It could be removed, to your point, = but I think your proposed text is very clear about the scope and might = help prevent confusion.


On Fri, Oct 17, = 2014 at 12:04 PM, Richard Barnes <rlb@ipv.sx> = wrote:
On Fri, Oct 17, 2014 at 10:32 AM, John = Bradley <ve7jtb@ve7jtb.com> wrote:
I think this part of sec 3 of assertions = states that:

 The protocol =
parameters and processing rules defined in this document
   are intended to support a client presenting a bearer assertion to an
   authorization server.  The use of holder-of-key assertions are not
   precluded by this document, but additional protocol details would
   need to be specified.


As part = of defining the additional protocol details for holder-of-key/PoP we can = relax the must for audience in the profile that defines how to use those = assertion = types.

I think = we're on a path to convergence here.

Given = all this, is there any point to even mentioning HoK credentials = here?  The entire remainder of the spec is written as if they = didn't exist.  And as the text above notes, you can't actually use = them with this specification.

If we're going to keep = the mention, could we augment the text above to make it clearer that HoK = assertions are out of scope.

"""
The protocol parameters and processing rules defined in this = document
are intended to support a client presenting a bearer = assertion to an
authorization server.  They are not = suitable for use with holder-of-key
assertions.  While they = could be used as a baseline for a holder-of-key
assertion = system, there would be a need for additional = mechanisms
(to support proof of possession of the secret = key), and possibly changes
to the security model (e.g., to relax the = requirement for an Audience).
"""

--Richard


 

John = B.

On Oct 17, 2014, at 2:25 PM, Pete = Resnick <presnick@qti.qualcomm.com> = wrote:

=20
On 10/17/14 12:09 PM, Mike Jones wrote:

This is the standard mitigation for a known set of actual attacks.  We shouldn=92t even consider making it optional.


Do you mean you shouldn't consider making it optional for HoK? Again, making it clear that the MUST applies only to bearer assertions, and that future extensions for HoK might have different requirements, is all that is being asked for here.

pr
--=20
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
=



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



= --Apple-Mail=_F3D98E0A-CF7C-4C65-83E9-5F5975CE2010-- From nobody Fri Oct 17 11:30:05 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5103A1A19F1 for ; Fri, 17 Oct 2014 11:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Igd5dnsBZkbz for ; Fri, 17 Oct 2014 11:29:52 -0700 (PDT) Received: from na3sys009aog116.obsmtp.com (na3sys009aog116.obsmtp.com [74.125.149.240]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE3E11A03AA for ; Fri, 17 Oct 2014 11:29:49 -0700 (PDT) Received: from mail-ie0-f172.google.com ([209.85.223.172]) (using TLSv1) by na3sys009aob116.postini.com ([74.125.148.12]) with SMTP ID DSNKVEFgHVZ4CsGDxKqQ2IN2w9E4sPeZQs1/@postini.com; Fri, 17 Oct 2014 11:29:49 PDT Received: by mail-ie0-f172.google.com with SMTP id rl12so1304057iec.17 for ; Fri, 17 Oct 2014 11:29:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ci/Nu0FfRmTBiKDzatZWOKnyhFkeXzWgmu/PQ9R9bBE=; b=ITYntAOIjfLp643fyM8yTpOjPLlJggVGHJaihZGa56t+ecE5j/Ix7R9T/rYdcY6w8q tuqZkNXofYCWYti3VUd9cCLzM4mH/xvfbvHqYAw3jvtPpkMDzxep+pDKjZZMKAYVpWow AT63wCnnmQoHZ6RGmYmU/j+n/XxZm0pCbbWi0lM67UHjwZ+VjX/6CifSg3gnaPE3MIfw o7QV4EAEsbE8OMunKIHpSAM1+t1ZfSZXiz65t2x5EeviySppOwnsIWvwOvXs/Mbc3B5w ILGjrS0B77Emhd1kdhL5OUxkpF3WKa5xIN2cyKGBd6S8iSWPPEFGkqg4xYhnHm5VUn2y a94w== X-Gm-Message-State: ALoCoQlyrMMBXS1jYNeZRbR6yM+Cqut5ySLx2jWW1/u1USPEYQd2F97fZqmZhfTqKXtG0hcDLWaVvDvdQxJDWqQxoxDJxwIF2AJZ92/4kZswlKX/lH4e2YEJ6rvdEPSBiAUH3mHr3cBB X-Received: by 10.50.164.194 with SMTP id ys2mr746929igb.43.1413570588397; Fri, 17 Oct 2014 11:29:48 -0700 (PDT) X-Received: by 10.50.164.194 with SMTP id ys2mr746920igb.43.1413570588295; Fri, 17 Oct 2014 11:29:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.12.137 with HTTP; Fri, 17 Oct 2014 11:29:17 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439BAF0C6A@TK5EX14MBXC286.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739439BAF0C6A@TK5EX14MBXC286.redmond.corp.microsoft.com> From: Brian Campbell Date: Fri, 17 Oct 2014 12:29:17 -0600 Message-ID: To: Mike Jones Content-Type: multipart/alternative; boundary=089e0149d116c7df9c0505a28cae Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Aa0Xdu_Gj7iq61IGeyVbQltfJSs Cc: The IESG , "draft-ietf-oauth-jwt-bearer.all@tools.ietf.org" , "oauth@ietf.org" , Radia Perlman , "secdir@ietf.org" Subject: Re: [OAUTH-WG] Secdir Review of draft-ietf-oauth-jwt-bearer-10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 18:29:56 -0000 --089e0149d116c7df9c0505a28cae Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree with mike that any additional guidance on when you'd want to use an assertion for client authentication vs. when you would want to use one for an authorization grant would belong in the generic assertions specification draft-ietf-oauth-assertions. I'm struggling with what guidance to give about it, however. Maybe I'm just too close to things but it seems almost definitional - one is for client auth and the other is an authz grant. Radia (or really anyone), is there some specific text you can propose? On Mon, Oct 6, 2014 at 1:54 AM, Mike Jones wrote: > Thanks for your review, Radia. I've added the working group to the threa= d > so that they're aware of your comments. > > > From: Radia Perlman [mailto:radiaperlman@gmail.com] > > Some background guidance on when you would want to use a token for > client authentication vs. when you would want to use one for an > authorization grant would be useful. In practice, the distinction between > the two is subtle. It is common for a token to contain the caller=E2=80= =99s > identity as well as group memberships and perhaps roles. I suspect the > reality is that the client has to figure out which protocol slot the serv= er > wants to get the token in and provide it there, where service designers > make the decision more or less arbitrarily. > > This guidance really belongs in the generic assertions specification > draft-ietf-oauth-assertions. I'll plan on reviewing that spec with the > other editors and the working group to see whether the guidance provided > there needs to be improved. > > --089e0149d116c7df9c0505a28cae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree with mike that any additional guidance on whe= n you'd want to use an assertion for client authentication vs. when you= would want to use one for an authorization grant would belong in the gener= ic assertions specification draft-ietf-oauth-assertions.

I'= ;m struggling with what guidance to give about it, however. Maybe I'm j= ust too close to things but it seems almost definitional - one is for clien= t auth and the other is an authz grant.

Radia (or really anyone), i= s there some specific text you can propose?


On Mon, Oct 6, 2014 at 1:5= 4 AM, Mike Jones <Michael.Jones@microsoft.com> wro= te:
Thanks for your re= view, Radia.=C2=A0 I've added the working group to the thread so that t= hey're aware of your comments.

> From: Radia Perlman [mailto:= radiaperlman@gmail.com]
> Some background guidance on when you would want to use a token for cli= ent authentication vs. when you would want to use one for an authorization = grant would be useful. In practice, the distinction between the two is subt= le. It is common for a token to contain the caller=E2=80=99s identity as we= ll as group memberships and perhaps roles. I suspect the reality is that th= e client has to figure out which protocol slot the server wants to get the = token in and provide it there, where service designers make the decision mo= re or less arbitrarily.

This guidance really belongs in the generic assertions specification draft-= ietf-oauth-assertions.=C2=A0 I'll plan on reviewing that spec with the = other editors and the working group to see whether the guidance provided th= ere needs to be improved.

--089e0149d116c7df9c0505a28cae-- From nobody Fri Oct 17 15:41:37 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39E861A8706 for ; Fri, 17 Oct 2014 15:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FekwTxp6107k for ; Fri, 17 Oct 2014 15:41:33 -0700 (PDT) Received: from na3sys009aog122.obsmtp.com (na3sys009aog122.obsmtp.com [74.125.149.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AD131A7D84 for ; Fri, 17 Oct 2014 15:41:33 -0700 (PDT) Received: from mail-ig0-f169.google.com ([209.85.213.169]) (using TLSv1) by na3sys009aob122.postini.com ([74.125.148.12]) with SMTP ID DSNKVEGbHbiHMVd+KSr2w3dIfH/Px6SPDgkJ@postini.com; Fri, 17 Oct 2014 15:41:33 PDT Received: by mail-ig0-f169.google.com with SMTP id uq10so3637727igb.4 for ; Fri, 17 Oct 2014 15:41:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=niamPEjwbznLTO4kodWYf3B3+pOhE2h71uMwrtjkaqA=; b=GIgtiEuoMtE4KvEKbIPiNzEPNJLFtn314CwVAXWzUXd3p5zVnBRC8h1tsuqZChm37a RF+LZk6dVH38uux8l69jclk3AMOzlfsGIzRU2Sl/3DY90/qh5kRDOLwG1zJ2i18CBKHm 3ThDCQRUgX+WApvm6QBU4uc/ZVaMW3DBumD8tC+DWUl+FfPxYIXRKN+bXQFWER+SUWvt Xn54lofA0yBMLxJ7ye4VcGaf5NPbiHZd6k5a+H8KYt4aOHH0PIjHEo0ucXqCV90d4Xcq 36vvPPOHGzzT8siqDEbCzU2qq9NxN3VVNvMErIioWbwWiphnMhlj1/G4wEuxkUoTzHwS 9n9w== X-Gm-Message-State: ALoCoQlfRzYwObNOS8sVw7ArZ4NmskU+iV34E+dgzIuG08vYZHO2sVPgW3Ea5142htW6OMZlKnuczMDVcOkF8MvuR0CSY3/Lw8j6eSdFjd6pU6Qx41+5Wzd9/rTODVn1G2vpA6G1lK2g X-Received: by 10.107.32.1 with SMTP id g1mr12289770iog.13.1413585692790; Fri, 17 Oct 2014 15:41:32 -0700 (PDT) X-Received: by 10.107.32.1 with SMTP id g1mr12289765iog.13.1413585692686; Fri, 17 Oct 2014 15:41:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.12.137 with HTTP; Fri, 17 Oct 2014 15:41:02 -0700 (PDT) In-Reply-To: References: <20141016112032.13008.86094.idtracker@ietfa.amsl.com> <5440307C.6070600@cs.tcd.ie> From: Brian Campbell Date: Fri, 17 Oct 2014 16:41:02 -0600 Message-ID: To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a1140c92e12a6c80505a61136 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/S2q35luj6tR6QkNmbiMFUqeSWG8 Cc: "oauth-chairs@tools.ietf.org" , draft-ietf-oauth-saml2-bearer@tools.ietf.org, The IESG , Peter Saint-Andre , oauth Subject: Re: [OAUTH-WG] Stephen Farrell's No Objection on draft-ietf-oauth-saml2-bearer-21: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Oct 2014 22:41:35 -0000 --001a1140c92e12a6c80505a61136 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Stephen, I'm working on updating these drafts and as I look again at the text that's in =C2=A75. Interoperability Considerations and the requirement in =C2=A73 = Assertion Format and Processing Requirements to compare these values using the Simple String Comparison (absent an application profile specifying otherwise) I'm not sure what to say or where based on your suggestion below. Is there something specific you can suggest (and where to put it)? Thanks, Brian On Thu, Oct 16, 2014 at 3:20 PM, Brian Campbell wrote: > > On Thu, Oct 16, 2014 at 2:54 PM, Stephen Farrell < > stephen.farrell@cs.tcd.ie> wrote: > >> >> > Some stuff needs to be exchanged out-of-band for this to work. >> > Entity/issuer/audience identifiers are part of that. This need is >> discussed >> > in the Interoperability Considerations at >> > https://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-21#section-5 >> >> So I think it'd be good to explicitly call out that these >> mappings are basically required and that they can be fraught >> (e.g. if someone uses wildcards badly, which they do). >> > > OK, I will add something to that effect in the next revisions. > > --001a1140c92e12a6c80505a61136 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Stephen,

I'm working on updati= ng these drafts and as I look again at the text that's in =C2=A75. Inte= roperability Considerations and the requirement in =C2=A73 Assertion Format= and Processing Requirements to compare these values using the Simple Strin= g Comparison (absent an application profile specifying otherwise) I'm = not sure what to say or where based on your suggestion below. Is there some= thing specific you can suggest (and where to put it)?

Thanks,<= br>Brian

On Th= u, Oct 16, 2014 at 3:20 PM, Brian Campbell <bcampbell@pingidentit= y.com> wrote:

On Thu,= Oct 16, 2014 at 2:54 PM, Stephen Farrell <stephen.farrell@cs.tcd.= ie> wrote:

> Some stuff needs to be exchanged out-of-band for this to work.
> Entity/issuer/audience identifiers are part of that. This need is disc= ussed
> in the Interoperability Considerations at
> https://tools.ietf.org/html/draft-ietf-oauth= -saml2-bearer-21#section-5

So I think it'd be good to explicitly call out that these mappings are basically required and that they can be fraught
(e.g. if someone uses wildcards badly, which they do).

OK, I will add something to that effect in the next = revisions.
=C2=A0

--001a1140c92e12a6c80505a61136-- From nobody Fri Oct 17 18:12:07 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A56651A0075; Fri, 17 Oct 2014 18:12:03 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vAC1Ak54qYev; Fri, 17 Oct 2014 18:12:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9411A0141; Fri, 17 Oct 2014 18:12:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141018011201.12233.99151.idtracker@ietfa.amsl.com> Date: Fri, 17 Oct 2014 18:12:01 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/HZ0zu1_1ExjpXc-gZFrhZXVzOXg Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-json-web-token-29.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Oct 2014 01:12:04 -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 Working Group of the IETF. Title : JSON Web Token (JWT) Authors : Michael B. Jones John Bradley Nat Sakimura Filename : draft-ietf-oauth-json-web-token-29.txt Pages : 34 Date : 2014-10-17 Abstract: JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JavaScript Object Notation (JSON) object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or MACed and/or encrypted. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-29 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-json-web-token-29 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Oct 17 18:33:21 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E2C31A019B for ; Fri, 17 Oct 2014 18:33:16 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kqpFTzLPSIPl for ; Fri, 17 Oct 2014 18:33:13 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0130.outbound.protection.outlook.com [65.55.169.130]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E59C91A0166 for ; Fri, 17 Oct 2014 18:33:11 -0700 (PDT) Received: from CO2PR03CA0032.namprd03.prod.outlook.com (10.141.194.159) by BY1PR0301MB1205.namprd03.prod.outlook.com (25.161.203.154) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Sat, 18 Oct 2014 01:33:09 +0000 Received: from BN1AFFO11FD028.protection.gbl (2a01:111:f400:7c10::168) by CO2PR03CA0032.outlook.office365.com (2a01:111:e400:1414::31) with Microsoft SMTP Server (TLS) id 15.0.1054.13 via Frontend Transport; Sat, 18 Oct 2014 01:33:09 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD028.mail.protection.outlook.com (10.58.52.88) with Microsoft SMTP Server (TLS) id 15.0.1039.16 via Frontend Transport; Sat, 18 Oct 2014 01:33:09 +0000 Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.93]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.03.0210.003; Sat, 18 Oct 2014 01:32:34 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: JOSE -35 and JWT -29 drafts addressing AppsDir review comments Thread-Index: Ac/qc04jSK1AsVY3QjmepP79VerROQAAAc8A Date: Sat, 18 Oct 2014 01:32:33 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439BB17A92@TK5EX14MBXC286.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.73] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439BB17A92TK5EX14MBXC286r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(438002)(189002)(377454003)(199003)(19300405004)(86362001)(85306004)(4396001)(20776003)(87936001)(107046002)(31966008)(84326002)(84676001)(16236675004)(64706001)(95666004)(85806002)(86612001)(66066001)(120916001)(19580405001)(99396003)(44976005)(76482002)(15202345003)(69596002)(19625215002)(512954002)(33656002)(92726001)(92566001)(68736004)(2501002)(97736003)(46102003)(80022003)(16297215004)(19617315012)(6806004)(110136001)(19580395003)(77096002)(106466001)(55846006)(54356999)(85852003)(107886001)(81156004)(21056001)(15975445006)(50986999)(2656002)(2351001)(26826002)(104016003)(71186001)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0301MB1205; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BY1PR0301MB1205; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0368E78B5B Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/u4SXDsfDlwlKe5Z1UpGB4bDeRb4 Subject: [OAUTH-WG] FW: JOSE -35 and JWT -29 drafts addressing AppsDir review comments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Oct 2014 01:33:16 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439BB17A92TK5EX14MBXC286r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Mike Jones Sent: Friday, October 17, 2014 6:32 PM To: jose@ietf.org Subject: JOSE -35 and JWT -29 drafts addressing AppsDir review comments I've posted updated JOSE and JWT drafts that address the Applications Area = Directorate review comments. Thanks to Ray Polk and Carsten Bormann for th= eir useful reviews. No breaking changes were made. The specifications are available at: * http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-35 * http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-35 * http://tools.ietf.org/html/draft-ietf-jose-json-web-key-35 * http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-35 * http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-29 HTML formatted versions are available at: * http://self-issued.info/docs/draft-ietf-jose-json-web-signature-3= 5.html * http://self-issued.info/docs/draft-ietf-jose-json-web-encryption-= 35.html * http://self-issued.info/docs/draft-ietf-jose-json-web-key-35.html * http://self-issued.info/docs/draft-ietf-jose-json-web-algorithms-= 35.html * http://self-issued.info/docs/draft-ietf-oauth-json-web-token-29.h= tml -- Mike P.S. I've also posted this notice at http://self-issued.info/?p=3D1293 and= as @selfissued. --_000_4E1F6AAD24975D4BA5B16804296739439BB17A92TK5EX14MBXC286r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From: Mike Jon= es
Sent: Friday, October 17, 2014 6:32 PM
To: jose@ietf.org
Subject: JOSE -35 and JWT -29 drafts addressing AppsDir review comme= nts

 

I’ve posted updated JOSE and JWT drafts that a= ddress the Applications Area Directorate review comments.  Thanks to R= ay Polk and Carsten Bormann for their useful reviews.  No breaking cha= nges were made.

 

The specifications are available at:

·         http://tools.ietf.org/html/draft-ietf-jose= -json-web-signature-35

·         http://tools.ietf.org/html/draft-ietf-jos= e-json-web-encryption-35

·         http://tools.ietf.org/html/draft-ietf-jose-json-= web-key-35

·         http://tools.ietf.org/html/draft-ietf-jos= e-json-web-algorithms-35

·         http://tools.ietf.org/html/draft-ietf-oauth-j= son-web-token-29

 

HTML formatted versions are available at:=

·         http://self-issued.info/docs/draft-= ietf-jose-json-web-signature-35.html

·         http://self-issued.info/docs/draft= -ietf-jose-json-web-encryption-35.html

·         http://self-issued.info/docs/draft-ietf-j= ose-json-web-key-35.html

·         http://self-issued.info/docs/draft= -ietf-jose-json-web-algorithms-35.html

·         http://self-issued.info/docs/draft-iet= f-oauth-json-web-token-29.html

 

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

 

P.S.  I’ve also posted this notice at http://self-issued.info/?p=3D1293 and as @selfissued.

 

--_000_4E1F6AAD24975D4BA5B16804296739439BB17A92TK5EX14MBXC286r_-- From nobody Sat Oct 18 11:58:39 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63E031A0104 for ; Sat, 18 Oct 2014 11:58:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qyc_tPlZ--ac for ; Sat, 18 Oct 2014 11:58:35 -0700 (PDT) Received: from mail-vc0-f174.google.com (mail-vc0-f174.google.com [209.85.220.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CFAD1A0105 for ; Sat, 18 Oct 2014 11:58:35 -0700 (PDT) Received: by mail-vc0-f174.google.com with SMTP id hq12so1978414vcb.33 for ; Sat, 18 Oct 2014 11:58:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=e9/MkLya3JBdSSBX35GsIOuIQMTt3McJ2pImio80waY=; b=Rv1dPMeJ5Qi7kPZzrNwBsLy+zqDlfao+jmwf5tt9mkeIeMf/wHJhUo2/3mD5UMsRHy lP3XPBZIRSJ81/s8eqUfYa35RymxFpAflpvcJrV6bNdH9ShwaqzqBxyQar9LSawpTRW4 Ci6XLJwOHZTSOx30AwC8VTZkDlAGPSGLqPV0mxkp8ZW49tUzxUFvlQWF7iVJT7YAMSmV XTmxBat59ZYw1Lnp14Dx/ibQeZERQI/zx6cRDdIibyjNC8cyvYLOF5JvYARtJb85ZGmk CB4PRLKwf4trRtY2NyZKJveByISezczOSRH9O7mPN9flM5QnJ1KdxAkZk/jVoK9zzfB9 zR1w== X-Gm-Message-State: ALoCoQk+VUFy9eqPD7mhCQ9Au5DRSRWyHaxR6pyb3zM5HHpDvxxs9PkYH9EvhJAHMQ5g3LBrmEZ2 MIME-Version: 1.0 X-Received: by 10.52.114.228 with SMTP id jj4mr6847930vdb.46.1413658714209; Sat, 18 Oct 2014 11:58:34 -0700 (PDT) Received: by 10.31.149.205 with HTTP; Sat, 18 Oct 2014 11:58:34 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439BB0D5A7@TK5EX14MBXC286.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739439BB0D5A7@TK5EX14MBXC286.redmond.corp.microsoft.com> Date: Sat, 18 Oct 2014 11:58:34 -0700 Message-ID: From: Richard Barnes To: Mike Jones Content-Type: multipart/alternative; boundary=bcaec5485a147e94330505b711c2 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/fvXmDCx9yEuLRsWYLltf1_b2izo Cc: "oauth-chairs@tools.ietf.org" , "oauth@ietf.org" , "draft-ietf-oauth-json-web-token@tools.ietf.org" , The IESG Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Oct 2014 18:58:37 -0000 --bcaec5485a147e94330505b711c2 Content-Type: text/plain; charset=UTF-8 Dude, I cleared on the 10th :) On Tue, Oct 14, 2014 at 5:53 AM, Mike Jones wrote: > The proposed resolution below has been incorporated in the -28 draft. > Hopefully you can clear your DISCUSS on that basis. > > Thanks again, > -- Mike > > > -----Original Message----- > > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones > > Sent: Saturday, October 11, 2014 12:54 PM > > To: Richard Barnes > > Cc: draft-ietf-oauth-json-web-token@tools.ietf.org; oauth- > > chairs@tools.ietf.org; The IESG; oauth@ietf.org > > Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on > draft-ietf-oauth-json-web- > > token-27: (with DISCUSS and COMMENT) > > > > > From: Richard Barnes [mailto:rlb@ipv.sx] > > > Sent: Friday, October 10, 2014 2:37 PM > > > To: Mike Jones > > > Cc: The IESG; oauth-chairs@tools.ietf.org; oauth@ietf.org; > > > draft-ietf-oauth-json-web-token@tools.ietf.org > > > Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on > > > draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) > > > > > > On Mon, Oct 6, 2014 at 3:54 AM, Mike Jones > > wrote: > > > Thanks for your review, Richard. My responses are inline below... > > > > > > > -----Original Message----- > > > > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Richard > > > > Barnes > > > > Sent: Wednesday, October 01, 2014 7:57 PM > > > > To: The IESG > > > > Cc: oauth-chairs@tools.ietf.org; oauth@ietf.org; > > > > draft-ietf-oauth-json-web- token@tools.ietf.org > > > > Subject: [OAUTH-WG] Richard Barnes' Discuss on > > > > draft-ietf-oauth-json-web- > > > > token-27: (with DISCUSS and COMMENT) > > > > > > > > Richard Barnes has entered the following ballot position for > > > > draft-ietf-oauth-json-web-token-27: Discuss > > > > > > > > When responding, please keep the subject line intact and reply to > > > > all email addresses included in the To and CC lines. (Feel free to > > > > cut this introductory paragraph, however.) > > > > > > > > > > > > Please refer to > > > > http://www.ietf.org/iesg/statement/discuss-criteria.html > > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > > > > The document, along with other ballot positions, can be found here: > > > > http://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/ > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > > -- > > > > DISCUSS: > > > > -------------------------------------------------------------------- > > > > -- > > > > > > > > Section 7. > > > > In order to prevent confusion between secured and Unsecured JWTs, > > > > the validation steps here need to call for the application to > specify which is > > required. > > > > > > Per my response on your JWS comments, this is already handed in a more > > general way in the JWS validation steps. Specifically, the last > paragraph of > > Section 5.2 is: > > > > > > "Finally, note that it is an application decision which algorithms are > acceptable > > in a given context. Even if a JWS can be successfully validated, unless > the > > algorithm(s) used in the JWS are acceptable to the application, it > SHOULD reject > > the JWS." > > > > > > I've cleared this DISCUSS in the interest of having this fight over in > JWS thread. > > But I also added the following COMMENT: > > > "It would be good for this document to pass on the note from JWS about > > selecting which algorithms are acceptable, and in particular, whether > unsecured > > JWTs are acceptable." > > > > Thanks for clearing the DISCUSS. I'm fine repeating the note about > acceptable > > algorithms in the JWT spec, assuming others are. > > > > > I would therefore request that you likewise withdraw this DISCUSS on > that > > basis. > > > > -- Mike > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > --bcaec5485a147e94330505b711c2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dude, I cleared on the 10th :)

On Tue, Oct 14, 2014 at 5:53 AM, Mi= ke Jones <Michael.Jones@microsoft.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">The proposed resolution below has been incorp= orated in the -28 draft.=C2=A0 Hopefully you can clear your DISCUSS on that= basis.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks again,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =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 [mailto:oauth-bo= unces@ietf.org] On Behalf Of Mike Jones
> Sent: Saturday, October 11, 2014 12:54 PM
> To: Richard Barnes
> Cc: = draft-ietf-oauth-json-web-token@tools.ietf.org; oauth-
> chairs@tools.ietf.org; Th= e IESG; oauth@ietf.org
> Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oaut= h-json-web-
> token-27: (with DISCUSS and COMMENT)
>
> > From: Richard Barnes [mailto:rlb@ip= v.sx]
> > Sent: Friday, October 10, 2014 2:37 PM
> > To: Mike Jones
> > Cc: The IESG; oaut= h-chairs@tools.ietf.org; oauth@ietf.o= rg;
> > draft-ietf-oauth-json-web-token@tools.ietf.org
> > Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on
> > draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) > >
> > On Mon, Oct 6, 2014 at 3:54 AM, Mike Jones
> <Michael.Jones@micro= soft.com> wrote:
> > Thanks for your review, Richard.=C2=A0 My responses are inline be= low...
> >
> > > -----Original Message-----
> > > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Richard
> > > Barnes
> > > Sent: Wednesday, October 01, 2014 7:57 PM
> > > To: The IESG
> > > Cc: oauth-cha= irs@tools.ietf.org; oauth@ietf.org;
> > > draft-ietf-oauth-json-web- token@tools.ietf.org
> > > Subject: [OAUTH-WG] Richard Barnes' Discuss on
> > > draft-ietf-oauth-json-web-
> > > token-27: (with DISCUSS and COMMENT)
> > >
> > > Richard Barnes has entered the following ballot position for=
> > > draft-ietf-oauth-json-web-token-27: Discuss
> > >
> > > When responding, please keep the subject line intact and rep= ly to
> > > all email addresses included in the To and CC lines. (Feel f= ree to
> > > cut this introductory paragraph, however.)
> > >
> > >
> > > Please refer to
> > > http://www.ietf.org/iesg/statement/discuss-crite= ria.html
> > > for more information about IESG DISCUSS and COMMENT position= s.
> > >
> > >
> > > The document, along with other ballot positions, can be foun= d here:
> > > http://datatracker.ietf.org/doc/draft-ie= tf-oauth-json-web-token/
> > >
> > >
> > >
> > > ----------------------= ----------------------------------------------
> > > --
> > > DISCUSS:
> > > ------------------------------------------------------------= --------
> > > --
> > >
> > > Section 7. > > > In order to prevent confusion between secured and Unsecured = JWTs,
> > > the validation steps here need to call for the application t= o specify which is
> required.
> >
> > Per my response on your JWS comments, this is already handed in a= more
> general way in the JWS validation steps.=C2=A0 Specifically, the last = paragraph of
> Section 5.2 is:
> >
> > "Finally, note that it is an application decision which algo= rithms are acceptable
> in a given context. Even if a JWS can be successfully validated, unles= s the
> algorithm(s) used in the JWS are acceptable to the application, it SHO= ULD reject
> the JWS."
> >
> > I've cleared this DISCUSS in the interest of having this figh= t over in JWS thread.
> But I also added the following COMMENT:
> > "It would be good for this document to pass on the note from= JWS about
> selecting which algorithms are acceptable, and in particular, whether = unsecured
> JWTs are acceptable."
>
> Thanks for clearing the DISCUSS.=C2=A0 I'm fine repeating the note= about acceptable
> algorithms in the JWT spec, assuming others are.
>
> > I would therefore request that you likewise withdraw this DISCUSS= on that
> basis.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =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
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--bcaec5485a147e94330505b711c2-- From nobody Sat Oct 18 11:59:39 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C34DF1A0115 for ; Sat, 18 Oct 2014 11:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMj4BcrLiu0V for ; Sat, 18 Oct 2014 11:59:32 -0700 (PDT) Received: from BLU004-OMC1S1.hotmail.com (blu004-omc1s1.hotmail.com [65.55.116.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6ECA11A0105 for ; Sat, 18 Oct 2014 11:59:32 -0700 (PDT) Received: from BLU406-EAS159 ([65.55.116.8]) by BLU004-OMC1S1.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Sat, 18 Oct 2014 11:59:31 -0700 X-TMN: [cItXFMZopAaxPEXDjEPPvbixaNSzlu0T] X-Originating-Email: [panca70@outlook.com] Message-ID: Content-Type: multipart/alternative; boundary="_88cac988-ddf5-45d5-9cec-87af8fce28e9_" MIME-Version: 1.0 X-Client-ID: 120 X-Mailer: BlackBerry Email (10.2.1.3247) Date: Sun, 19 Oct 2014 01:59:28 +0700 From: Panca Agus Ananda To: X-OriginalArrivalTime: 18 Oct 2014 18:59:31.0352 (UTC) FILETIME=[A63EA180:01CFEB05] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/qYjQc-pFy4B_cBxFLhHi5oSFzYc Subject: [OAUTH-WG] Bls: OAuth Digest, Vol 72, Issue 55 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Oct 2014 18:59:37 -0000 --_88cac988-ddf5-45d5-9cec-87af8fce28e9_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Dikirim dari ponsel cerdas BlackBerry 10 saya dengan jaringan Telkomsel. Pesan Asli Dari: oauth-request@ietf.org Terkirim: Minggu=2C 19 Oktober 2014 01.58 Ke: oauth@ietf.org Balas Ke: oauth@ietf.org Perihal: OAuth Digest=2C Vol 72=2C Issue 55 Send OAuth mailing list submissions to oauth@ietf.org To subscribe or unsubscribe via the World Wide Web=2C visit https://www.ietf.org/mailman/listinfo/oauth or=2C via email=2C send a message with subject or body 'help' to oauth-request@ietf.org You can reach the person managing the list at oauth-owner@ietf.org When replying=2C please edit your Subject line so it is more specific than "Re: Contents of OAuth digest..." Today's Topics: 1. Re: Stephen Farrell's No Objection on draft-ietf-oauth-saml2-bearer-21: (with COMMENT) (Brian Campbell) 2. I-D Action: draft-ietf-oauth-json-web-token-29.txt (internet-drafts@ietf.org) 3. FW: JOSE -35 and JWT -29 drafts addressing AppsDir review comments (Mike Jones) 4. Re: Richard Barnes' Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) (Richard Barnes) ---------------------------------------------------------------------- Message: 1 Date: Fri=2C 17 Oct 2014 16:41:02 -0600 From: Brian Campbell To: Stephen Farrell Cc: "oauth-chairs@tools.ietf.org" =2C draft-ietf-oauth-saml2-bearer@tools.ietf.org=2C The IESG =2C Peter Saint-Andre =2C oauth Subject: Re: [OAUTH-WG] Stephen Farrell's No Objection on draft-ietf-oauth-saml2-bearer-21: (with COMMENT) Message-ID: Content-Type: text/plain=3B charset=3D"utf-8" Stephen=2C I'm working on updating these drafts and as I look again at the text that's in ?5. Interoperability Considerations and the requirement in ?3 Assertion Format and Processing Requirements to compare these values using the Simple String Comparison (absent an application profile specifying otherwise) I'm not sure what to say or where based on your suggestion below. Is there something specific you can suggest (and where to put it)? Thanks=2C Brian On Thu=2C Oct 16=2C 2014 at 3:20 PM=2C Brian Campbell wrote: > > On Thu=2C Oct 16=2C 2014 at 2:54 PM=2C Stephen Farrell < > stephen.farrell@cs.tcd.ie> wrote: > >> >> > Some stuff needs to be exchanged out-of-band for this to work. >> > Entity/issuer/audience identifiers are part of that. This need is >> discussed >> > in the Interoperability Considerations at >> > https://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-21#section-5 >> >> So I think it'd be good to explicitly call out that these >> mappings are basically required and that they can be fraught >> (e.g. if someone uses wildcards badly=2C which they do). >> > > OK=2C I will add something to that effect in the next revisions. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Fri=2C 17 Oct 2014 18:12:01 -0700 From: internet-drafts@ietf.org To: i-d-announce@ietf.org Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-json-web-token-29.txt Message-ID: <20141018011201.12233.99151.idtracker@ietfa.amsl.com> Content-Type: text/plain=3B charset=3D"utf-8" 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 Working Group = of the IETF. Title : JSON Web Token (JWT) Authors : Michael B. Jones John Bradley Nat Sakimura Filename : draft-ietf-oauth-json-web-token-29.txt Pages : 34 Date : 2014-10-17 Abstract: JSON Web Token (JWT) is a compact=2C URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JavaScript Object Notation (JSON) object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure=2C enabling the claims to be digitally signed or MACed and/or encrypted. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-29 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-json-web-token-29 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/ ------------------------------ Message: 3 Date: Sat=2C 18 Oct 2014 01:32:33 +0000 From: Mike Jones To: "oauth@ietf.org" Subject: [OAUTH-WG] FW: JOSE -35 and JWT -29 drafts addressing AppsDir review comments Message-ID: <4E1F6AAD24975D4BA5B16804296739439BB17A92@TK5EX14MBXC286.redmond.co= rp.microsoft.com> Content-Type: text/plain=3B charset=3D"us-ascii" From: Mike Jones Sent: Friday=2C October 17=2C 2014 6:32 PM To: jose@ietf.org Subject: JOSE -35 and JWT -29 drafts addressing AppsDir review comments I've posted updated JOSE and JWT drafts that address the Applications Area = Directorate review comments. Thanks to Ray Polk and Carsten Bormann for th= eir useful reviews. No breaking changes were made. The specifications are available at: * http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-35 * http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-35 * http://tools.ietf.org/html/draft-ietf-jose-json-web-key-35 * http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-35 * http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-29 HTML formatted versions are available at: * http://self-issued.info/docs/draft-ietf-jose-json-web-signature-3= 5.html * http://self-issued.info/docs/draft-ietf-jose-json-web-encryption-= 35.html * http://self-issued.info/docs/draft-ietf-jose-json-web-key-35.html * http://self-issued.info/docs/draft-ietf-jose-json-web-algorithms-= 35.html * http://self-issued.info/docs/draft-ietf-oauth-json-web-token-29.h= tml -- Mike P.S. I've also posted this notice at http://self-issued.info/?p=3D1293 and= as @selfissued. -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 4 Date: Sat=2C 18 Oct 2014 11:58:34 -0700 From: Richard Barnes To: Mike Jones Cc: "oauth-chairs@tools.ietf.org" =2C "oauth@ietf.org" =2C "draft-ietf-oauth-json-web-token@tools.ietf.org" =2C The IESG Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) Message-ID: Content-Type: text/plain=3B charset=3D"utf-8" Dude=2C I cleared on the 10th :) On Tue=2C Oct 14=2C 2014 at 5:53 AM=2C Mike Jones wrote: > The proposed resolution below has been incorporated in the -28 draft. > Hopefully you can clear your DISCUSS on that basis. > > Thanks again=2C > -- Mike > > > -----Original Message----- > > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones > > Sent: Saturday=2C October 11=2C 2014 12:54 PM > > To: Richard Barnes > > Cc: draft-ietf-oauth-json-web-token@tools.ietf.org=3B oauth- > > chairs@tools.ietf.org=3B The IESG=3B oauth@ietf.org > > Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on > draft-ietf-oauth-json-web- > > token-27: (with DISCUSS and COMMENT) > > > > > From: Richard Barnes [mailto:rlb@ipv.sx] > > > Sent: Friday=2C October 10=2C 2014 2:37 PM > > > To: Mike Jones > > > Cc: The IESG=3B oauth-chairs@tools.ietf.org=3B oauth@ietf.org=3B > > > draft-ietf-oauth-json-web-token@tools.ietf.org > > > Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on > > > draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) > > > > > > On Mon=2C Oct 6=2C 2014 at 3:54 AM=2C Mike Jones > > wrote: > > > Thanks for your review=2C Richard. My responses are inline below... > > > > > > > -----Original Message----- > > > > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Richard > > > > Barnes > > > > Sent: Wednesday=2C October 01=2C 2014 7:57 PM > > > > To: The IESG > > > > Cc: oauth-chairs@tools.ietf.org=3B oauth@ietf.org=3B > > > > draft-ietf-oauth-json-web- token@tools.ietf.org > > > > Subject: [OAUTH-WG] Richard Barnes' Discuss on > > > > draft-ietf-oauth-json-web- > > > > token-27: (with DISCUSS and COMMENT) > > > > > > > > Richard Barnes has entered the following ballot position for > > > > draft-ietf-oauth-json-web-token-27: Discuss > > > > > > > > When responding=2C please keep the subject line intact and reply to > > > > all email addresses included in the To and CC lines. (Feel free to > > > > cut this introductory paragraph=2C however.) > > > > > > > > > > > > Please refer to > > > > http://www.ietf.org/iesg/statement/discuss-criteria.html > > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > > > > The document=2C along with other ballot positions=2C can be found h= ere: > > > > http://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/ > > > > > > > > > > > > > > > > -------------------------------------------------------------------= - > > > > -- > > > > DISCUSS: > > > > -------------------------------------------------------------------= - > > > > -- > > > > > > > > Section 7. > > > > In order to prevent confusion between secured and Unsecured JWTs=2C > > > > the validation steps here need to call for the application to > specify which is > > required. > > > > > > Per my response on your JWS comments=2C this is already handed in a m= ore > > general way in the JWS validation steps. Specifically=2C the last > paragraph of > > Section 5.2 is: > > > > > > "Finally=2C note that it is an application decision which algorithms = are > acceptable > > in a given context. Even if a JWS can be successfully validated=2C unle= ss > the > > algorithm(s) used in the JWS are acceptable to the application=2C it > SHOULD reject > > the JWS." > > > > > > I've cleared this DISCUSS in the interest of having this fight over i= n > JWS thread. > > But I also added the following COMMENT: > > > "It would be good for this document to pass on the note from JWS abou= t > > selecting which algorithms are acceptable=2C and in particular=2C wheth= er > unsecured > > JWTs are acceptable." > > > > Thanks for clearing the DISCUSS. I'm fine repeating the note about > acceptable > > algorithms in the JWT spec=2C assuming others are. > > > > > I would therefore request that you likewise withdraw this DISCUSS on > that > > basis. > > > > -- Mike > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Subject: Digest Footer _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------------------------------ End of OAuth Digest=2C Vol 72=2C Issue 55 ************************************* --_88cac988-ddf5-45d5-9cec-87af8fce28e9_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"


Dikirim dari ponsel cerdas BlackBerry 10 saya dengan jaringan Telkomsel.
&nbs= p=3B Pesan Asli  =3B
Dari: oauth-request@ietf.org
Terkirim: Minggu=2C 19 Oktober 2014 01.58
Ke: oauth@ietf.org
Balas Ke: oauth@ietf.org
Perihal: OAuth Digest=2C Vol 72=2C Issue 55

Send OAuth mailing list submissions to
 =3B =3B =3B =3B =3B =3B =3B oauth@ietf.org

To subscribe or unsubscribe via the World Wide Web=2C visit
 =3B =3B =3B =3B =3B =3B =3B https://www.ietf.org/mailman/listinfo= /oauth
or=2C via email=2C send a message with subject or body 'help' to
 =3B =3B =3B =3B =3B =3B =3B oauth-request@ietf= .org

You can reach the person managing the list at
 =3B =3B =3B =3B =3B =3B =3B oauth-owner@ietf.o= rg

When replying=2C please edit your Subject line so it is more specific
than "=3BRe: Contents of OAuth digest..."=3B


Today's Topics:

 =3B =3B 1. Re: Stephen Farrell's No Objection on
 =3B =3B =3B =3B =3B draft-ietf-oauth-saml2-bearer-21: = (with COMMENT) (Brian Campbell)
 =3B =3B 2. I-D Action: draft-ietf-oauth-json-web-token-29.txt
 =3B =3B =3B =3B =3B (internet-drafts@ietf.org)
 =3B =3B 3. FW: JOSE -35 and JWT -29 drafts addressing AppsDir = =3B =3B =3B =3B =3B =3B =3B review
 =3B =3B =3B =3B =3B comments (Mike Jones)
 =3B =3B 4. Re: Richard Barnes' Discuss on
 =3B =3B =3B =3B =3B draft-ietf-oauth-json-web-token-27= : (with DISCUSS and COMMENT)
 =3B =3B =3B =3B =3B (Richard Barnes)


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

Message: 1
Date: Fri=2C 17 Oct 2014 16:41:02 -0600
From: Brian Campbell <=3Bbcampbell@pingidentity.com>=3B
To: Stephen Farrell <=3Bstephen.farrell@cs.tcd.ie>=3B
Cc: "=3Boauth-chairs@tools.ietf.org"=3B <=3Boauth-chairs@tools.ie= tf.org>=3B=2C
 =3B =3B =3B =3B =3B =3B =3B draft-ietf-oauth-s= aml2-bearer@tools.ietf.org=2C The IESG
 =3B =3B =3B =3B =3B =3B =3B <=3Biesg@ietf.or= g>=3B=2C Peter Saint-Andre <=3Bstpeter@stpeter.im>=3B=2C oauth
 =3B =3B =3B =3B =3B =3B =3B <=3Boauth@ietf.o= rg>=3B
Subject: Re: [OAUTH-WG] Stephen Farrell's No Objection on
 =3B =3B =3B =3B =3B =3B =3B draft-ietf-oauth-s= aml2-bearer-21: (with COMMENT)
Message-ID:
 =3B =3B =3B =3B =3B =3B =3B <=3BCA+=3Bk3e= CRKjW8+=3B_NobCFyNWfHzTzD-S6_7rXFktEKoY0s9PqVzdw@mail.gmail.com>=3B Content-Type: text/plain=3B charset=3D"=3Butf-8"=3B

Stephen=2C

I'm working on updating these drafts and as I look again at the text that's=
in ?5. Interoperability Considerations and the requirement in ?3 Assertion<= br> Format and Processing Requirements to compare these values using the Simple=
String Comparison (absent an application profile specifying otherwise) I'm<= br> not sure what to say or where based on your suggestion below. Is there
something specific you can suggest (and where to put it)?

Thanks=2C
Brian

On Thu=2C Oct 16=2C 2014 at 3:20 PM=2C Brian Campbell <=3Bbcampbell@pingi= dentity.com>=3B
wrote:

>=3B
>=3B On Thu=2C Oct 16=2C 2014 at 2:54 PM=2C Stephen Farrell <=3B
>=3B stephen.farrell@cs.tcd.ie>=3B wrote:
>=3B
>=3B>=3B
>=3B>=3B >=3B Some stuff needs to be exchanged out-of-band for this t= o work.
>=3B>=3B >=3B Entity/issuer/audience identifiers are part of that. Th= is need is
>=3B>=3B discussed
>=3B>=3B >=3B in the Interoperability Considerations at
>=3B>=3B >=3B https://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-21#section-5<= br> >=3B>=3B
>=3B>=3B So I think it'd be good to explicitly call out that these
>=3B>=3B mappings are basically required and that they can be fraught >=3B>=3B (e.g. if someone uses wildcards badly=2C which they do).
>=3B>=3B
>=3B
>=3B OK=2C I will add something to that effect in the next revisions.
>=3B
>=3B
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <=3Bhttp://www.ietf.org/mail-archive/web/o= auth/attachments/20141017/2cdb2c08/attachment.html>=3B

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

Message: 2
Date: Fri=2C 17 Oct 2014 18:12:01 -0700
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
Cc: oauth@ietf.org
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-json-web-token-29.txt
Message-ID: <=3B20141018011201.12233.99151.idtracker@ietfa.amsl.com>=3B=
Content-Type: text/plain=3B charset=3D"=3Butf-8"=3B


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
 =3BThis draft is a work item of the Web Authorization Protocol Working= Group of the IETF.

 =3B =3B =3B =3B =3B =3B =3B Title =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B : JSON = Web Token (JWT)
 =3B =3B =3B =3B =3B =3B =3B Authors =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B : Michael B. Jones  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B John Bradley
 =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B Nat Sakimura
 =3B =3B =3B =3B =3B =3B =3B Filename =3B&n= bsp=3B =3B =3B =3B =3B =3B : draft-ietf-oauth-json-web-= token-29.txt
 =3B =3B =3B =3B =3B =3B =3B Pages =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B : 34  =3B =3B =3B =3B =3B =3B =3B Date =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B= : 2014-10-17

Abstract:
 =3B =3B JSON Web Token (JWT) is a compact=2C URL-safe means of rep= resenting
 =3B =3B claims to be transferred between two parties. =3B The = claims in a JWT
 =3B =3B are encoded as a JavaScript Object Notation (JSON) object = that is
 =3B =3B used as the payload of a JSON Web Signature (JWS) structur= e or as the
 =3B =3B plaintext of a JSON Web Encryption (JWE) structure=2C enab= ling the
 =3B =3B claims to be digitally signed or MACed and/or encrypted.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/
There's also a htmlized version available at:
h= ttp://tools.ietf.org/html/draft-ietf-oauth-json-web-token-29

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-json-web-token-2= 9


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/



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

Message: 3
Date: Sat=2C 18 Oct 2014 01:32:33 +=3B0000
From: Mike Jones <=3BMichael.Jones@microsoft.com>=3B
To: "=3Boauth@ietf.org"=3B <=3Boauth@ietf.org>=3B
Subject: [OAUTH-WG] FW: JOSE -35 and JWT -29 drafts addressing AppsDir
 =3B =3B =3B =3B =3B =3B =3B review comments Message-ID:
 =3B =3B =3B =3B =3B =3B =3B <=3B4E1F6AAD2497= 5D4BA5B16804296739439BB17A92@TK5EX14MBXC286.redmond.corp.microsoft.com>= =3B
 =3B =3B =3B =3B =3B =3B =3B
Content-Type: text/plain=3B charset=3D"=3Bus-ascii"=3B



From: Mike Jones
Sent: Friday=2C October 17=2C 2014 6:32 PM
To: jose@ietf.org
Subject: JOSE -35 and JWT -29 drafts addressing AppsDir review comments

I've posted updated JOSE and JWT drafts that address the Applications Area = Directorate review comments. =3B Thanks to Ray Polk and Carsten Bormann= for their useful reviews. =3B No breaking changes were made.

The specifications are available at:

* =3B =3B =3B =3B =3B =3B =3B =3B http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-35

* =3B =3B =3B =3B =3B =3B =3B =3B http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-35

* =3B =3B =3B =3B =3B =3B =3B =3B http://tool= s.ietf.org/html/draft-ietf-jose-json-web-key-35

* =3B =3B =3B =3B =3B =3B =3B =3B http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-35

* =3B =3B =3B =3B =3B =3B =3B =3B http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-29

HTML formatted versions are available at:

* =3B =3B =3B =3B =3B =3B =3B =3B http://self-issued.info/docs/draft-ietf-jose-json-web-signature-35.html=

* =3B =3B =3B =3B =3B =3B =3B =3B http://self-issued.info/docs/draft-ietf-jose-json-web-encryption-35.html

* =3B =3B =3B =3B =3B =3B =3B =3B http://self-issued.info/docs/draft-ietf-jose-json-web-key-35.html

* =3B =3B =3B =3B =3B =3B =3B =3B http://self-issued.info/docs/draft-ietf-jose-json-web-algorithms-35.html

* =3B =3B =3B =3B =3B =3B =3B =3B http://self-issued.info/docs/draft-ietf-oauth-json-web-token-29.html
 =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B -- Mike

P.S. =3B I've also posted this notice at http://self-issued.info/?p=3D1293 and as @selfissued.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <=3Bhttp://www.ietf.org/mail-archive/web/o= auth/attachments/20141018/03a87bce/attachment.html>=3B

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

Message: 4
Date: Sat=2C 18 Oct 2014 11:58:34 -0700
From: Richard Barnes <=3Brlb@ipv.sx>=3B
To: Mike Jones <=3BMichael.Jones@microsoft.com>=3B
Cc: "=3Boauth-chairs@tools.ietf.org"=3B <=3Boauth-chairs@tools.ie= tf.org>=3B=2C
 =3B =3B =3B =3B =3B =3B =3B "=3Boauth@ietf= .org"=3B <=3Boauth@ietf.org>=3B=2C
 =3B =3B =3B =3B =3B =3B =3B "=3Bdraft-ietf= -oauth-json-web-token@tools.ietf.org"=3B
 =3B =3B =3B =3B =3B =3B =3B <=3Bdraft-ietf-o= auth-json-web-token@tools.ietf.org>=3B=2C The IESG
 =3B =3B =3B =3B =3B =3B =3B <=3Biesg@ietf.or= g>=3B
Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on
 =3B =3B =3B =3B =3B =3B =3B draft-ietf-oauth-j= son-web-token-27: (with DISCUSS and COMMENT)
Message-ID:
 =3B =3B =3B =3B =3B =3B =3B <=3BCAL02cgRXYfv= Ue4c5YH+=3BRRgUZLrwO5-MKG1cjTqM4ufw-WCRWpg@mail.gmail.com>=3B
Content-Type: text/plain=3B charset=3D"=3Butf-8"=3B

Dude=2C I cleared on the 10th :)

On Tue=2C Oct 14=2C 2014 at 5:53 AM=2C Mike Jones <=3BMichael.Jones@micro= soft.com>=3B
wrote:

>=3B The proposed resolution below has been incorporated in the -28 draft= .
>=3B Hopefully you can clear your DISCUSS on that basis.
>=3B
>=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B Thanks again=2C
>=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B -- Mike
>=3B
>=3B >=3B -----Original Message-----
>=3B >=3B From: OAuth [mailto= :oauth-bounces@ietf.org] On Behalf Of Mike Jones
>=3B >=3B Sent: Saturday=2C October 11=2C 2014 12:54 PM
>=3B >=3B To: Richard Barnes
>=3B >=3B Cc: draft-ietf-oauth-json-web-token@tools.ietf.org=3B oauth-<= br> >=3B >=3B chairs@tools.ietf.org=3B The IESG=3B oauth@ietf.org
>=3B >=3B Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on
>=3B draft-ietf-oauth-json-web-
>=3B >=3B token-27: (with DISCUSS and COMMENT)
>=3B >=3B
>=3B >=3B >=3B From: Richard Barnes [ma= ilto:rlb@ipv.sx]
>=3B >=3B >=3B Sent: Friday=2C October 10=2C 2014 2:37 PM
>=3B >=3B >=3B To: Mike Jones
>=3B >=3B >=3B Cc: The IESG=3B oauth-chairs@tools.ietf.org=3B oauth@i= etf.org=3B
>=3B >=3B >=3B draft-ietf-oauth-json-web-token@tools.ietf.org
>=3B >=3B >=3B Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on
>=3B >=3B >=3B draft-ietf-oauth-json-web-token-27: (with DISCUSS and = COMMENT)
>=3B >=3B >=3B
>=3B >=3B >=3B On Mon=2C Oct 6=2C 2014 at 3:54 AM=2C Mike Jones
>=3B >=3B <=3BMichael.Jones@microsoft.com>=3B wrote:
>=3B >=3B >=3B Thanks for your review=2C Richard. =3B My response= s are inline below...
>=3B >=3B >=3B
>=3B >=3B >=3B >=3B -----Original Message-----
>=3B >=3B >=3B >=3B From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Richard
>=3B >=3B >=3B >=3B Barnes
>=3B >=3B >=3B >=3B Sent: Wednesday=2C October 01=2C 2014 7:57 PM >=3B >=3B >=3B >=3B To: The IESG
>=3B >=3B >=3B >=3B Cc: oauth-chairs@tools.ietf.org=3B oauth@ietf.o= rg=3B
>=3B >=3B >=3B >=3B draft-ietf-oauth-json-web- token@tools.ietf.org=
>=3B >=3B >=3B >=3B Subject: [OAUTH-WG] Richard Barnes' Discuss on<= br> >=3B >=3B >=3B >=3B draft-ietf-oauth-json-web-
>=3B >=3B >=3B >=3B token-27: (with DISCUSS and COMMENT)
>=3B >=3B >=3B >=3B
>=3B >=3B >=3B >=3B Richard Barnes has entered the following ballot= position for
>=3B >=3B >=3B >=3B draft-ietf-oauth-json-web-token-27: Discuss
>=3B >=3B >=3B >=3B
>=3B >=3B >=3B >=3B When responding=2C please keep the subject line= intact and reply to
>=3B >=3B >=3B >=3B all email addresses included in the To and CC l= ines. (Feel free to
>=3B >=3B >=3B >=3B cut this introductory paragraph=2C however.) >=3B >=3B >=3B >=3B
>=3B >=3B >=3B >=3B
>=3B >=3B >=3B >=3B Please refer to
>=3B >=3B >=3B >=3B http://www.ietf.org/iesg/statement/discuss-criteria.h= tml
>=3B >=3B >=3B >=3B for more information about IESG DISCUSS and COM= MENT positions.
>=3B >=3B >=3B >=3B
>=3B >=3B >=3B >=3B
>=3B >=3B >=3B >=3B The document=2C along with other ballot positio= ns=2C can be found here:
>=3B >=3B >=3B >=3B http://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/
>=3B >=3B >=3B >=3B
>=3B >=3B >=3B >=3B
>=3B >=3B >=3B >=3B
>=3B >=3B >=3B >=3B -----------------------------------------------= ---------------------
>=3B >=3B >=3B >=3B --
>=3B >=3B >=3B >=3B DISCUSS:
>=3B >=3B >=3B >=3B -----------------------------------------------= ---------------------
>=3B >=3B >=3B >=3B --
>=3B >=3B >=3B >=3B
>=3B >=3B >=3B >=3B Section 7.
>=3B >=3B >=3B >=3B In order to prevent confusion between secured a= nd Unsecured JWTs=2C
>=3B >=3B >=3B >=3B the validation steps here need to call for the = application to
>=3B specify which is
>=3B >=3B required.
>=3B >=3B >=3B
>=3B >=3B >=3B Per my response on your JWS comments=2C this is alread= y handed in a more
>=3B >=3B general way in the JWS validation steps. =3B Specifically= =2C the last
>=3B paragraph of
>=3B >=3B Section 5.2 is:
>=3B >=3B >=3B
>=3B >=3B >=3B "=3BFinally=2C note that it is an application deci= sion which algorithms are
>=3B acceptable
>=3B >=3B in a given context. Even if a JWS can be successfully validat= ed=2C unless
>=3B the
>=3B >=3B algorithm(s) used in the JWS are acceptable to the applicatio= n=2C it
>=3B SHOULD reject
>=3B >=3B the JWS."=3B
>=3B >=3B >=3B
>=3B >=3B >=3B I've cleared this DISCUSS in the interest of having th= is fight over in
>=3B JWS thread.
>=3B >=3B But I also added the following COMMENT:
>=3B >=3B >=3B "=3BIt would be good for this document to pass on = the note from JWS about
>=3B >=3B selecting which algorithms are acceptable=2C and in particula= r=2C whether
>=3B unsecured
>=3B >=3B JWTs are acceptable."=3B
>=3B >=3B
>=3B >=3B Thanks for clearing the DISCUSS. =3B I'm fine repeating t= he note about
>=3B acceptable
>=3B >=3B algorithms in the JWT spec=2C assuming others are.
>=3B >=3B
>=3B >=3B >=3B I would therefore request that you likewise withdraw t= his DISCUSS on
>=3B that
>=3B >=3B basis.
>=3B >=3B
>=3B >=3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B -- Mike
>=3B >=3B
>=3B >=3B _______________________________________________
>=3B >=3B OAuth mailing list
>=3B >=3B OAuth@ietf.org
>=3B >=3B https= ://www.ietf.org/mailman/listinfo/oauth
>=3B
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <=3Bhttp://www.ietf.org/mail-archive/web/o= auth/attachments/20141018/2dca48a8/attachment.html>=3B

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

Subject: Digest Footer

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


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

End of OAuth Digest=2C Vol 72=2C Issue 55
*************************************
--_88cac988-ddf5-45d5-9cec-87af8fce28e9_-- From nobody Sat Oct 18 12:00:14 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDE7F1A8A6E for ; Sat, 18 Oct 2014 12:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y_ZzYxirvZxj for ; Sat, 18 Oct 2014 12:00:09 -0700 (PDT) Received: from BLU004-OMC1S2.hotmail.com (blu004-omc1s2.hotmail.com [65.55.116.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30D941A036B for ; Sat, 18 Oct 2014 12:00:08 -0700 (PDT) Received: from BLU406-EAS159 ([65.55.116.9]) by BLU004-OMC1S2.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Sat, 18 Oct 2014 12:00:07 -0700 X-TMN: [+fEIgt8khDS2PnEnW9qqHAn6TgwfJKZy] X-Originating-Email: [panca70@outlook.com] Message-ID: Content-Type: multipart/alternative; boundary="_56cb1888-971e-40e9-81cf-d9ada375f92d_" MIME-Version: 1.0 X-Client-ID: 123 X-Mailer: BlackBerry Email (10.2.1.3247) Date: Sun, 19 Oct 2014 02:00:04 +0700 From: Panca Agus Ananda To: , X-OriginalArrivalTime: 18 Oct 2014 19:00:07.0251 (UTC) FILETIME=[BBA46230:01CFEB05] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/P7AnX1e6-Ka-uxuIQFwuwHxJGvg Subject: [OAUTH-WG] Bls: OAuth Digest, Vol 72, Issue 55 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Oct 2014 19:00:12 -0000 --_56cb1888-971e-40e9-81cf-d9ada375f92d_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Dikirim dari ponsel cerdas BlackBerry 10 saya dengan jaringan Telkomsel. Dari: oauth-request@ietf.org Terkirim: Minggu=2C 19 Oktober 2014 01.58 Ke: oauth@ietf.org Balas Ke: oauth@ietf.org Perihal: OAuth Digest=2C Vol 72=2C Issue 55 Send OAuth mailing list submissions to oauth@ietf.org To subscribe or unsubscribe via the World Wide Web=2C visit https://www.ietf.org/mailman/listinfo/oauth or=2C via email=2C send a message with subject or body 'help' to oauth-request@ietf.org You can reach the person managing the list at oauth-owner@ietf.org When replying=2C please edit your Subject line so it is more specific than "Re: Contents of OAuth digest..." Today's Topics: 1. Re: Stephen Farrell's No Objection on draft-ietf-oauth-saml2-bearer-21: (with COMMENT) (Brian Campbell) 2. I-D Action: draft-ietf-oauth-json-web-token-29.txt (internet-drafts@ietf.org) 3. FW: JOSE -35 and JWT -29 drafts addressing AppsDir review comments (Mike Jones) 4. Re: Richard Barnes' Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) (Richard Barnes) ---------------------------------------------------------------------- Message: 1 Date: Fri=2C 17 Oct 2014 16:41:02 -0600 From: Brian Campbell To: Stephen Farrell Cc: "oauth-chairs@tools.ietf.org" =2C draft-ietf-oauth-saml2-bearer@tools.ietf.org=2C The IESG =2C Peter Saint-Andre =2C oauth Subject: Re: [OAUTH-WG] Stephen Farrell's No Objection on draft-ietf-oauth-saml2-bearer-21: (with COMMENT) Message-ID: Content-Type: text/plain=3B charset=3D"utf-8" Stephen=2C I'm working on updating these drafts and as I look again at the text that's in ?5. Interoperability Considerations and the requirement in ?3 Assertion Format and Processing Requirements to compare these values using the Simple String Comparison (absent an application profile specifying otherwise) I'm not sure what to say or where based on your suggestion below. Is there something specific you can suggest (and where to put it)? Thanks=2C Brian On Thu=2C Oct 16=2C 2014 at 3:20 PM=2C Brian Campbell wrote: > > On Thu=2C Oct 16=2C 2014 at 2:54 PM=2C Stephen Farrell < > stephen.farrell@cs.tcd.ie> wrote: > >> >> > Some stuff needs to be exchanged out-of-band for this to work. >> > Entity/issuer/audience identifiers are part of that. This need is >> discussed >> > in the Interoperability Considerations at >> > https://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-21#section-5 >> >> So I think it'd be good to explicitly call out that these >> mappings are basically required and that they can be fraught >> (e.g. if someone uses wildcards badly=2C which they do). >> > > OK=2C I will add something to that effect in the next revisions. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Fri=2C 17 Oct 2014 18:12:01 -0700 From: internet-drafts@ietf.org To: i-d-announce@ietf.org Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-json-web-token-29.txt Message-ID: <20141018011201.12233.99151.idtracker@ietfa.amsl.com> Content-Type: text/plain=3B charset=3D"utf-8" 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 Working Group = of the IETF. Title : JSON Web Token (JWT) Authors : Michael B. Jones John Bradley Nat Sakimura Filename : draft-ietf-oauth-json-web-token-29.txt Pages : 34 Date : 2014-10-17 Abstract: JSON Web Token (JWT) is a compact=2C URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JavaScript Object Notation (JSON) object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure=2C enabling the claims to be digitally signed or MACed and/or encrypted. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-29 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-json-web-token-29 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/ ------------------------------ Message: 3 Date: Sat=2C 18 Oct 2014 01:32:33 +0000 From: Mike Jones To: "oauth@ietf.org" Subject: [OAUTH-WG] FW: JOSE -35 and JWT -29 drafts addressing AppsDir review comments Message-ID: <4E1F6AAD24975D4BA5B16804296739439BB17A92@TK5EX14MBXC286.redmond.co= rp.microsoft.com> Content-Type: text/plain=3B charset=3D"us-ascii" From: Mike Jones Sent: Friday=2C October 17=2C 2014 6:32 PM To: jose@ietf.org Subject: JOSE -35 and JWT -29 drafts addressing AppsDir review comments I've posted updated JOSE and JWT drafts that address the Applications Area = Directorate review comments. Thanks to Ray Polk and Carsten Bormann for th= eir useful reviews. No breaking changes were made. The specifications are available at: * http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-35 * http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-35 * http://tools.ietf.org/html/draft-ietf-jose-json-web-key-35 * http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-35 * http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-29 HTML formatted versions are available at: * http://self-issued.info/docs/draft-ietf-jose-json-web-signature-3= 5.html * http://self-issued.info/docs/draft-ietf-jose-json-web-encryption-= 35.html * http://self-issued.info/docs/draft-ietf-jose-json-web-key-35.html * http://self-issued.info/docs/draft-ietf-jose-json-web-algorithms-= 35.html * http://self-issued.info/docs/draft-ietf-oauth-json-web-token-29.h= tml -- Mike P.S. I've also posted this notice at http://self-issued.info/?p=3D1293 and= as @selfissued. -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 4 Date: Sat=2C 18 Oct 2014 11:58:34 -0700 From: Richard Barnes To: Mike Jones Cc: "oauth-chairs@tools.ietf.org" =2C "oauth@ietf.org" =2C "draft-ietf-oauth-json-web-token@tools.ietf.org" =2C The IESG Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) Message-ID: Content-Type: text/plain=3B charset=3D"utf-8" Dude=2C I cleared on the 10th :) On Tue=2C Oct 14=2C 2014 at 5:53 AM=2C Mike Jones wrote: > The proposed resolution below has been incorporated in the -28 draft. > Hopefully you can clear your DISCUSS on that basis. > > Thanks again=2C > -- Mike > > > -----Original Message----- > > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones > > Sent: Saturday=2C October 11=2C 2014 12:54 PM > > To: Richard Barnes > > Cc: draft-ietf-oauth-json-web-token@tools.ietf.org=3B oauth- > > chairs@tools.ietf.org=3B The IESG=3B oauth@ietf.org > > Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on > draft-ietf-oauth-json-web- > > token-27: (with DISCUSS and COMMENT) > > > > > From: Richard Barnes [mailto:rlb@ipv.sx] > > > Sent: Friday=2C October 10=2C 2014 2:37 PM > > > To: Mike Jones > > > Cc: The IESG=3B oauth-chairs@tools.ietf.org=3B oauth@ietf.org=3B > > > draft-ietf-oauth-json-web-token@tools.ietf.org > > > Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on > > > draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) > > > > > > On Mon=2C Oct 6=2C 2014 at 3:54 AM=2C Mike Jones > > wrote: > > > Thanks for your review=2C Richard. My responses are inline below... > > > > > > > -----Original Message----- > > > > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Richard > > > > Barnes > > > > Sent: Wednesday=2C October 01=2C 2014 7:57 PM > > > > To: The IESG > > > > Cc: oauth-chairs@tools.ietf.org=3B oauth@ietf.org=3B > > > > draft-ietf-oauth-json-web- token@tools.ietf.org > > > > Subject: [OAUTH-WG] Richard Barnes' Discuss on > > > > draft-ietf-oauth-json-web- > > > > token-27: (with DISCUSS and COMMENT) > > > > > > > > Richard Barnes has entered the following ballot position for > > > > draft-ietf-oauth-json-web-token-27: Discuss > > > > > > > > When responding=2C please keep the subject line intact and reply to > > > > all email addresses included in the To and CC lines. (Feel free to > > > > cut this introductory paragraph=2C however.) > > > > > > > > > > > > Please refer to > > > > http://www.ietf.org/iesg/statement/discuss-criteria.html > > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > > > > The document=2C along with other ballot positions=2C can be found h= ere: > > > > http://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/ > > > > > > > > > > > > > > > > -------------------------------------------------------------------= - > > > > -- > > > > DISCUSS: > > > > -------------------------------------------------------------------= - > > > > -- > > > > > > > > Section 7. > > > > In order to prevent confusion between secured and Unsecured JWTs=2C > > > > the validation steps here need to call for the application to > specify which is > > required. > > > > > > Per my response on your JWS comments=2C this is already handed in a m= ore > > general way in the JWS validation steps. Specifically=2C the last > paragraph of > > Section 5.2 is: > > > > > > "Finally=2C note that it is an application decision which algorithms = are > acceptable > > in a given context. Even if a JWS can be successfully validated=2C unle= ss > the > > algorithm(s) used in the JWS are acceptable to the application=2C it > SHOULD reject > > the JWS." > > > > > > I've cleared this DISCUSS in the interest of having this fight over i= n > JWS thread. > > But I also added the following COMMENT: > > > "It would be good for this document to pass on the note from JWS abou= t > > selecting which algorithms are acceptable=2C and in particular=2C wheth= er > unsecured > > JWTs are acceptable." > > > > Thanks for clearing the DISCUSS. I'm fine repeating the note about > acceptable > > algorithms in the JWT spec=2C assuming others are. > > > > > I would therefore request that you likewise withdraw this DISCUSS on > that > > basis. > > > > -- Mike > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Subject: Digest Footer _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------------------------------ End of OAuth Digest=2C Vol 72=2C Issue 55 ************************************* --_56cb1888-971e-40e9-81cf-d9ada375f92d_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"


Dikirim dari ponsel cerdas BlackBerry 10 saya dengan jaringan Telkomsel.
Dari: oauth-request@ietf.org
Terkirim: Minggu=2C 19 Oktober 2014 01.58
Ke: oauth@ietf.org
Balas Ke: oauth@ietf.org
Perihal: OAuth Digest=2C Vol 72=2C Issue 55

Send OAuth mailing list submissions to
 =3B =3B =3B =3B =3B =3B =3B oauth@ietf.org

To subscribe or unsubscribe via the World Wide Web=2C visit
 =3B =3B =3B =3B =3B =3B =3B https://www.ietf.org/mailman/listinfo= /oauth
or=2C via email=2C send a message with subject or body 'help' to
 =3B =3B =3B =3B =3B =3B =3B oauth-request@ietf= .org

You can reach the person managing the list at
 =3B =3B =3B =3B =3B =3B =3B oauth-owner@ietf.o= rg

When replying=2C please edit your Subject line so it is more specific
than "=3BRe: Contents of OAuth digest..."=3B


Today's Topics:

 =3B =3B 1. Re: Stephen Farrell's No Objection on
 =3B =3B =3B =3B =3B draft-ietf-oauth-saml2-bearer-21: = (with COMMENT) (Brian Campbell)
 =3B =3B 2. I-D Action: draft-ietf-oauth-json-web-token-29.txt
 =3B =3B =3B =3B =3B (internet-drafts@ietf.org)
 =3B =3B 3. FW: JOSE -35 and JWT -29 drafts addressing AppsDir = =3B =3B =3B =3B =3B =3B =3B review
 =3B =3B =3B =3B =3B comments (Mike Jones)
 =3B =3B 4. Re: Richard Barnes' Discuss on
 =3B =3B =3B =3B =3B draft-ietf-oauth-json-web-token-27= : (with DISCUSS and COMMENT)
 =3B =3B =3B =3B =3B (Richard Barnes)


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

Message: 1
Date: Fri=2C 17 Oct 2014 16:41:02 -0600
From: Brian Campbell <=3Bbcampbell@pingidentity.com>=3B
To: Stephen Farrell <=3Bstephen.farrell@cs.tcd.ie>=3B
Cc: "=3Boauth-chairs@tools.ietf.org"=3B <=3Boauth-chairs@tools.ie= tf.org>=3B=2C
 =3B =3B =3B =3B =3B =3B =3B draft-ietf-oauth-s= aml2-bearer@tools.ietf.org=2C The IESG
 =3B =3B =3B =3B =3B =3B =3B <=3Biesg@ietf.or= g>=3B=2C Peter Saint-Andre <=3Bstpeter@stpeter.im>=3B=2C oauth
 =3B =3B =3B =3B =3B =3B =3B <=3Boauth@ietf.o= rg>=3B
Subject: Re: [OAUTH-WG] Stephen Farrell's No Objection on
 =3B =3B =3B =3B =3B =3B =3B draft-ietf-oauth-s= aml2-bearer-21: (with COMMENT)
Message-ID:
 =3B =3B =3B =3B =3B =3B =3B <=3BCA+=3Bk3e= CRKjW8+=3B_NobCFyNWfHzTzD-S6_7rXFktEKoY0s9PqVzdw@mail.gmail.com>=3B Content-Type: text/plain=3B charset=3D"=3Butf-8"=3B

Stephen=2C

I'm working on updating these drafts and as I look again at the text that's=
in ?5. Interoperability Considerations and the requirement in ?3 Assertion<= br> Format and Processing Requirements to compare these values using the Simple=
String Comparison (absent an application profile specifying otherwise) I'm<= br> not sure what to say or where based on your suggestion below. Is there
something specific you can suggest (and where to put it)?

Thanks=2C
Brian

On Thu=2C Oct 16=2C 2014 at 3:20 PM=2C Brian Campbell <=3Bbcampbell@pingi= dentity.com>=3B
wrote:

>=3B
>=3B On Thu=2C Oct 16=2C 2014 at 2:54 PM=2C Stephen Farrell <=3B
>=3B stephen.farrell@cs.tcd.ie>=3B wrote:
>=3B
>=3B>=3B
>=3B>=3B >=3B Some stuff needs to be exchanged out-of-band for this t= o work.
>=3B>=3B >=3B Entity/issuer/audience identifiers are part of that. Th= is need is
>=3B>=3B discussed
>=3B>=3B >=3B in the Interoperability Considerations at
>=3B>=3B >=3B https://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-21#section-5<= br> >=3B>=3B
>=3B>=3B So I think it'd be good to explicitly call out that these
>=3B>=3B mappings are basically required and that they can be fraught >=3B>=3B (e.g. if someone uses wildcards badly=2C which they do).
>=3B>=3B
>=3B
>=3B OK=2C I will add something to that effect in the next revisions.
>=3B
>=3B
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <=3Bhttp://www.ietf.org/mail-archive/web/o= auth/attachments/20141017/2cdb2c08/attachment.html>=3B

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

Message: 2
Date: Fri=2C 17 Oct 2014 18:12:01 -0700
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
Cc: oauth@ietf.org
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-json-web-token-29.txt
Message-ID: <=3B20141018011201.12233.99151.idtracker@ietfa.amsl.com>=3B=
Content-Type: text/plain=3B charset=3D"=3Butf-8"=3B


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
 =3BThis draft is a work item of the Web Authorization Protocol Working= Group of the IETF.

 =3B =3B =3B =3B =3B =3B =3B Title =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B : JSON = Web Token (JWT)
 =3B =3B =3B =3B =3B =3B =3B Authors =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B : Michael B. Jones  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B John Bradley
 =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B Nat Sakimura
 =3B =3B =3B =3B =3B =3B =3B Filename =3B&n= bsp=3B =3B =3B =3B =3B =3B : draft-ietf-oauth-json-web-= token-29.txt
 =3B =3B =3B =3B =3B =3B =3B Pages =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B : 34  =3B =3B =3B =3B =3B =3B =3B Date =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B= : 2014-10-17

Abstract:
 =3B =3B JSON Web Token (JWT) is a compact=2C URL-safe means of rep= resenting
 =3B =3B claims to be transferred between two parties. =3B The = claims in a JWT
 =3B =3B are encoded as a JavaScript Object Notation (JSON) object = that is
 =3B =3B used as the payload of a JSON Web Signature (JWS) structur= e or as the
 =3B =3B plaintext of a JSON Web Encryption (JWE) structure=2C enab= ling the
 =3B =3B claims to be digitally signed or MACed and/or encrypted.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/
There's also a htmlized version available at:
h= ttp://tools.ietf.org/html/draft-ietf-oauth-json-web-token-29

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-json-web-token-2= 9


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/



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

Message: 3
Date: Sat=2C 18 Oct 2014 01:32:33 +=3B0000
From: Mike Jones <=3BMichael.Jones@microsoft.com>=3B
To: "=3Boauth@ietf.org"=3B <=3Boauth@ietf.org>=3B
Subject: [OAUTH-WG] FW: JOSE -35 and JWT -29 drafts addressing AppsDir
 =3B =3B =3B =3B =3B =3B =3B review comments Message-ID:
 =3B =3B =3B =3B =3B =3B =3B <=3B4E1F6AAD2497= 5D4BA5B16804296739439BB17A92@TK5EX14MBXC286.redmond.corp.microsoft.com>= =3B
 =3B =3B =3B =3B =3B =3B =3B
Content-Type: text/plain=3B charset=3D"=3Bus-ascii"=3B



From: Mike Jones
Sent: Friday=2C October 17=2C 2014 6:32 PM
To: jose@ietf.org
Subject: JOSE -35 and JWT -29 drafts addressing AppsDir review comments

I've posted updated JOSE and JWT drafts that address the Applications Area = Directorate review comments. =3B Thanks to Ray Polk and Carsten Bormann= for their useful reviews. =3B No breaking changes were made.

The specifications are available at:

* =3B =3B =3B =3B =3B =3B =3B =3B http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-35

* =3B =3B =3B =3B =3B =3B =3B =3B http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-35

* =3B =3B =3B =3B =3B =3B =3B =3B http://tool= s.ietf.org/html/draft-ietf-jose-json-web-key-35

* =3B =3B =3B =3B =3B =3B =3B =3B http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-35

* =3B =3B =3B =3B =3B =3B =3B =3B http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-29

HTML formatted versions are available at:

* =3B =3B =3B =3B =3B =3B =3B =3B http://self-issued.info/docs/draft-ietf-jose-json-web-signature-35.html=

* =3B =3B =3B =3B =3B =3B =3B =3B http://self-issued.info/docs/draft-ietf-jose-json-web-encryption-35.html

* =3B =3B =3B =3B =3B =3B =3B =3B http://self-issued.info/docs/draft-ietf-jose-json-web-key-35.html

* =3B =3B =3B =3B =3B =3B =3B =3B http://self-issued.info/docs/draft-ietf-jose-json-web-algorithms-35.html

* =3B =3B =3B =3B =3B =3B =3B =3B http://self-issued.info/docs/draft-ietf-oauth-json-web-token-29.html
 =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B -- Mike

P.S. =3B I've also posted this notice at http://self-issued.info/?p=3D1293 and as @selfissued.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <=3Bhttp://www.ietf.org/mail-archive/web/o= auth/attachments/20141018/03a87bce/attachment.html>=3B

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

Message: 4
Date: Sat=2C 18 Oct 2014 11:58:34 -0700
From: Richard Barnes <=3Brlb@ipv.sx>=3B
To: Mike Jones <=3BMichael.Jones@microsoft.com>=3B
Cc: "=3Boauth-chairs@tools.ietf.org"=3B <=3Boauth-chairs@tools.ie= tf.org>=3B=2C
 =3B =3B =3B =3B =3B =3B =3B "=3Boauth@ietf= .org"=3B <=3Boauth@ietf.org>=3B=2C
 =3B =3B =3B =3B =3B =3B =3B "=3Bdraft-ietf= -oauth-json-web-token@tools.ietf.org"=3B
 =3B =3B =3B =3B =3B =3B =3B <=3Bdraft-ietf-o= auth-json-web-token@tools.ietf.org>=3B=2C The IESG
 =3B =3B =3B =3B =3B =3B =3B <=3Biesg@ietf.or= g>=3B
Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on
 =3B =3B =3B =3B =3B =3B =3B draft-ietf-oauth-j= son-web-token-27: (with DISCUSS and COMMENT)
Message-ID:
 =3B =3B =3B =3B =3B =3B =3B <=3BCAL02cgRXYfv= Ue4c5YH+=3BRRgUZLrwO5-MKG1cjTqM4ufw-WCRWpg@mail.gmail.com>=3B
Content-Type: text/plain=3B charset=3D"=3Butf-8"=3B

Dude=2C I cleared on the 10th :)

On Tue=2C Oct 14=2C 2014 at 5:53 AM=2C Mike Jones <=3BMichael.Jones@micro= soft.com>=3B
wrote:

>=3B The proposed resolution below has been incorporated in the -28 draft= .
>=3B Hopefully you can clear your DISCUSS on that basis.
>=3B
>=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B Thanks again=2C
>=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B -- Mike
>=3B
>=3B >=3B -----Original Message-----
>=3B >=3B From: OAuth [mailto= :oauth-bounces@ietf.org] On Behalf Of Mike Jones
>=3B >=3B Sent: Saturday=2C October 11=2C 2014 12:54 PM
>=3B >=3B To: Richard Barnes
>=3B >=3B Cc: draft-ietf-oauth-json-web-token@tools.ietf.org=3B oauth-<= br> >=3B >=3B chairs@tools.ietf.org=3B The IESG=3B oauth@ietf.org
>=3B >=3B Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on
>=3B draft-ietf-oauth-json-web-
>=3B >=3B token-27: (with DISCUSS and COMMENT)
>=3B >=3B
>=3B >=3B >=3B From: Richard Barnes [ma= ilto:rlb@ipv.sx]
>=3B >=3B >=3B Sent: Friday=2C October 10=2C 2014 2:37 PM
>=3B >=3B >=3B To: Mike Jones
>=3B >=3B >=3B Cc: The IESG=3B oauth-chairs@tools.ietf.org=3B oauth@i= etf.org=3B
>=3B >=3B >=3B draft-ietf-oauth-json-web-token@tools.ietf.org
>=3B >=3B >=3B Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on
>=3B >=3B >=3B draft-ietf-oauth-json-web-token-27: (with DISCUSS and = COMMENT)
>=3B >=3B >=3B
>=3B >=3B >=3B On Mon=2C Oct 6=2C 2014 at 3:54 AM=2C Mike Jones
>=3B >=3B <=3BMichael.Jones@microsoft.com>=3B wrote:
>=3B >=3B >=3B Thanks for your review=2C Richard. =3B My response= s are inline below...
>=3B >=3B >=3B
>=3B >=3B >=3B >=3B -----Original Message-----
>=3B >=3B >=3B >=3B From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Richard
>=3B >=3B >=3B >=3B Barnes
>=3B >=3B >=3B >=3B Sent: Wednesday=2C October 01=2C 2014 7:57 PM >=3B >=3B >=3B >=3B To: The IESG
>=3B >=3B >=3B >=3B Cc: oauth-chairs@tools.ietf.org=3B oauth@ietf.o= rg=3B
>=3B >=3B >=3B >=3B draft-ietf-oauth-json-web- token@tools.ietf.org=
>=3B >=3B >=3B >=3B Subject: [OAUTH-WG] Richard Barnes' Discuss on<= br> >=3B >=3B >=3B >=3B draft-ietf-oauth-json-web-
>=3B >=3B >=3B >=3B token-27: (with DISCUSS and COMMENT)
>=3B >=3B >=3B >=3B
>=3B >=3B >=3B >=3B Richard Barnes has entered the following ballot= position for
>=3B >=3B >=3B >=3B draft-ietf-oauth-json-web-token-27: Discuss
>=3B >=3B >=3B >=3B
>=3B >=3B >=3B >=3B When responding=2C please keep the subject line= intact and reply to
>=3B >=3B >=3B >=3B all email addresses included in the To and CC l= ines. (Feel free to
>=3B >=3B >=3B >=3B cut this introductory paragraph=2C however.) >=3B >=3B >=3B >=3B
>=3B >=3B >=3B >=3B
>=3B >=3B >=3B >=3B Please refer to
>=3B >=3B >=3B >=3B http://www.ietf.org/iesg/statement/discuss-criteria.h= tml
>=3B >=3B >=3B >=3B for more information about IESG DISCUSS and COM= MENT positions.
>=3B >=3B >=3B >=3B
>=3B >=3B >=3B >=3B
>=3B >=3B >=3B >=3B The document=2C along with other ballot positio= ns=2C can be found here:
>=3B >=3B >=3B >=3B http://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/
>=3B >=3B >=3B >=3B
>=3B >=3B >=3B >=3B
>=3B >=3B >=3B >=3B
>=3B >=3B >=3B >=3B -----------------------------------------------= ---------------------
>=3B >=3B >=3B >=3B --
>=3B >=3B >=3B >=3B DISCUSS:
>=3B >=3B >=3B >=3B -----------------------------------------------= ---------------------
>=3B >=3B >=3B >=3B --
>=3B >=3B >=3B >=3B
>=3B >=3B >=3B >=3B Section 7.
>=3B >=3B >=3B >=3B In order to prevent confusion between secured a= nd Unsecured JWTs=2C
>=3B >=3B >=3B >=3B the validation steps here need to call for the = application to
>=3B specify which is
>=3B >=3B required.
>=3B >=3B >=3B
>=3B >=3B >=3B Per my response on your JWS comments=2C this is alread= y handed in a more
>=3B >=3B general way in the JWS validation steps. =3B Specifically= =2C the last
>=3B paragraph of
>=3B >=3B Section 5.2 is:
>=3B >=3B >=3B
>=3B >=3B >=3B "=3BFinally=2C note that it is an application deci= sion which algorithms are
>=3B acceptable
>=3B >=3B in a given context. Even if a JWS can be successfully validat= ed=2C unless
>=3B the
>=3B >=3B algorithm(s) used in the JWS are acceptable to the applicatio= n=2C it
>=3B SHOULD reject
>=3B >=3B the JWS."=3B
>=3B >=3B >=3B
>=3B >=3B >=3B I've cleared this DISCUSS in the interest of having th= is fight over in
>=3B JWS thread.
>=3B >=3B But I also added the following COMMENT:
>=3B >=3B >=3B "=3BIt would be good for this document to pass on = the note from JWS about
>=3B >=3B selecting which algorithms are acceptable=2C and in particula= r=2C whether
>=3B unsecured
>=3B >=3B JWTs are acceptable."=3B
>=3B >=3B
>=3B >=3B Thanks for clearing the DISCUSS. =3B I'm fine repeating t= he note about
>=3B acceptable
>=3B >=3B algorithms in the JWT spec=2C assuming others are.
>=3B >=3B
>=3B >=3B >=3B I would therefore request that you likewise withdraw t= his DISCUSS on
>=3B that
>=3B >=3B basis.
>=3B >=3B
>=3B >=3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B -- Mike
>=3B >=3B
>=3B >=3B _______________________________________________
>=3B >=3B OAuth mailing list
>=3B >=3B OAuth@ietf.org
>=3B >=3B https= ://www.ietf.org/mailman/listinfo/oauth
>=3B
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <=3Bhttp://www.ietf.org/mail-archive/web/o= auth/attachments/20141018/2dca48a8/attachment.html>=3B

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

Subject: Digest Footer

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


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

End of OAuth Digest=2C Vol 72=2C Issue 55
*************************************
--_56cb1888-971e-40e9-81cf-d9ada375f92d_-- From nobody Sat Oct 18 12:41:01 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AF801A0069; Sat, 18 Oct 2014 12:40: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kcZ5h0I0gbnZ; Sat, 18 Oct 2014 12:40:54 -0700 (PDT) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 097D51A020B; Sat, 18 Oct 2014 12:40:53 -0700 (PDT) Received: by mail-qc0-f181.google.com with SMTP id r5so2108461qcx.12 for ; Sat, 18 Oct 2014 12:40:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qy5ImFT2ksFQuVq9RU8s3rktkrdVTw1wz7qEtFaQF9o=; b=AFIfuYugaTXKQFcF3XgyLU6FKTzJGKeS8Kfqm21XEae+n8PUnhG/IkOrTxScCW8Efy EOJcHICiz4/iW5Rt97QjMnjNMAzUeg5XzSjMWHP7XlZHiY3Oz3zrRL7zaGZk0PMrWXrD QrywUQRD6ZVWlb8gsljM/eJc3zbnJGQ/REKFnLeEtMlQTBGI2qvxAP/uNe4TjfI01fWX PBT0xz+0y63KY/+h45aJzNrGHKevMA/gBxSDQlSIptON5PnWgm6pqcbpBoKV9l+Rr4KR 3SyzD/ObYHFO23eRazljdO8f3tsVLQ+WsQq3NuulSr0mhS1GAaJOwrBPuCRqFZew42lw rpBg== X-Received: by 10.140.104.114 with SMTP id z105mr21377563qge.75.1413661253073; Sat, 18 Oct 2014 12:40:53 -0700 (PDT) Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by mx.google.com with ESMTPSA id a9sm3894828qgf.7.2014.10.18.12.40.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 18 Oct 2014 12:40:51 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: multipart/alternative; boundary=Apple-Mail-B76DB45C-02F2-4B8C-83B0-28728E0D11A2 Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: Date: Sat, 18 Oct 2014 15:40:52 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <4E1F6AAD24975D4BA5B16804296739439BB0D5A7@TK5EX14MBXC286.redmond.corp.microsoft.com> To: Richard Barnes Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/BSZRPTNhr6zGJVg88OaFzBap3kk Cc: "draft-ietf-oauth-json-web-token@tools.ietf.org" , The IESG , "oauth-chairs@tools.ietf.org" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Oct 2014 19:40:56 -0000 --Apple-Mail-B76DB45C-02F2-4B8C-83B0-28728E0D11A2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Thanks, Richard & Mike! Sent from my iPhone > On Oct 18, 2014, at 2:58 PM, Richard Barnes wrote: >=20 > Dude, I cleared on the 10th :) >=20 >> On Tue, Oct 14, 2014 at 5:53 AM, Mike Jones = wrote: >> The proposed resolution below has been incorporated in the -28 draft. Ho= pefully you can clear your DISCUSS on that basis. >>=20 >> Thanks again, >> -- Mike >>=20 >> > -----Original Message----- >> > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones >> > Sent: Saturday, October 11, 2014 12:54 PM >> > To: Richard Barnes >> > Cc: draft-ietf-oauth-json-web-token@tools.ietf.org; oauth- >> > chairs@tools.ietf.org; The IESG; oauth@ietf.org >> > Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-jso= n-web- >> > token-27: (with DISCUSS and COMMENT) >> > >> > > From: Richard Barnes [mailto:rlb@ipv.sx] >> > > Sent: Friday, October 10, 2014 2:37 PM >> > > To: Mike Jones >> > > Cc: The IESG; oauth-chairs@tools.ietf.org; oauth@ietf.org; >> > > draft-ietf-oauth-json-web-token@tools.ietf.org >> > > Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on >> > > draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) >> > > >> > > On Mon, Oct 6, 2014 at 3:54 AM, Mike Jones >> > wrote: >> > > Thanks for your review, Richard. My responses are inline below... >> > > >> > > > -----Original Message----- >> > > > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Richard >> > > > Barnes >> > > > Sent: Wednesday, October 01, 2014 7:57 PM >> > > > To: The IESG >> > > > Cc: oauth-chairs@tools.ietf.org; oauth@ietf.org; >> > > > draft-ietf-oauth-json-web- token@tools.ietf.org >> > > > Subject: [OAUTH-WG] Richard Barnes' Discuss on >> > > > draft-ietf-oauth-json-web- >> > > > token-27: (with DISCUSS and COMMENT) >> > > > >> > > > Richard Barnes has entered the following ballot position for >> > > > draft-ietf-oauth-json-web-token-27: Discuss >> > > > >> > > > When responding, please keep the subject line intact and reply to >> > > > all email addresses included in the To and CC lines. (Feel free to >> > > > cut this introductory paragraph, however.) >> > > > >> > > > >> > > > Please refer to >> > > > http://www.ietf.org/iesg/statement/discuss-criteria.html >> > > > for more information about IESG DISCUSS and COMMENT positions. >> > > > >> > > > >> > > > The document, along with other ballot positions, can be found here:= >> > > > http://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/ >> > > > >> > > > >> > > > >> > > > -------------------------------------------------------------------= - >> > > > -- >> > > > DISCUSS: >> > > > -------------------------------------------------------------------= - >> > > > -- >> > > > >> > > > Section 7. >> > > > In order to prevent confusion between secured and Unsecured JWTs, >> > > > the validation steps here need to call for the application to speci= fy which is >> > required. >> > > >> > > Per my response on your JWS comments, this is already handed in a mor= e >> > general way in the JWS validation steps. Specifically, the last paragr= aph of >> > Section 5.2 is: >> > > >> > > "Finally, note that it is an application decision which algorithms ar= e acceptable >> > in a given context. Even if a JWS can be successfully validated, unless= the >> > algorithm(s) used in the JWS are acceptable to the application, it SHOU= LD reject >> > the JWS." >> > > >> > > I've cleared this DISCUSS in the interest of having this fight over i= n JWS thread. >> > But I also added the following COMMENT: >> > > "It would be good for this document to pass on the note from JWS abou= t >> > selecting which algorithms are acceptable, and in particular, whether u= nsecured >> > JWTs are acceptable." >> > >> > Thanks for clearing the DISCUSS. I'm fine repeating the note about acc= eptable >> > algorithms in the JWT spec, assuming others are. >> > >> > > I would therefore request that you likewise withdraw this DISCUSS on t= hat >> > basis. >> > >> > -- Mike >> > >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail-B76DB45C-02F2-4B8C-83B0-28728E0D11A2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Thanks, Richard & Mike!

Sent from my iPhone

On Oct 18, 2014, at 2:58 PM, Richard Barnes <rlb@ipv.sx> wrote:

Dude, I cleared on the 10th :)

On Tue, Oct 14, 2014 at 5:53 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:
The proposed resolution below has been incorporated in the -28 draft.  Hopefully you can clear your DISCUSS on that basis.

                                Thanks again,
                                -- Mike

> -----Original Message-----
> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
> Sent: Saturday, October 11, 2014 12:54 PM
> To: Richard Barnes
> Cc: draft-ietf-oauth-json-web-token@tools.ietf.org; oauth-
> chairs@tools.ietf.org; The IESG; oauth@ietf.org
> Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on draft-ietf-oauth-json-web-
> token-27: (with DISCUSS and COMMENT)
>
> > From: Richard Barnes [mailto:rlb@ipv.sx]
> > Sent: Friday, October 10, 2014 2:37 PM
> > To: Mike Jones
> > Cc: The IESG; oauth-chairs@tools.ietf.org; oauth@ietf.org;
> > draft-ietf-oauth-json-web-token@tools.ietf.org
> > Subject: Re: [OAUTH-WG] Richard Barnes' Discuss on
> > draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT)
> >
> > On Mon, Oct 6, 2014 at 3:54 AM, Mike Jones
> <Michael.Jones@microsoft.com> wrote:
> > Thanks for your review, Richard.  My responses are inline below...
> >
> > > -----Original Message-----
> > > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Richard
> > > Barnes
> > > Sent: Wednesday, October 01, 2014 7:57 PM
> > > To: The IESG
> > > Cc: oauth-chairs@tools.ietf.org; oauth@ietf.org;
> > > draft-ietf-oauth-json-web- token@tools.ietf.org
> > > Subject: [OAUTH-WG] Richard Barnes' Discuss on
> > > draft-ietf-oauth-json-web-
> > > token-27: (with DISCUSS and COMMENT)
> > >
> > > Richard Barnes has entered the following ballot position for
> > > draft-ietf-oauth-json-web-token-27: Discuss
> > >
> > > When responding, please keep the subject line intact and reply to
> > > all email addresses included in the To and CC lines. (Feel free to
> > > cut this introductory paragraph, however.)
> > >
> > >
> > > Please refer to
> > > http://www.ietf.org/iesg/statement/discuss-criteria.html
> > > for more information about IESG DISCUSS and COMMENT positions.
> > >
> > >
> > > The document, along with other ballot positions, can be found here:
> > > http://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/
> > >
> > >
> > >
> > > --------------------------------------------------------------------
> > > --
> > > DISCUSS:
> > > --------------------------------------------------------------------
> > > --
> > >
> > > Section 7.
> > > In order to prevent confusion between secured and Unsecured JWTs,
> > > the validation steps here need to call for the application to specify which is
> required.
> >
> > Per my response on your JWS comments, this is already handed in a more
> general way in the JWS validation steps.  Specifically, the last paragraph of
> Section 5.2 is:
> >
> > "Finally, note that it is an application decision which algorithms are acceptable
> in a given context. Even if a JWS can be successfully validated, unless the
> algorithm(s) used in the JWS are acceptable to the application, it SHOULD reject
> the JWS."
> >
> > I've cleared this DISCUSS in the interest of having this fight over in JWS thread.
> But I also added the following COMMENT:
> > "It would be good for this document to pass on the note from JWS about
> selecting which algorithms are acceptable, and in particular, whether unsecured
> JWTs are acceptable."
>
> Thanks for clearing the DISCUSS.  I'm fine repeating the note about acceptable
> algorithms in the JWT spec, assuming others are.
>
> > I would therefore request that you likewise withdraw this DISCUSS on that
> basis.
>
>                               -- Mike
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail-B76DB45C-02F2-4B8C-83B0-28728E0D11A2-- From nobody Sun Oct 19 08:47:38 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6DF1A1B4F for ; Sun, 19 Oct 2014 08:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.148 X-Spam-Level: * X-Spam-Status: No, score=1.148 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 4qL-MOs5g2Jl for ; Sun, 19 Oct 2014 08:47:34 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.29]) (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 013FA1A1B45 for ; Sun, 19 Oct 2014 08:47:34 -0700 (PDT) Received: from [80.67.16.116] (helo=webmail.df.eu) by smtprelay02.ispgateway.de with esmtpa (Exim 4.84) (envelope-from ) id 1Xfshg-0002Zi-9a; Sun, 19 Oct 2014 17:47:32 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Sun, 19 Oct 2014 17:47:32 +0200 From: torsten@lodderstedt.net To: Sergey Beryozkin In-Reply-To: <543ED519.3080902@gmail.com> References: <20141014182611.dd6598cc163e9c640d4167fd@nri.co.jp> <-1123724406662361791@unknownmsgid> <543ED519.3080902@gmail.com> Message-ID: X-Sender: torsten@lodderstedt.net User-Agent: Roundcube Webmail X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/ILAUBLFeaRz2H9JXQbcgvSJGNLk Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] SPOP - code verifier requirements X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Oct 2014 15:47:36 -0000 Hi, using the base64url alphabet seems a reasonable choice. kind regards, Torsten. Am 15.10.2014 22:12, schrieb Sergey Beryozkin: > Hi, in our project we ship a transformer implementation that assumes > that a code verifier represents a base64url encoded SHA-256 hash of > the code challenge > > Cheers, Sergey > On 15/10/14 19:48, Chuck Mortimore wrote: >> We're actually debating it internally. It seems easiest to just >> encode >> the binary code up front. Any issue with that? >> >> - cmort >> >> On Oct 15, 2014, at 8:32 AM, Nat Sakimura > > wrote: >> >>> Thanks. >>> >>> So, to be clear, are you base64url encoding when sending it over the >>> wire or is your code verifier is created by base64url encoding the >>> binary value so that you do not need to encode it when sending it >>> over? >>> >>> =nat via iPhone >>> >>> Oct 16, 2014 00:27、Chuck Mortimore >> > のメッセージ: >>> >>>> We went with base64url in our implementation >>>> >>>> On Tue, Oct 14, 2014 at 2:26 AM, Nat Sakimura >>> > wrote: >>>> >>>> In his mail, Mike asked whether code verifier is >>>> a value that is sendable without trnasformation >>>> as a http parameter value, or if it needs to be >>>> % encoded when it is being sent. >>>> >>>> We have several options here: >>>> >>>> 1) Require that the code verifier to be a base64url encoded >>>> string of a binary random value. >>>> >>>> 2) Let code verifier to be a binary string and require it to be >>>> either % encoded or base64url encoded when it is sent. >>>> In this case, which encoding should we use? >>>> >>>> 3) require the code verifier to be conform to the following >>>> ABNF: >>>> code_verifier = 16*128unreserved >>>> unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" >>>> >>>> Which one do you guys prefer? >>>> >>>> Nat >>>> >>>> -- >>>> Nat Sakimura (n-sakimura@nri.co.jp >>>> ) >>>> Nomura Research Institute, Ltd. >>>> >>>> PLEASE READ: >>>> The information contained in this e-mail is confidential and >>>> intended for the named recipient(s) only. >>>> If you are not an intended recipient of this e-mail, you are >>>> hereby notified that any review, dissemination, distribution or >>>> duplication of this message is strictly prohibited. If you have >>>> received this message in error, please notify the sender >>>> immediately and delete your copy from your system. >>>> >>>> _______________________________________________ >>>> 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 From nobody Sun Oct 19 23:20:46 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 468FC1A1BD7 for ; Sun, 19 Oct 2014 23:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 GDqHeBUh3J41 for ; Sun, 19 Oct 2014 23:20:15 -0700 (PDT) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF2841A6FA8 for ; Sun, 19 Oct 2014 23:20:13 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id c9so3214344qcz.9 for ; Sun, 19 Oct 2014 23:20:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Ssx37L8sdvUh9sKLIZm4DnlEd0uwsmarFP8vVJAlzMo=; b=eY2NlzNwkculLRAQwnANuxV0umymZePvigntSFMSbNCfUQvUX9i05Nn8nTre1+1npH ViPqmo47+x6SzkERg1Auw00gC84iLvSHixN7LE3esclOu4RYLwrA9mYxVUnig1r/HsUt Qg9KvyNZCVNes2QzzsDvGgC0AvGUm8D1iJkSEfsqv5NRDy53+Zq7OVGBKswgp28Pr+gD SNx1uEfDqeIpYakMmHJrtnPrnMbzFHZ/WcX3djg+uICMPHrSW78RKxm84FYQoSqcT2ue fqdnW7M2onQtpPQNUqQNnzEotTutLVPsZ3EJVlyHb2vqGvms+wR7BDTSZVDdsfwAv0iy tE4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Ssx37L8sdvUh9sKLIZm4DnlEd0uwsmarFP8vVJAlzMo=; b=kxvbCbOKq7RTaAnte73PjkHqjKkav9ZzgR4EpuvjADrNuPdVy7ZVutMpnkwV48UCkR xpomO8pm/OlhiEDjDWmAzehIHUdMabAjWsJIpBUfYwKdVxzmw5OrzUkxKFA//+Yxq9Ko Mp3jyUaQ1n0xWRp38Ja0NNVcdoQozGLNT8sobctbOvfxkSZVUwaIeG20WBBC7hpnvRgR +ckOhY2qiWvTy2/A1GbtdOuUDbMrsH31nr32toIWA9OPofozZ2WWVDBZvsYgC1QsIwel WAE2eo2BmDlTkFLaJzaNx6+iG+m6hS3k1BNG5uvV5+4kBop6WB4j3KV24xQ3qG8Aj4nG iDMA== X-Gm-Message-State: ALoCoQmDa3HqPlmLCW/LzV20/bYSBwN/wlMmAs+GzjRLSfOrU61eAX/6BGz4NBCjQcZ1WCSfvJ7N X-Received: by 10.140.88.70 with SMTP id s64mr30566070qgd.65.1413786012905; Sun, 19 Oct 2014 23:20:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.89.116 with HTTP; Sun, 19 Oct 2014 23:19:52 -0700 (PDT) In-Reply-To: <20141014181931.2011201bddc3f13e114ff42c@nri.co.jp> References: <54002809.2020101@gmx.net> <20141014181931.2011201bddc3f13e114ff42c@nri.co.jp> From: William Denniss Date: Sun, 19 Oct 2014 23:19:52 -0700 Message-ID: To: Nat Sakimura Content-Type: multipart/alternative; boundary=001a11c11ce016a5820505d4b55b Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/umwQUBE-flKawxly_xczZWJwWsI Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Define a server capaiblity discovery parameter? (was: Re: OAuth SPOP Detailed Review) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 06:20:18 -0000 --001a11c11ce016a5820505d4b55b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 1) n. I vote that we don't want discovery at all, as it adds a lot of complexity while yielding little to no benefit. I think we should support 2 transformations, plain (as mandated by the spec), and the best hashing algorithm that is commonly available (i.e. SHA256). If the spec needs to be updated in the future for a newer, better algorithm, a revised version of the spec could be created then. Due to the short window of time for code redemption, the hashing algorithm would have to be *seriously* broken to be unusable for spop. If this sounds good, I have a some draft wording with the above changes that could be incorporated. On Tue, Oct 14, 2014 at 2:19 AM, Nat Sakimura wrote: > In his mail, Hannes suggested to include more explicit reference to a > feature in the OpenID Connect Discovery spec in section 3.1. > > My response to it was that we could define a parameter here > and ask the implementers to implement it. Questions remains whether > we want to define it here or leave it to be out of scope. > > So, my questions are: > > (1) Do we want it? (y or n) > (2) if y, then adding the following text at the end of 3.1 be adequate? > > When the server supports OpenID Connect Discovery 1.0, the server MUST > advertise its capability with a parameter > oauth_spop_supported_alg. > The value of it is a JSON array of JSON strings representing > "alg" (Algorithm) Header Parameter Values for JWS as defined in > JSON Web Algorithms. > > Nat > > On Wed, 3 Sep 2014 02:28:57 +0900 > Nat Sakimura wrote: > > > Hi. Thanks for the detailed comments. > > > > Here are the responses to the questions raised in [1] > > > > [1] > > http://www.tschofenig.priv.at/oauth/draft-ietf-oauth-spop-00-hannes.doc > > > > 3.1 [Question: Would it make sense to provide some information also > > in the > > > Dynamic Client Registration specification? I am a bit unhappy about > > > not specifying at least one mechanism for learning this information > > > since it is important for the overall security -- to avoid > > > downgrading attacks.] > > > > > > I would have included it if OAuth has defined a discovery document. n > > fact, it may be a good starting point to discuss whether we should > > have a discovery document for OAuth. > > > > If the client does the per client registration, then it will not be a > > public client so spop would not be needed. > > The clients as a class may register itself, but then each client > > instance would not know if the server knows that it is using spop, > > and assuming it without verifying is not very safe. > > > > 3.1 [Hannes: Can we make a more explicit reference to a feature in the > > > OpenID Connect Discovery specification?] > > > > > > It will be an extension to section 3 of OpenID Connect Discovery. This > > specification may define a JSON name for such a parameter. Then, one > > can include it in the metadata. > > > > A candidate for such name would be: > > > > oauth_spop_supported_alg: > > > > and the value would be the strings representing supported algorithms. > > It could be drawn from JWA algs. > > > > A simpler alternative would be: > > > > oauth_spop_support: > > > > and the value would be true or false. > > > > However, we have no good place to advertise them as of now. > > > > 3.2 [Hannes: Do we really need this flexibility here?] > > > > > > It is there as an extension point. John has a draft that uses > > aymmetric algo. An early draft had HMAC as well. > > > > We could however drop it. I suppose we can add other algorithms later > > without breaking this one. > > > > [Hannes: The term 'front channel' is not defined anywhere.] > > > > > > Will define if this section survives. > > > > 3.7 [Hannes: Why is there a SHOULD rather than a MUST?] > > > > > > The server may have other considerations before returning successful > > response. > > > > 5. [Hannes: Which request channel are you talking about? There are two > > > types of request channels here, namely the Access Token > > > Request/Response and the Authorization Request / Response channel. > > > What do you mean by adequately protected here? How likely is it > > > that this can be accomplished? If it is rather unlikely then it > > > would be better to define a different transformation algorithm!] > > > > > > This is referring to the authorization request. > > > > On iOS as of the time of writing, not Jailbreaking seems to be > > adequate. For Android, only presenting the intended browser as the > > options to handle the request seems adequate. Similar considerations > > would be there per platform. > > > > Note: Authors do think that using other algorithms is better. > > However, it proved to be rather unpopular among the developers that > > they were in touch with and believe that we do need to provide this > > "no-transform" capability. > > > > For other "corrections", I am still working on to prepare comments as > > word comments. > > Most of editorial changes will be accepted. Some proposed technical > > changes seems to be due to the clauses being unclear, so I will try > > to propose a clarification rather than just accepting them. > > > > Best, > > > > Nat > > > > 2014-08-29 16:13 GMT+09:00 Hannes Tschofenig > > : > > > > > > Hi John, Hi Nat, > > > > > > I went through the document in detail and suggest some changes > > > (most of them editorial): > > > > http://www.tschofenig.priv.at/oauth/draft-ietf-oauth-spop-00-hannes.doc > > > > http://www.tschofenig.priv.at/oauth/draft-ietf-oauth-spop-00-hannes.pdf > > > > > > My main concern at the moment are some optional features in the spec > > > that make it less interoperable, such as the feature discovery, and > > > the transformation function. The latter might go away depending on > > > your answer to my question raised at > > > http://www.ietf.org/mail-archive/web/oauth/current/msg13354.html > > > but the former requires some specification work. > > > > > > Ciao > > > Hannes > > > > > > PS: I agree with James that the title of the document is a bit > > > misleading when compared with the other work we are doing in the > > > group. > > > > > > > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > > > -- > > Nat Sakimura (=3Dnat) > > Chairman, OpenID Foundation > > http://nat.sakimura.org/ > > @_nat_en > > > -- > Nat Sakimura (n-sakimura@nri.co.jp) > Nomura Research Institute, Ltd. > > =E6=9C=AC=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E5=90=AB=E3=81=BE=E3=82=8C= =E3=82=8B=E6=83=85=E5=A0=B1=E3=81=AF=E6=A9=9F=E5=AF=86=E6=83=85=E5=A0=B1=E3= =81=A7=E3=81=82=E3=82=8A=E3=80=81=E5=AE=9B=E5=85=88=E3=81=AB=E8=A8=98=E8=BC= =89=E3=81=95=E3=82=8C=E3=81=A6=E3=81=84=E3=82=8B=E6=96=B9=E3=81=AE=E3=81=BF= =E3=81=AB=E9=80=81=E4=BF=A1 > =E3=81=99=E3=82=8B=E3=81=93=E3=81=A8=E3=82=92=E6=84=8F=E5=9B=B3=E3=81=97= =E3=81=A6=E3=81=8A=E3=82=8A=E3=81=BE=E3=81=99=E3=80=82=E6=84=8F=E5=9B=B3=E3= =81=95=E3=82=8C=E3=81=9F=E5=8F=97=E5=8F=96=E4=BA=BA=E4=BB=A5=E5=A4=96=E3=81= =AE=E6=96=B9=E3=81=AB=E3=82=88=E3=82=8B=E3=81=93=E3=82=8C=E3=82=89=E3=81=AE= =E6=83=85=E5=A0=B1=E3=81=AE > =E9=96=8B=E7=A4=BA=E3=80=81=E8=A4=87=E8=A3=BD=E3=80=81=E5=86=8D=E9=85=8D= =E5=B8=83=E3=82=84=E8=BB=A2=E9=80=81=E3=81=AA=E3=81=A9=E4=B8=80=E5=88=87=E3= =81=AE=E5=88=A9=E7=94=A8=E3=81=8C=E7=A6=81=E6=AD=A2=E3=81=95=E3=82=8C=E3=81= =A6=E3=81=84=E3=81=BE=E3=81=99=E3=80=82=E8=AA=A4=E3=81=A3=E3=81=A6=E6=9C=AC= =E3=83=A1=E3=83=BC=E3=83=AB > =E3=82=92=E5=8F=97=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E5=A0=B4=E5=90=88= =E3=81=AF=E3=80=81=E7=94=B3=E3=81=97=E8=A8=B3=E3=81=94=E3=81=96=E3=81=84=E3= =81=BE=E3=81=9B=E3=82=93=E3=81=8C=E3=80=81=E9=80=81=E4=BF=A1=E8=80=85=E3=81= =BE=E3=81=A7=E3=81=8A=E7=9F=A5=E3=82=89=E3=81=9B=E3=81=84=E3=81=9F=E3=81=A0= =E3=81=8D=E3=80=81=E5=8F=97 > =E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E3=83=A1=E3=83=BC=E3=83=AB=E3=82=92= =E5=89=8A=E9=99=A4=E3=81=97=E3=81=A6=E3=81=84=E3=81=9F=E3=81=A0=E3=81=8D=E3= =81=BE=E3=81=99=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E8=87=B4=E3=81= =97=E3=81=BE=E3=81=99=E3=80=82 PLEASE READ: > The information contained in this e-mail is confidential and intended > for the named recipient(s) only. If you are not an intended recipient > of this e-mail, you are hereby notified that any review, dissemination, > distribution or duplication of this message is strictly prohibited. If > you have received this message in error, please notify the sender > immediately and delete your copy from your system. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001a11c11ce016a5820505d4b55b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
1) n.

I vote that we don't want dis= covery at all, as it adds a lot of complexity while yielding little to no b= enefit.=C2=A0

I think we should support 2 transfor= mations, plain (as mandated by the spec), and the best hashing algorithm th= at is commonly available (i.e. SHA256).=C2=A0 If the spec needs to be updat= ed in the future for a newer, better algorithm, a revised version of the sp= ec could be created then.

Due to the short window = of time for code redemption, the hashing algorithm would have to be seri= ously broken to be unusable for spop.

If this = sounds good, I have a some draft wording with the above changes that could = be incorporated.


On Tue, Oct 14, 2014 at 2:19 AM, Nat Sakimura <n-sa= kimura@nri.co.jp> wrote:
In= his mail, Hannes suggested to include more explicit reference to a feature= in the OpenID Connect Discovery spec in section 3.1.

My response to it was that we could define a parameter here
and ask the implementers to implement it. Questions remains whether
we want to define it here or leave it to be out of scope.

So, my questions are:

(1) Do we want it? (y or n)
(2) if y, then adding the following text at the end of 3.1 be adequate?

When the server supports OpenID Connect Discovery 1.0, the server MUST
advertise its capability with a parameter
<spanx style=3D"verb">oauth_spop_supported_alg</spanx>= ;.
The value of it is a JSON array of JSON strings representing
"alg" (Algorithm) Header Parameter Values for JWS as defined in <xref target=3D"JWA">JSON Web Algorithms</xref>.

Nat

On Wed, 3 Sep 2014 02:28:57 +0900
Nat Sakimura <sakimura@gmail.com> wrote:

> Hi. Thanks for the detailed comments.
>
> Here are the responses to the questions raised in [1]
>
> [1]
> http://www.tschofenig.priv.at/oauth/draft-i= etf-oauth-spop-00-hannes.doc
>
> 3.1 [Question: Would it make sense to provide some information also > in the
> > Dynamic Client Registration specification? I am a bit unhappy abo= ut
> > not specifying at least one mechanism for learning this informati= on
> > since it is important for the overall security -- to avoid
> > downgrading attacks.]
>
>
> I would have included it if OAuth has defined a discovery document. n<= br> > fact, it may be a good starting point to discuss whether we should
> have a discovery document for OAuth.
>
> If the client does the per client registration, then it will not be a<= br> > public client so spop would not be needed.
> The clients as a class may register itself, but then each client
> instance would not know if the server knows that it is using spop,
> and assuming it without verifying is not very safe.
>
> 3.1 [Hannes: Can we make a more explicit reference to a feature in the=
> > OpenID Connect Discovery specification?]
>
>
> It will be an extension to section 3 of OpenID Connect Discovery. This=
> specification may define a JSON name for such a parameter. Then, one > can include it in the metadata.
>
> A candidate for such name would be:
>
> oauth_spop_supported_alg:
>
> and the value would be the strings representing supported algorithms.<= br> > It could be drawn from JWA algs.
>
> A simpler alternative would be:
>
> oauth_spop_support:
>
> and the value would be true or false.
>
> However, we have no good place to advertise them as of now.
>
> 3.2 [Hannes: Do we really need this flexibility here?]
>
>
> It is there as an extension point. John has a draft that uses
> aymmetric algo. An early draft had HMAC as well.
>
> We could however drop it. I suppose we can add other algorithms later<= br> > without breaking this one.
>
> [Hannes: The term 'front channel' is not defined anywhere.] >
>
> Will define if this section survives.
>
> 3.7 [Hannes: Why is there a SHOULD rather than a MUST?]
>
>
> The server may have other considerations before returning successful > response.
>
> 5. [Hannes: Which request channel are you talking about? There are two=
> > types of request channels here, namely the Access Token
> > Request/Response and the Authorization Request / Response channel= .
> > What do you mean by adequately protected here? How likely is it > > that this can be accomplished? If it is rather unlikely then it > > would be better to define a different transformation algorithm!]<= br> >
>
> This is referring to the authorization request.
>
> On iOS as of the time of writing, not Jailbreaking seems to be
> adequate. For Android, only presenting the intended browser as the
> options to handle the request seems adequate. Similar considerations > would be there per platform.
>
> Note: Authors do think that using other algorithms is better.
> However, it proved to be rather unpopular among the developers that > they were in touch with and believe that we do need to provide this > "no-transform" capability.
>
> For other "corrections", I am still working on to prepare co= mments as
> word comments.
> Most of editorial changes will be accepted. Some proposed technical > changes seems to be due to the clauses being unclear, so I will try > to propose a clarification rather than just accepting them.
>
> Best,
>
> Nat
>
> 2014-08-29 16:13 GMT+09:00 Hannes Tschofenig
> <hannes.tschofenig@gmx= .net>:
> >
> > Hi John, Hi Nat,
> >
> > I went through the document in detail and suggest some changes > > (most of them editorial):
> > http://www.tschofenig.priv.at/oauth/dr= aft-ietf-oauth-spop-00-hannes.doc
> > http://www.tschofenig.priv.at/oauth/dr= aft-ietf-oauth-spop-00-hannes.pdf
> >
> > My main concern at the moment are some optional features in the s= pec
> > that make it less interoperable, such as the feature discovery, a= nd
> > the transformation function. The latter might go away depending o= n
> > your answer to my question raised at
> > http://www.ietf.org/mail-archive/web/oauth/cu= rrent/msg13354.html
> > but the former requires some specification work.
> >
> > Ciao
> > Hannes
> >
> > PS: I agree with James that the title of the document is a bit > > misleading when compared with the other work we are doing in the<= br> > > group.
> >
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >
>
>
>
> --
> Nat Sakimura (=3Dnat)
> Chairman, OpenID Foundation
> http://nat.saki= mura.org/
> @_nat_en


--
Nat Sakimura (n-sakimura@nri.co.jp<= /a>)
Nomura Research Institute, Ltd.

=E6=9C=AC=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E5=90=AB=E3=81=BE=E3=82=8C=E3= =82=8B=E6=83=85=E5=A0=B1=E3=81=AF=E6=A9=9F=E5=AF=86=E6=83=85=E5=A0=B1=E3=81= =A7=E3=81=82=E3=82=8A=E3=80=81=E5=AE=9B=E5=85=88=E3=81=AB=E8=A8=98=E8=BC=89= =E3=81=95=E3=82=8C=E3=81=A6=E3=81=84=E3=82=8B=E6=96=B9=E3=81=AE=E3=81=BF=E3= =81=AB=E9=80=81=E4=BF=A1
=E3=81=99=E3=82=8B=E3=81=93=E3=81=A8=E3=82=92=E6=84=8F=E5=9B=B3=E3=81=97=E3= =81=A6=E3=81=8A=E3=82=8A=E3=81=BE=E3=81=99=E3=80=82=E6=84=8F=E5=9B=B3=E3=81= =95=E3=82=8C=E3=81=9F=E5=8F=97=E5=8F=96=E4=BA=BA=E4=BB=A5=E5=A4=96=E3=81=AE= =E6=96=B9=E3=81=AB=E3=82=88=E3=82=8B=E3=81=93=E3=82=8C=E3=82=89=E3=81=AE=E6= =83=85=E5=A0=B1=E3=81=AE
=E9=96=8B=E7=A4=BA=E3=80=81=E8=A4=87=E8=A3=BD=E3=80=81=E5=86=8D=E9=85=8D=E5= =B8=83=E3=82=84=E8=BB=A2=E9=80=81=E3=81=AA=E3=81=A9=E4=B8=80=E5=88=87=E3=81= =AE=E5=88=A9=E7=94=A8=E3=81=8C=E7=A6=81=E6=AD=A2=E3=81=95=E3=82=8C=E3=81=A6= =E3=81=84=E3=81=BE=E3=81=99=E3=80=82=E8=AA=A4=E3=81=A3=E3=81=A6=E6=9C=AC=E3= =83=A1=E3=83=BC=E3=83=AB
=E3=82=92=E5=8F=97=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E5=A0=B4=E5=90=88=E3= =81=AF=E3=80=81=E7=94=B3=E3=81=97=E8=A8=B3=E3=81=94=E3=81=96=E3=81=84=E3=81= =BE=E3=81=9B=E3=82=93=E3=81=8C=E3=80=81=E9=80=81=E4=BF=A1=E8=80=85=E3=81=BE= =E3=81=A7=E3=81=8A=E7=9F=A5=E3=82=89=E3=81=9B=E3=81=84=E3=81=9F=E3=81=A0=E3= =81=8D=E3=80=81=E5=8F=97
=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E3=83=A1=E3=83=BC=E3=83=AB=E3=82=92=E5= =89=8A=E9=99=A4=E3=81=97=E3=81=A6=E3=81=84=E3=81=9F=E3=81=A0=E3=81=8D=E3=81= =BE=E3=81=99=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E8=87=B4=E3=81=97= =E3=81=BE=E3=81=99=E3=80=82 PLEASE READ:
The information contained in this e-mail is confidential and intended
for the named recipient(s) only. If you are not an intended recipient
of this e-mail, you are hereby notified that any review, dissemination,
distribution or duplication of this message is strictly prohibited. If
you have received this message in error, please notify the sender
immediately and delete your copy from your system.

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

--001a11c11ce016a5820505d4b55b-- From nobody Sun Oct 19 23:35:00 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 832E21A0378 for ; Sun, 19 Oct 2014 23:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 nN-t5ADUXfCJ for ; Sun, 19 Oct 2014 23:34:55 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDEAD1A6FAE for ; Sun, 19 Oct 2014 23:34:54 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id w7so3212167lbi.8 for ; Sun, 19 Oct 2014 23:34:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=iGtWXbG6IYuwe/Flld5KpIpQ6k43dHAD3I9sEkUT348=; b=yjJoYq9N40gURptR3kDo1EpWw2Qqi4MXFlOyWMUHZJCNbYbc596nFF4nLmNrXspxyx BrVFyVBHbvcJ/J5XhdDp5kn/TJtDIHjzZQCbn4tzVA/3iFgHZhllrYJehd1ZvJekzJ3D Zg2fo0Twa4vuQ0Mft6fHRvW71kMH6Oi+ZXamVZDFNg2Z75uAtzSm1e0fBm0ofKUnCi2c FxPYKqr8+XERW1cmM7Mi85acQfxQLfaMTvSgHmgVo7ueTFdJzwJsCG522HFYc26iezG0 3RXFiMKUQQyiUWivkxe2WHOeJ8k5jjCSwwggAj+ageBM0ErR25/Q2Y2lyje+bwaXi+pK gQWQ== MIME-Version: 1.0 X-Received: by 10.152.116.68 with SMTP id ju4mr25143773lab.13.1413786893027; Sun, 19 Oct 2014 23:34:53 -0700 (PDT) Sender: sakimura@gmail.com Received: by 10.112.166.7 with HTTP; Sun, 19 Oct 2014 23:34:52 -0700 (PDT) In-Reply-To: References: <54002809.2020101@gmx.net> <20141014181931.2011201bddc3f13e114ff42c@nri.co.jp> Date: Mon, 20 Oct 2014 15:34:52 +0900 X-Google-Sender-Auth: 8JQ74g_2q-iwbVdGCv338ZdzFI0 Message-ID: From: Nat Sakimura To: William Denniss Content-Type: multipart/alternative; boundary=001a11c3572a8c0ef00505d4e93b Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/3n44ctykOqZ-1AU7ZcczI_ndUs0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Define a server capaiblity discovery parameter? (was: Re: OAuth SPOP Detailed Review) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 06:34:58 -0000 --001a11c3572a8c0ef00505d4e93b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable That would be great. Actually, several stakeholders informed me that they would like sha256 transformation as well. Either John B. or I was supposed draft it but we have not to the date, so a draft wording would be great. Thanks! 2014-10-20 15:19 GMT+09:00 William Denniss : > 1) n. > > I vote that we don't want discovery at all, as it adds a lot of complexit= y > while yielding little to no benefit. > > I think we should support 2 transformations, plain (as mandated by the > spec), and the best hashing algorithm that is commonly available (i.e. > SHA256). If the spec needs to be updated in the future for a newer, bett= er > algorithm, a revised version of the spec could be created then. > > Due to the short window of time for code redemption, the hashing algorith= m > would have to be *seriously* broken to be unusable for spop. > > If this sounds good, I have a some draft wording with the above changes > that could be incorporated. > > > On Tue, Oct 14, 2014 at 2:19 AM, Nat Sakimura > wrote: > >> In his mail, Hannes suggested to include more explicit reference to a >> feature in the OpenID Connect Discovery spec in section 3.1. >> >> My response to it was that we could define a parameter here >> and ask the implementers to implement it. Questions remains whether >> we want to define it here or leave it to be out of scope. >> >> So, my questions are: >> >> (1) Do we want it? (y or n) >> (2) if y, then adding the following text at the end of 3.1 be adequate? >> >> When the server supports OpenID Connect Discovery 1.0, the server MUST >> advertise its capability with a parameter >> oauth_spop_supported_alg. >> The value of it is a JSON array of JSON strings representing >> "alg" (Algorithm) Header Parameter Values for JWS as defined in >> JSON Web Algorithms. >> >> Nat >> >> On Wed, 3 Sep 2014 02:28:57 +0900 >> Nat Sakimura wrote: >> >> > Hi. Thanks for the detailed comments. >> > >> > Here are the responses to the questions raised in [1] >> > >> > [1] >> > http://www.tschofenig.priv.at/oauth/draft-ietf-oauth-spop-00-hannes.do= c >> > >> > 3.1 [Question: Would it make sense to provide some information also >> > in the >> > > Dynamic Client Registration specification? I am a bit unhappy about >> > > not specifying at least one mechanism for learning this information >> > > since it is important for the overall security -- to avoid >> > > downgrading attacks.] >> > >> > >> > I would have included it if OAuth has defined a discovery document. n >> > fact, it may be a good starting point to discuss whether we should >> > have a discovery document for OAuth. >> > >> > If the client does the per client registration, then it will not be a >> > public client so spop would not be needed. >> > The clients as a class may register itself, but then each client >> > instance would not know if the server knows that it is using spop, >> > and assuming it without verifying is not very safe. >> > >> > 3.1 [Hannes: Can we make a more explicit reference to a feature in the >> > > OpenID Connect Discovery specification?] >> > >> > >> > It will be an extension to section 3 of OpenID Connect Discovery. This >> > specification may define a JSON name for such a parameter. Then, one >> > can include it in the metadata. >> > >> > A candidate for such name would be: >> > >> > oauth_spop_supported_alg: >> > >> > and the value would be the strings representing supported algorithms. >> > It could be drawn from JWA algs. >> > >> > A simpler alternative would be: >> > >> > oauth_spop_support: >> > >> > and the value would be true or false. >> > >> > However, we have no good place to advertise them as of now. >> > >> > 3.2 [Hannes: Do we really need this flexibility here?] >> > >> > >> > It is there as an extension point. John has a draft that uses >> > aymmetric algo. An early draft had HMAC as well. >> > >> > We could however drop it. I suppose we can add other algorithms later >> > without breaking this one. >> > >> > [Hannes: The term 'front channel' is not defined anywhere.] >> > >> > >> > Will define if this section survives. >> > >> > 3.7 [Hannes: Why is there a SHOULD rather than a MUST?] >> > >> > >> > The server may have other considerations before returning successful >> > response. >> > >> > 5. [Hannes: Which request channel are you talking about? There are two >> > > types of request channels here, namely the Access Token >> > > Request/Response and the Authorization Request / Response channel. >> > > What do you mean by adequately protected here? How likely is it >> > > that this can be accomplished? If it is rather unlikely then it >> > > would be better to define a different transformation algorithm!] >> > >> > >> > This is referring to the authorization request. >> > >> > On iOS as of the time of writing, not Jailbreaking seems to be >> > adequate. For Android, only presenting the intended browser as the >> > options to handle the request seems adequate. Similar considerations >> > would be there per platform. >> > >> > Note: Authors do think that using other algorithms is better. >> > However, it proved to be rather unpopular among the developers that >> > they were in touch with and believe that we do need to provide this >> > "no-transform" capability. >> > >> > For other "corrections", I am still working on to prepare comments as >> > word comments. >> > Most of editorial changes will be accepted. Some proposed technical >> > changes seems to be due to the clauses being unclear, so I will try >> > to propose a clarification rather than just accepting them. >> > >> > Best, >> > >> > Nat >> > >> > 2014-08-29 16:13 GMT+09:00 Hannes Tschofenig >> > : >> > > >> > > Hi John, Hi Nat, >> > > >> > > I went through the document in detail and suggest some changes >> > > (most of them editorial): >> > > >> http://www.tschofenig.priv.at/oauth/draft-ietf-oauth-spop-00-hannes.doc >> > > >> http://www.tschofenig.priv.at/oauth/draft-ietf-oauth-spop-00-hannes.pdf >> > > >> > > My main concern at the moment are some optional features in the spec >> > > that make it less interoperable, such as the feature discovery, and >> > > the transformation function. The latter might go away depending on >> > > your answer to my question raised at >> > > http://www.ietf.org/mail-archive/web/oauth/current/msg13354.html >> > > but the former requires some specification work. >> > > >> > > Ciao >> > > Hannes >> > > >> > > PS: I agree with James that the title of the document is a bit >> > > misleading when compared with the other work we are doing in the >> > > group. >> > > >> > > >> > > _______________________________________________ >> > > OAuth mailing list >> > > OAuth@ietf.org >> > > https://www.ietf.org/mailman/listinfo/oauth >> > > >> > >> > >> > >> > -- >> > Nat Sakimura (=3Dnat) >> > Chairman, OpenID Foundation >> > http://nat.sakimura.org/ >> > @_nat_en >> >> >> -- >> Nat Sakimura (n-sakimura@nri.co.jp) >> Nomura Research Institute, Ltd. >> >> =E6=9C=AC=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E5=90=AB=E3=81=BE=E3=82=8C= =E3=82=8B=E6=83=85=E5=A0=B1=E3=81=AF=E6=A9=9F=E5=AF=86=E6=83=85=E5=A0=B1=E3= =81=A7=E3=81=82=E3=82=8A=E3=80=81=E5=AE=9B=E5=85=88=E3=81=AB=E8=A8=98=E8=BC= =89=E3=81=95=E3=82=8C=E3=81=A6=E3=81=84=E3=82=8B=E6=96=B9=E3=81=AE=E3=81=BF= =E3=81=AB=E9=80=81=E4=BF=A1 >> =E3=81=99=E3=82=8B=E3=81=93=E3=81=A8=E3=82=92=E6=84=8F=E5=9B=B3=E3=81=97= =E3=81=A6=E3=81=8A=E3=82=8A=E3=81=BE=E3=81=99=E3=80=82=E6=84=8F=E5=9B=B3=E3= =81=95=E3=82=8C=E3=81=9F=E5=8F=97=E5=8F=96=E4=BA=BA=E4=BB=A5=E5=A4=96=E3=81= =AE=E6=96=B9=E3=81=AB=E3=82=88=E3=82=8B=E3=81=93=E3=82=8C=E3=82=89=E3=81=AE= =E6=83=85=E5=A0=B1=E3=81=AE >> =E9=96=8B=E7=A4=BA=E3=80=81=E8=A4=87=E8=A3=BD=E3=80=81=E5=86=8D=E9=85=8D= =E5=B8=83=E3=82=84=E8=BB=A2=E9=80=81=E3=81=AA=E3=81=A9=E4=B8=80=E5=88=87=E3= =81=AE=E5=88=A9=E7=94=A8=E3=81=8C=E7=A6=81=E6=AD=A2=E3=81=95=E3=82=8C=E3=81= =A6=E3=81=84=E3=81=BE=E3=81=99=E3=80=82=E8=AA=A4=E3=81=A3=E3=81=A6=E6=9C=AC= =E3=83=A1=E3=83=BC=E3=83=AB >> =E3=82=92=E5=8F=97=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E5=A0=B4=E5=90=88= =E3=81=AF=E3=80=81=E7=94=B3=E3=81=97=E8=A8=B3=E3=81=94=E3=81=96=E3=81=84=E3= =81=BE=E3=81=9B=E3=82=93=E3=81=8C=E3=80=81=E9=80=81=E4=BF=A1=E8=80=85=E3=81= =BE=E3=81=A7=E3=81=8A=E7=9F=A5=E3=82=89=E3=81=9B=E3=81=84=E3=81=9F=E3=81=A0= =E3=81=8D=E3=80=81=E5=8F=97 >> =E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E3=83=A1=E3=83=BC=E3=83=AB=E3=82=92= =E5=89=8A=E9=99=A4=E3=81=97=E3=81=A6=E3=81=84=E3=81=9F=E3=81=A0=E3=81=8D=E3= =81=BE=E3=81=99=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E8=87=B4=E3=81= =97=E3=81=BE=E3=81=99=E3=80=82 PLEASE READ: >> The information contained in this e-mail is confidential and intended >> for the named recipient(s) only. If you are not an intended recipient >> of this e-mail, you are hereby notified that any review, dissemination, >> distribution or duplication of this message is strictly prohibited. If >> you have received this message in error, please notify the sender >> immediately and delete your copy from your system. >> >> _______________________________________________ >> 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 Nat Sakimura (=3Dnat) http://www.sakimura.org/en/ http://twitter.com/_nat_en --001a11c3572a8c0ef00505d4e93b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
That would be great.=C2=A0

Actually, se= veral stakeholders informed me that they would like sha256 transformation a= s well.=C2=A0
Either John B. or I was supposed =C2=A0draft it but= we have not to the date, so a draft wording would be great.=C2=A0

Thanks!

2014-10-20 15:19 GMT+09:00 William Denniss <wdenniss@= google.com>:
1) n.

I vote that we don't want discovery at all,= as it adds a lot of complexity while yielding little to no benefit.=C2=A0<= /div>

I think we should support 2 transformations, plain= (as mandated by the spec), and the best hashing algorithm that is commonly= available (i.e. SHA256).=C2=A0 If the spec needs to be updated in the futu= re for a newer, better algorithm, a revised version of the spec could be cr= eated then.

Due to the short window of time for co= de redemption, the hashing algorithm would have to be seriously brok= en to be unusable for spop.

If this sounds good, I= have a some draft wording with the above changes that could be incorporate= d.

On Tue, Oct 14, 2014 at 2:19 AM, Nat Sakimura = <n-sakimura@nri.co.jp> wrote:
In his mail, Hannes suggested to include more explicit reference to = a feature in the OpenID Connect Discovery spec in section 3.1.

My response to it was that we could define a parameter here
and ask the implementers to implement it. Questions remains whether
we want to define it here or leave it to be out of scope.

So, my questions are:

(1) Do we want it? (y or n)
(2) if y, then adding the following text at the end of 3.1 be adequate?

When the server supports OpenID Connect Discovery 1.0, the server MUST
advertise its capability with a parameter
<spanx style=3D"verb">oauth_spop_supported_alg</spanx>= ;.
The value of it is a JSON array of JSON strings representing
"alg" (Algorithm) Header Parameter Values for JWS as defined in <xref target=3D"JWA">JSON Web Algorithms</xref>.

Nat

On Wed, 3 Sep 2014 02:28:57 +0900
Nat Sakimura <sa= kimura@gmail.com> wrote:

> Hi. Thanks for the detailed comments.
>
> Here are the responses to the questions raised in [1]
>
> [1]
> http://www.tschofenig.priv.at/oauth/draft-i= etf-oauth-spop-00-hannes.doc
>
> 3.1 [Question: Would it make sense to provide some information also > in the
> > Dynamic Client Registration specification? I am a bit unhappy abo= ut
> > not specifying at least one mechanism for learning this informati= on
> > since it is important for the overall security -- to avoid
> > downgrading attacks.]
>
>
> I would have included it if OAuth has defined a discovery document. n<= br> > fact, it may be a good starting point to discuss whether we should
> have a discovery document for OAuth.
>
> If the client does the per client registration, then it will not be a<= br> > public client so spop would not be needed.
> The clients as a class may register itself, but then each client
> instance would not know if the server knows that it is using spop,
> and assuming it without verifying is not very safe.
>
> 3.1 [Hannes: Can we make a more explicit reference to a feature in the=
> > OpenID Connect Discovery specification?]
>
>
> It will be an extension to section 3 of OpenID Connect Discovery. This=
> specification may define a JSON name for such a parameter. Then, one > can include it in the metadata.
>
> A candidate for such name would be:
>
> oauth_spop_supported_alg:
>
> and the value would be the strings representing supported algorithms.<= br> > It could be drawn from JWA algs.
>
> A simpler alternative would be:
>
> oauth_spop_support:
>
> and the value would be true or false.
>
> However, we have no good place to advertise them as of now.
>
> 3.2 [Hannes: Do we really need this flexibility here?]
>
>
> It is there as an extension point. John has a draft that uses
> aymmetric algo. An early draft had HMAC as well.
>
> We could however drop it. I suppose we can add other algorithms later<= br> > without breaking this one.
>
> [Hannes: The term 'front channel' is not defined anywhere.] >
>
> Will define if this section survives.
>
> 3.7 [Hannes: Why is there a SHOULD rather than a MUST?]
>
>
> The server may have other considerations before returning successful > response.
>
> 5. [Hannes: Which request channel are you talking about? There are two=
> > types of request channels here, namely the Access Token
> > Request/Response and the Authorization Request / Response channel= .
> > What do you mean by adequately protected here? How likely is it > > that this can be accomplished? If it is rather unlikely then it > > would be better to define a different transformation algorithm!]<= br> >
>
> This is referring to the authorization request.
>
> On iOS as of the time of writing, not Jailbreaking seems to be
> adequate. For Android, only presenting the intended browser as the
> options to handle the request seems adequate. Similar considerations > would be there per platform.
>
> Note: Authors do think that using other algorithms is better.
> However, it proved to be rather unpopular among the developers that > they were in touch with and believe that we do need to provide this > "no-transform" capability.
>
> For other "corrections", I am still working on to prepare co= mments as
> word comments.
> Most of editorial changes will be accepted. Some proposed technical > changes seems to be due to the clauses being unclear, so I will try > to propose a clarification rather than just accepting them.
>
> Best,
>
> Nat
>
> 2014-08-29 16:13 GMT+09:00 Hannes Tschofenig
> <han= nes.tschofenig@gmx.net>:
> >
> > Hi John, Hi Nat,
> >
> > I went through the document in detail and suggest some changes > > (most of them editorial):
> > http://www.tschofenig.priv.at/oauth/dr= aft-ietf-oauth-spop-00-hannes.doc
> > http://www.tschofenig.priv.at/oauth/dr= aft-ietf-oauth-spop-00-hannes.pdf
> >
> > My main concern at the moment are some optional features in the s= pec
> > that make it less interoperable, such as the feature discovery, a= nd
> > the transformation function. The latter might go away depending o= n
> > your answer to my question raised at
> > http://www.ietf.org/mail-archive/web/oauth/cu= rrent/msg13354.html
> > but the former requires some specification work.
> >
> > Ciao
> > Hannes
> >
> > PS: I agree with James that the title of the document is a bit > > misleading when compared with the other work we are doing in the<= br> > > group.
> >
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.or= g
> > https://www.ietf.org/mailman/listinfo/oauth
> >
>
>
>
> --
> Nat Sakimura (=3Dnat)
> Chairman, OpenID Foundation
> http://nat.saki= mura.org/
> @_nat_en


--
Nat Sakimura (n-s= akimura@nri.co.jp)
Nomura Research Institute, Ltd.

=E6=9C=AC=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E5=90=AB=E3=81=BE=E3=82=8C=E3= =82=8B=E6=83=85=E5=A0=B1=E3=81=AF=E6=A9=9F=E5=AF=86=E6=83=85=E5=A0=B1=E3=81= =A7=E3=81=82=E3=82=8A=E3=80=81=E5=AE=9B=E5=85=88=E3=81=AB=E8=A8=98=E8=BC=89= =E3=81=95=E3=82=8C=E3=81=A6=E3=81=84=E3=82=8B=E6=96=B9=E3=81=AE=E3=81=BF=E3= =81=AB=E9=80=81=E4=BF=A1
=E3=81=99=E3=82=8B=E3=81=93=E3=81=A8=E3=82=92=E6=84=8F=E5=9B=B3=E3=81=97=E3= =81=A6=E3=81=8A=E3=82=8A=E3=81=BE=E3=81=99=E3=80=82=E6=84=8F=E5=9B=B3=E3=81= =95=E3=82=8C=E3=81=9F=E5=8F=97=E5=8F=96=E4=BA=BA=E4=BB=A5=E5=A4=96=E3=81=AE= =E6=96=B9=E3=81=AB=E3=82=88=E3=82=8B=E3=81=93=E3=82=8C=E3=82=89=E3=81=AE=E6= =83=85=E5=A0=B1=E3=81=AE
=E9=96=8B=E7=A4=BA=E3=80=81=E8=A4=87=E8=A3=BD=E3=80=81=E5=86=8D=E9=85=8D=E5= =B8=83=E3=82=84=E8=BB=A2=E9=80=81=E3=81=AA=E3=81=A9=E4=B8=80=E5=88=87=E3=81= =AE=E5=88=A9=E7=94=A8=E3=81=8C=E7=A6=81=E6=AD=A2=E3=81=95=E3=82=8C=E3=81=A6= =E3=81=84=E3=81=BE=E3=81=99=E3=80=82=E8=AA=A4=E3=81=A3=E3=81=A6=E6=9C=AC=E3= =83=A1=E3=83=BC=E3=83=AB
=E3=82=92=E5=8F=97=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E5=A0=B4=E5=90=88=E3= =81=AF=E3=80=81=E7=94=B3=E3=81=97=E8=A8=B3=E3=81=94=E3=81=96=E3=81=84=E3=81= =BE=E3=81=9B=E3=82=93=E3=81=8C=E3=80=81=E9=80=81=E4=BF=A1=E8=80=85=E3=81=BE= =E3=81=A7=E3=81=8A=E7=9F=A5=E3=82=89=E3=81=9B=E3=81=84=E3=81=9F=E3=81=A0=E3= =81=8D=E3=80=81=E5=8F=97
=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E3=83=A1=E3=83=BC=E3=83=AB=E3=82=92=E5= =89=8A=E9=99=A4=E3=81=97=E3=81=A6=E3=81=84=E3=81=9F=E3=81=A0=E3=81=8D=E3=81= =BE=E3=81=99=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E8=87=B4=E3=81=97= =E3=81=BE=E3=81=99=E3=80=82 PLEASE READ:
The information contained in this e-mail is confidential and intended
for the named recipient(s) only. If you are not an intended recipient
of this e-mail, you are hereby notified that any review, dissemination,
distribution or duplication of this message is strictly prohibited. If
you have received this message in error, please notify the sender
immediately and delete your copy from your system.

_______________________________________________
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




--
Nat Saki= mura (=3Dnat)
= http://www.sakimura.org/en/
http://twitter.com/_nat_en
--001a11c3572a8c0ef00505d4e93b-- From nobody Mon Oct 20 04:03:18 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1791A8028 for ; Mon, 20 Oct 2014 04:03:15 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cuTGOLX2trVs for ; Mon, 20 Oct 2014 04:03:11 -0700 (PDT) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 310321A19FB for ; Mon, 20 Oct 2014 04:03:10 -0700 (PDT) Received: by mail-qa0-f42.google.com with SMTP id j7so3167231qaq.1 for ; Mon, 20 Oct 2014 04:03:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=VVS76zIoLMHXPU42Gl/lnIwz2U6Q3SIzOum1N1KWDRg=; b=KVFTfoHMvv0iCTRjj50XiFK3Ysj8IxPKVzcD8ZhRXH8j/9DMb24lDCmLBLAkjQ+G0Z G/hei4AF9sOPHb+cuymBJ4vcTQ1BZ6Ic9j+0PvHcLq2kKLgs0Trcz9E+w5rEos7rdXT/ YEBYnpKeeKLJH9jkn+8KkHaHtKsdkU8QyXAPF64xo7XUFqxbdcBhxmegNTcexyiGLTJK 3FJm8e1F0W+phB2y/UwbIpA35uOSm7jcIJ/G7viyTuezSWKWUzB3PldUaYt3xUzhUy6e an+LXqlT8unzA7WXG7+bZYKsYjNzcDTTpQSRxnCsk9TVIGYSiCvlFOdGHBOacRkUkmWH j7TQ== X-Gm-Message-State: ALoCoQnLRvsVWViyuJf1YI8DDwd7O23JBLr8SuKfNmgSPipUAEubdAt4P66UoYoOAhjNm4/sls7Z X-Received: by 10.140.86.135 with SMTP id p7mr33473253qgd.54.1413802990043; Mon, 20 Oct 2014 04:03:10 -0700 (PDT) Received: from [192.168.1.36] (186-79-105-47.baf.movistar.cl. [186.79.105.47]) by mx.google.com with ESMTPSA id g94sm7606782qgd.0.2014.10.20.04.03.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 20 Oct 2014 04:03:09 -0700 (PDT) References: <54002809.2020101@gmx.net> <20141014181931.2011201bddc3f13e114ff42c@nri.co.jp> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-FEC7D006-B48E-487C-84AC-5D076D8E7FAD; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: <3750B78B-23D0-4C2B-88C9-D649E45C6FB3@ve7jtb.com> X-Mailer: iPhone Mail (12A405) From: John Bradley Date: Mon, 20 Oct 2014 08:03:04 -0300 To: Nat Sakimura Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/SVwdRT4agC8z5vyfF42jaJRnbEo Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Define a server capaiblity discovery parameter? (was: Re: OAuth SPOP Detailed Review) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 11:03:15 -0000 --Apple-Mail-FEC7D006-B48E-487C-84AC-5D076D8E7FAD Content-Type: multipart/alternative; boundary=Apple-Mail-250D7857-BF11-4416-A5B4-73FA732DE11D Content-Transfer-Encoding: 7bit --Apple-Mail-250D7857-BF11-4416-A5B4-73FA732DE11D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I started to draft the change. If you send me what you have I will incorpor= ate it.=20 Sent from my iPhone > On Oct 20, 2014, at 3:34 AM, Nat Sakimura wrote: >=20 > That would be great.=20 >=20 > Actually, several stakeholders informed me that they would like sha256 tra= nsformation as well.=20 > Either John B. or I was supposed draft it but we have not to the date, so= a draft wording would be great.=20 >=20 > Thanks! >=20 > 2014-10-20 15:19 GMT+09:00 William Denniss : >> 1) n. >>=20 >> I vote that we don't want discovery at all, as it adds a lot of complexit= y while yielding little to no benefit.=20 >>=20 >> I think we should support 2 transformations, plain (as mandated by the sp= ec), and the best hashing algorithm that is commonly available (i.e. SHA256)= . If the spec needs to be updated in the future for a newer, better algorit= hm, a revised version of the spec could be created then. >>=20 >> Due to the short window of time for code redemption, the hashing algorith= m would have to be seriously broken to be unusable for spop. >>=20 >> If this sounds good, I have a some draft wording with the above changes t= hat could be incorporated. >>=20 >>=20 >>> On Tue, Oct 14, 2014 at 2:19 AM, Nat Sakimura wro= te: >>> In his mail, Hannes suggested to include more explicit reference to a fe= ature in the OpenID Connect Discovery spec in section 3.1. >>>=20 >>> My response to it was that we could define a parameter here >>> and ask the implementers to implement it. Questions remains whether >>> we want to define it here or leave it to be out of scope. >>>=20 >>> So, my questions are: >>>=20 >>> (1) Do we want it? (y or n) >>> (2) if y, then adding the following text at the end of 3.1 be adequate? >>>=20 >>> When the server supports OpenID Connect Discovery 1.0, the server MUST >>> advertise its capability with a parameter >>> oauth_spop_supported_alg. >>> The value of it is a JSON array of JSON strings representing >>> "alg" (Algorithm) Header Parameter Values for JWS as defined in >>> JSON Web Algorithms. >>>=20 >>> Nat >>>=20 >>> On Wed, 3 Sep 2014 02:28:57 +0900 >>> Nat Sakimura wrote: >>>=20 >>> > Hi. Thanks for the detailed comments. >>> > >>> > Here are the responses to the questions raised in [1] >>> > >>> > [1] >>> > http://www.tschofenig.priv.at/oauth/draft-ietf-oauth-spop-00-hannes.do= c >>> > >>> > 3.1 [Question: Would it make sense to provide some information also >>> > in the >>> > > Dynamic Client Registration specification? I am a bit unhappy about >>> > > not specifying at least one mechanism for learning this information >>> > > since it is important for the overall security -- to avoid >>> > > downgrading attacks.] >>> > >>> > >>> > I would have included it if OAuth has defined a discovery document. n >>> > fact, it may be a good starting point to discuss whether we should >>> > have a discovery document for OAuth. >>> > >>> > If the client does the per client registration, then it will not be a >>> > public client so spop would not be needed. >>> > The clients as a class may register itself, but then each client >>> > instance would not know if the server knows that it is using spop, >>> > and assuming it without verifying is not very safe. >>> > >>> > 3.1 [Hannes: Can we make a more explicit reference to a feature in the= >>> > > OpenID Connect Discovery specification?] >>> > >>> > >>> > It will be an extension to section 3 of OpenID Connect Discovery. This= >>> > specification may define a JSON name for such a parameter. Then, one >>> > can include it in the metadata. >>> > >>> > A candidate for such name would be: >>> > >>> > oauth_spop_supported_alg: >>> > >>> > and the value would be the strings representing supported algorithms. >>> > It could be drawn from JWA algs. >>> > >>> > A simpler alternative would be: >>> > >>> > oauth_spop_support: >>> > >>> > and the value would be true or false. >>> > >>> > However, we have no good place to advertise them as of now. >>> > >>> > 3.2 [Hannes: Do we really need this flexibility here?] >>> > >>> > >>> > It is there as an extension point. John has a draft that uses >>> > aymmetric algo. An early draft had HMAC as well. >>> > >>> > We could however drop it. I suppose we can add other algorithms later >>> > without breaking this one. >>> > >>> > [Hannes: The term 'front channel' is not defined anywhere.] >>> > >>> > >>> > Will define if this section survives. >>> > >>> > 3.7 [Hannes: Why is there a SHOULD rather than a MUST?] >>> > >>> > >>> > The server may have other considerations before returning successful >>> > response. >>> > >>> > 5. [Hannes: Which request channel are you talking about? There are two= >>> > > types of request channels here, namely the Access Token >>> > > Request/Response and the Authorization Request / Response channel. >>> > > What do you mean by adequately protected here? How likely is it >>> > > that this can be accomplished? If it is rather unlikely then it >>> > > would be better to define a different transformation algorithm!] >>> > >>> > >>> > This is referring to the authorization request. >>> > >>> > On iOS as of the time of writing, not Jailbreaking seems to be >>> > adequate. For Android, only presenting the intended browser as the >>> > options to handle the request seems adequate. Similar considerations >>> > would be there per platform. >>> > >>> > Note: Authors do think that using other algorithms is better. >>> > However, it proved to be rather unpopular among the developers that >>> > they were in touch with and believe that we do need to provide this >>> > "no-transform" capability. >>> > >>> > For other "corrections", I am still working on to prepare comments as >>> > word comments. >>> > Most of editorial changes will be accepted. Some proposed technical >>> > changes seems to be due to the clauses being unclear, so I will try >>> > to propose a clarification rather than just accepting them. >>> > >>> > Best, >>> > >>> > Nat >>> > >>> > 2014-08-29 16:13 GMT+09:00 Hannes Tschofenig >>> > : >>> > > >>> > > Hi John, Hi Nat, >>> > > >>> > > I went through the document in detail and suggest some changes >>> > > (most of them editorial): >>> > > http://www.tschofenig.priv.at/oauth/draft-ietf-oauth-spop-00-hannes.= doc >>> > > http://www.tschofenig.priv.at/oauth/draft-ietf-oauth-spop-00-hannes.= pdf >>> > > >>> > > My main concern at the moment are some optional features in the spec= >>> > > that make it less interoperable, such as the feature discovery, and >>> > > the transformation function. The latter might go away depending on >>> > > your answer to my question raised at >>> > > http://www.ietf.org/mail-archive/web/oauth/current/msg13354.html >>> > > but the former requires some specification work. >>> > > >>> > > Ciao >>> > > Hannes >>> > > >>> > > PS: I agree with James that the title of the document is a bit >>> > > misleading when compared with the other work we are doing in the >>> > > group. >>> > > >>> > > >>> > > _______________________________________________ >>> > > OAuth mailing list >>> > > OAuth@ietf.org >>> > > https://www.ietf.org/mailman/listinfo/oauth >>> > > >>> > >>> > >>> > >>> > -- >>> > Nat Sakimura (=3Dnat) >>> > Chairman, OpenID Foundation >>> > http://nat.sakimura.org/ >>> > @_nat_en >>>=20 >>>=20 >>> -- >>> Nat Sakimura (n-sakimura@nri.co.jp) >>> Nomura Research Institute, Ltd. >>>=20 >>> =E6=9C=AC=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E5=90=AB=E3=81=BE=E3=82=8C= =E3=82=8B=E6=83=85=E5=A0=B1=E3=81=AF=E6=A9=9F=E5=AF=86=E6=83=85=E5=A0=B1=E3=81= =A7=E3=81=82=E3=82=8A=E3=80=81=E5=AE=9B=E5=85=88=E3=81=AB=E8=A8=98=E8=BC=89=E3= =81=95=E3=82=8C=E3=81=A6=E3=81=84=E3=82=8B=E6=96=B9=E3=81=AE=E3=81=BF=E3=81=AB= =E9=80=81=E4=BF=A1 >>> =E3=81=99=E3=82=8B=E3=81=93=E3=81=A8=E3=82=92=E6=84=8F=E5=9B=B3=E3=81=97= =E3=81=A6=E3=81=8A=E3=82=8A=E3=81=BE=E3=81=99=E3=80=82=E6=84=8F=E5=9B=B3=E3=81= =95=E3=82=8C=E3=81=9F=E5=8F=97=E5=8F=96=E4=BA=BA=E4=BB=A5=E5=A4=96=E3=81=AE=E6= =96=B9=E3=81=AB=E3=82=88=E3=82=8B=E3=81=93=E3=82=8C=E3=82=89=E3=81=AE=E6=83=85= =E5=A0=B1=E3=81=AE >>> =E9=96=8B=E7=A4=BA=E3=80=81=E8=A4=87=E8=A3=BD=E3=80=81=E5=86=8D=E9=85=8D= =E5=B8=83=E3=82=84=E8=BB=A2=E9=80=81=E3=81=AA=E3=81=A9=E4=B8=80=E5=88=87=E3=81= =AE=E5=88=A9=E7=94=A8=E3=81=8C=E7=A6=81=E6=AD=A2=E3=81=95=E3=82=8C=E3=81=A6=E3= =81=84=E3=81=BE=E3=81=99=E3=80=82=E8=AA=A4=E3=81=A3=E3=81=A6=E6=9C=AC=E3=83=A1= =E3=83=BC=E3=83=AB >>> =E3=82=92=E5=8F=97=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E5=A0=B4=E5=90=88= =E3=81=AF=E3=80=81=E7=94=B3=E3=81=97=E8=A8=B3=E3=81=94=E3=81=96=E3=81=84=E3=81= =BE=E3=81=9B=E3=82=93=E3=81=8C=E3=80=81=E9=80=81=E4=BF=A1=E8=80=85=E3=81=BE=E3= =81=A7=E3=81=8A=E7=9F=A5=E3=82=89=E3=81=9B=E3=81=84=E3=81=9F=E3=81=A0=E3=81=8D= =E3=80=81=E5=8F=97 >>> =E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E3=83=A1=E3=83=BC=E3=83=AB=E3=82=92= =E5=89=8A=E9=99=A4=E3=81=97=E3=81=A6=E3=81=84=E3=81=9F=E3=81=A0=E3=81=8D=E3=81= =BE=E3=81=99=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E8=87=B4=E3=81=97=E3= =81=BE=E3=81=99=E3=80=82 PLEASE READ: >>> The information contained in this e-mail is confidential and intended >>> for the named recipient(s) only. If you are not an intended recipient >>> of this e-mail, you are hereby notified that any review, dissemination, >>> distribution or duplication of this message is strictly prohibited. If >>> you have received this message in error, please notify the sender >>> immediately and delete your copy from your system. >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 > --=20 > Nat Sakimura (=3Dnat) > http://www.sakimura.org/en/ > http://twitter.com/_nat_en > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-250D7857-BF11-4416-A5B4-73FA732DE11D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I started to draft the change.  I= f you send me what you have I will incorporate it. 



Sent from my iPhone

On Oct 20, 2014, at 3:34 AM,= Nat Sakimura <n-sakimura@nri.co.= jp> wrote:

That would be great. 

Actually, several stakehold= ers informed me that they would like sha256 transformation as well. 
Either John B. or I was supposed  draft it but we have not to t= he date, so a draft wording would be great. 

T= hanks!

= 2014-10-20 15:19 GMT+09:00 William Denniss <wdenniss@google.com>:
1) n.

=
I vote that we don't want discovery at all, as it adds a lot of complex= ity while yielding little to no benefit. 

I th= ink we should support 2 transformations, plain (as mandated by the spec), an= d the best hashing algorithm that is commonly available (i.e. SHA256). = If the spec needs to be updated in the future for a newer, better algorithm= , a revised version of the spec could be created then.

<= div>Due to the short window of time for code redemption, the hashing algorit= hm would have to be seriously broken to be unusable for spop.

If this sounds good, I have a some draft wording with the a= bove changes that could be incorporated.

On Tue, Oc= t 14, 2014 at 2:19 AM, Nat Sakimura <n-sakimura@nri.co.jp> w= rote:
In his mail, Hannes suggested to incl= ude more explicit reference to a feature in the OpenID Connect Discovery spe= c in section 3.1.

My response to it was that we could define a parameter here
and ask the implementers to implement it. Questions remains whether
we want to define it here or leave it to be out of scope.

So, my questions are:

(1) Do we want it? (y or n)
(2) if y, then adding the following text at the end of 3.1 be adequate?

When the server supports OpenID Connect Discovery 1.0, the server MUST
advertise its capability with a parameter
<spanx style=3D"verb">oauth_spop_supported_alg</spanx>.
The value of it is a JSON array of JSON strings representing
"alg" (Algorithm) Header Parameter Values for JWS as defined in
<xref target=3D"JWA">JSON Web Algorithms</xref>.

Nat

On Wed, 3 Sep 2014 02:28:57 +0900
Nat Sakimura <sak= imura@gmail.com> wrote:

> Hi. Thanks for the detailed comments.
>
> Here are the responses to the questions raised in [1]
>
> [1]
> http://www.tschofenig.priv.at/oauth/draft-iet= f-oauth-spop-00-hannes.doc
>
> 3.1 [Question: Would it make sense to provide some information also
= > in the
> > Dynamic Client Registration specification? I am a bit unhappy abou= t
> > not specifying at least one mechanism for learning this informatio= n
> > since it is important for the overall security -- to avoid
> > downgrading attacks.]
>
>
> I would have included it if OAuth has defined a discovery document. n > fact, it may be a good starting point to discuss whether we should
> have a discovery document for OAuth.
>
> If the client does the per client registration, then it will not be a > public client so spop would not be needed.
> The clients as a class may register itself, but then each client
> instance would not know if the server knows that it is using spop,
> and assuming it without verifying is not very safe.
>
> 3.1 [Hannes: Can we make a more explicit reference to a feature in the<= br> > > OpenID Connect Discovery specification?]
>
>
> It will be an extension to section 3 of OpenID Connect Discovery. This<= br> > specification may define a JSON name for such a parameter. Then, one > can include it in the metadata.
>
> A candidate for such name would be:
>
> oauth_spop_supported_alg:
>
> and the value would be the strings representing supported algorithms. > It could be drawn from JWA algs.
>
> A simpler alternative would be:
>
> oauth_spop_support:
>
> and the value would be true or false.
>
> However, we have no good place to advertise them as of now.
>
> 3.2 [Hannes: Do we really need this flexibility here?]
>
>
> It is there as an extension point. John has a draft that uses
> aymmetric algo. An early draft had HMAC as well.
>
> We could however drop it. I suppose we can add other algorithms later > without breaking this one.
>
> [Hannes: The term 'front channel' is not defined anywhere.]
>
>
> Will define if this section survives.
>
> 3.7 [Hannes: Why is there a SHOULD rather than a MUST?]
>
>
> The server may have other considerations before returning successful > response.
>
> 5. [Hannes: Which request channel are you talking about? There are two<= br> > > types of request channels here, namely the Access Token
> > Request/Response and the Authorization Request / Response channel.=
> > What do you mean by adequately protected here? How likely is it > > that this can be accomplished? If it is rather unlikely then it > > would be better to define a different transformation algorithm!] >
>
> This is referring to the authorization request.
>
> On iOS as of the time of writing, not Jailbreaking seems to be
> adequate. For Android, only presenting the intended browser as the
> options to handle the request seems adequate. Similar considerations > would be there per platform.
>
> Note: Authors do think that using other algorithms is better.
> However, it proved to be rather unpopular among the developers that
= > they were in touch with and believe that we do need to provide this
= > "no-transform" capability.
>
> For other "corrections", I am still working on to prepare comments as > word comments.
> Most of editorial changes will be accepted. Some proposed technical
= > changes seems to be due to the clauses being unclear, so I will try
= > to propose a clarification rather than just accepting them.
>
> Best,
>
> Nat
>
> 2014-08-29 16:13 GMT+09:00 Hannes Tschofenig
> <hann= es.tschofenig@gmx.net>:
> >
> > Hi John, Hi Nat,
> >
> > I went through the document in detail and suggest some changes
= > > (most of them editorial):
> > http://www.tschofenig.priv.at/oauth/draf= t-ietf-oauth-spop-00-hannes.doc
> > http://www.tschofenig.priv.at/oauth/draf= t-ietf-oauth-spop-00-hannes.pdf
> >
> > My main concern at the moment are some optional features in the sp= ec
> > that make it less interoperable, such as the feature discovery, an= d
> > the transformation function. The latter might go away depending on=
> > your answer to my question raised at
> > http://www.ietf.org/mail-archive/web/oauth/curr= ent/msg13354.html
> > but the former requires some specification work.
> >
> > Ciao
> > Hannes
> >
> > PS: I agree with James that the title of the document is a bit
= > > misleading when compared with the other work we are doing in the > > group.
> >
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org=
> > https://www.ietf.org/mailman/listinfo/oauth
> >
>
>
>
> --
> Nat Sakimura (=3Dnat)
> Chairman, OpenID Foundation
> http://nat.sakim= ura.org/
> @_nat_en


--
Nat Sakimura (n-sa= kimura@nri.co.jp)
Nomura Research Institute, Ltd.

=E6=9C=AC=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E5=90=AB=E3=81=BE=E3=82=8C=E3=82= =8B=E6=83=85=E5=A0=B1=E3=81=AF=E6=A9=9F=E5=AF=86=E6=83=85=E5=A0=B1=E3=81=A7=E3= =81=82=E3=82=8A=E3=80=81=E5=AE=9B=E5=85=88=E3=81=AB=E8=A8=98=E8=BC=89=E3=81=95= =E3=82=8C=E3=81=A6=E3=81=84=E3=82=8B=E6=96=B9=E3=81=AE=E3=81=BF=E3=81=AB=E9=80= =81=E4=BF=A1
=E3=81=99=E3=82=8B=E3=81=93=E3=81=A8=E3=82=92=E6=84=8F=E5=9B=B3=E3=81=97=E3=81= =A6=E3=81=8A=E3=82=8A=E3=81=BE=E3=81=99=E3=80=82=E6=84=8F=E5=9B=B3=E3=81=95=E3= =82=8C=E3=81=9F=E5=8F=97=E5=8F=96=E4=BA=BA=E4=BB=A5=E5=A4=96=E3=81=AE=E6=96=B9= =E3=81=AB=E3=82=88=E3=82=8B=E3=81=93=E3=82=8C=E3=82=89=E3=81=AE=E6=83=85=E5=A0= =B1=E3=81=AE
=E9=96=8B=E7=A4=BA=E3=80=81=E8=A4=87=E8=A3=BD=E3=80=81=E5=86=8D=E9=85=8D=E5=B8= =83=E3=82=84=E8=BB=A2=E9=80=81=E3=81=AA=E3=81=A9=E4=B8=80=E5=88=87=E3=81=AE=E5= =88=A9=E7=94=A8=E3=81=8C=E7=A6=81=E6=AD=A2=E3=81=95=E3=82=8C=E3=81=A6=E3=81=84= =E3=81=BE=E3=81=99=E3=80=82=E8=AA=A4=E3=81=A3=E3=81=A6=E6=9C=AC=E3=83=A1=E3=83= =BC=E3=83=AB
=E3=82=92=E5=8F=97=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E5=A0=B4=E5=90=88=E3=81= =AF=E3=80=81=E7=94=B3=E3=81=97=E8=A8=B3=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3= =81=9B=E3=82=93=E3=81=8C=E3=80=81=E9=80=81=E4=BF=A1=E8=80=85=E3=81=BE=E3=81=A7= =E3=81=8A=E7=9F=A5=E3=82=89=E3=81=9B=E3=81=84=E3=81=9F=E3=81=A0=E3=81=8D=E3=80= =81=E5=8F=97
=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E3=83=A1=E3=83=BC=E3=83=AB=E3=82=92=E5=89= =8A=E9=99=A4=E3=81=97=E3=81=A6=E3=81=84=E3=81=9F=E3=81=A0=E3=81=8D=E3=81=BE=E3= =81=99=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E8=87=B4=E3=81=97=E3=81=BE= =E3=81=99=E3=80=82 PLEASE READ:
The information contained in this e-mail is confidential and intended
for the named recipient(s) only. If you are not an intended recipient
of this e-mail, you are hereby notified that any review, dissemination,
distribution or duplication of this message is strictly prohibited. If
you have received this message in error, please notify the sender
immediately and delete your copy from your system.

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


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




--
Nat Sakim= ura (=3Dnat)
ht= tp://www.sakimura.org/en/
http://twitter.com/_nat_en
____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-250D7857-BF11-4416-A5B4-73FA732DE11D-- --Apple-Mail-FEC7D006-B48E-487C-84AC-5D076D8E7FAD Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHBDCCBwAw ggXooAMCAQICAkgHMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTQwMzI0MjM1NjIzWhcNMTYwMzI1MDkzOTMxWjCBnzEZMBcGA1UEDRMQcXpGMDFYWUNaTUwz ODdoRDELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEiMCAGCSqGSIb3DQEJ ARYTamJyYWRsZXlAaWNsb3VkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALUy 9KOEBlgvo55mGu8RI3AUwHiDreyC8uNKrJyRzXnVWkx9BFOch86GhDhh7jrsCVM/wu69k716Sf1H eMOlTh3TlBp5ylIh+TFf5CMrGew6TeQ9X/shGrLdNKCrBG3/w+n5c33sdiRVfa0+wEPhUGk3X90v Su4DNheZDgxYPNOQTGExk/oWsPVTjF47ubPd1RI1EHJxqy8tEbaDe+hjOiLcajZxLfy5/thjavCb z8lCnibAMXyJU8qiG8N9lZbrCly+Po5oBYvi2Om7H4N1Ry78ufELEJwsB4NebgEb8uV+qMMhnBu8 R8DZpXzVrQWdwxzT4d+xwvZZgMuIqsOD7zcCAwEAAaOCA1UwggNRMAkGA1UdEwQCMAAwCwYDVR0P BAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUlA2+gZSQ+xSG IFo9cOM/hrDl7O8wHwYDVR0jBBgwFoAUrlWDb+wxyrn3HfqvazHzyB3jrLswgZkGA1UdEQSBkTCB joETamJyYWRsZXlAaWNsb3VkLmNvbYETamJyYWRsZXlAaWNsb3VkLmNvbYEXam9obi5icmFkbGV5 QHdpbmdhYS5jb22BEXZlN2p0YkB2ZTdqdGIuY29tgQ9qYnJhZGxleUBtZS5jb22BEGpicmFkbGV5 QG1hYy5jb22BE2picmFkbGV5QHdpbmdhYS5jb20wggFMBgNVHSAEggFDMIIBPzCCATsGCysGAQQB gbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBk ZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIB ARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhlIENsYXNzIDIg VmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFu Y2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVs eWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy dHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZo dHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5jcnQwIwYD VR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQC7HBJX W64HhQdVgv4THWMRU+C3PAC7RK4Ca8kaM03XjJc6bJ3CCssvDOeB4cUADDqhXth0fkfR+1niM5pF feciZyWN23eG8Z53poS6w8otVZTYxI5CuZIHoCPCWr2oRV5eBcCRx7/Ezoe9Vn934stA6O3e00Jl Q0a87dZP9sOAlysHkNpnRcO37JImKDxhCu6RYonBjBQcy4ikZutQqqI0uCGEoYj9JwmWVj8DSWLO ZbLcQ0kjGg/inHGVcZC+19kI/TyfjwgEOnTIb8E163XJ6xO3yPD4Rbx1qxEY4O8iLtViOBYL4stL u+N+71s7n0p36jMG389tH7nDtHIWKvrZMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQICSAcwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTQxMDIwMTEwMzA0WjAjBgkqhkiG9w0BCQQxFgQUMQHaTgVTdUeDGhjM SWs17sJKXMowgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB AgJIBzCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgw NgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIC SAcwDQYJKoZIhvcNAQEBBQAEggEAXmcu62o9Ct2Fjhrqm/Q5Q7mS/HLalcqEm8zpILpEULQm6pkN kUlV87SHrLq7AxAvzQvZBxRh2vOzadbzUNTG3975IsNaEpc+IKNgqPoDknpdgB2+5+1+1sRsClMf H4ZvgXzD9jZgLz63B3IAOxceOW6/qEiyIK0PpgoniQZgCSyG30jBTHU/jg/hPS1yXrQl4vn5wVp4 8bHwSlbdJhde+6m6yPmHnm3PmVhHz0LW81eRxficEm54rCHCjaGBEvYYAiRuDPnfEJGPQUKFVoda tEXs0ZRjVbw5IqVJQICtYRPvFCN75lpfp1yIx6ADoXFe46XJdX7zJ7qlc7FCYHHomAAAAAAAAA== --Apple-Mail-FEC7D006-B48E-487C-84AC-5D076D8E7FAD-- From nobody Mon Oct 20 08:46:48 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B6781A1B4B; Mon, 20 Oct 2014 08:46:45 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4fz25eOCScj; Mon, 20 Oct 2014 08:46:41 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0747.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:747]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2E901A1B0F; Mon, 20 Oct 2014 08:45:18 -0700 (PDT) Received: from BY2PR03CA005.namprd03.prod.outlook.com (10.255.93.22) by CY1PR0301MB1212.namprd03.prod.outlook.com (25.161.212.146) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Mon, 20 Oct 2014 15:44:56 +0000 Received: from BN1AFFO11FD030.protection.gbl (10.255.93.4) by BY2PR03CA005.outlook.office365.com (10.255.93.22) with Microsoft SMTP Server (TLS) id 15.0.1054.13 via Frontend Transport; Mon, 20 Oct 2014 15:44:55 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD030.mail.protection.outlook.com (10.58.52.168) with Microsoft SMTP Server (TLS) id 15.0.1049.20 via Frontend Transport; Mon, 20 Oct 2014 15:44:53 +0000 Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.93]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.03.0210.003; Mon, 20 Oct 2014 15:44:42 +0000 From: Mike Jones To: Barry Leiba Thread-Topic: Barry Leiba's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) Thread-Index: Ac/nrPscpwn+lU95TEyXOragiNkBcgEz7Qsg Date: Mon, 20 Oct 2014 15:44:41 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439BB1AE8A@TK5EX14MBXC286.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739439BB0D351@TK5EX14MBXC286.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439BB0D351@TK5EX14MBXC286.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(164054003)(199003)(13464003)(51704005)(52044002)(50854003)(43784003)(51914003)(189002)(377454003)(21056001)(50986999)(68736004)(69596002)(19580395003)(19580405001)(84676001)(87936001)(85852003)(230783001)(85806002)(2656002)(86612001)(85306004)(76176999)(54356999)(15975445006)(120916001)(97736003)(26826002)(76482002)(23676002)(80022003)(46102003)(92726001)(55846006)(92566001)(99396003)(86362001)(33656002)(66066001)(95666004)(4396001)(64706001)(31966008)(20776003)(47776003)(50466002)(104016003)(44976005)(77096002)(107046002)(110136001)(6806004)(81156004)(106466001)(15202345003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB1212; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB1212; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 03706074BC Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Sh5Hm4ILZLV3aj39KFrBrr4YbcU Cc: "oauth-chairs@tools.ietf.org" , "oauth@ietf.org" , The IESG , "draft-ietf-oauth-json-web-token@tools.ietf.org" Subject: Re: [OAUTH-WG] Barry Leiba's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 15:46:45 -0000 SGkgQmFycnksDQoNCkNvdWxkIHlvdSB0YWtlIGEgbG9vayBhdCB0aGUgdGV4dCBjaGFuZ2VzIG1h ZGUgYW5kIHJlc3BvbnNlcyB0byB5b3VyIERJU0NVU1MgcG9zaXRpb25zIGluIHRoZSBuZXh0IGZl dyBkYXlzPyAgV2XigJlyZSBkb3duIHRvIGEgd2VlayBsZWZ0IHRvIHN1Ym1pdCBuZXcgZHJhZnRz IGFuZCBpZiB3ZSBuZWVkIHRvIG1ha2UgZnVydGhlciBjaGFuZ2VzIGZvciB5b3UsIGl0IHdvdWxk IGJlIGdvb2QgdG8ga25vdyB3aGF0IHRoZXkgYXJlIGJlZm9yZSB0aGF0Lg0KDQpJbiByZXNwb25z ZSB0byB5b3VyIGZpcnN0IERJU0NVU1MsIHRoZSBzdHJpbmcgY29tcGFyaXNvbiBydWxlcyBhdCBo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWpzb24td2ViLXRva2Vu LTI5I3NlY3Rpb24tNy4zIGhhdmUgYmVlbiByZXZpc2VkIHRvIHJlZmVyZW5jZSB0aGUgcnVsZXMg aW4gUkZDIDcxNTksIHRvIGV4cGxpY2l0bHkgbGlzdCB0aGUgZXhjZXB0aW9ucyBmb3Ig4oCcdHlw 4oCdIGFuZCDigJxjdHnigJ0sIGFuZCB0byBpbmNsdWRlIHRoZSBuZXcgbGFzdCBwYXJhZ3JhcGgg YWJvdXQgaW5jbHVkaW5nIGNhc2UtaW5zZW5zaXRpdmUgdmFsdWVzIGFzIHBhcnQgb2YgY2FzZS1z ZW5zaXRpdmUgZmllbGRzLg0KDQpJbiByZXNwb25zZSB0byB5b3VyIHNlY29uZCwgdGhlIGRyYWZ0 cyBub3cgcmVmZXJlbmNlIFJGQyA2ODM4LCBub3cgaW5jbHVkZSBmcmFnbWVudCBpZGVudGlmaWVy IGNvbnNpZGVyYXRpb25zIGFuZCBwcm92aXNpb25hbCByZWdpc3RyYXRpb24gZW50cmllcywgYW5k IEthdGhsZWVuIGluaXRpYXRlZCB0aGUgbWVkaWEtdHlwZXNAaWFuYS5vcmcgcmV2aWV3IG9uIE9j dG9iZXIgMXN0LCB3aXRoIG5vIG9iamVjdGlvbnMgaGF2aW5nIGJlZW4gdm9pY2VkIGR1cmluZyB0 aGUgcmV2aWV3Lg0KDQpUaGUgcHJvcG9zZWQgcmVzb2x1dGlvbnMgd2VyZSBhcHBsaWVkIGluIHJl c3BvbnNlIHRvIHlvdXIgQ09NTUVOVCBwb3NpdGlvbnMgdG9vLg0KDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBUaGFua3MsDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAt LSBNaWtlDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBNaWtlIEpvbmVzIFtt YWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tXSANClNlbnQ6IFR1ZXNkYXksIE9jdG9i ZXIgMTQsIDIwMTQgNTo0NyBBTQ0KVG86IEJhcnJ5IExlaWJhOyBUaGUgSUVTRw0KQ2M6IG9hdXRo LWNoYWlyc0B0b29scy5pZXRmLm9yZzsgZHJhZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi10b2tlbkB0 b29scy5pZXRmLm9yZzsgb2F1dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBCYXJyeSBMZWliYSdz IERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi10b2tlbi0yNzogKHdpdGggRElT Q1VTUyBhbmQgQ09NTUVOVCkNCg0KVGhlIHByb3Bvc2VkIHJlc29sdXRpb25zIGhhdmUgYmVlbiBh cHBsaWVkIHRvIHRoZSAtMjggZHJhZnQuICBIb3BlZnVsbHkgdGhpcyB3aWxsIGVuYWJsZSB0byBj bGVhciB5b3VyIERJU0NVU1Nlcy4gIFRoYW5rcyBhZ2FpbiBmb3IgdGhlIGNhcmVmdWwgcmVhZCEN Cg0KCQkJCS0tIE1pa2UNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBP QXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNaWtlIEpv bmVzDQo+IFNlbnQ6IFNhdHVyZGF5LCBPY3RvYmVyIDA0LCAyMDE0IDU6MTcgUE0NCj4gVG86IEJh cnJ5IExlaWJhOyBUaGUgSUVTRw0KPiBDYzogb2F1dGgtY2hhaXJzQHRvb2xzLmlldGYub3JnOyBk cmFmdC1pZXRmLW9hdXRoLWpzb24td2ViLSANCj4gdG9rZW5AdG9vbHMuaWV0Zi5vcmc7IG9hdXRo QGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEJhcnJ5IExlaWJhJ3MgRGlzY3Vz cyBvbiANCj4gZHJhZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi0NCj4gdG9rZW4tMjc6ICh3aXRoIERJ U0NVU1MgYW5kIENPTU1FTlQpDQo+IA0KPiBUaGFua3MgZm9yIHlvdXIgcmV2aWV3LCBCYXJyeS4g IEknbSBhZGRpbmcgdGhlIHdvcmtpbmcgZ3JvdXAgc28gDQo+IHRoZXnigJlyZSBhd2FyZSBvZiB0 aGVzZSBjb21tZW50cy4gIEF0IFN0ZXBoZW4gRmFycmVsbCdzIHJlcXVlc3QsIEknbSANCj4gcmVz cG9uZGluZyB3aXRoICI+ICIgbGluZSBwcmVmaXhlcyBvbiBwcmV2aW91cyB0aHJlYWQgY29udGVu dC4gIEknbSANCj4gYWxzbyByZXBlYXRpbmcgKGFuZCBpbiB0aGUgZmlyc3QgY2FzZSwNCj4gYXVn bWVudGluZykgbXkgcHJldmlvdXMgcmVzcG9uc2VzIHRvIHRoZSBESVNDVVNTIGNvbW1lbnRzIGlu IHRoaXMgDQo+IGNvbnNvbGlkYXRlZCBtZXNzYWdlLg0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiA+IEZyb206IEJhcnJ5IExlaWJhIFttYWlsdG86YmFycnlsZWliYUBjb21w dXRlci5vcmddDQo+ID4gU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDAxLCAyMDE0IDg6NTQgQU0N Cj4gPiBUbzogVGhlIElFU0cNCj4gPiBDYzogb2F1dGgtY2hhaXJzQHRvb2xzLmlldGYub3JnOyBk cmFmdC1pZXRmLW9hdXRoLWpzb24td2ViLSANCj4gPiB0b2tlbkB0b29scy5pZXRmLm9yZw0KPiA+ IFN1YmplY3Q6IEJhcnJ5IExlaWJhJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLW9hdXRoLWpzb24t d2ViLXRva2VuLTI3Og0KPiA+ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpDQo+ID4NCj4gPiBC YXJyeSBMZWliYSBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3IN Cj4gPiBkcmFmdC1pZXRmLW9hdXRoLWpzb24td2ViLXRva2VuLTI3OiBEaXNjdXNzDQo+ID4NCj4g PiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFu ZCByZXBseSB0byANCj4gPiBhbGwgZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBh bmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gDQo+ID4gY3V0IHRoaXMgaW50cm9kdWN0b3J5IHBh cmFncmFwaCwgaG93ZXZlci4pDQo+ID4NCj4gPg0KPiA+IFBsZWFzZSByZWZlciB0bw0KPiA+IGh0 dHA6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQo+ ID4gZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBv c2l0aW9ucy4NCj4gPg0KPiA+DQo+ID4gVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJh bGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KPiA+IGh0dHA6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi10b2tlbi8NCj4gPg0KPiA+ DQo+ID4NCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+IC0tDQo+ID4gRElTQ1VTUzoNCj4gPiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KPiA+IC0tDQo+ID4NCj4gPiBJIGhhdmUgdHdvIHBvaW50cyB0aGF0IEknZCBsaWtlIHRv IGdldCByZXNvbHZlZCBiZWZvcmUgaGFwcGlseSANCj4gPiBhcHByb3ZpbmcgdGhpcyBmaW5lDQo+ ID4gZG9jdW1lbnQ6DQo+ID4NCj4gPiAtLSBTZWN0aW9uIDcuMSAtLQ0KPiA+DQo+ID4gVGhlIGNv bXBhcmlzb24geW91IHNwZWNpZnkgaXMgYXMgc3BlY2lmaWVkIGluIFJGQyA3MTU5LCBTZWN0aW9u IDguMywgDQo+ID4gd2hpY2ggaXMgdG8gInRyYW5zZm9ybSB0aGUgdGV4dHVhbCByZXByZXNlbnRh dGlvbiBpbnRvIHNlcXVlbmNlcyBvZiANCj4gPiBVbmljb2RlIGNvZGUgdW5pdHMgYW5kIHRoZW4g cGVyZm9ybSB0aGUgY29tcGFyaXNvbiBudW1lcmljYWxseSwgY29kZSANCj4gPiB1bml0IGJ5IGNv ZGUgdW5pdCIuICBUaGlzIGhhcyBubyByZWdhcmQgZm9yIHRleHQgY2FzZSwgYW5kIHNvIGl0J3Mg YSANCj4gPiBjYXNlLXNlbnNpdGl2ZQ0KPiBjb21wYXJpc29uLg0KPiA+DQo+ID4gQW5kLCB5ZXQs IFNlY3Rpb25zIDUuMSBhbmQgNS4yIHNwZWNpZnkgdGhhdCB0aGUgdmFsdWVzIG9mIHR5cCBhbmQg DQo+ID4gY3R5IGFyZSBjYXNlLSBpbnNlbnNpdGl2ZSwgYW5kIHNwZWNpZnkgdXNpbmcgdXBwZXIg Y2FzZSBhcyBhIFNIT1VMRCwgDQo+ID4gZm9yICJjb21wYXRpYmlsaXR5IHdpdGggbGVnYWN5IGlt cGxlbWVudGF0aW9ucyIuDQo+ID4NCj4gPiBJdCBkb2Vzbid0IHNlZW0gdGhhdCAibGVnYWN5IiBo YXMgYW55dGhpbmcgdG8gZG8gd2l0aCB0aGlzOiBzb21lb25lIA0KPiA+IGNvbmZvcm1pbmcgdG8g KnRoaXMqIHNwZWNpZmljYXRpb24gd2lsbCBjb21wYXJlIHRoZSB2YWx1ZXMgb2YgdHlwIA0KPiA+ IGFuZCBjdHkgVW5pY29kZS1jaGFyYWN0ZXIgYnkgVW5pY29kZS1jaGFyYWN0ZXIsIGFuZCB3aWxs IGZhaWwgdG8gDQo+ID4gbWF0Y2ggIkpXVCIgd2l0aA0KPiAiand0Ii4NCj4gPg0KPiA+IElzIHRo ZXJlIG5vdCBhIHByb2JsZW0gaGVyZT8NCj4gDQo+IFdlIGNhbiB1cGRhdGUgdGhlIHRleHQgdG8g Y2xhcmlmeSB0aGF0IE1JTUUgdHlwZSBjb21wYXJpc29ucyBhcmUgYW4gDQo+IGV4Y2VwdGlvbiB0 byB0aGUg4oCcY29kZSB1bml0IGJ5IGNvZGUgdW5pdOKAnSBjb21wYXJpc29uIHJ1bGUuICBUaGUg ZHJhZnRzIA0KPiB3aWxsIGFsc28gYmUgc2NydXRpbml6ZWQgZm9yIG90aGVyIHBvc3NpYmxlIG9j Y3VycmVuY2VzIG9mIGV4Y2VwdGlvbnMgDQo+IHRvIHRoZSBkZWZhdWx0IHN0cmluZyBjb21wYXJp c29uIGluc3RydWN0aW9ucy4gIEZpbmFsbHksIHdlIGNhbiBhZGQgDQo+IGxhbmd1YWdlIHRvIDcu MSBhYm91dCAidW5sZXNzIG90aGVyd2lzZSBub3RlZCBmb3IgYSBwYXJ0aWN1bGFyIGtpbmQgb2Yg DQo+IHN0cmluZyIgc28gdGhhdCBpdCdzIGNsZWFyIHRoYXQgdGhlcmUgYXJlIGV4Y2VwdGlvbnMg dG8gdGhlIHJ1bGUuDQo+IA0KPiA+IC0tIFNlY3Rpb24gMTAuMy4xIC0tDQo+ID4NCj4gPiBOaWNl IHRoYXQgeW91IGNpdGUgMjA0NiBmb3IgbWVkaWEgdHlwZXMsIGJ1dCB0aGUgKnJlZ2lzdHJhdGlv biogb2YgDQo+ID4gbWVkaWEgdHlwZXMgaXMgZG9jdW1lbnRlZCBpbiBSRkMgNjgzOCwgYW5kIHRo aXMgZG9jdW1lbnQgZG9lc24ndCANCj4gPiBxdWl0ZSBjb25mb3JtIHRvIHRoYXQuICBUaGUgb25s eSB0aGluZyBtaXNzaW5nIGluIHRoZSBkb2MgaXMgDQo+ID4gIkZyYWdtZW50IGlkZW50aWZpZXIg Y29uc2lkZXJhdGlvbnMiIGluIHRoZSByZWdpc3RyYXRpb24gdGVtcGxhdGUsIA0KPiA+IGJ1dCA2 ODM4IGFsc28gc3Ryb25nbHkgc3VnZ2VzdHMgcmV2aWV3IG9mIHRoZSBtZWRpYS10eXBlIA0KPiA+ IHJlZ2lzdHJhdGlvbiBvbiB0aGUgbWVkaWEtdHlwZXMgbWFpbGluZyBsaXN0LiAgR2l2ZW4gdGhh dCB0aGlzIHdpbGwgDQo+ID4gbm90IGdldCBleHBlcnQgcmV2aWV3IChiZWNhdXNlIGl0J3MgYW4g SUVURi1zdHJlYW0gUkZDKSwgSSdkIGxpa2UgdG8gDQo+ID4gYXNrIGZvciBhbiBleHBsaWNpdCBy ZXZpZXcgb24gdGhlIG1lZGlhLXR5cGVzIGxpc3QgdG8gbWFrZSBzdXJlIHRoYXQgDQo+ID4gdGhl IHJlZ2lzdHJhdGlvbiBpbmZvcm1hdGlvbiBpcw0KPiBjb21wbGV0ZSBhbmQgbWFrZXMgc2Vuc2Uu DQo+IA0KPiBUaGFua3MgZm9yIHRoZSA2ODMzIHJlZmVyZW5jZS4gIFdl4oCZbGwgdXNlIHRoYXQu ICBJIGtub3cgdGhhdCBLYXRobGVlbiANCj4gYWxyZWFkeSBpbml0aWF0ZWQgdGhlIHJldmlldyBv biB0aGUgbWVkaWEtdHlwZXMgbGlzdC4NCj4gDQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiAtLQ0KPiA+ IENPTU1FTlQ6DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiAtLQ0KPiA+DQo+ID4gLS0gQWJzdHJhY3Qg LS0NCj4gPg0KPiA+ICAgIFRoZSBzdWdnZXN0ZWQgcHJvbnVuY2lhdGlvbiBvZiBKV1QgaXMgdGhl IHNhbWUgYXMgdGhlIEVuZ2xpc2ggd29yZA0KPiA+ICAgICJqb3QiLg0KPiA+DQo+ID4gSSBoYXZl IG5vIG9iamVjdGlvbiAod2VsbCwgSSBkbywgYnV0IGl0J3Mgbm90IGZvciBtZSB0byBzYXkgaG93 IHlvdSANCj4gPiB3YW50IHRvIHByb25vdW5jZSBpdCkgdG8gaGF2aW5nIHRoaXMgc2VudGVuY2Ug aW4gdGhlIEludHJvZHVjdGlvbiwgDQo+ID4gYnV0IGl0IHNlZW1zIG91dCBvZiBwbGFjZSBpbiB0 aGUgQWJzdHJhY3QsIHdoaWNoIGlzIG1lYW50IHRvIGJlIGNvbmNpc2UuDQo+IA0KPiBPSyAtIFdl IGNhbiByZW1vdmUgaXQgZnJvbSB0aGUgQWJzdHJhY3QuDQo+IA0KPiA+IC0tIFNlY3Rpb24gNC4x IC0tDQo+ID4NCj4gPiBJdCBhcHBlYXJzIHRoYXQgYWxsIGNsYWltcyBkZWZpbmVkIGhlcmUgYXJl IE9QVElPTkFMLCBhbmQgZWFjaCBvbmUgDQo+ID4gc2F5cyBzbyBpbiBpdHMgc3Vic2VjdGlvbi4g IEdpdmVuIHRoYXQgdGhleSAqYWxsKiBhcmUsIGl0IG1pZ2h0IGJlIA0KPiA+IHVzZWZ1bCB0byBz YXkgdGhhdCB1cCBmcm9udCwgbWF5YmUgd2l0aCBhIHNlbnRlbmNlIHRoYXQgc2F5cywgIkFsbCAN Cj4gPiBjbGFpbXMgZGVmaW5lZCBpbiB0aGlzIHNlY3Rpb24gYXJlIE9QVElPTkFMIHRvIHVzZS4i ICAoSSBkb24ndCBmZWVsIA0KPiA+IHN0cm9uZ2x5IGFib3V0IHRoaXM7IGl0J3MganVzdCBhIHN1 Z2dlc3Rpb24sIHNvIGRvIHdpdGggaXQgYXMgeW91IA0KPiA+IHNlZSBiZXN0LikgIFNlZQ0KPiBh bHNvIG15IGNvbW1lbnQgb24gMTAuMS4xLCBiZWxvdy4NCj4gDQo+IEVkaXRvcmlhbGx5LCB3ZSBk ZWNpZGVkIHRvIGRlc2NyaWJlIHRoZSBvcHRpb25hbGl0eSBvZiBlYWNoIGNsYWltIGluIA0KPiB0 aGUgY2xhaW0gZGVmaW5pdGlvbiBzbyB0aGF0IHdoZW4gdXNlZCBhcyBhIHJlZmVyZW5jZSB3aXRo b3V0IHJlYWRpbmcgDQo+IHRoZSB3aG9sZSB0aGluZywgdGhlIG9wdGlvbmFsaXR5IHdpbGwgc3Rp bGwgYmUgb2J2aW91cyB0byB0aGUgcmVhZGVyLg0KPiANCj4gPiAtLSBTZWN0aW9uIDQuMS4yIC0t DQo+ID4NCj4gPiAgICBUaGUgc3ViamVjdCB2YWx1ZSBNQVkgYmUgc2NvcGVkIHRvIGJlIGxvY2Fs bHkNCj4gPiAgICB1bmlxdWUgaW4gdGhlIGNvbnRleHQgb2YgdGhlIGlzc3VlciBvciBNQVkgYmUg Z2xvYmFsbHkgdW5pcXVlLg0KPiA+DQo+ID4gT3IgaXQgTUFZIGJlIGFueXRoaW5nIGVsc2UsIGlu Y2x1ZGluZyBub3QgdW5pcXVlIGF0IGFsbC4gIElzIHRoYXQgd2hhdCB5b3UgbWVhbj8NCj4gPiBP ciBhcmUgdGhlc2UgbWVhbnQgdG8gYmUgdHdvIG9wdGlvbnMsIG9uZSBvZiB3aGljaCBoYXMgdG8g YmUgdHJ1ZT8gIA0KPiA+IElmIHNvLCB5b3UgbmVlZCB0byByZS1kbyB0aGlzLCBwZXJoYXBzIGxp a2UgdGhpczoNCj4gPg0KPiA+IE5FVw0KPiA+ICAgVGhlIHN1YmplY3QgdmFsdWUgTVVTVCBlaXRo ZXIgYmUgZ2xvYmFsbHkgdW5pcXVlLCBvciBiZSBzY29wZWQNCj4gPiAgIHRvIGJlIGxvY2FsbHkg dW5pcXVlIGluIHRoZSBjb250ZXh0IG9mIHRoZSBpc3N1ZXIuDQo+ID4gRU5EDQo+IA0KPiBZb3Vy IG5ldyBsYW5ndWFnZSBtYXRjaGVzIHRoZSBpbnRlbnQuICBJJ2xsIHBsYW4gdG8gcmV2aXNlIGFj Y29yZGluZ2x5Lg0KPiANCj4gPiAtLSBTZWN0aW9uIDEwLjEuMSAtLQ0KPiA+DQo+ID4gR2l2ZW4g dGhhdCB0aGUgZGVzY3JpcHRpb25zIG9mIHRoZSBjbGFpbXMgaW5jbHVkZSBhIHN0YXRlbWVudCB0 aGF0IA0KPiA+IHRoZWlyIHVzZSBpcyBPUFRJT05BTCwgc2hvdWxkIHRoZXJlIG5vdCBiZSBhbiBl bnRyeSBpbiB0aGUgdGFibGUgDQo+ID4gdGhhdCBzYXlzIHdoZXRoZXIgdGhlIGNsYWltIGlzIE9Q VElPTkFMIG9yIFJFUVVJUkVEID8gIE9yIGlzIGl0IHRoZSANCj4gPiBpbnRlbnQgdGhhdA0KPiA+ ICphbGwqIG9mIHRoZW0gYWx3YXlzIGJlIE9QVElPTkFMID8gIE9yIGlzIGl0IHN1ZmZpY2llbnQg dG8gaGF2ZSB0aGF0IA0KPiA+IGluZGljYXRpb24gaW4gdGhlIHJlZmVyZW5jZSBkb2N1bWVudGF0 aW9uID8NCj4gDQo+IFdoYXQgY2xhaW1zIGFyZSByZXF1aXJlZCBieSBhcHBsaWNhdGlvbnMgd2ls bCBiZSBzcGVjaWZpZWQgYnkgDQo+IGFwcGxpY2F0aW9ucy4gIEZvciBpbnN0YW5jZSwgc29tZSBh cHBsaWNhdGlvbnMgdXNpbmcgSldUcyByZXF1aXJlIHRoYXQgDQo+IHRoZSBpc3N1ZXIsIHN1Ympl Y3QsIGFuZCBhdWRpZW5jZSBiZSBwcmVzZW50LiAgVGhlcmVmb3JlLCBJIGRvbid0IA0KPiB0aGlu ayB0aGF0IGFkZGluZyBhIHRhYmxlIGVudHJ5IHdvdWxkIGhlbHAgYSBncmVhdCBkZWFsLCBhbmQg aXQgY291bGQgZXZlbiBjb25mdXNlIHNvbWUgZGV2ZWxvcGVycy4NCj4gDQo+IAkJCQktLSBNaWtl DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4gT0F1dGhAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0K From nobody Mon Oct 20 10:09:49 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB111A701C for ; Mon, 20 Oct 2014 10:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CzKpYqFu6TV8 for ; Mon, 20 Oct 2014 10:09:37 -0700 (PDT) Received: from na3sys009aog119.obsmtp.com (na3sys009aog119.obsmtp.com [74.125.149.246]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B5361A6EF2 for ; Mon, 20 Oct 2014 09:59:27 -0700 (PDT) Received: from mail-ie0-f177.google.com ([209.85.223.177]) (using TLSv1) by na3sys009aob119.postini.com ([74.125.148.12]) with SMTP ID DSNKVEU/Z8sFEii+NSZjMcEJEleN344RPJ/p@postini.com; Mon, 20 Oct 2014 09:59:27 PDT Received: by mail-ie0-f177.google.com with SMTP id rd18so5094124iec.36 for ; Mon, 20 Oct 2014 09:59:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=E2sSmUY0rClsqunhfXZA9Gs+K74+eYtDuQr+hehZ0+U=; b=a5hGAHHHjobFDRwDHb08lXg+tKeXeh1AJYZt2o0nIyT7uxLp74QYHCpfx8puW/J8mF ADh2l1UgoL+b6ti4RsLUFMOArNyrgnrTFW+RVWv9Oz3b/7jRIpKGISMKDL84lGo3hx1U vPKAYKE7lzLv3p5KweAs5EpQ1n0f4urlvaN1VrdhLCSU6oHh+TocGKclwXzKRt1mO2Wo fypXogx5uPCcm2VqONZrBZxDf3qq9TMe8mBcBSCg3kPBKhC3LogQq8Yzae0xUd5sscJu 0RklhbLEoJbChcEWwFzFZBMi3R+b2mHveNOe/a/Xhm56Qn3aKDVqChc7UaB2DgiSiqlb Ppiw== X-Gm-Message-State: ALoCoQll2IGzMdbsg4Iz0zS+/TJkwPmIwqPfFXNL0CY/YvcKdjINo0OXl4l2FylRoy9HfrRDNHPVOKoXUTGgD8bYmSGLD6+r+beSs+vLmY0Fl5bdmsYGmjn6dd3m/Z9XBFhCU09APkgX X-Received: by 10.107.7.229 with SMTP id g98mr4246386ioi.58.1413824354042; Mon, 20 Oct 2014 09:59:14 -0700 (PDT) X-Received: by 10.107.7.229 with SMTP id g98mr4245052ioi.58.1413824341063; Mon, 20 Oct 2014 09:59:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.86.167 with HTTP; Mon, 20 Oct 2014 09:58:30 -0700 (PDT) In-Reply-To: References: <20141018220518.E834D6E721@mail.zxidp.org> From: Brian Campbell Date: Mon, 20 Oct 2014 10:58:30 -0600 Message-ID: To: oauth Content-Type: multipart/alternative; boundary=001a113f9b009fd2530505dda17f Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/yf_SNncHq8xPFXEHu-i7sYTAK78 Subject: [OAUTH-WG] Fwd: EncryptedAssertion in draft-ietf-oauth-saml2-bearer-21 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 17:09:42 -0000 --001a113f9b009fd2530505dda17f Content-Type: text/plain; charset=UTF-8 I received the below over the weekend and, although oauth@ietf.org is cc'd, it didn't post to the list - I assume because sampo-ietf@zxidp.org isn't subscribed. I thought I should send to the WG list so folks are aware. I don't believe EncryptedAssertion should be supported, for three main reasons. 1) It is very late in the document process, which is currently in IESG review. It's too late, really, for a change like this. 2) It adds complexly that's not necessarily needed as the Subject and/or individual attributes of a SAML Assertion can be encrypted to the authorization server 3) It greatly increases the risk that usage of this profile be vulnerable to attacks such as those described in http://www.nds.ruhr-uni-bochum.de/research/publications/backwards-compatibility/ whereas having the encrypted parts appear under a signature (and not attempting decryption if the signature validation fails) mitigates the risk ---------- Forwarded message ---------- From: Date: Sat, Oct 18, 2014 at 4:05 PM Subject: EncryptedAssertion in draft-ietf-oauth-saml2-bearer-21 To: brian.d.campbell@gmail.com Cc: oauth@ietf.org, sampo-ietf@zxidp.org Seems sec 3, list item 10 (p.8) mentions that encryption per SAML2 is allowed, but I think it would be helpful to call out that specifically EncryptedAssertion is allowed. Mentioning EncryptedAssertion as valid possibility in secs 2.2 and 2.3 would also help. The Privacy Considerations section should mention use of EncryptedAssertion to protect against eavesdropping by intermediaries that handle assertions (e.g. OAUTH Client which gets it from STS and passes it to AS). Cheers, --Sampo --001a113f9b009fd2530505dda17f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I received the below over the weekend and, although <= a href=3D"mailto:oauth@ietf.org" target=3D"_blank">oauth@ietf.org is cc= 'd, it didn't post to the list - I assume because sampo-ietf@zxidp.org isn't= subscribed. I thought I should send to the WG list so folks are aware.
=
I don't believe EncryptedAssertion should be supported, = for three main reasons.

1) It is very late in the documen= t process, which is currently in IESG review. It's too late, really, fo= r a change like this.
2) It adds complexly that's not nec= essarily needed as the Subject and/or individual attributes of a SAML Asser= tion can be encrypted to the authorization server
3) It great= ly increases the risk that usage of this profile be vulnerable to attacks s= uch as those described in http://www.nds.ruhr-uni-bochum.= de/research/publications/backwards-compatibility/ whereas having the en= crypted parts appear under a signature (and not attempting decryption if th= e signature validation fails) mitigates the risk


---------- Forwarded message ----------
From: <sampo-ietf@zxidp.org>
Date: Sat,= Oct 18, 2014 at 4:05 PM
Subject: EncryptedAssertion in draft-ietf-oauth= -saml2-bearer-21
To: brian.d.campbell@gmail.com
Cc: oauth@ietf.org, sampo-ietf@zxidp.org


Seems se= c 3, list item 10 (p.8) mentions that encryption per SAML2 is
allowed, but I think it would be helpful to call out that specifically
EncryptedAssertion is allowed. Mentioning EncryptedAssertion as valid
possibility in secs 2.2 and 2.3 would also help.

The Privacy Considerations section should mention use of EncryptedAssertion=
to protect against eavesdropping by intermediaries that handle assertions (e.g. OAUTH Client which gets it from STS and passes it to AS).

Cheers,
--Sampo


--001a113f9b009fd2530505dda17f-- From nobody Mon Oct 20 11:42:15 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DAE91A9004 for ; Mon, 20 Oct 2014 11:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJk7rd8_xRRW for ; Mon, 20 Oct 2014 11:42:10 -0700 (PDT) Received: from na3sys009aog121.obsmtp.com (na3sys009aog121.obsmtp.com [74.125.149.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD9A71A1B92 for ; Mon, 20 Oct 2014 11:42:09 -0700 (PDT) Received: from mail-wi0-f174.google.com ([209.85.212.174]) (using TLSv1) by na3sys009aob121.postini.com ([74.125.148.12]) with SMTP ID DSNKVEVXgXbFMw/OHqf9so14D/KoKJFfJ6N1@postini.com; Mon, 20 Oct 2014 11:42:09 PDT Received: by mail-wi0-f174.google.com with SMTP id r20so64407wiv.13 for ; Mon, 20 Oct 2014 11:42:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=xf1zfup/9mRndbwRRIsom+1fLrn9NGCoHAw4PT44rjc=; b=WKcC0HSS5gN0b+cwKuPyknmDBX4/Y5AGUyM6MmsdtwW63BYazepCMnB0mCGttb1D+8 gnUc2BvCGmg3Jv7qxuISKxYT7S9VkKITpiJdzxjRqrtaI6gSw8anmIvy2nJDS/BLukIB ldKe/hyEtuzxrA5DrB145riFOygXVt9TaV044Co/F/5uZuP18h6xQnlJqF6PdUuhiHfp oqt4JUWwBjKAWWv5mMDSmYwBVZXc5q4QCKfOwAXie93/IO8OYYM7SZf7MJ79jm3+kcN6 GBnaPuYG3xUtNVWQKayVXAroqFgRKd+zR36Vykp1ebKq30AZiWqG/QhuPbTg9YIi2YDE 0+qQ== X-Gm-Message-State: ALoCoQlia1xAPpXOgZydGRzhCTtc1yOVA0wgTzmFgIIcLWd77b1GK5vNyIhSoGwwsR1cA52FJ34V+EYDpXJkORDX4g4zz97AzJWjewNzQpzAV3yY42LettmBCtv3Twi41qYq6ecM50j/ X-Received: by 10.195.13.114 with SMTP id ex18mr6883475wjd.111.1413830528128; Mon, 20 Oct 2014 11:42:08 -0700 (PDT) X-Received: by 10.195.13.114 with SMTP id ex18mr6883457wjd.111.1413830527964; Mon, 20 Oct 2014 11:42:07 -0700 (PDT) Received: from [192.168.53.160] ([86.188.131.84]) by mx.google.com with ESMTPSA id ey6sm10511766wib.16.2014.10.20.11.42.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 20 Oct 2014 11:42:07 -0700 (PDT) Message-ID: <5445577D.4050207@pingidentity.com> Date: Mon, 20 Oct 2014 20:42:05 +0200 From: Hans Zandbelt User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Richer, Justin P." References: <543FF850.6070409@gmx.net> <543FFB13.2060903@pingidentity.com> <5440373F.9090601@pingidentity.com> In-Reply-To: <5440373F.9090601@pingidentity.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/0qEjTcRZDKaHF8Y4NcoBjlKxeGw Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference Call X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 18:42:13 -0000 or pointier: there are OAuth 2.0 deployments today that offer login semantics because they have a REST/JSON user profile API that can be accessed using the AT that was obtained in a code flow; should that be acknowledged in the doc? Hans. On 10/16/14, 11:23 PM, Hans Zandbelt wrote: > a deployment-related question that I have around this topic: > > it seems that authentication using OAuth 2.0 is possible today for > confidential clients using the code flow, with a registered > redirect_uri, not consuming/storing/using refresh_tokens, and assuming > that there's an API that returns user identity info in JSON format and > the claim that uniquely identifies the user is known by the client. > > The usage/presence of the short-lived code in this scenario/flow > guarantees that the user has just authenticated, and the audience issue > is covered by the fact that the code (thus the access_token in the token > endpoint response) are bound to the confidential client, all as per > standard OAuth 2.0 semantics. > > 2 questions about that: > - is this right or am I overlooking some security/semantics issues here > - if right, would it make sense to acknowledge that or is that muddying > the waters even more (the current text does seem to only implicitly > acknowledge this) > > There may be value in acknowledging this because the majority of OAuth > 2.0 OPs exposing a userinfo-like API would adhere to a REST GET+JSON > response anyhow [1] thus achieving login semantics with plain OAuth 2.0 > and a bit of common practice wrt. the user info API. > > Thanks for the excellent write-up! > > Hans. > > PS: I've been asked this concrete question about Spotify's OAuth 2.0 > support and in fact I'm able to configure Spotify as an IDP to my OIDC > client with a minor workaround to abstain from expecting an id_token in > the token endpoint response, but calling the Spotify specific user info > endpoint like it was a standards-compliant OpenID Connect endpoint. (the > client has a per-OP configurable unique user id claim name anyhow). > > On 10/16/14, 7:27 PM, Richer, Justin P. wrote: >> Ah yes, good catch! If only someone would put up a webpage describing >> the difference between authorization and authentication and why people >> need to stop confusing the two. >> >> Oh wait... >> >> >> On Oct 16, 2014, at 1:06 PM, Hans Zandbelt >> wrote: >> >>> About the write-up: at the end of the metaphor section it says: >>> "These recipes each add a number of items, such as a common profile >>> API, to OAuth to create an authorization protocol." >>> >>> whereas I believe that should read "to create an authentication >>> protocol" >>> >>> Hans. >>> >>> On 10/16/14, 6:54 PM, Hannes Tschofenig wrote: >>>> Participants: >>>> >>>> * Brian Campbell >>>> * John Bradley >>>> * Derek Atkins >>>> * Phil Hunt >>>> * William Kim >>>> * Josh Mandel >>>> * Hannes Tschofenig >>>> >>>> >>>> Notes: >>>> >>>> Justin distributed a draft writeup and explained the reasoning behind >>>> it. The intended purpose is to put the write-up (after enough >>>> review) on >>>> oauth.net. See attachments. Justin solicited feedback from the >>>> conference call participants and from the working group. >>>> >>>> One discussion item was specifically related to the concept of audience >>>> restrictions, which comes in two flavours: (a) restriction of the >>>> access >>>> token regarding the resource server and (b) restriction of the id token >>>> regarding the client. Obviously, it is necessary to have both of these >>>> audience restrictions in place and to actually check them. >>>> >>>> The group then went into a discussion about the use of pseudonyms in >>>> authentication and the problems deployments ran into when they used >>>> pseudonyms together with a wide range of attributes that identified >>>> users nevertheless. Phil suggested to produce a write-up about this >>>> topic. >>>> >>>> Finally, the group started a discussion about potential actions for the >>>> OAuth working groups. Two activities were mentioned, namely to produce >>>> an IETF draft of the write-up Justin has prepared as a "formal" >>>> response >>>> to the problems with authentication using OAuth and, as a second topic, >>>> potential re-chartering of the OAuth working group to work on some >>>> solutions in this area. Hannes suggested to postpone these discussions >>>> and to first finish the write-up Justin had distributed. >>>> >>>> Ciao >>>> Hannes & Derek >>>> >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> >>> -- >>> Hans Zandbelt | Sr. Technical Architect >>> hzandbelt@pingidentity.com | Ping Identity >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> > -- Hans Zandbelt | Sr. Technical Architect hzandbelt@pingidentity.com | Ping Identity From nobody Mon Oct 20 12:04:26 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E50531A9135 for ; Mon, 20 Oct 2014 12:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=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 Ch1nBspJJ61r for ; Mon, 20 Oct 2014 12:04:23 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id DB7551A9115 for ; Mon, 20 Oct 2014 12:04:22 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6DDFE42E0DD; Mon, 20 Oct 2014 15:04:22 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id 585C052E143; Mon, 20 Oct 2014 15:04:22 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.78]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.03.0174.001; Mon, 20 Oct 2014 15:04:22 -0400 From: "Richer, Justin P." To: Hans Zandbelt Thread-Topic: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference Call Thread-Index: AQHP6WZlO/nGGvgIwEWGX+qJtsnt/pwzfweAgAYcUYCAAAY4gA== Date: Mon, 20 Oct 2014 19:04:21 +0000 Message-ID: <4198EC12-ED03-4ED8-AAD3-3555E34C7EA2@mitre.org> References: <543FF850.6070409@gmx.net> <543FFB13.2060903@pingidentity.com> <5440373F.9090601@pingidentity.com> <5445577D.4050207@pingidentity.com> In-Reply-To: <5445577D.4050207@pingidentity.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.15.56] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/x85_BSsN3SwJguCT_Pxx6qWKY1s Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference Call X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 19:04:25 -0000 This is actually one of the sticky bits that I've tried to address in the d= ocument itself -- I've seen apps that assume that if they're given an acces= s token that can be used to fetch profile information then the user is actu= ally there. This isn't actually a guarantee, but it's commonly true enough = that developers get lazy and rely on it.=20 -- Justin On Oct 20, 2014, at 2:42 PM, Hans Zandbelt wro= te: > or pointier: there are OAuth 2.0 deployments today that offer login seman= tics because they have a REST/JSON user profile API that can be accessed us= ing the AT that was obtained in a code flow; should that be acknowledged in= the doc? >=20 > Hans. >=20 > On 10/16/14, 11:23 PM, Hans Zandbelt wrote: >> a deployment-related question that I have around this topic: >>=20 >> it seems that authentication using OAuth 2.0 is possible today for >> confidential clients using the code flow, with a registered >> redirect_uri, not consuming/storing/using refresh_tokens, and assuming >> that there's an API that returns user identity info in JSON format and >> the claim that uniquely identifies the user is known by the client. >>=20 >> The usage/presence of the short-lived code in this scenario/flow >> guarantees that the user has just authenticated, and the audience issue >> is covered by the fact that the code (thus the access_token in the token >> endpoint response) are bound to the confidential client, all as per >> standard OAuth 2.0 semantics. >>=20 >> 2 questions about that: >> - is this right or am I overlooking some security/semantics issues here >> - if right, would it make sense to acknowledge that or is that muddying >> the waters even more (the current text does seem to only implicitly >> acknowledge this) >>=20 >> There may be value in acknowledging this because the majority of OAuth >> 2.0 OPs exposing a userinfo-like API would adhere to a REST GET+JSON >> response anyhow [1] thus achieving login semantics with plain OAuth 2.0 >> and a bit of common practice wrt. the user info API. >>=20 >> Thanks for the excellent write-up! >>=20 >> Hans. >>=20 >> PS: I've been asked this concrete question about Spotify's OAuth 2.0 >> support and in fact I'm able to configure Spotify as an IDP to my OIDC >> client with a minor workaround to abstain from expecting an id_token in >> the token endpoint response, but calling the Spotify specific user info >> endpoint like it was a standards-compliant OpenID Connect endpoint. (the >> client has a per-OP configurable unique user id claim name anyhow). >>=20 >> On 10/16/14, 7:27 PM, Richer, Justin P. wrote: >>> Ah yes, good catch! If only someone would put up a webpage describing >>> the difference between authorization and authentication and why people >>> need to stop confusing the two. >>>=20 >>> Oh wait... >>>=20 >>>=20 >>> On Oct 16, 2014, at 1:06 PM, Hans Zandbelt >>> wrote: >>>=20 >>>> About the write-up: at the end of the metaphor section it says: >>>> "These recipes each add a number of items, such as a common profile >>>> API, to OAuth to create an authorization protocol." >>>>=20 >>>> whereas I believe that should read "to create an authentication >>>> protocol" >>>>=20 >>>> Hans. >>>>=20 >>>> On 10/16/14, 6:54 PM, Hannes Tschofenig wrote: >>>>> Participants: >>>>>=20 >>>>> * Brian Campbell >>>>> * John Bradley >>>>> * Derek Atkins >>>>> * Phil Hunt >>>>> * William Kim >>>>> * Josh Mandel >>>>> * Hannes Tschofenig >>>>>=20 >>>>>=20 >>>>> Notes: >>>>>=20 >>>>> Justin distributed a draft writeup and explained the reasoning behind >>>>> it. The intended purpose is to put the write-up (after enough >>>>> review) on >>>>> oauth.net. See attachments. Justin solicited feedback from the >>>>> conference call participants and from the working group. >>>>>=20 >>>>> One discussion item was specifically related to the concept of audien= ce >>>>> restrictions, which comes in two flavours: (a) restriction of the >>>>> access >>>>> token regarding the resource server and (b) restriction of the id tok= en >>>>> regarding the client. Obviously, it is necessary to have both of thes= e >>>>> audience restrictions in place and to actually check them. >>>>>=20 >>>>> The group then went into a discussion about the use of pseudonyms in >>>>> authentication and the problems deployments ran into when they used >>>>> pseudonyms together with a wide range of attributes that identified >>>>> users nevertheless. Phil suggested to produce a write-up about this >>>>> topic. >>>>>=20 >>>>> Finally, the group started a discussion about potential actions for t= he >>>>> OAuth working groups. Two activities were mentioned, namely to produc= e >>>>> an IETF draft of the write-up Justin has prepared as a "formal" >>>>> response >>>>> to the problems with authentication using OAuth and, as a second topi= c, >>>>> potential re-chartering of the OAuth working group to work on some >>>>> solutions in this area. Hannes suggested to postpone these discussion= s >>>>> and to first finish the write-up Justin had distributed. >>>>>=20 >>>>> Ciao >>>>> Hannes & Derek >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>=20 >>>> -- >>>> Hans Zandbelt | Sr. Technical Architect >>>> hzandbelt@pingidentity.com | Ping Identity >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>=20 >=20 > --=20 > Hans Zandbelt | Sr. Technical Architect > hzandbelt@pingidentity.com | Ping Identity From nobody Mon Oct 20 12:21:26 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 384B11AC3C7 for ; Mon, 20 Oct 2014 12:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EytxrQE9EWZn for ; Mon, 20 Oct 2014 12:21:12 -0700 (PDT) Received: from na3sys009aog130.obsmtp.com (na3sys009aog130.obsmtp.com [74.125.149.143]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C29B91AC3C3 for ; Mon, 20 Oct 2014 12:21:09 -0700 (PDT) Received: from mail-wi0-f172.google.com ([209.85.212.172]) (using TLSv1) by na3sys009aob130.postini.com ([74.125.148.12]) with SMTP ID DSNKVEVgpSAJLOwMCO5ncO4kIBBQoGAmC9EP@postini.com; Mon, 20 Oct 2014 12:21:09 PDT Received: by mail-wi0-f172.google.com with SMTP id n3so8058113wiv.11 for ; Mon, 20 Oct 2014 12:21:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=RJpH6cLGY/WzNk0Sb3PE69g+wRv7BHtbVm5PUrRdrzk=; b=liEgXIX9DjiF0v581oxyuNNfP6GrPnGJc2hIUxVg1cWgRD0SYidqF8Ty8xo+ReLlAb SGk8M4eoCBkJot3SRRdQZ6AH041ucTTsslGYFkS/3V+1yFqpcje0CbQwfkK/FkEIIeNB 9nZbp/IsL4pE6La+a5y0IltG90xIRIZ6nkWnOs+lHsdKkQMG70QsuYy5s85sq2fz9yIe un4GYhcE5MeR/s2eeePwLz52Le+E75Pq2VbOI5Ze1qSjUcVA00y9Edxa0i45QPERl2A5 yM1VtTEnpCqImA0Lj99WtI0HGMTb9qZ1+H5F23tqyhMTleNjWrek8CYFsYZFNe3jCljg EGSA== X-Gm-Message-State: ALoCoQmM0FmAcrcKEXpjRCKzEebs4MQLnKRTARAaciPOndIDQeBon2T2fNbgNecQvG32h9GzRFBnDkOBF43HCPusiFhdTe6EGiIXy681+3hntrnMOzc2GQNt7XzVF1X6GSdML0BwsbRl X-Received: by 10.180.198.234 with SMTP id jf10mr22496366wic.68.1413832861687; Mon, 20 Oct 2014 12:21:01 -0700 (PDT) X-Received: by 10.180.198.234 with SMTP id jf10mr22496338wic.68.1413832861437; Mon, 20 Oct 2014 12:21:01 -0700 (PDT) Received: from [192.168.53.160] ([86.188.131.84]) by mx.google.com with ESMTPSA id q9sm10626145wix.6.2014.10.20.12.21.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 20 Oct 2014 12:21:00 -0700 (PDT) Message-ID: <5445609B.70607@pingidentity.com> Date: Mon, 20 Oct 2014 21:20:59 +0200 From: Hans Zandbelt User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Richer, Justin P." References: <543FF850.6070409@gmx.net> <543FFB13.2060903@pingidentity.com> <5440373F.9090601@pingidentity.com> <5445577D.4050207@pingidentity.com> <4198EC12-ED03-4ED8-AAD3-3555E34C7EA2@mitre.org> In-Reply-To: <4198EC12-ED03-4ED8-AAD3-3555E34C7EA2@mitre.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/-D2fitLSAGiLJzenrqZy4x_3160 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference Call X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 19:21:17 -0000 My point is that it *is* a guarantee if the AT just came to the client in a code flow; I don't see a problem with that although clients have to be aware of what they're doing and not allow any other flows for this. Hans. On 10/20/14, 9:04 PM, Richer, Justin P. wrote: > This is actually one of the sticky bits that I've tried to address in the document itself -- I've seen apps that assume that if they're given an access token that can be used to fetch profile information then the user is actually there. This isn't actually a guarantee, but it's commonly true enough that developers get lazy and rely on it. > > -- Justin > > > On Oct 20, 2014, at 2:42 PM, Hans Zandbelt wrote: > >> or pointier: there are OAuth 2.0 deployments today that offer login semantics because they have a REST/JSON user profile API that can be accessed using the AT that was obtained in a code flow; should that be acknowledged in the doc? >> >> Hans. >> >> On 10/16/14, 11:23 PM, Hans Zandbelt wrote: >>> a deployment-related question that I have around this topic: >>> >>> it seems that authentication using OAuth 2.0 is possible today for >>> confidential clients using the code flow, with a registered >>> redirect_uri, not consuming/storing/using refresh_tokens, and assuming >>> that there's an API that returns user identity info in JSON format and >>> the claim that uniquely identifies the user is known by the client. >>> >>> The usage/presence of the short-lived code in this scenario/flow >>> guarantees that the user has just authenticated, and the audience issue >>> is covered by the fact that the code (thus the access_token in the token >>> endpoint response) are bound to the confidential client, all as per >>> standard OAuth 2.0 semantics. >>> >>> 2 questions about that: >>> - is this right or am I overlooking some security/semantics issues here >>> - if right, would it make sense to acknowledge that or is that muddying >>> the waters even more (the current text does seem to only implicitly >>> acknowledge this) >>> >>> There may be value in acknowledging this because the majority of OAuth >>> 2.0 OPs exposing a userinfo-like API would adhere to a REST GET+JSON >>> response anyhow [1] thus achieving login semantics with plain OAuth 2.0 >>> and a bit of common practice wrt. the user info API. >>> >>> Thanks for the excellent write-up! >>> >>> Hans. >>> >>> PS: I've been asked this concrete question about Spotify's OAuth 2.0 >>> support and in fact I'm able to configure Spotify as an IDP to my OIDC >>> client with a minor workaround to abstain from expecting an id_token in >>> the token endpoint response, but calling the Spotify specific user info >>> endpoint like it was a standards-compliant OpenID Connect endpoint. (the >>> client has a per-OP configurable unique user id claim name anyhow). >>> >>> On 10/16/14, 7:27 PM, Richer, Justin P. wrote: >>>> Ah yes, good catch! If only someone would put up a webpage describing >>>> the difference between authorization and authentication and why people >>>> need to stop confusing the two. >>>> >>>> Oh wait... >>>> >>>> >>>> On Oct 16, 2014, at 1:06 PM, Hans Zandbelt >>>> wrote: >>>> >>>>> About the write-up: at the end of the metaphor section it says: >>>>> "These recipes each add a number of items, such as a common profile >>>>> API, to OAuth to create an authorization protocol." >>>>> >>>>> whereas I believe that should read "to create an authentication >>>>> protocol" >>>>> >>>>> Hans. >>>>> >>>>> On 10/16/14, 6:54 PM, Hannes Tschofenig wrote: >>>>>> Participants: >>>>>> >>>>>> * Brian Campbell >>>>>> * John Bradley >>>>>> * Derek Atkins >>>>>> * Phil Hunt >>>>>> * William Kim >>>>>> * Josh Mandel >>>>>> * Hannes Tschofenig >>>>>> >>>>>> >>>>>> Notes: >>>>>> >>>>>> Justin distributed a draft writeup and explained the reasoning behind >>>>>> it. The intended purpose is to put the write-up (after enough >>>>>> review) on >>>>>> oauth.net. See attachments. Justin solicited feedback from the >>>>>> conference call participants and from the working group. >>>>>> >>>>>> One discussion item was specifically related to the concept of audience >>>>>> restrictions, which comes in two flavours: (a) restriction of the >>>>>> access >>>>>> token regarding the resource server and (b) restriction of the id token >>>>>> regarding the client. Obviously, it is necessary to have both of these >>>>>> audience restrictions in place and to actually check them. >>>>>> >>>>>> The group then went into a discussion about the use of pseudonyms in >>>>>> authentication and the problems deployments ran into when they used >>>>>> pseudonyms together with a wide range of attributes that identified >>>>>> users nevertheless. Phil suggested to produce a write-up about this >>>>>> topic. >>>>>> >>>>>> Finally, the group started a discussion about potential actions for the >>>>>> OAuth working groups. Two activities were mentioned, namely to produce >>>>>> an IETF draft of the write-up Justin has prepared as a "formal" >>>>>> response >>>>>> to the problems with authentication using OAuth and, as a second topic, >>>>>> potential re-chartering of the OAuth working group to work on some >>>>>> solutions in this area. Hannes suggested to postpone these discussions >>>>>> and to first finish the write-up Justin had distributed. >>>>>> >>>>>> Ciao >>>>>> Hannes & Derek >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>> >>>>> -- >>>>> Hans Zandbelt | Sr. Technical Architect >>>>> hzandbelt@pingidentity.com | Ping Identity >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> >> >> -- >> Hans Zandbelt | Sr. Technical Architect >> hzandbelt@pingidentity.com | Ping Identity > -- Hans Zandbelt | Sr. Technical Architect hzandbelt@pingidentity.com | Ping Identity From nobody Mon Oct 20 12:29:16 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18DCD1AC419 for ; Mon, 20 Oct 2014 12:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=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 QD3riPLc__Tb for ; Mon, 20 Oct 2014 12:29:03 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5AC1AC412 for ; Mon, 20 Oct 2014 12:29:03 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id DE0E252E079; Mon, 20 Oct 2014 15:29:02 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id D13B472E047; Mon, 20 Oct 2014 15:29:02 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.78]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.03.0174.001; Mon, 20 Oct 2014 15:29:02 -0400 From: "Richer, Justin P." To: Hans Zandbelt Thread-Topic: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference Call Thread-Index: AQHP6WZlO/nGGvgIwEWGX+qJtsnt/pwzfweAgAYcUYCAAAY4gIAABKaAgAACQAA= Date: Mon, 20 Oct 2014 19:29:02 +0000 Message-ID: <5659AE3D-7BC0-407C-9A0B-9FE112348815@mitre.org> References: <543FF850.6070409@gmx.net> <543FFB13.2060903@pingidentity.com> <5440373F.9090601@pingidentity.com> <5445577D.4050207@pingidentity.com> <4198EC12-ED03-4ED8-AAD3-3555E34C7EA2@mitre.org> <5445609B.70607@pingidentity.com> In-Reply-To: <5445609B.70607@pingidentity.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.15.56] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <7330E3DF3994C7468FE1A8B6BE3FB230@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/h1u6_FLQb5s7Uk1GJBhuJ5BpRt0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference Call X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 19:29:07 -0000 Right, when you get the AT directly from the token endpoint and it's good f= or something, that will *probably* tell you the user is logged in. This is = assuming that the authentication context can also be communicated, audience= restrictions can be communicated, and all the other good stuff the documen= t talks about. A real problem tends to stem from clients who will take acce= ss tokens from various public endpoints and use them directly (implicit cli= ents are inherently open to this problem). Or that an access token can have= a life long past the authentication event, so if a client saves the access= token off someplace, does a bunch of work, then finally asks "Who's there?= " and makes the user info API call, it's going to get info but not necessar= ily what it assumes.=20 Really, all of this is why there's the ID Token and the Signed Request comp= onents in OIDC and FBC, respectively. Plus you don't always want the profil= e information on every request, so having something the client can read dir= ectly saves a round trip to fetch data it doesn't really want. Having the s= eparation between the authentication context and the profile information re= ally does make the code paths a bit simpler. -- Justin On Oct 20, 2014, at 3:20 PM, Hans Zandbelt wro= te: > My point is that it *is* a guarantee if the AT just came to the client in= a code flow; I don't see a problem with that although clients have to be a= ware of what they're doing and not allow any other flows for this. >=20 > Hans. >=20 > On 10/20/14, 9:04 PM, Richer, Justin P. wrote: >> This is actually one of the sticky bits that I've tried to address in th= e document itself -- I've seen apps that assume that if they're given an ac= cess token that can be used to fetch profile information then the user is a= ctually there. This isn't actually a guarantee, but it's commonly true enou= gh that developers get lazy and rely on it. >>=20 >> -- Justin >>=20 >>=20 >> On Oct 20, 2014, at 2:42 PM, Hans Zandbelt = wrote: >>=20 >>> or pointier: there are OAuth 2.0 deployments today that offer login sem= antics because they have a REST/JSON user profile API that can be accessed = using the AT that was obtained in a code flow; should that be acknowledged = in the doc? >>>=20 >>> Hans. >>>=20 >>> On 10/16/14, 11:23 PM, Hans Zandbelt wrote: >>>> a deployment-related question that I have around this topic: >>>>=20 >>>> it seems that authentication using OAuth 2.0 is possible today for >>>> confidential clients using the code flow, with a registered >>>> redirect_uri, not consuming/storing/using refresh_tokens, and assuming >>>> that there's an API that returns user identity info in JSON format and >>>> the claim that uniquely identifies the user is known by the client. >>>>=20 >>>> The usage/presence of the short-lived code in this scenario/flow >>>> guarantees that the user has just authenticated, and the audience issu= e >>>> is covered by the fact that the code (thus the access_token in the tok= en >>>> endpoint response) are bound to the confidential client, all as per >>>> standard OAuth 2.0 semantics. >>>>=20 >>>> 2 questions about that: >>>> - is this right or am I overlooking some security/semantics issues her= e >>>> - if right, would it make sense to acknowledge that or is that muddyin= g >>>> the waters even more (the current text does seem to only implicitly >>>> acknowledge this) >>>>=20 >>>> There may be value in acknowledging this because the majority of OAuth >>>> 2.0 OPs exposing a userinfo-like API would adhere to a REST GET+JSON >>>> response anyhow [1] thus achieving login semantics with plain OAuth 2.= 0 >>>> and a bit of common practice wrt. the user info API. >>>>=20 >>>> Thanks for the excellent write-up! >>>>=20 >>>> Hans. >>>>=20 >>>> PS: I've been asked this concrete question about Spotify's OAuth 2.0 >>>> support and in fact I'm able to configure Spotify as an IDP to my OIDC >>>> client with a minor workaround to abstain from expecting an id_token i= n >>>> the token endpoint response, but calling the Spotify specific user inf= o >>>> endpoint like it was a standards-compliant OpenID Connect endpoint. (t= he >>>> client has a per-OP configurable unique user id claim name anyhow). >>>>=20 >>>> On 10/16/14, 7:27 PM, Richer, Justin P. wrote: >>>>> Ah yes, good catch! If only someone would put up a webpage describing >>>>> the difference between authorization and authentication and why peopl= e >>>>> need to stop confusing the two. >>>>>=20 >>>>> Oh wait... >>>>>=20 >>>>>=20 >>>>> On Oct 16, 2014, at 1:06 PM, Hans Zandbelt >>>>> wrote: >>>>>=20 >>>>>> About the write-up: at the end of the metaphor section it says: >>>>>> "These recipes each add a number of items, such as a common profile >>>>>> API, to OAuth to create an authorization protocol." >>>>>>=20 >>>>>> whereas I believe that should read "to create an authentication >>>>>> protocol" >>>>>>=20 >>>>>> Hans. >>>>>>=20 >>>>>> On 10/16/14, 6:54 PM, Hannes Tschofenig wrote: >>>>>>> Participants: >>>>>>>=20 >>>>>>> * Brian Campbell >>>>>>> * John Bradley >>>>>>> * Derek Atkins >>>>>>> * Phil Hunt >>>>>>> * William Kim >>>>>>> * Josh Mandel >>>>>>> * Hannes Tschofenig >>>>>>>=20 >>>>>>>=20 >>>>>>> Notes: >>>>>>>=20 >>>>>>> Justin distributed a draft writeup and explained the reasoning behi= nd >>>>>>> it. The intended purpose is to put the write-up (after enough >>>>>>> review) on >>>>>>> oauth.net. See attachments. Justin solicited feedback from the >>>>>>> conference call participants and from the working group. >>>>>>>=20 >>>>>>> One discussion item was specifically related to the concept of audi= ence >>>>>>> restrictions, which comes in two flavours: (a) restriction of the >>>>>>> access >>>>>>> token regarding the resource server and (b) restriction of the id t= oken >>>>>>> regarding the client. Obviously, it is necessary to have both of th= ese >>>>>>> audience restrictions in place and to actually check them. >>>>>>>=20 >>>>>>> The group then went into a discussion about the use of pseudonyms i= n >>>>>>> authentication and the problems deployments ran into when they used >>>>>>> pseudonyms together with a wide range of attributes that identified >>>>>>> users nevertheless. Phil suggested to produce a write-up about this >>>>>>> topic. >>>>>>>=20 >>>>>>> Finally, the group started a discussion about potential actions for= the >>>>>>> OAuth working groups. Two activities were mentioned, namely to prod= uce >>>>>>> an IETF draft of the write-up Justin has prepared as a "formal" >>>>>>> response >>>>>>> to the problems with authentication using OAuth and, as a second to= pic, >>>>>>> potential re-chartering of the OAuth working group to work on some >>>>>>> solutions in this area. Hannes suggested to postpone these discussi= ons >>>>>>> and to first finish the write-up Justin had distributed. >>>>>>>=20 >>>>>>> Ciao >>>>>>> Hannes & Derek >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>=20 >>>>>>=20 >>>>>> -- >>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>> hzandbelt@pingidentity.com | Ping Identity >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>=20 >>>=20 >>> -- >>> Hans Zandbelt | Sr. Technical Architect >>> hzandbelt@pingidentity.com | Ping Identity >>=20 >=20 > --=20 > Hans Zandbelt | Sr. Technical Architect > hzandbelt@pingidentity.com | Ping Identity From nobody Mon Oct 20 13:06:40 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19E911ACDB1 for ; Mon, 20 Oct 2014 13:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.611 X-Spam-Level: X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PP-SUFnalAdb for ; Mon, 20 Oct 2014 13:06:33 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFA301ACDC5 for ; Mon, 20 Oct 2014 13:06:27 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s9KK6Qcc028580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 20 Oct 2014 20:06:27 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s9KK6POm007317 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Oct 2014 20:06:26 GMT Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s9KK6Pm8001533; Mon, 20 Oct 2014 20:06:25 GMT Received: from [192.168.1.133] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 20 Oct 2014 13:06:25 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: <5659AE3D-7BC0-407C-9A0B-9FE112348815@mitre.org> Date: Mon, 20 Oct 2014 13:06:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <81C330CB-0B07-4E70-ABBF-F47E5AEA4CF5@oracle.com> References: <543FF850.6070409@gmx.net> <543FFB13.2060903@pingidentity.com> <5440373F.9090601@pingidentity.com> <5445577D.4050207@pingidentity.com> <4198EC12-ED03-4ED8-AAD3-3555E34C7EA2@mitre.org> <5445609B.70607@pingidentity.com> <5659AE3D-7BC0-407C-9A0B-9FE112348815@mitre.org> To: "Richer, Justin P." X-Mailer: Apple Mail (2.1878.6) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/fqdRHJkTBzZetoW96V_ii448uQI Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference Call X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 20:06:38 -0000 The problem is you are making a lot of assumptions that may or may not = be true - they are just generally true. The right to access may be granted without even authenticating a user. = For example, a web resource might allow any registered client to have = acess to any resource. Only certain scopes require consent. For = example, readProfile is public, but updateProfile is restricted. The presumption that receiving an AT would be entirely false in this = situation as the user was never even authenticated because consent was = not required. We=92ve also talked about how access to a resource /Me also binds the = name of the authenticate user to the access request. If the API does = not have a /Me endpoint, than the identity information you are = requesting could be for any person the AT is allowed to see. This = creates another =93hack=94 point where clients could be fooled to = thinking they have authenticate a particular person when in fact all = they have proven is access it a particular resource not necessarily the = user is valid. Phil @independentid www.independentid.com phil.hunt@oracle.com On Oct 20, 2014, at 12:29 PM, Richer, Justin P. = wrote: > Right, when you get the AT directly from the token endpoint and it's = good for something, that will *probably* tell you the user is logged in. = This is assuming that the authentication context can also be = communicated, audience restrictions can be communicated, and all the = other good stuff the document talks about. A real problem tends to stem = from clients who will take access tokens from various public endpoints = and use them directly (implicit clients are inherently open to this = problem). Or that an access token can have a life long past the = authentication event, so if a client saves the access token off = someplace, does a bunch of work, then finally asks "Who's there?" and = makes the user info API call, it's going to get info but not necessarily = what it assumes.=20 >=20 > Really, all of this is why there's the ID Token and the Signed Request = components in OIDC and FBC, respectively. Plus you don't always want the = profile information on every request, so having something the client can = read directly saves a round trip to fetch data it doesn't really want. = Having the separation between the authentication context and the profile = information really does make the code paths a bit simpler. >=20 > -- Justin >=20 > On Oct 20, 2014, at 3:20 PM, Hans Zandbelt = wrote: >=20 >> My point is that it *is* a guarantee if the AT just came to the = client in a code flow; I don't see a problem with that although clients = have to be aware of what they're doing and not allow any other flows for = this. >>=20 >> Hans. >>=20 >> On 10/20/14, 9:04 PM, Richer, Justin P. wrote: >>> This is actually one of the sticky bits that I've tried to address = in the document itself -- I've seen apps that assume that if they're = given an access token that can be used to fetch profile information then = the user is actually there. This isn't actually a guarantee, but it's = commonly true enough that developers get lazy and rely on it. >>>=20 >>> -- Justin >>>=20 >>>=20 >>> On Oct 20, 2014, at 2:42 PM, Hans Zandbelt = wrote: >>>=20 >>>> or pointier: there are OAuth 2.0 deployments today that offer login = semantics because they have a REST/JSON user profile API that can be = accessed using the AT that was obtained in a code flow; should that be = acknowledged in the doc? >>>>=20 >>>> Hans. >>>>=20 >>>> On 10/16/14, 11:23 PM, Hans Zandbelt wrote: >>>>> a deployment-related question that I have around this topic: >>>>>=20 >>>>> it seems that authentication using OAuth 2.0 is possible today for >>>>> confidential clients using the code flow, with a registered >>>>> redirect_uri, not consuming/storing/using refresh_tokens, and = assuming >>>>> that there's an API that returns user identity info in JSON format = and >>>>> the claim that uniquely identifies the user is known by the = client. >>>>>=20 >>>>> The usage/presence of the short-lived code in this scenario/flow >>>>> guarantees that the user has just authenticated, and the audience = issue >>>>> is covered by the fact that the code (thus the access_token in the = token >>>>> endpoint response) are bound to the confidential client, all as = per >>>>> standard OAuth 2.0 semantics. >>>>>=20 >>>>> 2 questions about that: >>>>> - is this right or am I overlooking some security/semantics issues = here >>>>> - if right, would it make sense to acknowledge that or is that = muddying >>>>> the waters even more (the current text does seem to only = implicitly >>>>> acknowledge this) >>>>>=20 >>>>> There may be value in acknowledging this because the majority of = OAuth >>>>> 2.0 OPs exposing a userinfo-like API would adhere to a REST = GET+JSON >>>>> response anyhow [1] thus achieving login semantics with plain = OAuth 2.0 >>>>> and a bit of common practice wrt. the user info API. >>>>>=20 >>>>> Thanks for the excellent write-up! >>>>>=20 >>>>> Hans. >>>>>=20 >>>>> PS: I've been asked this concrete question about Spotify's OAuth = 2.0 >>>>> support and in fact I'm able to configure Spotify as an IDP to my = OIDC >>>>> client with a minor workaround to abstain from expecting an = id_token in >>>>> the token endpoint response, but calling the Spotify specific user = info >>>>> endpoint like it was a standards-compliant OpenID Connect = endpoint. (the >>>>> client has a per-OP configurable unique user id claim name = anyhow). >>>>>=20 >>>>> On 10/16/14, 7:27 PM, Richer, Justin P. wrote: >>>>>> Ah yes, good catch! If only someone would put up a webpage = describing >>>>>> the difference between authorization and authentication and why = people >>>>>> need to stop confusing the two. >>>>>>=20 >>>>>> Oh wait... >>>>>>=20 >>>>>>=20 >>>>>> On Oct 16, 2014, at 1:06 PM, Hans Zandbelt >>>>>> wrote: >>>>>>=20 >>>>>>> About the write-up: at the end of the metaphor section it says: >>>>>>> "These recipes each add a number of items, such as a common = profile >>>>>>> API, to OAuth to create an authorization protocol." >>>>>>>=20 >>>>>>> whereas I believe that should read "to create an authentication >>>>>>> protocol" >>>>>>>=20 >>>>>>> Hans. >>>>>>>=20 >>>>>>> On 10/16/14, 6:54 PM, Hannes Tschofenig wrote: >>>>>>>> Participants: >>>>>>>>=20 >>>>>>>> * Brian Campbell >>>>>>>> * John Bradley >>>>>>>> * Derek Atkins >>>>>>>> * Phil Hunt >>>>>>>> * William Kim >>>>>>>> * Josh Mandel >>>>>>>> * Hannes Tschofenig >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Notes: >>>>>>>>=20 >>>>>>>> Justin distributed a draft writeup and explained the reasoning = behind >>>>>>>> it. The intended purpose is to put the write-up (after enough >>>>>>>> review) on >>>>>>>> oauth.net. See attachments. Justin solicited feedback from the >>>>>>>> conference call participants and from the working group. >>>>>>>>=20 >>>>>>>> One discussion item was specifically related to the concept of = audience >>>>>>>> restrictions, which comes in two flavours: (a) restriction of = the >>>>>>>> access >>>>>>>> token regarding the resource server and (b) restriction of the = id token >>>>>>>> regarding the client. Obviously, it is necessary to have both = of these >>>>>>>> audience restrictions in place and to actually check them. >>>>>>>>=20 >>>>>>>> The group then went into a discussion about the use of = pseudonyms in >>>>>>>> authentication and the problems deployments ran into when they = used >>>>>>>> pseudonyms together with a wide range of attributes that = identified >>>>>>>> users nevertheless. Phil suggested to produce a write-up about = this >>>>>>>> topic. >>>>>>>>=20 >>>>>>>> Finally, the group started a discussion about potential actions = for the >>>>>>>> OAuth working groups. Two activities were mentioned, namely to = produce >>>>>>>> an IETF draft of the write-up Justin has prepared as a "formal" >>>>>>>> response >>>>>>>> to the problems with authentication using OAuth and, as a = second topic, >>>>>>>> potential re-chartering of the OAuth working group to work on = some >>>>>>>> solutions in this area. Hannes suggested to postpone these = discussions >>>>>>>> and to first finish the write-up Justin had distributed. >>>>>>>>=20 >>>>>>>> Ciao >>>>>>>> Hannes & Derek >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>=20 >>>>>>>=20 >>>>>>> -- >>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>> hzandbelt@pingidentity.com | Ping Identity >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>=20 >>>>>=20 >>>>=20 >>>> -- >>>> Hans Zandbelt | Sr. Technical Architect >>>> hzandbelt@pingidentity.com | Ping Identity >>>=20 >>=20 >> --=20 >> Hans Zandbelt | Sr. Technical Architect >> hzandbelt@pingidentity.com | Ping Identity >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Mon Oct 20 13:14:13 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B75C1ACDD0 for ; Mon, 20 Oct 2014 13:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rDa2k7V1KTBf for ; Mon, 20 Oct 2014 13:14:06 -0700 (PDT) Received: from na3sys009aog105.obsmtp.com (na3sys009aog105.obsmtp.com [74.125.149.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F02021ACDAF for ; Mon, 20 Oct 2014 13:14:02 -0700 (PDT) Received: from mail-ie0-f170.google.com ([209.85.223.170]) (using TLSv1) by na3sys009aob105.postini.com ([74.125.148.12]) with SMTP ID DSNKVEVtCpuBZ6GflIu/0jrCqW4KRKrguJX/@postini.com; Mon, 20 Oct 2014 13:14:03 PDT Received: by mail-ie0-f170.google.com with SMTP id rd18so5538639iec.15 for ; Mon, 20 Oct 2014 13:14:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=iK1cpOQz1IC7uVOyzQxteuRDumdHNygULhmOmjYZjGY=; b=mu/i2Oa8XYUAAdjrYsqvqo2d+VQL7WX6vHjlimIbxp0lqyQTl8rV2D6V17FhPdsynb kGkyyYzBYgQijiXtWr3g/yUPjxS+ASBdgEHA/jJXY4onNUGbfuw90HpgoMKYB0hklEXH 2VNYx9MU2yxd0VQD7h4301rBB4HGbw/+VBYcSc8OulhGCYWpES2j04rOm2SMJRPiAq9I N21Lq9sfwgW0xAr4LR9HnJay6fWj7K6e+ld/di5gwpYkJJW4oJHjbx2neyU2O/5wiZE9 ie4opwPdYyA0x3iO5RCOW6886wvToQlm9XhmClWcuJXtF5ryepdhehtWUqKPCltc19es Uetg== X-Gm-Message-State: ALoCoQnyEfECGHpYTYADXah7oplgXxr1tAluiwRkICaKkpX2z4INsKxG33zo+dgUvCIPgMB5+Hm/Gn6YGrrilIAsODJcoMWJ4pQZORXG7Idgg6n3rHDmpW2p86A01omY1LuWg53+Gs/I X-Received: by 10.43.76.199 with SMTP id zf7mr4668953icb.57.1413836042248; Mon, 20 Oct 2014 13:14:02 -0700 (PDT) X-Received: by 10.43.76.199 with SMTP id zf7mr4668945icb.57.1413836042108; Mon, 20 Oct 2014 13:14:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.86.167 with HTTP; Mon, 20 Oct 2014 13:13:31 -0700 (PDT) In-Reply-To: References: <20141014182611.dd6598cc163e9c640d4167fd@nri.co.jp> <-1123724406662361791@unknownmsgid> <543ED519.3080902@gmail.com> From: Brian Campbell Date: Mon, 20 Oct 2014 14:13:31 -0600 Message-ID: To: Torsten Lodderstedt Content-Type: multipart/alternative; boundary=001a11c3b2520f9be90505e05b56 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/x23JmF-BoZ4kem-q7o4uTz5h24g Cc: oauth Subject: Re: [OAUTH-WG] SPOP - code verifier requirements X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 20:14:08 -0000 --001a11c3b2520f9be90505e05b56 Content-Type: text/plain; charset=UTF-8 In the default case, aren't the challenge and verifier just an arbitrary string value? One that would be application/x-www-form-urlencoded on the authorization request (http://tools.ietf.org/html/rfc6749#section-4.1.1) and token request (http://tools.ietf.org/html/rfc6749#section-4.1.3) like any other parameter value? If the client uses unreserved characters then no additional encoding is needed but I"m not sure I see any reason to restrict it. If a transform is used, I'd think that the transform defines how the octets are represented as strings. --001a11c3b2520f9be90505e05b56 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In the default case, aren't the challenge and ver= ifier just an arbitrary string value? One that would be application/x-www-f= orm-urlencoded on the authorization request (http://tools.ietf.org/html= /rfc6749#section-4.1.1) and token request (http://tools.ietf.org/ht= ml/rfc6749#section-4.1.3) like any other parameter value? If the client= uses unreserved characters then no additional encoding is needed but I&quo= t;m not sure I see any reason to restrict it.

If a transform i= s used, I'd think that the transform defines how the octets are represe= nted as strings.

=C2=A0=C2=A0
--001a11c3b2520f9be90505e05b56-- From nobody Mon Oct 20 13:26:01 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F13291ACE14 for ; Mon, 20 Oct 2014 13:25: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id up-v78jkj83O for ; Mon, 20 Oct 2014 13:25:54 -0700 (PDT) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 046321ACE06 for ; Mon, 20 Oct 2014 13:25:53 -0700 (PDT) Received: by mail-lb0-f176.google.com with SMTP id p9so4481127lbv.7 for ; Mon, 20 Oct 2014 13:25:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=R42cfRLUKlh/5yQZ3lcoxVzp7LPqwRK5xYHit2mwc7E=; b=LvF/Q9JnfzO5XVg5jsS+9TtIaAvKrdA8rnbIVos8NkOYbTXucRoYOD/pcbXxGHsIYF NN95ODUOY5tYG9BKV1wDS31In5sAqLPxefenVt7pD1zbk4o4ZTSo8MjJLAaVNlt07N4/ kzFe6Rfq3iR7PfBdhH68kQZvSDQ/fN2M3EHp+cnnDayTN4pKuVmSb/GkB8HgBD5bxFHK PXMwx2VEIndTvnWe1JIjmCaE425/uCF+OcyvfIwIwf/o6EJqkc1hVmmOmnAm/LAcbOjb 5fzGin18MjK3xPTUZjsL7rdNMFcgenO/oHmH/WGtDeVnsmgFPnp2rOqVXbqaKnW//8Pt 6u8w== MIME-Version: 1.0 X-Received: by 10.112.54.162 with SMTP id k2mr29746120lbp.63.1413836752190; Mon, 20 Oct 2014 13:25:52 -0700 (PDT) Received: by 10.112.166.7 with HTTP; Mon, 20 Oct 2014 13:25:52 -0700 (PDT) In-Reply-To: References: <20141014182611.dd6598cc163e9c640d4167fd@nri.co.jp> <-1123724406662361791@unknownmsgid> <543ED519.3080902@gmail.com> Date: Mon, 20 Oct 2014 15:25:52 -0500 Message-ID: From: Nat Sakimura To: Brian Campbell Content-Type: multipart/alternative; boundary=001a11c3eeee6287610505e085e3 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/_I43bqyKbiXd2TjK7rwxfkDFxGY Cc: oauth Subject: Re: [OAUTH-WG] SPOP - code verifier requirements X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 20:25:57 -0000 --001a11c3eeee6287610505e085e3 Content-Type: text/plain; charset=UTF-8 So, for the default case, the intent was to use just the unreserved chars, i.e., code_verifier = code_challenge = 16*128unreserved unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" In sha256 case, I would expect the transform to conform to the constraint: i.e., define such a transform so that the end result expressed in code_verifier and code_challenge would be expressed in unreserved. Nat 2014-10-20 15:13 GMT-05:00 Brian Campbell : > In the default case, aren't the challenge and verifier just an arbitrary > string value? One that would be application/x-www-form-urlencoded on the > authorization request (http://tools.ietf.org/html/rfc6749#section-4.1.1) > and token request (http://tools.ietf.org/html/rfc6749#section-4.1.3) like > any other parameter value? If the client uses unreserved characters then no > additional encoding is needed but I"m not sure I see any reason to restrict > it. > > If a transform is used, I'd think that the transform defines how the > octets are represented as strings. > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001a11c3eeee6287610505e085e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
So, for the default case, the intent was to use just the u= nreserved chars, i.e.,=C2=A0

code_verifier =3D =C2=A0code_challenge =3D= 16*128unreserved
unreserv= ed=C2=A0 =C2=A0 =3D ALPHA / DIGIT / "-" / "." / "_= " / "~"

In sha256 case, I would expect the tran= sform to conform to the constraint: i.e., define such a transform=C2=A0
s= o that the end result expressed in code_verifier and code_challenge would b= e expressed in unreserved.=C2=A0

Nat

2014-10-20 15:13 GMT-05:00 = Brian Campbell <bcampbell@pingidentity.com>:
In the default case, aren= 't the challenge and verifier just an arbitrary string value? One that = would be application/x-www-form-urlencoded on the authorization request (http://tools.ietf.org/html/rfc6749#section-4.1.1) and token request (= http://tools.ietf.org/html/rfc6749#section-4.1.3) like any other pa= rameter value? If the client uses unreserved characters then no additional = encoding is needed but I"m not sure I see any reason to restrict it.
If a transform is used, I'd think that the transform define= s how the octets are represented as strings.

=C2=A0=C2=A0
=

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




--
Nat Saki= mura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
--001a11c3eeee6287610505e085e3-- From nobody Mon Oct 20 13:34:14 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA86D1ACE2F for ; Mon, 20 Oct 2014 13:34:12 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6tmA2wf9ladu for ; Mon, 20 Oct 2014 13:34:10 -0700 (PDT) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B9261ACE29 for ; Mon, 20 Oct 2014 13:34:10 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id i17so4404821qcy.13 for ; Mon, 20 Oct 2014 13:34:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=IEJANpDURMMDJ2xuWetDo7D18gDY36+mMfcfkgo7y1I=; b=cBBJzfmEstHKgeUgdkuVE7XM7p1AR4NWuTQ0sYkPRdUF0bz0LMAEdt5ITcLORWCN5c /8hvlfUDWeT6p7pwjKo9aAjjHccA3wFxD/mbR6/paA9pgWXj3CY7Y8m2hBzVHas/GEAt bO7ihw5FrXA798lvdzfgkdxyXKD3Q9/vaks8b0g6rYLc/S2Ac8MScPHMlLd0GCKNbiCq sd0DSeiEZHKKpWqOKREDeW7W4q+PsmsP7XRq9wLyscEKTcHlarZgQGmq+X5XiPIZ4Lhi vLs+yPXeDv26z7Rw1tM/e3bNQHbDtNl8IAPCL0EdUaXZeUM2l9TYDQQv6AUhgfJBXYWz O5jQ== X-Gm-Message-State: ALoCoQnYDsX2vAeT1rfpv/2Ynbbtt+mjDYRBZCoVOIPLWaXtkX3czXJvtDV9UaspVPTLcMfJcAFd X-Received: by 10.224.98.212 with SMTP id r20mr4722847qan.31.1413837249261; Mon, 20 Oct 2014 13:34:09 -0700 (PDT) Received: from [192.168.1.216] (186-79-82-5.baf.movistar.cl. [186.79.82.5]) by mx.google.com with ESMTPSA id n46sm8814828qgn.9.2014.10.20.13.34.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 20 Oct 2014 13:34:08 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_FCB63C65-E0EF-4490-BF5C-F58BDC4400CB" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Bradley In-Reply-To: Date: Mon, 20 Oct 2014 17:33:47 -0300 Message-Id: References: <20141014182611.dd6598cc163e9c640d4167fd@nri.co.jp> <-1123724406662361791@unknownmsgid> <543ED519.3080902@gmail.com> To: Brian Campbell X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/pvZ_Q9n-rMRlr_UVLYWWxuwCEiM Cc: oauth Subject: Re: [OAUTH-WG] SPOP - code verifier requirements X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 20:34:12 -0000 --Apple-Mail=_FCB63C65-E0EF-4490-BF5C-F58BDC4400CB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Yes for the default case it is a simple string comparison, so not such = a big issue. It might still be possible to cause it to break by using a binary value = and letting the underlying libraries do the encoding on the two calls to = the authorization server. They might possibly use different escaping, = or the server might unescape one back to binary and use the escaped = version on the other input causing the comparison to fail. I agree that base64url encoding is probably the safest for = interoperability but will add a bit of processing on the client in the = default case that might not be necessary if the verifier value is = already URL safe by some other mechanism. Given a desire to make a SHA256 transform MTI for servers, standardizing = on base64url encoding of the values seems to make sense. John B. On Oct 20, 2014, at 5:13 PM, Brian Campbell = wrote: > In the default case, aren't the challenge and verifier just an = arbitrary string value? One that would be = application/x-www-form-urlencoded on the authorization request = (http://tools.ietf.org/html/rfc6749#section-4.1.1) and token request = (http://tools.ietf.org/html/rfc6749#section-4.1.3) like any other = parameter value? If the client uses unreserved characters then no = additional encoding is needed but I"m not sure I see any reason to = restrict it. >=20 > If a transform is used, I'd think that the transform defines how the = octets are represented as strings.=20 >=20 > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_FCB63C65-E0EF-4490-BF5C-F58BDC4400CB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Yes = for the default case it is a simple string comparison,  so not such = a big issue.

It might still be possible to cause it = to break by using a binary value and letting the underlying libraries do = the encoding on the two calls to the authorization server.  They = might possibly use different escaping,  or the server might = unescape one back to binary and use the escaped version on the other = input causing the comparison to fail.

I agree = that base64url encoding is probably the safest for interoperability but = will add a bit of processing on the client in the default case that = might not be necessary if the verifier value is already URL safe by some = other mechanism.

Given a desire to make a = SHA256 transform MTI for servers, standardizing on base64url encoding of = the values seems to make sense.

John = B.


On Oct 20, 2014, at 5:13 PM, = Brian Campbell <bcampbell@pingidentity.com&= gt; wrote:

In the default case, aren't the = challenge and verifier just an arbitrary string value? One that would be = application/x-www-form-urlencoded on the authorization request (http://tools.ietf.org/html/rfc6749#section-4.1.1) = and token request (http://tools.ietf.org/html/rfc6749#section-4.1.3) = like any other parameter value? If the client uses unreserved characters = then no additional encoding is needed but I"m not sure I see any reason = to restrict it.

If a transform is used, I'd think that the = transform defines how the octets are represented as strings. =

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

= --Apple-Mail=_FCB63C65-E0EF-4490-BF5C-F58BDC4400CB-- From nobody Mon Oct 20 13:54:33 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0FB21ACE82 for ; Mon, 20 Oct 2014 13:54:31 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IPay3vFiVLPw for ; Mon, 20 Oct 2014 13:54:29 -0700 (PDT) Received: from mail-qg0-f45.google.com (mail-qg0-f45.google.com [209.85.192.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 312A21A0105 for ; Mon, 20 Oct 2014 13:54:29 -0700 (PDT) Received: by mail-qg0-f45.google.com with SMTP id q107so4129721qgd.32 for ; Mon, 20 Oct 2014 13:54:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=nttqzaXADXEfS3X2RPa+0yy1MioKSTZI3o6GOvyhkvI=; b=UTuJOFjWCCESKg2R5BrOFcQ4eKyq7ptkZ6QdpucxDf+zRiqwrfl6h4egck0lJ41dvL 09Si7Kt7jPiX5xEJ7yBEFkYzr9VviQOgz9Y6j2C5RReoDZPb8EGyz9RgQtrt6Kxst3JR eyu8RbBqbYtkli7g3WH4aVPFBeOT06p1/cmzyqDaH8C9E/2wPu/A2sl1Lf1MlpcUF5OA IFbKWtfBdsz/lMFBkeQaSOb38HZguSHflgVRIsoY6q3+m8CMVqqLC0cgcSb+qc/TdWFo jJa0KrbnGmkXhSkqCVxiOzu6JqGvDQivXIPtsK2P0orIjDHEXDrRHptFkAB+YUC9BEtc XdZg== X-Gm-Message-State: ALoCoQkiUKJHfhsR0leT7nQqDeNfjzVZdwkJdSA0c7H8HVEvFwPp7LWN7kmhcdia38kbztrAvHVW X-Received: by 10.224.98.212 with SMTP id r20mr4867575qan.31.1413838468315; Mon, 20 Oct 2014 13:54:28 -0700 (PDT) Received: from [192.168.1.216] (186-79-82-5.baf.movistar.cl. [186.79.82.5]) by mx.google.com with ESMTPSA id g94sm8870079qgd.0.2014.10.20.13.54.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 20 Oct 2014 13:54:27 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_95A1DDE6-B6C9-4C61-9436-2EA07EA5F3A8" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Bradley In-Reply-To: Date: Mon, 20 Oct 2014 17:54:10 -0300 Message-Id: <1ECAA5B4-186D-47F2-90B6-756483801A50@ve7jtb.com> References: <20141014182611.dd6598cc163e9c640d4167fd@nri.co.jp> <-1123724406662361791@unknownmsgid> <543ED519.3080902@gmail.com> To: Nat Sakimura X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/f-kaWILQUzxzwa8RKW10HfAIedE Cc: oauth Subject: Re: [OAUTH-WG] SPOP - code verifier requirements X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 20:54:32 -0000 --Apple-Mail=_95A1DDE6-B6C9-4C61-9436-2EA07EA5F3A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Part of the issue is that we want people to use a good source of entropy = for this. PRNG on the device seems like the most likely thing. Those = generally give you a an array of bytes. Yes you could use anything to make them URL safe but that happens to be = precisely what base64url is intended for. =20 So while it is true that they could come up with some other way to do = it, likely that is the result of doing something stupid around = generating the values like using a fixed string with a counter. In the default mode the AS is just doing a string compare so what the = client uses to encode the string the string is probably not relevant to = the server. =20 Saying that the client MUST send a URL safe value vs letting it be = encoded by the http lib is I think important for interoperability. For the SHA256 version we are adding base64url encoding for both the = hash and the string seem the best choice as well. John B. On Oct 20, 2014, at 5:25 PM, Nat Sakimura wrote: > So, for the default case, the intent was to use just the unreserved = chars, i.e.,=20 >=20 > code_verifier =3D code_challenge =3D 16*128unreserved > unreserved =3D ALPHA / DIGIT / "-" / "." / "_" / "~" >=20 > In sha256 case, I would expect the transform to conform to the = constraint: i.e., define such a transform=20 > so that the end result expressed in code_verifier and code_challenge = would be expressed in unreserved.=20 >=20 > Nat >=20 > 2014-10-20 15:13 GMT-05:00 Brian Campbell = : > In the default case, aren't the challenge and verifier just an = arbitrary string value? One that would be = application/x-www-form-urlencoded on the authorization request = (http://tools.ietf.org/html/rfc6749#section-4.1.1) and token request = (http://tools.ietf.org/html/rfc6749#section-4.1.3) like any other = parameter value? If the client uses unreserved characters then no = additional encoding is needed but I"m not sure I see any reason to = restrict it. >=20 > If a transform is used, I'd think that the transform defines how the = octets are represented as strings.=20 >=20 > =20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 >=20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_95A1DDE6-B6C9-4C61-9436-2EA07EA5F3A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Part = of the issue is that we want people to use a good source of entropy for = this.   PRNG on the device seems like the most likely thing. =  Those generally give you a an array of = bytes.

Yes you could use anything to make them URL = safe but that happens to be precisely what base64url is intended for. =  

So while it is true that they could come = up with some other way to do it, likely that is the result of doing = something stupid around generating the values like using a fixed string = with a counter.

In the default mode the AS is = just doing a string compare so what the client uses to encode the string = the string is probably not relevant to the server.   =  

Saying that the client MUST send a URL = safe value vs letting it be encoded by the http lib is I think important = for interoperability.

For the SHA256 version we = are adding base64url encoding for both the hash and the string seem the = best choice as well.

John = B.

On Oct 20, 2014, at 5:25 PM, Nat Sakimura = <sakimura@gmail.com> = wrote:

So, for the default case, the intent was = to use just the unreserved chars, i.e., 

code_verifier =3D =  code_challenge =3D 16*128unreserved
unreserved  =   =3D ALPHA / DIGIT / "-" / "." / "_" / = "~"

In sha256 = case, I would expect the transform to conform to the constraint: i.e., = define such a transform 
so that the end = result expressed in code_verifier and code_challenge would be expressed = in unreserved. 

Nat

2014-10-20 = 15:13 GMT-05:00 Brian Campbell <bcampbell@pingidentity.com>:
In the default case, aren't the challenge = and verifier just an arbitrary string value? One that would be = application/x-www-form-urlencoded on the authorization request (http://tools.ietf.org/html/rfc6749#section-4.1.1) = and token request (http://tools.ietf.org/html/rfc6749#section-4.1.3) = like any other parameter value? If the client uses unreserved characters = then no additional encoding is needed but I"m not sure I see any reason = to restrict it.

If a transform is used, I'd think that the = transform defines how the octets are represented as strings. =

  

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




--
Nat = Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
_______________________________________________
OAuth mailing = list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth

= --Apple-Mail=_95A1DDE6-B6C9-4C61-9436-2EA07EA5F3A8-- From nobody Mon Oct 20 14:22:29 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56F7D1ACEEB for ; Mon, 20 Oct 2014 14:22:27 -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, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1j0-syItiKu for ; Mon, 20 Oct 2014 14:22:24 -0700 (PDT) Received: from mail-qg0-f49.google.com (mail-qg0-f49.google.com [209.85.192.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7EAA1ACEE5 for ; Mon, 20 Oct 2014 14:22:23 -0700 (PDT) Received: by mail-qg0-f49.google.com with SMTP id e89so4105718qgf.8 for ; Mon, 20 Oct 2014 14:22:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=hHGukQ47TmZ8AprISfyo15beO38kg3e/AduNaJEgEac=; b=Vead+MwpMeREW2j85sxbVoP/3WLa1LksYvBfdz08x0mcBtEal3PwwVKAmp0D1Du0B1 255VoU8J4ml8gow3GZyutyGkc3us5MwAUSBdGAAayC4zW6TFltPfWIK2w6187KcblXBd io67HkgzHbK8l2wGhGPRDlllZ/Po2VBtRUVvuGfRHVkL2a/aswN/zvLuGUCSG4nd5x/F TVhzr3V0puifKicVXmKGFBaXVI4jZgqTqLaOE7BNyDM39GDccKe69wiX8rBJSFBcHnxB rLQEGdsg61c5YBJPkP1ew8H9vz7U7ywK7Ap+rwA1hTzGz/V/X0a09qufuVRFGZGqwWPq /EuQ== X-Gm-Message-State: ALoCoQkAR7sHSAN/UWcTo1YAsvsQjD00/iQvGxyE8bT/ZY3sJqBAkxNfOu/be0iuDXKmAqbmO1xc X-Received: by 10.140.40.239 with SMTP id x102mr8719867qgx.69.1413840142929; Mon, 20 Oct 2014 14:22:22 -0700 (PDT) Received: from [192.168.1.216] (186-79-82-5.baf.movistar.cl. [186.79.82.5]) by mx.google.com with ESMTPSA id 68sm5804101qgj.34.2014.10.20.14.22.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 20 Oct 2014 14:22:22 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Bradley In-Reply-To: <81C330CB-0B07-4E70-ABBF-F47E5AEA4CF5@oracle.com> Date: Mon, 20 Oct 2014 18:22:16 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <8917DA32-1E14-4256-B093-A7BDFB36DF8E@ve7jtb.com> References: <543FF850.6070409@gmx.net> <543FFB13.2060903@pingidentity.com> <5440373F.9090601@pingidentity.com> <5445577D.4050207@pingidentity.com> <4198EC12-ED03-4ED8-AAD3-3555E34C7EA2@mitre.org> <5445609B.70607@pingidentity.com> <5659AE3D-7BC0-407C-9A0B-9FE112348815@mitre.org> <81C330CB-0B07-4E70-ABBF-F47E5AEA4CF5@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/bINBHpMAjtup7a7eCnu5vbqwSwk Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference Call X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 21:22:27 -0000 Even in the simple code use case there are things that need to be = profiled. 1. The resource owner must be the only one who can grant AT for the = profile resource. (This may not be true for general purpose API or = require a special api call) 2. OAuth allows a fair flexibility around redirect uri matching with = confidential clients. "code" can be intercepted and replayed to the = client. The redirect_uri matching rules need to be tightened up like = Connect has done. Oauth assumes that a third party can't use code to = get to the protected resource because of the client secret, for an = identity service replaying code to the client is an attack. (Oauth mitigates this by sending the redirect_uri in the request to the = token endpoint, but exact matching of that URI including query = parameters is not necessarily treated with sufficient diligence by = implementations only thinking about authorization. 3. There is no real authentication context so the clieent has no idea = when the user authenticated or how etc. There are probably other things but re-using an existing data API for = authentication may go seriously wrong even in this case without a fairly = sophisticated analysis.=20 John B. On Oct 20, 2014, at 5:06 PM, Phil Hunt wrote: > The problem is you are making a lot of assumptions that may or may not = be true - they are just generally true. >=20 > The right to access may be granted without even authenticating a user. = For example, a web resource might allow any registered client to have = acess to any resource. Only certain scopes require consent. For = example, readProfile is public, but updateProfile is restricted. >=20 > The presumption that receiving an AT would be entirely false in this = situation as the user was never even authenticated because consent was = not required. >=20 > We=92ve also talked about how access to a resource /Me also binds the = name of the authenticate user to the access request. If the API does = not have a /Me endpoint, than the identity information you are = requesting could be for any person the AT is allowed to see. This = creates another =93hack=94 point where clients could be fooled to = thinking they have authenticate a particular person when in fact all = they have proven is access it a particular resource not necessarily the = user is valid. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 > On Oct 20, 2014, at 12:29 PM, Richer, Justin P. = wrote: >=20 >> Right, when you get the AT directly from the token endpoint and it's = good for something, that will *probably* tell you the user is logged in. = This is assuming that the authentication context can also be = communicated, audience restrictions can be communicated, and all the = other good stuff the document talks about. A real problem tends to stem = from clients who will take access tokens from various public endpoints = and use them directly (implicit clients are inherently open to this = problem). Or that an access token can have a life long past the = authentication event, so if a client saves the access token off = someplace, does a bunch of work, then finally asks "Who's there?" and = makes the user info API call, it's going to get info but not necessarily = what it assumes.=20 >>=20 >> Really, all of this is why there's the ID Token and the Signed = Request components in OIDC and FBC, respectively. Plus you don't always = want the profile information on every request, so having something the = client can read directly saves a round trip to fetch data it doesn't = really want. Having the separation between the authentication context = and the profile information really does make the code paths a bit = simpler. >>=20 >> -- Justin >>=20 >> On Oct 20, 2014, at 3:20 PM, Hans Zandbelt = wrote: >>=20 >>> My point is that it *is* a guarantee if the AT just came to the = client in a code flow; I don't see a problem with that although clients = have to be aware of what they're doing and not allow any other flows for = this. >>>=20 >>> Hans. >>>=20 >>> On 10/20/14, 9:04 PM, Richer, Justin P. wrote: >>>> This is actually one of the sticky bits that I've tried to address = in the document itself -- I've seen apps that assume that if they're = given an access token that can be used to fetch profile information then = the user is actually there. This isn't actually a guarantee, but it's = commonly true enough that developers get lazy and rely on it. >>>>=20 >>>> -- Justin >>>>=20 >>>>=20 >>>> On Oct 20, 2014, at 2:42 PM, Hans Zandbelt = wrote: >>>>=20 >>>>> or pointier: there are OAuth 2.0 deployments today that offer = login semantics because they have a REST/JSON user profile API that can = be accessed using the AT that was obtained in a code flow; should that = be acknowledged in the doc? >>>>>=20 >>>>> Hans. >>>>>=20 >>>>> On 10/16/14, 11:23 PM, Hans Zandbelt wrote: >>>>>> a deployment-related question that I have around this topic: >>>>>>=20 >>>>>> it seems that authentication using OAuth 2.0 is possible today = for >>>>>> confidential clients using the code flow, with a registered >>>>>> redirect_uri, not consuming/storing/using refresh_tokens, and = assuming >>>>>> that there's an API that returns user identity info in JSON = format and >>>>>> the claim that uniquely identifies the user is known by the = client. >>>>>>=20 >>>>>> The usage/presence of the short-lived code in this scenario/flow >>>>>> guarantees that the user has just authenticated, and the audience = issue >>>>>> is covered by the fact that the code (thus the access_token in = the token >>>>>> endpoint response) are bound to the confidential client, all as = per >>>>>> standard OAuth 2.0 semantics. >>>>>>=20 >>>>>> 2 questions about that: >>>>>> - is this right or am I overlooking some security/semantics = issues here >>>>>> - if right, would it make sense to acknowledge that or is that = muddying >>>>>> the waters even more (the current text does seem to only = implicitly >>>>>> acknowledge this) >>>>>>=20 >>>>>> There may be value in acknowledging this because the majority of = OAuth >>>>>> 2.0 OPs exposing a userinfo-like API would adhere to a REST = GET+JSON >>>>>> response anyhow [1] thus achieving login semantics with plain = OAuth 2.0 >>>>>> and a bit of common practice wrt. the user info API. >>>>>>=20 >>>>>> Thanks for the excellent write-up! >>>>>>=20 >>>>>> Hans. >>>>>>=20 >>>>>> PS: I've been asked this concrete question about Spotify's OAuth = 2.0 >>>>>> support and in fact I'm able to configure Spotify as an IDP to my = OIDC >>>>>> client with a minor workaround to abstain from expecting an = id_token in >>>>>> the token endpoint response, but calling the Spotify specific = user info >>>>>> endpoint like it was a standards-compliant OpenID Connect = endpoint. (the >>>>>> client has a per-OP configurable unique user id claim name = anyhow). >>>>>>=20 >>>>>> On 10/16/14, 7:27 PM, Richer, Justin P. wrote: >>>>>>> Ah yes, good catch! If only someone would put up a webpage = describing >>>>>>> the difference between authorization and authentication and why = people >>>>>>> need to stop confusing the two. >>>>>>>=20 >>>>>>> Oh wait... >>>>>>>=20 >>>>>>>=20 >>>>>>> On Oct 16, 2014, at 1:06 PM, Hans Zandbelt >>>>>>> wrote: >>>>>>>=20 >>>>>>>> About the write-up: at the end of the metaphor section it says: >>>>>>>> "These recipes each add a number of items, such as a common = profile >>>>>>>> API, to OAuth to create an authorization protocol." >>>>>>>>=20 >>>>>>>> whereas I believe that should read "to create an authentication >>>>>>>> protocol" >>>>>>>>=20 >>>>>>>> Hans. >>>>>>>>=20 >>>>>>>> On 10/16/14, 6:54 PM, Hannes Tschofenig wrote: >>>>>>>>> Participants: >>>>>>>>>=20 >>>>>>>>> * Brian Campbell >>>>>>>>> * John Bradley >>>>>>>>> * Derek Atkins >>>>>>>>> * Phil Hunt >>>>>>>>> * William Kim >>>>>>>>> * Josh Mandel >>>>>>>>> * Hannes Tschofenig >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Notes: >>>>>>>>>=20 >>>>>>>>> Justin distributed a draft writeup and explained the reasoning = behind >>>>>>>>> it. The intended purpose is to put the write-up (after enough >>>>>>>>> review) on >>>>>>>>> oauth.net. See attachments. Justin solicited feedback from the >>>>>>>>> conference call participants and from the working group. >>>>>>>>>=20 >>>>>>>>> One discussion item was specifically related to the concept of = audience >>>>>>>>> restrictions, which comes in two flavours: (a) restriction of = the >>>>>>>>> access >>>>>>>>> token regarding the resource server and (b) restriction of the = id token >>>>>>>>> regarding the client. Obviously, it is necessary to have both = of these >>>>>>>>> audience restrictions in place and to actually check them. >>>>>>>>>=20 >>>>>>>>> The group then went into a discussion about the use of = pseudonyms in >>>>>>>>> authentication and the problems deployments ran into when they = used >>>>>>>>> pseudonyms together with a wide range of attributes that = identified >>>>>>>>> users nevertheless. Phil suggested to produce a write-up about = this >>>>>>>>> topic. >>>>>>>>>=20 >>>>>>>>> Finally, the group started a discussion about potential = actions for the >>>>>>>>> OAuth working groups. Two activities were mentioned, namely to = produce >>>>>>>>> an IETF draft of the write-up Justin has prepared as a = "formal" >>>>>>>>> response >>>>>>>>> to the problems with authentication using OAuth and, as a = second topic, >>>>>>>>> potential re-chartering of the OAuth working group to work on = some >>>>>>>>> solutions in this area. Hannes suggested to postpone these = discussions >>>>>>>>> and to first finish the write-up Justin had distributed. >>>>>>>>>=20 >>>>>>>>> Ciao >>>>>>>>> Hannes & Derek >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> OAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>> -- >>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>> hzandbelt@pingidentity.com | Ping Identity >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>> -- >>>>> Hans Zandbelt | Sr. Technical Architect >>>>> hzandbelt@pingidentity.com | Ping Identity >>>>=20 >>>=20 >>> --=20 >>> Hans Zandbelt | Sr. Technical Architect >>> hzandbelt@pingidentity.com | Ping Identity >>=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 From nobody Mon Oct 20 14:23:42 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF2D21ACEEB for ; Mon, 20 Oct 2014 14:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mMakaapgGykw for ; Mon, 20 Oct 2014 14:23:37 -0700 (PDT) Received: from na3sys009aog113.obsmtp.com (na3sys009aog113.obsmtp.com [74.125.149.209]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CDC71ACEE2 for ; Mon, 20 Oct 2014 14:23:37 -0700 (PDT) Received: from mail-ie0-f178.google.com ([209.85.223.178]) (using TLSv1) by na3sys009aob113.postini.com ([74.125.148.12]) with SMTP ID DSNKVEV9WM280QQH2iZjiqH4NvssTjG5O7JL@postini.com; Mon, 20 Oct 2014 14:23:37 PDT Received: by mail-ie0-f178.google.com with SMTP id rl12so5647164iec.37 for ; Mon, 20 Oct 2014 14:23:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=EDpoBllxA06Haxz36ex+xrYeAgbHFJoDl7I3CRRpJa8=; b=Cy1zU3hVTAztroAxB9ZebPbLZvXR+Jy0dgN4ukCrBVFV9cOU/eBVA0dfiFdCtXYC+v SL3Lb0WSA2T+D3w9jhHgb/o40LZcx0OFnW1TKWTneb9FCDcKd/u0TnzMTXv5nhMgTodh DcNvlWr/YADakIiQtRuvBcPWt8i2Tzr6mynsSW/Lnh4nUEG1De+GrtasrT2dGnYFtx8I KRvWCGd9COqTo8JQs37AZKkBub40PaVTDDJ6CTazYyjth6ZUldE6IkRUT8zSfswa/5cQ 6Xy1bdGG+FRFIJZhLUZt8EY3AUp9Alcc9TRvJ82mZ+ubbCjgVL24c7h+5OxGvx8mLUCG zmWQ== X-Gm-Message-State: ALoCoQlmaqJIO59h7PtW20yK4VycqYr5yt0GxLckF3uKJFWMKluiUFxZ+L+sd0SiVD6f52My1PiYLiKyeCGCwObp6VJPu/h40fJdVY/oz0OPm5DlJUXA4reZE75YsF+34Kml3QU5a0Mm X-Received: by 10.50.164.194 with SMTP id ys2mr21474856igb.43.1413840216643; Mon, 20 Oct 2014 14:23:36 -0700 (PDT) X-Received: by 10.50.164.194 with SMTP id ys2mr21474846igb.43.1413840216501; Mon, 20 Oct 2014 14:23:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.86.167 with HTTP; Mon, 20 Oct 2014 14:23:06 -0700 (PDT) In-Reply-To: <1ECAA5B4-186D-47F2-90B6-756483801A50@ve7jtb.com> References: <20141014182611.dd6598cc163e9c640d4167fd@nri.co.jp> <-1123724406662361791@unknownmsgid> <543ED519.3080902@gmail.com> <1ECAA5B4-186D-47F2-90B6-756483801A50@ve7jtb.com> From: Brian Campbell Date: Mon, 20 Oct 2014 15:23:06 -0600 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=089e0149d116dfccff0505e15389 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/ZFuZP1RQZHzBYAaBxtpfA05mjf4 Cc: oauth Subject: Re: [OAUTH-WG] SPOP - code verifier requirements X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 21:23:41 -0000 --089e0149d116dfccff0505e15389 Content-Type: text/plain; charset=UTF-8 That all makes sense. And yeah, our AS side implementation just does a string compare. I'd just really like to keep that compliant as the spec gets updated. But being tighter about what the client can send doesn't change anything there. If the concern is about people using a good source of entropy, then something to that effect should probably be said directly. On Mon, Oct 20, 2014 at 2:54 PM, John Bradley wrote: > Part of the issue is that we want people to use a good source of entropy > for this. PRNG on the device seems like the most likely thing. Those > generally give you a an array of bytes. > > Yes you could use anything to make them URL safe but that happens to be > precisely what base64url is intended for. > > So while it is true that they could come up with some other way to do it, > likely that is the result of doing something stupid around generating the > values like using a fixed string with a counter. > > In the default mode the AS is just doing a string compare so what the > client uses to encode the string the string is probably not relevant to the > server. > > Saying that the client MUST send a URL safe value vs letting it be encoded > by the http lib is I think important for interoperability. > > For the SHA256 version we are adding base64url encoding for both the hash > and the string seem the best choice as well. > > John B. > > On Oct 20, 2014, at 5:25 PM, Nat Sakimura wrote: > > So, for the default case, the intent was to use just the unreserved chars, > i.e., > > code_verifier = code_challenge = 16*128unreserved > unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" > > In sha256 case, I would expect the transform to conform to the constraint: > i.e., define such a transform > so that the end result expressed in code_verifier and code_challenge would > be expressed in unreserved. > > Nat > > 2014-10-20 15:13 GMT-05:00 Brian Campbell : > >> In the default case, aren't the challenge and verifier just an arbitrary >> string value? One that would be application/x-www-form-urlencoded on the >> authorization request (http://tools.ietf.org/html/rfc6749#section-4.1.1) >> and token request (http://tools.ietf.org/html/rfc6749#section-4.1.3) >> like any other parameter value? If the client uses unreserved characters >> then no additional encoding is needed but I"m not sure I see any reason to >> restrict it. >> >> If a transform is used, I'd think that the transform defines how the >> octets are represented as strings. >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > > -- > Nat Sakimura (=nat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --089e0149d116dfccff0505e15389 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
That all makes sense. And yeah, our AS side implement= ation just does a string compare. I'd just really like to keep that com= pliant as the spec gets updated. But being tighter about what the client ca= n send doesn't change anything there.

If the concern is ab= out people using a good source of entropy, then something to that effect sh= ould probably be said directly.

On Mon, Oct 20, 2014 at 2:54 PM, John Bradley <ve= 7jtb@ve7jtb.com> wrote:
Part of the issue is that we want people t= o use a good source of entropy for this. =C2=A0 PRNG on the device seems li= ke the most likely thing.=C2=A0 Those generally give you a an array of byte= s.

Yes you could use anything to make them URL safe but = that happens to be precisely what base64url is intended for. =C2=A0

So while it is true that they could come up with some oth= er way to do it, likely that is the result of doing something stupid around= generating the values like using a fixed string with a counter.
=
In the default mode the AS is just doing a string compare so= what the client uses to encode the string the string is probably not relev= ant to the server. =C2=A0 =C2=A0

Saying that the c= lient MUST send a URL safe value vs letting it be encoded by the http lib i= s I think important for interoperability.

For the = SHA256 version we are adding base64url encoding for both the hash and the s= tring seem the best choice as well.

John B.
<= div>

On Oct 20, 2014, at 5:25 PM, Nat S= akimura <sakimur= a@gmail.com> wrote:

So, for the default case, the intent was to use just the unreserved cha= rs, i.e.,=C2=A0

code_verifier =3D =C2=A0code_challenge =3D 16*128unrese= rved
unreserved=C2=A0 =C2= =A0 =3D ALPHA / DIGIT / "-" / "." / "_" / &qu= ot;~"

In sha256 case, I would expect the transform to con= form to the constraint: i.e., define such a transform=C2=A0
so that the e= nd result expressed in code_verifier and code_challenge would be expressed = in unreserved.=C2=A0

Nat

2014-10-20 15:13 GMT-05:00 Brian Campbel= l <bcampbell@pingidentity.com>:
In the default case, aren't the challenge and ve= rifier just an arbitrary string value? One that would be application/x-www-= form-urlencoded on the authorization request (http://tools.ietf.org/htm= l/rfc6749#section-4.1.1) and token request (http://tools.ietf.org/h= tml/rfc6749#section-4.1.3) like any other parameter value? If the clien= t uses unreserved characters then no additional encoding is needed but I&qu= ot;m not sure I see any reason to restrict it.

If a transform = is used, I'd think that the transform defines how the octets are repres= ented as strings.

=C2=A0=C2=A0

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




--
Nat Saki= mura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
_______________________________________________
OAuth mailing list
OAuth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth


--089e0149d116dfccff0505e15389-- From nobody Mon Oct 20 14:32:53 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D2E21A00B7 for ; Mon, 20 Oct 2014 14:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.909 X-Spam-Level: X-Spam-Status: No, score=-0.909 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, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 RNLr8gF6-Yi0 for ; Mon, 20 Oct 2014 14:32:48 -0700 (PDT) Received: from nm23-vm1.bullet.mail.bf1.yahoo.com (nm23-vm1.bullet.mail.bf1.yahoo.com [98.139.213.141]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E82FE1ACEEE for ; Mon, 20 Oct 2014 14:32:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1413840766; bh=Ry4gwfF00wa68tjKMtaKDJPZl74aQv9hhXmaC2nhXkA=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=k5VflIA9CZ7TpsYVTqHGX8aZOzeF/v9HDcVwTw2KomAi2TV+Kh5XKyfMhHZP024e85fV/WTyk3rznegOAvyQJgldpay5/t/icqYtTgKVeUMqHNsYNTumSLJwVpODWy7TTGscqzN9U/LEVY52JOplV5BQtmnATesPsORKZg4zYqk0v1BnuXuN8hknOECgArEPj328Y1fEDrbZTFjkPutNlR9m6mqbfwTQGyPX1PPCPtCv4vp5yhhLZ1pib/Tkk0pS9fGmvm3J0G5C5zoGx4MDXOgDpX9ZlmU8LY07PTN3G9xd1CtC3FY++kEDdquL6lgIGk5wLtuUyjEqQE6ewdP6SA== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=XnT2hLQbjpblSWtHokPRCXRssFQ94UD5FCIoIBOzRN2nHFRvM1Zh07BdKyNpEd04A1walho6WXe3D0kJyr524dVZ8fjIl2vHee8zeyboXSB4kkKDRCyRCeQ8H7VptD4JUvcubDn8Sp63z3Qb0aSwreFTEwNPPRxgxLrItUKrp3tsCJJSZc/DgcJKxA12FcDK90PiRxi3VDhmdgsuZ0vQ8hBsDZrIYGVVATm/7qKolld71dt64DDJm15XEn3qIBPs4DMVO9+gV2pwnOFkgM04P+l08wTPItDHuif1ZcVR9cQut1laNVDx8TvZPBBUBPU6riFiUvBNn6Zk9r45lT0wfA==; Received: from [66.196.81.170] by nm23.bullet.mail.bf1.yahoo.com with NNFMP; 20 Oct 2014 21:32:46 -0000 Received: from [98.139.212.216] by tm16.bullet.mail.bf1.yahoo.com with NNFMP; 20 Oct 2014 21:32:46 -0000 Received: from [127.0.0.1] by omp1025.mail.bf1.yahoo.com with NNFMP; 20 Oct 2014 21:32:46 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 860521.88929.bm@omp1025.mail.bf1.yahoo.com X-YMail-OSG: xd70SQwVM1nQFDYzqukcDY.vUISvGzBYeDirY6eQIBYNeNFxVvE1IoLGH1.4u_h zQnBV6SSveWsOyC0vBrqDNCewVQ95KqLQXAJmUHXgBM1ZkyTuIwrM4oVDoxTdcj0giYa9WMS7u4S xDHcDT9SVZBWY0W3zN87gCxSkBWWPamYsSJ7V0ciY5yDmBHY7NOmaK.J3.6XnlgkTdE6w3GS.JFM IuU2p29tRLlSHJ4FESAX61zIWdE6QmJMkBm8MV6xNaIq21VWSgMs9tEP1.Z8JfIYCdfuT1q3D20c s3g8RhGvAkgNmZ35gX7pm0Gj7i9l34Kgvt4lYGxqjN0G81rCZncfrDrKY_yvbRZEc3GXvdIkjQ17 6QVuxzlyoE8da9r6U9yWYRCZfIRB41uZ5WqV5KH61N0euiCJHEL6mQ6F14iz.xmODHHwSgp32tH7 C7NeW.Rd.XLjOa8_kBLWBzenE0Zl60YLkuw55A5kDSMX88J_RXS.CKqVUvkPXLk0gytPR1kYm Date: Mon, 20 Oct 2014 21:32:45 +0000 (UTC) From: Bill Mills To: "Richer, Justin P." , Hans Zandbelt Message-ID: <1182779784.362137.1413840765847.JavaMail.yahoo@jws10660.mail.bf1.yahoo.com> In-Reply-To: <5659AE3D-7BC0-407C-9A0B-9FE112348815@mitre.org> References: <5659AE3D-7BC0-407C-9A0B-9FE112348815@mitre.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_362136_1298734115.1413840765839" Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/N--v60RvARrwQ0f4WTBPyFqqsK0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference Call X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 21:32:51 -0000 ------=_Part_362136_1298734115.1413840765839 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 on OIDC being an authentication solution, OAuth is authorization and the= pitfalls of using it as authN have been well hashed out. =C2=A0If people a= re still getting it wrong more guidance is needed.=20 On Monday, October 20, 2014 1:07 PM, "Richer, Justin P." wrote: =20 Right, when you get the AT directly from the token endpoint and it's good = for something, that will *probably* tell you the user is logged in. This is= assuming that the authentication context can also be communicated, audienc= e restrictions can be communicated, and all the other good stuff the docume= nt talks about. A real problem tends to stem from clients who will take acc= ess tokens from various public endpoints and use them directly (implicit cl= ients are inherently open to this problem). Or that an access token can hav= e a life long past the authentication event, so if a client saves the acces= s token off someplace, does a bunch of work, then finally asks "Who's there= ?" and makes the user info API call, it's going to get info but not necessa= rily what it assumes.=20 Really, all of this is why there's the ID Token and the Signed Request comp= onents in OIDC and FBC, respectively. Plus you don't always want the profil= e information on every request, so having something the client can read dir= ectly saves a round trip to fetch data it doesn't really want. Having the s= eparation between the authentication context and the profile information re= ally does make the code paths a bit simpler. -- Justin On Oct 20, 2014, at 3:20 PM, Hans Zandbelt wro= te: > My point is that it *is* a guarantee if the AT just came to the client in= a code flow; I don't see a problem with that although clients have to be a= ware of what they're doing and not allow any other flows for this. >=20 > Hans. >=20 > On 10/20/14, 9:04 PM, Richer, Justin P. wrote: >> This is actually one of the sticky bits that I've tried to address in th= e document itself -- I've seen apps that assume that if they're given an ac= cess token that can be used to fetch profile information then the user is a= ctually there. This isn't actually a guarantee, but it's commonly true enou= gh that developers get lazy and rely on it. >>=20 >>=C2=A0 -- Justin >>=20 >>=20 >> On Oct 20, 2014, at 2:42 PM, Hans Zandbelt = wrote: >>=20 >>> or pointier: there are OAuth 2.0 deployments today that offer login sem= antics because they have a REST/JSON user profile API that can be accessed = using the AT that was obtained in a code flow; should that be acknowledged = in the doc? >>>=20 >>> Hans. >>>=20 >>> On 10/16/14, 11:23 PM, Hans Zandbelt wrote: >>>> a deployment-related question that I have around this topic: >>>>=20 >>>> it seems that authentication using OAuth 2.0 is possible today for >>>> confidential clients using the code flow, with a registered >>>> redirect_uri, not consuming/storing/using refresh_tokens, and assuming >>>> that there's an API that returns user identity info in JSON format and >>>> the claim that uniquely identifies the user is known by the client. >>>>=20 >>>> The usage/presence of the short-lived code in this scenario/flow >>>> guarantees that the user has just authenticated, and the audience issu= e >>>> is covered by the fact that the code (thus the access_token in the tok= en >>>> endpoint response) are bound to the confidential client, all as per >>>> standard OAuth 2.0 semantics. >>>>=20 >>>> 2 questions about that: >>>> - is this right or am I overlooking some security/semantics issues her= e >>>> - if right, would it make sense to acknowledge that or is that muddyin= g >>>> the waters even more (the current text does seem to only implicitly >>>> acknowledge this) >>>>=20 >>>> There may be value in acknowledging this because the majority of OAuth >>>> 2.0 OPs exposing a userinfo-like API would adhere to a REST GET+JSON >>>> response anyhow [1] thus achieving login semantics with plain OAuth 2.= 0 >>>> and a bit of common practice wrt. the user info API. >>>>=20 >>>> Thanks for the excellent write-up! >>>>=20 >>>> Hans. >>>>=20 >>>> PS: I've been asked this concrete question about Spotify's OAuth 2.0 >>>> support and in fact I'm able to configure Spotify as an IDP to my OIDC >>>> client with a minor workaround to abstain from expecting an id_token i= n >>>> the token endpoint response, but calling the Spotify specific user inf= o >>>> endpoint like it was a standards-compliant OpenID Connect endpoint. (t= he >>>> client has a per-OP configurable unique user id claim name anyhow). >>>>=20 >>>> On 10/16/14, 7:27 PM, Richer, Justin P. wrote: >>>>> Ah yes, good catch! If only someone would put up a webpage describing >>>>> the difference between authorization and authentication and why peopl= e >>>>> need to stop confusing the two. >>>>>=20 >>>>> Oh wait... >>>>>=20 >>>>>=20 >>>>> On Oct 16, 2014, at 1:06 PM, Hans Zandbelt >>>>> wrote: >>>>>=20 >>>>>> About the write-up: at the end of the metaphor section it says: >>>>>> "These recipes each add a number of items, such as a common profile >>>>>> API, to OAuth to create an authorization protocol." >>>>>>=20 >>>>>> whereas I believe that should read "to create an authentication >>>>>> protocol" >>>>>>=20 >>>>>> Hans. >>>>>>=20 >>>>>> On 10/16/14, 6:54 PM, Hannes Tschofenig wrote: >>>>>>> Participants: >>>>>>>=20 >>>>>>>=C2=A0 * Brian Campbell >>>>>>>=C2=A0 * John Bradley >>>>>>>=C2=A0 * Derek Atkins >>>>>>>=C2=A0 * Phil Hunt >>>>>>>=C2=A0 * William Kim >>>>>>>=C2=A0 * Josh Mandel >>>>>>>=C2=A0 * Hannes Tschofenig >>>>>>>=20 >>>>>>>=20 >>>>>>> Notes: >>>>>>>=20 >>>>>>> Justin distributed a draft writeup and explained the reasoning behi= nd >>>>>>> it. The intended purpose is to put the write-up (after enough >>>>>>> review) on >>>>>>> oauth.net. See attachments. Justin solicited feedback from the >>>>>>> conference call participants and from the working group. >>>>>>>=20 >>>>>>> One discussion item was specifically related to the concept of audi= ence >>>>>>> restrictions, which comes in two flavours: (a) restriction of the >>>>>>> access >>>>>>> token regarding the resource server and (b) restriction of the id t= oken >>>>>>> regarding the client. Obviously, it is necessary to have both of th= ese >>>>>>> audience restrictions in place and to actually check them. >>>>>>>=20 >>>>>>> The group then went into a discussion about the use of pseudonyms i= n >>>>>>> authentication and the problems deployments ran into when they used >>>>>>> pseudonyms together with a wide range of attributes that identified >>>>>>> users nevertheless. Phil suggested to produce a write-up about this >>>>>>> topic. >>>>>>>=20 >>>>>>> Finally, the group started a discussion about potential actions for= the >>>>>>> OAuth working groups. Two activities were mentioned, namely to prod= uce >>>>>>> an IETF draft of the write-up Justin has prepared as a "formal" >>>>>>> response >>>>>>> to the problems with authentication using OAuth and, as a second to= pic, >>>>>>> potential re-chartering of the OAuth working group to work on some >>>>>>> solutions in this area. Hannes suggested to postpone these discussi= ons >>>>>>> and to first finish the write-up Justin had distributed. >>>>>>>=20 >>>>>>> Ciao >>>>>>> Hannes & Derek >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>=20 >>>>>>=20 >>>>>> -- >>>>>> Hans Zandbelt=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | Sr. = Technical Architect >>>>>> hzandbelt@pingidentity.com | Ping Identity >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>=20 >>>=20 >>> -- >>> Hans Zandbelt=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | Sr. Tec= hnical Architect >>> hzandbelt@pingidentity.com | Ping Identity >>=20 >=20 > --=20 > Hans Zandbelt=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | Sr. Techn= ical Architect > hzandbelt@pingidentity.com | Ping Identity _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------=_Part_362136_1298734115.1413840765839 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 on OIDC being an authenticat= ion solution, OAuth is authorization and the pitfalls of using it as authN = have been well hashed out.  If people are still getting it wrong more = guidance is needed.


=
On Monday, October 20, 2= 014 1:07 PM, "Richer, Justin P." <jricher@mitre.org> wrote:


Right, when you get the = AT directly from the token endpoint and it's good for something, that will = *probably* tell you the user is logged in. This is assuming that the authen= tication context can also be communicated, audience restrictions can be com= municated, and all the other good stuff the document talks about. A real pr= oblem tends to stem from clients who will take access tokens from various p= ublic endpoints and use them directly (implicit clients are inherently open= to this problem). Or that an access token can have a life long past the au= thentication event, so if a client saves the access token off someplace, do= es a bunch of work, then finally asks "Who's there?" and makes the user inf= o API call, it's going to get info but not necessarily what it assumes.
Really, all of this is why there's the ID Token and the Signed Request= components in OIDC and FBC, respectively. Plus you don't always want the p= rofile information on every request, so having something the client can rea= d directly saves a round trip to fetch data it doesn't really want. Having = the separation between the authentication context and the profile informati= on really does make the code paths a bit simpler.

-- Justin

= On Oct 20, 2014, at 3:20 PM, Hans Zandbelt <hzandbelt@p= ingidentity.com> wrote:

> My point is that it *is* a guara= ntee if the AT just came to the client in a code flow; I don't see a proble= m with that although clients have to be aware of what they're doing and not= allow any other flows for this.
>
> Hans.
>
> On= 10/20/14, 9:04 PM, Richer, Justin P. wrote:
>> This is actually o= ne of the sticky bits that I've tried to address in the document itself -- = I've seen apps that assume that if they're given an access token that can b= e used to fetch profile information then the user is actually there. This i= sn't actually a guarantee, but it's commonly true enough that developers ge= t lazy and rely on it.
>>
>>  -- Justin
>>=
>>
>> On Oct 20, 2014, at 2:42 PM, Hans Zandbelt <<= a ymailto=3D"mailto:hzandbelt@pingidentity.com" href=3D"mailto:hzandbelt@pi= ngidentity.com">hzandbelt@pingidentity.com> wrote:
>>
&= gt;>> or pointier: there are OAuth 2.0 deployments today that offer l= ogin semantics because they have a REST/JSON user profile API that can be a= ccessed using the AT that was obtained in a code flow; should that be ackno= wledged in the doc?
>>>
>>> Hans.
>>> =
>>> On 10/16/14, 11:23 PM, Hans Zandbelt wrote:
>>>= ;> a deployment-related question that I have around this topic:
>&= gt;>>
>>>> it seems that authentication using OAuth 2= .0 is possible today for
>>>> confidential clients using the= code flow, with a registered
>>>> redirect_uri, not consumi= ng/storing/using refresh_tokens, and assuming
>>>> that ther= e's an API that returns user identity info in JSON format and
>>&g= t;> the claim that uniquely identifies the user is known by the client.<= br>>>>>
>>>> The usage/presence of the short-li= ved code in this scenario/flow
>>>> guarantees that the user= has just authenticated, and the audience issue
>>>> is cove= red by the fact that the code (thus the access_token in the token
>&g= t;>> endpoint response) are bound to the confidential client, all as = per
>>>> standard OAuth 2.0 semantics.
>>>> <= br>>>>> 2 questions about that:
>>>> - is this r= ight or am I overlooking some security/semantics issues here
>>>= ;> - if right, would it make sense to acknowledge that or is that muddyi= ng
>>>> the waters even more (the current text does seem to = only implicitly
>>>> acknowledge this)
>>>> <= br>>>>> There may be value in acknowledging this because the ma= jority of OAuth
>>>> 2.0 OPs exposing a userinfo-like API wo= uld adhere to a REST GET+JSON
>>>> response anyhow [1] thus = achieving login semantics with plain OAuth 2.0
>>>> and a bi= t of common practice wrt. the user info API.
>>>>
>&g= t;>> Thanks for the excellent write-up!
>>>>
>&= gt;>> Hans.
>>>>
>>>> PS: I've been as= ked this concrete question about Spotify's OAuth 2.0
>>>> su= pport and in fact I'm able to configure Spotify as an IDP to my OIDC
>= ;>>> client with a minor workaround to abstain from expecting an i= d_token in
>>>> the token endpoint response, but calling the= Spotify specific user info
>>>> endpoint like it was a stan= dards-compliant OpenID Connect endpoint. (the
>>>> client ha= s a per-OP configurable unique user id claim name anyhow).
>>>&= gt;
>>>> On 10/16/14, 7:27 PM, Richer, Justin P. wrote:
= >>>>> Ah yes, good catch! If only someone would put up a web= page describing
>>>>> the difference between authorizatio= n and authentication and why people
>>>>> need to stop co= nfusing the two.
>>>>>
>>>>> Oh wait..= .
>>>>>
>>>>>
>>>>>= On Oct 16, 2014, at 1:06 PM, Hans Zandbelt
>>>>> <hzandbelt@pingidentity.com> wrote:
>>>>= >
>>>>>> About the write-up: at the end of the met= aphor section it says:
>>>>>> "These recipes each add = a number of items, such as a common profile
>>>>>> API= , to OAuth to create an authorization protocol."
>>>>>>= ;
>>>>>> whereas I believe that should read "to creat= e an authentication
>>>>>> protocol"
>>>&g= t;>>
>>>>>> Hans.
>>>>>> <= br>>>>>>> On 10/16/14, 6:54 PM, Hannes Tschofenig wrote:<= br>>>>>>>> Participants:
>>>>>>&g= t;
>>>>>>>  * Brian Campbell
>>>&= gt;>>>  * John Bradley
>>>>>>>  = * Derek Atkins
>>>>>>>  * Phil Hunt
>>= ;>>>>>  * William Kim
>>>>>>>&n= bsp; * Josh Mandel
>>>>>>>  * Hannes Tschofeni= g
>>>>>>>
>>>>>>>
>= >>>>>> Notes:
>>>>>>>
>>= ;>>>>> Justin distributed a draft writeup and explained the = reasoning behind
>>>>>>> it. The intended purpose i= s to put the write-up (after enough
>>>>>>> review)= on
>>>>>>> oauth.net. See attachments. Justin soli= cited feedback from the
>>>>>>> conference call par= ticipants and from the working group.
>>>>>>>
&= gt;>>>>>> One discussion item was specifically related to= the concept of audience
>>>>>>> restrictions, whic= h comes in two flavours: (a) restriction of the
>>>>>>= > access
>>>>>>> token regarding the resource se= rver and (b) restriction of the id token
>>>>>>> re= garding the client. Obviously, it is necessary to have both of these
>= ;>>>>>> audience restrictions in place and to actually ch= eck them.
>>>>>>>
>>>>>>> = The group then went into a discussion about the use of pseudonyms in
>= ;>>>>>> authentication and the problems deployments ran i= nto when they used
>>>>>>> pseudonyms together with= a wide range of attributes that identified
>>>>>>>= users nevertheless. Phil suggested to produce a write-up about this
>= ;>>>>>> topic.
>>>>>>>
>&g= t;>>>>> Finally, the group started a discussion about potent= ial actions for the
>>>>>>> OAuth working groups. T= wo activities were mentioned, namely to produce
>>>>>>= > an IETF draft of the write-up Justin has prepared as a "formal"
>= ;>>>>>> response
>>>>>>> to the p= roblems with authentication using OAuth and, as a second topic,
>>= >>>>> potential re-chartering of the OAuth working group to = work on some
>>>>>>> solutions in this area. Hannes= suggested to postpone these discussions
>>>>>>> an= d to first finish the write-up Justin had distributed.
>>>>&= gt;>>
>>>>>>> Ciao
>>>>>&g= t;> Hannes & Derek
>>>>>>>
>>>&= gt;>>>
>>>>>>>
>>>>>&g= t;> _______________________________________________
>>>>&= gt;>> OAuth mailing list
>>>>>>> OAuth@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/oaut= h
>>>>>>>
>>>>>>
>= >>>>> --
>>>>>> Hans Zandbelt  &nb= sp;           | Sr. Technical Architect
>>= ;>>>> hzandbelt@pingidentity.com | Ping Id= entity
>>>>>>
>>>>>> ___________= ____________________________________
>>>>>> OAuth mail= ing list
>>>>>> OAuth@ietf.org
>>>>>>= ; https://www.ietf.org/mailman/listinfo/oauth
>>>>> >>>>
>>>
>>> --
>>> Han= s Zandbelt              | Sr. Technical = Architect
>>> hzandbelt@pingidentity.com |= Ping Identity
>>
>
> --
> Hans Zandbelt = ;             | Sr. Technical Architect
&g= t; hzandbelt@pingidentity.com | Ping Identity

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


------=_Part_362136_1298734115.1413840765839-- From nobody Mon Oct 20 14:34:03 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F3401ACEF4 for ; Mon, 20 Oct 2014 14:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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_REMOTE_IMAGE=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TE-uldU6Q-6C for ; Mon, 20 Oct 2014 14:34:00 -0700 (PDT) Received: from nm37-vm0.bullet.mail.bf1.yahoo.com (nm37-vm0.bullet.mail.bf1.yahoo.com [72.30.238.200]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFD681A00B7 for ; Mon, 20 Oct 2014 14:33:59 -0700 (PDT) Received: from [98.139.212.151] by nm37.bullet.mail.bf1.yahoo.com with NNFMP; 20 Oct 2014 21:33:58 -0000 Received: from [98.139.212.204] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 20 Oct 2014 21:33:58 -0000 Received: from [127.0.0.1] by omp1013.mail.bf1.yahoo.com with NNFMP; 20 Oct 2014 21:33:58 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 895400.4020.bm@omp1013.mail.bf1.yahoo.com Received: (qmail 19746 invoked by uid 60001); 20 Oct 2014 21:33:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1413840838; bh=/TBpgqY4qulV7SRyilE6vyzTjMctJo/S97wSTqd8Um8=; h=Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=0Cn6VQLbf27yrRSeuT458NneBNG00PiXgr2hL7XzbEM9QIfFVlRMjYxlRztg8++Aniw7AEhm/n00pmsS0emONR1lCfXpl9DU9wlnlk/tAWJnl9Vl3Ju/vjYibIQcvBMtJ2dfXLqJXM246wWl3bN64aN8EBWWX7S24Rhck604WfI= X-YMail-OSG: qWWREz0VM1nB0.iicEq4SOHZIocfWcxoO85GwKisAOcfi5e NkqTaTdX_EX0jwz0VDwAq4LaUK0oIptXOKq2fw5GdQWUrkQjNemu0ppJTO7f .e53fruEPKVVmai1xB31rJvs4bXNIXukxmr33U3vSWAqDVE87YR_s1Zz8.Cb yItfnI0mvyuQWrsE_GmMzAFrf_PLp5Y82prCdIsUEB7LRGCVCgbqPStBVObH aGHUqwLxCssY5vikJ2d9SWeGZS_ZgrHvyvBji4PK9k.o61hGrMUfk5Ssf3_f taQKM3pGm6VVfJPy.6t4twJHu8yHzc7gsxz7hA1xHJoqJ6UE_twhG7UBYN6t CQUZuQzHqrLIEuXEfLuCiKmmWoE8kTWuRqL4kPg6lcaSA32jv2bepbrmJ2Ij Q7Nf_W1qYjmHT3u0lvIFkKSipogPqmTS61ECWNbN6tsUnZMixibsG_KBFv4a gSRpYxnONjLWekonMKWX7U2gQEV74v.6kasSNJ4PPpg.BLPi4zqtXUqHSPP2 lsGJjjqZJV8OsR9vLQMYLV9dzaHfHhKnkSlCNMsOKtOurSQp.hIFbpeCGyLg IFGWf51REiBdyIltZ1ixN_oGuJzeYzhe2WrmddUtQLfKE.5WA1nK8uy57ynI DDKUAI_Mofg3QKUrU7JDKJM_umiyX3vjNNdYhd2zXyG.oziK0syPVSAiYZaB YNbE4cKAsQletfkUahda1M2Wi1oydlFbzlxE3.C5LmgBmqr1COnrWpLPrXEM xm0OH3dlP5HDZJCNOzQiFLjYo5nicfPnKgNpGYRn4K4_oAaQ3cPtJB1mDMwS mzsuP4EHXGvwK3L5_DIH23pFrEgW0I3r.PuQJBZzKgizIukENVShz6zq27hq cIUPAMH_Gjqloo5bQmMSGQVELWexRd6et.xkUway3zKLtWDyV_pO1ZtUVjSl x2ZJkAyyplE1OWlAbZw3RM3nwbku8ByHI5nx2Ci25NNxi.JxhGBf_vK6IkNV FFyaM5i7TtUHW91w6ZJb04gC9g8r_AwVPNRCse7WqdGowmHr6059mOmc1DDK wry.Y3SNrfQ-- Received: from [207.140.43.23] by web141001.mail.bf1.yahoo.com via HTTP; Mon, 20 Oct 2014 14:33:58 PDT X-Rocket-MIMEInfo: 002.001, CgpJIHdhcyBsb29raW5nIGZvciAiZGV2aWNlIGZsb3ciIHJlY2VudGx5IHRoYXQgd2FzIHByZXNlbnQgaW4gdmVyc2lvbnMgMDUgYW5kIDA2LCBidXQgY291bGQgbm90IGZpbmQgYW55dGhpbmcgZXhjZXB0IGFuIG9sZCBmcm9tIEVyYW4gbWVzc2FnZSBiZWxvdy4gSGFzIGl0IGJlZW4gbW92ZWQgYW55d2hlcmUgZWxzZSBhcyBFcmFuIGhhcyBtZW50aW9uZWQgYmVsb3c_IFBsZWFzZSBwcm92aWRlIGEgcG9pbnRlciBpZiBzby4gCgoKSSBjb3VsZCBzZWUgdGhhdCBHb29nbGUgc3RpbGwgdXNlcyBpdDogVXNpbmcBMAEBAQE- X-Mailer: YahooMailWebService/0.8.203.733 Message-ID: <1413840838.90013.YahooMailNeo@web141001.mail.bf1.yahoo.com> Date: Mon, 20 Oct 2014 14:33:58 -0700 From: Oleg Gryb To: "oauth@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1278998794-477991545-1413840838=:90013" Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/FbuFy8xiiUZs0wRHU_xGQeq9yLs Subject: [OAUTH-WG] Where is Device Flow Now ? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Oleg Gryb List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 21:34:02 -0000 --1278998794-477991545-1413840838=:90013 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable =0A=0AI was looking for "device flow" recently that was present in versions= 05 and 06, but could not find anything except an old from Eran message bel= ow. Has it been moved anywhere else as Eran has mentioned below? Please pro= vide a pointer if so. =0A=0A=0AI could see that Google still uses it: Using= OAuth 2.0 for Devices - Google Accounts Authentication and Authorization = =E2=80=94 Google Developers =0A =0A =0AUsing OAuth 2.0 for Dev= ices - Google Accounts Authentica...=0AThis document is for you if: You are= writing an installed app for a platform other than Android or iOS, and = =0AView on developers.google.com Preview by Yahoo =0A =0A=0ASorry, if I'v= e missed anything,=0A=0A=0AOleg=0A=0A=3D=3D=3D=3D Old Message From Eran =3D= =3D=3D=3D=0A=0A=0AOAUTH-WG] Device flow to move to an extension=0A_________= _______________________=0A =0A=09* From: Eran Hammer-Lahav =0A=09* To: "OAuth WG (oauth at ietf.org)" =0A= =09* Date: Fri, 11 Jun 2010 08:33:27 -0700=0A______________________________= __=0A =0AUnlike the rest of the flows, the device flow lacks deployment exp= erience and is still likely to change. It also uses a very different archit= ecture than the rest of the flows (which becomes more obvious in my -07 rew= rite). Unless there is strong objection, I am going to remove it from the c= ore spec and republish it as a new draft. In general, I am going to iterate= through the spec in the next couple weeks and move unstable (and non-essen= tial) features out to extension specs. EHL =0A_____________________________= ___ --1278998794-477991545-1413840838=:90013 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


I was looking for "device flow" recently that was pr= esent in versions 05 and 06, but could not find anything except an old from= Eran message below. Has it been moved anywhere else as Eran has mentioned = below? Please provide a pointer if so.

=
 
 
3D"image"
 
 
 
 
 
<= span class=3D"link-enhancr-element icon icon-close link-enhancr-delete">
This document is for y= ou if: You are writing an installed app for a platform other than Android o= r iOS, and
View = on = developers.google.com
 
<= /td>

Sorry, if I've missed anythi= ng,

Oleg

=3D=3D=3D=3D Old Message From E= ran =3D=3D=3D=3D

OAUTH-WG] Device flo= w to move to an extension

=0A
=0A=0A=0A=0A=0A=0A
=0A=0A= =0A
Unlike the rest of the flows, the device flow=
 lacks deployment experience and is still likely to change. It also uses a =
very different architecture than the rest of the flows (which becomes more =
obvious in my -07 rewrite). Unless there is strong objection, I am going to=
 remove it from the core spec and republish it as a new draft.=0A=0AIn gene=
ral, I am going to iterate through the spec in the next couple weeks and mo=
ve unstable (and non-essential) features out to extension specs.=0A=0AEHL=
=0A
=0A=0A=0A=0A
<= br class=3D"" style=3D"">
--1278998794-477991545-1413840838=:90013-- From nobody Mon Oct 20 14:47:36 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA6291ACF11 for ; Mon, 20 Oct 2014 14:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ybYVXcxUFVeO for ; Mon, 20 Oct 2014 14:47:21 -0700 (PDT) Received: from na3sys009aog129.obsmtp.com (na3sys009aog129.obsmtp.com [74.125.149.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF25A1ACF0E for ; Mon, 20 Oct 2014 14:47:20 -0700 (PDT) Received: from mail-wg0-f46.google.com ([74.125.82.46]) (using TLSv1) by na3sys009aob129.postini.com ([74.125.148.12]) with SMTP ID DSNKVEWC6Egd62KqOyZwsiFM3cDOU/sKzm4P@postini.com; Mon, 20 Oct 2014 14:47:21 PDT Received: by mail-wg0-f46.google.com with SMTP id l18so6418955wgh.17 for ; Mon, 20 Oct 2014 14:47:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=/I884qjqispVsLF6vkh7X9U8svIBTfA9Q9etumoQHDo=; b=Mh1OI3MHb9iGFPZh4644UvTzGl4XOK3gDk0yL7tn/2z9K45zlBgP8M8h8/19sBFgDb 8PT4XRUf0zNj6kl6tbxp5wHig3UXiw5zxlO5LTNm/2UAfpDn25mVc08pBECvrUjC+HEq LD05QlQSnBtJ6ls5TUW1OQb5qIJSzYryooaFtp9NuqmxKrhOdj71We6uvmenNp1qCGUF 3eLlYltd9rvByZnRofrL+UodSMah/DDphMYM43FmBZBC7gYxIDoF6Nbark7Eq8xhtJDL S+Fw2WfJZRGpntR2nwXc9E4IYMX9A+wgyl+AOfy1NhClNlv0wYCtZDcdWCYvRDRdohWj irHw== X-Gm-Message-State: ALoCoQkdpTPuUdNaA8sDzdrgzfW6r8lg8Ycns08JeEV46eBLA3SW9VfWMY1IYYk05ywT9YrGGbGq3R1+qnETumzxQqE06So7M3te+8wr2sQd+TM/JMIvX/8xpJtJz98NBZtHB1mnIU57 X-Received: by 10.180.72.241 with SMTP id g17mr24201690wiv.31.1413841639360; Mon, 20 Oct 2014 14:47:19 -0700 (PDT) X-Received: by 10.180.72.241 with SMTP id g17mr24201684wiv.31.1413841639219; Mon, 20 Oct 2014 14:47:19 -0700 (PDT) Received: from [192.168.53.160] ([86.188.131.84]) by mx.google.com with ESMTPSA id 10sm13218817wjs.21.2014.10.20.14.47.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 20 Oct 2014 14:47:18 -0700 (PDT) Message-ID: <544582E4.6060506@pingidentity.com> Date: Mon, 20 Oct 2014 23:47:16 +0200 From: Hans Zandbelt User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John Bradley , Phil Hunt References: <543FF850.6070409@gmx.net> <543FFB13.2060903@pingidentity.com> <5440373F.9090601@pingidentity.com> <5445577D.4050207@pingidentity.com> <4198EC12-ED03-4ED8-AAD3-3555E34C7EA2@mitre.org> <5445609B.70607@pingidentity.com> <5659AE3D-7BC0-407C-9A0B-9FE112348815@mitre.org> <81C330CB-0B07-4E70-ABBF-F47E5AEA4CF5@oracle.com> <8917DA32-1E14-4256-B093-A7BDFB36DF8E@ve7jtb.com> In-Reply-To: <8917DA32-1E14-4256-B093-A7BDFB36DF8E@ve7jtb.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/iMKqSejBwSNFFr1y6nMen2W3g48 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference Call X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 21:47:29 -0000 I agree with the considerations, but I also feel that they are generally true for 3rd party clients to services where the resource owner has an account/profile. 1. typically the case for a /me (read) profile API 2. best practice after earlier exploits 3. the "code" has a recommended lifetime of 10 minutes by spec I also agree that because there are a number of conditions that need to be met (even though generally true as Phil says) as such it may be wise not to spell out this scenario with the risk of becoming "best" practice. I am not really advocating for this anyway, it just struck me that authz/authn really overlap here (admittedly as a "special" case). Hans. On 10/20/14, 11:22 PM, John Bradley wrote: > Even in the simple code use case there are things that need to be profiled. > > 1. The resource owner must be the only one who can grant AT for the profile resource. (This may not be true for general purpose API or require a special api call) > > 2. OAuth allows a fair flexibility around redirect uri matching with confidential clients. "code" can be intercepted and replayed to the client. The redirect_uri matching rules need to be tightened up like Connect has done. Oauth assumes that a third party can't use code to get to the protected resource because of the client secret, for an identity service replaying code to the client is an attack. > (Oauth mitigates this by sending the redirect_uri in the request to the token endpoint, but exact matching of that URI including query parameters is not necessarily treated with sufficient diligence by implementations only thinking about authorization. > > 3. There is no real authentication context so the clieent has no idea when the user authenticated or how etc. > > There are probably other things but re-using an existing data API for authentication may go seriously wrong even in this case without a fairly sophisticated analysis. > > John B. > > > On Oct 20, 2014, at 5:06 PM, Phil Hunt wrote: > >> The problem is you are making a lot of assumptions that may or may not be true - they are just generally true. >> >> The right to access may be granted without even authenticating a user. For example, a web resource might allow any registered client to have acess to any resource. Only certain scopes require consent. For example, readProfile is public, but updateProfile is restricted. >> >> The presumption that receiving an AT would be entirely false in this situation as the user was never even authenticated because consent was not required. >> >> Weve also talked about how access to a resource /Me also binds the name of the authenticate user to the access request. If the API does not have a /Me endpoint, than the identity information you are requesting could be for any person the AT is allowed to see. This creates another hack point where clients could be fooled to thinking they have authenticate a particular person when in fact all they have proven is access it a particular resource not necessarily the user is valid. >> >> Phil >> >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> >> >> >> On Oct 20, 2014, at 12:29 PM, Richer, Justin P. wrote: >> >>> Right, when you get the AT directly from the token endpoint and it's good for something, that will *probably* tell you the user is logged in. This is assuming that the authentication context can also be communicated, audience restrictions can be communicated, and all the other good stuff the document talks about. A real problem tends to stem from clients who will take access tokens from various public endpoints and use them directly (implicit clients are inherently open to this problem). Or that an access token can have a life long past the authentication event, so if a client saves the access token off someplace, does a bunch of work, then finally asks "Who's there?" and makes the user info API call, it's going to get info but not necessarily what it assumes. >>> >>> Really, all of this is why there's the ID Token and the Signed Request components in OIDC and FBC, respectively. Plus you don't always want the profile information on every request, so having something the client can read directly saves a round trip to fetch data it doesn't really want. Having the separation between the authentication context and the profile information really does make the code paths a bit simpler. >>> >>> -- Justin >>> >>> On Oct 20, 2014, at 3:20 PM, Hans Zandbelt wrote: >>> >>>> My point is that it *is* a guarantee if the AT just came to the client in a code flow; I don't see a problem with that although clients have to be aware of what they're doing and not allow any other flows for this. >>>> >>>> Hans. >>>> >>>> On 10/20/14, 9:04 PM, Richer, Justin P. wrote: >>>>> This is actually one of the sticky bits that I've tried to address in the document itself -- I've seen apps that assume that if they're given an access token that can be used to fetch profile information then the user is actually there. This isn't actually a guarantee, but it's commonly true enough that developers get lazy and rely on it. >>>>> >>>>> -- Justin >>>>> >>>>> >>>>> On Oct 20, 2014, at 2:42 PM, Hans Zandbelt wrote: >>>>> >>>>>> or pointier: there are OAuth 2.0 deployments today that offer login semantics because they have a REST/JSON user profile API that can be accessed using the AT that was obtained in a code flow; should that be acknowledged in the doc? >>>>>> >>>>>> Hans. >>>>>> >>>>>> On 10/16/14, 11:23 PM, Hans Zandbelt wrote: >>>>>>> a deployment-related question that I have around this topic: >>>>>>> >>>>>>> it seems that authentication using OAuth 2.0 is possible today for >>>>>>> confidential clients using the code flow, with a registered >>>>>>> redirect_uri, not consuming/storing/using refresh_tokens, and assuming >>>>>>> that there's an API that returns user identity info in JSON format and >>>>>>> the claim that uniquely identifies the user is known by the client. >>>>>>> >>>>>>> The usage/presence of the short-lived code in this scenario/flow >>>>>>> guarantees that the user has just authenticated, and the audience issue >>>>>>> is covered by the fact that the code (thus the access_token in the token >>>>>>> endpoint response) are bound to the confidential client, all as per >>>>>>> standard OAuth 2.0 semantics. >>>>>>> >>>>>>> 2 questions about that: >>>>>>> - is this right or am I overlooking some security/semantics issues here >>>>>>> - if right, would it make sense to acknowledge that or is that muddying >>>>>>> the waters even more (the current text does seem to only implicitly >>>>>>> acknowledge this) >>>>>>> >>>>>>> There may be value in acknowledging this because the majority of OAuth >>>>>>> 2.0 OPs exposing a userinfo-like API would adhere to a REST GET+JSON >>>>>>> response anyhow [1] thus achieving login semantics with plain OAuth 2.0 >>>>>>> and a bit of common practice wrt. the user info API. >>>>>>> >>>>>>> Thanks for the excellent write-up! >>>>>>> >>>>>>> Hans. >>>>>>> >>>>>>> PS: I've been asked this concrete question about Spotify's OAuth 2.0 >>>>>>> support and in fact I'm able to configure Spotify as an IDP to my OIDC >>>>>>> client with a minor workaround to abstain from expecting an id_token in >>>>>>> the token endpoint response, but calling the Spotify specific user info >>>>>>> endpoint like it was a standards-compliant OpenID Connect endpoint. (the >>>>>>> client has a per-OP configurable unique user id claim name anyhow). >>>>>>> >>>>>>> On 10/16/14, 7:27 PM, Richer, Justin P. wrote: >>>>>>>> Ah yes, good catch! If only someone would put up a webpage describing >>>>>>>> the difference between authorization and authentication and why people >>>>>>>> need to stop confusing the two. >>>>>>>> >>>>>>>> Oh wait... >>>>>>>> >>>>>>>> >>>>>>>> On Oct 16, 2014, at 1:06 PM, Hans Zandbelt >>>>>>>> wrote: >>>>>>>> >>>>>>>>> About the write-up: at the end of the metaphor section it says: >>>>>>>>> "These recipes each add a number of items, such as a common profile >>>>>>>>> API, to OAuth to create an authorization protocol." >>>>>>>>> >>>>>>>>> whereas I believe that should read "to create an authentication >>>>>>>>> protocol" >>>>>>>>> >>>>>>>>> Hans. >>>>>>>>> >>>>>>>>> On 10/16/14, 6:54 PM, Hannes Tschofenig wrote: >>>>>>>>>> Participants: >>>>>>>>>> >>>>>>>>>> * Brian Campbell >>>>>>>>>> * John Bradley >>>>>>>>>> * Derek Atkins >>>>>>>>>> * Phil Hunt >>>>>>>>>> * William Kim >>>>>>>>>> * Josh Mandel >>>>>>>>>> * Hannes Tschofenig >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Notes: >>>>>>>>>> >>>>>>>>>> Justin distributed a draft writeup and explained the reasoning behind >>>>>>>>>> it. The intended purpose is to put the write-up (after enough >>>>>>>>>> review) on >>>>>>>>>> oauth.net. See attachments. Justin solicited feedback from the >>>>>>>>>> conference call participants and from the working group. >>>>>>>>>> >>>>>>>>>> One discussion item was specifically related to the concept of audience >>>>>>>>>> restrictions, which comes in two flavours: (a) restriction of the >>>>>>>>>> access >>>>>>>>>> token regarding the resource server and (b) restriction of the id token >>>>>>>>>> regarding the client. Obviously, it is necessary to have both of these >>>>>>>>>> audience restrictions in place and to actually check them. >>>>>>>>>> >>>>>>>>>> The group then went into a discussion about the use of pseudonyms in >>>>>>>>>> authentication and the problems deployments ran into when they used >>>>>>>>>> pseudonyms together with a wide range of attributes that identified >>>>>>>>>> users nevertheless. Phil suggested to produce a write-up about this >>>>>>>>>> topic. >>>>>>>>>> >>>>>>>>>> Finally, the group started a discussion about potential actions for the >>>>>>>>>> OAuth working groups. Two activities were mentioned, namely to produce >>>>>>>>>> an IETF draft of the write-up Justin has prepared as a "formal" >>>>>>>>>> response >>>>>>>>>> to the problems with authentication using OAuth and, as a second topic, >>>>>>>>>> potential re-chartering of the OAuth working group to work on some >>>>>>>>>> solutions in this area. Hannes suggested to postpone these discussions >>>>>>>>>> and to first finish the write-up Justin had distributed. >>>>>>>>>> >>>>>>>>>> Ciao >>>>>>>>>> Hannes & Derek >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> OAuth mailing list >>>>>>>>>> OAuth@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>> hzandbelt@pingidentity.com | Ping Identity >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> OAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>> hzandbelt@pingidentity.com | Ping Identity >>>>> >>>> >>>> -- >>>> Hans Zandbelt | Sr. Technical Architect >>>> hzandbelt@pingidentity.com | Ping Identity >>> >>> _______________________________________________ >>> 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 | Sr. Technical Architect hzandbelt@pingidentity.com | Ping Identity From nobody Mon Oct 20 14:50:56 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D67B1ACF1B for ; Mon, 20 Oct 2014 14:50:55 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IU0JJk9KdHMw for ; Mon, 20 Oct 2014 14:50:52 -0700 (PDT) Received: from mail-qc0-f177.google.com (mail-qc0-f177.google.com [209.85.216.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 451B31ACF19 for ; Mon, 20 Oct 2014 14:50:52 -0700 (PDT) Received: by mail-qc0-f177.google.com with SMTP id c9so4456795qcz.22 for ; Mon, 20 Oct 2014 14:50:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=Wk1asCo1kjEMMKEpjFK55cMVes2KCzeIQnpJfPXCe8Y=; b=DmsJYwttGAQMl6ps58QWxPDloxUwrUsTeuTOp53SYxneo2e0Hyq5t4517nu97GxaU4 MrRFBVAwiuuS3SmhK+m4lr2ukvYG1ciz5iz1ZnbrcJogO7ehA/DSpYO7ZNY210UZDTf+ ZCk/aW/84/LrT8U+2NQu+9BggHq4m6jhhyaUihcXNlYc3yBIQmWlccpIr1pjKLKTPCEg 6yO22Yu7ZalA37F+6o1THuxKKHhuJ64k5NFkVIdU/FuEBr3EoTP6X4TmLsT6H0KD7aw6 jaj86pXXwqiRp/fB1yrviCvzzQwmkbr0WjAMXrEvI6JgAbE4Kzjpu90cK01aWW1bX9xK VO3w== X-Gm-Message-State: ALoCoQkJmY5/u5uGgaxyr6q5nNlHWZHe204hhjAS99fHLZZTH37+DCSQKncEMbdgpQhCwvl49fWT X-Received: by 10.224.62.20 with SMTP id v20mr24540602qah.87.1413841851342; Mon, 20 Oct 2014 14:50:51 -0700 (PDT) Received: from [192.168.1.216] (186-79-82-5.baf.movistar.cl. [186.79.82.5]) by mx.google.com with ESMTPSA id s95sm8980628qgs.12.2014.10.20.14.50.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 20 Oct 2014 14:50:50 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_82669F52-EE42-4D6D-8571-59E46B938634" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Bradley In-Reply-To: Date: Mon, 20 Oct 2014 18:50:45 -0300 Message-Id: <4A705EF2-AF75-4A75-AC3C-156DB851588F@ve7jtb.com> References: <20141014182611.dd6598cc163e9c640d4167fd@nri.co.jp> <-1123724406662361791@unknownmsgid> <543ED519.3080902@gmail.com> <1ECAA5B4-186D-47F2-90B6-756483801A50@ve7jtb.com> To: Brian Campbell X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/20fRR8qQu_2dLdBNREo8bYeiZGQ Cc: oauth Subject: Re: [OAUTH-WG] SPOP - code verifier requirements X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 21:50:55 -0000 --Apple-Mail=_82669F52-EE42-4D6D-8571-59E46B938634 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Saying that the string must be base64url encoded when sent to the AS = shouldn't impact any servers doing a string compare. Yes we are a touch vague about what constitutes high entropy. On Oct 20, 2014, at 6:23 PM, Brian Campbell = wrote: > That all makes sense. And yeah, our AS side implementation just does a = string compare. I'd just really like to keep that compliant as the spec = gets updated. But being tighter about what the client can send doesn't = change anything there. >=20 > If the concern is about people using a good source of entropy, then = something to that effect should probably be said directly.=20 >=20 > On Mon, Oct 20, 2014 at 2:54 PM, John Bradley = wrote: > Part of the issue is that we want people to use a good source of = entropy for this. PRNG on the device seems like the most likely thing. = Those generally give you a an array of bytes. >=20 > Yes you could use anything to make them URL safe but that happens to = be precisely what base64url is intended for. =20 >=20 > So while it is true that they could come up with some other way to do = it, likely that is the result of doing something stupid around = generating the values like using a fixed string with a counter. >=20 > In the default mode the AS is just doing a string compare so what the = client uses to encode the string the string is probably not relevant to = the server. =20 >=20 > Saying that the client MUST send a URL safe value vs letting it be = encoded by the http lib is I think important for interoperability. >=20 > For the SHA256 version we are adding base64url encoding for both the = hash and the string seem the best choice as well. >=20 > John B. >=20 > On Oct 20, 2014, at 5:25 PM, Nat Sakimura wrote: >=20 >> So, for the default case, the intent was to use just the unreserved = chars, i.e.,=20 >>=20 >> code_verifier =3D code_challenge =3D 16*128unreserved >> unreserved =3D ALPHA / DIGIT / "-" / "." / "_" / "~" >>=20 >> In sha256 case, I would expect the transform to conform to the = constraint: i.e., define such a transform=20 >> so that the end result expressed in code_verifier and code_challenge = would be expressed in unreserved.=20 >>=20 >> Nat >>=20 >> 2014-10-20 15:13 GMT-05:00 Brian Campbell = : >> In the default case, aren't the challenge and verifier just an = arbitrary string value? One that would be = application/x-www-form-urlencoded on the authorization request = (http://tools.ietf.org/html/rfc6749#section-4.1.1) and token request = (http://tools.ietf.org/html/rfc6749#section-4.1.3) like any other = parameter value? If the client uses unreserved characters then no = additional encoding is needed but I"m not sure I see any reason to = restrict it. >>=20 >> If a transform is used, I'd think that the transform defines how the = octets are represented as strings.=20 >>=20 >> =20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >>=20 >> --=20 >> Nat Sakimura (=3Dnat) >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 --Apple-Mail=_82669F52-EE42-4D6D-8571-59E46B938634 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Saying = that the string must be base64url encoded when sent to the AS shouldn't = impact any servers doing a string compare.

Yes we are = a touch vague about what constitutes high = entropy.


On Oct 20, 2014, at 6:23 = PM, Brian Campbell <bcampbell@pingidentity.com&= gt; wrote:

That all makes sense. And yeah, our = AS side implementation just does a string compare. I'd just really like = to keep that compliant as the spec gets updated. But being tighter about = what the client can send doesn't change anything there.

If = the concern is about people using a good source of entropy, then = something to that effect should probably be said directly. =

On = Mon, Oct 20, 2014 at 2:54 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
Part of the = issue is that we want people to use a good source of entropy for this. =   PRNG on the device seems like the most likely thing.  Those = generally give you a an array of bytes.

Yes you could = use anything to make them URL safe but that happens to be precisely what = base64url is intended for.  

So while it = is true that they could come up with some other way to do it, likely = that is the result of doing something stupid around generating the = values like using a fixed string with a = counter.

In the default mode the AS is just = doing a string compare so what the client uses to encode the string the = string is probably not relevant to the server.   =  

Saying that the client MUST send a URL = safe value vs letting it be encoded by the http lib is I think important = for interoperability.

For the SHA256 version we = are adding base64url encoding for both the hash and the string seem the = best choice as well.

John B.

On Oct 20, 2014, at 5:25 PM, Nat Sakimura = <sakimura@gmail.com> wrote:

So, for the default case, the intent was = to use just the unreserved chars, i.e., 

code_verifier =3D =  code_challenge =3D 16*128unreserved
unreserved  =   =3D ALPHA / DIGIT / "-" / "." / "_" / = "~"

In sha256 = case, I would expect the transform to conform to the constraint: i.e., = define such a transform 
so that the end = result expressed in code_verifier and code_challenge would be expressed = in unreserved. 

Nat

2014-10-20 = 15:13 GMT-05:00 Brian Campbell <bcampbell@pingidentity.com>:
In the default = case, aren't the challenge and verifier just an arbitrary string value? = One that would be application/x-www-form-urlencoded on the authorization = request (http://tools.ietf.org/html/rfc6749#section-4.1.1) = and token request (http://tools.ietf.org/html/rfc6749#section-4.1.3) = like any other parameter value? If the client uses unreserved characters = then no additional encoding is needed but I"m not sure I see any reason = to restrict it.

If a transform is used, I'd think that the = transform defines how the octets are represented as strings. =

  

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




--
Nat = Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
_______________________________________________
OAuth mailing = list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



= --Apple-Mail=_82669F52-EE42-4D6D-8571-59E46B938634-- From nobody Mon Oct 20 22:28:58 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F248F1AD05B for ; Mon, 20 Oct 2014 22:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 uaDJis9Jfrb3 for ; Mon, 20 Oct 2014 22:28:52 -0700 (PDT) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 595901AD052 for ; Mon, 20 Oct 2014 22:28:52 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id o8so355808qcw.17 for ; Mon, 20 Oct 2014 22:28:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=zjq6p5CAHsRUtJXTNnkRRVkaoeJFIR6Ymv78mS+uyvM=; b=HcW0XYREGI6ooLStemKVHZ95Olsdy5dTHAgribPno2GxdbqPFpn6z2dsEjhbUBjZMf aRDBWU12x6ZPvj0FXv+RETAi8agZWPgMByepCna/UWii+OmINnjanqYrddGhEfj70WF+ e1Vzq2wwCkD1bUpaZ6KLrN4iB/p0cC0CBBJP3WiJgkX5eSi3j+ho5TexEkfa25CIJOzy 1vHaEnObRiveptc+j4HrW7MZkkg1OoJkOi3VEcG9+AYlZ4O+SHc9Rm8JXluRUqYJm8lG 9xyR1bO4TxJ9U5DoKcPXqG7Kak+sz6Hab8CKTqK+/MmQaPIjDQgRrd1Yt6bNI7xd5+6/ PR7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=zjq6p5CAHsRUtJXTNnkRRVkaoeJFIR6Ymv78mS+uyvM=; b=TRc6KKOPoJ6pi3rlurR1PX3Ln7JoQCoSm8bE/DfzvuyzJ4HzqkqZflFREv3TsspoDP yMF6OOw2zs4mbtCX3Y4WOfHg4YlWKDnH09a3XZlIQLzaE06yXtBm22ewVVFmt1bKusoJ e0zgI6jl2bDqTx9+p6WK259oco1cjogvpNfcks/ZEu4OFx6qdVL7nkKtbIkC0+kFQ+j/ RYGJvtDEew0cLMwlaEyhPERF9H8l8b/FS/OPDCTF6J8KmB7aUuSMDwDQDGHO0KEBKE3u 8jKBBSb/6v3sgt3bEdBOppb2FhjrPv2zXjfbYapipodaQkQqkwXfYRzknPM5GU4plWR5 awpg== X-Gm-Message-State: ALoCoQmV2S9XX/HqZxQ0KHzzgRr8da83wWErOxr6sO28LGcz862v5gbDguUJiTLKtNS3TKElz3vS X-Received: by 10.224.120.67 with SMTP id c3mr42181314qar.84.1413869331365; Mon, 20 Oct 2014 22:28:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.89.116 with HTTP; Mon, 20 Oct 2014 22:28:31 -0700 (PDT) In-Reply-To: <3750B78B-23D0-4C2B-88C9-D649E45C6FB3@ve7jtb.com> References: <54002809.2020101@gmx.net> <20141014181931.2011201bddc3f13e114ff42c@nri.co.jp> <3750B78B-23D0-4C2B-88C9-D649E45C6FB3@ve7jtb.com> From: William Denniss Date: Mon, 20 Oct 2014 22:28:31 -0700 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=001a11c2f9544168540505e81b28 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/SER3HyEHlRIz0368PVxOqPvzFRs Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Define a server capaiblity discovery parameter? (was: Re: OAuth SPOP Detailed Review) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 05:28:56 -0000 --001a11c2f9544168540505e81b28 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I merged my proposed changes with Nat's recent 01 draft, my pull request (and diff) is here: https://bitbucket.org/Nat/oauth-spop/pull-request/1/specified-exactly-two-c= ode-transformation/diff TXT and PDF exports available for viewing from here: https://bitbucket.org/wdenniss/oauth-spop/downloads Let me know what you think. This proposed draft suggests two and only two transformation algorithms: plain and SHA-256. I think that simplifies the spec considerably, while still achieving everything it sets out to do. On Mon, Oct 20, 2014 at 4:03 AM, John Bradley wrote: > I started to draft the change. If you send me what you have I will > incorporate it. > > > > Sent from my iPhone > > On Oct 20, 2014, at 3:34 AM, Nat Sakimura wrote: > > That would be great. > > Actually, several stakeholders informed me that they would like sha256 > transformation as well. > Either John B. or I was supposed draft it but we have not to the date, s= o > a draft wording would be great. > > Thanks! > > 2014-10-20 15:19 GMT+09:00 William Denniss : > >> 1) n. >> >> I vote that we don't want discovery at all, as it adds a lot of >> complexity while yielding little to no benefit. >> >> I think we should support 2 transformations, plain (as mandated by the >> spec), and the best hashing algorithm that is commonly available (i.e. >> SHA256). If the spec needs to be updated in the future for a newer, bet= ter >> algorithm, a revised version of the spec could be created then. >> >> Due to the short window of time for code redemption, the hashing >> algorithm would have to be *seriously* broken to be unusable for spop. >> >> If this sounds good, I have a some draft wording with the above changes >> that could be incorporated. >> >> >> On Tue, Oct 14, 2014 at 2:19 AM, Nat Sakimura >> wrote: >> >>> In his mail, Hannes suggested to include more explicit reference to a >>> feature in the OpenID Connect Discovery spec in section 3.1. >>> >>> My response to it was that we could define a parameter here >>> and ask the implementers to implement it. Questions remains whether >>> we want to define it here or leave it to be out of scope. >>> >>> So, my questions are: >>> >>> (1) Do we want it? (y or n) >>> (2) if y, then adding the following text at the end of 3.1 be adequate? >>> >>> When the server supports OpenID Connect Discovery 1.0, the server MUST >>> advertise its capability with a parameter >>> oauth_spop_supported_alg. >>> The value of it is a JSON array of JSON strings representing >>> "alg" (Algorithm) Header Parameter Values for JWS as defined in >>> JSON Web Algorithms. >>> >>> Nat >>> >>> On Wed, 3 Sep 2014 02:28:57 +0900 >>> Nat Sakimura wrote: >>> >>> > Hi. Thanks for the detailed comments. >>> > >>> > Here are the responses to the questions raised in [1] >>> > >>> > [1] >>> > >>> http://www.tschofenig.priv.at/oauth/draft-ietf-oauth-spop-00-hannes.doc >>> > >>> > 3.1 [Question: Would it make sense to provide some information also >>> > in the >>> > > Dynamic Client Registration specification? I am a bit unhappy about >>> > > not specifying at least one mechanism for learning this information >>> > > since it is important for the overall security -- to avoid >>> > > downgrading attacks.] >>> > >>> > >>> > I would have included it if OAuth has defined a discovery document. n >>> > fact, it may be a good starting point to discuss whether we should >>> > have a discovery document for OAuth. >>> > >>> > If the client does the per client registration, then it will not be a >>> > public client so spop would not be needed. >>> > The clients as a class may register itself, but then each client >>> > instance would not know if the server knows that it is using spop, >>> > and assuming it without verifying is not very safe. >>> > >>> > 3.1 [Hannes: Can we make a more explicit reference to a feature in th= e >>> > > OpenID Connect Discovery specification?] >>> > >>> > >>> > It will be an extension to section 3 of OpenID Connect Discovery. Thi= s >>> > specification may define a JSON name for such a parameter. Then, one >>> > can include it in the metadata. >>> > >>> > A candidate for such name would be: >>> > >>> > oauth_spop_supported_alg: >>> > >>> > and the value would be the strings representing supported algorithms. >>> > It could be drawn from JWA algs. >>> > >>> > A simpler alternative would be: >>> > >>> > oauth_spop_support: >>> > >>> > and the value would be true or false. >>> > >>> > However, we have no good place to advertise them as of now. >>> > >>> > 3.2 [Hannes: Do we really need this flexibility here?] >>> > >>> > >>> > It is there as an extension point. John has a draft that uses >>> > aymmetric algo. An early draft had HMAC as well. >>> > >>> > We could however drop it. I suppose we can add other algorithms later >>> > without breaking this one. >>> > >>> > [Hannes: The term 'front channel' is not defined anywhere.] >>> > >>> > >>> > Will define if this section survives. >>> > >>> > 3.7 [Hannes: Why is there a SHOULD rather than a MUST?] >>> > >>> > >>> > The server may have other considerations before returning successful >>> > response. >>> > >>> > 5. [Hannes: Which request channel are you talking about? There are tw= o >>> > > types of request channels here, namely the Access Token >>> > > Request/Response and the Authorization Request / Response channel. >>> > > What do you mean by adequately protected here? How likely is it >>> > > that this can be accomplished? If it is rather unlikely then it >>> > > would be better to define a different transformation algorithm!] >>> > >>> > >>> > This is referring to the authorization request. >>> > >>> > On iOS as of the time of writing, not Jailbreaking seems to be >>> > adequate. For Android, only presenting the intended browser as the >>> > options to handle the request seems adequate. Similar considerations >>> > would be there per platform. >>> > >>> > Note: Authors do think that using other algorithms is better. >>> > However, it proved to be rather unpopular among the developers that >>> > they were in touch with and believe that we do need to provide this >>> > "no-transform" capability. >>> > >>> > For other "corrections", I am still working on to prepare comments as >>> > word comments. >>> > Most of editorial changes will be accepted. Some proposed technical >>> > changes seems to be due to the clauses being unclear, so I will try >>> > to propose a clarification rather than just accepting them. >>> > >>> > Best, >>> > >>> > Nat >>> > >>> > 2014-08-29 16:13 GMT+09:00 Hannes Tschofenig >>> > : >>> > > >>> > > Hi John, Hi Nat, >>> > > >>> > > I went through the document in detail and suggest some changes >>> > > (most of them editorial): >>> > > >>> http://www.tschofenig.priv.at/oauth/draft-ietf-oauth-spop-00-hannes.doc >>> > > >>> http://www.tschofenig.priv.at/oauth/draft-ietf-oauth-spop-00-hannes.pdf >>> > > >>> > > My main concern at the moment are some optional features in the spe= c >>> > > that make it less interoperable, such as the feature discovery, and >>> > > the transformation function. The latter might go away depending on >>> > > your answer to my question raised at >>> > > http://www.ietf.org/mail-archive/web/oauth/current/msg13354.html >>> > > but the former requires some specification work. >>> > > >>> > > Ciao >>> > > Hannes >>> > > >>> > > PS: I agree with James that the title of the document is a bit >>> > > misleading when compared with the other work we are doing in the >>> > > group. >>> > > >>> > > >>> > > _______________________________________________ >>> > > OAuth mailing list >>> > > OAuth@ietf.org >>> > > https://www.ietf.org/mailman/listinfo/oauth >>> > > >>> > >>> > >>> > >>> > -- >>> > Nat Sakimura (=3Dnat) >>> > Chairman, OpenID Foundation >>> > http://nat.sakimura.org/ >>> > @_nat_en >>> >>> >>> -- >>> Nat Sakimura (n-sakimura@nri.co.jp) >>> Nomura Research Institute, Ltd. >>> >>> =E6=9C=AC=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E5=90=AB=E3=81=BE=E3=82= =8C=E3=82=8B=E6=83=85=E5=A0=B1=E3=81=AF=E6=A9=9F=E5=AF=86=E6=83=85=E5=A0=B1= =E3=81=A7=E3=81=82=E3=82=8A=E3=80=81=E5=AE=9B=E5=85=88=E3=81=AB=E8=A8=98=E8= =BC=89=E3=81=95=E3=82=8C=E3=81=A6=E3=81=84=E3=82=8B=E6=96=B9=E3=81=AE=E3=81= =BF=E3=81=AB=E9=80=81=E4=BF=A1 >>> =E3=81=99=E3=82=8B=E3=81=93=E3=81=A8=E3=82=92=E6=84=8F=E5=9B=B3=E3=81= =97=E3=81=A6=E3=81=8A=E3=82=8A=E3=81=BE=E3=81=99=E3=80=82=E6=84=8F=E5=9B=B3= =E3=81=95=E3=82=8C=E3=81=9F=E5=8F=97=E5=8F=96=E4=BA=BA=E4=BB=A5=E5=A4=96=E3= =81=AE=E6=96=B9=E3=81=AB=E3=82=88=E3=82=8B=E3=81=93=E3=82=8C=E3=82=89=E3=81= =AE=E6=83=85=E5=A0=B1=E3=81=AE >>> =E9=96=8B=E7=A4=BA=E3=80=81=E8=A4=87=E8=A3=BD=E3=80=81=E5=86=8D=E9=85= =8D=E5=B8=83=E3=82=84=E8=BB=A2=E9=80=81=E3=81=AA=E3=81=A9=E4=B8=80=E5=88=87= =E3=81=AE=E5=88=A9=E7=94=A8=E3=81=8C=E7=A6=81=E6=AD=A2=E3=81=95=E3=82=8C=E3= =81=A6=E3=81=84=E3=81=BE=E3=81=99=E3=80=82=E8=AA=A4=E3=81=A3=E3=81=A6=E6=9C= =AC=E3=83=A1=E3=83=BC=E3=83=AB >>> =E3=82=92=E5=8F=97=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E5=A0=B4=E5=90= =88=E3=81=AF=E3=80=81=E7=94=B3=E3=81=97=E8=A8=B3=E3=81=94=E3=81=96=E3=81=84= =E3=81=BE=E3=81=9B=E3=82=93=E3=81=8C=E3=80=81=E9=80=81=E4=BF=A1=E8=80=85=E3= =81=BE=E3=81=A7=E3=81=8A=E7=9F=A5=E3=82=89=E3=81=9B=E3=81=84=E3=81=9F=E3=81= =A0=E3=81=8D=E3=80=81=E5=8F=97 >>> =E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E3=83=A1=E3=83=BC=E3=83=AB=E3=82= =92=E5=89=8A=E9=99=A4=E3=81=97=E3=81=A6=E3=81=84=E3=81=9F=E3=81=A0=E3=81=8D= =E3=81=BE=E3=81=99=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E8=87=B4=E3= =81=97=E3=81=BE=E3=81=99=E3=80=82 PLEASE READ: >>> The information contained in this e-mail is confidential and intended >>> for the named recipient(s) only. If you are not an intended recipient >>> of this e-mail, you are hereby notified that any review, dissemination, >>> distribution or duplication of this message is strictly prohibited. If >>> you have received this message in error, please notify the sender >>> immediately and delete your copy from your system. >>> >>> _______________________________________________ >>> 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 >> >> > > > -- > Nat Sakimura (=3Dnat) > http://www.sakimura.org/en/ > http://twitter.com/_nat_en > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a11c2f9544168540505e81b28 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I merged my proposed changes with Nat's recent 01 draf= t, my pull request (and diff) is here:=C2=A0https://bitbucket.org/Nat/oauth-spop/pull-request/1/= specified-exactly-two-code-transformation/diff

TXT a= nd PDF exports available for viewing from here:=C2=A0https://bitbuck= et.org/wdenniss/oauth-spop/downloads

Let me kn= ow what you think. This proposed draft suggests two and only two transforma= tion algorithms: plain and SHA-256.=C2=A0 I think that simplifies the spec = considerably, while still achieving everything it sets out to do.


= On Mon, Oct 20, 2014 at 4:03 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
I sta= rted to draft the change.=C2=A0 If you send me what you have I will incorpo= rate it.=C2=A0



Sent from my iPhone

On Oct 20, 2014, at 3:34 AM, Nat Sakimura <= ;n-sakimura@nri.c= o.jp> wrote:

That would be great.=C2=A0

Actually, several stake= holders informed me that they would like sha256 transformation as well.=C2= =A0
Either John B. or I was supposed =C2=A0draft it but we have n= ot to the date, so a draft wording would be great.=C2=A0

Thanks!

2014-10-20 15:19 GMT+09:00 William Denniss <<= a href=3D"mailto:wdenniss@google.com" target=3D"_blank">wdenniss@google.com= >:
1) n.
I vote that we don't want discovery at all, as it add= s a lot of complexity while yielding little to no benefit.=C2=A0
=
I think we should support 2 transformations, plain (as manda= ted by the spec), and the best hashing algorithm that is commonly available= (i.e. SHA256).=C2=A0 If the spec needs to be updated in the future for a n= ewer, better algorithm, a revised version of the spec could be created then= .

Due to the short window of time for code redempt= ion, the hashing algorithm would have to be seriously broken to be u= nusable for spop.

If this sounds good, I have a so= me draft wording with the above changes that could be incorporated.


On Tue, Oct 14, 2014 at 2:19 AM, Nat Sakimura <<= a href=3D"mailto:n-sakimura@nri.co.jp" target=3D"_blank">n-sakimura@nri.co.= jp> wrote:
In his mail, Han= nes suggested to include more explicit reference to a feature in the OpenID= Connect Discovery spec in section 3.1.

My response to it was that we could define a parameter here
and ask the implementers to implement it. Questions remains whether
we want to define it here or leave it to be out of scope.

So, my questions are:

(1) Do we want it? (y or n)
(2) if y, then adding the following text at the end of 3.1 be adequate?

When the server supports OpenID Connect Discovery 1.0, the server MUST
advertise its capability with a parameter
<spanx style=3D"verb">oauth_spop_supported_alg</spanx>= ;.
The value of it is a JSON array of JSON strings representing
"alg" (Algorithm) Header Parameter Values for JWS as defined in <xref target=3D"JWA">JSON Web Algorithms</xref>.

Nat

On Wed, 3 Sep 2014 02:28:57 +0900
Nat Sakimura <sa= kimura@gmail.com> wrote:

> Hi. Thanks for the detailed comments.
>
> Here are the responses to the questions raised in [1]
>
> [1]
> http://www.tschofenig.priv.at/oauth/draft-i= etf-oauth-spop-00-hannes.doc
>
> 3.1 [Question: Would it make sense to provide some information also > in the
> > Dynamic Client Registration specification? I am a bit unhappy abo= ut
> > not specifying at least one mechanism for learning this informati= on
> > since it is important for the overall security -- to avoid
> > downgrading attacks.]
>
>
> I would have included it if OAuth has defined a discovery document. n<= br> > fact, it may be a good starting point to discuss whether we should
> have a discovery document for OAuth.
>
> If the client does the per client registration, then it will not be a<= br> > public client so spop would not be needed.
> The clients as a class may register itself, but then each client
> instance would not know if the server knows that it is using spop,
> and assuming it without verifying is not very safe.
>
> 3.1 [Hannes: Can we make a more explicit reference to a feature in the=
> > OpenID Connect Discovery specification?]
>
>
> It will be an extension to section 3 of OpenID Connect Discovery. This=
> specification may define a JSON name for such a parameter. Then, one > can include it in the metadata.
>
> A candidate for such name would be:
>
> oauth_spop_supported_alg:
>
> and the value would be the strings representing supported algorithms.<= br> > It could be drawn from JWA algs.
>
> A simpler alternative would be:
>
> oauth_spop_support:
>
> and the value would be true or false.
>
> However, we have no good place to advertise them as of now.
>
> 3.2 [Hannes: Do we really need this flexibility here?]
>
>
> It is there as an extension point. John has a draft that uses
> aymmetric algo. An early draft had HMAC as well.
>
> We could however drop it. I suppose we can add other algorithms later<= br> > without breaking this one.
>
> [Hannes: The term 'front channel' is not defined anywhere.] >
>
> Will define if this section survives.
>
> 3.7 [Hannes: Why is there a SHOULD rather than a MUST?]
>
>
> The server may have other considerations before returning successful > response.
>
> 5. [Hannes: Which request channel are you talking about? There are two=
> > types of request channels here, namely the Access Token
> > Request/Response and the Authorization Request / Response channel= .
> > What do you mean by adequately protected here? How likely is it > > that this can be accomplished? If it is rather unlikely then it > > would be better to define a different transformation algorithm!]<= br> >
>
> This is referring to the authorization request.
>
> On iOS as of the time of writing, not Jailbreaking seems to be
> adequate. For Android, only presenting the intended browser as the
> options to handle the request seems adequate. Similar considerations > would be there per platform.
>
> Note: Authors do think that using other algorithms is better.
> However, it proved to be rather unpopular among the developers that > they were in touch with and believe that we do need to provide this > "no-transform" capability.
>
> For other "corrections", I am still working on to prepare co= mments as
> word comments.
> Most of editorial changes will be accepted. Some proposed technical > changes seems to be due to the clauses being unclear, so I will try > to propose a clarification rather than just accepting them.
>
> Best,
>
> Nat
>
> 2014-08-29 16:13 GMT+09:00 Hannes Tschofenig
> <han= nes.tschofenig@gmx.net>:
> >
> > Hi John, Hi Nat,
> >
> > I went through the document in detail and suggest some changes > > (most of them editorial):
> > http://www.tschofenig.priv.at/oauth/dr= aft-ietf-oauth-spop-00-hannes.doc
> > http://www.tschofenig.priv.at/oauth/dr= aft-ietf-oauth-spop-00-hannes.pdf
> >
> > My main concern at the moment are some optional features in the s= pec
> > that make it less interoperable, such as the feature discovery, a= nd
> > the transformation function. The latter might go away depending o= n
> > your answer to my question raised at
> > http://www.ietf.org/mail-archive/web/oauth/cu= rrent/msg13354.html
> > but the former requires some specification work.
> >
> > Ciao
> > Hannes
> >
> > PS: I agree with James that the title of the document is a bit > > misleading when compared with the other work we are doing in the<= br> > > group.
> >
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.or= g
> > https://www.ietf.org/mailman/listinfo/oauth
> >
>
>
>
> --
> Nat Sakimura (=3Dnat)
> Chairman, OpenID Foundation
> http://nat.saki= mura.org/
> @_nat_en


--
Nat Sakimura (n-s= akimura@nri.co.jp)
Nomura Research Institute, Ltd.

=E6=9C=AC=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E5=90=AB=E3=81=BE=E3=82=8C=E3= =82=8B=E6=83=85=E5=A0=B1=E3=81=AF=E6=A9=9F=E5=AF=86=E6=83=85=E5=A0=B1=E3=81= =A7=E3=81=82=E3=82=8A=E3=80=81=E5=AE=9B=E5=85=88=E3=81=AB=E8=A8=98=E8=BC=89= =E3=81=95=E3=82=8C=E3=81=A6=E3=81=84=E3=82=8B=E6=96=B9=E3=81=AE=E3=81=BF=E3= =81=AB=E9=80=81=E4=BF=A1
=E3=81=99=E3=82=8B=E3=81=93=E3=81=A8=E3=82=92=E6=84=8F=E5=9B=B3=E3=81=97=E3= =81=A6=E3=81=8A=E3=82=8A=E3=81=BE=E3=81=99=E3=80=82=E6=84=8F=E5=9B=B3=E3=81= =95=E3=82=8C=E3=81=9F=E5=8F=97=E5=8F=96=E4=BA=BA=E4=BB=A5=E5=A4=96=E3=81=AE= =E6=96=B9=E3=81=AB=E3=82=88=E3=82=8B=E3=81=93=E3=82=8C=E3=82=89=E3=81=AE=E6= =83=85=E5=A0=B1=E3=81=AE
=E9=96=8B=E7=A4=BA=E3=80=81=E8=A4=87=E8=A3=BD=E3=80=81=E5=86=8D=E9=85=8D=E5= =B8=83=E3=82=84=E8=BB=A2=E9=80=81=E3=81=AA=E3=81=A9=E4=B8=80=E5=88=87=E3=81= =AE=E5=88=A9=E7=94=A8=E3=81=8C=E7=A6=81=E6=AD=A2=E3=81=95=E3=82=8C=E3=81=A6= =E3=81=84=E3=81=BE=E3=81=99=E3=80=82=E8=AA=A4=E3=81=A3=E3=81=A6=E6=9C=AC=E3= =83=A1=E3=83=BC=E3=83=AB
=E3=82=92=E5=8F=97=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E5=A0=B4=E5=90=88=E3= =81=AF=E3=80=81=E7=94=B3=E3=81=97=E8=A8=B3=E3=81=94=E3=81=96=E3=81=84=E3=81= =BE=E3=81=9B=E3=82=93=E3=81=8C=E3=80=81=E9=80=81=E4=BF=A1=E8=80=85=E3=81=BE= =E3=81=A7=E3=81=8A=E7=9F=A5=E3=82=89=E3=81=9B=E3=81=84=E3=81=9F=E3=81=A0=E3= =81=8D=E3=80=81=E5=8F=97
=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E3=83=A1=E3=83=BC=E3=83=AB=E3=82=92=E5= =89=8A=E9=99=A4=E3=81=97=E3=81=A6=E3=81=84=E3=81=9F=E3=81=A0=E3=81=8D=E3=81= =BE=E3=81=99=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E8=87=B4=E3=81=97= =E3=81=BE=E3=81=99=E3=80=82 PLEASE READ:
The information contained in this e-mail is confidential and intended
for the named recipient(s) only. If you are not an intended recipient
of this e-mail, you are hereby notified that any review, dissemination,
distribution or duplication of this message is strictly prohibited. If
you have received this message in error, please notify the sender
immediately and delete your copy from your system.

_______________________________________________
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




--
Nat Saki= mura (=3Dnat)
= http://www.sakimura.org/en/
http://twitter.com/_nat_en
___________________= ____________________________
OAuth mailing list
<= span>OAuth@ietf.org=
https://www.ietf.org/mailman/listinfo/oauth
<= /div>

--001a11c2f9544168540505e81b28-- From nobody Tue Oct 21 06:17:20 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 043D61A1B91; Tue, 21 Oct 2014 06:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wmALWT2H0-7; Tue, 21 Oct 2014 06:16:53 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4651A1B80; Tue, 21 Oct 2014 06:16:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BEF29BF11; Tue, 21 Oct 2014 14:16:52 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JnyMj1WMrQzl; Tue, 21 Oct 2014 14:16:50 +0100 (IST) Received: from [109.125.46.87] (unknown [109.125.46.87]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B2A21BF18; Tue, 21 Oct 2014 14:16:49 +0100 (IST) Message-ID: <54465CBF.5070509@cs.tcd.ie> Date: Tue, 21 Oct 2014 14:16:47 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Mike Jones , The IESG References: <4E1F6AAD24975D4BA5B16804296739439BB0D3F3@TK5EX14MBXC286.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439BB0D3F3@TK5EX14MBXC286.redmond.corp.microsoft.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/M7GfMNFi9LMDp88VZX1w4idXTR4 Cc: "oauth-chairs@tools.ietf.org" , "draft-ietf-oauth-json-web-token@tools.ietf.org" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 13:17:02 -0000 Hi Mike, I've one remaining discuss point and a comment. See below... On 14/10/14 13:50, Mike Jones wrote: > The proposed resolutions below have been included in the -28 draft. Hopefully you'll be able to clear your DISCUSSes on that basis. > > The String Comparison Rules in Section 7.3 have been expanded to talk about when the application may need canonicalization rules. > > Thanks again, > -- Mike > >> -----Original Message----- >> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones >> Sent: Monday, October 06, 2014 7:20 PM >> To: Stephen Farrell; The IESG >> Cc: oauth-chairs@tools.ietf.org; draft-ietf-oauth-json-web- >> token@tools.ietf.org; oauth@ietf.org >> Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-json- >> web-token-27: (with DISCUSS and COMMENT) >> >> Thanks for tracking all of this Stephen. Responses inline below... >> >>> -----Original Message----- >>> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] >>> Sent: Monday, October 06, 2014 2:43 PM >>> To: Mike Jones; The IESG >>> Cc: oauth-chairs@tools.ietf.org; draft-ietf-oauth-json-web- >>> token@tools.ietf.org; oauth@ietf.org >>> Subject: Re: Stephen Farrell's Discuss on draft-ietf-oauth-json-web-token-27: >>> (with DISCUSS and COMMENT) >>> >>> >>> Hi Mike, >>> >>> On 06/10/14 08:54, Mike Jones wrote: >>>> Thanks for your review, Stephen. I've added the working group to >>>> the thread so they're aware of your comments. >>>> >>>>> -----Original Message----- From: Stephen Farrell >>>>> [mailto:stephen.farrell@cs.tcd.ie] Sent: Thursday, October 02, 2014 >>>>> 5:03 AM To: The IESG Cc: oauth-chairs@tools.ietf.org; >>>>> draft-ietf-oauth-json-web- token@tools.ietf.org Subject: Stephen >>>>> Farrell's Discuss on draft-ietf-oauth-json-web-token-27: (with >>>>> DISCUSS and COMMENT) >>>>> >>>>> Stephen Farrell has entered the following ballot position for >>>>> draft-ietf-oauth-json-web-token-27: Discuss >>>>> >>>>> When responding, please keep the subject line intact and reply to >>>>> all email addresses included in the To and CC lines. (Feel free to >>>>> cut this introductory paragraph, however.) >>>>> >>>>> >>>>> Please refer to >>>>> http://www.ietf.org/iesg/statement/discuss-criteria.html for more >>>>> information about IESG DISCUSS and COMMENT positions. >>>>> >>>>> >>>>> The document, along with other ballot positions, can be found >>>>> here: >>>>> http://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/ >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------- >>>>> -- >>>>> - >>>>> >>>>> >>> DISCUSS: >>>>> ------------------------------------------------------------------- >>>>> -- >>>>> - >>>>> >>>>> >>>>> >>>>> >>> (1) 4.1.1 and elsewhere you say case-sensitive: the same thing I >>> raised wrt DNS >>>>> names for another JOSE spec - do you need to say those SHOULD be >>>>> [upper|lower]cased when used in these? >>>> >>>> I believe that somewhere we should say that if case-insensitive >>>> values, such as DNS names, are used when constructing "kid" values, >>>> that the application doing so needs to define a convention on the >>>> canonical case to use for the case-insensitive portions, such as >>>> lowercasing them. >>> >>> As that discussion's happening on the key draft, I'll clear it here >>> and trust you to fix if a change is the end result. >> >> Thanks np >> >>>>> (2) Section 8: Why is "none" MTI? That seems both broken and going >>>>> in the oppostite direction from other WGs and so should be >>>>> explicitly jusified I think. (If a good enough justification exists >>>>> that is.) >>>> >>>> It is MTI because there are several existing applications of JWTs in >>>> which both unsigned and signed representations of the JWTs are >>>> requirements. These include draft-ietf-oauth-token-exchange, >>>> draft-hunt-oauth-v2-user-a4c, and OpenID Connect. This is a pretty >>>> common pattern where you sign something if the recipient cares who >>>> made the statements and where you don't have to sign it either if >>>> the recipient doesn't care who made the statements >>> >>> I don't see how (non-)signers can divine non-verifier's wishes that >>> way. (Absent negotiation or a directory.) >> >> Sometimes it does occur via negotiation. For instance, in some protocols, at >> registration time, relying parties explicitly tell identity providers what algorithms >> are acceptable to them, which may include "none". No divination - explicit >> communication. >> >>>> or if it can tell from >>>> another secured aspect of the application protocol (typically >>>> through the use of TLS) who made the statements. In the TLS case, >>>> the server authentication step makes a signature step unnecessary, >>>> so an Unsecured JWT is fine there. >>> >>> That's arguable IMO. >> >> I agree that it's application and context-dependent whether it's OK or not. The >> point is that there exist some circumstances in which it is OK, and this feature is >> being used in some of those cases. >> >>> I think I'll look back over the wg thread and either hold my nose or >> >> This issue was tracked as http://trac.tools.ietf.org/wg/jose/trac/ticket/36. >> Karen O'Donoghue recorded this conclusion in the tracker "Note: There was >> extensive discussion on the mailing list, and the rough consensus of the working >> group was to leave "none" in the document." >> >> Discussion threads on this topic include: >> [jose] #36: Algorithm "none" should be removed http://www.ietf.org/mail- >> archive/web/jose/current/msg02911.html - Began Jul 31, 2013 (91 messages) >> [jose] Text about applications and "alg":"none" http://www.ietf.org/mail- >> archive/web/jose/current/msg03321.html - Began Sep 3, 2013 (5 messages) >> >> This issue was a topic of a special working group call on Aug 19, 2013. The text >> discussed in the last thread and published at https://tools.ietf.org/html/draft- >> ietf-jose-json-web-algorithms-33#section-8.5 (Unsecured JWS Security >> Considerations) was the result of the working group's decisions resulting from all >> of this discussion. Thanks for all the pointers above. I read through all the (many!) Aug 19 mails and most of the `"none" should be removed" thread. So I do see that there was rough consensus to keep "none" in the draft and can (with difficulty;-) hold my nose and let that pass. I do not however, see that there was consensus to make "none" MTI for this draft. I did see a bit of haggling about this draft vs. JWS but still do not see why none ought be MTI here. >> >>>>> (3) Section 12: another way to handle privacy is to not include >>>>> sensitive data - I think you ought mention that as a bit of thought >>>>> along those lines can be much simpler than putting in place the key >>>>> management to handle thoughtlessly included PII. >>>> >>>> We can include a discussion of that point, >>> >>> Great. "Just say no" is workable here:-) I'll clear when we get such text. >>> >>>> but sometimes the very >>>> point of a JWT is to securely deliver PII from a verifiable party to >>>> an intended party with appropriate rights to receive it. >>> >>> Hmm. Its a moot point (so let's not argue it) but I wonder how often >>> PII is really needed for authorization with oauth. My guess would be >>> that its needed far less often than its found to be profitable >>> perhaps, or that carelessness plays a big role in using PII for such purposes. I've cleared on this as you added this text: "Of course, including only necessary privacy-sensitive information in a JWT is the most basic means of minimizing any potential privacy issues." That seems to me like a fairly offputting way to phrase it. I'd suggest instead: "Omitting privacy-sensitive information from a JWT is the simplest way of minimizing privacy issues." Cheers, S. PS: I didn't check the comments. >>> >>> S. >>> >>> >>> >>>> >>>>> ------------------------------------------------------------------- >>>>> -- >>>>> - >>>>> >>>>> >>> COMMENT: >>>>> ------------------------------------------------------------------- >>>>> -- >>>>> - >>>>> >>>>> >>>>> >>>>> >>> - abstract: 2nd sentence isn't needed here, in intro would be fine. >>>> >>>> I don't know - I think it's a big deal that the claims can be >>>> digitally signed or MACed and/or encrypted. That's the reason we >>>> have JWTs, rather than just JSON. >>>> >>>>> - 4.1.7: maybe worth adding that jti+iss being unique enough is not >>>>> sufficient and jti alone has to meet that need. In X.509 the >>>>> issuer/serial has the equivalent property so someone might assume >>>>> sequential jti values starting at 0 are ok. >>>> >>>> Makes sense to add a warning of some kind along these lines. I >>>> think I know the reasons you say that, but can you expand on that >>>> thought a bit before I take a stab on writing this up? For >>>> instance, while normally true, I don't think your observation is >>>> true if a relying party will only accept tokens from a single issuer. >>>> >>>>> - section 6: yuk >>>>> >>>>> - again I think the secdir comments are being handled by Kathleen >>>>> and the authors. >>>> >>>> Again, this is there because multiple applications asked for the >>>> ability to represent content that is optionally signed, sometimes >>>> securing it another way, such as with TLS. JWTs are used specific >>>> application protocol contexts - not in isolation. >>>> >>>> Thanks again, -- Mike >>>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > From nobody Tue Oct 21 09:37:04 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6342D1A88FD; Tue, 21 Oct 2014 09:37: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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 91Cg4KPcnI1U; Tue, 21 Oct 2014 09:36:57 -0700 (PDT) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 600641A8A71; Tue, 21 Oct 2014 09:36:52 -0700 (PDT) Received: by mail-lb0-f181.google.com with SMTP id l4so1385632lbv.12 for ; Tue, 21 Oct 2014 09:36:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fRQVjSssGSfi8YHOIYuEvtAMzWOCOOSReq5F3aMwa+w=; b=vqAGFo5baAOhZjFlgU8jVqNp1foCHg9+4WVxkog63JqsLtlUyvE2ZQMMy89VKYdPKG 3WlZieqJbEGtNVe26k+NDlNHAM5iFJsmcJN1sEgem5Hl8PoRqe0jv9jwdm6IarVGWJID L909g77iYE3JOFwVc1nn0xsVIJqh07JQoyey5QRlxVkLyeVM/cFI763fAM+yXbPmBeV6 LZqh4XdZ9ForkSX0u1a/uv+i7F21sk19Kx/TNRqV0M8+GnXGPdPD0jmuPpcLypVByK+x xHIj1OxiTF78mPtYL0qd1wxzxkIs0RYtxPj/y8CZrRrjB5j8Bpt8zLoCh7J0BgCsdWNM zI2g== MIME-Version: 1.0 X-Received: by 10.152.206.36 with SMTP id ll4mr36569040lac.64.1413909410626; Tue, 21 Oct 2014 09:36:50 -0700 (PDT) Received: by 10.112.95.36 with HTTP; Tue, 21 Oct 2014 09:36:50 -0700 (PDT) In-Reply-To: <54465CBF.5070509@cs.tcd.ie> References: <4E1F6AAD24975D4BA5B16804296739439BB0D3F3@TK5EX14MBXC286.redmond.corp.microsoft.com> <54465CBF.5070509@cs.tcd.ie> Date: Tue, 21 Oct 2014 12:36:50 -0400 Message-ID: From: Kathleen Moriarty To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a1133b7422a3f660505f170ab Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/CAFa3MSIDZt7n5fwB4UpiEDyOR0 Cc: "oauth-chairs@tools.ietf.org" , "oauth@ietf.org" , The IESG , "draft-ietf-oauth-json-web-token@tools.ietf.org" Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 16:37:02 -0000 --001a1133b7422a3f660505f170ab Content-Type: text/plain; charset=UTF-8 On Tue, Oct 21, 2014 at 9:16 AM, Stephen Farrell wrote: > > Hi Mike, > > I've one remaining discuss point and a comment. See below... > > On 14/10/14 13:50, Mike Jones wrote: > > The proposed resolutions below have been included in the -28 draft. > Hopefully you'll be able to clear your DISCUSSes on that basis. > > > > The String Comparison Rules in Section 7.3 have been expanded to talk > about when the application may need canonicalization rules. > > > > Thanks again, > > -- Mike > > > >> -----Original Message----- > >> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones > >> Sent: Monday, October 06, 2014 7:20 PM > >> To: Stephen Farrell; The IESG > >> Cc: oauth-chairs@tools.ietf.org; draft-ietf-oauth-json-web- > >> token@tools.ietf.org; oauth@ietf.org > >> Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on > draft-ietf-oauth-json- > >> web-token-27: (with DISCUSS and COMMENT) > >> > >> Thanks for tracking all of this Stephen. Responses inline below... > >> > >>> -----Original Message----- > >>> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > >>> Sent: Monday, October 06, 2014 2:43 PM > >>> To: Mike Jones; The IESG > >>> Cc: oauth-chairs@tools.ietf.org; draft-ietf-oauth-json-web- > >>> token@tools.ietf.org; oauth@ietf.org > >>> Subject: Re: Stephen Farrell's Discuss on > draft-ietf-oauth-json-web-token-27: > >>> (with DISCUSS and COMMENT) > >>> > >>> > >>> Hi Mike, > >>> > >>> On 06/10/14 08:54, Mike Jones wrote: > >>>> Thanks for your review, Stephen. I've added the working group to > >>>> the thread so they're aware of your comments. > >>>> > >>>>> -----Original Message----- From: Stephen Farrell > >>>>> [mailto:stephen.farrell@cs.tcd.ie] Sent: Thursday, October 02, 2014 > >>>>> 5:03 AM To: The IESG Cc: oauth-chairs@tools.ietf.org; > >>>>> draft-ietf-oauth-json-web- token@tools.ietf.org Subject: Stephen > >>>>> Farrell's Discuss on draft-ietf-oauth-json-web-token-27: (with > >>>>> DISCUSS and COMMENT) > >>>>> > >>>>> Stephen Farrell has entered the following ballot position for > >>>>> draft-ietf-oauth-json-web-token-27: Discuss > >>>>> > >>>>> When responding, please keep the subject line intact and reply to > >>>>> all email addresses included in the To and CC lines. (Feel free to > >>>>> cut this introductory paragraph, however.) > >>>>> > >>>>> > >>>>> Please refer to > >>>>> http://www.ietf.org/iesg/statement/discuss-criteria.html for more > >>>>> information about IESG DISCUSS and COMMENT positions. > >>>>> > >>>>> > >>>>> The document, along with other ballot positions, can be found > >>>>> here: > >>>>> http://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/ > >>>>> > >>>>> > >>>>> > >>>>> ------------------------------------------------------------------- > >>>>> -- > >>>>> - > >>>>> > >>>>> > >>> DISCUSS: > >>>>> ------------------------------------------------------------------- > >>>>> -- > >>>>> - > >>>>> > >>>>> > >>>>> > >>>>> > >>> (1) 4.1.1 and elsewhere you say case-sensitive: the same thing I > >>> raised wrt DNS > >>>>> names for another JOSE spec - do you need to say those SHOULD be > >>>>> [upper|lower]cased when used in these? > >>>> > >>>> I believe that somewhere we should say that if case-insensitive > >>>> values, such as DNS names, are used when constructing "kid" values, > >>>> that the application doing so needs to define a convention on the > >>>> canonical case to use for the case-insensitive portions, such as > >>>> lowercasing them. > >>> > >>> As that discussion's happening on the key draft, I'll clear it here > >>> and trust you to fix if a change is the end result. > >> > >> Thanks > > np > > >> > >>>>> (2) Section 8: Why is "none" MTI? That seems both broken and going > >>>>> in the oppostite direction from other WGs and so should be > >>>>> explicitly jusified I think. (If a good enough justification exists > >>>>> that is.) > >>>> > >>>> It is MTI because there are several existing applications of JWTs in > >>>> which both unsigned and signed representations of the JWTs are > >>>> requirements. These include draft-ietf-oauth-token-exchange, > >>>> draft-hunt-oauth-v2-user-a4c, and OpenID Connect. This is a pretty > >>>> common pattern where you sign something if the recipient cares who > >>>> made the statements and where you don't have to sign it either if > >>>> the recipient doesn't care who made the statements > >>> > >>> I don't see how (non-)signers can divine non-verifier's wishes that > >>> way. (Absent negotiation or a directory.) > >> > >> Sometimes it does occur via negotiation. For instance, in some > protocols, at > >> registration time, relying parties explicitly tell identity providers > what algorithms > >> are acceptable to them, which may include "none". No divination - > explicit > >> communication. > >> > >>>> or if it can tell from > >>>> another secured aspect of the application protocol (typically > >>>> through the use of TLS) who made the statements. In the TLS case, > >>>> the server authentication step makes a signature step unnecessary, > >>>> so an Unsecured JWT is fine there. > >>> > >>> That's arguable IMO. > >> > >> I agree that it's application and context-dependent whether it's OK or > not. The > >> point is that there exist some circumstances in which it is OK, and > this feature is > >> being used in some of those cases. > >> > >>> I think I'll look back over the wg thread and either hold my nose or > >> > >> This issue was tracked as > http://trac.tools.ietf.org/wg/jose/trac/ticket/36. > >> Karen O'Donoghue recorded this conclusion in the tracker "Note: There > was > >> extensive discussion on the mailing list, and the rough consensus of > the working > >> group was to leave "none" in the document." > >> > >> Discussion threads on this topic include: > >> [jose] #36: Algorithm "none" should be removed > http://www.ietf.org/mail- > >> archive/web/jose/current/msg02911.html - Began Jul 31, 2013 (91 > messages) > >> [jose] Text about applications and "alg":"none" > http://www.ietf.org/mail- > >> archive/web/jose/current/msg03321.html - Began Sep 3, 2013 (5 messages) > >> > >> This issue was a topic of a special working group call on Aug 19, > 2013. The text > >> discussed in the last thread and published at > https://tools.ietf.org/html/draft- > >> ietf-jose-json-web-algorithms-33#section-8.5 (Unsecured JWS Security > >> Considerations) was the result of the working group's decisions > resulting from all > >> of this discussion. > > Thanks for all the pointers above. I read through all the (many!) > Aug 19 mails and most of the `"none" should be removed" thread. > > So I do see that there was rough consensus to keep "none" in > the draft and can (with difficulty;-) hold my nose and let that > pass. I do not however, see that there was consensus to make > "none" MTI for this draft. I did see a bit of haggling about > this draft vs. JWS but still do not see why none ought be MTI > here. > > >> > >>>>> (3) Section 12: another way to handle privacy is to not include > >>>>> sensitive data - I think you ought mention that as a bit of thought > >>>>> along those lines can be much simpler than putting in place the key > >>>>> management to handle thoughtlessly included PII. > >>>> > >>>> We can include a discussion of that point, > >>> > >>> Great. "Just say no" is workable here:-) I'll clear when we get such > text. > >>> > >>>> but sometimes the very > >>>> point of a JWT is to securely deliver PII from a verifiable party to > >>>> an intended party with appropriate rights to receive it. > >>> > >>> Hmm. Its a moot point (so let's not argue it) but I wonder how often > >>> PII is really needed for authorization with oauth. My guess would be > >>> that its needed far less often than its found to be profitable > >>> perhaps, or that carelessness plays a big role in using PII for such > purposes. > > I've cleared on this as you added this text: > > "Of course, including > only necessary privacy-sensitive information in a JWT is the most > basic means of minimizing any potential privacy issues." > > That seems to me like a fairly offputting way to phrase it. I'd > suggest instead: > > "Omitting privacy-sensitive information from a JWT is the > simplest way of minimizing privacy issues." > I like this wording suggestion, thanks. > > Cheers, > S. > > PS: I didn't check the comments. > > >>> > >>> S. > >>> > >>> > >>> > >>>> > >>>>> ------------------------------------------------------------------- > >>>>> -- > >>>>> - > >>>>> > >>>>> > >>> COMMENT: > >>>>> ------------------------------------------------------------------- > >>>>> -- > >>>>> - > >>>>> > >>>>> > >>>>> > >>>>> > >>> - abstract: 2nd sentence isn't needed here, in intro would be fine. > >>>> > >>>> I don't know - I think it's a big deal that the claims can be > >>>> digitally signed or MACed and/or encrypted. That's the reason we > >>>> have JWTs, rather than just JSON. > >>>> > >>>>> - 4.1.7: maybe worth adding that jti+iss being unique enough is not > >>>>> sufficient and jti alone has to meet that need. In X.509 the > >>>>> issuer/serial has the equivalent property so someone might assume > >>>>> sequential jti values starting at 0 are ok. > >>>> > >>>> Makes sense to add a warning of some kind along these lines. I > >>>> think I know the reasons you say that, but can you expand on that > >>>> thought a bit before I take a stab on writing this up? For > >>>> instance, while normally true, I don't think your observation is > >>>> true if a relying party will only accept tokens from a single issuer. > >>>> > >>>>> - section 6: yuk > >>>>> > >>>>> - again I think the secdir comments are being handled by Kathleen > >>>>> and the authors. > >>>> > >>>> Again, this is there because multiple applications asked for the > >>>> ability to represent content that is optionally signed, sometimes > >>>> securing it another way, such as with TLS. JWTs are used specific > >>>> application protocol contexts - not in isolation. > >>>> > >>>> Thanks again, -- Mike > >>>> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > > > -- Best regards, Kathleen --001a1133b7422a3f660505f170ab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Oct 21, 2014 at 9:16 AM, Stephen Farrell <= stephen.farr= ell@cs.tcd.ie> wrote:

Hi Mike,

I've one remaining discuss point and a comment. See below...

On 14/10/14 13:50, Mike Jones wrote:
> The proposed resolutions below have been included in the -28 draft.=C2= =A0 Hopefully you'll be able to clear your DISCUSSes on that basis.
>
> The String Comparison Rules in Section 7.3 have been expanded to talk = about when the application may need canonicalization rules.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thanks again,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =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 [mailto:oaut= h-bounces@ietf.org] On Behalf Of Mike Jones
>> Sent: Monday, October 06, 2014 7:20 PM
>> To: Stephen Farrell; The IESG
>> Cc: oauth-chairs@to= ols.ietf.org; draft-ietf-oauth-json-web-
>> token@tools.ietf.org; = oauth@ietf.org
>> Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-iet= f-oauth-json-
>> web-token-27: (with DISCUSS and COMMENT)
>>
>> Thanks for tracking all of this Stephen.=C2=A0 Responses inline be= low...
>>
>>> -----Original Message-----
>>> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]
>>> Sent: Monday, October 06, 2014 2:43 PM
>>> To: Mike Jones; The IESG
>>> Cc: oauth-chair= s@tools.ietf.org; draft-ietf-oauth-json-web-
>>> token@tools.ietf.org; oauth@ietf.org
>>> Subject: Re: Stephen Farrell's Discuss on draft-ietf-oauth= -json-web-token-27:
>>> (with DISCUSS and COMMENT)
>>>
>>>
>>> Hi Mike,
>>>
>>> On 06/10/14 08:54, Mike Jones wrote:
>>>> Thanks for your review, Stephen.=C2=A0 I've added the = working group to
>>>> the thread so they're aware of your comments.
>>>>
>>>>> -----Original Message----- From: Stephen Farrell
>>>>> [mailto:s= tephen.farrell@cs.tcd.ie] Sent: Thursday, October 02, 2014
>>>>> 5:03 AM To: The IESG Cc: oauth-chairs@tools.ietf.org;
>>>>> draft-ietf-oauth-json-web- token@tools.ietf.org Subject: Stephen
>>>>> Farrell's Discuss on draft-ietf-oauth-json-web-tok= en-27: (with
>>>>> DISCUSS and COMMENT)
>>>>>
>>>>> Stephen Farrell has entered the following ballot posit= ion for
>>>>> draft-ietf-oauth-json-web-token-27: Discuss
>>>>>
>>>>> When responding, please keep the subject line intact a= nd reply to
>>>>> all email addresses included in the To and CC lines. (= Feel free to
>>>>> cut this introductory paragraph, however.)
>>>>>
>>>>>
>>>>> Please refer to
>>>>> http://www.ietf.org/iesg/statement/discuss= -criteria.html for more
>>>>> information about IESG DISCUSS and COMMENT positions.<= br> >>>>>
>>>>>
>>>>> The document, along with other ballot positions, can b= e found
>>>>> here:
>>>>> http://datatracker.ietf.org/doc/dr= aft-ietf-oauth-json-web-token/
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------= -------------
>>>>> --
>>>>> -
>>>>>
>>>>>
>>> DISCUSS:
>>>>> ------------------------------------------------------= -------------
>>>>> --
>>>>> -
>>>>>
>>>>>
>>>>>
>>>>>
>>> (1) 4.1.1 and elsewhere you say case-sensitive: the same thing= I
>>> raised wrt DNS
>>>>> names for another JOSE spec - do you need to say those= SHOULD be
>>>>> [upper|lower]cased when used in these?
>>>>
>>>> I believe that somewhere we should say that if case-insens= itive
>>>> values, such as DNS names, are used when constructing &quo= t;kid" values,
>>>> that the application doing so needs to define a convention= on the
>>>> canonical case to use for the case-insensitive portions, s= uch as
>>>> lowercasing them.
>>>
>>> As that discussion's happening on the key draft, I'll = clear it here
>>> and trust you to fix if a change is the end result.
>>
>> Thanks

np

>>
>>>>> (2) Section 8: Why is "none" MTI? That seems= both broken and going
>>>>> in the oppostite direction from other WGs and so shoul= d be
>>>>> explicitly jusified I think. (If a good enough justifi= cation exists
>>>>> that is.)
>>>>
>>>> It is MTI because there are several existing applications = of JWTs in
>>>> which both unsigned and signed representations of the JWTs= are
>>>> requirements.=C2=A0 These include draft-ietf-oauth-token-e= xchange,
>>>> draft-hunt-oauth-v2-user-a4c, and OpenID Connect.=C2=A0 Th= is is a pretty
>>>> common pattern where you sign something if the recipient c= ares who
>>>> made the statements and where you don't have to sign i= t either if
>>>> the recipient doesn't care who made the statements
>>>
>>> I don't see how (non-)signers can divine non-verifier'= s wishes that
>>> way. (Absent negotiation or a directory.)
>>
>> Sometimes it does occur via negotiation.=C2=A0 For instance, in so= me protocols, at
>> registration time, relying parties explicitly tell identity provid= ers what algorithms
>> are acceptable to them, which may include "none".=C2=A0 = No divination - explicit
>> communication.
>>
>>>> or if it can tell from
>>>> another secured aspect of the application protocol (typica= lly
>>>> through the use of TLS) who made the statements.=C2=A0 In = the TLS case,
>>>> the server authentication step makes a signature step unne= cessary,
>>>> so an Unsecured JWT is fine there.
>>>
>>> That's arguable IMO.
>>
>> I agree that it's application and context-dependent whether it= 's OK or not.=C2=A0 The
>> point is that there exist some circumstances in which it is OK, an= d this feature is
>> being used in some of those cases.
>>
>>> I think I'll look back over the wg thread and either hold = my nose or
>>
>> This issue was tracked as http://trac.tools.ietf.org/wg/jose/= trac/ticket/36.
>> Karen O'Donoghue recorded this conclusion in the tracker "= ;Note: There was
>> extensive discussion on the mailing list, and the rough=C2=A0 cons= ensus of the working
>> group was to leave "none" in the document."
>>
>> Discussion threads on this topic include:
>> [jose] #36: Algorithm "none" should be removed http://www.ietf.org/mail-<= /a>
>> archive/web/jose/current/msg02911.html - Began Jul 31, 2013=C2=A0 = (91 messages)
>> [jose] Text about applications and "alg":"none"= ; http://www.ietf.o= rg/mail-
>> archive/web/jose/current/msg03321.html - Began Sep 3, 2013 (5 mess= ages)
>>
>> This issue was a topic of a special working group call on Aug 19, = 2013.=C2=A0 The text
>> discussed in the last thread and published at https://tools.ietf.org/html/dr= aft-
>> ietf-jose-json-web-algorithms-33#section-8.5 (Unsecured JWS Securi= ty
>> Considerations) was the result of the working group's decision= s resulting from all
>> of this discussion.

Thanks for all the pointers above. I read through all the (many= !)
Aug 19 mails and most of the `"none" should be removed" thre= ad.

So I do see that there was rough consensus to keep "none" in
the draft and can (with difficulty;-) hold my nose and let that
pass. I do not however, see that there was consensus to make
"none" MTI for this draft. I did see a bit of haggling about
this draft vs. JWS but still do not see why none ought be MTI
here.

>>
>>>>> (3) Section 12: another way to handle privacy is to no= t include
>>>>> sensitive data - I think you ought mention that as a b= it of thought
>>>>> along those lines can be much simpler than putting in = place the key
>>>>> management to handle thoughtlessly included PII.
>>>>
>>>> We can include a discussion of that point,
>>>
>>> Great. "Just say no" is workable here:-) I'll cl= ear when we get such text.
>>>
>>>> but sometimes the very
>>>> point of a JWT is to securely deliver PII from a verifiabl= e party to
>>>> an intended party with appropriate rights to receive it. >>>
>>> Hmm. Its a moot point (so let's not argue it) but I wonder= how often
>>> PII is really needed for authorization with oauth. My guess wo= uld be
>>> that its needed far less often than its found to be profitable=
>>> perhaps, or that carelessness plays a big role in using PII fo= r such purposes.

I've cleared on this as you added this text:

=C2=A0 "Of course, including
=C2=A0 =C2=A0only necessary privacy-sensitive information in a JWT is the m= ost
=C2=A0 =C2=A0basic means of minimizing any potential privacy issues."<= br>
That seems to me like a fairly offputting way to phrase it. I'd
suggest instead:

=C2=A0 "Omitting privacy-sensitive information from a JWT is the
=C2=A0 simplest way of minimizing privacy issues."

I like this wording suggestion, thanks.
=C2=A0

Cheers,
S.

PS: I didn't check the comments.

>>>
>>> S.
>>>
>>>
>>>
>>>>
>>>>> ------------------------------------------------------= -------------
>>>>> --
>>>>> -
>>>>>
>>>>>
>>> COMMENT:
>>>>> ------------------------------------------------------= -------------
>>>>> --
>>>>> -
>>>>>
>>>>>
>>>>>
>>>>>
>>> - abstract: 2nd sentence isn't needed here, in intro would= be fine.
>>>>
>>>> I don't know - I think it's a big deal that the cl= aims can be
>>>> digitally signed or MACed and/or encrypted.=C2=A0 That'= ;s the reason we
>>>> have JWTs, rather than just JSON.
>>>>
>>>>> - 4.1.7: maybe worth adding that jti+iss being unique = enough is not
>>>>> sufficient and jti alone has to meet that need. In X.5= 09 the
>>>>> issuer/serial has the equivalent property so someone m= ight assume
>>>>> sequential jti values starting at 0 are ok.
>>>>
>>>> Makes sense to add a warning of some kind along these line= s.=C2=A0 I
>>>> think I know the reasons you say that, but can you expand = on that
>>>> thought a bit before I take a stab on writing this up?=C2= =A0 For
>>>> instance, while normally true, I don't think your obse= rvation is
>>>> true if a relying party will only accept tokens from a sin= gle issuer.
>>>>
>>>>> - section 6: yuk
>>>>>
>>>>> - again I think the secdir comments are being handled = by Kathleen
>>>>> and the authors.
>>>>
>>>> Again, this is there because multiple applications asked f= or the
>>>> ability to represent content that is optionally signed, so= metimes
>>>> securing it another way, such as with TLS.=C2=A0 JWTs are = used specific
>>>> application protocol contexts - not in isolation.
>>>>
>>>> Thanks again, -- Mike
>>>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>




--
=

Best regards,
Kathleen
--001a1133b7422a3f660505f170ab-- From nobody Tue Oct 21 10:36:34 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1E2D1A1B4B; Tue, 21 Oct 2014 10:36: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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wNurqAAcZ1Sc; Tue, 21 Oct 2014 10:36:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7EF1A1BB8; Tue, 21 Oct 2014 10:36:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141021173624.7137.6838.idtracker@ietfa.amsl.com> Date: Tue, 21 Oct 2014 10:36:24 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/h2gn8H7XSeXgESqpAHmywwHwFS8 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-assertions-18.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 17:36:33 -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 Working Group of the IETF. Title : Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants Authors : Brian Campbell Chuck Mortimore Michael B. Jones Yaron Y. Goland Filename : draft-ietf-oauth-assertions-18.txt Pages : 23 Date : 2014-10-21 Abstract: This specification provides a framework for the use of assertions with OAuth 2.0 in the form of a new client authentication mechanism and a new authorization grant type. Mechanisms are specified for transporting assertions during interactions with a token endpoint, as well as general processing rules. The intent of this specification is to provide a common framework for OAuth 2.0 to interwork with other identity systems using assertions, and to provide alternative client authentication mechanisms. Note that this specification only defines abstract message flows and processing rules. In order to be implementable, companion specifications are necessary to provide the corresponding concrete instantiations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-assertions-18 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-assertions-18 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 Oct 21 10:36:39 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDB361A1BB7 for ; Tue, 21 Oct 2014 10:36:33 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPAERd59rBeW; Tue, 21 Oct 2014 10:36:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A78031A1BBB; Tue, 21 Oct 2014 10:36:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: oauth-chairs@tools.ietf.org, draft-ietf-oauth-assertions@tools.ietf.org, oauth@ietf.org, Kathleen.Moriarty.ietf@gmail.com, stephen.farrell@cs.tcd.ie, rlb@ipv.sx X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141021173624.7137.52798.idtracker@ietfa.amsl.com> Date: Tue, 21 Oct 2014 10:36:24 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/KFcMZlRIVIqyVQfvK71lemaQdVQ Subject: [OAUTH-WG] New Version Notification - draft-ietf-oauth-assertions-18.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 17:36:34 -0000 A new version (-18) has been submitted for draft-ietf-oauth-assertions: http://www.ietf.org/internet-drafts/draft-ietf-oauth-assertions-18.txt Sub state has been changed to AD Followup from Revised ID Needed The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-assertions-18 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. IETF Secretariat. From nobody Tue Oct 21 10:39:19 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7A041A6EED; Tue, 21 Oct 2014 10:39:15 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ec0G5vze09d9; Tue, 21 Oct 2014 10:39:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 332CC1A6EF0; Tue, 21 Oct 2014 10:39:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141021173900.12572.61078.idtracker@ietfa.amsl.com> Date: Tue, 21 Oct 2014 10:39:00 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/7XVOp6pAodtLDJpUn2q6gYo45Z8 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-saml2-bearer-22.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 17:39:16 -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 Working Group of the IETF. Title : SAML 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants Authors : Brian Campbell Chuck Mortimore Michael B. Jones Filename : draft-ietf-oauth-saml2-bearer-22.txt Pages : 21 Date : 2014-10-21 Abstract: This specification defines the use of a Security Assertion Markup Language (SAML) 2.0 Bearer Assertion as a means for requesting an OAuth 2.0 access token as well as for use as a means of client authentication. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-22 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-saml2-bearer-22 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 Oct 21 10:39:27 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA00F1A6EE8 for ; Tue, 21 Oct 2014 10:39:18 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f_g2svlc-eSO; Tue, 21 Oct 2014 10:39:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1081A6EF2; Tue, 21 Oct 2014 10:39:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: oauth-chairs@tools.ietf.org, draft-ietf-oauth-saml2-bearer@tools.ietf.org, oauth@ietf.org, Kathleen.Moriarty.ietf@gmail.com, rlb@ipv.sx X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141021173900.12572.55366.idtracker@ietfa.amsl.com> Date: Tue, 21 Oct 2014 10:39:00 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/OsJdeQAn-8y3Tlgo2yCggVExbls Subject: [OAUTH-WG] New Version Notification - draft-ietf-oauth-saml2-bearer-22.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 17:39:19 -0000 A new version (-22) has been submitted for draft-ietf-oauth-saml2-bearer: http://www.ietf.org/internet-drafts/draft-ietf-oauth-saml2-bearer-22.txt Sub state has been changed to AD Followup from Revised ID Needed The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-saml2-bearer-22 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. IETF Secretariat. From nobody Tue Oct 21 10:42:50 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3A981A1C05; Tue, 21 Oct 2014 10:42:47 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4qqxEOXZ3pG; Tue, 21 Oct 2014 10:42:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4121A6EF2; Tue, 21 Oct 2014 10:42:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141021174241.8101.92326.idtracker@ietfa.amsl.com> Date: Tue, 21 Oct 2014 10:42:41 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/WJ76PF-cAx9_VW6InaeoxcogQO0 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-bearer-11.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 17:42:47 -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 Working Group of the IETF. Title : JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants Authors : Michael B. Jones Brian Campbell Chuck Mortimore Filename : draft-ietf-oauth-jwt-bearer-11.txt Pages : 15 Date : 2014-10-21 Abstract: This specification defines the use of a JSON Web Token (JWT) Bearer Token as a means for requesting an OAuth 2.0 access token as well as for use as a means of client authentication. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwt-bearer-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 21 10:43:00 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79AFB1A6EF2 for ; Tue, 21 Oct 2014 10:42:50 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dg4lfY2xxlR0; Tue, 21 Oct 2014 10:42:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3E51A6EF9; Tue, 21 Oct 2014 10:42:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: oauth-chairs@tools.ietf.org, draft-ietf-oauth-jwt-bearer@tools.ietf.org, oauth@ietf.org, Kathleen.Moriarty.ietf@gmail.com, rlb@ipv.sx X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141021174241.8101.20966.idtracker@ietfa.amsl.com> Date: Tue, 21 Oct 2014 10:42:41 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/hEZZRDyDscSK3ApSqjjJF78SPok Subject: [OAUTH-WG] New Version Notification - draft-ietf-oauth-jwt-bearer-11.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 17:42:51 -0000 A new version (-11) has been submitted for draft-ietf-oauth-jwt-bearer: http://www.ietf.org/internet-drafts/draft-ietf-oauth-jwt-bearer-11.txt Sub state has been changed to AD Followup from Revised ID Needed The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwt-bearer-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Tue Oct 21 11:26:24 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 576941A7011 for ; Tue, 21 Oct 2014 11:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lfbfE0UfiBcF for ; Tue, 21 Oct 2014 11:26:18 -0700 (PDT) Received: from na3sys009aog119.obsmtp.com (na3sys009aog119.obsmtp.com [74.125.149.246]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C54E1A6EF2 for ; Tue, 21 Oct 2014 11:26:18 -0700 (PDT) Received: from mail-ig0-f174.google.com ([209.85.213.174]) (using TLSv1) by na3sys009aob119.postini.com ([74.125.148.12]) with SMTP ID DSNKVEalSai7KA9pu72c9O0B1FZjhNyeQXCq@postini.com; Tue, 21 Oct 2014 11:26:18 PDT Received: by mail-ig0-f174.google.com with SMTP id a13so1917942igq.1 for ; Tue, 21 Oct 2014 11:26:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=UHZfvJlMDZsC5EzgQVxd6oFt3FBqIAfu+mOMOyx44pk=; b=UWbR2Jfa582ZJKdcxPffc8LM3tnB/DiCZGrDOtcQuYph1zcDpSLxIR15qRDkQRc4XZ SdgC4QnOTzGlNFsRJ+iXESZVuSExBO0DE7p2chlao2LzFohY70Yx20O4z9iExuJa6dDL psKh+X3QORuRt2i010cgjheG8XmK8ktNqAKGFPFze5OYP/0wyLTYdFWIeAPOSqPZA82K nru7be2J+aSsT2sZg3ssIEXttfeEkj3n7ZVbzg9lHP31kTUlXzazODMlR5A6mQG2omp6 RUO/J8YAlMcvO9yC4gkjrWBMjRVsmIsjlg0AcYXCg/WMN1nyUtBTiHuJ/a79HkubxAoi /+Ig== X-Gm-Message-State: ALoCoQlDqFdQgyXfHVMyqDpQwvkdnc5mW9vIe6LUQdfFBpCt6vzjiY9gIOBC5D5xLoFiHi5hXxsxHGRPxJ1JzsiYz8YuHGSkDFy2B4050NGtjIUSF5NMb9RCHve8jzPulpbludmBaHA3 X-Received: by 10.43.76.199 with SMTP id zf7mr11175993icb.57.1413915977614; Tue, 21 Oct 2014 11:26:17 -0700 (PDT) X-Received: by 10.43.76.199 with SMTP id zf7mr11175965icb.57.1413915977380; Tue, 21 Oct 2014 11:26:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.86.167 with HTTP; Tue, 21 Oct 2014 11:25:47 -0700 (PDT) From: Brian Campbell Date: Tue, 21 Oct 2014 12:25:47 -0600 Message-ID: To: oauth , "oauth-chairs@tools.ietf.org" , The IESG Content-Type: multipart/alternative; boundary=001a11c3b252931fc80505f2f70a Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/6wDc1INYJIT693DgMjHA4h2sZl0 Cc: Richard Barnes Subject: [OAUTH-WG] New Assertion Drafts Published X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 18:26:20 -0000 --001a11c3b252931fc80505f2f70a Content-Type: text/plain; charset=UTF-8 New versions of all three OAuth assertion documents (listed below) have been published with changes incorporating feedback received during IESG Evaluation. Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants https://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ http://tools.ietf.org/html/draft-ietf-oauth-assertions-18 JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/ http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-11 SAML 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants https://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-22 --001a11c3b252931fc80505f2f70a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
3D""New v= ersions of all three OAuth assertion d= ocuments (listed below) have been published with changes incor= porating feedback received during IESG Evaluation.

Assertion Framework for OAuth 2.0 Client Authen= tication and Authorization Grants
https://datatracker.i= etf.org/doc/draft-ietf-oauth-asser= tions/
http://tools.ietf.org/html/draft-ietf-oauth-assertions-18

JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Au= thorization Grants
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/
http://tools.ietf.org/h= tml/draft-ietf-oauth-jwt-bearer-11

SAML 2.0 Profile for OAuth 2.0 Client Authentication and Authorization = Grants
https://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/<= /a>
http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-22

=
--001a11c3b252931fc80505f2f70a-- From nobody Tue Oct 21 14:33:34 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1901A1A874C; Tue, 21 Oct 2014 14:33:26 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5h5qJQP57od6; Tue, 21 Oct 2014 14:33:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 005051A8768; Tue, 21 Oct 2014 14:33:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141021213320.10177.69742.idtracker@ietfa.amsl.com> Date: Tue, 21 Oct 2014 14:33:20 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/1QZ0fohsbFlcGLwSCUKrx5mqWVY Cc: draft-ietf-oauth-assertions@tools.ietf.org, oauth-chairs@tools.ietf.org, oauth@ietf.org Subject: [OAUTH-WG] Stephen Farrell's No Objection on draft-ietf-oauth-assertions-18: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 21:33:26 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-oauth-assertions-18: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for adding the MTI algorithms to the saml and jwt docs to clear the discuss I put on this one. I didn't check the comments below. - general: What prevents/detects conflicts between the oauth scope parameter and the saml or jwt equivalent? Are there other bits of replicated data that could be the basis for a vulnerability? (The comment below applies for both saml and jwt so putting it here.) - The no replay protection issue was debated in the WG wasn't it? (I think I recall it, not sure.) Seems like a bad plan to me to not require at least implementation of replay protection in the AS so that it can be turned on. Can you point me at where that was discussed on the list? From nobody Tue Oct 21 15:00:55 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ED5F1A87F2 for ; Tue, 21 Oct 2014 15:00:49 -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=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4hd8O_FRfzDg for ; Tue, 21 Oct 2014 15:00:48 -0700 (PDT) Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C43831A880E for ; Tue, 21 Oct 2014 15:00:44 -0700 (PDT) Received: by mail-qa0-f48.google.com with SMTP id dc16so1521191qab.7 for ; Tue, 21 Oct 2014 15:00:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=knG15Tqqakukcc2qbH5Gj7Z+24KOGttxQ8cyk98Num8=; b=PB/yQiKJ0FXsklggx/SzjOVaosJX8H9W4BqGfUBhuRi1r0X62UiSj66B/Pq+9LfyM4 t5aXIBaWjJoGnwYnoye03GknvtvCQBhgTQiwIle9j0qpammKyjW+12LebxokISZ+9pIF rqXWRbXaMDeFczSJWcaym5Tr57tkYAsGuS4bai1LOiivnoXzghPJIkkaJsRVxTB+UrHi DvLC5SyEU++kgHgBRfoDpSEdEbaiG0Y1ZxdR9Pk5N4qoEVLUSv4HYse/nUrA+rpTR8tZ zOWWfqmfIe+E2HLkg+vLje5wxS8KgQN6q2vVmroH33Hg/LIHgHr73FXWTrVZXUMpVCKN OaDA== X-Gm-Message-State: ALoCoQlG8ueSYM1dClMEVrRnONUp8CHxHgTSECv2g1E0IXxJ4WzbSF115oFKGOfkqZWKlqlF5UCd X-Received: by 10.224.97.10 with SMTP id j10mr17572037qan.103.1413928843309; Tue, 21 Oct 2014 15:00:43 -0700 (PDT) Received: from [192.168.1.37] (186-106-147-133.baf.movistar.cl. [186.106.147.133]) by mx.google.com with ESMTPSA id 78sm1446356qgp.2.2014.10.21.15.00.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 21 Oct 2014 15:00:42 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Bradley In-Reply-To: <20141021213320.10177.69742.idtracker@ietfa.amsl.com> Date: Tue, 21 Oct 2014 19:00:42 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <699DBB39-189D-482E-B1FF-125E9387F733@ve7jtb.com> References: <20141021213320.10177.69742.idtracker@ietfa.amsl.com> To: Stephen Farrell X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/HxE6SJ_4XsHiNXBKxcwsAm1lszs Cc: draft-ietf-oauth-assertions@tools.ietf.org, oauth-chairs@tools.ietf.org, The IESG , oauth@ietf.org Subject: Re: [OAUTH-WG] Stephen Farrell's No Objection on draft-ietf-oauth-assertions-18: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 22:00:49 -0000 On the topic of relay protection we added "jti" (JWT ID) Claim to the = JWT spec so that we would have a claim to use for replay detection on = assertions. In the Connect profile of the JWT assertions spec for client = authentication we did make it required for the sender to include it, but = gave some flexibility to the server in interpreting it. For self signed assertions used as client authentication I think = allowing the server to detect replay attacks is probably a good thing. For authorization assertions the issues get more complicated and, = probably shouldn't be locked down at this layer. There may be reasons for not detecting replay for authentication as well = that I am not aware of. I suspect that as Connect did applications using these specifications = will profile them to include replay protection if required. I am bothered by it not being required in these specs.=20 I do remember a discussion on this, but would have a hard time pointing = to it now. John B. On Oct 21, 2014, at 6:33 PM, Stephen Farrell = wrote: > Stephen Farrell has entered the following ballot position for > draft-ietf-oauth-assertions-18: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 >=20 > Thanks for adding the MTI algorithms to the saml and jwt docs > to clear the discuss I put on this one. >=20 > I didn't check the comments below. >=20 > - general: What prevents/detects conflicts between the oauth > scope parameter and the saml or jwt equivalent? Are there > other bits of replicated data that could be the basis for a > vulnerability? >=20 > (The comment below applies for both saml and jwt so=20 > putting it here.) >=20 > - The no replay protection issue was debated in the > WG wasn't it? (I think I recall it, not sure.) Seems like a > bad plan to me to not require at least implementation of > replay protection in the AS so that it can be turned on. Can > you point me at where that was discussed on the list? >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Wed Oct 22 01:16:19 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 523EA1A8AEB for ; Wed, 22 Oct 2014 01:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.551 X-Spam-Level: X-Spam-Status: No, score=0.551 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JUj3sUXoggGO for ; Wed, 22 Oct 2014 01:16:13 -0700 (PDT) Received: from mail-vc0-f194.google.com (mail-vc0-f194.google.com [209.85.220.194]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E24D1A8A8F for ; Wed, 22 Oct 2014 01:16:13 -0700 (PDT) Received: by mail-vc0-f194.google.com with SMTP id lf12so517490vcb.9 for ; Wed, 22 Oct 2014 01:16:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=+7lvUr08r2/BIPx+LWTg3C+hIanAFsH70dKkCM/lCi4=; b=SVp2eUe3uiuYEUwBIMnp/CT3p0m2tCwLnkRukQCioJE4dxOJR9xbQ1sJJ0fDU7Rj8/ amjXS/0RaKqMNAehrw6oenoiUjUfCCGuhvxggMLqYjgEJ9uzAZ7xRxgoWTveyOg0US1e L4sFXyh9TzClqHf5Os3aFdhDZ3Yt7NGCmtdGWqMwb00g2ja0n0EOQeQT+fXUO6E2Kryi i2tLAVleZ7GVhlqvbvWZsX+ys5fekLkTi1vbQB347g+NwMRsAnKOev2jy0e/JkRqtf3d yD7qdw1+U1NIhUcFtFYB7mEXysSg2IZGYn5+BffrOYyu0cKoQAgzMTvT84PSsUrvIe4M WWuw== MIME-Version: 1.0 X-Received: by 10.220.166.132 with SMTP id m4mr27784vcy.50.1413965772289; Wed, 22 Oct 2014 01:16:12 -0700 (PDT) Received: by 10.31.135.137 with HTTP; Wed, 22 Oct 2014 01:16:12 -0700 (PDT) Date: Wed, 22 Oct 2014 17:16:12 +0900 Message-ID: From: =?UTF-8?B?7J207LKc7Jqx?= To: oauth@ietfa.amsl.com Content-Type: multipart/alternative; boundary=047d7b34353c94fcdb0505fe8f8e Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/1VeHud5qj-u2GSo2C-C4EfNEqGs Subject: [OAUTH-WG] Confirmation of list posting-confirmation ID:VEDJ3wkmWAkq X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 08:16:15 -0000 --047d7b34353c94fcdb0505fe8f8e Content-Type: text/plain; charset=UTF-8 I want to use Vimeo API. What was whether I should write more documents from Oauth. The written description of what to do and where to specifically thank. Thank.. --047d7b34353c94fcdb0505fe8f8e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=C2=A0I want to use Vimeo API. What was whether I should w= rite more documents from Oauth.
The written description of what to do a= nd where to specifically thank.
Thank..
--047d7b34353c94fcdb0505fe8f8e-- From nobody Wed Oct 22 06:34:37 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD621A916F for ; Wed, 22 Oct 2014 06:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.849 X-Spam-Level: X-Spam-Status: No, score=-0.849 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, J_CHICKENPOX_45=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 K5tjPUNDXgxR for ; Wed, 22 Oct 2014 06:34:34 -0700 (PDT) Received: from mail-vc0-x243.google.com (mail-vc0-x243.google.com [IPv6:2607:f8b0:400c:c03::243]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 436971A8F4B for ; Wed, 22 Oct 2014 06:34:34 -0700 (PDT) Received: by mail-vc0-f195.google.com with SMTP id hy10so631972vcb.2 for ; Wed, 22 Oct 2014 06:34:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=4431ml3wcE1I1GR8INzGAhkWdj8Rsxwg/Yc+epj3FBk=; b=YQ/0l2uy6jsFFl3KH2UHngxgaRJMzB7OB2vzB+SKxBI0QKQp7E7Z2XiGF+gt3932e3 HFcAJ3q6z+xmydv27zx0Xz1T+sz644sJjps1NATdALUKd5HrEgxGZu/A3hL4ZRFrqqHM 9zP7O8HHQWwoUp5ndFodSd0Ta1BXQ0dpc9R3/Tq2UV90b6fSNZKq+OYE8YVSh20wff2o CGZLvQXSE+ZqwoEdxJnN8S6WNUtafRiyE0UJtZETMK5bdw+g3KcOb2JYJYYh+C3lIKgE 8RRW2a3HJsnqhqrte0CmCKf1CgcC/mzxmxIjJDA1IAimJI3mzc8zxp1KfhW9ukMQIWDS YVTg== MIME-Version: 1.0 X-Received: by 10.220.195.196 with SMTP id ed4mr528295vcb.65.1413984873360; Wed, 22 Oct 2014 06:34:33 -0700 (PDT) Received: by 10.31.135.137 with HTTP; Wed, 22 Oct 2014 06:34:33 -0700 (PDT) In-Reply-To: References: Date: Wed, 22 Oct 2014 22:34:33 +0900 Message-ID: From: =?UTF-8?B?7J207LKc7Jqx?= To: oauth@ietf.org Content-Type: multipart/alternative; boundary=001a11c1c32418344405060302fb Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/752q86jzaYRW2JZ2DOX8TFnxZVU Subject: Re: [OAUTH-WG] API about X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 13:34:35 -0000 --001a11c1c32418344405060302fb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello.. I want to use Vimeo API. Do not know what to do with concrete. I understand we need to accept that in Oauth. I hope my images taken over the years, many more people to see. My vimeo URL : vimeo.com/user17552256 If you do not know how well I would send ramble. I just need you help.thank. 2014-10-22 15:08 GMT+09:00 =EC=9D=B4=EC=B2=9C=EC=9A=B1 : > Hello.. > I want to use Vimeo API. Do not know what to do with concrete. > I understand we need to accept that in Oauth. I hope my images taken over > the years, > many more people to see. My vimeo URL : vimeo.com/user17552256 > If you do not know how well I would send ramble. > I just need you help.thank. > --001a11c1c32418344405060302fb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=C2=A0Hello..
=C2=A0I want to use Vimeo API. Do not know what to do with concrete.<= /div>
I understan= d we need to accept that in Oauth. I hope my images taken over the years,
many more pe= ople to see. My vimeo URL :=C2=A0vimeo.com/user17552256
If you do not know how well I would send = ramble.
I j= ust need you help.thank.

2014-10-22 15:08 GMT+09:00 =EC=9D=B4=EC=B2=9C=EC=9A=B1 <= span dir=3D"ltr"><nesone112@gmail.com>:
=C2=A0Hello..
=C2=A0I want to use Vimeo API. Do not know= what to do with concrete.
I understand we need to accept that in= Oauth. I hope my images taken over the years,
many more people t= o see. My vimeo URL : vimeo.com/user17552256
If you do not know how well I w= ould send ramble.
I just need you help.thank.

--001a11c1c32418344405060302fb-- From nobody Wed Oct 22 06:52:32 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AECDB1AC3A1 for ; Wed, 22 Oct 2014 06:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.009 X-Spam-Level: X-Spam-Status: No, score=-1.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 fs8KfimULMhP for ; Wed, 22 Oct 2014 06:52:28 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id D3CB71A9245 for ; Wed, 22 Oct 2014 06:52:27 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2E42072E16B; Wed, 22 Oct 2014 09:52:27 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id 23BAD72E149; Wed, 22 Oct 2014 09:52:27 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.78]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.03.0174.001; Wed, 22 Oct 2014 09:52:26 -0400 From: "Richer, Justin P." To: =?utf-8?B?7J207LKc7Jqx?= Thread-Topic: [OAUTH-WG] API about Thread-Index: AQHP7fzvE4BMdxT5hEKdItV/O4vS65w8ZeQA Date: Wed, 22 Oct 2014 13:52:25 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.15.56] Content-Type: multipart/alternative; boundary="_000_DE698183B2404F13B7FE02C7183E2FF5mitreorg_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/b7qnvHI23ZYgVR5yjmgt99ArQvM Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] API about X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 13:52:30 -0000 --_000_DE698183B2404F13B7FE02C7183E2FF5mitreorg_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WW91IHdpbGwgYmUgYmV0dGVyIG9mZiBhc2tpbmcgYSBWaW1lbyBkZXZlbG9wbWVudCBjb21tdW5p dHkgb3IgcG9zdGluZyB5b3VyIHF1ZXN0aW9uIHRvIGEgc2l0ZSBsaWtlIFN0YWNrIE92ZXJmbG93 LiBUaGlzIGxpc3QgaXMgZm9yIHdvcmtpbmcgb24gdGhlIE9BdXRoIHNwZWNpZmljYXRpb25zIHRo ZW1zZWx2ZXMsIG5vdCBmb3Igc3VwcG9ydGluZyBBUElzIHRoYXQgdXNlIE9BdXRoLiBCZXN0IG9m IGx1Y2shDQoNCiAtLSBKdXN0aW4NCg0KDQpPbiBPY3QgMjIsIDIwMTQsIGF0IDk6MzQgQU0sIOyd tOyynOyasSA8bmVzb25lMTEyQGdtYWlsLmNvbTxtYWlsdG86bmVzb25lMTEyQGdtYWlsLmNvbT4+ IHdyb3RlOg0KDQogSGVsbG8uLg0KIEkgd2FudCB0byB1c2UgVmltZW8gQVBJLiBEbyBub3Qga25v dyB3aGF0IHRvIGRvIHdpdGggY29uY3JldGUuDQpJIHVuZGVyc3RhbmQgd2UgbmVlZCB0byBhY2Nl cHQgdGhhdCBpbiBPYXV0aC4gSSBob3BlIG15IGltYWdlcyB0YWtlbiBvdmVyIHRoZSB5ZWFycywN Cm1hbnkgbW9yZSBwZW9wbGUgdG8gc2VlLiBNeSB2aW1lbyBVUkwgOiB2aW1lby5jb20vdXNlcjE3 NTUyMjU2PGh0dHA6Ly92aW1lby5jb20vdXNlcjE3NTUyMjU2Pg0KSWYgeW91IGRvIG5vdCBrbm93 IGhvdyB3ZWxsIEkgd291bGQgc2VuZCByYW1ibGUuDQpJIGp1c3QgbmVlZCB5b3UgaGVscC50aGFu ay4NCg0KMjAxNC0xMC0yMiAxNTowOCBHTVQrMDk6MDAg7J207LKc7JqxIDxuZXNvbmUxMTJAZ21h aWwuY29tPG1haWx0bzpuZXNvbmUxMTJAZ21haWwuY29tPj46DQogSGVsbG8uLg0KIEkgd2FudCB0 byB1c2UgVmltZW8gQVBJLiBEbyBub3Qga25vdyB3aGF0IHRvIGRvIHdpdGggY29uY3JldGUuDQpJ IHVuZGVyc3RhbmQgd2UgbmVlZCB0byBhY2NlcHQgdGhhdCBpbiBPYXV0aC4gSSBob3BlIG15IGlt YWdlcyB0YWtlbiBvdmVyIHRoZSB5ZWFycywNCm1hbnkgbW9yZSBwZW9wbGUgdG8gc2VlLiBNeSB2 aW1lbyBVUkwgOiB2aW1lby5jb20vdXNlcjE3NTUyMjU2PGh0dHA6Ly92aW1lby5jb20vdXNlcjE3 NTUyMjU2Pg0KSWYgeW91IGRvIG5vdCBrbm93IGhvdyB3ZWxsIEkgd291bGQgc2VuZCByYW1ibGUu DQpJIGp1c3QgbmVlZCB5b3UgaGVscC50aGFuay4NCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5v cmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9vYXV0aA0KDQo= --_000_DE698183B2404F13B7FE02C7183E2FF5mitreorg_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiPg0KWW91IHdpbGwgYmUgYmV0dGVyIG9mZiBhc2tpbmcg YSBWaW1lbyBkZXZlbG9wbWVudCBjb21tdW5pdHkgb3IgcG9zdGluZyB5b3VyIHF1ZXN0aW9uIHRv IGEgc2l0ZSBsaWtlIFN0YWNrIE92ZXJmbG93LiBUaGlzIGxpc3QgaXMgZm9yIHdvcmtpbmcgb24g dGhlIE9BdXRoIHNwZWNpZmljYXRpb25zIHRoZW1zZWx2ZXMsIG5vdCBmb3Igc3VwcG9ydGluZyBB UElzIHRoYXQgdXNlIE9BdXRoLiBCZXN0IG9mIGx1Y2shDQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRp dj4mbmJzcDstLSBKdXN0aW48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjxk aXY+DQo8ZGl2Pk9uIE9jdCAyMiwgMjAxNCwgYXQgOTozNCBBTSwg7J207LKc7JqxICZsdDs8YSBo cmVmPSJtYWlsdG86bmVzb25lMTEyQGdtYWlsLmNvbSI+bmVzb25lMTEyQGdtYWlsLmNvbTwvYT4m Z3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdiBkaXI9Imx0ciI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OmFyaWFsLHNhbnMtc2VyaWY7Zm9udC1zaXplOjE0cHgiPiZuYnNwO0hlbGxvLi48 L3NwYW4+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxzYW5zLXNlcmlmO2ZvbnQtc2l6 ZToxNHB4Ij4mbmJzcDtJIHdhbnQgdG8gdXNlIFZpbWVvIEFQSS4gRG8gbm90IGtub3cgd2hhdCB0 byBkbyB3aXRoIGNvbmNyZXRlLjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWws c2Fucy1zZXJpZjtmb250LXNpemU6MTRweCI+SSB1bmRlcnN0YW5kIHdlIG5lZWQgdG8gYWNjZXB0 IHRoYXQgaW4gT2F1dGguIEkgaG9wZSBteSBpbWFnZXMgdGFrZW4gb3ZlciB0aGUgeWVhcnMsPC9k aXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTox NHB4Ij5tYW55IG1vcmUgcGVvcGxlIHRvIHNlZS4gTXkgdmltZW8gVVJMIDombmJzcDs8YSBocmVm PSJodHRwOi8vdmltZW8uY29tL3VzZXIxNzU1MjI1NiIgdGFyZ2V0PSJfYmxhbmsiPnZpbWVvLmNv bS91c2VyMTc1NTIyNTY8L2E+PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxz YW5zLXNlcmlmO2ZvbnQtc2l6ZToxNHB4Ij5JZiB5b3UgZG8gbm90IGtub3cgaG93IHdlbGwgSSB3 b3VsZCBzZW5kIHJhbWJsZS48L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLHNh bnMtc2VyaWY7Zm9udC1zaXplOjE0cHgiPkkganVzdCBuZWVkIHlvdSBoZWxwLnRoYW5rLjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyPg0KPGRpdiBjbGFzcz0iZ21h aWxfcXVvdGUiPjIwMTQtMTAtMjIgMTU6MDggR01UJiM0MzswOTowMCDsnbTsspzsmrEgPHNwYW4g ZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86bmVzb25lMTEyQGdtYWlsLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPm5lc29uZTExMkBnbWFpbC5jb208L2E+Jmd0Ozwvc3Bhbj46PGJyPg0KPGJsb2Nr cXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVy LWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2IGRpcj0ibHRyIj4m bmJzcDtIZWxsby4uDQo8ZGl2PiZuYnNwO0kgd2FudCB0byB1c2UgVmltZW8gQVBJLiBEbyBub3Qg a25vdyB3aGF0IHRvIGRvIHdpdGggY29uY3JldGUuPC9kaXY+DQo8ZGl2PkkgdW5kZXJzdGFuZCB3 ZSBuZWVkIHRvIGFjY2VwdCB0aGF0IGluIE9hdXRoLiBJIGhvcGUgbXkgaW1hZ2VzIHRha2VuIG92 ZXIgdGhlIHllYXJzLDwvZGl2Pg0KPGRpdj5tYW55IG1vcmUgcGVvcGxlIHRvIHNlZS4gTXkgdmlt ZW8gVVJMIDogPGEgaHJlZj0iaHR0cDovL3ZpbWVvLmNvbS91c2VyMTc1NTIyNTYiIHRhcmdldD0i X2JsYW5rIj4NCnZpbWVvLmNvbS91c2VyMTc1NTIyNTY8L2E+PC9kaXY+DQo8ZGl2PklmIHlvdSBk byBub3Qga25vdyBob3cgd2VsbCBJIHdvdWxkIHNlbmQgcmFtYmxlLjwvZGl2Pg0KPGRpdj5JIGp1 c3QgbmVlZCB5b3UgaGVscC50aGFuay48L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8YnI+DQo8L2Rpdj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9B dXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnI+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DE698183B2404F13B7FE02C7183E2FF5mitreorg_-- From nobody Wed Oct 22 12:54:17 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F57F1A047A for ; Wed, 22 Oct 2014 12:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.35 X-Spam-Level: X-Spam-Status: No, score=0.35 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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, J_CHICKENPOX_26=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 lqvihe0iwDN6 for ; Wed, 22 Oct 2014 12:54:14 -0700 (PDT) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A26F11A0451 for ; Wed, 22 Oct 2014 12:54:14 -0700 (PDT) Received: by mail-vc0-f182.google.com with SMTP id la4so2506569vcb.13 for ; Wed, 22 Oct 2014 12:54:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=VAN4gRDLrAN+1LN+wsOhkW4Z+Dc4BbtbndC8d74mZPk=; b=PF5ygdkeNP2nHJn4vgjykTwMza52Fwb5d6OAGQbsTqcHhEGVSaYUHTe303LX45Doe0 +OfK+QEAeRr1oQL63YEm+pnGJIUYcHO266emRorX3tWdyBztrPUMt+dfdNddCSZXh2sE sQwt0gDuAWWwnmgQj0NFLZKSOLRRPP7EM1GZkJHFGHSqLoMQiEDG7QduIX+wQDSHB8Q7 mQCxUCwCx185J+Vj6/gfwrZbqfrUuiVmO1TQjzzWbwBaeQlXW8eRBidWzXNMnS5W6lUW f6Mri/MLw/9EM4DUGjt9B666TGNNp3uxdQWSsKrFz/7rm1qaeO7TLekyIEOgcli6aKDE /73g== MIME-Version: 1.0 X-Received: by 10.52.106.75 with SMTP id gs11mr255085vdb.0.1414007653552; Wed, 22 Oct 2014 12:54:13 -0700 (PDT) Received: by 10.31.135.137 with HTTP; Wed, 22 Oct 2014 12:54:13 -0700 (PDT) Date: Thu, 23 Oct 2014 04:54:13 +0900 Message-ID: From: =?UTF-8?B?7J207LKc7Jqx?= To: oauth@ietfa.amsl.com Content-Type: multipart/alternative; boundary=001a1133cdece6543f0506084fd1 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/wZc1s7iVmxqN_gArc8p3kTuSCxY Subject: [OAUTH-WG] Client ID,Client SECRET?. X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 19:54:15 -0000 --001a1133cdece6543f0506084fd1 Content-Type: text/plain; charset=UTF-8 Hello..I want to use Oauth.The question is not should get used. Vimeo API is impossible without Oauth. Is required the CLIENT ID,CLIENT SECRET. What I do not know what the field because I do not know. I'm sorry if the disturbance. But I want to be exactly registered with Oauth. If possible, please help give. --001a1133cdece6543f0506084fd1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello..I want to use Oauth.The question is not should get = used. Vimeo API is impossible without Oauth.
Is required the CLIENT ID,= CLIENT SECRET. What I do not know what the field because I do not know.
I'm sorry if the disturbance. But I want to be exactly registere= d with Oauth. If possible, please help give.
--001a1133cdece6543f0506084fd1-- From nobody Wed Oct 22 13:08:50 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFCC91A1A0E for ; Wed, 22 Oct 2014 13:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 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, J_CHICKENPOX_26=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 GxhC0taExsjJ for ; Wed, 22 Oct 2014 13:08:46 -0700 (PDT) Received: from mail-ob0-f179.google.com (mail-ob0-f179.google.com [209.85.214.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95FD11A0073 for ; Wed, 22 Oct 2014 13:08:46 -0700 (PDT) Received: by mail-ob0-f179.google.com with SMTP id wp4so3601015obc.10 for ; Wed, 22 Oct 2014 13:08:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=2Xdbk/VLglz2cx1X8XmVSQHlBxIEa4voG7trPgofcU4=; b=ObGZ5Tv4PXbnAMOR4ogi3IcpZigg+kmgAvUaC6sUD7emCQDXqn+gEexCUn9yZ6dYMQ /aR1HwZp5lGOjioZjMOe6CpSaMh/EJFF9Pud6/c6MDfjSli9MWTxnGOtNndvaSr/bhe+ X/i5XaSnpIcy03DCqtSF7SScwZKPnsZsub/P9riRl69lVO35EvgPCr6Go4T+hG6MIRnH IWLIHe4dAyiVkLsZg7OInmO8fBXwDDS7AhOvuR/E3uncaTR5QikeUqmbFSV5bEIWGPQp CvTparIxwu2DjNCN40PeyssxXznkOSURXlKjgMsnq9Tj4NRwherCSFLm3F8ksMdYhem5 mq5Q== X-Received: by 10.182.112.233 with SMTP id it9mr307041obb.8.1414008525790; Wed, 22 Oct 2014 13:08:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.60.70 with HTTP; Wed, 22 Oct 2014 13:08:25 -0700 (PDT) In-Reply-To: References: From: Josh Mandel Date: Wed, 22 Oct 2014 13:08:25 -0700 Message-ID: To: =?UTF-8?B?7J207LKc7Jqx?= Content-Type: multipart/alternative; boundary=089e0149cc0ce3c0670506088301 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/fDzRdkGAtGelvN4jvc1XB0la9hA Cc: oauth@ietfa.amsl.com Subject: Re: [OAUTH-WG] Client ID,Client SECRET?. X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 20:08:48 -0000 --089e0149cc0ce3c0670506088301 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable You'll want to follow Vimeo's instructions -- probably be visiting https://developer.vimeo.com/api and clicking "register your app". If you have any questions, you'll want to visit http://developer.vimeo.com/help . This mailing list is not affiliated with Vimeo, and we can't help you register with Vimeo :-) Best, Josh On Wed, Oct 22, 2014 at 12:54 PM, =EC=9D=B4=EC=B2=9C=EC=9A=B1 wrote: > Hello..I want to use Oauth.The question is not should get used. Vimeo API > is impossible without Oauth. > Is required the CLIENT ID,CLIENT SECRET. What I do not know what the fiel= d > because I do not know. > I'm sorry if the disturbance. But I want to be exactly registered with > Oauth. If possible, please help give. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --089e0149cc0ce3c0670506088301 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
You'll want to follow Vimeo's instructions -- prob= ably be visiting=C2=A0https://developer.vimeo.com/api and clicking "register yo= ur app". If you have any questions, you'll want to visit=C2=A0http://developer.= vimeo.com/help .

This mailing list is not affiliated= with Vimeo, and we can't help you register with Vimeo :-)
Best,

=C2=A0 Josh

On Wed, Oct 22, 2014 at 12:54 P= M, =EC=9D=B4=EC=B2=9C=EC=9A=B1 <nesone112@gmail.com> wrote= :
Hello..I want to use O= auth.The question is not should get used. Vimeo API is impossible without O= auth.
Is required the CLIENT ID,CLIENT SECRET. What I do not know what = the field because I do not know.
I'm sorry if the disturbance= . But I want to be exactly registered with Oauth. If possible, please help = give.

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


--089e0149cc0ce3c0670506088301-- From nobody Wed Oct 22 14:44:56 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD70F1A6FE4 for ; Wed, 22 Oct 2014 14:44: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2VDRzP6HHtML for ; Wed, 22 Oct 2014 14:44:49 -0700 (PDT) Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A6031A6F53 for ; Wed, 22 Oct 2014 14:44:49 -0700 (PDT) Received: by mail-qc0-f176.google.com with SMTP id r5so3446647qcx.21 for ; Wed, 22 Oct 2014 14:44:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=S06+c0MXL501GMwGTCQv5veO5+6bLgDtZetHPZk3WzI=; b=NsxHysdDi6M9tW1Atrxc+n29pxdEev96qtNu7GztNrkyo1Ff4jDPJYqjlMApTFP878 5PHxDOFzsrVYws+pdPxMJmMWuXnanTdClSNHt1HzUJduXPEzI9zaEiL1fj1woPnYKf/g Fy8tdp6lHqT49PblqReWtDwAH9/9Mj/S9jmvZtupkv4KKDdLWFn3O8Vzuo81mINdS0zh mfryRzLfqlzwPU30jptXA4jxG3i40rm1l8Z6wMZqXrG1HpuCy6UDds5usZ7UC3PdCjpG 6RpRbHkB6eKmAekMVIsGAGux41mSIuxAERZEPKXBoTVjpic9GXohqFsr9645162hJ8lF yIRw== X-Gm-Message-State: ALoCoQlQ7UfI4otSeidYV9fNE/pR0DbsF7B5+owD5Vx00VEqlhe/SrPbw5bfDOtootQRQBxX5MA/ X-Received: by 10.229.247.200 with SMTP id md8mr1461462qcb.7.1414014288214; Wed, 22 Oct 2014 14:44:48 -0700 (PDT) Received: from [192.168.8.101] ([201.188.9.153]) by mx.google.com with ESMTPSA id k4sm8739qaj.21.2014.10.22.14.44.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Oct 2014 14:44:47 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_5D8DC698-D03B-4CEB-8EA5-CBD881CCDBFD" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: John Bradley In-Reply-To: Date: Wed, 22 Oct 2014 18:44:35 -0300 Message-Id: References: <4E1F6AAD24975D4BA5B16804296739439BB0D3F3@TK5EX14MBXC286.redmond.corp.microsoft.com> <54465CBF.5070509@cs.tcd.ie> To: Kathleen Moriarty X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/0nWCCCjgumrnPE8KfYd3nJbDzZ0 Cc: "oauth-chairs@tools.ietf.org" , "draft-ietf-oauth-json-web-token@tools.ietf.org" , "oauth@ietf.org" , The IESG Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Oct 2014 21:44:54 -0000 --Apple-Mail=_5D8DC698-D03B-4CEB-8EA5-CBD881CCDBFD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii =46rom a JWT perspective a number of applications including connect = allow unsecured JWT. I guess you are referring to sec 8 of JWT in the OAuth WG. Some of the = threads you mention were in the JOSE WG relating to the JWS spec and if = none should be included. To some extent the issues are not quite the same for the different = specs. SAML certainly allows for unsigned documents, those are used in a lot of = places. I imagine that a SAML library that could not process unsigned = messages would generally be considered broken. That is not to say that it also needs to also support signed ones and = some number of trust models. =20 It is the same for JWT as it lives at a similar conceptual level to SAML = assertions.=20 It is better for interoperability to have all the JWT libs implement = "none", so that it can be supported in the many cases it may be used for = processing JWT protected by transport or some other mechanism, and = reliably reject "none" when signatures are required. The JWT spec is not requiring JWS or JWE to implement support for none, = though likely life would be easier if they did support it. John B. On Oct 21, 2014, at 1:36 PM, Kathleen Moriarty = wrote: >=20 >=20 > On Tue, Oct 21, 2014 at 9:16 AM, Stephen Farrell = wrote: >=20 > Hi Mike, >=20 > I've one remaining discuss point and a comment. See below... >=20 > On 14/10/14 13:50, Mike Jones wrote: > > The proposed resolutions below have been included in the -28 draft. = Hopefully you'll be able to clear your DISCUSSes on that basis. > > > > The String Comparison Rules in Section 7.3 have been expanded to = talk about when the application may need canonicalization rules. > > > > Thanks again, > > -- Mike > > > >> -----Original Message----- > >> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones > >> Sent: Monday, October 06, 2014 7:20 PM > >> To: Stephen Farrell; The IESG > >> Cc: oauth-chairs@tools.ietf.org; draft-ietf-oauth-json-web- > >> token@tools.ietf.org; oauth@ietf.org > >> Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on = draft-ietf-oauth-json- > >> web-token-27: (with DISCUSS and COMMENT) > >> > >> Thanks for tracking all of this Stephen. Responses inline below... > >> > >>> -----Original Message----- > >>> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > >>> Sent: Monday, October 06, 2014 2:43 PM > >>> To: Mike Jones; The IESG > >>> Cc: oauth-chairs@tools.ietf.org; draft-ietf-oauth-json-web- > >>> token@tools.ietf.org; oauth@ietf.org > >>> Subject: Re: Stephen Farrell's Discuss on = draft-ietf-oauth-json-web-token-27: > >>> (with DISCUSS and COMMENT) > >>> > >>> > >>> Hi Mike, > >>> > >>> On 06/10/14 08:54, Mike Jones wrote: > >>>> Thanks for your review, Stephen. I've added the working group to > >>>> the thread so they're aware of your comments. > >>>> > >>>>> -----Original Message----- From: Stephen Farrell > >>>>> [mailto:stephen.farrell@cs.tcd.ie] Sent: Thursday, October 02, = 2014 > >>>>> 5:03 AM To: The IESG Cc: oauth-chairs@tools.ietf.org; > >>>>> draft-ietf-oauth-json-web- token@tools.ietf.org Subject: Stephen > >>>>> Farrell's Discuss on draft-ietf-oauth-json-web-token-27: (with > >>>>> DISCUSS and COMMENT) > >>>>> > >>>>> Stephen Farrell has entered the following ballot position for > >>>>> draft-ietf-oauth-json-web-token-27: Discuss > >>>>> > >>>>> When responding, please keep the subject line intact and reply = to > >>>>> all email addresses included in the To and CC lines. (Feel free = to > >>>>> cut this introductory paragraph, however.) > >>>>> > >>>>> > >>>>> Please refer to > >>>>> http://www.ietf.org/iesg/statement/discuss-criteria.html for = more > >>>>> information about IESG DISCUSS and COMMENT positions. > >>>>> > >>>>> > >>>>> The document, along with other ballot positions, can be found > >>>>> here: > >>>>> http://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/ > >>>>> > >>>>> > >>>>> > >>>>> = ------------------------------------------------------------------- > >>>>> -- > >>>>> - > >>>>> > >>>>> > >>> DISCUSS: > >>>>> = ------------------------------------------------------------------- > >>>>> -- > >>>>> - > >>>>> > >>>>> > >>>>> > >>>>> > >>> (1) 4.1.1 and elsewhere you say case-sensitive: the same thing I > >>> raised wrt DNS > >>>>> names for another JOSE spec - do you need to say those SHOULD be > >>>>> [upper|lower]cased when used in these? > >>>> > >>>> I believe that somewhere we should say that if case-insensitive > >>>> values, such as DNS names, are used when constructing "kid" = values, > >>>> that the application doing so needs to define a convention on the > >>>> canonical case to use for the case-insensitive portions, such as > >>>> lowercasing them. > >>> > >>> As that discussion's happening on the key draft, I'll clear it = here > >>> and trust you to fix if a change is the end result. > >> > >> Thanks >=20 > np >=20 > >> > >>>>> (2) Section 8: Why is "none" MTI? That seems both broken and = going > >>>>> in the oppostite direction from other WGs and so should be > >>>>> explicitly jusified I think. (If a good enough justification = exists > >>>>> that is.) > >>>> > >>>> It is MTI because there are several existing applications of JWTs = in > >>>> which both unsigned and signed representations of the JWTs are > >>>> requirements. These include draft-ietf-oauth-token-exchange, > >>>> draft-hunt-oauth-v2-user-a4c, and OpenID Connect. This is a = pretty > >>>> common pattern where you sign something if the recipient cares = who > >>>> made the statements and where you don't have to sign it either if > >>>> the recipient doesn't care who made the statements > >>> > >>> I don't see how (non-)signers can divine non-verifier's wishes = that > >>> way. (Absent negotiation or a directory.) > >> > >> Sometimes it does occur via negotiation. For instance, in some = protocols, at > >> registration time, relying parties explicitly tell identity = providers what algorithms > >> are acceptable to them, which may include "none". No divination - = explicit > >> communication. > >> > >>>> or if it can tell from > >>>> another secured aspect of the application protocol (typically > >>>> through the use of TLS) who made the statements. In the TLS = case, > >>>> the server authentication step makes a signature step = unnecessary, > >>>> so an Unsecured JWT is fine there. > >>> > >>> That's arguable IMO. > >> > >> I agree that it's application and context-dependent whether it's OK = or not. The > >> point is that there exist some circumstances in which it is OK, and = this feature is > >> being used in some of those cases. > >> > >>> I think I'll look back over the wg thread and either hold my nose = or > >> > >> This issue was tracked as = http://trac.tools.ietf.org/wg/jose/trac/ticket/36. > >> Karen O'Donoghue recorded this conclusion in the tracker "Note: = There was > >> extensive discussion on the mailing list, and the rough consensus = of the working > >> group was to leave "none" in the document." > >> > >> Discussion threads on this topic include: > >> [jose] #36: Algorithm "none" should be removed = http://www.ietf.org/mail- > >> archive/web/jose/current/msg02911.html - Began Jul 31, 2013 (91 = messages) > >> [jose] Text about applications and "alg":"none" = http://www.ietf.org/mail- > >> archive/web/jose/current/msg03321.html - Began Sep 3, 2013 (5 = messages) > >> > >> This issue was a topic of a special working group call on Aug 19, = 2013. The text > >> discussed in the last thread and published at = https://tools.ietf.org/html/draft- > >> ietf-jose-json-web-algorithms-33#section-8.5 (Unsecured JWS = Security > >> Considerations) was the result of the working group's decisions = resulting from all > >> of this discussion. >=20 > Thanks for all the pointers above. I read through all the (many!) > Aug 19 mails and most of the `"none" should be removed" thread. >=20 > So I do see that there was rough consensus to keep "none" in > the draft and can (with difficulty;-) hold my nose and let that > pass. I do not however, see that there was consensus to make > "none" MTI for this draft. I did see a bit of haggling about > this draft vs. JWS but still do not see why none ought be MTI > here. >=20 > >> > >>>>> (3) Section 12: another way to handle privacy is to not include > >>>>> sensitive data - I think you ought mention that as a bit of = thought > >>>>> along those lines can be much simpler than putting in place the = key > >>>>> management to handle thoughtlessly included PII. > >>>> > >>>> We can include a discussion of that point, > >>> > >>> Great. "Just say no" is workable here:-) I'll clear when we get = such text. > >>> > >>>> but sometimes the very > >>>> point of a JWT is to securely deliver PII from a verifiable party = to > >>>> an intended party with appropriate rights to receive it. > >>> > >>> Hmm. Its a moot point (so let's not argue it) but I wonder how = often > >>> PII is really needed for authorization with oauth. My guess would = be > >>> that its needed far less often than its found to be profitable > >>> perhaps, or that carelessness plays a big role in using PII for = such purposes. >=20 > I've cleared on this as you added this text: >=20 > "Of course, including > only necessary privacy-sensitive information in a JWT is the most > basic means of minimizing any potential privacy issues." >=20 > That seems to me like a fairly offputting way to phrase it. I'd > suggest instead: >=20 > "Omitting privacy-sensitive information from a JWT is the > simplest way of minimizing privacy issues." >=20 > I like this wording suggestion, thanks. > =20 >=20 > Cheers, > S. >=20 > PS: I didn't check the comments. >=20 > >>> > >>> S. > >>> > >>> > >>> > >>>> > >>>>> = ------------------------------------------------------------------- > >>>>> -- > >>>>> - > >>>>> > >>>>> > >>> COMMENT: > >>>>> = ------------------------------------------------------------------- > >>>>> -- > >>>>> - > >>>>> > >>>>> > >>>>> > >>>>> > >>> - abstract: 2nd sentence isn't needed here, in intro would be = fine. > >>>> > >>>> I don't know - I think it's a big deal that the claims can be > >>>> digitally signed or MACed and/or encrypted. That's the reason we > >>>> have JWTs, rather than just JSON. > >>>> > >>>>> - 4.1.7: maybe worth adding that jti+iss being unique enough is = not > >>>>> sufficient and jti alone has to meet that need. In X.509 the > >>>>> issuer/serial has the equivalent property so someone might = assume > >>>>> sequential jti values starting at 0 are ok. > >>>> > >>>> Makes sense to add a warning of some kind along these lines. I > >>>> think I know the reasons you say that, but can you expand on that > >>>> thought a bit before I take a stab on writing this up? For > >>>> instance, while normally true, I don't think your observation is > >>>> true if a relying party will only accept tokens from a single = issuer. > >>>> > >>>>> - section 6: yuk > >>>>> > >>>>> - again I think the secdir comments are being handled by = Kathleen > >>>>> and the authors. > >>>> > >>>> Again, this is there because multiple applications asked for the > >>>> ability to represent content that is optionally signed, sometimes > >>>> securing it another way, such as with TLS. JWTs are used = specific > >>>> application protocol contexts - not in isolation. > >>>> > >>>> Thanks again, -- Mike > >>>> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > >=20 >=20 >=20 >=20 > --=20 >=20 > Best regards, > Kathleen --Apple-Mail=_5D8DC698-D03B-4CEB-8EA5-CBD881CCDBFD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii =46rom = a JWT perspective a number of applications including connect allow = unsecured JWT.

I guess you are referring to sec 8 of = JWT in the OAuth WG.  Some of the threads you mention were in the = JOSE WG relating to the JWS spec and if none should be = included.

To some extent the issues are not = quite the same for the different specs.

SAML = certainly allows for unsigned documents, those are used in a lot of = places.  I imagine that a SAML library that could not process = unsigned messages would generally be considered broken.
That = is not to say that it also needs to also support signed ones and some = number of trust models.  

It is the same = for JWT as it lives at a similar conceptual level to SAML = assertions. 

It is better for = interoperability to have all the JWT libs implement "none", so that it = can be supported in the many cases it may be used for processing JWT = protected by transport or some other mechanism, and reliably reject = "none" when signatures are required.

The JWT = spec is not requiring JWS or JWE to implement support for none, =  though likely life would be easier if they did support = it.

John = B.



On Oct 21, = 2014, at 1:36 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gm= ail.com> wrote:



On Tue, Oct 21, 2014 at 9:16 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:

Hi Mike,

I've = one remaining discuss point and a comment. See below...

On 14/10/14 13:50, Mike Jones wrote:
> The = proposed resolutions below have been included in the -28 draft.  = Hopefully you'll be able to clear your DISCUSSes on that = basis.
>
> The String Comparison Rules in Section 7.3 have = been expanded to talk about when the application may need = canonicalization rules.
>
>        =                     =    Thanks again,
>          =                     =  -- Mike
>
>> -----Original Message-----
>> = From: OAuth [mailto:oauth-bounces@ietf.org] On = Behalf Of Mike Jones
>> Sent: Monday, October 06, 2014 7:20 = PM
>> To: Stephen Farrell; The IESG
>> Cc: oauth-chairs@tools.ietf.org; draft-ietf-oauth-json-web-
>> token@tools.ietf.org; oauth@ietf.org
>> Subject: = Re: [OAUTH-WG] Stephen Farrell's Discuss on = draft-ietf-oauth-json-
>> web-token-27: (with DISCUSS and = COMMENT)
>>
>> Thanks for tracking all of this = Stephen.  Responses inline below...
>>
>>> = -----Original Message-----
>>> From: Stephen Farrell = [mailto:stephen.farrell@cs.tcd.ie]>>> Sent: Monday, October 06, 2014 2:43 PM
>>> = To: Mike Jones; The IESG
>>> Cc: oauth-chairs@tools.ietf.org; draft-ietf-oauth-json-web-
>>> token@tools.ietf.org; oauth@ietf.org
>>> = Subject: Re: Stephen Farrell's Discuss on = draft-ietf-oauth-json-web-token-27:
>>> (with DISCUSS and = COMMENT)
>>>
>>>
>>> Hi = Mike,
>>>
>>> On 06/10/14 08:54, Mike Jones = wrote:
>>>> Thanks for your review, Stephen.  I've = added the working group to
>>>> the thread so they're = aware of your comments.
>>>>
>>>>> = -----Original Message----- From: Stephen Farrell
>>>>> = [mailto:stephen.farrell@cs.tcd.ie] = Sent: Thursday, October 02, 2014
>>>>> 5:03 AM To: The = IESG Cc: oauth-chairs@tools.ietf.org;
>>>>> draft-ietf-oauth-json-web- token@tools.ietf.org Subject: = Stephen
>>>>> Farrell's Discuss on = draft-ietf-oauth-json-web-token-27: (with
>>>>> = DISCUSS and COMMENT)
>>>>>
>>>>> = Stephen Farrell has entered the following ballot position = for
>>>>> draft-ietf-oauth-json-web-token-27: = Discuss
>>>>>
>>>>> When responding, = please keep the subject line intact and reply to
>>>>> = all email addresses included in the To and CC lines. (Feel free = to
>>>>> cut this introductory paragraph, = however.)
>>>>>
>>>>>
>>>&= gt;> Please refer to
>>>>> http://www.ietf.org/iesg/statement/discuss-criteria.html=  for = more
>>>>> information about IESG DISCUSS and COMMENT = positions.
>>>>>
>>>>>
>>>= >> The document, along with other ballot positions, can be = found
>>>>> here:
>>>>> http://datatracker.ietf.org/doc/draft-ietf-oauth-json-we= b-token/
>>>>>
>>>>>
>>&g= t;>>
>>>>> = -------------------------------------------------------------------
>= ;>>>> --
>>>>> = -
>>>>>
>>>>>
>>> = DISCUSS:
>>>>> = -------------------------------------------------------------------
>= ;>>>> --
>>>>> = -
>>>>>
>>>>>
>>>>><= br>>>>>>
>>> (1) 4.1.1 and elsewhere you say = case-sensitive: the same thing I
>>> raised wrt = DNS
>>>>> names for another JOSE spec - do you need to = say those SHOULD be
>>>>> [upper|lower]cased when used = in these?
>>>>
>>>> I believe that = somewhere we should say that if case-insensitive
>>>> = values, such as DNS names, are used when constructing "kid" = values,
>>>> that the application doing so needs to = define a convention on the
>>>> canonical case to use for = the case-insensitive portions, such as
>>>> lowercasing = them.
>>>
>>> As that discussion's happening on = the key draft, I'll clear it here
>>> and trust you to fix = if a change is the end result.
>>
>> = Thanks

np

>>
>>>>> (2) Section 8: Why is = "none" MTI? That seems both broken and going
>>>>> in = the oppostite direction from other WGs and so should = be
>>>>> explicitly jusified I think. (If a good = enough justification exists
>>>>> that = is.)
>>>>
>>>> It is MTI because there are = several existing applications of JWTs in
>>>> which both = unsigned and signed representations of the JWTs are
>>>> = requirements.  These include = draft-ietf-oauth-token-exchange,
>>>> = draft-hunt-oauth-v2-user-a4c, and OpenID Connect.  This is a = pretty
>>>> common pattern where you sign something if = the recipient cares who
>>>> made the statements and = where you don't have to sign it either if
>>>> the = recipient doesn't care who made the = statements
>>>
>>> I don't see how (non-)signers = can divine non-verifier's wishes that
>>> way. (Absent = negotiation or a directory.)
>>
>> Sometimes it does = occur via negotiation.  For instance, in some protocols, = at
>> registration time, relying parties explicitly tell = identity providers what algorithms
>> are acceptable to them, = which may include "none".  No divination - explicit
>> = communication.
>>
>>>> or if it can tell = from
>>>> another secured aspect of the application = protocol (typically
>>>> through the use of TLS) who made = the statements.  In the TLS case,
>>>> the server = authentication step makes a signature step = unnecessary,
>>>> so an Unsecured JWT is fine = there.
>>>
>>> That's arguable = IMO.
>>
>> I agree that it's application and = context-dependent whether it's OK or not.  The
>> point is = that there exist some circumstances in which it is OK, and this feature = is
>> being used in some of those = cases.
>>
>>> I think I'll look back over the wg = thread and either hold my nose or
>>
>> This issue was = tracked as http://trac.tools.ietf.org/wg/jose/trac/ticket/36.>> Karen O'Donoghue recorded this conclusion in the tracker = "Note: There was
>> extensive discussion on the mailing list, = and the rough  consensus of the working
>> group was to = leave "none" in the document."
>>
>> Discussion = threads on this topic include:
>> [jose] #36: Algorithm "none" = should be removed http://www.ietf.org/mail-
>> = archive/web/jose/current/msg02911.html - Began Jul 31, 2013  (91 = messages)
>> [jose] Text about applications and = "alg":"none" http://www.ietf.org/mail-
>> = archive/web/jose/current/msg03321.html - Began Sep 3, 2013 (5 = messages)
>>
>> This issue was a topic of a special = working group call on Aug 19, 2013.  The text
>> discussed = in the last thread and published at https://tools.ietf.org/html/draft-
>> = ietf-jose-json-web-algorithms-33#section-8.5 (Unsecured JWS = Security
>> Considerations) was the result of the working = group's decisions resulting from all
>> of this = discussion.

Thanks for all the pointers above. I read = through all the (many!)
Aug 19 mails and most of the `"none" should = be removed" thread.

So I do see that there was rough consensus to = keep "none" in
the draft and can (with difficulty;-) hold my nose and = let that
pass. I do not however, see that there was consensus to = make
"none" MTI for this draft. I did see a bit of haggling = about
this draft vs. JWS but still do not see why none ought be = MTI
here.

>>
>>>>> = (3) Section 12: another way to handle privacy is to not = include
>>>>> sensitive data - I think you ought = mention that as a bit of thought
>>>>> along those = lines can be much simpler than putting in place the = key
>>>>> management to handle thoughtlessly included = PII.
>>>>
>>>> We can include a discussion = of that point,
>>>
>>> Great. "Just say no" is = workable here:-) I'll clear when we get such = text.
>>>
>>>> but sometimes the = very
>>>> point of a JWT is to securely deliver PII from = a verifiable party to
>>>> an intended party with = appropriate rights to receive it.
>>>
>>> Hmm. = Its a moot point (so let's not argue it) but I wonder how = often
>>> PII is really needed for authorization with oauth. = My guess would be
>>> that its needed far less often than = its found to be profitable
>>> perhaps, or that carelessness = plays a big role in using PII for such purposes.

I've = cleared on this as you added this text:

  "Of course, = including
   only necessary privacy-sensitive information = in a JWT is the most
   basic means of minimizing any = potential privacy issues."

That seems to me like a fairly = offputting way to phrase it. I'd
suggest instead:

  "Omitting privacy-sensitive = information from a JWT is the
  simplest way of minimizing = privacy issues."

I like this wording = suggestion, thanks.
 

Cheers,
S.

PS: I didn't check the comments.

>>>
>>> = S.
>>>
>>>
>>>
>>>>
= >>>>> = -------------------------------------------------------------------
>= ;>>>> --
>>>>> = -
>>>>>
>>>>>
>>> = COMMENT:
>>>>> = -------------------------------------------------------------------
>= ;>>>> --
>>>>> = -
>>>>>
>>>>>
>>>>><= br>>>>>>
>>> - abstract: 2nd sentence isn't = needed here, in intro would be = fine.
>>>>
>>>> I don't know - I think = it's a big deal that the claims can be
>>>> digitally = signed or MACed and/or encrypted.  That's the reason = we
>>>> have JWTs, rather than just = JSON.
>>>>
>>>>> - 4.1.7: maybe worth = adding that jti+iss being unique enough is not
>>>>> = sufficient and jti alone has to meet that need. In X.509 = the
>>>>> issuer/serial has the equivalent property so = someone might assume
>>>>> sequential jti values = starting at 0 are ok.
>>>>
>>>> Makes = sense to add a warning of some kind along these lines.  = I
>>>> think I know the reasons you say that, but can you = expand on that
>>>> thought a bit before I take a stab on = writing this up?  For
>>>> instance, while normally = true, I don't think your observation is
>>>> true if a = relying party will only accept tokens from a single = issuer.
>>>>
>>>>> - section 6: = yuk
>>>>>
>>>>> - again I think the = secdir comments are being handled by Kathleen
>>>>> = and the authors.
>>>>
>>>> Again, this is = there because multiple applications asked for the
>>>> = ability to represent content that is optionally signed, = sometimes
>>>> securing it another way, such as with = TLS.  JWTs are used specific
>>>> application = protocol contexts - not in = isolation.
>>>>
>>>> Thanks again, -- = Mike
>>>>
>> = _______________________________________________
>> OAuth = mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
><= br>



-- 

Best = regards,
Kathleen

= --Apple-Mail=_5D8DC698-D03B-4CEB-8EA5-CBD881CCDBFD-- From nobody Thu Oct 23 01:58:12 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A42D21A890C; Thu, 23 Oct 2014 01:58:09 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3VNP1CO9FLFZ; Thu, 23 Oct 2014 01:58:04 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D6601A1A2C; Thu, 23 Oct 2014 01:58:03 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id p9so460444lbv.19 for ; Thu, 23 Oct 2014 01:58:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=P7R9Uc5/R7IVHxj93Ab1QRJ1W0V81iVH2poCl80uxis=; b=c3pQ/04pQHQ9SzNJiSfbIqHPtMPV9pK4zG3tGhp1+YiT4N5mzqFEvr1vhDv8aS2CUD mxCrmjE9cL1d9yY865gsw409GyY/LMwTD6Lon5slMTSMEsYC6Ft3bxUbLN57Z4KmJzac CyD5VfZp2ibKmH8pNSlXALqF5XGoS3k2V6fDik3K4nPdp02T/ne1D4JzX5+/eR/NaDX7 JsBfq1i1c14jOSVpXVEKi+9KP11lGIdi7sq3TA6FDlFLq5j3Q7EGdFMPSWrpUgxj6pMm fPi2xuDbH4+UFG25ifm2hMRt8DxLD41LqTQb/op60k0zkkgsexYhZbDTxdrdnn6zVlxR dKNQ== MIME-Version: 1.0 X-Received: by 10.152.1.130 with SMTP id 2mr1865717lam.89.1414054681563; Thu, 23 Oct 2014 01:58:01 -0700 (PDT) Received: by 10.112.166.7 with HTTP; Thu, 23 Oct 2014 01:58:01 -0700 (PDT) In-Reply-To: References: <4E1F6AAD24975D4BA5B16804296739439BB0D3F3@TK5EX14MBXC286.redmond.corp.microsoft.com> <54465CBF.5070509@cs.tcd.ie> Date: Thu, 23 Oct 2014 03:58:01 -0500 Message-ID: From: Nat Sakimura To: John Bradley Content-Type: multipart/alternative; boundary=089e013c674efcdcb40506134212 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/k3CifMSB8lBGl5Fvc0bZ0Fk9mZY Cc: The IESG , "oauth@ietf.org" , "oauth-chairs@tools.ietf.org" , "draft-ietf-oauth-json-web-token@tools.ietf.org" Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 08:58:09 -0000 --089e013c674efcdcb40506134212 Content-Type: text/plain; charset=UTF-8 I second John's message. There are many ways to achieve a desired level of security and one of the most popular way is to delegate it to the transport layer and use 'none' as the alg. If 'none' becomes non-MTI, then it may cause a lot of interoperability issues down the road. Adding to it, JWT can be useful in other context than security as well. As interoperability is one of the most important criteria, having 'none' as MTI seems to be a reasonable idea to me. Nat 2014-10-22 16:44 GMT-05:00 John Bradley : > From a JWT perspective a number of applications including connect allow > unsecured JWT. > > I guess you are referring to sec 8 of JWT in the OAuth WG. Some of the > threads you mention were in the JOSE WG relating to the JWS spec and if > none should be included. > > To some extent the issues are not quite the same for the different specs. > > SAML certainly allows for unsigned documents, those are used in a lot of > places. I imagine that a SAML library that could not process unsigned > messages would generally be considered broken. > That is not to say that it also needs to also support signed ones and some > number of trust models. > > It is the same for JWT as it lives at a similar conceptual level to SAML > assertions. > > It is better for interoperability to have all the JWT libs implement > "none", so that it can be supported in the many cases it may be used for > processing JWT protected by transport or some other mechanism, and reliably > reject "none" when signatures are required. > > The JWT spec is not requiring JWS or JWE to implement support for none, > though likely life would be easier if they did support it. > > John B. > > > > On Oct 21, 2014, at 1:36 PM, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > > > > On Tue, Oct 21, 2014 at 9:16 AM, Stephen Farrell < > stephen.farrell@cs.tcd.ie> wrote: > >> >> Hi Mike, >> >> I've one remaining discuss point and a comment. See below... >> >> On 14/10/14 13:50, Mike Jones wrote: >> > The proposed resolutions below have been included in the -28 draft. >> Hopefully you'll be able to clear your DISCUSSes on that basis. >> > >> > The String Comparison Rules in Section 7.3 have been expanded to talk >> about when the application may need canonicalization rules. >> > >> > Thanks again, >> > -- Mike >> > >> >> -----Original Message----- >> >> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones >> >> Sent: Monday, October 06, 2014 7:20 PM >> >> To: Stephen Farrell; The IESG >> >> Cc: oauth-chairs@tools.ietf.org; draft-ietf-oauth-json-web- >> >> token@tools.ietf.org; oauth@ietf.org >> >> Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on >> draft-ietf-oauth-json- >> >> web-token-27: (with DISCUSS and COMMENT) >> >> >> >> Thanks for tracking all of this Stephen. Responses inline below... >> >> >> >>> -----Original Message----- >> >>> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] >> >>> Sent: Monday, October 06, 2014 2:43 PM >> >>> To: Mike Jones; The IESG >> >>> Cc: oauth-chairs@tools.ietf.org; draft-ietf-oauth-json-web- >> >>> token@tools.ietf.org; oauth@ietf.org >> >>> Subject: Re: Stephen Farrell's Discuss on >> draft-ietf-oauth-json-web-token-27: >> >>> (with DISCUSS and COMMENT) >> >>> >> >>> >> >>> Hi Mike, >> >>> >> >>> On 06/10/14 08:54, Mike Jones wrote: >> >>>> Thanks for your review, Stephen. I've added the working group to >> >>>> the thread so they're aware of your comments. >> >>>> >> >>>>> -----Original Message----- From: Stephen Farrell >> >>>>> [mailto:stephen.farrell@cs.tcd.ie] Sent: Thursday, October 02, 2014 >> >>>>> 5:03 AM To: The IESG Cc: oauth-chairs@tools.ietf.org; >> >>>>> draft-ietf-oauth-json-web- token@tools.ietf.org Subject: Stephen >> >>>>> Farrell's Discuss on draft-ietf-oauth-json-web-token-27: (with >> >>>>> DISCUSS and COMMENT) >> >>>>> >> >>>>> Stephen Farrell has entered the following ballot position for >> >>>>> draft-ietf-oauth-json-web-token-27: Discuss >> >>>>> >> >>>>> When responding, please keep the subject line intact and reply to >> >>>>> all email addresses included in the To and CC lines. (Feel free to >> >>>>> cut this introductory paragraph, however.) >> >>>>> >> >>>>> >> >>>>> Please refer to >> >>>>> http://www.ietf.org/iesg/statement/discuss-criteria.html for more >> >>>>> information about IESG DISCUSS and COMMENT positions. >> >>>>> >> >>>>> >> >>>>> The document, along with other ballot positions, can be found >> >>>>> here: >> >>>>> http://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/ >> >>>>> >> >>>>> >> >>>>> >> >>>>> ------------------------------------------------------------------- >> >>>>> -- >> >>>>> - >> >>>>> >> >>>>> >> >>> DISCUSS: >> >>>>> ------------------------------------------------------------------- >> >>>>> -- >> >>>>> - >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>> (1) 4.1.1 and elsewhere you say case-sensitive: the same thing I >> >>> raised wrt DNS >> >>>>> names for another JOSE spec - do you need to say those SHOULD be >> >>>>> [upper|lower]cased when used in these? >> >>>> >> >>>> I believe that somewhere we should say that if case-insensitive >> >>>> values, such as DNS names, are used when constructing "kid" values, >> >>>> that the application doing so needs to define a convention on the >> >>>> canonical case to use for the case-insensitive portions, such as >> >>>> lowercasing them. >> >>> >> >>> As that discussion's happening on the key draft, I'll clear it here >> >>> and trust you to fix if a change is the end result. >> >> >> >> Thanks >> >> np >> >> >> >> >>>>> (2) Section 8: Why is "none" MTI? That seems both broken and going >> >>>>> in the oppostite direction from other WGs and so should be >> >>>>> explicitly jusified I think. (If a good enough justification exists >> >>>>> that is.) >> >>>> >> >>>> It is MTI because there are several existing applications of JWTs in >> >>>> which both unsigned and signed representations of the JWTs are >> >>>> requirements. These include draft-ietf-oauth-token-exchange, >> >>>> draft-hunt-oauth-v2-user-a4c, and OpenID Connect. This is a pretty >> >>>> common pattern where you sign something if the recipient cares who >> >>>> made the statements and where you don't have to sign it either if >> >>>> the recipient doesn't care who made the statements >> >>> >> >>> I don't see how (non-)signers can divine non-verifier's wishes that >> >>> way. (Absent negotiation or a directory.) >> >> >> >> Sometimes it does occur via negotiation. For instance, in some >> protocols, at >> >> registration time, relying parties explicitly tell identity providers >> what algorithms >> >> are acceptable to them, which may include "none". No divination - >> explicit >> >> communication. >> >> >> >>>> or if it can tell from >> >>>> another secured aspect of the application protocol (typically >> >>>> through the use of TLS) who made the statements. In the TLS case, >> >>>> the server authentication step makes a signature step unnecessary, >> >>>> so an Unsecured JWT is fine there. >> >>> >> >>> That's arguable IMO. >> >> >> >> I agree that it's application and context-dependent whether it's OK or >> not. The >> >> point is that there exist some circumstances in which it is OK, and >> this feature is >> >> being used in some of those cases. >> >> >> >>> I think I'll look back over the wg thread and either hold my nose or >> >> >> >> This issue was tracked as >> http://trac.tools.ietf.org/wg/jose/trac/ticket/36. >> >> Karen O'Donoghue recorded this conclusion in the tracker "Note: There >> was >> >> extensive discussion on the mailing list, and the rough consensus of >> the working >> >> group was to leave "none" in the document." >> >> >> >> Discussion threads on this topic include: >> >> [jose] #36: Algorithm "none" should be removed >> http://www.ietf.org/mail- >> >> archive/web/jose/current/msg02911.html - Began Jul 31, 2013 (91 >> messages) >> >> [jose] Text about applications and "alg":"none" >> http://www.ietf.org/mail- >> >> archive/web/jose/current/msg03321.html - Began Sep 3, 2013 (5 messages) >> >> >> >> This issue was a topic of a special working group call on Aug 19, >> 2013. The text >> >> discussed in the last thread and published at >> https://tools.ietf.org/html/draft- >> >> ietf-jose-json-web-algorithms-33#section-8.5 (Unsecured JWS Security >> >> Considerations) was the result of the working group's decisions >> resulting from all >> >> of this discussion. >> >> Thanks for all the pointers above. I read through all the (many!) >> Aug 19 mails and most of the `"none" should be removed" thread. >> >> So I do see that there was rough consensus to keep "none" in >> the draft and can (with difficulty;-) hold my nose and let that >> pass. I do not however, see that there was consensus to make >> "none" MTI for this draft. I did see a bit of haggling about >> this draft vs. JWS but still do not see why none ought be MTI >> here. >> >> >> >> >>>>> (3) Section 12: another way to handle privacy is to not include >> >>>>> sensitive data - I think you ought mention that as a bit of thought >> >>>>> along those lines can be much simpler than putting in place the key >> >>>>> management to handle thoughtlessly included PII. >> >>>> >> >>>> We can include a discussion of that point, >> >>> >> >>> Great. "Just say no" is workable here:-) I'll clear when we get such >> text. >> >>> >> >>>> but sometimes the very >> >>>> point of a JWT is to securely deliver PII from a verifiable party to >> >>>> an intended party with appropriate rights to receive it. >> >>> >> >>> Hmm. Its a moot point (so let's not argue it) but I wonder how often >> >>> PII is really needed for authorization with oauth. My guess would be >> >>> that its needed far less often than its found to be profitable >> >>> perhaps, or that carelessness plays a big role in using PII for such >> purposes. >> >> I've cleared on this as you added this text: >> >> "Of course, including >> only necessary privacy-sensitive information in a JWT is the most >> basic means of minimizing any potential privacy issues." >> >> That seems to me like a fairly offputting way to phrase it. I'd >> suggest instead: >> >> "Omitting privacy-sensitive information from a JWT is the >> simplest way of minimizing privacy issues." >> > > I like this wording suggestion, thanks. > > >> >> Cheers, >> S. >> >> PS: I didn't check the comments. >> >> >>> >> >>> S. >> >>> >> >>> >> >>> >> >>>> >> >>>>> ------------------------------------------------------------------- >> >>>>> -- >> >>>>> - >> >>>>> >> >>>>> >> >>> COMMENT: >> >>>>> ------------------------------------------------------------------- >> >>>>> -- >> >>>>> - >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>> - abstract: 2nd sentence isn't needed here, in intro would be fine. >> >>>> >> >>>> I don't know - I think it's a big deal that the claims can be >> >>>> digitally signed or MACed and/or encrypted. That's the reason we >> >>>> have JWTs, rather than just JSON. >> >>>> >> >>>>> - 4.1.7: maybe worth adding that jti+iss being unique enough is not >> >>>>> sufficient and jti alone has to meet that need. In X.509 the >> >>>>> issuer/serial has the equivalent property so someone might assume >> >>>>> sequential jti values starting at 0 are ok. >> >>>> >> >>>> Makes sense to add a warning of some kind along these lines. I >> >>>> think I know the reasons you say that, but can you expand on that >> >>>> thought a bit before I take a stab on writing this up? For >> >>>> instance, while normally true, I don't think your observation is >> >>>> true if a relying party will only accept tokens from a single issuer. >> >>>> >> >>>>> - section 6: yuk >> >>>>> >> >>>>> - again I think the secdir comments are being handled by Kathleen >> >>>>> and the authors. >> >>>> >> >>>> Again, this is there because multiple applications asked for the >> >>>> ability to represent content that is optionally signed, sometimes >> >>>> securing it another way, such as with TLS. JWTs are used specific >> >>>> application protocol contexts - not in isolation. >> >>>> >> >>>> Thanks again, -- Mike >> >>>> >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/oauth >> > >> >> > > > -- > > Best regards, > Kathleen > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --089e013c674efcdcb40506134212 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I second John's message. There are many ways to achiev= e a desired level of security and one of the most popular way is to delegat= e it to the transport layer and use 'none' as the alg. If 'none= ' becomes non-MTI, then it may cause a lot of interoperability issues d= own the road.=C2=A0

Adding to it, JWT can be useful in o= ther context than security as well. As interoperability is one of the most = important criteria, having 'none' as MTI seems to be a reasonable i= dea to me.=C2=A0

Nat

2014-10-22 16:44 GMT-05:00 John Bra= dley <ve7jtb@ve7jtb.com>:
=
From a JWT perspective a number of appl= ications including connect allow unsecured JWT.

I guess = you are referring to sec 8 of JWT in the OAuth WG.=C2=A0 Some of the thread= s you mention were in the JOSE WG relating to the JWS spec and if none shou= ld be included.

To some extent the issues are not = quite the same for the different specs.

SAML certa= inly allows for unsigned documents, those are used in a lot of places.=C2= =A0 I imagine that a SAML library that could not process unsigned messages = would generally be considered broken.
That is not to say that it = also needs to also support signed ones and some number of trust models. =C2= =A0

It is the same for JWT as it lives at a simila= r conceptual level to SAML assertions.=C2=A0

It is= better for interoperability to have all the JWT libs implement "none&= quot;, so that it can be supported in the many cases it may be used for pro= cessing JWT protected by transport or some other mechanism, and reliably re= ject "none" when signatures are required.

The JWT spec is not requiring JWS or JWE to implement support for none, = =C2=A0though likely life would be easier if they did support it.
=
John B.


=

On Oct 21, 2014, at 1:36 PM, Kathleen Moriarty <= ;kath= leen.moriarty.ietf@gmail.com> wrote:



On Tue, Oct 21, 20= 14 at 9:16 AM, Stephen Farrell=C2=A0<stephen.farrell@= cs.tcd.ie>=C2=A0wrote:

H= i Mike,

I've one remaining discuss point and a comment. See belo= w...

On 14/10/14 13:50, Mike Jones wrote:
> The prop= osed resolutions below have been included in the -28 draft.=C2=A0 Hopefully= you'll be able to clear your DISCUSSes on that basis.
>
> = The String Comparison Rules in Section 7.3 have been expanded to talk about= when the application may need canonicalization rules.
>
>=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thanks again,
>=C2=A0 =C2=A0 =C2=A0= =C2=A0 =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 [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
>&g= t; Sent: Monday, October 06, 2014 7:20 PM
>> To: Stephen Farrell; = The IESG
>> Cc:=C2=A0oauth-chairs@tools.ietf.org; draft-iet= f-oauth-json-web-
>>=C2=A0token@tools.ietf.org;=C2=A0= oauth@ietf.org
&= gt;> Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf= -oauth-json-
>> web-token-27: (with DISCUSS and COMMENT)
>&g= t;
>> Thanks for tracking all of this Stephen.=C2=A0 Responses inl= ine below...
>>
>>> -----Original Message-----
>= >> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]
>>> S= ent: Monday, October 06, 2014 2:43 PM
>>> To: Mike Jones; The I= ESG
>>> Cc:=C2=A0oauth-chairs@tools.ietf.org; draft-ietf= -oauth-json-web-
>>>=C2=A0token@tools.ietf.org;=C2=A0oauth@ietf.org>>> Subject: Re: Stephen Farrell's Discuss on draft-ietf-oau= th-json-web-token-27:
>>> (with DISCUSS and COMMENT)
>>= ;>
>>>
>>> Hi Mike,
>>>
>>&= gt; On 06/10/14 08:54, Mike Jones wrote:
>>>> Thanks for you= r review, Stephen.=C2=A0 I've added the working group to
>>>= ;> the thread so they're aware of your comments.
>>>>=
>>>>> -----Original Message----- From: Stephen Farrell>>>>> [mailto:stephen.farrell@cs.tcd.ie] Sent: Thursday, October 0= 2, 2014
>>>>> 5:03 AM To: The IESG Cc:=C2=A0= oauth-chai= rs@tools.ietf.org;
>>>>> draft-ietf-oauth-json-web-=C2=A0= token@tools.ietf.org=C2=A0Subject: Stephen
>>>= >> Farrell's Discuss on draft-ietf-oauth-json-web-token-27: (with=
>>>>> DISCUSS and COMMENT)
>>>>>
&g= t;>>>> Stephen Farrell has entered the following ballot positio= n for
>>>>> draft-ietf-oauth-json-web-token-27: Discuss>>>>>
>>>>> When responding, please keep= the subject line intact and reply to
>>>>> all email add= resses included in the To and CC lines. (Feel free to
>>>>&g= t; cut this introductory paragraph, however.)
>>>>>
&g= t;>>>>
>>>>> Please refer to
>>>&= gt;>=C2=A0http://www.ietf.org/iesg/statement/di= scuss-criteria.html=C2=A0for more
>>>>> = information about IESG DISCUSS and COMMENT positions.
>>>>&g= t;
>>>>>
>>>>> The document, along with= other ballot positions, can be found
>>>>> here:
>= >>>>=C2=A0http://datatracker.i= etf.org/doc/draft-ietf-oauth-json-web-token/
>>>>>>>>>>
>>>>>
>>>>> -----= --------------------------------------------------------------
>>&= gt;>> --
>>>>> -
>>>>>
>>= ;>>>
>>> DISCUSS:
>>>>> ------------= -------------------------------------------------------
>>>>= > --
>>>>> -
>>>>>
>>>&g= t;>
>>>>>
>>>>>
>>> (1) = 4.1.1 and elsewhere you say case-sensitive: the same thing I
>>>= ; raised wrt DNS
>>>>> names for another JOSE spec - do y= ou need to say those SHOULD be
>>>>> [upper|lower]cased w= hen used in these?
>>>>
>>>> I believe that s= omewhere we should say that if case-insensitive
>>>> values,= such as DNS names, are used when constructing "kid" values,
&= gt;>>> that the application doing so needs to define a convention = on the
>>>> canonical case to use for the case-insensitive p= ortions, such as
>>>> lowercasing them.
>>>
&= gt;>> As that discussion's happening on the key draft, I'll c= lear it here
>>> and trust you to fix if a change is the end re= sult.
>>
>> Thanks

np
>>
>>>>> (2) Section 8: Why is "none" MT= I? That seems both broken and going
>>>>> in the oppostit= e direction from other WGs and so should be
>>>>> explici= tly jusified I think. (If a good enough justification exists
>>>= ;>> that is.)
>>>>
>>>> It is MTI becau= se there are several existing applications of JWTs in
>>>> w= hich both unsigned and signed representations of the JWTs are
>>&g= t;> requirements.=C2=A0 These include draft-ietf-oauth-token-exchange,>>>> draft-hunt-oauth-v2-user-a4c, and OpenID Connect.=C2=A0 = This is a pretty
>>>> common pattern where you sign somethin= g if the recipient cares who
>>>> made the statements and wh= ere you don't have to sign it either if
>>>> the recipie= nt doesn't care who made the statements
>>>
>>>= I don't see how (non-)signers can divine non-verifier's wishes tha= t
>>> way. (Absent negotiation or a directory.)
>>
= >> Sometimes it does occur via negotiation.=C2=A0 For instance, in so= me protocols, at
>> registration time, relying parties explicitly = tell identity providers what algorithms
>> are acceptable to them,= which may include "none".=C2=A0 No divination - explicit
>= > communication.
>>
>>>> or if it can tell from<= br>>>>> another secured aspect of the application protocol (typ= ically
>>>> through the use of TLS) who made the statements.= =C2=A0 In the TLS case,
>>>> the server authentication step = makes a signature step unnecessary,
>>>> so an Unsecured JWT= is fine there.
>>>
>>> That's arguable IMO.>>
>> I agree that it's application and context-depende= nt whether it's OK or not.=C2=A0 The
>> point is that there ex= ist some circumstances in which it is OK, and this feature is
>> b= eing used in some of those cases.
>>
>>> I think I'= ;ll look back over the wg thread and either hold my nose or
>>
= >> This issue was tracked as=C2=A0http://trac.tools= .ietf.org/wg/jose/trac/ticket/36.
>> Karen O'Donoghue reco= rded this conclusion in the tracker "Note: There was
>> exten= sive discussion on the mailing list, and the rough=C2=A0 consensus of the w= orking
>> group was to leave "none" in the document.&quo= t;
>>
>> Discussion threads on this topic include:
>= ;> [jose] #36: Algorithm "none" should be removed=C2=A0<= /span>http://www.ie= tf.org/mail-
>> archive/web/jose/current/msg02911.html - Began= Jul 31, 2013=C2=A0 (91 messages)
>> [jose] Text about application= s and "alg":"none"=C2=A0http://www.ietf.org/mail-
>= > archive/web/jose/current/msg03321.html - Began Sep 3, 2013 (5 messages= )
>>
>> This issue was a topic of a special working group= call on Aug 19, 2013.=C2=A0 The text
>> discussed in the last thr= ead and published at=C2=A0https://tools.ietf.org/html/draft-
>= > ietf-jose-json-web-algorithms-33#section-8.5 (Unsecured JWS Security>> Considerations) was the result of the working group's decisi= ons resulting from all
>> of this discussion.

T= hanks for all the pointers above. I read through all the (many!)
Aug 19 = mails and most of the `"none" should be removed" thread.
=
So I do see that there was rough consensus to keep "none" in<= br>the draft and can (with difficulty;-) hold my nose and let that
pass.= I do not however, see that there was consensus to make
"none"= MTI for this draft. I did see a bit of haggling about
this draft vs. JW= S but still do not see why none ought be MTI
here.

>>=
>>>>> (3) Section 12: another way to handle privacy is t= o not include
>>>>> sensitive data - I think you ought me= ntion that as a bit of thought
>>>>> along those lines ca= n be much simpler than putting in place the key
>>>>> man= agement to handle thoughtlessly included PII.
>>>>
>&g= t;>> We can include a discussion of that point,
>>>
&g= t;>> Great. "Just say no" is workable here:-) I'll clea= r when we get such text.
>>>
>>>> but sometimes = the very
>>>> point of a JWT is to securely deliver PII from= a verifiable party to
>>>> an intended party with appropria= te rights to receive it.
>>>
>>> Hmm. Its a moot po= int (so let's not argue it) but I wonder how often
>>> PII = is really needed for authorization with oauth. My guess would be
>>= ;> that its needed far less often than its found to be profitable
>= ;>> perhaps, or that carelessness plays a big role in using PII for s= uch purposes.

I've cleared on this as you added this text= :

=C2=A0=C2=A0"Of course, including
=C2=A0 =C2= =A0only necessary privacy-sensitive information in a JWT is the most
=C2= =A0 =C2=A0basic means of minimizing any potential privacy issues."
=
That seems to me like a fairly offputting way to phrase it. I'd
= suggest instead:

=C2=A0=C2=A0"Omitting privacy-sen= sitive information from a JWT is the
=C2=A0=C2=A0simplest w= ay of minimizing privacy issues."

= I like this wording suggestion, thanks.
=C2=A0

Cheers,
S.

PS: I didn't check the comments.
<= div>
>>>
>>> S.
>>>
>>>
= >>>
>>>>
>>>>> ------------------= -------------------------------------------------
>>>>> -= -
>>>>> -
>>>>>
>>>>>=
>>> COMMENT:
>>>>> -------------------------= ------------------------------------------
>>>>> --
&g= t;>>>> -
>>>>>
>>>>>
>= ;>>>>
>>>>>
>>> - abstract: 2nd s= entence isn't needed here, in intro would be fine.
>>>><= br>>>>> I don't know - I think it's a big deal that the= claims can be
>>>> digitally signed or MACed and/or encrypt= ed.=C2=A0 That's the reason we
>>>> have JWTs, rather th= an just JSON.
>>>>
>>>>> - 4.1.7: maybe wo= rth adding that jti+iss being unique enough is not
>>>>> = sufficient and jti alone has to meet that need. In X.509 the
>>>= ;>> issuer/serial has the equivalent property so someone might assume=
>>>>> sequential jti values starting at 0 are ok.
>= ;>>>
>>>> Makes sense to add a warning of some kind= along these lines.=C2=A0 I
>>>> think I know the reasons yo= u say that, but can you expand on that
>>>> thought a bit be= fore I take a stab on writing this up?=C2=A0 For
>>>> instan= ce, while normally true, I don't think your observation is
>>&= gt;> true if a relying party will only accept tokens from a single issue= r.
>>>>
>>>>> - section 6: yuk
>>= >>>
>>>>> - again I think the secdir comments ar= e being handled by Kathleen
>>>>> and the authors.
>= ;>>>
>>>> Again, this is there because multiple app= lications asked for the
>>>> ability to represent content th= at is optionally signed, sometimes
>>>> securing it another = way, such as with TLS.=C2=A0 JWTs are used specific
>>>> app= lication protocol contexts - not in isolation.
>>>>
>&= gt;>> Thanks again, -- Mike
>>>>
>> _________= ______________________________________
>> OAuth mailing list
&g= t;>=C2=A0OAuth@ietf.org
>>=C2=A0https://www.ietf.org/mail= man/listinfo/oauth
>




--=C2=A0
=

Best regards,
Kathleen


____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth




--
Nat Saki= mura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
--089e013c674efcdcb40506134212-- From nobody Thu Oct 23 02:00:50 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 241501A8925; Thu, 23 Oct 2014 02:00:15 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eA0pyiX5L1hT; Thu, 23 Oct 2014 02:00:08 -0700 (PDT) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4EF71A1A2C; Thu, 23 Oct 2014 02:00:07 -0700 (PDT) Received: by mail-qg0-f44.google.com with SMTP id j5so379653qga.3 for ; Thu, 23 Oct 2014 02:00:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:mime-version:message-id:in-reply-to:references:from:to:cc :subject:content-type; bh=27fS3nljjs4DA+KP12XU1irAbyS+5NdLwF8PpKbmx14=; b=mGmT0vSS4h6xD3fMCFxuf73422KWH4q1FJ+GFowVuH15VNckelAkFQRZ0WPwVDXrTC wUi66EI2jVTC4HumKg7vRSlXyvNs+zLpansyFDRmDhOUZwzqQXLODm0FtRJnvw7qddyD gdREbq19HeEXEFveVdT9nIbcsrmTdGQf/c8uOi6RyT+X6eJ13q9pEB1vGdjk77vf+y1z v4F9/qDC5YSP0RzSTDrc5ZZ5NcuAW4yvXUYDpNLDbGrABEingyKma1OcIxIxMVIErKIX qp8SLF8r2lPCUyVjfAEkIxkkR0vrYYyci75lvLl60Fgrw4k/yWRue13HvHcwMR84G9d3 rtZQ== X-Received: by 10.140.108.35 with SMTP id i32mr5225217qgf.66.1414054806936; Thu, 23 Oct 2014 02:00:06 -0700 (PDT) Received: from hedwig-43.prd.orcali.com (ec2-54-85-253-42.compute-1.amazonaws.com. [54.85.253.42]) by mx.google.com with ESMTPSA id 18sm1128004qgl.5.2014.10.23.02.00.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 23 Oct 2014 02:00:06 -0700 (PDT) Date: Thu, 23 Oct 2014 02:00:06 -0700 (PDT) X-Google-Original-Date: Thu, 23 Oct 2014 09:00:05 GMT MIME-Version: 1.0 X-Mailer: Nodemailer (0.5.0; +http://www.nodemailer.com/) Message-Id: <1414054805258.aee19a78@Nodemailer> In-Reply-To: References: X-Orchestra-Oid: 36B6C36A-DCB2-434F-A1D7-C688D96C572F X-Orchestra-Sig: b26f19df21149b56135c8bae802899ee8bed2f0d X-Orchestra-Thrid: T0A917EF9-F85E-4DDD-A4FB-E09F985B43FD_1482743824403757289 X-Orchestra-Thrid-Sig: fdade0f10ed6b22e8b1bf03087205300420a9891 X-Orchestra-Account: 7b48121dd6eacc034c109a31b5b0e12b11e19791 From: "Matias Woloski" To: "Nat Sakimura" Content-Type: multipart/alternative; boundary="----Nodemailer-0.5.0-?=_1-1414054806002" Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/zhoC4BeyIlStW75p6YCq5eNvwJg Cc: oauth-chairs@tools.ietf.org, oauth@ietf.org, draft-ietf-oauth-json-web-token@tools.ietf.org, The IESG Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Oct 2014 09:00:15 -0000 X-List-Received-Date: Thu, 23 Oct 2014 09:00:15 -0000 ------Nodemailer-0.5.0-?=_1-1414054806002 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1 On Thu, Oct 23, 2014 at 10:58 AM, Nat Sakimura wrote: > I second John's message. There are many ways to achieve a desired level = of > security and one of the most popular way is to delegate it to the = transport > layer and use 'none' as the alg. If 'none' becomes non-MTI, then it may > cause a lot of interoperability issues down the road. > Adding to it, JWT can be useful in other context than security as well. = As > interoperability is one of the most important criteria, having 'none' as > MTI seems to be a reasonable idea to me. > Nat > 2014-10-22 16:44 GMT-05:00 John Bradley : >> From a JWT perspective a number of applications including connect allow >> unsecured JWT. >> >> I guess you are referring to sec 8 of JWT in the OAuth WG. Some of the >> threads you mention were in the JOSE WG relating to the JWS spec and if >> none should be included. >> >> To some extent the issues are not quite the same for the different specs= . >> >> SAML certainly allows for unsigned documents, those are used in a lot = of >> places. I imagine that a SAML library that could not process unsigned >> messages would generally be considered broken. >> That is not to say that it also needs to also support signed ones and = some >> number of trust models. >> >> It is the same for JWT as it lives at a similar conceptual level to = SAML >> assertions. >> >> It is better for interoperability to have all the JWT libs implement >> =22none=22, so that it can be supported in the many cases it may be used= for >> processing JWT protected by transport or some other mechanism, and = reliably >> reject =22none=22 when signatures are required. >> >> The JWT spec is not requiring JWS or JWE to implement support for none, >> though likely life would be easier if they did support it. >> >> John B. >> >> >> >> On Oct 21, 2014, at 1:36 PM, Kathleen Moriarty < >> kathleen.moriarty.ietf@gmail.com> wrote: >> >> >> >> On Tue, Oct 21, 2014 at 9:16 AM, Stephen Farrell < >> stephen.farrell@cs.tcd.ie> wrote: >> >>> >>> Hi Mike, >>> >>> I've one remaining discuss point and a comment. See below... >>> >>> On 14/10/14 13:50, Mike Jones wrote: >>> > The proposed resolutions below have been included in the -28 draft. >>> Hopefully you'll be able to clear your DISCUSSes on that basis. >>> > >>> > The String Comparison Rules in Section 7.3 have been expanded to = talk >>> about when the application may need canonicalization rules. >>> > >>> > Thanks again, >>> > -- Mike >>> > >>> >> -----Original Message----- >>> >> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones >>> >> Sent: Monday, October 06, 2014 7:20 PM >>> >> To: Stephen Farrell; The IESG >>> >> Cc: oauth-chairs@tools.ietf.org; draft-ietf-oauth-json-web- >>> >> token@tools.ietf.org; oauth@ietf.org >>> >> Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on >>> draft-ietf-oauth-json- >>> >> web-token-27: (with DISCUSS and COMMENT) >>> >> >>> >> Thanks for tracking all of this Stephen. Responses inline below... >>> >> >>> >>> -----Original Message----- >>> >>> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] >>> >>> Sent: Monday, October 06, 2014 2:43 PM >>> >>> To: Mike Jones; The IESG >>> >>> Cc: oauth-chairs@tools.ietf.org; draft-ietf-oauth-json-web- >>> >>> token@tools.ietf.org; oauth@ietf.org >>> >>> Subject: Re: Stephen Farrell's Discuss on >>> draft-ietf-oauth-json-web-token-27: >>> >>> (with DISCUSS and COMMENT) >>> >>> >>> >>> >>> >>> Hi Mike, >>> >>> >>> >>> On 06/10/14 08:54, Mike Jones wrote: >>> >>>> Thanks for your review, Stephen. I've added the working group to >>> >>>> the thread so they're aware of your comments. >>> >>>> >>> >>>>> -----Original Message----- From: Stephen Farrell >>> >>>>> [mailto:stephen.farrell@cs.tcd.ie] Sent: Thursday, October 02, = 2014 >>> >>>>> 5:03 AM To: The IESG Cc: oauth-chairs@tools.ietf.org; >>> >>>>> draft-ietf-oauth-json-web- token@tools.ietf.org Subject: Stephen >>> >>>>> Farrell's Discuss on draft-ietf-oauth-json-web-token-27: (with >>> >>>>> DISCUSS and COMMENT) >>> >>>>> >>> >>>>> Stephen Farrell has entered the following ballot position for >>> >>>>> draft-ietf-oauth-json-web-token-27: Discuss >>> >>>>> >>> >>>>> When responding, please keep the subject line intact and reply = to >>> >>>>> all email addresses included in the To and CC lines. (Feel free = to >>> >>>>> cut this introductory paragraph, however.) >>> >>>>> >>> >>>>> >>> >>>>> Please refer to >>> >>>>> http://www.ietf.org/iesg/statement/discuss-criteria.html for = more >>> >>>>> information about IESG DISCUSS and COMMENT positions. >>> >>>>> >>> >>>>> >>> >>>>> The document, along with other ballot positions, can be found >>> >>>>> here: >>> >>>>> http://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/ >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> -----------------------------------------------------------------= -- >>> >>>>> -- >>> >>>>> - >>> >>>>> >>> >>>>> >>> >>> DISCUSS: >>> >>>>> -----------------------------------------------------------------= -- >>> >>>>> -- >>> >>>>> - >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>> (1) 4.1.1 and elsewhere you say case-sensitive: the same thing I >>> >>> raised wrt DNS >>> >>>>> names for another JOSE spec - do you need to say those SHOULD be >>> >>>>> [upper|lower]cased when used in these=3F >>> >>>> >>> >>>> I believe that somewhere we should say that if case-insensitive >>> >>>> values, such as DNS names, are used when constructing =22kid=22 = values, >>> >>>> that the application doing so needs to define a convention on the >>> >>>> canonical case to use for the case-insensitive portions, such as >>> >>>> lowercasing them. >>> >>> >>> >>> As that discussion's happening on the key draft, I'll clear it = here >>> >>> and trust you to fix if a change is the end result. >>> >> >>> >> Thanks >>> >>> np >>> >>> >> >>> >>>>> (2) Section 8: Why is =22none=22 MTI=3F That seems both broken = and going >>> >>>>> in the oppostite direction from other WGs and so should be >>> >>>>> explicitly jusified I think. (If a good enough justification = exists >>> >>>>> that is.) >>> >>>> >>> >>>> It is MTI because there are several existing applications of JWTs = in >>> >>>> which both unsigned and signed representations of the JWTs are >>> >>>> requirements. These include draft-ietf-oauth-token-exchange, >>> >>>> draft-hunt-oauth-v2-user-a4c, and OpenID Connect. This is a = pretty >>> >>>> common pattern where you sign something if the recipient cares = who >>> >>>> made the statements and where you don't have to sign it either if >>> >>>> the recipient doesn't care who made the statements >>> >>> >>> >>> I don't see how (non-)signers can divine non-verifier's wishes = that >>> >>> way. (Absent negotiation or a directory.) >>> >> >>> >> Sometimes it does occur via negotiation. For instance, in some >>> protocols, at >>> >> registration time, relying parties explicitly tell identity = providers >>> what algorithms >>> >> are acceptable to them, which may include =22none=22. No divination= - >>> explicit >>> >> communication. >>> >> >>> >>>> or if it can tell from >>> >>>> another secured aspect of the application protocol (typically >>> >>>> through the use of TLS) who made the statements. In the TLS case,= >>> >>>> the server authentication step makes a signature step unnecessary,= >>> >>>> so an Unsecured JWT is fine there. >>> >>> >>> >>> That's arguable IMO. >>> >> >>> >> I agree that it's application and context-dependent whether it's OK = or >>> not. The >>> >> point is that there exist some circumstances in which it is OK, and >>> this feature is >>> >> being used in some of those cases. >>> >> >>> >>> I think I'll look back over the wg thread and either hold my nose = or >>> >> >>> >> This issue was tracked as >>> http://trac.tools.ietf.org/wg/jose/trac/ticket/36. >>> >> Karen O'Donoghue recorded this conclusion in the tracker =22Note: = There >>> was >>> >> extensive discussion on the mailing list, and the rough consensus = of >>> the working >>> >> group was to leave =22none=22 in the document.=22 >>> >> >>> >> Discussion threads on this topic include: >>> >> [jose] #36: Algorithm =22none=22 should be removed >>> http://www.ietf.org/mail- >>> >> archive/web/jose/current/msg02911.html - Began Jul 31, 2013 (91 >>> messages) >>> >> [jose] Text about applications and =22alg=22:=22none=22 >>> http://www.ietf.org/mail- >>> >> archive/web/jose/current/msg03321.html - Began Sep 3, 2013 (5 = messages) >>> >> >>> >> This issue was a topic of a special working group call on Aug 19, >>> 2013. The text >>> >> discussed in the last thread and published at >>> https://tools.ietf.org/html/draft- >>> >> ietf-jose-json-web-algorithms-33#section-8.5 (Unsecured JWS = Security >>> >> Considerations) was the result of the working group's decisions >>> resulting from all >>> >> of this discussion. >>> >>> Thanks for all the pointers above. I read through all the (many!) >>> Aug 19 mails and most of the `=22none=22 should be removed=22 thread. >>> >>> So I do see that there was rough consensus to keep =22none=22 in >>> the draft and can (with difficulty;-) hold my nose and let that >>> pass. I do not however, see that there was consensus to make >>> =22none=22 MTI for this draft. I did see a bit of haggling about >>> this draft vs. JWS but still do not see why none ought be MTI >>> here. >>> >>> >> >>> >>>>> (3) Section 12: another way to handle privacy is to not include >>> >>>>> sensitive data - I think you ought mention that as a bit of = thought >>> >>>>> along those lines can be much simpler than putting in place the = key >>> >>>>> management to handle thoughtlessly included PII. >>> >>>> >>> >>>> We can include a discussion of that point, >>> >>> >>> >>> Great. =22Just say no=22 is workable here:-) I'll clear when we get= such >>> text. >>> >>> >>> >>>> but sometimes the very >>> >>>> point of a JWT is to securely deliver PII from a verifiable party = to >>> >>>> an intended party with appropriate rights to receive it. >>> >>> >>> >>> Hmm. Its a moot point (so let's not argue it) but I wonder how = often >>> >>> PII is really needed for authorization with oauth. My guess would = be >>> >>> that its needed far less often than its found to be profitable >>> >>> perhaps, or that carelessness plays a big role in using PII for = such >>> purposes. >>> >>> I've cleared on this as you added this text: >>> >>> =22Of course, including >>> only necessary privacy-sensitive information in a JWT is the most >>> basic means of minimizing any potential privacy issues.=22 >>> >>> That seems to me like a fairly offputting way to phrase it. I'd >>> suggest instead: >>> >>> =22Omitting privacy-sensitive information from a JWT is the >>> simplest way of minimizing privacy issues.=22 >>> >> >> I like this wording suggestion, thanks. >> >> >>> >>> Cheers, >>> S. >>> >>> PS: I didn't check the comments. >>> >>> >>> >>> >>> S. >>> >>> >>> >>> >>> >>> >>> >>>> >>> >>>>> -----------------------------------------------------------------= -- >>> >>>>> -- >>> >>>>> - >>> >>>>> >>> >>>>> >>> >>> COMMENT: >>> >>>>> -----------------------------------------------------------------= -- >>> >>>>> -- >>> >>>>> - >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>> - abstract: 2nd sentence isn't needed here, in intro would be fine.= >>> >>>> >>> >>>> I don't know - I think it's a big deal that the claims can be >>> >>>> digitally signed or MACed and/or encrypted. That's the reason we >>> >>>> have JWTs, rather than just JSON. >>> >>>> >>> >>>>> - 4.1.7: maybe worth adding that jti+iss being unique enough is = not >>> >>>>> sufficient and jti alone has to meet that need. In X.509 the >>> >>>>> issuer/serial has the equivalent property so someone might = assume >>> >>>>> sequential jti values starting at 0 are ok. >>> >>>> >>> >>>> Makes sense to add a warning of some kind along these lines. I >>> >>>> think I know the reasons you say that, but can you expand on that >>> >>>> thought a bit before I take a stab on writing this up=3F For >>> >>>> instance, while normally true, I don't think your observation is >>> >>>> true if a relying party will only accept tokens from a single = issuer. >>> >>>> >>> >>>>> - section 6: yuk >>> >>>>> >>> >>>>> - again I think the secdir comments are being handled by = Kathleen >>> >>>>> and the authors. >>> >>>> >>> >>>> Again, this is there because multiple applications asked for the >>> >>>> ability to represent content that is optionally signed, sometimes >>> >>>> securing it another way, such as with TLS. JWTs are used = specific >>> >>>> application protocol contexts - not in isolation. >>> >>>> >>> >>>> Thanks again, -- Mike >>> >>>> >>> >> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= >>> >> OAuth mailing list >>> >> OAuth@ietf.org >>> >> https://www.ietf.org/mailman/listinfo/oauth >>> > >>> >>> >> >> >> -- >> >> Best regards, >> Kathleen >> >> >> >> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @=5Fnat=5Fen ------Nodemailer-0.5.0-?=_1-1414054806002 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1



On Thu, Oct 23, 2014 at 10:58 = AM, Nat Sakimura <sakimura@gmail.com> = wrote:

I second John's message. There are many ways to = achieve a desired level of security and one of the most popular way is to = delegate it to the transport layer and use 'none' as the alg. If 'none' = becomes non-MTI, then it may cause a lot of interoperability issues down = the road.=C2=A0

Adding to it, JWT can be useful in other context than security as well= . As interoperability is one of the most important criteria, having 'none' = as MTI seems to be a reasonable idea to me.=C2=A0

Nat

2014-10-22 16:44 GMT-05:00 John = Bradley <ve7jtb@ve7jtb.com>:
From a JWT perspective a number of = applications including connect allow unsecured JWT.

I guess you are referring to sec 8 of JWT in the OAuth WG.=C2=A0 Some = of the threads you mention were in the JOSE WG relating to the JWS spec and= if none should be included.

To some extent the issues are not quite the same for the different = specs.

SAML certainly allows for unsigned documents, those are used in a lot = of places.=C2=A0 I imagine that a SAML library that could not process = unsigned messages would generally be considered broken.
That is not to say that it also needs to also support signed ones and = some number of trust models. =C2=A0

It is the same for JWT as it lives at a similar conceptual level to = SAML assertions.=C2=A0

It is better for interoperability to have all the JWT libs implement = =22none=22, so that it can be supported in the many cases it may be used = for processing JWT protected by transport or some other mechanism, and = reliably reject =22none=22 when signatures are required.

The JWT spec is not requiring JWS or JWE to implement support for none= , =C2=A0though likely life would be easier if they did support it.

John B.



On Oct 21, 2014, at 1:36 PM, Kathleen Moriarty <kathleen.moriarty.= ietf@gmail.com> wrote:



On Tue, Oct 21, 2014 at 9:16 AM, Stephen = Farrell=C2=A0<stephen.farrell@cs.tcd.= ie>=C2=A0wrote:

Hi Mike,

I've one remaining discuss point and a comment. See = below...

On 14/10/14 13:50, Mike Jones wrote:
> The proposed resolutions = below have been included in the -28 draft.=C2=A0 Hopefully you'll be able = to clear your DISCUSSes on that basis.
>
> The String = Comparison Rules in Section 7.3 have been expanded to talk about when the = application may need canonicalization rules.
>
>=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Thanks again,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0= =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 [mailto:oauth-bounces@ietf.org] On Behalf Of Mike = Jones
>> Sent: Monday, October 06, 2014 7:20 PM
>> To: = Stephen Farrell; The IESG
>> Cc:=C2=A0oauth-chairs@tools.ietf.= org; draft-ietf-oauth-json-web-
>>=C2=A0token@tools.ietf.= org;=C2=A0oauth@ietf= .org
>> Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on = draft-ietf-oauth-json-
>> web-token-27: (with DISCUSS and = COMMENT)
>>
>> Thanks for tracking all of this Stephen.= =C2=A0 Responses inline below...
>>
>>> -----Original = Message-----
>>> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.= ie]
>>> Sent: Monday, October 06, 2014 2:43 = PM
>>> To: Mike Jones; The IESG
>>> = Cc:=C2=A0oauth-chairs@tools.ietf.org; draft-ietf-oauth-json-web-
>&= gt;>=C2=A0token@tools.ietf.org;=C2=A0oauth@ietf.org
>>> = Subject: Re: Stephen Farrell's Discuss on draft-ietf-oauth-json-web-token-2= 7:
>>> (with DISCUSS and COMMENT)
>>>
>>&g= t;
>>> Hi Mike,
>>>
>>> On 06/10/14 = 08:54, Mike Jones wrote:
>>>> Thanks for your review, = Stephen.=C2=A0 I've added the working group to
>>>> the = thread so they're aware of your comments.
>>>>
>>&g= t;>> -----Original Message----- From: Stephen = Farrell
>>>>> [mailto:stephen.farrell@cs.tcd.ie] Sent: Thursday, October= 02, 2014
>>>>> 5:03 AM To: The IESG = Cc:=C2=A0oauth-chairs@tools.ietf.org;
>>>>> = draft-ietf-oauth-json-web-=C2=A0token@tools.ietf.org=C2=A0Subject: = Stephen
>>>>> Farrell's Discuss on = draft-ietf-oauth-json-web-token-27: (with
>>>>> DISCUSS = and COMMENT)
>>>>>
>>>>> Stephen = Farrell has entered the following ballot position for
>>>>&g= t; draft-ietf-oauth-json-web-token-27: Discuss
>>>>>
&= gt;>>>> When responding, please keep the subject line intact = and reply to
>>>>> all email addresses included in the To= and CC lines. (Feel free to
>>>>> cut this introductory = paragraph, however.)
>>>>>
>>>>>
>= ;>>>> Please refer to
>>>>>=C2=A0http://www.ietf.org/iesg/statement/discuss-criteria.= html=C2=A0for more
>>>>> information = about IESG DISCUSS and COMMENT positions.
>>>>>
>&g= t;>>>
>>>>> The document, along with other = ballot positions, can be found
>>>>> = here:
>>>>>=C2=A0http://datatracker.= ietf.org/doc/draft-ietf-oauth-json-web-token/
>>>>>>>>>>
>>>>>
>>>>> = -------------------------------------------------------------------
>= >>>> --
>>>>> -
>>>>>
&g= t;>>>>
>>> DISCUSS:
>>>>> = -------------------------------------------------------------------
>= >>>> --
>>>>> -
>>>>>
&g= t;>>>>
>>>>>
>>>>>
>&= gt;> (1) 4.1.1 and elsewhere you say case-sensitive: the same thing = I
>>> raised wrt DNS
>>>>> names for another = JOSE spec - do you need to say those SHOULD be
>>>>> = [upper|lower]cased when used in these=3F
>>>>
>>>= ;> I believe that somewhere we should say that if = case-insensitive
>>>> values, such as DNS names, are used = when constructing =22kid=22 values,
>>>> that the = application doing so needs to define a convention on = the
>>>> canonical case to use for the case-insensitive = portions, such as
>>>> lowercasing them.=
>>>
>>> As that discussion's happening on the key = draft, I'll clear it here
>>> and trust you to fix if a change = is the end result.
>>
>> Thanks

np
=

>>
>>>>> (2) Section 8: Why is =22none=22 = MTI=3F That seems both broken and going
>>>>> in the = oppostite direction from other WGs and so should be
>>>>>= explicitly jusified I think. (If a good enough justification = exists
>>>>> that is.)
>>>>
>>>= ;> It is MTI because there are several existing applications of JWTs = in
>>>> which both unsigned and signed representations of = the JWTs are
>>>> requirements.=C2=A0 These include = draft-ietf-oauth-token-exchange,
>>>> = draft-hunt-oauth-v2-user-a4c, and OpenID Connect.=C2=A0 This is a = pretty
>>>> common pattern where you sign something if the = recipient cares who
>>>> made the statements and where you = don't have to sign it either if
>>>> the recipient doesn't = care who made the statements
>>>
>>> I don't see = how (non-)signers can divine non-verifier's wishes that
>>> way= . (Absent negotiation or a directory.)
>>
>> Sometimes it= does occur via negotiation.=C2=A0 For instance, in some protocols, = at
>> registration time, relying parties explicitly tell identity = providers what algorithms
>> are acceptable to them, which may = include =22none=22.=C2=A0 No divination - explicit
>> = communication.
>>
>>>> or if it can tell = from
>>>> another secured aspect of the application protocol= (typically
>>>> through the use of TLS) who made the = statements.=C2=A0 In the TLS case,
>>>> the server = authentication step makes a signature step unnecessary,
>>>>= so an Unsecured JWT is fine there.
>>>
>>> That's = arguable IMO.
>>
>> I agree that it's application and = context-dependent whether it's OK or not.=C2=A0 The
>> point is = that there exist some circumstances in which it is OK, and this feature = is
>> being used in some of those cases.
>>
>>&g= t; I think I'll look back over the wg thread and either hold my nose = or
>>
>> This issue was tracked as=C2=A0http://trac.= tools.ietf.org/wg/jose/trac/ticket/36.
>> Karen O'Donoghue = recorded this conclusion in the tracker =22Note: There was
>> = extensive discussion on the mailing list, and the rough=C2=A0 consensus of = the working
>> group was to leave =22none=22 in the document.= =22
>>
>> Discussion threads on this topic = include:
>> [jose] #36: Algorithm =22none=22 should be = removed=C2=A0http://www.ietf.org/mail-
>> = archive/web/jose/current/msg02911.html - Began Jul 31, 2013=C2=A0 (91 = messages)
>> [jose] Text about applications and = =22alg=22:=22none=22=C2=A0http://www.ietf.org/mail-
>> = archive/web/jose/current/msg03321.html - Began Sep 3, 2013 (5 = messages)
>>
>> This issue was a topic of a special = working group call on Aug 19, 2013.=C2=A0 The text
>> discussed in= the last thread and published at=C2=A0https://tools.ietf.= org/html/draft-
>> ietf-jose-json-web-algorithms-33#section-8.= 5 (Unsecured JWS Security
>> Considerations) was the result of the= working group's decisions resulting from all
>> of this = discussion.

Thanks for all the pointers above. I read = through all the (many!)
Aug 19 mails and most of the `=22none=22 should = be removed=22 thread.

So I do see that there was rough consensus to = keep =22none=22 in
the draft and can (with difficulty;-) hold my nose = and let that
pass. I do not however, see that there was consensus to = make
=22none=22 MTI for this draft. I did see a bit of haggling = about
this draft vs. JWS but still do not see why none ought be = MTI
here.

>>
>>>>> (3) Section 12: = another way to handle privacy is to not include
>>>>> = sensitive data - I think you ought mention that as a bit of = thought
>>>>> along those lines can be much simpler than = putting in place the key
>>>>> management to handle = thoughtlessly included PII.
>>>>
>>>> We can = include a discussion of that point,
>>>
>>> Great. = =22Just say no=22 is workable here:-) I'll clear when we get such text.=
>>>
>>>> but sometimes the = very
>>>> point of a JWT is to securely deliver PII from a = verifiable party to
>>>> an intended party with appropriate = rights to receive it.
>>>
>>> Hmm. Its a moot point= (so let's not argue it) but I wonder how often
>>> PII is = really needed for authorization with oauth. My guess would = be
>>> that its needed far less often than its found to be = profitable
>>> perhaps, or that carelessness plays a big role = in using PII for such purposes.

I've cleared on this as you = added this text:

=C2=A0=C2=A0=22Of course, = including
=C2=A0 =C2=A0only necessary privacy-sensitive information in a= JWT is the most
=C2=A0 =C2=A0basic means of minimizing any potential = privacy issues.=22

That seems to me like a fairly offputting way to = phrase it. I'd
suggest instead:

=C2=A0=C2=A0=22Omitt= ing privacy-sensitive information from a JWT is the
=C2=A0=C2=A0simplest way of minimizing privacy issues.=22

I like this wording suggestion, thanks.
=C2=A0

Cheers,
S.

PS: I didn't check the comments.

>>>
>>> S.
>>>
>>>
>= >>
>>>>
>>>>> = -------------------------------------------------------------------
>= >>>> --
>>>>> -
>>>>>
&g= t;>>>>
>>> COMMENT:
>>>>> = -------------------------------------------------------------------
>= >>>> --
>>>>> -
>>>>>
&g= t;>>>>
>>>>>
>>>>>
>&= gt;> - abstract: 2nd sentence isn't needed here, in intro would be fine.=
>>>>
>>>> I don't know - I think it's a big = deal that the claims can be
>>>> digitally signed or MACed = and/or encrypted.=C2=A0 That's the reason we
>>>> have JWTs,= rather than just JSON.
>>>>
>>>>> - 4.1.= 7: maybe worth adding that jti+iss being unique enough is = not
>>>>> sufficient and jti alone has to meet that need.= In X.509 the
>>>>> issuer/serial has the equivalent = property so someone might assume
>>>>> sequential jti = values starting at 0 are ok.
>>>>
>>>> Makes = sense to add a warning of some kind along these lines.=C2=A0 = I
>>>> think I know the reasons you say that, but can you = expand on that
>>>> thought a bit before I take a stab on = writing this up=3F=C2=A0 For
>>>> instance, while normally = true, I don't think your observation is
>>>> true if a = relying party will only accept tokens from a single issuer.=
>>>>
>>>>> - section 6: = yuk
>>>>>
>>>>> - again I think the = secdir comments are being handled by Kathleen
>>>>> and = the authors.
>>>>
>>>> Again, this is there = because multiple applications asked for the
>>>> ability to = represent content that is optionally signed, sometimes
>>>> = securing it another way, such as with TLS.=C2=A0 JWTs are used = specific
>>>> application protocol contexts - not in = isolation.
>>>>
>>>> Thanks again, -- = Mike
>>>>
>> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
>> OAuth mailing = list
>>=C2=A0OAuth@ietf.org
>>=C2=A0https://www.ietf.= org/mailman/listinfo/oauth
>




--=C2=A0

Best regards,
Kathleen


=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F OAuth mailing list
OAuth@ietf.= org
http= s://www.ietf.org/mailman/listinfo/oauth




--
Nat Sakimura = (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@=5Fnat=5Fen

------Nodemailer-0.5.0-?=_1-1414054806002-- From nobody Fri Oct 24 02:11:11 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D981C1AD8F1 for ; Fri, 24 Oct 2014 02:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PRPGn09HgHTD for ; Fri, 24 Oct 2014 02:11:08 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FC6B1AD8DC for ; Fri, 24 Oct 2014 02:11:08 -0700 (PDT) Received: by mail-lb0-f169.google.com with SMTP id 10so2194022lbg.14 for ; Fri, 24 Oct 2014 02:11:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=NWkuCn7P2LZj5ylcdUrr5fuo4FdpKORgceZ9h1OL2jA=; b=T5/S7zewOzqHEVqGHIenKhNsAqhmeXd2OWvjfpVEVi0To9p18QN2+99gje3ZM5iB7F 2sA/hkWUHcfYI61BHrpEb9mrKsCDU/5uv7+Wf9WrIRSwF5w8hOfCBr/VvmgjoJ/GWXcr 4fOO9tK1aAsg1RY3yI2asfNnIa4n/f4td7zooUJaF3gnrDwwnpcGMVIbWKnQDy/yH1hu 5clf8zTFjWIa87HLVHZm+CjM4Oab8RoXfSlEc9A+kYCtUzHKbkPB69LSjj4gzjPmRauh u72diZ+GeQGTcZPlXSiQYT5F9a0EGyw61WsEngy11ZASsdbx9vAOY1KyPZMrmNk9NW7Z CxOA== MIME-Version: 1.0 X-Received: by 10.152.206.11 with SMTP id lk11mr3141640lac.42.1414141866546; Fri, 24 Oct 2014 02:11:06 -0700 (PDT) Received: by 10.112.181.36 with HTTP; Fri, 24 Oct 2014 02:11:06 -0700 (PDT) Date: Fri, 24 Oct 2014 18:11:06 +0900 Message-ID: From: Takahiko Kawasaki To: "oauth@ietf.org" Content-Type: multipart/alternative; boundary=001a113493929e1a870506278f02 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Xx-eyhOZolS3oCwbhkfdVF2XtJ8 Subject: [OAUTH-WG] Password in plaintext in emails from mailmain-owner@ietf.org X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 09:11:10 -0000 --001a113493929e1a870506278f02 Content-Type: text/plain; charset=UTF-8 Hello, As a result of subscribing to oauth@ietf.org, mailmain-owner@ietf.org periodically sends me emails titled "ietf.org mailing list memberships reminder" containing my password in PLAINTEXT. It's unbelievably insecure. Is this happening only to me? How to stop mailmain-owner@ietf.org from sending such emails? It's a terrible joke that this happens for OAUTH@ietf.org. They store our passwords in plaintext in their database, or at least in a way for them to decrypt our passwords. One-way hash should be used... Takahiko Kawasaki --001a113493929e1a870506278f02 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

As a result of subscribing to oauth@ietf.org, mailmain-owner@ietf.org periodically sends me emails titled &qu= ot;ietf.org mailing list memberships remind= er" containing my password in PLAINTEXT. It's unbelievably insecur= e.

Is this happening only to me? How to stop mailmain-owner@ietf.org from sending such emails? I= t's a terrible joke that this happens for OAUTH@ietf.org.

They store our passwords in plaintext in th= eir database, or at least in a way for them to decrypt our passwords. One-w= ay hash should be used...

Takahiko Kawasaki
--001a113493929e1a870506278f02-- From nobody Fri Oct 24 02:16:28 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88CCA1AD8DC for ; Fri, 24 Oct 2014 02:16:26 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fF8jef-RdE4e for ; Fri, 24 Oct 2014 02:16:24 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0077.outbound.protection.outlook.com [65.55.169.77]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 607341AD945 for ; Fri, 24 Oct 2014 02:16:23 -0700 (PDT) Received: from CO1PR02MB206.namprd02.prod.outlook.com (10.242.165.144) by CO1PR02MB208.namprd02.prod.outlook.com (10.242.165.150) with Microsoft SMTP Server (TLS) id 15.1.6.9; Fri, 24 Oct 2014 09:16:20 +0000 Received: from CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.251]) by CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.251]) with mapi id 15.01.0006.000; Fri, 24 Oct 2014 09:16:20 +0000 From: Antonio Sanso To: Takahiko Kawasaki Thread-Topic: [OAUTH-WG] Password in plaintext in emails from mailmain-owner@ietf.org Thread-Index: AQHP72p3D/PPp/Jaaki9NlfBowoIIZw++CUA Date: Fri, 24 Oct 2014 09:16:19 +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-transport-fromentityheader: Hosted x-originating-ip: [192.147.117.11] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR02MB208; x-forefront-prvs: 0374433C81 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(377454003)(189002)(24454002)(199003)(20776003)(101416001)(107046002)(99396003)(77096002)(120916001)(99286002)(106116001)(106356001)(110136001)(76482002)(19617315012)(97736003)(21056001)(33656002)(4396001)(50986999)(19580405001)(54356999)(76176999)(19580395003)(14971765001)(15975445006)(82746002)(86362001)(92726001)(92566001)(122556002)(46102003)(80022003)(40100003)(16236675004)(15395725005)(64706001)(15202345003)(87936001)(66066001)(95666004)(2656002)(83716003)(85852003)(36756003)(31966008)(85306004)(551544002)(104396001)(221513004)(222073002); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR02MB208; H:CO1PR02MB206.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_A8850865FD1C47C28C65A2D962D522ABadobecom_" MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Y_1aysiXkEyUZ-A8k9fhr8545Ps Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Password in plaintext in emails from mailmain-owner@ietf.org X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 09:16:26 -0000 --_000_A8850865FD1C47C28C65A2D962D522ABadobecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable hi, this is not Oauth@ietf only :) regards antonio On Oct 24, 2014, at 11:11 AM, Takahiko Kawasaki > wrote: Hello, As a result of subscribing to oauth@ietf.org, mailma= in-owner@ietf.org periodically sends me ema= ils titled "ietf.org mailing list memberships reminder" c= ontaining my password in PLAINTEXT. It's unbelievably insecure. Is this happening only to me? How to stop mailmain-owner@ietf.org from sending such emails? It's a terrible joke that = this happens for OAUTH@ietf.org. They store our passwords in plaintext in their database, or at least in a w= ay for them to decrypt our passwords. One-way hash should be used... Takahiko Kawasaki _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_A8850865FD1C47C28C65A2D962D522ABadobecom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable hi,

this is not Oauth@ietf only :)

regards

antonio
On Oct 24, 2014, at 11:11 AM, Takahiko Kawasaki <daru.tk@gmail.com> wrote:

Hello,

As a result of subscribing to oauth@ietf.= org, mailmain-owner@ietf.org peri= odically sends me emails titled "ietf.org= mailing list memberships reminder" containing my password in PLAI= NTEXT. It's unbelievably insecure.

Is this happening only to me? How to stop mailmain-owner@ietf.org from sending such emails? It's a terrible joke = that this happens for OAUTH@ietf.org.

They store our passwords in plaintext in their database, or at least in a w= ay for them to decrypt our passwords. One-way hash should be used...

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

--_000_A8850865FD1C47C28C65A2D962D522ABadobecom_-- From nobody Fri Oct 24 02:24:47 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 590B21A8923 for ; Fri, 24 Oct 2014 02:24: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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HmbYySFgbOui for ; Fri, 24 Oct 2014 02:24:42 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C4721A19E5 for ; Fri, 24 Oct 2014 02:24:41 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id gm9so2298624lab.27 for ; Fri, 24 Oct 2014 02:24:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Bnj9Gekxb1sSTycJtaY8PdQvj1J/XwwKm+I+2g76KIk=; b=vC8xid3jyAnrGa4GLz7Sq/1sc0OZjdpKxM+YsWmrXM1MpS6CViAiXbaoRAiM/xBTR4 bxz+n+Z3jRFSZ85uEswnJpxTGzpp7URes1KlLG5A2zFQRL7yTcvujHDl7E9uxzq5ZOVG i0qiCqZl2HEm1pEuUQEsQi59IpYzcO3fokQcejbZWPY3e4xaStAhqEuKrp+YoTw7sX/r Re8AN0+Hs3Fe/EKJsXBS9PE0GkjH3GUIPJF3wctEivEp557aUFWFPLxc+VmKbRCh73xs 411Ah0+niN4G5T03Wfnp7naCaJOdZBqcm/KNurmx4xKO3IXnHFAbsKr34lFVJbTfNOIr gBvQ== MIME-Version: 1.0 X-Received: by 10.112.44.229 with SMTP id h5mr1888115lbm.86.1414142679771; Fri, 24 Oct 2014 02:24:39 -0700 (PDT) Received: by 10.112.181.36 with HTTP; Fri, 24 Oct 2014 02:24:39 -0700 (PDT) In-Reply-To: References: Date: Fri, 24 Oct 2014 18:24:39 +0900 Message-ID: From: Takahiko Kawasaki To: Antonio Sanso Content-Type: multipart/alternative; boundary=001a11346d5016efe9050627c097 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/Pe_kUVYgWkV8YmtvbVhER6i1LH0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Password in plaintext in emails from mailmain-owner@ietf.org X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 09:24:44 -0000 --001a11346d5016efe9050627c097 Content-Type: text/plain; charset=UTF-8 Sorry. I found a configuration parameter labeled "Get password reminder email for this list?" at https://www.ietf.org/mailman/options/oauth/{my-email-address} Unbelievable option... This should not exist. Takahiko Kawasaki 2014-10-24 18:16 GMT+09:00 Antonio Sanso : > hi, > > this is not Oauth@ietf only :) > > regards > > antonio > On Oct 24, 2014, at 11:11 AM, Takahiko Kawasaki > wrote: > > Hello, > > As a result of subscribing to oauth@ietf.org, mailmain-owner@ietf.org > periodically sends me emails titled "ietf.org mailing list memberships > reminder" containing my password in PLAINTEXT. It's unbelievably insecure. > > Is this happening only to me? How to stop mailmain-owner@ietf.org from > sending such emails? It's a terrible joke that this happens for > OAUTH@ietf.org. > > They store our passwords in plaintext in their database, or at least in a > way for them to decrypt our passwords. One-way hash should be used... > > Takahiko Kawasaki > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --001a11346d5016efe9050627c097 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sorry. I found a configuration parameter labeled= "Get password reminder email for this list?" at

https://= www.ietf.org/mailman/options/oauth/{my-email-address}

Unbe= lievable option... This should not exist.

Takahiko Kawasaki



2014-10-24 18:16 GMT+09:00 Antonio Sanso <asanso@adobe.com>= :
hi,

this is not Oauth@ietf only :)

regards

antonio
On Oct 24, 2014, at 11:11 AM, Takahiko Kawasaki <daru.tk@gmail.com> wrote:

Hello,

As a result of subscribing to oauth@ietf.org, mailmain-owner= @ietf.org periodically sends me emails titled "ietf.org mailing list memberships reminder&= quot; containing my password in PLAINTEXT. It's unbelievably insecure.<= br>
Is this happening only to me? How to stop mailmain-owner@ietf.org from sending such emails? It's a terrible j= oke that this happens for OAUTH@ietf.org.

They store our passwords in plaintext in their database, or at least in a w= ay for them to decrypt our passwords. One-way hash should be used...

Takahiko Kawasaki
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth


--001a11346d5016efe9050627c097-- From nobody Fri Oct 24 05:01:16 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2E6F1A8A82 for ; Fri, 24 Oct 2014 05:01:14 -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, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fOA6DJ85liuw for ; Fri, 24 Oct 2014 05:01:12 -0700 (PDT) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C61FB1A8A6E for ; Fri, 24 Oct 2014 05:01:10 -0700 (PDT) Received: by mail-qg0-f49.google.com with SMTP id e89so826467qgf.8 for ; Fri, 24 Oct 2014 05:01:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=waBkqgCmu4Ri+6fc1FHVYMNrM2TY/NbHSvWpZ1AUZng=; b=v6SGzLXpcF3cWVeZqlljHQGF1YarU784g089fTJlufLOUc/Hpo00TzeGC0uFw2lpPt yg7csvwU2lc0qe4oSVxmUpSiaUh4zIxp/s16MDsVeedRRx1zXWsIO2/EcYkdgZRtETwP ZmYreJe1+DGhi9n02DzKhD/WJNgkF5gZ8O8+/Xc1b+3ALYkG8QMTAav60JZhjfg4JPVM O/a3PCONigrfS2fIEGyANpPhMoirV1z+fB7k57sX8MLWX/Ua6RCdfYf9jbY884smE6oo 4+S1cVDVQslYQG9ImZ4br0xJI2bu9oyzDnpvUWfyqddJc+wgoCrgDi8aFlN0DYWlXzZX D+xA== X-Received: by 10.170.162.86 with SMTP id e83mr2160805ykd.113.1414152068818; Fri, 24 Oct 2014 05:01:08 -0700 (PDT) Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by mx.google.com with ESMTPSA id d32sm3909332qge.20.2014.10.24.05.01.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 24 Oct 2014 05:01:07 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: multipart/alternative; boundary=Apple-Mail-40CB136F-E302-4947-ACE8-5314CBD59935 Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: Date: Fri, 24 Oct 2014 08:01:06 -0400 Content-Transfer-Encoding: 7bit Message-Id: <65AF50EF-289B-486E-A63B-143317D0F434@gmail.com> References: To: Takahiko Kawasaki Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/YWm1coTi0aeb2pA8ylkABhCDkqw Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Password in plaintext in emails from mailmain-owner@ietf.org X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 12:01:15 -0000 --Apple-Mail-40CB136F-E302-4947-ACE8-5314CBD59935 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi, This comes up every once in a while, but as long as you don't use the same p= assword for the mailing lists as other places, there really is no threat. If someone else posted as you, just complain and it gets addressed. =20 The only other risk I can think of would be someone removing you from the li= st and the archive is posted publicly. Best regards, Kathleen=20 Sent from my iPhone > On Oct 24, 2014, at 5:24 AM, Takahiko Kawasaki wrote: >=20 > Sorry. I found a configuration parameter labeled "Get password reminder em= ail for this list?" at >=20 > https://www.ietf.org/mailman/options/oauth/{my-email-address} >=20 > Unbelievable option... This should not exist. >=20 > Takahiko Kawasaki >=20 >=20 >=20 > 2014-10-24 18:16 GMT+09:00 Antonio Sanso : >> hi, >>=20 >> this is not Oauth@ietf only :) >>=20 >> regards >>=20 >> antonio >>> On Oct 24, 2014, at 11:11 AM, Takahiko Kawasaki wrot= e: >>>=20 >>> Hello, >>>=20 >>> As a result of subscribing to oauth@ietf.org, mailmain-owner@ietf.org pe= riodically sends me emails titled "ietf.org mailing list memberships reminde= r" containing my password in PLAINTEXT. It's unbelievably insecure. >>>=20 >>> Is this happening only to me? How to stop mailmain-owner@ietf.org from s= ending such emails? It's a terrible joke that this happens for OAUTH@ietf.or= g. >>>=20 >>> They store our passwords in plaintext in their database, or at least in a= way for them to decrypt our passwords. One-way hash should be used... >>>=20 >>> Takahiko Kawasaki >>> _______________________________________________ >>> 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-40CB136F-E302-4947-ACE8-5314CBD59935 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi,

This come= s up every once in a while, but as long as you don't use the same password f= or the mailing lists as other places, there really is no threat.
<= br>
If someone else posted as you, just complain and it gets addre= ssed.  

The only other risk I can think of wou= ld be someone removing you from the list and the archive is posted publicly.=

Best regards,
Kathleen 

Sent= from my iPhone

On Oct 24, 2014, at 5:24 AM, Takahiko Kawasaki= <daru.tk@gmail.com> wrote:
Sorry.= I found a configuration parameter labeled "Get password reminder email for t= his list?" at

https://www.ietf.org/mailman/options/oauth/{my-email-addr= ess}

Unbelievable option... This should not exist.

<= /div>Takahiko Kawasaki



2014-10-24 18:16 GMT+09:00 Antonio Sanso <as= anso@adobe.com>:
hi,

this is not Oauth@ietf only :)

regards

antonio
On Oct 24, 2014, at 11:11 AM, Takahiko Kawasaki <daru.tk@gmail.com> wrote:

Hello,

As a result of subscribing to oauth@ietf.org, mailmain-owner@= ietf.org periodically sends me emails titled "ietf.org mailing list memberships reminder" contain= ing my password in PLAINTEXT. It's unbelievably insecure.

Is this happening only to me? How to stop mailmain-owner@ietf.org from sending such emails? It's a terrible joke t= hat this happens for OAUTH@ietf.org.

They store our passwords in plaintext in their database, or at least in a wa= y for them to decrypt our passwords. One-way hash should be used...

Takahiko Kawasaki
_______________________________________________
OAuth mailing list
OAuth@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/oauth


____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-40CB136F-E302-4947-ACE8-5314CBD59935-- From nobody Fri Oct 24 23:03:41 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E25AB1A6F99; Fri, 24 Oct 2014 23:03: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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DMCSSW7LQfwy; Fri, 24 Oct 2014 23:03:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A7CF1A6FFC; Fri, 24 Oct 2014 23:03:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141025060330.3302.41195.idtracker@ietfa.amsl.com> Date: Fri, 24 Oct 2014 23:03:30 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/JFeWWKwnzLNyh5DtO5lOciFHdeM Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-json-web-token-30.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Oct 2014 06:03:33 -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 Working Group of the IETF. Title : JSON Web Token (JWT) Authors : Michael B. Jones John Bradley Nat Sakimura Filename : draft-ietf-oauth-json-web-token-30.txt Pages : 35 Date : 2014-10-24 Abstract: JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JavaScript Object Notation (JSON) object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or MACed and/or encrypted. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-30 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-json-web-token-30 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Oct 24 23:31:48 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DAE21A8032 for ; Fri, 24 Oct 2014 23:31: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pvk2Ilek9lTj for ; Fri, 24 Oct 2014 23:31:41 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0114.outbound.protection.outlook.com [65.55.169.114]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 980B31A8029 for ; Fri, 24 Oct 2014 23:31:40 -0700 (PDT) Received: from BN3PR0301CA0013.namprd03.prod.outlook.com (25.160.180.151) by BN3PR0301MB1203.namprd03.prod.outlook.com (25.161.207.156) with Microsoft SMTP Server (TLS) id 15.1.6.9; Sat, 25 Oct 2014 06:31:38 +0000 Received: from BN1AFFO11FD042.protection.gbl (2a01:111:f400:7c10::193) by BN3PR0301CA0013.outlook.office365.com (2a01:111:e400:4000::23) with Microsoft SMTP Server (TLS) id 15.1.6.9 via Frontend Transport; Sat, 25 Oct 2014 06:31:38 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD042.mail.protection.outlook.com (10.58.52.253) with Microsoft SMTP Server (TLS) id 15.0.1049.20 via Frontend Transport; Sat, 25 Oct 2014 06:31:37 +0000 Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.93]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.03.0210.003; Sat, 25 Oct 2014 06:30:58 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: JOSE -36 and JWT -30 drafts addressing additional IESG review comments Thread-Index: Ac/wHSy6mtwUCqErTVi1YRqv04aybgAAAWtw Date: Sat, 25 Oct 2014 06:30:57 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439BB2624E@TK5EX14MBXC286.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439BB2624ETK5EX14MBXC286r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(438002)(189002)(199003)(377454003)(71186001)(92566001)(85852003)(92726001)(4396001)(50986999)(54356999)(87936001)(2501002)(77096002)(55846006)(20776003)(66066001)(64706001)(2656002)(86362001)(85806002)(84326002)(86612001)(2351001)(6806004)(95666004)(19300405004)(512954002)(81156004)(106466001)(76482002)(84676001)(15975445006)(16297215004)(68736004)(69596002)(107886001)(44976005)(19580405001)(19580395003)(107046002)(15202345003)(21056001)(26826002)(85306004)(19625215002)(80022003)(46102003)(31966008)(16236675004)(97736003)(120916001)(33656002)(110136001)(19617315012)(104016003)(99396003)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1203; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1203; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0375972289 Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/VNm50BAXv0F1cmpFUMtbqS-o1Ys Subject: [OAUTH-WG] FW: JOSE -36 and JWT -30 drafts addressing additional IESG review comments X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Oct 2014 06:31:46 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439BB2624ETK5EX14MBXC286r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Mike Jones Sent: Friday, October 24, 2014 11:31 PM To: jose@ietf.org Subject: JOSE -36 and JWT -30 drafts addressing additional IESG review comm= ents These JOSE and JWT drafts incorporate resolutions to some previously unreso= lved IESG comments. The primary change was adding flattened JSON Serializa= tion syntax for the single digital signature/MAC and single recipient cases= . See http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-36#app= endix-A.7 and http://tools.ietf.org/html/draft-ietf-jose-json-web-encryptio= n-36#appendix-A.5 for examples. See the history entries for details on th= e few other changes. No breaking changes were made. The specifications are available at: * http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-36 * http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-36 * http://tools.ietf.org/html/draft-ietf-jose-json-web-key-36 * http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-36 * http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-30 HTML formatted versions are available at: * http://self-issued.info/docs/draft-ietf-jose-json-web-signature-36= .html * http://self-issued.info/docs/draft-ietf-jose-json-web-encryption-3= 6.html * http://self-issued.info/docs/draft-ietf-jose-json-web-key-36.html * http://self-issued.info/docs/draft-ietf-jose-json-web-algorithms-3= 6.html * http://self-issued.info/docs/draft-ietf-oauth-json-web-token-30.ht= ml -- Mike P.S. I've also posted this notice at http://self-issued.info/?p=3D1296 and= as @selfissued. --_000_4E1F6AAD24975D4BA5B16804296739439BB2624ETK5EX14MBXC286r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From: Mike Jon= es
Sent: Friday, October 24, 2014 11:31 PM
To: jose@ietf.org
Subject: JOSE -36 and JWT -30 drafts addressing additional IESG revi= ew comments

 

These JOSE and JWT drafts incorporate resolutions to= some previously unresolved IESG comments.  The primary change was add= ing flattened JSON Serialization syntax for the single digital signature/MA= C and single recipient cases.  See http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-36#appendix-A= .7 and http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-36#appendix-= A.5 for examples.   See the history entries for details on th= e few other changes.  No breaking changes were made.

 

The specifications are available at:

·        http://tools.ietf.org/html/draft-ietf-jose= -json-web-signature-36

·        http://tools.ietf.org/html/draft-ietf-jos= e-json-web-encryption-36

·        http://tools.ietf.org/html/draft-ietf-jose-json-= web-key-36

·        http://tools.ietf.org/html/draft-ietf-jos= e-json-web-algorithms-36

·        http://tools.ietf.org/html/draft-ietf-oauth-j= son-web-token-30

 

HTML formatted versions are available at:=

·        http://self-issued.info/docs/draft-= ietf-jose-json-web-signature-36.html

·        http://self-issued.info/docs/draft= -ietf-jose-json-web-encryption-36.html

·        http://self-issued.info/docs/draft-ietf-j= ose-json-web-key-36.html

·        http://self-issued.info/docs/draft= -ietf-jose-json-web-algorithms-36.html

·        http://self-issued.info/docs/draft-iet= f-oauth-json-web-token-30.html

 

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

 

P.S.  I’ve also posted this notice at http://self-issued.info/?p=3D1296 and as @selfissued.

--_000_4E1F6AAD24975D4BA5B16804296739439BB2624ETK5EX14MBXC286r_-- From nobody Fri Oct 24 23:33:49 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58DDF1A7005; Fri, 24 Oct 2014 23:33:43 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9axvEOxbiwMy; Fri, 24 Oct 2014 23:33:40 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0762.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::762]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFCAF1A7004; Fri, 24 Oct 2014 23:33:39 -0700 (PDT) Received: from CH1PR03CA011.namprd03.prod.outlook.com (10.255.156.156) by BY1PR0301MB1208.namprd03.prod.outlook.com (25.161.203.16) with Microsoft SMTP Server (TLS) id 15.1.6.9; Sat, 25 Oct 2014 06:33:15 +0000 Received: from BL2FFO11FD030.protection.gbl (10.255.156.132) by CH1PR03CA011.outlook.office365.com (10.255.156.156) with Microsoft SMTP Server (TLS) id 15.1.6.9 via Frontend Transport; Sat, 25 Oct 2014 06:33:15 +0000 Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD030.mail.protection.outlook.com (10.173.161.40) with Microsoft SMTP Server (TLS) id 15.0.1049.20 via Frontend Transport; Sat, 25 Oct 2014 06:33:15 +0000 Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.93]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.193]) with mapi id 14.03.0210.003; Sat, 25 Oct 2014 06:32:46 +0000 From: Mike Jones To: 'Stephen Farrell' , The IESG Thread-Topic: Stephen Farrell's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) Thread-Index: Ac/wHXZicsJzwKMjQzKRicyupW00kA== Date: Sat, 25 Oct 2014 06:32:45 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439BB26277@TK5EX14MBXC286.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(189002)(51704005)(52604005)(377454003)(479174003)(69224002)(24454002)(13464003)(199003)(43784003)(52044002)(2656002)(99396003)(80022003)(230783001)(64706001)(31966008)(23676002)(50986999)(54356999)(104016003)(6806004)(85852003)(120916001)(4396001)(77096002)(85306004)(86362001)(55846006)(76482002)(47776003)(20776003)(26826002)(92566001)(92726001)(21056001)(33656002)(46102003)(15202345003)(97736003)(86612001)(87936001)(66066001)(15975445006)(19580395003)(19580405001)(107046002)(95666004)(50466002)(44976005)(85806002)(69596002)(68736004)(106466001)(81156004)(84676001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0301MB1208; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BY1PR0301MB1208; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0375972289 Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/_Gw3e61HKtnKkvDhA2RsNKEFzEA Cc: "oauth-chairs@tools.ietf.org" , "draft-ietf-oauth-json-web-token@tools.ietf.org" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Oct 2014 06:33:43 -0000 SGkgU3RlcGhlbiwNCg0KSSBhcHBsaWVkIHlvdXIgcHJpdmFjeSB3b3JkaW5nIHRvIHRoZSAtMzAg ZHJhZnQuICBUaGFua3MuDQoNCkFib3V0IHlvdXIgRElTQ1VTUyBvbiAiYWxnIjoibm9uZSIgYmVp bmcgTVRJLCBzZXZlcmFsIHdvcmtpbmcgZ3JvdXAgbWVtYmVycyBoYXZlIGNoaW1lZCBpbiBhZ3Jl ZWluZyB0aGF0IGl0IHNob3VsZCBjb250aW51ZSB0byBiZSBNVEksIGFuZCBzYWlkIHdoeS4gIElu IHN1bW1hcnkgLSB1bnNpZ25lZCBzZWN1cml0eSB0b2tlbnMgcmVwcmVzZW50aW5nIGNsYWltcyBh cmUgcmVhbGx5IGNvbW1vbiBpbiBpZGVudGl0eSBwcm90b2NvbHM7IGludGVyb3Agd2lsbCBiZSBp bXByb3ZlZCBpZiB0aGlzIGZ1bmN0aW9uYWxpdHkgaXMgTVRJLiAgQ2FuIEkgdGhlcmVmb3JlIGFz ayB5b3UgaG9sZCB5b3VyIG5vc2UgYSBsaXR0bGUgYml0IG1vcmUgYW5kIGNsZWFyIHRoaXMgcmVt YWluaW5nIERJU0NVU1M/DQoNCgkJCQlUaGFua3MgYWdhaW4sDQoJCQkJLS0gTWlrZQ0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogU3RlcGhlbiBGYXJyZWxsIFttYWlsdG86c3Rl cGhlbi5mYXJyZWxsQGNzLnRjZC5pZV0gDQpTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDIxLCAyMDE0 IDY6MTcgQU0NClRvOiBNaWtlIEpvbmVzOyBUaGUgSUVTRw0KQ2M6IG9hdXRoLWNoYWlyc0B0b29s cy5pZXRmLm9yZzsgZHJhZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi10b2tlbkB0b29scy5pZXRmLm9y Zzsgb2F1dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBTdGVwaGVuIEZhcnJlbGwncyBEaXNjdXNz IG9uIGRyYWZ0LWlldGYtb2F1dGgtanNvbi13ZWItdG9rZW4tMjc6ICh3aXRoIERJU0NVU1MgYW5k IENPTU1FTlQpDQoNCg0KSGkgTWlrZSwNCg0KSSd2ZSBvbmUgcmVtYWluaW5nIGRpc2N1c3MgcG9p bnQgYW5kIGEgY29tbWVudC4gU2VlIGJlbG93Li4uDQoNCk9uIDE0LzEwLzE0IDEzOjUwLCBNaWtl IEpvbmVzIHdyb3RlOg0KPiBUaGUgcHJvcG9zZWQgcmVzb2x1dGlvbnMgYmVsb3cgaGF2ZSBiZWVu IGluY2x1ZGVkIGluIHRoZSAtMjggZHJhZnQuICBIb3BlZnVsbHkgeW91J2xsIGJlIGFibGUgdG8g Y2xlYXIgeW91ciBESVNDVVNTZXMgb24gdGhhdCBiYXNpcy4NCj4gDQo+IFRoZSBTdHJpbmcgQ29t cGFyaXNvbiBSdWxlcyBpbiBTZWN0aW9uIDcuMyBoYXZlIGJlZW4gZXhwYW5kZWQgdG8gdGFsayBh Ym91dCB3aGVuIHRoZSBhcHBsaWNhdGlvbiBtYXkgbmVlZCBjYW5vbmljYWxpemF0aW9uIHJ1bGVz Lg0KPiANCj4gCQkJCVRoYW5rcyBhZ2FpbiwNCj4gCQkJCS0tIE1pa2UNCj4gDQo+PiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWlrZSBKb25lcw0KPj4gU2VudDogTW9uZGF5LCBPY3Rv YmVyIDA2LCAyMDE0IDc6MjAgUE0NCj4+IFRvOiBTdGVwaGVuIEZhcnJlbGw7IFRoZSBJRVNHDQo+ PiBDYzogb2F1dGgtY2hhaXJzQHRvb2xzLmlldGYub3JnOyBkcmFmdC1pZXRmLW9hdXRoLWpzb24t d2ViLSANCj4+IHRva2VuQHRvb2xzLmlldGYub3JnOyBvYXV0aEBpZXRmLm9yZw0KPj4gU3ViamVj dDogUmU6IFtPQVVUSC1XR10gU3RlcGhlbiBGYXJyZWxsJ3MgRGlzY3VzcyBvbiANCj4+IGRyYWZ0 LWlldGYtb2F1dGgtanNvbi0NCj4+IHdlYi10b2tlbi0yNzogKHdpdGggRElTQ1VTUyBhbmQgQ09N TUVOVCkNCj4+DQo+PiBUaGFua3MgZm9yIHRyYWNraW5nIGFsbCBvZiB0aGlzIFN0ZXBoZW4uICBS ZXNwb25zZXMgaW5saW5lIGJlbG93Li4uDQo+Pg0KPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+Pj4gRnJvbTogU3RlcGhlbiBGYXJyZWxsIFttYWlsdG86c3RlcGhlbi5mYXJyZWxsQGNz LnRjZC5pZV0NCj4+PiBTZW50OiBNb25kYXksIE9jdG9iZXIgMDYsIDIwMTQgMjo0MyBQTQ0KPj4+ IFRvOiBNaWtlIEpvbmVzOyBUaGUgSUVTRw0KPj4+IENjOiBvYXV0aC1jaGFpcnNAdG9vbHMuaWV0 Zi5vcmc7IGRyYWZ0LWlldGYtb2F1dGgtanNvbi13ZWItIA0KPj4+IHRva2VuQHRvb2xzLmlldGYu b3JnOyBvYXV0aEBpZXRmLm9yZw0KPj4+IFN1YmplY3Q6IFJlOiBTdGVwaGVuIEZhcnJlbGwncyBE aXNjdXNzIG9uIGRyYWZ0LWlldGYtb2F1dGgtanNvbi13ZWItdG9rZW4tMjc6DQo+Pj4gKHdpdGgg RElTQ1VTUyBhbmQgQ09NTUVOVCkNCj4+Pg0KPj4+DQo+Pj4gSGkgTWlrZSwNCj4+Pg0KPj4+IE9u IDA2LzEwLzE0IDA4OjU0LCBNaWtlIEpvbmVzIHdyb3RlOg0KPj4+PiBUaGFua3MgZm9yIHlvdXIg cmV2aWV3LCBTdGVwaGVuLiAgSSd2ZSBhZGRlZCB0aGUgd29ya2luZyBncm91cCB0byANCj4+Pj4g dGhlIHRocmVhZCBzbyB0aGV5J3JlIGF3YXJlIG9mIHlvdXIgY29tbWVudHMuDQo+Pj4+DQo+Pj4+ PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSBGcm9tOiBTdGVwaGVuIEZhcnJlbGwgDQo+Pj4+ PiBbbWFpbHRvOnN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWVdIFNlbnQ6IFRodXJzZGF5LCBPY3Rv YmVyIDAyLCANCj4+Pj4+IDIwMTQNCj4+Pj4+IDU6MDMgQU0gVG86IFRoZSBJRVNHIENjOiBvYXV0 aC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc7DQo+Pj4+PiBkcmFmdC1pZXRmLW9hdXRoLWpzb24td2Vi LSB0b2tlbkB0b29scy5pZXRmLm9yZyBTdWJqZWN0OiBTdGVwaGVuIA0KPj4+Pj4gRmFycmVsbCdz IERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi10b2tlbi0yNzogKHdpdGggDQo+ Pj4+PiBESVNDVVNTIGFuZCBDT01NRU5UKQ0KPj4+Pj4NCj4+Pj4+IFN0ZXBoZW4gRmFycmVsbCBo YXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCj4+Pj4+IGRyYWZ0 LWlldGYtb2F1dGgtanNvbi13ZWItdG9rZW4tMjc6IERpc2N1c3MNCj4+Pj4+DQo+Pj4+PiBXaGVu IHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBs eSB0byANCj4+Pj4+IGFsbCBlbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBD QyBsaW5lcy4gKEZlZWwgZnJlZSB0byANCj4+Pj4+IGN1dCB0aGlzIGludHJvZHVjdG9yeSBwYXJh Z3JhcGgsIGhvd2V2ZXIuKQ0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiBQbGVhc2UgcmVmZXIgdG8NCj4+ Pj4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5o dG1sIGZvciBtb3JlIA0KPj4+Pj4gaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBD T01NRU5UIHBvc2l0aW9ucy4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gVGhlIGRvY3VtZW50LCBhbG9u ZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZA0KPj4+Pj4gaGVyZToN Cj4+Pj4+IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vYXV0aC1q c29uLXdlYi10b2tlbi8NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+ Pj4gLQ0KPj4+Pj4gLS0NCj4+Pj4+IC0NCj4+Pj4+DQo+Pj4+Pg0KPj4+IERJU0NVU1M6DQo+Pj4+ PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj4+Pj4+IC0NCj4+Pj4+IC0tDQo+Pj4+PiAtDQo+Pj4+Pg0KPj4+Pj4NCj4+ Pj4+DQo+Pj4+Pg0KPj4+ICgxKSA0LjEuMSBhbmQgZWxzZXdoZXJlIHlvdSBzYXkgY2FzZS1zZW5z aXRpdmU6IHRoZSBzYW1lIHRoaW5nIEkgDQo+Pj4gcmFpc2VkIHdydCBETlMNCj4+Pj4+IG5hbWVz IGZvciBhbm90aGVyIEpPU0Ugc3BlYyAtIGRvIHlvdSBuZWVkIHRvIHNheSB0aG9zZSBTSE9VTEQg YmUgDQo+Pj4+PiBbdXBwZXJ8bG93ZXJdY2FzZWQgd2hlbiB1c2VkIGluIHRoZXNlPw0KPj4+Pg0K Pj4+PiBJIGJlbGlldmUgdGhhdCBzb21ld2hlcmUgd2Ugc2hvdWxkIHNheSB0aGF0IGlmIGNhc2Ut aW5zZW5zaXRpdmUgDQo+Pj4+IHZhbHVlcywgc3VjaCBhcyBETlMgbmFtZXMsIGFyZSB1c2VkIHdo ZW4gY29uc3RydWN0aW5nICJraWQiIHZhbHVlcywgDQo+Pj4+IHRoYXQgdGhlIGFwcGxpY2F0aW9u IGRvaW5nIHNvIG5lZWRzIHRvIGRlZmluZSBhIGNvbnZlbnRpb24gb24gdGhlIA0KPj4+PiBjYW5v bmljYWwgY2FzZSB0byB1c2UgZm9yIHRoZSBjYXNlLWluc2Vuc2l0aXZlIHBvcnRpb25zLCBzdWNo IGFzIA0KPj4+PiBsb3dlcmNhc2luZyB0aGVtLg0KPj4+DQo+Pj4gQXMgdGhhdCBkaXNjdXNzaW9u J3MgaGFwcGVuaW5nIG9uIHRoZSBrZXkgZHJhZnQsIEknbGwgY2xlYXIgaXQgaGVyZSANCj4+PiBh bmQgdHJ1c3QgeW91IHRvIGZpeCBpZiBhIGNoYW5nZSBpcyB0aGUgZW5kIHJlc3VsdC4NCj4+DQo+ PiBUaGFua3MNCg0KbnANCg0KPj4NCj4+Pj4+ICgyKSBTZWN0aW9uIDg6IFdoeSBpcyAibm9uZSIg TVRJPyBUaGF0IHNlZW1zIGJvdGggYnJva2VuIGFuZCBnb2luZyANCj4+Pj4+IGluIHRoZSBvcHBv c3RpdGUgZGlyZWN0aW9uIGZyb20gb3RoZXIgV0dzIGFuZCBzbyBzaG91bGQgYmUgDQo+Pj4+PiBl eHBsaWNpdGx5IGp1c2lmaWVkIEkgdGhpbmsuIChJZiBhIGdvb2QgZW5vdWdoIGp1c3RpZmljYXRp b24gDQo+Pj4+PiBleGlzdHMgdGhhdCBpcy4pDQo+Pj4+DQo+Pj4+IEl0IGlzIE1USSBiZWNhdXNl IHRoZXJlIGFyZSBzZXZlcmFsIGV4aXN0aW5nIGFwcGxpY2F0aW9ucyBvZiBKV1RzIA0KPj4+PiBp biB3aGljaCBib3RoIHVuc2lnbmVkIGFuZCBzaWduZWQgcmVwcmVzZW50YXRpb25zIG9mIHRoZSBK V1RzIGFyZSANCj4+Pj4gcmVxdWlyZW1lbnRzLiAgVGhlc2UgaW5jbHVkZSBkcmFmdC1pZXRmLW9h dXRoLXRva2VuLWV4Y2hhbmdlLCANCj4+Pj4gZHJhZnQtaHVudC1vYXV0aC12Mi11c2VyLWE0Yywg YW5kIE9wZW5JRCBDb25uZWN0LiAgVGhpcyBpcyBhIHByZXR0eSANCj4+Pj4gY29tbW9uIHBhdHRl cm4gd2hlcmUgeW91IHNpZ24gc29tZXRoaW5nIGlmIHRoZSByZWNpcGllbnQgY2FyZXMgd2hvIA0K Pj4+PiBtYWRlIHRoZSBzdGF0ZW1lbnRzIGFuZCB3aGVyZSB5b3UgZG9uJ3QgaGF2ZSB0byBzaWdu IGl0IGVpdGhlciBpZiANCj4+Pj4gdGhlIHJlY2lwaWVudCBkb2Vzbid0IGNhcmUgd2hvIG1hZGUg dGhlIHN0YXRlbWVudHMNCj4+Pg0KPj4+IEkgZG9uJ3Qgc2VlIGhvdyAobm9uLSlzaWduZXJzIGNh biBkaXZpbmUgbm9uLXZlcmlmaWVyJ3Mgd2lzaGVzIHRoYXQgDQo+Pj4gd2F5LiAoQWJzZW50IG5l Z290aWF0aW9uIG9yIGEgZGlyZWN0b3J5LikNCj4+DQo+PiBTb21ldGltZXMgaXQgZG9lcyBvY2N1 ciB2aWEgbmVnb3RpYXRpb24uICBGb3IgaW5zdGFuY2UsIGluIHNvbWUgDQo+PiBwcm90b2NvbHMs IGF0IHJlZ2lzdHJhdGlvbiB0aW1lLCByZWx5aW5nIHBhcnRpZXMgZXhwbGljaXRseSB0ZWxsIA0K Pj4gaWRlbnRpdHkgcHJvdmlkZXJzIHdoYXQgYWxnb3JpdGhtcyBhcmUgYWNjZXB0YWJsZSB0byB0 aGVtLCB3aGljaCBtYXkgDQo+PiBpbmNsdWRlICJub25lIi4gIE5vIGRpdmluYXRpb24gLSBleHBs aWNpdCBjb21tdW5pY2F0aW9uLg0KPj4NCj4+Pj4gb3IgaWYgaXQgY2FuIHRlbGwgZnJvbQ0KPj4+ PiBhbm90aGVyIHNlY3VyZWQgYXNwZWN0IG9mIHRoZSBhcHBsaWNhdGlvbiBwcm90b2NvbCAodHlw aWNhbGx5IA0KPj4+PiB0aHJvdWdoIHRoZSB1c2Ugb2YgVExTKSB3aG8gbWFkZSB0aGUgc3RhdGVt ZW50cy4gIEluIHRoZSBUTFMgY2FzZSwgDQo+Pj4+IHRoZSBzZXJ2ZXIgYXV0aGVudGljYXRpb24g c3RlcCBtYWtlcyBhIHNpZ25hdHVyZSBzdGVwIHVubmVjZXNzYXJ5LCANCj4+Pj4gc28gYW4gVW5z ZWN1cmVkIEpXVCBpcyBmaW5lIHRoZXJlLg0KPj4+DQo+Pj4gVGhhdCdzIGFyZ3VhYmxlIElNTy4N Cj4+DQo+PiBJIGFncmVlIHRoYXQgaXQncyBhcHBsaWNhdGlvbiBhbmQgY29udGV4dC1kZXBlbmRl bnQgd2hldGhlciBpdCdzIE9LIA0KPj4gb3Igbm90LiAgVGhlIHBvaW50IGlzIHRoYXQgdGhlcmUg ZXhpc3Qgc29tZSBjaXJjdW1zdGFuY2VzIGluIHdoaWNoIGl0IA0KPj4gaXMgT0ssIGFuZCB0aGlz IGZlYXR1cmUgaXMgYmVpbmcgdXNlZCBpbiBzb21lIG9mIHRob3NlIGNhc2VzLg0KPj4NCj4+PiBJ IHRoaW5rIEknbGwgbG9vayBiYWNrIG92ZXIgdGhlIHdnIHRocmVhZCBhbmQgZWl0aGVyIGhvbGQg bXkgbm9zZSBvcg0KPj4NCj4+IFRoaXMgaXNzdWUgd2FzIHRyYWNrZWQgYXMgaHR0cDovL3RyYWMu dG9vbHMuaWV0Zi5vcmcvd2cvam9zZS90cmFjL3RpY2tldC8zNi4NCj4+IEthcmVuIE8nRG9ub2do dWUgcmVjb3JkZWQgdGhpcyBjb25jbHVzaW9uIGluIHRoZSB0cmFja2VyICJOb3RlOiBUaGVyZSAN Cj4+IHdhcyBleHRlbnNpdmUgZGlzY3Vzc2lvbiBvbiB0aGUgbWFpbGluZyBsaXN0LCBhbmQgdGhl IHJvdWdoICANCj4+IGNvbnNlbnN1cyBvZiB0aGUgd29ya2luZyBncm91cCB3YXMgdG8gbGVhdmUg Im5vbmUiIGluIHRoZSBkb2N1bWVudC4iDQo+Pg0KPj4gRGlzY3Vzc2lvbiB0aHJlYWRzIG9uIHRo aXMgdG9waWMgaW5jbHVkZToNCj4+IFtqb3NlXSAjMzY6IEFsZ29yaXRobSAibm9uZSIgc2hvdWxk IGJlIHJlbW92ZWQgDQo+PiBodHRwOi8vd3d3LmlldGYub3JnL21haWwtIGFyY2hpdmUvd2ViL2pv c2UvY3VycmVudC9tc2cwMjkxMS5odG1sIC0gDQo+PiBCZWdhbiBKdWwgMzEsIDIwMTMgICg5MSBt ZXNzYWdlcykgW2pvc2VdIFRleHQgYWJvdXQgYXBwbGljYXRpb25zIGFuZCANCj4+ICJhbGciOiJu b25lIiBodHRwOi8vd3d3LmlldGYub3JnL21haWwtIA0KPj4gYXJjaGl2ZS93ZWIvam9zZS9jdXJy ZW50L21zZzAzMzIxLmh0bWwgLSBCZWdhbiBTZXAgMywgMjAxMyAoNSANCj4+IG1lc3NhZ2VzKQ0K Pj4NCj4+IFRoaXMgaXNzdWUgd2FzIGEgdG9waWMgb2YgYSBzcGVjaWFsIHdvcmtpbmcgZ3JvdXAg Y2FsbCBvbiBBdWcgMTksIA0KPj4gMjAxMy4gIFRoZSB0ZXh0IGRpc2N1c3NlZCBpbiB0aGUgbGFz dCB0aHJlYWQgYW5kIHB1Ymxpc2hlZCBhdCANCj4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC0NCj4+IGlldGYtam9zZS1qc29uLXdlYi1hbGdvcml0aG1zLTMzI3NlY3Rpb24tOC41 IChVbnNlY3VyZWQgSldTIFNlY3VyaXR5DQo+PiBDb25zaWRlcmF0aW9ucykgd2FzIHRoZSByZXN1 bHQgb2YgdGhlIHdvcmtpbmcgZ3JvdXAncyBkZWNpc2lvbnMgDQo+PiByZXN1bHRpbmcgZnJvbSBh bGwgb2YgdGhpcyBkaXNjdXNzaW9uLg0KDQpUaGFua3MgZm9yIGFsbCB0aGUgcG9pbnRlcnMgYWJv dmUuIEkgcmVhZCB0aHJvdWdoIGFsbCB0aGUgKG1hbnkhKSBBdWcgMTkgbWFpbHMgYW5kIG1vc3Qg b2YgdGhlIGAibm9uZSIgc2hvdWxkIGJlIHJlbW92ZWQiIHRocmVhZC4NCg0KU28gSSBkbyBzZWUg dGhhdCB0aGVyZSB3YXMgcm91Z2ggY29uc2Vuc3VzIHRvIGtlZXAgIm5vbmUiIGluIHRoZSBkcmFm dCBhbmQgY2FuICh3aXRoIGRpZmZpY3VsdHk7LSkgaG9sZCBteSBub3NlIGFuZCBsZXQgdGhhdCBw YXNzLiBJIGRvIG5vdCBob3dldmVyLCBzZWUgdGhhdCB0aGVyZSB3YXMgY29uc2Vuc3VzIHRvIG1h a2UgIm5vbmUiIE1USSBmb3IgdGhpcyBkcmFmdC4gSSBkaWQgc2VlIGEgYml0IG9mIGhhZ2dsaW5n IGFib3V0IHRoaXMgZHJhZnQgdnMuIEpXUyBidXQgc3RpbGwgZG8gbm90IHNlZSB3aHkgbm9uZSBv dWdodCBiZSBNVEkgaGVyZS4NCg0KPj4NCj4+Pj4+ICgzKSBTZWN0aW9uIDEyOiBhbm90aGVyIHdh eSB0byBoYW5kbGUgcHJpdmFjeSBpcyB0byBub3QgaW5jbHVkZSANCj4+Pj4+IHNlbnNpdGl2ZSBk YXRhIC0gSSB0aGluayB5b3Ugb3VnaHQgbWVudGlvbiB0aGF0IGFzIGEgYml0IG9mIA0KPj4+Pj4g dGhvdWdodCBhbG9uZyB0aG9zZSBsaW5lcyBjYW4gYmUgbXVjaCBzaW1wbGVyIHRoYW4gcHV0dGlu ZyBpbiANCj4+Pj4+IHBsYWNlIHRoZSBrZXkgbWFuYWdlbWVudCB0byBoYW5kbGUgdGhvdWdodGxl c3NseSBpbmNsdWRlZCBQSUkuDQo+Pj4+DQo+Pj4+IFdlIGNhbiBpbmNsdWRlIGEgZGlzY3Vzc2lv biBvZiB0aGF0IHBvaW50LA0KPj4+DQo+Pj4gR3JlYXQuICJKdXN0IHNheSBubyIgaXMgd29ya2Fi bGUgaGVyZTotKSBJJ2xsIGNsZWFyIHdoZW4gd2UgZ2V0IHN1Y2ggdGV4dC4NCj4+Pg0KPj4+PiBi dXQgc29tZXRpbWVzIHRoZSB2ZXJ5DQo+Pj4+IHBvaW50IG9mIGEgSldUIGlzIHRvIHNlY3VyZWx5 IGRlbGl2ZXIgUElJIGZyb20gYSB2ZXJpZmlhYmxlIHBhcnR5IA0KPj4+PiB0byBhbiBpbnRlbmRl ZCBwYXJ0eSB3aXRoIGFwcHJvcHJpYXRlIHJpZ2h0cyB0byByZWNlaXZlIGl0Lg0KPj4+DQo+Pj4g SG1tLiBJdHMgYSBtb290IHBvaW50IChzbyBsZXQncyBub3QgYXJndWUgaXQpIGJ1dCBJIHdvbmRl ciBob3cgb2Z0ZW4gDQo+Pj4gUElJIGlzIHJlYWxseSBuZWVkZWQgZm9yIGF1dGhvcml6YXRpb24g d2l0aCBvYXV0aC4gTXkgZ3Vlc3Mgd291bGQgYmUgDQo+Pj4gdGhhdCBpdHMgbmVlZGVkIGZhciBs ZXNzIG9mdGVuIHRoYW4gaXRzIGZvdW5kIHRvIGJlIHByb2ZpdGFibGUgDQo+Pj4gcGVyaGFwcywg b3IgdGhhdCBjYXJlbGVzc25lc3MgcGxheXMgYSBiaWcgcm9sZSBpbiB1c2luZyBQSUkgZm9yIHN1 Y2ggcHVycG9zZXMuDQoNCkkndmUgY2xlYXJlZCBvbiB0aGlzIGFzIHlvdSBhZGRlZCB0aGlzIHRl eHQ6DQoNCiAgIk9mIGNvdXJzZSwgaW5jbHVkaW5nCQ0KICAgb25seSBuZWNlc3NhcnkgcHJpdmFj eS1zZW5zaXRpdmUgaW5mb3JtYXRpb24gaW4gYSBKV1QgaXMgdGhlIG1vc3QJDQogICBiYXNpYyBt ZWFucyBvZiBtaW5pbWl6aW5nIGFueSBwb3RlbnRpYWwgcHJpdmFjeSBpc3N1ZXMuIg0KDQpUaGF0 IHNlZW1zIHRvIG1lIGxpa2UgYSBmYWlybHkgb2ZmcHV0dGluZyB3YXkgdG8gcGhyYXNlIGl0LiBJ J2Qgc3VnZ2VzdCBpbnN0ZWFkOg0KDQogICJPbWl0dGluZyBwcml2YWN5LXNlbnNpdGl2ZSBpbmZv cm1hdGlvbiBmcm9tIGEgSldUIGlzIHRoZQ0KICBzaW1wbGVzdCB3YXkgb2YgbWluaW1pemluZyBw cml2YWN5IGlzc3Vlcy4iDQoNCkNoZWVycywNClMuDQoNClBTOiBJIGRpZG4ndCBjaGVjayB0aGUg Y29tbWVudHMuDQoNCj4+Pg0KPj4+IFMuDQo+Pj4NCj4+Pg0KPj4+DQo+Pj4+DQo+Pj4+PiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCj4+Pj4+IC0NCj4+Pj4+IC0tDQo+Pj4+PiAtDQo+Pj4+Pg0KPj4+Pj4NCj4+PiBDT01N RU5UOg0KPj4+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4+PiAtDQo+Pj4+PiAtLQ0KPj4+Pj4gLQ0KPj4+Pj4N Cj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+PiAtIGFic3RyYWN0OiAybmQgc2VudGVuY2UgaXNuJ3Qg bmVlZGVkIGhlcmUsIGluIGludHJvIHdvdWxkIGJlIGZpbmUuDQo+Pj4+DQo+Pj4+IEkgZG9uJ3Qg a25vdyAtIEkgdGhpbmsgaXQncyBhIGJpZyBkZWFsIHRoYXQgdGhlIGNsYWltcyBjYW4gYmUgDQo+ Pj4+IGRpZ2l0YWxseSBzaWduZWQgb3IgTUFDZWQgYW5kL29yIGVuY3J5cHRlZC4gIFRoYXQncyB0 aGUgcmVhc29uIHdlIA0KPj4+PiBoYXZlIEpXVHMsIHJhdGhlciB0aGFuIGp1c3QgSlNPTi4NCj4+ Pj4NCj4+Pj4+IC0gNC4xLjc6IG1heWJlIHdvcnRoIGFkZGluZyB0aGF0IGp0aStpc3MgYmVpbmcg dW5pcXVlIGVub3VnaCBpcyANCj4+Pj4+IG5vdCBzdWZmaWNpZW50IGFuZCBqdGkgYWxvbmUgaGFz IHRvIG1lZXQgdGhhdCBuZWVkLiBJbiBYLjUwOSB0aGUgDQo+Pj4+PiBpc3N1ZXIvc2VyaWFsIGhh cyB0aGUgZXF1aXZhbGVudCBwcm9wZXJ0eSBzbyBzb21lb25lIG1pZ2h0IGFzc3VtZSANCj4+Pj4+ IHNlcXVlbnRpYWwganRpIHZhbHVlcyBzdGFydGluZyBhdCAwIGFyZSBvay4NCj4+Pj4NCj4+Pj4g TWFrZXMgc2Vuc2UgdG8gYWRkIGEgd2FybmluZyBvZiBzb21lIGtpbmQgYWxvbmcgdGhlc2UgbGlu ZXMuICBJIA0KPj4+PiB0aGluayBJIGtub3cgdGhlIHJlYXNvbnMgeW91IHNheSB0aGF0LCBidXQg Y2FuIHlvdSBleHBhbmQgb24gdGhhdCANCj4+Pj4gdGhvdWdodCBhIGJpdCBiZWZvcmUgSSB0YWtl IGEgc3RhYiBvbiB3cml0aW5nIHRoaXMgdXA/ICBGb3IgDQo+Pj4+IGluc3RhbmNlLCB3aGlsZSBu b3JtYWxseSB0cnVlLCBJIGRvbid0IHRoaW5rIHlvdXIgb2JzZXJ2YXRpb24gaXMgDQo+Pj4+IHRy dWUgaWYgYSByZWx5aW5nIHBhcnR5IHdpbGwgb25seSBhY2NlcHQgdG9rZW5zIGZyb20gYSBzaW5n bGUgaXNzdWVyLg0KPj4+Pg0KPj4+Pj4gLSBzZWN0aW9uIDY6IHl1aw0KPj4+Pj4NCj4+Pj4+IC0g YWdhaW4gSSB0aGluayB0aGUgc2VjZGlyIGNvbW1lbnRzIGFyZSBiZWluZyBoYW5kbGVkIGJ5IEth dGhsZWVuIA0KPj4+Pj4gYW5kIHRoZSBhdXRob3JzLg0KPj4+Pg0KPj4+PiBBZ2FpbiwgdGhpcyBp cyB0aGVyZSBiZWNhdXNlIG11bHRpcGxlIGFwcGxpY2F0aW9ucyBhc2tlZCBmb3IgdGhlIA0KPj4+ PiBhYmlsaXR5IHRvIHJlcHJlc2VudCBjb250ZW50IHRoYXQgaXMgb3B0aW9uYWxseSBzaWduZWQs IHNvbWV0aW1lcyANCj4+Pj4gc2VjdXJpbmcgaXQgYW5vdGhlciB3YXksIHN1Y2ggYXMgd2l0aCBU TFMuICBKV1RzIGFyZSB1c2VkIHNwZWNpZmljIA0KPj4+PiBhcHBsaWNhdGlvbiBwcm90b2NvbCBj b250ZXh0cyAtIG5vdCBpbiBpc29sYXRpb24uDQo+Pj4+DQo+Pj4+IFRoYW5rcyBhZ2FpbiwgLS0g TWlrZQ0KPj4+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4+IE9BdXRoIG1haWxpbmcgbGlzdA0KPj4gT0F1dGhAaWV0Zi5vcmcNCj4+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCj4gDQo= From nobody Fri Oct 24 23:33:50 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C16ED1A8026; Fri, 24 Oct 2014 23: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lE5Hm8P8Xpk9; Fri, 24 Oct 2014 23:33:43 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0137.outbound.protection.outlook.com [207.46.100.137]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 271A11A6FB5; Fri, 24 Oct 2014 23:33:43 -0700 (PDT) Received: from CO2PR03CA0017.namprd03.prod.outlook.com (10.141.194.144) by DM2PR0301MB1214.namprd03.prod.outlook.com (25.160.219.155) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Sat, 25 Oct 2014 06:33:41 +0000 Received: from BN1AFFO11FD038.protection.gbl (2a01:111:f400:7c10::154) by CO2PR03CA0017.outlook.office365.com (2a01:111:e400:1414::16) with Microsoft SMTP Server (TLS) id 15.1.6.9 via Frontend Transport; Sat, 25 Oct 2014 06:33:41 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD038.mail.protection.outlook.com (10.58.52.242) with Microsoft SMTP Server (TLS) id 15.0.1049.20 via Frontend Transport; Sat, 25 Oct 2014 06:33:40 +0000 Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.93]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.03.0210.003; Sat, 25 Oct 2014 06:33:12 +0000 From: Mike Jones To: Alissa Cooper Thread-Topic: Alissa Cooper's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS) Thread-Index: Ac/wHYlUBVIbaR7EQTyqVnZrHOlz4Q== Date: Sat, 25 Oct 2014 06:33:10 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439BB2628A@TK5EX14MBXC286.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439BB2628ATK5EX14MBXC286r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(438002)(52044002)(43784003)(24454002)(41574002)(377454003)(189002)(13464003)(199003)(85852003)(106466001)(92566001)(19617315012)(21056001)(110136001)(20776003)(77096002)(81156004)(15202345003)(104016003)(92726001)(19300405004)(19625215002)(80022003)(84326002)(15975445006)(46102003)(85806002)(107046002)(31966008)(97736003)(33656002)(512874002)(4396001)(66066001)(85306004)(68736004)(69596002)(99396003)(76482002)(55846006)(6806004)(19580395003)(44976005)(230783001)(84676001)(19580405001)(87936001)(2656002)(120916001)(16236675004)(86612001)(95666004)(86362001)(71186001)(50986999)(54356999)(64706001)(26826002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB1214; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB1214; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0375972289 Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/xjYp8CUY5GcEZczs2yyJXooTfbg Cc: "oauth-chairs@tools.ietf.org" , "oauth@ietf.org" , The IESG , "draft-ietf-oauth-json-web-token@tools.ietf.org" Subject: Re: [OAUTH-WG] Alissa Cooper's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Oct 2014 06:33:46 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439BB2628ATK5EX14MBXC286r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWxpc3NhLA0KDQpJbiBhZGRpdGlvbiB0byBpbmNvcnBvcmF0aW5nIHlvdXIgcHJvcG9zZWQg dGV4dCBlYXJsaWVyLCBJIGFsc28ganVzdCBpbmNsdWRlZCB0aGlzIHNlbnRlbmNlIGluIHRoZSBw cml2YWN5IGNvbnNpZGVyYXRpb25zIHRleHQgb2YgZHJhZnQgLTMwLCB3aGljaCB3YXMgc3VwcGxp ZWQgYnkgU3RlcGhlbjoNCuKAnE9taXR0aW5nIHByaXZhY3ktc2Vuc2l0aXZlIGluZm9ybWF0aW9u IGZyb20gYSBKV1QgaXMgdGhlIHNpbXBsZXN0IHdheSBvZiBtaW5pbWl6aW5nIHByaXZhY3kgaXNz dWVz4oCdLg0KDQpIb3BlZnVsbHkgdGhlc2UgcmVzb2x1dGlvbnMgd2lsbCBlbmFibGUgeW91IHRv IGNsZWFyIHlvdXIgRElTQ1VTUy4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgVGhhbmtzIGFnYWluLA0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpG cm9tOiBNaWtlIEpvbmVzIFttYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tXQ0KU2Vu dDogVHVlc2RheSwgT2N0b2JlciAxNCwgMjAxNCA1OjQ1IEFNDQpUbzogQWxpc3NhIENvb3Blcg0K Q2M6IEthdGhsZWVuIE1vcmlhcnR5OyBUaGUgSUVTRzsgb2F1dGgtY2hhaXJzQHRvb2xzLmlldGYu b3JnPG1haWx0bzpvYXV0aC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+OyBkcmFmdC1pZXRmLW9hdXRo LWpzb24td2ViLXRva2VuQHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLW9hdXRoLWpz b24td2ViLXRva2VuQHRvb2xzLmlldGYub3JnPjsgb2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRo QGlldGYub3JnPg0KU3ViamVjdDogUkU6IEFsaXNzYSBDb29wZXIncyBEaXNjdXNzIG9uIGRyYWZ0 LWlldGYtb2F1dGgtanNvbi13ZWItdG9rZW4tMjc6ICh3aXRoIERJU0NVU1MpDQoNClRoZXNlIHJl c29sdXRpb25zIGhhdmUgYmVlbiBpbmNvcnBvcmF0ZWQgaW4gdGhlIC0yOCBkcmFmdC4gIFRoYW5r cyBhZ2FpbiBmb3IgeW91ciByZXZpZXcuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogS2F0aGxlZW4g TW9yaWFydHkgW21haWx0bzprYXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbV0NClNlbnQ6 IFRodXJzZGF5LCBPY3RvYmVyIDAyLCAyMDE0IDg6MjEgQU0NClRvOiBNaWtlIEpvbmVzDQpDYzog QWxpc3NhIENvb3BlcjsgVGhlIElFU0c7IG9hdXRoLWNoYWlyc0B0b29scy5pZXRmLm9yZzxtYWls dG86b2F1dGgtY2hhaXJzQHRvb2xzLmlldGYub3JnPjsgZHJhZnQtaWV0Zi1vYXV0aC1qc29uLXdl Yi10b2tlbkB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi10 b2tlbkB0b29scy5pZXRmLm9yZz47IG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9y Zz4NClN1YmplY3Q6IFJlOiBBbGlzc2EgQ29vcGVyJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLW9h dXRoLWpzb24td2ViLXRva2VuLTI3OiAod2l0aCBESVNDVVNTKQ0KDQoNCg0KT24gVGh1LCBPY3Qg MiwgMjAxNCBhdCAxMToxNCBBTSwgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQu Y29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+PiB3cm90ZToNCg0KUmVzcG9u ZGluZyB0byB0aGUgRElTQ1VTUyBiZWxvd+KApg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IEFsaXNzYSBDb29wZXIgW21haWx0bzphbGlzc2FAY29vcGVydy5pbjxtYWls dG86YWxpc3NhQGNvb3BlcncuaW4+XQ0KU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDAxLCAyMDE0 IDEyOjI1IFBNDQpUbzogVGhlIElFU0cNCkNjOiBvYXV0aC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc8 bWFpbHRvOm9hdXRoLWNoYWlyc0B0b29scy5pZXRmLm9yZz47IGRyYWZ0LWlldGYtb2F1dGgtanNv bi13ZWItdG9rZW5AdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtb2F1dGgtanNvbi13 ZWItdG9rZW5AdG9vbHMuaWV0Zi5vcmc+DQpTdWJqZWN0OiBBbGlzc2EgQ29vcGVyJ3MgRGlzY3Vz cyBvbiBkcmFmdC1pZXRmLW9hdXRoLWpzb24td2ViLXRva2VuLTI3OiAod2l0aCBESVNDVVNTKQ0K DQoNCg0KQWxpc3NhIENvb3BlciBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3Np dGlvbiBmb3INCg0KZHJhZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi10b2tlbi0yNzogRGlzY3Vzcw0K DQoNCg0KV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFj dCBhbmQgcmVwbHkgdG8gYWxsIGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5k IENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzIGludHJvZHVjdG9yeSBwYXJhZ3JhcGgs IGhvd2V2ZXIuKQ0KDQoNCg0KDQoNClBsZWFzZSByZWZlciB0byBodHRwOi8vd3d3LmlldGYub3Jn L2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KDQpmb3IgbW9yZSBpbmZvcm1h dGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KDQoNCg0KDQoN ClRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUg Zm91bmQgaGVyZToNCg0KaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRm LW9hdXRoLWpzb24td2ViLXRva2VuLw0KDQoNCg0KDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCkRJ U0NVU1M6DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQoNCj09IFNlY3Rpb24gMTIgPT0NCg0KDQoNCiJB IEpXVCBtYXkgY29udGFpbiBwcml2YWN5LXNlbnNpdGl2ZSBpbmZvcm1hdGlvbi4gIFdoZW4gdGhp cyBpcyB0aGUNCg0KICAgY2FzZSwgbWVhc3VyZXMgbXVzdCBiZSB0YWtlbiB0byBwcmV2ZW50IGRp c2Nsb3N1cmUgb2YgdGhpcw0KDQogICBpbmZvcm1hdGlvbiB0byB1bmludGVuZGVkIHBhcnRpZXMu Ig0KDQoNCg0KSXQgc2VlbXMgdG8gbWUgdGhhdCB0aGlzIHNob3VsZCBiZSBhIG5vcm1hdGl2ZSBN VVNULCBwYXJ0aWN1bGFybHkgaW4gbGlnaHQgb2YgdGhlIGZhY3QgdGhhdCBjbGFpbXMgYXJlIGJl aW5nIGRlZmluZWQgdGhhdCBhcmUgbWVhbnQgdG8gZGlyZWN0bHkgaWRlbnRpZnkgdXNlcnMgKGUu Zy4sIHN1YikgYW5kIG90aGVyIGNsYWltcyBkZWZpbmVkIGhlcmUgb3IgbGF0ZXIgY291bGQgZG8g c28gYXMgd2VsbC4NCg0KDQoNClRoZXJlIHNlZW1zIHRvIGJlIGRlYmF0ZSB3aGV0aGVyIGEgMjEx OSBsYW5ndWFnZSBzaG91bGQgYmUgdXNlZCBvdGhlciB0aGFuIHdoZW4gZGVzY3JpYmluZyBwcm90 b2NvbCByZXF1aXJlbWVudHMuICBKaW0gU2NoYWFkICh0aGUgSk9TRSBjaGFpcikgYmVsaWV2ZXMg dGhhdCB0aGV5IHNob3VsZG7igJl0IGFuZCB0aGVzZSBkb2N1bWVudHMgaGF2ZSBmb2xsb3dlZCB0 aGF0IGNvbnZlbnRpb24uDQpXaXRoIG90aGVyIGRvY3VtZW50cywgdGhlcmUgaXMgUkZDMjExOSBs YW5ndWFnZSB1c2VkIGZvciBzZWN1cml0eSAmIHByaXZhY3kgY29uc2lkZXJhdGlvbnMuICBBdCBz b21lIHBvaW50IHRoZXJlIHdhcyBhIHRyZW5kIHRvIGhhdmUgYSBzZXBhcmF0ZSAiU2VjdXJpdHkg UmVxdWlyZW1lbnRzIiBzZWN0aW9uIGZyb20gIlNlY3VyaXR5IENvbnNpZGVyYXRpb25zIiwgYnV0 IEkgZG9uJ3QgdGhpbmsgdGhlcmUgd2FzIGFueSByZXF1aXJlbWVudCBmb3IgdGhpcywganVzdCBh IHByZWZlcmVuY2UuICBJIGFncmVlIHRoYXQgdGhpcyBzaG91bGQgYmUgYSBNVVNULCBidXQgd2l0 aCBTdGVwaGVuIGFzIHdlbGwgdGhhdCB5b3Ugc2hvdWxkIGRpc2NvdXJhZ2UgcHV0dGluZyBpbiBw cml2YWN5IHJlbGF0ZWQgaW5mb3JtYXRpb24gdG8gYmVnaW4gd2l0aC4NCg0KDQoNCiJPbmUgd2F5 IHRvIGFjaGlldmUgdGhpcyBpcyB0byB1c2UNCg0KICAgYW4gZW5jcnlwdGVkIEpXVC4gIEFub3Ro ZXIgd2F5IGlzIHRvIGVuc3VyZSB0aGF0IEpXVHMgY29udGFpbmluZw0KDQogICB1bmVuY3J5cHRl ZCBwcml2YWN5LXNlbnNpdGl2ZSBpbmZvcm1hdGlvbiBhcmUgb25seSB0cmFuc21pdHRlZCBvdmVy DQoNCiAgIGVuY3J5cHRlZCBjaGFubmVscyBvciBwcm90b2NvbHMsIHN1Y2ggYXMgVExTLiINCg0K DQoNClNpbmNlIHNlbnNpdGl2ZSBKV1RzIHNob3VsZCBiZSBwcm90ZWN0ZWQgZnJvbSBib3RoIGlu dGVybWVkaWFyeSBvYnNlcnZhdGlvbiBhbmQgZnJvbSBiZWluZyBzZW50IHRvIHVuaW50ZW5kZWQg cmVjaXBpZW50cywgSSB3b3VsZA0KDQpzdWdnZXN0Og0KDQoNCg0KT25lIHdheSB0byBhY2hpZXZl IHRoaXMgaXMgdG8gdXNlIGFuIGVuY3J5cHRlZCBKV1QgYW5kIGF1dGhlbnRpY2F0ZSB0aGUgcmVj aXBpZW50LiBBbm90aGVyIHdheSBpcyB0byBlbnN1cmUgdGhhdCBKV1RzIGNvbnRhaW5pbmcgdW5l bmNyeXB0ZWQgcHJpdmFjeS1zZW5zaXRpdmUgaW5mb3JtYXRpb24gYXJlIG9ubHkgdHJhbnNtaXR0 ZWQgb3ZlciBlbmNyeXB0ZWQgY2hhbm5lbHMgb3IgcHJvdG9jb2xzIHRoYXQgYWxzbyBzdXBwb3J0 IGVuZHBvaW50IGF1dGhlbnRpY2F0aW9uLCBzdWNoIGFzIFRMUy4NCg0KDQoNClRoYW5rcyBmb3Ig dGhpcyBzdWdnZXN0ZWQgbGFuZ3VhZ2UuICBXZSBjYW4gaW5jb3Jwb3JhdGUgc29tZXRoaW5nIGxp a2UgdGhhdC4NCk9LLCB0aGlzIG1ha2VzIHNlbnNlIGFuZCB3aWxsIGZlZWQgaW50byBQZXRlJ3Mg ZGlzY3VzcyBvbiB3aGVyZSBUTFMgc2hvdWxkIGJlIHJlcXVpcmVkLg0KDQpUaGFua3MhDQoNCg0K DQoNCg0KLS0NCg0KQmVzdCByZWdhcmRzLA0KS2F0aGxlZW4NCg== --_000_4E1F6AAD24975D4BA5B16804296739439BB2628ATK5EX14MBXC286r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvQWNl dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5 bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30N CnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu MHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIEFsaXNz YSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkluIGFkZGl0aW9uIHRvIGluY29ycG9yYXRpbmcgeW91ciBwcm9wb3NlZCB0 ZXh0IGVhcmxpZXIsIEkgYWxzbyBqdXN0IGluY2x1ZGVkIHRoaXMgc2VudGVuY2UgaW4gdGhlIHBy aXZhY3kgY29uc2lkZXJhdGlvbnMgdGV4dCBvZiBkcmFmdCAtMzAsIHdoaWNoIHdhcyBzdXBwbGll ZA0KIGJ5IFN0ZXBoZW46PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPuKAnE9taXR0aW5n IHByaXZhY3ktc2Vuc2l0aXZlIGluZm9ybWF0aW9uIGZyb20gYSBKV1QgaXMgdGhlIHNpbXBsZXN0 IHdheSBvZiBtaW5pbWl6aW5nIHByaXZhY3kgaXNzdWVz4oCdLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SG9wZWZ1bGx5 IHRoZXNlIHJlc29sdXRpb25zIHdpbGwgZW5hYmxlIHlvdSB0byBjbGVhciB5b3VyIERJU0NVU1Mu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhhbmtzIGFnYWluLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu IDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE1pa2Ug Sm9uZXMgWzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iPm1haWx0 bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1 ZXNkYXksIE9jdG9iZXIgMTQsIDIwMTQgNTo0NSBBTTxicj4NCjxiPlRvOjwvYj4gQWxpc3NhIENv b3Blcjxicj4NCjxiPkNjOjwvYj4gS2F0aGxlZW4gTW9yaWFydHk7IFRoZSBJRVNHOyA8YSBocmVm PSJtYWlsdG86b2F1dGgtY2hhaXJzQHRvb2xzLmlldGYub3JnIj4NCm9hdXRoLWNoYWlyc0B0b29s cy5pZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLW9hdXRoLWpzb24td2Vi LXRva2VuQHRvb2xzLmlldGYub3JnIj4NCmRyYWZ0LWlldGYtb2F1dGgtanNvbi13ZWItdG9rZW5A dG9vbHMuaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPg0Kb2F1 dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBBbGlzc2EgQ29vcGVyJ3Mg RGlzY3VzcyBvbiBkcmFmdC1pZXRmLW9hdXRoLWpzb24td2ViLXRva2VuLTI3OiAod2l0aCBESVND VVNTKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGVzZSByZXNvbHV0aW9ucyBo YXZlIGJlZW4gaW5jb3Jwb3JhdGVkIGluIHRoZSAtMjggZHJhZnQuJm5ic3A7IFRoYW5rcyBhZ2Fp biBmb3IgeW91ciByZXZpZXcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gS2F0aGxlZW4gTW9yaWFydHkgWzwv c3Bhbj48YSBocmVmPSJtYWlsdG86a2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBnbWFpbC5jb20iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5tYWlsdG86a2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBn bWFpbC5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5dDQo8YnI+DQo8 Yj5TZW50OjwvYj4gVGh1cnNkYXksIE9jdG9iZXIgMDIsIDIwMTQgODoyMSBBTTxicj4NCjxiPlRv OjwvYj4gTWlrZSBKb25lczxicj4NCjxiPkNjOjwvYj4gQWxpc3NhIENvb3BlcjsgVGhlIElFU0c7 IDwvc3Bhbj48YSBocmVmPSJtYWlsdG86b2F1dGgtY2hhaXJzQHRvb2xzLmlldGYub3JnIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+b2F1dGgtY2hhaXJzQHRvb2xzLmlldGYub3JnPC9zcGFu PjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Ow0KPC9zcGFuPjxhIGhyZWY9Im1haWx0 bzpkcmFmdC1pZXRmLW9hdXRoLWpzb24td2ViLXRva2VuQHRvb2xzLmlldGYub3JnIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+ZHJhZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi10b2tlbkB0b29s cy5pZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjsNCjwvc3Bh bj48YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5vYXV0aEBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi Pjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogQWxpc3NhIENvb3BlcidzIERpc2N1c3Mgb24gZHJh ZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi10b2tlbi0yNzogKHdpdGggRElTQ1VTUyk8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIE9jdCAyLCAyMDE0IGF0IDExOjE0IEFNLCBNaWtlIEpv bmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIiB0YXJn ZXQ9Il9ibGFuayI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMw Ij5SZXNwb25kaW5nIHRvIHRoZSBESVNDVVNTIGJlbG934oCmPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcwQzAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogQWxpc3NhIENv b3BlciBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzphbGlzc2FAY29vcGVydy5pbiIgdGFyZ2V0PSJf YmxhbmsiPmFsaXNzYUBjb29wZXJ3LmluPC9hPl0NCjxicj4NClNlbnQ6IFdlZG5lc2RheSwgT2N0 b2JlciAwMSwgMjAxNCAxMjoyNSBQTTxicj4NClRvOiBUaGUgSUVTRzxicj4NCkNjOiA8YSBocmVm PSJtYWlsdG86b2F1dGgtY2hhaXJzQHRvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1 dGgtY2hhaXJzQHRvb2xzLmlldGYub3JnPC9hPjsNCjxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRm LW9hdXRoLWpzb24td2ViLXRva2VuQHRvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ZHJh ZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi10b2tlbkB0b29scy5pZXRmLm9yZzwvYT48YnI+DQpTdWJq ZWN0OiBBbGlzc2EgQ29vcGVyJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLW9hdXRoLWpzb24td2Vi LXRva2VuLTI3OiAod2l0aCBESVNDVVNTKTxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8cD5BbGlzc2EgQ29vcGVyIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFs bG90IHBvc2l0aW9uIGZvcjxvOnA+PC9vOnA+PC9wPg0KPHA+ZHJhZnQtaWV0Zi1vYXV0aC1qc29u LXdlYi10b2tlbi0yNzogRGlzY3VzczxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cD5XaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUg aW50YWN0IGFuZCByZXBseSB0byBhbGwgZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBU byBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMgaW50cm9kdWN0b3J5IHBhcmFn cmFwaCwgaG93ZXZlci4pPG86cD48L286cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+UGxlYXNlIHJlZmVyIHRvIDxhIGhyZWY9Imh0 dHA6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sIiB0 YXJnZXQ9Il9ibGFuayI+DQo8c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29y YXRpb246bm9uZSI+aHR0cDovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNy aXRlcmlhLmh0bWw8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHA+Zm9yIG1vcmUgaW5mb3Jt YXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy48bzpwPjwvbzpw PjwvcD4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8cD5UaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2Fu IGJlIGZvdW5kIGhlcmU6PG86cD48L286cD48L3A+DQo8cD48YSBocmVmPSJodHRwOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtb2F1dGgtanNvbi13ZWItdG9rZW4vIiB0YXJn ZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9u Om5vbmUiPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vYXV0aC1q c29uLXdlYi10b2tlbi88L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHA+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9wPg0KPHA+RElTQ1VTUzo8bzpwPjwv bzpwPjwvcD4NCjxwPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHA+PT0gU2VjdGlvbiAxMiA9PTxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cD4mcXVvdDtBIEpXVCBtYXkgY29udGFpbiBwcml2YWN5LXNlbnNp dGl2ZSBpbmZvcm1hdGlvbi4mbmJzcDsgV2hlbiB0aGlzIGlzIHRoZTxvOnA+PC9vOnA+PC9wPg0K PHA+Jm5ic3A7Jm5ic3A7IGNhc2UsIG1lYXN1cmVzIG11c3QgYmUgdGFrZW4gdG8gcHJldmVudCBk aXNjbG9zdXJlIG9mIHRoaXM8bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOyZuYnNwOyBpbmZvcm1h dGlvbiB0byB1bmludGVuZGVkIHBhcnRpZXMuJnF1b3Q7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0K PHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cD5JdCBzZWVtcyB0byBtZSB0aGF0IHRoaXMgc2hv dWxkIGJlIGEgbm9ybWF0aXZlIE1VU1QsIHBhcnRpY3VsYXJseSBpbiBsaWdodCBvZiB0aGUgZmFj dCB0aGF0IGNsYWltcyBhcmUgYmVpbmcgZGVmaW5lZCB0aGF0IGFyZSBtZWFudCB0byBkaXJlY3Rs eSBpZGVudGlmeSB1c2VycyAoZS5nLiwgc3ViKSBhbmQgb3RoZXIgY2xhaW1zIGRlZmluZWQgaGVy ZSBvciBsYXRlciBjb3VsZCBkbyBzbyBhcyB3ZWxsLjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4g c3R5bGU9ImNvbG9yOiMwMDcwQzAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxz cGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj5UaGVyZSBzZWVtcyB0byBiZSBkZWJhdGUgd2hldGhl ciBhIDIxMTkgbGFuZ3VhZ2Ugc2hvdWxkIGJlIHVzZWQgb3RoZXIgdGhhbiB3aGVuIGRlc2NyaWJp bmcgcHJvdG9jb2wgcmVxdWlyZW1lbnRzLiZuYnNwOyBKaW0gU2NoYWFkICh0aGUgSk9TRSBjaGFp cikgYmVsaWV2ZXMgdGhhdCB0aGV5IHNob3VsZG7igJl0IGFuZCB0aGVzZSBkb2N1bWVudHMgaGF2 ZSBmb2xsb3dlZCB0aGF0IGNvbnZlbnRpb24uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaXRoIG90aGVyIGRvY3VtZW50 cywgdGhlcmUgaXMgUkZDMjExOSBsYW5ndWFnZSB1c2VkIGZvciBzZWN1cml0eSAmYW1wOyBwcml2 YWN5IGNvbnNpZGVyYXRpb25zLiZuYnNwOyBBdCBzb21lIHBvaW50IHRoZXJlIHdhcyBhIHRyZW5k IHRvIGhhdmUgYSBzZXBhcmF0ZSAmcXVvdDtTZWN1cml0eSBSZXF1aXJlbWVudHMmcXVvdDsgc2Vj dGlvbiBmcm9tICZxdW90O1NlY3VyaXR5IENvbnNpZGVyYXRpb25zJnF1b3Q7LCBidXQgSSBkb24n dCB0aGluayB0aGVyZSB3YXMNCiBhbnkgcmVxdWlyZW1lbnQgZm9yIHRoaXMsIGp1c3QgYSBwcmVm ZXJlbmNlLiZuYnNwOyBJIGFncmVlIHRoYXQgdGhpcyBzaG91bGQgYmUgYSBNVVNULCBidXQgd2l0 aCBTdGVwaGVuIGFzIHdlbGwgdGhhdCB5b3Ugc2hvdWxkIGRpc2NvdXJhZ2UgcHV0dGluZyBpbiBw cml2YWN5IHJlbGF0ZWQgaW5mb3JtYXRpb24gdG8gYmVnaW4gd2l0aC48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPGRpdj4NCjxwPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cD4mcXVvdDtPbmUgd2F5IHRvIGFjaGlldmUgdGhpcyBpcyB0 byB1c2U8bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOyZuYnNwOyBhbiBlbmNyeXB0ZWQgSldULiZu YnNwOyBBbm90aGVyIHdheSBpcyB0byBlbnN1cmUgdGhhdCBKV1RzIGNvbnRhaW5pbmc8bzpwPjwv bzpwPjwvcD4NCjxwPiZuYnNwOyZuYnNwOyB1bmVuY3J5cHRlZCBwcml2YWN5LXNlbnNpdGl2ZSBp bmZvcm1hdGlvbiBhcmUgb25seSB0cmFuc21pdHRlZCBvdmVyPG86cD48L286cD48L3A+DQo8cD4m bmJzcDsmbmJzcDsgZW5jcnlwdGVkIGNoYW5uZWxzIG9yIHByb3RvY29scywgc3VjaCBhcyBUTFMu JnF1b3Q7PG86cD48L286cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPlNpbmNl IHNlbnNpdGl2ZSBKV1RzIHNob3VsZCBiZSBwcm90ZWN0ZWQgZnJvbSBib3RoIGludGVybWVkaWFy eSBvYnNlcnZhdGlvbiBhbmQgZnJvbSBiZWluZyBzZW50IHRvIHVuaW50ZW5kZWQgcmVjaXBpZW50 cywgSSB3b3VsZDxvOnA+PC9vOnA+PC9wPg0KPHA+c3VnZ2VzdDo8bzpwPjwvbzpwPjwvcD4NCjxw PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+T25lIHdheSB0byBhY2hpZXZlIHRoaXMgaXMgdG8g dXNlIGFuIGVuY3J5cHRlZCBKV1QgYW5kIGF1dGhlbnRpY2F0ZSB0aGUgcmVjaXBpZW50LiBBbm90 aGVyIHdheSBpcyB0byBlbnN1cmUgdGhhdCBKV1RzIGNvbnRhaW5pbmcgdW5lbmNyeXB0ZWQgcHJp dmFjeS1zZW5zaXRpdmUgaW5mb3JtYXRpb24gYXJlIG9ubHkgdHJhbnNtaXR0ZWQgb3ZlciBlbmNy eXB0ZWQgY2hhbm5lbHMgb3IgcHJvdG9jb2xzIHRoYXQgYWxzbyBzdXBwb3J0IGVuZHBvaW50DQog YXV0aGVudGljYXRpb24sIHN1Y2ggYXMgVExTLjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5 bGU9ImNvbG9yOiMwMDcwQzAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFu IHN0eWxlPSJjb2xvcjojMDA3MEMwIj5UaGFua3MgZm9yIHRoaXMgc3VnZ2VzdGVkIGxhbmd1YWdl LiZuYnNwOyBXZSBjYW4gaW5jb3Jwb3JhdGUgc29tZXRoaW5nIGxpa2UgdGhhdC48L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk9LLCB0aGlzIG1ha2VzIHNlbnNlIGFuZCB3aWxsIGZlZWQgaW50byBQ ZXRlJ3MgZGlzY3VzcyBvbiB3aGVyZSBUTFMgc2hvdWxkIGJlIHJlcXVpcmVkLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MhJm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6IzAw NzBDMCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyIGNsZWFyPSJh bGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tIDxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkthdGhsZWVuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_4E1F6AAD24975D4BA5B16804296739439BB2628ATK5EX14MBXC286r_-- From nobody Sat Oct 25 05:10:42 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC0C61A880E; Sat, 25 Oct 2014 05:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 uYXSpJ-KLSR0; Sat, 25 Oct 2014 05:10:21 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.29.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 DBAA81A8820; Sat, 25 Oct 2014 05:10:19 -0700 (PDT) Received: from [80.187.101.65] (helo=[10.23.70.159]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1Xi0Ae-0002ZE-1i; Sat, 25 Oct 2014 14:10:16 +0200 Date: Sat, 25 Oct 2014 14:10:05 +0200 Message-ID: <04y4xbbrisylnwtku1y08n9a.1414239005858@email.android.com> Importance: normal From: Torsten Lodderstedt To: Nat Sakimura , John Bradley MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.android.email_660276537683240" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/m0TY8j_MJnGvjbLoAeOKu9SkYI0 Cc: "draft-ietf-oauth-json-web-token@tools.ietf.org" , "oauth-chairs@tools.ietf.org" , The IESG , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Oct 2014 12:10:27 -0000 ----_com.android.email_660276537683240 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 KzEKCkRlbGVnYXRpbmcgc2VjdXJpdHkgdG8gdGhlIHRyYW5zcG9ydCBsYXllciBpcyBhIGNvbW1v biBwYXR0ZXJuLiAiTm9uZSIgc2hvdWxkIGJlIE1USSBvdGhlcndpc2UgSSBleHBlY3QgYSBsb3Qg b2YgaW50ZXJvcCBpc3N1ZXMuCgo8ZGl2Pi0tLS0tLS0tIFVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNo dCAtLS0tLS0tLTwvZGl2PjxkaXY+Vm9uOiBOYXQgU2FraW11cmEgPHNha2ltdXJhQGdtYWlsLmNv bT4gPC9kaXY+PGRpdj5EYXR1bToyMy4xMC4yMDE0ICAxMDo1OCAgKEdNVCswMTowMCkgPC9kaXY+ PGRpdj5BbjogSm9obiBCcmFkbGV5IDx2ZTdqdGJAdmU3anRiLmNvbT4gPC9kaXY+PGRpdj5DYzog VGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+LCBvYXV0aEBpZXRmLm9yZywgb2F1dGgtY2hhaXJzQHRv b2xzLmlldGYub3JnLCBkcmFmdC1pZXRmLW9hdXRoLWpzb24td2ViLXRva2VuQHRvb2xzLmlldGYu b3JnIDwvZGl2PjxkaXY+QmV0cmVmZjogUmU6IFtPQVVUSC1XR10gU3RlcGhlbiBGYXJyZWxsJ3Mg RGlzY3VzcyBvbiBkcmFmdC1pZXRmLW9hdXRoLWpzb24td2ViLXRva2VuLTI3OiAod2l0aCBESVND VVNTIGFuZCBDT01NRU5UKSA8L2Rpdj48ZGl2Pgo8L2Rpdj5JIHNlY29uZCBKb2huJ3MgbWVzc2Fn ZS4gVGhlcmUgYXJlIG1hbnkgd2F5cyB0byBhY2hpZXZlIGEgZGVzaXJlZCBsZXZlbCBvZiBzZWN1 cml0eSBhbmQgb25lIG9mIHRoZSBtb3N0IHBvcHVsYXIgd2F5IGlzIHRvIGRlbGVnYXRlIGl0IHRv IHRoZSB0cmFuc3BvcnQgbGF5ZXIgYW5kIHVzZSAnbm9uZScgYXMgdGhlIGFsZy4gSWYgJ25vbmUn IGJlY29tZXMgbm9uLU1USSwgdGhlbiBpdCBtYXkgY2F1c2UgYSBsb3Qgb2YgaW50ZXJvcGVyYWJp bGl0eSBpc3N1ZXMgZG93biB0aGUgcm9hZC4gCgpBZGRpbmcgdG8gaXQsIEpXVCBjYW4gYmUgdXNl ZnVsIGluIG90aGVyIGNvbnRleHQgdGhhbiBzZWN1cml0eSBhcyB3ZWxsLiBBcyBpbnRlcm9wZXJh YmlsaXR5IGlzIG9uZSBvZiB0aGUgbW9zdCBpbXBvcnRhbnQgY3JpdGVyaWEsIGhhdmluZyAnbm9u ZScgYXMgTVRJIHNlZW1zIHRvIGJlIGEgcmVhc29uYWJsZSBpZGVhIHRvIG1lLiAKCk5hdAoKMjAx NC0xMC0yMiAxNjo0NCBHTVQtMDU6MDAgSm9obiBCcmFkbGV5IDx2ZTdqdGJAdmU3anRiLmNvbT46 CkZyb20gYSBKV1QgcGVyc3BlY3RpdmUgYSBudW1iZXIgb2YgYXBwbGljYXRpb25zIGluY2x1ZGlu ZyBjb25uZWN0IGFsbG93IHVuc2VjdXJlZCBKV1QuCgpJIGd1ZXNzIHlvdSBhcmUgcmVmZXJyaW5n IHRvIHNlYyA4IG9mIEpXVCBpbiB0aGUgT0F1dGggV0cuICBTb21lIG9mIHRoZSB0aHJlYWRzIHlv dSBtZW50aW9uIHdlcmUgaW4gdGhlIEpPU0UgV0cgcmVsYXRpbmcgdG8gdGhlIEpXUyBzcGVjIGFu ZCBpZiBub25lIHNob3VsZCBiZSBpbmNsdWRlZC4KClRvIHNvbWUgZXh0ZW50IHRoZSBpc3N1ZXMg YXJlIG5vdCBxdWl0ZSB0aGUgc2FtZSBmb3IgdGhlIGRpZmZlcmVudCBzcGVjcy4KClNBTUwgY2Vy dGFpbmx5IGFsbG93cyBmb3IgdW5zaWduZWQgZG9jdW1lbnRzLCB0aG9zZSBhcmUgdXNlZCBpbiBh IGxvdCBvZiBwbGFjZXMuICBJIGltYWdpbmUgdGhhdCBhIFNBTUwgbGlicmFyeSB0aGF0IGNvdWxk IG5vdCBwcm9jZXNzIHVuc2lnbmVkIG1lc3NhZ2VzIHdvdWxkIGdlbmVyYWxseSBiZSBjb25zaWRl cmVkIGJyb2tlbi4KVGhhdCBpcyBub3QgdG8gc2F5IHRoYXQgaXQgYWxzbyBuZWVkcyB0byBhbHNv IHN1cHBvcnQgc2lnbmVkIG9uZXMgYW5kIHNvbWUgbnVtYmVyIG9mIHRydXN0IG1vZGVscy4gIAoK SXQgaXMgdGhlIHNhbWUgZm9yIEpXVCBhcyBpdCBsaXZlcyBhdCBhIHNpbWlsYXIgY29uY2VwdHVh bCBsZXZlbCB0byBTQU1MIGFzc2VydGlvbnMuIAoKSXQgaXMgYmV0dGVyIGZvciBpbnRlcm9wZXJh YmlsaXR5IHRvIGhhdmUgYWxsIHRoZSBKV1QgbGlicyBpbXBsZW1lbnQgIm5vbmUiLCBzbyB0aGF0 IGl0IGNhbiBiZSBzdXBwb3J0ZWQgaW4gdGhlIG1hbnkgY2FzZXMgaXQgbWF5IGJlIHVzZWQgZm9y IHByb2Nlc3NpbmcgSldUIHByb3RlY3RlZCBieSB0cmFuc3BvcnQgb3Igc29tZSBvdGhlciBtZWNo YW5pc20sIGFuZCByZWxpYWJseSByZWplY3QgIm5vbmUiIHdoZW4gc2lnbmF0dXJlcyBhcmUgcmVx dWlyZWQuCgpUaGUgSldUIHNwZWMgaXMgbm90IHJlcXVpcmluZyBKV1Mgb3IgSldFIHRvIGltcGxl bWVudCBzdXBwb3J0IGZvciBub25lLCAgdGhvdWdoIGxpa2VseSBsaWZlIHdvdWxkIGJlIGVhc2ll ciBpZiB0aGV5IGRpZCBzdXBwb3J0IGl0LgoKSm9obiBCLgoKCgpPbiBPY3QgMjEsIDIwMTQsIGF0 IDE6MzYgUE0sIEthdGhsZWVuIE1vcmlhcnR5IDxrYXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdtYWls LmNvbT4gd3JvdGU6CgoKCk9uIFR1ZSwgT2N0IDIxLCAyMDE0IGF0IDk6MTYgQU0sIFN0ZXBoZW4g RmFycmVsbCA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT4gd3JvdGU6CgpIaSBNaWtlLAoKSSd2 ZSBvbmUgcmVtYWluaW5nIGRpc2N1c3MgcG9pbnQgYW5kIGEgY29tbWVudC4gU2VlIGJlbG93Li4u CgpPbiAxNC8xMC8xNCAxMzo1MCwgTWlrZSBKb25lcyB3cm90ZToKPiBUaGUgcHJvcG9zZWQgcmVz b2x1dGlvbnMgYmVsb3cgaGF2ZSBiZWVuIGluY2x1ZGVkIGluIHRoZSAtMjggZHJhZnQuICBIb3Bl ZnVsbHkgeW91J2xsIGJlIGFibGUgdG8gY2xlYXIgeW91ciBESVNDVVNTZXMgb24gdGhhdCBiYXNp cy4KPgo+IFRoZSBTdHJpbmcgQ29tcGFyaXNvbiBSdWxlcyBpbiBTZWN0aW9uIDcuMyBoYXZlIGJl ZW4gZXhwYW5kZWQgdG8gdGFsayBhYm91dCB3aGVuIHRoZSBhcHBsaWNhdGlvbiBtYXkgbmVlZCBj YW5vbmljYWxpemF0aW9uIHJ1bGVzLgo+Cj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg VGhhbmtzIGFnYWluLAo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UKPgo+ PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQo+PiBGcm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRo LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNaWtlIEpvbmVzCj4+IFNlbnQ6IE1vbmRh eSwgT2N0b2JlciAwNiwgMjAxNCA3OjIwIFBNCj4+IFRvOiBTdGVwaGVuIEZhcnJlbGw7IFRoZSBJ RVNHCj4+IENjOiBvYXV0aC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc7IGRyYWZ0LWlldGYtb2F1dGgt anNvbi13ZWItCj4+IHRva2VuQHRvb2xzLmlldGYub3JnOyBvYXV0aEBpZXRmLm9yZwo+PiBTdWJq ZWN0OiBSZTogW09BVVRILVdHXSBTdGVwaGVuIEZhcnJlbGwncyBEaXNjdXNzIG9uIGRyYWZ0LWll dGYtb2F1dGgtanNvbi0KPj4gd2ViLXRva2VuLTI3OiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5U KQo+Pgo+PiBUaGFua3MgZm9yIHRyYWNraW5nIGFsbCBvZiB0aGlzIFN0ZXBoZW4uICBSZXNwb25z ZXMgaW5saW5lIGJlbG93Li4uCj4+Cj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQo+Pj4g RnJvbTogU3RlcGhlbiBGYXJyZWxsIFttYWlsdG86c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZV0K Pj4+IFNlbnQ6IE1vbmRheSwgT2N0b2JlciAwNiwgMjAxNCAyOjQzIFBNCj4+PiBUbzogTWlrZSBK b25lczsgVGhlIElFU0cKPj4+IENjOiBvYXV0aC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc7IGRyYWZ0 LWlldGYtb2F1dGgtanNvbi13ZWItCj4+PiB0b2tlbkB0b29scy5pZXRmLm9yZzsgb2F1dGhAaWV0 Zi5vcmcKPj4+IFN1YmplY3Q6IFJlOiBTdGVwaGVuIEZhcnJlbGwncyBEaXNjdXNzIG9uIGRyYWZ0 LWlldGYtb2F1dGgtanNvbi13ZWItdG9rZW4tMjc6Cj4+PiAod2l0aCBESVNDVVNTIGFuZCBDT01N RU5UKQo+Pj4KPj4+Cj4+PiBIaSBNaWtlLAo+Pj4KPj4+IE9uIDA2LzEwLzE0IDA4OjU0LCBNaWtl IEpvbmVzIHdyb3RlOgo+Pj4+IFRoYW5rcyBmb3IgeW91ciByZXZpZXcsIFN0ZXBoZW4uICBJJ3Zl IGFkZGVkIHRoZSB3b3JraW5nIGdyb3VwIHRvCj4+Pj4gdGhlIHRocmVhZCBzbyB0aGV5J3JlIGF3 YXJlIG9mIHlvdXIgY29tbWVudHMuCj4+Pj4KPj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0gRnJvbTogU3RlcGhlbiBGYXJyZWxsCj4+Pj4+IFttYWlsdG86c3RlcGhlbi5mYXJyZWxsQGNz LnRjZC5pZV0gU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMDIsIDIwMTQKPj4+Pj4gNTowMyBBTSBU bzogVGhlIElFU0cgQ2M6IG9hdXRoLWNoYWlyc0B0b29scy5pZXRmLm9yZzsKPj4+Pj4gZHJhZnQt aWV0Zi1vYXV0aC1qc29uLXdlYi0gdG9rZW5AdG9vbHMuaWV0Zi5vcmcgU3ViamVjdDogU3RlcGhl bgo+Pj4+PiBGYXJyZWxsJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLW9hdXRoLWpzb24td2ViLXRv a2VuLTI3OiAod2l0aAo+Pj4+PiBESVNDVVNTIGFuZCBDT01NRU5UKQo+Pj4+Pgo+Pj4+PiBTdGVw aGVuIEZhcnJlbGwgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9y Cj4+Pj4+IGRyYWZ0LWlldGYtb2F1dGgtanNvbi13ZWItdG9rZW4tMjc6IERpc2N1c3MKPj4+Pj4K Pj4+Pj4gV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFj dCBhbmQgcmVwbHkgdG8KPj4+Pj4gYWxsIGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUg VG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvCj4+Pj4+IGN1dCB0aGlzIGludHJvZHVjdG9y eSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQo+Pj4+Pgo+Pj4+Pgo+Pj4+PiBQbGVhc2UgcmVmZXIgdG8K Pj4+Pj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlh Lmh0bWwgZm9yIG1vcmUKPj4+Pj4gaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBD T01NRU5UIHBvc2l0aW9ucy4KPj4+Pj4KPj4+Pj4KPj4+Pj4gVGhlIGRvY3VtZW50LCBhbG9uZyB3 aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZAo+Pj4+PiBoZXJlOgo+Pj4+ PiBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtb2F1dGgtanNvbi13 ZWItdG9rZW4vCj4+Pj4+Cj4+Pj4+Cj4+Pj4+Cj4+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPj4+Pj4gLS0KPj4+ Pj4gLQo+Pj4+Pgo+Pj4+Pgo+Pj4gRElTQ1VTUzoKPj4+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+Pj4+PiAtLQo+ Pj4+PiAtCj4+Pj4+Cj4+Pj4+Cj4+Pj4+Cj4+Pj4+Cj4+PiAoMSkgNC4xLjEgYW5kIGVsc2V3aGVy ZSB5b3Ugc2F5IGNhc2Utc2Vuc2l0aXZlOiB0aGUgc2FtZSB0aGluZyBJCj4+PiByYWlzZWQgd3J0 IEROUwo+Pj4+PiBuYW1lcyBmb3IgYW5vdGhlciBKT1NFIHNwZWMgLSBkbyB5b3UgbmVlZCB0byBz YXkgdGhvc2UgU0hPVUxEIGJlCj4+Pj4+IFt1cHBlcnxsb3dlcl1jYXNlZCB3aGVuIHVzZWQgaW4g dGhlc2U/Cj4+Pj4KPj4+PiBJIGJlbGlldmUgdGhhdCBzb21ld2hlcmUgd2Ugc2hvdWxkIHNheSB0 aGF0IGlmIGNhc2UtaW5zZW5zaXRpdmUKPj4+PiB2YWx1ZXMsIHN1Y2ggYXMgRE5TIG5hbWVzLCBh cmUgdXNlZCB3aGVuIGNvbnN0cnVjdGluZyAia2lkIiB2YWx1ZXMsCj4+Pj4gdGhhdCB0aGUgYXBw bGljYXRpb24gZG9pbmcgc28gbmVlZHMgdG8gZGVmaW5lIGEgY29udmVudGlvbiBvbiB0aGUKPj4+ PiBjYW5vbmljYWwgY2FzZSB0byB1c2UgZm9yIHRoZSBjYXNlLWluc2Vuc2l0aXZlIHBvcnRpb25z LCBzdWNoIGFzCj4+Pj4gbG93ZXJjYXNpbmcgdGhlbS4KPj4+Cj4+PiBBcyB0aGF0IGRpc2N1c3Np b24ncyBoYXBwZW5pbmcgb24gdGhlIGtleSBkcmFmdCwgSSdsbCBjbGVhciBpdCBoZXJlCj4+PiBh bmQgdHJ1c3QgeW91IHRvIGZpeCBpZiBhIGNoYW5nZSBpcyB0aGUgZW5kIHJlc3VsdC4KPj4KPj4g VGhhbmtzCgpucAoKPj4KPj4+Pj4gKDIpIFNlY3Rpb24gODogV2h5IGlzICJub25lIiBNVEk/IFRo YXQgc2VlbXMgYm90aCBicm9rZW4gYW5kIGdvaW5nCj4+Pj4+IGluIHRoZSBvcHBvc3RpdGUgZGly ZWN0aW9uIGZyb20gb3RoZXIgV0dzIGFuZCBzbyBzaG91bGQgYmUKPj4+Pj4gZXhwbGljaXRseSBq dXNpZmllZCBJIHRoaW5rLiAoSWYgYSBnb29kIGVub3VnaCBqdXN0aWZpY2F0aW9uIGV4aXN0cwo+ Pj4+PiB0aGF0IGlzLikKPj4+Pgo+Pj4+IEl0IGlzIE1USSBiZWNhdXNlIHRoZXJlIGFyZSBzZXZl cmFsIGV4aXN0aW5nIGFwcGxpY2F0aW9ucyBvZiBKV1RzIGluCj4+Pj4gd2hpY2ggYm90aCB1bnNp Z25lZCBhbmQgc2lnbmVkIHJlcHJlc2VudGF0aW9ucyBvZiB0aGUgSldUcyBhcmUKPj4+PiByZXF1 aXJlbWVudHMuICBUaGVzZSBpbmNsdWRlIGRyYWZ0LWlldGYtb2F1dGgtdG9rZW4tZXhjaGFuZ2Us Cj4+Pj4gZHJhZnQtaHVudC1vYXV0aC12Mi11c2VyLWE0YywgYW5kIE9wZW5JRCBDb25uZWN0LiAg VGhpcyBpcyBhIHByZXR0eQo+Pj4+IGNvbW1vbiBwYXR0ZXJuIHdoZXJlIHlvdSBzaWduIHNvbWV0 aGluZyBpZiB0aGUgcmVjaXBpZW50IGNhcmVzIHdobwo+Pj4+IG1hZGUgdGhlIHN0YXRlbWVudHMg YW5kIHdoZXJlIHlvdSBkb24ndCBoYXZlIHRvIHNpZ24gaXQgZWl0aGVyIGlmCj4+Pj4gdGhlIHJl Y2lwaWVudCBkb2Vzbid0IGNhcmUgd2hvIG1hZGUgdGhlIHN0YXRlbWVudHMKPj4+Cj4+PiBJIGRv bid0IHNlZSBob3cgKG5vbi0pc2lnbmVycyBjYW4gZGl2aW5lIG5vbi12ZXJpZmllcidzIHdpc2hl cyB0aGF0Cj4+PiB3YXkuIChBYnNlbnQgbmVnb3RpYXRpb24gb3IgYSBkaXJlY3RvcnkuKQo+Pgo+ PiBTb21ldGltZXMgaXQgZG9lcyBvY2N1ciB2aWEgbmVnb3RpYXRpb24uICBGb3IgaW5zdGFuY2Us IGluIHNvbWUgcHJvdG9jb2xzLCBhdAo+PiByZWdpc3RyYXRpb24gdGltZSwgcmVseWluZyBwYXJ0 aWVzIGV4cGxpY2l0bHkgdGVsbCBpZGVudGl0eSBwcm92aWRlcnMgd2hhdCBhbGdvcml0aG1zCj4+ IGFyZSBhY2NlcHRhYmxlIHRvIHRoZW0sIHdoaWNoIG1heSBpbmNsdWRlICJub25lIi4gIE5vIGRp dmluYXRpb24gLSBleHBsaWNpdAo+PiBjb21tdW5pY2F0aW9uLgo+Pgo+Pj4+IG9yIGlmIGl0IGNh biB0ZWxsIGZyb20KPj4+PiBhbm90aGVyIHNlY3VyZWQgYXNwZWN0IG9mIHRoZSBhcHBsaWNhdGlv biBwcm90b2NvbCAodHlwaWNhbGx5Cj4+Pj4gdGhyb3VnaCB0aGUgdXNlIG9mIFRMUykgd2hvIG1h ZGUgdGhlIHN0YXRlbWVudHMuICBJbiB0aGUgVExTIGNhc2UsCj4+Pj4gdGhlIHNlcnZlciBhdXRo ZW50aWNhdGlvbiBzdGVwIG1ha2VzIGEgc2lnbmF0dXJlIHN0ZXAgdW5uZWNlc3NhcnksCj4+Pj4g c28gYW4gVW5zZWN1cmVkIEpXVCBpcyBmaW5lIHRoZXJlLgo+Pj4KPj4+IFRoYXQncyBhcmd1YWJs ZSBJTU8uCj4+Cj4+IEkgYWdyZWUgdGhhdCBpdCdzIGFwcGxpY2F0aW9uIGFuZCBjb250ZXh0LWRl cGVuZGVudCB3aGV0aGVyIGl0J3MgT0sgb3Igbm90LiAgVGhlCj4+IHBvaW50IGlzIHRoYXQgdGhl cmUgZXhpc3Qgc29tZSBjaXJjdW1zdGFuY2VzIGluIHdoaWNoIGl0IGlzIE9LLCBhbmQgdGhpcyBm ZWF0dXJlIGlzCj4+IGJlaW5nIHVzZWQgaW4gc29tZSBvZiB0aG9zZSBjYXNlcy4KPj4KPj4+IEkg dGhpbmsgSSdsbCBsb29rIGJhY2sgb3ZlciB0aGUgd2cgdGhyZWFkIGFuZCBlaXRoZXIgaG9sZCBt eSBub3NlIG9yCj4+Cj4+IFRoaXMgaXNzdWUgd2FzIHRyYWNrZWQgYXMgaHR0cDovL3RyYWMudG9v bHMuaWV0Zi5vcmcvd2cvam9zZS90cmFjL3RpY2tldC8zNi4KPj4gS2FyZW4gTydEb25vZ2h1ZSBy ZWNvcmRlZCB0aGlzIGNvbmNsdXNpb24gaW4gdGhlIHRyYWNrZXIgIk5vdGU6IFRoZXJlIHdhcwo+ PiBleHRlbnNpdmUgZGlzY3Vzc2lvbiBvbiB0aGUgbWFpbGluZyBsaXN0LCBhbmQgdGhlIHJvdWdo ICBjb25zZW5zdXMgb2YgdGhlIHdvcmtpbmcKPj4gZ3JvdXAgd2FzIHRvIGxlYXZlICJub25lIiBp biB0aGUgZG9jdW1lbnQuIgo+Pgo+PiBEaXNjdXNzaW9uIHRocmVhZHMgb24gdGhpcyB0b3BpYyBp bmNsdWRlOgo+PiBbam9zZV0gIzM2OiBBbGdvcml0aG0gIm5vbmUiIHNob3VsZCBiZSByZW1vdmVk IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC0KPj4gYXJjaGl2ZS93ZWIvam9zZS9jdXJyZW50L21z ZzAyOTExLmh0bWwgLSBCZWdhbiBKdWwgMzEsIDIwMTMgICg5MSBtZXNzYWdlcykKPj4gW2pvc2Vd IFRleHQgYWJvdXQgYXBwbGljYXRpb25zIGFuZCAiYWxnIjoibm9uZSIgaHR0cDovL3d3dy5pZXRm Lm9yZy9tYWlsLQo+PiBhcmNoaXZlL3dlYi9qb3NlL2N1cnJlbnQvbXNnMDMzMjEuaHRtbCAtIEJl Z2FuIFNlcCAzLCAyMDEzICg1IG1lc3NhZ2VzKQo+Pgo+PiBUaGlzIGlzc3VlIHdhcyBhIHRvcGlj IG9mIGEgc3BlY2lhbCB3b3JraW5nIGdyb3VwIGNhbGwgb24gQXVnIDE5LCAyMDEzLiAgVGhlIHRl eHQKPj4gZGlzY3Vzc2VkIGluIHRoZSBsYXN0IHRocmVhZCBhbmQgcHVibGlzaGVkIGF0IGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC0KPj4gaWV0Zi1qb3NlLWpzb24td2ViLWFsZ29y aXRobXMtMzMjc2VjdGlvbi04LjUgKFVuc2VjdXJlZCBKV1MgU2VjdXJpdHkKPj4gQ29uc2lkZXJh dGlvbnMpIHdhcyB0aGUgcmVzdWx0IG9mIHRoZSB3b3JraW5nIGdyb3VwJ3MgZGVjaXNpb25zIHJl c3VsdGluZyBmcm9tIGFsbAo+PiBvZiB0aGlzIGRpc2N1c3Npb24uCgpUaGFua3MgZm9yIGFsbCB0 aGUgcG9pbnRlcnMgYWJvdmUuIEkgcmVhZCB0aHJvdWdoIGFsbCB0aGUgKG1hbnkhKQpBdWcgMTkg bWFpbHMgYW5kIG1vc3Qgb2YgdGhlIGAibm9uZSIgc2hvdWxkIGJlIHJlbW92ZWQiIHRocmVhZC4K ClNvIEkgZG8gc2VlIHRoYXQgdGhlcmUgd2FzIHJvdWdoIGNvbnNlbnN1cyB0byBrZWVwICJub25l IiBpbgp0aGUgZHJhZnQgYW5kIGNhbiAod2l0aCBkaWZmaWN1bHR5Oy0pIGhvbGQgbXkgbm9zZSBh bmQgbGV0IHRoYXQKcGFzcy4gSSBkbyBub3QgaG93ZXZlciwgc2VlIHRoYXQgdGhlcmUgd2FzIGNv bnNlbnN1cyB0byBtYWtlCiJub25lIiBNVEkgZm9yIHRoaXMgZHJhZnQuIEkgZGlkIHNlZSBhIGJp dCBvZiBoYWdnbGluZyBhYm91dAp0aGlzIGRyYWZ0IHZzLiBKV1MgYnV0IHN0aWxsIGRvIG5vdCBz ZWUgd2h5IG5vbmUgb3VnaHQgYmUgTVRJCmhlcmUuCgo+Pgo+Pj4+PiAoMykgU2VjdGlvbiAxMjog YW5vdGhlciB3YXkgdG8gaGFuZGxlIHByaXZhY3kgaXMgdG8gbm90IGluY2x1ZGUKPj4+Pj4gc2Vu c2l0aXZlIGRhdGEgLSBJIHRoaW5rIHlvdSBvdWdodCBtZW50aW9uIHRoYXQgYXMgYSBiaXQgb2Yg dGhvdWdodAo+Pj4+PiBhbG9uZyB0aG9zZSBsaW5lcyBjYW4gYmUgbXVjaCBzaW1wbGVyIHRoYW4g cHV0dGluZyBpbiBwbGFjZSB0aGUga2V5Cj4+Pj4+IG1hbmFnZW1lbnQgdG8gaGFuZGxlIHRob3Vn aHRsZXNzbHkgaW5jbHVkZWQgUElJLgo+Pj4+Cj4+Pj4gV2UgY2FuIGluY2x1ZGUgYSBkaXNjdXNz aW9uIG9mIHRoYXQgcG9pbnQsCj4+Pgo+Pj4gR3JlYXQuICJKdXN0IHNheSBubyIgaXMgd29ya2Fi bGUgaGVyZTotKSBJJ2xsIGNsZWFyIHdoZW4gd2UgZ2V0IHN1Y2ggdGV4dC4KPj4+Cj4+Pj4gYnV0 IHNvbWV0aW1lcyB0aGUgdmVyeQo+Pj4+IHBvaW50IG9mIGEgSldUIGlzIHRvIHNlY3VyZWx5IGRl bGl2ZXIgUElJIGZyb20gYSB2ZXJpZmlhYmxlIHBhcnR5IHRvCj4+Pj4gYW4gaW50ZW5kZWQgcGFy dHkgd2l0aCBhcHByb3ByaWF0ZSByaWdodHMgdG8gcmVjZWl2ZSBpdC4KPj4+Cj4+PiBIbW0uIEl0 cyBhIG1vb3QgcG9pbnQgKHNvIGxldCdzIG5vdCBhcmd1ZSBpdCkgYnV0IEkgd29uZGVyIGhvdyBv ZnRlbgo+Pj4gUElJIGlzIHJlYWxseSBuZWVkZWQgZm9yIGF1dGhvcml6YXRpb24gd2l0aCBvYXV0 aC4gTXkgZ3Vlc3Mgd291bGQgYmUKPj4+IHRoYXQgaXRzIG5lZWRlZCBmYXIgbGVzcyBvZnRlbiB0 aGFuIGl0cyBmb3VuZCB0byBiZSBwcm9maXRhYmxlCj4+PiBwZXJoYXBzLCBvciB0aGF0IGNhcmVs ZXNzbmVzcyBwbGF5cyBhIGJpZyByb2xlIGluIHVzaW5nIFBJSSBmb3Igc3VjaCBwdXJwb3Nlcy4K CkkndmUgY2xlYXJlZCBvbiB0aGlzIGFzIHlvdSBhZGRlZCB0aGlzIHRleHQ6CgogICJPZiBjb3Vy c2UsIGluY2x1ZGluZwogICBvbmx5IG5lY2Vzc2FyeSBwcml2YWN5LXNlbnNpdGl2ZSBpbmZvcm1h dGlvbiBpbiBhIEpXVCBpcyB0aGUgbW9zdAogICBiYXNpYyBtZWFucyBvZiBtaW5pbWl6aW5nIGFu eSBwb3RlbnRpYWwgcHJpdmFjeSBpc3N1ZXMuIgoKVGhhdCBzZWVtcyB0byBtZSBsaWtlIGEgZmFp cmx5IG9mZnB1dHRpbmcgd2F5IHRvIHBocmFzZSBpdC4gSSdkCnN1Z2dlc3QgaW5zdGVhZDoKCiAg Ik9taXR0aW5nIHByaXZhY3ktc2Vuc2l0aXZlIGluZm9ybWF0aW9uIGZyb20gYSBKV1QgaXMgdGhl CiAgc2ltcGxlc3Qgd2F5IG9mIG1pbmltaXppbmcgcHJpdmFjeSBpc3N1ZXMuIgoKSSBsaWtlIHRo aXMgd29yZGluZyBzdWdnZXN0aW9uLCB0aGFua3MuCiAKCkNoZWVycywKUy4KClBTOiBJIGRpZG4n dCBjaGVjayB0aGUgY29tbWVudHMuCgo+Pj4KPj4+IFMuCj4+Pgo+Pj4KPj4+Cj4+Pj4KPj4+Pj4g LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQo+Pj4+PiAtLQo+Pj4+PiAtCj4+Pj4+Cj4+Pj4+Cj4+PiBDT01NRU5UOgo+Pj4+ PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tCj4+Pj4+IC0tCj4+Pj4+IC0KPj4+Pj4KPj4+Pj4KPj4+Pj4KPj4+Pj4KPj4+ IC0gYWJzdHJhY3Q6IDJuZCBzZW50ZW5jZSBpc24ndCBuZWVkZWQgaGVyZSwgaW4gaW50cm8gd291 bGQgYmUgZmluZS4KPj4+Pgo+Pj4+IEkgZG9uJ3Qga25vdyAtIEkgdGhpbmsgaXQncyBhIGJpZyBk ZWFsIHRoYXQgdGhlIGNsYWltcyBjYW4gYmUKPj4+PiBkaWdpdGFsbHkgc2lnbmVkIG9yIE1BQ2Vk IGFuZC9vciBlbmNyeXB0ZWQuICBUaGF0J3MgdGhlIHJlYXNvbiB3ZQo+Pj4+IGhhdmUgSldUcywg cmF0aGVyIHRoYW4ganVzdCBKU09OLgo+Pj4+Cj4+Pj4+IC0gNC4xLjc6IG1heWJlIHdvcnRoIGFk ZGluZyB0aGF0IGp0aStpc3MgYmVpbmcgdW5pcXVlIGVub3VnaCBpcyBub3QKPj4+Pj4gc3VmZmlj aWVudCBhbmQganRpIGFsb25lIGhhcyB0byBtZWV0IHRoYXQgbmVlZC4gSW4gWC41MDkgdGhlCj4+ Pj4+IGlzc3Vlci9zZXJpYWwgaGFzIHRoZSBlcXVpdmFsZW50IHByb3BlcnR5IHNvIHNvbWVvbmUg bWlnaHQgYXNzdW1lCj4+Pj4+IHNlcXVlbnRpYWwganRpIHZhbHVlcyBzdGFydGluZyBhdCAwIGFy ZSBvay4KPj4+Pgo+Pj4+IE1ha2VzIHNlbnNlIHRvIGFkZCBhIHdhcm5pbmcgb2Ygc29tZSBraW5k IGFsb25nIHRoZXNlIGxpbmVzLiAgSQo+Pj4+IHRoaW5rIEkga25vdyB0aGUgcmVhc29ucyB5b3Ug c2F5IHRoYXQsIGJ1dCBjYW4geW91IGV4cGFuZCBvbiB0aGF0Cj4+Pj4gdGhvdWdodCBhIGJpdCBi ZWZvcmUgSSB0YWtlIGEgc3RhYiBvbiB3cml0aW5nIHRoaXMgdXA/ICBGb3IKPj4+PiBpbnN0YW5j ZSwgd2hpbGUgbm9ybWFsbHkgdHJ1ZSwgSSBkb24ndCB0aGluayB5b3VyIG9ic2VydmF0aW9uIGlz Cj4+Pj4gdHJ1ZSBpZiBhIHJlbHlpbmcgcGFydHkgd2lsbCBvbmx5IGFjY2VwdCB0b2tlbnMgZnJv bSBhIHNpbmdsZSBpc3N1ZXIuCj4+Pj4KPj4+Pj4gLSBzZWN0aW9uIDY6IHl1awo+Pj4+Pgo+Pj4+ PiAtIGFnYWluIEkgdGhpbmsgdGhlIHNlY2RpciBjb21tZW50cyBhcmUgYmVpbmcgaGFuZGxlZCBi eSBLYXRobGVlbgo+Pj4+PiBhbmQgdGhlIGF1dGhvcnMuCj4+Pj4KPj4+PiBBZ2FpbiwgdGhpcyBp cyB0aGVyZSBiZWNhdXNlIG11bHRpcGxlIGFwcGxpY2F0aW9ucyBhc2tlZCBmb3IgdGhlCj4+Pj4g YWJpbGl0eSB0byByZXByZXNlbnQgY29udGVudCB0aGF0IGlzIG9wdGlvbmFsbHkgc2lnbmVkLCBz b21ldGltZXMKPj4+PiBzZWN1cmluZyBpdCBhbm90aGVyIHdheSwgc3VjaCBhcyB3aXRoIFRMUy4g IEpXVHMgYXJlIHVzZWQgc3BlY2lmaWMKPj4+PiBhcHBsaWNhdGlvbiBwcm90b2NvbCBjb250ZXh0 cyAtIG5vdCBpbiBpc29sYXRpb24uCj4+Pj4KPj4+PiBUaGFua3MgYWdhaW4sIC0tIE1pa2UKPj4+ Pgo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+PiBP QXV0aCBtYWlsaW5nIGxpc3QKPj4gT0F1dGhAaWV0Zi5vcmcKPj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aAo+CgoKCgotLSAKCkJlc3QgcmVnYXJkcywKS2F0aGxl ZW4KCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpPQXV0 aCBtYWlsaW5nIGxpc3QKT0F1dGhAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9vYXV0aAoKCgoKLS0gCk5hdCBTYWtpbXVyYSAoPW5hdCkKQ2hhaXJtYW4sIE9w ZW5JRCBGb3VuZGF0aW9uCmh0dHA6Ly9uYXQuc2FraW11cmEub3JnLwpAX25hdF9lbg== ----_com.android.email_660276537683240 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+KzE8ZGl2Pjxicj48L2Rpdj48ZGl2 PkRlbGVnYXRpbmcgc2VjdXJpdHkgdG8gdGhlIHRyYW5zcG9ydCBsYXllciBpcyBhIGNvbW1vbiBw YXR0ZXJuLiAiTm9uZSIgc2hvdWxkIGJlIE1USSBvdGhlcndpc2UgSSBleHBlY3QgYSBsb3Qgb2Yg aW50ZXJvcCBpc3N1ZXMuPC9kaXY+PGJyPjxicj48ZGl2Pi0tLS0tLS0tIFVyc3Byw7xuZ2xpY2hl IE5hY2hyaWNodCAtLS0tLS0tLTwvZGl2PjxkaXY+Vm9uOiBOYXQgU2FraW11cmEgPHNha2ltdXJh QGdtYWlsLmNvbT4gPC9kaXY+PGRpdj5EYXR1bToyMy4xMC4yMDE0ICAxMDo1OCAgKEdNVCswMTow MCkgPC9kaXY+PGRpdj5BbjogSm9obiBCcmFkbGV5IDx2ZTdqdGJAdmU3anRiLmNvbT4gPC9kaXY+ PGRpdj5DYzogVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+LCBvYXV0aEBpZXRmLm9yZywgb2F1dGgt Y2hhaXJzQHRvb2xzLmlldGYub3JnLCBkcmFmdC1pZXRmLW9hdXRoLWpzb24td2ViLXRva2VuQHRv b2xzLmlldGYub3JnIDwvZGl2PjxkaXY+QmV0cmVmZjogUmU6IFtPQVVUSC1XR10gU3RlcGhlbiBG YXJyZWxsJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLW9hdXRoLWpzb24td2ViLXRva2VuLTI3OiAo d2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKSA8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2IGRpcj0i bHRyIj5JIHNlY29uZCBKb2huJ3MgbWVzc2FnZS4gVGhlcmUgYXJlIG1hbnkgd2F5cyB0byBhY2hp ZXZlIGEgZGVzaXJlZCBsZXZlbCBvZiBzZWN1cml0eSBhbmQgb25lIG9mIHRoZSBtb3N0IHBvcHVs YXIgd2F5IGlzIHRvIGRlbGVnYXRlIGl0IHRvIHRoZSB0cmFuc3BvcnQgbGF5ZXIgYW5kIHVzZSAn bm9uZScgYXMgdGhlIGFsZy4gSWYgJ25vbmUnIGJlY29tZXMgbm9uLU1USSwgdGhlbiBpdCBtYXkg Y2F1c2UgYSBsb3Qgb2YgaW50ZXJvcGVyYWJpbGl0eSBpc3N1ZXMgZG93biB0aGUgcm9hZC4mbmJz cDs8ZGl2Pjxicj48L2Rpdj48ZGl2PkFkZGluZyB0byBpdCwgSldUIGNhbiBiZSB1c2VmdWwgaW4g b3RoZXIgY29udGV4dCB0aGFuIHNlY3VyaXR5IGFzIHdlbGwuIEFzIGludGVyb3BlcmFiaWxpdHkg aXMgb25lIG9mIHRoZSBtb3N0IGltcG9ydGFudCBjcml0ZXJpYSwgaGF2aW5nICdub25lJyBhcyBN VEkgc2VlbXMgdG8gYmUgYSByZWFzb25hYmxlIGlkZWEgdG8gbWUuJm5ic3A7PC9kaXY+PGRpdj48 YnI+PC9kaXY+PGRpdj5OYXQ8L2Rpdj48L2Rpdj48ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJy PjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4yMDE0LTEwLTIyIDE2OjQ0IEdNVC0wNTowMCBKb2hu IEJyYWRsZXkgPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86dmU3anRiQHZlN2p0 Yi5jb20iIHRhcmdldD0iX2JsYW5rIj52ZTdqdGJAdmU3anRiLmNvbTwvYT4mZ3Q7PC9zcGFuPjo8 YnI+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44 ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+PGRpdiBzdHls ZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPkZyb20gYSBKV1QgcGVyc3BlY3RpdmUgYSBudW1iZXIg b2YgYXBwbGljYXRpb25zIGluY2x1ZGluZyBjb25uZWN0IGFsbG93IHVuc2VjdXJlZCBKV1QuPGRp dj48YnI+PC9kaXY+PGRpdj5JIGd1ZXNzIHlvdSBhcmUgcmVmZXJyaW5nIHRvIHNlYyA4IG9mIEpX VCBpbiB0aGUgT0F1dGggV0cuJm5ic3A7IFNvbWUgb2YgdGhlIHRocmVhZHMgeW91IG1lbnRpb24g d2VyZSBpbiB0aGUgSk9TRSBXRyByZWxhdGluZyB0byB0aGUgSldTIHNwZWMgYW5kIGlmIG5vbmUg c2hvdWxkIGJlIGluY2x1ZGVkLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+VG8gc29tZSBleHRl bnQgdGhlIGlzc3VlcyBhcmUgbm90IHF1aXRlIHRoZSBzYW1lIGZvciB0aGUgZGlmZmVyZW50IHNw ZWNzLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+U0FNTCBjZXJ0YWlubHkgYWxsb3dzIGZvciB1 bnNpZ25lZCBkb2N1bWVudHMsIHRob3NlIGFyZSB1c2VkIGluIGEgbG90IG9mIHBsYWNlcy4mbmJz cDsgSSBpbWFnaW5lIHRoYXQgYSBTQU1MIGxpYnJhcnkgdGhhdCBjb3VsZCBub3QgcHJvY2VzcyB1 bnNpZ25lZCBtZXNzYWdlcyB3b3VsZCBnZW5lcmFsbHkgYmUgY29uc2lkZXJlZCBicm9rZW4uPC9k aXY+PGRpdj5UaGF0IGlzIG5vdCB0byBzYXkgdGhhdCBpdCBhbHNvIG5lZWRzIHRvIGFsc28gc3Vw cG9ydCBzaWduZWQgb25lcyBhbmQgc29tZSBudW1iZXIgb2YgdHJ1c3QgbW9kZWxzLiAmbmJzcDs8 L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pkl0IGlzIHRoZSBzYW1lIGZvciBKV1QgYXMgaXQgbGl2 ZXMgYXQgYSBzaW1pbGFyIGNvbmNlcHR1YWwgbGV2ZWwgdG8gU0FNTCBhc3NlcnRpb25zLiZuYnNw OzwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+SXQgaXMgYmV0dGVyIGZvciBpbnRlcm9wZXJhYmls aXR5IHRvIGhhdmUgYWxsIHRoZSBKV1QgbGlicyBpbXBsZW1lbnQgIm5vbmUiLCBzbyB0aGF0IGl0 IGNhbiBiZSBzdXBwb3J0ZWQgaW4gdGhlIG1hbnkgY2FzZXMgaXQgbWF5IGJlIHVzZWQgZm9yIHBy b2Nlc3NpbmcgSldUIHByb3RlY3RlZCBieSB0cmFuc3BvcnQgb3Igc29tZSBvdGhlciBtZWNoYW5p c20sIGFuZCByZWxpYWJseSByZWplY3QgIm5vbmUiIHdoZW4gc2lnbmF0dXJlcyBhcmUgcmVxdWly ZWQuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5UaGUgSldUIHNwZWMgaXMgbm90IHJlcXVpcmlu ZyBKV1Mgb3IgSldFIHRvIGltcGxlbWVudCBzdXBwb3J0IGZvciBub25lLCAmbmJzcDt0aG91Z2gg bGlrZWx5IGxpZmUgd291bGQgYmUgZWFzaWVyIGlmIHRoZXkgZGlkIHN1cHBvcnQgaXQuPC9kaXY+ PGRpdj48YnI+PC9kaXY+PGRpdj5Kb2huIEIuPC9kaXY+PGRpdj48ZGl2IGNsYXNzPSJoNSI+PGRp dj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PGRpdj48ZGl2Pk9uIE9jdCAyMSwg MjAxNCwgYXQgMTozNiBQTSwgS2F0aGxlZW4gTW9yaWFydHkgJmx0OzxhIGhyZWY9Im1haWx0bzpr YXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmthdGhsZWVu Lm1vcmlhcnR5LmlldGZAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+PGJyPjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiPjxicj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYTtmb250 LXNpemU6MTJweDtmb250LXN0eWxlOm5vcm1hbDtmb250LXZhcmlhbnQ6bm9ybWFsO2ZvbnQtd2Vp Z2h0Om5vcm1hbDtsZXR0ZXItc3BhY2luZzpub3JtYWw7bGluZS1oZWlnaHQ6bm9ybWFsO3RleHQt YWxpZ246c3RhcnQ7dGV4dC1pbmRlbnQ6MHB4O3RleHQtdHJhbnNmb3JtOm5vbmU7d2hpdGUtc3Bh Y2U6bm9ybWFsO3dvcmQtc3BhY2luZzowcHgiPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHls ZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhO2ZvbnQtc2l6ZToxMnB4O2ZvbnQtc3R5bGU6bm9ybWFs O2ZvbnQtdmFyaWFudDpub3JtYWw7Zm9udC13ZWlnaHQ6bm9ybWFsO2xldHRlci1zcGFjaW5nOm5v cm1hbDtsaW5lLWhlaWdodDpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDowcHg7 dGV4dC10cmFuc2Zvcm06bm9uZTt3aGl0ZS1zcGFjZTpub3JtYWw7d29yZC1zcGFjaW5nOjBweCI+ T24gVHVlLCBPY3QgMjEsIDIwMTQgYXQgOToxNiBBTSwgU3RlcGhlbiBGYXJyZWxsPHNwYW4+Jm5i c3A7PC9zcGFuPjxzcGFuIGRpcj0ibHRyIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOnN0ZXBoZW4uZmFy cmVsbEBjcy50Y2QuaWUiIHRhcmdldD0iX2JsYW5rIj5zdGVwaGVuLmZhcnJlbGxAY3MudGNkLmll PC9hPiZndDs8L3NwYW4+PHNwYW4+Jm5ic3A7PC9zcGFuPndyb3RlOjxicj48YmxvY2txdW90ZSBj bGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7Ym9yZGVy LWxlZnQtd2lkdGg6MXB4O2JvcmRlci1sZWZ0LWNvbG9yOnJnYigyMDQsMjA0LDIwNCk7Ym9yZGVy LWxlZnQtc3R5bGU6c29saWQ7cGFkZGluZy1sZWZ0OjFleCI+PGJyPkhpIE1pa2UsPGJyPjxicj5J J3ZlIG9uZSByZW1haW5pbmcgZGlzY3VzcyBwb2ludCBhbmQgYSBjb21tZW50LiBTZWUgYmVsb3cu Li48YnI+PGRpdj48ZGl2Pjxicj5PbiAxNC8xMC8xNCAxMzo1MCwgTWlrZSBKb25lcyB3cm90ZTo8 YnI+Jmd0OyBUaGUgcHJvcG9zZWQgcmVzb2x1dGlvbnMgYmVsb3cgaGF2ZSBiZWVuIGluY2x1ZGVk IGluIHRoZSAtMjggZHJhZnQuJm5ic3A7IEhvcGVmdWxseSB5b3UnbGwgYmUgYWJsZSB0byBjbGVh ciB5b3VyIERJU0NVU1NlcyBvbiB0aGF0IGJhc2lzLjxicj4mZ3Q7PGJyPiZndDsgVGhlIFN0cmlu ZyBDb21wYXJpc29uIFJ1bGVzIGluIFNlY3Rpb24gNy4zIGhhdmUgYmVlbiBleHBhbmRlZCB0byB0 YWxrIGFib3V0IHdoZW4gdGhlIGFwcGxpY2F0aW9uIG1heSBuZWVkIGNhbm9uaWNhbGl6YXRpb24g cnVsZXMuPGJyPiZndDs8YnI+Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO1RoYW5rcyBhZ2Fpbiw8YnI+Jmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOy0tIE1pa2U8YnI+Jmd0Ozxicj4m Z3Q7Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4mZ3Q7Jmd0OyBGcm9tOiBPQXV0 aCBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBNaWtlIEpv bmVzPGJyPiZndDsmZ3Q7IFNlbnQ6IE1vbmRheSwgT2N0b2JlciAwNiwgMjAxNCA3OjIwIFBNPGJy PiZndDsmZ3Q7IFRvOiBTdGVwaGVuIEZhcnJlbGw7IFRoZSBJRVNHPGJyPiZndDsmZ3Q7IENjOjxz cGFuPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86b2F1dGgtY2hhaXJzQHRvb2xzLmlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGgtY2hhaXJzQHRvb2xzLmlldGYub3JnPC9hPjsgZHJh ZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi08YnI+Jmd0OyZndDs8c3Bhbj4mbmJzcDs8L3NwYW4+PGEg aHJlZj0ibWFpbHRvOnRva2VuQHRvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dG9rZW5A dG9vbHMuaWV0Zi5vcmc8L2E+OzxzcGFuPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86b2F1 dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aEBpZXRmLm9yZzwvYT48YnI+Jmd0OyZn dDsgU3ViamVjdDogUmU6IFtPQVVUSC1XR10gU3RlcGhlbiBGYXJyZWxsJ3MgRGlzY3VzcyBvbiBk cmFmdC1pZXRmLW9hdXRoLWpzb24tPGJyPiZndDsmZ3Q7IHdlYi10b2tlbi0yNzogKHdpdGggRElT Q1VTUyBhbmQgQ09NTUVOVCk8YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDsgVGhhbmtzIGZvciB0cmFj a2luZyBhbGwgb2YgdGhpcyBTdGVwaGVuLiZuYnNwOyBSZXNwb25zZXMgaW5saW5lIGJlbG93Li4u PGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxi cj4mZ3Q7Jmd0OyZndDsgRnJvbTogU3RlcGhlbiBGYXJyZWxsIFttYWlsdG86PGEgaHJlZj0ibWFp bHRvOnN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWUiIHRhcmdldD0iX2JsYW5rIj5zdGVwaGVuLmZh cnJlbGxAY3MudGNkLmllPC9hPl08YnI+Jmd0OyZndDsmZ3Q7IFNlbnQ6IE1vbmRheSwgT2N0b2Jl ciAwNiwgMjAxNCAyOjQzIFBNPGJyPiZndDsmZ3Q7Jmd0OyBUbzogTWlrZSBKb25lczsgVGhlIElF U0c8YnI+Jmd0OyZndDsmZ3Q7IENjOjxzcGFuPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86 b2F1dGgtY2hhaXJzQHRvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGgtY2hhaXJz QHRvb2xzLmlldGYub3JnPC9hPjsgZHJhZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi08YnI+Jmd0OyZn dDsmZ3Q7PHNwYW4+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzp0b2tlbkB0b29scy5pZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRva2VuQHRvb2xzLmlldGYub3JnPC9hPjs8c3Bhbj4mbmJz cDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ b2F1dGhAaWV0Zi5vcmc8L2E+PGJyPiZndDsmZ3Q7Jmd0OyBTdWJqZWN0OiBSZTogU3RlcGhlbiBG YXJyZWxsJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLW9hdXRoLWpzb24td2ViLXRva2VuLTI3Ojxi cj4mZ3Q7Jmd0OyZndDsgKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCk8YnI+Jmd0OyZndDsmZ3Q7 PGJyPiZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsgSGkgTWlrZSw8YnI+Jmd0OyZndDsmZ3Q7 PGJyPiZndDsmZ3Q7Jmd0OyBPbiAwNi8xMC8xNCAwODo1NCwgTWlrZSBKb25lcyB3cm90ZTo8YnI+ Jmd0OyZndDsmZ3Q7Jmd0OyBUaGFua3MgZm9yIHlvdXIgcmV2aWV3LCBTdGVwaGVuLiZuYnNwOyBJ J3ZlIGFkZGVkIHRoZSB3b3JraW5nIGdyb3VwIHRvPGJyPiZndDsmZ3Q7Jmd0OyZndDsgdGhlIHRo cmVhZCBzbyB0aGV5J3JlIGF3YXJlIG9mIHlvdXIgY29tbWVudHMuPGJyPiZndDsmZ3Q7Jmd0OyZn dDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gRnJv bTogU3RlcGhlbiBGYXJyZWxsPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFttYWlsdG86PGEgaHJl Zj0ibWFpbHRvOnN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWUiIHRhcmdldD0iX2JsYW5rIj5zdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllPC9hPl0gU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMDIsIDIw MTQ8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgNTowMyBBTSBUbzogVGhlIElFU0cgQ2M6PHNwYW4+ Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpvYXV0aC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5vYXV0aC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc8L2E+Ozxicj4mZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBkcmFmdC1pZXRmLW9hdXRoLWpzb24td2ViLTxzcGFuPiZuYnNwOzwv c3Bhbj48YSBocmVmPSJtYWlsdG86dG9rZW5AdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij50b2tlbkB0b29scy5pZXRmLm9yZzwvYT48c3Bhbj4mbmJzcDs8L3NwYW4+U3ViamVjdDogU3Rl cGhlbjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBGYXJyZWxsJ3MgRGlzY3VzcyBvbiBkcmFmdC1p ZXRmLW9hdXRoLWpzb24td2ViLXRva2VuLTI3OiAod2l0aDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBESVNDVVNTIGFuZCBDT01NRU5UKTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBTdGVwaGVuIEZhcnJlbGwgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBi YWxsb3QgcG9zaXRpb24gZm9yPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGRyYWZ0LWlldGYtb2F1 dGgtanNvbi13ZWItdG9rZW4tMjc6IERpc2N1c3M8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+ Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3Vi amVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG88YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYWxs IGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBm cmVlIHRvPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGN1dCB0aGlzIGludHJvZHVjdG9yeSBwYXJh Z3JhcGgsIGhvd2V2ZXIuKTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsm Z3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBQbGVhc2UgcmVmZXIgdG88YnI+Jmd0OyZn dDsmZ3Q7Jmd0OyZndDs8c3Bhbj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRm Lm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwiIHRhcmdldD0iX2JsYW5r Ij5odHRwOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRt bDwvYT48c3Bhbj4mbmJzcDs8L3NwYW4+Zm9yIG1vcmU8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg aW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy48YnI+ Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlv bnMsIGNhbiBiZSBmb3VuZDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBoZXJlOjxicj4mZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OzxzcGFuPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtb2F1dGgtanNvbi13ZWItdG9rZW4vIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9hdXRo LWpzb24td2ViLXRva2VuLzwvYT48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsm Z3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAtLTxicj4mZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyAtPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 PGJyPiZndDsmZ3Q7Jmd0OyBESVNDVVNTOjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IC0tPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IC08 YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZn dDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7ICgx KSA0LjEuMSBhbmQgZWxzZXdoZXJlIHlvdSBzYXkgY2FzZS1zZW5zaXRpdmU6IHRoZSBzYW1lIHRo aW5nIEk8YnI+Jmd0OyZndDsmZ3Q7IHJhaXNlZCB3cnQgRE5TPGJyPiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IG5hbWVzIGZvciBhbm90aGVyIEpPU0Ugc3BlYyAtIGRvIHlvdSBuZWVkIHRvIHNheSB0aG9z ZSBTSE9VTEQgYmU8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgW3VwcGVyfGxvd2VyXWNhc2VkIHdo ZW4gdXNlZCBpbiB0aGVzZT88YnI+Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7 IEkgYmVsaWV2ZSB0aGF0IHNvbWV3aGVyZSB3ZSBzaG91bGQgc2F5IHRoYXQgaWYgY2FzZS1pbnNl bnNpdGl2ZTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7IHZhbHVlcywgc3VjaCBhcyBETlMgbmFtZXMsIGFy ZSB1c2VkIHdoZW4gY29uc3RydWN0aW5nICJraWQiIHZhbHVlcyw8YnI+Jmd0OyZndDsmZ3Q7Jmd0 OyB0aGF0IHRoZSBhcHBsaWNhdGlvbiBkb2luZyBzbyBuZWVkcyB0byBkZWZpbmUgYSBjb252ZW50 aW9uIG9uIHRoZTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7IGNhbm9uaWNhbCBjYXNlIHRvIHVzZSBmb3Ig dGhlIGNhc2UtaW5zZW5zaXRpdmUgcG9ydGlvbnMsIHN1Y2ggYXM8YnI+Jmd0OyZndDsmZ3Q7Jmd0 OyBsb3dlcmNhc2luZyB0aGVtLjxicj4mZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7IEFzIHRo YXQgZGlzY3Vzc2lvbidzIGhhcHBlbmluZyBvbiB0aGUga2V5IGRyYWZ0LCBJJ2xsIGNsZWFyIGl0 IGhlcmU8YnI+Jmd0OyZndDsmZ3Q7IGFuZCB0cnVzdCB5b3UgdG8gZml4IGlmIGEgY2hhbmdlIGlz IHRoZSBlbmQgcmVzdWx0Ljxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyBUaGFua3M8YnI+PGJyPjwv ZGl2PjwvZGl2Pm5wPGJyPjxkaXY+PGRpdj48YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgKDIpIFNlY3Rpb24gODogV2h5IGlzICJub25lIiBNVEk/IFRoYXQgc2VlbXMgYm90aCBi cm9rZW4gYW5kIGdvaW5nPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGluIHRoZSBvcHBvc3RpdGUg ZGlyZWN0aW9uIGZyb20gb3RoZXIgV0dzIGFuZCBzbyBzaG91bGQgYmU8YnI+Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgZXhwbGljaXRseSBqdXNpZmllZCBJIHRoaW5rLiAoSWYgYSBnb29kIGVub3VnaCBq dXN0aWZpY2F0aW9uIGV4aXN0czxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aGF0IGlzLik8YnI+ Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7IEl0IGlzIE1USSBiZWNhdXNlIHRo ZXJlIGFyZSBzZXZlcmFsIGV4aXN0aW5nIGFwcGxpY2F0aW9ucyBvZiBKV1RzIGluPGJyPiZndDsm Z3Q7Jmd0OyZndDsgd2hpY2ggYm90aCB1bnNpZ25lZCBhbmQgc2lnbmVkIHJlcHJlc2VudGF0aW9u cyBvZiB0aGUgSldUcyBhcmU8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyByZXF1aXJlbWVudHMuJm5ic3A7 IFRoZXNlIGluY2x1ZGUgZHJhZnQtaWV0Zi1vYXV0aC10b2tlbi1leGNoYW5nZSw8YnI+Jmd0OyZn dDsmZ3Q7Jmd0OyBkcmFmdC1odW50LW9hdXRoLXYyLXVzZXItYTRjLCBhbmQgT3BlbklEIENvbm5l Y3QuJm5ic3A7IFRoaXMgaXMgYSBwcmV0dHk8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyBjb21tb24gcGF0 dGVybiB3aGVyZSB5b3Ugc2lnbiBzb21ldGhpbmcgaWYgdGhlIHJlY2lwaWVudCBjYXJlcyB3aG88 YnI+Jmd0OyZndDsmZ3Q7Jmd0OyBtYWRlIHRoZSBzdGF0ZW1lbnRzIGFuZCB3aGVyZSB5b3UgZG9u J3QgaGF2ZSB0byBzaWduIGl0IGVpdGhlciBpZjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7IHRoZSByZWNp cGllbnQgZG9lc24ndCBjYXJlIHdobyBtYWRlIHRoZSBzdGF0ZW1lbnRzPGJyPiZndDsmZ3Q7Jmd0 Ozxicj4mZ3Q7Jmd0OyZndDsgSSBkb24ndCBzZWUgaG93IChub24tKXNpZ25lcnMgY2FuIGRpdmlu ZSBub24tdmVyaWZpZXIncyB3aXNoZXMgdGhhdDxicj4mZ3Q7Jmd0OyZndDsgd2F5LiAoQWJzZW50 IG5lZ290aWF0aW9uIG9yIGEgZGlyZWN0b3J5Lik8YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDsgU29t ZXRpbWVzIGl0IGRvZXMgb2NjdXIgdmlhIG5lZ290aWF0aW9uLiZuYnNwOyBGb3IgaW5zdGFuY2Us IGluIHNvbWUgcHJvdG9jb2xzLCBhdDxicj4mZ3Q7Jmd0OyByZWdpc3RyYXRpb24gdGltZSwgcmVs eWluZyBwYXJ0aWVzIGV4cGxpY2l0bHkgdGVsbCBpZGVudGl0eSBwcm92aWRlcnMgd2hhdCBhbGdv cml0aG1zPGJyPiZndDsmZ3Q7IGFyZSBhY2NlcHRhYmxlIHRvIHRoZW0sIHdoaWNoIG1heSBpbmNs dWRlICJub25lIi4mbmJzcDsgTm8gZGl2aW5hdGlvbiAtIGV4cGxpY2l0PGJyPiZndDsmZ3Q7IGNv bW11bmljYXRpb24uPGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsgb3IgaWYgaXQgY2Fu IHRlbGwgZnJvbTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7IGFub3RoZXIgc2VjdXJlZCBhc3BlY3Qgb2Yg dGhlIGFwcGxpY2F0aW9uIHByb3RvY29sICh0eXBpY2FsbHk8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyB0 aHJvdWdoIHRoZSB1c2Ugb2YgVExTKSB3aG8gbWFkZSB0aGUgc3RhdGVtZW50cy4mbmJzcDsgSW4g dGhlIFRMUyBjYXNlLDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7IHRoZSBzZXJ2ZXIgYXV0aGVudGljYXRp b24gc3RlcCBtYWtlcyBhIHNpZ25hdHVyZSBzdGVwIHVubmVjZXNzYXJ5LDxicj4mZ3Q7Jmd0OyZn dDsmZ3Q7IHNvIGFuIFVuc2VjdXJlZCBKV1QgaXMgZmluZSB0aGVyZS48YnI+Jmd0OyZndDsmZ3Q7 PGJyPiZndDsmZ3Q7Jmd0OyBUaGF0J3MgYXJndWFibGUgSU1PLjxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7 Jmd0OyBJIGFncmVlIHRoYXQgaXQncyBhcHBsaWNhdGlvbiBhbmQgY29udGV4dC1kZXBlbmRlbnQg d2hldGhlciBpdCdzIE9LIG9yIG5vdC4mbmJzcDsgVGhlPGJyPiZndDsmZ3Q7IHBvaW50IGlzIHRo YXQgdGhlcmUgZXhpc3Qgc29tZSBjaXJjdW1zdGFuY2VzIGluIHdoaWNoIGl0IGlzIE9LLCBhbmQg dGhpcyBmZWF0dXJlIGlzPGJyPiZndDsmZ3Q7IGJlaW5nIHVzZWQgaW4gc29tZSBvZiB0aG9zZSBj YXNlcy48YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7IEkgdGhpbmsgSSdsbCBsb29rIGJhY2sg b3ZlciB0aGUgd2cgdGhyZWFkIGFuZCBlaXRoZXIgaG9sZCBteSBub3NlIG9yPGJyPiZndDsmZ3Q7 PGJyPiZndDsmZ3Q7IFRoaXMgaXNzdWUgd2FzIHRyYWNrZWQgYXM8c3Bhbj4mbmJzcDs8L3NwYW4+ PGEgaHJlZj0iaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cvam9zZS90cmFjL3RpY2tldC8z NiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL2pvc2UvdHJh Yy90aWNrZXQvMzY8L2E+Ljxicj4mZ3Q7Jmd0OyBLYXJlbiBPJ0Rvbm9naHVlIHJlY29yZGVkIHRo aXMgY29uY2x1c2lvbiBpbiB0aGUgdHJhY2tlciAiTm90ZTogVGhlcmUgd2FzPGJyPiZndDsmZ3Q7 IGV4dGVuc2l2ZSBkaXNjdXNzaW9uIG9uIHRoZSBtYWlsaW5nIGxpc3QsIGFuZCB0aGUgcm91Z2gm bmJzcDsgY29uc2Vuc3VzIG9mIHRoZSB3b3JraW5nPGJyPiZndDsmZ3Q7IGdyb3VwIHdhcyB0byBs ZWF2ZSAibm9uZSIgaW4gdGhlIGRvY3VtZW50LiI8YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDsgRGlz Y3Vzc2lvbiB0aHJlYWRzIG9uIHRoaXMgdG9waWMgaW5jbHVkZTo8YnI+Jmd0OyZndDsgW2pvc2Vd ICMzNjogQWxnb3JpdGhtICJub25lIiBzaG91bGQgYmUgcmVtb3ZlZDxzcGFuPiZuYnNwOzwvc3Bh bj48YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cDovL3d3dy5pZXRmLm9yZy9tYWlsLTwvYT48YnI+Jmd0OyZndDsgYXJjaGl2ZS93ZWIvam9zZS9j dXJyZW50L21zZzAyOTExLmh0bWwgLSBCZWdhbiBKdWwgMzEsIDIwMTMmbmJzcDsgKDkxIG1lc3Nh Z2VzKTxicj4mZ3Q7Jmd0OyBbam9zZV0gVGV4dCBhYm91dCBhcHBsaWNhdGlvbnMgYW5kICJhbGci OiJub25lIjxzcGFuPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21h aWwtIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLTwvYT48YnI+Jmd0 OyZndDsgYXJjaGl2ZS93ZWIvam9zZS9jdXJyZW50L21zZzAzMzIxLmh0bWwgLSBCZWdhbiBTZXAg MywgMjAxMyAoNSBtZXNzYWdlcyk8YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDsgVGhpcyBpc3N1ZSB3 YXMgYSB0b3BpYyBvZiBhIHNwZWNpYWwgd29ya2luZyBncm91cCBjYWxsIG9uIEF1ZyAxOSwgMjAx My4mbmJzcDsgVGhlIHRleHQ8YnI+Jmd0OyZndDsgZGlzY3Vzc2VkIGluIHRoZSBsYXN0IHRocmVh ZCBhbmQgcHVibGlzaGVkIGF0PHNwYW4+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtPC9hPjxicj4mZ3Q7Jmd0OyBpZXRmLWpvc2UtanNvbi13ZWItYWxn b3JpdGhtcy0zMyNzZWN0aW9uLTguNSAoVW5zZWN1cmVkIEpXUyBTZWN1cml0eTxicj4mZ3Q7Jmd0 OyBDb25zaWRlcmF0aW9ucykgd2FzIHRoZSByZXN1bHQgb2YgdGhlIHdvcmtpbmcgZ3JvdXAncyBk ZWNpc2lvbnMgcmVzdWx0aW5nIGZyb20gYWxsPGJyPiZndDsmZ3Q7IG9mIHRoaXMgZGlzY3Vzc2lv bi48YnI+PGJyPjwvZGl2PjwvZGl2PlRoYW5rcyBmb3IgYWxsIHRoZSBwb2ludGVycyBhYm92ZS4g SSByZWFkIHRocm91Z2ggYWxsIHRoZSAobWFueSEpPGJyPkF1ZyAxOSBtYWlscyBhbmQgbW9zdCBv ZiB0aGUgYCJub25lIiBzaG91bGQgYmUgcmVtb3ZlZCIgdGhyZWFkLjxicj48YnI+U28gSSBkbyBz ZWUgdGhhdCB0aGVyZSB3YXMgcm91Z2ggY29uc2Vuc3VzIHRvIGtlZXAgIm5vbmUiIGluPGJyPnRo ZSBkcmFmdCBhbmQgY2FuICh3aXRoIGRpZmZpY3VsdHk7LSkgaG9sZCBteSBub3NlIGFuZCBsZXQg dGhhdDxicj5wYXNzLiBJIGRvIG5vdCBob3dldmVyLCBzZWUgdGhhdCB0aGVyZSB3YXMgY29uc2Vu c3VzIHRvIG1ha2U8YnI+Im5vbmUiIE1USSBmb3IgdGhpcyBkcmFmdC4gSSBkaWQgc2VlIGEgYml0 IG9mIGhhZ2dsaW5nIGFib3V0PGJyPnRoaXMgZHJhZnQgdnMuIEpXUyBidXQgc3RpbGwgZG8gbm90 IHNlZSB3aHkgbm9uZSBvdWdodCBiZSBNVEk8YnI+aGVyZS48YnI+PHNwYW4+PGJyPiZndDsmZ3Q7 PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICgzKSBTZWN0aW9uIDEyOiBhbm90aGVyIHdheSB0byBo YW5kbGUgcHJpdmFjeSBpcyB0byBub3QgaW5jbHVkZTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBz ZW5zaXRpdmUgZGF0YSAtIEkgdGhpbmsgeW91IG91Z2h0IG1lbnRpb24gdGhhdCBhcyBhIGJpdCBv ZiB0aG91Z2h0PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFsb25nIHRob3NlIGxpbmVzIGNhbiBi ZSBtdWNoIHNpbXBsZXIgdGhhbiBwdXR0aW5nIGluIHBsYWNlIHRoZSBrZXk8YnI+Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgbWFuYWdlbWVudCB0byBoYW5kbGUgdGhvdWdodGxlc3NseSBpbmNsdWRlZCBQ SUkuPGJyPiZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyBXZSBjYW4gaW5jbHVk ZSBhIGRpc2N1c3Npb24gb2YgdGhhdCBwb2ludCw8YnI+Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7 Jmd0OyBHcmVhdC4gIkp1c3Qgc2F5IG5vIiBpcyB3b3JrYWJsZSBoZXJlOi0pIEknbGwgY2xlYXIg d2hlbiB3ZSBnZXQgc3VjaCB0ZXh0Ljxicj4mZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0 OyBidXQgc29tZXRpbWVzIHRoZSB2ZXJ5PGJyPiZndDsmZ3Q7Jmd0OyZndDsgcG9pbnQgb2YgYSBK V1QgaXMgdG8gc2VjdXJlbHkgZGVsaXZlciBQSUkgZnJvbSBhIHZlcmlmaWFibGUgcGFydHkgdG88 YnI+Jmd0OyZndDsmZ3Q7Jmd0OyBhbiBpbnRlbmRlZCBwYXJ0eSB3aXRoIGFwcHJvcHJpYXRlIHJp Z2h0cyB0byByZWNlaXZlIGl0Ljxicj4mZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7IEhtbS4g SXRzIGEgbW9vdCBwb2ludCAoc28gbGV0J3Mgbm90IGFyZ3VlIGl0KSBidXQgSSB3b25kZXIgaG93 IG9mdGVuPGJyPiZndDsmZ3Q7Jmd0OyBQSUkgaXMgcmVhbGx5IG5lZWRlZCBmb3IgYXV0aG9yaXph dGlvbiB3aXRoIG9hdXRoLiBNeSBndWVzcyB3b3VsZCBiZTxicj4mZ3Q7Jmd0OyZndDsgdGhhdCBp dHMgbmVlZGVkIGZhciBsZXNzIG9mdGVuIHRoYW4gaXRzIGZvdW5kIHRvIGJlIHByb2ZpdGFibGU8 YnI+Jmd0OyZndDsmZ3Q7IHBlcmhhcHMsIG9yIHRoYXQgY2FyZWxlc3NuZXNzIHBsYXlzIGEgYmln IHJvbGUgaW4gdXNpbmcgUElJIGZvciBzdWNoIHB1cnBvc2VzLjxicj48YnI+PC9zcGFuPkkndmUg Y2xlYXJlZCBvbiB0aGlzIGFzIHlvdSBhZGRlZCB0aGlzIHRleHQ6PGJyPjxicj4mbmJzcDs8c3Bh bj4mbmJzcDs8L3NwYW4+Ik9mIGNvdXJzZSwgaW5jbHVkaW5nPGJyPiZuYnNwOyAmbmJzcDtvbmx5 IG5lY2Vzc2FyeSBwcml2YWN5LXNlbnNpdGl2ZSBpbmZvcm1hdGlvbiBpbiBhIEpXVCBpcyB0aGUg bW9zdDxicj4mbmJzcDsgJm5ic3A7YmFzaWMgbWVhbnMgb2YgbWluaW1pemluZyBhbnkgcG90ZW50 aWFsIHByaXZhY3kgaXNzdWVzLiI8YnI+PGJyPlRoYXQgc2VlbXMgdG8gbWUgbGlrZSBhIGZhaXJs eSBvZmZwdXR0aW5nIHdheSB0byBwaHJhc2UgaXQuIEknZDxicj5zdWdnZXN0IGluc3RlYWQ6PGJy Pjxicj4mbmJzcDs8c3Bhbj4mbmJzcDs8L3NwYW4+Ik9taXR0aW5nIHByaXZhY3ktc2Vuc2l0aXZl IGluZm9ybWF0aW9uIGZyb20gYSBKV1QgaXMgdGhlPGJyPiZuYnNwOzxzcGFuPiZuYnNwOzwvc3Bh bj5zaW1wbGVzdCB3YXkgb2YgbWluaW1pemluZyBwcml2YWN5IGlzc3Vlcy4iPGJyPjwvYmxvY2tx dW90ZT48ZGl2Pjxicj48L2Rpdj48ZGl2PkkgbGlrZSB0aGlzIHdvcmRpbmcgc3VnZ2VzdGlvbiwg dGhhbmtzLjwvZGl2PjxkaXY+Jm5ic3A7PC9kaXY+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1 b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0LXdpZHRoOjFw eDtib3JkZXItbGVmdC1jb2xvcjpyZ2IoMjA0LDIwNCwyMDQpO2JvcmRlci1sZWZ0LXN0eWxlOnNv bGlkO3BhZGRpbmctbGVmdDoxZXgiPjxicj5DaGVlcnMsPGJyPlMuPGJyPjxicj5QUzogSSBkaWRu J3QgY2hlY2sgdGhlIGNvbW1lbnRzLjxicj48ZGl2PjxkaXY+PGJyPiZndDsmZ3Q7Jmd0Ozxicj4m Z3Q7Jmd0OyZndDsgUy48YnI+Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0 OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IC0tPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IC08 YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZn dDsmZ3Q7IENPTU1FTlQ6PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgLS08YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgLTxicj4mZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsgLSBhYnN0cmFjdDog Mm5kIHNlbnRlbmNlIGlzbid0IG5lZWRlZCBoZXJlLCBpbiBpbnRybyB3b3VsZCBiZSBmaW5lLjxi cj4mZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsgSSBkb24ndCBrbm93IC0gSSB0 aGluayBpdCdzIGEgYmlnIGRlYWwgdGhhdCB0aGUgY2xhaW1zIGNhbiBiZTxicj4mZ3Q7Jmd0OyZn dDsmZ3Q7IGRpZ2l0YWxseSBzaWduZWQgb3IgTUFDZWQgYW5kL29yIGVuY3J5cHRlZC4mbmJzcDsg VGhhdCdzIHRoZSByZWFzb24gd2U8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyBoYXZlIEpXVHMsIHJhdGhl ciB0aGFuIGp1c3QgSlNPTi48YnI+Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyAtIDQuMS43OiBtYXliZSB3b3J0aCBhZGRpbmcgdGhhdCBqdGkraXNzIGJlaW5nIHVuaXF1 ZSBlbm91Z2ggaXMgbm90PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHN1ZmZpY2llbnQgYW5kIGp0 aSBhbG9uZSBoYXMgdG8gbWVldCB0aGF0IG5lZWQuIEluIFguNTA5IHRoZTxicj4mZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBpc3N1ZXIvc2VyaWFsIGhhcyB0aGUgZXF1aXZhbGVudCBwcm9wZXJ0eSBzbyBz b21lb25lIG1pZ2h0IGFzc3VtZTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzZXF1ZW50aWFsIGp0 aSB2YWx1ZXMgc3RhcnRpbmcgYXQgMCBhcmUgb2suPGJyPiZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0 OyZndDsmZ3Q7Jmd0OyBNYWtlcyBzZW5zZSB0byBhZGQgYSB3YXJuaW5nIG9mIHNvbWUga2luZCBh bG9uZyB0aGVzZSBsaW5lcy4mbmJzcDsgSTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7IHRoaW5rIEkga25v dyB0aGUgcmVhc29ucyB5b3Ugc2F5IHRoYXQsIGJ1dCBjYW4geW91IGV4cGFuZCBvbiB0aGF0PGJy PiZndDsmZ3Q7Jmd0OyZndDsgdGhvdWdodCBhIGJpdCBiZWZvcmUgSSB0YWtlIGEgc3RhYiBvbiB3 cml0aW5nIHRoaXMgdXA/Jm5ic3A7IEZvcjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7IGluc3RhbmNlLCB3 aGlsZSBub3JtYWxseSB0cnVlLCBJIGRvbid0IHRoaW5rIHlvdXIgb2JzZXJ2YXRpb24gaXM8YnI+ Jmd0OyZndDsmZ3Q7Jmd0OyB0cnVlIGlmIGEgcmVseWluZyBwYXJ0eSB3aWxsIG9ubHkgYWNjZXB0 IHRva2VucyBmcm9tIGEgc2luZ2xlIGlzc3Vlci48YnI+Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyAtIHNlY3Rpb24gNjogeXVrPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IC0gYWdhaW4gSSB0aGluayB0aGUgc2VjZGlyIGNvbW1l bnRzIGFyZSBiZWluZyBoYW5kbGVkIGJ5IEthdGhsZWVuPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IGFuZCB0aGUgYXV0aG9ycy48YnI+Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7 IEFnYWluLCB0aGlzIGlzIHRoZXJlIGJlY2F1c2UgbXVsdGlwbGUgYXBwbGljYXRpb25zIGFza2Vk IGZvciB0aGU8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyBhYmlsaXR5IHRvIHJlcHJlc2VudCBjb250ZW50 IHRoYXQgaXMgb3B0aW9uYWxseSBzaWduZWQsIHNvbWV0aW1lczxicj4mZ3Q7Jmd0OyZndDsmZ3Q7 IHNlY3VyaW5nIGl0IGFub3RoZXIgd2F5LCBzdWNoIGFzIHdpdGggVExTLiZuYnNwOyBKV1RzIGFy ZSB1c2VkIHNwZWNpZmljPGJyPiZndDsmZ3Q7Jmd0OyZndDsgYXBwbGljYXRpb24gcHJvdG9jb2wg Y29udGV4dHMgLSBub3QgaW4gaXNvbGF0aW9uLjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsm Z3Q7Jmd0OyZndDsgVGhhbmtzIGFnYWluLCAtLSBNaWtlPGJyPiZndDsmZ3Q7Jmd0OyZndDs8YnI+ Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+Jmd0OyZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPiZndDsmZ3Q7PHNwYW4+Jm5ic3A7PC9z cGFuPjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRo QGlldGYub3JnPC9hPjxicj4mZ3Q7Jmd0OzxzcGFuPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48YnI+Jmd0Ozxi cj48YnI+PC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjwvZGl2PjxiciBzdHlsZT0iZm9udC1mYW1p bHk6SGVsdmV0aWNhO2ZvbnQtc2l6ZToxMnB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtdmFyaWFu dDpub3JtYWw7Zm9udC13ZWlnaHQ6bm9ybWFsO2xldHRlci1zcGFjaW5nOm5vcm1hbDtsaW5lLWhl aWdodDpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDowcHg7dGV4dC10cmFuc2Zv cm06bm9uZTt3aGl0ZS1zcGFjZTpub3JtYWw7d29yZC1zcGFjaW5nOjBweCI+PGJyIGNsZWFyPSJh bGwiIHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2E7Zm9udC1zaXplOjEycHg7Zm9udC1zdHls ZTpub3JtYWw7Zm9udC12YXJpYW50Om5vcm1hbDtmb250LXdlaWdodDpub3JtYWw7bGV0dGVyLXNw YWNpbmc6bm9ybWFsO2xpbmUtaGVpZ2h0Om5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQtaW5k ZW50OjBweDt0ZXh0LXRyYW5zZm9ybTpub25lO3doaXRlLXNwYWNlOm5vcm1hbDt3b3JkLXNwYWNp bmc6MHB4Ij48ZGl2IHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2E7Zm9udC1zaXplOjEycHg7 Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJpYW50Om5vcm1hbDtmb250LXdlaWdodDpub3JtYWw7 bGV0dGVyLXNwYWNpbmc6bm9ybWFsO2xpbmUtaGVpZ2h0Om5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0 O3RleHQtaW5kZW50OjBweDt0ZXh0LXRyYW5zZm9ybTpub25lO3doaXRlLXNwYWNlOm5vcm1hbDt3 b3JkLXNwYWNpbmc6MHB4Ij48YnI+PC9kaXY+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZl dGljYTtmb250LXNpemU6MTJweDtmb250LXN0eWxlOm5vcm1hbDtmb250LXZhcmlhbnQ6bm9ybWFs O2ZvbnQtd2VpZ2h0Om5vcm1hbDtsZXR0ZXItc3BhY2luZzpub3JtYWw7bGluZS1oZWlnaHQ6bm9y bWFsO3RleHQtYWxpZ246c3RhcnQ7dGV4dC1pbmRlbnQ6MHB4O3RleHQtdHJhbnNmb3JtOm5vbmU7 d2hpdGUtc3BhY2U6bm9ybWFsO3dvcmQtc3BhY2luZzowcHg7ZmxvYXQ6bm9uZTtkaXNwbGF5Omlu bGluZSFpbXBvcnRhbnQiPi0tPHNwYW4+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48YnIgc3R5bGU9ImZv bnQtZmFtaWx5OkhlbHZldGljYTtmb250LXNpemU6MTJweDtmb250LXN0eWxlOm5vcm1hbDtmb250 LXZhcmlhbnQ6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtsZXR0ZXItc3BhY2luZzpub3JtYWw7 bGluZS1oZWlnaHQ6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7dGV4dC1pbmRlbnQ6MHB4O3RleHQt dHJhbnNmb3JtOm5vbmU7d2hpdGUtc3BhY2U6bm9ybWFsO3dvcmQtc3BhY2luZzowcHgiPjxkaXYg ZGlyPSJsdHIiIHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2E7Zm9udC1zaXplOjEycHg7Zm9u dC1zdHlsZTpub3JtYWw7Zm9udC12YXJpYW50Om5vcm1hbDtmb250LXdlaWdodDpub3JtYWw7bGV0 dGVyLXNwYWNpbmc6bm9ybWFsO2xpbmUtaGVpZ2h0Om5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3Rl eHQtaW5kZW50OjBweDt0ZXh0LXRyYW5zZm9ybTpub25lO3doaXRlLXNwYWNlOm5vcm1hbDt3b3Jk LXNwYWNpbmc6MHB4Ij48YnI+PGRpdj5CZXN0IHJlZ2FyZHMsPC9kaXY+PGRpdj5LYXRobGVlbjwv ZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48YnI+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+ PGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPgpP QXV0aCBtYWlsaW5nIGxpc3Q8YnI+CjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1 dGhAaWV0Zi5vcmc8L2E+PGJyPgo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9vYXV0aDwvYT48YnI+Cjxicj48L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPjxi ciBjbGVhcj0iYWxsIj48ZGl2Pjxicj48L2Rpdj4tLSA8YnI+TmF0IFNha2ltdXJhICg9bmF0KTxk aXY+Q2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uPGJyPjxhIGhyZWY9Imh0dHA6Ly9uYXQuc2Fr aW11cmEub3JnLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9uYXQuc2FraW11cmEub3JnLzwvYT48 YnI+QF9uYXRfZW48L2Rpdj4KPC9kaXY+CjwvYm9keT4= ----_com.android.email_660276537683240-- From nobody Sun Oct 26 16:18:17 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24AB31A1A97; Sun, 26 Oct 2014 16:18: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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tgaArrOmEQ7I; Sun, 26 Oct 2014 16:18:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 064EF1A1B12; Sun, 26 Oct 2014 16:18:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141026231809.3216.45800.idtracker@ietfa.amsl.com> Date: Sun, 26 Oct 2014 16:18:09 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/eNCekEgWOMtobXZYSeqO6U19lqI Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2014 23:18:12 -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 Working Group of the IETF. Title : Symmetric Proof of Possession for the OAuth Authorization Code Grant Authors : Nat Sakimura John Bradley Naveen Agarwal Filename : draft-ietf-oauth-spop-01.txt Pages : 11 Date : 2014-10-26 Abstract: The OAuth 2.0 public client utilizing Authorization Code Grant (RFC 6749 - 4.1) is susceptible to the code interception attack. This specification describes a mechanism that acts as a control against this threat. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-spop-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-spop-01 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 Oct 27 12:58:32 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD9FF1AD399; Mon, 27 Oct 2014 12:58:09 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7bWGqNmbqVYN; Mon, 27 Oct 2014 12:58:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C0F961A0386; Mon, 27 Oct 2014 12:57:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141027195759.23487.80102.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 12:57:59 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/74x6HwUohrVlK3tY8e0zjPVXkr4 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-02.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 19:58:09 -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 Working Group of the IETF. Title : Symmetric Proof of Possession for the OAuth Authorization Code Grant Authors : Nat Sakimura John Bradley Naveen Agarwal Filename : draft-ietf-oauth-spop-02.txt Pages : 10 Date : 2014-10-27 Abstract: The OAuth 2.0 public client utilizing Authorization Code Grant (RFC 6749 - 4.1) is susceptible to the code interception attack. This specification describes a mechanism that acts as a control against this threat. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-spop-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-spop-02 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 Oct 27 16:21:53 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33F6C1A6FE3 for ; Mon, 27 Oct 2014 16:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uIHsuRmY9FFd for ; Mon, 27 Oct 2014 16:21:38 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id A39DF1A6FD6 for ; Mon, 27 Oct 2014 16:21:22 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 42DC6B2E018; Mon, 27 Oct 2014 19:21:22 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id 3A89DB2E017; Mon, 27 Oct 2014 19:21:22 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.78]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.03.0174.001; Mon, 27 Oct 2014 19:21:22 -0400 From: "Richer, Justin P." To: Hannes Tschofenig Thread-Topic: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference Call Thread-Index: AQHP8jy3IhFJJ3qL2UKpZ0KVl4+vkg== Date: Mon, 27 Oct 2014 23:21:21 +0000 Message-ID: References: <543FF850.6070409@gmx.net> In-Reply-To: <543FF850.6070409@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.11.119] Content-Type: text/plain; charset="us-ascii" Content-ID: <899B003E2C0681469AB022C65F21AA38@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/qUMiGbGxi6B2uemdMdUtLAMX1-A Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference Call X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 23:21:45 -0000 I've been incorporating peoples' feedback into the proposed oauth.net page,= and the current state is here: https://github.com/jricher/oauth.net/blob/authentication/articles/authentic= ation.php Commentary has slowed down and I think the document's in reasonable. I woul= d like to publish this as a draft version on oauth.net in the very near fut= ure (like, this week), so get comments and feedback to me on this soon. I'm= going to be at IIW all week if anyone wants to back me into a corner and t= alk about this. -- Justin On Oct 16, 2014, at 12:54 PM, Hannes Tschofenig = wrote: > Participants: >=20 > * Brian Campbell > * John Bradley > * Derek Atkins > * Phil Hunt > * William Kim > * Josh Mandel > * Hannes Tschofenig >=20 >=20 > Notes: >=20 > Justin distributed a draft writeup and explained the reasoning behind > it. The intended purpose is to put the write-up (after enough review) on > oauth.net. See attachments. Justin solicited feedback from the > conference call participants and from the working group. >=20 > One discussion item was specifically related to the concept of audience > restrictions, which comes in two flavours: (a) restriction of the access > token regarding the resource server and (b) restriction of the id token > regarding the client. Obviously, it is necessary to have both of these > audience restrictions in place and to actually check them. >=20 > The group then went into a discussion about the use of pseudonyms in > authentication and the problems deployments ran into when they used > pseudonyms together with a wide range of attributes that identified > users nevertheless. Phil suggested to produce a write-up about this topic= . >=20 > Finally, the group started a discussion about potential actions for the > OAuth working groups. Two activities were mentioned, namely to produce > an IETF draft of the write-up Justin has prepared as a "formal" response > to the problems with authentication using OAuth and, as a second topic, > potential re-chartering of the OAuth working group to work on some > solutions in this area. Hannes suggested to postpone these discussions > and to first finish the write-up Justin had distributed. >=20 > Ciao > Hannes & Derek > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Tue Oct 28 03:41:45 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81CBB1A1B5D for ; Tue, 28 Oct 2014 03:41:14 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Syeas07Z4JYp for ; Tue, 28 Oct 2014 03:41:11 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCAA61A1B71 for ; Tue, 28 Oct 2014 03:41:07 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id y10so452119wgg.35 for ; Tue, 28 Oct 2014 03:41:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=BWl+mErs8EcYU/xNmb8YDeBW2hU31F7lsblXuXDbqKU=; b=p4CHCh0mjqwADMFE8dZ2gXpE3E+g1lY1uFD2TM3upLgNjw+wlPqyE8P8y6doCI8TmO hydJ45NvbC6i4TBRmKyWhaSon8iUNLgQqvwrNg59boONqRnQLRdiWH1xGvkt7MPqpwR6 RLDSTffSBzWL6NvDrBUycRwiHDU166/u/EZWiqmT+9VJInt9qhhqU0pvcIrdQ0RJ1+Am Op1SXSa3qlSThRdi//n+rYY+bvMG0341LcmJz0DTC493WTiWhozxxbOyYkV3mNX9gbWG wcPB1YBEYZORaupvLgOSLqJPlaa1eh0LElnRh2oeKHO/djN0zkwJH1QKbpSMxkn/SrdS jaIQ== X-Received: by 10.194.91.176 with SMTP id cf16mr3010566wjb.60.1414492866331; Tue, 28 Oct 2014 03:41:06 -0700 (PDT) Received: from [192.168.2.7] ([109.255.82.67]) by mx.google.com with ESMTPSA id b6sm1707581wiy.22.2014.10.28.03.41.05 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Oct 2014 03:41:05 -0700 (PDT) Message-ID: <544F72C0.8010403@gmail.com> Date: Tue, 28 Oct 2014 10:41:04 +0000 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: oauth@ietf.org References: <4E1F6AAD24975D4BA5B16804296739439BB0D3F3@TK5EX14MBXC286.redmond.corp.microsoft.com> <54465CBF.5070509@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/L7CBQx1_h_5wlfo9avUmwcQ-oc0 Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 10:41:14 -0000 Hi I've found 'none' to be a useful mechanism for using JWT representations as OAuth2 (bearer) tokens where JWT is turned into JWS with a none algorithm and then encrypted... Cheers, Sergey On 23/10/14 09:58, Nat Sakimura wrote: > I second John's message. There are many ways to achieve a desired level > of security and one of the most popular way is to delegate it to the > transport layer and use 'none' as the alg. If 'none' becomes non-MTI, > then it may cause a lot of interoperability issues down the road. > > Adding to it, JWT can be useful in other context than security as well. > As interoperability is one of the most important criteria, having 'none' > as MTI seems to be a reasonable idea to me. > > Nat > > 2014-10-22 16:44 GMT-05:00 John Bradley >: > > From a JWT perspective a number of applications including connect > allow unsecured JWT. > > I guess you are referring to sec 8 of JWT in the OAuth WG. Some of > the threads you mention were in the JOSE WG relating to the JWS spec > and if none should be included. > > To some extent the issues are not quite the same for the different > specs. > > SAML certainly allows for unsigned documents, those are used in a > lot of places. I imagine that a SAML library that could not process > unsigned messages would generally be considered broken. > That is not to say that it also needs to also support signed ones > and some number of trust models. > > It is the same for JWT as it lives at a similar conceptual level to > SAML assertions. > > It is better for interoperability to have all the JWT libs implement > "none", so that it can be supported in the many cases it may be used > for processing JWT protected by transport or some other mechanism, > and reliably reject "none" when signatures are required. > > The JWT spec is not requiring JWS or JWE to implement support for > none, though likely life would be easier if they did support it. > > John B. > > > > On Oct 21, 2014, at 1:36 PM, Kathleen Moriarty > > wrote: > >> >> >> On Tue, Oct 21, 2014 at 9:16 AM, Stephen >> Farrell> >wrote: >> >> >> Hi Mike, >> >> I've one remaining discuss point and a comment. See below... >> >> On 14/10/14 13:50, Mike Jones wrote: >> > The proposed resolutions below have been included in the -28 >> draft. Hopefully you'll be able to clear your DISCUSSes on >> that basis. >> > >> > The String Comparison Rules in Section 7.3 have been >> expanded to talk about when the application may need >> canonicalization rules. >> > >> > Thanks again, >> > -- Mike >> > >> >> -----Original Message----- >> >> From: OAuth [mailto:oauth-bounces@ietf.org >> ] On Behalf Of Mike Jones >> >> Sent: Monday, October 06, 2014 7:20 PM >> >> To: Stephen Farrell; The IESG >> >> Cc:oauth-chairs@tools.ietf.org >> ; draft-ietf-oauth-json-web- >> >>token@tools.ietf.org >> ;oauth@ietf.org >> >> >> Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on >> draft-ietf-oauth-json- >> >> web-token-27: (with DISCUSS and COMMENT) >> >> >> >> Thanks for tracking all of this Stephen. Responses inline >> below... >> >> >> >>> -----Original Message----- >> >>> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie >> ] >> >>> Sent: Monday, October 06, 2014 2:43 PM >> >>> To: Mike Jones; The IESG >> >>> Cc:oauth-chairs@tools.ietf.org >> ; draft-ietf-oauth-json-web- >> >>>token@tools.ietf.org >> ;oauth@ietf.org >> >> >>> Subject: Re: Stephen Farrell's Discuss on >> draft-ietf-oauth-json-web-token-27: >> >>> (with DISCUSS and COMMENT) >> >>> >> >>> >> >>> Hi Mike, >> >>> >> >>> On 06/10/14 08:54, Mike Jones wrote: >> >>>> Thanks for your review, Stephen. I've added the working >> group to >> >>>> the thread so they're aware of your comments. >> >>>> >> >>>>> -----Original Message----- From: Stephen Farrell >> >>>>> [mailto:stephen.farrell@cs.tcd.ie >> ] Sent: Thursday, October >> 02, 2014 >> >>>>> 5:03 AM To: The IESG Cc:oauth-chairs@tools.ietf.org >> ; >> >>>>> draft-ietf-oauth-json-web-token@tools.ietf.org >> Subject: Stephen >> >>>>> Farrell's Discuss on draft-ietf-oauth-json-web-token-27: >> (with >> >>>>> DISCUSS and COMMENT) >> >>>>> >> >>>>> Stephen Farrell has entered the following ballot >> position for >> >>>>> draft-ietf-oauth-json-web-token-27: Discuss >> >>>>> >> >>>>> When responding, please keep the subject line intact and >> reply to >> >>>>> all email addresses included in the To and CC lines. >> (Feel free to >> >>>>> cut this introductory paragraph, however.) >> >>>>> >> >>>>> >> >>>>> Please refer to >> >>>>>http://www.ietf.org/iesg/statement/discuss-criteria.htmlfor >> more >> >>>>> information about IESG DISCUSS and COMMENT positions. >> >>>>> >> >>>>> >> >>>>> The document, along with other ballot positions, can be >> found >> >>>>> here: >> >>>>>http://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/ >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> ------------------------------------------------------------------- >> >>>>> -- >> >>>>> - >> >>>>> >> >>>>> >> >>> DISCUSS: >> >>>>> >> ------------------------------------------------------------------- >> >>>>> -- >> >>>>> - >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>> (1) 4.1.1 and elsewhere you say case-sensitive: the same >> thing I >> >>> raised wrt DNS >> >>>>> names for another JOSE spec - do you need to say those >> SHOULD be >> >>>>> [upper|lower]cased when used in these? >> >>>> >> >>>> I believe that somewhere we should say that if >> case-insensitive >> >>>> values, such as DNS names, are used when constructing >> "kid" values, >> >>>> that the application doing so needs to define a >> convention on the >> >>>> canonical case to use for the case-insensitive portions, >> such as >> >>>> lowercasing them. >> >>> >> >>> As that discussion's happening on the key draft, I'll >> clear it here >> >>> and trust you to fix if a change is the end result. >> >> >> >> Thanks >> >> np >> >> >> >> >>>>> (2) Section 8: Why is "none" MTI? That seems both broken >> and going >> >>>>> in the oppostite direction from other WGs and so should be >> >>>>> explicitly jusified I think. (If a good enough >> justification exists >> >>>>> that is.) >> >>>> >> >>>> It is MTI because there are several existing applications >> of JWTs in >> >>>> which both unsigned and signed representations of the >> JWTs are >> >>>> requirements. These include draft-ietf-oauth-token-exchange, >> >>>> draft-hunt-oauth-v2-user-a4c, and OpenID Connect. This >> is a pretty >> >>>> common pattern where you sign something if the recipient >> cares who >> >>>> made the statements and where you don't have to sign it >> either if >> >>>> the recipient doesn't care who made the statements >> >>> >> >>> I don't see how (non-)signers can divine non-verifier's >> wishes that >> >>> way. (Absent negotiation or a directory.) >> >> >> >> Sometimes it does occur via negotiation. For instance, in >> some protocols, at >> >> registration time, relying parties explicitly tell identity >> providers what algorithms >> >> are acceptable to them, which may include "none". No >> divination - explicit >> >> communication. >> >> >> >>>> or if it can tell from >> >>>> another secured aspect of the application protocol (typically >> >>>> through the use of TLS) who made the statements. In the >> TLS case, >> >>>> the server authentication step makes a signature step >> unnecessary, >> >>>> so an Unsecured JWT is fine there. >> >>> >> >>> That's arguable IMO. >> >> >> >> I agree that it's application and context-dependent whether >> it's OK or not. The >> >> point is that there exist some circumstances in which it is >> OK, and this feature is >> >> being used in some of those cases. >> >> >> >>> I think I'll look back over the wg thread and either hold >> my nose or >> >> >> >> This issue was tracked >> ashttp://trac.tools.ietf.org/wg/jose/trac/ticket/36. >> >> Karen O'Donoghue recorded this conclusion in the tracker >> "Note: There was >> >> extensive discussion on the mailing list, and the rough >> consensus of the working >> >> group was to leave "none" in the document." >> >> >> >> Discussion threads on this topic include: >> >> [jose] #36: Algorithm "none" should be >> removedhttp://www.ietf.org/mail- >> >> archive/web/jose/current/msg02911.html - Began Jul 31, >> 2013 (91 messages) >> >> [jose] Text about applications and >> "alg":"none"http://www.ietf.org/mail- >> >> archive/web/jose/current/msg03321.html - Began Sep 3, 2013 >> (5 messages) >> >> >> >> This issue was a topic of a special working group call on >> Aug 19, 2013. The text >> >> discussed in the last thread and published >> athttps://tools.ietf.org/html/draft- >> >> ietf-jose-json-web-algorithms-33#section-8.5 (Unsecured JWS >> Security >> >> Considerations) was the result of the working group's >> decisions resulting from all >> >> of this discussion. >> >> Thanks for all the pointers above. I read through all the (many!) >> Aug 19 mails and most of the `"none" should be removed" thread. >> >> So I do see that there was rough consensus to keep "none" in >> the draft and can (with difficulty;-) hold my nose and let that >> pass. I do not however, see that there was consensus to make >> "none" MTI for this draft. I did see a bit of haggling about >> this draft vs. JWS but still do not see why none ought be MTI >> here. >> >> >> >> >>>>> (3) Section 12: another way to handle privacy is to not include >> >>>>> sensitive data - I think you ought mention that as a bit of thought >> >>>>> along those lines can be much simpler than putting in place the key >> >>>>> management to handle thoughtlessly included PII. >> >>>> >> >>>> We can include a discussion of that point, >> >>> >> >>> Great. "Just say no" is workable here:-) I'll clear when we get such text. >> >>> >> >>>> but sometimes the very >> >>>> point of a JWT is to securely deliver PII from a verifiable party to >> >>>> an intended party with appropriate rights to receive it. >> >>> >> >>> Hmm. Its a moot point (so let's not argue it) but I wonder how often >> >>> PII is really needed for authorization with oauth. My guess would be >> >>> that its needed far less often than its found to be profitable >> >>> perhaps, or that carelessness plays a big role in using PII for such purposes. >> >> I've cleared on this as you added this text: >> >> "Of course, including >> only necessary privacy-sensitive information in a JWT is >> the most >> basic means of minimizing any potential privacy issues." >> >> That seems to me like a fairly offputting way to phrase it. I'd >> suggest instead: >> >> "Omitting privacy-sensitive information from a JWT is the >> simplest way of minimizing privacy issues." >> >> >> I like this wording suggestion, thanks. >> >> >> Cheers, >> S. >> >> PS: I didn't check the comments. >> >> >>> >> >>> S. >> >>> >> >>> >> >>> >> >>>> >> >>>>> >> ------------------------------------------------------------------- >> >>>>> -- >> >>>>> - >> >>>>> >> >>>>> >> >>> COMMENT: >> >>>>> >> ------------------------------------------------------------------- >> >>>>> -- >> >>>>> - >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>> - abstract: 2nd sentence isn't needed here, in intro would >> be fine. >> >>>> >> >>>> I don't know - I think it's a big deal that the claims can be >> >>>> digitally signed or MACed and/or encrypted. That's the >> reason we >> >>>> have JWTs, rather than just JSON. >> >>>> >> >>>>> - 4.1.7: maybe worth adding that jti+iss being unique >> enough is not >> >>>>> sufficient and jti alone has to meet that need. In X.509 the >> >>>>> issuer/serial has the equivalent property so someone >> might assume >> >>>>> sequential jti values starting at 0 are ok. >> >>>> >> >>>> Makes sense to add a warning of some kind along these >> lines. I >> >>>> think I know the reasons you say that, but can you expand >> on that >> >>>> thought a bit before I take a stab on writing this up? For >> >>>> instance, while normally true, I don't think your >> observation is >> >>>> true if a relying party will only accept tokens from a >> single issuer. >> >>>> >> >>>>> - section 6: yuk >> >>>>> >> >>>>> - again I think the secdir comments are being handled by >> Kathleen >> >>>>> and the authors. >> >>>> >> >>>> Again, this is there because multiple applications asked >> for the >> >>>> ability to represent content that is optionally signed, >> sometimes >> >>>> securing it another way, such as with TLS. JWTs are used >> specific >> >>>> application protocol contexts - not in isolation. >> >>>> >> >>>> Thanks again, -- Mike >> >>>> >> >> _______________________________________________ >> >> OAuth mailing list >> >>OAuth@ietf.org >> >>https://www.ietf.org/mailman/listinfo/oauth >> > >> >> >> >> >> -- >> >> Best regards, >> Kathleen > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > -- > Nat Sakimura (=nat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From nobody Tue Oct 28 12:16:21 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EBB91AC3FC for ; Tue, 28 Oct 2014 12:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ow6Q7iWcxFCP for ; Tue, 28 Oct 2014 12:16:11 -0700 (PDT) Received: from BLU004-OMC1S22.hotmail.com (blu004-omc1s22.hotmail.com [65.55.116.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68C051AC3A0 for ; Tue, 28 Oct 2014 12:13:55 -0700 (PDT) Received: from BLU406-EAS398 ([65.55.116.8]) by BLU004-OMC1S22.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Tue, 28 Oct 2014 12:13:54 -0700 X-TMN: [/t8EoWUsdI2OM3oNB9eVU41w/fLza/ea] X-Originating-Email: [panca70@outlook.com] Message-ID: Content-Type: multipart/mixed; boundary="===============1908545373==" MIME-Version: 1.0 X-Client-ID: 436 X-Mailer: BlackBerry Email (10.2.1.3247) Date: Wed, 29 Oct 2014 02:13:43 +0700 From: Panca Agus Ananda To: X-OriginalArrivalTime: 28 Oct 2014 19:13:54.0546 (UTC) FILETIME=[50E11520:01CFF2E3] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/cAvzZ6zdudkaPLk1AwfVm6ohGAM Subject: [OAUTH-WG] Bls: OAuth Digest, Vol 72, Issue 78 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 19:16:18 -0000 --===============1908545373== Content-Type: multipart/alternative; boundary="_abb7de1d-18fc-4472-aa4c-78a0a5b0e7cd_" --_abb7de1d-18fc-4472-aa4c-78a0a5b0e7cd_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Dikirim dari ponsel cerdas BlackBerry 10 saya dengan jaringan Telkomsel. Dari: oauth-request@ietf.org Terkirim: Rabu=2C 29 Oktober 2014 02.01 Ke: oauth@ietf.org Balas Ke: oauth@ietf.org Perihal: OAuth Digest=2C Vol 72=2C Issue 78 Send OAuth mailing list submissions to oauth@ietf.org To subscribe or unsubscribe via the World Wide Web=2C visit https://www.ietf.org/mailman/listinfo/oauth or=2C via email=2C send a message with subject or body 'help' to oauth-request@ietf.org You can reach the person managing the list at oauth-owner@ietf.org When replying=2C please edit your Subject line so it is more specific than "Re: Contents of OAuth digest..." Today's Topics: 1. Re: Notes from 2nd "OAuth & Authentication" Conference Call (Richer=2C Justin P.) 2. Re: Stephen Farrell's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) (Sergey Beryozkin) ---------------------------------------------------------------------- Message: 1 Date: Mon=2C 27 Oct 2014 23:21:21 +0000 From: "Richer=2C Justin P." To: Hannes Tschofenig Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Notes from 2nd "OAuth & Authentication" Conference Call Message-ID: Content-Type: text/plain=3B charset=3D"us-ascii" I've been incorporating peoples' feedback into the proposed oauth.net page= =2C and the current state is here: https://github.com/jricher/oauth.net/blob/authentication/articles/authentic= ation.php Commentary has slowed down and I think the document's in reasonable. I woul= d like to publish this as a draft version on oauth.net in the very near fut= ure (like=2C this week)=2C so get comments and feedback to me on this soon.= I'm going to be at IIW all week if anyone wants to back me into a corner a= nd talk about this. -- Justin On Oct 16=2C 2014=2C at 12:54 PM=2C Hannes Tschofenig wrote: > Participants: > > * Brian Campbell > * John Bradley > * Derek Atkins > * Phil Hunt > * William Kim > * Josh Mandel > * Hannes Tschofenig > > > Notes: > > Justin distributed a draft writeup and explained the reasoning behind > it. The intended purpose is to put the write-up (after enough review) on > oauth.net. See attachments. Justin solicited feedback from the > conference call participants and from the working group. > > One discussion item was specifically related to the concept of audience > restrictions=2C which comes in two flavours: (a) restriction of the acces= s > token regarding the resource server and (b) restriction of the id token > regarding the client. Obviously=2C it is necessary to have both of these > audience restrictions in place and to actually check them. > > The group then went into a discussion about the use of pseudonyms in > authentication and the problems deployments ran into when they used > pseudonyms together with a wide range of attributes that identified > users nevertheless. Phil suggested to produce a write-up about this topic= . > > Finally=2C the group started a discussion about potential actions for the > OAuth working groups. Two activities were mentioned=2C namely to produce > an IETF draft of the write-up Justin has prepared as a "formal" response > to the problems with authentication using OAuth and=2C as a second topic= =2C > potential re-chartering of the OAuth working group to work on some > solutions in this area. Hannes suggested to postpone these discussions > and to first finish the write-up Justin had distributed. > > Ciao > Hannes & Derek > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth ------------------------------ Message: 2 Date: Tue=2C 28 Oct 2014 10:41:04 +0000 From: Sergey Beryozkin To: oauth@ietf.org Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-json-web-token-27: (with DISCUSS and COMMENT) Message-ID: <544F72C0.8010403@gmail.com> Content-Type: text/plain=3B charset=3Dwindows-1252=3B format=3Dflowed Hi I've found 'none' to be a useful mechanism for using JWT representations as OAuth2 (bearer) tokens where JWT is turned into JWS with a none algorithm and then encrypted... Cheers=2C Sergey On 23/10/14 09:58=2C Nat Sakimura wrote: > I second John's message. There are many ways to achieve a desired level > of security and one of the most popular way is to delegate it to the > transport layer and use 'none' as the alg. If 'none' becomes non-MTI=2C > then it may cause a lot of interoperability issues down the road. > > Adding to it=2C JWT can be useful in other context than security as well. > As interoperability is one of the most important criteria=2C having 'none= ' > as MTI seems to be a reasonable idea to me. > > Nat > > 2014-10-22 16:44 GMT-05:00 John Bradley >: > > From a JWT perspective a number of applications including connect > allow unsecured JWT. > > I guess you are referring to sec 8 of JWT in the OAuth WG. Some of > the threads you mention were in the JOSE WG relating to the JWS spec > and if none should be included. > > To some extent the issues are not quite the same for the different > specs. > > SAML certainly allows for unsigned documents=2C those are used in a > lot of places. I imagine that a SAML library that could not process > unsigned messages would generally be considered broken. > That is not to say that it also needs to also support signed ones > and some number of trust models. > > It is the same for JWT as it lives at a similar conceptual level to > SAML assertions. > > It is better for interoperability to have all the JWT libs implement > "none"=2C so that it can be supported in the many cases it may be use= d > for processing JWT protected by transport or some other mechanism=2C > and reliably reject "none" when signatures are required. > > The JWT spec is not requiring JWS or JWE to implement support for > none=2C though likely life would be easier if they did support it. > > John B. > > > > On Oct 21=2C 2014=2C at 1:36 PM=2C Kathleen Moriarty > > wrote: > >> >> >> On Tue=2C Oct 21=2C 2014 at 9:16 AM=2C Stephen >> Farrell> >wrote: >> >> >> Hi Mike=2C >> >> I've one remaining discuss point and a comment. See below... >> >> On 14/10/14 13:50=2C Mike Jones wrote: >> > The proposed resolutions below have been included in the -28 >> draft. Hopefully you'll be able to clear your DISCUSSes on >> that basis. >> > >> > The String Comparison Rules in Section 7.3 have been >> expanded to talk about when the application may need >> canonicalization rules. >> > >> > Thanks again=2C >> > -- Mike >> > >> >> -----Original Message----- >> >> From: OAuth [mailto:oauth-bounces@ietf.org >> ] On Behalf Of Mike Jones >> >> Sent: Monday=2C October 06=2C 2014 7:20 PM >> >> To: Stephen Farrell=3B The IESG >> >> Cc:oauth-chairs@tools.ietf.org >> =3B draft-ietf-oauth-json-we= b- >> >>token@tools.ietf.org >> =3Boauth@ietf.org >> >> >> Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on >> draft-ietf-oauth-json- >> >> web-token-27: (with DISCUSS and COMMENT) >> >> >> >> Thanks for tracking all of this Stephen. Responses inline >> below... >> >> >> >>> -----Original Message----- >> >>> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie >> ] >> >>> Sent: Monday=2C October 06=2C 2014 2:43 PM >> >>> To: Mike Jones=3B The IESG >> >>> Cc:oauth-chairs@tools.ietf.org >> =3B draft-ietf-oauth-json-we= b- >> >>>token@tools.ietf.org >> =3Boauth@ietf.org >> >> >>> Subject: Re: Stephen Farrell's Discuss on >> draft-ietf-oauth-json-web-token-27: >> >>> (with DISCUSS and COMMENT) >> >>> >> >>> >> >>> Hi Mike=2C >> >>> >> >>> On 06/10/14 08:54=2C Mike Jones wrote: >> >>>> Thanks for your review=2C Stephen. I've added the working >> group to >> >>>> the thread so they're aware of your comments. >> >>>> >> >>>>> -----Original Message----- From: Stephen Farrell >> >>>>> [mailto:stephen.farrell@cs.tcd.ie >> ] Sent: Thursday=2C October >> 02=2C 2014 >> >>>>> 5:03 AM To: The IESG Cc:oauth-chairs@tools.ietf.org >> =3B >> >>>>> draft-ietf-oauth-json-web-token@tools.ietf.org >> Subject: Stephen >> >>>>> Farrell's Discuss on draft-ietf-oauth-json-web-token-27: >> (with >> >>>>> DISCUSS and COMMENT) >> >>>>> >> >>>>> Stephen Farrell has entered the following ballot >> position for >> >>>>> draft-ietf-oauth-json-web-token-27: Discuss >> >>>>> >> >>>>> When responding=2C please keep the subject line intact and >> reply to >> >>>>> all email addresses included in the To and CC lines. >> (Feel free to >> >>>>> cut this introductory paragraph=2C however.) >> >>>>> >> >>>>> >> >>>>> Please refer to >> >>>>>http://www.ietf.org/iesg/statement/discuss-criteria.htmlfor >> more >> >>>>> information about IESG DISCUSS and COMMENT positions. >> >>>>> >> >>>>> >> >>>>> The document=2C along with other ballot positions=2C can b= e >> found >> >>>>> here: >> >>>>>http://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-t= oken/ >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> ----------------------------------------------------------------= --- >> >>>>> -- >> >>>>> - >> >>>>> >> >>>>> >> >>> DISCUSS: >> >>>>> >> ----------------------------------------------------------------= --- >> >>>>> -- >> >>>>> - >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>> (1) 4.1.1 and elsewhere you say case-sensitive: the same >> thing I >> >>> raised wrt DNS >> >>>>> names for another JOSE spec - do you need to say those >> SHOULD be >> >>>>> [upper|lower]cased when used in these? >> >>>> >> >>>> I believe that somewhere we should say that if >> case-insensitive >> >>>> values=2C such as DNS names=2C are used when constructing >> "kid" values=2C >> >>>> that the application doing so needs to define a >> convention on the >> >>>> canonical case to use for the case-insensitive portions=2C >> such as >> >>>> lowercasing them. >> >>> >> >>> As that discussion's happening on the key draft=2C I'll >> clear it here >> >>> and trust you to fix if a change is the end result. >> >> >> >> Thanks >> >> np >> >> >> >> >>>>> (2) Section 8: Why is "none" MTI? That seems both broken >> and going >> >>>>> in the oppostite direction from other WGs and so should be >> >>>>> explicitly jusified I think. (If a good enough >> justification exists >> >>>>> that is.) >> >>>> >> >>>> It is MTI because there are several existing applications >> of JWTs in >> >>>> which both unsigned and signed representations of the >> JWTs are >> >>>> requirements. These include draft-ietf-oauth-token-exchang= e=2C >> >>>> draft-hunt-oauth-v2-user-a4c=2C and OpenID Connect. This >> is a pretty >> >>>> common pattern where you sign something if the recipient >> cares who >> >>>> made the statements and where you don't have to sign it >> either if >> >>>> the recipient doesn't care who made the statements >> >>> >> >>> I don't see how (non-)signers can divine non-verifier's >> wishes that >> >>> way. (Absent negotiation or a directory.) >> >> >> >> Sometimes it does occur via negotiation. For instance=2C in >> some protocols=2C at >> >> registration time=2C relying parties explicitly tell identity >> providers what algorithms >> >> are acceptable to them=2C which may include "none". No >> divination - explicit >> >> communication. >> >> >> >>>> or if it can tell from >> >>>> another secured aspect of the application protocol (typical= ly >> >>>> through the use of TLS) who made the statements. In the >> TLS case=2C >> >>>> the server authentication step makes a signature step >> unnecessary=2C >> >>>> so an Unsecured JWT is fine there. >> >>> >> >>> That's arguable IMO. >> >> >> >> I agree that it's application and context-dependent whether >> it's OK or not. The >> >> point is that there exist some circumstances in which it is >> OK=2C and this feature is >> >> being used in some of those cases. >> >> >> >>> I think I'll look back over the wg thread and either hold >> my nose or >> >> >> >> This issue was tracked >> ashttp://trac.tools.ietf.org/wg/jose/trac/ticket/36. >> >> Karen O'Donoghue recorded this conclusion in the tracker >> "Note: There was >> >> extensive discussion on the mailing list=2C and the rough >> consensus of the working >> >> group was to leave "none" in the document." >> >> >> >> Discussion threads on this topic include: >> >> [jose] #36: Algorithm "none" should be >> removedhttp://www.ietf.org/mail- >> >> archive/web/jose/current/msg02911.html - Began Jul 31=2C >> 2013 (91 messages) >> >> [jose] Text about applications and >> "alg":"none"http://www.ietf.org/mail- >> >> archive/web/jose/current/msg03321.html - Began Sep 3=2C 2013 >> (5 messages) >> >> >> >> This issue was a topic of a special working group call on >> Aug 19=2C 2013. The text >> >> discussed in the last thread and published >> athttps://tools.ietf.org/html/draft- >> >> ietf-jose-json-web-algorithms-33#section-8.5 (Unsecured JWS >> Security >> >> Considerations) was the result of the working group's >> decisions resulting from all >> >> of this discussion. >> >> Thanks for all the pointers above. I read through all the (many!= ) >> Aug 19 mails and most of the `"none" should be removed" thread. >> >> So I do see that there was rough consensus to keep "none" in >> the draft and can (with difficulty=3B-) hold my nose and let tha= t >> pass. I do not however=2C see that there was consensus to make >> "none" MTI for this draft. I did see a bit of haggling about >> this draft vs. JWS but still do not see why none ought be MTI >> here. >> >> >> >> >>>>> (3) Section 12: another way to handle privacy is to not in= clude >> >>>>> sensitive data - I think you ought mention that as a bit o= f thought >> >>>>> along those lines can be much simpler than putting in plac= e the key >> >>>>> management to handle thoughtlessly included PII. >> >>>> >> >>>> We can include a discussion of that point=2C >> >>> >> >>> Great. "Just say no" is workable here:-) I'll clear when we = get such text. >> >>> >> >>>> but sometimes the very >> >>>> point of a JWT is to securely deliver PII from a verifiable= party to >> >>>> an intended party with appropriate rights to receive it. >> >>> >> >>> Hmm. Its a moot point (so let's not argue it) but I wonder h= ow often >> >>> PII is really needed for authorization with oauth. My guess = would be >> >>> that its needed far less often than its found to be profitab= le >> >>> perhaps=2C or that carelessness plays a big role in using PI= I for such purposes. >> >> I've cleared on this as you added this text: >> >> "Of course=2C including >> only necessary privacy-sensitive information in a JWT is >> the most >> basic means of minimizing any potential privacy issues." >> >> That seems to me like a fairly offputting way to phrase it. I'd >> suggest instead: >> >> "Omitting privacy-sensitive information from a JWT is the >> simplest way of minimizing privacy issues." >> >> >> I like this wording suggestion=2C thanks. >> >> >> Cheers=2C >> S. >> >> PS: I didn't check the comments. >> >> >>> >> >>> S. >> >>> >> >>> >> >>> >> >>>> >> >>>>> >> ----------------------------------------------------------------= --- >> >>>>> -- >> >>>>> - >> >>>>> >> >>>>> >> >>> COMMENT: >> >>>>> >> ----------------------------------------------------------------= --- >> >>>>> -- >> >>>>> - >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>> - abstract: 2nd sentence isn't needed here=2C in intro would >> be fine. >> >>>> >> >>>> I don't know - I think it's a big deal that the claims can = be >> >>>> digitally signed or MACed and/or encrypted. That's the >> reason we >> >>>> have JWTs=2C rather than just JSON. >> >>>> >> >>>>> - 4.1.7: maybe worth adding that jti+iss being unique >> enough is not >> >>>>> sufficient and jti alone has to meet that need. In X.509 t= he >> >>>>> issuer/serial has the equivalent property so someone >> might assume >> >>>>> sequential jti values starting at 0 are ok. >> >>>> >> >>>> Makes sense to add a warning of some kind along these >> lines. I >> >>>> think I know the reasons you say that=2C but can you expand >> on that >> >>>> thought a bit before I take a stab on writing this up? For >> >>>> instance=2C while normally true=2C I don't think your >> observation is >> >>>> true if a relying party will only accept tokens from a >> single issuer. >> >>>> >> >>>>> - section 6: yuk >> >>>>> >> >>>>> - again I think the secdir comments are being handled by >> Kathleen >> >>>>> and the authors. >> >>>> >> >>>> Again=2C this is there because multiple applications asked >> for the >> >>>> ability to represent content that is optionally signed=2C >> sometimes >> >>>> securing it another way=2C such as with TLS. JWTs are used >> specific >> >>>> application protocol contexts - not in isolation. >> >>>> >> >>>> Thanks again=2C -- Mike >> >>>> >> >> _______________________________________________ >> >> OAuth mailing list >> >>OAuth@ietf.org >> >>https://www.ietf.org/mailman/listinfo/oauth >> > >> >> >> >> >> -- >> >> Best regards=2C >> Kathleen > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > -- > Nat Sakimura (=3Dnat) > Chairman=2C OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > > _______________________________________________ > 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=2C Vol 72=2C Issue 78 ************************************* --_abb7de1d-18fc-4472-aa4c-78a0a5b0e7cd_ MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"


Dikirim dari ponsel cerdas BlackBerry 10 saya dengan jaringan Telkomsel.
Dari: oauth-request@ietf.org
Terkirim: Rabu=2C 29 Oktober 2014 02.01
Ke: oauth@ietf.org
Balas Ke: oauth@ietf.org
Perihal: OAuth Digest=2C Vol 72=2C Issue 78

Send OAuth mailing list submissions to
 =3B =3B =3B =3B =3B =3B =3B oauth@ietf.org

To subscribe or unsubscribe via the World Wide Web=2C visit
 =3B =3B =3B =3B =3B =3B =3B https://www.ietf.org/mailman/listinfo= /oauth
or=2C via email=2C send a message with subject or body 'help' to
 =3B =3B =3B =3B =3B =3B =3B oauth-request@ietf= .org

You can reach the person managing the list at
 =3B =3B =3B =3B =3B =3B =3B oauth-owner@ietf.o= rg

When replying=2C please edit your Subject line so it is more specific
than "=3BRe: Contents of OAuth digest..."=3B


Today's Topics:

 =3B =3B 1. Re: Notes from 2nd "=3BOAuth &=3B Authentication= "=3B Conference =3B =3B =3B Call
 =3B =3B =3B =3B =3B (Richer=2C Justin P.)
 =3B =3B 2. Re: Stephen Farrell's Discuss on
 =3B =3B =3B =3B =3B draft-ietf-oauth-json-web-token-27= : (with DISCUSS and COMMENT)
 =3B =3B =3B =3B =3B (Sergey Beryozkin)


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

Message: 1
Date: Mon=2C 27 Oct 2014 23:21:21 +=3B0000
From: "=3BRicher=2C Justin P."=3B <=3Bjricher@mitre.org>=3B
To: Hannes Tschofenig <=3Bhannes.tschofenig@gmx.net>=3B
Cc: "=3Boauth@ietf.org"=3B <=3Boauth@ietf.org>=3B
Subject: Re: [OAUTH-WG] Notes from 2nd "=3BOAuth &=3B Authentication= "=3B
 =3B =3B =3B =3B =3B =3B =3B Conference =3B=  =3B =3B =3B =3B Call
Message-ID: <=3BB18173FA-7AD9-40A7-98AF-8D2A4AED744D@mitre.org>=3B
Content-Type: text/plain=3B charset=3D"=3Bus-ascii"=3B

I've been incorporating peoples' feedback into the proposed oauth.net page= =2C and the current state is here:

https://github.com/jricher/oauth.net/blob/authenticat= ion/articles/authentication.php

Commentary has slowed down and I think the document's in reasonable. I woul= d like to publish this as a draft version on oauth.net in the very near fut= ure (like=2C this week)=2C so get comments and feedback to me on this soon.= I'm going to be at IIW all week if anyone wants to back me into a corner and talk about this.

 =3B-- Justin

On Oct 16=2C 2014=2C at 12:54 PM=2C Hannes Tschofenig <=3Bhannes.tschofen= ig@gmx.net>=3B wrote:

>=3B Participants:
>=3B
>=3B * Brian Campbell
>=3B * John Bradley
>=3B * Derek Atkins
>=3B * Phil Hunt
>=3B * William Kim
>=3B * Josh Mandel
>=3B * Hannes Tschofenig
>=3B
>=3B
>=3B Notes:
>=3B
>=3B Justin distributed a draft writeup and explained the reasoning behin= d
>=3B it. The intended purpose is to put the write-up (after enough review= ) on
>=3B oauth.net. See attachments. Justin solicited feedback from the
>=3B conference call participants and from the working group.
>=3B
>=3B One discussion item was specifically related to the concept of audie= nce
>=3B restrictions=2C which comes in two flavours: (a) restriction of the = access
>=3B token regarding the resource server and (b) restriction of the id to= ken
>=3B regarding the client. Obviously=2C it is necessary to have both of t= hese
>=3B audience restrictions in place and to actually check them.
>=3B
>=3B The group then went into a discussion about the use of pseudonyms in=
>=3B authentication and the problems deployments ran into when they used<= br> >=3B pseudonyms together with a wide range of attributes that identified<= br> >=3B users nevertheless. Phil suggested to produce a write-up about this = topic.
>=3B
>=3B Finally=2C the group started a discussion about potential actions fo= r the
>=3B OAuth working groups. Two activities were mentioned=2C namely to pro= duce
>=3B an IETF draft of the write-up Justin has prepared as a "=3Bforma= l"=3B response
>=3B to the problems with authentication using OAuth and=2C as a second t= opic=2C
>=3B potential re-chartering of the OAuth working group to work on some >=3B solutions in this area. Hannes suggested to postpone these discussio= ns
>=3B and to first finish the write-up Justin had distributed.
>=3B
>=3B Ciao
>=3B Hannes &=3B Derek
>=3B <=3BAuthentication with OAuth 2.doc>=3B<=3BAuthentication with= OAuth 2.html>=3B<=3BAuthentication with OAuth 2.pdf>=3B_____________= __________________________________
>=3B OAuth mailing list
>=3B OAuth@ietf.org
>=3B https://www.= ietf.org/mailman/listinfo/oauth



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

Message: 2
Date: Tue=2C 28 Oct 2014 10:41:04 +=3B0000
From: Sergey Beryozkin <=3Bsberyozkin@gmail.com>=3B
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on
 =3B =3B =3B =3B =3B =3B =3B draft-ietf-oauth-j= son-web-token-27: (with DISCUSS and COMMENT)
Message-ID: <=3B544F72C0.8010403@gmail.com>=3B
Content-Type: text/plain=3B charset=3Dwindows-1252=3B format=3Dflowed

Hi

I've found 'none' to be a useful mechanism for using JWT representations as OAuth2 (bearer) tokens where JWT is turned into JWS with a none
algorithm and then encrypted...

Cheers=2C Sergey
On 23/10/14 09:58=2C Nat Sakimura wrote:
>=3B I second John's message. There are many ways to achieve a desired le= vel
>=3B of security and one of the most popular way is to delegate it to the=
>=3B transport layer and use 'none' as the alg. If 'none' becomes non-MTI= =2C
>=3B then it may cause a lot of interoperability issues down the road. >=3B
>=3B Adding to it=2C JWT can be useful in other context than security as = well.
>=3B As interoperability is one of the most important criteria=2C having = 'none'
>=3B as MTI seems to be a reasonable idea to me.
>=3B
>=3B Nat
>=3B
>=3B 2014-10-22 16:44 GMT-05:00 John Bradley <=3Bve7jtb@ve7jtb.com
>=3B <=3Bmailto:ve7jtb@ve7jtb.com<= /a>>=3B>=3B:
>=3B
>=3B =3B =3B =3B =3B =3B From a JWT perspective a num= ber of applications including connect
>=3B =3B =3B =3B =3B allow unsecured JWT.
>=3B
>=3B =3B =3B =3B =3B I guess you are referring to sec 8 o= f JWT in the OAuth WG. =3B Some of
>=3B =3B =3B =3B =3B the threads you mention were in the = JOSE WG relating to the JWS spec
>=3B =3B =3B =3B =3B and if none should be included.
>=3B
>=3B =3B =3B =3B =3B To some extent the issues are not qu= ite the same for the different
>=3B =3B =3B =3B =3B specs.
>=3B
>=3B =3B =3B =3B =3B SAML certainly allows for unsigned d= ocuments=2C those are used in a
>=3B =3B =3B =3B =3B lot of places. =3B I imagine tha= t a SAML library that could not process
>=3B =3B =3B =3B =3B unsigned messages would generally be= considered broken.
>=3B =3B =3B =3B =3B That is not to say that it also need= s to also support signed ones
>=3B =3B =3B =3B =3B and some number of trust models.
>=3B
>=3B =3B =3B =3B =3B It is the same for JWT as it lives a= t a similar conceptual level to
>=3B =3B =3B =3B =3B SAML assertions.
>=3B
>=3B =3B =3B =3B =3B It is better for interoperability to= have all the JWT libs implement
>=3B =3B =3B =3B =3B "=3Bnone"=3B=2C so that it c= an be supported in the many cases it may be used
>=3B =3B =3B =3B =3B for processing JWT protected by tran= sport or some other mechanism=2C
>=3B =3B =3B =3B =3B and reliably reject "=3Bnone&quo= t=3B when signatures are required.
>=3B
>=3B =3B =3B =3B =3B The JWT spec is not requiring JWS or= JWE to implement support for
>=3B =3B =3B =3B =3B none=2C =3B though likely life w= ould be easier if they did support it.
>=3B
>=3B =3B =3B =3B =3B John B.
>=3B
>=3B
>=3B
>=3B =3B =3B =3B =3B On Oct 21=2C 2014=2C at 1:36 PM=2C K= athleen Moriarty
>=3B =3B =3B =3B =3B <=3Bkathleen.moriarty.ietf@gmail.c= om
>=3B =3B =3B =3B =3B <=3Bmailto:kathleen.moriarty.ietf@gmail.com>=3B>= =3B wrote:
>=3B
>=3B>=3B
>=3B>=3B
>=3B>=3B =3B =3B =3B =3B On Tue=2C Oct 21=2C 2014 at 9:= 16 AM=2C Stephen
>=3B>=3B =3B =3B =3B =3B Farrell<=3Bstephen.farrell@c= s.tcd.ie
>=3B>=3B =3B =3B =3B =3B <=3Bmailto:stephen.farrell@cs.tcd.ie>=3B>=3Bwrote:=
>=3B>=3B
>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B Hi Mike=2C
>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B I've one remaining discuss point and a comment. See below...
>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B On 14/10/14 13:50=2C Mike Jones wrote:
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B The proposed resolutions below have been included in the -28
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B draft. =3B Hopefully you'll be able to clear your DISCUSSes on
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B that basis.
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B The String Comparison Rules in Section 7.3 have been
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B expanded to talk about when the application may need
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B canonicalization rules.
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B =3B =3B =3B =3B =3B =3B =3B =3B&= nbsp=3B =3B =3B =3B =3B =3B =3B =3B =3B&nbs= p=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B Thanks again=2C
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B =3B =3B =3B =3B =3B =3B =3B =3B&= nbsp=3B =3B =3B =3B =3B =3B =3B =3B =3B&nbs= p=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B -- Mike
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B -----Original Message-----
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B From: OAuth [mailto:oauth-bounces@ietf.or= g
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B <=3Bmailto:oauth-bounces@ie= tf.org>=3B] On Behalf Of Mike Jones
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B Sent: Monday=2C October 06=2C 2014 7:20 PM
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B To: Stephen Farrell=3B The IESG
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B Cc:oauth-chairs@tools.ietf.org
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B <=3Bmailto:oauth-chair= s@tools.ietf.org>=3B=3B draft-ietf-oauth-json-web-
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3Btoken@tools.ietf.org
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B <=3Bmailto:token@tools.ietf.o= rg>=3B=3Boauth@ietf.org
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B <=3Bmailto:oauth@ietf.org>=3B=
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B draft-ietf-oauth-json-
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B web-token-27: (with DISCUSS and COMMENT)
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B Thanks for tracking all of this Stephen. =3B Responses= inline
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B below...
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B -----Original Message-----
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B From: Stephen Farrell [mailto:steph= en.farrell@cs.tcd.ie
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B <=3Bmailto:stephen.farre= ll@cs.tcd.ie>=3B]
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B Sent: Monday=2C October 06=2C 2014 2:43 PM
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B To: Mike Jones=3B The IESG
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B Cc:oauth-chairs@tools.ietf.org
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B <=3Bmailto:oauth-chair= s@tools.ietf.org>=3B=3B draft-ietf-oauth-json-web-
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3Btoken@tools.ietf.org
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B <=3Bmailto:token@tools.ietf.o= rg>=3B=3Boauth@ietf.org
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B <=3Bmailto:oauth@ietf.org>=3B=
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B Subject: Re: Stephen Farrell's Discuss on
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B draft-ietf-oauth-json-web-token-27:
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B (with DISCUSS and COMMENT)
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B Hi Mike=2C
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B On 06/10/14 08:54=2C Mike Jones wrote:
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B Thanks for your review=2C Stephen. =3B I'v= e added the working
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B group to
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B the thread so they're aware of your comments.<= br> >=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B -----Original Message----- From: Stephen= Farrell
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B [mailto:stephen.farrell= @cs.tcd.ie
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B <=3Bmailto:stephen.farre= ll@cs.tcd.ie>=3B] Sent: Thursday=2C October
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B 02=2C 2014
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B 5:03 AM To: The IESG Cc:oauth-chairs@too= ls.ietf.org
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B <=3Bmailto:oauth-chair= s@tools.ietf.org>=3B=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B draft-ietf-oauth-json-web-token@tools.ie= tf.org
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B <=3Bmailto:token@tools.ietf.o= rg>=3BSubject: Stephen
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B Farrell's Discuss on draft-ietf-oauth-js= on-web-token-27:
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B (with
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B DISCUSS and COMMENT)
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B Stephen Farrell has entered the followin= g ballot
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B position for
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B draft-ietf-oauth-json-web-token-27: Disc= uss
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B When responding=2C please keep the subje= ct line intact and
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B reply to
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B all email addresses included in the To a= nd CC lines.
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B (Feel free to
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B cut this introductory paragraph=2C howev= er.)
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B Please refer to
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3Bhttp://www.ietf.org/iesg/statement/discuss-c= riteria.htmlfor
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B more
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B information about IESG DISCUSS and COMME= NT positions.
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B The document=2C along with other ballot = positions=2C can be
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B found
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B here:
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3Bhttp://datatracker.ietf.org/doc/draft-i= etf-oauth-json-web-token/
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B -------------------------------------------------------------------
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B --
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B -
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B DISCUSS:
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B -------------------------------------------------------------------
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B --
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B -
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B (1) 4.1.1 and elsewhere you say case-sensitive: the = same
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B thing I
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B raised wrt DNS
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B names for another JOSE spec - do you nee= d to say those
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B SHOULD be
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B [upper|lower]cased when used in these? >=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B I believe that somewhere we should say that if=
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B case-insensitive
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B values=2C such as DNS names=2C are used when c= onstructing
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B "=3Bkid"=3B values=2C
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B that the application doing so needs to define = a
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B convention on the
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B canonical case to use for the case-insensitive= portions=2C
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B such as
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B lowercasing them.
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B As that discussion's happening on the key draft=2C I= 'll
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B clear it here
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B and trust you to fix if a change is the end result.<= br> >=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B Thanks
>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B np
>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B (2) Section 8: Why is "=3Bnone"= =3B MTI? That seems both broken
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B and going
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B in the oppostite direction from other WG= s and so should be
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B explicitly jusified I think. (If a good = enough
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B justification exists
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B that is.)
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B It is MTI because there are several existing a= pplications
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B of JWTs in
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B which both unsigned and signed representations= of the
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B JWTs are
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B requirements. =3B These include draft-ietf= -oauth-token-exchange=2C
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B draft-hunt-oauth-v2-user-a4c=2C and OpenID Con= nect. =3B This
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B is a pretty
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B common pattern where you sign something if the= recipient
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B cares who
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B made the statements and where you don't have t= o sign it
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B either if
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B the recipient doesn't care who made the statem= ents
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B I don't see how (non-)signers can divine non-verifie= r's
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B wishes that
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B way. (Absent negotiation or a directory.)
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B Sometimes it does occur via negotiation. =3B For insta= nce=2C in
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B some protocols=2C at
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B registration time=2C relying parties explicitly tell ident= ity
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B providers what algorithms
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B are acceptable to them=2C which may include "=3Bnone&q= uot=3B. =3B No
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B divination - explicit
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B communication.
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B or if it can tell from
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B another secured aspect of the application prot= ocol (typically
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B through the use of TLS) who made the statement= s. =3B In the
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B TLS case=2C
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B the server authentication step makes a signatu= re step
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B unnecessary=2C
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B so an Unsecured JWT is fine there.
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B That's arguable IMO.
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B I agree that it's application and context-dependent whethe= r
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B it's OK or not. =3B The
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B point is that there exist some circumstances in which it i= s
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B OK=2C and this feature is
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B being used in some of those cases.
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B I think I'll look back over the wg thread and either= hold
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B my nose or
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B This issue was tracked
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B ashttp://trac.tools.ietf.org/wg/jose/trac/ticket/36.
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B Karen O'Donoghue recorded this conclusion in the tracker >=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B "=3BNote: There was
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B extensive discussion on the mailing list=2C and the rough<= br> >=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B consensus of the working
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B group was to leave "=3Bnone"=3B in the document.&q= uot=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B Discussion threads on this topic include:
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B [jose] #36: Algorithm "=3Bnone"=3B should be
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B removedhttp://www.ietf.org/mail-
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B archive/web/jose/current/msg02911.html - Began Jul 31=2C >=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B 2013 =3B (91 messages)
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B [jose] Text about applications and
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B "=3Balg"=3B:"=3Bnone"=3Bhttp://www.ietf.org/mail-
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B archive/web/jose/current/msg03321.html - Began Sep 3=2C 20= 13
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B (5 messages)
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B This issue was a topic of a special working group call on<= br> >=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B Aug 19=2C 2013. =3B The text
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B discussed in the last thread and published
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B athttps://tools.ietf.org/html/draft-
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B ietf-jose-json-web-algorithms-33#section-8.5 (Unsecured JW= S
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B Security
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B Considerations) was the result of the working group's
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B decisions resulting from all
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B of this discussion.
>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B Thanks for all the pointers above. I read through all the (many!)
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B Aug 19 mails and most of the `"=3Bnone"=3B should be removed&qu= ot=3B thread.
>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B So I do see that there was rough consensus to keep "=3Bnone"=3B= in
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B the draft and can (with difficulty=3B-) hold my nose and let that
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B pass. I do not however=2C see that there was consensus to make
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B "=3Bnone"=3B MTI for this draft. I did see a bit of haggling ab= out
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B this draft vs. JWS but still do not see why none ought be MTI
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B here.
>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B (3) Section 12: another way to handle pr= ivacy is to not include
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B sensitive data - I think you ought menti= on that as a bit of thought
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B along those lines can be much simpler th= an putting in place the key
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B management to handle thoughtlessly inclu= ded PII.
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B We can include a discussion of that point=2C >=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B Great. "=3BJust say no"=3B is workable here:= -) I'll clear when we get such text.
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B but sometimes the very
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B point of a JWT is to securely deliver PII from= a verifiable party to
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B an intended party with appropriate rights to r= eceive it.
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B Hmm. Its a moot point (so let's not argue it) but I = wonder how often
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B PII is really needed for authorization with oauth. M= y guess would be
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B that its needed far less often than its found to be = profitable
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B perhaps=2C or that carelessness plays a big role in = using PII for such purposes.
>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B I've cleared on this as you added this text:
>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B "=3BOf course=2C including
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B only necessary privacy-sensitive information in= a JWT is
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B the most
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B basic means of minimizing any potential privacy= issues."=3B
>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B That seems to me like a fairly offputting way to phrase it. I'd
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B suggest instead:
>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B "=3BOmitting privacy-sensitive information from a JWT is the
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B simplest way of minimizing privacy issues."=3B
>=3B>=3B
>=3B>=3B
>=3B>=3B =3B =3B =3B =3B I like this wording suggestion= =2C thanks.
>=3B>=3B
>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B Cheers=2C
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B S.
>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B PS: I didn't check the comments.
>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B S.
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B -------------------------------------------------------------------
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B --
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B -
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B COMMENT:
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B -------------------------------------------------------------------
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B --
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B -
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B - abstract: 2nd sentence isn't needed here=2C in int= ro would
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B be fine.
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B I don't know - I think it's a big deal that th= e claims can be
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B digitally signed or MACed and/or encrypted.&nb= sp=3B That's the
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B reason we
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B have JWTs=2C rather than just JSON.
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B - 4.1.7: maybe worth adding that jti+= =3Biss being unique
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B enough is not
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B sufficient and jti alone has to meet tha= t need. In X.509 the
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B issuer/serial has the equivalent propert= y so someone
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B might assume
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B sequential jti values starting at 0 are = ok.
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B Makes sense to add a warning of some kind alon= g these
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B lines. =3B I
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B think I know the reasons you say that=2C but c= an you expand
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B on that
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B thought a bit before I take a stab on writing = this up? =3B For
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B instance=2C while normally true=2C I don't thi= nk your
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B observation is
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B true if a relying party will only accept token= s from a
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B single issuer.
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B - section 6: yuk
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B - again I think the secdir comments are = being handled by
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B Kathleen
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B>=3B and the authors.
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B Again=2C this is there because multiple applic= ations asked
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B for the
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B ability to represent content that is optionall= y signed=2C
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B sometimes
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B securing it another way=2C such as with TLS.&n= bsp=3B JWTs are used
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B specific
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B application protocol contexts - not in isolati= on.
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B Thanks again=2C -- Mike
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B>=3B>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B _______________________________________________
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3B OAuth mailing list
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3BOAuth@ietf.org <=3Bmail= to:OAuth@ietf.org>=3B
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B>=3Bhtt= ps://www.ietf.org/mailman/listinfo/oauth
>=3B>=3B =3B =3B =3B =3B =3B =3B =3B = =3B >=3B
>=3B>=3B
>=3B>=3B
>=3B>=3B
>=3B>=3B
>=3B>=3B =3B =3B =3B =3B --
>=3B>=3B
>=3B>=3B =3B =3B =3B =3B Best regards=2C
>=3B>=3B =3B =3B =3B =3B Kathleen
>=3B
>=3B
>=3B =3B =3B =3B =3B ____________________________________= ___________
>=3B =3B =3B =3B =3B OAuth mailing list
>=3B =3B =3B =3B =3B OAuth@ietf.org <=3Bmailto:OAuth@ietf.org>=3B
>=3B =3B =3B =3B =3B https://www.ietf.org/mailman/listinfo/oauth
>=3B
>=3B
>=3B
>=3B
>=3B --
>=3B Nat Sakimura (=3Dnat)
>=3B Chairman=2C OpenID Foundation
>=3B http://nat.sakimura.org/ >=3B @_nat_en
>=3B
>=3B
>=3B _______________________________________________
>=3B OAuth mailing list
>=3B OAuth@ietf.org
>=3B https://www.= ietf.org/mailman/listinfo/oauth
>=3B



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

Subject: Digest Footer

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


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

End of OAuth Digest=2C Vol 72=2C Issue 78
*************************************
--_abb7de1d-18fc-4472-aa4c-78a0a5b0e7cd_-- --===============1908545373== Content-Type: image/png MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="IMG_20141026_083233_edit_edit_edit.png" iVBORw0KGgoAAAANSUhEUgAAAtAAAALQCAIAAAA2NdDLAAAgAElEQVR4nOy9WY8bSXYGes6JJReS VaWSWmr3NmPPxbwY98m4f8E/3IBtwE9jDAboQdsDudfpltQttaqKZC4R9+FkHgYzk8nkzmrxQ4+G lUxGREbG8sVZ8f/7f/8JALz3cDR4PF5djZoDbFcCYkfjpUznXF0yBf9u072ISETtSlcW5Umea0h1 YZnaFwCglOJ/tdZKKf4zTVO+h4iIyBhDRPytJoiiaDIZp2l6c3PzySefPHv2LEkSuSGsjoi01gCg kADAo5OvlFLWWq112CRrbZQmSZKgIrnoAIho1fAhos63Uz+wXvHFovzZLMvzXGv9008/lWX54sWL ZDRaWSCXitj4N2jtLnOKvPd5nr99+/brr7/+l3/5FyI62iR1K657bI9/BADw1LqXYMVkuWAtdlmg 9tiGzs/nAOdWjdA12G/Haq3fvHr95z//+euXL//1X//VKB1FkVVa6uJ/3ZaTYINnlIfy3pdlqbwr igI9FEXhwRVF4VwBAOShLMvXr3783//9XwL3xz/+8emT27Is2+U45/i6PEW4s/BO19+SjudxDgBW rcIX7A2IeLSVt3PnW/sTjZo/MNvQWhtjlFLGGGstBmDeYIxBRE1grWW2cX19PR6PoygyxgCAUKVN Wy7YdF3YvYfDKcSbfZ7n6Um3TGZ4Dep2wQVHACKeG884Q2itvfd8QuPT5nE6TZY7rk5eVmMZJKKy xQx4DXdFxu3P87xRZmd1A5+LC+m8mYiccxfCcb7w3sv7C8dT43XKQFm76YY3VNSEPACQB0S0WhOR 1spaw7TDWmuthZozEZG11hijtSaiJEmeP3/+9MmTq6urNE0nk4lSahXVUEgEQe1BMxAAgysAS5IB 9ACBUAwRYcVT7sg5QsLBa4dzjh/GwRr+hNh5wx6WHhYX7V7O7nDOeYQzacwFR8CFc6wF9w+f08q8 OH4D2u8IEcOFp39V3FpWtB2I6AMiHMecPDU/GHp/z7BoKGsa8pJAj7C+siU1itYAAOgQUblqY+Mj NVMN/hcRWZ7B8g9bg4iePHny2WefPbu9vbq6Yp7B5Vcldz3Iog2t55Wp65wrioIr7X6EQwodmIZ7 75VSp1ptQ1oZKqd6Tg+HbgyjLMsL4figcOEcPeDdmpc+5xwrPfnDCVtFRODKVd8iYp7nWZZZfZpG 7odwbDYoW/d+4LrejR6/IbVb6FBw5SsIyvdyhaqNg5RSiSemFFEURVHEShMiUkiIiB60UizbiOM4 SZI4jrXW19dXk9EoTRKtVEgyVj7O0nX03hdFobUmQPRV83mBY/Vhtb8ed2gQUZZlRVFEUST2K9th X6OahUx7L7YHTTONusYjn4c+WPS/4hMyzuPX3on+49nWv+1BZ7F8kcW9AOAY1ZHw2DtaSA0btSMi +VpWK/YZmq3ylmjH8Ane/4BNa7agWL37ADpaCbu8xVVqiN8AVo3vHqLNchH+lVKKHLAkYzKZiLEq 38OiDq31ZDIZj8fj8fjq6urm5iZN0ziO4jgmRKXU5rYjCABZlokkgwclOuecy7JsNpvdPL2VB1z8 puvxB1faB+89P/LDw0OnQrSn6gONrvl8vtGBaV/1dpbCkqdWLauka7+d+XUSnDPn2AiHaOrWnbML U2lDJqYsmOI9cOj9ZRCvqu8hIlcZ6SMizmYzAIiiaDwe84xuI7QklQLbB92BELGo9/4DUqkcE0cY cK0qXMtEw7WbUVt/AhEg8p9eKeYWhgiDWYSjUcp2G8w2kiQZjUZJEmut+LeKf7lwqHHQ9+yh0w3O ZrP5fM4UJ7SCZqFfURSkl6T3hz418HN47+fzOatUTqs+QEQmYQ0Jx6kQeGBdcMEHDT4GCM8Q+a5z DkidXKvCC7JjxYrHhpSYFzeRyqwq5BCT/UI49gzeO2s7SJBz3u57Zf/rD2qs/hSRAyJW/qjB9lnT juoeDWCMGY1GjVmUJEmaplEUCeGw1kZRxGIP3pIVEXumrG6YIJyE6JxjbSJrLmSWZlmWZVkcx/Lb hXvwoK7aEkqpsvQQqGYv9goNsMz40i0XXBCCl01fnrXC0XvPKnU2U2NBslGaJbsQkI+DnisuhGNv 4A2y3h2HGnIOQf8ICMN1YCXV8IiVToSIjFEA0EkLWEphHRhjCJG9UwAgiqI4jm+fPJlMJtba0WjE zEPcZZVSRmujtSFlSHagfsXKEuEo5pkvymw6uxqNAaDwjmdCURTMRUJKtCj98GBx4rLp66qlZFWL dm/poq/iON65tD2Ah9nFbvSCC8IdmrUSRFSWjq+0luvzIiK8zBJRURRG6VAewy1fK8tsr/DDOcqF cOwBsjUG/c5hmroFa1sEmcAV5uK8+tdqDcJ6y6dltBUEXCZf1G7Jt5b9U548efLkyZObmxtjDPMP No9iwsE2H7BsDrKq8dInjeui8qy+Jiq9W/HbQKVyeN5RmX+dGohYlmWSJKduyAUXfNDoXN/4ophB FEVxaE36juDFNo5jPtS9fv36808/g1pCwwE5+te9VQ94IRynwSpawBAiuZE6vHME8Itn91SmF1qx naMK2EYVp0uuhD/ni/whKj0iagQFPrFmNBpNJpOnt8w3bphhiDE2IioERCDvyDsAh+hD1yNqMILF N8tkwoM4p0C9uXIsyxJ84U+237e761RIkuTdu3dyIjlJG858Db3gghOiKIo8z+V8QkRlWZ75lOGD YlEUd3d3fEVrPZ1OIeANjUcYaEQ/BBfCsWf0cI7QKKFtBrwKst80dh2xw6jiUZKTP5lJaK1EwiG1 yz1iN4SItqhmi9Z6PB5fX19fX1/f3t5eX1+naSrSkXDAUX8c8QHgMqV5HjwiAgL7vJxkf3XOibTm HCQc/NKVUuw/vGNpw9/XWa+XF1xwNijLkmNv5HleS2sP7qKyHUJBcijt5kVmx8KHSz4uhOME6B+R jW9X7b5YBxrn8FyKmDSgKFBqmcSCiMhvWWIhlCX1AAAchOPZR7e3t7ccrdwYE8e2q1VeaUTySB7Q cbhSABFXrKfD3ntjlY10FBsPS9yLCFhD2v6Jl9JXd9ducACoNQG4+j8OU7bi9jURR/bDmXanGhdc cMGBwPGEoHaLdf7ELipD0Di+Zlm2e4Gd130r68qHuJZ1youOibWMciAjYcJRa0aYWfvad6RWqwSA ZbkI+1sqpSbaAMB4PI7j+Pb29tmzZ1dXV5wnBQL3ljYT6rHeCK+3e5iVSpKoBQCQKZQi9trqV04d FDx5VnmoD8F+HfF3FybtBWdi13LBBWeI+Xwe26h9/RxmbgNCDqKoo8GHxqEIR99u0fVNZ9zuDcpc ATxFNGjgs36rTl9WpBJ9y9Bh6T6g/mHqgWUKWvnEaFzKKwsK0JCSeORIHhEX1XlAcBrJIGjwSqO1 ypCy1o5Gyc3NzWQyYmcUYxQAN1i2mWYISmMMgJfwG8tfh1FAmn3hfakUKkMendYEAIV3zhWqCtwX uNqGmUi7eqXxbtvjpxoDHT+t2hk00gFgHFsJG3hyjwytNfALHDKE97S4tU8rDuDh4QG8V0hhSNvT JX7+oLH1Nrb7Stiu+qyis6wVrO6tIs/LOBBAmRf5PEtNBAC+NVFP+LL6C0/TdOD+uMtLb6hsTinh OKuRehzsckbEwO2W061pXcWckQGBCKIrqU00mAosnFCIKpWKMcZYpbXWqJMk4UgbHNqcT9U92+1a 8UZIg9pPzTIASbFIRN75sixtFLGx99Y7fUO6sNFsZxsO7tIdT/Pe+923/12kLHvHBzhbL3iM2I5z bEoLMDgkczwhvn6e+pTwqXl5n8/nO6ZuGI6Q1nyIKpWjgAA8NQ7fwec+AZD3irq8sKBKH8/7PBEp hZrE39UBANIip3k99Nm2o24WodJoIx3HMXu6GmNSVGmajkZpksRRZI3RSpGEE100YHlOEiEAhwMX i1S5ExDBi/CgleeFFMZJNMtmiKAUQRV3qxR9ysreOTAkuGdtR9JPO3o1X17B1jIAj+DBlf5MZAhU iz1oWf7hOJfvKZp0wQVHQ2eiKiJSSJGx5KHMcrneNLrCrY8um04svyQPXgHeQbI8P8l5ZlfC8cGe e9aYWUBllzD855KroqGzF2kBW2xUBqGVi0fo01ERjmWLUaj1HZ5vi6LIWJWmaZqmcRwzNRmRjuNY JBwLdUztOtv5CPJVaCTSeXPnRZZtsK2G1prZhhS4uucODhaxXEw1LzhPnKeI/sPEjivVCd9IWZa7 24puge1X1YGd1XHbmQ377QZNv1HkFmCjgbZELmQbi5TxmtUl1Q6tNSEqIlK4SDRfKV8IAIAtOaIo SpIkjm2apqPRKEkSJhwxKa11HMeStiNkOasePyQlVTsH96S1llOWYB0MXpQsvN+fhHNIoL29xOGo RsXmQwNxdebfCx4PDjeGL9ThfHDyzClbgNe3h4cHANBac8iv4+AYxziZHvxu8PH7+R9iKZHQMWEV qoYE+BLvE6gJB6OSaoCXP/mYTsTeH8B8JY7j8TgdjUaj0cjUSJQOXVq49rDenn4IjTnCOxtGGA2T CHZR0XoRyT8MGXJyh4jTriDszQ/rbKgvuOCCcwAGQRShDugp3/aww30Rx55Vol0Fy9H5bMnn2N8a 4WBcsk2Gm6jwYtnbZMdlriCkgf1XJfQWoSf0AAtaoOuxrgKuwBYeSqHSPBk8EUSRiWPL1hvGGGst EWqtjDYBc6hMU5VS/XlKQ57RHvHyXJ1R6kSeETruckjTPM+VUqcdKtznO9KO7R6h6ij0AEAKmwFZ 1/16ixovOEM8oqVyo93utwRZz/tPR0fohEUV6IbIVOM4ztE3NqDj4BiEQ1LaVA4Ij00AtS80xqXE D5UroTZEMpXQcnhyxSqS2kiT7TmwDh5a+aQgaq21JmutNiwaAWNMHMeTySRNU877yiIMYwzhUrgO YRuiKxnydG3SEYo9GrMulGeIPoXB54PTnuwpSDl9wQUX/Gaw5cKygjTwKsGZJiFY5ZaWu54ACNty kcYPcRP9/mw2s9aiL3n5ZdH4WiGHVLEjfzreqoqP3BBvo5FK4Dw0HSMbITVx4awKzjlShCixO6mO n+G1QkKvFCFKFE7gsAyKKDKaABGREI1SHP1CKaW1iiJjjFEalVJRZK21cRyz6QYTjoUk0C+MNthv hfUd/eS3v0NCC9COALdaA0AtiVFExDyDp+719fVpPULPyh/1rNCd2ad9acCidB7+NxdcsA1k9Yvj WNKpHEdawMtpWZaN6gLTBQ+rmYGc/yeTSUOPfwQchAG0j7OHqOW3BKqyn2gAqEKVsx8KLOV9ZREA 1HE5+beVUATRGMNWHUxajdHsk0JE4/FIKcWyjSRJKEj6CgDivsu0Q7xqhwTDkGZUdiVBOSHfb48B HuvGGJHsWWtl3Dx9+nSLbmxjI2GJWJBAMC1hdTD1QwhL6xqrZp8V9TmHSKOHE30dX/7vvZ/P5zIF 4PD+WcdXf/xWFS4inGYPOwDI85yDGA0sYYvHrxYH79k+Ic9zrq4hiibvO3N18aHOOZdlWVEUezGN 3xS68wA6EAN/2NTfO7/qq73jtGO6oXlv/glAsIhwpbWOoijQbHjmDQCgFFqrawripSilkdAjeVIQ K22Nrsw+FCilosiMRsl4PE7TNE0TkSUoUkopqzRBLWNZxM9YsIeesRi+NRGNBMUsKVNgxVsuy9IY Mx6Pw4t7mQCdL32jcVCWJbvpDi+/8z75uPk4dwBY85+CaOAqdsC4qPzUWZYxIeaLtYyu/XQHjPDb 05lrpW7ntsnleV6W5XFCMO2y1G9dI384k27ffrtp/U7kGRxACJb1KUOMRrcjHOJJxw0IC+H2eF9F uZbjQbsxEoKB7zmQf6zQo/BiFafyTAbEY0GnXUKIKsjEuk4Vs1ARS/B12e5rawy9cFSpCQdiHbac yBhDQGK9oTTGcZwk0Xg8Ho/HXIIwg9AhpT0DG2RibSdgEBW0QTj6wQ/VICU8oxZxzfeBTilFJ6QN 4VF+6z3qt6cxOAcJx28Ms9ksjuNTt+I02Hr7P/5u1Twz19t2FEVi79V5WNqI4669U7ZwMXQLTfLl 550Le6PlUEtPjzyp15ycDu3Sc3LzwE2xXWtXvVShGqxQqL1CnLABUqiNIkIkUAgAnrOi1ITBE5Im VAhaEykwVhmjI6OTJE6SJI2TUZqw9gSWbSGx/q/5gMv/rX185kFrb2tArEQ7vz1hBhNZNXg2dpL0 gXhU43ooGqJa6u2YVV9eaAtjOp0WRdEp/b7gnBEuXGmactKlzgQOw8scePPu2y4rg4qi2EVd209o YHU7OwjHRdqxCrJHaq2LouixyiHfZMRtkyKRyImpZp2+L/BbUeJ+UlWNgESkKv0IIGIc2yiKYmvZ tcRaGxkdx3EURXEcUx3AA4blHR0i4QjFEhjkTNkUYkQSlqmUolry4b2HLq/aA6HtNwR7yoqydXv2 aGfdM68Hdu9la9wvptPpfD7vdz6/4JwRyozlPXJKpuGFHGLDbWh5QvCmwJYce6+3gQ53Af6/i1Zl LWQMiQCtk9KyMoXthFmlwh3b2JVlq2ZNigT4QkS5ERGRABGt0nIzgrPs7Vp7z8ZWj8fj2EYsyTDG sH8KkxguYfgEWDCbwUxirU59Uy2mdAUTjuPLwCTy2GVShLiE0tkv3r9/X5blt99+e3t7e+q2XLAl GmyjKIqNBLRbT6hwcQ4VBWuVErKyHW4u95Tcd346vs3X2SJss2Q8CW8Ig2MuJBx+KexVOBAl3oZw DjHU4HTtdcWeiMUcdWJYQCLiOKF8y/XV+Pb2No0TkZQ0Sgg5RP+jQU04Vll4rPr5EGuPxhWWQ7Yl HHJoWFv1gXA+TlUs4Tif9sDFjGOveHh4yLLs559/vpz3Hi+q8NnByYo3iCGyyT2+9LCoPM/7aYdo tNnVRb7qWcaHNLWhgO78ySMOjLEddqQ70okiXva1V/RyINFKwuGXQ1qF8SsRkdUobNHJoS+stYBl Y/fVuHAbUUQAHsAphVyQtXY0Gl2NR819mqNVekBE13ro9k7PaGhwVkG+pSCm76q+2gLHZ6Vha08e W11wVmyjMcgv2BF3d3fe+/fv35+6IRdsiaIo+FRw5BBTDQV9w8gdls3e+8GKlYHrbafN5Ubr/AdH OPYOXoVFmcIXFacJDlQqAMDBPcWogtUfTEHEaFQpFVoM8F6utRIjDEXAYgwmF6PRKIqiNE2ZrCyR Hl9CbdZXxcsOPUqWo5KHBKLHhwVWiCs6e6ZfyteoIrTh6CnzCHDOXV1dhdlrLxBcDuL7Agv5yrKc Tqfs33ghc48OknOV1+c8z/frYRdCpl47u2T4lfceewcSW28caLBtYzR6QSfaPYh1HG5fB1qRt1jF ycBF6G7RnhCRxNuQ3V2GKRHV8TocAJD3VHEOjexmQhhFUVRFsHCTyXg0Gt3e3hBgmqaz+4eiKLgE 59A5x/SFeJgiYh0EhXdSrYiQHHZs/wP1GrtsybWR7FI5WuuT7Gks1ciyTLqiLCtR06r29D/7prZj jWJ5zPRLR4+Mi4Rjj2CG4ZzjOJVa69P27UWtswXKspzNZlCb9O0x3mj7XYjCIlTfSDOGl8w6lFMN tkGEI9TN7GFQtmIaH/8cua8aw6iUnTakMviYZIQpWNloA4I4ccvHffZJWQQhjaMoiqLYGmNMZEya psaotAazlKurqyzLZvPp2vHE1TnnjDEi/2hINfZFOFbd0zmWiMh1eb0fepBIpK84jqfTaVmWRVHs S1LayVZ7bj63hZ/P4ixAPnVb+rC253q21SOvQlmW3d3dManNsuw4Mvm1QsdVPzy/IXlGYOO50MtU Vs6tbTN7CEfntyH6x7EIy7doVef02YiqbjbK9zPs2vGwMPjQ21u63M+isJe1BRHQATpwBUsjIGg9 P6OvXVQUKW8MaeO1BqUKpRRRgVgi+SqpqypROSClnZckK6xDsUZFBibjiLOvIeIoTtj4Qyk1Ho+s NVRZjZTWEHgzn8+VIlDVqMqyTGHYMABXKjZURaBaEsPfU/Bf11Mvs4HecKKr0OYQPAG4Qk4oA1BA 3aOsF/Ic3MxvszTjutBfviiIG1aWmkPEO0fczhVpP9Y9cbGqTsQ1zSlIQ8CBTg6WbTDb6HrRbRbi AMCtiXx3GvHqFsTiEG/h73//+6+//nrxie3EI9Jm3t3dVUE/S+dLRxqgdLx4eu8RALei6OhWREz2 i3+7vu0lIi3tOeuAhhwIRazSXP83mRo0OGTyBSvRE42DBRjLHijVJr8wlaDKqlRcNkK7ivF4zFle 4zhO05TNNYhoFCdJkiAiizdGo1E+nQEA+sqaJNwhoMuJFwNAizRsOtt3v/8s9tVATNXp9vzB4vxl G48O33333Ww2c84dJ67544IsnmcOUTKGy8V+Z8reyS7Ly12hOPzX4YxOOnEhHNtAHJp7TL1CRUmS JETsh6K0rs7PSJ4IAeqUrRXN8AoojmJ2Xbl9csuSjCRJ4jhOkoQpC1uJxnFsrU2TRBGpOPbe+7Jg gxJrbcg5wrNy2LAG4YBhbq57QaOKgXI5CQV2uJYs1XVSeO/PKnnbJfDXvjCfz2ezGdvuPX/+/NTN OS+086CeLfgl8rzgtdR7r5Q6aJSLLSCr6/39PQDEcVxkszzPp9NpkiTHbMnZEY6e93RaIRtv5APZ qwgtJCVbxNG4DCdMcYgI6LBOpMJOKwA+SZJrmwi7f/LkCctFRIHCnznXvFIqiiIe3+C9Usp5JyOe 5+3CjjVQ3/J8XmQzGRBdtP9hN/3JqnJ8b8jzgyJUju7L8mtHnA/bYMJ6MRrdFzii+XQ6/RASqWy6 9XrvZ7PZkTfC7SCHuizL8jyX6EqnbtdK1Cp+4ljsx19hzo5wHAfDw5iEcVHa8gwK8vWF2yQzA0Tk OLLW2igyWlc5TQC9UmRVJGxDaxUZQ0RJFBMgIUZRlGVZZC3HD02ShLPGM9tQSllj2JJULE+11oUr i6IQuhMG+cfaWUb0cO2tfcedXvR8uxRyQoRC0TOR6J4D5/CL+LlOSOGpG/W4cXd3VxTFfD4PHRpP 26SDYqM1wTn3WAiHuBpBLZh5FKsfWyifRAxzXoSjfy3bsX82WiXZJn+tczzvB+2dm1OZ8HWWSShF CyuNZaUGsxMORk5EBKSUYlsNjq5hrWVbUeYubOYjwgCqU8P7IMgYi0zyPGchx2w2WyhQaq/XTpXK RkDsMAtsdMWm78w5B8fd7EMFmbzxc1g7Tt4AwflEQnvsIKLZbPbq1auHh4c8zyU2z6nbdUaQKAOP AsI5RHJ8zm+zcSo+sgEHnBvh2BRtM9p9Fctso3/c8wZPRGVZ8ptb0AtNRNWuH9iMEkEBAAT8JRKh IjJaxVFkjTFGRVEUOUzTFMGP4uh6POL4YIaQo1ZEka1CY4En7xR4dCUAeADEhfSCBRvyed0Tu94/ u9Gw9ljV/wPfS0ihDrGzDXGY5FVDXr1wjrWk6qA4E3HL+bCfRw3n3E8//fR///d/r169kgVkMdIO LD16FC+Rbd5P3Yqh4HUjDHB+thAJNAcrY5H5kdvwuAnHjlg1PliNIgffznsaEcq5KI4cyrSDL4pu Re4PI4AZY6wx1tokSaIoslbHcZxi9VKeP39+fX1dm3d0BBHvHy5ixAQB/whDg2zdP7vcuTW8974O 3bp1G/oXXPlWhI1COE6ylEggsuNX3cZFwrEX5Hn+ww8/fP/99xzvK0mSp0+fwuG7Fx9PXK9HZCrE K3Ce5+eg+hwCrfV85rIs4z2I94VjimT0IxqIR8OQ4CoMY4z3nlUhURQxOVBKIbFhDiJCHWDCIVYW G1FkASCOIkQcJSlTjSSJoyiaTCYjpQBgMpkAAKGPrCZaEBfvPbLNKXgEh+BUzawRHClw3rHrNyIo jUVRAoA2VBTOewfg6zjnAOig0qecrwwwRB0XpHsxwt4QLkxW/Gr3WwLHrvPUikRS4pokAgfiBOd2 1GNTx1O34hGDO/DVq1fv379nbSl7vB+tAQ8PD6f1wh2yqHI0wiM0ZnewAPtxKRy5qRKCcqPf7m6l p+HMyO+6M+ji84FW+X7BhkAUFmyAwzOE7TaIiJPCS1BR/glH8RJqKd+ybUccx9fX17z8cOGsQxFN W0N50fPW2sMoiqJ2chDOpIx1VNO9Y+2g8q3PoUHr3qsbCHFyg2URd0gvGnU1OnZt4wdKzrMsO87J af2b8l68n+BRxWUaiH7Tsb1UIWwjz/N37949f/5cQuyISuXQvZrneVmWmwrSd+mBhrBwSGmioT5/ sISAlRSxjcKvFs97LjGGKvBGYCMre1PnqFtrT7ld7Y9bpbLf+Rl24toODd2fOAGbmIgCABOO2gkF AIAUIHmtjTFGAWokDlKexsZastrEWqXWGEUKvDGGCAAcogdwAE5rXTeJhSWotQJwzhUAxME8nCvq b8W8lksAFrSEnKMsS0Rdl3+OEo6uV+CDfwF2HgCNN+69l9wl3OGrbDg6i2oovIZX3YBwnU3DbR3i 2NB4okd0kjsfyI6b5/mrV6/u7+9ZJvr8+XOOrHPMxvAxY1UjD4qBVRyuJduX3A6OHRz/ROzHp8eG 98eZEA5ErKOULk4ORx57cCaEY+A42Dv9b5O4ssaQmyFw94DaFbYiIlhtP8YYDvNFCrTW1lhrrSHS Wo9GqTEmiUwURVYbjuKFiByDXFxIWBYCEvzbewySvnZuALJjsUFrTw+ciUFiJ4YoLPZ+1G7050mO 8p0ytmFzZOOlbYgwBgJT/DBJxG9MyNGDtpRrI3BuNgD49ttv//KXv7x79w6gyvn87Nmz0L770Fi1 uJ0VznlRaiOMTXzalgwE70oErn/U7TjmV+EsCMc5gMVia8+djNB+U4K9sMMqa0wASwBAKpWu8sRq JGNMZE0U2dSaJEkAXJpEsY2stUZhEpnEaEREX/EYArTaKCSjKrdpqF1qOQ8tePClQw9aKUn3EUrJ uGoW+rWlZ4sgpMsqlePT3k5g60NlvdF4RWTvHHUAACAASURBVEOnAy0X1fytQirBKSK2WcNt1Tr7 2jlCwnFyjSc/F0vIhHaIFe8qIPV3xePgK6EGbaOXK7/iaViW5Zs3b77++mu+8vnnnz99+vTm5mY8 HndWunPDO8DBqQ5R8nCI23n/DY8FvMCyU9vROMdAW4pOtXuSJETkiqLO3LlmpPEN+3opi53sQwaz jSHcP9R7cZwMZhhs/8VWF4jIS63SCysNhWStjePIGBPHEROOJEliGxljjMI4jnmnJ6gcXjg4KduK ChttjyEe7mF+MZaYNYZI44QqF8+TmB9/TIoP/Y6RlfeljG+/wZMjPPR8OOKN3UFERVG8ffv2m2++ efXq1WQyubm5efLkyccff8zHzeM0gw04jlPXKnQmHGlMt/NckVaB19Vz9lLB5WhJHGZhXvSdrg/U DADQh6516/IPoUBpV8EzsGceNkb/wkoDkYOL8/uzNapmYw5st4HIjCTS2lpjtbJGG6OSJNLgkziK 49gYY7WxxlaxwvyC1shxZFVIU6iND1xgzedr/35Ydo4NiYt8tV1nHgErR85hgq8wWFLFfuq7YF9b 8jm8oNDojwcbXuKNbgIimk6nL1++fPnyJS81o1EdX2fAEXNfyLJsPp+PRqPjVLcK7Xn9qE+8u7iS HfTBw6NpqFvnzUV2hAOpTlahQ3jeKYfZDmc+kjicaOdXnedUllWwiajoUMKI40JHAD0AKF15oCil jFJRFCVxZK1NYktEsTVhQFKo6QVLOMSGA9Z1Y3UUDsTXDc4xEOewf5xcfbvW6mUI9rIZ88g84Wlv iOvKGlfk/nG7Wh9zDkNxj/jpp59ev379pz/9aTablWV5c3MzGo14ZeBIo3AUodF8Pmer1clk8rik CGeI9vtaZY17EvDO0XnGds7zJsULHdX5tvpN5fbVsG5t/ZFZz6HRYA+h8f9wnQIiJkkiWeZDwsH2 X6wEqSpCZEPR2vuVkshEkU3ixFprFVltmJ1oUu2IXqueos/Ghy2Qg9ay0Sgtp1lvlMAbvBh8DOmH s4Lfq7RDxEihle6HiYYrIzw2zfoesfsa6L3/r//6r+l0OpvNPv3005ubm8lkkqYpT73jRKgkojzP syzjuBEf8tjeO3i5YMUK1iESzgXoEcE7F4YvWiTZ4H1qeY9gdF7coNoVYouzMA88JnydiQoCq0nR PshtnbINXho4QbwQDl2HLhd3EsQqE6yxSimFyHlZq5hgEofDWt057UOaHBrsrFqV5NuG1dJa3ipV +BWPvOr+/gJ3QegEselvBxr8DmnDcfaAHhxNbdHTaQ0y13Ah/o0JIQ6Hu7u7ly9ffvPNN3ygVEp9 8cUXWuurq6ubm5ujjTRWp5ZlyadbpdQ52HP8BniPWAQDABMOUaOfw9Otmrmh8yMfO0+mUjkCTrVg sZm9nN54lFQhLgLDGiJSEoncA1QWGxEixJHljPBak1JE5DV5o50xymqIDDCRRPCIYH2pAZVCRS4y JrV6FBvJvma10aQqxYmH6j9k/5NaRAFAAJ4D9XN00GXzT6YYBIB8ZxgYzbPnRVU4fw6FPXLdITUm /ynWAu+9BwQPHt1CnYRIrVjmG0yMaph579b9SpRrwj611tzharkBPZLHxaj2vtw2ghkAoIdsNndF SUS4NDb7wSeSPb04H3gme5hPZ0ZpTQqcR6qeysNvhHkcaLV99+7ddDp9/fr1+/fvrTZJFP/+97+f TCZxHLNW5RCVrgKftTikOi8vJ9dgdqJy9HskYIH3w8PD1Xgi2rGl4IG9K8/xdQjOufl8zutbWZZs IdC4Zy0Zbej6h6tEjko4TntIqowrl8UbnQbSYcOIvZaJAICFGSwxE/8R4pQo1sY2wjpCBqEiIoOg lCIFURSlaZokSRonHAEdACIbiTKl0wmTb+PVQZaGtpl3KOHoeXZjTGMY4XLOWElkz4Rmj29n1Sj0 rc9yJ4udjr+ZcaX8+OdwQBFssjBtTsjWQQxKzktcfDbofDtFUbx///6HH3749ddf2Q/u6dOnX3zx xWQy4ZjCR24kj+eiKEQUemTCMXCwPUblXTgAiqLgvfxM4guEQMTZbNbpK7Sv8qF3sfqwJByw3Bcs TZJ9hYgUG2yCZyFE0EhHVW4Ur7QHAK3QGkUEWuvIamu1McQBVRDRglNKITie24m1qbVpFClCBZ7A K6UIPaEH8AiIhEiek5ug5zYgAqJ3AOAdR+BABAyP+x6hESe0vUNSHYjUAdhgAvArUIiaqECCQGkn nEyefblI7PpzsT1zIVJC307ZMQQ8ACAo8L4SGLhtQiB01NCRg7aPT4Rso/OB11S3DyxFvNjkd5vc LE3u6w3eL5Mk2aTkdRVvNC4Ea2J7HAprhExd3/79+x/+/d//HQDu7+8no7Fz7vPPP//0Hz4BgPF4 fHw6yyZKPJaYQR5/RwyNsmUX+A1YCrLoSNjbwCfa+4PX/ekAWB7eLV4xxmRFCZ6INAAB7E25tnbZ Pw3hOB8x7NK+gqiIjTwXV+T0z/4p1lqJvRFFEaKPoiiyhr1blVJCOADA6EpewgGM+7V67T6RnEAi khFT0M4S2ucVEcB474uiMMY0DEgri1as1JBYp2jf4gX1aGE2kHAEwcurxbG+KWjV+nA3HVV3LG1L 5XjvZacT0xlRbR5/xHJQyOO4TXrv1/YqDw/ZIXrG4f6aBNDlBH4+q8cqFEVxf3//3Xff5Xk+m81Y FHpzc/PixYvxeGyMmVxfHblJkj/9tPmHw1OcmBe0gwOdoGVbQZraYFHnTKHEhqOnn7d7hKIo1q6W ZyfzWYPwoDF81tQ/aouSEJHLNKSQxQvoazuKRXQv9nqNoyoYFyIqhURgjY2jKLEcXIOUIgUKABSx vgYAIIoiVqPURgkd7RaNBhE5X6lI+FgpGs2iKELFBwCgoqIolEJs2br7OrUHH2skT1vDPYcvNn64 6UYiP2+PYF+j84cdmz+b11AH4dhxlRw4f0LVVcjeTqIBbIg3hitKO9HZ/oFFyXp6NEUAWzg20h8+ Cnjv5/P5L7/88qc//ent27fj8ThJks8//xwArq6uxJft+ODxfPLk72LoIFfks9ilnaRhW4APgQyh Gg3L98PlUtl0RiOAVgoArLVZ6WRmcZv7l4J+WRSfjfM8F87BYK/vsJ2PjXDsgDzPwz/DLqY6HqjW JMp7cVpjYUaSJHFkxHSDM6Sw9UZlRqqQlTKIiFAQkVbIGVLEboNoUX7I9GXIQmCTITdwHKqQdfJX pJXWejSy/FW4KcoHNolt+8KFlCscECIUWdWNbeeFzgUiNM5dVUKntMGLMmVl1R3O5atauwUa9isn OVKz3dlZyZyP7NTAsgEAQMTr6+tjVr01pIv++te//tu//dvbt29//fVXpdTz589Ho9HNzc3t7e3C c/7oiON4lyhVO6IxkjFICAXLI/xM/DvWIlzMQQ5X9WdYTTgO+vaxTtLWWSkijsfjLMtyRKyjRjW0 4dBaA6Fr95FnnM/nfJ2Fspz/kjOLtVMTH5VwnPCkIrEjw16rRgx4RNSktNJEoAIwDSCiyGqjyRil NWnF5hWklBpF0ThNY6O11uQdsiUGIqBnzYtGskqTB40kA9R7j4AaF+E3iP/04IuycBXfRERrLcs5 iqJgKYVkpg0HeshXOuWTbEqyKiBHSLzyPBd6tB1aJiBL4FnJ91QneAQI7A6cc4r6Ddna57OG1D34 YvGYbYfbpkrF+8Uskojy8i56m7R/hC5UGFgNnwTHPxPz4zcOCWcO1qS8evXqL3/5y5s3b1h5obW+ ubl5/vz5zc3Nzc0Nq1ZP2Mjz7NLG/DoHhr0WPCX5LMd7rXOOBrzcU2lpeSXRWidJMn+YShAm75uG d43P2HLRb7wgFqIDgGTb5vNSe6h/QBIOaHUi92AVORSQiLQhttIIQj85ibTB23bFJLSO43gUxZPJ RLM3indQu9ECVndyp2NNJ/lKQ73SFicIwRS5ha9drTh0D49yHLANYKCFCV9/uO60ZS3LYs+OyS/7 X4OatHUo7aHp6ywh/EQNwnFQPIqFLASHz+e3f8KNSkbL0Y6eURRxMkXn3Pv37yeTyXHq3RpFUbx+ /fp//ud/Xr58+be//Y3DerLsk0NuSIDRU7UwNBoVHJlMD6zrUUg4AICIWMm4xcJykmMMd6y1FgBY Xw9bHSdwWzuVD4hwtDsoMprjHCgkUqC1knxpxhj2TAFwiKgIEBwhGK0qLYmiOI7HSWwMjaxBlAw5 /PKMVIq+shcmQPRASIRLWU4IEBF96ZCj3ActZEs9XiZ4exZLRhzst9kZ1CX8LbdHmI1zbq33o2id XDBlfOB1vBYyysO0c3wJ/bETiYoyS6Qax62/CSaYviwJwBUFIlqtG6LS/kViv2sZEc3nc6oRRoI5 BHwdJBcAiqK4u7ubTqfj8TiOYyA8/jK9Fg8PD3mev3z58j/+4z/4SMD7EBF9/vnnnBKWzwkA0Jjj R4NYu/O7C9eTUzRnJR6R63V4MGuYQZynTywiIlai7izLauvASmUf3hnyocbnzpK11uxxzVsAu1Ag IjsrLFT8a1t5tofC4Q1zrvvOynSDQ39q5D7SNdhKgxd2QrbGMMaYNE2jKFLesWeKBBvFSjC1tBHM 53OWz4cXG2YTPQ/I51r+IJ9XPb6s0duBpSZL5rTrmtd4joHijVC40jhw7X2oBfYiKwxXz3V4w26K jL2IbbkBWmtONMoBBkTeduiNwRjDcgIWFcxmsyiK+rO3HBmz2UzixX377bdfffXVDz/8cHt7a629 urqK4/jFixd//OMfkySRPG3VG+l9iMONyba2/uTcuhP9tsm9Bl592Ho6NH4mdUnkaKgZBh8Rz8cM RUQRWIcXQlws1I0NZRXD6FGmNMCyE6kaWgPs7FjYXiBH7Wpe+UD+gx4ANGFkNAEiYFLZdSpjjDaV XQVRZUKhFGmtWStitbZWG+U1uYh0pJUCbxWl8cIQjACKosjqdC1shAGr35OYCAyZMKJpk3NJOBQ2 GuIUxCBht1hpQKju4QtDCuQObz9s+JkJTYMzhY+N4U+cR1w2Ju3CLnsqb5y8ZxRFAUBiMLHqJ5tW t8XmwVVwxp+GxftSyZuWuwbdBxf+4JwLMxAt/azHXqe3vrX9GMfxbDZjhppl2Ww2s9bGaRK2bV/S jvWvqev7sizfvn3797///fvvv3/58uXbt2/fvn17c3MTx/FHH3308ccff/bZZ0opFm8Md/A5kAhH bM/huEY5Gz1OqIPerrojHyFCPXvYgBPK4aqp0RK6NCB6bVHfN0oIP69dflnI0Vj/22fgR0A4tnhz S2yj4ViIAACmli5aa+M41roK22WsqgkHIWKSJERYBzJXmiiKoipVG2nuYvH8ISKJpS+sUPQmMs9x 2Ty73fLQh0V+i4hRFPERM7yfRTKwWrzRQ3QW/+L2ZHzVytVZL1tXHXNF6JVweO99ex89uUOs1Lt7 R21Swso728fio4Eny3w+n8/n0+k0y7LRZKyUevHiBasGGg84UHC4Y6tEv+m9/8///M8ff/yRA3ll WZamKd9zdXX19OlTvh7H8fHjijbAwm3nnCwgtFt2rsPhDFVm0GVlL5qUkG2cFRrnWPYJUKp6ED5o hSLtgVKixm3WWvGs5CttwbZ87iYc/YfyY2KLwdc+Z8tY0LVPsNbEMUNtRElilFJJGhljqhhYtZcs u6porW1lN4pKKfZYUQBXk5EGn8ZWK83hz7MsK7Is3PtDqu4DD1KJ4iWmGGIo2viX7+FkS3EcS4HM crZjG/0Itts165FzrvOgumrAdQsPPEBgyaGUQuepDiiJzRv3CRkqta/g0uRc9ZPwz8b4bHd4/wDu fCLvKxuWkDS3sfEK139GCb50vXNO/J42rX8LxHHMccF5j//ll19e//yGN/LRaNTu24GL5u64v7+f zWYS2ms0GnEq6Zubm+vr688+++wf//EfP/30Uz6cLB1/T7eZisL0mLvj8AX85IKBHvS0quFZyjiH rTOEHHe99+GauktvY+AX2Uk1GiJzxiOQcGwEXqMrD6WueVWPD7DWJkkUxzEbilqrjTG1J0rld0pE iJ7FGHWOWFIcjhRIax1rZYzRpKIokqyzEIy/UI/FE55PZuE7kIgLolRjTTkEtIN1wFCzFr6iajM0 CtIdhWvupicY7rThunnvPQRDzdWR0Zv3LN8wHIeWLjDPOGhkgv6lZ9V3vlaznsP6y8ZDPG5ns5kc 4nskMPtqtlJqNBqVZckupog4m87u7+/fvHkjvmNhpQdd6LnwX3/99eeff37z5s0333zz5ZdfPnv2 DGpvhS+++GI2mxljfv/733/66adPnjxhu7wzOf6Grmr9wvaTQMZMI1TUOYMFzCw6Ogdj8x7w9FFK eV858UJrnq4SUcCyrL39k55zV0Ok3UE4zmogbkR7+RgUWj7WkFBanpQzxlhtrLVxYpIkslZpTbFV xihNHNmw2tQRgUgZrSKjjTGGQ3shaMTImiS2FpVm+gFQV4GNhU9elfyb5zkG4b9EuyGuj1THAIVa NwbBGsFLmLWWtKqYR5eOJpTJDxSfhgqdgT/xy+ZFDfuM8LOvsaIgAOC8Ms18yvxBRnqnamRIO7uu NZp08JE/cHI1srBuJ3HcetWmlrSD5cbQyql7aCil0jTN8/zu7g4AOKxQlmXffffd/f09B9QStn24 jcp7753P8/zXX3998+bNy5cvv/3227dv32ZZlmXZzc0NL+Uff/xxFEWI+OzZM84ncG4OF+FqwweA M/RSeSxsAwAQkcOpsZGTqKtOFV2tE4gI9bnXOVf7wJWwHChhswIBoPZ/XCXWDQmu3KM7jwVnxTkG jj+mmSLkCX/LhhsczyqOoyiKjNJxHMeJiaLIakN1xldVOawK4ahEC5xT3moiotgapZQiMsYYrNY4 JjpyKm1smaFlqDyOaFVg2eyDjUJqT5lFzPLGv+EwaqhUxOFt065muzwaHEzaOdcQv+935DjnJMy8 9A9XcLhV6WiDv6ciDxtLg3ZtxorG+NCBuZ8yHgA8AXlHf/PmjTEmK3LWXf70008//fTTkydPOEHJ fgNqtXWCv/z88/v371+/fv3111+/f/8eAGazWVmWaZpeXV199NFHxpjRaFQUBbvFntsu7mtPRfZd PHVzKrRZNZyr40wPnHNZluV5fhJLnSGCvUrQrlRZlt4Dh5Hcjg23F95VtYd3CgWp/cKHLSLYa7B6 fHBLOLqZSOzDnZtvsFYDAFJprLJWW6sja6JIx9bEkbWajDHWKKU4EAaqhagCEb0m0OA1ePSOPeiN MVoprbWhitLyre0ofg3ZRtjV4ZVGl2JtjgqrrfGFcCz+DARC272jLMtYeQQVHV7/EzkNe+8XdGB5 /5Idzful03PZlij4KluO994XJRE5rM4KiOg9ICJLQRaKyIHEo0N57soy38IW4oMCeYDacQACCQcs K9T2DhnwzLzjOB6NRj///PMsmxdFkef5V199xQKPP/zhD59//jmrNn73u99xsrRVpXWCVkQW4fK/ //77//u//3v3y1veUb7//nsOtf7s2TPn3GQy+eSTT54+fco0/eHh4fb2lpWv53ZS55xQeZ6fpw0H BjYBh2zRnsGtDTPUHFMTyqRhePRYY0xRVFFBRV5eltsEn5Vn7HxY3+VMS0SP2IaDdROuKzuArw0t Kw0FFGz+mSTJaDSy1kbWRFGURDaO48goY0xkF4cS3hQxkB/UokjPZxdEZJmHgqZcAeuEq9ISuUE8 SsLgXYuD+7JjCwZxvdpUsfpAAS0KpO5Yu1w3zPjbtKb6Vb3xh/q2LaZ9P8tpK1w4TV0DWZYBlkmS VBYhwWDGXgef3yR2D8Ux/O5V3+DqYGhHXls/+ugj0uqnn34CAI7PQUSz2eyrr756+fLls2fPrq6u WC44m83G43FIj8J2Pjw8iCUKBAJwDi/217/+lYg+++yzb7755uXLl19++eV8Pp9PZ7///e85vYv3 fjQasegljuPJZMIZUjiQaGhQdVZgwvHw8ABdyTIOge2qODei1g+RahzfIJezf2802HyAOI79Jqk6 GxJ6QcMfuF1j+OfZEY7ho40PJeKf1ikDqMiBrrxLxuNRksRxHFuj4jgexZHW2mhiccLC5LMmHCzt qBXYnjwYpFgbTcqiMlCZO1T0bfmwLOIWuSKOfJVCBABqI9Y2FehkG22Ieanc3PnW1+5bVIflCP1o thZlrf1hNTkBoFPOEZqgBk/Pmim/+ZK0u0xOmNyO5QwEekB/TsEKSwel65AcAOARLF8AAMBaW5bl 1dUVi6+xzi/DK8CPP/44n8+fP3/++vVrZh5QS0f456y3fnh4YJWHcy6O49BQaTabzefzL7/88uHh 4c2bN19++eXNzc39/b3W+v7+nteHoiiurq6I6Pb2djKZ3N7epmk6Ho/TNCWih4eHZ8+ezWYzLvko vbIBeHaLZfdjFCecG3hEQeAneEy2tIt2zFqLiMzIpc2h9L39k/Ym65cN+Bo7UcNXllHtdtWJs3db 2lpQvxHaz7x8Rq8+OLcwtV31QwDgSBvjVDGx4CChaZpyovlIK2OM0cQqDJGCKlhIEVRtrcj/x1yB DTuEHopEAerO7Owrfrv8pkOXlgZEstIvsxoCv8IxRC6GbWjUskXAjP7xE7JDaR5AUyfi6gRIbXsB pkS+5UK86hFgc6rRvj+kGsc80Pc0aRX227bwNfFwVUq19b7yjg7dM8zCoyi6ubnhOOv39/e3t7dx HLO93i+//PLu3bvpdPrVV1999tln//3f/83XWSODdfRlAMiyTEzL+cpsNru/vweAV69eOec49Qnv JezsOp/O2LiKYw0/e/YsSZLr62tmNgymHZz+5myP6Ye2DdpIhxL+ucXkCqfGcbandgMeHh7Y+fkk jj8DJVVh53D8N6VUkiRM3MPb1hbVfkZsWQv0QIcylrV3nwmYnou8tLPl5EEBRlqlcXQ1io0x2oC1 No5tmto0ttZaw7aZ7BJSSzVkpydAADAyPT0AgK7/UwgEHlzFeKhyZXSOr7iSwHf5y0Duq2xwvnQA QEYT+MZ/CuvygY1eAbZKb7Z2camlCI6DxLk69tyQwbDdgGlwDlj2iQAABFDeKe8AAJ0PSZknJIcF QX20Dj9URh6waunpnEvoABxgMJCqUj0smciY5Rob7a2eo1G26ur7tmlLJzyAASpzR7nTGxi8bz+F XVd+DzkEz6czTcoAGSB5X+i8p8X4hNaGQb3N2WJHJiL0ytvok+cvLClyfpKkGpBIacBnz575vMin MwWQT2dYunw6+/OXX/7ud7/j4H7f/fDDJ598wuXMZjPn3NXV1d3d3ddff/3FF1+gh6IorDb39/e+ dOghn2eRsdeTq7u7u6uPPlJKPX369Orqajwec+RyAGC6E7YQwsPSmbKO/WDt/rQRgWir/Ldrzy4b 2coGryiyLEt2hGZd3qCi9oFQxRmedfmKClqLgAhLc9s5cA60tkS6dIAIgAagvgl7giwzKVxIKIJn bJ78V72Fs5HZDkYYOwFXWFwiIgJyVFAWchhjjMU0TTn2xiiJhGpoXiN87foh5VS7V1XmUuHLlhMQ xDaVf9kSuNEwNt2QHL5a69lsliQJNPbgA8s5m0SkVgJynO8h4q4GhkzyfoIo6Hn28MzdluD5wBqm /cNVuVQgkP4t3d8rXWw3qWNNko15hXyyVUL4Ux86Lu54eutswNoFsVGjeMaeFojIgTv/+Z//+Z/+ 6Z8eHh5Ymv3JJ59Ya4uisNayAAMAWLtRluWPP/54fX0dxzF72DJLYHnJu3fvnj59Op/Pb25uXr9+ zZYZSZIQ0ZMnT7TWk8mEpTuj0Wg8Hk8mk/F4DAFreURaic5J/YiOmkNwBEmbfObINCz2Y4uKg1Yt 2GjIYW1uD/XCTkTlidLLHbbKTRe1fpRlia46f/e8WvJgtE6TKIntzfV1mqZJQlEUJZFJ03Q0StI0 rUKY17YXIPQi3CQqqrH0IGHQi3Bj9rUFa4jGA4bUj3ffMJzX2q7gdh5oRBdFgXXw470XHj74kPLF orazqLYYoyHT61TGrShqY2q1BboJUO85wHnHm9zaN7LF8tpJy8JUtGw3E7oBKSLOBkBE4KTbl45O Sw7SlTHyfhrc+Dm3/MWLF9Pp9P7+PlwN2M6Dg2GwKmQ2m93e3s7n86dPn7755RemTU+fPmVqMhqN rq+vy7K8ubm5uroyxnBIsS+++CLLso8++kgazLOe1SU8ZxFxPB6freqkB64rE9NeaMc59MYh2tBT YsOQ4pg9EB6DG9ol/iDrIf8dvuBGJIWj4fRHlrVYCgdZ+nYEeBFjIqK1NjZWKTUeJTc3N0+ePBmP x0aXWuskMkmSpGlsjNGatNboPSIannsenHO+bCpBtKtqgdquoiEICcE8I9QQN0prHKbZnYkzVBER n5w2whaDpr2BiXWPZDLbCGsO67Xr8qobNq2rYutB4X7Z1rqnGQOvrCphL6uJX0a3kY33nFTJOdfv 84aBffEqdLpoDjwMsHyFnaV5kdrxJe6rG588eaKUurq64m4simI+n3PovPl8DgBsXfH06VMAYOrg EbXWT548McZMJhPuutFo9MUXX3CZt7e3n332mTGGow83XNMlmcCmau8zgYy0TV0b+vGIemBfEPv6 oijEIbYoCnZWkhxmB8KqDm/LQRtHC/khSzha0aqOIetaMho9oWxtVSfKCa9amksvjh58QxgXy5CK tNEKkyRi6/FxOhqnozRhd1aMoshYFcfWKA0ABJ7TyjOccx4XwgnWQBMtFGbWWh5SVIcqh0BiwWEH pahVTxp2snOuKAq2gYcgcd+QjkJE6Ao32z76N0pY1TZx+eM/tdZ5vsZ8oC2/aV+Ufast8ul/wJU1 OgCsYnEuntx5OYZ0SjioVar3gM4DVP9CaI7hgTxgfWrnp5C9dpcVtqEV8rUCrnFbXpS8HfZQwPCc unb/aLPktS/CO+e9z8pKM0hE4D14bOhDrQAAIABJREFUH9qpVUFTEACWeqz6lsvpr2Zb8BxkQwqe oTKwWewxn88bybLT8ZjlE0mSiAOLnCXkNqjdW7DOM76dTurc4Fan/L1gIzjneGhx8NnG6ZdOlxVP qAP0TvDGfAl/fmgG0OGTeVYQM0YIjrO8e4m/O9bur7GNrLWpsI3xOE3T0Wg0SkFrbYxCxHQUa60J UGtN4KFeNHkZ5YWeRdncK95XZzJajvgpbibcGCYcEOysQ+DrWOzMDIYHxB2y2G006LkNYfiaLbBK dyCPCeta7oJouMMrFSLf+BC2qm3DsUqf3SO+4je+Yr4MteFoUA3hZCHm88w5x6bvYpfQuIcztrOF QftZQpl52PNCm0K5SPhzOa5VokSELMuENU6n03Q0GiJWORx4snDnhJJhqoN282bQeChEvEK01lpr Z7MZW/nNZjP2K5GnlhHYHwXnUSMUCZ+6LTthj+3faBOUVYKnSTjSmMXuRYA08OlwtZNI/0OFy8LR OMA2KpUdmzh8lAjPaJyexSpT3mtsNC8lSZKMR8loNBqNRuNxOpmM0jQejRAR2VI9io1INVRg8oke sizzWjfO4iLADxegBqsIz6CdmpQhT9q58RwTi4NsPaP629N+L50jXk7wA5+uR6+MHgihxKVvQ5Ih V9o1tqk7x7rw3i995QG856+wsveuDE4REZ33XfvseqlM6woPIWEejTtdWbLlhCIqi0LFcbks59Ba v371CgCmDw+ccIT1cYuWBO9RCkdEX4cn8oGAvXrwWlaRZRkPBpGvKKj8w7Ms4yATSAuZUSjn6Ogc kOL3CbbG4Ng2jZDSbGPByeKFjXm/CDPHXrK+znUiI1lCBUoV+271WaDzuR47+TgmwgkrNhysg9tX Fft6HR3S0zx3dUaKJVZ9lN1n+w7aokfa8n+53vOrxubNB835fM7aDYZSajweG2PG4/EojdmenHNY J0lCNIc6ERSgI6KKcASZWhFAEg2wpwZVkTqrFsqW5pf17qtMRDfqk01/FT741svigi5AtT3vwnhW /VYkHAMLH3Jbpwyjv6geL5UQVAdAW1Vao6qAfHdIOFa9Wb+M9uCRRFCNk7cEluCQEnmesz7uxYsX bF7AO+iqISE8rIMQB6SBX1ZZlmwMwVfm83kyHkGQA8h7f/JNKnyQUKiDiMzAQg7h66MCE5RQTvNb 5RZtfDhPelBQHQ5frjwWXRULBfNs3ri+9oS5FxzVaFTYRjjoV+kRVm3hvHwkSYLoEb0Cn8YRG7UZ TVohn3s0KU2KFCiNRMABvgi91gYAVKXr8ojoihKqQBpY2W14/tKL8pZbLpyj0eZQEtNgVMOndzvl bM/NWDvPtL+S03PnD8PrDVH88q/c1g4xjY0TltPUDRnTO7L7ziraJZZlCd5j4yvvCVEtq05CshK6 qfe/pJ7uaxCOpbpqIU0oKmP3SwjkZ845TtrOZmtFUdzd3U0mE6jP92FdPX+GX/CjArDNqgv1ayw6 Rud7QmuwTKjypWr1y97lHDx6F9Yk9cIiLiTQGkh4Isv8swI7D59bGttHCpG4Pzw8pHEi422ITRWc SKrEx5WS8m4bjt4p2pYib1z7Fr/ZDmIG0d9QcS6FFWulKCCJwFqbRjEicvzQyTi9ubkZjUZxHCdR PB6PR+NEKTVKLQBoqpwtiergRd4hojJUliX5PuM7YRKrErFKjFjeQtjcD1pDqrHeyWMi4hZLQGj1 1i62k3P003DZY/zmKhXZOBd6geXA82LyskracXzLgHBESZPaGsOQcMh8axe25u8AzBI6e2xZnbfk kyXWQuwwwn9yoEPuZ87hnqZpkiTtYJcsuQk1LI2+CJvH6h7OXjafz7nBbFZcQpWoaDQaaWNDQaM8 SfvZ9762siSS6jxHQjhWVYS9BnG/bYWC7IssAzt/wrGpjvKE4DWTp8bA5at9njz08AsXc54jzrm2 WVhPS8Llcev+994flXAM6Vbv/ap8hoiIiwOmN2QSG8WJ1VqPkuRqMkrjZJSkozSOoiiNosioxEZE FFH1K01K+6qMhfUcgFJatOZFUfCpt3N9Gig363zY9moYkKelqEq7jL+tJXvc81vXC8HBnf9sxJ4P 0dlIY8yQB5dMQVhTg+pX/fRocI9Wa3Flalr9GgI1p7xaDCptq2x4FHW+DFcHiIOAW4QaFnby5K8k fy+Dk5YZY7Ise3h4EHIAQdJILkH2YKbRnYRjsQyFveccOOedA+fLvCjzoshz79y7X97O41jdaSY0 Li+un9xmfr6kumbTDn4h1FpYV/b69mDuxc94DqHJzhYsEDrPxHKPGpu6pQzcCjdFPxUIvw3VtXuv qB/nNT/DoF49bBER0zSNtEmSJB3F1tokitM0TeMkTdMkiaMostpI8ACtK8tzRFS00Fxwzg7imORl uapStk5ta1IaTeIPvt7/GmsfdQVqlCflBA0N27dO+F6bj/4x1P8tn2KZ9g4cT6GEQ7bPxg7a/lXn eO11AGnU2G0DtOmpqC3JCG/2y4QjlCX2t3AI3HImoIZ6Beq9gbt0Pp+zLYUMIY6eCTWxaEiM3r17 xylMecCHyqzwNgwcWNxyRgZuXl4UWZZxOx8eHjhqZ57npNX79+85ei+QmkwmZVkGwrbjiakei9b8 TMDUM4qii15pv/DeNwSKS5Ri8xA4m6JnKWsjjOlwfA/ezQjHRg82BI2n5dVNBN3tvuCUJ2maWKtH ScKRQ621cRzHsY0TayOdRpG1NrI2iiwhJHGkVY6IWlUhzGtUCmkEQESNlHsAX8VgCE+sboA/J4Ot TTtVA1prDmEeliklMzdaKe5eAb4tzAMnu8um+hTeY0Izjp630NOeBjrvGe79u7Y6GDx7O4wPPHPN 7jvD+5lJQS3bWAg2+BzP/7YlHGz006rWOefL0hWFa6WVWdxcujLLmcbJdk5aO18AAEUApUPnfVFC 6Yp5VmYLoaAHuJv/Or27ZxZ7fX2tFDrnDCkChLJ6m2ynUhQlKyZKqkIISDC6oijQe1cUviwJAL2/ f/9ea41KGWNmD9M4jn/Wr8s8T5Kkcl1B1NaC88g5VlqROZqPecERwWyDd8dTt+W3A1nrQn162Mke m3tBY8na1366i+AhLKTzeueBbaN9iv89pYSjsbdJRAqsc460H14rLaF7xhXSMCxgHMccniuOIo5D HMex5eNXHXVD9jwRjHPVYRRFF4Rj2pEDiltByELCz4hY7Si9zgVyd/hVWZZKLbL4bN3gxtAJZ9Gq 5Sk8WMuQakRMaY/IkL2FzyvVDWnqpsyMb21fC+dM+KF/1jVuqK0WWjYcvjuRIz9pGNFLqg7pnatD 1kqvlmXJSdJ5jhAR04Isy9hXJY7ju7u7t2/fskzOGPP06VNjzLNnz6bTaZs78pXpdPrw8DAeX3GO EnY05UZOp9Owl7z3s9ksL0sWb3jvHUCWZUw4rLXj8RiV4kiLv22riMcIPoVz+ICLcGhHyDqGy6Gu eVVcEngMjuW4Fp27vqzPw98py0rdivBfnYaG+8L2cTiGQ1afcLMJH4PXU1l/V0kUtNaRBiKKY5um 8WQyGo9H49EojmMiJKI0ikZxPErTOI4Ta4hoNBoBgGKOiQtvQKVUuF9ikPqrjY1O+WEcCymchZmr +ASusFheRSrlTg7kDNuOiYaLCnNzaeTaMhs3LNQQvRKOIVi7XTVe3MBCOwtpvK9Ozc6SdMR7RHSw /YYqhQvnEBkGm3865/LcsQ0Hu4fwt2y64WtbTh7b8/k8y7JXr17d3Nyw82qe5xwTjIkscw4Jnx82 g9fH2Ww2m82IWPmoZV64IIAKLvxg0ZflfDrN5/Miy5zzvnR3d3dpmnLyqmfWktbO888AoHvBxXUx Dfd17LtAwCHOONbZhXDsAnGeVwG9Dg9m/aN36biy2zgPdaYD72dHcbZUC2Nby3bVOGHuZajISnIM CUdjaW5vVG1xgg/8SyWFgTFGu4yFGSIzqD+qSphhLUs4CIFX50BuUZsZ1q3C2r6trcMOW9hwwOt/ UgyypfCfHEe55+drpVhLB/oVh2boYnJrUcmWXMlNFTGMX+elIju0jCQxhOwXtLiuSN5bY3cJh5Qj L24Q3dnh+C5tZuHEw8MDiy54HLPXYlEsAr/y8OORzPbU3vs8z2Wxs9ay9eizZ8/YqqMoCk5iyX4r 9/f37JjQ6K7QRpgt7YuiiONYCAf3idBc5hzOVWRIKeWRiAgInXNRFI1GI7YB0tZyl1/kHGcFYwyf 7jjK6pn7qpw5RB7PH2SjKctyyf69y4YjPNftuKNTHWBXouasAjeVj76TyYTPJItv5aYBfGhr9c3p jUbDMJ3t0NpMJeI4Zr1J4gsistZGNjJaJ3EcRTZJ4kgbVqOkSRLH1hjFgRGrl6FYo7ygAqy8r0Qp HtB17zGdJnUbgQMwt30UG8Dl19xAtQEE/hGCsiyV6tsgh4sKWF4i6SfyPN9IStEQbOzOKjpL8N7j CoeTNW+oqzmL5MAeEKDMC02qstJwHsS3pYuCLFQw1b9DzWND3c3DwwOLMfI8Z7bHUcwJrcj5+P4s yzgmN+tNOME6jy4AYP7BehNE5PXu119/vbu7e/78+XQ6ffr0aXsQ8tSz1v7yyy95XjJ955xnwi2g NTiZAPHwKJyfTqcs3rh/f/dwdz+dTp8/f66MSdO0zJzWGhUZY8KKh3sM9eMDDNu1HeT1XRjGyRGq YDZdJDsXc/ZzHm6Xw4KuPM+pXJ+ns7NGDCzoN9og4ECEo9HKnjaFgegbRosCYwzHLL+5uYldzgdx a+1kPL66uhqPR1EUJTaKoiiJ49FolCQRAJCHMEJA2DBEROflIIsrupUPi+J0J7aZq1Y3V2eVk4iH vPrzQr92Tdya07je3I9h53N4yva3EmkUgqcTaX9PvZ3VDRmCriua58Cx23lbQ9nUcc8AIadoDfor Hf6m1j4R24Ty0YTJROUc7yuLIul/SQ3I3kwcfiOKIrZ2CrUtWGM6nU6n07/97W9//OMfeS6wCQjU HklcMuvReKizXUjjETpp93w+V0qxZOWXX36J4zhN059//vnVm9fv3r179vx5FEXpeKSUipIYtwoz sxY87C9sYzhCAw5r7UVvFaKvN5a/EZUKHyY3ElGErukYRCfaosFQD/6N8tM657TWfMLZrtIQm9Im DS7IJbHz8Ku6smnnv7gIANy3lZTYg3K11b8n5yEvCkWkHKD3SpH2aIBSE10no5t0nMBUNGfj1F6l NiKIFUYax4lNYp1ERFACgI0sYknAivnK/XWhlsZFa1ftHlmWISKfHeViz+omBhCym/KZdbguBoLN bMneRVrLp29O9bFoeVl3Ml/oG7sin/dBfGvybj6foyvJO6uIvCPv6pN7s7SFUAQWGY299+T5hTr+ yapTLBE45xsddQx02wwshn7nnK+yhLR/FsyxtoSjk/cIp2lYL93d3cltDw8PdaFaa83aDVenE+Pb apOLarCNx+P5fD6bzcqyfP/+PetljDGj0ejPf/5zmqavX782xvz666+ffPLZP/zDPyBSnufsE1e3 gpyr6DUz/jRN2bZDRMQ8PoWQySpTZnkJmJcFy1ecc/f397OHaZ7nn3766X1ZJkkSGYvK10F8MehP 5r6rBkD/YoRZloktQj/nvoDRPgcOEZ5f0I1Abw5dWvien1IrAOZGsuROrMopXa1gkgLKE3gAD4Ra K3kIR0S+NjBoY2DbQt1r5xro92vD0dgypelSpatCT67cgImIj2IiHoiiKEmSq6ur29tbRFSooM6P wASN5R/GmEYi6Uq04Pmz4/bwOOAFVClVJbKq44e24ZYjgvDq3zOYJKAKtxxr9xNozfZOyNm0Mf58 cMPaQrjBm7qersrmeuhlKLR3GULznXN+OdP88a0E5N1Us6tqx9IN8rk98cJvWa7APIN9qjnSbhyN rbV5nvPezzxAdLQ8CNM05R+KJosHNs8gpZREzvjxxx/fvXs3nc5ZO9m2KErT9O7ujmthUYpYj/pl L+uGFoNHmvd+Op2GTjd5nr9+/frJkyd5njsAjrmutUZY9Iav+qfZJz3dHvxVTRM523WKpnxgCnZB A0ee6b8lhEu0mEaFlHcI/ZX+5z1iyIq96h01Mtb2gOUxvDH1/6RHdDGcHvnAQJN3f6384uy345DD 4N/u6p0D71259Jzo+X/VPsLSiNjoOI61UkmSTCaT61E6iSIAGEEGAETeKIihjHyhfW7RWiwNFJaM 8iUCRlGE4BRU61vjcMst1ErxQc/h0n+gyBMWpSOj8zw3pFqjZ+2rdUppRO8JHDpE9OT5Q3/3OXR8 J/8XdFzY8PBQwv/Hog9CAF9/2885GudsTUDgpvfvI6P4Mw1OpFKpY8CjLxGA6iQsrq3TqBi0UwTO N+3keVCu4untOxkbaDew44k8ePAEwKQfPHqPVXoVF56wgxqrqBKLKeOrU3sgCgpb1ajVe+/qRDUO oHDu57dvfR3jlRPBPzw8KPUQRdGzZ88i8KBIGz0vcofgvWc2gITzIveEzkHhnUPIygJIu8LBLAMA a+PSI5AuHEBeoiq//f570vr58+cvXrwIe41bwi4zsgy1XwTWzuoi5+C0aFmWuaLQWpd5Vs0UV2YP Dw/OTe/vlVKjt29Ho9HHH3/89OnT0pUAoIAAIFfsq1IArF41lgRl3OkLa7shmsoLLjgQGsfRgVhl FcFa+y2aEU7VSrpQC137U1YG5gvEoufwW2vtWitUaJGPTiLC9zArOp7RKBvPA0Dn6oLL3jiV0mQ0 Yt0w656ttZHPWbxRr3cqlIWwMFm+7awl7BEKUlfLdVbZsBkOW3vACkemVUOtkeS6E6uGXf+v/LKD 4vJ1cM4NJBydyPM8SZJOv9CweY2v5HwJOwsGQ8OC42OPW9dC6xSMt87z93w+ZxcSCRjKkcu9n19f X7PIgbmIr4OAMRBxPp+zFERGBetl7+/vwzaw+wkiFkXx/fffF0URRdH19TXUg0Tkaj2h6Bs+5FD7 jklFWZZJ7BxxY0GlAICfkZ3L4sloj7qPC9u44ORo2yet1afIDyHYg/YihxtiUcFMnU8XLGHtbDM/ 15ATICzvAo26whsqwoGB0Wn49R7B4uLqj1rgUF3BJQGUVaS1JsQkjjkNVRLFkbFWk1FoyYpPLNa+ ssw2+AN7tVT1rIiLupZLMufwVczQlRmhVi2dsoKvcp7cjm1AYNUYEg7XSpEQeAIPhQ8iym839Ney jf7AC9u5y3YK0veCpcZ0qbcYMnd8V2SOVT0i+3eWZfP5fDqdSlB/tk3O85xtMsQucj6fsxCCO4pZ BadVc3VwsLKWlGit3717x6+SKQW/3Ol0+vbt27u7u9CeWvySmMT0vAV5xeF4Y6HL/f09xw1jV5qf f/7ZWhslCQCwJex333337t27JElevHgRT0acO35riBA77PML/7jgOJB5zcdgvlgUBR+Mh4zDxrjd MTKKpG9c1drGFfGHkGU/yzJNC5MAtiLnAw+vHo1C5KAOwbIg4s9GpXLdOadDqtFzGtsFzDb6E5Gw SAMRFXit9ShNr66urq6uoiiKbZQkiSYwxiifG2MkFAcnieWVDhFZP9143865cMNoay7bb1przRaj Sqkq/Hntwcw3tD1de3psX1pkIYnysuRD5ybB+b0GFs5ji2r0NKBHwtH+djh2dEY/FaTrff1x1aiQ npnP5zyBOWbXdDrlKzJByrIE0MxFmDcAALvLwpKksAL7lcznc/AUfsWSNlkyeFH75ZdffvrppzRN uVi2NApbuPYNsrFUOEi40tlsxjyGZSqz2Qzu7qBOPvfu3TuO7l8UxT/+8f+ZzWZqFPfwxaoZvW0R Qy7YgShfcMGmkFmPdVYKmfsi8FiMxuVhufdR2nA2aW//4QbBM45tzJl2SKsUemut0RTHMdtyMSPh 1UPWZ1G5LhdfdlYnP/F1uML1KpXORXMjLIk3VlRhjNEITDW01mkcTcajUWqjyCbWKgWRsQAQm5iI WG/CAb4krHJDvDEQqxq2MI6rCUf4raTF6nki+bAvwiEQIYf8CQBac6UolYr708Bid1yy10o4htQ+ nCEdFPsSnLR7hJ1gWXnB3iUszGjQce9dnucciYuHIpt/8qQVPyO+WVaNIq/S74nfI9RecPw4XMt8 Pn94eGBywHngQpoy5CXyiQrrkEdQBwNovkEiAOCw67wsMr8pvfvDH/5AaonubIrtNOgXXLAX+Npi lDcdPrjKar+0lgYjvMcTddPF09W5OHxt/dYpVGhDqENjzXHgyrJ0VrOutuEqIXapku/Mex9UWlEK X1uJNlgOH6iKoliYqvYcNcLtU65LgwaeTdvnPwa/MERUipg9sC29iCs4UIlR2hhja7dYdihnwUb7 rDYE/Tezt7pzTghHY0A0+gRbNBYRPS3Yxh6FHNDaEf2y+8wWdTU0eZ0lNAZ0+HkXqtFoxr6K2g7O OTZbXmrGapXK4gr+/+y92ZMcR5If7B4ZedTRB5ogQHC4XA6/0XzaXclMphc96a/Xs/Qgk/SNja3t SrMaDgECYB91ZmaEfw+/DC+vzKzq6kaDxyzcYI2qrDwiIiM8fn7ruTL8FQebpmnbdr1eAxNsNhso OdTCYl6ra5pG68QWRZFlGewdWM/IFWYf1LZt23TaURyB6VDNH1ZGQYowfF6tVk3TnD5LkXPMOpRp /kq9f+/DZrOBgnC5XDLzjzfXzPzV//v/qDr6EfQJanyin4V6C1zBNBHFGPOTk1sMNfGnsz6VOWPK 7zxEFcPPZIy5mh/BdCrGGJmShWW/IyrGUFKHQ/LR5of9UpTwf7copAMcyp44lfygE/jO4dU+Aj6c oxBi4r17fC3LMu9dlfvpdFIWvqqqSe6997NpWeZumvmMXck0ydzZ2YyZ8/2oPLRZGzNUb9yrWemd oxC1q+6WGqrsGPihp7cYBWS9G44++nHU03DoU/DZpSLm1szWo1GMqHsGmwhV+6I1qPjRLbcNGLZB fs11LIfjrG/E8gXYGoAzFosFtB0yMDgyO0ABiBqbzcYW3MLb713SNE1orczRvUeFMmQmvKTCbBhz 6EUOdcT2USUkaFxUlXLcoR0aFPx98+YNOc6ybMXht7/97RdffPEI9x2cP51OH3TVJ/pEH069uQp3 B0rTe6jDsL5rLLtQQxzH5EdmpXvKC1mfB01iJLJerpxzEnZbfhOC3rkHPqAi1aqQ+7cF1OiUnaPK ZtwEl++nou7S4WAQIAuBs4EjgeGLzcMhSSn0hKJDz0lVKUsE+8j5bD6bzWbTKs/znCHPuaqqMnaa ZgNgqMz39r9HWCtsS4Y9lX2XzBijng69mXMOgKOX86N3Q+ixNWHX6Y3UM7Uw22gXeu3UTrmU6Nr2 0W7th9RRCFiwTip2ozpyYQ9Zn9jN3t0s1BjI+ifREISNnjNyJB3Ech1XsZyg4Rg6jXYdIaK0+LEg sbu3ifZdN5QYSzfGCBEK4AOCgiRvHj07reeRXuOhsDlKKth2d3fnnJvNZsvlEn4eEsKhVL896qXi ICJY7oqiCInT4SZ6IzW+oFNZ7m9vb//whz88e/bs888/P/FFp/eC6dE1wKIrGrziJ1ErfqJPZKm3 T2vZ1Q+554lWgt5+qhwDy0qFEJdsH0MNB8QM6zG26xeJiMTQ6M2PxKwBuJhSJLuGqaCLX/FXWda4 v8npPT9OYmIfwIayLEPkf+Fz57iqyrIsz+fVdFpOy4KIPImnWGQ+Z8o9FTlXZV6VeVk459jix556 48OJU8SpjoPVcJg9vtveFPEcRGldZpEHtFBxjA1EpH1NySE26pwmd8XbEZPxoSORoH/NzR1RbJpt nmdE0Tk6GTns6EGAY/RMqxKgw5hDxi659yly+CcySggRGQEVpwGOQaeYiDYJW2CJwhixWq2Wy+Xb t29Xq5Vdn0TUlVhNpe23sWnqrpYstB1lWcYoTROaOlASRA5ps2LyFVWjSVmW+OqcQ2k3kJ2jx52u cG0v0z++YiGEVILSvht1XwXiWa1W2Xxye33T1l3D3CD9oo7h/nALEbFwJxSa85hGMu6wXsKHivB8 RHo04jl9KX2in4tiSgEMy6B914feezSRB3YPHUafDkUySukZh5wWB5EaWEQyIyVaaIKFeSjSFaqL 0NYw18pAh2rBxGB+7iAFpc1LFR4qybRtuwc4nnb/7hFUT9575zL4bcBjYzqdzmfT2WzmkVpDIpzP YRpAvCt8c5jZ7p3W+nOiFkHGYlJ6FG1O8SQ12s3eOWteYYs8+vc6mduMGmV6gGN0A1ZgNLxnD7Ic oZ5c65xr276Wmw9kArX47EO4pFUa3aOoMJccO+3hjTmkkDtdw6GrNIQQo8QY19utSgN1XTdNc3d3 t0ykOUZpxx0cEWlGeU5xrWSWsTZVQ9fo8NxWDqWopW1bJMagFHJCRH6/cv2R0eu9a0TzQ4kCxZ6I II2NtkYZi7KXpmlubm7+8R//sW3br7766tmzZ5PJhE6LzG/b9nBC9E/0q6FfO6jCysJGNplMsAXo Bm/007tu6nHbd8gMWDV6mgUWqi043h6c1rZtZlaoDZsXEcg8NOqOGdsQgsQWl6jUocIY7S/PffGg 8+oYNomMbaUPOI6QBSKHeh7jTphWvCMGbeFDzlRmbloW06qcTifn52dz+Io6AuBg5qrIsyzLs6wq 8umknFQFS3S8x2V8lnH6y0SZc6P7D+877ml7hghOAcSQd0uyN5Fhx8pGT4E7R07QJv3EGmA76WMq gE4dEKYQ2t5LP8wgBMO5tx0f6sqgOMvuiv3ZTAdY0omA46Gk+/oIeDoNcFByCwVtTcwIoIaILJfL u7u7zWazWm2Wy/VqtSHVahDjycycRonbNjjnYsRqEiJBJRrv8+22jlHatsM3RCTSGW6Gnjf24Gaz mUwm0Hno8WgG8xTWNrw/HXDN0dNcqhvXtO1yuZyEs3+8W9xd32yWq9///vfF5x7aF9z/0KuNhDi9 DuaeqBU7Tp8sL3+V9CBA8whaLXjHAAAgAElEQVT0A20lTJNImahbAxZCWnF7VRKHu7LGneEqdY2y iOF4U6GcsN9VWw8IosKn/WwphOAoNk3DtDPaqlOIfuixaP26Xi97qhf0RS/Um5wEOKy/wr0vZogw KGXawE2gg5pMJrPZbDqdIpdGWZaOxTmXSXTOecd5nhfeawHurg0HOMO47t3gBjuC2rwTDUOWLON+ ErTxkegR60fHWYfFjs+hG364bsM+nfax3RGTyig6OX2W7u6WzmyaBsXSRu5wskkFeovOxhkiRAqw AziKrlarxWIBwIHa9E3TWHmdmYuioK7YUqdmg9O4RsYjllVJr7Vyib1h27aIrVdAud1uoTLcOVw/ MMLLvhpNiO5SmlrZV5Jg7aMNi8ViU28h8TDz999/n2XZ2dnZfD5HO09UVX5CCZ/o56WYCF5Wiqep 74/V6S2sAUH3JnV7ouQboQijBzh6G6td5oAIu7WckmfoTt/TkajSAqygW7wUiYj3wz702lHzCu/c 0jvvNHUc0SgVPR9/PQ1CIod0inXKNkU/g8fpJVnGZVnOCj+ZTGZVNS3LyvvK+9y7zJEnYpLMsXNc eJd7lzE5EqbgOBIz8Uj06fFm9N5K74Qea75XSuudeewE066fEY4c70sPT6h2XcFZb0ocwRzDwTxO vS4PH3RkR5GBh+ARnLGb8QdarqoYe20fdpwGOJxzqAgPQ0lMcAHLb71eQ72xXK43m8122ywWS4ku xh0PYmbvM5JxZ+GYcgI650ajQkbfArZ2K9ao8GHNZPLAQCreD2XCPW14VAi7mkl1XSOiBDy3qqrN ZuOEmCg27Xa1/uP/94fcZV9//TVHmc/nKLlCRGJK8ggTM0e5Z5EOZ4V+/YRRPtEHkq4j6DKxi08m k7Isu019sMso4Bglq8DA+tXoD+XDR7TLw6XtnMs1/XGCLIo8kCQQx6F2VYdTAI7MERmxEwvNqih6 x1NDuiWvAf+4s12MLlVQ38tufi89VCsA5IVUXZNJmWXZs/m0qqpZNSnLssjzsiwRsZI7ZuaMKcuy Ms+cc95lti7JEakX5/T2SEUYYpRCcVCbahR2jHacTUbn4Wn7sKx/+YnM7tFssVPopa/W3n8KWXkX M+n0KfFQtHH63UZva6vFcnK1+fC9BD5GVgQ51Lz+ke6v3NzcIOSscwVPUAZqUqQVv7u722zgRhp7 L0iSlnLUOVytv6qVVU5xvHmUJlU0DmtDOG5DXE7xpDm+TPAZtV06fw6DToqs8N5vmlq79sMPP/yX //Jffv/73/+H//AfUCPX5taz84HZ0RjEHGq5PtEnOk4P5VpYyG3b1nUdmkZtH9ieW2nbtu1NPu+9 mlTIeGv1VO/2K5aqRRKj7YwpYK3HQ+q6Xu/nBoSKdHgrgIPdmbEVER4ktggpZl6NztpOBTRt2yUT giDUNM1yubTGIxEBBjjJpGL1pScSTtY6akXhz87OprOqLMur6aQsy0mJ9KCS5/m0rJjZMznnvKMs y3KfaQZlyyUPaTisb7xtsw4ZLu8NwendOb6lDZEQ8/3D1ZsrH+ixa209jzAVwT8XisEsy07PT0on Aw57Tq+n9uvxu/Xeghz2mX0QqdSidZj22rCn4ejjIbgbbLabGOPr16/X6zXEiEgwo2ZgH3d3d+/e 3SwWC4kp8ol8CP1gd0lV5oeNHH2tlgU4lzHve9KYa4+pcPavOWXb1gun0+lqtQqpCNyhR9goX3im QcPhnPPsNk29vL37P//0z+vF8j/9p/80KUrnMhIJe2+BRHZxKbzvRn3vDDwyrT5hFPo4g/CEcsjT 0qEtnJJGsLdeWLpLUPlIBL6VO1uJXs4j99zLl0VJqxFSqqdeYzilEldNoR6xpo0jOg9KdhBJXqKK PJzJd6BPgWGFYtu2rcTWcmAdCvA0O4CSTC11XS+XdzHGy8tLPEITdWy3W7iLIVVPnufeatFH34c2 cSh49QJsmJlSNgJIzEAbeZ5Pp9X5+flsPimK4qwqq6oq86KqKucoy7LS50TkJBJR4R0AB5tgudGR 3X9uRz3XP9tsa/qy3HDY94du2GyoKyeRWjSq+1XZtLcHfAjgQLPZPT5xliI8Z9IbWFX5ITolHKZ3 wvGeDu/2IEPeON13B2gOhjuxc86yETabtwKO9Xp9fXP3L//yL69fv9Y3njQcHitzsVjc3d2JCPwz 4r6/he6dh4LWTD+O6cBEZAg4cH5d10VRSHKG5/2Cf4/eGXpzQ4UTRM/qCW3bLhYLfM5yD8NKCAEq EFyyXq/fv3//X//rf/2P//E/VlU1m82Enb2/iEiXh2PnFtfr5if6REPq8QcV60ePb7dbdeTEcZZu YiNNsIiAM1IUIvLeb7fbMi9ijL0pGEIYmlSCybPX2x2CybKjm3pMyYXFBDqos4g92DU48RD0An4h ViEKGKFYpHtobImIZAdWwiAnofIoHO/lDATOgEcXYmu1tgacxkZqqaCTVtruQTAdoF4mMls1rWMr WQYPuOl0OptNptNpWRYa71oUvih8kXlmdizMnUeoY3JGiNG/kIeEd6z5EFkmPirYnYK7d/NAdi0Z JYwVM6OeXHcyd3q2IYCNxtemJxF+uJk5PjYFTYxR/XNpANcwXQ7d+WnlmCEXGB2THS84bcQONdLO lh4CoB3e3QMcaOFOC8rUNM133333/v37m5sbPTNKSUQi3TLZrOsYmIgtQ+mpQ08cyeESOA5BMAlt diA9uFvmYm7l7rem6fjc3d0R0Ww2U3UmTsiyjEIITeOci21LRHXbuqoiIkeUEeWZZ58TEYeYs4vs pGmb9ebux+t/+ef/fXFx8eLFi0k1bagm+KXChSvPnXMicQg48PUT7PhXQg8Scg5Jlb2dWBUP7X7p AJZul9X8vA18LaPohdAB6OQbZZityUlqc1TYc7S4kk5vxRzaNvwE6INKbHompcRfqhGxqhG1QVMS JjUot/Auxlhv1977u7s7WDZvb2+n0+lms6mqCjud6l2cc6vVKkmnwszr9Rr120UEigYaODbcb1KJ x+IhRwi7JjTzVVUh2cZkUqL6iffeZwAchfc+B8ehnTKKHyWpwD49BEaSvGNGubkePJ3XHyFgjvSZ 6EAucGWLvJ/Zwj0qcaoSLOXETh93yCyiPe0FpCARApqhx1Xg1vK5x7UdH073iq3yRGaUHsUYEUhS FGXv+Hi8daIQwnK5hCVFbaUxxmgCgNUi2xNferDp9EnYO7Nnk7I/qT4TchhgsdVmpat2qVDEGGiP N0k53V45iTxvmgbST8+tCpl49GR7cxwXkbu7uz//+c+LxaJpmmeXV2dnZ6gMB8AhUC+7bHTExNTQ OnEkfy56Wpj+r416y+fIaaOfQUAbuoNaBWc/2ksIv0aTHCHG6GhXSRWQHdMOJv7EivsgA9BE83/H uBeJquxXTR5ojN5BRFASgRKqgOuYMvzM+CyKMWgCHDjnoOnUzuFxCPGFbhJH7u7usixTY6gz6f7E JARq29Y5EhGkMwaTsXe2WOdhm4cOQWoucmRp07vkQj4nZinLbDor5oUvCneW8dS7qfOFL2alK/PM cyydZGzVNX3riZVXItMwKhbdVqhhO3bKXDxiOtntxERElLmM0QCmyJRlWWQ0idEw55h9tstlbm6l SmP9+jFqonbz+75kihJ2a0OidB+Y1F8S+4SO3pCh2yOomT461MOcjzgtKfH3RqDLCMeOiBw5pITs StZ0o85EROKY2MkuwSs55jiiGRo2KPA9ih8FATq9d/ZOm7onBmYWprYNEjnG+PqHH969e7dtYt3K psaAOiKX5o4TkRi5bSUERbcUQlSjAxGJIHf+Kdvk6DkIyUPW0Z7RkNoWEhJtNlsRms1mzK6uG2dS 5bLLnGNBqnex6WvGzTT6CAxaxo5SPQgWcsQiUuZFWzcUJcRu/ueZD03LZQqghX0kzck88zFEZrdZ rb3L/vlusXq5evny5fn5ORhLnudBtszsqOP7jjofUmGiGIgcMUfHTJy5rJs73bCxo3z3uk8Y6A+n nx5V3FuPY5R++hysRI66VMgjNOyFrl6LgzG6Qx5l+S04W8803y32tpW2BWvKiJo2cIqKyqJo2mZk jpG2bZqG0xEWoigxBImRpZvDpItGBHtz27Yx1pvN5u7uznu/2Wysi0Lbtqhr2ANG2lTAC83uox96 l8BtYrvdorBivVm3bVuWpeIDu+l478mx1k3kzIlE51xkx96vt20TY+1cEAmwdTBTnm+Zm2T6aNu2 idE5t6rroiiic947Zm5TsdUWTi1dPrHokA4EpdNso+1r22mM7a6ffEwSRyYRybLdi0xmlBz6jOl0 Wvk8z/OqLFHc1XufZQj/83pb3TAeIZeM6i1OucqiDetUMXo5YE2vuAkPyPZFHzTcDod2FnqUp+co Hem+vkpOtS06DRvJMAjWtgqLNs/zXsuZGeIszHUPaCT1ecTp135ssm+TBi/LfhWR5XLZtu0//dM/ /eX1DyISIznnkpcGeGJn9USteTJGjV50u6RkoEcaRgccXHraiON4EZwOplZorawrmewHKKUVcdAg BfZnL1HVqxUDQJCTdKZZBzKrKVFN73K5vL6+rusaS28+n5dnMwgYVjkM6Enq3H0fuPzJ6NET+yfQ 0Oxtch/7YU9E+2hDMI1DqoJEpni6nt87QsZ/2ap47VyVgbEb61ePqFajU5BEISLeD0JRAWa5vGkT 6U3Ab51zSNtjzTr263w+f//+vXZQRNbrdYyxqirkD0QO7svLSxu5pt2EPkP7WBTFZrPpMRl4OOjC BBDBYC4Wi9lspmPVti1Km6G6mfpgxRivr99DxY47YKMfvrgYo4ehpa9BMmTQVm2VTkQU497CyLLM ZeQcozVVnld5XhZ5URQ+83mee++Kwnsnbr/yWW9LfoRG9BG7dQ9UWh3RaFxir3kYXE7GI2W4Q+W2 5bAgqLh1WotxGNQoiQ+k429T/UjSURIRPLrXVMxX9U3p7SsYB0kORA9o3/7rfZzfydPSg9pQb1sM 3na7fffu3fv379s2brfbIq9iiERYn2BznXK1J5f0DF4Y23un8fF1MYpF1LXCms9iysPByZPD+y4o uteSUcChuFwNlwplet1RIAsjC4SwEEJZlj332N7CAcat63q5XIqIRskGJu+985n3PpoOogJtZGFm YrKg5F46ERb8BCDg5yLVdD45HR7bvqc5vnYtSUfUa6Gn4aB9iED7xcZ0WlqnyJ6Qud1uNRk/jqxW K+/2UjDc3NxMp1Pc5+7ubjqdwqyA+2w2G2lD0zSxDUQkyfwRk59mihNZd2EgadVrF3DCer0OIaA6 I7IAv3//vqoqiLiKlpbLJYo+YsHC8KFwwXYtad+JnWOfFVnhnKtyT0Sz4izGmFclMcOrAYJQ27ZE cTqft7e3VVXhPkAbaOezZ8/evn1LRNPp9OLi4vz8/OrqinbLtts6sSGq+qR7U9xJ+G3bethHOyvp gXiK9DqbHlQ0LgusWy8QUFVVRZaVZZn7DL4a4AvOuSzb+SsMpUkakIpcvB8Ip78qDa8lY2bW83t/ aV/oHL2VckPvfZZ1fFkBh0KKoSZjtM02x0CvqYcG4TiJdHmbrJx65GTN6IAjkfbchJXi0XDo3myJ j/JXtRqXXwLsgBtBD1r1aLPZROEY42q1ur29vb6+VlNlcHs2Tsyouq6VSekLsgK6ek7cu/ONzg1t KifF1eh9jPmmY767CdAZYp0NLkPbwPLsu7ZzLJhUAfahuq6HSXSYWfcGuwx1Ttpn1XUNnzj1/Ggk FkVRVGVd18KMNjvnfJGLCDm8uHgKY/nYJCLj5q9/HXQijAPpCmJjJenNup42goh4P2mN/Qy3hqFU ifS+w80OZzbbLp+ErtZ3795J8pl4//491jLcJpiZo9R1DZfSbdJeSNJDpHt3fhtVVb19+/b8/ByK GUqpt2AHASKXlPgL98f85wQOYDfRDI0oBdBlsUriYowRqmg8GyfrMry4uECwWFVVgAXqugfQcHFx YUcGi6gsy7Isv/32WyhU4EAKXpEwwLG0ERbIejAUbJy9d2DDhS1zgThrTwaoKYpiPpkURTGbTSeT ic+yqqpQFaXM8qIoEKWSuZ2VQf8On346ySAapfcr7TNEZbh24iosHfJ9HUo9jrG2mULYqDrstWDW p2+lP9e+izeoynA6ENBraRgP+eiWf8jbfyoC1BCRPPdEJCmCozcZwHFW623btovF8vr65vZmEdpu dcBhqqomzrnttg2hc0QdFeZoH8wdD4jtLRna30TT6J06hj2MLiJBunUtyVKrTN/Crx5Q0K+jr0+S ixURgbvhCPKdjLWfaH9ehRBg/AbDXa1Ws+18Pp9vV2vwWWamPCuKIg+l954zx8zinRVpaDfOBhI9 ZLz+inUbH5VOwdCU8G73OfRdqXgwu4YMeUgoI9BTdegl2Nq2263uccFkrQhNl6U7pipIRITsmfP5 /O3bt9A0MHNGnGUZC61Wq3q7BVYoiuL8/Pzm5ub29raqqrpeMfNsNkPdRGgvfHJ3gBqPktdqCEHj QSiFugBwUHI9QcT4er1WGGHdBJ1zpS+RThOplZAIlZM2+vPPP9d8S0jGhauEO7Y/HMyqqlBFFStR jyuHDKE5/qL1lflRTbi+hg73NQ0RxbhjiHZ3QTQKzCjoG/6WRVGWpXfsnMt9rp3MHFj5brM/1E+l oZKg11odcXTHao9pzHrSY5GKalUq7Rl9dPuxwEINDVbVYduJBx2SSh/d349HQ8Rgj+hnq9RRehxi sEj8EZc/LaFH8EpxJhmJJZXs1TABTtSpMUIIIZRlhbXdti1i0w/davj0Q6QnDwfqlKkynJZ2M2Bj 2lNdixitCRnLdK89h+C+jCmKXHJ0V4Xw8Y6jGZD2KOXqgMIDLJWZneQiEkTKsnSSMTM7r8bfoQzw iX4yOgVtkInSJCJOWy9p/OfAwK0v9ND8iaaeAJQHb968sbM0Jg8MNShoDIhzDmm+8BScgGuLolAQ s9ls1ut1RiwieeZhJQeYxk4nyQ5IqXqR7iyY1WrrxBLrQji9jzFOp1P4LYlInuchhNlsBrtGCKEo isvLS+fcYrHIsmw+nwOC6Mj4PHPOYYFMp1OUW3fO4S8zQ73R4+EAHCAr/GC/U96IO/cGvG1r64Yy fLlKfviDhtwAcJmT91Sm2prC+zzLJmU5rSoU6q0QA+vzMi+8I2Z2LKjN5pxjF1y2l9ugx/gsKdej AyT7KYB6U0qPiHGYGOJuO+coefQMx04xh6o0FGpwygveu+oUZicmHUIPG9nLLa4/cSU/lO7dAOxp CuagXjsuoI/SL8SMYumEJjmRXSpAEFaKiDiX4chms1HvliEU0znZU7NZG+Whx+tGrrPx3k4dAnO9 CWYXu94/dHF6fee74UIbEiZG7+B2u4WuWJfYkS4o9I/JBQ9sHTJiNxQkLJRlWWxb1FvhWlyet9Tq whTjCWsft7M/fyITG/Ih7MXOkONTUwYlvohITJkSfIgDxoJ3CoajvlAA/W3KnwGggGSXm81ms9n8 6U9/evHiBRGtVqubmxtmvry8nM/nt7e3Gvpxe3vrvZ+UVQgBHhuwnFKazFBswJSTZVlsWhGpQw3t heKY8/Pz6+trK6EBiOhycM7N53MErRCRjUh4/vz569evoVR4+fLl999/X1XVl19+Ce2CulAgPQa0 FBD1Ee5OakbxDlkM1OBSliXQw2w225NA9gb3ntWgSn3l/+CZeT4uU+02YiYi6qJl9CjeWdivaZso KqdTUR4GnjzPUfR1Op3OZrPMdbbVLMsyR865LBmqoaylj6ClDCkuWfWoQxqaovWzxSsycP9Usjag Hsd/kIy+x/XGdo57lRy2/UaOvCd9wnDDIKIocbvdzmYzrAftWs95VjU9YgrZ67DLWDzOQeJdx38h 5JxTb6njpJhVlbFgQ3rCarWaTqdJL9ghkp48MYxto5Qzo2c6AVm4yftJQkf7oh/s53v7ZR9hNRzg sEeWD41Nud4RlwzPlHCMGBPtoRZilDDrQgjsHARTr9V/UF8atkuYgTqYsgt1Pt7xTwQavtPH3USS h+BxXmTnv0ZtwIShkRrb7bY2lcBCCIvF4vb2loiWy+WLFy/+1//6X7jJN99889//+3//9ttvVVdh VWjIkfPdd98hE//d3R18M9VrEnN7sVg8f/78+voaCbnbtr28vESyLxVrYSXsrYWzs7PNeu29v729 ff78OY5DaSHSQaKrqyvURsbUnU6n8/kcqo7ZbOacm06nSJz11VdfUVryL168KMuyqqrPPvusruvf /OY36N3l5SWZkhSAHZonCYBDmweOAVIxYMdS7Fs5Cjh0SPUOkiwDZLZRpX0NComIt69HX6pFG0Ca WZbleaayAkazqgo4acxm07Oz+fn5vCzySVWyROfcfFplWYagC6boHDFLlrEb5Ns4kUb3YDF24hNv 0juiGFl/6m08o/ydE1m1R0/aOyLAWZXAEWzx0/DKtm3hs+1S2c+hKYrMvqJbxaNr0/wCCTKHfj7S ne12u9ls67p+//56vd6GIE0TIjkiJ0TMLgS5u1tCCIOpBUgiDFLAtSnbYGYSdDp3bIHwYW/WHllx 6pTzKalSsyyDHNIzxNDht3wIbRzSWcq+TVNbCDEO8X72KrjxU1p3s9ms3m7x2ef5NmXyqLwXEmES F51znBJBghWiKcORtYndRtntvej/Y5Ot8vMLJAQfEQI3RDQvuL5Wnfli/DGxy5B5+3CffP36tWay WiwWq8ViuVxuk4eEpGqgbdvCoxN6gv/23/6bc+4Pf/iDJMVhkWg6ncISx8w3NzdQkjGzRk451+VL fP78+eXl5Wq1msymzbZu2/bs7Ozu7k5N7QBGRVG8ePHihx9+IOe++uqrGON8PvfeLxaLZ1dXRDSb z199+SURvX//3rlY1/XXX399eXn5zTfffP/993meX11dzWazi4sLbP+TyQR3gLyBPjIzOBJgVtu2 i8VC+TPQjFo31MrPzJx1cSJ5ntd1PZlM2rZFueYjxKj/lRbDcMJbFSzIbmHDKdG/nIg5aTg4OVKE RIrmtPNkJHtAKiAmeGyodacoCkedsOu9R5pVZ+JIbQeOD8G9pCw7pnB859x6vVb9FTCjDodOLBpT BWO7HaouRkm7o5ij17tRXboS1D+qGNB7PnAAOpJBlMqDLocIbgGHHu+dhhN6icvifnKFD6ThRqXd OfI+nmpLgA0VC7X3k0Lz7XYLkzDsuIDpKa/oniMknNV7crZLHrIqM6kWgQ7Yy0a7drzLj0sIG1Jg /fBt3qsquFfDISJYjC5F5eA4ph8RTSYTsEU16iMijAZTcbFYwL0Oqmxgu6Zpmrs7731eFjFGqber 1cqXxWw2m0wmIkL0QZPkQcuqW4lP8Sy1KJ125UlnnTgO9qFDbqa5MuHbS0Tr9dqZQHoI3IAO6/Ua Tpowc8CKEUL48ccfN5vNarVaLpe4rbLTL7/8crPZtHX9/v17IoIRAR4SQAk//PDDJpH1eVc/ZeVp yo3VMgK5+tmzZ1B+qBm0LMvf/va3IQSaCbSeWBFE9Pz5c+/9+/fvJ5PJ5eXl3/zN33gjPH/+2XNK PBz2Gufc7373u8xFToUvXr161RtDbJ3aVGdSLVDy5Seis7OzzsAUY9u2iLXRN6IbFnyxETQO30ps ytisj790ZsqyzPlsdHqMXpullJvK4pT6kbEab6H8DiDDhmnEVO7BbqU7W0mWZZ6L0hdF7n2WO5c7 lzGxxNwxkRREBRFnTEQs7Kjbm1l2w/SINdzreTQpJdjkDxjd7BVch6OZNiwdGnp9x7wf+zcKboak XiAYeZ2mJ7bqEXR8qMG+9b1TQp9244FAcMjSNPQkOkJurC0qgNp/1Nnp8RTin8rijsmps0hBeFO3 N9e3i8VKRLabZrtpYiQRVnOE+dtfh3orfYoOuI7qnkRubCs6+a2eSe+jwWn39qvXmOGvNFA/0NNl paMD6hblPOo3tt1uEfU31OgwM0WRECkKRSEnEqOLQm2IJE3SyAp3Mb2lz2NZHkHzNq/lMI19TC28 t2sjkPGDtX7MTCLo6RPyB5Un6WjX3r59e3V19cMPPyDpgk6DDt41DewRWBvY+N+/f2/hER6EZCoa BqgnhBBQDu3Nmzdt2xZFISFcXFwURSHO/cv/+T8uZZDDpoMHITO3ThWI+5RiOiBbu+SbKUYzgSZB SH716hUA68uXL9+8eXN2dhZjnM1mGjDRRXa47Ntvv7XuF69evVLdSUbMh9PncKpdqv6hw0mIhbxb /kQuy4QoL3a5s5i5yMqi3GkUMn/b85nTR+R5PplVClwm0zkbp8NjcwJRKg+ZYiEEvGCd+iQSwd96 azZ92OU8hx4MBHWT3U2x7IFYYSuaTCZ5wfBtsXE+CtA6tOWYuUMbQ6xAh2TZR5kYrNHuQ1ikS+6f dn5YyDXsS88IHQ5UGLcEoK1qlePnHxdnP5wU/td1rW49ItLTjOka6M3gp1JvfAjZuWFnyUPHTdW8 u5jPrtxiXC6XP7x7//r1a+QH3G6axWIBNfKo/kUZa7Zf6MeS6jmcccXVZjPvFs5w66WjK8JaW3uX WEDTI8R89W57BKMcpxMnBnYF7GHob7LkjlTAYmbhvYLGov40FIk6/SoAh4+5ugT6lP/myJQYdlLS Q0ebre/rceOjPTp+gmbyPVH0PH7PaKqH6J6tJnURAQeA78K7d++ICEmf4P2A89+9ewdNhoZKXl9f X19ft22Lc5qmwd6Mx61WK+tHSUb8UxNMCCE0DZwSNpsNVBpFUTRNg5gL8FX10MQlZVlCQQv/DE5q eHWWPDs7g73j4uICH66urj777DOYJF68ePH1119jI7Ojh73Pu8wm36T9l642u1NoBDcnd9HenHQp o5U9qLtbjBEGLBVddNdD0Epe+tG3z8d9vziKSDhQxGCU8+hTOAXjaGMOCdueTDpYnXBIJ9B7BoYG 2KIsy/l8XniZTiaTqg42QP0AACAASURBVCjLvPK+8K5iLkRyl5VFyXhtIkzEx+tfPZysMDFUbKgS 7HTSjV97bdeGHVkNLiKzH1gx1F41erx3W7XOPkjP0dsw0iNOqrllSedH3E8/GpOroD2tRYm4lOv9 o2Kgp6KHDgWlsVWO1jYSo8Qgq+X6++/f/PDDu822aZpmtdpsNptt3Ugk2Sv/sNNSyFFfWpjVFOCS Wdv2/d4LN6uqsqmXhz3atSyp94atEkO9q46o9I8vtAchUeiKwfdTTGB/UbAQMUfegQwnLjRtCy00 ch8jzTlTbIOEWJebMi/KsqQYuKvhQvaeYsyRhyS8mM45cToNT1OOMXL2UQzUNI0j6nRow6ePXYiX MlrnSFV3KDcYUvEwaBrUS2CxWIjI3d0d9BObzeabb75BUpl//ud/JqKbm5vnz58XRYHEEldXV/P5 PGNebTZ/+fOfsSP+JUZ4UN7e3sYYQ9tycmlUQxgkdaRJuLq8vLu7Az+8uLhYrVbYdBDz+dlnn71+ /RoJLWKKB4FDxtnZGUJDX716hegSnXiwlWDDIqI8z1++fPns2bO/+7u/K8sSd3779u3nn3+O86+v r6+urgDuvffX19dwz9QbwkIU271EkfE+9+SmaWIq1JKWs0CJMtQNO+eKvPB5TslPgExceowxD0UI AeYPJSiBiqqkzB0CFkfnbkZMGY26f4q9VNJUZGKR3YrJklYpxpgdEKG7gPVgMiGCEw33TmAueMM6 52azWZlTWZZVmRdFUfo8M9m+7YWP2Jb06cNrlflaLqxP5JTeRJ11H/pou+v0FN2qE9MPtnmjqprR XuBXQLoevz6CQIc7kO0dHsgmQnj4xFHCDA4pQZm1C8q+ewEldP9L0Gd8OClEo/3x0YWgG7+qOtbr 9Y8//vj+/fs2yHq93mzq7XYLNjLcqORky50YS1Zd11ANcspRyymw88hLdF3CTbq3LqB1Hxm2QfmF Hg9dBt6D3mHHO2XPHy7b3j1RkRi5FIFonRtEr0jXKlVsMHPbtpw55xwxe+87fkhERG3brtdrchxC KPK+o1V3yxMAB3zsj/T3CJfrCSejl4zeHGuTTLV08FhoI6qqur29xT7aYyMQHTcpvgNahxijBiGK iIaMQsJEyvk//vGPOhvxYbVawQ/j4uICqTahB21Ttm/gEnWUQWVzSGXQScDhAIFaWZahLxoeQsl6 ++zZM+89AjSIaD6fo5vAH5999tmrV69E5O3bt3//93//xz/+sa7rsizPz8+JqCgKKNoxwtPp9DwR 7vaHP/yBmeGl4Zz7h3/4B6zNy8vLzWajDxWR6XQKoRr+IrYsiCSzpvc+Eqsa+17LFBHleQ5spPNf /TZ6dmrItBntnCZxXBUhGNXRp8AEgaqiRxpziOy2O1y5h84cvdWh4z4Z1VoiqusNnlQUOw0B0obg dSJyUk0qjreZTxGwTIXvAn68redGRCneHTgNhbuUn97bsUPsiQ44fuqqxuskYyIZHYJTSNugppOe kmPYjOOSH6fsHT2E8WiEhOQQD70WpHxteFv81GvkcLv6tZA2e9d+cwSKWRqgDSj+NuumacJmU282 ddPGm5u7ECKlja23Udn9+3iTLJjDB4CGLOWx7UnGoytZ9XMnDoLsl7/RVuJgzzws+65dH4/QKk7W W3Sqv74A7xLaiBoNsa0dMTmWGHNY9NMFm5u79d2iPT/Pys1kMkGvR0wnAzZ93J49lKzowNsRoxoc WmnxU1VVf/nLX5xzV1dX2Gg1iAM93a43uEQNCjc/XjdN88PrNzc3Nz+gZPF2u21qPc1a07zfZUDA +726ugohADrEGP/v//2/zrm7uzuwTZyDO6zXa+/9crmEdIqoVISQVFUFj8vVagWfSlhqdDaen5/X dV0Uxdu3b10i9eiPqRrIu3fvsMUgVcZ8PkcQaYwRPpWXl5evXr36N//m3yBe4d/+239L++HfRPSn P/0JfAyXTCaTPM9x5OXLl/P5HFAJrhuKFXqrBvk0iaiqKjVeWFJ3yCFkHySS2GM4s7N5TKkC1eLj U9Jq6whIxq9ozzrssowyIpoVOV5QVVXW6u2cE8f8WJ8ESydCltEbHhGQfEoQFkcNCorKq6o6OzvL 83w2m6lNgZPzLfjiKQ0NIWRuT2M8hPl2PzsycHqH3ozRAH1VrNlOWWxod9meUWbIuxUfKFbQFupY Hen4kDB6ylOOMCx7AplR6klLzExyUMnRgxT2Whu501NyWMPhL1axMaLRMZ9VsNaT987fRwYxRqK9 NFNwOIN64/b2FmIK5MLu3RFRf3PqbnU6BBx2Qbco0HEvH+wE6i5nO37ocb1x0O6DG1qNtAz0cKe0 /3GEzS/fKZMzVfDgBJZuqqt62SW/QhHhzGVZFoeNydz19fX8MoM/KXNXtp5NRMAwTZW+095iV65y pNf67rSdbSqri+N2NbVt++OPPy4Wi+Vy+Ze//AXxGmojU+Rxd3eHaA785L2H8h93RrTFervByZq1 GsjDLmRcC6MJyqPjEYgdhfpBTLoBlyqEEdHt7a2IFEUBYRrWjTzPMW1evHixXC7v7u6++OKL+Xz+ 7Nmz6XQ6mUyw0b548eK7776DghyGEvgceO//3b/7d0T08uVLlPaoqmo+n//d3/2dHU9O1odDw/7N N98MFx16/fLlS3zVBFl6EwvLmPni4sJee3punnAgXeSQFLLgQ29D6Vpy322AUXSxEJH9/OTU46KP Jp/SBu+UQvYFQM6YTqdnZ2coyaagjBSUCAyrfYyvxy3FGLP7/DlOQRu9n3p7oeo27CWSzAH4q37L 2EKON8mlfHCUrDY9xtETd07caVSMG3bhEPX6bj8750j4lO3hUGOgzQupjqhtUq95dk86cZn9AklE aB+INE2DKateTSGE0Pq7u7s3b96+fv0aQddQC1vV/X7/hY5WYN5rAO1FV1kKJs/mqCKth6Ikef7j oG4wdmGOgLMOcu2A/mhE9yNe8T1KkTjykxCRk0AszmXs2rphIYri9nUJWQopV9jXiUAijri16WEw DiE4oeVymaW0S914GgDRIQ+3v6D2oaTtkX0dw+Gyad8o6RXUfRWZFZATAvoAwAi4bCv4U2cFSlAM Tsp3d3dwm3DOXV9fLxYLaC/m8/nFs8v1en19fc3JJxGKB3j5wEUDCgMY72hnj3MKLDA42N01yKIs SyToxJ797Nkz5Hj47LPP4LAJY8QXX3zx/Pnztm3hlYndxHv/29/+1nv/7//9v1cu6pyD+hxOgVVV qf+E7i89xd6Qq/eGfchFjwtyT0J237x3mXAqjGKbN7zqXsAxKhKf1Nz7bpw+jLSAO8Oi/WdJBv/6 5NNy1Tvu7aaYbdBtVFVlDVqnvMLd8jwqbI0eP32KYKncu8sOb6i8QOGInmZlEaXMeLn3VsLw5OMi ae/MU04jgzas/PE4UpQDgvmcxhb2ETzxi9V5HKcT904ETRBRjO7u7u7169dv3rxZrdYqs3b+H7jn /hPoIaGk7nAE9SlvWXUbh8AE7WsNR5U9InuXP9WbPTTUInKEpaqTAXM3MnZ8ANONRmr3IOyXEown Vlo1GCUVbTs5IUkLZVkmaw6RYQJEFJlaUxMHd0NuWfWYgdAC73tKy1NbZe+GO9zd3S2Xyzdv3oSU wPvq6gqZnV6/fh1j/OKLL4qi+P777y8vLxEvCsMEIlGRGA3zs65rRKJCk/F5UUBpAReEq6ur5XI5 nU4/++yz5XIJVcR2u0Vm4WCK/Wq4BBz1lBlid7y4uKiq6vLyEhMSkAUzEzEgX3zxxdXVFVTggBpQ XUBDoHoChXdv3rx58eLF9fU1JW+2LKXcVlFHJdveErhXIj1OTw4+7Pp9qiZ9RHz0s9IuLFaFeGaG 0gmwdzqdoh5bMn9q2J5jIQkxuh1jtTuxcH/YhpqJD6SenE2jUNGsdjYpdFQxqyPQu1Axh32EAjKl oWmW9mNehorrJ6EjmOMU+AXyxmkcnYVvl56A3H92BFQcfNCDnopE9kp+s+ycMLoTDswv1g1VhPc2 18S8ek8xfnMx0mZT397e3t7eBtqrbUZjgEOkCzs85XUrxx9dGrrDHTkuInDlM2uTKVUtyVIB2CFW pv0kp5aGgPvhM5fNX3sk3Wrshswco2QZi1CMu7Jt+mtXFyGT2LSxabOkQ2YmkSDAEyGG0EVRMRFH cY45CoUYo0R2RCRWNZj7BklxQhg2atvUIZXogykN2ALmNigt1uv1arVqmuaLL77AGmligFbjz3/+ M3ZQn4q/ENH5+fn79+83m827d+/gEhdCuL29RYarEMLNzc3V1ZWIwH8Cnptt237//ffq5g+XIySR XCwWCkqUmSNkNMb45Zdfnp+fo2gIEcWUmAuTAWgAoaeckgNB+aEumTj/888///zzz/EVzqqKSF68 eFHXNTJ1okoIrPBkNG2WseByLZIek+9F90ZM+ubRSTIydU6mI5c/4s6S4gnoNJ+tU4mJTtBzHKfR 3fDEFg6W/9P0y8Nipzd3KdNqlmXT6TTLMhRJgWmt1wj9GmMkl/UOdq38mLosSxZw9OSzIarQ4RtK lnrO6OTjQSmZQ6ti9A6nv+8HEfiq3vmh4qlL5VGY2WYrJ1Mf2R6EE49e29ucPqr20tKJgo7u6LS/ bOTIvpeoSw6xbaHx3m63Ybdr9gGHshsk0X4oFLNtsz0a9Z5R0APQPFQ1KxaB4I55rlg5mhCPzoJm huEQdv8JqIeuVPVomsSSMjeEEFAMk1LXoKhTTb7qNqB7aFwX8QEM7TSvbuagRSAiKDFgVEIwZyR5 9uzZ9fU1PCfKsoTV4y9/+QssbjAoYOF89913l5eXRVH8eHuDMBAiijG+efPm5uZGRJ49e/b8+XMA qZBqDnOy4s9mM2AOZEOBJDCdTtFmrLsQgqoN5vP5xcUFM4M/e+/hYweufnFxMZlMfve736k1HG/f J4JSAREZFxcX1gGCmefz+Xw+h5Ib6m3ACyh7cFqWZRcXFwhRwRF8wFVDgVAJgONIvu2nZSMfjykd Z30fKI8davSHrM0jQ/ETLPk9+0iWMVFkFu9dljlmgf0uy5i5Cx22gwAvDWfMPj356V4a7eGHTA6X KtOM8mhKlvWQigOdMsR22TBzluXMGZEj4uxA5s1fC9nMYyr0aKYNVWOoxG/HdrTjPwHacLLLQGoD GjuCFoNPaozIztAoIqzqESEJkYVYXLNtb27Wy+V6s6lDkHhA6NCtUURCeLAbzSN0RSeCJ2zS1IHd GCM0wC135iCFJrtLLJh+6IoePLrfSL3baLZZnOdEmMjhQ4xwY8GPkSjG4LOMSWJwMbQBWTdih6ic cyHG2DS1cUfrBHdXxxhdUWTMEqlNEaeRabvdvl2v/uf//J9Xz5//7d/+7f/4H/+DiD77/Plms7m8 vPIZr5cr+EVuVmsRWa1WEmJsw3azydg12zo0yT9j1jZC3Eapu9ypGvijsj4llxFOITlYd5PJ5OLi AuqBZ59d/XhzPZ1OhamNIZJcXj1zf8qefXbFzJeXl77I87KYnc1Dcvn33k/nc3KuqKrzy8uqqr7+ 5pvf/f738JB49ZvfUMrxOJlMAHHg7oZYFTJOJ6MvHShhnqQsaESALRDkmZLgpTE/Lb/+r5iBfmQ6 pK89vml9oF7ko5IPIfiU9z7LGGgd7seIhgUWPqTbeHL6QNcEUuevRNgJ1IeL0qKy7E+5ak/hoWLi zyLtnU49zj5KbExLw8t7qe9p3zOmZ0YZvfNPYF5J+oNOIvzAW8VBMivrZx5jrOt6vd68efNmuZSb m5vVahVjDAQwYVwi8B8TpYwCdhiOz5ye3gUGjp656pAPTe/apmmybC+LDI3pRdURAZ/VgpYl3wWV tvXzB67HRxDGQdtJg2GEaoGZN5tNYZSaqrro7Br76jpAEyTQxO3QO3EsIshUAUcKyCTff//9fD5H dikk5YRuAzoVMSEeYCm6Z6N5McZtqjCnuzIlNSeOA17Aco1HQ5dARC9evHj79m2M8dtvv/3DH/7w 8uXLi4sLVOiA+vnbb7/N8/zVq1dff/01qVzk3H/+z/8ZznaAL9BMENGzZ8+g3lANZZZlq9UKWAFD ZDmkXc6qAVInGMwKhXR5notIWZa/cFb5iX5e8skFgb130NFB+ZalNF82saalGCO5pyyy8DhSnb82 MtvPgMkpTBQZ4nBwKB1aYD5k1o9bRcOrnha7aBTDkSceb5IkJ39N3+u91xRDsBCP3gfDrgMliel/ pPmgEvxA3/5Is2tCBjFG81KEoXuHz91qtVqvmtubxWodkcucdmGiB8c5xiiHBJOj5PZLmpFJmDtE Vz0zlrUR2JPHtCBExjKo2MIT60ExSf3jgQCZj0qSijLCgjCqaIFJom1bl2U2FRIPjJ56SdiPj3PO UafVy2KMNzc3qEEKRELJ+NKm2uVojFXyKUJVn1PMq8lkslgsmLlpGqTGgus9kmshmqOua+TERC7O 6XSqlb2cc0VRTGbTly9fwifj66+/hiHjiy++wDmQBonICoTee86yoiieP3+uNg5MZiCGmBJL6CRB DRH9ekpFJNmPgxsm6bn3Dj3SC/76wAp/RBv6OP3Cx7DTosOd+Pz8fDKZaOwroLRGkfWuBEiv69p3 2vhTE12Pyl6PoCyVa1GFJBmLACfvJzJKjuF+v5NT9xUe9qA83NdVBYWP9/p7LU8yW8fyjjesR2wi tbIs68mFo/SrNiQp4GiaJkaj8Uq+FzHG1Wq1WCzWq6auayTj0AFv2zYchlWYYg9673aCqRenpLCL 0bk3vH+MsWn29ma7bIc3UQUGUKZWJwGL1E2ITVqXnwx2iPFBoQFMV3+OZMAKtqeqvFHFm9H6ECVb oVX4IZkSEaEqB27YNE05qbbbrXRpi2siAsNB8+AYoSoiPKiqKmiILy8vb29vASaISJNgqtsE4AVu CGRZliUiXdfr9cuXL32Ra3as7777DuXTdBzsQtbXDfs30l7pmeqHp1+Hg6n30Zd+5O08+TR4xO1+ 4dvqJzpEPsvEe8rzHLoNAA6NVXEmcWePmBl2U9BTibYP2smcyT+mSg41jqZGdiEDqvkc3seqN+Cu RQacxrEQ2VPoaVeFDPzpKGWDJqLOEio7Nn0KKTBSZS9S8OLXQ++i5wh25HGP1gwdEtOH6v2e4D76 k+5eFqV1OTaCxBhDi1nRdSeEWNdt04S6bkW4l5dCRNr2IKSD/uOhHbfQ9pTdvbcHszEI6szvvb7e QlZlRncr3t22t2fbiTfOCg73lQdvgXav4PBVJ3gBx1T6J5poVT1BgVc0FYKC7HoBwoVAGIj1KCcT qDHOz8+DxOl0quGdi8ViPp8vl0uXKmZrVkroJGDvgJUE4SrLejObzeBTiYRXvZeCmyNEFiEbiGVF RhDNw/Hll1+iyyg1jmtHWVndtqgPYkmtIcNxHuqNjoz8RyLtRm9G/Iplmk90YC55ZKGfzWbIXD6Z TJD2lfdNuaO3y6RTrT+oHVaQOnRCT9Mw/vT9siZZIjah26rzhIZjtMBVj7zJnH+kAb1NcUgfz9g0 lP9wnJlPL4fdG3ywtmxQxXjUSjK6kz1Vf+2mO/wxxohsqqNYZ4cn9t8bM2u8I6AGUhG0bQsNh6Tc qrRfJGlUU9UbdtUvWTg70D89uO8qoI/eYdhx5xzRDrXQYW2W3lY1Gba1YhLS2MZYGrTm9C4+hg7Z iTTKwyItkLbTWoj0BEx1EXEpbEdE5vP5ZDKp2xZxKCGEq2efzefz2exMRObzAi6T5+fndsXxQMMK B7iiKL766qt8Wn3//fdAElqTzDYSH87Ozt6+fYuXqDGo5SDpEcSqXu7L7XY7nU4heDjnpvtOPEpu LDb1l6Yn6KOfA6c9bbMtTn3C236iUfKX5+eTyeTs7AxBUFD9negm5oSJKEsL+0EP/sC3qy1UtgLr z65tycjKKSfBdruF358kt3AgKr/vSn0ECZ1Op2wSD73hqPhrl6j3/ohvAR028YDNndhIq97oC6+n 3eFesuL+Pg+SGCMTS6qgfaTUlraqk/6TyaCu6+222W63Td2aAYF+CKIziVBoud7Gpmlj3LmX9jZm fIZ8HbmDMm3bWh+Ox6k6ktTHzpEIMVOMrXOYqCNKrDQxRgsI96nH1nX3VRQrxkivsgcNYMdueMee M8QlA5B0/1U6zn1vbiIics7BaTSORQ4rZ1AwHdPQISUG9A1FUYhjZi4nFdZY27bn5+dVVRVVmef5 ZlNXVUXSAVxdg6vVaj6fw8kXgaNElGUZUmLADzSrCugk0Dwk1egxHGhef/Ob36zX67OzM0SUEJGQ y31ubRyMUtW8x5zLwpG4Iq+IIxltwShDtta64Wj/iujX2/InJyt8/lxPP70B/uzsbDKZoLAelIQw K55ysRNHRO5RFv0j7dMRHOUjvTMtK7SXq4YDB5ErUDUccFOAL7dtySPmcTRhNSJ7m9ORPtoNbHja oTl0YJuxESjH0NKQm+tx3ColZWHL30fBjd3LJXmMQp9krz29MaM9HVwO105TAedADc+h1+Y2xBhj ykoemqZJZhQQAAc2FaZUhNrWUu41KaZMo20IABzYOYav/dG8wGK7nrpiOBP0+ON4sU6kngERG7Om 8dBHsNWEPap/9zr8YjqN62mISAE0M9bgITEJPRq+F3WbRZQKcMN0Pofj5GQyIcfb7bZp3ud5Pp3M cRPUT8dcms1meDSi+cCvkI4TN0Gka9dm5vl8zslUTWaSt22LBJ1lWVrAQQlkWIVNr3c7+IIleWRA dfR+jt36CRUJ97b/r15XMRyBX4uexpd5kWc+Y5exm5SVOqkpyz7ydhVwHNrJPpBijPCosBKYtsou Qmc8/F2K+NJNomma5XJ5fX09VETLUY9rFWiO92h426HV/+G9H3/QKfv06SfoV7i/ISxFNxi1EQwB kAwMH0ca9oH6Hn1NneZATM0a3rkd7F2SjquzZyMOm0TTNDEYrUZ6Bv4jIuQJjVFilLquV6uV9RiN +xmstW2RR6q13TtzDlFvLDUPLB2Gpx+PFIKoQ6suCkfMBzJqnNImC5cPPfoI4Oi8NVMA7aivVddO 5PhK+Uj01y7YyrF9T865+XwuIpE6fuJSpm2k+cJNptMpM5dlqSeoLyrs1MwcHJGxvKDmmbYczyyK AiYVqDc4GU3EzM9DWH+f8GruKVJ95NdD9CTsayi33HtbbetDG/AxVsSjB+EnhnfMfMw96kNuuz8I nLynaWxjOjRcHi7NNjEckL4CjiMhDwo48jxn+SjVRMHfj/iuguyvktIv6q9N0yBpYO+Se90ODsmR o197zf4pkaaIJHPDsVcwjArGCIhNfsWsdcvA7nuvFV3rZSDt4Tb7FLtbi6HTe6dlNo8ADg3fhaEH sa5q448xboPxaegmtwUc+OwUobZtQKEKJLVMiGdXqD3GKGIwx4FOPWIa9BQMoNHpenxRPCH1OIu2 h9mJCI+hi3vBMRkudujM46OnDihxUIWg94gH0fn5uc4iMrkEq6qCTUQfxCa62No+oDrFMTXf0CDm SJ3POCXqANpIkGIccPz09OinP1QI+XnpY7T20UP3CxyfB9EhJX1Xpq/MC+8yVQOSRZeHZRWstxxI hUYSQjxa09sTpg9dPnowpgSClNASLOur1cpGmfvTsuAdoQ+coHLAnnLi5aNXiRyDUGIsPpa0I03T pCSqoRPckzqa9vurzjFkqlJpxoJD3cGrhF1jWGrkEP5TcZBhvTaAgzKnLVRkLCLkuiPa5dBazZPr 34f2SiG0bRsDbTfNdtPU27ZpgzGXiI4MAEd39ON4TuKhh9RsbNLPAHTSR96chsiDDlhUTmlGT2A6 fsLw/jKgQ6h3eLB33DkXJCp0QFhpCCHPPOqJUMp40Wsz4AibFCb4CY6iMTsmolh4BLcPRLLgpyOM 96+A+OMkqPhEv3DyKJgymUwQPk77yyCmKj7qrm8vZmINDPHuYwlbPe7Q0y4OfThAsL5jb1uv16j7 7JzToDJ7f712qM6xv/ZC2H96iimFgAUrqXmifw7RaDb3GKMwMXOKhsXuHrCRWy8z3WkkqS5iyq5o 79abJD2nFpCabE7stT7dwYtSf0qoxdqwmDmGvfJpIgIInSIaMFb9wcL5oM26Xq/X6/V6s9k0ISJs QVFs7PKGddutiKgR51AvRn86jllhSTmuxrBVuHqXP+16tFNOWQS6FA907USV5+OAuyQti8Jia1K5 dzSGDE1dK6JJPX5+fr5t2tVqNZ+dF0URQrAMxPIfq+GAFdjyjdFW2aez8Tz7RJ/o10tWtzFc2n42 maplsRc8ZsmeoAuSjb5x1FV9x4EfqN4YapVPv1zJ1njEB+XLkEV6O+jxkTrkk9GTqySlUddz7t2E Tu+d7Ics7v/omJmED+my1P9xeE/OHBEhrfJ224iIersj6yKMyhZbdHaKVBVdR+CQQGkDF+VwRLEq S/C1p3+GZsHxrsQxolR6wxhjDBLt+8X4oK8xknR5Mna5N7B1tg0RUdsGEdlum+22CUFi7BJp9/K4 6EOj7GDHaKcsYW4MUe+hQTuk2NMdzu61nEbjoVBD5CRxWrUaurV3ni8H+n0cUCbDwcPQxpAzJG2T 2N26t/rigYIJeppzO0cUXSPQZ+RlVVVVkVdIzgGbGv42TbNer+HUqVMa9hT7uEOQsTe9h+UFnpZ+ XrvMJ/oroN7mwmNufMfZoIcSTzPYDOWS4fXKKTJnYIpEoi4FUG8LJ8OdmdndN+2H2jbZj1g5RXIS kc1ms16vEZ+CBIJgE0QEScUWXqdBTnRt9oOUwyoin3LJ0MfwlGcNx2fHu4UVDtpzwJRVRrcUY8xy r+ghbcDRbq6r1YqSZH+ogyrb9Y5DTFeBUjcJ/dAbAdrfBvSDiBC5GCOJU3eKaLbYPQ2HMS50b5zK Xd/FmfeODzizU+dYpw1Ndk5H6UTUeLqfk10yerBnzrC2JCthP4JOnOp4azttU5cvbOTM44qZ3k+n N7s3zqrhcM618YiRywAAIABJREFUbTsUmfYB4k6ROcQfarnTyu/OudlsFoS895h1RJTnuSa90MJs k8kE6TfMyNDRAeiTSm6f6BP98umIRUw3gp70CPKTyQSsYZj06RS69/zuefserUfOH12jcd910fbk 0N3ANRBiAH04QIYyoKZpwDs0oE6rIYwqqIcYiFINC3tE1fL9Edj/OtxuT9dzWDLtdETE5OKYsqE1 ZJ/Y+bvEAAt0jFE6yJIyYQ3ya9miFbYlcDoebswK8qJJDali4uk9VcAR2i7dRQihlb05ra2NJNaV j4jaWPVABgRK+PaROH1rqc4fiXDSiHBopW1Quo1JnMgDWm7pqRyrh9j0EYoNpRhjINl5D9w3FQ3C Y2Z+6My1sOnII45ca09TZKyLdwhKyLDIe0dpvV5vt1vkQsSRqqrqbSspHrgsy/V63cN8NniVkuQm 7lTHXjtXEfl37yUPok/qjU/08WgoCJHhdVat7jU4xXsP1bqSbr0n2tpBw+3WNoLucwQbniApE0BP AlDhRg09lpurYgOVHhVzYJODN8Z2u0WtMo1V895DTuppbhFka4+k1u5586n8B/vFcGTwQaMneudo vOWQhhuVDqyeQkQxiHVEoH1wBo8W+zj8FMRWCIMTYt+6PNoX+9Mh/ZP6PVjhWL0regBIfTOHT4wx IooktLJLj8EjLRQRzpyIQEjtniiZaZ5zJmsIcxdIZjuF1urrgH6orutAckqtmUP0VHz/CdGGvclh g93IyZhizrlTNBzDG/aW2Int780NTiYeveEhSBdC6PG3Q6dBioARFuyRmfM8h/SSmeSklMLvKeFX 27WHajhOPfUTfaJfJOlG3wP9VnvXVWjriv2M6UmUFwyt14fYxIhM/2Hc0O6gIMALuznpZz1e1zUS jFKqnkwmvAJ8BHgFB7Hm67rulUwECrE9xT7UNA3RrhAUJbUK/h7pTox7ToiUeP0Rid9iGnzQl6pA IcYIk8oQzejoaSCJRSQaAo3NmIi8v8esNjxoAeVQBWVhkGKO3t10QDCG9s2mcziEoDkfyWQa1WCB TqHiGFkTzLa3S1vuXGcOiFEcOxKXDCto0k7b0fsLIw58REZe0lEaQoSH3uEIpQY/AeYYANljIMkJ 8dHktj3qduJkwdKDnJpu/57YYC1fQGZW2xN0NmZyv82ibVvwilRqJzShUf1wzxfEpaDck9u7o95V j7vJJ/pET0gfqHG0aMMCaPvZa+CGcy6a1MjRlG460sQYYwQTgQ/HCbxieMN7lR92r1LOosKN1anq yZo+AaoODXXTZkNY6XEoPWifjtJNlPbI7XaLr3VdE0XcXLfzIcvrdSSEAKWL2hoo7cc2o9Tx0VPl k3m1nUmFjBXD3kdDVIamNWFbbtvDOG0HSj8P9yFrURpVTmhMB1Ffg4WtAulNt9ttjBGqC/VF1fHH HtCZe8Q55zS1OafkS73nqugpSbujFh997/AK1P1Om2f9V3p3Hkbzdo9g85l4OP4fjyyMe/wdiOhR CpjRPg7tGnqyTtqnUvaIIRq8L9l3WB6l0Vfsvb+7u1sul9V0RkRFXqn1BKsDX6HwkGRV0V7fyzZ7 X08HHL8i48gHTstP9AunoWSivMgm3rTkfZELJ6HD/KpSr3AKIVOpjncnxBgFHlIntC89XshkJ1SF dvo62jEhiU6IpAvDcLL3r93WyjW6SN0osWnxr15vnBAJYV/opKgo0gba93irm7Zeb7TAUqfaydp2 W5dlef3u/XQ6bfx2dbdIwfdkz6R9xUOMcegIFtr25v2Pm82mt3Xpdhi58y8ZbqJ2FxwgG6Rg8nEs 3+JxpQuqslP3gvZOc86J0W+pxoiIRFgNz739Q1sOtU3btpvNprcHt207n8+LooiSNduwWtUYv7YN UbLkSBHzPKfoKDCzE6ZWYi3k2dXcaSy8z5zz4rq4gNZ1Xswt+6Io2qThEMoDSpETCeVCTsgLeWJC P2KMnLkYoxBt67oNQYiEyJm89dTfSIRIiMXueug3Ufesj0e9txxjPPTEzDQZ818XDhNxFOeYXE3M xEzsiPcn3jHfTyKibLBX8pgzKXfqJiYijuyQRITYSfdXL+RDNXK0s+l3RhNCGwMxs8tzjq19XEa5 k4AzfYTlNDJxJjGTzAt5cSyRiTl6XOLaljPfrDfrEJ1zsQ7+/DwGxyEQta00nLS2uTC1kZuQOe/a 6LOOkzkiZnJRgsvSqI/1AstZ3GZTtw2ReJMb5ojsdnxwhqYZLO3+kf5NPw4y+Gkw9yf66Yn3PSXI iBN6fKizOMkv+hHqPqNyEN5Pt8sU6EA6ZO2G7pp239VKKN576BW890gGrJ4oqkJfLpfqJtmb9Dou PROGurgjFpRTXTfYdCHE4Cc8S0R21SSS+d9igvPzc+/927dv7WavuhDtr56vgIOI4F8yOkTwPLCA I+6SWfX14ao72VNpJDNH99VI50NhKxiIoGqMDvWZPRjYIqb4DqRrfPfu3Xw+r+u6bdvlcolwQdyn KIqqqnQcoLFAbnU1osPDBgptZm5C672nZIpRLbeIqHCpMYq9l25TSnMiFbX1xcEoQ794RnnIlPnL Fyhl4M41bPa9gy/7vAwTBi9drZ/QPahbd+8R6l8s0i+8IyKhbaFv0+JtTd25nCuHUcaKJ/aKwnea FX8QdPZW2YMcqD/RJ/qF0yHMcBBwYP87BWokTk20+2/HMqAXEVsMjPp+kdaor5Ii+EUg4ZROMcsy J+ScAxPBPrRvpydOhcfWiTrde3JrcClxFi60FtmQKlQBzeBWikIg2fee1UlRyQqza6ejqqoQTYoS tb3BjAfq0sUYh9Ld6JmS0pCn7+iIHzJ0WGoOqbgpCaKdxTr5Y+q14vYiTvEBye+bpmmbiMjqzitC uG0DEd0tVkQUhd//eFMURV03bZA2NCJ1Xdfz+RwyNhHVdR1jFHIxxswX23pBRCHGdEIm5Nn5pmny fEJEzIHZZZkXgT8KMzvv8wQpdoVA97AX9ysJ7425MSB+yLYd96q9Pz1k+VVAiiM02v595dBp9xkc wRRVYwclg11RFOr7iZA0cgzUq15cnf9O5z5Mtq4s0sStVqvM5ZvNRnmRfpBk0wRiUHBTFEVsgxQ7 N+Qe7RisEH0CHJ/or4Vcyg9kre04XhTFjgv3VPG6xxxaCTHGyAiqjJT8AMRxCCFaEwMiINJVzAzA 0duDVT+jLAll26wM2jSN6kXg62obDN4hyfdQt89onDFlUKpt2Ds8d7jHc3JZUGWGog3az5mGzRf7 6GazgdyPB6lQTgaTWf/2GOOmqe1zD7mvy74yIwYMXR72a5fQAbcDSzZT5Ha7xfmaqjWQhBDm8zml 7M6dswXTdrv1WWHVLT3XH30dQJDr9Rov3Tk3n89jShmCwZlOpzHG6XSqL8V7Dz3KdrvdqShiqKoq xrhYLGazGaKKiqKYzWbOOee8qvUkufIQEcXdVB99v2QWxijOfqgUfgqN3iTGyNx3ReQU3f7hDz3S mJ8GzXRTxXiWqQBwYgPgu9M/GKPiAH2J6gRKafk7o7Fj5rquI1OWZVHYey/IEMPO5NiV1WrFlIEd AbvYIFiwJqwXbQBuXk6rezoSo2MHFeDpA/iJ/prIzuSnVaw+aDk/7aN7TqNYj1mWeX3Yvn6e4Id/ KErTnglC15qw20oZu/I+4CCiGBvat0PqurXKbaABKzfofmB7IskzVnUYuqnvfDAPFEzXMxUoUMc+ +vYOZS69BIJE1LYhy7IQUvZVZuYIGWy7bXrbRowjNou23dj21KHPetRPwh7UbbXjrZI1TRNDZw6Q 5CmpJwzdhuFOWxRFlnsjpbkQWoQT41aBJMt80wTblixzbZDMUSRyPnfc5TKRFAUTYJ6mLPNl0wYR FsqI/WRaTiaTspxMZ5fee5jJomzatp3OLp1z79+/93lBRD6fYkyms9lisZifXazX62oym+Rddavp 5BIPnc/ns9lsOp3alxVj3G63G06+I3EcZJA1Ld2342ZZRvtvR6Sfo3PUh+ahpLp6PcIPz5HzIELK Ppbu395Ph686ZBjtMa9DA2L1SRan3kuo79q7v96ql3IUK65tW19UWZZJg5pBDKQbY3Sh9d77vCQi zrxzrtfn7XYLV2VmBua2rwPPRdyZbQww+imk0shHfcWf6EPoV61Z/NkpJndGT8bcoNs2Jbs+H07C MdRLhxDAgCzgkNDSPuCARwfvvnbsRvd7lctprNxAj8Q4qpCJpODk6ti27SG2qDe3TyQiZmelJUq7 iOyXt9ARULOxaWE/e7cqmrr9OFWVG7YqDBTGRVHEgf8p2gAh3jkXU+M3m01m/Bz1iVbxG1PFVxiD 4CcBpVFd1xjMsiyReIB9pmoJtEH3iSzLstxnWeaznJmrqlosFiKiGZNWq1We56rTRmliIvqbv/kb 7/1qtbq4uFgsFi9fvlR3mVevXgFo2tKa8Aj5+uuvz87OAu+gA9qsoicZd1qoajRWhd0x3YCdP8Nf 7UyAWwncaOwJ9HTyQYwRM+WpbviLJYUID5WuYuyjjeFnq+XCkW0TvPfOd8pITEgR4TaDvs05112W 9n5oOHA7MAHNc19VlUo7quRQ/YrVPp6oOvrX8MY/0a+UHrdO1+s1Nq+6rpGK19sQxD31QMrhOAq6 oVd3YsFEJCIXdmtMzM7KnfM2hD+sqz2WYesb6eLUFaim8Z6sDxZgTQa6zu21+JAdCvqQQTb3GNAH Ss6YzCxpQDBKw+RglLiYc67nB+6c6yJpm716qm3s6peKyd0OqLdarVRkF2LvvRWlY4wiHQZyzhG7 KC4KCzl2eZQuvjeYyAUkyRJCtJLDZyHOfFHXdSviPTvninzis0iyIaIiF/HiACm8r+s691WM8exs nmXZj7c3eZFnRX52doYUW977cjpRiFPX9VmRxxjLlBP6qijKspxMJl+8/FvdwoFF7FjhAwAHMAo7 l+e5c74oisViQUSbzQbYBTNnvV4jewogZtM0ISOmxnFOPPTS75PdGw6do6a9LMvix6kNq/Tx9h5G ZErSZCBohaWbJV3oSj+1xsHOShz52S7hE8mqOg623C63sYO9G+IneHmDIjkADpcIDCQr8u126yMx c+ayEAK5jhnu7g8OpnnkQthsNurSrrBGY+/7LGWg8lEZRhI0+lS57RAdecs/cUv+1ZIGJ+qmg/RU 9hzdfFXbpxdCJt9sNv76+hpiIu2/vyBR19uQ/XUVYjkQkUteC5QC5LBWxSxXVO+MErpvIRBJT0YU kTzPNcrAujvoOWSStIOwVm2uiB4W0zb0ZufuJjKShMp+I6MEUlGYDPfRh3Lyio+xRQ0nbYNmNbWc SEQ09IYSG6rbzhCzWq0UqYxSTMnCe2OijiZoQEyVJvTXmBAA5gHc77WiWJ7n6pgCvxy8bkSxeu8n k0lRFJefXXnvXd59RY58n2jUBABcQkQkpR451DVtLd7B+fl50wTn3Gw2izFOJhOcEFIlEdUzYTFs t1tsKlgYITyGN7HJnacT6cHb6U9FT2LKGZqERm+bptO44zMRubHKzB/Ytt3nww0jo6/qretIrm3b clLBXwSyF7q82WwqzjTjnxjSR/Z0nJBzlHnioK6jh76Lj1257a+SeD8i7xM9LenGisALrJoQAubq EBXE5DWFXFNwaUA5Mz3HLxYL1Bzq7RAot6036m38gPNOdtGehXdExLKXkkFEnOxalpZghFhlbQcS xbksBpGMmIl2j9vZWWKIzrnkTLCnqIwx6XzIxQCOqWbdrlUi+8yRHZ4CdUYPB+ij0zhmQk5I6qaG LBKZOKaKnUJN3VAnlPsmROeKbXCSedelPfWefQgUuBCT5CCw43xnWBFxbWiJS3Jd8qvJpMrymS8q IoqGufvCM++FQRcVbzYbJsaGmzKUExFBcGLuFAnYiZEsqywnltM9e/YM0aqbzaau68V6RQbWZFmW eT+bzc7Pz8/OznxRMnNIthjnnBavAkCB/KeqIEywuq7zPKc4jqJ6bDqmfLJZlgXJEGPos1ySkSyE 4DyyVkvuuWma0NYk0bF33PpMijxr25aE6Xj1ky6sRHrSOkxOKhB770M7nlnSEcn/z9677UiSW2ej a5GMyENlV1VXt3rG45HUGggGLN8JvjLsB/C7+BENbMBXGxvYgABBsgFLtmZGoz5UH6qy8hjBIPfF F1yxghGZldXdM7L3L2LQk5UZwSAZ5Dp860TEUJox+GPP+5Qtk4c+rEFVaDNxDOJIhte7yETUhIM+ Xk2/kvuRdgrPeNDsDnUILEG8UzMVQpBRDaDqm01Khy9wZuw7oJRlWRRFo2r8wkdqdGxypiiyLNRQ TfpL+0t7aDukY4vVL4TQ6X7qLtwIcB0oxX6/x5FBrCUsidba6XR6fn4+1ExgDf/222+//vrrjE62 eAEli74uF2KMEYFDxJZsViGEwiikoYnWWtOvLcJjhZ3CgEhpWAJBB6OApAg6uoEliKiLfwX/QRIw w8M0WeS9d/CmZEf9dyNuFsYYIBMZqhFCaJJThfg3CCQD5VuyjoqKTH3nXPwpLA1bAQ2rDTJkrZ3N ZgjJ024cSEAiA672rcMaEIjdbndIxcTwBLRAV0VRAJLBRry6ugoh+BgAwHTTt3Y6nZ6dnZVlCYEj JruGSSHBpLAfvSPxU1Iiu4wph5r+tRWIE6wtKymuHt772Wyms5sgpUfrxGPMUe/nYw1LqiVyY4zs YWaOA+Ngu13p06hf3A/ePnTNKSyKmaGpH7pgdMCj1wutyFCE0Rrx1A9Dy554iD5mD6J0Iu5tRwQO IkLEE3CvVgI2TERVVS2XS7auLMtiMlWzNsxsUgi6lid0gxcUUEwiQkxWOS11guOstebX+L+jTuwH bOa/iE0f1kYTXj+0QW64ubm5vLwMKW0jEQFiAM8ahc9Xq9W7d++QOSmmbFVgTzFGEMP5fD70iUaw lff+/fv3y+WSmeHSJ5MKITihyBkjjH1XSlbeoyFFdfrQSSGeiH1wzlHT5sYxlKtKoNdsCt0PEUU2 zAzVP5JpAoubOOwF4CtNaILKpYjbLXNde6FEde2ZuW4IS0Ps2Dg8JjSd32WoQwg2GkeGdvsu6XXy wDDeewrGROPKM4gOrX8ZSKSlAh/IMgWmYAwzhcKVTdMwlcYYdqFwJRFZQ0yGydHAj4TJ4C4ispMp UZukxJZUuLm1djKZLM4Wht3V4wu8y+l0ChACAodIJ6GhqqqqbRVjrOv6ydU9pBkCB4QMZoZXpnOO nQWLnc/n2/1O7BQxyYUYVVEUiJE1RavADUEyUh7BUvIqvbxetZrRxip0iNRuMV1S1LYJuDKbzUTW FPs63mndDzY+sbHKu4AmHEUkyC6+I23aFi45WZxq71JiOnMrRpvkujS0Tx3v7eB01FyQadRQm3K0 vWYQljLaNacxc6aXa1eMgeOCfkqXa/j4oCNRAh5MpPtykJ7UBNvQplJEtUWuY4xsnXLSijFGNj3y OOwTntFCMyEEu9N8cY6/3P+97S/2jlPaer0WI4VgDI8ePfowca2u6/12B3PGcrmMMW6327quV6tV k4qGGmMuLy/Pz8+1wBGT75H3frlcbjabu7s7GmgUIEqr1er58+cZcRZVcLfbIYAghKBTOjVN42LK 8qRt/EQUB5HuAnh0RzR2lJeTL5Uou1HFntBRmghoUbT/rDwSJdNya8dRk4wpP5gMTyYCGh2TG6xJ hdkAFmUeDyJ14WUAF4lpHVEGbDhsIdxtMvXEkPBoeELIrHkQsEeShf3oxoJL5nw+h1qGwi7gr3hE cn01IQQOjGBX/b7w57AhTyvmC99M51w03WCAhWBeGeUoisKUZVEUbjLV8oS0bKHyZw8EjlHaNFyc GCOFNvS3qqqzszPYaBgJFQYgnhlzbnpQM6m6IY6rj0FetGBa8UC0xYnAQze1ftMn66Edjr4CZmZS 7yiqR6jPp495eKX+Ro5e6Nc8e1DLHbbw4SO0ZyEUMaXNbT/gV26pDQBOZobIczxBALJ9wBA5m80m k4m19vgtugGN+7Dp/JDt/1iQgz/aWWT0dgEP4K4njANEO6shemJbrVbv3ry9ubmBXzMlS4psaSK6 urpi5lGZBixpvV7/8Y9/pLFtH2OEmrrb7SSsIWuwxaB8R1Y43d3c3BARM08mE9AF8Ce2bXIbXCc6 lhBZ730MtUk5cFo0gzkQe9/geiZy3AkcwDBkiqKsRMuecK7ZEBMblLdoR09kykkk8lQ7Vwj5YeOY qGEmZxpmpDRt2Dbcrov4bzhbBqJyVoYQ3GS6q1fe+BCCs9PpdPru3TtjipqYAhliCmSjMcaEGKwr GqJoDNuyUUwlhEAE8Jxs0SqNhXXz+VwcGqy1rS1/oOVwAsmHUCqkCla2CcgBAuFYYws3n03neGXY nUStwDGZzMQLVcqReO+HYyCiqqog4bYuosW0nEw0v0G8TLue6WUxM1njnJuUs0ePHsE2omGA4YOy ueOVyzctxfcNcCwiSnElXaSrbD9mbivgpDJ4ePp8Pp9MJpKTHnL6vcLciU2oADNHw8aYMgTERtZ1 HajLMwYvAWo59wPVVj74hyxv97MWIIhNJAamCMRCTFa4LHZ3QeCwxBxbNx9EpvyvaLK2H9/EMgLi XhQFDC7Gmaqq2DoimkwmQiudbe2nw65ANr33q9Xq/PxcMtHpC+gojHEI3P5L+yEb6I9U+iSipmkQ z3noFpVJoQfH6gYlVpi9NPDZm5sbWC6g9RERDOIwTMxms0ePHp2uMhljdrvdH/7wh81mc3Nz45yD PSWkmlaS6V8rA7oHMKDdbvftt9/qzEbyAal75/O5NoZC74UCDFvMzc3N9fV1UPXb8MFtt1upfcrK ScIYDiojVugnpcEcOH3QiR8ohQnQQLxNRpAuiYK+S1xToS5oWYeTaRxps2XyMblHCENqDR/M6/Ua 62WMCU07JGADq9UqhVI459z5+TmeQ4k0c3JvnM/nWBxWPiKgUFCNQu0lIt8ZK6IGdsmQNGIuo4XZ MEdkzISEIbLLoJu2q9a00S4ioCCezWYYqq5UQqpaLKli8UBKwJjLssxkaggZRgkcYL3lbGqtLYsp 8nDI+DmhOLk6a7ja7WUixhgIHOIrA8NENxdujygnhAzbqT23KoIa5MB7D+USRsSiKD4S1ciaxjNi SoytfXSCymar7/qYZ5KyUh0S5lglCGEFX+Q/KYHDEOPf00d7qhD5/bcQAvGxMrMxjrv0treD+jtL iVWADbhYlmWJRPtwcmdbcUrU0T363rElzy1sS9x77430/1+Tyv+KBpIIGqK/9N6XZbnb7RaLxegL wruGDz6llzgqnYCUaUU/hPDixYvdbodoDsg6YORv374ty/Ldu3eLxWKxWPzyl7980HSapnnz5s27 d+8o5WSSFEfAgFerVVEUeO4QucE3d3d3//Vf/4UippqeQA4zxiwWC9gQNQRiUhHvpmmur6+//vpr +Wm5XM5ms9ls1ortYOeCXhBRZJLMS7Aix+S5KYYZJjbGUGSKyvIbWwYVQmAmo+y2bSd9nIOIkFLC GI6RXFEaY4qyJCIwe5Oy6LCxVZXH7BmVY8ekxKPGmIvLp7KCJkVrzufz5XL57LO/3mw20+m0rqpy MimnuupSu3WKorDEi8VCSp+DH08mE7hVWjYxxlIFvrbQeqTdbrfb7UIIIPSybhq3oAElgsxUluX5 +aXsElKMfNiYmSID6kgr2fnfee/LsvP2da61hXnvmW1VVYvFeQihLEuICIhuLZXM0RYExvuEcaEs drvdbDqbTqeBuh2ipcMuzkGFFBozLjkJTyVNdtEndSgXpJ5Aka1pBaAkAWPHy9GFZJCt7SlE/0gz yVsKAzaRqAnGOrLBRIox+uitK7S1McZ4r3PCsablhrRtuO8io+QM0T9wPdBFA/CDqB1Iez1gjpg/ bbTD4wMcGkC/jyYEMaSaTe0e+6BmBjEmTdOYELbbbVFOiaiJ1DQNaqkgM15LAw8nI+EU0l/X9e3t 7dnZmZixtYYX/pJI9H9kiykpM2ym+BKK93q9hjvFqEEkxnh7e/v69WvR4uQnAWWvrq6urq6MyaVk POj29haECywVfS6XSwAGd3d3Z2dnf//3f386+cIG22w2Ij/9/ve/F6YD3Xi1WmFnCtoxXI3VarXb 7WDowffiKgCZQ9iZ9tOX7yFz7/d7hMhiSOg8D9CQNjTeCJvUOEybqkEFcRCR1pvldqHXLfVUS48r W4XbGETdwJRA6rKiKCaT7tEiJ4EuoBO82slkguidlkargFgUdWzxdgRNRE1hDSUd3bHRJB45QuBR Ya3db3eTyUT6xWatqir4ZjqdonLbbNLBpKWK5qB+1I8AA+kCJ/Ba1vR6aiaBPq21REZUN1gB0K1s 6MxVBaIVFhCJNPQjJtOJc661fAF/ZsL0RUTIqf8BTiAQFI1JWvFAfrkTW1VV6/Uadkrx3dMb+IMF Di1ISayK+AnpvKsh1RHNUNYPbAnSEMqVed0e6Lyr5SEtm8uhquf39Zw308Z7H2TD37cg8jEtA2UF tmRmMsEY40O01sJgxxyYeT6bkipYrRvCo0II0+kUFmo0hBRC8qCEvmQCeta0MPSpjEf/h7QP87EA a9xsNpvNZrvd4k99wfn5+c3NDXzqR3uo6/rm5ma322U0h5L718XFxaGzUNf1y5cvAZcK6hxSGcJH jx4dcr871EzKswyBw3sPaSakTIzT6fTu7g4hVNvtdmh0BtGo6/rdu3fiyiqMWAyF5+fnQ6IKnObF ixfoZL/f4wjgZG23291u5w7RYj0OEW0EwW5jwJSDobA3MEuZCe6V3kTsyNQ12S7z+RxZpDJlLrYu 5R02wKpwmjUFHgocYjqdcj+IFN0MJ5iJGpwgaJPy+ehhWGJht7OzubVWwGoTAoVQFEVsAoD9xWKB 1BeTyQT4ijG9+Lfhm265OLVeqNkW96k6PP6UD+myznBPkgo2VaSU1dADkG9keFp64ATQi6ihFs0w G2vYZAdXqh8sAAAgAElEQVQpGtIZxCX1RYQZpQM8jjdd16O9oxnRDmUFEJkCJymQfh4EVX1Y0wKH bNqYKtJxcgKg9HZko9LHCRycMmRjz8ghuq/Pll2NXtz+ibU93EW2zh+2ep/Ke+b7bmLMres6UmOt JROYmW2wyfndudI5t16vccvwVC4WC5DXEIJcRkT7/f7Vq1d/9Vd/pa3df2nfRxMHhVEnRzCv0dRq m81mtVrd3NxsNhs4OYLxQ7J0zl1fX3/11VcAObJXL0fs5cuXWeCFtC+++CL0S3XKqKy1L168uLm5 2W63uH2/30M2hbY5Kt2e0oCa4Pbr62siQvEKSlv9+voaiA5ImfyEBBAxxlevXonjAahrXdeCoz97 9uzu7i6qdA9oAGaePHkCGohS7UgMTWJy0ldT8joBZcU4IAHgGrEGEdF0Oo2NBwOWTsDv5frhMRuT A4jStnDOQR4EDjHWOkNDURTwBmdmawqYIQCNkFKwoIfVda3JLBAe+Hgmktpupu12W1gHQIWZYVIB 6THJwwP/TiYT4YgQhcSMkvZKi9YghLWH0B6Qx+u6hrgz5K9i9hLeli2tGbjakMKQs4ZHwN/YJFMU JVaHa2L/CZyQmONamnqGIyKS2Gn+ZAVHYrJctH/2Q2RBeoha29bpwQLDlsnEWGEx3AAfAvoqlhRI 5DHGeILT6NCAioeyibLrtMBxb380Js2f0rqX3ieshx6KRwzXVvaGdHKCnHRSa7X/j++o3yf4hDEm Umyapi3eFqJNLUaOMVpThAEyRymUUToR8krJr3m1WkHloH7Skb+0YZM6UO1ynXCLmDN2u11d17Bl 43XUdY3Ea2VZXl5ejmLGRVHALPL27dv9fg+v85iSOZ2fn6OENaXXncVyUvLG0H0KzO+cgzAxPCly +6tXrzBOWQEpOJWRtVNEf7nm/fv3v/71rx89egRiCKJ0fn6OqpziwGFch5uKvlTX9Xa7dc7d3t7C pySEAAdqjHM+n3/++ecCk0PBBpli5jdv3mChEH0DCixzca3Do3OSJhIvxjhrU5YnMF148AJ7nM1m RVGUZascy6K0LDydqVGBY7hMmHPrcTkp5/P52WKR+TGkFe1SYhdFAY9iToGp8MgF1gKPUai8RMb1 i6XZJoQQuJhOptMWV4ht3pLpDJ6JRNa6oiim0yxX8WwyDSFElQu8dTSLFEKAUDKZpjIoYvs3xlgb 02QnZemms94q+Lrx3lobm4MbS0P3g/3X2WXaOSqEJqrC2dTHNmAVj03gNqOGzq4YG+9bq7lOC/sg C4hxFPwo8ThEfEcRApkvKn1AFxm9AA0nLaR26mjV2CBaDU0kEBxx2ETCEMOQvKDjvLE9gfk1eE0d LijPOo1RJXSKmAcJvnr+HGqa4mUlsoK+kQ8EBJp+qUVpo+rEp5I5ug6lCkz6r/3+uEQy9pv3nsk2 TUNsmdkgk0gIvuJYFsHXIVKIITKiDHqO87jdg1uEEEKodjtwl1Y9qP3mbvWjqyeSQQSE/oeyNz1g 2x83STz09UVVHEoajskR0oG4M9ntLXLbL7QE/wN9F47emzdvRK1HDomQAkGfPn1KqQBk9kRjzN3d 3du3b1++fLnZbJxzy+USYQTQvTOVQwivKBjM/N1330FEKIpCIhUENjg0WVzzn//5n9baq6srWQEI Pcvl8rPPPoNjgKDUuEYLQFn/Ao0jB8bbt2/X67Vcb1JuiD/96U9YE90hJZvIZrMBaCdu+Dc3N599 9hkwPCJ69erV3/3d3wkFligBvF9WTVw35FlutVrBGdU5N5vNYKhGyfIWPEhzMMaIv25SdlliODVN GSbnEeWemaeJx4s+B0zFWvv555/jeukt3+ih5JRcwaRYMlwMHwuTMoHixslk0jQNMmsEVXME2JFz TmAiE2kIzPCYm14rf+hRNYGSIcYozIOSGW/YrRuK266wRLZpmrx0Vq/ZVBx1kHQ1z6ZqVNNvByfW 9AFGtmNUABaE46Qmf0GehnVZjcuquuvWOiCr45T7NKZogvaB6rQfHVkrQX4YwmGSj4sx3cKGlPoM 4UtVVSE3DqrSUIJ/uDVCjSycjDmbtTw0bfv2s1G54U9vRxh8279+olpFEU+Ht4w2e1o+xPGzfFr7 gLnf8xPn69OyECKbvO6dM0ghMJlM6lA3TVMUkxACcy4oxJQcmYhA5eu6ls4lKU7WIJEcmUWM8UhO 2CNrHg/89ZEC37EnDn4SjRZgw7t3766urqCvSriZc7k1H7z/d7/73X6/b3PrpYQoTdOUZfnVV199 +eWXo/HD3vtvvvnmm2++wSsgheAuFosXL168evXqxz/+8XCo0CiWy+X79++JCJ4cYFJEBPxSqI3k wKRkE7HWXl9fv379Gr59An+CmX777bd/+7d/i802PFPADK6vr6+url6+fInvQ4rbCCHc3d397Gc/ O7Tsh0QZ2ByQRYOSDLder588ebJcLvEW9J6UfYgPEIjh+AyFDaIbYA/wvv1+f3Z2BpcXva9APbbb 7fv372FbnEwmcOPAaK21brFYTKfTNmSlLOCBMZ1OjXNFUbB1zjlbTKy1pGQXvE5cnEXA3ruzmYyY qMHMpmWLZ3gzZWcBt4gfaO/m2MVQZHyUiiJOpw2IPlFNlKRRF2InDLZ5OSehaRqeP3KP8oTwWdNv FcLEniMROWAWgWKMofFkrIn9CnAUHZ9id1fNOutyxb0/fXKuaJomhkgmWxnOngWZjMSqIm681ppM DWU7ovwZJqKYBGvowZEljSYxUQyB+6ElRMmGkokd3I5/ZE4qgz61Akd+ljSiOJo0Ygi65NgGH9X2 2l8jcSAObKKx5AhYl5FooxA4WG6aNiKp8VXhjDUUQgilq6oKMIJtzVg93ShBGu0qFe0rGI4qmUVi sMY6JhOD4U5AP8rgpWjRUGZrEQ78KyMzZIgxqkbAjv6OvUeeGOzu0etjOwTd+eBZoyfFOqIkcTJz oKYTG9R/7XTYjMxcumqLJAOYIaY2zRe3lZgC+daZ1FBlORpfUbWzruTIoQnWWpciXUMIZG1VVWxN 43fOTpi89zvnqKp3k8kkUkNEXNdN09imsanctLSmrotJSZl6ll4AEcWYWyDT+uDfh5nM+tvmEEXK dyNs/8vl8urqarlcgqdCDx6Fsih5RQBsgCZZ1/Xr168RIgEh4NmzZ6O3393d7Xa7u7u7N2/eNE3T 7VJjFovF119//dd//dfDTSKKO7JdiTDnnANgAJPKqD0LcNR2uwWDjE2o63rdhKb2IYTZZBqb0JVW jkRKk8Q32/VmeXNbuqLeV+u7zl/hv373e+/9uzdvDXFswjAQfT6dGWLcO1wKZg6+iU1wxvoQg9JC h13pn9CbhLpsNhu4a+x2O22jaG+IAO3ymD7IWyLtQb8V37gQgijnoIQmRS0IjgIZC/4fVVXtdjv4 P7gnT55AHIPAAaP+bDZzZWmMMa5wzhWTGSUlGFxNDJyZtHFKQ7gjJwamW1mW80cLThHwI/hbPJh8 DcPO3HYghyJKBdYmmyp64AWMumceaq0PBwUiMgF4GhljLLH3PsPQRTiLKWT3/gccUARNiv9Eb3jB uUkyjqDu2k+qFT5gQzk2ye/BxgwR5D5NOHPzHGIYLZGK43Bi1nTiUe+9PblaBSfrntjdKZ12HLYm ZQhmZjhVwXIHlUUNu0szo4XI/qQOTkGLjycjBCcL/WO2TmnZ96dgGPc2PYUMZTk+WjPmmXTvgw79 KP8cagKb40Xv9/vQlq0vqB+7F5qGiEII2+0WIeWg1PAbaH2tyDPzdrudz+dtuoCjj9ZLnV2JecGc Pfb76F3tX5JxMnOcHGC6vbt3u91qtbq7uyvLEv/e3t7CWxCBeM+ePRsOgJnX6/WLFy82m816vUZA BPI7Axcsy/LLL78cHbz3HgYOaM8u6UtN06zXa3hujr5fMNHb29v1eg0uIEAImMjl5eXoE4HQr9fr 29tbQfsQESp+YK2O2k9OLf+CqaO2WTak5XJ5rzEX/WdsixP2/2HJhJgZIbUCWtR17fuNVJCdMfmR lzxYIQQ41uz3e2RbJpXGKXsdyFxiU8wpDoL4jYJhucvLSwkidWUxmUym8/nZ2dlsdkZExLYoClPA haeni4iTyJBCHVoFo/wt8GUmcEAElqAJGvLpOE53YByBsQCcRuRQreZKb4JXZ/4ZnPwihbJoEpD0 C/hGIIkZbmFrLYXaey8ANXruIHSKCOW3xgQkLhmwdngnHKKtsgPkjfYmFXvOoRqKN8YQruGRSqDf VwsPPipK9+0qeWqDZSog1HrGgBIN2aGc0sz2eWLr5AwifOiCZRLGC7dQ7LrtdovVxpe4smkahChr DWCs3UOPZKPiT5nLqBAwfMaRues9n53iE0/0g9pQZjpR4KC+4eZhkGE2BrVmQEWCONKkeFQKkZjY MIXoq9oQU4jGGHLRWY4ataJIRJFov9/BXGuMgTOdZjMoY+G9ny3O8sEHPDRSPwrsSANmEEIwA8Nl CGE2m3HUrLE9O/vNFn/frtY6AqDe7VM1JeKB19Fus3l7ff3HP/5xsViI4yGcAS8vLy8vLz8fEzic MdVu9/7tW4lUjzFu1+u6rnfzORH95Cc/MUTOGJ+ZVIgM0Wq53K7X0KyrEIB2e++Xy+XTp08hHwzN E5zSVTUpl/Z6vRZ91SSn+IxCore6rt+/f397e+uc49jaIKBIIF2T4AHCHfCn9LnZbHBNJl5gPKPA pEnpoyRyVV4iiAl2kXR7ioolPVOKgBURwSSPV3QrYR9HepDPIYXp6qr0cM7AtpdNq1M1hhCePn36 3Xff4SeJ+3WLxQJ0czKZFJOyLMvZ2dn5+fl8vmBmNs5am1I/jWhF985fwyECipi+SUWac44UjjLS fxxXVOFDCndRSTUhirIkme5JD0mRZWUpNzpGIymmkpIFAgErCysOqrE2hGAgBzTdc0lJCdIPVOEj K4YNnW3QbKtl0oZJuUZk0WyqSd/997+tafcLOQPOOUE45BRhNQSkzWLkksxxTE03KmWc/r5d59AJ H9hXcNqAFN80DZxFQEFwrhDdIDTuMEhwklvfiTLHEaz1eOfWWqSQG/70AR2O3jsUOB5kEpAbPyqD m+pt+D6Gk8X7hbrcOsQpNt9SRe5STErAl7ATRL5sNht4uCN0X3oA4Ap5FjWMjjt2hBBWq1XyhMjX r/XNGoi23nt4RL59+xaZ14XTAHL48ssvU0nbnnFzvV6/e/cOKa5ROAOoMC6QrIxDLrjb7QSlkP3f 9NOED++CQo+4Bpxf2eG73W69XgNQGTWegu7BLIKDr68Rx5HsLpkmvBxCCBA4wEeBCkDFh+wCPi0W JdGKsUkwTv093BdGBQ5x9soEC7FW4Ll1XZPh0UUebfqyqqqQ8BoJTGXkgLtGrAep6TKwJiVl16QY +1Dfjo2HkX/xxRf48vr6WjzbJILBTeczZMgGz57NZtP5fD6fT2bToigQrEJsBiehMyqjSVAA/tTr i9ky89nZGbZ7RzT7Z5yZbXm0zGlf4GBmBNdwcvzG6vh+Wi0xgGmqbVNdeKA1mU0R9EILyN77ZDym GCOTNUgqFiMRSllyiMjdFkIIMNkyw+WwZ6dtmtg00dmRgqLWlU07+Bxfbc3g/YCF1qMi8RojoZgP LeQhre+yKoMIIBx8bKd+f032VVVVpW2PNAiBtpuQysYh4Mcos8+4i377mGBM+QdDCHotBXrBIQzJ jRQchXp0bTwgWXo68Dlveq0zKVzDMNTX4B/UtLShJYOPxDZktFnnaJ9qDx3BZsavjwJVtrWnGTcm tIOJTCQbiZtARMGE4D057LTOUzsQalzjr1iWBXgw2E3T1DE2zhZViJvNhpmnVfXo0aNiNiMRVmL0 3iN82hTu3sHD4nB7e0tEfZJCqCD9N3/zN6YXBt/u4W+++QaBGCJhwMHi8vJysVh88cUXrV7U15Hu 7u7+/d//HX6vsDIIOxQWO8oLN5vN+/fvcQHwv91uh5hMEgF3oE+ytTHGt2/f+pS0CjGlRPTu3bvd bvfZZ59l4C6a5JOA2l1VFQI9IIGF5JEAeL99d33MQFh+va/AQcSmhtU2qWWBbyEl1AIvF/DAqcqO o69SfgVcGpR/oUTdi+3DqGLm+vZD3Qo5ghAQ+4lQh+k9dG/GmFTrg2TiEpDiUskI389SKotpjIG8 8pvf/Ga1WuFlXVxcINzXWuvOzs6ADSBuGEkjxPZBxk6nU1d0yTa4Relb1w0ASiEVkZcRRFV5C+Az mASeYlOqZjht9SY/upBjjVN1dVIqIJ4rmEQSsXN6hzeKTW8O5OOSD9LhcK9nzRgT+5lYRxv22SGn Ar2ronL21mAJ900qGk15QOvm0twLgXCStoamuw9uh+wdMeWcFilWQxpuYqBJxBihRcldMUbk0xV4 Q2SOeNiTxvSTvMk1UYKQ1TsX/AmqQwjh0aNH1trJZCLZkX1bZqV7XzIAPXvqXtk9Asfx1ZbOOY6I +ye2UV9LzRVO6XNUsNCd/E8QOA7dm7XOiEPsvTcoeuA6N3ZwfHi2Yc+AHEXDGTnGltjtdpJ+SsoF ELULwap8RNt/fzwmBX/+6U9/qut6Op2DvxIRii08f/4c1A/hnUSE+Gpw4lZdJiKiP/7xj+DBQrH1 odY7FltaFH1KTAUcV/A8UiwcitzNzQ0Qgv1+DyAZdgpCqqHki9Z7FzEyM85vTKUZX758WZbl69ev iQhZXGPKRQSGIiyWUyGw9XqNAbuULEcW6lATSitRRYvFAiOUe4MqTm5S5JqAmrJuSByORJyCVRxy xQgHcvVqpS74xjhLD3HmgEfRcrn03kPb124GsBMd4VD6V6GNgmGgn0w/1739x3/8h3PuzZs3ADaw PggucTCmQAhoS4Sk2BDYPtgWpqvENnCujC6GULhZVVVMgamR+AKbEjcwWYrOmglFZiqIyHCJwwrt Pzvx9/I99bFHxbAQmX52SFGD3KdLxB19JltrRTw/mL2KA3EA8wjBE7V1OGOM1HdQN5Go8TTOboPw N3j7Nk1jTGaXhRqWUyQiUl/Kh4eQ4BB6kseDyLcS7MZ+7f0l4rbWAzpTVIyQqVGSTZ9J51xT1c45 ALwhBBRfFvECCXT1UzQZTdPqWSiG+Jb+NaRkbv25RsgcOHuz2QzkFbgxnKRi7HKljPmaBAXAdGNr CTcHIkLsEMdReUUPhqiNQBmaDo/deLyJOC4DG14ziuEfATa08PFDo2REXaQSMxPp8Bb9AQZIJsbK RR8r35gyhOAcdfhrNNYY42xBhFMfykmRFiSGoKyBIcYmsCUg9tQXOGKIxpgiEjWBi4O+zaLCwZ8R zptEBqxXqmpBUk/lIVs0DjkfKVUM2e12V1dXMPDHlC8yhCARUqSOEiJFMQbcPp1O4VFByQ6iGSSE ACSYgvMKUG1Ue/Dev3v3TqMLWQO2UVUVckigAC+ECc3ntEqdYZxgrvi82WxQgC3DZfVnLFEY+Emg E5m75sF6wIJtGGMAdWSAxKGDQwrhkK6YuUvvJHOkB2RtQc9wfMHgTUpEJhdI8DANnEZjjGCOMBZz StSJ7GSLxQKEV9ZzKEt98cUXv/nNb0JKiEcJPwbU5CSCCOJ5WZZOZeoUNMJaa4zrCeADL5hDmv0R WHXIcfv8bsjAevdqQqzfLic/BuzRmCLP9PC0PVWr7IfUd40AWmuNKsECahVD5OQtoVGWbE06/hca Go2d6Ms098Iq4y3GB7hu6Ag8dQs2TYiBEtxaN8e8je5tQwaM9RlOEDqKTxUO9QWIFYJXl/D4NHYW 9E/wLZA/4tZ5CuI1OpQYpUO289b6OMiMIlrdbDZDGB6nCsPW2kTKO9TNmF6WlBgjEYtSpXtuBwMc ESJ7JJnO6DC6kzUYP+x6x+WV1EYcOGTvDQFwtNF1Oy5w3DOIey84/vOna2rJOkRaPDaYORLHGBEo C1dKWbHuyNuc6+z3+6IoegIHt853si27p6qmd6lPpbl2uxY2h7MkM4tSK01OR4wR/grn5+dIyYAU T4c4ItjhdrtFCk6ctaZpgJmL01K2B0TpB7yB7b1er+EkUZYlqrGbQS477FI8Yr1eI1+4JKEKKWG0 pH7WK4OVxzvKfDDF3jGcozxXaDLc0uV9YQrylGHCAhAol3IBY9GgogvOpAeTie+SB1keJ8iKLOyD iL/0j2qusOVRkgI1JnRKE9kFlE2Ld5Ibbdgb4ChS0DsatmX7GrDdA1FkNq4IIVDsap4xW2S8UV2Y EJrEpaBwkzHW9JMkhBCsdcZYIsa/6XpQpREvtyMEZ4jTZoICiUqauL733lob0q9AePCrZFYdtoyO o1lrqVFCbuhtPmMMUW/1O3HkiC9ePzfDR7YQulxTzINCJ8ebvLfBBmqBByZKcfmSV59zxKt/J/e+ b5T5UzaifINsu60UErwICjA2UzJtGmNMbC1iQDtBX0R8SeaMjkm0gku9xUQuLy91DJRTyd9k6boJ YSeoWWqhoSgKgVXxL3gG6D6HPClhGlUdQojUxtaHVj9uW1JELCVRgwbCVrt0PXNk7nmTtuKpnH60 sSpUOxSdaaC9aS4yqlf0vjzwxONDundPH+tB4FTlriGDydIV4m0xM95OjKZpmia2dlhmDtxJ3tD5 0L3R+yUEZ4zIxNbaxWIRDUpCKRAyMVRHTGkk+TRihOOGr+tqv9/vdjHG0NBmt57NZtPptE0UEWJH VbEUUCdiNMze+/Vqtd1sLi8vy7K8Wy6br75idY08zRlriF+9ePndd9/hTAFKXCwWsQkCIo6yHOFP UIvxp1SwE5NK9qZEgcRPglw2TYOAc4gUhyTv7NRnI3Ept7Jm/3KNuEqUZYlUp0fACd1CMu5st1sg MTJ+VP6DIEgq8kAeKrPLngKzBWUwDPc8tEaRRTTstOl0KpndSbKHJ08JMVpRUpz0islnsQya1PC9 c+6QnOpVhOCoiNbLHS7E5RCO+iGq9lj7MPI32o4sPSWQg5M2KbJItoJHmpwo55yxREQBOKSqi4Zr sr4gcAyPRw+YgdRiUkTJCc30E19S944METUpGBVTm83n93cbY1P7Tm5TlwclYtbeY/CIOvPez2az GKM9rDoo806bFzWkMgc4FSIlgJnBqZuI6mqHc7jb7ZbL5XK5xAojatpEms/nMGGId7d2B8tkGjxC pBmfJoKGZPw0lpNbFDVW32jeiVvQs34X2BIcWKamCSIcjUP0yuLTk1O7z4kvdnRKb6W+fqiHTWqf hIcHBnO//BsnjH3Yz/GoimG3evVOMamMjvxTUaGHthhj1PmXig6QwFYxrkNMu1uSjR8MAD4N8BaP pK8S+9p4PJUIc7e3t3JSKBrhWLL3FNHuMnWC02y3281mM5+3/h+vX79eLpfofL/fO5cbHeD5ASUe E0Gt0crXMTk0DOUGUAkRU7D/8VwYQ0Mq9J0tb5NSDQlOaVW2az3H4frIrJ1zkHKgTuj05PgTx1Zk IBqTmylRfjFwOOeG7FNLBvotQIEX4w4s8trqhCuldoxuiLUsimL4uGyEo18KrKJjOCgpV1KDHUQS H/R7l+ZTxS7Bb7SSNooY6UyyIZVfzobqyJjIzNYGIjvyLrlpgiv096b/a5eh+QhzFblP/zQc8fF2 BJA4JDrAlTVSewj12zXJN+UUsaOlvOlGeVsg64ckxHDAWNBuYvkJYoc9lv9bN/10+VxVPoRg0kwx O2tteZr5Y1RuM0QmwQZkGOZYY8x6uzLGID8B1rAVU2JrQRh2DnswFCN9EjLJDxBu4ysAsHd3d6vV CmcVMy3L0sReD+I3TkQQhjKqJG9B71I5NplVOGutwKo4w3BqQmGj8gpiZmraZ1lrQ0DUDKU/Q4IP gx0zq8GFE8818X5Nazgq+RwHVbNlav1H5o9w/eTT+iA/aDDdEwbU50FEQJ575K4TxzbaA4S5Q4n8 kTm0373z3sNzK1JDjExgvYWFdAudvkn54kIIELdSKjDoHtFQC/mOjkGo//X1tWxdX9cxxv1+Dy8i TWZDCEStiCACBzYDEMqmaV69evX+/fuY3Dj0suDUJMPNDhotvgkhuJQjaxTemM/nkGNwAbJe4ggD WTGqWqR+KUA1gA0YYwAIGZX57d6DIDo92DwmJd6LpJhU9kEQyvW6TVUCN4jZbDZ8qHZbEVVevgzJ QCakSXNrUgIHLLAyVBgd8FyRL1vOxSbE+4mAJqfQ8cR1Q6J5F4tFF6hijDF5AifYYiAPhYTR6jyc MBgNny7YjPyZ+eoRkdNWhmHTonp2TQjh4OkcWwgas4l8sElFeoiqoM5oc86FJr9XYlvuHTarSkvw AA2o0XX8TkgDY2XYRODolhT+FgdopbwCn3LviB4Afyi5slFlWEKqNSy99DodvEqs4Xq9lqIqi8Xi 9vYWNkUigsmDlKMW9hwOmxY4cPbu7u5QZ4SShfvu7q6u688//zzjOtjHoFCYl+EI2V80JDwaHU6L Umfj0YrFoW0ANzrkrgG9M8YgU5wM5pDF1JgutXmHAyUUQWworPLNYH1gUkmhs50bB0Si2Na+yQHV 9L5CjBHuovxAIGFU7hcaJyhmfpv6QuCNTHo+fQyfvH2MoPOpBkB9Iwj118R7b10blSDMGz40+Aab sG2m9N4nTw5DRLAaHB8D1NbXr1+fnZ1dXl4yc9ME7fjJmXs7MwQOyCLCU0OKVri+vr6+vpYbdfJ1 fKk9DPCvtnHopdDts88+Q+JOOFrhep+STV1dXZkDOTS1Xi51yEEHIMo3KY9W1jhZW5DVtAUmU8ZM mD7JmKaubUqHKGkRZrMZMwOAEdUFfipwWQ3JbqLHman4yKOK4w/5sigKqTaihRtZMaHhOJX6rCGC V+Mr9zYNnwyFs5BSqGlIRq7XYXh4NcvlcrPZYElBDaQ2O94FMpdkUoHs/KIo/vmf//lf//VfZak7 oIhaeuSsLfCB1B7C/eAxKaCk824VrYeT54QIkqOSb/ZNJnC0Dz0gA7RnWGUaxfWG7VBsscb2/xzv s0j+xNAAACAASURBVPfcQRs9/yLljPwUiWOrJ5lIKZ0GAd/D56BCpOCUIA+jzicmdSg/EcF2WxYF xejrGgdvs16j5/l8HnxDITYKOcAgm7om4VjGdGZdonq3L6aT3WbLzMjPrdGa9d2q8vX79+9v7+68 9z603vXoFin6V6tVTLGp0+l0Mp3jqOx2u9evX8OP/ZtvvvnpT3+K6kSPHz9m5vPz891uJ2lh8Thr LYQMa63hzgwB6pkdoQwtlLUlBf9Ig+daObFIAOOcK4ri7OxsNpvpUzp8s/hclmVTeyEcsg3kRjlm wqRbl+FWoUVF+y6ynziYaKgVOPKSe5idIRPbVG4PcJOMsYkxhhhkw8cYm9AYjhQbIjJM7QeTVymK 3DtZZsyR9nSW/5FYyKEOj19wSjenP5CI7nNR7bYZlPLae+ccszI0xBRuHQIz1/t9VRRFUbA1EDi8 92xcpmUeb3Bsojb1UYBbpfyakdmqqqCtygkSkANaQZvroh1wjnBobWe73eIEoXbXEYED4ghEE1Ri Q4gKEc3nc+gww7vwONGm4BwalIUiy8ueNVAS7z0uE9dRowrM6n8FOMHKvH//3lpruXNCcqmk+71R tcaY1WqFt2CMAcGfz+eIVqM+8GCU1wuUH/gRy2Jaa+GBEWPU/r+jEOyQDGL6MEOjf7lXouqAVWtl VYtQEDgQ4eJStgtwdpvyoEjTo4IYAK/5b7/9VqRSTm4MRORgKzIphJqS5IUumpQFJcaoj2vSiTuB A/9KdMaJOpmWbNKH49eMi7enPOvQAMLA2nK8yY7BedTSK05tUJYUqXyo22azQfqT0YPXttQDdh4l 26QwVLB52UB9H1aCpzdcrA94aHfPvbm5ubm5ef/+PULgROyA//yuqtbrdRNDWZaBCbCKxKwCebu5 ubm6ulo8unj+/Dm+f/v2LcQRZl4ul5BCYA4UG6qsp1dZQWOMgBRisj7IhkyCb+eQ0U0mXSMgHv6E FIWuptPpfD4/OztbLBaZo6gcjKHAwclXQ96yfr/y+mJKVIrG3KZ8C6lGNlQuZibuXFxjHBFei6Jg WIVQr0e5udBR1svcST+yYtn1gjV2TBHj5+7L4a+H2hE2+QllDiEyRwbAY36Ig/bJXMekga1GWB+Y 67q2tnDOJQWpX9AxRqjCsU0X5GOMQTlCcqv79h4RVNtut3Vdi14HG4SsT13X4h5YVRVxh4oLY8Aj 9vv99fV1kxKBU7thepsffd7d3eHepmlw9rP6txnPMynjpE8lSKy1Z2dnoLSAHEZ1Nu47jeKkg8OB bmDWh3aUCBMmlaLFSZTcJ9TnFLo3lH159uxZaNq7xNEBLF/mKKJbBhIg8BjjBFVcLBZSsvVQ0zXS NJghQc6ZkWLYRqUQIkKirSycEFtIcPFDPYss0lY/UYtp+qVChj0gn3pRFACHwINgJMIFSJHb7nVm S2QoGooRTtwxcOOjsUprbCuvdvsjHRKGt0trok6NpUjpoDF3cZtHBI7sgu+jBeXBcPqDQgj2gOsb VPDG+7qqcKqDwh6YuXCuLAqTdGKintUj0+91gzPEer3GIemOX6sP98YA3ozesK3jWKzBfr/f7/cQ OHy6xjkHPayhCF9q51xWcp2ZwdExi6b2y5tbiBfb9cZX9dnZGRPtt7v9dheaJvimsK61UDQBA45N sGz21d57X04npFzDRLiWpdM6yvEWYwQqiD+R0Q6pFQ8Fcx7iWGw6qSLGnnFE7uWUpbgT55sAMaEx pjHUFpVNKia1+VRG9k+M0VITQkA4rjiKhuRyOyS5SYJhwyYajjE2QKRCdGyiLlOeEDibVC6MP9gu IEWvyfAp2TeHGEA8wV/1RHHkBEniz9ZS7DYxp0IQoTNdGXbUrwUD5XKCIgkhNlXNtoixtbi3Ykd/ d5tIoQnB+91ut7lbldZZYhPJGBNq79gg30/7HwUKnsgYCtW+8vsKF+BfDhEuUL4J29V6Vk44xP1m S09GpiblD7WijDMIh3FWIYHSYoz7/R7aLczHMUb8KRDmiWsr/OXs7MwYA/BjdCeYgZ+HFjiQmf7Q U0xKHGKMqWsvooZGBSidPpGWYoy6fPoQBUG9Ogh8GuGQh5qUlFO7/YpHLadUWMMBn0L9aCx5AfYe DQBjSKT4yzmHP4lMUUyMEWnDJhuyIaqSg5/BBf3ldM6V8ixt/iaYVPRa6NfpvbdFa0c3xhDyH/fI X4eW2FRv5tCK/I8lGaIr4E9tThPCkTW8gzdv3vzo8VWMER6ONjZEdH62AIa52Wz2qSiApKhC8g/Y HZDxDdtiOp3CyWC9XiPkHc7hoqBTSqAbY7y5uYG7O/IHQ4QcChxaFEUPKJlorX3x4oUWZfAIiC9R QY7nlxdEBGwtQopKeWlMqhmBLBQinkvOYyISFAHKvaBt1Jfw0BqVmYPT+AVdkBkdIRyUdAV8BroT UjGkyWTy6NEjWL4P3Z4pXizRGYotxkEzKtMrJwkyhICCwqG1OnfRK7FFBA+6oMcYbfIdiamCD6Xk LoeEADl62GmccvOHvueyDNKqUs8QOFhVZMz6F7FV3tGRt6AfdGSOp4gRmVR3ooDyCZs8sQ0KSSMh RTc4uXnFtliag0umc27oihuTWxIlDAAbdb44k12UATF4oSH5A4FohBS0JWkbiWiz2czPpjGhHVLN RIQD0Tf2+/10Op3NZkVR3NzcPHn2o2ycouZeXl5KLgpK7gXwexh9I8aYuq6RnybGCOIAX0XvPTTg e5cd+1b8HDObSPZQkyrXcILYsWIi6LQ+HAe4UrZRtTohbqciapBCYih0zltYqza7RAjIqKEp8BCK wLxkjqRcWARlAV4yO5vTQxoeipSemmAegqbCwCUFA0ZdYsDPoZ9ERMJih7z+Rz/60X//93/jM/xG ZS4kYbG6xZGgDwPiEGMbqz1KLEw/R7geDQ8c1HU7zgMO/fRpm1ZBRNUTqTZdA1fQNsgNwEBVVftN J3BsV2siWq+Wd3d3m1VbLxGShCysZGSXs2dSBFdVVcghWFWVRJQJ2V2tVhKoZozBfr29vb28vPQ+ OOe2272elCByMG3WdY0Sz0SEpDqNKjfMKlQPksTNu/dE1OC9gVkmnLNJqfWxUEjvDeMOiMXFxQXc 44QqXV5eilwyFDiiMqA0TeukDaoakxWj6ddkOvQSZc3xJ7qF30Z2/XB3jSMcRx6ZmlHZjkGnDJsQ QuDIHJmLTiIPMRiLqIeDvQUfQmjT1KZ5CXyo2TD1ZQKt6uFd6OOs5QwBt9vvi/FQN7lxdGWOCw1H 5IMjHQ47/7OIGvc2CH/BN9G2rkjw3iDXph/w3kthqI4SxtikFPixdXQIIYTtdgszK/U9TZJ42raq qs7Ozs7OzkA6rp5chhDOH10C+V+tVk9/dIVtBiVHU+BMWCzL8smTJ0VRLJdLDtESB+6UK2a739dE htkWxaSuayjBzpVV5Y1x0+m8zdU0EKqWyyUSQ4l+T0mtFRXr3iaDhzgFjn7InUI/Atteb+bjIg4C 40UB0wAJKUFB81f5Uh4kQqSAB6iKilkcQmXAtrNQVZm4MIVFfVDLygQaGaT3/tmzZ0NqKeBCZ+MY hPuGvo8BZCDRMzG8I3k43r17J/PV48EcR2qIUDKrZy6y7U6NEefEWjuMpc8Ei1F4wKiIlT877DFK yPTWwUxJ+aWLYeLrr79e3dxWVXX98sVut9uv74jaEvONr5qmubtdAvyAWqOTT+DLn//857/61a/w 7n/5y182qeEykQaQn985t1wus7AUfLi5uUnlqntvRMMYkn8G6gL8uYZLEamNg8VoN5vN/OKRMSaC SaQweuFkMJFCLHC2DQYD+ROXfLipI8N/dvjlz1aJMW0JFYhK0LkxHkqigz+aN1DS6ZAK4j87O4M+ Mbz+lB2or2CVAouTA5D+ICtjqLtMVCVmJo7GmOPV9Ww0TdOIwEFpTwIrkss05MCploRQEHHyF1xE 0IvJZKL7YebsG+ofDWb2qnjvkdXL7joyxyM3yu2iWQqM9INJHrH/JEE49KRAHIAp2VSOx6g82WjQ YeRlIXJkMplEpqqqKh8oZbzIBqA/iNhxfn4+nU7xXByoxdn5+fm5SckPiAg5xTXfAp+QfJEg7z/7 2c8uLi5ke+jXBQVgtVoBlBXvEFIZuHng+YFxrtdr1AHFwc9qzEoyzeGCZ3Cm3CKa+iGAE5sEfqZi xxEFQEts+i45qjo2/pDirkGXzD6CEyfhb5gshj3KleUu/Vw0/XR02NaPHIaI9puGK/SAh1di/Frg gIOtnhGkJbG/eO8nk8kRqquHIU9cLpdSwl3ovPM+WGsp2hhME4M1joi9b4rCiZ2Gomm8AJsIBy+Y 2XPSb5KRmy3DsjU6GnQRLBORcTYc9tjobvlQ+vUxTWQCUsIstivG8PLly//3//5/bm9v/+33/1eM 0Tb+6dOn1y//eHV19f7tu6dPn97e3oYQONJyuTyy5379619Toke/+c1vZL8Ke8C9yH81vF28oInI +6ppGk7pErO1wl7Zb7bn5+fb1RpQih9khjHGkE2bvmli8oeaz+caWY5MSLkYmWzh5ouz1lYSDRFN ZlOIF9baq6sr7Dnn3OvXry8vL2FjChR9aMqylJ1jC2eTUs7WRCaG9cGaGAJbE2OEjWaUWsmUtUG0 LMuLi4uLi4vFYjGaRP6Ulu3mqDzaBJXBT0IXkmpeMzfM0RiCc3G7ldoI6F7OkuGMjDEa4RBbzPAU NCmBGFpGnmI/+bQdS9Z0yKlFT5kTXi0696HlOjSjA012INhqN2z5kigYw8zGex/zbATxwOfRwQ1O ojxPf2ApKNt2ysw2tpkzmJijZaIYiYmaqt7VbQKGopjYojCOOEQKkQ2FZm+tbbynsvWNi2Sbpm72 0XtfN94YE2LjvZ/W0+BbeS5lmG1pd4yRY4ghcAyb1d1sUs6mk7quz88fATB49uzZfD6fTovQ7Lfb tXOurvfMETm08C8RE4UYG6JgjGGOT548/ulPf2yM2W7XBGozyPQATkNpdyEeMiTHTIIsHnuiM0cT G7LsOBrLrrBlzb6pg3PtN5NiytEw1rP3Jo1hR9EYNiH60BD+lO+7/wbN9HNeBVW11afC8cetsZnV QDoclTyybyT6Q74Jqlz7kTYUboTHo8Pz83PUNAHbxjXZ+dW3i5qqBxn63i2ySqOTEgAD6TpAkLOS uXRY8tMdCgpiUvqAyWTSrZGo8mJTGC4NEVlrOh2Oo8Ce4sl/CCwlhX88KK/An6tpKEJmZIxpiPb7 /XK5hD2FiGJoXr58aYnevXvHRG/evGm7CDGqrHmhX19RGjiEvMLhhh7uSGkotAPAM8ZxnF6DZu/f vzfJri/SqKBNZVmCn4cQrLV18jPf7XYF0vXAP8C2L1Gwn8ViUZalYTeZTPb7PULSgXyAwzVN02Ym tZaZ4VZGij/hcNYpiFfvItktTd15PI02MEWsJ5y0Iesw8/3c6LTGA99SLQrIr6KVitSob9RcWa6U DruXMojFxdwzMcWo0FxSqKno09n4oapmCMfoZz3HD1qtD28a3tCk9tD1D8I/PpXqAv1e40xRJZYN ISCKpae5MnvvI8e6rsmwJt8ZzxviSWhQfNsTZ4xR0Y+UknRlt4QQoPnIMCaTyePHj2OM4GTtplV5 VFl5RRARLHHI+ARCcWhLSKSWfCNzDBKGKvad/jUyWmFU8j1uz7wQ+i+i44i4DLYYEBaBdkZvl+cW 1om346gMYfqZu2TwADOAxOhYFTqBN0v/1Gf8eJwA3kfu0n9i7hcXF2J+EqgjE4CG4o6s/NOnT3V+ sEPSSbaeuOzq6go+HMvlEjQfv7ZyAv6oqqpIVYigdAI3s0UvejB7BkitlLMfjmC0/WBAxSdp+k2H ZMpaLpcvXryIqRi6C02M0cSaqMt4H0Joau9TaY+QfLWyrSM68TAg5ZSGcwjC572PfmRfZlsN4j9E HKMSACTi0uG3iYdS0zRhv0cqHu89hV6+WxgsnHNlMYU3WUzWlrOzM7i1GmPEhxSdykEC8SqKQiya N7fvFovFer2eTqcS2RtjRG756BsRQYYnQRIEITUesm58wMIeaZlUQcqSopFzLQFAIECGndjvCh/0 rogxIhm/FlwyqG+4izhlwZFh4KdMuJdRaRk6m2BGT+XLQyzwQ1uvfzkI+FOz8COX6Ys/oA2lveOt hT6YiIhDZOaQ3mdMkQ5w92ei0DRElpMrWHpcbFKiPGdbq4TgRhow0yIUqzJpi8UChlFSCSpEpxct dpgZD0m+4fiFQycsub194KxqlNEBJxpu7JPJZDKZUF8cTGvUi26FHgu6IUL5UOCQyYrUnglSmO+o wKE38Gw2Ez0QvhFHDAFBZdzK+C4+4F445x4xVZgUbxJUeTNt+z7ejoMooxRg9C40PPfi4gL4t4xW jx8fqqqi/vfYBt7758+fX15evnz50hgjkiIlkc4596c//emXv/zl6ADwpkyy2gg5Yua6rltYApZv 7D/A1yPF6PsrYowJFLWjO748cviPgB8Paj+YyDIUivHn3d3d9fW1994ixqzahxA4VCEERHu26Ijv CDRoinDZIRkdmgbRMgE5Oz+ypCHEpmk48lCjjSmfXUjmW1K5s2QxmXk2m4WUW9c5h2wQ292GiFxR NE3DIez3e+Os2CzFk/n8/LwspkFlOIUjCCJEXMqGC+IrKcAhtJ2fn19eXsJtvqqqi8tHqHQgWYDa vduEyWQSbTdBweQEPGhJIREzA3C2Dy+6eG8TSUKeG5Vfp+hbmp8BschevdyltWRmptiZck4ZOSd7 B/aDU0lmtWY2bKK/Dn/SRDbjgie2+87pg71NP+1L1N0eH2rMPRW6lxjU8TEBfk4F1t8Y45vKKBcB qB5EFNLJ9aoeckxRRXhZ220lHv5A6fAn5H7ttX1zc+OckyRRGdWC8XSz2RjVrq6u8Cu48nB7hORG gD+dc5AbkODh/Pz8XnuB1oNF1IipZljshybEvtmuruvHjx9DgHOpknnG4+WzfnegIdvtFgsC5nfI 1TTjRyEEdl1sl4ScHJ8mBgMnWZHtjDHa3n1oceBqk5H0UXH/xAYi75x7/vz5d999R8moJGKo4Cgh pYomlakd3EGc8KTcjIgsInD84Q9/ODQGZB85OztDYHAWKePacsnNFlEM+/3elUVZlsYczOwWlM+q XibB3+QB2TE+HQX5s7SMnGErRNVS7siAvN3T6TRGqus6wkc9eO99tdt3zKPpnRC9kzS8Scp9KeMN eMdaWAZaQAlZFd3IRBN904RxeVmbBil5j5MSfUTS1wMwCgsNMcL9U2Tts7Ozx48fi86x2WzMWVvh CTgt8L3ZbDbUMzLBFHO/vLx8d/O+mJShqauqQl1s+JC2BjsORGSK7i5SZbJ9qsqGXyHlZKW6H9Q6 UWzwkwxe73ARLFr5O5pOyEh6RreXFJ/Tfp2iGupHxKNuE8MBt3GAh5v82qnRSUjSl5k+oqu31inj ubfp1Rv21o3tQ+nvBzT90Pab4TU6BaISOKiJzGyAc8BuTVGEv6TTt//ipECSkNTjjUoCBmyvLVho DBEVRQETKoBSQSYgTOx2uy+++AKDcSp/OSzx2HvI+ImxQdbRwoduOLw6g0VIBoLZbIaoNEp7NVtB 7H9x3xbOLdzr0OIjbhYADPQfsYkYYw6dZVZ+3JjmbDb78Y9/LHUMZFmONCFZstpGpSilvvwt31AC meC0S4n3uVQl7jizA/GUa+StaWcU/HSi3COfp9Mpsjm7FDlIKV87Jb9RnXpRbsQK4EpAYia5weoH 3dzcHBlSCGE2m33++efX19ehb5lyiO2UqijT6bScTiaTyWyWxxAen6RE/R1K8/XJGx8Ntf2wFpPZ Gy8DR054vE3F6na7HZIZT6xrmgYYYo2sG1VXFlXnb8iEiajQDlKBQ6IPycUgFj5VgQopKz40eGCV 3nsTjfe+qvJQAlwMjg7GhikgTLdJRQcmkwnKK1PSM5g5JtW5rmtjbdM0piiICNYKWEBkM4UQVqsV AA/ddrvdxcUFM5+dnW02mzjm5RNCgOs+DnldtQGxoLniMMWOiLpEWGL5FjUdAjXS/p/iU32o3buB 5QLNmVi1I8xYQ0pxwOZjinGIMSLT6OmjEsV3ePG9wkFINag0YZXjQERVVQ07+biTzsOJUx//E1Yd BsHAH9MOCTdERIN3F7P/9wWOnlEARcldAY+HpmkoZf8MYlVJAgdzV2dRtMCg8upK7U00k0wMshqt /3UI0+kUiR31sHEeQwiSVjKmhH54blVVoHJIz6MbVBRdZxXUA6/78vISltMwcEeTBZRTgCoq1lqp W3TIpyHGuFwuIRKVZfmjH/0IuCkR/cM//MOvfvWr6XT65MmTofAtMjr+hFgDBzJIA0cCcYXBt+6l 5UQosHOdP4csghBn+QYrOZlMRD6QL0XSOsSbg7LpQALQrF3oGxZzKO5n7C+muidYis1m41Lyhcwb Y5Rv+pTRwBgDN8TMrTBTkg/50zx+/Pj3v/+92NEyOuxevXpFRFrgmMymi8Xi6dORKF5KG3e4ajqY c1T/++TNGINkWZ+22xCCjheNKqFeiBHpdASkykikT6GDLfCg1knkdFLi6na71dtIHw8IHyGlgoGa 0qTyK0J90JiZGojV1Xq91tNxziHikZmxXJyMrJBSQwhg0piIYUYgXAhhX1VROY7Vde2StaKVTsZW T3/vU3B1CAF1NREp4Iq+j1j0q/XSOjbGmNnk7u4ON+oxU0IapHcND+AbGFNQZOiEV/2wpgXc7NxK nIhQB2a2seMN8iWu1zfKLETUMEZKy4+HoR4CPNhEPsBKmTPZqHdNiB6BtKb1Nu3dHiPk78yskPc5 GOp46E3/C02II1GgNi67C12JrTkj9AeQfYj96w+1g/qJ3BXCYAH7fzLzEYED1IOZcaaM7SkYnMpk hWTGMslk4FNlUR2PIF8KNG2Mub29xe4AF0HSC+89MHzhnboMgvSGD0Jb3rx58/z581F+LDu825PG gNSPIiL6TqEw2PMwkUyn05/+9KfwsRBv6MxMhQpqy+XSOffjH//4H//xH7/88kto2//0T/+EMdR1 3QaW9++NKhrr/Pz8888/R6XZ6XT6k5/8BLVFDk0TRHKz2Vw8Otf5PafTqXa2pcMOT07FmsrtR1xr 5ekxRpfytmVVt4hOAjaykaBJEKIMT7vNSvZFGtjoIfHc3Ny8efNmOHiRccVJyPS9W6if9eTy8nK1 WhmVZcPd3Nwwswgc2+32zC9ETx0ylZAqi+Ltikgu0Th6jT61SpR39ckFmuMvWEBF+VAU3eLKZFEY iYg4di9VIFMZvGhv0gPEFOAHnHwApVYCfpVKCiIKSKyaXNY0jWQRltgkyUgopgdOJbNFRjQpr0ZQ DuF62yFBIaU0+8P1gYlXJ/iiZPXwzbhmAzS4qiqUM7i9vcWjszQhw4azofch1AW9MT7VDoG0Ib3p 1CxoOjYV+fXwkkRqlBcqN6ZkNnl+ObQQ2hDnoWxxHEH54JZFSUj7Pp6VtaCMTRm88aABfPBQ5eCH wX4ZEzjUjT2rUOsYLhy3nDhmRhK/1ixIxlob+kbMsiyZep5GIn0KE4Iiwcz71ISXQOkCoZAUnzqA WcZjUkUSZgb2wP1kvtTX7KXomnz/6NEjFGUc9VHIMAzd8/Pnz5lZ0mGNvgUwJ+fc06dPv/rqqy++ +ELXcxahhzjfpVoBCCH8y7/8y3w+v7y8BG3Z7Xa/+93vho8T7WixaFmemIxxkJExVr7MdpcQ4Uzv B7ICGVGuHJ0v9bdBGATCPKjJ7YBbYJ/CT5kjBZoxhowJCVmXHsqy/O1vf/v27Vt5fUJwsDEwR1D7 oZ1rMplgb4BIClAHS1lyZo4tBYT1N/TdCVPraa5N04SUzSi7eKhffk9QB872J+8WSrO8+6yJnVXE rOxXSiWdIHA4lX8TL14fD1ltkxwysL9hF4gKnIwpkiWqYs1SAbWqKxnAEJrGXIZuUCEB6fKN+K6K 5Q/HJt73Er33FNtCxrp/BEDVdT2SBUHfSwSPUQnkicm5RIKKhzcC5dLyDX8KQ5sWC6QdQU2EiIsM Z4wxsVNWbCpaHVTAgpbOP5EMETQ3TB0OUYGRltCj/B3HGGMI3AcYZKhHNkRMKeqHT8kHnUSr4S34 Rn+Z6cSHnz8ynuMrMOy//003d41q9KoLtYsIlTholg9Pi8lkwsglQN3BxOfCtWHhEjdO6fi4lHFg vV4jf6C4X1AiI/j35ubmr/76ixACqiuQOjWyM9F/Roicc9vt1hSOVN7hoRAcY7y4uICZQ+iDbiJb C9QnqZ/Oz88vLi4gBIyuvEwE43n27BkedCIDNik2NYSwWCwuLy9BuBaLxbt374YojsZiYX+BuKMf l2EbQxIkQgb+FGacrc8RPVauGQ0O0DjT8LmjbT6f68qUMgWjcrB2z0qOgzIYLNo333yjrSGdOJ6a SxncR5cFTVCWoBK3tFt5v2u1yf1+Dx8OGoAtwyaamVb+zFhh6++jPQhuelCTDBN4GZx8XZlYGLYI Ac65ep9HQMECyrFLKQEGIxVigwIeo6opGrssrixOmtKCwudFviai6XTq9+3+BuBBA/jdpiY9IH7E pnScJjWBJdrDb4wxJsLT4oDY0W7raEaRj91ux8xHBA5SEKJ2n8RPcvjvfXGmXwfk4xsrU87pt2Cd XezeEd6pvC8RaMxD6pL/AC30LWJaQvpU/R+/YPgskc/uHca91xz5VX66F+HIvukLQIGI2LQZbqJK xg99t67rcuK0wEEHkhkg8IqI4PpHRHd3dyi/DEcoSl7tuAvg5c3NzWq1kgwQus8mJUUVqOMQedfq kHbjwN5A7j7ABtnF+nZKuYPBjPElgtFobBuYFDoOSnVxcTGfzyFAjIoaWg6gZIwwCbo3qsRMOBql JQ1AkVFeGsJTj9wVksmblP1L/yRD1cdKqBwoAN6XoEoYLRwvRu0aeuKjDcfWGIM4EZkgnoJU0+H8 ZgAAIABJREFU0bKwVVUNwQLJMykz2u12Wv474hZjjJEYZlm9nkmlrutqXyMV636/nzcN3tYhuUF2 LRAOrQ5+jKfehzWBWKR9fxRc+HFHng6ch6b2wTeGKMQYjbFFwTEW1k6KorC21VGaxjI3qFCecBFb lhwjxzibTApr4XDBMdr0ASGwhiQLLDkVA4lBAgkktcu1KiNyyZMnT6TWKyATk2A9fT0b8t4zfhqs dtZGz2cLPByWQrWUw/2yq/9D2nEZenSoJhIhLUskZmMtN01D1njvI1Fo+SiJ4h0jed8QMzUhUBdc /Un28xANzqeAU0xECu6KRIbaGBbNzocfho3vG3m4by+NtuMTuW+tRnJ4ZDfei3BQ32l0AAl1WqD3 3rpGorI1NxptMUYJYaVkPWlSzaO6rlGsEQcETqlaG5lMJnVdw/+pLEvoEtvtViCWqAzfMVVE4jao PjjnSJEyaLoSpyAsCh+GVe/19PFBdPRDSjDUGH2jyAewvPR08aNN1BX4b758+RIJ4GUYxxN/6djg 0PdZkaZ/1c+VphXImDJNaF1R7pIvYceB9262SmVZIsLoXlFp2GTlS1WJXrafSfEpo0JDxgKyFZZr jjz9m2++Qc8w9FMSxRDX6e7u7kIIjW+Lam6329W33/7iF79YLBankANhDEFZsO6963tqWIgPTk90 nBwYY+bTGV6bWGT1/steA8izHgzOMHa2ZI099Dict9HIZNGb8a9TiUQhXYqNTVwE5OjKnpOIL5ci 7KWQo+w5lKSPFJxzbAwR8aCa6JEGwofPzBzjwQMviuButxP/oR9G5hjixtlPxhhzH8Zxr0ygLSbm aAatJM2HGEdyOJ/C6T94kIeuCR8UIfLQxx2HHzLZ65Cccd9DDwpwHyxw9KaQvvcpyRVAiJDq94px JB4w7sAFilq7RoN9stlsRHvGB2HMQaECOOyo7QzXLp37RwYGAQjAyRGKB4672+0ePXqED1BLwNQf xAX1U47TWKnTBOp3vE+RALT1IYSwWq1ev37985//HFKRRHgeenRIMEyZiqjpcWox8bj5QIrLwJ6+ 3+83m4144I3eBQ8VoczZlEM/fOEDmul7dILjiONnFtakGydPdtljAqtDtMWksOWyzaChitvb2wzz dsvl0lpLkRE86b2/Wd4+fvwYgZdhoL2FMQe3P2MTVV6cBz+4qyEn0Espn5EiIlFA0sxe3ysUIYMf BN/TeAMaD1qmxBRFISRDRAedxQ8mG9QxgeOSSf6nEusvBiPqF/ECFEnJ7UsEDlQZiwm3dM5JARRS XsMSSzZc1UOGA3FlkipHH/P6PqCduJM/QMnQjY/6Z2Q7ZHQFvj/QTj2jIcASgzAN4DB5sgVBRA73 eI+Bg3qg0VCqkO97v/Yvpr608cMLHPp94dsQu+TCkSxOomD1suWGL3q320UmgI7UhpdG/AlQAe5N 5+fn+F64MlwQoOlBJ9Zl2UXDhgDE3JJ6kUhI8uJEIqLA7YaH9URo1OPHj0FG4OonnWezaJoGsApC 7nWCMuq7FAzfwrNnz0K/CsmDQA7IDd77f/u3f5tOp7/4xS/Ksnzz5g3yaw0fyimBh6he8pNJvt50 VFiRpmOPRRsUh1MegHlyGaV6DrpA3Sk2oNEmdw09SERUhUWMVFqOrOEyLaw8evRIB8E65969e0cH XqKOsl4sFtvtVjRtEh8ObDVwXEhViSfdM205PNxH73+AJiI/EUnklWyaT57QejqdUojGmJubm+vr axz4VgFOTYA4/Q0pR4rYj1UByZCYNylyoferlhLgU5ZlXdMfZKe6lIpYomdl0bIBc99mT0qShUJj TFfoHMF+bA/uCk1M8VzpfygIZ/jQUGITVv0JN5XmN59KboYw9wE0IqTsCMKisgtOxAA+YTsEHuhv TkEUPsloY2rdnwNL0wlyRt7hkdE+GOHoXQmRKEXA9hvoVZpP9z1qboOURe4kEmt5u90i5A0NGAkg QIgXTdPM53NEdcJJCBRDcnYhe4pkD1IPbSuxtRO3hlSMkpxf59zZ2VlVVahRwMx1XQOtkYqseq2E g4BYychFo4D5IBywboh/vahkR6SNoeAinHWz2fz2t78FXQXie6gTSpIKYjr0CojoE5Q3xqEzLq42 YrwwKSk49clXUD4l2oVfvhQfeR3sc3r2B8F7QnLqFEhDZoGHHkmKKHPBqJzKZYJvbm5uDr0ayCLi BJkxoJ7gKStFR+Gj4+0HVlLRcAy0lyV2+UPdV3ksF2r3ZQxVVb19+/bVq1fItBOYqqqS6gmyspZ5 3jctWV2gPERDTCHiQ+kKIipdAbSqfdm+IddeEEJ0xjpjF/MzIiqKYj6dGWJDXFhn2Vg2TGSN4UiW DRFZxOtaMmzm05kzNhAH3xhiVCQRXsvMkQl6D74xypPZGBMNhRBskh6KoiDThdLJxjq0np2LCffk MFbxeBDCcPxEJ9PSwAfvxqyN6mRH2hESQ4lLhRQTpNFX6vPFlspHwr8UYmxCjDE0jdzV/hQzH4H7 ZyT/DgGHezmxXCBxIt+3DCFdjc7yXjFiKIJkd9372HvmePCbBwgc1LdDaYGjFaPHsBYIHGDqYH7g hTp2PbM1oHw8FK02WV8SL5rU1us1EFlOLsBoYoXx3lMzcrhCCAKchGTHkRi6I4q7kGJkvzAqcyUd 9TfMUNIPkOCNMZAeXr9+fXV1tVgspJDbkbvAkmezWUhlpzIR4TjxiTFuNhsJwMkkoZDy+AmAgZcV Y0T8qlwmwUch2c7E1vygFWDmLA+HVs7dCflPURpQBDVhDbI+AI1G+7m6uvrDH/4grjMZC5Zw4TYs tmma8/NzORjc1inCxuqUVyHch9DyH7jhKIZkxfg+wmRCCFjdu7u729tbyaBFKh5EzjAiPIOqG2JV BVQcWjht6T2H98cpzBguY7jLWquTo2hWLXK97kQa0iFT329Ip75m5kBtBM1isfCxG0wLX5sOO0Ge crat8CGtpYMxd33HT+3E+1Eq4g2O+cKgg/nKIRHM8yPe28e2EEKgkVDb0KvIRfpDGxodupwr4AGh H98b+7k1e/1w12H2lE/STuwtu+yQBPCRT5GLh6KAZtgi3ulrDt1y/CFHdtRDo1SCSgqg05YLwkGK 5Sh555iJjVpKPSIZW1XdjVI8nZAdoUg2VSTZbrdCQ2QxhXSDWoqfgayySeFyjx8/ns1mgE9Q+EKC reIgZbBMc7/fgxojkVeMEc4ZgAGOVDUTH8mMph1vGf2UVO5VVSGH2Hw+P+SvoMUCzftlOgJCjO4Z IXc6Msin1Fj6SlkreRcxxtlshnBceS5kNaPqw41SniOrYZJNHNmYhjfKBVlidd3m87ko7ZiIhDGG lPVLbs/8EG5uboT/Ah7DXFppEtTQGmdSHogL1KEhctZaMkQUW8NKyxg4+RZEHlFG/ywNIWeCzdDH EWgRIPSXIYTQBEpiWStwJIYh/0J+LKAZhAh5jpkF0mDTQ/IFFAkKaqMkCOuyQxCkRI8REgY/dj13 abAfR2VTFCIoVzKzc21k7HQ6DUzi6Yb5175yzjXK+TxyC9joEDJrreG2dgn8WJ0qR8fMrigoIT1Z pLieslBGPcLvT6gd7Xmot2VRP2BanOxH6EQoe3Zvpuzie4l7HLLM00f+fcgiusN7ez4++OO3Z0x3 KHCMylv6muH073miesShKz8VwgEDhLGl5AoCuC0iyPDRxpgm4SC4eGgLMKq6m+k3fZmkk6KkviOB B0aCagOU+GXG100kagI1wUR6+vhqMZt776dFud/vr6+vJ65YzOah9ibmb1/oEriLUTYFtKqqXr9+ fUi9NsbsdjtoR977Izr0cEHw2aUSIdDvBVDx3j9//vx4P3QAmbj3LrQMPBCmrtd2CNPiXYurPspV ghGj6XuzcQ4/612BRZBUC9I4ZUaJMb5///75VyOkdbvddumh01PEjm+UdwsNjPLGmKurq2+++YbU XtWDdMg3hz9g0vvss8/kCqibWuBob3MuxmhNz0dBbhl5Id9zM8boM6bbg8ajoRF5E5xcezi0bF4Q Tt21SGykeCQ2kyCQApHhT53GGLqLTQULmqa5u7sTlkbp1UaVMD8mnHa/37eYenKeHTaXsvrjg/i4 CAiB2Peq8bDYhRC2u10IYR9adQG7rSiKuvFFUQDVKIoCOlBRFEj8RWnbtNmd0wdXtPgH93OEo3M5 3iK3CbWCV+zpL/HTthhjExrhGfiyUXVwsjbkJRlHvJcpymXc/5LG+O4PLIpl7YMjwug0geOgWDCY /mnr0GqWR3TEDxM4onJoFYykrusmrPXA2hS01urBJvUGBKRNxLfb7SaTYjjOTOfO/BzlM8QdDExy iAlxgN7SqES3oz0Q0U9+8pPVagV0fT6fb7dbgBC4hY+mgoCHe0geiEDXdSTIcGoQOBAOemJ5dy0W iF8Lbr+5uVksFsvl8gj10FNerVaX5xfS7fCCI48G9oP1hOLhVOFPoYoZ75e9IdomOIhNOaYxALaG Dhy0bHh62EJXs10Exz6fcuGP9on9A4FJO9tprEIjtXLv/8feu/1Ikhvno0Fm1r26p6fnqtFqJQ2s H1Yr2zAE+RwD52dD8IP94v/Y7340DNgPBixLslZerXdnZnt6quuaGXEevmRUJMnMquruGa2sDTQa VVlMJskkGR/jWtf11dWVfpVgs7jnPkJUlKXUTSog9W5AIVd4572TvahfYYdKhpSj+6Djj1j1hyFl Zsry7a+3aEkEoZjZ8T7WZ1Cp7CUcZHstJCK+FfZYJChWyTj7REcEvVIniZGsRI6MDzDQD8x7VeLq gl263q74F7ue/mSlsiKiGlZmLspyvV4PuXr+/Pl//eY3FBQf57NzMllaZrPZfD4fj8eFH6TjNhqN nG9Akp4AIAKREAygCtEJKYhzRaQM4fq1/ZLTNPe9QTGJV6T5I2vGEUwf4tnS8TnLqOwmomNeVZXn fc5kDDgOuD2s8VT08J7QxpFQ5iB4OnD70YDDbm1HPjFbrLVaj6bGuqV1hWkv940fyrJvLUsFK304 htR7kx1vb3HOIc7NoCh3u13h/GA0FqpHw+Fms4EyO/pDe1LmXe8qIuKq3lQ1ES2u362XK2IpnHdl kzOhLEpYjIFB9ttU6oKFbgKxpHocN5QFluVe3gmcwSHnezS2oGq3u1ksBmUpzJv1erNea2djsnBN qHDeCQ2KEp8L53eb7epm+e7t9WwyravqZrEYDYYoZsmZbaHeVTfvFmT0KZRb72wiR1Pb0pPb5o8q DNAb2TjgcKIzUrEWzmP9RiddhIcqH4n2T/ssNskrsqRlrCtGRKb9VuhS4SueCIUd4ISIlI8fP14u l5vVRkJQbR8USMrhiJxOlO12t2960A4oA0uFe++b7LEYH3wIa6Nn/XvEPXrsRpfZbM1qdkfJphZt o/aDbRsb/bTdWy0LtwivLMubmxur1rXjbwF4P/zCSy9CeFO9/vTZs6+++ur/fPfHu91uBrOv3W69 Xn/00Ueff/755eXleDw+OztDMljnnHcl1CUq1oNoB8GeIUfRyqEmFJF3795pd9jEz7GrHS2sTwQc KaVvJ50bx2hwsgdrCQKnBjkFwMHBFYWrWouRMYfSVulPPTp+W/6oPh9Hts5j+HqKD05+YmI4aQ98 2bVwUt+jkiICNt+BRQK46dgqJF3UMA61hwryzFwJke7vrpHP6RuHkj7iosilolsoVrSQROtXeZj3 vg4cKzIygCRSg3nDoAHLBwSGp5JUCUng+gkt0cNxem62xfQzPGggDcXSVn8He7uenhGRHZqXx48f H7NvsxkHWxVQETQLy+WyK3YIzNEwUJvNBr1LJSJ2UyUjkBgOh7AOsciYg5OtdUJJhwsNI2M+oh8s jjk/Pz/poIX5k5X3K3akMDEoZ0SvAVrYxFFNiVvOO/vrMBq1xZRH73a7clMVVExpUGxYdlIOhjN2 o9H0QqgUKp14R4UvmpQ/RDQYGLAT4jH4YDr63tEGDA/1iO8I+RizvJkcMJMQ3Y8Nqfd+uVw2phgN wtifmdJ3I8FMUhyHPxISZibX/OpM00RYQl6izW7dul3E+WDcjnoc11KJ+LqqyAsJRKP7PbEcDpi5 HJSu8HEUhX22PoJBhjeqOBW9ignpsasqIvrzH/3IOTeZTf/sz/4MB/fBYIBEcbPZTNcJBmo4Kn0z Q5rrdnI7E9gUQhdpG6Z0vYUi2vcjOVD7VGQkHN6xa68ubgbAeyK78CKZEznnfHtZqq3//h5mqtlJ 857JMDxu+75GXNOyUu1LofNIiCCYgXxSmisimUwlRKRnuKaAfmUhO1AJ00WUMUHXHPEhvq79vzXm wCjZlihkb8YwDIgLzyMJvZB9P7M92qP/VoEQaySZQnrFp70RT0QSJzcl1FaYMhi8MgjqiGhZSlU5 5ilzgzWrass8LApxsitk6Lke0WjA5BwPB0NmZvIiQoXf7epBOaxlvatFRDz5mutpMVjvamYuyVVV NRI3qGVQS7GriWqppS5r8b4mks2OiHzFvuKBuMv5Odjw0Jfe+yH5Ysfe+5H4spJInsoh520k9leb D3vCsXfZz8PhEE4i0+n0xYsXi8Xi7OxMxR5ZAhdUzATPkdxBPOIycBP0+PO+xFdmQkuriqtKpUqx AYTuWni6Ao5IyKGFKWFzKr2wZzyFVllLlDIEGtdq1THwIMzy3S57HHwCrJGcEpCEKkS6mLX6MGud 0Vu2MJea0diXVwcrbivEIXQv1b17t9tx8O+YTCanas1dO6PKh6GeoU/pjm0ry1KqerFYfP3115wY ISvBPFgzPUW/8hGZKdIeRYKNaGvoGQG1ouh5nAtkLwKCqFirKAqES2fmFy9ebHZbRASBiw1CgxRF MZ1OsUEAcETPTZuhYg+cgRS3pRES2/3dd/8kgJucyPei7565ofZT2fbb7VhCAGk97kSYIyJtUva6 bXD0v/uN58/ux4yGBOisF9NWddXT9dMB6pamWItavWjHM/01bVLU8vSDLd/Xi8Y+44gyOWUuh6Qq CE+M16eAHmVcSGYE8QPUHIPBAAJtEYFFvIigmATlnWICqHrruh4XxWq10qgS6hBHwXVFb7Em5BGt 1+vFYmGnmQ5mVjPIRpugF4fD4XQ6Bbt98eKFSv56AAdCaEAyAaPRHjMRS874BMEwTrELdkg46EYL J5Uu28wvlgBK1K8VBdJwRPbGMmRy6RISMLMN9qpDB6xQhXgkxzM4rQcy5tSYT6FVP3PXlmiv9Yo1 6bAODZY+//xzMk6REYcqXfA1wFSG7+XFxUVW1NxzJcu3esjoa06gewE0x8jMU/Lei2+yPkowPtB6 OGS8tDK3uzdVG5xKCO6L7E6hM0Pho5186qnhvUdiYqSydCEOrtZ5UAHJwUeOmZtcsmH/9cElzxbG CkmZX5Z5aBei68nSjYW6WYqSG1HCuiTAC5C23MmehTeAI4nNQMb+1JJLWOYBppgbhC4Wm4URegu3 o5Dlxu3eSHKwUtrewnrdjiEfkqzYcUu/poX7W0mUUQClZSg3N5hZHUrLsiirkmUsUirLp7Z/B1Ki qJaTwvEXXUC6K7U9jxaaPZQrnxuPx/sAX+2tSd+sBMyNu1ar1bt37xRhcDALsxyXmaXNLH3bZMF+ eP78OV6f5m/LEk75oMVicXV1hcbD7DT7suzKBRLSKJkKO4goCzhALnGLsyNZJSFKlQerpkNM5mfr +FOW5Xq9zlqtonka3wK6J1zXQAnK13tGLCUf7D+ygEONN5tiufmsb7wIiYttVeh+NueGdg0fYAkK HrEX/FxcXCAneFEUz549m81mt9tfTgIQp6ITe2PEGm9RA92Wc0Pyj88N/DSxdLxziPvLzDAqVk96 CWd3PeJk299jv32L1p5EVnyCV6Mne5y3sPbevXt3fX292TVf1fbTVtLVWu4QzelqzAJBZT91XTuh aNb0sAoxxuEdhVvMrKuSrusRt9bzov7kJEYS1C4QfbCeLxHHtWysv8vp/y5UEfXaSjjSFvY/8XYk RuoT1SkJENFiTcsPPTcaOsnBpmMbfwrg0DI66yDb2KOHsliv11zLcDgsisb7kU1sKBQr2xkZLSGe YWXCOlmC6wEbd0QY/d3c3EQVYvUB60NjDtHLZrO5ubm5ublRWQjwipqDiDF+z1Iqw0DgL4STokSm qK9Gg01VVfXFF1/8+te/XiwWiKKB/bZxv+/eYYjo4uKCg4OGmqccY6eiATD0SvZBkYRDB1nlAXZ7 v7q6evXqVfZNWXMWxGczNsX7/Ld8YrpmFWNAYKa7a2Vy06M9XRHYFK4hphxkTtoj1GB9C6i9LtSG 4+Li4quvvoqYWnl2dqZYcjQaPXjwgNvuyEfSSSxcOdNJQ2mn2od3lbRCKg5usaENjpkdGVBvnNCi SprDwR126oiaqSAnILD+l6uQTsKBBpsRGv/b3/72/OJBURSArtbhhYhEpInBekjL60NMwP6hQPyA wMJRSV/56Lyiu39uflqFQufumWWHKVOXtoxaRJrzX2htCjLSe/cFkiP+Qd4fPaXrlqjC/Vfi9HF3 nKX9t6eiHf0pOyvYqqV6N5t0qO2wHGxYWh0FwHHKTULBn2W7XRMxODWsFOtxPRwNnHPDYSkyJmIR B/9VZcYIDW6FjtG2ecwWrUy6qirgBiyQN2/eeO+n06kNMIPFe3V1peINlEcc58Vi4YPfZtdxEdwO rq3K9sqQhDLdCtIu6AF9sVj88z//889+9jMiWi6X4/EYPjJpzgrVOOuwOOcQx30vbtzbo2RWxG63 gyFaKqRJcapqvupdBQGG9342m6lZg0oRwKdTZZN+VQ0OxL2QBOBe5W5HugenxMzANKgBa8o5h5cL JXjqC0lGHIBgLcgdiFdgBd6p7EexV9RTO6rlZDJZrVZliIyLWUinJJrXmdeFObLXTwIoPucmZOeZ a1s5WAmKcyFeKhGF9XyLnZSZ1fYUi1CCJA3kiLkXHatk6Y77+C1IX3kKSLltiKDm3FCg+uBAz8Zs Rc9hy+USzrFEdHNzA38T59z19bWtn3Kj4YJ/E3WzN25CjITrQnTc6KWvOHeX2UrcsXDNMkicSCSh UCVT24rTfrC8MEIbWU55PLM8yFxRGwdT1uaiMX/Ovouu5/a051BTm0Ay2bNyVwOiidL/dDuAdGhM OpuJWZdsV5GorasNRATBMm4R54uQFImbOF+02+28b7TbWG5gBhx0GaduWXaXH4/Hq9XKHpZSjQNK rlarr7/++vr6GlpjfS5CC4qINXLsEtN67+fz+WKxmM/nkL2DA1m1CBmIo3dxCGwI17btdvurX/3q wYMHl5eXL168uLm5+frrr//kT/4kMw6hWpxMcASH4kkLa4DU1M1WgsBGDS25naFeWxjdqHIU59x8 PlcFhK5opMLRILD2hGzZEHZXHVhMWhciMUK/xkenzrb6smz7scNPp9MuwOrazr24+ObNm8ePH+NV qnkK5WDZ559/XoYQ9fP5XOcYqER0KbwPzIn5fK6s5XhY0F9yz/tP1GV0hbG6C92d3wMR015zL957 YvLe13jTzQtu8puj12VI7Xh8Jp6DdOQpRz+khtBVVSH3dONaVjPVDEihVikiQiEYidamCpEq5Kq1 71enkPfehmZRSuPo1e3I39imOehTmHlQ7OOQdpHdYuxFl96kTkAiLfDRW3kLKBjbxlRq1Xw9AnDY yi2bZGMmmXYw0zyK+esxY6XPOuYR90VoWooJQF3i+nQcbgc40gp7AccREo5OwFETkbATJ3VdYK/f rIqNd4NBQURF6Verm+12XZZDAA5N4DwaTfaHmcCej3w1Plh46OZjr3jvEX1c09y//urVw4cPX79+ /fbtW6jeFW24YI+JIxYHx/XsTo5ZNBwOkdvSAg7I8NXlRIzQFIIT3SjAjzabzWaz+eyzzwaDwa9+ 9av5fD6fz7McREyqPKAWyBgggo347kHCgJft1JKgoh1X3oWUBXC9URCmQ71cLjUACQcNsr4gfIYe B87ScCHWZnjvbeILffUuWPykjXfOwXVU8SKb8BaoTcUw/ePgQ8RY/brZbDA59bzdxIZogyHMK/gr TKfT5XKpv4pIM6yIF4mradj597QBHT8JItK3oglNdEOxwNmgyLu2P5rlIrLdbne7HTWP4OaqTnqH 6CuN/XkZ4ounk/h2pGK642vrKbndbq2lUlVVVPi6riHhqJmKoijbkswq5CHEV90mXDCy0Z+6Zrad VA1qC1es3lHMqNZUq3v2QYpml3qWmku2QN9UjPicbVIEEWxhGI1aoJPllykxs8uxySM7fsxd0RMp x1CPedzxLDD39IbrpPXcrs6Op9xKqnH0E488QUlwVIEu0hV+u92W5aYsy7IYIHAfVoqxEmsdS5j5 +NGGfxlOj5vNRtc+DLSx4ZchydFmsxnX9a9+9ataWLmIhGO6lYnWjWlaI4ToaYCNcXlxcSFBNaP8 CR+i/VCVuXAwWa1WX3311cOHD8uyfP369aeffirGiNUSuCMEFThp2Ojg6vXWJeFw7dOUlQdbH41I eEDGSfDy8lJ/0sI4lKoBigUcWgNMGuyLU4CI87/kLK56SBo7ENb9WW+ESQe8S1TJ1VWt/qRcZr1e n52dYRICDmLoyrLc7Tb2XiiYPvvsMwUVexxGBkwRkXPu7OzsVDnESRQJ0/qLKUkOU4sRTNnPFlLd e18kWFHVde3N5u7NgWA4GgKI+BCPnA65sJ5KJ2EX3cXssOsy42DWTkSVMNUVb5voh957NyxFJAIc bASzVVWl2SO523NYyTIDu8HhdAIprv6EXvjj7H5SQYhkLD8k+rznvt1yAm3RQR7ZXBBKK0lqk2hn 7+pjf98j180sr5Wcjy51n+DvzpW7oUD8KrMDHhVoxGCudUu2wa3evX+ZTZYQ1cMLORZxFYLl7HY7 X/vdZrsb7Nbr9aAcDodD5zZl2bI6soJoXb+Wn/VsJkjhBKblnLu5uSHDzjUoogvxKHmZN7YCAAAg AElEQVS9ls2GS0fEZem324qIvSfmqjE9cYI/IioKPxgU0+mYEzm/bkpR+Cwf8rxrGRyR7RYhRppi pZtv3rzBiblr/+Tg7lGFgO7o2s3NDeQHSCAXkEpmwmBA0soVbehPtgtqxGA3pQidAPOpdkZv1I5D BGIPaVqzxiSNpAgqZEqHIuI1mntWq0VVcAJi5i6v41T5BaML/DSdTq+urprX0a4Bhj5FUZyfn//w hz9EUhVbYQnZl82skW3B/ZIO1kmPU/RgVRKpSCP6KqdLONJWYcZAk4LKgc+ad9m4xe73Ait11EmA NARZ/cKpJKcAqWi1dP2qcBgztSgKtNJxibQIqSWHCg9Park+1+4gLvjCQFCplqpkNAsuF+a4/yn2 Uloq+mwZP7X5XwIvDh83jwEc1M0Xb4E5LOCwdepnHclUNtMf2/TUn2wzsrMuGtJoEPqHi8ybi4rZ Cqk9CF1d+GAkRsjhnFutVr4cwH+Eg5cKBVRNiV6JgyFhj3uIkg8OkGVZrlYru05TJfXvfve7s7Mz ZiYq7F4RvTj9Oh6PHz9+HLmiRIWVrTLzcrl89+7daDTCCRtQwwU9vr2lMKlo1QT77du3iEr89u3b d+/enZ+fZ/dn9aSwJzFOoolHd6lNN7yRLYbYlwmDL0GRkZ70rGgEBM2CLamAw17Mbp56O7WZXQ9p O63gOe21HhHX6/WbN2+66onETlVVIbZHFRLh7oNwMNsWDofD1WqlX8/Pz6+urnTPIUg4fAi/Qe/H ZqKHTkUedoKinx/MV6Usy+1qDbNkIvrud78r0sQxDBtkozabTCaU86TAbIAt+vGU7pVAqbpcmwKW v+WiDx18UIQ86roW7AJlJslhNE/SK5bUH1ivQNppr3AwHuRgiqWMJ4havEsSVB5PaXxJHSsRgcSC EtkG/jshiVAITCx7R7XRs/UUMJMnEm9EzJgSDpqvMAAOLWNdbbVaDqGoWlXd00Ejy+DTNkubouvZ W1r1n9KAW88ZvZ96AdkRexcTOS8F1SxFxfWudo6Z612122zLslytl9iEmSvvETeTfCvoKdf1Lupa /vwQfkJUb2hwsHzA/nG7cpT1eo0wj9vtdjp/YE3TbKwFPSVfXl7OZjNrcmiboSxfw1FUVfXmzRsY osKeA84O6RuJsI5zDq4uMD4Fk0OPIsilKdNgNKocXdl/FDQiAgEUTFs0rrmNxQmH3q79U5/FwZeV jegXxitwY4lYOLVhTVQnh3S7ZNTKWiA73/S14rSGi7Bi0Z4ul0s9J7fT47V753g0GkCshf9VtR0O 4b7KzFVZ+u12DQGYZk4BWfz0y1/+Mu1gaYOduRAE7L1SNNVUJpEdR51bPabsuquC3x+vaDieILTY 7Xa/+93vXr16JcE/RXXtMNiQvYgFMTRjW8J7NBftJzaJZ/WKfpYQRFx7p2Uq2U8GgU6R96TFrNYT /3s0ZVmv/Qh4cVDBZvlQIyUK0oJjRiCeZpmbmndX1zWM+7I1iIgY19bQstiSK6V+911KWKPtdT/g 6Hoom16k1aZieVu4D8ec+FP06K5H2BcdxSBJj9dR5V0NivBKOpgndST8RkR9Xio6M1OymVacI+89 VpNjhieF9568w7lwPB6r1JrarwmHb4RpIGOUkGHb4QOSdkqIDapMFwdQ3eeXy6VG3BkOhxcXF1Dz W6dHbQ/k/0+fPqXwmtJjBrCLbj7OucVi8W//9m9g3sPh8JNPPukcamM2wczX19fQDQFt4Csl2zsH jTCHaAUa2kRxEuBXGnnCorfRaIR7J5OJBBnMbDZTzpLeWxTFw4cPo/1QCyDQqnXZU92KNz4gFh7p sGuUUv2pZ9Ai0gqtNFq7qTgmmy2WmQuiyWQCfgd5PD5oFBYJuUsjzU7USMRQidhxDC+6goHcI0lQ Uma/nkQ6w+g9Aw6sge12+9VXX71580Y6jIRJ8VP4+j4aQ4nwX4mNUDE6MUQlo/gZ+9vd/rNq+NIz ASViNw62YBGnhJFaeqaJ2IC+St1SsxCTmQ8y8iy5zF1M+8HpXs8izlpsiFjBRtesFZHDnrYqmpIm dQj+JHCwlHf2cGJqn8IjgCKJqihq7e0AxzEU4Yn9dW41L2ptz3N72mp/Seu5ZR87JBytjavrbrgM sAC+i4hj77gmqbmmuip2W+ecq3fVYDCouQrBEhAbowkLgQGEMgJKGZxbsjMhzppEQuSEaiEuSsfM o/GAiJDkqKqqmnfkmByztCJYU4dj/+XlZT/zU8CBr5ixiAR1eXmJqFxd9yovxKbBIZ0bESHYeY+k gdqrQ0KSdzGmISKSviqMp3MOph72TAgxQ2SPQm0zTE2YQtY0siwh4QBfr6qqLIcBbzQFIgMR7bsK XSCE6OE1/cMYeejYpwDNHJm0T3U0VhjBzD0h6kGffvrp1dWVxVuUAo6ekKV3J7uvuRb27/TziTaC fgUKH+2sfDvCS1JVX0oSIhJBxFcULis87KFj2q8VRiNWVRXRXlZhm33kc5nZmuMVQW6h/yPPLvuh Z1VgIzjYNWlT1Nm08JEXm5+q9Dhoh6Wbt4k4Y7Fx5FGjl4O3Wsv5SB55wBENTkxtMU6u2p7W3glV 9JBteVfzoq/cHRmvpyfRnLE1H9nIrt+oW6XS3Jj70TkHh3lpJ0ICKbyuQni9KmQRCoWbg7sEwCEh YsRJLyuasal6noLIM3uu0JLeRK7sYVccbBUliJ8RRhPZYeBXmapFQMPhcLFYvH37drPZoAFWxQMb uJ6e2h1GzUEUbQQpRT4Ox2g0UteeaKzgyutDbodoWJTvcrAX0Rqi3LPK8nVsS5PCzcppFHzAVCJN 2tJDdltOtTa4kibsjUibZGvQnR/mMuruq7MxmOXuzVqXy2UdUtA3lWg7gOxuBzh6eEkqaU+vSHCa ijoWkSYR6HqcC+kA3odiSA8ZdiOz7bA94kaLefImfuRWoot5D2gMo6Icnksr0ZkdyUWxMqPDtFZY VdWQRtmpnBU89rTffra7MB09DlGdEcuxP7kMn7LS/k5DvLquC8nEw+in/lFIoYCFHUREEnsVSRud dFXc86AjW36PlHat9d6NL3lqa3KXJ55ayYGXmwMcceHkVjUbdwjGIyQOSZrFkXhhR06kFqmZK+bm WL/dbYjINceGvbwBaMMGsTi+a6kM2BZQgSIkE5QgEjIRC3Vfxak9ela0XVjAARECJDQgl3i3SkhQ hSDfmDlIRBfJD/oJkoPUAKWHhoHUesP+iry16V0WjmC3VMuVqBhkqN7vTUbsT1ZeYhuMhYOniMsq hTPEQcGtAcfwLqyXw54/ihRFsV5vWtKLqsaYQynjvYfSDYo5DhFUD0IF7/3NzY1KcVBJCfWYOgWp Pu+ozh1BkhhnZFcL5qIP7tTqjmzvtZ4L2qWoHsWMaQTcOxIse+GuWXUH5L7HoesnbKldy/4k498U PTSY1DmY9ahPFIKRT+czzDY7TXVyV7l0zMf0JUUhR96LD5HKIK6wSiFFLOFIG9Dg91PCxpsaOhsc seGUJTvqzIzaN8ESLc69AI7b3RsNphgjknC1OXjUdcvH+JjHHdmk41veN6q9Eo5Dj+5DnjA1cEFp Utf19fV1URQKOKQ779JxTyfq8M5Q+QEOu6vVipnhL4PZqIAAOGA6ncLbZb1ew2EhfajVyEABXYZM SbongJPpI6I2q+QD/31wDDyGvdk2MLMmPDs4gNi1EP09tZbwwTUjey+b0Mw6mGR2VP3Abd8ZrcGK N3S4vLHnOJWskMaH5ClW2gFFDxlgpMFLQLvdDuYyqAr7P7J1ogAwlsJffRYFN2D4v3z55ZeIlIq3 2QAOO3YULH7pVlFB70IqKoT7Zbr7cIjErG+rNsFo7fmbiMqyVCnZPTYSOY2C31rnFCQi3ziFy3tS UWFYgGRTQE1tnNe17XbBAmb2ReG9h3v6eDxG4H3vfVXXgHTqGQ+jY+ga9UG3EDLdGnBElVAbcOzr yVQo0ecse741t9ab2ipkorDLpICDwvxxlImb0nWlo0dEhyUiPY2/H4BiF3JcZ/Ky7vjc7O33AE2O ARy52w/rEKuaShZfkXiudrvNmsjviJzzRCRBwtFTT9psbpdVAKGbJwcPCDYulEiJfHV1VZpkipFQ HR9gfRmpCSKyahc82i6BFGpoX2C2qQvBB58LzeLRDx2sblflDcoyQiCQTjGJ9tfW1v9QrRkm8Hb0 VDyQDk6kurKgpGvb9N7XuwYlWD+PlKB/UQOOMmR4UdCmAVFwhO5qZNRNCMC0Wg18QkHVru8UaqDZ bPbll19q4xXQNG6xrRYfWida4B4RiQ/JEqmDXem88cGQCqiCTRwbCoxWgjSPTowS0U/X19c3NzdV iOQdrfY77pWnEuSNOp9IsFROEC04E/MY5L1HiFRfFEQ0GAyGw+FoNBqNRuSc9348GOhss1uAb+eU P1L4qXRrpng8O+mZqWJsJu4F90SkJ0UrKbX+OBT8DigBHCdSS6HGkZqm6573PG9VXdIPON5TSyzi uffK70Ii4tx+WCBgKEucTxwRkSuinTbSk9radDviZKJbNm9tGvSipi5z47E9zVveqYsdBKaCHdg+ S7UMej6s61ojD4kxqkD5SFyNvR3wQtPYchK7IqJIhlGGfAs4mlPYjhQNRA/NVqK/Qqrd9WhVPXz+ +ecabJTahho251m28aqM1kiseq8LfqPeewn2ntTetLswH8xftKQefTUlr2rQoub5DvcW+yDrRBO1 ZzAYnJ2dPXz4cLfbIb5LHnA0O51zKhdK53Rzj2Za8U7vujv4iHC0WppkrRR17+6vkxsFTW/bpJc1 Oiai0helJ6l265uFp7oonaeahRG+Gk6SjoRI/R0OC1TvSOj73qa6WcPNSo6SOGc1LFj2zjkmx+SK suRmwAejyfjhw4e+LMfjseXV4p33flCUTqhwXoSlZoK1opATckSDohwUZUar3Xp2c0vTZBaH/0Qk 5AUuDORYNf2oQUTEEczcWBLTQmPwKsF5QMKVWGGc/crMdjYc8/46cae0fsLWbBewPdxLOxRHxigg 96z41zZMaVd4WlVa4Ej4FT1L+agkmhQtA78hhplkBAr7hThCRUcB1SlJcPpxHGaDSMqMj+nacSqV DEB0ziOzBf687P8ahbyrhSpyjlxNrhJibmYpIgd6EnKuQK+dc2EutzbbgCI8ZjjnJXmYX3hHiFxe i7BIXRSDzWa1WFwPBoPpoInmWe8qJyQ14z+kGqoTWS6Xi9WSCl8kgIODRwm+bjYbTbpBAVWrRyUl x327w2MKqeI/VXakzwXviPQF+NWGHs8+0RYGwaVTY7R3wRSc46+vr1+8eKFtgEOsAp3+ZhdFYcOw WkcVOKN23Z7vAovW03/q62kYsBobEkeb3XbmGjeoYlC+u1nUwjBKcsU+aEwxKItBSd6Vw8Gursqy dN6LIyYhDW2OfB/OudFodHZ2RjkMAUWXDzabRVHUIU+Mjt1BBNBPOu4UTFTIwAs75xSdZN+HnVX3 eLKBNlFy8fzrur5zwpbDJD0GMYZRpe8umnm28UVRqDyDAryF0MhDvxZqcs65srCLLW5DNyHwl94S +UkeaXifPa32MNSofM9dt54kaZMMdomFJbpS7BGTDPgw7+V2gCPzuOwtJ/X3SCGBdGew66rhyJpP bWf2J7mXZ9yNDr4LhZsiTbpEMXFxQqHW6sa+rTuD/mDXePrZt93mEcFzOp0uFouyLMFlFTco/4Nc fTAY7ANN5khPoXVdI1komB/O3MAuuGJ3KrsiKPjtW/VBVVVXV1eUk0NcX19HFpdqDEFBDUGJ0iTb bOtXooCDcrwGLFmTv++FzaG2rAhBG8AhvRwU1niJ9hEABHCKPJWxYtizYhsyvDVL3vunT58Oh0P4 JKfqM3RBRyYiNe+DeCYa7QZwiAhS8gwGg9ls5hNPEOccKrJSvslkstvt0KsuT6cjyYcsNdnZYIUf uKKjkIVpJ8nzM6nJG9/6GAgvbt7haOKDnUSzPHol9indZetLMUdXGS3Wbz9blmUxGpJ3w/FoNBlj AUwmk6IonPfj8diXe9GuPSNa8y776LR+tEEjfUXRvRoE3Tocx90BbA/vg4PogsPpLX5owm4bicq+ pBGGkGXVLsPrezBN+nXfkTb3leADaRDJXtUSV9Xxhg8JJWIWfhAi9Nd34Gm9w3ISgjy18lOfDnHa qYafWiOFGXIPSmQIXhAVxtvLLELaOdpvKnZ32t+gShYW5ylWvqQ6+Eh34I18HhcfP37siM7m85vl EthCxRUWo3BQ53dxLMuE7Ep3zm02G8VGMNK0CEN1PbY2BRx4+qtXr7IPRTRPmCvac7my9p74UhZP +GD+qTy1R59ixzOqSgeK2uKQ6LQGR19vQoGpHFSrgtkA7jqSrzEz/Io5eJTYXxX/UcBMu93Ovs3N ZvP8+fPz83PASjaWJVkEE7UKJgddXgt7sxoIggAqUxbViO1M1aPRqBgMfLBbBuY4JpZIlnywf9T+ wHQU1zmJ4jAYDLpAny0pp5t5VyFmflkMifZwBDbkFPi3XUjHV/4hyb6srHYMBfBaAUi997Db0J+K oqCAXbxvziSoJOKmER/Vp+sJjI01vpbHcop2GSs76QITyleOKaOX0mJ0BFc++IKz9Ujbo0pEopNK VOCD0R1xxvHV2mHp+jV75aQWRvPQfr73np603pnZ5XZdEeHg0G7JTAaoFg/vb81TzEqXXLAiC2qj s7ge68/Pz91gXFXVxnDZ7Xa7Xq/hJolNWDNLZ5mf3Wy98flUBNA9WkTtloPJQebtAy0WC92O7IC8 fftWc9hWVQWtjS0DwX7UVGtLAG9N+37BmA9yNG+yxugV+wjl5ZZta0/n8/nV1ZU1ryGzhfafw7Ok 3RGR9XptjS2URwNwTKdTa++iNVRV9eLFC+ScowA4RAT/lf1F5jgp/e3f/u3nn3/+u9/9zsaSKDWa CjRJZDLkpiN7ZJ/vQtFTJBiBpk1KMRSuoG+2npP2HWSCZebxSMbjMYXn1nX97t077/1oNOpxi+2i rm3xVNJ3fHDj0zNQ9ldvIpKNRiMIt8bjMSLz2AOTttV+rqpKY5Xqi7BPdGbcfIiZU5skkBZVZFuY vS4SYnG22UmW07TK3Kv0PnpuylMbBtKW3KhIo6uGO5MPgp8DDf69k4Vxt0YG2WGP6rx32HFabSLR 3tWc7pzzbYvRtnceAId9EHYzK030KvdVKaNzjl3sskft0EdYtvYWNOD8/HxTU1mWq/UaTHS9XuOM u1qtNGQ4eFijA83xfnAXVZdYVqqhP3XrsLt0aVOCBTMCCiwAlqfZ3Uz5Mfw2rZhBy6h23vuMRByS fzw9EkKo8Ur6OPshsjJRVY4mg1XxvJXTs8mZEr0OSCZu5xlLAdxozdo2QEYbcEUFGCrWYuaLiwtr ZGrbPx6PERji/Pycey1F4ExLRmXsvd+n1IIZh+12RBE+3Ww2xAjB28jK7qJS0SZGj4N4I1KDdZH2 SnmePzHQJ9oAPVHTBtfY9ex2OyQTKps8ZL+fjfv4M5YdhOgnTdlQluVoNIJMazKZRGvD1mMpGtXg J7xvof53IfEjCA516RuJeIbrUDSklC1m4UgKOLLtbF/vf+ahByU19xzsPhj7/4bgjB66NeboQWz9 M+34Z5Bh/ydJNDE/Xdsvo65rQT3iqqpyZVHXtS8KdX/LAY642fBwwd47HIz0ulV6usRnntpCCDyu ClGLhsOhjeaJ0Nrb7VZDKRDRarWaTCY9Wz2YGXZRZ8JPwSzMtV3Eo30GeV6AVyDDZubRaAR9fQM7 2nYStgYc1vViBB0iUrGEcn34iFo/Uqt9sONWhaBYZVnCPlTdRFVFwsFEQ+OJ2X1Vy0TczZ6ZNbxs 11B3kRWQpH1XHDMcDikkiqMATwF08MoAKzUmAhlDFpv4PkJ4NvO8Jlh1IZh4SxCkgnQ6dD7GoNQh LC7dWT6sYpUIJJ60vBUR29mcsttI5h+R3oWpwI27Ke12O812470H2DqV7AnsFrffWn2TvREyrQcP HkzmcwgkVZumMAVSjSzGt6s9m5lFf8IHSXxBD1KeYYjYStL/lBOfuI4K04uZIt2N7cIcx/TlW+qi U8fq+Bl1i8ojG47Tbk+gMPbxurE9FyKi3Y6IxMRACoDDLrp0s2q8Db33u2pbFEUTSM13GJX3Emwg 6uT8zcybzWZ1s1wsFsWg1GwjXQPOxtSUQgAGxRxm4TYiEFuJYhR7ntlsNsjXChoOh2JOXCo+mc1m qA1JWBRpaV+urq6knWGqCnEzyThloKlWEiMis9kM17P8m9paKm7bhFKCeyz3UXikZSDIAZoBXrn1 MT6ybsSD7Cuo61rq2sqzKSwlTcCr0ThtZzmYygK7RA+KBhnFXLDq2BedTCYR3uxnb8zMJj/q3cUb Ou56JugXKEVSIzKSQ8hFuhZbJNKPDvTe+/F4DMlhVVXkGhBaVdXbt2+pLcPs6QudqCx4H6QvMSul OD8/n0wmFxcXw+nUez8cj87OzrxJ/TCeTsfjcS0NItYZwcxWS5ruHdQ+VWASqzLFxpzIBlzxkoca aXhpWyx6YvQhrS17/SSyldylwj9mLHLHcbPUVeAOrctUeFJ5rmvlXjrnvfcOGofaOeeo9jjBK2qP An8RUQo4imKgLLzZjqBV90X/wQ/P0uOEbm51XVMuBhSZvR37wHK5HE7GxyS+tslvD5JNFaljFZlH wLAgOpRiK6OQeIWIwK21Zu/99fV1yk2U6/uQAwWMtmpS6O3RDBTNujG6NoFVWeEKJYBD5RkU5gCG /fr6GpV472G8CSdBRLPQWFNHjmHau4j9IygIOhuhQ70LUhki2mw2s9nMertwsPjBjdYojYO+GJop hRoiMhqNttstBDb77R4WN/rVDqhlye1NtrlyL6tan47hvrm5ySIeK7fIvgbM11QOphRdidgecK61 39aqIiXfN5/0DaY/FUUxn8/Pzs7m83kBG47REJFbFcuXZTkej3d1E6hY78UQiVGa2DGxS6sKMjCL ALBFAqZE6hgtY7/WdY2joDSo41gM8b7Rxn0xM31Bf8zI438l6QtlY/YuQUrnWLiqy7KUqmbjGChN dB9L2LKs4nLr3MCHLM0aC1yqiDnFgmcRdo6Cty2EyrWIXF9fT88fXl9f2/IuWFqIiRYKoUXWmjK7 2WbPFZmx6hD+u2AXooYj8TJxDsGssEe9efPmu9/9rv6ImMhRay2bZBMtA5wuyhKnOhGlaMtyzsES kwyIsfFYsyMDur6+hmMgxhbeNN57K9exlWS5j0VgElQNVRKpXb8CcFRVVVXb4XBom+ZNhLTVaqWu hbaGrKOsllEpEYU3uN1u9fW1xnE4HEbSKqChrF+liNT13gjuvtgwHtoDNY6nwWCg1hiWoitZhmcZ 6mAwgFQDnPUPiCt4Y7plrzvnptPpZDKZz+fj8ViKInJ/9YZ4x3vRWchbiA3OBc1LetZnZhzayOBi MXo3CQkqs+PJIVhFk28iwBWC42obwdj/B2Ub6U/J1/SGrpq+pd8bfTiRUtuG47QHkaRGlAAcWFQa 2ck5u/U5ojjqnHMtj22XcyKtsSObuH94Yipu1PJ44ng8XiwW18tNWZa7oKTXpxDRbDarhQeDwaNH j7z349l0u93ycSaNHIwkIllyRBio0FOyQm5sPjCh67pdT0TI+aLXwcLU09XeUgxK3my1DJl9j4IR ZVmW5+fnWcCko1qGBF5W6J7K0dMaYFaJ+hWZuRC+wgrsoxqy8EUbLyJIeheVx684Rnq4/HRgRGzd m81ms9mgSS6Y/eIn8EfI5FTWpbwAJX/xi19onWAEy+WyNY42Kw+mrCYr0ZbpKDAz35dvOhGFkZXj rAWPodtpedKZgUEA54Nn7B86IdrKeDxGqhRB2LckCbJPTYSCSkXnViRZVYBPRryErzbYlz0z2duH w6FWqJISERHELWgAR6w64eBwS8fxkm8O4PhWtnELukfZUlf90ff9/1Or8kJh6yATMdOJkIj3A2bm 3a6ua9ltvfdFWXrvi6KMDgnhM1Qn3jmHyLxSV+RcUZYk0sg/2gFmKLE7iUA5FuxgMHj16tVOPDPX zBC2K0LCgVjdioqiGI1GdV3XdapVYWrSolbMFREPBoVz4pwUhQuq11rNOeydVcjHgc0BaTKVbR/0 UIV9q+45dhuPNCytFxQ6BcBhBQD6tSc2efosaktNtP2pHB0P0vwb2kIFHDjokgqqez37dEet6xrm hs65rMZkPB6Px2MbaiVqvP7kg8evbTMFk5f0dvt1MBh88skn//RP/2Rxz3g8LqPWa3QvtSjWUdAy usuTvx+oQckIHgy3cgxlYWCXaKuffLDbWK1W4IgRXvbeU80KlXIBhr8RpLPZGnN5YypFbc1uWZbA uY20g2ursUohHfZWi+4VfKBAJJCI2hYOgq0DnAQ1Sjhl7oUZLVByWz70rYTjW0ppPytkP+tuVwlm pjN+fD7wXmZ2DqZ8JPsw8LXFG1a7TVpdMDIognsLjDjYHZYEayJQImLm4XA4Hk/W67UbjKltFQiu OZlMmFl5Mw6iKuPUajnY3imr88EqAlpySNDReJ/wDt00FHAo57ZeIV2d4hAUHE2yfqree8UuZen5 kEkEEAYHSwsbl8gWQyOJ6OOPP/7Xf/1X3Y6sIIFzobfIaDe0X4pR1JPWRtoUkSa8PVHaEgrYEVNi u91eXV2h15GrsHbcfrDNs59teYs2KAh1sm9Bi/3iF79QXgAqiqL1/pxzOM1nw4SphCMddw4h0izF /NiUTysnot1uh+e6YBYQSQKzd/XQ8YAjO7JwQ9FliQYsFgsvNBgMumBLM0rfPBalgkrv/Ww2s0s3 O33rut5W1Xq9xkaDgD/oljde3emDoqQhNlIetZ2PVNpBQb4V4VrMKxGxNhwq4WBDkmY/j7rfOzjt I2D6c+/N39IfOPVD1TsJVMzc1tooWEE5FiIm55hr8q6mmgpPIuxRnvXE71rO7SlfxIAAACAASURB VIHT1ywyCM/xsPNg32zddg+3WhV7mLTLbbvd1jsuQ1xzMhL4ZoUawKGWsLavLjhSSgiqa4bB+2Da qVd6FiyYJe7CsQf/09RlFIw/qqpaLBYaJsS64LrgcDEYDJwjhWj4NfKwi1xYe0KUUtjt9RbtvnMO 3qQicnNzgwExXkik488hOBikyEAbkECAF+uGKYe4oQJQ7IdIDU9tQ0bUBiACJx3V5tgeUUCiyiYw pD4om/BedPv1JsSI1pbVBjTR2hVM4c4UcNge7sVEZhuvOiK3w+ZWAUQU50RvUS6loDgd1hSZRo+z 5wlqz8t+h5cU+jnnKjA2x2RypO12u8lw5L2vcjD5duKTD0AqGtUJbdeYXQkgDi8GHJ7UdDyc0nQr tLfYe/E5FbulEo5GyuI9lopzToSxFPcxSQ3gaEzqzL7GJhFa5wgcPVbfAo4/QupbuQIzo/uZBDpF RUN08N5+s4HUHoEQGldMZZmRqIOZvRNEDNMDgATrvOxhICJue1Ww4yhBRhfgUJt6eyzUha/NY+bz 8/PHjx8/ffqUwnYROYtmmwRMYNUcuK4pUaK7lNUBVUTbjm9HjNijBMMdyQAsbd7FxYWCpK7jK0RB mohKkZZyZUo4l+K56Lk61LpFexNTiswLzb5c1UgoCIggnfaOg0In+wq0YWpK4kKARwU0SFWhEEcb UFXVarVywUUZ18V4FTSP116ljKdrZqCw7VJ2u9cC6CQOytkK0ydG592e9lQmIog7IgRZWkna8agX 4HBFUUB9milsTE+AB/vb8GFIkQGMf4H/yCB3CZaw3I4fj4WYSrP0g0t0w5QgDJdYaVgoqS4q+uKa iwaRNPhG0KSagg2HAg5O9Cl5+H/8kIW790v9W/rjoHTmKNg9FXBkp43O82a5GbuoADicc86xkKOQ QKhlKOo0EYF3TkiYnfc1zuvY+hzrGTfbBsty0gJVVUl79xuPxzh87+oKygUEjEIlg8HABi2tTRZG bAVFUTx69KgoisvLSygXNBhUdtyYeTabWcswZc9dthRaAHWOx+O0crsvKVN3IvBtsUCETLYR5DDz HeE3bOVWC0PB6C1yVFHKgo/pdApVl5bZ7Xbn5+fwHlVxCH5NJ6o34QzsU/bSgXCvdtmmSlVSXYkP uqRGDGHCk0iwHo2eKCEjG7DIX/7lX/7TP/0TEe12O+1Xo4+hgLPSKXj8qV03fQ1dh4tw8lZ4FXGp dOzquu7X1WWvcHBblXZkGC2mGXHTOrtATGrmY2UhPQ3DSuvqwockb8w1bDBZSw1TNx4ozd6BA5Yp 2TUZFB+ggE6DtDH2dft2/GMJqau5ruGOtZ8ejRq9ZcPBhqgDZ9yCbDV3QRv31Z5v6VS648jfy4tL sbhecRpCCj5cAqsFBNnDitvP8wi+q/AgXDOx8/HdFxySX/S30M5tiN8jvqvURCQKJb33lbT2OuVt erbG1+12e3Fx8Vd/9Vfe++vr68VicXV11d8qDo6U2ZZ07b0q0oecAEGNsXvA+QXBUoui0LMi2Kfy ciucQBeePn366aef/uAHP6BDAnJmvry8VBE+xB5dTY2abaUdKuFI4VHXjVEz7IftdqsQzUqkFJlN p9MusQ0lAhg2gDuyj0nbhn3+N7/5TdqFUsUdsD2O8mL0U9ecjqY7WtbF7VI6HuKk7VFTZ0t6Bdw3 ekQPgGBmcuy9r6lGjhV9YWkjm1NLOJennf3wHAhqFCytSG8Cju69HwwGW+bJZMJcq/ihcWdFs43d e48cSCUNFDxgo8b0GAZRG4NHG7RI46USJB9i5R/6OQte90PRM0yxLG1/8UjR9Lf0TaC7rK8PuTZ1 3nrIIcqirutggA+ZB1TbGdEgGVhPRMxbtzfv8ERUS0ti3c/2sB8OBoPpdIoUYgi7TiFZkjdxHSwH onq/bJXZR3iFg6coEt/P5/Nf/OIX2Z0zIiRR08NhzxlPH6SunmTYLYfAVhyijBPFeZi32604wl8x KG9WS1d4ceQKPxgNd3X18NHl1dWVOKqFWVq9LssBCm9224ePLq+vr3d1NRgNi8LbbLpafy0t8bw4 mp3NXeE3u+2urojIFb4WJnHi6Ga1dM6tNmtXNN1HJfZ2S/iK/3Bv2W63SPyOrTWkl6hFBBKIyWQC KKZvxAX7nvF4bOGI9344HEDWolQnUUpB4H11Xf/3f/93ajC7T57y4MGD+Xxu9TpaV8RXdNSi0yp1 UBr9NK1WpVhdiqWee6PrUUvs8tO43bZAF1+JzhbX19dXV1dlWUb21cwMRhrtWWlLKFfs1hTXE07/ VrozGo2gQ8nKTtW1HVZDg9HQhQitzUGqqbGpjYGnQuVRY/QQ0BX/3ypTQArL7EyrqkpMOtmu4Yp0 KHxPrtSUteH4lv63Uzo5QSIaaO4eVCqWOCB0T9Bpkvc+TGtYMrYqsZ/VA9y3nMWEiGrXnNrVaLGr JRoGdDwen52dLRYLq4i2B4Cevd2KNMgcjq0Xw+XlJRHBnJOSkNtpheBk6iGvgKOnGd7Ex7SN1w/q aZLemHYHYhIoneHuERVWZAN2fnV1NZlMEB5e64G4fTgcWj+RiBDdC5oXNd6ERgzjgHslWEDafTLd gfWcjyilFBKGWIiA+bXZbIIJbQsx6LHNusLiRQzHo8jLt+td4C2IyHq9XiwWOPHuG2mLwjgWn60C W4yKXceOmcm3mqsRyrKkKq6IT+Czgi/ADnzWhvbMlQgMcbfyUntxjLDLdoqIttstTKCjk4cPhjn7 870QEY1GI0T1p/tDGEeSPg4KC0UbdkxwfGHm0Wi0XC5HMAXabGAsTSr1xV7mnQu2QpqLMpJg2beg QCFdEtnW6uJhY43BbTvQY4QMtx7nHt7g5IM6HO1bklgvfUv/+6gRdXgnIq7wEjLoRvtkdn7WIcmF 2c0awBHdkur1KWhnRqPRaDS6uLhAvuiKWFE8lqFrp50jjS4leXt5VSvYn169emXVDT3bL27cbDbI nK5SWPD+Mhd5PZJVe+NDS4ZVdaEcWycHbxc8DtagaPwPfvCD8/PzLu52fX397Nkz2wyu+dWrV6iq 69EAGdPpFFFKFXCocgfjYNlcv3DIor3RaGRr8yaLiub+VUW21qBQ1Zrr2gHkdvKUbPQKSA2QUx3J dyhsYrvdrjUW/Y7OUcdSgq0AQqbb6+reg04qLuFAtukS5PkwVKbTIUK6Po/ZsntWAt7ZYrHAIlcY URSFE7YM0gWbc+Z9JOD3IZM/slor7ciuVRg3DZhvbm7G04l6oABTSzMjm0mMzSh6tH3XUcgNUCoP a8kVgymGXtlut8il0kg7jA2Hjfao89ji14MDklKKn0QOH0/vneInnpok7O4P7Q1B9ocOepp58s1T jokITOq8I2YuvNtut2UxwFLTk33PCSpabiqDxOENroxgLb7tzY5TxGw2gy25D461lHMuIyNpOMj2 OORZRbWw28ChX6FASr7tIaK1lWU5n8/LEKs0vcv+Vw2CWkTiv/XIjSrXatFgDS+2Xq9/+9vfwhKi yiVh143LKg6Uj+CiBTSpNIWIptPpu3fvdNCcc7PZDDszTrn21GqnQfoWlN1kB0rLR+2JRAC4N2u8 SERQFeHKl19+2RUuy4VgcUBR2uzRaNQc3yeTiQuBzKkt3jiVvInJqhejSeaD3Yr2R58F0x42RpcS fFyzHMsb8xnftkmMYL5SakwAJGF9W7QBTbCamnebLe3qwagsWYbkxXkvhL8a4fkcpD5ERIUQO3qv VqMxD8gJftMphZWjyM85V1XVmnfOOaoaEWsjZ6vrZqyE4JPFIUGu2LG1clgkdDCT2zlHQfDr1VdZ BM7GRORJVITQSDjqbU0kJEIsVGlJFCGigkmEnBCk3U6IWYhvF3ua3EkOLKcQtn4xH6I3JBTn9lTy VKipin2nztn3nu77fKrk/xjqgnR/cCjEhzkTNbzfpU1uNz+OvssLSVU7ct77shLnnIetgHeO2Tnn RZwjT+IK15quIpzMBxe05FIzF96J+LJ0UAMzI9gniSDu2GQ0Gg0Go8Hg+uurYVFuHHshdiTMwuzC 6oDfiiMqXHBM3R0IzAjIgm3/iy++wFeLQnru1bO+qlyz4TdSApOD7kbP99RtEkBtAxFOgoFWVYXk MsBf0XqTcLH5yfuKuSTyZVlRtRPeCbtBSd6nCxXy4+vFAr9WiMzKDEeUNbQszBUzCug79raGDrtR 2KPAakQtP1zhYSMijkaTsTiCgYgrvGjmc+dgvELekXe7unK77WA0tB7R+o40fUyWxuPxP/zDP/zj P/6j5balirAUFiHcdZNJNoz+STuLcw5JTLoKpOdgMX66EqwBNDoIztYHNX8UhDlZn1g9EGs8TUua 9cOS961BYObdbnd2dkbVTlUAZGJCdD3090Jd7bHjgItVVcl2i7fmjOeVPRiJCIKNZqdEtJ5PbSon ji1WCpfthe5HEIGk45/e24Wes095rxIOK8bsfNA3jJffZSa7DyKt+WaSsreeEbDHMzF+E1aX0ZwZ knXByfQRamF92EPoyRXHTavU32636/Xa0Z7vVoF0LeN5PthJKGiw0gUQ9gcICYbD4WQyIaIvv/xy Op1GccCqKu8foXVyiJahACV7cKeQ156CMyrldCh7mbrxr4mS2XIIEqq6FbU76SdVW2gN2XghqRAd 4dgti7F12rbpzmynUaqztmdL7QW1zShVrJANFa+6NpxFUaEFDdrNxWKhNrn2xaFYURRffvnlixcv /ud//keF4o2EQ0QwOWCx7JzD50iAw7lwoj2U1SNKy8Q6/kDt5QQmB/lMn6I9yC004G5bQn77zc7O tkjyXzrvZd9ySewWXbeM+tZNamQPx5HlasjBQ2G6QF2FD12h9LA3YaZiuusEsAqarAKFQ+hP9Y6O VpouDMUKkSbOYiOivUpFRJxBG9ZLJdv3k+h+cYbyDGUhdkpIt1KsH7S9b/6drT8SQ96iTnr/+Pt2 ulQKko+Ued+FdFZ3vU0rCVZQ0tNgEeHEL6AHcBCRcOMvoKDch7AKWNpVVe12u6+//no+O9tsNsqi or2OApdCeMrhcMirZfYECNE1ONn5+Tm2i6urq0jk4L0nqojEnNhJEQbYsPd+MplAy+CCMXvW0805 t9vtXr9+XZtM7vo4/ZrVMrgQXkKzN0DjD4VIGgYteiM2FoW+a59EYe+ybnzz5g022Ahz4NVETU1v P0iRGkUP8Njzv/jiCw1UYYECGC6FmfDgwQNqh7pAhVm8EjV7vV5PJhMkfscoNf18+PDh2dmZvs4y xEvHV53i6/VaQgD5W1O/T3O05Hrety2gsAviuNq4OWjjT+LWIDsP4Bbb1bbbTYj3SlgPun0ASqOd OPeo45nqj6IOupA+3iVZYaN4wNFd2gC92CUOleAoH2FEkK7hoHZhBRxVCDCaHfmTeJudJ/eOOSiw 8AiM9rMWRxlj7bT6LkFOdES+I90FH5PpRU+rDg77H66MpEdQp7zKTg8RwWAoRCDdXnxir90POBxp rlolFWYjxTzY7Xq1mUwm261KN1qYQ0ygCI2HjZ984jfLzK9evUJh7D/KvEtNUeZdKJ+xyUAHVbDd gxiU8BTgg4h5e+8hxem/HWniVR7AzOv1+qCVqzpXKiLHW4N7oDNmfIPBAPnwcKMektV5lRItSVmW FxcXkeTANuUg07Etx+Owz89mMxF5+/Yt4EXUQWXQGAE0PgIctg2RgQszf/bZZ/iMFDZ6yiWNNIqZ BwkYJTaG1oD2JCFHtn3p5tIjDCArTWozMIvLtHIMjSJiWwnkNz0NU4id/lpV1evXrzH7qwT+WzlH +ND1nA9EEjQUVlukM0OCbZE9MaRLSznEMXBK8ZyKHHwwFrHCRhT2be8eq0nRxogVGhkJB95UBFCO HJD+9t8vV4sQTFYS03mvZOZ8WioqkKKNe+mUC+EQjm1828UmlfTYktnDfTRWxzy3B7Ls+fr7NHDJ /9r9RDsUklCHMCzuYwQ4nHMR4CBjGumMOSF86LbbLTTX3hWr1Wowma/X6+2uM+gWTnSqueii9XqN yNyr1YpDolcAjtQa0ZImoBcRRTYqdaBDZhyRSIONikRz0dV1vNHBNQ9tVl4Lm83+szEFS1j14PDG bwj+KRwMV7MtL03OVUCi1WoFqQAY/OPHj089ylrwF6lCopJgB9E53ObZqULU/GzwVh1n231ch7sv Behm10hJQZptAQeZUy8FDdAdocYdybbHyqh1NeLrYDDAErXWBigwmUwOzle7Hnxj8EzOue12+9ln n3XpEbK8hJnJZwSAd2QAnbcbA0OdQADgztjJ9sjGoykFwZp2zb79HlmRHZlI/pkdfN1ho65JOyNg S8LRZk7fWIqGKGLDPV0oy9IbaNW17mBi2+LftOdSFnzoxdt2ZR+W0V7srzD73FYNbeTRPuLvz/3H IMWD7b/7hOmq4XaAI8VeabUSIuqqGPJ2gIPC5qnwDtJNCRlZy7KcTmYisqljxbHllGVIZMrMfrff CaNzAhFVVQVbOg6ht2zqVy3svWeOfVLm8/nXX3+tWEHNLOAo2zVclGRZU5EMcBUSiXnvIwth7I03 Nzdv375FuFVIx+u63u12+jUVUoIg6FXJhP2gkT/svhoNAhizcw4GmFjsGNLdbtdzPD6S7AGPuo1g LOkrA+kZNWJ5Vch0kz4RL1GDu2Pu7WcRwo2BM2mWk2gx6Bn0dgLng508SCmD18Wj0U7ABbkJmrlf NpFIqossgtEhruvaeSGi1Wr12WefAaFnQS/aoA99TwqWVD7U9UZ0s7ZZXbit4IwsVLrOytnKexqJ 5+rk9jnXfJVScKCoWnudDODQYlEb7sJR+jt7UiWn/tRFnhoBlc5J/Um7740dTPQ4XRH3gsysYqin WBbcWE2KrcG5JhlVBDWoA6kc08L+ht1lKETkfTgzRaOkbzPdfpvXzYltTUalYm50TeVk8hbpEdZa 6W2327quZZc5iK/X69F4TMbYkA6pxbFPigj4qA8+iZWJkEGNNL6JsqVGnXgEBDA+pI4D69Jzc0RA 5AAcNsQntR1l9Yrl+iiwXq+Xy+XFxQWMTzE+iI4lycmW2rbAej3SCeijKSfLQQ0XFxe4F6IgZt7t dlj1atN2UMpiybYBJ8bU09iOTHrdNlUz0lGLtTWCnAhwRFWp2GY8HsMEs+HXAGIIi6YNxYd0Bzm+ 82hrVpTUzzKzT+cQkqHLaIiILIzK+pH3UFfhqqqGozE+vHnz5my0B9Fpv2yDtU/p3nF8q+5Iun9x iBGiU+feD3xdOz72na5pDSN5izbYxEdvtTOoVLJP77nYT+mR/S6Y48inHHULEZnQNVFtoafuIOa4 F1JAlr0O6mlAF4CwwIg6Br/r0WkDUsoCnT9cyop6clek61d79rA2WMxMBTGzC5trz34YHDb3/DuK JkDBohBsCZoUMB6cfcuylDquX4UBGnTLBnLQYuPxWHJtU0YDwOHbsRIoxxGYGcFY1bMmTWYWGY26 4Lihh1v9SXPGwmUGw6vidhC0V/oKEAQF2EKN7VTR7IP5LSw/bre5WZmWEoWlZ5tn76Jw1IG3KTZw xDx1IaI59CEWKCt80Tqdcy9fvvztb39Lhl2WGHdvDAOpA1gA7p3EyI+UbaQiKR0aNWZUSVfkspsl NTqJRrOnAV1Nxcis1+v1ev1wMh2W5bJ7BKyE4+5ynSyl+3hXMUt6HT3VKWJviZao1oM11tMdu3Ol bAP3Jmtmf5iLXpBezEo4RMTdylb0dkjivvCHrnN7sa+14S5dCOmN+pOOeWRqGr2Lnr70LOquGtLG 2+0mbe1B6sEllBu6tIMppYvlFuKT90EKE3VZSXBhdc7h3Vro0Ozs5uupz+onNgrraDJYmSgzL5fL nuMcZJnPnz//z//8T9gF7nY7hF1Q/8HJZOIKT7v99LY7FfYKrR+cCOfhxWJRVZWL46s2z8UVDd2h NeBehFcnor3hahAYK1KR1omxySWpfsUuCL+rXKYOtBOcFB3RGyXISJSBqqhptVppS+z2C6kP5C5q lNq14uy70MovLi7gcAqHROdcP8e0VIYYr2ScB3XAvXF4gTlwD2tAnFYYbDSVT6dTGPio66k3hsdk 5utJUOOO5NvB9RRw+MQtuL8SZV23bgmsi9+9ewe/KchRUCdgjc4nq+9wQZiZzpJb73TZXWZfW7Dh SLdmLaNGWxhAlCzLUsJoK+yjIBrRXhzk5WyCketEUglHejtc8ux1fNaNKQs46rqWcKLSx9nmZS0e skvivsDEQXIdoXK7kAQROaPjS0/54cr+a9fbsRvoAVSRgImTxkc7qDJkfSkRZImOjPrEFApov6KE i64tGqHcmrKYzAUNAonJrXr6MnwfGEXnMBuTfBHy3kuylu/rcdTRF8jJ17ttxMn0w3q9HoyGdmFm K7m8vAT/LkPqVA6WAc08CYGYI3DAJjSnlVKA56WZwJQUQ+jy55D6lYwWAF99gCx6mqdwsorqh2D7 5cuX0XmYgmjHTjC9rrfb3mWVGtvt1hpqqL0dZB6r1WqxWNAhzhu9LOCh+XyuRi3oLGRLB2tDs21e GDUd1azjzvgSqwjAbvuKz6AhKssSfLOBUWdnZw8ePECsD23979dENLvSut7c+yMdDRgQ6Uqg9mv7 kE26I6m9elmWg8EAYfNXwTYiYgBW0JU9amthCrwkOiIosrGB4ESk5p0aMNtNUFGLbmrNEcFIOKJN MwLHB2BZaNvRA3ZXXNIzbj3Pcu2v0WfLTcn2upchHmiGefWK1LtuT0G/PcyRsRfGRWSkjJBT15tK xZy2vAThnOQi+lD/u5a94CeLdT4kpRhL9v6lwsxiRDtNASKKrF7SartVKl2kMkhfFKPR6Ga90vZQ OOwREfZAeLQqp4AMQ6vSLdoe5XERfh/2oMxtM1j7XnzwTFH8SkQ2tKV94+Bi2h69jsIQaVjDESuv tVvcer2ezWZ2ZJj5zZs3Ue8iUUHEDsruWOb2ot7lgpoGhHO1+uZAU3MS0gVoe/DgAbZ3ERkMBhxM LmyTrHRNL+IVIKR6URSQlFCYh96QRkyJbGvSgN1sDFHL9Xo9GAyeP39+fn6ulswfUpgB0s5nk40p gQ/Bffl4GdHtSKemD/nobZTSI0fp97WdZQmzZD6fYwBHo9GjR4/W67U43u1M+FQiMrMQvrVd8cG0 d5FGBko+pPDRyikEdd1VW040I1ZWIW1KbTjueFQ98qX0wIW7A5Hs5+b4ReKcg3yYg+ewHWERUTn3 fmyrzvC+dFAQYpCi1bsp9TByhYbWMkBRkTdujVq4qqp6G6sMtNrs2KbyDHVhkGBhpuKxCB45o3+J HqFAucFsx02nY4t1M/0Wbkich6uqIt+M3kmYtb+RODvZU7WeQFyINTybzaCG0IECXhwMBqPRiEmI yA+agFGSqO20IyoDVtAQCeedcxZwuEC2bUAzWWS5v9Fo5L1JmkFhx6PgDxLfGHY87/1kMnn79u35 +TmsQLJJ17Qj3liuNLESqmq73WquNQriIg4RgyzOiP6DBeMtPHnyZDKZDAaDuq4fPnyom2Q2QHYP 4SQJo1GYP06nUwA+NZTRHqWL5Te/+c18Pn/27JmGg0NcTcjIvfePHz8GgtE6tQZr8/D06dPXr18T 0aNHj1ar1XK5LNfr9Xe+850XL16AD2noseP7di+kKK9nx1GCJAoCKL0YCXWVJ90aPKW80Dl3c3ND IrQH433t/KZJPnxbdYLZc3Fx4XbrzWajcyuCDhI0Ha5DNQDSIcKOg+lEbRhBQXimEb3sTFP8oZKP FHAws08kHLYBPc3Tz3fBCjo/o0oO1hnty1FY5bg2aanqolEK1Ir6CnSCRWGZt72xr5GGnYPxHAk4 7IEG0mB8tlPFBT9Me710XiWpEXzs2QQkCFcsk/bBE8qyKBfsBjCG3nvnmuA9dpRoz+oy3czSvWyP KSoyb3xXlqVwM277k2hy4yEJh0SCakwSBRyYPOPxuCwG3nspisFgsON6NpvBj5SIdrvdar3G1rHZ bAYk3nvxDswiekcKL6L5YwFB14DYn8CtYbOJ91VVVZeXCpSvwBZIzQEODZtQxLSAM2Zd13thKTPC tGM8x+Mx9Bd0tNWL1bMw83K5VMDhc4YmkeRDD/3T6ZSZJ5PJdDodDAbAOvP5HAHB1JziGLKCltls BpgCVQjwhy2MEdaFSWHVvHv3bjgcAnDsdrvlcvno0SPIM+BWAwfp0WiE+t++fRu9GuwhH3/88fn5 OaQgRNSoV25ubtBn2HBgy/B3DvB1F3JHWLiIyGazsSHP67Zqn7vz1KfUIftqGoOqdFu3d314UdAd SZm0GIO14XCIQ4wtQ2b6QiKSjZym42MPKJiIuodqhVVVQe3HUkfP0lZplFgLO9JssentH4Ys1Dhy dumYRLPaAjgXJJb46kkqk7FaRMoQo1oPEyKNE9Aeacn9aELVUCk8KDPs9qJPnAIOrouyLGsW9SxT 27SIB6c3Rqg3xZH2yKTnwmZqmdzOLhjxGYizFzB0NTvCuAfpeAlH9CskHD6YKDY4PlN/3xN3icTL hjLC4OM0Px5NvPeTswvvffW2SVWqHpXeuHc28buKWH8BijZS9YNdLBZwHuk/g8EVQoV5OP2r/8hB pnB+fv71119Dh4JDPJg3gEijszC5VCjMVTiPPH/+XI0qynYwq6iP4I+RWCViB1VVPX/+vL+/i8Vi Mpnsdrvz83OAHuSaEBEEFIeKZ71eY2SOp6IoHj16dH5+/urVK/DTjz766KuvvkL8jO12+9FHH0Hh Yq1etOVlWV5eXv74xz9eLBaLxeL8/Hw6nY5GIwCLyWQyHo9Ho9HTp099SBwT0ZMnT37+858DZFAQ f65WqxKuiRR2GexuEOmc1MM7kg8xXk6KdqJ2FSA7PzgX0jRLXcUUpUIspkFgIH8Uyw5NVRGu7wkB 3kPpBnSXQ3lEqnNFfL35fL7b7aLUOdFDdWlF3fFB2W+xne77eFCj+g39tG4oRgAAIABJREFUagxF XWbjtjgjgo9RMUp43vugVMar16n7jaTXdW5HqEIrz+xKIcsg+CsWbSQ/AMYjo/wWY6NAOZnEMSPW 1d+eea4DctIbiao9Zob74ONHiQ2EMj8rltPJqWgGM1ZTPGounmw3s3S/sw69YBPXQfsoRuDXvF9H FOPUJEYRHSXWRYXKXOE6MDm7WC6X8/n8zZs3YHL2pA60MRgN1+v1fNSEBISEQAvogQFPQfis6XR6 c3Nzc3NzcXHR7DPeSZUfRnDEMiSJVbsNVdCkt3AIJDoejxG70loygq+NRqNomyqKQoIjSVEUT548 AftXy83ZbKbOrmosqSaQWgzHsNFotN1uFWHAZrM0GUKsWgRsyzl3c3Pz8uXLxWKB65BJOOcuLy+L olgsFvP5XB1l9cX1v1mM23w+/+u//utf//rX3//+98fjMRrz7NkzRCuvqurZs2cPHjyw00wJSrcf //jHP/rRjwD4ZrOZpqNDsC4c9SeTyfn5efQugG++973vfe9739PrOiX2ZqswGsXinE6nByU5Lsnz ng5KuiulZE3QTzLLkCDqz7YhbUCWet5fg8edE5HVamV9ssuy3O7W3nvvwVZFZULNXhB2im+gCESb VIdckVQ6u010UZ3kjlKK0MZsNsMJACKNCISJNOnpU8DBIeBKf0vuiDbMoTbTBXsl7a/vyCYYvegI Q7igjKc2w7CPTvGBa+esOiYKThYCaq/7dqvcmu2hLnhx6wl/cCfVzSHCwWRGOzIiUfgFUZBKODC2 kRzOuXsGE0eStA04mNm5vTVfix9459o2dgj81VL+xknU8+RDKMzxeDyfzy8vL8uyrJ2/uLjYvn5F RLBIIHixUfOUsixh3jE9m7ugnLWNd87VdQ0/WNWXjcdjTfRlGy8iVkaDeY7DD9r2+PHj169fs8nW 0TW7JOQrefLkCTMjbOjNzU0ZKBWu2M38/Pz8Zz/72X/8x388fPhwsVgMBgMENkVIb9yOZmhGKvS0 KIoHDx788Ic/hEzIGjqMx+PLy0sMLwUPFAvFiOjhw4d///d/v1wukXPENq8sy5cvX+p/vd61TOzU HQ6Hf/M3f3N1dTWfzwF9ICtCJHsc/6BZs+cTpbOzs8vLy7/4i7/45S9/+cknn/zLv/zLT3/603// 938noo8++ggQUGWTabzRSGChcrIGfpFJU6tnqffBJvsBR5ena/8WcAyguR0xc1mUWHKbQM3GRE2o FucQEkKOEcbegrJ88fgbdTO119VPnYJaajAYbLkvGZuSa/uh6IP0MAFuh8MEJlKdZMsMphvxBNO9 NT/3gkol7dR7ImeIArzWg06Kto+sk9rH9FNv75fQalNPrdnSqf1yJtXRSfuGZSGSk8o4oyJRwtv3 wT0+eqKitKgSWzOGERsihEbiHZHzJ+lK7mw0aluoK13aKsjoWcKiFgMNv09edRS9o+uJYEIiAsYD lXrtGrkCWKzKCeDmAANwEZlOp81h3cfzTYIIE6wXzOnJkyf/9V//pWr+siwpCZkK8t7P5/OXL19u t9uLi4unT59+/vnn3nvFAUVRUMIgcVg6Ozt78uQJJuFkMnn27NmrV69Go5FCB8Jpx+3tTzGY4/H4 008/Xa/XP/rRj7z3i8ViuVxeXV1tt9uHDx/OZjOgMQpck40F6HQ6/fjjj1+8eLFcLiFFgIgFbBjj jExpkovm8OjRo7/7u7/DUQROJVGBsiyvrq5cr/Ytetci8vDhw8lkAhx5dXU1Ho8vLi5ev36N+BcS Yjr0zOHvf//7zPzgwQMRefLkyWaz+fjjj/HTdDpdr9foWtVO22bfI1gnvIcU7ZUYxyokxwN7cM7B i7qrNVEPe0itim7NJD7MmSPdKHEqsoH57MimJ9T0KAxocrvdP0IJFHbkfn6TrSGLOfC5qipEGdmV 7mBCJjKiXWqbMkgI1+OMAYdKyOzYYl6JSPYc9mGQxJGE7lgU74La2yU2RuB8Vp2nHVGpuP56axyZ JZ0e+BrZYEY96hlePbKkDUvvsm/K9vTU18fGtFMbaZuU3mJnYH/l/f3N/mpr7rn33s8V/X3ZD7UR 6KaAo1HK5HKpUHvLskuVgtDOez8YjYno8vLyiy++eP78+WKxAM4QImyGIjKggd6+Wa19LsQOONzV 1RUzv3z58sGDB3/+53++Xq8fPXoEMX7XVHn69CkRffnllx9//DE0OD//+c/x08OHD3/60582ADG5 9+HDhw8ePPjJT37yk5/8ZLFYjMfjq6urP/3TP9WzwSeffNKYQxnAgUPRy5cvX758qeOsYAIrdzgc /uY3v4F5KQX4q+42k8nkO9/5ztdff/3DH/4QBg2DweCLL77w3j979gyiC4QTzfb32bNn0ZWWsCro WVrX2+/RllTFN3DPaDSCwwuwI3QfVp97cBoDUsCm1U5RKJ4gyYiaHa1Nm50N4rRYhYHZb12ru8gF Mys6IstAVpx1/LqNOnyLw2UPdTEA5/eS/7quISbCqtMPAWl451xR7ANX1MLO+ZpcW2p4FJVMyfmf COd7t7eccuTIJCuWJNEzRJp6CpSgPgQ+gBEiVHQyGdr517P9RfMVI4BzPwYEijl7i+ogQc1+IXkL IWHOmMbpr9LyUjlIPQfunimkcoioI9bdyyX2nrbCVPx7EMxFuEGMpDpLzEwsLMwmlsl213dO6F9u rrGrIUfkhIgNt8oaKwoRXi4LQ44lAgck3bKzz9VRrY1HUiqH0PGPhs7O0n6BStpfdqHhzrmyqKtK wLOlb87rXa2/uPKY7x5ELVHJ3A9MjVRPexTfxS5WMNl9QF+hc05HinN/tSc/GsA0AZK8yWRyc3ND hZ8/OF9u1s57V5ZCPJ+fF0VxfvGgGJTiSFyjjGuk494Nx6PxdPKX/+//o2nb8NNHZ2ez2ezho0tf FrUweSfSEgA577//gx88e/5c2bmuLCw6ZOWo6pqSEXt4efn//d//2zXC2Jd8UbDZjnV9wSghYjE6 6xDTIjsJRWQ8Hn/88cd6+ieiuq6fPHmyXC7Bj2ezGVh+V9siSleNmMg01L2r2OswO41UHnryOdgG LQOokbVXjRyU7FmLure7zWazjztJRAjbTscdv6SdGCxLOENTUC37YJTqT/TveK+AA5SKMSPBwGg0 gi39eFBCAlbXtUjt27F40doisJzjp1ranlRcTCZOyUndgeoESk2E9LfVVtstepEdWD34uljT7Oyu Co0gJdpK7YsaczCzjfl4sP17JkSZiz0UDRQnTufZW0CN3tfts5lEC8x+tZ+jhh3vQK+DIyLIFpvW HFksWZjSY2Z75NMxXQ/eLoG4bSQIPSOFcY78YyO+SEREBXe7klkJk9bTc1CJBC06MqeOhk7pHsCX qzYjBIquHly22aFoLYT0lsyVuPwx2wUzL5fLy4dz7/31zQJmDY8ePQKgeT6dWAukoih8WaiWwVrS jMfj58+fT6fTH/zgB94ke1Oj6fl8fn5+rkc1PaxiP3n06JEGJGVm8A5NKUqhOynvyIbNsLS34UgG A4204bftsHBI/RHVRsG9JTu8aDOMOXpa1UM6/Xpq6OGhKd+5Bc+9NfPqaVJ5dXUF3RWFBDZHjhEW nXq6Rz+Zz8AKTfhs7x03Crwjz/5i/tuL+Xs7hqlzyfXvR957Con7kHxINAQTjoNJxbrbeu9xApDD 6z1D0eQwthc+dMeRmJ6Gp2S3LcgnVS9r8fJgMGBOmUEcVcnW7ENuFB9M68sQwtwFb0N7ZpWQa37P ILsBR9Tx9ob73hUuLgSqIqKiKAp3ODBM10/Hr/CIWWZ/an1gUekiZJsN+w8wpYdTHtMe6t1uUj0I hZZQjhlHJfcMQzLoVoJVkMJZMrsnzAK0GdG9Peqkno6nwOIYafP7Jh3FbDv2LUwyAx8MiG73Jf27 vr4uy3LHfjweb7ZbIZrMZ0+fPi2GTTBi0rfgm7hwyE6iXioShJ3f+c53nHNPnz598+ZNFPDDOQfB PiaJc47MrFaPDzJngxQEdJ2LjnVv7GBVaeY27fLFxUV2GZchKB8lm8DdM8ub9t6bbeKpmON9ULlY LDQUjAokjifd4HoOeRRmSXaf+maSiFi9Epy1IBvs6cJebGUMu+6FrKjtpGqjY7Fy09VqBT0REdV+ n01ej/jZd6pvFsBFlSlq3ACprC3mnMOgsfF3db229FnxBgXAcRdmcFC8ofpsHQf81MV9owLZ9Zwy sCzCSMtgvVhBQjoyWoCIqEcddYjUhs6HoAKRU4x9tIbNoGABprKHnu7og/TSkW0Dg4GPpa1KTLqf Fpw1ncq+8S5Ypld+X5gjcGLj2XugfHIlF9pcQXMaCQbvDtlcYeMJR4yLi4vhcHj+8GI0Gp2fn0OE XhSFuEZakBNZNavgxYsXRPT06VM22dEiYVUY3qaSCEMUIXhXb+/vmbLipWNkfn9UdEfUUq5WK5jy 4nv/CSkiWyoL9CTk5CUioFfEfTq1lVZFdJDd6nDccb4q4FitVl988QVUBt77vIWFIREZ3CHselYo cgvsgu0YajLdcVQV4oLfmoiwb5zK0tNDTnq8F6rjqw+xzClx3YRACPzJpmrrARxdjIqOABz2p1uM mMJiaodISkuySf50F8GjhYMteEeCnyLAoQWqqqqqHZtgMCKNyVHPs/p/5RCzGRgx+yJQLM26ZxUZ 0bNO2q/Twj4JuBc9lEwEiJ7HiTQmA7aqnr3o9yvnYGbxjjoAx36cg1n6fvs9NOsj61FmXiwW4/GE iMQPkUTDe//48WOgk+l0Op/PFYxCwkHG8lTPMHTKWgizvbO5Xbt3D4L8lr75VFZVBTNaDnlW6FaA o2t/l+CKqUFmerIbfxOJ+c2bN5999hlUkjc3N/6IJQ3d/10emy7dUysUY2RjNdPKG8DDiqKotmJl FbYGe+bT/4padJuzelZlA4p4qqpar9et2o6LFhB1/I4SDj2spGPrDFEymdNzYQ9X0889zAw/mZih CaQLgAOgMIoDyxWkHS25gshhHWXv0DXMWMukYT/0tUpiYBRh0PsiMeYp2tn0q21S9O5U6CgiNbXM O6JO4auV7f0eMYeIQPXcpVLBB+Y4ER054w+Vu8Wa+wFZrtfrxeLm8ePHq+1VWZbWu4GcUyV7I6go i6jOg/bXt6BTbzyyfPo2+wXz/1vJmlSeeqML0fMOFo4MSDmEnzc+yqeINyLS/VFrUIswxEKJwln6 U6Kna6NvJ+C6XY/QHUR8e/36tQ0B67330LC2vS3UpoEk4+ZwPHnvJRWPBxGrOcXHRWCM4Rw5R+yI XPN5XzL8VBOiDxBRE+kZKdZgPOU6XHDFGNNh707zKVitEyS0MBdtv4Vv3Nq24g1Ldj+1v6pVjYUC 1BGeyzJOvZ0CJkvVJTAaBc6IDDssp7xfHm+Xf781SbRRHBM1LmLw+NRV2HqB2UFTMxH83263URzG 9Ik4RDnn1uv1zu1HzCLvfY+IhMgpw+aOeBHvmbQx1LFOFBJJ+GwwRL42pbIsB6PGzRtXqqoicszM xEg7gsCjIiLeRSaTdglEi+X47c6U/KDiCudcNEB/DCAjXR3KmjV/QlSgR2QlRrJ45LP0mPr/s/dm PZYc2ZngOebud48lIzNJFkmVpCKqpNYIGgHqfhhM9zw0+kkC9FP1C2YG0NNoJDTQkKBlJFWLLBZZ mclcIiPi7m525uFzO/e4+RIeK5OlOiCCN/36NTczNzv2nX2z2eSINdKvb60ftjZUzWntvYevpVZb VZ+vB6IwIOX+QILeGJ3H6QINR9f9zanLTeGlu9PtmpKGz4c9MOIAg4jAbcqmX7y2cWVGOCFgOkGb m80G6xK6jWa/bjOWNg3HTVFdl3pjyMu6Vu2UnNl6UW/TvarnqEUbh1OZKsFdTSq1GyD7St0P9zoa zlt1YXR91QyWGS4qDQEcFMtw6D/tPOiQ1e5jZziZEOvKqonj6FZZQx6Ump3pARzJPZa4bcsrIW4i wRAhBAAORNSijgaKi5YSkiCjR6BHftYHtQwsWWPZ7Qi70opAuk8rY3pMRgJSb5vdbock9xcXF8fH x0gviygktPDu3Tub1DxhjAk3YGbk6RaRGuCoqeYGUOLDgUotegIhwAkHDxJMaX28h9vtSdGd+JTb OEAAMCWvpJ/U0ul6I/v7yTNRKyuJ2gvEpjD3cSPIakGE49/k+ma7zb1H/Z6QVw6PGDJ0M3hZaisR EXUWczF/tnPOepWrCQCHgXUnbOvgjakJOJr8okcC67qC3CGgLn1GKyXp4JpgQntr3QuaKyo5I0MI IXjA3KbyI4QAwBHCoGV5042mkKJ1k+q3TaR14wd1rwGBotS3zFIQo0OlKhNJ04OkFX/sDVcUkkNg V1QVEJMYJUFgk7rjcUkHcCPAwQ1f71ZCTJnGsYN2u102OqQAx7d+u7mv4/8xYcQ9UuI12HQ5eJxx KXTI2yql9fxK2S8+4OBPKk64mOfeKjZCCC9evICLj4spVs/Pz6EygMoQmANwhIhOT0/10eo4oSrw i4uLCnDoY/AhYaPDSR318zxHOn1VeGrtQXqUN3QvegXVcGh+1h4x7gA1YB67A+DQBmlYnpZ+kkaw CeTCqrpE9BBEFYOiKNSkgr+2AzpAMlgYX4HT2RxftvTMB0uq21ATkvrBtd4f6sGiEh0tyUAKiy0S c0A3/KpRWZYUPG5u6hIgqF/byC0AvZ7Nen43MUer4bWpZqj1tutxvYdpc/skeCIxiNiOJc89ILnu gSe/bY7x7tQDBVof1A84KshlEn81xUWJ15ugHAeMvRhC4LpAnOc53aA0+q8nAXCE+BkXHx88hUgD b7ZeX0k+cT3L1us1xexeEC9V9aCB0Cifq2pvjtmWtZwF/moufO0A9Auj0UhiTvfpdLper3OkmrcO B7dGG2DfWK8Qne0Nll9Yo+MtaOC8J1LOcPLeq9vBN998c35+ntzAJoL8/skx0oDirasR6sA+4t9O xQ2TMAUSCcGROJJA1VtnoiCByQUSksDkJATKHHCGnSjFp4dWo4ovM1W/qe3ssab3jsm/k4bjXja8 dRHVygIWQuFDMOF5erbhn/APCMYtkYx9QUWKgctPm93tdhS81Ml2gM2/9Oci10Sp9JNEzYHEijat QR+te+p257TvD+LtUK5YMJRQ8naaPekoUFp/SpVgh0REGAtuyGgGUfPgb140PTn87Wwwqh5tg0MI x4Z9dFEUNm02AmWHH3IJfbD6jBudBVAGLJfL2WKhEmCIGcmUdrtdkp3sHgkiDVzvhxzNVfJoEbw+ KydrC7CsWb4nUUDSkEPgVIxUYo4lVWlDAYbP8/lcNdyawQh+x/gJjPVFUSwWi3yz2YzHY2WpugqT ddbhQphewUiQaxKQJ4SAMseDZ7hGzeUusWjTENQSl9fNEldYNRT0SJjx4baVO1LPJg/RzWKIwt/y aNVJqBAPWGC5Xmike9L92XycxSIouKyr9tZQ73GIY6Eca0bpWqISC9FRrPVV97ar3Wk9MxLnDOn2 irD/REkj1XAkxoLq/sqXsWHy4DusTz6oUlqfq11txRZdmKNnAfjBm1IaRHX7nZiInp6HltcxoUc+ Jnsm50Y9GcINEkIltnCI6+Esy8BSd7vdq1evTp6cQouuZWP/HRJ83p1zSImJgz8YL8gQwnw+vy+v wVayUR7DwR96rnX4Qgj6Nkej0Wg0Wq1Ws9nMe68vd7PZwLnHxYxKqISy2Wym0+lms8Gxq+XptYpF s2AsmcQBVhcuIvnV1dV0Op1Op1aZHOqGK/SyORHJIldNSzN7WOt+GLJJWvckuEzrOG9HUk/zJaaw NdVlCFJNw309u43A7hOrRFTnEVXJBDuNy45ZNJWnrxkdIdl4klLCaDTCP52vWQeSnlBD7hejo9If qutGaDo5ttCtgMh9TLrG+Nn90ApeMQb7CnCeOZemH9VharFli9qTkzJ9hHGJwN/tdssS9BBtiuxR NdDgPr2A45rtxgeNVBPrXPtCdYCh250iof3g0Gi0GVtmvaIeytrbnsA3EemCOIlVojFRwQ5RW0ua b39oR2eGSErDfTiGow04aRERCn7a/V4UhafDwbnZbCq/0ceSsj5AQs02EXGxxv1qtVJfh64Qj4cg NXzbhddqdpeogUZBYFVpYIPkeY5yr/P5fLlcwr5B0SHUPm48HhdFkef50dGRXQOTYU4k6l2QXM+B a+bzuSo5rEIYSpgHmtOGp/Qg0nMO7/uOQok9GJLr6n+q9zzO2lJKHmdPr36NEQ6wxNsA7xeqCNUK QkVWxIXbXM1NssBUotSuPoZI8DVgrm4MOO5R+lTzX/80iog3Gdn14pBH2HO6J2pUj1I9O3E/AIem LU/OudsBjh5i5qaGQ7HjkBa083Vw0IdRSs56vtVmFcdYwGFxhu1n/6pLAIekAaUp2mheGTgb1xIG 1bWkH07RYifTLn7UF13vAhGhiLlz7tWrV6WEh44r/MAJiUmwqnCIqqB7i3RntyY8Oqkp3wqvoZxA Kgq9iMUGjwqcm7Da5xFIUXcCG2rAEXRmSFaLZGaYOX/z5g1FnYSLWY3JZDBF/wbMyZ1oOKyRhhek frZWeeouZ6UPskwquUeHLCI4pKkjxUIrjks63PUVfGmRN/3QvY6bY7cdziTnXPPYtqAkxIqjbDw6 uZ62pRL02woXdY0F6x5TnZymCFNKkop2tTTkcY3f3IP3BoY8pAaemOgejKvnztbPoJ6FrToMG/YZ QuDoUdEOVqT2v+YXNyUx/h/2dG8KT10/r2OCA0pIAJOlnTvsu657bMtxOx+QrsVqPQ86tNZ2McGd bEhqma0fz0rYg0XuTtvtdlqWIqKFx5j59PR0sVgssjFGd3JyUoE5X2p55KpvD9StD5Xs2gCjfoTT sEmz2Wy1WjVdfZs0mUxaLRLUWLpHR0f2q+aS63/WtQcfNXQwIYR87wPHEhjNuxVYDe/Ho1EyYC3n Ya/EKPzqSmgIrLa15hWdL50K0ukLQjaC7lbKD5XP7MVr2Y29P+l2on5Xyc8aApWNXsujk8atrzLY scVqEpNeqyWop+UbZRpt9uQupEw2AV5Jb/Wf9vRNzuCun1x70ZJijmBjUuqWgnQIHRoOoTsUKjIm laYp5/CIhq0kQRjWi8IWlms2tXM1V1zboH1WK+AgoxyyQKd/iM2vrYH5MBNxhcBoHblKv5brZiaV ITTcpHIjCiGs1+v5fE5R1ff06dOPPvpoPp/Pjp4ozIKj32a/6zpfH9nf5fuihEvgIH8E0Nmk4Vmd 7uWVdZnX9VuuRz/1nIDalPc+f3b2BIqaVhm32fX7Yv2J1fyOr1AF1qQdsAx7eDQVQXZEyefkHBqN Rt777X5HpIBDFB8o72NmkQo3NOGapTIEhx/efMiq7Oq5J+Hddzc/JW8NawYhVTbr1wDuf4PXzcOy CwyhJIkq3i9WRSt0A2DFmlH/xNbRNY/MZPJbSX+SJLbienqJpIVuk8pdAYc+ywKOJgKwG4rqiMHu L8XTrbAJgEMfJw2y7cgBPaeAoxWsKNVcmHWszC46nDXdd6y5jWP5IX1uYnP5IZ67lt+gEv3nP/6x iDw5+0ii0mi731nzgdIPcbx3JBU1lewyewTw4aLX50DM0XWPmDzRCXVddyaIxEqtAx/abDP/6U9/ CmfUR6aBwKUVRtyoKedcCNcw4lZBRwk8VHEDeGhOsNrsrcFCPU9xJMD0gPwWXY++nWqkekpHGVJc H7ITBu4WVR0pW1cfDjHFLPb7veaTuV/AUTV4Z17XWu0aL1Stkk3hXnzQTHmJSN1EGPZwHc6MEr9R AI5mBbWqz7fy4RjoNApKTv0uCBUaedktBFEk2oqc9i4NcNVJaL4Cg2JrzkPN+bGdTICO1MNBdQ23 zpWLmXXivB0KCFtGMcQ210X9y6NLw3HHI78sy5F57pMnTz799FM4CWIs0MlPg3/z5s3z0+fXWhCa cO0u3fvQCNL495hQ6B7FrSHUdQhan4e7KB3yn/zkJwmMhVfBrVscQuAdQyYRqaj6zUsc64m3ttCv GQb3aYU1iBFCplTU1A1EIeKPvQQRcSbRU81YY+IXLCxYrVYhGmjgnNXsoXB7OAZnqZsLXEBqqTLi spDIqnys31Y1Xv+PBpz8VtOTeGWr0zv9EKJhE0rOP5zurRY3FtKcsxIjcZKDdhjMSjtgu2GPZEft NVa0P0R0LeBI3CGvUYY1zDFNiJD0pDUS1f5Kv5I2vVcgFmOo8qYurtpiks4QUbKbWye8OWlYtBwD 9RPFZ/uE1KvBWfZirz8c3XoLHd4FETX6KcbC5Zybz+dHR0ejycQ5ZwMdc5JPP/1058t7DAb8NaPH WQZKd7ctDJHeu341xEV0COXPnj17ZJ8MO2zrFdHajVCvjWKV4davs+dxIQQ9wBMTSb9iQ+Ogvvvu u/1+P51ObXlPtGjBkMSEDdqsmJBRIERm9t4vl0s47Ci2y/McMnSPPOHa/Gqb92+3W2RckUYwS5MR 293Sg20pAu3ECYjMcWI18APW9NBF/xAAHy/CjgK5foNxzCazrlgqf1h1bugSrHsO6QSRdIEziRqO BI5Y6gYchyuJvZJNzpV24pYD3oKhpJPx+A/NzxZwJGjD+nHvXKYIQ8sIJC00p9H79tpRQ1aIRD4j IthxTTChoouWB4rfBFVvWK1G/566KWioNTvgfqkZfUhEaIAH2Hq9Pj09ddH7ezweu6yioiiwTgIJ EWWjokc7+xt6ZLqLOvwDoXw8KbKcwapclhGFvHCl7048JQdbThYSZyvKOiPdD/6V+OCImMmBG3bv rYxqj9Ddj00FBamWaKG2oGT8Xy84Z0+avk1duWcH8bt9KH3Gbk+ld7SNVVZDCLvIg7z3kmX7yNFG ws45djm422w8zfJ8v9n4TLayd5PZVvhoOt9vNsLZeDQK+SgE2mw2E5erPGqRGfq89WWeV3HVm81m Mp+m7ynLtsvy6Oj0/PycmZ+dPbu4uChDmE4nCG/zwRfsmEUoZBkDiwtsAAAgAElEQVRnRe4dhYyp yELGnDHHArNcV7QkyMael2qJaH7bTTcAHMkV31hLllz3V0QojYGzsKYM8N7vfCl198YQI345VGJ3 U/K2JCIifNCRhMOLs8f2EEDmGkrcOBr7w9o9zMzOjrl6f3EVkf7toEoNFlECETH+tvWZY/EnCqHy WBJh7+uWppCLIo7KaKLoRNY5l2U1sd5LWSKdmS67auOb5zoi8iFVQd0UjLKwC84H55wjCUTExMwM HOf4YDoJ7CjCu0xIBPuCQyCnpZYr0aNjSdyoY1EV2j8iO3xH1dt1jpjICQU7Oc3UMkycOdSIGU0n 4tgVOeeZyzOXZW5cuKIQ75xz5L2IcAi3txlJU4BpXnnUE1SMD1Db19X/g4YCEBE5IXnkfrZSaBoa b9dOx3W5ByVKs22pX/e5jXq10mSPk2qPQuJ2NHxBV2Al5lFAAnVrs0jeSNKy/lC/dc5BuGsOR9PF q2LDObdcLvVxIWaeoDosEJEyEDNn7IgI2hGIDkVRbLdbJKdjZs1ceXJy8urVKxE5Ojo6Pz9HHkyr 0uCYVlar0kyn08Viod+GEFarVZ7nn376aQgBZXWm0+n79+9hG0JGOcRecyymkGXZfD5Hy+PxuAv8 NfUoSchxzxncer2HFT+OijKR5pEM2NYCsMK9E4IUrkqOVvkbB/DhxI2HLzXsJtQ3M0TdgMM5Nmu4 ps9gZpe1uDEOE5Vro27VMdgGJUay2DgUaZDe3HR88d6v93uJ6g1CefTaLh5yXN1sgGTUq3Fn2QyH B06itzUnU0f0Q3RWSPSFMKmAt+z3e+RkwhKC1enuiY5+Q/dID6fhuNEmugvlZVnaPPDIPonTrr9P IociUioT3PTxN5pBbd9WFxOR8XjclZ2m2T5Gp5gJgKPncapFz/N8s1zbSVCrv6qONRcZu4yJZsdH i8Xi9evXn3z+2cXFxWQxJ6JPF/PKmY7o2Scfv3r16uzZs3w0evbJx1dXV5PF/JgEppZmfn50yfpt qBfIarV6+vxZ8LLb7eaTyWazOT09/dnPfvbf//t/xxDsBEKPulgsqlrVTLaAmYgQUzEesVAIgTIX mHJOs7TpVEhbhsfk28Q3gino45JA/ztSTQzXD8ywbSm83u/3XC/4kigwFFWEEDgIUgWXkep7wekw 7W/tmX3T/ZwFogh52WLAYJHxAYyCxpxbG8FNp9RChOSFNnESasRYBw4vKeZIJsS6hZZlGSo1CUFf QvU1U3+TGPKgORyiHuBDUPfBUEKmUo9yM5GquAq6xoPdsT9YyrKM84yILi8vnz59SkRAG3g12+1W WYFuzBtx6cPkNPZI2xu8k7LqN3RfpDtCjeYWANzjgq8MmTDU4QMMBLYc3APRTRtPbA3j8TjE3FbD G9FYODooaTq9TSHDIfZkNBrJlZBxzrDGfjgBIH0bM2fET58+PTk5GY1G//E//sfFYgGVgx34ZrO5 uLh49uwZLpZleXZ2ttvtFo3KBc6558+fI0ptPB4ji1xRFG/fvl1FKoriP/2n//RX/8//+7u/+7v/ 7b/9N5ysP//5zz/77LPj42N9ul1GwD1lWa5XSzHYkWLEecYHV9xWzUfTEzAZI1QCbTdUZ5JN1nuP 7KaS0tpS2eJt6nEYYhb53W6n2gv1LcAPXfThwN9EwwGlejMr6F2oIKeajJqPPFujT03D4ZxDdhNF G66Rgr1nhusjqsELMeEeCXSwdzYBByiZUr3oBS23Z+m4Nckwj5/Y8wr4igjz4bc1BUYEHFY7otvE BlQfMArZn7bQ93iyFkUh7jAQrHwhFhFUDCFVmJlxaYd/wFDrNzSAADUeDlVXGFbXlqr6a6ENnSrE lm3Ts5fsVwP5giXnHGVcFIUa13e7HbJ7Je5+13apHh7Z3g1M+mq12m63yGPvy8Dk4HmSOUfIshwo eMFXEqgMviiKMshv/+5P/vRP//QP/uAPFovF0dGR1sjRqbY8fbvd7vf7ly9fnp+fv37x8vLy8vz8 HBE60HNA2kBy+9ls9vnnny9iAUOlEML/9r//H3meIw0tM2ej8fGTs+Vyud1uk5uZeR47U3DqjYsH UVwbZVm+f3f+5s2baoYh55EErgERfRG6XhU4K2SOFu9Kw3RgZIPXA6J4+kuNovGatiP+M8Rp3+33 0FuIyH6/X6/XB+E7gR1RSVOWpYQU4IZAamoZ0v8hhL7CbRmGkggv5GBS4UBELBFbBJFtUOncOUcZ USy7U2GX7ifaMYkQCZhOhQmgzVTYgRny3sO1EO4vwod0yHaK4m4NRAQfDyIKkvql2tF3fB5K164l wAu0j3ExM0nKoOKnOCfxIlCyyoJiUuENVPTegvvdI9lN572/uroqRuM8z5fLZZZlp6en31fHvl8y uJyorgz7Hnv1fdGt1FrXTJRzLkcSDhzAOKg0k7dSsjcOwr1xC+pyZu6RrvSN9vdSKcsyzlg9G7bb LUWBNSndC80EPttkKfqhPptpB5DCFvAfqTNhfFFDTHMJgm/ibEacSFEUz58//63f+i1EwKLgHsJK 0RRam81m6/WaiBaLxXK5RGm+/X7/k5/8xCpjdAaggprP5/gAmyuMLOPx2KZFWq/XP/7xj4+Pj9+/ f5/UgdOpwN+s7jEADxJ8hki62WyuLi7JJF1NzlcVf6mu9rBahCq3enxFA5Op344SyV7hsuohFGeI SFmWl5eXeN15nqMWjOpmRITjD0MIds37ql5dsGY1Hftd+FRGVTQEAIdzjhmHGWmRW3ZCBnA45xw5 C2dDPbe9Hop6Q/JQ220xCp7moCT6cEhkzfhajC7ENismbYa1xz0cK7/RiV71P6Tlh6pGIuDQOVQD kG4BRYFKVSP1B91R4hpO/Y3r1lsul8vl8uLiQognk8ns+Amut7K4f7fEzHecjF8/1KKryzWKqiSp //I8t/sgPzs7w/rTPL6JA0eTg7Rin7IsW4vEXrupbgo79HH4EJn+IUF4iL6cGsCW5zlUhc2oTiIq y9T/ABbN6XQKjzacOZw5chyCCFcYGOKdMJFjl2fkmBzno+Lq6mpxfLQ4Pnr6/Nn8aIGSg2Xw+QgF a7IQgsuz3BVlWZLj8XRSBu/ybHF8dLVaLhaL7XZ7cnICMEFESDpEERHmeX58fAogBajB0cYETANY w8xAM6enp63pxoHYMGcUY3Qr7xCprCr7/X6/2znnyLEw7X05ykYKvOxM6joBp9awjq43GNqK0w4j R8RVcEATxWLVZTnXGq/s0IF4FyMwvfdl6ff7fZZlwm693Xjv9x6YSdbbHU4RHwIFiQkzgyaRU0S1 3/lrB3vjEVbhlxwhJuEdsRPnfZZVgcqH481X/n2OBPFf8bysOhs3Yk2d0IU5yHANOP+ov5bEgJQq ZgQhP+yEJJAIO8QB2ZYDsRAFdiIi7PATdJGI23w1vgcyc2Wv9DElbDEExqvmI8EcNR3bw6s0FBcm j+t59NXV1eXlZZYXMAfTr0Xs5T0S3nIygcwM8xMcEq7NjWZfykDkIY03xpnzIZC7K3Zptly1j6C2 XjGgKUuoxXy/34NHaYwPVuN+50UOJ2z+9OlTqzxvbrNkjrQAN9FhP3EMDU1iqB5ijyV+A1BCQMSk OqSQesl111YjVESYXeIGqCYAb4pKNP1S9cSt/Dai3IDUop999tlHH32EYj/JPGjCLgAIbUfxxMcf f2zvV+/R4+NjKDaOj49Ho9Fms0Ggih4PLmYjRhZ27/3JyYmIvHr1iqKnpI50MplEWe3wc3Qg56qd 8Xi8Wi6t0ZraVmSoF6mBfqU1V4yrfAua3zwGwQ9jv98DrqGHAF4abQQfOlVEiRy0/yGEsqx5M3jv y33A/XR/InuonPUO2sHqLCN04zCxWNJYe97hqGdmhmzhTA4V3H9tD61CQu9PlBxdqKULwSQ/sd9+ 4MebGKfRVh2ttTUnaIOjDWuI3HU/Xa0bArjNWCz1KhYwJk5naYKi+0r09Jg0ZPcNOU2lRQN3WMCa bEnV6l1zNRqNVqvVZDK5urpaLBZaU+12iyGEsNlsrC/g/VJ1sNYvWpZOJi2WvREa+nhXCHzQgOp1 5QB5YrFDc/YAbjILa5J/TAohUJbZkSjT1xw+9isisrV27JFpCWxBTPirNnJIei3BS8iKfO/Lwxrk g3rDTpEX+ejjH/3o08+fnD1zWVH6KsbvwMTJCTl2uQ+hLMvNZuMDlV6WyzVzJuQsR8jznKOvQzEa IbQkz0cuy+eLUYbXT1XPJ9OC4kuczhbe+6Pj05cvX+bFOITAXki9KDAnVd6IaHoQHhVj51wxGk1n MyKaTCbT6Xy3233z7Qshlxdj51woPREJw9EuPZlIpNzvfaMoXTXbcWgxROgGdK3QqYS3tlqtFovF ZrNRUxdc5BQ2uUi73W4ymaxWK2Yej8dweSnLssjHQcogQcgFkSAsRD5iUBhTRCTEWQgDWN4QYhFm DsLEIQg75wJ5ZiZP5jyrVrVzzgchdnsJHASxsXmelz44Iedido5BfWMBeyCOL7T6qcS1I0RCjP88 I0cB+0oMILXAUJR1hEiYQ5T4/cEZ02AguIzUko8NDYK9Hfuut9M+M9U9bVAjIYWn+naqNXarfoab D0ii4axVw9Gz0az1GbRerxEzH2Jom20KnubJ1oZuOxH062ZcB13djQd2HUlUNCZjbMrirT+0/1RR 1h+MhESV5/ue2urR98NlCF3L5dI5d35+XrGUojCq6xsQ1Gk3/dVA8t5fXVyGEBaz2Wg0gk9hKzjT 4hUggAHE7wUpvamoRYdJrj577/NZIyYimLoS9mLzNt1PWJ0wyjycbd57L9xeRVeV/HoR86V5efvB rx1vYiYAE0FeQm2KY3gqvFbJ2PjRh9/+7d/+2c9+Bo1F6+PUmQOYBsZUvEurLHH19F/4Z5Zl0+nU DjaZc2ZGvg0cnHD1WK/XTeUTvkIyMSLCiXtycnJyfDydTpHqeHV59ebNGyLabDbj8RiHn3YPKbFt QOlms1mtVq2oP2GC94tZg4npyvP82bNnr169CiFgDaC482az2e/3uio0U/tkMsEqggKJiGAIs4J+ E4KHev1YqwboIot9e4ijuwC0d865PPJqfdfMFWDCQ3e7XZ5jC1TFn7Fub8raWjl1vxpDr1f8WrcS X/OTB6WuqY4jqmXguPvjEhkMbw3tuu7CC3enBGp4GaRmtosZ7+vi4oLyMRFBe4plZr3Nqvs5rXSj tnitJFVJw/7AS53LgWy0M6FKKXZws9XFfKOxYwN+/fXXn3/++evXrz/55BPsyqurK6mXL25uYf1n MI5K2+12W+4vLi7A0+I7PYig3vtPP/30yy+/JKI8z3/84x+/fv36o48++vbbbykqwj///HMi+vLL Lz///PN/+Zd/KYoC83l0dPTRRx/9zu/8zk3rlzHzarW60U+6qKkswPpZr9fL5fK7ly814RARrVYr F1Nr6nQ557bb7WazOWRnJiIiIQ/h3/pNzmYzooDT7f3796nxSV+DKgxwhWO4Qe1VNdiQr1fuuF+S hgIWi1VE6kmID19dazMLJvG5EpBsMK6OzfZbSSHw06fPj49Ps2wcglVvaChQRuSIXAhElO92mxDc 1dWV9564cKMpxTkMBhmEEIIrsvEsG40ky2tJV/mAuEVE2G393nPw7Dw7yot8Mg3bnQ81uDaZTNDh cVEdwEcnT4no7OyMmY9PTyHr+Gy3FRfIkcvxn2dPFPNQxoUBbEtEGvqRTE5i7LwF2gjkMIdcT7xZ Dco52OGns+lkMvHCbjSOM0+L0ychBFmusvGkmEyms9l6vfa7nStyDoGFiiw/Gk8wlunR8fHx8bff fvujz3/01VdfCbuS2BMLO89SEgtnIuI5QBMICR5hO6HugduYB9Zu9xALO3ZMggE7oig8cxBXbXAR R5Jn4liYObCUwWdMxE4kOHaOuZTAbUZb1+jAARxAncGVGpSY8JeUOTAFgccGdHVyeBNVKouDKu8w 6rqqpPoWBou0M2ZhNLNVtmzn/oAUc+Jynzx6d0redQiBHtiYosLP4dFtT+PuAKXdbrfdbt+8eeOc 25Ty/v17BOUdHR1ht+LkVp7f5QHQ1jkLs7o2eyUojkajo6OjKP/kCZ+HQHh+fv7tt9/W0I8I1Jbj 8fjVq1eTyeTFixfUhpLbOxhvAKw/HJ8tY6wpzn/xi18o+8Jn4A9t9quvvsLnf/7nf95utxD/sizb bDZAJNeviu7vrz3Ubkp4ucvl8uc///l3L19CvQEJbbfbwadQMx/qT2wLMSNQJYAlTgv4frPZLJfL PgEo1Au7698mYUIfWo4RkRDaNRxNSU7V5gr/8dkOofXMs4KyzoBW2dZ7+ruaZZkKzV33WN3+drvV sEypGw6UoVh0lXyrSxBPxJEPmx+0o7jZe2+1muPxeDQaLRaLjGvKhjzPp9Mp0H1RFMfHx7/61a8o RgPiuh0XnEWwXeE/ScarV/v5EEgUkcPqIKzXwcJgLtztdp9//vm//uu/hhDOzs7evXs3m80mk8l8 Ph+NRm/fvqWo/j09Pf3666/Pzs6+/fZb/LwaaePYO/DfOuZu5XS32ReCX4nKcBRdrLCBmRl/rRq/ cjmKMSvqO9z0IWj2KNFGtGZP0X102AuNzBOPT8Of/v0Fon64BJF0u9sT0dVmD9+v3W53fn4ORaDm rcH9rYBDomqz9i5qu6YPcHjvnzx5MhqN5vM5dWnTiaCePD8/b7aCTq5Wq67FAJkbltPDWERw/Afj 8E5EgalMLcLXlPrTBkUDuIz3UlmW6/V6Pp/v9/uPPvro2nZ62r/1b5Wa3ICiR8Fms3n//v27d+8m k0mlkMhzoA0Qkh/meW78NoiIAjQZfEhbVe9qpWeqAQ6pl8q06uKeYiVKcJx0bW6nD0pd7yCxF4JF 2mOVOzLo2dN0vV5rWSnoA10jNENTV8EnCI9IIlqjyb/EGaATq1bS5XKJeUPcSjBCnzMRnoEkkLg8 U95pZMhodGcSpl2535V7l7ntfjdbzN+ev0OznBnsyXTy5FS9kCAERRWZEEk+KjhzWTHa+7AX4mIE i0MIFEIZwp6IMiLNv4lFGepYmNrRhorubJhRax42vYfNzdU9WVZMp/PtbrfZbBZHJ9Pp9Pz8/MnZ sz/6oz9yzs3nc7UP/uv//JIo5CM3mS1cPspHk81um7HLxpM8z6dHbr1e74JwMVpud9l44tkdPTlb bzd7xNMyBZeFEDxL6bJAIYTgmUvniJyIBAqBYjHhZP3fwl4Lz092TFxFPpBQQHxKpSpgppw5UBYo gxojk0BCgYITl3NOwTvnnISqNo7ZKM11f/BMqjTzLVsDyo8ggZiEDwCLxMUCxBIqRVTbr6u/Xc4T UrvSUonjN9ROygN7GG8DcVZyFDQceTFiZvhdwZqgtayTRgA4uF6gG2eMysEAu6NiAklgt9uJ1CQo ZgaagTFX4bKrl56gOnsP9XABfa61aTY7nORLTawn0ua2jDuq+MTKeDrUeUIRuf6l6CgTQrAn6S3o WkH31oTZOD8/v7i6Iud2ZYnUs36/38aS4JVhhQjf1n7OtNqsrXOo9lZEglT+BsKUqwCtti579y1G CAXXXQbfT8mqsmJ306qiGcxg6+lQb7SoRiguTQ2BaaYn0c5AoFSPDXQQrycBKDZfiAVA0HZsNhvc 0BpgbD9zPdbG6qLQDrCLVoBkZsRiJI5d6nFtrK2H/ByQj5GJhIiOj493iRBj5kFRsI8exzZu6B6J YwwwEU0mk9FotN3tTk9PJ5PJkydPPvnkE+fcxx9//NGPfkRE66ur9+/fv3z5crFYzGazFy9ewGkJ jaxWK8sFyrK8uro6Pj6+uLgIIRwdHSGkxTEw5cFSLiZpJs7IEOl+B0uqH45BmC4GnjAfAKtjc2dE /4qPo3Gx9ylcs+snT9fPykTqksn3rOToJxnmN/Pvk0IIV1dXk+ksyzLPYTQaLZdLjaewxKhdxQet qvINsBGIv9A17vf73bbU9QnAYV8BIsW22wBHMRpmAXnz5g1wiYsRZLogW3/CMW4Zx0RSNQyfm7Zy T+ket4Gd2hn9nGhzNd4tsf7Q3RDDA20x66ajZnEduIZohOhcrNOlL4KIKsNr3Th6wHYQz7wnZBrF 87Qwsd5tf4bP125alfgfbXsDTcPHIjlNE7dEX09CjPEzswIOZ5xPQ8zwap1JbYOJhQUDj/ydzs/P Qwjk8nLviRw5F0LYlQicydlx/LGDROjyEeq7OueyrBBOrQ+B+OTkJB9NXD4K5LimGCByLngvJLDN B08kLs9GJC54cqOcxJX7wMyOzRThW85JyLGzuMtIow6rkDPHmaucgyq/AFU2oEwokBZXXwuTcAjB YYal/t9dVofwaDTKXH56elqxkmNGVviTk9PJZDKbzTabLV6uOLcty8vVqihGy+Vqu929fft2t9t9 9tlnX//i208//bREmpXMXVxcbjaby6v1+fsrgLNX373d7HcivC93RlPKIVRxsHFHRfwuIsS30Gc0 KaMgJCTi2CFDBLQURBw8VZbvjHN2IigZyiKESJCqxiU5L+zIkVS39bOrgHdX8TUjYtIBW4iQr7xH qCwDHRTssAyqO9RtNRzS6qLxG3oQsvgSnB+hQnAGJCOwWbaJN24N6K0yqve+jIXxmNm5nBrHbVmW yDRDUVfRqlPRxr3379+/h8DQtNjqZ+XhZLCmPZKsa6rKD7WBHIyHqqWQBG3bFhIooMe2pRAt3fRB kr41TRlQl6kOURH2deuJGbMM13KWQFgVEaHDGZrbX/Y4Cd8IQ9hAgEcgtWJgUTZhB8VNpTtHms5W Rv+m9hedbsXUSSmNRIGB3FlE9Pr161/+8pf/4X/5X3Hd4hj7c0shBvi0ppEZjUaotGSrrCWkrxrd CCEgC4jKxM0nXou4YTRF9IouRLQPaYZjydDWnyev4+7aDmaez+aj0ejJkycUxYjf+73f22w2r169 QmJmoIEX33zLeQZDD3goGAGcNv7mb/5mvjj+8ssvv/766zzPhSnP881mc3l5udvtVqsV+Fpg2m63 EqdCYj1YgzaSgQ8d4MDdZPiajaqo/CdCzCWqHpn4yw/jVqafockiIhQX9qHC7o+g52ib8wFRP7/u 6o07yniC3LvZIScvrBsiAkUpRauE2kYUTDQrfVZCWuxSj3pNhFerVZZlX3/99Y9//OMmZ5OYwhHv fbvdQpGsjCs52tV0axeJwg4lMUnom8upucYSXBLqPh9WLgU1mXwIodX7ZDg9aGYUOzSK3mB2CBUk bQyqn6XjV/Cjx8vNVXkuIsjnPaR/WI6hewYeU8lhqWmM6IFQ1M2JEu0ICIAmmOiVLtpsdqvVBlYY ibIjEZeld84GrbFzWZ4XzmWz2Rxxm8zpc7MsK4rRZDKNSceZaioCY+ZkIqLxbFpMDlYtTzJdzAMf 6jbpdXHsSVAJtvnqwWKQNEwr9KaxbRG8a2RsWS9to0AKDi53XBXOudlsdnZ2VpbleDy+Wi2vllev X78ej8fe+zdv3kwmk/F4DEGtlFAUxb/927/94he/CCG8ffv26uoKLlGbzWa52iCCd7PZhGgWoRj5 VsWD+VJEPBMRRdtaPGsNzzpszuh5YJ142uW27rOZWSNLgnJt5xwTxzgLPFRYiIm8iBNHVCUDCUGy TF1kHJEb5A9hlRo1EvMfEZFI8F4qaCU2aDAG4LQ7FlL6bVR3RXeRQXovEZRlEcthTKjwrzmwuF9S 3oiDQZW+bEL/DlJs3blH13aIyaCUIuBwckh1kz4al8rSO+cg+sN/s4tdo0tN5YHiIZAyMTFwJ3mu NNzeE/KmyrEyMb2SwBGLv5vt2M8QaZIcV119aP0CHbs7C7X/TPT0m+1qMh3t9yU7QdRJ5dzHgZhN nJcQB5fFiLkGBSmJyWUkcvBIZOY0Vcu1WVqtksCq2oYN9nsm5LHG5x5oZtUzWN8aFqvLLln3qv/I 8zzLHDx+EVkERlyVrY+bGT9BZ8bj8fPnz/GT+XyOwxvvAndqNjaNj7+W7OjQSFPndC24DDFJfAhh MploWI3tA76tzC7GAdkqgSiiDTIbfsgoqM2nej6fgxvCVcV7/+7dO3z19u3bV69eqTv6zpdHR0df ffXVd999B6drpP+6vLwkouVqs16vK8OkVLie4sbDYJECqKzgSK1Kqjfx/YfOxaPd8kF3k6qtlfiF PR5T0hnVY80GoRTlEiEiKb0u1yolw8PsTpHKUAMmWEkz9+3FInVbeOTXdR14ldShUyE/5CkShNpE 5GunLxFdvi9Z6y5UCbjRfBZiUiU95vU2hYvqoWWZYQ0CSqUjCSEURZbIx1IlaT28XN9I3kXmlAEj ah7tuK7P1W+b7E75D/dm0Nrv9z54JGXW3GXO1Ti/HYimrJDouGbN7kQ1VKcMpx/xPAR1qXOUfKx7 RTHFlLKX1vtb07hZLNW6C3LMvuKM1jehM9hlc4mKuIpNEnOQ0rE7COv35HPezB9gu+PYtSJDRjBt pTWqfKHRVDIlbJZC2JdX7y8oSMZOfPD70jmHDIsUhFFksvKZCCwUfOCMFrP5KK9CySE9R2fSNECZ jKnl7OwMecrLslytVldXV3q6WwTac073ZArBr2azWasFMYRQtkWHhBAcMAeRy7KiKM7Ozr5ZrrIs Y3MP2LOewd57V8nfNf9cVW8ARTWUOO0U7QWiutayLC8vL51zxXgEkejly5ez2QyYY7/fq2+sc66U kOf569evLy4udrsdAo81gmZfmqRAJBTD8dUMJCIBaY4oRyeQclRIfPA+kHMuSKhppFR6J/JxKaJQ anNoPaPO+KABzlhEQuYyin4zHDP3gRt4H6QMRFRU37r1ZsfM4/GYuZxM8jBguuXwoa5MJtH/6KDr qCYBuUGZuSwr2esWuVYPTKp+ER4zCcMJgbwP1omPK5fAWlMNbAelYKonj986ESaRICIBibOQ3kYY XgtMnogZ912PYyRqNQOJY6cTaH/WANIH5587opUm0zc4IZeuhhcAACAASURBVL2t5wQCfAwmTYAF f5h2CkIHfkASo6vLEJjhpOmIuIv1oV84PiC9N/rgsPf3+31ZBhH2XpJG8GS9CMgInoE2oOdD4Snn chEJCCojxHw520gIJMLoHTLgiMh+XwJSS92PQUxop/3QNaXgQl3f9tM+RovQw0j4PuyJg/d7EchU Hjr9uIR8dEknInKuLlpY/ShXmk4sHuvnTgAc0PzfVHS2e7vLpeCGQ34M0m2G+WqO2mLPi4sLJKYd 4u5A5mQF+js/P18sFlA5dqmOdDPDMQImA2TjxrcWAt7RByLJfAo53sLNhADe8dDpdKrKHjFRUn5f gRj1Z9ZdoZJ9VKse/iltirgm76v9JIry7969y/N8V+5fvXrlvV8ul+gqdvJ2u10sFpW/BZMYJzjN SAZUIZT6jpEJNgkxRanCkWbf+jsvbZGlAynEgvJ5njvXt5UqSZGY1JcidsQ5x8bD6e77sW2MYudQ ROhWT6mwUwPyEqUSjlSZdQ5XrNaw2exAtiZI0x+lWKo4Q4vVNdFnJNdTakR4PihXTN7FcNVWqzxq tQvaZusasP/Qj/0jtdsndMclhOiqz9HxomwUoFDSpM9oZzQaqcUTNzQZXQ9XbyDdmm0FZN0qrz0g RARJ1ehWGo47+nD0IEuqrxyrg09iVy21DqHytagnorU/zxXG9uxM6z5pG6KDbqN2MzWPRpvj7w7a jhbfowECFUtt5wVTHjaUvihGB3mISHyAy34IfrNa46xq1fXpZxddbgmVz/Icvg5XV1cx3DyP00JE EuFhJS46x0TsHOd5VpZ7vRiCd471thA8c9+60TdoDZmtnVeCQiWppkvGZoT1VxQFMk9C0SqElBOh LMvc6AzUxBjDWEiIEN5SXTGvQdm69lZjmJN7FHUB01xeLff7/eXl5cuXL3GRMkfRIFiWJefZdrtF IjKrsMUaVq1s5B0I60KUHTuXey8h0Gg0qQYgQgcNgdO3Y6Q9jpOd7JG7AI4AHM8SiKDwgIRddYqI OOZdJVXnYhrjYi6Dd965smTnSu+bFRxa/YBSPktCfHDiCCKV6wW+itqsw5l0g1HGnCLksLwt4AjQ o9SnVFTO4uwgeRMzORIyPi5EhxO0Un0wsYri3P4hWjwr92sm4aqYDVNGTCKe9Lv0aFSNVO1KLDoj lYrF7oHEE4vurNq4GdXPmMN1taRYGKfIA3sQ6oKqkcrWh6VYOZneQjRKngjy3mviA9V3dh3Vzdw/ wNlNxbzEJJC6brv7hcVJROx9ac87/VWXD0fyRLuY72JPudkmG0ZWj97zlMSh57DaVbPbAAnW4EUI ix0yAE3lmUx3E8YmOa+6KIG0/X0YKBa04vTkcU3SU43istA51ZogRVEke6/plpxlmUap4MUg2MEa pOyI7ETpWSgx4Yx6BYOLJW+6Sa07XH9i839YguPIZDKBl4b9lf4W2UjXqyuq4wMQIql8rNlD0QGN jAGuOQOqurBhLFKVY001LnC8gLplu90K8du3b9+/f3/YvWW151GbcbVadTmEq2croIZEbwBrCLCF AO5Cd+MLlcykPKpLBkXu3eBDWZajcVq7B9NSmhLqVh+pzTnXtFVW7QMEhOhOy9G1MLlNsabvNfz1 zEkCVqRhAk9Ytj0UzVnVqUUQEe+DbnNU8biWLRARV/WbanhCX4e98oPzaWul5vFsVeLK3yi+Anun lna7RSomfaH2ItaVSrzee2sXTp5eKe0jEkq+TbjKtUd+3H0VxoKIqItNbyhNGakeEpXWbsUW7oUj DSHddPflYpI4Teb2McMpz3NETt99IoZAjTtiun42B09SOD/GTJrVsri8vNRhKp8NMYdJk3RNI0cv xSyc1Jio1thdPemhRUT6HVhnULBt+JDtC23agxTXAy4gEbtuG/2LeSiKIoRAMkXxNq0iCCsG7/dI 2OdNFV/dlpCqE1OOSOWgh2EqKMETkWcM7wUd2Gw2cGJHbmMfJPHbgmsn3hQqNHbhdDu00vsQQpYV lsO66+JoVLsrsbywFZXukcToaZ1zWZVk/XCD5owFKijLUsZEMVLJRZgi0auuqYykaHbJ87wfcGhn mnDTguMQgkRE0soZumZJ+JB5LCRXtANMPoR6FR0SOrhZEGmgjBBVKXq9HLJBiEiIKdFiRolDz4hi shMhMt7KrnJeqXB/osNQW5WFdK1j/PBJe240si0v0U6Ccy6QOOeSiEWdE53GBE/oriezgxIVkW0B BMHJ10qf17pknREt6NG6URRTsA+xknPdOtDKTGjw6Zn45N2UHgdzKCdPwn9uR2pPOVi18L/hg7HG +F8PkuiGrWiaog/mu3fvrq6ueuwpIabSU26uCIOijmSz2SBFVU8EEEdv8PV6HWLYLRqfTCbT6XQ2 m6G+yZCZxw93u10SWdOjBekiJDlWqULVEjCjlGXJZVmWpaIQlTWbWg1ogCqjGB/YDX44Go0QiQoh Bmkz8AGAY7vdwlxVNtL1l3Jwogz1AKIeHKDcLcRjzPanlVwjm21THLxfCpU/nceJmLOzTNy5Q1ha c3WJCDFjIdnlZ/dvCCHrdUbRxdMlxlmQmvT8dnr1iCTMlbZH6BpT/Ed0MN3qUVHXQxzCPrkbHNgZ JiKE7XohWArqk1+9oASF3HTUd6H7Qjnaglo2m15KzGxPcTHe3GpQtrhWARmoeXCotliD+JJeAcu6 jFWd0Oo6oFpVu86t6wYytVuQ0ROoQlERGNoKp0ukaxux1AQuN+IbOHbvS+vQQ3iEFv61HaC4SFpd N/BBDzL9p24WTOk1QbBd7fZrTblXV0mDJ/rRhAY9yJNxXV1dwaN2MpnAOVHvT1oIMdOoRlLp9VYN R0L4drfbaTy67g04WCwWi2uHYP+piTEA5/uDj5IrSf+dc6PRaLtZ2b2K+K4QgpRlaQodKbvBlCKx uvaQmTPnnHPWGQfBwwAcWo4BOGO9XkN9YknVCQqnbHXHLikkudJlRLiWEnXIg7IAHWwIwTuXZZmw MHPOLssy2A849mQ0GiHTqCCLP1OQAAE0i54WihfJ2FaCSFdoCfQKiT5J3wIZbZ8YPbPeaReYtnD4 EH19AgkWEEYUYjgM0aF6S8t75CqYWXUSRNT0m7GiNnGND9axSPoT86uSiFwgrgJYqnnjwFmWORLn HBOjPC/8O9AAM/VIiHZEt+ZvOu0DRZEeyvOcOeeolUyYgy6eZHKcc1Tl1a+i36t8gMwQMLLskKgQ OCZBM7vdDiyC20wqIpJljqSy6fd7S/ScO/g50mDsdrueuXLOZcQSNaZU1wc3lTRDyKpzbkoK3IE5 btHCEGoeH8kNKowN0dPYiiJ6EQumr1psk3CsWiH+14b0PLMTsl6vtSRK/88T/gsCph6umHLRO7KM xWnzPJ/NZsfHx0OWmvYhxIyo6/Ua9ecSvVbrS8ehRQbrKCVDgGsLumrvVHZgg+AT5qWbB8KQpn45 PT19+/ZtWZbL5RL1kZfLpVbQpXi6W+3RwW5y7dTcH1mTSrhzNaZrCc/RxzlMJjs93Yvc5XkuZXXq l2WZdxiGlHMlR1SX6oKiviFBGKZjYv9JjWOvFe3pQ5Prh8ajDaWVrpuwPj7IrqnzoORKCwrhkogy YU1NkThF2kFdm8fo3unuUAOU57lzBY4KDCTBjsC+duAQJyo7nzhFFS4GwGdZNh5PEsBhCXdqyodW 8CfRaRv3NAGHlaH7xwiXNWpjcXYeSIJ9lkXStp9DhA2JthtnnPCGIxVL7jo3vrsTMKL+s2uAw21D 9o2j24O2B2zAWDc2CUzrza1A9fulgW8IS0GZMlJLwcWBjf8mNbQ4ym1haMBOiwA/48HZkDSxOpnI F+TYBvWbRayaAVsL7pZisn+Cmuochc8QUBT6WL207tIyFgWwx4CIAIwmfWsFHKNRQRF2ENHp6enn n3/+9u3bb775Bl2Fi2hz3sqyFHrYFNra29a3lthQmhrXB6JqnpmZWUj2+/1odKhnMZvNyrLcrTeU BBxypQFgIjcsCKIJBaSee+DQeH1+QsNHxC5Xe4CBlVeRTtV/4pHNRm9ogxwD+ty70XxirqnBi9hV sV8RUVbNeemlEh68BHg5MAlJgHqDSRxzoKryDRE1En+0d/uOrPK+fj4ajUrK4CuWTDX243g8TiQW MEkmyfO8NfYwyzKk/VUm0ARkHBOog7s2l5/3Po+1pZqOBT3Db46iuWKbv4JSC/3UEMW7bHHLTzAb 0lZq9NqfP7Q+FadV1yOSYz0Js08S3h+uN/ZszqaAiP3CDg/HT5WyKZ49XW/6Q0MbXdR1eENxVxQF sm+t1+sE7FtKFg2O4cVi4Zw7OTmBy2dRFNcaRKiONkL0G0VTXaizVUwk48oHraBmpGmOHRk57VfJ e09+ZTFNdbN5175eOSVxF//iiy+I6LuXr/I8V6daUJZlH3/88fPnz//u7/7OR5K2cosiEh6sNmni w6EG5uSG75Gi1BWcc7tdVXARJmrrbNRasVklNmxn1DEYqKe9lj+at1NZuxS4TyaT09PT0Wj03Xff iUmUtC+r4ORDC3xoRyjWw7sObVgKN9V2Qdddt6nXrDBU5d90XOlgOLrHUlRp4E4sWhdz9jRjvL8v 4ugt29UfvCPn3CgfwWs+YeAaOJa8hSiFRktSJExCURRwumJDzacjcdF+v4f7WvJtFKYrAQ9+6/3j bT2Azs/Pi6JI9JE9R0Aljue5dMRrWAhueWYrp1VZDkcJcMxwUo3CrbUjQwhvKkQ7ftONI1Fe1pR8 Aw78akqn02mrhsSefNDtowe6aluX7wNBjeYs3+5B2g4iIGLtmIMDHWi32y2XSzgn+oNb+0H/3ERd WKP7/b4oiul0+p//83/+kz/5k2I8zbJsPp9fy9ZdJDL2syzLYExJDkIlfWVIS6rWCmggrOldwYfy guYuUlyFdgBElsul8vAQAqq42Z7Yz61LAoDpT/7kT6bT6dnZmfyHMB6PT5+cFEUxmUwUeeR5vl6v /+Iv/gLPVS2rbSpRKX0I5GJwzWM+VKq00FyWZeaqfHF5np+dnG42m+XFRRKbGphEDvkiHVFJIXPE uUMCTWFSP5hkakWqr/BXvyy9F6qyYgRK3WiEae+RmTfMFvMfffZplmXzo8U333yDCGeXZ+J9IPEs W78vJQQ+qMpExMN1mkRQjGHYdr/dulCjPDNnElFI3NsMkEFMhDLrLMJlGRAu670455gr3ftuVzJz URTjsaufwofJqT/6MWQzAMEuwJHn+XQ6BXZoBRzgDFa3p77kk8nE+nBYsozC2vKaBB8OX0WN1ToJ 530FqZvN5ujoKLmhtU37LBsWfiPC07twiX1WTG+aWnySH+Z5rsD0pp0Zbk+59aLimE1VtU2uHkXY 9YhDfaS6zVRvE5HKVAeTWxOX6QeF7Wp3x1cfCH6/EVkcCnBgsTlH2zxm5/Xr11htiR9oa7Oqn9hs Np988snz588/+ugjzor1ej1EiFSsQMaoURSFfu7vAHy1tDMhVlOjhuFTNWMhetdzR4YcPHQ2m+3W G4urqMM3W1vWsUgssfHxxx//9Kc/RVk1vy+fPHmy2a6n06nawsfjcVmWv//7v79arTDq7XbbusBE KkfJx8ccqgs1PSFqUyA9Wn/KshwVmfrTMPPJycnq8lIjU8Bqt9vtfD7HP6Ebt/rtW3rPdhD46X6/ XywWm83m7Ozs937v9yaTyX6/32w2kKI0OSyGUJbl3kRVYrmGCGWI0mzr905N/Mwm8oVFcFqxE5yI YlJwHm5j1m2VZVnl+xXDNBL1yX3RwNZEhLot3dUycA7Iq0tssL/FexyPx8zRRbaOrbhO2kjXEEII KF+SbCX1BrPpLoaf1pZxJepSe5raM9L+kKus+eJ9y7zZ0zS52HzdYOOaxGxg/x+f8Bbs+pfoP9C1 2FqBCHc4EuTz+Rw5GVvFVjZ5SPFBv2qt3fJDIQCpeAwffI4kJhUIIVxeXqolz64bq5dDDItt1jn3 xRdffPzxx3me731oZpFqXW3w61RoiQ7oDK/Xa4hN2oeeoWFlTyYTizl0/1BkFlB4EtF4PB6Px8oW pWGogypiNBoBIliBg4g8SWDCf/uyHI/HSKhsV+2PfvQjxKF89tlnX3/1iyzLnj59qhomiUE0V1dX q9VqOp0G42PVpEferiJSHXhcGbMxReqKO9yHY3i/mzs7kRgo6jmwXN+9e1cUxbNnz8qy/Oyzz/7h H/5BzVuK4T7++ONXr17t93tNtF/p/+9wAupr0jWpirTJZHL69GyxWFCRUZE5RzvxJcvW772j1Wq1 90FEttu991KVnYs9CRLjSWIWV/PMfmXSXY5zESFA6dycCoEoI86ExBOzSKXXDFEpyaHKJyYcE8Lu 2VPhdlJmRc1x4RZH5k1pOKBRKMDqBhtjF2/0IG4DHPYRaLOpOLE/15O4+XTlBvDuWq1WiYVaW+7h DOAwSdQuDfPByvN8t6vu1EmzDMpOhWKmhH0Bxt3u0FS7zIO6i3EMYWPmPM8Tu0/z3VmQMLz4Q27n qIdwQ1lPU/qDIDs0azyCFpGIEokZF2ezmWrSLKqoI5VD/DeoLMujo6Of/exnp6enuHIjr3VAOqgr 8IFjHgWKewYZuppD05eoyisY+LFSFffobgHgcM6Nx2MYfZqbVkQmk4kbVx+m0+l4PIabN6Ih7P12 B6rqAqvr3bt3OKe/+eYbSLqr9RI7UOfWOYeYFFXJ2GHWhzx0Bfav6mv1Rq2toTPqUdsK0x+BRIQj AGLmUkh1RYVzRVFAgYdEbUhCQDH9EXKZaA7cpvNW8iBq7A79IBKY2cc8tohthtNSURTPnz//4z/+ 481uu16vEWFORNDHYOoUZwPVpdach5i4YWRnxFVGIhgOKkdQe65Y+U+nCwt4H+uWJeoBaRg4Hoiv YpLzPBfz4uzehLwBh0GJsMCqJfqJmR0G0uY06gy1ttk8qpubyHI2Ikoy9FvvxSxW27BhRBZXJQe2 hh1R3fOD4z85Kn2twKk3Z/UqIaDmFd0aZUe653661qBzX4QxwpZtn2jXQ6sygw5Gyc5mlfLJZNKs X9elP2mKWR8stXJ/7X//K5zNZvBy0PJd6tEiMT67CWNxrjPzYrGAkcLLDQ6k9Xq9XC6x5bIsW6/X k8nkxYsX8GkAa5hMJqb8bI2s5UV9U/K8gHIahRN138KVdTab5XkGvQUZUUPbhPMsBzk6OhqP8ul0 Wu72b9++/Z//+s+73Q62Wwvz1Z+Lo1ETn9+9exdCuLq6KorizXevLy8vnz1/igJ16mjy7t27L7/8 UtUnFnO0siE7pfd1MrXubdVwaPFu26uBIOOBzk44oHnvS3ZwPDo9Pc1Ho9FoVOQ5DHzHx8fMPJ1O ATUgY8Fzy8WSjUAATQQGXo9VnUg8GDszA4KDSUHHzsx/+Id/+F/+y38JTFdXV9v97ssvvzw/P99s NkJUel96H0QQn+JRm5JJhHycp+8JahzYmnU+rXKrQTNBxMSuqkRazYBOxeHnEYXsQoBUnbi+3aN6 uIsbi4jYWiEx6F3fO0JIQBBqg8v0lNXGu9o/nEPdPhwU1Q9dICbBrz0EJgz/aMujLNqwnU8aTP4p Runb0qt4Ruj7dTGzCJjnjcRIjnpluHLfOnD6XlJ/9hCb4sCKzEI9lr5zsXW/vYSjHjSr99Tth6Lk oL2jNJnMQmIWISKUF0l+JTFzvn0fzUZgFCCipl90F4nIcrmEwGd3AnKP4p48z5fL5Wg0gsjShB16 AGCrzOfzi4uLoiiwT9QEQNEvfbFYjEYFvMS7ekVx+00mk+fPnzvir776ar/f7/f70Xg0Go1WEcOp TMDENj8SpuuXv/xllZlUKM/zd+dvccPr168vLy8vLi6++eab169f64nVBXmHU/8KEREfrtdPtkow idD/mIqN2AEiohDEOUcm//fl5eXJyQkzP3nyhIk2m81//a//9Re/+MUnn3yisY6/+tWv0I6PhXZD CJqxPsnxRcbdz1rTlSs5492lkPd3fud3/vzP//z09PT4yenf/M3fENGXX35J1ZwHOhTSO4yoNsCH mbf7Ijn4Q3TeE2IwOdMBPeOK+iJYob+fm99Ln0NkWUieoQF0FY3GzMwu0/fYBRGU9J7qsGnTcCgC uFbD0fPEYELqgJvttxZnADZxzDmGO7mhwLAda7qpEhFT5ZTtYg2X+Xye5zlRaOVLKrBlbTWZFdZr rgQenCjh8UlM4S2JpS6dc1p610qnh1+1LZNWxpjDSUQnXaIDvD2c7nNANycfy4Mtl0vAW7VphbZa X0OoPqhDNV78GzAWFUf1pjzPkdmCOg4b5xxc8/Q63hyU262wUQlJNhVwWKddbU01KyBdAXai9ENk YZTnWVkKBDIAWKqWvnOuL9s6GWVmlmVMzMy/9Vu/tVqtVI+ih5CzmQSpYjHaTlmWb9++ff36tXMu Y+ecI646gypr5+fneMWatgTOIj19s9S6svtxQAhB5FDuS4ytxP7QcgVNqSlSi9gc2MlHIPQqiHzx xRdPTk/Pzs6eP3/+ySef/Nmf/RkQ51/91V9hVWO9AVVjiYIPaJwtESEVSvMM0Deb5zkJ6wYE7JhM Jl988cUnn3zyxRdfZKPif/yP//FP//RPiC0nqDcOhYWdTmOXleyh3UXvRq5SedQ/i6gXqmRO1JVK +TX4OPavTi82ZBKLeEfeq7gnadNmCVLZ3TlH+Qino5V5XLfvxRDAkeeFYo6erkpUGLcmB9PWJpNJ ohxCH9TtXRkacJUOAY+wwjrqcbYaEJlJYg63KH+ORGS/3/bvd02clcyYWnnQpZ50F98vuRjUjX/q ZzbVKlxM01BL1kCHWhyJa0syYzlCMHSFgZm66L77IcyL9x6d1IM2uQESf+vwutZHfZ2172pYs4gI PvbNXlGMQdU3gT68evWKqumu1ICtShG8XSTwvrq6SvK36pIN9YzUgJxQzWGDNd+Riw6waj6EhBq3 E2PrqjRD9R2SYM2KnwQREZcXi8VCMS/2T4L5HFdtan6I3W73L//yL8gpQlkeQrCpzTG3m80GMbfI tNb6RhLqermJBqL1ThEB0BQJZFToiQIjRJOK9z5IUBfX5iMeh+JziYzdVLuBvPiz8fj4+Pj58+fP nj1DptrJZALH8J/+9Kd/+7d/S0Rw41DgSAm4ZHYx8xs1NKAukogEL7PZbFfudQFoqLNz7sWLF/v9 frVaHdLEESETHRHtS99EbB8yvrgRJZIDyO7K5XKJ0302m2HCZ7PZ1dVV8ydDHpdKnHBnDr6JGHDg YfuPx2MYCHBRnFMI4owD6S0AB0d7Cqw3/WiDotKLO7wJOWqGmj74SlmWQVmrqg7bT/uBzItQrKx6 CBEpJYQQ1MGIiCB6TCYj+3b0iLXiViuFWMxoNpthCMMP1lZI1E84EAe2b+eEmTVkN5i4VD0mskgW QapF1ULqrg7nzRBHxWit5gAe7MZ8vwTxVyMAtTNdvld6uF7bcusb9N5fXl5eXV0REawY9tsQK1zY mDeF55DXN5vNerufTqfn5+cnJyfJCvPeQ1+yXC4TtIEXbD2xsRW16AB+S0STyUTRGBntt4gAJOnw 9StFG2A02FE9a1p3XPXenaj2bDabAQNZhY1zzkUHRt1XIWY+nUwmzfISIQTUZkvmZ9i7Q+faO08G QLQOEF8KMj203S/m4veONq6l3W53cXExe/7R0dHxdrMr9z5z+ZPTMya3Wq6Z+Z/+8f8j4XLvd9v9 Zr0djUbQUsT/YkPCwYvjDMVKcMWqTZ1zxCwkLqc8z2fuAI7Pzs6gzPv7v//7UioP6xBC5Z8UAbf3 3ksmJoMWDUUbd2c+NxOignlk6H38tTxHGQW2sFYSwGFZliUUqxT3VFO91EUHvnfdncAZgBpQUmp6 LjL6APu3vw9Zt9NoURRFcfDrosbxqWTV+M1BKY9VwbJ5DxQ2eZ6r6tf+beppVFOS+GSISMYHbXHc 7EilWCuQ3hxL10RlJt27BqXfiKwTYdfT9c5EZrtWt6RvGcsv0WeQOThUT2NbyPM8a3DgLvaYr9fr 2Wxmh9H0S7BqliFL8L5IosEMUIPriSI0iTiZTBhKrQqPVmqOBYCaiL777rvdbmfTYmoeGDtLeuKi D1dXV99+++18Pt97efv2La6g5wr20cJqtSrL8urqStUPrf2haE7TkcKnFc/ViAlMiK4bQOlkA+O3 iaDQoypQhsd0wFVW9uWoz9SeK+CwPbQSc+uDlKG4AfVXJVKz/9ciDL3HV96OTFRLXFP7ITY5H2xt HyDOUNKyuqvVaj6d4Tj/8ssvnzx5grPtH//xH3GbrhYg3a6UJ1bWsQOHB5yLKQFdnsGjCF7Dm83m r//6r09PT9e77V//9V+fn5/r+9obi1Wox/h48kPAhNwQLoD4HmDKvZGKB4q9iqJYr9dZls3ncygF EcncBBzXM95GOExiwGXm6XQKkQNvbTQaZXnhnAuusLqNpnbkpmTl4H6CurQpLVA8cSD9NsVd9BDD gQeYKjkUcKhOLnkoG1uMvQjNkN0UML8CcAAd3mQaaoQ9cjs2Aitn19OxnLTeOC72v8Fgspfi7ACv VnnPzhugBnIoJO30ZxqtsQ5tS6LTnw2JtqIzGcw4cBW2T+vguVaoBV0ZM+/3ZQhq6+E8L4hYXRsH NttPFkmsVitd9Krk0GnBuwEUUBgBKPDixYvT09OLq9WTJ0+sZlI/I09fCAFKVNQw61G1cbSq4EPi 5EEGB4gILB1i0nDp6oE0Y5dszyHKxqRSVb4U51zVz4uLi+l0mo9HpYToqY75YRW0ynLvHIfgqSoF KsQ1g70VaxRH90uKIuHQGhppAI4azIJnkoEUla7ClxK/qCCFuGQVCVPrKdgJ0Vqv3pzEPJT1D1Ej YBOAgPBy8jzb7bYkYbtZk4Svf/kLInr69On/9X//n5988klRFC9e/kqZkcs4iIcvoQ9lLX2ZOs8w hRDw8CCH9IhBPLEECSFInudZkR8dHUHuAdh9+fLl6TcI9gAAIABJREFUX/7lX7568/rNmzcJmNN3 EUiEBH89iZAb5rFxF+hwPwZiaWM2YiJjdekGSs8GJiZxIXDGWRnynEa70slWJpNcOAs0mkwmCxmJ SOUxxrU5Ye4bPjMHw6JDtJGR8SBxzsHKhoO2codkR0Sc4beSZY4ZG/l6Vl9xho67mlFfrbdBU8ws zXckIs5lRIEoFEWWZaxrQLGCi3E34KL2hFKuW7FQPvAZZg6ESog17Yvz5L3PahJsvtlshPLJdOa9 z/KWOMFO4oPqmhy7PCPHQ3KBJ+TqXoA9dybfJv+0wCuEMJ1OK4snETGvt5tKm+m4LMtRnqGrzMyZ c3lWjEdZPZfdEMLN3vuDiw03wqCBsm2PFXA8aHxOQjjU8RcmpaYz1L1rXDBwuKlCUEgMTPruS1MX Tb3tYCtxripmBgWGnbQQ89ioA4QNCk+Io/9zGUs/wwu1Gdht3XEU6VN839Z5+xYUQthuNnBtwWxA eFJHcY4WiOYPu9pM+p+bej33oktoKD9qiETUk6OqeNlQjcT+i6G79+qBCEBwv9+/ePFCs7lAp/Xz n//88vISA0nYK/W+IMXW0sjgrmsVqxGHGZQfr169QhxsCEH44G+L++NEPmwRvsckafgfDOFIsIfi twhAQ962s7MzOFOLiGvEVvS3aW+weikwH6j08zyfz+c4oatgN3ZE5KP3lTmRXWvLySN7OjPcfNA8 gFQaUbYWzR8HAVhdjhRqUFTlaodr2tw64FBWY8MmxCQhVUK4n0YA3ODEiZBRfebucnoOcf64hcnG /haR9qprUJFbWf3AE6Spr2Lm2i9dw1cU8rq+xeHjkTuHNSaUx2IuGDkSRg0f/HBC+yGE9XqdpILw 9TpeqmzQPiQWH+FKn4llutvtrH0RU4QY2hAzIuO3CZZSGUXda1rnVjk+GzOHRDsOR7/RluXOfYu4 2i9BQihD6bfrFd4FR3dRvAuJER/9yyPZq6PRCMGZduA959AtYHXrxcNfEREJcFZo3B6YRARFRn1b 9drHpspS3tcNzCdSzeZ5/t133ymnsGj1plwpcWqm6jjMKKq79azy3n/99ddXV1eb7QYHyLVA7aFx R4WEa3ViazfcRuS8M0G1qb5WYC+73W5SjObzeYjZvm/XOEefDPVYJMNM4NCthx+0jpxVHpRGaBlw NHYrXYZ3Xhek/YkedVlMJx/lpRRwgMVp6I22A1Zpc4X5KK8n/bRXWkwGMUAU+mO6zlRRn4WDrdyZ IKDvi0IjRtIqFIqi2Gw29pBS5X0eq6D3DKGVq+jNIpKe1hr1oAKN5U3qynQXDHVryvMca8M5h4Sb D9cN59ybN28o+vO3BoO0km7pEALHpc/GXx3JuxJHmel0mjRiW9NXYMGmi/b1OvY/6E4tOnHG//wu 07JarSjC0Ldv356dnd3oDG7enLxBvommbsjNB6m6oeGwAjfyQ7ToZphERLiq0PaDkMih91qtVnme X1xc4NxyMSRP6/bdYu+Eer3K7XY7m84vLi4Wx0er1ero6Ag2ZoD1sixRIhFHeevsfeAaox5qgn67 nAaKZPrXak+32y3NF8B2WZalwOg6tW5oO0ozw4isDuDg/ceOmX2EDmqVYL4ecEi3ketGJ0VTS6TX Qyz8FJ0Wa46o+lXrhCiOqXrCNWfSpLf2pdgP6AASNEg0+Hax0/QiH65jGz6mfaCVWpk2pjHP89Vq pfkdrJZBZRX7E/1g1kzfEVMDHAoPoehr2n7uXZ3wIdO7d+9gT2lCQku+XpOdoma7LMsiO3jz6svI YhourGDFB63B2Rr7qo3oI/QedbbSv/A8tyvALvGWBXGdXz1ot9sxMwJkkvFaj4omtc5eXi9Oexdq SkWWJEZAtJ5ukF0qv5I2kwpQyvev2xhAOpPQRoxGI8Qkw9FsPp/jgOlfz/2kOj/Ei11cXCDnLLTN 6iMM2FGFqLQtjB8c1MDrv0f5RnXJWSxTRUTe+/Pzc7/bn5ycQKHbNGc3pXP72aYwJ+O5VfXf+MMp tyciIXbOAXbYZw1zjOszqQyXcLg73Z9eRJYyXb2t/LCrcdx28EjoeJDFPXoPlr03lcPV8tLTW/23 XrR2nw+BnPFH5JjMOlFkJnPVHDKbPCutyiH7z0NuEzLJU9V+cXdqm9z7me4H1bJARsTmBPt2HR6d vl5VWeNQ9EXqV1YtYe/RJWg3UmvEuSKPpCcqwYSYIO8+5iAlLESVvbDl4CiQDVG9NuId7thPXVpd R1frqdaq4eiCXPG+H8zRiKML2gWAWoRZiogmwG0leM/oP1tDinTeNP18nuXItDEej1+9enV6eooY b4grqittbUo7MzA+5deSLB/AUffu3btyuwN6Y2a7sfQghKDcvuyNgSMxEwFtAGcg6v6gOgVPdk2x 5K6AY+BXwSR76KGue3Ao9v883lM7Plt1Kk1S/IH8k5qz4KbQAQLkhwM4KGrXsAJPTk4Wi4XlEqGe hKOrkQSnNhGhfs5xZqiVS4Pl7jgMfVLSywetd3eP5Jy7vLwEAwWS7VrNCRDJ87zKcFXnqlZAUa2D /tUyB/bm1mclH6iRXt3izfsl55z3VSzMs2fPwm4rIi7j7W5f5LW33Go6CZHurlEcyCZATQ2H1OiO ffmAKISg4YXb7RasxG7nVsDh6l79II6R4a1LMZm+six3ux3irTabDcIrfig7/SHopieKxvxDvIEV jK4r/ZhgxPjsTsABAqtveINVGo7mUAZ0vxOsp/d1T4uyheY9VtlwR7bmnENeQntxyEJNfnI7JnYX 3UYXw78vwiSgwJYmYdPeWr2OfqY6zugiq4XKsqxK/YSwTM3ucLtOJ4/vVo5dP+ku5spsdIbtRCSP vl+CoKZZv+B+TzFvj+2q/RVKqnbBbTWmiIlYG44PWm9LYIrKQF2GuiEPaiXV2RDsOFRpFA8LlIjq /sIag2P1kNrCXZDHjTDHvxOypm471cj0QCZ9kP4Ea6+5KpD5Rh0vLK9R9UZZlkhtXoxHIoJMEtB/ 7Pf7pofpQw//+6WEOw//YTIzInJ1daU+WAMf2n6l/qUN7pvNZvDHuokm42aUzEP/nAzRbQx5aM9t qgWxPRm4LK2Wesj9rU+nO7Nf5e3Nr/Sz3XfNk0XvTK4n8Qr67lSuaD1QhgzHYhfWKBWwD30l5YOV oXfOXVszy9X9UjXh1cAu2XP31p10zmlWU2bWUBRc11JMRDSdTtfrNfp8cXGBxBs6v+qW5UztQR0I ksA0OX6XWDmk83cJfG0SM1M8coqi2PntYrF49uzZmzdvinEFxRaLBdeLi+vSBH5NbEzastam6Xl6 Mupbv1wx0UZWOv81OAgts0hK+mlYu+UvWN76K805a3+42+2AHnTCrYhzyLJfHowmGqvSb0z5daJu mequDd4uO3X69EZHdGOORiNUEmj51Y172/nba1W29s7WItjDezIQClgYBCbAjXhmabiSuPsIlbjL wtCcT62rQjumW8+ZPKGtdzav22kBBrB537X92/Vfpz2nBl+wRp17pxD6sgOrrUgHn8UiXlaL1e/1 dnc2ZxvnOinn1flRERAnKOwpWSwPaNeHrlp7sdV4mSzN26n+3YCUnTei8Xjs9+VsNnv69GlZln67 OSTeL72YZBZiUlZDXdzc2wArit66hnD32JAKXFReoaI5IWIPex1m46/u0oGHpuS80dnGhHdZN5hZ sWkijCpo4FhRk+oe+xR1dY4zQHARybIMDn2ad44++Kn7cOimE9WVH7aHbCyMxsxXgLJTMTNEW34/ omkP4GiGZFu6uwU50XnYo7d5w3096KZkEz51rZZk3w1ZVOgS8jVolQzqBgBDDt8mYlNv2QePOkmY Xf+M9+idbrHBbk0a9j3QwITZhM1FS5olG7h5heoBrg9KPRM7nGB0m8/ns9ksyzKOJRhEhCgQVdks gjcQgSlICEJ5NiIOxEFzSMQIVY8cgvX/hKhKOxiTD9qdc9fpsgDu1+lErNaSkEaLtMYBuRgoiNgo Z7LyK2HlS8yia1vA7OFbIUGZX7UB3wtG/CHSXTZXk0ETEeKM7tQlCACxYVvu+BF4zo2olT1aaloD Exo4omuFN4s2Wvtzl6m7yyJ5UKcodCyEgIpd2PKt2OLaA7EHDJGGxXZN7r2TyKF4cys1bU6qQtCL Ta3X/fY/y7JmWErP1NsXMxqNkG1eU2+BNPOdxtk284T2EH5uXVAHjvfumkDbFHQ2VWbJojg5OSH2 79+/13tCCFQ/b659ut1IyaAsTrr7GdbkNSLyENbrx6REM0H1YChr0rKEVQqLHkXEbG/ARO33+9Fo FBoZqIKmXqUqS+bR0RGEJKSwtEarf290L4xIS1q4bikrqdI8pFdQFSCZxOOIOgPp2kl7II37cFL5 08L0m1JTdT38t8imc4uHDiRoQ8uyRFKo4amnBhIGe58aDjt9fTBHbmz7lHqu2eYJxPfnQnh0dJRl 2eXl5Ww2e//+vTLxBGA2z1T8hYYDHDxRydjM/8P746L/bNcN/Tqu+2UrSI0c42uYiIoiy3Pn91VP ADj6JRVr2R2i+sOrT86wptrzphRb+6ECjqbWqqr+6g9R7lZMCTEmWVUa6rqR5J1TtGHT+3Z1I4TA IWw2G+fcbrc7PT395ptv7n2wv6FW6t/7CeEIgS88JLR7P1RuTXfXXvdEjjSxr54gTU7VZUZRxHZf ku1NGZe0hFDcJznnVqsVwkdwRUd6j8L8/ZtU+udRRLTuqJIew82TlesBHfYRD6ThALZ49eqVc66q qG5CP5rIw9q9KKbZac2iQVFxPdBYcw2Xj+PVdpL99hAqK8wAM3vvHVcZxrQb0OE7OdxMRh2lbC4B pgmMaN3ndbqeWfx7IKuF5ui/7JwTX2k1/n/23qxXciQ7EzzHjKRvd8uIjMrsSmWXSqXCNKpHgPQg QK/6C/qHA8zD/ApBT3qcwWDQI6FbKBSkqqzcIjIi7vWVpJ15+GjHD42L091vZEY15uAiwp1OGm09 +wJPZ+SSSZ7VK87ExCpfQtH9CJsZjAvUftQ3yWA1UArkxYsXCOX/SCjZjwDT1Y1nQSQwV1FiZs7y zDlXR39DqDdgof5TX6NeB7gPBJg9FEm+vrULMNUUhdb1CxpC0BwtQ4LuCG9nwR4KJZqTGA5gE3o2 hJ6SiiGDupIiMfV76HwNx0l0oNyrinT/8R//AYZD8XXXa0li2iutWY/rYDh6l8Q5VxQFknV2bbTa gvI39isZJ2RLbl2Mf6nrWrXZ4+O9GNTpJM/zmT/aiWLfeh27QvxX/2yDyU8hZmcWInEOeyAQCTOJ hBg08/8DkUl9DZq3XC4Js2ZAkZSIdMvBwA5icagzNaJVIwJmwmbmaNLzMwcJekDev3/vnLu9vQVf HpiY+U8obVov9JIXy+p9OGP09bQty7K8KIgoa4chaI7jDwrP/orrCeq4aZ6G++xi/uiuAuCyt58L EiNJu0Kv9rAR+a4w90DDofOsynsr3tj7adouReedc5MYDp3orpphOiQKie5PiQQsIs+V7fQkQIwL MU79cDiA4YD2Amg3qRZLRMgGSJHRVsf+EQ3HbDYDeyjtzCoALcIywj9qJ3t/teWFbC375xUCZrPZ crnMuSFL2tsYLXxV7l7XCa7hTtwaPlhF12U8VghN3u2harG9HfjYIM/z5XymPkNV2QrE188aaWnV D13Dn0KCXJS+ionuFhHvPPbzdrtdLBbr9frh4YGwFd2PWlb6RwDX1jMPcRvPQmjHGwkxJ/rI0bZd 9VlmOcv9fv/xOHCcxUZECaShgkNeSokydbpJZQjwLptD71yX3ut5U5QXHnovqM/1mKooChA77TCk Do1sUuI1fTg61X256tqQsHUXw8jqSsxXOBL71OVXRjgYOvPMh1jIQHPmf/fdd2Tc7sigaVu6N5gk YA3+Hc3/ipqxWCq8zk6scq9i3MitesOO3Z4l+xXpQ/RxqD2mT8UUcM4tl0svTf4u55zPuKyayXHu yDklovPE9i2itNsm7n5qf00nZAp8zAzECDRUv+N3gvy2UDhVu71et3MOBrSqqtlsZkPsumANLohS 6cXpzEzUpMrVVfiXf/mXTz/9VK1penMjRVw06o8BnOE29N9kTpKNeg3Yko1DMJFOM/NsNmtIRFRf bbfb1Wp1ZSefC1xfjqLuPc/1usuWSYW3EEKe5xNjiEIIxE3F08t6e2zHmDvHg4TPajnBhPZxK/qq MV1/vWxEp9kIdQezpPEyfN1YCobLGdOAYgND/XCFfcE0aFVYlJ/AFCuz1T3eVhZX1gTGb+0ndCda f0TxyIhokiAacJSJs1JZltZTOjmoVoR9RumcjT3De58zO+dms1lRFLtt4wRQlqWtyGC51d4JpIET wtGrwD7VjFGOn68cmpuQhu5jA2ZG3XF7EdXGQ7sSmDoM6W1gRne7HdLbaB7SLkvateBadKO8debz oiiEj/H333333WKx+EDn9KcCz+w6ZpSuhPeMo+5yMxZCCDjyJ6mLrhozZ1lWS7M39vv9crnsSm4/ FYRTodTdkXZ1vb264d5mLxiyYiQ6lT0o6aTP2B6xy2YbmLBX5d/Ld05nO+zjSKWDPJbUdrBTEpxk cDkXsimPqeX+ghd0YcgPRWJRqN7lhLHZezfRY+WC/rjoNJesq2UOuqsbQrBO/hqlgq+wrTw+PlJU X1vzDWhDt9hs0p/k1SGm7HQx3CCZEHUK+0CohJnv7++r3RpUJ2GPDoeDxlvqKNTZSpVDZLDM0Gm0 KN5e1HfZz0O9VVpov4JsExF2FDWuEDCs2H1+pt3w4idH2mwRtkDMsWl1iGl2IOYz2ScBbrzMznsm 4iBUByd02O7mebFbb+bzeQidxAx1cEL4o/ghd94TZ+yC0HI2R9CmiHDzrBPhupb1ejufL53Lqjo4 dmTNVUxEgqCjmgI1xqxwys/jJ1P+O6KMyDvH0uIzulW47Nfjh58gBsq+kZ3z3mWZz0VklhXi2LPn QPWhqvYlPOKZOOAx1yFdbel35H2963eWPDCeAFB1ZsGkjsScK1107UjG6wUt7hhzraw4BbsyM7Vr TXf51IkAb1+KzMeIvDp94FY0JaKiKBxnoT4eWe8cyfHPccbkmbi50gKOf0ChfNyKfHQrbDKNjiiI XAy7mDiGIVC8H2LYXnde1A3+eHNkLyDii1wSQDW+AJYUgd1Rdw3VcCRWlQSwh9BVZP2yTIN6bNze 3pKhtdZe08vQdDmM5IoqS7oMRzKoZxRlwGCVZemKAtpFMvZUvMqGjKOyxnw+z/O8LEtHrDf3brle qVE5biJS73qbYF4Hy8a9wF5PMD+zhmf/9OLd9QBpdbPZlGXJdVBGttkw0uBKjnbow+GA+xeLRZJS zyLT7m4HF6vktgqNugmzDTwInaj3vu563vC1SqlnBB5OMgvADmbmPM856tW6ZTWSHdtSBT33WBUR TUHImg3omL3eeMvRKe+uzum4yuHxJPI5V8MBsEO4RiTudq+LiMSUE5qoxlP0m2DpCzQEQHdTdFrT fR8Tg/VqtepK13Z6Vc9xVs/1XSJy9GDv9hsfoKq1j13wstaLqY4fWk3VdQ18FCQQN4aVEILPZkRE zEGqEBz4EO+9teV3F6/NmU7aiKouU60jmC0sIZiPbuOqLgshIEzAgvVmAH1VpO+inyle0WtW5+gV hWrjzvgh13U9n891+RP6KjGup0uPp0zFCMxms5cvX+73e854t9vFTKDHV4TQ4uixTb33ZVlut9tQ 1VBWIQGR7TD1HXJl11R2Z6qFamFiF6R5keCPnZAISd1c5CCC9KbisNVj2jmRqM6YNGikOg1Tb0fn p9/aAT0jRNQ4Dxx7go/MxEzkiRfFbLlY1HW9e3ziIPv9tqqquq5EamU4iKiuyzzPUTqwLPfM8v79 oa5LzeRm83bA2agTPSRZ5vLch1DFnnDsYTMzMCC656g9YcBsMBIi4iuCRdtbbJTItXRsODvNbmdm 06vuUvPgLxSXLjmJzMQhri01aXlZw2IDEYuQcfDSndDc09UFJgBmsfCZq8UHwl+zt9zl2/XH5B+j TvTotqXEL+HAEo3mFNCp6yWo8L1Tr/yRedZt773f7/dQ2Fv12MT+XABKwmRyMlnF1c5lRA48RvxR ovOSg+bBOQRD6Km3wG2EYLhV5ezFp2xyUvvj2BgzxfoXV4L0JTBJZqe7S6SpTum4na/GtUuTXA+Q yIlou92qaie0y0lokmBFrMhIgbSMuIdNmXiODiiK1sG7qE1Ew3ETCCFocU6A7lpUIbcKDPtU4sbx XJMjIkVRvHr16nA4vHv9bbdxZoYPeVf7h4O3rbYiAp0HsmLTACekCHRIPTNdwrh0uD8ZTFfF5xGg nHt6emIKh8Nht9tpmBImQEu5EjU5jG31CqvDS9hf/eBjceNjsbdw9GFSdSD+nc/n9XZLqnL/mFZh SLfB3KOT+KAUYhy6NAOShsUzZHR+CSQWH4kRzhSdqy7OmDkd9GhPkXZOmsutYkYbVMPKSLMnhwnk PBKxZeU6fO1tM/E9EBGElNLVfq9WfWvHm8xq704YAssAqWyM6UL5xms63AuNSSVELzNLIOfzOTJG AED5rn9l74wkFJ06HoXNU77pCS7C9+2ks8LEbruYTuDx8fFwODw9PSm9xMIkPVf5W31ckDLF/qpH oiiKRqcU9RmKoPFsURTb7bZ7NiSmT8B1m65UR91lOMCMW22YHvu+oae2iWT+zJgDkczn8+Vy+e51 v2tn68k6OOcoiENVlaqpMioiT09P6A9cdHs7YNV9ZCr54ZQEkYY8SOtPL3L8OzZIwtTYV5CgLBi9 97iK/dnV4z2vOErGbTYufnDSCA7eOSfkqcGSWZbtdrvdbnc4HJiCsgvSmCaJOocrwYxTezggosEm q3Ufi6K4u7tbb7fntj+hA0R0oVhtHHXS53VMrrUPhZmiDq9Hf/Dj8CIcTRs41OAYdAW5L5KrCxJT i+pXMByNdSw1OX4QGOc5sGlHiJxEJz/vm4qDNCCa9n49SQXGVUQ6zwjwGfFASP5Fale+1BIxBFO4 qAug23+6mlWykFFfCjPdGZgjlCV7rleO0CeFrj7WxfzWCaHl6DQ08e0nVWFVVa3X6xDCZrOB3mKk t/oTJlCNJmQMqNa0gX5CClwul8pOKsNBfT6qytEnMzM0cCtVWPOKFQsuA2gpMKghzx7tUlmWs7yw r1MbvzLpSheV0+2O4nnROjNPZ5vHJafnBeU2uKtvb4OLQhM+wCBCsRzoUHh5XddQhOhbsILwwkkA k6/bT6/DNGZ7QjC3tB2ZvfevXr367vXrEEI4FQjkCI1MmmcoJy5bkqjYsMZW/RAnP352zjETM7uo wB9itj4cQJ4hQwv1pCjD4b3Psvy4RtzIqTQQ4gjdBmoI4wCGEFz+Aat42iHY05RM5shBY2bNyJ78 hEno3cMnm+02NfIrrDnQMCWlACyoFpAirg51qu2e2J+hbpzsbe/xH5oHbQcdQ15KKzk/L2eTkTGj 2HZtnMVzvews+Kk0mXA1IKL1ep34rwB6eS8wbYvFIsRQ6dlstry5gVDePVpiynkra0JtTNHLmSX6 uijCtjaTFXpwz36/h+fEyMAn8iIigiyTEI+GbgtV7bmHQQ4xmE07r9afXg0HJkrvPNk9GuQS7LOq DyHiwE4/O6K2KkOECJZ1IQ703MxHW+ltPxyvQxPD6D8zEWXChc+z3M3n89vb2+Vy6bnJaG5NaQkE E3kIeSvP89lsphexAxVjYt+GmOG3l+I273JeWROcDhFZrVZZltV1XfUxHM4515hjmOADIhKY6BSF AF9ymctB0q6zTB6x5+MYmeEpQswNP/TjA6SdOBtBxRiOTruqn0BaCGhMYdBE7BVS9Ia6CnXlXR7q qip5zzSfFZv1E5OEuqqrMssyT4X3vmarN2WRU16158AQejmJc1z0slevL0u8VXQZee/EHo73BIha z8XQPVYgvCYn6XgnEyOa/ax8pDsnXEUBJA8zDGTCbf/xy5pVaBEMOy8fujZdAs6ka/0x36ugBogQ 83Agr7ntIT4k0217q3gczAcYYTGOF9b6yNFuZUX5PM9VG3Gyz0Nrrw1qmLF6orirU9AQ0eFwwHRZ wcIyDQnNg/5GjwFF4ge9bvKsheTKRBGT2wbOFgJt+4WYt0Db3unAyZddBG0+48QYm963+4Jktnd3 dw8PD5jGw+Ewns4LnIQirOVyWRRFURTYHolUhJUCfrflcpAARr/qDKmlT0S22y1OAaKZDlWpmshu f/CI0DGS6AQ6C2GiLmQcUoc35kaf0dhPxeyb69+WwpRtjHB3CPc6z90Qeucc6ikijs8bj0WKppP1 eo03woB7OBz2+z3YTXAtrsj/8i//spQmM2FRFEQ/apZYd6o0N0U9aFVVRTFXhuO57Ol0SuICxsPr FouFWg/tPerY4WJU3WKxeFrv4d1/pa7Udm/E5hBiBJ9VZw6BNqhrPZ/Pv//+e2g4rP/ic+kdenQb CqC7ygc8l24ZRopx2T0B5bMyn6ZG7RXxh2Bk1Xe7HWpAkFFJoZNIcN67F9X/QM1SjW5juUQlLTWa qEyv9rzZbKY4BWcJN4PLmV7I0YY1djuZeHJMaTCBpk0RtPbmzZs//vGPkDYSHNEcyEwOh0ORZSGE zLksy+ZZnkW8Ddm0hupAhDCxIbCIZ058ZEil0rhwGIAuYZ8LBwkWWlWazfYQYpJAWeZDCFUQ8chR 4UQkcDDtHmcJ0ReC2JZG6H0OMAWTE04CAQzxM7QaREROmJT4ueAzfri7X8zmPkiWZU4klCUTxbCd /jRrmJDVarVYLIqimM/nIFcUrYH6rAab2OwIIFfKtFHsEIJWpAkOorLcM69E6vuH2x9++CEvfGQr wVqExmTERw5evWho9CzrT+0onjPAEVtNh3psgFAwM9ISOnf08tHlOckldPnI3gcmcvyN421dZ1m2 222aDrcle4rLenNzg1Dnt4/vbSNV2UQqPT3zEB2JAAAgAElEQVQ9wclmNpu9f/eDqic///zzzWaz 3myq3Vbm+f39/f39PZdlls/9zNueRk1LdzzDaIqDmPFKMnbm1r8xMMc1MTitKUMCmUO5W67mdvgJ l3A9kdJm7UXgf7VdDiHnXgR7c3OToMrrweaS7oURTec4FEXx9u1b/ZrkwgZcoxE4YpCEx+yWxXvG Kev2eMRQZOVy9eSgUa/JITh5m7oUrNdr9e603UgmQck5REwims1mkO1msxn7HIT56JzFbMOp1f8L rXEMu7LOFiORQSEmHMTXcX+r8YFPhBDCdruFVYUj86S/Qlz2eV7X9ayYkeFC1CzSdNU1ERNQe2g7 VmfT7fORSE8QF7g3YDg0Mcne+0DMzND3Xy9/nISEzAzt9un6J+/97e1tKMuqqr7++mv17x7CNZgQ 7EykRZnP50loFdyTlScOxomvaxgOISjTgO2tmoy6rhEQOJ/PN7utj1U/gmF/8axdbmVlhlBNs0mu YPuO2qz4FfiUedC1Z/qKaP+PbNm0R7qAI6Nu+4ney/J8qmXMsuzx8dEuEzRe6/W6rmsUvt7tdnme 39/f4/HZbPb69esQQllV//iP//jL3/wvCOz/5S9/+fMv/rOIwEADsAyHFY2uhOnTS3ETXuZVoJN2 sUYE2AzhG/a2xA3CkonZbHYoa33pWYPtQoixYN2OJbd5U3BgBCxG1WcRntnrCna98eGo4cA02V7a Yw9aeOV8WUi6PmIZavnayPFO/RBOpcVNDn7Xo4pMBAQR1XW92Wyypjw3irs6InEuC6GKccloCu04 Inc4VERuNlsgAyw2WZ7nmLdeQ4yLMb04wNEH26M453QSqI4jQzc8l5Vqv98jlrWqKhdqjbGENAb5 u9zsVosl1w1SyFyTDK3lGkFUh+CIHXEdAtuIkq76In5locz5uq5xG0tDe6AsYWL8Cx3BcfdaAciJ Y3bsJXNZLVVV1U5EJAiHEEqTtUIaAV5YApNj4gnkox+6uOYk1nONhGe0Ghwo9sAFyYTmWXa3XL59 +zbUdb0/1PsD1RXVlaOjg4oFuIje3tws5vNZUdzd3c3n88T9Db6Em7pmouViURdFENlsNifHmNQ9 EBHYZF1MfNc1flsJFWoHFx8fqTDrr1MyYXsAnHOZScOPiXaG+YgzP/X48NEiozqq04/Yz/o1yzJH nDmf+6yqKp9kEoL7SxAWKvcHFjcvZgiELk0lnc1mA/GAiKr9oSRGxthyt8+yjJ1zQrv1hpmrqnJB /vi7fy+K4mc/+9nu3eOb/Lsvvvgiz/KqqqJWA76fTVfLshxPR6HQi8esrIjPyBc33s5+v1+v1/PZ jX1QRdCRtwzBdIpmPRt6+2mNKVa3HWIKPrCG18s2I/ROO6Z052RTFN1TKPL6iYydtNyFs7iCLM/z bonqLnxo+e8suMZGsNvtJIaKJIXTrFLn9evX1u9B08p2gWOGzcaGGlcuyzJ4G2Lhu9tRW8COtMw7 nB7UXjMOevB0f+AEKkM2Me3/lBfBuqTuF2gZnFlRFNXhaPL3vsX4e++tMTyQaH4R7nhUjEw1R39v TeBB0bgr7cp5J+PruAIJl6qqlAr1qlVUcNHHR2ape/y6LZwEe5+SPf08z/OiKL744gtwtE9PT5vN Zig4xQoxRVE45xaLxWq1Wi6X8Oucz+fQ0MILRN0PwVZWdQ0f4UimG1eAkfJREKx/+OEHcqzYtuum 0yvzjdvR9f4R7dc4MLdcQ7sPcnNFqD11J1vuRUrTGY4WpyLtZCfDgMUqy/LNmzeoaKMlcrbbreYw pPZs4+yAJm1N6HJZlkVRbDabx8fH1f0n33///csXr55LVgH0LpxE765eMmTJnoi8f//+k4dXl73d rnsXsMm7eENiLI/edu57LcK/2K7NfTmUrwTbGQxcy9OrF0FXr38NZDZ4IbRzU9qBwXbwLEOdz+e9 HjcjoCyY48zSV+3P9ElxsQDm+MK/efPG3hBiTBS1sY9qMsDyU0QccJoLdMw7rllM9H7Ec3NUQUMo 1F2VvEhHahG93qYb0U5CLzkfhdB7owiVZcmN2WgXQoU/ii6fFCmQJ86dFy/OuYxawXuZ82IZjrLM nK+pgq5C6sB01Fg0/ehqOIjZeWFHRCwk7FwszjFtgM20BBLnHHEQES9CdaiIiNk3dEaIKJAjInEs Ip7bxvwBOhLnWd1O9DYh0uyQp4GZW5mpXCBqQjqxI+F+EcqKmakO1f5QVQfwgkk7FHFKlmXL5fLu 7u7m5mY+n8NUP5/PYVUBawvbym63q6pqv98jtUZZVTCOkFHVnkSaiHwWxxztONvtlpmd2dIuzjC6 HVopQwZbdgPuvROBiZvkGsROEvsKGm60Sr3syFjLBnMeP0zvmE2aDsYaJWwoeBbfNjNBASN1LUQV UVmuwSAeDod9Waqlkkwe5CLzLNhIgULNjinU1WHfmB2ZiMjXvtoftrx58/3r8hA+/fTTT1+84jZ/ iaNQ1U0NiunzMwSKFafffEH7Q2Dfi+3dHZRN0qh3ntuNjx8gKD49PYEThffGlMOewPhSZrPZjJmR t1VMHIGFYMLxVVOEny7zZAZqG8/tkfAEzWdp3XCB7A4/AxrlNC17MXSbToKiYKhMoKaG+zdTU2s+ ofraZlVVyPaIxE3KR4eY75zigVHtXHJC8GF8FRIRoee0NG5fjf9Ky+lBRKq6rmsS2e/3m81mv9/j nsN+jztvb28d8+PjI+dMRJJVzjkXjqRO9RDaLOqqpL1oc/Gp6Gn4YEUN3QGOgHaDSZxzdSixD+u6 ruvgnPPNPbC+OyISJu/9eHSgqny0P71KjpPdszcnIycikGonxMyr1QqKDfh74iipcsI+qnLzfD7/ 5JNPZrPZ7e3t/f09Mhctl0uopnDWwFhgj4WYVwNbGnY0hFCBFxmfkMY+6I4CJbZo2XpwsBz59WRs CDjyGF1J17ILST3ekf60nhqWnk+CjbbIfCMHbrfbLHfwBu2KH8Bj+PXx8TGEUJZl3b4zESB9u1CA EnvhRsVbVdVmuz0cDst3T1999dWXf/7Lu7u72WyWrLhipx8NXIxu41hBjSZQnyFN2IiSg9o4HwPX LCDqdZAgyd532Z4rsbtY36wduOzxk4CJ3W63IJF2OCdzsk2HJvHX0M+6Ke04db2HpOfxU6d5M5Nn rRUg2c1IT9RlUHpfZHVfkWlozdTJo2LddK0yTR93MVWoi/XZ4YeY5zkiFReLhYgI9SeYUwtf0m2s K5Ra2knoY5QGdzecroI1qeipUMzSy7EmGhF8WK/XjXYkSFVV0Ce6Wvb7/e5pXW53dVVh3rEiR5NK uct95l1GdCKYUDUfCOfTgSQoOznYdtd12cGT0s+RQSEpy9I1biOcZ1klVQjB8dGHxJOISEgrIvaA ZxckELOQWMIweApGvPpjT61ojJl0RM65PMu89zerFcXopK+++mqz2WB9kzcqQ6zpOmBMgWIDfAbY QWxR0BX4xOlPUtez2QwHEyQNIXnJLkrOFK7UJBSpAkyEmc0fICzRY0OHSc1gBwur8fjGOgUc9URO M04rEdJ7op9H/EpuCsPR/ju/Yy3bCkXcqyZgQC9vbYlil2QmkFgG8SzOnctyCTVltN1s8ny+D0Gq ep4X+802Y1cZteP4K86Cs5QWLnroQxwXkZGUX5dBFzMDC1nUmtBjGwmYWF6Ucb+eUbhMwD4L2CRY s7hX99WIaNdsoVPJzY6BtiM71a5BN16/S1DHGQ5gq5MesFM2tD08Vr4MMdjkLEtQCAF51r766qsp 7wW3q0l4RGS1Wt3d3b18+VLnnZkhhlqLLMfwcaWv+tkqOZSxm75ZLUm26hBwG3padN4sy4jd9vbt 291u19SKa2iAEJGrpSxL+Aro6/TZ8dApNnZ3a4WBqlZFlhGhM/mahJ8MrW+vFBJCkNB41YgImgSJ xeRb3X4ToXqKgLizUrieKQTj7jzLmXk+myPABNOIEAZFauDhbDdgSQGTAWdkpJNyMaOAdWSDWgLe 01BmOOdcFIJdzKGOwBa4spehYSkkJvgXU+uB3bEutVOr6BFvHjkzuwmbmRwm8cPzemJiu6I/t75S 8qu+b6jl1m0ddvlcUFSgAsZut0vY0xENNPfpBW3jYpyclENt8fdVzcxS8mq1wgZ78+aNiNx+8jCf z6tyTK3144CVo/SzDuEknj8tDAw3grmCTnpcw5cAAhX1kbMYrJ8ENpvNZWVM2MDQPdnT05MyJuNu SolhhaP/kU2UORGGKCgQVi8Lr0I8m+yHU14RQkg0HEP3472bzeb3v/+9Xlc3yaTb1sBh2YuiKOC8 LSLwb9e4O8wVmC3crIl94L1BUbOa57mPOaQtf9CFkXngGNloHUSQgMu2CSUIEUl5IJF6u//h2++a 1F5CROSjAFpVldTBEYXDoQhUB/F1yAJlWnkyy0REjSkKEk11wZTVRhSDdtJO49CIxv1AlelM9CIK ag10IcBfJAgRBWbJHYcgVWO2O6IzGMvrU6wv97kdDB+l0zTJivF4+WxWZFm2AN/gs2rfeEExBaTr OMrWkeQ75uViMZ/NFvN5nueZ9y7yDc7U1gH7oohb+QbcVm42FKkgnoU5rHGprgMR1WUpIlkGtgPo RlVFRx+cosgPB7OfxYnRUU8hBiOTp9T65NwOPy4UfUTY+HOcbFZffc3bLYzk8B1BBdJE1jReMMfO A6OKgItxzrE0RZOF2tFAcIbyrvYHmtVE9N/+23/7xS9+8b++fFEUxa6P4RCRi/1pLoBEhADynJLh ysL4Mg0pgBWmZ0giIhjKn0XDMdSf5wXn3GazUYndvvqsUQxNcgYVRa/CZGgVk97AeIwcVtebeYZO VCP6S6tYkd58Fss5AlmWIbW5aimTGVYNBMgnPGBc2wlZ88OE6I2hXVX5D9lIOWrnMJyiKMAWgO3A ZKrL0gW53pTEohEcFY4KW9LQYiaKVeu++eabr7/+GoH7GbuiKMBw5L4xlIQQhnAeZq93BZWVTLas GpWVf71MR8pt6570GTvxduX2ImUl5xxJk8gZqBkci5JktauM4LWumJUcuek4MZFTOXqJFkUxKwrM Twhhu9028cbMRAS0qw+66FS0XC6ZGWoJqDdwVMnUh7Qx4ckRVhclF1OEKT+32WzkUCrzoXRXuxHa uooQDfDNrhNn52oqLuvgsYvJfH87zbof9+T4I/a2K3uiIsfIERjX+/b2GSuiiVJ6j0ZzZ0z1CmcO Ivr+++8//fRTer5JvgDskLF5lGe9jNxcP5azVM6weJJxSr3spRj7+A3UDt+d3rj2aj6fa+BSr8G9 16YBmDKx2cjzColdqhe0jOdJU4i6tk0xmugbG4V8WeE0dlUO9pGRfo4wsEh6A5XAbrdr+DDJiIgk ymSBJTARk7hQU5HnjjMSh7/5bDkrFrinqirywqbkAQ48pMmHh4fNZpPMw2w2Q/pRF0F5uyE9qqUZ 1FYSSKwPCfW4TVCtUwHlzfsfXq/X6yzQ+/fvv//m2zfffV/t9mVZenYPDw+NXzq7rAnej6qRsvJC +rcsZvW+ZJe+RV/UnX8VmjHniUVgZPv2HtrkfhdzxNmblUKAPIsICdd1HULtPFEViMSxo8i+CJEI ievvyTjuUDNNVz85/qCIZNJiOHKfFc7fLVcsJLXs9zupQx2qUJdkprrFpsSlB+eBZHTgWlQRfaT9 HTFdiZNmF4Unh/YQeE02WxGJRqgjkcaOrUMt0qTUkBBIxLPzPvIZ4ogoOF9VlbjG02hIO3WEUQ3H VdDZJycbv1irkTylNhEics7BYzQysKd6XQfPzhF7djZPl2ldsiyDvwwzUxiuDIsKMkGobpIxrB+f 6rKSEGQYo8p0Y+IEGGnN0jx7fQoJA1jEeEHfxl1lh/wb1GqsMucFr6ahKIo2dZaBsI/pcHt7i7w7 SSMhwsUto82Wdmior8k9vW1BUU9EvdlgEl8E5U5sV3rfaxmOqqoksHWc4WEXSDqT/4W6QnPQPj09 3d3diQiZALPkkUTloAlGXazhiYQ5iH21nWHm5XKJGAEyW/D29hbcmMrryICuao9kdJUp82sPg8Sa usrlaIkWO+d68MqyfHx83D+uv/nmm9evX79+/bra7Xe7Xe6zw+Hg2RVFMfPZcrkkfyxvTUxJTrMs y3oL4ohxB9bZ1kc4BgYniEP63Id1Au3XoTOcDNY2yMwQ97f7nfe+lgbjM7PNgtHQwA7DoUR6SJ+h 2AFqP93JJ9GNiOx2u6KYa5ueG1OU9x6GraZv0dLnoj20O3YoNuDGsVwuVSNi9RAJZbV8A0cTTDMN zmGJwUOLCD5UUUuXNJvMD7eTeSLrq/46VSab4L95PSRc7zMyHL33Hw4HVEJI7gkh2FDqId2hFfa6 7U/XjDZMdnQJIiKO2WAvJpPjrzuyVWYnd9/FUQGGgCmgC6jlVD3/IXpou0oRx3ZX4SSBB3G5sg84 cbvdTgVj277tJ0VSnsxJ1SkL3wXMMKny2ywKUrycTC/buwlV8M6qqrJzETruEVOwgB1Y7+7kpgRR S7w+2WwvaEEyGthkkMZ6D7Zul95BgSqrMaUZTgiMs0GE6Ay0y0TeOfwrTGVducXsL/7rf/nsL/5z WOSlP8pw7HOiTu0HJOeIXW665wtfe+dc7ZmIqpqoyLjOi1lORNKZtHyWHy3kmbcrJygm4l1gZnbE PJvNCfkdLIFxLtS1UP20fv/tV1/97ne/O6y3P/zwQ/m03mw2c+e2NzdZ5m5ubm5ul/V+ib3evAKH MARXVcgUIySZI+rhXNn8C9YtzIuscgSGhgJL5kKgUKWVuSRyMLrR28Vc4WDSxxAYaicigTlAUeRc ZazXGbEQE7kgaio67o2apA61l/5T2t5+Rz0BEbEIhz4zX6erCSNb1zUT/eyT+2+//dZnWVVVNw8P eZ4XuWfUreVwKHcoCeKcg4BLRM4xsc3RQpmXzMt85j95uFmtVs7RrHBMFZNjqrzzTBWTQJHum/HW gUMpVc6hlgrXV4Xf7/eOg+PgnQSqc6pzqrOMDz5kM1dWgQgkQQIJeAmiKmcnMYOoEPDXkcAISYj3 E1GQ4FDvZpx4oDx9H5VnOpFyJrjBKgFx0rRdZTiaWm7Ul0Olg2RaT1H0fzr5YLGcealmHju8LnJi KoklDWiCBqLdJlPNVHsnNdWZpxBaLl/OuQbNwFQkxOz6tCboD+SHjImqQ5nnOZKZbrfb+XwOj676 w5hWrGq2F7CymoJZ2okWn7EbvVvIXgQRUXI27m2jNlxFXxczRlacGwK4WQzR1tBXnaMLVk1iK6nB d2LcpDLEE1O0FWbd+QomoZZEZam2yH3WVjWqqc6KohVZc3x1hcJrQNmapDM6TRd4POR5bpNh2M7b 91LcRpbhrarqV1/+5V//9V8jR0IjJU8IqkzArmWWZcjUdFIhf6RzA81mDd48BpRaCCH84Q9/+OO/ /8fvf//7arsXkc27d2VZZvP527dvicL79+/v7m+yLLu5uUn0inC8TCQVlfx6VydRY0BMQdgkHBKH 7EddmChfQrZWC0Ii0wN6cY20g32mvMh8mLTPk8Z9LPv5i1/84vvvv1+tVrCyLRYL1bSBfU8eZGbL zfhYxxxWFXz2pri5HtWIg449T8R6veJienIgDqAeWMWAf0XENQf8xGG3WhAVUrntPTo6a5Mm86xf KV0+0h5Ol456lUYnH8GiAyNjbie+DmDF7oQYdOd/4Cg16wtG0D5VliVywQ1jlw8OyfwD+Z9FSiYe 4fHD3p26hLp3V1+Mf94F/VGA69XJInCJJaEL3SRm1FGWWC9+qzLR2EBVn0w/bqooTY1SmHGgFU0v aG/omo7I7PJg/MK8qR+jOgmQ88Qr6lxth05r73E66ZgzsiohhKenJ/CtSMYloXkRdP76lNbpLooi xEn48ssvUdj3egAa0liVqU8NXG/qXg7oh0Xk9evXP/zwQ1mWEoItA4b/D4fDmzdvbm5uNptNwnMg FdUQ6z1kEGkyk3oPtbymYsOe6R3ySaZqHLhNRSRW99B+KgpLTD9nqc3PojSALoW4v7//+7//+zdv 3tze3r5//x7kZ7/fgzPAxlMNn4jMZrMGQVCL2K/m85vF4na5XM3ny/k8a2oDZYX3ToRD4BC8cw7x C8CeTCTNv0XexKzVVekdByZ4szAJk+SZL8uwKIqyLD3RzHsEWx2kJhIfo4op0QxAPJcjt2HBTsKJ ee78PmW2ZcI99ozYXp1LIZoWJvQQxwEykvqbJ29v+g9TqbnSRc4jU3eSSDdsX/vIIulkCIH4bF0C 6EjX5YJjzTwFDDbpm7UR4yfVKwRT0ZMmGFWnL98Itdb3TmyKiJxz54bRjjQ11KuJLYDpGb/fxfB1 e6Ur8XZF+omoL1sul70C9AhVHrFKUAzTCCEg4kBiInpoBZCuP0lSFKJj7VAv9Tam1Mbf7fy4dm6k 2zrww+GgaZHK+mgek5irAG41iMjKsmx72INwGv+VlhHhAtD+n1WSUd+XYqLETmGmDgjl3bt3KqSW ZYmUFEhBhoNGddhsNii1oLkcOFrl2eTSoDYvOLSsmoQjxHIb4Kx52JzfReKD82A0bRIDBfVXb9NP 2ZZNlL+qak6+5bJfh+7Hrvviiy8+++yzL7/88h//8R/RW2XZsV6J0rFxGW5k08ZZWMvQo16Shj9o DFRy6FyMmHXuqA/ryjFW4aFx3WpNd+HIsQX4dQxbOlR5ICaxEk1gOIZm7/p7iFo8h7lyhjCtUzSF 4YBcgXVnZlTx7Saqp76j5EwKwSEHCNuB8YmNJ6VllKnr+mRRpyGdKwYFPbwOp5dmn1walVf1eFqa N0Uxdu55TJ4VUz0KkAxkyJqwXC41PuAasGTXTniiSCDj+6ghBdPfEkKYz+f7/d7SHchmvdmPJjLl +lOGXa4/jKcbHwcXYy58TNOL3miZLvAcvWHTQ5yj0p7eX5VFGFrOBKXqnb2HOcRQ491ud39/r6g8 GBARTJGSZ9gU8zyfzWbw/JKjrfonU0KmRGIYE4UQvvvuu2+++SYLjXNWXddc1Rm70KSfD0RE3KSi 1ySVTXFz32SROsk4dy9iDpXPUMra3bhDSPzkJCQai6TB7leLznrvnAjJSydiQ/hV4V/nHLLI397e vnv3rismIlA5OFPRkTIiYhJwGKvlcrlYLBeLWVHkKOcbXWWZOfOeibxz0Jc0OjDna+dr5yt2RBQk CJEn9sSBWKT5nDsffFYT+4Lrug4+2+/3ZSidz5i5LMvAxMwSgmeiQNLkfYiT0Gg+mq9d9VIXq56c zClrNLXSrBD4JCJEigbXG/0x9BbnmoLF1PXYaQH6rOqNv/iLv0DaeJETZR964aR5fgobpwKDPhKi W5tlboK532U9mo8EM1uGY6T/Iz1Xnrv3ROO0epMevndc14BK4HYgU9gIFwPUr+wARX/McbrObU/t c3n3qqqQJtteDH0lNUIIypSM25Xs56NtmOJsQqEdzjFdJ29VrjbptNKSEF1pnEkvAUmXjQouMd84 lx788Qnt1Zr0irbULvmx3W5vb28jEmxwn0p7ytlBT3M4HMg77z2yR0cc8wwMxwVy3rmQZdl6vf7D H/7w+vXrT+8exFiOwCISUV2XIlKHEsr83W4HorXZbFar1cF5ULJkqnVipROi4kxqfGSdglYMsrJ+ HlJynDunySbhaPLTg5FwSxwzy0mMHSU+r2xhfLDp6QjHnAA06nd3dyhbA9s5PMMTCnRkMswZaYbG jX/WarVCzZTGVyuyMhYgtWRZJlXLKMbR6hRCQDEnLI3EiCd146hjeVJmht3He898VFqExoDiekmF spJ6xKyua8psTxGwAHKmlHnuXuv2ZHoLWZb9+te/3u12f/zjH5+eHs9677ODbiqUg9e8cMxcVzUR 1WYZiz6GA4AdchIJn4QQvZeU1NmNJDGQ8HkdSBXUIKJVDKdDURS7/eUy/LmgxBQbbzxp5BDAaD70 64h4n0q5fZu/yUmluCDRB5zb1xE7k4iAlZFojVPKbXGfmKg826yIeO+rjt+GcjDX8LBg1jDLcJKC Ltrek4hfOu+73a5YzOHgSccoNWgFLu5R884L3E7PhLDfb9+8efP27duH5Y1uU48zHPm7uq7hSgY2 EZU/Z7OZiMyyXGJFA456VG2do4ti78aAbJ3FlHEgM7C7gcglaMWZ+hdnj7PtXO1NWcike3aVGVgs tPwxu5DsSXzRBzwk+FE61Ewdc+b9zWr1f/9f/+fLly+JiEIdqrIuDxzX4ljz07SB3nt2TJxlfj6f ryIgGhb8tHMO+xzaKdv/wMfAYHsAfTttubI1mn8M5xqsap7nYb8n4lqEiMFxOe8aDpYkyHF+yB19 Kpia7JciRMwoDDxxto+NnNoZI/nSO7cGMwcDaVh62sfdzNNYDcVddV3/8pe//LM/+7Nvv/12vV6/ efO6qirvn0EmvhhwOsqy3O/3kEDAPewe36Pe5BRAPH8wjlDw3KKITlX/wTHbYW87aEQxsJhUBTB/ X6/AmAJW8QmYorZRFdFzcUUTXzqiyx95Nsuyh4cH3KZhKXZ6pc+Pvjv/Q/Jnz54Gcrm4Toxzbrfb zWazuq6BiZSHgGCUUG6N7Fc80l0Sy1Wd1BzankzvM0c/psfHR2g4MN1MWSKgN97CIo4ITp04jdPP 4ccDmKLtdouVenp6qrb7siwdRJiGyEkIQailUeRofNlVNZT/HJ2x1SPYDbuwWYcPBSV1eDDxtNJd NI5aevlRNkEoyuaKCJaSOgeGY3EcaeMIbfykwqP3hiGG40jZnMM532w279+/h1Lh6elJjJnJKmBI 4wnRSTkyVVmWzWYz1C4GM8cxFB7cBhtfGekkz4CSEq9QdlA5D9UP6aweDgfN9eI9+NWY+J9d6OQv pw5/oMxuwrb2KkXIrGPvlA7AJMMWc8PuXKbhmLBJW4BF+du//VvwhapPmv2kDAcAhECV00Dd+/2e 8uM2G28hOcW6rJav9aaGrb1Zd7jSi+XWqMgAACAASURBVDAQKHDunF8Giv3UecCOLvTFi1oTDG4+ yydPQXnT6f08i/zZrxowoTyH7bNi0d6jZw/voIaj+5j24wIlRzC5tJPH5/N5b9ZFRXPUUYB7k+Qb Vd8wGNS0JKM1GhJYpwAmFK5bT09PKMbddF716qZLGkZRFMV6vV7e3iCN41kvPQnc+NudY1iRnk+x Nf14TC6JGSv3h1DVLCR1qMoy1HVdY1cFIpK6BILnIBxEKlSvJanq4Cphhhyj5jB1LxofmoulVeyh VYajV2UlHS/9BJRRnj5p3AmIZRM8jGLfElOB6X7Wvo28SOToCp3o7ewHva5ahHfv3pXrR5xzL4Hq 4Mz9gYSioieEwGahHVPuHbPMMu9JMqZZ5uc5gmDJOc6YPEnhXa5qcO+IqAx1IBERluCZMsdSiyMJ Eo+ABBfz6ebeUdYcAWglHEnmODA5Es8URDIRYhZ2RFQFIZJAjoRsKszemWMmhMOYS/2TjHus5NW7 CnYXBXdiV/CxTOyFxhdFtdPpHzPDKPn1119DvUdtIXUcYJW+AFGPd0kbTyYfHZO6P79TF5IDblUa 9kVJOkfbgtrayER1JrrPy/IgKIxMde/Eahxf8lTouJGiw4vFAhLdZeqNJFZxiC5foyawoEyVqpGu b1NPREutelYT4+yITRiiPIQM+BKrFsRexNokF11MqqjWmSTTnDMuq9PBWvEl1jlrVH81J2y1bikI ixBDP/300w/EYttmz12jccBA3r59q7lsnXM4GJHZauiNiFRVs+MRJUGxbh8OlXrA9HIbXYZXIhtn c85675HJnyMTk7TTiDJC2ltcz0wtjyzLRpzquxOIbCvdbWb1n3Xg3mcVusJZF3ysD0x9DIf9iWNg MPRG9hHFaEk7+OxIsiybz4s8z+/u7j7//PPVakUxnSsUG6Bt3f5r/g+KhrCEBgBwXZlC8JdsYl4y U09HuKnH65wLddPISdJo+ftEjXElnGzHnXLKu+BF40wDVEer1Qr79vHxUSsAB06p4AhdxORfw3Z0 Ty4c/LWfyJEDXG17Mq7MG+pS70HobQpIyQqWF4yOhld/oj7ARdfm6ZOsd0L5R1d0voow8nZFp12+ Z7zPtlchBAj23V+HuKXx86LSFL4eGQ7FL9Y3Z6Sh3mGECMmArWIjkSaTZ+2o7KZ0zhVFUVcNLVws FlphyJpjlFEYnwXbQ8gHUCL1jnpoo2s6CpzMy6qO/Whg+l9D/wE2DyZGZResPIGkXmKi0cjQgBDC brfTKHOcRjh2WJSEr1YocTF3uzKaehqVjQAB645CqYF6O/ZyM+piafldaw8aP/lHfhyOC/G6a7/F vld6rrMjpiB40EF+PsY+xO2t14X0Tt+W8Zg5LlnIHB+H0Mbai6LI83yWZ4vFfFHk8zzzCJFlyvMs Y9I/Dm0X0VCLCFMgqR2LYxEKjiU04QjiHWWeQy1CQo5IxDuSELwEJhGSwFSTFI7JMTuuMOGCJK7M wlTXKJAnTJU0/jF9IETiNM9G+ybdhJeBP0UpPLPrT8Q5GQTtHC9gE3fREbYuCHkmvHn3uF6viejx zVsvlFF/gJWIJN3TvXquWncKgB/S3oaYv6Di41nudhI+cNfzbQjLR3ZRvajY5qymRjpjrR4TwZIP fbaXHictX6YtUKMBPGC4bU5V4Fgj4hqdxG632+122sKzBNdYyFQ7hP2N+O9rOGVr5eoa8MYZva6q Q8VWqJUcM6ijiwlVur218mIXNPmrrhYCJQ6Hw26308p+ts8jaVtUzmPmxWJBp7i0jwqUO9QhK7Po HCmPGKThNpJ5gCAOx0/Vau73ez+QeK2LEBvk1dkkykNoZj2xTgbRBOYMkGEjQggw3oVYE07Pj+Wc hkLsRoCN98C50Gvi7TbeCNltSqvqDSsRJq1hz69Wq8Xi6LqBn/ABsT+9nJxVrqisbIVOvSH5qhyP M2VWRIQkhBCQ4CuYXLQixMwuaj4UkikdOryWNx2ZyYvhg6pSEmkeJFx9nn77299+8sknb9++3W63 MJ+TQSaWvNmkZ8/OZIhIYo1VhRPqRTQbwB2LPSUrAV6/NmWfp6heem9QBKUqTETJDd0/AkcUMe3V vcAxGeP093Ybh+723J0WQnh8fERlZm0zaVznOZH5pw9QqfZ+v0fBk0QjcP1+y7QWLV3E6w1BbzvO xEPqFTsGNcBzLESUpB8hdhALoHP2poC7RYUjyoakY2gfRgHEpyTxh/b+Li+iXL/3/v7+vnvPRw5l WY6wUw0vwhJCgJNHIEs8BF7is9kMPoMUtVlAENJxf+kFvQHoDBsd67Jer619BBPOcuS74d+kLWD/ 4EyCOIEfUioFdY7lP6bMEkz/urDS/mov4oN+dpDwnRMRJ+SlFS2t/+ofUXNPp14GES4ayR95RXFM vPdFUcw83a2Wt3cruIvmnokCE89yjwqCzjlcTAdIQUiEgmv/eZYgQUj0K1FAYRFHgR3VIiziPLlA PmNfcyaOnc/EhRCq4KqqcugqcxCBYsuTE6JgCoWYdNptDUcH4Lx8KWNw4rFmIdoOOqccP3rAS+QR +cicWXuNc84xz2cz7z1eut1s3rx+7Zsk8SoAxI1KJsnVNMboLETkhDz155XXulSJEpGIyrK0xZVi n3uISIJFJ5LbpJ2E0gdj9ByRYKe8aCJA7oV9ZAStDTEEAK0Fc9arRQSclg2vS15ax1KaVoDUG6bw CsqWGcnTURtFn9XtLowZvGlCUZLuMIKpEKNMwIjeT5XeYN9A+xMp2fpYqHAgMUhpAst5nCa9Wecu hACu83A4rNdrfNa3a+cTS5Mzj6OW/YsXL05142OBEAIUlRgyESH4rfdmtX1UVZUUzdLJKYoC3IlG S3YbsU8l5y0MJOdHUlp9Ch/y6C+iiSVUzYgYKIjaODOqwLMDAdjVHOrqlRBCYJMh48rWnHHX15nX 0Abn3N1qfnNzc3t7g8xseIo7aaS7ney9bteCDehX+ytwExZCJz+UkmVZ5J5qiZVW1E1cWxDpCVI4 2asrYUSP0lLkXNo4R0WVZTUs52HXBarluNtTwSZp3J6UDy3h2IQFdqsMSaddAUb7X8VS2GedBavh yPN8BNt3+YDD4QBf/hGlgmqpe3uFi0poAPbOcc7DOZfU7YTJ41z7u+6N5uT0hW5hVxxT0ffxiL2g OBbsFAqel2V5fYXbLjQEfqQfIzcMXQ8DLkXS9tW315VlBrUQEfAcaEod05CXAjpzWPhgIpl+6pKV hlUMvS3L8unpSePOySgww0CubswA5PtXr14xc2pi/ShBF2i9Xj8+Pj49PWGbuuj0x3IUsnXsEp0G FDTjE9gRlDYGJg0m5tmiVystSbREhoHAtl4Fps6/Puhi/n90FWIiZAJ1km9GFETqIEhXj6QQQZoP EY7qBIK83dj+z9ZwmNEwUSir3PmTGg4oRdgoIZg5unEQMdV17ZiYQkPNpGZyRd5UYlwsFst5Y0zB EDBwjoqTniokza8cxNwsxAIlCpGQI8afNHoWfD7e5og9u9xnFdcqDFSh5KjYaMwvTCTEQiIyk6Nr lAhSATWzF8IwciQm6q8Wey70pOWARkrILt4Fr9IJz0AghJnYxRKyuY+emEjWw8yB5FCxhiNhYbW5 OhBRVTea16Z+AuYt1CJygLQg4owO7Ln4kCymorZUWRxVVdVVbxCRJqlTw6UebXX8nMhwaPt6/2q1 UpOKyhvaT+qQVQ3uGOFTEy177w0ghfP53DkHqUYbtIhLIjdNERcxczd6sSzLC0IaEyE8GRE4khAC XBtBLnsLYXbBMihIJI3rsbTFc8IJ7UUSgzsFElZRaRUWJgxkX9CphFsAgtEZeTzt5ErTMYpyA10X DmQ5CRHZ7/cQNZRPR56lId2Ursdisfjss88u68NPBcz8/v37169fv3v3DkqaZHd2VX/dHS8iGq5c 1zXO5Hq9vrm5cdE5VNUeQ94DPlYjS17hTCLa40VuiRe6NPCiJ+PrEBXUR9cNaXuinKXbvECmtGq5 51JLJhZxzHxRFIvFovAONVN0+BO7p2Cx58jh6opZ+pQzAT7eB2auQ3O/9x7BtxLSyewqRIf6zK3/ roLetyRvbytizmhZtdMJDD3S3opCNCi41KYQlZisa2fJXSf7r59BGq0Mhi0HbqB7fvI8R0bO5OSC ENrqdBdAURTQ3iXQe7Pd3qgEXhQFd8I33OToHhfTNQ2R4W5PqqrKi9aij1uxR17tY/rd3o2kR1I6 2cmmQB3LZ+oMK+HukgAVFOl8bDY4d4ALspQ44+6UHF3qQ4LdHoeYvjCEAK2OSItvxyvg7Jk8e/GR K4pit9vBjaOua1Svcc7VVc9Jxi4Xk4FxuVy+fPnSORfCM0Qtf2gIIXDUcLx//x5WFd1JUScX7OkZ mlh9CocBx0m9R6m9hayKS7Xo4MS5rccG2LI7+qHrNKeChdJIDZy2D0qsxZD0/CQkG9SNKv+xW0II REcETczMrlEztJtNNBws5JhbVT/gEAB1BTMxByjqhYjIEy+K2Twvbpcrx1K0dc5DFs+RwTqTX6FX NtDrvViP4iKKSJa5qmo8nOq6do4CWA1uPRJMHrOTrBJf4FJxCk5yA0TnKVUS/tIyHz0NT/ZpANhI coriqfLT09vpbTnJP8vMyLncNaCc3EVKsdSpHAnNbFbicwFBKy4mR7Cmw+7Y7YRgXM65rE3RNO/f FDaoe3as1pb64hmdc0l65MPhcBZDAF2Ocw65NHe7HQqSD621LtOUEaERjVKkD5YeXiF7LqY4ge7U 2+t2Lnp3Hra+xJQYSkgoJtydUml3OijTquyhto83dA+b5auwG5Da/E8CnHOo4QsG6/Xr1yDtOBxg OESEQTiHMYMYTwigJ40uLooCyo/eLHUT+8kd/wMYuUL0CbVydggBShooyZTh0Nj0cYXNjwbnotqE xnPMVCYi2Lco1ZbneebT6Ro3MF/QeWf8vntnr58LMTZmoibn+ZGDHMbXPS2PMhzjKoShO09zG9Ri OLo329w/HEsCWZNf76Au4H3ts1YGvX4nM7N3LVa1qqpZJD8hFrYE88GjYqrVASSJv4bATU4j9uLF i/IgZALj7YOJ/lL3HjLQ5HkucbAuJh4M7aBF6nNPgdoG0hH4J6esxCizslwuhUrbmjrhTgfVYm63 W41pSBoR42FjSw0P8R8WbdrrXR1B8uA1CioaN6mcCyq5doWkET1K71GBa4XE4h26P5g8PiNyLNkZ 15w6cJFYqmROe7l7y3AgY1Uy5J+EmJ0FIYT1ev3u3TuJiTWJGkeH7s0NUoZ1ua9kOdgLrI6NGxpX BuCD1WqOz5tzTuqADabIRfkPHYWiezoGMdV1XYaLqKxq1WPfJP5Z0K+BSIgaDQe2iXM+XmnpBpgI ZwVbhgjOGd0OpBQR2BY41HvfVCrmYyrD7h62skt3Hs7iBRNVh73uhIK01AHshF3jkuUp+pWYAmDN 0I+7bqAPht/omaMJfe5+PQP1xz3AzGRitTCryio1mIGhiGWJE+GiedGuixpHrD8gEcFmeHIlVB9p V+250I5DuFmRCxPq7/giD0yOnXOubt+ZbCfcrx4AmkjD9VlIFYZka2uXhE+Yc5RlWZ77GKCmam+H 8oHgiiB4aH8axYDRN7BzJOK6XmLeV4lXuwiJMNFquXTM+kciQ4yS6iwdH9P3gMXpdaUaAnWoWszm h90ePmeOOvnH0GF4pAUJVY3bmh8H0vVS5FRUvwjsvdvt4D1K5oxckFGzC1MZDovBAb0GYGqLKZNE ByLqOyeaa1I52RACydHSD972een6ZrNRtjdeG3RdVjXdYrG4ubnpw2hTl6drOPigoEtZliVYZiCI p6envQnrsIDTXtaNl6i9rrQKjkt1LB9Kxi1Ux6VI1o50ZJN00ZllNHUUGAioL24AIsaCwn58saOP 7d6UBRoRGqh9KHw7teXJw2JvAA51zi2XS2XrE3J4AYLoGkNHQOmo7SG3XacbEdA31hMVx7V+rDKL 1qoyDlN6d+6qXQbdlqcztXW7LMPxKMWEeydf3ZWFnhFAuefz+Ww2y7JsNps9PDxsdzvnXB2RIjMn tiZQijzP4eSh51fD15fLJTKDQW7EMi0Wi3Hj/nK5nM/nT09PeZ4XecPkIZ7CLHRTm1BD8ELMkKS2 Dw1U1v5TZxFDX8kFHK5PPvlEWcZuh+2hs+ti70y0KRPBttDrd+JiaAVHF36k02giOgea7arHmBlG Hxd9Bqizpa125NyxnGY4bFgH/FaGUFJXA3PNOU9IVCOnBrGLej0ewVG3NQyrqprNZspu16FnA1Ek omcZzD4e0N6C2/DsOMvruraJtrpP9bKPXVap99nLdoWlQMccLdJc77qaIsZbYl11m4EDJ1BETBYK MdqILoR4j5VHpAnbGNBwhBCYhNuRcBqf4ViIRPONHn9P/TomAQSO2WwGSzY+ExFzj+/ndLhAP++E RBBfwzXYnSZ6hTwYIO/KUBIHYhKSmLuK7ck6q59XC1rPAydPvTS6nBqZZNl4zTP8ckLTjne+lvp4 /RRgmbrWigsnRo4PY2ez51rqu7u7xWLx2ec/X61Ws9lsNpvhRmU4RES4h8dSARUAJRy4AWZ+eHjA 7r29vcX93nskThyCxWLx85///NWrVyAHqtREH3a7HT4vljlBQZ7JbO5vi0WW03yRzebHdB1KO0S0 GHdCTRwR1dlxXGVZigs3y2K/3ztHRUbIvBrvD5EhOFJi4drnQFxGxUHkmLMzqYXTf0NwRI4oc65u H9LM+1BVnjn33jPbm6ED6nXBqesgVYXcbQHHNmYUVDuO5TnUkNTbT0UdI44gJxgOZGwELlPL0NB0 fTiiK9G1wvHzV1BsAkGN43crl1QfNbJcKkRMxKp9OGnjLDiLYEAcUV7V6g9YoGoTZuZo8uwSJIne G5b8n8zgom/X1ka4mXHQLun9u92u28kLSOllAL5cd4itovKMwMwQQIuigKhHDVPYmsnk8NtVfq5u SPeKxTsiIhI1Tw2JEhGhZi+BeECtOM7vms9Tu6c05tmXvmu0kk6mCjHkzeoCyZrV2n2bvuevUW+c 3I1QrX/++ee/+tWvXr16NZvNisX8cDjMFwsi4iLTdmrpsTjbr6qMtIYn3KYeCSdTPtzc3IA7EZHX r1/rEO7u7rozBo2mxsUgD14iN6oAc1LxKTEUSKIpWd8II9HQeHWK7E/jdqUuuBhKo5XiuWObo7bz ir7a5kFPZqk3KlCf0q4q26FtZtnR79N+6KobKMqoHHPP0EmGQ+s5QTkjMclBd1Is4/O8dDchSIqS nitE2MXEvXqlN0g6mWXdBBSDtZ6lM9dDL1lNLug9mMzZYm5LN4UQ6rIsigLFanERnG+vLVCiq7Ny xwjzoYtS8VvOTy+GCSF/3WNgSyz+OAyHM0GhhgM4ujFdz3aoeAdd9+3tLTTeLlpn8IZeDYf9bFHD kEvHSUCGyso23n5Q0aXm7gshEBPHcFmKFPcarcxPAuP25QY6sVcj0uEFuqiz7h97Vlody2LllFev Xn355ZcPDw8iQs4tFgtpazrB346HNuBXJWMWJwDrnksvoAuxqu4EoIwBqcJnvdkmfsQYtWPddvSM FEVRliVcR5fLpepUQIy7D9rWrlf8W+aytwx7AsB7yhn0MhxJ+xSVM69evQohfPXVV59//vl6vVap BkHFzrkXL1589913d3d3j4+PMOZallrbhMFLG1eh6wQ9sFEG487GavLptTA9F1j3lmdsUzmGRi+3 WKi6wrljXocEOBp6kFj6ufpzJUxhOEhZjdkMpAs+2PqTWFMRCJgQUX9soERHDTjn4yLiY5HuncwJ GVKDJTjLlhI8i1FIbpboEvXsrEYi6+gO8bF2YELp3TNVIiUzmbPZbLlcqi6aKXTfoMnTgOgTFjAR yi+AZJgcDSUcDUc66qHR/0mwFwpdvlahOxAZSHWYPH7Z/lRCItbvL/56PYMbQvjss89evnwJh19x xx1ud8yIYrvX1HJxfxQ0eSiNuhGAbZrP571zq1qWbq+64g2UMZC3QRryPD8cDkOlVey0qzailzBP BDAc6nvbe2b1onXRHS8wmwyTmV++fJll2RdffEFxa3nvYVmbzWYvX75k5l/96lchhPv7eyBnjgXO LDJs3NhNcDjm4QwBVGXi7mJYJk7/vSC9yU8FYBe22y2GhrRjYJDVUaC7NggBrWO17j8hvKmbg5nv 7+9/mM+P3htMLvPinIdCgxr9NXzDcCE5nzo/9jrK/+x2u950hAl0D/yz7B/giGtqJ3YhUeNZ9reb NZ/6lIrde84FZR0QEMuaxbUx/w0aAbmvlvJ+v2ej1U985cYJoZUyIXL0lp2bDiff+DHDxbLQRIYj IWMUnZPsDtc7rokpABXJ8/yTTz5ZLBY1KGUjfqDZj8J2PA7AKsDh57o3dqcOvozwQQGA21Bxy96c 1OKQGL4U2pH8Z4EyHL0MhIhAsYHiaHDeR8xOb2u9fZjNZn/1V38lIrBGrddr5BeYz+eoBwm2g5lh s5aYZEU95GBJ56jTtfYX4MDTDAeCi3TxTnZdEz7iZUkttHMhWfgPgYwkWmc2m823334bYjL17m3d XpVl+bz07HoQUxperyTTpjfc398/PDzM5/P1em1PyHyxcC46N/dpOHrNli7mh8DuxzbY7/er1ar3 WNLAgj7XKiP/WMJzjEioJ4E5ppQ2jWBQQ44aLhaPeBZ+1GaDhVqOO2VjbW8VyHjad3uo95+bsPK5 dDZJmxPumdTUnxDvglOjYz+pFAHUEfQnFzdbOFWdeLwzcO16eHjQi+cqJ3pF+S5PFgbKGiSge/is NZ3Y5ynsiOoVXAwXmD4h1+t1QNH1a5fnCDFeT2JJKS1pRIZZGUmpHkL49NNPP/3Zqx9++AGv++ST T/Ahy7Kf//zn6/X6/v4eywrXGdcugKW8jl0mVUThymmGQ3p9oTu89kQnwY8Q1BDwL//yL7/97W/V ha03h4wFEJIwrDX98QGIRlPTnLz/5cuXn3322Xdff/r1t9+Uzgs3Zk6HWINgNBwN33F8kTaiJbv0 urK9s9nMIgg9papdHOqYnqhraIb69g4pFSc23lpcTnUbigq7E86xqlnayMm3nIKTVjzlcrTilH2L dnWcsZ4IvUeDiC6oKzQVNQ9PlbQ5wjZYPz7DTT8ztHYLooaaP+rhlYRIhKSxhilZJabT7IKKmEoC pZNz5TJAXIn3nlzS4fC8kzbR/i7D5f1g7ziL+ow0ddIlQMVRaGGnV0WxeOMyw8pIl8BSQLy37gHW lg3+Y0TnISKhDvB60cJYr1+/vru7896/fPkS4bKKvZXnwFe17Sass2VBJjEc9qs19gNms5mtRvNB LSnWB22oh+eC+jH97ne/A4+mjBs3JukePh1T71FdmlkF3J82tbnEivATefblcrlcLm9ububzuafG Fuaco7p0R8mXaNSHA8NX3Yb2RLlsoAPbpR9f9LzsjY1+wGRCC3L0ItJNaNUbXe7zpHpjXK7tQhbL w463adUhbGpAWBdO7e01+aN6GW5ckmns+LmS68XwkQgG4zBEXLud16zhpMyHcdy+WK9WFMWLFy/g A7Hf7vxiIXJGanc9CKoSSOh3aJdxplgX7YKuhhCQgwd5vRJQbYRqWHVWe8ukuwjdEemR2W63iEmE m3zdV7G8O15t82IHx/EWgGZDCEDm7VRSDSRIGKAiR2PxIQJuEREMWb1uFc/r+tqEzhyB+mzKOvOZ dfQbAWUjdHMr2oW1XpPkk0EfE/m46bimdzdcCc7EKamYrklUjlUKohiBOzm61otpwa6xiND5Et4Q TJ0iadyLbNQJDUepzOfzv/mbvynLp3/9H/+9ftpuNpub2YL04OHuUwxHc1cbRWIjQs+BTDLY7hdU FPtxYGSGdQ9bjt5eVx0Gt60nQ6L/lIsjADeuEdHKuaaKWxZri6uSA91DuHuINa/FuGfpybW840hn dNQfm20xAagNPnLoWhzOepDMwl3MwInIfD6/u7tzzu33+7IsJc+32+3N/V1VVUWM5nv79i0MLklU 9Js3b168ePH27Vu9ghiHh4eHt2/f2rIdRMS+EXLAEI8UbYfzIzKGPT4+onJC0wjz+/fvbckxALY3 JhN16hEDoeU5E1TjovchOC246AERgrii88iRiEfgN8odC0IXlNJfyW3YtOVJ+0nUTIigX8nkR9EH u/skobBaskOzfodY3kVzyAJGGA6AiDRkcgoVT3CQuhlC8wa9lovVe38qsnEZgE2mtp48et4eIyot /6SiGxsRVkRoOImswgcS5kQaHba0q5RRh+HAnpNodvnNb37zT//0T+t99fj4eDtfUvQV8EYJbJ1G u6B+0V2qczgc9vt9ktVn3HFaz8k1SPPcR0awvP2B26WY7LM8wYByFi3pnl4A0j4mrBtzDAuho2co nDZswAK4jcViAX9n28IIq/Hja6Q+BPxJqDfoTH27Xa/ngqIoVqtVXdfIPlxvt8y8r8q6rqu6DiGU FIjo7du3yqraeEbLbQCcc19//TVFjw1SHt03dGexWPzsZz8b6k8I4bvvviOiuq4fHx9FZLPZwENL nQy++eYbTUtjn4VEjXTd3vv3798nboVKMpXhAPTaaCQWcFD6vdvtlFVSjgflMAHM3NQBrVtpsoen vwemEGjMSVmWUPYEU/OcDIOofA/GgoQX4KKcc2JcuKxex8paHH3kE8YioY8Ifkw6fwbDoaDGIWjt 0GOtfiLTvAc+HsDad53zIxzPP5vUXlYLcrHqcjpMxynwYy3L0mYWsU/b1XHOzedz5tt/+Id/+D/+ t//9UFVYvlYsg/Hh6B2kdNTmzKyx75AktP9n+STS8MCT68+Oc1vDsdc7/Lv97K4LRdFtprEeycSS MY7Yn5J7RiIUmBnIcTabdbXKQ+mAEqo2RefxkfAodh4+jh5NAuAdeyVZUHnu8Cv7ojzP5/M5KNY3 33wjkCGZ9vv9/nDYbDa19KcWIK0J4QAAIABJREFUffnyZZfb0GabKseIgAOG8Y6IkFdqvV5bDYcV xDH23//+969fv0YQA5KW6v0u1ppQydsaE/FhsVgsl0vd89L2TQS5tYpd+xl3amRsXddga/C6xWKh o7ailBrr7doh6fv1/o72fGFQb9++LYri/fv3zrnlctnlq96+fXtzc7NcLsFOPT09UZw6qzhJDN9D FpyTPUycK4AWst6Yzy4AgwypYqyL37kU5Uq4XghD+JDdiFZpNgLQi3wkiFXBZrvqgpW/lTuczWa/ +MUvXrx4AUXlbDaT9bYoigzLyoGIpD5WSkt2m0THEUydOgfgV5RU1uBYFYlGevhcU/rsjG9XuXFk EdraiGdhQLvcBhGhXDisyMkA482N/NHbT8S2ABWqGgxion4domTThemmJz/F0VBJq09P8Keh4ZgI QOjJYl2/8bIsWywW3vvVagWftqd37ygWzAPDoZpOFEPRtOVQM8A/A2fcItLATQpzlYUkNGUrYJS3 wmqyfCKy2+1++9vfKn57eHhYrVaqroMXiGopqqp6eHh4enqCuK/R44nHt3UVKMvSmiS0yjQkdQC8 ROfzORQnWojq8fHRRc/NzWbz+PgYQlgul1C63N7e6lhw/awVUe2I2k1agdDMIYSnp6fD4fD9998f Dgfk48oiHA4HsEoist1uob0uikIdgBoeAO3TsQCkxdJYHTaOayJiJRYxRZEoCuTUDhSYzWaZNn0B dtbV7cpD1+z7YXzRcyddzXNgi+jBwMKYuW6sDzqbIaaSbBQhP5aqdtLopHEWSzghfHQxOZueN4ga Wea89//pyy8WtyuXZy7P5ne3ROThjE1QaGkN2NCqBSpEUeyGkU+3F6YRGfqmS2MjOXd7hvscG+Ak i2NLIViLtWUvPgTDkQDaRKYvqKaAHA1fctqWhwh7FHYC2LErjgD/0Ss89M6V1Wocxy6tmUke7L1y chLinT1Dm9DOGXaKiXd+IJBpTprPruSYzWazxQrVzrz3qqUvyzIwlWVZhwBlABHKAjHItiJGRaSg jkkwZ75Y1IfyEETynJlr12AhJO4cJ0O73e7p6UnxzH6/h/kev4I3ohijQUTr9VpE3r9/n+c5qjdY wVj/7Tp4Ju/VgTw+PsIZBUUidfJxiMAJPT4+wk6x2Ww2m81qtYIUZ+0UZ60IRYbjpFIB7MV6vX79 +vVisQghbLdbaKoeHx//7d/+DdaWP/uzP/vzP//z77//Pg3vcM455/MMjFd3fhC0ogsEttIOTWIS MIwRWhxQAVg/9vt9VlWVjaIZH7Za4Cw30GtQSFHPKejy6dYhthe6xOYCNMHMh8Nht9tZxYAdUWiP lIx6QBUhPw7DMRFw+Ds68Ba3gQ5bHdpyufy7v/u7f/7nf/Zl8N7Pi5yIsqaiCgrANg3aujMUTQzA jlYjKrEAgXWOofOTlPfcLOkutx+m6Or0/in8gbSTWfEAV/FB94A2DgExyzLIdsBlHI3ibG4emgcR 0Xw+3Vp9ym3bkr/605ROqq5LRDw3NvteFDHez3NhWvuT1ugn5zamwBC6du00jOeCc+7FixeoWgJ9 wOFwqOq6qqpGw7Hfk4YOMCFWoK5rpfcjHXaxPCwqcxVFETwTUZ7nIM+ffPLJSAsQ0JFZHJ/hGZ3Q DhDCoijQJbAa2oIlTBZjWMVY8l4cEz0v3ZkHFVDuCm8B6e0GdV4A1ocBjVsZSSKAR0S6RVCBsiw1 mgGhgjjX4IrwuFW9EJGUBySJtgPRFzEzdKv2isTK7WrJbZOe5jM0K8fYiomltihKhL1hSH9yICJ1 XT89Pe12u95AqRFQpr43n9LzgsRA3FP3NXlX1D0bwG0+CccGbXrvidk591/+628++/l/Kt+vRcTV IiK+goYDwmuTWqNr0uvtVZAwywtwG6gdytJoWk7PlMR/g3B0g7U/KuLo5UjEwMhLepHLFOgqNj40 4C2IT4NJRd04uu4aXTuLFRI0g5B+2O/3QEMSBZpeq1nSpZNzS0SOHTOH6HFGRB80aLx3LRK1/Agf 9qG6dSnYLnWHZmXQ5HriizARnHPiaLVa3d/fQz5WabWqqrIsy3DU6tsPvU31Xof2XotlMnMIR9su Lkqsj5E0CJWG1lvP8xy90jisZJbUiU2th6pn1fZ1w+tbekek45XowJFsJM0zoeRZfS1tdqKTKpxx 0AlP5El8uLm5effu3WazKYri8fFR9QgYVFEUn3766fv375fLJaKI1WdFx17V9Xa73ey2UM90JUOO YJk2XIEU5KKnbcKm2Juzs06aqnDppwtfpHPK0owDSDh0dDZDsF1OZpdwvhyrZ4GuC9V5nt/c3EDx 1e7KT4DFLE9w3E9tp1GcfA1zYiZmXq1WX3755fbNu9evX9PuQERcB2Z2TTvNaek9lvYU2VfblFN6 2qeMYmh3JXyGXanQieo8mRJmIruQaDjOffxKAHpFPdjVapVlGazIOOE22UYvcDQFJonsEK4sMTd2 iHH86swxxMnRKOUmw8kploG2UsnMSCTX1BW5aOItukzgI2Q4LgPr3HMWefPek2uq80BVycxNldTo V0hEVUSSekK7Zp0h0YhNPgZIO7UcPfHVB186im29DuHbe6/JNG0KTiszQ77XqUh0A3ipvki7NGRd VQ8GRTLd27gVaiAotqILoVwLbu6OcQSg20AjOsaEk2bmn/3sZ/f39//6r/8Ks6kWyAXSzrLsxYsX IQR1QCGDq9H5zWbzH3/4/dPT02azoeilAd4OJWmwu7RZiboNzQxku2e5GdwjCIs9C9SsMOCwdiF0 mamht2s6ATrfhImtEGJ8DcWzofE1E9vRfYm9nud5EvZ5GYx0AKz9+D1EjYZDYtiI4YLTnmMSohdV s5S/+c1v/vv/8/8+rteHQ5llGVUV7CUSUx0rUtDW1IdDu2B9jtSeatmCk4qBLv9Obeayl/L13nk9 MPNPwTe2AIn/YE9Bdg3qdRwx7FCIKU90NtQ0q2havcaQ2F5i4MO4LDE+sS1ugxskrkmo2Dsmkaai xHWTcilYGvM/H4Am6caYyNiBNfFFozYDw5HnOUpmHIzWUPeGknmpifqKL3Jf0n3djZE8Nzsk5iDo R8JQY1gRQvpk6GCqbKpqQZPdddGCzlKIecF7s/fiWezhEIuhJP1URsTiRlUhWCVKF3H1QsJPjN+M t8CXXDsJJSheXRTFzc0NEDK8a0M7L4h6FKzX6z/+8Y+Hw2Gz2TAzNCV5nqs+NYmPW61WFOmylpvR gdtISViXLrEFnCQYU+63M9hFcMnidRukuJmsN81JJKLchn2j8ssAMNEJ3528OlEqoqpNsy3OnM+J iE+lw4kMB0CZQu2TmFzIEtMh622//vWvZ+QPh8O/v/kB+8a+Lssy+Da7vkym3Y5x1C5a9W93CN0H LT9h7+nlM7otiIFxJcdkDUfr84+j2FBwzhVFgQ0G3QZ2gjLKpGJA80QrN53abu3MY5Mrlod6Y6QP 0gfJPY38Sq0l894jrUrTYTIo/n9Oiv/jAZaV4lTb1IsXwGw2u33xYJUEVVXVLEQkpkZSciSJSExI goXei4gWAfdZR4WwHuohyhKM1yGc0BUD2/tDX1nvLrFXUIyU3NkFO/ah2+x1LI1Wd0tedJKBoD7G iDoBqwqKwxEzjBONFGd6D7xHNd1wt+ch+vwiiuL7778H+7LZbO7v75+enhBsbFVoSPylCUyx3Mpr auY07b/3PtPqvTKsUJoOE3Gxawf29L60vycc2DmYKvAzO3HKYA7gMA5gtJ0EIWEWx0Kem3mf5fPl vHoTfmBxoZK6DOW+wj1EVNf7w2EvjVqRRKCDwvKEQ30IJIub1eJm5aAoMGmw6brJtJCT84F8aDXZ nSLnXLU/hLxwRBxEZXMxN0iMbirLEhqzuuaqqhaz+Rc//8XhcbNarchxIBHnRcQFESJ1znKmJvBE 6MqUJ2XokX0oFITMWkcrcKS3jcNIkFoo1KESCtaLxPSKqG1s4s474Q3r7L5iQiPMTHTaqfkC0BYt xwalJQwryf29ayEmT0PjSWPwHc4LUqQgINBy7Ylxqq5rqoMTCkFIRKpaQmile+fmjzOfxeA6ioyP Z3bO7Q77rMi5bhQeIYRQ1iKBKMDfjohCqLsy8RXQ2WNsr8joT1ec3J5YXP2jYRcmTn9is6zsiZna 1VWQ+Uq/Dh7JnngXl+zNuq6c+//Ye7Ney3HkXDSCGta0p8rKqqxqF4w+7YPTB7bhp2v4Pvif+z8Y MBrtESh09+1zujorhz2sURLJ+/CJsUKkpKW1h8xq24FClraWRFEUGfxizplmRb5kzpgzy+SYrHFE 5HztvWfjyXt2TXjLEFDqHfkez6HeEbTOsct9XeV57skAcBhvnDeeKjY9LmKYiszW+3q3e2iaJfPC eyvxg15FNY7xjTClM1UAHC2ItUI/Wt5I7A6AEdDHjFcyknthR9CAAwvqXGio7U1660ydXbCCADhc SGhJRMvlcr/fS7dTIzi5xpDLvNuvH7b39/VuW1ctvLi/c2VZVgfLzORnxIz289x4b53DtmKtPYo6 SMHtlUrMGEPEnbQkT0QbI5SaYE7S9Ot7hWb9JQIz8dKyNi8RkSTK9aH8x1B6kugMBGigOc8cGy8n jOd0O+tms3n16lU026LbmRmWeEgSqeJUNDTAHAAcemTECdE5l6lmEQEnaONo/Dv1ihysd/hzXErQ lMpS1CKLWMLWfwoH6Z3MKT7ggeNwhnvPD7WW/vrENQWPDaANGNehXh5J7SXk+3JDif85mJGo8dKY FFC7FqyTBTL0RhJWZoxx5L33HNamc64kb61lPlrNdf97HYP+myLSKx0fIlc1JodwZx928tHmKjYv JOOhkMrC5ZlzzrP33uObDvUt3fn6OxMOwLt8frRrHw6HXrgJXQgmzHa7tcccyh41EzTmGOoeqW0C kw03glHsdrtUoZtyGNnvvfeHw0FjDq8Il+k6I9FsfwRPkPGE+0WkpJdfxUOAQpBR1MjQQtMnd7vd ZrM5HA4IhBazCGxtUEvJRxnavIRdROgi19/42aO6Ryhil9GfUg1ruspEhky2nGPjiOiioa3dzefl dru2tm6ayrmG2UPk8t57b51rlMB3BHFZxt57Jl4sFvP5nFTq/pYmTKz4lgFqQiVATeKUBIJ1rZNp Z0KIOSnb0DGuyVFm8vk8OxwOBh4eQav5CA2HdiaYgm41YxpiAdH18sUFMqYXR+M81FrHgjYKONI2 p7R/krz3RK21a7FYrFYrJDKHYQWcMdWypjS0nOErqmU7ZKeN+tAOvnUujOcI2mDlSU1EDEd9Za13 5IuiOBxaPz7nnDEdPMR9Jv//Jk2RVCrf4hHQNoomxdb4zbffmizTaak8d/QjjwaFmGaI3YAuQW9F Irv7o57ySHpqwbFA1jszi+PFFPwN9gVnJh8i9gG7I2cLUinApYcmOFcCG6WpHISZy+ble6pMjOG2 KdRitYFGADgkCEVvheNamXA7WVtbW1fVnjJD5IyhpqmaplosFlnGh4PLijzPc0+W2BE7Yj5WRQ5j 4Ymcb4jIu3ZADBviLO8+7KXkjJQtdth6wmtECRGJQeOPkBmA/PYUNEtMgzd675EWZr1ea+d8FPuR 9Fm91kEK0xFbAnecNFvj5EiH5cqT8a5OxQ5Eij5N6KG1VqNvE6oSC7bA2ErtIuecJ631IgrIozdb pQlxPePvNbT+BfnSKICQg+hK73s0HCBZhxOXtGyNxzMn7+lrYeTXR3MWwX+vX7+GkiNaL6SYWnq7 5KBMOyDzWVLOuz4HDoyhtZadj9yk0o8S3cghLIWU4Vys2pjDZVkWpUEA3uOG6L8poomyGShiONh6 syy7vLxEUcCzWjtJE/W4vdcI7zLGVFW12+1ubl5Ru8Gx/Aoa6bZThkJBBr3GFBBwOY7lRheSbURF 1HCMn1yIf5HlCUcHufhxgv2U3dk5h/Q8SKRGXXV+L9NOm/3Nb37Trv08Ey040B7CVUw+KcYC+5rw AZx8akb3EdIAVk72DhmQr95N9cwzw6lsnCoFpHkiKenfOZfRoOSEmbFcLjGaOCkaZu7ze9IdwwFS ybZ4xY1bavs7MP7xrLUotcXdYi7R5opZgpWAhaGHJdVM6LUq786cERnY9S0bZiYDP4b+6CRp3HcV GNJJ/ab6zFloY+LOPX5ZLzN6ikllqM0pnRknIMLZbHZ9fQ2b1IjqUj2oVTUL45NoOt0lgAwAjiFR yYtZysZO1tELnvWamid4TzAVqbl3etU8UTr8z0daKpiOEiKIKTEdUKERkWXyTLrIg4jsUVNTkISO sEu9B0xICu6cy9QGKX3TMwTYyDnXNC4KGujtngvhVy4JAmBmCHKpyBe1Ay7dBgljMw4GdA01SMEa gdd4hLTvH1UEZyRLltZheO/zPEfuL0AN/axeXKVJRgYuolnWFkrzQZ/EzFHi1JFe9f7ZRs7I3yeF tulmDmntpJZiZMpyiGtKaQrc02qxCMSQEveRlk4vQoxpBMwjSCt/zmYzPzExV2hcjjF3BYf2vtR+ v4eVMfqKgBRSphxrAOpxxCDp2WZCqAheikNecwr11ZxKhhNB8qiRcYqmx/hSOdladL33nrgz3SOB u7fNdB4efxo4DmdOAI6TFD104itD6rq5uRFxU+PLCGiK1td7aCwa7z3kMwlzBUOXG7W010sR4Bi6 ZtoYdIiDhZv9Ec2fK0/3Xv6MWGRif/zTajg8C5kne/qD8lD2jBE7TWStzRS3h0ZBrpdk4ekApDxT oEav71Hkm9LbPUwVBD6ItxA6MG6VFjXe4XDgECxKKlBL1IG998rmKItI8jZREAx6n4vLnHP7/R7h HvKC5wIOwD6vtCa9vA4rGhrozWYzZPuOVBrpjmOMub+/X61WyzwDJpNanlovHt0V8WTuFl87ajjy UMPpUzpwTKQpyU9TEp2/yIUmw3RUn4c9znvvPDnnbVUf6qZCLIPENZiM68b2RC+EBxERQB8RHfb1 OG4Y6i8NW3xAdV2jOlF0XjtLC54Ql6KoDy4EZOs/SaEuWTzr9frjx4/ffPPNeB24iORjeR2Oe76z 8ERKGVMvq9JpDUcuTs0r7flTgGOE1z/FpIIUxWJJ0also4WthxeyWl0fJPBE59UQvikHNDBRvXKI 8c1ptjAUHdZLHEJvXNOajfT508/6bw2HIhNSRJx1Sy/DgWXZGEMIYJ6Xu92uu5fHKsyw8cdNaaWL 5NykID1qKxsnHRninOBFq9XqcDi4QHRKCY1fgQ+wbTvnUF8e27Mk2E1JI3ugE+89EihMz0ntlDUc CEn27IkODFqLL0QDCwGCynw+f//+vUAi/ZRe/NGmdAvIablc4mVFSUNE1lrh8CJa65YjAQYKIUi2 IFx8dBodUq5+LkpzRoH0TklB+IvuxTBJijBOAsOkTS0myjTqHdDoXlF+SAuwb539noHkia7P3mmt fXh4gKeS9Mpau9lskHNMzFJD3dYPGgG/h8Ph/fv39/f3VVX9r5//D/lJTJ4n30IG5BMIfydnrIDC IVtPJyw2uX0ccLzQeimKoixzFMNsu9HVLErew0i6RfGIum59QnXyXOpTBflhB9vjmSRGMe0wrIid n6Y45IY3egoy+69Dzw7cpUHnXFEU33zzzcXFRZZlJs+yLNsHFfpxpfQlvCqK4tDUUbOpjjP67tG8 ZZWza3wywADHKhup9x46j1StgpMA3xBBy7IttgBGDTt1E6rURiMseL1RhZR7u5c6SwlEIBXQgW1l yEB5kka0CyA8Quf7kjjeaGSG1Pag77777le/+hWFPcWErEt6wZLaB7mbck1Ikjbpx7Xpw8a32KfT WQyFlbsihwRHUpXDBfFLfCWsWPhaEzYZYkOMlBjGsBmRUZmNp916w84j2YDxxM6XWU7W2ao2REhm JE3Yrg+UMWY2WyAoHGfUGA7Fhh37E3DVsaxiBDggE7i+UAJjjPjcmZCch5nX6/Vqteodc+89gCrQ lVwjX79q6kNd3W/W+ax0fEx44kKXT86QI4d6Gd3GWYRF8rnCH1K1yhQQZoy5vLy8ubnpTV+rka7+ FlBp+BDIKqZufaNTMcPR7RHJ1nJWQlAX0pumDyXTsatGjx4flk8ARzQPnQ6UP6U9pfdZvhvrQcIV NcI+VXfWGFPOZ8uLFTImW0PGmDKjcj4DS3LOGmOc758tqb//eM9lM/beM5vorlTcciG5Z/poqCjS gBG5SzRATShkLbsJcIaYGnu3Pw5+G7Khiiep7ucQ4EBkmcTmQAEpD9V2ll7S8MKEehScuO5RmLeA MrLBI/GXHliaplaJmIOWUuTVWKXPl/MRrISCJHqdXDf6QvSIZSwXz2YzaMXl115LQUTTtzrsvtvt Vpf1w7EMtDGmaY5TSix5ePR8Pkcg2cnAjYkkJQC0q6AMgmYxWGmaV0oPh0ZAZokE8ujzRLRer+/v 71HN7n//4i/SFp7rNadTJJqfRdDiijKs54KB43BmTN46a7/xE7yDQV9//fVyOR/XlgXrSa17ErR0 R05hVVZZr3Tv2sjyvCQiETOq9YVHNz2G9kdA0sDviJ7W/8+CFfpn4ISe9A6dU+kdz2qB2WAXlJNX V1fgNqvVyhra7/f4xbQXeGYm+5yyKJw5rHqtoLeIXVI4VCiEAk9tw8d0GhKTqG8UpoHFItwS1cvk idHS0CQAvWma3W6XXuaDbwr6pk3JHEztOo21Cx6stpv5N32uHEM34/0x6QgnqiYO8YkUlDcgowpZ COc/iTmsSjJGYaZJBrOIttutJI/XlbMoqGRaH2Rrmbmqqk7ir8fRxNvPhR1CMj+cc37ypMfHPrk7 olcoFSuTCSOl743QnP5T3Oy1vfwplLYwwpdhnkTSWRqVoZFmDjMA+Wt7M8PARLrdbrMs2263s9kM ApL2Y5n4jr18NoIOI3tGtKhGLhtvh5/mR8KjU3boR3RefhU2cXL+F0WxWq2Wy7l807RlQZkaiDdN 42ztvbe2pmB2kTRf9NhgvFScSklMKj54HHN2rBPbnjdwIjtyXgF4kUQxThpwSA8f8V6fhrQKuven oT8jasXW81+UmVMgLckoYewoy7KYlczMmSHD5aw8VBVnTERZ8PD1wTmsp5/dXk3ET+3IeCLZtolD Yer4PTNjmKiuqswYUvUKBGfrNkEukJQNEj0xBxLWkbJB6nI5TFpUlklfB4BDfsLHAttpmkbye1qV 3hQ0Mj66Az7xwYy6Ef2ZWrWmoQ1H1NpHZDep6xoIJsJMIuW64BMT1VghZX6S92XmXPRR0RCcte1N p5PcIRopUTwIDtWKJgrbiR5i3UKbNc+PhRQCJusolRG/ZepAbCLlLPlcFgRtrCHl1Nl7MfqMCyJc PNIy0oj1XiNR5kQE2JGxIyLjx8yHqS49fW6EOE/uZPKriOPtxSFKRU+MoUboKDl9OolWnqv/9H0a jgjCGmNQLSVqSo+DUcl8ZFEQpisKcPqj2laz1JSxTnoLN5i29fgWydCiDL1TOQlC6RRDx092NL1N 1P28NKXI+KmtPUp7MX6lngy9qjsMrzgQ9AIO7QbEzJeXl3K9nqhebX64K+3VuGt/7zD28orxdkST ISkQtR43kg+F6rqu63q32yFdZiQDyN7fu3+nc1IQg+bGokWA3kIW6XK5rKqqKArssIfDQd81PrtS VknKcytCsXordMHvRAJ5UgQQ9T96FjPf3t5K9OJQ31wIBhZnDNP1X9aLWphVTx0XoZQ3ARF/MsO8 7oDEbWau9djQnNp6X5ZllueahenbecCHo11SzrOn3WaLA/bkrTJJ+BjCa4QRLnOUFm6YRmHmHZ8h qj9RlNmQeJi6s9B1fZ4FnErNQP0g/fkwmGLhg84D3KeqqoeHh6qpy7J89+7dbDZjdsaYMjNVVdV1 rXcX79sABWD5KIHgyPvqxTy09nrV/uAS6vgE2hBKe/WiO1y6dUW4B59AO1VBod1rSYnmA6ly2zZk KbDWegcvUSeucJQAsl7eOk7eezN6VQo4oBVz2l+kjXFoc84ys3Utb8KC0nmWIvoEcCRi7i/U+MjJ vms6U8gn8SAu+OvpPovsrjabfhcK6DuzLLu4uPjyyy+Z2TF5eNhnho0nIs/k0HhmhhyBx2kinGpC wfSRC4jo6urqxx9/VJxNGK9LcRX6u92um6Yyhi4uLpbLpVPOsMGNoyGVCMAY470NLYD74ykOUJ7C GsTK9d6GFeyMIWMMnO2223WWXTZNleemaSrv51A9qm6PbBm9Q+26/7E6f7wAybLz3KSPYIYkEEUy uzYVMBERFUXx4cMH5LEcijcWlqLHwQXHlP73CcijAzg0TpQr5JFT/E2ei7Q01jQNgCpRqPbTJUyd q6srZoZnskzfXl0ZyHUdHdbr9dBPIyS8Ujeu1v8jmZdefrIbpV2CtjB9KZR11e8eeYSIslHqJhAR Z8Y39u7u7u7uDigYydCKjJxzZFvYZ4xxVmk7PFHYEZ1yZjaBaELCGU0nhOmQFzXdTcdvjEZPLuYX Qx4jGg6xdGDEfMg+1+bIJyIlTklrArDkJ62Kg4ajqirnGv3QXoRxFlajbixP9HbYqCLyTOBh8hTk h9Uz0HvWs2J8y39e3cMUerpK7KSGI31E98wYRNbCtL6mDBx/BOUI8IUgO5/Pv/zyS9FwuDZkwxPR kKPo42hoSE1wckxBVUSuL/aqt2Usjf1+z8xFUZRliWxJGqL5RFMIs5Hm5NFkg5Ageczk6ahdJXGO omzwwejQnKr39iwkJiRJB6B/9X1KVoxPVVUS1Pnw8AAu1PvtxRICP1yxkIh37bgzbOvQEfm0O5UX SGbnEN55dtIaeArqDXy8bGD+i44OFTUhu0u+RQ4mlYiJS/tEtN/ve1tOIZceTUDmFqVJYnnyNGDE mU4SnCIQUM7INT6YV4MA1G75FxcXaYMYkEiAbtEM584SeUPkP378eHd3R0Tz+fxQV55Dvt7Aeowx TagO6r3Pwlji6VIEB1D1vFE4AAAgAElEQVRX0uxgostHMUlm2CkUNsmjPaUXx/Q2OKjP1H7+yV1P SfwV7aCCGLQWV1ieFIOVe7Xruw+JDiUJgdxOwZPDe4ijEMhOOMfQBFNU95b+RkBDGg6r4SC3JmES KZw67oFDGvtPTM/I4iaaVCaSc21RVt9nGpPpPT0gS7/p5eUlyk8aY3zGZJj5NPILZ6a+wgi5gdoR /Rc3liAghcXbu48KOJCoVOyRogSSK4WZnJQzXSCtmBSsBrYmtV1kb6ZPVacM4MaFsjXpBangKhiL uZVIj9iI+z0rNCADuBFmBQ6P8JxegJXbpLQMDgRkYHDFz0j/+lOgCLWhq4vFAjlZcZJ9u71FX12r B1B/JJIAxuVyY8x8Pt/tdi+h+Om1dqXmxuhXfCz4G6bWOw4BooAFh8NhNpshT74wx7u7u81mA6CQ Lj+9vHVPWJl+ZfmhBZ1b0AWnZSwJKVXT+1JDJyErk9o4hwZE+sZdv1Ef4tyEzT270HyWJlmLm9JD UjZUHzyNJCWA6y1o3KqCOy4v08d2jE6ZVKL50JpUdAOtY6l6O9uBFybxdOvvyCdRRz1bm8PNPvqJ wG0+6Ld0O2fJ0LKW8e98Pq+zY8IMZo7Y2jMKnEPtOOeMOQGYoncUltLbmlOpiTBiEITOwjeUqJHk oRpzCMOMdDC6G0IiH558tFMunNRnZzBJ5lAX3IEnymNhvztami4uLuq6ZqYpmaWAMDAtpauigUMy IYx20zS5jE7aOfkq0DHgU0l1vpejaESQd5zacYm3wCEGFBUYk5mhX7MJeWpxvFgshlozoQSaMcaG D09EABznv+KRhmB1ZBLChI6APBQJstOzss5Sd2Twq1UVmTmY6ERBgt3g/v5eijUPfeiyLI/aozCc JgRDymVoRACNrLoou9+QqJ0u0eFRPE1DGuYxFfYTNBxavSGYJpJNBQSb4NMut1jbUTF67yG42L6k 9aq3gBo9NdueSOPtSZTKUWulAEc3DcTRpGLdEfk9b2//VGj6i7ciAbXrqFFZ6vmcICz9RJ0qkLyZ lQvHRMxkyHMr+D7vW6S3yK1aMokadMox9t27d3meU8t0pmojHpexWjqWWnAorGupgy2+C9h9YUMZ +S7jKzRi8lpgownRCePudJEBgYJuxiu/nzzPsyxzTGIiH/o6QrKbQMnBoXQGJHlhDjmsXNGLpf3r HYsXojTWWTiyT3w4Iv0YEaG63cmnaPsRdb+lrsOOn1xo3zlHIbWDMSbnI4J5RhzmVH43OZl6Qsi7 y46uVVD6a8o10DHiWBQMGodBjC7zvCzLcxeqU7Eq4CDapKJBm+APTSfbf8rci0aj99fnNakMUTTx UvZRVRWz118E0oPWcPRaH/joQPfMNAVwOG2HVYDDddQjSs9ExqkQO6HxDewT8J9PQ0P8Vl8y8psP CbajPJ7pU4bawRYiGSnm8zlnxjnnFAgQx96XA4XCCsAfIotQxPHu7+/F7HhSPQBXNqtyclPX5yNS Ae73exijZUmKPMZ9ea4gBOJPvYqFD6f2i6cQq+px1IU+cgGHVO7Y41PFTPTuunFmg7HlELskM0Ey mInFfKiTPgTti+1Pgmvm87n3Po94vT6WPS/a+fQbnjdmjyUT0sOdfKL33jCT97ZpTnZOXkoCrNG+ hE1zYjsgtU9UVUVZp3T4EKhMOzl+gWAgDXrS7d97L5MAXxozMrJ/gYC4Zf1IoYRjh9GIc857kxcm z4tZ6cjboAcnxbpU2NXRW17cjtAHZoZrAs6Lb9FERV968tGbjSyAoRYGquUE6fyZ9rijAsB7jINe VrrIgHONFmsOhwNcpxHWr9uEjxh8pfPcKPnvOenE+ISP2zRN14ySMtyjxs4ngUgn145User0Lcgb 6nY8JWntk6tSeiCschg6xcs67XA4gDmtaRpZkvrXKdR+NcNETIY9kzdcLua1d5Z8bR1nWUPOku/o 0pg52T4ncryT5FRliRHa7XYQJo0x4gPUK16KUB6Vi+NAPiiGRSGxXq9vbm6iXvmQgCTyXeCgTtb/ YqfHut7v90WRGUNZhmFzCH5hZol5MSYeusAi4vVmjEEUTF+EiwjDjXNN01QIjYlslNFK1FJ6ljFU XaJ6AF5pvHMhYSvGGZqP3GSGuM2hMvzxcS+2JDix9oTFahzHQWWkZXeZgr11/16IsK0659j2m6Wj nkz0PsPrr9dr2apZ6Scxz/C+rawGHBC2/6ZpnHWyoe52u0coOXpNKoITsUdKnq7eFmQlNE1ze3ur BU19jegAcfDw8CDOPm0fwpdF+Z+hxFNDr9A7GYA5lsslSjVaa5EnLcUc5wKOs8AHXjw1pgra4pcX nTXa0H9qnsXKc0hboBCltd1uYVXZbrcQcEUiIaLFYtE0rmmaIcCh5TaaoJjVdBJwrNfr1somtzCb vBBToL5LdgjNwSlZxb09DzreTohBcuMAX3puf51PxgA1uW5KFS1zn9WOliSXy2We57l3zjky5L3n Y9Wt46Clj2COC1WdZM7R9i+d6XXb1+yxDcsPweT6RXpvpG7aTRHDvLIdCKsE8/zuu+90m6wsznpn 1J5wmi1jYiP9hrV2Pi/T1+8dopME/o9s5SOqHe1Tojus+TPOa48cyctiVFBhlmVkW3UDjOPGmOVy Cdgxpc8SW+pCWndjTE6k92ZHdPQ76yOmUDTEOZrNjsWlpvTg0SQ7paEe3892cDGNkhXIiQNzSjIi UgRITHcGWFTHhoToI2OMKUromihy/m+feHpi9c4eMT1I3xpVuSfSOWndu4xM1Kw2muAYgTx4EBtf znJi59kRUVmWi9VFVpQ1c0XkTUZEBsIEk3POePJHfnT8HLKk9XwoimI+nxdFgbIvI7HdJ0+26hnv WSn5+wIojgfyKdiz8+w8e0/Os6HY92rKPHk0iZZVQ3ljDNystKqTWrh8jENBcApSGSLr0a46NE1T N822OgqF+XaDrV0Eu6PTNB7XtXmz6y5bPsN8dsRM7J1zu+qw3zdSzEU9tIaKKyoKU1c2yzIOKMYY 45BCPi0eiqZMuyo9UVaSc85w0zTWsF5rZ9BLg0tFz88YI426FpCIUpGz82ebNbg9bueKIyrmM0u+ nmXhEUTUZiDS2qfecYtjlNL9NfrdHHX1+L9eGuFyvTu2vLRp6jzPPn78YL3NOTfGs3FsnA9bmNY0 sHFElBlEbxqTeTbO+dqQz/IMaSeYebVcbrfbandYb+5u794TiyYDACvwcyZPjcl8GYYoywlPz4tY 1i1nWdM0F5cLEohsKMsNZjczoSC589YkEx4nvOuOWShdXs4K563zUQHzgD7DZaHauSWi4INrTcak 9022Ufv4jw3NFzNi39ganSvLwpAnZ+dlMS8LY1K9TM8+p/kAkMd8Pm9Tmwsdd9mw1Y0jiefSp02h Vl1PziYF6LQtTe/Ex5U5GqRqQspbr5whhuQ/4GEXApGbuvnrv/7rn/3sZyTb4TkmFaWNOH4yIAzp CdBGm4YkKF20DkOWKyQA6gMxUBF55ToKdILC98vVHLoZKO2JqCzL+XweVh38GCAQOKA6pSw5OrRD gRE9GmWvmXm5XEKZRIo1pP46vccyvHQ+C29Fme6sFrXqmY09G8HbVyZA0p/2JGYmJgB0zg8PD4em ruu66Rs6fBdIIaA2pP6kPzy2omnSmHS7bqrtdtt4J4U39WUAVfP5vK7r5XIZSY1YxVPWi+k41aKj BuZ5Efg+waeMHvFZ1BukwCtIRvXcCoW4pSzLm5sbcYxIScsqz7JkIj1/qqqJno4N1XtflmVRFFDi 6qb0i0cZMohInNZTCwuiBCALbTYbaGE1B1ssFscUUKFWiAu5jmSh6Q73Sv/6oed+JqGvv/767du3 4wt5XG3plVeHdCMKqDHGXF9fy8mqqiK1fe+ytcrtdOjp8CQdFGum7J2fEnC0O1zThlNKVFI0xL7X gb9vkcioQYOEPR7bsOtWRcIpad8H10tr7e5Q/c3f/A0UcY9YihHv0OepC9i1+IjlpJEHVhQs/TRg ptGwjIjwBCIDsztafvfunfgclWVZ7XdEhOh8bkeDiQhGX3ZssizjjvNB72tK/J7WjQ8Nl24kZvEO Don+0VxP9+H0Hvzy5LulmABBsiyDZwy+shRtIoWh9e7uvYczZiu/1vZwqPM8n81mReGIzGKxcE7e N1ZoB0A2NehR0vagyFFVVfu6ggYuasHZTl6yxWIB3axos20oqUWnlk+00j21PQfqndJtUpjsMwLN 5yJWnismpC0YIa3bcKEFZp4vF5fXV8gxqhsntZ1ziFWUk881gFrtfzLZqDHm5ubmhx9+oGDUFp4m Ew9zSXCDzMlj1ZiiAFCQd1wul3d3d/v9Hi+omSSHxFaQcnX9VYCPcY9dkFypI2k1JEpJ2hRr9eFw uLq6ur+/T70FNB9zIamPC94n8lO0LUbdxmRAfOLFxcXHjx85xEPJNVVVwa9W39tOvER+k2MBCd77 /X4fAw4Z7iHl/GckDkpYscxFy2xwL1FfFt4rMrkxDx4eHsRlQaJkh7qhh9Ja+8tf/lI0xkfdQ2JS 0UtLOil/ItBUdBUaTIC/w41DjG0yIDbUDxS0VBRF+sn0GR4ga+0f//jH+/t7qD0Wi4UL2UiLonCu pqDnYLAhPNYftxktHCDk3Tm33W4xPiLNaONOb+jd0Gp8OrYVLgOiLuvs4x085bnj/HdkBSFxXHSx tVZsx4C/YmJDlIrOXyLyIcmm4omCfW21WgGt9gpeHQbR3WaG3kuse5iQILHl9Y6DtbTdbvGmKUuC 3EP9gz9IT5RzJipyfoIkswVICyuOz4mMBXHw41kul8iUQMmnl2ViQrmQ/tioJy9Lse3SgLBERJDx vvvuu3//939PX4QG8rgIWhIvBFjAOdgcBbg458qyXCwWHPyoTIgIldFAar4mlL3kxCO1lzj4zp/7 jSiRPKNcDxHhBfE6vZdN7MCXX375/v17Zo4aEUYUvbUxxjN77yWOckSKzocYrnCon0L6v4k0qJ1T zKQsS7E7AK9cXV29ffsWiiMXHLKgwJDtMNWmyugvl0vBPd77ILGJM2LnFpnNFMzz1lokrseWb0J2 0aZpZvO5qyqnwu4pTBpAEDEDiY46kpiPAxBEZ804ZH5gprrG/t/f/x/o7ff7/YcPH/Lc1LZhnjGz yTMi4qY1amRZlnHmnCPfLBYLEXD1nMZbOOfgDmZVjcBxDcfQT4L0en8dp0gilDOn+MUkwCGNaDCq L4gAn+6S5CXEn3VdZ1nWNLUgSK3Eoi5jhTfLseXuwHjvt9utRle4qpfvaFtOz6/BaQNfE1+2ruva tU7H6Y1HKc16x/2JQ9JHpCRvPX77fx3CpgLRInXq1+R5cO7OZjPOTFbkFxcXq9VK+Mbx3m7pL1Y5 /SiCqs/0ZSR+cugC8A2J6pf1K/tx7yQRwCEKCXkvYAgOAa7ijUdBlAV/xhmNTrir+xmh7tKbRFpT qHdhLbKaJP0XKeOa4JJUyh16ov7ziy++2O/3qc6stx2gLupGio2IEGOeYrhBsjxFLzadxqWHqFvj F+tRSLVGpLKeRT2QQxiV7+/vcYAv9/3338snRGKlfLRkNuacbNvSB8Bw772z8fW626wy7QtJdOsx 2DoktBaHVmEKvpuoTosFksozGhlR5R0OBwmB4RAY5kIdOCywu7u7169fV1Wz2+2uF0sS12UoMPEt HB5XpnY+/bL7/R4eQ4fDIcuy/X4/vgBeSNbUK19DNz2evffRZM2K/iKafWselwJBzcRFq+FDLlH5 M9p3p+gd8ZUBDtbrdXApzXvDCH3fyMvggPApdbZT+fdkTzQU613yJ/lyGCsAd6KpkLHzlD85St9u NpuByeDPR0AxZl4ul3lZ5Hl+dXUFJblP0ir2bmnpx3oK4JB9tHcHTZ+bZdlyuRS0oQWtIX8gZgZ3 ms/nkvuYgqWDQuY9eK1pnWvUH2GV+pqTg8+hqtTkITm+bET7/b6qqvHUn9gmZGQippEKoumYM/PF xUVVVZGjd3S9bMRadap7PiRg5FNW+9DWJWc0b9VXDgk9jybdk/QrepVRtXvBUUtG3bEwxhwOh3/+ 53/GbEOUvwmkJ1b0bcqy3G63sMhIdIZM5bqqnHNlOZeO0QDu081Kh0U3IBRdgzP7/f7rr7+WdrAk 4I0YMWLpgKgZ5EHSrBamoTMncgiLWCwWmcl90zS2yfMckjT6aoKFS6NSrQnUryMeo76vHsSLkh4N EVDSXTAxyjIRZRP2Ks37pFkXnCuH1rxERUFmVXJkR1CIZE0E3bkJqkdrLTx7xNQ9m817Q6wtE6Uu b4g+9Q5+JMDiSEmuU0KljCwamahZmWbpFO08XP3qVE456jIcvayGMNOfIumvH1ZbLPj2vduYhgCO Gmx4vlx4MsvV6vrm1Wy+nC3mZDqIPP1AqjMdegTgiNC/V1WWRjqPnM6LxSLi/DA0j+sSMGLCq0mN IfaFq6ur3g74bsl1/dBTb9kSOiZlMqdMSD04sm0BcEzBLuPXpECKustnsViA52NDHOmeeKXYsGme BhyyUcm4oBUwl5EX6FfMjupFe/HHM4ISEcjw51HcpGP6S9Rhl1/x7lVVQYKPdAbGmN5hy7JsNptZ a2ezuVEeW7LfRILpI0gMcumjofCQsHVRaVDwpRKr5Mg3yvtKpcijKeS79MHAZKgxxrTd6gIOkNik MJhGZY3LVF0ubeTrhYDPS8d9OjkvI+CcQ3gqhJ5HAA58cZk/euGgNR05rCe8uJLhvDtm3jwa4DTg YOarq6uP93fTR0BPRXyIXmkSaYx7UaBoNeRXmdiCLG23JFME77pmoEn6DFLDCLktDIjn4MvFwYje q1iKGnk5erocNdJs2vgQtDpJzjmTtQ6PeZ4vlhfwEExNA75bLUE/t6+f53UjBTFTPH/FRiCKilRq GnmihhoRgb+FuLwep3Vtd6Yg2onb6UmKtudzeZ0JmTDgszkOJlJlz0mVhtyoOwbDLnUFJD0rZHK2 O5RyfBl6SrvvRPKWYJayLKekfptIT9l6n5EwIuLDAfFdG+qcSrIrdxljqDtLkFjCew9XU0F23TAQ 14RaQRMJ1iurUn4xc13XUh+uV8kpOklKVAt9yh4iovV6rc9jQrvgK+6cK0KU7OFwsIYa9mwtGc7L gjoWqthvAEtRZpFYPWWb0VqWkSnRy4DGfTiGWHN73P3JBFdz/DkSFkhE2Sne7ruJmPRoCwBN7xJF GtzmMVxw6PHWO2+dPdrd9BvhmioEidgk339KoiFw3bRRxwsGAAfmw7gO4yQJ5hA+ECl+xpmDACbv ffv11eXRbB9itVF/5PgZEUnfW5y3J70cOabGOzAjsK8sy25ubrxhb5gp05oK05fph7t2etX5szvT +76iAxh7i76Ey0OSVfqsIVzV22xEwo2NMavVSpQW46SfKHD/5F0p5XmO3HouZB4bgQ6U7BSRIDTS TxMiJ6CY1IPDyowljAg7oO3a9xFgHPUB+1pOSubQ90iNlf8EJAMUGVygiENCKuqm0MFP0DGkzhzY JFxAGDJrXfDPkM82HjclMnEKcfRqhwtPJAfg+sikNwT2Ba+AIvOH9EG8O7OQM19mWA5rkWcKICNj IqJIatBihGyopOZxqzcKuQJfTrcxTqkoTCMy3IQGjXJEjVaa/pqaoN4QMV3vvuOjMpvNjDHuqFNp hjCH6Pz4KIK0ZkfJWIArHffEJWqdn24qekEt9ESjCiw1n8+LomchDClFomtEZZjnOYWEIRoGcTBF 9Upj45BiCkCZQi/BLWVUiZ4hlNeFmElsEqvV6vLyUhbp8VHh0Xp45eQT+zDStzypFZV2Hl85C7Wu MD6Rua23q2nPJUc+pr1oTXQfIrDCoeAlh/BAcypyRLeAca7rWrKzD49HTHmew6RCwfw6crEsVa2h oT55VTqm1UXYIDCwmkvIMuduPm5jjBcP8W5YTfrETlUbH/Il/2QjU05qbPopcTfRQ7bZbHQ+ACIS ZGeUSUUMBBhjfAlB5b2IkhLbc2/nkX5ffsVmHEUJCVaInqVLrPngC9mrCBk6AwcLvMh+v1+v1xyi 2GVJW2tnJfKNqhbw7/Coy+wUWZa7NHjnJ6GJHZjS0YlbmpDOIqM/HwdFZZZlYvujYEeT20UvIqF9 zB6qkCn97FU3+pALTjMLjTZM18qutyLdIAc/NWbOizb9QFHkU+pcj3Rb1G+tOYVj56oIN3DXIjBl tz6p9kgH7dnncGcYvV4mx3971Qy6jehvSetpnWPOmDOTFSYrivmimC9m86XJjlpYLelGSo6T0O1c 0q8wAjUikgQBJ/dReUr0IHkpr8ygWhhLFW+CXMWjX5gYHKqmvOMjKOo5/BwE9+B8pD/mbjG88U+W /gr5FhgA7slD90Z7SiozR98FHe4AjibU95Jn04ll5nuZ10+QopEV+GatRcSKDdWnem8fQqNgo1CB AHdrJ2GJLhnqlcz1CBLqx202G+RRcMGtROu1uOuyJz9FD+Kg4JHlh5kEnby89bt37x4eHgRwVJVF aTrBZx3A4YmmAQ4KCE868KKYo7fZRz9pSi9ll7VJ4nbNvLSyxxgzVI/XWkuBcej2oycizYkPmt5U W2SCKZeTPIBgnUY79nN73oY8XbopmW/UnUWpikJ4X5ZlqL1JT8iuKIQ9xlqLjCNZfuSw0aZIfVvy yCY9EVuMMO7o4u6fZ887jTkUH8B79fctaiBpkEi57mLQ4LKAVGxlWabLMVqhz7hapSmZFXBJHrlF 8gUQEQz9WlGtt9v0Xiw0nZ1IK5U1v8Ve26t1E0adbhBTPEhEmyuB7vhp+qQSTcP4h5C4X+qLSel9 nO8GmlVVtV6vYeE1xvTmKWblydFuQOG8fFndVRfMQESUR3rU3iiPoYX6GZFGOnYTNRxCsgWi6Nrt 7a32NtCX6Q3edV0gsTEHS0Fs8hCxPnq0iGtGVdOQSS8R9oKBXEj6JBcIyVeXKHY/oPTGszhE5OKu w+FwOBweHh4uLy+Zeb1eC3giotlshj1DZk8KL0YAB6kpGM1RelYWNpFe7nGyrlKOIFMiU8VNoNiQ AD85KWLWfntMLtT7xCzLnIr+CM8FL2tnnUkCBZmZVH0M6tateMyLGyKiTCUPpRBfk+etKyL2s0c/ QkgDJgHfnc50JT+t6qBTGCK6KyVO5HuZxmkjU6j34s584GNC96P7+4SGkzbRGpdlyZkhw/msLBdz UGs8zTOfeGOI2yApp+a+Pk/oVM9d7JwT0KwhRUoCC37/+99DRjLGTHSPGzJqC4bgIHxC18vKlJAq USCeab31OODQtmks7ci9eiKhAzo5QiRkynGEaaaTbnaxWIgrccTDhcVJwlZjDAUGKNuWtjTpdZrr Gn0CgbHhyQqX3n/iHeIkRRv88HU95wQMwjAm+eOmtkmUJQn+0KCOL02Ru3AuXGOCcwMMKwB8wjrF jEIBoLiQFgzdxp/ydW1ITJn2VgBN0zSbzYZDnrEjmAixBuJSwOyLosDOga5yJ5XZ8d9eYqVdx/uK Gwqe6Lop5D8jpZtHZzcavdePKvn0ouWgW8rzHMKlhKjI9W2ekvlceEe61YGAj2X98rFw5ZhtWHc1 AJrz8lSm/ZHgXjl/5EQDO/25nESWDBaz7wYOgKQP0SoWjj/x7YY6kAKOFDQnt58HQeR2HIsClXlw 0E4/ERoOrMQsv76+fvXq1evXr1+9erVarQiFlL3P81ymId5U+EOqTuh2YPorxm+qR3XI6MZBfOJQ L8aGtLYcxBibVHHSw6JtKNGvMlWG2KaQCAPnvim0BToU4Fw0IKx7iLFrFuqGXWinP1f7wzqVr1Kv OB5IMSILP3WqbZomFzQku6OYh3t7/HKY44ktP0LDIT6S+GYi92dZJrY6hI1QGNmiKFxQjhljJLpB Zq0sg965pfhmJxsSFBjADTJjACm4q4qnkFxBPwJqCZys6zqNufDK/uIcrddbIkLqERAMhKJRxEPL cr5YLIpcQV3NzkYBhw5817iY1AaQ8utPQ+lDe3eOI3s61ZpX3jOaKYh0KHEoFNxuECkgmEyawtRy TeufYa31PCZFybdWm8HRn0tfOWQhDTqPqR9C2B/R8SYOygxSlg4+v6JYL03HCib4I7tuVt/pgGNK ZzQ8fRbA0duU/rUo8qqqelsbeSKybmASwJMjK4rV5eXNqy+ubq5n8zkLY8kMGSP1ewUNkLKyyfBO eaOJpFUIy+Wy9xof3OlE5yfp8Km7dtBD3aZeAsKF5NWavgJAUcf0LNJLmxNp86UptTwIyZKU5A7n AiMhZoZ6Q5/hYCjRIDsdNxNC/4aeXpZlDg8RUp5ZIxDp5egZN54eztLHa5AuAjGx2O/x4nojt6Fu hcAIan2vYDWn2WzmgptnFsKX5ZNreKG7J0KY1nDgMonRXa/X8/lclkRRFBJr5IJnk0RJUUAnYnBJ x0Smy+FwQN5J8VcXxcnt7S2FGZbnOZErimIxnxljMuONMT1Oo8lMaW11eS6pl/U6d8EFWh70iTFH L9p43kdEb52F0k0wJ+NrAnZEbAs6SWMMeyfzgX2vHrsTgpHKcynaiJQQ0yliH6y8gJ23AizkgENm hWdBG2eRZo4U5lvv930c/khX9KMnj9w40oKkXXIOS+aEFQYn5Mixap+JgpH06urq8vJSqwRS67lW BmgA9zg6eS/MK73nUQ0d/gReuXmSwhBachPrgzwXF0BOIyJx6ZD4fEomue6AHJsQk3KuRhAHEtjy uLknzlVDHEx6dRbaSC+WRGoYTLjx4bxUHNMjbzoW1Ziik7mWswEeT0Yk/6mQQCgzMN1hkIv0UfoC 1GiN7tIILkp7t9vtkBBMbzZ6frhQG92G4rSIiME1VpUAFQMKPi2kZJlzMJ0IJOKQZ733kwOaaE+R zWaDhD/e+8VigRJf9/f3Hz58qKrm8vIae6T3lojKsry4uKi2Dxx8ONpV1zbeI0mgBpKYDCjoRQHI ogXz6dGtdKn3OGFkC7EAACAASURBVDp5LneIQAB0GxhPWbG5quwgN+IrYz7Yuq26bozJKBvJsg+C VlIz2ajbrPTSWtQboRG2JfdmphMFHXDq0Y72XDQ0sXtPPlq8O0mC805eJodT2uw/yY6YTibyHAEc cjrLMhwXRbFcLq+vr1erlaMMtzfe5207nWb1jMI2ObDbnXzF7nslx055lXU/tIctyYeaKcy83+9F ppJ3l7sizYTIjRRUNdoKINBE1lrU27RZY8xXX33VNM3l5eWU903bFJY49NAh4qAvTFWVsoXJgMju MLFxCi+rPQ0ETKDP0Mgm34hMCIud8rhc8AsFmCmf6hOLnlPocaxk6NM657bbreQ3i1iVC1XTortE f2WMWSwWAObytWRZ8jk6N9FVRoDaK0dL0YhAC+JUilhZM4Llo0ZksQEMSd50yNy4cr1ev337tqqq q6ur8PXZe79ara6vr2/r/eFwKIvW56CuawyM91TXtVaHym4aWfhwFyVBnvQCOoazKGHZyQXDP+np 4VRuUB+q5ZkQ4o+VBcMKVvVyuezNHGytdU2xWCwAJUe6LchGr9ahWRetHadCrJ+I+QRapeqWPxWa Aiv1KI1/l+fp0zNRy4iYlsvlbLFAeVhjDJHR09UYwxxrODgJlUr3m7PeN7oYf2pNbe8tel5tNptU eabNKDjQqAIcT0QdrcNOhR8fjOO6t6I1fPXqleuLVeklUUX7UKPR9aUMmdIODoZSjSGMUfitm1De SCi6EirY7XYram9SYfxy2UmeOUTHhK/AMs8umvTQEbP3A/PRe33noHdYBZZaS2Scc1W1l1wXknsK s+329lbwrxg7ZHcnIus9ClXZNu9Qhy5Wq5vra7KOmNkTOe+ty9g4IiIjHsUypNHYij7JmLyubZ5n 3rMxeVU1eV7mecm8957DppATGWbjPR8OtTHGWmRfYO+5qpr1epvnpTG5LF7nHJGbz+fG5N4zRsM5 b0xGxHleELFzvshylKRH3tWmacjPyRvDGfk8zxZNzRfLrw679+TKPM/JEbkMX2xfOpfP9llujEEK cJMblxfFYk5EbBsiMj54yHoyngqTNZ68J+/JeMqIHbEN39MMf9jPRXZ4bvrwryeyTNY51Ij3RCa3 jqxj55iLcuZNneU5ZU1WFCZz82Vu6ZB1GYj33rua2eer3OZ2zvPa1IfNwZoG/+kriYjYETvihtiZ jHKGb1rrUCLWOuozqeiZyczI5gaBsn2GTiLLnshneao86OhyP6UNZQqueiFVxxCHPAFbJ/DV3muM MahBQT75tf16A0w7nGPm1eqiLMvL65vV5ZUvCpfnDt8uzzxRQ5R3NY8c0jlEWoQ+DceYA8pJ0ghG xYagtdYFSl8PcQ7wXaSmkfaHZP2OKxIRESF3eOoAJ9cgE/x6vZ4I0CUUQIv0j14jl5eXkiFakzYn yVMmzvwUmjAzqn9H4Cba+x79Fp0M82J9/6mB9KcQM+s5xCpbnA/uloJqBWdQtzaxJhHfF4vFt99+ O5/PrarRx63fXycfswaePlS1EDdVa21Zlj64WUhckw8mIQ6FCnVrpOrLi8uIbDOYH4hnIYXc9a8g p0JFel8ZxWCr/R7qEDwrz/PWt4DJGEOe8jzP2qo05XK5ZMUsjD8RPNarqfuU9PRHp4Kgsw7GFFF3 iWcD5k+KX8VxGN5F2g9GB2NHHdYG+KIoIiW8zL1IIzL9jYT4mZxAX4707B0RxD/jTBuhp3DdfhwQ zs1ms+VyuVgsLi8vl8sltNqmWxtWXw/yqhDrufr5c0l4o+hWowt8l0TzL3rf8W+qVSAwlEumUVBV VRDooyqpnKQYoMkaweihYPITl14k+XvvVVFfNqFAh1yf6i+n9DAlDhWX4J7Y6xAGGvlphGKW9ymh hmZ/z6La7aX0jXptK4I/9KfyEr+qDC4ZGSIzmy1ms/133323Wq22u0Nd1zNaaL8nvT2I/4QOjhJ3 VBEjcKxvtCHzo5Nict3wqsPhgBUCqwoqG5Gq++xCNTX9UrjFd+01UG+ICYYCTIGnC3SSRVHgsjzP Yb9frlbOuZyNMcY7e2jq1kh3Dk//7IDj6cRdvy0iYsqAGExI2DoU/CUE96Asyzwfo2fxZXe7XeRu JWZs9XENUb/V31or0ShaYJX+yMnHcYBHq1ifl/Ti/Sn05xnJGOOGi+ak4y8AgplXqxXK0F++/vLi +gq7teMYhPm+/AGfYGFqnpOS/AQ5x4ccmrosdnp7NBqpo54CN0denTqECifUxpqJKUBcIK/qMoJ5 ap3H0L3yOHkjEVNHAJYJScYm6n7S8xwspCaEtfuukl64mfBt7gtf6m08py6vjL6TvmdcsfYUEoAm j9Oj/IwPIqI8z5E3xqgx0oEqcqUPwatpI8vlEt5/8/m8LMv1ZoddWSaxtQ1kgkxVs4y4OQC1IC10 AJuKqEwoZM6v6/r6+lqwvDxIQlcOh0NVVYh01W8hgVJiS0L/pYIMBby13W69R+KNHEtC8NZms8l9 6wS63W6bplkul+ydMeZnP/vZdrutdnvnnG2OBQ4Y2R2aWL/dKzc/8lv+9Ei/SzmbiXKCQ8w6h4AO r5TVQl5qujo7m81kzVPwkIcKyqtUE91V3Q84vPdSr8A58n02Pt2RlMmefGvhHp/sawoHlzOP3hfH b/w0b6Sf0vtEZWgYbCFqhE37Z1mWi8Xi5ubm8uZmugJbQ42XHoSTbgeYipH3IhH1WrpT8qrOu++r diSN6z1Ii2QSfjh9KKL9HisXXHpiC9HtODiJJIgIgmuvz0fvopaTAiPAu6INCwcncczIrzmiKijR uuuuR1BDY47pItFxPnUnsRb39Xlw27OqrcqDYAUYGhfUvpIdXeujZC8XbttZBv6YwxEtQKMgSFZ+ gkoAajTqYrVIq8EhURiHRFh69msfTwo1A6UFapMCtY3Udb1arShJfldV1XK5bJoGE917f3l5iQoy AlHrun54eMDgZIHwK6oNeedns5kj78gz82w2++rLV8vlcrmav3nzxlZ10zT/5/f/3263Q8ynras8 zysskjaWrX8iyjic+6F/aqSTDxZFkedO5gksI/LniJ7DqMp2FHKlMDPQxn6/x7zy3qO2cNcO2AIO mdhoBEw5fOhjJAuNAg5OQnaH5CHzCRy/+kgAPfXtIn8SxF0HiHQYpyh9o9vlw0kVFRMSwOBL6WEa GTIRySIZ99nJBe+68csgDoFrQdWhFRs6+gPqWPwp8h5UC9KUfh0IY5KXSM6L1SCaWhNHY7FYaEsr mLko0acDek3TnTN69q8uYfRckiUPDEqSmqfMKl3vLinyNfTco/dppKXRC5hDpA1EcDwPe9uzkCid YJcCU8ZDEUKC4zw/ukP2iXePf7o2QOCh46hZJiUcLbOQldUHLwqBIKTAdbRCKCg2hEh9C2kEYw5g 4b1HJkqZstDWkHLXiNYtLt7v91dXV6KQlLfGNbgXzlB5nl9dXc2KMusWp5Wmqqryzt3c3Pz5n//5 q1evijKbz+e2qq211WG/2WyIqKoq9sf2nSKc4a6e9k8dbUR7c1BpHAumyJQWnwxNcq8L9X04eO3I v0VRwLBa1zUWBYKonTJ+A3B4x07lT8TMkTaZM81iFMonORMJFfJSUW/l3dOTn4BS7jR0wUniM60G zzJdNUroBRyPeIo01SqczBF/yPmhZr33kQKFVWbPZ+G0Q+RCwm/0X324lslzMLvP53PwW/3RrbXi Q0pha0/fVEIOgVNF4SqbiwkhezKZsehgFZWE1COyUy+Je5yk/sMb5Xm+3++nL5zuSu+/QBw7oArl PgeUaO0LmvTBO0SL+jrHmqZHr/dOuIvow4feBwccintFLzBOabO9gpTI+vq7WmtT5+ERioajVwcl Z9brdfRVpIJw76vJho0Zs9/vta+l2GvkFcRe472XTSJqypg2ywqsdFAhCAIV91LoG/TixIRAy/B7 0shJXh/nJR7Vew9bjA9mRdTsybLMFHR1dcWeIFLP5/PZbMbMIeOOK8vSW5fn+c2rL15//RWbNhfI 4mL15ptv/vDDD2xM0zRMztpWxPLeOabeEFAtRU36tD9VivYMY0yet0YonXVDLosWHY61Z6jwQe/9 crkEaizLsq5rRBLpdCyhFy3gkJkjgLVpmsPhUNe1c7WIFt3pHU/1XmAxZQQ+GaXMNJWaPm2PjhRG Y3BMUrXESGvwvpmeJ92b1rOHmSmA3/FN0qmgbt3JFx1DDmYRLA2fJJ8Ef5A0biZkZDYhF5nswTIZ IBSZkPWS+qZB5NKhhT2tvZA0B/hTr1ndWspyo2fJjsYhJiB9+nQauUU0DU7Z64VSMUPfSMpvA+tI hJ/0ZeXg3MRdORqVdzjJNcA9I4gw8WHtU4a9XfSHJxXCSkfF+6QHRYaY6AtFXwvGBX2mN79NdDuU Aev1+u7urm5c0zT7/R5uFogUh95bZttsNhPlhESO4AXzPG8aC20hbhTtAg6MMrLoNYb2vSpRi8Vp VQU+GTpc1jTNdrt1zh0OB9FIYwOD2zZydnGI7hFzqckya63PssVi8eUXr+CGNp/P6+aAd4Gd+OLi gpp6u91mhojayEoO2DEVDs74qH86hJfCSgHJHI7ynqVyGG60/sg95ftCQ+tDzTboZlPAISYVmU7Q YJVlud/vmQ9RHpehVzh55qdAkZ7MPTYhpr5rOkN7rjGZAua4G7uhVFM992IWtUmVmMuyFAupvsx7 r21psus8+kUm0sn3DWy/NfGLLwKH0lesPMx6haspKnDI8bvdzoUCVXK9zlgocjg4p1e5NWV7oq60 0As+cHK32yHeRHYZeajemHrB9JByRZJ8UJgqrhtxKU9JXRI1AxHuJK+Pop69Q9d78qTu51i+cvw6 uUY77DyCmqYxnPciROqqbfEUcbiL2ulZOcMU4Q8fnDHxpy5fF/UnJW2PMMasH7a3H+85M9vtdrZc 4AX3+72zxtt2M4DeQlKpOGXLQJSptobIr1hXh8PBhAgXY8zvf/97sf7Iv05SUgb0IOPjgoVotVrJ iG23248fPzYhlbtzjqnNjQP0M5vN2BNqssjgc2ZMlkGnUs5nN6++QOVJFIvjzHBmkDX54f72frO+ WM6JqE1IQs5655ga70itmZeWn56PRrISpee8MRmz51DtM+vWIOje3mOzz7IM8QjariEh0CKHYfKI BOaci5xGRW9sAnnvm+ZY7icCplGvfmqfJoxGz0k5/vSWnUeT1nAM8XRjTFuQ13cAh4/cz/ELE3M7 PjlzlmV5UWRZlhV5XhZZkXNmoClBOg98+FYH2QEzL06+zwfCdWJBB3szouTXmmPRi9CocQ3ObVD+ bTYbwfeyBEwIDDYhEZYcSyZlpahuhX5pX+RDYww0lKhXlfUVHOlVXdhuNmp5XK9qwalqtAI45EG9 K9olPhxENJ/PBb4MDd3j1lo7XieBCXXRnFDv1Omlo6HIxG6n1MVocr0UtpZ/taVZNz69D/p1SBVC i950ZEBEuZ3n+Waz+Zd/+ZfV5cVsNqtss9/vW+U5FcaY29vbw+GAMNFM1ViRptbrNfxbBfRUVbXd bsuyvL29zfP87u5ut9tB/bBer5fLJdwGBRzArPPu3Tsx2eh+GmMQVCKmEyzFH3/8EYpH6QwelGXZ arXKsqw+VADgq9XKAyx33V2ttVdXVzCmiJfJF1988dVXXx32W5IAM4ee9LuDjXy1sQ/6rJzxKULq 0L1GmSZxHLluDOGP8fbTW1h582VZ5tukYy0ioSDpGuUU5T1nWYbYZkDh9kqKXcx+UioNmXifuyMn aPo3PXlla9UlQ0RM+EzxLfAwoGRiGO0zVOTL5bKczXpjFtrNaaA/vutUyC/mPSrq2yHeqy0sqQCp zStgtnCPsKFUuuiA5UVwfrFYHA6Hu7u7h4cHsEfqpimSVYw/XYgM0EuYg2oNPh/cTc+KayTjgJZv 9ZuO2GXar0xE1G+YFoISHR3QSpr0cUJQzOArS+FPvdyEvXBXua4bgZ1kpGPHK6dc9IyU53lvsXiQ BjQKZJy2cT6CRMk/JMmF86kFyzhH+311dXW13++///77m1dfXl9fz9b7D+/vEaOBBW/yrCzL2WyG 0qDpo4kI4Fr8iR4eHu7v75fL5e9//3sK9kgistY+PDwcDgcAiMPhgDD0/X7/hz/8ARM9whDyrLqu d7s2cBfv+/Hjx4uLCzRVVVWR+4eHB+/9crm8uLiIALtmAbAK3q/XXxNtNhskPfPev/3xx++++27d bPNZafJMMiLWtiEiJuecw6d1fPzPd//EGR9i+ZCf9LGfdxI9+6RiFcFEdFTvR8pSQdLP9cQAL3qY tQkZhEP4PouOxCv/UEc9yQym94FecqmCQt+O/5580OdS0qiODeq0xtVdIkbDDcqTdxmTDwH21GYs dM75zOSmVab5MNOyPM/yPCtyk2fFfFbMZ1lZOCbP5JlCmx2CTMFdpeMIe3wiRSK+6HGpfYVW85LO 5/l83qYTDO6NMo1lAktwH+akVYkZKcCmpmkuLy/zPIemMPXkExKYxX3O1Lr/6b1aK0lBWB3SNPQ+ PRLyxWbUezGpjE2pYoP7NMpeJXYTHaHpBvAPPSgLtV2KkIhsXHPhvT+aVDQokyuGjqfQRMXJZyF8 NsHvd3d3yD/hp2UgkK8O5QEUWVA8OOdQws0YQ6a1pKat6a2ImVEKCLkx6rp+//49BeMlfEH2+/1m s0EMSNM0sDuiBWgmAGw3mw3y2Un3iMhau9vtcK/3frfb3d3dwd0Eao+mrh8eHlwITluv17OizQS/ 3W4LCB8m895zlsMLZL1e//rXv14ul01TOec+fvzonPv6yy81tDLGHJrGOVdX+6ZpSs7SddK7dIPM 3dLn2jYeQSIPGVXsmwZec4pOMtKOnosJ9HNhlIGYC84C4QaiiXWNSIrT2x953EuQbIrqz34yz11I vZemqyt6LxvHHKB2A8gKlKfHJ4NcoTXtWgzNsgz6V/wL7drJ/ALe++jhL4c26MzdQboBxapWh0Qa Fyma7UJwLKJhfV+mVNGLSAwXmOd4tyeu3OhBFMw32+02NeKfJDxUUjBAbXnyelImCJd4dYBYRalQ mEhw+RKVmAkuaJHgJBqpcb0LCO2freFItUmUOEnoDvW18Zn1ok4FDWMW3t/fX19fU1BBT28KBUq8 Yx9i3tFgO6VMOzhRutyUEOgoQWjY/q+vr/f7vYSTbDYbfNc8zw+HA9JmGGNubm40mJVUdJIhCjzo w4cPVVXd3t465//whz98++23zPz+/fuiKN6/+wOkAUnFDRMJWnPWGmMcNdCpEFFd17/97W/LWZ7n eUaeQp5/27QBFGVZIvcGEQl/tK7WGW/0FBfS7ONPAnCkWwgoyzIeUeVNo6ZbAbjpKyWouxH9GG2H 3DoO+0wRPIXrum5sR1nqH6U5fwrgGPnK4e0mdUnr3h/dmbPoJIw4tx0tjViioigcSgxBM8FkvXPe zYq8tg2UFlmRm5CvpSiKYlZmRVudOC+KLM/JsA96xBESWaXX8P/sgFKcIYbqIct3FLXrV199hSVm VFV0EdC1DoOZkWVL0opHjcOeLjf2+tXKi4uSwzwt6wyYsD/f30gyo5+MUtZOJI+T+VHCU/5UWtsO abeV3jGJ+nnUcDyaRkb/RTUcU6ScIQJIBEiCrUGyjHNf4PII6adXVYVIk+Ov7ijycp/ra/Q6Tvnp YDMgpVIDiNH6NBO8UKHMAFAArherjajL6rr+4Ycf1uv1w0NbfOj29na9Xt/e3h72D5jEu93uanVh rXXeCu7JjCmK4nK5km+92+2897u9894DcGw2m/V6XeTZbDbLyc/n88OmU+LIWku29YH33lt7dKjW ZJR7uZR869UEnkX9XOQliZnbXKtE9Kjgt0irIcf6gind0MfCNHW+gVbbwaXME1kOZ7X/CJL+nHtX GsQLwhR1IRb9RWV0LXE9+/VyWWs7d74oCiJerVb39/ebzQY7cROKkeKbcihHzCqz7fQR1tIwfRKg ry0pFLT0vc+FrGKt/eKLL+SNMEvxmuKghusxkykMoKQCkxkCbcHt7e1RQlC4PBqx1Nli6NeRN8XL Io/OI3ZGwUMiDWpRROc0i7Qa0sLQB/VdTx1jTKSDkVeWYcG+oyHIxDc6G3CIxBz1QJO87cBEfyrz 1xOUzlwYMi74/Lvdbr1eS9aN84GnQXt1XecGefJVhpKgVB+C2Mcr+6Q3LCHsDdorB+oQFIWXJBY6 okmiz8GSMEfv7+9/+9vf/vDDD4dD9eHDh3/8x3+8v79/9eoVEWXG3tzcENFms/lD3TBzxqYsSwCL 5WKRZVntLDdHKaTZbpg9M+cZG2N4v2+a5uJy1Ti7KIvl5cVht20kjYpzxGyKvLLNPIm+1oCjc9IN BP6dP31eDnCk3VZPPPFMcaSXu7SU1lo6gpqKVG63iR3Tf8rWznxkqVDSQrbLTevnC82HU+7uUTsT O/ASpKDGoKZHLyXp7bN3e4TvdX/tUX6kyCM9LyAbkMF7//r163w2W6/Xi4vV3fqhrmvf1A/bzRev v6yqyhv2hlcXFy3aKApTFqYsnFQaUDQ+FueC2seR3i9FezECc/EK6/Uacfv6JO5FGCD+xEyGgftw OCBjnrV2s9mgKoULuUfF46EsS2TviJB9BDXEg+QsikQv/6isuFZVA1WBaZ1ARYll0/hDNzIlbQbq R2oX4xRw0EAS0hHyjzOppK2ka09LZr33jLiifEoyxux2ux9//FHgM86fJY/6kDnDMclUbn/izpuO vLIA9qhl7EkXFxdDZj8tzeB2LC2t/ACu2u128Eh9+/ZH59z9/b0x5t27d3mef/nqcr1e39zceO+R Ov1ydVEUBaw589nMhXiwTDHQLGOxKRYma5rm9vb2+vo6Ix/ti1jMWdfJKzSSyZoXZYweEw4M9zid PrNF7gQdg2AHOiqvKSAykhu8941tnW9sqCfchCrz4wuHmYcGKL3RGAMHI+89oi85JGBOuYlXRCOr e/iJT0R9vawmoiHN/FCDT+lPupEPda8XkkYkZnJcMJ/P9/u9qonqLi8vy8XizZs3b9++ff/+vff+ 4uKiqqrXr1/D4VFyZWZZRkECWSwWabTCCE0Z5Gchq/L307QYS+89OIy+Rcsq8kFlVxbecjgcxLkN uXdJOe8bY5bLJYq/A6NooRqrUroBJnZEhAPJM+TRckY86uypymojPwlUEtnYBx8UZkbSCtheI3V7 2kP9OH1lr9Oh7tj4x5L0kprk0zwScKTqlKgTJxGcROvB6n9uBx69KkyIq8afdV3f398DcOhuxAqJ NreBaVMdEKIpWpeL1rXC+6qqr66uUglmCvVKk9IIUGf0IilWxRRfLBaSghdTs2ma9+/f7/d7THd4 pyIi11p7d+eurq7+6Z/+yRiz3e+Z2c6tDVWRkEsYDhzankrEzjk2xMzIF1LOiqZpaFZa5xCoYvKM mjYFllFMgUMaeKjBeiU/JuK+VE69NS0/O3EwhBlVAGhoDmBsRdqQTy9aDVLwV7JlvARGF57ljXLX 7SI8fSBi6MkF/rxbl7Q23ux4yr4XoomwgxSe6AUrYrLEtoEFUpRl0zSWfDGf/eIXv/jbv/3bf/3X f/3lL3/5u9/97vvvv/+rv/qrpmnevHlze3sLtNHKGyEm9tgsM7RDJ+fQ49Ra505OGLV1MsPxljE5 7+/vv/jii6id8e0Z9ovlcgnJUEJk9WWSXMqFmt6ya2L/HjKp9D4aS7tJCs9SNz35yExOR4NDjmnx sdPqDTk2ietSKsT2DrX+BFICBmXGI8FDbzqP0NMcC96ce6fcKLExZzUl6I+Z5/M5tkANUUnvPcn6 1ODu3D6LBg8tbLfbX/ziF7e3t7Kjn2VVQQyIc65kzrJsvV7PZrN2I2HvnEOkCTTVQ42Ms9E8zyM3 YMHm0XuZkJwjssOt1+v3799vNpvdbvfhw4f5fI5oFET2Ms0+fPiw3++Fp2+3WwHyWtUpAWayOFtA 4Mk5R+zX6/WsyHWXyrJ0Tc0cCtbbNuFQZNuiPsBBekcM+5xc8NmVZNEnwyeWapzRpNXdlmMNImWE vffWO/3K05cnNBwTR8aokEIA6eBh0zGmoAMa92iY+Iiv8Agsrm/xwz4czIOBiy9E4/BCa5tSJpa2 IEPqnEP+Hpx3zs1ms7/8y7/8+c9/XlXV3//93//DP/zDN998c3Nz85vf/Obbb7/9/vvvTTczlVHZ MLMs43N84VN6ibVmQ00T7/0Ib3QhnJCIdrsdBUnJhURherOUPUWWj1F1OiWosPdbpIuRgiO/3t2n 7A7CG7VhQidPmjI+afeAAEiFSUZWlbIsIe24rufvlA7LMTNrcUioV8TVvwpz1rgnmjl5+rCJXZRl f+6Wn4WMW7Lx92Z9Z2WO9ccwaJJ7R5z2p5DMm6qqLi4ubm9vSQ3FmNLFG/IGzuGb7TbLc4uBzrLZ bHaoKzLcONteagwsiHApHVJ+DE1ivOBut0txa6YKo2Dp6tkMzCGjVFXV3d3du3fv3r5965z74Ycf 8CuS9W63dr/fk3XkPXRORKQzrIOcc4bjOLT2JyYZPWhE5vNlVVXGeEPE7K21BlkiMsPMmfWp9psH olT0BUTYT8/f5M694XzSHzfPcw7+mCc5lEANEjcONZ6iXaCn8f1eQfw42qb1E/Lei4ZGPqgYvDCd hDQ0ifo2LrY+ggKSOH3N434VeiGwchJtRH+2ojYREc2XC8/0+quvirL8+f/8C2PM//P//t3FxcWv f/3r//3Xf/Vv//ZvP/+ff/H27dvtdltVVW7YGPaGXcYu4wZZR9u0CjmR+SSr4QT5UP4py3qi5Xuv p+DWJifTxRUZNfQZkZrSaSBhsXKBCNJ6256+hWO/j7ZnnESsspsWSirEoQiLtgdpVCEmVzBt6LbT Dvdipt4d3AUSC4vE4k5EXZpkzHORZSn4Hp7b0PgyTpeZVUlnNavV3ZK9R8sr+lFnGWt7aTabITUF SpTJCGpBXkrxNQAAIABJREFUgZJJ1jSNyY+6HIzeYrGo65pQ1XNWSt+YCXnAdIN6ZIAlh4Kq4XZ+ f38vM4xCNgVANC1iYjOgkJYDbwct3H/8x3/c3t5ut9vNZrPf729vbwXttaKD57quoXvQIE93pvcr O+dYpbci06YDKcvSehSBc3mel7khosvVBbKc/fjjj+sPt1rPpDe/CHBw16qSZZknp+8a6eTJDWbK DpQ+ZVyoxesbYwy3C6p3TUWBZHr/ruvac7/b2qkenrHHJ+ILkWS3DJ2BcInkg8K+NYEJak59kiFE gHXi7q7aHHMalTZH0M/ToZtudqT/IiZFt6THHEif1N99uVwWRfHmzRvKWu3F1dVVWZZ/93d/9/79 +6urq1/96ldv376lbmIo+VfW2lOqpLyQkgNAdmjfERQuoRknk1hAOteGBg3chblpxi7T+Mcff/zm m2+IOqtPLkvt2ucSUAjsO0OKlohcSLgiq5JVKjOMT6qYdKFERqqliNr3iSeK/hPSctolE7xY2lEN icKEMzMfa1brmdMxqZyl3vDeEx2R0fC9ya5Ajtg7T4eqanvDzqMplmuImfEvtRmUmJUfXpednOyv ONkSEXnnyBstxkVbvjEZERNlRJmlzJHz6hGeqXG2ZLLeVbbZVQeXceHtjKm2Telayx+36R1dXTfz +bxpOk5SuCDLsqaxeW41uxE2sztUKRvSdKibxWKx2e3n8zncy2zdUN1kWXb3sLbWAl68/3j78PCw 3u42u/2+qq331nt4UR3q2hhT7yuvUDxAdK/xQldtCC8Dgcm1Q+PZ5IUj5lmRLWYaye0M0XLeHPji m6831f5gD8ZT7Yg9N55sxt5758l7ykZ32PH9Xnf42YXscdL7BxGZPMMcbiePTF0mj5SOdNwCsTit s9ZaT967598dz30RSWZsgtuT+KbJnNSw1QdDmxYbopaf+CLee6LTriG9T/HKEPOJx3Oc9K7DKjK8 JW/Im3K+KGbzKp+ZfN7MDBEVNzM2xhI1s33DxSGfr3229dk+L4uiaEye57nLZ2VZ0mzmigKwwxni jMszi2B4T96T9eSI7HOPnOTpEUbhnMNq8aqEodRsQ35kXc5NY1y9EcJTSgI3MM4+WGe0ngB9oK7s 3qulGCGnimTRsJyAveYkLpfXsdbCfw5djWrXabLWsidvnSEm58l5InLdfSfQ8V6PZLaeSOn1BY0d xQwiR9Q4x1kGdo8p2xrIVYddyK0eP/LRUSpK93DaXNrLfYbyhHxKkmS3plvyGPNsRIPShMrgyP6Z ZZkjX1VV01jkktMfGLl3EAUuDDobLRkafSjh/qYvqv7h4QGFWyPMtNvtkDTs7u7uxx9/3G63CN9f r9fIty+T3lprfAc4QrSdbiljZu87Uw09WS6XUCGGedxWOoWjQ9M086KM2hl/Cg58koB5nNorH8so J07U6YqQXhduiUOJzk9U4T47yUzDJMG64GDcFTDK3WyPWpTUFMGmp+33YxqOz85VHkE8nKEHu13T NPP5/M2bN9hloyyLs9kM/AQK19nFkpTiWXMMl9QHTj7Ep8Zh2EGxIpbLJQ3EYYmaYT6f39/fi+qC kqklMWIYAZgVJKGimBuilrWpgs4xGWgneo0hJPVz9C6Rv+OU8dEvO+XGCLOihdS4M/S4oRUkt6Cw Cx4hfWO1hcWIWZE/K/GXhg7h+PixI5w+cvvIn8K5XppxXF1dIZsFtkDxtCLNNL2RwpsR+ZDQszVI HfbL5dLaFqzoyYqsoEADQy/FIb1pq7seuIaTJHfCRwCYEHKC/u/3+7quUT0OpYm22+12uwWQQgI+ DbOkzVbU9o4phKT3/WeMIa97atpzQUG3XF4Yk8/nJQrOSeN5XksGM/2C1tr5fG6RWxOvGCZIqmj5 6RArmn6X9z6y4PZu0i+n3uiDR/HT5TK8HWAidODgpxAbRDmMBSXsPnrcp/l26XN7z/+kaGRvy7Ls YBvr3eXl5bfffovlbxL3eSm4tdvtVjdXklcqxRbwJPvpjMa4PoySD1cUBeQlucWrYvEUdnThz/A/ kJPyUPkTfiRpCSpSPpLCZq0qKI8DXTxWb8lO+VXozR6Jfc/iFWgZvRUlSvoFYQXYHw69Rp+JECrq m0gXlMwlF/Ka40y060lehrT9XFv7Jg5EpOHQJN9jvIUpD5oOM88lqChgGENMbJTTk9pYROOcc4nB Ri4TwTQ3vN1u87xw3bpcANQowYc5LfNGNwi9CDbmsiyjr6QFSt0HrdIIfppzMH0KgGO73SKV6m63 Qw5/eFF471H+rVVL+I53lV48EckuaIzJCKmyMzpi/KOXMhG9fv16uZxfXV0hKTuenmXtziTo2Nuj ifST7UzPQinOkPnvvSeK81jIsbhejjTuFT1rr4e8F/uvEcwhyj+AWqBkH8wozrnZbIZMcROZwCeg c5n756KhaW+MaaqaiFar1Zs3b1JhTG+3UF5Sd4eLWKgPlv6fyLBIKpoReYy6gv79/T111RvcddDR Hg+yVe33e1SapC77Rfyq2HRY+a3jEWBKLqS7lBSfTuXXGrKkOFXQSuhwOIw7SuoW9O5MyiuoRxXh W/D0CD2NEO6FIg1YSopRuEATvTzTyMr2fOoS0nmLYd1I73ntjXiyXJC0EyFWUl4nUxqRe0f6poXF JpRT/93vfvfHP/5xPp8jrtW0VQrZmJzohFOqTIW6rlEzJcty5xyCO7RaT4wXzCypiPUs3O12xpjd bleW5eFwSLd65M+AQgJJfrz3FxcXcBzbbrdYSKj4iluQQHez2QCviGefwFV0RpwESQF5HwLW4XOa jmQ7mIazLM9ZQ1W3vLz48quvv/rqqzdv3vzZn/0ZJJKv3ny73++RRn2z2Rzq4LGVGXLGcxsqO850 hH4ivFJIqwFwDPXsjI6e0Xpyioda1E4qQ6Tnz+pS1HjopzeGnEtFhY5aLroXyFL8e4A2XIiXxoeD 5h+TuVcx/iwUmp3UeDQOPwUM1EtDqmxwCfD96+vrtAyKTBJ8HewHGiP6JNxvFMKeNpE/O0E4xua0 3++jslNaCsK/6/V6fB+VeA25TBxOSQ01xgdQo3et6ado7YW+UqQvCioQuUDQedSI9x7BvTQwIYUP k0IYcn36BTlYjF2IH5bQ2cgfZWTQNGm9he7J+C3MLLHKksNJBGChYxrsJ65Gr7TEQ9X5QNgCMcki BQ5183NQsBg9pVf4vz6JfdRa+/bt2w8fPiwWC0w7maknm00/nvb/0HCbVTVCYdD6M5iQZ+aIUVSz 6MzhcIBdRhYbM9tQeQjV50lBcgCX29vb/X4P/C7TVF6zzY6KZew7kJ9UnbAhwJHn+ZevboqiWJYz ibxdLud5ngNq/PznP8f1ZVkS+aIoVqvVarV6eHjQyFc8P1hlZz9JU7Svn5K4LxrFdlOmgjTsG6JT u8Ije+hDvrtU6ZrnOYcpLctQdwYTWFyRYJjjYC3W+EnqG/dK7YK89ZkzX6Tj/vmfmDCdUE+RRu3u MvEigTi9q83yEvaDz06yOx4OB+/9fr/vCsDehjqUghKEB/buoCKI409xMEqlbX2lU6kZ8G+WZRDw ZBVrx1KNAEySLk/HyETlKtECUqpryDJEsvpyVclc+t8264m64EDfq8dBjtOhwAHkwyEdxJCGQ7ak 5XIpIwNFVETMfEy79ixCCT4PSodIlpK036TgGCxt2EHFFYX5qK5/hGponKCHaJrm48ePcHjGxuxV jljnHMAl4gVa2OI9cm5id9GGK22y8qMaS8xjPdf1Cum9XlQU+BfP9d6jzlYeSGZwURR1qDjfNA3m d9M0MH/KVz72wbt0Hsu76ONIX/fq1avri0u5ACHmf/bdn3/xxRee1CdjZ50zWXZ5fb28uNhX1b9l 2aGqsIG1w2jY0Ymd5KdmcNF2B8GL8qscRy7SJ/PHeKWIet7eRsuK+sLhIsQv61FwITMjnWWvtZhV aP25GXr+a1KvesMYg2+PEHdk/Wm3tG7EnPWOPHNmyvksLwtSlj5sflVVLRaLaFNMp9a4hvjlCJNN NBBCzjkiL8WG8CuEz155DwciNIrsJ1kYILtGT9GKH3BXtMCh8DrmuZhdnPLkSCll6Rr6UBfHTxkc AeiyR7fd9nSM2OSeBlMvUadsQEOE3QFsPOUMQ5uUvhL51AEAkHVCXoQAOJAGG2zlrFQkvQ+OWEza xQiIaWVAJP3IVJBQ46f0TcNJ2NXW6/WHDx8wvsj6JVdy6wqn+sPHnygUSANrLssya9O05yenkURy ixZRD0svDY0hhdSzTahUJBoOAAssFUAr2N0FbWidChExHSe0D2Wae99FfyBjzMXFxc3NTZ7nkg0X GWPhcK5J9PB5nq9WqyzL/n/23mxZbuQ6G12ZQKGGPXKTzaa6pbZky2GfK8kP4Lf2Y/hCjnDYR2H/ 8Wto65BNco81Ashc5+JDrlrIBFDYAzfZVq9gbFahgESOax62261sGB+KNw7PHtph+oK8BACa9aTQ MWRuFYwZ/ToAY0SfntZG6Ydsf8JEDESkSbmi1Ri2HcPVuWpiRhyzpj/BACAIBZ/TLYFTj0OU5zmi 0Ad2zsDWEr3Rc6oP4SFRVVUpKRLUX2uNU2WhKHjIHswtoZlpr5xGIdZKJivZ0i6A4OS6rlHpTavr tFwRzZLsc0HvnRTaquCOAZ4vbVlLiX2TKcfzwfK5VxlcuB0/PBI4qFGhVk9vyLXbywAXMwZkqFra ju5xquQdteUhgIwZzKZOdjnMnR08ZqSWxDl3dXVFbfVJxO4we2bW3nSCiBHsir9FUWQTVMTo5htm sxmis8S4hUmGb87whFtrZ7OZD3YQhJhycIwStK7pAQcvAQq6HNGOgJ9wIZdOZ28xyWCnIFfpf0jC 0Xwla2z+5s03MortdjuZTOHSGnKfID+HJcZfa4iOj06/++67f/3Xf/XMxtoslGIZufeE2xhQeDwz RyKsGwWBNfp6r55oAfQ5mSodSyXmLX2QJb8QFM4RJjJtByx60NgPQmiN5aUH778XxrxvZx7Q+MAj Gh0J0odbQ6c+CUgAyB3Cz16KUDZcpyoS0FDJ0Gf14dC6B9ErhJ7rQ0AUZKHFYnFycpL6KMg96Vvk ovixsXJI0htba1lk20OC0tj14PHU4rS4xMqLIP7pRiIZOwLhk/BV+4h0T2s/zzEGwQp/o8mi957a RhnoMISl0xiPgtNCZ/u53Pp4s8V9eSu8um8WZKLl5DzS7ijMbJ7n3nlYDW2Po+KwmQMwm82kdrz3 XrvdCcCjQjyhOHhRSKSoJNiXRzTGkcAqsB3OOR0FQ8pAQ22+XiJBgIzEKKNTu6S9FfY2lctl6mQg zAxZAXIAEVVVdXZ21ilAaxw3nU6Pj49tKAlNxuR57hI3xjHwhag6Brb9A/oW49qng1QHCcjzPAtV miB06hGBtzCq3h4pnTPuwQ2SbEZUZfjVJYn5HzGIPcPxbKRxGIa7IUzYyKfEwiLiwWw2QxA7ntIe YBAbpMxpqkhHpkg0JYLc8HCGb4h+fcwS+JCZW+vew45C6BOLbh8I01qL6phC/nVom543IS4cfCC0 DGBtR4kG6Y80JSwI/OQk5W6qztTsiHRD34yWO5NKD7Otvu186kPmhZQ8RUac7XZ7fHyc3kBdnEfU K0mOkoJVlXKj4dzd3RHR0dGReEmmj+fSytMaXAdQ8LAsqze0Xok+lckwhPtj86REdnS+VPaN9x7p IDm504bCJWJbMaY1Lg7alDzPp9Optfbi4gLD+cMf/gAGApAyarKQYCag2ADToP1bJSZb919cYUjF cMPbQ/j0dP5TZk506dHM4PPeQJPZXV1NiokxZpHZuq5LV3tDwaM+ME+TwhN5Y4nIGwsnGBfS9Bpj 2BpxwseHR5nQng5YOZZ04gW9RTnxiIweGbOBH6FlPNy4sIMaFeZ57gNzIBoOFyr1UFvFOtAyK+Uz WtAJmJ8cUhlx+Lbh+flC2BcBbKfau+V69e7du5ubm//+7/9+9eoVt3HFcrkU7l8yMgkB9t4vl0tx 85I60uv1OlVQTSb7tBNEBBwlxo5PwQeLaUN3I8sy76G52TVVAqxF0mQi+uqrr7SCASCiNik/FXG/ yNTelv2pTRWZKsGqPTRFUodfAu6Eu710ABKjPhrifxqJkcCZ9/UN0DpC5xxSiGpvVgFum37A32jr p0xL+haxyjnn4NFIPciqj7KLyhzuolE4j8C+OvaTWFtF2h6/NaMByFdtWyGl1HoM4PwsFovN5mNE SiksmKh85CtRw7GIilI/q/ufjgUajganh912enpaliXkEgp7EcoSa+3ecy+0BtMsiqHoFA6CVqKZ EfWGV5658hdOr8LmW2szG9drTiE1waDlzWYzn8+h6rAhCGK1WkEQISKxmMrju90O8W+iQSWldbTW cnsrfiFqjAg0vh6gVdFuGTOKh410DL0UnZkoJEjNvG5BYyU8FbkByW2pJCDtSIZHvUUfvY4dGo5h GfGTwsBwHin9m0BE1+v1+/fv/+Vf/qU4vciyLCuKo6MjIgL3MJ/Pb25u1us1VLbaM8wYA6Ec4qYJ Yfm3t7epgDGdTrPMUttb7pFefQfHSEp1AcVqYAWM9x7EkoMbI1zT4C42YEzRfdZCv6SWJiLYcOUr eDVBkjp0AJt/s9msVitgzqIoIo5HDotQB5H6jAJcl7Cje82SuCLgQ2cLgif7HLqjiUr1NBScC8FI ybiQHSqiffgsQ5MGoR0RyxG1z0ievvKRMKC4k9EKjhv/0ifhh3zI2C2RAlgktT8yIg+HA+Z4zWRF +T7ecJDzhBUTU4Lmi1O2MVJ7RF8ldS7+ptoacKmITxHQnKU+BjxCMtZcDj6UZYlkYhJMJQHP6/Ua nqFZqD1LRNbkxLTZbFzN6912MptamFH1TFpDZCxZIrK8f3U0ui8fvPdkDu+Qpx4Oo9G+n73KD7hn pqHgTO6M8FHKautfO18n7UdanzEj6YeG4YgU6SnP9KODaJZ8YNTqur68vvpw+dFP/r+6rtkYkaFn s1mWZUdHRybEH9XcWjixv0wmk81mM5vNYFyIGI6iKGaz2Ww2/dOf/vSrX/3qWYZLRFTXNXoo6hm7 D1QkIgKTBCIKTAK9ix5j+pW6wkflq1EWQ6SOEL7Ee48EBBQiYhCfcnl56UNAJdI0D49LW2fwFgwN bv6Smgy/2mDW7zwawuhDtyH8TXozqyx8PmSEGlAuRjMjd242GyAH4Vqkco10OH2cgkKoDtA5nBzJ AZ9Ef5D2aRiMKqUz3ILpLzfwJB0TcZ85xq3apCLKumjGOOiyWPnaSMvQ6eF+qFi0I4W43gz32Xu/ WCxWqxWMX3qxwLvIVw6VL7RUmrbJg4ru1MqjNY0cPFHW6/WHDx+cc4vFYrfbiX9rXdcfP37E0CRi pSqbWjPv37/fbrcomSijwz0hdoaZ2TJFM0xfDMMxToc/VpnxgEFpdkE11WI4+jopcpteZa1nilQd oHl1KCEkIpQo/DTvq4cjKzuM+B4JfGi8XzJE2iBK2A7M/K6uvfelqcuyrL1fLpeQI4+OjiaTSZ7n JycncGNn240qxaRiQ0mm9J7f//7/ffHixR//+Me/+7u/o7aqIGLvngSEbgENSrQ2B/+A09NTQV+z 2Uw4APE25SDr6y0nZ0r0AdSW/nUgggmOR1IgzaggFI2afPClGLOTxa1VhinaX2hr+jQQAxMl/ceo I6ShBUKJTLzXYkmD3ntJlt93TycIJzQgjedQxJESfMd3MQWgMN+T0iO1OGg2CiBqdtkiovnvka9G AQc1l+yhlNpF9/e1A6ahqKcD0ypr71Tk1Xq9lsnBxvXBl1MPnBRbI/kcKZB8zbmLmi51yhOnDReq q6DBNCaIiHweYyhjrFf/aiZjrCPjyBhjvLGV58r5m7vlYnHs+fpuuZ7P58fHDXbYlbfwVsuMPT4+ houotXaz2bx79+7Pf/4zMg1vt1tvyCoFC4yOQbiRzrQKQn520JYgASyB0U7QXRqOpxrFmHOavst7 T2SNyYgMkCFchKOn8KAY7zjoV4WF1VtL2zUAqY2PvrwcKp8dhKqZdqSe9x4YwBtyzm3qkpnX3t/e 3m45h4YDMQIUotDzPEdRpzzPTd6dPQ+2gDzPB/MosjHm5ORE0HJqtHrAIgr6inS0eZ5Xrq69M5md TAuyhg1Vbh/91CjLDbGhbJJPpoVjX7kht/cIJ2tiJNK/ZFQT2cyGShFa/wf0C79RaGrx7MEZEJoi Lv9WVaKA5UgCi/qmVEbnnGsKwIYBeu9zY237obp25LxlstxKBKIbHy6jIz+VZYmtInhAJhbNmpDx j8XroN9TLZIH8vSOB4MN0Q3CZo7h43QCBqtyAGhjh+hC7mVXEXch7/dWZOEuwb/PZjMcWpnQg1Oh dQYoYmItUnYafT5xJzI9U8jsKY+LdKhHShB0AuKmxAOAQjU4+drJhAqFcCEUVm7TzLuwonUdRwBF KqWoM1gU8T6rqmo2mxljpJQDnOo3m80ky4no5uYGpV6urq5ub28/fPjgttvpdJomvpW3G2OMb/mp dA72+SHF5pofavWwx6TyhDyH7sx+igbbx9slAX+0MfT+F3aZg5y9Xq+9Ag5V6aMu+XYmq1Rr8hOM AW5iyrK6rq9ubsqyLE3hXFN5CBwGAogk1zAFh2ssBKwnOMtCTeHknr4uz/OTk+O7uztQx1QO1Cfx viC6McljK9K/RqcD+F1CAr0yoIyJW5Qhe5W5Tnn6N9xemuYYOiHdTmf7kUZKlNkUzppux3svYTVQ CbOSqNPGuQ0yXd60zp3wFiAiKKQ1THxTzkwf/FTvPsAb3Qs+VYJbG6KAaESIqd5AgjdltUjpOUaO V+Y6uBl3FHbfbrdyhJjZGOgSIMONmtntdrvIC+89eZzGOKdIHdKYit/cQetJWZY+2MyA0K21EkOb xjd3MhyaoRGqwG0fZv04q3jxg6OWoVHYtciidnR0JDpSdJiZa66R/0oEi0Yz2W8mM8bQCNT25bAg lPhFBuhVkj3ydaYvmLwp/jzMle9VeohVDv1pMR9CIXzI+izZ5HyX6zTAt6Nh7ycf/GghnQfZnJ1b WN+vteXyLNbXecfMnv0+MaMrnXMmTC+0mPgM/dN0OhWGQ06cpqkUhLrIlDadTo+OjrC4QtV6j+f9 JwcNiikkZUw1PtGTo6/AYgsP+jGshqT3AKRkCDGGsHH7diFWUFy5Hy6rFBw79EmJBisMjfcehYck xaJRxpoUOifcMM2ns9vb28ViATcX49l4ZtuBQ7AZRBIYRuYRMdID4ZDMuk/9b9p1y7333Ru9C+Jl 48QAM9jvIdSpTXQ2KZpHydYXHkrUNVFPRjIcqZRmbWuCjEoVoM3YtK81cFiXUpbl0dFRw2/WbIyB nsOrJF0UDB+oGqO3mg8GERvCX/c/EaFsbK6qWohlpNP1VwarZ0CD/BqtJgeNhQgcmhlP39K3ALad eyP6rFe5DhlR0+Ijw6ApeiRVpGf4ORkRVhnxo1/67n/8G7tb4zHHPj5ZJihI8VWYSO1nDv5Dqnh3 chvD/fwJRgIze+UV6IMzVlmWNed67QQhyLObzcYbstaKu4MOzZBdiuhHzXNUVbVcLp2rv/vuOwqW 8T56cy8Q3suHcqwU9o8x+/TcelCCFgRXUCAWxhikFRHzhPwqb7RdQaqC32R0JAHh3os/k+xY4eRY RZpI4IYWnyJchGfR21SDG/VNaNDABEoxc4S3mGBGT++UloWmPHj5TNCCa4rQqTJB34zC5MOalThK JSXzgHRSvPeRLJVlE+/rwDdIv4VJ3Lu2qr1O2r+YiKw1RB6sCNHeA2i805n3+wFXVYMis8yIDJdl OZnuIAJmrut6uz0QDAYKDSXzdrsNJQwsKq2AO4bWWu9XDkFrYnuCYU9v9DzP8QkF21J+yKkA15TR 5mDJQhl68WaXDDasTOx7XTdbNOA8E/s8z6vSGcrYG2K7We8yO6GJRapQIuNqzvOM2HpH1loEwQ7P WHzSaO7JMpX5hOpq6403xMzxjkpBIykBVpoquS3iTj6dQr+P/+t/5+G+jJEjA1O+V2gRObkeFacw xqTGe+jkG442vDHPcyRiEiq1Wq00O9IRKmlajLv2L5anDg5nNFgi6HLQYZkoT2SCsuberzPG3GeP 4GbTyVDppvqkAq1itO1sN0TEDRtRsK93u812Wzk/8VyUXOu6X13vbUCwpVf1YwWEmppgv0ZM2Xq9 ns1mb968ETKTIp8DE5OAsE16h+z1OgamnJOB+FshGaDiMEOIrygnyRvn8zlykxhjpM+CZvEsPFpk EoAuptMpK8cabc0HJhdOKFMleVuCflhczRbIYEUE1dxVpK2M6KxXnhMQQb2CaJ7R4SzLcmOLLD87 PjG+UxWC+yn6KfOUeXKOM085G1N7tj7PczbkvadBrohGn/FYwyGJKfFVhFGQRrnOKuegHnO0s7nH g4wUszncP5HvmzsPjapTKWeVAU83G93GiU26Dziomg2bPM+Ns9iRInPYUIM+4jmEwdfZG7W04Zwj xVTKgcEoQEWcqracjlq0GsJtkNJhpHMVSas6VU7K0HRONZyM9PXOYxP106vo3P6Z/hHASCXQeOg8 MppE4YMPOQNciEWCKdArT+QUtAm/QU95bq0VhgPhD+JLzqwZmgZiwhO8nPUNWmmHVR55uEZCim06 7znYzhe+/cIKsw9JCPswu94YMK9ICwNjlKWp65qIETeLyDJ9/LEH0kymFPwStDYC0OQRDp4NJpRS stYeHR0hPRQYjrOzM3zFWzoVnyKh+RCeKmoJmzidiCOF8NlanVwUBcqFWuUfysyIy9XTIjohDAFE JJqEVMgRhB8dkz4zUCSEy0XpGKYFS0Nur3iOtrdggyzLptOpCSUj0jcKTensDwXLUQp9B2q8RNHK VE1hs0rTQiCj6Yu+WuUMnNIbDQc5jJGgqelAy9baoihEU+Lb4dEBLzcSifAcYzoAJafJWLxMMFdS 7EdShao6AAAgAElEQVR2Kr7aJIe65tyjSUv5fZlhUetF3AAr0DHQQi1Y2aqk2T6s7VS60gHwIXWP 7jw8V3w7Q3MyKEshCSn2GdmM+bCMaYwZkzVE3998emr1vqysvtJ52wMa71yU6KJwBiLxMJtgE+yQ RE3QpcsV8VrP85yDQZOZ4YQomC4Vp+IrpkMtDH2y7rMwuCMnoRM6RRr5LJfv284ngvSsCUbtvKe5 0vifNyxaVSFbja9cFfkl9EFRFFBjRCrSFMB01k26TJfn+dHR0Xw+78xlqUF22sCCTqdT7FIIS+A2 FosFeJqyLNnQ6empMCsDuBfzNplM5vM5Uo+IgQ98DAwZaGQSYLVaSeoRDPb8/BxMdq6KiFEi/wj5 M8rvTZNhzZpEndRPUWDIJEoFHFWf665uX+NwCnWD13fLiNsQ0uZCoNxkMoG2BntgTNEuDZhALQYz sw1jGd9OJ3SYVPBXPFDA9+12O2OM2N01O0KK1dUkbZitHuhTJxKXteyUyynxghFyLh+ESZIpq6oK aJGZNcke6Fv0Ru1XItyodu20IX1eOmrTduwi2cQ9WrVofqSrmgtOKUS6RaKzLbyI3FCWpZCig7Ox 3W4R5iPlHsBw6P4zM0KCI0ZKa33GgxzmR5KuB4DMSReR61Z16Hl+5Nv1S5kZud2A0MNmaDEN6Rsj NLfb7YB8i6KwRUFEzjm4uEcajgOdN6Oy6TwJpCxyH9P8RYF0UiM0PuTcx6HmYl27uq4bN9IRiiIk mDLBMTO1quhXyIuYPREtFgswAenNmgL1hZgJCCISB2RKXPoc+zzPRUUquyg6X/iaZdnFxQUScsAK o3fdfD5HPq7b21tkQsOD6/X65cuXyOpxcXFxfHxsjJlOp3ACFfwDnkCIBTxF6lDTVBT8eIWwcdHa ST+FQbE97hR5V1GVFIRggRAbZalJ2cHANfoovkbPZCdEfXPOLRaLu7s7ZOUe5Rg2GvYegpqAGRWo qWmwcD19YrHMgvaLfjw6ED5Dq62iGYxIl+jlrG18QTRZxf7e7XbOOaKm8UhzkEInakvZI03jxWlL d88H/ymECegptdZGmDtF5cwdufQ5KDYkI5Nc7xuRzIlpjxoay75J0KP2obwLKVlB16bHVJiQUznC YtyIopaIvXHeUAbNR0tUTTvfGRLyTDDM66T8h14IGtxd4zvgvS/LEpwBjPqh5X3oWqfoGem9gUlR HNypbQwxOuXs0w8NmPgkRl8BqZLvYcAh+qNNxVUfgCP7PTk+C4MieEC+ghXg4FCl7rXeu3YOwr1E 4eoDW8hYqmsns21D1OUwc1/X9WSSF0VxcnJycnKCd4FuyVOaLqSsUp/2HtyJC/m2sbuQstNk1lrr nDs9PWVmMQOlMtLZ2dnp6elvf/vbu7u76XT68uVLid2jNspF5+fzeVmWZ2dn6PZsNnv9+jUSquI2 +IJIt/M8f/36NTDndDpF9yBgw0gBNgXh/WIhku7h7dDooJgDGA7MubiRaqF9GPQRw+jwFuf2TKcg YVlBdAkKZiHHImb0IZ+IlNR1DYYD2ZJM1ssY1b1lh3thn/iL2ko/oyILImokh2Rg+8pQ79WbCLrE ej/AcGjpoa9BPfVQRyPx0cMoQfqiiORwCGHwbX9mMaxyqJWM61VV9TEcWoknbep3Cds0rOeM+t85 k/rtaVM6LWAwWu01HNJVZjbc1BoFt9EpNo1XcjS6yjG3fkpIJyTlM6JfH8Z2RDdjLaRkBjNLaDeg LHsTtHA7iyIYShfSRZNyGqWuw9V3UX5Muy2g9Vgj1/rgPYJ/1LvSvsVXvgRFSCfmHN4PwnMQTPsj dEbW7pGDD+mqOs0rctvNzc2rVy9R2hryPaRqiMudYauAsiylGraAlI8GuwMnYogimp29urkmovPz c2qHyLXH0jAE//zP//yXv/xF4z3cHz0lgs1ut4MWBHyMadtEBElOp1NwJ3Vdn56eIuwWhhg8jq8X FxdSFQtMQ64q0JJSRSP1szEG1To1ZFn29ddfD+g2NLbvnG0OeX7TzSwZPgDaWjRghpNuYzagNEU2 h9q7uq7ZUZ7ndkRKkjHQkeBFzw72qHCCoo0f+UrIvpH6SPNl+lRENxjlZSazn/vmZu7SrOrHO0H0 YN77qGAsjSYDeorG3N+FHFugXalj+4eaGRei5MFca6UUtY1NKZcwMLR0GCJnUELzZGmwuZGh/Ne/ /jXU8qenp9ipMKA453abLYGL8r4sSxxgYwwUl7rNZozMPtSJ9YY4Fp6/LNCsAPVPspZTD7bW+ZeD al2MHb6dEiP0Yajmsz4yHfrY/tFFA+n4NVmk9GgAn4DwDB+ccccKHK0+K3hKXWnrOUYyMY/o0lMC M4uLaKSwHNkX385ygTObTr4Jlh0oDIqiODo6QsYL5DOVvJxQoKa6z855g03WhmA9SPn4SftPvH79 +vb2FqYH5A4AlUn3J1QO3377rVAEXLcBpDMoionMAvpgimgX0aOyLJEwA5OGUYMLkVCdlH7p4fuQ pUYuwpLOzGBfKHgTItKkk/NLQWRI7AGYULUEG/UnC/W3gZllUNr2FFmC8EF7bfpQhEW019kkr6pq oojCY6Cbo2RmWS0NQvD6BDWt2sK0dhLaVHQjitUPuj9RT/TXlPuJQvKIyNocPijSYFVVqLyqn5Vm B1AP2Fvhxkzib7EX7sMOjjZotPb6/DSkRTFhnfQDhz/ScHgVZSMPCoXobKdP/yRcRd8kgMEHdlgs FlC9XlxcwK0JNuDtdrvZbAwTIof/8pe/gOE4Pz+HPKRnXvbD55dA7wnRHo5+0juKR/sjs8q7BXGQ lXeeXmKjAv/AcAy3rPn7aJN75Rg0kvPWXU6HEF3BdnUhcq/T+P0Z4Zm5DS2EdLZflqUnXwVwjpxz HsW7RiwO+BK51YZYPy0mabnOh9Kseahbtl6vpa4pNOd9eR36aCfeBc7DBPsCfoLKxBhDhsTuYEIg SSfDIU3JjEHfAG8V3Qfxl9RaGR8s8qSwNP6enJw45168eAHCLG4DqZtF3a7U7YMXf5ZlwGl1vc9z CLFNtroxBtnV4OKmOSS5QT6L6UTWyDm32Ww0edXDiRZ0s9mgIjfsR1KOjtrRADY4XGrBxoa4VCEi vidu6GEwZICRSRHqZdp+T8wcxSPpjSIrN6bHmpXr3NZNC8kvnXbETs0hPG+FuV6v1xFnN+YoC7ch 1s2+oQlO0fyZ6BKLokBn0imNhMiU/eoTNKMFEvG3VkUx5H6501qrEZ4Jdl+UwO4ESEuZsdba4+Nj ZB2WktlEhIKKk8nkqmr8mJCNNKo6GE2XMBzhv757PzNEKxIxFnLdqVBkmfyR2wwgymcfSuLpJZbW xGnUuV5HP3lKEzkt6Pge/YrAIN09YGCV1lyI4MVOeDQt18fcd19huWK+ZHWZlkOaBaWGrQRLiSvj WUF9p4g9esIFVWoLrOwWE/Kg+2CR6VTjUz/DEbqx33JC5+AlZoypXI30ibadCyBtBwQb+1yYjKIo OrvkvUepJuGT1us1Htd91i502+329PR0tVo5546Pj/tkA300cDYRKUZhBefzuSiltLANG83XX3+9 XC5PT0+HQ2SpjVXAhIkbOIZPiZADWswhvbp2/EeIkEyvJhOaKETi92KxKIpiV5Xa6VjuaZG29hRp dBeZAkZ5fPRtKVFnYeTDhqJ7GX44EQcDt7W/or1vIh1R8i4rKVOA6bbbLVTTzFyWTTxO9K4URL1h VJ2C/TsC5yjLEH2QreC932w26L/eCvoRCiun1TDgjjUW0DOmP0TsRQqivez8dZhBxCk9PzsHzGaz 4+NjkYeISMpEVbsSqtq6rsVdqygKt9v2tq5GxIM6j3tg388Hrp0BZbjP+ld4acCGIicrYjhISaje +4ZOKRjYn/qnLMvqEMnVSVd8koNBQ+06ImJM8NiXt2upDrtaRNu+SaAnYEpUs/3+E8NveU4FjHMu 0lR571EsrzZtI9JoYCIi5qwJm6RA9U3wLWNm74iIcFqFtklAhO2v9zEMVrmsRj/VdQ07WERHDkIU YhrZMsCgSV5OHMBGId12uQAtwMaGQmI+nyPIP+8p6Ko1MXh8s9nA/1SrUvqU5UVRIEl5hGCjiY2e ksFS4Co6D6NcNKr4LSXJIKhN7FKVCT6cnp5uq3KxWOxuSvQH5G+g2xokNUP0yP1cTIVw4k2iNYK2 IN0uncEOMpsDXIgPJur42XBBVAtpC8Oz4EN1EgnRlABgua2T4ZBjg1HDIGfzQhYDVuSmCKrK5SIb VO4Uc2m0Ozt3UmR6kPlPxdDos1d+QJr5OMj8IV9q2qYATt1isfjNb34znxUXFxeiF9Xbi5lPT08v Ly9ns9n5+TnEdPEwLcvSEXtDnvZsBSpDNtvMUMw8j4YvjRfpW6boHh/cfrnJeLvFX82VRuyCUzln uSsDhybzooM1iQ3YK9pDXRYi7Wakr3vvyXBnhJfkSqJEQQ0OSciAftD0ezsNQsuHwxgTyPZYM1Z3 o20DxKeASBROO+O9rz0qGRqFAu8HlhplT9O2aT67mqlopSa6vr4+OTlZr9eLxQKe4FrxLDhtMplI qo8BRkE2W6RUQ7Pzo4UONunUgEYblXoyaGlR04dcZNJspyJc9xCfs1BTVw9K2vQh70NkDRdmWjer z6l4UVhroWgfQALN40yScci2/U7gOUeDmGQ+n2sGMRI+NTdJamJxHZ7Cx8fHL2ZTa+3FxcVyuVws FsD5OgiRulY/uhIdnAcWb9MKOq2xj+6BfQti/X01HNGkNG36B7rI5nmOmBQKtga46Euw1kgQtYow H1VV1b4phIgDIz7bPrgsgRhD8wZyLuqvoii4bcbTy4+zKrsZvA7cmmy7CGcks+oVcfs8DWPHqL+m MigAIWd5ns9mM8SDST8hPWw2mzzPz8/PnXPffPPN9fU1HL9fv3798d3bqLcj+/ZjhDHchkS7UbCk cPDkiMKOtLxolGN15xmkRILRe0y2lnOO27UhTFIfTgu7unEwHNIHjabrkE63T2EmByTiqvU9nVqQ /x0wsO2Z9yYVL67Bj5uEztdxUPDYjHa73dXV1fX1NRwgvv76a3ADkSJ5Op1eXV2JSwfK2Y/sgw9x bWVZXl5efnu00NkvqEeA1FuxKIqo5oMPuT3EUCLZFzUGJqXdQTQ4tU+HDQkY6yRrqh5+BGmMjHwG 4aM2t83tpAauu+5jB0hmgYidigC/oibOgDja9xZr7WKxmE6nv/zlL1fbTVmWR5P89evXZC3Kc8pm kBAhr4q3iebShowgUTjPWIZD2yNoXGAMqwTeKcMYDZLC2qccU3umugX0g/1BI/C+JlWc0Adjm+Du iHI3n03TCByYZ7PZZFpYa1+9evXu3bvM0MnJyXa7g0wA70gKB1XalLcjBEtmRo8iz/O6zdFHHnYi hkaov1NRjFd36ookZKDz8YOA+y8vL48Ws8ViAc7SBmcrySroibNJvlgsgGWstW/evLm6ulocH13d XLdWloiDlNroNjBeKF0/M0MS7S5uf+b+nwj1TZrvSg8hGEc0CvgAthi/CuehkQuHyg4iZgn30Ok0 qifZq8hYXIm6IeRnYC60DBA0bR36FfmMbeZUpVC963ziVR2BEIkxW9TsY0ZNl1fHvUuBfFLg4I6Q MmTM7NkHj1H3eIbcE9mew+6c895Op9P1ev1v//Zvb968+c1vfuO9/8tf/nJ6eoqoV5Bz8WCDyIRF 8d6fnJxEr7PW/vGPf/zlL3/5pz/96eTk5ObmpqqqX/7yl2/fvrXWfvfdd2/fvi3L8u3bt6Ap2MzH x8cHB6KjPQWtee/hNwbcC9Wg3N/4i1SVBPMLlwBTL8LodGsRi9NJ3YdVO2C+866k7/I4jUO8NtTv vbu726zXfc/uecegNezrXp+SWw7my5cvnXNn7NfrNVTOxWwWncHz8/P1et0UNg/XZeqwMRCkI843 NJLhEEsK780HRAGngJ0UjlIPhpklOIeCx6VGN/rzSO3lA6RhPAJdQmTFkJ5L/yMxkYNen4OvNTj6 r16/ns/nZPNf/OIXsAicnzeeIvP5XAemS+NCRabTaR3qq+Ee4e6ttU2JcXUqvAqkxnzKiui3pJPD CigYqrQkYUfkL++EPM8vLy/zPP/2mzdwyNKrCZ5jOp1uNhsiEoYDSCoyuw5DIIRj76QH7ZDnARFY dUoSMUaIJYVVMkExherRYQ+4kMlYnZd44PKUxgKp9sKGuIB0X0WgJUtpdng1pWVkUnKhJpZNkjd3 AgYoT6W/Drz6ywev0lnKlapuZrWpnP4p2aQgkGSNldO51Wp1c3MDSfrq6soYA+9L3We9Xp3EGPf/ 4Q9/wCpjb3///feobfnu3Tvk4KpcPZvNsIjgWtKdwKHmpQ8eiM452KM1hiSi9XrtvYcThrbUIERW 71udLk/Hg3Sejs1moymaJhak5OTos4DmSwQPD65JN3jv1+t1udsJ/k8nikPQrFXFRvSrARhydJYp aF8Wi8VXX33lnKu8s9Y29m5rp9MpdBXylLTAoT8QpeBiAQ8BpEoLOTZ7GA59jLGfjMqPG4nFWkNA bbUqBdEN3sKRclWfsUjx2zfpBwGag8iTAAZQaTky03SsHMXrxKGf4IgvLi6++fm3RVHMj06IiJo4 j2YloDzQ/iuYk81mg40Ofn+5XEYDB3j1XiFCQdBh2W04ySDechTvRWvvxW3sdWJ5jjGWZXl7e3t7 e3txcSEDx3CyLEO1WzmB2jKKTHwHlVKeiA8Femp2Sq6MHNEzALhZ55ou1bUnMs5xVTnnvIouaVZZ 78zAZxhmOLkIHjThnyyKnMqYV4gwnVw0idOACxwJt/XPKXShS+WDk04CNUPLQiFD4X60jNEp6GsM I7KB7hi39ZGfDniE7ufBLWtHXYySmevaPZV6Yxi898R2Ppsvl3f4end3p28QapoeLvHw6HQekjMO e6vgASIC9aLgN5zn+S9+8QuJjDPB7weNr9fr9XqNXAZnZ2cSgSL14aI9uV6vJYUGriCdLqzAROSc u7y8PD8/v729PTk5EVMFJUtsQ0YNffG+22BYF3IQgDkxCZYbRXjfzZixOqRblOvpEFJ6gYV49erV ixcvqqpabtaLxSKb5NPp1DGv1+vXr19fXV1dXFxQ2x3eKZdB5xw4V+3qDm6yqqrDGg5Z9ZRCQEDX uIAS/xS5IhYyPTx80PEmSP8yUtHU99PDqA623cFnZ7PZd9999w//zz/OZrPj0/M8z/NiMplMUCic gvo3EsiQl2K5XG42m/fv35dleXx8LI6rLalRufhyKM4Cz0GoCiMHYBv8mB4w6ubZQaE2uh/6Sez4 6+trZKaDJ5Egne12i+2I1WTaiwUQpsXq9GDo7PCwdP7MIJyEZiyEd9Q4Wm5LXS95MHvHGL5tDHjv 6RNkiw9Euvkq8XiRQlg+pFhSCI/mhJ6NyXgekE0riJTJMjMc20UJ+uQvjT7LtEPJoa31FLgiRE49 +HU+pBcjImPMfD5fbdbHx8fL5fL169ebzSbaEiJOwPhyeXkpZaqOj48RIkdE2+1W3PBFcbvb7aKQ Be/9x48f9Wm6vLykQHGEBolcjRm4vb1FhD8FWQuZNiSehZQ22rY9oGXU6ZwPg/ceEdw2OEKJVcUa KxkZIsxgQiSz7CjXLsAmd9qkiqduhEJASjGfIevo8fFxFQLaIV76UIIOT00VA6Qpl1yE8FnX9Vgf Ds2uCpqDmOtVrC23fQsiFiSNwog8GIRgPwaNdiHooaAjOW8HNwRaBsPx29/+djKZnL14eXJyQhY1 EZrbQFci6/j19TUYjvV6jUy6d3d3KHsWv6X9lZk3m83d3V1d11dXV9AckNpwHPQcfdG8TwhZlsFR OcsyBMT6do4aIkKCmg8fPuxHFAxVzHx3dyc6Hj3GYV6hc8nSK18Ot0FKR0XhXNQBhAURrax27B0Y bEprrUrjQ0oYpdZBMP0fOkDUVA8YtYbQ1f2gWEVkyHhlCHhj7CduDCXxC//LeA6AnALPvixLZOb+ RFtaWwRATUXL4py7vb2FCCGTLP71D+uPbocCaSzLkqy5vr6m9sYQAGaTxJd3d3e///3vkcIxz/M3 b95oSgElOkrRSgS+tENheuFR8fLlS+/97e0twjHEuyjSTOMiUhiIZhddBer2wSNQ8oJIOC5uG46t 7dvD1lowHIJDkPaUmSfF5MWLF8KhyiPoCXJCQtKDIjlrpwuXCRE1effbjTHG1OyhRkLjsIxrPLNX y4UrkilOPuMe8TGIk3JSl74oRT0+Ce0lhaekTTgPCtshj4gCIBJoMDwd25JlWd+apRebwXeQrqc5 tKJ2++abb/I8//Wvf002N8YERXKrS2JQAIHBjGMHLBYL5P9eLpfp/KfsEqKScD8CrLUnx72GIHqX lC0bUNMBsILHx8dfffXV+fn5xGbIcuOc+/jxI+KAqIu3NUz7mh3OffjwAVgmahwfjDGjXDa6uveA p54NOGQ/lBrFGuqQg67DxNalyh7WbTxShfvM4IPfKFQgEbbhULfsSXQ5D4Nn428avpOawkNwj3vy hWTl3ivmM1FpYOfIFkWle1YxU7qpkdrovnu0CU5TeiEl2sHl9vb2/fv3FKjX999//+rVK8FaMK8g vab3/vvvv4eTGWgKzBDgUYhIvErruoYQiA222WwWiwXEegTzX19fa7EQ4/3mm2+knx8+fIC9YDab IbuXCVma0m2TB8iyDH5vB6dut9vB+xA8DdipztONi8Kaax1PJ1bpO1A+VKbNTWMFc85Rl+pRjqo4 jWrJQUBE4ul0+sCwWGp7MuqLpLxBI1ejdIS23/lccydy0ZjDASmd6En7uUT3j1cM+ODlfn5+fnJy kud5NplSl+XaGKuDYzFX0JFut9vLy0sUJERODtkNjT+ztZEeNVL5SE7ftIfp6CJNmvSn1XjConWq EDi4zZ6fn3/99deWyTnnXYUAY2PMhw8fwBXByIfUokVRZGZP/+DI0sj9htiQV24rjpjNoQTdXzBo rQawsxRHxFeZfM1bQIYDO6vP6gBSSKWWzwkhg6fNWiehEy2mWhxtk+Uk/IqDw/VnZDieE6DhcCq9 ylOBLEY6j3gR4jWWy+XJyYmIbcBFoms52KV79Vkw59u3b//pn/7JtauRW2vBo4PMQ7aBQIuttVwu pV488OHx8TFkOSAi5BFB8AvsLxRYEwqmEO/9brf74Ycf1uv12dkZDmBVVZPJBOpk5xzqsxBRlmVH R0dv374lopOTE1wHab+8vITqF9wMYnkgocEKA5YOib/Adhzc0joJCnQnkFuieZbjQ4r4wq6NRK5R s2iwrwPALVmWlS6Or4moyd79P9DoTlEHCWHxU47Jehj/fl8pSlRMkhU/1eqIzkokeD3INkLbT27a TnvfNxy99x58gLZ3cLv4yEDnoSjB9L1+/VowfvRMlmVEe92DDd6dUEkZY371q19VVfXDDz+4kF8B h2q5XO52u7vVSrJ0iI0JCT8kD0ebCdu/a8yKiDlQNEkHH8E9m83mH//xH8/Pz1++fFkUxcRm6/Va XOjhYiIcFS7iYBumoihubm5Q8ljyGArw3udoyKoSNneqwXom9UZ0yDs/IP6IVJIMjSB0C8J5CLqM RqG1lwKCVuQvM0utbQEctGAy3/tpcr+7T5/OLNpsHfPSdc0findNXz1wg0gR6W0t3VjrYrdaoksD 2j3Jwx0e+DXVeI8EEL/trlqtVtsSRXPC0X7STZ425ZxDfogmNGa0iTY9CMMvav0aZuju7g4enVp3 jt2oMzReX19fXFxo+qqFXhsyOuZ5DvcyyDzalC/RvBQkN4h8y+WyruvNZoOQFtwMKZHC9oOMDrRJ IZ2XxKh77+HK6py7u7s7OjqCc5swK3jpZrNBbgXxYB0zt6T48lQPqr8KbgePiGhhJC/RM2BD9FDk /5C2Cd7XKNcQAQkokavipxU1BYFqMpk8XMMxDPc9bGK+xXRg5QQzdtBRY0ry+V5vQWPkH5vntaWt ryvDO3a1NZWh2lrHXBvLzCVTbWwd2DX96GJxtFwujclms4Ux2WJ+TEGVpIdqjCHfEE4cJ2Yyhowh Zs7zLM8XznkJ28E2yrOiLMuz0xdlWZ6cnIhzKPYN5D5f129ev16v1+V266oKneP2Xyay4R+pzzah 5LZ1ZyvKhpor+39ZljvnnfM/+9k3L1++PDk5FU4IA4FbMrCVDkgDeO+vbq6rqlpt1tBeNt3hDJ88 O+dLpsyg8gU7Yk6zJjTbnUOHufnHnokPWJfMoNdCP9wbh2oFhjhyczuXBgWDsaiyNNVMxQ59mpDb HrfBrJv2B2cbf9EABWmJVV6W1oNmz4Wn2sFeRra/OslIEj4eUbiQYPtTWDcizH7w/rF94BTBWgq7 yqkZwpWSuCS/MW5j7M3UVZbKbebYOW+4vRXNmCr1vb2iNtJqmsqynMg451HtYTS0pqKTKe/vSHMD PDfxWZvY5NRYa3e73Wq1evXqlXAMUAnLTvPew/wBn3Q8iyQQ2tVDbhb/dw7mzs1mo4MBRTTCKROj EhoUPkacNpA3BdIjfi3LMrfxVjHsyTvD3rCnnunCMxn7iaGMvXE1V2XGnn1tyLOviZ262Td/2Rny 1jCxY1+7mq217GtDOfsQM+LJ2FyQO4sZAfpvsjW6J67cZWWMyZrUtGw9N8KBC/pXZmeI5FBwtFGN YarLioi2682nYjgiiM4ncmXqK8CMQIjWWng5UJDehMHUjwja7XyFhrp2NiSeAhW/ubnRHJzoPwaG kOe5J/fy5ctvvvkGOdcopKXqHalEC7ZDDbGbkZ2zEYu9h4Yqy7LZvICfDjOD44ZmTKJJUX91JMrr PPOaGHjvDTdytthc0kHh12+//Vayqda7HRFNJhNoX3Am4aCArsrjIHWr1Qq1kYxpakIMD6BFFANr jzGNGfjnghThgvmwPUW38QGkFCkUsT3AguehfA9RE5o+nU6zdi0lvZqCENudMfIrqgghPFv3x4rc siAAACAASURBVBNDvRzpP7AnezfbOLIbmUjkyn1VpJ+I2/hygIPDCjOTwdfnUd7tASTzoEeXwHD/ oj0f66GpxedFTUnABSy5SE2muQffnwZG3yPGKfGrwK6GTOtCEd2qqmCg6duW0Zzo3urXQUoEm44U 451zouSBXvAqzbRXoG/ofMq3C4brADGZUsGoNqQQJCImhtgvbB8HyxoolAt5PkizhsoTKDqhrFS8 zrlHMRydo00xQqehqHl94uQhGxQGRRLPhq5X93mzRhejDFrOOYR7DA4uHkKe55ayPM+/+eYb+Cjc F0xIdmRCdXtqu6rAQmmtPTo6kshJ59zx8THY8JOTk3fv3kFlp/s/gIVFhn48pp7NZlgdJHLxdb3Z bE6OF5PJ5Pj4+O7uDv4ZOG/Rs4jKUZ1hZjYgIc0t0MJ05OUkIm4lZIuNl48c1yDs4yzuC9IxOSbA a50sch7Kggs2FLZDsjoSkWRJsgEoReJqQlyTMb1BOrvAI2Kl9OnLAk+n/YdEg9WL2Qc1HIKV9IPY 8KbtdDagDtFYj/638xxgOKqy9o69YfZYFXKfnskWoxbsCNZanb1wAKIDyMGwiK/DdhmT7UlX9EEa AVFA1Mxms9FpK7FdI54bANIoKkCAxE3IptLMNNgsE0AIMywCIpSaxNAPJzatC+FQKJWZfXt+wP3A E3MYd6WMhXRJntVqIX1FjknEpnjvJepEZrvpqmfvfVl7IlqtVnqMNjjWyLPRGXQKKcmhFiQmPb9H WOxIMD11E3KVTb3pYtvYs9vtRD0le1TH1QgMS0Wi6k9/qlUuegkh0YFnA8sfVswR0enp6YsXLwb6 0Acy+0JLFosFcnFScFPygbKCuqMcSZ7n8/kcdnowItfX16vVKgq5llHI1kdrmNJ0dD7EM2eH1LOi wMdbrq+vJ5MJeV+WJdECakzwGWLyjFrAPaKutJa8b9RDxrecG/S5lQ/8iSN+B2jYYxgaoyLjSeVN 0ZKNHJn07EDfG8lVUNRBktC/5u1QeMGPzExkoHkSkc6rMgWAmhrbpVT3xXU4vvUqOQYLvgsGjDQc NqQrkLntlI3kJ3oKdvlHASJjeO/Z8iGS9JSQZZnNiALDATe7kTwHoBPD6F9TtJDZJvOszn6hH48e gcSoIx855LlJh4M9Jsx6Hio5iCpFW09QUw2jxhX5lVUxARNShmtFIDOvVisTPBSF2IchtzgDrcgx IV9w3wSiY4KoTeK20gkQqmEzwmfwQ+KlwMp7Y49mDVVVtVpvmXm73er1MiodjsynVSXlXMjMlMJ8 PtdcUYzOHgy699K6vMmGrPv6VyKCgw+63qcviUzIzQj7K8gPdFJr6fWEHuQ5rLVlWVpq6MHZ2VnA gwNv6xjL8A3NcZoURIQ80JPJRMolY6ci78pqtZKwF2wpMQw5lfhBaxr0RrfKOSZTJT079UPa/Ale B2TMV1VZlifHC7hZlWW5Dnn+0/USY1YQF3xZljAfkvPMbJWzjiAa5xx7ZqTb3EO8RpHA8blAcJP4 1VNgGnCD+ErL/Gi+AcF4A+3bdqC/DYHv4AlMkghoOp1in0BPA5cRa23qtEtENTEWaD6fQ9nLY3QJ /b/rV+h2RKLQOJTaGFkPWdrRp9Uk6nczmNjgSwYMA9y3I95WZenqyjvHzntq10yGoPmpeoLtB03Y sFw3DKnwEHEe0WdodtO1q1XZFFHL+1D9ioKGI1e10ABCVqEwFj5DNrZWoqApxLOI+sSEgCkhz8Jq GJUqF42I8MyhNEEWEkDrSSCVLSOan+H5lN5m44pC1KqcqgAmWcJ8xBNlL6maxuSKdHOwgOtmWfmb 2xCgi0jgbNZohoCItOB0e3cFHS1aeHi1WN+2LtqkRobIYX2NyDbCJpBli7BJNICD/N0w9G19yWnT Z2qRuO1OqjwS9GwYY6C5Sl8B8owsF0YZzIhoNpudnZ19++231tqbm5vLy8u6rtfrtfAWPmSREnZ7 oD/RrzgkenSaJFRV9bvf/U6uHM1mRVG8evni/fv3OIrCWXe+C7+GxW30rt57cp6IMvZEZNkREcyV 1K5ro7raocJ9JDwVvwLuQZy35ZiNebaTV+a2HlgMzxF5FukwUiXCLuncnlQDZXSE8nuHnq/X6yzJ 5dwH3FX8XfA7vmq0gK0lLj6dIh21TS0azfkQNvwj5S3GAIio996b586kok3PvivrwXjQ3GEfytW3 idLet2ORTCipAZw2mUz+53/+5+c//7kUSRfHI90sAk8i8wczIx2WDunSPA1UAppIExEyjxmVJku+ pruXQ34/0aZ47007kYpve1cMHzThcjD2yWQCimn7/biNMrhEDAe0Glpz02L+lOHDOfef//mf2AM4 dJHN11o7m81OT08RBwQ+IgupWmWkVmXbykN12W5H94Ngk+Rl1CXED7Qs5gPMkfaP0/foN963k8MQ 9Q3agr4OCx9AgZe6lxAQadJkOzZVkh1Bi2Wt9Wyh+Lm9veW2OzRgPp9/9dVXeZ5Pp9P5fI66i3pQ LlQIayKaHoqaWcWe4cP//b//l4iQ7PaGeTabzWcFgnVtcGvSGk7ZJCjapAs2Ujh7MKkYqDICw8Gx VuNLhL6tApEL6Xoe3LhRVgZhOo2yv1DbKUSzhsPNTqdTsS3KHp5kTfA2MCxC/gbaaTBacoW6kMA+ QVC4Jzrp6UTJoDr9VH4sgCrHqWt5F0DFyHXtUK4NPk7E9hOk/urpgRLtsPpyYDWMWYthPbSA9/7m 5gYmYw7ObdTeJ032M+9hX7i6uvr6668ji4C8SBhZAUG2xhh4mHWyuaBBRrkpaF4kbRxnR0+OVoqI QdM5l6Zy2O12wjD1oYj0alPurqq22608LhA5smiWAqDtmHpm5CnfbDPvfe1c9fbtX5gZDubg0pDi HU7reZ5bS6uVKYqiqnbONtyqtkhAY2pCmSSoJHItIY2hoJHCUz537i0eFEQ4uOQIPYvujxbjMehb NxJZUoTpG8N4RWatRwKiSb335a5er9fNHBqPjB1gtzt9ZrMsm81mr1+/Pj4+vr297UyRnvZ55PUI OKjjsDrgUO/u7oosq6rq6uoKzijUPufyrHR4MpkgNp2IrM0hxpVlaTw75wprKGg4CI44iGThpqEx XX1+6ERe2tHyAY1A48rMwmWaLvcOChoLuZgqFDVfQkHZIFZhzRI50wgAEo+dmsZxBbyIZjgedjD7 MMmXCRo1fSLlipwdaKTYkndPpnsbCSlrmMIYFe/BKQr7h621t7e3r1+/Fhksop34DPK/WCzev3/f CCptb2JpVuwdWZI6wqsaC7qHgv9hVZFu6CMsMlJEy6UdVuWQJA6lk6KMCYoUEGZoNptlIXH48Pyj S31VeOq61qbbfTfCfIAqoZiGtRaECQwHMsIhRyqiiOGDODs5kvQkeoxYNZAPXH+msNg+wHLAtEwJ wxGdcP9EIWKdKy1OA8PP6nJrB28e0xMRNBH+Wtc1maYmLZJU6uMnZwA8JmqygNhH7G2ajW5MZ9J9 zEE1B5ECKhnvfZ7n26qaz+cfPnyAC60NYb3QzItgCqjr+vz8HJtYBGt8Np43m01tyBgzL3KSBVIM h21jlaiHKX9zX3gkCelklw9mVIuwIbCALAEnlVEHXj18g7V7scMETzrdfp7nzpDENnPbt05ArEWC WzXDof/et7cDo+hECM8M3BaU5cPBp/BhpJ7De1/VdVXXtSMicobYPEd8ysFe0SBHOCwWDmj+hTkI bJbT21K2q0w4SJ0k2PAqsEW/Tisk8ArRqtahdKJtJ3SRR8Bq47AIqgeHrVFWOjo4+cE9M+qMbefh 8MGRv28+U0BnrLXQTeq+RRBRJckV2dnmwEWUGpXWvPer1cqrgm0cVO+C8KHWlQXVTBWresitWir3 NRM8IYhoRcogLXsCyT0fTFoizNDHKEQEIIUxrP19etWQAThT1nW92+3qus4nFmnvoLy6vr6GPiPP c2TJxabHAkeOMsKT6aRSERwcgktyS5OiMUAKzjnjvbV2eXdTVdWLFy/QQ5lAjGs2m6Gp8/NzrG+W ZavVarvdVy52dV1VlbF7f+w2ASP5Kz1K+6a/fgK4X7Nj6CIrx7dUgXGvpobf0nkdG4+Dhi/LMiae TqfI7yLSYfpgRBXIsOS97WNTngq0LvY5ge/pLyLDj6aC1f9abcegTMbsdrvlcrlabYjIe6g3nqD/ 42HkMO+LA4eVJfJBtAvU5Xguoo5XHu54SmQbUULoVwi23263CLrhtlsJsnVxsOzjoiTSEOYGzvsp gpK3aM99GZT3vgoeVOK65IOr/sGTAiIYsTh9vjUi6c1mMzBJRVF0eob1ETK5uNvtkHtTo3QOiYLg X4i0JSBSYOO0b1bjKhAysUoLTX6PzyU6CLROZvvEmuBJJIMhJVOOaVwPTtrRZj9WLsQJqDAtcgdT tYzrzz54h9Qewp7ebksigouG+KjCmIqgFekqFg6qDuD9zWYD88oDsLMWDtJhyrTLvOXGlGVpiK6v r6fTKWyfQji1s4tsemstPDm227W8tKlc7Fk0/J0Mh1rreJk+GZ/xrHBfwibQ99RIZQP4bM++Z/+3 QFzcU/tCp5rnYZC2ENmGhm/+cYE3xhtTO7fd7arKMVNtrCfvnc4u+kwmpz6z0QCToTeSfBUy0/eg j/LOeY8kyxK3KNfFpAKUAkWgNiv07Vs4UMtbXH9BZuxnuGQK06B9EeRxH0DKZ0ojyAuQqliEbRS1 xH29cbUeRbcfgZyRoig+fvwosSGdOirdZjMJwVXo/Pz8d7/7HXorXeXgGohJwESZkHs+n09BpCJO UZRJ0r0clGz8odU5A/TMjnx8APQmGMah8roH4BoY11O2ceTjT4JMoWQTPr0sy+VyDdXFbDZDdZLb 29v5fI5Ng0NIRIvFAqFKXuVRsNZKsSVoHbHM4g4sSkItcu33mXO5jcXZAVqFNoW6MHtmhq8ybHt6 jbRhBWo36GakKR/yfzv2y+VyXuToPxE1vnIdGo4nVsJ9CRRLK37pnkGeglKNynjhlbla6nGYJHRW biZz71M8mUyquhV3fa/H+2BkO1/Cqg3DvfhgkKtU+YoleZ6xCgU1qngsgHtKmVPiLKxHrZMqRQAb xGTaJJgO1gfb6SMMbS4yD/3DP/zDANFNAXRRpEoJ1pD90wg8ATul3IBWpUBAgh1B0rHjBqlBI08R 3O0Tn98nDLSMQNDvzc2NFKtLH+nUcOAKKif813/9V+TqIWwfcgZiEiRjOK/sfD7P81zqsunppcAG GWPuEbZHinvVnRieggeDFpeFMj2mQewnOQOINtaYPdEGs/xl5jzPTZ397Gc/e/XqVR/iHgl4HTxD KVTTqesaV2pXYjfDSHF3dwcXbmbGB8RHEVGWZcfHx6enp1BtFUWBG/I832w2GOxms9GmolQfaEPo jRZu9Og6twczO++ZOc9iLMMhLEUOpBYF5KiDZUbYt3OuLHfQBEbKFa3nkGsPm/Y++HJIV8pkRFfS XRd5z+Vd2ZdldbSRVS9ZVVWohjBGzatfTffxaXgkHGz/y1nHscCGmdkyM1eVK8uWf4CjPaV6Wh0e 7x0EyRiji12bkOgWyV1IyQwPe1eaKwEfQPgLUwA5sCrYaZT13AQfIw5OHj4k3RpDDmSLQq4OqKaU AE4WbySVe0O3oEX8wL43Gg5gWh88KqQdeTVoVspwiAblAfOpvUzkohxzUScg5pG6vF9pUCeEvxJX LPeLFzyHhAt1KGQDkrparY6OjqjnGArvMsRwpE+md+JlT+JBOQDazfUBIGcGxEwcaJFmVPa3jyNI jfw1gWb++te//u677+x9KoNHmhtN+7FgeC/8M7Isk2WDNyjSqMPagiQcsGWC86jr+m//9m9vbm5e vnz57t27u7u7PM+vrq5ubm4mkwny36HktLw61a1F6SK13Y4GkZ1zzlCcY86GUjhyHbwUKeZGXs3M TbV65+7u7hbTyWQyyUPe96fFs184SCgQBT7DhSoPNnGYl0WsVZIxILhUDHCuqdnGITFRxMdYa1k5 z0f6vwg0GnL+k5z6J/SU+rzQOkfqf4YQ1XCKBEvoZrMpy5KZmD55ICz3u+fneQ7bv2SWfFj7pKwS ekH10dZ7VWs4hKZ6lYiIgpvCPfLEhHME8o94b0m5qxkICg4TESET6QsOmJCXcDBdqBXg26Bf3anh 6LRxHAS9ECkBwldkHaTAfPjgLJK+SyY8fQXoCx7HhGPOTShQl6taB4022jSloFK8IX6mzSsiGQhg QgJ5mRfR6ssNpLjXZ0AQBxmag/KN9x75wtFnVBQkZXo07bhkiYzHPVmWMdHf//3fv3nzxlpb3V8t lpL86XQ6mUwWi8VmvUMSSSIi44no66+/hgsV/p6dnSGa+eXLl8JpOudOT0+dc69fv16v1ycnJ5vN 5uzs7O3bt0VRXF5eijJQePm0V8xRHcrYaVRPESXz7NoFcWwAHSku7K0cXWlWwLF33jlnt9ttPpnk eT5JqiwOwwO4ky9HJk7PkVfFkyLFQ4QpBNdQe0Qyt3XdmJ+x+RPGmojIhQtOZVdM++lUALlzTiTl L2cmv1iIYlWcczVQtrHlrt5WZeVdTcaJwGqeXJd3GIwxMOOijNlw6tvHg3AY2P+dqZhI7S6UAaL7 6NRBy0T9AFsA1PvaaUOYDx2HSMqzLeKNdCf7nDMabQTFasu+GJNhAAsILmcY13nvJdeO6ao+LbdF P2EettvtyckJwlKEghRFISoNkVhEEcXBXMVJoD610Vqs4dA0IJo+uKHK10+NYj4FEwOFITApymbi sgx5uD9M7s2bN9o2di+Q9uW0LBaL3W7nnJvkUzhLW2ttRmVZomDb8fFxWZYXFxfb7RZqrvPzc5gq bm9vJ5PJyclJVVUfP34korOzMxhZkJzj9PQU6cZFUTncvU5GWPdcaz6w76y1m/WSVc2FPM/FVKSn Tkvkep6dczB8IidPZYiZc+fm8/nEdmfe/Axo+NNAdFxJucIZlUdZ3ykgTKf8TQ3DgkNFw+H7/aOF 4ehjNQTEh67z1584j5GAFWXm2tUI17yXPesTgQnZbPvCKTsfwYeRnfcqnNUneY1TFKTtFMaY1Wo1 snam0EsJqYCfHGwrSEUFdLTZbKCxCFmCWmEvuil8BQaWUeijF32uqsoSR1oiOP6PB+HGtPqnEyEA mHmxWABde5VuVUuS+IpUT82V4FhTVdViscAsiTJju91CXI9Enei9GnvYEGIjkGVZB04XMUj8cinY I6DD19noPvsJERjoSfST+HCEzTGUf13Ae49aKo8x7gBgbkDauLOzs7qu6cSCo1wul2T8xcWFTDuE DOw2H6JhZVw4JMaYo6MjqECXyyUMK3DhEQJ2cHRjfsU2AJowgeZJV621YHc0h0FKZVKW5e3trVNZ AsHXbrdb76q6ro+LCZiPLMtmk8+cJOZ5IOI5tH1XTm/KmgB88DDFX21vxgcYDeE/SkFrwu38B/js TNxsyjXqr8Hvh6hH9fUTdEKzjo1JhTxx7V3tHbNh7pzARNwn5ctJT2/SMsG/b+T9mhvQ+7PPhivw 8uVLNoz6lPop+QANuhwBIsrzHHmopM3UQUF3TPTZmtW+u7vTKe9A7JbLpQ3BgNqIKX9FVaz1E32v lvO12+2KPBNGoW7njB4DIoRAPGZmeNhI1c8UjDHz+RzmFfgCil1Jkv3g7OtauxwQNR6RGZaqouDS Oukst4P89XWsgkxsrOHQxIyU8oeZxX4mvqk/FvAhWRYR3d3diT4DszDGAUXYWEn1KohjAPp+1Qjd WptlmTX5YrFYr9dFUeSTfUCHV9Eo6MByuZT8S5LHBuuy2WyQPcyEAgTicgVut88BW3w4BpQcAtDK gOEAAYN6A9ZNcNaLxcKFjHtehaWgxhsMw8vlkpQujlSOS9wQqCNR7DT6vwf6OAnRA0EhbNqxP3uh JHkKH2Tyg3S49xTWQo++uU526xitdUpsnoTt+HJ4lz5M+kjA+nrmqqrKqq5DFQJmZmOeR4WnRxT5 c9wr+D/yS5OWNUUnxXYI3hPeGgiKkv08mUzEfICDsN1uUTcKFh8a3KVaJ8HKBMDBn0luAFsDLYgY DnR/NOaUFB0Rqkx7At2tcw3NhpwJv7qDndfNInrROQcmIxLnNMj8S3ky7XRiVYQqK8BtHDRMcg+s AT74c3T2NmCw7nW3oaik8Bz7pJCdXae2NwqIn/d+t9t9CUhhpH4FOxsFiJfL9Xq9rStP3PKt0021 Z3afC4UCjZcwNXsfjoO58QiZkM08uW2ZeTImK72bzXKuyoy9cXXlyVrLzhsiw8TOu6quyjIz1lW1 q2qX52VZkmfyzN7vNttqV97d3FZVVe1KV9XkOTPWMBmmSZbbwpBnw1TSjojI77tlm+Lwe/Dtyssp HB8fT6fT9XptiE5PT71zzHx6ej6bLb777ruf//znKDeKzGMoB4MHZ7PZZrM5PT1erVbe03K53G42 MvmwstaWiGhLlLEvvCuKolYuVxkTMxeNMP4ov7rRu7fDM2vsK/rvZWZixvoSEyeyLftGLyFbsUUS 2oYP/CR1ItiQoIAQG+s1FhAupzUic+8BkgrXHEOPn4EXaf+aaCKHlKD7x5mbgYXWjPIfjz6PAp1j lJnquq7ZM7Fjs6vcalfWzu+Iamt3mXXOlwG7EDH0Ge18o/pzirrvcy6YM2vZGGesM01TnRbY++18 lT+JejUcjW1UuA1k6NE7U/M9aGS9Xi+XS/gt4vqAwkBzCcysBXdt2JVYVu/9arWCk5z3HuxOxIoJ q5FyVNEHsPWr1WqSWSLabDbixS8GaE1oembJE3lrqSjyui7rusxzWxQ5jDnJnWStca5idllm4OWJ yBtmripUd2rK9FhrmR2zkZgPNmStLaY5k9vu1jajYpp775kck4NnIRlPxhvLZDwZ43yVkanqnfG5 McZkmZ0oAxkR167RceUTcp6czzvHKRMBVxGn0neQUgJ3MshfLEDERzZPYRVTq9AA12mtvb6+3mw2 CCR5WB/0KzBvOqGN7oO1Fn4b+Gm9XothAk2tVit4ooiEFA1HLCADXdLca+dmiBqEm+rZ2Zllruv6 5cUFM1tr/+Zv/ubbb79dLBbn5+er1aooitVqNZ/PRf+5WCzu7u6gIEGGnNVqJZmGvaO6rm9vb09O TjgwdgOKtPuSRnr0Lo3eOPC1+Xyogx2PJDeka5oeQ33Few+Gg3nPlKQsdcfXA509MIQfBQZ4Enik qkPWy3vP1Gi2Nf0LvOKzQoTJHzNA4Taoa1fbkD9aXiE4Jyo/ZJPCQKCLMD1LJD+SnffJzJEDQGeH JSIGqQtTVwkO8YBiUHBJmSHdOFZTbJeuavTr4J82m40wHPcCcckU5XfUARvKb1GIB5RCdMPQWGaz vXFK1BD6Rdp6JUuMG7LcUtBKpB4XmjPrZg+laajXMFOal5QJfQZE8wDSkrYBtZL3viy3zO5ueUPG 2yZK0+g5pf6tCeK9Wq3Ozs6kT9ERjaZYLkY0Q3g4BEOC/wXq8WY//+AtJKj66uoKLWAst7e3y+US qhdsR+gbxSnJhKh6HP8essLqJ25f2f9j9viQ59nLlxdZls0mRZ7nmbXMDEfaPM/Pzs6ICGF1yHor csbPfvazs7Oz//N//uvm5saECKvtduurWmnt+O5uOSsmeTGpiWtiYBLL+24F0CgmWa9UvRBrm/TW PbzBhql1JwybptIpTjvLzBabp8tZCnqOIJJTXdd1Yq5udiPxiA7/tXAMDwCtK74Xxuurn4Klcb5J eeeJHf41K2qZ2dA9w7QauK+vvVWPtPbj8Ej1jkpvDL+muy6+IgQ+YOMDTnLa41L2+bDYfFDikm5o 34W0n30tRNyGVymjsiyz1PAouFPH6A30Sr9XJ96Q8FRqy4fa6aQstzDFWNvShdR1WRQYhXQ4nhnc v92u89x6T3XtmV1dl6Ypv+DDv+ZxqExk7DrtirCVmvx1TCLuy0IuBIGnIPwPh8e83RjikN0d5Pn6 +lp+1V61w84cYkd89+7d2fk5hSJqkdqNgy9n/0Y3kOyxEtbay8tL5OxyznlD0FjIqF2o0okhwBXo 9vb2+voaiczRjjEGvu4ovSM7+6CbEgauo6D7buNQTK4oivOz87quTZhAvAWVl0UrCxYtD4BXhOCg ZlEYQZvOIYjMGJNbg4j5oiimxZO5jrZRZIfR8b6NfLoTEektqL0Toov6zoi1bX79iZd4BHQKV/di Ptp7hpxznlGY14likhKx5PkhtaQ8DwiedO18S8BgkcOED1Ga+Drsc+ZHVC0RjscrbzMiKopCMNVw tzWwqlCPbQOTCoWNpLHfQONEjWFdtyzoN/XGkxt8SIoKu3ano0kfi4bVh4seLEp9w4xAHF+im3VS afyNsblVQQ3pjDygkojGhtFufjYdiQBysjIzTBXUzOaeYRzweSYiyPGg/UilhQmVaZHBwtIRlWzl PZBsSsE1b9++RcmcukFG9Waz0bc5VfL49vb25ubm7u7u9PT06urq/Pz86upKlHjYc5GNvw9sCH4Z iezAjEpqIO8cHLgkIkZ2s+ghJffL0dER3L6QVJRAQZGQqqpMKJoDdwRJUUWNDE+NmaDpB6k5TzS3 6VjUhUhavS+Wj1iB9PrDYOTjak5ipsR3adeGX/TXYwohohHSv2l/ELUlJsoQmbBxmg+HGkx3CIzq 3jkHhgMnoEYCerb0+RhEraZ9to0hKFcyQctPkfgHPOPqvbMnBQIP5FO3kwqCf4JPvb4e0VrRcMgV hBCi2d1uh3xWB73pBTpFBTHTdPIKA6BZBHSybles1VCHClYUQk7EYu5V/MHBN+rVH7C2R09pyRMQ hdE657o1HJDan3DPcZK7UDibe8kKD347PqxWK605uC+AU765uTk+Pr6+ucEBiJLVuJDPEToMnWJW pJnNZhu1CR7o48eP6/XaEeMULZdLtHZ+fv7+/Xu4SmFLwUkCygxm/vDhQx0SzIkoPF52rcprEwAA IABJREFU1x7jD5gWDfp0SeNY+tls9vbtW6Q9JeXShQQkhppcEc45S7k47bv+JLMPJvBascH9RSLG vPHxIqnIJW05uFfY7eQ20pv7xK9H9vavFmTqNMoaSZj1SjnXCBhVVTnXbHjvPQd55JON4ABECP+R aPmgOaZ5ndl7PORJgetU37xYLPLJXg+tNznkn74UF9HE2qQKqyCBoihAp8GsgMx3xvcNDDAFtMbj MrLLK3woBEMqRULf0ZbGNULrVGnoSJxOQG0NfBaDlwxErqSYWVwX4CEg20BCO58p1QGGredaojcp lPX71H2AcyURqQhmlq3YddSxrvGq/P73v//5z3+e5/lquYzytpJSesPwgVBV7IYmFs579i0/GsBu t7u+vnbOlXVjNyEi7xwRvX/7zntPzm93azRiiepdSUSb5coQGd9gLhxjNI4Q2QdMVN9GFE+iTt2J Vg5pbZ5cv7y8vL6+fv/+PbxMpBEoYwwhXX+jDBTIbC62HstAT80b1ZIlfEBqPE4uCMG4F5Z/WpLQ yTQMvKJTp+KknErS5sEW/so0HE8J99o8mk10zjGxc66sXe2dq713zCbjvcfHZ2A7xAxKiYajUxE4 3sOjE6y1m83GBHODEAhdwz19SlKgcoju9l21QupQU74DlbEhNtZkxprSlfq2oigWi0VVVdbYPJts t9uyrLIsI96rDUjpDzrHKL1CWSgOPsCaidFD1hPSOWSRu0Rd8eHDB5TXiEcWWCidoVxyk6eG9c4W YEZZLBbL5VI0SUKpQe9kLGlv5ba0Zeo0qTwn4Ph9apTHQeUu7POwZY7ilWi5kX748OHk5OTPf/6z DZnQom3nVGZoaCnATGjNSl05UYvhA6DJNpjMB34VM1Ayun2uNgoiu1w/NLp7sOocDITQ30ihNShC t9vtapVbFTYmxx6P393d/cd//AdUNZ1Z951zRA06xj2bzYa4sNYaY5kZUdz01FR/JEQaiEc2JRxG KteOYRQe3BOtSjH9aY9/gk8BvF94ruvaOe96yul9Fnh8SsN7gfd+MtlX5RCKG3nuW2tFVoRfJ4cK 2Nq9o3MnS5udGg7sf2Bs5DqDdwgSklJIuVHXde32BHvY1U8ONQXEKD8NZzQfwMMYI1Qv3vsffvih 73GZJVGcS0iBlkWpi/hKn4no1atXP/zwA2iTCclniWgymUTOnSLq9HEhMglo/8kYDnmT9u6JBiP3 yMb6RGdMezCgUyJwMzPUbqp7o5yZAVdXV1I1PjqfotGqQ+5nvIuDG5HcWZWNJzMz53kOJ509MjLE /Um6OnsVUS99xkbOMDwnBsiPtLPb7ZbL5Ww2Axdvgq+GMeb29haBx0jKjq2JLm2327dv3/7pT39C 39brNQd3k3AMmr7jbS4UW5rktqqqbFLgt0cl30hGNJ7Z/aTE4GDjnUvZJ2MNQ4QrsQP/avQcD/Th UBdN+6cD86ZUcIyvjmpvCIFD3pP3SHEQErshGUZPztFPCp0a8k8HXgEyJGkkRkqBJG74IGnAPPJV SCksziYkyvOhMGTnoGC+capIrGT94qAeRk5nnBedYTPyzBsATcIpJEQXPwwcPRCjPu8Kr6Ja8KBv e7ZGN0dvF/4D9qZh6UJLQXgFJuHs7Ax57o0xYHo60UXqg9FJ3z+hhmPYAXMYUiXeSNyq4zsUj9yK 8NYJ8wHee+dam6MPPn78OJvNwOiRStkmiq/o/k6u1rs9W4D95HUoo9kzENKfTj5d/yQsLScOARSI 04BqFI+YEOLLic+NALxlr6+vjef5fJ5ZW1WVMWaz2eS5hbnk9PS0qipJ0E5ECO2RghGQIfR04Xh4 XxPRJLNlWW42djqdMu+PIvICPd6kkh6Ygd2V/jRyK+q7tGAhHzrbiXgLfU+KUOTvGO/X9I2trfLX wnOMgs4z8oSNB2q3xx7Iv/d5VRxPru7q9H4gZXfAlp5MJih3ore0KOd9kltIOBXdICXelGJfiMZV FAWSjMHdHi5lQFlwjEOft9stsNlsNkOY/ZiDL7GQzBzSPROF0A+425NKwcxKIa0B38U7UI/rYNQh bgC3JNEAmp8gRbn2j5n9W6C6hhppX1k+z8W20gmSMF4MMemO+gwmFa0364RIWTKSaxGJWX8O6DjD 8hMRbAHps0xuTK3tzWazWq0g04M3p5D0IdXxSHRJH3VJuyGfkGWBfUuK5dDDPXcS/EWMY0PkiYmZ QuLOarcj7w0ROW88ZyrjSAQZmdpzRoaIjGf8s0zxP2OWN7fzYlpPyg8fPkyn02lRGGNQ9tZ7W1XV arVi5tPT0+VyCRXler3+93//9z/84Q9YFGhBqK2YcXXNykUU/rbL5XI+K6qqyo3NssxALpROG5mx /RSZBnG3NGqHJ/w+99yL4UhpPLXtGo/pGylOVHZdxLKMaeGZdek/FtDYue+GkXtMmkL02Xq3dc6V jjx7hr8oCECzfZ/VzuWD/8TwWO7l7YSmJpOJUSV+qM1Ja6MJOIB0H6ZSqxhBoju7Rbt2MAszM5nJ ZDqdztfr7Waz22ze4Ya7u1XfKFarzYBqVaIf0p/KXTXJC2+83GBDGW3x7hygcTJ2YYMwk8fHx32d AYDJkCGDY+g0qbSIS9cSe+UHMxBKIukhcLPYULQ4BO4nZjjGb6lOSP1jh+8ZABmYSG99fZMD04nc AZgOrSVLgZmRBGygh4jqlFKKIJwDSax1T0ZSAk8thlSIkwRuyFQ4lZUBdBiqWM3Sok2tPOwcnbRM PROuMab3frvdwoFoWhREVJalcy7Pm8SmV1dXzjmUZXr//n1d10iKmobSRH1oXLIz65yricuyRPkx V1ZHR0e5jW1YB+a9ByI2f/z9D4Z7MQEPex147Z98Mj41cJflu/dmdY+cZfnrPY2TRD4haAp08OaR A9e3dabBEH0wB99PqX5O7ePZ2VU6JIWKwkNMuuLzUUwKcYa4urpar9fwJ2Nm2IJFdR01OTBS/EWz QnettcfHx0VR5Nm+EB1GSgHXHTytYNcQM3J7ewumCixLH2hxl7uKxUcTlWj69wEBeZ5Htp6ohrBm EHX1Lnmd7Hz5PDb7whjQvF5nswMcdEQDrEpWL4uaqsuE4mpmWfdHOyKBC2Pm1aqDmR0G6TkUJPKW pm+jp7CT0Mb3BKZBsxdybDQX0uIJkHMyPKuBlCtrH4k1KsaPmXWBOoC2RG63W7H4oidB5UPOOfDj qL54e3tLoQICHrc9ZQjCtOyz1ElP6rqmYjqfz9kAH7UmEx/V9OFPTOAtdSMvE6B3PR7KATzmYMmu /kTeFZ+Zyv04IWLHRz1CREQS6M7MZV3Vvomcd95475ly/6UuSCT1PQDgXB/Fu+oGwQog40Vfzm9R A4BAgq4fpNZanBYCP5vNZrOZFPLcbrfff/898KrYO0jRkYCgOhiOyIE9y7L5fF4UBUgvNLvr9fri xanoJEDFmfnq6kqb0fvGAqQtTBs6A4ZjYMdIWSVE/aSzMfA6GTVmI1138GSx2qmr7Dy1FVTozBNr OKS7RlX4peBX2HmzrhMoqF//FYNQ9AqhphEjIk7L+LUoCjiLQXHnvb+7u0ubiq7ob6TMUXVdg9zq +4cZjk6PgZhd0L+G21sKjDafkTIc3rF+1iuQFjrsdm3hW9xfxOtKrkeMcGRDhdOotID9Ch0gjCP6 jWOkcLyZE6D7MBytBvtfNNCNMVLIk4Pe1SPP4/hO4lSa0TkkfgINclhGTl0w+DW7Fxq7kKQn1FL5 zJ4bQzAwzDHawb4bjPIGlcmESSUtUyWaD3iAWQV9ncSV6XQKvIQXTSYTFFvAFWAqpG/ebrd4e39m y8Nmffix4RUQbjebzXK5ZF8VRXF0dKTlTIQcij9K9yu9x52LxUK0NT547Omn0nnW4nqqsTYK9s+q kA7v/cnJCQplRDEp2qtj34Hgm6HXQqxI+s6HazgizkDepE+jflnUS1E8yJXIgBcxKH39FHYhsmFT Fxa21u52u5ubG90s9EhIyOO53kvCjSUV3ZjIqdjtdlH6jT6GIxKdRxIScRplsTvuaW3MbcQciWrV OQd6H3wtWXcgfmm7bya4dMn+lt0jV9JGMJOoQX98fIx7gGHTm9PVmUwmzlXU3kLRAInIJTM3htg+ bJ9zu9DU5wJ0ANWi9UVmHu+aLUdVeI6f7C8jIdqQIy1x1GY4XJO8v66qqvLOAflwl4PzjwQ6Ranx j4tkKFeAQNLoP3xYLpcoYCnxKRC1U8cA6RiiS3CEkcVAnCglohCMIPBqpIkRzUqbxWxE0E5GBycL agDIaZITQYMLGb04iWFsRg1kGxiyaMsNpysd/jWacG2CaV4d6CnUTkDpiAwwqrZau7fdGg7NJBBR VVWfLQ+H2F/gWERqIiQ2fQCEQArTl27f6DMwLLjOyWQq7YwUJWG+EoYDqrPQm6FO6q9RXIbmOvfX TUxl8ZRmPvYcRhS5QHsuFYo1H8LDBOV19tPvw1Ob90qaMjyrdYwps0jN3iXvfVmWyFIMi+NIhsM0 hs8JBhtx5RBEMoPzH08vK/lDO43qxlOmcDwb8VBm5QEPNTCw/2WZpDCeKPOofbwHuv0Tq3Ff4Ecr hEBN5Uiy/4JYDb1VOBA5uqclpW+KOmmz0FGNdqJ7sMPlOhAaiirgive+M6WVQCSdHx0dWTPR7xLT Q+dhiWhwgA6NOwUMBsJc17WE7wJsO3sHsonI5JgkFIUVvfAhKzmPTovs9wETJv2gp30/RtMiScAq cCHA0PCTlLDQwIeEPhsqlX7OxF8S3Rv5Cg1DbD1ql/ahHmQKKgh+c7vdzudHD8O5PqSQwy7v023k ppVAfi+dj8id4MPCC/9LbdZKsxoN4ko6ycx1Ve2NeSD5SXw/K6dUQ01iU2x/9p64iXlxde2yTLIQ 4F9mu6tZip5QlJZ6yTpXKssyQz7LMmaX57klNsZYYuFKvfebzWY6wamLt4ozTNRUlO00qTCz7U+Z MIxV/3/23vRJkty4E3VHHHlUVnV1d/Vcb0iOxNUa7e3bFd/++/tdX2QrW1GmD0+UidSKx8xwpruO rDwiAvD34Rfw9ERERl5VNU3uuI31REUiAAQCcPzg5/k7zVG0qy02UmhlFi5G+MFA+cNWEG9bR7kd jvU/UkIiqWP53pkTy7ULDRLHpvZeSIQDdKAfC+rYipM0wB6Tt7ajsYu5dc0pCF6UfYEllF0gRpGt 8+HhwUrKlQd2Ty9JD0WktRX1AVumnr5kt9x3B2EOdO+DV1eqd1AhsRgPSpDGSwUcsetR2xBjSwdR jUYf2dWzBNbYcM9agDpbZAv4TIQFimwBAvLLy0uViUr097SNskvVF/qyyWnzaQCHBcWHkIV10JyJ yHAgNiV9EzsRkwFN2kKDcKzQGsqyfKQlHQZ09DNjEoSYGCXxm1Cq6io5NFCcXgo+um/RvqBBmtaQ Qkta8EFE3Z1U5zcYHFxIqG9R7VpmTdMgGg9tG3C43VH2MELKDlRAYs8oXXQIyvOcc9wMRISEzizB IFHWnAu9re+l7ibRXeSHP/ustOuj7DpUbf4kon3z2Ub9+xFnHEt2bA9XrOizcfsB2pCepfviZOeA Ljd4MO4qbx+RbQVTAsh6CbwUo1GMSgXNFI8WlksroQzyPlrM0bv7aoys7k2Kp223neztqE85QKgT AUgs6+7yPYm+Eb0TCX8nRqwKOAaUJl1FgXMO/iYDqViSjum1QocBm1PnXGZkTlqgzVkRhTe4+MEk HIkeKBnBQ/AmxyAkXRsWOyIKYLMsgxeri/lRtfBwc12RYAgBipU6bECS2zdjLewYKBZ4IxBLVDB6 sYVacKbf5l1iiHYbjuwSgVqIkyAkiA3FSERpgyDbx6GIgXzFQviEEAynFWOY+2We5XmescFYTJ6k 9k2WZdl5YRh71vYgjnlhCUdCe5vusviBjVBrO+qNhgr/8DvmD0YHbVHbe3Nc1x/1qB219fYijGTC 2D/BiNTtAosr4YdgJd57uBNa5rxarWwUigPFEsrtQwjISIH7t7e3i8UC10+CN5hViOyw88LATEUs WhL9cX1BzJR02waThOm9c246nW4pX6JCPPah3eDtlmr1UPf390h73nv20+0pAQqKjXiH7VdXTGU/ a4j5Lg4CHM/KcPExVMczUPLA6bVL4qSIb0Dnd+CpRRWxVqUy8JzduffWDwlHvyXRwdK/BHBYsHLI s7jwMUWLleGv12sVmUDQl4iXMCnrukaSPBhk9bxmCAid28alae0wgnOuVaa0Eo7Ns3CUL/NRp0K8 o14elLzNvmx3J94rCNk7kiezMJVYDs+WHoFHfOrYw/ch1M8Efoit81h2dEj558aUuhi994HELuCP wZIDQTZxPWw/tOuIYv8cmHsqRCnL8u7ubjQZY198eHhgZijZZVsSrDsfbWtPxGi4hvXjyvCtWP3V q1er1ao3QdU5dDin1SnBMS3t1q8wLI0FIG/GvtO7f6loAVv7119/TVG24WIeFshdbm9vAdqsfyiZ 766sHgHRoXnQMKNdnXie51leJv2HkExT0lDMw5Kr05EeVQ8Z1vMpgb3qV0km19+u8rQ7CGnvzGsN Cb2vlstMKBPKAlEgXAchltYUMbPxGloTxeDYlTln0mTSuFBn4qhZuzx3YWtKSafFzZ+bImJ1u72E NeQo9Pl2iuAnWFdstYgsDA6tS6AQKAvt2x0FONjYEwFw6BaoxlAA3YALmJebTsaMQURuvVzgDgu1 /xExUcHu+7v7erUeX5Yuc9Pp1I5YOyeRzQ7BT4kD5ZXPPGWjgvXg6KCCkU3TFnBswcG9rx1rGJZ2 HFbNWaRs1C5JF9NNaZluZzD19a5eBDng/QcEdGz+/ZHOI8UagdtvEiiEzfd5aWPeOKOcNr1rkh9u 1aHl7Vm59yklexy3YvmEVDW812gvub/RFgWvWzgq7MYIOZmOYg9uO6J5ut9JICKhEEKDvQ77JLV3 chF7ON/MIOc2vMLFoEciMplMYAn34cMHEXnz5s319TVvZ7EQkVA3zboiHzJi51xRFKtq7SUIU1bk 5JgzpyJmYcrzHNb+llmJCJAKPm6bAThzgakVNCmWdM5p/PYXI2h6Eh8KFTRpZ7oGLxDNDRhwgJiY iHysEDBwWJrSSwkGVKzWpQETxTPpQDHJ+QQU+Pj4eHl5qTcRCgZjPpvN3rx5Mx6PATv02z08PABw rFar9WqF2dVVe93f3+MTJ9rBEILWZhMB4N+mabx/iSxTXYh2rJCj98fDV5Y9vVl5lTLxBHNIXw6d H+lHOo0OgR0DxkY4WIOHgNnCTDJ5RM8tese6xapsw67BruHFsHjDFnbOafoK7JEwH9ybP/xMSji2 5S3YbbtCGo4wX4zFKKJicMevx3IDtAWmYfknM08mk7u7u++//x5vfXl5WRRFIoFW80SVjlgJkzPY gmK2+rIsSbYYMnZzxRwoBsl9mlxnV9q65yA9RmMa4V87vRJNlQ18pp9HZ2cw5vpJK3oLNs/4GBD4 76Xh2Ww/lT1PW88Ru8ccBBcgBpBWoJG0BznB3gOr+pKcTLCNLYpitVqpqLMsS+89Qt0hZt+nn36q ij0sCbt64aLSzUMbQlgsFpC5YcpB6FeWJYCIygbt0rJRxc54sz2UjPnWJ+5EVXluUlYi0e4M4flt f/S0MNClvUDno7IffeEDz490CB24r1MM4UBxTnqTORK6A9VrYDcSoxxJ4nAkOyvsJTXrCtzvD3+F LMsk9ORwefK1bJm8RFcUWwB9AI/tfQWYzNuQiYjtUdf1YrGYzWYDbAqFi6JIdnMM1yrSV1991Umc Tgj0zjHexmg0ovmD2n4mraieIc96tl2Kn7itsCxIjUZFpKqq0WjUVSY9E0nUNIfoiiPRAWR4Dh0i QNtFQHNlWQZPySQ4Te299cgBT5+vLzy2kyevJYup9dMQEaQaP/vZz372s5+Nx+OLiwt1L4Ju5eHh Qb8F5rd6EeOE4Uy8eZUSXV1doXLkuNedVQuLtPoSeNCc9lKnjcOLtTVMKn+2amzaNjdRQtyhj6fz P9KfLwEWqGqPovh5Fy60iKFXP66EM3TiOa8knSBJk8kE/ESTemAT7Z5AunoZQBkJGyhwdXW1Wq2Q bHLfGJxFuw6Zan1PXUtb2tqPwIezLENEIomxGZNWtC3nnIb6oJg5FvycmZfL5Xg8tj7GNsFsMnTd r5zoqvI8171vFy7Jsgy39hiNDqjfhh/cS/j8NsYX1Gm9UfetJIdjrLDEjENEhic3xRykeZ6v6q0p ji90gpJlmHRbSO8MbmMDkOQEmfnJa0mVGsz8+Pjooi/ZbDZ79+7d559/Xpblq1evFDVqQ/Bbg+gC BtUQseZ5rqIOVIXov4vFoizL6+vrPM+vrq6gZIENBxlDbmZGhrr5fIXHi6Jw2bMfhXUBH/9geuc0 UJvUwCZuTcqkjCzEYjX+mGDTj/RnR9xJSu4GPfsggQgxQCcCF2FCJnlEVUs+HBxTaTwe39/fe+/X 6/Vo1DUe3+qhVXnjiOKcI2pd/SkekA5p90xCP7Ft2TVrhSu9Egs9P0BDUZblw8NDVVVlWQ6ogVRC rHcWi4X6tijImM/nUIhD0uyi+2FSW1ftRRGgJBltBqAJx8iLG/NdYEZFlM8t1cQuYl/PHtdUUa28 NQHUQNx2WDXkHPQyvY167+fzeZ7nRP2uE0dRR9/RKbD3kSdp9/inkhqSb50gayKaz+fe+9Fo9Pr1 azK2PrC30G9Eca6XZTmbzeq6ZgmQ/qGkiARp/WYx75Gt++3bt6PR6ObmZjabIXGAVqVd8t6zIDhY uwKZWXyPdYjKQg43/9e512uooVLBHzaNO/qmKz+RNitvQldVTbnrdNWp/Nn6/SP9JdLApBIRTcGK 8NiqW9ECYpIGJOvOqjw0FBDuYKOFSMPK85Jlq1Z6Kgp1MY4FSg7sEU9IVsCQDBfu7D3iYqcPIVRV dXV1dXNz88c//vH+/h4h0WzJ5DDTPSAhCxgRTSYTnNbgeDwej5VLJGHWyETo1gO/sso29CUMUPrY h4ZCttSP7zTwiwUB9t12D9FBNDxZyXjxIguOarIVgmguU90DMAUxF9U+w84qfLYPHz7MZrOH+0eK n3O93h9wbONkEf+jMBQOgrEZ7K23j9TXoGuq0XsTtHf17B3zXtKwXd77siy//PJLjDAQKtaMGlso 2sAiubq6GhU59r/7+3sgCR9PPzBd9jHVy+vXryeTybt372azmbqrwQtLc8HoprrBo88v4aBt/H04 2ksK6gTeW0lvW125a/dspGhDhaLtnSN7/oPTQFd/NO94AZJtf6hd4r2BM4yPaSBBYM62sHTSMiip 6NqZzE3YX3UPS57t7lAgbGTqfCAizK3ko5uD82kpWZUJtlCmOjCfQ3QG1PABs9nMe//NN9+o4Ysd B2URvWOrgAM7JkdfXFwws4YkSfpAg4EkesfQIkjZxDcj51xakZ5WITCww/G0S73LUyxGUw20jk63 hi5fVplHIlDSs7IqwJ7wRfrf5WkbOJUOPN3urQTfomkaLHtUW9c1tCTSSSGmklLNpIy5bpkXRFww yLi6uvrFL34B7/C//du//c1vfvOHP/yBdpgPExGEtHVdO8r0HVFWIjYhOgLx7Z3bVs5xaKWnkp3Y hzRn579mjpZoxsGIRvQMkTl+pL9s0kV37Jy3ey1Hs9CkgEQ1ZfcQ3GUmKgt3MVxTt85uz21gb+wj 6/XacaFCjpdZFPaMdDhhWDDw1qjCe//73/9eE5B1N0GMOQxL7dhCVh1CGI1GzrjLirFptaMBIRBE 0VVVgZOTUbXTDrTRJSurbqUiLobieBmL0V5KBGvWJ8eS3e3sUyqMGVYuDiDrAVJT1h/wgDVwniDS 8EFbAnaK+Ppk+aGdlERUVdVyuQyRcEqA7bSW16XlnGNp5aJJuGLEGF0sFhLDn89ms88++2y1Wv3t 3/7tarX67rvvcufqutYQQE3TQKVCRuNW5k8zXe2evbfMwXVuroenjQrwjupV91f94qjQxaywfGRe 2Y+cDsRhtjzt+wRdYdKT0LFd/Xgo4cbU8RnsCth6/ww7AlWRMTlK7utctQ/GDXgDqfcOrH1cQQbF Q+xA+PbzyXJdiTJ7K5PYdZTaCJY6daJC7/3Dw4PiLS1v42mJCMIZ2CFCVjl96xDz3g3sDhhzGORt TOuIqAM1LCSy1OU5OXxkd+3ruz7qM60iZ2KhWMu47iS2Px3eGYwgIuZ+zLRXMjEMOHTjOaSqAzsD SPHw8PD73/8ePldI6kNEo9EITvaa6xkPOueKLK+qCjxCMYcGeQsxvDGO4xcXF3/zN3/zz//8z+/e vftv/+2//du//uv333+vgAM2HB8+fJgWvFqtrq6u0GjSVT7JhoMOE3LQIOxIatCCVjpNOyxFeknV hYf7m0jUM7qYuNI55+KSeY4j3Q+yoR7yFp3PccSLn/Ps1oPYe/j0Gl6AkvmJxQ7VPu5j+iU7Je0e luS03WVBA0zJgmZ7H7xlMpkM9H8vVVWVuZJjWtfEHOoJSW0wdeWKCLiWPXSpr83e2qyl2nw+75ZR /QsYLCTK1mxW4QURafxQ2hY/oFe23aZpOHM4W15fXw/LI0InVjozF0Uxn8+dc+VkPBqN8q6HIcfI TgcMxRNTnufj8dim+wLZzmDrsu7aw5gjhJDFgPY4Gc/nc5IUoDHttwd8GZ3faSVtoMimY0h4Zscs B4FiZT6fz2YzNThCYjyI5larlX6Ouq4nk8lisVDNYtM0GmoGlhxYlt98883Pf/7zP/3pT9fX12/f vgW+6ZqvhxCQFEnva/dUpXLOy+4diuFf7TxE2V7t8rHtWuPZvT1UezrwFxHJjLTjR1/Z0+jEQesI n+Sjyg+7g7rSi65GoHdAujex2O0qVrn1LnaKFKnO+MOT8StRM0aOkbYPEVSoSn1U5tqx58PKIoQ4 lna5ybZw/UDHHJA+GEwOmu0W25u6xlUnAiCixcCKl8slM89ms+QQ0ivtUCmImtcPdT8xAAAgAElE QVSk5WUnYEg+0Ckypef7TkmE7N7mdK8CQrT6FOosDDXpUAUYES0Wi/FoStFwRqd1Z7VsYfkfVt9k ae+296w7SghhuVzO5/Plcum9v7i4oCjqVEix4RHBPz4+4iZwd1WvV6uVxFTLEH58++2333777a9+ 9atf/vKX33zzzXw+XywW0MWo9kSi0ah2g54UAu4VYPTSmWuhV7LYLXYU4JBoOk1EbVDhyC/UvOmp ZsjLizdsz5+pdemoYP6CIVoXECcM5Jx319lob6qaD3+q9kTvdMtT3J7hXlGWJcJSHQ7fmblpGih/ VafwAuF8bNwHiWYop1XlIgEqdYVGYMLwSWbjFmQ9+yga3lZVhSQVkIKoBFQZBaoNIWTZDpCxr7e2 fNM0ENHkKua1pVXi/fJbbJIeRinRIKJvVv4zMPNUJIVNbrlcFvkoz/MQtjIId2roN5h1NvEA+tNp kU9YpL1oR7buIMZob+XPyhETBgTkvlgs4NRKferSVqEoYb1e13X98PBwd3cH6QiikWLk8bk/fPjw P//n//z+++8fHh7u7++rqlosFvf39xS/u1o8NU2zfs7YdMPSst7y3cfP2Qj3Wnvs7Q+4BlAFYhs7 kRACNCxWmXVyJz8SOvZjHVXzc1T7Z0HYI8UYHBw7yImAJBlMPSVrmClkaEr04za7ln0W26rmEjvc U73d+6XNhgGx61HvdRTpwdhaodkXHJ5j0aLAB+MDocEgutKRRAiBqBsuBjFSVQuZ6M9tZIFtd2V0 0p7rChPq7fDXt4ASrov4M+/l3cOnvV3r/EnWP3hit2k7sTCCXSmfFUJYl6qMtiQcSHbKMaxCKyM5 oGOnv9VfEAFtqLTw4eFBf+rOJZYAJcvt7S3kInWzhie9HlCwfn7zm98w83/8x39QjE9arVYAKxp/ t01oFM2+nolO22wSPvIkmOPYSkInl3QLLLxX8IG1k+QQoD/bOBwvgDn+T1v4ujN1hRNKu8aki7/t iTkRyCs6x+REXg81a7DbKh5E2MA8z0ejEVKPHgvuddfUk/3hz55GdqH1esbuJVWC6PlfjUNtMR1J /KtOJYlXIF78w4cPFKVZNu+EYk0ynymJ7nU4WTGJ975AGKGiKKwRn/aenlRe/bQkfV5G1g8C/ced 0WjEniaTycPDAwT7EumoRhNNIW/LHnrpODnHMRKObgwQ3t2R849r4Ai4TlyLq6parVa9+kgREd/U dQ2pxnw+f3x8bHyFGBsc4yVLTND861//Glwmz/PFYjEuy/F4vFgs8K3rus6YmNlxu+o45ohq7Vf8 EQC8OyZn7itPuPOdXI/aWesqQFUIJohht1hE+a+I8KmGjX/x+/HzYZqPhBKsjLNEMJmMEhqYJ8lP er7HnxAwW/2gbpDW2U2hBu4rb0GETUSkyLIMChGISGU7FvCBZ/EnzBO7i3A22wU4km3I4idN3rZe r3FUUIaJwKDJUKscJcuy2Ww2mUys8T7+HY/H+LIa3aCua8Rj7HbJYsSuT0qvRtv+acU5VlSW73pg mHrn3Me2LCXqzFjaeK4hBBXOi8hHEy/jeelJAAcuIJZfrVbAxbpd1XVtbZQgI53P5021xphjittY /RQnjAbdU84CQLNer3VhULsA2mO6RF+Mlu/4JoTgsuz84PRnjhUbiyKRp7fwOLB1lf+16lvmEAJU thJzY0rUZ1EbgOigoGQ/0l8S2Qmmq0x2O9LbuTEg/9YLVAWJMrACftLtSu0zgIl7E2pqhU3TjEYj tUjQzazrZTkwh62U5SgdwWnUteHQaz1o6bD0rncNOgJMhiPWLoNT/FQUxWw2e//+PW2/I9CeiAC6 kXGOxU8J/1S5g00GbmnA6CKJhaqPP6Uj8lGs6jRefNRpQ0VPGW9y7CK0eYz6MlwVPlXq53NCt/8C CBMUFkl3d3dQi0D8gNQGFCc31FXr9dL71vNbVTCJGF9d6mEJNdC66ilCCECJWCSYDw7C1SDM3FS1 yClusedDjaOE8ANllJP2/rprhdtzKtgT0KGIBGPVq3JsHXzCh3DqRnGE8O9HdHIUfbTcQ8GBog1d qhxdnCKMTh1YlLr7typeJRoH2AQaFJWAe2eRiu54O7ssbavgdWlwjLoBRy0FGRwDcuu56JTBOpL0 VNb7095Dfl3XSKqqYnubdL7bEPABDDXcdhiM8XisIedVTw3rUdoBv9yRwXt6Z7h2mI4CHIds9jpH D6/22A4c3oS6BVJUiIgIsqLjfpYV1uZD9kXb/Wj5xYsRjCqAOd6/fz8ejz98+LAj2WNq1dy7SChq vrr3uws0ROcLFfThqyFfw3lvdi7p5HzaSdIVZg7YrySbwSY6ULxWmzsFHBKl6Fm2+UDDp9sfQcax ZEeMmfkji77WPXlb0KmwnoxPJvUu2L47wSQhUniR1OA6jrIWGVMU2umFImZmRo4LFQDgcc3A0ovd rWTlrIE7gPRlje6SbQ9DtM+lbTtFJU2TxpE0DLddp0gcAQAB44FkFV9dXc1mM41BNZ/PETFdC0D/ 1R0r2w3aFhHZ3VN5cpd72E/TBij9C2Aiqp/WO2oOYyWEEjjPSu+FaGOGQ0TEgUjIMgNJsWdZlsOn T6VTvFTQ5j62vvtLac+FKMR/g4gX8bw/18oQsRBLqFZLmG0S0d2H9/9WV69fv0YEfoykiyDPOUcU MglC4ijgPwpNaCoKwXUS04QQeB/Sd85lvMnY4qJ7N5ucamqaALRiP1Kix+ld27uUIHzg6gCLJOJn 1tXtmn4BDC5OBWEWInbORUdZsLnEpFSYOHqGoUBiqU6GUVrQ/5HTy3RymBW0O2sLnrkoyrIM6/Wa Pr6Qr9KqmNv/QhDnGBMqecdexaUdbdhUQbyBKloLM0fWCTOE4IiZ2BFTEDvHKIousJztlBv2ZQ0m PmlXMRRCIAp57pomQJ9A9OzJCkQY/xkHR4c/Q6AQsG2jD85wjjQ1B1QeEhUxvfu6locAQ+n6+vrq 6mo6nU6n08fHx6+//trFoAPOpGHPsmy1XCvOUxhhg4ZpE/iErUkpEzt2zjVRAk1EXsNecyacBZEg 8hLJeZ+DunIOMTm9dDtRSKFBzbts6ECpEbSMclKm8qPoI+Tmeg7Wvt3e3mZZhjyQzIyAKBLtwrDt 8nbC0t7xH5AqWWq/o2xKKtqguDCY0pTCSQ1kzlLDeC6t5LAv8rSc65xpkGCCYe1ME7xzLnArCARH gzqGti37Dq/5zP4fRac1dLIs6pyvjKOec+4jBBxdgtWUPY4qSKXOsG/9uf1BtDy7TYpX3IHBAUVw 4GLYJDwI3bdlGiFmmXYx/Je24mJiVauv6d2VteQ5g3MU9eKDo0htrSge6qjvEygWhHsEbStKsIU9 PDx8++23Nzc3uKkjT2ZRdIGa3SV3YZ3ufTtV2vjoEAMM8N+PSo9gpz7t5jVqMYcyjl1d174RCWlU tcPnAcbUJqdNEt6cLNU4lmQ3ixX2xESykXBkEkRCdm6cDlkvHzUKPjPP729HmYP3/MXFRSbBBaA9 oiAtywnCQqHxjhiSjIydD/6EgbJTVJiKUWlFfNPptKqq9lxV1QOmo5qScHiXSuY8H7AKPoZlIrzJ J6z/4cCBn8ixBGmvd/cXamDrna8u+wd14+NDzCB0K4n/iA+nwsunplRAnWTE/AhJtlwqJO8Lxjjw IEV8rsACMMV7n2XOAg5VQbbM3AcwCgqtfLLMC183FBBP0IsPFKTMiyZ43iYyFh6qF7ANJV197kNj QsF4Gp/QAYCkuq5VP9XL4iD5wDVSpmMorC6maZrf/va3yN2t+AxcUbtq9SNk4qPrdtmdBn3Twgm5 uqlDCMRU+ybPHUGl0rvp/lmsiuFf9b0yaZPw2vO0iJyQOVaH5WVsjk7g3ckjTwXkMVY4kYjI+/fv Q+Ovrq7KspxOp7rsdXKrbhJspTdfT7e3u6hVJAuJiCOHyGCz2Uzd8cuyhFssEtjuqseergaa09ex j9k756+OA+UEJ9AwFj+crNapqx1PCpvNZkvff2YfzqT0CEhExkkvKbNrc3pacn0JKT82Mt9OkngV unyScUtIovGpLYZpE7bjSdhK1F5Eto2Q7Hl9PB7PF49WCoKnNLPSAMdz22G2X0w52LWoOJB0I1Oj kyzLbF4VS7YJZkbAAi2sA1gUxWeffQbdE9CGVTeLMXkkIuecl9CrUqFtzJRwSCuUQqP47m0tT8tM f1jqvrnEDLzYMsfj8ePjkjq4RMvrFe0OiPTcPtzJvqh/7pq47cFB9WcmNteTACPUA5iFpm5vbyeT Sa/JZyLqtNcqFgrRJB4/hQMMthNyzr1+/do5d3Fx4ZzL2S0Wi2q17nWug3hWD0DdSZ4MrA0KR+Zb 2O1cK3mxJTM8RN3NILk/VKf0eMQlYgAyJmzdCq3AD5q1HxZz9IyD+cneH954nuTj2vpbw2ch31Nx INKgOj9AGKQOjEgBRyLWpb55JZIan0qMW2qh6t6BVVyijMIiBjeYRWWX/N9FGm76aUnHwZsoySqS ITMDuytOewsV0q63Tl4TUdRWq5Wm1VRsAZ8XrVZhh4s5662EA/IJRTzaivfeGTFSwg9DCDhseu91 oyyKjNRLRT4y1cmZlKwHidG4JabwsL9amYfeZ95j+Xc+J911MrCfkLa/qG7SYVuvsinMREQ+Yqwd /iOn9xZTsygK7/2q8UizZJeKchbjeyxw07ITzH4OMhrKrU8TL3pnJs46f/M3f5PnebVcTCaTZl0h LeHed4FkMtEk2msXU53pb8MVvtjaOSrkABlgR7uFE+0MibVyx8lwmHRi6HlU64GJz1Er5cxlpYPT RRsfDznnMnZenmZhPhMp4EhGsoNI+gEHZp03maqYORyzSjQZBQ36RNib1Nl3E6V596mXoWSL4R1p uewurI8ovFCUcKABSiK9oBjU/Obm5vb2FklSEUVNK3TOwaRGYY1zrvZtgCUlcBW8gM1km3wmS977 LcBBPwTmOJYjnMy5JLAPbWipxWIBywMdvt4Hmbn1WInnjKiGjHZPXb3VSfytexgdJvTZy8Y/betx JiIKRIgI3g1IdyYpenPO5S5brVbAyxqTWKepvXbReRVqSDIJr3UvtFZRrQXTjj445xaLRZkXzDyb zabTKfmrr7/++n65Gt7e3KB1cHfyb6raZrg/lDiwK5gRI6YmoqaV2KcParHeFAztmTU71EjFMpQQ PQjcdm5PEKIY09kw4nBKYHr66/ZP+kbwELamAMmDT/iV8RGLIvPV1lRk4h6W8sORAo5eDd0hH9Se Q3Ahh+0yAK9gGgnWwUwW44KurYjxmGVmqIBlO7fR1sH9+WkAk9mbqozuAjt9R9kOrt0rD7aPTyYT KwjRLCpE9Pbt208//ZSIkJJXjL7bb+e2FaMTFxOgJc9z7322rSzT/sR+9n/lHuHMyyOPY6mXm3TL 6DXHBGAIs63TsbeqXe8umgELwS65mzekvVAJ2OE9BKlbtiUyKlVs2CJS+y0ksZklTCLi4/x4DrSh FyICwAFzCt17wCzUPk4d4ZBUxVZo978uC9h1CoH9FEQmeZ6/efPm/sP7i4uLu/cfNouEiDpT3oa6 0jfa9aZkWUCH2/YqZX4o0jkT2uvNOyri1E8GpmM/JUoqM+s1Mkgwlj6loiAx4U2V3D6foKeio+oX A4+evPJDaNcB9y+P7CDXdZ2VRfJr7zgEk8e1+5mGP5yylF0qFaVhjcyTEHS4Rz3Si1F69c7d5abk nJtMJi6mTNNzNdJtvnv3LoRQVRW49Hg8Vm6gyENXbogR7mGTQPuWw4af+K2zzcbmRnkr/TlADaWE Xfb+qqSAw3tP5BCDG8X0zD3Qko5+m9SjFQ+mS8URo+SBvEw62xjFnUC7Z/+kuH+EEIJsXsFOO5Vw vIBBK8dMg1VVYftXuy2K6zmxdNklzEwmXnte7yhfuZXr0MXFBcqAZRRFoeFAhvvcxRy2D/bVtu4c BklfnhIRXbIoNkAkYoLhcK6Hk9Vc9IqylSwieZKmh+mQVlTw24XsT/5lcQhReR2Oi85tNYTIDNsW YSH+8mdP9sgEGbNyCRVC6LzVoxoI52bF912YqH+q95yeyHGqHI/HGhmMOp6Gzw37VGym3PiEVQCd BSKF40RaluUuxGz3AiSMpWjAcX9/jwscDve2q9KgdV1RXC/H9j9ReNGuSKNncoeXAS52h+7e3yoQ yAILnLYP1OQpP0USHWb2WELbyeudc8w9UuVDXqH7Rt2303WbvLJdsUQExbB/KQm2Wj5bLK+jil9V vTIw2v0Swu0/vfcu+hm0BUSyLHt8fHx8eFgul8vlUjOw90o4yAjPQ7SV7v1Ye7efLjo5hw5fL9qu hURdcUWylWqam+4j3Zp1aXQ/yiHrJcX6ffvEc9POc0gc6l2oVy9Uyt1bzN4fWOy9j+umSNRmYdQN koRO1MueQbI7c8qTkG6BzrlgbD+10RCDR9mR7NV3AzErFtG0Ss65jaY7WmLCPNx7D8DBxgWXmZGT hbZW+tOPvD1u2fWlN51ze5PWaqIZvB1ebb1e9/qq2HVdlmWI8TOgXs/zHIINVNhtyIZlI8M6IEuW 6H8gRpnVvtpuLJIs/7TVhJM+E/B/Kkq4JK4Txuq9Xy5XYTt6jN25exmiPcNpyfl8zsyuPW1vgs+0 5gvuoHTJSYHudzoNr7TyLt6MAD0phNcdGn/at2iaZr1eq/UoVCr2qKHSuS4rt0Aqea/uKAjhDLSx jvbePzw8PD48PDw8fPjwATpI59r8sd0vgRWr3fh4gPWuniTBhq2Sde+zCezoLbm5Y94DnNrmodhL wzvWyyhWEup2Cc13wRYZHmqXcC+AO5xEhKPbGAs5IZIWgZVlSYtle5/JEzkowoSJKDCJiPCG7x/T 7NFLvndAziGtrStn1bb0IKcyfBTQ+zZtuqWukCOY6KLUiVyuHlXY3fFTURSaQvkp3rifLLYA+MB7 2c4nu09XBYNpiRwoA+INvalbITKuqfUGJCWaGZ46+c+TetCuXtv4MWzi01MEHDb8CWqy21AIwbmc VKUifWrpk/fC5wYo3W54k2s0MWqTqH+CSoWNnZFvEwsNGQw63lKUYJRCCI429eB8f+DgYOqfyct6 u0pPF3VjmKJEpz0pWlSqBhxaEhcauTK0WWwyy4zg0mJr6yX9Kc9zxEJ+eHiYz+e+Wt/d3WEOh92A Q/tpgcIhzXXrOWGGn7wojkUYIil6s2Rv2qpslRZkg5tLdD4awB9a5wvLM7rdSP7d/LRdxs6Bow5X h69Z7jOdw3kaGliKUknzU+uK/9Kyjm2K79jPprpY1hJv54XeTJvIAWwk6B1JBjYeLtYaUeHI3jmW IBgXiU0uITWDcK3n7dMPeXdLBenebNfULpGYHY2yLN+8ebNYLIA8Bpq2YiTaRma9D6rHu4ox2u5l m1gGuka6Eo6kNrWSBMpR2NcTRW5g9z2cae5ak8kcOqGGXQREbBPTaSWQKUEHpn2wB+4ube5LG+J3 IxuEgoDYRmdj5kB7bMGeFoc97aHkcEK6wjzPiyzvMgu1VAIpUNsV+kYXnl11yW7RO26QKt3e3i4W i/ndrV0DXcBh10ayWg6h3nki5kxsazv/Kx/7ZZPhsuPcjalswcRwo1YjRmYpUR+m12srj+0WeJJJ u7eS3gLpC3d+HRDDHNLt3u++NTEQbFeIiT3JbFzUrfW6Y+9hXIOcR06cCB3lRHom7Qa1PR/OKiVd X5TqptlADX2EiNi1KdxAu7hlMuVsuwN68ASFKM7An2yy2Ou1247a/uQYb/hgQB0f9d7yYC+LxUIB B8WXHdAMKtronsMTSZ5iOBFRMYYeDr33nJ5ZtjppTbhsVeC+Ki/RAqnRqO1xL18+8ARgi4mJu6U3 8zzfiq10Hll9So81gIiILJdLaLDs/YFX0CtKZmK72LY8ssRIn7bL7lQGn0CqCVK53AvDDnzZPM/H 43GR9UvkEqbQexxxhkI0qdHy3UZxwe2vjohgenZ/f//tt9/mvCUeVEldF3CcTAmksDiji2Zoe0Hp 9YHT4CgJwVYfYv1RdNdOy10g40CCGNbKnxJMH6J1ahff9D6y93VOpoQtDteWIFr7sZ6VnHM555PJ JEe06aoJIbiDjc2fnHRbOrwDFkkkIxZai/ag/qu7HtclPxyIU3csyKcVJXR1K3qtLAgXibcIwhNT hNS6Jb+A4QB6rluh8nM2+b9oa6luGWVrHvld/jXWYgYW4r3rUTmYfoJNNtc8t50B4Oi+AvVttduH jXY0EyOV3JRoSdFNN5LPyewAKg/lgJgEiDpyiHD7ENoFfrXapmlUkXZOQxRPS/ZUJCJCKebYhTbs FnVIW7jQnVu9Z3srf1bChlqWJQBHAixw4ZyDFAR/wly39/yBgGBu2w9TPXF6mu7IxqCCTWouy9JK OKxY6wlJ162uFBV+qmlq7042/OEOhwXdYmJ298T9yk653s14VxAIHBUGNIbKQ6lvYifQ5JD3Opme pP7erzNQ8x72JWlJqGKjfN854uCyOnPLuvEiDerZnhrMbAWJw6/Zq8TZSUIc2lnjZMOlhx/qgoyt Kjsw1/StP5BXCGHAf8ruzcBGvZZMtnvKbcCFLFtWrYreN4BjaOieUIuq/E1XKFTMusq89zHyb+qp F2JU0IF28etyuVT9CMeABRQ/UBdzkHEV1pLe+8z1Q+HQMUDpfVOJfpRZlstwtljbs25LAw/uIuyU VVVhIMbjcV3XkG7B8frk7ZM7Ocq7VakV7mlNDFCcQCmct8d9O4wHvqae1TQoJ2aP916ihFiODCpw MulbJPhAhau2D6PRCFKQh4cHoJP7+3v8ZHEJpFx4Ed0gN/YckWtYdSzON3qntb5mGo/H1XJFCvLQ N+MI9+TWYdJnCGIxh10ziTiEt+1IkmqHGx1itfGoEMwRs7eG7mYwHEd7r5d1t86jUPVRJQeK2bc7 h1I0dnKFfc9Z6X2e59OyFJG8qquqelgumdm/qNRyQwcCjl41SkK9Z4beqsgAjrquVSHbG/VBGfuu LVCvE1ZvpQI6Q5JKBtiyHh6elpKT0oCixJb53e9+95//838ertA59/j4eH19rWDLmejJeB31JbYt FkWh8fpQIe+L5xRCN0bEBiCqGBv39wOOhEUesqSHZSEhhNVqhSANsCjR9HenRWLBkFnrjd4DmYh0 k9CcQxIt6XAdOsanAFLdyepMzJaBgcLi1xO/hmzy3pPbbHXhpTJWAGrYYBu0bVZtxRg3Nzc/+clP bm9vHx8ff/3rX8MjS0tiZDQztcTw5wrzRSREjxKVjrKELMuYvS4buL1djEfIIZdl2ePDnIishAOP r9fr3peyQogDSblVIsPQCvGNXJyEicBDi50MOHaV8W1nNuE3doUG6oKDp93kToAdJwCU5HHV7Oyq R0xh2iuciDTMzfY8K1tfXNVSZe6IqGHnnKuxg7oshJAxiUhgJyKOmIjCSxmPynbU2mGycv6BCnvv h2goqnuSnjQWi4UKRxUuJ2B3lyyke+wJUVWkGypia6qYZLFY2HPUAKrO8xxGY1aObtldIsG1r7lr ZMDbsfHrgg0xaE0cvS0BYVEU6/X6w4cP22WI+lIWLJfLq6srDJcGLE8AR6IW0EMgmU/MIXjvLRZE 01m+8TihjiBTt0WLGUIIp2zwJwsJ7JwIHZXN+ZRIsBOuSnES67o6p/Vkp2fmJOs69tTeHUJx5cB5 Ala+mqM1kf5pH+hUBn0s6UffhfSxjLWHl5eXZVl+9dVXv/3tby1GwbtjWo/HY/y7XC6bpnn//j3q QeahXqbmnBuNctRAMbzHxcWUiK6vr733F5MpEZEPTdPUVaVdOv+Asmsn645/gkJUJfEkfRiC8m39 YmlXPb09P58OBxYDv57QsQRtPCGdU60FHBTfyznXBn9mHo/HuXPr9Xo8HnvvJ75pmibjrKqqmKT9 hRZ4iOra5D4Ockn0iKFJGPZYu+qz2Ps1Fh84tubm4JjszZYnBIxu0sSZOM90eYW+F0cC326aBjux i5nhet9IFyzcaEVkOp12i2lt2pyeEnsxB5qrqkotQPW0rAd7JiTc3mim0JmmaR4fH3vPObBxCTFR FOKKuu3cKxZwiImoZkdyNBo9Pj6S4SNJ+I0uAFBR9K6JoY88b2zXXhqNRuv1Gj1Qh5mT1TQgxYlk sFW3mMWh5y9jy4m6gENHXz+bvqB657ptzyUQJitApQ3Z9APSwE6J7i0WC8T1wyyfz+fX19ej0Wg+ n19eXlrAYRONIuD/1dVVURT39/fT6XS1Wmmat2q1ou1JHIeL9CgwGo2wosqyLLN8Nps1VU1E0vjv v/9etnO1nDyMB06VpJid0k+1wdsaurWFKOGgfbKQZ93DupXvwmpP2OJeFHhUbWf3SOsa+jF3LmPO ynI6mdTBz6bjq+VsuVzer1ZF5h7rmqBqlBBxS6qc7WuwX6bVS8y80T5uh/3QJQ+43MsBdmWKljDU h2D03bhQngANe9AUlSFYM2QVhMMUTzEERZE2G8Nb8FjgFcU0EiOQoi2OCmIx5t6WZDv4KXhRV0bO 2wp9isfFASlmkrXEGnDYPSWEnhh0q9XKmYhhwdhSWL3J4+OjjevaS10JB7WHupG2q4vLbp12xdV1 neXZIYo2emHA4WKCLg0S5WKIizMNEexXSerRUYAqJ7l5IEnH74Yk5f5dCQeZXSdRKFpcqVIB6BT8 dmKzzUXkXo56jFSeg5VbODxQDPBRE7k9Pj5Op9M//vGPRJRl2XK5tFC6LMuyLB8fHx8fH9++fXtx cXFxcYFnHx8fxVgzKYrXC4ksAN8R6/yTTz65upgWRTGbTK+vr5ePC+/9f/z2312MFGKPGqfJGHbN zN59VPkgG3OTJ4eM3aZFxEcJx8Bxfxf0edrpY6H2QIHzmxi+SK8P6EOy3Z7ZT0g47KxL2EgIocgy Irq4uKjrejSaXF9fz9brP/3pT1LXKuBEjiQ6yiD0eML3Snip3cNotzxPKSncw1sAACAASURBVM/z ujkC9ChptCQoPvQULiKPj48hhLIssfCt25SlRKvS3Y+bpnETV1XV3d0dRRfT3l1Da0ha6TJzipoI q75xfYF6La1WK41UoaId1b2KCJvkFURUVRU0IDYWw3ATwGoJnrDsCH8mZgxAG6vVSvXdIXjEV8R3 6Y0ZDcFBomxKlr8IiUguTyHp3Uv2O6kqSKF697vuomx7tvdyA9xs9UpC3quajerapB3ZzQ23iGMY /I2oPNawO6gfMwsFIRYidsxO2CVMkOsmiAk7jbWkDo2kRwFG48TaMIzOUsBh7I82F7gMJ8qOYJUi xNT2g4lz8iwhk8YRZZw5ChIaCZRlmTSrjMp6NV+G6k9f/271eAchBIcqo2aUU34xWq2kqqrV4121 XE5H2dXFKM9kXHDF3kldZhLqmklEmjyTpmnYcn8SHyjjwtdVVa0mk9HPf/7zm5ubyahk5vFoxMyj ory7u7NnF4rqLZjO9Jo19C6BzYLf5fpPfVMw3mmgECXqyd+6VfyULa2LG0TEa9QEIk/UEEmCkuOm 27P1nhb1aJcdPhER+d0w66kARzIOvX/a7h7fzlm8EZIJ6wHkmAOJEyYiF0Lm/bj2zDyuA3NOOYnI 62l+9ar+/vbhce0Xgb24ikIIUhnpRZMREQ2KEg4iRP5gcpkLxGvignjd/kfkMiJO2khnkOuMcc0V cdP+Z8hRcCSOgouj6sixSJHxZFT4ei2+rnw9HZdEGWS8FDyLXy8fM5Yyd40jRyGEhllgKwUPnngN ntkayqhtBJOTQOtVBZ9Piarqq6ur9+/fDxsOuki028Rw1+aVlF+v169ml0TETagel35VOd9OkJZf eaGqyV1GRMTiiAOzxy4ggvjNjjnPMsfc7nAiuKnCByZiosw53zQS1Vu4kzmnsxnX3JnfTigjzl2W scuFc2EvkgtTEJb04G0JEhfzawjBbyeSFHoxCYdqkhJ5WojGdLukdueTbjB7z6mWdonCKG4oPYLN DR5gbZGNsa2tB0MB2SAEG8HI/7WYPd8f9ro9dPLAWtnG4ZVALfL+/XsISC8vL4moLEsc9/M8v729 VT0RMh1rcsiEMGeSdx+NRhi30Wj05Zdf5nnOEl69eoX+recLPRvZ/qsl1IGiP9CAnKBnAmwTMx+b Qm9vxzqHhm0lDtOunw6o9hQZjOyeGMOA/nzA8RxV9db5tHxJh0WtFyF+w5aDhbBcr1+9eiWumEwm j+tVXdcP1XK5XO71FziZsC52yTJVl0G9o9HpUhJH+JDWyViJJhxb/wRcUPGwShLJeAkwt3soR89H MXaLbAwYoXNhY2nX7ZhWXpZl18Sy+wrdO73jCXU52H6eZRzNzK25DLtARIE30hq1WoMsARt8b380 iCoKh2Nyh5HJhId2m5PkVaDuqL60DUfC7jHE28joiQlzKZiYa3r/mVo07W48BZK4Lt771WoFEaLt zy7zpXMoGdvhoR6NRgPMoixLaECm02kLE2PsURwpMFPX6zXsQF+9erVer5n55ubm9vaWiJbLpTXU ms/n0DKqxbhSr5ZNtZIhhDdv3nzxxRd3d3fVaum9z5yD+dV6vcao6pvqrIPkU45x7RnAHMMPYigO 9PI/sForqOx2zHNauLfmrjwghEB8yqyTwQ4/B+BIZPt7ZRtP0tATcif7+YgoyzLgcopb1Gg0CkR5 no8vZnVdL9ar5XI5XcwfHh6+f7irK89l7r3Pnsh7xQk55zKijKhwWeGynB2OuSjABOFsMuybGnj7 JyLKXVYTs5Dmf2hLyua/LqlCZLVaTSYTIqqqSkRgDapHU03QaJWk21BpA0EsLkFPoI7R3bTz7BYx 82Qy0eacc10jUFXXGh1E6w/htxMhKUHEAhuL4D0ABEeDVscb0SxkY8G426iugKOVKPW5EDvn6rpG zYmO6ViybEQ1MiLCdkejlCNtXmF7AbbWOoevKLgvntDvXXQ48jqN1uu1b7iqqrqu1V9gr7t5+muU ahzYqKIHTeuXHExVGan3rcbuKBqwEui9iYUxHo+heFM/jizLsM6LotAHoQWEmRK286urqzdv3qi0 kKOkKjNQnZkRdkYX3ng8/uSTT8A7kMYwhDCfz+fzOWJpiMkkaRFPV5CAQIHgJpPJpKqq9XKB5UdE Pprc4mOpJgWV4DQDgeoul9GEhk/qA4QjiJgclXYPO276RbIaN+p83wRw7KrEbsaGKRz9jntlPM9B ByKMMwGHfbWB1zwHiGBi6MwEXsfSy7JsNBqxD1dXV9cki8ViuphPJhOfcVVVtdB6vc4YfF/jJZzc kY2/Lk4OyUuBXWBP7Y2N0UUP2Op0jxRjekkxMCBKwmoBKwVrtq5rze8KztM0zWKxgC25goxdHqdK 2FaShCMSY3rqwtRuVFXq+UJEee7QW2SXTWwgEppOpzZTGpDTarUalRk8VNfrtZhogSKyXq+LPMcg QIzE3BO5TYUZNjSqRNJiVgqFGFc2y8Q5m6y1BQHrTlOIRMCRnAeSc50MB/7a1fYhxXqPpy9P+LR1 HQA4nqlLw4dDTD77vfFVFLlrVw9pSxcwZGXKDVuLcVMsaQ6ERy4uLpgZXiFXV1fIgquSQ2BKlfdO p1Pv/du3b+FIMpvNWki+3SuKsrjRaBRCuLy8nE6nGH9EksFxQf3KqqpaLBZgKBRRCx0wwTCYiRGo c86H0DRN3dReQmAKvDUJdcW6GAj1wMlwzp6K0baB289sznKZLmoJB8tseh8/lnpPMMmvex8/s/WB bpxTv0UbJ1dySCsS/dHG4zFkgWVZFlHgURRFLuLz4u316zLLi/FotVqtffPw8PC4WtZ1nXE7w6uq OY21ufY/ZqEyL8q8wDWyYRORZjAQEZir7zJr0UGDlBQIG2e8tq24YUuMemlFO2IyYKiHJ7Kkqt8p gmEgRbvKNig9M2/ucFTWY6hVjYvCqG3P+DgHZgvPWGUjoRPkg4jG4zH8+W3GEwwC7OKDNJnLiFnI B2mCNE0TsozzPPcekpIQLzZvZDnV7e0tmgjbnha6weNPSM7OP8nrIRB4y7a1lxQY2Zt7AIdd1Rz9 gA9pzNpk8PHK7KciBZJIpCIHqN4HKD54KA9SPJFIcc5ktVmWcYu2O1ljOoXtwRof5eLiYjweT6dT wOqmaa6vr9HJ8XisblR2un/22WfOuS+//PLNmzcbKWWnIQSqh1Dh4uICEo7JZBJCwNqWmAWmaZr1 en1/f58sGBW3DKABCGbAqlarlS7p0An3buUKAGoqGsGf9nyZjuQTnd3VVnzX1nVC07sQw67w5Em1 50MNW+fJgONJGu1tpXv4O4qOFWSeQyGms0b8ZTCoJm7SehTO8+LNmzf5dFzX9eN6NR6Pp6vlarVa LNfL5ZKI6ro5HxkVRYEYwcnC0WM92MWusbWnW30cyxNSSd22N/LRGFBnPB6LSFEUmqxAsYiyUB0x NvGO9d8EcLDJCsvGkA6dUUVJ2E5GsYuAIcbjsXKe+XyOQRiPxzaKMSzMdIR0oEIn8q8gvoXbE/TS RcIZ6e7uTjdTjVnSJchLkg3CMtUDj1sYokTCsVe8NED7JRzKxDHPDlmNQKBFUWB3kb5QIS9Dq9VK RKqqgoQDr/DkWqG91KtNP/yTi/FVwxLtWllGe/iex4no4uICB6bJZDKbzabTKTiLXZMXFxcw8FRS wSBWGuY9FliIKZqgIgFDUTUnbEXtgQa1ee9hyYEHLQyVaEibmF90r+u6Ho1GEJ/c3t5ad6y6rklk gyyZaTuIuGpYdD6ruW4vG32SXVOMhVoictxVfm+FlOy7+N+gSkXL76j/FNxwoEzlCemQb3QmopKO ZPj55ByYGzg0M/NyufTewytK2NVV5U1SkqvZJRFdVOtpOXpcr5qmeX93669mInJ/f39/Px8+1/Wa BUOEj/8m4/GoLMuyhB9EWRTOIOUMqyy6fgw0FELInCvynESKuI/mWZZnGXwl1G8LuywMsxQTqCuZ KhCtDqVpmmIyFFvCkuOMZEtJodCBop1HhEe9g8PaOmS3s9kMvE7ZIBHh8AaGprpybY4oiHj8B0NO lATHa4JYhCcizDA4E4qeifVq7Zwb5YU0vlquyAcnlEO4FX0wYVbjhLwPTsgJSeNhjuOERMjF/9Ar vR4mNl9q7yYetiNh9pY5FHBoLcNTTUExZtIPolhRIRsRlWWJUFSwCsavu6JcPyuF8yKbgSSaQamA a7PX+oZ2bBpQuU0mk5ubm9evX19fX4/HY2Yej8eXl5eTyaQsy1evXl1eXnK02X54eICzSZusJEb2 pWjhEUIYbYNre2pxMVTGdDqFH8pyuVytVtrt2Wz23XffIcK9ixFXVccUtv3+zdxtgZpGKUUrReaI aLFYEBFHaS33pX3RE5WIIGqIQo1zRF+H0OF4faAbdjVtnZbMv70Fdj24uXOS0ejJdPJQJ2fEc3Db LkpmwvB56XwsgreAABzC4KwoQgjCtFgsiNlG3sTBwHt/9eb1er1++8k7rJ1vvvlmOr1bLBYPDw/J kVSb4H3nUggprTSCTSZ3LaZJnbovohfY0ZVpoB4E6LOPuO14FVbFbMN3UpRQ4tDojMe7Sl9MD529 n5RJXid0nAl6CbYgYFaXl5d5nr969coWCCG8f//+22+/BZPxvo2Jk3wFBVKbEWPGsVyPfxHjbjxu LGtFRgjfl5ZZB+rAPCG92vze+QyjHDIBNoZrHqCePilb7PLHXS0lxVQOc3K3DiSLLexNvaPfW6OD qwbujFaHhtvFXI99Ls7bcuDEuq0PLWQuIyIXraBXq9V0NHbO5ezy7WStrQcpb4y9VboQmB3zZ59+ +vnnn19cXEyn0/F4/Itf/GI6nb569eqzzz77l3/5l08++eT29hZQPc/zPMum06nVFH799deffPIJ lty3337705/+tGmab775Zjwef//999fX14vFAhG9MDWTPEwKZfDJID2G5AnlFQV2AUciwYNW2EU7 bUhuVJYmIeAQE0KgLA3VzMaJDg9KJ3Pjc9PA7DESiB2RP0yo7O5aFOoRpPVV3tvuKUxk+JlnFQwM 3Hly4Bg6qXCeliRq9yDnEASsY09EwtQsK1q7yWRCRcbsHMtkXGaZG00neZ5fXl7+4fs/TSY/nU6/ u729DaFZLpd2/oiI98E30s2wBcIpnKh9x9Z2JM8hDgTZd3fbiat6X0dEoEtV9X8vaBPKiejV5dXl xSw0npkdsfjQVLVzziGXbRBHDPsSKuViMi3KEcJCELW2Jl3Pl1FRrpcrJvJNU0SbMybKnJMQijzP jXqoF7jCSg1K3sViMZvNqqpSIPXFF1/gGhwGUE9EYBmKCsuyKMtSTzjgMHVdO+PXA7bP0ea9aZrC bYxOMOqwisPXQdIoVeLsOseGEMbjsQqM3XZc780jPoRod+zjcY6Mm3QiMti7rWvNx0k4IsjaiKO7 H8TWaLGtPtW78b8wKcq7v7+fz+fayWc9y1I8TNtWnPEH1uGl6DNNnSHS0HI4lGMTnU6nzrWqTahC dVMPTKvVajQZwxhTYXtmModdXFyMRqM3b97UdX1xcfHFF18AL79+/VoHCnZPeZ5jvgJ/VFUFWQXa vbq6AoDAcsJ9mGHrWysitn6hdj7oGktSRvVOaJ1samumTmjJuNlzD23bEpGZ0jr4yGFxLgY9mHTm nbx7HTh1n3uGn9mHk/FBL4raVeyEQdj1XZRpDH+4Ez4r4DiEgi1Yh+0kEzO7PGPmrCi89+RaNpLn uRAVRQEd6NXV1WKxuLm5ATqvqgqhIYkohDCfz51z5WhncjLvfZblIYR3795hLU8mE8g51EjTjkOS 2RtbbLfaXcF1LGX5CCZlV1dXqujU7VaXKtQZ6Mynn35aBU+RB7pooanW6E0TKMb/1iMTWKVyWsQ7 XhlRNyJpdckOmm63zPxf/+t//eUvfzmdTv/hH/7hf/2v/0UxoOVqtZrP5yEE59qMUSq3qOs6Snn7 E6ys1+vEjlWnMSyLiejq6irPc4RvDsZpQCcnJBDMPJvNLK9rTOJSVV43TaPjtp32pzWvydo0e+3Q qGQlyzKrTgVsSsQ51LcAj1OpHEgAepD8nFbD+aQnafz58PAAwMFRhPXkHdMMpbwt3mjVZrLplW2V o5QPU1M7n80ukShk4NUyhJzDu2RZPpl6t0m2ZPGp7qbMjKi6VVVdXV0hni6YCySoFizqBc4r+ie8 TtSN1srutMO9YlJbrHvfCuv0Qk9duK2PF0WhEH5UtO7mIuKM6x0yERRl6VerromrdhIT9TQEcMoU OiCS264QXsJpytO0N4PV7uICJ0s46Dy/0OSCzl6SzyrnOLYDw6TzLUS7Ud0/XJ5777MiZ+ZMJM9z FqnX6ywUTRPIB+ccOc4KDnWTZdnU5V6YsuyLt2/92zfv37+/u7vLaRZCmM1m33zzDbINfPhwGwLl eYZTRFEU84fF1avparXKmaSuLsdTyDUnkwk2+K5kwi5MXJTT/BCTuETCj4NKNpqiFbCgYIIfqlgF KOrq6urLL7/8wx/+wMyLap3n+evXr7F/F0UBVztq9a0FRrKu6zxvRTWz2QwW8bytabWMsXddgHAm UdCJyN8QCf/iF7/41a9+dX9/j0FQn9gQBCjHehrDkoOIRTykSrEXjXO5iA+hoYyFhCRYpgTAAfCk Z0JlztrhEGMr1HU9m81g7iYi0LNkJl0LJGp66iPDcxRUqd0eehF2Z58+nJ4FcGA36ppKJFhMB+uQ o8PhZOvRLdx+mBeQcAx3TKUdWC2wkODtDEAu+mIlNewS7frWsCOF5IpmKPp0UJTvwbQFUlz8a2Pz aYI9jr5tajmvmogE1Q2QqmZC9LZ1+9IN2BFjY5FOUSUMp5jVajUdj5bLZbvdSqvpXK/X0IWDv+BJ MRI4MYnvMdpHLaeTZ5EcHPYmwQfK/naX3y+kedqZf3JtyYO94OOcanfVM1D/kyPO4QrNUT6s12us U+wQTsQ51wRPMUQvOcZBwk4APc6JyHg8ziHz4zZtMqyv5vM5IvU1TTMajVarqjV7Kgoi+vyLT1er xatXrxBrazqdYk2prUPXCUKiasC+/q5VrI9rbCvlRVi/+fgCDUE9oTL/hJxzs9nss88+u7y8rKqq oU3MHtX7qFFFVTVVVc3n8yzLVqs1EV1cXEBmY2Uzzrk6ZquJPCF9UxW63N3dVVW1Xq8vLi4w4HVd Q4b061//+ne/+x06DwYbw2akX19EYJjiuYFgdefk2B5e7YyOhhbQcQjbSbtE5Pr6WkQUk0nMjZfn OWwygOTUmUViQxLTw2Jjsl/kEKbnBg03czU46BLg5XDt1F1XIr5pfMxlB2p7YGwXtLC9c9qat08l w6Gjnzzy3JgDlhzaAjM7YiaTnNCxy1u0AVmf7u4oA+stjkaOFH1/FDHgpsILz9w0jUhwxBQkNJ5c RkRBfAghNJ6FxIf1clWvK++9+PDH3/9hPB77ukXuWQxgzDH1rqo8dL/Xdq2lhTX23jUgeCMVtzTb 0+MQYuY8Gn8xc8acRU/9uvYi7Fr7FVY2xNGXHau/+8VVQK2RQmTfVHwxqGp3F73Yp/f54dUox1IC Ec4Z3mRR91W1BwE8reb3cGRJBpGvVitybjQaQaUCobeI8AhshDIp2IecMlrXIa/Judw5Dsyesiyj 0jVN00iYXl2+evWqaZq7u7tvv/12Nps5596/fw/HrjzPb25uiOj9+/er1eq77757+/ZtkbWhgnPn iizDn/ou7UXscPtqzIGIsx6U0DRNa2DBjPwgTOzYOWpl9bnLrq9eaVUZu4xdgxAg7GxY0ozduBwV r9+gPKAYbe/oIfqaBU/z+TxnN2c3m1xAJABNRJ7ngQnJyaApFmMt3p0vKoVFxCCNrtE0zT/90z/9 9//+3//H//gfTdP84Q9/uL29XSwW8POPXE66Oqz2mOcDBodleEr2E3Rkw2VWq9VsNtMDJwQkZVkC YFnwqq/PUQav62hbunwEDTyyCepybKXcmYtKu3hHcv+pRBpJryQevt12XJTu6efFNg+KuzjF7bks y6zIVYbBUWFm/UshAOSobQEoUZwLCRvqbJqGYEHJG2mhVdqB72iwW2b+7W9/S0RAweTasTo2XIqL mSQ3s3Y7yBiYuKoV6QCzo+ExTK4VuyR1Yjx9VTNzCKEoCjHKSzZEUc6EdThg/v2E06ZbQwKaQyfF /GH78YnmHXKqSuVJ1k/3NenUQT7HEOc52NHJVNe1cHvGwAxvmoazNisp/oW5hqYCwZxvKODXsiyh FgkhQPuAwjc3NxcXF03TvHv37u7uDtefffYZM19cXFC0jQAjoj6HADZZ4JlZtjNXW5YLtqCneRfD AypRPGKRsQ+AfEUfwUFF1QGk1gaOtTkbslkCTyaTi4uLqqqg11DVgHPOFXlRFFBJ2JA/3K9SaY9b eqaq6/r+/n48Hv/qV7/6h3/4h6+++urv/u7vvv76a2WeYuQlymT0PIk4qnxwOKuEUA+sU+02qhxY /0VDkF7gX5UuU8c5yH47uxghDkksMzYnnz5UsRed9BgbDyCJbpkBOoFlHHUmGCDXsdC0F9bW5mUI E0UNGGG8CfEGNLVRVcbT6dRGs1AhB0jX1ePjI0WNCTSyVeO5oNo3GXFGzEGYhENr08BBHm7v5nf3 s9mMiIqi+Ldf/+vqcTGbzT7//PPL61dXV1cZu+ENhIVkO6do11+nF3CAOaoZ6YDGd+/Xz/PcRRN8 51zuMpZ0m1EkYVGFJou3310BB0YSFyjTOz2OO4VL/9qTvleUdFxZjxkiaLHlskMNylOmWTroqZPb G6jzPFHHyQ9+VIBDREjaiRAa31Cdu4ya4Kluz/3MLOSlckGysiSRjChUdTbKmLnkrCAnVZPn+Tgr yqKcFiPn3O3t7fX19c3NzXq99t7/9PP/649//KNEG0PvWht2ZEoiIkdMQs65YLR1OAnjmokz3mz8 RJuk1izCIliwynmdcyziiIos48Exd9EXBpYowWb9zFq5tUSDD92/RQTr7s31ayKSiI02zD+aI9zc 3Px///IvR32U5XL57//+7zc3N6oA+sd//Mc8z9fr9WKxgGmF7WdUH2eATZDyOufEn5LFQg08l8ul Yj7d4C3Hw45AnUhfuzRWCSmTtF/HPgvsYrGFOr/Y3dYuZK3quNDmthaJ2jsxuvCkvIrQtWEdAtUR ho7L+K7WT+AIajFw7IPnk6JOVV4CRsBAGhbm4/G4HG+F9tON2ao84TOC14HVhc4nqOVUFaL/ogwS EKA/GmpmOp3Wdf31118jB5uI/NV0cnt7+/btW4u7u19ThYqWkmJsLCJVaoLe4nWQP0XL269/iOzO OUfUDqkG/pMYuoeZFRIpmGir3dY92zIK71SRFPp8zZOZv5dkl6Rk3ywWkcBbLPXwRvf3aheQOnW3 Pa1jdp50v4v0fazn6wz9QGhj7/kqmDRg4GPMTA1jTWHt45XV9zKjDOnNYLZPRpuJ+Fo45+jw/uQn P4EtV13XwgLXM46a3N7uyZYaIuLibXMrijID7/16ve7d55JPrDuo7ibYXJII4s65sAEwCMOab+2v 4tRxFHYZCNKFftahVRNDo2QP9Ls+hRZ4fHzE2GJgYRnz/v17lZdY/tka38RrCJyAorLCjcdj+0YJ 65MocewVHXWXBiaD/olWcK6DXT/kNGo3askGJOWOFartXvfonhQj85kSCxWd6qmE48Cjv0WX2mnt ukpveqvSycExlM3e5k4jfBiNQUsvqEzRvd85x0JFXoxGI8BbbGwQ+uV5Pru85BjIyw5Fq+aMWAQF AF3V1mnzFfM8EDvnat8aIkwmE01WB00BgtzBmhpHebhv/f73v3dF/vbt25ubGztLeqPHWN4xgA8U YOHPYGJ739/fL5dLrNhhhNE7MZiZSCAKAmcEcs3zPPh6AzsMT4TMGTIEuyxt/RytdDUk6EDH6LD5 I7skHPseF9mkpT5qokqLZfZs1Tuw1ItKOIYh1MkA6xz08xGSiODMEGISEO/9xcVFlmVNVTMzBamJ M1g8MDPzcrGAqiLP82q9LovC+s05ZoT7zLPMN42mUgWXeFwtR0XJxLnL2lgRcTitLBMJXDimLLHL nMx2aBWdkHHaV3MxNmAeQ3qAS2ATsd/RGXcV1xq6tYOjBey+4zj33rf273GLUQUK2AJiEWE8JSaK 67XitK2EmI9N/0QN2MWBRfRBywBVRA1RzXQyzfM8L5yQb7PxcmDHQl7IE2Xd1nUY0XMVHtuRtyOm lqF67lJ4gVdWtCr70ljqbq6cX4zRffwi7Z/aYZW14PCgx8LT09OH7dQVij/s+2vzVv6jX4hjltGT +7CX1uv1er3exfqfifTcDBoVpZ4bVDOKfyEwcCZ9YustlmWTySQzCYrszPDel2XZmDzLFEVNSipf wTVC1jQxmaHCl/l8nuf55LsL6DW7E7f7dori8zZmQL/5p050MjoLilKZIvqP2MK7BrMrP8uyDGc1 Irq+vsY4w5Js15ajKETBkBhHdns/bGdF2kV797ZdBeSADVV/e25kfD6d3MN9qOvlAAftNjx/biwC qKcs1PJSJYRnwHr3kSzHiG4RLoRAbsOK8zzX2B76Os45WB1iwqsjBhnGdfhbM7P6RnU7r8dRivwQ 4X2LokBcYDjRkDFx64YixYXmDbGAhgzaUN83x86ZjNMYFtWWkjgXYxpB0qNa1Kbx3ffWw32vPGZY O2xlGOPxGDE2ZrMZC2k2K/VuDdvGcEkHlEGFEMD8N2/U1zQGpBsKRe2BEvFzMqTJUyH0qK2Djc68 Hf5Va9NoZnCSIqLcbb8e6z87qC0uFDTqISarOe1wECJyQiEqq1qnxOCJKHDgIEVROBPgnQ8x1xXp yd2bFhHGaU2IhOb3DxSExMNzo6nXsHkOIRimvvW/A8jAWCEyEThw7aLCvZVzcvtflrcnD2FyeYab tB1Xh2OqlCQCDG+HydLZvIGZrg3wBbCyWq0Ul8DtTYPTXV5eYvYgdackCgAAIABJREFUp8zt7e2n n37qhBCiX8k5R4Px9jFrbYy/9Jo2DAgm6G2BIJqRMhlQdcNJYCgTj4rSOc6y7ObNm6urKyQ10EVI RL4RIqAuJnIhEDOSLmYircu7RRtd2R5H67BdgrdgElscsLe169aWFJEYMKd/Jkdv+KdUAiZdPVJq MlT45FwqOow9dXbSXD03DctakpnQvfPk5JLJIdIgOTtznufr5TLLsoaImZsYdEc39cy7wJznuXAI 5JzLSfx6vsiyjEIoXUa1d5xlRCIkVQOFbEbkjvFHsIOAVdxVFCIHU6IIgPYB/qV5ni+XjyE0k8kk z3PnSCQQMVEgEiRdUbySZYzDtrbIxL6uivGYJDRNYN0pOQQJBBkht110zvl1leVl0YYLI+/bRAoq mAcG610sAzOkdzLoUVCiwivP89evX7+6vCjLMmOHiG06jEggy3Bv3KHGEiPPrqoKuhKrjlEBA3gs CxVZbkVT7ZfyQXxgduKDcJCYjQWWMXrW0m4AVOXsyAf1GxIf8iLPdcIAFcWEO20NRDCPRUW+aYqi OF3C8eR0yEoeLmOP+EQUQvjuu+8oHsrD8V4Yu4iZe/EJb3dOd80sxsjK2DnnyvHICifs4+qoouib oh4O0eUSs2FACorm3PRIeZ6jPAQbb9++HY/HECpcXV1hpkq0sYA76MCbWmB7CD/qrtiknqDea5Ra HnUbyqKPftQoExGNx+Of//znn3/+OXxf0RyCnJKBjarUa48GtDHXwA2IQK0MMIsJKq3tS/IWYdCq dIs69lN9RTrajeT/HTpttztAnHBoD+39kwHHgADJLuGnpUOG7hDxhp0zh9c2UEqr2lUzBmS1WjEz /ErauRoD/1dVBY1tEwhzG74hyIqutamARMUbEJyQY9WA66o8dqapmETPDNY+IERC1hj0LZtMLy8v Ly8v3759a5UaLiZH1RWXKBG0GLZDzCbOHAQAWkyiiahuzM44aFi5O23bPD4VWeg8nU6n0+nFxcVk NFabG4oWVNIxaW9fwdxBnA8rmElexCpHutxVdV7qwBg2UUO2DOlcjGuODtzcvOFo8ZqU7CWOyhQX M+BoYOg8mVNbirt+ajFU4qHQRVKbMknJ+BOAWBDfhHamqq/UUPP7VL/2DIrdtGka730ITQiNEBEn zO7QScbRXxwn+/ZlooQjM3esiP7y8hLCwFamFJP0bI4IZmEXRYFgfwhRp+JNjrFxHh4ekJAawwXB KREJO2yuMFBCxnllIhq/FrUhFwC0PJBtovxR1MpyjBTECWXEUBnkHBcP3i5zKs0KdQOwnLMjoRCC i9oW5zLHjolJWvnQqBy9fnV9fX09m83G49Hr168vp+Wnn3767t27yWTiqA1ZZkVW+NwWmzoThwOD r1LW5PvqaHe5rZh09vbXnRNyWDZwwErbUevOh+IQdAr0w2NT51Bn+980SlJP6ad5fFeZE53Inlb2 8ALCDG3o8JJqMAfIEJomYLP0PoTgArksoyDNap0JiZC4DCZMmPlSN8KuTUkqlEGwAKlg9P4Y6CGb 2JTD1DUUtUe+FlLU1fLhnpp6UuQu+MlkwsSZBCZm32REJIGYmrqSEFyWZa0NQHuevru7n1xMtX6c 1asqqN29tkwUvK+zjFnYObdeLh2RhJA5Jz7keR7Eb0TjR1HfJNE9rqlqxMBwhrLtfAu0GV5xrucs KyKZY+fYN7VvaibJHEe5uWQOUJWYxDFk/MGR5I5HRd71PHQk9j8K3jl2JMEHRpwUojxGh0LANI76 8YvxpMxyDuKECnK5a1GLcCsRjx0mQZbaIGWW5yOY7VPO7kQJx+HCt17S6SvG8oNNqM3T6kyqXS6X mN9QKIhICEH2OgkMEnSEeb4lqtoCHFGbmMWMazc3N/h+ikIoqkJ05umLv3r16tWrVwiKh4SotH36 aZoGGd6xYjnak3shEfnyyy/RBKYL1IREBHMnuOMibrG2m+f5zc0NRHzdz3rIh9YyaDdxC9Klpe8I ucKkHCsCSCoE+oYc8vr6+quvvvrJT37yySefXF1dXl9fjwsej8dAXSDLARGeJHRCgHAUP2n0my7f 5G2yvdULMWHjk/mW0pFb5nYlx8kb2l97Af4TUbK+9u6Re2UqwyeHE3p4PnURRhdf/uCEKa2rBoI6 jsGCmcUq5uFyBc8UkD19boTnmWPmwE4tKzmqF2lbraBhAFUcIh3ovEt8pZabFJlkE8Lj4yOu//qv /5riJ4CRGUy8Qwj39/fg4ZHpZcpzHpeLzU6e50RUjFoThyzLJB7/MEqwfVksFk0TvPeQjmhAQrfD bvQcgkQH1zhG7rKToDhuiduIPuui1V0iurDXWZaBAXZ/6pLac1h/V4ny8vF4jOCzP/3pTz98+ACb QnW0wQzRj+VjwBVVnGH3AdhSFwc61i32qYiN+41lLnasj6WkNrhj4U9ElKP2i55rQJohkyrxZDIZ 5UWWZXVVhRCq5UoTrONbwrbx9evXSAQP/SVkiVh7zKyyB8ALBPuiOMMuLy+zmIQdM8PuiBhDCE6E 3WQy+fKnP3n37l1d1999992XX36JFK8hBGR0e/XqFbLFQtP01Vdf6YQ+h8VDfoPFDIswMfZE+Kbq pEdx/WvWtFiNNI0XyUIIr19f65gURf7u3c1/+S//9/X19Wq1evPmTbN+pAhTQuM3Eym0aGC5XPYg nlbasuWozDsUQL0SjoQStNFTzy5lhPn3BBrapwfrHnijveCADETY+b7H0IBK5Rwa6NUhH/TjARb2 RZJeIWSkbvwq5eZWBt4GwsJRBNamCFCNP9UNRJ9iZs4z51wdnFr9W7eOpG+9xwnMOu89kTDv/L4i 7WbpfUNEQkEo1E1VN8Vi+Tgal3meQzhQN5VaYFT1+n//x7/P5/PvvvtuPB4zudlsVpZjPXFNLqZv 3ryhEGAnizGxMRVDCL/57W/+03/6T9gUEF81tDabFcYzRDeZEz7WrpkjkfROd4MTER82VsC9ZyGK vEvDo4kxdSczYVQRv4t0h8pNLrekVzjp4d8Pd7eaBOOTTz758OHD27dvl8vlbDYzca7zPM/h66s9 gdvwYrHAXozPMZRleJis9qj7k2LGbgH7bvZXXQNPdb6BQVAW0xBTq8I814wDDq6T0Xg0Gk1H4+vr 67vb29Vq5ataJ0EWMwQy88XFxbt378AORqPRer1GOke4mKqDKAQP0JvoNALjGI/HsFFg416hpxOU zIvi1atXn3zyCVq5vr5umubm5ubNmzfIAn91daWRBL/44gtgHSRMCZ2wE87tzC2pBWjbRRswWcGy 7uX4Cqp1RuchcAITxAng9etrwKP7+/uiKH7+85//1V/91aeffjoej29ubhCv7ObmBu8boneJ3fV9 lGbBH3j4IyZijN4C6ktFqTZhy6q0W0DL9dbcCwo6j+9HAH017wQcu6DVQG36qwUcR63Nk2UYP5SE I2n6o8If2pkQ2twrmJ/gb1CtAkKTmb1NTDmGtSZRsAoXBmaOhlBBRJqQgSlpeE3X57GSzHxE/BQ+ 6JPBV84ewSGbIRNViLZlljglL5fLDx8+PD4+LpfLIi8fHx+JXFmWMDgt5g9/+tOf8rJsmqb2Ta/z yPWb13//93//5s2bx8fH5XINWxa8PkVLzCfHwbrv6Psmv+5AbykpMuitJ3lW32igNgs12j9dpk0U kV6/fl37RplqCAHxS96+fWsb9dwmEsfhEyINDRClcRBCCHmywI6F+YcIJA6vcIAt7qXkxIkLSBr0 e5vD2SkN6SPYaGez2avLi7dv3zCF+dwtHu7LMq+qKs/dalU1DROVUB8i+eJ0Oq2qKss4z533vigy xYPOuclkNJlMigIepDDVDtB7hkDMkmXsfY18g3W9FgkigZlaFuOIHWWZe/36NWwemWk6fT0ej/I8 Q65kzQdLBNdzdo7zPGsa8T5ZaeI6qQqsxdCmWIbvu8WD8F4QwYnIarVq/NplItSwC0Fq72uXuTzn PM+Fqnfv3hHRL//f/yfP85/89PO//uu//uqrr7744ovZbKYB4pqmYeddjJZhv2nLwoIAhoP/7v2a Cjh6WSqb8K+hL02iYo7ukmk35h2p1DCH/J6orkM2lbt+iuEgn9jDJQF2hz/4hN34P4d2idySMpjk erbBus6yTL2xUFKD/IKAJ2AfFkzci3bjF8/MoW5CnotIm5Cob3U4Y1smOXiCRBFLauGH+vUAU2S5 RpoQbt83Z8dB/n/23qRJcuS4H3X3AJBLbd3V1ds0h8blmYwiaU/vmT39TzLTQUcd+NV11IFG04GU iSPODKe7uqoyExH+Do5wOCIAJHKrrp5pt7bqTCQQGyI8fuHr5mFVuQJnxt8SAAOHTc219+vN6u5e wgYWRTGfL168ePF+s4KYHK6cVQ8PD1QW79+/92Yjj5b4SET/s5YElsX79+/tlnxctGHlDclPZMKK CIUQCMWUFb33Otx25EOMYCmP6OFNt4+8rl7AEboGs73NI6LaexVXyLtQa0iIHE9r997XXdsMFaRB jLOiPLkFHNM3e4zOOba59nOiYUp6RdECNpnNPGCmO5F6j19sDP0gQo39yrcUogOqjOZsNru/v18s FiqH0Mkkt4nowjl3fn4uGZW+/fbbZA8rYjhRe5SBqGkLJiK4hrRT9Rs1vl5UVZXkM/TeLxYLuQ7x YKF1aRXTFVh9aGOQ0ATPICLJ5mznblE4CWJDRK9evTo/P//Hf/zH169fE9Hbt29fvXolbFGUUDpV NOqiDrJ8aLSkgUVfOBRxrreRVq/c+2sSz8eSCplGYLrBuPGvPIstUklWAcAY4BihEQnHcZfVT4R2 PX09MimHkUAdwuhCaPUggjbaXaGuAaAsS1kvEvtSows65x42jU2VGLZD1EdojYrRdQ0ioq9lrrb7 iL1f+cbQQrMkkhthC3pREr5DTMcqf13MBHt+eQkxoB/ffQSA8AD39/fe+F9I1B8xLPCrh9lsBoAb EwPwWN6LOenCV0nwer0u5o6ZffAhhEYhHvW8IYTeCSdCcR7NL5hstRQpkffo3iSRwcSFhJlJGKwj RHRRXK1gUTwfk1paXNsFHMKENQrL5eWlbnZ7RhpVJ8Okw8nnXhhlAYcdwUHR9DTqPYfJsCaKm/3K 7yUiWq1W8rmqqsvLS7Fvkivr9VriYQCAhP6EiDGXy6WYGlAMwwLRSV0HTexDE5x7d3dnLb2Flsvl JniAUJTkw6b267IsQ6gJCyTWf4ABEAEYEJDIh03gut6IS1l3WFAEbAn17oJjC0AaL6GF1TT417/+ 9X/91x+fPbv8p3/6pz/+8Y8A8Itf/Pz//J//71e/+tWf/vSnZ8+eLZdzagL5ERFUVRFCQOS6XssZ zvvA7EPwzEGkPt57DsGHzXr9wOyjfIgBggQmalXN0QxQhbeqDu8MQFT9jgAOMEzfzqvma5/Fg/ee RZQ6vpENAA4cDZYwAjimn96OuEB+skhlb+qFOCPDqDxTNhXnXFE0G5scfpqAm8b0VbSoktRNFDGy r8xmMy4QAOoQgqT78r4sSy9+s7E6YTjOOfkCELlCplJBRGAO5sjeo2RktdMAv6mdc5vV+sMP73V7 m8/n9Xqzun8Qqclmtf7bN/97f39/eXl5dgbsfb1eqfhE1tT9wwMA3K0e6rpmQMkLo2JRdHKm7aRy DXvlr96VmPn+/r6qKkmiWxbNFin7lko7ehmDHDLloKscSQW9vatb2Fe+odvDcPJXj3AoQRNioNIq 6v2t4b9VKxflLKnaNuz58+egip4QA5xNHzgiwrjNTDGI3e+nnYiNWYMl6bacqlUcdGBdVjLx4cOH y8tLNViR1SuLX7r2/v17UX29f//exvKyHddmSwvv7u40WZFaV8g9kvJRekoxj6JaWQPAer1+//49 xYA5ZVmKCZV03x5WxJqk6IaZ7+2vJCUaGo0QE/Pm1+VUIcmgRZ8nfZnP57/5zW8A4J//+Z//8Ic/ /Md//Mcf/vAHMQe7vr6W8ZTzkKoY5bMYlrs4GonwIJ7wJu2s2mZpmJqY6MtVrYp4tYwUpQvVFm5/ 3fq5t9ShusaeGfBSyW10jkXjfGNrpY+JSKaIK3YVaZxCBCLTKVlQ4/IzbUnoeuEpELFHFIzu9OI3 10YMc66Ox8gQgovpqa0QzjZD5e1eIcOAmtLHbKU97Y+94yi0l4X88eNHaZL4sCgb32w28pP43IEJ 7wFt0LzWLhKpCVJiozYXRUHUeqZoY8IJ8mxo+XIuFXsUFJ9/JqslUAxBmTUGmD3CcnuK5hfpe6FW z5IYtJEJSG0l8SLhkGOS1TzINJCTsE622WwmoMfFVMbOOTuSarEhX9Vq5+LiolAfPyumHh9EZkZs j9dhW5DXXPKBUSmTsGYrpZhO3HeU1J9ko5Jdf71eA1AIYdsBc4wS9t0LdCAuciL6/vvvv/vuu4uL i9ls9re//U1ibTFz7dcAgIDkoPbr7//+LURY+vcfvpMzh8TssjFw3n/4++3H94EDMK03NQDUfl25 CphDqO/ubsWkYz6fe18/PASZHMwhnvtRlvl6LUBEAc3gsK8brecIOmzBSoTATS11vd5sViJpQGTv Nzc31zc312/evHr+/Pm7d+/m8/m//du/AcD5+bk6f6sgFAxDaan2ylDEzR0i2M+RgU6wZHrky0PF thgDnFutzdDgHEjDs33YUGMkZBb223A8QUnDJ2nSFADEfXquR6DQ9RSwwHf8VGYxB2Uqadmk5bPa bejcVhNRAdZYMyKiWGsBh7BZr9vEaXKgAucknA5jYDnpOvE9ZTAiECJUeQYicPC9o6luqwjQ5HYB WK9WZVnWm424nNR1DcwIUBZFVZbPrq5ub29R+y5RrUEO3M1VYMbAXHuPQXbQerMJTXIop8ogMFKf SS9pwluIXU67u16v//jHP5YOq6q6urh8/fr1rCokhadKOKScYMRR3I5hY0mmujOtV8RUCi+0RiLy MecfxJco270x5usYZCgG0ClnNRVgFCD2OhFh1NzlFKLxn0iLC+WweTSSoSWXhFWJ0u82MmZCyYJR Y2nKkvSoz08vjfCLXrQRoomNJblrD36XbF22luROi+yI6Lvvvvv2228/fPjwzTffiNdrc9wHDzFu BDOLAYcaLmiKNaHVahWil7aMklrlyBziEAT+i8hUzC3VzggA7u7u5BWLQNJOWTBaRjDmGjqrkmnX O/gWSqrkTV8BxpxJv/3tb0MIAOHrr7/WaGM6f8TIWSUxYu0M5ijZvLwoslqtVmJBLe0YF0XkpG2W lxJikiHl3aEr/9PgiYnSNwHKVqVydBqZukc3Gn3kTffUNDR0I91kw/1PTckUyi9ufSqE4H2PhSnG 5GQuSxaq5+Pvv/8+UBtsV7xgVIEiW5rKRazww3MP4LAhHMf4NjTBewBAXFREH61aaY6ONhDjWBRF IYe3cRwmi5SiK75qH2bOOeeS89VJ4a8eyNfr9XJeAcD79++dc2/fvGrfQp9aFjKWS0SLxaL3bK8q IY5S3iS+kS3KioUg2gIKr6aIOfROATR2h7Wmoz5GntxK0rwmg7nOKuia0eaPCdRyAxGp8wGyWxcY sNzbJtvVnSZBwvHtxcQ2k5kHvAe2Ew0YLKgeFEyEFh2KEIJYRDvnNMEpM2OM0InRXACirk5LCNGe Qz+AmS7yvsQYCp17eHj4+9//Lg24u7vDGChdR+bjx4+yfb5//165ktS+WCy0bW1/u7Ajf7kA4LCx yGG5rfYAUK83AKAuZ8AMgR3Dq+sXl8uzqqqqqiCiZTWTYhERHIEPFTkCdNyIYR0DMCBiHTiEQIGB wZsIORwzd3vvoW8OTHqtkXvygF4GozeyvMRw1GQf/TBuP6PR4wX+GuEAP0qyR0l7Zes48MFaFX3a FpW3Z6QBbMTgvdMJowU0RMWBHgPsUZOpUakIXJAcC/JVrDrkYGO1LYhYR3cxWxH74LHWK00kyqxH bF0rvX94eLDCBl2ScrGqqqurK0SUr9qCoOHLsNM7ACgQiTlIXkdgZa3CyMfNs45FIYQPHz6EEGaz GfKirusw81VVffvttxIuQQ40m82mLAvnXCu8MSVw9D+QM6TNyWdFCLrZWROKfAcUbKeyYblCBRCR X6+t5kFipOps0cJ1sjW/Zmak+SDIh9auBKM+L8QUdkMj6L0ndDm8GCKFHVPunHKbpZ1OAHwkLxUl wRkW4kWJYiu8kaBbgs3FnrzZ1LGJGKhow0IWTSCiZDGHBSV1Xa/Xa3ROkIQUUlWVFG4Bh1yRN6v5 WgUGbTYbDUEGw8IM6L5NoiYvti0WAKRM+wgzz2YziXC6XC5DqC8vL+tuTFJ5PJdyBWOxoZRATJV8 DDV7nPTkZ/U4auWqGFFPWvIGVc6RyCEPJGbeDzQwHM2k4PB99DOlxxRpHIWSN5UvAcVMVjCuuxRG IiI53gqk5mgUItxJGA7GYJ3qvwAAdTPr2S4TKztERGjr6ViEBGzPM+KikrRfWiIrsaoqMW4TYbCE EtHuh9CoeHBYCaWQS5b4o01ywVLMvJxXiPjAD865siCJZiGk0o7kWYVTIQRRhdR1fXt7e3l5qTfU JjcKM0sgSundhw8f5JWpmcVqtZKgizoxfIzZ6JwLNcvAOuc0excabyMhC8S99xDTF2e7bXN01HEu dIHpjNTpODR8zLzerIrSaYrAof1pCGr0ln+613+Kg5o2taoqAlwul3Vdr30t3q13d3fMXPuagO7u 7kQTKRhivV43MTexDVFMMaWQiA2hKxwaUWqo9fJssVDkK1NQJpmgeIoGklIjGV8pRBRIJMHCExyZ 12gzwgjgYGaRjujUlGlq37LOA1knde3X6xUCSC6A9jwHmkOX682agwcOwJpwlxE4+Fr/AjJDiBkM ZZ8WqYhm64kxAVhP/7qdqz0HIoqhHDG7ELxz5D2GAMp/RVrTGN9EtGfXWDJ1mRm4UXhNnlOfH/0o cUku2xjv407s5dQsbqR43c842qHrxt9gBeokUkZEMThT9EAxvo7uIkRUk3SKlVNFl1rWGCEYIg5A RMRGsCHww+Pm4R7Em8ZkcmhHDACDd8AFwqIqy2dXEB0AOXp7hRAcQQBmZgdMhCtkR8Ch5lATOURE bs4PHGUeTdcwhBOYiyrVdX1/f+9jCEoi2oTGa1TFEvL2Gvg3WtTd3V2IRvS6KQiTEe38ZrNZr1Yh +gEI8hDGJXhLhejJ7izbhzDfFdwLey/LcgUgp2W5Td6pRnEFgBDqVbiHqMTJe6CbiPe+ELwDZjqi EbjlfdYpe3d3N6vmvfy0V3qW04lec34Uhk7IhOPUomigKAoILNaO8/m8Xq3lRXrvCRtn1//93/+V A/18Ppdgw845wGAQd1useIWIN5fEGKVudFElmV4iE5MIsq5sPacFpdpDA0ZzISvB0l9FCwNxSg31 WnCJhg9ChqqqpJ3iWkLR3jNBxLbEJiFQXxxPiFNROysrRC+KAFAujpgqTydpAxlNorwgVU/qGYui mRFGRztd9r2zbm/a7/Hx0OY70fSFmTT1M8UfluPlUGPkdTxmf8dnBUcVyfQS7Ne6rkXeoOGFZLnp 4Vh7qvI8CzgQQZW8kYIN12F3ONTQYYQawlIP2baQEE3QpEbVXIcQJFHUOkaOruuasDFHsAGK8kEI ITw8NHzjWFLJERLfOuHJoqEoXavbirstwIBJphBHIw9hs7e3t8vlUjxWLIkoRfKX6OP2yKojAPHY r9uK4Bg2YenZxJGCiCeEdYsxopa5cm2Aaes6m8CaEEKhvpp2yfXKdvJxvL+/RxMZptUFTj73JANx dFGEhX7HLRkyl2B1H9UtXxaJOLKKNkEFAwBtoAsZQIEsRVGcn58vl8vz8/OzszPZ4Ou6/vjx4/v3 7//2t7+Fro8Mq6Uk0WazQdcqZZwJQSg361GmiCHVoWs3I40py1IVIupRDQAiwPQxNGGzYAAAQMyn q6pyMY6QMIZCepqrsZABgLsCFQteLTaX9Adi3czRaAMCb1Zr9kFlGXtPneYMZgZW8Ttzo7D0kRTM CROxJ0L7UvZtyxOiKb34TOHFEO0hsHkK4g0wG9LIKW7KAS9gAB+49hgYK+baB+ewqqgoGMCDD4hh U1PUIyPipsnv1DoTNN+N8bLde+RX4YQMgYiCh9qvhTHOZjO/Tk0rRA4BGMiBGGpUsyIKdFWGWngO ABSAfWDJLSH/CJhDEPc9eV9qjd4ImB1waH169xj8oYshBObmvYhUw3tfuiaQK0T5BDdCWPa+350H DDaqqur29vb6+lpDMNR1LeBDU1duNhsNzSKmvnkjkxMdlcX6fuWjOa2cPxUA6QdEPD8/l1xuCeAo THYLtf5ZLBaSkBwAzs7OWsOTZKw5OpKMD7ROccpcTrBr7Go/oMlxrLUk++hIvdNJp5dvfKKKuj4O 8rA9CqHNB9ZKEREZWAQMIaYJkMAvzcSKI1ZV1XK5lPh6X3311YsXLyRSluRDuby8/Pvf/75YLEQv ozux9EjjizTR/uI7JBOVVt6s2oSi0X1AZFUCWmV3lzcigQgpJsKmmFdQ5QEq49HEtlVVieqBiETS IieSqNPgdlOPatcc4HJUHkMMj6iOPNJrkejUkWUci+z815aH0OAb205RshQxC8yTIh6w//iRIYNT 0x7IY2KxcIJ30eWcPTInldxsrVrZeIh2G7IR6BJAQ83JqpTjTcvD467RARxiWa8lNKJZahzTFNMr T1BZiDybHP2l6vl8rnXUde05ENFqs66qal3Xz549s3lKE1LeSEQcDdH2e+9DSE7DhySSJKhmoeuq Kg0YYmh6c4iJTuQMJpxZ4ibc398LR1K0oTtUry3ger2WfBEqZa/X6xCC90F574cPHyTzFxFJuk1B hB8/fpTIbCrJ9rO5zq7Eek9E9TLO9/f3bVN0XBQTjAxBfKZ5MEEbyp1tJ3MBkdymDktHWYcqf7Nf rWMVTksyNER6yJbhenh4WCwWpSsET+gk1r7Ie5K9VmL/yfznFR16AAAgAElEQVRIzKOISAJR3Nzc LJdLCb8hWFItBsRj1jpkyubXBDBtCkLbVLuoYoKVpm0CJmQ7n83KsiyZS2YvVZydnVVVQQSbzcp7 L9oZAJAYoFVVrVYrgHBxcbZ6eJgvqrPzRaNhidxhVoiQgBEbFISNDTlA3BKRASHKJwIH8RCpPSKG ugmqEWqPDOwDAHAIyAChQRs6gMRALKz2CC6hChyJCGIIZDYh1VWwQZPtprXkg1u3J+3KSU+04z5Z sv39rPueT8j2/LMNoOtOr7MdzOEwH5NGYwvEiOAcMYALRBTExwrbfQSJkBlkZyFCMd0PgZE1LoOU qXUpOlF/CiV71m+1A0URABw2cQJLJISARbFcLr280NAcPqFrQmvLHD9gj4xbblpge5Rs+ev1erFY lGVZxMwJlStQLRkGapE9tIgJwyUjmspfoYts6pgPDwzM1V/1KXmkSZaLYnjb7t3r9fqbb77ZbDbq 63B+fi6gUIwFMbo0r+7u5cid+E8AgGQm16+dgdDdWj9s4adtINT2cR04iPanYOz5hRSR5NDkcLKw KaFj8RGBGhyjQfhN45esAVW0Ioz6TomroWFbmBmwRWkCMqxLqqg29KUK7FAnFIjKFI4qFZVwqGAz GP8jlYuI34ogVoomS943SUPUWqKOmamlAeLAMp/Pxe61LMubmxsBvDcvXkieW+m7doHMK8W+SW8H M1kw+lfbA9kk6b3Y1rjvi1ZIERvThhxQO3BREqOR6h1rAh93Iexd+MRV+fnuyjnp3CNjyvNEOshZ PJih2wBg5EBlzxt6Ja/Iagk5ajCHYi1UVUVUYtRItvpiIsCgX4XPKDvSU5mPdh5g4A6aoDhodJ29 E1KrkxMtEaFrImMCwMN6VVXVxvvlcmkLQXMWR8TZrPJ1+rp7BfzJRWs8kdwp7Q8hiOo8abxs4dCF I1bi2/uuFQdAtPFUoxboqqRVZ5TsznqnIjk5AxMROJJtCeLGzcwfPnxg5tVq9eHDh7OzM9kj5Mws G0ETQXU2F6mwGtVZEcPHjx+16p5plPD9fOcWwX4bownZh9aSWXzzAnsA4BAxF7bPDg0oRh/uEENi 521TnUG+VJJJqXuYHe4DOYhmQby7u/Ob+urq6mwx+/777xezuaREur29HYJobOQiDYqnxqYXEVer 1WazETiCMfGj7t96QPnw4YNIqEYaqQaPGMPdK+bTbD1nZ2eykUv5MvsLE02ciCT3m6h75vP5YrE4 OzuT5HDn5+ciW3t4eKjIXVxckLEpsy1JRkDZjV5JdG2WiAF8kFAcINIL0S96z+I6qzEzOEh+beCA UdTBXasOjpIV1s+xvYmlpYvx1gCAGYgIwTkqOWDhgLDYwKYsGKEmLGqsN5sNAnaiu/ABFiWHEAvr OdQObghpZK8YocfJ3FwZgSz7QqvGK+GoSKCzBwOKrTd2ab+SiyzmD8eAcHaXHSB5VtYLAqB9cJgG f+WuKHqoHFmnsomqujxxbhQSEWm1YYE5vt5whOaij+c6gHPyayBfU+2cC0UMT0mE2LCIIqaLg+AR EUJwiEW3OodYe+8AOgGttNvyuHNQljBfWMaCUYEL0JjOEfk1+MsKNhX8QHVRQU0dYQAAALT5TmVN BQBpNbTKHaxrXq99nkoGgMGHgqkKUAW3wKoKdRGCQ6Tg/ephUc3mZYUMxG1AC0QU/QZxa2gv/SUG x6EivP3798uqpOCh3hAhBU/AHEUjBFAjA3tCDhywlfkavVuoOYCvoSgKhIAQEMCHdkro21f1vfja ENGHDx8QcbFYKEAHgHq9ISIRTmstisZCDNUSQtgCOKqq0qBvyQ1qFSGyeujCxjDsWFubmPm9N0Bk +kl0h6QNQ8/a/ex0ToliD7x+uAOAv3Mry1nfm0DgHiAOi+AAUbBJ28i1gTgFOYrORYQKgk6E2al3 uyADGdvcQePh4aGoGmtHqUhKEF2M3EPRz0JyqcSxYma+vr7+85//LOWLMObZs2cvX74UMDufz8VW A2JEL3FUKXEsTFxCVkOs0wyiMAMMs9N7DntLOxNmSjEiEikmxTgEaCLW+L7Eb1/os6ajHE6m1DKl CmXFh+AeJVWX28ITwiiiDsYDy9oc2LaFEFarWhg1xYhhKlsFk+HBbiv6NWCrrFFlChEBqzVl14/B DIJuOr3QzTbV/nQXAkR8c3l5eXd39/bt2xBCXTcmccwsmSZFrhMtEhrAIZT40dze3m4274P473dG kiNYbDwEfYxX4b23cY8S0r7mr2a1WomTLUfCrthYr+fPaoOVjzkbeRYYADTmaTCxWHQ+yJGVox8f RpVK6HPWkweTsPH9gjLuZnCx1ECWWF9vh6csDBVD1VkycQE6asIzMXJqTiI22O/ZcRIo8913382r AhqXixiSa7WGOL1UrqUoW4RgIoEoq0Z6IbNH8CMzf//992dnZ2oWpLxGZpsYdYaYZhaiSWyQYF/Y Nk9ql1nOzAINz8/P379/LzF2yrJcLBaLxaIs3bNnz7766qsQws3Nze3t7fv375fL5WKxuL6+FnUJ RbcXZ8KWF0Uh2sfeUVK1jh5n23UCzQxWBK3MSO7MY4I9AlnOhcb8JWCQtyY+OzKp6rqWxHiC4R65 qU+Bepna42PELzSd7CpLdm4lZRd6JZiQD3ZfaNYvNDHBROqJUdVoz5yigtRgg8KUAIDKVsSrplGI SIVTxaXOqI4gKtNcj3dcbyjiQf/Z+Zn76u2Lq0vJv63RMm5vb+/u7iQSuYjbi6IAKrXL6/V6uVyA wTQzRxT8x48fu9stEEGJAdkhAwEiQ6g9VY3WyyGxD1SQxCKS+ENbN051dcnRhjUp0w+9dmYj4gB7 DxqDRf0MACJisExvTY2JsesmtYBsfx/by+X1S+wXbbS+abEltHPXzoCdrG84Mxbpiph2KMcemlWc cFyK6AFDCALfxKRRiAz4kPERK18xzJHQEeqVKjijLEtxHBI5hOBukXPIa/vhhx/+9re//eUvf5EO aqd0EogVhnbeOSfCEnGXkjs3m83Nzc1sNru6ujo7O3v9+vUPP/wwn88vLy/Pz5cvX758/fr1L37x C4wpUhW9QjTdkovaU/nsumnsh7YcnbiN1rDeeO8h5rpZrVY6fXPhx2GvazeyHSQiUeJYviaiHT2N YYw3bB/8sul+oSnUu5X23pbMrpNKX5TJyPRWNbccbwqTNbTZhyLgEBNOMUrQGMc2KgMYUYdsEB4C mcQrVv0hXE7vV/+46d3fCkfm87lY5YuUQtwALy4uvPcfP378+PGj7kp1aANjahoX3ctns5mIKwQN 2OqsjYX0q6qqu7u7foOBbUQxpqI0Va3Kkt3WbtZ6JREKqO5e3R3izt6mk1WcwTEagmxnEpnawsoY bbaV/WiNiW3DPsIDCw5y3joFPY08roX0DmVCvfDNUmJGcDjpXsgAq9XKIUM3zgRxJ3GMokJN+qrr VlM11nU9m83ev39/dnb28ePH6+vr58+fn5+f//d///eLFy++/fbbu7u7b7755r//+78hczAWcs4F EVQiAMByuRRYUxTF1dXVw8PD+fk5AEhGt6urq3fv3gHAb37zGxFyIPKLFy/khCGcQhQrtnxhIvl4 isI7OTMlIya+VjIUwaRB2azXeuSyHyzg0EJ2fVNbqXfyWKbGmfQODWlAJDZZFo/eyC/0k6LuFErh yHGhhq7ZfPHqYlQxqsIFe2BVwKHQRFmEQAd1MOGoRiFDAAAclElKICJtg9XFuG4esl5uk49ML+Ao o9bDAVXlDABmpdtsNsXyPMyXIQR+zoIbPn78KLG9AeD9Zn1/fy8xD0HjPcZ2ksPAniHoyTyBktWs 1NjHZVXwXRMcmSF4zyMxymxRIoapqkogi26R9mbqZlQZol33aIs8IAotlPUVRRGiukl190PMsMdL BeIw6Zafs12JfQQAPmYgtA/K/AOzQnRcdAraSbBVeN7WHv/H6ElltYx5J6199VH2Ax300GwzsuQs dY7IGNMK67Pe++hcRLe3t3boBL2+ePHi9evXIo348OHDX//614eHhz//+c/v37+31eh+KR1c1zUi ImEI4ezsjJklOMxyuXTOSYTTZ8+evXv3TtxJrq+vf/azn/3P//zPy5cvQ2g8bwX6QEQYSXXJyld9 MBulbPJam2MBM8fwuioMXK/X0AUWj79hJ4JZMMYoQwBCeStH4R808V3qXqj046aksyc9ef9kKeGu j1mjnpcUPVg223B7apxo1GgMAJxzonBUpKKkcUudc4Gb0D5qqS1qlxCacorRrF5bezEiFLFXZBeX zw8PD/JZRB3S/e/u7+7v7zWAlR0cdU8FgPV6LQfIpC5lm+LZRya+5wi7CKFjGy0iHzlGioSj95GE Bek20atYyZGHQkaL6kQFryVYh6OIenLj6AHAMfQ6Q/TqyRuqyjYf082pDi+pxmKR3Geht96JpJhG S+MowCliLjSYAGV2rRT0TYBYBKWHYMjcZyz8UqfTjx8/rtbtcSHEyGDL5fKvf/3rf/3Xf11fX797 9+5Pf/qTLPL1er3ZbJqI4KY9OsIz5+bzeTWflWX59u3b29vbuq7fvn377NkzIjo/P5/P58vl8sWL F1L727dvy7IUB5OiqFQ2KJIM7KaNxaxT4wOV4D82Abtksq5FthHfWi7PYD5+evfxZiMimNNevJkh czjBaNgrrs4WlGOnhOM2/zOg4x7BfwrEmRTN/ij/JYzukA3Yfk024+RIKR/spqhCdfur5cIaqEaL VWPSNhZAPLo0uyA27Fr3s4ZvULTBH3JX3KXLdoRpQOELkZ0Gcm1MP3JQAgDMlmebzeZ+vRLhhzwl dh6zoqzrelaUAgJWq5UYhVjdiihWSnLL2bxercGHoiTwQfTvXHtyhQQTkivUNx0kqJfggyHJvb6p oZ/sVzZyXH1xRczYoLetVis5t+upUp9VKUsOOITyuTqmUhnZtouYY0K+Sg9VwgxZNHgxCxB5izx7 oJ1dr0SIs1hMKhI8OrGVMlm8QSgbkrRQwnWwCaQTQpBwGtWsUMCh1svisnx/f/+Xv/xFwm2hSS1d t+mVGyrLsgn3Jr4kywUR/fa3vxWcTkSXl5fPnz/HqGEVjcnl5aX4m4jvCUDIhZbKWexQj5/+lZIJ o2xLaNMNEjr0eejKrnR0ZYee4UTC4WOsd/k1GBP9L/SFttJTRmmyYEN0joVstSZTXdd4iF4tGJ3z h6oIISRyU2aG1ic0veF0xDFvKnczP3NUHFTAar8lS34+n0uIAXFsYeaHh4cPHz788MMPSeHKNJxz Z2dn6qsyvWsqQ1JJEhuBMZiU9KrP0r0v3wSHjuJWD2X3052MMpVyNrinA0hvWULJfm+vi6hKFF3y 5vTl7Vp7mJaEpQlpckqygMPiRMheqk4LEcPUfg2m5SHGEpZoKkVRfPPNN0VRPHv2TLyzQgjn5+dW 9qDOqwBARfH1119fXF0ioqRiefHixe3t7evXr9HEFU4ak/sb6086bkMMUY8yymJ0r7Wvo67r48kq psirAkAAYPkbxRbBxMlg6Pimc/asPh4aBRkGczMDsFwpSiq9Y3CBCxEshxBqHwAYiTk6RX8BH0+T ntQ2/wlhh54iRq4IjUMHJdkFKUbvyAvpLdxWITGIm8b44KEuXYHc6qux799ID5unECGLjGJvANYg Nq3kFU1SdXCO1cVXTtdFwc6VzCDigfPzH8qyirIB7z0Xzdl7NpshBA5clW4+nyMEX68RCiwdsEcg jPFlxodYdhDltAm/tYd8iHaskJ3wRUbL1nIOmsCVGJ1mmVn9ZtH40IZugLKkAb3UCntGbhrXR0w0 PLEWlKo0yp9N5l8CJvJQd7ZtPBxvoxdCIvXPul1JXlK+UDk6khQx6aK+D+4IMNtVLfeITZAAsvl8 LsYfYm1axyTRqgKEmLPn5cuXz58/f/Hy5dXV1WwxXywWKvN/+fKlzKGh0Y6Dcyin0w6qKYN8Femc 39QafaQzIH0LZmsV0wn7HPSPQir7kSRGYF56LmP70TjNbn0F9oZ81j0dmj4ldEUnjxxxUg2Pav+u D8OAYLS0o9H4kffRBBInpfx1IyJxk/pEdlkxN5ENWANhee/n8/nLly/rmHVyFTrJKIQzq5eibuFT XlyI6dmSwVc9iIIDlbnKnpvzWMt42QR8AgCJ6Ci3uZiMk41tAET9mkAQ770fDMie8oH9JRw5KZjQ EbFNhChQkhgeDw8PyrUxRs2yV6xiqT0mmkHTERwHRkS0OXairxESZCAiLI1Bm96EwYeNvAn91Q6U FdELzefz29vbqqqeP3++Xq9lQlxeXi4Wi6+++urdu3fVfF6WZVE1sbm0nMTsI6+rlybOfgBAE6BG ZrAG1bClJfN7a+H7kc6Z41WhAg/oSDhAhEDIDERYFK4oXAgegOXio823L/QjoASoPXLtIzVubUwI oXCDnvCHtixridrn7ybh0EIABqSkeVPZXnfcPM/MhMDMAZp/DAyE3gcp3QODI8fOI8wL5713XIfU c4SJYL1+mM+rEGpmz0wh1N4DUZNCtk8yVCOy9xvvN2XpmL38837DLF9Fc90mo9ljLqGxQlNtfoIg rbHOFLIzoR9weBPirVfqPl56IpBIMI5EiVAhv7wMjeGt91hlUm9F0w1CH5n7q/VTr8mtkpVNKdKS n+RYLK5iiHh2drZYLCQp8NnZmcT9BIDz8/Pz8/Of//znZ2dnQfBcWZCJvuJMBuHTkeIMtQy1P8E2 P+pd6xr6SVfIY7JsPUyoqbI15/5CluzqzsP9PSblEosvNJ2UpeiRkPpiJuUjbH1V5O0Lp/pcJCLK pYXj5R3ZbDaSMVs5QF3XFQZxXREhqOjTrcmXjWi1lQSL5Cry/J7kSn6bbUPvnSoFKGLGuFQLM/kM qdOjv9Eh5uCQw3pvy2BYtiYjK8OqUEglPBw1QxKWTkRwatWiohFnkgUbIfxYl/b46URkk/VNJ2ul e3Z2dnZ2BgDL5fLq6urZs2ez2ayqqpubm1evXt3e3hKRBAN99eqVc04SF1HRwW1TaMpcUcyrN5up 1uOLpfeISoh7xiGzijCSg0aogAGwY5DRud78ar4CkANmKIAC16hNMjc0ldrPHYvfrNjm5rHxVDGS kI85CHpvbmG0ufLTFIcks/SRByHZIL9AkF1JJ3xRdFy0ku1Av2p0KT0YaCF6Z6+kZ/i9HHHC9Es4 Wn95CMzsABgYEBi4KHoOchsCgM753Ht/h0EyVyQ3SxIT+RD8BgtCCK41IWn2VuMw4gGCc1iWriyd 2IzqP4DQWI3BJDubhEIIEOu2O768UFUYtaMTSX2X8jJ17wbzEvsBR1JEzj2FpRZZLlqINqFCckDX wHMQU4jJKVxNR3MNAkTMkRS+H4UYlv+QQkYKd5jmD9yjHKs/uri4kBigFxcX19fXr1+/ds69ffv2 5cuXFxcXAHB9fS2L9uzsTAYTxQn5eDzTKrkSVKv3MLP3jfdasnHm0o6TkpUEilwnbHNz1wflw95N ldkrU12kViLhqzejwpi4yZHxEvyRUe8uPiR1e3zglfPQEU6d8M2JTZ1y2zDwegw9S2/JW6sTZiUs 3bkGZyj7wm7WSYhoQ/6qTYBzDl3zoIUjHFNXTmnJHrTHS5nYEjG2s1fKsvTgE89eGTorFpKdOxFa iBg7yWUmrCYx0QAT0HOPcRPJgqCV3LFFeJREbUhsKzkarvGslc3bG/K6tttwWBDaK3uxwWtVm6BX RNSMiBIF3GII/QkRk9wZum1kkLl/HDlz0NJGql3P1p5OJGtBLeQ5EJHoF2sOI+fh3tzRKmGTWYiI z549+/3vf/+rX/3q5cuX4oRyeXmpoS31waqqROzRlr/7qRGxRwGaq0WgI9VgiPbPLtpwKECxUc4m GkPt2ubhjjQlCJzlAWtii6KmUS6P0SugX4uCqqrwflNVxWbDFL3pQxYrCQAoLpYfMemEsZPWevkn dDj4OwUd0pjeI/vIzY8sZdlanQ2kpF9lX5RjJBEx1HYL4KhrUN2/3CZ/KUZsQsTZbBawRqNwV+GH 3XTgeDoXZpFcHqWwfirKFEwvqY2QmXSEGBBAI3AQA8aIZwEBmNdd60OxThV5qiJgK16ymK+pYtho vc9MJCQ/YQyj0vuIBoUTa0XFoEkbILICRNwOOEJ0wrZ6qaEWKIllqMgzqqrSUUs6Lz+J/sVe574g EDuRFCspRY5uNGqPO4ewCfFrFUvgs7MzRHzz5s1XX311fX3961//+t27d3d3d2dnZ9fX18mDZGLr 5pRII8f73vurnjAs2tAPHLNXyxX1/+ZolZIrWZKvJyWMdhXctZJJGnDEI7Vd56JeRUQOJPHNNOUB d3yUOkFyj9KMJ05J90dodEGdcBbJLKUYxi2RakAm55hS4B7367dHxh+9RDEFI0WvBBVIyPZJ1JwM NUS34hK5olBDj0yIKME9A5LFKJBtVBB9CD5F11s6pAEYTSGHCpFzkQT1wZjByoewXq/ZSBqUS2hM Jv0slg/j9oL2q+ZP0TMhMyO1kGU2m8lFkab0QpZGLiLZs7kxgRBRt5ik9PZ3UKUiR1WdBPZ5iXGb hwxPKlitVhJSArtONbYcaXTSpRDz5w4N31bimPA9hJDEoz0R9doV99yGjV4QAQhAcMbNzc3z588X iwUR/fKXv/zqq68kkIaEOa+qKscWMpj2YJG8W9uYPcQMvWTDlPUWyFmA0ebv7kIOZsa+nWniylfR GvQFvdkZagzE4WglHNEoBInJQVk52ASJKC/ITDB6MH5r2g9dGk/qWH8iOvwQf0Sl4WAV21Qtjy+K mE6naBjGzEEqeFbxBgAUJVrtAEYduso5FG2QIatDUZtEiy3sh4y1RqeRJ0a9g2+lBfa6skfZ7+7v 70Uj00R3RNhsNhxv896LFIFirl3F7ol4AybwN28SwOpbgIYrocAXW4icl/LgkCHmWGVsEtZL7RIU u3eZjEk4hrKQEJGol7ZObo1jbUvTIGsQtQntzmQ6k+vDptN6vQ4hSL2SpP6k3JxNJpshZiQvzN4w n88Xi8WbN29+8YtfvHnzRgxCz8/Pb25uNLa/5JXVF5nM3d6KduU42KdS6bUDUiCY/5Tz6K31CqQY v2FrIUOk/EtejYsZfPYreeK5PKlaEuBZ1N5gjkb31EHqP27AYRfFk+2mFcAkqzj/PHTKsoRG7n2i Nh+d8qZijJusf5X5RIjQkXnIddlvNL+0aklUq2IpqVofebxuH5uSYbTdzO9RJLFerzU9ExYOTZYu sQyTDV42X8naKr/mGyiY/cKYnbZ6BhXmqeSVGgVZz86SWEpoUah6Ydfe1ttZfarjvJo3+kDi6KcA ESYjItcSPhYAGg0WNzHk49R0xWq1QoAC820vbx7qVY6VIvNmtbr/+JEA/GYTNrUErtd/e3RyhGdM XBuICBCca7af58+fA8DNzc1vf/vbV69eVVXlnJOkJ7K2F4uFdaDC0fwmIzSixoPmjfdji/zOIcFG cqFbIAOyucgADCwOIHpz5x9BCBy4DffJJhhGShj1fbYZdtKr+okjDckeGeO/+FnqVA47ZXVgtAjz 6OqanSvqurUP9d6HZjk83a338SmcckeePs5Ddw5J2sbXIDPXHACgmHb/lOYdEbvkO/3QT9T1w9SL UVbRPtXIPBpNCjrXKPUVaijacI6co4DK0HIulJi/mF8xAGLPvydAyYtGRIeEXSFNa88e7Bk7AKKH upE6cGuz702GbWaezWaSnlNIrjvnJCaYXCMCRAYIm83KOLAANPhGQyqDfiaCEGpXVADgvWXIDdxR d18RHhMVAJ2Nb2T56ID0R8vAafFKE/w+tBuJ/kXD1LOx5OCYz2y8oj1I2y8R304a7ZGjSp6IGPs3 M+fcYrEIod5sNi9fvry6ulrMZkT0s5/9bLFYvHz58u7u7urq6vLyEszpgYzt93Rd5lEOB2qNgcYm NKcEXE+ZNkO067MWAVhQlY8SEUlseLlfjwvTK4LJsENuK4qioFlVVaIuBaC6rkXBufXZkX3lM8Uo j3nQ30PYNqWcnHSRbi3EpprqxfED5W9v5AhWmHj/RLIWoGhizyAiUtChUAkHABSFo67HuIr6IMo8 8tHbr4XJYWO/Pu5NCT7TEWg6SG32+dz1T0kBREGIiFy3Zl4+en1KgaJwt54ZNouKXhf3ls1ms16v yUT3xgnm6iFmY9Er2n6M8TKSxo/gV0upSkXjNOuojeg1KEopmpqyGxAAAwMHsb8NmxoRGQmNm6/8 p2r+EHwIARlYkvNOkM03JcS/wQdkQIZQe/kbvOcQkAmZkAEZp6v/WqkW9/WQCQE0ep2eYtWAQH2D AcJ8XgFUkjjtX/7lX/7hH/7hP//zP//1X//17u4OiIqqoqJAG/HMOQ0BIYLLocHAqNvu7VY2vZKv /TBRJQHWEiJfJAHZQ2BgBg4QAjKa8pEBQWQVXQmHhLjg+LV1/eDYwoDACDYYBttfAYJAeERAZCIQ B922amTmIMMWE6mEKFdoHieyg8MG+CfCFTD12g9sHmwqlUUdQgDyEEPOSFOJgBmQBFcdR2L8aQFI z4Iwn63cwh5BD7LDGO3wOEo4IlwbP2UpBTkgyp3AyAF7DK7SMuNXQASScUMAaEx/qIvesqcGy59A nHxQfxHnCLERXegVIgQANcYgQiJQUw3nsCgcIpdlgdRqVaDdmHukGtTUS5ZNEYDKMaR1MiT6D0a3 ocPJltkzvNy5jRCBQX1S2OzNZJKJ9qqtRezBwLJIfDwgNWyKWTwMVGqrpvoy5o06Blkic4hsw/uN b/I6iaA3RPBQExVyWwh1CYEIJFQ4Qu0oSKQQkfn6Tc1FSc4hAPsgw4AcIdHkKddvw2HH1GZZ25tE xtCg2u6Sw8w0QalXsD+d5HVqFo+6Pm1KCz37qmpNZFDivHpxcfbmzZvLy0si+u1vf/u73/0uhPDv //7vdV2fn5+ryfGQlcaBsL07s7czZetmwl1KSjuKbMjg190AACAASURBVOMoZIeo90iN2PEly2/o vbJfMzCmpxfzETQ0pOHqtH+48J+CkONYfTz1WE0ov+21iniTOyxEGBof7tiXdG47+oHeFihSGbFb F7Zmz+6NHahrJBwiBVFXFOdQvzZMP1uPp4AHe7/0447klNJ6XQ3EpIMRnHMB0+MiEd3c3NgrdV3f 3d3N53PNWKvXMQqnrWzJmXxsaMxuJLB1MGakCQyQAqmLn/KpSDHUde8IdACHTiZ7q3q/bBu9MeIY IQQAKJqlqBElxdgvySOH1AgAq9Wqruvb21sODlu3FwLYuy+hgdpdtaJFCWVVGdevoizLV69enZ2d PX/+/N27d7PZ7Oc///nr16/LslwsFgAg8g/xj5VksEN74T7NPcA/JUEbvVcAADioOGR6XT1nm70I Mx90MPI5q3BJwKuuDYijlDySVLFTe6RkHxgRAD25gOSRvHMYAhOwmKcgckCQRIISI5WZgXuiROf0 mcIOS4+MBo4IiC1y3enBZPMYeVyr6GtxOo2nN2O8RvsjIpZlKQoRMS9TuAwGcCBidEMh1xImUTcA ewKfnwhwfFra6Y1YDUiCPFDifvpAEtspUiFSE8OHRVErYa4wKsF1qvdi2RzlhBBQYmKZjiiTFAyA 0Y0WoJV1RUVbB9CMjEBhAxWMDNPAWu3oosYft/uBfFDElJ+b9RF7cdd1xcx1XT88PDiaHf0coKSb loup9t69e1cUxWw2Wyxmy+Xy5cuXi8Xi6urqzZs3zrnr6+vz83PqBtKQhT3+qqbT4XEdhiQZnOdm 40kBPU9Evay/d70lX3XOUwyGwUaN2JYTT6h7dDBOwqYWIgJulmgIoRXDdpsk949Ulq+jz4jsJrpf +6esjl5J9REBB0evtPHbEgScN2wIWSYXdek1+8QuOpRkPm8bvXbVKFZIPtiFIyCjKJqvIqAty9K5 jokoACD1iBJ/HIAjP8aomUtyvfcwE2J6kPRX5tY31cg5bHUck7OoIYRc1y1JLHbn87lE99ZWWX/J EGNvCmvCWLKtK4RQFkXSQowiA61xyC7HUisnGYLth4s3dHSahkL/csrh/5SjXk5ENJ/PBfE9PDwo o4nlW+37FBrkCLJiZrOZ2L0KgFgsZldXFy9evJDA5Ofn569evSIiSb0mgcmXy6Utyua6O4q9p9Ku TDaXZIBh1rY0I+HoAYunoKEqeiE8ZOw1+dXFFGshpjjWR7ArNdm/a7iWhiN5InYOEEPBjOR82Eii yUYlzawu8TBt2g/d85RRSDt5PlG9xy3zKGcYWVNkQo1hjO09VGlStU7a/H5lJkM667wGW6azIgtE jAEzLAQpy9IVgtTZOXSOioI0RIfKNoZxVX97jjK2p6NexmLl9LbL9ubpR0EFIgCAgTGwVa/YCW09 MOyzzjnRhWGmPbDwUV8um6DeQwgpuYhRj4bF1FCwhW4q4td7CBfrRXAT23FEWq/Xl5eX5+fnEA04 TkeIeHl5eXd3J+/47OxMomu8fPny1atXV1dXFxcXz58/FyB5fX19dnZ2e3srr98q8Kxs48BB25W9 Dt2/dbYJRkTIIMhjUYIGaDj5U47NycRPVMwhJVgd51EOYHr+kxrrmkMItWfvPWJ7ygkBWOQbuN3H b2iSJJ19yvhjP9ppp/9cuh+68XDzDvZe1F2tPf/0gWy9PhKbWOvR+0V6IQ7eijOs3EKASFVVCjgo BgTTHW42m2H3AKW7Y9w7JwGOx9lHpkjTdTBjlNVJfqFD9yQQoXMbdq4zczBXUlPbiBXs6V08mReL hZy67f0qXyfjxqw/2c4ONc97Lw/1IuMRKm5vb0X+75xbr9dJmpmdSGMcwSeCGlqpRDgFAAmlwqGZ IlF81NgA85jouocIARpfCakInSuuri6+/vqdlF8Uxfny7PXr12/fvn3z5s3Zxfl8Phej0YeHB1cW nkM5q0Q/52J2PlcWWnRrdd0lHpc+HnuwnwKnHjLzaI2nofPX3s/mNvlVXzVmkrwhRKLh/LYSmcD/ tpBWqkeekJGYHBIVzCGsaiKqOfU6xsMABxg5rb3tKbzQY9EhqpHHGYc9uN+BIpMcaqixxUTAgYhI wZ58xPCTCIuyMdcoS6emowI4ZrMK0atIQ8FKURSATK4j/4eud+jnSBiVJvlGm9hmDpGVIm8ljhLQ 9grYz23VNvaoXJSIkaK+t1IQSTZipV/23BsMKEzNSjB9m/n1rVSIDKCua9kaV6uVFfjvSjqTdgU+ RyHsc3ghIob27BtRP/cGusyHDoGTXzU/DRGdL8+eP3/+y1/+8u3bt9fX15eXl4vZXIKUV1UllsYy FPP5XFajPq40MWzrFLLdnM5bc9Vyvip21c48NRo6IKouz+IPZbgQ2jxwQ2VOH5b8JEoxtB0i7qRq GK866ewhm9ln/dKVPvfZO5HQROuRv8aRNZ0APSwa2Srj0ehQbPgNPRaL0YZNO2/DIieZKnfiSDtR wttPR2jUSVPu3wlbbC2qKc100QIOW6N8kG1FxVQWiNiSVdqBRBMXySHjXOg8UC8azZOiP40Hfer9 au0SHpPkrCm1z+fzjx8/zmYzXyOahLTRUzHL+gqAnI0mxh8Aqqoqy/Lq6ur29rau68vLy3lZ/exn P1O0MZvNlsulGJGUZQkxhq9dqEn5dp/bu9f5kts6c+zUTGx0NN1rfvOJaIQZsfmH2VMTuZhlt7r7 qo+iHA5ysQciAvYz6125py0keC5LV9eemSEgAEav2fYUuDUWLqrNV99rOjXnbZvxONUcRiNsKv86 kXRT32borTvTlKFSMebOTbITzPKcRFdr29n9yoiI1Inopdp9kd1qsXJFfFgAgIix9VZwrRGD2ZSP ItJITlNsEkrAsNZpYuFHWTKqluU0yXnz63S2HL8DQBOQWX6Q2FeiXsH4iBxWkoOiRB3U7Guc2/sD QAziQESukNgnpJlWtNk7DcJQvxoELF8k84pADUm35kz6if2q3Dq4p2CLkvlGYqstFovNZrNYLLBw qu6x0u+kgdoceQfOOSkNAACDGP1eXFzM5/PXr18DwHK5nJfV119//fbt2+VyeXZ2dnl5idETAbHZ rKzi89SDMI17dnC3RsyVrzlYhk96QByvesro9YKDHJlhNJuyCnXAQXUJDIx2b3W2EJlRkmyCQpuN ORYoVafcqreuhMme4h2d7mD6aakF3PvZsMpOsK9h+ykoBxOY+UrY691mC+BooIMgDHXvt1INxR+a VEUjfaVg/fTGwYmv+9Z3MfLrlPc4vtYwiksTtVGA9i2caCcdaa28mkFfGONgIm9Qohx0DkiGcvH8 9JYItUIIySxVVZX4XNiwIXvUAdGk4/FXIxHVdS35zwQzkQMfPYktlpIo5GrJwQxVWQLAYrG4vb1d LBbz+VygxtnZ2XK5fPv6zVdffSViDAAoy7Ik9+tf//r58+cSGKcoioIcRMGXfeW9Q3GCwdnysqxg Y+inKY8/Mp10Funq0v1DzX2gm/GkBSIAMMx0RuAIACCxI5zjLIQgsegKX9R1vao9EXFAZmbwQRMu mKrzK3nzptDniyHG2z0kljt6fxl2CVd8ekrQhkgpVFVvcYbVuVgJBxEhsZp8inREvf3RiEw0WnlU oNQiz2hMj5B7DdH05HBIcCAtauJUzxH5fg9CtvZzCiZzgr3u+TjTT7apoSi9HfAoVxAlWpe8OO1R yNJOKdPz3iMQMjtEh6ipx/x6s+HU1WWwnaMj3Eg49Kbb29uLi4u7uzsFsI9Gvcgm6eR4k2Qci6IQ pCmAg4iYgYiCh/l8Xte1mK1sNpucfV1dXQHA69evHx4eRC3iCiyK4uLi4ve///3l+cWbN29s0L3z xfL8/NzaEDkk6E4Le7DYeVCORAnO2E96cZxl02yTRyhn4qFkYrPtO2o/Y3odRifhOBaRD2Is7Khg ZvKAiJvNBhGZXF3X3OTj7engVoHKUMO2FvL54o8h+oQyOduGkfmQ04H8gWJuZGrCYxRgZixGNSIY TZD+JHlPAINCDX3QqtejDoXEyUDPuxgtNqZ0gWNC9kM6m8D6ITg+csMQ9d5pL+ZsZ+QUB30668ck fdds1Mf2BpW+RHE+J1OFmRV6cnTh1tP7rltbETP7OeVcksw+ibq63/zQ7W0rUBjaGPbjGhSjytc1 A0BBrl5vXBOjd3l3d3d3xwjh/PklADBACOH7778HgBfXzxDx//1//m8BHIh4c3Mzn8/fvn17c3Nz e3srwUCLonj27BkA3H24tXkUAVIMQ8OGvp+cPjlHlkTBTSsYIH6eIlKTWX4UgTaaRPYAHR2HcBi1 9pDDAXUdWCwKUaHlqFxQ48HIwQKZSZT9BRYPmxqZMbRlJuzM8r69+47TsjN+RpQg6RxY/ygp7+Bs NiPjtmrtxhIbMvkgbolyrZo1ogvn2mzyuqPI3JaDaFEQAEuYKJb8J7hFYSEfRI4O22Zv0q/eO5NT U3IYyA/xQ+WMFJuXJgtf86FMgfinIGvJMU4it7D4cnDcArMPjK01p96AiMwQQhD+6IqiKop5Wc2K ssAew8SRdVeILSt0XWsgOyJ8qp2y0YlMswqmJk15A6IBgGIMf4FQ0ovLy8sXL17IEwDAALPZ7He/ +91yufy/fv3L6+tr59zNzc3Dw4PkbhUR4uXlpYAMIRkcESrawcHOfy117vlEg3lSIfM4bT1k71qa 5SDJxgyZVMki8Lx2a2BheSsiMgRB3jJ/1N4FEcXTXZPO6PXpvdO6yJi+z2YzSV1ksyhL4VYFa+va aTrtATV26tTToZE2P1p3Rio6LhOw+mLozn+1/bTXXROVXA+cBAAxogZCn3uLTlEbwkGmMEYJR+/U UiN0RRvHpSFJUu/FKeXkD8oHK27/VDx8D1IJh0op5Lo9WQmX22w2jIQmSbiVdUHMB+ScWywW89l8 D1/UooghS2UaSfgKOMaaFDMTy75Hbraj0HuDsaobpKqqJCcvANR1/fHjx5/97N18Pr//eCd58xB5 sZiJiuTm5ubZs2ez2awsy+fPnwOAoJD5fO6cm81mr17d6IBWVSV58kx75CWBJAKVi2Z5HhIwdGhN 7s/3E6jxydEGtemB9yxNQUbCE/NKt+6XtoTE4AtjwC6pSH7V803CoXZTTqPkdQTEgMTkGBAcEHnv kFdMQ+64CjL2k3B8jtBhb/r0neURPpCbOVBzERmApkn6WqIYtg6iID2JeqkKEUUbGGUYReEAQNKw kYk6rZI/nXX52W98EirakO1gpx7tRDnU6IXj46GXFGgkT2k8jIkrTk8IEKUR2Q1DD/ZctPoYa8kh JYuQuFfaYV+WoA0rvUgcrNgYeejjops7OztbrdoYXVVVLRYLR61cf8qwNDAjuXs2m1k/hQNxnCZI 3Io2dIofIlaxE/rh4eHDhw9ff/313d0dBJ7P5999953YUl1eXl5fX7979+7Vq1eSQQ0Anj17dnV1 pSWIY63oKcUE1W5gyu7tXjVOhw/mgZQcl/Prj0PTR6yX8taOlDa9omTVtQ9iq3DBaIWuJqUislZx 2t5IjprEV433yv39fVE4rVFIg4WoPvgL2phIP6le68HUuplYuYWVcBhTj/ZZLQeNImY/0nVxuKHo OCXYYqyugV9GMMoIhb50r70XPwnZjqjfcvI60kOa+arbZVmWAChiVyJaLpdFUVhDxd0AR/KMlZMk ItzxEocArH0BO3HJXeeoRNogakb26urq5uZms9nULzZE9Ktf/Wo+n5+fn19cXFxcXFxfX8/n8+Vy +fDwIF4nRVEIvIAYL0WK1aOAdkE/l/R48c0OWbH21ex6zjg1v94qgZhYSO/F/PpQdYmYpGFA0Bzv rNIE4smPjTnYvigqIDJBoAICeAAIAeaLYr0p5TiiKhuISk/9+pPaR39qxMxqvrcTachtNOqVRD+C xg9lesm9O+uU8yT0YY64DPvn8H6r6ZBD3cRnk0Un2k975RQRL0WScSy7014xlf4EiGpZUZbl+fm5 c+XZ2ZkYKoh9Z3O3kd5p1GwY4Es6SoOxueyhSg95O3WMowmqygPGvWSpL+CBUNeOb5CwcWhkAJjN Zs+ePZvP50VRzKsZAJyfn0uik8ViURTF7e1tGWm5XLZuJjELAHQ3od4NiY4ntDiWCKT3NX3CzQm7 pgZDm73KjaaU2TtVUtmpIQATJCc7yvAE2wttHkdXe0EbOhm0QL0iZKOKjZScROmQmL9VVWmNzKzq TjzYWvanAFY4ywd5olrGfx55MD1cmp+YGREEWiY/weh770SRMTp4MJMzD1YWWev24bJTXfseQsh1 FYnpxiFTLq8xb5XemawLTiw8uP/B6c0QknNpznPg2Ak4PyGJAbJzpZxxbNww5pjcRb66HgWFAgBb 5lgwUMuIdSjtGpYKrcFdssLt4WwK9BsPkDLlRRI1us+qKt+9+woA5vP5oqy+++47iRNaVRUhOITF rJKYr1W1gCZPSk5RcwlMmkpR/2HHqgMAGJQdZHhUpFVRdtm5biobWgAMnfDbo9QxdIq1cH6DuTBY 7AQ2oW9KxqrJBmxFdsnJxj7cy3O3gQ+O//LPtmQgQiKUqYRN0JWGlYvmM372bVHoAaD5CwyOAYC7 cx6BCYFK5x82gAGYAQNgAA4cgsASJCZAAAhNA7n31ZGuLwBqFrDceV8WNXCD8r33ax+QagyBSGQe obET6hS7ZcPQjgN7M27p0PU/2Hu9+xxzN3pv31ORJQCPMp/hlhwP4h8WmYqBmTtrLd/2tlRhQSq2 +ZIwSjggvpitvdbITnZdRH7TtEG1K/JTPP1x+7hT/xHhtKLRbx73XgxEpJUS4RbrOjQJU7hpZ7IT i+lGvpbHEXPya7KZjfCQkduaX5NrfdOVc4bYbb72qInnZGDckQlbzkZ2DO1HZmZ23I7SeluOsN6B l6WLHORfQUglVmV1tqyk2I8fP0o+EEkz2VQX0HtfFQAg57HmJ2EFzOyhBgCCWrhTu+bzOZG8MA1J 1l5hgAwcjOwuA51vD4VgTGqTqvPYWXnhyeESVVVJ7uXLl/qTdEGsN8YLtB2fSEnLj8Uf9xMvHauW Aw/EPZhjWNoxscApMgn5ICjZhmmaLh5IBBhCas5JMSypTrbOUYy4rX2CDRMSqkyRRB7OrZOtzNsQ ox0g4hGFFHvPUvvYT0FqktCBcqajNEA+hBAk9eZms1FvWMgUhVvLgSiT6GX+luQeRPShJ4y3bn5D nik4qlKB4emU9yhBe7aEE70d9YcYaip2VfBbG3bctbNvr1uGycZGXiiEsFwuNxsvtr/aYF8zEdWu eddJiXqbiioOOmRg96tCm5E3MVSgwg6hJISqxRDJxbwodTJMtCRJ+41b1+DrGYfSe9DWNXDIHtxb wsQCFbEepTHaHjTsoHPy6CoFeIJSw5acAI6RZ828GRS05kWNvyNbu51LbFLbMzMVjeusWIaPBP+J 3bdsXavA4KGqKtx4DMwBIOKPw3nU4fNZn/8Joo2c7JSIAzKmShspKoRAtEXCIdPGpgldr9cSaDyp YuKLVuGEXQJy0uu9M6pm0hDjELs/oknZOj5DxFmakqHlvxWRDDRpCz/ZOtU/LQY9nLBPYBMxlpy1 Oh303m/qDQAUrrGgV+VLzcERhhAQWD4cIb+asNSkuVPIrge1ph66WQ2qhRLr697CW/DRzUyRPGv/ 5g3rbfATpES6+wmpy3DbK0pD8uftxRoRdI45RhozdAWNxzkY3GPvGeFlGG2b7IGA1XTAxC2IECEK G7sdb/5S2ww7Y5lQFjkzB0BEFASDCMwcjGB/J5o4mT/5dHr6lEz1rXNyp2KlrI7jA7Y3aF3CG5n5 4eFBwsYkQgswcrLehtV1jdSG5OIYtHRkAjRWGtCGP7clT3Pd2lMQO2Vsk9MvPG0G/nRI3qOdQkaO 2yiik0dmrs0Pp9OGY5g4+amu67quHy+ha6/cSWFBEgUvocSmWiGYneK9W4tQr4QjARz5s0Md2XvW Hi7iGynhk28M7YuwVwdsuPZoKw7Ygoy8R7ujW8sSC4lk+ql8WB+xQpfeLthmJF/jegPoCtKsywl0 /d1N6QbrIAFAiH1nphCIoDEDlDOHyDh1VIZG75NPj6dGBxpwTKpiwHBn+uMAEEwAXJ0nyS6uuJmI AHC9XkvuhWTHtUi3V9OB7CGb3iMMpykQRZberzeBgbl3FDRmyzlFLVvbkO8+n8RiFCeLh8cKMZ8b ZwgdPWZv7Y2gnYdinYnBF0UhaEONhaVJ4p6tk2074JA6pCw1sGjYKAB07aJzwxnsBr/Ti03HDA3V nsfOSygpM2k5TnBv2YMmTuWJ0rzp9HR2DhlYzBi3jLWaU52owSNgMblnvzL1xSUfesu3OMMEDUPl +Bo6zD5u9S/tVTYMtAHWjeCEmQGormugAAAhhLqugdxms3kEd4xxOt2LTujpzP9eOpZ4w5YWuglI a64tQ1OgzI3/FMppcrVaccx8Ye/MGbJiYoZVwpnlgzpjU3/k/kHlyPjL2nuIchQ1gooOrGuE8jKT M/DIg098GiddMNuoTLyGIymTV2fsBHNAZFxqnbaDhMM+1ky4OGjqy5c/NWQxZ0UaQ4BDrTGomyqm OwQ9Y6TFTnn943TcmboVfxx9Ih6l/Zgd/Vsult3cONhF9e0nX10HNmBkAHPAYcE3c7tShBM1EGGg nHheBAAAljaLakY8CMABhgBl6agsmg1gg5vaSxCyEAJ0DWP37vLehIiPIDn4LCiO/242HN2nWoEE xxCiABC4E7VJFXlWgPHw8FDXdZJEw1KuWHHOAa5tmcLPQwiz2UzKtxuJYQLcztVppPwkZ9rTyc7w HM1bRILT9FxbG2PXqXVu0MEcj/swVNTToaFWNebwiBp7g5kZOIhLS0yYyibPlKINNUGVebWzSqWz x0+4P0k1An2yiiHAIb9qCSOCilMA2CNWMYIzkrd7rClo19tRCtRik0mZJ+lG0wCcZoo1vZ17dOfw udHbcgUWYOKAgYXjgPZQKLlRxODJlmZhnC0+qU5WsihWCVC9DQMLOxCgc5KXPpGOiyyfGi/+tMTR c4QojZRtz5GIKLNLPqxWK2GtwkKt5jpnywDgiubAijHwOQCUZfnw8IAxLCkianr6Xng0sTv5tM9B Qy9NXM5bj3b7kT16JYAJPp0+xX49fOF0X25DDXLl1mTN6vgU9QKA6FYs/LVT9AheKvn18Z4QtqkI rfSitxCd90NtgC7rP5BsUacDMeNz4sAZcyLs3HOAEBdNg3mbn6wUJHBywjiodjNJkj3bsrBDKhqp PTkkCR/njMxAtTCfo3A75oBuS0ulhvFRbJWWzSXnXPAAABQzNDKzC2LcJwZ6nxhwQBdifkL65Dqm E5EcNIf2Zu7RdzQGcJYw85mSOVn7DRqJsqR3sBNVU1V0t/MdAIdttq6OvC978N6JeGUK5UjCXtcs 7Wz0pwcG4TguWN+7Db2fkyshcHzrrCzKxVNmwwMJOcYFqYpmZPYHHNOb3ttuC7c12n9y27g2pBcW nFTIcXjhuhtx5taV3HZ4RTu39hhTPd+VFXbs1ynL1JpOjc4H6iZT3aPGIcrFGFaZnaANZm6MpIxb iuWtKn6EqKa0hXQrtSyAEJEJmdkDCvenGMGaY1AQ24ytPdqJpgwpIlozYfn/6Jx0pMBT5+w4Eelc 6t3Cd31ZCeAQLCtcl7vhcc0uEhARQm2PghK3255iLdQgoug2uB1wWDEGZPurvTjO83vJrvqec9Gx CU0C3pHy99iYerqPnZ8mrsHTi/sBrOlP3NGSl2tZpdKpAEeOCbR9kjHeoo1eXDJ95u0xR49y/x60 dd4chV12zx9THui/PFTCTo1MeM3Wm/PGjy/dnHsm7UyK2nWEEyCVVErd5G3SjMYJtvt4bzuZWXxc dYkmsMP2BhGAUBQpEuqRCIrCheARC8khkDe1lxIpy3j3VQaTNqjv8e5ob79/nHZ9ZHj0frSkXR6K 5iyzURBq8pNdWc65xGqk0dnFt6+TU126GnFdM9MHRUp20Q2dQBK0Ye+fPBKfH9kFO8KaLFccmd46 VnTYEmBu/vXXAlGMAYCAgMjAm8baDCS6qP4NIbCEMEXwPgDuFfhrK1n0l+wWiLlbw2dJI2D8CyWk 3MTykd7Ph1eUfE1m3fR68zOZ/ZrckxeFfeaTmLlxee9F4GHDNylb7z4vdbVAgWPwj6IoJKnSer2Z 0rtjzdsc4h13s98DbRyx9s+IOOb3ES+V/Ff5oFA44cyg51QXfReLQvQpii0SYE1EgjaYGVA44daw +pigimT5JND8KHR0Lj1yEj5K4dmlMf4zWMjjLgREHDqz5s0+FeBQeUZ+sMtf1xPZvHcWDBxQy36/ TqGhnfKRCaNGH+J8sHvqCWs0sbwoxtN1zrHvSVZpJ2evDEMo4Ya9mEM/994zxKcwpry3gkcNnBx6 zuvcNDlIXeS5RuKiJGau69YgHCbypgl00re2Kz2RZjwpUhwggCPX2CpcGNnyQwjENRjnRpG9SbRc NqQxPxpyPcB6ZGpZqXYvyDj6dnB4gTlE+1Q05Xi2bzu3Y5qhnyRZbHMQas52cgW8FyTKmORSOQrp i0ksMxLflqfw5j4hnZRpJtLISWLzSf5G5n4peZqoarr0/kDqZV4tpIgmDjoVrapbDSDsU/q5Da0x bKdC0fvcPN4iDxqI2IjR2JsjtlCtubD2/kfEZo1YDaFCzN2lwg8Y4E27Lr18M9jp8f1IR+MLbSUL UokoiQJp934d0vwo0vyE7Tz33osLt5QvgjRVr6CxYyhKTOrCvtBH+queAfQ6dOfVE0Eb/WwkOzyc ei/rPeGMr2t8wrh8f8AxBmKnPX7A06elTyhxOcpE2XUNPxoaeHyyZ7ikDbqvWxuF3nY650YyoegN vbwAjf51SlPRyGaom5y5bTk2x4cQAhEwN/c7RwANorLe8FtrH58Avc8+GvL4JPU+fVJBWjrBmINJ YUrOYaNbb7BDWwQiJnGMhO9xzIdR1/IBxJ1bOGD/agAAIABJREFU4z0iImKIQazVZwqJGJo0hBDS VYCJbDswIDC1lk8nlcjuBGhyYDHERj4JW+s9SCQ3yIdHWyziq83mb2yAvYh8dKPREa49dPNTo0dA G6eeB4MnmD7au7PNu4ZJFhhb7znimCQcQc5nGFmzPefZgcrPLnmZ2FU2Q3fx2wi+Q+2xlNSefJU7 +pmLnBS9x+iiIsfFsnREVNfeWopMHNg95bSPIqubeP2nSUP8SmVdQzgYRrdhBeLq4SKaFA3gIbPd gp5xzpkwJQuYRnqxKw3NjYQZjtSVc4NPDjJyJrDTOJ+0bdNJZMB7Ao4h3jzOr5vP+1X5hXakiafb cdJnrSZi6BA/vUn59fEShs76SSNzUl4Jfc3OHx8qytqg5LVzHzLYyhT0NluCWOrpfb2VyimUHBRA ASRMtS8KqjfAzGXZxrZp44Nti0sxxKGS6wkw+hJX9CnQkNpLUcLemjV5UH2wNQgHdm1B9mvzUPt3 fdxSUo4GpxoXnwyta4s5Jj51IhpahgN3DnL+x8cfKnCV9hxfwjGFfT9N2cZPk5h7do2RF2SNFez9 Q1NZWJ7GnrN/tQEKOEaQx7Y11n9dzfK572Yrzh2fk/mvVkvN0fxiSqugy/5sv2wHiQhiMOkhIqKy bEJxbDYbIok62mZ3tNYh473bCZ4mNz+dU9QXOiLpa12tVovFQkPl5vYZjyAVPin1YfqhM/VnQNNP gKeo1/IEbYnCvj0BB3ErqFBeLnMRo6QduHVSkHua94cHiPGhkTOrYrJVDWYYFs3fERqC/5/7KjoW 9YQp68v2Oo45oGuzZg/cCeCALuywR+opayg/qVOT+GqQfait5RSZxFA30dDW0obECXkVvdURAzPE jNFM6ACAQx3qUBbkPbMjYELgEAIHAAQk5FEZx8jYcvcGln+NmWF6sO6eN/oLRHnFY83plPkEaVc7 671ITP/BcDKUd9m2ov1Ao+9wT7LGyCItEAS8a2DNEV76admsgv7knHzMJm3nW5x9OLjOYwV3jrRF Ah2nYlDGFVXtJB+EWzAUDw8PzjmJwbV349RieWgi2tZPqSifhSPzdfwGGIUUvQ9adKa/2tDxPxHi rj3Xrs/KPEtUMGy8+fU2Ffvrnfae8QZIC8dVBhhtHbSovYXMuVgiIWXKUwBHb0smtoq6sVyXy2VZ 8GazqevW16Cu67bjO+7fycpKBjlh0G3Jpr3N+cKsIHvzyJ6dtPPpwA5t8+dyFOGuN+zezda1KeFH JadPVVUhhMQvRuu1X5/scGF0qOzdobaeHB6HhljWOCU8avrjvWLLXo5nRqZzuutts3wuXAAIHhld kTsytf8IgAgxAOl1U6tQ7368x9vSR/Jnm8xFzKZtaCUZ2L0ZsT/O2E4CZDAmTrt24fOgHIPHEzig BPZpLo+MQK9ewF5RSMGRRXFGenG8rraZZqqMgxLuuqUoC1aeshVaoREP5jmQE4iMiCMb6lbAIccC YkAk7hMHcBNPUJrUvD/nQsFQM5cl1ojB0QppA94xeO/Fb0BytATob/yUMee+JcXxX6cXnN0EAABj WqIvFGmSQK9Dkj28B3lLRA0JpzHKmlIxloq36noDAJIjUHZncWVxzjG3yTURUVLL6hY+Ul0IAd2n PMKp0439egLamtanV8LxOR1uJ+52ON0tdghSYJfyXyeW//Rpyml7Iu0kjDm8zD1IGZN940mwivHH 8yuaJTWEAMOmCXuguiFJTA4p7A0WrBxr9NBIxbYCjvbO7lcigtC2fER4k6O0EALF+BwQM8zFeJFN 3eNtg20WeTgsbn06oogvpCRrFrvy2l0pmYoiOauqipmxiTQKkk52vV7rrJYr0J3qylIwysyOdVLt pWSZ9349Igf4QuM0BjiGMEQCPvIXmT/Se/0p0FYWaVcpm7BR493Zm/MewrJPOsK6gSXmFzDQYLsJ sUlRlj+lm+XRyb44SMxBBuBj8kjy0wjcHMLc4w0DiYLalfEAtMdbzlL95aDKPtu8HWzyRzMCcxNJ jBC99wI1mhS/PFWqMdR4yFDdF8zxoyH1kBIVoRXs2etl2ejsQggiSpH5JkhXlOwW7mghzCwh7NQF BiZrMYZuSK4nMoz8zpFt6wudggYBRwIA7RWMcW2TnyB7bT8+/HjIKWF6FUcvc4826wYmjCA/Z0/B aiojtPui936/XM479cLuggDA2TzM98ihz7ZM7Opi8ua1a2GbFEHZbh/XG1S+jgAOqVq4vHfBew+E omWv67reCKOXRjYV7jTZmuYNdEu7M73AL/RZUK/AEjKwq5vCHgKVxEJuKBHdHpTvYtDdy7ZuTxMx 0BeaQj2AQ1+A6OTyv/orQIpLegHH50778dCRvo8UuDVewkiZI6h/b/UkR8/M3ojgvfdDJrHgPuo8 MpmGdrWcwVk8gZmHSy8+HqnLQo0cbfTj7FGVimXTOYKR8vRKMmK9RXH0IwAJylQE7z1uNLsKA0Dg WmRLDoiZAxpVfZ/p3xTCGFpNQc8XzPGTotyeSa/vynZOd5xLzsn5r6eo9AvllAIOiyoQsSgK/Zyn R0lOZkNM/Ef2OhXdjyyncba7HxY5hKYXm7dNRR36tbe03oN4AjJEsXJI83obPHIEsYet/C+YSTsC 1/KvyUVbZrsoDvCcjOYWbQDHKUNkwVAjyq69eJA550KQZouUYs/52TYuUrJJfAEcP2U6RBggU12d qo7SnkSG0btnTazri5zjKFRA5lRtMUcu2FDq5GMbtb/7TF/S0LY65XC8R8la5ji/3m+fmHKU1/Jz OcHWVnXuN4hEBCTcF3gjr2I66SvYOhqtnCNez4OWYleTMtSwRLaRY45du5DLTtrCuzfvIQQCcVYn QAJyiAEQuSxdCMDMPoRoPK9CDgfZoA1U0NO2Lzjj6dOBfFixb+9PUwqfctuUeyZuMdgl6G5Pe6Mi ++wXFLIrNYDDAkBr4q5XoAsPh2RTSlPewbHek52jx0LH45hg78fHC9mqTxkRrY9Uioiag3R6Y3al vHZt7Xize58dot7D9JTdLuERQpQlcd0KYnprTMQbuE2lsjfGGn82gcIsObfqmiIhIhFGwDFW105v 5CcFNQ4/bzwmKZwVb5FDmp0svfGbk9UxdFvClBIh+kgDkisjJ94EZBwIOD4VHbjEjrhCDyyq0FC1 8rLlq5JMU4ivJ/FMOazlx6EhhDGRD+7aCyviPvzEkBSbXz8KJQKGnTjmeDc5+puwCdslagARbPTG EkiAiH7uFNu9TX8iIo4hM2MI0U44qRHKBUjJNKYsvTsYFKjjZs31e6Ugzec+wLH3y9XqbIPz2sG4 vSCic242mxVFsVqtONwT0WazCYGRGDiM+Pr39u7AOyeSnRVPjRJM+VkQmlTyBxalCyQpUI+pvfv9 SMPAbCsjoGHkIvTBiBwbJfvXeMO2knKJrYWM39C7fpOL41/HC8/X0ZTHe+9JeHV6Tyb1tGR/KgRS iFeShhxNNCmWmvIPmL6Ps1YPBwRbCz8W6ky21eOyWp3EQ8XudFjp+ck0vtn77aTkPbsjj/cmihNI Y1n/TlXog/lT4zgy526PRvuhZ8UfspA5NI6O6/XaOQghbI2k3N/TeO1pYoKTUr5vbX3idI2Z2oIu 655O1utEi7JScNk1dJsoyzKpa/pAjTdSf0oKHFmSvXcenbbuMnsg58id9l9fe7Pc/arbWo69UihW tfDCzirL2Y8COH40dKwJcTrAYd9RcrLfAiP6Shi5uSONMN3JRRSHUGwM4rAtxciz+SPTx2T3RqqE I8FMbP6GgevQvS7iFmlwsPcgShcYgLvDwMrD5btzbrFYiOMAEfHqIQQMnllSrXyhCYTQI9vYNv0+ l7HtUbHpdqDSMrsjKNpYLOayiaikHI66wQ+BCXu996X8yDapp4bvbXumt6woy9LOoWRKgZl2CeA4 YtNHps4edLhsY8pmdnQ8eFwxcoTJTZkjHdHgPHtTKkCzkgkLRHYvcOgG7DOhGC+zF2QkP+06bSZ2 6kAoo6/Sfh1vACLKwnXOiWcQEVHp9NcgY4yhrmsxI927eUenJ9WYhHQnS66MPHH0BjzaJqoVlWUp qnY9ncpPVVXplgFmp8hLOFHbxInSsi+Z7faQfKIGKG2drvtNZ/vUcbeGCVWPnYcPpKKqKohzhbph NixOPO5EP/o86N1Wj3tg3aM90287xZQaGQ3u+vQeVHUEBxKuQwBH2x3z+UR9PK74hLp5Uh558zPS kf6qc6QFg40MiDFJY1y8/P+393XPcttGvt0AyBnJciJtEsdeK+ukahNlHyI/pWo3r6m992/Ok5+z qdr75srdxEklJTsqW5Z99HnODInehybBJr4Icjhz5ljqUh1xQKDRAIHGDw2gQcSzUmNMVVUt7FpL YOnE+z4zX+1kciw+tLyW7lrAJ7+nckWSY4G7A1z1zkCh3xfixTzSdDQjZBjI6KdN35xw4yg6/E/Q wuof9HMsFxr/pf55XmZGmjRkuwnRxro9TbbOk2H2BXQMDSiH3nXxY5Si1SshWib3actBCCnEzwXf tfC6lnASEx3GogV0gTg+XeLq5Bwm2R7okTK7OCnzlWcOkaxcXxaz0i4qnHK8x/itiutwPhvKCDNX zuiWTMkqfJWP75HXWzktw9O6ro0xbrsG9Dgj3Oo3q0Tl5A1Jk5GVUrJf33Ra1iulWi5hFZ0Qrq4Q jDsuJTW4B1ePAThANKDVm0VKEadiRmky+eKPcWzAMas+F2fdDcwUUHD7/KwyTkOcBLCYGIwphyRk UzwHtOEIYyYNjzKFQrZzdKQQkT1zyE6tNBEBoPZvyXmTqLDL5DXhXD1WHn8SuKQEm8wi3NfpwASv pPAFbHVdo/D9KOEIYs4F4rXQ6kaO/DCR7yyL9WuY7ywVGjVXlHA4at834aifARyrI4NzRqDlqKWc m3vOGq9Wy+uo1evBC0coW/wciL2YousgmLZteOQh4GuhqLQlqShxYKrr14CiWjpLeF3X+6aVM1Qi YjhC/dKYV5lvielIanCuDJOBTqun4oMAFqMgRD6rWNc1Aw5E5H1+SvhkYuoDr62FLPCefoMohTYm uySvpKbip5Kfpqf75g0Q4MPDGUftaUfiTEc+HLvs7VGnkrK8hcU/UAbPwDHaKLoIoU+SG2JTY+3c GUmor0/Q/QpzmSxOJlBhd6xRQFwAgKoyRLYhi4hN01hrLSEihvdiuJ8lt/ycpt5uCiHi4uV0RHS7 TPJdOG/VyKSNTCOxc8VU17XW2lk4vNUTmXx+yUZ0uH5efPnUWnSkIWYxLGAVLCOv2yULbSSpaBHA 4TCjPH00C0jm2+KJ5wf5CsqoyEPkzNR4KNUqDWKZtIdnjQk+0trh6EDtIM0Ac/Vd9ENHkYec3Hvo DQ5uvVHmoUXK5ZEyYHgMk1L116pZOzpPy3byDQDPXy8vL6lNTipmNRI3CQ6/teBMiGi0AYCmacqZ XxdNVPIBPFOvJOCQkaPwYkQw+oKh5CErBkaIiGpwxVRVVVVV/JMZr25LICJYw4NiyPYYA+110axS 8AY43owTrYRV6iS0nVAQIfUJjLdjFLzllV73TbYI2WjyR7HVWIZcaxMx3VBT3joLsViG4WKwkk/r PsaKM/7yyJPze0GjMcNPiPzWEhCBtWSBrXlE5CzzfTHZ8aiA3h3DRTWA4gERkcgijjwUxZPF7CJe iGv8mZG+uLZ9766eJNEsvJ+uS04WLUwLAIr7DQCisrQHIgALYBVSXWkEa8C0bWsVaI1t21qwamwh t8BfTQGQ7Wpecdnc12Q1YW3DzkC4JYTQ0sW3bWut1ZVVSiFAXde73W6ydKkqWoVSX9RNt0ZjtowQ yOL0W6aZKKVye2aJPOMI/9KxlieVNiIiKd6uBLyg1hm5gD8IL38g+x5Ve8YRqJRSuNlsjKkZgPKS ijEaAIxxOMOzfhHLRbOUjxhOeDoi2/ZcPRbV3jzorgtiJiVJvSoUIzYXinWg4a+fUOpS7D0Ik9gI TL3OnZBkSkKX0chOH4vmPXDzjF9Pn5ephPL4/XD+J6DJVnvt1rxDSLaDdIeJhIvIA2pwr4jGx2KL jT0rwq+35NFomkvgnHOwCnDXyUK/G2a85MfPqLXe7/bb7fbWO3devHjxzx98cHl5CQCXl5e73a5p GkRk3MA2ldDO0TSNMeb27ds//OEP//znP//617/ebDaPHz9+8uTJ06dPz/nrH6KyUmmzPJMGlYyF wwt0brhwZJjo7gHQWptKiRUT3gHabcuQ/kOPp65DBetCUmAiStz2PD78cO1jzSytFo2aCfSsCMLe MG3KnSvJMktJxMIxS4635NEyLXnOujVPY1ggzBSC5gIOKFhrDDvVIXRz6/8Q0lrz+oUbjaqqAoC2 bauqahEBkQioIYXiBpnexImIt2/fMcbcvnPngw8/BIB79+5Za589e/bixYvnz5875iA+utT47PLn zp07P3/wi3//zX+8/8GHT548+d73v//8xYv79+8/efLk9evXb86nKQAcuSQ4ppDhYJtRPpOq1rxL g8+7GmMAGCBaBzjc2srpx+ySHCUcCTcelfNx3MrFm0uFvFMyyHBPDU4CjlCvTqvihAAeEz/rbHz5 8y3geEulFLSzDnB0C4dEnVNLGoEMK07JljCfRZNrDW/JIzY/UO+lQGt9dXW12WxarZqmaZqGiPiC 2S4BYdu2bJy4c+fOT37yk+/907179+7xUERE33777dOnTx8/fvzVV1/lfajcvXv34cOHDx8+/Ndf /Pzu3btfPXn6m9/85sWLFw8ePPh///3fr169ev369Ylq4VSUN/ROjIgYdzcuk+PYHzQMAHGILD2O KzUAjqqqGHDwugoA8KKJNHJk9m1cu/GAKdXeJsU7md5YDDgyIflXEnDMtUwUAg6P+STgcCFvAUeO KG3WWzZAfgdItCciIrCdg1EBO+K9IgPh3Xz6ZKtUb+a3Y3ITYgYfxhgiQrdVEQAAeM8NP7P78zt3 7vzLTz+6f/++BRg8Tmr1ox+/9867dwjh2Yvnry5fd1AUwXP6ppT66Gc//c//+38ePnz47Nmz7Xb7 4/fvv3z58r337nz8sXn//fct0SeffGKtxTP7OoePrKn5dx8etnnkGKkk7i+KvZwjwIEESICdzxVG DlVV8QZQXkzpfWxoIUPEgjK3XIdTRutGo4Wt5UzAUJ5S6CHa+KMGhuhP6C0ceUtDUqoyGZLJs2gD 3gKOScpbupZpxrPSp4U0wrPdM4NpcuaNLnzOnoyA51s6IrkBRGpkXlhRqHgtHBHdDg8AaPYtABhj 7t69e//+/aqq6u3WpWVUsdlsPvroo5cvXz579my/3zP/tm3l/PjevXsff/wx+8m+ffu2MWa32/HB y3feeedXv/rV559//sc//vHvf/+7PjPPCkcCHMv4SJMG9NfEj+J0gGNIwp7sjVF1XSsFWmtUxMeU nHvyglMBkbJ04/3B5VpMKWgitcr1go+MVosCjvxwI3hGFlPcT4t+woxpxM8oFR7DEKGFIz8sEtFb wLGc3pwBcmjKws0X/2/7qTD1J1MUDUnCvz3DlbdlvKUSQkQdDC26qjWqBkkjaARqm01lNMK+tT2Y JK31j370I2PMdru1AIhoBR9jakT93nvvf/bZX5umm6/zDaMuzkcf/ezBg3/78Y8/UMpstwYAoH+r tb59+84vfvHLBw8ePHr0iKA7/3DttMpYJZh4lozkMN8lye4PVeKKTWmKQBg8bDIcMUZtNpXWuN3W ppJnEkFrh11QZp0q+PQy0HrEDc8DWJnI8mfGLL2ihCVkszbbvA6cbZw4wh6OTPwM4MjI9hZw5Kj8 G3/nKTRFdAhD/Owf4gmjPL2050D45u0L0VprpbXWRGSMcds/2c5hrTXG3Lp1i69BYPJ0uhv2nIJ1 k+/9fl/XdV3X2+323XffdQldFfM5TETkXaVsGvlufILx+H3QUD1AirHzgmAPB7loxpjNZlPXpqoq Y/jGPnnjmjzua728UstAhxRhFlHMC04oRthO3DrLmSys5BVgJk4ecGRswyWvkiJlZVggnhcYBxwC L5/petgpsfZbYvIteKJxzkUM0fiFHGYB9hPTDW6T2KKyqKw2gAq0UbYhHvt5SNvtdp0SD65dQ8Sq qhiXUH8g1u3zcFNVY8wPfvCDy8tLTs6GX0XdzRfGGGNqAEVkAZSPW4fMbsxZ9NJhOyxR3Fk4IiqA zuUMDv4v+KSr6swiMGwHripT16aqdFVppaGqNaLb0qH4EGwvjJLZTAi8KpFwxYHCVX8m00IwEUY7 N3UBU9osFeJMj9Fozg8H9H44hgjpGrDdqfl51I8FpTE7T6NwwBAeWdXLflcKUq1FC9rT5HR2MT49 GR1Yk1nhB4scz1w7/11dY2+JyN0Wm9/vmUIYXnghoF7RIhICc495SZOWMcvjl0u4mNustsH+JXns b5oG0VZV1do931ix2+12u92tW7da8mfD1lo2isi7LeSMHBGvrq6++eYbIqrrerffW2v7rW3AV3U8 f/784uIi9KlwXVQuhhcTRXjUwlGAQigMHBZCYjTYOYD4jAkfQnG2DVQEwhDlvG6UFDPU8OPXkwxE wWKd3TUbImIzm1TLbGZz7SrTFyTSdQOzl/sxdPVEHSKEkkCgalKCRfXeFDSZZ9Uop8WsXGHNYoe1 6+qFQ7gVAt5U2sX5ehxW+a5nom2jFC1gCdoIOQjAPaJUqlTWc6VdEGcWjYaEVZkvqIFlVNd10zQA atdcIQJg8+73biHS8+cXP9zviYgRiQOjxlS7XWNtc3HxDVErr/Ji8Tabytr26ur1N998jUhaq5YQ WjBonF/zi4sL3nOqlEKwCJYnaSeD8ql+NzndjyaUt6oCQF8nwfYI7NxwIWLsrArIkQMRUdmeDZ9D 6Wwa/Ir9dymoEHGzqXqHoUZpUAqU0g6yKAVKASpSGqBsdioLXBA/pNEoE+IA13GkMueOL3FbflbM WkiOaNQbTqL5rkVTimgULTVxymMIL215QY7ag4iIm6MKMvFKDd01FzdzD8f5jMopvPkdo3wBJ9FG rOcsWYUpjxxNMsnhHL5j17aPAC+8iaOXqQvn6S8R8Y6NzUa1bQsETdNcXl4+ffp0e+cdN4nUWu/3 e0T86quvvv7667Ztw9kwz18fP378pz/96S9/+cvdu3e3t29VVVWZ+tWrV9vt9tWrV5eXl59++unn n3/Ozs7PEGccxj9ZHDGITuSYGW5duFJqW2+UUlojnwCq61obubGUt2Hywsq5aFEQOMNpVK+k3Iom 55Zsbysxh6xFk3rMiphRkUqMFgsGmrnabxY3GVKoV8ktqSzI73yGfKZrGSrOYXw6nIgofb80AXS3 cZAlIML+AYgAxhfDDgzH3PsIfIaly9G6l8N6TSiYS+v16szMIDoVIBp5hYgyjAoQZvcmEOOJLW4B gPDSXu0V0uXVi7/+9c8ffvhhvd1etZebzWa/210BAcCTJ08ePXr05ZdfRr+j0/6ffvrp3bt3f/vb 31ZVtanqL7/8koh4GeX3v//9H/7wh4YsKUQ7sdB5DOWTt1vkcEkg5jhy4j4d5FPHDAOo2+7pMxql VarbtyG2bmD/kt+yJQNu3do4TxtVVfFRFCmPNsibOaKFuhZKdUnXEtgf/6TM1FtbJQiDY647T0MB gTiGvwXJUcYhciEFuiiS0aTBlZRLOcV96dyPbuKx2EmQ+5Y8yrcPotD1/vDS40CS+l9BnBF36LWA 7FrsHCw6kJcA81A9hdyiP70Q1k2DB5FYRmHgd5j4LhVW1mzheMe8Y4xpG7DWXl5e/u1vf3v67fP3 3nuP9we8vrr84osvXr169cUXX0S/iEMbV1dXX3/99e9+97tHjx798pe//OCDD376s5//4x//uLi4 +OSTTz777LNnz57tbQvjnYOnLPvEToVEzAxFd0hgf+RVLBMkGIpNMHyKx60VSGsHf6Z+H6iqqmqz 2WiDvDPGGDPCObwZIuvD9LooA+tnNQbuzlwbEnxcYwGl6gsRRmrulHl7pK5RPq8SpZioVW8ScuMA R+cHAlF5Rb2uoWHtb7+gVyCMzvSjCITx34NcKmVG5fwMQKKNLrItrTSZ3IWkmMu/3k85XQg5hP7X o5hmLToe5wPJbbvTWje2bdu2azeaEC3Q1dXVq/3XVxfffolg2rYlwpcvX1ZVRftGEV8VPHAjGhZ3 ad+0AM9fX/7h9//1p///P5vN5vv3/uni4oJvgLu4+Obly5eVMTpySeYRCcWgngEcmZ9hd41eED/8 7GpksG0gSlxCA9fekqG1AiBEEIsg3U82YPDqCd+Nst10zjYCx+S8/4NQTS/fnJ5cd3OHmxzJpRYZ kiI+WsVnphyAhuJTEUfFJaFekq9SSeRDmd5YolsKFdLiiRmX/cYBjo6uXV9f+4RgFvXVNdGmwzcu gmz3/VBMXnj/MLBFEV96yy6UOd8JJzttCEG8UkxmFGXbjRXX3QKPR2y+1lrzKth2u93tds4aZKnZ 7/cIhoj2+5YtHyhONsrnkDkiPn/+/PLy8tXl1eXlJWdxdXXl3JtS2gHDupSCBeHINAtwDLfDx0EM iVzi2bkEAKC1ETswhvm6PG9SVRVjDgYZbJ1KKSg6Ywux1xO9Xlbe6biM3toKzMEcYcy5umt4jqmg uYAjVLP5/MtFFRkVpQwFmBRJFuGmAQ42BvJK5rV2GyrYEbaEFhQKkffBI2K3EJek1PSxFJ9OwvBU qslBPZNvNItUP4yGU87C0QLYcc0QAAHYXldY8JeWhrcilR0/ULZW5dtoTBo/h9l55DLN5JiPQ+OC WyRCsrxJQaMisgpaBW27Z+BYERHtQCO2ABqVhdEZATcxdYrbWqsAmt0OAK5ev27xhTHm6urKGEPW mt7Ndgjv0oU6iDJ2iMJU0YQRm0dyp+cATca2je5mEz68KgY/BID+uAkohdoobZTSaKred1t/w2uJ jjwNsJtFUTGISNoq8sRNyHVziR7yZXTCXCuXAAARNUlEQVTMw6Pdi+VnIZwwqdXbjGCrA45rgZuu FGZSCFfC88HF0Uo/vXhn0kXhyLOWYIR2vbkISYRYvjBT95w6BRPp24GcUgAZoVyqZfJ/N8gY05J1 M0UYfxQiChfpWN37N4oJD6QuuUXga2ndaUbqXVkPMDFo1at8CDHMj0LCOCtm0f0MMo1Mu0XaMR+2 baAzcvC2UCa+HmVbb1BQplDno88lcSdl4WUzaNvWuejIlAvH1rVMQwrJVRqfc5llUIk+80871j9R tFEOOA6nFCuiIhgQDcnLL4sQt3AcdQA7UhYnkPkEJHvLigwnIx3OSozlQ4gD+AuYcwib3MNuDEFT LhEyyiQby8YMAxGTA0+r+iQAQAl/kY5DzsKhpBdXIN5lO9kmwvy8I3kZiipxrTVa3LfWKAQL1Fpl befsDfYEZKFCQEWoCDQqt8mAxGEBIlKI1NcH/9V8KpO6/TdWs3InRjWiCR2lR3toIFr2wiEqekol Ot6nhsk04BhOrzjAoZTiTRv8dfh2G3fXfJCFO8kSk/wsicbnY6Wc3nWAjvLD5IJxocQc4uXiPYwE AJJbxKKqLM8kHx6NWxxT8s+9lTXYfRp+IP9tRBYabMxGsiCx9AUA6PzlFjRQL0KqdlJGvOKBdvgq mcgZVTKLUslXRJ3RLAprIx9hhngFi3COhvvbBkQxisafyLWiLs1442fGPzVfN+rImxm7mmefUak+ 7I7gxssgypKfXoQ8QpEcbxkip0dzB/uwSolo8Ua/Za3U6Vx5VQeT1to57OomnbxNcpwPbwSB+X3Q xddaAygqdis3N4sMICgHHDJSt+VWeBSdZMLHT3BYUuGU/N+gh71Mef7Nu0SdR9Hu6teTW+LKGliR WJPVJX1sFCbpsi+b8yxz4OFpIe+n88zrTZOiucxSRylJFhAiFiadWzNCg4kllZBdp3FS8pXnGUqw NC0AAMiBJCOFm2lNsJsaszOv1urZmWnQRDX3RrBu9kMErPZRWm4ndnUAZM+udMUkAiIFYIlUB2w7 z3GMO0D880yIMLYrdq/Ed5Re6tq2JRidYZHjGPYgB4jANp1gXjV1olrvA8XwxiBhT3L7hfWaf6gv pmiwL8TeUvqtb/8gCvBTPC+fFfYTC0tW8QmvZJ821Gc8ZI9IREYpay0hotZgLREhkbW2bdtWXQIR EOiK7L611iLv7VDdWU0aH3Al7PQvubkRb410vl042iCjBQA7urVnjal5l/UQ4G13KNwhxnGG6Q2z LXKoxd+Lj59wJx7MY71jUm7bFgH5hhQAqxDqymhltdbGgNGt0a3CvUJA2CPi4E0htomDUI22fI2q ZLFCS5S3QPMsIMpOxijYcTwL7zo36isCDsL+Gft5mps2B3U+ert8iJmdkBtyiWoLotDAIMbXEll3 9AxnOv4qXONZPPMuaB+DGKsM+XNbpEx4YNZhKaIz3UnxJEb09Du/LhEm/1GYwuOpmSE8MaL72RGD kfFYnpmlhblEI4SFCoV05o0wWvjMlHJQJn8OWxCShTg1HdhW+Uo2IuKiMbemadyhEr59bSVhbxjl zSRhhB4BBNYUEY4iZgfItAYApVRd1+y2nC9M0RrdNtHFxtxVFOlRyeuhcoeQ1H5h/AWVklIsJeLJ tAMHHL3K6C4QOuewj7IkbTe1nI42j/nI1J05Fkux0c4FZlHN8lG8kCb5H9LgTkZhKVJ1Xm42RFxS +Zk2xAPJsIzSr1YQUQZyQGLvhZdp1xZb3xqRPkgx6tgZ/6Th+OcO5Tq0EauBiblFGH5Wytp999Wl QkQHO0YK0SqlsKH+YAt20zO2Wh0Fg3ROao8yez6EvAWUONpIp00BDgYWxvDKC7llFF5SYcCxcklu AtH4UtmUwl82EMztPlHA4ULEvGbCRLoS2oC5gEPW4TLAkd/XL5NMWDiiQ2AJZatsof0jtf8jE7NE /kJWx6CwP7g2JxVWiYRuyJQ/DxTe6yHku/Cy7q/n2gsKLlhxWZD1AUfKwqHGUwQppPwpscUoo6DD h9yibD2AkknVyX/GMDdtix7FkaXjJAw4+PIU6OunpVFFKaXI8pD5XfZTMqyhJB5moQ1Hw8S9n8+5 e1+VYsevdrvd1rVhNxvs2atwu0lI5/yBQiQRvqXs6olTgAuKySdiZkkrH/yfnZIbtotlAIf3sJRm JHf1zGnskVtF0ZJK9Ftm6NoV7lyBU5Rvr6v02MMR+lgMf/TFgv02+YIk0EaE3CsbYAif4TgVjPtq 4ca3MIsUmPD+hoihf56YgoScU5J8h4l9aXMX27cNIipA6q98UxqbpgVsoVuhJgDeEenO+3jbTbAP JBE4BqCjG2iXS75YL81aN4maOmRi/s9jiJ0fdDZkAAAozbYNvhLFaK0ReSON5k/AUa9d2V4jcTfM 3JaSBy4Zcg7+C8WQD1HAIUNm3Xa5iEqTh7aNZVlnEnl1stoejnI6rDZLrREScxxpPDiE7aQNxgvP gGLZMVwPTAGXueRWRpzZwK1W9A+RMT41Zg8xY11u6IcJYV2XSDF3cMdzVU7CRBFKK/p/BMF4/DOF enOIfZ9ba1va7fd7JOuOD9gj7+XA2IB97BxTes+9ilo4IAZNUns4kI/6oGIAh4h8H0rvY4OPwhKH i4Qr6OSDG/CpEU+oG1E47fDwx9IRNGeKyCSJpMVItNUPXnmyzIjay2lxZsoRk2n+rD+nl1RSyHGR YBPC5Wmya0mplhnTMgzXpWWc89/CvXWOa6Cs56Reym4MQY/qHyikaI6jryN4YvA2UjTupX1gauz3 ZPPWQeSDhyTcowvx+omXRVgVQ9G89Qg5bx9xCR7CV+dNiMhXeFztd4i4u9q3bauwNZpaa53C764b Piwj+Uv8vU5KAZFlCMBbi6mqSmngI691XRuj2cIBAP1NsyMxEPHGtJsyyqgsDPaKUmKRJRq5hMLz t4WixpRkREVCtoAh29UpMsUVfxfwy7yTBZm2cNDYVHBdgLpvN0VplzWym0vhd5GYYzFPSm6ujNgJ wh7lpfIAR5hdSgz+T4akzkSEKCGvC/KUx0zlfFanKMqJhh+VEHG73e73+6a75bVx/a4bAtuT3sR2 MkqZMcLllQWklEJgL6J8DkXzja8SUoiMLA7E7+Zld11tOEOFI7Fs85k6DyPnafXBztrBdxHbiRfr n/JsF6fJp1xQIV4pjNTC3Gy9GN40F3ptQukT8Xmx1KJq7NqNmq3C5tZRJv5a2CW1gDKZZLJ3Seqw QkGSfkyPjM1uaCfp8qtfWyEitjvIwyxRv1j+Q6xhDwLQEMKECROLl3zSLalXxgCUjPBKCLZSyiKa o7q+jZNR9TqplGfxd0mMMVuFV1dXyuwb2yij2n2rFAAQ2s5zKAAAsqtR9C7FWMUSeQKaXFUp5TDG BV5yZHdepqrrWpvOgJTKHRGV4mvreS5+A6oxT7NGYs+t3AjpBnChXHPOQjMlVLJdNCrGuoDDK0WE eXHlLJSJCBzg8DRU+Klg/GkPQX+HqJfo2v+KlJqjrNj+SjTsia0yciiNjrIQHKd2zy51+NbjUy4M CADUMUysj0iKHk7xCjglW85AMqsUbxpVVWX2e0Tc7/fGGGs7+7ZSqm193OOOABymVa+BoprhAMAh VSspparKbDab2lTGGFQkrfpEFGw/Xagnbladh0Sht6FEtANzAaGuy+s6pQxnybM64CjIcUbKxSNU bkllElUc8j0XDksZn9hLaW7deVBaBpYnT5G8NAjHB82PhEIoOEcqT6NAMLMPe1E0mnsLsSJ7Fg4v uxBwULDl00vrySNBUgik5vZ8fjjyPq8bTNwyt9stW5jatrXWEgF2F9x3XjoALIDC0R1w50LluAEW a9u07kJEpfieFO2umH8DloKPQmHvPnwhIBoSTRWJdsaLXGNNDtCP6cdrfMNdKt7wGc7pnXCzFow9 kxdMWThSQ1TPLtdpS+TJCAbpcT3aiKX5blbWB1IKqymlIiCwwJTntm2GzjcdFgERp2c4RJarLfm8 uu8rXWyFCMYK24aQMOQDosFECRItSvyUuQ88w3MumUKdM60u+WgJgC9MR8V7hqg/IcUNyTYEAKEf 0hRSvynLKyuSUyNVxfe+amOM6jxsFN3GPisvOEpLTjAcZbRapqlSRPX54SRHwJLIk4BDxklp8olB cA7JailaWC/juVg241UoxabUUahxJBA0NY9MlnOyCry10sV8Fkcuyf0QIqIU4JiQJ8ltZCSQQzsA UHfVpz82p2WLBDLgkHHatnVuF6KAQ3ZXGp93lf4/ojLHhJHxI8aSjPx5Un3JokmJ/Af56nBNM4n8 lpHcewEAfLkaABljWmsRcbPZ9BYOsrhXWu+u2jaxe3SWXeEaKbXSegjx9MBdw8bHX7uNorwzYw0X oqF6P5xnmEkq7+k4CzITjgDkeOQGrPDKQFrkjeNAu4hQHcnI0VnQuoADxq13cuCj/jnTN+cKJvkM Syoh1PAmH7NyWquJB8nXBH3Fma5Jx9OwiwFHhryNojDqD4MHp+i4LqTyf1KQauQnY0pkl1BOnb2r X6mnUP6AmRMmYsuJ/rwptG5Ljuxg6F1xa62x3w1q3eXAWjVNA6SJyNoGACyNtkw6VcM7Salgbb6X 4aQwZTHgoNi0EhF58ywiKKWMMXVdG2OqqlKqW1RVSmHg/65HD+Aqiqh0I+SNAHblJJsKjg/EHkN7 z6rAYHoTDaRoiPdwiMyztwqIv4uZxDmLghjvRR7UnKzVkphej+iwPRxOcaTg26xWlVAlpWLMpbL2 NxtwhMLIziBH9OCjkIzuSeg52grG+w7HDNaRgpviww7pHrx9J16+4V+vuNGM5M/zRBup6vLU2WTF ZijfVhEIgLC7UpEUAiAqUkRIRHvb1nUNsAM0ANA0zb4d3YTC6AR6r95O7Ow8bFk5DqIVLRyOiVJK a8VuNti1l9vJwX8O36927GHY5ZPKfjrOfHLwIsQccAC0iqrBuUyiPc6OQ0LdIpNQzEXhXArXKNzP jHMRxrf2yCO8v4djqrcXfc7F6CTUkr6ix0MdGabQhqdTSoQvXKMJKdWSWP868eZ2nsU4hgLXNKnx e/w5RpjYK1Robxhxg9FpWyKiZggBSlZR2KU9yVMx05tGZaokRjmmvl6BMlosfFtCpdAZuK0SEWHf YkUn2kPvCh1IK6VUd/2Oct5gwx6Xd7jknXlZsUTR7lxojs5QqhezbYMNG8YYrTubh7decEgW+Vc3 lDwUFV06gXGbxwK3TKt08KguaixNMvd074HyeD1IVkvbtvl5MgUhGZlLhPGUZ/yUSpRX+aoKzj9K lJHSPbRtS7BfxlDKFgKOKNpIgY+oOijv2BEUJYh3qnsh7jl/pRAtXVJp+/taefVdbh3NjrsD4Ahb BRHxLV/R/qME4GBCKyJQbqT0kES0qXjJvYJ4/KJZhMW/WRTWyVFy6dY3EAioHQBE377ZegFaI9Ra adAttm1LVu12O+iSDr2sXybICdz3nZUHUc9LnifVWmO2YNUxdLs3UHUKkx1/eankz17VcD0oFwj9 1TV5AVYoxhlTvvFgdsEuXzmZhJ6uoPFmsjbrsJTERC5UaMtI9n05d80PUp1rc5HzMcCZKffhWj6m yiSxwKK04QWkTdN4Fo65dohQJE/LhD/DKY7DUuGlQYcb3mVr49wdz27v+hSDkGNhrlZQ0zSeMJAd /sNXr1+/zrbLkVcPa610Byc3jUahjMs0xEYpOaPEalrE9+0EYf+fxfw0SCVaRYu5zTWqybyGcXr8 czjtqRAACCM+cAuNi4xJyiWcJM7OXYcWFelA6gVGqVKg1yE91qEhRn9uTMRPfuJZavmkK4NHa/t8 TaA0ZhANPkuk/vRCMiQ17SxCRKktQ40xi2l4TnCBPG6ECt9mhr8w5ioazDvn+L95+JMF+5sRzwAA AABJRU5ErkJggg== --===============1908545373== Content-Type: application/octet-stream MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="VID_20141016_233549.mp4" AAAAGGZ0eXBtcDQyAAAAAG1wNDFpc28yAAAACHdpZGUAAAAIbWRhdAAABBxtb292AAAAbG12aGQA AAAA0GWkZdBlpGUAALuAAAAAAAABAAABAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAAABhHRyYWsAAABcdGto ZAAAAAfQZaRm0GWkZgAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAQAAAAAAAAAAAAAAAAAA AAEAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAAASBtZGlhAAAAIG1kaGQAAAAA0GWkZtBlpGYA ALuAAAAAABXHAAAAAAAhaGRscgAAAAAAAAAAc291bgAAAAAAAAAAAAAAAAAAAADXbWluZgAAABBz bWhkAAAAAAAAAAAAAAAkZGluZgAAABxkcmVmAAAAAAAAAAEAAAAMdXJsIAAAAAEAAACbc3RibAAA AFtzdHNkAAAAAAAAAAEAAABLbXA0YQAAAAAAAAABAAAAAAAAAAAAAgAQAAAAALuAAAAAAAAnZXNk cwAAAAADGQAAEAQRQBUAAAAAAu4AAALuAAUCEZAGAQIAAAAQc3R0cwAAAAAAAAAAAAAAEHN0c2MA AAAAAAAAAAAAAAAAAAAAAAAAEGNvNjQAAAAAAAAAAAAAAZt0cmFrAAAAXHRraGQAAAAH0GWkZtBl pGYAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAA AAAAAABAAAAAB4AAAAQ4AAAAAAE3bWRpYQAAACBtZGhkAAAAANBlpGbQZaRmAAC7gAAAAAAVxwAA AAAAIWhkbHIAAAAAAAAAAHZpZGUAAAAAAAAAAAAAAAAAAAAA7m1pbmYAAAAUdm1oZAAAAAEAAAAA AAAAAAAAACRkaW5mAAAAHGRyZWYAAAAAAAAAAQAAAAx1cmwgAAAAAQAAAK5zdGJsAAAAbnN0c2QA AAAAAAAAAQAAAF5hdmMxAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAB4AEOABIAAAASAAAAAAAAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGP//AAAACGF2Y0MAAAAQc3R0cwAAAAAA AAAAAAAAEHN0c2MAAAAAAAAAAAAAAAAAAAAAAAAAEGNvNjQAAAAAAAAAAAAAAIl1ZHRhAAAAgW1l dGEAAAAAAAAAJmhkbHIAAAAAAAAAAG1kaXIAAAAAAAAAAAAAAAAAAAAAAAAAAABPaWxzdAAAAByp ZGF5AAAAFGRhdGEAAAABAAAAADIwMTQAAAArqW5hbQAAACNkYXRhAAAAAQAAAAAyMDE0LTEwLTE2 VDIzOjM1OjUw --===============1908545373==-- From nobody Tue Oct 28 12:56:32 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 948821ACD61 for ; Tue, 28 Oct 2014 12:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.175 X-Spam-Level: X-Spam-Status: No, score=-1.175 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, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 gbwthHASVTbg for ; Tue, 28 Oct 2014 12:56:29 -0700 (PDT) Received: from nm48-vm8.bullet.mail.gq1.yahoo.com (nm48-vm8.bullet.mail.gq1.yahoo.com [67.195.87.228]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EDE41ACDD2 for ; Tue, 28 Oct 2014 12:56:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1414526187; bh=8ot8y44eraCMqbDWi500Zue5EcwDXz0rml923eTh/Sk=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=J8pXAyqjBOGsDH2tRGgJ2t0QScUu3hc5cnLjmXsnz2IF5SqwUq8T9ZnTBHE6FQIaOZMiNcNOdR2m0HpN91H+EteJgt90HLmdd73FPkUFzursyfgKtsORFio7uOsL5gH+LAfkDgMEgaOv8L2OQteUlMWdlimUEVqKn2Gdx/diC3jOHCkgLfk89X35sowYAmag0fuS+6MZ3YZBYXtgALpbNUzXLIWCFgfb6t1ehDAfHAxzz7eWRxyhOsDu47MkU/JgC2rDscnZqwTepC3b/ApFXYLx8bfUqJdtS3W314EDgsJQZWjzu+Mt+zZdQAR4lT9EihT7sgukPNTklaUw/Mq0NA== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=e90tQ+7vai3BwUtwUw1ST/deN6uxRgKKyCJrLznK8YwWQBEyrEieL1Q+/pjVl030Q7CXRXcD7CYGiCZlu8RXst2LfnrWdTivsshrBJfWUklXVUK3tDDtvccsgROgnba26d9ibhHnq6SbZY822n00a17u1kcy5Xa7YkQVmXtp22f/pIDptD+uQevTSl9fln1/YTI5e9cIjkHE/++DWQLpVVK2bh/615p7YL5KavNqgZm9sYgk1NZqWAoX+NlX2T/JZmSdCwiChEh0/gQn3qEW52W/Pj3aLKegrRg2OyemfJ2gjKzClL4jQnRyT7AUsSBVPEx1Jc1yIBURstjuSFZasA==; Received: from [127.0.0.1] by nm48.bullet.mail.gq1.yahoo.com with NNFMP; 28 Oct 2014 19:56:27 -0000 Received: from [98.137.12.62] by nm48.bullet.mail.gq1.yahoo.com with NNFMP; 28 Oct 2014 19:53:27 -0000 Received: from [66.196.81.170] by tm7.bullet.mail.gq1.yahoo.com with NNFMP; 28 Oct 2014 19:53:26 -0000 Received: from [98.139.215.254] by tm16.bullet.mail.bf1.yahoo.com with NNFMP; 28 Oct 2014 19:53:26 -0000 Received: from [127.0.0.1] by omp1067.mail.bf1.yahoo.com with NNFMP; 28 Oct 2014 19:53:26 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 789505.37477.bm@omp1067.mail.bf1.yahoo.com X-YMail-OSG: U5rqwwIVM1noHV2WPe8CnArRwVVHdigquCfek10.cBrovKwSv3slikJyOB9hwXh bCJhY9aB2lKFzg44uE0SrmPAF57slPJmZwpAIML0QKhYHmagjbDQVEi4ng_5D7HZL4FNmgER_ZAc u1.n1OIO7eoC4YbQO_Cnw4XcTF8bupOpyFL1xjNfzH5_GC7gTkyvcPO75lMIJUa_iFBjD0v2D_KL ZuLisFYKrGYiH06svsa47vRUrLMSpyOj6pKaw5DmaO_9N6AUM_NAjdL6BMbFSuHzEigZTVvZp7ra aNpIdx2Qtdt2_v0UnE3LK.Rt4QcBeoSM.LUMjTo0ajJkTxak.v5P_RosaE1qqBRVX0KLSfVQLPlJ Yr453H5hiOeremlb9Uvqef4kaDgcL3YJPceNjsrBIkPC7U5Rxqd_4GtTK9727TSmTpRUmlhqI0cR .EPJOjLEJpVVROvkNImxY7wxbzTgduvVmWKLEqFdqyUCU9sCq6.TSvi9fbPTZcBPsQMi_HAMH_TS teDqvGbtgTUqs3ZQF2kG0A0uMOB9ETziGqFYgA0DNaEuYVTADfIfVrFMCWXnHk.A- Received: by 66.196.81.119; Tue, 28 Oct 2014 19:53:26 +0000 Date: Tue, 28 Oct 2014 19:53:25 +0000 (UTC) From: Bill Mills To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Message-ID: <2061250451.14565.1414526005529.JavaMail.yahoo@jws10605.mail.bf1.yahoo.com> In-Reply-To: <20141026231809.3216.45800.idtracker@ietfa.amsl.com> References: <20141026231809.3216.45800.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_14564_590347385.1414526005525" Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/T7NsMtV5wjmULAegQDTTZglBrOU Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 19:56:30 -0000 ------=_Part_14564_590347385.1414526005525 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The server needs to be able to enforce policy with S256 as being required. = =C2=A0This means that you need to add a new error under the OAuth error reg= istry in this spec that allows the server to indicate the required hash. -bill=20 On Sunday, October 26, 2014 4:18 PM, "internet-drafts@ietf.org" wrote: =20 =20 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 Working Group = of the IETF. =C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Symme= tric Proof of Possession for the OAuth Authorization Code Grant =C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 : Nat Sakimu= ra =C2=A0 =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 Naveen Agarwal =C2=A0=C2=A0=C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-ietf-oauth-s= pop-01.txt =C2=A0=C2=A0=C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 11 =C2=A0=C2=A0=C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 2014-10-= 26 Abstract: =C2=A0 The OAuth 2.0 public client utilizing Authorization Code Grant (RFC =C2=A0 6749 - 4.1) is susceptible to the code interception attack.=C2=A0 Th= is =C2=A0 specification describes a mechanism that acts as a control against =C2=A0 this threat. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-spop-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-spop-01 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 ------=_Part_14564_590347385.1414526005525 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The server needs to be able to = enforce policy with S256 as being required.  This means that you need = to add a new error under the OAuth error registry in this spec that allows = the server to indicate the required hash.

-bill


On Sunday, October 26, 2014 4:18 PM, "internet-drafts@ietf.org= " <internet-drafts@ietf.org> wrote:



A New Internet-Draft is available from the o= n-line Internet-Drafts directories.
This draft is a work item of the We= b Authorization Protocol Working Group of the IETF.

    &n= bsp;   Title          : Symmetric Proof of P= ossession for the OAuth Authorization Code Grant
      &n= bsp; Authors        : Nat Sakimura
    &n= bsp;                     = John Bradley
                &nb= sp;         Naveen Agarwal
    Filena= me        : draft-ietf-oauth-spop-01.txt
  = ;  Pages          : 11
   = Date            : 2014-10-26

Abstract= :
  The OAuth 2.0 public client utilizing Authorization Code Grant= (RFC
  6749 - 4.1) is susceptible to the code interception attack= .  This
  specification describes a mechanism that acts as a = control against
  this threat.


The IETF datatracker sta= tus page for this draft is:
https://datatracker.ietf.org/doc/= draft-ietf-oauth-spop/

There's also a htmlized version available= at:
http://tools.ietf.org/html/draft-ietf-oauth-spop-01
<= br>A diff from the previous version is available at:
http= ://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-spop-01


Plea= se note that it may take a couple of minutes from the time of submissionuntil the htmlized version and diff are available at tools.ietf.org.
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/inte= rnet-drafts/

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


------=_Part_14564_590347385.1414526005525-- From nobody Tue Oct 28 12:58:22 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A826E1ACDE6 for ; Tue, 28 Oct 2014 12:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.509 X-Spam-Level: X-Spam-Status: No, score=-1.509 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, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 lIYtf4N9zQwL for ; Tue, 28 Oct 2014 12:58:18 -0700 (PDT) Received: from nm14-vm0.bullet.mail.bf1.yahoo.com (nm14-vm0.bullet.mail.bf1.yahoo.com [98.139.213.164]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 516E91ACDE8 for ; Tue, 28 Oct 2014 12:58:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1414526293; bh=s1jrnSUgfa4GWOrq3f/yf00HQtpiXQIRHr2fJMWXU2o=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=FJZ+QRIzawoWBRk3SP1g/xLZNIT0EDM7s9IsMZGZVtfAsZ6OBKu7vu9F2mF2W05GNHlgyx+cnq/W/8xNDwFpf8iky/1HuGl7IuRCmr7cbnCH4F20frzuzMpWnvzbk09vLGVy7Y6GbFkw2fOwoCo9i2jEU48jzaBSzaXPUU9hZgOowAFjkiSKVzEjrU+SBJ1YqjYfFiBKZUfCwDmaH3HGR96ic2322g0fa72lCshy4cNFzjp+dLzh4nCKyrTvPFshgr3VbpFNPP8pxdz6ohd82iWky45WcvU83b/nY2zw0CpNW6gKUTZkUu/LnCzx5K4BPF+wUJpfeTcklDc+Sg06mA== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=WwhqnV2hE55g0R8sRioY3Fxn+1amibo2fzk0W/0YeQr8NxA4VIl+wxyKFf7kz75pmHdAACn9rFO6fRmZkJzr316ZHkwe8ZosGF3JsbqivWZSa3I+bi4BmynC9Tpu/+Yh4LaEA9LXDdgmemPKduc0EPeNrIFZA3C11xeWnbaLonTMwnXlGd1ioKGINSWlpbSl8kgZK/e80Q+z3qd0uuKTMKkA4fh/XrWVWvwEGDSWXZp69WOEGyGWjr9fxdqC8URTF8Zjv/7sKhSo16/O/TqwtlZqi4p7QmEKIUqYBdCWIFZucDPI3q/PdF5nfpulXhAiwuSVGtZEL9dJBsfv9BiqQA==; Received: from [66.196.81.172] by nm14.bullet.mail.bf1.yahoo.com with NNFMP; 28 Oct 2014 19:58:13 -0000 Received: from [98.139.212.200] by tm18.bullet.mail.bf1.yahoo.com with NNFMP; 28 Oct 2014 19:58:13 -0000 Received: from [127.0.0.1] by omp1009.mail.bf1.yahoo.com with NNFMP; 28 Oct 2014 19:58:13 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 874329.90647.bm@omp1009.mail.bf1.yahoo.com Received: by 66.196.81.113; Tue, 28 Oct 2014 19:58:13 +0000 Date: Tue, 28 Oct 2014 19:58:12 +0000 (UTC) From: Bill Mills To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Message-ID: <174996737.1122991.1414526292227.JavaMail.yahoo@jws10658.mail.bf1.yahoo.com> In-Reply-To: <2061250451.14565.1414526005529.JavaMail.yahoo@jws10605.mail.bf1.yahoo.com> References: <20141026231809.3216.45800.idtracker@ietfa.amsl.com> <2061250451.14565.1414526005529.JavaMail.yahoo@jws10605.mail.bf1.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1122990_797263958.1414526292221" Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/-smt4OwxS6jQKMjwTHHVXivHSnA Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 19:58:19 -0000 ------=_Part_1122990_797263958.1414526292221 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Also the nae here "SPOP" is oging to be confusing with the POP token draft = that's been discussed for quite a while. =C2=A0Naming is allways horrible f= un, but this one is somewhat worse than some options. -bill =C2=A0=20 On Tuesday, October 28, 2014 12:53 PM, Bill Mills wrote: =20 The server needs to be able to enforce policy with S256 as being required.= =C2=A0This means that you need to add a new error under the OAuth error re= gistry in this spec that allows the server to indicate the required hash. -bill=20 On Sunday, October 26, 2014 4:18 PM, "internet-drafts@ietf.org" wrote: =20 =20 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 Working Group = of the IETF. =C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Symme= tric Proof of Possession for the OAuth Authorization Code Grant =C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 : Nat Sakimu= ra =C2=A0 =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 Naveen Agarwal =C2=A0=C2=A0=C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-ietf-oauth-s= pop-01.txt =C2=A0=C2=A0=C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 11 =C2=A0=C2=A0=C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 2014-10-= 26 Abstract: =C2=A0 The OAuth 2.0 public client utilizing Authorization Code Grant (RFC =C2=A0 6749 - 4.1) is susceptible to the code interception attack.=C2=A0 Th= is =C2=A0 specification describes a mechanism that acts as a control against =C2=A0 this threat. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-spop-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-spop-01 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 ------=_Part_1122990_797263958.1414526292221 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Also the nae here "SPOP" is oging to be confusing with the POP token dra= ft that's been discussed for quite a while.  Naming is allways horribl= e fun, but this one is somewhat worse than some options.

=
-bill  = ;


= On Tuesday, October 28, 2014 12:53 PM, Bil= l Mills <wmills_92105@yahoo.com> wrote:


=
The server needs to be able to = enforce policy with S256 as being required.  This means that you need = to add a new error under the OAuth error registry in this spec that allows = the server to indicate the required hash.

-bill


On Sunday, October 26, 2014 4:18 PM, "internet-dra= fts@ietf.org" <internet-drafts@ietf.org> wrote:



A New Internet-Draft is available = from the on-line Internet-Drafts directories.
This draft= is a work item of the Web Authorization Protocol Working Group of the IETF= .

        Title&nb= sp;         : Symmetric Proof of Possession for the OA= uth Authorization Code Grant
        = Authors        : Nat Sakimura
 =                     &nbs= p;   John Bradley
         =                 Naveen Agarwal
    Filename        : dra= ft-ietf-oauth-spop-01.txt
    Pages  =         : 11
    Date=             : 2014-10-26
Abstract:
  The OAuth 2.0 public c= lient utilizing Authorization Code Grant (RFC
  674= 9 - 4.1) is susceptible to the code interception attack.  This
  specification describes a mechanism that acts as a contr= ol against
  this threat.


The IETF datatracker status page for this dr= aft is:
https:= //datatracker.ietf.org/doc/draft-ietf-oauth-spop/
There's also a htmlized version available at:
http://tools.ietf.org/html/draf= t-ietf-oauth-spop-01

A diff from t= he previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-= oauth-spop-01


P= lease note that it may take a couple of minutes from the time of submission=
until the htmlized version and diff are available at too= ls.ietf.org.

Internet-Drafts are also = available by anonymous FTP at:
ft= p://ftp.ietf.org/internet-drafts/

= _______________________________________________
OAuth mai= ling list
OAut= h@ietf.org
https://ww= w.ietf.org/mailman/listinfo/oauth

=

------=_Part_1122990_797263958.1414526292221-- From nobody Wed Oct 29 11:20:34 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C4EC1A8782 for ; Wed, 29 Oct 2014 11:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.791 X-Spam-Level: X-Spam-Status: No, score=0.791 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7xgt87NoIel for ; Wed, 29 Oct 2014 11:20:20 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id 12FF41A8786 for ; Wed, 29 Oct 2014 11:20:16 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 436EAB2E317 for ; Wed, 29 Oct 2014 14:20:16 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id 3842052E123 for ; Wed, 29 Oct 2014 14:20:16 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.78]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.03.0174.001; Wed, 29 Oct 2014 14:20:15 -0400 From: "Richer, Justin P." To: "oauth@ietf.org WG" Thread-Topic: Shepherd Writeup for draft-ietf-oauth-dyn-reg-management-05 Thread-Index: AQHP86T8hzeBnNuWvUy3O9k7Bm6ajw== Date: Wed, 29 Oct 2014 18:20:15 +0000 Message-ID: References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.34.159] Content-Type: multipart/alternative; boundary="_000_F01950E6EFF14B9C83E9CC8DD713F706mitreorg_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/7F3BgmLVRA8HJ-x7ArVpCmTdqR4 Subject: [OAUTH-WG] Fwd: Shepherd Writeup for draft-ietf-oauth-dyn-reg-management-05 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 18:20:27 -0000 --_000_F01950E6EFF14B9C83E9CC8DD713F706mitreorg_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable FYI, this needed to be sent to the WG. Begin forwarded message: From: "Maciej Machulak (PGR)" > Subject: RE: Shepherd Writeup for draft-ietf-oauth-dyn-reg-management-05 Date: September 12, 2014 at 12:22:29 PM EDT To: "Richer, Justin P." >, Mike= Jones > Cc: Hannes Tschofenig >, John Bradley > Hi, I am also aware of no IPR. I don't think changes needed. Cloud Identity's software implements an earlier version, as far as I rememb= er. I will check and let you know. Kind regards, Maciej ________________________________ From: Richer, Justin P. [jricher@mitre.org] Sent: Friday, September 12, 2014 2:56 PM To: Mike Jones Cc: Hannes Tschofenig; John Bradley; Maciej Machulak (PGR) Subject: Re: Shepherd Writeup for draft-ietf-oauth-dyn-reg-management-05 1) I am aware of no IPR. 2) MITREid Connect, OxAuth -- Maciej, does CloudID offer the full managemen= t API in an UMA context? I thought it did but I'm not sure 3) I think it's ready, no changes are needed. -- Justin On Sep 11, 2014, at 9:13 PM, Mike Jones > wrote: I am aware of no IPR on the document. No changes are needed. Justin has im= plementation information. -- Mike ________________________________ From: Hannes Tschofenig Sent: =FD9/=FD11/=FD2014 5:03 PM To: Richer, Justin P.; Mike Jones; John Bradley; m.p.machulak@= ncl.ac.uk Subject: Shepherd Writeup for draft-ietf-oauth-dyn-reg-management-05 Hi guys, So far there was positive response regarding the publication of the documen= t as an Experimental RFC. I am going to start working on my shepherd write-= up and, as you know, I need your help. 1) IPR: I will need you to confirm that any and all appropriate IPR disclos= ures required for full conformance with the provisions of BCP 78 and BCP 79= have already been filed. I need this info on the mailing list so that I ca= n reference it. 2) Implementations: I need info regarding any implementation you guys are a= ware of. 3) Do you think that the document is ready for a last call or are there cha= nges you would like to make? Ciao Hannes -- IMPORTANT NOTICE: The contents of this email and any attachments are con= fidential 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. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Regist= ered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, R= egistered in England & Wales, Company No: 2548782 --_000_F01950E6EFF14B9C83E9CC8DD713F706mitreorg_ Content-Type: text/html; charset="windows-1256" Content-ID: <9F73F8532B71754EB6BFA0C1AA66960F@imc.mitre.org> Content-Transfer-Encoding: quoted-printable FYI, this needed to be sent to the WG.

Begin forwarded message:

From:= "Maciej Machulak = (PGR)" <Maciej.M= achulak@newcastle.ac.uk>
Subje= ct: RE: Shepherd Writeup for= draft-ietf-oauth-dyn-reg-management-05
Date:= September 12, 2014 at = 12:22:29 PM EDT
To: <= /b>"Richer, Justin P.&= quot; <jricher@mitre.org>, M= ike Jones <Michael.Jones@= microsoft.com>
Cc: <= /b>Hannes Tschofenig <Hannes.Tschofenig@arm.com>= ;, John Bradley <ve7jtb@ve7jtb.com<= /a>>

Hi,

I am also aware of no IPR. I don't think changes needed.

Cloud Identity's software implements an earlier version, as far as I r= emember. I will check and let you know.

Kind regards,
Maciej
From: Richer, Justin P. [jricher@mitre.org]
Sent: Friday, September 12, 2014 2:56 PM
To: Mike Jones
Cc: Hannes Tschofenig; John Bradley; Maciej Machulak (PGR)
Subject: Re: Shepherd Writeup for draft-ietf-oauth-dyn-reg-managemen= t-05

1) I am aware of no IPR.

2) MITREid Connect, OxAuth -- Maciej, does CloudID offer the full mana= gement API in an UMA context? I thought it did but I'm not sure

3) I think it's ready, no changes are needed.

 -- Justin


On Sep 11, 2014, at 9:13 PM, Mike Jones <Michael.Jones@microsoft.com> = wrote:

I am aware of= no IPR on the document. No changes are needed.  Justin has implementa= tion information.

-- Mike
From: Hannes Tschofenig=
Sent: =FD9/= =FD11/=FD2014 5:03 PM
To: Richer, Justin P.; Mike Jones= ; John Bradley; m.p.machulak@ncl.ac.uk
Subject: Sheph= erd Writeup for draft-ietf-oauth-dyn-reg-management-05

Hi guys,

So far there was positive response regarding the publication of the documen= t as an Experimental RFC. I am going to start working on my shepherd write-= up and, as you know, I need  your help.

1) IPR: I will need you to confirm that any and all appropriate IPR disclos= ures required for full conformance with the provisions of BCP 78 and BCP 79= have already been filed. I need this info on the mailing list so that I ca= n reference it.

2) Implementations: I need info regarding any implementation you guys are a= ware of.

3) Do you think that the document is ready for a last call or are there cha= nges you would like to make?

Ciao
Hannes


-- IMPORTANT NOTICE: The contents of this email and any attachments are con= fidential 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.<= br>
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Regist= ered in England & Wales, Company No:  2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, R= egistered in England & Wales, Company No:  2548782



--_000_F01950E6EFF14B9C83E9CC8DD713F706mitreorg_-- From nobody Wed Oct 29 11:20:50 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF4911A878C for ; Wed, 29 Oct 2014 11:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qw5iHgXCKJD8 for ; Wed, 29 Oct 2014 11:20:33 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id C1EFA1A877F for ; Wed, 29 Oct 2014 11:20:33 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 77DD8B2E319 for ; Wed, 29 Oct 2014 14:20:33 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id 6CF4CB2E315 for ; Wed, 29 Oct 2014 14:20:33 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.78]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.03.0174.001; Wed, 29 Oct 2014 14:20:33 -0400 From: "Richer, Justin P." To: "oauth@ietf.org WG" Thread-Topic: Shepherd Writeup for draft-ietf-oauth-dyn-reg-management-05 Thread-Index: AQHP86UHhzeBnNuWvUy3O9k7Bm6ajw== Date: Wed, 29 Oct 2014 18:20:32 +0000 Message-ID: <2929C815-C7ED-420E-BBA5-3A7EB5742551@mitre.org> References: <12E76FFE-5129-4642-A304-B257CC21CA0B@ve7jtb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.34.159] Content-Type: multipart/alternative; boundary="_000_2929C815C7ED420EBBA53A7EB5742551mitreorg_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/jKc5EcKyJYyMJznZ6_t7rl4W8Nk Subject: [OAUTH-WG] Fwd: Shepherd Writeup for draft-ietf-oauth-dyn-reg-management-05 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 18:20:38 -0000 --_000_2929C815C7ED420EBBA53A7EB5742551mitreorg_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable This *also* needed to be sent to the WG. Begin forwarded message: From: John Bradley > Subject: Re: Shepherd Writeup for draft-ietf-oauth-dyn-reg-management-05 Date: September 12, 2014 at 10:47:54 AM EDT To: Michael Jones > Cc: Hannes Tschofenig >, "Justin P. Richer" >,= "m.p.machulak@ncl.ac.uk" > I am, also aware of no IPR on the document. No changes required to my knowledge. John B. On Sep 11, 2014, at 10:13 PM, Mike Jones > wrote: I am aware of no IPR on the document. No changes are needed. Justin has im= plementation information. -- Mike ________________________________ From: Hannes Tschofenig Sent: =FD9/=FD11/=FD2014 5:03 PM To: Richer, Justin P.; Mike Jones; John Bradley; m.p.machulak@= ncl.ac.uk Subject: Shepherd Writeup for draft-ietf-oauth-dyn-reg-management-05 Hi guys, So far there was positive response regarding the publication of the documen= t as an Experimental RFC. I am going to start working on my shepherd write-= up and, as you know, I need your help. 1) IPR: I will need you to confirm that any and all appropriate IPR disclos= ures required for full conformance with the provisions of BCP 78 and BCP 79= have already been filed. I need this info on the mailing list so that I ca= n reference it. 2) Implementations: I need info regarding any implementation you guys are a= ware of. 3) Do you think that the document is ready for a last call or are there cha= nges you would like to make? Ciao Hannes -- IMPORTANT NOTICE: The contents of this email and any attachments are con= fidential 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. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Regist= ered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, R= egistered in England & Wales, Company No: 2548782 --_000_2929C815C7ED420EBBA53A7EB5742551mitreorg_ Content-Type: text/html; charset="windows-1256" Content-ID: Content-Transfer-Encoding: quoted-printable This *also* needed to be sent to the WG.

Begin forwarded message:

From:= John Bradley <ve7jtb@ve7jtb.com>
Subje= ct: Re: Shepherd Writeup for= draft-ietf-oauth-dyn-reg-management-05
Date:= September 12, 2014 at = 10:47:54 AM EDT
To: <= /b>Michael Jones <Michael.Jones@microsoft.com>= ;
Cc: <= /b>Hannes Tschofenig <Hannes.Tschofenig@arm.com>= ;, "Justin P. Richer" <jr= icher@mitre.org>, "m.p.machulak@ncl.ac.uk= " <m.p.machulak@ncl.ac.uk= >

I am, also aware of no IPR on the document.

No changes required to my knowledge.

John B.

On Sep 11, 2014, at 10:13 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

I am awar= e of no IPR on the document. No changes are needed.  Justin has implem= entation information.

-- Mike
From: <= span style=3D"font-family: Calibri, sans-serif; font-size: 11pt;">Hannes Tschofenig
Sent: <= span style=3D"font-family: Calibri, sans-serif; font-size: 11pt;">=FD9/=FD1= 1/=FD2014 5:03 PM
To: Richer, Justin P.; Mike Jones; John Bradley; m.p.machulak@ncl= .ac.uk
Subject: Shephe= rd Writeup for draft-ietf-oauth-dyn-reg-management-05

Hi guys,

So far there was positive response regarding the publication of the documen= t as an Experimental RFC. I am going to start working on my shepherd write-= up and, as you know, I need  your help.

1) IPR: I will need you to confirm that any and all appropriate IPR disclos= ures required for full conformance with the provisions of BCP 78 and BCP 79= have already been filed. I need this info on the mailing list so that I ca= n reference it.

2) Implementations: I need info regarding any implementation you guys are a= ware of.

3) Do you think that the document is ready for a last call or are there cha= nges you would like to make?

Ciao
Hannes


-- IMPORTANT NOTICE: The contents of this email and any attachments are con= fidential 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.<= br>
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Regist= ered in England & Wales, Company No:  2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, R= egistered in England & Wales, Company No:  2548782


--_000_2929C815C7ED420EBBA53A7EB5742551mitreorg_-- From nobody Wed Oct 29 11:24:13 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18C1D1A8786 for ; Wed, 29 Oct 2014 11:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.151 X-Spam-Level: ** X-Spam-Status: No, score=2.151 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 H62H8htoiZao for ; Wed, 29 Oct 2014 11:24:07 -0700 (PDT) Received: from BLU004-OMC1S25.hotmail.com (blu004-omc1s25.hotmail.com [65.55.116.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 077851A878C for ; Wed, 29 Oct 2014 11:23:54 -0700 (PDT) Received: from BLU406-EAS226 ([65.55.116.7]) by BLU004-OMC1S25.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Wed, 29 Oct 2014 11:23:54 -0700 X-TMN: [mgiNy+53/bnW10CTHpvOEAspFNjHPrQ1] X-Originating-Email: [panca70@outlook.com] Message-ID: Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Client-ID: 476 X-Mailer: BlackBerry Email (10.2.1.3247) Date: Thu, 30 Oct 2014 01:23:47 +0700 From: Panca Agus Ananda To: oauth@ietf.org X-OriginalArrivalTime: 29 Oct 2014 18:23:54.0258 (UTC) FILETIME=[7EFB3720:01CFF3A5] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/kjQN6SidBFHcPD_G3QxBQPiqrEw Subject: [OAUTH-WG] Bls: OAuth Digest, Vol 72, Issue 80 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 18:24:08 -0000 =20 From nobody Wed Oct 29 11:24:15 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A43B31A8786 for ; Wed, 29 Oct 2014 11:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.973 X-Spam-Level: X-Spam-Status: No, score=0.973 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 1z02_GeolvF8 for ; Wed, 29 Oct 2014 11:24:07 -0700 (PDT) Received: from BLU004-OMC1S14.hotmail.com (blu004-omc1s14.hotmail.com [65.55.116.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80A7C1A8792 for ; Wed, 29 Oct 2014 11:24:00 -0700 (PDT) Received: from BLU406-EAS226 ([65.55.116.8]) by BLU004-OMC1S14.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Wed, 29 Oct 2014 11:23:59 -0700 X-TMN: [2oVUMzXaCobRkaecAhhJqU0w9qSqDBPY] X-Originating-Email: [panca70@outlook.com] Message-ID: Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Client-ID: 477 X-Mailer: BlackBerry Email (10.2.1.3247) Date: Thu, 30 Oct 2014 01:23:58 +0700 From: Panca Agus Ananda To: oauth@ietf.org X-OriginalArrivalTime: 29 Oct 2014 18:23:59.0807 (UTC) FILETIME=[8249ECF0:01CFF3A5] Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/XU_vF9z2N96ghsB9xKkNeQrkCok Subject: [OAUTH-WG] Bls: OAuth Digest, Vol 72, Issue 80 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 18:24:08 -0000

= =

= =
Dikirim dari ponsel cerdas BlackBerry 10 saya dengan = jaringan Telkomsel.
= =
<= div id=3D"_persistentHeader" style=3D"border-style: solid none none; border= -top-color: rgb(181, 196, 223); border-top-width: 1pt; padding: 3pt 0in 0in= ; font-family: Tahoma, 'BB Alpha Sans', 'Slate Pro'; font-size: 10pt;"> Dari: oauth-request@ietf.org
Terkirim: Kamis, 30= Oktober 2014 01.20
Ke: oauth@ietf.org
Balas = Ke: oauth@ietf.org
Perihal: OAuth Digest, Vol 72, Issu= e 80

From nobody Wed Oct 29 11:39:40 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41B031A8841 for ; Wed, 29 Oct 2014 11:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltcOBenv-WPG for ; Wed, 29 Oct 2014 11:39:32 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0A9A1A8829 for ; Wed, 29 Oct 2014 11:39:31 -0700 (PDT) Received: from [192.168.10.209] ([64.71.18.60]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0M4WRI-1Y0F6D1LR6-00yh4R for ; Wed, 29 Oct 2014 19:39:30 +0100 Message-ID: <5451345E.2070004@gmx.net> Date: Wed, 29 Oct 2014 19:39:26 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "oauth@ietf.org" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="eq1QvQMofMEwn6tntgXlNAcHhi3MtSIRV" X-Provags-ID: V03:K0:cMouZxrsk64lcqfVWCgJ1FCqd5gE7CvB01UptYqLHDiUqrqRvg5 cz1Tr5ygRhbH5k00oC/d1qazASDDJpI0wYtE4gyg0bJCNDmdx+DCCJYidyWEZH+hWtqypHk 2W5aWnIUlNHjJ/3SaNSbHOAPBZPTFKKqQR+B4uZAo3asvGZeKunR3EM1fCj1y6cUoRJG1JH gNzVgB6mNMxFHEGIBmvRg== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/isxoY-Wy7CKJFwIboX-f1biLXxE Subject: [OAUTH-WG] Shepherd Writeup for Dynamic Client Registration Management X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 18:39:37 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --eq1QvQMofMEwn6tntgXlNAcHhi3MtSIRV Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, in earlier discussions in the working group we decided to change the status of the Dynamic Client Registration Management specification from Standards Track to an Experimental RFC. This will help to gain implementation and deployment experience. In order to advance the document I have started to produce my shepherd writeup: https://github.com/hannestschofenig/tschofenig-ids/blob/master/shepherd-w= riteups/Writeup_OAuth_DynRegManagement.txt Your feedback, is as always, appreciated! Ciao Hannes --eq1QvQMofMEwn6tntgXlNAcHhi3MtSIRV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUUTReAAoJEGhJURNOOiAt858H/2WkpIHQkgas9ClXx/jT2tYm Jc2TwyfHptfxdpaL6gdX+hUNrD5+FqPpEbHEjetPaJSb1rCFApdYUsbxw3EZs7CM FMTQgXDYnV+w1EqUP7nKKL6CL7DxNTXsjDEcTyf5Wt8kHLFe0SVNkuH3yd0SANdo 6g9F1zU5Jy4V5JyFhPT2kT+FerhHd31XCcA+LA7GmksS3a+t2pVFDrODLaiqfZTa gLI0kUjZgo0H0iaGH9P2hfqy4nsHpiqzIyMgFttMK9fJgbnv+ZCZjP6Nx1trWMYO SVWCRopSJP0YH9A2OOV4odDvalOiHTmSoWAnMRVxcvTN2n2kSVvvsnpF+QPETEU= =e5Vt -----END PGP SIGNATURE----- --eq1QvQMofMEwn6tntgXlNAcHhi3MtSIRV-- From nobody Wed Oct 29 15:12:00 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 602CA1A1B0B for ; Wed, 29 Oct 2014 15:11:57 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XURXCte2bjAR for ; Wed, 29 Oct 2014 15:11:55 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0702.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:702]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B62C61A911F for ; Wed, 29 Oct 2014 15:11:54 -0700 (PDT) Received: from BN3PR0301CA0011.namprd03.prod.outlook.com (25.160.180.149) by BN3PR0301MB1203.namprd03.prod.outlook.com (25.161.207.156) with Microsoft SMTP Server (TLS) id 15.1.6.9; Wed, 29 Oct 2014 22:11:31 +0000 Received: from BN1AFFO11FD014.protection.gbl (2a01:111:f400:7c10::181) by BN3PR0301CA0011.outlook.office365.com (2a01:111:e400:4000::21) with Microsoft SMTP Server (TLS) id 15.1.11.14 via Frontend Transport; Wed, 29 Oct 2014 22:11:31 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD014.mail.protection.outlook.com (10.58.52.74) with Microsoft SMTP Server (TLS) id 15.0.1049.20 via Frontend Transport; Wed, 29 Oct 2014 22:11:30 +0000 Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.93]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.03.0210.003; Wed, 29 Oct 2014 22:10:49 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: Shepherd Writeup for draft-ietf-oauth-dyn-reg-management-05 Thread-Index: Ac/OHDp1FlhKhoVdREKp896d1bMjFAACo+hwCWeXSDA= Date: Wed, 29 Oct 2014 22:10:48 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739439BB31E86@TK5EX14MBXC286.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739439AEBE09E@TK5EX14MBXC292.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439AEBE09E@TK5EX14MBXC292.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.32] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439BB31E86TK5EX14MBXC286r_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(438002)(189002)(199003)(40434003)(377454003)(77096002)(85806002)(86362001)(2656002)(92566001)(71186001)(85852003)(87936001)(92726001)(50986999)(2501002)(76176999)(54356999)(86612001)(84326002)(19300405004)(69596002)(55846006)(81156004)(76482002)(84676001)(31966008)(33656002)(15975445006)(44976005)(19580395003)(68736004)(19580405001)(107886001)(230783001)(46102003)(2351001)(80022003)(19625215002)(26826002)(99396003)(110136001)(97736003)(16236675004)(85306004)(20776003)(66066001)(95666004)(106466001)(4396001)(15202345003)(107046002)(64706001)(6806004)(21056001)(120916001)(104016003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1203; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1203; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 03793408BA Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=Michael.Jones@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/ICnYuutZ6zAt8ribXgFJgZ13J-4 Subject: [OAUTH-WG] FW: Shepherd Writeup for draft-ietf-oauth-dyn-reg-management-05 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 22:11:57 -0000 --_000_4E1F6AAD24975D4BA5B16804296739439BB31E86TK5EX14MBXC286r_ Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Forwarding to the working group=85 From: Mike Jones Sent: Thursday, September 11, 2014 6:14 PM To: Hannes Tschofenig; Richer, Justin P.; John Bradley; m.p.machulak@ncl.ac= .uk Subject: RE: Shepherd Writeup for draft-ietf-oauth-dyn-reg-management-05 I am aware of no IPR on the document. No changes are needed. Justin has im= plementation information. -- Mike ________________________________ From: Hannes Tschofenig Sent: =FD9/=FD11/=FD2014 5:03 PM To: Richer, Justin P.; Mike Jones; John Bradley; m.p.machulak@= ncl.ac.uk Subject: Shepherd Writeup for draft-ietf-oauth-dyn-reg-management-05 Hi guys, So far there was positive response regarding the publication of the documen= t as an Experimental RFC. I am going to start working on my shepherd write-= up and, as you know, I need your help. 1) IPR: I will need you to confirm that any and all appropriate IPR disclos= ures required for full conformance with the provisions of BCP 78 and BCP 79= have already been filed. I need this info on the mailing list so that I ca= n reference it. 2) Implementations: I need info regarding any implementation you guys are a= ware of. 3) Do you think that the document is ready for a last call or are there cha= nges you would like to make? Ciao Hannes -- IMPORTANT NOTICE: The contents of this email and any attachments are con= fidential 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. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Regist= ered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, R= egistered in England & Wales, Company No: 2548782 --_000_4E1F6AAD24975D4BA5B16804296739439BB31E86TK5EX14MBXC286r_ Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable

Forwarding to the working= group=85

 <= /p>

From: Mike Jon= es
Sent: Thursday, September 11, 2014 6:14 PM
To: Hannes Tschofenig; Richer, Justin P.; John Bradley; m.p.machulak= @ncl.ac.uk
Subject: RE: Shepherd Writeup for draft-ietf-oauth-dyn-reg-managemen= t-05

 

I am aware of no IPR on the document. N= o changes are needed.  Justin has implementation information.

-- Mike

From: Hannes= Tschofenig
Sent: =FD9/=FD11/=FD2014 5:03 PM
To: Richer, Justin P.; Mike Jones; John Bradley; m.p.machulak@nc= l.ac.uk
Subject: Shepherd Writeup for draft-ietf-oauth-dyn-reg-management-0= 5

Hi guys,

So far there was positive response regarding the publication of the documen= t as an Experimental RFC. I am going to start working on my shepherd write-= up and, as you know, I need  your help.

1) IPR: I will need you to confirm that any and all appropriate IPR disclos= ures required for full conformance with the provisions of BCP 78 and BCP 79= have already been filed. I need this info on the mailing list so that I ca= n reference it.

2) Implementations: I need info regarding any implementation you guys are a= ware of.

3) Do you think that the document is ready for a last call or are there cha= nges you would like to make?

Ciao
Hannes


-- IMPORTANT NOTICE: The contents of this email and any attachments are con= fidential 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.<= br>
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Regist= ered in England & Wales, Company No:  2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, R= egistered in England & Wales, Company No:  2548782

--_000_4E1F6AAD24975D4BA5B16804296739439BB31E86TK5EX14MBXC286r_-- From nobody Wed Oct 29 17:54:55 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1463A1ACDB5 for ; Wed, 29 Oct 2014 17:54:54 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6MewMk-hBsqm for ; Wed, 29 Oct 2014 17:54:51 -0700 (PDT) Received: from mail-pd0-f175.google.com (mail-pd0-f175.google.com [209.85.192.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6BD51ACE93 for ; Wed, 29 Oct 2014 17:54:51 -0700 (PDT) Received: by mail-pd0-f175.google.com with SMTP id y13so4045772pdi.34 for ; Wed, 29 Oct 2014 17:54:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:content-transfer-encoding :mime-version:subject:message-id:date:references:to; bh=8r9aH/XI2iuc24QdzEbbvq1W4CDUkMhB4+hqKpqs0ZQ=; b=bohOCw264Vam1E+mUdFfTgcX3v8Ppvb5Jzgq6Y2BjItKWmhe+H5Oi0G8hSepL/n1DM r/XxaCpvT43Q03cdPzIXxqWgsohv+wnj5XT8MOaybsTGUgzRGAL2AZ+qt5UnyFG4IJUS sg8aCBJTB4P3kYL2QedHzs/WTiXcM+7j1EaO7W/aHTSx/Xb4yDl3JwXcvz73746WFyuV 9ed8iUYCAPEPtlsjvln48prGSmPXMhebAPPShITrTELozK0hGq5yCKMU4BnZIHfsxnm+ iBZRKiOtbrLsD5LAfd83UfAU4n/GobsPyJ8OfMtJ+9g5DTz3g+T9qLBgVPYbImFFl14k IJNg== X-Gm-Message-State: ALoCoQlK5XiYcbyQhF+x67bL7qAvAMe5rXe4qX5GxEG1ykanS7tSSKImS87d0E6+Ymzj2TVNSzDc X-Received: by 10.68.136.226 with SMTP id qd2mr13733386pbb.55.1414630491271; Wed, 29 Oct 2014 17:54:51 -0700 (PDT) Received: from [10.255.135.162] (sjspeed.wiline.com. [64.71.18.60]) by mx.google.com with ESMTPSA id v10sm5378854pbs.64.2014.10.29.17.54.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 29 Oct 2014 17:54:50 -0700 (PDT) From: John Bradley Content-Type: multipart/alternative; boundary=Apple-Mail-4399AC92-1B31-4E44-9DA5-EC58D30E0566 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Message-Id: Date: Wed, 29 Oct 2014 17:54:49 -0700 References: <2929C815-C7ED-420E-BBA5-3A7EB5742551@mitre.org> To: oauth X-Mailer: iPhone Mail (12B411) Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/yE1ZiwJlC7dEFNWdebUx9TH1nng Subject: [OAUTH-WG] Fwd: Fwd: Shepherd Writeup for draft-ietf-oauth-dyn-reg-management-05 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 00:54:54 -0000 --Apple-Mail-4399AC92-1B31-4E44-9DA5-EC58D30E0566 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sent from my iPhone Begin forwarded message: > From: "Richer, Justin P." > Date: October 29, 2014 at 11:20:32 AM PDT > To: "oauth@ietf.org WG" > Subject: [OAUTH-WG] Fwd: Shepherd Writeup for draft-ietf-oauth-dyn-reg-man= agement-05 >=20 > This *also* needed to be sent to the WG. >=20 > Begin forwarded message: >=20 >> From: John Bradley >> Subject: Re: Shepherd Writeup for draft-ietf-oauth-dyn-reg-management-05 >> Date: September 12, 2014 at 10:47:54 AM EDT >> To: Michael Jones >> Cc: Hannes Tschofenig , "Justin P. Richer" , "m.p.machulak@ncl.ac.uk" >>=20 >> I am, also aware of no IPR on the document. >>=20 >> No changes required to my knowledge. >>=20 >> John B. >>=20 >>> On Sep 11, 2014, at 10:13 PM, Mike Jones w= rote: >>>=20 >>> I am aware of no IPR on the document. No changes are needed. Justin has= implementation information. >>>=20 >>> -- Mike >>> From: Hannes Tschofenig >>> Sent: =E2=80=8E9/=E2=80=8E11/=E2=80=8E2014 5:03 PM >>> To: Richer, Justin P.; Mike Jones; John Bradley; m.p.machulak@ncl.ac.uk >>> Subject: Shepherd Writeup for draft-ietf-oauth-dyn-reg-management-05 >>>=20 >>> Hi guys, >>>=20 >>> So far there was positive response regarding the publication of the docu= ment as an Experimental RFC. I am going to start working on my shepherd writ= e-up and, as you know, I need your help. >>>=20 >>> 1) IPR: I will need you to confirm that any and all appropriate IPR disc= losures required for full conformance with the provisions of BCP 78 and BCP 7= 9 have already been filed. I need this info on the mailing list so that I ca= n reference it. >>>=20 >>> 2) Implementations: I need info regarding any implementation you guys ar= e aware of. >>>=20 >>> 3) Do you think that the document is ready for a last call or are there c= hanges you would like to make? >>>=20 >>> Ciao >>> Hannes >>>=20 >>>=20 >>> -- IMPORTANT NOTICE: The contents of this email and any attachments are c= onfidential 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 a= ny other person, use it for any purpose, or store or copy the information in= any medium. Thank you. >>>=20 >>> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Reg= istered in England & Wales, Company No: 2557590 >>> ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ= , Registered in England & Wales, Company No: 2548782 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-4399AC92-1B31-4E44-9DA5-EC58D30E0566 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


Sent from my iPhone
=
Begin forwarded message:

= From: "Richer, Justin P." <jrich= er@mitre.org>
Date: October 29, 2014 at 11:20:32 AM PDT
= To: "oauth@ietf.org WG" <oauth@ietf.org>
Subject: [= OAUTH-WG] Fwd: Shepherd Writeup for draft-ietf-oauth-dyn-reg-management-05

This *also* needed to be sent to the WG.

Begin forwarded message:

From: <= /b>John Bradley <ve7jtb@ve7jtb.com>
Subjec= t: Re: Shepherd Writeup for d= raft-ietf-oauth-dyn-reg-management-05
Date: <= /b>September 12, 2014 at 10:= 47:54 AM EDT
To: Michael Jones <Michael.Jones@microsoft.com>
=
Cc: Hannes Tschofenig <Hannes.Tschofenig@arm.com>, "= Justin P. Richer" <jricher@mitre.org= >, "m.p.machulak@ncl.ac.uk" <= m.p.machulak@ncl.ac.uk>
=

I am, also aware of no IPR on the document.

No changes required to my knowledge.

John B.

On Sep 11, 2014, at 10:13 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

I am aware= of no IPR on the document. No changes are needed.  Justin has implemen= tation information.

-- Mike
From: Hannes Tschofenig
Sent: =E2=80=8E9/=E2= =80=8E11/=E2=80=8E2014 5:03 PM
To: Richer, Justin P.; Mike Jones; John Bradley; m.p.machulak@ncl.ac= .uk
Subject: = Shepherd W= riteup for draft-ietf-oauth-dyn-reg-management-05

Hi guys,

So far there was positive response regarding the publication of the document= as an Experimental RFC. I am going to start working on my shepherd write-up= and, as you know, I need  your help.

1) IPR: I will need you to confirm that any and all appropriate IPR disclosu= res required for full conformance with the provisions of BCP 78 and BCP 79 h= ave already been filed. I need this info on the mailing list so that I can r= eference it.

2) Implementations: I need info regarding any implementation you guys are aw= are of.

3) Do you think that the document is ready for a last call or are there chan= ges you would like to make?

Ciao
Hannes


-- IMPORTANT NOTICE: The contents of this email and any attachments are conf= idential 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 o= ther person, use it for any purpose, or store or copy the information in any medium.  Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registe= red in England & Wales, Company No:  2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Re= gistered in England & Wales, Company No:  2548782


____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-4399AC92-1B31-4E44-9DA5-EC58D30E0566-- From nobody Thu Oct 30 09:13:11 2014 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 555A61A0030 for ; Thu, 30 Oct 2014 09:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FqGOIMhJUWs7 for ; Thu, 30 Oct 2014 09:13:06 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BF501A0005 for ; Thu, 30 Oct 2014 09:13:06 -0700 (PDT) Received: from [192.168.10.214] ([64.71.18.60]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MSdz2-1Xc4sG0sZI-00RUvJ for ; Thu, 30 Oct 2014 17:13:04 +0100 Message-ID: <545261A6.3080409@gmx.net> Date: Thu, 30 Oct 2014 17:04:54 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "oauth@ietf.org" OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="uGRV2iD2KNT3qBiwV9U3UPPciRS5wNWhQ" X-Provags-ID: V03:K0:0sPVjxZwofiBqBk3hGB9OYGjGTMLlk27MVofqEGDtwbAd4Fbmay ys/pZbGu9P+BmMvvLRI2mdFCSZCjjLCaknCXLs1RpJggi+bgXj53RKTFquAom85cR4cwZ21 xV1GMedKKRVBW1JsMLFjh7yykHpwd3KhW/eFtdIuYLIu92OXtrUEjIG8n6VGQGpFxWvrmrd i+qDGeX+jnDswWmLV85+A== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/2IwBAHvx5oanSfkow0sbP6Xv2ZY Subject: [OAUTH-WG] Agenda X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 16:13:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --uGRV2iD2KNT3qBiwV9U3UPPciRS5wNWhQ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, we prepared a first draft of the agenda for the meeting. Let us know whether there is anything to add. Here is the link: http://www.ietf.org/proceedings/91/agenda/agenda-91-oauth Ciao Hannes & Derek --uGRV2iD2KNT3qBiwV9U3UPPciRS5wNWhQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUUmGmAAoJEGhJURNOOiAt0bMH/jP65LPZJsULmEUudNh0LbcE ahELr50ZVBL2+nKnWGFwLYtWknSeB79PM8CP8E1KuxxtngWIqRGYjY3P+4Yrc/oU orSSbNghaKR5f6uy8L8fR4jW+/XBblkX45OT/wzzXjW5gaA440Bqmi4eAl36Nzzb Y0MpWZ3Bs2fPRA8i18ai4YprwFYF6o/TZtTfE9z1Az44YmIoQVY4jWxPWqeC9HnL mPXBLUQ+AXJikvtMPNcv2JomKrkcg3wAWp8/WHeJ3qQLecZ7RfGs/RACrT/GSTpS wbatNkK+N5+4nDkVN4WIYKYBx0ZIPSIPFo6v3a/AsC5+NFXcDhw2lSBb337uur4= =4sT3 -----END PGP SIGNATURE----- --uGRV2iD2KNT3qBiwV9U3UPPciRS5wNWhQ--