From nobody Mon Dec 5 10:30:26 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62F81129C6F for ; Mon, 5 Dec 2016 10:30:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.097 X-Spam-Level: X-Spam-Status: No, score=-7.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wFAWJqne-hJA for ; Mon, 5 Dec 2016 10:30:23 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 B9865129C6E for ; Mon, 5 Dec 2016 10:30:21 -0800 (PST) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id uB5IUKD7012907 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 5 Dec 2016 18:30:21 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id uB5IUKSd018443 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 5 Dec 2016 18:30:20 GMT Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id uB5IUIVm013819 for ; Mon, 5 Dec 2016 18:30:19 GMT Received: from [10.0.1.30] (/24.86.208.48) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 05 Dec 2016 10:30:18 -0800 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_E10E14DB-6B65-4B28-80AB-D4E6BCFBE36D" Date: Mon, 5 Dec 2016 10:30:17 -0800 To: ID Events Mailing List Message-Id: <6F54C6BE-F4AA-4FE7-99F3-2D6CFB46602F@oracle.com> Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Subject: [Id-event] Welcome the chairs and first action items X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 18:30:25 -0000 --Apple-Mail=_E10E14DB-6B65-4B28-80AB-D4E6BCFBE36D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99d like to welcome our new chairs, Dick Hardt and Yaron Sheffer = to the WG! Thanks for agreeing to take this on! Updates of note: Mike Jones and I recently revised the SET draft and it is now ready for = consideration for WG adoption: https://tools.ietf.org/html/draft-hunt-idevent-token-07 = During some of the informal meetings we had a lot of discussion around = the distribution draft and its current data model for management of = event feeds. There was also some more discussion on the OpenID RISC WG = call about this. In order to move things forward, I would like to = propose that the distribution draft (draft-hunt-idevent-distribution-01) = be split into 2 documents: * Transmission - The foundational HTTP POST distribution method. * Feed Control - Defines how subscribers register for, update, and = operationally manage feeds they are receiving. =46rom my perspective, the benefit of splitting out transmission is that = we can move it forward as a WG document quicker and continue to work on = the control plane requirements as a separate thread. Chairs, can you call for consensus on: 1. Adoption of SET Draft = (https://tools.ietf.org/html/draft-hunt-idevent-token-07 = ) as a WG draft 2. Splitting the SET distribution draft into two drafts Thanks! Phil @independentid www.independentid.com = phil.hunt@oracle.com = --Apple-Mail=_E10E14DB-6B65-4B28-80AB-D4E6BCFBE36D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I=E2=80=99d like to welcome our new chairs, Dick Hardt and = Yaron Sheffer to the WG!  Thanks for agreeing to take this on!

Updates of = note:

Mike = Jones and I recently revised the SET draft and it is now = ready for consideration for WG adoption:
https://tools.ietf.org/html/draft-hunt-idevent-token-07

During some of = the informal meetings we had a lot of discussion around the distribution = draft and its current data model for management of event feeds. There = was also some more discussion on the OpenID RISC WG call about this. In = order to move things forward, I would like to propose that = the distribution draft (draft-hunt-idevent-distribution-01) be split = into 2 documents:
*  Transmission - The = foundational HTTP POST distribution method.
* =  Feed Control - Defines how subscribers register for, update, and = operationally manage feeds they are receiving.

=46rom my perspective, the benefit of = splitting out transmission is that we can move it forward as a WG = document quicker and continue to work on the control plane requirements = as a separate thread.

Chairs, can you call for consensus on:
1. =  Adoption of SET Draft (https://tools.ietf.org/html/draft-hunt-idevent-token-07) = as a WG draft

2.=  Splitting the SET distribution draft into two drafts

Thanks!




= --Apple-Mail=_E10E14DB-6B65-4B28-80AB-D4E6BCFBE36D-- From nobody Mon Dec 5 11:40:27 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 809591295AE for ; Mon, 5 Dec 2016 11:40:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECnJpYkfhSLm for ; Mon, 5 Dec 2016 11:40:19 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0105.outbound.protection.outlook.com [104.47.37.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1F60129594 for ; Mon, 5 Dec 2016 11:40:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=D4JvyDIzq1i6xRmH1IH7/ccrFRL1GF3hedOWiddb3lo=; b=Zf9qQWqj7sirZ99vA7+OvuzQSWb8Vg4DRypZHx9Kh/eb/yRe8ud8pLOKfaaIlwRL+4wwpcRreYkAaNg3olZh0vW9RMgrSwUym8rxW5jBbpQebU1jH+rgtDY4JzoTRgHgnOQyj44ynLst0Xlk/ge71k1NHGwREVIGCHJnmtwgr34= Received: from BN3PR03MB2355.namprd03.prod.outlook.com (10.166.74.150) by BN3PR03MB2355.namprd03.prod.outlook.com (10.166.74.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.761.9; Mon, 5 Dec 2016 19:40:16 +0000 Received: from BN3PR03MB2355.namprd03.prod.outlook.com ([10.166.74.150]) by BN3PR03MB2355.namprd03.prod.outlook.com ([10.166.74.150]) with mapi id 15.01.0761.016; Mon, 5 Dec 2016 19:40:16 +0000 From: Mike Jones To: Dick Hardt , Yaron Sheffer Thread-Topic: [Id-event] Welcome the chairs and first action items Thread-Index: AQHSTyWpiJtUWd9uK0uQTaCqR2bMZKD5v4eg Date: Mon, 5 Dec 2016 19:40:16 +0000 Message-ID: References: <6F54C6BE-F4AA-4FE7-99F3-2D6CFB46602F@oracle.com> In-Reply-To: <6F54C6BE-F4AA-4FE7-99F3-2D6CFB46602F@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.80.137] x-ms-office365-filtering-correlation-id: 3801d37f-1603-4cdf-feb8-08d41d468a15 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN3PR03MB2355; x-microsoft-exchange-diagnostics: 1; BN3PR03MB2355; 7:8hZICe/HzO408jFQCirnoOzmL5IPgj6kZNHAjj1j9EEk3TFWzZgRwSw/ZZVYd4pqFB7C1Q0vuXwf2OVi62SiCnKFUr27XIB47dyNVeRXKq0N0nkiY8Z+n6hQLcA7qCHxFh+uzz0E+EUh1RhZCa2q9uQ1Kryf51Ac1Fgb+bfEQHPvyRK62pBagIXMZooHSdRUZBVMLYMttN2SzqGwX0c6s0YFtp+4MSO5C7ESDARyZluJr0LdXdCf7xbG7Tz4KyPcpmkVjfOVWfDF+MmxrBZiOJTSkKeHCEIdZcLy574POVqLH7k32U7en2SXi4EBQ76topwMPCooap6WELu4L7cgYcmytL8Q4KgU+0pSksj75qc0jIC5w5Fmuugt2cDPuAcUfjjn7yaYzK61hTxm7dpf9yun0gy8qtHff6MggldZj0H9jhBENOYkXBVRRYn2ZFPCC8CK0sN4Ogi+fNBIMEPr704gcyK/0GkZxyn2hItw+Ck= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(100405760836317)(21748063052155)(146099531331640); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123562025)(20161123564025)(20161123555025)(6047074)(6072148); SRVR:BN3PR03MB2355; BCL:0; PCL:0; RULEID:; SRVR:BN3PR03MB2355; x-forefront-prvs: 0147E151B5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(377454003)(51414003)(189002)(7846002)(92566002)(5001770100001)(81156014)(8936002)(97736004)(106356001)(16601075003)(105586002)(99286002)(3280700002)(66066001)(3846002)(10290500002)(189998001)(8990500004)(102836003)(106116001)(6116002)(76176999)(54356999)(790700001)(10090500001)(50986999)(19609705001)(68736007)(9686002)(86362001)(3660700001)(86612001)(39850400001)(101416001)(2906002)(4326007)(2950100002)(8676002)(74316002)(39060400001)(39450400002)(5005710100001)(5660300001)(38730400001)(7736002)(122556002)(6506006)(7906003)(39410400001)(606004)(2900100001)(229853002)(76576001)(33656002)(7696004)(77096006)(39840400001)(81166006)(1680700002)(39860400001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR03MB2355; H:BN3PR03MB2355.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR03MB23558A6DC46D177038669EB6F5830BN3PR03MB2355namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Dec 2016 19:40:16.5444 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR03MB2355 Archived-At: Cc: ID Events Mailing List , Phil Hunt Subject: Re: [Id-event] Welcome the chairs and first action items X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 19:40:24 -0000 --_000_BN3PR03MB23558A6DC46D177038669EB6F5830BN3PR03MB2355namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzLCBEaWNrIGFuZCBZYXJvbiwgZm9yIHZvbHVudGVlcmluZyB0byBzZXJ2ZSB0aGUgSUVU RiBjb21tdW5pdHkgaW4gdGhpcyB3YXkuICBJIGxvb2sgZm9yd2FyZCB0byB3b3JraW5nIHdpdGgg eW91IQ0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBJZC1ldmVudCBbbWFpbHRvOmlkLWV2ZW50LWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQaGlsIEh1bnQNClNlbnQ6IE1vbmRheSwgRGVjZW1iZXIg NSwgMjAxNiAxMDozMCBBTQ0KVG86IElEIEV2ZW50cyBNYWlsaW5nIExpc3QgPGlkLWV2ZW50QGll dGYub3JnPg0KU3ViamVjdDogW0lkLWV2ZW50XSBXZWxjb21lIHRoZSBjaGFpcnMgYW5kIGZpcnN0 IGFjdGlvbiBpdGVtcw0KDQpJ4oCZZCBsaWtlIHRvIHdlbGNvbWUgb3VyIG5ldyBjaGFpcnMsIERp Y2sgSGFyZHQgYW5kIFlhcm9uIFNoZWZmZXIgdG8gdGhlIFdHISAgVGhhbmtzIGZvciBhZ3JlZWlu ZyB0byB0YWtlIHRoaXMgb24hDQoNClVwZGF0ZXMgb2Ygbm90ZToNCg0KTWlrZSBKb25lcyBhbmQg SSByZWNlbnRseSByZXZpc2VkIHRoZSBTRVQgZHJhZnQgYW5kIGl0IGlzIG5vdyByZWFkeSBmb3Ig Y29uc2lkZXJhdGlvbiBmb3IgV0cgYWRvcHRpb246DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaHVudC1pZGV2ZW50LXRva2VuLTA3DQoNCkR1cmluZyBzb21lIG9mIHRoZSBpbmZv cm1hbCBtZWV0aW5ncyB3ZSBoYWQgYSBsb3Qgb2YgZGlzY3Vzc2lvbiBhcm91bmQgdGhlIGRpc3Ry aWJ1dGlvbiBkcmFmdCBhbmQgaXRzIGN1cnJlbnQgZGF0YSBtb2RlbCBmb3IgbWFuYWdlbWVudCBv ZiBldmVudCBmZWVkcy4gVGhlcmUgd2FzIGFsc28gc29tZSBtb3JlIGRpc2N1c3Npb24gb24gdGhl IE9wZW5JRCBSSVNDIFdHIGNhbGwgYWJvdXQgdGhpcy4gSW4gb3JkZXIgdG8gbW92ZSB0aGluZ3Mg Zm9yd2FyZCwgSSB3b3VsZCBsaWtlIHRvIHByb3Bvc2UgdGhhdCB0aGUgZGlzdHJpYnV0aW9uIGRy YWZ0IChkcmFmdC1odW50LWlkZXZlbnQtZGlzdHJpYnV0aW9uLTAxKSBiZSBzcGxpdCBpbnRvIDIg ZG9jdW1lbnRzOg0KKiAgVHJhbnNtaXNzaW9uIC0gVGhlIGZvdW5kYXRpb25hbCBIVFRQIFBPU1Qg ZGlzdHJpYnV0aW9uIG1ldGhvZC4NCiogIEZlZWQgQ29udHJvbCAtIERlZmluZXMgaG93IHN1YnNj cmliZXJzIHJlZ2lzdGVyIGZvciwgdXBkYXRlLCBhbmQgb3BlcmF0aW9uYWxseSBtYW5hZ2UgZmVl ZHMgdGhleSBhcmUgcmVjZWl2aW5nLg0KDQpGcm9tIG15IHBlcnNwZWN0aXZlLCB0aGUgYmVuZWZp dCBvZiBzcGxpdHRpbmcgb3V0IHRyYW5zbWlzc2lvbiBpcyB0aGF0IHdlIGNhbiBtb3ZlIGl0IGZv cndhcmQgYXMgYSBXRyBkb2N1bWVudCBxdWlja2VyIGFuZCBjb250aW51ZSB0byB3b3JrIG9uIHRo ZSBjb250cm9sIHBsYW5lIHJlcXVpcmVtZW50cyBhcyBhIHNlcGFyYXRlIHRocmVhZC4NCg0KQ2hh aXJzLCBjYW4geW91IGNhbGwgZm9yIGNvbnNlbnN1cyBvbjoNCjEuICBBZG9wdGlvbiBvZiBTRVQg RHJhZnQgKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1odW50LWlkZXZlbnQtdG9r ZW4tMDcpIGFzIGEgV0cgZHJhZnQNCg0KMi4gIFNwbGl0dGluZyB0aGUgU0VUIGRpc3RyaWJ1dGlv biBkcmFmdCBpbnRvIHR3byBkcmFmdHMNCg0KVGhhbmtzIQ0KDQpQaGlsDQoNCkBpbmRlcGVuZGVu dGlkDQp3d3cuaW5kZXBlbmRlbnRpZC5jb208aHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNvbT4N CnBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4NCg0KDQoN Cg0K --_000_BN3PR03MB23558A6DC46D177038669EB6F5830BN3PR03MB2355namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uYXBwbGUtc3R5bGUtc3Bhbg0K CXttc28tc3R5bGUtbmFtZTphcHBsZS1zdHlsZS1zcGFuO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGlu O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojMDAyMDYwIj5UaGFua3MsIERpY2sgYW5kIFlhcm9uLCBmb3Igdm9sdW50ZWVyaW5nIHRvIHNl cnZlIHRoZSBJRVRGIGNvbW11bml0eSBpbiB0aGlzIHdheS4mbmJzcDsgSSBsb29rIGZvcndhcmQg dG8gd29ya2luZyB3aXRoIHlvdSE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21w b3NlIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9hPjwvcD4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48L3Nw YW4+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFF MUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+RnJvbTo8L2I+IElkLWV2ZW50IFttYWlsdG86aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9y Z10gPGI+DQpPbiBCZWhhbGYgT2YgPC9iPlBoaWwgSHVudDxicj4NCjxiPlNlbnQ6PC9iPiBNb25k YXksIERlY2VtYmVyIDUsIDIwMTYgMTA6MzAgQU08YnI+DQo8Yj5Ubzo8L2I+IElEIEV2ZW50cyBN YWlsaW5nIExpc3QgJmx0O2lkLWV2ZW50QGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9i PiBbSWQtZXZlbnRdIFdlbGNvbWUgdGhlIGNoYWlycyBhbmQgZmlyc3QgYWN0aW9uIGl0ZW1zPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J4oCZZCBsaWtlIHRvIHdlbGNv bWUgb3VyIG5ldyBjaGFpcnMsIERpY2sgSGFyZHQgYW5kIFlhcm9uIFNoZWZmZXIgdG8gdGhlIFdH ISAmbmJzcDtUaGFua3MgZm9yIGFncmVlaW5nIHRvIHRha2UgdGhpcyBvbiE8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlVwZGF0ZXMgb2Ygbm90ZTo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWlrZSBKb25l cyBhbmQgSSByZWNlbnRseSByZXZpc2VkIHRoZSBTRVQgZHJhZnQgYW5kIGl0IGlzIDx1Pg0Kbm93 IHJlYWR5IGZvciBjb25zaWRlcmF0aW9uIGZvciBXRyBhZG9wdGlvbjwvdT46PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaHVudC1pZGV2ZW50LXRva2VuLTA3Ij5odHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaHVudC1pZGV2ZW50LXRva2VuLTA3PC9hPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EdXJpbmcg c29tZSBvZiB0aGUgaW5mb3JtYWwgbWVldGluZ3Mgd2UgaGFkIGEgbG90IG9mIGRpc2N1c3Npb24g YXJvdW5kIHRoZSBkaXN0cmlidXRpb24gZHJhZnQgYW5kIGl0cyBjdXJyZW50IGRhdGEgbW9kZWwg Zm9yIG1hbmFnZW1lbnQgb2YgZXZlbnQgZmVlZHMuIFRoZXJlIHdhcyBhbHNvIHNvbWUgbW9yZSBk aXNjdXNzaW9uIG9uIHRoZSBPcGVuSUQgUklTQyBXRyBjYWxsIGFib3V0IHRoaXMuIEluIG9yZGVy DQogdG8gbW92ZSB0aGluZ3MgZm9yd2FyZCwgPHU+SSB3b3VsZCBsaWtlIHRvIHByb3Bvc2UgdGhh dCB0aGUgZGlzdHJpYnV0aW9uIGRyYWZ0IChkcmFmdC1odW50LWlkZXZlbnQtZGlzdHJpYnV0aW9u LTAxKSBiZSBzcGxpdCBpbnRvIDIgZG9jdW1lbnRzPC91Pjo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiogJm5ic3A7VHJhbnNtaXNzaW9uIC0gVGhl IGZvdW5kYXRpb25hbCBIVFRQIFBPU1QgZGlzdHJpYnV0aW9uIG1ldGhvZC48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiogJm5ic3A7RmVlZCBDb250 cm9sIC0gRGVmaW5lcyBob3cgc3Vic2NyaWJlcnMgcmVnaXN0ZXIgZm9yLCB1cGRhdGUsIGFuZCBv cGVyYXRpb25hbGx5IG1hbmFnZSBmZWVkcyB0aGV5IGFyZSByZWNlaXZpbmcuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZyb20gbXkgcGVyc3Bl Y3RpdmUsIHRoZSBiZW5lZml0IG9mIHNwbGl0dGluZyBvdXQgdHJhbnNtaXNzaW9uIGlzIHRoYXQg d2UgY2FuIG1vdmUgaXQgZm9yd2FyZCBhcyBhIFdHIGRvY3VtZW50IHF1aWNrZXIgYW5kIGNvbnRp bnVlIHRvIHdvcmsgb24gdGhlIGNvbnRyb2wgcGxhbmUgcmVxdWlyZW1lbnRzIGFzIGEgc2VwYXJh dGUgdGhyZWFkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5DaGFpcnMsIGNhbiB5b3UgY2FsbCBmb3IgY29uc2Vuc3VzIG9uOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MS4gJm5ic3A7QWRvcHRp b24gb2YgU0VUIERyYWZ0ICg8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaHVudC1pZGV2ZW50LXRva2VuLTA3Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaHVudC1pZGV2ZW50LXRva2VuLTA3PC9hPikgYXMgYSBXRyBkcmFmdDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yLiAmbmJzcDtTcGxpdHRp bmcgdGhlIFNFVCBkaXN0cmlidXRpb24gZHJhZnQgaW50byB0d28gZHJhZnRzPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyE8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPlBoaWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+QGluZGVwZW5kZW50aWQ8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPjxhIGhyZWY9Imh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20iPnd3dy5p bmRlcGVuZGVudGlkLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIj5waGlsLmh1bnRA b3JhY2xlLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BN3PR03MB23558A6DC46D177038669EB6F5830BN3PR03MB2355namp_-- From nobody Mon Dec 5 15:34:00 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6482F129E79 for ; Mon, 5 Dec 2016 15:33:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.596 X-Spam-Level: X-Spam-Status: No, score=-5.596 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_LOW=-0.7, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZiUW2KYfBiUt for ; Mon, 5 Dec 2016 15:33:57 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2620A129621 for ; Mon, 5 Dec 2016 15:33:57 -0800 (PST) Received: by mail-wm0-x235.google.com with SMTP id t79so108762569wmt.0 for ; Mon, 05 Dec 2016 15:33:57 -0800 (PST) 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; bh=/J50O8eK7S+wfnOeIm+x/psI35Eq0Gr8JP7HiWVA5+o=; b=nrqGMmoMuDnjZ6A9EjM+U+31oXZ7adnVQnDMM2dSopH4CsKeMLqL+K0nFNGyVvHg8N lHZeMUsXTlO/mfh3elF/+sZ8+8pXvZZlg48KnRCkVg9d6U2X4kQblA9mVbnKNeFhDlJ0 YoX/XMLmZpDQ+2fVkxXwbqOBWBMAqxHqp9IgTnKLR2uU5vq3/aCHRPBc5gtvk4+xzCIu bOY7oEuHIGLJ707ipqjrKQ75cy5Rx1Xlg60EIcg+IM0eWJkBnHE73kCmaAYvdNH191eB xl078Zl8smohHQkp/35j2vvr63TpknXYD9MNjzyhfcrpjeS3Z0+Wwox5fU+GnWe4eWQk lSaQ== 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; bh=/J50O8eK7S+wfnOeIm+x/psI35Eq0Gr8JP7HiWVA5+o=; b=ZBG26t6LmuCQKqSGeHOoxyY8bxiwESpJ+jLTO4XxcMBvy3Z/RdNxmL8Fyq8TshsPrK M2F616qvnKsZBlPICWWes1jPa7X/1AYXlWIAX6AVpVXgjCzUpo03eDQvxznxYFZvK1Me d4x5k4/9qD/lDAPdFBD/HaQ+NN+yl0EMEhE2u4vD+m6RSt6WMuCvIpIbE9KsIPgjbmOH L//n71KJ3S8TozfqRMdc1RBUvhQJkG1l26cPtfSckdAxqObXaiUCM3SPdJI9WqNsnQpn 472OfiVHNqEj2ZVQMdrtWVdBHo7hF0FQXxaLsdihQSunEU2QsmDVJycameDCZnmKvKAZ gYag== X-Gm-Message-State: AKaTC01D4n4s2a6MtfsWi+IFbT4sDzA6pWqyoe2Z9XedCrZDUzqvT8rmxjFzYq4m2x8cqUjl1AsWvngk5V6cTpG4 X-Received: by 10.28.7.130 with SMTP id 124mr88730wmh.18.1480980834029; Mon, 05 Dec 2016 15:33:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.31.21 with HTTP; Mon, 5 Dec 2016 15:33:53 -0800 (PST) In-Reply-To: <6F54C6BE-F4AA-4FE7-99F3-2D6CFB46602F@oracle.com> References: <6F54C6BE-F4AA-4FE7-99F3-2D6CFB46602F@oracle.com> From: Adam Dawes Date: Mon, 5 Dec 2016 15:33:53 -0800 Message-ID: To: Phil Hunt Content-Type: multipart/alternative; boundary=001a1144267a8875c10542f1b862 Archived-At: Cc: ID Events Mailing List Subject: Re: [Id-event] Welcome the chairs and first action items X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 23:33:59 -0000 --001a1144267a8875c10542f1b862 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I strongly support splitting the distribution spec in two parts. I think Google will be able to make good progress with an experimental RISC implementation using the event token spec + basic transmission. This will give us some valuable real world experience to guide use cases for feed control and to firm up the event token and basic transmission specs. On Mon, Dec 5, 2016 at 10:30 AM, Phil Hunt wrote: > I=E2=80=99d like to welcome our new chairs, Dick Hardt and Yaron Sheffer = to the > WG! Thanks for agreeing to take this on! > > Updates of note: > > Mike Jones and I recently revised the SET draft and it is *now ready for > consideration for WG adoption*: > https://tools.ietf.org/html/draft-hunt-idevent-token-07 > > During some of the informal meetings we had a lot of discussion around th= e > distribution draft and its current data model for management of event > feeds. There was also some more discussion on the OpenID RISC WG call abo= ut > this. In order to move things forward, *I would like to propose that the > distribution draft (draft-hunt-idevent-distribution-01) be split into 2 > documents*: > * Transmission - The foundational HTTP POST distribution method. > * Feed Control - Defines how subscribers register for, update, and > operationally manage feeds they are receiving. > > From my perspective, the benefit of splitting out transmission is that we > can move it forward as a WG document quicker and continue to work on the > control plane requirements as a separate thread. > > Chairs, can you call for consensus on: > 1. Adoption of SET Draft (https://tools.ietf.org/html/ > draft-hunt-idevent-token-07) as a WG draft > > 2. Splitting the SET distribution draft into two drafts > > Thanks! > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > --=20 Adam Dawes | Sr. Product Manager | adawes@google.com | +1 650-214-2410 --001a1144267a8875c10542f1b862 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I strongly support splitting the distribution spec in two = parts. I think Google will be able to make good progress with an experiment= al RISC implementation using the event token spec + basic transmission. Thi= s will give us some valuable real world experience to guide use cases for f= eed control and to firm up the event token and basic transmission specs.=C2= =A0

On Mon, = Dec 5, 2016 at 10:30 AM, Phil Hunt <phil.hunt@oracle.com>= wrote:
I=E2=80=99d like to welcome our new chairs, Dick Hardt and Yaron Sheffer= to the WG!=C2=A0 Thanks for agreeing to take this on!

U= pdates of note:

Mike Jones and I recently revised = the SET draft and it is now ready for consideration for WG adoption:=

During some of the informal meetings w= e had a lot of discussion around the distribution draft and its current dat= a model for management of event feeds. There was also some more discussion = on the OpenID RISC WG call about this. In order to move things forward, = I would like to propose that the distribution draft (draft-hunt-idevent-distribution-01) be split into 2 documents:
* =C2=A0Transmi= ssion - The foundational HTTP POST distribution method.
* =C2=A0F= eed Control - Defines how subscribers register for, update, and operational= ly manage feeds they are receiving.

From my perspe= ctive, the benefit of splitting out transmission is that we can move it for= ward as a WG document quicker and continue to work on the control plane req= uirements as a separate thread.

Chairs, can you ca= ll for consensus on:
1.=C2=A0 Adoption of SET Draft (h= ttps://tools.ietf.org/html/draft-hunt-idevent-token-07) as a WG dr= aft

2.=C2=A0 Splitting the SET distribution draft = into two drafts

Thanks!





_______________________________________________ Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event




--
--001a1144267a8875c10542f1b862-- From nobody Tue Dec 6 20:51:52 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6604C129477 for ; Tue, 6 Dec 2016 20:51:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztjYtGBv1CK1 for ; Tue, 6 Dec 2016 20:51:49 -0800 (PST) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC7A1129500 for ; Tue, 6 Dec 2016 20:51:47 -0800 (PST) Received: by mail-yw0-x22c.google.com with SMTP id a10so291121325ywa.3 for ; Tue, 06 Dec 2016 20:51:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=Oy/yC5rXH3gdzOUGGillgmIzN56cXgx3diTHY5W7xIE=; b=JkWHten7TEzpRaYot5IrdF+YJOtbI8e+Az27ubwQjQhUoF7Um7kSqAZUcFjLVeH+b6 GwIbFT+Qqml9slXwI1K78vrPVmZWfqrlyBbRkedNmaNaAMRdKCBOiJzeewtY8ghws2bt p8DER6s3evSYsNYZCQvMe/CAG7BZP97Q6UHL+6wcXxtvvPpaGyexZyhW7zdFtRRl+NkX FKtWZGl8RyXE3hA8UyndU7ucS4Fm1v3EeNTYfzXWQkJSUuqptNl9KEMt9aFIT+eQmyQb h9p+a1a1utmNr6SoFMYTsgAVXp8OsSpeM1U/WKZdnRon6gnCRSz094wJ/9VEYti4rL0c YgWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=Oy/yC5rXH3gdzOUGGillgmIzN56cXgx3diTHY5W7xIE=; b=B5BxCdWOTN8lXWxgl6KYn6UhJmA0k7rA4bY8ICsumnO3d0xvr0ck2g92v71ecNC5eJ Rhk2MFMmv/MXod/MkUj5FQSfajmCLvNpmqU4UJmowmw5fgMqNAVcJqG5vrVjDwZPzO1w pVXYRCR9KIC+jgw6WIowYq1FZ32MklOa52lueg8RLfYq8mmhy0VJQK9Lp36XK40kPU/8 UaGqIZo/nK1q8YKWm0FKsmUjLMUThz2f7BscBEdnf4h4EPp1YWo3DAKdgCDMsMWZT87P ixUobdgaV07RA5loyR7Qipe9y2CRxo8sk+1aOJJeLDe3k32PxCQq/OjYCxW2z30vfNVm 5fqg== X-Gm-Message-State: AKaTC01usQA/cDErIGgEdCbpToJQWhXSOGBDCg19XahN2XX1kHIDVSlmErtLLHSu404eMA== X-Received: by 10.129.70.196 with SMTP id t187mr63276982ywa.307.1481086306736; Tue, 06 Dec 2016 20:51:46 -0800 (PST) Received: from ?IPv6:2602:306:3280:5cf0:58e6:857f:9296:2563? ([2602:306:3280:5cf0:58e6:857f:9296:2563]) by smtp.gmail.com with ESMTPSA id d63sm9643521ywb.12.2016.12.06.20.51.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Dec 2016 20:51:45 -0800 (PST) To: Adam Dawes , Phil Hunt References: <6F54C6BE-F4AA-4FE7-99F3-2D6CFB46602F@oracle.com> From: Yaron Sheffer Message-ID: <3825870f-6469-997c-a12d-aaa284949ec2@gmail.com> Date: Tue, 6 Dec 2016 20:51:32 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------8C44EE7255D002EDCAB925F6" Archived-At: Cc: ID Events Mailing List Subject: Re: [Id-event] Welcome the chairs and first action items X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 04:51:51 -0000 This is a multi-part message in MIME format. --------------8C44EE7255D002EDCAB925F6 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Thank you all for the warm welcome! Dick and I are both traveling this week, we will connect when we're both back and decide on the next steps. Yaron On 05/12/16 15:33, Adam Dawes wrote: > I strongly support splitting the distribution spec in two parts. I > think Google will be able to make good progress with an experimental > RISC implementation using the event token spec + basic transmission. > This will give us some valuable real world experience to guide use > cases for feed control and to firm up the event token and basic > transmission specs. > > On Mon, Dec 5, 2016 at 10:30 AM, Phil Hunt > wrote: > > I’d like to welcome our new chairs, Dick Hardt and Yaron Sheffer > to the WG! Thanks for agreeing to take this on! > > Updates of note: > > Mike Jones and I recently revised the SET draft and it is _now > ready for consideration for WG adoption_: > https://tools.ietf.org/html/draft-hunt-idevent-token-07 > > > During some of the informal meetings we had a lot of discussion > around the distribution draft and its current data model for > management of event feeds. There was also some more discussion on > the OpenID RISC WG call about this. In order to move things > forward, _I would like to propose that the distribution draft > (draft-hunt-idevent-distribution-01) be split into 2 documents_: > * Transmission - The foundational HTTP POST distribution method. > * Feed Control - Defines how subscribers register for, update, > and operationally manage feeds they are receiving. > > From my perspective, the benefit of splitting out transmission is > that we can move it forward as a WG document quicker and continue > to work on the control plane requirements as a separate thread. > > Chairs, can you call for consensus on: > 1. Adoption of SET Draft > (https://tools.ietf.org/html/draft-hunt-idevent-token-07 > ) as a WG > draft > > 2. Splitting the SET distribution draft into two drafts > > Thanks! > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > > > > > -- > Adam Dawes | Sr. Product Manager |adawes@google.com > | +1 650-214-2410 > --------------8C44EE7255D002EDCAB925F6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Thank you all for the warm welcome!

Dick and I are both traveling this week, we will connect when we're both back and decide on the next steps.

    Yaron


On 05/12/16 15:33, Adam Dawes wrote:
I strongly support splitting the distribution spec in two parts. I think Google will be able to make good progress with an experimental RISC implementation using the event token spec + basic transmission. This will give us some valuable real world experience to guide use cases for feed control and to firm up the event token and basic transmission specs. 

On Mon, Dec 5, 2016 at 10:30 AM, Phil Hunt <phil.hunt@oracle.com> wrote:
I’d like to welcome our new chairs, Dick Hardt and Yaron Sheffer to the WG!  Thanks for agreeing to take this on!

Updates of note:

Mike Jones and I recently revised the SET draft and it is now ready for consideration for WG adoption:

During some of the informal meetings we had a lot of discussion around the distribution draft and its current data model for management of event feeds. There was also some more discussion on the OpenID RISC WG call about this. In order to move things forward, I would like to propose that the distribution draft (draft-hunt-idevent-distribution-01) be split into 2 documents:
*  Transmission - The foundational HTTP POST distribution method.
*  Feed Control - Defines how subscribers register for, update, and operationally manage feeds they are receiving.

From my perspective, the benefit of splitting out transmission is that we can move it forward as a WG document quicker and continue to work on the control plane requirements as a separate thread.

Chairs, can you call for consensus on:
1.  Adoption of SET Draft (https://tools.ietf.org/html/draft-hunt-idevent-token-07) as a WG draft

2.  Splitting the SET distribution draft into two drafts

Thanks!


_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event




--
Adam Dawes | Sr. Product Manager | adawes@google.com | +1 650-214-2410

--------------8C44EE7255D002EDCAB925F6-- From nobody Sat Dec 10 13:27:46 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A81D129516 for ; Sat, 10 Dec 2016 13:27:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.874 X-Spam-Level: X-Spam-Status: No, score=-0.874 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, HTTP_ESCAPED_HOST=1.125, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8FmZi27n4Gx for ; Sat, 10 Dec 2016 13:27:43 -0800 (PST) Received: from mail-wj0-x236.google.com (mail-wj0-x236.google.com [IPv6:2a00:1450:400c:c01::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89A5F1294E5 for ; Sat, 10 Dec 2016 13:27:42 -0800 (PST) Received: by mail-wj0-x236.google.com with SMTP id tg4so41821638wjb.1 for ; Sat, 10 Dec 2016 13:27:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:to:message-id:date:user-agent:mime-version; bh=4hLA2I8B49tKN9NFwa3OxjVPptTpFdbM4k/yM9V92Cg=; b=BnHv8UC1stZZ/4xco1tfNEpRSDx71qQXoYiGntji9zlp80++jP8Ztu/4XMZjE1WftG H3wLrUKXMDhmmEC/E6gyEN6FvbknxpXc2GnGyFhsX7O1bGKRKgBbZMjRuOLPRh3qp0aL nd1xto0eSGbwr0nkE5Qd2sWjJZW55+Ede0arlO7TpN05/iJSx45yMu1fjLKA95iADuQm MIUcqXzKPsTzSOBQKaLyZjiIifHc11q6rWX4kSgZBe+Tid0cpO46LVvBA6g/69hytays ec+Dp5dn8sWc9262B+LRl9fDI1PrLpqF5qhhCXgVVfGbW0Azw+1kNHryBbpvsnL7/NIu iizg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version; bh=4hLA2I8B49tKN9NFwa3OxjVPptTpFdbM4k/yM9V92Cg=; b=Fe9bVZQmAQVnVGcnR7uiuRITxyMeABZdXWUtU8om1dly+Q4pM+JtQg5/v23P373VAI YH1QKvlzaZdjLnHO5jSQ0hcdvt5iPbWzdnSNgFU06OY9NIgBj8btQWNpaAeqTBXHK1MT mMz1lKfsZKqwsl1t+QZnm1Xtj/ldY3qQnDc6RLREMj372FUAkqniRHlp4qdix1h0tTuF IV/TgFwn6y5rs+/nkFuLp81Dd9Npb9LBayFndAn/Y9WSvZFL9jHQJZVkaZn3v2xAiDZs MgyG2snT28bZC9/EO9Jqgv+IqSYG56ufXXMShjosBgdeq/qf7FBVqeurUt6u1HRdpL97 N5Qw== X-Gm-Message-State: AKaTC00LA0jLMYdLXmxuNi/cx0QqxIXBBxUfh+wMQyedjJChzwtqjeSWNmEu10ADHZFZJQ== X-Received: by 10.194.87.230 with SMTP id bb6mr84914747wjb.163.1481405260502; Sat, 10 Dec 2016 13:27:40 -0800 (PST) Received: from [10.0.0.10] (bzq-79-180-116-150.red.bezeqint.net. [79.180.116.150]) by smtp.gmail.com with ESMTPSA id g17sm49313027wjs.38.2016.12.10.13.27.38 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 10 Dec 2016 13:27:39 -0800 (PST) From: Yaron Sheffer To: SecEvent Message-ID: <9114f681-cba9-b6d3-8369-ccd9193ce1b8@gmail.com> Date: Sat, 10 Dec 2016 23:27:37 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------FA801932A8099F57E0F830BD" Archived-At: Subject: [Id-event] Some comments to draft-hunt-idevent-token-07 X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2016 21:27:45 -0000 This is a multi-part message in MIME format. --------------FA801932A8099F57E0F830BD Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi, I finally read the draft in detail, and I do have a few comments. My main suggestion is to tighten the specification of an Event, by defining more strictly the difference between "event" and "event extension" and tweaking the JSON structure a bit. In addition, I think we should require the claim to be signed, since it will be used for security-sensitive activities across complex distributed systems. * 1: Why is signing optional? The publisher doesn't know how the subscriber's system is architected, and might well want end-to-end authentication of the claim. This is also important for auditing. * 1: "example events" - is specification of individual events (maybe only a few basic ones) within scope of our charter? Otherwise we cannot guarantee interop. * 1.2: principle -> principal * 2: "first value" is meaningless. JSON objects are unordered (4th paragraph of RFC 7159). If order/is/ important, we could make "events" into an array. * 2: event extensions are not defined but only introduced by the text after they are described. Also, in the example there's this URL:https://​example.​com/​scim/​event/​pas​swor​dRes​etEx​t - I believe it needs to be part of the passwordReset object and not parallel to it. * Why "events" and not "event"? We don't really have support for multiple events. Certainly not if they are all of the same type. The current text is confusing: "events" is not the same as "a primary event and its extensions". * "In the above example "iss" and "sub" contained within the claim" - this is incorrect, probably leftover from an earlier version. * "aud" MAY be a URI: shouldn't it be an array, maybe an array that contains a single URI? * Why do we use the terms "single-valued" vs. "multiple-valued" strings? Why not use the normal JSON terminology, "string" vs. "array of strings"? * Why is "sub" optional? Do we have any good examples of events where this value is not required? * "a future date" - we should clarify that there may be cases when nbf is smaller than iat, i.e. when it takes some time until the SET is issued. * "exp" - is it also a NumericDate? Please specify. * In the medical example, it is strange that the event is named by a URL that points to an HTML page. I would expect a more stable URI. * 2.2: is encryption a MUST whenever there are attributes specified? If so, we should have a normative section saying so, not just mention it in the context of an example. Besides, we have not defined what attributes are. * 2.2: this section is confusing. We first say that the JWT must be encrypted. But then instead, we sign it, and we "sign" with a null algorithm. Why? * Signed SETs MUST (not MAY) be validated by the subscriber. * Also, I think we should remove the preconditions and always require signing, as a MUST. An optional signature is actually a security loophole because an attacker can remove the signature, and the subscriber doesn't know that it's missing. * 3.2: "that alone will not guarantee that the correct subscribing party knows they should have received a particular SET." The text is unclear to me. Do we mean: "that alone does not guarantee that a particular SET was delivered to the correct subscribing party"? * We may want a separate Implementation Considerations section, and move "delivery", "sequencing" and "timing" into it. Yes they are security-relevant, just like anything else in this document, but they would apply just as well to any event stream protocol. * 3.3: this is the first time we mention provisioning. Do we really intend SETs to be used for that? * 3.3: ISTM that we should define a sequencing mechanism, rather than leave it open to profiles. E.g., require a sequence number whenever "txn" is used. * 3.4: Also, our timestamps only have 1 second granularity, and so are too coarse for session state (consider automated logins/logouts). * 3.5: Why don't we have an unambiguous way to distinguish SETs from access tokens, why leave it to implementers? Sounds like a major security issue in the making. We should consider here ALL implementations that accept access tokens, including legacy implementations that cannot be modified. * 4: The audit happens on the subscriber side. By then it is too late to require JWS to be used by the publisher. As mentioned, I propose that JWS should ALWAYS be required. * 4: "When sharing personally identifiable information" - we should remove this condition. I don't see a case where the information shared is NOT PII, and therefore legal agreements about information sharing and user consent must always be in place. * 4: I don't think the subject information is "perceived" as PII. It is PII, otherwise it would be useless to the subscriber, because the subscriber would not be able to identify the subject. Also, even if the information on the wire is not in itself PII, e.g. when using a hash, the fact that a publisher shares information that a particular user is also a user on its system and is undergoing certain state changes is privacy-sensitive. * I suggest to add an Implementation Status section, per RFC 7942. Thanks, Yaron --------------FA801932A8099F57E0F830BD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi, I finally read the draft in detail, and I do have a few comments.

My main suggestion is to tighten the specification of an Event, by defining more strictly the difference between "event" and "event extension" and tweaking the JSON structure a bit.

In addition, I think we should require the claim to be signed, since it will be used for security-sensitive activities across complex distributed systems.

  • 1: Why is signing optional? The publisher doesn't know how the subscriber's system is architected, and might well want end-to-end authentication of the claim. This is also important for auditing.
  • 1: "example events" - is specification of individual events (maybe only a few basic ones) within scope of our charter? Otherwise we cannot guarantee interop.
  • 1.2: principle -> principal
  • 2: "first value" is meaningless. JSON objects are unordered (4th paragraph of RFC 7159). If order is important, we could make "events" into an array.
  • 2: event extensions are not defined but only introduced by the text after they are described. Also, in the example there's this URL: https://​example.​com/​scim/​event/​pas​swor​dRes​etEx​t - I believe it needs to be part of the passwordReset object and not parallel to it.
  • Why "events" and not "event"? We don't really have support for multiple events. Certainly not if they are all of the same type. The current text is confusing: "events" is not the same as "a primary event and its extensions".
  • "In the above example "iss" and "sub" contained within the claim" - this is incorrect, probably leftover from an earlier version.
  • "aud" MAY be a URI: shouldn't it be an array, maybe an array that contains a single URI?
  • Why do we use the terms "single-valued" vs. "multiple-valued" strings? Why not use the normal JSON terminology, "string" vs. "array of strings"?
  • Why is "sub" optional? Do we have any good examples of events where this value is not required?
  • "a future date" - we should clarify that there may be cases when nbf is smaller than iat, i.e. when it takes some time until the SET is issued.
  • "exp" - is it also a NumericDate? Please specify.
  • In the medical example, it is strange that the event is named by a URL that points to an HTML page. I would expect a more stable URI.
  • 2.2: is encryption a MUST whenever there are attributes specified? If so, we should have a normative section saying so, not just mention it in the context of an example. Besides, we have not defined what attributes are.
  • 2.2: this section is confusing. We first say that the JWT must be encrypted. But then instead, we sign it, and we "sign" with a null algorithm. Why?
  • Signed SETs MUST (not MAY) be validated by the subscriber.
  • Also, I think we should remove the preconditions and always require signing, as a MUST. An optional signature is actually a security loophole because an attacker can remove the signature, and the subscriber doesn't know that it's missing.
  • 3.2: "that alone will not guarantee that the correct subscribing party knows they should have received a particular SET." The text is unclear to me. Do we mean: "that alone does not guarantee that a particular SET was delivered to the correct subscribing party"?
  • We may want a separate Implementation Considerations section, and move "delivery", "sequencing" and "timing" into it. Yes they are security-relevant, just like anything else in this document, but they would apply just as well to any event stream protocol.
  • 3.3: this is the first time we mention provisioning. Do we really intend SETs to be used for that?
  • 3.3: ISTM that we should define a sequencing mechanism, rather than leave it open to profiles. E.g., require a sequence number whenever "txn" is used.
  • 3.4: Also, our timestamps only have 1 second granularity, and so are too coarse for session state (consider automated logins/logouts).
  • 3.5: Why don't we have an unambiguous way to distinguish SETs from access tokens, why leave it to implementers? Sounds like a major security issue in the making. We should consider here ALL implementations that accept access tokens, including legacy implementations that cannot be modified.
  • 4: The audit happens on the subscriber side. By then it is too late to require JWS to be used by the publisher. As mentioned, I propose that JWS should ALWAYS be required.
  • 4: "When sharing personally identifiable information" - we should remove this condition. I don't see a case where the information shared is NOT PII, and therefore legal agreements about information sharing and user consent must always be in place.
  • 4: I don't think the subject information is "perceived" as PII. It is PII, otherwise it would be useless to the subscriber, because the subscriber would not be able to identify the subject. Also, even if the information on the wire is not in itself PII, e.g. when using a hash, the fact that a publisher shares information that a particular user is also a user on its system and is undergoing certain state changes is privacy-sensitive.
  • I suggest to add an Implementation Status section, per RFC 7942.

Thanks,

    Yaron

--------------FA801932A8099F57E0F830BD-- From nobody Sat Dec 10 13:32:55 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F7F612951B for ; Sat, 10 Dec 2016 13:32:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwtTmxAX1ro8 for ; Sat, 10 Dec 2016 13:32:52 -0800 (PST) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B254A129518 for ; Sat, 10 Dec 2016 13:32:51 -0800 (PST) Received: by mail-wm0-x22f.google.com with SMTP id a197so15946922wmd.0 for ; Sat, 10 Dec 2016 13:32:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version; bh=QEbMe6o8r34EGbN5AImabBiwcL/bIkmtzOfjfD8RKZg=; b=LW+w+pOyNs3QrmNs+bJ/1sWtx+BE3OsvYWhZpT3+tbNfsOOwhMwW7T6fZeVuz7Qc+G QYSEGtXjoHdDfyyQOOvOBZOO6L4JHQEYQSeZNQsJ0ve6KQsHcR7Kd7YDcB6yv42DiTZe U6dS8+JnBCQoWEgR7kS7gj9sVpdS5KiIE0J/vwYWyu/3z4wF/MEGEQeK9O94tGzglanm InWGMMX88l19ML3EIu1VFGaInHw+lcOETK/VJ45j/kg3rfjw6fxE56ESvhWdaFC4Y1LP mqWSspgaSAr47Ib3617oPFy6axZi7PdB0cSmoGPom2mjsMjIWNlui8jvRsEJHaXGAxGy mJBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version; bh=QEbMe6o8r34EGbN5AImabBiwcL/bIkmtzOfjfD8RKZg=; b=ZdhDkDeU9rh4pokzs3ZgSpet0JwT/8OknfSSKmoeJhCjYXV1hsY0Plzfi6NJSDmRxn 07gNAnA8gwJ++H2TYUSrORDyb3LBaQL6LA7fwmEWBX3xjSl9hbCQ1NrwDfOjHrrqDpqn cwXMxx2QmJ7tcFVOGTHLnGlP5Bqv7rW6ijJ+HzzYovOUe5J9WkSi2y7OrIep6Trbi9nB vKAt5R7puJ+A/Xh62pDYs8srwiUMsYf3o8zXP4Sy5iu2aF5lUCfTjQ/DYtcdRfQL+9s1 J/w7/q7uyDCtJ3IkDzdwBCu1cqMVa3LRsJgiZjobTFLacQ0I9D9mBb8njBjJ0JJZaEaP i9Cw== X-Gm-Message-State: AKaTC00lKHwHdJjixDJnaRJiBHuEc7HeVESwmbLt0ss8dkZxcVpRBQAOcUIrxmGMx4GENw== X-Received: by 10.28.216.9 with SMTP id p9mr11262045wmg.11.1481405569969; Sat, 10 Dec 2016 13:32:49 -0800 (PST) Received: from [10.0.0.10] (bzq-79-180-116-150.red.bezeqint.net. [79.180.116.150]) by smtp.gmail.com with ESMTPSA id yj10sm49344109wjb.3.2016.12.10.13.32.48 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 10 Dec 2016 13:32:49 -0800 (PST) To: ID Events Mailing List From: Yaron Sheffer Message-ID: Date: Sat, 10 Dec 2016 23:32:47 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------070CF03F704F21D3B1D8B1C8" Archived-At: Subject: [Id-event] And a few comments to draft-hunt-idevent-distribution-01 X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2016 21:32:53 -0000 This is a multi-part message in MIME format. --------------070CF03F704F21D3B1D8B1C8 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit It sounds reasonable to me to split this document in two, so here are a few comments to the "main" portion of this document. * methodUri should probably be methodUrn. * 5.3.1: SET validation and/or decryption should not rely on whether keys are specified in the subscription definition. For exmaple, the SET may be signed with a certificate that's available off-line. * Why 202 Accepted and not simply 200 OK? RFC 7231 states that for a 202, an application "ought to" provide a status polling endpoint. Are we planning to include such a thing? * Error description string: I think we should include a language tag, though I couldn't find a standard way to do it in JSON. Probably: "lang":"en-US". Thanks, Yaron --------------070CF03F704F21D3B1D8B1C8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

It sounds reasonable to me to split this document in two, so here are a few comments to the "main" portion of this document.

  • methodUri should probably be methodUrn.
  • 5.3.1: SET validation and/or decryption should not rely on whether keys are specified in the subscription definition. For exmaple, the SET may be signed with a certificate that's available off-line.
  • Why 202 Accepted and not simply 200 OK? RFC 7231 states that for a 202, an application "ought to" provide a status polling endpoint. Are we planning to include such a thing?
  • Error description string: I think we should include a language tag, though I couldn't find a standard way to do it in JSON. Probably: "lang":"en-US".

Thanks,

    Yaron

--------------070CF03F704F21D3B1D8B1C8-- From nobody Wed Dec 14 08:51:44 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD84129B85 for ; Wed, 14 Dec 2016 08:51:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.971 X-Spam-Level: X-Spam-Status: No, score=-5.971 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=1.125, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ZfrrmS8bH5u for ; Wed, 14 Dec 2016 08:51:40 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 892CB129B7F for ; Wed, 14 Dec 2016 08:51:40 -0800 (PST) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id uBEGpcav015322 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Dec 2016 16:51:38 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0021.oracle.com (8.13.8/8.14.4) with ESMTP id uBEGpbZr027362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Dec 2016 16:51:37 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id uBEGpaDS020873; Wed, 14 Dec 2016 16:51:36 GMT Received: from [192.168.1.22] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 14 Dec 2016 08:51:35 -0800 Content-Type: multipart/alternative; boundary=Apple-Mail-5589C1DE-8F99-4B13-8036-78CE1D5F82D0 Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (14B100) In-Reply-To: <9114f681-cba9-b6d3-8369-ccd9193ce1b8@gmail.com> Date: Wed, 14 Dec 2016 08:51:34 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: <9114f681-cba9-b6d3-8369-ccd9193ce1b8@gmail.com> To: Yaron Sheffer X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: SecEvent Subject: Re: [Id-event] Some comments to draft-hunt-idevent-token-07 X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 16:51:42 -0000 --Apple-Mail-5589C1DE-8F99-4B13-8036-78CE1D5F82D0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yaron, Thanks for your extensive feedback.=20 Apologies for my late response. I will respond shortly.=20 Phil > On Dec 10, 2016, at 1:27 PM, Yaron Sheffer wrote: >=20 > Hi, I finally read the draft in detail, and I do have a few comments. >=20 > My main suggestion is to tighten the specification of an Event, by definin= g more strictly the difference between "event" and "event extension" and twe= aking the JSON structure a bit. >=20 > In addition, I think we should require the claim to be signed, since it wi= ll be used for security-sensitive activities across complex distributed syst= ems. > 1: Why is signing optional? The publisher doesn't know how the subscriber'= s system is architected, and might well want end-to-end authentication of th= e claim. This is also important for auditing. > 1: "example events" - is specification of individual events (maybe only a f= ew basic ones) within scope of our charter? Otherwise we cannot guarantee in= terop. > 1.2: principle -> principal > 2: "first value" is meaningless. JSON objects are unordered (4th paragraph= of RFC 7159). If order is important, we could make "events" into an array. > 2: event extensions are not defined but only introduced by the text after t= hey are described. Also, in the example there's this URL: https://=E2=80=8Be= xample.=E2=80=8Bcom/=E2=80=8Bscim/=E2=80=8Bevent/=E2=80=8Bpas=E2=80=8Bswor=E2= =80=8BdRes=E2=80=8BetEx=E2=80=8Bt - I believe it needs to be part of the pas= swordReset object and not parallel to it. > Why "events" and not "event"? We don't really have support for multiple ev= ents. Certainly not if they are all of the same type. The current text is co= nfusing: "events" is not the same as "a primary event and its extensions". > "In the above example "iss" and "sub" contained within the claim" - this i= s incorrect, probably leftover from an earlier version. > "aud" MAY be a URI: shouldn't it be an array, maybe an array that contains= a single URI? > Why do we use the terms "single-valued" vs. "multiple-valued" strings? Why= not use the normal JSON terminology, "string" vs. "array of strings"? > Why is "sub" optional? Do we have any good examples of events where this v= alue is not required? > "a future date" - we should clarify that there may be cases when nbf is sm= aller than iat, i.e. when it takes some time until the SET is issued. > "exp" - is it also a NumericDate? Please specify. > In the medical example, it is strange that the event is named by a URL tha= t points to an HTML page. I would expect a more stable URI. > 2.2: is encryption a MUST whenever there are attributes specified? If so, w= e should have a normative section saying so, not just mention it in the cont= ext of an example. Besides, we have not defined what attributes are. > 2.2: this section is confusing. We first say that the JWT must be encrypte= d. But then instead, we sign it, and we "sign" with a null algorithm. Why? > Signed SETs MUST (not MAY) be validated by the subscriber. > Also, I think we should remove the preconditions and always require signin= g, as a MUST. An optional signature is actually a security loophole b= ecause an attacker can remove the signature, and the subscriber doesn't know= that it's missing. > 3.2: "that alone will not guarantee that the correct subscribing party kno= ws they should have received a particular SET." The text is unclear to me. D= o we mean: "that alone does not guarantee that a particular SET was delivere= d to the correct subscribing party"? > We may want a separate Implementation Considerations section, and move "de= livery", "sequencing" and "timing" into it. Yes they are security-relevant, j= ust like anything else in this document, but they would apply just as well t= o any event stream protocol. > 3.3: this is the first time we mention provisioning. Do we really intend S= ETs to be used for that? > 3.3: ISTM that we should define a sequencing mechanism, rather than leave = it open to profiles. E.g., require a sequence number whenever "txn" i= s used. > 3.4: Also, our timestamps only have 1 second granularity, and so are too c= oarse for session state (consider automated logins/logouts). > 3.5: Why don't we have an unambiguous way to distinguish SETs from access t= okens, why leave it to implementers? Sounds like a major security issue in t= he making. We should consider here ALL implementations that accept access to= kens, including legacy implementations that cannot be modified. > 4: The audit happens on the subscriber side. By then it is too late to req= uire JWS to be used by the publisher. As mentioned, I propose that JWS shoul= d ALWAYS be required. > 4: "When sharing personally identifiable information" - we should remove t= his condition. I don't see a case where the information shared is NOT PII, a= nd therefore legal agreements about information sharing and user consent mus= t always be in place. > 4: I don't think the subject information is "perceived" as PII. It is PII,= otherwise it would be useless to the subscriber, because the subscriber wou= ld not be able to identify the subject. Also, even if the information on the= wire is not in itself PII, e.g. when using a hash, the fact that a publishe= r shares information that a particular user is also a user on its system and= is undergoing certain state changes is privacy-sensitive. > I suggest to add an Implementation Status section, per RFC 7942. > Thanks, >=20 > Yaron > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event --Apple-Mail-5589C1DE-8F99-4B13-8036-78CE1D5F82D0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Yaron,

Thanks for your extensive feed= back. 

Apologies for my late response. I will respond shortly. 
Phil

On Dec 10, 2016, at 1:27 PM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
=20 =20 =20

Hi, I finally read the draft in detail, and I do have a few comments.

My main suggestion is to tighten the specification of an Event, by defining more strictly the difference between "event" and "event extension" and tweaking the JSON structure a bit.

In addition, I think we should require the claim to be signed, since it will be used for security-sensitive activities across complex distributed systems.

  • 1: Why is signing optional? The publisher doesn't know how the subscriber's system is architected, and might well want end-to-end authentication of the claim. This is also important for auditing.
  • 1: "example events" - is specification of individual events (maybe only a few basic ones) within scope of our charter? Otherwise we cannot guarantee interop.
  • 1.2: principle -> principal
  • 2: "first value" is meaningless. JSON objects are unordered (4th paragraph of RFC 7159). If order is important, we could make "events" into an array.
  • 2: event extensions are not defined but only introduced by the text after they are described. Also, in the example there's this URL: https://=E2= =80=8Bexample.=E2=80=8Bcom/=E2=80=8Bscim/=E2=80=8Bevent/=E2=80=8Bpas=E2=80=8B= swor=E2=80=8BdRes=E2=80=8BetEx=E2=80=8Bt - I believe it needs to be part of the passwordReset object and not parallel to it.
  • Why "events" and not "event"? We don't really have support for multiple events. Certainly not if they are all of the same type. The current text is confusing: "events" is not the same as "a primary event and its extensions".
  • "In the above example "iss" and "sub" contained within the claim" - this is incorrect, probably leftover from an earlier version.
  • "aud" MAY be a URI: shouldn't it be an array, maybe an array that contains a single URI?
  • Why do we use the terms "single-valued" vs. "multiple-valued" strings? Why not use the normal JSON terminology, "string" vs. "array of strings"?
  • Why is "sub" optional? Do we have any good examples of events where this value is not required?
  • "a future date" - we should clarify that there may be cases when nbf is smaller than iat, i.e. when it takes some time until the SET is issued.
  • "exp" - is it also a NumericDate? Please specify.
  • In the medical example, it is strange that the event is named by a URL that points to an HTML page. I would expect a more stable URI.
  • 2.2: is encryption a MUST whenever there are attributes specified? If so, we should have a normative section saying so, not just mention it in the context of an example. Besides, we have not defined what attributes are.
  • 2.2: this section is confusing. We first say that the JWT must be encrypted. But then instead, we sign it, and we "sign" with a null algorithm. Why?
  • Signed SETs MUST (not MAY) be validated by the subscriber.
  • Also, I think we should remove the preconditions and always require signing, as a MUST. An optional signature is actually a security loophole because an attacker can remove the signature, and the subscriber doesn't know that it's missing.
  • 3.2: "that alone will not guarantee that the correct subscribing party knows they should have received a particular SET." The text is unclear to me. Do we mean: "that alone does not guarantee that a particular SET was delivered to the correct subscribing party"?
    • =
  • We may want a separate Implementation Considerations section, and move "delivery", "sequencing" and "timing" into it. Yes they are security-relevant, just like anything else in this document, but they would apply just as well to any event stream protocol.
  • 3.3: this is the first time we mention provisioning. Do we really intend SETs to be used for that?
  • 3.3: ISTM that we should define a sequencing mechanism, rather than leave it open to profiles. E.g., require a sequence number whenever "txn" is used.
  • 3.4: Also, our timestamps only have 1 second granularity, and so are too coarse for session state (consider automated logins/logouts).
  • 3.5: Why don't we have an unambiguous way to distinguish SETs from access tokens, why leave it to implementers? Sounds like a major security issue in the making. We should consider here ALL implementations that accept access tokens, including legacy implementations that cannot be modified.
  • 4: The audit happens on the subscriber side. By then it is too late to require JWS to be used by the publisher. As mentioned, I propose that JWS should ALWAYS be required.
  • 4: "When sharing personally identifiable information" - we should remove this condition. I don't see a case where the information shared is NOT PII, and therefore legal agreements about information sharing and user consent must always be in place.
  • 4: I don't think the subject information is "perceived" as PII. It is PII, otherwise it would be useless to the subscriber, because the subscriber would not be able to identify the subject. Also, even if the information on the wire is not in itself PII, e.g. when using a hash, the fact that a publisher shares information that a particular user is also a user on its system and is undergoing certain state changes is privacy-sensitive.
  • I suggest to add an Implementation Status section, per RFC 7942.

Thanks,

    Yaron

=20
____________________= ___________________________
Id-event mailing list
= Id-event@ietf.org
<= span>https://www.= ietf.org/mailman/listinfo/id-event
<= /html>= --Apple-Mail-5589C1DE-8F99-4B13-8036-78CE1D5F82D0-- From nobody Wed Dec 14 12:18:10 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDA04129434 for ; Wed, 14 Dec 2016 12:18:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.972 X-Spam-Level: X-Spam-Status: No, score=-5.972 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=1.125, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GEfRSyEu8Gcy for ; Wed, 14 Dec 2016 12:18:05 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 94EC51293FF for ; Wed, 14 Dec 2016 12:18:05 -0800 (PST) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id uBEKI3cw025795 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 14 Dec 2016 20:18:03 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id uBEKI3mS000888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 14 Dec 2016 20:18:03 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id uBEKI3H0015904; Wed, 14 Dec 2016 20:18:03 GMT Received: from [192.168.1.26] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 14 Dec 2016 12:18:02 -0800 Content-Type: multipart/alternative; boundary="Apple-Mail=_92F2885A-21E1-4F79-93B3-01751D6ABB47" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Phil Hunt In-Reply-To: <9114f681-cba9-b6d3-8369-ccd9193ce1b8@gmail.com> Date: Wed, 14 Dec 2016 12:18:01 -0800 Message-Id: References: <9114f681-cba9-b6d3-8369-ccd9193ce1b8@gmail.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.3124) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: SecEvent Subject: Re: [Id-event] Some comments to draft-hunt-idevent-token-07 X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 20:18:08 -0000 --Apple-Mail=_92F2885A-21E1-4F79-93B3-01751D6ABB47 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yaron, Thanks for your comments. My responses inline. Phil @independentid www.independentid.com = phil.hunt@oracle.com = > On Dec 10, 2016, at 1:27 PM, Yaron Sheffer = wrote: >=20 > Hi, I finally read the draft in detail, and I do have a few comments. >=20 > My main suggestion is to tighten the specification of an Event, by = defining more strictly the difference between "event" and "event = extension" and tweaking the JSON structure a bit. >=20 >=20 The spec has undergone some restructuring recently, and it may need some = more tightening up. The informal consensus from the id-events list is = that there should be only one event. However, in order to allow some = deployers to provide additional information, and extension methodology = was included. An example is given. > In addition, I think we should require the claim to be signed, since = it will be used for security-sensitive activities across complex = distributed systems. > 1: Why is signing optional? The publisher doesn't know how the = subscriber's system is architected, and might well want end-to-end = authentication of the claim. This is also important for auditing. I think the key word in your question is =E2=80=9Cmight=E2=80=9D. Also, = its not the publisher that needs authentication of the statement its = really the subscriber. Many have preferred to have a minimum option where security is = essentially point-to-point depending primarily on TLS. There are other = cases where end-to-end key based is preferred especially when = transmitting over less secure transport. Remember that this specification is a coming together of a bunch of = initiatives around a common format. It is difficult to assign mandatory = requirements unless there is strong consensus to do so. > 1: "example events" - is specification of individual events (maybe = only a few basic ones) within scope of our charter? Otherwise we cannot = guarantee interop. The intention is to define a base level format that other working groups = and SDOs will use to define their own events. The primary benefit is to = have a common format. I had originally envisioned an event registry, but the early discussions = were to avoid IANA registration. We then switched to using URI=E2=80=99s = for events.=20 The informal consensus was that what matters is that publisher and = subscriber agree on meaning and that it is ok for events to be highly = specific. > 1.2: principle -> principal Noted > 2: "first value" is meaningless. JSON objects are unordered (4th = paragraph of RFC 7159). If order is important, we could make "events" = into an array. Yup. How would the group like to fix this? We could make =E2=80=9Cevent= s=E2=80=9D singular and have an extensions attribute to hold the = extensions. Or we could go to a more complex JSON structure (not = personally a fan). > 2: event extensions are not defined but only introduced by the text = after they are described. Also, in the example there's this URL: = https://=E2=80=8Be= xample.=E2=80=8Bcom/=E2=80=8Bscim/=E2=80=8Bevent/=E2=80=8Bpas=E2=80=8Bswor= =E2=80=8BdRes=E2=80=8BetEx=E2=80=8Bt = - I believe it needs to be part = of the passwordReset object and not parallel to it. I will check for clarity. The password example is intended to = demonstrate an example where a publisher wishes to provide additional = context such as the number of resets performed. Note in defining a = password reset event it might indeed make sense to combine that info. My = intent was to show an extension. Maybe there is a better hypothetical = example? > Why "events" and not "event"? We don't really have support for = multiple events. Certainly not if they are all of the same type. The = current text is confusing: "events" is not the same as "a primary event = and its extensions=E2=80=9D. Reflects your earlier comment re: primary vs. extensions. "events=E2=80=9D= is plural to reflect the fact that the attribute is multi-valued. I = agree, given that only one primary event can be included, the naming is = misleading. > "In the above example "iss" and "sub" contained within the claim" - = this is incorrect, probably leftover from an earlier version. NO. In the example, =E2=80=9Ciss=E2=80=9D and =E2=80=9Csub=E2=80=9D = indicate the subject is from a different issuer of the event. For = example a relying party web site wants to tell the identity provider = (the original subject issuer) that the user has requested a logout. > "aud" MAY be a URI: shouldn't it be an array, maybe an array that = contains a single URI? This is defined by the JWT spec. > Why do we use the terms "single-valued" vs. "multiple-valued" strings? = Why not use the normal JSON terminology, "string" vs. "array of = strings=E2=80=9D? Habit from the world of IDM. We could align it. > Why is "sub" optional? Do we have any good examples of events where = this value is not required? You might have an event about a session, or an IP address, or some other = thing. There was an email discussion in the past about whether sub should be a = security subject (e.g. as defined by SAML or OpenID Connect), or whether = sub is just the subject of the event and thus can be anything. I expect to see more discussion on this. > "a future date" - we should clarify that there may be cases when nbf = is smaller than iat, i.e. when it takes some time until the SET is = issued. Assume you are referring to =E2=80=9Cnbf=E2=80=9D. The definition comes = from JWT.=20 > "exp" - is it also a NumericDate? Please specify. Defined by JWT, RFC7519 > In the medical example, it is strange that the event is named by a URL = that points to an HTML page. I would expect a more stable URI. It is an example. Many have indicated that they want the event should be = a URL to the page that defines the event. > 2.2: is encryption a MUST whenever there are attributes specified? If = so, we should have a normative section saying so, not just mention it in = the context of an example. Besides, we have not defined what attributes = are. Please quote the text, 2.2 simply shows how to construct a SET token = based on language from 7519. > 2.2: this section is confusing. We first say that the JWT must be = encrypted. Where does it say this? > But then instead, we sign it, and we "sign" with a null algorithm. = Why? > Signed SETs MUST (not MAY) be validated by the subscriber. specific text please? > Also, I think we should remove the preconditions and always require = signing, as a MUST. An optional signature is actually a security = loophole because an attacker can remove the signature, and the = subscriber doesn't know that it's missing. Which text are you referring to. Signatures aren=E2=80=99t always necessary if the method for delivery = itself authenticates the publisher delivering the HTTP POST request and = it is secured by TLS.=20 > 3.2: "that alone will not guarantee that the correct subscribing party = knows they should have received a particular SET." The text is unclear = to me. Do we mean: "that alone does not guarantee that a particular SET = was delivered to the correct subscribing party=E2=80=9D? Just because an endpoint returns success after a POST does not by itself = guarantee it was able to decrypt or parse the message. Nor does it prove = the subscriber held the private key to decrypt the JWE. We cover this somewhat in the distribution draft when we talk about = verification messages which require the receiver to parse the message = and return content back proving possession. > We may want a separate Implementation Considerations section, and move = "delivery", "sequencing" and "timing" into it. Yes they are = security-relevant, just like anything else in this document, but they = would apply just as well to any event stream protocol. Seems reasonable. > 3.3: this is the first time we mention provisioning. Do we really = intend SETs to be used for that? Yes. Some of us do - this work actually began within the SCIM WG. = Provisioning was provided as an example of a type of event where = ordering would be crucial. > 3.3: ISTM that we should define a sequencing mechanism, rather than = leave it open to profiles. E.g., require a sequence number whenever = "txn" is used. txn is a separate concept. txn is there when publishers decide to issue = multiple events against the same originating event. For example, one = subscriber might understand suspicious activity while another might only = understand logout. Some have requested an attribute that lets the = publisher track that the different events actually stem from the same = original event. For example when a publishers operations center gets a = call to trace a series of events.=20 > 3.4: Also, our timestamps only have 1 second granularity, and so are = too coarse for session state (consider automated logins/logouts). The point here is to address event design issues where relying on = timestamp to order events is problematic. For example if you signal = logout only by subject identifier then it becomes hard to tell if a user = is logging back in or not. It is better to cancel a session associated = with a subject so that the new session can still be established. > 3.5: Why don't we have an unambiguous way to distinguish SETs from = access tokens, why leave it to implementers? Sounds like a major = security issue in the making. We should consider here ALL = implementations that accept access tokens, including legacy = implementations that cannot be modified. I agree. The real issue is that JWT=E2=80=99s should have had a type to = begin with. One of the threads is here: https://www.ietf.org/mail-archive/web/id-event/current/msg00120.html > 4: The audit happens on the subscriber side. By then it is too late to = require JWS to be used by the publisher. As mentioned, I propose that = JWS should ALWAYS be required. This is something that publisher and subscriber have to negotiate. This = is anticipated in the distribution spec to some degree. Though IMO, = there is not a lot of consensus on this yet. > 4: "When sharing personally identifiable information" - we should = remove this condition. I don't see a case where the information shared = is NOT PII, and therefore legal agreements about information sharing and = user consent must always be in place. How about cancellation of a token or a session? If just passing a = =E2=80=9Cjti=E2=80=9D value, there is arguably no PII. The JTI might be = traceable, but the relying party would have to know about it to infer = meaning. Also, tokens/sessions should never be permanent. I am not a = lawyer, but I doubt these examples would actually be PII. > 4: I don't think the subject information is "perceived" as PII. It is = PII, otherwise it would be useless to the subscriber, because the = subscriber would not be able to identify the subject. Also, even if the = information on the wire is not in itself PII, e.g. when using a hash, = the fact that a publisher shares information that a particular user is = also a user on its system and is undergoing certain state changes is = privacy-sensitive. Again, the subject of an event might be about a session or a token, = device, etc. > I suggest to add an Implementation Status section, per RFC 7942. It would be helpful for the chairs to provide guidance on this. =20 > Thanks, >=20 > Yaron > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event --Apple-Mail=_92F2885A-21E1-4F79-93B3-01751D6ABB47 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Yaron,

Thanks for your comments. My responses inline.




On Dec 10, 2016, at 1:27 PM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

=20 =20

Hi, = I finally read the draft in detail, and I do have a few comments.

My main suggestion is to tighten the = specification of an Event, by defining more strictly the difference between "event" and "event extension" and tweaking the JSON structure a bit.


The spec has = undergone some restructuring recently, and it may need some more = tightening up. The informal consensus from the id-events list is that = there should be only one event. However, in order to allow some = deployers to provide additional information, and extension methodology = was included.  An example is given.

In addition, I think we should = require the claim to be signed, since it will be used for security-sensitive activities across complex distributed systems.

  • 1:= Why is signing optional? The publisher doesn't know how the subscriber's system is architected, and might well want end-to-end authentication of the claim. This is also important for auditing.
I think the key = word in your question is =E2=80=9Cmight=E2=80=9D.  Also, its not = the publisher that needs authentication of the statement its really the = subscriber.

Many have preferred to = have a minimum option where security is essentially point-to-point = depending primarily on TLS.  There are other cases where end-to-end = key based is preferred especially when transmitting over less secure = transport.

Remember that this = specification is a coming together of a bunch of initiatives around a = common format. It is difficult to assign mandatory requirements unless = there is strong consensus to do so.

  • 1:= "example events" - is specification of individual events (maybe only a few basic ones) within scope of our charter? Otherwise we cannot guarantee interop.
The = intention is to define a base level format that other working groups and = SDOs will use to define their own events. The primary benefit is to have = a common format.

I had originally = envisioned an event registry, but the early discussions were to avoid = IANA registration. We then switched to using URI=E2=80=99s for = events. 

The informal consensus = was that what matters is that publisher and subscriber agree on meaning = and that it is ok for events to be highly = specific.
  • 1.2: principle -> = principal
Noted
  • 2:= "first value" is meaningless. JSON objects are unordered (4th paragraph of RFC 7159). If order is important, we could make "events" into an = array.
Yup.   How would the group = like to fix this?  We could make =E2=80=9Cevents=E2=80=9D singular = and have an extensions attribute to hold the extensions.  Or we = could go to a more complex JSON structure (not personally a fan).
I will check for clarity. The = password example is intended to demonstrate an example where a publisher = wishes to provide additional context such as the number of resets = performed.  Note in defining a password reset event it might indeed = make sense to combine that info. My intent was to show an extension. = Maybe there is a better hypothetical example?
  • Why "events" and not "event"? We don't really have support for multiple events. Certainly not if they are all of the same type. The current text is confusing: "events" is not the same as "a primary event and its = extensions=E2=80=9D.
Reflects your = earlier comment re: primary vs. extensions.  "events=E2=80=9D is = plural to reflect the fact that the attribute is multi-valued. I agree, = given that only one primary event can be included, the naming is = misleading.
  • "In the above example "iss" and "sub" contained within the claim" - this is incorrect, probably leftover from an earlier = version.
NO.  In the example, = =E2=80=9Ciss=E2=80=9D and =E2=80=9Csub=E2=80=9D indicate the subject is = from a different issuer of the event.  For example a relying party = web site wants to tell the identity provider (the original subject = issuer) that the user has requested a logout.
  • "aud" MAY be a URI: shouldn't it be an array, maybe an array that contains a single URI?
This is defined by = the JWT spec.
  • Why do we use the terms "single-valued" vs. "multiple-valued" strings? Why not use the normal JSON terminology, "string" vs. "array of strings=E2=80=9D?
Habit from = the world of IDM. We could align it.
  • Why is "sub" optional? Do we have any good examples of events where this value is not required?
You = might have an event about a session, or an IP address, or some other = thing.

There was an email discussion = in the past about whether sub should be a security subject (e.g. as = defined by SAML or OpenID Connect), or whether sub is just the subject = of the event and thus can be anything.

I expect to see more discussion on this.
  • "a= future date" - we should clarify that there may be cases when nbf is smaller than iat, i.e. when it takes some time until the SET is issued.
Assume you are = referring to =E2=80=9Cnbf=E2=80=9D. The definition comes from = JWT. 
  • "exp" - is it also a NumericDate? Please = specify.
Defined by JWT, RFC7519
  • In= the medical example, it is strange that the event is named by a URL that points to an HTML page. I would expect a more stable = URI.
It is an example. Many have = indicated that they want the event should be a URL to the page that = defines the event.

  • 2.2: is encryption a MUST whenever there are attributes specified? If so, we should have a normative section saying so, not just mention it in the context of an example. Besides, we have not defined what attributes = are.
Please quote the text, 2.2 simply = shows how to construct a SET token based on language from 7519.
  • 2.2: this section is confusing. We first say that the JWT must be encrypted.
Where does it say = this?
  • But then instead, we sign it, and we "sign" with a null algorithm. Why?
  • Signed SETs MUST (not MAY) be validated by the = subscriber.
specific text please?
  • Also, I think we should remove the preconditions and always require signing, as a MUST. An optional signature is actually a security loophole because an attacker can remove the signature, and the subscriber doesn't know that it's = missing.
Which text are you referring = to.

Signatures aren=E2=80=99t always = necessary if the method for delivery itself authenticates the publisher = delivering the HTTP POST request and it is secured by TLS. 
  • 3.2: "that alone will not guarantee that the correct subscribing party knows they should have received a particular SET." The text is unclear to me. Do we mean: "that alone does not guarantee that a particular SET was delivered to the correct subscribing = party=E2=80=9D?
Just because an = endpoint returns success after a POST does not by itself guarantee it = was able to decrypt or parse the message. Nor does it prove  the = subscriber held the private key to decrypt the JWE.

We cover this somewhat in the distribution draft = when we talk about verification messages which require the receiver to = parse the message and return content back proving possession.
  • We= may want a separate Implementation Considerations section, and move "delivery", "sequencing" and "timing" into it. Yes they are security-relevant, just like anything else in this document, but they would apply just as well to any event stream = protocol.
Seems reasonable.
  • 3.3: this is the first time we mention provisioning. Do we really intend SETs to be used for that?
Yes. Some = of us do - this work actually began within the SCIM WG. =  Provisioning was provided as an example of a type of event where = ordering would be crucial.
  • 3.3: ISTM that we should define a sequencing mechanism, rather than leave it open to profiles. E.g., require a sequence number whenever "txn" is used.
txn is a = separate concept. txn is there when publishers decide to issue multiple = events against the same originating event.  For example, one = subscriber might understand suspicious activity while another might only = understand logout. Some have requested an attribute that lets the = publisher track that the different events actually stem from the same = original event.  For example when a publishers operations center = gets a call to trace a series of events. 
  • 3.4: Also, our timestamps only have 1 second granularity, and so are too coarse for session state (consider automated = logins/logouts).
The point here is to = address event design issues where relying on timestamp to order events = is problematic. For example if you signal logout only by subject = identifier then it becomes hard to tell if a user is logging back in or = not. It is better to cancel a session associated with a subject so that = the new session can still be established.
  • 3.5: Why don't we have an unambiguous way to distinguish SETs from access tokens, why leave it to implementers? Sounds like a major security issue in the making. We should consider here ALL implementations that accept access tokens, including legacy implementations that cannot be = modified.
I agree. The real issue is = that JWT=E2=80=99s should have had a type to begin with. One of the = threads is here:
https://www.ietf.org/mail-archive/web/id-event/current/msg00120= .html
  • 4:= The audit happens on the subscriber side. By then it is too late to require JWS to be used by the publisher. As mentioned, I propose that JWS should ALWAYS be = required.
This is something that = publisher and subscriber have to negotiate. This is anticipated in the = distribution spec to some degree. Though IMO, there is not a lot of = consensus on this yet.
  • 4:= "When sharing personally identifiable information" - we should remove this condition. I don't see a case where the information shared is NOT PII, and therefore legal agreements about information sharing and user consent must always be in = place.
How about cancellation of a = token or a session?  If just passing a =E2=80=9Cjti=E2=80=9D value, = there is arguably no PII.  The JTI might be traceable, but the = relying party would have to know about it to infer meaning.  Also, = tokens/sessions should never be permanent.  I am not a lawyer, but = I doubt these examples would actually be PII.
  • 4:= I don't think the subject information is "perceived" as PII. It is PII, otherwise it would be useless to the subscriber, because the subscriber would not be able to identify the subject. Also, even if the information on the wire is not in itself PII, e.g. when using a hash, the fact that a publisher shares information that a particular user is also a user on its system and is undergoing certain state changes is = privacy-sensitive.
Again, the subject = of an event might be about a session or a token, device, etc.
  • I = suggest to add an Implementation Status section, per RFC = 7942.
It would be helpful for the = chairs to provide guidance on this.  

Thanks,

    = Yaron

_______________________________________________
Id-event = mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event

= --Apple-Mail=_92F2885A-21E1-4F79-93B3-01751D6ABB47-- From nobody Wed Dec 14 12:58:47 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84E9012953F for ; Wed, 14 Dec 2016 12:58:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZdqidrGGTCk4 for ; Wed, 14 Dec 2016 12:58:42 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0094.outbound.protection.outlook.com [104.47.38.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF4D1129487 for ; Wed, 14 Dec 2016 12:58:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Qiv+hmA4eBucpR2202yKt9DuRdo2+ZR1r8cSMZPQ5mc=; b=Dk1sFeHVTZQI+LxF3wVwmQDiHtoIkgsyZM38ljILC0jS/iJYQB8JRTGQVFS1zSarOEG9+wEOeNgZ8nkQhJggPfJIj0M7W0+4mSG8kuJ4Lppf39Sp/n9K3SSTuE9CankQQkyuFSJ3gzaZiS2m/23/NRf826tPA0t0HwW9iLHlNFg= Received: from BN3PR03MB2355.namprd03.prod.outlook.com (10.166.74.150) by BN3PR03MB2355.namprd03.prod.outlook.com (10.166.74.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.771.8; Wed, 14 Dec 2016 20:58:38 +0000 Received: from BN3PR03MB2355.namprd03.prod.outlook.com ([10.166.74.150]) by BN3PR03MB2355.namprd03.prod.outlook.com ([10.166.74.150]) with mapi id 15.01.0771.014; Wed, 14 Dec 2016 20:58:38 +0000 From: Mike Jones To: Phil Hunt , Yaron Sheffer Thread-Topic: [Id-event] Some comments to draft-hunt-idevent-token-07 Thread-Index: AQHSUyxOjIY+pknIPU+y0NA2aRWa0aEH5/2AgAAKVtA= Date: Wed, 14 Dec 2016 20:58:38 +0000 Message-ID: References: <9114f681-cba9-b6d3-8369-ccd9193ce1b8@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [174.7.254.34] x-ms-office365-filtering-correlation-id: 0f8927cd-8ea6-468b-7369-08d42463fa7e x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN3PR03MB2355; x-microsoft-exchange-diagnostics: 1; BN3PR03MB2355; 7:N1LqNJZeLJu7hRUlmSrrb/eqY9xNWh3hc4Fogj1Ci42IFObNZxnMcKCEfZ9nNoiQnsYYhjUpRqFqdp2WUX+CSi+5UKJ5jDfT5XUJcqgWHk58wYHHUX9RciFr6VhZzVwWVLpPuWnYRFETJahsJQCoSyk4Njsgt0yS+FnzjxHyWU2zExBJzRfBijr0tpnOkYbIX6qoesda6SD36bZzCGCVi/FxfDYDCQ1c8U6BPHH12kLAX+I6dHQ1I+JCKgGpp5VTXN8iWb0tYdIoELG4xuQPG8cq3Vpn5EScEtsPyQIvwSiYUZj9gaGtO3vkgOvyFkBcyOYhueYkgLPp5M8P3G/+MjTQWPiZ7+EZ+ulPVjG/PH6zxt+s0/7EIOriUiGwpVEHKyRIBQJLQRwXonQ5Bi8a6wG+RjpBUOJyWQQQiMYd5O3SJErjUjp7N0eb1AZmoOYtI/mbRZEsHCPKm6ruqlhr4z0BL8hfHXEDvuECkBch15c= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(100405760836317)(21748063052155)(21532816269658)(146099531331640); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123564025)(20161123562025)(20161123560025)(20161123555025)(6072148)(6047074); SRVR:BN3PR03MB2355; BCL:0; PCL:0; RULEID:; SRVR:BN3PR03MB2355; x-forefront-prvs: 01565FED4C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39850400002)(39860400002)(39450400003)(39840400002)(39410400002)(377454003)(24454002)(189002)(199003)(106356001)(2900100001)(3846002)(81166006)(76576001)(9686002)(74316002)(101416001)(19609705001)(92566002)(4326007)(8936002)(7906003)(106116001)(122556002)(3280700002)(25786008)(99286002)(189998001)(105586002)(3660700001)(86612001)(33656002)(16601075003)(790700001)(6116002)(102836003)(86362001)(230783001)(345774005)(81156014)(8676002)(97736004)(6436002)(38730400001)(606005)(6506006)(77096006)(1680700002)(7696004)(7736002)(5001770100001)(39060400001)(76176999)(50986999)(54356999)(551544002)(229853002)(66066001)(2906002)(10090500001)(8990500004)(2950100002)(5660300001)(68736007)(5005710100001)(10290500002)(569005); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR03MB2355; H:BN3PR03MB2355.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR03MB235507D80D7BC915FA6775A4F59A0BN3PR03MB2355namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Dec 2016 20:58:38.8115 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR03MB2355 Archived-At: Cc: SecEvent Subject: Re: [Id-event] Some comments to draft-hunt-idevent-token-07 X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 20:58:45 -0000 --_000_BN3PR03MB235507D80D7BC915FA6775A4F59A0BN3PR03MB2355namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TGV0IG1lIGFsc28gdGhhbmsgeW91IGZvciB0aGVzZSBkZXRhaWxlZCBjb21tZW50cywgWWFyb24u ICBUaGV54oCZcmUgdmVyeSB1c2VmdWwhDQoNCknigJltIG9uIHZhY2F0aW9uIHRoaXMgd2VlayBi dXQgaGF2ZSBhbHJlYWR5IGZsYWdnZWQgdGhpcyB0byByZXNwb25kIHRvIGluIGRldGFpbCBuZXh0 IHdlZWsuICBUaGF0IHNhaWQsIEkgYWdyZWUgd2l0aCBtYW55IG9mIFBoaWzigJlzIHJlc3BvbnNl cy4gIFRoYXQgc2FpZCwgSSBhbSBhZ2FpbnN0IGNoYW5naW5nIOKAnGV2ZW50c+KAnSB0byDigJxl dmVudOKAnS4gIEl04oCZcyBhcHBsaWNhdGlvbi1kZXBlbmRlbnQgd2hldGhlciB0aGVyZSBpcyBv bmx5IG9uZSBldmVudCwgYSBzZXQgb2YgcmVsYXRlZCBldmVudHMgc2hhcmluZyBjb250ZXh0LCBh bmQgd2hpY2ggaXMgcHJpbWFyeS4gIEkgdGhpbmsgd2Ugc2hvdWxkIHJlbWFpbiBnZW5lcmFsIGlu IHRoaXMgcmVnYXJkLiAgKFllcywgd2UgZG8gbmVlZCB0byBmaW5pc2ggY2xlYW5pbmcgdXAgdGhl IGxhbmd1YWdlIGxlZnRvdmVyIGZyb20gd2hlbiBldmVudHMgd2VyZSByZXByZXNlbnRlZCBpbiBh IEpTT04gYXJyYXkgcmF0aGVyIHRoYW4gYSBKU09OIG9iamVjdC4pDQoNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206 IElkLWV2ZW50IFttYWlsdG86aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IFBoaWwgSHVudA0KU2VudDogV2VkbmVzZGF5LCBEZWNlbWJlciAxNCwgMjAxNiAxMjoxOCBQTQ0K VG86IFlhcm9uIFNoZWZmZXIgPHlhcm9uZi5pZXRmQGdtYWlsLmNvbT4NCkNjOiBTZWNFdmVudCA8 aWQtZXZlbnRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0lkLWV2ZW50XSBTb21lIGNvbW1lbnRz IHRvIGRyYWZ0LWh1bnQtaWRldmVudC10b2tlbi0wNw0KDQpZYXJvbiwNCg0KVGhhbmtzIGZvciB5 b3VyIGNvbW1lbnRzLiBNeSByZXNwb25zZXMgaW5saW5lLg0KDQpQaGlsDQoNCkBpbmRlcGVuZGVu dGlkDQp3d3cuaW5kZXBlbmRlbnRpZC5jb208aHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNvbT4N CnBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4NCg0KDQoN Cg0KT24gRGVjIDEwLCAyMDE2LCBhdCAxOjI3IFBNLCBZYXJvbiBTaGVmZmVyIDx5YXJvbmYuaWV0 ZkBnbWFpbC5jb208bWFpbHRvOnlhcm9uZi5pZXRmQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpIaSwg SSBmaW5hbGx5IHJlYWQgdGhlIGRyYWZ0IGluIGRldGFpbCwgYW5kIEkgZG8gaGF2ZSBhIGZldyBj b21tZW50cy4NCk15IG1haW4gc3VnZ2VzdGlvbiBpcyB0byB0aWdodGVuIHRoZSBzcGVjaWZpY2F0 aW9uIG9mIGFuIEV2ZW50LCBieSBkZWZpbmluZyBtb3JlIHN0cmljdGx5IHRoZSBkaWZmZXJlbmNl IGJldHdlZW4gImV2ZW50IiBhbmQgImV2ZW50IGV4dGVuc2lvbiIgYW5kIHR3ZWFraW5nIHRoZSBK U09OIHN0cnVjdHVyZSBhIGJpdC4NCg0KVGhlIHNwZWMgaGFzIHVuZGVyZ29uZSBzb21lIHJlc3Ry dWN0dXJpbmcgcmVjZW50bHksIGFuZCBpdCBtYXkgbmVlZCBzb21lIG1vcmUgdGlnaHRlbmluZyB1 cC4gVGhlIGluZm9ybWFsIGNvbnNlbnN1cyBmcm9tIHRoZSBpZC1ldmVudHMgbGlzdCBpcyB0aGF0 IHRoZXJlIHNob3VsZCBiZSBvbmx5IG9uZSBldmVudC4gSG93ZXZlciwgaW4gb3JkZXIgdG8gYWxs b3cgc29tZSBkZXBsb3llcnMgdG8gcHJvdmlkZSBhZGRpdGlvbmFsIGluZm9ybWF0aW9uLCBhbmQg ZXh0ZW5zaW9uIG1ldGhvZG9sb2d5IHdhcyBpbmNsdWRlZC4gIEFuIGV4YW1wbGUgaXMgZ2l2ZW4u DQoNCkluIGFkZGl0aW9uLCBJIHRoaW5rIHdlIHNob3VsZCByZXF1aXJlIHRoZSBjbGFpbSB0byBi ZSBzaWduZWQsIHNpbmNlIGl0IHdpbGwgYmUgdXNlZCBmb3Igc2VjdXJpdHktc2Vuc2l0aXZlIGFj dGl2aXRpZXMgYWNyb3NzIGNvbXBsZXggZGlzdHJpYnV0ZWQgc3lzdGVtcy4NCg0KICAqICAgMTog V2h5IGlzIHNpZ25pbmcgb3B0aW9uYWw/IFRoZSBwdWJsaXNoZXIgZG9lc24ndCBrbm93IGhvdyB0 aGUgc3Vic2NyaWJlcidzIHN5c3RlbSBpcyBhcmNoaXRlY3RlZCwgYW5kIG1pZ2h0IHdlbGwgd2Fu dCBlbmQtdG8tZW5kIGF1dGhlbnRpY2F0aW9uIG9mIHRoZSBjbGFpbS4gVGhpcyBpcyBhbHNvIGlt cG9ydGFudCBmb3IgYXVkaXRpbmcuDQpJIHRoaW5rIHRoZSBrZXkgd29yZCBpbiB5b3VyIHF1ZXN0 aW9uIGlzIOKAnG1pZ2h04oCdLiAgQWxzbywgaXRzIG5vdCB0aGUgcHVibGlzaGVyIHRoYXQgbmVl ZHMgYXV0aGVudGljYXRpb24gb2YgdGhlIHN0YXRlbWVudCBpdHMgcmVhbGx5IHRoZSBzdWJzY3Jp YmVyLg0KDQpNYW55IGhhdmUgcHJlZmVycmVkIHRvIGhhdmUgYSBtaW5pbXVtIG9wdGlvbiB3aGVy ZSBzZWN1cml0eSBpcyBlc3NlbnRpYWxseSBwb2ludC10by1wb2ludCBkZXBlbmRpbmcgcHJpbWFy aWx5IG9uIFRMUy4gIFRoZXJlIGFyZSBvdGhlciBjYXNlcyB3aGVyZSBlbmQtdG8tZW5kIGtleSBi YXNlZCBpcyBwcmVmZXJyZWQgZXNwZWNpYWxseSB3aGVuIHRyYW5zbWl0dGluZyBvdmVyIGxlc3Mg c2VjdXJlIHRyYW5zcG9ydC4NCg0KUmVtZW1iZXIgdGhhdCB0aGlzIHNwZWNpZmljYXRpb24gaXMg YSBjb21pbmcgdG9nZXRoZXIgb2YgYSBidW5jaCBvZiBpbml0aWF0aXZlcyBhcm91bmQgYSBjb21t b24gZm9ybWF0LiBJdCBpcyBkaWZmaWN1bHQgdG8gYXNzaWduIG1hbmRhdG9yeSByZXF1aXJlbWVu dHMgdW5sZXNzIHRoZXJlIGlzIHN0cm9uZyBjb25zZW5zdXMgdG8gZG8gc28uDQoNCg0KDQogICog ICAxOiAiZXhhbXBsZSBldmVudHMiIC0gaXMgc3BlY2lmaWNhdGlvbiBvZiBpbmRpdmlkdWFsIGV2 ZW50cyAobWF5YmUgb25seSBhIGZldyBiYXNpYyBvbmVzKSB3aXRoaW4gc2NvcGUgb2Ygb3VyIGNo YXJ0ZXI/IE90aGVyd2lzZSB3ZSBjYW5ub3QgZ3VhcmFudGVlIGludGVyb3AuDQpUaGUgaW50ZW50 aW9uIGlzIHRvIGRlZmluZSBhIGJhc2UgbGV2ZWwgZm9ybWF0IHRoYXQgb3RoZXIgd29ya2luZyBn cm91cHMgYW5kIFNET3Mgd2lsbCB1c2UgdG8gZGVmaW5lIHRoZWlyIG93biBldmVudHMuIFRoZSBw cmltYXJ5IGJlbmVmaXQgaXMgdG8gaGF2ZSBhIGNvbW1vbiBmb3JtYXQuDQoNCkkgaGFkIG9yaWdp bmFsbHkgZW52aXNpb25lZCBhbiBldmVudCByZWdpc3RyeSwgYnV0IHRoZSBlYXJseSBkaXNjdXNz aW9ucyB3ZXJlIHRvIGF2b2lkIElBTkEgcmVnaXN0cmF0aW9uLiBXZSB0aGVuIHN3aXRjaGVkIHRv IHVzaW5nIFVSSeKAmXMgZm9yIGV2ZW50cy4NCg0KVGhlIGluZm9ybWFsIGNvbnNlbnN1cyB3YXMg dGhhdCB3aGF0IG1hdHRlcnMgaXMgdGhhdCBwdWJsaXNoZXIgYW5kIHN1YnNjcmliZXIgYWdyZWUg b24gbWVhbmluZyBhbmQgdGhhdCBpdCBpcyBvayBmb3IgZXZlbnRzIHRvIGJlIGhpZ2hseSBzcGVj aWZpYy4NCg0KICAqICAgMS4yOiBwcmluY2lwbGUgLT4gcHJpbmNpcGFsDQpOb3RlZA0KDQoNCiAg KiAgIDI6ICJmaXJzdCB2YWx1ZSIgaXMgbWVhbmluZ2xlc3MuIEpTT04gb2JqZWN0cyBhcmUgdW5v cmRlcmVkICg0dGggcGFyYWdyYXBoIG9mIFJGQyA3MTU5KS4gSWYgb3JkZXIgaXMgaW1wb3J0YW50 LCB3ZSBjb3VsZCBtYWtlICJldmVudHMiIGludG8gYW4gYXJyYXkuDQpZdXAuICAgSG93IHdvdWxk IHRoZSBncm91cCBsaWtlIHRvIGZpeCB0aGlzPyAgV2UgY291bGQgbWFrZSDigJxldmVudHPigJ0g c2luZ3VsYXIgYW5kIGhhdmUgYW4gZXh0ZW5zaW9ucyBhdHRyaWJ1dGUgdG8gaG9sZCB0aGUgZXh0 ZW5zaW9ucy4gIE9yIHdlIGNvdWxkIGdvIHRvIGEgbW9yZSBjb21wbGV4IEpTT04gc3RydWN0dXJl IChub3QgcGVyc29uYWxseSBhIGZhbikuDQoNCg0KICAqICAgMjogZXZlbnQgZXh0ZW5zaW9ucyBh cmUgbm90IGRlZmluZWQgYnV0IG9ubHkgaW50cm9kdWNlZCBieSB0aGUgdGV4dCBhZnRlciB0aGV5 IGFyZSBkZXNjcmliZWQuIEFsc28sIGluIHRoZSBleGFtcGxlIHRoZXJlJ3MgdGhpcyBVUkw6IGh0 dHBzOi8v4oCLZXhhbXBsZS7igItjb20v4oCLc2NpbS/igItldmVudC/igItwYXPigItzd29y4oCL ZFJlc+KAi2V0RXjigIt0PGh0dHBzOi8vZXhhbXBsZS5jb20vJUUyJTgwJThCc2NpbS8lRTIlODAl OEJldmVudC8lRTIlODAlOEJwYXMlRTIlODAlOEJzd29yJUUyJTgwJThCZFJlcyVFMiU4MCU4QmV0 RXglRTIlODAlOEJ0PiAtIEkgYmVsaWV2ZSBpdCBuZWVkcyB0byBiZSBwYXJ0IG9mIHRoZSBwYXNz d29yZFJlc2V0IG9iamVjdCBhbmQgbm90IHBhcmFsbGVsIHRvIGl0Lg0KSSB3aWxsIGNoZWNrIGZv ciBjbGFyaXR5LiBUaGUgcGFzc3dvcmQgZXhhbXBsZSBpcyBpbnRlbmRlZCB0byBkZW1vbnN0cmF0 ZSBhbiBleGFtcGxlIHdoZXJlIGEgcHVibGlzaGVyIHdpc2hlcyB0byBwcm92aWRlIGFkZGl0aW9u YWwgY29udGV4dCBzdWNoIGFzIHRoZSBudW1iZXIgb2YgcmVzZXRzIHBlcmZvcm1lZC4gIE5vdGUg aW4gZGVmaW5pbmcgYSBwYXNzd29yZCByZXNldCBldmVudCBpdCBtaWdodCBpbmRlZWQgbWFrZSBz ZW5zZSB0byBjb21iaW5lIHRoYXQgaW5mby4gTXkgaW50ZW50IHdhcyB0byBzaG93IGFuIGV4dGVu c2lvbi4gTWF5YmUgdGhlcmUgaXMgYSBiZXR0ZXIgaHlwb3RoZXRpY2FsIGV4YW1wbGU/DQoNCg0K ICAqICAgV2h5ICJldmVudHMiIGFuZCBub3QgImV2ZW50Ij8gV2UgZG9uJ3QgcmVhbGx5IGhhdmUg c3VwcG9ydCBmb3IgbXVsdGlwbGUgZXZlbnRzLiBDZXJ0YWlubHkgbm90IGlmIHRoZXkgYXJlIGFs bCBvZiB0aGUgc2FtZSB0eXBlLiBUaGUgY3VycmVudCB0ZXh0IGlzIGNvbmZ1c2luZzogImV2ZW50 cyIgaXMgbm90IHRoZSBzYW1lIGFzICJhIHByaW1hcnkgZXZlbnQgYW5kIGl0cyBleHRlbnNpb25z 4oCdLg0KUmVmbGVjdHMgeW91ciBlYXJsaWVyIGNvbW1lbnQgcmU6IHByaW1hcnkgdnMuIGV4dGVu c2lvbnMuICAiZXZlbnRz4oCdIGlzIHBsdXJhbCB0byByZWZsZWN0IHRoZSBmYWN0IHRoYXQgdGhl IGF0dHJpYnV0ZSBpcyBtdWx0aS12YWx1ZWQuIEkgYWdyZWUsIGdpdmVuIHRoYXQgb25seSBvbmUg cHJpbWFyeSBldmVudCBjYW4gYmUgaW5jbHVkZWQsIHRoZSBuYW1pbmcgaXMgbWlzbGVhZGluZy4N Cg0KDQogICogICAiSW4gdGhlIGFib3ZlIGV4YW1wbGUgImlzcyIgYW5kICJzdWIiIGNvbnRhaW5l ZCB3aXRoaW4gdGhlIGNsYWltIiAtIHRoaXMgaXMgaW5jb3JyZWN0LCBwcm9iYWJseSBsZWZ0b3Zl ciBmcm9tIGFuIGVhcmxpZXIgdmVyc2lvbi4NCk5PLiAgSW4gdGhlIGV4YW1wbGUsIOKAnGlzc+KA nSBhbmQg4oCcc3Vi4oCdIGluZGljYXRlIHRoZSBzdWJqZWN0IGlzIGZyb20gYSBkaWZmZXJlbnQg aXNzdWVyIG9mIHRoZSBldmVudC4gIEZvciBleGFtcGxlIGEgcmVseWluZyBwYXJ0eSB3ZWIgc2l0 ZSB3YW50cyB0byB0ZWxsIHRoZSBpZGVudGl0eSBwcm92aWRlciAodGhlIG9yaWdpbmFsIHN1Ympl Y3QgaXNzdWVyKSB0aGF0IHRoZSB1c2VyIGhhcyByZXF1ZXN0ZWQgYSBsb2dvdXQuDQoNCg0KICAq ICAgImF1ZCIgTUFZIGJlIGEgVVJJOiBzaG91bGRuJ3QgaXQgYmUgYW4gYXJyYXksIG1heWJlIGFu IGFycmF5IHRoYXQgY29udGFpbnMgYSBzaW5nbGUgVVJJPw0KVGhpcyBpcyBkZWZpbmVkIGJ5IHRo ZSBKV1Qgc3BlYy4NCg0KDQogICogICBXaHkgZG8gd2UgdXNlIHRoZSB0ZXJtcyAic2luZ2xlLXZh bHVlZCIgdnMuICJtdWx0aXBsZS12YWx1ZWQiIHN0cmluZ3M/IFdoeSBub3QgdXNlIHRoZSBub3Jt YWwgSlNPTiB0ZXJtaW5vbG9neSwgInN0cmluZyIgdnMuICJhcnJheSBvZiBzdHJpbmdz4oCdPw0K SGFiaXQgZnJvbSB0aGUgd29ybGQgb2YgSURNLiBXZSBjb3VsZCBhbGlnbiBpdC4NCg0KDQogICog ICBXaHkgaXMgInN1YiIgb3B0aW9uYWw/IERvIHdlIGhhdmUgYW55IGdvb2QgZXhhbXBsZXMgb2Yg ZXZlbnRzIHdoZXJlIHRoaXMgdmFsdWUgaXMgbm90IHJlcXVpcmVkPw0KWW91IG1pZ2h0IGhhdmUg YW4gZXZlbnQgYWJvdXQgYSBzZXNzaW9uLCBvciBhbiBJUCBhZGRyZXNzLCBvciBzb21lIG90aGVy IHRoaW5nLg0KDQpUaGVyZSB3YXMgYW4gZW1haWwgZGlzY3Vzc2lvbiBpbiB0aGUgcGFzdCBhYm91 dCB3aGV0aGVyIHN1YiBzaG91bGQgYmUgYSBzZWN1cml0eSBzdWJqZWN0IChlLmcuIGFzIGRlZmlu ZWQgYnkgU0FNTCBvciBPcGVuSUQgQ29ubmVjdCksIG9yIHdoZXRoZXIgc3ViIGlzIGp1c3QgdGhl IHN1YmplY3Qgb2YgdGhlIGV2ZW50IGFuZCB0aHVzIGNhbiBiZSBhbnl0aGluZy4NCg0KSSBleHBl Y3QgdG8gc2VlIG1vcmUgZGlzY3Vzc2lvbiBvbiB0aGlzLg0KDQoNCiAgKiAgICJhIGZ1dHVyZSBk YXRlIiAtIHdlIHNob3VsZCBjbGFyaWZ5IHRoYXQgdGhlcmUgbWF5IGJlIGNhc2VzIHdoZW4gbmJm IGlzIHNtYWxsZXIgdGhhbiBpYXQsIGkuZS4gd2hlbiBpdCB0YWtlcyBzb21lIHRpbWUgdW50aWwg dGhlIFNFVCBpcyBpc3N1ZWQuDQpBc3N1bWUgeW91IGFyZSByZWZlcnJpbmcgdG8g4oCcbmJm4oCd LiBUaGUgZGVmaW5pdGlvbiBjb21lcyBmcm9tIEpXVC4NCg0KDQogICogICAiZXhwIiAtIGlzIGl0 IGFsc28gYSBOdW1lcmljRGF0ZT8gUGxlYXNlIHNwZWNpZnkuDQpEZWZpbmVkIGJ5IEpXVCwgUkZD NzUxOQ0KDQoNCiAgKiAgIEluIHRoZSBtZWRpY2FsIGV4YW1wbGUsIGl0IGlzIHN0cmFuZ2UgdGhh dCB0aGUgZXZlbnQgaXMgbmFtZWQgYnkgYSBVUkwgdGhhdCBwb2ludHMgdG8gYW4gSFRNTCBwYWdl LiBJIHdvdWxkIGV4cGVjdCBhIG1vcmUgc3RhYmxlIFVSSS4NCkl0IGlzIGFuIGV4YW1wbGUuIE1h bnkgaGF2ZSBpbmRpY2F0ZWQgdGhhdCB0aGV5IHdhbnQgdGhlIGV2ZW50IHNob3VsZCBiZSBhIFVS TCB0byB0aGUgcGFnZSB0aGF0IGRlZmluZXMgdGhlIGV2ZW50Lg0KDQoNCiAgKiAgIDIuMjogaXMg ZW5jcnlwdGlvbiBhIE1VU1Qgd2hlbmV2ZXIgdGhlcmUgYXJlIGF0dHJpYnV0ZXMgc3BlY2lmaWVk PyBJZiBzbywgd2Ugc2hvdWxkIGhhdmUgYSBub3JtYXRpdmUgc2VjdGlvbiBzYXlpbmcgc28sIG5v dCBqdXN0IG1lbnRpb24gaXQgaW4gdGhlIGNvbnRleHQgb2YgYW4gZXhhbXBsZS4gQmVzaWRlcywg d2UgaGF2ZSBub3QgZGVmaW5lZCB3aGF0IGF0dHJpYnV0ZXMgYXJlLg0KUGxlYXNlIHF1b3RlIHRo ZSB0ZXh0LCAyLjIgc2ltcGx5IHNob3dzIGhvdyB0byBjb25zdHJ1Y3QgYSBTRVQgdG9rZW4gYmFz ZWQgb24gbGFuZ3VhZ2UgZnJvbSA3NTE5Lg0KDQoNCiAgKiAgIDIuMjogdGhpcyBzZWN0aW9uIGlz IGNvbmZ1c2luZy4gV2UgZmlyc3Qgc2F5IHRoYXQgdGhlIEpXVCBtdXN0IGJlIGVuY3J5cHRlZC4N CldoZXJlIGRvZXMgaXQgc2F5IHRoaXM/DQoNCg0KICAqICAgQnV0IHRoZW4gaW5zdGVhZCwgd2Ug c2lnbiBpdCwgYW5kIHdlICJzaWduIiB3aXRoIGEgbnVsbCBhbGdvcml0aG0uIFdoeT8NCiAgKiAg IFNpZ25lZCBTRVRzIE1VU1QgKG5vdCBNQVkpIGJlIHZhbGlkYXRlZCBieSB0aGUgc3Vic2NyaWJl ci4NCnNwZWNpZmljIHRleHQgcGxlYXNlPw0KDQoNCiAgKiAgIEFsc28sIEkgdGhpbmsgd2Ugc2hv dWxkIHJlbW92ZSB0aGUgcHJlY29uZGl0aW9ucyBhbmQgYWx3YXlzIHJlcXVpcmUgc2lnbmluZywg YXMgYSBNVVNULiBBbiBvcHRpb25hbCBzaWduYXR1cmUgaXMgYWN0dWFsbHkgYSBzZWN1cml0eSBs b29waG9sZSBiZWNhdXNlIGFuIGF0dGFja2VyIGNhbiByZW1vdmUgdGhlIHNpZ25hdHVyZSwgYW5k IHRoZSBzdWJzY3JpYmVyIGRvZXNuJ3Qga25vdyB0aGF0IGl0J3MgbWlzc2luZy4NCldoaWNoIHRl eHQgYXJlIHlvdSByZWZlcnJpbmcgdG8uDQoNClNpZ25hdHVyZXMgYXJlbuKAmXQgYWx3YXlzIG5l Y2Vzc2FyeSBpZiB0aGUgbWV0aG9kIGZvciBkZWxpdmVyeSBpdHNlbGYgYXV0aGVudGljYXRlcyB0 aGUgcHVibGlzaGVyIGRlbGl2ZXJpbmcgdGhlIEhUVFAgUE9TVCByZXF1ZXN0IGFuZCBpdCBpcyBz ZWN1cmVkIGJ5IFRMUy4NCg0KDQogICogICAzLjI6ICJ0aGF0IGFsb25lIHdpbGwgbm90IGd1YXJh bnRlZSB0aGF0IHRoZSBjb3JyZWN0IHN1YnNjcmliaW5nIHBhcnR5IGtub3dzIHRoZXkgc2hvdWxk IGhhdmUgcmVjZWl2ZWQgYSBwYXJ0aWN1bGFyIFNFVC4iIFRoZSB0ZXh0IGlzIHVuY2xlYXIgdG8g bWUuIERvIHdlIG1lYW46ICJ0aGF0IGFsb25lIGRvZXMgbm90IGd1YXJhbnRlZSB0aGF0IGEgcGFy dGljdWxhciBTRVQgd2FzIGRlbGl2ZXJlZCB0byB0aGUgY29ycmVjdCBzdWJzY3JpYmluZyBwYXJ0 eeKAnT8NCkp1c3QgYmVjYXVzZSBhbiBlbmRwb2ludCByZXR1cm5zIHN1Y2Nlc3MgYWZ0ZXIgYSBQ T1NUIGRvZXMgbm90IGJ5IGl0c2VsZiBndWFyYW50ZWUgaXQgd2FzIGFibGUgdG8gZGVjcnlwdCBv ciBwYXJzZSB0aGUgbWVzc2FnZS4gTm9yIGRvZXMgaXQgcHJvdmUgIHRoZSBzdWJzY3JpYmVyIGhl bGQgdGhlIHByaXZhdGUga2V5IHRvIGRlY3J5cHQgdGhlIEpXRS4NCg0KV2UgY292ZXIgdGhpcyBz b21ld2hhdCBpbiB0aGUgZGlzdHJpYnV0aW9uIGRyYWZ0IHdoZW4gd2UgdGFsayBhYm91dCB2ZXJp ZmljYXRpb24gbWVzc2FnZXMgd2hpY2ggcmVxdWlyZSB0aGUgcmVjZWl2ZXIgdG8gcGFyc2UgdGhl IG1lc3NhZ2UgYW5kIHJldHVybiBjb250ZW50IGJhY2sgcHJvdmluZyBwb3NzZXNzaW9uLg0KDQoN CiAgKiAgIFdlIG1heSB3YW50IGEgc2VwYXJhdGUgSW1wbGVtZW50YXRpb24gQ29uc2lkZXJhdGlv bnMgc2VjdGlvbiwgYW5kIG1vdmUgImRlbGl2ZXJ5IiwgInNlcXVlbmNpbmciIGFuZCAidGltaW5n IiBpbnRvIGl0LiBZZXMgdGhleSBhcmUgc2VjdXJpdHktcmVsZXZhbnQsIGp1c3QgbGlrZSBhbnl0 aGluZyBlbHNlIGluIHRoaXMgZG9jdW1lbnQsIGJ1dCB0aGV5IHdvdWxkIGFwcGx5IGp1c3QgYXMg d2VsbCB0byBhbnkgZXZlbnQgc3RyZWFtIHByb3RvY29sLg0KU2VlbXMgcmVhc29uYWJsZS4NCg0K DQogICogICAzLjM6IHRoaXMgaXMgdGhlIGZpcnN0IHRpbWUgd2UgbWVudGlvbiBwcm92aXNpb25p bmcuIERvIHdlIHJlYWxseSBpbnRlbmQgU0VUcyB0byBiZSB1c2VkIGZvciB0aGF0Pw0KWWVzLiBT b21lIG9mIHVzIGRvIC0gdGhpcyB3b3JrIGFjdHVhbGx5IGJlZ2FuIHdpdGhpbiB0aGUgU0NJTSBX Ry4gIFByb3Zpc2lvbmluZyB3YXMgcHJvdmlkZWQgYXMgYW4gZXhhbXBsZSBvZiBhIHR5cGUgb2Yg ZXZlbnQgd2hlcmUgb3JkZXJpbmcgd291bGQgYmUgY3J1Y2lhbC4NCg0KDQogICogICAzLjM6IElT VE0gdGhhdCB3ZSBzaG91bGQgZGVmaW5lIGEgc2VxdWVuY2luZyBtZWNoYW5pc20sIHJhdGhlciB0 aGFuIGxlYXZlIGl0IG9wZW4gdG8gcHJvZmlsZXMuIEUuZy4sIHJlcXVpcmUgYSBzZXF1ZW5jZSBu dW1iZXIgd2hlbmV2ZXIgInR4biIgaXMgdXNlZC4NCnR4biBpcyBhIHNlcGFyYXRlIGNvbmNlcHQu IHR4biBpcyB0aGVyZSB3aGVuIHB1Ymxpc2hlcnMgZGVjaWRlIHRvIGlzc3VlIG11bHRpcGxlIGV2 ZW50cyBhZ2FpbnN0IHRoZSBzYW1lIG9yaWdpbmF0aW5nIGV2ZW50LiAgRm9yIGV4YW1wbGUsIG9u ZSBzdWJzY3JpYmVyIG1pZ2h0IHVuZGVyc3RhbmQgc3VzcGljaW91cyBhY3Rpdml0eSB3aGlsZSBh bm90aGVyIG1pZ2h0IG9ubHkgdW5kZXJzdGFuZCBsb2dvdXQuIFNvbWUgaGF2ZSByZXF1ZXN0ZWQg YW4gYXR0cmlidXRlIHRoYXQgbGV0cyB0aGUgcHVibGlzaGVyIHRyYWNrIHRoYXQgdGhlIGRpZmZl cmVudCBldmVudHMgYWN0dWFsbHkgc3RlbSBmcm9tIHRoZSBzYW1lIG9yaWdpbmFsIGV2ZW50LiAg Rm9yIGV4YW1wbGUgd2hlbiBhIHB1Ymxpc2hlcnMgb3BlcmF0aW9ucyBjZW50ZXIgZ2V0cyBhIGNh bGwgdG8gdHJhY2UgYSBzZXJpZXMgb2YgZXZlbnRzLg0KDQoNCiAgKiAgIDMuNDogQWxzbywgb3Vy IHRpbWVzdGFtcHMgb25seSBoYXZlIDEgc2Vjb25kIGdyYW51bGFyaXR5LCBhbmQgc28gYXJlIHRv byBjb2Fyc2UgZm9yIHNlc3Npb24gc3RhdGUgKGNvbnNpZGVyIGF1dG9tYXRlZCBsb2dpbnMvbG9n b3V0cykuDQpUaGUgcG9pbnQgaGVyZSBpcyB0byBhZGRyZXNzIGV2ZW50IGRlc2lnbiBpc3N1ZXMg d2hlcmUgcmVseWluZyBvbiB0aW1lc3RhbXAgdG8gb3JkZXIgZXZlbnRzIGlzIHByb2JsZW1hdGlj LiBGb3IgZXhhbXBsZSBpZiB5b3Ugc2lnbmFsIGxvZ291dCBvbmx5IGJ5IHN1YmplY3QgaWRlbnRp ZmllciB0aGVuIGl0IGJlY29tZXMgaGFyZCB0byB0ZWxsIGlmIGEgdXNlciBpcyBsb2dnaW5nIGJh Y2sgaW4gb3Igbm90LiBJdCBpcyBiZXR0ZXIgdG8gY2FuY2VsIGEgc2Vzc2lvbiBhc3NvY2lhdGVk IHdpdGggYSBzdWJqZWN0IHNvIHRoYXQgdGhlIG5ldyBzZXNzaW9uIGNhbiBzdGlsbCBiZSBlc3Rh Ymxpc2hlZC4NCg0KDQogICogICAzLjU6IFdoeSBkb24ndCB3ZSBoYXZlIGFuIHVuYW1iaWd1b3Vz IHdheSB0byBkaXN0aW5ndWlzaCBTRVRzIGZyb20gYWNjZXNzIHRva2Vucywgd2h5IGxlYXZlIGl0 IHRvIGltcGxlbWVudGVycz8gU291bmRzIGxpa2UgYSBtYWpvciBzZWN1cml0eSBpc3N1ZSBpbiB0 aGUgbWFraW5nLiBXZSBzaG91bGQgY29uc2lkZXIgaGVyZSBBTEwgaW1wbGVtZW50YXRpb25zIHRo YXQgYWNjZXB0IGFjY2VzcyB0b2tlbnMsIGluY2x1ZGluZyBsZWdhY3kgaW1wbGVtZW50YXRpb25z IHRoYXQgY2Fubm90IGJlIG1vZGlmaWVkLg0KSSBhZ3JlZS4gVGhlIHJlYWwgaXNzdWUgaXMgdGhh dCBKV1TigJlzIHNob3VsZCBoYXZlIGhhZCBhIHR5cGUgdG8gYmVnaW4gd2l0aC4gT25lIG9mIHRo ZSB0aHJlYWRzIGlzIGhlcmU6DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2Vi L2lkLWV2ZW50L2N1cnJlbnQvbXNnMDAxMjAuaHRtbA0KDQoNCiAgKiAgIDQ6IFRoZSBhdWRpdCBo YXBwZW5zIG9uIHRoZSBzdWJzY3JpYmVyIHNpZGUuIEJ5IHRoZW4gaXQgaXMgdG9vIGxhdGUgdG8g cmVxdWlyZSBKV1MgdG8gYmUgdXNlZCBieSB0aGUgcHVibGlzaGVyLiBBcyBtZW50aW9uZWQsIEkg cHJvcG9zZSB0aGF0IEpXUyBzaG91bGQgQUxXQVlTIGJlIHJlcXVpcmVkLg0KVGhpcyBpcyBzb21l dGhpbmcgdGhhdCBwdWJsaXNoZXIgYW5kIHN1YnNjcmliZXIgaGF2ZSB0byBuZWdvdGlhdGUuIFRo aXMgaXMgYW50aWNpcGF0ZWQgaW4gdGhlIGRpc3RyaWJ1dGlvbiBzcGVjIHRvIHNvbWUgZGVncmVl LiBUaG91Z2ggSU1PLCB0aGVyZSBpcyBub3QgYSBsb3Qgb2YgY29uc2Vuc3VzIG9uIHRoaXMgeWV0 Lg0KDQoNCiAgKiAgIDQ6ICJXaGVuIHNoYXJpbmcgcGVyc29uYWxseSBpZGVudGlmaWFibGUgaW5m b3JtYXRpb24iIC0gd2Ugc2hvdWxkIHJlbW92ZSB0aGlzIGNvbmRpdGlvbi4gSSBkb24ndCBzZWUg YSBjYXNlIHdoZXJlIHRoZSBpbmZvcm1hdGlvbiBzaGFyZWQgaXMgTk9UIFBJSSwgYW5kIHRoZXJl Zm9yZSBsZWdhbCBhZ3JlZW1lbnRzIGFib3V0IGluZm9ybWF0aW9uIHNoYXJpbmcgYW5kIHVzZXIg Y29uc2VudCBtdXN0IGFsd2F5cyBiZSBpbiBwbGFjZS4NCkhvdyBhYm91dCBjYW5jZWxsYXRpb24g b2YgYSB0b2tlbiBvciBhIHNlc3Npb24/ICBJZiBqdXN0IHBhc3NpbmcgYSDigJxqdGnigJ0gdmFs dWUsIHRoZXJlIGlzIGFyZ3VhYmx5IG5vIFBJSS4gIFRoZSBKVEkgbWlnaHQgYmUgdHJhY2VhYmxl LCBidXQgdGhlIHJlbHlpbmcgcGFydHkgd291bGQgaGF2ZSB0byBrbm93IGFib3V0IGl0IHRvIGlu ZmVyIG1lYW5pbmcuICBBbHNvLCB0b2tlbnMvc2Vzc2lvbnMgc2hvdWxkIG5ldmVyIGJlIHBlcm1h bmVudC4gIEkgYW0gbm90IGEgbGF3eWVyLCBidXQgSSBkb3VidCB0aGVzZSBleGFtcGxlcyB3b3Vs ZCBhY3R1YWxseSBiZSBQSUkuDQoNCg0KICAqICAgNDogSSBkb24ndCB0aGluayB0aGUgc3ViamVj dCBpbmZvcm1hdGlvbiBpcyAicGVyY2VpdmVkIiBhcyBQSUkuIEl0IGlzIFBJSSwgb3RoZXJ3aXNl IGl0IHdvdWxkIGJlIHVzZWxlc3MgdG8gdGhlIHN1YnNjcmliZXIsIGJlY2F1c2UgdGhlIHN1YnNj cmliZXIgd291bGQgbm90IGJlIGFibGUgdG8gaWRlbnRpZnkgdGhlIHN1YmplY3QuIEFsc28sIGV2 ZW4gaWYgdGhlIGluZm9ybWF0aW9uIG9uIHRoZSB3aXJlIGlzIG5vdCBpbiBpdHNlbGYgUElJLCBl LmcuIHdoZW4gdXNpbmcgYSBoYXNoLCB0aGUgZmFjdCB0aGF0IGEgcHVibGlzaGVyIHNoYXJlcyBp bmZvcm1hdGlvbiB0aGF0IGEgcGFydGljdWxhciB1c2VyIGlzIGFsc28gYSB1c2VyIG9uIGl0cyBz eXN0ZW0gYW5kIGlzIHVuZGVyZ29pbmcgY2VydGFpbiBzdGF0ZSBjaGFuZ2VzIGlzIHByaXZhY3kt c2Vuc2l0aXZlLg0KQWdhaW4sIHRoZSBzdWJqZWN0IG9mIGFuIGV2ZW50IG1pZ2h0IGJlIGFib3V0 IGEgc2Vzc2lvbiBvciBhIHRva2VuLCBkZXZpY2UsIGV0Yy4NCg0KDQogICogICBJIHN1Z2dlc3Qg dG8gYWRkIGFuIEltcGxlbWVudGF0aW9uIFN0YXR1cyBzZWN0aW9uLCBwZXIgUkZDIDc5NDIuDQpJ dCB3b3VsZCBiZSBoZWxwZnVsIGZvciB0aGUgY2hhaXJzIHRvIHByb3ZpZGUgZ3VpZGFuY2Ugb24g dGhpcy4NCg0KVGhhbmtzLA0KICAgIFlhcm9uDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KSWQtZXZlbnQgbWFpbGluZyBsaXN0DQpJZC1ldmVudEBpZXRm Lm9yZzxtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2lkLWV2ZW50DQoNCg== --_000_BN3PR03MB235507D80D7BC915FA6775A4F59A0BN3PR03MB2355namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJTZWdvZSBVSSI7 DQoJcGFub3NlLTE6MiAxMSA1IDIgNCAyIDQgMiAyIDM7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21z by1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCnNwYW4uYXBwbGUtc3R5bGUtc3Bhbg0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1zdHls ZS1zcGFuO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFw cGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj b2xvcjojMDAyMDYwO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41 aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBs aXN0IGwwDQoJe21zby1saXN0LWlkOjE4MTE2NzYxNzsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6 MjY3NDM0MjUyO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs MDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDps ZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDo0 MjA2MTIwMTY7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE1NDIyNDc4MzY7fQ0KQGxpc3QgbDE6 bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToi Q291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30N CkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVs NA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsOA0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCkBsaXN0IGwyDQoJe21zby1saXN0LWlkOjQ0MTAwMDgxMjsNCgltc28tbGlzdC10 ZW1wbGF0ZS1pZHM6MTAyNjg1MTM2Njt9DQpAbGlzdCBsMjpsZXZlbDENCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwyOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJp ZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDI6bGV2ZWwzDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDI6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI6 bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw3DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQu MGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDI6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDMNCgl7 bXNvLWxpc3QtaWQ6NzA3NDg1OTYxOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTU1MDA0ODI4 ODt9DQpAbGlzdCBsMzpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVs Mg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiI7fQ0KQGxpc3QgbDM6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDM6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDM6bGV2ZWw1 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDM6bGV2ZWw2DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDM6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDM6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDM6bGV2ZWw5DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDQNCgl7bXNvLWxpc3QtaWQ6ODM3NzczODYx Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTg0OTY4MjM1MDt9DQpAbGlzdCBsNDpsZXZlbDEN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3Qg bDQ6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDQ6bGV2ZWw0DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDQ6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDQ6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDQ6 bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDQ6bGV2ZWw4DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDQ6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQu NWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDUNCgl7bXNvLWxpc3QtaWQ6OTExMzA4NjE4Ow0KCW1zby1saXN0LXRlbXBsYXRl LWlkczo2NzgwODg2MzA7fQ0KQGxpc3QgbDU6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41 aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsNTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGw1OmxldmVsMw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGw1OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGw1OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw1OmxldmVsNg0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw1OmxldmVsNw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCkBsaXN0IGw1OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0 IGw1OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw2DQoJe21zby1saXN0 LWlkOjk2MDMwNzExMTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTk0NDczNzAwO30NCkBsaXN0 IGw2OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDY6bGV2ZWwyDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZl bC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Ijt9DQpAbGlzdCBsNjpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNjps ZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNjpsZXZlbDUNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNjpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4w aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsNjpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNjpsZXZl bDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNjpsZXZlbDkNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsNw0KCXttc28tbGlzdC1pZDoxMDY2ODczODE0Ow0KCW1zby1s aXN0LXRlbXBsYXRlLWlkczotMTI0MDAwNzM2ODt9DQpAbGlzdCBsNzpsZXZlbDENCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGw3OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJ bXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDc6bGV2ZWwz DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDc6bGV2ZWw0DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDc6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDc6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDc6bGV2ZWw3DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDc6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDc6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDgNCgl7bXNvLWxpc3QtaWQ6MTA4NDE4NDg3MzsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTg3 NTY2OTg3MDt9DQpAbGlzdCBsODpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw4 OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDg6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDg6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDg6 bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDg6bGV2ZWw2DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDg6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMu NWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDg6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDg6bGV2 ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDkNCgl7bXNvLWxpc3QtaWQ6MTIz NDY2MDMyODsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTI1ODI4OTYwODt9DQpAbGlzdCBsOTps ZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw5OmxldmVsMg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0K QGxpc3QgbDk6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDk6bGV2ZWw0 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDk6bGV2ZWw1DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDk6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDk6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDk6bGV2ZWw4DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDk6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDEwDQoJe21zby1saXN0LWlkOjEyNDgwMzM1Mzk7DQoJbXNvLWxpc3Qt dGVtcGxhdGUtaWRzOi0xOTY2OTE1NzY7fQ0KQGxpc3QgbDEwOmxldmVsMQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDEwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNv LWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDEwOmxldmVsMw0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMTA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDEwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxMDpsZXZlbDcN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTA6bGV2ZWw4DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDEwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGwxMQ0KCXttc28tbGlzdC1pZDoxMzIxNzMwODU4Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlk czoxNzY4NjE2NTA7fQ0KQGxpc3QgbDExOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDExOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDExOmxldmVsMw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGwxMTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsMTE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDExOmxldmVs Ng0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxMTpsZXZlbDcNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMTE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDExOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxMg0KCXtt c28tbGlzdC1pZDoxMzI1MTU5MDk2Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxMTY1NTE0OTA2 O30NCkBsaXN0IGwxMjpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxMjpsZXZl bDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iO30NCkBsaXN0IGwxMjpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41 aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsMTI6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDEyOmxl dmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxMjpsZXZlbDYNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTI6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMu NWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDEyOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxMjps ZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTMNCgl7bXNvLWxpc3QtaWQ6 MTMyOTk0Mjc3ODsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE0MzY4MDExNTg7fQ0KQGxpc3Qg bDEzOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDEzOmxldmVsMg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biI7fQ0KQGxpc3QgbDEzOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwx MzpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTM6bGV2ZWw1DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDEzOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwxMzpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs MTM6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDEzOmxldmVsOQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxNA0KCXttc28tbGlzdC1pZDoxMzQ0NDMzMDI3 Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTkyNjcxMjQ0Mjt9DQpAbGlzdCBsMTQ6bGV2ZWwx DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTQ6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3Rv cDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlz dCBsMTQ6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE0OmxldmVsNA0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxNDpsZXZlbDUNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMTQ6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDE0OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxNDpsZXZlbDgN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTQ6bGV2ZWw5DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDE1DQoJe21zby1saXN0LWlkOjEzNjQ0NzczODc7DQoJbXNvLWxp c3QtdGVtcGxhdGUtaWRzOjE4MDk5ODgzNjY7fQ0KQGxpc3QgbDE1OmxldmVsMQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDE1OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJ bXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDE1OmxldmVs Mw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxNTpsZXZlbDQNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMTU6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDE1OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxNTpsZXZl bDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTU6bGV2ZWw4DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE1OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwxNg0KCXttc28tbGlzdC1pZDoxMzk5ODY0ODk2Ow0KCW1zby1saXN0LXRlbXBsYXRl LWlkczotNjQ4MzU1MjI0O30NCkBsaXN0IGwxNjpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwxNjpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwxNjpsZXZlbDMNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTY6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIu MGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDE2OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxNjps ZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTY6bGV2ZWw3DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE2OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0 LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGwxNjpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTcN Cgl7bXNvLWxpc3QtaWQ6MTU3MTUwMzY1NTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTY1NzU4 Mzk3ODt9DQpAbGlzdCBsMTc6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTc6 bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMTc6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDE3OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwx NzpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTc6bGV2ZWw2DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE3OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwxNzpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs MTc6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE4DQoJe21zby1saXN0 LWlkOjE2NjI2NTQyNDA7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xMDUzMTQwMjI4O30NCkBs aXN0IGwxODpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxODpsZXZlbDINCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNv LWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iO30NCkBsaXN0IGwxODpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsMTg6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE4OmxldmVsNQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxODpsZXZlbDYNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMTg6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDE4OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxODpsZXZlbDkN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTkNCgl7bXNvLWxpc3QtaWQ6MTY4ODQ4 MDM4OTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTU0NzA0OTE1MDt9DQpAbGlzdCBsMTk6bGV2 ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTk6bGV2ZWwyDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWIt c3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpA bGlzdCBsMTk6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE5OmxldmVs NA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOTpsZXZlbDUNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMTk6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDE5OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOTpsZXZl bDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTk6bGV2ZWw5DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDIwDQoJe21zby1saXN0LWlkOjE3NTQ0NzU4OTY7DQoJbXNv LWxpc3QtdGVtcGxhdGUtaWRzOjQzMTk0NDY2Njt9DQpAbGlzdCBsMjA6bGV2ZWwxDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMjA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsN Cgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMjA6bGV2 ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDIwOmxldmVsNA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41 aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsMjA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDIwOmxl dmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyMDpsZXZlbDgNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQu NWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDIxDQoJe21zby1saXN0LWlkOjE3OTkxMDUzMDY7DQoJbXNvLWxpc3QtdGVtcGxh dGUtaWRzOi0xNzUyNTQ5MTMyO30NCkBsaXN0IGwyMTpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwyMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRp LWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwyMTpsZXZlbDMNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjE6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDIxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwy MTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjE6bGV2ZWw3DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDIxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwyMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs MjINCgl7bXNvLWxpc3QtaWQ6MTg0MzQ3MDA5NjsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTEz MTY5NDYxNzg7fQ0KQGxpc3QgbDIyOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDIyOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDIyOmxldmVsMw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCkBsaXN0IGwyMjpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsMjI6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDIyOmxldmVsNg0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyMjpsZXZlbDcNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMjI6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDIyOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyMw0KCXttc28t bGlzdC1pZDoxODk2ODE5MTQwOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotNjU2MTI0ODIwO30N CkBsaXN0IGwyMzpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyMzpsZXZlbDIN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iO30NCkBsaXN0IGwyMzpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsMjM6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDIzOmxldmVs NQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyMzpsZXZlbDYNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMjM6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDIzOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyMzpsZXZl bDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjQNCgl7bXNvLWxpc3QtaWQ6MjA5 OTI3OTM2NDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE4NjIyNTU0OTQ7fQ0KQGxpc3QgbDI0 OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI0OmxldmVsMg0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7 fQ0KQGxpc3QgbDI0OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyNDps ZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjQ6bGV2ZWw1DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI0OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoz LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGwyNDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjQ6 bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI0OmxldmVsOQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyNQ0KCXttc28tbGlzdC1pZDoyMTAzMzI5ODM2Ow0K CW1zby1saXN0LXRlbXBsYXRlLWlkczoxMTA3NDc1MjA0O30NCkBsaXN0IGwyNTpsZXZlbDENCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyNTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEu MGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBO ZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwy NTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjU6bGV2ZWw0DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI1OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwyNTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs MjU6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI1OmxldmVsOA0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyNTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpAbGlzdCBsMjYNCgl7bXNvLWxpc3QtaWQ6MjExMTEyNTg0MTsNCgltc28tbGlzdC10 ZW1wbGF0ZS1pZHM6MTMyNzExNDc5Mjt9DQpAbGlzdCBsMjY6bGV2ZWwxDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMjY6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28t YmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMjY6bGV2ZWwzDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI2OmxldmVsNA0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCkBsaXN0IGwyNjpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsMjY6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI2OmxldmVsNw0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyNjpsZXZlbDgNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMjY6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wN Cgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMDAyMDYwIj5MZXQgbWUgYWxzbyB0aGFuayB5b3UgZm9yIHRoZXNlIGRldGFpbGVk IGNvbW1lbnRzLCBZYXJvbi4mbmJzcDsgVGhleeKAmXJlIHZlcnkgdXNlZnVsITxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAy MDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+SeKAmW0gb24gdmFjYXRpb24gdGhpcyB3ZWVrIGJ1 dCBoYXZlIGFscmVhZHkgZmxhZ2dlZCB0aGlzIHRvIHJlc3BvbmQgdG8gaW4gZGV0YWlsIG5leHQg d2Vlay4mbmJzcDsgVGhhdCBzYWlkLCBJIGFncmVlIHdpdGggbWFueSBvZiBQaGls4oCZcyByZXNw b25zZXMuJm5ic3A7IFRoYXQgc2FpZCwgSSBhbSBhZ2FpbnN0IGNoYW5naW5nIOKAnGV2ZW50c+KA nSB0byDigJxldmVudOKAnS4mbmJzcDsgSXTigJlzIGFwcGxpY2F0aW9uLWRlcGVuZGVudA0KIHdo ZXRoZXIgdGhlcmUgaXMgb25seSBvbmUgZXZlbnQsIGEgc2V0IG9mIHJlbGF0ZWQgZXZlbnRzIHNo YXJpbmcgY29udGV4dCwgYW5kIHdoaWNoIGlzIHByaW1hcnkuJm5ic3A7IEkgdGhpbmsgd2Ugc2hv dWxkIHJlbWFpbiBnZW5lcmFsIGluIHRoaXMgcmVnYXJkLiZuYnNwOyAoWWVzLCB3ZSBkbyBuZWVk IHRvIGZpbmlzaCBjbGVhbmluZyB1cCB0aGUgbGFuZ3VhZ2UgbGVmdG92ZXIgZnJvbSB3aGVuIGV2 ZW50cyB3ZXJlIHJlcHJlc2VudGVkIGluIGEgSlNPTiBhcnJheQ0KIHJhdGhlciB0aGFuIGEgSlNP TiBvYmplY3QuKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFu IHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0K PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjwvc3Bhbj4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9t OjwvYj4gSWQtZXZlbnQgW21haWx0bzppZC1ldmVudC1ib3VuY2VzQGlldGYub3JnXSA8Yj4NCk9u IEJlaGFsZiBPZiA8L2I+UGhpbCBIdW50PGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgRGVj ZW1iZXIgMTQsIDIwMTYgMTI6MTggUE08YnI+DQo8Yj5Ubzo8L2I+IFlhcm9uIFNoZWZmZXIgJmx0 O3lhcm9uZi5pZXRmQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IFNlY0V2ZW50ICZsdDtp ZC1ldmVudEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtJZC1ldmVudF0g U29tZSBjb21tZW50cyB0byBkcmFmdC1odW50LWlkZXZlbnQtdG9rZW4tMDc8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPllhcm9uLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLiBNeSByZXNw b25zZXMgaW5saW5lLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+UGhpbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5AaW5kZXBlbmRlbnRpZDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+PGEgaHJlZj0iaHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNvbSI+ d3d3LmluZGVwZW5kZW50aWQuY29tPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj48YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iPnBoaWwu aHVudEBvcmFjbGUuY29tPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P biBEZWMgMTAsIDIwMTYsIGF0IDE6MjcgUE0sIFlhcm9uIFNoZWZmZXIgJmx0OzxhIGhyZWY9Im1h aWx0bzp5YXJvbmYuaWV0ZkBnbWFpbC5jb20iPnlhcm9uZi5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5I aSwgSSBmaW5hbGx5IHJlYWQgdGhlIGRyYWZ0IGluIGRldGFpbCwgYW5kIEkgZG8gaGF2ZSBhIGZl dyBjb21tZW50cy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+TXkgbWFp biBzdWdnZXN0aW9uIGlzIHRvIHRpZ2h0ZW4gdGhlIHNwZWNpZmljYXRpb24gb2YgYW4gRXZlbnQs IGJ5IGRlZmluaW5nIG1vcmUgc3RyaWN0bHkgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiAmcXVvdDtl dmVudCZxdW90OyBhbmQgJnF1b3Q7ZXZlbnQgZXh0ZW5zaW9uJnF1b3Q7IGFuZCB0d2Vha2luZyB0 aGUgSlNPTiBzdHJ1Y3R1cmUgYQ0KIGJpdC48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBzcGVjIGhhcyB1bmRl cmdvbmUgc29tZSByZXN0cnVjdHVyaW5nIHJlY2VudGx5LCBhbmQgaXQgbWF5IG5lZWQgc29tZSBt b3JlIHRpZ2h0ZW5pbmcgdXAuIFRoZSBpbmZvcm1hbCBjb25zZW5zdXMgZnJvbSB0aGUgaWQtZXZl bnRzIGxpc3QgaXMgdGhhdCB0aGVyZSBzaG91bGQgYmUgb25seSBvbmUgZXZlbnQuIEhvd2V2ZXIs IGluIG9yZGVyIHRvIGFsbG93IHNvbWUgZGVwbG95ZXJzIHRvIHByb3ZpZGUgYWRkaXRpb25hbA0K IGluZm9ybWF0aW9uLCBhbmQgZXh0ZW5zaW9uIG1ldGhvZG9sb2d5IHdhcyBpbmNsdWRlZC4gJm5i c3A7QW4gZXhhbXBsZSBpcyBnaXZlbi48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkluIGFkZGl0aW9uLCBJIHRoaW5rIHdl IHNob3VsZCByZXF1aXJlIHRoZSBjbGFpbSB0byBiZSBzaWduZWQsIHNpbmNlIGl0IHdpbGwgYmUg dXNlZCBmb3Igc2VjdXJpdHktc2Vuc2l0aXZlIGFjdGl2aXRpZXMgYWNyb3NzIGNvbXBsZXggZGlz dHJpYnV0ZWQgc3lzdGVtcy48bzpwPjwvbzpwPjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MGluO2xpbmUtaGVpZ2h0OjIwLjI1cHQ7bXNv LWxpc3Q6bDI2IGxldmVsMSBsZm8xO2JveC1zaXppbmc6IGJvcmRlci1ib3g7Y3Vyc29yOmRlZmF1 bHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vn b2UgVUkmcXVvdDssc2Fucy1zZXJpZiI+MTogV2h5IGlzIHNpZ25pbmcgb3B0aW9uYWw/IFRoZSBw dWJsaXNoZXIgZG9lc24ndCBrbm93IGhvdyB0aGUgc3Vic2NyaWJlcidzIHN5c3RlbSBpcyBhcmNo aXRlY3RlZCwgYW5kIG1pZ2h0IHdlbGwgd2FudCBlbmQtdG8tZW5kIGF1dGhlbnRpY2F0aW9uIG9m IHRoZSBjbGFpbS4gVGhpcyBpcyBhbHNvIGltcG9ydGFudCBmb3IgYXVkaXRpbmcuPG86cD48L286 cD48L3NwYW4+PC9saT48L3VsPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgdGhlIGtleSB3b3JkIGluIHlvdXIgcXVlc3Rpb24gaXMg 4oCcbWlnaHTigJ0uICZuYnNwO0Fsc28sIGl0cyBub3QgdGhlIHB1Ymxpc2hlciB0aGF0IG5lZWRz IGF1dGhlbnRpY2F0aW9uIG9mIHRoZSBzdGF0ZW1lbnQgaXRzIHJlYWxseSB0aGUgc3Vic2NyaWJl ci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ TWFueSBoYXZlIHByZWZlcnJlZCB0byBoYXZlIGEgbWluaW11bSBvcHRpb24gd2hlcmUgc2VjdXJp dHkgaXMgZXNzZW50aWFsbHkgcG9pbnQtdG8tcG9pbnQgZGVwZW5kaW5nIHByaW1hcmlseSBvbiBU TFMuICZuYnNwO1RoZXJlIGFyZSBvdGhlciBjYXNlcyB3aGVyZSBlbmQtdG8tZW5kIGtleSBiYXNl ZCBpcyBwcmVmZXJyZWQgZXNwZWNpYWxseSB3aGVuIHRyYW5zbWl0dGluZyBvdmVyIGxlc3Mgc2Vj dXJlIHRyYW5zcG9ydC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+UmVtZW1iZXIgdGhhdCB0aGlzIHNwZWNpZmljYXRpb24gaXMgYSBjb21pbmcg dG9nZXRoZXIgb2YgYSBidW5jaCBvZiBpbml0aWF0aXZlcyBhcm91bmQgYSBjb21tb24gZm9ybWF0 LiBJdCBpcyBkaWZmaWN1bHQgdG8gYXNzaWduIG1hbmRhdG9yeSByZXF1aXJlbWVudHMgdW5sZXNz IHRoZXJlIGlzIHN0cm9uZyBjb25zZW5zdXMgdG8gZG8gc28uPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwv cD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxkaXY+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21hcmdpbi1sZWZ0OjBpbjtsaW5lLWhlaWdodDoyMC4yNXB0O21zby1saXN0OmwyMiBsZXZl bDEgbGZvMiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVv dDtTZWdvZSBVSSZxdW90OyxzYW5zLXNlcmlmIj4xOiAmcXVvdDtleGFtcGxlIGV2ZW50cyZxdW90 OyAtIGlzIHNwZWNpZmljYXRpb24gb2YgaW5kaXZpZHVhbCBldmVudHMgKG1heWJlIG9ubHkgYSBm ZXcgYmFzaWMgb25lcykgd2l0aGluIHNjb3BlIG9mIG91ciBjaGFydGVyPyBPdGhlcndpc2Ugd2Ug Y2Fubm90IGd1YXJhbnRlZSBpbnRlcm9wLjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC91bD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgaW50 ZW50aW9uIGlzIHRvIGRlZmluZSBhIGJhc2UgbGV2ZWwgZm9ybWF0IHRoYXQgb3RoZXIgd29ya2lu ZyBncm91cHMgYW5kIFNET3Mgd2lsbCB1c2UgdG8gZGVmaW5lIHRoZWlyIG93biBldmVudHMuIFRo ZSBwcmltYXJ5IGJlbmVmaXQgaXMgdG8gaGF2ZSBhIGNvbW1vbiBmb3JtYXQuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGFkIG9yaWdpbmFs bHkgZW52aXNpb25lZCBhbiBldmVudCByZWdpc3RyeSwgYnV0IHRoZSBlYXJseSBkaXNjdXNzaW9u cyB3ZXJlIHRvIGF2b2lkIElBTkEgcmVnaXN0cmF0aW9uLiBXZSB0aGVuIHN3aXRjaGVkIHRvIHVz aW5nIFVSSeKAmXMgZm9yIGV2ZW50cy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGluZm9ybWFsIGNvbnNlbnN1cyB3YXMgdGhh dCB3aGF0IG1hdHRlcnMgaXMgdGhhdCBwdWJsaXNoZXIgYW5kIHN1YnNjcmliZXIgYWdyZWUgb24g bWVhbmluZyBhbmQgdGhhdCBpdCBpcyBvayBmb3IgZXZlbnRzIHRvIGJlIGhpZ2hseSBzcGVjaWZp Yy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8dWwgdHlw ZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjBpbjtsaW5lLWhl aWdodDoyMC4yNXB0O21zby1saXN0OmwxMSBsZXZlbDEgbGZvMyI+DQo8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90OyxzYW5zLXNlcmlm Ij4xLjI6IHByaW5jaXBsZSAtJmd0OyBwcmluY2lwYWw8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwv dWw+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Tm90ZWQ8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8dWwgdHlw ZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjBpbjtsaW5lLWhl aWdodDoyMC4yNXB0O21zby1saXN0OmwxOSBsZXZlbDEgbGZvNCI+DQo8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90OyxzYW5zLXNlcmlm Ij4yOiAmcXVvdDtmaXJzdCB2YWx1ZSZxdW90OyBpcyBtZWFuaW5nbGVzcy4gSlNPTiBvYmplY3Rz IGFyZSB1bm9yZGVyZWQgKDR0aCBwYXJhZ3JhcGggb2YgUkZDIDcxNTkpLiBJZiBvcmRlcjxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48ZW0+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LHNhbnMtc2VyaWYiPmlzPC9zcGFu PjwvZW0+DQogaW1wb3J0YW50LCB3ZSBjb3VsZCBtYWtlICZxdW90O2V2ZW50cyZxdW90OyBpbnRv IGFuIGFycmF5LjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC91bD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZdXAuICZuYnNwOyBIb3cgd291bGQg dGhlIGdyb3VwIGxpa2UgdG8gZml4IHRoaXM/ICZuYnNwO1dlIGNvdWxkIG1ha2Ug4oCcZXZlbnRz 4oCdIHNpbmd1bGFyIGFuZCBoYXZlIGFuIGV4dGVuc2lvbnMgYXR0cmlidXRlIHRvIGhvbGQgdGhl IGV4dGVuc2lvbnMuICZuYnNwO09yIHdlIGNvdWxkIGdvIHRvIGEgbW9yZSBjb21wbGV4IEpTT04g c3RydWN0dXJlIChub3QgcGVyc29uYWxseSBhIGZhbikuPGJyPg0KPGJyPg0KPG86cD48L286cD48 L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttYXJnaW4tbGVmdDowaW47bGluZS1oZWlnaHQ6MjAuMjVwdDttc28tbGlzdDpsMTYgbGV2 ZWwxIGxmbzUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7U2Vnb2UgVUkmcXVvdDssc2Fucy1zZXJpZiI+MjogZXZlbnQgZXh0ZW5zaW9ucyBhcmUgbm90 IGRlZmluZWQgYnV0IG9ubHkgaW50cm9kdWNlZCBieSB0aGUgdGV4dCBhZnRlciB0aGV5IGFyZSBk ZXNjcmliZWQuIEFsc28sIGluIHRoZSBleGFtcGxlIHRoZXJlJ3MgdGhpcyBVUkw6PHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8v ZXhhbXBsZS5jb20vJUUyJTgwJThCc2NpbS8lRTIlODAlOEJldmVudC8lRTIlODAlOEJwYXMlRTIl ODAlOEJzd29yJUUyJTgwJThCZFJlcyVFMiU4MCU4QmV0RXglRTIlODAlOEJ0Ij5odHRwczovL+KA i2V4YW1wbGUu4oCLY29tL+KAi3NjaW0v4oCLZXZlbnQv4oCLcGFz4oCLc3dvcuKAi2RSZXPigItl dEV44oCLdDwvYT48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+LQ0KIEkgYmVsaWV2ZSBpdCBuZWVkcyB0byBiZSBwYXJ0IG9mIHRoZSBwYXNzd29yZFJlc2V0 IG9iamVjdCBhbmQgbm90IHBhcmFsbGVsIHRvIGl0LjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC91 bD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J IHdpbGwgY2hlY2sgZm9yIGNsYXJpdHkuIFRoZSBwYXNzd29yZCBleGFtcGxlIGlzIGludGVuZGVk IHRvIGRlbW9uc3RyYXRlIGFuIGV4YW1wbGUgd2hlcmUgYSBwdWJsaXNoZXIgd2lzaGVzIHRvIHBy b3ZpZGUgYWRkaXRpb25hbCBjb250ZXh0IHN1Y2ggYXMgdGhlIG51bWJlciBvZiByZXNldHMgcGVy Zm9ybWVkLiAmbmJzcDtOb3RlIGluIGRlZmluaW5nIGEgcGFzc3dvcmQgcmVzZXQgZXZlbnQgaXQg bWlnaHQgaW5kZWVkDQogbWFrZSBzZW5zZSB0byBjb21iaW5lIHRoYXQgaW5mby4gTXkgaW50ZW50 IHdhcyB0byBzaG93IGFuIGV4dGVuc2lvbi4gTWF5YmUgdGhlcmUgaXMgYSBiZXR0ZXIgaHlwb3Ro ZXRpY2FsIGV4YW1wbGU/PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2 Pg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDow aW47bGluZS1oZWlnaHQ6MjAuMjVwdDttc28tbGlzdDpsMjAgbGV2ZWwxIGxmbzYiPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDss c2Fucy1zZXJpZiI+V2h5ICZxdW90O2V2ZW50cyZxdW90OyBhbmQgbm90ICZxdW90O2V2ZW50JnF1 b3Q7PyBXZSBkb24ndCByZWFsbHkgaGF2ZSBzdXBwb3J0IGZvciBtdWx0aXBsZSBldmVudHMuIENl cnRhaW5seSBub3QgaWYgdGhleSBhcmUgYWxsIG9mIHRoZSBzYW1lIHR5cGUuIFRoZSBjdXJyZW50 IHRleHQgaXMgY29uZnVzaW5nOiAmcXVvdDtldmVudHMmcXVvdDsgaXMgbm90IHRoZSBzYW1lIGFz ICZxdW90O2EgcHJpbWFyeQ0KIGV2ZW50IGFuZCBpdHMgZXh0ZW5zaW9uc+KAnS48bzpwPjwvbzpw Pjwvc3Bhbj48L2xpPjwvdWw+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+UmVmbGVjdHMgeW91ciBlYXJsaWVyIGNvbW1lbnQgcmU6IHByaW1hcnkg dnMuIGV4dGVuc2lvbnMuICZuYnNwOyZxdW90O2V2ZW50c+KAnSBpcyBwbHVyYWwgdG8gcmVmbGVj dCB0aGUgZmFjdCB0aGF0IHRoZSBhdHRyaWJ1dGUgaXMgbXVsdGktdmFsdWVkLiBJIGFncmVlLCBn aXZlbiB0aGF0IG9ubHkgb25lIHByaW1hcnkgZXZlbnQgY2FuIGJlIGluY2x1ZGVkLCB0aGUgbmFt aW5nIGlzIG1pc2xlYWRpbmcuPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 ZGl2Pg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVm dDowaW47bGluZS1oZWlnaHQ6MjAuMjVwdDttc28tbGlzdDpsMSBsZXZlbDEgbGZvNyI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90 OyxzYW5zLXNlcmlmIj4mcXVvdDtJbiB0aGUgYWJvdmUgZXhhbXBsZSAmcXVvdDtpc3MmcXVvdDsg YW5kICZxdW90O3N1YiZxdW90OyBjb250YWluZWQgd2l0aGluIHRoZSBjbGFpbSZxdW90OyAtIHRo aXMgaXMgaW5jb3JyZWN0LCBwcm9iYWJseSBsZWZ0b3ZlciBmcm9tIGFuIGVhcmxpZXIgdmVyc2lv bi48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Tk8uICZuYnNwO0luIHRoZSBleGFtcGxlLCDigJxp c3PigJ0gYW5kIOKAnHN1YuKAnSBpbmRpY2F0ZSB0aGUgc3ViamVjdCBpcyBmcm9tIGEgZGlmZmVy ZW50IGlzc3VlciBvZiB0aGUgZXZlbnQuICZuYnNwO0ZvciBleGFtcGxlIGEgcmVseWluZyBwYXJ0 eSB3ZWIgc2l0ZSB3YW50cyB0byB0ZWxsIHRoZSBpZGVudGl0eSBwcm92aWRlciAodGhlIG9yaWdp bmFsIHN1YmplY3QgaXNzdWVyKSB0aGF0IHRoZSB1c2VyIGhhcyByZXF1ZXN0ZWQgYSBsb2dvdXQu PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHVsIHR5cGU9ImRp c2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDowaW47bGluZS1oZWlnaHQ6 MjAuMjVwdDttc28tbGlzdDpsMTggbGV2ZWwxIGxmbzgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssc2Fucy1zZXJpZiI+JnF1 b3Q7YXVkJnF1b3Q7IE1BWSBiZSBhIFVSSTogc2hvdWxkbid0IGl0IGJlIGFuIGFycmF5LCBtYXli ZSBhbiBhcnJheSB0aGF0IGNvbnRhaW5zIGEgc2luZ2xlIFVSST88bzpwPjwvbzpwPjwvc3Bhbj48 L2xpPjwvdWw+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhpcyBpcyBkZWZpbmVkIGJ5IHRoZSBKV1Qgc3BlYy48YnI+DQo8YnI+DQo8bzpwPjwv bzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21hcmdpbi1sZWZ0OjBpbjtsaW5lLWhlaWdodDoyMC4yNXB0O21zby1saXN0Omwy MyBsZXZlbDEgbGZvOSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWls eTomcXVvdDtTZWdvZSBVSSZxdW90OyxzYW5zLXNlcmlmIj5XaHkgZG8gd2UgdXNlIHRoZSB0ZXJt cyAmcXVvdDtzaW5nbGUtdmFsdWVkJnF1b3Q7IHZzLiAmcXVvdDttdWx0aXBsZS12YWx1ZWQmcXVv dDsgc3RyaW5ncz8gV2h5IG5vdCB1c2UgdGhlIG5vcm1hbCBKU09OIHRlcm1pbm9sb2d5LCAmcXVv dDtzdHJpbmcmcXVvdDsgdnMuICZxdW90O2FycmF5IG9mIHN0cmluZ3PigJ0/PG86cD48L286cD48 L3NwYW4+PC9saT48L3VsPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkhhYml0IGZyb20gdGhlIHdvcmxkIG9mIElETS4gV2UgY291bGQgYWxpZ24g aXQuPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHVsIHR5cGU9 ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDowaW47bGluZS1oZWln aHQ6MjAuMjVwdDttc28tbGlzdDpsMjEgbGV2ZWwxIGxmbzEwIj4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LHNhbnMtc2VyaWYi PldoeSBpcyAmcXVvdDtzdWImcXVvdDsgb3B0aW9uYWw/IERvIHdlIGhhdmUgYW55IGdvb2QgZXhh bXBsZXMgb2YgZXZlbnRzIHdoZXJlIHRoaXMgdmFsdWUgaXMgbm90IHJlcXVpcmVkPzxvOnA+PC9v OnA+PC9zcGFuPjwvbGk+PC91bD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5Zb3UgbWlnaHQgaGF2ZSBhbiBldmVudCBhYm91dCBhIHNlc3Npb24s IG9yIGFuIElQIGFkZHJlc3MsIG9yIHNvbWUgb3RoZXIgdGhpbmcuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZXJlIHdhcyBhbiBlbWFpbCBk aXNjdXNzaW9uIGluIHRoZSBwYXN0IGFib3V0IHdoZXRoZXIgc3ViIHNob3VsZCBiZSBhIHNlY3Vy aXR5IHN1YmplY3QgKGUuZy4gYXMgZGVmaW5lZCBieSBTQU1MIG9yIE9wZW5JRCBDb25uZWN0KSwg b3Igd2hldGhlciBzdWIgaXMganVzdCB0aGUgc3ViamVjdCBvZiB0aGUgZXZlbnQgYW5kIHRodXMg Y2FuIGJlIGFueXRoaW5nLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JIGV4cGVjdCB0byBzZWUgbW9yZSBkaXNjdXNzaW9uIG9uIHRoaXMuPGJy Pg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHVsIHR5cGU9ImRpc2Mi Pg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDowaW47bGluZS1oZWlnaHQ6MjAu MjVwdDttc28tbGlzdDpsMTIgbGV2ZWwxIGxmbzExIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LHNhbnMtc2VyaWYiPiZxdW90 O2EgZnV0dXJlIGRhdGUmcXVvdDsgLSB3ZSBzaG91bGQgY2xhcmlmeSB0aGF0IHRoZXJlIG1heSBi ZSBjYXNlcyB3aGVuIG5iZiBpcyBzbWFsbGVyIHRoYW4gaWF0LCBpLmUuIHdoZW4gaXQgdGFrZXMg c29tZSB0aW1lIHVudGlsIHRoZSBTRVQgaXMgaXNzdWVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+ PC91bD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5Bc3N1bWUgeW91IGFyZSByZWZlcnJpbmcgdG8g4oCcbmJm4oCdLiBUaGUgZGVmaW5pdGlvbiBj b21lcyBmcm9tIEpXVC4mbmJzcDs8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxkaXY+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1s ZWZ0OjBpbjtsaW5lLWhlaWdodDoyMC4yNXB0O21zby1saXN0Omw3IGxldmVsMSBsZm8xMiI+DQo8 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZx dW90OyxzYW5zLXNlcmlmIj4mcXVvdDtleHAmcXVvdDsgLSBpcyBpdCBhbHNvIGEgTnVtZXJpY0Rh dGU/IFBsZWFzZSBzcGVjaWZ5LjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC91bD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EZWZpbmVkIGJ5IEpX VCwgUkZDNzUxOTxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjx1 bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MGluO2xp bmUtaGVpZ2h0OjIwLjI1cHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEzIj4NCjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LHNhbnMt c2VyaWYiPkluIHRoZSBtZWRpY2FsIGV4YW1wbGUsIGl0IGlzIHN0cmFuZ2UgdGhhdCB0aGUgZXZl bnQgaXMgbmFtZWQgYnkgYSBVUkwgdGhhdCBwb2ludHMgdG8gYW4gSFRNTCBwYWdlLiBJIHdvdWxk IGV4cGVjdCBhIG1vcmUgc3RhYmxlIFVSSS48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgaXMg YW4gZXhhbXBsZS4gTWFueSBoYXZlIGluZGljYXRlZCB0aGF0IHRoZXkgd2FudCB0aGUgZXZlbnQg c2hvdWxkIGJlIGEgVVJMIHRvIHRoZSBwYWdlIHRoYXQgZGVmaW5lcyB0aGUgZXZlbnQuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8dWwgdHlwZT0iZGlz YyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjBpbjtsaW5lLWhlaWdodDoy MC4yNXB0O21zby1saXN0OmwzIGxldmVsMSBsZm8xNCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90OyxzYW5zLXNlcmlmIj4yLjI6 IGlzIGVuY3J5cHRpb24gYSBNVVNUIHdoZW5ldmVyIHRoZXJlIGFyZSBhdHRyaWJ1dGVzIHNwZWNp ZmllZD8gSWYgc28sIHdlIHNob3VsZCBoYXZlIGEgbm9ybWF0aXZlIHNlY3Rpb24gc2F5aW5nIHNv LCBub3QganVzdCBtZW50aW9uIGl0IGluIHRoZSBjb250ZXh0IG9mIGFuIGV4YW1wbGUuIEJlc2lk ZXMsIHdlIGhhdmUgbm90IGRlZmluZWQNCiB3aGF0IGF0dHJpYnV0ZXMgYXJlLjxvOnA+PC9vOnA+ PC9zcGFuPjwvbGk+PC91bD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5QbGVhc2UgcXVvdGUgdGhlIHRleHQsIDIuMiBzaW1wbHkgc2hvd3MgaG93 IHRvIGNvbnN0cnVjdCBhIFNFVCB0b2tlbiBiYXNlZCBvbiBsYW5ndWFnZSBmcm9tIDc1MTkuPGJy Pg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHVsIHR5cGU9ImRpc2Mi Pg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDowaW47bGluZS1oZWlnaHQ6MjAu MjVwdDttc28tbGlzdDpsMjUgbGV2ZWwxIGxmbzE1Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LHNhbnMtc2VyaWYiPjIuMjog dGhpcyBzZWN0aW9uIGlzIGNvbmZ1c2luZy4gV2UgZmlyc3Qgc2F5IHRoYXQgdGhlIEpXVCBtdXN0 IGJlIGVuY3J5cHRlZC48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hlcmUgZG9lcyBpdCBzYXkg dGhpcz88YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8dWwgdHlw ZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjBpbjtsaW5lLWhl aWdodDoyMC4yNXB0O21zby1saXN0OmwyIGxldmVsMSBsZm8xNiI+DQo8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90OyxzYW5zLXNlcmlm Ij5CdXQgdGhlbiBpbnN0ZWFkLCB3ZSBzaWduIGl0LCBhbmQgd2UgJnF1b3Q7c2lnbiZxdW90OyB3 aXRoIGEgbnVsbCBhbGdvcml0aG0uIFdoeT88bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MGluO2xpbmUtaGVpZ2h0OjIwLjI1cHQ7bXNvLWxp c3Q6bDIgbGV2ZWwxIGxmbzE2O2JveC1zaXppbmc6IGJvcmRlci1ib3g7Y3Vyc29yOmRlZmF1bHQi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2Ug VUkmcXVvdDssc2Fucy1zZXJpZiI+U2lnbmVkIFNFVHMgTVVTVCAobm90IE1BWSkgYmUgdmFsaWRh dGVkIGJ5IHRoZSBzdWJzY3JpYmVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC91bD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5zcGVjaWZpYyB0 ZXh0IHBsZWFzZT88YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8 dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjBpbjts aW5lLWhlaWdodDoyMC4yNXB0O21zby1saXN0Omw4IGxldmVsMSBsZm8xNyI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90OyxzYW5z LXNlcmlmIj5BbHNvLCBJIHRoaW5rIHdlIHNob3VsZCByZW1vdmUgdGhlIHByZWNvbmRpdGlvbnMg YW5kIGFsd2F5cyByZXF1aXJlIHNpZ25pbmcsIGFzIGEgTVVTVC4gQW4gb3B0aW9uYWwgc2lnbmF0 dXJlIGlzIGFjdHVhbGx5IGEgc2VjdXJpdHkgbG9vcGhvbGUgYmVjYXVzZSBhbiBhdHRhY2tlciBj YW4gcmVtb3ZlIHRoZSBzaWduYXR1cmUsIGFuZA0KIHRoZSBzdWJzY3JpYmVyIGRvZXNuJ3Qga25v dyB0aGF0IGl0J3MgbWlzc2luZy48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hpY2ggdGV4dCBh cmUgeW91IHJlZmVycmluZyB0by48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+U2lnbmF0dXJlcyBhcmVu4oCZdCBhbHdheXMgbmVjZXNzYXJ5IGlm IHRoZSBtZXRob2QgZm9yIGRlbGl2ZXJ5IGl0c2VsZiBhdXRoZW50aWNhdGVzIHRoZSBwdWJsaXNo ZXIgZGVsaXZlcmluZyB0aGUgSFRUUCBQT1NUIHJlcXVlc3QgYW5kIGl0IGlzIHNlY3VyZWQgYnkg VExTLiZuYnNwOzxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjx1 bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MGluO2xp bmUtaGVpZ2h0OjIwLjI1cHQ7bXNvLWxpc3Q6bDkgbGV2ZWwxIGxmbzE4Ij4NCjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LHNhbnMt c2VyaWYiPjMuMjogJnF1b3Q7dGhhdCBhbG9uZSB3aWxsIG5vdCBndWFyYW50ZWUgdGhhdCB0aGUg Y29ycmVjdCBzdWJzY3JpYmluZyBwYXJ0eSBrbm93cyB0aGV5IHNob3VsZCBoYXZlIHJlY2VpdmVk IGEgcGFydGljdWxhciBTRVQuJnF1b3Q7IFRoZSB0ZXh0IGlzIHVuY2xlYXIgdG8gbWUuIERvIHdl IG1lYW46ICZxdW90O3RoYXQgYWxvbmUgZG9lcyBub3QgZ3VhcmFudGVlDQogdGhhdCBhIHBhcnRp Y3VsYXIgU0VUIHdhcyBkZWxpdmVyZWQgdG8gdGhlIGNvcnJlY3Qgc3Vic2NyaWJpbmcgcGFydHni gJ0/PG86cD48L286cD48L3NwYW4+PC9saT48L3VsPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkp1c3QgYmVjYXVzZSBhbiBlbmRwb2ludCByZXR1 cm5zIHN1Y2Nlc3MgYWZ0ZXIgYSBQT1NUIGRvZXMgbm90IGJ5IGl0c2VsZiBndWFyYW50ZWUgaXQg d2FzIGFibGUgdG8gZGVjcnlwdCBvciBwYXJzZSB0aGUgbWVzc2FnZS4gTm9yIGRvZXMgaXQgcHJv dmUgJm5ic3A7dGhlIHN1YnNjcmliZXIgaGVsZCB0aGUgcHJpdmF0ZSBrZXkgdG8gZGVjcnlwdCB0 aGUgSldFLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5XZSBjb3ZlciB0aGlzIHNvbWV3aGF0IGluIHRoZSBkaXN0cmlidXRpb24gZHJhZnQgd2hl biB3ZSB0YWxrIGFib3V0IHZlcmlmaWNhdGlvbiBtZXNzYWdlcyB3aGljaCByZXF1aXJlIHRoZSBy ZWNlaXZlciB0byBwYXJzZSB0aGUgbWVzc2FnZSBhbmQgcmV0dXJuIGNvbnRlbnQgYmFjayBwcm92 aW5nIHBvc3Nlc3Npb24uPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2 Pg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDow aW47bGluZS1oZWlnaHQ6MjAuMjVwdDttc28tbGlzdDpsNiBsZXZlbDEgbGZvMTkiPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDss c2Fucy1zZXJpZiI+V2UgbWF5IHdhbnQgYSBzZXBhcmF0ZSBJbXBsZW1lbnRhdGlvbiBDb25zaWRl cmF0aW9ucyBzZWN0aW9uLCBhbmQgbW92ZSAmcXVvdDtkZWxpdmVyeSZxdW90OywgJnF1b3Q7c2Vx dWVuY2luZyZxdW90OyBhbmQgJnF1b3Q7dGltaW5nJnF1b3Q7IGludG8gaXQuIFllcyB0aGV5IGFy ZSBzZWN1cml0eS1yZWxldmFudCwganVzdCBsaWtlIGFueXRoaW5nIGVsc2UgaW4gdGhpcyBkb2N1 bWVudCwNCiBidXQgdGhleSB3b3VsZCBhcHBseSBqdXN0IGFzIHdlbGwgdG8gYW55IGV2ZW50IHN0 cmVhbSBwcm90b2NvbC48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2VlbXMgcmVhc29uYWJsZS48 YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8dWwgdHlwZT0iZGlz YyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjBpbjtsaW5lLWhlaWdodDoy MC4yNXB0O21zby1saXN0OmwxMCBsZXZlbDEgbGZvMjAiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssc2Fucy1zZXJpZiI+My4z OiB0aGlzIGlzIHRoZSBmaXJzdCB0aW1lIHdlIG1lbnRpb24gcHJvdmlzaW9uaW5nLiBEbyB3ZSBy ZWFsbHkgaW50ZW5kIFNFVHMgdG8gYmUgdXNlZCBmb3IgdGhhdD88bzpwPjwvbzpwPjwvc3Bhbj48 L2xpPjwvdWw+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+WWVzLiBTb21lIG9mIHVzIGRvIC0gdGhpcyB3b3JrIGFjdHVhbGx5IGJlZ2FuIHdpdGhp biB0aGUgU0NJTSBXRy4gJm5ic3A7UHJvdmlzaW9uaW5nIHdhcyBwcm92aWRlZCBhcyBhbiBleGFt cGxlIG9mIGEgdHlwZSBvZiBldmVudCB3aGVyZSBvcmRlcmluZyB3b3VsZCBiZSBjcnVjaWFsLjxi cj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjx1bCB0eXBlPSJkaXNj Ij4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MGluO2xpbmUtaGVpZ2h0OjIw LjI1cHQ7bXNvLWxpc3Q6bDEzIGxldmVsMSBsZm8yMSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90OyxzYW5zLXNlcmlmIj4zLjM6 IElTVE0gdGhhdCB3ZSBzaG91bGQgZGVmaW5lIGEgc2VxdWVuY2luZyBtZWNoYW5pc20sIHJhdGhl ciB0aGFuIGxlYXZlIGl0IG9wZW4gdG8gcHJvZmlsZXMuIEUuZy4sIHJlcXVpcmUgYSBzZXF1ZW5j ZSBudW1iZXIgd2hlbmV2ZXIgJnF1b3Q7dHhuJnF1b3Q7IGlzIHVzZWQuPG86cD48L286cD48L3Nw YW4+PC9saT48L3VsPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPnR4biBpcyBhIHNlcGFyYXRlIGNvbmNlcHQuIHR4biBpcyB0aGVyZSB3aGVuIHB1 Ymxpc2hlcnMgZGVjaWRlIHRvIGlzc3VlIG11bHRpcGxlIGV2ZW50cyBhZ2FpbnN0IHRoZSBzYW1l IG9yaWdpbmF0aW5nIGV2ZW50LiAmbmJzcDtGb3IgZXhhbXBsZSwgb25lIHN1YnNjcmliZXIgbWln aHQgdW5kZXJzdGFuZCBzdXNwaWNpb3VzIGFjdGl2aXR5IHdoaWxlIGFub3RoZXIgbWlnaHQgb25s eSB1bmRlcnN0YW5kIGxvZ291dC4gU29tZQ0KIGhhdmUgcmVxdWVzdGVkIGFuIGF0dHJpYnV0ZSB0 aGF0IGxldHMgdGhlIHB1Ymxpc2hlciB0cmFjayB0aGF0IHRoZSBkaWZmZXJlbnQgZXZlbnRzIGFj dHVhbGx5IHN0ZW0gZnJvbSB0aGUgc2FtZSBvcmlnaW5hbCBldmVudC4gJm5ic3A7Rm9yIGV4YW1w bGUgd2hlbiBhIHB1Ymxpc2hlcnMgb3BlcmF0aW9ucyBjZW50ZXIgZ2V0cyBhIGNhbGwgdG8gdHJh Y2UgYSBzZXJpZXMgb2YgZXZlbnRzLiZuYnNwOzxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPGRpdj4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bWFyZ2luLWxlZnQ6MGluO2xpbmUtaGVpZ2h0OjIwLjI1cHQ7bXNvLWxpc3Q6bDI0IGxldmVsMSBs Zm8yMiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtT ZWdvZSBVSSZxdW90OyxzYW5zLXNlcmlmIj4zLjQ6IEFsc28sIG91ciB0aW1lc3RhbXBzIG9ubHkg aGF2ZSAxIHNlY29uZCBncmFudWxhcml0eSwgYW5kIHNvIGFyZSB0b28gY29hcnNlIGZvciBzZXNz aW9uIHN0YXRlIChjb25zaWRlciBhdXRvbWF0ZWQgbG9naW5zL2xvZ291dHMpLjxvOnA+PC9vOnA+ PC9zcGFuPjwvbGk+PC91bD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5UaGUgcG9pbnQgaGVyZSBpcyB0byBhZGRyZXNzIGV2ZW50IGRlc2lnbiBp c3N1ZXMgd2hlcmUgcmVseWluZyBvbiB0aW1lc3RhbXAgdG8gb3JkZXIgZXZlbnRzIGlzIHByb2Js ZW1hdGljLiBGb3IgZXhhbXBsZSBpZiB5b3Ugc2lnbmFsIGxvZ291dCBvbmx5IGJ5IHN1YmplY3Qg aWRlbnRpZmllciB0aGVuIGl0IGJlY29tZXMgaGFyZCB0byB0ZWxsIGlmIGEgdXNlciBpcyBsb2dn aW5nIGJhY2sgaW4gb3Igbm90LiBJdA0KIGlzIGJldHRlciB0byBjYW5jZWwgYSBzZXNzaW9uIGFz c29jaWF0ZWQgd2l0aCBhIHN1YmplY3Qgc28gdGhhdCB0aGUgbmV3IHNlc3Npb24gY2FuIHN0aWxs IGJlIGVzdGFibGlzaGVkLjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRp dj4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6 MGluO2xpbmUtaGVpZ2h0OjIwLjI1cHQ7bXNvLWxpc3Q6bDE1IGxldmVsMSBsZm8yMyI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90 OyxzYW5zLXNlcmlmIj4zLjU6IFdoeSBkb24ndCB3ZSBoYXZlIGFuIHVuYW1iaWd1b3VzIHdheSB0 byBkaXN0aW5ndWlzaCBTRVRzIGZyb20gYWNjZXNzIHRva2Vucywgd2h5IGxlYXZlIGl0IHRvIGlt cGxlbWVudGVycz8gU291bmRzIGxpa2UgYSBtYWpvciBzZWN1cml0eSBpc3N1ZSBpbiB0aGUgbWFr aW5nLiBXZSBzaG91bGQgY29uc2lkZXIgaGVyZSBBTEwgaW1wbGVtZW50YXRpb25zDQogdGhhdCBh Y2NlcHQgYWNjZXNzIHRva2VucywgaW5jbHVkaW5nIGxlZ2FjeSBpbXBsZW1lbnRhdGlvbnMgdGhh dCBjYW5ub3QgYmUgbW9kaWZpZWQuPG86cD48L286cD48L3NwYW4+PC9saT48L3VsPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYWdyZWUuIFRo ZSByZWFsIGlzc3VlIGlzIHRoYXQgSldU4oCZcyBzaG91bGQgaGF2ZSBoYWQgYSB0eXBlIHRvIGJl Z2luIHdpdGguIE9uZSBvZiB0aGUgdGhyZWFkcyBpcyBoZXJlOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9pZC1ldmVudC9jdXJyZW50L21zZzAwMTIwLmh0bWwiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvaWQtZXZlbnQvY3VycmVudC9tc2cw MDEyMC5odG1sPC9hPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4N Cjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MGlu O2xpbmUtaGVpZ2h0OjIwLjI1cHQ7bXNvLWxpc3Q6bDQgbGV2ZWwxIGxmbzI0Ij4NCjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LHNh bnMtc2VyaWYiPjQ6IFRoZSBhdWRpdCBoYXBwZW5zIG9uIHRoZSBzdWJzY3JpYmVyIHNpZGUuIEJ5 IHRoZW4gaXQgaXMgdG9vIGxhdGUgdG8gcmVxdWlyZSBKV1MgdG8gYmUgdXNlZCBieSB0aGUgcHVi bGlzaGVyLiBBcyBtZW50aW9uZWQsIEkgcHJvcG9zZSB0aGF0IEpXUyBzaG91bGQgQUxXQVlTIGJl IHJlcXVpcmVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC91bD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGlzIHNvbWV0aGluZyB0aGF0 IHB1Ymxpc2hlciBhbmQgc3Vic2NyaWJlciBoYXZlIHRvIG5lZ290aWF0ZS4gVGhpcyBpcyBhbnRp Y2lwYXRlZCBpbiB0aGUgZGlzdHJpYnV0aW9uIHNwZWMgdG8gc29tZSBkZWdyZWUuIFRob3VnaCBJ TU8sIHRoZXJlIGlzIG5vdCBhIGxvdCBvZiBjb25zZW5zdXMgb24gdGhpcyB5ZXQuPGJyPg0KPGJy Pg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxp IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDowaW47bGluZS1oZWlnaHQ6MjAuMjVwdDtt c28tbGlzdDpsNSBsZXZlbDEgbGZvMjUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssc2Fucy1zZXJpZiI+NDogJnF1b3Q7V2hl biBzaGFyaW5nIHBlcnNvbmFsbHkgaWRlbnRpZmlhYmxlIGluZm9ybWF0aW9uJnF1b3Q7IC0gd2Ug c2hvdWxkIHJlbW92ZSB0aGlzIGNvbmRpdGlvbi4gSSBkb24ndCBzZWUgYSBjYXNlIHdoZXJlIHRo ZSBpbmZvcm1hdGlvbiBzaGFyZWQgaXMgTk9UIFBJSSwgYW5kIHRoZXJlZm9yZSBsZWdhbCBhZ3Jl ZW1lbnRzIGFib3V0IGluZm9ybWF0aW9uDQogc2hhcmluZyBhbmQgdXNlciBjb25zZW50IG11c3Qg YWx3YXlzIGJlIGluIHBsYWNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC91bD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ib3cgYWJvdXQgY2Fu Y2VsbGF0aW9uIG9mIGEgdG9rZW4gb3IgYSBzZXNzaW9uPyAmbmJzcDtJZiBqdXN0IHBhc3Npbmcg YSDigJxqdGnigJ0gdmFsdWUsIHRoZXJlIGlzIGFyZ3VhYmx5IG5vIFBJSS4gJm5ic3A7VGhlIEpU SSBtaWdodCBiZSB0cmFjZWFibGUsIGJ1dCB0aGUgcmVseWluZyBwYXJ0eSB3b3VsZCBoYXZlIHRv IGtub3cgYWJvdXQgaXQgdG8gaW5mZXIgbWVhbmluZy4gJm5ic3A7QWxzbywgdG9rZW5zL3Nlc3Np b25zIHNob3VsZCBuZXZlcg0KIGJlIHBlcm1hbmVudC4gJm5ic3A7SSBhbSBub3QgYSBsYXd5ZXIs IGJ1dCBJIGRvdWJ0IHRoZXNlIGV4YW1wbGVzIHdvdWxkIGFjdHVhbGx5IGJlIFBJSS48YnI+DQo8 YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8dWwgdHlwZT0iZGlzYyI+DQo8 bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjBpbjtsaW5lLWhlaWdodDoyMC4yNXB0 O21zby1saXN0OmwxNyBsZXZlbDEgbGZvMjYiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssc2Fucy1zZXJpZiI+NDogSSBkb24n dCB0aGluayB0aGUgc3ViamVjdCBpbmZvcm1hdGlvbiBpcyAmcXVvdDtwZXJjZWl2ZWQmcXVvdDsg YXMgUElJLiBJdCBpcyBQSUksIG90aGVyd2lzZSBpdCB3b3VsZCBiZSB1c2VsZXNzIHRvIHRoZSBz dWJzY3JpYmVyLCBiZWNhdXNlIHRoZSBzdWJzY3JpYmVyIHdvdWxkIG5vdCBiZSBhYmxlIHRvIGlk ZW50aWZ5IHRoZSBzdWJqZWN0LiBBbHNvLA0KIGV2ZW4gaWYgdGhlIGluZm9ybWF0aW9uIG9uIHRo ZSB3aXJlIGlzIG5vdCBpbiBpdHNlbGYgUElJLCBlLmcuIHdoZW4gdXNpbmcgYSBoYXNoLCB0aGUg ZmFjdCB0aGF0IGEgcHVibGlzaGVyIHNoYXJlcyBpbmZvcm1hdGlvbiB0aGF0IGEgcGFydGljdWxh ciB1c2VyIGlzIGFsc28gYSB1c2VyIG9uIGl0cyBzeXN0ZW0gYW5kIGlzIHVuZGVyZ29pbmcgY2Vy dGFpbiBzdGF0ZSBjaGFuZ2VzIGlzIHByaXZhY3ktc2Vuc2l0aXZlLjxvOnA+PC9vOnA+PC9zcGFu PjwvbGk+PC91bD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5BZ2FpbiwgdGhlIHN1YmplY3Qgb2YgYW4gZXZlbnQgbWlnaHQgYmUgYWJvdXQgYSBz ZXNzaW9uIG9yIGEgdG9rZW4sIGRldmljZSwgZXRjLjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9w Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPGRpdj4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87bWFyZ2luLWxlZnQ6MGluO2xpbmUtaGVpZ2h0OjIwLjI1cHQ7bXNvLWxpc3Q6bDE0IGxldmVs MSBsZm8yNyI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVv dDtTZWdvZSBVSSZxdW90OyxzYW5zLXNlcmlmIj5JIHN1Z2dlc3QgdG8gYWRkIGFuIEltcGxlbWVu dGF0aW9uIFN0YXR1cyBzZWN0aW9uLCBwZXIgUkZDIDc5NDIuPG86cD48L286cD48L3NwYW4+PC9s aT48L3VsPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkl0IHdvdWxkIGJlIGhlbHBmdWwgZm9yIHRoZSBjaGFpcnMgdG8gcHJvdmlkZSBndWlkYW5j ZSBvbiB0aGlzLiAmbmJzcDs8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFlhcm9uPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KSWQtZXZlbnQgbWFpbGluZyBsaXN0PGJyPg0KPGEg aHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYub3JnIj5JZC1ldmVudEBpZXRmLm9yZzwvYT48YnI+ DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50 Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50PC9hPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_BN3PR03MB235507D80D7BC915FA6775A4F59A0BN3PR03MB2355namp_-- From nobody Sun Dec 18 13:32:16 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C892129406 for ; Sun, 18 Dec 2016 13:32:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZyaBxL7iwT4 for ; Sun, 18 Dec 2016 13:32:13 -0800 (PST) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EACA91293DF for ; Sun, 18 Dec 2016 13:32:12 -0800 (PST) Received: by mail-wm0-x22c.google.com with SMTP id a197so78698622wmd.0 for ; Sun, 18 Dec 2016 13:32:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=wC856/tSxJhl/ySDVrwcd5veqN2KPae1eCo4eVrz9so=; b=k1lV+/jJd+2msE7ubQLjhfoSdUOa49KMm1ZzV8j+DQWRu1cpRZBn5EWRS3G8Ub75sD E0jz7tiTCvp6zF7FPeVrLpvhOUS53Js7DlQOuMsjRvbtFXCVLdmD/UelnCV4A/cnga+O lbCPJxQ5kOZoavJGVnijloJM2yKJa1eewwbJjeSuKXDspmUS1sfbQ3w/s7qkYm+uzvpU U00VYMq7cyFg6bJQLFifGLWcT/mUiRO2z3nmnpAkxL9P6OtxIMl4DdW7GWJGvozG3eQ3 m3jtxDWCi/iXobOqvpaYpGGsD3ULcnOR12Bd5Lz0U32UajJgKSW/6g33cyJBWgMcYKcY Jvnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=wC856/tSxJhl/ySDVrwcd5veqN2KPae1eCo4eVrz9so=; b=bLgamVzVmWd3Dk80sjCYDwAOfrimtV2yIujnfu2XKkU1ocKrmjuOCajitrgHnzcH1s zVbDPkuw0qK0P492JO0/qUW+78iECZvE8HJpd8y4CINSgSgtpL7FyxnQrexq7hoi/mzp izj0pQsNaltktBRKu1djUbR85UhcEVTkPG3YBaPxn5Vb+RJfokny4BQk4rSzXcenQTi1 OC8AIbdh61I0aoSm9Jg9Q4WZdwEyuZdvb7AbFZkQklOgbDB/30m+D1EvazsKi4X6Q28A xzd2+J50JIwQ+10xqZzgac4NOEKAg7omQSP+inj7NlIyhqpQhb0hW0vmVVF2R0qQVTf5 J6Ig== X-Gm-Message-State: AIkVDXJmStS3yGWDOdXIHEtEl4dr16fTM9Wlwkb0cX4/giplxl/v6lgNARt+oaoLu7c01g== X-Received: by 10.28.113.76 with SMTP id m73mr10194156wmc.114.1482096730894; Sun, 18 Dec 2016 13:32:10 -0800 (PST) Received: from [10.0.0.11] (bzq-79-177-83-171.red.bezeqint.net. [79.177.83.171]) by smtp.gmail.com with ESMTPSA id i2sm17653051wjx.44.2016.12.18.13.32.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Dec 2016 13:32:10 -0800 (PST) To: Phil Hunt References: <9114f681-cba9-b6d3-8369-ccd9193ce1b8@gmail.com> From: Yaron Sheffer Message-ID: Date: Sun, 18 Dec 2016 23:32:08 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: SecEvent Subject: Re: [Id-event] Some comments to draft-hunt-idevent-token-07 X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2016 21:32:15 -0000 Hi Phil, Thank you for your detailed comments, they are very helpful as I ramp up my understanding of this area. Please see some responses inline. Thanks, Yaron On 14/12/16 22:18, Phil Hunt wrote: > Yaron, > > Thanks for your comments. My responses inline. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > >> On Dec 10, 2016, at 1:27 PM, Yaron Sheffer > > wrote: >> >> Hi, I finally read the draft in detail, and I do have a few comments. >> >> My main suggestion is to tighten the specification of an Event, by >> defining more strictly the difference between "event" and "event >> extension" and tweaking the JSON structure a bit. >> >> > The spec has undergone some restructuring recently, and it may need some > more tightening up. The informal consensus from the id-events list is > that there should be only one event. However, in order to allow some > deployers to provide additional information, and extension methodology > was included. An example is given. >> >> In addition, I think we should require the claim to be signed, since >> it will be used for security-sensitive activities across complex >> distributed systems. >> >> * 1: Why is signing optional? The publisher doesn't know how the >> subscriber's system is architected, and might well want end-to-end >> authentication of the claim. This is also important for auditing. > I think the key word in your question is “might”. Also, its not the > publisher that needs authentication of the statement its really the > subscriber. > > Many have preferred to have a minimum option where security is > essentially point-to-point depending primarily on TLS. There are other > cases where end-to-end key based is preferred especially when > transmitting over less secure transport. > > Remember that this specification is a coming together of a bunch of > initiatives around a common format. It is difficult to assign mandatory > requirements unless there is strong consensus to do so. > >> * 1: "example events" - is specification of individual events (maybe >> only a few basic ones) within scope of our charter? Otherwise we >> cannot guarantee interop. > The intention is to define a base level format that other working groups > and SDOs will use to define their own events. The primary benefit is to > have a common format. > > I had originally envisioned an event registry, but the early discussions > were to avoid IANA registration. We then switched to using URI’s for > events. > > The informal consensus was that what matters is that publisher and > subscriber agree on meaning and that it is ok for events to be highly > specific. I still need to wrap my mind around a spec (and a working group) where the end result is not interoperable implementations. >> >> * 1.2: principle -> principal > Noted >> >> * 2: "first value" is meaningless. JSON objects are unordered (4th >> paragraph of RFC 7159). If order /is/ important, we could make >> "events" into an array. > Yup. How would the group like to fix this? We could make “events” > singular and have an extensions attribute to hold the extensions. Or we > could go to a more complex JSON structure (not personally a fan). I'm personally fine with a main "event" object and an "extensions" attribute. I can even live with "event" being called "events", per Mike's proposal. But the structure needs to make sense as a JSON object if we want it implemented. >> >> * 2: event extensions are not defined but only introduced by the >> text after they are described. Also, in the example there's this >> URL: https:// >> ​example.​com/​scim/​event/​pas​swor​dRes​etEx​t - I believe it >> needs to be part of the passwordReset object and not parallel to it. > I will check for clarity. The password example is intended to > demonstrate an example where a publisher wishes to provide additional > context such as the number of resets performed. Note in defining a > password reset event it might indeed make sense to combine that info. My > intent was to show an extension. Maybe there is a better hypothetical > example? >> >> * Why "events" and not "event"? We don't really have support for >> multiple events. Certainly not if they are all of the same type. >> The current text is confusing: "events" is not the same as "a >> primary event and its extensions”. > Reflects your earlier comment re: primary vs. extensions. "events” is > plural to reflect the fact that the attribute is multi-valued. I agree, > given that only one primary event can be included, the naming is misleading. >> >> * "In the above example "iss" and "sub" contained within the claim" >> - this is incorrect, probably leftover from an earlier version. > NO. In the example, “iss” and “sub” indicate the subject is from a > different issuer of the event. For example a relying party web site > wants to tell the identity provider (the original subject issuer) that > the user has requested a logout. I'm still confused by the text. The paragraph talks about iss and sub contained within the claim, and contrasted with "the top level value of iss", which I'm unable to locate. >> >> * "aud" MAY be a URI: shouldn't it be an array, maybe an array that >> contains a single URI? > This is defined by the JWT spec. I am talking about the syntax. "aud" is an array of URIs, not a URI. >> >> * Why do we use the terms "single-valued" vs. "multiple-valued" >> strings? Why not use the normal JSON terminology, "string" vs. >> "array of strings”? > Habit from the world of IDM. We could align it. We should. >> >> * Why is "sub" optional? Do we have any good examples of events >> where this value is not required? > You might have an event about a session, or an IP address, or some other > thing. > > There was an email discussion in the past about whether sub should be a > security subject (e.g. as defined by SAML or OpenID Connect), or whether > sub is just the subject of the event and thus can be anything. > > I expect to see more discussion on this. I'm confused. If the subject is an IP address or session identifier, it still doesn't make it into an optional value. >> >> * "a future date" - we should clarify that there may be cases when >> nbf is smaller than iat, i.e. when it takes some time until the >> SET is issued. > Assume you are referring to “nbf”. The definition comes from JWT. The clarification is still needed, if the JWT definition is imprecise. >> >> * "exp" - is it also a NumericDate? Please specify. > Defined by JWT, RFC7519 If we repeat all other JWT definitions, we should repeat this one too, for consistency. >> >> * In the medical example, it is strange that the event is named by a >> URL that points to an HTML page. I would expect a more stable URI. > It is an example. Many have indicated that they want the event should be > a URL to the page that defines the event. I would prefer our examples to be what we think are best practices. And personally I don't think this is one. What if the next version of the web site's code changes "consent.html" into "consent.jsp"? > >> * 2.2: is encryption a MUST whenever there are attributes specified? >> If so, we should have a normative section saying so, not just >> mention it in the context of an example. Besides, we have not >> defined what attributes are. > Please quote the text, 2.2 simply shows how to construct a SET token > based on language from 7519. Quoting: "In this example, because the event contains attribute values, the token MUST be encrypted per JWE (see [RFC7516]) before transmission." >> >> * 2.2: this section is confusing. We first say that the JWT must be >> encrypted. > Where does it say this? See above. >> >> * But then instead, we sign it, and we "sign" with a null algorithm. >> Why? >> * Signed SETs MUST (not MAY) be validated by the subscriber. > specific text please? Quote: "so that individual events MAY be authenticated and validated by the subscriber." >> >> * Also, I think we should remove the preconditions and always >> require signing, as a MUST. An optional signature is actually a >> security loophole because an attacker can remove the signature, >> and the subscriber doesn't know that it's missing. > Which text are you referring to. > > Signatures aren’t always necessary if the method for delivery itself > authenticates the publisher delivering the HTTP POST request and it is > secured by TLS. >> >> * 3.2: "that alone will not guarantee that the correct subscribing >> party knows they should have received a particular SET." The text >> is unclear to me. Do we mean: "that alone does not guarantee that >> a particular SET was delivered to the correct subscribing party”? > Just because an endpoint returns success after a POST does not by itself > guarantee it was able to decrypt or parse the message. Nor does it prove > the subscriber held the private key to decrypt the JWE. Absolutely. And your text here is much clearer than the sentence I quote above, "that alone does not guarantee...". > > We cover this somewhat in the distribution draft when we talk about > verification messages which require the receiver to parse the message > and return content back proving possession. >> >> * We may want a separate Implementation Considerations section, and >> move "delivery", "sequencing" and "timing" into it. Yes they are >> security-relevant, just like anything else in this document, but >> they would apply just as well to any event stream protocol. > Seems reasonable. >> >> * 3.3: this is the first time we mention provisioning. Do we really >> intend SETs to be used for that? > Yes. Some of us do - this work actually began within the SCIM WG. > Provisioning was provided as an example of a type of event where > ordering would be crucial. >> >> * 3.3: ISTM that we should define a sequencing mechanism, rather >> than leave it open to profiles. E.g., require a sequence number >> whenever "txn" is used. > txn is a separate concept. txn is there when publishers decide to issue > multiple events against the same originating event. For example, one > subscriber might understand suspicious activity while another might only > understand logout. Some have requested an attribute that lets the > publisher track that the different events actually stem from the same > original event. For example when a publishers operations center gets a > call to trace a series of events. >> >> * 3.4: Also, our timestamps only have 1 second granularity, and so >> are too coarse for session state (consider automated logins/logouts). > The point here is to address event design issues where relying on > timestamp to order events is problematic. For example if you signal > logout only by subject identifier then it becomes hard to tell if a user > is logging back in or not. It is better to cancel a session associated > with a subject so that the new session can still be established. >> >> * 3.5: Why don't we have an unambiguous way to distinguish SETs from >> access tokens, why leave it to implementers? Sounds like a major >> security issue in the making. We should consider here ALL >> implementations that accept access tokens, including legacy >> implementations that cannot be modified. > I agree. The real issue is that JWT’s should have had a type to begin > with. One of the threads is here: > https://www.ietf.org/mail-archive/web/id-event/current/msg00120.html Yep. I would like to reopen this discussion post-adoption. >> >> * 4: The audit happens on the subscriber side. By then it is too >> late to require JWS to be used by the publisher. As mentioned, I >> propose that JWS should ALWAYS be required. > This is something that publisher and subscriber have to negotiate. This > is anticipated in the distribution spec to some degree. Though IMO, > there is not a lot of consensus on this yet. >> >> * 4: "When sharing personally identifiable information" - we should >> remove this condition. I don't see a case where the information >> shared is NOT PII, and therefore legal agreements about >> information sharing and user consent must always be in place. > How about cancellation of a token or a session? If just passing a “jti” > value, there is arguably no PII. The JTI might be traceable, but the > relying party would have to know about it to infer meaning. Also, > tokens/sessions should never be permanent. I am not a lawyer, but I > doubt these examples would actually be PII. >> >> * 4: I don't think the subject information is "perceived" as PII. It >> is PII, otherwise it would be useless to the subscriber, because >> the subscriber would not be able to identify the subject. Also, >> even if the information on the wire is not in itself PII, e.g. >> when using a hash, the fact that a publisher shares information >> that a particular user is also a user on its system and is >> undergoing certain state changes is privacy-sensitive. > Again, the subject of an event might be about a session or a token, > device, etc. >> >> * I suggest to add an Implementation Status section, per RFC 7942. > It would be helpful for the chairs to provide guidance on this. I am an author on 7942, so I will only recommend it as an individual: I think it will be helpful to WG members when evaluating the draft. We can probably delay it to just before WGLC though. >> >> Thanks, >> >> Yaron >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event > From nobody Wed Dec 21 13:20:47 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 098A3129A11 for ; Wed, 21 Dec 2016 13:20:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.301 X-Spam-Level: X-Spam-Status: No, score=-7.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A8BxtQpCYwIk for ; Wed, 21 Dec 2016 13:20:41 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 4A2E2129A0D for ; Wed, 21 Dec 2016 13:20:41 -0800 (PST) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id uBLLKdgf005832 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 21 Dec 2016 21:20:39 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id uBLLKcn1027719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Dec 2016 21:20:38 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id uBLLKa9d003050; Wed, 21 Dec 2016 21:20:37 GMT Received: from [192.168.1.26] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 21 Dec 2016 13:20:35 -0800 Content-Type: multipart/alternative; boundary="Apple-Mail=_549E3578-A46C-4E6A-B4CF-8EA100D79063" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Phil Hunt In-Reply-To: Date: Wed, 21 Dec 2016 13:20:34 -0800 Message-Id: <3097AC43-4652-40DB-8120-F25D68E1F0A8@oracle.com> References: <9114f681-cba9-b6d3-8369-ccd9193ce1b8@gmail.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.3124) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: SecEvent Subject: Re: [Id-event] Some comments to draft-hunt-idevent-token-07 X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2016 21:20:46 -0000 --Apple-Mail=_549E3578-A46C-4E6A-B4CF-8EA100D79063 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yaron, Thanks for your comments. Its always good to get broader review. My = responses inline. I have marked some sections as =E2=80=9CThread: =E2=80=A6=E2=80=9D which = is an invitation to open a new email thread to keep the discussion = going. Phil @independentid www.independentid.com = phil.hunt@oracle.com = > On Dec 18, 2016, at 1:32 PM, Yaron Sheffer = wrote: >=20 > Hi Phil, >=20 > Thank you for your detailed comments, they are very helpful as I ramp = up my understanding of this area. Please see some responses inline. >=20 > Thanks, > Yaron >=20 > On 14/12/16 22:18, Phil Hunt wrote: >> Yaron, >>=20 >> Thanks for your comments. My responses inline. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com = > >> phil.hunt@oracle.com = > >>=20 >>=20 >>=20 >>=20 >>=20 >>> On Dec 10, 2016, at 1:27 PM, Yaron Sheffer >>> >> = wrote: >>>=20 >>> Hi, I finally read the draft in detail, and I do have a few = comments. >>>=20 >>> My main suggestion is to tighten the specification of an Event, by >>> defining more strictly the difference between "event" and "event >>> extension" and tweaking the JSON structure a bit. >>>=20 >>>=20 >> The spec has undergone some restructuring recently, and it may need = some >> more tightening up. The informal consensus from the id-events list is >> that there should be only one event. However, in order to allow some >> deployers to provide additional information, and extension = methodology >> was included. An example is given. >>>=20 >>> In addition, I think we should require the claim to be signed, since >>> it will be used for security-sensitive activities across complex >>> distributed systems. >>>=20 >>> * 1: Why is signing optional? The publisher doesn't know how the >>> subscriber's system is architected, and might well want = end-to-end >>> authentication of the claim. This is also important for auditing. >> I think the key word in your question is =E2=80=9Cmight=E2=80=9D. = Also, its not the >> publisher that needs authentication of the statement its really the >> subscriber. >>=20 >> Many have preferred to have a minimum option where security is >> essentially point-to-point depending primarily on TLS. There are = other >> cases where end-to-end key based is preferred especially when >> transmitting over less secure transport. >>=20 >> Remember that this specification is a coming together of a bunch of >> initiatives around a common format. It is difficult to assign = mandatory >> requirements unless there is strong consensus to do so. >>=20 >>> * 1: "example events" - is specification of individual events = (maybe >>> only a few basic ones) within scope of our charter? Otherwise we >>> cannot guarantee interop. >> The intention is to define a base level format that other working = groups >> and SDOs will use to define their own events. The primary benefit is = to >> have a common format. >>=20 >> I had originally envisioned an event registry, but the early = discussions >> were to avoid IANA registration. We then switched to using URI=E2=80=99= s for >> events. >>=20 >> The informal consensus was that what matters is that publisher and >> subscriber agree on meaning and that it is ok for events to be highly >> specific. >=20 > I still need to wrap my mind around a spec (and a working group) where = the end result is not interoperable implementations. [PH] I think you may be confusing protocol and message format with = content. The goal of this specification is to provide a common event = format that can be easily exchanged. Other WGs and SDOs are planning to = use this common format to define their own specific events. E.g. = http://openid.net/specs/openid-connect-backchannel-1_0.html So what we are looking for is a way for libraries to be developed that = are extensions of current JWT libraries.=20 Ideally this is small incremental profile of JWT that adds key = clarifications, security and privacy considerations. >=20 >>>=20 >>> * 1.2: principle -> principal >> Noted >>>=20 >>> * 2: "first value" is meaningless. JSON objects are unordered (4th >>> paragraph of RFC 7159). If order /is/ important, we could make >>> "events" into an array. >> Yup. How would the group like to fix this? We could make = =E2=80=9Cevents=E2=80=9D >> singular and have an extensions attribute to hold the extensions. Or = we >> could go to a more complex JSON structure (not personally a fan). >=20 > I'm personally fine with a main "event" object and an "extensions" = attribute. I can even live with "event" being called "events", per = Mike's proposal. But the structure needs to make sense as a JSON object = if we want it implemented. [PH] Thread: Should the primary event be a separate attribute? We had this broken out before. If there is sufficient desire to break it = out again, I have no objection. >=20 >>>=20 >>> * 2: event extensions are not defined but only introduced by the >>> text after they are described. Also, in the example there's this >>> URL: = >https:// >>> = =E2=80=8Bexample.=E2=80=8Bcom/=E2=80=8Bscim/=E2=80=8Bevent/=E2=80=8Bpas=E2= =80=8Bswor=E2=80=8BdRes=E2=80=8BetEx=E2=80=8Bt - I believe it >>> needs to be part of the passwordReset object and not parallel to = it. >> I will check for clarity. The password example is intended to >> demonstrate an example where a publisher wishes to provide additional >> context such as the number of resets performed. Note in defining a >> password reset event it might indeed make sense to combine that info. = My >> intent was to show an extension. Maybe there is a better hypothetical >> example? >>>=20 >>> * Why "events" and not "event"? We don't really have support for >>> multiple events. Certainly not if they are all of the same type. >>> The current text is confusing: "events" is not the same as "a >>> primary event and its extensions=E2=80=9D. >> Reflects your earlier comment re: primary vs. extensions. "events=E2=80= =9D is >> plural to reflect the fact that the attribute is multi-valued. I = agree, >> given that only one primary event can be included, the naming is = misleading. >>>=20 >>> * "In the above example "iss" and "sub" contained within the claim" >>> - this is incorrect, probably leftover from an earlier version. >> NO. In the example, =E2=80=9Ciss=E2=80=9D and =E2=80=9Csub=E2=80=9D = indicate the subject is from a >> different issuer of the event. For example a relying party web site >> wants to tell the identity provider (the original subject issuer) = that >> the user has requested a logout. >=20 > I'm still confused by the text. The paragraph talks about iss and sub = contained within the claim, and contrasted with "the top level value of = iss", which I'm unable to locate. [PH] Thread: On the issue of =E2=80=9Csub=E2=80=9D and =E2=80=9Ciss=E2=80= =9D =E2=80=9Csub=E2=80=9D in the root level is defined by the JWT = specification. Many of the implementations of JWT have asserted = =E2=80=9Csub=E2=80=9D as unique only within the context of a specific = issuer. This worked fine in SSO cases because only the identity provider = that controls the issuer would issue an assertion for a subject within = their domain. When we start to talk about hypothetical events that may arise, it is = reasonable to expect that a relying party may wish to issue an event = about a federated identity providers subject. If they do that, then = =E2=80=9Ciss=E2=80=9D becomes conflicted. =E2=80=9Ciss=E2=80=9D should = be the issuer of the event. Yet, =E2=80=9Csub=E2=80=9D by itself in many = cases does not sufficiently identify the subject of the event. We worked around this by allowing sub and iss to be moved to the payload = area. This would allow a relying party site the ability to signal an = event about a subject for which they were not the original issuer. >=20 >>>=20 >>> * "aud" MAY be a URI: shouldn't it be an array, maybe an array that >>> contains a single URI? >> This is defined by the JWT spec. >=20 > I am talking about the syntax. "aud" is an array of URIs, not a URI. [PH] I will double-check this. >=20 >>>=20 >>> * Why do we use the terms "single-valued" vs. "multiple-valued" >>> strings? Why not use the normal JSON terminology, "string" vs. >>> "array of strings=E2=80=9D? >> Habit from the world of IDM. We could align it. >=20 > We should. [PH] OK >=20 >>>=20 >>> * Why is "sub" optional? Do we have any good examples of events >>> where this value is not required? >> You might have an event about a session, or an IP address, or some = other >> thing. >>=20 >> There was an email discussion in the past about whether sub should be = a >> security subject (e.g. as defined by SAML or OpenID Connect), or = whether >> sub is just the subject of the event and thus can be anything. >>=20 >> I expect to see more discussion on this. >=20 > I'm confused. If the subject is an IP address or session identifier, = it still doesn't make it into an optional value. [PH] Thread: =E2=80=9Csub=E2=80=9D used for any purpose or used as an = authenticated user only It depends on what the defining event spec wants to use. There was = resistance to forcing its use. In fact there was a lot of opinion that =E2=80=9Csub=E2=80=9D should = only be used for an authenticated user as that was the defacto use. I think this thread could use some more discussion. >=20 >>>=20 >>> * "a future date" - we should clarify that there may be cases when >>> nbf is smaller than iat, i.e. when it takes some time until the >>> SET is issued. >> Assume you are referring to =E2=80=9Cnbf=E2=80=9D. The definition = comes from JWT. >=20 > The clarification is still needed, if the JWT definition is imprecise. >=20 >>>=20 >>> * "exp" - is it also a NumericDate? Please specify. >> Defined by JWT, RFC7519 >=20 > If we repeat all other JWT definitions, we should repeat this one too, = for consistency. >=20 >>>=20 >>> * In the medical example, it is strange that the event is named by = a >>> URL that points to an HTML page. I would expect a more stable = URI. >> It is an example. Many have indicated that they want the event should = be >> a URL to the page that defines the event. >=20 > I would prefer our examples to be what we think are best practices. = And personally I don't think this is one. What if the next version of = the web site's code changes "consent.html" into "consent.jsp=E2=80=9D? [PH] =46rom my standpoint this is a chicken and the egg practice. This = is a new format which there are several planned extensions. So there is = nothing stable I as editor can refer to. The hypothetical examples are shown to give a variety of examples that = are acceptable. For example, SCIM *might* use URNs while other = specifications like RISC might user pointers to published HTML or txt = files on the OpenId.net site. It is really up to the publisher and the subscriber to agree. >=20 >>=20 >>> * 2.2: is encryption a MUST whenever there are attributes = specified? >>> If so, we should have a normative section saying so, not just >>> mention it in the context of an example. Besides, we have not >>> defined what attributes are. >> Please quote the text, 2.2 simply shows how to construct a SET token >> based on language from 7519. >=20 > Quoting: "In this example, because the event contains attribute = values, the token MUST be encrypted per JWE (see [RFC7516]) before = transmission.=E2=80=9D [PH] Examples are not normative. The text may not be sufficiently = clear. What I was trying to distinguish was the difference between an = event that says a record was modified, and an event that says a record = was modified with the actual changes as part of the event. >=20 >>>=20 >>> * 2.2: this section is confusing. We first say that the JWT must be >>> encrypted. >> Where does it say this? >=20 > See above. >=20 >>>=20 >>> * But then instead, we sign it, and we "sign" with a null = algorithm. >>> Why? >>> * Signed SETs MUST (not MAY) be validated by the subscriber. >> specific text please? >=20 > Quote: "so that individual events MAY be authenticated and validated = by the subscriber." >=20 >>>=20 >>> * Also, I think we should remove the preconditions and always >>> require signing, as a MUST. An optional signature is actually a >>> security loophole because an attacker can remove the signature, >>> and the subscriber doesn't know that it's missing. >> Which text are you referring to. >>=20 >> Signatures aren=E2=80=99t always necessary if the method for delivery = itself >> authenticates the publisher delivering the HTTP POST request and it = is >> secured by TLS. >>>=20 >>> * 3.2: "that alone will not guarantee that the correct subscribing >>> party knows they should have received a particular SET." The text >>> is unclear to me. Do we mean: "that alone does not guarantee that >>> a particular SET was delivered to the correct subscribing = party=E2=80=9D? >> Just because an endpoint returns success after a POST does not by = itself >> guarantee it was able to decrypt or parse the message. Nor does it = prove >> the subscriber held the private key to decrypt the JWE. >=20 > Absolutely. And your text here is much clearer than the sentence I = quote above, "that alone does not guarantee...". >=20 >>=20 >> We cover this somewhat in the distribution draft when we talk about >> verification messages which require the receiver to parse the message >> and return content back proving possession. >>>=20 >>> * We may want a separate Implementation Considerations section, and >>> move "delivery", "sequencing" and "timing" into it. Yes they are >>> security-relevant, just like anything else in this document, but >>> they would apply just as well to any event stream protocol. >> Seems reasonable. >>>=20 >>> * 3.3: this is the first time we mention provisioning. Do we really >>> intend SETs to be used for that? >> Yes. Some of us do - this work actually began within the SCIM WG. >> Provisioning was provided as an example of a type of event where >> ordering would be crucial. >>>=20 >>> * 3.3: ISTM that we should define a sequencing mechanism, rather >>> than leave it open to profiles. E.g., require a sequence number >>> whenever "txn" is used. >> txn is a separate concept. txn is there when publishers decide to = issue >> multiple events against the same originating event. For example, one >> subscriber might understand suspicious activity while another might = only >> understand logout. Some have requested an attribute that lets the >> publisher track that the different events actually stem from the same >> original event. For example when a publishers operations center gets = a >> call to trace a series of events. >>>=20 >>> * 3.4: Also, our timestamps only have 1 second granularity, and so >>> are too coarse for session state (consider automated = logins/logouts). >> The point here is to address event design issues where relying on >> timestamp to order events is problematic. For example if you signal >> logout only by subject identifier then it becomes hard to tell if a = user >> is logging back in or not. It is better to cancel a session = associated >> with a subject so that the new session can still be established. >>>=20 >>> * 3.5: Why don't we have an unambiguous way to distinguish SETs = from >>> access tokens, why leave it to implementers? Sounds like a major >>> security issue in the making. We should consider here ALL >>> implementations that accept access tokens, including legacy >>> implementations that cannot be modified. >> I agree. The real issue is that JWT=E2=80=99s should have had a type = to begin >> with. One of the threads is here: >> https://www.ietf.org/mail-archive/web/id-event/current/msg00120.html >=20 > Yep. I would like to reopen this discussion post-adoption. [PH] Thread: Avoiding SETs being confused as an access token I agree. My personal thought is to avoid usage of =E2=80=9Csub=E2=80=9D = at the top level. It addresses the issuer conflict mentioned above and = current implementations will fail if an event is passed as if it were an = access token as sub is missing. The complaint I heard back is that there are some libraries that simply = will not work at all if =E2=80=9Csub=E2=80=9D is not present. This is = despite the JWT spec making sub optional. I=E2=80=99m not sure what is best here. I tend to side with existing = libraries being upgraded to be SET compatible anyway. The reality is, = SET isn=E2=80=99t breaking JWT rules, its the implementation that is. With that said, there may be a better way to distinguish SETs and JWTs. >=20 >>>=20 >>> * 4: The audit happens on the subscriber side. By then it is too >>> late to require JWS to be used by the publisher. As mentioned, I >>> propose that JWS should ALWAYS be required. >> This is something that publisher and subscriber have to negotiate. = This >> is anticipated in the distribution spec to some degree. Though IMO, >> there is not a lot of consensus on this yet. >>>=20 >>> * 4: "When sharing personally identifiable information" - we should >>> remove this condition. I don't see a case where the information >>> shared is NOT PII, and therefore legal agreements about >>> information sharing and user consent must always be in place. >> How about cancellation of a token or a session? If just passing a = =E2=80=9Cjti=E2=80=9D >> value, there is arguably no PII. The JTI might be traceable, but the >> relying party would have to know about it to infer meaning. Also, >> tokens/sessions should never be permanent. I am not a lawyer, but I >> doubt these examples would actually be PII. >>>=20 >>> * 4: I don't think the subject information is "perceived" as PII. = It >>> is PII, otherwise it would be useless to the subscriber, because >>> the subscriber would not be able to identify the subject. Also, >>> even if the information on the wire is not in itself PII, e.g. >>> when using a hash, the fact that a publisher shares information >>> that a particular user is also a user on its system and is >>> undergoing certain state changes is privacy-sensitive. >> Again, the subject of an event might be about a session or a token, >> device, etc. >>>=20 >>> * I suggest to add an Implementation Status section, per RFC 7942. >> It would be helpful for the chairs to provide guidance on this. >=20 > I am an author on 7942, so I will only recommend it as an individual: = I think it will be helpful to WG members when evaluating the draft. We = can probably delay it to just before WGLC though. [PH] Thread: RFC7942 support I am a bit surprised by this specification and as editor I would like = some guidance on this from the chairs. As editor, RFC7942 has admirable goals, but it creates a = chicken-and-the-egg problem=E2=80=A6 My understanding of RFCs is that except for errata there is no revision = process for RFCs. 7942 introduces a requirement for monthly if not daily = updates that the IETF does not currently support. Many organizations are not willing/able to publish their implementation = support until code is =E2=80=9Cshipping=E2=80=9D and often until after = the IETF has published RFCs. Introducing an implementation list at the = draft stage unfairly penalizes organizations that will not ship until = RFC status is obtained. IMO it would also be mis-leading as to the = acceptance of a specification. For example, my impression of SCIM implementation was that it almost = immediately doubled *after* publication as 7643/7644. Had published = implementation information at publication it would have been immediately = incomplete and potentially erroneous. >=20 >>>=20 >>> Thanks, >>>=20 >>> Yaron >>>=20 >>> _______________________________________________ >>> Id-event mailing list >>> Id-event@ietf.org >>> https://www.ietf.org/mailman/listinfo/id-event = >>=20 >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event = --Apple-Mail=_549E3578-A46C-4E6A-B4CF-8EA100D79063 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Yaron,

Thanks for your comments. Its always good to get broader = review. My responses inline.

I have marked some sections as = =E2=80=9CThread: =E2=80=A6=E2=80=9D which is an invitation to open a new = email thread to keep the discussion going.




On Dec 18, 2016, at 1:32 PM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

Hi Phil,

Thank you for your detailed comments, they are = very helpful as I ramp up my understanding of this area. Please see some = responses inline.

Thanks,
Yaron

On 14/12/16 22:18, Phil Hunt = wrote:
Yaron,

Thanks for your comments. My responses = inline.

Phil

@independentid
www.independentid.com <http://www.independentid.com>
phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>





On Dec 10, 2016, at 1:27 = PM, Yaron Sheffer <yaronf.ietf@gmail.com
<mailto:yaronf.ietf@gmail.com>> wrote:

Hi, I finally read the draft in detail, and I = do have a few comments.

My main suggestion = is to tighten the specification of an Event, by
defining = more strictly the difference between "event" and "event
extension" and tweaking the JSON structure a bit.


The spec has = undergone some restructuring recently, and it may need some
more tightening up. The informal consensus from the id-events = list is
that there should be only one event. However, in = order to allow some
deployers to provide additional = information, and extension methodology
was included. =  An example is given.

In addition, I think we should require the = claim to be signed, since
it will be used for = security-sensitive activities across complex
distributed = systems.

 * 1: Why is signing = optional? The publisher doesn't know how the
   subscriber's system is architected, and = might well want end-to-end
   authentication = of the claim. This is also important for auditing.
I think the key word in your question is = =E2=80=9Cmight=E2=80=9D.  Also, its not the
publisher = that needs authentication of the statement its really the
subscriber.

Many have preferred = to have a minimum option where security is
essentially = point-to-point depending primarily on TLS.  There are other
cases where end-to-end key based is preferred especially = when
transmitting over less secure transport.

Remember that this specification is a coming = together of a bunch of
initiatives around a common format. = It is difficult to assign mandatory
requirements unless = there is strong consensus to do so.

 * 1: "example = events" - is specification of individual events (maybe
   only a few basic ones) within scope of our = charter? Otherwise we
   cannot guarantee = interop.
The intention is to define a base = level format that other working groups
and SDOs will use = to define their own events. The primary benefit is to
have = a common format.

I had originally = envisioned an event registry, but the early discussions
were= to avoid IANA registration. We then switched to using URI=E2=80=99s = for
events.

The informal = consensus was that what matters is that publisher and
subscriber agree on meaning and that it is ok for events to = be highly
specific.

I still need to = wrap my mind around a spec (and a working group) where the end result is = not interoperable implementations.

[PH] I = think you may be confusing protocol and message format with content. The = goal of this specification is to provide a common event format that can = be easily exchanged.  Other WGs and SDOs are planning to use this = common format to define their own specific events. E.g. http://openid.net/specs/openid-connect-backchannel-1_0.html=

So what we are looking for is a way = for libraries to be developed that are extensions of current JWT = libraries. 

Ideally this is = small incremental profile of JWT that adds key clarifications, security = and privacy considerations.


 * = 1.2: principle -> principal
Noted

 * = 2: "first value" is meaningless. JSON objects are unordered (4th
   paragraph of RFC 7159). If order /is/ = important, we could make
   "events" into = an array.
Yup.   How would the = group like to fix this?  We could make =E2=80=9Cevents=E2=80=9D
singular and have an extensions attribute to hold the = extensions.  Or we
could go to a more complex JSON = structure (not personally a fan).

I'm personally fine = with a main "event" object and an "extensions" attribute. I can even = live with "event" being called "events", per Mike's proposal. But the = structure needs to make sense as a JSON object if we want it = implemented.

[PH] Thread: = Should the primary event be a separate attribute?

We had this broken out before. If there is = sufficient desire to break it out again, I have no objection.


 * 2: event extensions are not defined = but only introduced by the
   text after = they are described. Also, in the example there's this
   URL: <https://%e2%80%8bexample.%e2%80%8bcom/%E2%80%8Bscim/%E2%80%8Bev= ent/%E2%80%8Bpas%E2%80%8Bswor%E2%80%8BdRes%E2%80%8BetEx%E2%80%8Bt>h= ttps://
   =E2=80=8Bexample.=E2=80=8Bcom/=E2=80=8Bscim/=E2= =80=8Bevent/=E2=80=8Bpas=E2=80=8Bswor=E2=80=8BdRes=E2=80=8BetEx=E2=80=8Bt = - I believe it
   needs to be part of the = passwordReset object and not parallel to it.
I = will check for clarity. The password example is intended to
demonstrate an example where a publisher wishes to provide = additional
context such as the number of resets performed. =  Note in defining a
password reset event it might = indeed make sense to combine that info. My
intent was to = show an extension. Maybe there is a better hypothetical
example?
 * Why "events" and not "event"? We don't really have = support for
   multiple events. Certainly = not if they are all of the same type.
   The = current text is confusing: "events" is not the same as "a
   primary event and its extensions=E2=80=9D.
Reflects your earlier comment re: primary vs. = extensions.  "events=E2=80=9D is
plural to reflect = the fact that the attribute is multi-valued. I agree,
given = that only one primary event can be included, the naming is = misleading.

 * "In the above example "iss" and "sub" contained = within the claim"
   - this is incorrect, = probably leftover from an earlier version.
NO. =  In the example, =E2=80=9Ciss=E2=80=9D and =E2=80=9Csub=E2=80=9D = indicate the subject is from a
different issuer of the = event.  For example a relying party web site
wants to = tell the identity provider (the original subject issuer) that
the user has requested a logout.
I'm still confused = by the text. The paragraph talks about iss and sub contained within the = claim, and contrasted with "the top level value of iss", which I'm = unable to locate.
[PH]  Thread: On the issue of = =E2=80=9Csub=E2=80=9D and =E2=80=9Ciss=E2=80=9D

=E2=80=9Csub=E2=80=9D in the root level is defined by = the JWT specification. Many of the implementations of JWT have asserted = =E2=80=9Csub=E2=80=9D as unique only within the context of a specific = issuer. This worked fine in SSO cases because only the identity provider = that controls the issuer would issue an assertion for a subject within = their domain.

When we start to talk = about hypothetical events that may arise, it is reasonable to expect = that a relying party may wish to issue an event about a federated = identity providers subject.  If they do that, then =E2=80=9Ciss=E2=80= =9D becomes conflicted.  =E2=80=9Ciss=E2=80=9D should be the issuer = of the event. Yet, =E2=80=9Csub=E2=80=9D by itself in many cases does = not sufficiently identify the subject of the event.

We worked around this by allowing sub and iss to = be moved to the payload area. This would allow a relying party site the = ability to signal an event about a subject for which they were not the = original issuer.


 * "aud" MAY be a URI: = shouldn't it be an array, maybe an array that
   contains a single URI?
This is defined by the JWT spec.

I am talking about the syntax. "aud" is an array = of URIs, not a URI.
[PH] I will double-check this.


 * Why do we use the terms = "single-valued" vs. "multiple-valued"
   strings? Why not use the normal JSON = terminology, "string" vs.
   "array of = strings=E2=80=9D?
Habit from the world of = IDM. We could align it.

We = should.
[PH] OK


 * Why is "sub" optional? Do we have any good examples = of events
   where this value is not = required?
You might have an event about a = session, or an IP address, or some other
thing.

There was an email discussion in the past = about whether sub should be a
security subject (e.g. as = defined by SAML or OpenID Connect), or whether
sub is just = the subject of the event and thus can be anything.

I expect to see more discussion on this.

I'm confused. If the subject is an IP address or = session identifier, it still doesn't make it into an optional = value.
[PH] Thread: =E2=80=9Csub=E2=80=9D used = for any purpose or used as an authenticated user only

It depends on what the defining event spec wants = to use. There was resistance to forcing its use.

In fact there was a lot of opinion that =E2=80=9Csub= =E2=80=9D should only be used for an authenticated user as that was the = defacto use.

I think this thread = could use some more discussion.


 * = "a future date" - we should clarify that there may be cases when
   nbf is smaller than iat, i.e. when it takes = some time until the
   SET is issued.
Assume you are referring to =E2=80=9Cnbf=E2=80=9D.= The definition comes from JWT.

The clarification = is still needed, if the JWT definition is imprecise.


 * "exp" - is it also a NumericDate? Please specify.
Defined by JWT, RFC7519

If we repeat all other JWT definitions, we = should repeat this one too, for consistency.


 * In the medical example, it is strange that the event = is named by a
   URL that points to an HTML = page. I would expect a more stable URI.
It is = an example. Many have indicated that they want the event should be
a URL to the page that defines the event.

I would prefer our examples to be what we think = are best practices. And personally I don't think this is one. What if = the next version of the web site's code changes "consent.html" into = "consent.jsp=E2=80=9D?

[PH] =46rom = my standpoint this is a chicken and the egg practice. This is a new = format which there are several planned extensions.  So there is = nothing stable I as editor can refer to.

The hypothetical examples are shown to give a = variety of examples that are acceptable.  For example, SCIM *might* = use URNs while other specifications like RISC might user pointers to = published HTML or txt files on the OpenId.net site.

It = is really up to the publisher and the subscriber to agree.



 * 2.2: is encryption a MUST whenever = there are attributes specified?
   If so, = we should have a normative section saying so, not just
   mention it in the context of an example. = Besides, we have not
   defined what = attributes are.
Please quote the text, 2.2 = simply shows how to construct a SET token
based on = language from 7519.

Quoting: "In this example, because the = event contains attribute values, the token MUST be encrypted per JWE = (see [RFC7516]) before = transmission.=E2=80=9D

[PH] Examples are not normative.  The text may not = be sufficiently clear.  What I was trying to distinguish was the = difference between an event that says a record was modified, and an = event that says a record was modified with the actual changes as part of = the event.



 * = 2.2: this section is confusing. We first say that the JWT must be
   encrypted.
Where = does it say this?

See above.


 * But then instead, we = sign it, and we "sign" with a null algorithm.
   Why?
 * Signed SETs MUST = (not MAY) be validated by the subscriber.
specific text please?

Quote: "so that individual events MAY be = authenticated and validated by the subscriber."


 * Also, I think we should remove the preconditions and = always
   require signing, as a MUST. An = optional signature is actually a
   security = loophole because an attacker can remove the signature,
   and the subscriber doesn't know that it's = missing.
Which text are you referring to.

Signatures aren=E2=80=99t always necessary if = the method for delivery itself
authenticates the publisher = delivering the HTTP POST request and it is
secured by = TLS.

 * 3.2: "that alone will not guarantee that the correct = subscribing
   party knows they should have = received a particular SET." The text
   is = unclear to me. Do we mean: "that alone does not guarantee that
   a particular SET was delivered to the = correct subscribing party=E2=80=9D?
Just = because an endpoint returns success after a POST does not by itself
guarantee it was able to decrypt or parse the message. Nor = does it prove
the subscriber held the private key to = decrypt the JWE.

Absolutely. And your text here is much = clearer than the sentence I quote above, "that alone does not = guarantee...".


We cover this = somewhat in the distribution draft when we talk about
verification messages which require the receiver to parse the = message
and return content back proving possession.

 * = We may want a separate Implementation Considerations section, and
   move "delivery", "sequencing" and "timing" = into it. Yes they are
   security-relevant, = just like anything else in this document, but
   they would apply just as well to any event = stream protocol.
Seems reasonable.

 * = 3.3: this is the first time we mention provisioning. Do we really
   intend SETs to be used for that?
Yes. Some of us do - this work actually began = within the SCIM WG.
Provisioning was provided as an = example of a type of event where
ordering would be = crucial.

 * 3.3: ISTM that we should define a sequencing = mechanism, rather
   than leave it open to = profiles. E.g., require a sequence number
   whenever "txn" is used.
txn is a separate concept. txn is there when = publishers decide to issue
multiple events against the = same originating event.  For example, one
subscriber = might understand suspicious activity while another might only
understand logout. Some have requested an attribute that lets = the
publisher track that the different events actually = stem from the same
original event.  For example when = a publishers operations center gets a
call to trace a = series of events.

 * 3.4: Also, our timestamps only have 1 second = granularity, and so
   are too coarse for = session state (consider automated logins/logouts).
The point here is to address event design issues = where relying on
timestamp to order events is problematic. = For example if you signal
logout only by subject = identifier then it becomes hard to tell if a user
is = logging back in or not. It is better to cancel a session associated
with a subject so that the new session can still be = established.

 * 3.5: Why don't we have an unambiguous way to = distinguish SETs from
   access tokens, why = leave it to implementers? Sounds like a major
   security issue in the making. We should = consider here ALL
   implementations that = accept access tokens, including legacy
   implementations that cannot be modified.
I agree. The real issue is that JWT=E2=80=99s = should have had a type to begin
with. One of the threads = is here:
https://www.ietf.org/mail-archive/web/id-event/current/msg00120= .html

Yep. I would like to reopen this = discussion post-adoption.

[PH] Thread: = Avoiding SETs being confused as an access token

I agree. My personal thought is to avoid usage of = =E2=80=9Csub=E2=80=9D at the top level. It addresses the issuer conflict = mentioned above and current implementations will fail if an event is = passed as if it were an access token as sub is missing.

The complaint I heard back is that there are some = libraries that simply will not work at all if =E2=80=9Csub=E2=80=9D is = not present. This is despite the JWT spec making sub = optional.

I=E2=80=99m not sure what = is best here. I tend to side with existing libraries being upgraded to = be SET compatible anyway. The reality is, SET isn=E2=80=99t breaking JWT = rules, its the implementation that is.

With that said, there may be a better way to = distinguish SETs and JWTs.



 * 4: The audit happens on the subscriber side. By then = it is too
   late to require JWS to be used = by the publisher. As mentioned, I
   propose = that JWS should ALWAYS be required.
This is = something that publisher and subscriber have to negotiate. This
is anticipated in the distribution spec to some degree. = Though IMO,
there is not a lot of consensus on this = yet.

 * 4: "When sharing personally identifiable information" = - we should
   remove this condition. I = don't see a case where the information
   shared is NOT PII, and therefore legal = agreements about
   information sharing and = user consent must always be in place.
How = about cancellation of a token or a session?  If just passing a = =E2=80=9Cjti=E2=80=9D
value, there is arguably no PII. =  The JTI might be traceable, but the
relying party = would have to know about it to infer meaning.  Also,
tokens/sessions should never be permanent.  I am not a = lawyer, but I
doubt these examples would actually be = PII.

 * 4: I don't think the subject information is = "perceived" as PII. It
   is PII, otherwise = it would be useless to the subscriber, because
   the subscriber would not be able to = identify the subject. Also,
   even if the = information on the wire is not in itself PII, e.g.
   when using a hash, the fact that a = publisher shares information
   that a = particular user is also a user on its system and is
   undergoing certain state changes is = privacy-sensitive.
Again, the subject of an = event might be about a session or a token,
device, etc.

 * I = suggest to add an Implementation Status section, per RFC 7942.
It would be helpful for the chairs to provide = guidance on this.

I am an author on 7942, so I will only = recommend it as an individual: I think it will be helpful to WG members = when evaluating the draft. We can probably delay it to just before WGLC = though.

[PH] Thread: = RFC7942 support

I am a bit surprised = by this specification and as editor I would like some guidance on this = from the chairs.

As editor, RFC7942 = has admirable goals, but it creates a chicken-and-the-egg = problem=E2=80=A6

My understanding of = RFCs is that except for errata there is no revision process for RFCs. = 7942 introduces a requirement for monthly if not daily updates that the = IETF does not currently support.

Many = organizations are not willing/able to publish their implementation = support until code is =E2=80=9Cshipping=E2=80=9D and often until after = the IETF has published RFCs.  Introducing an implementation list at = the draft stage unfairly penalizes organizations that will not ship = until RFC status is obtained.  IMO it would also be mis-leading as = to the acceptance of a specification.

For example, my impression of SCIM implementation = was that it almost immediately doubled *after* publication as 7643/7644. =  Had published implementation information at publication it would = have been immediately incomplete and potentially = erroneous.



Thanks,

   Yaron

_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event


_______________________________________________
Id-event mailing = list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event

= --Apple-Mail=_549E3578-A46C-4E6A-B4CF-8EA100D79063-- From nobody Thu Dec 22 03:34:15 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DABB129534 for ; Thu, 22 Dec 2016 03:34:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPUwGWjknRvp for ; Thu, 22 Dec 2016 03:34:12 -0800 (PST) Received: from mail-pf0-x241.google.com (mail-pf0-x241.google.com [IPv6:2607:f8b0:400e:c00::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97770129408 for ; Thu, 22 Dec 2016 03:34:12 -0800 (PST) Received: by mail-pf0-x241.google.com with SMTP id y68so12381548pfb.1 for ; Thu, 22 Dec 2016 03:34:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=/8h+umob6q0E2FMQSze0N0HLZ4A3b1rxGwrQ7v2dz6A=; b=hPRzuU0jkGEgqfnnRm/ljZiaiJgQGBtOLiy2fB5at7mMq14k+Puj/9TtO7KOfNhsSR vmr2tvj8hNUcfVO08gXwwqKVD5NcQwxr761Bvz6oNlD1zY81Z//gPvVO1dfoVlj8OyVM MX3Z+d/iRggHMGqgBa4xqhEgJT5VAIrFS4dqcZGtYa6JHWDdC0au/dgfUWbru/VtMh+R SEG3Lb4Mx9q2WYGJ+jwkf1d6ZYqP7rJA21gwzLdJOZfHgeGui5w0L8eWSEutYw1r97qr WMqhJhmaWtEUnlJqDPXFtxJkF3cy8LsjYDGaHLQA7h3cN0Z90nIuBSkuWEG+aPGYXGWr UW1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=/8h+umob6q0E2FMQSze0N0HLZ4A3b1rxGwrQ7v2dz6A=; b=Q2dD2IhO2KUmwrxMZ7Adxnfuxop/hjVrjFa9LsDyw3E9ShRc5KBj0j5eujMlEoRDSL XpmeaZS75MyPyCjadfWie2zm0DhVyAGCb4kVPNwXA8zhgWo6O0eUrNLO7DT9E8UPWt5j A5CMRfe0pDSCrzH7SSLUfNXByinA/mEYLhA+5nUK3HHDy+PROHWojdNU8dv4oVviaTth iZV+idPdm/1oPIqIpUtqek+eyvMmpT4pEYRKvcKG7j1LPnkvqJVF0J8ij/KSeJetoJbH kt6/dlLl1qynKiVHJDRcNDmnP1KGfQtdK4SWYyuaCNeL2sP3LTy2FgUh2TlTvU2MSmDl 03Tw== X-Gm-Message-State: AIkVDXKux6JAhmm5GOXjHjSp/htX2Ht3GckJ0D1uUaRJouFLoLvP9Oj/XsNlIbODDzzxDA== X-Received: by 10.84.129.4 with SMTP id 4mr5560612plb.104.1482406452168; Thu, 22 Dec 2016 03:34:12 -0800 (PST) Received: from [172.17.202.138] (silverdollar.intuit.com. [199.16.140.26]) by smtp.gmail.com with ESMTPSA id v1sm54500392pgv.33.2016.12.22.03.34.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Dec 2016 03:34:11 -0800 (PST) To: Phil Hunt References: <9114f681-cba9-b6d3-8369-ccd9193ce1b8@gmail.com> <3097AC43-4652-40DB-8120-F25D68E1F0A8@oracle.com> From: Yaron Sheffer Message-ID: <18dfa38d-75fb-d47c-6821-6baf368fc6a9@gmail.com> Date: Thu, 22 Dec 2016 13:34:04 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <3097AC43-4652-40DB-8120-F25D68E1F0A8@oracle.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: SecEvent Subject: Re: [Id-event] Some comments to draft-hunt-idevent-token-07 - RFC 7942 X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 11:34:14 -0000 Hi Phil, I'd like to respond separately to your last point, as an individual (and coauthor of the said RFC). It's important to me to clarify the intent and some important details of the RFC. Thanks, Yaron On 21/12/16 23:20, Phil Hunt wrote: > Yaron, > > Thanks for your comments. Its always good to get broader review. My > responses inline. > > I have marked some sections as “Thread: …” which is an invitation to > open a new email thread to keep the discussion going. > > Phil > >>>> >>>> * I suggest to add an Implementation Status section, per RFC 7942. >>> It would be helpful for the chairs to provide guidance on this. >> >> I am an author on 7942, so I will only recommend it as an individual: >> I think it will be helpful to WG members when evaluating the draft. We >> can probably delay it to just before WGLC though. > > [PH] Thread: RFC7942 support > > I am a bit surprised by this specification and as editor I would like > some guidance on this from the chairs. > > As editor, RFC7942 has admirable goals, but it creates a > chicken-and-the-egg problem… The RFC and its predecessor were used by over 50 I-Ds, so obviously the problems are not insurmountable. > > My understanding of RFCs is that except for errata there is no revision > process for RFCs. 7942 introduces a requirement for monthly if not daily > updates that the IETF does not currently support. No. The RFC applies to I-Ds only, and the Implementation Status section should be removed before the I-D is published as an RFC. This is stated clearly in RFC 7942 (not clearly enough though, since you missed it :-). > > Many organizations are not willing/able to publish their implementation > support until code is “shipping” and often until after the IETF has > published RFCs. Introducing an implementation list at the draft stage > unfairly penalizes organizations that will not ship until RFC status is > obtained. IMO it would also be mis-leading as to the acceptance of a > specification. Again, the goal is to support the WG and the IETF at large while the I-D is being developed. It is not a goal (or a likely result, IMHO) to benefit or penalize specific implementers. The RFC is vague enough that companies can choose what to publish and what not to. > > For example, my impression of SCIM implementation was that it almost > immediately doubled *after* publication as 7643/7644. Had published > implementation information at publication it would have been immediately > incomplete and potentially erroneous. See above. > >> >>>> >>>> Thanks, >>>> >>>> Yaron >>>> >>>> _______________________________________________ >>>> Id-event mailing list >>>> Id-event@ietf.org >>>> https://www.ietf.org/mailman/listinfo/id-event >>> >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event > From nobody Thu Dec 22 07:12:32 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C5E2129511 for ; Thu, 22 Dec 2016 07:12:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.302 X-Spam-Level: X-Spam-Status: No, score=-7.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R4pjmDhZd_rT for ; Thu, 22 Dec 2016 07:12:29 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 4B18C129456 for ; Thu, 22 Dec 2016 07:12:29 -0800 (PST) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id uBMFCQQF029526 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 22 Dec 2016 15:12:27 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id uBMFCQok029661 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 22 Dec 2016 15:12:26 GMT Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id uBMFCPEu004283; Thu, 22 Dec 2016 15:12:26 GMT Received: from [192.168.1.22] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 22 Dec 2016 07:12:25 -0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (14B100) In-Reply-To: <18dfa38d-75fb-d47c-6821-6baf368fc6a9@gmail.com> Date: Thu, 22 Dec 2016 07:12:23 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9114f681-cba9-b6d3-8369-ccd9193ce1b8@gmail.com> <3097AC43-4652-40DB-8120-F25D68E1F0A8@oracle.com> <18dfa38d-75fb-d47c-6821-6baf368fc6a9@gmail.com> To: Yaron Sheffer X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: SecEvent Subject: Re: [Id-event] Some comments to draft-hunt-idevent-token-07 - RFC 7942 X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 15:12:31 -0000 Thanks Yaron for the clarification.=20 If it is only in the I-d stage then my concerns are misplaced.=20 I think it would be useful as there are a number of libraries that should al= ready work.=20 Phil > On Dec 22, 2016, at 3:34 AM, Yaron Sheffer wrote: >=20 > Hi Phil, >=20 > I'd like to respond separately to your last point, as an individual (and c= oauthor of the said RFC). It's important to me to clarify the intent and som= e important details of the RFC. >=20 > Thanks, > Yaron >=20 >> On 21/12/16 23:20, Phil Hunt wrote: >> Yaron, >>=20 >> Thanks for your comments. Its always good to get broader review. My >> responses inline. >>=20 >> I have marked some sections as =E2=80=9CThread: =E2=80=A6=E2=80=9D which i= s an invitation to >> open a new email thread to keep the discussion going. >>=20 >> Phil >>=20 >>>>>=20 >>>>> * I suggest to add an Implementation Status section, per RFC 7942. >>>> It would be helpful for the chairs to provide guidance on this. >>>=20 >>> I am an author on 7942, so I will only recommend it as an individual: >>> I think it will be helpful to WG members when evaluating the draft. We >>> can probably delay it to just before WGLC though. >>=20 >> [PH] Thread: RFC7942 support >>=20 >> I am a bit surprised by this specification and as editor I would like >> some guidance on this from the chairs. >>=20 >> As editor, RFC7942 has admirable goals, but it creates a >> chicken-and-the-egg problem=E2=80=A6 >=20 > The RFC and its predecessor were used by over 50 I-Ds, so obviously the pr= oblems are not insurmountable. >>=20 >> My understanding of RFCs is that except for errata there is no revision >> process for RFCs. 7942 introduces a requirement for monthly if not daily >> updates that the IETF does not currently support. >=20 > No. The RFC applies to I-Ds only, and the Implementation Status section sh= ould be removed before the I-D is published as an RFC. This is stated clearl= y in RFC 7942 (not clearly enough though, since you missed it :-). >=20 >>=20 >> Many organizations are not willing/able to publish their implementation >> support until code is =E2=80=9Cshipping=E2=80=9D and often until after th= e IETF has >> published RFCs. Introducing an implementation list at the draft stage >> unfairly penalizes organizations that will not ship until RFC status is >> obtained. IMO it would also be mis-leading as to the acceptance of a >> specification. >=20 > Again, the goal is to support the WG and the IETF at large while the I-D i= s being developed. It is not a goal (or a likely result, IMHO) to benefit or= penalize specific implementers. The RFC is vague enough that companies can c= hoose what to publish and what not to. >=20 >>=20 >> For example, my impression of SCIM implementation was that it almost >> immediately doubled *after* publication as 7643/7644. Had published >> implementation information at publication it would have been immediately >> incomplete and potentially erroneous. >=20 > See above. >>=20 >>>=20 >>>>>=20 >>>>> Thanks, >>>>>=20 >>>>> Yaron >>>>>=20 >>>>> _______________________________________________ >>>>> Id-event mailing list >>>>> Id-event@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/id-event >>>>=20 >>>=20 >>> _______________________________________________ >>> Id-event mailing list >>> Id-event@ietf.org >>> https://www.ietf.org/mailman/listinfo/id-event >>=20 From nobody Wed Dec 28 13:37:33 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94B741296A4 for ; Wed, 28 Dec 2016 13:37:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R_2eRZFXpsaI for ; Wed, 28 Dec 2016 13:37:30 -0800 (PST) Received: from mail-wj0-x22c.google.com (mail-wj0-x22c.google.com [IPv6:2a00:1450:400c:c01::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C4FB1296A2 for ; Wed, 28 Dec 2016 13:37:30 -0800 (PST) Received: by mail-wj0-x22c.google.com with SMTP id c11so140652306wjx.3 for ; Wed, 28 Dec 2016 13:37:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version; bh=i3MmPbYe8ij2/MljG+bmO2avrbZ2iwzal4nEhzn+Ofw=; b=lrHwyKQgAWrv/I5Wr8pY9ZX9W1I9dLD6NuQc2Gpg7f3Ywcd2xCbuojo+VOx9PHyxJO 1FXte08q2THT+XZkST1NwYETZSkr+YunM2rRHwxvdhNFOrfrJ/ZtASy0rX2KZAkOfIvJ vdNNLE1Qx5UrVvkHpZ7DZ6+8w3jkizGBN7f2CxRKXtWno+kEAkrBqFc17vLd1RgnTCqw rlozr/ZsryFegSFOK//5B2WjueihPlK5WdDdoPrSUqJnCTtphr6u/8h5jpFHVGaRRzdl X2wb78M9TWzjcJ9CROB6eJD9SQqVzmmzi/P3zclHIc2zbqaZJ3PjlfsCBV426cMoGD19 Rj0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version; bh=i3MmPbYe8ij2/MljG+bmO2avrbZ2iwzal4nEhzn+Ofw=; b=B9Fgoh8pEL2TLDxyd2ECtds9qFazz2iEBqX4hqoOdBrDRWwzglMocjFMn5eYz0Vix5 uVJI8wlqL3sFgzDGB+EKMgNZLW3il5oRahCKVg8devfqxov2hYBXkYfAGCWbT/kngLqO Pm2d8M6cdX+ai4ZttTKVqirO7OrEwOlE0O4lWz0TGofuTrjIFnRiu/SUabc3YpgGHC3c 8g/L+WCKqIwEefrUxK40iievtPueuYSHr4RWU2pzTLdLPRX+6hSLrX5xioQQZ56+sdJF cwTr1UXFHvsVyP/7++YiZyOcJ4VrKEGQRx9vxbUcI/XiZGxTx6BclfERb0PdS5LLL4Hr 1CXA== X-Gm-Message-State: AIkVDXIZarEhTDOiXnlssoqAn6h/7hErKk0jpmm7vo30dcmjOPQkyfMA/CLgIjLwkL12vQ== X-Received: by 10.194.47.203 with SMTP id f11mr35065076wjn.146.1482961048408; Wed, 28 Dec 2016 13:37:28 -0800 (PST) Received: from [10.0.0.13] (bzq-109-65-81-175.red.bezeqint.net. [109.65.81.175]) by smtp.gmail.com with ESMTPSA id gj6sm66028286wjb.29.2016.12.28.13.37.26 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Dec 2016 13:37:27 -0800 (PST) To: ID Events Mailing List From: Yaron Sheffer Message-ID: <6f4b8e65-852a-49e3-dbaf-d3ef5039c7c8@gmail.com> Date: Wed, 28 Dec 2016 23:37:25 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------00527DB714BA493253C80D7F" Archived-At: Subject: [Id-event] Draft adoption X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2016 21:37:31 -0000 This is a multi-part message in MIME format. --------------00527DB714BA493253C80D7F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi everyone, The chairs would like to poll the WG regarding adoption of draft-hunt-idevent-token-07, however we both feel that one more revision would be useful before we do that. We ask the editors to focus this revision on the syntax of the "events" (or "event") JSON structure and how it reflects an event and its extensions. This is to ensure we have a more solid baseline proposal before we start the consensus process. Happy New Year 2017! Dick and Yaron --------------00527DB714BA493253C80D7F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi everyone,

The chairs would like to poll the WG regarding adoption of draft-hunt-idevent-token-07, however we both feel that one more revision would be useful before we do that. We ask the editors to focus this revision on the syntax of the "events" (or "event") JSON structure and how it reflects an event and its extensions. This is to ensure we have a more solid baseline proposal before we start the consensus process.

Happy New Year 2017!

    Dick and Yaron

--------------00527DB714BA493253C80D7F-- From nobody Wed Dec 28 14:03:31 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A012B129705 for ; Wed, 28 Dec 2016 14:03:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.3 X-Spam-Level: X-Spam-Status: No, score=-7.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CAUav1lgoCOi for ; Wed, 28 Dec 2016 14:03:28 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 41A7E1296B7 for ; Wed, 28 Dec 2016 14:03:28 -0800 (PST) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id uBSM3P41009428 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 28 Dec 2016 22:03:26 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.13.8/8.14.4) with ESMTP id uBSM3OiV019989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 28 Dec 2016 22:03:24 GMT Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id uBSM3OrC026262; Wed, 28 Dec 2016 22:03:24 GMT Received: from [192.168.1.18] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 28 Dec 2016 14:03:23 -0800 Content-Type: multipart/alternative; boundary=Apple-Mail-405AB0A5-DDC3-4906-8B4A-61918267A9AF Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (14C92) In-Reply-To: <6f4b8e65-852a-49e3-dbaf-d3ef5039c7c8@gmail.com> Date: Wed, 28 Dec 2016 14:03:22 -0800 Content-Transfer-Encoding: 7bit Message-Id: <67CF49D1-E59E-4297-87FE-EF651C5B0160@oracle.com> References: <6f4b8e65-852a-49e3-dbaf-d3ef5039c7c8@gmail.com> To: Yaron Sheffer X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: ID Events Mailing List Subject: Re: [Id-event] Draft adoption X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2016 22:03:29 -0000 --Apple-Mail-405AB0A5-DDC3-4906-8B4A-61918267A9AF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I propose we have two attributes along the lines of: "evt" a required string URI describing the primary event "ext" an optional multi valued string containing one or more extensions URIs= to the primary event.=20 If agreeable, I will propose some final wording.=20 Note that this is a breaking change and will mean that it will no longer pos= sible to express multiple events about the same state change or observation i= n one JWT unless one is an extension of the other.=20 Because of the dependence issue do we need to also revert back to the IANA e= vent registry proposed in the original drafts? Phil > On Dec 28, 2016, at 1:37 PM, Yaron Sheffer wrote: >=20 > Hi everyone, >=20 > The chairs would like to poll the WG regarding adoption of draft-hunt-idev= ent-token-07, however we both feel that one more revision would be useful be= fore we do that. We ask the editors to focus this revision on the syntax of t= he "events" (or "event") JSON structure and how it reflects an event and its= extensions. This is to ensure we have a more solid baseline proposal before= we start the consensus process. >=20 > Happy New Year 2017! >=20 > Dick and Yaron > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event --Apple-Mail-405AB0A5-DDC3-4906-8B4A-61918267A9AF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I propose we have two attributes along= the lines of:

"evt" a required string URI describing the primary event

"e= xt" an optional multi valued string containing one or more extensions URIs t= o the primary event. 

If agreeable, I will propose some final wo= rding. 

Note that this is a breaking change and will mean that it will= no longer possible to express multiple events about the same state change o= r observation in one JWT unless one is an extension of the other. 

Bec= ause of the dependence issue do we need to also revert back to the IANA even= t registry proposed in the original drafts?

Phil

On Dec 28, 2= 016, at 1:37 PM, Yaron Sheffer <= yaronf.ietf@gmail.com> wrote:

=
=20 =20 =20

Hi everyone,

The chairs would like to poll the WG regarding adoption of draft-hunt-idevent-token-07, however we both feel that one more revision would be useful before we do that. We ask the editors to focus this revision on the syntax of the "events" (or "event") JSON structure and how it reflects an event and its extensions. This is to ensure we have a more solid baseline proposal before we start the consensus process.

Happy New Year 2017!

    Dick and Yaron

=20
____________________= ___________________________
Id-event mailing list
= Id-event@ietf.org
<= span>https://www.= ietf.org/mailman/listinfo/id-event
<= /html>= --Apple-Mail-405AB0A5-DDC3-4906-8B4A-61918267A9AF-- From nobody Wed Dec 28 16:31:57 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09B54129722 for ; Wed, 28 Dec 2016 16:31:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q65i0gaCoirC for ; Wed, 28 Dec 2016 16:31:54 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0122.outbound.protection.outlook.com [104.47.38.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB2FB129694 for ; Wed, 28 Dec 2016 16:31:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=U5E+i0MwHDkrICiMd5cjaQPkeEX05VGsepovF2lzdLQ=; b=ju00C8YmLnfb9q21N/i1xtqB4RiY80blRibbVTlmevxMk+5L81Cu8jJzsquKBoQQCa/rglL4TJFTmdUeklu+OrKNq59U7SsWP2BL6ojrseuFi07mvZMhNhWOoT2Wi7NsdE7XqquQs3Dw+tP+2+LIKdPeSLN54TevmwbnyXXjzNo= Received: from BN3PR03MB2355.namprd03.prod.outlook.com (10.166.74.150) by BN3PR03MB2354.namprd03.prod.outlook.com (10.166.74.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.11; Thu, 29 Dec 2016 00:31:51 +0000 Received: from BN3PR03MB2355.namprd03.prod.outlook.com ([10.166.74.150]) by BN3PR03MB2355.namprd03.prod.outlook.com ([10.166.74.150]) with mapi id 15.01.0803.021; Thu, 29 Dec 2016 00:31:51 +0000 From: Mike Jones To: "Phil Hunt (IDM)" , Yaron Sheffer Thread-Topic: [Id-event] Draft adoption Thread-Index: AQHSYVKcHobL8+E+9ku0U8KcU6BpqqEd6cMAgAAnyCA= Date: Thu, 29 Dec 2016 00:31:51 +0000 Message-ID: References: <6f4b8e65-852a-49e3-dbaf-d3ef5039c7c8@gmail.com> <67CF49D1-E59E-4297-87FE-EF651C5B0160@oracle.com> In-Reply-To: <67CF49D1-E59E-4297-87FE-EF651C5B0160@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.95.25] x-ms-office365-filtering-correlation-id: 16a0664a-42d0-41d9-3675-08d42f82157c x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN3PR03MB2354; x-microsoft-exchange-diagnostics: 1; BN3PR03MB2354; 7:EZGLAlg/VxTz2TC4Q6dC5NDpAD0dybDvaS0RzVaNpVLXEhe+f1px5t0eHZS9m50s1BE7Cg/iipHf5I3mnR65F7T8tO/boS5d+aHs6qECY66ZbgOY8GEFfuZC6C8jwTQEe2SXCGUxd6H28rwluPu9hOKGbhJ9C88QBM34ftkWScHa7cqoPy/+jIFfVwQdpM4awmReggWI7INsQbg2aKF2lI4z/ykacwXudDQcAxPzJfSDp9COIE4f+KIr9vV2dRJb8WX46KK4qgU9HlMAHZC6OG/Ui+o2irz03G+IsUaNvuCfHr0yqDJ9XkWauFyrEph4SQtlUMTC5fnjNaYTi0LqCN0I2bbctWtluD1VAFEC6OcFVNPYhXIJs/WqoTnRktwCMO7uOzCl9YtzL6N8EeqK4oOWI79ojA94SDq0HknxPtSVQU64SKzbrjkBYlkwNsQiddpoZ7JAQA1Z1ilDYTPMCRSrZX+bSbnvkRM73AokKUU= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(100405760836317)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123560025)(20161123564025)(20161123555025)(6047074)(6042181)(6072148); SRVR:BN3PR03MB2354; BCL:0; PCL:0; RULEID:; SRVR:BN3PR03MB2354; x-forefront-prvs: 01713B2841 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(57704003)(53754006)(377454003)(199003)(24454002)(189002)(76576001)(54356999)(38730400001)(8676002)(101416001)(92566002)(81166006)(8936002)(9686002)(66066001)(81156014)(68736007)(4326007)(2906002)(606005)(19609705001)(189998001)(6436002)(229853002)(3660700001)(6506006)(76176999)(39060400001)(25786008)(3280700002)(105586002)(86362001)(7696004)(33656002)(106116001)(97736004)(7906003)(5001770100001)(77096006)(99286002)(2950100002)(5660300001)(55016002)(561944003)(50986999)(2900100001)(5005710100001)(790700001)(122556002)(7736002)(3846002)(8990500004)(74316002)(6116002)(10090500001)(106356001)(10290500002)(102836003)(86612001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR03MB2354; H:BN3PR03MB2355.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR03MB235520DD6B8F7ACFBC1D61F1F56B0BN3PR03MB2355namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Dec 2016 00:31:51.6326 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR03MB2354 Archived-At: Cc: ID Events Mailing List Subject: Re: [Id-event] Draft adoption X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2016 00:31:56 -0000 --_000_BN3PR03MB235520DD6B8F7ACFBC1D61F1F56B0BN3PR03MB2355namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmW0gbm90IGhhcHB5IHdpdGggdGhpcyBwcm9wb3NlZCBjaGFuZ2UuICBJdCBzZWVtcyB0byBi ZSBvdmVybHkgY29tcGxpY2F0aW5nIHdoYXQgd2FzIGZvcm1lcmx5IGEgc2ltcGxlIHN0cnVjdHVy ZS4NCg0KSSBiZWxpZXZlIOKAnGV2ZW50c+KAnSByZW1haW5zIHRoZSByaWdodCBzeW50YXguICBJ dCBhbGxvd3MgbXVsdGlwbGUgcmVsYXRlZCBldmVudHMgdG8gYmUgY2xlYW5seSBleHByZXNzZWQu DQoNClJhdGhlciB0aGFuIHRyeWluZyB0byBkaWZmZXJlbnRpYXRlIGJldHdlZW4g4oCccHJpbWFy eeKAnSBhbmQg4oCcc2Vjb25kYXJ54oCdIGV2ZW50cywgSSB3b3VsZCBjb3VudGVyLXByb3Bvc2Ug dGhhdCB3ZSBkcm9wIHRoZSBkaXN0aW5jdGlvbiBlbnRpcmVseS4gIEFsbCB0aGUgcmVsYXRlZCBl dmVudHMgbGlzdGVkIGluIHRoZSDigJxldmVudHPigJ0gc3RydWN0IG9jY3VycmVkLiAgV2hldGhl ciBvbmUgaXMg4oCccHJpbWFyeeKAnSBpcyBhcmd1YWJseSB1bmltcG9ydGFudCwgc2luY2UgdGhl IGNvbW11bmljYXRpbmcgcGFydGllcyB3aWxsIHByb2Nlc3MgYWxsIHRoZSBpbmZvcm1hdGlvbiBz ZW50IGZvciBhbGwgdGhlIHJlbGF0ZWQgZXZlbnRzLiAgTGV04oCZcyBzaW1wbGlmeSB0aGluZ3Mg YnkgcmVtb3ZpbmcgdGhlIHByaW1hcnkvc2Vjb25kYXJ5IGRpc3RpbmN0aW9uLCByYXRoZXIgdGhh biBjb21wbGljYXRpbmcgdGhpbmdzIGJ5IGhhdmluZyB0d28gcmVsYXRlZCBzeW50YXhlcy4NCg0K SeKAmW0gYWxzbyBnb2luZyB0byByYWlzZSBhIHByb2Nlc3MgcG9pbnQuICBJIGtub3cgdGhhdCBJ IGhhdmVu4oCZdCByZWFkIG9yIHJlc3BvbmRlZCB0byBZYXJvbuKAmXMgY29tbWVudHMgeWV0IGJl Y2F1c2UgdGhleSBjYW1lIGluIGR1cmluZyB0aGUgaG9saWRheXMuICBJIHN1c3BlY3QgdGhpcyBp cyB0cnVlIG9mIG1hbnkgb3RoZXJzIGFzIHdlbGwuICBCZWZvcmUgbWFraW5nIGFueSBicmVha2lu ZyBjaGFuZ2VzLCBJ4oCZZCBhc2sgdGhhdCB3ZSBoYXZlIGEgbGVhc3QgYSB3ZWVr4oCZcyBkaXNj dXNzaW9uIHBlcmlvZCBhZnRlciBKYW51YXJ5IDJuZC4NCg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRoYW5rcywNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206 IElkLWV2ZW50IFttYWlsdG86aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IFBoaWwgSHVudCAoSURNKQ0KU2VudDogV2VkbmVzZGF5LCBEZWNlbWJlciAyOCwgMjAxNiAyOjAz IFBNDQpUbzogWWFyb24gU2hlZmZlciA8eWFyb25mLmlldGZAZ21haWwuY29tPg0KQ2M6IElEIEV2 ZW50cyBNYWlsaW5nIExpc3QgPGlkLWV2ZW50QGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtJZC1l dmVudF0gRHJhZnQgYWRvcHRpb24NCg0KSSBwcm9wb3NlIHdlIGhhdmUgdHdvIGF0dHJpYnV0ZXMg YWxvbmcgdGhlIGxpbmVzIG9mOg0KDQoiZXZ0IiBhIHJlcXVpcmVkIHN0cmluZyBVUkkgZGVzY3Jp YmluZyB0aGUgcHJpbWFyeSBldmVudA0KDQoiZXh0IiBhbiBvcHRpb25hbCBtdWx0aSB2YWx1ZWQg c3RyaW5nIGNvbnRhaW5pbmcgb25lIG9yIG1vcmUgZXh0ZW5zaW9ucyBVUklzIHRvIHRoZSBwcmlt YXJ5IGV2ZW50Lg0KDQpJZiBhZ3JlZWFibGUsIEkgd2lsbCBwcm9wb3NlIHNvbWUgZmluYWwgd29y ZGluZy4NCg0KTm90ZSB0aGF0IHRoaXMgaXMgYSBicmVha2luZyBjaGFuZ2UgYW5kIHdpbGwgbWVh biB0aGF0IGl0IHdpbGwgbm8gbG9uZ2VyIHBvc3NpYmxlIHRvIGV4cHJlc3MgbXVsdGlwbGUgZXZl bnRzIGFib3V0IHRoZSBzYW1lIHN0YXRlIGNoYW5nZSBvciBvYnNlcnZhdGlvbiBpbiBvbmUgSldU IHVubGVzcyBvbmUgaXMgYW4gZXh0ZW5zaW9uIG9mIHRoZSBvdGhlci4NCg0KQmVjYXVzZSBvZiB0 aGUgZGVwZW5kZW5jZSBpc3N1ZSBkbyB3ZSBuZWVkIHRvIGFsc28gcmV2ZXJ0IGJhY2sgdG8gdGhl IElBTkEgZXZlbnQgcmVnaXN0cnkgcHJvcG9zZWQgaW4gdGhlIG9yaWdpbmFsIGRyYWZ0cz8NCg0K UGhpbA0KDQpPbiBEZWMgMjgsIDIwMTYsIGF0IDE6MzcgUE0sIFlhcm9uIFNoZWZmZXIgPHlhcm9u Zi5pZXRmQGdtYWlsLmNvbTxtYWlsdG86eWFyb25mLmlldGZAZ21haWwuY29tPj4gd3JvdGU6DQoN CkhpIGV2ZXJ5b25lLA0KDQpUaGUgY2hhaXJzIHdvdWxkIGxpa2UgdG8gcG9sbCB0aGUgV0cgcmVn YXJkaW5nIGFkb3B0aW9uIG9mIGRyYWZ0LWh1bnQtaWRldmVudC10b2tlbi0wNywgaG93ZXZlciB3 ZSBib3RoIGZlZWwgdGhhdCBvbmUgbW9yZSByZXZpc2lvbiB3b3VsZCBiZSB1c2VmdWwgYmVmb3Jl IHdlIGRvIHRoYXQuIFdlIGFzayB0aGUgZWRpdG9ycyB0byBmb2N1cyB0aGlzIHJldmlzaW9uIG9u IHRoZSBzeW50YXggb2YgdGhlICJldmVudHMiIChvciAiZXZlbnQiKSBKU09OIHN0cnVjdHVyZSBh bmQgaG93IGl0IHJlZmxlY3RzIGFuIGV2ZW50IGFuZCBpdHMgZXh0ZW5zaW9ucy4gVGhpcyBpcyB0 byBlbnN1cmUgd2UgaGF2ZSBhIG1vcmUgc29saWQgYmFzZWxpbmUgcHJvcG9zYWwgYmVmb3JlIHdl IHN0YXJ0IHRoZSBjb25zZW5zdXMgcHJvY2Vzcy4NCg0KSGFwcHkgTmV3IFllYXIgMjAxNyENCg0K ICAgIERpY2sgYW5kIFlhcm9uDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KSWQtZXZlbnQgbWFpbGluZyBsaXN0DQpJZC1ldmVudEBpZXRmLm9yZzxtYWls dG86SWQtZXZlbnRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2lkLWV2ZW50DQo= --_000_BN3PR03MB235520DD6B8F7ACFBC1D61F1F56B0BN3PR03MB2355namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MDAyMDYwIj5J4oCZbSBub3QgaGFwcHkgd2l0aCB0aGlzIHByb3Bvc2VkIGNoYW5nZS4mbmJzcDsg SXQgc2VlbXMgdG8gYmUgb3Zlcmx5IGNvbXBsaWNhdGluZyB3aGF0IHdhcyBmb3JtZXJseSBhIHNp bXBsZSBzdHJ1Y3R1cmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5JIGJl bGlldmUg4oCcZXZlbnRz4oCdIHJlbWFpbnMgdGhlIHJpZ2h0IHN5bnRheC4mbmJzcDsgSXQgYWxs b3dzIG11bHRpcGxlIHJlbGF0ZWQgZXZlbnRzIHRvIGJlIGNsZWFubHkgZXhwcmVzc2VkLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+UmF0aGVyIHRoYW4gdHJ5aW5nIHRvIGRp ZmZlcmVudGlhdGUgYmV0d2VlbiDigJxwcmltYXJ54oCdIGFuZCDigJxzZWNvbmRhcnnigJ0gZXZl bnRzLCBJIHdvdWxkIGNvdW50ZXItcHJvcG9zZSB0aGF0IHdlIGRyb3AgdGhlIGRpc3RpbmN0aW9u IGVudGlyZWx5LiZuYnNwOyBBbGwgdGhlIHJlbGF0ZWQgZXZlbnRzIGxpc3RlZCBpbiB0aGUg4oCc ZXZlbnRz4oCdIHN0cnVjdCBvY2N1cnJlZC4mbmJzcDsgV2hldGhlcg0KIG9uZSBpcyDigJxwcmlt YXJ54oCdIGlzIGFyZ3VhYmx5IHVuaW1wb3J0YW50LCBzaW5jZSB0aGUgY29tbXVuaWNhdGluZyBw YXJ0aWVzIHdpbGwgcHJvY2VzcyBhbGwgdGhlIGluZm9ybWF0aW9uIHNlbnQgZm9yIGFsbCB0aGUg cmVsYXRlZCBldmVudHMuJm5ic3A7IExldOKAmXMgc2ltcGxpZnkgdGhpbmdzIGJ5IHJlbW92aW5n IHRoZSBwcmltYXJ5L3NlY29uZGFyeSBkaXN0aW5jdGlvbiwgcmF0aGVyIHRoYW4gY29tcGxpY2F0 aW5nIHRoaW5ncyBieSBoYXZpbmcgdHdvDQogcmVsYXRlZCBzeW50YXhlcy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2 MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPknigJltIGFsc28gZ29pbmcgdG8gcmFpc2UgYSBwcm9j ZXNzIHBvaW50LiZuYnNwOyBJIGtub3cgdGhhdCBJIGhhdmVu4oCZdCByZWFkIG9yIHJlc3BvbmRl ZCB0byBZYXJvbuKAmXMgY29tbWVudHMgeWV0IGJlY2F1c2UgdGhleSBjYW1lIGluIGR1cmluZyB0 aGUgaG9saWRheXMuJm5ic3A7IEkgc3VzcGVjdCB0aGlzIGlzIHRydWUgb2YgbWFueSBvdGhlcnMg YXMgd2VsbC4mbmJzcDsgQmVmb3JlIG1ha2luZw0KIGFueSBicmVha2luZyBjaGFuZ2VzLCBJ4oCZ ZCBhc2sgdGhhdCB3ZSBoYXZlIGEgbGVhc3QgYSB3ZWVr4oCZcyBkaXNjdXNzaW9uIHBlcmlvZCBh ZnRlciBKYW51YXJ5IDI8c3VwPm5kPC9zdXA+LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoYW5rcyw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0t IE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1l PSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbEVu ZENvbXBvc2UiPjwvc3Bhbj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gSWQtZXZlbnQgW21haWx0bzppZC1ldmVudC1i b3VuY2VzQGlldGYub3JnXSA8Yj4NCk9uIEJlaGFsZiBPZiA8L2I+UGhpbCBIdW50IChJRE0pPGJy Pg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgRGVjZW1iZXIgMjgsIDIwMTYgMjowMyBQTTxicj4N CjxiPlRvOjwvYj4gWWFyb24gU2hlZmZlciAmbHQ7eWFyb25mLmlldGZAZ21haWwuY29tJmd0Ozxi cj4NCjxiPkNjOjwvYj4gSUQgRXZlbnRzIE1haWxpbmcgTGlzdCAmbHQ7aWQtZXZlbnRAaWV0Zi5v cmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbSWQtZXZlbnRdIERyYWZ0IGFkb3B0aW9u PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBwcm9wb3Nl IHdlIGhhdmUgdHdvIGF0dHJpYnV0ZXMgYWxvbmcgdGhlIGxpbmVzIG9mOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNp Z25hdHVyZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mcXVvdDtldnQmcXVvdDsgYSByZXF1aXJl ZCBzdHJpbmcgVVJJIGRlc2NyaWJpbmcgdGhlIHByaW1hcnkgZXZlbnQ8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWdu YXR1cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JnF1b3Q7ZXh0JnF1b3Q7IGFuIG9wdGlvbmFs IG11bHRpIHZhbHVlZCBzdHJpbmcgY29udGFpbmluZyBvbmUgb3IgbW9yZSBleHRlbnNpb25zIFVS SXMgdG8gdGhlIHByaW1hcnkgZXZlbnQuJm5ic3A7PGJyPg0KPGJyPg0KSWYgYWdyZWVhYmxlLCBJ IHdpbGwgcHJvcG9zZSBzb21lIGZpbmFsIHdvcmRpbmcuJm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0 dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5vdGUgdGhhdCB0aGlzIGlzIGEgYnJlYWtpbmcg Y2hhbmdlIGFuZCB3aWxsIG1lYW4gdGhhdCBpdCB3aWxsIG5vIGxvbmdlciBwb3NzaWJsZSB0byBl eHByZXNzIG11bHRpcGxlIGV2ZW50cyBhYm91dCB0aGUgc2FtZSBzdGF0ZSBjaGFuZ2Ugb3Igb2Jz ZXJ2YXRpb24gaW4gb25lIEpXVCB1bmxlc3Mgb25lIGlzIGFuIGV4dGVuc2lvbiBvZiB0aGUgb3Ro ZXIuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25h dHVyZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJl Y2F1c2Ugb2YgdGhlIGRlcGVuZGVuY2UgaXNzdWUgZG8gd2UgbmVlZCB0byBhbHNvIHJldmVydCBi YWNrIHRvIHRoZSBJQU5BIGV2ZW50IHJlZ2lzdHJ5IHByb3Bvc2VkIGluIHRoZSBvcmlnaW5hbCBk cmFmdHM/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVy ZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBoaWw8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KT24gRGVjIDI4LCAyMDE2LCBhdCAxOjM3IFBN LCBZYXJvbiBTaGVmZmVyICZsdDs8YSBocmVmPSJtYWlsdG86eWFyb25mLmlldGZAZ21haWwuY29t Ij55YXJvbmYuaWV0ZkBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPHA+SGkgZXZlcnlvbmUsPG86cD48L286cD48L3A+DQo8cD5UaGUgY2hh aXJzIHdvdWxkIGxpa2UgdG8gcG9sbCB0aGUgV0cgcmVnYXJkaW5nIGFkb3B0aW9uIG9mIGRyYWZ0 LWh1bnQtaWRldmVudC10b2tlbi0wNywgaG93ZXZlciB3ZSBib3RoIGZlZWwgdGhhdCBvbmUgbW9y ZSByZXZpc2lvbiB3b3VsZCBiZSB1c2VmdWwgYmVmb3JlIHdlIGRvIHRoYXQuIFdlIGFzayB0aGUg ZWRpdG9ycyB0byBmb2N1cyB0aGlzIHJldmlzaW9uIG9uIHRoZSBzeW50YXggb2YgdGhlICZxdW90 O2V2ZW50cyZxdW90OyAob3IgJnF1b3Q7ZXZlbnQmcXVvdDspIEpTT04NCiBzdHJ1Y3R1cmUgYW5k IGhvdyBpdCByZWZsZWN0cyBhbiBldmVudCBhbmQgaXRzIGV4dGVuc2lvbnMuIFRoaXMgaXMgdG8g ZW5zdXJlIHdlIGhhdmUgYSBtb3JlIHNvbGlkIGJhc2VsaW5lIHByb3Bvc2FsIGJlZm9yZSB3ZSBz dGFydCB0aGUgY29uc2Vuc3VzIHByb2Nlc3MuPG86cD48L286cD48L3A+DQo8cD5IYXBweSBOZXcg WWVhciAyMDE3ITxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyBEaWNrIGFuZCBZYXJvbjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCklkLWV2ZW50IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpJZC1ldmVu dEBpZXRmLm9yZyI+SWQtZXZlbnRAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudCI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BN3PR03MB235520DD6B8F7ACFBC1D61F1F56B0BN3PR03MB2355namp_-- From nobody Wed Dec 28 18:49:44 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6D16129793 for ; Wed, 28 Dec 2016 18:49:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.3 X-Spam-Level: X-Spam-Status: No, score=-7.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aDY4uiKQJkMm for ; Wed, 28 Dec 2016 18:49:41 -0800 (PST) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (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 7B1B212953B for ; Wed, 28 Dec 2016 18:49:41 -0800 (PST) X-AuditID: 12074424-1c3ff70000002eee-44-586479c39840 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 33.0B.12014.3C974685; Wed, 28 Dec 2016 21:49:40 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id uBT2nclm022268; Wed, 28 Dec 2016 21:49:38 -0500 Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id uBT2naNg024053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 28 Dec 2016 21:49:37 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_3C719820-72E3-4C69-8CD6-BDC41D3551D0" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Justin Richer In-Reply-To: <67CF49D1-E59E-4297-87FE-EF651C5B0160@oracle.com> Date: Wed, 28 Dec 2016 21:49:36 -0500 Message-Id: References: <6f4b8e65-852a-49e3-dbaf-d3ef5039c7c8@gmail.com> <67CF49D1-E59E-4297-87FE-EF651C5B0160@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.3124) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphleLIzCtJLcpLzFFi42IRYrdT0T1SmRJhcHGCvEXHgm4miwXzG9kt Vt2fwe7A7LFz1l12jyVLfjJ5fHx6iyWAOYrLJiU1J7MstUjfLoEr40F3I1vBEf+KU/tXsTcw nnfuYuTkkBAwkfi08hVzFyMXh5BAG5NE74QTrBDORkaJHydnM4NUCQk8ZJJ4dkISxGYWSJD4 vGIDC4jNK6AnsWn9W6YuRg4OYQE1ibVXlEDCbAKqEtPXtICFOQXsJFr6dEDCLEDhpYfeMkJM iZM4caiRCWKKlcTflo1Qm/IkTqzZBxYXEVCR+Hb1OiPEnbIST04uYpnAyD8LyRGzkBwBEdeW WLbwNTOErSmxv3s5C6a4hkTnt4msCxjZVjHKpuRW6eYmZuYUpybrFicn5uWlFuma6+Vmluil ppRuYgQHuovKDsbuHu9DjAIcjEo8vBIyKRFCrIllxZW5hxglOZiURHlrRIBCfEn5KZUZicUZ 8UWlOanFhxglOJiVRHj3VgDleFMSK6tSi/JhUtIcLErivJcy3SOEBNITS1KzU1MLUotgsjIc HEoSvH68QI2CRanpqRVpmTklCGkmDk6Q4TxAwzvAhhcXJOYWZ6ZD5E8xKkqJ82aDJARAEhml eXC9oESU8Paw6StGcaBXhHnrQap4gEkMrvsV0GAmoMFqOckgg0sSEVJSDYzxE03WT9u6QLRz UaSquMu5a4dfrHs88XOn7JWGbcH9cy/U5LFdanMIVvjJKO381vvpZnZNdq3N0ycz7Wwr+z7v fOeqTykCl7S/MLRJOghyTZVcabzf+m6M+JR1p7/0Z1zKPBQsv05s+fkl7d8VXK1EWzY9Dz/D 4m12sedZ7IaOVzmiVxO3v49VYinOSDTUYi4qTgQAx9URIx8DAAA= Archived-At: Cc: Yaron Sheffer , ID Events Mailing List Subject: Re: [Id-event] Draft adoption X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2016 02:49:43 -0000 --Apple-Mail=_3C719820-72E3-4C69-8CD6-BDC41D3551D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 -1 to this proposed new syntax. I rather like the simplified structure = of: =E2=80=9Cevents": { =E2=80=9Cevent1:foo:bar=E2=80=9D: {=E2=80=9Ceventstuff=E2=80=9D:=E2=80=9D= goes here=E2=80=9D} =E2=80=9Cevent2:foo:bar=E2=80=9D: {=E2=80=9Cother event stuff=E2=80=9D: = =E2=80=9Cgoes here too=E2=80=9D, =E2=80=9Cright?=E2=80=9D: true} =E2=80=9Cevent3:this:one:is:empty=E2=80=9D: {} } I don=E2=80=99t like the idea of core events and extensions and all that = =E2=80=94 I think it makes things more complicated than necessary. Each = thing inside the =E2=80=9Cevents=E2=80=9D object should be about itself. = If you want to extend it, then it=E2=80=99s up to you whether to use the = sub-object (since JSON is schema-by-fiat you can usually get away with = it in the real world) or have a parallel data structure as another = =E2=80=9Cevent=E2=80=9D next to it. But it=E2=80=99s up to your = application as to how that works. So we should drop the notion of = primary and secondary and core and extension entirely =E2=80=94 you=E2=80=99= ve just got a list of event objects, each lives in its own namespace.=20 What we can do here is say that everything in the =E2=80=9Cevents=E2=80=9D= object is related to each other in some fashion, and that fashion = should be discoverable by looking at the envelope information in the = root claims. We can *also* provide guidance for what kinds of things go = inside those so that people aren=E2=80=99t constantly making up new = terms to mean the same thing across different events. For example, all = the core JWT claims should have a similar meaning inside an event = object, which itself is nestled inside the =E2=80=9Cevents=E2=80=9D = collection in the JWT. That said, I=E2=80=99m not against shortening =E2=80=9Cevents=E2=80=9D = to =E2=80=9Cevt=E2=80=9D to fit with other JWT tln's. And as much as = Mike loves the explicit plural, I dislike =E2=80=9Cevs=E2=80=9D or = =E2=80=9Cets=E2=80=9D or something like that if we=E2=80=99re doing = three letters. If we keep it long, =E2=80=9Cevents=E2=80=9D is fine with = me. =E2=80=94 Justin > On Dec 28, 2016, at 5:03 PM, Phil Hunt (IDM) = wrote: >=20 > I propose we have two attributes along the lines of: >=20 > "evt" a required string URI describing the primary event >=20 > "ext" an optional multi valued string containing one or more = extensions URIs to the primary event.=20 >=20 > If agreeable, I will propose some final wording.=20 >=20 > Note that this is a breaking change and will mean that it will no = longer possible to express multiple events about the same state change = or observation in one JWT unless one is an extension of the other.=20 >=20 > Because of the dependence issue do we need to also revert back to the = IANA event registry proposed in the original drafts? >=20 > Phil >=20 > On Dec 28, 2016, at 1:37 PM, Yaron Sheffer > wrote: >=20 >> Hi everyone, >>=20 >> The chairs would like to poll the WG regarding adoption of = draft-hunt-idevent-token-07, however we both feel that one more revision = would be useful before we do that. We ask the editors to focus this = revision on the syntax of the "events" (or "event") JSON structure and = how it reflects an event and its extensions. This is to ensure we have a = more solid baseline proposal before we start the consensus process. >>=20 >> Happy New Year 2017! >>=20 >> Dick and Yaron >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event = > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event --Apple-Mail=_3C719820-72E3-4C69-8CD6-BDC41D3551D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 -1 to this proposed new syntax. I rather like the simplified = structure of:

=E2=80=9Cevents": {
 =E2=80=9Cevent1:foo:bar=E2=80=9D: = {=E2=80=9Ceventstuff=E2=80=9D:=E2=80=9Dgoes here=E2=80=9D}
 =E2=80=9Cevent2:foo:bar=E2=80=9D: {=E2=80=9Cother event = stuff=E2=80=9D: =E2=80=9Cgoes here too=E2=80=9D, =E2=80=9Cright?=E2=80=9D:= true}
 =E2=80=9Cevent3:this:one:is:empty=E2=80=9D= : {}
}

I don=E2=80=99t like the idea of core events and extensions = and all that =E2=80=94 I think it makes things more complicated than = necessary. Each thing inside the =E2=80=9Cevents=E2=80=9D object should = be about itself. If you want to extend it, then it=E2=80=99s up to you = whether to use the sub-object (since JSON is schema-by-fiat you can = usually get away with it in the real world) or have a parallel data = structure as another =E2=80=9Cevent=E2=80=9D next to it. But it=E2=80=99s = up to your application as to how that works. So we should drop the = notion of primary and secondary and core and extension entirely =E2=80=94 = you=E2=80=99ve just got a list of event objects, each lives in its own = namespace. 

What we can do here is say that everything in the = =E2=80=9Cevents=E2=80=9D object is related to each other in some = fashion, and that fashion should be discoverable by looking at the = envelope information in the root claims. We can *also* provide guidance = for what kinds of things go inside those so that people aren=E2=80=99t = constantly making up new terms to mean the same thing across different = events. For example, all the core JWT claims should have a similar = meaning inside an event object, which itself is nestled inside the = =E2=80=9Cevents=E2=80=9D collection in the JWT.

That said, I=E2=80=99m not against = shortening =E2=80=9Cevents=E2=80=9D to =E2=80=9Cevt=E2=80=9D to fit with = other JWT tln's. And as much as Mike loves the explicit plural, I = dislike =E2=80=9Cevs=E2=80=9D or =E2=80=9Cets=E2=80=9D or something like = that if we=E2=80=99re doing three letters. If we keep it long, = =E2=80=9Cevents=E2=80=9D is fine with me.

 =E2=80=94 Justin

On Dec 28, 2016, at 5:03 PM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:

I propose we = have two attributes along the lines of:

"evt" a required string URI describing = the primary event

"ext" an optional multi valued string containing one or more = extensions URIs to the primary event. 

If agreeable, I will propose some final = wording. 

Note that this is a breaking change and will mean that it = will no longer possible to express multiple events about the same state = change or observation in one JWT unless one is an extension of the = other. 

Because of the dependence issue do we need to also revert = back to the IANA event registry proposed in the original = drafts?

Phil

On Dec 28, 2016, at = 1:37 PM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

Hi everyone,

The chairs would like to poll = the WG regarding adoption of draft-hunt-idevent-token-07, however we both feel that one more revision would be useful before we do that. We ask the editors to focus this revision on the syntax of the "events" (or "event") JSON structure and how it reflects an event and its extensions. This is to ensure we have a more solid baseline proposal before we start the consensus process.

Happy New Year = 2017!

    Dick and Yaron

=20
_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event
______________________________________= _________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event

= --Apple-Mail=_3C719820-72E3-4C69-8CD6-BDC41D3551D0-- From nobody Thu Dec 29 08:39:23 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7786112960C for ; Thu, 29 Dec 2016 08:39:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y65Lq1twxFcR for ; Thu, 29 Dec 2016 08:39:20 -0800 (PST) Received: from mail-pg0-x241.google.com (mail-pg0-x241.google.com [IPv6:2607:f8b0:400e:c05::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DAA4129605 for ; Thu, 29 Dec 2016 08:39:20 -0800 (PST) Received: by mail-pg0-x241.google.com with SMTP id g1so19398413pgn.0 for ; Thu, 29 Dec 2016 08:39:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=M7/mpb79KLXH8H0WgyPG+ky7Sryp96PUADX0FgxnfFs=; b=lcWWfwxVyhGabhD1zJJgSMy3hBQXo+CnSWuWadwX2Op2Ue1k59+KvsWT5TF6QdpGUD F3MwkSyuFLB8sbqcmOY63uImTJFsEctO8mbS5LWEp1OAgEbRXIKVyGR3M8SRPiVCFrwD aCYnuFlDDblXeVykgrz5156uASpYR1dFaMUK0ycKnnSocdoKHTqdyrHVlp7g6A6L5LOI uuOnVdv1/S2IKdACFFB4WzA3TKcWnKa33xMBaEZn9AWRKyS4gid27L/KX13tLGquR+h+ 80iMdks8C407/kMRwWMETh7B9+CTGsTusaVRwqmTSB3kZbFaRidIqG39dUuCpdWw7kGT jm8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=M7/mpb79KLXH8H0WgyPG+ky7Sryp96PUADX0FgxnfFs=; b=DuIBjjxCxHdBZ3qu9+GhQgWbKzReXRSYIjYPGaZ4QkdDh36QUknlVZS11epsPhOOLw Z1VM2pAaEE/UElEdIN4Mzq1J7G5uySAWrJDNI3NL6oA9kkWDnlpmw32CwrRcekjKmqIo rIXlNYoBf0ERIJeedxn2GhAi6qMsHOG3SDHkuecoWK1DXFPijpGjL62ZGhb6K9qdLaop BFYqF4MNaD5gl1hn4EaVtoqTiaHtpMUaAckyZaQkoK2KQCGXDRJQlv3AC0nzuC2YZyFg Yu7bq3HpaYkZA2dTymn9zJi03yCMrY1Kv1W8mdF6zH+iMVtLj1R1sRGhBy0dk1PkYtAS HRFA== X-Gm-Message-State: AIkVDXIA1QEckJGO1efjZfbUyjz902dkQ2SaBwNOwqVK7XkYP3sN/9giYk/Byr3M3xvbOw== X-Received: by 10.84.129.111 with SMTP id 102mr91613677plb.103.1483029559274; Thu, 29 Dec 2016 08:39:19 -0800 (PST) Received: from [172.18.133.122] (cowboy2.intuit.com. [65.204.229.12]) by smtp.gmail.com with ESMTPSA id z29sm80321689pgc.11.2016.12.29.08.39.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Dec 2016 08:39:17 -0800 (PST) To: Mike Jones , "Phil Hunt (IDM)" References: <6f4b8e65-852a-49e3-dbaf-d3ef5039c7c8@gmail.com> <67CF49D1-E59E-4297-87FE-EF651C5B0160@oracle.com> From: Yaron Sheffer Message-ID: Date: Thu, 29 Dec 2016 18:39:13 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: ID Events Mailing List Subject: Re: [Id-event] Draft adoption X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2016 16:39:21 -0000 Hi Mike, (chair hat on): I'm absolutely OK with your process proposal. (hat off): Excuse for for being pedantic about JSON syntax. If we want to support multiple events, this should be an array, not an object. This indicates an ordering between events, and also allows clean handling of multiple events of the same type. I will let others decide whether we need a single event per SET or multiple. Thanks, Yaron On 29/12/16 02:31, Mike Jones wrote: > I’m not happy with this proposed change. It seems to be overly > complicating what was formerly a simple structure. > > > > I believe “events” remains the right syntax. It allows multiple related > events to be cleanly expressed. > > > > Rather than trying to differentiate between “primary” and “secondary” > events, I would counter-propose that we drop the distinction entirely. > All the related events listed in the “events” struct occurred. Whether > one is “primary” is arguably unimportant, since the communicating > parties will process all the information sent for all the related > events. Let’s simplify things by removing the primary/secondary > distinction, rather than complicating things by having two related syntaxes. > > > > I’m also going to raise a process point. I know that I haven’t read or > responded to Yaron’s comments yet because they came in during the > holidays. I suspect this is true of many others as well. Before making > any breaking changes, I’d ask that we have a least a week’s discussion > period after January 2^nd . > > > > Thanks, > > -- Mike > > > > *From:* Id-event [mailto:id-event-bounces@ietf.org] *On Behalf Of *Phil > Hunt (IDM) > *Sent:* Wednesday, December 28, 2016 2:03 PM > *To:* Yaron Sheffer > *Cc:* ID Events Mailing List > *Subject:* Re: [Id-event] Draft adoption > > > > I propose we have two attributes along the lines of: > > > > "evt" a required string URI describing the primary event > > > > "ext" an optional multi valued string containing one or more extensions > URIs to the primary event. > > If agreeable, I will propose some final wording. > > > > Note that this is a breaking change and will mean that it will no longer > possible to express multiple events about the same state change or > observation in one JWT unless one is an extension of the other. > > > > Because of the dependence issue do we need to also revert back to the > IANA event registry proposed in the original drafts? > > > > Phil > > > On Dec 28, 2016, at 1:37 PM, Yaron Sheffer > wrote: > > Hi everyone, > > The chairs would like to poll the WG regarding adoption of > draft-hunt-idevent-token-07, however we both feel that one more > revision would be useful before we do that. We ask the editors to > focus this revision on the syntax of the "events" (or "event") JSON > structure and how it reflects an event and its extensions. This is > to ensure we have a more solid baseline proposal before we start the > consensus process. > > Happy New Year 2017! > > Dick and Yaron > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > From nobody Thu Dec 29 11:47:32 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 612CB1294CA for ; Thu, 29 Dec 2016 11:47:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYJ6DYys94FB for ; Thu, 29 Dec 2016 11:47:28 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0119.outbound.protection.outlook.com [104.47.34.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6656512944A for ; Thu, 29 Dec 2016 11:47:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jUu6hHy6O4g/sD1MNjeUDZAzst4/VxRQim7FgPPfd94=; b=BNbFiIxsNkKNLMZYIYvjB9AeJFFs+Vjdimx2x0l053EQklol2QU/0thIZtpDlU+kJhKaM2muszmfhJ4msGqRfa91sqj5z1Qx9eEMxaJwKvJMS8CVKjn0Y0TdV7E6Aqu9XJsO+oRwUX0i51rKhtlcsOxlo5vJ2aLGFgncnQbb5XM= Received: from BN3PR03MB2355.namprd03.prod.outlook.com (10.166.74.150) by BN3PR03MB2353.namprd03.prod.outlook.com (10.166.74.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.11; Thu, 29 Dec 2016 19:47:23 +0000 Received: from BN3PR03MB2355.namprd03.prod.outlook.com ([10.166.74.150]) by BN3PR03MB2355.namprd03.prod.outlook.com ([10.166.74.150]) with mapi id 15.01.0803.021; Thu, 29 Dec 2016 19:47:24 +0000 From: Mike Jones To: Yaron Sheffer , SecEvent Thread-Topic: [Id-event] Some comments to draft-hunt-idevent-token-07 Thread-Index: AQHSUyxOjIY+pknIPU+y0NA2aRWa0aEeRrHw Date: Thu, 29 Dec 2016 19:47:23 +0000 Message-ID: References: <9114f681-cba9-b6d3-8369-ccd9193ce1b8@gmail.com> In-Reply-To: <9114f681-cba9-b6d3-8369-ccd9193ce1b8@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.95.25] x-ms-office365-filtering-correlation-id: 544e0336-a948-434c-2906-08d4302382b1 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN3PR03MB2353; x-microsoft-exchange-diagnostics: 1; BN3PR03MB2353; 7:gRwQwFX/KJodF/Ja+/8uspRmD/PjdX/E2BBApKbVncXnkgfKHDeXE4xhm2FIewHTWh2g5tcfmXJhLTIOHlJf5V/O2xEnUYcx5O0b7lzSCZtHar9Es3/peBwR96bbPB/ZQ14YvlgfvuRUwPQeOpHjkICa85gTDilsTg8dUamigvPAnqUb5/RPDtBlZ3UtjsUGD8CCWo1L+sRKT971B+CLwBFi7rEjJe1q9tu883xgr8htLDIM4ALFzrCPLFyrsbieK5YCUZ9a4hzyi3RkYlZhby/rhDo7WwSShdCL/KHyRAgcn+q8I70KVhfh38/s8v9pHrkdlpVoXQmDgo8YjYyV2P0JZvYG7ehe6/mtjmDJ6qSK2IY61vZodB6XNFDVvyLOLpLMJvhRM/YSW0OZ/jn1qEo9IzOQeCMus/2ST9IjEOxxSeyaPKxt4S3KNaPgjB6wr7Vuzv9CrMZ4zEK78pobtGECCM+i9Hj1x1ovQJSuSDA= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(192374486261705)(100405760836317)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123560025)(20161123564025)(20161123555025)(6047074)(6072148); SRVR:BN3PR03MB2353; BCL:0; PCL:0; RULEID:; SRVR:BN3PR03MB2353; x-forefront-prvs: 01713B2841 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39840400002)(39410400002)(39860400002)(39450400003)(39850400002)(377454003)(43784003)(199003)(189002)(66066001)(105586002)(6506006)(68736007)(10290500002)(38730400001)(5001770100001)(39060400001)(3660700001)(33656002)(7696004)(8990500004)(551544002)(106356001)(92566002)(229853002)(2950100002)(99286003)(74316002)(7736002)(5660300001)(7906003)(106116001)(77096006)(25786008)(6436002)(230783001)(55016002)(606005)(81156014)(50986999)(76176999)(4326007)(54356999)(97736004)(86612001)(86362001)(8936002)(102836003)(5005710100001)(3280700002)(9686002)(122556002)(6116002)(790700001)(10090500001)(81166006)(2900100001)(189998001)(101416001)(3846002)(2906002)(8676002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR03MB2353; H:BN3PR03MB2355.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR03MB2355F10CCD751A2B3FD03F9AF56B0BN3PR03MB2355namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Dec 2016 19:47:23.8497 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR03MB2353 Archived-At: Cc: Phil Hunt Subject: Re: [Id-event] Some comments to draft-hunt-idevent-token-07 X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2016 19:47:31 -0000 --_000_BN3PR03MB2355F10CCD751A2B3FD03F9AF56B0BN3PR03MB2355namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmW0gcmVwbHlpbmcgdG8gWWFyb27igJlzIG9yaWdpbmFsIG1lc3NhZ2Ugc28gdGhlIHJlc3Vs dCB3aWxsIGJlIHNob3J0IGVub3VnaCB0byBiZSBxdWlja2x5IHJlYWRhYmxlLCB3aGlsZSBhY2tu b3dsZWRnaW5nIHRoYXQgUGhpbCBhbHJlYWR5IG1hZGUgbWFueSBwb2ludHMgaW4gaGlzIHJlc3Bv bnNlcyB0aGF0IEkgYWdyZWUgd2l0aC4gIFdoZXJlIEkgZG9u4oCZdCBoYXZlIGFueXRoaW5nIHRv IGFkZCB0byBQaGls4oCZcyByZXNwb25zZXMsIEkgZG9u4oCZdCBpbmNsdWRlIGEgcmVzcG9uc2Ug dG8gdGhvc2UgcG9pbnRzLiAgTXkgcmVwbGllcyBhcmUgcHJlZml4ZWQgYnkg4oCcTWlrZT7igJ0u DQoNClRoYW5rcyBmb3IgdGFraW5nIHRoZSB0aW1lIHRvIGRvIGEgdGhvcm91Z2ggcmVhZCwgWWFy b24hDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAtLSBNaWtlDQoNCkZyb206IElkLWV2ZW50IFttYWlsdG86aWQtZXZlbnQtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIFlhcm9uIFNoZWZmZXINClNlbnQ6IFNhdHVyZGF5LCBEZWNl bWJlciAxMCwgMjAxNiAxOjI4IFBNDQpUbzogU2VjRXZlbnQgPGlkLWV2ZW50QGlldGYub3JnPg0K U3ViamVjdDogW0lkLWV2ZW50XSBTb21lIGNvbW1lbnRzIHRvIGRyYWZ0LWh1bnQtaWRldmVudC10 b2tlbi0wNw0KDQoNCkhpLCBJIGZpbmFsbHkgcmVhZCB0aGUgZHJhZnQgaW4gZGV0YWlsLCBhbmQg SSBkbyBoYXZlIGEgZmV3IGNvbW1lbnRzLg0KDQpNeSBtYWluIHN1Z2dlc3Rpb24gaXMgdG8gdGln aHRlbiB0aGUgc3BlY2lmaWNhdGlvbiBvZiBhbiBFdmVudCwgYnkgZGVmaW5pbmcgbW9yZSBzdHJp Y3RseSB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuICJldmVudCIgYW5kICJldmVudCBleHRlbnNpb24i IGFuZCB0d2Vha2luZyB0aGUgSlNPTiBzdHJ1Y3R1cmUgYSBiaXQuDQoNCg0KDQpNaWtlPiBQZXIg bXkgcmVwbHkgaW4gdGhlIHRocmVhZCDigJxbSWQtZXZlbnRdIERyYWZ0IGFkb3B0aW9u4oCdLCBJ IHRoaW5rIHdl4oCZZCBiZSBiZXR0ZXIgb2ZmIGNvbXBsZXRlbHkgZHJvcHBpbmcgdGhlIGRpc3Rp bmN0aW9uIGJldHdlZW4gcHJpbWFyeSBldmVudHMgYW5kIHNlY29uZGFyeSBldmVudHMuICBXaGVu IGFwcGxpY2F0aW9ucyBzZW5kIGEgc2V0IG9mIHJlbGF0ZWQgZXZlbnRzIHRvZ2V0aGVyLCBpdOKA mXMgbG9naWNhbCBmb3IgcmVjaXBpZW50cyB0byBwcm9jZXNzIGFsbCBvZiB0aGVtIChvciBhbGwg b2YgdGhlbSB0aGF0IHRoZXkgdW5kZXJzdGFuZCkuICBUaGUgcHJpbWFyeS9zZWNvbmRhcnkgZGlz dGluY3Rpb24gaXMgdW5oZWxwZnVsIGFuZCBsZWFkcyB0byBjb21wbGljYXRpb24sIHJhdGhlciB0 aGFuIGNsYXJpdHkgb3Igc2ltcGxpZmljYXRpb24uICBMZXTigJlzIGRyb3AgaXQgZW50aXJlbHku DQoNCg0KDQpJbiBhZGRpdGlvbiwgSSB0aGluayB3ZSBzaG91bGQgcmVxdWlyZSB0aGUgY2xhaW0g dG8gYmUgc2lnbmVkLCBzaW5jZSBpdCB3aWxsIGJlIHVzZWQgZm9yIHNlY3VyaXR5LXNlbnNpdGl2 ZSBhY3Rpdml0aWVzIGFjcm9zcyBjb21wbGV4IGRpc3RyaWJ1dGVkIHN5c3RlbXMuDQoNCiAgKiAg IDE6IFdoeSBpcyBzaWduaW5nIG9wdGlvbmFsPyBUaGUgcHVibGlzaGVyIGRvZXNuJ3Qga25vdyBo b3cgdGhlIHN1YnNjcmliZXIncyBzeXN0ZW0gaXMgYXJjaGl0ZWN0ZWQsIGFuZCBtaWdodCB3ZWxs IHdhbnQgZW5kLXRvLWVuZCBhdXRoZW50aWNhdGlvbiBvZiB0aGUgY2xhaW0uIFRoaXMgaXMgYWxz byBpbXBvcnRhbnQgZm9yIGF1ZGl0aW5nLg0KDQpNaWtlPiBUaGlzIGlzIGdyb3VuZCBhbHJlYWR5 IHdlbGwtY292ZXJlZCBkdXJpbmcgYm90aCB0aGUgSk9TRSBbUkZDIDc1MTVdIGFuZCBKV1QgW1JG QyA3NTE5XSBzdGFuZGFyZGl6YXRpb24gZWZmb3J0cy4gIFRoZSBrZXkgb2JzZXJ2YXRpb24gaXMg dGhhdCBKV1QgKGFuZCBTRVQpIGlzIGEgZGF0YSBzdHJ1Y3R1cmUgdG8gYmUgdXNlZCBpbiBwcm90 b2NvbHMgYW5kIGFwcGxpY2F0aW9ucyDigJMgbm90IGEgcHJvdG9jb2wgb3IgYXBwbGljYXRpb24g c3BlY2lmaWNhdGlvbi4gIEl04oCZcyB1cCB0byBwcm90b2NvbCBhbmQgYXBwbGljYXRpb24gc3Bl Y2lmaWNhdGlvbnMgdG8gZGVmaW5lIHdoZXRoZXIgc2lnbmluZyBpcyBuZWVkZWQgKGFuZCBpZiBz bywgd2l0aCB3aGF0IGFsZ29yaXRobXMpLiAgSW4gc29tZSBjYXNlcywgaXQgd29u4oCZdCBiZSBu ZWVkZWQgYmVjYXVzZSB0aGUgSldUL1NFVCBpcyBhbHJlYWR5IGludGVncml0eSBwcm90ZWN0ZWQg YnkgdGhlIHByb3RvY29sIG9yIGFwcGxpY2F0aW9uIOKAkyBmb3IgaW5zdGFuY2UsIGJ5IFRMUy4g IEp1c3QgbGlrZSBmb3IgSldULCB3ZSBzaG91bGRu4oCZdCByZXF1aXJlIHNpZ25pbmcgaW4gY2Fz ZXMgdGhhdCBpdCBhZGRzIG5vIHZhbHVlIGJ1dCBkb2VzIGFkZCBvdmVyaGVhZC4gIEEgd29ya2lu ZyBncm91cCBjb25zZW5zdXMgY2FsbCBjb25maXJtZWQgdGhlIG5lZWQgZm9yIHRoZSBhYmlsaXR5 IHRvIHVzZSDigJxhbGfigJ064oCcbm9uZeKAnSBmb3IgSldTIG9iamVjdHMuDQoNCg0KICAqICAg MTogImV4YW1wbGUgZXZlbnRzIiAtIGlzIHNwZWNpZmljYXRpb24gb2YgaW5kaXZpZHVhbCBldmVu dHMgKG1heWJlIG9ubHkgYSBmZXcgYmFzaWMgb25lcykgd2l0aGluIHNjb3BlIG9mIG91ciBjaGFy dGVyPyBPdGhlcndpc2Ugd2UgY2Fubm90IGd1YXJhbnRlZSBpbnRlcm9wLg0KDQpNaWtlPiBJIGFn cmVlIHdpdGggUGhpbOKAmXMgcmVzcG9uc2UgdGhhdCBpbnRlcm9wIGhhcHBlbnMgd2l0aGluIGFw cGxpY2F0aW9ucyBhbmQgcHJvdG9jb2xzIHVzaW5nIFNFVHMuDQoNCg0KICAqICAgMS4yOiBwcmlu Y2lwbGUgLT4gcHJpbmNpcGFsDQogICogICAyOiAiZmlyc3QgdmFsdWUiIGlzIG1lYW5pbmdsZXNz LiBKU09OIG9iamVjdHMgYXJlIHVub3JkZXJlZCAoNHRoIHBhcmFncmFwaCBvZiBSRkMgNzE1OSku IElmIG9yZGVyIGlzIGltcG9ydGFudCwgd2UgY291bGQgbWFrZSAiZXZlbnRzIiBpbnRvIGFuIGFy cmF5Lg0KDQpNaWtlPiBPcmRlciBpcyB1bmltcG9ydGFudC4gIFRoaXMgd2FzIGFscmVhZHkgd2lk ZWx5IGRpc2N1c3NlZCBvbiB0aGUgaWQtZXZlbnQgbGlzdC4gIFdoaWxlIHdlIHVzZWQgdG8gdXNl IGFuIGFycmF5IHJlcHJlc2VudGF0aW9uLCBhIGNvbnNjaW91cyBjaG9pY2Ugd2FzIG1hZGUgdG8g bW92ZSB0byB0aGUgY3VycmVudCDigJxzZXQgb2YgZXZlbnRz4oCdIHN5bnRheCwgcmVwbGFjaW5n IHRoZSBvbGQg4oCcYXJyYXkgb2YgZXZlbnRz4oCdIHN5bnRheC4NCg0KDQogICogICAyOiBldmVu dCBleHRlbnNpb25zIGFyZSBub3QgZGVmaW5lZCBidXQgb25seSBpbnRyb2R1Y2VkIGJ5IHRoZSB0 ZXh0IGFmdGVyIHRoZXkgYXJlIGRlc2NyaWJlZC4gQWxzbywgaW4gdGhlIGV4YW1wbGUgdGhlcmUn cyB0aGlzIFVSTDogaHR0cHM6Ly/igItleGFtcGxlLuKAi2NvbS/igItzY2ltL+KAi2V2ZW50L+KA i3Bhc+KAi3N3b3LigItkUmVz4oCLZXRFeOKAi3QgLSBJIGJlbGlldmUgaXQgbmVlZHMgdG8gYmUg cGFydCBvZiB0aGUgcGFzc3dvcmRSZXNldCBvYmplY3QgYW5kIG5vdCBwYXJhbGxlbCB0byBpdC4N Cg0KTWlrZT4gVGhlIOKAnGV2ZW50IGV4dGVuc2lvbnPigJ0gbGFuZ3VhZ2UgaXMgYSBob2xkb3Zl ciBmcm9tIHdoZW4gdGhlcmUgd2FzIGFuIGFycmF5IG9mIGV2ZW50cyBhbmQgdGhlIGZpcnN0IGV2 ZW50IHdhcyBzb21laG93IHNwZWNpYWwuICBJIGFncmVlIHRoYXQgd2UgbmVlZCB0byBwZXJmb3Jt IGVkaXRvcmlhbCBzdXJnZXJ5IHRvIGNsZWFuIHRoaXMgdXAsIGJlY2F1c2UgaXQgaXMgY3VycmVu dGx5IG1pc2xlYWRpbmcuDQoNCg0KICAqICAgV2h5ICJldmVudHMiIGFuZCBub3QgImV2ZW50Ij8g V2UgZG9uJ3QgcmVhbGx5IGhhdmUgc3VwcG9ydCBmb3IgbXVsdGlwbGUgZXZlbnRzLiBDZXJ0YWlu bHkgbm90IGlmIHRoZXkgYXJlIGFsbCBvZiB0aGUgc2FtZSB0eXBlLiBUaGUgY3VycmVudCB0ZXh0 IGlzIGNvbmZ1c2luZzogImV2ZW50cyIgaXMgbm90IHRoZSBzYW1lIGFzICJhIHByaW1hcnkgZXZl bnQgYW5kIGl0cyBleHRlbnNpb25zIi4NCg0KTWlrZT4gV2hhdOKAmXMgYmVpbmcgcmVwcmVzZW50 ZWQgaXMgYSBzZXQgb2YgcmVsYXRlZCBldmVudHMgZnJvbSB0aGUgc2FtZSBpc3N1ZXIuICBBZ2Fp biwgdGhlIGV4dGVuc2lvbnMgbGFuZ3VhZ2UgaXMgbWlzbGVhZGluZywgYW5kIG5lZWRzIHRvIGJl IGZpeGVkLg0KDQoNCiAgKiAgICJJbiB0aGUgYWJvdmUgZXhhbXBsZSAiaXNzIiBhbmQgInN1YiIg Y29udGFpbmVkIHdpdGhpbiB0aGUgY2xhaW0iIC0gdGhpcyBpcyBpbmNvcnJlY3QsIHByb2JhYmx5 IGxlZnRvdmVyIGZyb20gYW4gZWFybGllciB2ZXJzaW9uLg0KDQpNaWtlPiBJIGFncmVlIHdpdGgg UGhpbOKAmXMgcG9pbnRzLiAgVGhlIGVkaXRvcnMgY2FuIHdvcmsgb24gdGhpcyB0byBtYWtlIHRo ZSBpbnRlbnQgY2xlYXJlci4NCg0KDQogICogICAiYXVkIiBNQVkgYmUgYSBVUkk6IHNob3VsZG4n dCBpdCBiZSBhbiBhcnJheSwgbWF5YmUgYW4gYXJyYXkgdGhhdCBjb250YWlucyBhIHNpbmdsZSBV Ukk/DQogICogICBXaHkgZG8gd2UgdXNlIHRoZSB0ZXJtcyAic2luZ2xlLXZhbHVlZCIgdnMuICJt dWx0aXBsZS12YWx1ZWQiIHN0cmluZ3M/IFdoeSBub3QgdXNlIHRoZSBub3JtYWwgSlNPTiB0ZXJt aW5vbG9neSwgInN0cmluZyIgdnMuICJhcnJheSBvZiBzdHJpbmdzIj8NCiAgKiAgIFdoeSBpcyAi c3ViIiBvcHRpb25hbD8gRG8gd2UgaGF2ZSBhbnkgZ29vZCBleGFtcGxlcyBvZiBldmVudHMgd2hl cmUgdGhpcyB2YWx1ZSBpcyBub3QgcmVxdWlyZWQ/DQogICogICAiYSBmdXR1cmUgZGF0ZSIgLSB3 ZSBzaG91bGQgY2xhcmlmeSB0aGF0IHRoZXJlIG1heSBiZSBjYXNlcyB3aGVuIG5iZiBpcyBzbWFs bGVyIHRoYW4gaWF0LCBpLmUuIHdoZW4gaXQgdGFrZXMgc29tZSB0aW1lIHVudGlsIHRoZSBTRVQg aXMgaXNzdWVkLg0KICAqICAgImV4cCIgLSBpcyBpdCBhbHNvIGEgTnVtZXJpY0RhdGU/IFBsZWFz ZSBzcGVjaWZ5Lg0KICAqICAgSW4gdGhlIG1lZGljYWwgZXhhbXBsZSwgaXQgaXMgc3RyYW5nZSB0 aGF0IHRoZSBldmVudCBpcyBuYW1lZCBieSBhIFVSTCB0aGF0IHBvaW50cyB0byBhbiBIVE1MIHBh Z2UuIEkgd291bGQgZXhwZWN0IGEgbW9yZSBzdGFibGUgVVJJLg0KICAqICAgMi4yOiBpcyBlbmNy eXB0aW9uIGEgTVVTVCB3aGVuZXZlciB0aGVyZSBhcmUgYXR0cmlidXRlcyBzcGVjaWZpZWQ/IElm IHNvLCB3ZSBzaG91bGQgaGF2ZSBhIG5vcm1hdGl2ZSBzZWN0aW9uIHNheWluZyBzbywgbm90IGp1 c3QgbWVudGlvbiBpdCBpbiB0aGUgY29udGV4dCBvZiBhbiBleGFtcGxlLiBCZXNpZGVzLCB3ZSBo YXZlIG5vdCBkZWZpbmVkIHdoYXQgYXR0cmlidXRlcyBhcmUuDQogICogICAyLjI6IHRoaXMgc2Vj dGlvbiBpcyBjb25mdXNpbmcuIFdlIGZpcnN0IHNheSB0aGF0IHRoZSBKV1QgbXVzdCBiZSBlbmNy eXB0ZWQuIEJ1dCB0aGVuIGluc3RlYWQsIHdlIHNpZ24gaXQsIGFuZCB3ZSAic2lnbiIgd2l0aCBh IG51bGwgYWxnb3JpdGhtLiBXaHk/DQogICogICBTaWduZWQgU0VUcyBNVVNUIChub3QgTUFZKSBi ZSB2YWxpZGF0ZWQgYnkgdGhlIHN1YnNjcmliZXIuDQogICogICBBbHNvLCBJIHRoaW5rIHdlIHNo b3VsZCByZW1vdmUgdGhlIHByZWNvbmRpdGlvbnMgYW5kIGFsd2F5cyByZXF1aXJlIHNpZ25pbmcs IGFzIGEgTVVTVC4gQW4gb3B0aW9uYWwgc2lnbmF0dXJlIGlzIGFjdHVhbGx5IGEgc2VjdXJpdHkg bG9vcGhvbGUgYmVjYXVzZSBhbiBhdHRhY2tlciBjYW4gcmVtb3ZlIHRoZSBzaWduYXR1cmUsIGFu ZCB0aGUgc3Vic2NyaWJlciBkb2Vzbid0IGtub3cgdGhhdCBpdCdzIG1pc3NpbmcuDQogICogICAz LjI6ICJ0aGF0IGFsb25lIHdpbGwgbm90IGd1YXJhbnRlZSB0aGF0IHRoZSBjb3JyZWN0IHN1YnNj cmliaW5nIHBhcnR5IGtub3dzIHRoZXkgc2hvdWxkIGhhdmUgcmVjZWl2ZWQgYSBwYXJ0aWN1bGFy IFNFVC4iIFRoZSB0ZXh0IGlzIHVuY2xlYXIgdG8gbWUuIERvIHdlIG1lYW46ICJ0aGF0IGFsb25l IGRvZXMgbm90IGd1YXJhbnRlZSB0aGF0IGEgcGFydGljdWxhciBTRVQgd2FzIGRlbGl2ZXJlZCB0 byB0aGUgY29ycmVjdCBzdWJzY3JpYmluZyBwYXJ0eSI/DQogICogICBXZSBtYXkgd2FudCBhIHNl cGFyYXRlIEltcGxlbWVudGF0aW9uIENvbnNpZGVyYXRpb25zIHNlY3Rpb24sIGFuZCBtb3ZlICJk ZWxpdmVyeSIsICJzZXF1ZW5jaW5nIiBhbmQgInRpbWluZyIgaW50byBpdC4gWWVzIHRoZXkgYXJl IHNlY3VyaXR5LXJlbGV2YW50LCBqdXN0IGxpa2UgYW55dGhpbmcgZWxzZSBpbiB0aGlzIGRvY3Vt ZW50LCBidXQgdGhleSB3b3VsZCBhcHBseSBqdXN0IGFzIHdlbGwgdG8gYW55IGV2ZW50IHN0cmVh bSBwcm90b2NvbC4NCiAgKiAgIDMuMzogdGhpcyBpcyB0aGUgZmlyc3QgdGltZSB3ZSBtZW50aW9u IHByb3Zpc2lvbmluZy4gRG8gd2UgcmVhbGx5IGludGVuZCBTRVRzIHRvIGJlIHVzZWQgZm9yIHRo YXQ/DQogICogICAzLjM6IElTVE0gdGhhdCB3ZSBzaG91bGQgZGVmaW5lIGEgc2VxdWVuY2luZyBt ZWNoYW5pc20sIHJhdGhlciB0aGFuIGxlYXZlIGl0IG9wZW4gdG8gcHJvZmlsZXMuIEUuZy4sIHJl cXVpcmUgYSBzZXF1ZW5jZSBudW1iZXIgd2hlbmV2ZXIgInR4biIgaXMgdXNlZC4NCiAgKiAgIDMu NDogQWxzbywgb3VyIHRpbWVzdGFtcHMgb25seSBoYXZlIDEgc2Vjb25kIGdyYW51bGFyaXR5LCBh bmQgc28gYXJlIHRvbyBjb2Fyc2UgZm9yIHNlc3Npb24gc3RhdGUgKGNvbnNpZGVyIGF1dG9tYXRl ZCBsb2dpbnMvbG9nb3V0cykuDQogICogICAzLjU6IFdoeSBkb24ndCB3ZSBoYXZlIGFuIHVuYW1i aWd1b3VzIHdheSB0byBkaXN0aW5ndWlzaCBTRVRzIGZyb20gYWNjZXNzIHRva2Vucywgd2h5IGxl YXZlIGl0IHRvIGltcGxlbWVudGVycz8gU291bmRzIGxpa2UgYSBtYWpvciBzZWN1cml0eSBpc3N1 ZSBpbiB0aGUgbWFraW5nLiBXZSBzaG91bGQgY29uc2lkZXIgaGVyZSBBTEwgaW1wbGVtZW50YXRp b25zIHRoYXQgYWNjZXB0IGFjY2VzcyB0b2tlbnMsIGluY2x1ZGluZyBsZWdhY3kgaW1wbGVtZW50 YXRpb25zIHRoYXQgY2Fubm90IGJlIG1vZGlmaWVkLg0KDQpNaWtlPiBXZSBkbyBoYXZlIGFuIHVu YW1iaWd1b3VzIG1hbm5lciBvZiBkaXN0aW5ndWlzaGluZyBTRVRzIGZyb20gb3RoZXIgSldUcyDi gJMgdGhlIGluY2x1c2lvbiBvZiB0aGUg4oCcZXZlbnRz4oCdIGNsYWltLiAgT0F1dGggYWNjZXNz IHRva2VucyBhcmUsIGJ5IGRlZmluaXRpb24sIG9wYXF1ZSwgYW5kIGNvbXBsZXRlbHkgb3V0c2lk ZSBvZiBvdXIgc2NvcGUgb2Ygd29yay4NCg0KDQogICogICA0OiBUaGUgYXVkaXQgaGFwcGVucyBv biB0aGUgc3Vic2NyaWJlciBzaWRlLiBCeSB0aGVuIGl0IGlzIHRvbyBsYXRlIHRvIHJlcXVpcmUg SldTIHRvIGJlIHVzZWQgYnkgdGhlIHB1Ymxpc2hlci4gQXMgbWVudGlvbmVkLCBJIHByb3Bvc2Ug dGhhdCBKV1Mgc2hvdWxkIEFMV0FZUyBiZSByZXF1aXJlZC4NCiAgKiAgIDQ6ICJXaGVuIHNoYXJp bmcgcGVyc29uYWxseSBpZGVudGlmaWFibGUgaW5mb3JtYXRpb24iIC0gd2Ugc2hvdWxkIHJlbW92 ZSB0aGlzIGNvbmRpdGlvbi4gSSBkb24ndCBzZWUgYSBjYXNlIHdoZXJlIHRoZSBpbmZvcm1hdGlv biBzaGFyZWQgaXMgTk9UIFBJSSwgYW5kIHRoZXJlZm9yZSBsZWdhbCBhZ3JlZW1lbnRzIGFib3V0 IGluZm9ybWF0aW9uIHNoYXJpbmcgYW5kIHVzZXIgY29uc2VudCBtdXN0IGFsd2F5cyBiZSBpbiBw bGFjZS4NCg0KTWlrZT4gV2Ugc2hvdWxkIHN0YXkgY29tcGxldGVseSBjbGVhciBvZiBzcGVjaWZ5 aW5nIHdoYXQgYXBwbGljYXRpb25zIGFuZCBwcm90b2NvbHMgbXVzdCBkbyB3aXRoIFNFVHMuICBJ dOKAmXMgdXAgdG8gdGhlbSB0byBwcm9maWxlIFNFVHMgc28gdGhhdCB0aGUgYXBwbGljYXRpb27i gJlzIHByaXZhY3kgYW5kIHNlY3VyaXR5IHByb3BlcnRpZXMgYXJlIG1haW50YWluZWQsIHdoaWNo IHdpbGwgZGlmZmVyIGJldHdlZW4gYXBwbGljYXRpb25zLiAgSnVzdCBsaWtlIHdoZXRoZXIg4oCc YWxn4oCdOiDigJxub25l4oCdIGlzIGFwcHJvcHJpYXRlIGlzIGEgcHJvdG9jb2wvYXBwbGljYXRp b24gZGVjaXNpb24sIGl04oCZcyBhbHNvIGEgcHJvdG9jb2wvYXBwbGljYXRpb24gZGVjaXNpb24g d2hldGhlciBlbmNyeXB0aW9uIGlzIG5lZWRlZCwgZGVwZW5kaW5nIHVwb24gdGhlIGNvbnRleHQu DQoNCg0KICAqICAgNDogSSBkb24ndCB0aGluayB0aGUgc3ViamVjdCBpbmZvcm1hdGlvbiBpcyAi cGVyY2VpdmVkIiBhcyBQSUkuIEl0IGlzIFBJSSwgb3RoZXJ3aXNlIGl0IHdvdWxkIGJlIHVzZWxl c3MgdG8gdGhlIHN1YnNjcmliZXIsIGJlY2F1c2UgdGhlIHN1YnNjcmliZXIgd291bGQgbm90IGJl IGFibGUgdG8gaWRlbnRpZnkgdGhlIHN1YmplY3QuIEFsc28sIGV2ZW4gaWYgdGhlIGluZm9ybWF0 aW9uIG9uIHRoZSB3aXJlIGlzIG5vdCBpbiBpdHNlbGYgUElJLCBlLmcuIHdoZW4gdXNpbmcgYSBo YXNoLCB0aGUgZmFjdCB0aGF0IGEgcHVibGlzaGVyIHNoYXJlcyBpbmZvcm1hdGlvbiB0aGF0IGEg cGFydGljdWxhciB1c2VyIGlzIGFsc28gYSB1c2VyIG9uIGl0cyBzeXN0ZW0gYW5kIGlzIHVuZGVy Z29pbmcgY2VydGFpbiBzdGF0ZSBjaGFuZ2VzIGlzIHByaXZhY3ktc2Vuc2l0aXZlLg0KDQpNaWtl PiBQZXIgbXkgcHJldmlvdXMgY29tbWVudCwgd2hhdOKAmXMgUElJIChvciBub3QpIGlzIHByb3Rv Y29sL2FwcGxpY2F0aW9uLXNwZWNpZmljIGFuZCBub3QgYW4gYXBwcm9wcmlhdGUgdG9waWMgZm9y IHRoZSBTRVQgc3BlYy4gIFRoZSBlZGl0b3JzIHNob3VsZCByZW1vdmUgYW55IHN1Y2ggbGFuZ3Vh Z2UsIG90aGVyIHRoYW4gcGVyaGFwcyBpbmZvcm1hdGl2ZSBjb21tZW50cyBpbiB0aGUgU2VjdXJp dHkgQ29uc2lkZXJhdGlvbnMgYW5kIFByaXZhY3kgQ29uc2lkZXJhdGlvbnMgc2VjdGlvbnMsIGxp c3RpbmcgdGhpbmdzIHRoYXQgcHJvdG9jb2wvYXBwbGljYXRpb24gZGVzaWduZXJzIHNob3VsZCBj b25zaWRlci4NCg0KDQogICogICBJIHN1Z2dlc3QgdG8gYWRkIGFuIEltcGxlbWVudGF0aW9uIFN0 YXR1cyBzZWN0aW9uLCBwZXIgUkZDIDc5NDIuDQoNClRoYW5rcywNCg0KICAgIFlhcm9uDQoNCg0K DQpNaWtlPiBUaGFua3MgYWdhaW4gZm9yIHRoZSB0aG9yb3VnaCBhbmQgdGhvdWdodGZ1bCBjb21t ZW50cywgWWFyb24hDQoNCg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQoNCg== --_000_BN3PR03MB2355F10CCD751A2B3FD03F9AF56B0BN3PR03MB2355namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJTZWdvZSBVSSI7 DQoJcGFub3NlLTE6MiAxMSA1IDIgNCAyIDQgMiAyIDM7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0Zv bGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJh Z3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCglt YXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0K CW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6YmxhY2s7 fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5 bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJp Z2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgljb2xvcjpibGFjazt9DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUt bmFtZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6IzAwMjA2MDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25z ICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxNzg0OTYxOTg5Ow0KCW1zby1saXN0LXRlbXBs YXRlLWlkczotNTkxMDgzOTkyO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1m b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4w aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZl bDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90 dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBi Z2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMDAyMDYwIj5J4oCZbSByZXBseWluZyB0byBZYXJvbuKAmXMgb3JpZ2luYWwg bWVzc2FnZSBzbyB0aGUgcmVzdWx0IHdpbGwgYmUgc2hvcnQgZW5vdWdoIHRvIGJlIHF1aWNrbHkg cmVhZGFibGUsIHdoaWxlIGFja25vd2xlZGdpbmcgdGhhdCBQaGlsIGFscmVhZHkgbWFkZSBtYW55 IHBvaW50cyBpbiBoaXMgcmVzcG9uc2VzIHRoYXQgSSBhZ3JlZSB3aXRoLiZuYnNwOyBXaGVyZSBJ IGRvbuKAmXQgaGF2ZQ0KIGFueXRoaW5nIHRvIGFkZCB0byBQaGls4oCZcyByZXNwb25zZXMsIEkg ZG9u4oCZdCBpbmNsdWRlIGEgcmVzcG9uc2UgdG8gdGhvc2UgcG9pbnRzLiZuYnNwOyBNeSByZXBs aWVzIGFyZSBwcmVmaXhlZCBieSDigJxNaWtlJmd0O+KAnS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMwMDIwNjAiPlRoYW5rcyBmb3IgdGFraW5nIHRoZSB0aW1lIHRvIGRvIGEgdGhvcm91 Z2ggcmVhZCwgWWFyb24hPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48 L3A+DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+PC9zcGFuPg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImNvbG9yOndpbmRvd3RleHQiPiBJZC1ldmVudCBbbWFpbHRvOmlkLWV2ZW50LWJvdW5jZXNA aWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPllhcm9uIFNoZWZmZXI8YnI+DQo8Yj5TZW50 OjwvYj4gU2F0dXJkYXksIERlY2VtYmVyIDEwLCAyMDE2IDE6MjggUE08YnI+DQo8Yj5Ubzo8L2I+ IFNlY0V2ZW50ICZsdDtpZC1ldmVudEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g W0lkLWV2ZW50XSBTb21lIGNvbW1lbnRzIHRvIGRyYWZ0LWh1bnQtaWRldmVudC10b2tlbi0wNzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0 b206LjAwMDFwdCI+SGksIEkgZmluYWxseSByZWFkIHRoZSBkcmFmdCBpbiBkZXRhaWwsIGFuZCBJ IGRvIGhhdmUgYSBmZXcgY29tbWVudHMuPG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2lu OjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPk15IG1haW4gc3VnZ2VzdGlvbiBpcyB0byB0aWdo dGVuIHRoZSBzcGVjaWZpY2F0aW9uIG9mIGFuIEV2ZW50LCBieSBkZWZpbmluZyBtb3JlIHN0cmlj dGx5IHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gJnF1b3Q7ZXZlbnQmcXVvdDsgYW5kICZxdW90O2V2 ZW50IGV4dGVuc2lvbiZxdW90OyBhbmQgdHdlYWtpbmcgdGhlIEpTT04gc3RydWN0dXJlIGEgYml0 LjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAw MXB0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBz dHlsZT0iY29sb3I6IzAwMjA2MCI+TWlrZSZndDsgUGVyIG15IHJlcGx5IGluIHRoZSB0aHJlYWQg 4oCcW0lkLWV2ZW50XSBEcmFmdCBhZG9wdGlvbuKAnSwgSSB0aGluayB3ZeKAmWQgYmUgYmV0dGVy IG9mZiBjb21wbGV0ZWx5IGRyb3BwaW5nIHRoZSBkaXN0aW5jdGlvbiBiZXR3ZWVuIHByaW1hcnkg ZXZlbnRzIGFuZCBzZWNvbmRhcnkgZXZlbnRzLiZuYnNwOyBXaGVuIGFwcGxpY2F0aW9ucw0KIHNl bmQgYSBzZXQgb2YgcmVsYXRlZCBldmVudHMgdG9nZXRoZXIsIGl04oCZcyBsb2dpY2FsIGZvciBy ZWNpcGllbnRzIHRvIHByb2Nlc3MgYWxsIG9mIHRoZW0gKG9yIGFsbCBvZiB0aGVtIHRoYXQgdGhl eSB1bmRlcnN0YW5kKS4mbmJzcDsgVGhlIHByaW1hcnkvc2Vjb25kYXJ5IGRpc3RpbmN0aW9uIGlz IHVuaGVscGZ1bCBhbmQgbGVhZHMgdG8gY29tcGxpY2F0aW9uLCByYXRoZXIgdGhhbiBjbGFyaXR5 IG9yIHNpbXBsaWZpY2F0aW9uLiZuYnNwOyBMZXTigJlzIGRyb3AgaXQNCiBlbnRpcmVseS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4w MDAxcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPkluIGFk ZGl0aW9uLCBJIHRoaW5rIHdlIHNob3VsZCByZXF1aXJlIHRoZSBjbGFpbSB0byBiZSBzaWduZWQs IHNpbmNlIGl0IHdpbGwgYmUgdXNlZCBmb3Igc2VjdXJpdHktc2Vuc2l0aXZlIGFjdGl2aXRpZXMg YWNyb3NzIGNvbXBsZXggZGlzdHJpYnV0ZWQgc3lzdGVtcy48bzpwPjwvbzpwPjwvcD4NCjx1bCBz dHlsZT0ibWFyZ2luLXRvcDowaW47Ym94LXNpemluZzogYm9yZGVyLWJveDtjb2xvcjpyZ2IoNDUs DQogICAgICA0OCwgNTIpO2ZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDtmb250LXZhcmlh bnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IDI7dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IDI7LXdl YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O2N1cnNvcjpkZWZhdWx0O3dvcmQtc3BhY2luZzow cHgiIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDowaW47bGluZS1oZWlnaHQ6MjAuMjVwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMTtib3gtc2l6 aW5nOiBib3JkZXItYm94O2N1cnNvcjpkZWZhdWx0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LHNhbnMtc2VyaWYiPjE6IFdo eSBpcyBzaWduaW5nIG9wdGlvbmFsPyBUaGUgcHVibGlzaGVyIGRvZXNuJ3Qga25vdyBob3cgdGhl IHN1YnNjcmliZXIncyBzeXN0ZW0gaXMgYXJjaGl0ZWN0ZWQsIGFuZCBtaWdodCB3ZWxsIHdhbnQg ZW5kLXRvLWVuZCBhdXRoZW50aWNhdGlvbiBvZiB0aGUgY2xhaW0uIFRoaXMgaXMgYWxzbyBpbXBv cnRhbnQgZm9yIGF1ZGl0aW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC91bD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAw MjA2MCI+TWlrZSZndDsgVGhpcyBpcyBncm91bmQgYWxyZWFkeSB3ZWxsLWNvdmVyZWQgZHVyaW5n IGJvdGggdGhlIEpPU0UgW1JGQyA3NTE1XSBhbmQgSldUIFtSRkMgNzUxOV0gc3RhbmRhcmRpemF0 aW9uIGVmZm9ydHMuJm5ic3A7IFRoZSBrZXkgb2JzZXJ2YXRpb24gaXMgdGhhdCBKV1QgKGFuZCBT RVQpIGlzIGEgZGF0YSBzdHJ1Y3R1cmUgdG8gYmUgdXNlZCBpbiBwcm90b2NvbHMgYW5kDQogYXBw bGljYXRpb25zIOKAkyBub3QgYSBwcm90b2NvbCBvciBhcHBsaWNhdGlvbiBzcGVjaWZpY2F0aW9u LiZuYnNwOyBJdOKAmXMgdXAgdG8gcHJvdG9jb2wgYW5kIGFwcGxpY2F0aW9uIHNwZWNpZmljYXRp b25zIHRvIGRlZmluZSB3aGV0aGVyIHNpZ25pbmcgaXMgbmVlZGVkIChhbmQgaWYgc28sIHdpdGgg d2hhdCBhbGdvcml0aG1zKS4mbmJzcDsgSW4gc29tZSBjYXNlcywgaXQgd29u4oCZdCBiZSBuZWVk ZWQgYmVjYXVzZSB0aGUgSldUL1NFVCBpcyBhbHJlYWR5IGludGVncml0eQ0KIHByb3RlY3RlZCBi eSB0aGUgcHJvdG9jb2wgb3IgYXBwbGljYXRpb24g4oCTIGZvciBpbnN0YW5jZSwgYnkgVExTLiAm bmJzcDtKdXN0IGxpa2UgZm9yIEpXVCwgd2Ugc2hvdWxkbuKAmXQgcmVxdWlyZSBzaWduaW5nIGlu IGNhc2VzIHRoYXQgaXQgYWRkcyBubyB2YWx1ZSBidXQgZG9lcyBhZGQgb3ZlcmhlYWQuJm5ic3A7 IEEgd29ya2luZyBncm91cCBjb25zZW5zdXMgY2FsbCBjb25maXJtZWQgdGhlIG5lZWQgZm9yIHRo ZSBhYmlsaXR5IHRvIHVzZSDigJxhbGfigJ064oCcbm9uZeKAnSBmb3INCiBKV1Mgb2JqZWN0cy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHVsIHN0eWxlPSJt YXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjBpbjtsaW5lLWhlaWdodDoyMC4yNXB0O21zby1saXN0OmwwIGxldmVsMSBs Zm8xO2JveC1zaXppbmc6IGJvcmRlci1ib3g7Y3Vyc29yOmRlZmF1bHQiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssc2Fucy1z ZXJpZiI+MTogJnF1b3Q7ZXhhbXBsZSBldmVudHMmcXVvdDsgLSBpcyBzcGVjaWZpY2F0aW9uIG9m IGluZGl2aWR1YWwgZXZlbnRzIChtYXliZSBvbmx5IGEgZmV3IGJhc2ljIG9uZXMpIHdpdGhpbiBz Y29wZSBvZiBvdXIgY2hhcnRlcj8gT3RoZXJ3aXNlIHdlIGNhbm5vdCBndWFyYW50ZWUgaW50ZXJv cC48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPk1pa2UmZ3Q7IEkg YWdyZWUgd2l0aCBQaGls4oCZcyByZXNwb25zZSB0aGF0IGludGVyb3AgaGFwcGVucyB3aXRoaW4g YXBwbGljYXRpb25zIGFuZCBwcm90b2NvbHMgdXNpbmcgU0VUcy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlw ZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjts aW5lLWhlaWdodDoyMC4yNXB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xO2JveC1zaXppbmc6IGJv cmRlci1ib3g7Y3Vyc29yOmRlZmF1bHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssc2Fucy1zZXJpZiI+MS4yOiBwcmluY2lw bGUgLSZndDsgcHJpbmNpcGFsPG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjtsaW5lLWhlaWdodDoyMC4yNXB0O21zby1saXN0 OmwwIGxldmVsMSBsZm8xO2JveC1zaXppbmc6IGJvcmRlci1ib3g7Y3Vyc29yOmRlZmF1bHQiPg0K PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkm cXVvdDssc2Fucy1zZXJpZiI+MjogJnF1b3Q7Zmlyc3QgdmFsdWUmcXVvdDsgaXMgbWVhbmluZ2xl c3MuIEpTT04gb2JqZWN0cyBhcmUgdW5vcmRlcmVkICg0dGggcGFyYWdyYXBoIG9mIFJGQyA3MTU5 KS4gSWYgb3JkZXI8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+PGVtPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90OyxzYW5z LXNlcmlmIj5pczwvc3Bhbj48L2VtPg0KIGltcG9ydGFudCwgd2UgY291bGQgbWFrZSAmcXVvdDtl dmVudHMmcXVvdDsgaW50byBhbiBhcnJheS48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMwMDIwNjAiPk1pa2UmZ3Q7IE9yZGVyIGlzIHVuaW1wb3J0YW50LiZuYnNwOyBUaGlzIHdh cyBhbHJlYWR5IHdpZGVseSBkaXNjdXNzZWQgb24gdGhlIGlkLWV2ZW50IGxpc3QuJm5ic3A7IFdo aWxlIHdlIHVzZWQgdG8gdXNlIGFuIGFycmF5IHJlcHJlc2VudGF0aW9uLCBhIGNvbnNjaW91cyBj aG9pY2Ugd2FzIG1hZGUgdG8gbW92ZSB0byB0aGUgY3VycmVudCDigJxzZXQgb2YgZXZlbnRz4oCd IHN5bnRheCwgcmVwbGFjaW5nDQogdGhlIG9sZCDigJxhcnJheSBvZiBldmVudHPigJ0gc3ludGF4 LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8dWwgc3R5bGU9 Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MGluO2xpbmUtaGVpZ2h0OjIwLjI1cHQ7bXNvLWxpc3Q6bDAgbGV2ZWwx IGxmbzE7Ym94LXNpemluZzogYm9yZGVyLWJveDtjdXJzb3I6ZGVmYXVsdCI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90OyxzYW5z LXNlcmlmIj4yOiBldmVudCBleHRlbnNpb25zIGFyZSBub3QgZGVmaW5lZCBidXQgb25seSBpbnRy b2R1Y2VkIGJ5IHRoZSB0ZXh0IGFmdGVyIHRoZXkgYXJlIGRlc2NyaWJlZC4gQWxzbywgaW4gdGhl IGV4YW1wbGUgdGhlcmUncyB0aGlzIFVSTDo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly/igItleGFtcGxlLuKAi2NvbS/igItz Y2ltL+KAi2V2ZW50L+KAi3Bhc+KAi3N3b3LigItkUmVz4oCLZXRFeOKAi3QiPmh0dHBzOi8v4oCL ZXhhbXBsZS7igItjb20v4oCLc2NpbS/igItldmVudC/igItwYXPigItzd29y4oCLZFJlc+KAi2V0 RXjigIt0PC9hPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj4tDQogSSBiZWxpZXZlIGl0IG5lZWRzIHRvIGJlIHBhcnQgb2YgdGhlIHBhc3N3b3JkUmVzZXQg b2JqZWN0IGFuZCBub3QgcGFyYWxsZWwgdG8gaXQuPG86cD48L286cD48L3NwYW4+PC9saT48L3Vs Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMDAyMDYwIj5NaWtlJmd0OyBUaGUg4oCcZXZlbnQgZXh0ZW5zaW9uc+KAnSBsYW5n dWFnZSBpcyBhIGhvbGRvdmVyIGZyb20gd2hlbiB0aGVyZSB3YXMgYW4gYXJyYXkgb2YgZXZlbnRz IGFuZCB0aGUgZmlyc3QgZXZlbnQgd2FzIHNvbWVob3cgc3BlY2lhbC4mbmJzcDsgSSBhZ3JlZSB0 aGF0IHdlIG5lZWQgdG8gcGVyZm9ybSBlZGl0b3JpYWwgc3VyZ2VyeSB0byBjbGVhbiB0aGlzIHVw LCBiZWNhdXNlDQogaXQgaXMgY3VycmVudGx5IG1pc2xlYWRpbmcuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5 cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47 bGluZS1oZWlnaHQ6MjAuMjVwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMTtib3gtc2l6aW5nOiBi b3JkZXItYm94O2N1cnNvcjpkZWZhdWx0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LHNhbnMtc2VyaWYiPldoeSAmcXVvdDtl dmVudHMmcXVvdDsgYW5kIG5vdCAmcXVvdDtldmVudCZxdW90Oz8gV2UgZG9uJ3QgcmVhbGx5IGhh dmUgc3VwcG9ydCBmb3IgbXVsdGlwbGUgZXZlbnRzLiBDZXJ0YWlubHkgbm90IGlmIHRoZXkgYXJl IGFsbCBvZiB0aGUgc2FtZSB0eXBlLiBUaGUgY3VycmVudCB0ZXh0IGlzIGNvbmZ1c2luZzogJnF1 b3Q7ZXZlbnRzJnF1b3Q7IGlzIG5vdCB0aGUgc2FtZSBhcyAmcXVvdDthIHByaW1hcnkNCiBldmVu dCBhbmQgaXRzIGV4dGVuc2lvbnMmcXVvdDsuPG86cD48L286cD48L3NwYW4+PC9saT48L3VsPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojMDAyMDYwIj5NaWtlJmd0OyBXaGF04oCZcyBiZWluZyByZXByZXNlbnRlZCBpcyBhIHNl dCBvZiByZWxhdGVkIGV2ZW50cyBmcm9tIHRoZSBzYW1lIGlzc3Vlci4mbmJzcDsgQWdhaW4sIHRo ZSBleHRlbnNpb25zIGxhbmd1YWdlIGlzIG1pc2xlYWRpbmcsIGFuZCBuZWVkcyB0byBiZSBmaXhl ZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHVsIHN0eWxl PSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjBpbjtsaW5lLWhlaWdodDoyMC4yNXB0O21zby1saXN0OmwwIGxldmVs MSBsZm8xO2JveC1zaXppbmc6IGJvcmRlci1ib3g7Y3Vyc29yOmRlZmF1bHQiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssc2Fu cy1zZXJpZiI+JnF1b3Q7SW4gdGhlIGFib3ZlIGV4YW1wbGUgJnF1b3Q7aXNzJnF1b3Q7IGFuZCAm cXVvdDtzdWImcXVvdDsgY29udGFpbmVkIHdpdGhpbiB0aGUgY2xhaW0mcXVvdDsgLSB0aGlzIGlz IGluY29ycmVjdCwgcHJvYmFibHkgbGVmdG92ZXIgZnJvbSBhbiBlYXJsaWVyIHZlcnNpb24uPG86 cD48L286cD48L3NwYW4+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5NaWtlJmd0OyBJIGFncmVl IHdpdGggUGhpbOKAmXMgcG9pbnRzLiZuYnNwOyBUaGUgZWRpdG9ycyBjYW4gd29yayBvbiB0aGlz IHRvIG1ha2UgdGhlIGludGVudCBjbGVhcmVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4N CjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO2xpbmUtaGVpZ2h0 OjIwLjI1cHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzE7Ym94LXNpemluZzogYm9yZGVyLWJveDtj dXJzb3I6ZGVmYXVsdCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWls eTomcXVvdDtTZWdvZSBVSSZxdW90OyxzYW5zLXNlcmlmIj4mcXVvdDthdWQmcXVvdDsgTUFZIGJl IGEgVVJJOiBzaG91bGRuJ3QgaXQgYmUgYW4gYXJyYXksIG1heWJlIGFuIGFycmF5IHRoYXQgY29u dGFpbnMgYSBzaW5nbGUgVVJJPzxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bGluZS1oZWlnaHQ6MjAuMjVwdDttc28tbGlz dDpsMCBsZXZlbDEgbGZvMTtib3gtc2l6aW5nOiBib3JkZXItYm94O2N1cnNvcjpkZWZhdWx0Ij4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJ JnF1b3Q7LHNhbnMtc2VyaWYiPldoeSBkbyB3ZSB1c2UgdGhlIHRlcm1zICZxdW90O3NpbmdsZS12 YWx1ZWQmcXVvdDsgdnMuICZxdW90O211bHRpcGxlLXZhbHVlZCZxdW90OyBzdHJpbmdzPyBXaHkg bm90IHVzZSB0aGUgbm9ybWFsIEpTT04gdGVybWlub2xvZ3ksICZxdW90O3N0cmluZyZxdW90OyB2 cy4gJnF1b3Q7YXJyYXkgb2Ygc3RyaW5ncyZxdW90Oz88bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxs aSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO2xpbmUtaGVpZ2h0OjIw LjI1cHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzE7Ym94LXNpemluZzogYm9yZGVyLWJveDtjdXJz b3I6ZGVmYXVsdCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTom cXVvdDtTZWdvZSBVSSZxdW90OyxzYW5zLXNlcmlmIj5XaHkgaXMgJnF1b3Q7c3ViJnF1b3Q7IG9w dGlvbmFsPyBEbyB3ZSBoYXZlIGFueSBnb29kIGV4YW1wbGVzIG9mIGV2ZW50cyB3aGVyZSB0aGlz IHZhbHVlIGlzIG5vdCByZXF1aXJlZD88bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO2xpbmUtaGVpZ2h0OjIwLjI1cHQ7bXNv LWxpc3Q6bDAgbGV2ZWwxIGxmbzE7Ym94LXNpemluZzogYm9yZGVyLWJveDtjdXJzb3I6ZGVmYXVs dCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtTZWdv ZSBVSSZxdW90OyxzYW5zLXNlcmlmIj4mcXVvdDthIGZ1dHVyZSBkYXRlJnF1b3Q7IC0gd2Ugc2hv dWxkIGNsYXJpZnkgdGhhdCB0aGVyZSBtYXkgYmUgY2FzZXMgd2hlbiBuYmYgaXMgc21hbGxlciB0 aGFuIGlhdCwgaS5lLiB3aGVuIGl0IHRha2VzIHNvbWUgdGltZSB1bnRpbCB0aGUgU0VUIGlzIGlz c3VlZC48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MGluO2xpbmUtaGVpZ2h0OjIwLjI1cHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxm bzE7Ym94LXNpemluZzogYm9yZGVyLWJveDtjdXJzb3I6ZGVmYXVsdCI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90OyxzYW5zLXNl cmlmIj4mcXVvdDtleHAmcXVvdDsgLSBpcyBpdCBhbHNvIGEgTnVtZXJpY0RhdGU/IFBsZWFzZSBz cGVjaWZ5LjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDowaW47bGluZS1oZWlnaHQ6MjAuMjVwdDttc28tbGlzdDpsMCBsZXZlbDEg bGZvMTtib3gtc2l6aW5nOiBib3JkZXItYm94O2N1cnNvcjpkZWZhdWx0Ij4NCjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LHNhbnMt c2VyaWYiPkluIHRoZSBtZWRpY2FsIGV4YW1wbGUsIGl0IGlzIHN0cmFuZ2UgdGhhdCB0aGUgZXZl bnQgaXMgbmFtZWQgYnkgYSBVUkwgdGhhdCBwb2ludHMgdG8gYW4gSFRNTCBwYWdlLiBJIHdvdWxk IGV4cGVjdCBhIG1vcmUgc3RhYmxlIFVSSS48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO2xpbmUtaGVpZ2h0OjIwLjI1cHQ7 bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzE7Ym94LXNpemluZzogYm9yZGVyLWJveDtjdXJzb3I6ZGVm YXVsdCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtT ZWdvZSBVSSZxdW90OyxzYW5zLXNlcmlmIj4yLjI6IGlzIGVuY3J5cHRpb24gYSBNVVNUIHdoZW5l dmVyIHRoZXJlIGFyZSBhdHRyaWJ1dGVzIHNwZWNpZmllZD8gSWYgc28sIHdlIHNob3VsZCBoYXZl IGEgbm9ybWF0aXZlIHNlY3Rpb24gc2F5aW5nIHNvLCBub3QganVzdCBtZW50aW9uIGl0IGluIHRo ZSBjb250ZXh0IG9mIGFuIGV4YW1wbGUuIEJlc2lkZXMsIHdlIGhhdmUgbm90IGRlZmluZWQNCiB3 aGF0IGF0dHJpYnV0ZXMgYXJlLjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bGluZS1oZWlnaHQ6MjAuMjVwdDttc28tbGlz dDpsMCBsZXZlbDEgbGZvMTtib3gtc2l6aW5nOiBib3JkZXItYm94O2N1cnNvcjpkZWZhdWx0Ij4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJ JnF1b3Q7LHNhbnMtc2VyaWYiPjIuMjogdGhpcyBzZWN0aW9uIGlzIGNvbmZ1c2luZy4gV2UgZmly c3Qgc2F5IHRoYXQgdGhlIEpXVCBtdXN0IGJlIGVuY3J5cHRlZC4gQnV0IHRoZW4gaW5zdGVhZCwg d2Ugc2lnbiBpdCwgYW5kIHdlICZxdW90O3NpZ24mcXVvdDsgd2l0aCBhIG51bGwgYWxnb3JpdGht LiBXaHk/PG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjBpbjtsaW5lLWhlaWdodDoyMC4yNXB0O21zby1saXN0OmwwIGxldmVsMSBs Zm8xO2JveC1zaXppbmc6IGJvcmRlci1ib3g7Y3Vyc29yOmRlZmF1bHQiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssc2Fucy1z ZXJpZiI+U2lnbmVkIFNFVHMgTVVTVCAobm90IE1BWSkgYmUgdmFsaWRhdGVkIGJ5IHRoZSBzdWJz Y3JpYmVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDowaW47bGluZS1oZWlnaHQ6MjAuMjVwdDttc28tbGlzdDpsMCBsZXZlbDEg bGZvMTtib3gtc2l6aW5nOiBib3JkZXItYm94O2N1cnNvcjpkZWZhdWx0Ij4NCjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LHNhbnMt c2VyaWYiPkFsc28sIEkgdGhpbmsgd2Ugc2hvdWxkIHJlbW92ZSB0aGUgcHJlY29uZGl0aW9ucyBh bmQgYWx3YXlzIHJlcXVpcmUgc2lnbmluZywgYXMgYSBNVVNULiBBbiBvcHRpb25hbCBzaWduYXR1 cmUgaXMgYWN0dWFsbHkgYSBzZWN1cml0eSBsb29waG9sZSBiZWNhdXNlIGFuIGF0dGFja2VyIGNh biByZW1vdmUgdGhlIHNpZ25hdHVyZSwgYW5kDQogdGhlIHN1YnNjcmliZXIgZG9lc24ndCBrbm93 IHRoYXQgaXQncyBtaXNzaW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bGluZS1oZWlnaHQ6MjAuMjVwdDttc28tbGlz dDpsMCBsZXZlbDEgbGZvMTtib3gtc2l6aW5nOiBib3JkZXItYm94O2N1cnNvcjpkZWZhdWx0Ij4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJ JnF1b3Q7LHNhbnMtc2VyaWYiPjMuMjogJnF1b3Q7dGhhdCBhbG9uZSB3aWxsIG5vdCBndWFyYW50 ZWUgdGhhdCB0aGUgY29ycmVjdCBzdWJzY3JpYmluZyBwYXJ0eSBrbm93cyB0aGV5IHNob3VsZCBo YXZlIHJlY2VpdmVkIGEgcGFydGljdWxhciBTRVQuJnF1b3Q7IFRoZSB0ZXh0IGlzIHVuY2xlYXIg dG8gbWUuIERvIHdlIG1lYW46ICZxdW90O3RoYXQgYWxvbmUgZG9lcyBub3QgZ3VhcmFudGVlDQog dGhhdCBhIHBhcnRpY3VsYXIgU0VUIHdhcyBkZWxpdmVyZWQgdG8gdGhlIGNvcnJlY3Qgc3Vic2Ny aWJpbmcgcGFydHkmcXVvdDs/PG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjtsaW5lLWhlaWdodDoyMC4yNXB0O21zby1saXN0 OmwwIGxldmVsMSBsZm8xO2JveC1zaXppbmc6IGJvcmRlci1ib3g7Y3Vyc29yOmRlZmF1bHQiPg0K PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkm cXVvdDssc2Fucy1zZXJpZiI+V2UgbWF5IHdhbnQgYSBzZXBhcmF0ZSBJbXBsZW1lbnRhdGlvbiBD b25zaWRlcmF0aW9ucyBzZWN0aW9uLCBhbmQgbW92ZSAmcXVvdDtkZWxpdmVyeSZxdW90OywgJnF1 b3Q7c2VxdWVuY2luZyZxdW90OyBhbmQgJnF1b3Q7dGltaW5nJnF1b3Q7IGludG8gaXQuIFllcyB0 aGV5IGFyZSBzZWN1cml0eS1yZWxldmFudCwganVzdCBsaWtlIGFueXRoaW5nIGVsc2UgaW4gdGhp cyBkb2N1bWVudCwNCiBidXQgdGhleSB3b3VsZCBhcHBseSBqdXN0IGFzIHdlbGwgdG8gYW55IGV2 ZW50IHN0cmVhbSBwcm90b2NvbC48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO2xpbmUtaGVpZ2h0OjIwLjI1cHQ7bXNvLWxp c3Q6bDAgbGV2ZWwxIGxmbzE7Ym94LXNpemluZzogYm9yZGVyLWJveDtjdXJzb3I6ZGVmYXVsdCI+ DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtTZWdvZSBV SSZxdW90OyxzYW5zLXNlcmlmIj4zLjM6IHRoaXMgaXMgdGhlIGZpcnN0IHRpbWUgd2UgbWVudGlv biBwcm92aXNpb25pbmcuIERvIHdlIHJlYWxseSBpbnRlbmQgU0VUcyB0byBiZSB1c2VkIGZvciB0 aGF0PzxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDowaW47bGluZS1oZWlnaHQ6MjAuMjVwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZv MTtib3gtc2l6aW5nOiBib3JkZXItYm94O2N1cnNvcjpkZWZhdWx0Ij4NCjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LHNhbnMtc2Vy aWYiPjMuMzogSVNUTSB0aGF0IHdlIHNob3VsZCBkZWZpbmUgYSBzZXF1ZW5jaW5nIG1lY2hhbmlz bSwgcmF0aGVyIHRoYW4gbGVhdmUgaXQgb3BlbiB0byBwcm9maWxlcy4gRS5nLiwgcmVxdWlyZSBh IHNlcXVlbmNlIG51bWJlciB3aGVuZXZlciAmcXVvdDt0eG4mcXVvdDsgaXMgdXNlZC48bzpwPjwv bzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MGluO2xpbmUtaGVpZ2h0OjIwLjI1cHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzE7Ym94LXNpemlu ZzogYm9yZGVyLWJveDtjdXJzb3I6ZGVmYXVsdCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEz LjVwdDtmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90OyxzYW5zLXNlcmlmIj4zLjQ6IEFs c28sIG91ciB0aW1lc3RhbXBzIG9ubHkgaGF2ZSAxIHNlY29uZCBncmFudWxhcml0eSwgYW5kIHNv IGFyZSB0b28gY29hcnNlIGZvciBzZXNzaW9uIHN0YXRlIChjb25zaWRlciBhdXRvbWF0ZWQgbG9n aW5zL2xvZ291dHMpLjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bGluZS1oZWlnaHQ6MjAuMjVwdDttc28tbGlzdDpsMCBs ZXZlbDEgbGZvMTtib3gtc2l6aW5nOiBib3JkZXItYm94O2N1cnNvcjpkZWZhdWx0Ij4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7 LHNhbnMtc2VyaWYiPjMuNTogV2h5IGRvbid0IHdlIGhhdmUgYW4gdW5hbWJpZ3VvdXMgd2F5IHRv IGRpc3Rpbmd1aXNoIFNFVHMgZnJvbSBhY2Nlc3MgdG9rZW5zLCB3aHkgbGVhdmUgaXQgdG8gaW1w bGVtZW50ZXJzPyBTb3VuZHMgbGlrZSBhIG1ham9yIHNlY3VyaXR5IGlzc3VlIGluIHRoZSBtYWtp bmcuIFdlIHNob3VsZCBjb25zaWRlciBoZXJlIEFMTCBpbXBsZW1lbnRhdGlvbnMNCiB0aGF0IGFj Y2VwdCBhY2Nlc3MgdG9rZW5zLCBpbmNsdWRpbmcgbGVnYWN5IGltcGxlbWVudGF0aW9ucyB0aGF0 IGNhbm5vdCBiZSBtb2RpZmllZC48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMw MDIwNjAiPk1pa2UmZ3Q7IFdlIGRvIGhhdmUgYW4gdW5hbWJpZ3VvdXMgbWFubmVyIG9mIGRpc3Rp bmd1aXNoaW5nIFNFVHMgZnJvbSBvdGhlciBKV1RzIOKAkyB0aGUgaW5jbHVzaW9uIG9mIHRoZSDi gJxldmVudHPigJ0gY2xhaW0uJm5ic3A7IE9BdXRoIGFjY2VzcyB0b2tlbnMgYXJlLCBieSBkZWZp bml0aW9uLCBvcGFxdWUsIGFuZCBjb21wbGV0ZWx5IG91dHNpZGUgb2Ygb3VyIHNjb3BlIG9mIHdv cmsuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjx1bCBzdHls ZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDowaW47bGluZS1oZWlnaHQ6MjAuMjVwdDttc28tbGlzdDpsMCBsZXZl bDEgbGZvMTtib3gtc2l6aW5nOiBib3JkZXItYm94O2N1cnNvcjpkZWZhdWx0Ij4NCjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LHNh bnMtc2VyaWYiPjQ6IFRoZSBhdWRpdCBoYXBwZW5zIG9uIHRoZSBzdWJzY3JpYmVyIHNpZGUuIEJ5 IHRoZW4gaXQgaXMgdG9vIGxhdGUgdG8gcmVxdWlyZSBKV1MgdG8gYmUgdXNlZCBieSB0aGUgcHVi bGlzaGVyLiBBcyBtZW50aW9uZWQsIEkgcHJvcG9zZSB0aGF0IEpXUyBzaG91bGQgQUxXQVlTIGJl IHJlcXVpcmVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDowaW47bGluZS1oZWlnaHQ6MjAuMjVwdDttc28tbGlzdDpsMCBsZXZl bDEgbGZvMTtib3gtc2l6aW5nOiBib3JkZXItYm94O2N1cnNvcjpkZWZhdWx0Ij4NCjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LHNh bnMtc2VyaWYiPjQ6ICZxdW90O1doZW4gc2hhcmluZyBwZXJzb25hbGx5IGlkZW50aWZpYWJsZSBp bmZvcm1hdGlvbiZxdW90OyAtIHdlIHNob3VsZCByZW1vdmUgdGhpcyBjb25kaXRpb24uIEkgZG9u J3Qgc2VlIGEgY2FzZSB3aGVyZSB0aGUgaW5mb3JtYXRpb24gc2hhcmVkIGlzIE5PVCBQSUksIGFu ZCB0aGVyZWZvcmUgbGVnYWwgYWdyZWVtZW50cyBhYm91dCBpbmZvcm1hdGlvbg0KIHNoYXJpbmcg YW5kIHVzZXIgY29uc2VudCBtdXN0IGFsd2F5cyBiZSBpbiBwbGFjZS48bzpwPjwvbzpwPjwvc3Bh bj48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAw MjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPk1pa2UmZ3Q7IFdlIHNob3VsZCBzdGF5IGNvbXBs ZXRlbHkgY2xlYXIgb2Ygc3BlY2lmeWluZyB3aGF0IGFwcGxpY2F0aW9ucyBhbmQgcHJvdG9jb2xz IG11c3QgZG8gd2l0aCBTRVRzLiZuYnNwOyBJdOKAmXMgdXAgdG8gdGhlbSB0byBwcm9maWxlIFNF VHMgc28gdGhhdCB0aGUgYXBwbGljYXRpb27igJlzIHByaXZhY3kgYW5kIHNlY3VyaXR5IHByb3Bl cnRpZXMgYXJlIG1haW50YWluZWQsDQogd2hpY2ggd2lsbCBkaWZmZXIgYmV0d2VlbiBhcHBsaWNh dGlvbnMuJm5ic3A7IEp1c3QgbGlrZSB3aGV0aGVyIOKAnGFsZ+KAnTog4oCcbm9uZeKAnSBpcyBh cHByb3ByaWF0ZSBpcyBhIHByb3RvY29sL2FwcGxpY2F0aW9uIGRlY2lzaW9uLCBpdOKAmXMgYWxz byBhIHByb3RvY29sL2FwcGxpY2F0aW9uIGRlY2lzaW9uIHdoZXRoZXIgZW5jcnlwdGlvbiBpcyBu ZWVkZWQsIGRlcGVuZGluZyB1cG9uIHRoZSBjb250ZXh0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJk aXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO2xpbmUt aGVpZ2h0OjIwLjI1cHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzE7Ym94LXNpemluZzogYm9yZGVy LWJveDtjdXJzb3I6ZGVmYXVsdCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250 LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90OyxzYW5zLXNlcmlmIj40OiBJIGRvbid0IHRoaW5r IHRoZSBzdWJqZWN0IGluZm9ybWF0aW9uIGlzICZxdW90O3BlcmNlaXZlZCZxdW90OyBhcyBQSUku IEl0IGlzIFBJSSwgb3RoZXJ3aXNlIGl0IHdvdWxkIGJlIHVzZWxlc3MgdG8gdGhlIHN1YnNjcmli ZXIsIGJlY2F1c2UgdGhlIHN1YnNjcmliZXIgd291bGQgbm90IGJlIGFibGUgdG8gaWRlbnRpZnkg dGhlIHN1YmplY3QuIEFsc28sDQogZXZlbiBpZiB0aGUgaW5mb3JtYXRpb24gb24gdGhlIHdpcmUg aXMgbm90IGluIGl0c2VsZiBQSUksIGUuZy4gd2hlbiB1c2luZyBhIGhhc2gsIHRoZSBmYWN0IHRo YXQgYSBwdWJsaXNoZXIgc2hhcmVzIGluZm9ybWF0aW9uIHRoYXQgYSBwYXJ0aWN1bGFyIHVzZXIg aXMgYWxzbyBhIHVzZXIgb24gaXRzIHN5c3RlbSBhbmQgaXMgdW5kZXJnb2luZyBjZXJ0YWluIHN0 YXRlIGNoYW5nZXMgaXMgcHJpdmFjeS1zZW5zaXRpdmUuPG86cD48L286cD48L3NwYW4+PC9saT48 L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMDAyMDYwIj5NaWtlJmd0OyBQZXIgbXkgcHJldmlvdXMgY29tbWVudCwgd2hh dOKAmXMgUElJIChvciBub3QpIGlzIHByb3RvY29sL2FwcGxpY2F0aW9uLXNwZWNpZmljIGFuZCBu b3QgYW4gYXBwcm9wcmlhdGUgdG9waWMgZm9yIHRoZSBTRVQgc3BlYy4mbmJzcDsgVGhlIGVkaXRv cnMgc2hvdWxkIHJlbW92ZSBhbnkgc3VjaCBsYW5ndWFnZSwgb3RoZXIgdGhhbiBwZXJoYXBzIGlu Zm9ybWF0aXZlDQogY29tbWVudHMgaW4gdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIGFuZCBQ cml2YWN5IENvbnNpZGVyYXRpb25zIHNlY3Rpb25zLCBsaXN0aW5nIHRoaW5ncyB0aGF0IHByb3Rv Y29sL2FwcGxpY2F0aW9uIGRlc2lnbmVycyBzaG91bGQgY29uc2lkZXIuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4i IHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDow aW47bGluZS1oZWlnaHQ6MjAuMjVwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMTtib3gtc2l6aW5n OiBib3JkZXItYm94O2N1cnNvcjpkZWZhdWx0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LHNhbnMtc2VyaWYiPkkgc3VnZ2Vz dCB0byBhZGQgYW4gSW1wbGVtZW50YXRpb24gU3RhdHVzIHNlY3Rpb24sIHBlciBSRkMgNzk0Mi48 bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4t Ym90dG9tOi4wMDAxcHQiPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46 MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFlhcm9uPG86cD48 L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxz cGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJj b2xvcjojMDAyMDYwIj5NaWtlJmd0OyBUaGFua3MgYWdhaW4gZm9yIHRoZSB0aG9yb3VnaCBhbmQg dGhvdWdodGZ1bCBjb21tZW50cywgWWFyb24hPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5 bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iY29sb3I6 IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjow aW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxz cGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BN3PR03MB2355F10CCD751A2B3FD03F9AF56B0BN3PR03MB2355namp_-- From nobody Thu Dec 29 11:51:55 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 912E012945D for ; Thu, 29 Dec 2016 11:51:53 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YEVt0c1jrgkp for ; Thu, 29 Dec 2016 11:51:51 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0129.outbound.protection.outlook.com [104.47.37.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A53481293E8 for ; Thu, 29 Dec 2016 11:51:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jvZYera3ErKntnlWcd3m8uxOh/kzKQt5cmtR/MH4zrU=; b=UdXCR8gr+WT/pDvk8R2mBuQtRsXlFEfv0EpBF+xsfImWv0cq6fd3yE+ZWQBwww65T2nu2cxatPOytLJ89o4ImanQiKxqy5vbuCeMSNeZQs2WWJdMoUNJio9yaEdky3JS/CiSEmr355WtqF9HAMZk/AQbYpxp/ANBj/SZvN3KPkg= Received: from BN3PR03MB2355.namprd03.prod.outlook.com (10.166.74.150) by BN3PR03MB2354.namprd03.prod.outlook.com (10.166.74.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.11; Thu, 29 Dec 2016 19:51:49 +0000 Received: from BN3PR03MB2355.namprd03.prod.outlook.com ([10.166.74.150]) by BN3PR03MB2355.namprd03.prod.outlook.com ([10.166.74.150]) with mapi id 15.01.0803.021; Thu, 29 Dec 2016 19:51:50 +0000 From: Mike Jones To: Yaron Sheffer , "Phil Hunt (IDM)" Thread-Topic: [Id-event] Draft adoption Thread-Index: AQHSYVKcHobL8+E+9ku0U8KcU6BpqqEd6cMAgAAnyCCAAQ/8gIAANKdg Date: Thu, 29 Dec 2016 19:51:49 +0000 Message-ID: References: <6f4b8e65-852a-49e3-dbaf-d3ef5039c7c8@gmail.com> <67CF49D1-E59E-4297-87FE-EF651C5B0160@oracle.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.95.25] x-ms-office365-filtering-correlation-id: c2d239bc-2306-48c7-1237-08d43024213a x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN3PR03MB2354; x-microsoft-exchange-diagnostics: 1; BN3PR03MB2354; 7:nrgNsHFNeLo406ngIXCeHSq/XKKCMxaCdrmmLNyOqHQzdWu4nrOISiUARA0IPOuehm4OgWfl3Bddcat3S1HHdj9bYQ/O4c3AiHcdi6guBbANdS3wqVFx875PR77IV2gMu2aU/bkjCSF4CR27GVFbZQW+vIKtnzCfLd6I02NroFKmoBjCvE3ZGGGhFIjk3hwgX7DfFjujFeubsZuumKdpb0OAvPp7kiujJrM3fhlLVOO1nheB5VqcMDOT96UfPLqaO8cNLwxGY94PZOY84ItInfz7IGmfJ8nbAEV5mh8IG/ucqyRIiSAzGfFG/3hUeLGrmS+QAdgJ9w7XBDh+I4HcgzgUxtqyCbBaxHgpe1tH8T2c2DYmdZGKBmKX+0Yewn+/uGXBiHCo/NaxkH2AL7ibm3AxQgGXwwI4WgmsBnJ1X+L7xLMyILJFAVQBSXqcXOQ8mZIkopoC3DbqXzmLQ+MtyliZoEzvfkE5gdZcP6O55x0= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(100405760836317)(146099531331640); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123560025)(20161123564025)(20161123555025)(6047074)(6042181)(6072148); SRVR:BN3PR03MB2354; BCL:0; PCL:0; RULEID:; SRVR:BN3PR03MB2354; x-forefront-prvs: 01713B2841 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(13464003)(24454002)(199003)(189002)(51444003)(377454003)(53754006)(57704003)(86612001)(97736004)(10290500002)(5660300001)(77096006)(5001770100001)(55016002)(105586002)(86362001)(7696004)(93886004)(33656002)(106116001)(74316002)(2900100001)(122556002)(7736002)(2950100002)(102836003)(99286003)(305945005)(10090500001)(106356001)(6116002)(3846002)(5005710100001)(50986999)(561944003)(8990500004)(229853002)(9686002)(8936002)(81166006)(92566002)(4326007)(2906002)(68736007)(66066001)(81156014)(54356999)(101416001)(3280700002)(38730400001)(8676002)(25786008)(3660700001)(6506006)(39060400001)(6436002)(189998001)(76176999); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR03MB2354; H:BN3PR03MB2355.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Dec 2016 19:51:49.7940 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR03MB2354 Archived-At: Cc: ID Events Mailing List Subject: Re: [Id-event] Draft adoption X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2016 19:51:53 -0000 SSBhZ3JlZSB3aXRoIHlvdSB0aGF0IHdlIHdhbnQgdG8gdXNlIEpTT04gc3ludGF4IGluIGEgbmF0 dXJhbCB3YXksIFlhcm9uLiAgSW4gZmFjdCwgaXQgd2FzIHRob3NlIGNvbnNpZGVyYXRpb25zIHRo YXQgbGVkIHVzIHRvIHRoZSBjdXJyZW50IHN5bnRheCwgaGF2aW5nIG1vdmVkIGF3YXkgZnJvbSB0 aGUgcHJldmlvdXMgYXJyYXkgc3ludGF4Lg0KDQpUaGUgY3VycmVudCAiZXZlbnRzIiBjbGFpbSBz eW50YXggY2xlYW5seSBhbmQgY29uY2lzZWx5IHJlcHJlc2VudHMgYSBzZXQgb2YgcmVsYXRlZCBl dmVudHMuICBUaGV5IGFyZSB1bm9yZGVyZWQgYnkgZGVzaWduLCB3aXRoIG5vICJwcmltYXJ5IiBl dmVudC4gIEkgYWdyZWUgdGhhdCB0aGUgZWRpdG9ycyAobXlzZWxmIGluY2x1ZGVkKSBoYXZlIHdv cmsgdG8gZG8gdG8gZmluaXNoIHJlbW92aW5nIHRoZSB2ZXN0aWdlcyBvZiB0aGUgb2xkIHN5bnRh eCwgaW4gd2hpY2ggZXZlbnRzIHdlcmUgb3JkZXJlZC4gIEkgdGhpbmsgdGhhdCB0aGUgc3BlYyB3 aWxsIGJlIG11Y2ggbGVzcyBjb25mdXNpbmcgYWZ0ZXIgdGhhdC4gIEkgYWdyZWUgd2l0aCB5b3Vy IGRlY2lzaW9uIGZvciB1cyB0byBwcm9kdWNlIGEgbmV3LCBjbGVhbmVyIGluZGl2aWR1YWwgZHJh ZnQgYmVmb3JlIGFkb3B0aW9uIGFzIGEgd29ya2luZyBncm91cCBkb2N1bWVudC4gIFRoYW5rcyBm b3IgdXJnaW5nIHVzIHRvIGdldCBpdCByaWdodCENCg0KCQkJCUNoZWVycywNCgkJCQktLSBNaWtl DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBZYXJvbiBTaGVmZmVyIFttYWls dG86eWFyb25mLmlldGZAZ21haWwuY29tXSANClNlbnQ6IFRodXJzZGF5LCBEZWNlbWJlciAyOSwg MjAxNiA4OjM5IEFNDQpUbzogTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29t PjsgUGhpbCBIdW50IChJRE0pIDxwaGlsLmh1bnRAb3JhY2xlLmNvbT4NCkNjOiBJRCBFdmVudHMg TWFpbGluZyBMaXN0IDxpZC1ldmVudEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbSWQtZXZlbnRd IERyYWZ0IGFkb3B0aW9uDQoNCkhpIE1pa2UsDQoNCihjaGFpciBoYXQgb24pOiBJJ20gYWJzb2x1 dGVseSBPSyB3aXRoIHlvdXIgcHJvY2VzcyBwcm9wb3NhbC4NCg0KKGhhdCBvZmYpOiBFeGN1c2Ug Zm9yIGZvciBiZWluZyBwZWRhbnRpYyBhYm91dCBKU09OIHN5bnRheC4gSWYgd2Ugd2FudCB0byBz dXBwb3J0IG11bHRpcGxlIGV2ZW50cywgdGhpcyBzaG91bGQgYmUgYW4gYXJyYXksIG5vdCBhbiBv YmplY3QuIFRoaXMgaW5kaWNhdGVzIGFuIG9yZGVyaW5nIGJldHdlZW4gZXZlbnRzLCBhbmQgYWxz byBhbGxvd3MgY2xlYW4gaGFuZGxpbmcgb2YgbXVsdGlwbGUgZXZlbnRzIG9mIHRoZSBzYW1lIHR5 cGUuDQoNCkkgd2lsbCBsZXQgb3RoZXJzIGRlY2lkZSB3aGV0aGVyIHdlIG5lZWQgYSBzaW5nbGUg ZXZlbnQgcGVyIFNFVCBvciBtdWx0aXBsZS4NCg0KVGhhbmtzLA0KCVlhcm9uDQoNCk9uIDI5LzEy LzE2IDAyOjMxLCBNaWtlIEpvbmVzIHdyb3RlOg0KPiBJ4oCZbSBub3QgaGFwcHkgd2l0aCB0aGlz IHByb3Bvc2VkIGNoYW5nZS4gIEl0IHNlZW1zIHRvIGJlIG92ZXJseSANCj4gY29tcGxpY2F0aW5n IHdoYXQgd2FzIGZvcm1lcmx5IGEgc2ltcGxlIHN0cnVjdHVyZS4NCj4NCj4NCj4NCj4gSSBiZWxp ZXZlIOKAnGV2ZW50c+KAnSByZW1haW5zIHRoZSByaWdodCBzeW50YXguICBJdCBhbGxvd3MgbXVs dGlwbGUgDQo+IHJlbGF0ZWQgZXZlbnRzIHRvIGJlIGNsZWFubHkgZXhwcmVzc2VkLg0KPg0KPg0K Pg0KPiBSYXRoZXIgdGhhbiB0cnlpbmcgdG8gZGlmZmVyZW50aWF0ZSBiZXR3ZWVuIOKAnHByaW1h cnnigJ0gYW5kIOKAnHNlY29uZGFyeeKAnQ0KPiBldmVudHMsIEkgd291bGQgY291bnRlci1wcm9w b3NlIHRoYXQgd2UgZHJvcCB0aGUgZGlzdGluY3Rpb24gZW50aXJlbHkuDQo+IEFsbCB0aGUgcmVs YXRlZCBldmVudHMgbGlzdGVkIGluIHRoZSDigJxldmVudHPigJ0gc3RydWN0IG9jY3VycmVkLiAg DQo+IFdoZXRoZXIgb25lIGlzIOKAnHByaW1hcnnigJ0gaXMgYXJndWFibHkgdW5pbXBvcnRhbnQs IHNpbmNlIHRoZSANCj4gY29tbXVuaWNhdGluZyBwYXJ0aWVzIHdpbGwgcHJvY2VzcyBhbGwgdGhl IGluZm9ybWF0aW9uIHNlbnQgZm9yIGFsbCANCj4gdGhlIHJlbGF0ZWQgZXZlbnRzLiAgTGV04oCZ cyBzaW1wbGlmeSB0aGluZ3MgYnkgcmVtb3ZpbmcgdGhlIA0KPiBwcmltYXJ5L3NlY29uZGFyeSBk aXN0aW5jdGlvbiwgcmF0aGVyIHRoYW4gY29tcGxpY2F0aW5nIHRoaW5ncyBieSBoYXZpbmcgdHdv IHJlbGF0ZWQgc3ludGF4ZXMuDQo+DQo+DQo+DQo+IEnigJltIGFsc28gZ29pbmcgdG8gcmFpc2Ug YSBwcm9jZXNzIHBvaW50LiAgSSBrbm93IHRoYXQgSSBoYXZlbuKAmXQgcmVhZCANCj4gb3IgcmVz cG9uZGVkIHRvIFlhcm9u4oCZcyBjb21tZW50cyB5ZXQgYmVjYXVzZSB0aGV5IGNhbWUgaW4gZHVy aW5nIHRoZSANCj4gaG9saWRheXMuICBJIHN1c3BlY3QgdGhpcyBpcyB0cnVlIG9mIG1hbnkgb3Ro ZXJzIGFzIHdlbGwuICBCZWZvcmUgDQo+IG1ha2luZyBhbnkgYnJlYWtpbmcgY2hhbmdlcywgSeKA mWQgYXNrIHRoYXQgd2UgaGF2ZSBhIGxlYXN0IGEgd2Vla+KAmXMgDQo+IGRpc2N1c3Npb24gcGVy aW9kIGFmdGVyIEphbnVhcnkgMl5uZCAuDQo+DQo+DQo+DQo+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBUaGFua3MsDQo+DQo+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQo+ DQo+DQo+DQo+ICpGcm9tOiogSWQtZXZlbnQgW21haWx0bzppZC1ldmVudC1ib3VuY2VzQGlldGYu b3JnXSAqT24gQmVoYWxmIE9mIA0KPiAqUGhpbCBIdW50IChJRE0pDQo+ICpTZW50OiogV2VkbmVz ZGF5LCBEZWNlbWJlciAyOCwgMjAxNiAyOjAzIFBNDQo+ICpUbzoqIFlhcm9uIFNoZWZmZXIgPHlh cm9uZi5pZXRmQGdtYWlsLmNvbT4NCj4gKkNjOiogSUQgRXZlbnRzIE1haWxpbmcgTGlzdCA8aWQt ZXZlbnRAaWV0Zi5vcmc+DQo+ICpTdWJqZWN0OiogUmU6IFtJZC1ldmVudF0gRHJhZnQgYWRvcHRp b24NCj4NCj4NCj4NCj4gSSBwcm9wb3NlIHdlIGhhdmUgdHdvIGF0dHJpYnV0ZXMgYWxvbmcgdGhl IGxpbmVzIG9mOg0KPg0KPg0KPg0KPiAiZXZ0IiBhIHJlcXVpcmVkIHN0cmluZyBVUkkgZGVzY3Jp YmluZyB0aGUgcHJpbWFyeSBldmVudA0KPg0KPg0KPg0KPiAiZXh0IiBhbiBvcHRpb25hbCBtdWx0 aSB2YWx1ZWQgc3RyaW5nIGNvbnRhaW5pbmcgb25lIG9yIG1vcmUgDQo+IGV4dGVuc2lvbnMgVVJJ cyB0byB0aGUgcHJpbWFyeSBldmVudC4NCj4NCj4gSWYgYWdyZWVhYmxlLCBJIHdpbGwgcHJvcG9z ZSBzb21lIGZpbmFsIHdvcmRpbmcuDQo+DQo+DQo+DQo+IE5vdGUgdGhhdCB0aGlzIGlzIGEgYnJl YWtpbmcgY2hhbmdlIGFuZCB3aWxsIG1lYW4gdGhhdCBpdCB3aWxsIG5vIA0KPiBsb25nZXIgcG9z c2libGUgdG8gZXhwcmVzcyBtdWx0aXBsZSBldmVudHMgYWJvdXQgdGhlIHNhbWUgc3RhdGUgY2hh bmdlIA0KPiBvciBvYnNlcnZhdGlvbiBpbiBvbmUgSldUIHVubGVzcyBvbmUgaXMgYW4gZXh0ZW5z aW9uIG9mIHRoZSBvdGhlci4NCj4NCj4NCj4NCj4gQmVjYXVzZSBvZiB0aGUgZGVwZW5kZW5jZSBp c3N1ZSBkbyB3ZSBuZWVkIHRvIGFsc28gcmV2ZXJ0IGJhY2sgdG8gdGhlIA0KPiBJQU5BIGV2ZW50 IHJlZ2lzdHJ5IHByb3Bvc2VkIGluIHRoZSBvcmlnaW5hbCBkcmFmdHM/DQo+DQo+DQo+DQo+IFBo aWwNCj4NCj4NCj4gT24gRGVjIDI4LCAyMDE2LCBhdCAxOjM3IFBNLCBZYXJvbiBTaGVmZmVyIDx5 YXJvbmYuaWV0ZkBnbWFpbC5jb20gDQo+IDxtYWlsdG86eWFyb25mLmlldGZAZ21haWwuY29tPj4g d3JvdGU6DQo+DQo+ICAgICBIaSBldmVyeW9uZSwNCj4NCj4gICAgIFRoZSBjaGFpcnMgd291bGQg bGlrZSB0byBwb2xsIHRoZSBXRyByZWdhcmRpbmcgYWRvcHRpb24gb2YNCj4gICAgIGRyYWZ0LWh1 bnQtaWRldmVudC10b2tlbi0wNywgaG93ZXZlciB3ZSBib3RoIGZlZWwgdGhhdCBvbmUgbW9yZQ0K PiAgICAgcmV2aXNpb24gd291bGQgYmUgdXNlZnVsIGJlZm9yZSB3ZSBkbyB0aGF0LiBXZSBhc2sg dGhlIGVkaXRvcnMgdG8NCj4gICAgIGZvY3VzIHRoaXMgcmV2aXNpb24gb24gdGhlIHN5bnRheCBv ZiB0aGUgImV2ZW50cyIgKG9yICJldmVudCIpIEpTT04NCj4gICAgIHN0cnVjdHVyZSBhbmQgaG93 IGl0IHJlZmxlY3RzIGFuIGV2ZW50IGFuZCBpdHMgZXh0ZW5zaW9ucy4gVGhpcyBpcw0KPiAgICAg dG8gZW5zdXJlIHdlIGhhdmUgYSBtb3JlIHNvbGlkIGJhc2VsaW5lIHByb3Bvc2FsIGJlZm9yZSB3 ZSBzdGFydCB0aGUNCj4gICAgIGNvbnNlbnN1cyBwcm9jZXNzLg0KPg0KPiAgICAgSGFwcHkgTmV3 IFllYXIgMjAxNyENCj4NCj4gICAgICAgICBEaWNrIGFuZCBZYXJvbg0KPg0KPiAgICAgX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gICAgIElkLWV2ZW50 IG1haWxpbmcgbGlzdA0KPiAgICAgSWQtZXZlbnRAaWV0Zi5vcmcgPG1haWx0bzpJZC1ldmVudEBp ZXRmLm9yZz4NCj4gICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQt ZXZlbnQNCj4NCg== From nobody Thu Dec 29 12:00:37 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB55D129A0C for ; Thu, 29 Dec 2016 12:00:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.301 X-Spam-Level: X-Spam-Status: No, score=-7.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TU7z8MmMIcuD for ; Thu, 29 Dec 2016 12:00:32 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 DC6FD129608 for ; Thu, 29 Dec 2016 12:00:25 -0800 (PST) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id uBTK0Nxp029664 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 29 Dec 2016 20:00:23 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id uBTK0MuA010770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Dec 2016 20:00:23 GMT Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id uBTK0K6C029328; Thu, 29 Dec 2016 20:00:21 GMT Received: from [192.168.1.16] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Dec 2016 12:00:20 -0800 Content-Type: multipart/alternative; boundary="Apple-Mail=_806EF8CE-8580-4374-B43F-0E55E930959D" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Phil Hunt In-Reply-To: Date: Thu, 29 Dec 2016 12:00:18 -0800 Message-Id: References: <6f4b8e65-852a-49e3-dbaf-d3ef5039c7c8@gmail.com> <67CF49D1-E59E-4297-87FE-EF651C5B0160@oracle.com> To: Mike Jones X-Mailer: Apple Mail (2.3124) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: Yaron Sheffer , ID Events Mailing List Subject: Re: [Id-event] Draft adoption X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2016 20:00:36 -0000 --Apple-Mail=_806EF8CE-8580-4374-B43F-0E55E930959D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 +1 Phil @independentid www.independentid.com = phil.hunt@oracle.com = > On Dec 29, 2016, at 11:51 AM, Mike Jones = wrote: >=20 > I agree with you that we want to use JSON syntax in a natural way, = Yaron. In fact, it was those considerations that led us to the current = syntax, having moved away from the previous array syntax. >=20 > The current "events" claim syntax cleanly and concisely represents a = set of related events. They are unordered by design, with no "primary" = event. I agree that the editors (myself included) have work to do to = finish removing the vestiges of the old syntax, in which events were = ordered. I think that the spec will be much less confusing after that. = I agree with your decision for us to produce a new, cleaner individual = draft before adoption as a working group document. Thanks for urging us = to get it right! >=20 > Cheers, > -- Mike >=20 > -----Original Message----- > From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com]=20 > Sent: Thursday, December 29, 2016 8:39 AM > To: Mike Jones ; Phil Hunt (IDM) = > Cc: ID Events Mailing List > Subject: Re: [Id-event] Draft adoption >=20 > Hi Mike, >=20 > (chair hat on): I'm absolutely OK with your process proposal. >=20 > (hat off): Excuse for for being pedantic about JSON syntax. If we want = to support multiple events, this should be an array, not an object. This = indicates an ordering between events, and also allows clean handling of = multiple events of the same type. >=20 > I will let others decide whether we need a single event per SET or = multiple. >=20 > Thanks, > Yaron >=20 > On 29/12/16 02:31, Mike Jones wrote: >> I=E2=80=99m not happy with this proposed change. It seems to be = overly=20 >> complicating what was formerly a simple structure. >>=20 >>=20 >>=20 >> I believe =E2=80=9Cevents=E2=80=9D remains the right syntax. It = allows multiple=20 >> related events to be cleanly expressed. >>=20 >>=20 >>=20 >> Rather than trying to differentiate between =E2=80=9Cprimary=E2=80=9D = and =E2=80=9Csecondary=E2=80=9D >> events, I would counter-propose that we drop the distinction = entirely. >> All the related events listed in the =E2=80=9Cevents=E2=80=9D struct = occurred. =20 >> Whether one is =E2=80=9Cprimary=E2=80=9D is arguably unimportant, = since the=20 >> communicating parties will process all the information sent for all=20= >> the related events. Let=E2=80=99s simplify things by removing the=20 >> primary/secondary distinction, rather than complicating things by = having two related syntaxes. >>=20 >>=20 >>=20 >> I=E2=80=99m also going to raise a process point. I know that I = haven=E2=80=99t read=20 >> or responded to Yaron=E2=80=99s comments yet because they came in = during the=20 >> holidays. I suspect this is true of many others as well. Before=20 >> making any breaking changes, I=E2=80=99d ask that we have a least a = week=E2=80=99s=20 >> discussion period after January 2^nd . >>=20 >>=20 >>=20 >> Thanks, >>=20 >> -- Mike >>=20 >>=20 >>=20 >> *From:* Id-event [mailto:id-event-bounces@ietf.org] *On Behalf Of=20 >> *Phil Hunt (IDM) >> *Sent:* Wednesday, December 28, 2016 2:03 PM >> *To:* Yaron Sheffer >> *Cc:* ID Events Mailing List >> *Subject:* Re: [Id-event] Draft adoption >>=20 >>=20 >>=20 >> I propose we have two attributes along the lines of: >>=20 >>=20 >>=20 >> "evt" a required string URI describing the primary event >>=20 >>=20 >>=20 >> "ext" an optional multi valued string containing one or more=20 >> extensions URIs to the primary event. >>=20 >> If agreeable, I will propose some final wording. >>=20 >>=20 >>=20 >> Note that this is a breaking change and will mean that it will no=20 >> longer possible to express multiple events about the same state = change=20 >> or observation in one JWT unless one is an extension of the other. >>=20 >>=20 >>=20 >> Because of the dependence issue do we need to also revert back to the=20= >> IANA event registry proposed in the original drafts? >>=20 >>=20 >>=20 >> Phil >>=20 >>=20 >> On Dec 28, 2016, at 1:37 PM, Yaron Sheffer > > wrote: >>=20 >> Hi everyone, >>=20 >> The chairs would like to poll the WG regarding adoption of >> draft-hunt-idevent-token-07, however we both feel that one more >> revision would be useful before we do that. We ask the editors to >> focus this revision on the syntax of the "events" (or "event") = JSON >> structure and how it reflects an event and its extensions. This is >> to ensure we have a more solid baseline proposal before we start = the >> consensus process. >>=20 >> Happy New Year 2017! >>=20 >> Dick and Yaron >>=20 >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >>=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event --Apple-Mail=_806EF8CE-8580-4374-B43F-0E55E930959D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 +1




On Dec 29, 2016, at 11:51 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

I = agree with you that we want to use JSON syntax in a natural way, Yaron. =  In fact, it was those considerations that led us to the current = syntax, having moved away from the previous array syntax.

The current "events" claim syntax cleanly and = concisely represents a set of related events.  They are unordered = by design, with no "primary" event.  I agree that the editors = (myself included) have work to do to finish removing the vestiges of the = old syntax, in which events were ordered.  I think that the spec = will be much less confusing after that.  I agree with your decision = for us to produce a new, cleaner individual draft before adoption as a = working group document.  Thanks for urging us to get it right!

Cheers,
-- = Mike

-----Original Message-----
From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com]
Sent: = Thursday, December 29, 2016 8:39 AM
To: Mike Jones <Michael.Jones@microsoft.com>; Phil Hunt (IDM) <phil.hunt@oracle.com>
Cc: ID Events = Mailing List <id-event@ietf.org>
Subject: Re: = [Id-event] Draft adoption

Hi Mike,

(chair hat on): I'm absolutely OK with your = process proposal.

(hat off): Excuse for for = being pedantic about JSON syntax. If we want to support multiple events, = this should be an array, not an object. This indicates an ordering = between events, and also allows clean handling of multiple events of the = same type.

I will let others decide whether = we need a single event per SET or multiple.

Thanks,
Yaron

On 29/12/16 02:31, Mike Jones wrote:
I=E2=80=99m not happy with this proposed = change.  It seems to be overly
complicating what was = formerly a simple structure.



I believe =E2=80=9Cevents=E2=80=9D remains the = right syntax.  It allows multiple
related events to = be cleanly expressed.



Rather than trying to differentiate between =E2=80=9Cprimary=E2= =80=9D and =E2=80=9Csecondary=E2=80=9D
events, I would = counter-propose that we drop the distinction entirely.
All = the related events listed in the =E2=80=9Cevents=E2=80=9D struct = occurred.  
Whether one is =E2=80=9Cprimary=E2=80=9D = is arguably unimportant, since the
communicating parties = will process all the information sent for all
the related = events.  Let=E2=80=99s simplify things by removing the
primary/secondary distinction, rather than complicating = things by having two related syntaxes.



I=E2=80=99m also going to raise a process = point.  I know that I haven=E2=80=99t read
or = responded to Yaron=E2=80=99s comments yet because they came in during = the
holidays.  I suspect this is true of many others = as well.  Before
making any breaking changes, I=E2=80=99= d ask that we have a least a week=E2=80=99s
discussion = period after January 2^nd .



=             &n= bsp;           &nbs= p;            =             &n= bsp;    Thanks,

=             &n= bsp;           &nbs= p;            =             &n= bsp;    -- Mike



*From:* Id-event [mailto:id-event-bounces@ietf.org] *On Behalf Of
*Phil Hunt (IDM)
*Sent:* Wednesday, December = 28, 2016 2:03 PM
*To:* Yaron Sheffer <yaronf.ietf@gmail.com>
*Cc:* ID Events = Mailing List <id-event@ietf.org>
*Subject:* Re: = [Id-event] Draft adoption



I propose we have two attributes along the lines of:



"evt" a required = string URI describing the primary event



"ext" an optional multi valued string = containing one or more
extensions URIs to the primary = event.

If agreeable, I will propose some = final wording.



Note that this is a breaking change and will mean that it = will no
longer possible to express multiple events about = the same state change
or observation in one JWT unless = one is an extension of the other.



Because of the dependence issue do we need to = also revert back to the
IANA event registry proposed in = the original drafts?



Phil


On Dec 28, = 2016, at 1:37 PM, Yaron Sheffer <yaronf.ietf@gmail.com=
<mailto:yaronf.ietf@gmail.com>> wrote:

   Hi everyone,

   The chairs would like to = poll the WG regarding adoption of
=    draft-hunt-idevent-token-07, however we both feel that = one more
   revision would be useful = before we do that. We ask the editors to
=    focus this revision on the syntax of the "events" (or = "event") JSON
   structure and how it = reflects an event and its extensions. This is
=    to ensure we have a more solid baseline proposal = before we start the
   consensus = process.

   Happy New Year = 2017!

=        Dick and Yaron
=    _______________________________________________
   Id-event mailing list
=    Id-event@ietf.org <mailto:Id-event@ietf.org>
=    https://www.ietf.org/mailman/listinfo/id-event

_______________________________________________Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event

= --Apple-Mail=_806EF8CE-8580-4374-B43F-0E55E930959D-- From nobody Thu Dec 29 12:19:29 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EDBB129647 for ; Thu, 29 Dec 2016 12:19:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.291 X-Spam-Level: X-Spam-Status: No, score=-7.291 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ZAmIVe8mEKW for ; Thu, 29 Dec 2016 12:19:25 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 B4D06129499 for ; Thu, 29 Dec 2016 12:19:25 -0800 (PST) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id uBTKJMAR013264 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 29 Dec 2016 20:19:23 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id uBTKJMw3015888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 29 Dec 2016 20:19:22 GMT Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id uBTKJMqj031950; Thu, 29 Dec 2016 20:19:22 GMT Received: from [192.168.1.16] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Dec 2016 12:19:21 -0800 Content-Type: multipart/alternative; boundary="Apple-Mail=_ADBB2CF0-F622-414F-95A2-63035DB1E470" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Phil Hunt In-Reply-To: Date: Thu, 29 Dec 2016 12:19:20 -0800 Message-Id: <012A438F-2CFE-4BBC-86A1-41BB11B373BE@oracle.com> References: <9114f681-cba9-b6d3-8369-ccd9193ce1b8@gmail.com> To: Mike Jones X-Mailer: Apple Mail (2.3124) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: Yaron Sheffer , SecEvent Subject: Re: [Id-event] Some comments to draft-hunt-idevent-token-07 X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2016 20:19:28 -0000 --Apple-Mail=_ADBB2CF0-F622-414F-95A2-63035DB1E470 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 [personal hat] +1 [editor hat] I=E2=80=99ll await chair instruction on what to modify before/after = adoption etc. The clean-up and consistency issues can happen as soon as some of these = decisions are clarified as the formal consensus. At the moment we=E2=80=99= re kind of stuck in between =E2=80=9Cstyles=E2=80=9D. I note there may be some resistance to change now as I understand some = implementation and testing is already under way =E2=80=94 which is why I = singled the =E2=80=9Cbreaking=E2=80=9D change. Phil @independentid www.independentid.com = phil.hunt@oracle.com = > On Dec 29, 2016, at 11:47 AM, Mike Jones = wrote: >=20 > I=E2=80=99m replying to Yaron=E2=80=99s original message so the result = will be short enough to be quickly readable, while acknowledging that = Phil already made many points in his responses that I agree with. Where = I don=E2=80=99t have anything to add to Phil=E2=80=99s responses, I = don=E2=80=99t include a response to those points. My replies are = prefixed by =E2=80=9CMike>=E2=80=9D. > =20 > Thanks for taking the time to do a thorough read, Yaron! > =20 > -- Mike > =C2=A0 <> > From: Id-event [mailto:id-event-bounces@ietf.org = ] On Behalf Of Yaron Sheffer > Sent: Saturday, December 10, 2016 1:28 PM > To: SecEvent > > Subject: [Id-event] Some comments to draft-hunt-idevent-token-07 > =20 > Hi, I finally read the draft in detail, and I do have a few comments. > My main suggestion is to tighten the specification of an Event, by = defining more strictly the difference between "event" and "event = extension" and tweaking the JSON structure a bit. > =20 > Mike> Per my reply in the thread =E2=80=9C[Id-event] Draft = adoption=E2=80=9D, I think we=E2=80=99d be better off completely = dropping the distinction between primary events and secondary events. = When applications send a set of related events together, it=E2=80=99s = logical for recipients to process all of them (or all of them that they = understand). The primary/secondary distinction is unhelpful and leads = to complication, rather than clarity or simplification. Let=E2=80=99s = drop it entirely. > =20 > In addition, I think we should require the claim to be signed, since = it will be used for security-sensitive activities across complex = distributed systems. > 1: Why is signing optional? The publisher doesn't know how the = subscriber's system is architected, and might well want end-to-end = authentication of the claim. This is also important for auditing. > =20 > Mike> This is ground already well-covered during both the JOSE [RFC = 7515] and JWT [RFC 7519] standardization efforts. The key observation = is that JWT (and SET) is a data structure to be used in protocols and = applications =E2=80=93 not a protocol or application specification. = It=E2=80=99s up to protocol and application specifications to define = whether signing is needed (and if so, with what algorithms). In some = cases, it won=E2=80=99t be needed because the JWT/SET is already = integrity protected by the protocol or application =E2=80=93 for = instance, by TLS. Just like for JWT, we shouldn=E2=80=99t require = signing in cases that it adds no value but does add overhead. A working = group consensus call confirmed the need for the ability to use = =E2=80=9Calg=E2=80=9D:=E2=80=9Cnone=E2=80=9D for JWS objects. > =20 > 1: "example events" - is specification of individual events (maybe = only a few basic ones) within scope of our charter? Otherwise we cannot = guarantee interop. > =20 > Mike> I agree with Phil=E2=80=99s response that interop happens within = applications and protocols using SETs. > =20 > 1.2: principle -> principal > 2: "first value" is meaningless. JSON objects are unordered (4th = paragraph of RFC 7159). If order is important, we could make "events" = into an array. > =20 > Mike> Order is unimportant. This was already widely discussed on the = id-event list. While we used to use an array representation, a = conscious choice was made to move to the current =E2=80=9Cset of = events=E2=80=9D syntax, replacing the old =E2=80=9Carray of events=E2=80=9D= syntax. > =20 > 2: event extensions are not defined but only introduced by the text = after they are described. Also, in the example there's this URL: = https://=E2=80=8Bexample.=E2=80=8Bcom/=E2=80=8Bscim/=E2=80=8Bevent/=E2=80=8B= pas=E2=80=8Bswor=E2=80=8BdRes=E2=80=8BetEx=E2=80=8Bt = - I believe it needs to be part = of the passwordReset object and not parallel to it. > =20 > Mike> The =E2=80=9Cevent extensions=E2=80=9D language is a holdover = from when there was an array of events and the first event was somehow = special. I agree that we need to perform editorial surgery to clean = this up, because it is currently misleading. > =20 > Why "events" and not "event"? We don't really have support for = multiple events. Certainly not if they are all of the same type. The = current text is confusing: "events" is not the same as "a primary event = and its extensions". > =20 > Mike> What=E2=80=99s being represented is a set of related events from = the same issuer. Again, the extensions language is misleading, and = needs to be fixed. > =20 > "In the above example "iss" and "sub" contained within the claim" - = this is incorrect, probably leftover from an earlier version. > =20 > Mike> I agree with Phil=E2=80=99s points. The editors can work on = this to make the intent clearer. > =20 > "aud" MAY be a URI: shouldn't it be an array, maybe an array that = contains a single URI? > Why do we use the terms "single-valued" vs. "multiple-valued" strings? = Why not use the normal JSON terminology, "string" vs. "array of = strings"? > Why is "sub" optional? Do we have any good examples of events where = this value is not required? > "a future date" - we should clarify that there may be cases when nbf = is smaller than iat, i.e. when it takes some time until the SET is = issued. > "exp" - is it also a NumericDate? Please specify. > In the medical example, it is strange that the event is named by a URL = that points to an HTML page. I would expect a more stable URI. > 2.2: is encryption a MUST whenever there are attributes specified? If = so, we should have a normative section saying so, not just mention it in = the context of an example. Besides, we have not defined what attributes = are. > 2.2: this section is confusing. We first say that the JWT must be = encrypted. But then instead, we sign it, and we "sign" with a null = algorithm. Why? > Signed SETs MUST (not MAY) be validated by the subscriber. > Also, I think we should remove the preconditions and always require = signing, as a MUST. An optional signature is actually a security = loophole because an attacker can remove the signature, and the = subscriber doesn't know that it's missing. > 3.2: "that alone will not guarantee that the correct subscribing party = knows they should have received a particular SET." The text is unclear = to me. Do we mean: "that alone does not guarantee that a particular SET = was delivered to the correct subscribing party"? > We may want a separate Implementation Considerations section, and move = "delivery", "sequencing" and "timing" into it. Yes they are = security-relevant, just like anything else in this document, but they = would apply just as well to any event stream protocol. > 3.3: this is the first time we mention provisioning. Do we really = intend SETs to be used for that? > 3.3: ISTM that we should define a sequencing mechanism, rather than = leave it open to profiles. E.g., require a sequence number whenever = "txn" is used. > 3.4: Also, our timestamps only have 1 second granularity, and so are = too coarse for session state (consider automated logins/logouts). > 3.5: Why don't we have an unambiguous way to distinguish SETs from = access tokens, why leave it to implementers? Sounds like a major = security issue in the making. We should consider here ALL = implementations that accept access tokens, including legacy = implementations that cannot be modified. > =20 > Mike> We do have an unambiguous manner of distinguishing SETs from = other JWTs =E2=80=93 the inclusion of the =E2=80=9Cevents=E2=80=9D = claim. OAuth access tokens are, by definition, opaque, and completely = outside of our scope of work. > =20 > 4: The audit happens on the subscriber side. By then it is too late to = require JWS to be used by the publisher. As mentioned, I propose that = JWS should ALWAYS be required. > 4: "When sharing personally identifiable information" - we should = remove this condition. I don't see a case where the information shared = is NOT PII, and therefore legal agreements about information sharing and = user consent must always be in place. > =20 > Mike> We should stay completely clear of specifying what applications = and protocols must do with SETs. It=E2=80=99s up to them to profile = SETs so that the application=E2=80=99s privacy and security properties = are maintained, which will differ between applications. Just like = whether =E2=80=9Calg=E2=80=9D: =E2=80=9Cnone=E2=80=9D is appropriate is = a protocol/application decision, it=E2=80=99s also a = protocol/application decision whether encryption is needed, depending = upon the context. > =20 > 4: I don't think the subject information is "perceived" as PII. It is = PII, otherwise it would be useless to the subscriber, because the = subscriber would not be able to identify the subject. Also, even if the = information on the wire is not in itself PII, e.g. when using a hash, = the fact that a publisher shares information that a particular user is = also a user on its system and is undergoing certain state changes is = privacy-sensitive. > =20 > Mike> Per my previous comment, what=E2=80=99s PII (or not) is = protocol/application-specific and not an appropriate topic for the SET = spec. The editors should remove any such language, other than perhaps = informative comments in the Security Considerations and Privacy = Considerations sections, listing things that protocol/application = designers should consider. > =20 > I suggest to add an Implementation Status section, per RFC 7942. > Thanks, > Yaron > =20 > Mike> Thanks again for the thorough and thoughtful comments, Yaron! > =20 > -- Mike > =20 --Apple-Mail=_ADBB2CF0-F622-414F-95A2-63035DB1E470 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
[personal hat]
+1

[editor hat]
I=E2=80= =99ll await chair instruction on what to modify before/after adoption = etc.

The = clean-up and consistency issues can happen as soon as some of these = decisions are clarified as the formal consensus.  At the moment = we=E2=80=99re kind of stuck in between =E2=80=9Cstyles=E2=80=9D.

I note there may be = some resistance to change now as I understand some implementation and = testing is already under way =E2=80=94 which is why I singled the = =E2=80=9Cbreaking=E2=80=9D change.

Phil



On Dec 29, 2016, at 11:47 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

I=E2=80=99m = replying to Yaron=E2=80=99s original message so the result will be short = enough to be quickly readable, while acknowledging that Phil already = made many points in his responses that I agree with.  Where I = don=E2=80=99t have anything to add to Phil=E2=80=99s responses, I = don=E2=80=99t include a response to those points.  My replies are = prefixed by =E2=80=9CMike>=E2=80=9D.
 
Thanks for = taking the time to do a thorough read, Yaron!
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;       -- Mike
 
From: Id-event = [mailto:id-event-bounces@ietf.org] On Behalf = Of Yaron = Sheffer
Sent: Saturday, December 10, 2016 = 1:28 PM
To: SecEvent <id-event@ietf.org>
Subject: [Id-event] Some comments to = draft-hunt-idevent-token-07
 
Hi, I finally read the draft in detail, and I = do have a few comments.
My main suggestion is to tighten the = specification of an Event, by defining more strictly the difference = between "event" and "event extension" and tweaking the JSON structure a = bit.
 
Mike> Per my reply in the thread =E2=80=9C[Id-event] Draft = adoption=E2=80=9D, I think we=E2=80=99d be better off completely = dropping the distinction between primary events and secondary = events.  When applications send a set of related events together, = it=E2=80=99s logical for recipients to process all of them (or all of = them that they understand).  The primary/secondary distinction is = unhelpful and leads to complication, rather than clarity or = simplification.  Let=E2=80=99s drop it entirely.
 
In addition, I think we should require the claim = to be signed, since it will be used for security-sensitive activities = across complex distributed systems.
  • 1: Why is = signing optional? The publisher doesn't know how the subscriber's system = is architected, and might well want end-to-end authentication of the = claim. This is also important for auditing.
 
Mike> = This is ground already well-covered during both the JOSE [RFC 7515] and = JWT [RFC 7519] standardization efforts.  The key observation is = that JWT (and SET) is a data structure to be used in protocols and = applications =E2=80=93 not a protocol or application = specification.  It=E2=80=99s up to protocol and application = specifications to define whether signing is needed (and if so, with what = algorithms).  In some cases, it won=E2=80=99t be needed because the = JWT/SET is already integrity protected by the protocol or application = =E2=80=93 for instance, by TLS.  Just like for JWT, we shouldn=E2=80=99= t require signing in cases that it adds no value but does add = overhead.  A working group consensus call confirmed the need for = the ability to use =E2=80=9Calg=E2=80=9D:=E2=80=9Cnone=E2=80=9D for JWS = objects.
 
  • 1: "example events" - = is specification of individual events (maybe only a few basic ones) = within scope of our charter? Otherwise we cannot guarantee interop.
 
Mike> I = agree with Phil=E2=80=99s response that interop happens within = applications and protocols using SETs.
 
  • 1.2: principle -> = principal
  • 2: "first value" is meaningless. JSON = objects are unordered (4th paragraph of RFC 7159). If order is important, we could make = "events" into an array.
 
Mike> = Order is unimportant.  This was already widely discussed on the = id-event list.  While we used to use an array representation, a = conscious choice was made to move to the current =E2=80=9Cset of = events=E2=80=9D syntax, replacing the old =E2=80=9Carray of events=E2=80=9D= syntax.
 
 
Mike> = The =E2=80=9Cevent extensions=E2=80=9D language is a holdover from when = there was an array of events and the first event was somehow = special.  I agree that we need to perform editorial surgery to = clean this up, because it is currently misleading.
 
  • Why "events" and not = "event"? We don't really have support for multiple events. Certainly not = if they are all of the same type. The current text is confusing: = "events" is not the same as "a primary event and its extensions".
 
Mike> = What=E2=80=99s being represented is a set of related events from the = same issuer.  Again, the extensions language is misleading, and = needs to be fixed.
 
  • "In the above example = "iss" and "sub" contained within the claim" - this is incorrect, = probably leftover from an earlier version.
 
Mike> I = agree with Phil=E2=80=99s points.  The editors can work on this to = make the intent clearer.
 
  • "aud" MAY be a URI: = shouldn't it be an array, maybe an array that contains a single URI?
  • Why do we use the terms "single-valued" vs. "multiple-valued" = strings? Why not use the normal JSON terminology, "string" vs. "array of = strings"?
  • Why is "sub" optional? Do we have any good = examples of events where this value is not required?
  • "a future date" - we should clarify that there may be cases = when nbf is smaller than iat, i.e. when it takes some time until the SET = is issued.
  • "exp" - is it also a NumericDate? Please = specify.
  • In the medical example, it is strange that = the event is named by a URL that points to an HTML page. I would expect = a more stable URI.
  • 2.2: is encryption a = MUST whenever there are attributes specified? If so, we should have a = normative section saying so, not just mention it in the context of an = example. Besides, we have not defined what attributes are.
  • 2.2: this section is confusing. We first say that the JWT = must be encrypted. But then instead, we sign it, and we "sign" with a = null algorithm. Why?
  • Signed SETs MUST (not = MAY) be validated by the subscriber.
  • Also, I think we should = remove the preconditions and always require signing, as a MUST. An = optional signature is actually a security loophole because an attacker = can remove the signature, and the subscriber doesn't know that it's = missing.
  • 3.2: "that alone will not guarantee that = the correct subscribing party knows they should have received a = particular SET." The text is unclear to me. Do we mean: "that alone does = not guarantee that a particular SET was delivered to the correct = subscribing party"?
  • We may want a separate = Implementation Considerations section, and move "delivery", "sequencing" = and "timing" into it. Yes they are security-relevant, just like anything = else in this document, but they would apply just as well to any event = stream protocol.
  • 3.3: this is the first time we mention = provisioning. Do we really intend SETs to be used for that?
  • 3.3: ISTM that we should define a sequencing mechanism, = rather than leave it open to profiles. E.g., require a sequence number = whenever "txn" is used.
  • 3.4: Also, our = timestamps only have 1 second granularity, and so are too coarse for = session state (consider automated logins/logouts).
  • 3.5: Why don't we have an unambiguous way to distinguish SETs = from access tokens, why leave it to implementers? Sounds like a major = security issue in the making. We should consider here ALL = implementations that accept access tokens, including legacy = implementations that cannot be modified.
 
Mike> We = do have an unambiguous manner of distinguishing SETs from other JWTs =E2=80= =93 the inclusion of the =E2=80=9Cevents=E2=80=9D claim.  OAuth = access tokens are, by definition, opaque, and completely outside of our = scope of work.
 
  • 4: The audit happens on = the subscriber side. By then it is too late to require JWS to be used by = the publisher. As mentioned, I propose that JWS should ALWAYS be = required.
  • 4: "When sharing personally identifiable = information" - we should remove this condition. I don't see a case where = the information shared is NOT PII, and therefore legal agreements about = information sharing and user consent must always be in place.
 
Mike> We = should stay completely clear of specifying what applications and = protocols must do with SETs.  It=E2=80=99s up to them to profile = SETs so that the application=E2=80=99s privacy and security properties = are maintained, which will differ between applications.  Just like = whether =E2=80=9Calg=E2=80=9D: =E2=80=9Cnone=E2=80=9D is appropriate is = a protocol/application decision, it=E2=80=99s also a = protocol/application decision whether encryption is needed, depending = upon the context.
 
  • 4: I don't think the = subject information is "perceived" as PII. It is PII, otherwise it would = be useless to the subscriber, because the subscriber would not be able = to identify the subject. Also, even if the information on the wire is = not in itself PII, e.g. when using a hash, the fact that a publisher = shares information that a particular user is also a user on its system = and is undergoing certain state changes is privacy-sensitive.
 
Mike> = Per my previous comment, what=E2=80=99s PII (or not) is = protocol/application-specific and not an appropriate topic for the SET = spec.  The editors should remove any such language, other than = perhaps informative comments in the Security Considerations and Privacy = Considerations sections, listing things that protocol/application = designers should consider.
 
  • I suggest to add an = Implementation Status section, per RFC 7942.
Thanks,
    = Yaron
 
Mike> Thanks again for the thorough and thoughtful = comments, Yaron!
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;       -- Mike
 

= --Apple-Mail=_ADBB2CF0-F622-414F-95A2-63035DB1E470-- From nobody Thu Dec 29 15:02:42 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F4301296DE for ; Thu, 29 Dec 2016 15:02:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BPCPgaJcESVA for ; Thu, 29 Dec 2016 15:02:34 -0800 (PST) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00B511296D5 for ; Thu, 29 Dec 2016 15:02:33 -0800 (PST) Received: by mail-io0-x22c.google.com with SMTP id p42so362378765ioo.1 for ; Thu, 29 Dec 2016 15:02:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7VX/ydjhu3xkVYVAGnQwMMmmsnAxb6AP5IAMTEvpqqI=; b=SToO0n3t+1s0181SB6/zcYRCLuf4b+wS5ZgvhVkneGsJcYzAVWcxOGywRisOEmNOgR q6m+am0GYCILqdqx6jxXWlk45jPKMOmMjWIkXQgcW6vF8/huI7zQsnZGIeQgwM17U3je BrB8N9ALBTAJ0OqFomDik66nScNVWJOlozcoM6dwYqBuuGIgrdCOwlKcLNtA3Z5GlMWR VkOpmc0JexSNMnxhsdSxWq1TZPKTqJld9KU81fzDZnvyJFHdycyiqqizHqft8B1UVOrm 7Ijsw/3+BN6AuYZQMybYRq4iozjfLxBsyJjbuxbgjlC7wf9tDlHcSfufM981TD+R/m+S c0/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7VX/ydjhu3xkVYVAGnQwMMmmsnAxb6AP5IAMTEvpqqI=; b=cqur6MbCubgpPYH75MshfKTDO5mC3Hln+G8oUjEqcXveIHmtqIXT8Z7kVxyI20duIn WGp7uj1cugVwLwKJZBA/q48jUmzM2tZ4wzNyAOLBqpN3qg3tHbPcohrFJHEyiOfinIXJ zQ6a0SoKQT1EjBuJ9P5MXp21di6AG2R7EMZqYPZy73uUKTx5GWpB2mtA1ZCqCppwGRGk 3Wa9Lp2xtyoxtOQR5Rqx5okv2yUwLujIN4SK0TiSvrCt0VYcGfVyO21RMU18Ok0h23Wz ylCB+wnzvQT9sO0ZWX1m8k6XAZT82oAE9qvDxDYVekZXVyh61u5srXOuMcg1CiccqcOs kHFw== X-Gm-Message-State: AIkVDXLciBwqlsqM61YN/R5o5dkDb66lR/07kMZ9prqo1k1cDJbpJaAVPwsHCQEJ84N+0REj0kTraVfb8N9PVQ== X-Received: by 10.107.17.105 with SMTP id z102mr39901236ioi.165.1483052552932; Thu, 29 Dec 2016 15:02:32 -0800 (PST) MIME-Version: 1.0 References: <9114f681-cba9-b6d3-8369-ccd9193ce1b8@gmail.com> <012A438F-2CFE-4BBC-86A1-41BB11B373BE@oracle.com> In-Reply-To: <012A438F-2CFE-4BBC-86A1-41BB11B373BE@oracle.com> From: Dick Hardt Date: Thu, 29 Dec 2016 23:02:22 +0000 Message-ID: To: Mike Jones , Phil Hunt Content-Type: multipart/alternative; boundary=001a113f6c4e99f2280544d414ce Archived-At: Cc: Yaron Sheffer , SecEvent Subject: Re: [Id-event] Some comments to draft-hunt-idevent-token-07 X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2016 23:02:40 -0000 --001a113f6c4e99f2280544d414ce Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Wrt. Existing implementations If someone is already implementing, they are doing so knowing the spec can change We should not be swayed by existing implementations except for lessons they may have learned On Thu, Dec 29, 2016 at 12:19 PM Phil Hunt wrote: > [personal hat] > +1 > > [editor hat] > I=E2=80=99ll await chair instruction on what to modify before/after adopt= ion etc. > > The clean-up and consistency issues can happen as soon as some of these > decisions are clarified as the formal consensus. At the moment we=E2=80= =99re kind > of stuck in between =E2=80=9Cstyles=E2=80=9D. > > I note there may be some resistance to change now as I understand some > implementation and testing is already under way =E2=80=94 which is why I = singled > the =E2=80=9Cbreaking=E2=80=9D change. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > > > > > On Dec 29, 2016, at 11:47 AM, Mike Jones > wrote: > > I=E2=80=99m replying to Yaron=E2=80=99s original message so the result wi= ll be short > enough to be quickly readable, while acknowledging that Phil already made > many points in his responses that I agree with. Where I don=E2=80=99t ha= ve > anything to add to Phil=E2=80=99s responses, I don=E2=80=99t include a re= sponse to those > points. My replies are prefixed by =E2=80=9CMike>=E2=80=9D. > > Thanks for taking the time to do a thorough read, Yaron! > > -- Mike > > *From:* Id-event [mailto:id-event-bounces@ietf.org > ] *On Behalf Of *Yaron Sheffer > *Sent:* Saturday, December 10, 2016 1:28 PM > *To:* SecEvent > *Subject:* [Id-event] Some comments to draft-hunt-idevent-token-07 > > Hi, I finally read the draft in detail, and I do have a few comments. > My main suggestion is to tighten the specification of an Event, by > defining more strictly the difference between "event" and "event extensio= n" > and tweaking the JSON structure a bit. > > Mike> Per my reply in the thread =E2=80=9C[Id-event] Draft adoption=E2=80= =9D, I think we=E2=80=99d > be better off completely dropping the distinction between primary events > and secondary events. When applications send a set of related events > together, it=E2=80=99s logical for recipients to process all of them (or = all of > them that they understand). The primary/secondary distinction is unhelpf= ul > and leads to complication, rather than clarity or simplification. Let=E2= =80=99s > drop it entirely. > > In addition, I think we should require the claim to be signed, since it > will be used for security-sensitive activities across complex distributed > systems. > > - 1: Why is signing optional? The publisher doesn't know how the > subscriber's system is architected, and might well want end-to-end > authentication of the claim. This is also important for auditing. > > > Mike> This is ground already well-covered during both the JOSE [RFC 7515] > and JWT [RFC 7519] standardization efforts. The key observation is that > JWT (and SET) is a data structure to be used in protocols and application= s > =E2=80=93 not a protocol or application specification. It=E2=80=99s up t= o protocol and > application specifications to define whether signing is needed (and if so= , > with what algorithms). In some cases, it won=E2=80=99t be needed because= the > JWT/SET is already integrity protected by the protocol or application =E2= =80=93 for > instance, by TLS. Just like for JWT, we shouldn=E2=80=99t require signin= g in cases > that it adds no value but does add overhead. A working group consensus > call confirmed the need for the ability to use =E2=80=9Calg=E2=80=9D:=E2= =80=9Cnone=E2=80=9D for JWS objects. > > > - 1: "example events" - is specification of individual events (maybe > only a few basic ones) within scope of our charter? Otherwise we canno= t > guarantee interop. > > > Mike> I agree with Phil=E2=80=99s response that interop happens within > applications and protocols using SETs. > > > - 1.2: principle -> principal > - 2: "first value" is meaningless. JSON objects are unordered (4th > paragraph of RFC 7159). If order *is* important, we could make > "events" into an array. > > > Mike> Order is unimportant. This was already widely discussed on the > id-event list. While we used to use an array representation, a conscious > choice was made to move to the current =E2=80=9Cset of events=E2=80=9D sy= ntax, replacing > the old =E2=80=9Carray of events=E2=80=9D syntax. > > > - 2: event extensions are not defined but only introduced by the text > after they are described. Also, in the example there's this URL: > https://=E2=80=8Bexample.=E2=80=8Bcom/=E2=80=8Bscim/=E2=80=8Bevent/=E2= =80=8Bpas=E2=80=8Bswor=E2=80=8BdRes=E2=80=8BetEx=E2=80=8Bt > > - I believe it needs to be part of the passwordReset object and not > parallel to it. > > > Mike> The =E2=80=9Cevent extensions=E2=80=9D language is a holdover from = when there was an > array of events and the first event was somehow special. I agree that we > need to perform editorial surgery to clean this up, because it is current= ly > misleading. > > > - Why "events" and not "event"? We don't really have support for > multiple events. Certainly not if they are all of the same type. The > current text is confusing: "events" is not the same as "a primary even= t and > its extensions". > > > Mike> What=E2=80=99s being represented is a set of related events from th= e same > issuer. Again, the extensions language is misleading, and needs to be > fixed. > > > - "In the above example "iss" and "sub" contained within the claim" - > this is incorrect, probably leftover from an earlier version. > > > Mike> I agree with Phil=E2=80=99s points. The editors can work on this t= o make > the intent clearer. > > > - "aud" MAY be a URI: shouldn't it be an array, maybe an array that > contains a single URI? > - Why do we use the terms "single-valued" vs. "multiple-valued" > strings? Why not use the normal JSON terminology, "string" vs. "array = of > strings"? > - Why is "sub" optional? Do we have any good examples of events where > this value is not required? > - "a future date" - we should clarify that there may be cases when nbf > is smaller than iat, i.e. when it takes some time until the SET is iss= ued. > - "exp" - is it also a NumericDate? Please specify. > - In the medical example, it is strange that the event is named by a > URL that points to an HTML page. I would expect a more stable URI. > - 2.2: is encryption a MUST whenever there are attributes specified? > If so, we should have a normative section saying so, not just mention = it in > the context of an example. Besides, we have not defined what attribute= s are. > - 2.2: this section is confusing. We first say that the JWT must be > encrypted. But then instead, we sign it, and we "sign" with a null > algorithm. Why? > - Signed SETs MUST (not MAY) be validated by the subscriber. > - Also, I think we should remove the preconditions and always require > signing, as a MUST. An optional signature is actually a security looph= ole > because an attacker can remove the signature, and the subscriber doesn= 't > know that it's missing. > - 3.2: "that alone will not guarantee that the correct subscribing > party knows they should have received a particular SET." The text is > unclear to me. Do we mean: "that alone does not guarantee that a parti= cular > SET was delivered to the correct subscribing party"? > - We may want a separate Implementation Considerations section, and > move "delivery", "sequencing" and "timing" into it. Yes they are > security-relevant, just like anything else in this document, but they = would > apply just as well to any event stream protocol. > - 3.3: this is the first time we mention provisioning. Do we really > intend SETs to be used for that? > - 3.3: ISTM that we should define a sequencing mechanism, rather than > leave it open to profiles. E.g., require a sequence number whenever "t= xn" > is used. > - 3.4: Also, our timestamps only have 1 second granularity, and so are > too coarse for session state (consider automated logins/logouts). > - 3.5: Why don't we have an unambiguous way to distinguish SETs from > access tokens, why leave it to implementers? Sounds like a major secur= ity > issue in the making. We should consider here ALL implementations that > accept access tokens, including legacy implementations that cannot be > modified. > > > Mike> We do have an unambiguous manner of distinguishing SETs from other > JWTs =E2=80=93 the inclusion of the =E2=80=9Cevents=E2=80=9D claim. OAut= h access tokens are, by > definition, opaque, and completely outside of our scope of work. > > > - 4: The audit happens on the subscriber side. By then it is too late > to require JWS to be used by the publisher. As mentioned, I propose th= at > JWS should ALWAYS be required. > - 4: "When sharing personally identifiable information" - we should > remove this condition. I don't see a case where the information shared= is > NOT PII, and therefore legal agreements about information sharing and = user > consent must always be in place. > > > Mike> We should stay completely clear of specifying what applications and > protocols must do with SETs. It=E2=80=99s up to them to profile SETs so = that the > application=E2=80=99s privacy and security properties are maintained, whi= ch will > differ between applications. Just like whether =E2=80=9Calg=E2=80=9D: = =E2=80=9Cnone=E2=80=9D is > appropriate is a protocol/application decision, it=E2=80=99s also a > protocol/application decision whether encryption is needed, depending upo= n > the context. > > > - 4: I don't think the subject information is "perceived" as PII. It > is PII, otherwise it would be useless to the subscriber, because the > subscriber would not be able to identify the subject. Also, even if th= e > information on the wire is not in itself PII, e.g. when using a hash, = the > fact that a publisher shares information that a particular user is als= o a > user on its system and is undergoing certain state changes is > privacy-sensitive. > > > Mike> Per my previous comment, what=E2=80=99s PII (or not) is > protocol/application-specific and not an appropriate topic for the SET > spec. The editors should remove any such language, other than perhaps > informative comments in the Security Considerations and Privacy > Considerations sections, listing things that protocol/application designe= rs > should consider. > > > - I suggest to add an Implementation Status section, per RFC 7942. > > Thanks, > Yaron > > Mike> Thanks again for the thorough and thoughtful comments, Yaron! > > -- Mike > > > > _______________________________________________ > > Id-event mailing list > > Id-event@ietf.org > > https://www.ietf.org/mailman/listinfo/id-event > > --001a113f6c4e99f2280544d414ce Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Wrt. Existing implementations

If someone is a= lready implementing, they are doing so knowing the spec can change

We should not be swayed by existing implementations except= for lessons they may have learned


On Thu, Dec 29, 2016 at 12:19 PM Phil Hunt <phil.hunt@oracle.com> wrote:
[personal hat]
+1

[edit= or hat]
I=E2=80=99ll await chair instruction = on what to modify before/after adoption etc.
=
The clean-up and con= sistency issues can happen as soon as some of these decisions are clarified= as the formal consensus.=C2=A0 At the moment we=E2=80=99re kind of stuck i= n between =E2=80=9Cstyles=E2=80=9D.

I note there may be some resi= stance to change now as I understand some implementation and testing is alr= eady under way =E2=80=94 which is why I singled the =E2=80=9Cbreaking=E2=80= =9D change.

Phil
=

@independentid
phil.hunt@oracle.com









On Dec 29, 2016, at 11:47 AM, Mike Jones <= Michael.Jones@microsoft.com> wrote:

I=E2=80=99m replying to Yaron=E2=80=99s orig= inal message so the result will be short enough to be quickly readable, whi= le acknowledging that Phil already made many points in his responses that I= agree with.=C2=A0 Where I don=E2=80=99t have anything to add to Phil=E2=80= =99s responses, I don=E2=80=99t include a response to those points.=C2=A0 M= y replies are prefixed by =E2=80=9CMike>=E2=80=9D.
= =C2=A0
Thanks for t= aking the time to do a thorough read, Yaron!
= =C2=A0
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=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:=C2=A0Id-event [mailto:id-event-bounces@ietf.org]=C2=A0On Behalf Of=C2=A0Yaron Sheffer
Sent:=C2=A0Saturday, December 10, 2016 1:28 PM
To:=C2=A0SecEvent <id-event@ietf.org>
Subject:=C2=A0[Id-event] Some = comments to draft-hunt-idevent-token-07
<= u class=3D"gmail_msg">=C2=A0
Hi, I finally read the dra= ft in detail, and I do have a few comments.
My main suggestion is to tighten the specification of an Event,= by defining more strictly the difference between "event" and &qu= ot;event extension" and tweaking the JSON structure a bit.
=C2=A0
Mike> Per my reply in t= he thread =E2=80=9C[Id-event] Draft adoption=E2=80=9D, I think we=E2=80=99d= be better off completely dropping the distinction between primary events a= nd secondary events.=C2=A0 When applications send a set of related events t= ogether, it=E2=80=99s logical for recipients to process all of them (or all= of them that they understand).=C2=A0 The primary/secondary distinction is = unhelpful and leads to complication, rather than clarity or simplification.= =C2=A0 Let=E2=80=99s drop it entirely.
=C2=A0
In addition, I think w= e should require the claim to be signed, since it will be used for security= -sensitive activities across complex distributed systems.
  • 1: Why is signing op= tional? The publisher doesn't know how the subscriber's system is a= rchitected, and might well want end-to-end authentication of the claim. Thi= s is also important for auditing.
=C2=A0
Mike> This is ground alre= ady well-covered during both the JOSE [RFC 7515] and JWT [RFC 7519] standar= dization efforts.=C2=A0 The key observation is that JWT (and SET) is a data= structure to be used in protocols and applications =E2=80=93 not a protoco= l or application specification.=C2=A0 It=E2=80=99s up to protocol and appli= cation specifications to define whether signing is needed (and if so, with = what algorithms).=C2=A0 In some cases, it won=E2=80=99t be needed because t= he JWT/SET is already integrity protected by the protocol or application = =E2=80=93 for instance, by TLS.=C2=A0 Just like for JWT, we shouldn=E2=80= =99t require signing in cases that it adds no value but does add overhead.= =C2=A0 A working group consensus call confirmed the need for the ability to= use =E2=80=9Calg=E2=80=9D:=E2=80=9Cnone=E2=80=9D for JWS objects.
=C2=A0
    <= li class=3D"MsoNormal gmail_msg" style=3D"margin:0in 0in 0.0001pt;font-size= :11pt;font-family:Calibri,sans-serif;line-height:20.25pt;box-sizing:border-= box">1: "example events" - is specification o= f individual events (maybe only a few basic ones) within scope of our chart= er? Otherwise we cannot guarantee interop.
= =C2=A0
Mike> I agree wi= th Phil=E2=80=99s response that interop happens within applications and pro= tocols using SETs.
=C2=A0
  • 1.2: principle -> prin= cipal
  • 2: "first value" is meaningless. JSON objec= ts are unordered (4th paragraph of RFC 7159). If order=C2=A0is=C2=A0important, we could make "events&= quot; into an array.<= /span>
=C2=A0
Mike> Order is unimportant.=C2=A0 This= was already widely discussed on the id-event list.=C2=A0 While we used to = use an array representation, a conscious choice was made to move to the cur= rent =E2=80=9Cset of events=E2=80=9D syntax, replacing the old =E2=80=9Carr= ay of events=E2=80=9D syntax.
=C2=A0
= =C2=A0
Mike> The =E2=80= =9Cevent extensions=E2=80=9D language is a holdover from when there was an = array of events and the first event was somehow special.=C2=A0 I agree that= we need to perform editorial surgery to clean this up, because it is curre= ntly misleading.
=C2=A0<= /u>
  • Why "events" and = not "event"? We don't really have support for multiple events= . Certainly not if they are all of the same type. The current text is confu= sing: "events" is not the same as "a primary event and its e= xtensions".
=C2=A0
Mike> What=E2=80=99s being represented is = a set of related events from the same issuer.=C2=A0 Again, the extensions l= anguage is misleading, and needs to be fixed.
= =C2=A0
  • "In the above example "iss" and "sub" contained= within the claim" - this is incorrect, probably leftover from an earl= ier version.
=C2=A0<= /u>
Mike> I agree with Phil=E2=80=99s points.=C2= =A0 The editors can work on this to make the intent clearer.
=C2=A0
  • "aud" MAY be a URI: shouldn't it be an array= , maybe an array that contains a single URI?
  • Why do we use= the terms "single-valued" vs. "multiple-valued" string= s? Why not use the normal JSON terminology, "string" vs. "ar= ray of strings"?=
  • Why is "sub" optional? Do w= e have any good examples of events where this value is not required?
  • "a future date" - we should clarify that there may be c= ases when nbf is smaller than iat, i.e. when it takes some time until the S= ET is issued.<= /li>
  • "exp" - is it also a NumericDate? P= lease specify.=
  • In the medical example, it is strange that t= he event is named by a URL that points to an HTML page. I would expect a mo= re stable URI.=
  • 2.2: is encryption a MUST whenever there are= attributes specified? If so, we should have a normative section saying so,= not just mention it in the context of an example. Besides, we have not def= ined what attributes are.=
  • 2.2: this section is confusing. W= e first say that the JWT must be encrypted. But then instead, we sign it, a= nd we "sign" with a null algorithm. Why?
  • Signed S= ETs MUST (not MAY) be validated by the subscriber.
  • Also, I = think we should remove the preconditions and always require signing, as a M= UST. An optional signature is actually a security loophole because an attac= ker can remove the signature, and the subscriber doesn't know that it&#= 39;s missing.<= /li>
  • 3.2: "that alone will not guarantee that= the correct subscribing party knows they should have received a particular= SET." The text is unclear to me. Do we mean: "that alone does no= t guarantee that a particular SET was delivered to the correct subscribing = party"?
  • We may want a separate Implementation Consider= ations section, and move "delivery", "sequencing" and &= quot;timing" into it. Yes they are security-relevant, just like anythi= ng else in this document, but they would apply just as well to any event st= ream protocol.=
  • 3.3: this is the first time we mention provi= sioning. Do we really intend SETs to be used for that?
  • 3.3:= ISTM that we should define a sequencing mechanism, rather than leave it op= en to profiles. E.g., require a sequence number whenever "txn" is= used.
    • 3.4: Also, our timestamps only have 1 second granula= rity, and so are too coarse for session state (consider automated logins/lo= gouts).3.5: Why don't we have an unambiguous way to di= stinguish SETs from access tokens, why leave it to implementers? Sounds lik= e a major security issue in the making. We should consider here ALL impleme= ntations that accept access tokens, including legacy implementations that c= annot be modified.
=C2=A0
Mike> We do have an unambiguous manner o= f distinguishing SETs from other JWTs =E2=80=93 the inclusion of the =E2=80= =9Cevents=E2=80=9D claim.=C2=A0 OAuth access tokens are, by definition, opa= que, and completely outside of our scope of work.
<= /u>=C2=A0
  • 4: The audit happens on the subscriber side. By then it is too late t= o require JWS to be used by the publisher. As mentioned, I propose that JWS= should ALWAYS be required.
  • 4: "When sharing personall= y identifiable information" - we should remove this condition. I don&#= 39;t see a case where the information shared is NOT PII, and therefore lega= l agreements about information sharing and user consent must always be in p= lace.
    • =C2=A0
    Mike> We should stay completely clear of specifying w= hat applications and protocols must do with SETs.=C2=A0 It=E2=80=99s up to = them to profile SETs so that the application=E2=80=99s privacy and security= properties are maintained, which will differ between applications.=C2=A0 J= ust like whether =E2=80=9Calg=E2=80=9D: =E2=80=9Cnone=E2=80=9D is appropria= te is a protocol/application decision, it=E2=80=99s also a protocol/applica= tion decision whether encryption is needed, depending upon the context.
    = =C2=A0
  • 4: I don't think the subject information = is "perceived" as PII. It is PII, otherwise it would be useless t= o the subscriber, because the subscriber would not be able to identify the = subject. Also, even if the information on the wire is not in itself PII, e.= g. when using a hash, the fact that a publisher shares information that a p= articular user is also a user on its system and is undergoing certain state= changes is privacy-sensitive.
=C2=A0
Mike> Per my previous commen= t, what=E2=80=99s PII (or not) is protocol/application-specific and not an = appropriate topic for the SET spec.=C2=A0 The editors should remove any suc= h language, other than perhaps informative comments in the Security Conside= rations and Privacy Considerations sections, listing things that protocol/a= pplication designers should consider.
=C2=A0
  • I sugg= est to add an Implementation Status section, per RFC 7942.
Thanks,
=C2=A0=C2=A0=C2=A0 Yaron
=C2=A0
Mike> Thanks again for the thorough and though= tful comments, Yaron!=
= =C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike<= u class=3D"gmail_msg">
=C2=A0

_______= ________________________________________

Id-even= t mailing list

Id-event@ietf.org

https://www.ietf.o= rg/mailman/listinfo/id-event

--001a113f6c4e99f2280544d414ce-- From nobody Sat Dec 31 12:24:27 2016 Return-Path: X-Original-To: id-event@ietfa.amsl.com Delivered-To: id-event@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9154B129470 for ; Sat, 31 Dec 2016 12:24:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVZelghqyKnq for ; Sat, 31 Dec 2016 12:24:24 -0800 (PST) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 166E012946D for ; Sat, 31 Dec 2016 12:24:24 -0800 (PST) Received: by mail-wm0-x244.google.com with SMTP id m203so76379124wma.3 for ; Sat, 31 Dec 2016 12:24:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=suJtSe/N5YA6YWR/dYODjRsoEoUtQZ41TfCIXlo+hJs=; b=aC4CtpT+BfaL1LRQnhmZf240urLAf5srGjTMO6qOHV2cIqT1MGrBOgbfQjbYHhKfkU RTKOUqVpuqEsbU3rDu/G0LMAp1bn64Zj2DXVrQajtaCEfFGlt3K4WILzM2IdjdN87zVn wuacSFb80Y9n7KSpZN+LgBf4OJPHN0Nii0rZU8SwY82VH8jKKE7Z22dGX4lzxwdZIDGP tzFe3s2ihoiznQn4S+7k+jsszvsFOxDN/vYKN2s5pp1xwsYhvLmhiNmf4qk2zqFgWu7R 9b65R9iu5ORCU6MzOZBdT2qNn3CWUDfxa8H+WZoel0JXNaj/SboLIUcnu+C6iTh2fjlf c8aQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=suJtSe/N5YA6YWR/dYODjRsoEoUtQZ41TfCIXlo+hJs=; b=l5ggQ9u9mDPHnzcc/lEDS1mugnP4PvKEZ7YQ8qxhToXgdbQxJVbiGfmAeu21OhmmSP dPOJacwQOYESqlTrNS90N+26e7k2hLWk2bsDWbCCcXKvX2IGIUpYB+EXzrlX4xUf5/xo s4UKQpl5aOzKydJD9JckHSiz1vGqFXWTIuBP0K8A8mj+/eSD8gcgqa6HBQczTbzKt1vr p8nvRwOTWEP9hKiyoBrsbsi/EEltCA9ggWsHTNh5tEOTK1iNc3/xRu/gKLHiauQ0kOxv XNvahBH2JxITaAaYTM2rBIxG7xq6uvPcC62uiUstA/MiDAz6wTnDCNAO65+NdD5Px99N OKaA== X-Gm-Message-State: AIkVDXKpJigqNCfCKwGOlj7geQucFVb+ZovvCsoUfmFXsNdWzVWXAZ4Ew3RNCvNul8RibQ== X-Received: by 10.28.141.18 with SMTP id p18mr44184113wmd.31.1483215861949; Sat, 31 Dec 2016 12:24:21 -0800 (PST) Received: from [10.0.0.13] (bzq-79-177-158-66.red.bezeqint.net. [79.177.158.66]) by smtp.gmail.com with ESMTPSA id 81sm76335960wmw.7.2016.12.31.12.24.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 31 Dec 2016 12:24:20 -0800 (PST) To: Phil Hunt , Mike Jones References: <9114f681-cba9-b6d3-8369-ccd9193ce1b8@gmail.com> <012A438F-2CFE-4BBC-86A1-41BB11B373BE@oracle.com> From: Yaron Sheffer Message-ID: <11c9c4fd-09bc-84d9-6af1-cb8f8c3ee816@gmail.com> Date: Sat, 31 Dec 2016 22:24:19 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <012A438F-2CFE-4BBC-86A1-41BB11B373BE@oracle.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: SecEvent Subject: Re: [Id-event] Some comments to draft-hunt-idevent-token-07 X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "A mailing list to discuss the potential solution for a common identity event messaging format and distribution system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Dec 2016 20:24:26 -0000 Hi Phil, The chairs requested to clarify the event/events syntax and the related text, to make it all consistent with whatever semantics the editors settle on: single event with extensions, list of ordered events, set of events, whatever. The goal is to have a consistent start with respect to the main subject of this document. Everything else can happen after adoption. Or in Mike's words: we are asking the editors to produce a new, cleaner individual draft before adoption as a working group document. Thanks, Yaron On 29/12/16 22:19, Phil Hunt wrote: > [personal hat] > +1 > > [editor hat] > I’ll await chair instruction on what to modify before/after adoption etc. > > The clean-up and consistency issues can happen as soon as some of these > decisions are clarified as the formal consensus. At the moment we’re > kind of stuck in between “styles”. > > I note there may be some resistance to change now as I understand some > implementation and testing is already under way — which is why I singled > the “breaking” change. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > >> On Dec 29, 2016, at 11:47 AM, Mike Jones > > wrote: >> >> I’m replying to Yaron’s original message so the result will be short >> enough to be quickly readable, while acknowledging that Phil already >> made many points in his responses that I agree with. Where I don’t >> have anything to add to Phil’s responses, I don’t include a response >> to those points. My replies are prefixed by “Mike>”. >> >> Thanks for taking the time to do a thorough read, Yaron! >> >> -- Mike >> >> *From:* Id-event [mailto:id-event-bounces@ietf.org] *On Behalf >> Of *Yaron Sheffer >> *Sent:* Saturday, December 10, 2016 1:28 PM >> *To:* SecEvent > >> *Subject:* [Id-event] Some comments to draft-hunt-idevent-token-07 >> >> Hi, I finally read the draft in detail, and I do have a few comments. >> My main suggestion is to tighten the specification of an Event, by >> defining more strictly the difference between "event" and "event >> extension" and tweaking the JSON structure a bit. >> >> Mike> Per my reply in the thread “[Id-event] Draft adoption”, I think >> we’d be better off completely dropping the distinction between primary >> events and secondary events. When applications send a set of related >> events together, it’s logical for recipients to process all of them >> (or all of them that they understand). The primary/secondary >> distinction is unhelpful and leads to complication, rather than >> clarity or simplification. Let’s drop it entirely. >> >> In addition, I think we should require the claim to be signed, since >> it will be used for security-sensitive activities across complex >> distributed systems. >> >> * 1: Why is signing optional? The publisher doesn't know how the >> subscriber's system is architected, and might well want end-to-end >> authentication of the claim. This is also important for auditing. >> >> >> Mike> This is ground already well-covered during both the JOSE [RFC >> 7515] and JWT [RFC 7519] standardization efforts. The key observation >> is that JWT (and SET) is a data structure to be used in protocols and >> applications – not a protocol or application specification. It’s up >> to protocol and application specifications to define whether signing >> is needed (and if so, with what algorithms). In some cases, it won’t >> be needed because the JWT/SET is already integrity protected by the >> protocol or application – for instance, by TLS. Just like for JWT, we >> shouldn’t require signing in cases that it adds no value but does add >> overhead. A working group consensus call confirmed the need for the >> ability to use “alg”:“none” for JWS objects. >> >> >> * 1: "example events" - is specification of individual events (maybe >> only a few basic ones) within scope of our charter? Otherwise we >> cannot guarantee interop. >> >> >> Mike> I agree with Phil’s response that interop happens within >> applications and protocols using SETs. >> >> >> * 1.2: principle -> principal >> * 2: "first value" is meaningless. JSON objects are unordered (4th >> paragraph of RFC 7159). If order /is/ important, we could make >> "events" into an array. >> >> >> Mike> Order is unimportant. This was already widely discussed on the >> id-event list. While we used to use an array representation, a >> conscious choice was made to move to the current “set of events” >> syntax, replacing the old “array of events” syntax. >> >> >> * 2: event extensions are not defined but only introduced by the >> text after they are described. Also, in the example there's this >> URL: https://​example.​com/​scim/​event/​pas​swor​dRes​etEx​t >> - >> I believe it needs to be part of the passwordReset object and not >> parallel to it. >> >> >> Mike> The “event extensions” language is a holdover from when there >> was an array of events and the first event was somehow special. I >> agree that we need to perform editorial surgery to clean this up, >> because it is currently misleading. >> >> >> * Why "events" and not "event"? We don't really have support for >> multiple events. Certainly not if they are all of the same type. >> The current text is confusing: "events" is not the same as "a >> primary event and its extensions". >> >> >> Mike> What’s being represented is a set of related events from the >> same issuer. Again, the extensions language is misleading, and needs >> to be fixed. >> >> >> * "In the above example "iss" and "sub" contained within the claim" >> - this is incorrect, probably leftover from an earlier version. >> >> >> Mike> I agree with Phil’s points. The editors can work on this to >> make the intent clearer. >> >> >> * "aud" MAY be a URI: shouldn't it be an array, maybe an array that >> contains a single URI? >> * Why do we use the terms "single-valued" vs. "multiple-valued" >> strings? Why not use the normal JSON terminology, "string" vs. >> "array of strings"? >> * Why is "sub" optional? Do we have any good examples of events >> where this value is not required? >> * "a future date" - we should clarify that there may be cases when >> nbf is smaller than iat, i.e. when it takes some time until the >> SET is issued. >> * "exp" - is it also a NumericDate? Please specify. >> * In the medical example, it is strange that the event is named by a >> URL that points to an HTML page. I would expect a more stable URI. >> * 2.2: is encryption a MUST whenever there are attributes specified? >> If so, we should have a normative section saying so, not just >> mention it in the context of an example. Besides, we have not >> defined what attributes are. >> * 2.2: this section is confusing. We first say that the JWT must be >> encrypted. But then instead, we sign it, and we "sign" with a null >> algorithm. Why? >> * Signed SETs MUST (not MAY) be validated by the subscriber. >> * Also, I think we should remove the preconditions and always >> require signing, as a MUST. An optional signature is actually a >> security loophole because an attacker can remove the signature, >> and the subscriber doesn't know that it's missing. >> * 3.2: "that alone will not guarantee that the correct subscribing >> party knows they should have received a particular SET." The text >> is unclear to me. Do we mean: "that alone does not guarantee that >> a particular SET was delivered to the correct subscribing party"? >> * We may want a separate Implementation Considerations section, and >> move "delivery", "sequencing" and "timing" into it. Yes they are >> security-relevant, just like anything else in this document, but >> they would apply just as well to any event stream protocol. >> * 3.3: this is the first time we mention provisioning. Do we really >> intend SETs to be used for that? >> * 3.3: ISTM that we should define a sequencing mechanism, rather >> than leave it open to profiles. E.g., require a sequence number >> whenever "txn" is used. >> * 3.4: Also, our timestamps only have 1 second granularity, and so >> are too coarse for session state (consider automated logins/logouts). >> * 3.5: Why don't we have an unambiguous way to distinguish SETs from >> access tokens, why leave it to implementers? Sounds like a major >> security issue in the making. We should consider here ALL >> implementations that accept access tokens, including legacy >> implementations that cannot be modified. >> >> >> Mike> We do have an unambiguous manner of distinguishing SETs from >> other JWTs – the inclusion of the “events” claim. OAuth access tokens >> are, by definition, opaque, and completely outside of our scope of work. >> >> >> * 4: The audit happens on the subscriber side. By then it is too >> late to require JWS to be used by the publisher. As mentioned, I >> propose that JWS should ALWAYS be required. >> * 4: "When sharing personally identifiable information" - we should >> remove this condition. I don't see a case where the information >> shared is NOT PII, and therefore legal agreements about >> information sharing and user consent must always be in place. >> >> >> Mike> We should stay completely clear of specifying what applications >> and protocols must do with SETs. It’s up to them to profile SETs so >> that the application’s privacy and security properties are maintained, >> which will differ between applications. Just like whether “alg”: >> “none” is appropriate is a protocol/application decision, it’s also a >> protocol/application decision whether encryption is needed, depending >> upon the context. >> >> >> * 4: I don't think the subject information is "perceived" as PII. It >> is PII, otherwise it would be useless to the subscriber, because >> the subscriber would not be able to identify the subject. Also, >> even if the information on the wire is not in itself PII, e.g. >> when using a hash, the fact that a publisher shares information >> that a particular user is also a user on its system and is >> undergoing certain state changes is privacy-sensitive. >> >> >> Mike> Per my previous comment, what’s PII (or not) is >> protocol/application-specific and not an appropriate topic for the SET >> spec. The editors should remove any such language, other than perhaps >> informative comments in the Security Considerations and Privacy >> Considerations sections, listing things that protocol/application >> designers should consider. >> >> >> * I suggest to add an Implementation Status section, per RFC 7942. >> >> Thanks, >> Yaron >> >> Mike> Thanks again for the thorough and thoughtful comments, Yaron! >> >> -- Mike >> >