From nobody Thu Mar 1 04:08:22 2018 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 EA5D1129C53 for ; Thu, 1 Mar 2018 04:08:19 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IeiX79BWJvOZ for ; Thu, 1 Mar 2018 04:08:18 -0800 (PST) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07C5B127876 for ; Thu, 1 Mar 2018 04:08:17 -0800 (PST) Received: by mail-wr0-x234.google.com with SMTP id v111so5858390wrb.3 for ; Thu, 01 Mar 2018 04:08:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=pHbi0R4oj2nbOVwcTdOQ6VOfuSTVKkVTRCZdD9ezNL4=; b=brx1cXGg+5leDzZP5JronoivXlUWO8UhxMtDVzX0xAXtnOhDvWsKBs4Ae/WSu+llFI ItnRnCiStAp5Dx2qtNy3eNcj75xZJLmmRiYISpMHkX+W8QsKRVp8Y0cOAsDqA5WhdBC0 oMrA8WDTREWXpcTBOISmpbGDVUhHg7k0dMetNDDluT3iq3NBnpwLB3mXNj0Tvl7tNA0g 0iFFNVCdeu/TrBMkOPh99KaT7CRw6hO4mu7HD4spa8SxtKkLZxDCIwGZ7HY7asKsEltb 9k62+e8qtNSIRMlpsV1xMh3R07LKupA6BKuAqat8ju/AYtnAAy2e0Hdyz1WHL4DWAW8J ghSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=pHbi0R4oj2nbOVwcTdOQ6VOfuSTVKkVTRCZdD9ezNL4=; b=OMZwQDXIxW9K3iA/RoFlrUNHgw9RQiCGPKChC4vEFg/ykokT7EQQumNJJlfjdwFMcc BARZ6zdYf5xrddGAHnYZFoYy7FRgWH5vXsfEpAx4BTOX9xE2INy2DKA4gyZ2ZrUP+6+7 yVPIzh4MQz0quf1MveI19CrFOpynYZs+xQ9ECg+s8F1FmtXycb6aJmgn885TitqP+6HP sIFUpr6bqO1CZSrJly19jnzGP2AhpQP2KKpbjSblPJkSHkl5iItsHI+u8gBRaeD+a1FZ 6j+B3pzgCLIjj0XQAwGYIu64CJCyREMPig+hYHWdhKcSYrLGxb0X3St5+2SbpepgiDfd HlcA== X-Gm-Message-State: APf1xPACxtEY5UT+NwuiyzwLuMKYqWPrh0vrLC5iHHai/BRQSdxg4g/e hGZTezvSC9z4sdOlYvuwebgQexhy X-Google-Smtp-Source: AG47ELv1XdhOE1idfLaPlQQKvpD/S43IQoNtlCxQP4mQXC68kDpft0X6CTlsZ9zYMKysO1T+7LjuVA== X-Received: by 10.223.128.201 with SMTP id 67mr1502193wrl.131.1519906096255; Thu, 01 Mar 2018 04:08:16 -0800 (PST) Received: from [172.18.129.55] (bzq-202-11.red.bezeqint.net. [212.179.202.11]) by smtp.gmail.com with ESMTPSA id h197sm3395425wmd.17.2018.03.01.04.08.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Mar 2018 04:08:15 -0800 (PST) To: Mike Jones , SecEvent References: From: Yaron Sheffer Message-ID: <33329eba-e8b4-498b-3ea1-8e19607a6144@gmail.com> Date: Thu, 1 Mar 2018 14:08:13 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Id-event] Security Event Token (SET) spec addressing 2nd WGLC and shepherd comments X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 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, 01 Mar 2018 12:08:20 -0000 Looks good. Thank you folks! On 01/03/18 09:09, Mike Jones wrote: > A new draft of the Security Event Token (SET) specification has > published that addresses review comments from the second Working Group > Last Call and shepherd comments from Yaron Sheffer.  Changes were: > > * Changed “when the event was issued” to “when the SET was issued” in > the “iat” description, as suggested by Annabelle Backman. > * Applied editorial improvements that improve the consistency of the > specification that were suggested by Annabelle Backman, Marius > Scurtescu, and Yaron Sheffer. > > The specification is available at: > > * https://tools.ietf.org/html/draft-ietf-secevent-token-06 > > An HTML-formatted version is also available at: > > * http://self-issued.info/docs/draft-ietf-secevent-token-06.html > >                                                        -- Mike > > P.S.  This announcement was also posted at > http://self-issued.info/?p=1781 and as @selfissued > . > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > From nobody Thu Mar 1 11:32:51 2018 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 A3D1D12F2A4 for ; Thu, 1 Mar 2018 11:32:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.528 X-Spam-Level: X-Spam-Status: No, score=-14.528 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qCgColgzToRk for ; Thu, 1 Mar 2018 11:32:47 -0800 (PST) Received: from smtp-fw-9101.amazon.com (smtp-fw-9101.amazon.com [207.171.184.25]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21BA412F2A9 for ; Thu, 1 Mar 2018 11:32:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1519932767; x=1551468767; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=n7q9B7sAGasDHBMyEk0NsO8P2ak7r8fw4v2zDkLOIhE=; b=eVHGX9bo87QZAVPmWQ29FkTgm/diqXIRgT5mZjuBSDc6oXDYoTgpt7+F SdekYViAs4fPZ9Q1hJjXRZ7D5gBJylOwMdVhRMLIskmdGU3Wj6+GpNa2y wWe/2BRMQ6vLa2ru8GGGLeCdAjFXi5xrwX4OPxRBKiG0yxjL2DEMWCKj+ w=; X-IronPort-AV: E=Sophos;i="5.47,409,1515456000"; d="scan'208,217";a="725230187" Received: from sea3-co-svc-lb6-vlan3.sea.amazon.com (HELO email-inbound-relay-1d-98acfc19.us-east-1.amazon.com) ([10.47.22.38]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Mar 2018 19:32:43 +0000 Received: from EX13MTAUWC001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan2.iad.amazon.com [10.40.159.162]) by email-inbound-relay-1d-98acfc19.us-east-1.amazon.com (8.14.7/8.14.7) with ESMTP id w21JWeFu105977 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 1 Mar 2018 19:32:42 GMT Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Thu, 1 Mar 2018 19:32:41 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC004.ant.amazon.com (10.43.162.101) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Thu, 1 Mar 2018 19:32:41 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1236.000; Thu, 1 Mar 2018 19:32:40 +0000 From: "Richard Backman, Annabelle" To: Mike Jones , Yaron Sheffer CC: SecEvent , Phil Hunt Thread-Topic: [Id-event] Doc shepherd review Thread-Index: AQHTsOu4GgT2LTCZR0++jnMPeBylqqO6d4+AgAADDoCAABkyAIAArF2A Date: Thu, 1 Mar 2018 19:32:40 +0000 Message-ID: <49FAC72F-48E7-4B4C-8ACD-1259DADFE8FC@amazon.com> References: <6e8afb70-3e6b-0ea5-7749-442c1c2d4c41@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.a.0.180210 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.160.48] Content-Type: multipart/alternative; boundary="_000_49FAC72F48E74B4C8ACD1259DADFE8FCamazoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Id-event] Doc shepherd review X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 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, 01 Mar 2018 19:32:50 -0000 --_000_49FAC72F48E74B4C8ACD1259DADFE8FCamazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 4oCc4oCmd2hldGhlciBhbmQgaG93IG11bHRpcGxlIG1lbWJlcnMgb2YgdGhlIEpTT04gb2JqZWN0 IHRoYXQgaXMgdGhlIHZhbHVlIG9mIHRoZSBldmVudHMgY2xhaW0gYXJlIHVzZWQgZm9yIFNFVHMg Y29uZm9ybWluZyB0byB0aG9zZSBwcm9maWxlcy7igJ0NCg0KVGhlIOKAnHdoZXRoZXIgYW5kIGhv d+KAnSBjb25zdHJ1Y3Rpb24gY29uZGVuc2VzIHRoaXMgc3RhdGVtZW50LCBidXQgSSB0aGluayBp dCBtYWtlcyBpdCBoYXJkZXIgdG8gdW5kZXJzdGFuZC4gSG93IGFib3V0Og0KDQrigJzigKZ3aGV0 aGVyIHRoZSB2YWx1ZSBvZiB0aGUgZXZlbnRzIGNsYWltIG1heSBjb250YWluIG11bHRpcGxlIG1l bWJlcnMsIGFuZCB0aGUgc2lnbmlmaWNhbmNlIG9mIHRoaXMgY2FzZSBpZiBhbnkgZm9yIFNFVHMg Y29uZm9ybWluZyB0byB0aG9zZSBwcm9maWxlcy7igJ0NCg0KLS0NCkFubmFiZWxsZSBSaWNoYXJk IEJhY2ttYW4NCkFtYXpvbiDigJMgSWRlbnRpdHkgU2VydmljZXMNCg0KRnJvbTogSWQtZXZlbnQg PGlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBNaWtlIEpvbmVzIDxNaWNo YWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+DQpEYXRlOiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDI4LCAy MDE4IGF0IDU6MTYgUE0NClRvOiBZYXJvbiBTaGVmZmVyIDx5YXJvbmYuaWV0ZkBnbWFpbC5jb20+ DQpDYzogU2VjRXZlbnQgPGlkLWV2ZW50QGlldGYub3JnPiwgUGhpbCBIdW50IDxwaGlsLmh1bnRA b3JhY2xlLmNvbT4NClN1YmplY3Q6IFJlOiBbSWQtZXZlbnRdIERvYyBzaGVwaGVyZCByZXZpZXcN Cg0KWWFyb24sIHRoZSBlZGl0cyBpbiBodHRwczovL2dpdGh1Yi5jb20vaW5kZXBlbmRlbnRpZC9J ZGVudGl0eS1FdmVudHMvcHVsbC8xMS9jb21taXRzL2UyN2EyNjk2ZjcwNzEwN2VjODVhOTk0ODQ0 YzZjYmUyMjgzMzU2ZWMgYWRkcmVzcyB5b3VyIHJldmlldyBjb21tZW50cy4NCg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0t IE1pa2UNCg0KRnJvbTogSWQtZXZlbnQgPGlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJl aGFsZiBPZiBNaWtlIEpvbmVzDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDI4LCAyMDE4IDM6 NDYgUE0NClRvOiBQaGlsIEh1bnQgPHBoaWwuaHVudEBvcmFjbGUuY29tPjsgWWFyb24gU2hlZmZl ciA8eWFyb25mLmlldGZAZ21haWwuY29tPg0KQ2M6IFNlY0V2ZW50IDxpZC1ldmVudEBpZXRmLm9y Zz4NClN1YmplY3Q6IFJlOiBbSWQtZXZlbnRdIERvYyBzaGVwaGVyZCByZXZpZXcNCg0KUGhpbCBp cyBjb3JyZWN0LiAgVGhlIOKAnHR4buKAnSBjbGFpbSBpcyBpbnRlbnRpb25hbGx5IHVzYWJsZSB3 aXRoIGFueSBKV1QgYW5kIG5vdCBzcGVjaWZpYyB0byBTRVRzLiBUaGlzIGp1c3QgaGFwcGVucyB0 byBiZSB0aGUgc3BlYyB0byBkZWZpbmUgaXQgYW5kIGFkZCBpdCB0byB0aGUgSUFOQSBKV1QgQ2xh aW1zIHJlZ2lzdHJ5Lg0KDQpZYXJvbiwgSSBwbGFuIHRvIHR3ZWFrIHlvdXIgbGFuZ3VhZ2Ug4oCc U0VUcyBzZXJ2ZSB0byBleGNoYW5nZSBpbmZvcm1hdGlvbiBhYm91dCBpZGVudGl0eS1yZWxhdGVk IGV2ZW50c+KAnSBiZWNhdXNlIHRoZSBjaGFydGVyIGlzIGFib3V0IHNlY3VyaXR5IGV2ZW50cywg b25seSBzb21lIG9mIHdoaWNoIGFyZSBpZGVudGl0eSBldmVudHMuICBXZSBzaG91bGRu4oCZdCBu YXJyb3cgdGhlIHNjb3BlIG9mIGFwcGxpY2FiaWxpdHkgYmV5b25kIHdoYXTigJlzIGludGVuZGVk Lg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBJZC1ldmVudCA8aWQtZXZlbnQtYm91bmNlc0Bp ZXRmLm9yZzxtYWlsdG86aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZz4+IE9uIEJlaGFsZiBPZiBQ aGlsIEh1bnQNClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMjgsIDIwMTggMzozNSBQTQ0KVG86 IFlhcm9uIFNoZWZmZXIgPHlhcm9uZi5pZXRmQGdtYWlsLmNvbTxtYWlsdG86eWFyb25mLmlldGZA Z21haWwuY29tPj4NCkNjOiBTZWNFdmVudCA8aWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOmlkLWV2 ZW50QGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbSWQtZXZlbnRdIERvYyBzaGVwaGVyZCByZXZp ZXcNCg0KWWFyb24sDQoNClRoYW5rcyBmb3IgdGhlIGNvbW1lbnRzLCB3aWxsIGFkZCB0byB0aGUg bmV4dCB1cGRhdGUuDQoNCk1pa2UgaGFzIGFkZGVkIHNvbWUgb3RoZXIgbWlub3IgZWRpdG9yaWFs IGZpeGVzIGZvciBjb25zaXN0ZW5jeSB3aXRoIEpXVCBldGMgd2hpY2ggSSBiZWxpZXZlIHRoZSBn cm91cCBkaXNjdXNzZWQuDQoNCkEgY291cGxlIHF1ZXN0aW9ucyBpbmxpbmXigKYNCg0KUGhpbA0K DQpPcmFjbGUgQ29ycG9yYXRpb24sIElkZW50aXR5IENsb3VkIFNlcnZpY2VzIEFyY2hpdGVjdA0K QGluZGVwZW5kZW50aWQNCnd3dy5pbmRlcGVuZGVudGlkLmNvbTxodHRwOi8vd3d3LmluZGVwZW5k ZW50aWQuY29tPg0KcGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUu Y29tPg0KDQpPbiBGZWIgMjgsIDIwMTgsIGF0IDM6MjcgUE0sIFlhcm9uIFNoZWZmZXIgPHlhcm9u Zi5pZXRmQGdtYWlsLmNvbTxtYWlsdG86eWFyb25mLmlldGZAZ21haWwuY29tPj4gd3JvdGU6DQoN CkhpLA0KDQpJIHdpbGwgYmUgZG9jdW1lbnQgc2hlcGhlcmQgZm9yIHRoZSBTRVQgc3BlYy4gQXMg c3VjaCwgSSBqdXN0IHJlcmVhZCBpdCBvbmNlIGFnYWluLCBhbmQgSSB0aGluayBpdCBpcyBpbiB2 ZXJ5IGdvb2Qgc2hhcGUuIEhlcmUgYXJlIG15IChtb3N0bHkgZWRpdG9yaWFsKSBjb21tZW50cy4N Cg0KLSBBYnN0cmFjdDogcGxlYXNlIGFkZCB0aGUgZm9sbG93aW5nIHRvIGNsYXJpZnksIGUuZy4g YWZ0ZXIgdGhlIGZpcnN0IHNlbnRlbmNlOiBTRVRzIHNlcnZlIHRvIGV4Y2hhbmdlIGluZm9ybWF0 aW9uIGFib3V0IGlkZW50aXR5LXJlbGF0ZWQgZXZlbnRzLg0KLSBBIHNlY3VyaXR5IHN1YmplY3Qg TUFZIGJlIHBlcm1hbmVudCAtIHRoaXMgaXMgZGVzY3JpcHRpdmUgdGV4dCwgcGxlYXNlIGNoYW5n ZSAiTUFZIiB0byAibWF5Ii4NCi0gIlNFVHMgaGF2ZSBubyBjYXBhYmlsaXR5IGZvciBlcnJvciBz aWduYWxpbmcgdG8gZW5zdXJlIHRoZSB2YWxpZGF0aW9uIG9mIGEgcmVjZWl2ZWQgU0VUIiAtIFNF VHMgYXJlIGEgZm9ybWF0LCBzbyBpdCBpcyBhIGhpZ2hlciBsZXZlbCBwcm90b2NvbCB0aGF0IG1h eSBvciBtYXkgbm90IHNpZ25hbCBlcnJvcnMuIEkgc3VnZ2VzdCB0byByZW1vdmUgdGhpcyBzZW50 ZW5jZS4NCi0gImhhcyBvY2N1cnJlZCBhYm91dCBhIFN1YmplY3QuIiBTaG91bGQgdGhpcyBiZSAi aGFzIG9jY3VycmVkIHRvIGEgU3ViamVjdOKAnT8NCg0KSSB3aWxsIHJlLXJlYWQuIEkgdGhpbmsg d2hhdCB0aGUgc3BlYyBpcyB0cnlpbmcgdG8gc2F5IGlzIHRvIG9yIHJlbGF0ZWQgdG8uIE1lYW5p bmcgdGhlIGV2ZW4gaXMgZGlyZWN0bHkgcmVsYXRlZCB0byB0aGUgc3ViamVjdCBidXQgbm90IG5l Y2Vzc2FyaWx5IHRvIHRoZSBzdWJqZWN0LiAgSSB3aWxsIHJldmlldyBhbmQgc3VnZ2VzdCBzb21l IHRleHQuDQoNCi0gMi4yOiBmb3IgcmVhZGFiaWxpdHksIHBsZWFzZSBpbmNsdWRlIHRoZSBmdWxs IG5hbWVzIG9mIHRoZSBjbGFpbXMgKCJJc3N1ZXIiLCAiSldUIElEIiBldGMuKS4NCi0gSU1PIHRo ZSBkaXN0aW5jdGlvbiBiZXR3ZWVuIEpXVHMgYW5kIFNFVHMgd2l0aCByZWdhcmQgdG8gdGhlIG5l ZWQgdG8gdXNlICJleHAiIGlzIG5vdCBjb252aW5jaW5nLiBJIHN1Z2dlc3Qgd2UgcmVmZXIgdG8g U2VjLiA0LjUgZm9yIGEgYmV0dGVyIHJhdGlvbmFsZSB3aHkgd2UgbWFrZSB0aGlzIGNsYWltIE5P VCBSRUNPTU1FTkRFRCByYXRoZXIgdGhhbiBPUFRJT05BTCBhcyBpbiBSRkMgNzUxOS4NCi0gdHhu OiB0aGlzIHBhcmFncmFwaCBzaG91bGQgc3BlYWsgYWJvdXQgU0VUcyByYXRoZXIgdGhhbiBKV1Rz Lg0KDQpJIHdpbGwgZGVmZXIgdG8gTWlrZSwgYnV0IEkgYmVsaWV2ZSBoZSBzdWdnZXN0ZWQgdG8g aGF2ZSB0aGlzIHJlZ2lzdGVyZWQgZm9yIGdlbmVyYWwgSldUIHVzZS4NCg0KLSAidG8gcHJvdmlk ZSBpbnRlZ3JpdHksIGNvbmZpZGVudGlhbGl0eSwgYW5kIGlzc3VlciB2YWxpZGF0aW9uIiwgc2hv dWxkIGJlICJpc3N1ZXIgYXV0aGVudGljaXR5Ii4NCi0gIldoZXRoZXIgYW5kIGhvdyBtdWx0aXBs ZSAiZXZlbnRzIiB2YWx1ZXMgYXJlIHVzZWQiOiB0aGUgcmVhZGVyIHdobyBoYXMgbm90IGJlZW4g Zm9sbG93aW5nIG91ciBkaXNjdXNzaW9ucyBtYXkgbm90IHVuZGVyc3RhbmQgd2hhdCB0aGlzIG1l YW5zLCBtYXliZSB3ZSBzaG91bGQgc2F5IGluIHBhcmVudGhlc2VzLCAoaS5lLiBtdWx0aXBsZSBt ZW1iZXJzIGluIHRoZSAiZXZlbnRzIiBKU09OIG9iamVjdCkuDQotICJNVVNUIHN1cHBvcnQgVExT IDEuMiIgLSBhZGQgIm9yIGEgaGlnaGVyIHZlcnNpb24iLg0KLSA0LjU6IGludGVudGlvbmFsbHkg LSBJIHRoaW5rIHdlIG1lYW4gIm1hbGljaW91c2x5Ii4NCi0gNi4xLjE6ICJTZWN1cml0eSBFdmVu dCBVUkkiIC0gdGhpcyBkZXNjcmlwdGlvbiBpcyBpbmNvcnJlY3QsIHNob3VsZCBwcm9iYWJseSBi ZSAiU2VjdXJpdHkgRXZlbnQgaW5mb3JtYXRpb24iIG9yIHNvbWV0aGluZyBzaW1pbGFybHkgdmFn dWUuDQotIFJGQyA3NjE3IC0gdW51c2VkIHJlZi4gU2ltaWxhcmx5IHNhbWwtY29yZS4NCg0KVGhh bmtzLA0KICAgIFlhcm9uDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpJZC1ldmVudCBtYWlsaW5nIGxpc3QNCklkLWV2ZW50QGlldGYub3JnPG1haWx0 bzpJZC1ldmVudEBpZXRmLm9yZz4NCmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92 Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVu dCZkPUR3SUdhUSZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUm cj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJm09Ri1RbXZERlRB cGlRNldqZ2EwVTlzc1pxX1FNTElZR19YaVUyZzVKTzBVZyZzPW5Md0RaaHVNNEJfWlZ4WDNkR0Vh ZlpneFlPQ1JER0xCQVBUQTdJSjNZVW8mZT0NCg0K --_000_49FAC72F48E74B4C8ACD1259DADFE8FCamazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <0ED107E577B5E648B1EE92ABF07BD6BD@amazon.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5h cHBsZS1zdHlsZS1zcGFuDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLXN0eWxlLXNwYW47fQ0Kc3Bh bi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzAwMjA2MDt9DQpzcGFuLkVtYWlsU3R5bGUy MA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsNCgljb2xvcjojMDAyMDYwO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj7igJzigKZ3aGV0aGVy IGFuZCBob3cgbXVsdGlwbGUgbWVtYmVycyBvZiB0aGUgSlNPTiBvYmplY3QgdGhhdCBpcyB0aGUg dmFsdWUgb2YgdGhlIGV2ZW50cyBjbGFpbSBhcmUgdXNlZCBmb3IgU0VUcyBjb25mb3JtaW5nIHRv IHRob3NlIHByb2ZpbGVzLuKAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUg4oCcd2hldGhl ciBhbmQgaG934oCdIGNvbnN0cnVjdGlvbiBjb25kZW5zZXMgdGhpcyBzdGF0ZW1lbnQsIGJ1dCBJ IHRoaW5rIGl0IG1ha2VzIGl0IGhhcmRlciB0byB1bmRlcnN0YW5kLiBIb3cgYWJvdXQ6PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPuKAnOKApndoZXRoZXIgdGhlIHZhbHVlIG9mIHRoZSBldmVudHMg Y2xhaW0gbWF5IGNvbnRhaW4gbXVsdGlwbGUgbWVtYmVycywgYW5kIHRoZSBzaWduaWZpY2FuY2Ug b2YgdGhpcyBjYXNlIGlmIGFueSBmb3IgU0VUcyBjb25mb3JtaW5nIHRvIHRob3NlIHByb2ZpbGVz LuKAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4t LSZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OyxzZXJpZiI+QW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+QW1hem9uIOKA kyBJZGVudGl0eSBTZXJ2aWNlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu IDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtjb2xvcjpibGFjayI+SWQtZXZlbnQgJmx0O2lkLWV2ZW50LWJvdW5jZXNAaWV0Zi5v cmcmZ3Q7IG9uIGJlaGFsZiBvZiBNaWtlIEpvbmVzICZsdDtNaWNoYWVsLkpvbmVzQG1pY3Jvc29m dC5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPldlZG5lc2RheSwgRmVicnVhcnkgMjgsIDIwMTgg YXQgNToxNiBQTTxicj4NCjxiPlRvOiA8L2I+WWFyb24gU2hlZmZlciAmbHQ7eWFyb25mLmlldGZA Z21haWwuY29tJmd0Ozxicj4NCjxiPkNjOiA8L2I+U2VjRXZlbnQgJmx0O2lkLWV2ZW50QGlldGYu b3JnJmd0OywgUGhpbCBIdW50ICZsdDtwaGlsLmh1bnRAb3JhY2xlLmNvbSZndDs8YnI+DQo8Yj5T dWJqZWN0OiA8L2I+UmU6IFtJZC1ldmVudF0gRG9jIHNoZXBoZXJkIHJldmlldzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFp bE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPllhcm9uLCB0aGUgZWRp dHMgaW4NCjwvc3Bhbj48L2E+PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL2luZGVwZW5kZW50 aWQvSWRlbnRpdHktRXZlbnRzL3B1bGwvMTEvY29tbWl0cy9lMjdhMjY5NmY3MDcxMDdlYzg1YTk5 NDg0NGM2Y2JlMjI4MzM1NmVjIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2lu YWxCb2R5Ij5odHRwczovL2dpdGh1Yi5jb20vaW5kZXBlbmRlbnRpZC9JZGVudGl0eS1FdmVudHMv cHVsbC8xMS9jb21taXRzL2UyN2EyNjk2ZjcwNzEwN2VjODVhOTk0ODQ0YzZjYmUyMjgzMzU2ZWM8 L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PC9zcGFu PjwvYT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBz dHlsZT0iY29sb3I6IzAwMjA2MCI+DQogYWRkcmVzcyB5b3VyIHJldmlldyBjb21tZW50cy48L3Nw YW4+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMw MDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3Bh biBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IC0tIE1pa2U8L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4g c3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUx IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PGI+RnJvbTo8L2I+ IElkLWV2ZW50ICZsdDtpZC1ldmVudC1ib3VuY2VzQGlldGYub3JnJmd0Ow0KPGI+T24gQmVoYWxm IE9mIDwvYj5NaWtlIEpvbmVzPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgRmVicnVhcnkg MjgsIDIwMTggMzo0NiBQTTxicj4NCjxiPlRvOjwvYj4gUGhpbCBIdW50ICZsdDtwaGlsLmh1bnRA b3JhY2xlLmNvbSZndDs7IFlhcm9uIFNoZWZmZXIgJmx0O3lhcm9uZi5pZXRmQGdtYWlsLmNvbSZn dDs8YnI+DQo8Yj5DYzo8L2I+IFNlY0V2ZW50ICZsdDtpZC1ldmVudEBpZXRmLm9yZyZndDs8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtJZC1ldmVudF0gRG9jIHNoZXBoZXJkIHJldmlldzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJv b2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+UGhp bCBpcyBjb3JyZWN0LiZuYnNwOyBUaGUg4oCcdHhu4oCdIGNsYWltIGlzIGludGVudGlvbmFsbHkg dXNhYmxlIHdpdGggYW55IEpXVCBhbmQgbm90IHNwZWNpZmljIHRvIFNFVHMuIFRoaXMganVzdCBo YXBwZW5zIHRvIGJlIHRoZSBzcGVjIHRvIGRlZmluZSBpdCBhbmQgYWRkIGl0IHRvIHRoZSBJQU5B DQogSldUIENsYWltcyByZWdpc3RyeS48L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFs Qm9keSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2tt YXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+WWFyb24s IEkgcGxhbiB0byB0d2VhayB5b3VyIGxhbmd1YWdlIOKAnDwvc3Bhbj5TRVRzIHNlcnZlIHRvIGV4 Y2hhbmdlIGluZm9ybWF0aW9uIGFib3V0IGlkZW50aXR5LXJlbGF0ZWQgZXZlbnRzPHNwYW4gc3R5 bGU9ImNvbG9yOiMwMDIwNjAiPuKAnSBiZWNhdXNlIHRoZSBjaGFydGVyIGlzIGFib3V0DQogc2Vj dXJpdHkgZXZlbnRzLCBvbmx5IHNvbWUgb2Ygd2hpY2ggYXJlIGlkZW50aXR5IGV2ZW50cy4mbmJz cDsgV2Ugc2hvdWxkbuKAmXQgbmFycm93IHRoZSBzY29wZSBvZiBhcHBsaWNhYmlsaXR5IGJleW9u ZCB3aGF04oCZcyBpbnRlbmRlZC48L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9k eSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJr Ol9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8L3NwYW4+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpf TWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9y aWdpbmFsQm9keSI+PGI+RnJvbTo8L2I+IElkLWV2ZW50ICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFp bHRvOmlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6 X01haWxPcmlnaW5hbEJvZHkiPmlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+PHNwYW4g c3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PC9zcGFuPjwvYT48c3BhbiBz dHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mZ3Q7DQo8Yj5PbiBCZWhhbGYg T2YgPC9iPlBoaWwgSHVudDxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDI4 LCAyMDE4IDM6MzUgUE08YnI+DQo8Yj5Ubzo8L2I+IFlhcm9uIFNoZWZmZXIgJmx0Ozwvc3Bhbj48 YSBocmVmPSJtYWlsdG86eWFyb25mLmlldGZAZ21haWwuY29tIj48c3BhbiBzdHlsZT0ibXNvLWJv b2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij55YXJvbmYuaWV0ZkBnbWFpbC5jb208L3NwYW4+PHNw YW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PC9zcGFuPjwvYT48c3Bh biBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mZ3Q7PGJyPg0KPGI+Q2M6 PC9iPiBTZWNFdmVudCAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzppZC1ldmVudEBpZXRmLm9y ZyI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+aWQtZXZlbnRA aWV0Zi5vcmc8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9k eSI+PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5 Ij4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbSWQtZXZlbnRdIERvYyBzaGVwaGVyZCBy ZXZpZXc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+WWFyb24sPG86cD48L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9v a21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21h cms6X01haWxPcmlnaW5hbEJvZHkiPlRoYW5rcyBmb3IgdGhlIGNvbW1lbnRzLCB3aWxsIGFkZCB0 byB0aGUgbmV4dCB1cGRhdGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdp bmFsQm9keSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFs Qm9keSI+TWlrZSBoYXMgYWRkZWQgc29tZSBvdGhlciBtaW5vciBlZGl0b3JpYWwgZml4ZXMgZm9y IGNvbnNpc3RlbmN5IHdpdGggSldUIGV0YyB3aGljaCBJIGJlbGlldmUgdGhlIGdyb3VwIGRpc2N1 c3NlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5BIGNvdXBs ZSBxdWVzdGlvbnMgaW5saW5l4oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9y aWdpbmFsQm9keSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFy azpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5QaGlsPC9zcGFu PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21h cms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+T3JhY2xlIENv cnBvcmF0aW9uLCBJZGVudGl0eSBDbG91ZCBTZXJ2aWNlcyBBcmNoaXRlY3Q8L3NwYW4+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj5AaW5kZXBlbmRlbnRpZDwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2tt YXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48L3NwYW4+PGEgaHJlZj0iaHR0cDovL3d3dy5pbmRlcGVu ZGVudGlkLmNvbSI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+ d3d3LmluZGVwZW5kZW50aWQuY29tPC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01h aWxPcmlnaW5hbEJvZHkiPjwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFp bE9yaWdpbmFsQm9keSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2tt YXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBv cmFjbGUuY29tIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5w aGlsLmh1bnRAb3JhY2xlLmNvbTwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWls T3JpZ2luYWxCb2R5Ij48L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxP cmlnaW5hbEJvZHkiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2tt YXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWls T3JpZ2luYWxCb2R5Ij5PbiBGZWIgMjgsIDIwMTgsIGF0IDM6MjcgUE0sIFlhcm9uIFNoZWZmZXIg Jmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86eWFyb25mLmlldGZAZ21haWwuY29tIj48c3BhbiBz dHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij55YXJvbmYuaWV0ZkBnbWFpbC5j b208L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PC9z cGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mZ3Q7 DQogd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPkhpLDxicj4NCjxi cj4NCkkgd2lsbCBiZSBkb2N1bWVudCBzaGVwaGVyZCBmb3IgdGhlIFNFVCBzcGVjLiBBcyBzdWNo LCBJIGp1c3QgcmVyZWFkIGl0IG9uY2UgYWdhaW4sIGFuZCBJIHRoaW5rIGl0IGlzIGluIHZlcnkg Z29vZCBzaGFwZS4gSGVyZSBhcmUgbXkgKG1vc3RseSBlZGl0b3JpYWwpIGNvbW1lbnRzLjxicj4N Cjxicj4NCi0gQWJzdHJhY3Q6IHBsZWFzZSBhZGQgdGhlIGZvbGxvd2luZyB0byBjbGFyaWZ5LCBl LmcuIGFmdGVyIHRoZSBmaXJzdCBzZW50ZW5jZTogU0VUcyBzZXJ2ZSB0byBleGNoYW5nZSBpbmZv cm1hdGlvbiBhYm91dCBpZGVudGl0eS1yZWxhdGVkIGV2ZW50cy48YnI+DQotIEEgc2VjdXJpdHkg c3ViamVjdCBNQVkgYmUgcGVybWFuZW50IC0gdGhpcyBpcyBkZXNjcmlwdGl2ZSB0ZXh0LCBwbGVh c2UgY2hhbmdlICZxdW90O01BWSZxdW90OyB0byAmcXVvdDttYXkmcXVvdDsuPGJyPg0KLSAmcXVv dDtTRVRzIGhhdmUgbm8gY2FwYWJpbGl0eSBmb3IgZXJyb3Igc2lnbmFsaW5nIHRvIGVuc3VyZSB0 aGUgdmFsaWRhdGlvbiBvZiBhIHJlY2VpdmVkIFNFVCZxdW90OyAtIFNFVHMgYXJlIGEgZm9ybWF0 LCBzbyBpdCBpcyBhIGhpZ2hlciBsZXZlbCBwcm90b2NvbCB0aGF0IG1heSBvciBtYXkgbm90IHNp Z25hbCBlcnJvcnMuIEkgc3VnZ2VzdCB0byByZW1vdmUgdGhpcyBzZW50ZW5jZS48YnI+DQotICZx dW90O2hhcyBvY2N1cnJlZCBhYm91dCBhIFN1YmplY3QuJnF1b3Q7IFNob3VsZCB0aGlzIGJlICZx dW90O2hhcyBvY2N1cnJlZCB0byBhIFN1YmplY3TigJ0/PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPkkgd2lsbCByZS1yZWFkLiBJIHRo aW5rIHdoYXQgdGhlIHNwZWMgaXMgdHJ5aW5nIHRvIHNheSBpcyB0byBvciByZWxhdGVkIHRvLiBN ZWFuaW5nIHRoZSBldmVuIGlzIGRpcmVjdGx5IHJlbGF0ZWQgdG8gdGhlIHN1YmplY3QgYnV0IG5v dCBuZWNlc3NhcmlseSB0byB0aGUgc3ViamVjdC4gJm5ic3A7SSB3aWxsIHJldmlldyBhbmQgc3Vn Z2VzdA0KIHNvbWUgdGV4dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0 eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4tIDIuMjogZm9yIHJlYWRhYmlsaXR5 LCBwbGVhc2UgaW5jbHVkZSB0aGUgZnVsbCBuYW1lcyBvZiB0aGUgY2xhaW1zICgmcXVvdDtJc3N1 ZXImcXVvdDssICZxdW90O0pXVCBJRCZxdW90OyBldGMuKS48YnI+DQotIElNTyB0aGUgZGlzdGlu Y3Rpb24gYmV0d2VlbiBKV1RzIGFuZCBTRVRzIHdpdGggcmVnYXJkIHRvIHRoZSBuZWVkIHRvIHVz ZSAmcXVvdDtleHAmcXVvdDsgaXMgbm90IGNvbnZpbmNpbmcuIEkgc3VnZ2VzdCB3ZSByZWZlciB0 byBTZWMuIDQuNSBmb3IgYSBiZXR0ZXIgcmF0aW9uYWxlIHdoeSB3ZSBtYWtlIHRoaXMgY2xhaW0g Tk9UIFJFQ09NTUVOREVEIHJhdGhlciB0aGFuIE9QVElPTkFMIGFzIGluIFJGQyA3NTE5Ljxicj4N Ci0gdHhuOiB0aGlzIHBhcmFncmFwaCBzaG91bGQgc3BlYWsgYWJvdXQgU0VUcyByYXRoZXIgdGhh biBKV1RzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFy azpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3Jp Z2luYWxCb2R5Ij5JIHdpbGwgZGVmZXIgdG8gTWlrZSwgYnV0IEkgYmVsaWV2ZSBoZSBzdWdnZXN0 ZWQgdG8gaGF2ZSB0aGlzIHJlZ2lzdGVyZWQgZm9yIGdlbmVyYWwgSldUIHVzZS4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01h aWxPcmlnaW5hbEJvZHkiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWls T3JpZ2luYWxCb2R5Ij4tICZxdW90O3RvIHByb3ZpZGUgaW50ZWdyaXR5LCBjb25maWRlbnRpYWxp dHksIGFuZCBpc3N1ZXIgdmFsaWRhdGlvbiZxdW90Oywgc2hvdWxkIGJlICZxdW90O2lzc3VlciBh dXRoZW50aWNpdHkmcXVvdDsuPGJyPg0KLSAmcXVvdDtXaGV0aGVyIGFuZCBob3cgbXVsdGlwbGUg JnF1b3Q7ZXZlbnRzJnF1b3Q7IHZhbHVlcyBhcmUgdXNlZCZxdW90OzogdGhlIHJlYWRlciB3aG8g aGFzIG5vdCBiZWVuIGZvbGxvd2luZyBvdXIgZGlzY3Vzc2lvbnMgbWF5IG5vdCB1bmRlcnN0YW5k IHdoYXQgdGhpcyBtZWFucywgbWF5YmUgd2Ugc2hvdWxkIHNheSBpbiBwYXJlbnRoZXNlcywgKGku ZS4gbXVsdGlwbGUgbWVtYmVycyBpbiB0aGUgJnF1b3Q7ZXZlbnRzJnF1b3Q7IEpTT04gb2JqZWN0 KS48YnI+DQotICZxdW90O01VU1Qgc3VwcG9ydCBUTFMgMS4yJnF1b3Q7IC0gYWRkICZxdW90O29y IGEgaGlnaGVyIHZlcnNpb24mcXVvdDsuPGJyPg0KLSA0LjU6IGludGVudGlvbmFsbHkgLSBJIHRo aW5rIHdlIG1lYW4gJnF1b3Q7bWFsaWNpb3VzbHkmcXVvdDsuPGJyPg0KLSA2LjEuMTogJnF1b3Q7 U2VjdXJpdHkgRXZlbnQgVVJJJnF1b3Q7IC0gdGhpcyBkZXNjcmlwdGlvbiBpcyBpbmNvcnJlY3Qs IHNob3VsZCBwcm9iYWJseSBiZSAmcXVvdDtTZWN1cml0eSBFdmVudCBpbmZvcm1hdGlvbiZxdW90 OyBvciBzb21ldGhpbmcgc2ltaWxhcmx5IHZhZ3VlLjxicj4NCi0gUkZDIDc2MTcgLSB1bnVzZWQg cmVmLiBTaW1pbGFybHkgc2FtbC1jb3JlLjxicj4NCjxicj4NClRoYW5rcyw8YnI+DQombmJzcDsm bmJzcDsmbmJzcDsgWWFyb248YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCklkLWV2ZW50IG1haWxpbmcgbGlzdDxicj4NCjwvc3Bh bj48YSBocmVmPSJtYWlsdG86SWQtZXZlbnRAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJtc28tYm9v a21hcms6X01haWxPcmlnaW5hbEJvZHkiPklkLWV2ZW50QGlldGYub3JnPC9zcGFuPjxzcGFuIHN0 eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjwvc3Bhbj48L2E+PHNwYW4gc3R5 bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PGJyPg0KPC9zcGFuPjxhIGhyZWY9 Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3 LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZhbXA7ZD1Ed0lHYVEmYW1wO2M9 Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZhbXA7cj1uYTVGVnpC VFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJmFtcDttPUYtUW12REZUQXBpUTZX amdhMFU5c3NacV9RTUxJWUdfWGlVMmc1Sk8wVWcmYW1wO3M9bkx3RFpodU00Ql9aVnhYM2RHRWFm Wmd4WU9DUkRHTEJBUFRBN0lKM1lVbyZhbXA7ZSI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpf TWFpbE9yaWdpbmFsQm9keSI+aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy bD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmFt cDtkPUR3SUdhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElf Sm5FJmFtcDtyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmYW1w O209Ri1RbXZERlRBcGlRNldqZ2EwVTlzc1pxX1FNTElZR19YaVUyZzVKTzBVZyZhbXA7cz1uTHdE Wmh1TTRCX1pWeFgzZEdFYWZaZ3hZT0NSREdMQkFQVEE3SUozWVVvJmFtcDtlPC9zcGFuPjxzcGFu IHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjwvc3Bhbj48L2E+PHNwYW4g c3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_49FAC72F48E74B4C8ACD1259DADFE8FCamazoncom_-- From nobody Fri Mar 2 03:11:03 2018 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 66DD4127698 for ; Fri, 2 Mar 2018 03:11:02 -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 o-Y5PmW0VNB0 for ; Fri, 2 Mar 2018 03:11:01 -0800 (PST) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD85A127601 for ; Fri, 2 Mar 2018 03:11:00 -0800 (PST) Received: by mail-wr0-x233.google.com with SMTP id m12so9660787wrm.13 for ; Fri, 02 Mar 2018 03:11:00 -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 :content-transfer-encoding:content-language; bh=dePXkLGdpsmOjHaVn0l6GtzagBq9Ce5o62jpr+prcWg=; b=qUAUyLeCrg3ZyoHtmoAJimlzXFmBypM/mm8Iq4uQQqKcwDOaQNpNHOE5NyOZqroyML nGhatrZ/mDr8i3QyUwjl1n7UbAFf9NkhrrmXKOnccHFXdHaGNP5WM/wMwyLyG5vQtlcT 0D0i5sGO7UyqmYuC/3QaSrC53yscT1OpRzFudo01igttXyVmOJ8U/rFrHj0pi5O/bEkQ En6wL+9M/XdRZaYHFij3WRXmVISfswnIC/NY9dtAcrk3g+iY1fIhptCqU7DmBtjgDj5d X0FmlhxVM4Uhly/jPQf+my9d2MUcPz+MC79GId+jdDXxqgypwGXUrDTy1xklxketsgiP Snxw== 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:content-transfer-encoding:content-language; bh=dePXkLGdpsmOjHaVn0l6GtzagBq9Ce5o62jpr+prcWg=; b=Fo+qeOCXFbuerrYbtJ5Aso8P6BeflUSmyqfel/tF1+447SqnYiQoUeponXH4DZPV3S DDfls0oSIhK2bwlQIIir0dPS2PM1sKCpLkC+tgGDVIo47U+JBPTM4Uga7yLgKbdIPQRq f/6wOWMQvrXVbqgiInG9IZZLCj63k+NHuQm1KV1qMYMnfWB2z56SJhWQczlRn3PGV1J5 UxBODtzRfv1Dhl28DBpUD1DTvLSik8416XF8mRT6RWo6/GisJ5inBiLgYf39oVrJ3DoM Fm7gYJQZyxwG79hVS30cMkOxrwLAd0/WlHJsGqxWUX6EQjAV41q7AQn4Ojd2zq53ME8s txMA== X-Gm-Message-State: APf1xPBotNUZN5e6EKrrd72E/ygdQUYz+f2qCigYv2rNKrmPRsV1rtkv 9SxF2ujFh9Y9pCyPE08omJ1q4w3n X-Google-Smtp-Source: AG47ELsFSRmTgu77FfhG4UMuykkNWtieJMw4Z7caGFaex/u1pLWBC946iqcrc4L6lrav4z5dLkoFpg== X-Received: by 10.223.139.130 with SMTP id o2mr4973745wra.147.1519989058935; Fri, 02 Mar 2018 03:10:58 -0800 (PST) Received: from [10.0.0.149] (bzq-109-65-61-134.red.bezeqint.net. [109.65.61.134]) by smtp.gmail.com with ESMTPSA id b136sm1052298wme.34.2018.03.02.03.10.57 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Mar 2018 03:10:58 -0800 (PST) To: SecEvent From: Yaron Sheffer Message-ID: Date: Fri, 2 Mar 2018 13:10:56 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [Id-event] SecEvent meeting agenda items - urgent X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 02 Mar 2018 11:11:02 -0000 Hi everyone, We're a bit late on this. Please let Dick and I know ASAP if you'd like a slot on the London meeting agenda. Thanks,     Yaron From nobody Fri Mar 2 10:30:56 2018 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 C09D9126C25 for ; Fri, 2 Mar 2018 10:30:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 lP5rYvIMVWhd for ; Fri, 2 Mar 2018 10:30:53 -0800 (PST) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::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 15BD012D7F2 for ; Fri, 2 Mar 2018 10:30:52 -0800 (PST) Received: by mail-ua0-x236.google.com with SMTP id i15so6638191uak.3 for ; Fri, 02 Mar 2018 10:30:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=1Di/aTBLqTIHCTyzffqMJu2kCOyZe9zOAh+BiXOU3TA=; b=eBT9uuoXn3/hewqB1tpQtCG7PYVHwPm2acOZ046Mc9ufvFZrXcnTvBYm9eR0nXkL4T XXEv/xVqHiRUHC+LFim2bhzvWs8HK9SJFOUX1sZTPy+InrKfGt6k7xdf+fLhTGo34lk0 H9NjRax4geZM0oRCecWbdSZ0/lW94+RpmUsXMigjM7wZ58umS/TqL3BhrXWpBcGB2WTg U6kuwEBpNxhkY4ypSwrPJtubFyBTukZ2OpO56i46T4wMeujsTzkbuKlzHoJOci36ew8h KuiTJmZ90LWXIPbUOD/9rx3098saFjE+8ha6/sscgs6XaSU4t9J11U0LQ11sENn9OArd AzSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=1Di/aTBLqTIHCTyzffqMJu2kCOyZe9zOAh+BiXOU3TA=; b=cV0Pm0aqTVKX7HFOUuypdKV2U8dPrDSn9hmhP+eewJAsjH+K91tAZooz67VxSR47mu G5BbDq4VXeVoa8ApMk5ALxOZVonwabvxwUXbKSfUqwG0fMUNzuf4/Zbc7mE79nAITDDl W3WhtisPezHzZruPXtU7krmxjUiHpcRY8Y8mMyRUUdQ5oMzmSWghYZraQUCI/G9hhFm7 2BahcN8L/lRjGoVUKHhNKotcg7pvnC62OcjhZDLZZP9/SBJAJc0pseiZ4knbqtdTfwOP vXwzm1FGJsXN7ioHulihUcTcYCYRIMQ5NYH287pshZQqG9CS0KwtNv/7cK96d34QIOmg oAeg== X-Gm-Message-State: APf1xPD2+CcZMUf6LNBfb0bs37awQBkH+JaIwDqSZ0YU4lxjKNSqQuPu IQmZZdbDYXbvMnUy295HWuVQqpHU4rC6rKaXbbuZzAzQ764= X-Google-Smtp-Source: AG47ELtG+jvu6vlAgaXO8d3c+9FdzzEGzTJepvyAkfoczJNRizZhdejP53Htr1cJvseT4VjSIQuxsX0tHrVfPCwrt9E= X-Received: by 10.159.61.43 with SMTP id l43mr4520891uai.6.1520015450361; Fri, 02 Mar 2018 10:30:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.94.88 with HTTP; Fri, 2 Mar 2018 10:30:29 -0800 (PST) From: Marius Scurtescu Date: Fri, 2 Mar 2018 10:30:29 -0800 Message-ID: To: ID Events Mailing List , Phillip Hunt Content-Type: multipart/alternative; boundary="f403045e8b7cf9732c0566722ce0" Archived-At: Subject: [Id-event] small changes to draft-ietf-secevent-delivery X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 02 Mar 2018 18:30:55 -0000 --f403045e8b7cf9732c0566722ce0 Content-Type: text/plain; charset="UTF-8" I have a few other suggestions: 1. In section 1.2 we could drop the definition of Identity Provider and Relying Party. I don't think these are necessary in this spec. 2. In section 2.1, the description of the PUSH delivery mode states that the response must contain "Content-Type: application/json". I think that is the case only for error responses, I think on success no Content-Type is needed at all. 3. In section 2.2, it is stated that "the Event Receiver SHALL indicate an HTTP Status 400 error with an error code as described in Section 2.4". I think that some error codes should be matched by other 4xx codes (for example 401 and 403). I think it would be useful to list all the possible error codes and corresponding HTTP Status codes in this section and not refer to 2.4, 4. In section 2.3.1, the description of maxEvents, at the very end. A conflict between zero request events and returnImmediately is described and the later should be ignored. I think this should not be a silent ignore but an error condition, The current spec is at: https://tools.ietf.org/html/draft-ietf-secevent-delivery-01 I am happy to send pull requests for all these changes. Let me know. Thanks, Marius --f403045e8b7cf9732c0566722ce0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have a few other suggestions:

1. In sect= ion 1.2 we could drop the definition of Identity Provider and Relying Party= . I don't think these are necessary in this spec.

2. In = section 2.1, the description of the PUSH delivery mode states that the resp= onse must contain "Content-Type: application/json". I think that = is the case only for error responses, I think on success no Content-Type is= needed at all.

3. In section 2.2, it is stated that "t= he Event Receiver SHALL indicate an HTTP Status 400 error with an error cod= e as described in Section 2.4". I think that some error codes should b= e matched by other 4xx codes (for example 401 and 403). I think it would be= useful to list all the possible error codes and corresponding HTTP Status = codes in this section and not refer to 2.4,

4. In section 2.= 3.1, the description of maxEvents, at the very end. A conflict between zero= request events and returnImmediately is described and the later should be = ignored. I think this should not be a silent ignore but an error condition,=

The current spec is at:=
I am happy to send pull requests for all these changes. Let= me know.

Thanks,
Marius
--f403045e8b7cf9732c0566722ce0-- From nobody Fri Mar 2 11:46:41 2018 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 9E9D9124217 for ; Fri, 2 Mar 2018 11:46:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.512 X-Spam-Level: X-Spam-Status: No, score=-14.512 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5SopkPPwhW9 for ; Fri, 2 Mar 2018 11:46:38 -0800 (PST) Received: from smtp-fw-9101.amazon.com (smtp-fw-9101.amazon.com [207.171.184.25]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EC561200FC for ; Fri, 2 Mar 2018 11:46:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1520019997; x=1551555997; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=h3jYZfteeBAadFiQYkMTJv6tioIKrZkKnfrD+wZjawc=; b=TKHUeyJukQ2oyiajLwXjpqsS0SH+mp6aog/sq22FDr8WRtm3r1Iqvbc8 2cb4bJJNYNj5KwFQLNytGbHindXHf8HuU9PUZR/A1a4y8/ZPQ+pZyMwuO UaLyqHsxP3+A7Pu4NGWOvJCg/3nleaZRKaD7cLU1SBOEcivXjlmDsQbrf Q=; X-IronPort-AV: E=Sophos;i="5.47,413,1515456000"; d="scan'208";a="725440298" Received: from sea3-co-svc-lb6-vlan3.sea.amazon.com (HELO email-inbound-relay-1e-428a6f71.us-east-1.amazon.com) ([10.47.22.38]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Mar 2018 19:46:36 +0000 Received: from EX13MTAUWC001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan2.iad.amazon.com [10.40.159.162]) by email-inbound-relay-1e-428a6f71.us-east-1.amazon.com (8.14.7/8.14.7) with ESMTP id w22JkV3f066159 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 2 Mar 2018 19:46:35 GMT Received: from EX13D11UWC001.ant.amazon.com (10.43.162.151) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Fri, 2 Mar 2018 19:46:34 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC001.ant.amazon.com (10.43.162.151) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Fri, 2 Mar 2018 19:46:34 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1236.000; Fri, 2 Mar 2018 19:46:34 +0000 From: "Richard Backman, Annabelle" To: Yaron Sheffer , SecEvent Thread-Topic: [Id-event] SecEvent meeting agenda items - urgent Thread-Index: AQHTshdMZLK8+/M3NUCmmQxaNnuJMaO81AsA Date: Fri, 2 Mar 2018 19:46:34 +0000 Message-ID: <0A395F45-4391-41DE-BF10-370013E6992C@amazon.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.a.0.180210 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.160.245] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Id-event] SecEvent meeting agenda items - urgent X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 02 Mar 2018 19:46:40 -0000 V2Ugc2hvdWxkIHNwZW5kIHNvbWUgdGltZSBvbiBFdmVudCBTdWJqZWN0IFR5cGVzLiBNYXliZSB3 ZSBjYW4gc3BlbmQgc29tZSB0aW1lIG9uIGl0IGVhcmx5IGluIHRoZSB3ZWVrLCBhbmQgcHJlc2Vu dCByZXN1bHRzIG9uIEZyaWRheT8NCg0KLS0gDQpBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQpB bWF6b24g4oCTIElkZW50aXR5IFNlcnZpY2VzDQogDQoNCu+7v09uIDMvMi8xOCwgMzoxMiBBTSwg IklkLWV2ZW50IG9uIGJlaGFsZiBvZiBZYXJvbiBTaGVmZmVyIiA8aWQtZXZlbnQtYm91bmNlc0Bp ZXRmLm9yZyBvbiBiZWhhbGYgb2YgeWFyb25mLmlldGZAZ21haWwuY29tPiB3cm90ZToNCg0KICAg IEhpIGV2ZXJ5b25lLA0KICAgIA0KICAgIFdlJ3JlIGEgYml0IGxhdGUgb24gdGhpcy4gUGxlYXNl IGxldCBEaWNrIGFuZCBJIGtub3cgQVNBUCBpZiB5b3UnZCBsaWtlIA0KICAgIGEgc2xvdCBvbiB0 aGUgTG9uZG9uIG1lZXRpbmcgYWdlbmRhLg0KICAgIA0KICAgIFRoYW5rcywNCiAgICAgICAgIFlh cm9uDQogICAgDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCiAgICBJZC1ldmVudCBtYWlsaW5nIGxpc3QNCiAgICBJZC1ldmVudEBpZXRmLm9yZw0K ICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQNCiAgICAN Cg0K From nobody Fri Mar 2 11:55:05 2018 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 A4321129C6A for ; Fri, 2 Mar 2018 11:55:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 6YGV76uFL2yb for ; Fri, 2 Mar 2018 11:55:01 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0104.outbound.protection.outlook.com [104.47.41.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32F21124217 for ; Fri, 2 Mar 2018 11:54:57 -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=FyURXnRU233H1CodLJmZXyQJzimXM30t6kEQ0NnUZ1o=; b=WbktNH1T46uRhla2jLTlTPbQAvjARvMr2bwfAoDUBIrHyt6tsLC5l8+Vaef9x7aespYrkOj9ugfOx7ZnU1tnmVqZrsPARpf++mR9YrH4NmnolJo/PfrsKWkOs22Z8mMLxmCbjDm1ZfPQFBJjN0wcQnKUpXVKx1H0CVF6EfwY5N4= Received: from SN6PR2101MB0943.namprd21.prod.outlook.com (52.132.114.20) by SN6PR2101MB1118.namprd21.prod.outlook.com (52.132.115.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.567.2; Fri, 2 Mar 2018 19:54:55 +0000 Received: from SN6PR2101MB0943.namprd21.prod.outlook.com ([fe80::9866:f6b5:e2d6:50]) by SN6PR2101MB0943.namprd21.prod.outlook.com ([fe80::9866:f6b5:e2d6:50%2]) with mapi id 15.20.0567.006; Fri, 2 Mar 2018 19:54:55 +0000 From: Mike Jones To: Yaron Sheffer , SecEvent Thread-Topic: [Id-event] SecEvent meeting agenda items - urgent Thread-Index: AQHTshcscUYfLNtrLUKlQil4BZPscqO9XFoA Date: Fri, 2 Mar 2018 19:54:55 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-03-02T19:54:54.2365262Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General x-originating-ip: [2001:4898:80e8:1::562] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN6PR2101MB1118; 6:VRFEvIuVSurcAm/7slgf0vBICnPLv8B5+3UwieUDzJXe9SIbPo7WzqJuwpR4+PrgE/K0fscvTSTvVncJzGHIAr2i+Jw8c9BI/wuO1VQC9N7LfOabJEGXPi5HBw+AHtb4d9Ylk8K9ab/7KKpqzcOrtxMrruFsv/l7p6Jh8lkT4GcbywEzxF+jmeG3pyqbKLZrhQDbeYiLruf0GlvkiG99q4ga+e2/qlEi1c01ELKFcXAJgK43INstv9jPBK8fDzj0veKrpbZDIjeBcGS1JhCwG5/MF4Qz5hMB4K9HUyJ935Rxh//MmJ2q87C81+H0BlJwkY4Kxe+2wT4mYnfZz95SEzubhLTMRV/UX1wRplkjaiPvrsOPRV5k1HhqBKIJ44f3; 5:rFo8bFzuxsxsYaCmT3aE8njPxoeACSSk+BjC35pJZovoL1nmWY9WHCLgw95AjdDMmIr1u5Q+JAr8OmgeIE+5QE0hf2aJdAl1wRQqWXwcEJsZDamDm87hiuYhwwXYlq/E36POKGwBoDIWmmW4aRJbiN7ljnpbLXCsk+hTX4ilMaI=; 24:GK9736TlTCeQqU90gfB13AQlVj/Ca90DdyU8sA0BCbcffP6yK4+pZM/TkZ/BtcdpwVsB34SUc7rKVptNEJ1K+dkACGGZURgk+9NdiOe2Gp4=; 7:q61m2rQ7zdpjgpS4OAadeDjue4BmhgiY2F4+WoyXp/khB1uy7f+rWGA4agTtBWF1SuOWd+v5Fk9P0oggk3xwZpRg5joVp4UsVZ+U9XdYaeIpAWaBa4Pu18E3qEEvC9BvrBYbOhzufwnUNdUPMZnPVEVhXjuF6jzbPgIwm2yi6q6x6kBX6RiE/+IMcfdbrgg+JmLuNHvEKiZVpSHT7glUdYBvWvSZieqqCWVyRUhgq7tJNZ+q3wH5anT9MXCTzsom x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 1f6f1dbd-170a-4a47-2302-08d5807778ac x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:SN6PR2101MB1118; x-ms-traffictypediagnostic: SN6PR2101MB1118: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040501)(2401047)(8121501046)(5005006)(3231220)(944501235)(52105095)(93006095)(93001095)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041288)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123560045)(20161123562045)(6072148)(201708071742011); SRVR:SN6PR2101MB1118; BCL:0; PCL:0; RULEID:; SRVR:SN6PR2101MB1118; x-forefront-prvs: 05991796DF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(346002)(366004)(39380400002)(39860400002)(376002)(199004)(189003)(22804003)(53754006)(13464003)(68736007)(46003)(74316002)(5660300001)(22452003)(39060400002)(3280700002)(2950100002)(6246003)(305945005)(7736002)(53546011)(6506007)(3660700001)(5250100002)(106356001)(6346003)(102836004)(186003)(33656002)(72206003)(86612001)(966005)(97736004)(478600001)(25786009)(110136005)(7696005)(14454004)(6436002)(86362001)(316002)(9686003)(8990500004)(8936002)(105586002)(53936002)(229853002)(6116002)(81166006)(10090500001)(10290500003)(2900100001)(81156014)(6306002)(55016002)(8676002)(218543002)(99286004)(76176011)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR2101MB1118; H:SN6PR2101MB0943.namprd21.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) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-message-info: fjY8Fc8HRcnml+THLDGKGR6hZaYTIX5qqsxglXshFtw+sSJur/SF4UzgFLMT7DnoW+zsRuCLUHDwFI5ahPpMH6PdqRIjKONexydNRwIyaWKcSe699zHqIdZb/MY097ItN9OEIbFdd4rj7bz8KW5c9gekGSILyL0tFtwMVqzY6Q4= 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-Network-Message-Id: 1f6f1dbd-170a-4a47-2302-08d5807778ac X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Mar 2018 19:54:55.5653 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR2101MB1118 Archived-At: Subject: Re: [Id-event] SecEvent meeting agenda items - urgent X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 02 Mar 2018 19:55:04 -0000 SSBwbGFuIHRvIGRvIGEgc2hvcnQgcHJlc2VudGF0aW9uIG9uIHRoZSBzdGF0dXMgb2YgdGhlIFNF VCBkcmFmdC4gIDE1IG1pbnV0ZXMgc2hvdWxkIGJlIHN1ZmZpY2llbnQuDQoNCgkJCQktLSBNaWtl DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBJZC1ldmVudCA8aWQtZXZlbnQt Ym91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIFlhcm9uIFNoZWZmZXINClNlbnQ6IEZyaWRh eSwgTWFyY2ggMiwgMjAxOCAzOjExIEFNDQpUbzogU2VjRXZlbnQgPGlkLWV2ZW50QGlldGYub3Jn Pg0KU3ViamVjdDogW0lkLWV2ZW50XSBTZWNFdmVudCBtZWV0aW5nIGFnZW5kYSBpdGVtcyAtIHVy Z2VudA0KDQpIaSBldmVyeW9uZSwNCg0KV2UncmUgYSBiaXQgbGF0ZSBvbiB0aGlzLiBQbGVhc2Ug bGV0IERpY2sgYW5kIEkga25vdyBBU0FQIGlmIHlvdSdkIGxpa2UgYSBzbG90IG9uIHRoZSBMb25k b24gbWVldGluZyBhZ2VuZGEuDQoNClRoYW5rcywNCiDCoMKgwqAgWWFyb24NCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklkLWV2ZW50IG1haWxpbmcg bGlzdA0KSWQtZXZlbnRAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vaWQtZXZlbnQNCg== From nobody Fri Mar 2 11:55:31 2018 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 227D6124217 for ; Fri, 2 Mar 2018 11:55:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.022 X-Spam-Level: X-Spam-Status: No, score=-0.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jLKhyWrgF7GO for ; Fri, 2 Mar 2018 11:55:27 -0800 (PST) Received: from userp2120.oracle.com (userp2120.oracle.com [156.151.31.85]) (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 ABD24129C6A for ; Fri, 2 Mar 2018 11:55:26 -0800 (PST) Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w22JqFiT011542; Fri, 2 Mar 2018 19:55:23 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=corp-2017-10-26; bh=kgsIra6/Qfvd2lmIhgiaRtey1ciXsC4a/+Ze+9dUcPc=; b=dAE6fCLENTK0yka86WuWlcTzrFi9V825nvMP0cGhirxcX+Y/5nUDP4LCfgqJUXncN1qK wfQ+Uaw8yyb1fyV/JT+5h1N/T/qSS0YrbNG/XGvddKnqAUJIiStoAQUjD/tyENMYb2SL BoHlsAzmQlGHwWs0dL+63/r399LNbE6DNIGVIcaV+A4jewMcCo3NYmzY0b5N59lFXSsU 9dsiZ9cg31MkFYntYpQ7gmnpZk6hdwQSraWg5kdIhJuMMvGu022lahYSgZJeyqlVm02G VHbA8kGx/wmz8g+OnomLFPq16Z/f7c3vm0Czj/FoMKwr0n+LlrO5YW5UzbGwbXjD0U5f Ig== Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp2120.oracle.com with ESMTP id 2gfbjw8et0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 02 Mar 2018 19:55:23 +0000 Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w22JtMHi006496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 2 Mar 2018 19:55:22 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w22JtMwT030098; Fri, 2 Mar 2018 19:55:22 GMT Received: from [192.168.1.28] (/70.70.142.148) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 02 Mar 2018 11:55:22 -0800 From: Phil Hunt Message-Id: <57C95B37-57A5-440E-9A4C-2D32B3677B9F@oracle.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_14DC493E-38E3-475C-BAC8-B2D16DB24FB3" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Fri, 2 Mar 2018 11:55:20 -0800 In-Reply-To: Cc: ID Events Mailing List To: Marius Scurtescu References: X-Mailer: Apple Mail (2.3445.5.20) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8820 signatures=668682 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803020234 Archived-At: Subject: Re: [Id-event] small changes to draft-ietf-secevent-delivery X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 02 Mar 2018 19:55:29 -0000 --Apple-Mail=_14DC493E-38E3-475C-BAC8-B2D16DB24FB3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Marius, Thanks. Item 1 and 2 look reasonable. for Item 3, 4, I think the group should review. See below. Given the submission deadline is Monday, it would be good to wait group = confirmation of your proposals. Phil Oracle Corporation, Identity Cloud Services Architect @independentid www.independentid.com = phil.hunt@oracle.com = > On Mar 2, 2018, at 10:30 AM, Marius Scurtescu = wrote: >=20 > I have a few other suggestions: >=20 > 1. In section 1.2 we could drop the definition of Identity Provider = and Relying Party. I don't think these are necessary in this spec. >=20 > 2. In section 2.1, the description of the PUSH delivery mode states = that the response must contain "Content-Type: application/json". I think = that is the case only for error responses, I think on success no = Content-Type is needed at all. >=20 > 3. In section 2.2, it is stated that "the Event Receiver SHALL = indicate an HTTP Status 400 error with an error code as described in = Section 2.4". I think that some error codes should be matched by other = 4xx codes (for example 401 and 403). I think it would be useful to list = all the possible error codes and corresponding HTTP Status codes in this = section and not refer to 2.4, The 4xx messages are assumed by the HTTP RFCs while the errors in = sec 2.4 related to errors around jwt processing. We can call out = specific 4xx errors that are likely to occur, but I find that people = then have issues wondering if they can ever use the complete set of = error conditions from RFC7231.=20 Would people find it useful to clarify or give examples of how 7231 = errors might occur? I=E2=80=99m not sure which of the sec 2.4 error codes could be matched = with 401 or 403. These are mostly JWT error conditions. Can you = elaborate? >=20 > 4. In section 2.3.1, the description of maxEvents, at the very end. A = conflict between zero request events and returnImmediately is described = and the later should be ignored. I think this should not be a silent = ignore but an error condition, The value of 0 is used to allow a poller to acknowledge previously = received SETs without having to process or wait for new events. Thus = returnImmediately is assumed. Thus the value of returnImmediately is = ignored. Some participants indicated a desire to keep acknowledgement threads = separate from SET polling threads. Others wanted to be able to do both = at the same time. >=20 > The current spec is at: > https://tools.ietf.org/html/draft-ietf-secevent-delivery-01 = >=20 > I am happy to send pull requests for all these changes. Let me know. >=20 > Thanks, > Marius > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65ea= pI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3Dne_ktq-vH7-ENPz= 2hHpvEBD9gZ8NVol5ZAKe9EeHvu8&s=3DuhRVJB8aZnVZHEY_MgIwN8ZjrBDaxt7YDmif4wyv6= jg&e=3D --Apple-Mail=_14DC493E-38E3-475C-BAC8-B2D16DB24FB3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Marius,

Thanks.

Item 1 and 2 look reasonable.
for Item 3, 4, I think the group = should review. See below.

Given the submission deadline is Monday, it would be good to = wait group confirmation of your proposals.

Phil

Oracle Corporation, Identity Cloud = Services Architect
@independentid
www.independentid.com
phil.hunt@oracle.com

On Mar 2, 2018, at 10:30 AM, Marius Scurtescu <mscurtescu@google.com> wrote:

I have a few other suggestions:

1. In section 1.2 we could drop the definition of Identity = Provider and Relying Party. I don't think these are necessary in this = spec.

2. In section 2.1, the description of the PUSH delivery mode = states that the response must contain "Content-Type: application/json". = I think that is the case only for error responses, I think on success no = Content-Type is needed at all.

3. In section 2.2, it is stated that "the Event Receiver = SHALL indicate an HTTP Status 400 error with an error code as described = in Section 2.4". I think that some error codes should be matched by = other 4xx codes (for example 401 and 403). I think it would be useful to = list all the possible error codes and corresponding HTTP Status codes in = this section and not refer to = 2.4,

<PH>The= 4xx messages are assumed by the HTTP RFCs while the errors in sec 2.4 = related to errors around jwt processing. We can call out specific 4xx = errors that are likely to occur, but I find that people then have issues = wondering if they can ever use the complete set of error conditions from = RFC7231. 

Would people find it = useful to clarify or give examples of how 7231 errors might = occur?

I=E2=80=99m not sure which of = the sec 2.4 error codes could be matched with 401 or 403. These are = mostly JWT error conditions. Can you elaborate?


4. In section 2.3.1, the description of maxEvents, at the = very end. A conflict between zero request events and returnImmediately = is described and the later should be ignored. I think this should not be = a silent ignore but an error = condition,
<PH>The value of 0 is = used to allow a poller to acknowledge previously received SETs without = having to process or wait for new events. Thus returnImmediately is = assumed. Thus the value of returnImmediately is ignored.

Some participants indicated a desire to keep = acknowledgement threads separate from SET polling threads.  Others = wanted to be able to do both at the same time.

The current spec is at:
https://tools.ietf.org/html/draft-ietf-secevent-delivery-01=

I am happy to = send pull requests for all these changes. Let me know.

Thanks,
Marius
_______________________________________________
Id-event = mailing list
Id-event@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf= .org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZY= R8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4K= ZNA&m=3Dne_ktq-vH7-ENPz2hHpvEBD9gZ8NVol5ZAKe9EeHvu8&s=3DuhRVJB8aZn= VZHEY_MgIwN8ZjrBDaxt7YDmif4wyv6jg&e=3D

= --Apple-Mail=_14DC493E-38E3-475C-BAC8-B2D16DB24FB3-- From nobody Fri Mar 2 14:12:33 2018 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 6E70E12D7F1 for ; Fri, 2 Mar 2018 14:12:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.022 X-Spam-Level: X-Spam-Status: No, score=-0.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zy79WTcy9tsu for ; Fri, 2 Mar 2018 14:12:29 -0800 (PST) Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE516124239 for ; Fri, 2 Mar 2018 14:12:28 -0800 (PST) Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w22MCQg2020514; Fri, 2 Mar 2018 22:12:26 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=corp-2017-10-26; bh=h2y6FojehGxf2DYAsOQ45JBQLXyxx+MlxjfcI13U4yE=; b=I8UxRneAi4PPQWMKcr9jYJm3nalVF+E4YU/bB8q9yJlkbpNpTh9Ico6eKAry104xRXsS VqRQKij42b2KOecMQ9jbDvNPaBaYXnE1QGQHzOrZHm9VA0tPNPc0L7cIG1Ownf9d06Em OlYxYez5Rb/syFzlXUrYt2qx3BAj2ZZDyEPXsAzGS8H30bg1RBWBcOZsc587nDXqCJZ7 L6qnWFPFvlLlnctSNlzp+mgFgsb5b0shL2tZtnGUHZKGw6q1gsJdeOjSDNsv5bzdZNEE 2g26Z8S8BG+6PrzxbVED+msZ3UkPD+RTxP1G7QrObhWdBcYqy0HosqV0afAkQqsmLNzR FQ== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp2130.oracle.com with ESMTP id 2gfbt38raw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 02 Mar 2018 22:12:26 +0000 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 w22MCPCV007465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 2 Mar 2018 22:12:25 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 w22MCPf9005234; Fri, 2 Mar 2018 22:12:25 GMT Received: from [192.168.1.28] (/70.70.142.148) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 02 Mar 2018 14:12:24 -0800 From: Phil Hunt Message-Id: <847751A4-FF04-407E-9B2D-BB733CB9A1A0@oracle.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_6D3EF858-C365-4D46-99F1-E3478364DF02" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Fri, 2 Mar 2018 14:12:22 -0800 In-Reply-To: <49FAC72F-48E7-4B4C-8ACD-1259DADFE8FC@amazon.com> Cc: Mike Jones , Yaron Sheffer , SecEvent To: "Richard Backman, Annabelle" References: <6e8afb70-3e6b-0ea5-7749-442c1c2d4c41@gmail.com> <49FAC72F-48E7-4B4C-8ACD-1259DADFE8FC@amazon.com> X-Mailer: Apple Mail (2.3445.5.20) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8820 signatures=668682 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803020261 Archived-At: Subject: Re: [Id-event] Doc shepherd review X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 02 Mar 2018 22:12:31 -0000 --Apple-Mail=_6D3EF858-C365-4D46-99F1-E3478364DF02 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Annabelle, Apologies, but =E2=80=9Csignificance of this case=E2=80=9D does not seem = to add actionable information or aid in understanding. Also "if any=E2=80=9D= seems unclear. Can you propose something else (with before and after text)? Thanks, Phil Oracle Corporation, Identity Cloud Services Architect @independentid www.independentid.com = phil.hunt@oracle.com = > On Mar 1, 2018, at 11:32 AM, Richard Backman, Annabelle = wrote: >=20 > =E2=80=9C=E2=80=A6whether and how multiple members of the JSON object = that is the value of the events claim are used for SETs conforming to = those profiles.=E2=80=9D > =20 > The =E2=80=9Cwhether and how=E2=80=9D construction condenses this = statement, but I think it makes it harder to understand. How about: > =20 > =E2=80=9C=E2=80=A6whether the value of the events claim may contain = multiple members, and the significance of this case if any for SETs = conforming to those profiles.=E2=80=9D > =20 > --=20 > Annabelle Richard Backman > Amazon =E2=80=93 Identity Services > =20 > From: Id-event > on behalf of Mike Jones = > > Date: Wednesday, February 28, 2018 at 5:16 PM > To: Yaron Sheffer > > Cc: SecEvent >, Phil Hunt = > > Subject: Re: [Id-event] Doc shepherd review > =20 > Yaron, the edits in=C2=A0 = <>https://github.com/independentid/Identity-Events/pull/11/commits/e27a269= 6f707107ec85a994844c6cbe2283356ec = = address your review comments. > =20 > -- = Mike > =20 > From: Id-event > On Behalf Of Mike Jones > Sent: Wednesday, February 28, 2018 3:46 PM > To: Phil Hunt >; = Yaron Sheffer > > Cc: SecEvent > > Subject: Re: [Id-event] Doc shepherd review > =20 > Phil is correct. The =E2=80=9Ctxn=E2=80=9D claim is intentionally = usable with any JWT and not specific to SETs. This just happens to be = the spec to define it and add it to the IANA JWT Claims registry. > =20 > Yaron, I plan to tweak your language =E2=80=9CSETs serve to exchange = information about identity-related events=E2=80=9D because the charter = is about security events, only some of which are identity events. We = shouldn=E2=80=99t narrow the scope of applicability beyond what=E2=80=99s = intended. > =20 > -- = Mike > =20 > From: Id-event > On Behalf Of Phil Hunt > Sent: Wednesday, February 28, 2018 3:35 PM > To: Yaron Sheffer > > Cc: SecEvent > > Subject: Re: [Id-event] Doc shepherd review > =20 > Yaron, > =20 > Thanks for the comments, will add to the next update. > =20 > Mike has added some other minor editorial fixes for consistency with = JWT etc which I believe the group discussed. > =20 > A couple questions inline=E2=80=A6 > =20 > Phil > =20 > Oracle Corporation, Identity Cloud Services Architect > @independentid > www.independentid.com = > phil.hunt@oracle.com > =20 >=20 >> On Feb 28, 2018, at 3:27 PM, Yaron Sheffer > wrote: >> =20 >> Hi, >>=20 >> I will be document shepherd for the SET spec. As such, I just reread = it once again, and I think it is in very good shape. Here are my (mostly = editorial) comments. >>=20 >> - Abstract: please add the following to clarify, e.g. after the first = sentence: SETs serve to exchange information about identity-related = events. >> - A security subject MAY be permanent - this is descriptive text, = please change "MAY" to "may". >> - "SETs have no capability for error signaling to ensure the = validation of a received SET" - SETs are a format, so it is a higher = level protocol that may or may not signal errors. I suggest to remove = this sentence. >> - "has occurred about a Subject." Should this be "has occurred to a = Subject=E2=80=9D? > =20 > I will re-read. I think what the spec is trying to say is to or = related to. Meaning the even is directly related to the subject but not = necessarily to the subject. I will review and suggest some text. > =20 >=20 >> - 2.2: for readability, please include the full names of the claims = ("Issuer", "JWT ID" etc.). >> - IMO the distinction between JWTs and SETs with regard to the need = to use "exp" is not convincing. I suggest we refer to Sec. 4.5 for a = better rationale why we make this claim NOT RECOMMENDED rather than = OPTIONAL as in RFC 7519. >> - txn: this paragraph should speak about SETs rather than JWTs. > =20 > I will defer to Mike, but I believe he suggested to have this = registered for general JWT use.=20 > =20 >=20 >> - "to provide integrity, confidentiality, and issuer validation", = should be "issuer authenticity". >> - "Whether and how multiple "events" values are used": the reader who = has not been following our discussions may not understand what this = means, maybe we should say in parentheses, (i.e. multiple members in the = "events" JSON object). >> - "MUST support TLS 1.2" - add "or a higher version". >> - 4.5: intentionally - I think we mean "maliciously". >> - 6.1.1: "Security Event URI" - this description is incorrect, should = probably be "Security Event information" or something similarly vague. >> - RFC 7617 - unused ref. Similarly saml-core. >>=20 >> Thanks, >> Yaron >>=20 >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwIGaQ&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65ea= pI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DF-QmvDFTApiQ6Wj= ga0U9ssZq_QMLIYG_XiU2g5JO0Ug&s=3DnLwDZhuM4B_ZVxX3dGEafZgxYOCRDGLBAPTA7IJ3Y= Uo&e = =3D >=20 > =20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65ea= pI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3D2HLT4d2twCFYgn2= XHeUK2tHsbk1_pzDH38mvNQNamnQ&s=3DZa82EBppu_mOdrdvDQwJumc9CpxIeunBFdeuGQpSW= 4A&e=3D = --Apple-Mail=_6D3EF858-C365-4D46-99F1-E3478364DF02 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Annabelle,

Apologies, but =E2=80=9Csignificance of this case=E2=80=9D = does not seem to add actionable information or aid in understanding. = Also "if any=E2=80=9D seems unclear.

Can you propose something else (with = before and after text)?

Thanks,

Phil

Oracle Corporation, Identity Cloud = Services Architect
@independentid
www.independentid.com
phil.hunt@oracle.com

On Mar 1, 2018, at 11:32 AM, Richard Backman, Annabelle = <richanna@amazon.com> wrote:

=E2=80=9C=E2=80=A6whether and how multiple members of the = JSON object that is the value of the events claim are used for SETs = conforming to those profiles.=E2=80=9D
 
The =E2=80=9Cwhether and how=E2=80=9D = construction condenses this statement, but I think it makes it harder to = understand. How about:
 
=E2=80=9C=E2=80=A6whether the value of the events claim may = contain multiple members, and the significance of this case if any for = SETs conforming to those profiles.=E2=80=9D
 
-- 
Annabelle Richard Backman
Amazon =E2=80=93 Identity Services
 
From: Id-event <id-event-bounces@ietf.org> = on behalf of Mike Jones <Michael.Jones@microsoft.com>
Date: Wednesday, February 28, = 2018 at 5:16 PM
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Cc: SecEvent <id-event@ietf.org>, Phil = Hunt <phil.hunt@oracle.com>
Subject: Re: [Id-event] Doc = shepherd review
 
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;    -- Mike
 
From: Id-event <id-event-bounces@ietf.org> On Behalf = Of Mike Jones
Sent: Wednesday, February 28, = 2018 3:46 PM
To: Phil Hunt <phil.hunt@oracle.com>; = Yaron Sheffer <yaronf.ietf@gmail.com>
Cc: SecEvent <id-event@ietf.org>
Subject: Re: [Id-event] Doc shepherd = review
 
Phil is correct.  The =E2=80=9Ctxn=E2=80=9D= claim is intentionally usable with any JWT and not specific to SETs. = This just happens to be the spec to define it and add it to the IANA JWT = Claims registry.
 
Yaron, I = plan to tweak your language =E2=80=9CSETs serve to exchange = information about identity-related events=E2=80=9D because the charter is about security = events, only some of which are identity events.  We shouldn=E2=80=99t= narrow the scope of applicability beyond what=E2=80=99s = intended.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;    -- Mike
 
From: Id-event <id-event-bounces@ietf.org> On Behalf = Of Phil Hunt
Sent: Wednesday, February 28, = 2018 3:35 PM
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Cc: SecEvent <id-event@ietf.org>
Subject: Re: [Id-event] Doc shepherd = review
 
Yaron,
 
Thanks for the comments, will add to the = next update.
 
Mike has added some other minor editorial = fixes for consistency with JWT etc which I believe the group = discussed.
 
A couple questions inline=E2=80=A6
 
Phil
 
Oracle = Corporation, Identity Cloud Services Architect
@independentid
phil.hunt@oracle.com

 

On Feb 28, 2018, at = 3:27 PM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
 
Hi,

I will be document shepherd for the SET spec. As such, I just = reread it once again, and I think it is in very good shape. Here are my = (mostly editorial) comments.

- Abstract: = please add the following to clarify, e.g. after the first sentence: SETs = serve to exchange information about identity-related events.
- A security subject MAY be permanent - this is descriptive = text, please change "MAY" to "may".
- "SETs have no = capability for error signaling to ensure the validation of a received = SET" - SETs are a format, so it is a higher level protocol that may or = may not signal errors. I suggest to remove this sentence.
- = "has occurred about a Subject." Should this be "has occurred to a = Subject=E2=80=9D?
 
I will re-read. I think what the spec is = trying to say is to or related to. Meaning the even is directly related = to the subject but not necessarily to the subject.  I will review = and suggest some text.

 

- 2.2: for readability, please include the = full names of the claims ("Issuer", "JWT ID" etc.).
- IMO = the distinction between JWTs and SETs with regard to the need to use = "exp" is not convincing. I suggest we refer to Sec. 4.5 for a better = rationale why we make this claim NOT RECOMMENDED rather than OPTIONAL as = in RFC 7519.
- txn: this paragraph should speak about SETs = rather than JWTs.
 
I will defer to Mike, but I believe he = suggested to have this registered for general JWT use. 

 

- "to = provide integrity, confidentiality, and issuer validation", should be = "issuer authenticity".
- "Whether and how multiple = "events" values are used": the reader who has not been following our = discussions may not understand what this means, maybe we should say in = parentheses, (i.e. multiple members in the "events" JSON object).
- "MUST support TLS 1.2" - add "or a higher version".
- 4.5: intentionally - I think we mean "maliciously".
- 6.1.1: "Security Event URI" - this description is = incorrect, should probably be "Security Event information" or something = similarly vague.
- RFC 7617 - unused ref. Similarly = saml-core.

Thanks,
    Yaron

_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf= .org_mailman_listinfo_id-2Devent&d=3DDwIGaQ&c=3DRoP1YumCXCgaWHvlZY= R8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4K= ZNA&m=3DF-QmvDFTApiQ6Wjga0U9ssZq_QMLIYG_XiU2g5JO0Ug&s=3DnLwDZhuM4B= _ZVxX3dGEafZgxYOCRDGLBAPTA7IJ3YUo&e=3D
 
_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf= .org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZY= R8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4K= ZNA&m=3D2HLT4d2twCFYgn2XHeUK2tHsbk1_pzDH38mvNQNamnQ&s=3DZa82EBppu_= mOdrdvDQwJumc9CpxIeunBFdeuGQpSW4A&e=3D

= --Apple-Mail=_6D3EF858-C365-4D46-99F1-E3478364DF02-- From nobody Fri Mar 2 14:30:19 2018 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 561E8126BF7 for ; Fri, 2 Mar 2018 14:30:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.821 X-Spam-Level: X-Spam-Status: No, score=-9.821 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJo_B-pFLviy for ; Fri, 2 Mar 2018 14:30:14 -0800 (PST) Received: from smtp-fw-33001.amazon.com (smtp-fw-33001.amazon.com [207.171.190.10]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73C9A1250B8 for ; Fri, 2 Mar 2018 14:30:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1520029814; x=1551565814; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=RjCNj3nEi/7JhNw7bcM7T9jLOT/M3NuSmbFwbL6rsE0=; b=aTfAnQVWmc5/m4xIAkZmo0/Ia+Vkxv72uAVNCgqofjExeGckvXoxfw5g BdOJaXewKbRkKV98negz7EimTJabOsKGxPG0YWLCsnWFApGSK8yTpKoVE atayLOnpj5mfjhxLoinzsbdV/IXMJ5QNmiVgXlnkXN2P2O/dXsSknM97Z g=; X-IronPort-AV: E=Sophos;i="5.47,414,1515456000"; d="scan'208,217";a="722509917" Received: from sea3-co-svc-lb6-vlan2.sea.amazon.com (HELO email-inbound-relay-1e-62350142.us-east-1.amazon.com) ([10.47.22.34]) by smtp-border-fw-out-33001.sea14.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Mar 2018 22:30:12 +0000 Received: from EX13MTAUWC001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan2.iad.amazon.com [10.40.159.162]) by email-inbound-relay-1e-62350142.us-east-1.amazon.com (8.14.7/8.14.7) with ESMTP id w22MU0bN130510 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 2 Mar 2018 22:30:10 GMT Received: from EX13D11UWC001.ant.amazon.com (10.43.162.151) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Fri, 2 Mar 2018 22:30:10 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC001.ant.amazon.com (10.43.162.151) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Fri, 2 Mar 2018 22:30:09 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1236.000; Fri, 2 Mar 2018 22:30:09 +0000 From: "Richard Backman, Annabelle" To: Phil Hunt CC: Mike Jones , Yaron Sheffer , SecEvent Thread-Topic: [Id-event] Doc shepherd review Thread-Index: AQHTsOu4GgT2LTCZR0++jnMPeBylqqO6d4+AgAADDoCAABkyAIAArF2AgAJFDwD//37cgA== Date: Fri, 2 Mar 2018 22:30:09 +0000 Message-ID: <3B339ACB-8386-46F9-8795-278442BA4F06@amazon.com> References: <6e8afb70-3e6b-0ea5-7749-442c1c2d4c41@gmail.com> <49FAC72F-48E7-4B4C-8ACD-1259DADFE8FC@amazon.com> <847751A4-FF04-407E-9B2D-BB733CB9A1A0@oracle.com> In-Reply-To: <847751A4-FF04-407E-9B2D-BB733CB9A1A0@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.a.0.180210 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.161.235] Content-Type: multipart/alternative; boundary="_000_3B339ACB838646F98795278442BA4F06amazoncom_" MIME-Version: 1.0 Precedence: Bulk Archived-At: Subject: Re: [Id-event] Doc shepherd review X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 02 Mar 2018 22:30:17 -0000 --_000_3B339ACB838646F98795278442BA4F06amazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SG93IGFib3V0Og0KDQpDaGFuZ2UgdGhpcyBsaW5lPGh0dHBzOi8vZ2l0aHViLmNvbS9pbmRlcGVu ZGVudGlkL0lkZW50aXR5LUV2ZW50cy9wdWxsLzExL2NvbW1pdHMvZTI3YTI2OTZmNzA3MTA3ZWM4 NWE5OTQ4NDRjNmNiZTIyODMzNTZlYyNkaWZmLWRjYjJmNzg2NGVhMTM1OTM2NzIwMDU5MmJmZWMz ZTIxUjczNz4gdG86DQoNCkFtb25nIHRoZSBzeW50YXggYW5kIHNlbWFudGljcyBvZiBTRVRzIHRo YXQgYSBwcm9maWxpbmcgc3BlY2lmaWNhdGlvbiBtYXkgZGVmaW5lIGlzIHdoZXRoZXIgdGhlIHZh bHVlIG9mIHRoZSBldmVudHMgY2xhaW0gbWF5IGNvbnRhaW4gbXVsdGlwbGUgbWVtYmVycywgYW5k IGFueSBhZGRpdGlvbmFsIHByb2Nlc3NpbmcgaW5zdHJ1Y3Rpb25zIHJlcXVpcmVkIHdoZW4gbXVs dGlwbGUgbWVtYmVycyBhcmUgcHJlc2VudCBpbiBTRVRzIGNvbmZvcm1pbmcgdG8gdGhhdCBwcm9m aWxlLg0KDQpJIHRoaW5rIHRoaXMgaXMgYSBjbGVhcmVyLCBtb3JlIHByZWNpc2UgZGVzY3JpcHRp b24gb2Ygd2hhdCBpdCBpcyBwcm9maWxlIGF1dGhvcnMgbmVlZCB0byBjb25zaWRlci4gSXQgYWxz byBmaXRzIGJldHRlciB3aXRoIHRoZSBzdWJzZXF1ZW50IGV4YW1wbGVzLCB3aGljaCBwcmVzZW50 IGRpZmZlcmVudCBydWxlcyBmb3IgcHJvY2Vzc2luZyBtdWx0aS1ldmVudCBTRVRzLg0KDQotLQ0K QW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbg0KQW1hem9uIOKAkyBJZGVudGl0eSBTZXJ2aWNlcw0K DQpGcm9tOiBQaGlsIEh1bnQgPHBoaWwuaHVudEBvcmFjbGUuY29tPg0KRGF0ZTogRnJpZGF5LCBN YXJjaCAyLCAyMDE4IGF0IDI6MTIgUE0NClRvOiAiUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUi IDxyaWNoYW5uYUBhbWF6b24uY29tPg0KQ2M6IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWlj cm9zb2Z0LmNvbT4sIFlhcm9uIFNoZWZmZXIgPHlhcm9uZi5pZXRmQGdtYWlsLmNvbT4sIFNlY0V2 ZW50IDxpZC1ldmVudEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbSWQtZXZlbnRdIERvYyBzaGVw aGVyZCByZXZpZXcNCg0KQW5uYWJlbGxlLA0KDQpBcG9sb2dpZXMsIGJ1dCDigJxzaWduaWZpY2Fu Y2Ugb2YgdGhpcyBjYXNl4oCdIGRvZXMgbm90IHNlZW0gdG8gYWRkIGFjdGlvbmFibGUgaW5mb3Jt YXRpb24gb3IgYWlkIGluIHVuZGVyc3RhbmRpbmcuIEFsc28gImlmIGFueeKAnSBzZWVtcyB1bmNs ZWFyLg0KDQpDYW4geW91IHByb3Bvc2Ugc29tZXRoaW5nIGVsc2UgKHdpdGggYmVmb3JlIGFuZCBh ZnRlciB0ZXh0KT8NCg0KVGhhbmtzLA0KDQpQaGlsDQoNCk9yYWNsZSBDb3Jwb3JhdGlvbiwgSWRl bnRpdHkgQ2xvdWQgU2VydmljZXMgQXJjaGl0ZWN0DQpAaW5kZXBlbmRlbnRpZA0Kd3d3LmluZGVw ZW5kZW50aWQuY29tPGh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20+DQpwaGlsLmh1bnRAb3Jh Y2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+DQoNCg0KT24gTWFyIDEsIDIwMTgs IGF0IDExOjMyIEFNLCBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSA8cmljaGFubmFAYW1hem9u LmNvbTxtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbT4+IHdyb3RlOg0KDQrigJzigKZ3aGV0aGVy IGFuZCBob3cgbXVsdGlwbGUgbWVtYmVycyBvZiB0aGUgSlNPTiBvYmplY3QgdGhhdCBpcyB0aGUg dmFsdWUgb2YgdGhlIGV2ZW50cyBjbGFpbSBhcmUgdXNlZCBmb3IgU0VUcyBjb25mb3JtaW5nIHRv IHRob3NlIHByb2ZpbGVzLuKAnQ0KDQpUaGUg4oCcd2hldGhlciBhbmQgaG934oCdIGNvbnN0cnVj dGlvbiBjb25kZW5zZXMgdGhpcyBzdGF0ZW1lbnQsIGJ1dCBJIHRoaW5rIGl0IG1ha2VzIGl0IGhh cmRlciB0byB1bmRlcnN0YW5kLiBIb3cgYWJvdXQ6DQoNCuKAnOKApndoZXRoZXIgdGhlIHZhbHVl IG9mIHRoZSBldmVudHMgY2xhaW0gbWF5IGNvbnRhaW4gbXVsdGlwbGUgbWVtYmVycywgYW5kIHRo ZSBzaWduaWZpY2FuY2Ugb2YgdGhpcyBjYXNlIGlmIGFueSBmb3IgU0VUcyBjb25mb3JtaW5nIHRv IHRob3NlIHByb2ZpbGVzLuKAnQ0KDQotLQ0KQW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbg0KQW1h em9uIOKAkyBJZGVudGl0eSBTZXJ2aWNlcw0KDQpGcm9tOiBJZC1ldmVudCA8aWQtZXZlbnQtYm91 bmNlc0BpZXRmLm9yZzxtYWlsdG86aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFs ZiBvZiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hh ZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+DQpEYXRlOiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDI4LCAy MDE4IGF0IDU6MTYgUE0NClRvOiBZYXJvbiBTaGVmZmVyIDx5YXJvbmYuaWV0ZkBnbWFpbC5jb208 bWFpbHRvOnlhcm9uZi5pZXRmQGdtYWlsLmNvbT4+DQpDYzogU2VjRXZlbnQgPGlkLWV2ZW50QGll dGYub3JnPG1haWx0bzppZC1ldmVudEBpZXRmLm9yZz4+LCBQaGlsIEh1bnQgPHBoaWwuaHVudEBv cmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+DQpTdWJqZWN0OiBSZTogW0lk LWV2ZW50XSBEb2Mgc2hlcGhlcmQgcmV2aWV3DQoNCllhcm9uLCB0aGUgZWRpdHMgaW4gaHR0cHM6 Ly9naXRodWIuY29tL2luZGVwZW5kZW50aWQvSWRlbnRpdHktRXZlbnRzL3B1bGwvMTEvY29tbWl0 cy9lMjdhMjY5NmY3MDcxMDdlYzg1YTk5NDg0NGM2Y2JlMjI4MzM1NmVjPGh0dHBzOi8vdXJsZGVm ZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZ2l0aHViLmNvbV9pbmRlcGVu ZGVudGlkX0lkZW50aXR5LTJERXZlbnRzX3B1bGxfMTFfY29tbWl0c19lMjdhMjY5NmY3MDcxMDdl Yzg1YTk5NDg0NGM2Y2JlMjI4MzM1NmVjJmQ9RHdNR2FRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQ Wmg4QnY3cUlyTVVCNjVlYXBJX0puRSZyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJ MWFMY0xONEtaTkEmbT0ySExUNGQydHdDRllnbjJYSGVVSzJ0SHNiazFfcHpESDM4bXZOUU5hbW5R JnM9Z3g3OFFZTV80Wlk5NU1BbDlkNmJRc3IyNzVpb1llZDcwN2FvR2I3d0dkYyZlPT4gYWRkcmVz cyB5b3VyIHJldmlldyBjb21tZW50cy4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogSWQtZXZl bnQgPGlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmlkLWV2ZW50LWJvdW5jZXNAaWV0 Zi5vcmc+PiBPbiBCZWhhbGYgT2YgTWlrZSBKb25lcw0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFy eSAyOCwgMjAxOCAzOjQ2IFBNDQpUbzogUGhpbCBIdW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxt YWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+PjsgWWFyb24gU2hlZmZlciA8eWFyb25mLmlldGZA Z21haWwuY29tPG1haWx0bzp5YXJvbmYuaWV0ZkBnbWFpbC5jb20+Pg0KQ2M6IFNlY0V2ZW50IDxp ZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86aWQtZXZlbnRAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6 IFtJZC1ldmVudF0gRG9jIHNoZXBoZXJkIHJldmlldw0KDQpQaGlsIGlzIGNvcnJlY3QuICBUaGUg 4oCcdHhu4oCdIGNsYWltIGlzIGludGVudGlvbmFsbHkgdXNhYmxlIHdpdGggYW55IEpXVCBhbmQg bm90IHNwZWNpZmljIHRvIFNFVHMuIFRoaXMganVzdCBoYXBwZW5zIHRvIGJlIHRoZSBzcGVjIHRv IGRlZmluZSBpdCBhbmQgYWRkIGl0IHRvIHRoZSBJQU5BIEpXVCBDbGFpbXMgcmVnaXN0cnkuDQoN Cllhcm9uLCBJIHBsYW4gdG8gdHdlYWsgeW91ciBsYW5ndWFnZSDigJxTRVRzIHNlcnZlIHRvIGV4 Y2hhbmdlIGluZm9ybWF0aW9uIGFib3V0IGlkZW50aXR5LXJlbGF0ZWQgZXZlbnRz4oCdIGJlY2F1 c2UgdGhlIGNoYXJ0ZXIgaXMgYWJvdXQgc2VjdXJpdHkgZXZlbnRzLCBvbmx5IHNvbWUgb2Ygd2hp Y2ggYXJlIGlkZW50aXR5IGV2ZW50cy4gIFdlIHNob3VsZG7igJl0IG5hcnJvdyB0aGUgc2NvcGUg b2YgYXBwbGljYWJpbGl0eSBiZXlvbmQgd2hhdOKAmXMgaW50ZW5kZWQuDQoNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBN aWtlDQoNCkZyb206IElkLWV2ZW50IDxpZC1ldmVudC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpp ZC1ldmVudC1ib3VuY2VzQGlldGYub3JnPj4gT24gQmVoYWxmIE9mIFBoaWwgSHVudA0KU2VudDog V2VkbmVzZGF5LCBGZWJydWFyeSAyOCwgMjAxOCAzOjM1IFBNDQpUbzogWWFyb24gU2hlZmZlciA8 eWFyb25mLmlldGZAZ21haWwuY29tPG1haWx0bzp5YXJvbmYuaWV0ZkBnbWFpbC5jb20+Pg0KQ2M6 IFNlY0V2ZW50IDxpZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86aWQtZXZlbnRAaWV0Zi5vcmc+Pg0K U3ViamVjdDogUmU6IFtJZC1ldmVudF0gRG9jIHNoZXBoZXJkIHJldmlldw0KDQpZYXJvbiwNCg0K VGhhbmtzIGZvciB0aGUgY29tbWVudHMsIHdpbGwgYWRkIHRvIHRoZSBuZXh0IHVwZGF0ZS4NCg0K TWlrZSBoYXMgYWRkZWQgc29tZSBvdGhlciBtaW5vciBlZGl0b3JpYWwgZml4ZXMgZm9yIGNvbnNp c3RlbmN5IHdpdGggSldUIGV0YyB3aGljaCBJIGJlbGlldmUgdGhlIGdyb3VwIGRpc2N1c3NlZC4N Cg0KQSBjb3VwbGUgcXVlc3Rpb25zIGlubGluZeKApg0KDQpQaGlsDQoNCk9yYWNsZSBDb3Jwb3Jh dGlvbiwgSWRlbnRpdHkgQ2xvdWQgU2VydmljZXMgQXJjaGl0ZWN0DQpAaW5kZXBlbmRlbnRpZA0K d3d3LmluZGVwZW5kZW50aWQuY29tPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92 Mi91cmw/dT1odHRwLTNBX193d3cuaW5kZXBlbmRlbnRpZC5jb20mZD1Ed01HYVEmYz1Sb1AxWXVt Q1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJnI9bmE1RlZ6QlRXbWFucVdOeTRE cGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZtPTJITFQ0ZDJ0d0NGWWduMlhIZVVLMnRIc2JrMV9w ekRIMzhtdk5RTmFtblEmcz1TRk1xTHZTd21YLU1YMHI4UWFuajBrMmpZVlByd0JTU1VzSmh4MDNL eVBVJmU9Pg0KcGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29t Pg0KDQpPbiBGZWIgMjgsIDIwMTgsIGF0IDM6MjcgUE0sIFlhcm9uIFNoZWZmZXIgPHlhcm9uZi5p ZXRmQGdtYWlsLmNvbTxtYWlsdG86eWFyb25mLmlldGZAZ21haWwuY29tPj4gd3JvdGU6DQoNCkhp LA0KDQpJIHdpbGwgYmUgZG9jdW1lbnQgc2hlcGhlcmQgZm9yIHRoZSBTRVQgc3BlYy4gQXMgc3Vj aCwgSSBqdXN0IHJlcmVhZCBpdCBvbmNlIGFnYWluLCBhbmQgSSB0aGluayBpdCBpcyBpbiB2ZXJ5 IGdvb2Qgc2hhcGUuIEhlcmUgYXJlIG15IChtb3N0bHkgZWRpdG9yaWFsKSBjb21tZW50cy4NCg0K LSBBYnN0cmFjdDogcGxlYXNlIGFkZCB0aGUgZm9sbG93aW5nIHRvIGNsYXJpZnksIGUuZy4gYWZ0 ZXIgdGhlIGZpcnN0IHNlbnRlbmNlOiBTRVRzIHNlcnZlIHRvIGV4Y2hhbmdlIGluZm9ybWF0aW9u IGFib3V0IGlkZW50aXR5LXJlbGF0ZWQgZXZlbnRzLg0KLSBBIHNlY3VyaXR5IHN1YmplY3QgTUFZ IGJlIHBlcm1hbmVudCAtIHRoaXMgaXMgZGVzY3JpcHRpdmUgdGV4dCwgcGxlYXNlIGNoYW5nZSAi TUFZIiB0byAibWF5Ii4NCi0gIlNFVHMgaGF2ZSBubyBjYXBhYmlsaXR5IGZvciBlcnJvciBzaWdu YWxpbmcgdG8gZW5zdXJlIHRoZSB2YWxpZGF0aW9uIG9mIGEgcmVjZWl2ZWQgU0VUIiAtIFNFVHMg YXJlIGEgZm9ybWF0LCBzbyBpdCBpcyBhIGhpZ2hlciBsZXZlbCBwcm90b2NvbCB0aGF0IG1heSBv ciBtYXkgbm90IHNpZ25hbCBlcnJvcnMuIEkgc3VnZ2VzdCB0byByZW1vdmUgdGhpcyBzZW50ZW5j ZS4NCi0gImhhcyBvY2N1cnJlZCBhYm91dCBhIFN1YmplY3QuIiBTaG91bGQgdGhpcyBiZSAiaGFz IG9jY3VycmVkIHRvIGEgU3ViamVjdOKAnT8NCg0KSSB3aWxsIHJlLXJlYWQuIEkgdGhpbmsgd2hh dCB0aGUgc3BlYyBpcyB0cnlpbmcgdG8gc2F5IGlzIHRvIG9yIHJlbGF0ZWQgdG8uIE1lYW5pbmcg dGhlIGV2ZW4gaXMgZGlyZWN0bHkgcmVsYXRlZCB0byB0aGUgc3ViamVjdCBidXQgbm90IG5lY2Vz c2FyaWx5IHRvIHRoZSBzdWJqZWN0LiAgSSB3aWxsIHJldmlldyBhbmQgc3VnZ2VzdCBzb21lIHRl eHQuDQoNCi0gMi4yOiBmb3IgcmVhZGFiaWxpdHksIHBsZWFzZSBpbmNsdWRlIHRoZSBmdWxsIG5h bWVzIG9mIHRoZSBjbGFpbXMgKCJJc3N1ZXIiLCAiSldUIElEIiBldGMuKS4NCi0gSU1PIHRoZSBk aXN0aW5jdGlvbiBiZXR3ZWVuIEpXVHMgYW5kIFNFVHMgd2l0aCByZWdhcmQgdG8gdGhlIG5lZWQg dG8gdXNlICJleHAiIGlzIG5vdCBjb252aW5jaW5nLiBJIHN1Z2dlc3Qgd2UgcmVmZXIgdG8gU2Vj LiA0LjUgZm9yIGEgYmV0dGVyIHJhdGlvbmFsZSB3aHkgd2UgbWFrZSB0aGlzIGNsYWltIE5PVCBS RUNPTU1FTkRFRCByYXRoZXIgdGhhbiBPUFRJT05BTCBhcyBpbiBSRkMgNzUxOS4NCi0gdHhuOiB0 aGlzIHBhcmFncmFwaCBzaG91bGQgc3BlYWsgYWJvdXQgU0VUcyByYXRoZXIgdGhhbiBKV1RzLg0K DQpJIHdpbGwgZGVmZXIgdG8gTWlrZSwgYnV0IEkgYmVsaWV2ZSBoZSBzdWdnZXN0ZWQgdG8gaGF2 ZSB0aGlzIHJlZ2lzdGVyZWQgZm9yIGdlbmVyYWwgSldUIHVzZS4NCg0KLSAidG8gcHJvdmlkZSBp bnRlZ3JpdHksIGNvbmZpZGVudGlhbGl0eSwgYW5kIGlzc3VlciB2YWxpZGF0aW9uIiwgc2hvdWxk IGJlICJpc3N1ZXIgYXV0aGVudGljaXR5Ii4NCi0gIldoZXRoZXIgYW5kIGhvdyBtdWx0aXBsZSAi ZXZlbnRzIiB2YWx1ZXMgYXJlIHVzZWQiOiB0aGUgcmVhZGVyIHdobyBoYXMgbm90IGJlZW4gZm9s bG93aW5nIG91ciBkaXNjdXNzaW9ucyBtYXkgbm90IHVuZGVyc3RhbmQgd2hhdCB0aGlzIG1lYW5z LCBtYXliZSB3ZSBzaG91bGQgc2F5IGluIHBhcmVudGhlc2VzLCAoaS5lLiBtdWx0aXBsZSBtZW1i ZXJzIGluIHRoZSAiZXZlbnRzIiBKU09OIG9iamVjdCkuDQotICJNVVNUIHN1cHBvcnQgVExTIDEu MiIgLSBhZGQgIm9yIGEgaGlnaGVyIHZlcnNpb24iLg0KLSA0LjU6IGludGVudGlvbmFsbHkgLSBJ IHRoaW5rIHdlIG1lYW4gIm1hbGljaW91c2x5Ii4NCi0gNi4xLjE6ICJTZWN1cml0eSBFdmVudCBV UkkiIC0gdGhpcyBkZXNjcmlwdGlvbiBpcyBpbmNvcnJlY3QsIHNob3VsZCBwcm9iYWJseSBiZSAi U2VjdXJpdHkgRXZlbnQgaW5mb3JtYXRpb24iIG9yIHNvbWV0aGluZyBzaW1pbGFybHkgdmFndWUu DQotIFJGQyA3NjE3IC0gdW51c2VkIHJlZi4gU2ltaWxhcmx5IHNhbWwtY29yZS4NCg0KVGhhbmtz LA0KICAgIFlhcm9uDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpJZC1ldmVudCBtYWlsaW5nIGxpc3QNCklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJ ZC1ldmVudEBpZXRmLm9yZz4NCmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91 cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZk PUR3SUdhUSZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmcj1u YTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJm09Ri1RbXZERlRBcGlR NldqZ2EwVTlzc1pxX1FNTElZR19YaVUyZzVKTzBVZyZzPW5Md0RaaHVNNEJfWlZ4WDNkR0VhZlpn eFlPQ1JER0xCQVBUQTdJSjNZVW8mZT0NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCklkLWV2ZW50IG1haWxpbmcgbGlzdA0KSWQtZXZlbnRAaWV0Zi5v cmc8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPg0KaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9p bnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19p ZC0yRGV2ZW50JmQ9RHdJQ0FnJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVl YXBJX0puRSZyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmbT0y SExUNGQydHdDRllnbjJYSGVVSzJ0SHNiazFfcHpESDM4bXZOUU5hbW5RJnM9WmE4MkVCcHB1X21P ZHJkdkRRd0p1bWM5Q3B4SWV1bkJGZGV1R1FwU1c0QSZlPQ0KDQo= --_000_3B339ACB838646F98795278442BA4F06amazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXtt c28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFy Z2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVm dDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjt9DQpzcGFuLmFwcGxlLXN0eWxlLXNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtc3R5 bGUtc3Bhbjt9DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTph cHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ Y29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhvdyBhYm91dDo8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Q2hhbmdlIDxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9pbmRl cGVuZGVudGlkL0lkZW50aXR5LUV2ZW50cy9wdWxsLzExL2NvbW1pdHMvZTI3YTI2OTZmNzA3MTA3 ZWM4NWE5OTQ4NDRjNmNiZTIyODMzNTZlYyNkaWZmLWRjYjJmNzg2NGVhMTM1OTM2NzIwMDU5MmJm ZWMzZTIxUjczNyI+DQp0aGlzIGxpbmU8L2E+IHRvOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+QW1vbmcgdGhlIHN5bnRheCBhbmQgc2VtYW50aWNzIG9m IFNFVHMgdGhhdA0KPGI+YSBwcm9maWxpbmcgc3BlY2lmaWNhdGlvbiBtYXk8L2I+IGRlZmluZSBp cyB3aGV0aGVyIDxiPnRoZSB2YWx1ZSBvZiB0aGUgZXZlbnRzIGNsYWltIG1heSBjb250YWluIG11 bHRpcGxlIG1lbWJlcnMsIGFuZCBhbnkgYWRkaXRpb25hbCBwcm9jZXNzaW5nIGluc3RydWN0aW9u cyByZXF1aXJlZCB3aGVuIG11bHRpcGxlIG1lbWJlcnMgYXJlIHByZXNlbnQgaW48L2I+IFNFVHMg Y29uZm9ybWluZyB0bw0KPGI+dGhhdCBwcm9maWxlPC9iPi48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SSB0aGluayB0aGlzIGlzIGEgY2xlYXJlciwgbW9yZSBwcmVjaXNlIGRlc2NyaXB0aW9uIG9m IHdoYXQgaXQgaXMgcHJvZmlsZSBhdXRob3JzIG5lZWQgdG8gY29uc2lkZXIuIEl0IGFsc28gZml0 cyBiZXR0ZXIgd2l0aCB0aGUgc3Vic2VxdWVudCBleGFtcGxlcywgd2hpY2ggcHJlc2VudCBkaWZm ZXJlbnQgcnVsZXMgZm9yIHByb2Nlc3NpbmcgbXVsdGktZXZlbnQgU0VUcy48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+LS0mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPkFu bmFiZWxsZSBSaWNoYXJkIEJhY2ttYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPkFtYXpvbiDigJMgSWRlbnRpdHkgU2Vydmlj ZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2si PkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6Ymxh Y2siPlBoaWwgSHVudCAmbHQ7cGhpbC5odW50QG9yYWNsZS5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTog PC9iPkZyaWRheSwgTWFyY2ggMiwgMjAxOCBhdCAyOjEyIFBNPGJyPg0KPGI+VG86IDwvYj4mcXVv dDtSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSZxdW90OyAmbHQ7cmljaGFubmFAYW1hem9uLmNv bSZndDs8YnI+DQo8Yj5DYzogPC9iPk1pa2UgSm9uZXMgJmx0O01pY2hhZWwuSm9uZXNAbWljcm9z b2Z0LmNvbSZndDssIFlhcm9uIFNoZWZmZXIgJmx0O3lhcm9uZi5pZXRmQGdtYWlsLmNvbSZndDss IFNlY0V2ZW50ICZsdDtpZC1ldmVudEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+ UmU6IFtJZC1ldmVudF0gRG9jIHNoZXBoZXJkIHJldmlldzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Bbm5hYmVsbGUsIDxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXBvbG9naWVzLCBidXQg4oCcc2lnbmlm aWNhbmNlIG9mIHRoaXMgY2FzZeKAnSBkb2VzIG5vdCBzZWVtIHRvIGFkZCBhY3Rpb25hYmxlIGlu Zm9ybWF0aW9uIG9yIGFpZCBpbiB1bmRlcnN0YW5kaW5nLiBBbHNvICZxdW90O2lmIGFueeKAnSBz ZWVtcyB1bmNsZWFyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5DYW4geW91IHByb3Bvc2Ugc29tZXRoaW5nIGVsc2UgKHdpdGggYmVmb3JlIGFu ZCBhZnRlciB0ZXh0KT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlBoaWw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+T3JhY2xl IENvcnBvcmF0aW9uLCBJZGVudGl0eSBDbG91ZCBTZXJ2aWNlcyBBcmNoaXRlY3Q8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPkBpbmRlcGVuZGVudGlkPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj48YSBocmVmPSJodHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29tIj53d3cuaW5kZXBlbmRl bnRpZC5jb208L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PjxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSI+cGhpbC5odW50QG9yYWNsZS5j b208L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk9uIE1hciAxLCAyMDE4LCBhdCAxMTozMiBBTSwgUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUg Jmx0OzxhIGhyZWY9Im1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tIj5yaWNoYW5uYUBhbWF6b24u Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj7igJzigKZ3aGV0aGVyIGFuZCBob3cgbXVsdGlwbGUgbWVtYmVycyBvZiB0aGUgSlNP TiBvYmplY3QgdGhhdCBpcyB0aGUgdmFsdWUgb2YgdGhlIGV2ZW50cyBjbGFpbSBhcmUgdXNlZCBm b3IgU0VUcyBjb25mb3JtaW5nIHRvIHRob3NlIHByb2ZpbGVzLuKAnTxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUg4oCcd2hldGhlciBhbmQg aG934oCdIGNvbnN0cnVjdGlvbiBjb25kZW5zZXMgdGhpcyBzdGF0ZW1lbnQsIGJ1dCBJIHRoaW5r IGl0IG1ha2VzIGl0IGhhcmRlciB0byB1bmRlcnN0YW5kLiBIb3cgYWJvdXQ6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPuKAnOKApndoZXRoZXIg dGhlIHZhbHVlIG9mIHRoZSBldmVudHMgY2xhaW0gbWF5IGNvbnRhaW4gbXVsdGlwbGUgbWVtYmVy cywgYW5kIHRoZSBzaWduaWZpY2FuY2Ugb2YgdGhpcyBjYXNlIGlmIGFueSBmb3IgU0VUcyBjb25m b3JtaW5nIHRvIHRob3NlIHByb2ZpbGVzLuKAnTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4tLSZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+QW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyxzZXJpZiI+QW1hem9uIOKAkyBJZGVudGl0eSBTZXJ2aWNlczwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdCI+RnJvbTo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+SWQtZXZlbnQgJmx0 OzxhIGhyZWY9Im1haWx0bzppZC1ldmVudC1ib3VuY2VzQGlldGYub3JnIj48c3BhbiBzdHlsZT0i Y29sb3I6cHVycGxlIj5pZC1ldmVudC1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7DQog b24gYmVoYWxmIG9mIE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVz QG1pY3Jvc29mdC5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPk1pY2hhZWwuSm9uZXNA bWljcm9zb2Z0LmNvbTwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxiPkRhdGU6PHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5XZWRuZXNkYXksIEZlYnJ1YXJ5 IDI4LCAyMDE4IGF0IDU6MTYgUE08YnI+DQo8Yj5Ubzo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPllhcm9uIFNoZWZmZXIgJmx0OzxhIGhyZWY9Im1h aWx0bzp5YXJvbmYuaWV0ZkBnbWFpbC5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnlh cm9uZi5pZXRmQGdtYWlsLmNvbTwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxiPkNjOjxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+U2VjRXZlbnQgJmx0Ozxh IGhyZWY9Im1haWx0bzppZC1ldmVudEBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBs ZSI+aWQtZXZlbnRAaWV0Zi5vcmc8L3NwYW4+PC9hPiZndDssIFBoaWwgSHVudCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxl Ij5waGlsLmh1bnRAb3JhY2xlLmNvbTwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5SZTogW0lk LWV2ZW50XSBEb2Mgc2hlcGhlcmQgcmV2aWV3PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxh IG5hbWU9Il9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+WWFy b24sIHRoZSBlZGl0cyBpbjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5h bEJvZHkiPjwvc3Bhbj48YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20v djIvdXJsP3U9aHR0cHMtM0FfX2dpdGh1Yi5jb21faW5kZXBlbmRlbnRpZF9JZGVudGl0eS0yREV2 ZW50c19wdWxsXzExX2NvbW1pdHNfZTI3YTI2OTZmNzA3MTA3ZWM4NWE5OTQ4NDRjNmNiZTIyODMz NTZlYyZhbXA7ZD1Ed01HYVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVC NjVlYXBJX0puRSZhbXA7cj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRL Wk5BJmFtcDttPTJITFQ0ZDJ0d0NGWWduMlhIZVVLMnRIc2JrMV9wekRIMzhtdk5RTmFtblEmYW1w O3M9Z3g3OFFZTV80Wlk5NU1BbDlkNmJRc3IyNzVpb1llZDcwN2FvR2I3d0dkYyZhbXA7ZT0iPjxz cGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJj b2xvcjpwdXJwbGUiPmh0dHBzOi8vZ2l0aHViLmNvbS9pbmRlcGVuZGVudGlkL0lkZW50aXR5LUV2 ZW50cy9wdWxsLzExL2NvbW1pdHMvZTI3YTI2OTZmNzA3MTA3ZWM4NWE5OTQ4NDRjNmNiZTIyODMz NTZlYzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFs Qm9keSI+PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxC b2R5Ij48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iY29s b3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1i b29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPmFk ZHJlc3MNCiB5b3VyIHJldmlldyBjb21tZW50cy48L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJt c28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21h cms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8 L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHki PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg LS0gTWlrZTwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdp bmFsQm9keSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5 bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJv ZHkiPjxiPkZyb206PC9iPjwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3Jp Z2luYWxCb2R5Ij48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPklk LWV2ZW50ICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5v cmciPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0 eWxlPSJjb2xvcjpwdXJwbGUiPmlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9zcGFu PjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjwvc3Bhbj48L2E+ PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jmd0OzxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48Yj5Pbg0KIEJlaGFsZiBP ZjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+TWlr ZSBKb25lczxicj4NCjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj5XZWRuZXNkYXksIEZlYnJ1YXJ5IDI4LCAyMDE4IDM6NDYgUE08YnI+ DQo8Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPlBoaWwgSHVudCAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xl LmNvbSI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4g c3R5bGU9ImNvbG9yOnB1cnBsZSI+cGhpbC5odW50QG9yYWNsZS5jb208L3NwYW4+PC9zcGFuPjxz cGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjwvc3Bhbj48L2E+PHNw YW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jmd0OzsNCiBZYXJvbiBT aGVmZmVyICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnlhcm9uZi5pZXRmQGdtYWlsLmNvbSI+ PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9 ImNvbG9yOnB1cnBsZSI+eWFyb25mLmlldGZAZ21haWwuY29tPC9zcGFuPjwvc3Bhbj48c3BhbiBz dHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48L3NwYW4+PC9hPjxzcGFuIHN0 eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZndDs8YnI+DQo8Yj5DYzo8L2I+ PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlNlY0V2ZW50 ICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmlkLWV2ZW50QGlldGYub3JnIj48c3BhbiBzdHls ZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVy cGxlIj5pZC1ldmVudEBpZXRmLm9yZzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29r bWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJvb2tt YXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+PHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBbSWQtZXZlbnRdIERv YyBzaGVwaGVyZCByZXZpZXc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29r bWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFy azpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPlBoaWwgaXMg Y29ycmVjdC4mbmJzcDsgVGhlIOKAnHR4buKAnSBjbGFpbSBpcyBpbnRlbnRpb25hbGx5IHVzYWJs ZSB3aXRoIGFueSBKV1QgYW5kIG5vdCBzcGVjaWZpYyB0byBTRVRzLiBUaGlzIGp1c3QgaGFwcGVu cyB0byBiZSB0aGUgc3BlYyB0byBkZWZpbmUgaXQgYW5kIGFkZCBpdCB0byB0aGUgSUFOQQ0KIEpX VCBDbGFpbXMgcmVnaXN0cnkuPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJr Ol9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3Jp Z2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjwvc3Bh bj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iY29sb3I6 IzAwMjA2MCI+WWFyb24sIEkgcGxhbiB0byB0d2VhayB5b3VyIGxhbmd1YWdlIOKAnDwvc3Bhbj48 L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+U0VUcyBz ZXJ2ZSB0byBleGNoYW5nZSBpbmZvcm1hdGlvbiBhYm91dCBpZGVudGl0eS1yZWxhdGVkIGV2ZW50 czxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj7igJ0NCiBiZWNhdXNlIHRoZSBjaGFydGVyIGlz IGFib3V0IHNlY3VyaXR5IGV2ZW50cywgb25seSBzb21lIG9mIHdoaWNoIGFyZSBpZGVudGl0eSBl dmVudHMuJm5ic3A7IFdlIHNob3VsZG7igJl0IG5hcnJvdyB0aGUgc2NvcGUgb2YgYXBwbGljYWJp bGl0eSBiZXlvbmQgd2hhdOKAmXMgaW50ZW5kZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28t Ym9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4m bmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5h bEJvZHkiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxz cGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgLS0gTWlrZTwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFp bE9yaWdpbmFsQm9keSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFs Qm9keSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNw YW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmln aW5hbEJvZHkiPjxiPkZyb206PC9iPjwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9N YWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJv ZHkiPklkLWV2ZW50ICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmlkLWV2ZW50LWJvdW5jZXNA aWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxz cGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+ PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjwvc3Bh bj48L2E+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jmd0Ozxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48Yj5Pbg0KIEJl aGFsZiBPZjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 L2I+UGhpbCBIdW50PGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPldlZG5lc2RheSwgRmVicnVhcnkgMjgsIDIwMTggMzozNSBQ TTxicj4NCjxiPlRvOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+WWFyb24gU2hlZmZlciAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzp5YXJvbmYu aWV0ZkBnbWFpbC5jb20iPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJv ZHkiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnlhcm9uZi5pZXRmQGdtYWlsLmNvbTwvc3Bh bj48L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PC9z cGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mZ3Q7 PGJyPg0KPGI+Q2M6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj5TZWNFdmVudCAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzppZC1ldmVudEBpZXRm Lm9yZyI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4g c3R5bGU9ImNvbG9yOnB1cnBsZSI+aWQtZXZlbnRAaWV0Zi5vcmc8L3NwYW4+PC9zcGFuPjxzcGFu IHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjwvc3Bhbj48L2E+PHNwYW4g c3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jmd0Ozxicj4NCjxiPlN1Ympl Y3Q6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5S ZTogW0lkLWV2ZW50XSBEb2Mgc2hlcGhlcmQgcmV2aWV3PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPllhcm9uLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5UaGFu a3MgZm9yIHRoZSBjb21tZW50cywgd2lsbCBhZGQgdG8gdGhlIG5leHQgdXBkYXRlLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmln aW5hbEJvZHkiPk1pa2UgaGFzIGFkZGVkIHNvbWUgb3RoZXIgbWlub3IgZWRpdG9yaWFsIGZpeGVz IGZvciBjb25zaXN0ZW5jeSB3aXRoIEpXVCBldGMgd2hpY2ggSSBiZWxpZXZlIHRoZSBncm91cCBk aXNjdXNzZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFp bE9yaWdpbmFsQm9keSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1i b29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+QSBjb3VwbGUgcXVlc3Rpb25zIGlubGluZeKApjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJv ZHkiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28t Ym9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPlBoaWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5PcmFjbGUg Q29ycG9yYXRpb24sIElkZW50aXR5IENsb3VkIFNlcnZpY2VzIEFyY2hpdGVjdDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPkBpbmRl cGVuZGVudGlkPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFp bE9yaWdpbmFsQm9keSI+PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBv aW50LmNvbS92Mi91cmw/dT1odHRwLTNBX193d3cuaW5kZXBlbmRlbnRpZC5jb20mYW1wO2Q9RHdN R2FRJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmYW1w O3I9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZhbXA7bT0ySExU NGQydHdDRllnbjJYSGVVSzJ0SHNiazFfcHpESDM4bXZOUU5hbW5RJmFtcDtzPVNGTXFMdlN3bVgt TVgwcjhRYW5qMGsyallWUHJ3QlNTVXNKaHgwM0t5UFUmYW1wO2U9Ij48c3BhbiBzdHlsZT0ibXNv LWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj53 d3cuaW5kZXBlbmRlbnRpZC5jb208L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21h cms6X01haWxPcmlnaW5hbEJvZHkiPjwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFy azpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48L3NwYW4+PGEgaHJl Zj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJr Ol9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5waGlsLmh1bnRA b3JhY2xlLmNvbTwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9y aWdpbmFsQm9keSI+PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3Jp Z2luYWxCb2R5Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0ibXNv LWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1i b29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+T24gRmViIDI4LCAyMDE4LCBhdCAzOjI3IFBNLCBZ YXJvbiBTaGVmZmVyICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnlhcm9uZi5pZXRmQGdtYWls LmNvbSI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4g c3R5bGU9ImNvbG9yOnB1cnBsZSI+eWFyb25mLmlldGZAZ21haWwuY29tPC9zcGFuPjwvc3Bhbj48 c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48L3NwYW4+PC9hPjxz cGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZndDsNCiB3cm90ZTo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdp bmFsQm9keSI+SGksPGJyPg0KPGJyPg0KSSB3aWxsIGJlIGRvY3VtZW50IHNoZXBoZXJkIGZvciB0 aGUgU0VUIHNwZWMuIEFzIHN1Y2gsIEkganVzdCByZXJlYWQgaXQgb25jZSBhZ2FpbiwgYW5kIEkg dGhpbmsgaXQgaXMgaW4gdmVyeSBnb29kIHNoYXBlLiBIZXJlIGFyZSBteSAobW9zdGx5IGVkaXRv cmlhbCkgY29tbWVudHMuPGJyPg0KPGJyPg0KLSBBYnN0cmFjdDogcGxlYXNlIGFkZCB0aGUgZm9s bG93aW5nIHRvIGNsYXJpZnksIGUuZy4gYWZ0ZXIgdGhlIGZpcnN0IHNlbnRlbmNlOiBTRVRzIHNl cnZlIHRvIGV4Y2hhbmdlIGluZm9ybWF0aW9uIGFib3V0IGlkZW50aXR5LXJlbGF0ZWQgZXZlbnRz Ljxicj4NCi0gQSBzZWN1cml0eSBzdWJqZWN0IE1BWSBiZSBwZXJtYW5lbnQgLSB0aGlzIGlzIGRl c2NyaXB0aXZlIHRleHQsIHBsZWFzZSBjaGFuZ2UgJnF1b3Q7TUFZJnF1b3Q7IHRvICZxdW90O21h eSZxdW90Oy48YnI+DQotICZxdW90O1NFVHMgaGF2ZSBubyBjYXBhYmlsaXR5IGZvciBlcnJvciBz aWduYWxpbmcgdG8gZW5zdXJlIHRoZSB2YWxpZGF0aW9uIG9mIGEgcmVjZWl2ZWQgU0VUJnF1b3Q7 IC0gU0VUcyBhcmUgYSBmb3JtYXQsIHNvIGl0IGlzIGEgaGlnaGVyIGxldmVsIHByb3RvY29sIHRo YXQgbWF5IG9yIG1heSBub3Qgc2lnbmFsIGVycm9ycy4gSSBzdWdnZXN0IHRvIHJlbW92ZSB0aGlz IHNlbnRlbmNlLjxicj4NCi0gJnF1b3Q7aGFzIG9jY3VycmVkIGFib3V0IGEgU3ViamVjdC4mcXVv dDsgU2hvdWxkIHRoaXMgYmUgJnF1b3Q7aGFzIG9jY3VycmVkIHRvIGEgU3ViamVjdOKAnT88bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9v a21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1z by1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+SSB3aWxsIHJlLXJlYWQuIEkgdGhpbmsgd2hh dCB0aGUgc3BlYyBpcyB0cnlpbmcgdG8gc2F5IGlzIHRvIG9yIHJlbGF0ZWQgdG8uIE1lYW5pbmcg dGhlIGV2ZW4gaXMgZGlyZWN0bHkgcmVsYXRlZCB0byB0aGUgc3ViamVjdCBidXQgbm90IG5lY2Vz c2FyaWx5IHRvIHRoZSBzdWJqZWN0LiAmbmJzcDtJIHdpbGwgcmV2aWV3IGFuZCBzdWdnZXN0DQog c29tZSB0ZXh0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBz dHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPi0gMi4yOiBmb3IgcmVh ZGFiaWxpdHksIHBsZWFzZSBpbmNsdWRlIHRoZSBmdWxsIG5hbWVzIG9mIHRoZSBjbGFpbXMgKCZx dW90O0lzc3VlciZxdW90OywgJnF1b3Q7SldUIElEJnF1b3Q7IGV0Yy4pLjxicj4NCi0gSU1PIHRo ZSBkaXN0aW5jdGlvbiBiZXR3ZWVuIEpXVHMgYW5kIFNFVHMgd2l0aCByZWdhcmQgdG8gdGhlIG5l ZWQgdG8gdXNlICZxdW90O2V4cCZxdW90OyBpcyBub3QgY29udmluY2luZy4gSSBzdWdnZXN0IHdl IHJlZmVyIHRvIFNlYy4gNC41IGZvciBhIGJldHRlciByYXRpb25hbGUgd2h5IHdlIG1ha2UgdGhp cyBjbGFpbSBOT1QgUkVDT01NRU5ERUQgcmF0aGVyIHRoYW4gT1BUSU9OQUwgYXMgaW4gUkZDIDc1 MTkuPGJyPg0KLSB0eG46IHRoaXMgcGFyYWdyYXBoIHNob3VsZCBzcGVhayBhYm91dCBTRVRzIHJh dGhlciB0aGFuIEpXVHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPkkgd2lsbCBk ZWZlciB0byBNaWtlLCBidXQgSSBiZWxpZXZlIGhlIHN1Z2dlc3RlZCB0byBoYXZlIHRoaXMgcmVn aXN0ZXJlZCBmb3IgZ2VuZXJhbCBKV1QgdXNlLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxC b2R5Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmln aW5hbEJvZHkiPi0gJnF1b3Q7dG8gcHJvdmlkZSBpbnRlZ3JpdHksIGNvbmZpZGVudGlhbGl0eSwg YW5kIGlzc3VlciB2YWxpZGF0aW9uJnF1b3Q7LCBzaG91bGQgYmUgJnF1b3Q7aXNzdWVyIGF1dGhl bnRpY2l0eSZxdW90Oy48YnI+DQotICZxdW90O1doZXRoZXIgYW5kIGhvdyBtdWx0aXBsZSAmcXVv dDtldmVudHMmcXVvdDsgdmFsdWVzIGFyZSB1c2VkJnF1b3Q7OiB0aGUgcmVhZGVyIHdobyBoYXMg bm90IGJlZW4gZm9sbG93aW5nIG91ciBkaXNjdXNzaW9ucyBtYXkgbm90IHVuZGVyc3RhbmQgd2hh dCB0aGlzIG1lYW5zLCBtYXliZSB3ZSBzaG91bGQgc2F5IGluIHBhcmVudGhlc2VzLCAoaS5lLiBt dWx0aXBsZSBtZW1iZXJzIGluIHRoZSAmcXVvdDtldmVudHMmcXVvdDsgSlNPTiBvYmplY3QpLjxi cj4NCi0gJnF1b3Q7TVVTVCBzdXBwb3J0IFRMUyAxLjImcXVvdDsgLSBhZGQgJnF1b3Q7b3IgYSBo aWdoZXIgdmVyc2lvbiZxdW90Oy48YnI+DQotIDQuNTogaW50ZW50aW9uYWxseSAtIEkgdGhpbmsg d2UgbWVhbiAmcXVvdDttYWxpY2lvdXNseSZxdW90Oy48YnI+DQotIDYuMS4xOiAmcXVvdDtTZWN1 cml0eSBFdmVudCBVUkkmcXVvdDsgLSB0aGlzIGRlc2NyaXB0aW9uIGlzIGluY29ycmVjdCwgc2hv dWxkIHByb2JhYmx5IGJlICZxdW90O1NlY3VyaXR5IEV2ZW50IGluZm9ybWF0aW9uJnF1b3Q7IG9y IHNvbWV0aGluZyBzaW1pbGFybHkgdmFndWUuPGJyPg0KLSBSRkMgNzYxNyAtIHVudXNlZCByZWYu IFNpbWlsYXJseSBzYW1sLWNvcmUuPGJyPg0KPGJyPg0KVGhhbmtzLDxicj4NCiZuYnNwOyZuYnNw OyZuYnNwOyBZYXJvbjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KSWQtZXZlbnQgbWFpbGluZyBsaXN0PGJyPg0KPC9zcGFuPjxh IGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFy azpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+SWQtZXZlbnRA aWV0Zi5vcmc8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmln aW5hbEJvZHkiPjwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdp bmFsQm9keSI+PGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBv aW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9f aWQtMkRldmVudCZhbXA7ZD1Ed0lHYVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3 cUlyTVVCNjVlYXBJX0puRSZhbXA7cj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFh TGNMTjRLWk5BJmFtcDttPUYtUW12REZUQXBpUTZXamdhMFU5c3NacV9RTUxJWUdfWGlVMmc1Sk8w VWcmYW1wO3M9bkx3RFpodU00Ql9aVnhYM2RHRWFmWmd4WU9DUkRHTEJBUFRBN0lKM1lVbyZhbXA7 ZSI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5 bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy bD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmFt cDtkPUR3SUdhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElf Sm5FJmFtcDtyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmYW1w O209Ri1RbXZERlRBcGlRNldqZ2EwVTlzc1pxX1FNTElZR19YaVUyZzVKTzBVZyZhbXA7cz1uTHdE Wmh1TTRCX1pWeFgzZEdFYWZaZ3hZT0NSREdMQkFQVEE3SUozWVVvJmFtcDtlPC9zcGFuPjwvc3Bh bj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48L3NwYW4+PC9h PjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPj08bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJr Ol9NYWlsT3JpZ2luYWxCb2R5Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpf TWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTpIZWx2ZXRpY2EiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KSWQtZXZlbnQgbWFpbGluZyBsaXN0PGJyPg0KPC9zcGFuPjwvc3Bhbj48c3BhbiBz dHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48L3NwYW4+PGEgaHJlZj0ibWFp bHRvOklkLWV2ZW50QGlldGYub3JnIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3Jp Z2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZl dGljYTtjb2xvcjpwdXJwbGUiPklkLWV2ZW50QGlldGYub3JnPC9zcGFuPjwvc3Bhbj48c3BhbiBz dHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48L3NwYW4+PC9hPjxzcGFuIHN0 eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj48YnI+DQo8L3NwYW4+PC9zcGFuPjxzcGFu IHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjwvc3Bhbj48YSBocmVmPSJo dHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5p ZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmYW1wO2Q9RHdJQ0FnJmFtcDtjPVJv UDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmYW1wO3I9bmE1RlZ6QlRX bWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZhbXA7bT0ySExUNGQydHdDRllnbjJY SGVVSzJ0SHNiazFfcHpESDM4bXZOUU5hbW5RJmFtcDtzPVphODJFQnBwdV9tT2RyZHZEUXdKdW1j OUNweElldW5CRmRldUdRcFNXNEEmYW1wO2U9Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9N YWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OkhlbHZldGljYTtjb2xvcjpwdXJwbGUiPmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNv bS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRl dmVudCZhbXA7ZD1Ed0lDQWcmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVC NjVlYXBJX0puRSZhbXA7cj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRL Wk5BJmFtcDttPTJITFQ0ZDJ0d0NGWWduMlhIZVVLMnRIc2JrMV9wekRIMzhtdk5RTmFtblEmYW1w O3M9WmE4MkVCcHB1X21PZHJkdkRRd0p1bWM5Q3B4SWV1bkJGZGV1R1FwU1c0QSZhbXA7ZT08L3Nw YW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjwv c3Bhbj48L2E+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJv ZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_3B339ACB838646F98795278442BA4F06amazoncom_-- From nobody Fri Mar 2 14:39:24 2018 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 337011201FA for ; Fri, 2 Mar 2018 14:39:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.03 X-Spam-Level: X-Spam-Status: No, score=-0.03 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 pUOJQiyNrVs6 for ; Fri, 2 Mar 2018 14:39:18 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0128.outbound.protection.outlook.com [104.47.41.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C844126B6E for ; Fri, 2 Mar 2018 14:39: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=JN7O4LUYX6xXr6W+bDthX2pyyS6zjfHV5ckVSFJADnw=; b=IxcJ5NI90cdBFMJWLkV/RcmfMEc8jXuFNERNLcOWRqmA+mmJR3MY0JIxTGR2Lai3xEe6jNCiVHkDpgksne5y4xnOpSf9TPNMwwxjKn5vlzk1crlcvDnSRfco+h/zqqPLxA/kEyiX7LKFkAFDHN6j7rLQLRB0VXqUG5+f6FBw2S4= Received: from SN6PR2101MB0943.namprd21.prod.outlook.com (52.132.114.20) by SN6PR2101MB1088.namprd21.prod.outlook.com (52.132.115.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.567.2; Fri, 2 Mar 2018 22:39:15 +0000 Received: from SN6PR2101MB0943.namprd21.prod.outlook.com ([fe80::9866:f6b5:e2d6:50]) by SN6PR2101MB0943.namprd21.prod.outlook.com ([fe80::9866:f6b5:e2d6:50%2]) with mapi id 15.20.0567.006; Fri, 2 Mar 2018 22:39:15 +0000 From: Mike Jones To: "Richard Backman, Annabelle" , Phil Hunt CC: Yaron Sheffer , SecEvent Thread-Topic: [Id-event] Doc shepherd review Thread-Index: AQHTsOu1MSk9fbz0K0q+w+e8f4Rw8aO6d4+AgAABG+CAABr/wIABMp4AgAG+9ACAAAT4gIAAAKHw Date: Fri, 2 Mar 2018 22:39:15 +0000 Message-ID: References: <6e8afb70-3e6b-0ea5-7749-442c1c2d4c41@gmail.com> <49FAC72F-48E7-4B4C-8ACD-1259DADFE8FC@amazon.com> <847751A4-FF04-407E-9B2D-BB733CB9A1A0@oracle.com> <3B339ACB-8386-46F9-8795-278442BA4F06@amazon.com> In-Reply-To: <3B339ACB-8386-46F9-8795-278442BA4F06@amazon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=mbj@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-03-02T22:39:13.5518544Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General x-originating-ip: [2001:4898:80e8:c::42e] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN6PR2101MB1088; 7:5vo0WSDJs2r/zUYogjwvIAWilOpQU5SQlmOi+SSB82S2izyCKLnyIs/mapBkpDvsy3a7rmiBa3/+Grd/Y6Q/Pm4y+KBHScx4PTkcpJ9csfCUt0Sl2+jOEgj/idvzqR0DhNgXMgV+hWoPkSSCev77fua+Rj8/7i54xCqlKk2S6tuHYD2QJVDnR3Yj1fyBYUWJKhmWDv+aEqxE/d4UJSATwEfS/XKMVYVFtOuF/F0etl62H4dbsp25y70NHt2dW+a2 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: d9b03f5b-5d0e-4e84-4973-08d5808e6d87 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:SN6PR2101MB1088; x-ms-traffictypediagnostic: SN6PR2101MB1088: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(10436049006162)(89211679590171)(166708455590820)(192374486261705)(33061846794335)(85827821059158)(21748063052155)(146099531331640)(47284530071512); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040501)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3231220)(944501236)(52105095)(3002001)(6055026)(61426038)(61427038)(6041288)(20161123558120)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(6072148)(201708071742011); SRVR:SN6PR2101MB1088; BCL:0; PCL:0; RULEID:; SRVR:SN6PR2101MB1088; x-forefront-prvs: 05991796DF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39380400002)(376002)(346002)(39860400002)(366004)(51914003)(189003)(199004)(3280700002)(606006)(19609705001)(7736002)(68736007)(74316002)(5250100002)(22452003)(186003)(86612001)(106356001)(5660300001)(1680700002)(316002)(97736004)(110136005)(54906003)(33656002)(2906002)(39060400002)(102836004)(6346003)(790700001)(6116002)(59450400001)(6506007)(53546011)(14454004)(8936002)(81156014)(4326008)(55016002)(6436002)(8676002)(2900100001)(81166006)(8990500004)(93886005)(86362001)(10290500003)(105586002)(72206003)(966005)(10090500001)(2950100002)(53386004)(478600001)(6246003)(236005)(53936002)(6306002)(25786009)(9686003)(54896002)(99286004)(46003)(7696005)(3660700001)(76176011)(575784001)(229853002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR2101MB1088; H:SN6PR2101MB0943.namprd21.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) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-message-info: 7QtgeSffMDG7scTu1V1+SEpoPbSxzpSxLq1PiLI5canFMQr02MS7klj375Wy1QpTxJYG9sRN4AywX5iiXNx6XMmz+FY4S1ec5tXa9L65P+bdh04v3didIgeQlAm/LsBMly0BpQdvfA1RqVyorpjJwbJQk/FYhv8prU90GYKYdUo= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN6PR2101MB0943BE3D0CAF53953E8AEA8BF5C50SN6PR2101MB0943_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: d9b03f5b-5d0e-4e84-4973-08d5808e6d87 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Mar 2018 22:39:15.3236 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR2101MB1088 Archived-At: Subject: Re: [Id-event] Doc shepherd review X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 02 Mar 2018 22:39:22 -0000 --_000_SN6PR2101MB0943BE3D0CAF53953E8AEA8BF5C50SN6PR2101MB0943_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhdOKAmXMgY2xvc2VyLiAgSSBmaW5kIHRoZSB3b3JkIOKAnGFkZGl0aW9uYWzigJ0gc29tZXdo YXQgcHJlanVkaWNpYWwsIGhvd2V2ZXIuICBIb3cgYWJvdXQgdGhpcyBtb3JlIG5ldXRyYWwgbGFu Z3VhZ2U/DQoNCkFtb25nIHRoZSBzeW50YXggYW5kIHNlbWFudGljcyBvZiBTRVRzIHRoYXQgYSBw cm9maWxpbmcgc3BlY2lmaWNhdGlvbiBtYXkgZGVmaW5lIGlzIHdoZXRoZXIgdGhlIHZhbHVlIG9m IHRoZSDigJxldmVudHPigJ0gY2xhaW0gbWF5IGNvbnRhaW4gbXVsdGlwbGUgbWVtYmVycywgYW5k IHdoYXQgcHJvY2Vzc2luZyBpbnN0cnVjdGlvbnMgYXJlIGVtcGxveWVkIGluIHRoZSBzaW5nbGUt IGFuZCBtdWx0aXBsZS12YWx1ZWQgY2FzZXMgZm9yIFNFVHMgY29uZm9ybWluZyB0byB0aGF0IHBy b2ZpbGUuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IFJpY2hhcmQgQmFja21hbiwgQW5uYWJl bGxlIDxyaWNoYW5uYUBhbWF6b24uY29tPg0KU2VudDogRnJpZGF5LCBNYXJjaCAyLCAyMDE4IDI6 MzAgUE0NClRvOiBQaGlsIEh1bnQgPHBoaWwuaHVudEBvcmFjbGUuY29tPg0KQ2M6IE1pa2UgSm9u ZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT47IFlhcm9uIFNoZWZmZXIgPHlhcm9uZi5p ZXRmQGdtYWlsLmNvbT47IFNlY0V2ZW50IDxpZC1ldmVudEBpZXRmLm9yZz4NClN1YmplY3Q6IFJl OiBbSWQtZXZlbnRdIERvYyBzaGVwaGVyZCByZXZpZXcNCg0KSG93IGFib3V0Og0KDQpDaGFuZ2Ug dGhpcyBsaW5lPGh0dHBzOi8vZ2l0aHViLmNvbS9pbmRlcGVuZGVudGlkL0lkZW50aXR5LUV2ZW50 cy9wdWxsLzExL2NvbW1pdHMvZTI3YTI2OTZmNzA3MTA3ZWM4NWE5OTQ4NDRjNmNiZTIyODMzNTZl YyNkaWZmLWRjYjJmNzg2NGVhMTM1OTM2NzIwMDU5MmJmZWMzZTIxUjczNz4gdG86DQoNCkFtb25n IHRoZSBzeW50YXggYW5kIHNlbWFudGljcyBvZiBTRVRzIHRoYXQgYSBwcm9maWxpbmcgc3BlY2lm aWNhdGlvbiBtYXkgZGVmaW5lIGlzIHdoZXRoZXIgdGhlIHZhbHVlIG9mIHRoZSBldmVudHMgY2xh aW0gbWF5IGNvbnRhaW4gbXVsdGlwbGUgbWVtYmVycywgYW5kIGFueSBhZGRpdGlvbmFsIHByb2Nl c3NpbmcgaW5zdHJ1Y3Rpb25zIHJlcXVpcmVkIHdoZW4gbXVsdGlwbGUgbWVtYmVycyBhcmUgcHJl c2VudCBpbiBTRVRzIGNvbmZvcm1pbmcgdG8gdGhhdCBwcm9maWxlLg0KDQpJIHRoaW5rIHRoaXMg aXMgYSBjbGVhcmVyLCBtb3JlIHByZWNpc2UgZGVzY3JpcHRpb24gb2Ygd2hhdCBpdCBpcyBwcm9m aWxlIGF1dGhvcnMgbmVlZCB0byBjb25zaWRlci4gSXQgYWxzbyBmaXRzIGJldHRlciB3aXRoIHRo ZSBzdWJzZXF1ZW50IGV4YW1wbGVzLCB3aGljaCBwcmVzZW50IGRpZmZlcmVudCBydWxlcyBmb3Ig cHJvY2Vzc2luZyBtdWx0aS1ldmVudCBTRVRzLg0KDQotLQ0KQW5uYWJlbGxlIFJpY2hhcmQgQmFj a21hbg0KQW1hem9uIOKAkyBJZGVudGl0eSBTZXJ2aWNlcw0KDQpGcm9tOiBQaGlsIEh1bnQgPHBo aWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+DQpEYXRlOiBG cmlkYXksIE1hcmNoIDIsIDIwMTggYXQgMjoxMiBQTQ0KVG86ICJSaWNoYXJkIEJhY2ttYW4sIEFu bmFiZWxsZSIgPHJpY2hhbm5hQGFtYXpvbi5jb208bWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb20+ Pg0KQ2M6IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWlj aGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4sIFlhcm9uIFNoZWZmZXIgPHlhcm9uZi5pZXRmQGdt YWlsLmNvbTxtYWlsdG86eWFyb25mLmlldGZAZ21haWwuY29tPj4sIFNlY0V2ZW50IDxpZC1ldmVu dEBpZXRmLm9yZzxtYWlsdG86aWQtZXZlbnRAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtJZC1l dmVudF0gRG9jIHNoZXBoZXJkIHJldmlldw0KDQpBbm5hYmVsbGUsDQoNCkFwb2xvZ2llcywgYnV0 IOKAnHNpZ25pZmljYW5jZSBvZiB0aGlzIGNhc2XigJ0gZG9lcyBub3Qgc2VlbSB0byBhZGQgYWN0 aW9uYWJsZSBpbmZvcm1hdGlvbiBvciBhaWQgaW4gdW5kZXJzdGFuZGluZy4gQWxzbyAiaWYgYW55 4oCdIHNlZW1zIHVuY2xlYXIuDQoNCkNhbiB5b3UgcHJvcG9zZSBzb21ldGhpbmcgZWxzZSAod2l0 aCBiZWZvcmUgYW5kIGFmdGVyIHRleHQpPw0KDQpUaGFua3MsDQoNClBoaWwNCg0KT3JhY2xlIENv cnBvcmF0aW9uLCBJZGVudGl0eSBDbG91ZCBTZXJ2aWNlcyBBcmNoaXRlY3QNCkBpbmRlcGVuZGVu dGlkDQp3d3cuaW5kZXBlbmRlbnRpZC5jb208aHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNvbT4N CnBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4NCg0KT24g TWFyIDEsIDIwMTgsIGF0IDExOjMyIEFNLCBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSA8cmlj aGFubmFAYW1hem9uLmNvbTxtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbT4+IHdyb3RlOg0KDQri gJzigKZ3aGV0aGVyIGFuZCBob3cgbXVsdGlwbGUgbWVtYmVycyBvZiB0aGUgSlNPTiBvYmplY3Qg dGhhdCBpcyB0aGUgdmFsdWUgb2YgdGhlIGV2ZW50cyBjbGFpbSBhcmUgdXNlZCBmb3IgU0VUcyBj b25mb3JtaW5nIHRvIHRob3NlIHByb2ZpbGVzLuKAnQ0KDQpUaGUg4oCcd2hldGhlciBhbmQgaG93 4oCdIGNvbnN0cnVjdGlvbiBjb25kZW5zZXMgdGhpcyBzdGF0ZW1lbnQsIGJ1dCBJIHRoaW5rIGl0 IG1ha2VzIGl0IGhhcmRlciB0byB1bmRlcnN0YW5kLiBIb3cgYWJvdXQ6DQoNCuKAnOKApndoZXRo ZXIgdGhlIHZhbHVlIG9mIHRoZSBldmVudHMgY2xhaW0gbWF5IGNvbnRhaW4gbXVsdGlwbGUgbWVt YmVycywgYW5kIHRoZSBzaWduaWZpY2FuY2Ugb2YgdGhpcyBjYXNlIGlmIGFueSBmb3IgU0VUcyBj b25mb3JtaW5nIHRvIHRob3NlIHByb2ZpbGVzLuKAnQ0KDQotLQ0KQW5uYWJlbGxlIFJpY2hhcmQg QmFja21hbg0KQW1hem9uIOKAkyBJZGVudGl0eSBTZXJ2aWNlcw0KDQpGcm9tOiBJZC1ldmVudCA8 aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9y Zz4+IG9uIGJlaGFsZiBvZiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208 bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+DQpEYXRlOiBXZWRuZXNkYXksIEZl YnJ1YXJ5IDI4LCAyMDE4IGF0IDU6MTYgUE0NClRvOiBZYXJvbiBTaGVmZmVyIDx5YXJvbmYuaWV0 ZkBnbWFpbC5jb208bWFpbHRvOnlhcm9uZi5pZXRmQGdtYWlsLmNvbT4+DQpDYzogU2VjRXZlbnQg PGlkLWV2ZW50QGlldGYub3JnPG1haWx0bzppZC1ldmVudEBpZXRmLm9yZz4+LCBQaGlsIEh1bnQg PHBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+DQpTdWJq ZWN0OiBSZTogW0lkLWV2ZW50XSBEb2Mgc2hlcGhlcmQgcmV2aWV3DQoNCllhcm9uLCB0aGUgZWRp dHMgaW4gaHR0cHM6Ly9naXRodWIuY29tL2luZGVwZW5kZW50aWQvSWRlbnRpdHktRXZlbnRzL3B1 bGwvMTEvY29tbWl0cy9lMjdhMjY5NmY3MDcxMDdlYzg1YTk5NDg0NGM2Y2JlMjI4MzM1NmVjPGh0 dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZ2l0aHVi LmNvbV9pbmRlcGVuZGVudGlkX0lkZW50aXR5LTJERXZlbnRzX3B1bGxfMTFfY29tbWl0c19lMjdh MjY5NmY3MDcxMDdlYzg1YTk5NDg0NGM2Y2JlMjI4MzM1NmVjJmQ9RHdNR2FRJmM9Um9QMVl1bUNY Q2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZyPW5hNUZWekJUV21hbnFXTnk0RHBj dHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmbT0ySExUNGQydHdDRllnbjJYSGVVSzJ0SHNiazFfcHpE SDM4bXZOUU5hbW5RJnM9Z3g3OFFZTV80Wlk5NU1BbDlkNmJRc3IyNzVpb1llZDcwN2FvR2I3d0dk YyZlPT4gYWRkcmVzcyB5b3VyIHJldmlldyBjb21tZW50cy4NCg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0K RnJvbTogSWQtZXZlbnQgPGlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmlkLWV2ZW50 LWJvdW5jZXNAaWV0Zi5vcmc+PiBPbiBCZWhhbGYgT2YgTWlrZSBKb25lcw0KU2VudDogV2VkbmVz ZGF5LCBGZWJydWFyeSAyOCwgMjAxOCAzOjQ2IFBNDQpUbzogUGhpbCBIdW50IDxwaGlsLmh1bnRA b3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+PjsgWWFyb24gU2hlZmZlciA8 eWFyb25mLmlldGZAZ21haWwuY29tPG1haWx0bzp5YXJvbmYuaWV0ZkBnbWFpbC5jb20+Pg0KQ2M6 IFNlY0V2ZW50IDxpZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86aWQtZXZlbnRAaWV0Zi5vcmc+Pg0K U3ViamVjdDogUmU6IFtJZC1ldmVudF0gRG9jIHNoZXBoZXJkIHJldmlldw0KDQpQaGlsIGlzIGNv cnJlY3QuICBUaGUg4oCcdHhu4oCdIGNsYWltIGlzIGludGVudGlvbmFsbHkgdXNhYmxlIHdpdGgg YW55IEpXVCBhbmQgbm90IHNwZWNpZmljIHRvIFNFVHMuIFRoaXMganVzdCBoYXBwZW5zIHRvIGJl IHRoZSBzcGVjIHRvIGRlZmluZSBpdCBhbmQgYWRkIGl0IHRvIHRoZSBJQU5BIEpXVCBDbGFpbXMg cmVnaXN0cnkuDQoNCllhcm9uLCBJIHBsYW4gdG8gdHdlYWsgeW91ciBsYW5ndWFnZSDigJxTRVRz IHNlcnZlIHRvIGV4Y2hhbmdlIGluZm9ybWF0aW9uIGFib3V0IGlkZW50aXR5LXJlbGF0ZWQgZXZl bnRz4oCdIGJlY2F1c2UgdGhlIGNoYXJ0ZXIgaXMgYWJvdXQgc2VjdXJpdHkgZXZlbnRzLCBvbmx5 IHNvbWUgb2Ygd2hpY2ggYXJlIGlkZW50aXR5IGV2ZW50cy4gIFdlIHNob3VsZG7igJl0IG5hcnJv dyB0aGUgc2NvcGUgb2YgYXBwbGljYWJpbGl0eSBiZXlvbmQgd2hhdOKAmXMgaW50ZW5kZWQuDQoN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAtLSBNaWtlDQoNCkZyb206IElkLWV2ZW50IDxpZC1ldmVudC1ib3VuY2VzQGlldGYu b3JnPG1haWx0bzppZC1ldmVudC1ib3VuY2VzQGlldGYub3JnPj4gT24gQmVoYWxmIE9mIFBoaWwg SHVudA0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAyOCwgMjAxOCAzOjM1IFBNDQpUbzogWWFy b24gU2hlZmZlciA8eWFyb25mLmlldGZAZ21haWwuY29tPG1haWx0bzp5YXJvbmYuaWV0ZkBnbWFp bC5jb20+Pg0KQ2M6IFNlY0V2ZW50IDxpZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86aWQtZXZlbnRA aWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtJZC1ldmVudF0gRG9jIHNoZXBoZXJkIHJldmlldw0K DQpZYXJvbiwNCg0KVGhhbmtzIGZvciB0aGUgY29tbWVudHMsIHdpbGwgYWRkIHRvIHRoZSBuZXh0 IHVwZGF0ZS4NCg0KTWlrZSBoYXMgYWRkZWQgc29tZSBvdGhlciBtaW5vciBlZGl0b3JpYWwgZml4 ZXMgZm9yIGNvbnNpc3RlbmN5IHdpdGggSldUIGV0YyB3aGljaCBJIGJlbGlldmUgdGhlIGdyb3Vw IGRpc2N1c3NlZC4NCg0KQSBjb3VwbGUgcXVlc3Rpb25zIGlubGluZeKApg0KDQpQaGlsDQoNCk9y YWNsZSBDb3Jwb3JhdGlvbiwgSWRlbnRpdHkgQ2xvdWQgU2VydmljZXMgQXJjaGl0ZWN0DQpAaW5k ZXBlbmRlbnRpZA0Kd3d3LmluZGVwZW5kZW50aWQuY29tPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9v ZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX193d3cuaW5kZXBlbmRlbnRpZC5jb20mZD1Ed01H YVEmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJnI9bmE1RlZ6 QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZtPTJITFQ0ZDJ0d0NGWWduMlhI ZVVLMnRIc2JrMV9wekRIMzhtdk5RTmFtblEmcz1TRk1xTHZTd21YLU1YMHI4UWFuajBrMmpZVlBy d0JTU1VzSmh4MDNLeVBVJmU9Pg0KcGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVu dEBvcmFjbGUuY29tPg0KDQpPbiBGZWIgMjgsIDIwMTgsIGF0IDM6MjcgUE0sIFlhcm9uIFNoZWZm ZXIgPHlhcm9uZi5pZXRmQGdtYWlsLmNvbTxtYWlsdG86eWFyb25mLmlldGZAZ21haWwuY29tPj4g d3JvdGU6DQoNCkhpLA0KDQpJIHdpbGwgYmUgZG9jdW1lbnQgc2hlcGhlcmQgZm9yIHRoZSBTRVQg c3BlYy4gQXMgc3VjaCwgSSBqdXN0IHJlcmVhZCBpdCBvbmNlIGFnYWluLCBhbmQgSSB0aGluayBp dCBpcyBpbiB2ZXJ5IGdvb2Qgc2hhcGUuIEhlcmUgYXJlIG15IChtb3N0bHkgZWRpdG9yaWFsKSBj b21tZW50cy4NCg0KLSBBYnN0cmFjdDogcGxlYXNlIGFkZCB0aGUgZm9sbG93aW5nIHRvIGNsYXJp ZnksIGUuZy4gYWZ0ZXIgdGhlIGZpcnN0IHNlbnRlbmNlOiBTRVRzIHNlcnZlIHRvIGV4Y2hhbmdl IGluZm9ybWF0aW9uIGFib3V0IGlkZW50aXR5LXJlbGF0ZWQgZXZlbnRzLg0KLSBBIHNlY3VyaXR5 IHN1YmplY3QgTUFZIGJlIHBlcm1hbmVudCAtIHRoaXMgaXMgZGVzY3JpcHRpdmUgdGV4dCwgcGxl YXNlIGNoYW5nZSAiTUFZIiB0byAibWF5Ii4NCi0gIlNFVHMgaGF2ZSBubyBjYXBhYmlsaXR5IGZv ciBlcnJvciBzaWduYWxpbmcgdG8gZW5zdXJlIHRoZSB2YWxpZGF0aW9uIG9mIGEgcmVjZWl2ZWQg U0VUIiAtIFNFVHMgYXJlIGEgZm9ybWF0LCBzbyBpdCBpcyBhIGhpZ2hlciBsZXZlbCBwcm90b2Nv bCB0aGF0IG1heSBvciBtYXkgbm90IHNpZ25hbCBlcnJvcnMuIEkgc3VnZ2VzdCB0byByZW1vdmUg dGhpcyBzZW50ZW5jZS4NCi0gImhhcyBvY2N1cnJlZCBhYm91dCBhIFN1YmplY3QuIiBTaG91bGQg dGhpcyBiZSAiaGFzIG9jY3VycmVkIHRvIGEgU3ViamVjdOKAnT8NCg0KSSB3aWxsIHJlLXJlYWQu IEkgdGhpbmsgd2hhdCB0aGUgc3BlYyBpcyB0cnlpbmcgdG8gc2F5IGlzIHRvIG9yIHJlbGF0ZWQg dG8uIE1lYW5pbmcgdGhlIGV2ZW4gaXMgZGlyZWN0bHkgcmVsYXRlZCB0byB0aGUgc3ViamVjdCBi dXQgbm90IG5lY2Vzc2FyaWx5IHRvIHRoZSBzdWJqZWN0LiAgSSB3aWxsIHJldmlldyBhbmQgc3Vn Z2VzdCBzb21lIHRleHQuDQoNCi0gMi4yOiBmb3IgcmVhZGFiaWxpdHksIHBsZWFzZSBpbmNsdWRl IHRoZSBmdWxsIG5hbWVzIG9mIHRoZSBjbGFpbXMgKCJJc3N1ZXIiLCAiSldUIElEIiBldGMuKS4N Ci0gSU1PIHRoZSBkaXN0aW5jdGlvbiBiZXR3ZWVuIEpXVHMgYW5kIFNFVHMgd2l0aCByZWdhcmQg dG8gdGhlIG5lZWQgdG8gdXNlICJleHAiIGlzIG5vdCBjb252aW5jaW5nLiBJIHN1Z2dlc3Qgd2Ug cmVmZXIgdG8gU2VjLiA0LjUgZm9yIGEgYmV0dGVyIHJhdGlvbmFsZSB3aHkgd2UgbWFrZSB0aGlz IGNsYWltIE5PVCBSRUNPTU1FTkRFRCByYXRoZXIgdGhhbiBPUFRJT05BTCBhcyBpbiBSRkMgNzUx OS4NCi0gdHhuOiB0aGlzIHBhcmFncmFwaCBzaG91bGQgc3BlYWsgYWJvdXQgU0VUcyByYXRoZXIg dGhhbiBKV1RzLg0KDQpJIHdpbGwgZGVmZXIgdG8gTWlrZSwgYnV0IEkgYmVsaWV2ZSBoZSBzdWdn ZXN0ZWQgdG8gaGF2ZSB0aGlzIHJlZ2lzdGVyZWQgZm9yIGdlbmVyYWwgSldUIHVzZS4NCg0KLSAi dG8gcHJvdmlkZSBpbnRlZ3JpdHksIGNvbmZpZGVudGlhbGl0eSwgYW5kIGlzc3VlciB2YWxpZGF0 aW9uIiwgc2hvdWxkIGJlICJpc3N1ZXIgYXV0aGVudGljaXR5Ii4NCi0gIldoZXRoZXIgYW5kIGhv dyBtdWx0aXBsZSAiZXZlbnRzIiB2YWx1ZXMgYXJlIHVzZWQiOiB0aGUgcmVhZGVyIHdobyBoYXMg bm90IGJlZW4gZm9sbG93aW5nIG91ciBkaXNjdXNzaW9ucyBtYXkgbm90IHVuZGVyc3RhbmQgd2hh dCB0aGlzIG1lYW5zLCBtYXliZSB3ZSBzaG91bGQgc2F5IGluIHBhcmVudGhlc2VzLCAoaS5lLiBt dWx0aXBsZSBtZW1iZXJzIGluIHRoZSAiZXZlbnRzIiBKU09OIG9iamVjdCkuDQotICJNVVNUIHN1 cHBvcnQgVExTIDEuMiIgLSBhZGQgIm9yIGEgaGlnaGVyIHZlcnNpb24iLg0KLSA0LjU6IGludGVu dGlvbmFsbHkgLSBJIHRoaW5rIHdlIG1lYW4gIm1hbGljaW91c2x5Ii4NCi0gNi4xLjE6ICJTZWN1 cml0eSBFdmVudCBVUkkiIC0gdGhpcyBkZXNjcmlwdGlvbiBpcyBpbmNvcnJlY3QsIHNob3VsZCBw cm9iYWJseSBiZSAiU2VjdXJpdHkgRXZlbnQgaW5mb3JtYXRpb24iIG9yIHNvbWV0aGluZyBzaW1p bGFybHkgdmFndWUuDQotIFJGQyA3NjE3IC0gdW51c2VkIHJlZi4gU2ltaWxhcmx5IHNhbWwtY29y ZS4NCg0KVGhhbmtzLA0KICAgIFlhcm9uDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpJZC1ldmVudCBtYWlsaW5nIGxpc3QNCklkLWV2ZW50QGlldGYu b3JnPG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZz4NCmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBv aW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9f aWQtMkRldmVudCZkPUR3SUdhUSZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1 ZWFwSV9KbkUmcj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJm09 Ri1RbXZERlRBcGlRNldqZ2EwVTlzc1pxX1FNTElZR19YaVUyZzVKTzBVZyZzPW5Md0RaaHVNNEJf WlZ4WDNkR0VhZlpneFlPQ1JER0xCQVBUQTdJSjNZVW8mZT0NCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklkLWV2ZW50IG1haWxpbmcgbGlzdA0KSWQt ZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPg0KaHR0cHM6Ly91cmxkZWZl bnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1h bl9saXN0aW5mb19pZC0yRGV2ZW50JmQ9RHdJQ0FnJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4 QnY3cUlyTVVCNjVlYXBJX0puRSZyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFM Y0xONEtaTkEmbT0ySExUNGQydHdDRllnbjJYSGVVSzJ0SHNiazFfcHpESDM4bXZOUU5hbW5RJnM9 WmE4MkVCcHB1X21PZHJkdkRRd0p1bWM5Q3B4SWV1bkJGZGV1R1FwU1c0QSZlPQ0KDQo= --_000_SN6PR2101MB0943BE3D0CAF53953E8AEA8BF5C50SN6PR2101MB0943_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25v cm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1z b25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uYXBw bGUtc3R5bGUtc3Bhbg0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1zdHlsZS1zcGFuO30NCnNwYW4u YXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1z cGFjZTt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNw YW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu IDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5UaGF04oCZcyBjbG9zZXIuJm5ic3A7IEkgZmlu ZCB0aGUgd29yZCDigJxhZGRpdGlvbmFs4oCdIHNvbWV3aGF0IHByZWp1ZGljaWFsLCBob3dldmVy LiZuYnNwOyBIb3cgYWJvdXQgdGhpcyBtb3JlIG5ldXRyYWwgbGFuZ3VhZ2U/PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIw NjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+QW1vbmcg dGhlIHN5bnRheCBhbmQgc2VtYW50aWNzIG9mIFNFVHMgdGhhdCBhIHByb2ZpbGluZyBzcGVjaWZp Y2F0aW9uIG1heSBkZWZpbmUgaXMgd2hldGhlciB0aGUgdmFsdWUgb2YgdGhlIOKAnGV2ZW50c+KA nSBjbGFpbSBtYXkgY29udGFpbiBtdWx0aXBsZSBtZW1iZXJzLCBhbmQNCjxiPndoYXQ8L2I+IHBy b2Nlc3NpbmcgaW5zdHJ1Y3Rpb25zIGFyZSA8Yj5lbXBsb3llZCBpbiB0aGUgc2luZ2xlLSBhbmQg bXVsdGlwbGUtdmFsdWVkIGNhc2VzPC9iPiBmb3IgU0VUcyBjb25mb3JtaW5nIHRvIHRoYXQgcHJv ZmlsZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUg Jmx0O3JpY2hhbm5hQGFtYXpvbi5jb20mZ3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBN YXJjaCAyLCAyMDE4IDI6MzAgUE08YnI+DQo8Yj5Ubzo8L2I+IFBoaWwgSHVudCAmbHQ7cGhpbC5o dW50QG9yYWNsZS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBNaWtlIEpvbmVzICZsdDtNaWNoYWVs LkpvbmVzQG1pY3Jvc29mdC5jb20mZ3Q7OyBZYXJvbiBTaGVmZmVyICZsdDt5YXJvbmYuaWV0ZkBn bWFpbC5jb20mZ3Q7OyBTZWNFdmVudCAmbHQ7aWQtZXZlbnRAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbSWQtZXZlbnRdIERvYyBzaGVwaGVyZCByZXZpZXc8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhvdyBhYm91dDo8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Q2hhbmdlIDxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9pbmRlcGVuZGVudGlk L0lkZW50aXR5LUV2ZW50cy9wdWxsLzExL2NvbW1pdHMvZTI3YTI2OTZmNzA3MTA3ZWM4NWE5OTQ4 NDRjNmNiZTIyODMzNTZlYyNkaWZmLWRjYjJmNzg2NGVhMTM1OTM2NzIwMDU5MmJmZWMzZTIxUjcz NyI+DQp0aGlzIGxpbmU8L2E+IHRvOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+QW1vbmcgdGhlIHN5bnRheCBhbmQgc2VtYW50aWNzIG9mIFNFVHMgdGhh dA0KPGI+YSBwcm9maWxpbmcgc3BlY2lmaWNhdGlvbiBtYXk8L2I+IGRlZmluZSBpcyB3aGV0aGVy IDxiPnRoZSB2YWx1ZSBvZiB0aGUgZXZlbnRzIGNsYWltIG1heSBjb250YWluIG11bHRpcGxlIG1l bWJlcnMsIGFuZCBhbnkgYWRkaXRpb25hbCBwcm9jZXNzaW5nIGluc3RydWN0aW9ucyByZXF1aXJl ZCB3aGVuIG11bHRpcGxlIG1lbWJlcnMgYXJlIHByZXNlbnQgaW48L2I+IFNFVHMgY29uZm9ybWlu ZyB0bw0KPGI+dGhhdCBwcm9maWxlPC9iPi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGlu ayB0aGlzIGlzIGEgY2xlYXJlciwgbW9yZSBwcmVjaXNlIGRlc2NyaXB0aW9uIG9mIHdoYXQgaXQg aXMgcHJvZmlsZSBhdXRob3JzIG5lZWQgdG8gY29uc2lkZXIuIEl0IGFsc28gZml0cyBiZXR0ZXIg d2l0aCB0aGUgc3Vic2VxdWVudCBleGFtcGxlcywgd2hpY2ggcHJlc2VudCBkaWZmZXJlbnQgcnVs ZXMgZm9yIHByb2Nlc3NpbmcgbXVsdGktZXZlbnQgU0VUcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+LS0mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtm b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPkFubmFiZWxsZSBS aWNoYXJkIEJhY2ttYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssc2VyaWYiPkFtYXpvbiDigJMgSWRlbnRpdHkgU2VydmljZXM8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPlBoaWwg SHVudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIj5waGlsLmh1bnRA b3JhY2xlLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPkZyaWRheSwgTWFyY2ggMiwgMjAx OCBhdCAyOjEyIFBNPGJyPg0KPGI+VG86IDwvYj4mcXVvdDtSaWNoYXJkIEJhY2ttYW4sIEFubmFi ZWxsZSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb20iPnJpY2hh bm5hQGFtYXpvbi5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOiA8L2I+TWlrZSBKb25lcyAmbHQ7PGEg aHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSI+TWljaGFlbC5Kb25lc0Bt aWNyb3NvZnQuY29tPC9hPiZndDssIFlhcm9uIFNoZWZmZXIgJmx0OzxhIGhyZWY9Im1haWx0bzp5 YXJvbmYuaWV0ZkBnbWFpbC5jb20iPnlhcm9uZi5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7LCBTZWNF dmVudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlkLWV2ZW50QGlldGYub3JnIj5pZC1ldmVudEBpZXRm Lm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbSWQtZXZlbnRdIERvYyBzaGVw aGVyZCByZXZpZXc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+QW5uYWJlbGxlLCA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkFwb2xvZ2llcywgYnV0IOKAnHNpZ25pZmljYW5jZSBvZiB0aGlzIGNhc2XigJ0g ZG9lcyBub3Qgc2VlbSB0byBhZGQgYWN0aW9uYWJsZSBpbmZvcm1hdGlvbiBvciBhaWQgaW4gdW5k ZXJzdGFuZGluZy4gQWxzbyAmcXVvdDtpZiBhbnnigJ0gc2VlbXMgdW5jbGVhci48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2FuIHlvdSBwcm9w b3NlIHNvbWV0aGluZyBlbHNlICh3aXRoIGJlZm9yZSBhbmQgYWZ0ZXIgdGV4dCk/PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyw8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj5QaGlsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPk9yYWNsZSBDb3Jwb3JhdGlvbiwgSWRlbnRpdHkg Q2xvdWQgU2VydmljZXMgQXJjaGl0ZWN0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5AaW5k ZXBlbmRlbnRpZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGEgaHJlZj0iaHR0cDovL3d3 dy5pbmRlcGVuZGVudGlkLmNvbSI+d3d3LmluZGVwZW5kZW50aWQuY29tPC9hPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YSBocmVmPSJtYWlsdG86cGhpbC5o dW50QG9yYWNsZS5jb20iPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk9uIE1hciAxLCAyMDE4LCBhdCAxMTozMiBBTSwgUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUg Jmx0OzxhIGhyZWY9Im1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tIj5yaWNoYW5uYUBhbWF6b24u Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj7igJzigKZ3aGV0aGVyIGFuZCBob3cgbXVsdGlwbGUgbWVtYmVycyBvZiB0aGUgSlNP TiBvYmplY3QgdGhhdCBpcyB0aGUgdmFsdWUgb2YgdGhlIGV2ZW50cyBjbGFpbSBhcmUgdXNlZCBm b3IgU0VUcyBjb25mb3JtaW5nIHRvIHRob3NlIHByb2ZpbGVzLuKAnTxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUg4oCcd2hldGhlciBhbmQg aG934oCdIGNvbnN0cnVjdGlvbiBjb25kZW5zZXMgdGhpcyBzdGF0ZW1lbnQsIGJ1dCBJIHRoaW5r IGl0IG1ha2VzIGl0IGhhcmRlciB0byB1bmRlcnN0YW5kLiBIb3cgYWJvdXQ6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPuKAnOKApndoZXRoZXIg dGhlIHZhbHVlIG9mIHRoZSBldmVudHMgY2xhaW0gbWF5IGNvbnRhaW4gbXVsdGlwbGUgbWVtYmVy cywgYW5kIHRoZSBzaWduaWZpY2FuY2Ugb2YgdGhpcyBjYXNlIGlmIGFueSBmb3IgU0VUcyBjb25m b3JtaW5nIHRvIHRob3NlIHByb2ZpbGVzLuKAnTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4tLSZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+QW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyxzZXJpZiI+QW1hem9uIOKAkyBJZGVudGl0eSBTZXJ2aWNlczwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdCI+RnJvbTo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+SWQtZXZlbnQgJmx0 OzxhIGhyZWY9Im1haWx0bzppZC1ldmVudC1ib3VuY2VzQGlldGYub3JnIj48c3BhbiBzdHlsZT0i Y29sb3I6cHVycGxlIj5pZC1ldmVudC1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7DQog b24gYmVoYWxmIG9mIE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVz QG1pY3Jvc29mdC5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPk1pY2hhZWwuSm9uZXNA bWljcm9zb2Z0LmNvbTwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxiPkRhdGU6PHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5XZWRuZXNkYXksIEZlYnJ1YXJ5 IDI4LCAyMDE4IGF0IDU6MTYgUE08YnI+DQo8Yj5Ubzo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPllhcm9uIFNoZWZmZXIgJmx0OzxhIGhyZWY9Im1h aWx0bzp5YXJvbmYuaWV0ZkBnbWFpbC5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnlh cm9uZi5pZXRmQGdtYWlsLmNvbTwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxiPkNjOjxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+U2VjRXZlbnQgJmx0Ozxh IGhyZWY9Im1haWx0bzppZC1ldmVudEBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBs ZSI+aWQtZXZlbnRAaWV0Zi5vcmc8L3NwYW4+PC9hPiZndDssIFBoaWwgSHVudCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxl Ij5waGlsLmh1bnRAb3JhY2xlLmNvbTwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5SZTogW0lk LWV2ZW50XSBEb2Mgc2hlcGhlcmQgcmV2aWV3PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxh IG5hbWU9Il9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+WWFy b24sIHRoZSBlZGl0cyBpbjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48L3NwYW4+PC9hPjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50 LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZ2l0aHViLmNvbV9pbmRlcGVuZGVudGlkX0lkZW50aXR5 LTJERXZlbnRzX3B1bGxfMTFfY29tbWl0c19lMjdhMjY5NmY3MDcxMDdlYzg1YTk5NDg0NGM2Y2Jl MjI4MzM1NmVjJmFtcDtkPUR3TUdhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdx SXJNVUI2NWVhcElfSm5FJmFtcDtyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFM Y0xONEtaTkEmYW1wO209MkhMVDRkMnR3Q0ZZZ24yWEhlVUsydEhzYmsxX3B6REgzOG12TlFOYW1u USZhbXA7cz1neDc4UVlNXzRaWTk1TUFsOWQ2YlFzcjI3NWlvWWVkNzA3YW9HYjd3R2RjJmFtcDtl PSI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5 bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly9naXRodWIuY29tL2luZGVwZW5kZW50aWQvSWRlbnRp dHktRXZlbnRzL3B1bGwvMTEvY29tbWl0cy9lMjdhMjY5NmY3MDcxMDdlYzg1YTk5NDg0NGM2Y2Jl MjI4MzM1NmVjPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3Jp Z2luYWxCb2R5Ij48L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmln aW5hbEJvZHkiPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxl PSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjoj MDAyMDYwIj5hZGRyZXNzDQogeW91ciByZXZpZXcgY29tbWVudHMuPC9zcGFuPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9y aWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9v a21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxiPkZyb206PC9iPjxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5JZC1ldmVudCAmbHQ7PC9zcGFu PjxhIGhyZWY9Im1haWx0bzppZC1ldmVudC1ib3VuY2VzQGlldGYub3JnIj48c3BhbiBzdHlsZT0i bXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxl Ij5pZC1ldmVudC1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0ibXNv LWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJtc28t Ym9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZndDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGI+T24NCiBCZWhhbGYgT2Y8c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPk1pa2UgSm9uZXM8YnI+DQo8Yj5T ZW50OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ V2VkbmVzZGF5LCBGZWJydWFyeSAyOCwgMjAxOCAzOjQ2IFBNPGJyPg0KPGI+VG86PC9iPjxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5QaGlsIEh1bnQgJmx0 Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iPjxzcGFuIHN0eWxl PSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJw bGUiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJv b2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJtc28tYm9v a21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZndDs7DQogWWFyb24gU2hlZmZlciAmbHQ7PC9zcGFu PjxhIGhyZWY9Im1haWx0bzp5YXJvbmYuaWV0ZkBnbWFpbC5jb20iPjxzcGFuIHN0eWxlPSJtc28t Ym9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnlh cm9uZi5pZXRmQGdtYWlsLmNvbTwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFy azpfTWFpbE9yaWdpbmFsQm9keSI+PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJr Ol9NYWlsT3JpZ2luYWxCb2R5Ij4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPjxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5TZWNFdmVudCAmbHQ7PC9zcGFuPjxhIGhy ZWY9Im1haWx0bzppZC1ldmVudEBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpf TWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aWQtZXZlbnRAaWV0 Zi5vcmc8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5h bEJvZHkiPjwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFs Qm9keSI+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5SZTogW0lkLWV2ZW50XSBEb2Mgc2hlcGhlcmQgcmV2aWV3 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5h bEJvZHkiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJv ZHkiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5QaGlsIGlzIGNvcnJlY3QuJm5ic3A7IFRo ZSDigJx0eG7igJ0gY2xhaW0gaXMgaW50ZW50aW9uYWxseSB1c2FibGUgd2l0aCBhbnkgSldUIGFu ZCBub3Qgc3BlY2lmaWMgdG8gU0VUcy4gVGhpcyBqdXN0IGhhcHBlbnMgdG8gYmUgdGhlIHNwZWMg dG8gZGVmaW5lIGl0IGFuZCBhZGQgaXQgdG8gdGhlIElBTkENCiBKV1QgQ2xhaW1zIHJlZ2lzdHJ5 Ljwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48 c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJt c28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYw Ij5ZYXJvbiwgSSBwbGFuIHRvIHR3ZWFrIHlvdXIgbGFuZ3VhZ2Ug4oCcPC9zcGFuPlNFVHMgc2Vy dmUgdG8gZXhjaGFuZ2UgaW5mb3JtYXRpb24gYWJvdXQgaWRlbnRpdHktcmVsYXRlZCBldmVudHM8 c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+4oCdIGJlY2F1c2UgdGhlIGNoYXJ0ZXIgaXMgYWJv dXQNCiBzZWN1cml0eSBldmVudHMsIG9ubHkgc29tZSBvZiB3aGljaCBhcmUgaWRlbnRpdHkgZXZl bnRzLiZuYnNwOyBXZSBzaG91bGRu4oCZdCBuYXJyb3cgdGhlIHNjb3BlIG9mIGFwcGxpY2FiaWxp dHkgYmV5b25kIHdoYXTigJlzIGludGVuZGVkLjwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJv b2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHki PjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgLS0gTWlrZTwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWls T3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2tt YXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48Yj5Gcm9tOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+SWQtZXZlbnQgJmx0Ozwvc3Bhbj48YSBocmVmPSJt YWlsdG86aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFy azpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aWQtZXZlbnQt Ym91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpf TWFpbE9yaWdpbmFsQm9keSI+PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9N YWlsT3JpZ2luYWxCb2R5Ij4mZ3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjxiPk9uDQogQmVoYWxmIE9mPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5QaGlsIEh1bnQ8YnI+DQo8Yj5TZW50OjwvYj48c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+V2VkbmVzZGF5LCBG ZWJydWFyeSAyOCwgMjAxOCAzOjM1IFBNPGJyPg0KPGI+VG86PC9iPjxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5ZYXJvbiBTaGVmZmVyICZsdDs8L3NwYW4+ PGEgaHJlZj0ibWFpbHRvOnlhcm9uZi5pZXRmQGdtYWlsLmNvbSI+PHNwYW4gc3R5bGU9Im1zby1i b29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+eWFy b25mLmlldGZAZ21haWwuY29tPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJr Ol9NYWlsT3JpZ2luYWxCb2R5Ij48L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6 X01haWxPcmlnaW5hbEJvZHkiPiZndDs8YnI+DQo8Yj5DYzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlNlY0V2ZW50ICZsdDs8L3NwYW4+PGEgaHJl Zj0ibWFpbHRvOmlkLWV2ZW50QGlldGYub3JnIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9N YWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5pZC1ldmVudEBpZXRm Lm9yZzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFs Qm9keSI+PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxC b2R5Ij4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBbSWQtZXZlbnRdIERvYyBzaGVwaGVyZCByZXZpZXc8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFs Qm9keSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9k eSI+WWFyb24sPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5h bEJvZHkiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6 X01haWxPcmlnaW5hbEJvZHkiPlRoYW5rcyBmb3IgdGhlIGNvbW1lbnRzLCB3aWxsIGFkZCB0byB0 aGUgbmV4dCB1cGRhdGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFy azpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+TWlrZSBoYXMgYWRkZWQgc29tZSBvdGhl ciBtaW5vciBlZGl0b3JpYWwgZml4ZXMgZm9yIGNvbnNpc3RlbmN5IHdpdGggSldUIGV0YyB3aGlj aCBJIGJlbGlldmUgdGhlIGdyb3VwIGRpc2N1c3NlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5BIGNvdXBs ZSBxdWVzdGlvbnMgaW5saW5l4oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1i b29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+UGhpbDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJv ZHkiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01h aWxPcmlnaW5hbEJvZHkiPk9yYWNsZSBDb3Jwb3JhdGlvbiwgSWRlbnRpdHkgQ2xvdWQgU2Vydmlj ZXMgQXJjaGl0ZWN0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpf TWFpbE9yaWdpbmFsQm9keSI+QGluZGVwZW5kZW50aWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48L3NwYW4+PGEgaHJlZj0iaHR0 cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3d3dy5pbmRl cGVuZGVudGlkLmNvbSZhbXA7ZD1Ed01HYVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4 QnY3cUlyTVVCNjVlYXBJX0puRSZhbXA7cj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtB STFhTGNMTjRLWk5BJmFtcDttPTJITFQ0ZDJ0d0NGWWduMlhIZVVLMnRIc2JrMV9wekRIMzhtdk5R TmFtblEmYW1wO3M9U0ZNcUx2U3dtWC1NWDByOFFhbmowazJqWVZQcndCU1NVc0poeDAzS3lQVSZh bXA7ZT0iPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFu IHN0eWxlPSJjb2xvcjpwdXJwbGUiPnd3dy5pbmRlcGVuZGVudGlkLmNvbTwvc3Bhbj48L3NwYW4+ PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PC9zcGFuPjwvYT48 c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmln aW5hbEJvZHkiPjwvc3Bhbj48YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iPjxz cGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJj b2xvcjpwdXJwbGUiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHls ZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48L3NwYW4+PC9hPjxzcGFuIHN0eWxl PSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5PbiBGZWIg MjgsIDIwMTgsIGF0IDM6MjcgUE0sIFlhcm9uIFNoZWZmZXIgJmx0Ozwvc3Bhbj48YSBocmVmPSJt YWlsdG86eWFyb25mLmlldGZAZ21haWwuY29tIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9N YWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj55YXJvbmYuaWV0ZkBn bWFpbC5jb208L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmln aW5hbEJvZHkiPjwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdp bmFsQm9keSI+Jmd0Ow0KIHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFy azpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i bXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5IaSw8YnI+DQo8YnI+DQpJIHdpbGwgYmUg ZG9jdW1lbnQgc2hlcGhlcmQgZm9yIHRoZSBTRVQgc3BlYy4gQXMgc3VjaCwgSSBqdXN0IHJlcmVh ZCBpdCBvbmNlIGFnYWluLCBhbmQgSSB0aGluayBpdCBpcyBpbiB2ZXJ5IGdvb2Qgc2hhcGUuIEhl cmUgYXJlIG15IChtb3N0bHkgZWRpdG9yaWFsKSBjb21tZW50cy48YnI+DQo8YnI+DQotIEFic3Ry YWN0OiBwbGVhc2UgYWRkIHRoZSBmb2xsb3dpbmcgdG8gY2xhcmlmeSwgZS5nLiBhZnRlciB0aGUg Zmlyc3Qgc2VudGVuY2U6IFNFVHMgc2VydmUgdG8gZXhjaGFuZ2UgaW5mb3JtYXRpb24gYWJvdXQg aWRlbnRpdHktcmVsYXRlZCBldmVudHMuPGJyPg0KLSBBIHNlY3VyaXR5IHN1YmplY3QgTUFZIGJl IHBlcm1hbmVudCAtIHRoaXMgaXMgZGVzY3JpcHRpdmUgdGV4dCwgcGxlYXNlIGNoYW5nZSAmcXVv dDtNQVkmcXVvdDsgdG8gJnF1b3Q7bWF5JnF1b3Q7Ljxicj4NCi0gJnF1b3Q7U0VUcyBoYXZlIG5v IGNhcGFiaWxpdHkgZm9yIGVycm9yIHNpZ25hbGluZyB0byBlbnN1cmUgdGhlIHZhbGlkYXRpb24g b2YgYSByZWNlaXZlZCBTRVQmcXVvdDsgLSBTRVRzIGFyZSBhIGZvcm1hdCwgc28gaXQgaXMgYSBo aWdoZXIgbGV2ZWwgcHJvdG9jb2wgdGhhdCBtYXkgb3IgbWF5IG5vdCBzaWduYWwgZXJyb3JzLiBJ IHN1Z2dlc3QgdG8gcmVtb3ZlIHRoaXMgc2VudGVuY2UuPGJyPg0KLSAmcXVvdDtoYXMgb2NjdXJy ZWQgYWJvdXQgYSBTdWJqZWN0LiZxdW90OyBTaG91bGQgdGhpcyBiZSAmcXVvdDtoYXMgb2NjdXJy ZWQgdG8gYSBTdWJqZWN04oCdPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5JIHdp bGwgcmUtcmVhZC4gSSB0aGluayB3aGF0IHRoZSBzcGVjIGlzIHRyeWluZyB0byBzYXkgaXMgdG8g b3IgcmVsYXRlZCB0by4gTWVhbmluZyB0aGUgZXZlbiBpcyBkaXJlY3RseSByZWxhdGVkIHRvIHRo ZSBzdWJqZWN0IGJ1dCBub3QgbmVjZXNzYXJpbHkgdG8gdGhlIHN1YmplY3QuICZuYnNwO0kgd2ls bCByZXZpZXcgYW5kIHN1Z2dlc3QNCiBzb21lIHRleHQuPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJv ZHkiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdp bmFsQm9keSI+LSAyLjI6IGZvciByZWFkYWJpbGl0eSwgcGxlYXNlIGluY2x1ZGUgdGhlIGZ1bGwg bmFtZXMgb2YgdGhlIGNsYWltcyAoJnF1b3Q7SXNzdWVyJnF1b3Q7LCAmcXVvdDtKV1QgSUQmcXVv dDsgZXRjLikuPGJyPg0KLSBJTU8gdGhlIGRpc3RpbmN0aW9uIGJldHdlZW4gSldUcyBhbmQgU0VU cyB3aXRoIHJlZ2FyZCB0byB0aGUgbmVlZCB0byB1c2UgJnF1b3Q7ZXhwJnF1b3Q7IGlzIG5vdCBj b252aW5jaW5nLiBJIHN1Z2dlc3Qgd2UgcmVmZXIgdG8gU2VjLiA0LjUgZm9yIGEgYmV0dGVyIHJh dGlvbmFsZSB3aHkgd2UgbWFrZSB0aGlzIGNsYWltIE5PVCBSRUNPTU1FTkRFRCByYXRoZXIgdGhh biBPUFRJT05BTCBhcyBpbiBSRkMgNzUxOS48YnI+DQotIHR4bjogdGhpcyBwYXJhZ3JhcGggc2hv dWxkIHNwZWFrIGFib3V0IFNFVHMgcmF0aGVyIHRoYW4gSldUcy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmln aW5hbEJvZHkiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFp bE9yaWdpbmFsQm9keSI+SSB3aWxsIGRlZmVyIHRvIE1pa2UsIGJ1dCBJIGJlbGlldmUgaGUgc3Vn Z2VzdGVkIHRvIGhhdmUgdGhpcyByZWdpc3RlcmVkIGZvciBnZW5lcmFsIEpXVCB1c2UuJm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJtc28t Ym9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+LSAmcXVvdDt0byBwcm92aWRlIGludGVn cml0eSwgY29uZmlkZW50aWFsaXR5LCBhbmQgaXNzdWVyIHZhbGlkYXRpb24mcXVvdDssIHNob3Vs ZCBiZSAmcXVvdDtpc3N1ZXIgYXV0aGVudGljaXR5JnF1b3Q7Ljxicj4NCi0gJnF1b3Q7V2hldGhl ciBhbmQgaG93IG11bHRpcGxlICZxdW90O2V2ZW50cyZxdW90OyB2YWx1ZXMgYXJlIHVzZWQmcXVv dDs6IHRoZSByZWFkZXIgd2hvIGhhcyBub3QgYmVlbiBmb2xsb3dpbmcgb3VyIGRpc2N1c3Npb25z IG1heSBub3QgdW5kZXJzdGFuZCB3aGF0IHRoaXMgbWVhbnMsIG1heWJlIHdlIHNob3VsZCBzYXkg aW4gcGFyZW50aGVzZXMsIChpLmUuIG11bHRpcGxlIG1lbWJlcnMgaW4gdGhlICZxdW90O2V2ZW50 cyZxdW90OyBKU09OIG9iamVjdCkuPGJyPg0KLSAmcXVvdDtNVVNUIHN1cHBvcnQgVExTIDEuMiZx dW90OyAtIGFkZCAmcXVvdDtvciBhIGhpZ2hlciB2ZXJzaW9uJnF1b3Q7Ljxicj4NCi0gNC41OiBp bnRlbnRpb25hbGx5IC0gSSB0aGluayB3ZSBtZWFuICZxdW90O21hbGljaW91c2x5JnF1b3Q7Ljxi cj4NCi0gNi4xLjE6ICZxdW90O1NlY3VyaXR5IEV2ZW50IFVSSSZxdW90OyAtIHRoaXMgZGVzY3Jp cHRpb24gaXMgaW5jb3JyZWN0LCBzaG91bGQgcHJvYmFibHkgYmUgJnF1b3Q7U2VjdXJpdHkgRXZl bnQgaW5mb3JtYXRpb24mcXVvdDsgb3Igc29tZXRoaW5nIHNpbWlsYXJseSB2YWd1ZS48YnI+DQot IFJGQyA3NjE3IC0gdW51c2VkIHJlZi4gU2ltaWxhcmx5IHNhbWwtY29yZS48YnI+DQo8YnI+DQpU aGFua3MsPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IFlhcm9uPGJyPg0KPGJyPg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJZC1ldmVudCBtYWls aW5nIGxpc3Q8YnI+DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYub3JnIj48 c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0i Y29sb3I6cHVycGxlIj5JZC1ldmVudEBpZXRmLm9yZzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9 Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0i bXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48YnI+DQo8L3NwYW4+PGEgaHJlZj0iaHR0 cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0 Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmFtcDtkPUR3SUdhUSZhbXA7Yz1Sb1Ax WXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJmFtcDtyPW5hNUZWekJUV21h bnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmYW1wO209Ri1RbXZERlRBcGlRNldqZ2Ew VTlzc1pxX1FNTElZR19YaVUyZzVKTzBVZyZhbXA7cz1uTHdEWmh1TTRCX1pWeFgzZEdFYWZaZ3hZ T0NSREdMQkFQVEE3SUozWVVvJmFtcDtlIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWls T3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3VybGRlZmVu c2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFu X2xpc3RpbmZvX2lkLTJEZXZlbnQmYW1wO2Q9RHdJR2FRJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxa WVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmYW1wO3I9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQ cHVZcVBrQUkxYUxjTE40S1pOQSZhbXA7bT1GLVFtdkRGVEFwaVE2V2pnYTBVOXNzWnFfUU1MSVlH X1hpVTJnNUpPMFVnJmFtcDtzPW5Md0RaaHVNNEJfWlZ4WDNkR0VhZlpneFlPQ1JER0xCQVBUQTdJ SjNZVW8mYW1wO2U8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxP cmlnaW5hbEJvZHkiPjwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9y aWdpbmFsQm9keSI+PTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCklk LWV2ZW50IG1haWxpbmcgbGlzdDxicj4NCjwvc3Bhbj48L3NwYW4+PGEgaHJlZj0ibWFpbHRvOklk LWV2ZW50QGlldGYub3JnIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxC b2R5Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOnB1cnBsZSI+SWQtZXZlbnRAaWV0Zi5vcmc8L3Nw YW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjwv c3Bhbj48L2E+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+PGJyPg0KPC9zcGFuPjwvc3Bhbj48YSBocmVmPSJodHRwczovL3VybGRl ZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWls bWFuX2xpc3RpbmZvX2lkLTJEZXZlbnQmYW1wO2Q9RHdJQ0FnJmFtcDtjPVJvUDFZdW1DWENnYVdI dmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmYW1wO3I9bmE1RlZ6QlRXbWFucVdOeTREcGN0 eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZhbXA7bT0ySExUNGQydHdDRllnbjJYSGVVSzJ0SHNiazFf cHpESDM4bXZOUU5hbW5RJmFtcDtzPVphODJFQnBwdV9tT2RyZHZEUXdKdW1jOUNweElldW5CRmRl dUdRcFNXNEEmYW1wO2U9Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxC b2R5Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOnB1cnBsZSI+aHR0cHM6Ly91cmxkZWZlbnNlLnBy b29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0 aW5mb19pZC0yRGV2ZW50JmFtcDtkPUR3SUNBZyZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBa aDhCdjdxSXJNVUI2NWVhcElfSm5FJmFtcDtyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQ a0FJMWFMY0xONEtaTkEmYW1wO209MkhMVDRkMnR3Q0ZZZ24yWEhlVUsydEhzYmsxX3B6REgzOG12 TlFOYW1uUSZhbXA7cz1aYTgyRUJwcHVfbU9kcmR2RFF3SnVtYzlDcHhJZXVuQkZkZXVHUXBTVzRB JmFtcDtlPTwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdp bmFsQm9keSI+PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2lu YWxCb2R5Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PC9zcGFu Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_SN6PR2101MB0943BE3D0CAF53953E8AEA8BF5C50SN6PR2101MB0943_-- From nobody Fri Mar 2 14:53:51 2018 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 EDBD91250B8 for ; Fri, 2 Mar 2018 14:53:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.52 X-Spam-Level: X-Spam-Status: No, score=-12.52 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yeCfHESxuHMF for ; Fri, 2 Mar 2018 14:53:46 -0800 (PST) Received: from smtp-fw-9102.amazon.com (smtp-fw-9102.amazon.com [207.171.184.29]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34C57124B0A for ; Fri, 2 Mar 2018 14:53:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1520031226; x=1551567226; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=a15nwqW7qvCqpNwqyyoIhkbV38ZbUHWZ7qZdb7/S2Lk=; b=bpgEZgErrQlt6LAtcaf1en7mW6IPqfPhBmRLM5i6XBh5szSGLeoB/NPQ Wx1jObSH9ZUIztF5jEkZadZOPiG3aLP4nNFrCmp9MXvJ5usKpUdJD50mp VTL0r1TsznhxIgh8S0xuTZuNB5jPRjDJuUDtviCHEIVzpU9KfTBlBPa2Z E=; X-IronPort-AV: E=Sophos;i="5.47,414,1515456000"; d="scan'208,217";a="597634816" Received: from sea3-co-svc-lb6-vlan3.sea.amazon.com (HELO email-inbound-relay-2a-7c6d20a4.us-west-2.amazon.com) ([10.47.22.38]) by smtp-border-fw-out-9102.sea19.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Mar 2018 22:53:43 +0000 Received: from EX13MTAUWC001.ant.amazon.com (pdx1-ws-svc-p6-lb9-vlan3.pdx.amazon.com [10.236.137.198]) by email-inbound-relay-2a-7c6d20a4.us-west-2.amazon.com (8.14.7/8.14.7) with ESMTP id w22Mrg2s037882 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 2 Mar 2018 22:53:43 GMT Received: from EX13D11UWC001.ant.amazon.com (10.43.162.151) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Fri, 2 Mar 2018 22:53:43 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC001.ant.amazon.com (10.43.162.151) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Fri, 2 Mar 2018 22:53:42 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1236.000; Fri, 2 Mar 2018 22:53:42 +0000 From: "Richard Backman, Annabelle" To: Mike Jones , Phil Hunt CC: Yaron Sheffer , SecEvent Thread-Topic: [Id-event] Doc shepherd review Thread-Index: AQHTsOu4GgT2LTCZR0++jnMPeBylqqO6d4+AgAADDoCAABkyAIAArF2AgAJFDwD//37cgIAAiKeA//997QA= Date: Fri, 2 Mar 2018 22:53:42 +0000 Message-ID: <4D723055-D4CD-4418-AF9B-5E20EA9DCC9C@amazon.com> References: <6e8afb70-3e6b-0ea5-7749-442c1c2d4c41@gmail.com> <49FAC72F-48E7-4B4C-8ACD-1259DADFE8FC@amazon.com> <847751A4-FF04-407E-9B2D-BB733CB9A1A0@oracle.com> <3B339ACB-8386-46F9-8795-278442BA4F06@amazon.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.a.0.180210 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.160.245] Content-Type: multipart/alternative; boundary="_000_4D723055D4CD4418AF9B5E20EA9DCC9Camazoncom_" MIME-Version: 1.0 Precedence: Bulk Archived-At: Subject: Re: [Id-event] Doc shepherd review X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 02 Mar 2018 22:53:50 -0000 --_000_4D723055D4CD4418AF9B5E20EA9DCC9Camazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBsaWtlIHRoZSBhZGRpdGlvbiBvZiDigJxzaW5nbGUtIGFuZOKAnS4gKzENCg0KSSB0aGluayDi gJxhZGRpdGlvbmFs4oCdIGlzIGZhaXIsIGdpdmVuIHRoYXQgdGhleSB3b3VsZCBiZSBhZGRpdGlv bmFsIGluc3RydWN0aW9ucyBvbiB0b3Agb2YgdGhlIHByb2Nlc3NpbmcgaW5zdHJ1Y3Rpb25zIGRl ZmluZWQgd2l0aGluIFNFVCwgYnV0IEnigJltIGZpbmUgd2l0aCB0YWtpbmcgaXQgb3V0IGFuZCBn b2luZyB3aXRoIHlvdXIgdGV4dC4NCg0KLS0NCkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW4NCkFt YXpvbiDigJMgSWRlbnRpdHkgU2VydmljZXMNCg0KRnJvbTogSWQtZXZlbnQgPGlkLWV2ZW50LWJv dW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1p Y3Jvc29mdC5jb20+DQpEYXRlOiBGcmlkYXksIE1hcmNoIDIsIDIwMTggYXQgMjo0MCBQTQ0KVG86 ICJSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSIgPHJpY2hhbm5hQGFtYXpvbi5jb20+LCBQaGls IEh1bnQgPHBoaWwuaHVudEBvcmFjbGUuY29tPg0KQ2M6IFlhcm9uIFNoZWZmZXIgPHlhcm9uZi5p ZXRmQGdtYWlsLmNvbT4sIFNlY0V2ZW50IDxpZC1ldmVudEBpZXRmLm9yZz4NClN1YmplY3Q6IFJl OiBbSWQtZXZlbnRdIERvYyBzaGVwaGVyZCByZXZpZXcNCg0KVGhhdOKAmXMgY2xvc2VyLiAgSSBm aW5kIHRoZSB3b3JkIOKAnGFkZGl0aW9uYWzigJ0gc29tZXdoYXQgcHJlanVkaWNpYWwsIGhvd2V2 ZXIuICBIb3cgYWJvdXQgdGhpcyBtb3JlIG5ldXRyYWwgbGFuZ3VhZ2U/DQoNCkFtb25nIHRoZSBz eW50YXggYW5kIHNlbWFudGljcyBvZiBTRVRzIHRoYXQgYSBwcm9maWxpbmcgc3BlY2lmaWNhdGlv biBtYXkgZGVmaW5lIGlzIHdoZXRoZXIgdGhlIHZhbHVlIG9mIHRoZSDigJxldmVudHPigJ0gY2xh aW0gbWF5IGNvbnRhaW4gbXVsdGlwbGUgbWVtYmVycywgYW5kIHdoYXQgcHJvY2Vzc2luZyBpbnN0 cnVjdGlvbnMgYXJlIGVtcGxveWVkIGluIHRoZSBzaW5nbGUtIGFuZCBtdWx0aXBsZS12YWx1ZWQg Y2FzZXMgZm9yIFNFVHMgY29uZm9ybWluZyB0byB0aGF0IHByb2ZpbGUuDQoNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBN aWtlDQoNCkZyb206IFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIDxyaWNoYW5uYUBhbWF6b24u Y29tPg0KU2VudDogRnJpZGF5LCBNYXJjaCAyLCAyMDE4IDI6MzAgUE0NClRvOiBQaGlsIEh1bnQg PHBoaWwuaHVudEBvcmFjbGUuY29tPg0KQ2M6IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWlj cm9zb2Z0LmNvbT47IFlhcm9uIFNoZWZmZXIgPHlhcm9uZi5pZXRmQGdtYWlsLmNvbT47IFNlY0V2 ZW50IDxpZC1ldmVudEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbSWQtZXZlbnRdIERvYyBzaGVw aGVyZCByZXZpZXcNCg0KSG93IGFib3V0Og0KDQpDaGFuZ2UgdGhpcyBsaW5lPGh0dHBzOi8vZ2l0 aHViLmNvbS9pbmRlcGVuZGVudGlkL0lkZW50aXR5LUV2ZW50cy9wdWxsLzExL2NvbW1pdHMvZTI3 YTI2OTZmNzA3MTA3ZWM4NWE5OTQ4NDRjNmNiZTIyODMzNTZlYyNkaWZmLWRjYjJmNzg2NGVhMTM1 OTM2NzIwMDU5MmJmZWMzZTIxUjczNz4gdG86DQoNCkFtb25nIHRoZSBzeW50YXggYW5kIHNlbWFu dGljcyBvZiBTRVRzIHRoYXQgYSBwcm9maWxpbmcgc3BlY2lmaWNhdGlvbiBtYXkgZGVmaW5lIGlz IHdoZXRoZXIgdGhlIHZhbHVlIG9mIHRoZSBldmVudHMgY2xhaW0gbWF5IGNvbnRhaW4gbXVsdGlw bGUgbWVtYmVycywgYW5kIGFueSBhZGRpdGlvbmFsIHByb2Nlc3NpbmcgaW5zdHJ1Y3Rpb25zIHJl cXVpcmVkIHdoZW4gbXVsdGlwbGUgbWVtYmVycyBhcmUgcHJlc2VudCBpbiBTRVRzIGNvbmZvcm1p bmcgdG8gdGhhdCBwcm9maWxlLg0KDQpJIHRoaW5rIHRoaXMgaXMgYSBjbGVhcmVyLCBtb3JlIHBy ZWNpc2UgZGVzY3JpcHRpb24gb2Ygd2hhdCBpdCBpcyBwcm9maWxlIGF1dGhvcnMgbmVlZCB0byBj b25zaWRlci4gSXQgYWxzbyBmaXRzIGJldHRlciB3aXRoIHRoZSBzdWJzZXF1ZW50IGV4YW1wbGVz LCB3aGljaCBwcmVzZW50IGRpZmZlcmVudCBydWxlcyBmb3IgcHJvY2Vzc2luZyBtdWx0aS1ldmVu dCBTRVRzLg0KDQotLQ0KQW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbg0KQW1hem9uIOKAkyBJZGVu dGl0eSBTZXJ2aWNlcw0KDQpGcm9tOiBQaGlsIEh1bnQgPHBoaWwuaHVudEBvcmFjbGUuY29tPG1h aWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+DQpEYXRlOiBGcmlkYXksIE1hcmNoIDIsIDIwMTgg YXQgMjoxMiBQTQ0KVG86ICJSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSIgPHJpY2hhbm5hQGFt YXpvbi5jb208bWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb20+Pg0KQ2M6IE1pa2UgSm9uZXMgPE1p Y2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQu Y29tPj4sIFlhcm9uIFNoZWZmZXIgPHlhcm9uZi5pZXRmQGdtYWlsLmNvbTxtYWlsdG86eWFyb25m LmlldGZAZ21haWwuY29tPj4sIFNlY0V2ZW50IDxpZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86aWQt ZXZlbnRAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtJZC1ldmVudF0gRG9jIHNoZXBoZXJkIHJl dmlldw0KDQpBbm5hYmVsbGUsDQoNCkFwb2xvZ2llcywgYnV0IOKAnHNpZ25pZmljYW5jZSBvZiB0 aGlzIGNhc2XigJ0gZG9lcyBub3Qgc2VlbSB0byBhZGQgYWN0aW9uYWJsZSBpbmZvcm1hdGlvbiBv ciBhaWQgaW4gdW5kZXJzdGFuZGluZy4gQWxzbyAiaWYgYW554oCdIHNlZW1zIHVuY2xlYXIuDQoN CkNhbiB5b3UgcHJvcG9zZSBzb21ldGhpbmcgZWxzZSAod2l0aCBiZWZvcmUgYW5kIGFmdGVyIHRl eHQpPw0KDQpUaGFua3MsDQoNClBoaWwNCg0KT3JhY2xlIENvcnBvcmF0aW9uLCBJZGVudGl0eSBD bG91ZCBTZXJ2aWNlcyBBcmNoaXRlY3QNCkBpbmRlcGVuZGVudGlkDQp3d3cuaW5kZXBlbmRlbnRp ZC5jb208aHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNvbT4NCnBoaWwuaHVudEBvcmFjbGUuY29t PG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4NCg0KT24gTWFyIDEsIDIwMTgsIGF0IDExOjMy IEFNLCBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSA8cmljaGFubmFAYW1hem9uLmNvbTxtYWls dG86cmljaGFubmFAYW1hem9uLmNvbT4+IHdyb3RlOg0KDQrigJzigKZ3aGV0aGVyIGFuZCBob3cg bXVsdGlwbGUgbWVtYmVycyBvZiB0aGUgSlNPTiBvYmplY3QgdGhhdCBpcyB0aGUgdmFsdWUgb2Yg dGhlIGV2ZW50cyBjbGFpbSBhcmUgdXNlZCBmb3IgU0VUcyBjb25mb3JtaW5nIHRvIHRob3NlIHBy b2ZpbGVzLuKAnQ0KDQpUaGUg4oCcd2hldGhlciBhbmQgaG934oCdIGNvbnN0cnVjdGlvbiBjb25k ZW5zZXMgdGhpcyBzdGF0ZW1lbnQsIGJ1dCBJIHRoaW5rIGl0IG1ha2VzIGl0IGhhcmRlciB0byB1 bmRlcnN0YW5kLiBIb3cgYWJvdXQ6DQoNCuKAnOKApndoZXRoZXIgdGhlIHZhbHVlIG9mIHRoZSBl dmVudHMgY2xhaW0gbWF5IGNvbnRhaW4gbXVsdGlwbGUgbWVtYmVycywgYW5kIHRoZSBzaWduaWZp Y2FuY2Ugb2YgdGhpcyBjYXNlIGlmIGFueSBmb3IgU0VUcyBjb25mb3JtaW5nIHRvIHRob3NlIHBy b2ZpbGVzLuKAnQ0KDQotLQ0KQW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbg0KQW1hem9uIOKAkyBJ ZGVudGl0eSBTZXJ2aWNlcw0KDQpGcm9tOiBJZC1ldmVudCA8aWQtZXZlbnQtYm91bmNlc0BpZXRm Lm9yZzxtYWlsdG86aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBNaWtl IEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNA bWljcm9zb2Z0LmNvbT4+DQpEYXRlOiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDI4LCAyMDE4IGF0IDU6 MTYgUE0NClRvOiBZYXJvbiBTaGVmZmVyIDx5YXJvbmYuaWV0ZkBnbWFpbC5jb208bWFpbHRvOnlh cm9uZi5pZXRmQGdtYWlsLmNvbT4+DQpDYzogU2VjRXZlbnQgPGlkLWV2ZW50QGlldGYub3JnPG1h aWx0bzppZC1ldmVudEBpZXRmLm9yZz4+LCBQaGlsIEh1bnQgPHBoaWwuaHVudEBvcmFjbGUuY29t PG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+DQpTdWJqZWN0OiBSZTogW0lkLWV2ZW50XSBE b2Mgc2hlcGhlcmQgcmV2aWV3DQoNCllhcm9uLCB0aGUgZWRpdHMgaW4gaHR0cHM6Ly9naXRodWIu Y29tL2luZGVwZW5kZW50aWQvSWRlbnRpdHktRXZlbnRzL3B1bGwvMTEvY29tbWl0cy9lMjdhMjY5 NmY3MDcxMDdlYzg1YTk5NDg0NGM2Y2JlMjI4MzM1NmVjPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9v ZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZ2l0aHViLmNvbV9pbmRlcGVuZGVudGlkX0lk ZW50aXR5LTJERXZlbnRzX3B1bGxfMTFfY29tbWl0c19lMjdhMjY5NmY3MDcxMDdlYzg1YTk5NDg0 NGM2Y2JlMjI4MzM1NmVjJmQ9RHdNR2FRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUly TVVCNjVlYXBJX0puRSZyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEta TkEmbT0ySExUNGQydHdDRllnbjJYSGVVSzJ0SHNiazFfcHpESDM4bXZOUU5hbW5RJnM9Z3g3OFFZ TV80Wlk5NU1BbDlkNmJRc3IyNzVpb1llZDcwN2FvR2I3d0dkYyZlPT4gYWRkcmVzcyB5b3VyIHJl dmlldyBjb21tZW50cy4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogSWQtZXZlbnQgPGlkLWV2 ZW50LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmc+PiBP biBCZWhhbGYgT2YgTWlrZSBKb25lcw0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAyOCwgMjAx OCAzOjQ2IFBNDQpUbzogUGhpbCBIdW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhp bC5odW50QG9yYWNsZS5jb20+PjsgWWFyb24gU2hlZmZlciA8eWFyb25mLmlldGZAZ21haWwuY29t PG1haWx0bzp5YXJvbmYuaWV0ZkBnbWFpbC5jb20+Pg0KQ2M6IFNlY0V2ZW50IDxpZC1ldmVudEBp ZXRmLm9yZzxtYWlsdG86aWQtZXZlbnRAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtJZC1ldmVu dF0gRG9jIHNoZXBoZXJkIHJldmlldw0KDQpQaGlsIGlzIGNvcnJlY3QuICBUaGUg4oCcdHhu4oCd IGNsYWltIGlzIGludGVudGlvbmFsbHkgdXNhYmxlIHdpdGggYW55IEpXVCBhbmQgbm90IHNwZWNp ZmljIHRvIFNFVHMuIFRoaXMganVzdCBoYXBwZW5zIHRvIGJlIHRoZSBzcGVjIHRvIGRlZmluZSBp dCBhbmQgYWRkIGl0IHRvIHRoZSBJQU5BIEpXVCBDbGFpbXMgcmVnaXN0cnkuDQoNCllhcm9uLCBJ IHBsYW4gdG8gdHdlYWsgeW91ciBsYW5ndWFnZSDigJxTRVRzIHNlcnZlIHRvIGV4Y2hhbmdlIGlu Zm9ybWF0aW9uIGFib3V0IGlkZW50aXR5LXJlbGF0ZWQgZXZlbnRz4oCdIGJlY2F1c2UgdGhlIGNo YXJ0ZXIgaXMgYWJvdXQgc2VjdXJpdHkgZXZlbnRzLCBvbmx5IHNvbWUgb2Ygd2hpY2ggYXJlIGlk ZW50aXR5IGV2ZW50cy4gIFdlIHNob3VsZG7igJl0IG5hcnJvdyB0aGUgc2NvcGUgb2YgYXBwbGlj YWJpbGl0eSBiZXlvbmQgd2hhdOKAmXMgaW50ZW5kZWQuDQoNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZy b206IElkLWV2ZW50IDxpZC1ldmVudC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzppZC1ldmVudC1i b3VuY2VzQGlldGYub3JnPj4gT24gQmVoYWxmIE9mIFBoaWwgSHVudA0KU2VudDogV2VkbmVzZGF5 LCBGZWJydWFyeSAyOCwgMjAxOCAzOjM1IFBNDQpUbzogWWFyb24gU2hlZmZlciA8eWFyb25mLmll dGZAZ21haWwuY29tPG1haWx0bzp5YXJvbmYuaWV0ZkBnbWFpbC5jb20+Pg0KQ2M6IFNlY0V2ZW50 IDxpZC1ldmVudEBpZXRmLm9yZzxtYWlsdG86aWQtZXZlbnRAaWV0Zi5vcmc+Pg0KU3ViamVjdDog UmU6IFtJZC1ldmVudF0gRG9jIHNoZXBoZXJkIHJldmlldw0KDQpZYXJvbiwNCg0KVGhhbmtzIGZv ciB0aGUgY29tbWVudHMsIHdpbGwgYWRkIHRvIHRoZSBuZXh0IHVwZGF0ZS4NCg0KTWlrZSBoYXMg YWRkZWQgc29tZSBvdGhlciBtaW5vciBlZGl0b3JpYWwgZml4ZXMgZm9yIGNvbnNpc3RlbmN5IHdp dGggSldUIGV0YyB3aGljaCBJIGJlbGlldmUgdGhlIGdyb3VwIGRpc2N1c3NlZC4NCg0KQSBjb3Vw bGUgcXVlc3Rpb25zIGlubGluZeKApg0KDQpQaGlsDQoNCk9yYWNsZSBDb3Jwb3JhdGlvbiwgSWRl bnRpdHkgQ2xvdWQgU2VydmljZXMgQXJjaGl0ZWN0DQpAaW5kZXBlbmRlbnRpZA0Kd3d3LmluZGVw ZW5kZW50aWQuY29tPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1o dHRwLTNBX193d3cuaW5kZXBlbmRlbnRpZC5jb20mZD1Ed01HYVEmYz1Sb1AxWXVtQ1hDZ2FXSHZs WllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJnI9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZ cVBrQUkxYUxjTE40S1pOQSZtPTJITFQ0ZDJ0d0NGWWduMlhIZVVLMnRIc2JrMV9wekRIMzhtdk5R TmFtblEmcz1TRk1xTHZTd21YLU1YMHI4UWFuajBrMmpZVlByd0JTU1VzSmh4MDNLeVBVJmU9Pg0K cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPg0KDQpPbiBG ZWIgMjgsIDIwMTgsIGF0IDM6MjcgUE0sIFlhcm9uIFNoZWZmZXIgPHlhcm9uZi5pZXRmQGdtYWls LmNvbTxtYWlsdG86eWFyb25mLmlldGZAZ21haWwuY29tPj4gd3JvdGU6DQoNCkhpLA0KDQpJIHdp bGwgYmUgZG9jdW1lbnQgc2hlcGhlcmQgZm9yIHRoZSBTRVQgc3BlYy4gQXMgc3VjaCwgSSBqdXN0 IHJlcmVhZCBpdCBvbmNlIGFnYWluLCBhbmQgSSB0aGluayBpdCBpcyBpbiB2ZXJ5IGdvb2Qgc2hh cGUuIEhlcmUgYXJlIG15IChtb3N0bHkgZWRpdG9yaWFsKSBjb21tZW50cy4NCg0KLSBBYnN0cmFj dDogcGxlYXNlIGFkZCB0aGUgZm9sbG93aW5nIHRvIGNsYXJpZnksIGUuZy4gYWZ0ZXIgdGhlIGZp cnN0IHNlbnRlbmNlOiBTRVRzIHNlcnZlIHRvIGV4Y2hhbmdlIGluZm9ybWF0aW9uIGFib3V0IGlk ZW50aXR5LXJlbGF0ZWQgZXZlbnRzLg0KLSBBIHNlY3VyaXR5IHN1YmplY3QgTUFZIGJlIHBlcm1h bmVudCAtIHRoaXMgaXMgZGVzY3JpcHRpdmUgdGV4dCwgcGxlYXNlIGNoYW5nZSAiTUFZIiB0byAi bWF5Ii4NCi0gIlNFVHMgaGF2ZSBubyBjYXBhYmlsaXR5IGZvciBlcnJvciBzaWduYWxpbmcgdG8g ZW5zdXJlIHRoZSB2YWxpZGF0aW9uIG9mIGEgcmVjZWl2ZWQgU0VUIiAtIFNFVHMgYXJlIGEgZm9y bWF0LCBzbyBpdCBpcyBhIGhpZ2hlciBsZXZlbCBwcm90b2NvbCB0aGF0IG1heSBvciBtYXkgbm90 IHNpZ25hbCBlcnJvcnMuIEkgc3VnZ2VzdCB0byByZW1vdmUgdGhpcyBzZW50ZW5jZS4NCi0gImhh cyBvY2N1cnJlZCBhYm91dCBhIFN1YmplY3QuIiBTaG91bGQgdGhpcyBiZSAiaGFzIG9jY3VycmVk IHRvIGEgU3ViamVjdOKAnT8NCg0KSSB3aWxsIHJlLXJlYWQuIEkgdGhpbmsgd2hhdCB0aGUgc3Bl YyBpcyB0cnlpbmcgdG8gc2F5IGlzIHRvIG9yIHJlbGF0ZWQgdG8uIE1lYW5pbmcgdGhlIGV2ZW4g aXMgZGlyZWN0bHkgcmVsYXRlZCB0byB0aGUgc3ViamVjdCBidXQgbm90IG5lY2Vzc2FyaWx5IHRv IHRoZSBzdWJqZWN0LiAgSSB3aWxsIHJldmlldyBhbmQgc3VnZ2VzdCBzb21lIHRleHQuDQoNCi0g Mi4yOiBmb3IgcmVhZGFiaWxpdHksIHBsZWFzZSBpbmNsdWRlIHRoZSBmdWxsIG5hbWVzIG9mIHRo ZSBjbGFpbXMgKCJJc3N1ZXIiLCAiSldUIElEIiBldGMuKS4NCi0gSU1PIHRoZSBkaXN0aW5jdGlv biBiZXR3ZWVuIEpXVHMgYW5kIFNFVHMgd2l0aCByZWdhcmQgdG8gdGhlIG5lZWQgdG8gdXNlICJl eHAiIGlzIG5vdCBjb252aW5jaW5nLiBJIHN1Z2dlc3Qgd2UgcmVmZXIgdG8gU2VjLiA0LjUgZm9y IGEgYmV0dGVyIHJhdGlvbmFsZSB3aHkgd2UgbWFrZSB0aGlzIGNsYWltIE5PVCBSRUNPTU1FTkRF RCByYXRoZXIgdGhhbiBPUFRJT05BTCBhcyBpbiBSRkMgNzUxOS4NCi0gdHhuOiB0aGlzIHBhcmFn cmFwaCBzaG91bGQgc3BlYWsgYWJvdXQgU0VUcyByYXRoZXIgdGhhbiBKV1RzLg0KDQpJIHdpbGwg ZGVmZXIgdG8gTWlrZSwgYnV0IEkgYmVsaWV2ZSBoZSBzdWdnZXN0ZWQgdG8gaGF2ZSB0aGlzIHJl Z2lzdGVyZWQgZm9yIGdlbmVyYWwgSldUIHVzZS4NCg0KLSAidG8gcHJvdmlkZSBpbnRlZ3JpdHks IGNvbmZpZGVudGlhbGl0eSwgYW5kIGlzc3VlciB2YWxpZGF0aW9uIiwgc2hvdWxkIGJlICJpc3N1 ZXIgYXV0aGVudGljaXR5Ii4NCi0gIldoZXRoZXIgYW5kIGhvdyBtdWx0aXBsZSAiZXZlbnRzIiB2 YWx1ZXMgYXJlIHVzZWQiOiB0aGUgcmVhZGVyIHdobyBoYXMgbm90IGJlZW4gZm9sbG93aW5nIG91 ciBkaXNjdXNzaW9ucyBtYXkgbm90IHVuZGVyc3RhbmQgd2hhdCB0aGlzIG1lYW5zLCBtYXliZSB3 ZSBzaG91bGQgc2F5IGluIHBhcmVudGhlc2VzLCAoaS5lLiBtdWx0aXBsZSBtZW1iZXJzIGluIHRo ZSAiZXZlbnRzIiBKU09OIG9iamVjdCkuDQotICJNVVNUIHN1cHBvcnQgVExTIDEuMiIgLSBhZGQg Im9yIGEgaGlnaGVyIHZlcnNpb24iLg0KLSA0LjU6IGludGVudGlvbmFsbHkgLSBJIHRoaW5rIHdl IG1lYW4gIm1hbGljaW91c2x5Ii4NCi0gNi4xLjE6ICJTZWN1cml0eSBFdmVudCBVUkkiIC0gdGhp cyBkZXNjcmlwdGlvbiBpcyBpbmNvcnJlY3QsIHNob3VsZCBwcm9iYWJseSBiZSAiU2VjdXJpdHkg RXZlbnQgaW5mb3JtYXRpb24iIG9yIHNvbWV0aGluZyBzaW1pbGFybHkgdmFndWUuDQotIFJGQyA3 NjE3IC0gdW51c2VkIHJlZi4gU2ltaWxhcmx5IHNhbWwtY29yZS4NCg0KVGhhbmtzLA0KICAgIFlh cm9uDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJ ZC1ldmVudCBtYWlsaW5nIGxpc3QNCklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBp ZXRmLm9yZz4NCmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRw cy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZkPUR3SUdhUSZj PVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmcj1uYTVGVnpCVFdt YW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJm09Ri1RbXZERlRBcGlRNldqZ2EwVTlz c1pxX1FNTElZR19YaVUyZzVKTzBVZyZzPW5Md0RaaHVNNEJfWlZ4WDNkR0VhZlpneFlPQ1JER0xC QVBUQTdJSjNZVW8mZT0NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCklkLWV2ZW50IG1haWxpbmcgbGlzdA0KSWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRv OklkLWV2ZW50QGlldGYub3JnPg0KaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3Yy L3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50 JmQ9RHdJQ0FnJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZy PW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmbT0ySExUNGQydHdD RllnbjJYSGVVSzJ0SHNiazFfcHpESDM4bXZOUU5hbW5RJnM9WmE4MkVCcHB1X21PZHJkdkRRd0p1 bWM5Q3B4SWV1bkJGZGV1R1FwU1c0QSZlPQ0KDQo= --_000_4D723055D4CD4418AF9B5E20EA9DCC9Camazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <50894B0DE8E2514B8CFAFCC370749B5E@amazon.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXtt c28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFy Z2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVm dDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjt9DQpzcGFuLmFwcGxlLXN0eWxlLXNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtc3R5 bGUtc3Bhbjt9DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTph cHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6 d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMDAyMDYwO30N CnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEw LjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2lu OjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JIGxpa2UgdGhlIGFkZGl0aW9uIG9mIOKAnHNpbmdsZS0gYW5k4oCd LiAmIzQzOzE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayDigJxhZGRpdGlvbmFs4oCd IGlzIGZhaXIsIGdpdmVuIHRoYXQgdGhleSB3b3VsZCBiZSBhZGRpdGlvbmFsIGluc3RydWN0aW9u cyBvbiB0b3Agb2YgdGhlIHByb2Nlc3NpbmcgaW5zdHJ1Y3Rpb25zIGRlZmluZWQgd2l0aGluIFNF VCwgYnV0IEnigJltIGZpbmUgd2l0aCB0YWtpbmcgaXQgb3V0IGFuZCBnb2luZyB3aXRoIHlvdXIg dGV4dC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+ LS0mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssc2VyaWYiPkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPkFtYXpvbiDi gJMgSWRlbnRpdHkgU2VydmljZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Y29sb3I6YmxhY2siPklkLWV2ZW50ICZsdDtpZC1ldmVudC1ib3VuY2VzQGlldGYu b3JnJmd0OyBvbiBiZWhhbGYgb2YgTWlrZSBKb25lcyAmbHQ7TWljaGFlbC5Kb25lc0BtaWNyb3Nv ZnQuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5GcmlkYXksIE1hcmNoIDIsIDIwMTggYXQgMjo0 MCBQTTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7UmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUmcXVv dDsgJmx0O3JpY2hhbm5hQGFtYXpvbi5jb20mZ3Q7LCBQaGlsIEh1bnQgJmx0O3BoaWwuaHVudEBv cmFjbGUuY29tJmd0Ozxicj4NCjxiPkNjOiA8L2I+WWFyb24gU2hlZmZlciAmbHQ7eWFyb25mLmll dGZAZ21haWwuY29tJmd0OywgU2VjRXZlbnQgJmx0O2lkLWV2ZW50QGlldGYub3JnJmd0Ozxicj4N CjxiPlN1YmplY3Q6IDwvYj5SZTogW0lkLWV2ZW50XSBEb2Mgc2hlcGhlcmQgcmV2aWV3PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMDAyMDYwIj5UaGF04oCZcyBjbG9zZXIuJm5ic3A7IEkgZmluZCB0aGUgd29y ZCDigJxhZGRpdGlvbmFs4oCdIHNvbWV3aGF0IHByZWp1ZGljaWFsLCBob3dldmVyLiZuYnNwOyBI b3cgYWJvdXQgdGhpcyBtb3JlIG5ldXRyYWwgbGFuZ3VhZ2U/PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+QW1vbmcgdGhlIHN5bnRh eCBhbmQgc2VtYW50aWNzIG9mIFNFVHMgdGhhdCBhIHByb2ZpbGluZyBzcGVjaWZpY2F0aW9uIG1h eSBkZWZpbmUgaXMgd2hldGhlciB0aGUgdmFsdWUgb2YgdGhlIOKAnGV2ZW50c+KAnSBjbGFpbSBt YXkgY29udGFpbiBtdWx0aXBsZSBtZW1iZXJzLCBhbmQNCjxiPndoYXQ8L2I+IHByb2Nlc3Npbmcg aW5zdHJ1Y3Rpb25zIGFyZSA8Yj5lbXBsb3llZCBpbiB0aGUgc2luZ2xlLSBhbmQgbXVsdGlwbGUt dmFsdWVkIGNhc2VzPC9iPiBmb3IgU0VUcyBjb25mb3JtaW5nIHRvIHRoYXQgcHJvZmlsZS48L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAtLSBNaWtlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj5Gcm9tOjwvYj4gUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgJmx0O3JpY2hh bm5hQGFtYXpvbi5jb20mZ3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBNYXJjaCAyLCAy MDE4IDI6MzAgUE08YnI+DQo8Yj5Ubzo8L2I+IFBoaWwgSHVudCAmbHQ7cGhpbC5odW50QG9yYWNs ZS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBNaWtlIEpvbmVzICZsdDtNaWNoYWVsLkpvbmVzQG1p Y3Jvc29mdC5jb20mZ3Q7OyBZYXJvbiBTaGVmZmVyICZsdDt5YXJvbmYuaWV0ZkBnbWFpbC5jb20m Z3Q7OyBTZWNFdmVudCAmbHQ7aWQtZXZlbnRAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJlOiBbSWQtZXZlbnRdIERvYyBzaGVwaGVyZCByZXZpZXc8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhvdyBhYm91dDo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Q2hhbmdlIDxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9pbmRlcGVuZGVudGlkL0lkZW50aXR5 LUV2ZW50cy9wdWxsLzExL2NvbW1pdHMvZTI3YTI2OTZmNzA3MTA3ZWM4NWE5OTQ4NDRjNmNiZTIy ODMzNTZlYyNkaWZmLWRjYjJmNzg2NGVhMTM1OTM2NzIwMDU5MmJmZWMzZTIxUjczNyI+DQp0aGlz IGxpbmU8L2E+IHRvOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+QW1vbmcgdGhlIHN5bnRheCBhbmQgc2VtYW50aWNzIG9mIFNFVHMgdGhhdA0KPGI+YSBw cm9maWxpbmcgc3BlY2lmaWNhdGlvbiBtYXk8L2I+IGRlZmluZSBpcyB3aGV0aGVyIDxiPnRoZSB2 YWx1ZSBvZiB0aGUgZXZlbnRzIGNsYWltIG1heSBjb250YWluIG11bHRpcGxlIG1lbWJlcnMsIGFu ZCBhbnkgYWRkaXRpb25hbCBwcm9jZXNzaW5nIGluc3RydWN0aW9ucyByZXF1aXJlZCB3aGVuIG11 bHRpcGxlIG1lbWJlcnMgYXJlIHByZXNlbnQgaW48L2I+IFNFVHMgY29uZm9ybWluZyB0bw0KPGI+ dGhhdCBwcm9maWxlPC9iPi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayB0aGlzIGlz IGEgY2xlYXJlciwgbW9yZSBwcmVjaXNlIGRlc2NyaXB0aW9uIG9mIHdoYXQgaXQgaXMgcHJvZmls ZSBhdXRob3JzIG5lZWQgdG8gY29uc2lkZXIuIEl0IGFsc28gZml0cyBiZXR0ZXIgd2l0aCB0aGUg c3Vic2VxdWVudCBleGFtcGxlcywgd2hpY2ggcHJlc2VudCBkaWZmZXJlbnQgcnVsZXMgZm9yIHBy b2Nlc3NpbmcgbXVsdGktZXZlbnQgU0VUcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyxzZXJpZiI+LS0mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPkFubmFiZWxsZSBSaWNoYXJkIEJh Y2ttYW48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssc2VyaWYiPkFtYXpvbiDigJMgSWRlbnRpdHkgU2VydmljZXM8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPlBoaWwgSHVudCAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIj5waGlsLmh1bnRAb3JhY2xlLmNv bTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPkZyaWRheSwgTWFyY2ggMiwgMjAxOCBhdCAyOjEy IFBNPGJyPg0KPGI+VG86IDwvYj4mcXVvdDtSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSZxdW90 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5jb20iPnJpY2hhbm5hQGFtYXpv bi5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOiA8L2I+TWlrZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFp bHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQu Y29tPC9hPiZndDssIFlhcm9uIFNoZWZmZXIgJmx0OzxhIGhyZWY9Im1haWx0bzp5YXJvbmYuaWV0 ZkBnbWFpbC5jb20iPnlhcm9uZi5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7LCBTZWNFdmVudCAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmlkLWV2ZW50QGlldGYub3JnIj5pZC1ldmVudEBpZXRmLm9yZzwvYT4m Z3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbSWQtZXZlbnRdIERvYyBzaGVwaGVyZCByZXZp ZXc8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ QW5uYWJlbGxlLCA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkFwb2xvZ2llcywgYnV0IOKAnHNpZ25pZmljYW5jZSBvZiB0aGlzIGNhc2XigJ0gZG9lcyBub3Qg c2VlbSB0byBhZGQgYWN0aW9uYWJsZSBpbmZvcm1hdGlvbiBvciBhaWQgaW4gdW5kZXJzdGFuZGlu Zy4gQWxzbyAmcXVvdDtpZiBhbnnigJ0gc2VlbXMgdW5jbGVhci48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2FuIHlvdSBwcm9wb3NlIHNvbWV0 aGluZyBlbHNlICh3aXRoIGJlZm9yZSBhbmQgYWZ0ZXIgdGV4dCk/PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyw8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj5QaGlsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPk9yYWNsZSBDb3Jwb3JhdGlvbiwgSWRlbnRpdHkgQ2xvdWQgU2Vy dmljZXMgQXJjaGl0ZWN0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5AaW5kZXBlbmRlbnRp ZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGEgaHJlZj0iaHR0cDovL3d3dy5pbmRlcGVu ZGVudGlkLmNvbSI+d3d3LmluZGVwZW5kZW50aWQuY29tPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNs ZS5jb20iPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1hciAx LCAyMDE4LCBhdCAxMTozMiBBTSwgUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgJmx0OzxhIGhy ZWY9Im1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tIj5yaWNoYW5uYUBhbWF6b24uY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj7i gJzigKZ3aGV0aGVyIGFuZCBob3cgbXVsdGlwbGUgbWVtYmVycyBvZiB0aGUgSlNPTiBvYmplY3Qg dGhhdCBpcyB0aGUgdmFsdWUgb2YgdGhlIGV2ZW50cyBjbGFpbSBhcmUgdXNlZCBmb3IgU0VUcyBj b25mb3JtaW5nIHRvIHRob3NlIHByb2ZpbGVzLuKAnTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUg4oCcd2hldGhlciBhbmQgaG934oCdIGNv bnN0cnVjdGlvbiBjb25kZW5zZXMgdGhpcyBzdGF0ZW1lbnQsIGJ1dCBJIHRoaW5rIGl0IG1ha2Vz IGl0IGhhcmRlciB0byB1bmRlcnN0YW5kLiBIb3cgYWJvdXQ6PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPuKAnOKApndoZXRoZXIgdGhlIHZhbHVl IG9mIHRoZSBldmVudHMgY2xhaW0gbWF5IGNvbnRhaW4gbXVsdGlwbGUgbWVtYmVycywgYW5kIHRo ZSBzaWduaWZpY2FuY2Ugb2YgdGhpcyBjYXNlIGlmIGFueSBmb3IgU0VUcyBjb25mb3JtaW5nIHRv IHRob3NlIHByb2ZpbGVzLuKAnTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4tLSZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyxzZXJpZiI+QW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OyxzZXJpZiI+QW1hem9uIOKAkyBJZGVudGl0eSBTZXJ2aWNlczwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+RnJv bTo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+SWQtZXZlbnQgJmx0OzxhIGhyZWY9 Im1haWx0bzppZC1ldmVudC1ib3VuY2VzQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVy cGxlIj5pZC1ldmVudC1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7DQogb24gYmVoYWxm IG9mIE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29m dC5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0 LmNvbTwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxiPkRhdGU6PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5XZWRuZXNkYXksIEZlYnJ1YXJ5IDI4LCAyMDE4 IGF0IDU6MTYgUE08YnI+DQo8Yj5Ubzo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PC9iPllhcm9uIFNoZWZmZXIgJmx0OzxhIGhyZWY9Im1haWx0bzp5YXJv bmYuaWV0ZkBnbWFpbC5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnlhcm9uZi5pZXRm QGdtYWlsLmNvbTwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxiPkNjOjxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+U2VjRXZlbnQgJmx0OzxhIGhyZWY9Im1h aWx0bzppZC1ldmVudEBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aWQtZXZl bnRAaWV0Zi5vcmc8L3NwYW4+PC9hPiZndDssIFBoaWwgSHVudCAmbHQ7PGEgaHJlZj0ibWFpbHRv OnBoaWwuaHVudEBvcmFjbGUuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5waGlsLmh1 bnRAb3JhY2xlLmNvbTwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PHNwYW4gY2xhc3M9 ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5SZTogW0lkLWV2ZW50XSBE b2Mgc2hlcGhlcmQgcmV2aWV3PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9N YWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+WWFyb24sIHRoZSBl ZGl0cyBpbjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 L3NwYW4+PC9hPjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91 cmw/dT1odHRwcy0zQV9fZ2l0aHViLmNvbV9pbmRlcGVuZGVudGlkX0lkZW50aXR5LTJERXZlbnRz X3B1bGxfMTFfY29tbWl0c19lMjdhMjY5NmY3MDcxMDdlYzg1YTk5NDg0NGM2Y2JlMjI4MzM1NmVj JmFtcDtkPUR3TUdhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVh cElfSm5FJmFtcDtyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEm YW1wO209MkhMVDRkMnR3Q0ZZZ24yWEhlVUsydEhzYmsxX3B6REgzOG12TlFOYW1uUSZhbXA7cz1n eDc4UVlNXzRaWTk1TUFsOWQ2YlFzcjI3NWlvWWVkNzA3YW9HYjd3R2RjJmFtcDtlPSI+PHNwYW4g c3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9ImNvbG9y OnB1cnBsZSI+aHR0cHM6Ly9naXRodWIuY29tL2luZGVwZW5kZW50aWQvSWRlbnRpdHktRXZlbnRz L3B1bGwvMTEvY29tbWl0cy9lMjdhMjY5NmY3MDcxMDdlYzg1YTk5NDg0NGM2Y2JlMjI4MzM1NmVj PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5 Ij48L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHki PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MDAyMDYwIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5h ZGRyZXNzDQogeW91ciByZXZpZXcgY29tbWVudHMuPC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28t Ym9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9k eSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAtLSBNaWtlPC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01h aWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9v a21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxiPkZyb206PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5JZC1ldmVudCAmbHQ7PC9zcGFuPjxhIGhyZWY9 Im1haWx0bzppZC1ldmVudC1ib3VuY2VzQGlldGYub3JnIj48c3BhbiBzdHlsZT0ibXNvLWJvb2tt YXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5pZC1ldmVu dC1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJr Ol9NYWlsT3JpZ2luYWxCb2R5Ij48L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6 X01haWxPcmlnaW5hbEJvZHkiPiZndDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PGI+T24NCiBCZWhhbGYgT2Y8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPk1pa2UgSm9uZXM8YnI+DQo8Yj5TZW50OjwvYj48 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+V2VkbmVzZGF5 LCBGZWJydWFyeSAyOCwgMjAxOCAzOjQ2IFBNPGJyPg0KPGI+VG86PC9iPjxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5QaGlsIEh1bnQgJmx0Ozwvc3Bhbj48 YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iPjxzcGFuIHN0eWxlPSJtc28tYm9v a21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnBoaWwu aHVudEBvcmFjbGUuY29tPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9N YWlsT3JpZ2luYWxCb2R5Ij48L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01h aWxPcmlnaW5hbEJvZHkiPiZndDs7DQogWWFyb24gU2hlZmZlciAmbHQ7PC9zcGFuPjxhIGhyZWY9 Im1haWx0bzp5YXJvbmYuaWV0ZkBnbWFpbC5jb20iPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6 X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnlhcm9uZi5pZXRm QGdtYWlsLmNvbTwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9y aWdpbmFsQm9keSI+PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3Jp Z2luYWxCb2R5Ij4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5TZWNFdmVudCAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0 bzppZC1ldmVudEBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdp bmFsQm9keSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aWQtZXZlbnRAaWV0Zi5vcmc8L3Nw YW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjwv c3Bhbj48L2E+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jmd0 Ozxicj4NCjxiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj5SZTogW0lkLWV2ZW50XSBEb2Mgc2hlcGhlcmQgcmV2aWV3PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFu IHN0eWxlPSJjb2xvcjojMDAyMDYwIj5QaGlsIGlzIGNvcnJlY3QuJm5ic3A7IFRoZSDigJx0eG7i gJ0gY2xhaW0gaXMgaW50ZW50aW9uYWxseSB1c2FibGUgd2l0aCBhbnkgSldUIGFuZCBub3Qgc3Bl Y2lmaWMgdG8gU0VUcy4gVGhpcyBqdXN0IGhhcHBlbnMgdG8gYmUgdGhlIHNwZWMgdG8gZGVmaW5l IGl0IGFuZCBhZGQgaXQgdG8gdGhlIElBTkENCiBKV1QgQ2xhaW1zIHJlZ2lzdHJ5Ljwvc3Bhbj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHls ZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21h cms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5ZYXJvbiwg SSBwbGFuIHRvIHR3ZWFrIHlvdXIgbGFuZ3VhZ2Ug4oCcPC9zcGFuPlNFVHMgc2VydmUgdG8gZXhj aGFuZ2UgaW5mb3JtYXRpb24gYWJvdXQgaWRlbnRpdHktcmVsYXRlZCBldmVudHM8c3BhbiBzdHls ZT0iY29sb3I6IzAwMjA2MCI+4oCdIGJlY2F1c2UgdGhlIGNoYXJ0ZXIgaXMgYWJvdXQNCiBzZWN1 cml0eSBldmVudHMsIG9ubHkgc29tZSBvZiB3aGljaCBhcmUgaWRlbnRpdHkgZXZlbnRzLiZuYnNw OyBXZSBzaG91bGRu4oCZdCBuYXJyb3cgdGhlIHNjb3BlIG9mIGFwcGxpY2FiaWxpdHkgYmV5b25k IHdoYXTigJlzIGludGVuZGVkLjwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9N YWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg LS0gTWlrZTwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxC b2R5Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWls T3JpZ2luYWxCb2R5Ij48Yj5Gcm9tOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+SWQtZXZlbnQgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86aWQt ZXZlbnQtYm91bmNlc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9y aWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aWQtZXZlbnQtYm91bmNlc0Bp ZXRmLm9yZzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdp bmFsQm9keSI+PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2lu YWxCb2R5Ij4mZ3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPjxiPk9uDQogQmVoYWxmIE9mPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjwvYj5QaGlsIEh1bnQ8YnI+DQo8Yj5TZW50OjwvYj48c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+V2VkbmVzZGF5LCBGZWJydWFyeSAy OCwgMjAxOCAzOjM1IFBNPGJyPg0KPGI+VG86PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5ZYXJvbiBTaGVmZmVyICZsdDs8L3NwYW4+PGEgaHJlZj0i bWFpbHRvOnlhcm9uZi5pZXRmQGdtYWlsLmNvbSI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpf TWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+eWFyb25mLmlldGZA Z21haWwuY29tPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3Jp Z2luYWxCb2R5Ij48L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmln aW5hbEJvZHkiPiZndDs8YnI+DQo8Yj5DYzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlNlY0V2ZW50ICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRv OmlkLWV2ZW50QGlldGYub3JnIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2lu YWxCb2R5Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5pZC1ldmVudEBpZXRmLm9yZzwvc3Bh bj48L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PC9z cGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mZ3Q7 PGJyPg0KPGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPlJlOiBbSWQtZXZlbnRdIERvYyBzaGVwaGVyZCByZXZpZXc8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+WWFyb24s PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmln aW5hbEJvZHkiPlRoYW5rcyBmb3IgdGhlIGNvbW1lbnRzLCB3aWxsIGFkZCB0byB0aGUgbmV4dCB1 cGRhdGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9y aWdpbmFsQm9keSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29r bWFyazpfTWFpbE9yaWdpbmFsQm9keSI+TWlrZSBoYXMgYWRkZWQgc29tZSBvdGhlciBtaW5vciBl ZGl0b3JpYWwgZml4ZXMgZm9yIGNvbnNpc3RlbmN5IHdpdGggSldUIGV0YyB3aGljaCBJIGJlbGll dmUgdGhlIGdyb3VwIGRpc2N1c3NlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNv LWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5BIGNvdXBsZSBxdWVzdGlv bnMgaW5saW5l4oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpf TWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+UGhpbDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5h bEJvZHkiPk9yYWNsZSBDb3Jwb3JhdGlvbiwgSWRlbnRpdHkgQ2xvdWQgU2VydmljZXMgQXJjaGl0 ZWN0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdp bmFsQm9keSI+QGluZGVwZW5kZW50aWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNv LWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly91cmxk ZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3d3dy5pbmRlcGVuZGVudGlk LmNvbSZhbXA7ZD1Ed01HYVEmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVC NjVlYXBJX0puRSZhbXA7cj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRL Wk5BJmFtcDttPTJITFQ0ZDJ0d0NGWWduMlhIZVVLMnRIc2JrMV9wekRIMzhtdk5RTmFtblEmYW1w O3M9U0ZNcUx2U3dtWC1NWDByOFFhbmowazJqWVZQcndCU1NVc0poeDAzS3lQVSZhbXA7ZT0iPjxz cGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJj b2xvcjpwdXJwbGUiPnd3dy5pbmRlcGVuZGVudGlkLmNvbTwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5 bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PC9zcGFuPjwvYT48c3BhbiBzdHls ZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHki Pjwvc3Bhbj48YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iPjxzcGFuIHN0eWxl PSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJw bGUiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJv b2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJtc28tYm9v a21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxz cGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5PbiBGZWIgMjgsIDIwMTgs IGF0IDM6MjcgUE0sIFlhcm9uIFNoZWZmZXIgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86eWFy b25mLmlldGZAZ21haWwuY29tIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2lu YWxCb2R5Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj55YXJvbmYuaWV0ZkBnbWFpbC5jb208 L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHki Pjwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+ Jmd0Ow0KIHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9y aWdpbmFsQm9keSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2tt YXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5IaSw8YnI+DQo8YnI+DQpJIHdpbGwgYmUgZG9jdW1lbnQg c2hlcGhlcmQgZm9yIHRoZSBTRVQgc3BlYy4gQXMgc3VjaCwgSSBqdXN0IHJlcmVhZCBpdCBvbmNl IGFnYWluLCBhbmQgSSB0aGluayBpdCBpcyBpbiB2ZXJ5IGdvb2Qgc2hhcGUuIEhlcmUgYXJlIG15 IChtb3N0bHkgZWRpdG9yaWFsKSBjb21tZW50cy48YnI+DQo8YnI+DQotIEFic3RyYWN0OiBwbGVh c2UgYWRkIHRoZSBmb2xsb3dpbmcgdG8gY2xhcmlmeSwgZS5nLiBhZnRlciB0aGUgZmlyc3Qgc2Vu dGVuY2U6IFNFVHMgc2VydmUgdG8gZXhjaGFuZ2UgaW5mb3JtYXRpb24gYWJvdXQgaWRlbnRpdHkt cmVsYXRlZCBldmVudHMuPGJyPg0KLSBBIHNlY3VyaXR5IHN1YmplY3QgTUFZIGJlIHBlcm1hbmVu dCAtIHRoaXMgaXMgZGVzY3JpcHRpdmUgdGV4dCwgcGxlYXNlIGNoYW5nZSAmcXVvdDtNQVkmcXVv dDsgdG8gJnF1b3Q7bWF5JnF1b3Q7Ljxicj4NCi0gJnF1b3Q7U0VUcyBoYXZlIG5vIGNhcGFiaWxp dHkgZm9yIGVycm9yIHNpZ25hbGluZyB0byBlbnN1cmUgdGhlIHZhbGlkYXRpb24gb2YgYSByZWNl aXZlZCBTRVQmcXVvdDsgLSBTRVRzIGFyZSBhIGZvcm1hdCwgc28gaXQgaXMgYSBoaWdoZXIgbGV2 ZWwgcHJvdG9jb2wgdGhhdCBtYXkgb3IgbWF5IG5vdCBzaWduYWwgZXJyb3JzLiBJIHN1Z2dlc3Qg dG8gcmVtb3ZlIHRoaXMgc2VudGVuY2UuPGJyPg0KLSAmcXVvdDtoYXMgb2NjdXJyZWQgYWJvdXQg YSBTdWJqZWN0LiZxdW90OyBTaG91bGQgdGhpcyBiZSAmcXVvdDtoYXMgb2NjdXJyZWQgdG8gYSBT dWJqZWN04oCdPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5JIHdpbGwgcmUtcmVh ZC4gSSB0aGluayB3aGF0IHRoZSBzcGVjIGlzIHRyeWluZyB0byBzYXkgaXMgdG8gb3IgcmVsYXRl ZCB0by4gTWVhbmluZyB0aGUgZXZlbiBpcyBkaXJlY3RseSByZWxhdGVkIHRvIHRoZSBzdWJqZWN0 IGJ1dCBub3QgbmVjZXNzYXJpbHkgdG8gdGhlIHN1YmplY3QuICZuYnNwO0kgd2lsbCByZXZpZXcg YW5kIHN1Z2dlc3QNCiBzb21lIHRleHQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+ LSAyLjI6IGZvciByZWFkYWJpbGl0eSwgcGxlYXNlIGluY2x1ZGUgdGhlIGZ1bGwgbmFtZXMgb2Yg dGhlIGNsYWltcyAoJnF1b3Q7SXNzdWVyJnF1b3Q7LCAmcXVvdDtKV1QgSUQmcXVvdDsgZXRjLiku PGJyPg0KLSBJTU8gdGhlIGRpc3RpbmN0aW9uIGJldHdlZW4gSldUcyBhbmQgU0VUcyB3aXRoIHJl Z2FyZCB0byB0aGUgbmVlZCB0byB1c2UgJnF1b3Q7ZXhwJnF1b3Q7IGlzIG5vdCBjb252aW5jaW5n LiBJIHN1Z2dlc3Qgd2UgcmVmZXIgdG8gU2VjLiA0LjUgZm9yIGEgYmV0dGVyIHJhdGlvbmFsZSB3 aHkgd2UgbWFrZSB0aGlzIGNsYWltIE5PVCBSRUNPTU1FTkRFRCByYXRoZXIgdGhhbiBPUFRJT05B TCBhcyBpbiBSRkMgNzUxOS48YnI+DQotIHR4bjogdGhpcyBwYXJhZ3JhcGggc2hvdWxkIHNwZWFr IGFib3V0IFNFVHMgcmF0aGVyIHRoYW4gSldUcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHki PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFs Qm9keSI+SSB3aWxsIGRlZmVyIHRvIE1pa2UsIGJ1dCBJIGJlbGlldmUgaGUgc3VnZ2VzdGVkIHRv IGhhdmUgdGhpcyByZWdpc3RlcmVkIGZvciBnZW5lcmFsIEpXVCB1c2UuJm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6 X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29r bWFyazpfTWFpbE9yaWdpbmFsQm9keSI+LSAmcXVvdDt0byBwcm92aWRlIGludGVncml0eSwgY29u ZmlkZW50aWFsaXR5LCBhbmQgaXNzdWVyIHZhbGlkYXRpb24mcXVvdDssIHNob3VsZCBiZSAmcXVv dDtpc3N1ZXIgYXV0aGVudGljaXR5JnF1b3Q7Ljxicj4NCi0gJnF1b3Q7V2hldGhlciBhbmQgaG93 IG11bHRpcGxlICZxdW90O2V2ZW50cyZxdW90OyB2YWx1ZXMgYXJlIHVzZWQmcXVvdDs6IHRoZSBy ZWFkZXIgd2hvIGhhcyBub3QgYmVlbiBmb2xsb3dpbmcgb3VyIGRpc2N1c3Npb25zIG1heSBub3Qg dW5kZXJzdGFuZCB3aGF0IHRoaXMgbWVhbnMsIG1heWJlIHdlIHNob3VsZCBzYXkgaW4gcGFyZW50 aGVzZXMsIChpLmUuIG11bHRpcGxlIG1lbWJlcnMgaW4gdGhlICZxdW90O2V2ZW50cyZxdW90OyBK U09OIG9iamVjdCkuPGJyPg0KLSAmcXVvdDtNVVNUIHN1cHBvcnQgVExTIDEuMiZxdW90OyAtIGFk ZCAmcXVvdDtvciBhIGhpZ2hlciB2ZXJzaW9uJnF1b3Q7Ljxicj4NCi0gNC41OiBpbnRlbnRpb25h bGx5IC0gSSB0aGluayB3ZSBtZWFuICZxdW90O21hbGljaW91c2x5JnF1b3Q7Ljxicj4NCi0gNi4x LjE6ICZxdW90O1NlY3VyaXR5IEV2ZW50IFVSSSZxdW90OyAtIHRoaXMgZGVzY3JpcHRpb24gaXMg aW5jb3JyZWN0LCBzaG91bGQgcHJvYmFibHkgYmUgJnF1b3Q7U2VjdXJpdHkgRXZlbnQgaW5mb3Jt YXRpb24mcXVvdDsgb3Igc29tZXRoaW5nIHNpbWlsYXJseSB2YWd1ZS48YnI+DQotIFJGQyA3NjE3 IC0gdW51c2VkIHJlZi4gU2ltaWxhcmx5IHNhbWwtY29yZS48YnI+DQo8YnI+DQpUaGFua3MsPGJy Pg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IFlhcm9uPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJZC1ldmVudCBtYWlsaW5nIGxpc3Q8 YnI+DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYub3JnIj48c3BhbiBzdHls ZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVy cGxlIj5JZC1ldmVudEBpZXRmLm9yZzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29r bWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJvb2tt YXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48YnI+DQo8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly91cmxk ZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFp bG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmFtcDtkPUR3SUdhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FX SHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJmFtcDtyPW5hNUZWekJUV21hbnFXTnk0RHBj dHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmYW1wO209Ri1RbXZERlRBcGlRNldqZ2EwVTlzc1pxX1FN TElZR19YaVUyZzVKTzBVZyZhbXA7cz1uTHdEWmh1TTRCX1pWeFgzZEdFYWZaZ3hZT0NSREdMQkFQ VEE3SUozWVVvJmFtcDtlIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxC b2R5Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3VybGRlZmVuc2UucHJvb2Zw b2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZv X2lkLTJEZXZlbnQmYW1wO2Q9RHdJR2FRJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2 N3FJck1VQjY1ZWFwSV9KbkUmYW1wO3I9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkx YUxjTE40S1pOQSZhbXA7bT1GLVFtdkRGVEFwaVE2V2pnYTBVOXNzWnFfUU1MSVlHX1hpVTJnNUpP MFVnJmFtcDtzPW5Md0RaaHVNNEJfWlZ4WDNkR0VhZlpneFlPQ1JER0xCQVBUQTdJSjNZVW8mYW1w O2U8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJv ZHkiPjwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9k eSI+PTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i bXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQpJZC1ldmVudCBtYWlsaW5nIGxpc3Q8YnI+DQo8L3NwYW4+ PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpJZC1ldmVudEBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9Im1z by1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTpIZWx2ZXRpY2E7Y29sb3I6cHVycGxlIj5JZC1ldmVudEBpZXRmLm9yZzwv c3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+ PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+PGJyPg0K PC9zcGFuPjwvc3Bhbj48YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20v djIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJEZXZl bnQmYW1wO2Q9RHdJQ0FnJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1 ZWFwSV9KbkUmYW1wO3I9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pO QSZhbXA7bT0ySExUNGQydHdDRllnbjJYSGVVSzJ0SHNiazFfcHpESDM4bXZOUU5hbW5RJmFtcDtz PVphODJFQnBwdV9tT2RyZHZEUXdKdW1jOUNweElldW5CRmRldUdRcFNXNEEmYW1wO2U9Ij48c3Bh biBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYTtjb2xvcjpwdXJwbGUiPmh0dHBzOi8v dXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3Jn X21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZhbXA7ZD1Ed0lDQWcmYW1wO2M9Um9QMVl1bUNY Q2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZhbXA7cj1uYTVGVnpCVFdtYW5xV055 NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJmFtcDttPTJITFQ0ZDJ0d0NGWWduMlhIZVVLMnRI c2JrMV9wekRIMzhtdk5RTmFtblEmYW1wO3M9WmE4MkVCcHB1X21PZHJkdkRRd0p1bWM5Q3B4SWV1 bkJGZGV1R1FwU1c0QSZhbXA7ZT08L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21h cms6X01haWxPcmlnaW5hbEJvZHkiPjwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFy azpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28t Ym9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4D723055D4CD4418AF9B5E20EA9DCC9Camazoncom_-- From nobody Fri Mar 2 16:01:16 2018 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 0A937126CC4 for ; Fri, 2 Mar 2018 16:01:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.721 X-Spam-Level: X-Spam-Status: No, score=-0.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 EOWP2Vm13E4f for ; Fri, 2 Mar 2018 16:01:05 -0800 (PST) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::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 BA46A12EBAD for ; Fri, 2 Mar 2018 16:00:55 -0800 (PST) Received: by mail-vk0-x22f.google.com with SMTP id t126so6733436vkb.11 for ; Fri, 02 Mar 2018 16:00:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YWrc+s5wzf7Ha3Gt8sGYLTlE1EKR2Prrluy7wTV5aQQ=; b=MhnHFaCxEw00l8iqjlyvDrrkHQOZ3Mp9m5dlx8T60TDspPXAzmDHQeoHwA70Ti1iwH df4qC2j13a1AUIgsp17Ih0H0MY18vyXtSBfU/0/ZZpapSFVwByoJCNtrM1bwDgTHWH9B E39cFAoKstBnU1LSq+ojGG4LPxRKqSxff3yoZU9s4nwpI3xAon3FJ5JPhyM+nlDXSYjv weBC9ZCKYsgasq8GL9zGqtR/qTbu1pDaYbe0EZezcVlpCF1F/2BIO0z7X3IbYFVnRhO+ Np1riN9S7VvVMXWiEowibnZgpbJ7ndokfg+yVOOgNBS6TLoOVcwWJIWtw4OrerklIQk2 4rfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YWrc+s5wzf7Ha3Gt8sGYLTlE1EKR2Prrluy7wTV5aQQ=; b=fXx3KMjgHKP3IcMb/UiZn+USc00EttrmyhYs+aRuTTxmRxpX5pCndDiIRlzW+B6F2n FR58hkHFJEqc3NRwGplnJ73rOIbMnwg0y/XJhTyfLmWt5z74krABNEIbmuYxITkID3Vm DEkifFUxbnzEZ1ki/u6aklq5fLU7weyD9ltuFtD3ifGDCpcQWvIsS8Z4bZ+uaUmvUl1x XGuCpCSmY60lKjpklHSoeSCMIYMczCX2ovz/gptt7HwWK+RM+HO77VJDUEaHGMSuoqyg 5uE/VjYQMVQIOfBycsCFpTR3aBMYYaJF/F8PAwAx9SHIQDahgfCMynNvKnCECqF1lM5T xn2Q== X-Gm-Message-State: AElRT7GzvoxTT3/bZc+jTWmjXVefaaIXAzdb6QAsPE2G/4Hd/EllzuGC AuPBOWQ2xVCE+TBUL2TRabW+0yBloQnMtDHR+kgK6Q== X-Google-Smtp-Source: AG47ELvh/40yesxUgDqp4N93k7qK+tmOqE44BarMkGZntU68GmtrDX28vR+WiTOEUZOjGs9TjHTahX/6TiI4qP60UaU= X-Received: by 10.31.207.198 with SMTP id f189mr5296725vkg.75.1520035254223; Fri, 02 Mar 2018 16:00:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.94.88 with HTTP; Fri, 2 Mar 2018 16:00:33 -0800 (PST) In-Reply-To: <57C95B37-57A5-440E-9A4C-2D32B3677B9F@oracle.com> References: <57C95B37-57A5-440E-9A4C-2D32B3677B9F@oracle.com> From: Marius Scurtescu Date: Fri, 2 Mar 2018 16:00:33 -0800 Message-ID: To: Phil Hunt Cc: ID Events Mailing List Content-Type: multipart/alternative; boundary="001a114e5112608dd9056676c9fb" Archived-At: Subject: Re: [Id-event] small changes to draft-ietf-secevent-delivery X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 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, 03 Mar 2018 00:01:11 -0000 --001a114e5112608dd9056676c9fb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Mar 2, 2018 at 11:55 AM, Phil Hunt wrote: > Marius, > > Thanks. > > Item 1 and 2 look reasonable. > Sounds good. > > for Item 3, 4, I think the group should review. See below. > I also commented inline. > > Given the submission deadline is Monday, it would be good to wait group > confirmation of your proposals. > What that does mean in practical terms? If no one has objections we can go ahead? By when? > > Phil > > Oracle Corporation, Identity Cloud Services Architect > @independentid > www.independentid.com > phil.hunt@oracle.com > > On Mar 2, 2018, at 10:30 AM, Marius Scurtescu > wrote: > > I have a few other suggestions: > > 1. In section 1.2 we could drop the definition of Identity Provider and > Relying Party. I don't think these are necessary in this spec. > > 2. In section 2.1, the description of the PUSH delivery mode states that > the response must contain "Content-Type: application/json". I think that = is > the case only for error responses, I think on success no Content-Type is > needed at all. > > 3. In section 2.2, it is stated that "the Event Receiver SHALL indicate a= n > HTTP Status 400 error with an error code as described in Section 2.4". I > think that some error codes should be matched by other 4xx codes (for > example 401 and 403). I think it would be useful to list all the possible > error codes and corresponding HTTP Status codes in this section and not > refer to 2.4, > > > The 4xx messages are assumed by the HTTP RFCs while the errors in sec > 2.4 related to errors around jwt processing. We can call out specific 4xx > errors that are likely to occur, but I find that people then have issues > wondering if they can ever use the complete set of error conditions from > RFC7231. > > Would people find it useful to clarify or give examples of how 7231 error= s > might occur? > > I=E2=80=99m not sure which of the sec 2.4 error codes could be matched wi= th 401 or > 403. These are mostly JWT error conditions. Can you elaborate? > I think jwtAud and jwtIss should be 403 and not 400. setType and dup may also need something else than 400. > > 4. In section 2.3.1, the description of maxEvents, at the very end. A > conflict between zero request events and returnImmediately is described a= nd > the later should be ignored. I think this should not be a silent ignore b= ut > an error condition, > > The value of 0 is used to allow a poller to acknowledge previously > received SETs without having to process or wait for new events. Thus > returnImmediately is assumed. Thus the value of returnImmediately is > ignored. > Right, but to me with 0 and returnImmediately present the request is invalid and I don't think that returnImmediately should be simply ignored > Some participants indicated a desire to keep acknowledgement threads > separate from SET polling threads. Others wanted to be able to do both a= t > the same time. > Understood. > > The current spec is at: > https://tools.ietf.org/html/draft-ietf-secevent-delivery-01 > > > I am happy to send pull requests for all these changes. Let me know. > > Thanks, > Marius > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www. > ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3D > RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3D > na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3Dne_ktq-vH7- > ENPz2hHpvEBD9gZ8NVol5ZAKe9EeHvu8&s=3DuhRVJB8aZnVZHEY_ > MgIwN8ZjrBDaxt7YDmif4wyv6jg&e=3D > > > --001a114e5112608dd9056676c9fb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Mar 2, 2018 at 11:55 AM, Phil Hunt <phil.hunt@oracle.com= > wrote:
Marius,

Thanks.

Item 1 and 2 look reasonable.

Sounds good.

=C2=A0

for Item 3, 4, I think the group should rev= iew. See below.

I also co= mmented inline.

=C2=A0
<= br>
Given the submission deadline is Monday, it would be good to = wait group confirmation of your proposals.

What that does mean in practical terms? If no one has obj= ections we can go ahead? By when?
=C2=A0
<= div>
Phil

Orac= le Corporation, Identity Cloud Services Architect
@independentid<= /div>

On Mar 2, 20= 18, at 10:30 AM, Marius Scurtescu <mscurtescu@google.com> wrote:

I have a few other suggestions:

1. In section 1.2= we could drop the definition of Identity Provider and Relying Party. I don= 't think these are necessary in this spec.

2. In section= 2.1, the description of the PUSH delivery mode states that the response mu= st contain "Content-Type: application/json". I think that is the = case only for error responses, I think on success no Content-Type is needed= at all.

3. In section 2.2, it is stated that "the Even= t Receiver SHALL indicate an HTTP Status 400 error with an error code as de= scribed in Section 2.4". I think that some error codes should be match= ed by other 4xx codes (for example 401 and 403). I think it would be useful= to list all the possible error codes and corresponding HTTP Status codes i= n this section and not refer to 2.4,
<PH>The 4xx messages are assumed by the HTTP RFCs while= the errors in sec 2.4 related to errors around jwt processing. We can call= out specific 4xx errors that are likely to occur, but I find that people t= hen have issues wondering if they can ever use the complete set of error co= nditions from RFC7231.=C2=A0

Would people find it = useful to clarify or give examples of how 7231 errors might occur?

I=E2=80=99m not sure which of the sec 2.4 error codes coul= d be matched with 401 or 403. These are mostly JWT error conditions. Can yo= u elaborate?

I thin= k=C2=A0jwtAud and=C2=A0jwtIss should be 403 and not 400.

setType and dup may also need something else than 400.


4. In section 2.3.1, the descrip= tion of maxEvents, at the very end. A conflict between zero request events = and returnImmediately is described and the later should be ignored. I think= this should not be a silent ignore but an error condition,
<PH>The value of 0 is used to allow a poller to= acknowledge previously received SETs without having to process or wait for= new events. Thus returnImmediately is assumed. Thus the value of returnImm= ediately is ignored.

Right, but to me with 0 and returnImmediately present the request is inva= lid and I don't think that=C2=A0returnImmediately should be simply igno= red=C2=A0



=
Some participants indicated a desire to keep acknowledgement thr= eads separate from SET polling threads.=C2=A0 Others wanted to be able to d= o both at the same time.

--001a114e5112608dd9056676c9fb-- From nobody Fri Mar 2 16:23:12 2018 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 6008F126C83 for ; Fri, 2 Mar 2018 16:23:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.021 X-Spam-Level: X-Spam-Status: No, score=-0.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, HTTPS_HTTP_MISMATCH=1.989, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id whxwkQ65AuZF for ; Fri, 2 Mar 2018 16:23:09 -0800 (PST) Received: from aserp2120.oracle.com (aserp2120.oracle.com [141.146.126.78]) (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 5FE65126C26 for ; Fri, 2 Mar 2018 16:23:09 -0800 (PST) Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w230LbUt144242; Sat, 3 Mar 2018 00:23:07 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=corp-2017-10-26; bh=Tjq4DVBJb/B6HCKhIl77tFVWr/VR6/JnSJsdQtN3SaU=; b=rjD8anManOCwI4asN0gwFENObpLHJztUOJGtX2mG8+4R+UYKJip5zl4xRnsUaSvSKYlh S3h3IYfy30CzO2P9t6K+ev1iCwkrVi6fWESsuNyNRhx9baGJZwa5CNmFopp/+MlkhvPe 1+ELvlHOwb9Ad8tacPmDF6P0hIY3yabxI8TZFrnTcyKcyXaGfBuDp/xDco4Xw9wvwVUx aGD1MQSG8ija+KA78AZBV80rpsRYApOFaGeV7wKhbTDR812tqSMgWCmYFXzGMfHGXBr3 qev9PVPZAXoaCu+g28LCzJmVDpTDWMGqzxnDODN5DQiONFugRGig2rWT7czCYet/kiHI Xg== Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp2120.oracle.com with ESMTP id 2gfbnhs7sx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 03 Mar 2018 00:23:07 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w230N6gV029380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sat, 3 Mar 2018 00:23:06 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w230N61o031805; Sat, 3 Mar 2018 00:23:06 GMT Received: from [192.168.1.28] (/70.70.142.148) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 02 Mar 2018 16:23:05 -0800 From: Phil Hunt Message-Id: <0D2EA133-3E7B-497D-9364-C919D4FCB925@oracle.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_C12AB9D4-0C00-4952-9AEB-CF9FA1148666" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Fri, 2 Mar 2018 16:23:02 -0800 In-Reply-To: Cc: ID Events Mailing List To: Marius Scurtescu References: <57C95B37-57A5-440E-9A4C-2D32B3677B9F@oracle.com> X-Mailer: Apple Mail (2.3445.5.20) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8820 signatures=668682 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803030004 Archived-At: Subject: Re: [Id-event] small changes to draft-ietf-secevent-delivery X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 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, 03 Mar 2018 00:23:11 -0000 --Apple-Mail=_C12AB9D4-0C00-4952-9AEB-CF9FA1148666 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Inline Phil Oracle Corporation, Identity Cloud Services Architect @independentid www.independentid.com = phil.hunt@oracle.com = > On Mar 2, 2018, at 4:00 PM, Marius Scurtescu = wrote: >=20 > On Fri, Mar 2, 2018 at 11:55 AM, Phil Hunt > wrote: > Marius, >=20 > Thanks. >=20 > Item 1 and 2 look reasonable. >=20 > Sounds good. >=20 > =20 >=20 > for Item 3, 4, I think the group should review. See below. >=20 > I also commented inline. >=20 > =20 >=20 > Given the submission deadline is Monday, it would be good to wait = group confirmation of your proposals. >=20 > What that does mean in practical terms? If no one has objections we = can go ahead? By when? > =20 >=20 > Phil >=20 > Oracle Corporation, Identity Cloud Services Architect > @independentid > www.independentid.com = phil.hunt@o= racle.com >=20 >> On Mar 2, 2018, at 10:30 AM, Marius Scurtescu > wrote: >>=20 >> I have a few other suggestions: >>=20 >> 1. In section 1.2 we could drop the definition of Identity Provider = and Relying Party. I don't think these are necessary in this spec. >>=20 >> 2. In section 2.1, the description of the PUSH delivery mode states = that the response must contain "Content-Type: application/json". I think = that is the case only for error responses, I think on success no = Content-Type is needed at all. >>=20 >> 3. In section 2.2, it is stated that "the Event Receiver SHALL = indicate an HTTP Status 400 error with an error code as described in = Section 2.4". I think that some error codes should be matched by other = 4xx codes (for example 401 and 403). I think it would be useful to list = all the possible error codes and corresponding HTTP Status codes in this = section and not refer to 2.4, >=20 > The 4xx messages are assumed by the HTTP RFCs while the errors in = sec 2.4 related to errors around jwt processing. We can call out = specific 4xx errors that are likely to occur, but I find that people = then have issues wondering if they can ever use the complete set of = error conditions from RFC7231.=20 >=20 > Would people find it useful to clarify or give examples of how 7231 = errors might occur? >=20 > I=E2=80=99m not sure which of the sec 2.4 error codes could be matched = with 401 or 403. These are mostly JWT error conditions. Can you = elaborate? >=20 > I think jwtAud and jwtIss should be 403 and not 400. jwtAud and jwtIss are issues with the payload. 403 indicates the wrong = authorization credential was used. E.g. a bad authorization header. It is important to distinguish between an http authorization header and = a malformed SET. >=20 > setType and dup may also need something else than 400. I think dup is no longer needed as we changed language to allow = recovery. setType - We should maybe update the terminology to setEventUri = indicating the receiver is refusing a specific event type. 406 is the closest, yet that code is about media types not being = acceptable. 406 can occur if someone requests application/xml for = example. >=20 >=20 >>=20 >> 4. In section 2.3.1, the description of maxEvents, at the very end. A = conflict between zero request events and returnImmediately is described = and the later should be ignored. I think this should not be a silent = ignore but an error condition, > The value of 0 is used to allow a poller to acknowledge previously = received SETs without having to process or wait for new events. Thus = returnImmediately is assumed. Thus the value of returnImmediately is = ignored. >=20 > Right, but to me with 0 and returnImmediately present the request is = invalid and I don't think that returnImmediately should be simply = ignored=20 See section 2.3.3, in particular acknowledge only (2.3.3.2). = =E2=80=9CmaxEvents=E2=80=9D:0 is what makes a request ack only. It can = be expressed in a more obvious way, but I believe the discussion was = this was simpler overall. returnImmediately:true in the case of 2.3.3.2 is redundant. It isn=E2=80=99= t an error because control always returns immediately. = returnImmediately:false would however would be an error because there is = nothing to return in section 2.3.3.2. Looking at the text, it looks like we need to clarify that either an = error is returned or just an acceptance when maxEvents is 0. >=20 >=20 >=20 > Some participants indicated a desire to keep acknowledgement threads = separate from SET polling threads. Others wanted to be able to do both = at the same time. >=20 > Understood. >=20 > =20 >>=20 >> The current spec is at: >> https://tools.ietf.org/html/draft-ietf-secevent-delivery-01 = >>=20 >> I am happy to send pull requests for all these changes. Let me know. >>=20 >> Thanks, >> Marius >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65ea= pI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3Dne_ktq-vH7-ENPz= 2hHpvEBD9gZ8NVol5ZAKe9EeHvu8&s=3DuhRVJB8aZnVZHEY_MgIwN8ZjrBDaxt7YDmif4wyv6= jg&e=3D = --Apple-Mail=_C12AB9D4-0C00-4952-9AEB-CF9FA1148666 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Inline
Phil

Oracle Corporation, Identity Cloud = Services Architect
@independentid
www.independentid.com
phil.hunt@oracle.com

On Mar 2, 2018, at 4:00 PM, Marius Scurtescu <mscurtescu@google.com> wrote:

On Fri, = Mar 2, 2018 at 11:55 AM, Phil Hunt <phil.hunt@oracle.com> wrote:
Marius,

Thanks.

Item 1 and 2 look reasonable.

Sounds good.

 

for Item 3, 4, I think the group should = review. See below.

I also commented inline.

 

Given the submission deadline is = Monday, it would be good to wait group confirmation of your = proposals.

What that does mean in practical terms? = If no one has objections we can go ahead? By when?
 

Phil

Oracle Corporation, Identity Cloud = Services Architect
@independentid
www.independentid.com
phil.hunt@oracle.com
=

On Mar 2, 2018, at 10:30 AM, Marius Scurtescu <mscurtescu@google.com> = wrote:

I = have a few other suggestions:

1. In section 1.2 we = could drop the definition of Identity Provider and Relying Party. I = don't think these are necessary in this spec.

2. In section 2.1, the = description of the PUSH delivery mode states that the response must = contain "Content-Type: application/json". I think that is the case only = for error responses, I think on success no Content-Type is needed at = all.

3. In section 2.2, it = is stated that "the Event Receiver SHALL indicate an HTTP Status 400 = error with an error code as described in Section 2.4". I think that some = error codes should be matched by other 4xx codes (for example 401 and = 403). I think it would be useful to list all the possible error codes = and corresponding HTTP Status codes in this section and not refer to = 2.4,

<PH>The 4xx messages are assumed by the = HTTP RFCs while the errors in sec 2.4 related to errors around jwt = processing. We can call out specific 4xx errors that are likely to = occur, but I find that people then have issues wondering if they can = ever use the complete set of error conditions from = RFC7231. 

Would people find it useful to clarify or give examples of = how 7231 errors might occur?

I=E2=80=99m not sure which of the sec = 2.4 error codes could be matched with 401 or 403. These are mostly JWT = error conditions. Can you = elaborate?

I think jwtAud and jwtIss = should be 403 and not = 400.

<PH>
jwtAud and jwtIss are issues with = the payload.  403 indicates the wrong authorization credential was = used. E.g. a bad authorization header.

It is important to distinguish between an http = authorization header and a malformed SET.

setType and dup may also = need something else than = 400.

<PH>
I think dup is no longer needed as = we changed language to allow recovery.

setType - We should maybe update the terminology = to setEventUri indicating the receiver is refusing a specific event = type.

406 is the closest, yet that = code is about media types not being acceptable.  406 can occur if = someone requests application/xml for example.




4. In section 2.3.1, = the description of maxEvents, at the very end. A conflict between zero = request events and returnImmediately is described and the later should = be ignored. I think this should not be a silent ignore but an error = condition,
<PH>The value of 0 = is used to allow a poller to acknowledge previously received SETs = without having to process or wait for new events. Thus returnImmediately = is assumed. Thus the value of returnImmediately is = ignored.

Right, but to me with 0 and = returnImmediately present the request is invalid and I don't think = that returnImmediately should be simply = ignored 
<PH>
See section 2.3.3, in particular acknowledge only (2.3.3.2). =  =E2=80=9CmaxEvents=E2=80=9D:0 is what makes a request ack only. It = can be expressed in a more obvious way, but I believe the discussion was = this was simpler overall.

returnImmediately:true in the case of 2.3.3.2 is = redundant. It isn=E2=80=99t an error because control always returns = immediately.  returnImmediately:false would however would be an = error because there is nothing to return in section = 2.3.3.2.

Looking at the text, it = looks like we need to clarify that either an error is returned or just = an acceptance when maxEvents is 0.





Some participants = indicated a desire to keep acknowledgement threads separate from SET = polling threads.  Others wanted to be able to do both at the same = time.

Understood.

 

The = current spec is at:
https://tools.ietf.org/html/draft-ietf-secevent-delivery-01

I am happy to send pull = requests for all these changes. Let me know.

Thanks,
Marius
_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3Dne_ktq-vH7-ENPz2hHpvEBD9gZ8NVol5ZAKe9EeHvu8&s=3DuhRVJB8aZnVZHEY_MgIwN8ZjrBDaxt7YDmif4wyv6jg&e=3D

= --Apple-Mail=_C12AB9D4-0C00-4952-9AEB-CF9FA1148666-- From nobody Sat Mar 3 04:15:54 2018 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 19CD7129515 for ; Sat, 3 Mar 2018 04:15:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTCyLUYP537z for ; Sat, 3 Mar 2018 04:15:49 -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 E24BC12778E for ; Sat, 3 Mar 2018 04:15:48 -0800 (PST) X-AuditID: 12074424-9f1ff700000069d2-b9-5a9a91f0fe4b 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 dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 48.0B.27090.1F19A9A5; Sat, 3 Mar 2018 07:15:46 -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 w23CFdxV031904; Sat, 3 Mar 2018 07:15:41 -0500 Received: from [192.168.1.3] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w23CFapj012993 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 3 Mar 2018 07:15:38 -0500 To: "Richard Backman, Annabelle" , Mike Jones , Phil Hunt Cc: Yaron Sheffer , SecEvent References: <6e8afb70-3e6b-0ea5-7749-442c1c2d4c41@gmail.com> <49FAC72F-48E7-4B4C-8ACD-1259DADFE8FC@amazon.com> <847751A4-FF04-407E-9B2D-BB733CB9A1A0@oracle.com> <3B339ACB-8386-46F9-8795-278442BA4F06@amazon.com> <4D723055-D4CD-4418-AF9B-5E20EA9DCC9C@amazon.com> From: Justin Richer Message-ID: <2ee87285-fb49-64b9-c161-fc4dd6c880b2@mit.edu> Date: Sat, 3 Mar 2018 07:15:27 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <4D723055-D4CD-4418-AF9B-5E20EA9DCC9C@amazon.com> Content-Type: multipart/alternative; boundary="------------A7C7C0E64C34907021C7F161" Content-Language: en-US X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMKsWRmVeSWpSXmKPExsUixG6novtp4qwogx2HrS06FnQzWeyd9onF YsH8RnaL9sccFqvuz2B3YPVYcaGL1WPnrLvsHkuW/GTyaN3xl93j49NbLAGsUVw2Kak5mWWp Rfp2CVwZtw87FTTcZa7YcLSdqYGxeRFTFyMHh4SAicTSeZpdjFwcQgKLmST2rD/JDOFsYJQ4 tXYjK4RzlUli/exmIIeTQ1hAW+LQhoWMIAkRgSmMErfuX2YHSTALuEs0LLrIBNFxlEXiZvcN sASbgKrE9DUtTCA2r4CVxNojG9lAbBYBFYnp5+cyg9iiAjESUz9uZIWoEZQ4OfMJC4jNKWAn 8fj0QqgFYRIv/+2FssUlbj2ZzzSBUWAWkpZZSMpmISmDsM0k5m1+yAxhy0s0b50NZHMA2WoS y1qVkIUXMLKvYpRNya3SzU3MzClOTdYtTk7My0st0jXXy80s0UtNKd3ECI4jF5UdjN093ocY BTgYlXh4HZJmRgmxJpYVV+YeYpTkYFIS5X36ECjEl5SfUpmRWJwRX1Sak1p8iFGCg1lJhPd1 0awoId6UxMqq1KJ8mJQ0B4uSOK+HiXaUkEB6YklqdmpqQWoRTFaGg0NJgtcRmC6EBItS01Mr 0jJzShDSTBycIMN5gIbvnwAyvLggMbc4Mx0if4rRkmPLo5dtzBwHwOSNF6/bmIVY8vLzUqXE eZNAGgRAGjJK8+BmgtKi+zo7i1eM4kAvCvP+BqniAaZUuKmvgBYyAS1kfzsDZGFJIkJKqoFx wtr5ro+TWWZU/1nbURK8UeJo/47zWU0Tlmw9OImxaYqZzfM9Stvc7vJW7vmqUybw8cK6OKsT NTHn/JY9/19ZImcrXnXxU0Ztdefyf4prFDjeiDUd9djsrhBc9GnS1/v+axLbxXP4bs1c0iB0 Yd2L75Nm3PnbONM8tu+x43zTh4cPx+/1XjB1ixJLcUaioRZzUXEiANykmllmAwAA Archived-At: Subject: Re: [Id-event] Doc shepherd review X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 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, 03 Mar 2018 12:15:52 -0000 This is a multi-part message in MIME format. --------------A7C7C0E64C34907021C7F161 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I'd prefer to keep "additional" here as well. On 3/2/2018 5:53 PM, Richard Backman, Annabelle wrote: > > I like the addition of “single- andâ€. +1 > > I think “additional†is fair, given that they would be additional > instructions on top of the processing instructions defined within SET, > but I’m fine with taking it out and going with your text. > > -- > > Annabelle Richard Backman > > Amazon – Identity Services > > *From: *Id-event on behalf of Mike Jones > > *Date: *Friday, March 2, 2018 at 2:40 PM > *To: *"Richard Backman, Annabelle" , Phil Hunt > > *Cc: *Yaron Sheffer , SecEvent > *Subject: *Re: [Id-event] Doc shepherd review > > That’s closer. I find the word “additional†somewhat prejudicial, > however. How about this more neutral language? > > Among the syntax and semantics of SETs that a profiling specification > may define is whether the value of the “events†claim may contain > multiple members, and *what* processing instructions are *employed in > the single- and multiple-valued cases* for SETs conforming to that > profile. > > -- Mike > > *From:* Richard Backman, Annabelle > *Sent:* Friday, March 2, 2018 2:30 PM > *To:* Phil Hunt > *Cc:* Mike Jones ; Yaron Sheffer > ; SecEvent > *Subject:* Re: [Id-event] Doc shepherd review > > How about: > > Change this line > > to: > > Among the syntax and semantics of SETs that *a profiling specification > may* define is whether *the value of the events claim may contain > multiple members, and any additional processing instructions required > when multiple members are present in* SETs conforming to *that profile*. > > I think this is a clearer, more precise description of what it is > profile authors need to consider. It also fits better with the > subsequent examples, which present different rules for processing > multi-event SETs. > > -- > > Annabelle Richard Backman > > Amazon – Identity Services > > *From: *Phil Hunt > > *Date: *Friday, March 2, 2018 at 2:12 PM > *To: *"Richard Backman, Annabelle" > > *Cc: *Mike Jones >, Yaron Sheffer > >, SecEvent > > > *Subject: *Re: [Id-event] Doc shepherd review > > Annabelle, > > Apologies, but “significance of this case†does not seem to add > actionable information or aid in understanding. Also "if any†seems > unclear. > > Can you propose something else (with before and after text)? > > Thanks, > > Phil > > Oracle Corporation, Identity Cloud Services Architect > > @independentid > > www.independentid.com > > phil.hunt@oracle.com > > On Mar 1, 2018, at 11:32 AM, Richard Backman, Annabelle > > wrote: > > “…whether and how multiple members of the JSON object that is the > value of the events claim are used for SETs conforming to those > profiles.†> > The “whether and how†construction condenses this statement, but I > think it makes it harder to understand. How about: > > “…whether the value of the events claim may contain multiple > members, and the significance of this case if any for SETs > conforming to those profiles.†> > -- > > Annabelle Richard Backman > > Amazon – Identity Services > > *From:*Id-event > on behalf of Mike Jones > > > *Date:*Wednesday, February 28, 2018 at 5:16 PM > *To:*Yaron Sheffer > > *Cc:*SecEvent >, Phil > Hunt > > *Subject:*Re: [Id-event] Doc shepherd review > > Yaron, the edits > inhttps://github.com/independentid/Identity-Events/pull/11/commits/e27a2696f707107ec85a994844c6cbe2283356ecaddress > your review comments. > > -- Mike > > *From:*Id-event > >*On > Behalf Of*Mike Jones > *Sent:*Wednesday, February 28, 2018 3:46 PM > *To:*Phil Hunt > >; Yaron Sheffer > > > *Cc:*SecEvent > > *Subject:*Re: [Id-event] Doc shepherd review > > Phil is correct.  The “txn†claim is intentionally usable with any > JWT and not specific to SETs. This just happens to be the spec to > define it and add it to the IANA JWT Claims registry. > > Yaron, I plan to tweak your language “SETs serve to exchange > information about identity-related events†because the charter is > about security events, only some of which are identity events.  We > shouldn’t narrow the scope of applicability beyond what’s intended. > > -- Mike > > *From:*Id-event > >*On > Behalf Of*Phil Hunt > *Sent:*Wednesday, February 28, 2018 3:35 PM > *To:*Yaron Sheffer > > > *Cc:*SecEvent > > *Subject:*Re: [Id-event] Doc shepherd review > > Yaron, > > Thanks for the comments, will add to the next update. > > Mike has added some other minor editorial fixes for consistency > with JWT etc which I believe the group discussed. > > A couple questions inline… > > Phil > > Oracle Corporation, Identity Cloud Services Architect > > @independentid > > www.independentid.com > > phil.hunt@oracle.com > > On Feb 28, 2018, at 3:27 PM, Yaron Sheffer > > wrote: > > Hi, > > I will be document shepherd for the SET spec. As such, I just > reread it once again, and I think it is in very good shape. > Here are my (mostly editorial) comments. > > - Abstract: please add the following to clarify, e.g. after > the first sentence: SETs serve to exchange information about > identity-related events. > - A security subject MAY be permanent - this is descriptive > text, please change "MAY" to "may". > - "SETs have no capability for error signaling to ensure the > validation of a received SET" - SETs are a format, so it is a > higher level protocol that may or may not signal errors. I > suggest to remove this sentence. > - "has occurred about a Subject." Should this be "has occurred > to a Subjectâ€? > > I will re-read. I think what the spec is trying to say is to or > related to. Meaning the even is directly related to the subject > but not necessarily to the subject.  I will review and suggest > some text. > > - 2.2: for readability, please include the full names of the > claims ("Issuer", "JWT ID" etc.). > - IMO the distinction between JWTs and SETs with regard to the > need to use "exp" is not convincing. I suggest we refer to > Sec. 4.5 for a better rationale why we make this claim NOT > RECOMMENDED rather than OPTIONAL as in RFC 7519. > - txn: this paragraph should speak about SETs rather than JWTs. > > I will defer to Mike, but I believe he suggested to have this > registered for general JWT use. > > - "to provide integrity, confidentiality, and issuer > validation", should be "issuer authenticity". > - "Whether and how multiple "events" values are used": the > reader who has not been following our discussions may not > understand what this means, maybe we should say in > parentheses, (i.e. multiple members in the "events" JSON object). > - "MUST support TLS 1.2" - add "or a higher version". > - 4.5: intentionally - I think we mean "maliciously". > - 6.1.1: "Security Event URI" - this description is incorrect, > should probably be "Security Event information" or something > similarly vague. > - RFC 7617 - unused ref. Similarly saml-core. > > Thanks, >     Yaron > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=F-QmvDFTApiQ6Wjga0U9ssZq_QMLIYG_XiU2g5JO0Ug&s=nLwDZhuM4B_ZVxX3dGEafZgxYOCRDGLBAPTA7IJ3YUo&e= > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=2HLT4d2twCFYgn2XHeUK2tHsbk1_pzDH38mvNQNamnQ&s=Za82EBppu_mOdrdvDQwJumc9CpxIeunBFdeuGQpSW4A&e= > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event --------------A7C7C0E64C34907021C7F161 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I'd prefer to keep "additional" here as well.


On 3/2/2018 5:53 PM, Richard Backman, Annabelle wrote:

I like the addition of “single- andâ€. +1

 

I think “additional†is fair, given that they would be additional instructions on top of the processing instructions defined within SET, but I’m fine with taking it out and going with your text.

 

-- 

Annabelle Richard Backman

Amazon – Identity Services

 

From: Id-event <id-event-bounces@ietf.org> on behalf of Mike Jones <Michael.Jones@microsoft.com>
Date: Friday, March 2, 2018 at 2:40 PM
To: "Richard Backman, Annabelle" <richanna@amazon.com>, Phil Hunt <phil.hunt@oracle.com>
Cc: Yaron Sheffer <yaronf.ietf@gmail.com>, SecEvent <id-event@ietf.org>
Subject: Re: [Id-event] Doc shepherd review

 

That’s closer.  I find the word “additional†somewhat prejudicial, however.  How about this more neutral language?

 

Among the syntax and semantics of SETs that a profiling specification may define is whether the value of the “events†claim may contain multiple members, and what processing instructions are employed in the single- and multiple-valued cases for SETs conforming to that profile.

 

                                                                -- Mike

 

From: Richard Backman, Annabelle <richanna@amazon.com>
Sent: Friday, March 2, 2018 2:30 PM
To: Phil Hunt <phil.hunt@oracle.com>
Cc: Mike Jones <Michael.Jones@microsoft.com>; Yaron Sheffer <yaronf.ietf@gmail.com>; SecEvent <id-event@ietf.org>
Subject: Re: [Id-event] Doc shepherd review

 

How about:

 

Change this line to:

 

Among the syntax and semantics of SETs that a profiling specification may define is whether the value of the events claim may contain multiple members, and any additional processing instructions required when multiple members are present in SETs conforming to that profile.

 

I think this is a clearer, more precise description of what it is profile authors need to consider. It also fits better with the subsequent examples, which present different rules for processing multi-event SETs.

 

-- 

Annabelle Richard Backman

Amazon – Identity Services

 

From: Phil Hunt <phil.hunt@oracle.com>
Date: Friday, March 2, 2018 at 2:12 PM
To: "Richard Backman, Annabelle" <richanna@amazon.com>
Cc: Mike Jones <Michael.Jones@microsoft.com>, Yaron Sheffer <yaronf.ietf@gmail.com>, SecEvent <id-event@ietf.org>
Subject: Re: [Id-event] Doc shepherd review

 

Annabelle,

 

Apologies, but “significance of this case†does not seem to add actionable information or aid in understanding. Also "if any†seems unclear.

 

Can you propose something else (with before and after text)?

 

Thanks,

 

Phil

 

Oracle Corporation, Identity Cloud Services Architect

@independentid

phil.hunt@oracle.com

 

On Mar 1, 2018, at 11:32 AM, Richard Backman, Annabelle <richanna@amazon.com> wrote:

 

“…whether and how multiple members of the JSON object that is the value of the events claim are used for SETs conforming to those profiles.â€

 

The “whether and how†construction condenses this statement, but I think it makes it harder to understand. How about:

 

“…whether the value of the events claim may contain multiple members, and the significance of this case if any for SETs conforming to those profiles.â€

 

-- 

Annabelle Richard Backman

Amazon – Identity Services

 

From: Id-event <id-event-bounces@ietf.org> on behalf of Mike Jones <Michael.Jones@microsoft.com>
Date: Wednesday, February 28, 2018 at 5:16 PM
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Cc: SecEvent <id-event@ietf.org>, Phil Hunt <phil.hunt@oracle.com>
Subject: Re: [Id-event] Doc shepherd review

 

 

                                                                -- Mike

 

From: Id-event <id-event-bounces@ietf.org> On Behalf Of Mike Jones
Sent: Wednesday, February 28, 2018 3:46 PM
To: Phil Hunt <phil.hunt@oracle.com>; Yaron Sheffer <yaronf.ietf@gmail.com>
Cc: SecEvent <id-event@ietf.org>
Subject: Re: [Id-event] Doc shepherd review

 

Phil is correct.  The “txn†claim is intentionally usable with any JWT and not specific to SETs. This just happens to be the spec to define it and add it to the IANA JWT Claims registry.

 

Yaron, I plan to tweak your language “SETs serve to exchange information about identity-related events†because the charter is about security events, only some of which are identity events.  We shouldn’t narrow the scope of applicability beyond what’s intended.

 

                                                                -- Mike

 

From: Id-event <id-event-bounces@ietf.org> On Behalf Of Phil Hunt
Sent: Wednesday, February 28, 2018 3:35 PM
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Cc: SecEvent <id-event@ietf.org>
Subject: Re: [Id-event] Doc shepherd review

 

Yaron,

 

Thanks for the comments, will add to the next update.

 

Mike has added some other minor editorial fixes for consistency with JWT etc which I believe the group discussed.

 

A couple questions inline…

 

Phil

 

Oracle Corporation, Identity Cloud Services Architect

@independentid

 

On Feb 28, 2018, at 3:27 PM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

 

Hi,

I will be document shepherd for the SET spec. As such, I just reread it once again, and I think it is in very good shape. Here are my (mostly editorial) comments.

- Abstract: please add the following to clarify, e.g. after the first sentence: SETs serve to exchange information about identity-related events.
- A security subject MAY be permanent - this is descriptive text, please change "MAY" to "may".
- "SETs have no capability for error signaling to ensure the validation of a received SET" - SETs are a format, so it is a higher level protocol that may or may not signal errors. I suggest to remove this sentence.
- "has occurred about a Subject." Should this be "has occurred to a Subject�

 

I will re-read. I think what the spec is trying to say is to or related to. Meaning the even is directly related to the subject but not necessarily to the subject.  I will review and suggest some text.

 

- 2.2: for readability, please include the full names of the claims ("Issuer", "JWT ID" etc.).
- IMO the distinction between JWTs and SETs with regard to the need to use "exp" is not convincing. I suggest we refer to Sec. 4.5 for a better rationale why we make this claim NOT RECOMMENDED rather than OPTIONAL as in RFC 7519.
- txn: this paragraph should speak about SETs rather than JWTs.

 

I will defer to Mike, but I believe he suggested to have this registered for general JWT use. 

 

- "to provide integrity, confidentiality, and issuer validation", should be "issuer authenticity".
- "Whether and how multiple "events" values are used": the reader who has not been following our discussions may not understand what this means, maybe we should say in parentheses, (i.e. multiple members in the "events" JSON object).
- "MUST support TLS 1.2" - add "or a higher version".
- 4.5: intentionally - I think we mean "maliciously".
- 6.1.1: "Security Event URI" - this description is incorrect, should probably be "Security Event information" or something similarly vague.
- RFC 7617 - unused ref. Similarly saml-core.

Thanks,
    Yaron

_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=F-QmvDFTApiQ6Wjga0U9ssZq_QMLIYG_XiU2g5JO0Ug&s=nLwDZhuM4B_ZVxX3dGEafZgxYOCRDGLBAPTA7IJ3YUo&e=

 

_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=2HLT4d2twCFYgn2XHeUK2tHsbk1_pzDH38mvNQNamnQ&s=Za82EBppu_mOdrdvDQwJumc9CpxIeunBFdeuGQpSW4A&e=

 



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

--------------A7C7C0E64C34907021C7F161-- From nobody Sat Mar 3 04:41:14 2018 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 500C612D7EC for ; Sat, 3 Mar 2018 04:41:13 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LifbgtwlrXil for ; Sat, 3 Mar 2018 04:41:11 -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 33597129515 for ; Sat, 3 Mar 2018 04:41:11 -0800 (PST) Received: by mail-wm0-x235.google.com with SMTP id t74so7839676wme.3 for ; Sat, 03 Mar 2018 04:41:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=mvqtdFL3oy19VVptf/N3Z/+lr+Pi9BZ+++lFMXiUCuA=; b=X0WqiSY4k15vMkaPxeSyZNPhejyishhbXZGYWV2K6KrYRgJMMyzlg33xVjbyPTl7a9 cYh+C4yapsQpYtqaXgD6LlpubzoKh6FrhwIFzJ7k61K9UkmLOVBKAyMymjhiLDWAwS8w XcZSImM0Awe3nVyriyKOZn/HhPcRJe7s8+kzk9wwQzC39Pv5ESp2+UrOiAK1Muxe2bTF isZFaKsRDezbLV93WUM3dl38VyznZ1P97luQKoxX52cEVV7eXHGmcJLWuekefHBD7028 0SsV8MOJkT8DJGLfNCNRbgQU+PvRo4JjyrcsCumOm21cAWJCXaSD1Bcd3VB2aO2Ac/Vm gn1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=mvqtdFL3oy19VVptf/N3Z/+lr+Pi9BZ+++lFMXiUCuA=; b=g4sMhqJLZXBoNUwJXkGOEcBby/qcGCkIX9y4re0wvqd5+PfU/5JhUwmN29+MUs5Yqz 4ffxXmJbJXrMDeNQQh7YqmVtoSBIbFeQELKyvH0ra6hZlm/52BXZg0lyXKOheYFJW/U9 PFcLjV3miw8ogPlWI1rBJgbitCdhmQqxI1hYTOH/Ez6tabqQeX9RpWVZM4P4lVC2Rg46 9SY2KLitxarW8BMx/ElfH5KbnJjef+X0Ko7p4BbJM+zaVnrzh8RBi5tf3Vlta2TO7gtG VcfmRmmqR7FLhYfBLKqtqzT8UFuAB6eJw4lI2CHGrqm18RPBifMc3mc3Aedy0FSnXGpW rFYQ== X-Gm-Message-State: AElRT7GREj8SErjGW/vPGZpG+oxC4A9j+gREY2tAFn5hIGPaRJHPpnaj fY+xteoRnY0M/YPQzcfcnmvvHJ5r X-Google-Smtp-Source: AG47ELucd6SBBDYBserN9ypWvOWGet96Pm3fxSKv2PtNA/2FmPcH35nAL2Fo1PmNItTV9kM60SF1IA== X-Received: by 10.28.48.11 with SMTP id w11mr4164885wmw.88.1520080869346; Sat, 03 Mar 2018 04:41:09 -0800 (PST) Received: from [10.0.0.149] (bzq-109-65-61-134.red.bezeqint.net. [109.65.61.134]) by smtp.gmail.com with ESMTPSA id i12sm10388118wrc.28.2018.03.03.04.41.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 03 Mar 2018 04:41:06 -0800 (PST) To: Marius Scurtescu , Phil Hunt Cc: ID Events Mailing List References: <57C95B37-57A5-440E-9A4C-2D32B3677B9F@oracle.com> From: Yaron Sheffer Message-ID: <84b10c00-be5c-0ce4-e70c-ee11a8380b09@gmail.com> Date: Sat, 3 Mar 2018 14:41:04 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Id-event] small changes to draft-ietf-secevent-delivery X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 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, 03 Mar 2018 12:41:13 -0000 Marius, given the timeline, please make whatever changes you see fit, and present them in London with the understanding that the group might ask you to backtrack. Thanks, Yaron On 03/03/18 02:00, Marius Scurtescu wrote: > On Fri, Mar 2, 2018 at 11:55 AM, Phil Hunt > wrote: > > Marius, > > Thanks. > > Item 1 and 2 look reasonable. > > > Sounds good. > > > for Item 3, 4, I think the group should review. See below. > > > I also commented inline. > > > Given the submission deadline is Monday, it would be good to wait > group confirmation of your proposals. > > > What that does mean in practical terms? If no one has objections we can > go ahead? By when? > > > Phil > > Oracle Corporation, Identity Cloud Services Architect > @independentid > www.independentid.com > phil.hunt@oracle.com > >> On Mar 2, 2018, at 10:30 AM, Marius Scurtescu >> > wrote: >> >> I have a few other suggestions: >> >> 1. In section 1.2 we could drop the definition of Identity >> Provider and Relying Party. I don't think these are necessary in >> this spec. >> >> 2. In section 2.1, the description of the PUSH delivery mode >> states that the response must contain "Content-Type: >> application/json". I think that is the case only for error >> responses, I think on success no Content-Type is needed at all. >> >> 3. In section 2.2, it is stated that "the Event Receiver SHALL >> indicate an HTTP Status 400 error with an error code as described >> in Section 2.4". I think that some error codes should be matched >> by other 4xx codes (for example 401 and 403). I think it would be >> useful to list all the possible error codes and corresponding HTTP >> Status codes in this section and not refer to 2.4, > > The 4xx messages are assumed by the HTTP RFCs while the errors > in sec 2.4 related to errors around jwt processing. We can call out > specific 4xx errors that are likely to occur, but I find that people > then have issues wondering if they can ever use the complete set of > error conditions from RFC7231. > > Would people find it useful to clarify or give examples of how 7231 > errors might occur? > > I’m not sure which of the sec 2.4 error codes could be matched with > 401 or 403. These are mostly JWT error conditions. Can you elaborate? > > > I think jwtAud and jwtIss should be 403 and not 400. > > setType and dup may also need something else than 400. > > >> >> 4. In section 2.3.1, the description of maxEvents, at the very >> end. A conflict between zero request events and returnImmediately >> is described and the later should be ignored. I think this should >> not be a silent ignore but an error condition, > The value of 0 is used to allow a poller to acknowledge > previously received SETs without having to process or wait for new > events. Thus returnImmediately is assumed. Thus the value of > returnImmediately is ignored. > > > Right, but to me with 0 and returnImmediately present the request is > invalid and I don't think that returnImmediately should be simply ignored > > > > Some participants indicated a desire to keep acknowledgement threads > separate from SET polling threads.  Others wanted to be able to do > both at the same time. > > > Understood. > >> >> The current spec is at: >> https://tools.ietf.org/html/draft-ietf-secevent-delivery-01 >> >> >> I am happy to send pull requests for all these changes. Let me know. >> >> Thanks, >> Marius >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=ne_ktq-vH7-ENPz2hHpvEBD9gZ8NVol5ZAKe9EeHvu8&s=uhRVJB8aZnVZHEY_MgIwN8ZjrBDaxt7YDmif4wyv6jg&e= >> > > > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > From nobody Sun Mar 4 18:28:11 2018 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 9A0D812D86E for ; Sun, 4 Mar 2018 18:28:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.72 X-Spam-Level: X-Spam-Status: No, score=-0.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 42Qr4NfP5FqP for ; Sun, 4 Mar 2018 18:28:02 -0800 (PST) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CA2E128959 for ; Sun, 4 Mar 2018 18:28:00 -0800 (PST) Received: by mail-vk0-x22a.google.com with SMTP id x125so8867090vkc.13 for ; Sun, 04 Mar 2018 18:28:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=w3Wf/gbmuB7ryEexnuDKXugYR7Zz74pYm33RXkdXYBc=; b=UeEE1kKkHmAvxO4+I6WkzYZ+oavbibZrFW60tiAYLJP4L/pAzVBfyp/zjF+muvRsw6 u4b943UC+x/gvnWPDQycWdcYL2QmPk6L2q7XDq6fqEJOu96xWN59PCM+qCc7I24FsfdV UwkJf2vyKCwq7NvvkEUD5DppmeSPNMFI5dFrlk4/3Mh17YNd6Qw3Nc5jGkaqbzoMeTSF XQPtx4UXVk7+0hHHJ9LipxKzuo2wVJxvNGHqPzU7NTlVmYQiLGiBVKBCKu1w1LYi0Plx n4Le1xwLINHvwpgwB7j9W4PeAeZ4qp8+/DgbLViFSpZ6UBDFwkeT/9aO8+WTYd+tdu2W WSjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=w3Wf/gbmuB7ryEexnuDKXugYR7Zz74pYm33RXkdXYBc=; b=myZFwviYy2LXxsUctkWJxRRGHDLNleOiSKQ1TafG0C0NDlcDNIQFkauyHkzms0Hhdb IO9ZCpLXtsBNyNND2E7p6dElmZzDPCpthkWwbXoQ/u35xiMKOc8C+zIDPSzfzqLKB1r9 R3tUJ5jTvnjVW9vLpIQ0oTbe6L4Q9k06tz3NnD7CvLMhmTQ45FVqhHz+/RIVOzd/2/8I HWDXv32/0dfCrBynXHQWx+K/Mr3Fx6lEfuEJmsV47916pCxasoUqDPEpf+TgwkzGD9wi OMQ+8RUhWvXe9Ml66e6P9hzEiVDXFQUKSNWb9sQGoBN3NN4vkW3CL/PN1VBPoxwHM70m WRiw== X-Gm-Message-State: APf1xPDYhN0gHB57jTCZWG34e7XpkJsW907SRQIl3sovr/8UU1b9c1Lm Hs0yu2hE5nD5Zn0MEPbn7JqlPVFgizbe6z7eCsyNjA== X-Google-Smtp-Source: AG47ELvwK/eba+o49Hwyx2W6ec5rNXbjtbTXA1LIY5WP422VFG1OeMHPVGshdArEXkguvgJeF71QHjdvPzY4gio6ZR0= X-Received: by 10.31.156.71 with SMTP id f68mr8861636vke.129.1520216878945; Sun, 04 Mar 2018 18:27:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.94.88 with HTTP; Sun, 4 Mar 2018 18:27:38 -0800 (PST) In-Reply-To: <0D2EA133-3E7B-497D-9364-C919D4FCB925@oracle.com> References: <57C95B37-57A5-440E-9A4C-2D32B3677B9F@oracle.com> <0D2EA133-3E7B-497D-9364-C919D4FCB925@oracle.com> From: Marius Scurtescu Date: Sun, 4 Mar 2018 18:27:38 -0800 Message-ID: To: Phil Hunt Cc: ID Events Mailing List Content-Type: multipart/alternative; boundary="001a1141bffc0de0240566a1139b" Archived-At: Subject: Re: [Id-event] small changes to draft-ietf-secevent-delivery X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 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 Mar 2018 02:28:10 -0000 --001a1141bffc0de0240566a1139b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Let's go with 1 and 2, sending a pull requests, and we can discuss more about 3 and 4. Comments inline. On Fri, Mar 2, 2018 at 4:23 PM, Phil Hunt wrote: > Inline > Phil > > Oracle Corporation, Identity Cloud Services Architect > @independentid > www.independentid.com > phil.hunt@oracle.com > > On Mar 2, 2018, at 4:00 PM, Marius Scurtescu > wrote: > > On Fri, Mar 2, 2018 at 11:55 AM, Phil Hunt wrote: > >> Marius, >> >> Thanks. >> >> Item 1 and 2 look reasonable. >> > > Sounds good. > > > >> >> for Item 3, 4, I think the group should review. See below. >> > > I also commented inline. > > > >> >> Given the submission deadline is Monday, it would be good to wait group >> confirmation of your proposals. >> > > What that does mean in practical terms? If no one has objections we can g= o > ahead? By when? > > >> >> Phil >> >> Oracle Corporation, Identity Cloud Services Architect >> @independentid >> www.independentid.com >> >> phil.hunt@oracle.com >> >> On Mar 2, 2018, at 10:30 AM, Marius Scurtescu >> wrote: >> >> I have a few other suggestions: >> >> 1. In section 1.2 we could drop the definition of Identity Provider and >> Relying Party. I don't think these are necessary in this spec. >> >> 2. In section 2.1, the description of the PUSH delivery mode states that >> the response must contain "Content-Type: application/json". I think that= is >> the case only for error responses, I think on success no Content-Type is >> needed at all. >> >> 3. In section 2.2, it is stated that "the Event Receiver SHALL indicate >> an HTTP Status 400 error with an error code as described in Section 2.4"= . I >> think that some error codes should be matched by other 4xx codes (for >> example 401 and 403). I think it would be useful to list all the possibl= e >> error codes and corresponding HTTP Status codes in this section and not >> refer to 2.4, >> >> >> The 4xx messages are assumed by the HTTP RFCs while the errors in se= c >> 2.4 related to errors around jwt processing. We can call out specific 4x= x >> errors that are likely to occur, but I find that people then have issues >> wondering if they can ever use the complete set of error conditions from >> RFC7231. >> >> Would people find it useful to clarify or give examples of how 7231 >> errors might occur? >> >> I=E2=80=99m not sure which of the sec 2.4 error codes could be matched w= ith 401 >> or 403. These are mostly JWT error conditions. Can you elaborate? >> > > I think jwtAud and jwtIss should be 403 and not 400. > > > > jwtAud and jwtIss are issues with the payload. 403 indicates the wrong > authorization credential was used. E.g. a bad authorization header. > > It is important to distinguish between an http authorization header and a > malformed SET. > I am not suggesting 401, but 403. The request is perfectly valid, but the iss or aud presented are not allowed to send events to this receiver. > setType and dup may also need something else than 400. > > > > I think dup is no longer needed as we changed language to allow recovery. > Maybe you are right, we can probably drop "dup". I don't see any value in it for a Transmitter. > > setType - We should maybe update the terminology to setEventUri indicatin= g > the receiver is refusing a specific event type. > > 406 is the closest, yet that code is about media types not being > acceptable. 406 can occur if someone requests application/xml for exampl= e. > setEventIdentifier? To go with the latest terminology in the SET spec. Even 403 might be a could status in this case. 406 seems to be related to the "Accept" header, and that's not the case here. 415? How about invalid "typ" claim in the SET header? 415? Also, how about 429 for too many requests? > > >> >> 4. In section 2.3.1, the description of maxEvents, at the very end. A >> conflict between zero request events and returnImmediately is described = and >> the later should be ignored. I think this should not be a silent ignore = but >> an error condition, >> >> The value of 0 is used to allow a poller to acknowledge previously >> received SETs without having to process or wait for new events. Thus >> returnImmediately is assumed. Thus the value of returnImmediately is >> ignored. >> > > Right, but to me with 0 and returnImmediately present the request is > invalid and I don't think that returnImmediately should be simply ignored > > > See section 2.3.3, in particular acknowledge only (2.3.3.2). > =E2=80=9CmaxEvents=E2=80=9D:0 is what makes a request ack only. It can b= e expressed in a > more obvious way, but I believe the discussion was this was simpler overa= ll. > > returnImmediately:true in the case of 2.3.3.2 is redundant. It isn=E2=80= =99t an > error because control always returns immediately. returnImmediately:fals= e > would however would be an error because there is nothing to return in > section 2.3.3.2. > > Looking at the text, it looks like we need to clarify that either an erro= r > is returned or just an acceptance when maxEvents is 0. > Agreed with all of the above. I was suggesting to return an error for maxEvents:0 and returnImmediately:false. > > > > > >> Some participants indicated a desire to keep acknowledgement threads >> separate from SET polling threads. Others wanted to be able to do both = at >> the same time. >> > > Understood. > > > >> >> The current spec is at: >> https://tools.ietf.org/html/draft-ietf-secevent-delivery-01 >> >> >> I am happy to send pull requests for all these changes. Let me know. >> >> Thanks, >> Marius >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.iet >> f.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHv >> lZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYq >> PkAI1aLcLN4KZNA&m=3Dne_ktq-vH7-ENPz2hHpvEBD9gZ8NVol5ZAKe9EeHvu >> 8&s=3DuhRVJB8aZnVZHEY_MgIwN8ZjrBDaxt7YDmif4wyv6jg&e=3D >> >> > --001a1141bffc0de0240566a1139b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Let&= #39;s go with 1 and 2, sending a pull requests, and we can discuss more abo= ut 3 and 4. Comments inline.

On Fri, Mar 2, 2018 at 4:23 PM, Phil Hunt <phil.hunt@oracle.com> = wrote:
Inline
Phil

Oracle = Corporation, Identity Cloud Services Architect
@independentid
phil.hunt@oracle.com

On Ma= r 2, 2018, at 4:00 PM, Marius Scurtescu <mscu= rtescu@google.com> wrote:

<= div class=3D"gmail_quote">On Fri, Mar 2, 2018 at 11:55 AM, Phil Hunt=C2=A0<phil.hunt@oracle.com>=C2=A0<= /span>wrote:
Marius,

Thanks.

Item 1 and 2 look reasonable.
=

Sounds good.

=C2=A0

for Item 3, 4, I think the group should revi= ew. See below.

I also com= mented inline.

=C2=A0
Given the submission deadline is Monday, it would be good to w= ait group confirmation of your proposals.

What that does mean in practical terms? If no one has obje= ctions we can go ahead? By when?
=C2=A0

Phil

Oracle Corporation, = Identity Cloud Services Architect
@independentid
phil.hunt@oracle.com

On Mar 2, 2018, at 10:= 30 AM, Marius Scurtescu <mscurtescu@google.co= m> wrote:

I have a few other suggestions:

1. In section 1.2 we could drop the definition of Identity Provider = and Relying Party. I don't think these are necessary in this spec.

2. In section 2.1, the description= of the PUSH delivery mode states that the response must contain "Cont= ent-Type: application/json". I think that is the case only for error r= esponses, I think on success no Content-Type is needed at all.

3. In section 2.2, it is stated that "= ;the Event Receiver SHALL indicate an HTTP Status 400 error with an error c= ode as described in Section 2.4". I think that some error codes should= be matched by other 4xx codes (for example 401 and 403). I think it would = be useful to list all the possible error codes and corresponding HTTP Statu= s codes in this section and not refer to 2.4,

<PH>The 4xx messages are assumed by the HTTP R= FCs while the errors in sec 2.4 related to errors around jwt processing. We= can call out specific 4xx errors that are likely to occur, but I find that= people then have issues wondering if they can ever use the complete set of= error conditions from RFC7231.=C2=A0

Would people= find it useful to clarify or give examples of how 7231 errors might occur?=

I=E2=80=99m not sure which of the sec 2.4 error c= odes could be matched with 401 or 403. These are mostly JWT error condition= s. Can you elaborate?

I think=C2=A0jwtAud and=C2=A0jwtIss should be 403 and not 400.

<PH>jwtAud and jwtIss are issues with the payload. =C2=A0403 indicates the wro= ng authorization credential was used. E.g. a bad authorization header.

It is important to distinguish between an http authori= zation header and a malformed SET.

<= div>I am not suggesting 401, but 403. The request is perfectly valid, but t= he iss or aud presented are not allowed to send events to this receiver.=C2= =A0

<= div style=3D"word-wrap:break-word">

setType and dup may also need something else = than 400.

<= div><PH>
I think dup is no longer needed as we changed language = to allow recovery.

Maybe you ar= e right, we can probably drop "dup". I don't see any value in= it for a Transmitter.

=C2=A0

setType - We should maybe update the terminology to setEven= tUri indicating the receiver is refusing a specific event type.
<= br>
406 is the closest, yet that code is about media types not be= ing acceptable. =C2=A0406 can occur if someone requests application/xml for= example.

setEventIdentifier? T= o go with the latest terminology in the SET spec.

= Even 403 might be a could status in this case. 406 seems to be related to t= he "Accept" header, and that's not the case here. 415?
<= div>
How about invalid "typ" claim in the SET heade= r?=C2=A0 415?

Also, how about 429 for too many req= uests?





4. In section 2.3.1, the = description of maxEvents, at the very end. A conflict between zero request = events and returnImmediately is described and the later should be ignored. = I think this should not be a silent ignore but an error condition,
<PH>The value of 0 is used to allow a po= ller to acknowledge previously received SETs without having to process or w= ait for new events. Thus returnImmediately is assumed. Thus the value of re= turnImmediately is ignored.

Right, but to me with 0 and returnImmediately present the request = is invalid and I don't think that=C2=A0returnImmediately should be simp= ly ignored=C2=A0
<PH>= ;
See section 2.3.3, in particular acknowledge only (2.3.3.2). = =C2=A0=E2=80=9CmaxEvents=E2=80=9D:0 is what makes a request ack only. It ca= n be expressed in a more obvious way, but I believe the discussion was this= was simpler overall.

returnImmediately:true in th= e case of 2.3.3.2 is redundant. It isn=E2=80=99t an error because control a= lways returns immediately. =C2=A0returnImmediately:false would however woul= d be an error because there is nothing to return in section 2.3.3.2.
<= div>
Looking at the text, it looks like we need to clarify th= at either an error is returned or just an acceptance when maxEvents is 0.

Agreed with all of the above. I = was suggesting to return an error for maxEvents:0 and=C2=A0returnImmediatel= y:false.=C2=A0

<= pre class=3D"gmail-m_7923753753194020498newpage" style=3D"font-size:13.3333= px;margin-top:0px;margin-bottom:0px">



Some participants indicated a desire to keep acknowledgement threads sepa= rate from SET polling threads.=C2=A0 Others wanted to be able to do both at= the same time.

Und= erstood.

=C2=A0

The current spec is at:
<= a href=3D"https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf= .org_html_draft-2Dietf-2Dsecevent-2Ddelivery-2D01&d=3DDwMFaQ&c=3DRo= P1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPp= uYqPkAI1aLcLN4KZNA&m=3Dne_ktq-vH7-ENPz2hHpvEBD9gZ8NVol5ZAKe9EeHvu8&= s=3DHlxm0ufeHaSgSiJeOwFFJrFyiarhtBVMckB9QCslj3Q&e=3D" class=3D"gmail-m_= 7923753753194020498gmail-cremed gmail-m_7923753753194020498cremed gmail-cre= med gmail-cremed cremed" target=3D"_blank">https://tools.ietf.org/html/draft-ietf-secevent-delivery-01

I am happy to= send pull requests for all these changes. Let me know.

<= /div>
Thanks,
Marius
=
_______________________________________________
Id-eve= nt mailing list
Id-event@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-= 3A__www.ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c= =3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWm= anqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3Dne_ktq-vH7-ENPz2hHpvEBD= 9gZ8NVol5ZAKe9EeHvu8&s=3DuhRVJB8aZnVZHEY_MgIwN8ZjrBDaxt7YDmif= 4wyv6jg&e=3D

<= /div>
--001a1141bffc0de0240566a1139b-- From nobody Sun Mar 4 18:29:54 2018 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 E77D4126C19 for ; Sun, 4 Mar 2018 18:29:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 raIA5hfmN6mt for ; Sun, 4 Mar 2018 18:29:44 -0800 (PST) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2CF612D80F for ; Sun, 4 Mar 2018 18:29:44 -0800 (PST) Received: by mail-vk0-x22d.google.com with SMTP id k187so8868256vke.12 for ; Sun, 04 Mar 2018 18:29:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mxgCt2K7Q0YQIBgbGMl2HspWa7JmgODd5dnaous22o4=; b=X7jSuudi0AipyxA6CbRoPUfnkyEjqVnNCDRUI9ZFnGPDCfaAsj1JwpECTkI+DqJrYP pKOhFTQKgAV9Tc9uc8VM8hiaTYtOBtX1tCc4rNVMVprfYj/LN5oEmiz+lZ3VgxIKqK0K Q6JsxikLBawdZq4/0BtvJ7RGs/DzQ5pg//AkUxMFaSX7k/0MXAjjfPS29MfGaq1iH+hV 14PrhRKmzSDhYdmlYiVjoyPcErzdpbsTqzQiXz97ZRIiiF4WQKufHyP1n993Rfts8EhN Z+4zllqbqg09T4bXHrTHOeYbm5udRhHLIZInh9wl0CY5ijl9CyK/c2hyg/yLF6D/Utex 7oFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mxgCt2K7Q0YQIBgbGMl2HspWa7JmgODd5dnaous22o4=; b=jEc8SrFC9qnPNjj9ITimj9qLvqNZdd5LYAYZDbiAsWtXVhw3i0qRby/Ys5X8yRbVnh JYBGAqOkE8IU8xAZxaCthumn8rt5UZJJr+VcwTtEyfSI4/BSaPjConLryq1SkXsYjtUj Wgso+kw0BmnTNqm1RfTK+rU3HsWoFIldGCjYHb/jAVMShdtuqTdcjhAb4GnLDHxKqeax sZBmYu9M5q03UFp/Embfqjt7GgpNJquz4gYHYOc10H1LX5uiP+hrqCZho03t/EsDwZ+/ M0DPidPDPj9EcdO+1aeX+CgJ3aNj5WHZkFh7DrGkKoqXWl900srdsRgzSZWak9LCnowO 7kAQ== X-Gm-Message-State: APf1xPDvq4OJfWZkAjdxsWZiJDOu/+AfnZF2oQVVaMAuVT301pcwF9az wetymHieovIyaQhMD+Y+7C9U+IraLiKdGp3MaEvSqg== X-Google-Smtp-Source: AG47ELsyLEb0qFUDYcKFGAQPtwTUMN0Xm0FKRQTS76/iHhLL+WXNpDyBJWpKN3xK33rUw35650uw78trRe6N1mtNfjo= X-Received: by 10.31.254.199 with SMTP id l190mr8973571vki.17.1520216983358; Sun, 04 Mar 2018 18:29:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.94.88 with HTTP; Sun, 4 Mar 2018 18:29:22 -0800 (PST) In-Reply-To: <84b10c00-be5c-0ce4-e70c-ee11a8380b09@gmail.com> References: <57C95B37-57A5-440E-9A4C-2D32B3677B9F@oracle.com> <84b10c00-be5c-0ce4-e70c-ee11a8380b09@gmail.com> From: Marius Scurtescu Date: Sun, 4 Mar 2018 18:29:22 -0800 Message-ID: To: Yaron Sheffer Cc: Phil Hunt , ID Events Mailing List Content-Type: multipart/alternative; boundary="94eb2c14b19646f3590566a119ed" Archived-At: Subject: Re: [Id-event] small changes to draft-ietf-secevent-delivery X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 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 Mar 2018 02:29:53 -0000 --94eb2c14b19646f3590566a119ed Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Mar 3, 2018 at 4:41 AM, Yaron Sheffer wrote= : > Marius, > > given the timeline, please make whatever changes you see fit, and present > them in London with the understanding that the group might ask you to > backtrack. > I will not be in London, unfortunately. These are minor changes, but feedback from the group would be great. Thanks, Marius > > Thanks, > Yaron > > On 03/03/18 02:00, Marius Scurtescu wrote: > >> On Fri, Mar 2, 2018 at 11:55 AM, Phil Hunt > phil.hunt@oracle.com>> wrote: >> >> Marius, >> >> Thanks. >> >> Item 1 and 2 look reasonable. >> >> >> Sounds good. >> >> >> for Item 3, 4, I think the group should review. See below. >> >> >> I also commented inline. >> >> >> Given the submission deadline is Monday, it would be good to wait >> group confirmation of your proposals. >> >> >> What that does mean in practical terms? If no one has objections we can >> go ahead? By when? >> >> >> Phil >> >> Oracle Corporation, Identity Cloud Services Architect >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> >> On Mar 2, 2018, at 10:30 AM, Marius Scurtescu >>> > wrote: >>> >>> I have a few other suggestions: >>> >>> 1. In section 1.2 we could drop the definition of Identity >>> Provider and Relying Party. I don't think these are necessary in >>> this spec. >>> >>> 2. In section 2.1, the description of the PUSH delivery mode >>> states that the response must contain "Content-Type: >>> application/json". I think that is the case only for error >>> responses, I think on success no Content-Type is needed at all. >>> >>> 3. In section 2.2, it is stated that "the Event Receiver SHALL >>> indicate an HTTP Status 400 error with an error code as described >>> in Section 2.4". I think that some error codes should be matched >>> by other 4xx codes (for example 401 and 403). I think it would be >>> useful to list all the possible error codes and corresponding HTTP >>> Status codes in this section and not refer to 2.4, >>> >> >> The 4xx messages are assumed by the HTTP RFCs while the errors >> in sec 2.4 related to errors around jwt processing. We can call out >> specific 4xx errors that are likely to occur, but I find that people >> then have issues wondering if they can ever use the complete set of >> error conditions from RFC7231. >> >> Would people find it useful to clarify or give examples of how 7231 >> errors might occur? >> >> I=E2=80=99m not sure which of the sec 2.4 error codes could be match= ed with >> 401 or 403. These are mostly JWT error conditions. Can you elaborate= ? >> >> >> I think jwtAud and jwtIss should be 403 and not 400. >> >> setType and dup may also need something else than 400. >> >> >> >>> 4. In section 2.3.1, the description of maxEvents, at the very >>> end. A conflict between zero request events and returnImmediately >>> is described and the later should be ignored. I think this should >>> not be a silent ignore but an error condition, >>> >> The value of 0 is used to allow a poller to acknowledge >> previously received SETs without having to process or wait for new >> events. Thus returnImmediately is assumed. Thus the value of >> returnImmediately is ignored. >> >> >> Right, but to me with 0 and returnImmediately present the request is >> invalid and I don't think that returnImmediately should be simply ignore= d >> >> >> >> Some participants indicated a desire to keep acknowledgement threads >> separate from SET polling threads. Others wanted to be able to do >> both at the same time. >> >> >> Understood. >> >> >>> The current spec is at: >>> https://tools.ietf.org/html/draft-ietf-secevent-delivery-01 >>> >> ietf.org_html_draft-2Dietf-2Dsecevent-2Ddelivery-2D01&d=3D >>> DwMFaQ&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FV >>> zBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3Dne_ktq-vH7-ENPz2hHp >>> vEBD9gZ8NVol5ZAKe9EeHvu8&s=3DHlxm0ufeHaSgSiJeOwFFJrFyiarhtBVMc >>> kB9QCslj3Q&e=3D> >>> >>> I am happy to send pull requests for all these changes. Let me know= . >>> >>> Thanks, >>> Marius >>> _______________________________________________ >>> Id-event mailing list >>> Id-event@ietf.org >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.iet >>> f.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHv >>> lZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYq >>> PkAI1aLcLN4KZNA&m=3Dne_ktq-vH7-ENPz2hHpvEBD9gZ8NVol5ZAKe9EeHvu >>> 8&s=3DuhRVJB8aZnVZHEY_MgIwN8ZjrBDaxt7YDmif4wyv6jg&e=3D >>> >> ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCg >>> aWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXP >>> puYqPkAI1aLcLN4KZNA&m=3Dne_ktq-vH7-ENPz2hHpvEBD9gZ8NVol5ZAKe9 >>> EeHvu8&s=3DuhRVJB8aZnVZHEY_MgIwN8ZjrBDaxt7YDmif4wyv6jg&e=3D> >>> >> >> >> >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >> >> --94eb2c14b19646f3590566a119ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On S= at, Mar 3, 2018 at 4:41 AM, Yaron Sheffer <yaronf.iet= f@gmail.com> wrote:
Marius,=

given the timeline, please make whatever changes you see fit, and present t= hem in London with the understanding that the group might ask you to backtr= ack.

I will not be in London, unfortuna= tely. These are minor changes, but feedback from the group would be great.<= /div>

Thanks,
Marius

= =C2=A0

Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Yaron

On 03/03/18 02:00, Marius Scurtescu wrote:
On Fri, Mar 2, 2018 at 11:55 AM, Phil Hunt <phil.hunt@oracle.com <= ;mailto:phil.hunt@oracle.com>> wrote:

=C2=A0 =C2=A0 Marius,

=C2=A0 =C2=A0 Thanks.

=C2=A0 =C2=A0 Item 1 and 2 look reasonable.


Sounds good.


=C2=A0 =C2=A0 for Item 3, 4, I think the group should review. See below.

I also commented inline.


=C2=A0 =C2=A0 Given the submission deadline is Monday, it would be good to = wait
=C2=A0 =C2=A0 group confirmation of your proposals.


What that does mean in practical terms? If no one has objections we can go = ahead? By when?


=C2=A0 =C2=A0 Phil

=C2=A0 =C2=A0 Oracle Corporation, Identity Cloud Services Architect
=C2=A0 =C2=A0 @independentid
 =C2=A0 =C2=A0 www.independentid.com <http://www.independentid.com>
=C2=A0 =C2=A0 phil.hunt@oracle.com <mailto:phil.hunt@oracle.com&= gt;

=C2=A0 =C2=A0 On Mar 2, 2018, at 10:30 AM, Marius Scurtescu
=
=C2=A0 =C2=A0 <mscurtescu@google.com <mailto:mscurtescu@google.= com>> wrote:

=C2=A0 =C2=A0 I have a few other suggestions:

=C2=A0 =C2=A0 1. In section 1.2 we could drop the definition of Identity =C2=A0 =C2=A0 Provider and Relying Party. I don't think these are neces= sary in
=C2=A0 =C2=A0 this spec.

=C2=A0 =C2=A0 2. In section 2.1, the description of the PUSH delivery mode<= br> =C2=A0 =C2=A0 states that the response must contain "Content-Type:
=C2=A0 =C2=A0 application/json". I think that is the case only for err= or
=C2=A0 =C2=A0 responses, I think on success no Content-Type is needed at al= l.

=C2=A0 =C2=A0 3. In section 2.2, it is stated that "the Event Receiver= SHALL
=C2=A0 =C2=A0 indicate an HTTP Status 400 error with an error code as descr= ibed
=C2=A0 =C2=A0 in Section 2.4". I think that some error codes should be= matched
=C2=A0 =C2=A0 by other 4xx codes (for example 401 and 403). I think it woul= d be
=C2=A0 =C2=A0 useful to list all the possible error codes and corresponding= HTTP
=C2=A0 =C2=A0 Status codes in this section and not refer to 2.4,

=C2=A0 =C2=A0 <PH>The 4xx messages are assumed by the HTTP RFCs while= the errors
=C2=A0 =C2=A0 in sec 2.4 related to errors around jwt processing. We can ca= ll out
=C2=A0 =C2=A0 specific 4xx errors that are likely to occur, but I find that= people
=C2=A0 =C2=A0 then have issues wondering if they can ever use the complete = set of
=C2=A0 =C2=A0 error conditions from RFC7231.

=C2=A0 =C2=A0 Would people find it useful to clarify or give examples of ho= w 7231
=C2=A0 =C2=A0 errors might occur?

=C2=A0 =C2=A0 I=E2=80=99m not sure which of the sec 2.4 error codes could b= e matched with
=C2=A0 =C2=A0 401 or 403. These are mostly JWT error conditions. Can you el= aborate?


I think=C2=A0jwtAud and=C2=A0jwtIss should be 403 and not 400.

setType and dup may also need something else than 400.



=C2=A0 =C2=A0 4. In section 2.3.1, the description of maxEvents, at the ver= y
=C2=A0 =C2=A0 end. A conflict between zero request events and returnImmedia= tely
=C2=A0 =C2=A0 is described and the later should be ignored. I think this sh= ould
=C2=A0 =C2=A0 not be a silent ignore but an error condition,
=C2=A0 =C2=A0 <PH>The value of 0 is used to allow a poller to acknowl= edge
=C2=A0 =C2=A0 previously received SETs without having to process or wait fo= r new
=C2=A0 =C2=A0 events. Thus returnImmediately is assumed. Thus the value of<= br> =C2=A0 =C2=A0 returnImmediately is ignored.


Right, but to me with 0 and returnImmediately present the request is invali= d and I don't think that=C2=A0returnImmediately should be simply ignore= d



=C2=A0 =C2=A0 Some participants indicated a desire to keep acknowledgement = threads
=C2=A0 =C2=A0 separate from SET polling threads.=C2=A0 Others wanted to be = able to do
=C2=A0 =C2=A0 both at the same time.


Understood.


=C2=A0 =C2=A0 The current spec is at:
=C2=A0 =C2=A0 https://to= ols.ietf.org/html/draft-ietf-secevent-delivery-01
=C2=A0 =C2=A0 <https://urldefen= se.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_html_draft-= 2Dietf-2Dsecevent-2Ddelivery-2D01&d=3DDwMFaQ&c=3DRoP1YumC= XCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4Dpct= yXPpuYqPkAI1aLcLN4KZNA&m=3Dne_ktq-vH7-ENPz2hHpvEBD9gZ8NVol5ZA= Ke9EeHvu8&s=3DHlxm0ufeHaSgSiJeOwFFJrFyiarhtBVMckB9QCslj3Q&= ;e=3D>

=C2=A0 =C2=A0 I am happy to send pull requests for all these changes. Let m= e know.

=C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 Marius
=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 Id-event mailing list
 =C2=A0 =C2=A0 Id-event@ietf.org <mailto:Id-event@ietf.org>
=C2=A0 =C2=A0 https://urldefense.proofpoint.com/v2/= url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent&d= =3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3Dne_ktq-vH7-E<= wbr>NPz2hHpvEBD9gZ8NVol5ZAKe9EeHvu8&s=3DuhRVJB8aZnVZHEY_MgIwN8ZjrB= Daxt7YDmif4wyv6jg&e=3D
=C2=A0 =C2=A0 <https://urldefense.proofpoint.com= /v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent&am= p;d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&= amp;r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3Dne_ktq-vH7-ENPz2hHpvEBD9gZ8NVol5ZAKe9EeHvu8&s=3DuhRVJB8aZnVZHEY_MgIwN8ZjrBDaxt7YDmif4wyv6jg&e=3D>




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


--94eb2c14b19646f3590566a119ed-- From nobody Sun Mar 4 20:16:53 2018 Return-Path: X-Original-To: id-event@ietf.org Delivered-To: id-event@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 364B2120047; Sun, 4 Mar 2018 20:16:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: id-event@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.73.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152022341213.27972.4237069562394704813@ietfa.amsl.com> Date: Sun, 04 Mar 2018 20:16:52 -0800 Archived-At: Subject: [Id-event] I-D Action: draft-ietf-secevent-delivery-02.txt X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 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 Mar 2018 04:16:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Security Events WG of the IETF. Title : SET Token Delivery Using HTTP Authors : Phil Hunt Marius Scurtescu Morteza Ansari Anthony Nadalin Annabelle Richard Backman Filename : draft-ietf-secevent-delivery-02.txt Pages : 26 Date : 2018-03-04 Abstract: This specification defines how a series of security event tokens (SETs) may be delivered to a previously registered receiver using HTTP POST over TLS initiated as a push to the receiver, or as a poll by the receiver. The specification also defines how delivery can be assured subject to the SET Token Receiver's need for assurance. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-secevent-delivery/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-secevent-delivery-02 https://datatracker.ietf.org/doc/html/draft-ietf-secevent-delivery-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-secevent-delivery-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Mar 4 20:21:49 2018 Return-Path: X-Original-To: id-event@ietf.org Delivered-To: id-event@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5805F120047; Sun, 4 Mar 2018 20:21:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: id-event@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.73.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152022370432.28000.10526961209140986620@ietfa.amsl.com> Date: Sun, 04 Mar 2018 20:21:44 -0800 Archived-At: Subject: [Id-event] I-D Action: draft-ietf-secevent-token-07.txt X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 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 Mar 2018 04:21:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Security Events WG of the IETF. Title : Security Event Token (SET) Authors : Phil Hunt Michael B. Jones William Denniss Morteza Ansari Filename : draft-ietf-secevent-token-07.txt Pages : 27 Date : 2018-03-04 Abstract: This specification defines the Security Event Token (SET) data structure. A SET describes a statement of fact from the perspective of an issuer about the state of a security subject, which is intended to be shared with one or more recipients. This statement of fact represents an event that occurred to the security subject. In some use cases, the security subject may be a digitial identity, but SETs are also applicable to non-identity use cases. A SET is a JSON Web Token (JWT), which can be optionally signed and/or encrypted. SETs can be distributed via protocols such as HTTP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-secevent-token/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-secevent-token-07 https://datatracker.ietf.org/doc/html/draft-ietf-secevent-token-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-secevent-token-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Mar 4 20:24:15 2018 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 26E53124C27 for ; Sun, 4 Mar 2018 20:24:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-spgRcYmpR0 for ; Sun, 4 Mar 2018 20:24:11 -0800 (PST) Received: from userp2120.oracle.com (userp2120.oracle.com [156.151.31.85]) (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 E9439120047 for ; Sun, 4 Mar 2018 20:24:10 -0800 (PST) Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w254MZRx186418 for ; Mon, 5 Mar 2018 04:24:10 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : content-type : mime-version : subject : date : references : to : in-reply-to : message-id; s=corp-2017-10-26; bh=yQl2911aIbJ6oyfnmo3SzYqtTrVdw2rw4gfqXmQM3DA=; b=lSrYXnwVWuT1h0d31sEaTJct5/l6uObhc4GKmpMiFY1c7lJcJxMZ3glqpOYZ6Vy8dJ7p KVkIHw77up5q4nfFN336Otk2OrceFaRxr4UUGpaLCXAZSBerHOCtwJg3/6Sr5YnonacQ bYEON/C9k4htzdnd8R97PwCNnWKoHl7VS9nCGNC2PxIG8SO3b+bnneFtmgBESDlOA0+M 8x1aHWR285F/6KyqY+RV3rav+D4M5b4VVN8JuSD2XKwjjGQBtqnhio6jP4JA47sj0PP7 jMXhaWE5HuBfS5xg98GBBqCXD8Rz0wYKdTdS2ku8uDCpp2my6O/V0Npl5ldEOEOhB+C2 7w== Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp2120.oracle.com with ESMTP id 2ggwyfr3jk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 05 Mar 2018 04:24:10 +0000 Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w254O9UW002763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Mon, 5 Mar 2018 04:24:09 GMT Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w254O9dO032753 for ; Mon, 5 Mar 2018 04:24:09 GMT Received: from [192.168.1.28] (/70.70.142.148) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 04 Mar 2018 20:24:09 -0800 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_D82B1677-A04A-4DFB-AFF7-7A0B058A0EFA" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Sun, 4 Mar 2018 20:24:07 -0800 References: <152022370432.28000.10526961209140986620@ietfa.amsl.com> To: SecEvent In-Reply-To: <152022370432.28000.10526961209140986620@ietfa.amsl.com> Message-Id: <308D474B-664F-4A2C-BD85-D2B7789591A0@oracle.com> X-Mailer: Apple Mail (2.3445.5.20) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8822 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803050051 Archived-At: Subject: Re: [Id-event] I-D Action: draft-ietf-secevent-token-07.txt X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 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 Mar 2018 04:24:13 -0000 --Apple-Mail=_D82B1677-A04A-4DFB-AFF7-7A0B058A0EFA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This update contains a minor wording refinement suggested by Annabelle = in regards to the shepherd review. Phil Oracle Corporation, Identity Cloud Services Architect @independentid www.independentid.com = phil.hunt@oracle.com = > On Mar 4, 2018, at 8:21 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Security Events WG of the IETF. >=20 > Title : Security Event Token (SET) > Authors : Phil Hunt > Michael B. Jones > William Denniss > Morteza Ansari > Filename : draft-ietf-secevent-token-07.txt > Pages : 27 > Date : 2018-03-04 >=20 > Abstract: > This specification defines the Security Event Token (SET) data > structure. A SET describes a statement of fact from the perspective > of an issuer about the state of a security subject, which is = intended > to be shared with one or more recipients. This statement of fact > represents an event that occurred to the security subject. In some > use cases, the security subject may be a digitial identity, but SETs > are also applicable to non-identity use cases. A SET is a JSON Web > Token (JWT), which can be optionally signed and/or encrypted. SETs > can be distributed via protocols such as HTTP. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.or= g_doc_draft-2Dietf-2Dsecevent-2Dtoken_&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8= PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3D= q1YQshngXLpkD7jUEUA-VC4HLb3zkTt8k_akWGbLFGg&s=3DKv8WUeJUFNmptXwXbEexniialb= BZGRM_Ne57gkYDEwM&e=3D >=20 > There are also htmlized versions available at: > = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_html= _draft-2Dietf-2Dsecevent-2Dtoken-2D07&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8P= Zh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3D= q1YQshngXLpkD7jUEUA-VC4HLb3zkTt8k_akWGbLFGg&s=3D0NvXf7l65hkSR-iyssN-lKJnaz= cocfZwiWB0dlKTcbM&e=3D > = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.or= g_doc_html_draft-2Dietf-2Dsecevent-2Dtoken-2D07&d=3DDwICAg&c=3DRoP1YumCXCg= aWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcL= N4KZNA&m=3Dq1YQshngXLpkD7jUEUA-VC4HLb3zkTt8k_akWGbLFGg&s=3DOJXT6W9F-9Pl-DM= -mKlFY2E4Wp-Tm5hcOxT1LFKH7_I&e=3D >=20 > A diff from the previous version is available at: > = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_rfcdif= f-3Furl2-3Ddraft-2Dietf-2Dsecevent-2Dtoken-2D07&d=3DDwICAg&c=3DRoP1YumCXCg= aWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcL= N4KZNA&m=3Dq1YQshngXLpkD7jUEUA-VC4HLb3zkTt8k_akWGbLFGg&s=3D0s-Ble5HZvOZAuu= BRJjlrQ1_elpZn81H5W32KePCWQ0&e=3D >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > = https://urldefense.proofpoint.com/v2/url?u=3Dftp-3A__ftp.ietf.org_internet= -2Ddrafts_&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3D= na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3Dq1YQshngXLpkD7jUEUA-VC4HLb= 3zkTt8k_akWGbLFGg&s=3DZ3pILXO1GpLzQSYRhLJ25KBfNcDEUKNFO6fgkclZeAg&e=3D >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65ea= pI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3Dq1YQshngXLpkD7j= UEUA-VC4HLb3zkTt8k_akWGbLFGg&s=3DhSfN_NNQjPXKh4JySgCaix5VNYFMrWtRS6aC47qjU= 3M&e=3D --Apple-Mail=_D82B1677-A04A-4DFB-AFF7-7A0B058A0EFA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii This = update contains a minor wording refinement suggested by Annabelle in = regards to the shepherd review.

Phil

Oracle Corporation, Identity Cloud = Services Architect
@independentid
www.independentid.com
phil.hunt@oracle.com

On Mar 4, 2018, at 8:21 PM, internet-drafts@ietf.org wrote:


A New Internet-Draft is available from the on-line = Internet-Drafts directories.
This draft is a work item of = the Security Events WG of the IETF.

=        Title =           : Security = Event Token (SET)
=        Authors =         : Phil Hunt
= =             &n= bsp;           &nbs= p;Michael B. Jones
=             &n= bsp;           &nbs= p;William Denniss
=             &n= bsp;           &nbs= p;Morteza Ansari
Filename =        : = draft-ietf-secevent-token-07.txt
Pages =           : 27
= Date =            : = 2018-03-04

Abstract:
=   This specification defines the Security Event Token (SET) = data
  structure.  A SET describes a = statement of fact from the perspective
  of an = issuer about the state of a security subject, which is intended
  to be shared with one or more recipients. =  This statement of fact
  represents an = event that occurred to the security subject.  In some
=   use cases, the security subject may be a digitial identity, = but SETs
  are also applicable to non-identity = use cases.  A SET is a JSON Web
  Token = (JWT), which can be optionally signed and/or encrypted.  SETs
  can be distributed via protocols such as = HTTP.


The IETF datatracker = status page for this draft is:
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatrac= ker.ietf.org_doc_draft-2Dietf-2Dsecevent-2Dtoken_&d=3DDwICAg&c=3DR= oP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyX= PpuYqPkAI1aLcLN4KZNA&m=3Dq1YQshngXLpkD7jUEUA-VC4HLb3zkTt8k_akWGbLFGg&a= mp;s=3DKv8WUeJUFNmptXwXbEexniialbBZGRM_Ne57gkYDEwM&e=3D

There are also htmlized versions available = at:
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ie= tf.org_html_draft-2Dietf-2Dsecevent-2Dtoken-2D07&d=3DDwICAg&c=3DRo= P1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXP= puYqPkAI1aLcLN4KZNA&m=3Dq1YQshngXLpkD7jUEUA-VC4HLb3zkTt8k_akWGbLFGg&am= p;s=3D0NvXf7l65hkSR-iyssN-lKJnazcocfZwiWB0dlKTcbM&e=3D
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatrac= ker.ietf.org_doc_html_draft-2Dietf-2Dsecevent-2Dtoken-2D07&d=3DDwICAg&= amp;c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqW= Ny4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3Dq1YQshngXLpkD7jUEUA-VC4HLb3zkTt8k_ak= WGbLFGg&s=3DOJXT6W9F-9Pl-DM-mKlFY2E4Wp-Tm5hcOxT1LFKH7_I&e=3D

A diff from the previous version is available = at:
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf= .org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dsecevent-2Dtoken-2D07&d=3DDwICAg&= amp;c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqW= Ny4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3Dq1YQshngXLpkD7jUEUA-VC4HLb3zkTt8k_ak= WGbLFGg&s=3D0s-Ble5HZvOZAuuBRJjlrQ1_elpZn81H5W32KePCWQ0&e=3D


Please note that it may take a = couple of minutes from the time of submission
until the = htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by = anonymous FTP at:
https://urldefense.proofpoint.com/v2/url?u=3Dftp-3A__ftp.ietf.o= rg_internet-2Ddrafts_&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qI= rMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3D= q1YQshngXLpkD7jUEUA-VC4HLb3zkTt8k_akWGbLFGg&s=3DZ3pILXO1GpLzQSYRhLJ25K= BfNcDEUKNFO6fgkclZeAg&e=3D

_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf= .org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZY= R8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4K= ZNA&m=3Dq1YQshngXLpkD7jUEUA-VC4HLb3zkTt8k_akWGbLFGg&s=3DhSfN_NNQjP= XKh4JySgCaix5VNYFMrWtRS6aC47qjU3M&e=3D

= --Apple-Mail=_D82B1677-A04A-4DFB-AFF7-7A0B058A0EFA-- From nobody Sun Mar 4 20:28:28 2018 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 65587126C19 for ; Sun, 4 Mar 2018 20:28:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IYCXC7MVXkqw for ; Sun, 4 Mar 2018 20:28:25 -0800 (PST) Received: from aserp2120.oracle.com (aserp2120.oracle.com [141.146.126.78]) (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 46B77124C27 for ; Sun, 4 Mar 2018 20:28:25 -0800 (PST) Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w254QvK6137837 for ; Mon, 5 Mar 2018 04:28:24 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : content-type : mime-version : subject : date : references : to : in-reply-to : message-id; s=corp-2017-10-26; bh=18e9XZQJBZqiEf/7ueqNB9RsrQRdSp42+6IYMKlgpd8=; b=HKMx7JR7eeerZQw0EJsX6IeSm4H/6gN/reLDPFATJ8W3+nAUU+n4VvSZRSkeFcGGlf5D ijUoIVXKmib8ghjwV1wDB1sr18cCSluktuUGcDWHLpmtFprvQqVDxfdbxadE1Ar/Zzk5 OZs8FE8jOQfP2NslspWN/YoFz4LIIAS+WgO7PnmECaqjYNWVVq5SmNWxoZe6UPI0IXZj bp5Y+7tlsL0s4/28zpSkdIlKYDhZ6BPyox3PHFnie51zm/VmLWHu6a/zaY027SLHaCPI zxQ3EZzVJXTzW1NJ+EBUHXggqUOJR/FQAdZE2GjESWWAgywueXzPizNY2v+y7l32Bzkm Sw== Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp2120.oracle.com with ESMTP id 2ggwwbg43w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 05 Mar 2018 04:28:24 +0000 Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w254SNAF013886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Mon, 5 Mar 2018 04:28:23 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w254SNB1000841 for ; Mon, 5 Mar 2018 04:28:23 GMT Received: from [192.168.1.28] (/70.70.142.148) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 04 Mar 2018 20:28:22 -0800 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_236F1678-A583-4313-8403-32D3380F1165" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Sun, 4 Mar 2018 20:28:21 -0800 References: <152022341213.27972.4237069562394704813@ietfa.amsl.com> To: SecEvent In-Reply-To: <152022341213.27972.4237069562394704813@ietfa.amsl.com> Message-Id: <9D3011ED-8586-4DE1-91C3-E3BCB6BEDBA3@oracle.com> X-Mailer: Apple Mail (2.3445.5.20) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8822 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803050052 Archived-At: Subject: Re: [Id-event] I-D Action: draft-ietf-secevent-delivery-02.txt X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 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 Mar 2018 04:28:27 -0000 --Apple-Mail=_236F1678-A583-4313-8403-32D3380F1165 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This document contains some minor updates from Marius in advance of = IETF101. The terminology for Identity Provider and Relying Party are = dropped from the definitions section as they are no longer relevant to = the draft. Thanks, Phil Oracle Corporation, Identity Cloud Services Architect @independentid www.independentid.com = phil.hunt@oracle.com = > On Mar 4, 2018, at 8:16 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Security Events WG of the IETF. >=20 > Title : SET Token Delivery Using HTTP > Authors : Phil Hunt > Marius Scurtescu > Morteza Ansari > Anthony Nadalin > Annabelle Richard Backman > Filename : draft-ietf-secevent-delivery-02.txt > Pages : 26 > Date : 2018-03-04 >=20 > Abstract: > This specification defines how a series of security event tokens > (SETs) may be delivered to a previously registered receiver using > HTTP POST over TLS initiated as a push to the receiver, or as a poll > by the receiver. The specification also defines how delivery can be > assured subject to the SET Token Receiver's need for assurance. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.or= g_doc_draft-2Dietf-2Dsecevent-2Ddelivery_&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZ= YR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA= &m=3D7zJawjx-yW6HkoyQ0kPujxicrDfv4Cg8XVNoGYmvE94&s=3DVQHhRhtyrzqHrsoE9iLqw= Xq7xcrD53t2Glq0q1Z4kUo&e=3D >=20 > There are also htmlized versions available at: > = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_html= _draft-2Dietf-2Dsecevent-2Ddelivery-2D02&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZY= R8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&= m=3D7zJawjx-yW6HkoyQ0kPujxicrDfv4Cg8XVNoGYmvE94&s=3DI5UYs-uys-eu8x8yw__Ykv= hzjapHK7e4j9NgP8ch36s&e=3D > = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.or= g_doc_html_draft-2Dietf-2Dsecevent-2Ddelivery-2D02&d=3DDwICAg&c=3DRoP1YumC= XCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1a= LcLN4KZNA&m=3D7zJawjx-yW6HkoyQ0kPujxicrDfv4Cg8XVNoGYmvE94&s=3Dwq8KOLIkIkla= w-WUKb79-no0qzcNqz6uJlpS-5VpM2o&e=3D >=20 > A diff from the previous version is available at: > = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_rfcdif= f-3Furl2-3Ddraft-2Dietf-2Dsecevent-2Ddelivery-2D02&d=3DDwICAg&c=3DRoP1YumC= XCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1a= LcLN4KZNA&m=3D7zJawjx-yW6HkoyQ0kPujxicrDfv4Cg8XVNoGYmvE94&s=3DzJmsq0m9g-lN= Jiv76S48Vy0aQpIa7dSSsEslZSyfxGg&e=3D >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > = https://urldefense.proofpoint.com/v2/url?u=3Dftp-3A__ftp.ietf.org_internet= -2Ddrafts_&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3D= na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3D7zJawjx-yW6HkoyQ0kPujxicrD= fv4Cg8XVNoGYmvE94&s=3DkEqnjOUi11WqXEat4PujFnSrlxmgIdxCG5rOK2BwyjI&e=3D >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65ea= pI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3D7zJawjx-yW6Hkoy= Q0kPujxicrDfv4Cg8XVNoGYmvE94&s=3D58FcylthfpumPRv2gSAssAKqfLy8P3r7LCYl1Jh8j= d4&e=3D --Apple-Mail=_236F1678-A583-4313-8403-32D3380F1165 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii This = document contains some minor updates from Marius in advance of IETF101. = The terminology for Identity Provider and Relying Party are dropped from = the definitions section as they are no longer relevant to the draft.

Thanks,

Phil

Oracle Corporation, Identity Cloud = Services Architect
@independentid
www.independentid.com
phil.hunt@oracle.com

On Mar 4, 2018, at 8:16 PM, internet-drafts@ietf.org wrote:


A New Internet-Draft is available from the on-line = Internet-Drafts directories.
This draft is a work item of = the Security Events WG of the IETF.

=        Title =           : SET Token = Delivery Using HTTP
=        Authors =         : Phil Hunt
= =             &n= bsp;           &nbs= p;Marius Scurtescu
=             &n= bsp;           &nbs= p;Morteza Ansari
=             &n= bsp;           &nbs= p;Anthony Nadalin
=             &n= bsp;           &nbs= p;Annabelle Richard Backman
Filename =        : = draft-ietf-secevent-delivery-02.txt
Pages =           : 26
= Date =            : = 2018-03-04

Abstract:
=   This specification defines how a series of security event = tokens
  (SETs) may be delivered to a = previously registered receiver using
  HTTP = POST over TLS initiated as a push to the receiver, or as a poll
  by the receiver.  The specification also = defines how delivery can be
  assured subject = to the SET Token Receiver's need for assurance.


The IETF datatracker status page for this = draft is:
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatrac= ker.ietf.org_doc_draft-2Dietf-2Dsecevent-2Ddelivery_&d=3DDwICAg&c=3D= RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4Dpcty= XPpuYqPkAI1aLcLN4KZNA&m=3D7zJawjx-yW6HkoyQ0kPujxicrDfv4Cg8XVNoGYmvE94&= amp;s=3DVQHhRhtyrzqHrsoE9iLqwXq7xcrD53t2Glq0q1Z4kUo&e=3D

There are also htmlized versions available = at:
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ie= tf.org_html_draft-2Dietf-2Dsecevent-2Ddelivery-2D02&d=3DDwICAg&c=3D= RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4Dpcty= XPpuYqPkAI1aLcLN4KZNA&m=3D7zJawjx-yW6HkoyQ0kPujxicrDfv4Cg8XVNoGYmvE94&= amp;s=3DI5UYs-uys-eu8x8yw__YkvhzjapHK7e4j9NgP8ch36s&e=3D
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatrac= ker.ietf.org_doc_html_draft-2Dietf-2Dsecevent-2Ddelivery-2D02&d=3DDwIC= Ag&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWma= nqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3D7zJawjx-yW6HkoyQ0kPujxicrDfv4Cg8X= VNoGYmvE94&s=3Dwq8KOLIkIklaw-WUKb79-no0qzcNqz6uJlpS-5VpM2o&e=3D
A diff from the previous version is available = at:
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf= .org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dsecevent-2Ddelivery-2D02&d=3DDwIC= Ag&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWma= nqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3D7zJawjx-yW6HkoyQ0kPujxicrDfv4Cg8X= VNoGYmvE94&s=3DzJmsq0m9g-lNJiv76S48Vy0aQpIa7dSSsEslZSyfxGg&e=3D

Please note that it may take a = couple of minutes from the time of submission
until the = htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by = anonymous FTP at:
https://urldefense.proofpoint.com/v2/url?u=3Dftp-3A__ftp.ietf.o= rg_internet-2Ddrafts_&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qI= rMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3D= 7zJawjx-yW6HkoyQ0kPujxicrDfv4Cg8XVNoGYmvE94&s=3DkEqnjOUi11WqXEat4PujFn= SrlxmgIdxCG5rOK2BwyjI&e=3D

_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf= .org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZY= R8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4K= ZNA&m=3D7zJawjx-yW6HkoyQ0kPujxicrDfv4Cg8XVNoGYmvE94&s=3D58Fcylthfp= umPRv2gSAssAKqfLy8P3r7LCYl1Jh8jd4&e=3D

= --Apple-Mail=_236F1678-A583-4313-8403-32D3380F1165-- From nobody Sun Mar 4 22:26:38 2018 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 DEBD1126FB3 for ; Sun, 4 Mar 2018 22:26:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 xh4N5IRvvu-v for ; Sun, 4 Mar 2018 22:26:33 -0800 (PST) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A76E126D0C for ; Sun, 4 Mar 2018 22:26:33 -0800 (PST) Received: by mail-wm0-x230.google.com with SMTP id z9so13122956wmb.3 for ; Sun, 04 Mar 2018 22:26:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LmRS6lBSxEY29XfW+3NOxCjq8Ptlb0giRqE0VaVvxpU=; b=TW2XtM83o9zn5No5lwH9N1b6EcskjpQMG1Gwsb8dwtxKvmeJ0C8dpc9gMkv8M14Az+ +hY0Y2fGg7jkO0vD3o7xc1I1PM7pD7lRLs6UOYYncPBM1H80S4fUBr4SCW+vNIxTknWg ZOG5NRJsZIj3JG+dChWzKURgZwy7ugmh215Uypey5jU6M9Ij0S+Jmnsnv30TsZePjjL/ PAmdYJ82+Z2heg63K3UJ9YVUlR9x+uZPFBk5wL4OBA8ry1DgF+76jllP3amMH6ZpIE8m At/rdQLpKdQ5WJdMEw38FDq1Ixq2wHjoDx+KMywneV6Xx+wgqQerdL4sqwvbHruWxd6n DkLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LmRS6lBSxEY29XfW+3NOxCjq8Ptlb0giRqE0VaVvxpU=; b=tMVca9xhUnimrJd4JSvDXFlEtDdQQ0mSCVX+xNgvtTJlnrcQeNmb6drVP+kxvk6p57 WYlGl+tDb6A1ss50S7wlxmNNP8QBn0/wElpdS7wQGMPxZUO2nyB6oCrGuB24zlIg0uC7 kQitvV7oUqL+ed5ojh3/DdjrREXzIBoacrCkDXGfjkJgRUWTf/TLrXaUkmgmRF0g+tUD piCKZOaVf+XmxzCCq7S2mgIADNroNAjdIvh5TpntsFnWdvjZdUh1i8euBJocfnSvtStS N/mu5bGjkj5+eyl9rJJaoTLVoRfGrcMvyVyElbeIOxICcSVQCBi3DdOkwRKBv0I7uZfX EFQQ== X-Gm-Message-State: AElRT7F+DakInYTon9mQscIAGbtp+qSf1ZDGOMFpqHYJ+ljDx/ZzzgB6 xnQLRTb3GRroLxi54s2gqCkX5zvrLNYNNQptNYUPyAWaYYs= X-Google-Smtp-Source: AG47ELuuJnbvCCUpK3iC0uAVclzNQGbzdlatHCZY30taKtkFls09lS4Pcke0Imzc9CRaE6069K7BRk6TNivwgeFwgxc= X-Received: by 10.28.106.19 with SMTP id f19mr7754860wmc.84.1520231191403; Sun, 04 Mar 2018 22:26:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.51.76 with HTTP; Sun, 4 Mar 2018 22:26:30 -0800 (PST) In-Reply-To: <9D3011ED-8586-4DE1-91C3-E3BCB6BEDBA3@oracle.com> References: <152022341213.27972.4237069562394704813@ietfa.amsl.com> <9D3011ED-8586-4DE1-91C3-E3BCB6BEDBA3@oracle.com> From: Adam Dawes Date: Sun, 4 Mar 2018 22:26:30 -0800 Message-ID: To: Phil Hunt Cc: SecEvent Content-Type: multipart/alternative; boundary="089e082ce1a02489310566a468d8" Archived-At: Subject: Re: [Id-event] I-D Action: draft-ietf-secevent-delivery-02.txt X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 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 Mar 2018 06:26:37 -0000 --089e082ce1a02489310566a468d8 Content-Type: text/plain; charset="UTF-8" Generally looks fine. I think the main thing that need to be resolved is what is MTI. From Singapore, there was a suggestion that it be up to the transmitter to decide whether to push, pull or both. This is not ideal as some Transmitters may support push while other Receivers may only be able to accept pull. It seems there is a bit of an enterprise/consumer split here where enterprise receivers are more likely to need pull to deal with firewalls while consumer transmitters are likely to want to support only push to protect themselves from polling load of high number of clients. I don't see much way around this situation for the spec. It seems unreasonable to force large consumer transmitters to take high frequency polling from a large number of clients and it's impossible for some enterprise receivers to get outside their firewall restrictions. I think the only answer is with the formation of intermediary services. These can serve as a queuing mechanism taking the signals from consumer Transmitters and enabling polling of them by enterprise Receivers. Similarly, these service providers could also poll for data form enterprise Transmitters that only support polling and then post those events to consumer Receivers. I think we should accept that forcing both push and pull on the whole ecosystem is unreasonable and that if there is a high need for interop between consumer and enterprise, service providers will step in to provide the glue. On Sun, Mar 4, 2018 at 8:28 PM, Phil Hunt wrote: > This document contains some minor updates from Marius in advance of > IETF101. The terminology for Identity Provider and Relying Party are > dropped from the definitions section as they are no longer relevant to the > draft. > > Thanks, > > Phil > > Oracle Corporation, Identity Cloud Services Architect > @independentid > www.independentid.com > phil.hunt@oracle.com > > On Mar 4, 2018, at 8:16 PM, internet-drafts@ietf.org wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Security Events WG of the IETF. > > Title : SET Token Delivery Using HTTP > Authors : Phil Hunt > Marius Scurtescu > Morteza Ansari > Anthony Nadalin > Annabelle Richard Backman > Filename : draft-ietf-secevent-delivery-02.txt > Pages : 26 > Date : 2018-03-04 > > Abstract: > This specification defines how a series of security event tokens > (SETs) may be delivered to a previously registered receiver using > HTTP POST over TLS initiated as a push to the receiver, or as a poll > by the receiver. The specification also defines how delivery can be > assured subject to the SET Token Receiver's need for assurance. > > > The IETF datatracker status page for this draft is: > https://urldefense.proofpoint.com/v2/url?u=https-3A__ > datatracker.ietf.org_doc_draft-2Dietf-2Dsecevent-2Ddelivery_&d=DwICAg&c= > RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r= > na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=7zJawjx- > yW6HkoyQ0kPujxicrDfv4Cg8XVNoGYmvE94&s=VQHhRhtyrzqHrsoE9iLqwXq7xcrD53 > t2Glq0q1Z4kUo&e= > > There are also htmlized versions available at: > https://urldefense.proofpoint.com/v2/url?u=https-3A__tools. > ietf.org_html_draft-2Dietf-2Dsecevent-2Ddelivery-2D02&d=DwICAg&c= > RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r= > na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=7zJawjx- > yW6HkoyQ0kPujxicrDfv4Cg8XVNoGYmvE94&s=I5UYs-uys-eu8x8yw__ > YkvhzjapHK7e4j9NgP8ch36s&e= > https://urldefense.proofpoint.com/v2/url?u=https-3A__ > datatracker.ietf.org_doc_html_draft-2Dietf-2Dsecevent- > 2Ddelivery-2D02&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r= > na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=7zJawjx- > yW6HkoyQ0kPujxicrDfv4Cg8XVNoGYmvE94&s=wq8KOLIkIklaw-WUKb79- > no0qzcNqz6uJlpS-5VpM2o&e= > > A diff from the previous version is available at: > https://urldefense.proofpoint.com/v2/url?u=https-3A__www. > ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dsecevent- > 2Ddelivery-2D02&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r= > na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=7zJawjx- > yW6HkoyQ0kPujxicrDfv4Cg8XVNoGYmvE94&s=zJmsq0m9g- > lNJiv76S48Vy0aQpIa7dSSsEslZSyfxGg&e= > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf. > org_internet-2Ddrafts_&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIr > MUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=7zJawjx- > yW6HkoyQ0kPujxicrDfv4Cg8XVNoGYmvE94&s=kEqnjOUi11WqXEat4PujFnSrlxmgId > xCG5rOK2BwyjI&e= > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__www. > ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c= > RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r= > na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=7zJawjx- > yW6HkoyQ0kPujxicrDfv4Cg8XVNoGYmvE94&s=58FcylthfpumPRv2gSAssAKqfLy8P3 > r7LCYl1Jh8jd4&e= > > > > _______________________________________________ > 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 --089e082ce1a02489310566a468d8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Generally looks fine. I think the main thing that nee= d to be resolved is what is MTI. From Singapore, there was a suggestion tha= t it be up to the transmitter to decide whether to push, pull or both. This= is not ideal as some Transmitters may support push while other Receivers m= ay only be able to accept pull. It seems there is a bit of an enterprise/co= nsumer split here where enterprise receivers are more likely to need pull t= o deal with firewalls while consumer transmitters are likely to want to sup= port only push to protect themselves from polling load of high number of cl= ients.=C2=A0

I don't see much way around this = situation for the spec. It seems unreasonable to force large consumer trans= mitters to take high frequency polling from a large number of clients and i= t's impossible for some enterprise receivers to get outside their firew= all restrictions. I think the only answer is with the formation of intermed= iary services. These can serve as a queuing mechanism taking the signals fr= om consumer Transmitters and enabling polling of them by enterprise Receive= rs. Similarly, these service providers could also poll for data form enterp= rise Transmitters that only support polling and then post those events to c= onsumer Receivers.=C2=A0

I think we should accept = that forcing both push and pull on the whole ecosystem is unreasonable and = that if there is a high need for interop between consumer and enterprise, s= ervice providers will step in to provide the glue.=C2=A0

On Sun, Mar 4, 2018 at 8= :28 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
This document contains some minor updates from Marius in adv= ance of IETF101. The terminology for Identity Provider and Relying Party ar= e dropped from the definitions section as they are no longer relevant to th= e draft.

Thanks,

=
Phil

Oracle Corporation, Identity Cloud Services Architect
@inde= pendentid
phil.hunt@oracle.com

On Mar 4, 2018, at= 8:16 PM, int= ernet-drafts@ietf.org wrote:


A New Interne= t-Draft is available from the on-line Internet-Drafts directories.
This = draft is a work item of the Security Events WG of the IETF.

=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Title =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0: SET Token Delivery Using HTTP
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Authors =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0: Phil Hunt
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Marius Scurtescu
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Morteza Ansar= i
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0Anthony Nadalin
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Annabelle Richard Backman
= Filename =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: draft-ietf-sec= event-delivery-02.txt
Pages =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 26
Date =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 2018-03-04
Abstract:
=C2=A0=C2=A0This specification defines how a series of s= ecurity event tokens
=C2=A0=C2=A0(SETs) may be delivered to a previousl= y registered receiver using
=C2=A0=C2=A0HTTP POST over TLS initiated as= a push to the receiver, or as a poll
=C2=A0=C2=A0by the receiver.=C2= =A0 The specification also defines how delivery can be
=C2=A0=C2=A0assu= red subject to the SET Token Receiver's need for assurance.


= The IETF datatracker status page for this draft is:
https://ur= ldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.org= _doc_draft-2Dietf-2Dsecevent-2Ddelivery_&d=3DDwICAg&c=3D<= wbr>RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTW= manqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3D7zJawjx-yW6HkoyQ0kPujx= icrDfv4Cg8XVNoGYmvE94&s=3DVQHhRhtyrzqHrsoE9iLqwXq7xcrD53= t2Glq0q1Z4kUo&e=3D

There are also htmlized = versions available at:
https://urldefense.proofpoint.com/v= 2/url?u=3Dhttps-3A__tools.ietf.org_html_draft-2Dietf-2Dsecevent-2= Ddelivery-2D02&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7= qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aL= cLN4KZNA&m=3D7zJawjx-yW6HkoyQ0kPujxicrDfv4Cg8XVNoGYmvE94&= s=3DI5UYs-uys-eu8x8yw__YkvhzjapHK7e4j9NgP8ch36s&e=3D
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__data= tracker.ietf.org_doc_html_draft-2Dietf-2Dsecevent-2Ddelivery-2D02= &d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_J= nE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3D7z= Jawjx-yW6HkoyQ0kPujxicrDfv4Cg8XVNoGYmvE94&s=3Dwq8KOLIkIklaw-W= UKb79-no0qzcNqz6uJlpS-5VpM2o&e=3D

A di= ff from the previous version is available at:
https:/= /urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_rfcd= iff-3Furl2-3Ddraft-2Dietf-2Dsecevent-2Ddelivery-2D02&d=3DDwIC= Ag&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3D7zJawjx-yW= 6HkoyQ0kPujxicrDfv4Cg8XVNoGYmvE94&s=3DzJmsq0m9g-lNJiv76S48Vy0= aQpIa7dSSsEslZSyfxGg&e=3D


Please n= ote that it may take a couple of minutes from the time of submission
unt= il the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are a= lso available by anonymous FTP at:
https://urldefense.proofpoint.com/v2/url?u=3Dftp-3A__= ftp.ietf.org_internet-2Ddrafts_&d=3DDwICAg&c=3DRoP1Y= umCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4D= pctyXPpuYqPkAI1aLcLN4KZNA&m=3D7zJawjx-yW6HkoyQ0kPujxicrDfv4Cg= 8XVNoGYmvE94&s=3DkEqnjOUi11WqXEat4PujFnSrlxmgIdxCG5rOK2B= wyjI&e=3D

_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Dev= ent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eap= I_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m= =3D7zJawjx-yW6HkoyQ0kPujxicrDfv4Cg8XVNoGYmvE94&s=3D58Fcy= lthfpumPRv2gSAssAKqfLy8P3r7LCYl1Jh8jd4&e=3D


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




--
--089e082ce1a02489310566a468d8-- From nobody Mon Mar 5 08:25:21 2018 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 8E3D312D942 for ; Mon, 5 Mar 2018 08:25:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 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, HTML_OBFUSCATE_10_20=0.093, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=no 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 7aoBgP-R2Pyx for ; Mon, 5 Mar 2018 08:25:18 -0800 (PST) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8A1912D940 for ; Mon, 5 Mar 2018 08:25:17 -0800 (PST) Received: by mail-ua0-x22b.google.com with SMTP id u99so10852161uau.8 for ; Mon, 05 Mar 2018 08:25:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=81gGc87lCk6y8R3AgWbBjFz6Zkl3tpwetpzb7gJWT3o=; b=L3qe2lGegRQ29atVJU+nKMYJHH6MfI7zf4pEofNT+iApUW1lososiaIN8xquY6qWLs DGG+HG2GEdEaMneknq5DvVcdX2Ky/wDtEhi6zk4dq9ppJ6mP9/FWrRL7pPGKJMZyK5C4 vlG+FHKral7q+5CIZDp3O/JznY3f0X1jGFZ67ldvHm73ryFUc5p1AaNDqCJEYohJXdps tbxJiAqBcLBoLLUHQP1ow5yoEB5o3C5pvUzKYYiyz2KRu7KsSZTtRZ6TTLzzhjkEslk6 MVCiA562pbetkJjWvRfzJYP4fL451xy917PO1E5yuB6Ub6El9UWae9AbRyciVbUhWv9J RNLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=81gGc87lCk6y8R3AgWbBjFz6Zkl3tpwetpzb7gJWT3o=; b=F3tpTCbdExSG0ZwEP6cNCTdaHOLT/XcwjCcOhu8/yjoUEjBq0SqPGL5odCyiFWf7Og sA+w/j5DlworXjfXMJl/fC8wYi9lERV0jFHvCQ5/LzyaUoZ1qOU01kpBF48y4nzDI54x ZrphrGnP+ZOJSJW8ZbK5ibCEJ8uZeHTB2F3F/dW1iI+GwUkoMTWOuqcakUrXeTf7bkdC 4SLTX2U0/MwuVKnVrh91iK+Xz3o/ftEfno06lBBXDgswbVZ5HT8HvxTLTZlzyLEIwTbZ US9G7zGPCIBYGCKoDcQESCT7xXI9t5JzY1/bbXGTlr9jAkXb7UkZTiIeqfJ0opj9sNYx lGTA== X-Gm-Message-State: AElRT7HWsTTATLe2m5bs4GIxVUXttqiC5bL6HNzzpzVwxEFY+e9yQeTF co/VZPnsntxVzjpSSoMCuuseg9WYgyDZNEXwGqWx0w== X-Google-Smtp-Source: AG47ELvsMOHaPpfhOL+rQWI9TGf/+o4KxXfE5+ld/By0tyTpHMN0+Op8Yogf8Bje3o5L6YB/PWEWPky05ZKS+N61EyQ= X-Received: by 10.176.6.197 with SMTP id g63mr7818518uag.72.1520267116235; Mon, 05 Mar 2018 08:25:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.94.88 with HTTP; Mon, 5 Mar 2018 08:24:55 -0800 (PST) In-Reply-To: References: <152022341213.27972.4237069562394704813@ietfa.amsl.com> <9D3011ED-8586-4DE1-91C3-E3BCB6BEDBA3@oracle.com> From: Marius Scurtescu Date: Mon, 5 Mar 2018 08:24:55 -0800 Message-ID: To: Adam Dawes Cc: Phil Hunt , SecEvent Content-Type: multipart/alternative; boundary="94eb2c122e646e14740566acc554" Archived-At: Subject: Re: [Id-event] I-D Action: draft-ietf-secevent-delivery-02.txt X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 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 Mar 2018 16:25:20 -0000 --94eb2c122e646e14740566acc554 Content-Type: text/plain; charset="UTF-8" On Sun, Mar 4, 2018 at 10:26 PM, Adam Dawes wrote: > Generally looks fine. I think the main thing that need to be resolved is > what is MTI. From Singapore, there was a suggestion that it be up to the > transmitter to decide whether to push, pull or both. This is not ideal as > some Transmitters may support push while other Receivers may only be able > to accept pull. It seems there is a bit of an enterprise/consumer split > here where enterprise receivers are more likely to need pull to deal with > firewalls while consumer transmitters are likely to want to support only > push to protect themselves from polling load of high number of clients. > > I don't see much way around this situation for the spec. It seems > unreasonable to force large consumer transmitters to take high frequency > polling from a large number of clients and it's impossible for some > enterprise receivers to get outside their firewall restrictions. I think > the only answer is with the formation of intermediary services. These can > serve as a queuing mechanism taking the signals from consumer Transmitters > and enabling polling of them by enterprise Receivers. Similarly, these > service providers could also poll for data form enterprise Transmitters > that only support polling and then post those events to consumer Receivers. > > I think we should accept that forcing both push and pull on the whole > ecosystem is unreasonable and that if there is a high need for interop > between consumer and enterprise, service providers will step in to provide > the glue. > The solution we discussed was to split the delivery draft into two: one separate draft for push and another separate draft for poll. This way each provider can chose to implement the delivery methods they want. This also sets the precedent to create other delivery methods easily. I will start a separate thread on this regard. Hopefully in London the working group can have a discussion and decision around this. > > On Sun, Mar 4, 2018 at 8:28 PM, Phil Hunt wrote: > >> This document contains some minor updates from Marius in advance of >> IETF101. The terminology for Identity Provider and Relying Party are >> dropped from the definitions section as they are no longer relevant to the >> draft. >> >> Thanks, >> >> Phil >> >> Oracle Corporation, Identity Cloud Services Architect >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> >> On Mar 4, 2018, at 8:16 PM, internet-drafts@ietf.org wrote: >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Security Events WG of the IETF. >> >> Title : SET Token Delivery Using HTTP >> Authors : Phil Hunt >> Marius Scurtescu >> Morteza Ansari >> Anthony Nadalin >> Annabelle Richard Backman >> Filename : draft-ietf-secevent-delivery-02.txt >> Pages : 26 >> Date : 2018-03-04 >> >> Abstract: >> This specification defines how a series of security event tokens >> (SETs) may be delivered to a previously registered receiver using >> HTTP POST over TLS initiated as a push to the receiver, or as a poll >> by the receiver. The specification also defines how delivery can be >> assured subject to the SET Token Receiver's need for assurance. >> >> >> The IETF datatracker status page for this draft is: >> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatra >> cker.ietf.org_doc_draft-2Dietf-2Dsecevent-2Ddelivery_& >> d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5 >> FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=7zJawjx-yW6HkoyQ0 >> kPujxicrDfv4Cg8XVNoGYmvE94&s=VQHhRhtyrzqHrsoE9iLqwXq7xcrD53t >> 2Glq0q1Z4kUo&e= >> >> There are also htmlized versions available at: >> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.i >> etf.org_html_draft-2Dietf-2Dsecevent-2Ddelivery-2D02&d=DwICA >> g&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWm >> anqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=7zJawjx-yW6HkoyQ0kPujxic >> rDfv4Cg8XVNoGYmvE94&s=I5UYs-uys-eu8x8yw__YkvhzjapHK7e4j9NgP8ch36s&e= >> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatra >> cker.ietf.org_doc_html_draft-2Dietf-2Dsecevent-2Ddelivery- >> 2D02&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE& >> r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=7zJawjx-yW6H >> koyQ0kPujxicrDfv4Cg8XVNoGYmvE94&s=wq8KOLIkIklaw-WUKb79-no0qz >> cNqz6uJlpS-5VpM2o&e= >> >> A diff from the previous version is available at: >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iet >> f.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dsecevent-2Ddelivery- >> 2D02&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE& >> r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=7zJawjx-yW6H >> koyQ0kPujxicrDfv4Cg8XVNoGYmvE94&s=zJmsq0m9g-lNJiv76S48Vy0aQp >> Ia7dSSsEslZSyfxGg&e= >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf. >> org_internet-2Ddrafts_&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv >> 7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4K >> ZNA&m=7zJawjx-yW6HkoyQ0kPujxicrDfv4Cg8XVNoGYmvE94&s=kEqnjOUi >> 11WqXEat4PujFnSrlxmgIdxCG5rOK2BwyjI&e= >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iet >> f.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHv >> lZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYq >> PkAI1aLcLN4KZNA&m=7zJawjx-yW6HkoyQ0kPujxicrDfv4Cg8XVNoGYmvE9 >> 4&s=58FcylthfpumPRv2gSAssAKqfLy8P3r7LCYl1Jh8jd4&e= >> >> >> >> _______________________________________________ >> 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 > <(650)%20214-2410> > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > --94eb2c122e646e14740566acc554 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On S= un, Mar 4, 2018 at 10:26 PM, Adam Dawes <adawes@google.co= m> wrote:
=
Generally looks fine. I think the main thing that need to be resolved = is what is MTI. From Singapore, there was a suggestion that it be up to the= transmitter to decide whether to push, pull or both. This is not ideal as = some Transmitters may support push while other Receivers may only be able t= o accept pull. It seems there is a bit of an enterprise/consumer split here= where enterprise receivers are more likely to need pull to deal with firew= alls while consumer transmitters are likely to want to support only push to= protect themselves from polling load of high number of clients.=C2=A0

I don't see much way around this situation for the= spec. It seems unreasonable to force large consumer transmitters to take h= igh frequency polling from a large number of clients and it's impossibl= e for some enterprise receivers to get outside their firewall restrictions.= I think the only answer is with the formation of intermediary services. Th= ese can serve as a queuing mechanism taking the signals from consumer Trans= mitters and enabling polling of them by enterprise Receivers. Similarly, th= ese service providers could also poll for data form enterprise Transmitters= that only support polling and then post those events to consumer Receivers= .=C2=A0

I think we should accept that forcing both= push and pull on the whole ecosystem is unreasonable and that if there is = a high need for interop between consumer and enterprise, service providers = will step in to provide the glue.=C2=A0

The solution we discussed was to split the delivery draft into two= : one separate draft for push and another separate draft for poll. This way= each provider can chose to implement the delivery methods they want. This = also sets the precedent to create other delivery methods easily.
=
I will start a separate thread on this regard. Hopefully in = London the working group can have a discussion and decision around this.
=C2=A0

On Sun, Mar 4, 201= 8 at 8:28 PM, Phil Hunt <phil.hunt@oracle.com><= /span> wrote:
Th= is document contains some minor updates from Marius in advance of IETF101. = The terminology for Identity Provider and Relying Party are dropped from th= e definitions section as they are no longer relevant to the draft.

=
Thanks,

Ph= il

Oracle Corporation, Identity Cloud Services Arc= hitect
@independentid
<= /div>
phil.hunt@oracle.com

On Mar 4, 2018, at 8:16 PM, <= a href=3D"mailto:internet-drafts@ietf.org" target=3D"_blank" class=3D"creme= d">internet-drafts@ietf.org wrote:

=
A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories.
This draft is a work item of the Security Events WG of the IETF= .

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Title =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: SET Token Delivery Using HTT= P
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Authors =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: Phil Hunt
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Marius Scurtescu
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Morteza Ansari
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0Anthony Nadalin
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Annabelle Richard B= ackman
Filename =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0: draft-ietf-secevent-delivery-02.txt
Pages =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0: 26
Da= te =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 2018= -03-04

Abstract:
=C2=A0=C2=A0This specification defines how a se= ries of security event tokens
=C2=A0=C2=A0(SETs) may be delivered to a = previously registered receiver using
=C2=A0=C2=A0HTTP POST over TLS ini= tiated as a push to the receiver, or as a poll
=C2=A0=C2=A0by the recei= ver.=C2=A0 The specification also defines how delivery can be
=C2=A0=C2= =A0assured subject to the SET Token Receiver's need for assurance.
<= br>
The IETF datatracker status page for this draft is:
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__d= atatracker.ietf.org_doc_draft-2Dietf-2Dsecevent-2Ddelivery_&<= wbr>d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&= ;r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3D7zJawjx-= yW6HkoyQ0kPujxicrDfv4Cg8XVNoGYmvE94&s=3DVQHhRhtyrzqHrsoE9iLqw= Xq7xcrD53t2Glq0q1Z4kUo&e=3D

There are also htmliz= ed versions available at:
https://urldefense.p= roofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_html_draft-2Die= tf-2Dsecevent-2Ddelivery-2D02&d=3DDwICAg&c=3DRoP1YumCXCga= WHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPp= uYqPkAI1aLcLN4KZNA&m=3D7zJawjx-yW6HkoyQ0kPujxicrDfv4Cg8XVNoGY= mvE94&s=3DI5UYs-uys-eu8x8yw__YkvhzjapHK7e4j9NgP8ch36s&e= =3D
https://urldefense.proofpoint.= com/v2/url?u=3Dhttps-3A__datatracker.ietf.org_doc_html_draft-2Die= tf-2Dsecevent-2Ddelivery-2D02&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3D7zJawjx-yW6HkoyQ0kPujxicrDfv4Cg8XVNoGYmvE9<= wbr>4&s=3Dwq8KOLIkIklaw-WUKb79-no0qzcNqz6uJlpS-5VpM2o&e=3D=

A diff from the previous version is available at:
<= a href=3D"https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.o= rg_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dsecevent-2Ddelivery-2D02&d=3DDwICAg&= amp;c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWN= y4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3D7zJawjx-yW6HkoyQ0kPujxicrDfv4Cg8XVNoGY= mvE94&s=3DzJmsq0m9g-lNJiv76S48Vy0aQpIa7dSSsEslZSyfxGg&e=3D" target= =3D"_blank" class=3D"cremed">https://urldefense.proofpoint.com/v2/url?= u=3Dhttps-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dseceve= nt-2Ddelivery-2D02&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh= 8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLc= LN4KZNA&m=3D7zJawjx-yW6HkoyQ0kPujxicrDfv4Cg8XVNoGYmvE94&s= =3DzJmsq0m9g-lNJiv76S48Vy0aQpIa7dSSsEslZSyfxGg&e=3D
<= br>
Please note that it may take a couple of minutes from the time of su= bmission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
https://u= rldefense.proofpoint.com/v2/url?u=3Dftp-3A__ftp.ietf.org_internet= -2Ddrafts_&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrM= UB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&= amp;m=3D7zJawjx-yW6HkoyQ0kPujxicrDfv4Cg8XVNoGYmvE94&s=3DkEqnjOUi11WqXEat4PujFnSrlxmgIdxCG5rOK2BwyjI&e=3D

_____= __________________________________________
Id-event mailing listId= -event@ietf.org
https://urldefense.proofpoint.com/v2/url= ?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=3DD= wICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r= =3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3D7zJawjx-yW6HkoyQ0kPujxicrDfv4Cg8XVNoGYmvE94&s=3D58FcylthfpumPRv2gSAssAKqfLy8P3r7LCYl1Jh8jd4&e=3D


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


<= br clear=3D"all">

--
Adam Dawes=C2=A0|=C2=A0Sr. Product Manager=C2=A0|=C2=A0adawes@google.com=C2=A0|=C2=A0+1 650-214-2410=


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


--94eb2c122e646e14740566acc554-- From nobody Mon Mar 5 08:42:27 2018 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 F368D1270AC for ; Mon, 5 Mar 2018 08:42:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 NKBulYAhkUUm for ; Mon, 5 Mar 2018 08:42:18 -0800 (PST) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E2F1127342 for ; Mon, 5 Mar 2018 08:42:18 -0800 (PST) Received: by mail-ua0-x229.google.com with SMTP id e25so10910325uam.6 for ; Mon, 05 Mar 2018 08:42:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=qlAj6sJWPJQN1Rq+77jh6Z88sMoeMTwFiV66oFPkIMM=; b=JkR80sIxYZqcow1nyJGR3UHru47dFrFKG8oN6Twx1SAJo75777JLhtHzk2Lr3w+/vY 9Y+VETdLrVyTpCxapMw3iWKWbjVPIu0dY976lh3kj6ZW8Z/GZucgO4IfY8YlVmP3BmcO xdMkQqOuuHociaWyB/YtKuGl+MLcmNdl2ACWn7pt+JaTbZ1EoOU8FvRXxX24Dzesre4g bMGEptJ9I480HBqghjZRWCnykuyrrTmPUq14p7Z+e/uCU5iGp4F0FnLldBABMIf6/+4f 5Kv8K0rRXYWKjzDJ8vb4AQTj+0xtpPH+5+/Ae5znFVaRPn0Fh6VuZ99VnH0elh6h6R+K YnsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=qlAj6sJWPJQN1Rq+77jh6Z88sMoeMTwFiV66oFPkIMM=; b=QpDKaJS0OodtHQO+ReELme6lLZD8sLWm8y9ZNVEJwDfJRDbR4i4H21ehW5zPV0h51z w7hW4VWIL6VrZXhtoszxhdRYXVcbKpt8B0MV0KaUQgcfKomCtfACzKSheG8yVPgvlbGt R4FpuyILKHmR/wSRDNcVmCYXW77YhrrdUvIP835EfsXdwcqMEmj8DKvcffpsJVEsMv5x 13LAJ7KmvjxUAhgEmPTYyCO1LuJ2bnzDxzHQyEel2HVm+0Ukq9OB+N4qvp84rmchEnZ5 jpAtQUTKyS5oVeGx94YaIuKQr1pHV0SUOR/N7B0vg/mRpYnCOAEQZqEbLcm69mLJ653/ GeAw== X-Gm-Message-State: APf1xPDhfZJfPZdlJvmH2X466oHl3MD9IW5xOZAPsLlhN3Kyfu7XuR+8 3mJa4rFkRT9QN5+vqyY4Ymw+A8W5VhaUMy6W0yUvk48RRHA= X-Google-Smtp-Source: AG47ELtz9BegIA/3Mk0xNHX2gGJqd4J8z7Dps1nboLw0KPROsc5YjvAdstIACO7x3QhSmIqdPAKTO6QkUffLm54QVwY= X-Received: by 10.176.75.216 with SMTP id b24mr10346565uag.137.1520268136944; Mon, 05 Mar 2018 08:42:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.158.144 with HTTP; Mon, 5 Mar 2018 08:41:56 -0800 (PST) From: Marius Scurtescu Date: Mon, 5 Mar 2018 08:41:56 -0800 Message-ID: To: ID Events Mailing List , Yaron Sheffer , "Hardt, Dick" , Phillip Hunt Cc: Adam Dawes Content-Type: multipart/alternative; boundary="f403045f8bce44ace10566ad02b7" Archived-At: Subject: [Id-event] separate push and poll delivery drafts X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 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 Mar 2018 16:42:20 -0000 --f403045f8bce44ace10566ad02b7 Content-Type: text/plain; charset="UTF-8" The current delivery draft defines both a push and a poll delivery methods: https://tools.ietf.org/html/draft-ietf-secevent-delivery-02 Two issues have been raised with the current draft: 1. Many implementors raised the concern that they want to implement either push or poll, but not both. With both delivery methods in one spec optionality is tricky, the suggestion was to make them MTI, but not mandatory to deploy which is very confusing. 2. For the draft to move to Last Call status we need implementors for all parts of the draft. Currently there are push implementations, but not poll implementations. By separating them we can allow the more mature method to move forward while allowing the less mature method to be refined and gain implementation feedback. Also, by having separate specs per delivery method we set the stage for other delivery methods to be added easily. Can we add this to the agenda to be discussed in London? The discussion should answer: A. Do we have consensus for splitting the delivery spec into two? B. If yes for A, can the two new specs replace the existing spec and stay as working group drafts (this would be ideal)? As opposed to the two new specs starting from scratch as I-Ds. If it helps, I am happy to send to the list two separate specs as TXT/PDF so we have something concrete to look at. Let me know. I will not be in London, but will try to attend remotely. Thanks, Marius --f403045f8bce44ace10566ad02b7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The current delivery draft defines both a push and a poll = delivery methods:

Two issues have been raised with the curre= nt draft:

1. Many implementors raised the concern = that they want to implement either push or poll, but not both. With both de= livery methods in one spec optionality is tricky, the suggestion was to mak= e them MTI, but not mandatory to deploy which is very confusing.
=
2. For the draft to move to Last Call status we need impleme= ntors for all parts of the draft. Currently there are push implementations,= but not poll implementations. By separating them we can allow the more mat= ure method to move forward while allowing the less mature method to be refi= ned and gain implementation feedback.

Also, by hav= ing separate specs per delivery method we set the stage for other delivery = methods to be added easily.

Can we add this to the= agenda to be discussed in London?

The discussion = should answer:
A. Do we have consensus for splitting the delivery= spec into two?
B. If yes for A, can the two new specs replace th= e existing spec and stay as working group drafts (this would be ideal)? As = opposed to the two new specs starting from scratch as I-Ds.

<= /div>
If it helps, I am happy to send to the list two separate specs as= TXT/PDF so we have something concrete to look at. Let me know.
<= br>
I will not be in London, but will try to attend remotely.

Thanks,
Marius
--f403045f8bce44ace10566ad02b7-- From nobody Mon Mar 5 15:23:49 2018 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 A294B120227 for ; Mon, 5 Mar 2018 15:23:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7B0xslJmo4y for ; Mon, 5 Mar 2018 15:23:46 -0800 (PST) Received: from aserp2120.oracle.com (aserp2120.oracle.com [141.146.126.78]) (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 10BE912D873 for ; Mon, 5 Mar 2018 15:23:46 -0800 (PST) Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w25NMvP2192637; Mon, 5 Mar 2018 23:23:44 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2017-10-26; bh=4gbQAzjRGOoKmwe5hnUF+at38JHIhnh2cVIfdl2QcJE=; b=FLBNEFijdvWfqAydXmzZQQirIWKULh80HwOzJBL3wK0kKP6vVJsXJbric4eeRwVcazYs hgcGvzl7Oc74iGfABazp9sg0fbByqKR6ixnz9g5CmrkYD9CLUuVAsE4h+aWBZSHpcobp Zl6v1priYGDVlJtE+uF7/gl1T7Qk9isaDdScNHTZfOkB8TMVY6NSzNh919xVWqsFd7tE TJaH0FpLMzxQxHaTXFY+nuUP6LVQJO2YfZd+YF8g8d23H4lDcTB/90crtV7CvclmsV35 U8rYjzPqhz5RdnY/8iKAuSlvQ0BxV31bfVEBkc4Vdi5JDuc9BLwuY5RRG3GSkbfSfun4 1w== Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp2120.oracle.com with ESMTP id 2ghe3kgata-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 05 Mar 2018 23:23:44 +0000 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 w25NNhgL020350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 5 Mar 2018 23:23:43 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w25NNh8j015249; Mon, 5 Mar 2018 23:23:43 GMT Received: from [192.168.1.27] (/70.70.142.148) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 05 Mar 2018 15:23:43 -0800 Content-Type: multipart/alternative; boundary=Apple-Mail-40A08286-D90C-4F57-9090-C8B33E108711 Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (15D60) In-Reply-To: Date: Mon, 5 Mar 2018 15:23:42 -0800 Cc: SecEvent Content-Transfer-Encoding: 7bit Message-Id: <14192E4E-D1B7-49DB-A806-89E734BD24CD@oracle.com> References: <152022341213.27972.4237069562394704813@ietfa.amsl.com> <9D3011ED-8586-4DE1-91C3-E3BCB6BEDBA3@oracle.com> To: Adam Dawes X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8823 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803050266 Archived-At: Subject: Re: [Id-event] I-D Action: draft-ietf-secevent-delivery-02.txt X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 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 Mar 2018 23:23:48 -0000 --Apple-Mail-40A08286-D90C-4F57-9090-C8B33E108711 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I agree polling is expensive, however the number of streams is minimal compa= red to the users being federated. After all this is a backchannel service.=20= Push is complicated by management and status checking which occur in the opp= osite direction to the set delivery requiring mutual credential sets etc.=20= Polling on the other hand could be done with a single set of credentials for= delivery pick up and management.=20 Further polling could be made bi directional=E2=80=94>halving the number of c= onnections to support and manage.=20 I am not saying go one way or another. Just want to hi-light that both have t= heir pros and cons.=20 Ps. There are a lot of network and firewall restrictions in backchannel data= services in general. This is not exclusive to enterprise firewalls.=20 I suggest exploring more options during the week in London.=20 Phil > On Mar 4, 2018, at 10:26 PM, Adam Dawes wrote: >=20 > Generally looks fine. I think the main thing that need to be resolved is w= hat is MTI. =46rom Singapore, there was a suggestion that it be up to the tr= ansmitter to decide whether to push, pull or both. This is not ideal as some= Transmitters may support push while other Receivers may only be able to acc= ept pull. It seems there is a bit of an enterprise/consumer split here where= enterprise receivers are more likely to need pull to deal with firewalls wh= ile consumer transmitters are likely to want to support only push to protect= themselves from polling load of high number of clients.=20 >=20 > I don't see much way around this situation for the spec. It seems unreason= able to force large consumer transmitters to take high frequency polling fro= m a large number of clients and it's impossible for some enterprise receiver= s to get outside their firewall restrictions. I think the only answer is wit= h the formation of intermediary services. These can serve as a queuing mecha= nism taking the signals from consumer Transmitters and enabling polling of t= hem by enterprise Receivers. Similarly, these service providers could also p= oll for data form enterprise Transmitters that only support polling and then= post those events to consumer Receivers.=20 >=20 > I think we should accept that forcing both push and pull on the whole ecos= ystem is unreasonable and that if there is a high need for interop between c= onsumer and enterprise, service providers will step in to provide the glue.=20= >=20 >> On Sun, Mar 4, 2018 at 8:28 PM, Phil Hunt wrote: >> This document contains some minor updates from Marius in advance of IETF1= 01. The terminology for Identity Provider and Relying Party are dropped from= the definitions section as they are no longer relevant to the draft. >>=20 >> Thanks, >>=20 >> Phil >>=20 >> Oracle Corporation, Identity Cloud Services Architect >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>> On Mar 4, 2018, at 8:16 PM, internet-drafts@ietf.org wrote: >>>=20 >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >>> This draft is a work item of the Security Events WG of the IETF. >>>=20 >>> Title : SET Token Delivery Using HTTP >>> Authors : Phil Hunt >>> Marius Scurtescu >>> Morteza Ansari >>> Anthony Nadalin >>> Annabelle Richard Backman >>> Filename : draft-ietf-secevent-delivery-02.txt >>> Pages : 26 >>> Date : 2018-03-04 >>>=20 >>> Abstract: >>> This specification defines how a series of security event tokens >>> (SETs) may be delivered to a previously registered receiver using >>> HTTP POST over TLS initiated as a push to the receiver, or as a poll >>> by the receiver. The specification also defines how delivery can be >>> assured subject to the SET Token Receiver's need for assurance. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.= org_doc_draft-2Dietf-2Dsecevent-2Ddelivery_&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZ= YR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m= =3D7zJawjx-yW6HkoyQ0kPujxicrDfv4Cg8XVNoGYmvE94&s=3DVQHhRhtyrzqHrsoE9iLqwXq7x= crD53t2Glq0q1Z4kUo&e=3D >>>=20 >>> There are also htmlized versions available at: >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_ht= ml_draft-2Dietf-2Dsecevent-2Ddelivery-2D02&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZY= R8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3D= 7zJawjx-yW6HkoyQ0kPujxicrDfv4Cg8XVNoGYmvE94&s=3DI5UYs-uys-eu8x8yw__YkvhzjapH= K7e4j9NgP8ch36s&e=3D >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.= org_doc_html_draft-2Dietf-2Dsecevent-2Ddelivery-2D02&d=3DDwICAg&c=3DRoP1YumC= XCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLc= LN4KZNA&m=3D7zJawjx-yW6HkoyQ0kPujxicrDfv4Cg8XVNoGYmvE94&s=3Dwq8KOLIkIklaw-WU= Kb79-no0qzcNqz6uJlpS-5VpM2o&e=3D >>>=20 >>> A diff from the previous version is available at: >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_rfcd= iff-3Furl2-3Ddraft-2Dietf-2Dsecevent-2Ddelivery-2D02&d=3DDwICAg&c=3DRoP1YumC= XCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLc= LN4KZNA&m=3D7zJawjx-yW6HkoyQ0kPujxicrDfv4Cg8XVNoGYmvE94&s=3DzJmsq0m9g-lNJiv7= 6S48Vy0aQpIa7dSSsEslZSyfxGg&e=3D >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of submis= sion >>> until the htmlized version and diff are available at tools.ietf.org. >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> https://urldefense.proofpoint.com/v2/url?u=3Dftp-3A__ftp.ietf.org_intern= et-2Ddrafts_&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3D= na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3D7zJawjx-yW6HkoyQ0kPujxicrDfv= 4Cg8XVNoGYmvE94&s=3DkEqnjOUi11WqXEat4PujFnSrlxmgIdxCG5rOK2BwyjI&e=3D >>>=20 >>> _______________________________________________ >>> Id-event mailing list >>> Id-event@ietf.org >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail= man_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65ea= pI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3D7zJawjx-yW6HkoyQ0= kPujxicrDfv4Cg8XVNoGYmvE94&s=3D58FcylthfpumPRv2gSAssAKqfLy8P3r7LCYl1Jh8jd4&e= =3D >>=20 >>=20 >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >>=20 >=20 >=20 >=20 > --=20 > Adam Dawes | Sr. Product Manager | adawes@google.com | +1 650-214-2410 >=20 > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI= _JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3Dqx-E-WhdexG5sQGVjrd= 2O_twAAAmNFPWTX-hu-lOXRc&s=3DSMUEG_p7eYs9bej00Os13bVjLmmS9O7FNjpDt1kYMpo&e=3D= --Apple-Mail-40A08286-D90C-4F57-9090-C8B33E108711 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable I agree polling is expensive, however the n= umber of streams is minimal compared to the users being federated. After all= this is a backchannel service. 

Push is compli= cated by management and status checking which occur in the opposite directio= n to the set delivery requiring mutual credential sets etc. 
=
Polling on the other hand could be done with a single set of c= redentials for delivery pick up and management. 

Further polling could be made bi directional=E2=80=94>halving the numb= er of connections to support and manage. 

I am= not saying go one way or another. Just want to hi-light that both have thei= r pros and cons. 

Ps. There are a lot of network and firewall re= strictions in backchannel data services in general.  This is not exclus= ive to enterprise firewalls. 

I suggest explor= ing more options during the week in London. 

Phil

On Mar 4, 2018, at 10:26 PM, Adam Dawe= s <adawes@google.com> wrote:<= br>
Generally l= ooks fine. I think the main thing that need to be resolved is what is MTI. =46rom= Singapore, there was a suggestion that it be up to the transmitter to decid= e whether to push, pull or both. This is not ideal as some Transmitters may s= upport push while other Receivers may only be able to accept pull. It seems t= here is a bit of an enterprise/consumer split here where enterprise receiver= s are more likely to need pull to deal with firewalls while consumer transmi= tters are likely to want to support only push to protect themselves from pol= ling load of high number of clients. 

I don't s= ee much way around this situation for the spec. It seems unreasonable to for= ce large consumer transmitters to take high frequency polling from a large n= umber of clients and it's impossible for some enterprise receivers to get ou= tside their firewall restrictions. I think the only answer is with the forma= tion of intermediary services. These can serve as a queuing mechanism taking= the signals from consumer Transmitters and enabling polling of them by ente= rprise Receivers. Similarly, these service providers could also poll for dat= a form enterprise Transmitters that only support polling and then post those= events to consumer Receivers. 

I think we sho= uld accept that forcing both push and pull on the whole ecosystem is unreaso= nable and that if there is a high need for interop between consumer and ente= rprise, service providers will step in to provide the glue. 

On Sun, Mar 4, 20= 18 at 8:28 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #= ccc solid;padding-left:1ex">
This document contains some minor updates from Marius in ad= vance of IETF101. The terminology for Identity Provider and Relying Party ar= e dropped from the definitions section as they are no longer relevant to the= draft.

Thanks,

Phil

Oracle Corporation, Ide= ntity Cloud Services Architect
@independentid
phil.hunt@orac= le.com
=

On Mar 4, 2018, at 8= :16 PM, intern= et-drafts@ietf.org wrote:


A New Internet-Dra= ft is available from the on-line Internet-Drafts directories.
This draft i= s a work item of the Security Events WG of the IETF.

  &nb= sp;    Title        &= nbsp;  : SET Token Delivery Using HTTP
    = ;   Authors         := Phil Hunt
          &= nbsp;            = ;  Marius Scurtescu
      &= nbsp;            = ;      Morteza Ansari
  &nb= sp;            &= nbsp;         Anthony Nada= lin
           &n= bsp;            =  Annabelle Richard Backman
Filename   = ;     : draft-ietf-secevent-delivery-02.txt Pages        &nbs= p;  : 26
Date      &= nbsp;     : 2018-03-04

Abstract:
 &= nbsp;This specification defines how a series of security event tokens
&n= bsp; (SETs) may be delivered to a previously registered receiver using<= br>   HTTP POST over TLS initiated as a push to the receiver, or a= s a poll
  by the receiver.  The specification also defin= es how delivery can be
  assured subject to the SET Token Rece= iver's need for assurance.


The IETF datatracker status page for t= his draft is:
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-= 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dsecevent-2Ddelive= ry_&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI= _JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3D7= zJawjx-yW6HkoyQ0kPujxicrDfv4Cg8XVNoGYmvE94&s=3DVQHhRhtyrz= qHrsoE9iLqwXq7xcrD53t2Glq0q1Z4kUo&e=3D

= There are also htmlized versions available at:
https://urldefense.pro= ofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_html_draft-2Dietf-= 2Dsecevent-2Ddelivery-2D02&d=3DDwICAg&c=3DRoP1YumCXCg= aWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPp= uYqPkAI1aLcLN4KZNA&m=3D7zJawjx-yW6HkoyQ0kPujxicrDfv4Cg8XVNoGY<= wbr>mvE94&s=3DI5UYs-uys-eu8x8yw__YkvhzjapHK7e4j9NgP8ch36s&e=3D<= /a>
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Dsecevent-2Ddeliver= y-2D02&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65e= apI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3D= 7zJawjx-yW6HkoyQ0kPujxicrDfv4Cg8XVNoGYmvE94&s=3Dwq8KOLIkIklaw-= WUKb79-no0qzcNqz6uJlpS-5VpM2o&e=3D

A di= ff from the previous version is available at:
https://urlde= fense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_rfcdiff-3Fu= rl2-3Ddraft-2Dietf-2Dsecevent-2Ddelivery-2D02&d=3DDwICAg&c= =3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVz= BTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3D7zJawjx-yW6HkoyQ0kPu= jxicrDfv4Cg8XVNoGYmvE94&s=3DzJmsq0m9g-lNJiv76S48Vy0aQpIa7dSSsE= slZSyfxGg&e=3D


Please note that it m= ay take a couple of minutes from the time of submission
until the htmlize= d version and diff are available at tools.ietf.or= g.

Internet-Drafts are also available by anonymous FTP at:
https://urldefense.proofpoint= .com/v2/url?u=3Dftp-3A__ftp.ietf.org_internet-2Ddrafts_&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&= r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3D7zJawjx-yW6HkoyQ0kPujxicrDfv4Cg8XVNoGYmvE94&s=3DkEqnjOUi11WqXEat4Pu= jFnSrlxmgIdxCG5rOK2BwyjI&e=3D

_________= ______________________________________
Id-event mailing list
Id-event@ietf.org
= https://urldefe= nse.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listi= nfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7q= IrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcL= N4KZNA&m=3D7zJawjx-yW6HkoyQ0kPujxicrDfv4Cg8XVNoGYmvE94&s=3D= 58FcylthfpumPRv2gSAssAKqfLy8P3r7LCYl1Jh8jd4&e=3D
=


______________________________<= wbr>_________________
Id-event mailing list
Id-event@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/id-event




--
Adam Dawes | Sr. Product Manager | adaw= es@google.com |&= nbsp;+1 650-214-2410

= --Apple-Mail-40A08286-D90C-4F57-9090-C8B33E108711-- From nobody Mon Mar 5 15:27:12 2018 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 141FB126DEE for ; Mon, 5 Mar 2018 15:27:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 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, HTML_OBFUSCATE_10_20=0.093, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=no 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 sRM8QqgzQKBV for ; Mon, 5 Mar 2018 15:27:09 -0800 (PST) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::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 40079120227 for ; Mon, 5 Mar 2018 15:27:09 -0800 (PST) Received: by mail-ua0-x22f.google.com with SMTP id u99so11784652uau.8 for ; Mon, 05 Mar 2018 15:27:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BikoNHy62+qElwMX8XAJMMZO+THE/IYg9OsTF4i5KWc=; b=JggcBTgTH5cQL8oYwtYVdVdkaYe6vn/G/piMLBywBBAyLfBb/6IzYDIFdpjceavX6C B0Vev83sAfa0Q88O9S+rxK5iDGl6pLnBygutc+iGwxtkGojxO2f6vpI+9WnOrNoFQrxg Hm4q/K0/neWA4YsiIwgRplHfBfdDW8n9De8tRFQq/jP1en+aI76apoy0WypApdNrSlgf 6bp4boNyZq17vRHzHKwrhR4scbOBTWOSm8Q/ZJknadCbqRvlRWMDb76xJerezgRbFVUC GjUVjKu9+PkIoEAieBZoenFxCT9cEwCZb1JVjnhxOQ5l6UF84ECognytAIDQh6zGjaNz Ad1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BikoNHy62+qElwMX8XAJMMZO+THE/IYg9OsTF4i5KWc=; b=if5fXMFaz9LPCEuKQc+lHod/y7nGjJtMK4dVuyVJfyz6Esz80EcOBXfoQMFsbJiGxF MuaLDAH3dWbEY0oPAYuWFGgHH8/KbNbhKpqPAXAO0es0u4XvKIjWYGUFX92sOYkVlHfF wZAaNt/Eam+moH9cRuQXu2spu6Sz9JmPUDMIoCOJfv4KF8mVViu9xUZ9cmeA1js4T5WH b2L3/il7E979kFkFkhJvVJXZ9oZ9Nc8BxvYsFaRNj50UVrghxPIrNgyTt/tyfehOkKPX m1+x8A7EvWZ3Z50gqQ+xVz4jzDckBBBj4ZmNyC1iKHdTGI1u5uN+9FpA4RE/q687WbW2 PZag== X-Gm-Message-State: AElRT7HE2QRO20PJdK0qwkpjQBwzCnZM/Wn+Zb/7BqNasOdJG1o0zqUx jzMTwqZD9ZepCOC+XyxIIkyXPuxbbRRGBx73dMsoWQ== X-Google-Smtp-Source: AG47ELs9rCwEKLnZyhRyrXurcExdAQIopCBrpW7HVrYUPauX9Uu6/Qod2nwFLAe+6gz37pejgPfI/4XrtPdxfqrhNoM= X-Received: by 10.176.6.197 with SMTP id g63mr8874748uag.72.1520292427885; Mon, 05 Mar 2018 15:27:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.94.88 with HTTP; Mon, 5 Mar 2018 15:26:46 -0800 (PST) In-Reply-To: <14192E4E-D1B7-49DB-A806-89E734BD24CD@oracle.com> References: <152022341213.27972.4237069562394704813@ietfa.amsl.com> <9D3011ED-8586-4DE1-91C3-E3BCB6BEDBA3@oracle.com> <14192E4E-D1B7-49DB-A806-89E734BD24CD@oracle.com> From: Marius Scurtescu Date: Mon, 5 Mar 2018 15:26:46 -0800 Message-ID: To: Phil Hunt Cc: Adam Dawes , SecEvent Content-Type: multipart/alternative; boundary="94eb2c122e641f09d80566b2aaa9" Archived-At: Subject: Re: [Id-event] I-D Action: draft-ietf-secevent-delivery-02.txt X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 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 Mar 2018 23:27:11 -0000 --94eb2c122e641f09d80566b2aaa9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable There are definitely use cases for polling, this is not one vs the other situation. I am suggesting to decouple the two delivery methods. Marius On Mon, Mar 5, 2018 at 3:23 PM, Phil Hunt wrote: > I agree polling is expensive, however the number of streams is minimal > compared to the users being federated. After all this is a backchannel > service. > > Push is complicated by management and status checking which occur in the > opposite direction to the set delivery requiring mutual credential sets > etc. > > Polling on the other hand could be done with a single set of credentials > for delivery pick up and management. > > Further polling could be made bi directional=E2=80=94>halving the number = of > connections to support and manage. > > I am not saying go one way or another. Just want to hi-light that both > have their pros and cons. > > Ps. There are a lot of network and firewall restrictions in backchannel > data services in general. This is not exclusive to enterprise firewalls. > > I suggest exploring more options during the week in London. > > Phil > > On Mar 4, 2018, at 10:26 PM, Adam Dawes wrote: > > Generally looks fine. I think the main thing that need to be resolved is > what is MTI. From Singapore, there was a suggestion that it be up to the > transmitter to decide whether to push, pull or both. This is not ideal as > some Transmitters may support push while other Receivers may only be able > to accept pull. It seems there is a bit of an enterprise/consumer split > here where enterprise receivers are more likely to need pull to deal with > firewalls while consumer transmitters are likely to want to support only > push to protect themselves from polling load of high number of clients. > > I don't see much way around this situation for the spec. It seems > unreasonable to force large consumer transmitters to take high frequency > polling from a large number of clients and it's impossible for some > enterprise receivers to get outside their firewall restrictions. I think > the only answer is with the formation of intermediary services. These can > serve as a queuing mechanism taking the signals from consumer Transmitter= s > and enabling polling of them by enterprise Receivers. Similarly, these > service providers could also poll for data form enterprise Transmitters > that only support polling and then post those events to consumer Receiver= s. > > I think we should accept that forcing both push and pull on the whole > ecosystem is unreasonable and that if there is a high need for interop > between consumer and enterprise, service providers will step in to provid= e > the glue. > > On Sun, Mar 4, 2018 at 8:28 PM, Phil Hunt wrote: > >> This document contains some minor updates from Marius in advance of >> IETF101. The terminology for Identity Provider and Relying Party are >> dropped from the definitions section as they are no longer relevant to t= he >> draft. >> >> Thanks, >> >> Phil >> >> Oracle Corporation, Identity Cloud Services Architect >> @independentid >> www.independentid.com >> >> phil.hunt@oracle.com >> >> On Mar 4, 2018, at 8:16 PM, internet-drafts@ietf.org wrote: >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Security Events WG of the IETF. >> >> Title : SET Token Delivery Using HTTP >> Authors : Phil Hunt >> Marius Scurtescu >> Morteza Ansari >> Anthony Nadalin >> Annabelle Richard Backman >> Filename : draft-ietf-secevent-delivery-02.txt >> Pages : 26 >> Date : 2018-03-04 >> >> Abstract: >> This specification defines how a series of security event tokens >> (SETs) may be delivered to a previously registered receiver using >> HTTP POST over TLS initiated as a push to the receiver, or as a poll >> by the receiver. The specification also defines how delivery can be >> assured subject to the SET Token Receiver's need for assurance. >> >> >> The IETF datatracker status page for this draft is: >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatra >> cker.ietf.org_doc_draft-2Dietf-2Dsecevent-2Ddelivery_& >> d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5 >> FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3D7zJawjx-yW6HkoyQ0 >> kPujxicrDfv4Cg8XVNoGYmvE94&s=3DVQHhRhtyrzqHrsoE9iLqwXq7xcrD53t >> 2Glq0q1Z4kUo&e=3D >> >> There are also htmlized versions available at: >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.i >> etf.org_html_draft-2Dietf-2Dsecevent-2Ddelivery-2D02&d=3DDwICA >> g&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWm >> anqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3D7zJawjx-yW6HkoyQ0kPujxic >> rDfv4Cg8XVNoGYmvE94&s=3DI5UYs-uys-eu8x8yw__YkvhzjapHK7e4j9NgP8ch36s&e=3D >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatra >> cker.ietf.org_doc_html_draft-2Dietf-2Dsecevent-2Ddelivery- >> 2D02&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE& >> r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3D7zJawjx-yW6H >> koyQ0kPujxicrDfv4Cg8XVNoGYmvE94&s=3Dwq8KOLIkIklaw-WUKb79-no0qz >> cNqz6uJlpS-5VpM2o&e=3D >> >> A diff from the previous version is available at: >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.iet >> f.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dsecevent-2Ddelivery- >> 2D02&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE& >> r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3D7zJawjx-yW6H >> koyQ0kPujxicrDfv4Cg8XVNoGYmvE94&s=3DzJmsq0m9g-lNJiv76S48Vy0aQp >> Ia7dSSsEslZSyfxGg&e=3D >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org >> >> . >> >> Internet-Drafts are also available by anonymous FTP at: >> https://urldefense.proofpoint.com/v2/url?u=3Dftp-3A__ftp.ietf. >> org_internet-2Ddrafts_&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv >> 7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4K >> ZNA&m=3D7zJawjx-yW6HkoyQ0kPujxicrDfv4Cg8XVNoGYmvE94&s=3DkEqnjOUi >> 11WqXEat4PujFnSrlxmgIdxCG5rOK2BwyjI&e=3D >> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.iet >> f.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHv >> lZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYq >> PkAI1aLcLN4KZNA&m=3D7zJawjx-yW6HkoyQ0kPujxicrDfv4Cg8XVNoGYmvE9 >> 4&s=3D58FcylthfpumPRv2gSAssAKqfLy8P3r7LCYl1Jh8jd4&e=3D >> >> >> >> _______________________________________________ >> 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 > <(650)%20214-2410> > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www. > ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3D > RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3D > na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3Dqx-E- > WhdexG5sQGVjrd2O_twAAAmNFPWTX-hu-lOXRc&s=3DSMUEG_ > p7eYs9bej00Os13bVjLmmS9O7FNjpDt1kYMpo&e=3D > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > --94eb2c122e641f09d80566b2aaa9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There are definitely use cases for polling, this is not on= e vs the other situation.

I am suggesting to decouple th= e two delivery methods.

Marius

On Mon, Mar 5, 2018 at 3:23 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
I agree polling is expensive, however the number of = streams is minimal compared to the users being federated. After all this is= a backchannel service.=C2=A0

Push is complicated b= y management and status checking which occur in the opposite direction to t= he set delivery requiring mutual credential sets etc.=C2=A0

<= /div>
Polling on the other hand could be done with a single set of cred= entials for delivery pick up and management.=C2=A0

Further polling could be made bi directional=E2=80=94>halving the numbe= r of connections to support and manage.=C2=A0

I am= not saying go one way or another. Just want to hi-light that both have the= ir pros and cons.=C2=A0

Ps. There are a lot of network and firewall = restrictions in backchannel data services in general.=C2=A0 This is not exc= lusive to enterprise firewalls.=C2=A0

I suggest ex= ploring more options during the week in London.=C2=A0

Phil

On Mar 4, 2018, at 10:26 PM, Adam Dawes <adawes@google.com> wrote:
Generally looks= fine. I think the main thing that need to be resolved is what is MTI. From= Singapore, there was a suggestion that it be up to the transmitter to deci= de whether to push, pull or both. This is not ideal as some Transmitters ma= y support push while other Receivers may only be able to accept pull. It se= ems there is a bit of an enterprise/consumer split here where enterprise re= ceivers are more likely to need pull to deal with firewalls while consumer = transmitters are likely to want to support only push to protect themselves = from polling load of high number of clients.=C2=A0

I don't see much way around this situation for the spec. It seems unre= asonable to force large consumer transmitters to take high frequency pollin= g from a large number of clients and it's impossible for some enterpris= e receivers to get outside their firewall restrictions. I think the only an= swer is with the formation of intermediary services. These can serve as a q= ueuing mechanism taking the signals from consumer Transmitters and enabling= polling of them by enterprise Receivers. Similarly, these service provider= s could also poll for data form enterprise Transmitters that only support p= olling and then post those events to consumer Receivers.=C2=A0
I think we should accept that forcing both push and pull on th= e whole ecosystem is unreasonable and that if there is a high need for inte= rop between consumer and enterprise, service providers will step in to prov= ide the glue.=C2=A0

On Sun, Mar 4, 2018 at 8:28 PM, Phil Hunt &= lt;phil.hunt@orac= le.com> wrote:
This document contai= ns some minor updates from Marius in advance of IETF101. The terminology fo= r Identity Provider and Relying Party are dropped from the definitions sect= ion as they are no longer relevant to the draft.

Thanks,=

Phi= l

Oracle Corporation, Identity Cloud Services Arch= itect
@independentid
phil.hunt@oracle.com
=

On Mar 4, 2018, at 8:16 PM, <= a href=3D"mailto:internet-drafts@ietf.org" target=3D"_blank">internet-draft= s@ietf.org wrote:


A New Internet= -Draft is available from the on-line Internet-Drafts directories.
This d= raft is a work item of the Security Events WG of the IETF.

=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Title =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0: SET Token Delivery Using HTTP
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Authors =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0: Phil Hunt
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Marius Scurtescu
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Morteza Ansar= i
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0Anthony Nadalin
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Annabelle Richard Backman
Filename =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0: draft-ietf-secevent-delivery-02.txt
Pages =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0: 26
Date =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 2018-03-04

Abstrac= t:
=C2=A0=C2=A0This specification defines how a series of security even= t tokens
=C2=A0=C2=A0(SETs) may be delivered to a previously registered= receiver using
=C2=A0=C2=A0HTTP POST over TLS initiated as a push to t= he receiver, or as a poll
=C2=A0=C2=A0by the receiver.=C2=A0 The specif= ication also defines how delivery can be
=C2=A0=C2=A0assured subject to= the SET Token Receiver's need for assurance.


The IETF datat= racker status page for this draft is:
https://urldefense.proo= fpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dsecevent-2Ddelivery_&d=3DDwICAg&c=3DRoP1YumCXCgaWH= vlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuY= qPkAI1aLcLN4KZNA&m=3D7zJawjx-yW6HkoyQ0kPujxicrDfv4Cg8XVNoGYmv= E94&s=3DVQHhRhtyrzqHrsoE9iLqwXq7xcrD53t2Glq0q1Z4kUo&e=3D<= /a>

There are also htmlized versions available at:
<= a href=3D"https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf= .org_html_draft-2Dietf-2Dsecevent-2Ddelivery-2D02&d=3DDwICAg&c=3DRo= P1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPp= uYqPkAI1aLcLN4KZNA&m=3D7zJawjx-yW6HkoyQ0kPujxicrDfv4Cg8XVNoGYmvE94&= s=3DI5UYs-uys-eu8x8yw__YkvhzjapHK7e4j9NgP8ch36s&e=3D" target=3D"_blank"= >https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.iet= f.org_html_draft-2Dietf-2Dsecevent-2Ddelivery-2D02&d=3DDwICAg= &c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTW= manqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3D7zJawjx-yW6HkoyQ0kPujx= icrDfv4Cg8XVNoGYmvE94&s=3DI5UYs-uys-eu8x8yw__YkvhzjapHK7e4j9N= gP8ch36s&e=3D
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.org_doc_html_draft-2D= ietf-2Dsecevent-2Ddelivery-2D02&d=3DDwICAg&c=3DRoP1YumCXCgaWH<= wbr>vlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYq= PkAI1aLcLN4KZNA&m=3D7zJawjx-yW6HkoyQ0kPujxicrDfv4Cg8XVNoGYmvE= 94&s=3Dwq8KOLIkIklaw-WUKb79-no0qzcNqz6uJlpS-5VpM2o&e=3D

A diff from the previous version is available at:
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__ww= w.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dsecevent-2Ddelivery-2D02&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI= _JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3D= 7zJawjx-yW6HkoyQ0kPujxicrDfv4Cg8XVNoGYmvE94&s=3DzJmsq0m9g-lNJ= iv76S48Vy0aQpIa7dSSsEslZSyfxGg&e=3D


Please no= te that it may take a couple of minutes from the time of submission
unti= l the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anon= ymous FTP at:
http= s://urldefense.proofpoint.com/v2/url?u=3Dftp-3A__ftp.ietf.org_int= ernet-2Ddrafts_&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv= 7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3D7zJawjx-yW6HkoyQ0kPujxicrDfv4Cg8XVNoGYmvE94&s=3DkEqnj= OUi11WqXEat4PujFnSrlxmgIdxCG5rOK2BwyjI&e=3D

= _______________________________________________
Id-event mailing li= st
Id-event@ietf.= org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.= org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHv= lZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYq= PkAI1aLcLN4KZNA&m=3D7zJawjx-yW6HkoyQ0kPujxicrDfv4Cg8XVNoGYmvE= 94&s=3D58FcylthfpumPRv2gSAssAKqfLy8P3r7LCYl1Jh8jd4&e=3D


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




--
Adam Dawes=C2=A0|=C2=A0Sr. Product Manager=C2=A0|=C2=A0adawes@google.com=C2=A0|=C2=A0+1 650-214-2410

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


--94eb2c122e641f09d80566b2aaa9-- From nobody Mon Mar 5 15:36:51 2018 Return-Path: X-Original-To: id-event@ietf.org Delivered-To: id-event@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C96EA1200C5; Mon, 5 Mar 2018 15:36:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Yaron Sheffer To: X-Test-IDTracker: no X-IETF-IDTracker: 6.74.0 Auto-Submitted: auto-generated Precedence: bulk Cc: secevent-chairs@ietf.org, yaronf.ietf@gmail.com, Yaron Sheffer , iesg-secretary@ietf.org, id-event@ietf.org Message-ID: <152029300980.12879.15509649143975179203.idtracker@ietfa.amsl.com> Date: Mon, 05 Mar 2018 15:36:49 -0800 Archived-At: Subject: [Id-event] Publication has been requested for draft-ietf-secevent-token-07 X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 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 Mar 2018 23:36:50 -0000 Yaron Sheffer has requested publication of draft-ietf-secevent-token-07 as Proposed Standard on behalf of the SECEVENT working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-secevent-token/ From nobody Mon Mar 5 16:07:59 2018 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 CD5A0126B72 for ; Mon, 5 Mar 2018 16:07:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.808 X-Spam-Level: X-Spam-Status: No, score=-11.808 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12ysSkyiiIUD for ; Mon, 5 Mar 2018 16:07:54 -0800 (PST) Received: from smtp-fw-6002.amazon.com (smtp-fw-6002.amazon.com [52.95.49.90]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E57FD1200C5 for ; Mon, 5 Mar 2018 16:07:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1520294873; x=1551830873; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=04GOWhZNYOXsyShH8sSe5IUdo9Z8yeIzhd3ERkePsfo=; b=Ao16QtATOS0GHIeWVAsJJOZG9ztF7PNVT94e3487/8FVL35SX+NU4lkh vHXX2jFCUquWLrLCCoAxtlWJgi4+zlrKQZ3uGA3ij2ZG34XDc/MjFckKF UzQJMRdWrRgoa83SE6xbIvyxLWbTC3M1GNcs2DlbNMBX9iLZt1HFWRTne I=; X-IronPort-AV: E=Sophos;i="5.47,429,1515456000"; d="scan'208,217";a="334492949" Received: from iad6-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-1d-f273de60.us-east-1.amazon.com) ([10.124.125.6]) by smtp-border-fw-out-6002.iad6.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Mar 2018 00:07:52 +0000 Received: from EX13MTAUWC001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan3.iad.amazon.com [10.40.159.166]) by email-inbound-relay-1d-f273de60.us-east-1.amazon.com (8.14.7/8.14.7) with ESMTP id w2607jTi102051 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 6 Mar 2018 00:07:50 GMT Received: from EX13D11UWC002.ant.amazon.com (10.43.162.174) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Tue, 6 Mar 2018 00:07:50 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC002.ant.amazon.com (10.43.162.174) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Tue, 6 Mar 2018 00:07:49 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1236.000; Tue, 6 Mar 2018 00:07:49 +0000 From: "Richard Backman, Annabelle" To: Marius Scurtescu , Phil Hunt CC: Adam Dawes , SecEvent Thread-Topic: [Id-event] I-D Action: draft-ietf-secevent-delivery-02.txt Thread-Index: AQHTtDjYmpgbSbg55ESWebLcZs9+hqPBDFeAgAAhAgCAARw0AIAAANwA//+FW4A= Date: Tue, 6 Mar 2018 00:07:49 +0000 Message-ID: <8C851BC8-00EB-4D7B-9820-5BCECFF78DCB@amazon.com> References: <152022341213.27972.4237069562394704813@ietfa.amsl.com> <9D3011ED-8586-4DE1-91C3-E3BCB6BEDBA3@oracle.com> <14192E4E-D1B7-49DB-A806-89E734BD24CD@oracle.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.a.0.180210 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.161.235] Content-Type: multipart/alternative; boundary="_000_8C851BC800EB4D7B98205BCECFF78DCBamazoncom_" MIME-Version: 1.0 Precedence: Bulk Archived-At: Subject: Re: [Id-event] I-D Action: draft-ietf-secevent-delivery-02.txt X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 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: Tue, 06 Mar 2018 00:07:58 -0000 --_000_8C851BC800EB4D7B98205BCECFF78DCBamazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEgdG8gZGVjb3VwbGluZyB0aGVtLiBUaGVyZSBhcmUgc3Ryb25nIHVzZSBjYXNlcyBmb3IgZWFj aCBpbmRlcGVuZGVudCBvZiB0aGUgb3RoZXIuIE5vdGhpbmcgc3RvcHMgdHJhbnNtaXR0ZXJzIGZy b20gaW1wbGVtZW50aW5nIGJvdGggZm9yIGNhc2VzIHRoYXQgd2FycmFudCBpdC4NCg0KLS0NCkFu bmFiZWxsZSBSaWNoYXJkIEJhY2ttYW4NCkFtYXpvbiDigJMgSWRlbnRpdHkgU2VydmljZXMNCg0K RnJvbTogSWQtZXZlbnQgPGlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBN YXJpdXMgU2N1cnRlc2N1IDxtc2N1cnRlc2N1QGdvb2dsZS5jb20+DQpEYXRlOiBNb25kYXksIE1h cmNoIDUsIDIwMTggYXQgMzoyNyBQTQ0KVG86IFBoaWwgSHVudCA8cGhpbC5odW50QG9yYWNsZS5j b20+DQpDYzogQWRhbSBEYXdlcyA8YWRhd2VzQGdvb2dsZS5jb20+LCBTZWNFdmVudCA8aWQtZXZl bnRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0lkLWV2ZW50XSBJLUQgQWN0aW9uOiBkcmFmdC1p ZXRmLXNlY2V2ZW50LWRlbGl2ZXJ5LTAyLnR4dA0KDQpUaGVyZSBhcmUgZGVmaW5pdGVseSB1c2Ug Y2FzZXMgZm9yIHBvbGxpbmcsIHRoaXMgaXMgbm90IG9uZSB2cyB0aGUgb3RoZXIgc2l0dWF0aW9u Lg0KDQpJIGFtIHN1Z2dlc3RpbmcgdG8gZGVjb3VwbGUgdGhlIHR3byBkZWxpdmVyeSBtZXRob2Rz Lg0KDQpNYXJpdXMNCg0KT24gTW9uLCBNYXIgNSwgMjAxOCBhdCAzOjIzIFBNLCBQaGlsIEh1bnQg PHBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+IHdyb3Rl Og0KSSBhZ3JlZSBwb2xsaW5nIGlzIGV4cGVuc2l2ZSwgaG93ZXZlciB0aGUgbnVtYmVyIG9mIHN0 cmVhbXMgaXMgbWluaW1hbCBjb21wYXJlZCB0byB0aGUgdXNlcnMgYmVpbmcgZmVkZXJhdGVkLiBB ZnRlciBhbGwgdGhpcyBpcyBhIGJhY2tjaGFubmVsIHNlcnZpY2UuDQoNClB1c2ggaXMgY29tcGxp Y2F0ZWQgYnkgbWFuYWdlbWVudCBhbmQgc3RhdHVzIGNoZWNraW5nIHdoaWNoIG9jY3VyIGluIHRo ZSBvcHBvc2l0ZSBkaXJlY3Rpb24gdG8gdGhlIHNldCBkZWxpdmVyeSByZXF1aXJpbmcgbXV0dWFs IGNyZWRlbnRpYWwgc2V0cyBldGMuDQoNClBvbGxpbmcgb24gdGhlIG90aGVyIGhhbmQgY291bGQg YmUgZG9uZSB3aXRoIGEgc2luZ2xlIHNldCBvZiBjcmVkZW50aWFscyBmb3IgZGVsaXZlcnkgcGlj ayB1cCBhbmQgbWFuYWdlbWVudC4NCg0KRnVydGhlciBwb2xsaW5nIGNvdWxkIGJlIG1hZGUgYmkg ZGlyZWN0aW9uYWzigJQ+aGFsdmluZyB0aGUgbnVtYmVyIG9mIGNvbm5lY3Rpb25zIHRvIHN1cHBv cnQgYW5kIG1hbmFnZS4NCg0KSSBhbSBub3Qgc2F5aW5nIGdvIG9uZSB3YXkgb3IgYW5vdGhlci4g SnVzdCB3YW50IHRvIGhpLWxpZ2h0IHRoYXQgYm90aCBoYXZlIHRoZWlyIHByb3MgYW5kIGNvbnMu DQoNClBzLiBUaGVyZSBhcmUgYSBsb3Qgb2YgbmV0d29yayBhbmQgZmlyZXdhbGwgcmVzdHJpY3Rp b25zIGluIGJhY2tjaGFubmVsIGRhdGEgc2VydmljZXMgaW4gZ2VuZXJhbC4gIFRoaXMgaXMgbm90 IGV4Y2x1c2l2ZSB0byBlbnRlcnByaXNlIGZpcmV3YWxscy4NCg0KSSBzdWdnZXN0IGV4cGxvcmlu ZyBtb3JlIG9wdGlvbnMgZHVyaW5nIHRoZSB3ZWVrIGluIExvbmRvbi4NCg0KUGhpbA0KDQpPbiBN YXIgNCwgMjAxOCwgYXQgMTA6MjYgUE0sIEFkYW0gRGF3ZXMgPGFkYXdlc0Bnb29nbGUuY29tPG1h aWx0bzphZGF3ZXNAZ29vZ2xlLmNvbT4+IHdyb3RlOg0KR2VuZXJhbGx5IGxvb2tzIGZpbmUuIEkg dGhpbmsgdGhlIG1haW4gdGhpbmcgdGhhdCBuZWVkIHRvIGJlIHJlc29sdmVkIGlzIHdoYXQgaXMg TVRJLiBGcm9tIFNpbmdhcG9yZSwgdGhlcmUgd2FzIGEgc3VnZ2VzdGlvbiB0aGF0IGl0IGJlIHVw IHRvIHRoZSB0cmFuc21pdHRlciB0byBkZWNpZGUgd2hldGhlciB0byBwdXNoLCBwdWxsIG9yIGJv dGguIFRoaXMgaXMgbm90IGlkZWFsIGFzIHNvbWUgVHJhbnNtaXR0ZXJzIG1heSBzdXBwb3J0IHB1 c2ggd2hpbGUgb3RoZXIgUmVjZWl2ZXJzIG1heSBvbmx5IGJlIGFibGUgdG8gYWNjZXB0IHB1bGwu IEl0IHNlZW1zIHRoZXJlIGlzIGEgYml0IG9mIGFuIGVudGVycHJpc2UvY29uc3VtZXIgc3BsaXQg aGVyZSB3aGVyZSBlbnRlcnByaXNlIHJlY2VpdmVycyBhcmUgbW9yZSBsaWtlbHkgdG8gbmVlZCBw dWxsIHRvIGRlYWwgd2l0aCBmaXJld2FsbHMgd2hpbGUgY29uc3VtZXIgdHJhbnNtaXR0ZXJzIGFy ZSBsaWtlbHkgdG8gd2FudCB0byBzdXBwb3J0IG9ubHkgcHVzaCB0byBwcm90ZWN0IHRoZW1zZWx2 ZXMgZnJvbSBwb2xsaW5nIGxvYWQgb2YgaGlnaCBudW1iZXIgb2YgY2xpZW50cy4NCg0KSSBkb24n dCBzZWUgbXVjaCB3YXkgYXJvdW5kIHRoaXMgc2l0dWF0aW9uIGZvciB0aGUgc3BlYy4gSXQgc2Vl bXMgdW5yZWFzb25hYmxlIHRvIGZvcmNlIGxhcmdlIGNvbnN1bWVyIHRyYW5zbWl0dGVycyB0byB0 YWtlIGhpZ2ggZnJlcXVlbmN5IHBvbGxpbmcgZnJvbSBhIGxhcmdlIG51bWJlciBvZiBjbGllbnRz IGFuZCBpdCdzIGltcG9zc2libGUgZm9yIHNvbWUgZW50ZXJwcmlzZSByZWNlaXZlcnMgdG8gZ2V0 IG91dHNpZGUgdGhlaXIgZmlyZXdhbGwgcmVzdHJpY3Rpb25zLiBJIHRoaW5rIHRoZSBvbmx5IGFu c3dlciBpcyB3aXRoIHRoZSBmb3JtYXRpb24gb2YgaW50ZXJtZWRpYXJ5IHNlcnZpY2VzLiBUaGVz ZSBjYW4gc2VydmUgYXMgYSBxdWV1aW5nIG1lY2hhbmlzbSB0YWtpbmcgdGhlIHNpZ25hbHMgZnJv bSBjb25zdW1lciBUcmFuc21pdHRlcnMgYW5kIGVuYWJsaW5nIHBvbGxpbmcgb2YgdGhlbSBieSBl bnRlcnByaXNlIFJlY2VpdmVycy4gU2ltaWxhcmx5LCB0aGVzZSBzZXJ2aWNlIHByb3ZpZGVycyBj b3VsZCBhbHNvIHBvbGwgZm9yIGRhdGEgZm9ybSBlbnRlcnByaXNlIFRyYW5zbWl0dGVycyB0aGF0 IG9ubHkgc3VwcG9ydCBwb2xsaW5nIGFuZCB0aGVuIHBvc3QgdGhvc2UgZXZlbnRzIHRvIGNvbnN1 bWVyIFJlY2VpdmVycy4NCg0KSSB0aGluayB3ZSBzaG91bGQgYWNjZXB0IHRoYXQgZm9yY2luZyBi b3RoIHB1c2ggYW5kIHB1bGwgb24gdGhlIHdob2xlIGVjb3N5c3RlbSBpcyB1bnJlYXNvbmFibGUg YW5kIHRoYXQgaWYgdGhlcmUgaXMgYSBoaWdoIG5lZWQgZm9yIGludGVyb3AgYmV0d2VlbiBjb25z dW1lciBhbmQgZW50ZXJwcmlzZSwgc2VydmljZSBwcm92aWRlcnMgd2lsbCBzdGVwIGluIHRvIHBy b3ZpZGUgdGhlIGdsdWUuDQoNCk9uIFN1biwgTWFyIDQsIDIwMTggYXQgODoyOCBQTSwgUGhpbCBI dW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+PiB3 cm90ZToNClRoaXMgZG9jdW1lbnQgY29udGFpbnMgc29tZSBtaW5vciB1cGRhdGVzIGZyb20gTWFy aXVzIGluIGFkdmFuY2Ugb2YgSUVURjEwMS4gVGhlIHRlcm1pbm9sb2d5IGZvciBJZGVudGl0eSBQ cm92aWRlciBhbmQgUmVseWluZyBQYXJ0eSBhcmUgZHJvcHBlZCBmcm9tIHRoZSBkZWZpbml0aW9u cyBzZWN0aW9uIGFzIHRoZXkgYXJlIG5vIGxvbmdlciByZWxldmFudCB0byB0aGUgZHJhZnQuDQoN ClRoYW5rcywNCg0KUGhpbA0KDQpPcmFjbGUgQ29ycG9yYXRpb24sIElkZW50aXR5IENsb3VkIFNl cnZpY2VzIEFyY2hpdGVjdA0KQGluZGVwZW5kZW50aWQNCnd3dy5pbmRlcGVuZGVudGlkLmNvbTxo dHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9fd3d3Lmlu ZGVwZW5kZW50aWQuY29tJmQ9RHdNRmFRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUly TVVCNjVlYXBJX0puRSZyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEta TkEmbT1xeC1FLVdoZGV4RzVzUUdWanJkMk9fdHdBQUFtTkZQV1RYLWh1LWxPWFJjJnM9ZTh3RzdG UVZRTUJJR1FUSmgwZXUzUE5yYzdJMFFmdTdfa0xnTVdSYUdhWSZlPT4NCnBoaWwuaHVudEBvcmFj bGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4NCg0KDQpPbiBNYXIgNCwgMjAxOCwg YXQgODoxNiBQTSwgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmc+IHdyb3RlOg0KDQoNCkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJs ZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NClRoaXMgZHJh ZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIFNlY3VyaXR5IEV2ZW50cyBXRyBvZiB0aGUgSUVURi4N Cg0KICAgICAgIFRpdGxlICAgICAgICAgICA6IFNFVCBUb2tlbiBEZWxpdmVyeSBVc2luZyBIVFRQ DQogICAgICAgQXV0aG9ycyAgICAgICAgIDogUGhpbCBIdW50DQogICAgICAgICAgICAgICAgICAg ICAgICAgTWFyaXVzIFNjdXJ0ZXNjdQ0KICAgICAgICAgICAgICAgICAgICAgICAgIE1vcnRlemEg QW5zYXJpDQogICAgICAgICAgICAgICAgICAgICAgICAgQW50aG9ueSBOYWRhbGluDQogICAgICAg ICAgICAgICAgICAgICAgICAgQW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbg0KRmlsZW5hbWUgICAg ICAgIDogZHJhZnQtaWV0Zi1zZWNldmVudC1kZWxpdmVyeS0wMi50eHQNClBhZ2VzICAgICAgICAg ICA6IDI2DQpEYXRlICAgICAgICAgICAgOiAyMDE4LTAzLTA0DQoNCkFic3RyYWN0Og0KICBUaGlz IHNwZWNpZmljYXRpb24gZGVmaW5lcyBob3cgYSBzZXJpZXMgb2Ygc2VjdXJpdHkgZXZlbnQgdG9r ZW5zDQogIChTRVRzKSBtYXkgYmUgZGVsaXZlcmVkIHRvIGEgcHJldmlvdXNseSByZWdpc3RlcmVk IHJlY2VpdmVyIHVzaW5nDQogIEhUVFAgUE9TVCBvdmVyIFRMUyBpbml0aWF0ZWQgYXMgYSBwdXNo IHRvIHRoZSByZWNlaXZlciwgb3IgYXMgYSBwb2xsDQogIGJ5IHRoZSByZWNlaXZlci4gIFRoZSBz cGVjaWZpY2F0aW9uIGFsc28gZGVmaW5lcyBob3cgZGVsaXZlcnkgY2FuIGJlDQogIGFzc3VyZWQg c3ViamVjdCB0byB0aGUgU0VUIFRva2VuIFJlY2VpdmVyJ3MgbmVlZCBmb3IgYXNzdXJhbmNlLg0K DQoNClRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0K aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19kYXRh dHJhY2tlci5pZXRmLm9yZ19kb2NfZHJhZnQtMkRpZXRmLTJEc2VjZXZlbnQtMkRkZWxpdmVyeV8m ZD1Ed0lDQWcmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJnI9 bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZtPTd6SmF3angteVc2 SGtveVEwa1B1anhpY3JEZnY0Q2c4WFZOb0dZbXZFOTQmcz1WUUhoUmh0eXJ6cUhyc29FOWlMcXdY cTd4Y3JENTN0MkdscTBxMVo0a1VvJmU9DQoNClRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNp b25zIGF2YWlsYWJsZSBhdDoNCmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91 cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9kcmFmdC0yRGlldGYtMkRzZWNldmVu dC0yRGRlbGl2ZXJ5LTJEMDImZD1Ed0lDQWcmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdx SXJNVUI2NWVhcElfSm5FJnI9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40 S1pOQSZtPTd6SmF3angteVc2SGtveVEwa1B1anhpY3JEZnY0Q2c4WFZOb0dZbXZFOTQmcz1JNVVZ cy11eXMtZXU4eDh5d19fWWt2aHpqYXBISzdlNGo5TmdQOGNoMzZzJmU9DQpodHRwczovL3VybGRl ZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX2RhdGF0cmFja2VyLmlldGYu b3JnX2RvY19odG1sX2RyYWZ0LTJEaWV0Zi0yRHNlY2V2ZW50LTJEZGVsaXZlcnktMkQwMiZkPUR3 SUNBZyZjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmcj1uYTVG VnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJm09N3pKYXdqeC15VzZIa295 UTBrUHVqeGljckRmdjRDZzhYVk5vR1ltdkU5NCZzPXdxOEtPTElrSWtsYXctV1VLYjc5LW5vMHF6 Y05xejZ1SmxwUy01VnBNMm8mZT0NCg0KQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24g aXMgYXZhaWxhYmxlIGF0Og0KaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy bD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfcmZjZGlmZi0zRnVybDItM0RkcmFmdC0yRGlldGYt MkRzZWNldmVudC0yRGRlbGl2ZXJ5LTJEMDImZD1Ed0lDQWcmYz1Sb1AxWXVtQ1hDZ2FXSHZsWllS OFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJnI9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBr QUkxYUxjTE40S1pOQSZtPTd6SmF3angteVc2SGtveVEwa1B1anhpY3JEZnY0Q2c4WFZOb0dZbXZF OTQmcz16Sm1zcTBtOWctbE5KaXY3NlM0OFZ5MGFRcElhN2RTU3NFc2xaU3lmeEdnJmU9DQoNCg0K UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhl IHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYg YXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZzxodHRwczovL3VybGRlZmVuc2UucHJvb2Zw b2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9fdG9vbHMuaWV0Zi5vcmcmZD1Ed01GYVEmYz1Sb1Ax WXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJnI9bmE1RlZ6QlRXbWFucVdO eTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZtPXF4LUUtV2hkZXhHNXNRR1ZqcmQyT190d0FB QW1ORlBXVFgtaHUtbE9YUmMmcz1XbFg5U1dmZDVOMnNfZ1BMY1NKZW5xcE5na0dOdXNjaXNhU1M2 bnNVc3FzJmU9Pi4NCg0KSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9u eW1vdXMgRlRQIGF0Og0KaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91 PWZ0cC0zQV9fZnRwLmlldGYub3JnX2ludGVybmV0LTJEZHJhZnRzXyZkPUR3SUNBZyZjPVJvUDFZ dW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmcj1uYTVGVnpCVFdtYW5xV055 NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJm09N3pKYXdqeC15VzZIa295UTBrUHVqeGljckRm djRDZzhYVk5vR1ltdkU5NCZzPWtFcW5qT1VpMTFXcVhFYXQ0UHVqRm5Tcmx4bWdJZHhDRzVyT0sy Qnd5akkmZT0NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCklkLWV2ZW50IG1haWxpbmcgbGlzdA0KSWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2 ZW50QGlldGYub3JnPg0KaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91 PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmQ9RHdJ Q0FnJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZyPW5hNUZW ekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmbT03ekphd2p4LXlXNkhrb3lR MGtQdWp4aWNyRGZ2NENnOFhWTm9HWW12RTk0JnM9NThGY3lsdGhmcHVtUFJ2MmdTQXNzQUtxZkx5 OFAzcjdMQ1lsMUpoOGpkNCZlPQ0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpJZC1ldmVudCBtYWlsaW5nIGxpc3QNCklkLWV2ZW50QGlldGYub3Jn PG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vaWQtZXZlbnQ8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy bD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0yRGV2ZW50JmQ9 RHdNRmFRJmM9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZyPW5h NUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmbT1xeC1FLVdoZGV4RzVz UUdWanJkMk9fdHdBQUFtTkZQV1RYLWh1LWxPWFJjJnM9U01VRUdfcDdlWXM5YmVqMDBPczEzYlZq TG1tUzlPN0ZOanBEdDFrWU1wbyZlPT4NCg0KDQoNCi0tDQpBZGFtIERhd2VzIHwgU3IuIFByb2R1 Y3QgTWFuYWdlciB8IGFkYXdlc0Bnb29nbGUuY29tPG1haWx0bzphZGF3ZXNAZ29vZ2xlLmNvbT4g fCArMSA2NTAtMjE0LTI0MTA8dGVsOig2NTApJTIwMjE0LTI0MTA+DQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJZC1ldmVudCBtYWlsaW5nIGxpc3QN CklkLWV2ZW50QGlldGYub3JnPG1haWx0bzpJZC1ldmVudEBpZXRmLm9yZz4NCmh0dHBzOi8vdXJs ZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21h aWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZkPUR3SUNBZyZjPVJvUDFZdW1DWENnYVdIdmxaWVI4 UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmcj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtB STFhTGNMTjRLWk5BJm09cXgtRS1XaGRleEc1c1FHVmpyZDJPX3R3QUFBbU5GUFdUWC1odS1sT1hS YyZzPVNNVUVHX3A3ZVlzOWJlajAwT3MxM2JWakxtbVM5TzdGTmpwRHQxa1lNcG8mZT0NCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklkLWV2ZW50IG1h aWxpbmcgbGlzdA0KSWQtZXZlbnRAaWV0Zi5vcmc8bWFpbHRvOklkLWV2ZW50QGlldGYub3JnPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudA0KDQo= --_000_8C851BC800EB4D7B98205BCECFF78DCBamazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <9823A2D2A6384843AE86FB09669A0E54@amazon.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5t NjU1NTkwNzkyNDk0OTg1MjkyMG02OTAwNjk2NDQ3MzMxNjgxNDAwYXBwbGUtc3R5bGUtc3Bhbg0K CXttc28tc3R5bGUtbmFtZTptXzY1NTU5MDc5MjQ5NDk4NTI5MjBtXzY5MDA2OTY0NDczMzE2ODE0 MDBhcHBsZS1zdHlsZS1zcGFuO30NCnNwYW4ubTY1NTU5MDc5MjQ5NDk4NTI5MjBtNjkwMDY5NjQ0 NzMzMTY4MTQwMGFwcGxlLXRhYi1zcGFuDQoJe21zby1zdHlsZS1uYW1lOm1fNjU1NTkwNzkyNDk0 OTg1MjkyMG1fNjkwMDY5NjQ0NzMzMTY4MTQwMGFwcGxlLXRhYi1zcGFuO30NCnNwYW4uRW1haWxT dHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGlu IDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mIzQzOzEgdG8gZGVjb3VwbGluZyB0aGVtLiBUaGVyZSBhcmUgc3Ryb25nIHVzZSBjYXNl cyBmb3IgZWFjaCBpbmRlcGVuZGVudCBvZiB0aGUgb3RoZXIuIE5vdGhpbmcgc3RvcHMgdHJhbnNt aXR0ZXJzIGZyb20gaW1wbGVtZW50aW5nIGJvdGggZm9yIGNhc2VzIHRoYXQgd2FycmFudCBpdC48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+LS0mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssc2VyaWYiPkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPkFtYXpvbiDigJMgSWRl bnRpdHkgU2VydmljZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Y29sb3I6YmxhY2siPklkLWV2ZW50ICZsdDtpZC1ldmVudC1ib3VuY2VzQGlldGYub3JnJmd0 OyBvbiBiZWhhbGYgb2YgTWFyaXVzIFNjdXJ0ZXNjdSAmbHQ7bXNjdXJ0ZXNjdUBnb29nbGUuY29t Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5Nb25kYXksIE1hcmNoIDUsIDIwMTggYXQgMzoyNyBQTTxi cj4NCjxiPlRvOiA8L2I+UGhpbCBIdW50ICZsdDtwaGlsLmh1bnRAb3JhY2xlLmNvbSZndDs8YnI+ DQo8Yj5DYzogPC9iPkFkYW0gRGF3ZXMgJmx0O2FkYXdlc0Bnb29nbGUuY29tJmd0OywgU2VjRXZl bnQgJmx0O2lkLWV2ZW50QGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW0lk LWV2ZW50XSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXNlY2V2ZW50LWRlbGl2ZXJ5LTAyLnR4dDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGEgbmFtZT0iX01haWxPcmlnaW5hbEJvZHkiPlRoZXJlIGFyZSBkZWZpbml0ZWx5IHVzZSBj YXNlcyBmb3IgcG9sbGluZywgdGhpcyBpcyBub3Qgb25lIHZzIHRoZSBvdGhlciBzaXR1YXRpb24u DQo8bzpwPjwvbzpwPjwvYT48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+SSBhbSBzdWdnZXN0aW5nIHRvIGRl Y291cGxlIHRoZSB0d28gZGVsaXZlcnkgbWV0aG9kcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJt c28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+TWFyaXVzPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJv b2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5PbiBNb24sIE1hciA1LCAyMDE4IGF0IDM6MjMgUE0s IFBoaWwgSHVudCAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5h bEJvZHkiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21h cms6X01haWxPcmlnaW5hbEJvZHkiPjwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFy azpfTWFpbE9yaWdpbmFsQm9keSI+Jmd0Ow0KIHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1z by1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+SSBhZ3JlZSBwb2xsaW5nIGlzIGV4cGVuc2l2 ZSwgaG93ZXZlciB0aGUgbnVtYmVyIG9mIHN0cmVhbXMgaXMgbWluaW1hbCBjb21wYXJlZCB0byB0 aGUgdXNlcnMgYmVpbmcgZmVkZXJhdGVkLiBBZnRlciBhbGwgdGhpcyBpcyBhIGJhY2tjaGFubmVs IHNlcnZpY2UuJm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5h bEJvZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJv ZHkiPlB1c2ggaXMgY29tcGxpY2F0ZWQgYnkgbWFuYWdlbWVudCBhbmQgc3RhdHVzIGNoZWNraW5n IHdoaWNoIG9jY3VyIGluIHRoZSBvcHBvc2l0ZSBkaXJlY3Rpb24gdG8gdGhlIHNldCBkZWxpdmVy eSByZXF1aXJpbmcgbXV0dWFsIGNyZWRlbnRpYWwgc2V0cyBldGMuJm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+UG9sbGluZyBvbiB0aGUgb3RoZXIgaGFu ZCBjb3VsZCBiZSBkb25lIHdpdGggYSBzaW5nbGUgc2V0IG9mIGNyZWRlbnRpYWxzIGZvciBkZWxp dmVyeSBwaWNrIHVwIGFuZCBtYW5hZ2VtZW50LiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9v a21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21h cms6X01haWxPcmlnaW5hbEJvZHkiPkZ1cnRoZXIgcG9sbGluZyBjb3VsZCBiZSBtYWRlIGJpIGRp cmVjdGlvbmFs4oCUJmd0O2hhbHZpbmcgdGhlIG51bWJlciBvZiBjb25uZWN0aW9ucyB0byBzdXBw b3J0IGFuZCBtYW5hZ2UuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9y aWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdp bmFsQm9keSI+SSBhbSBub3Qgc2F5aW5nIGdvIG9uZSB3YXkgb3IgYW5vdGhlci4gSnVzdCB3YW50 IHRvIGhpLWxpZ2h0IHRoYXQgYm90aCBoYXZlIHRoZWlyIHByb3MgYW5kIGNvbnMuJm5ic3A7PGJy Pg0KPGJyPg0KUHMuIFRoZXJlIGFyZSBhIGxvdCBvZiBuZXR3b3JrIGFuZCBmaXJld2FsbCByZXN0 cmljdGlvbnMgaW4gYmFja2NoYW5uZWwgZGF0YSBzZXJ2aWNlcyBpbiBnZW5lcmFsLiZuYnNwOyBU aGlzIGlzIG5vdCBleGNsdXNpdmUgdG8gZW50ZXJwcmlzZSBmaXJld2FsbHMuJm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+SSBzdWdnZXN0IGV4cGxvcmlu ZyBtb3JlIG9wdGlvbnMgZHVyaW5nIHRoZSB3ZWVrIGluIExvbmRvbi4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2IGlkPSJtXzY1NTU5MDc5MjQ5NDk4NTI5MjBBcHBsZU1haWxTaWduYXR1 cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFp bE9yaWdpbmFsQm9keSI+UGhpbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48YnI+ DQpPbiBNYXIgNCwgMjAxOCwgYXQgMTA6MjYgUE0sIEFkYW0gRGF3ZXMgJmx0Ozwvc3Bhbj48YSBo cmVmPSJtYWlsdG86YWRhd2VzQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHls ZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5hZGF3ZXNAZ29vZ2xlLmNvbTwvc3Bh bj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48L3NwYW4+PC9h PjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPiZndDsNCiB3cm90 ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdp bmFsQm9keSI+R2VuZXJhbGx5IGxvb2tzIGZpbmUuIEkgdGhpbmsgdGhlIG1haW4gdGhpbmcgdGhh dCBuZWVkIHRvIGJlIHJlc29sdmVkIGlzIHdoYXQgaXMgTVRJLiBGcm9tIFNpbmdhcG9yZSwgdGhl cmUgd2FzIGEgc3VnZ2VzdGlvbiB0aGF0IGl0IGJlIHVwIHRvIHRoZSB0cmFuc21pdHRlciB0byBk ZWNpZGUgd2hldGhlciB0byBwdXNoLCBwdWxsIG9yDQogYm90aC4gVGhpcyBpcyBub3QgaWRlYWwg YXMgc29tZSBUcmFuc21pdHRlcnMgbWF5IHN1cHBvcnQgcHVzaCB3aGlsZSBvdGhlciBSZWNlaXZl cnMgbWF5IG9ubHkgYmUgYWJsZSB0byBhY2NlcHQgcHVsbC4gSXQgc2VlbXMgdGhlcmUgaXMgYSBi aXQgb2YgYW4gZW50ZXJwcmlzZS9jb25zdW1lciBzcGxpdCBoZXJlIHdoZXJlIGVudGVycHJpc2Ug cmVjZWl2ZXJzIGFyZSBtb3JlIGxpa2VseSB0byBuZWVkIHB1bGwgdG8gZGVhbCB3aXRoIGZpcmV3 YWxscw0KIHdoaWxlIGNvbnN1bWVyIHRyYW5zbWl0dGVycyBhcmUgbGlrZWx5IHRvIHdhbnQgdG8g c3VwcG9ydCBvbmx5IHB1c2ggdG8gcHJvdGVjdCB0aGVtc2VsdmVzIGZyb20gcG9sbGluZyBsb2Fk IG9mIGhpZ2ggbnVtYmVyIG9mIGNsaWVudHMuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29r bWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFy azpfTWFpbE9yaWdpbmFsQm9keSI+SSBkb24ndCBzZWUgbXVjaCB3YXkgYXJvdW5kIHRoaXMgc2l0 dWF0aW9uIGZvciB0aGUgc3BlYy4gSXQgc2VlbXMgdW5yZWFzb25hYmxlIHRvIGZvcmNlIGxhcmdl IGNvbnN1bWVyIHRyYW5zbWl0dGVycyB0byB0YWtlIGhpZ2ggZnJlcXVlbmN5IHBvbGxpbmcgZnJv bSBhIGxhcmdlIG51bWJlciBvZiBjbGllbnRzIGFuZCBpdCdzIGltcG9zc2libGUNCiBmb3Igc29t ZSBlbnRlcnByaXNlIHJlY2VpdmVycyB0byBnZXQgb3V0c2lkZSB0aGVpciBmaXJld2FsbCByZXN0 cmljdGlvbnMuIEkgdGhpbmsgdGhlIG9ubHkgYW5zd2VyIGlzIHdpdGggdGhlIGZvcm1hdGlvbiBv ZiBpbnRlcm1lZGlhcnkgc2VydmljZXMuIFRoZXNlIGNhbiBzZXJ2ZSBhcyBhIHF1ZXVpbmcgbWVj aGFuaXNtIHRha2luZyB0aGUgc2lnbmFscyBmcm9tIGNvbnN1bWVyIFRyYW5zbWl0dGVycyBhbmQg ZW5hYmxpbmcgcG9sbGluZyBvZiB0aGVtDQogYnkgZW50ZXJwcmlzZSBSZWNlaXZlcnMuIFNpbWls YXJseSwgdGhlc2Ugc2VydmljZSBwcm92aWRlcnMgY291bGQgYWxzbyBwb2xsIGZvciBkYXRhIGZv cm0gZW50ZXJwcmlzZSBUcmFuc21pdHRlcnMgdGhhdCBvbmx5IHN1cHBvcnQgcG9sbGluZyBhbmQg dGhlbiBwb3N0IHRob3NlIGV2ZW50cyB0byBjb25zdW1lciBSZWNlaXZlcnMuJm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+SSB0aGluayB3ZSBzaG91bGQg YWNjZXB0IHRoYXQgZm9yY2luZyBib3RoIHB1c2ggYW5kIHB1bGwgb24gdGhlIHdob2xlIGVjb3N5 c3RlbSBpcyB1bnJlYXNvbmFibGUgYW5kIHRoYXQgaWYgdGhlcmUgaXMgYSBoaWdoIG5lZWQgZm9y IGludGVyb3AgYmV0d2VlbiBjb25zdW1lciBhbmQgZW50ZXJwcmlzZSwgc2VydmljZSBwcm92aWRl cnMNCiB3aWxsIHN0ZXAgaW4gdG8gcHJvdmlkZSB0aGUgZ2x1ZS4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i bXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5PbiBTdW4sIE1hciA0LCAyMDE4IGF0IDg6 MjggUE0sIFBoaWwgSHVudCAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3Jh Y2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxP cmlnaW5hbEJvZHkiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9zcGFuPjxzcGFuIHN0eWxlPSJtc28t Ym9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9Im1zby1i b29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Jmd0Ow0KIHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+VGhpcyBkb2N1bWVudCBjb250YWlu cyBzb21lIG1pbm9yIHVwZGF0ZXMgZnJvbSBNYXJpdXMgaW4gYWR2YW5jZSBvZiBJRVRGMTAxLiBU aGUgdGVybWlub2xvZ3kgZm9yIElkZW50aXR5IFByb3ZpZGVyIGFuZCBSZWx5aW5nIFBhcnR5IGFy ZSBkcm9wcGVkIGZyb20gdGhlIGRlZmluaXRpb25zIHNlY3Rpb24gYXMgdGhleSBhcmUgbm8gbG9u Z2VyDQogcmVsZXZhbnQgdG8gdGhlIGRyYWZ0LiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9y aWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdp bmFsQm9keSI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5h bEJvZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHki PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+UGhpbDxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNv LWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5 Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPk9yYWNsZSBDb3Jwb3JhdGlvbiwgSWRlbnRpdHkg Q2xvdWQgU2VydmljZXMgQXJjaGl0ZWN0PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21h cms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+QGluZGVwZW5k ZW50aWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9k eSI+PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91 cmw/dT1odHRwLTNBX193d3cuaW5kZXBlbmRlbnRpZC5jb20mYW1wO2Q9RHdNRmFRJmFtcDtjPVJv UDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9KbkUmYW1wO3I9bmE1RlZ6QlRX bWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZhbXA7bT1xeC1FLVdoZGV4RzVzUUdW anJkMk9fdHdBQUFtTkZQV1RYLWh1LWxPWFJjJmFtcDtzPWU4d0c3RlFWUU1CSUdRVEpoMGV1M1BO cmM3STBRZnU3X2tMZ01XUmFHYVkmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9 Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+d3d3LmluZGVwZW5kZW50aWQuY29tPC9z cGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjwvc3Bhbj48 L2E+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i bXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnBo aWwuaHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9Im1zby1ib29r bWFyazpfTWFpbE9yaWdpbmFsQm9keSI+cGhpbC5odW50QG9yYWNsZS5jb208L3NwYW4+PHNwYW4g c3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PC9zcGFuPjwvYT48c3BhbiBz dHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxicj4N Cjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPk9uIE1hciA0 LCAyMDE4LCBhdCA4OjE2IFBNLA0KPC9zcGFuPjxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9N YWlsT3JpZ2luYWxCb2R5Ij5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L3NwYW4+PHNwYW4gc3R5 bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PC9zcGFuPjwvYT48c3BhbiBzdHls ZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4gd3JvdGU6PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJv b2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21h cms6X01haWxPcmlnaW5hbEJvZHkiPjxicj4NCkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWls YWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy48YnI+DQpU aGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBTZWN1cml0eSBFdmVudHMgV0cgb2YgdGhl IElFVEYuPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7VGl0bGUgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7OiBTRVQgVG9rZW4gRGVsaXZlcnkgVXNpbmcgSFRUUDxicj4NCiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0F1dGhvcnMgJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7OiBQaGlsIEh1bnQ8YnI+DQombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtNYXJpdXMgU2N1cnRlc2N1PGJyPg0KJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7TW9ydGV6YSBBbnNhcmk8YnI+DQombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtBbnRob255IE5hZGFsaW48YnI+DQombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuPGJy Pg0KRmlsZW5hbWUgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7OiBk cmFmdC1pZXRmLXNlY2V2ZW50LWRlbGl2ZXJ5LTAyLnR4dDxicj4NClBhZ2VzICZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzogMjY8YnI+ DQpEYXRlICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOzogMjAxOC0wMy0wNDxicj4NCjxicj4NCkFic3RyYWN0Ojxicj4NCiZu YnNwOyZuYnNwO1RoaXMgc3BlY2lmaWNhdGlvbiBkZWZpbmVzIGhvdyBhIHNlcmllcyBvZiBzZWN1 cml0eSBldmVudCB0b2tlbnM8YnI+DQombmJzcDsmbmJzcDsoU0VUcykgbWF5IGJlIGRlbGl2ZXJl ZCB0byBhIHByZXZpb3VzbHkgcmVnaXN0ZXJlZCByZWNlaXZlciB1c2luZzxicj4NCiZuYnNwOyZu YnNwO0hUVFAgUE9TVCBvdmVyIFRMUyBpbml0aWF0ZWQgYXMgYSBwdXNoIHRvIHRoZSByZWNlaXZl ciwgb3IgYXMgYSBwb2xsPGJyPg0KJm5ic3A7Jm5ic3A7YnkgdGhlIHJlY2VpdmVyLiZuYnNwOyBU aGUgc3BlY2lmaWNhdGlvbiBhbHNvIGRlZmluZXMgaG93IGRlbGl2ZXJ5IGNhbiBiZTxicj4NCiZu YnNwOyZuYnNwO2Fzc3VyZWQgc3ViamVjdCB0byB0aGUgU0VUIFRva2VuIFJlY2VpdmVyJ3MgbmVl ZCBmb3IgYXNzdXJhbmNlLjxicj4NCjxicj4NCjxicj4NClRoZSBJRVRGIGRhdGF0cmFja2VyIHN0 YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOjxicj4NCjwvc3Bhbj48YSBocmVmPSJodHRwczov L3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX2RhdGF0cmFja2Vy LmlldGYub3JnX2RvY19kcmFmdC0yRGlldGYtMkRzZWNldmVudC0yRGRlbGl2ZXJ5XyZhbXA7ZD1E d0lDQWcmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZh bXA7cj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJmFtcDttPTd6 SmF3angteVc2SGtveVEwa1B1anhpY3JEZnY0Q2c4WFZOb0dZbXZFOTQmYW1wO3M9VlFIaFJodHly enFIcnNvRTlpTHF3WHE3eGNyRDUzdDJHbHEwcTFaNGtVbyZhbXA7ZT0iIHRhcmdldD0iX2JsYW5r Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5odHRwczovL3Vy bGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX2RhdGF0cmFja2VyLmll dGYub3JnX2RvY19kcmFmdC0yRGlldGYtMkRzZWNldmVudC0yRGRlbGl2ZXJ5XyZhbXA7ZD1Ed0lD QWcmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZhbXA7 cj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJmFtcDttPTd6SmF3 angteVc2SGtveVEwa1B1anhpY3JEZnY0Q2c4WFZOb0dZbXZFOTQmYW1wO3M9VlFIaFJodHlyenFI cnNvRTlpTHF3WHE3eGNyRDUzdDJHbHEwcTFaNGtVbyZhbXA7ZT08L3NwYW4+PHNwYW4gc3R5bGU9 Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0i bXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48YnI+DQo8YnI+DQpUaGVyZSBhcmUgYWxz byBodG1saXplZCB2ZXJzaW9ucyBhdmFpbGFibGUgYXQ6PGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0 dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMu aWV0Zi5vcmdfaHRtbF9kcmFmdC0yRGlldGYtMkRzZWNldmVudC0yRGRlbGl2ZXJ5LTJEMDImYW1w O2Q9RHdJQ0FnJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1VQjY1ZWFwSV9K bkUmYW1wO3I9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40S1pOQSZhbXA7 bT03ekphd2p4LXlXNkhrb3lRMGtQdWp4aWNyRGZ2NENnOFhWTm9HWW12RTk0JmFtcDtzPUk1VVlz LXV5cy1ldTh4OHl3X19Za3ZoemphcEhLN2U0ajlOZ1A4Y2gzNnMmYW1wO2U9IiB0YXJnZXQ9Il9i bGFuayI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+aHR0cHM6 Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190b29scy5pZXRm Lm9yZ19odG1sX2RyYWZ0LTJEaWV0Zi0yRHNlY2V2ZW50LTJEZGVsaXZlcnktMkQwMiZhbXA7ZD1E d0lDQWcmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZh bXA7cj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJmFtcDttPTd6 SmF3angteVc2SGtveVEwa1B1anhpY3JEZnY0Q2c4WFZOb0dZbXZFOTQmYW1wO3M9STVVWXMtdXlz LWV1OHg4eXdfX1lrdmh6amFwSEs3ZTRqOU5nUDhjaDM2cyZhbXA7ZT08L3NwYW4+PHNwYW4gc3R5 bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PC9zcGFuPjwvYT48c3BhbiBzdHls ZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48YnI+DQo8L3NwYW4+PGEgaHJlZj0i aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19kYXRh dHJhY2tlci5pZXRmLm9yZ19kb2NfaHRtbF9kcmFmdC0yRGlldGYtMkRzZWNldmVudC0yRGRlbGl2 ZXJ5LTJEMDImYW1wO2Q9RHdJQ0FnJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJ ck1VQjY1ZWFwSV9KbkUmYW1wO3I9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxj TE40S1pOQSZhbXA7bT03ekphd2p4LXlXNkhrb3lRMGtQdWp4aWNyRGZ2NENnOFhWTm9HWW12RTk0 JmFtcDtzPXdxOEtPTElrSWtsYXctV1VLYjc5LW5vMHF6Y05xejZ1SmxwUy01VnBNMm8mYW1wO2U9 IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFs Qm9keSI+aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNB X19kYXRhdHJhY2tlci5pZXRmLm9yZ19kb2NfaHRtbF9kcmFmdC0yRGlldGYtMkRzZWNldmVudC0y RGRlbGl2ZXJ5LTJEMDImYW1wO2Q9RHdJQ0FnJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpo OEJ2N3FJck1VQjY1ZWFwSV9KbkUmYW1wO3I9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBr QUkxYUxjTE40S1pOQSZhbXA7bT03ekphd2p4LXlXNkhrb3lRMGtQdWp4aWNyRGZ2NENnOFhWTm9H WW12RTk0JmFtcDtzPXdxOEtPTElrSWtsYXctV1VLYjc5LW5vMHF6Y05xejZ1SmxwUy01VnBNMm8m YW1wO2U9PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHki Pjwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+ PGJyPg0KPGJyPg0KQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxl IGF0Ojxicj4NCjwvc3Bhbj48YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5j b20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19yZmNkaWZmLTNGdXJsMi0zRGRyYWZ0 LTJEaWV0Zi0yRHNlY2V2ZW50LTJEZGVsaXZlcnktMkQwMiZhbXA7ZD1Ed0lDQWcmYW1wO2M9Um9Q MVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZhbXA7cj1uYTVGVnpCVFdt YW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJmFtcDttPTd6SmF3angteVc2SGtveVEw a1B1anhpY3JEZnY0Q2c4WFZOb0dZbXZFOTQmYW1wO3M9ekptc3EwbTlnLWxOSml2NzZTNDhWeTBh UXBJYTdkU1NzRXNsWlN5ZnhHZyZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0i bXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5odHRwczovL3VybGRlZmVuc2UucHJvb2Zw b2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19yZmNkaWZmLTNGdXJsMi0z RGRyYWZ0LTJEaWV0Zi0yRHNlY2V2ZW50LTJEZGVsaXZlcnktMkQwMiZhbXA7ZD1Ed0lDQWcmYW1w O2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZhbXA7cj1uYTVG VnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJmFtcDttPTd6SmF3angteVc2 SGtveVEwa1B1anhpY3JEZnY0Q2c4WFZOb0dZbXZFOTQmYW1wO3M9ekptc3EwbTlnLWxOSml2NzZT NDhWeTBhUXBJYTdkU1NzRXNsWlN5ZnhHZyZhbXA7ZT08L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1i b29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJv b2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48YnI+DQo8YnI+DQo8YnI+DQpQbGVhc2Ugbm90ZSB0 aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJt aXNzaW9uPGJyPg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWls YWJsZSBhdCA8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29t L3YyL3VybD91PWh0dHAtM0FfX3Rvb2xzLmlldGYub3JnJmFtcDtkPUR3TUZhUSZhbXA7Yz1Sb1Ax WXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJNVUI2NWVhcElfSm5FJmFtcDtyPW5hNUZWekJUV21h bnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xONEtaTkEmYW1wO209cXgtRS1XaGRleEc1c1FHVmpy ZDJPX3R3QUFBbU5GUFdUWC1odS1sT1hSYyZhbXA7cz1XbFg5U1dmZDVOMnNfZ1BMY1NKZW5xcE5n a0dOdXNjaXNhU1M2bnNVc3FzJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJt c28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPnRvb2xzLmlldGYub3JnPC9zcGFuPjxzcGFu IHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjwvc3Bhbj48L2E+PHNwYW4g c3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Ljxicj4NCjxicj4NCkludGVy bmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDo8YnI+DQo8 L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91 PWZ0cC0zQV9fZnRwLmlldGYub3JnX2ludGVybmV0LTJEZHJhZnRzXyZhbXA7ZD1Ed0lDQWcmYW1w O2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZhbXA7cj1uYTVG VnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJmFtcDttPTd6SmF3angteVc2 SGtveVEwa1B1anhpY3JEZnY0Q2c4WFZOb0dZbXZFOTQmYW1wO3M9a0VxbmpPVWkxMVdxWEVhdDRQ dWpGblNybHhtZ0lkeENHNXJPSzJCd3lqSSZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBz dHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5odHRwczovL3VybGRlZmVuc2Uu cHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9ZnRwLTNBX19mdHAuaWV0Zi5vcmdfaW50ZXJuZXQtMkRk cmFmdHNfJmFtcDtkPUR3SUNBZyZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJN VUI2NWVhcElfSm5FJmFtcDtyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xO NEtaTkEmYW1wO209N3pKYXdqeC15VzZIa295UTBrUHVqeGljckRmdjRDZzhYVk5vR1ltdkU5NCZh bXA7cz1rRXFuak9VaTExV3FYRWF0NFB1akZuU3JseG1nSWR4Q0c1ck9LMkJ3eWpJJmFtcDtlPTwv c3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48L3NwYW4+ PC9hPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxicj4NCjxi cj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K SWQtZXZlbnQgbWFpbGluZyBsaXN0PGJyPg0KPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpJZC1ldmVu dEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01h aWxPcmlnaW5hbEJvZHkiPklkLWV2ZW50QGlldGYub3JnPC9zcGFuPjxzcGFuIHN0eWxlPSJtc28t Ym9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9Im1zby1i b29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8v dXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3Jn X21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZhbXA7ZD1Ed0lDQWcmYW1wO2M9Um9QMVl1bUNY Q2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZhbXA7cj1uYTVGVnpCVFdtYW5xV055 NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJmFtcDttPTd6SmF3angteVc2SGtveVEwa1B1anhp Y3JEZnY0Q2c4WFZOb0dZbXZFOTQmYW1wO3M9NThGY3lsdGhmcHVtUFJ2MmdTQXNzQUtxZkx5OFAz cjdMQ1lsMUpoOGpkNCZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0ibXNvLWJv b2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5odHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5j b20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2lkLTJE ZXZlbnQmYW1wO2Q9RHdJQ0FnJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFpoOEJ2N3FJck1V QjY1ZWFwSV9KbkUmYW1wO3I9bmE1RlZ6QlRXbWFucVdOeTREcGN0eVhQcHVZcVBrQUkxYUxjTE40 S1pOQSZhbXA7bT03ekphd2p4LXlXNkhrb3lRMGtQdWp4aWNyRGZ2NENnOFhWTm9HWW12RTk0JmFt cDtzPTU4RmN5bHRoZnB1bVBSdjJnU0Fzc0FLcWZMeThQM3I3TENZbDFKaDhqZDQmYW1wO2U9PC9z cGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjwvc3Bhbj48 L2E+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFs Qm9keSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9 Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PGJyPg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJZC1ldmVudCBtYWlsaW5nIGxpc3Q8 YnI+DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+SWQtZXZl bnRAaWV0Zi5vcmc8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFs Qm9keSI+PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxC b2R5Ij48YnI+DQo8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQu Y29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19pZC0y RGV2ZW50JmFtcDtkPUR3TUZhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBaaDhCdjdxSXJN VUI2NWVhcElfSm5FJmFtcDtyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQa0FJMWFMY0xO NEtaTkEmYW1wO209cXgtRS1XaGRleEc1c1FHVmpyZDJPX3R3QUFBbU5GUFdUWC1odS1sT1hSYyZh bXA7cz1TTVVFR19wN2VZczliZWowME9zMTNiVmpMbW1TOU83Rk5qcER0MWtZTXBvJmFtcDtlPSIg dGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJv ZHkiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWQtZXZlbnQ8L3NwYW4+ PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PC9zcGFuPjwvYT48 c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxicj4NCjxiciBjbGVh cj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPi0tIDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLXRvcDo3LjVwdCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTguMHB0Ij48c3BhbiBzdHls ZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM1 NTU1NTU7Ym9yZGVyOnNvbGlkICNENTBGMjUgMS41cHQ7cGFkZGluZzoyLjBwdCI+QWRhbSBEYXdl cyZuYnNwO3w8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmln aW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzU1NTU1NTtib3JkZXI6c29saWQgIzMzNjlF OCAxLjVwdDtwYWRkaW5nOjIuMHB0Ij4mbmJzcDtTci4NCiBQcm9kdWN0IE1hbmFnZXImbmJzcDt8 PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiM1NTU1NTU7Ym9yZGVyOnNvbGlkICMwMDk5MzkgMS41cHQ7 cGFkZGluZzoyLjBwdCI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48YSBocmVmPSJtYWlsdG86YWRhd2Vz QGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9N YWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2JvcmRlcjpzb2xpZCAjMDA5OTM5IDEuNXB0 O3BhZGRpbmc6Mi4wcHQiPmFkYXdlc0Bnb29nbGUuY29tPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHls ZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48L3NwYW4+PC9hPjxzcGFuIHN0eWxl PSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzU1 NTU1NTtib3JkZXI6c29saWQgIzAwOTkzOSAxLjVwdDtwYWRkaW5nOjIuMHB0Ij4mbmJzcDt8PC9z cGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiM1NTU1NTU7Ym9yZGVyOnNvbGlkICNFRUIyMTEgMS41cHQ7cGFk ZGluZzoyLjBwdCI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48YSBocmVmPSJ0ZWw6KDY1MCklMjAyMTQt MjQxMCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmln aW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Ym9yZGVyOnNvbGlkICNFRUIyMTEgMS41cHQ7cGFkZGlu ZzoyLjBwdCI+JiM0MzsxDQogNjUwLTIxNC0yNDEwPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0i bXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJt c28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzU1NTU1 NSI+PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxC b2R5Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N CklkLWV2ZW50IG1haWxpbmcgbGlzdDxicj4NCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86SWQtZXZl bnRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9N YWlsT3JpZ2luYWxCb2R5Ij5JZC1ldmVudEBpZXRmLm9yZzwvc3Bhbj48c3BhbiBzdHlsZT0ibXNv LWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJtc28t Ym9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJr Ol9NYWlsT3JpZ2luYWxCb2R5Ij48L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnBy b29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0 aW5mb19pZC0yRGV2ZW50JmFtcDtkPUR3SUNBZyZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBa aDhCdjdxSXJNVUI2NWVhcElfSm5FJmFtcDtyPW5hNUZWekJUV21hbnFXTnk0RHBjdHlYUHB1WXFQ a0FJMWFMY0xONEtaTkEmYW1wO209cXgtRS1XaGRleEc1c1FHVmpyZDJPX3R3QUFBbU5GUFdUWC1o dS1sT1hSYyZhbXA7cz1TTVVFR19wN2VZczliZWowME9zMTNiVmpMbW1TOU83Rk5qcER0MWtZTXBv JmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxP cmlnaW5hbEJvZHkiPmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1o dHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9faWQtMkRldmVudCZhbXA7ZD1E d0lDQWcmYW1wO2M9Um9QMVl1bUNYQ2dhV0h2bFpZUjhQWmg4QnY3cUlyTVVCNjVlYXBJX0puRSZh bXA7cj1uYTVGVnpCVFdtYW5xV055NERwY3R5WFBwdVlxUGtBSTFhTGNMTjRLWk5BJmFtcDttPXF4 LUUtV2hkZXhHNXNRR1ZqcmQyT190d0FBQW1ORlBXVFgtaHUtbE9YUmMmYW1wO3M9U01VRUdfcDdl WXM5YmVqMDBPczEzYlZqTG1tUzlPN0ZOanBEdDFrWU1wbyZhbXA7ZT08L3NwYW4+PHNwYW4gc3R5 bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PC9zcGFuPjwvYT48c3BhbiBzdHls ZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9Im1z by1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJZC1ldmVudCBtYWlsaW5nIGxpc3Q8YnI+ DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOklkLWV2ZW50QGlldGYub3JnIj48c3BhbiBzdHlsZT0i bXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5JZC1ldmVudEBpZXRmLm9yZzwvc3Bhbj48 c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48L3NwYW4+PC9hPjxz cGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxicj4NCjwvc3Bhbj48 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkLWV2ZW50IiB0 YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9k eSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZC1ldmVudDwvc3Bhbj48 c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48L3NwYW4+PC9hPjxz cGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_8C851BC800EB4D7B98205BCECFF78DCBamazoncom_-- From nobody Mon Mar 5 16:14:52 2018 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 8F0021271FD for ; Mon, 5 Mar 2018 16:14:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.829 X-Spam-Level: X-Spam-Status: No, score=-11.829 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_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h_DXJ0luKW1h for ; Mon, 5 Mar 2018 16:14:48 -0800 (PST) Received: from smtp-fw-6001.amazon.com (smtp-fw-6001.amazon.com [52.95.48.154]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D226120227 for ; Mon, 5 Mar 2018 16:14:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1520295288; x=1551831288; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Wn1thiZevDtQACAy5wD/1TEzYV/zstPNuGRRBg94RMY=; b=DXuGS0GaYHCIWq57RtgOpTpi945Y1TccJEXwRGeu+m3ZrfUxk+U+ubth RWkXC9RrXZVXcKU7iarW8JA/ffi0JR/uDcjc9p3Zrc3aRuudUKseynouY kywcB/afKdT0hDXAacOIp9INf28mDxk0zXlFhQOV/DkgF7/ao1vVwmEpe o=; X-IronPort-AV: E=Sophos;i="5.47,429,1515456000"; d="scan'208,217";a="334428013" Received: from iad6-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-2c-a11fcaa7.us-west-2.amazon.com) ([10.124.125.6]) by smtp-border-fw-out-6001.iad6.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Mar 2018 00:14:46 +0000 Received: from EX13MTAUWC001.ant.amazon.com (pdx1-ws-svc-p6-lb9-vlan3.pdx.amazon.com [10.236.137.198]) by email-inbound-relay-2c-a11fcaa7.us-west-2.amazon.com (8.14.7/8.14.7) with ESMTP id w260EjuM083733 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 6 Mar 2018 00:14:45 GMT Received: from EX13D11UWC003.ant.amazon.com (10.43.162.162) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Tue, 6 Mar 2018 00:14:45 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC003.ant.amazon.com (10.43.162.162) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Tue, 6 Mar 2018 00:14:45 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1236.000; Tue, 6 Mar 2018 00:14:44 +0000 From: "Richard Backman, Annabelle" To: Marius Scurtescu , ID Events Mailing List , Yaron Sheffer , "Hardt, Dick" , Phillip Hunt CC: Adam Dawes Thread-Topic: [Id-event] separate push and poll delivery drafts Thread-Index: AQHTtKD+86/Tyndgi0W6mw4qcXzdw6PB0OMA Date: Tue, 6 Mar 2018 00:14:44 +0000 Message-ID: <6E3DA4D0-755E-44DE-8511-204ABC27AC25@amazon.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.a.0.180210 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.161.47] Content-Type: multipart/alternative; boundary="_000_6E3DA4D0755E44DE8511204ABC27AC25amazoncom_" MIME-Version: 1.0 Precedence: Bulk Archived-At: Subject: Re: [Id-event] separate push and poll delivery drafts X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 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: Tue, 06 Mar 2018 00:14:50 -0000 --_000_6E3DA4D0755E44DE8511204ABC27AC25amazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEgZm9yIHNwbGl0dGluZyB0aGVtIGludG8gdHdvIHNlcGFyYXRlIGRyYWZ0cy4gSXQgd2lsbCBt YWtlIGVhY2ggb25lIGNsZWFyZXIsIGFuZCByZW1vdmUgYW1iaWd1aXR5IGFzIHRvIHdoYXQgdHJh bnNtaXR0ZXJzIGFuZCByZWNlaXZlcnMgbmVlZCB0byBpbXBsZW1lbnQuDQoNCldlIHNob3VsZCBn ZXQgdGhpcyBvbiB0aGUgYWdlbmRhIGZvciBMb25kb24uIEkgY2FuIHByZXNlbnQgaXQuDQoNCi0t DQpBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQpBbWF6b24g4oCTIElkZW50aXR5IFNlcnZpY2Vz DQoNCkZyb206IElkLWV2ZW50IDxpZC1ldmVudC1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYg b2YgTWFyaXVzIFNjdXJ0ZXNjdSA8bXNjdXJ0ZXNjdUBnb29nbGUuY29tPg0KRGF0ZTogTW9uZGF5 LCBNYXJjaCA1LCAyMDE4IGF0IDg6NDIgQU0NClRvOiBJRCBFdmVudHMgTWFpbGluZyBMaXN0IDxp ZC1ldmVudEBpZXRmLm9yZz4sIFlhcm9uIFNoZWZmZXIgPHlhcm9uZi5pZXRmQGdtYWlsLmNvbT4s ICJIYXJkdCwgRGljayIgPGRpY2tAYW1hem9uLmNvbT4sIFBoaWxsaXAgSHVudCA8cGhpbC5odW50 QG9yYWNsZS5jb20+DQpDYzogQWRhbSBEYXdlcyA8YWRhd2VzQGdvb2dsZS5jb20+DQpTdWJqZWN0 OiBbSWQtZXZlbnRdIHNlcGFyYXRlIHB1c2ggYW5kIHBvbGwgZGVsaXZlcnkgZHJhZnRzDQoNClRo ZSBjdXJyZW50IGRlbGl2ZXJ5IGRyYWZ0IGRlZmluZXMgYm90aCBhIHB1c2ggYW5kIGEgcG9sbCBk ZWxpdmVyeSBtZXRob2RzOg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt c2VjZXZlbnQtZGVsaXZlcnktMDINCg0KVHdvIGlzc3VlcyBoYXZlIGJlZW4gcmFpc2VkIHdpdGgg dGhlIGN1cnJlbnQgZHJhZnQ6DQoNCjEuIE1hbnkgaW1wbGVtZW50b3JzIHJhaXNlZCB0aGUgY29u Y2VybiB0aGF0IHRoZXkgd2FudCB0byBpbXBsZW1lbnQgZWl0aGVyIHB1c2ggb3IgcG9sbCwgYnV0 IG5vdCBib3RoLiBXaXRoIGJvdGggZGVsaXZlcnkgbWV0aG9kcyBpbiBvbmUgc3BlYyBvcHRpb25h bGl0eSBpcyB0cmlja3ksIHRoZSBzdWdnZXN0aW9uIHdhcyB0byBtYWtlIHRoZW0gTVRJLCBidXQg bm90IG1hbmRhdG9yeSB0byBkZXBsb3kgd2hpY2ggaXMgdmVyeSBjb25mdXNpbmcuDQoNCjIuIEZv ciB0aGUgZHJhZnQgdG8gbW92ZSB0byBMYXN0IENhbGwgc3RhdHVzIHdlIG5lZWQgaW1wbGVtZW50 b3JzIGZvciBhbGwgcGFydHMgb2YgdGhlIGRyYWZ0LiBDdXJyZW50bHkgdGhlcmUgYXJlIHB1c2gg aW1wbGVtZW50YXRpb25zLCBidXQgbm90IHBvbGwgaW1wbGVtZW50YXRpb25zLiBCeSBzZXBhcmF0 aW5nIHRoZW0gd2UgY2FuIGFsbG93IHRoZSBtb3JlIG1hdHVyZSBtZXRob2QgdG8gbW92ZSBmb3J3 YXJkIHdoaWxlIGFsbG93aW5nIHRoZSBsZXNzIG1hdHVyZSBtZXRob2QgdG8gYmUgcmVmaW5lZCBh bmQgZ2FpbiBpbXBsZW1lbnRhdGlvbiBmZWVkYmFjay4NCg0KQWxzbywgYnkgaGF2aW5nIHNlcGFy YXRlIHNwZWNzIHBlciBkZWxpdmVyeSBtZXRob2Qgd2Ugc2V0IHRoZSBzdGFnZSBmb3Igb3RoZXIg ZGVsaXZlcnkgbWV0aG9kcyB0byBiZSBhZGRlZCBlYXNpbHkuDQoNCkNhbiB3ZSBhZGQgdGhpcyB0 byB0aGUgYWdlbmRhIHRvIGJlIGRpc2N1c3NlZCBpbiBMb25kb24/DQoNClRoZSBkaXNjdXNzaW9u IHNob3VsZCBhbnN3ZXI6DQpBLiBEbyB3ZSBoYXZlIGNvbnNlbnN1cyBmb3Igc3BsaXR0aW5nIHRo ZSBkZWxpdmVyeSBzcGVjIGludG8gdHdvPw0KQi4gSWYgeWVzIGZvciBBLCBjYW4gdGhlIHR3byBu ZXcgc3BlY3MgcmVwbGFjZSB0aGUgZXhpc3Rpbmcgc3BlYyBhbmQgc3RheSBhcyB3b3JraW5nIGdy b3VwIGRyYWZ0cyAodGhpcyB3b3VsZCBiZSBpZGVhbCk/IEFzIG9wcG9zZWQgdG8gdGhlIHR3byBu ZXcgc3BlY3Mgc3RhcnRpbmcgZnJvbSBzY3JhdGNoIGFzIEktRHMuDQoNCklmIGl0IGhlbHBzLCBJ IGFtIGhhcHB5IHRvIHNlbmQgdG8gdGhlIGxpc3QgdHdvIHNlcGFyYXRlIHNwZWNzIGFzIFRYVC9Q REYgc28gd2UgaGF2ZSBzb21ldGhpbmcgY29uY3JldGUgdG8gbG9vayBhdC4gTGV0IG1lIGtub3cu DQoNCkkgd2lsbCBub3QgYmUgaW4gTG9uZG9uLCBidXQgd2lsbCB0cnkgdG8gYXR0ZW5kIHJlbW90 ZWx5Lg0KDQpUaGFua3MsDQpNYXJpdXMNCg== --_000_6E3DA4D0755E44DE8511204ABC27AC25amazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiYjNDM7MSBmb3Igc3BsaXR0aW5nIHRoZW0gaW50byB0d28gc2VwYXJhdGUgZHJh ZnRzLiBJdCB3aWxsIG1ha2UgZWFjaCBvbmUgY2xlYXJlciwgYW5kIHJlbW92ZSBhbWJpZ3VpdHkg YXMgdG8gd2hhdCB0cmFuc21pdHRlcnMgYW5kIHJlY2VpdmVycyBuZWVkIHRvIGltcGxlbWVudC48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2Ugc2hvdWxkIGdldCB0aGlzIG9uIHRoZSBhZ2VuZGEg Zm9yIExvbmRvbi4gSSBjYW4gcHJlc2VudCBpdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OyxzZXJpZiI+LS0mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPkFubmFiZWxsZSBSaWNoYXJk IEJhY2ttYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssc2VyaWYiPkFtYXpvbiDigJMgSWRlbnRpdHkgU2VydmljZXM8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPklkLWV2ZW50ICZs dDtpZC1ldmVudC1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgTWFyaXVzIFNjdXJ0 ZXNjdSAmbHQ7bXNjdXJ0ZXNjdUBnb29nbGUuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5Nb25k YXksIE1hcmNoIDUsIDIwMTggYXQgODo0MiBBTTxicj4NCjxiPlRvOiA8L2I+SUQgRXZlbnRzIE1h aWxpbmcgTGlzdCAmbHQ7aWQtZXZlbnRAaWV0Zi5vcmcmZ3Q7LCBZYXJvbiBTaGVmZmVyICZsdDt5 YXJvbmYuaWV0ZkBnbWFpbC5jb20mZ3Q7LCAmcXVvdDtIYXJkdCwgRGljayZxdW90OyAmbHQ7ZGlj a0BhbWF6b24uY29tJmd0OywgUGhpbGxpcCBIdW50ICZsdDtwaGlsLmh1bnRAb3JhY2xlLmNvbSZn dDs8YnI+DQo8Yj5DYzogPC9iPkFkYW0gRGF3ZXMgJmx0O2FkYXdlc0Bnb29nbGUuY29tJmd0Ozxi cj4NCjxiPlN1YmplY3Q6IDwvYj5bSWQtZXZlbnRdIHNlcGFyYXRlIHB1c2ggYW5kIHBvbGwgZGVs aXZlcnkgZHJhZnRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbE9yaWdpbmFsQm9keSI+VGhlIGN1cnJlbnQg ZGVsaXZlcnkgZHJhZnQgZGVmaW5lcyBib3RoIGEgcHVzaCBhbmQgYSBwb2xsIGRlbGl2ZXJ5IG1l dGhvZHM6DQo8bzpwPjwvbzpwPjwvYT48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PC9zcGFuPjxhIGhy ZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNlY2V2ZW50LWRlbGl2 ZXJ5LTAyIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5odHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zZWNldmVudC1kZWxpdmVyeS0wMjwv c3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48L3NwYW4+ PC9hPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPlR3byBpc3N1ZXMgaGF2ZSBiZWVu IHJhaXNlZCB3aXRoIHRoZSBjdXJyZW50IGRyYWZ0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21h cms6X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6 X01haWxPcmlnaW5hbEJvZHkiPjEuIE1hbnkgaW1wbGVtZW50b3JzIHJhaXNlZCB0aGUgY29uY2Vy biB0aGF0IHRoZXkgd2FudCB0byBpbXBsZW1lbnQgZWl0aGVyIHB1c2ggb3IgcG9sbCwgYnV0IG5v dCBib3RoLiBXaXRoIGJvdGggZGVsaXZlcnkgbWV0aG9kcyBpbiBvbmUgc3BlYyBvcHRpb25hbGl0 eSBpcyB0cmlja3ksIHRoZSBzdWdnZXN0aW9uIHdhcyB0byBtYWtlDQogdGhlbSBNVEksIGJ1dCBu b3QgbWFuZGF0b3J5IHRvIGRlcGxveSB3aGljaCBpcyB2ZXJ5IGNvbmZ1c2luZy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4yLiBGb3IgdGhlIGRyYWZ0IHRvIG1v dmUgdG8gTGFzdCBDYWxsIHN0YXR1cyB3ZSBuZWVkIGltcGxlbWVudG9ycyBmb3IgYWxsIHBhcnRz IG9mIHRoZSBkcmFmdC4gQ3VycmVudGx5IHRoZXJlIGFyZSBwdXNoIGltcGxlbWVudGF0aW9ucywg YnV0IG5vdCBwb2xsIGltcGxlbWVudGF0aW9ucy4gQnkgc2VwYXJhdGluZyB0aGVtIHdlIGNhbg0K IGFsbG93IHRoZSBtb3JlIG1hdHVyZSBtZXRob2QgdG8gbW92ZSBmb3J3YXJkIHdoaWxlIGFsbG93 aW5nIHRoZSBsZXNzIG1hdHVyZSBtZXRob2QgdG8gYmUgcmVmaW5lZCBhbmQgZ2FpbiBpbXBsZW1l bnRhdGlvbiBmZWVkYmFjay48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2lu YWxCb2R5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxC b2R5Ij5BbHNvLCBieSBoYXZpbmcgc2VwYXJhdGUgc3BlY3MgcGVyIGRlbGl2ZXJ5IG1ldGhvZCB3 ZSBzZXQgdGhlIHN0YWdlIGZvciBvdGhlciBkZWxpdmVyeSBtZXRob2RzIHRvIGJlIGFkZGVkIGVh c2lseS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5DYW4gd2Ug YWRkIHRoaXMgdG8gdGhlIGFnZW5kYSB0byBiZSBkaXNjdXNzZWQgaW4gTG9uZG9uPzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPlRoZSBkaXNjdXNzaW9uIHNob3Vs ZCBhbnN3ZXI6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+ QS4gRG8gd2UgaGF2ZSBjb25zZW5zdXMgZm9yIHNwbGl0dGluZyB0aGUgZGVsaXZlcnkgc3BlYyBp bnRvIHR3bz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5C LiBJZiB5ZXMgZm9yIEEsIGNhbiB0aGUgdHdvIG5ldyBzcGVjcyByZXBsYWNlIHRoZSBleGlzdGlu ZyBzcGVjIGFuZCBzdGF5IGFzIHdvcmtpbmcgZ3JvdXAgZHJhZnRzICh0aGlzIHdvdWxkIGJlIGlk ZWFsKT8gQXMgb3Bwb3NlZCB0byB0aGUgdHdvIG5ldyBzcGVjcyBzdGFydGluZyBmcm9tIHNjcmF0 Y2ggYXMgSS1Ecy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5J ZiBpdCBoZWxwcywgSSBhbSBoYXBweSB0byBzZW5kIHRvIHRoZSBsaXN0IHR3byBzZXBhcmF0ZSBz cGVjcyBhcyBUWFQvUERGIHNvIHdlIGhhdmUgc29tZXRoaW5nIGNvbmNyZXRlIHRvIGxvb2sgYXQu IExldCBtZSBrbm93LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJv ZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHki Pkkgd2lsbCBub3QgYmUgaW4gTG9uZG9uLCBidXQgd2lsbCB0cnkgdG8gYXR0ZW5kIHJlbW90ZWx5 LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPlRoYW5rcyw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHki Pk1hcml1czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_6E3DA4D0755E44DE8511204ABC27AC25amazoncom_-- From nobody Tue Mar 6 09:51:51 2018 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 04D9B1289B0 for ; Tue, 6 Mar 2018 09:51:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 MCnvFraZcKA4 for ; Tue, 6 Mar 2018 09:51:45 -0800 (PST) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D46912895E for ; Tue, 6 Mar 2018 09:51:45 -0800 (PST) Received: by mail-ua0-x231.google.com with SMTP id f5so13648042uam.5 for ; Tue, 06 Mar 2018 09:51:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/+uRzwlQNGBZIyJcYM4NZBb4e6gGGUTXL/vnyKQTv9c=; b=Yiev1OFO2P9+W9xVl1VS3kGYBH13X6FPqabDG9+vyYyBQAyqeBC2LXeuPSjquimYzd QlAIx6fxggexRP+h2cmRfQ7vuyZvFlLYJKCtNenVRJh/2EmpiKILM5cnZgEr49ATGwlr MTS7E3f5CGyZgBptwkL0LmiImDvBci577rKUm4QjqT9aZi9tw0RSKGpNeMvf4/KEcj1N YqFLUb2qG0GwllfTG1xCJyayDufaoIFzHFxRGuWrIv4YBddInRa4NzDS0rOL9yEVC871 5v6FtfCJRsDsBA/wavwzahTLQzDjIWmeje3slqOQndNwwRfnttmiWP4fIshLGPZEIsHK /GJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/+uRzwlQNGBZIyJcYM4NZBb4e6gGGUTXL/vnyKQTv9c=; b=KvIx3mLQ9qGhjnEubh6jDvhLUDdJoJRqsgbSYdCIkax2jgqCuaFuCkW+4lWL4pajG7 sanaKoV5w8lIDsGdkWJL7dLhpNXvn1p8zwL5wkuH9CKIBFXQnMrIQXCwA5rYbDuGTifh iVrVDxJGVu+Kh0dxnj70PrfAqXFKiFcxOF3GaaTx5kvjKZLC2ipJVX+OVhHdwxE68gxI w67Lr+o/vXlfPxAyeHJsgOmzJdVYEgWoZFcYYFwXY662gp/8I9gEWZdO4uB23xMYNtfv JojIE8UAmj4siUEmMBJ807be1H0Ss3khr+6ve5XsehmsVRgf/mq0IjlRAaV8n5a+dn/r UyDg== X-Gm-Message-State: APf1xPBqGAmjo0n8CnRhXaOxBQPwRKWw/lluYjjcrfM86mj5YdTje0sG gzrvIUJNz8D6EpaLahRC+5H52O5wTQz8QJFJ9VeFNQ== X-Google-Smtp-Source: AG47ELvRhsiwfKgEtFwKWyXd/b9zc0XHRpTCf3QHddHy7wTiD0Rato1fjsGfcIavlsUbUmuryUvYCYreCnqR6ICO2Rs= X-Received: by 10.159.61.88 with SMTP id m24mr14036062uai.139.1520358704185; Tue, 06 Mar 2018 09:51:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.94.88 with HTTP; Tue, 6 Mar 2018 09:51:23 -0800 (PST) In-Reply-To: <6E3DA4D0-755E-44DE-8511-204ABC27AC25@amazon.com> References: <6E3DA4D0-755E-44DE-8511-204ABC27AC25@amazon.com> From: Marius Scurtescu Date: Tue, 6 Mar 2018 09:51:23 -0800 Message-ID: To: "Richard Backman, Annabelle" Cc: ID Events Mailing List , Yaron Sheffer , "Hardt, Dick" , Phillip Hunt , Adam Dawes Content-Type: multipart/alternative; boundary="f403043664f87f52570566c2181c" Archived-At: Subject: Re: [Id-event] separate push and poll delivery drafts X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 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: Tue, 06 Mar 2018 17:51:48 -0000 --f403043664f87f52570566c2181c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Mar 5, 2018 at 4:14 PM, Richard Backman, Annabelle < richanna@amazon.com> wrote: > +1 for splitting them into two separate drafts. It will make each one > clearer, and remove ambiguity as to what transmitters and receivers need = to > implement. > > > > We should get this on the agenda for London. I can present it. > Thanks for offering to present. Yaron, please let us know if this is on the agenda. > > > -- > > Annabelle Richard Backman > > Amazon =E2=80=93 Identity Services > > > > *From: *Id-event on behalf of Marius > Scurtescu > *Date: *Monday, March 5, 2018 at 8:42 AM > *To: *ID Events Mailing List , Yaron Sheffer < > yaronf.ietf@gmail.com>, "Hardt, Dick" , Phillip Hunt < > phil.hunt@oracle.com> > *Cc: *Adam Dawes > *Subject: *[Id-event] separate push and poll delivery drafts > > > > The current delivery draft defines both a push and a poll delivery > methods: > > https://tools.ietf.org/html/draft-ietf-secevent-delivery-02 > > > > Two issues have been raised with the current draft: > > > > 1. Many implementors raised the concern that they want to implement eithe= r > push or poll, but not both. With both delivery methods in one spec > optionality is tricky, the suggestion was to make them MTI, but not > mandatory to deploy which is very confusing. > > > > 2. For the draft to move to Last Call status we need implementors for all > parts of the draft. Currently there are push implementations, but not pol= l > implementations. By separating them we can allow the more mature method t= o > move forward while allowing the less mature method to be refined and gain > implementation feedback. > > > > Also, by having separate specs per delivery method we set the stage for > other delivery methods to be added easily. > > > > Can we add this to the agenda to be discussed in London? > > > > The discussion should answer: > > A. Do we have consensus for splitting the delivery spec into two? > > B. If yes for A, can the two new specs replace the existing spec and stay > as working group drafts (this would be ideal)? As opposed to the two new > specs starting from scratch as I-Ds. > > > > If it helps, I am happy to send to the list two separate specs as TXT/PDF > so we have something concrete to look at. Let me know. > > > > I will not be in London, but will try to attend remotely. > > > > Thanks, > > Marius > --f403043664f87f52570566c2181c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Mar 5, 2018 at 4:14 PM, Richard Backman, Annabelle &l= t;richanna@amazon.com> wrote:

+1 for splitting them into two separate drafts. It w= ill make each one clearer, and remove ambiguity as to what transmitters and= receivers need to implement.

=C2=A0

We should get this on the agenda for London. I can p= resent it.


Thanks for offer= ing to present.

Yaron, please let us know if this = is on the agenda.
=C2=A0

=C2=A0

--=C2=A0

Annabelle Richard Backman

Amazon =E2=80=93 Identity Services=

=C2=A0

From= : Id-event <id-event-bounces@ietf.org> on behalf of Marius Scurtescu <mscur= tescu@google.com>
Date: Monday, March 5, 2018 at 8:42 AM
To: ID Events Mailing List <id-event@ietf.org>, Yaron Sheffer= <yaronf.ietf@gmail.com>, "Hardt, Dick" <dick@amazon.com= >, Phillip Hunt <phil.hunt@oracle.com>
Cc: Adam Dawes <adawes@google.com>
Subject: [Id-event] separate push and poll delivery drafts=

=C2=A0

The current delivery draft defines both a push and a poll= delivery methods:

=C2=A0

Two issues have been raised with the current d= raft:

=C2=A0

1. Many implementors raised the concern that t= hey want to implement either push or poll, but not both. With both delivery= methods in one spec optionality is tricky, the suggestion was to make them MTI, but not mandatory to deploy which is very confusing.

=C2=A0

2. For the draft to move to Last Call status w= e need implementors for all parts of the draft. Currently there are push im= plementations, but not poll implementations. By separating them we can allow the more mature method to move forward while allowing the less matur= e method to be refined and gain implementation feedback.

=C2=A0

Also, by having separate specs per delivery me= thod we set the stage for other delivery methods to be added easily.=

=C2=A0

Can we add this to the agenda to be discussed = in London?

=C2=A0

The discussion should answer:

A. Do we have consensus for splitting the deli= very spec into two?

B. If yes for A, can the two new specs replace= the existing spec and stay as working group drafts (this would be ideal)? = As opposed to the two new specs starting from scratch as I-Ds.

=C2=A0

If it helps, I am happy to send to the list tw= o separate specs as TXT/PDF so we have something concrete to look at. Let m= e know.

=C2=A0

I will not be in London, but will try to atten= d remotely.

=C2=A0

Thanks,

Marius


--f403043664f87f52570566c2181c-- From nobody Tue Mar 6 23:29:32 2018 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 11199124BE8 for ; Tue, 6 Mar 2018 23:29:31 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3tXPjfht0Vk for ; Tue, 6 Mar 2018 23:29:29 -0800 (PST) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2694F124B0A for ; Tue, 6 Mar 2018 23:29:29 -0800 (PST) Received: by mail-it0-x22d.google.com with SMTP id u5so2203197itc.1 for ; Tue, 06 Mar 2018 23:29:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=oCJ/layDWm5AF4szRqlPvXmjEZXcCX+kfk8kDy//0J0=; b=ZuzluZDpmOC8hz8Jv90JQvCOAW+y88gm36UYtpsdgGtyniqP09BhdeolumY52sPqRB WDi/eNUs/mljvHEM4YNh2mBodt8LdaTuRzM9E3oBnaSwY/bzLzcMZJulZjQ9lq7tx6a4 93mD5hOai11iougF5tIOBtO8hOe/rDLvIoZdrSCSwhtLPAUwACfQ8jPqH4NJoY6uApCw a9epqm9Ieu+9RcLalIu/BmDgrNPmbfEwT8j83ZkcdahOJ4/yru/pBtjCmc6gUZ1oCwdx cJzwTJEnSU1PjzgOsmi48uyRqetDih/7/JtceghW34IpthvU9EHAZgsDqPNzxtyoPhu+ CgEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=oCJ/layDWm5AF4szRqlPvXmjEZXcCX+kfk8kDy//0J0=; b=hjdBdHQLxLz5txO9niiE6Q2XrPkAmoWoSoY/6TTI5WTTXjzZ2iBX9yTgRMEHjx909J rxsnHFvbPhZN4XVwKX+aXmanotoRpPv+Mtr6WmvaHs4Qjt+Hc827qHffqw8QBamIIRuU VYDgAvjYHu+RKlqWmckCa+6Wju4BoxscCxACe31qR0mAsV4c2QIuEE7jM1YJcEXMyWms LmvmCPqYQev+AbpIFrmAt2UV8lsIz+kMDK4TTQovUC5GVeL7Y1Vsu4ZU6E3FReLhu/4j XzAZ9+wAUi+Q4tJNJFuPXv8Ktpht9OyE8OfSaGPkbDSJBKwuRZOcRU+jSE9I/qBL9JKR DF1w== X-Gm-Message-State: AElRT7Hrv1kK3WxFILm8rUbATD4N3/oEkav+fVO++NLlDs7m9Jwzdu2j uZRX3rDwi5cP9p+nyPWFKPo= X-Google-Smtp-Source: AG47ELsI7ZV+NlmHM1bxEY7F68NE0O4QyDPQviTUYHLPM7pJfG0gbaubs8I8rrHPGkTYM+fhwsjtjA== X-Received: by 10.36.74.148 with SMTP id k142mr22722615itb.115.1520407768438; Tue, 06 Mar 2018 23:29:28 -0800 (PST) Received: from [10.100.8.171] (wsip-70-167-159-70.oc.oc.cox.net. [70.167.159.70]) by smtp.gmail.com with ESMTPSA id 193sm6273109itf.1.2018.03.06.23.29.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Mar 2018 23:29:27 -0800 (PST) To: Marius Scurtescu , "Richard Backman, Annabelle" Cc: ID Events Mailing List , "Hardt, Dick" , Phillip Hunt , Adam Dawes References: <6E3DA4D0-755E-44DE-8511-204ABC27AC25@amazon.com> From: Yaron Sheffer Message-ID: Date: Tue, 6 Mar 2018 23:29:26 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Id-event] separate push and poll delivery drafts X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 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 Mar 2018 07:29:31 -0000 It is on the agenda now. Thanks, Yaron On 06/03/18 09:51, Marius Scurtescu wrote: > On Mon, Mar 5, 2018 at 4:14 PM, Richard Backman, Annabelle > > wrote: > > +1 for splitting them into two separate drafts. It will make each > one clearer, and remove ambiguity as to what transmitters and > receivers need to implement.____ > > __ __ > > We should get this on the agenda for London. I can present it. > > > Thanks for offering to present. > > Yaron, please let us know if this is on the agenda. > > ____ > > __ __ > > -- ____ > > Annabelle Richard Backman____ > > Amazon – Identity Services____ > > __ __ > > *From: *Id-event > on behalf of Marius Scurtescu > > > *Date: *Monday, March 5, 2018 at 8:42 AM > *To: *ID Events Mailing List >, Yaron Sheffer >, "Hardt, Dick" >, Phillip Hunt > > *Cc: *Adam Dawes > > *Subject: *[Id-event] separate push and poll delivery drafts____ > > __ __ > > The current delivery draft defines both a push and a poll delivery > methods: ____ > > https://tools.ietf.org/html/draft-ietf-secevent-delivery-02____ > > __ __ > > Two issues have been raised with the current draft:____ > > __ __ > > 1. Many implementors raised the concern that they want to implement > either push or poll, but not both. With both delivery methods in one > spec optionality is tricky, the suggestion was to make them MTI, but > not mandatory to deploy which is very confusing.____ > > __ __ > > 2. For the draft to move to Last Call status we need implementors > for all parts of the draft. Currently there are push > implementations, but not poll implementations. By separating them we > can allow the more mature method to move forward while allowing the > less mature method to be refined and gain implementation feedback.____ > > __ __ > > Also, by having separate specs per delivery method we set the stage > for other delivery methods to be added easily.____ > > __ __ > > Can we add this to the agenda to be discussed in London?____ > > __ __ > > The discussion should answer:____ > > A. Do we have consensus for splitting the delivery spec into two?____ > > B. If yes for A, can the two new specs replace the existing spec and > stay as working group drafts (this would be ideal)? As opposed to > the two new specs starting from scratch as I-Ds.____ > > __ __ > > If it helps, I am happy to send to the list two separate specs as > TXT/PDF so we have something concrete to look at. Let me know.____ > > __ __ > > I will not be in London, but will try to attend remotely.____ > > __ __ > > Thanks,____ > > Marius____ > > From nobody Tue Mar 6 23:49:23 2018 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 39500126C83 for ; Tue, 6 Mar 2018 23:49:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.975 X-Spam-Level: X-Spam-Status: No, score=-1.975 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CfxarViLsdop for ; Tue, 6 Mar 2018 23:49:21 -0800 (PST) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDC6E126C2F for ; Tue, 6 Mar 2018 23:49:20 -0800 (PST) Received: by mail-it0-x231.google.com with SMTP id j7so2244021ita.3 for ; Tue, 06 Mar 2018 23:49:20 -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 :content-language:content-transfer-encoding; bh=wirdWb3ODydYx090a21F8GORA9zHY5MenwZJ8Nia560=; b=UDKXiPOdR3lWXqNtFNeG6vZy8tL6/MtdWXnW5/Kc7wC1ZnyNDoqK84MlW6nidLQ2iq sqoj/l6qysjjaJQWsnY5Wz6yGeU2oXHkTyJ9BbNeBJvnvZPG7kSFmKbTyNYu0emuYB/O AqLIGz+fCkPgolBSD2lwuEVpgOZKOEsncDVs04nR9eyO3akBn9p2QdzBeS8yWT2o9hpm 5JtEaDAuknI/YTO29yhd7BuhiLxUZyiWq7GqAc83MYskBAyuQoUDshHDHJ2zckuNvqxv bWqLjmp/IVSK3ca2SSgQCE75owNedpf0RFgpNa9vzlKgdjzvf6K8Uka81Tl+C0KI79TG LBKg== 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:content-language:content-transfer-encoding; bh=wirdWb3ODydYx090a21F8GORA9zHY5MenwZJ8Nia560=; b=esCAdGYXQ+AtMZRrTRJkQwarKsAeLOuBR4AHHfLnr4CmU86D4hv+TDreARlZuBgkKd fxfqEHDftYeTfmU86IlLHDYhZQc3ijD2qpXJANzBrjLsrqdAjYCqvsOGoK9upAsd/8pm rtD7rYeUju3MIJZjhH5bt1EPE7SB0MgN7qFMQld0zozZ+l/eOewu2uNCvVI2C2K/NZvI FyPID0p9i1sMFSptYmaK9Dk4syEBfq6qxOsYK8L8oHSDmB3PcAWIFM5g1NVWnxYqiYOi HJhIRL5x9q2Po3y+xrs4giE5pU2cPlDq//3/2qkQRbq5vK59YCEDY83/izOMoSpMugwQ 93GQ== X-Gm-Message-State: AElRT7HhWS985LHxb31+N1zdStpx2i1YTkqzk/7sKAnEvbkunQSEp1u0 fT7B2bTpAUD+P6X7dK3gHKHzFTVv X-Google-Smtp-Source: AG47ELszC9ekwccljHZHuQLHjH3mEyldG/5FGYJw6MYSAaZncyAO/DHYfx6oRZWFDpJ4YnLLMf7Mqw== X-Received: by 10.36.192.198 with SMTP id u189mr21296380itf.59.1520408960088; Tue, 06 Mar 2018 23:49:20 -0800 (PST) Received: from [10.100.8.171] (wsip-70-167-159-70.oc.oc.cox.net. [70.167.159.70]) by smtp.gmail.com with ESMTPSA id n9sm11785998ion.27.2018.03.06.23.49.19 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Mar 2018 23:49:19 -0800 (PST) To: SecEvent From: Yaron Sheffer Message-ID: <6212ca71-8583-c82d-6f51-45ede3cb1dd6@gmail.com> Date: Tue, 6 Mar 2018 23:49:18 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: text/html; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: [Id-event] SecEvent IETF-101 agenda posted X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 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 Mar 2018 07:49:22 -0000 https://datatracker.ietf.org/meeting/101/materials/agenda-101-secevent

Let us know if you have any comments.

Thanks,
    Yaron
From nobody Sun Mar 18 00:47:47 2018 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 170D5129C6E for ; Sun, 18 Mar 2018 00:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FpW-0Y9LejQz for ; Sun, 18 Mar 2018 00:47:45 -0700 (PDT) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::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 AF0CE124235 for ; Sun, 18 Mar 2018 00:47:44 -0700 (PDT) Received: by mail-wr0-x235.google.com with SMTP id s18so15441474wrg.9 for ; Sun, 18 Mar 2018 00:47:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LNiagCPQZWzjFnlD+mXFbV5CnyMH6RrJINy1JQZinQk=; b=VI9Tfb3DWpa9AANwhcf6o0wLLIlIuEs+bNaCoXeTXIeIEcIkW7rmyWEb9P824+WpMO JyCnzDbHiMMRf/pLKLJ0LUYfl+oWYDoKyq3VdTeKS1Eh13c7OXBfrwLBzjiJMwxVIEfT xMhvq4VvB6/AG9ZffPCAViptfWXHxu8ALcvkHDiYgRMHDkXPLKb6WsWT2M3Z7WnzYRI3 Pkvi1oPjjk31UQDNMSJ/iAwLAw5ZoIQU4jgw0YCWb1z2v/B3ZWDt287NFXd9ndLMNDoP TFKLjlMrKnHFoMZBUuQsjhM7nCppHCj+BHHSmN7lgLkKlUCzuMHB/SP+Dq2di0/jBfOK lpDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LNiagCPQZWzjFnlD+mXFbV5CnyMH6RrJINy1JQZinQk=; b=c7gSC4AuG6vKkF6Gua2Blw47hmqqz9qIwXRTq1egCoX9inNxzlHBD97Ms3hHIdydDk pMKguC9SEaPknAWgeHESPrG4Ik4iq22IsiMV42YC8HB9GHdsoL6zb+M7X9tYYIxRsjUc loCc5Whdy2BBNswuEsmST3ilWXCUzXujMowY6nt6C2nR+OvANXj5Acbk9msVKft3G+H6 OX2vZvtG8x6oDOLAF3Us8X5AQbsFFfoXWGVJmi1FcMSQ/RNujJQcRnL6UEciTM9Emuqc 7dr9k4l69q3q/5C56h0ArvXh4Tv63ifai9afg2J0hjLJ8ZjiByN3GXw3asfGZq1Oidqn DH9g== X-Gm-Message-State: AElRT7HggHcM606LcXEmWIOAt7jFDHc4vlMcMSeAdFQqT1cvbDfSn/5h mUG/duUX+TwmRdkbBRda33mUHi4WO7APKiejKxk= X-Google-Smtp-Source: AG47ELuFEvlnDfz+FR63YbEz/+9CdP/P7dFV17JGbD9manrRQJCshDv3IU0XCxIHuRiJ0ktIHYXrr7MiTYnIGGfrI80= X-Received: by 10.223.195.116 with SMTP id e49mr5940635wrg.5.1521359263270; Sun, 18 Mar 2018 00:47:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.150.236 with HTTP; Sun, 18 Mar 2018 00:47:42 -0700 (PDT) In-Reply-To: <6212ca71-8583-c82d-6f51-45ede3cb1dd6@gmail.com> References: <6212ca71-8583-c82d-6f51-45ede3cb1dd6@gmail.com> From: Mayank Bhatnagar Date: Sun, 18 Mar 2018 13:17:42 +0530 Message-ID: To: Yaron Sheffer Cc: SecEvent Content-Type: multipart/alternative; boundary="f403045c3c52768a720567ab0e08" Archived-At: Subject: Re: [Id-event] SecEvent IETF-101 agenda posted X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 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 Mar 2018 07:47:46 -0000 --f403045c3c52768a720567ab0e08 Content-Type: text/plain; charset="UTF-8" hi Yaron, thanks for this agenda. However is there any online webex kind of link where we can connect and participate from remote. Also what are the dates. thanks & regards, Mayank On Wed, Mar 7, 2018 at 1:19 PM, Yaron Sheffer wrote: > https://datatracker.ietf.org/meeting/101/materials/agenda-101-secevent > > Let us know if you have any comments. > > Thanks, > Yaron > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > --f403045c3c52768a720567ab0e08 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
hi Yaron,
thanks for this agenda.

=
However is there any online webex kind of link where we can connect an= d participate from remote.
Also what are the dates.
thanks & regards,
Mayank

=

On Wed, Mar= 7, 2018 at 1:19 PM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
=20 =20 =20 =20
https://datatracker.ietf.org/meeting/101/materials/agenda-101= -secevent

Let us know if you have any comments.

Thanks,
=C2=A0=C2=A0=C2=A0 Yaron

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


--f403045c3c52768a720567ab0e08-- From nobody Sun Mar 18 03:37:45 2018 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 4A7411275F4 for ; Sun, 18 Mar 2018 03:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 jw33JabrAJMX for ; Sun, 18 Mar 2018 03:37:33 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (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 5BE3412741D for ; Sun, 18 Mar 2018 03:37:33 -0700 (PDT) X-AuditID: 12074422-887ff7000000664e-d7-5aae416988ce Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 31.D9.26190.B614EAA5; Sun, 18 Mar 2018 06:37:31 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id w2IAbQG8018697; Sun, 18 Mar 2018 06:37:27 -0400 Received: from dhcp-90dd.meeting.ietf.org (dhcp-90dd.meeting.ietf.org [31.133.144.221]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w2IAaSvw011869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 18 Mar 2018 06:37:24 -0400 From: Justin Richer Message-Id: <9EEF1C94-5ADA-4BB1-9F28-6869BE0D2D0A@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_0A86B622-9790-4A1D-A98B-8E3A6A650DF4" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Sun, 18 Mar 2018 10:37:40 +0000 In-Reply-To: Cc: Yaron Sheffer , SecEvent To: Mayank Bhatnagar References: <6212ca71-8583-c82d-6f51-45ede3cb1dd6@gmail.com> X-Mailer: Apple Mail (2.3445.5.20) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGKsWRmVeSWpSXmKPExsUixG6nrpvtuC7KYM1CDYuOBd1MFvO3LGGz WHV/BrsDs8fOWXfZPZYs+ckUwBTFZZOSmpNZllqkb5fAlfHu8BHmgtPqFV3HFjI1MHYpdzFy ckgImEic3nCHsYuRi0NIYDGTxNOXa1hAEkICGxkllv/2hEhcYZJo/v2OESTBJqAqMX1NC1MX IwcHr4CVxOmX/iBhZoEkiRk3r7CB2LxAQ9+/fQhWIixgLvH+IztImAWoc/3CPrASToFAies9 v5khWt0lGhZdZAKxRYBaF54+ywaxtplR4t2PY8wQhypJTP9+m20CI/8sJOtmIVkHEdeWWLbw NTOErSmxv3s5C6a4hkTnt4msCxjZVjHKpuRW6eYmZuYUpybrFicn5uWlFuma6uVmluilppRu YgQHuIvSDsaJ/7wOMQpwMCrx8B4oXhslxJpYVlyZe4hRkoNJSZT37uY1UUJ8SfkplRmJxRnx RaU5qcWHGCU4mJVEePcyrIsS4k1JrKxKLcqHSUlzsCiJ83qYaEcJCaQnlqRmp6YWpBbBZGU4 OJQkeB85ADUKFqWmp1akZeaUIKSZODhBhvMADZ8GUsNbXJCYW5yZDpE/xWjPsWftwzZmji2P XgLJA2DyxovXbcxCLHn5ealS4ry9IG0CIG0ZpXlwk0HJS751wt1XjOJAjwrzfrEHquIBJj64 2a+A1jIBrfVZugZkbUkiQkqqgbHnr8DmjJzO1YlXM2JuBp2rXuitwVgnuvmnw/9HgSHJtvyH 3xd8kdf14H1R6L3quWeP5trHd6rEP3CwMcfYqQp83J9w4NpbHtalKxv/RSw+sKPdSPg+29w/ JWIfGf9tCLomqzatutumas2GrsXuz8+tvhl9YMbBavm/fm4bb8+Yz3sr87rRcQYlluKMREMt 5qLiRACiCun2OQMAAA== Archived-At: Subject: Re: [Id-event] SecEvent IETF-101 agenda posted X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 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 Mar 2018 10:37:44 -0000 --Apple-Mail=_0A86B622-9790-4A1D-A98B-8E3A6A650DF4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Mayank, Remote participation information for the entire IETF meeting is here: https://ietf.org/how/meetings/101/remote/ = Remote support is provided for all official working group meetings. =E2=80=94 Justin > On Mar 18, 2018, at 7:47 AM, Mayank Bhatnagar = wrote: >=20 > hi Yaron, > thanks for this agenda. >=20 > However is there any online webex kind of link where we can connect = and participate from remote. > Also what are the dates. >=20 > thanks & regards, > Mayank >=20 >=20 > On Wed, Mar 7, 2018 at 1:19 PM, Yaron Sheffer > wrote: > https://datatracker.ietf.org/meeting/101/materials/agenda-101-secevent = >=20 > Let us know if you have any comments. >=20 > Thanks, > 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=_0A86B622-9790-4A1D-A98B-8E3A6A650DF4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Mayank,

Remote participation information for the entire IETF meeting = is here:

https://ietf.org/how/meetings/101/remote/

Remote support is = provided for all official working group meetings.
 =E2=80=94 Justin

On Mar 18, 2018, at 7:47 AM, Mayank Bhatnagar <mayankbhatnagar1178@gmail.com> wrote:

hi Yaron,
thanks = for this agenda.

However is there any online webex kind of link where we can = connect and participate from remote.
Also what are = the dates.

thanks & regards,
Mayank


On Wed, = Mar 7, 2018 at 1:19 PM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
=20 =20 =20 =20
https://datatracker.ietf.org/meeting/101/materials/agenda-101-secevent

Let us know if you have any comments.

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=_0A86B622-9790-4A1D-A98B-8E3A6A650DF4-- From nobody Sun Mar 18 04:09:32 2018 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 10160124B17 for ; Sun, 18 Mar 2018 04:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6wSW64t56RgP for ; Sun, 18 Mar 2018 04:09:29 -0700 (PDT) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBC991243FE for ; Sun, 18 Mar 2018 04:09:18 -0700 (PDT) Received: by mail-wr0-x234.google.com with SMTP id z8so6041235wrh.7 for ; Sun, 18 Mar 2018 04:09:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eo4MceLa+QkXs/OrvMp5BLsiGQrcqLH7iYoIXCWckYc=; b=qyG8Vc7tCTd+IS2E2uLpy3BVyGNSFJyo1Dt/vbFqjte24LyfwwGsoTg60E9rzNC8M+ TtRhBzlIovFACWA0/ijKxYBtsTBTYva01Ypt8Q8J/981ixNik+/IHCHtJbwK3SuZfnuc IgrYiDuqgWFV55K35sM9zuBxvb38sAxNclHClTihKiCGa8XwKn555OSb64UNP+XMPbeJ IiLRZLS6c2LhG8kKmAylx/dWEW2UWohiT7dxZOtTf7Cbt9NupBv1rQof7e0Vfqil6zCj 3nmVjA9pu3gzHBC0q0dAwuMJOnueCcrCwuyrurArXkDJwjXvNSMNLFqrWFizoQUf+Hhw k2Vw== 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=eo4MceLa+QkXs/OrvMp5BLsiGQrcqLH7iYoIXCWckYc=; b=m/10CgtnSUVXtlz9zZ60wfkHU9FUSJ+CrU2V39IYKHYMXVQBpFnNNY2OpySGTJHqQ1 purL3sPPO060uCIvy4M82FUlTuoQMf16aRDTXIQ22J0U82UAUkIegH8YnUH8XEkxIRWl VQuf7Pbz6BHCr6JNvypDo4pCjnrNRA1y+lLddexuuMmsPd33Mt7WV9mUoS9OXc4pZfsS Pt0A6IU5nEe9NOCpUv1+oD35vMWhldjxqhfwHgX7fREPubO2RCzySlbFMuP7yhWUOi2G +DyfuJU1Rfq9rQywpMdjSdKufbaQPMNsvcVWat9b/sptnJFrTZy7/ifHmpK7Ys6R3K2r PXPQ== X-Gm-Message-State: AElRT7EpnQVWq3EY9NEHirn1tLQKTXBV+vdMgZw6x4P/MsVUIc6OMpg+ ihfKhrjMXRLQiqSPKnDjfa0BZjGT1nWv5Zq7yrQ= X-Google-Smtp-Source: AG47ELs/TufS8fvfYyaJP3U4E8ex2LP6J4edVt9hf/soM6NNDTRRQdTQqIkgJ/d74UOdrDVOJBNNjiBZVQD/Ss+4gys= X-Received: by 10.223.151.1 with SMTP id r1mr6388049wrb.126.1521371357426; Sun, 18 Mar 2018 04:09:17 -0700 (PDT) MIME-Version: 1.0 References: <6212ca71-8583-c82d-6f51-45ede3cb1dd6@gmail.com> <9EEF1C94-5ADA-4BB1-9F28-6869BE0D2D0A@mit.edu> In-Reply-To: <9EEF1C94-5ADA-4BB1-9F28-6869BE0D2D0A@mit.edu> From: Mayank Bhatnagar Date: Sun, 18 Mar 2018 11:09:06 +0000 Message-ID: To: Justin Richer Cc: Yaron Sheffer , SecEvent Content-Type: multipart/alternative; boundary="f403045d5af454b9ee0567addf48" Archived-At: Subject: Re: [Id-event] SecEvent IETF-101 agenda posted X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 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 Mar 2018 11:09:31 -0000 --f403045d5af454b9ee0567addf48 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks a lot Justin. Regards, Mayank On Sun, Mar 18, 2018, 16:07 Justin Richer wrote: > Mayank, > > Remote participation information for the entire IETF meeting is here: > > https://ietf.org/how/meetings/101/remote/ > > Remote support is provided for all official working group meetings. > > =E2=80=94 Justin > > On Mar 18, 2018, at 7:47 AM, Mayank Bhatnagar < > mayankbhatnagar1178@gmail.com> wrote: > > hi Yaron, > thanks for this agenda. > > However is there any online webex kind of link where we can connect and > participate from remote. > Also what are the dates. > > thanks & regards, > Mayank > > > On Wed, Mar 7, 2018 at 1:19 PM, Yaron Sheffer > wrote: > >> https://datatracker.ietf.org/meeting/101/materials/agenda-101-secevent >> >> Let us know if you have any comments. >> >> 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 > > > --f403045d5af454b9ee0567addf48 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks a lot Justin.=C2=A0

Regards,=C2=A0
Mayank=C2=A0

On Sun, Mar 18, 2018, 16:= 07 Justin Richer <jricher@mit.edu= > wrote:
Mayank,

Remote= participation information for the entire IETF meeting is here:
<= br>


=C2=A0=E2=80=94 Justin

hi Yaron,
thanks for this agenda.

However= is there any online webex kind of link where we can connect and participat= e from remote.
Also what are the dates.

= thanks & regards,
Mayank


On Wed, Mar 7, 2018 at = 1:19 PM, Yaron Sheffer <yaronf.ietf@gmail.com&g= t; wrote:
=20 =20 =20 =20
https://datatracker.ietf.org/me= eting/101/materials/agenda-101-secevent

Let us know if you have any comments.

Thanks,
=C2=A0=C2=A0=C2=A0 Yaron

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


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

--f403045d5af454b9ee0567addf48-- From nobody Tue Mar 20 01:38:07 2018 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 CA2EA12D88D for ; Tue, 20 Mar 2018 01:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 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_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8jo2aCAXR1W for ; Tue, 20 Mar 2018 01:38:04 -0700 (PDT) Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F19B31205D3 for ; Tue, 20 Mar 2018 01:37:57 -0700 (PDT) Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w2K8TwUn089310 for ; Tue, 20 Mar 2018 08:37:57 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : content-type : mime-version : subject : message-id : date : to; s=corp-2017-10-26; bh=yzM7chM8olOb1ZYlywZN0ZKKoP1ZRY/8/VNTVFVupDI=; b=wCSXv9s0HAYbPXH6ZEz3uyx9shG9dHACsXpSNt2ziw3QFUIsmzuLK/Ec1acc8ySr8Wuw /E19u8edTb940YzbsR3OIBR7n3+f4GRAkl4kboZUbRY2CBXnBwkeQjIMu4kTtS54i2Q+ nqYMobB97xSnOnbikjB1EYPHCdlxBIIHPTjbWMjukOd5wXBAiYBWrmOOKYkEwrKum3CC D1WjCcPux/rEzgon9P04vER+d6JadDjLRzhSNfbvLz+OKgyPku6HqrciIgstfL1c7USU pmkbiqxufGiW+fnKbKnJCVym2Bgx5LOGiPS3ftMKusH4FfWXeGN7pePYildMd60RlcAC +A== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp2130.oracle.com with ESMTP id 2gtxu801qb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 20 Mar 2018 08:37:56 +0000 Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w2K8buLU005033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 20 Mar 2018 08:37:56 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w2K8bt2J010609 for ; Tue, 20 Mar 2018 08:37:55 GMT Received: from dhcp-9f83.meeting.ietf.org (/31.133.159.131) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 20 Mar 2018 01:37:55 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_F3F4C7B0-8271-403B-AE1F-251FA23F7EC7" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Message-Id: <6BD9FBF6-AB4A-4084-855C-C874B0F3D60B@oracle.com> Date: Tue, 20 Mar 2018 08:37:46 +0000 To: ID Events Mailing List X-Mailer: Apple Mail (2.3445.5.20) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8837 signatures=668693 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=792 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803200006 Archived-At: Subject: [Id-event] SECEVENTS Working Meetings at IETF101 X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 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: Tue, 20 Mar 2018 08:38:06 -0000 --Apple-Mail=_F3F4C7B0-8271-403B-AE1F-251FA23F7EC7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I have booked Waterloo (for 12 people) Tuesday at 6PM for one hour, and = Wednesday at 5:30 for one hour so that IETF101 attendees can meet to = discuss progressing the SET Delivery draft in advance of Friday=E2=80=99s = meeting. Apologies for the late times. These were the only slots available for = the sign-up rooms. All are welcome. Thanks, Phil Oracle Corporation, Identity Cloud Services Architect @independentid www.independentid.com = phil.hunt@oracle.com = --Apple-Mail=_F3F4C7B0-8271-403B-AE1F-251FA23F7EC7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = have booked Waterloo (for 12 people) Tuesday at 6PM for one hour, and = Wednesday at 5:30 for one hour so that IETF101 attendees can meet to = discuss progressing the SET Delivery draft in advance of Friday=E2=80=99s = meeting.

Apologies = for the late times. These were the only slots available for the sign-up = rooms.

All are = welcome.

Thanks,

Phil

Oracle Corporation, Identity Cloud = Services Architect
@independentid
www.independentid.com
phil.hunt@oracle.com

= --Apple-Mail=_F3F4C7B0-8271-403B-AE1F-251FA23F7EC7-- From nobody Tue Mar 20 14:31:38 2018 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 77DAB129C6C for ; Tue, 20 Mar 2018 14:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFoLDC9sOI1E for ; Tue, 20 Mar 2018 14:31:35 -0700 (PDT) Received: from aserp2120.oracle.com (aserp2120.oracle.com [141.146.126.78]) (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 66030129C6B for ; Tue, 20 Mar 2018 14:31:35 -0700 (PDT) Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w2KLUZw8015009 for ; Tue, 20 Mar 2018 21:31:34 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : content-type : mime-version : subject : message-id : date : to; s=corp-2017-10-26; bh=u2PKADxkJekLKUSSQmVbzYS0yuRYjzUBe1Ini5xJ3Ew=; b=auyiXMASWSPLQ8ptBGiK600nHycGM82Y9VWEM5qPg1MKkgBBCAPI0pZNvT2yBG7tktd/ 5W37/IgMT7FfnmY2c7zsgseT4vPaetE/c1cX6BMiBAwM/sALyk3zxhn4wQBWstk7H5Zw IIrlFm06uCP5vbxuQ+7JOuLhKhaC6NXrbiJpfW44syXM15xGO8yJVnSaQ6B0cgLkX+zc 5OU48I/elZyOm3m16rWYCD2nC6OZoXb8Hkpie4orkYUS8lZKfQfRFJmWClgCeCtNEoZu p1XRscrEgHl/uCEq5oFMv427ebj6KHqkqAtvM6EjVjLBWLbQukowF9dsvpEdwRcD+yX7 Qw== Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp2120.oracle.com with ESMTP id 2gua9b8041-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 20 Mar 2018 21:31:34 +0000 Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w2KLVXVH000985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 20 Mar 2018 21:31:33 GMT Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w2KLVXvs003156 for ; Tue, 20 Mar 2018 21:31:33 GMT Received: from dhcp-9f83.meeting.ietf.org (/31.133.159.131) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 20 Mar 2018 14:31:33 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_AE37AB18-E12D-4F0F-84CA-1DEFC213A1E3" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Message-Id: Date: Tue, 20 Mar 2018 21:31:32 +0000 To: ID Events Mailing List X-Mailer: Apple Mail (2.3445.5.20) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8838 signatures=668695 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=569 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803200127 Archived-At: Subject: [Id-event] rescheduled working meeting X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 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: Tue, 20 Mar 2018 21:31:37 -0000 --Apple-Mail=_AE37AB18-E12D-4F0F-84CA-1DEFC213A1E3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Due to some scheduling conflicts only a few could make it today. I also = notice that the proposed time of 6PM for tomorrow is in the middle of = the plenary. Instead of the 6PM session, I would like to suggest we get together for = lunch at the Fiamma restaurant(in the hotel) Wednesday at noon instead = of 6PM If that works, please confirm and I will cancel the 6PM session. Thanks Phil Oracle Corporation, Identity Cloud Services Architect @independentid www.independentid.com = phil.hunt@oracle.com = --Apple-Mail=_AE37AB18-E12D-4F0F-84CA-1DEFC213A1E3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Due = to some scheduling conflicts only a few could make it today. I also = notice that the proposed time of 6PM for tomorrow is in the middle of = the plenary.

Instead = of the 6PM session, I would like to suggest we get together for lunch at = the Fiamma restaurant(in the hotel) Wednesday at noon instead of = 6PM

If that = works, please confirm and I will cancel the 6PM session.

Thanks

Phil

Oracle Corporation, Identity Cloud = Services Architect
@independentid
www.independentid.com
phil.hunt@oracle.com

= --Apple-Mail=_AE37AB18-E12D-4F0F-84CA-1DEFC213A1E3-- From nobody Tue Mar 20 14:44:26 2018 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 58E81129C6B for ; Tue, 20 Mar 2018 14:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.809 X-Spam-Level: X-Spam-Status: No, score=-11.809 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r27_cH971x42 for ; Tue, 20 Mar 2018 14:44:23 -0700 (PDT) Received: from smtp-fw-6001.amazon.com (smtp-fw-6001.amazon.com [52.95.48.154]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98D4E12711D for ; Tue, 20 Mar 2018 14:44:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1521582263; x=1553118263; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=Rs99qvgwKc+4nmdRIFfDsVYexj+I6cwPG5jKwzBqPFg=; b=MBrubqwhO/pAMreyLEPNb2sg9VE9yv3F2subeMsKgj10+a4jYu9FKdTX Yil6CoZVqs+sRc/AMW8u2a1KwRF+dUI4hEirI/GrLdT5gWmgdCajIORas mfZ2bAYH9FqZ6kecI9EoLgYNngLP/6pxjAxT5cnolWhmha9eCTV9+9XoY o=; X-IronPort-AV: E=Sophos;i="5.48,337,1517875200"; d="scan'208,217";a="336674565" Received: from iad6-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-2b-3714e498.us-west-2.amazon.com) ([10.124.125.6]) by smtp-border-fw-out-6001.iad6.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Mar 2018 21:44:20 +0000 Received: from EX13MTAUWC001.ant.amazon.com (pdx1-ws-svc-p6-lb9-vlan3.pdx.amazon.com [10.236.137.198]) by email-inbound-relay-2b-3714e498.us-west-2.amazon.com (8.14.7/8.14.7) with ESMTP id w2KLiKne001160 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 20 Mar 2018 21:44:20 GMT Received: from EX13D11UWC003.ant.amazon.com (10.43.162.162) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Tue, 20 Mar 2018 21:44:19 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC003.ant.amazon.com (10.43.162.162) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Tue, 20 Mar 2018 21:44:19 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1236.000; Tue, 20 Mar 2018 21:44:19 +0000 From: "Richard Backman, Annabelle" To: Phil Hunt , ID Events Mailing List Thread-Topic: [Id-event] rescheduled working meeting Thread-Index: AQHTwJL/ZsVAofz3U0iojA/PNdrSq6PZqA2A Date: Tue, 20 Mar 2018 21:44:19 +0000 Message-ID: <0696AC5B-9BE5-4F37-80F8-BF94C79995DE@amazon.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.b.0.180311 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.160.200] Content-Type: multipart/alternative; boundary="_000_0696AC5B9BE54F3780F8BF94C79995DEamazoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Id-event] rescheduled working meeting X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 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: Tue, 20 Mar 2018 21:44:25 -0000 --_000_0696AC5B9BE54F3780F8BF94C79995DEamazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhdCB3b3JrcyBmb3IgbWUuDQoNCi0tDQpBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQpBbWF6 b24g4oCTIElkZW50aXR5IFNlcnZpY2VzDQoNCkZyb206IElkLWV2ZW50IDxpZC1ldmVudC1ib3Vu Y2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgUGhpbCBIdW50IDxwaGlsLmh1bnRAb3JhY2xlLmNv bT4NCkRhdGU6IFR1ZXNkYXksIE1hcmNoIDIwLCAyMDE4IGF0IDk6MzIgUE0NClRvOiBJRCBFdmVu dHMgTWFpbGluZyBMaXN0IDxpZC1ldmVudEBpZXRmLm9yZz4NClN1YmplY3Q6IFtJZC1ldmVudF0g cmVzY2hlZHVsZWQgd29ya2luZyBtZWV0aW5nDQoNCkR1ZSB0byBzb21lIHNjaGVkdWxpbmcgY29u ZmxpY3RzIG9ubHkgYSBmZXcgY291bGQgbWFrZSBpdCB0b2RheS4gSSBhbHNvIG5vdGljZSB0aGF0 IHRoZSBwcm9wb3NlZCB0aW1lIG9mIDZQTSBmb3IgdG9tb3Jyb3cgaXMgaW4gdGhlIG1pZGRsZSBv ZiB0aGUgcGxlbmFyeS4NCg0KSW5zdGVhZCBvZiB0aGUgNlBNIHNlc3Npb24sIEkgd291bGQgbGlr ZSB0byBzdWdnZXN0IHdlIGdldCB0b2dldGhlciBmb3IgbHVuY2ggYXQgdGhlIEZpYW1tYSByZXN0 YXVyYW50KGluIHRoZSBob3RlbCkgV2VkbmVzZGF5IGF0IG5vb24gaW5zdGVhZCBvZiA2UE0NCg0K SWYgdGhhdCB3b3JrcywgcGxlYXNlIGNvbmZpcm0gYW5kIEkgd2lsbCBjYW5jZWwgdGhlIDZQTSBz ZXNzaW9uLg0KDQpUaGFua3MNCg0KUGhpbA0KDQpPcmFjbGUgQ29ycG9yYXRpb24sIElkZW50aXR5 IENsb3VkIFNlcnZpY2VzIEFyY2hpdGVjdA0KQGluZGVwZW5kZW50aWQNCnd3dy5pbmRlcGVuZGVu dGlkLmNvbTxodHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29tPg0KcGhpbC5odW50QG9yYWNsZS5j b208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPg0KDQo= --_000_0696AC5B9BE54F3780F8BF94C79995DEamazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <116CAA9AF67A5442AB76452DCF9291FE@amazon.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5h cHBsZS1zdHlsZS1zcGFuDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLXN0eWxlLXNwYW47fQ0Kc3Bh bi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0 O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRoYXQgd29ya3MgZm9yIG1lLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4tLSZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+QW5uYWJlbGxlIFJpY2hh cmQgQmFja21hbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyxzZXJpZiI+QW1hem9uIOKAkyBJZGVudGl0eSBTZXJ2aWNlczxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+SWQtZXZlbnQg Jmx0O2lkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBQaGlsIEh1bnQg Jmx0O3BoaWwuaHVudEBvcmFjbGUuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UdWVzZGF5LCBN YXJjaCAyMCwgMjAxOCBhdCA5OjMyIFBNPGJyPg0KPGI+VG86IDwvYj5JRCBFdmVudHMgTWFpbGlu ZyBMaXN0ICZsdDtpZC1ldmVudEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+W0lk LWV2ZW50XSByZXNjaGVkdWxlZCB3b3JraW5nIG1lZXRpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxPcmlnaW5hbEJv ZHkiPkR1ZSB0byBzb21lIHNjaGVkdWxpbmcgY29uZmxpY3RzIG9ubHkgYSBmZXcgY291bGQgbWFr ZSBpdCB0b2RheS4gSSBhbHNvIG5vdGljZSB0aGF0IHRoZSBwcm9wb3NlZCB0aW1lIG9mIDZQTSBm b3IgdG9tb3Jyb3cgaXMgaW4gdGhlIG1pZGRsZSBvZiB0aGUgcGxlbmFyeS4NCjxvOnA+PC9vOnA+ PC9hPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJv b2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2tt YXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5JbnN0ZWFkIG9mIHRoZSA2UE0gc2Vzc2lvbiwgSSB3b3Vs ZCBsaWtlIHRvIHN1Z2dlc3Qgd2UgZ2V0IHRvZ2V0aGVyIGZvciBsdW5jaCBhdCB0aGUgRmlhbW1h IHJlc3RhdXJhbnQoaW4gdGhlIGhvdGVsKSBXZWRuZXNkYXkgYXQgbm9vbiBpbnN0ZWFkIG9mIDZQ TTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPklmIHRoYXQgd29y a3MsIHBsZWFzZSBjb25maXJtIGFuZCBJIHdpbGwgY2FuY2VsIHRoZSA2UE0gc2Vzc2lvbi48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5UaGFua3M8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i bXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PlBoaWw8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9k eSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij5PcmFjbGUgQ29ycG9yYXRpb24sIElkZW50aXR5IENsb3VkIFNlcnZpY2VzIEFyY2hpdGVjdDxv OnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPkBpbmRlcGVuZGVudGlkPG86cD48L286cD48L3NwYW4+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjwvc3Bhbj48YSBocmVmPSJodHRwOi8v d3d3LmluZGVwZW5kZW50aWQuY29tIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3Jp Z2luYWxCb2R5Ij53d3cuaW5kZXBlbmRlbnRpZC5jb208L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1i b29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJv b2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+ PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmln aW5hbEJvZHkiPjwvc3Bhbj48YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iPjxz cGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPnBoaWwuaHVudEBvcmFj bGUuY29tPC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHki Pjwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5h bEJvZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_0696AC5B9BE54F3780F8BF94C79995DEamazoncom_-- From nobody Wed Mar 21 03:52:12 2018 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 1AB6112E039 for ; Wed, 21 Mar 2018 03:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.376 X-Spam-Level: X-Spam-Status: No, score=-0.376 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_HEX=1.122, URI_NOVOWEL=0.5] autolearn=no 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 NBeKTQb6ritW for ; Wed, 21 Mar 2018 03:51:58 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0104.outbound.protection.outlook.com [104.47.42.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12F0D12EB5D for ; Wed, 21 Mar 2018 03:51:58 -0700 (PDT) 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=FMePrWSEr36DaUD592QTvX8qIT+XKacpGvQi8W6Pocg=; b=XeWIuGo9CQtBIyznmFhumvs1xuvS3McuxTmlpq6EbzUsBKaBl/2Dcrw4R3Xd9ATySypTl14PtvkJ0YW2ZDDwOMk96E5eIcGAkYMDv5YqrzpQ04Wi/Z/pZsJUA4xODO4obxtH5cjNTcSXUY4ZU8NkDsZG4AOVVT8KCPaD03s9Rb8= Received: from DM5PR00MB0358.namprd00.prod.outlook.com (52.132.128.165) by DM5PR00MB0296.namprd00.prod.outlook.com (52.132.128.37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.647.0; Wed, 21 Mar 2018 10:51:53 +0000 Received: from DM5PR00MB0358.namprd00.prod.outlook.com ([fe80::8d3d:4ea5:9f33:829f]) by DM5PR00MB0358.namprd00.prod.outlook.com ([fe80::8d3d:4ea5:9f33:829f%4]) with mapi id 15.20.0650.000; Wed, 21 Mar 2018 10:51:53 +0000 From: Anthony Nadalin To: Phil Hunt , ID Events Mailing List Thread-Topic: [Id-event] rescheduled working meeting Thread-Index: AQHTwJLZc+SREd/MfU22ID3+HcixDqPahArA Date: Wed, 21 Mar 2018 10:51:53 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [167.220.196.70] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR00MB0296; 7:upVinD6pTrwCl9REn2ZvcSNvT0/9uoB9rmEGsTsTewmg0KYuRu8Bxp9h7dc64KQAqs+VJrT9N68gxyIc4hTvhJ9lSqOY0jo10HAgNof3X6bdDCmkNJh4xDZEQWK8dDfjzs57j62VEa+UbLc+B86YkiUfhMmDfiVxR27XvbYBZRQKQEckNUsq62PensbJinTaR+9PjbKecgZJnlsKxlY9cwZea54RY88x+2XEvPUycco4GI2zEBZ7hj046e/Ja6hC; 20:QCKYT9OOyvAuCbbJIy5YLg9bn55RZvpUgnJxSpBxc4He/xNA6/3d7eVOXx9QUApgrYNmEKuF3vYgaOra3HauOX0H+LSSNEGwMrBUeRbJIOYjZdGdjBHkkECX8ZVvvWZQZs5gafJsUJ9GDrTlG1ke6Ub8aLzS1r505H1+oLiv/+8= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 26a52f44-b398-4520-67cf-08d58f19c1dd x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:DM5PR00MB0296; x-ms-traffictypediagnostic: DM5PR00MB0296: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(189930954265078)(219752817060721)(21748063052155)(146099531331640); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(3231221)(944501305)(52105095)(6055026)(61426038)(61427038)(6041310)(20161123562045)(20161123564045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:DM5PR00MB0296; BCL:0; PCL:0; RULEID:; SRVR:DM5PR00MB0296; x-forefront-prvs: 0618E4E7E1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(366004)(39380400002)(396003)(376002)(39860400002)(189003)(199004)(53824002)(14454004)(66066001)(606006)(6346003)(26005)(2906002)(186003)(102836004)(8936002)(3660700001)(7736002)(74316002)(81166006)(3280700002)(81156014)(106356001)(8676002)(2950100002)(790700001)(105586002)(236005)(9686003)(5250100002)(33656002)(55016002)(10290500003)(53936002)(6246003)(54896002)(6306002)(68736007)(25786009)(6116002)(97736004)(316002)(22452003)(8990500004)(3846002)(229853002)(19609705001)(478600001)(6436002)(10090500001)(6506007)(86362001)(76176011)(99286004)(2900100001)(110136005)(59450400001)(53546011)(5660300001)(7696005)(86612001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR00MB0296; H:DM5PR00MB0358.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=tonynad@microsoft.com; x-microsoft-antispam-message-info: PSjt53WrkkTMoaqS49RuPqSPYcdZrIND99o5vlb17Axy9sHX1WoSzmZGZMhvennCsEcYV+r1l6sVuW/wqd1BxL13T16n4K9s9OyuVufYz7TUOygCOhIQ2fUUlGbZD4ra0FatbAfqJ0JHYzs/6V6Hkjnl1KFp5DvH1wOUc1Yv3iZyNd0w8kvylinQBa2LXYkkRVtU9wufnqGZulVcK2K4mvsXSJX0WeGkpNJgoLRy2x7rRv8PuxbWK+74bYIM6ynFL1LrY3xVeqGN1XmTY3skppEzV0oQk59L/iWVBD4/XX/w2j0Ej7zCK25FZoMnBfzrleqvKLxi05VzuDJC/F54xw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR00MB03588A7DA9CA376396EB97B7A6AA0DM5PR00MB0358namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 26a52f44-b398-4520-67cf-08d58f19c1dd X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Mar 2018 10:51:53.1419 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR00MB0296 Archived-At: Subject: Re: [Id-event] rescheduled working meeting X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 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 Mar 2018 10:52:00 -0000 --_000_DM5PR00MB03588A7DA9CA376396EB97B7A6AA0DM5PR00MB0358namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable WFM From: Id-event On Behalf Of Phil Hunt Sent: Tuesday, March 20, 2018 2:32 PM To: ID Events Mailing List Subject: [Id-event] rescheduled working meeting Due to some scheduling conflicts only a few could make it today. I also not= ice that the proposed time of 6PM for tomorrow is in the middle of the plen= ary. Instead of the 6PM session, I would like to suggest we get together for lun= ch at the Fiamma restaurant(in the hotel) Wednesday at noon instead of 6PM If that works, please confirm and I will cancel the 6PM session. Thanks Phil Oracle Corporation, Identity Cloud Services Architect @independentid www.independentid.com phil.hunt@oracle.com --_000_DM5PR00MB03588A7DA9CA376396EB97B7A6AA0DM5PR00MB0358namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

WFM

 

From: Id-event <id-event-bounces@ietf.org&= gt; On Behalf Of Phil Hunt
Sent: Tuesday, March 20, 2018 2:32 PM
To: ID Events Mailing List <id-event@ietf.org>
Subject: [Id-event] rescheduled working meeting

 

Due to some scheduling conflicts only a few could ma= ke it today. I also notice that the proposed time of 6PM for tomorrow is in= the middle of the plenary.

 

Instead of the 6PM session, I would like to suggest = we get together for lunch at the Fiamma restaurant(in the hotel) Wednesday = at noon instead of 6PM

 

If that works, please confirm and I will cancel the = 6PM session.

 

Thanks

 

Phil

 =

Oracle Corporation, Iden= tity Cloud Services Architect

@independentid

phil.hunt@oracle.com

 

--_000_DM5PR00MB03588A7DA9CA376396EB97B7A6AA0DM5PR00MB0358namp_-- From nobody Wed Mar 21 03:59:23 2018 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 79B8312EB6F for ; Wed, 21 Mar 2018 03:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.375 X-Spam-Level: X-Spam-Status: No, score=-0.375 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_HEX=1.122, URI_NOVOWEL=0.5] 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 10_P2O1Mbon8 for ; Wed, 21 Mar 2018 03:59:16 -0700 (PDT) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::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 3A2F712EB45 for ; Wed, 21 Mar 2018 03:59:16 -0700 (PDT) Received: by mail-wr0-x22f.google.com with SMTP id z12so4726117wrg.4 for ; Wed, 21 Mar 2018 03:59:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:user-agent:in-reply-to:references:mime-version :content-transfer-encoding:subject:to:from:message-id; bh=1IsgDRA64Rgh5aTWD5C0VTlHpNmVshD5bPrQGZF52hc=; b=gVtULiO81ua1HifRRR0qNaweNdak2Xhek6KupAeAp+mbk3tahq3oC9k7B+Yzp81MpI oP9uOgrHx4BzNVPvnKKfkQKyHM7h1WmslD2Ok8E8HeIObBOGv/iutiCnvblf82ac8fU2 CsumdhMcY5CWeUXmZTzH7jdJJRQu4BFXarCMpUXJZ1cJBrmwtFXrprD5N3Yz75MEzJ4K xqUdDND/uoIxskah6qguqDsWbpcUp6gCEeiSrdraCtV0D6DAWFqKL4M+T6Ny/6j+uJGX 8oPnow1U5x2dnxjcdyjHfirT3jqAaSQKWNBKQ7e3MzRXRjzjyhMIHVtofCIu0NufvW/T qQbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:user-agent:in-reply-to:references :mime-version:content-transfer-encoding:subject:to:from:message-id; bh=1IsgDRA64Rgh5aTWD5C0VTlHpNmVshD5bPrQGZF52hc=; b=RuBvskYHckc18X4OdwlwS0672Q0aBu2W4AZstGf6EjHPL0g94W/iKFNkF1JqMYFw/b QnpA4r8rclhbZUumtOKdi2e/QD0cWcaZVVaiOh5U+0q8RiLAcMR4C2y3mVKhDn5az3Rj EP6PBankDu3feZ+ylS5toI39wCFUvJxA0qi7Y9R7Cp1eMhxcGkc0Ghx5IV7fZePvDuKB LdKsIgRqitNwpFS5hTtERz4ogTQPchGw0XyK25az6+ODmERbqUzfhP4tt0kLEqHSqA2+ /1Yw99+fP9vhaP7logLkDohou2G+4ogN/o2IAXLN9bbmgXEM7qLlDcIMbSfiPiebdKu2 lm/Q== X-Gm-Message-State: AElRT7H7IErGB7AhUMW61WWyiIreXZIwe2giCHFA6lpuVdis7UGjZ0ja p6aaqE8v+BPHBmrIuznZAgCqndq4 X-Google-Smtp-Source: AG47ELt5rSaBlHKatEBk5+6nCgSyTwrl8IP5nz8hZuMzGQPzllXPwKO85BIFs7wkg1H978snrYYxqw== X-Received: by 10.223.188.135 with SMTP id g7mr11393832wrh.69.1521629954489; Wed, 21 Mar 2018 03:59:14 -0700 (PDT) Received: from [10.169.144.209] ([2.53.29.203]) by smtp.gmail.com with ESMTPSA id d48sm7732968wrd.12.2018.03.21.03.59.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Mar 2018 03:59:13 -0700 (PDT) Date: Wed, 21 Mar 2018 10:59:00 +0000 User-Agent: K-9 Mail for Android In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----LCTNDU6KNW1WRDJBTXA2FXCJ6NDKW3" Content-Transfer-Encoding: 7bit To: id-event@ietf.org, Anthony Nadalin , Phil Hunt , ID Events Mailing List From: Yaron Sheffer Message-ID: <5187F096-0BB0-4636-A4C0-ED50B58553AB@gmail.com> Archived-At: Subject: Re: [Id-event] rescheduled working meeting X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 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 Mar 2018 10:59:18 -0000 ------LCTNDU6KNW1WRDJBTXA2FXCJ6NDKW3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Not for me, but please have the meeting anyway=2E=20 On March 21, 2018 10:51:53 AM GMT, Anthony Nadalin wrote: >WFM > >From: Id-event On Behalf Of Phil Hunt >Sent: Tuesday, March 20, 2018 2:32 PM >To: ID Events Mailing List >Subject: [Id-event] rescheduled working meeting > >Due to some scheduling conflicts only a few could make it today=2E I also >notice that the proposed time of 6PM for tomorrow is in the middle of >the plenary=2E > >Instead of the 6PM session, I would like to suggest we get together for >lunch at the Fiamma restaurant(in the hotel) Wednesday at noon instead >of 6PM > >If that works, please confirm and I will cancel the 6PM session=2E > >Thanks > >Phil > >Oracle Corporation, Identity Cloud Services Architect >@independentid >www=2Eindependentid=2Ecom >phil=2Ehunt@oracle=2Ecom ------LCTNDU6KNW1WRDJBTXA2FXCJ6NDKW3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Not for me, but please= have the meeting anyway=2E

On March 21,= 2018 10:51:53 AM GMT, Anthony Nadalin <tonynad@microsoft=2Ecom> wrot= e:

WFM

 

From: Id-event <id-event-bounces@ietf=2Eo= rg> On Behalf Of Phil Hunt
Sent: Tuesday, March 20, 2018 2:32 PM
To: ID Events Mailing List <id-event@ietf=2Eorg>
Subject: [Id-event] rescheduled working meeting

 

Due to some scheduling conflicts only a few could m= ake it today=2E I also notice that the proposed time of 6PM for tomorrow is= in the middle of the plenary=2E

 

Instead of the 6PM session, I would like to suggest= we get together for lunch at the Fiamma restaurant(in the hotel) Wednesday= at noon instead of 6PM

 

If that works, please confirm and I will cancel the= 6PM session=2E

 

Thanks

 

Phil<= /p>

 

Oracle Corporation, Ide= ntity Cloud Services Architect

@independentid

phil=2Ehunt@oracle=2Ecom

 

------LCTNDU6KNW1WRDJBTXA2FXCJ6NDKW3-- From nobody Wed Mar 21 06:43:29 2018 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 3D2F81243FE for ; Wed, 21 Mar 2018 06:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 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_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7NHiv3M4LL2y for ; Wed, 21 Mar 2018 06:43:21 -0700 (PDT) Received: from userp2120.oracle.com (userp2120.oracle.com [156.151.31.85]) (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 5347912EAB4 for ; Wed, 21 Mar 2018 06:43:19 -0700 (PDT) Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w2LDZkg5094963 for ; Wed, 21 Mar 2018 13:43:18 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : content-type : mime-version : subject : message-id : date : to; s=corp-2017-10-26; bh=9EOE5sf2UIjtE/TtAItppnH6JvuMGQFL2CRwudzNrzs=; b=L7rwmokKBtx2J8cBm0iLiwVAHOwn/HQVN/KTAYszK3fD8A7ZuCbP8lEKApl9A6c2fIIF +Vs07Tn7k0ovbKNue1t1BVOI1DpeHDqVAq4cYp3I1viCNFwwUydFoGzkaho93aG0e/j2 Z123jxUWkQf79WY8Sk8eCE8hb4rVWTzvT6A1bi7GpSAerqGmRbtaMIKDN2CEp37ThHO8 fG1eeHrra63hF7k6GXbkE/1meASGt8jWaOem1ZbRig+eZQgoa7Sy5jBVB3V/oHlJmUzK n25PG+9MgsvKwgK1bS/xitGXz3xKJcOSnpHnE9vyfg7Yqwg8KRpxbCAh7GQJzYsOLAP1 bA== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp2120.oracle.com with ESMTP id 2gurdpr19r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 21 Mar 2018 13:43:18 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w2LDhHrw003335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 21 Mar 2018 13:43:17 GMT Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w2LDhH7Q021685 for ; Wed, 21 Mar 2018 13:43:17 GMT Received: from dhcp-9f83.meeting.ietf.org (/31.133.159.131) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 21 Mar 2018 06:43:17 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_04B39826-CEE4-4C60-A254-C0EA053D115C" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Message-Id: <99920B12-09F2-4293-B214-F766C00CAE6E@oracle.com> Date: Wed, 21 Mar 2018 13:43:08 +0000 To: ID Events Mailing List X-Mailer: Apple Mail (2.3445.5.20) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8838 signatures=668695 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803200127 Archived-At: Subject: [Id-event] Summary of working session discussion X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 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 Mar 2018 13:43:28 -0000 --Apple-Mail=_04B39826-CEE4-4C60-A254-C0EA053D115C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii We held a couple of brief sessions over the last couple days. We talked about the issue of breaking up the delivery document, multiple = delivery methods, and optionality. Some observations: 1. Yaron indicated that the IETF will likely require one method be MTI = (mandatory to implement). While PUSH has better scale (because it does not need HTTP Long = Polling), the POLL method has broader utility due to the presence of = receivers with firewalls, gateways (IoT devices), or are mobile = applications that cannot implement endpoints to receive HTTP POSTs. 2. If POLL is chosen as the MTI method, many will still likely prefer = PUSH and so that will likely get implemented sooner by some 3. There was a general feeling that the delivery draft should stay as = one draft. Annabelle will present her recommendations at the formal meeting on = Friday where we can get broader input. Thanks everyone. Phil Oracle Corporation, Identity Cloud Services Architect @independentid www.independentid.com = phil.hunt@oracle.com = --Apple-Mail=_04B39826-CEE4-4C60-A254-C0EA053D115C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii We = held a couple of brief sessions over the last couple days.

We talked about the = issue of breaking up the delivery document, multiple delivery methods, = and optionality.

Some observations:

1. Yaron indicated that the IETF will = likely require one method be MTI (mandatory to implement).

While PUSH has better = scale (because it does not need HTTP Long Polling), the POLL method has = broader utility due to the presence of receivers with firewalls, = gateways (IoT devices), or are mobile applications that cannot implement = endpoints to receive HTTP POSTs.

2.  If POLL is chosen as the MTI = method, many will still likely prefer PUSH and so that will likely get = implemented sooner by some

3.  There was a general feeling that the delivery draft = should stay as one draft.

Annabelle will present her recommendations at the formal = meeting on Friday where we can get broader input.
Thanks everyone.

Phil

Oracle Corporation, Identity Cloud = Services Architect
@independentid
www.independentid.com
phil.hunt@oracle.com

= --Apple-Mail=_04B39826-CEE4-4C60-A254-C0EA053D115C-- From nobody Wed Mar 21 07:25:53 2018 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 5D54112DA3D for ; Wed, 21 Mar 2018 07:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.508 X-Spam-Level: X-Spam-Status: No, score=-14.508 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25cTRQ6UBxwQ for ; Wed, 21 Mar 2018 07:25:50 -0700 (PDT) Received: from smtp-fw-9101.amazon.com (smtp-fw-9101.amazon.com [207.171.184.25]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AE711271FD for ; Wed, 21 Mar 2018 07:25:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1521642351; x=1553178351; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=nkmxRDCDrxaP+iKmi2UbSMX3ryr3Y+9BtjOJgPdjTmE=; b=c5LNUbFiDtJo43D5pR0PRBvmgYuMVkJRs4CmoQRcQfBuQlHLcMNtQIqj VvANJAtVoaHU98dBNMyLW6xNeVrG8yeEydub1WhKk8fhg4b9LNhpzI2Iy fc4W/RO8Cc8KxfUeVrE4S24gs59Gc6ItTlIk3jm2H/Uj2WU2Uz0TEc8OK o=; X-IronPort-AV: E=Sophos;i="5.48,340,1517875200"; d="scan'208,217";a="729788255" Received: from sea3-co-svc-lb6-vlan3.sea.amazon.com (HELO email-inbound-relay-1a-821c648d.us-east-1.amazon.com) ([10.47.22.38]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Mar 2018 14:25:49 +0000 Received: from EX13MTAUWC001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan2.iad.amazon.com [10.40.159.162]) by email-inbound-relay-1a-821c648d.us-east-1.amazon.com (8.14.7/8.14.7) with ESMTP id w2LEPhJO104640 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 21 Mar 2018 14:25:47 GMT Received: from EX13D11UWC001.ant.amazon.com (10.43.162.151) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Wed, 21 Mar 2018 14:25:46 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC001.ant.amazon.com (10.43.162.151) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Wed, 21 Mar 2018 14:25:46 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1236.000; Wed, 21 Mar 2018 14:25:46 +0000 From: "Richard Backman, Annabelle" To: Phil Hunt , ID Events Mailing List Thread-Topic: [Id-event] Summary of working session discussion Thread-Index: AQHTwRq4/xeH4dPkh06PLJmjGpczJqPavseA Date: Wed, 21 Mar 2018 14:25:46 +0000 Message-ID: <62BA0863-97B7-48EA-A313-DBBEC91CF310@amazon.com> References: <99920B12-09F2-4293-B214-F766C00CAE6E@oracle.com> In-Reply-To: <99920B12-09F2-4293-B214-F766C00CAE6E@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.b.0.180311 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.161.135] Content-Type: multipart/alternative; boundary="_000_62BA086397B748EAA313DBBEC91CF310amazoncom_" MIME-Version: 1.0 Precedence: Bulk Archived-At: Subject: Re: [Id-event] Summary of working session discussion X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 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 Mar 2018 14:25:52 -0000 --_000_62BA086397B748EAA313DBBEC91CF310amazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U21hbGwgY29ycmVjdGlvbjogSSB3aWxsIHByZXNlbnQgYSBzdW1tYXJ5IG9mIHRoZSBkcmFmdCwg Y3VycmVudCBzdGF0dXMsIGFuZCBvdmVydmlldyBvZiB0aGUgb3BlbiBxdWVzdGlvbnMuDQoNCkkg d2lsbCByZXNlcnZlIG15IHJlY29tbWVuZGF0aW9ucyBmb3IgdGhlIGRpc2N1c3Npb24gdG8gZm9s bG93LiDimLoNCg0KLS0NCkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW4NCkFtYXpvbiDigJMgSWRl bnRpdHkgU2VydmljZXMNCg0KRnJvbTogSWQtZXZlbnQgPGlkLWV2ZW50LWJvdW5jZXNAaWV0Zi5v cmc+IG9uIGJlaGFsZiBvZiBQaGlsIEh1bnQgPHBoaWwuaHVudEBvcmFjbGUuY29tPg0KRGF0ZTog V2VkbmVzZGF5LCBNYXJjaCAyMSwgMjAxOCBhdCAxOjQ0IFBNDQpUbzogSUQgRXZlbnRzIE1haWxp bmcgTGlzdCA8aWQtZXZlbnRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbSWQtZXZlbnRdIFN1bW1hcnkg b2Ygd29ya2luZyBzZXNzaW9uIGRpc2N1c3Npb24NCg0KV2UgaGVsZCBhIGNvdXBsZSBvZiBicmll ZiBzZXNzaW9ucyBvdmVyIHRoZSBsYXN0IGNvdXBsZSBkYXlzLg0KDQpXZSB0YWxrZWQgYWJvdXQg dGhlIGlzc3VlIG9mIGJyZWFraW5nIHVwIHRoZSBkZWxpdmVyeSBkb2N1bWVudCwgbXVsdGlwbGUg ZGVsaXZlcnkgbWV0aG9kcywgYW5kIG9wdGlvbmFsaXR5Lg0KDQpTb21lIG9ic2VydmF0aW9uczoN Cg0KMS4gWWFyb24gaW5kaWNhdGVkIHRoYXQgdGhlIElFVEYgd2lsbCBsaWtlbHkgcmVxdWlyZSBv bmUgbWV0aG9kIGJlIE1USSAobWFuZGF0b3J5IHRvIGltcGxlbWVudCkuDQoNCldoaWxlIFBVU0gg aGFzIGJldHRlciBzY2FsZSAoYmVjYXVzZSBpdCBkb2VzIG5vdCBuZWVkIEhUVFAgTG9uZyBQb2xs aW5nKSwgdGhlIFBPTEwgbWV0aG9kIGhhcyBicm9hZGVyIHV0aWxpdHkgZHVlIHRvIHRoZSBwcmVz ZW5jZSBvZiByZWNlaXZlcnMgd2l0aCBmaXJld2FsbHMsIGdhdGV3YXlzIChJb1QgZGV2aWNlcyks IG9yIGFyZSBtb2JpbGUgYXBwbGljYXRpb25zIHRoYXQgY2Fubm90IGltcGxlbWVudCBlbmRwb2lu dHMgdG8gcmVjZWl2ZSBIVFRQIFBPU1RzLg0KDQoyLiAgSWYgUE9MTCBpcyBjaG9zZW4gYXMgdGhl IE1USSBtZXRob2QsIG1hbnkgd2lsbCBzdGlsbCBsaWtlbHkgcHJlZmVyIFBVU0ggYW5kIHNvIHRo YXQgd2lsbCBsaWtlbHkgZ2V0IGltcGxlbWVudGVkIHNvb25lciBieSBzb21lDQoNCjMuICBUaGVy ZSB3YXMgYSBnZW5lcmFsIGZlZWxpbmcgdGhhdCB0aGUgZGVsaXZlcnkgZHJhZnQgc2hvdWxkIHN0 YXkgYXMgb25lIGRyYWZ0Lg0KDQpBbm5hYmVsbGUgd2lsbCBwcmVzZW50IGhlciByZWNvbW1lbmRh dGlvbnMgYXQgdGhlIGZvcm1hbCBtZWV0aW5nIG9uIEZyaWRheSB3aGVyZSB3ZSBjYW4gZ2V0IGJy b2FkZXIgaW5wdXQuDQoNClRoYW5rcyBldmVyeW9uZS4NCg0KUGhpbA0KDQpPcmFjbGUgQ29ycG9y YXRpb24sIElkZW50aXR5IENsb3VkIFNlcnZpY2VzIEFyY2hpdGVjdA0KQGluZGVwZW5kZW50aWQN Cnd3dy5pbmRlcGVuZGVudGlkLmNvbTxodHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29tPg0KcGhp bC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPg0KDQo= --_000_62BA086397B748EAA313DBBEC91CF310amazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <2E91D70D5315AE42A6E32910DC794261@amazon.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJBcHBsZSBD b2xvciBFbW9qaSI7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAgMDt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93 ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25v cm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDph dXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJ bWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5hcHBsZS1zdHlsZS1zcGFuDQoJe21zby1zdHlsZS1uYW1l OmFwcGxlLXN0eWxlLXNwYW47fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjgu NWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNtYWxsIGNvcnJlY3Rpb246IEkg d2lsbCBwcmVzZW50IGEgc3VtbWFyeSBvZiB0aGUgZHJhZnQsIGN1cnJlbnQgc3RhdHVzLCBhbmQg b3ZlcnZpZXcgb2YgdGhlIG9wZW4gcXVlc3Rpb25zLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J IHdpbGwgcmVzZXJ2ZSBteSByZWNvbW1lbmRhdGlvbnMgZm9yIHRoZSBkaXNjdXNzaW9uIHRvIGZv bGxvdy4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcHBsZSBDb2xvciBFbW9qaSZx dW90OyI+4pi6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LHNlcmlmIj4tLSZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+QW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJp ZiI+QW1hem9uIOKAkyBJZGVudGl0eSBTZXJ2aWNlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzoz LjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+SWQtZXZlbnQgJmx0O2lkLWV2ZW50LWJv dW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBQaGlsIEh1bnQgJmx0O3BoaWwuaHVudEBv cmFjbGUuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5XZWRuZXNkYXksIE1hcmNoIDIxLCAyMDE4 IGF0IDE6NDQgUE08YnI+DQo8Yj5UbzogPC9iPklEIEV2ZW50cyBNYWlsaW5nIExpc3QgJmx0O2lk LWV2ZW50QGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5bSWQtZXZlbnRdIFN1bW1h cnkgb2Ygd29ya2luZyBzZXNzaW9uIGRpc2N1c3Npb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxPcmlnaW5hbEJvZHki PldlIGhlbGQgYSBjb3VwbGUgb2YgYnJpZWYgc2Vzc2lvbnMgb3ZlciB0aGUgbGFzdCBjb3VwbGUg ZGF5cy4NCjxvOnA+PC9vOnA+PC9hPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5XZSB0YWxrZWQgYWJvdXQg dGhlIGlzc3VlIG9mIGJyZWFraW5nIHVwIHRoZSBkZWxpdmVyeSBkb2N1bWVudCwgbXVsdGlwbGUg ZGVsaXZlcnkgbWV0aG9kcywgYW5kIG9wdGlvbmFsaXR5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9v a21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21h cms6X01haWxPcmlnaW5hbEJvZHkiPlNvbWUgb2JzZXJ2YXRpb25zOjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJt c28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28t Ym9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjEuIFlhcm9uIGluZGljYXRlZCB0aGF0IHRoZSBJ RVRGIHdpbGwgbGlrZWx5IHJlcXVpcmUgb25lIG1ldGhvZCBiZSBNVEkgKG1hbmRhdG9yeSB0byBp bXBsZW1lbnQpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHki PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPldo aWxlIFBVU0ggaGFzIGJldHRlciBzY2FsZSAoYmVjYXVzZSBpdCBkb2VzIG5vdCBuZWVkIEhUVFAg TG9uZyBQb2xsaW5nKSwgdGhlIFBPTEwgbWV0aG9kIGhhcyBicm9hZGVyIHV0aWxpdHkgZHVlIHRv IHRoZSBwcmVzZW5jZSBvZiByZWNlaXZlcnMgd2l0aCBmaXJld2FsbHMsIGdhdGV3YXlzIChJb1Qg ZGV2aWNlcyksIG9yIGFyZSBtb2JpbGUNCiBhcHBsaWNhdGlvbnMgdGhhdCBjYW5ub3QgaW1wbGVt ZW50IGVuZHBvaW50cyB0byByZWNlaXZlIEhUVFAgUE9TVHMuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1i b29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29r bWFyazpfTWFpbE9yaWdpbmFsQm9keSI+Mi4gJm5ic3A7SWYgUE9MTCBpcyBjaG9zZW4gYXMgdGhl IE1USSBtZXRob2QsIG1hbnkgd2lsbCBzdGlsbCBsaWtlbHkgcHJlZmVyIFBVU0ggYW5kIHNvIHRo YXQgd2lsbCBsaWtlbHkgZ2V0IGltcGxlbWVudGVkIHNvb25lciBieSBzb21lPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+My4gJm5ic3A7VGhlcmUgd2FzIGEgZ2Vu ZXJhbCBmZWVsaW5nIHRoYXQgdGhlIGRlbGl2ZXJ5IGRyYWZ0IHNob3VsZCBzdGF5IGFzIG9uZSBk cmFmdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5Bbm5hYmVs bGUgd2lsbCBwcmVzZW50IGhlciByZWNvbW1lbmRhdGlvbnMgYXQgdGhlIGZvcm1hbCBtZWV0aW5n IG9uIEZyaWRheSB3aGVyZSB3ZSBjYW4gZ2V0IGJyb2FkZXIgaW5wdXQuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1z by1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+VGhhbmtzIGV2ZXJ5b25lLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+UGhpbDxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9N YWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPk9yYWNsZSBDb3Jwb3JhdGlvbiwgSWRlbnRpdHkgQ2xvdWQgU2Vydmlj ZXMgQXJjaGl0ZWN0PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmln aW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+QGluZGVwZW5kZW50aWQ8bzpwPjwv bzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PC9zcGFuPjxh IGhyZWY9Imh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20iPjxzcGFuIHN0eWxlPSJtc28tYm9v a21hcms6X01haWxPcmlnaW5hbEJvZHkiPnd3dy5pbmRlcGVuZGVudGlkLmNvbTwvc3Bhbj48c3Bh biBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48L3NwYW4+PC9hPjxzcGFu IHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29r bWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRA b3JhY2xlLmNvbSI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+ cGhpbC5odW50QG9yYWNsZS5jb208L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFp bE9yaWdpbmFsQm9keSI+PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWls T3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFu Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFy azpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_62BA086397B748EAA313DBBEC91CF310amazoncom_-- From nobody Wed Mar 21 07:26:31 2018 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 561E712DA48 for ; Wed, 21 Mar 2018 07:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 uwG94XSnBSNZ for ; Wed, 21 Mar 2018 07:26:27 -0700 (PDT) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E14B112DA4A for ; Wed, 21 Mar 2018 07:26:25 -0700 (PDT) Received: by mail-wr0-x231.google.com with SMTP id f14so5389271wre.8 for ; Wed, 21 Mar 2018 07:26:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vImrlIkc1kd3salF0kJUiYBHCVFExoajOfD7jSzoRY4=; b=mZuFIPREiBPJYiBVWss/48F/R/t4gZsITGkbMJpKoSGO8Zfwi4y8sH29Ow/xWEgCP3 IHs0KORwiXQ2ujfl+MVW+qXrJTxsYRqms9f2M/LJx1E7TN5xJkXCgmtIemHiuoqnAD/h r4iPl53WHaD8BssiJlenGsxUQrIuX67jFLTthdg5bW+uZxtL7TcjUmWCcmg6e48KVt3X sWtwfPpUhooIyzFYhqHeUIqkOGgeJLME1y1DFExwGeIN8U5ZEX+ZoS9J/31PjEwyAYYg H1Unmdj/40qHmoibDqw6ePIzN76NCCDl74BobFm8JCGmxlOJ8tvBQVrbFyWMqk1WDbYj C7Gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vImrlIkc1kd3salF0kJUiYBHCVFExoajOfD7jSzoRY4=; b=V1UsPjxrLIkHRvb+ADqP7TIJHM4jFWF/McZPR4Yf/UCihdtFzvEvGjNoxmKtW9Xbzt t+AUJxk78BQANwnELgil8ir1wSZha83ftcrH9Rx/9MM5m5CDOelCF8G7mfLSD7rBoWIb z4y6PcmUL6wKAthoGuy68aOX5gX1JgVOtpcWoUidcaoUOXpdJ8Bel4N3pM28vZ0mqeaY dpO1ZHMW/SF6VST8VKnFKnheg802OcuIWfAf+21P8dQx/JLAbAWtPpp/tQNGgnINKJLb vCGdghV2xcysZ2qKhTNKl1g0DDczXQuBsK2kvxTqYuCcp2Mh85GCm/qiSDmamarzCikN tHVA== X-Gm-Message-State: AElRT7HrdrZshi9yrn8qWGKj86XldFUAJIW0sB+M6OjEKxwk7FE6dHL4 P5CjuvqwMpzXCJbtFv/m5fpSw8W/9UmKDlAjDYCfOQ== X-Google-Smtp-Source: AG47ELv8DlPJV82Z98AB2tb1+GQgxADwNrMP6VhtOiMZOfnOe2Wshs2ZCGJpf3EzD//RcXRCepUjDhQUn58hVwidUhE= X-Received: by 10.223.177.145 with SMTP id q17mr13763472wra.26.1521642384037; Wed, 21 Mar 2018 07:26:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.88.209 with HTTP; Wed, 21 Mar 2018 07:26:22 -0700 (PDT) In-Reply-To: <99920B12-09F2-4293-B214-F766C00CAE6E@oracle.com> References: <99920B12-09F2-4293-B214-F766C00CAE6E@oracle.com> From: Adam Dawes Date: Wed, 21 Mar 2018 07:26:22 -0700 Message-ID: To: Phil Hunt Cc: ID Events Mailing List Content-Type: multipart/alternative; boundary="f403045ebe26c6f3720567ecf9b2" Archived-At: Subject: Re: [Id-event] Summary of working session discussion X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 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 Mar 2018 14:26:30 -0000 --f403045ebe26c6f3720567ecf9b2 Content-Type: text/plain; charset="UTF-8" On Wed, Mar 21, 2018 at 6:43 AM, Phil Hunt wrote: > We held a couple of brief sessions over the last couple days. > > We talked about the issue of breaking up the delivery document, multiple > delivery methods, and optionality. > > Some observations: > > 1. Yaron indicated that the IETF will likely require one method be MTI > (mandatory to implement). > > While PUSH has better scale (because it does not need HTTP Long Polling), > the POLL method has broader utility due to the presence of receivers with > firewalls, gateways (IoT devices), or are mobile applications that cannot > implement endpoints to receive HTTP POSTs. > Receivers with this issue can mitigate the problem by implementing an intermediary routing service which will accept messages from push transmitters and buffer them until their clients poll for them. > > 2. If POLL is chosen as the MTI method, many will still likely prefer > PUSH and so that will likely get implemented sooner by some > Google has no plans to implement polling due to the fact that we cannot effectively rate limit the polling interval from potentially hundreds of thousands of clients. This represents a DDoS risk to us. This is especially true if our service were to go down for a non-trivial period of time and our universe of clients would likely all hammer us once we got online again. > > 3. There was a general feeling that the delivery draft should stay as one > draft. > Interested to hear more on the rationale for this. > > Annabelle will present her recommendations at the formal meeting on Friday > where we can get broader input. > > Thanks everyone. > > Phil > > Oracle Corporation, Identity Cloud Services Architect > @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 --f403045ebe26c6f3720567ecf9b2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Mar 21, 2018 at 6:43 AM, Phil Hunt <phil.hunt@oracle.com> wrote:
We held a couple of brief sessi= ons over the last couple days.

We talked about the issue= of breaking up the delivery document, multiple delivery methods, and optio= nality.

Some observations:

1. Yaron indicated that the IETF will likely require one method be MTI (m= andatory to implement).

While PUSH has better scal= e (because it does not need HTTP Long Polling), the POLL method has broader= utility due to the presence of receivers with firewalls, gateways (IoT dev= ices), or are mobile applications that cannot implement endpoints to receiv= e HTTP POSTs.






--
--f403045ebe26c6f3720567ecf9b2-- From nobody Wed Mar 21 08:10:55 2018 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 C8D3A1242F5 for ; Wed, 21 Mar 2018 08:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.887 X-Spam-Level: X-Spam-Status: No, score=-12.887 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, URI_HEX=1.122, URI_NOVOWEL=0.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2uIVVOlWxqSE for ; Wed, 21 Mar 2018 08:10:52 -0700 (PDT) Received: from smtp-fw-4101.amazon.com (smtp-fw-4101.amazon.com [72.21.198.25]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 900BB1275F4 for ; Wed, 21 Mar 2018 08:10:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1521645045; x=1553181045; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=yAjK58ny5//XrEMqLeO/+alyEWjSp596wdfaPsZii1s=; b=QYPHtUZtzh2m4URxbk1kdCXqkCoThOpNtHk8rp0lzKPVztWnz7AZaiGq HPXemDU1abhtsKlFW+A1IJWdkMJvLBXeOonH7LOe2ydAEGuJQ+jX5NH/A KWigfERJ6fMznfIMkbJf2ORFO0+UtIJoKpECGi8jhQ23sd6QvaKg8RVkI o=; X-IronPort-AV: E=Sophos;i="5.48,340,1517875200"; d="scan'208,217";a="712922879" Received: from iad6-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-1a-e34f1ddc.us-east-1.amazon.com) ([10.124.125.6]) by smtp-border-fw-out-4101.iad4.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Mar 2018 15:10:44 +0000 Received: from EX13MTAUWC001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan3.iad.amazon.com [10.40.159.166]) by email-inbound-relay-1a-e34f1ddc.us-east-1.amazon.com (8.14.7/8.14.7) with ESMTP id w2LFAe4C129030 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 21 Mar 2018 15:10:43 GMT Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Wed, 21 Mar 2018 15:10:41 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC004.ant.amazon.com (10.43.162.101) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Wed, 21 Mar 2018 15:10:42 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1236.000; Wed, 21 Mar 2018 15:10:42 +0000 From: "Richard Backman, Annabelle" To: Yaron Sheffer CC: "id-event@ietf.org" , Anthony Nadalin , Phil Hunt Thread-Topic: [Id-event] rescheduled working meeting Thread-Index: AQHTwJL/ZsVAofz3U0iojA/PNdrSq6PahBiAgAAB/QCAAEZTmg== Date: Wed, 21 Mar 2018 15:10:42 +0000 Message-ID: <4E6CB69F-CC75-4AEE-AEAD-A0DAACED2C67@amazon.com> References: , <5187F096-0BB0-4636-A4C0-ED50B58553AB@gmail.com> In-Reply-To: <5187F096-0BB0-4636-A4C0-ED50B58553AB@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_4E6CB69FCC754AEEAEADA0DAACED2C67amazoncom_" MIME-Version: 1.0 Precedence: Bulk Archived-At: Subject: Re: [Id-event] rescheduled working meeting X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 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 Mar 2018 15:10:55 -0000 --_000_4E6CB69FCC754AEEAEADA0DAACED2C67amazoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Since it was just the three of us today, do we still want to meet this even= ing? Sent from my iPhone On Mar 21, 2018, at 10:59 AM, Yaron Sheffer > wrote: Not for me, but please have the meeting anyway. On March 21, 2018 10:51:53 AM GMT, Anthony Nadalin > wrote: WFM From: Id-event = > On Behalf Of Phil Hunt Sent: Tuesday, March 20, 2018 2:32 PM To: ID Events Mailing List > Subject: [Id-event] rescheduled working meeting Due to some scheduling conflicts only a few could make it today. I also not= ice that the proposed time of 6PM for tomorrow is in the middle of the plen= ary. Instead of the 6PM session, I would like to suggest we get together for lun= ch at the Fiamma restaurant(in the hotel) Wednesday at noon instead of 6PM If that works, please confirm and I will cancel the 6PM session. Thanks Phil Oracle Corporation, Identity Cloud Services Architect @independentid www.independentid.com phil.hunt@oracle.com _______________________________________________ Id-event mailing list Id-event@ietf.org https://www.ietf.org/mailman/listinfo/id-event --_000_4E6CB69FCC754AEEAEADA0DAACED2C67amazoncom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Since it was just the three of us today, do we still want to meet this even= ing?

Sent from my iPhone

On Mar 21, 2018, at 10:59 AM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

Not for me, but please have the meeting anyway.

On March 21, 2018 10:51:53 AM GMT, Anthony Nadal= in <tonynad@microsoft.com&g= t; wrote:

WFM

 

From: Id-event <id-event-bounces@ietf.org> On Behalf Of Phil Hunt
Sent: Tuesday, March 20, 2018 2:32 PM
To: ID Events Mailing List <= id-event@ietf.org>
Subject: [Id-event] rescheduled working meeting

 

Due to some scheduling conflicts only a few could ma= ke it today. I also notice that the proposed time of 6PM for tomorrow is in= the middle of the plenary.

 

Instead of the 6PM session, I would like to suggest = we get together for lunch at the Fiamma restaurant(in the hotel) Wednesday = at noon instead of 6PM

 

If that works, please confirm and I will cancel the = 6PM session.

 

Thanks

 

Phil

 =

Oracle Corporation, Iden= tity Cloud Services Architect

@independentid

phil.hunt@oracle.com

 

_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://ww= w.ietf.org/mailman/listinfo/id-event
--_000_4E6CB69FCC754AEEAEADA0DAACED2C67amazoncom_-- From nobody Wed Mar 21 08:14:50 2018 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 4A98F12751F for ; Wed, 21 Mar 2018 08:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.018 X-Spam-Level: X-Spam-Status: No, score=-0.018 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z6D2xoGFbf1n for ; Wed, 21 Mar 2018 08:14:46 -0700 (PDT) Received: from aserp2130.oracle.com (aserp2130.oracle.com [141.146.126.79]) (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 22F9B1242F5 for ; Wed, 21 Mar 2018 08:14:37 -0700 (PDT) Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w2LFCkv0128794; Wed, 21 Mar 2018 15:14:34 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2017-10-26; bh=Y/QPaHr+yrWXVZbxHXDhYnB1t+fB8laB1BJtPLGJtdw=; b=sEAYa/eEpkgh7vosg4pEYCoyT0J5+IZ2FyDSsLdN9+SSIeZREBI5rXsI5cgmuy85H5nA NzSCbPoSwZhj7nxLajXk9aWmC7sNX6yrOaAh/mmVwrTUS/f8TWSmlWSKIo5s51Y+0vMK Oxc/bOArQCkAGrareiA1KwPKasIBjkI4nwKDcEqZedtlHeazDI2ITTrLAZM/Q2972CjT er7vsvZ9YpxxncXwcUuMb6qz42mmLkZpCpdvwfVWiOuNN7pqB8uxoPckm1eQRD0fR+hG 6ZyH1kV7FEfjnmtoIxHU4KZKd8fHLb9jkYC0vsvs/T5ILQHZs9SkqG7qiISjVHzn7HaM Jw== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp2130.oracle.com with ESMTP id 2gusu880yh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 21 Mar 2018 15:14:34 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w2LFEXWx018688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 21 Mar 2018 15:14:33 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w2LFEXD0019663; Wed, 21 Mar 2018 15:14:33 GMT Received: from [31.133.142.104] (/31.133.142.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 21 Mar 2018 08:14:32 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-15B156A0-BB92-4162-ADBA-C958DAAA2819 Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (15D100) In-Reply-To: <4E6CB69F-CC75-4AEE-AEAD-A0DAACED2C67@amazon.com> Date: Wed, 21 Mar 2018 15:14:28 +0000 Cc: Yaron Sheffer , "id-event@ietf.org" , Anthony Nadalin Content-Transfer-Encoding: 7bit Message-Id: <5A40BC1A-107D-440E-AD8F-708C9D4E2C51@oracle.com> References: <5187F096-0BB0-4636-A4C0-ED50B58553AB@gmail.com> <4E6CB69F-CC75-4AEE-AEAD-A0DAACED2C67@amazon.com> To: "Richard Backman, Annabelle" X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8838 signatures=668695 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803200127 Archived-At: Subject: Re: [Id-event] rescheduled working meeting X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 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 Mar 2018 15:14:48 -0000 --Apple-Mail-15B156A0-BB92-4162-ADBA-C958DAAA2819 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable No. Today=E2=80=99s lunch was because of the conflict due to the plenary thi= s evening.=20 Phil > On Mar 21, 2018, at 3:10 PM, Richard Backman, Annabelle wrote: >=20 > Since it was just the three of us today, do we still want to meet this eve= ning? >=20 > Sent from my iPhone >=20 > On Mar 21, 2018, at 10:59 AM, Yaron Sheffer wrote:= >=20 >> Not for me, but please have the meeting anyway.=20 >>=20 >>> On March 21, 2018 10:51:53 AM GMT, Anthony Nadalin wrote: >>> WFM >>> =20 >>> From: Id-event On Behalf Of Phil Hunt >>> Sent: Tuesday, March 20, 2018 2:32 PM >>> To: ID Events Mailing List >>> Subject: [Id-event] rescheduled working meeting >>> =20 >>> Due to some scheduling conflicts only a few could make it today. I also n= otice that the proposed time of 6PM for tomorrow is in the middle of the ple= nary. >>> =20 >>> Instead of the 6PM session, I would like to suggest we get together for l= unch at the Fiamma restaurant(in the hotel) Wednesday at noon instead of 6PM= >>> =20 >>> If that works, please confirm and I will cancel the 6PM session. >>> =20 >>> Thanks >>> =20 >>> Phil >>> =20 >>> Oracle Corporation, Identity Cloud Services Architect >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>> =20 >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event --Apple-Mail-15B156A0-BB92-4162-ADBA-C958DAAA2819 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable No. Today=E2=80=99s lunch was because of th= e conflict due to the plenary this evening. 

Phil

On Mar 21, 2018, at 3:10 PM, Richard Backman= , Annabelle <richanna@amazon.com> wrote:

= Since it was just the three of us today, do we still want to meet this eveni= ng?

Sent from my iPhone
Not for me, but please have the meeting anyway.

On March 21, 2018 10:51:53 AM GMT, Anthony Nadali= n <tonynad@microsoft.com>= wrote:

WFM

 

From: Id-event <id-event-bounces@ietf.org> On Behalf Of Phil Hunt
Sent: Tuesday, March 20, 2018 2:32 PM
To: ID Events Mailing List <i= d-event@ietf.org>
Subject: [Id-event] rescheduled working meeting

 

Due to some scheduling conflicts only a few could mak= e it today. I also notice that the proposed time of 6PM for tomorrow is in t= he middle of the plenary.

 

Instead of the 6PM session, I would like to suggest w= e get together for lunch at the Fiamma restaurant(in the hotel) Wednesday at= noon instead of 6PM

 

If that works, please confirm and I will cancel the 6= PM session.

 

Thanks

 

Phil

 <= /p>

Oracle Corporation, Ident= ity Cloud Services Architect

@independentid=

phil.hunt@oracle.com

 

_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://www.ietf.org/mailman/listi= nfo/id-event
= --Apple-Mail-15B156A0-BB92-4162-ADBA-C958DAAA2819-- From nobody Wed Mar 21 08:42:49 2018 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 BB3AC127241 for ; Wed, 21 Mar 2018 08:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 QCL9QHHwHrTM for ; Wed, 21 Mar 2018 08:42:39 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c: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 20501124B18 for ; Wed, 21 Mar 2018 08:42:39 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id j85so3327655vke.0 for ; Wed, 21 Mar 2018 08:42:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wUZY9tsDVQJiMAjKeBz/tUHIKUB0SYv/DEwzuH76Gzc=; b=KnxUmSDnK4g5T4eIbR9Fwr8UklBSTkjMVP9LWAGjN84FeXysG8cbcPQpgLEKDqazro 33BWlCm8gRzCEyUssw9MeXQzoEkBKwRdAyTAl7ujlRgWJ9Iru1AshtFFDWs8T9eyoNeJ D0dAU5upRDn/SzBBhfO2EZnaJ7Id0rvVRRjRU9GN6TV/TnRLknyra9PoMULq7m+QtbOc y5Af5vovGUaxA8tiWvyyYyJx92CxsKzYjn3q80GgHwGGkO1dLEgkV1EHZSOPdXmNwk2d a6Np6WDzmc7FlbbltB3+3nNNE4eON5h/DVsRxiJ5aAWBZpRIRUVgp4FeRc15yCYaOIqT Yjjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wUZY9tsDVQJiMAjKeBz/tUHIKUB0SYv/DEwzuH76Gzc=; b=LMQOLcjfPRZx/IcHbcEtSyEDKuAQxvSJbBFqaYDpn87KeKO69zf6sMuFjz9sAPPr6f UPY9AWW+ZlaBzqCdqrbKqgBtVqtsNdM2P6D1bgQkMvw9bcQb1Mkusifg1ihXdlcIUZrE jrGAEFR+KsHxYfGLLKEDkwH5wzUWNgyT70jq5jpyNl5nSxLBHRn4An/c6jCr1DkaAKYI G11HTyZVtfN5b+vSosrwT1EyWmJHk3/Zhl+XpAtnidKEEGEbhS+2P7KlFWWOUkiU5ABd BmVZzRsiYZAmsA3J8W1NQjSO+VO2o7DeI+Ng02a3KqtZcxOvv0CAI3BbUAAXXlIUObfh ECwg== X-Gm-Message-State: AElRT7EmKuRI6gawFpZrkeht4GHzQRG+JOJRhnvcFWKaB5zReZxzc6Be qczGLZDmukkSpSEbcZTe4pdtoWisBnIOGpAOcMO4fHpP X-Google-Smtp-Source: AG47ELsF28uA7c/nOY2O/N+eQPufVIYsTbqUjclK6x1jBkyzg7M6DAOl2H+MSZtrGPA2y+ZUHadNUw1sbSTuw13MiSw= X-Received: by 10.31.156.71 with SMTP id f68mr3161388vke.129.1521646957718; Wed, 21 Mar 2018 08:42:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.171.196 with HTTP; Wed, 21 Mar 2018 08:42:17 -0700 (PDT) In-Reply-To: <99920B12-09F2-4293-B214-F766C00CAE6E@oracle.com> References: <99920B12-09F2-4293-B214-F766C00CAE6E@oracle.com> From: Marius Scurtescu Date: Wed, 21 Mar 2018 08:42:17 -0700 Message-ID: To: Phil Hunt Cc: ID Events Mailing List Content-Type: multipart/alternative; boundary="001a1141bffc64268e0567ee0a26" Archived-At: Subject: Re: [Id-event] Summary of working session discussion X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 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 Mar 2018 15:42:43 -0000 --001a1141bffc64268e0567ee0a26 Content-Type: text/plain; charset="UTF-8" Thanks for the summary Phil. Comments inline... On Wed, Mar 21, 2018 at 6:43 AM, Phil Hunt wrote: > We held a couple of brief sessions over the last couple days. > > We talked about the issue of breaking up the delivery document, multiple > delivery methods, and optionality. > > Some observations: > > 1. Yaron indicated that the IETF will likely require one method be MTI > (mandatory to implement). > It would be very useful to point to other working groups and specs where this was the case. What is the mechanism by which a specific delivery method is made MTI? Which meta document specifies that? What happens if a provider is not implementing the MTI delivery method? What does that exactly mean? Just trying to understand what the process is. While PUSH has better scale (because it does not need HTTP Long Polling), > the POLL method has broader utility due to the presence of receivers with > firewalls, gateways (IoT devices), or are mobile applications that cannot > implement endpoints to receive HTTP POSTs. > To me it is very unlikely that IoT or mobile devices will use POLL (or PUSH). They will need some other delivery methods appropriate for their architecture. Having the current PUSH or POLL mandatory for these cases does not make sense to me, > 2. If POLL is chosen as the MTI method, many will still likely prefer > PUSH and so that will likely get implemented sooner by some > Many will simply not implement POLL if what they need is PUSH, and vice versa. Again, I don't see how the working group can pick any delivery method and make it MTI. And MTI in what context? Can we escalate this issue within IETF to get guidance? > 3. There was a general feeling that the delivery draft should stay as one > draft. > I don't see how that is helping, but if implementors can chose either PUSH or POLL from the current draft then that's fine. But in that case splitting should also be acceptable. > Annabelle will present her recommendations at the formal meeting on Friday > where we can get broader input. > > Thanks everyone. > > Phil > > Oracle Corporation, Identity Cloud Services Architect > @independentid > www.independentid.com > phil.hunt@oracle.com > > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > > --001a1141bffc64268e0567ee0a26 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the summary Phil.

Comments i= nline...

On = Wed, Mar 21, 2018 at 6:43 AM, Phil Hunt <phil.hunt@oracle.com> wrote:
We held a couple of brief sessions over the last couple days.
We talked about the issue of breaking up the delivery document,= multiple delivery methods, and optionality.

Some = observations:

1. Yaron indicated that the IETF wil= l likely require one method be MTI (mandatory to implement).

It would be very useful to point to other wor= king groups and specs where this was the case.

Wha= t is the mechanism by which a specific delivery method is made MTI? Which m= eta document specifies that?

What happens if a pro= vider is not implementing the MTI delivery method? What does that exactly m= ean?

Just trying to understand what the process is= .


While PUSH h= as better scale (because it does not need HTTP Long Polling), the POLL meth= od has broader utility due to the presence of receivers with firewalls, gat= eways (IoT devices), or are mobile applications that cannot implement endpo= ints to receive HTTP POSTs.

To me it is very unlikely that IoT or mobile devices will use POLL (or PUS= H). They will need some other delivery methods appropriate for their archit= ecture. Having the current PUSH or POLL mandatory for these cases does not = make sense to me,

=
2.=C2=A0 If POLL is chosen as the MTI method, many will stil= l likely prefer PUSH and so that will likely get implemented sooner by some=

Many will simply not implement= POLL if what they need is PUSH, and vice versa. Again, I don't see how= the working group can pick any delivery method and make it MTI. And MTI in= what context?

Can we escalate this issue within I= ETF to get guidance?



3.=C2=A0 There was a general feeling that the deliv= ery draft should stay as one draft.

=
I don't see how that is helping, but if implementors can chose eit= her PUSH or POLL from the current draft then that's fine. But in that c= ase splitting should also be acceptable.



Annabelle will present her recomm= endations at the formal meeting on Friday where we can get broader input.

Thanks everyone.

Phi= l

Oracle Corporation, Identity Cloud Services Arch= itect
@independentid
phil.hunt@oracle.com
<= /div>


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


--001a1141bffc64268e0567ee0a26-- From nobody Wed Mar 21 09:05:08 2018 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 4291412704A for ; Wed, 21 Mar 2018 09:05:07 -0700 (PDT) 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4j7OxaAfiSy for ; Wed, 21 Mar 2018 09:05:04 -0700 (PDT) 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 535F8126D45 for ; Wed, 21 Mar 2018 09:05:04 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id t7so10722216wmh.5 for ; Wed, 21 Mar 2018 09:05:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=4nLIF4OQqgxyAZ+L+k5BWllnbvG18o/vYy2J5AXCmko=; b=o1N+yZBqsrJ9MN0kYSslrrgLdbTfHeYxsha62XRnwI/6PW3F4Tn9TstfIjYmUIfWnd j9OS5mGIgBICkc2RMLZpISe9lXOoEe/Xt8bU/cdhpcCYhqRLAWxpEExoxq4dg64c7e/I 2bBm4fI67mfHjbshB4uoYgK9PAoczxpogptHUVqXRN4wLUouPP7aiNLAXjO17UJc2AaD 64uwpTx97OTQ3qVQmHWxlgom0BedZv77w5oraTt/KZx6/K/1t1AdrV2Am7YdNZDJFVu9 qBXE5Al6aNhb63/Rqa6xQ3HWdJWt2rvQ2rFX0fVfPWd/f2EDJ11kM6pMSlmRFz/4ARA/ M1EQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=4nLIF4OQqgxyAZ+L+k5BWllnbvG18o/vYy2J5AXCmko=; b=S4NBxVN/h+lzdYUs35+M5NGevqsTmmrQu4TlkfqXc4ohCk66GfzBekp3ChzthTR80n ed3c2gaU/0IZaLlLYhniqQOFyxHl723W4XPhvS1vjbwz6W9QDXjtiXkLO8vOpYvmmncd WVl3xgwN06/3hXDA78Mnc23eznCzpQvr4qyPS0Y2h41zX9DhzEtcIxkRq/6kF6DAIdoA 8htOVonIDtt23dRtxGokOfAcw6kj908qeFa1HF5yMzPo15urzsGUoc/5eODqDjX0eQd1 /0SOJTe+gD/xlMTHWhYcGbQTlgdU4o6003iNvwr9vHeUtVhYsFQraqm+NPj3q4uYR9BI eyPg== X-Gm-Message-State: AElRT7F36G7tIJ5/OIKI95ECCZsQDgZQDekUza80Qt3TzA/de1p7Mjnz WHnpvQq1rHNqSXmSyK3jcQYyvd6C X-Google-Smtp-Source: AG47ELu/vYs8+vO7adj7jL7G+q06Oii/clqyfmK3RTwa3UNzNkJ917dJ3cG+Y/OtQIRUlYmCcWRLFw== X-Received: by 10.28.55.4 with SMTP id e4mr2911500wma.7.1521648302366; Wed, 21 Mar 2018 09:05:02 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:11fb:f307:5bab:e324? ([2001:67c:370:128:11fb:f307:5bab:e324]) by smtp.gmail.com with ESMTPSA id n23sm4433631wra.14.2018.03.21.09.05.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Mar 2018 09:05:01 -0700 (PDT) To: Marius Scurtescu , Phil Hunt Cc: ID Events Mailing List References: <99920B12-09F2-4293-B214-F766C00CAE6E@oracle.com> From: Yaron Sheffer Message-ID: <221f7700-d279-1156-1b56-d222b111bce3@gmail.com> Date: Wed, 21 Mar 2018 16:05:00 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Id-event] Summary of working session discussion X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 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 Mar 2018 16:05:07 -0000 Hi Marius, The decision about whether we need to have an MTI protocol and which one it should be is up to the WG consensus, like everything else. But with my WG chair hat on, it is my strong conviction that we need to have one MTI method to encourage interoperability and reduce fragmentation. This is based on my IETF experience, and not on any meta-document as far as I can tell. Just think of implementers that are not part of the WG, and just read the RFCs two years from now. They need to have a clear message which method will allow them the best (though maybe not perfect) interoperability. Also, I personally do not have a preference which of the methods becomes MTI. It is common at the IETF to say that "there is no IETF police", in other words if you choose to not implement an MTI protocol/feature, nobody is going to come after you and punish you. It is between you and your market. I fully expect some of the WG participants to only implement the non-MTI method. We can absolutely ask the incoming AD for more guidance in this area. I think keeping the two methods within the same document will speed up and simplify the process, compared to running two docs in parallel. They do have enough commonalities. Thanks, Yaron On 21/03/18 15:42, Marius Scurtescu wrote: > Thanks for the summary Phil. > > Comments inline... > > On Wed, Mar 21, 2018 at 6:43 AM, Phil Hunt > wrote: > > We held a couple of brief sessions over the last couple days. > > We talked about the issue of breaking up the delivery document, > multiple delivery methods, and optionality. > > Some observations: > > 1. Yaron indicated that the IETF will likely require one method be > MTI (mandatory to implement). > > > It would be very useful to point to other working groups and specs where > this was the case. > > What is the mechanism by which a specific delivery method is made MTI? > Which meta document specifies that? > > What happens if a provider is not implementing the MTI delivery method? > What does that exactly mean? > > Just trying to understand what the process is.. > > > While PUSH has better scale (because it does not need HTTP Long > Polling), the POLL method has broader utility due to the presence of > receivers with firewalls, gateways (IoT devices), or are mobile > applications that cannot implement endpoints to receive HTTP POSTs. > > > To me it is very unlikely that IoT or mobile devices will use POLL (or > PUSH). They will need some other delivery methods appropriate for their > architecture. Having the current PUSH or POLL mandatory for these cases > does not make sense to me, > > > 2.  If POLL is chosen as the MTI method, many will still likely > prefer PUSH and so that will likely get implemented sooner by some > > > Many will simply not implement POLL if what they need is PUSH, and vice > versa. Again, I don't see how the working group can pick any delivery > method and make it MTI. And MTI in what context? > > Can we escalate this issue within IETF to get guidance? > > > > 3.  There was a general feeling that the delivery draft should stay > as one draft. > > > I don't see how that is helping, but if implementors can chose either > PUSH or POLL from the current draft then that's fine. But in that case > splitting should also be acceptable. > > > > Annabelle will present her recommendations at the formal meeting on > Friday where we can get broader input. > > Thanks everyone. > > Phil > > Oracle Corporation, Identity Cloud Services Architect > @independentid > www.independentid.com > phil.hunt@oracle.com > > > _______________________________________________ > 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 Wed Mar 21 20:49:28 2018 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 1E35D12D7EC for ; Wed, 21 Mar 2018 20:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 kBzU4LoqqOOa for ; Wed, 21 Mar 2018 20:49:24 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7611212D887 for ; Wed, 21 Mar 2018 20:49:24 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id z190so4434553vkg.1 for ; Wed, 21 Mar 2018 20:49:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=3YN9pLNV1ZmnB8OdKDCt3cSlReHbeAQ7b+4Kh4sPpG8=; b=N44+u7aAT3Ov0ZsgUHhpNwnSM7RBzPwCDgzAxcR5E8WJ+0yXY1W3Vh3v8+GGJg6tjY rth/8Zei+sv+7IeegU3pA/xLt5QQJBBlcXB+hLooQW2ENoTGStHgBqg9CcpTxkMe2T78 xhNAgDx6enRaO+ALg1G6jnPVfST20tCxxW3tig2UqohZkM7SoIsDxWAexBfStwSwIHVF LsxCopfkB+xlcZZC5Uf+Dp1h9r1nr7pxHCWei1RmntWakoPtahb29/CWqKWQnJb10rc7 rymaaJ6lA6m1dIvI/W/3/yWYuMKDF3ciwuPfr77jL84Iwj6a/rC+EQ5bCOd4u5x4ze5e zXEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=3YN9pLNV1ZmnB8OdKDCt3cSlReHbeAQ7b+4Kh4sPpG8=; b=KN3c4LGDbzbt4IL+e0KznpNyZGL/qL9XRujr+TcYw1HYUH4vmgLXeStd1N4Ks72Y7o eli9DTjE9NdD3l5H0/mKuaeMGsgcbIi/2ZXRetd1xXHKsQBQogPHHEWHlxEOxhn4hpCd ag9pKJcChKy/HwzNPdjJXJ2K0L6vOrH/VxyXisBRUiYNMchIPTFJUyECVFM+UJiZRcFM eUdyRAF4wEP6s2F82vrQ+t2VHsJSzUSyGZ+LpgsGAH+fwz7+E/TmU9Gsjs0nNqDNAScN 2Lv+9fwu/BRuGdUqS9lYcubikocEKY+aUaHHu6TI5P9ZhMCtpRWFnYHtr42STtHkEv9t arYQ== X-Gm-Message-State: AElRT7Hl3Pv1h97Ldp+D4QSV6jJChOSgi2cT3M8i61bDI3cI+0UTYjBB WexK6AoHjKxPRykD37WqDN0t1JpRvlInU1AhTnQjA6U4m5s= X-Google-Smtp-Source: AG47ELvRrdq0weXXqKzyYtBqjV5s21TAofVbCPDUKqGmIbzuAAkN2re+Pcz/y4Evy4quSZWR+ie2AJXjODLCDb4EQ5U= X-Received: by 10.31.9.10 with SMTP id 10mr7016577vkj.83.1521690562943; Wed, 21 Mar 2018 20:49:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.171.196 with HTTP; Wed, 21 Mar 2018 20:49:02 -0700 (PDT) From: Marius Scurtescu Date: Wed, 21 Mar 2018 20:49:02 -0700 Message-ID: To: ID Events Mailing List Content-Type: multipart/alternative; boundary="001a1145051276fb150567f831d3" Archived-At: Subject: [Id-event] "exp" claim in draft-ietf-secevent-token-07 X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 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 Mar 2018 03:49:26 -0000 --001a1145051276fb150567f831d3 Content-Type: text/plain; charset="UTF-8" Section 2.2 for "exp" states: "this claim is the time after which the JWT MUST NOT be accepted for processing. In the context of a SET however, this notion does not typically apply, since a SET represents something that has already occurred and is historical in nature. Therefore, its use is NOT RECOMMENDED." Similarly, section 4.5 makes recommendations against "exp". At IETF 100 in Singapore we briefly talked about this and the following problem came up: without "exp" how long should a receiver cache "jti" values to prevent double submissions (and replay attacks)? Today the same problem was raised as implementation feedback. It seems that "exp" should rather be required. Thoughts? What happens to section 4.5 if "exp" is required? Also, a required (or recommended) "exp" leads to implementation challenges when it comes to delivery. A transmitter that is retrying to deliver unconfirmed SETs, will have to probably re-mint them on each delivery attempt, as opposed to simply cache a minted SET and keep retrying with that. Or the transmitter will have to set an expiration period longer than the retry period, but long expiration periods put bigger loads on receivers (larger cache). Any chance this can be discussed on Friday? Marius --001a1145051276fb150567f831d3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Section 2.2 for "exp" states:

"this claim is the time after which the JWT MUST NOT be accepted= for processing.=C2=A0 In the context of a SET however, this notion does no= t typically apply, since a SET represents something that has already occurr= ed and is historical in nature. Therefore, its use is NOT RECOMMENDED."= ;

Similarly, section 4.5 makes recommendations aga= inst "exp".

At IETF 100 in Singapore we = briefly talked about this and the following problem came up: without "= exp" how long should a receiver cache "jti" values to preven= t double submissions (and replay attacks)?

Today t= he same problem was raised as implementation feedback.

=
It seems that "exp" should rather be required. Thoughts?

What happens to section 4.5 if "exp" is req= uired?

Also, a required (or recommended) "exp= " leads to implementation challenges when it comes to delivery. A tran= smitter that is retrying to deliver unconfirmed SETs, will have to probably= re-mint them on each delivery attempt, as opposed to simply cache a minted= SET and keep retrying with that. Or the transmitter will have to set an ex= piration period longer than the retry period, but long expiration periods p= ut bigger loads on receivers (larger cache).

Any c= hance this can be discussed on Friday?

Marius
<= /div>
--001a1145051276fb150567f831d3-- From nobody Thu Mar 22 03:04:40 2018 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 5BEB51205D3 for ; Thu, 22 Mar 2018 03:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 nn5tFP8rSNFb for ; Thu, 22 Mar 2018 03:04:32 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B9B8127873 for ; Thu, 22 Mar 2018 03:04:32 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id z190so4859671vkg.1 for ; Thu, 22 Mar 2018 03:04:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eZ231u0AiBKowdzxP90DdQ8A7EJjZRwsihkknnB8xd8=; b=LuublAMo/vGSEzKa//BHosMiBTpX/8UZy48BjeebW/eZNwzLwcG0vvnmT720hqXK36 no/rGbfzIXzLv2LK9XaqkHk+S5j5UjnicFTZPM6/hBp8uSVVhvM1db+js6hJ4WD310Kk 0fldOiRxWL5bAaCtVN8qP/UbQ8XOoTqGkA9INo6QS9E0X1cXuq+4NUxZmlOjpWZAQdOn diK588F0idICrdRGNcL8VEfoEkG/aChXprzKb/xmiJzQueZVX+ttwEJmZzj2U2eGyKUN 2GOVHzHaw31baCNTHptDmTeAHs6IwnoxPtfpEImZkV0BR+6ZoQZAfBTr5SPfcehDm6IA Efnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eZ231u0AiBKowdzxP90DdQ8A7EJjZRwsihkknnB8xd8=; b=Z57xFuVpwzB4iThiHLStVLof4imI0sJkklCEtweaAvzgpnhBht4+izbSLbvCj1bai8 A18WQnuoxd9SyhmwSvgzpdktZwDGFvaze90e8YWCBiKKBlC04b/rxObp7Q0Nccityqw6 RoWcOLDILH3+qmzFAAFBOZf2TsFYL4hp57AP9jMgSr6DnWoGVG9+PwcZGFA0YsvvhrJG jgmMdAHbYxYkp512jr1iRnFae3vmnVK8mgXfuWDxXoMgwgcwznYNOWF3hJJKJit1T6AQ qFNdK/uAR6MJr+YT22LuwXSEu/PbTwF11z69VoO48Otf6mciLOSJDTCXwzOB8YJb322+ aeow== X-Gm-Message-State: AElRT7GNkLjpybRvESv6+kObftL7Eez+hUjtb7nOVffuwj2GIdAeYd1Z RzZjb0YRR+3Qw/SUEzoqNFBOGde6jQVhzpUeQGnvpShl X-Google-Smtp-Source: AG47ELum/pUvzWIXKnqZBJsr8kILX6etEbA0L3D8Bh6FVZAD0sVTUsbp0fkQu+FmCnRE2dHw+imvzQyKP8148hUGqQA= X-Received: by 10.31.207.198 with SMTP id f189mr16138287vkg.75.1521713070663; Thu, 22 Mar 2018 03:04:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.171.196 with HTTP; Thu, 22 Mar 2018 03:04:10 -0700 (PDT) In-Reply-To: <221f7700-d279-1156-1b56-d222b111bce3@gmail.com> References: <99920B12-09F2-4293-B214-F766C00CAE6E@oracle.com> <221f7700-d279-1156-1b56-d222b111bce3@gmail.com> From: Marius Scurtescu Date: Thu, 22 Mar 2018 03:04:10 -0700 Message-ID: To: Yaron Sheffer Cc: Phil Hunt , ID Events Mailing List Content-Type: multipart/alternative; boundary="001a114e5112078ece0567fd6f65" Archived-At: Subject: Re: [Id-event] Summary of working session discussion X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 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 Mar 2018 10:04:35 -0000 --001a114e5112078ece0567fd6f65 Content-Type: text/plain; charset="UTF-8" Hi Yaron, I don't think anyone can argue with the desire for strong interop and less complexity. Wearing our implementor hats, what delivery method would optimally cover all use cases? Do we want a delivery method that in theory can cover most use cases, but it is suboptimal for many of them? How would a mobile or IoT device use the current PUSH or POLL methods? We are not talking about alternative delivery methods for the same use case, but different methods for each separate use case. I totally agree that as a workinggroup we should support one method per use case, for example one method for HTTP receivers sitting behind firewalls. I am using "use case" in a generic way, more like "profile". Why declare one method as MTI when it is clear that it will not work for many use cases and that implementors for those use cases will be forced to ignore the MTI? Regarding the current delivery draft, why do you think that keeping the two methods together is beneficial? The overlap between the two is minimal. Here are the reasons why I think the draft should be split: 1. The two methods have different maturity levels. The PUSH method is already implemented and more implementation will come online soon. The POLL method has no implementation yet, as far as I know. By keeping them together we hold back one and put pressure to rush the other. That's lose-lose. 2. With two methods in one drafts it is very ambiguous what is MTI. With two separate drafts each implemetor can chose what works for their use cases. Interop will work out based on use cases, I don't think we have to force it. The clear message for implementors two years from now would be a clear description for each method as to what use cases it is applicable to. No confusion at all, if you are behind a firewall then POLL is your only option. If you are delivering to IoT then whatever method works for that use case (we don't have one yet). I asked about a meta-document from a practical point of view. How/where will the MTI delivery method be defined? Same with IETF police, maybe you misunderstood. I am not worried about implementors disregarding recommendations. Since the unit for specifications are RFCs, how can some RFC be declared as MTI? In what context? Again, from a practical editorial point of view. Guidance would be very useful IMO. Thanks, Marius Marius On Wed, Mar 21, 2018 at 9:05 AM, Yaron Sheffer wrote: > Hi Marius, > > The decision about whether we need to have an MTI protocol and which one > it should be is up to the WG consensus, like everything else. But with my > WG chair hat on, it is my strong conviction that we need to have one MTI > method to encourage interoperability and reduce fragmentation. This is > based on my IETF experience, and not on any meta-document as far as I can > tell. Just think of implementers that are not part of the WG, and just read > the RFCs two years from now. They need to have a clear message which method > will allow them the best (though maybe not perfect) interoperability. Also, > I personally do not have a preference which of the methods becomes MTI. > > It is common at the IETF to say that "there is no IETF police", in other > words if you choose to not implement an MTI protocol/feature, nobody is > going to come after you and punish you. It is between you and your market. > I fully expect some of the WG participants to only implement the non-MTI > method. > > We can absolutely ask the incoming AD for more guidance in this area. > > I think keeping the two methods within the same document will speed up and > simplify the process, compared to running two docs in parallel. They do > have enough commonalities. > > Thanks, > Yaron > > On 21/03/18 15:42, Marius Scurtescu wrote: > >> Thanks for the summary Phil. >> >> Comments inline... >> >> On Wed, Mar 21, 2018 at 6:43 AM, Phil Hunt > phil.hunt@oracle.com>> wrote: >> >> We held a couple of brief sessions over the last couple days. >> >> We talked about the issue of breaking up the delivery document, >> multiple delivery methods, and optionality. >> >> Some observations: >> >> 1. Yaron indicated that the IETF will likely require one method be >> MTI (mandatory to implement). >> >> >> It would be very useful to point to other working groups and specs where >> this was the case. >> >> What is the mechanism by which a specific delivery method is made MTI? >> Which meta document specifies that? >> >> What happens if a provider is not implementing the MTI delivery method? >> What does that exactly mean? >> >> Just trying to understand what the process is.. >> >> >> While PUSH has better scale (because it does not need HTTP Long >> Polling), the POLL method has broader utility due to the presence of >> receivers with firewalls, gateways (IoT devices), or are mobile >> applications that cannot implement endpoints to receive HTTP POSTs. >> >> >> To me it is very unlikely that IoT or mobile devices will use POLL (or >> PUSH). They will need some other delivery methods appropriate for their >> architecture. Having the current PUSH or POLL mandatory for these cases >> does not make sense to me, >> >> >> 2. If POLL is chosen as the MTI method, many will still likely >> prefer PUSH and so that will likely get implemented sooner by some >> >> >> Many will simply not implement POLL if what they need is PUSH, and vice >> versa. Again, I don't see how the working group can pick any delivery >> method and make it MTI. And MTI in what context? >> >> Can we escalate this issue within IETF to get guidance? >> >> >> >> 3. There was a general feeling that the delivery draft should stay >> as one draft. >> >> >> I don't see how that is helping, but if implementors can chose either >> PUSH or POLL from the current draft then that's fine. But in that case >> splitting should also be acceptable. >> >> >> >> Annabelle will present her recommendations at the formal meeting on >> Friday where we can get broader input. >> >> Thanks everyone. >> >> Phil >> >> Oracle Corporation, Identity Cloud Services Architect >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> >> >> _______________________________________________ >> 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 >> >> --001a114e5112078ece0567fd6f65 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Yaron,

I don't think anyone can = argue with the desire for strong interop and less complexity.
Wearing our implementor hats, what delivery method would optima= lly cover all use cases? Do we want a delivery method that in theory can co= ver most use cases, but it is suboptimal for many of them? How would a mobi= le or IoT device use the current PUSH or POLL methods?

=
We are not talking about alternative delivery methods for the same use= case, but different methods for each separate use case. I totally agree th= at as a workinggroup we should support one method per use case, for example= one method for HTTP receivers sitting behind firewalls. I am using "u= se case" in a generic way, more like "profile".
Why declare one method as MTI when it is clear that it will no= t work for many use cases and that implementors for those use cases will be= forced to ignore the MTI?

Regarding the current d= elivery draft, why do you think that keeping the two methods together is be= neficial? The overlap between the two is minimal. Here are the reasons why = I think the draft should be split:

1. The two meth= ods have different maturity levels. The PUSH method is already implemented = and more implementation will come online soon. The POLL method has no imple= mentation yet, as far as I know. By keeping them together we hold back one = and put pressure to rush the other. That's lose-lose.

2. With two methods in one drafts it is very ambiguous what is MTI.= With two separate drafts each implemetor can chose what works for their us= e cases. Interop will work out based on use cases, I don't think we hav= e to force it.

The clear message for implementors = two years from now would be a clear description for each method as to what = use cases it is applicable to. No confusion at all, if you are behind a fir= ewall then POLL is your only option. If you are delivering to IoT then what= ever method works for that use case (we don't have one yet).
=
I asked about a meta-document from a practical point of view= . How/where will the MTI delivery method be defined? Same with IETF police,= maybe you misunderstood. I am not worried about implementors disregarding = recommendations. Since the unit for specifications are RFCs, how can some R= FC be declared as MTI? In what context? Again, from a practical editorial p= oint of view.

Guidance would be very useful IMO.

Thanks,
Marius

=

Marius

On Wed, Mar 21, 2018 at 9:05 AM, Yaron Sheff= er <yaronf.ietf@gmail.com> wrote:
Hi Marius,

The decision about whether we need to have an MTI protocol and which one it= should be is up to the WG consensus, like everything else. But with my WG = chair hat on, it is my strong conviction that we need to have one MTI metho= d to encourage interoperability and reduce fragmentation. This is based on = my IETF experience, and not on any meta-document as far as I can tell. Just= think of implementers that are not part of the WG, and just read the RFCs = two years from now. They need to have a clear message which method will all= ow them the best (though maybe not perfect) interoperability. Also, I perso= nally do not have a preference which of the methods becomes MTI.

It is common at the IETF to say that "there is no IETF police", i= n other words if you choose to not implement an MTI protocol/feature, nobod= y is going to come after you and punish you. It is between you and your mar= ket. I fully expect some of the WG participants to only implement the non-M= TI method.

We can absolutely ask the incoming AD for more guidance in this area.

I think keeping the two methods within the same document will speed up and = simplify the process, compared to running two docs in parallel. They do hav= e enough commonalities.

Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Yaron

On 21/03/18 15:42, Marius Scurtescu wrote:
Thanks for the summary Phil.

Comments inline...

 On Wed, Mar 21, 2018 at 6:43 AM, Phil Hunt <phil.hunt@oracle.com <mailto:phil.hunt@oracle.com= >> wrote:

=C2=A0 =C2=A0 We held a couple of brief sessions over the last couple days.=

=C2=A0 =C2=A0 We talked about the issue of breaking up the delivery documen= t,
=C2=A0 =C2=A0 multiple delivery methods, and optionality.

=C2=A0 =C2=A0 Some observations:

=C2=A0 =C2=A0 1. Yaron indicated that the IETF will likely require one meth= od be
=C2=A0 =C2=A0 MTI (mandatory to implement).


It would be very useful to point to other working groups and specs where th= is was the case.

What is the mechanism by which a specific delivery method is made MTI? Whic= h meta document specifies that?

What happens if a provider is not implementing the MTI delivery method? Wha= t does that exactly mean?

 Just trying to understand what the process is..


=C2=A0 =C2=A0 While PUSH has better scale (because it does not need HTTP Lo= ng
=C2=A0 =C2=A0 Polling), the POLL method has broader utility due to the pres= ence of
=C2=A0 =C2=A0 receivers with firewalls, gateways (IoT devices), or are mobi= le
=C2=A0 =C2=A0 applications that cannot implement endpoints to receive HTTP = POSTs.


To me it is very unlikely that IoT or mobile devices will use POLL (or PUSH= ). They will need some other delivery methods appropriate for their archite= cture. Having the current PUSH or POLL mandatory for these cases does not m= ake sense to me,


=C2=A0 =C2=A0 2.=C2=A0 If POLL is chosen as the MTI method, many will still= likely
=C2=A0 =C2=A0 prefer PUSH and so that will likely get implemented sooner by= some


Many will simply not implement POLL if what they need is PUSH, and vice ver= sa. Again, I don't see how the working group can pick any delivery meth= od and make it MTI. And MTI in what context?

Can we escalate this issue within IETF to get guidance?



=C2=A0 =C2=A0 3.=C2=A0 There was a general feeling that the delivery draft = should stay
=C2=A0 =C2=A0 as one draft.


I don't see how that is helping, but if implementors can chose either P= USH or POLL from the current draft then that's fine. But in that case s= plitting should also be acceptable.



=C2=A0 =C2=A0 Annabelle will present her recommendations at the formal meet= ing on
=C2=A0 =C2=A0 Friday where we can get broader input.

=C2=A0 =C2=A0 Thanks everyone.

=C2=A0 =C2=A0 Phil

=C2=A0 =C2=A0 Oracle Corporation, Identity Cloud Services Architect
=C2=A0 =C2=A0 @independentid
 =C2=A0 =C2=A0 www.independentid.com <http://www.independentid.= com>
=C2=A0 =C2=A0 phi= l.hunt@oracle.com <mailto:phil.hunt@oracle.com>


=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 Id-event mailing list
=C2=A0 =C2=A0 Id-eve= nt@ietf.org <mailto:Id-event@ietf.org>
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listin= fo/id-event
=C2=A0 =C2=A0 <https://www.ietf.org/mailman/li= stinfo/id-event>




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


--001a114e5112078ece0567fd6f65-- From nobody Thu Mar 22 03:29:40 2018 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 6D06F120726 for ; Thu, 22 Mar 2018 03:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 xiaE0L8I32-q for ; Thu, 22 Mar 2018 03:29:36 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0139.outbound.protection.outlook.com [104.47.32.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 571891201F2 for ; Thu, 22 Mar 2018 03:29:36 -0700 (PDT) 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=rNO36kSKPvuutOhkInUumWmFfE9Vp+fxjMbp1uQovz0=; b=aLPO8QMwbVbP/Gdz4cx6GESfOqhVVby5Qy1pK/74XDYYYxsiiJ09GxbjKtkNbMYI2m27cDmk/gDqE7eBmz+xZoforaTOUeTmJ8drPSWQtb59n0Hv0GAD7JcSGMn+oY61GUID86npKToJfkTAjMgmk6IEsufOeJpDNpBwTmD/xyo= Received: from DM5PR00MB0296.namprd00.prod.outlook.com (52.132.128.37) by DM5PR00MB0310.namprd00.prod.outlook.com (52.132.128.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.652.0; Thu, 22 Mar 2018 10:29:29 +0000 Received: from DM5PR00MB0296.namprd00.prod.outlook.com ([fe80::4505:9110:25d:a5e0]) by DM5PR00MB0296.namprd00.prod.outlook.com ([fe80::4505:9110:25d:a5e0%2]) with mapi id 15.20.0652.000; Thu, 22 Mar 2018 10:29:29 +0000 From: Mike Jones To: Marius Scurtescu , ID Events Mailing List Thread-Topic: [Id-event] "exp" claim in draft-ietf-secevent-token-07 Thread-Index: AQHTwZDMBIfMIC+jA0SEwbCxRulG6aPcCqZA Date: Thu, 22 Mar 2018 10:29:29 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.156.108] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR00MB0310; 7:hlF3GXnOKFG6t+0ze3b24IDUPEfcSrOPD7lbWGmC0TTL0Yhd9oBGU1LvV9LVMWKsrRvQT0cvJpWZxVrGi9iLnC6zDHBZHeOELTZRh04quXw22wYZ+auJwfwA21TJ8BdDIiwjsb150jSRgVNQYBXA23bdw+z/bvUni67MaRVJqwP0uQwJLDITFNlAqEh0VHPRIIxm4vVZ4GtiGv+ttIlsxyywLkgHcfxAKRnPVr0OkA+v1PrvwmCR6qtY5zBUTrkF; 20:qtrHQeYy+/rlal4tbPOW56eoMMqRKoGu2wnduwHfOl24w/dSl61Rjl3Z7JKXXx+HANjNTrO45DQk0aQu8LOWpQPMzZorjjerFCbbxNWCcxDYgY+CPhV8JSfUyhX4bWUJ3jlv2NABLxAQFppjOwNlbFJeozb6iUHaoVusm3wZquM= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 3f83b4c6-63c6-4092-d266-08d58fdfcb55 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:DM5PR00MB0310; x-ms-traffictypediagnostic: DM5PR00MB0310: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(8121501046)(5005006)(3231221)(944501327)(52105095)(10201501046)(93006095)(93001095)(3002001)(6055026)(61426038)(61427038)(6041310)(20161123562045)(20161123558120)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:DM5PR00MB0310; BCL:0; PCL:0; RULEID:; SRVR:DM5PR00MB0310; x-forefront-prvs: 0619D53754 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(396003)(39380400002)(39860400002)(366004)(346002)(189003)(199004)(446003)(6246003)(102836004)(6346003)(26005)(66066001)(14454004)(86612001)(25786009)(186003)(8990500004)(81166006)(81156014)(8676002)(2900100001)(105586002)(8936002)(10290500003)(10090500001)(478600001)(74316002)(72206003)(9686003)(7736002)(2906002)(3846002)(106356001)(5660300001)(790700001)(6116002)(316002)(3660700001)(7696005)(22452003)(76176011)(2950100002)(110136005)(6506007)(229853002)(3280700002)(59450400001)(54896002)(86362001)(6306002)(53546011)(33656002)(68736007)(5250100002)(53936002)(55016002)(6436002)(99286004)(97736004); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR00MB0310; H:DM5PR00MB0296.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-message-info: UofbOImrI91+JvpOVqwfgxjZKtH64mEnD3RTC56m5zfOiYKpp+jcmAok28YHj5PtT9WCJmr9Hift3N2EbWrdcmb/h0Hjva5g1KBWKO9+AZn+KIll0mrrWqNO0iLdJM/UDk0Wtxod/j8uIq3QYDQ8kroG92cCZ+RSljbrAU1NQYkfNg5YxfUP7HrCMYeCt/ggI7s4SfiY6xhxgWwCLz5uGbtv7xKp8pQh2P91lPSg5Ko802TaC2Ifjtr0vPNcy5t88C3u7rc4O5MdG1f1ik6EwxqUBmdI7COcWXXwBFuDuCW7w3fa2+iW4steri/KchGO/8t0S6ImJDXqvFtKmEm6vA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR00MB0296295C7D3C2E311C4F4941F5A90DM5PR00MB0296namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3f83b4c6-63c6-4092-d266-08d58fdfcb55 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2018 10:29:29.2790 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR00MB0310 Archived-At: Subject: Re: [Id-event] "exp" claim in draft-ietf-secevent-token-07 X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 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 Mar 2018 10:29:38 -0000 --_000_DM5PR00MB0296295C7D3C2E311C4F4941F5A90DM5PR00MB0296namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VG8gbWUsIGl0IHNlZW1zIHRoYXQgdHJ5aW5nIHRvIG1hbmRhdGUgdGhhdCBhbiBleHBpcmF0aW9u IHRpbWUgYmUgc2VudCB3aGVuIHRoZXJlIGlzIG5vIG5hdHVyYWwgZXhwaXJhdGlvbiB0aW1lIGZv ciB0aGUgaW5mb3JtYXRpb24gaXMgb2RkIGF0IGJlc3QsIGFuZCBjb3VudGVycHJvZHVjdGl2ZSBh dCB3b3JzdC4gIFdlIHNob3VsZCBub3QgZW5jb3VyYWdlIGRlcGxveWVycyB0byBoYXZlIHRvIOKA nGludmVudOKAnSBhcmJpdHJhcmlseSBjaG9zZW4gdmFsdWVzIGFuZCBpbmNsdWRlIHRoZW0gYXMg Y2xhaW1zIHRvIHNhdGlzZnkgYSBNVVNUIHRoYXQgc2hvdWxkbuKAmXQgaGF2ZSBiZWVuIHRoZXJl Lg0KDQpDYWNoaW5nIGRlY2lzaW9ucyBhcmUgaGlnaGx5IGRlcGxveW1lbnQgc3BlY2lmaWMuICBU aGV5IGNvdWxkLCBmb3IgaW5zdGFuY2UsIGJlIGJhc2VkIG9uIGEgZGVwbG95bWVudC1zcGVjaWZp ZWQgZGVsdGEgZnJvbSB0aGUg4oCcaWF04oCdIChpc3N1ZWQgYXQpIHZhbHVlIGFuZCBub3QgdXNl IOKAnGV4cOKAnSBhdCBhbGwuDQoNCldpdGggcmVzcGVjdCB0byDigJxleHDigJ0sIEkgdGhpbmsg dGhlIHNwZWMgYWxyZWFkeSBoYXMgaXQgcmlnaHQgZm9yIHRoZSBnZW5lcmFsIGNhc2UuICBPZiBj b3Vyc2UsIGl04oCZcyBmaW5lIGZvciBwYXJ0aWN1bGFyIFByb2ZpbGluZyBTcGVjaWZpY2F0aW9u cyB0byByZXF1aXJlIHRoYXQg4oCcZXhw4oCdIGJlIHByZXNlbnQgYW5kIGRlZmluZSBjb25zdHJh aW50cyB0aGF0IHRoZSBjbGFpbSB2YWx1ZSBtdXN0IHNhdGlzZnkgZm9yIGRlcGxveW1lbnRzIHVz aW5nIHRoYXQgcHJvZmlsZeKApg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBJZC1ldmVudCA8aWQtZXZlbnQt Ym91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIE1hcml1cyBTY3VydGVzY3UNClNlbnQ6IFRo dXJzZGF5LCBNYXJjaCAyMiwgMjAxOCAzOjQ5IEFNDQpUbzogSUQgRXZlbnRzIE1haWxpbmcgTGlz dCA8aWQtZXZlbnRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbSWQtZXZlbnRdICJleHAiIGNsYWltIGlu IGRyYWZ0LWlldGYtc2VjZXZlbnQtdG9rZW4tMDcNCg0KU2VjdGlvbiAyLjIgZm9yICJleHAiIHN0 YXRlczoNCg0KInRoaXMgY2xhaW0gaXMgdGhlIHRpbWUgYWZ0ZXIgd2hpY2ggdGhlIEpXVCBNVVNU IE5PVCBiZSBhY2NlcHRlZCBmb3IgcHJvY2Vzc2luZy4gIEluIHRoZSBjb250ZXh0IG9mIGEgU0VU IGhvd2V2ZXIsIHRoaXMgbm90aW9uIGRvZXMgbm90IHR5cGljYWxseSBhcHBseSwgc2luY2UgYSBT RVQgcmVwcmVzZW50cyBzb21ldGhpbmcgdGhhdCBoYXMgYWxyZWFkeSBvY2N1cnJlZCBhbmQgaXMg aGlzdG9yaWNhbCBpbiBuYXR1cmUuIFRoZXJlZm9yZSwgaXRzIHVzZSBpcyBOT1QgUkVDT01NRU5E RUQuIg0KDQpTaW1pbGFybHksIHNlY3Rpb24gNC41IG1ha2VzIHJlY29tbWVuZGF0aW9ucyBhZ2Fp bnN0ICJleHAiLg0KDQpBdCBJRVRGIDEwMCBpbiBTaW5nYXBvcmUgd2UgYnJpZWZseSB0YWxrZWQg YWJvdXQgdGhpcyBhbmQgdGhlIGZvbGxvd2luZyBwcm9ibGVtIGNhbWUgdXA6IHdpdGhvdXQgImV4 cCIgaG93IGxvbmcgc2hvdWxkIGEgcmVjZWl2ZXIgY2FjaGUgImp0aSIgdmFsdWVzIHRvIHByZXZl bnQgZG91YmxlIHN1Ym1pc3Npb25zIChhbmQgcmVwbGF5IGF0dGFja3MpPw0KDQpUb2RheSB0aGUg c2FtZSBwcm9ibGVtIHdhcyByYWlzZWQgYXMgaW1wbGVtZW50YXRpb24gZmVlZGJhY2suDQoNCkl0 IHNlZW1zIHRoYXQgImV4cCIgc2hvdWxkIHJhdGhlciBiZSByZXF1aXJlZC4gVGhvdWdodHM/DQoN CldoYXQgaGFwcGVucyB0byBzZWN0aW9uIDQuNSBpZiAiZXhwIiBpcyByZXF1aXJlZD8NCg0KQWxz bywgYSByZXF1aXJlZCAob3IgcmVjb21tZW5kZWQpICJleHAiIGxlYWRzIHRvIGltcGxlbWVudGF0 aW9uIGNoYWxsZW5nZXMgd2hlbiBpdCBjb21lcyB0byBkZWxpdmVyeS4gQSB0cmFuc21pdHRlciB0 aGF0IGlzIHJldHJ5aW5nIHRvIGRlbGl2ZXIgdW5jb25maXJtZWQgU0VUcywgd2lsbCBoYXZlIHRv IHByb2JhYmx5IHJlLW1pbnQgdGhlbSBvbiBlYWNoIGRlbGl2ZXJ5IGF0dGVtcHQsIGFzIG9wcG9z ZWQgdG8gc2ltcGx5IGNhY2hlIGEgbWludGVkIFNFVCBhbmQga2VlcCByZXRyeWluZyB3aXRoIHRo YXQuIE9yIHRoZSB0cmFuc21pdHRlciB3aWxsIGhhdmUgdG8gc2V0IGFuIGV4cGlyYXRpb24gcGVy aW9kIGxvbmdlciB0aGFuIHRoZSByZXRyeSBwZXJpb2QsIGJ1dCBsb25nIGV4cGlyYXRpb24gcGVy aW9kcyBwdXQgYmlnZ2VyIGxvYWRzIG9uIHJlY2VpdmVycyAobGFyZ2VyIGNhY2hlKS4NCg0KQW55 IGNoYW5jZSB0aGlzIGNhbiBiZSBkaXNjdXNzZWQgb24gRnJpZGF5Pw0KDQpNYXJpdXMNCg== --_000_DM5PR00MB0296295C7D3C2E311C4F4941F5A90DM5PR00MB0296namp_ 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 cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5t c29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMDAyMDYwO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9 IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5UbyBtZSwgaXQgc2VlbXMgdGhhdCB0cnlp bmcgdG8gbWFuZGF0ZSB0aGF0IGFuIGV4cGlyYXRpb24gdGltZSBiZSBzZW50IHdoZW4gdGhlcmUg aXMgbm8gbmF0dXJhbCBleHBpcmF0aW9uIHRpbWUgZm9yIHRoZSBpbmZvcm1hdGlvbiBpcyBvZGQg YXQgYmVzdCwgYW5kIGNvdW50ZXJwcm9kdWN0aXZlIGF0IHdvcnN0LiZuYnNwOyBXZSBzaG91bGQg bm90IGVuY291cmFnZSBkZXBsb3llcnMNCiB0byBoYXZlIHRvIOKAnGludmVudOKAnSBhcmJpdHJh cmlseSBjaG9zZW4gdmFsdWVzIGFuZCBpbmNsdWRlIHRoZW0gYXMgY2xhaW1zIHRvIHNhdGlzZnkg YSBNVVNUIHRoYXQgc2hvdWxkbuKAmXQgaGF2ZSBiZWVuIHRoZXJlLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzAwMjA2MCI+Q2FjaGluZyBkZWNpc2lvbnMgYXJlIGhpZ2hseSBkZXBsb3lt ZW50IHNwZWNpZmljLiZuYnNwOyBUaGV5IGNvdWxkLCBmb3IgaW5zdGFuY2UsIGJlIGJhc2VkIG9u IGEgZGVwbG95bWVudC1zcGVjaWZpZWQgZGVsdGEgZnJvbSB0aGUg4oCcaWF04oCdIChpc3N1ZWQg YXQpIHZhbHVlIGFuZCBub3QgdXNlIOKAnGV4cOKAnSBhdCBhbGwuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMDAyMDYwIj5XaXRoIHJlc3BlY3QgdG8g4oCcZXhw4oCdLCBJIHRoaW5rIHRo ZSBzcGVjIGFscmVhZHkgaGFzIGl0IHJpZ2h0IGZvciB0aGUgZ2VuZXJhbCBjYXNlLiZuYnNwOyBP ZiBjb3Vyc2UsIGl04oCZcyBmaW5lIGZvciBwYXJ0aWN1bGFyIFByb2ZpbGluZyBTcGVjaWZpY2F0 aW9ucyB0byByZXF1aXJlIHRoYXQg4oCcZXhw4oCdIGJlIHByZXNlbnQgYW5kIGRlZmluZSBjb25z dHJhaW50cyB0aGF0IHRoZQ0KIGNsYWltIHZhbHVlIG11c3Qgc2F0aXNmeSBmb3IgZGVwbG95bWVu dHMgdXNpbmcgdGhhdCBwcm9maWxl4oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAy MDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj5Gcm9tOjwvYj4gSWQtZXZlbnQgJmx0O2lkLWV2ZW50LWJvdW5jZXNAaWV0Zi5vcmcm Z3Q7IDxiPk9uIEJlaGFsZiBPZg0KPC9iPk1hcml1cyBTY3VydGVzY3U8YnI+DQo8Yj5TZW50Ojwv Yj4gVGh1cnNkYXksIE1hcmNoIDIyLCAyMDE4IDM6NDkgQU08YnI+DQo8Yj5Ubzo8L2I+IElEIEV2 ZW50cyBNYWlsaW5nIExpc3QgJmx0O2lkLWV2ZW50QGlldGYub3JnJmd0Ozxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBbSWQtZXZlbnRdICZxdW90O2V4cCZxdW90OyBjbGFpbSBpbiBkcmFmdC1pZXRmLXNl Y2V2ZW50LXRva2VuLTA3PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZWN0aW9uIDIu MiBmb3IgJnF1b3Q7ZXhwJnF1b3Q7IHN0YXRlczo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mcXVvdDt0aGlzIGNsYWltIGlzIHRoZSB0aW1lIGFm dGVyIHdoaWNoIHRoZSBKV1QgTVVTVCBOT1QgYmUgYWNjZXB0ZWQgZm9yIHByb2Nlc3NpbmcuJm5i c3A7IEluIHRoZSBjb250ZXh0IG9mIGEgU0VUIGhvd2V2ZXIsIHRoaXMgbm90aW9uIGRvZXMgbm90 IHR5cGljYWxseSBhcHBseSwgc2luY2UgYSBTRVQgcmVwcmVzZW50cyBzb21ldGhpbmcgdGhhdCBo YXMgYWxyZWFkeSBvY2N1cnJlZCBhbmQgaXMgaGlzdG9yaWNhbCBpbiBuYXR1cmUuDQogVGhlcmVm b3JlLCBpdHMgdXNlIGlzIE5PVCBSRUNPTU1FTkRFRC4mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2ltaWxhcmx5LCBzZWN0aW9uIDQu NSBtYWtlcyByZWNvbW1lbmRhdGlvbnMgYWdhaW5zdCAmcXVvdDtleHAmcXVvdDsuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkF0IElFVEYgMTAw IGluIFNpbmdhcG9yZSB3ZSBicmllZmx5IHRhbGtlZCBhYm91dCB0aGlzIGFuZCB0aGUgZm9sbG93 aW5nIHByb2JsZW0gY2FtZSB1cDogd2l0aG91dCAmcXVvdDtleHAmcXVvdDsgaG93IGxvbmcgc2hv dWxkIGEgcmVjZWl2ZXIgY2FjaGUgJnF1b3Q7anRpJnF1b3Q7IHZhbHVlcyB0byBwcmV2ZW50IGRv dWJsZSBzdWJtaXNzaW9ucyAoYW5kIHJlcGxheSBhdHRhY2tzKT88bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VG9kYXkgdGhlIHNhbWUgcHJvYmxl bSB3YXMgcmFpc2VkIGFzIGltcGxlbWVudGF0aW9uIGZlZWRiYWNrLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBzZWVtcyB0aGF0ICZxdW90 O2V4cCZxdW90OyBzaG91bGQgcmF0aGVyIGJlIHJlcXVpcmVkLiBUaG91Z2h0cz88bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hhdCBoYXBwZW5z IHRvIHNlY3Rpb24gNC41IGlmICZxdW90O2V4cCZxdW90OyBpcyByZXF1aXJlZD88bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWxzbywgYSByZXF1 aXJlZCAob3IgcmVjb21tZW5kZWQpICZxdW90O2V4cCZxdW90OyBsZWFkcyB0byBpbXBsZW1lbnRh dGlvbiBjaGFsbGVuZ2VzIHdoZW4gaXQgY29tZXMgdG8gZGVsaXZlcnkuIEEgdHJhbnNtaXR0ZXIg dGhhdCBpcyByZXRyeWluZyB0byBkZWxpdmVyIHVuY29uZmlybWVkIFNFVHMsIHdpbGwgaGF2ZSB0 byBwcm9iYWJseSByZS1taW50IHRoZW0gb24gZWFjaCBkZWxpdmVyeSBhdHRlbXB0LCBhcyBvcHBv c2VkIHRvDQogc2ltcGx5IGNhY2hlIGEgbWludGVkIFNFVCBhbmQga2VlcCByZXRyeWluZyB3aXRo IHRoYXQuIE9yIHRoZSB0cmFuc21pdHRlciB3aWxsIGhhdmUgdG8gc2V0IGFuIGV4cGlyYXRpb24g cGVyaW9kIGxvbmdlciB0aGFuIHRoZSByZXRyeSBwZXJpb2QsIGJ1dCBsb25nIGV4cGlyYXRpb24g cGVyaW9kcyBwdXQgYmlnZ2VyIGxvYWRzIG9uIHJlY2VpdmVycyAobGFyZ2VyIGNhY2hlKS48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW55IGNo YW5jZSB0aGlzIGNhbiBiZSBkaXNjdXNzZWQgb24gRnJpZGF5PzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NYXJpdXM8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DM5PR00MB0296295C7D3C2E311C4F4941F5A90DM5PR00MB0296namp_-- From nobody Thu Mar 22 03:42:08 2018 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 3B9AF126D05 for ; Thu, 22 Mar 2018 03:42:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lLSn82RFgOSO for ; Thu, 22 Mar 2018 03:41:57 -0700 (PDT) Received: from aserp2120.oracle.com (aserp2120.oracle.com [141.146.126.78]) (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 399DB1200C5 for ; Thu, 22 Mar 2018 03:41:57 -0700 (PDT) Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w2MAfslw154093; Thu, 22 Mar 2018 10:41:55 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2017-10-26; bh=HHIhIDMexZG27NqpMv7nNLrVZ7pKMaenbCn/qhOGmJk=; b=Psh9QPcJebJRq2RybLL5NqwMrFTUOIbYFnNASQT0BUvtUOjgu53uKj/KZYdqG235jJCJ jKtX6i1NjIef5WwCHw7+VGdRcXyFISQoQ4HYFJwcAAf4xMMYIres2ET/UCw3brWvWSst +O+OH8ceDzWnQcdaa39JYAwl6HX8yPk8f3d16WPNa27CshRisl3QS+eDsmIZ3bo9AdT2 VHtwLCMNk+1wZB4UR1tk/lr9jgh0LPOhDwNL2udkYQphpj/y5uvV0CGgtjSRw5FvVBT+ WjY/X9if6jbK1P4YJGAeWVKreiA/SICtjxaxw7DudQVJsoFUtkE/ozaJj38Dea06uvrW Gg== Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp2120.oracle.com with ESMTP id 2gvay9800q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 22 Mar 2018 10:41:55 +0000 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 w2MAfs97027610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 22 Mar 2018 10:41:54 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w2MAfsGj001763; Thu, 22 Mar 2018 10:41:54 GMT Received: from [25.161.208.254] (/24.114.39.114) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 22 Mar 2018 03:41:54 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-DB039685-8277-4C18-A29E-6142BAD31128 Mime-Version: 1.0 (1.0) From: Phil Hunt X-Mailer: iPhone Mail (15D100) In-Reply-To: Date: Thu, 22 Mar 2018 10:41:43 +0000 Cc: Marius Scurtescu , ID Events Mailing List Content-Transfer-Encoding: 7bit Message-Id: <426BBCAA-59AC-44CF-8937-6AFCE1C12383@oracle.com> References: To: Mike Jones X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8839 signatures=668695 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803200127 Archived-At: Subject: Re: [Id-event] "exp" claim in draft-ietf-secevent-token-07 X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 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 Mar 2018 10:42:07 -0000 --Apple-Mail-DB039685-8277-4C18-A29E-6142BAD31128 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable There are also a number of security considerations in the draft regarding us= e of =E2=80=9Cexp=E2=80=9D and differentiation from access tokens that are i= mportant.=20 Phil > On Mar 22, 2018, at 10:29 AM, Mike Jones wro= te: >=20 > To me, it seems that trying to mandate that an expiration time be sent whe= n there is no natural expiration time for the information is odd at best, an= d counterproductive at worst. We should not encourage deployers to have to =E2= =80=9Cinvent=E2=80=9D arbitrarily chosen values and include them as claims t= o satisfy a MUST that shouldn=E2=80=99t have been there. > =20 > Caching decisions are highly deployment specific. They could, for instanc= e, be based on a deployment-specified delta from the =E2=80=9Ciat=E2=80=9D (= issued at) value and not use =E2=80=9Cexp=E2=80=9D at all. > =20 > With respect to =E2=80=9Cexp=E2=80=9D, I think the spec already has it rig= ht for the general case. Of course, it=E2=80=99s fine for particular Profil= ing Specifications to require that =E2=80=9Cexp=E2=80=9D be present and defi= ne constraints that the claim value must satisfy for deployments using that p= rofile=E2=80=A6 > =20 > -- Mike > =20 > From: Id-event On Behalf Of Marius Scurtescu > Sent: Thursday, March 22, 2018 3:49 AM > To: ID Events Mailing List > Subject: [Id-event] "exp" claim in draft-ietf-secevent-token-07 > =20 > Section 2.2 for "exp" states: > =20 > "this claim is the time after which the JWT MUST NOT be accepted for proce= ssing. In the context of a SET however, this notion does not typically appl= y, since a SET represents something that has already occurred and is histori= cal in nature. Therefore, its use is NOT RECOMMENDED." > =20 > Similarly, section 4.5 makes recommendations against "exp". > =20 > At IETF 100 in Singapore we briefly talked about this and the following pr= oblem came up: without "exp" how long should a receiver cache "jti" values t= o prevent double submissions (and replay attacks)? > =20 > Today the same problem was raised as implementation feedback. > =20 > It seems that "exp" should rather be required. Thoughts? > =20 > What happens to section 4.5 if "exp" is required? > =20 > Also, a required (or recommended) "exp" leads to implementation challenges= when it comes to delivery. A transmitter that is retrying to deliver unconf= irmed SETs, will have to probably re-mint them on each delivery attempt, as o= pposed to simply cache a minted SET and keep retrying with that. Or the tran= smitter will have to set an expiration period longer than the retry period, b= ut long expiration periods put bigger loads on receivers (larger cache). > =20 > Any chance this can be discussed on Friday? > =20 > Marius > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI= _JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DQQOgQSojDGJSe_9Lg0o= GRRneEiqaQvngT0E72naO7dw&s=3D6ko84GUvrZOLjdLorjYhGWnlDd8x_j2zTLxeEESL56c&e=3D= --Apple-Mail-DB039685-8277-4C18-A29E-6142BAD31128 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable There are also a number of security conside= rations in the draft regarding use of =E2=80=9Cexp=E2=80=9D and differentiat= ion from access tokens that are important. 

Phil

On Mar 22, 2018, at 10:29 AM, Mike Jones <<= a href=3D"mailto:Michael.Jones@microsoft.com">Michael.Jones@microsoft.com> wrote:

To me, it seems that tr= ying to mandate that an expiration time be sent when there is no natural exp= iration time for the information is odd at best, and counterproductive at wo= rst.  We should not encourage deployers to have to =E2=80=9Cinvent=E2=80=9D arbitrarily chosen values and include t= hem as claims to satisfy a MUST that shouldn=E2=80=99t have been there.=

 

Caching decisions are h= ighly deployment specific.  They could, for instance, be based on a dep= loyment-specified delta from the =E2=80=9Ciat=E2=80=9D (issued at) value and= not use =E2=80=9Cexp=E2=80=9D at all.

 

With respect to =E2=80=9C= exp=E2=80=9D, I think the spec already has it right for the general case.&nb= sp; Of course, it=E2=80=99s fine for particular Profiling Specifications to r= equire that =E2=80=9Cexp=E2=80=9D be present and define constraints that the= claim value must satisfy for deployments using that profile=E2=80=A6

 

    = ;            &nb= sp;            &= nbsp;            = ;             --= Mike

 

From: Id-event <id-event-bounces@ietf.org> On Behalf Of Marius Scurtescu
Sent: Thursday, March 22, 2018 3:49 AM
To: ID Events Mailing List <i= d-event@ietf.org>
Subject: [Id-event] "exp" claim in draft-ietf-secevent-token-07<= /o:p>

 

Section 2.2 for "exp" states:

 

"this claim is the time after which the JWT MUST NOT b= e accepted for processing.  In the context of a SET however, this notio= n does not typically apply, since a SET represents something that has alread= y occurred and is historical in nature. Therefore, its use is NOT RECOMMENDED."

 

Similarly, section 4.5 makes recommendations against "= exp".

 

At IETF 100 in Singapore we briefly talked about this= and the following problem came up: without "exp" how long should a receiver= cache "jti" values to prevent double submissions (and replay attacks)?=

 

Today the same problem was raised as implementation f= eedback.

 

It seems that "exp" should rather be required. Though= ts?

 

What happens to section 4.5 if "exp" is required?

 

Also, a required (or recommended) "exp" leads to impl= ementation challenges when it comes to delivery. A transmitter that is retry= ing to deliver unconfirmed SETs, will have to probably re-mint them on each d= elivery attempt, as opposed to simply cache a minted SET and keep retrying with that. Or the transmitter w= ill have to set an expiration period longer than the retry period, but long e= xpiration periods put bigger loads on receivers (larger cache).

 

Any chance this can be discussed on Friday?

 

Marius

= --Apple-Mail-DB039685-8277-4C18-A29E-6142BAD31128-- From nobody Thu Mar 22 04:30:08 2018 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 58567120721 for ; Thu, 22 Mar 2018 04:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 kgscCztqQ_2l for ; Thu, 22 Mar 2018 04:30:02 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CDCF124235 for ; Thu, 22 Mar 2018 04:30:02 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id y127so4981497vky.9 for ; Thu, 22 Mar 2018 04:30:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+cH66UN5QSvvD/FsS8CCZudnMG9nNQj1503aaciY+Ao=; b=VeORy2SDeBW6wikkzXBs29Ulgb1zlO44HP2DvFdWBVj5Q94DoYrnxhDcJSeuP7NPxM 0Ehf29ERcEQYZ005alGSmnzOqZOovHOSM0oIa0MxGrpBTzxcx647cFEqVUOx+ZMeseLF dnnHhEuz4d0Eion+YLh9DBYh60PpB9IyHznSBy0dtgIoyK0HZGr0/fSN/fnMxoFEHy89 quAkkKCk+zLT+HNB5BQcm2rX5VNz3kesfxPFmSFuIhVMK9y6yxzsbK7Ijvm6NgqMk+c0 Idi4vIbxqTdN8jAAfmwaBNrJRySrbK6D9prDqQlrZNOs8L6fVMqOlAcYPwB8dgDz2NVY Vx3w== 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=+cH66UN5QSvvD/FsS8CCZudnMG9nNQj1503aaciY+Ao=; b=img9R0asoZRQZE/wrEdNgx+X97jXDq6zwxsuh6JLEtXBLHHtYkhCE/owVYfr8aJqub 2/DX1Z7VaypXGjUCKI2lW0MUfet7jyr7K6w3RRIQ+xMfp6lyMZ/+fhpJSj48zNAIPtY+ vX0IZQK1Y0b+USolT4rQOpXvd5oi9SC+7ZjYRh//MHb1b12r2Sk0XDZhdzZYVUbVxD9a 4PeOiq0fsrpevlgtZOrwU5Q3g+2qgaoGp3tKnH/x76Yyl7YgUPqEYYYN8pHIvPgSaofE XneRDvYyY0tMD31kcGmewd2ASexDgvyBVdpSt8XRtXOcG+UkS5ICoSDT1nZbQcmzIlGS /lWA== X-Gm-Message-State: AElRT7HLp6vQlkDHI7l1OJDRAhSjnPYQchrkT7U6TY4Vx0Xdm/WZHgVh EO9xx3aVGyeV+UJ5spjP1KTmKVcAsoLV6iKUrkbDKxJ+HFQ= X-Google-Smtp-Source: AG47ELtpqZaLIHLnedrmbDY4RhtlBhmjM8ZfllSt72NJuRT1NYa3ahshtOwGDDkqYtMDTmiZH42ZPKawdx6ah29GcKk= X-Received: by 10.31.215.65 with SMTP id o62mr15007166vkg.152.1521718200969; Thu, 22 Mar 2018 04:30:00 -0700 (PDT) MIME-Version: 1.0 References: <99920B12-09F2-4293-B214-F766C00CAE6E@oracle.com> <221f7700-d279-1156-1b56-d222b111bce3@gmail.com> In-Reply-To: From: William Denniss Date: Thu, 22 Mar 2018 11:29:50 +0000 Message-ID: To: Marius Scurtescu Cc: Yaron Sheffer , ID Events Mailing List , Phil Hunt Content-Type: multipart/alternative; boundary="94eb2c07d90ad1c12d0567fea028" Archived-At: Subject: Re: [Id-event] Summary of working session discussion X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 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 Mar 2018 11:30:06 -0000 --94eb2c07d90ad1c12d0567fea028 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Mar 22, 2018 at 10:04 AM Marius Scurtescu wrote: > Hi Yaron, > > I don't think anyone can argue with the desire for strong interop and les= s > complexity. > > Wearing our implementor hats, what delivery method would optimally cover > all use cases? Do we want a delivery method that in theory can cover most > use cases, but it is suboptimal for many of them? How would a mobile or I= oT > device use the current PUSH or POLL methods? > > We are not talking about alternative delivery methods for the same use > case, but different methods for each separate use case. I totally agree > that as a workinggroup we should support one method per use case, for > example one method for HTTP receivers sitting behind firewalls. I am usin= g > "use case" in a generic way, more like "profile". > > Why declare one method as MTI when it is clear that it will not work for > many use cases and that implementors for those use cases will be forced t= o > ignore the MTI? > > Regarding the current delivery draft, why do you think that keeping the > two methods together is beneficial? The overlap between the two is minima= l. > Here are the reasons why I think the draft should be split: > > 1. The two methods have different maturity levels. The PUSH method is > already implemented and more implementation will come online soon. The PO= LL > method has no implementation yet, as far as I know. By keeping them > together we hold back one and put pressure to rush the other. That's > lose-lose. > > 2. With two methods in one drafts it is very ambiguous what is MTI. With > two separate drafts each implemetor can chose what works for their use > cases. Interop will work out based on use cases, I don't think we have to > force it. > > The clear message for implementors two years from now would be a clear > description for each method as to what use cases it is applicable to. No > confusion at all, if you are behind a firewall then POLL is your only > option. If you are delivering to IoT then whatever method works for that > use case (we don't have one yet). > > I asked about a meta-document from a practical point of view.. How/where > will the MTI delivery method be defined? Same with IETF police, maybe you > misunderstood. I am not worried about implementors disregarding > recommendations. Since the unit for specifications are RFCs, how can some > RFC be declared as MTI? In what context? Again, from a practical editoria= l > point of view. > Speaking to one draft I worked on where we faced this decision, PKCE Section 4.2 defined two methods to transform the code challenge, plain text (no transformation), and SHA256. "S256" is declared as MTI in the spec, and "plain" is not. In this case we actually say "Mandatory to Implement", but gating SHA256 with a "MUST" and the "plain" with a "MAY" would have achieved the same effect. I advocated for making S256 MTI (when I first reviewed the draft, both were given equal weighting) so that native app clients would not need to perform discovery on the server to work out which method they can use (and provide additional API methods for the developer to specify the transform for servers that don't support discovery). Since SHA256 is MTI, all native app clients can rely on it being implemented. And that's what AppAuth does, it has no support for "plain", and doesn't bother with doing discovery on the PKCE method, which greatly simplified the implementation (and it's completely seamless to users of AppAuth). As we required MTI on the more secure option of the two, this also resulted in more secure implementations by default. YMMV =E2=80=93 but that's what we did in that case :-) > Guidance would be very useful IMO. > > Thanks, > Marius > > > Marius > > On Wed, Mar 21, 2018 at 9:05 AM, Yaron Sheffer > wrote: > >> Hi Marius, >> >> The decision about whether we need to have an MTI protocol and which one >> it should be is up to the WG consensus, like everything else. But with m= y >> WG chair hat on, it is my strong conviction that we need to have one MTI >> method to encourage interoperability and reduce fragmentation. This is >> based on my IETF experience, and not on any meta-document as far as I ca= n >> tell. Just think of implementers that are not part of the WG, and just r= ead >> the RFCs two years from now. They need to have a clear message which met= hod >> will allow them the best (though maybe not perfect) interoperability. Al= so, >> I personally do not have a preference which of the methods becomes MTI. >> >> It is common at the IETF to say that "there is no IETF police", in other >> words if you choose to not implement an MTI protocol/feature, nobody is >> going to come after you and punish you. It is between you and your marke= t. >> I fully expect some of the WG participants to only implement the non-MTI >> method. >> >> We can absolutely ask the incoming AD for more guidance in this area. >> >> I think keeping the two methods within the same document will speed up >> and simplify the process, compared to running two docs in parallel. They= do >> have enough commonalities. >> >> Thanks, >> Yaron >> >> On 21/03/18 15:42, Marius Scurtescu wrote: >> >>> Thanks for the summary Phil. >>> >>> Comments inline... >>> >>> On Wed, Mar 21, 2018 at 6:43 AM, Phil Hunt >> > wrote: >>> >>> We held a couple of brief sessions over the last couple days. >>> >>> We talked about the issue of breaking up the delivery document, >>> multiple delivery methods, and optionality. >>> >>> Some observations: >>> >>> 1. Yaron indicated that the IETF will likely require one method be >>> MTI (mandatory to implement). >>> >>> >>> It would be very useful to point to other working groups and specs wher= e >>> this was the case. >>> >>> What is the mechanism by which a specific delivery method is made MTI? >>> Which meta document specifies that? >>> >>> What happens if a provider is not implementing the MTI delivery method? >>> What does that exactly mean? >>> >>> Just trying to understand what the process is.. >>> >>> >>> While PUSH has better scale (because it does not need HTTP Long >>> Polling), the POLL method has broader utility due to the presence o= f >>> receivers with firewalls, gateways (IoT devices), or are mobile >>> applications that cannot implement endpoints to receive HTTP POSTs. >>> >>> >>> To me it is very unlikely that IoT or mobile devices will use POLL (or >>> PUSH). They will need some other delivery methods appropriate for their >>> architecture. Having the current PUSH or POLL mandatory for these cases >>> does not make sense to me, >>> >>> >>> 2. If POLL is chosen as the MTI method, many will still likely >>> prefer PUSH and so that will likely get implemented sooner by some >>> >>> >>> Many will simply not implement POLL if what they need is PUSH, and vice >>> versa. Again, I don't see how the working group can pick any delivery >>> method and make it MTI. And MTI in what context? >>> >>> Can we escalate this issue within IETF to get guidance? >>> >>> >>> >>> 3. There was a general feeling that the delivery draft should stay >>> as one draft. >>> >>> >>> I don't see how that is helping, but if implementors can chose either >>> PUSH or POLL from the current draft then that's fine. But in that case >>> splitting should also be acceptable. >>> >>> >>> >>> Annabelle will present her recommendations at the formal meeting on >>> Friday where we can get broader input. >>> >>> Thanks everyone. >>> >>> Phil >>> >>> Oracle Corporation, Identity Cloud Services Architect >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>> >>> >>> _______________________________________________ >>> 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 >>> >>> > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://www.ietf.org/mailman/listinfo/id-event > --94eb2c07d90ad1c12d0567fea028 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Thu, Ma= r 22, 2018 at 10:04 AM Marius Scurtescu <mscurtescu@google.com> wrote:
Hi Yaron,

<= div>I don't think anyone can argue with the desire for strong interop a= nd less complexity.

Wearing our implementor hats, = what delivery method would optimally cover all use cases? Do we want a deli= very method that in theory can cover most use cases, but it is suboptimal f= or many of them? How would a mobile or IoT device use the current PUSH or P= OLL methods?

We are not talking about alternative = delivery methods for the same use case, but different methods for each sepa= rate use case. I totally agree that as a workinggroup we should support one= method per use case, for example one method for HTTP receivers sitting beh= ind firewalls. I am using "use case" in a generic way, more like = "profile".

Why declare one method as MTI= when it is clear that it will not work for many use cases and that impleme= ntors for those use cases will be forced to ignore the MTI?

<= /div>
Regarding the current delivery draft, why do you think that keepi= ng the two methods together is beneficial? The overlap between the two is m= inimal. Here are the reasons why I think the draft should be split:

1. The two methods have different maturity levels. The PU= SH method is already implemented and more implementation will come online s= oon. The POLL method has no implementation yet, as far as I know. By keepin= g them together we hold back one and put pressure to rush the other. That&#= 39;s lose-lose.

2. With two methods in one drafts = it is very ambiguous what is MTI. With two separate drafts each implemetor = can chose what works for their use cases. Interop will work out based on us= e cases, I don't think we have to force it.

Th= e clear message for implementors two years from now would be a clear descri= ption for each method as to what use cases it is applicable to. No confusio= n at all, if you are behind a firewall then POLL is your only option. If yo= u are delivering to IoT then whatever method works for that use case (we do= n't have one yet).

I asked about a meta-docume= nt from a practical point of view.. How/where will the MTI delivery method = be defined? Same with IETF police, maybe you misunderstood. I am not worrie= d about implementors disregarding recommendations. Since the unit for speci= fications are RFCs, how can some RFC be declared as MTI? In what context? A= gain, from a practical editorial point of view.=C2=A0

Speaking to one draft I worked on= where we faced this decision,=C2=A0PKCE Section 4.2=C2=A0defined= two methods to transform the code challenge, plain text (no transformation= ), and SHA256.

"S256" is declared as MTI in the spec, and= "plain" is not. In this case we actually say "Mandatory to = Implement", but gating SHA256 with a "MUST" and the "pl= ain" with a "MAY" would have achieved the same effect.
=

I advocated for making S256 MTI (when I first reviewed the draft, both wer= e given equal weighting) so that native app clients would not need to perfo= rm discovery on the server to work out which method they can use (and provi= de additional API methods for the developer to specify the transform for se= rvers that don't support discovery). Since SHA256 is MTI, all native ap= p clients can rely on it being implemented.=C2=A0 And that's what AppAu= th does, it has no support for "plain", and doesn't bother wi= th doing discovery on the PKCE method, which greatly simplified the impleme= ntation (and it's completely seamless to users of AppAuth). As we requi= red MTI on the more secure option of the two, this also resulted in more se= cure implementations by default.

YMMV =E2=80=93 but that's = what we did in that case :-)

=C2=A0
G= uidance would be very useful IMO.

Thanks,
Marius


Marius<= /div>

On Wed, Mar 21, 2018 at 9:05 AM, Yaron Sheff= er <yaronf.ietf@gmail.com> wrote:
Hi Marius,

The decision about whether we need to have an MTI protocol and which one it= should be is up to the WG consensus, like everything else. But with my WG = chair hat on, it is my strong conviction that we need to have one MTI metho= d to encourage interoperability and reduce fragmentation. This is based on = my IETF experience, and not on any meta-document as far as I can tell. Just= think of implementers that are not part of the WG, and just read the RFCs = two years from now. They need to have a clear message which method will all= ow them the best (though maybe not perfect) interoperability. Also, I perso= nally do not have a preference which of the methods becomes MTI.

It is common at the IETF to say that "there is no IETF police", i= n other words if you choose to not implement an MTI protocol/feature, nobod= y is going to come after you and punish you. It is between you and your mar= ket. I fully expect some of the WG participants to only implement the non-M= TI method.

We can absolutely ask the incoming AD for more guidance in this area.

I think keeping the two methods within the same document will speed up and = simplify the process, compared to running two docs in parallel. They do hav= e enough commonalities.

Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Yaron

On 21/03/18 15:42, Marius Scurtescu wrote:
Thanks for the summary Phil.

Comments inline...

 On Wed, Mar 21, 2018 at 6:43 AM, Phil Hunt <phil.hunt@oracle.com <mailto:phil.hunt@oracle.com= >> wrote:

=C2=A0 =C2=A0 We held a couple of brief sessions over the last couple days.=

=C2=A0 =C2=A0 We talked about the issue of breaking up the delivery documen= t,
=C2=A0 =C2=A0 multiple delivery methods, and optionality.

=C2=A0 =C2=A0 Some observations:

=C2=A0 =C2=A0 1. Yaron indicated that the IETF will likely require one meth= od be
=C2=A0 =C2=A0 MTI (mandatory to implement).


It would be very useful to point to other working groups and specs where th= is was the case.

What is the mechanism by which a specific delivery method is made MTI? Whic= h meta document specifies that?

What happens if a provider is not implementing the MTI delivery method? Wha= t does that exactly mean?

 Just trying to understand what the process is..


=C2=A0 =C2=A0 While PUSH has better scale (because it does not need HTTP Lo= ng
=C2=A0 =C2=A0 Polling), the POLL method has broader utility due to the pres= ence of
=C2=A0 =C2=A0 receivers with firewalls, gateways (IoT devices), or are mobi= le
=C2=A0 =C2=A0 applications that cannot implement endpoints to receive HTTP = POSTs.


To me it is very unlikely that IoT or mobile devices will use POLL (or PUSH= ). They will need some other delivery methods appropriate for their archite= cture. Having the current PUSH or POLL mandatory for these cases does not m= ake sense to me,


=C2=A0 =C2=A0 2.=C2=A0 If POLL is chosen as the MTI method, many will still= likely
=C2=A0 =C2=A0 prefer PUSH and so that will likely get implemented sooner by= some


Many will simply not implement POLL if what they need is PUSH, and vice ver= sa. Again, I don't see how the working group can pick any delivery meth= od and make it MTI. And MTI in what context?

Can we escalate this issue within IETF to get guidance?



=C2=A0 =C2=A0 3.=C2=A0 There was a general feeling that the delivery draft = should stay
=C2=A0 =C2=A0 as one draft.


I don't see how that is helping, but if implementors can chose either P= USH or POLL from the current draft then that's fine. But in that case s= plitting should also be acceptable.



=C2=A0 =C2=A0 Annabelle will present her recommendations at the formal meet= ing on
=C2=A0 =C2=A0 Friday where we can get broader input.

=C2=A0 =C2=A0 Thanks everyone.

=C2=A0 =C2=A0 Phil

=C2=A0 =C2=A0 Oracle Corporation, Identity Cloud Services Architect
=C2=A0 =C2=A0 @independentid
 =C2=A0 =C2=A0 www.independentid.com <http://www.independentid.= com>
=C2=A0 =C2=A0 phi= l.hunt@oracle.com <mailto:phil.hunt@oracle.com>


=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 Id-event mailing list
=C2=A0 =C2=A0 Id-eve= nt@ietf.org <mailto:Id-event@ietf.org>
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/id= -event
=C2=A0 =C2=A0 <https://www.ietf.org/mailman/listinf= o/id-event>




_______________________________________________
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
--94eb2c07d90ad1c12d0567fea028-- From nobody Thu Mar 22 08:00:15 2018 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 BBAB412D892 for ; Thu, 22 Mar 2018 08:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Rfk2favVkcP for ; Thu, 22 Mar 2018 08:00:07 -0700 (PDT) Received: from smtp-fw-9101.amazon.com (smtp-fw-9101.amazon.com [207.171.184.25]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DDA412D950 for ; Thu, 22 Mar 2018 08:00:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1521730807; x=1553266807; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Yz+Ngfy87BaGxjNa06YFrE62NU7cBV9WFR0i1tBPt6Y=; b=vAkbegiZUasPzjYjv0d17+5xReilNB4Mr2/QwiiwU70qnB8BPotKsQsf +goTV6FD9d5fUAdw9H272idyMQTM9Z9N8/oCXtSO26SI8E5i7xkZz4nwu Ox3N0ihnirHxKm1nUoEwEueS9YsObsx5kTUlZxwbL60zBQI2aUesOkbqh 8=; X-IronPort-AV: E=Sophos;i="5.48,345,1517875200"; d="scan'208,217";a="730104073" Received: from sea3-co-svc-lb6-vlan3.sea.amazon.com (HELO email-inbound-relay-2b-4ff6265a.us-west-2.amazon.com) ([10.47.22.38]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Mar 2018 15:00:03 +0000 Received: from EX13MTAUWC001.ant.amazon.com (pdx1-ws-svc-p6-lb9-vlan2.pdx.amazon.com [10.236.137.194]) by email-inbound-relay-2b-4ff6265a.us-west-2.amazon.com (8.14.7/8.14.7) with ESMTP id w2MF02Pt035013 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 22 Mar 2018 15:00:03 GMT Received: from EX13D11UWC003.ant.amazon.com (10.43.162.162) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Thu, 22 Mar 2018 15:00:00 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC003.ant.amazon.com (10.43.162.162) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Thu, 22 Mar 2018 14:59:59 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1236.000; Thu, 22 Mar 2018 14:59:59 +0000 From: "Richard Backman, Annabelle" To: William Denniss CC: Marius Scurtescu , Yaron Sheffer , ID Events Mailing List , "Phil Hunt" Thread-Topic: [Id-event] Summary of working session discussion Thread-Index: AQHTwRq4/xeH4dPkh06PLJmjGpczJqPa1CyAgAAGWACAAS2EAIAAF/AAgAA6uDk= Date: Thu, 22 Mar 2018 14:59:59 +0000 Message-ID: <51300156-2DE7-40F8-8B41-66B719D1490C@amazon.com> References: <99920B12-09F2-4293-B214-F766C00CAE6E@oracle.com> <221f7700-d279-1156-1b56-d222b111bce3@gmail.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_513001562DE740F88B4166B719D1490Camazoncom_" MIME-Version: 1.0 Precedence: Bulk Archived-At: Subject: Re: [Id-event] Summary of working session discussion X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 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 Mar 2018 15:00:13 -0000 --_000_513001562DE740F88B4166B719D1490Camazoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > I don't think anyone can argue with the desire for strong interop and les= s complexity. We just finished having that exact argument over SET. The apparent consensu= s was that interoperability across profiles was not desired. I would like t= o see the working group to discuss whether or not profilers and implementer= s expect or want interoperable delivery methods, lest we repeat the same de= bate. There is little point in secevents labeling something MTI if only a s= mall subset of people will be using it. Similarly I am concerned about the working group trying to bless one method= or the other as MTI in the name of maximizing interoperability without evi= dence that said method will be used in the majority of deployments, particu= larly when there are valid technical reasons to favor either one over the o= ther in different scenarios. On Mar 22, 2018, at 11:31 AM, William Denniss > wrote: On Thu, Mar 22, 2018 at 10:04 AM Marius Scurtescu > wrote: Hi Yaron, I don't think anyone can argue with the desire for strong interop and less = complexity. Wearing our implementor hats, what delivery method would optimally cover al= l use cases? Do we want a delivery method that in theory can cover most use= cases, but it is suboptimal for many of them? How would a mobile or IoT de= vice use the current PUSH or POLL methods? We are not talking about alternative delivery methods for the same use case= , but different methods for each separate use case. I totally agree that as= a workinggroup we should support one method per use case, for example one = method for HTTP receivers sitting behind firewalls. I am using "use case" i= n a generic way, more like "profile". Why declare one method as MTI when it is clear that it will not work for ma= ny use cases and that implementors for those use cases will be forced to ig= nore the MTI? Regarding the current delivery draft, why do you think that keeping the two= methods together is beneficial? The overlap between the two is minimal. He= re are the reasons why I think the draft should be split: 1. The two methods have different maturity levels. The PUSH method is alrea= dy implemented and more implementation will come online soon. The POLL meth= od has no implementation yet, as far as I know. By keeping them together we= hold back one and put pressure to rush the other. That's lose-lose. 2. With two methods in one drafts it is very ambiguous what is MTI. With tw= o separate drafts each implemetor can chose what works for their use cases.= Interop will work out based on use cases, I don't think we have to force i= t. The clear message for implementors two years from now would be a clear desc= ription for each method as to what use cases it is applicable to. No confus= ion at all, if you are behind a firewall then POLL is your only option. If = you are delivering to IoT then whatever method works for that use case (we = don't have one yet). I asked about a meta-document from a practical point of view.. How/where wi= ll the MTI delivery method be defined? Same with IETF police, maybe you mis= understood. I am not worried about implementors disregarding recommendation= s. Since the unit for specifications are RFCs, how can some RFC be declared= as MTI? In what context? Again, from a practical editorial point of view. Speaking to one draft I worked on where we faced this decision, PKCE Sectio= n 4.2 defined two methods = to transform the code challenge, plain text (no transformation), and SHA256= . "S256" is declared as MTI in the spec, and "plain" is not. In this case we = actually say "Mandatory to Implement", but gating SHA256 with a "MUST" and = the "plain" with a "MAY" would have achieved the same effect. I advocated for making S256 MTI (when I first reviewed the draft, both were= given equal weighting) so that native app clients would not need to perfor= m discovery on the server to work out which method they can use (and provid= e additional API methods for the developer to specify the transform for ser= vers that don't support discovery). Since SHA256 is MTI, all native app cli= ents can rely on it being implemented. And that's what AppAuth does, it ha= s no support for "plain", and doesn't bother with doing discovery on the PK= CE method, which greatly simplified the implementation (and it's completely= seamless to users of AppAuth). As we required MTI on the more secure optio= n of the two, this also resulted in more secure implementations by default. YMMV - but that's what we did in that case :-) Guidance would be very useful IMO. Thanks, Marius Marius On Wed, Mar 21, 2018 at 9:05 AM, Yaron Sheffer > wrote: Hi Marius, The decision about whether we need to have an MTI protocol and which one it= should be is up to the WG consensus, like everything else. But with my WG = chair hat on, it is my strong conviction that we need to have one MTI metho= d to encourage interoperability and reduce fragmentation. This is based on = my IETF experience, and not on any meta-document as far as I can tell. Just= think of implementers that are not part of the WG, and just read the RFCs = two years from now. They need to have a clear message which method will all= ow them the best (though maybe not perfect) interoperability. Also, I perso= nally do not have a preference which of the methods becomes MTI. It is common at the IETF to say that "there is no IETF police", in other wo= rds if you choose to not implement an MTI protocol/feature, nobody is going= to come after you and punish you. It is between you and your market. I ful= ly expect some of the WG participants to only implement the non-MTI method. We can absolutely ask the incoming AD for more guidance in this area. I think keeping the two methods within the same document will speed up and = simplify the process, compared to running two docs in parallel. They do hav= e enough commonalities. Thanks, Yaron On 21/03/18 15:42, Marius Scurtescu wrote: Thanks for the summary Phil. Comments inline... On Wed, Mar 21, 2018 at 6:43 AM, Phil Hunt >> wrote: We held a couple of brief sessions over the last couple days. We talked about the issue of breaking up the delivery document, multiple delivery methods, and optionality. Some observations: 1. Yaron indicated that the IETF will likely require one method be MTI (mandatory to implement). It would be very useful to point to other working groups and specs where th= is was the case. What is the mechanism by which a specific delivery method is made MTI? Whic= h meta document specifies that? What happens if a provider is not implementing the MTI delivery method? Wha= t does that exactly mean? Just trying to understand what the process is.. While PUSH has better scale (because it does not need HTTP Long Polling), the POLL method has broader utility due to the presence of receivers with firewalls, gateways (IoT devices), or are mobile applications that cannot implement endpoints to receive HTTP POSTs. To me it is very unlikely that IoT or mobile devices will use POLL (or PUSH= ). They will need some other delivery methods appropriate for their archite= cture. Having the current PUSH or POLL mandatory for these cases does not m= ake sense to me, 2. If POLL is chosen as the MTI method, many will still likely prefer PUSH and so that will likely get implemented sooner by some Many will simply not implement POLL if what they need is PUSH, and vice ver= sa. Again, I don't see how the working group can pick any delivery method a= nd make it MTI. And MTI in what context? Can we escalate this issue within IETF to get guidance? 3. There was a general feeling that the delivery draft should stay as one draft. I don't see how that is helping, but if implementors can chose either PUSH = or POLL from the current draft then that's fine. But in that case splitting= should also be acceptable. Annabelle will present her recommendations at the formal meeting on Friday where we can get broader input. Thanks everyone. Phil Oracle Corporation, Identity Cloud Services Architect @independentid www.independentid.com phil.hunt@oracle.com > _______________________________________________ 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 _______________________________________________ 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 --_000_513001562DE740F88B4166B719D1490Camazoncom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > I don't thin= k anyone can argue with the desire for strong interop and less complexity.<= /span>

We just finished having that exact argument over SET. The apparent con= sensus was that interoperability across profiles was not desired. I would l= ike to see the working group to discuss whether or not profilers and implem= enters expect or want interoperable delivery methods, lest we repeat the same debate. There is little point in= secevents labeling something MTI if only a small subset of people will be = using it.

Similarly I am concerned about the working group trying to bless one m= ethod or the other as MTI in the name of maximizing interoperability withou= t evidence that said method will be used in the majority of deployments, pa= rticularly when there are valid technical reasons to favor either one over the other in different scenario= s.

On Mar 22, 2018, at 11:31 AM, William Denniss <wdenniss@google.com> wrote:


On Thu, Mar 22, 2018 at 10:04 AM Marius Scurtescu <mscurtescu@google.com> wrote:
Hi Yaron,

I don't think anyone can argue with the desire for strong interop and = less complexity.

Wearing our implementor hats, what delivery method would optimally cov= er all use cases? Do we want a delivery method that in theory can cover mos= t use cases, but it is suboptimal for many of them? How would a mobile or I= oT device use the current PUSH or POLL methods?

We are not talking about alternative delivery methods for the same use= case, but different methods for each separate use case. I totally agree th= at as a workinggroup we should support one method per use case, for example= one method for HTTP receivers sitting behind firewalls. I am using "use case" in a generic way, more l= ike "profile".

Why declare one method as MTI when it is clear that it will not work f= or many use cases and that implementors for those use cases will be forced = to ignore the MTI?

Regarding the current delivery draft, why do you think that keeping th= e two methods together is beneficial? The overlap between the two is minima= l. Here are the reasons why I think the draft should be split:

1. The two methods have different maturity levels. The PUSH method is = already implemented and more implementation will come online soon. The POLL= method has no implementation yet, as far as I know. By keeping them togeth= er we hold back one and put pressure to rush the other. That's lose-lose.

2. With two methods in one drafts it is very ambiguous what is MTI. Wi= th two separate drafts each implemetor can chose what works for their use c= ases. Interop will work out based on use cases, I don't think we have to fo= rce it.

The clear message for implementors two years from now would be a clear= description for each method as to what use cases it is applicable to. No c= onfusion at all, if you are behind a firewall then POLL is your only option= . If you are delivering to IoT then whatever method works for that use case (we don't have one yet).

I asked about a meta-document from a practical point of view.. How/whe= re will the MTI delivery method be defined? Same with IETF police, maybe yo= u misunderstood. I am not worried about implementors disregarding recommend= ations. Since the unit for specifications are RFCs, how can some RFC be declared as MTI? In what context? Again, fro= m a practical editorial point of view. 

Speaking to one draft I worked on where we faced this decision, <= /span>PKCE Section 4.2 defined two methods to transform the code challenge, plain text (no transformation= ), and SHA256.

"S256" is declared as MTI in the spec, and "plain" is n= ot. In this case we actually say "Mandatory to Implement", but ga= ting SHA256 with a "MUST" and the "plain" with a "= MAY" would have achieved the same effect.

I advocated for making S256 MTI (when I first reviewed the draft, both were= given equal weighting) so that native app clients would not need to perfor= m discovery on the server to work out which method they can use (and provid= e additional API methods for the developer to specify the transform for servers that don't support discover= y). Since SHA256 is MTI, all native app clients can rely on it being implem= ented.  And that's what AppAuth does, it has no support for "plai= n", and doesn't bother with doing discovery on the PKCE method, which greatly simplified the implementation (and it's = completely seamless to users of AppAuth). As we required MTI on the more se= cure option of the two, this also resulted in more secure implementations b= y default.

YMMV – but that's what we did in that case :-)

 
Guidance would be very useful IMO.

Thanks,
Marius


Marius

On Wed, Mar 21, 2018 at 9:05 AM, Yaron Sheffer <= span dir=3D"ltr"> <yaronf.ietf@= gmail.com> wrote:
Hi Marius,

The decision about whether we need to have an MTI protocol and which one it= should be is up to the WG consensus, like everything else. But with my WG = chair hat on, it is my strong conviction that we need to have one MTI metho= d to encourage interoperability and reduce fragmentation. This is based on my IETF experience, and not on = any meta-document as far as I can tell. Just think of implementers that are= not part of the WG, and just read the RFCs two years from now. They need t= o have a clear message which method will allow them the best (though maybe not perfect) interoperability. Also= , I personally do not have a preference which of the methods becomes MTI.
It is common at the IETF to say that "there is no IETF police", i= n other words if you choose to not implement an MTI protocol/feature, nobod= y is going to come after you and punish you. It is between you and your mar= ket. I fully expect some of the WG participants to only implement the non-MTI method.

We can absolutely ask the incoming AD for more guidance in this area.

I think keeping the two methods within the same document will speed up and = simplify the process, compared to running two docs in parallel. They do hav= e enough commonalities.

Thanks,
        Yaron

On 21/03/18 15:42, Marius Scurtescu wrote:
Thanks for the summary Phil.

Comments inline...

On Wed, Mar 21, 2018 at 6:43 AM, Phil Hunt <phil.hunt@oracle.com <mai= lto:phil.hunt@ora= cle.com>> wrote:

    We held a couple of brief sessions over the last couple days.=

    We talked about the issue of breaking up the delivery documen= t,
    multiple delivery methods, and optionality.

    Some observations:

    1. Yaron indicated that the IETF will likely require one meth= od be
    MTI (mandatory to implement).


It would be very useful to point to other working groups and specs where th= is was the case.

What is the mechanism by which a specific delivery method is made MTI? Whic= h meta document specifies that?

What happens if a provider is not implementing the MTI delivery method? Wha= t does that exactly mean?

Just trying to understand what the process is..


    While PUSH has better scale (because it does not need HTTP Lo= ng
    Polling), the POLL method has broader utility due to the pres= ence of
    receivers with firewalls, gateways (IoT devices), or are mobi= le
    applications that cannot implement endpoints to receive HTTP = POSTs.


To me it is very unlikely that IoT or mobile devices will use POLL (or PUSH= ). They will need some other delivery methods appropriate for their archite= cture. Having the current PUSH or POLL mandatory for these cases does not m= ake sense to me,


    2.  If POLL is chosen as the MTI method, many will still= likely
    prefer PUSH and so that will likely get implemented sooner by= some


Many will simply not implement POLL if what they need is PUSH, and vice ver= sa. Again, I don't see how the working group can pick any delivery method a= nd make it MTI. And MTI in what context?

Can we escalate this issue within IETF to get guidance?



    3.  There was a general feeling that the delivery draft = should stay
    as one draft.


I don't see how that is helping, but if implementors can chose either PUSH = or POLL from the current draft then that's fine. But in that case splitting= should also be acceptable.



    Annabelle will present her recommendations at the formal meet= ing on
    Friday where we can get broader input.

    Thanks everyone.

    Phil

    Oracle Corporation, Identity Cloud Services Architect
    @independentid
    www.independentid.com <http://www.independentid.com>
    phi= l.hunt@oracle.com <mailto:phil.hunt@oracle.com>


    _______________________________________________
    Id-event mailing list
    Id-eve= nt@ietf.org <mailto:Id-event@ietf.org>
    https://www.ietf.org/mailman/listinfo/id-event
    <https://www.ietf.org/mailman/listinf= o/id-event>




_______________________________________________
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
_______________________________________________
Id-event mailing list
Id-event@ietf.org
https://ww= w.ietf.org/mailman/listinfo/id-event
--_000_513001562DE740F88B4166B719D1490Camazoncom_-- From nobody Thu Mar 22 12:03:36 2018 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 6746F126DC2 for ; Thu, 22 Mar 2018 12:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 JLTJHl5-kxFy for ; Thu, 22 Mar 2018 12:03:30 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::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 9A3A81242EA for ; Thu, 22 Mar 2018 12:03:30 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id l123so5884754vke.8 for ; Thu, 22 Mar 2018 12:03:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ik3vMSf20UnbJIirg6nXwcy3v1tqF3p1YEdYpkyqe4U=; b=m3XIUMAN0vkkIiyG8WDE/8ewJJ/jzW+owRlZ31/CmyHRxc8yHZfjITBS9/uz02TtPv sinBKUW5RZ/CJAF1Cgus09ZnuSJtzsj8kpwhksRzjkCDmu9y8STuH5NODGmWR2f61HIL +xEPmhZFHOPCeCtfaxdIdlBk7LANpC21iZfWBm3Lgl2QDK2YNC2f0zU7Db/UDkCmj/EX BAJBaTkmtIo8p+2U048Qwi9SqUXTmTpp/j2fXIsAYAhzrQDNxlriv63TBSA+3O/6Orhw HFoQrpY/XYsELqEkVu9Ni7r7rK0hkuoCjb5/0GRiWSffD8Jrm2E9NA9/ixmX7lYHeDXY czCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ik3vMSf20UnbJIirg6nXwcy3v1tqF3p1YEdYpkyqe4U=; b=J5EdPa11Avl6MdSoNXjUxplVk32PNoeXp1v6Hp9cHsIG/9bC5DAX/dEFyTjeWPfJhV 5vZi2TYt2YVcGp7efR8STJgAI1VDhtHmjGvxFMjPQviOY1MJVyeshFFyaIw4rhz0SopE BKcTYxDkaeRFTmzh14FazWAS2YlwI8743G2EYssajsfeuwUq9Wwzug21yh/o5Kv1UcjT nFkLxxEq98vcOhkoDAXQ3t08JS3L678S0HJ4Jg2NbQ5mp+2ECSOy0b+JnPhBWddrWihQ sW2/chYpVwN8HfPXpgjrt5en1wnzEB8SUxw9dqJSHo/Oot1HabXlp02pE0YAgfsebA1L MJ4w== X-Gm-Message-State: AElRT7Fn/1OMNWX1jqKnB6Ey268/guyevPRFAr7TeZNP2MxOtlkJuirX iRd1K5kOVF9sbdfZrkgU8viFfo4GXTxkpWOPPwSkvg== X-Google-Smtp-Source: AG47ELtQEAKasS9IL1nIMsPQpXrGk+Y+MB0uabb6iOlodsOoSq2qKZvPkZCoNBgYnhdrCHlXXyAXl8DqK17QSBzxaM0= X-Received: by 10.31.156.71 with SMTP id f68mr6444723vke.129.1521745409183; Thu, 22 Mar 2018 12:03:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.171.196 with HTTP; Thu, 22 Mar 2018 12:03:08 -0700 (PDT) In-Reply-To: References: <99920B12-09F2-4293-B214-F766C00CAE6E@oracle.com> <221f7700-d279-1156-1b56-d222b111bce3@gmail.com> From: Marius Scurtescu Date: Thu, 22 Mar 2018 12:03:08 -0700 Message-ID: To: William Denniss Cc: Yaron Sheffer , ID Events Mailing List , Phil Hunt Content-Type: multipart/alternative; boundary="001a1141bffc8e377f056804f66e" Archived-At: Subject: Re: [Id-event] Summary of working session discussion X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 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 Mar 2018 19:03:34 -0000 --001a1141bffc8e377f056804f66e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Mar 22, 2018 at 4:29 AM, William Denniss wrote: > > On Thu, Mar 22, 2018 at 10:04 AM Marius Scurtescu > wrote: > >> Hi Yaron, >> >> I don't think anyone can argue with the desire for strong interop and >> less complexity. >> >> Wearing our implementor hats, what delivery method would optimally cover >> all use cases? Do we want a delivery method that in theory can cover mos= t >> use cases, but it is suboptimal for many of them? How would a mobile or = IoT >> device use the current PUSH or POLL methods? >> >> We are not talking about alternative delivery methods for the same use >> case, but different methods for each separate use case. I totally agree >> that as a workinggroup we should support one method per use case, for >> example one method for HTTP receivers sitting behind firewalls. I am usi= ng >> "use case" in a generic way, more like "profile". >> >> Why declare one method as MTI when it is clear that it will not work for >> many use cases and that implementors for those use cases will be forced = to >> ignore the MTI? >> >> Regarding the current delivery draft, why do you think that keeping the >> two methods together is beneficial? The overlap between the two is minim= al. >> Here are the reasons why I think the draft should be split: >> >> 1. The two methods have different maturity levels. The PUSH method is >> already implemented and more implementation will come online soon. The P= OLL >> method has no implementation yet, as far as I know. By keeping them >> together we hold back one and put pressure to rush the other. That's >> lose-lose. >> >> 2. With two methods in one drafts it is very ambiguous what is MTI. With >> two separate drafts each implemetor can chose what works for their use >> cases. Interop will work out based on use cases, I don't think we have t= o >> force it. >> >> The clear message for implementors two years from now would be a clear >> description for each method as to what use cases it is applicable to. No >> confusion at all, if you are behind a firewall then POLL is your only >> option. If you are delivering to IoT then whatever method works for that >> use case (we don't have one yet). >> >> I asked about a meta-document from a practical point of view.. How/where >> will the MTI delivery method be defined? Same with IETF police, maybe yo= u >> misunderstood. I am not worried about implementors disregarding >> recommendations. Since the unit for specifications are RFCs, how can som= e >> RFC be declared as MTI? In what context? Again, from a practical editori= al >> point of view. >> > > Speaking to one draft I worked on where we faced this decision, PKCE > Section 4.2 defined two > methods to transform the code challenge, plain text (no transformation), > and SHA256. > > "S256" is declared as MTI in the spec, and "plain" is not. In this case w= e > actually say "Mandatory to Implement", but gating SHA256 with a "MUST" an= d > the "plain" with a "MAY" would have achieved the same effect. > > I advocated for making S256 MTI (when I first reviewed the draft, both > were given equal weighting) so that native app clients would not need to > perform discovery on the server to work out which method they can use (an= d > provide additional API methods for the developer to specify the transform > for servers that don't support discovery). Since SHA256 is MTI, all nativ= e > app clients can rely on it being implemented. And that's what AppAuth > does, it has no support for "plain", and doesn't bother with doing > discovery on the PKCE method, which greatly simplified the implementation > (and it's completely seamless to users of AppAuth). As we required MTI on > the more secure option of the two, this also resulted in more secure > implementations by default. > > YMMV =E2=80=93 but that's what we did in that case :-) > Thanks William. Yes, if both delivery methods are described in one draft then the draft maybe declare one MTI and the other not. In this case the MTI is in the context of the draft or RFC, in order to claim that you support the RFC you have to respect the MTI. But if the delivery methods are in separate drafts then I don't see how that can be done. You are claim to support one RFC or the other. This is all technical details on how MTI can be specified. The question if an MTI for delivery methods is desirable or not is totally different. > > > >> Guidance would be very useful IMO. >> >> Thanks, >> Marius >> >> >> Marius >> >> On Wed, Mar 21, 2018 at 9:05 AM, Yaron Sheffer >> wrote: >> >>> Hi Marius, >>> >>> The decision about whether we need to have an MTI protocol and which on= e >>> it should be is up to the WG consensus, like everything else. But with = my >>> WG chair hat on, it is my strong conviction that we need to have one MT= I >>> method to encourage interoperability and reduce fragmentation. This is >>> based on my IETF experience, and not on any meta-document as far as I c= an >>> tell. Just think of implementers that are not part of the WG, and just = read >>> the RFCs two years from now. They need to have a clear message which me= thod >>> will allow them the best (though maybe not perfect) interoperability. A= lso, >>> I personally do not have a preference which of the methods becomes MTI. >>> >>> It is common at the IETF to say that "there is no IETF police", in othe= r >>> words if you choose to not implement an MTI protocol/feature, nobody is >>> going to come after you and punish you. It is between you and your mark= et. >>> I fully expect some of the WG participants to only implement the non-MT= I >>> method. >>> >>> We can absolutely ask the incoming AD for more guidance in this area. >>> >>> I think keeping the two methods within the same document will speed up >>> and simplify the process, compared to running two docs in parallel. The= y do >>> have enough commonalities. >>> >>> Thanks, >>> Yaron >>> >>> On 21/03/18 15:42, Marius Scurtescu wrote: >>> >>>> Thanks for the summary Phil. >>>> >>>> Comments inline... >>>> >>>> On Wed, Mar 21, 2018 at 6:43 AM, Phil Hunt >>> > wrote: >>>> >>>> We held a couple of brief sessions over the last couple days. >>>> >>>> We talked about the issue of breaking up the delivery document, >>>> multiple delivery methods, and optionality. >>>> >>>> Some observations: >>>> >>>> 1. Yaron indicated that the IETF will likely require one method be >>>> MTI (mandatory to implement). >>>> >>>> >>>> It would be very useful to point to other working groups and specs >>>> where this was the case. >>>> >>>> What is the mechanism by which a specific delivery method is made MTI? >>>> Which meta document specifies that? >>>> >>>> What happens if a provider is not implementing the MTI delivery method= ? >>>> What does that exactly mean? >>>> >>>> Just trying to understand what the process is.. >>>> >>>> >>>> While PUSH has better scale (because it does not need HTTP Long >>>> Polling), the POLL method has broader utility due to the presence = of >>>> receivers with firewalls, gateways (IoT devices), or are mobile >>>> applications that cannot implement endpoints to receive HTTP POSTs= . >>>> >>>> >>>> To me it is very unlikely that IoT or mobile devices will use POLL (or >>>> PUSH). They will need some other delivery methods appropriate for thei= r >>>> architecture. Having the current PUSH or POLL mandatory for these case= s >>>> does not make sense to me, >>>> >>>> >>>> 2. If POLL is chosen as the MTI method, many will still likely >>>> prefer PUSH and so that will likely get implemented sooner by some >>>> >>>> >>>> Many will simply not implement POLL if what they need is PUSH, and vic= e >>>> versa. Again, I don't see how the working group can pick any delivery >>>> method and make it MTI. And MTI in what context? >>>> >>>> Can we escalate this issue within IETF to get guidance? >>>> >>>> >>>> >>>> 3. There was a general feeling that the delivery draft should sta= y >>>> as one draft. >>>> >>>> >>>> I don't see how that is helping, but if implementors can chose either >>>> PUSH or POLL from the current draft then that's fine. But in that case >>>> splitting should also be acceptable. >>>> >>>> >>>> >>>> Annabelle will present her recommendations at the formal meeting o= n >>>> Friday where we can get broader input. >>>> >>>> Thanks everyone. >>>> >>>> Phil >>>> >>>> Oracle Corporation, Identity Cloud Services Architect >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>> >>>> >>>> _______________________________________________ >>>> 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 >>>> >>>> >> _______________________________________________ >> Id-event mailing list >> Id-event@ietf.org >> https://www.ietf.org/mailman/listinfo/id-event >> > --001a1141bffc8e377f056804f66e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Mar 22, 2018 at 4:29 AM, William Denniss <wdenniss= @google.com> wrote:

= On Thu, Mar 22, 2018 at 10:04 AM Marius Scurtescu <mscurtescu@google.co= m> wrote:
Hi Yaron,

I do= n't think anyone can argue with the desire for strong interop and less = complexity.

Wearing our implementor hats, what del= ivery method would optimally cover all use cases? Do we want a delivery met= hod that in theory can cover most use cases, but it is suboptimal for many = of them? How would a mobile or IoT device use the current PUSH or POLL meth= ods?

We are not talking about alternative delivery= methods for the same use case, but different methods for each separate use= case. I totally agree that as a workinggroup we should support one method = per use case, for example one method for HTTP receivers sitting behind fire= walls. I am using "use case" in a generic way, more like "pr= ofile".

Why declare one method as MTI when it= is clear that it will not work for many use cases and that implementors fo= r those use cases will be forced to ignore the MTI?

Regarding the current delivery draft, why do you think that keeping the t= wo methods together is beneficial? The overlap between the two is minimal. = Here are the reasons why I think the draft should be split:

<= /div>
1. The two methods have different maturity levels. The PUSH metho= d is already implemented and more implementation will come online soon. The= POLL method has no implementation yet, as far as I know. By keeping them t= ogether we hold back one and put pressure to rush the other. That's los= e-lose.

2. With two methods in one drafts it is ve= ry ambiguous what is MTI. With two separate drafts each implemetor can chos= e what works for their use cases. Interop will work out based on use cases,= I don't think we have to force it.

The clear = message for implementors two years from now would be a clear description fo= r each method as to what use cases it is applicable to. No confusion at all= , if you are behind a firewall then POLL is your only option. If you are de= livering to IoT then whatever method works for that use case (we don't = have one yet).

I asked about a meta-documen= t from a practical point of view.. How/where will the MTI delivery method b= e defined? Same with IETF police, maybe you misunderstood. I am not worried= about implementors disregarding recommendations. Since the unit for specif= ications are RFCs, how can some RFC be declared as MTI? In what context? Ag= ain, from a practical editorial point of view.=C2=A0

Speaking to one draft I worked on = where we faced this decision,=C2=A0PKCE Section 4.2=C2=A0defined two methods to transform the code challe= nge, plain text (no transformation), and SHA256.

"S256" is= declared as MTI in the spec, and "plain" is not. In this case we= actually say "Mandatory to Implement", but gating SHA256 with a = "MUST" and the "plain" with a "MAY" would hav= e achieved the same effect.

I advocated for making S256 MTI (when I f= irst reviewed the draft, both were given equal weighting) so that native ap= p clients would not need to perform discovery on the server to work out whi= ch method they can use (and provide additional API methods for the develope= r to specify the transform for servers that don't support discovery). S= ince SHA256 is MTI, all native app clients can rely on it being implemented= .=C2=A0 And that's what AppAuth does, it has no support for "plain= ", and doesn't bother with doing discovery on the PKCE method, whi= ch greatly simplified the implementation (and it's completely seamless = to users of AppAuth). As we required MTI on the more secure option of the t= wo, this also resulted in more secure implementations by default.

YMMV =E2=80=93 but that's what we did in that case :-)

Thanks William.

Yes, if both delivery methods are described in one draft then the draft = maybe declare one MTI and the other not. In this case the MTI is in the con= text of the draft or RFC, in order to claim that you support the RFC you ha= ve to respect the MTI.

But if the delivery methods= are in separate drafts then I don't see how that can be done. You are = claim to support one RFC or the other.

This is all= technical details on how MTI can be specified. The question if an MTI for = delivery methods is desirable or not is totally different.

=C2=A0

=C2=A0
Guidance would be very useful IMO.

Thanks= ,
Marius

Marius

On Wed, Mar 21, 2018 at 9:05 AM, Yaron Sheff= er <yaronf.ietf@gmail.com> wrote:
Hi Marius,

The decision about whether we need to have an MTI protocol and which one it= should be is up to the WG consensus, like everything else. But with my WG = chair hat on, it is my strong conviction that we need to have one MTI metho= d to encourage interoperability and reduce fragmentation. This is based on = my IETF experience, and not on any meta-document as far as I can tell. Just= think of implementers that are not part of the WG, and just read the RFCs = two years from now. They need to have a clear message which method will all= ow them the best (though maybe not perfect) interoperability. Also, I perso= nally do not have a preference which of the methods becomes MTI.

It is common at the IETF to say that "there is no IETF police", i= n other words if you choose to not implement an MTI protocol/feature, nobod= y is going to come after you and punish you. It is between you and your mar= ket. I fully expect some of the WG participants to only implement the non-M= TI method.

We can absolutely ask the incoming AD for more guidance in this area.

I think keeping the two methods within the same document will speed up and = simplify the process, compared to running two docs in parallel. They do hav= e enough commonalities.

Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Yaron

On 21/03/18 15:42, Marius Scurtescu wrote:
Thanks for the summary Phil.

Comments inline...

 On Wed, Mar 21, 2018 at 6:43 AM, Phil Hunt <phil.hunt@oracle.com <= ;mailto:phil.hunt@oracle.com>> wrote:

=C2=A0 =C2=A0 We held a couple of brief sessions over the last couple days.=

=C2=A0 =C2=A0 We talked about the issue of breaking up the delivery documen= t,
=C2=A0 =C2=A0 multiple delivery methods, and optionality.

=C2=A0 =C2=A0 Some observations:

=C2=A0 =C2=A0 1. Yaron indicated that the IETF will likely require one meth= od be
=C2=A0 =C2=A0 MTI (mandatory to implement).


It would be very useful to point to other working groups and specs where th= is was the case.

What is the mechanism by which a specific delivery method is made MTI? Whic= h meta document specifies that?

What happens if a provider is not implementing the MTI delivery method? Wha= t does that exactly mean?

 Just trying to understand what the process is..


=C2=A0 =C2=A0 While PUSH has better scale (because it does not need HTTP Lo= ng
=C2=A0 =C2=A0 Polling), the POLL method has broader utility due to the pres= ence of
=C2=A0 =C2=A0 receivers with firewalls, gateways (IoT devices), or are mobi= le
=C2=A0 =C2=A0 applications that cannot implement endpoints to receive HTTP = POSTs.


To me it is very unlikely that IoT or mobile devices will use POLL (or PUSH= ). They will need some other delivery methods appropriate for their archite= cture. Having the current PUSH or POLL mandatory for these cases does not m= ake sense to me,


=C2=A0 =C2=A0 2.=C2=A0 If POLL is chosen as the MTI method, many will still= likely
=C2=A0 =C2=A0 prefer PUSH and so that will likely get implemented sooner by= some


Many will simply not implement POLL if what they need is PUSH, and vice ver= sa. Again, I don't see how the working group can pick any delivery meth= od and make it MTI. And MTI in what context?

Can we escalate this issue within IETF to get guidance?



=C2=A0 =C2=A0 3.=C2=A0 There was a general feeling that the delivery draft = should stay
=C2=A0 =C2=A0 as one draft.


I don't see how that is helping, but if implementors can chose either P= USH or POLL from the current draft then that's fine. But in that case s= plitting should also be acceptable.



=C2=A0 =C2=A0 Annabelle will present her recommendations at the formal meet= ing on
=C2=A0 =C2=A0 Friday where we can get broader input.

=C2=A0 =C2=A0 Thanks everyone.

=C2=A0 =C2=A0 Phil

=C2=A0 =C2=A0 Oracle Corporation, Identity Cloud Services Architect
=C2=A0 =C2=A0 @independentid
 =C2=A0 =C2=A0 www.independentid.com <http://www.independentid.com>
=C2=A0 =C2=A0 phil.hunt@oracle.com <mailto:phil.hunt@oracle.com&= gt;


=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 Id-event mailing list
=C2=A0 =C2=A0 Id-event@ietf.org <mailto:Id-event@ietf.org>
=C2=A0 =C2=A0 https://www.ietf.org/ma= ilman/listinfo/id-event
=C2=A0 =C2=A0 <https://www.ietf.or= g/mailman/listinfo/id-event>




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


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

--001a1141bffc8e377f056804f66e-- From nobody Thu Mar 22 12:26:57 2018 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 CBC6D126E01 for ; Thu, 22 Mar 2018 12:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 KmWcMZuNtIB7 for ; Thu, 22 Mar 2018 12:26:53 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::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 62206126DCA for ; Thu, 22 Mar 2018 12:26:53 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id g192so5945503vkd.3 for ; Thu, 22 Mar 2018 12:26:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gcD4p765t0dliOD58CKlqamuJ4naHG/mggQUnanwiyI=; b=V4+zItW0McOJ7cc0nV808Mp8imHO0dgaCM3VoAwvTsbxonVk+aCR+aJHUnE5fX+yuZ JVcxMr0c2ozWbb3MHs57m1iVRp79s6xul7z69cJSrkva2zJDUGP1Wleofn5Bj8CoHRtw w0xsIFz+CmhX8SPb09B5Opujgp6xrdFdtrErTJF1COstdea98wni0o4FuPp10NDDynqW 4F/onxo6bGcSkMiGKItPcsaEwB18Cs5aUK2qvpjSLBIqfJgYamLF/mXfPey/qxITFIt5 sTZdd6900TY16hmKL4laI7xtIV0xUYMRuIiLZZVKzvHUD6+FaT1Rayba7AaqNf8xsqct weog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gcD4p765t0dliOD58CKlqamuJ4naHG/mggQUnanwiyI=; b=JvBF95KTx7YkrjhWvgyuAab1irAv56v6QdFNdnLeZxvi/Fm1qOHepqHQ9m0zCgIxNd bAPZlTAUUwueChR+dIgmvtQj36c0KDg3bFeeR6zy/k3jTN8XjDpsLIk88G/oXALcVBfG bS1+wigEHQe29KaQ1BTgqLBfi1sNsbRi+ATc09YMRroxIIPL6lLN9rcEaSEe/0a7OXPm m4att8aUcwHmhuC3xSROC8uKbZI4SU0UA4xa75hzvv31mLMy/j6dSbWDasEL1x9dwSvb J65dTiBMQERUF7ECTUlxVcHl/Jw/Di3DK4EEIwSgE+GfKpmN3MYdtEHf5vISTrt1EIWO HwUQ== X-Gm-Message-State: AElRT7FC1fJCXgv1c+Lez6AgNNS0bFzx4fCjnTgZrCAOJLNUYfYR7RgG 6BjgNyJN8BXmHgCtLzPcDid6xqcw2JnS4zL11pgjxg== X-Google-Smtp-Source: AG47ELtLPv0oQdEZ9bV2+yofkZ2E/1YJQW8vjwiZpP3w2SFqMo9SYOwi5ep//4VddZ1M97O2ylCBpNC1tGsXqJujwOI= X-Received: by 10.31.155.150 with SMTP id d144mr11828524vke.112.1521746811838; Thu, 22 Mar 2018 12:26:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.171.196 with HTTP; Thu, 22 Mar 2018 12:26:31 -0700 (PDT) In-Reply-To: References: From: Marius Scurtescu Date: Thu, 22 Mar 2018 12:26:31 -0700 Message-ID: To: Mike Jones , Leif Johansson Cc: ID Events Mailing List Content-Type: multipart/alternative; boundary="001a1141f92e294fbf0568054a09" Archived-At: Subject: Re: [Id-event] "exp" claim in draft-ietf-secevent-token-07 X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 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 Mar 2018 19:26:56 -0000 --001a1141f92e294fbf0568054a09 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Leif, I believe you raised this issue at a past meeting. Do you have any thoughts? Comments inline... On Thu, Mar 22, 2018 at 3:29 AM, Mike Jones wrote: > To me, it seems that trying to mandate that an expiration time be sent > when there is no natural expiration time for the information is odd at > best, and counterproductive at worst. We should not encourage deployers = to > have to =E2=80=9Cinvent=E2=80=9D arbitrarily chosen values and include th= em as claims to > satisfy a MUST that shouldn=E2=80=99t have been there. > "exp" does not apply to the event(s), it applies to the envelope, same as "iat". Here is the definition from RFC 7519: "The "exp" (expiration time) claim identifies the expiration time on or after which the JWT MUST NOT be accepted for processing." Transmitters don't "invent" the value, the value falls out of re-try parameters and the specific delivery method used. Are IdPs inventing the exp in an Id Token? Also, "exp" in a SET should probably be "RECOMMENDED" and not "MUST". > > Caching decisions are highly deployment specific. They could, for > instance, be based on a deployment-specified delta from the =E2=80=9Ciat= =E2=80=9D (issued > at) value and not use =E2=80=9Cexp=E2=80=9D at all. > For sure, but an exp claim makes the whole process more secure. A receiver may decide to cache for 2 minutes (and not accept SETs older than 2 minutes, hopefully), but a transmitter my keep re-trying to send events for 10 minutes. Many things can go wrong if exp is not present. > > > With respect to =E2=80=9Cexp=E2=80=9D, I think the spec already has it ri= ght for the > general case. Of course, it=E2=80=99s fine for particular Profiling Spec= ifications > to require that =E2=80=9Cexp=E2=80=9D be present and define constraints t= hat the claim > value must satisfy for deployments using that profile=E2=80=A6 > Yaron just raised concerns about interop, pushing this issue to profiles is not helping interop IMO. > > > -- Mike > > > > *From:* Id-event *On Behalf Of *Marius > Scurtescu > *Sent:* Thursday, March 22, 2018 3:49 AM > *To:* ID Events Mailing List > *Subject:* [Id-event] "exp" claim in draft-ietf-secevent-token-07 > > > > Section 2.2 for "exp" states: > > > > "this claim is the time after which the JWT MUST NOT be accepted for > processing. In the context of a SET however, this notion does not > typically apply, since a SET represents something that has already occurr= ed > and is historical in nature. Therefore, its use is NOT RECOMMENDED." > > > > Similarly, section 4.5 makes recommendations against "exp". > > > > At IETF 100 in Singapore we briefly talked about this and the following > problem came up: without "exp" how long should a receiver cache "jti" > values to prevent double submissions (and replay attacks)? > > > > Today the same problem was raised as implementation feedback. > > > > It seems that "exp" should rather be required. Thoughts? > > > > What happens to section 4.5 if "exp" is required? > > > > Also, a required (or recommended) "exp" leads to implementation challenge= s > when it comes to delivery. A transmitter that is retrying to deliver > unconfirmed SETs, will have to probably re-mint them on each delivery > attempt, as opposed to simply cache a minted SET and keep retrying with > that. Or the transmitter will have to set an expiration period longer tha= n > the retry period, but long expiration periods put bigger loads on receive= rs > (larger cache). > > > > Any chance this can be discussed on Friday? > > > > Marius > --001a1141f92e294fbf0568054a09 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Leif= , I believe you raised this issue at a past meeting. Do you have any though= ts?

Co= mments inline...

On Thu, Mar 22, 2018 at 3:29 AM, Mike Jones &l= t;Michael.J= ones@microsoft.com> wrote:

To me, it seems t= hat trying to mandate that an expiration time be sent when there is no natu= ral expiration time for the information is odd at best, and counterproducti= ve at worst.=C2=A0 We should not encourage deployers to have to =E2=80=9Cinvent=E2=80=9D arbitrarily chosen values and include = them as claims to satisfy a MUST that shouldn=E2=80=99t have been there.


"exp" does n= ot apply to the event(s), it applies to the envelope, same as "iat&quo= t;. Here is the definition from RFC 7519:
"The "exp&quo= t; (expiration time) claim identifies the expiration time on or after which= the JWT MUST NOT be accepted for processing."

Transmitters don't "invent" the value, the value falls out = of re-try parameters and the specific delivery method used. Are IdPs invent= ing the exp in an Id Token?

Also, "exp" = in a SET should probably be "RECOMMENDED" and not "MUST"= ;.


=C2=A0<= /u>

Caching decisions= are highly deployment specific.=C2=A0 They could, for instance, be based o= n a deployment-specified delta from the =E2=80=9Ciat=E2=80=9D (issued at) v= alue and not use =E2=80=9Cexp=E2=80=9D at all.


For sure, but an exp claim makes the whole proce= ss more secure. A receiver may decide to cache for 2 minutes (and not accep= t SETs older than 2 minutes, hopefully), but a transmitter my keep re-tryin= g to send events for 10 minutes. Many things can go wrong if exp is not pre= sent.

=C2=A0

=C2=A0<= /u>

With respect to = =E2=80=9Cexp=E2=80=9D, I think the spec already has it right for the genera= l case.=C2=A0 Of course, it=E2=80=99s fine for particular Profiling Specifi= cations to require that =E2=80=9Cexp=E2=80=9D be present and define constra= ints that the claim value must satisfy for deployments using that profile=E2=80=A6


Yaron just raised concern= s about interop, pushing this issue to profiles is not helping interop IMO.=
=C2=A0

=C2=A0<= /u>

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 -- Mike

=C2=A0<= /u>

From: Id-event <id-event-bounces@ietf.org> On= Behalf Of Marius Scurtescu
Sent: Thursday, March 22, 2018 3:49 AM
To: ID Events Mailing List <id-event@ietf.org>
Subject: [Id-event] "exp" claim in draft-ietf-secevent-tok= en-07

=C2=A0

Section 2.2 for "exp" states:

=C2=A0

"this claim is the time after which the JWT MUS= T NOT be accepted for processing.=C2=A0 In the context of a SET however, th= is notion does not typically apply, since a SET represents something that h= as already occurred and is historical in nature. Therefore, its use is NOT RECOMMENDED."

=C2=A0

Similarly, section 4.5 makes recommendations against= "exp".

=C2=A0

At IETF 100 in Singapore we briefly talked about thi= s and the following problem came up: without "exp" how long shoul= d a receiver cache "jti" values to prevent double submissions (an= d replay attacks)?

=C2=A0

Today the same problem was raised as implementation = feedback.

=C2=A0

It seems that "exp" should rather be requi= red. Thoughts?

=C2=A0

What happens to section 4.5 if "exp" is re= quired?

=C2=A0

Also, a required (or recommended) "exp" le= ads to implementation challenges when it comes to delivery. A transmitter t= hat is retrying to deliver unconfirmed SETs, will have to probably re-mint = them on each delivery attempt, as opposed to simply cache a minted SET and keep retrying with that. Or the transmitter = will have to set an expiration period longer than the retry period, but lon= g expiration periods put bigger loads on receivers (larger cache).

=C2=A0

Any chance this can be discussed on Friday?

=C2=A0

Marius


--001a1141f92e294fbf0568054a09-- From nobody Thu Mar 22 12:29:41 2018 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 6D738126DCA for ; Thu, 22 Mar 2018 12:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 L992rWvS1Ns3 for ; Thu, 22 Mar 2018 12:29:35 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F7DB126E01 for ; Thu, 22 Mar 2018 12:29:35 -0700 (PDT) Received: by mail-vk0-x22a.google.com with SMTP id l123so5932579vke.8 for ; Thu, 22 Mar 2018 12:29:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NAr1pStcHefNGSSdaGEvqITKLYZqwt1xsyWcZasiYuo=; b=BTapY6y2bj+IDXbDP6m51Sj6udahBujxKujq3zZRDqwag3mbTPYMx5Zn4GZR3QeWgi /mYBkjp2jLfALObRAtXcRy4I53zT3SwJNqu6oErlsDNKew5AP3cSYaY6b9P8WeMVfkGa 36Trz4aTmblHMljLMVYg3I5lw+HBxLVmGpC7qxxZX/brGm5aMBvY9LFlDsNm/1PfJhO6 Vm3BGnWQURpgz89qeuJEIEGR4WWMdZVXidRIKYTmLlEsO8a3j5W/06t+FBsM0ZJ8HXV8 BSuuEvbNMLjQjKj+fBi9Hlq5aG46XS5VVGkv44FrMHbXV2w35KgLDc4tYK5I5s/J8PYu 4GTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NAr1pStcHefNGSSdaGEvqITKLYZqwt1xsyWcZasiYuo=; b=YtxLkCuzHT9KwAnYKwD+X0wvz4vYt8S29QEQ/q7u0VFlSYe2Q8W2DJmkhT37vfDDfA +cpsDj/z3l+pn3c6l4IlVxE8uMUDZC78tBDvkzY5ZqoSthrsoFLX0R9sYn5DyTFISR8j 66d2msohcNYyby0NXbr+YowvKELeV2WqxMS0XLoi78AI9Ea6vnxByd6z6YXd+8yL3Qgv 1aVSysmSvb/XRzucAj2wsP99v8/ic7hYfp1Z5mRA+B5JsES3IKqvk9jVKFa7ni/IvYNr xucUvLbgWjMDk8Kc9cH1KwYneEzGSyPvXnRn5y5QuG5AEfp+nPHALqnngXoQHXJmEH59 VkFg== X-Gm-Message-State: AElRT7GUuNzWE50bemxzu4zDbkD/oKPV7UWn/ozCufZIKq75fvGXfU8S mwbn2qcOPDYmjv7977YxOgr90FO48H2TqgnwxZrbMA== X-Google-Smtp-Source: AG47ELtBAHXFmY6eoMPEZfJV3Whh521Sffh/e9Gd9Gok85Nmj7zMfNVnOJGPlLQX0q8hg7BVnZmZPjOYIQ2SZLdQFTM= X-Received: by 10.31.54.4 with SMTP id d4mr9430491vka.33.1521746974052; Thu, 22 Mar 2018 12:29:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.171.196 with HTTP; Thu, 22 Mar 2018 12:29:13 -0700 (PDT) In-Reply-To: <426BBCAA-59AC-44CF-8937-6AFCE1C12383@oracle.com> References: <426BBCAA-59AC-44CF-8937-6AFCE1C12383@oracle.com> From: Marius Scurtescu Date: Thu, 22 Mar 2018 12:29:13 -0700 Message-ID: To: Phil Hunt Cc: Mike Jones , ID Events Mailing List Content-Type: multipart/alternative; boundary="001a11440216d44e4a05680553b0" Archived-At: Subject: Re: [Id-event] "exp" claim in draft-ietf-secevent-token-07 X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 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 Mar 2018 19:29:39 -0000 --001a11440216d44e4a05680553b0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Mar 22, 2018 at 3:41 AM, Phil Hunt wrote: > There are also a number of security considerations in the draft regarding > use of =E2=80=9Cexp=E2=80=9D and differentiation from access tokens that = are important. > Yes, of course. That's why I mentioned section 4.5. I don't think we should fix the id token confusion problem by introducing a replay attack problem. > > Phil > > On Mar 22, 2018, at 10:29 AM, Mike Jones > wrote: > > To me, it seems that trying to mandate that an expiration time be sent > when there is no natural expiration time for the information is odd at > best, and counterproductive at worst. We should not encourage deployers = to > have to =E2=80=9Cinvent=E2=80=9D arbitrarily chosen values and include th= em as claims to > satisfy a MUST that shouldn=E2=80=99t have been there. > > > > Caching decisions are highly deployment specific. They could, for > instance, be based on a deployment-specified delta from the =E2=80=9Ciat= =E2=80=9D (issued > at) value and not use =E2=80=9Cexp=E2=80=9D at all. > > > > With respect to =E2=80=9Cexp=E2=80=9D, I think the spec already has it ri= ght for the > general case. Of course, it=E2=80=99s fine for particular Profiling Spec= ifications > to require that =E2=80=9Cexp=E2=80=9D be present and define constraints t= hat the claim > value must satisfy for deployments using that profile=E2=80=A6 > > > > -- Mike > > > > *From:* Id-event *On Behalf Of *Marius > Scurtescu > *Sent:* Thursday, March 22, 2018 3:49 AM > *To:* ID Events Mailing List > *Subject:* [Id-event] "exp" claim in draft-ietf-secevent-token-07 > > > > Section 2.2 for "exp" states: > > > > "this claim is the time after which the JWT MUST NOT be accepted for > processing. In the context of a SET however, this notion does not > typically apply, since a SET represents something that has already occurr= ed > and is historical in nature. Therefore, its use is NOT RECOMMENDED." > > > > Similarly, section 4.5 makes recommendations against "exp". > > > > At IETF 100 in Singapore we briefly talked about this and the following > problem came up: without "exp" how long should a receiver cache "jti" > values to prevent double submissions (and replay attacks)? > > > > Today the same problem was raised as implementation feedback. > > > > It seems that "exp" should rather be required. Thoughts? > > > > What happens to section 4.5 if "exp" is required? > > > > Also, a required (or recommended) "exp" leads to implementation challenge= s > when it comes to delivery. A transmitter that is retrying to deliver > unconfirmed SETs, will have to probably re-mint them on each delivery > attempt, as opposed to simply cache a minted SET and keep retrying with > that. Or the transmitter will have to set an expiration period longer tha= n > the retry period, but long expiration periods put bigger loads on receive= rs > (larger cache). > > > > Any chance this can be discussed on Friday? > > > > Marius > > _______________________________________________ > Id-event mailing list > Id-event@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www. > ietf.org_mailman_listinfo_id-2Devent&d=3DDwICAg&c=3D > RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=3D > na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DQQOgQSojDGJSe_ > 9Lg0oGRRneEiqaQvngT0E72naO7dw&s=3D6ko84GUvrZOLjdLorjYhGWnlDd8x_ > j2zTLxeEESL56c&e=3D > > --001a11440216d44e4a05680553b0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Mar 22, 2018 at 3:41 AM, Phil Hunt <phil.hunt@orac= le.com> wrote:
There are also a number of security considerations in the draft regar= ding use of =E2=80=9Cexp=E2=80=9D and differentiation from access tokens th= at are important.=C2=A0

Yes, of c= ourse. That's why I mentioned section 4.5.

I d= on't think we should fix the id token confusion problem by introducing = a replay attack problem.

=C2=A0

Phil

On Mar 22, 2018= , at 10:29 AM, Mike Jones <Michael.Jones@microsoft.com> wr= ote:

To me, it seems that t= rying to mandate that an expiration time be sent when there is no natural e= xpiration time for the information is odd at best, and counterproductive at= worst.=C2=A0 We should not encourage deployers to have to =E2=80=9Cinvent=E2=80=9D arbitrarily chosen values and include = them as claims to satisfy a MUST that shouldn=E2=80=99t have been there.=

=C2=A0

Caching decisions are = highly deployment specific.=C2=A0 They could, for instance, be based on a d= eployment-specified delta from the =E2=80=9Ciat=E2=80=9D (issued at) value = and not use =E2=80=9Cexp=E2=80=9D at all.

=C2=A0

With respect to =E2=80= =9Cexp=E2=80=9D, I think the spec already has it right for the general case= .=C2=A0 Of course, it=E2=80=99s fine for particular Profiling Specification= s to require that =E2=80=9Cexp=E2=80=9D be present and define constraints t= hat the claim value must satisfy for deployments using that profile=E2=80=A6

=C2=A0

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=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: Id-event <id-event-bounces@ietf= .org> On Behalf Of Marius Scurtescu
Sent: Thursday, March 22, 2018 3:49 AM
To: ID Events Mailing List <id-event@ietf.org>
Subject: [Id-event] "exp" claim in draft-ietf-secevent-tok= en-07

=C2=A0

Section 2.2 for "exp" states:

=C2=A0

"this claim is the time after which the JWT MUS= T NOT be accepted for processing.=C2=A0 In the context of a SET however, th= is notion does not typically apply, since a SET represents something that h= as already occurred and is historical in nature. Therefore, its use is NOT RECOMMENDED."

=C2=A0

Similarly, section 4.5 makes recommendations against= "exp".

=C2=A0

At IETF 100 in Singapore we briefly talked about thi= s and the following problem came up: without "exp" how long shoul= d a receiver cache "jti" values to prevent double submissions (an= d replay attacks)?

=C2=A0

Today the same problem was raised as implementation = feedback.

=C2=A0

It seems that "exp" should rather be requi= red. Thoughts?

=C2=A0

What happens to section 4.5 if "exp" is re= quired?

=C2=A0

Also, a required (or recommended) "exp" le= ads to implementation challenges when it comes to delivery. A transmitter t= hat is retrying to deliver unconfirmed SETs, will have to probably re-mint = them on each delivery attempt, as opposed to simply cache a minted SET and keep retrying with that. Or the transmitter = will have to set an expiration period longer than the retry period, but lon= g expiration periods put bigger loads on receivers (larger cache).

=C2=A0

Any chance this can be discussed on Friday?

=C2=A0

Marius


--001a11440216d44e4a05680553b0-- From nobody Thu Mar 22 13:59:08 2018 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 6DA0B12704A for ; Thu, 22 Mar 2018 13:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IrAjMgg42akr for ; Thu, 22 Mar 2018 13:59:05 -0700 (PDT) Received: from aserp2130.oracle.com (aserp2130.oracle.com [141.146.126.79]) (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 16CB812426E for ; Thu, 22 Mar 2018 13:59:05 -0700 (PDT) Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w2MKruWU026541 for ; Thu, 22 Mar 2018 20:59:04 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : content-type : mime-version : subject : message-id : references : to : date; s=corp-2017-10-26; bh=XxUDCfQtuiV1vYtMMNv+FXyRT50vQ8756KcEhPX8XQ8=; b=o9CuBpgExrhQ2BG7BQlUBH+mYIV+DLnTtY3Mnry/ki7WCgDeunlVe5RSsUpoVSeYZ49O JjXYQbhDqZgqE/LShtCx2EV2nQnToxoMepMDLv558Kn17EUOtChQHOtLhxlD58vfFtPE mXm/a6oHZqeggGmrnP1eE69JUA1ZVqloE3MnLJZvQ9B3s3/BByGkIgpDeJdma1BfAatW BnHHaGzgv8yq//iFK1KVoPTWDPlVw2NwVH7x0FTeIW0+sJ1U4H9mIMIaOKykz9tjmV2h LlwTi4p/WvUE3qJCeFUYzvOwE+jar67gJKtl/biqJ7oVVeqcUbvgWR2zVz3/bw4dMdCW 5A== Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp2130.oracle.com with ESMTP id 2gvkx6r0j4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 22 Mar 2018 20:59:04 +0000 Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w2MKx3Gx009103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 22 Mar 2018 20:59:03 GMT Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w2MKx3gF031799 for ; Thu, 22 Mar 2018 20:59:03 GMT Received: from dhcp-9f83.meeting.ietf.org (/31.133.159.131) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 22 Mar 2018 13:59:02 -0700 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_1F0B05C3-C183-49DB-AC4A-89B25A0995DC" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Message-Id: <0593CC97-8C1E-458B-8058-2F13A45F66B3@oracle.com> References: <152171640180.5660.17714250144971599335.idtracker@ietfa.amsl.com> To: ID Events Mailing List Date: Thu, 22 Mar 2018 20:59:07 +0000 X-Mailer: Apple Mail (2.3445.5.20) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8840 signatures=668695 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803200127 Archived-At: Subject: [Id-event] Fwd: New Version Notification for draft-hunt-secevent-sstp-00.txt X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 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 Mar 2018 20:59:07 -0000 --Apple-Mail=_1F0B05C3-C183-49DB-AC4A-89B25A0995DC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Given the discussion around having a single MTI method for SET Delivery, = and consensus issue emerging on choosing PUSH or PULL for MTI, this = draft is submitted as a *compromise* which merges both methods into a = single =E2=80=9Csymmetric=E2=80=9D approach capable of addressing both = communities concerns and all use cases. The draft has 3 examples which = show how PULL-only, PUSH-only, and how PUSH-PULL may be accomplished = using the unified approach. Whether =E2=80=9Cpushing=E2=80=9D (e.g. from an issuer to a receiver = HTTP endpoint) or =E2=80=9Cpulling=E2=80=9D (by a receiver from an = issuer HTTP endpoint), the same transfer and response methods and = formats are always used. Because delivery can be either direction or = both directions, the sender and receiver are free to choose role as HTTP = Client or Server based on the environmental and network restrictions = they face. Where possible, we have kept the protocol signalling and responses the = same or simpler. Three changes in particular:=20 * Transmitter/receiver terminology is dropped (due to bi-directionality) = and replaced with HTTP Client vs. HTTP/SSTP Server. (non-normative) * Both pushers and pullers use the same multi-SET format. (normative = change for PUSH) * The flag maxEvents=3DN is now replaced with a simple boolean = returnEvents and now also allows the HTTP client to indicate it does not = want to pull events=20 Previous features and capability(such as multi-threading) = characteristics have been preserved. For example, error signalling was = the same for both methods and remains the same. Tony and I recognize that as separate methods, there could be more = optimization. For example, in PUSH mode, receivers now have to process a = JSON structure that contains multiple SETs vs. just parsing one set. We = considered preserving single-event (application/jwt) format, and could = still do so. However, having multiple content-types seems to add = unnecessary complexity and more implementer coding. Best Regards, Phil Oracle Corporation, Identity Cloud Services Architect @independentid www.independentid.com = phil.hunt@oracle.com = > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-hunt-secevent-sstp-00.txt > Date: March 22, 2018 at 11:00:01 AM GMT > To: "Phil Hunt" , "Anthony Nadalin" = >=20 >=20 > A new version of I-D, draft-hunt-secevent-sstp-00.txt > has been successfully submitted by Phil Hunt and posted to the > IETF repository. >=20 > Name: draft-hunt-secevent-sstp > Revision: 00 > Title: Symmetric SET Transfer Protocol > Document date: 2018-03-22 > Group: Individual Submission > Pages: 23 > URL: = https://www.ietf.org/internet-drafts/draft-hunt-secevent-sstp-00.txt > Status: = https://datatracker.ietf.org/doc/draft-hunt-secevent-sstp/ > Htmlized: = https://tools.ietf.org/html/draft-hunt-secevent-sstp-00 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-hunt-secevent-sstp >=20 >=20 > Abstract: > This specification defines how security event tokens (SETs) may be > exchanged between a client and service provider using HTTP POST over > TLS using a symmetric format. The specification supports three = modes > of operation: "push", "pull", and "push-pull" bi-directional SET > exchange. The specification also defines a simple acknowledge > mechanism allowing parties to confirm delivery. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail=_1F0B05C3-C183-49DB-AC4A-89B25A0995DC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Given= the discussion around having a single MTI method for SET Delivery, and = consensus issue emerging on choosing PUSH or PULL for MTI, this draft is = submitted as a *compromise* which merges both methods into a single = =E2=80=9Csymmetric=E2=80=9D approach capable of addressing both = communities concerns and all use cases. The draft has 3 examples which = show how PULL-only, PUSH-only, and how PUSH-PULL may be accomplished = using the unified approach.

Whether =E2=80=9Cpushing=E2=80=9D= (e.g. from an issuer to a receiver HTTP endpoint) or =E2=80=9Cpulling=E2=80= =9D (by a receiver from an issuer HTTP endpoint), the same transfer and = response methods and formats are always used.  Because delivery can = be either direction or both directions, the sender and receiver are free = to choose role as HTTP Client or Server based on the environmental and = network restrictions they face.

Where possible, we have kept the = protocol signalling and responses the same or simpler. Three changes in = particular: 
* Transmitter/receiver = terminology is dropped (due to bi-directionality) and replaced with HTTP = Client vs. HTTP/SSTP Server. (non-normative)
* Both = pushers and pullers use the same multi-SET format.  (normative = change for PUSH)
* The flag maxEvents=3DN is now = replaced with a simple boolean returnEvents and now also allows the HTTP = client to indicate it does not want to pull events 

Previous features and = capability(such as multi-threading) characteristics have been preserved. = For example, error signalling was the same for both methods and remains = the same.

Tony = and I recognize that as separate methods, there could be more = optimization. For example, in PUSH mode, receivers now have to process a = JSON structure that contains multiple SETs vs. just parsing one set. We = considered preserving single-event (application/jwt) format, and could = still do so. However, having multiple content-types seems to add = unnecessary complexity and more implementer coding.

Best Regards,

Phil

Oracle Corporation, Identity Cloud = Services Architect
@independentid
www.independentid.com
phil.hunt@oracle.com

Begin forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-hunt-secevent-sstp-00.txt
Date: = March 22, 2018 at 11:00:01 AM = GMT
To: = "Phil Hunt" <phil.hunt@yahoo.com>, "Anthony Nadalin" <tonynad@microsoft.com>


A new version = of I-D, draft-hunt-secevent-sstp-00.txt
has been = successfully submitted by Phil Hunt and posted to the
IETF = repository.

Name: = draft-hunt-secevent-sstp
Revision: 00
Title:= = Symmetric SET Transfer Protocol
Document date: = 2018-03-22
Group: Individual Submission
Pages:= = 23
URL: =            https://www.ietf.org/internet-drafts/draft-hunt-secevent-sstp-0= 0.txt
Status: =         https://datatracker.ietf.org/doc/draft-hunt-secevent-sstp/<= br class=3D"">Htmlized:       https://tools.ietf.org/html/draft-hunt-secevent-sstp-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-hunt-secevent-sstp<= /a>


Abstract:
=   This specification defines how security event tokens (SETs) = may be
  exchanged between a client and service = provider using HTTP POST over
  TLS using a = symmetric format.  The specification supports three modes
  of operation: "push", "pull", and "push-pull" = bi-directional SET
  exchange.  The = specification also defines a simple acknowledge
=   mechanism allowing parties to confirm delivery.




Please note that it may take a couple of minutes from the = time of submission
until the htmlized version and diff are = available at tools.ietf.org.

The IETF = Secretariat


= --Apple-Mail=_1F0B05C3-C183-49DB-AC4A-89B25A0995DC-- From nobody Thu Mar 22 16:09:01 2018 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 DBD081270A0 for ; Thu, 22 Mar 2018 16:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 idU8iXZgh0dQ for ; Thu, 22 Mar 2018 16:08:57 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DF6F124D6C for ; Thu, 22 Mar 2018 16:08:56 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id f68so6275797vke.5 for ; Thu, 22 Mar 2018 16:08:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=U3ReJZvpxNRbdZRxyQuSqTWC/nIp5geNtR/t8iXirGI=; b=jNg04oAnW9KybVy14cGj8b6bleyQkAuba8VCFxaWMIWcoB6G1LpBU5ChPKs2Pq9Upy Sev1Ww77trBQvKazEJ3rzasQf0pSRZEqvCvM9peDT7gZZxfbO1Zxulp5Goo8NC6N3na4 /MO/ldJj9yiiGMteSck0ZO5B/Qr2FK8GcpZkGc/gnzviAWZvXmfj4q2sNS/47scs/1gu 4KScMlxvOdiuY4Uc8hdSh6iAd8GC0McZ4sx/LY76z1+9/CWZwedNPXrrthalcJGKD675 V7ra042YFVnkxYSS59QklXi9QT0A+iaw5XPJax1gm4QXq/xOKK6xJAInFjVUZIv4HohT IA7Q== 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=U3ReJZvpxNRbdZRxyQuSqTWC/nIp5geNtR/t8iXirGI=; b=qa5C3qZxlK+LFqir7+udJP3qO62vMUpu/TLhPu38hdj1AEEsih01IvM2M7V4z4qYmj F8GE0tTKNdz7PaupSHfOOedJRFwmNqK90NPxZj+2gznej8V9CA6ZmkxLtS7uP36ZwBFI gwMuvMphm6EJXh5MMYnp/SvPAo0zjBoYoM6xiokKLsED2jqen5KmodjBRHhnOGuVhyuf Dq9XP3aW6mPI5yDSbNUriCy5kAF/jBB9NcHI7U2TFpzeOJXx7N+IvMxiQlGEXvwWIr8J IJs0kaYfGCRuHQgPZSBj/TCUiauY0iIFJF9S70UmLfZotSpSd+Y7Y7J1shrO3uDcuq4e AMtA== X-Gm-Message-State: AElRT7HTJdKzlqv26K8DYOKJV2d2YWk9TsxSVpq4DAaqplogDfv/6xXV PRoEPrNKR0H1Pi20rQFrJtIxbWHZXzeQs6vZnlT3OLRUito= X-Google-Smtp-Source: AG47ELtFFK2wQAeLSfQucKsSuxhXM4+LUC+tP90dvBZ06HRJ1zE9WhTdXGdRyYYGMzvU9DJ3DYcFU8g2SKNjTHtLcVQ= X-Received: by 10.31.165.213 with SMTP id o204mr16892542vke.163.1521760135149; Thu, 22 Mar 2018 16:08:55 -0700 (PDT) MIME-Version: 1.0 References: <99920B12-09F2-4293-B214-F766C00CAE6E@oracle.com> <221f7700-d279-1156-1b56-d222b111bce3@gmail.com> In-Reply-To: From: William Denniss Date: Thu, 22 Mar 2018 23:08:44 +0000 Message-ID: To: Marius Scurtescu Cc: Yaron Sheffer , ID Events Mailing List , Phil Hunt Content-Type: multipart/alternative; boundary="001a11427c944a7c0e056808644b" Archived-At: Subject: Re: [Id-event] Summary of working session discussion X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 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 Mar 2018 23:09:00 -0000 --001a11427c944a7c0e056808644b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Mar 22, 2018 at 7:03 PM Marius Scurtescu wrote: > On Thu, Mar 22, 2018 at 4:29 AM, William Denniss > wrote: > >> >> On Thu, Mar 22, 2018 at 10:04 AM Marius Scurtescu >> wrote: >> >>> Hi Yaron, >>> >>> I don't think anyone can argue with the desire for strong interop and >>> less complexity. >>> >>> Wearing our implementor hats, what delivery method would optimally cove= r >>> all use cases? Do we want a delivery method that in theory can cover mo= st >>> use cases, but it is suboptimal for many of them? How would a mobile or= IoT >>> device use the current PUSH or POLL methods? >>> >>> We are not talking about alternative delivery methods for the same use >>> case, but different methods for each separate use case. I totally agree >>> that as a workinggroup we should support one method per use case, for >>> example one method for HTTP receivers sitting behind firewalls. I am us= ing >>> "use case" in a generic way, more like "profile". >>> >>> Why declare one method as MTI when it is clear that it will not work fo= r >>> many use cases and that implementors for those use cases will be forced= to >>> ignore the MTI? >>> >>> Regarding the current delivery draft, why do you think that keeping the >>> two methods together is beneficial? The overlap between the two is mini= mal. >>> Here are the reasons why I think the draft should be split: >>> >>> 1. The two methods have different maturity levels. The PUSH method is >>> already implemented and more implementation will come online soon. The = POLL >>> method has no implementation yet, as far as I know. By keeping them >>> together we hold back one and put pressure to rush the other. That's >>> lose-lose. >>> >>> 2. With two methods in one drafts it is very ambiguous what is MTI. Wit= h >>> two separate drafts each implemetor can chose what works for their use >>> cases. Interop will work out based on use cases, I don't think we have = to >>> force it. >>> >>> The clear message for implementors two years from now would be a clear >>> description for each method as to what use cases it is applicable to. N= o >>> confusion at all, if you are behind a firewall then POLL is your only >>> option. If you are delivering to IoT then whatever method works for tha= t >>> use case (we don't have one yet). >>> >>> I asked about a meta-document from a practical point of view.. How/wher= e >>> will the MTI delivery method be defined? Same with IETF police, maybe y= ou >>> misunderstood. I am not worried about implementors disregarding >>> recommendations. Since the unit for specifications are RFCs, how can so= me >>> RFC be declared as MTI? In what context? Again, from a practical editor= ial >>> point of view. >>> >> >> Speaking to one draft I worked on where we faced this decision, PKCE >> Section 4.2 defined >> two methods to transform the code challenge, plain text (no >> transformation), and SHA256. >> >> "S256" is declared as MTI in the spec, and "plain" is not. In this case >> we actually say "Mandatory to Implement", but gating SHA256 with a "MUST= " >> and the "plain" with a "MAY" would have achieved the same effect. >> >> I advocated for making S256 MTI (when I first reviewed the draft, both >> were given equal weighting) so that native app clients would not need to >> perform discovery on the server to work out which method they can use (a= nd >> provide additional API methods for the developer to specify the transfor= m >> for servers that don't support discovery). Since SHA256 is MTI, all nati= ve >> app clients can rely on it being implemented. And that's what AppAuth >> does, it has no support for "plain", and doesn't bother with doing >> discovery on the PKCE method, which greatly simplified the implementatio= n >> (and it's completely seamless to users of AppAuth). As we required MTI o= n >> the more secure option of the two, this also resulted in more secure >> implementations by default. >> >> YMMV =E2=80=93 but that's what we did in that case :-) >> > > Thanks William. > > Yes, if both delivery methods are described in one draft then the draft > maybe declare one MTI and the other not. In this case the MTI is in the > context of the draft or RFC, in order to claim that you support the RFC y= ou > have to respect the MTI. > > But if the delivery methods are in separate drafts then I don't see how > that can be done. You are claim to support one RFC or the other. > I agree with this logic. It's only relevant when multiple alternatives are documented in a single RFC. If there are conflicting opinions on which should be MTI, and they're different enough, perhaps that is an indication that separate specifications would be better. Another MTI example: OAuth 2.0 Section 2.3.1 mandates that servers support HTTP Basic for client authentication, while also documenting request-body for clients that are unable to use HTTP Basic Authentication. AppAuth took advantage of this MTI too, by only authenticating using HTTP Basic, since it is capable of doing so, and this simplified the API surface substantially. > > This is all technical details on how MTI can be specified. The question i= f > an MTI for delivery methods is desirable or not is totally different. > > > >> >> >> >>> Guidance would be very useful IMO. >>> >>> Thanks, >>> Marius >>> >>> >>> Marius >>> >>> On Wed, Mar 21, 2018 at 9:05 AM, Yaron Sheffer >>> wrote: >>> >>>> Hi Marius, >>>> >>>> The decision about whether we need to have an MTI protocol and which >>>> one it should be is up to the WG consensus, like everything else. But = with >>>> my WG chair hat on, it is my strong conviction that we need to have on= e MTI >>>> method to encourage interoperability and reduce fragmentation. This is >>>> based on my IETF experience, and not on any meta-document as far as I = can >>>> tell. Just think of implementers that are not part of the WG, and just= read >>>> the RFCs two years from now. They need to have a clear message which m= ethod >>>> will allow them the best (though maybe not perfect) interoperability. = Also, >>>> I personally do not have a preference which of the methods becomes MTI= . >>>> >>>> It is common at the IETF to say that "there is no IETF police", in >>>> other words if you choose to not implement an MTI protocol/feature, no= body >>>> is going to come after you and punish you. It is between you and your >>>> market. I fully expect some of the WG participants to only implement t= he >>>> non-MTI method. >>>> >>>> We can absolutely ask the incoming AD for more guidance in this area. >>>> >>>> I think keeping the two methods within the same document will speed up >>>> and simplify the process, compared to running two docs in parallel. Th= ey do >>>> have enough commonalities. >>>> >>>> Thanks, >>>> Yaron >>>> >>>> On 21/03/18 15:42, Marius Scurtescu wrote: >>>> >>>>> Thanks for the summary Phil. >>>>> >>>>> Comments inline... >>>>> >>>>> On Wed, Mar 21, 2018 at 6:43 AM, Phil Hunt >>>> > wrote: >>>>> >>>>> We held a couple of brief sessions over the last couple days. >>>>> >>>>> We talked about the issue of breaking up the delivery document, >>>>> multiple delivery methods, and optionality. >>>>> >>>>> Some observations: >>>>> >>>>> 1. Yaron indicated that the IETF will likely require one method b= e >>>>> MTI (mandatory to implement). >>>>> >>>>> >>>>> It would be very useful to point to other working groups and specs >>>>> where this was the case. >>>>> >>>>> What is the mechanism by which a specific delivery method is made MTI= ? >>>>> Which meta document specifies that? >>>>> >>>>> What happens if a provider is not implementing the MTI delivery >>>>> method? What does that exactly mean? >>>>> >>>>> Just trying to understand what the process is.. >>>>> >>>>> >>>>> While PUSH has better scale (because it does not need HTTP Long >>>>> Polling), the POLL method has broader utility due to the presence >>>>> of >>>>> receivers with firewalls, gateways (IoT devices), or are mobile >>>>> applications that cannot implement endpoints to receive HTTP POST= s. >>>>> >>>>> >>>>> To me it is very unlikely that IoT or mobile devices will use POLL (o= r >>>>> PUSH). They will need some other delivery methods appropriate for the= ir >>>>> architecture. Having the current PUSH or POLL mandatory for these cas= es >>>>> does not make sense to me, >>>>> >>>>> >>>>> 2. If POLL is chosen as the MTI method, many will still likely >>>>> prefer PUSH and so that will likely get implemented sooner by som= e >>>>> >>>>> >>>>> Many will simply not implement POLL if what they need is PUSH, and >>>>> vice versa. Again, I don't see how the working group can pick any del= ivery >>>>> method and make it MTI. And MTI in what context? >>>>> >>>>> Can we escalate this issue within IETF to get guidance? >>>>> >>>>> >>>>> >>>>> 3. There was a general feeling that the delivery draft should st= ay >>>>> as one draft. >>>>> >>>>> >>>>> I don't see how that is helping, but if implementors can chose either >>>>> PUSH or POLL from the current draft then that's fine. But in that cas= e >>>>> splitting should also be acceptable. >>>>> >>>>> >>>>> >>>>> Annabelle will present her recommendations at the formal meeting = on >>>>> Friday where we can get broader input. >>>>> >>>>> Thanks everyone. >>>>> >>>>> Phil >>>>> >>>>> Oracle Corporation, Identity Cloud Services Architect >>>>> @independentid >>>>> www.independentid.com >>>>> phil.hunt@oracle.com >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>>>> >>>>> >>> _______________________________________________ >>> Id-event mailing list >>> Id-event@ietf.org >>> https://www.ietf.org/mailman/listinfo/id-event >>> >> > --001a11427c944a7c0e056808644b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable



On= Thu, Mar 22, 2018 at 7:03 PM Marius Scurtescu <mscurtescu@google.com> wrote:
On Thu, Mar 22, 2018 at 4:29 AM, William = Denniss <wdenniss@google.co= m> wrote:

On= Thu, Mar 22, 2018 at 10:04 AM Marius Scurtescu <mscurtescu@google.com> wrote:
Hi Yaron,

<= /div>
I don't think anyone can argue with the desire for strong int= erop and less complexity.

Wearing our implementor = hats, what delivery method would optimally cover all use cases? Do we want = a delivery method that in theory can cover most use cases, but it is subopt= imal for many of them? How would a mobile or IoT device use the current PUS= H or POLL methods?

We are not talking about altern= ative delivery methods for the same use case, but different methods for eac= h separate use case. I totally agree that as a workinggroup we should suppo= rt one method per use case, for example one method for HTTP receivers sitti= ng behind firewalls. I am using "use case" in a generic way, more= like "profile".

Why declare one method = as MTI when it is clear that it will not work for many use cases and that i= mplementors for those use cases will be forced to ignore the MTI?

Regarding the current delivery draft, why do you think that= keeping the two methods together is beneficial? The overlap between the tw= o is minimal. Here are the reasons why I think the draft should be split:

1. The two methods have different maturity levels. = The PUSH method is already implemented and more implementation will come on= line soon. The POLL method has no implementation yet, as far as I know. By = keeping them together we hold back one and put pressure to rush the other. = That's lose-lose.

2. With two methods in one d= rafts it is very ambiguous what is MTI. With two separate drafts each imple= metor can chose what works for their use cases. Interop will work out based= on use cases, I don't think we have to force it.

<= div>The clear message for implementors two years from now would be a clear = description for each method as to what use cases it is applicable to. No co= nfusion at all, if you are behind a firewall then POLL is your only option.= If you are delivering to IoT then whatever method works for that use case = (we don't have one yet).

I asked about = a meta-document from a practical point of view.. How/where will the MTI del= ivery method be defined? Same with IETF police, maybe you misunderstood. I = am not worried about implementors disregarding recommendations. Since the u= nit for specifications are RFCs, how can some RFC be declared as MTI? In wh= at context? Again, from a practical editorial point of view.=C2=A0

Speaking to one draf= t I worked on where we faced this decision,=C2=A0PKCE Section 4.2=C2=A0defin= ed two methods to transform the code challenge, plain text (no transformati= on), and SHA256.

"S256" is declared as MTI in the spec, an= d "plain" is not. In this case we actually say "Mandatory to= Implement", but gating SHA256 with a "MUST" and the "p= lain" with a "MAY" would have achieved the same effect.

I advocated for making S256 MTI (when I first reviewed the draft, both we= re given equal weighting) so that native app clients would not need to perf= orm discovery on the server to work out which method they can use (and prov= ide additional API methods for the developer to specify the transform for s= ervers that don't support discovery). Since SHA256 is MTI, all native a= pp clients can rely on it being implemented.=C2=A0 And that's what AppA= uth does, it has no support for "plain", and doesn't bother w= ith doing discovery on the PKCE method, which greatly simplified the implem= entation (and it's completely seamless to users of AppAuth). As we requ= ired MTI on the more secure option of the two, this also resulted in more s= ecure implementations by default.

YMMV =E2=80=93 but that's= what we did in that case :-)

=
Thanks William.

Yes, if both delivery methods= are described in one draft then the draft maybe declare one MTI and the ot= her not. In this case the MTI is in the context of the draft or RFC, in ord= er to claim that you support the RFC you have to respect the MTI.
=C2=A0
But if the delivery methods are in separ= ate drafts then I don't see how that can be done. You are claim to supp= ort one RFC or the other.

I agree with this logic. It's only relevant when multiple altern= atives are documented in a single RFC.=C2=A0 If there are conflicting opini= ons on which should be MTI, and they're different enough, perhaps that = is an indication that separate specifications would be better.

=
Another = MTI example:=C2=A0OAuth 2.0 Section 2.3.1 mandates that servers support HTTP Basic f= or client authentication, while also documenting request-body for clients t= hat are unable to use HTTP Basic Authentication.=C2=A0 AppAuth took advanta= ge of this MTI too, by only authenticating using HTTP Basic, since it is ca= pable of doing so, and this simplified the API surface substantially.=C2=A0=
=C2=A0

This is all technical details on how MTI can be specified. The que= stion if an MTI for delivery methods is desirable or not is totally differe= nt.

=C2=A0

=C2=A0
= Guidance would be very useful IMO.

Thanks,
Marius


Marius

On Wed, Mar 21, 2018 at 9:05 AM, Yaron Sheff= er <yaronf.ietf@gmail.com<= /a>> wrote:
= Hi Marius,

The decision about whether we need to have an MTI protocol and which one it= should be is up to the WG consensus, like everything else. But with my WG = chair hat on, it is my strong conviction that we need to have one MTI metho= d to encourage interoperability and reduce fragmentation. This is based on = my IETF experience, and not on any meta-document as far as I can tell. Just= think of implementers that are not part of the WG, and just read the RFCs = two years from now. They need to have a clear message which method will all= ow them the best (though maybe not perfect) interoperability. Also, I perso= nally do not have a preference which of the methods becomes MTI.

It is common at the IETF to say that "there is no IETF police", i= n other words if you choose to not implement an MTI protocol/feature, nobod= y is going to come after you and punish you. It is between you and your mar= ket. I fully expect some of the WG participants to only implement the non-M= TI method.

We can absolutely ask the incoming AD for more guidance in this area.

I think keeping the two methods within the same document will speed up and = simplify the process, compared to running two docs in parallel. They do hav= e enough commonalities.

Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Yaron

On 21/03/18 15:42, Marius Scurtescu wrote:
Thanks for the summary Phil.

Comments inline...

 On Wed, Mar 21, 2018 at 6:43 AM, Phil Hunt <p= hil.hunt@oracle.com <mailto:phil.hunt@ora= cle.com>> wrote:

=C2=A0 =C2=A0 We held a couple of brief sessions over the last couple days.=

=C2=A0 =C2=A0 We talked about the issue of breaking up the delivery documen= t,
=C2=A0 =C2=A0 multiple delivery methods, and optionality.

=C2=A0 =C2=A0 Some observations:

=C2=A0 =C2=A0 1. Yaron indicated that the IETF will likely require one meth= od be
=C2=A0 =C2=A0 MTI (mandatory to implement).


It would be very useful to point to other working groups and specs where th= is was the case.

What is the mechanism by which a specific delivery method is made MTI? Whic= h meta document specifies that?

What happens if a provider is not implementing the MTI delivery method? Wha= t does that exactly mean?

Just trying to understand what the process is..


=C2=A0 =C2=A0 While PUSH has better scale (because it does not need HTTP Lo= ng
=C2=A0 =C2=A0 Polling), the POLL method has broader utility due to the pres= ence of
=C2=A0 =C2=A0 receivers with firewalls, gateways (IoT devices), or are mobi= le
=C2=A0 =C2=A0 applications that cannot implement endpoints to receive HTTP = POSTs.


To me it is very unlikely that IoT or mobile devices will use POLL (or PUSH= ). They will need some other delivery methods appropriate for their archite= cture. Having the current PUSH or POLL mandatory for these cases does not m= ake sense to me,


=C2=A0 =C2=A0 2.=C2=A0 If POLL is chosen as the MTI method, many will still= likely
=C2=A0 =C2=A0 prefer PUSH and so that will likely get implemented sooner by= some


Many will simply not implement POLL if what they need is PUSH, and vice ver= sa. Again, I don't see how the working group can pick any delivery meth= od and make it MTI. And MTI in what context?

Can we escalate this issue within IETF to get guidance?



=C2=A0 =C2=A0 3.=C2=A0 There was a general feeling that the delivery draft = should stay
=C2=A0 =C2=A0 as one draft.


I don't see how that is helping, but if implementors can chose either P= USH or POLL from the current draft then that's fine. But in that case s= plitting should also be acceptable.



=C2=A0 =C2=A0 Annabelle will present her recommendations at the formal meet= ing on
=C2=A0 =C2=A0 Friday where we can get broader input.

=C2=A0 =C2=A0 Thanks everyone.

=C2=A0 =C2=A0 Phil

=C2=A0 =C2=A0 Oracle Corporation, Identity Cloud Services Architect
=C2=A0 =C2=A0 @independentid
 =C2=A0 =C2=A0 www.independen= tid.com <http://www.i= ndependentid.com>
=C2=A0 =C2=A0 phil.hunt@oracle.com <mailt= o:phil.hunt@oracle.com>


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




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


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

--001a11427c944a7c0e056808644b-- From nobody Fri Mar 23 02:30:50 2018 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 40E0312D77E for ; Fri, 23 Mar 2018 02:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 acs6GuP5EHFA for ; Fri, 23 Mar 2018 02:30:45 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0110.outbound.protection.outlook.com [104.47.40.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61DD11243F3 for ; Fri, 23 Mar 2018 02:30:42 -0700 (PDT) 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=yiKdcUr7Ewo2zLCXjnAdtqDxjoW+UJYi7D3ewo7Ei8g=; b=Ld0AiaRTHHyplget3FJRTq+gTSR4w7o2vvlLH06lyubpDma6CPwVL9htGDi4qjC6o86gaDCwQakFaXWEgQpdM9Ri2e+D58ZGfmD4lEJkOftI1v6GCcYHSdKQlaDcQsK+ZUJOOG+HXUp5mUYf+YnJPJT7WFgB+Lk1T30/XzgO6T0= Received: from BL0PR00MB0292.namprd00.prod.outlook.com (52.132.19.158) by BL0PR00MB0306.namprd00.prod.outlook.com (52.132.19.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.656.0; Fri, 23 Mar 2018 09:30:20 +0000 Received: from BL0PR00MB0292.namprd00.prod.outlook.com ([fe80::58c9:a553:b191:62b8]) by BL0PR00MB0292.namprd00.prod.outlook.com ([fe80::58c9:a553:b191:62b8%3]) with mapi id 15.20.0656.000; Fri, 23 Mar 2018 09:30:20 +0000 From: Mike Jones To: Marius Scurtescu , Leif Johansson CC: ID Events Mailing List Thread-Topic: [Id-event] "exp" claim in draft-ietf-secevent-token-07 Thread-Index: AQHTwZDMBIfMIC+jA0SEwbCxRulG6aPcCqZAgACZlYCAAOr3YA== Date: Fri, 23 Mar 2018 09:30:19 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.156.108] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BL0PR00MB0306; 7:i1Mrtz6AkjpUtEcaWNVUJj8uT675P5ZPpg3Nm29f6RLfoRqls5DZkg5sO8kuea7aytFtm0TxpOSg2fTbRrbnolrgkDaJTPaZeBh6Q9J9/t+E1uCZQCIn9F4LRGqxqrcv+wVeCPwlwVzILFO6eHTpiVGY0JYabTuK2m+xBAZ+jCOYImP4VU/usVfhUY87zXMAct+5TcCOpqkuygMHAX82nNnaUFuY+z4loaUo8PjKE9iQTgr4nJqUYH5BIR0UM/f5; 20:/Mo21UowgmJmLC0IvZJEK+tw5wjkHbV1PRV1pjao1Twye+Sk/smho965FT8q9neFanIrlP/i/GyvTmbfHtLuUPCRKx57EaSP/DH6w/55g0Wt9eAU44kf4h9nAaTMrPjdWxK48RhJtssY9o+OnnXw77tPnjF/NzyaLlMqGcfUzdY= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: ce8b6d40-1abf-45f0-ddd8-08d590a0b246 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:BL0PR00MB0306; x-ms-traffictypediagnostic: BL0PR00MB0306: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(89211679590171)(211936372134217)(153496737603132)(21748063052155)(69029272430364); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3231221)(944501305)(52105095)(3002001)(6055026)(61426038)(61427038)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:BL0PR00MB0306; BCL:0; PCL:0; RULEID:; SRVR:BL0PR00MB0306; x-forefront-prvs: 0620CADDF3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(346002)(39380400002)(39860400002)(396003)(189003)(199004)(66066001)(229853002)(25786009)(74316002)(33656002)(72206003)(76176011)(8936002)(790700001)(6116002)(3846002)(9686003)(8676002)(446003)(11346002)(10090500001)(236005)(68736007)(81156014)(81166006)(59450400001)(6306002)(54896002)(99286004)(55016002)(7696005)(86612001)(86362001)(4326008)(3660700001)(7736002)(2906002)(106356001)(19609705001)(316002)(22452003)(6506007)(53546011)(102836004)(6436002)(8990500004)(97736004)(14454004)(53936002)(110136005)(5660300001)(6246003)(5250100002)(478600001)(105586002)(10290500003)(2900100001)(3280700002)(186003)(6346003)(26005); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR00MB0306; H:BL0PR00MB0292.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-message-info: /8Q9kdrLsmhTjIH7HJN64mVbkX/jec+PII5WwmKP9BVGmuFMMYAKRkKUTyDUOT3TIJLEiy86YmbpB7eXtgevCYla4WG1JrusRPJxERB2eaYA1h8C8hJGeFrMyDKdtbje7lRS9RHYFM/RSOTo8YMpDhOf+i7NS3kHCMKF+pU4i10GoJFH1fb7VNAsTifOj2yfghdyG9NIfRkqhW9rwv4zOLWz2F2bxK7y9X01dsw2V/4FddPAKUeXpLY3oi/vrylFQEi1YpTSsJLxk2hb553/BdLP74px4kGtzDPGmsayyvOsHlCi4qWuP2mS+Y/+D08WC3MR4zTxbGiUHeEj7CR7hg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BL0PR00MB02929A2AC7C693451F5605E1F5A80BL0PR00MB0292namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: ce8b6d40-1abf-45f0-ddd8-08d590a0b246 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2018 09:30:20.1127 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR00MB0306 Archived-At: Subject: Re: [Id-event] "exp" claim in draft-ietf-secevent-token-07 X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 23 Mar 2018 09:30:49 -0000 --_000_BL0PR00MB02929A2AC7C693451F5605E1F5A80BL0PR00MB0292namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBkaXNhZ3JlZSB3aXRoIHlvdXIgY2hhcmFjdGVyaXphdGlvbiB0aGF0IOKAnGV4cOKAnSBoYXMg YW55dGhpbmcgdG8gZG8gd2l0aCB0aGUgZGVsaXZlcnkgbWV0aG9kLiAgSGF2aW5nIGl0IGRvIHNv IHdvdWxkIGJlIGEgbGF5ZXJpbmcgdmlvbGF0aW9uLCBhcyBhIFNFVCBzaG91bGQgYmUgdGhlIHNh bWUgbm8gbWF0dGVyIHdoYXQgdHJhbnNwb3J0IGlzIHVzZWQuICBJZiBhIHBhcnRpY3VsYXIgZGVs aXZlcnkgbWV0aG9kIG5lZWRzIGNhY2hpbmcvdGltZW91dCBwYXJhbWV0ZXJzIGl0IHNob3VsZCBz cGVjaWZ5IHRoZW0gYXMgcGFydCBvZiB0aGUgdHJhbnNwb3J0IChqdXN0IGxpa2UgSFRUUCBkb2Vz KSwgcmF0aGVyIHRoYW4gdHJ5aW5nIHRvIGluamVjdCB0cmFuc3BvcnQtc3BlY2lmaWMgY29udGVu dCBpbnRvIHRoZSBwYXlsb2FkLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBNYXJpdXMgU2N1cnRlc2N1IDxt c2N1cnRlc2N1QGdvb2dsZS5jb20+DQpTZW50OiBUaHVyc2RheSwgTWFyY2ggMjIsIDIwMTggNzoy NyBQTQ0KVG86IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT47IExlaWYg Sm9oYW5zc29uIDxsZWlmakBzdW5ldC5zZT4NCkNjOiBJRCBFdmVudHMgTWFpbGluZyBMaXN0IDxp ZC1ldmVudEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbSWQtZXZlbnRdICJleHAiIGNsYWltIGlu IGRyYWZ0LWlldGYtc2VjZXZlbnQtdG9rZW4tMDcNCg0KTGVpZiwgSSBiZWxpZXZlIHlvdSByYWlz ZWQgdGhpcyBpc3N1ZSBhdCBhIHBhc3QgbWVldGluZy4gRG8geW91IGhhdmUgYW55IHRob3VnaHRz Pw0KDQpDb21tZW50cyBpbmxpbmUuLi4NCg0KT24gVGh1LCBNYXIgMjIsIDIwMTggYXQgMzoyOSBB TSwgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVs LkpvbmVzQG1pY3Jvc29mdC5jb20+PiB3cm90ZToNClRvIG1lLCBpdCBzZWVtcyB0aGF0IHRyeWlu ZyB0byBtYW5kYXRlIHRoYXQgYW4gZXhwaXJhdGlvbiB0aW1lIGJlIHNlbnQgd2hlbiB0aGVyZSBp cyBubyBuYXR1cmFsIGV4cGlyYXRpb24gdGltZSBmb3IgdGhlIGluZm9ybWF0aW9uIGlzIG9kZCBh dCBiZXN0LCBhbmQgY291bnRlcnByb2R1Y3RpdmUgYXQgd29yc3QuICBXZSBzaG91bGQgbm90IGVu Y291cmFnZSBkZXBsb3llcnMgdG8gaGF2ZSB0byDigJxpbnZlbnTigJ0gYXJiaXRyYXJpbHkgY2hv c2VuIHZhbHVlcyBhbmQgaW5jbHVkZSB0aGVtIGFzIGNsYWltcyB0byBzYXRpc2Z5IGEgTVVTVCB0 aGF0IHNob3VsZG7igJl0IGhhdmUgYmVlbiB0aGVyZS4NCg0KImV4cCIgZG9lcyBub3QgYXBwbHkg dG8gdGhlIGV2ZW50KHMpLCBpdCBhcHBsaWVzIHRvIHRoZSBlbnZlbG9wZSwgc2FtZSBhcyAiaWF0 Ii4gSGVyZSBpcyB0aGUgZGVmaW5pdGlvbiBmcm9tIFJGQyA3NTE5Og0KIlRoZSAiZXhwIiAoZXhw aXJhdGlvbiB0aW1lKSBjbGFpbSBpZGVudGlmaWVzIHRoZSBleHBpcmF0aW9uIHRpbWUgb24gb3Ig YWZ0ZXIgd2hpY2ggdGhlIEpXVCBNVVNUIE5PVCBiZSBhY2NlcHRlZCBmb3IgcHJvY2Vzc2luZy4i DQoNClRyYW5zbWl0dGVycyBkb24ndCAiaW52ZW50IiB0aGUgdmFsdWUsIHRoZSB2YWx1ZSBmYWxs cyBvdXQgb2YgcmUtdHJ5IHBhcmFtZXRlcnMgYW5kIHRoZSBzcGVjaWZpYyBkZWxpdmVyeSBtZXRo b2QgdXNlZC4gQXJlIElkUHMgaW52ZW50aW5nIHRoZSBleHAgaW4gYW4gSWQgVG9rZW4/DQoNCkFs c28sICJleHAiIGluIGEgU0VUIHNob3VsZCBwcm9iYWJseSBiZSAiUkVDT01NRU5ERUQiIGFuZCBu b3QgIk1VU1QiLg0KDQoNCg0KQ2FjaGluZyBkZWNpc2lvbnMgYXJlIGhpZ2hseSBkZXBsb3ltZW50 IHNwZWNpZmljLiAgVGhleSBjb3VsZCwgZm9yIGluc3RhbmNlLCBiZSBiYXNlZCBvbiBhIGRlcGxv eW1lbnQtc3BlY2lmaWVkIGRlbHRhIGZyb20gdGhlIOKAnGlhdOKAnSAoaXNzdWVkIGF0KSB2YWx1 ZSBhbmQgbm90IHVzZSDigJxleHDigJ0gYXQgYWxsLg0KDQpGb3Igc3VyZSwgYnV0IGFuIGV4cCBj bGFpbSBtYWtlcyB0aGUgd2hvbGUgcHJvY2VzcyBtb3JlIHNlY3VyZS4gQSByZWNlaXZlciBtYXkg ZGVjaWRlIHRvIGNhY2hlIGZvciAyIG1pbnV0ZXMgKGFuZCBub3QgYWNjZXB0IFNFVHMgb2xkZXIg dGhhbiAyIG1pbnV0ZXMsIGhvcGVmdWxseSksIGJ1dCBhIHRyYW5zbWl0dGVyIG15IGtlZXAgcmUt dHJ5aW5nIHRvIHNlbmQgZXZlbnRzIGZvciAxMCBtaW51dGVzLiBNYW55IHRoaW5ncyBjYW4gZ28g d3JvbmcgaWYgZXhwIGlzIG5vdCBwcmVzZW50Lg0KDQoNCg0KV2l0aCByZXNwZWN0IHRvIOKAnGV4 cOKAnSwgSSB0aGluayB0aGUgc3BlYyBhbHJlYWR5IGhhcyBpdCByaWdodCBmb3IgdGhlIGdlbmVy YWwgY2FzZS4gIE9mIGNvdXJzZSwgaXTigJlzIGZpbmUgZm9yIHBhcnRpY3VsYXIgUHJvZmlsaW5n IFNwZWNpZmljYXRpb25zIHRvIHJlcXVpcmUgdGhhdCDigJxleHDigJ0gYmUgcHJlc2VudCBhbmQg ZGVmaW5lIGNvbnN0cmFpbnRzIHRoYXQgdGhlIGNsYWltIHZhbHVlIG11c3Qgc2F0aXNmeSBmb3Ig ZGVwbG95bWVudHMgdXNpbmcgdGhhdCBwcm9maWxl4oCmDQoNCllhcm9uIGp1c3QgcmFpc2VkIGNv bmNlcm5zIGFib3V0IGludGVyb3AsIHB1c2hpbmcgdGhpcyBpc3N1ZSB0byBwcm9maWxlcyBpcyBu b3QgaGVscGluZyBpbnRlcm9wIElNTy4NCg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBJZC1ldmVudCA8aWQt ZXZlbnQtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86aWQtZXZlbnQtYm91bmNlc0BpZXRmLm9yZz4+ IE9uIEJlaGFsZiBPZiBNYXJpdXMgU2N1cnRlc2N1DQpTZW50OiBUaHVyc2RheSwgTWFyY2ggMjIs IDIwMTggMzo0OSBBTQ0KVG86IElEIEV2ZW50cyBNYWlsaW5nIExpc3QgPGlkLWV2ZW50QGlldGYu b3JnPG1haWx0bzppZC1ldmVudEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBbSWQtZXZlbnRdICJleHAi IGNsYWltIGluIGRyYWZ0LWlldGYtc2VjZXZlbnQtdG9rZW4tMDcNCg0KU2VjdGlvbiAyLjIgZm9y ICJleHAiIHN0YXRlczoNCg0KInRoaXMgY2xhaW0gaXMgdGhlIHRpbWUgYWZ0ZXIgd2hpY2ggdGhl IEpXVCBNVVNUIE5PVCBiZSBhY2NlcHRlZCBmb3IgcHJvY2Vzc2luZy4gIEluIHRoZSBjb250ZXh0 IG9mIGEgU0VUIGhvd2V2ZXIsIHRoaXMgbm90aW9uIGRvZXMgbm90IHR5cGljYWxseSBhcHBseSwg c2luY2UgYSBTRVQgcmVwcmVzZW50cyBzb21ldGhpbmcgdGhhdCBoYXMgYWxyZWFkeSBvY2N1cnJl ZCBhbmQgaXMgaGlzdG9yaWNhbCBpbiBuYXR1cmUuIFRoZXJlZm9yZSwgaXRzIHVzZSBpcyBOT1Qg UkVDT01NRU5ERUQuIg0KDQpTaW1pbGFybHksIHNlY3Rpb24gNC41IG1ha2VzIHJlY29tbWVuZGF0 aW9ucyBhZ2FpbnN0ICJleHAiLg0KDQpBdCBJRVRGIDEwMCBpbiBTaW5nYXBvcmUgd2UgYnJpZWZs eSB0YWxrZWQgYWJvdXQgdGhpcyBhbmQgdGhlIGZvbGxvd2luZyBwcm9ibGVtIGNhbWUgdXA6IHdp dGhvdXQgImV4cCIgaG93IGxvbmcgc2hvdWxkIGEgcmVjZWl2ZXIgY2FjaGUgImp0aSIgdmFsdWVz IHRvIHByZXZlbnQgZG91YmxlIHN1Ym1pc3Npb25zIChhbmQgcmVwbGF5IGF0dGFja3MpPw0KDQpU b2RheSB0aGUgc2FtZSBwcm9ibGVtIHdhcyByYWlzZWQgYXMgaW1wbGVtZW50YXRpb24gZmVlZGJh Y2suDQoNCkl0IHNlZW1zIHRoYXQgImV4cCIgc2hvdWxkIHJhdGhlciBiZSByZXF1aXJlZC4gVGhv dWdodHM/DQoNCldoYXQgaGFwcGVucyB0byBzZWN0aW9uIDQuNSBpZiAiZXhwIiBpcyByZXF1aXJl ZD8NCg0KQWxzbywgYSByZXF1aXJlZCAob3IgcmVjb21tZW5kZWQpICJleHAiIGxlYWRzIHRvIGlt cGxlbWVudGF0aW9uIGNoYWxsZW5nZXMgd2hlbiBpdCBjb21lcyB0byBkZWxpdmVyeS4gQSB0cmFu c21pdHRlciB0aGF0IGlzIHJldHJ5aW5nIHRvIGRlbGl2ZXIgdW5jb25maXJtZWQgU0VUcywgd2ls bCBoYXZlIHRvIHByb2JhYmx5IHJlLW1pbnQgdGhlbSBvbiBlYWNoIGRlbGl2ZXJ5IGF0dGVtcHQs IGFzIG9wcG9zZWQgdG8gc2ltcGx5IGNhY2hlIGEgbWludGVkIFNFVCBhbmQga2VlcCByZXRyeWlu ZyB3aXRoIHRoYXQuIE9yIHRoZSB0cmFuc21pdHRlciB3aWxsIGhhdmUgdG8gc2V0IGFuIGV4cGly YXRpb24gcGVyaW9kIGxvbmdlciB0aGFuIHRoZSByZXRyeSBwZXJpb2QsIGJ1dCBsb25nIGV4cGly YXRpb24gcGVyaW9kcyBwdXQgYmlnZ2VyIGxvYWRzIG9uIHJlY2VpdmVycyAobGFyZ2VyIGNhY2hl KS4NCg0KQW55IGNoYW5jZSB0aGlzIGNhbiBiZSBkaXNjdXNzZWQgb24gRnJpZGF5Pw0KDQpNYXJp dXMNCg0K --_000_BL0PR00MB02929A2AC7C693451F5605E1F5A80BL0PR00MB0292namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBp biAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzAwMjA2MCI+SSBkaXNhZ3JlZSB3aXRoIHlvdXIgY2hhcmFjdGVyaXph dGlvbiB0aGF0IOKAnGV4cOKAnSBoYXMgYW55dGhpbmcgdG8gZG8gd2l0aCB0aGUgZGVsaXZlcnkg bWV0aG9kLiZuYnNwOyBIYXZpbmcgaXQgZG8gc28gd291bGQgYmUgYSBsYXllcmluZyB2aW9sYXRp b24sIGFzIGEgU0VUIHNob3VsZCBiZSB0aGUgc2FtZSBubyBtYXR0ZXIgd2hhdCB0cmFuc3BvcnQg aXMgdXNlZC4mbmJzcDsgSWYNCiBhIHBhcnRpY3VsYXIgZGVsaXZlcnkgbWV0aG9kIG5lZWRzIGNh Y2hpbmcvdGltZW91dCBwYXJhbWV0ZXJzIGl0IHNob3VsZCBzcGVjaWZ5IHRoZW0gYXMgcGFydCBv ZiB0aGUgdHJhbnNwb3J0IChqdXN0IGxpa2UgSFRUUCBkb2VzKSwgcmF0aGVyIHRoYW4gdHJ5aW5n IHRvIGluamVjdCB0cmFuc3BvcnQtc3BlY2lmaWMgY29udGVudCBpbnRvIHRoZSBwYXlsb2FkLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IE1hcml1cyBT Y3VydGVzY3UgJmx0O21zY3VydGVzY3VAZ29vZ2xlLmNvbSZndDsgPGJyPg0KPGI+U2VudDo8L2I+ IFRodXJzZGF5LCBNYXJjaCAyMiwgMjAxOCA3OjI3IFBNPGJyPg0KPGI+VG86PC9iPiBNaWtlIEpv bmVzICZsdDtNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20mZ3Q7OyBMZWlmIEpvaGFuc3NvbiAm bHQ7bGVpZmpAc3VuZXQuc2UmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBJRCBFdmVudHMgTWFpbGluZyBM aXN0ICZsdDtpZC1ldmVudEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtJ ZC1ldmVudF0gJnF1b3Q7ZXhwJnF1b3Q7IGNsYWltIGluIGRyYWZ0LWlldGYtc2VjZXZlbnQtdG9r ZW4tMDc8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TGVpZiwg SSBiZWxpZXZlIHlvdSByYWlzZWQgdGhpcyBpc3N1ZSBhdCBhIHBhc3QgbWVldGluZy4gRG8geW91 IGhhdmUgYW55IHRob3VnaHRzPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5Db21tZW50cyBpbmxpbmUuLi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBNYXIgMjIsIDIwMTggYXQg MzoyOSBBTSwgTWlrZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWlj cm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+VG8gbWUs IGl0IHNlZW1zIHRoYXQgdHJ5aW5nIHRvIG1hbmRhdGUgdGhhdCBhbiBleHBpcmF0aW9uIHRpbWUg YmUgc2VudCB3aGVuIHRoZXJlIGlzIG5vIG5hdHVyYWwgZXhwaXJhdGlvbiB0aW1lIGZvciB0aGUg aW5mb3JtYXRpb24gaXMgb2RkIGF0IGJlc3QsIGFuZA0KIGNvdW50ZXJwcm9kdWN0aXZlIGF0IHdv cnN0LiZuYnNwOyBXZSBzaG91bGQgbm90IGVuY291cmFnZSBkZXBsb3llcnMgdG8gaGF2ZSB0byDi gJxpbnZlbnTigJ0gYXJiaXRyYXJpbHkgY2hvc2VuIHZhbHVlcyBhbmQgaW5jbHVkZSB0aGVtIGFz IGNsYWltcyB0byBzYXRpc2Z5IGEgTVVTVCB0aGF0IHNob3VsZG7igJl0IGhhdmUgYmVlbiB0aGVy ZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JnF1b3Q7ZXhwJnF1b3Q7IGRvZXMgbm90IGFw cGx5IHRvIHRoZSBldmVudChzKSwgaXQgYXBwbGllcyB0byB0aGUgZW52ZWxvcGUsIHNhbWUgYXMg JnF1b3Q7aWF0JnF1b3Q7LiBIZXJlIGlzIHRoZSBkZWZpbml0aW9uIGZyb20gUkZDIDc1MTk6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mcXVvdDtU aGUgJnF1b3Q7ZXhwJnF1b3Q7IChleHBpcmF0aW9uIHRpbWUpIGNsYWltIGlkZW50aWZpZXMgdGhl IGV4cGlyYXRpb24gdGltZSBvbiBvciBhZnRlciB3aGljaCB0aGUgSldUIE1VU1QgTk9UIGJlIGFj Y2VwdGVkIGZvciBwcm9jZXNzaW5nLiZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UcmFuc21pdHRlcnMgZG9uJ3QgJnF1b3Q7aW52ZW50 JnF1b3Q7IHRoZSB2YWx1ZSwgdGhlIHZhbHVlIGZhbGxzIG91dCBvZiByZS10cnkgcGFyYW1ldGVy cyBhbmQgdGhlIHNwZWNpZmljIGRlbGl2ZXJ5IG1ldGhvZCB1c2VkLiBBcmUgSWRQcyBpbnZlbnRp bmcgdGhlIGV4cCBpbiBhbiBJZCBUb2tlbj88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWxzbywgJnF1b3Q7ZXhwJnF1b3Q7IGluIGEgU0VUIHNo b3VsZCBwcm9iYWJseSBiZSAmcXVvdDtSRUNPTU1FTkRFRCZxdW90OyBhbmQgbm90ICZxdW90O01V U1QmcXVvdDsuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYw Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5DYWNoaW5nIGRlY2lzaW9ucyBhcmUgaGlnaGx5IGRl cGxveW1lbnQgc3BlY2lmaWMuJm5ic3A7IFRoZXkgY291bGQsIGZvciBpbnN0YW5jZSwgYmUgYmFz ZWQgb24gYSBkZXBsb3ltZW50LXNwZWNpZmllZCBkZWx0YSBmcm9tIHRoZSDigJxpYXTigJ0gKGlz c3VlZCBhdCkgdmFsdWUNCiBhbmQgbm90IHVzZSDigJxleHDigJ0gYXQgYWxsLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5Gb3Igc3VyZSwgYnV0IGFuIGV4cCBjbGFpbSBtYWtlcyB0aGUgd2hv bGUgcHJvY2VzcyBtb3JlIHNlY3VyZS4gQSByZWNlaXZlciBtYXkgZGVjaWRlIHRvIGNhY2hlIGZv ciAyIG1pbnV0ZXMgKGFuZCBub3QgYWNjZXB0IFNFVHMgb2xkZXIgdGhhbiAyIG1pbnV0ZXMsIGhv cGVmdWxseSksIGJ1dCBhIHRyYW5zbWl0dGVyIG15IGtlZXAgcmUtdHJ5aW5nIHRvIHNlbmQgZXZl bnRzIGZvciAxMCBtaW51dGVzLiBNYW55DQogdGhpbmdzIGNhbiBnbyB3cm9uZyBpZiBleHAgaXMg bm90IHByZXNlbnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBp biAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAy MDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5XaXRoIHJlc3BlY3QgdG8g4oCcZXhw4oCdLCBJ IHRoaW5rIHRoZSBzcGVjIGFscmVhZHkgaGFzIGl0IHJpZ2h0IGZvciB0aGUgZ2VuZXJhbCBjYXNl LiZuYnNwOyBPZiBjb3Vyc2UsIGl04oCZcyBmaW5lIGZvciBwYXJ0aWN1bGFyIFByb2ZpbGluZyBT cGVjaWZpY2F0aW9ucyB0byByZXF1aXJlDQogdGhhdCDigJxleHDigJ0gYmUgcHJlc2VudCBhbmQg ZGVmaW5lIGNvbnN0cmFpbnRzIHRoYXQgdGhlIGNsYWltIHZhbHVlIG11c3Qgc2F0aXNmeSBmb3Ig ZGVwbG95bWVudHMgdXNpbmcgdGhhdCBwcm9maWxl4oCmPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPllhcm9uIGp1c3QgcmFpc2VkIGNvbmNlcm5zIGFib3V0IGludGVyb3AsIHB1c2hpbmcgdGhp cyBpc3N1ZSB0byBwcm9maWxlcyBpcyBub3QgaGVscGluZyBpbnRlcm9wIElNTy48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAy MDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNv bG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PGI+RnJvbTo8L2I+IElkLWV2ZW50ICZsdDs8YSBocmVmPSJtYWlsdG86aWQtZXZl bnQtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmlkLWV2ZW50LWJvdW5jZXNAaWV0 Zi5vcmc8L2E+Jmd0Ow0KPGI+T24gQmVoYWxmIE9mIDwvYj5NYXJpdXMgU2N1cnRlc2N1PGJyPg0K PGI+U2VudDo8L2I+IFRodXJzZGF5LCBNYXJjaCAyMiwgMjAxOCAzOjQ5IEFNPGJyPg0KPGI+VG86 PC9iPiBJRCBFdmVudHMgTWFpbGluZyBMaXN0ICZsdDs8YSBocmVmPSJtYWlsdG86aWQtZXZlbnRA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pZC1ldmVudEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0K PGI+U3ViamVjdDo8L2I+IFtJZC1ldmVudF0gJnF1b3Q7ZXhwJnF1b3Q7IGNsYWltIGluIGRyYWZ0 LWlldGYtc2VjZXZlbnQtdG9rZW4tMDc8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPlNlY3Rpb24gMi4yIGZvciAmcXVvdDtleHAmcXVvdDsgc3RhdGVzOjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m cXVvdDt0aGlzIGNsYWltIGlzIHRoZSB0aW1lIGFmdGVyIHdoaWNoIHRoZSBKV1QgTVVTVCBOT1Qg YmUgYWNjZXB0ZWQgZm9yIHByb2Nlc3NpbmcuJm5ic3A7IEluIHRoZSBjb250ZXh0IG9mIGEgU0VU IGhvd2V2ZXIsIHRoaXMgbm90aW9uIGRvZXMgbm90IHR5cGljYWxseSBhcHBseSwgc2luY2UgYSBT RVQgcmVwcmVzZW50cyBzb21ldGhpbmcNCiB0aGF0IGhhcyBhbHJlYWR5IG9jY3VycmVkIGFuZCBp cyBoaXN0b3JpY2FsIGluIG5hdHVyZS4gVGhlcmVmb3JlLCBpdHMgdXNlIGlzIE5PVCBSRUNPTU1F TkRFRC4mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPlNpbWlsYXJseSwgc2VjdGlvbiA0LjUgbWFrZXMgcmVjb21tZW5kYXRpb25z IGFnYWluc3QgJnF1b3Q7ZXhwJnF1b3Q7LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QXQgSUVURiAxMDAgaW4gU2luZ2Fwb3JlIHdlIGJy aWVmbHkgdGFsa2VkIGFib3V0IHRoaXMgYW5kIHRoZSBmb2xsb3dpbmcgcHJvYmxlbSBjYW1lIHVw OiB3aXRob3V0ICZxdW90O2V4cCZxdW90OyBob3cgbG9uZyBzaG91bGQgYSByZWNlaXZlciBjYWNo ZSAmcXVvdDtqdGkmcXVvdDsgdmFsdWVzIHRvIHByZXZlbnQgZG91YmxlIHN1Ym1pc3Npb25zDQog KGFuZCByZXBsYXkgYXR0YWNrcyk/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5Ub2RheSB0aGUgc2FtZSBwcm9ibGVtIHdhcyByYWlzZWQg YXMgaW1wbGVtZW50YXRpb24gZmVlZGJhY2suPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JdCBzZWVtcyB0aGF0ICZxdW90O2V4cCZxdW90 OyBzaG91bGQgcmF0aGVyIGJlIHJlcXVpcmVkLiBUaG91Z2h0cz88bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPldoYXQgaGFwcGVucyB0byBz ZWN0aW9uIDQuNSBpZiAmcXVvdDtleHAmcXVvdDsgaXMgcmVxdWlyZWQ/PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BbHNvLCBhIHJlcXVp cmVkIChvciByZWNvbW1lbmRlZCkgJnF1b3Q7ZXhwJnF1b3Q7IGxlYWRzIHRvIGltcGxlbWVudGF0 aW9uIGNoYWxsZW5nZXMgd2hlbiBpdCBjb21lcyB0byBkZWxpdmVyeS4gQSB0cmFuc21pdHRlciB0 aGF0IGlzIHJldHJ5aW5nIHRvIGRlbGl2ZXIgdW5jb25maXJtZWQgU0VUcywgd2lsbCBoYXZlIHRv IHByb2JhYmx5DQogcmUtbWludCB0aGVtIG9uIGVhY2ggZGVsaXZlcnkgYXR0ZW1wdCwgYXMgb3Bw b3NlZCB0byBzaW1wbHkgY2FjaGUgYSBtaW50ZWQgU0VUIGFuZCBrZWVwIHJldHJ5aW5nIHdpdGgg dGhhdC4gT3IgdGhlIHRyYW5zbWl0dGVyIHdpbGwgaGF2ZSB0byBzZXQgYW4gZXhwaXJhdGlvbiBw ZXJpb2QgbG9uZ2VyIHRoYW4gdGhlIHJldHJ5IHBlcmlvZCwgYnV0IGxvbmcgZXhwaXJhdGlvbiBw ZXJpb2RzIHB1dCBiaWdnZXIgbG9hZHMgb24gcmVjZWl2ZXJzIChsYXJnZXINCiBjYWNoZSkuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5B bnkgY2hhbmNlIHRoaXMgY2FuIGJlIGRpc2N1c3NlZCBvbiBGcmlkYXk/PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5NYXJpdXM8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_BL0PR00MB02929A2AC7C693451F5605E1F5A80BL0PR00MB0292namp_-- From nobody Fri Mar 23 03:52:18 2018 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 AB93B12D86B for ; Fri, 23 Mar 2018 03:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zIUVIcDEegvb for ; Fri, 23 Mar 2018 03:52:13 -0700 (PDT) Received: from p3plsmtpa09-06.prod.phx3.secureserver.net (p3plsmtpa09-06.prod.phx3.secureserver.net [173.201.193.235]) (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 0FA4012D86F for ; Fri, 23 Mar 2018 03:52:06 -0700 (PDT) Received: from [192.168.0.107] ([78.130.190.73]) by :SMTPAUTH: with SMTP id zKIkeXkLXn3l9zKIleI01t; Fri, 23 Mar 2018 03:52:05 -0700 To: William Denniss , Marius Scurtescu Cc: Yaron Sheffer , ID Events Mailing List , Phil Hunt References: <99920B12-09F2-4293-B214-F766C00CAE6E@oracle.com> <221f7700-d279-1156-1b56-d222b111bce3@gmail.com> From: Vladimir Dzhuvinov Organization: Connect2id Ltd. Message-ID: Date: Fri, 23 Mar 2018 12:52:02 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060605060604040901070000" X-CMAE-Envelope: MS4wfE/Zrh7zHaDIxVlGjzQBw1SNC3kVw+YJ2yP4iqnEFKdug831VeW9M8MfwLJ3ei8YHcyfQ51Bac7vqdC2JSPIQyl/HraQ0k3shE6F2ldfvUzW3WcZsedD nV/TvRPSDDDC9dT1e015lTrJAdjnAUz+Fk/U6TYGJsazcGUC5AcKHtbW8o44kr77sZbMb8MutsH9wJ0YdbN2Sg8MsqUfD0/vTjyBW5wFXVLfF4uU+P88i6f4 i6UhEZNAXLToN8ROVvjdIYotIC2JVkwB69hBuy2yM+6NzbTR1JmeIMDT7YlqO6nJNF8smWl0nI3S8uENxPs0Xw== Archived-At: Subject: Re: [Id-event] Summary of working session discussion X-BeenThere: id-event@ietf.org X-Mailman-Version: 2.1.22 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: Fri, 23 Mar 2018 10:52:18 -0000 This is a cryptographically signed message in MIME format. --------------ms060605060604040901070000 Content-Type: multipart/alternative; boundary="------------79F7299C54C023888A90FEAE" Content-Language: en-US This is a multi-part message in MIME format. --------------79F7299C54C023888A90FEAE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 23/03/18 01:08, William Denniss wrote: > On Thu, Mar 22, 2018 at 7:03 PM Marius Scurtescu > wrote: > >> On Thu, Mar 22, 2018 at 4:29 AM, William Denniss = >> wrote: >> >>> On Thu, Mar 22, 2018 at 10:04 AM Marius Scurtescu >>> wrote: >>> >>>> Hi Yaron, >>>> >>>> I don't think anyone can argue with the desire for strong interop an= d >>>> less complexity. >>>> >>>> Wearing our implementor hats, what delivery method would optimally c= over >>>> all use cases? Do we want a delivery method that in theory can cover= most >>>> use cases, but it is suboptimal for many of them? How would a mobile= or IoT >>>> device use the current PUSH or POLL methods? >>>> >>>> We are not talking about alternative delivery methods for the same u= se >>>> case, but different methods for each separate use case. I totally ag= ree >>>> that as a workinggroup we should support one method per use case, fo= r >>>> example one method for HTTP receivers sitting behind firewalls. I am= using >>>> "use case" in a generic way, more like "profile". >>>> >>>> Why declare one method as MTI when it is clear that it will not work= for >>>> many use cases and that implementors for those use cases will be for= ced to >>>> ignore the MTI? >>>> >>>> Regarding the current delivery draft, why do you think that keeping = the >>>> two methods together is beneficial? The overlap between the two is m= inimal. >>>> Here are the reasons why I think the draft should be split: >>>> >>>> 1. The two methods have different maturity levels. The PUSH method i= s >>>> already implemented and more implementation will come online soon. T= he POLL >>>> method has no implementation yet, as far as I know. By keeping them >>>> together we hold back one and put pressure to rush the other. That's= >>>> lose-lose. >>>> >>>> 2. With two methods in one drafts it is very ambiguous what is MTI. = With >>>> two separate drafts each implemetor can chose what works for their u= se >>>> cases. Interop will work out based on use cases, I don't think we ha= ve to >>>> force it. >>>> >>>> The clear message for implementors two years from now would be a cle= ar >>>> description for each method as to what use cases it is applicable to= =2E No >>>> confusion at all, if you are behind a firewall then POLL is your onl= y >>>> option. If you are delivering to IoT then whatever method works for = that >>>> use case (we don't have one yet). >>>> >>>> I asked about a meta-document from a practical point of view.. How/w= here >>>> will the MTI delivery method be defined? Same with IETF police, mayb= e you >>>> misunderstood. I am not worried about implementors disregarding >>>> recommendations. Since the unit for specifications are RFCs, how can= some >>>> RFC be declared as MTI? In what context? Again, from a practical edi= torial >>>> point of view. >>>> >>> Speaking to one draft I worked on where we faced this decision, PKCE >>> Section 4.2 defined= >>> two methods to transform the code challenge, plain text (no >>> transformation), and SHA256. >>> >>> "S256" is declared as MTI in the spec, and "plain" is not. In this ca= se >>> we actually say "Mandatory to Implement", but gating SHA256 with a "M= UST" >>> and the "plain" with a "MAY" would have achieved the same effect. >>> >>> I advocated for making S256 MTI (when I first reviewed the draft, bot= h >>> were given equal weighting) so that native app clients would not need= to >>> perform discovery on the server to work out which method they can use= (and >>> provide additional API methods for the developer to specify the trans= form >>> for servers that don't support discovery). Since SHA256 is MTI, all n= ative >>> app clients can rely on it being implemented. And that's what AppAut= h >>> does, it has no support for "plain", and doesn't bother with doing >>> discovery on the PKCE method, which greatly simplified the implementa= tion >>> (and it's completely seamless to users of AppAuth). As we required MT= I on >>> the more secure option of the two, this also resulted in more secure >>> implementations by default. >>> >>> YMMV =E2=80=93 but that's what we did in that case :-) >>> >> Thanks William. >> >> Yes, if both delivery methods are described in one draft then the draf= t >> maybe declare one MTI and the other not. In this case the MTI is in th= e >> context of the draft or RFC, in order to claim that you support the RF= C you >> have to respect the MTI. >> > >> But if the delivery methods are in separate drafts then I don't see ho= w >> that can be done. You are claim to support one RFC or the other. >> > I agree with this logic. It's only relevant when multiple alternatives = are > documented in a single RFC. If there are conflicting opinions on which= > should be MTI, and they're different enough, perhaps that is an indicat= ion > that separate specifications would be better. > > Another MTI example: OAuth 2.0 Section 2.3.1 > mandates that serve= rs > support HTTP Basic for client authentication, while also documenting > request-body for clients that are unable to use HTTP Basic Authenticati= on. > AppAuth took advantage of this MTI too, by only authenticating using HT= TP > Basic, since it is capable of doing so, and this simplified the API sur= face > substantially. I hope neither method will become MTI. An MTI would work well if the MTI method could potentially cover all delivery cases, and the other method extends or enhances the MTI with features. But in the case of HTTP push vs pull, we have two delivery methods intended to solve different use cases. Designating one of them MTI is a bit like making apples MTI for oranges. Thanks, Vladimir > >> This is all technical details on how MTI can be specified. The questio= n if >> an MTI for delivery methods is desirable or not is totally different. >> >> >> >>> >>> >>>> Guidance would be very useful IMO. >>>> >>>> Thanks, >>>> Marius >>>> >>>> >>>> Marius >>>> >>>> On Wed, Mar 21, 2018 at 9:05 AM, Yaron Sheffer >>>> wrote: >>>> >>>>> Hi Marius, >>>>> >>>>> The decision about whether we need to have an MTI protocol and whic= h >>>>> one it should be is up to the WG consensus, like everything else. B= ut with >>>>> my WG chair hat on, it is my strong conviction that we need to have= one MTI >>>>> method to encourage interoperability and reduce fragmentation. This= is >>>>> based on my IETF experience, and not on any meta-document as far as= I can >>>>> tell. Just think of implementers that are not part of the WG, and j= ust read >>>>> the RFCs two years from now. They need to have a clear message whic= h method >>>>> will allow them the best (though maybe not perfect) interoperabilit= y. Also, >>>>> I personally do not have a preference which of the methods becomes = MTI.. >>>>> >>>>> It is common at the IETF to say that "there is no IETF police", in >>>>> other words if you choose to not implement an MTI protocol/feature,= nobody >>>>> is going to come after you and punish you. It is between you and yo= ur >>>>> market. I fully expect some of the WG participants to only implemen= t the >>>>> non-MTI method. >>>>> >>>>> We can absolutely ask the incoming AD for more guidance in this are= a. >>>>> >>>>> I think keeping the two methods within the same document will speed= up >>>>> and simplify the process, compared to running two docs in parallel.= They do >>>>> have enough commonalities. >>>>> >>>>> Thanks, >>>>> Yaron >>>>> >>>>> On 21/03/18 15:42, Marius Scurtescu wrote: >>>>> >>>>>> Thanks for the summary Phil. >>>>>> >>>>>> Comments inline... >>>>>> >>>>>> On Wed, Mar 21, 2018 at 6:43 AM, Phil Hunt >>>>> > wrote: >>>>>> >>>>>> We held a couple of brief sessions over the last couple days. >>>>>> >>>>>> We talked about the issue of breaking up the delivery document= , >>>>>> multiple delivery methods, and optionality. >>>>>> >>>>>> Some observations: >>>>>> >>>>>> 1. Yaron indicated that the IETF will likely require one metho= d be >>>>>> MTI (mandatory to implement). >>>>>> >>>>>> >>>>>> It would be very useful to point to other working groups and specs= >>>>>> where this was the case. >>>>>> >>>>>> What is the mechanism by which a specific delivery method is made = MTI? >>>>>> Which meta document specifies that? >>>>>> >>>>>> What happens if a provider is not implementing the MTI delivery >>>>>> method? What does that exactly mean? >>>>>> >>>>>> Just trying to understand what the process is.. >>>>>> >>>>>> >>>>>> While PUSH has better scale (because it does not need HTTP Lon= g >>>>>> Polling), the POLL method has broader utility due to the prese= nce >>>>>> of >>>>>> receivers with firewalls, gateways (IoT devices), or are mobil= e >>>>>> applications that cannot implement endpoints to receive HTTP P= OSTs. >>>>>> >>>>>> >>>>>> To me it is very unlikely that IoT or mobile devices will use POLL= (or >>>>>> PUSH). They will need some other delivery methods appropriate for = their >>>>>> architecture. Having the current PUSH or POLL mandatory for these = cases >>>>>> does not make sense to me, >>>>>> >>>>>> >>>>>> 2. If POLL is chosen as the MTI method, many will still likel= y >>>>>> prefer PUSH and so that will likely get implemented sooner by = some >>>>>> >>>>>> >>>>>> Many will simply not implement POLL if what they need is PUSH, and= >>>>>> vice versa. Again, I don't see how the working group can pick any = delivery >>>>>> method and make it MTI. And MTI in what context? >>>>>> >>>>>> Can we escalate this issue within IETF to get guidance? >>>>>> >>>>>> >>>>>> >>>>>> 3. There was a general feeling that the delivery draft should= stay >>>>>> as one draft. >>>>>> >>>>>> >>>>>> I don't see how that is helping, but if implementors can chose eit= her >>>>>> PUSH or POLL from the current draft then that's fine. But in that = case >>>>>> splitting should also be acceptable. >>>>>> >>>>>> >>>>>> >>>>>> Annabelle will present her recommendations at the formal meeti= ng on >>>>>> Friday where we can get broader input. >>>>>> >>>>>> Thanks everyone. >>>>>> >>>>>> Phil >>>>>> >>>>>> Oracle Corporation, Identity Cloud Services Architect >>>>>> @independentid >>>>>> www.independentid.com >>>>>> phil.hunt@oracle.com >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>>> >>>>>> >>>> _______________________________________________ >>>> 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 --------------79F7299C54C023888A90FEAE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable



On 23/03/18 01:08, William Denniss wrote:
On Thu, Mar 22, 2018 at 7:03 PM Marius Scurtescu <=
;mscurtescu@google.com>
wrote:


On Thu, Mar 22, 2018 at 4:29 AM, William Denniss <=
a class=3D"moz-txt-link-rfc2396E" href=3D"mailto:wdenniss@google.com"><=
;wdenniss@google.com>
wrote:


On Thu, Mar 22, 2018 at 10:04 AM Marius Scurtescu <mscurtescu@google.c=
om>
wrote:


Hi Yaron,

I don't think anyone can argue with the desire for strong interop and
less complexity.

Wearing our implementor hats, what delivery method would optimally cover
all use cases? Do we want a delivery method that in theory can cover most=

use cases, but it is suboptimal for many of them? How would a mobile or I=
oT
device use the current PUSH or POLL methods?

We are not talking about alternative delivery methods for the same use
case, but different methods for each separate use case. I totally agree
that as a workinggroup we should support one method per use case, for
example one method for HTTP receivers sitting behind firewalls. I am usin=
g
"use case" in a generic way, more like "profile".

Why declare one method as MTI when it is clear that it will not work for
many use cases and that implementors for those use cases will be forced t=
o
ignore the MTI?

Regarding the current delivery draft, why do you think that keeping the
two methods together is beneficial? The overlap between the two is minima=
l.
Here are the reasons why I think the draft should be split:

1. The two methods have different maturity levels. The PUSH method is
already implemented and more implementation will come online soon. The PO=
LL
method has no implementation yet, as far as I know. By keeping them
together we hold back one and put pressure to rush the other. That's
lose-lose.

2. With two methods in one drafts it is very ambiguous what is MTI. With
two separate drafts each implemetor can chose what works for their use
cases. Interop will work out based on use cases, I don't think we have to=

force it.

The clear message for implementors two years from now would be a clear
description for each method as to what use cases it is applicable to. No
confusion at all, if you are behind a firewall then POLL is your only
option. If you are delivering to IoT then whatever method works for that
use case (we don't have one yet).

I asked about a meta-document from a practical point of view.. How/where
will the MTI delivery method be defined? Same with IETF police, maybe you=

misunderstood. I am not worried about implementors disregarding
recommendations. Since the unit for specifications are RFCs, how can some=

RFC be declared as MTI? In what context? Again, from a practical editoria=
l
point of view.


Speaking to one draft I worked on where we faced this decision, PKCE
Section 4.2 <https://tools.ietf.org/html/rfc7636#=
section-4.2> defined
two methods to transform the code challenge, plain text (no
transformation), and SHA256.

"S256" is declared as MTI in the spec, and "plain" is not. In this case
we actually say "Mandatory to Implement", but gating SHA256 with a "MUST"=

and the "plain" with a "MAY" would have achieved the same effect.

I advocated for making S256 MTI (when I first reviewed the draft, both
were given equal weighting) so that native app clients would not need to
perform discovery on the server to work out which method they can use (an=
d
provide additional API methods for the developer to specify the transform=

for servers that don't support discovery). Since SHA256 is MTI, all nativ=
e
app clients can rely on it being implemented.  And that's what AppAuth
does, it has no support for "plain", and doesn't bother with doing
discovery on the PKCE method, which greatly simplified the implementation=

(and it's completely seamless to users of AppAuth). As we required MTI on=

the more secure option of the two, this also resulted in more secure
implementations by default.

YMMV =E2=80=93 but that's what we did in that case :-)


Thanks William.

Yes, if both delivery methods are described in one draft then the draft
maybe declare one MTI and the other not. In this case the MTI is in the
context of the draft or RFC, in order to claim that you support the RFC y=
ou
have to respect the MTI.




But if the delivery methods are in separate drafts=
 then I don't see how
that can be done. You are claim to support one RFC or the other.


I agree with this logic. It's only relevant when multiple alternatives ar=
e
documented in a single RFC.  If there are conflicting opinions on which
should be MTI, and they're different enough, perhaps that is an indicatio=
n
that separate specifications would be better.

Another MTI example: OAuth 2.0 Section 2.3.1
<https://tools.ietf.org/html/rfc6749#section-2.3.=
1> mandates that servers
support HTTP Basic for client authentication, while also documenting
request-body for clients that are unable to use HTTP Basic Authentication=
=2E
AppAuth took advantage of this MTI too, by only authenticating using HTTP=

Basic, since it is capable of doing so, and this simplified the API surfa=
ce
substantially.

I hope neither method will become MTI.

An MTI would work well if the MTI method could potentially cover all delivery cases, and the other method extends or enhances the MTI with features. But in the case of HTTP push vs pull, we have two delivery methods intended to solve different use cases. Designating one of them MTI is a bit like making apples MTI for oranges.

Thanks,
Vladimir



This is all technical details on how MTI can be specified. The question i=
f
an MTI for delivery methods is desirable or not is totally different.







Guidance would be very useful IMO.

Thanks,
Marius


Marius

On Wed, Mar 21, 2018 at 9:05 AM, Yaron Sheffer <yaronf.ietf@gmail.com&=
gt;
wrote:


Hi Marius,

The decision about whether we need to have an MTI protocol and which
one it should be is up to the WG consensus, like everything else. But wit=
h
my WG chair hat on, it is my strong conviction that we need to have one M=
TI
method to encourage interoperability and reduce fragmentation. This is
based on my IETF experience, and not on any meta-document as far as I can=

tell. Just think of implementers that are not part of the WG, and just re=
ad
the RFCs two years from now. They need to have a clear message which meth=
od
will allow them the best (though maybe not perfect) interoperability. Als=
o,
I personally do not have a preference which of the methods becomes MTI..

It is common at the IETF to say that "there is no IETF police", in
other words if you choose to not implement an MTI protocol/feature, nobod=
y
is going to come after you and punish you. It is between you and your
market. I fully expect some of the WG participants to only implement the
non-MTI method.

We can absolutely ask the incoming AD for more guidance in this area.

I think keeping the two methods within the same document will speed up
and simplify the process, compared to running two docs in parallel. They =
do
have enough commonalities.

Thanks,
        Yaron

On 21/03/18 15:42, Marius Scurtescu wrote:


Thanks for the summary Phil.

Comments inline...

On Wed, Mar 21, 2018 at 6:43 AM, Phil Hunt <phil.hunt@oracle.com=

&=
lt;mailto:phil.hunt@oracle.com>> wrote:

    We held a couple of brief sessions over the last couple days.

    We talked about the issue of breaking up the delivery document,
    multiple delivery methods, and optionality.

    Some observations:

    1. Yaron indicated that the IETF will likely require one method be
    MTI (mandatory to implement).


It would be very useful to point to other working groups and specs
where this was the case.

What is the mechanism by which a specific delivery method is made MTI?
Which meta document specifies that?

What happens if a provider is not implementing the MTI delivery
method? What does that exactly mean?

Just trying to understand what the process is..


    While PUSH has better scale (because it does not need HTTP Long
    Polling), the POLL method has broader utility due to the presence
of
    receivers with firewalls, gateways (IoT devices), or are mobile
    applications that cannot implement endpoints to receive HTTP POSTs.


To me it is very unlikely that IoT or mobile devices will use POLL (or
PUSH). They will need some other delivery methods appropriate for their
architecture. Having the current PUSH or POLL mandatory for these cases
does not make sense to me,


    2.  If POLL is chosen as the MTI method, many will still likely
    prefer PUSH and so that will likely get implemented sooner by some


Many will simply not implement POLL if what they need is PUSH, and
vice versa. Again, I don't see how the working group can pick any deliver=
y
method and make it MTI. And MTI in what context?

Can we escalate this issue within IETF to get guidance?



    3.  There was a general feeling that the delivery draft should stay
    as one draft.


I don't see how that is helping, but if implementors can chose either
PUSH or POLL from the current draft then that's fine. But in that case
splitting should also be acceptable.



    Annabelle will present her recommendations at the formal meeting on
    Friday where we can get broader input.

    Thanks everyone.

    Phil

    Oracle Corporation, Identity Cloud Services Architect
    @independentid
    www.independentid.com <http://www.independentid.com>
    phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>


    _______________________________________________
    Id-event mailing list
    Id-event@ietf.org <mailto:Id-event@ietf.org>
    https://www.ietf.org/mailman/listinfo/id-event
    <https://www.ietf.org/mailman/listinfo/id-event&=
gt;




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



______________________________________________=
_
Id-event mailing list
I=
d-event@ietf.org
https://www.ietf.org/mailman/listinfo/id-event



        

        

      

      

      

      

      

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


    

    

  


--------------79F7299C54C023888A90FEAE--

--------------ms060605060604040901070000
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
CfwwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw
CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4
dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290
MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD
VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP
TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh
TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak
+FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC
ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr
vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC
ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC
4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud
HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs
Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz
ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj
mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb
4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ
26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT
9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl
tukWeh95FPZKEBom+nyK+5swggVFMIIELaADAgECAhAlSsBX16i/yGZZkfkyj/exMA0GCSqG
SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy
MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE
AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h
aWwgQ0EwHhcNMTcwNDA2MDAwMDAwWhcNMTgwNDA2MjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkB
Fhd2bGFkaW1pckBjb25uZWN0MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBAMHntIxpX2yNwHUcSrxfJihY9EtYTwC4VArv/C03YlEV92AQljLFYVKtRp+iKT8WDKo2
CqzPYaIHbKD0ivoou0qXQgv4yOk8rQxFmpTzCCe2c1KercueHfy595CnMz1u8GsQyblZqFMD
HmzoEvD1YZiI3FEh049tVixBnHwPD9fyiGlf8+QdjwmBLMQwdrrib7xcswNXKYIsfj6Qm5oa
d83bsz8VmYm5U39DbNPh01SzqAzwZt3jMuhy0su7lMs75lKYzWMA7b/9qrp40E3vR0yDvOn5
7Ijs+LFE2wPDTebVVfYT+m24e5/v/2w6sX5g/6oJsZnwPM737zIXV7x6jqECAwEAAaOCAfUw
ggHxMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBQA+4E14UMY
HyjzXHClSV9VfWHpPzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX
BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0w
OwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u
ZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E
T1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsG
AQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P
RE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG
AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJA
Y29ubmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBACYLv9z6ZOucvt5MlRhNY6SJISDN
880UmdH7IdeP2kJjS3GwuVaVUCQY/frypeIm3A+y0fKEVNJAJO7tfL88yOW4wjA9JMGokpy5
RswZ0uikkNSOt6CF3YGagsfr4VnrcoUxCH+FoGZcWvWYHajJy+QkVG2i6XvsTE7jv1PIsoDU
SJuCW+Dvg6iJI9Etpfv1ZrBeDEL05PkPBZfazKMj4MkVirkfbG3qgbzRzAb+7Vsm309NKQ+i
EUfoxt83ByC6+URLl3PoR2UTZv7M1JQmTtaQWe1LrAEKlBGHkfnSlxueLnmpCUJRS7Ldyfh5
60OdVFcB5twXPnYWtoZfdTlbv5oxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZ
BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR
Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo
ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAlSsBX16i/yGZZkfkyj/exMA0GCWCG
SAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xODAzMjMxMDUyMDJaMC8GCSqGSIb3DQEJBDEiBCDTrRpVH4b8Y0uICQQZQHtr0/h4kFuj
84ATqPLgXutMpDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw
CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD
VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP
TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQJUrAV9eov8hmWZH5Mo/3sTCBwwYLKoZI
hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo
ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw
PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy
ZSBFbWFpbCBDQQIQJUrAV9eov8hmWZH5Mo/3sTANBgkqhkiG9w0BAQEFAASCAQAqxsFd+eMG
PTdS4UD8kchcA0pKuYu/RRSdbNBwhaRTwRiWDvEvZEQwA2+VLSjxFxezejcUuAYBuiZ7n8Wq
TNkrUdHEUmme+UblC3P7b+adhbyuJ/ejNzvRjJyO+GlmOoKwpWfw5+vsNQYdpUrSOztgq7/p
ZvtLNsClVUylSerpdYvVaS3GfHyz4li2+atfqZTqQPMFPa7DGf/iMTLOy3zf/55IBsr87Qd8
7mP3NEGmHEa4QGNZGyrznzzi8cBUsFs/8ne6fTU5HzIpbgJY35rLK8f2kUng2/fleaaz4cyJ
btP3J6isQZYVHXE56m1YhifZC2QsiLjYD3j6mMgoOpeWAAAAAAAA
--------------ms060605060604040901070000--


From nobody Sat Mar 24 07:00:57 2018
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 B52BB12DA03 for ; Sat, 24 Mar 2018 07:00:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 sF5Gdhwg-Uio for ; Sat, 24 Mar 2018 07:00:36 -0700 (PDT)
Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 374C012D7E2 for ; Sat, 24 Mar 2018 07:00:36 -0700 (PDT)
Received: by mail-wr0-x233.google.com with SMTP id p53so7186930wrc.10 for ; Sat, 24 Mar 2018 07:00:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:references:from:to:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=kvrbf1Mhc3eWgCa+gla5KooRBPTRAzCkeSzQD1GKz38=; b=ufA2TPIRKry5cxvFO+cKPUCDtsapiXGRt1CL9AP1TgoFCHPm9c2EzBxe1WUQGkh7Wi WCXr7PjFKnzNayz43ywJH/GMaSev8hJuwE29lKmXZNQv9wNLRNaDyzYpCUY7WVt0AEKi 82pgpcuiMAHYfa0CQW/MS5F0Tswx67X5lJxdK3XlYIIjbbPcYfu+ijfvrGJ6XFaJWwle QcqExgozcX6iqsvJ4IbATJPishtuBAlJ5JduQxm5Z9wpRg2orYGYcvP+dNAlaQpiIf/f GUXjsANel6PzpdjEykr2hrHbeMuenULZeiWcN7fOQ2Q5V7YMDpjgdEy5LTIFUmJ27EFP fDQA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:from:to:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=kvrbf1Mhc3eWgCa+gla5KooRBPTRAzCkeSzQD1GKz38=; b=VbGSBDjC748atBlZxKCNQ3zFFwH1szXQ5VdMYGYCNA9wmQvgnsmaqmragT5uZxfXmJ HIWyB1pYSXLGCX9XM2TaqODl6s0mYFWbQwMHgZHOF81tD1+t4aKJl6qPZM9XZfrKJ3iP Xv3TQT/yO/Jk8chH+P9Fx6Yv28cZCx6lyjnB3WO4FJcGITIoZ7x+ec+pdMxliQ7PbJ3K LW01/VO3gZa9e5Ksa6DILVzX1OlrkyJuktky3YGnlya60CZ6W8iwiw4gw1oBaGIvQRTl /Ub5Q0M7dX5ybPbSem/OqpK1ibHLoXV3zwEUanSe6gTLDWCMhZxPzcdyTYBpkw7G3vSh 8JWA==
X-Gm-Message-State: AElRT7EBRZk+13DDiJvMZaIMITr0BF79F48DxbmNZDGXvW9jZlvjcEH9 aWadScI50tY2aL7JV0u8MxUTCZ+J
X-Google-Smtp-Source: AG47ELtxG66T9MNBvU5EMB9BuOLLv3+8Rc715ZstJ6QR5wS0t4wJ2oa34WWHe4RmQk+oYBrRmhHyVA==
X-Received: by 10.223.166.179 with SMTP id t48mr25810910wrc.161.1521900034201;  Sat, 24 Mar 2018 07:00:34 -0700 (PDT)
Received: from [10.0.0.149] (bzq-79-182-28-178.red.bezeqint.net. [79.182.28.178]) by smtp.gmail.com with ESMTPSA id n23sm11224876wra.14.2018.03.24.07.00.32 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 24 Mar 2018 07:00:33 -0700 (PDT)
References: <02e701d3c299$9c421e40$d4c65ac0$@smyslov.net>
From: Yaron Sheffer 
To: SecEvent 
X-Forwarded-Message-Id: <02e701d3c299$9c421e40$d4c65ac0$@smyslov.net>
Message-ID: 
Date: Sat, 24 Mar 2018 17:00:28 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <02e701d3c299$9c421e40$d4c65ac0$@smyslov.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [Id-event] SecEvent draft minutes - IETF-101 (London)
X-BeenThere: id-event@ietf.org
X-Mailman-Version: 2.1.22
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, 24 Mar 2018 14:00:43 -0000

Thank you Valery for taking the minutes. All, please let us know if 
anything is incorrect or missing.

In addition, we had a series of hums on the SET Delivery draft. Per IETF 
process, we need to validate them on the list. So if you weren't in the 
room and you have a major objection to the results of these hums, please 
speak up. I do suggest that before doing so, you review the actual 
recorded meeting: https://www.youtube.com/watch?v=r0hbpQqsN6s.

IETF 101 London Friday 23 March 2018 9:30 - 11:30

[Yaron] (WG status update, agenda bashing)
[Annabelle] asks for 10 minutes for discussion

[Mike] (presents Security Event Token draft update)

[Annabelle] (presents SET Token delivery using HTTP draft)
[Mike] Microsoft needs for both POLL and PUSH
[Phil] Redefining smth in HTTP may cause problems
[William] Return codes are only for browsers to display messages for users
[Phil] It's needed for resending in case of error (?)
[Annabelle] What is MTI - push or poll?
[Phil] With PUSH  happened immediately...
[Leif] What is MTI for server or for client?
[William] Each option has an explicit use case
[Yaron (as chair)] We need to have only one preferred option
[Phil] There are very different cases
[Phil] Push is simple, but in terms of applicability it's not a long 
term use case
[Annabelle] There use cases for both
[Phil] Take two and then abandon one
[William] Why does the chair require a single MTI
[Leif] It's from chair's experience, WG consensus needed
[William] We have use cases for both
[Mike] Procedurally it's better to keep both methods in one draft
[Yaron] Having two methods complicates the description which method is 
for which situation etc.
[William] Still have interoperability issue for receiver
[Yaron] Need to resolve this
[Leif] WG should decide
[Ben as AD] If the WG doesn't select a single method the IESG would 
probably object
[Annabelle] SET will probably be profiled for different use cases
[Yaron] Is going to make hums about selecting a single delivery method 
and whether we need to split the draft
[John] What is hum about - mandatory to implement or to deploy?
[Leif] We should analyze scenarios
[Annabelle] The protocol are unidirectional, so MTI for 
transmitter/receiver is problematic
[Justin] No negotiation, either it is or not, MTI for the receiver is
dictated by what the receiver supports
[Phil] They both must be able HTTP, the roles can be changed
[Leif] Confusion between MTI and to deploy, a good question - select MTI 
for transmitter
[Annabelle] Every transmitter should have both
[Tero] Minimal implementation requires one, bigger may have both, single 
MTI is better then two for limited devices
[Annabelle] IoT implementers have special requirement
[William] They are application specific, we expected profile this
[Yaron] Hum if we need a single MTI for transmitter - silence
Later edit: Clearly no support for a single MTI.
[Justin] Hum must be for multiple discrete options
[Yaron] Hum on use cases for two methods - some hums
[Yaron] Hum if both should be MTI - some hums
[Yaron] Hum if should not specify MTI - some hums
Later edit: room was split between two MTIs and no MTIs.
[Annabelle] We should split the spec
[Justin] Agree to split the spec
[Justin] I hummed for both MTI for transmitter, because they are not 
usually constrained
[Annabelle] SET is possibly to be used w/o HTTP, this is only MTI for 
those using HTTP; both MTI is problematic because implementers will do 
unnecessary stuff
[William] If both are MTI, we need 2 specs
[John] Splitting the spec is the best way
[Mike] If split, then the information for developers will be duplicated
[Ben] Why single document better (?)
[Mike] My experience with JOSE
[Annabelle] Significant overlap between documents is SET, otherwise 
little commonality
Later edit: existing editors volunteered to take Push-specific doc, 
Annabelle and Mike volunteered to work on Poll.
[from jabber] Little commonality between two methods
[Mike] We'll do both, we have use cases for both
[Yaron] Hum if split documents - some long hums
[Yaron] Hum if one document - some hums
[Yaron] Room is in favor of splitting the documents
[Yaron] Wrap up: no MTI, split the document into two, transmitter 
implements either or both

[Annabelle] (presenting Subject Identifier Types)
[Mike] 3rd party specifications cannot establish IANA registry
[Leif] IANA Expert?
[Ben] FCFS, doesn't need Expert, or specification required
[Leif] I support this idea
[William] I also support
[Yaron] Any objections to adopt this document? No objections, publish as 
WG document

[Annabelle] Expiration ("exp") claim is not recommended; however it has 
some value
[Mike] It's a layering violation; problems with caching
[Annabelle] We're not talking about caching, you don't want to grow 
anti-replay database forever, having expiration helps
[Phil] The past doesn't expire, it's up to receiver how to use it, 
caching doesn't make sense
[Yaron] What about replay protection?
[Mike] JTI helps to detect replay (?) [from jabber] Transport should 
deal with replay
[John] Expiry is expected to mean that token should not be processed 
after that, it's not an indication that information is no longer valid
[Mike] It must not be mandatory
[Annabelle] Currently the draft says it's not recommended
[Mike] We have to allow it to be optional because of the need to 
distinguish from access tokens.
[Ben] Some use case when processing expired token (?)
[John] Have an explicit expire for JTI, there are other solutions
[Phil] I prefer to add a new attribute to SET, not changing ...
[Yaron] The document in LC, smaller changes are OK without blocking the 
doc's progress.
[Phil] Replay and caching are different for PUSH and POLL, prefer to see 
in HTTP header
[Brian] Expiration is not necessary, receiver has policy to follow
[Annabelle] No-one is advocating using exp for caching
[from jabber] JTI expiration belongs to JTI not to transport
[Yaron] We're not ready to have hum, room thinks there is an issue, 
please work through it on the list.

[Phil] Presents his SSTP Delivery draft - symmetric transport protocol, 
parameters used in requests and response are same
[Phil] We would change optionality from two methods to a single one, may 
be a compromise
[Yaron] The protocol was only published yesterday, so we are not ready 
to discuss now.

[Meeting adjourned.]


From nobody Sat Mar 24 08:17:30 2018
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 AA4E8129C6D for ; Sat, 24 Mar 2018 08:17:29 -0700 (PDT)
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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRd-R0bMzcfM for ; Sat, 24 Mar 2018 08:17:27 -0700 (PDT)
Received: from aserp2120.oracle.com (aserp2120.oracle.com [141.146.126.78]) (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 7E2B612D0C3 for ; Sat, 24 Mar 2018 08:17:27 -0700 (PDT)
Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w2OFGx8e014477; Sat, 24 Mar 2018 15:17:25 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2017-10-26; bh=GxfDD20bfRikK2q7OPxPdqqANBgBmc4EYTQRiUAA6Yg=; b=cBOupPgu2a7FfJbyZLjRZkrKiQiqyMPF+z/OWu8B1yooE3gDt+tKSYD/meeVHLy5WtOf OH+3Nhfk9Igjx36bXXp/WtV+t/dRIGuH1IyEG9Fdunknf8Bny4nS/yDSI4TTLox9H9lb 7WBhhBWl09ETNFZJdk6wHMEwhAZDGz6DUv25KSrS1Gk/XApLqPWGbeonJLqacAmJ8E3q 5rSZ5xS+msw1fT3RxlUwKe8aKtb04yBJCylo4tE2Zq1XO4o3AZFQABlaPIdnCiwQN3/D n24uIPBSI/tnd2xA+DaH2MeMCREf8jBcXaYIG+8w1KRZHfWCarQyO5SPyU2Jq+GTfUWp jg== 
Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp2120.oracle.com with ESMTP id 2gws69r09x-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 24 Mar 2018 15:17:24 +0000
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w2OFCY9l001867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 24 Mar 2018 15:12:34 GMT
Received: from ubhmp0004.oracle.com (ubhmp0004.oracle.com [156.151.24.57]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w2OFCXk6004439; Sat, 24 Mar 2018 15:12:33 GMT
Received: from [10.0.1.20] (/24.86.190.97) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 24 Mar 2018 15:12:33 +0000
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Phil Hunt 
X-Mailer: iPhone Mail (15D100)
In-Reply-To: 
Date: Sat, 24 Mar 2018 08:12:30 -0700
Cc: SecEvent 
Content-Transfer-Encoding: quoted-printable
Message-Id: <7A07D274-B38B-462F-AA88-F7A02DC0EF0E@oracle.com>
References: <02e701d3c299$9c421e40$d4c65ac0$@smyslov.net> 
To: Yaron Sheffer 
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8841 signatures=668695
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803240180
Archived-At: 
Subject: Re: [Id-event] SecEvent draft minutes - IETF-101 (London)
X-BeenThere: id-event@ietf.org
X-Mailman-Version: 2.1.22
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, 24 Mar 2018 15:17:30 -0000

Some corrections for minutes inline regarding http status.=20

Phil

> On Mar 24, 2018, at 7:00 AM, Yaron Sheffer  wrote:
>=20
> Thank you Valery for taking the minutes. All, please let us know if anythi=
ng is incorrect or missing.
>=20
> In addition, we had a series of hums on the SET Delivery draft. Per IETF p=
rocess, we need to validate them on the list. So if you weren't in the room a=
nd you have a major objection to the results of these hums, please speak up.=
 I do suggest that before doing so, you review the actual recorded meeting: h=
ttps://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.youtube.com_watch-=
3Fv-3Dr0hbpQqsN6s&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=
&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DbZnIUtQK2S3enqQ3E8wJZHx=
LExg0UyssjEM1UAJ18jw&s=3DVbJxhADDKAULj3hrOYI1cbC5A8hEmFIesTvuGzkkOP0&e=3D.
>=20
> IETF 101 London Friday 23 March 2018 9:30 - 11:30
>=20
> [Yaron] (WG status update, agenda bashing)
> [Annabelle] asks for 10 minutes for discussion
>=20
> [Mike] (presents Security Event Token draft update)
>=20
> [Annabelle] (presents SET Token delivery using HTTP draft)
> [Mike] Microsoft needs for both POLL and PUSH
> [Phil] Redefining smth in HTTP may cause problems
Redefining status codes in http may cause problems
> [William] Return codes are only for browsers to display messages for users=

> [Phil] It's needed for resending in case of error (?)
There was some other discussion i believe it was about status 400 which info=
rms the client of jwt related error and that using status 403 would not let c=
lients be able to differentiate between authz error and jwt error.=20
> [Annabelle] What is MTI - push or poll?
> [Phil] With PUSH  happened immediately...
> [Leif] What is MTI for server or for client?
> [William] Each option has an explicit use case
> [Yaron (as chair)] We need to have only one preferred option
> [Phil] There are very different cases
> [Phil] Push is simple, but in terms of applicability it's not a long term u=
se case
> [Annabelle] There use cases for both
> [Phil] Take two and then abandon one
> [William] Why does the chair require a single MTI
> [Leif] It's from chair's experience, WG consensus needed
> [William] We have use cases for both
> [Mike] Procedurally it's better to keep both methods in one draft
> [Yaron] Having two methods complicates the description which method is for=
 which situation etc.
> [William] Still have interoperability issue for receiver
> [Yaron] Need to resolve this
> [Leif] WG should decide
> [Ben as AD] If the WG doesn't select a single method the IESG would probab=
ly object
> [Annabelle] SET will probably be profiled for different use cases
> [Yaron] Is going to make hums about selecting a single delivery method and=
 whether we need to split the draft
> [John] What is hum about - mandatory to implement or to deploy?
> [Leif] We should analyze scenarios
> [Annabelle] The protocol are unidirectional, so MTI for transmitter/receiv=
er is problematic
> [Justin] No negotiation, either it is or not, MTI for the receiver is
> dictated by what the receiver supports
> [Phil] They both must be able HTTP, the roles can be changed
> [Leif] Confusion between MTI and to deploy, a good question - select MTI f=
or transmitter
> [Annabelle] Every transmitter should have both
> [Tero] Minimal implementation requires one, bigger may have both, single M=
TI is better then two for limited devices
> [Annabelle] IoT implementers have special requirement
> [William] They are application specific, we expected profile this
> [Yaron] Hum if we need a single MTI for transmitter - silence
> Later edit: Clearly no support for a single MTI.
> [Justin] Hum must be for multiple discrete options
> [Yaron] Hum on use cases for two methods - some hums
> [Yaron] Hum if both should be MTI - some hums
> [Yaron] Hum if should not specify MTI - some hums
> Later edit: room was split between two MTIs and no MTIs.
> [Annabelle] We should split the spec
> [Justin] Agree to split the spec
> [Justin] I hummed for both MTI for transmitter, because they are not usual=
ly constrained
> [Annabelle] SET is possibly to be used w/o HTTP, this is only MTI for thos=
e using HTTP; both MTI is problematic because implementers will do unnecessa=
ry stuff
> [William] If both are MTI, we need 2 specs
> [John] Splitting the spec is the best way
> [Mike] If split, then the information for developers will be duplicated
> [Ben] Why single document better (?)
> [Mike] My experience with JOSE
> [Annabelle] Significant overlap between documents is SET, otherwise little=
 commonality
> Later edit: existing editors volunteered to take Push-specific doc, Annabe=
lle and Mike volunteered to work on Poll.
> [from jabber] Little commonality between two methods
> [Mike] We'll do both, we have use cases for both
> [Yaron] Hum if split documents - some long hums
> [Yaron] Hum if one document - some hums
> [Yaron] Room is in favor of splitting the documents
> [Yaron] Wrap up: no MTI, split the document into two, transmitter implemen=
ts either or both
>=20
> [Annabelle] (presenting Subject Identifier Types)
> [Mike] 3rd party specifications cannot establish IANA registry
> [Leif] IANA Expert?
> [Ben] FCFS, doesn't need Expert, or specification required
> [Leif] I support this idea
> [William] I also support
> [Yaron] Any objections to adopt this document? No objections, publish as W=
G document
>=20
> [Annabelle] Expiration ("exp") claim is not recommended; however it has so=
me value
> [Mike] It's a layering violation; problems with caching
> [Annabelle] We're not talking about caching, you don't want to grow anti-r=
eplay database forever, having expiration helps
> [Phil] The past doesn't expire, it's up to receiver how to use it, caching=
 doesn't make sense
> [Yaron] What about replay protection?
> [Mike] JTI helps to detect replay (?) [from jabber] Transport should deal w=
ith replay
> [John] Expiry is expected to mean that token should not be processed after=
 that, it's not an indication that information is no longer valid
> [Mike] It must not be mandatory
> [Annabelle] Currently the draft says it's not recommended
> [Mike] We have to allow it to be optional because of the need to distingui=
sh from access tokens.
> [Ben] Some use case when processing expired token (?)
> [John] Have an explicit expire for JTI, there are other solutions
> [Phil] I prefer to add a new attribute to SET, not changing ...
> [Yaron] The document in LC, smaller changes are OK without blocking the do=
c's progress.
> [Phil] Replay and caching are different for PUSH and POLL, prefer to see i=
n HTTP header
> [Brian] Expiration is not necessary, receiver has policy to follow
> [Annabelle] No-one is advocating using exp for caching
> [from jabber] JTI expiration belongs to JTI not to transport
> [Yaron] We're not ready to have hum, room thinks there is an issue, please=
 work through it on the list.
>=20
> [Phil] Presents his SSTP Delivery draft - symmetric transport protocol, pa=
rameters used in requests and response are same
> [Phil] We would change optionality from two methods to a single one, may b=
e a compromise
> [Yaron] The protocol was only published yesterday, so we are not ready to d=
iscuss now.
>=20
> [Meeting adjourned.]
>=20
> _______________________________________________
> Id-event mailing list
> Id-event@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma=
n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI=
_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DbZnIUtQK2S3enqQ3E8w=
JZHxLExg0UyssjEM1UAJ18jw&s=3Dbm9Kqkwb8W8ClkdHFvnnH60BmArjysl02dP_3TAjwew&e=3D=



From nobody Mon Mar 26 12:04:33 2018
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 254A11272E1 for ; Mon, 26 Mar 2018 12:04:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.81
X-Spam-Level: 
X-Spam-Status: No, score=-11.81 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BqiWrQ3_QrRQ for ; Mon, 26 Mar 2018 12:04:30 -0700 (PDT)
Received: from smtp-fw-6002.amazon.com (smtp-fw-6002.amazon.com [52.95.49.90]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1783127136 for ; Mon, 26 Mar 2018 12:04:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1522091069; x=1553627069; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=caF2WY7WTvQU5l5InzZyr6O79E3sq16gqZn5e5qoiPk=; b=suWmtxavwqWI34Z8SkWl9cRaA4/Gs7Lc0IJ5mQ/krRn2LRJLADLOfR9p grH3XsYkGnK/yb4CGG+GfzY4ywgJv5i+orOyMtHT39DPTyQ970gcSku2A 3uvuJctErPzDNbJosigfdIIu6M5GfzOUrO7BiPFaj+c9pFwlImkwg/TrF 0=;
X-IronPort-AV: E=Sophos;i="5.48,365,1517875200";  d="scan'208,217";a="337448513"
Received: from iad6-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-1d-2c665b5d.us-east-1.amazon.com) ([10.124.125.6]) by smtp-border-fw-out-6002.iad6.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA;  26 Mar 2018 19:04:28 +0000
Received: from EX13MTAUWC001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan2.iad.amazon.com [10.40.159.162]) by email-inbound-relay-1d-2c665b5d.us-east-1.amazon.com (8.14.7/8.14.7) with ESMTP id w2QJ4MYN005933 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 26 Mar 2018 19:04:27 GMT
Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Mon, 26 Mar 2018 19:04:26 +0000
Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC004.ant.amazon.com (10.43.162.101) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Mon, 26 Mar 2018 19:04:26 +0000
Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1236.000; Mon, 26 Mar 2018 19:04:26 +0000
From: "Richard Backman, Annabelle" 
To: Phil Hunt , ID Events Mailing List 
Thread-Topic: [Id-event] Fwd: New Version Notification for draft-hunt-secevent-sstp-00.txt
Thread-Index: AQHTwiDG4YAgvNIuZ0mislP7x3/e8KPicO2A
Date: Mon, 26 Mar 2018 19:04:26 +0000
Message-ID: <3EBBB751-65D9-4E8A-A0DB-3FF014C97438@amazon.com>
References: <152171640180.5660.17714250144971599335.idtracker@ietfa.amsl.com> <0593CC97-8C1E-458B-8058-2F13A45F66B3@oracle.com>
In-Reply-To: <0593CC97-8C1E-458B-8058-2F13A45F66B3@oracle.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.b.0.180311
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.43.160.36]
Content-Type: multipart/alternative; boundary="_000_3EBBB75165D94E8AA0DB3FF014C97438amazoncom_"
MIME-Version: 1.0
Precedence: Bulk
Archived-At: 
Subject: Re: [Id-event] Fwd: New Version Notification for draft-hunt-secevent-sstp-00.txt
X-BeenThere: id-event@ietf.org
X-Mailman-Version: 2.1.22
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, 26 Mar 2018 19:04:32 -0000

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

V2hpbGUgdGhlcmUgaXMgYSBjZXJ0YWluIHNpbXBsaWNpdHkgaW4gaGF2aW5nIGEgc2luZ2xlIHBy
b3RvY29sIHdoZXJlIGFsbCByZXF1ZXN0cyBhbmQgcmVzcG9uc2VzIGxvb2sgdGhlIHNhbWUsIHRo
aXMgc2ltcGxpY2l0eSBpcyBzdXBlcmZpY2lhbDsgdGhpcyBwcm90b2NvbCBoYXMgYWxsIHRoZSBz
YW1lIGNvbXBsZXhpdGllcyBhbmQgaW50ZXJvcCBjaGFsbGVuZ2VzIGFzIHRoZSB0d28gcHJvdG9j
b2wgYXBwcm9hY2gsIGFsYmVpdCBpbiBkaWZmZXJlbnQgZm9ybXMuIEFzIHdpdGggUHVzaC9Qb2xs
LCBTU1RQIGFsbG93cyBhbiBldmVudCB0cmFuc21pdHRlciB0byB0cmFuc21pdCByZXF1ZXN0cyBi
eSBhY3RpbmcgYXMgYW4gSFRUUCBjbGllbnQgKGkuZS4g4oCccHVzaOKAnSkgb3IgYXMgYW4gSFRU
UCBzZXJ2ZXIgKGkuZS4g4oCccHVsbOKAnSkuIEhvd2V2ZXIsIG5laXRoZXIgbW9kZSBpcyBNVEkg
Zm9yIFNTVFAgc28gc2F5aW5nIHNpbXBseSB0aGF0IOKAnEkgc3VwcG9ydCBTU1RQ4oCdIGlzIGlu
c3VmZmljaWVudCB0byBpbmZvcm0gb3RoZXJzIGhvdyB0byBpbnRlZ3JhdGUgd2l0aCB5b3UuIFRo
ZSBxdWVzdGlvbiBjaGFuZ2VzIGZyb20g4oCcd2hpY2ggcHJvdG9jb2wgZGlkIHlvdSBpbXBsZW1l
bnQ/4oCdIHRvIOKAnHdoaWNoIGZlYXR1cmVzIG9mIHRoZSBwcm90b2NvbCBkaWQgeW91IGltcGxl
bWVudD/igJ0gYnV0IHRoZSBxdWVzdGlvbiBzdGlsbCBoYXMgdG8gYmUgYW5zd2VyZWQuDQoNClNp
bWlsYXJseSBJIHRoaW5rIGJpLWRpcmVjdGlvbmFsaXR5IGlzIGZhciBsZXNzIHVzZWZ1bCBpbiBw
cmFjdGljZSB0aGFuIGl0IG1pZ2h0IHNlZW0uIEZvciB0aGUgdXNlIGNhc2VzIHRoYXQgd2XigJl2
ZSBiZWVuIGRpc2N1c3NpbmcgU0VUIHJlY2VwdGlvbiBpcyBsaWtlbHkgdG8gYmUgY2VudHJhbGl6
ZWQsIGVpdGhlciBhcyBhIHNpbmdsZSBlbmRwb2ludCB0aGF0IHJlY2VpdmVzIFNFVHMgb3IgYXMg
YSBzaW5nbGUgc3lzdGVtIHRoYXQgcG9sbHMgZm9yIFNFVHMsIGJ1dCBTRVQgZ2VuZXJhdGlvbiBp
cyBsaWtlbHkgdG8gYmUgZGlzdHJpYnV0ZWQsIGFzIGRpZmZlcmVudCBldmVudHMgb2NjdXIgaW4g
ZGlmZmVyZW50IHBsYWNlcyB3aXRoaW4gdGhlIGNsaWVudOKAmXMgYXJjaGl0ZWN0dXJlLiBBIGNs
aWVudCB3b3VsZCBoYXZlIHRvIHJlY29uY2lsZSB0aGlzIGNvbmZsaWN0IGluIG9yZGVyIGZvciB0
aGVtIHRvIG1ha2UgdXNlIG9mIFNTVFDigJlzIGJpLWRpcmVjdGlvbmFsaXR5LCBhbmQgdGhhdCBh
ZGRzIHNpZ25pZmljYW50IGNvbXBsZXhpdHkuIEZvciB0aGUgc2VydmVyLCBpdOKAmXMgbm90IHF1
aXRlIHNvIGJhZC4gU3VwcG9ydGluZyBiaS1kaXJlY3Rpb25hbCBTU1RQIGlzbuKAmXQgbXVjaCBt
b3JlIGNvbXBsZXggdGhhbiBzdXBwb3J0aW5nIEhUVFAgUG9sbC4gSG93ZXZlciwgaXQgZG9lcyB0
aWdodGx5IGNvdXBsZSB0aGUgc2VydmVy4oCZcyBTRVQgdHJhbnNtaXNzaW9uIGFuZCBTRVQgcmVj
ZXB0aW9uIHN5c3RlbXMgdG9nZXRoZXIsIHdoaWNoIGludHJvZHVjZXMgdW5uZWNlc3Nhcnkgb3Bl
cmF0aW9uYWwgcmlzayBmb3IgYm90aCBzeXN0ZW1zLiBGcm9tIGEgZnVuY3Rpb25hbCBzdGFuZHBv
aW50LCB0aGVyZSBpcyBubyByZWFzb24gdGhlc2UgdHdvIHN5c3RlbXMgbmVlZCB0byBkZXBlbmQg
b24gb25lIGFub3RoZXIuDQoNCi0tDQpBbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuDQpBbWF6b24g
4oCTIElkZW50aXR5IFNlcnZpY2VzDQoNCkZyb206IElkLWV2ZW50IDxpZC1ldmVudC1ib3VuY2Vz
QGlldGYub3JnPiBvbiBiZWhhbGYgb2YgUGhpbCBIdW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbT4N
CkRhdGU6IFRodXJzZGF5LCBNYXJjaCAyMiwgMjAxOCBhdCAyOjAwIFBNDQpUbzogSUQgRXZlbnRz
IE1haWxpbmcgTGlzdCA8aWQtZXZlbnRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbSWQtZXZlbnRdIEZ3
ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1odW50LXNlY2V2ZW50LXNzdHAt
MDAudHh0DQoNCkdpdmVuIHRoZSBkaXNjdXNzaW9uIGFyb3VuZCBoYXZpbmcgYSBzaW5nbGUgTVRJ
IG1ldGhvZCBmb3IgU0VUIERlbGl2ZXJ5LCBhbmQgY29uc2Vuc3VzIGlzc3VlIGVtZXJnaW5nIG9u
IGNob29zaW5nIFBVU0ggb3IgUFVMTCBmb3IgTVRJLCB0aGlzIGRyYWZ0IGlzIHN1Ym1pdHRlZCBh
cyBhICpjb21wcm9taXNlKiB3aGljaCBtZXJnZXMgYm90aCBtZXRob2RzIGludG8gYSBzaW5nbGUg
4oCcc3ltbWV0cmlj4oCdIGFwcHJvYWNoIGNhcGFibGUgb2YgYWRkcmVzc2luZyBib3RoIGNvbW11
bml0aWVzIGNvbmNlcm5zIGFuZCBhbGwgdXNlIGNhc2VzLiBUaGUgZHJhZnQgaGFzIDMgZXhhbXBs
ZXMgd2hpY2ggc2hvdyBob3cgUFVMTC1vbmx5LCBQVVNILW9ubHksIGFuZCBob3cgUFVTSC1QVUxM
IG1heSBiZSBhY2NvbXBsaXNoZWQgdXNpbmcgdGhlIHVuaWZpZWQgYXBwcm9hY2guDQoNCldoZXRo
ZXIg4oCccHVzaGluZ+KAnSAoZS5nLiBmcm9tIGFuIGlzc3VlciB0byBhIHJlY2VpdmVyIEhUVFAg
ZW5kcG9pbnQpIG9yIOKAnHB1bGxpbmfigJ0gKGJ5IGEgcmVjZWl2ZXIgZnJvbSBhbiBpc3N1ZXIg
SFRUUCBlbmRwb2ludCksIHRoZSBzYW1lIHRyYW5zZmVyIGFuZCByZXNwb25zZSBtZXRob2RzIGFu
ZCBmb3JtYXRzIGFyZSBhbHdheXMgdXNlZC4gIEJlY2F1c2UgZGVsaXZlcnkgY2FuIGJlIGVpdGhl
ciBkaXJlY3Rpb24gb3IgYm90aCBkaXJlY3Rpb25zLCB0aGUgc2VuZGVyIGFuZCByZWNlaXZlciBh
cmUgZnJlZSB0byBjaG9vc2Ugcm9sZSBhcyBIVFRQIENsaWVudCBvciBTZXJ2ZXIgYmFzZWQgb24g
dGhlIGVudmlyb25tZW50YWwgYW5kIG5ldHdvcmsgcmVzdHJpY3Rpb25zIHRoZXkgZmFjZS4NCg0K
V2hlcmUgcG9zc2libGUsIHdlIGhhdmUga2VwdCB0aGUgcHJvdG9jb2wgc2lnbmFsbGluZyBhbmQg
cmVzcG9uc2VzIHRoZSBzYW1lIG9yIHNpbXBsZXIuIFRocmVlIGNoYW5nZXMgaW4gcGFydGljdWxh
cjoNCiogVHJhbnNtaXR0ZXIvcmVjZWl2ZXIgdGVybWlub2xvZ3kgaXMgZHJvcHBlZCAoZHVlIHRv
IGJpLWRpcmVjdGlvbmFsaXR5KSBhbmQgcmVwbGFjZWQgd2l0aCBIVFRQIENsaWVudCB2cy4gSFRU
UC9TU1RQIFNlcnZlci4gKG5vbi1ub3JtYXRpdmUpDQoqIEJvdGggcHVzaGVycyBhbmQgcHVsbGVy
cyB1c2UgdGhlIHNhbWUgbXVsdGktU0VUIGZvcm1hdC4gIChub3JtYXRpdmUgY2hhbmdlIGZvciBQ
VVNIKQ0KKiBUaGUgZmxhZyBtYXhFdmVudHM9TiBpcyBub3cgcmVwbGFjZWQgd2l0aCBhIHNpbXBs
ZSBib29sZWFuIHJldHVybkV2ZW50cyBhbmQgbm93IGFsc28gYWxsb3dzIHRoZSBIVFRQIGNsaWVu
dCB0byBpbmRpY2F0ZSBpdCBkb2VzIG5vdCB3YW50IHRvIHB1bGwgZXZlbnRzDQoNClByZXZpb3Vz
IGZlYXR1cmVzIGFuZCBjYXBhYmlsaXR5KHN1Y2ggYXMgbXVsdGktdGhyZWFkaW5nKSBjaGFyYWN0
ZXJpc3RpY3MgaGF2ZSBiZWVuIHByZXNlcnZlZC4gRm9yIGV4YW1wbGUsIGVycm9yIHNpZ25hbGxp
bmcgd2FzIHRoZSBzYW1lIGZvciBib3RoIG1ldGhvZHMgYW5kIHJlbWFpbnMgdGhlIHNhbWUuDQoN
ClRvbnkgYW5kIEkgcmVjb2duaXplIHRoYXQgYXMgc2VwYXJhdGUgbWV0aG9kcywgdGhlcmUgY291
bGQgYmUgbW9yZSBvcHRpbWl6YXRpb24uIEZvciBleGFtcGxlLCBpbiBQVVNIIG1vZGUsIHJlY2Vp
dmVycyBub3cgaGF2ZSB0byBwcm9jZXNzIGEgSlNPTiBzdHJ1Y3R1cmUgdGhhdCBjb250YWlucyBt
dWx0aXBsZSBTRVRzIHZzLiBqdXN0IHBhcnNpbmcgb25lIHNldC4gV2UgY29uc2lkZXJlZCBwcmVz
ZXJ2aW5nIHNpbmdsZS1ldmVudCAoYXBwbGljYXRpb24vand0KSBmb3JtYXQsIGFuZCBjb3VsZCBz
dGlsbCBkbyBzby4gSG93ZXZlciwgaGF2aW5nIG11bHRpcGxlIGNvbnRlbnQtdHlwZXMgc2VlbXMg
dG8gYWRkIHVubmVjZXNzYXJ5IGNvbXBsZXhpdHkgYW5kIG1vcmUgaW1wbGVtZW50ZXIgY29kaW5n
Lg0KDQpCZXN0IFJlZ2FyZHMsDQoNClBoaWwNCg0KT3JhY2xlIENvcnBvcmF0aW9uLCBJZGVudGl0
eSBDbG91ZCBTZXJ2aWNlcyBBcmNoaXRlY3QNCkBpbmRlcGVuZGVudGlkDQp3d3cuaW5kZXBlbmRl
bnRpZC5jb208aHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNvbT4NCnBoaWwuaHVudEBvcmFjbGUu
Y29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4NCg0KDQpCZWdpbiBmb3J3YXJkZWQgbWVz
c2FnZToNCg0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1k
cmFmdHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRy
YWZ0LWh1bnQtc2VjZXZlbnQtc3N0cC0wMC50eHQNCkRhdGU6IE1hcmNoIDIyLCAyMDE4IGF0IDEx
OjAwOjAxIEFNIEdNVA0KVG86ICJQaGlsIEh1bnQiIDxwaGlsLmh1bnRAeWFob28uY29tPG1haWx0
bzpwaGlsLmh1bnRAeWFob28uY29tPj4sICJBbnRob255IE5hZGFsaW4iIDx0b255bmFkQG1pY3Jv
c29mdC5jb208bWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbT4+DQoNCg0KQSBuZXcgdmVyc2lv
biBvZiBJLUQsIGRyYWZ0LWh1bnQtc2VjZXZlbnQtc3N0cC0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nl
c3NmdWxseSBzdWJtaXR0ZWQgYnkgUGhpbCBIdW50IGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJl
cG9zaXRvcnkuDQoNCk5hbWU6IGRyYWZ0LWh1bnQtc2VjZXZlbnQtc3N0cA0KUmV2aXNpb246IDAw
DQpUaXRsZTogU3ltbWV0cmljIFNFVCBUcmFuc2ZlciBQcm90b2NvbA0KRG9jdW1lbnQgZGF0ZTog
MjAxOC0wMy0yMg0KR3JvdXA6IEluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6IDIzDQpVUkw6
ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWh1
bnQtc2VjZXZlbnQtc3N0cC0wMC50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFj
a2VyLmlldGYub3JnL2RvYy9kcmFmdC1odW50LXNlY2V2ZW50LXNzdHAvDQpIdG1saXplZDogICAg
ICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWh1bnQtc2VjZXZlbnQtc3N0cC0w
MA0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwv
ZHJhZnQtaHVudC1zZWNldmVudC1zc3RwDQoNCg0KQWJzdHJhY3Q6DQogIFRoaXMgc3BlY2lmaWNh
dGlvbiBkZWZpbmVzIGhvdyBzZWN1cml0eSBldmVudCB0b2tlbnMgKFNFVHMpIG1heSBiZQ0KICBl
eGNoYW5nZWQgYmV0d2VlbiBhIGNsaWVudCBhbmQgc2VydmljZSBwcm92aWRlciB1c2luZyBIVFRQ
IFBPU1Qgb3Zlcg0KICBUTFMgdXNpbmcgYSBzeW1tZXRyaWMgZm9ybWF0LiAgVGhlIHNwZWNpZmlj
YXRpb24gc3VwcG9ydHMgdGhyZWUgbW9kZXMNCiAgb2Ygb3BlcmF0aW9uOiAicHVzaCIsICJwdWxs
IiwgYW5kICJwdXNoLXB1bGwiIGJpLWRpcmVjdGlvbmFsIFNFVA0KICBleGNoYW5nZS4gIFRoZSBz
cGVjaWZpY2F0aW9uIGFsc28gZGVmaW5lcyBhIHNpbXBsZSBhY2tub3dsZWRnZQ0KICBtZWNoYW5p
c20gYWxsb3dpbmcgcGFydGllcyB0byBjb25maXJtIGRlbGl2ZXJ5Lg0KDQoNCg0KDQpQbGVhc2Ug
bm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBv
ZiBzdWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZh
aWxhYmxlIGF0IHRvb2xzLmlldGYub3JnPGh0dHA6Ly90b29scy5pZXRmLm9yZz4uDQoNClRoZSBJ
RVRGIFNlY3JldGFyaWF0DQoNCg==

--_000_3EBBB75165D94E8AA0DB3FF014C97438amazoncom_
Content-Type: text/html; charset="utf-8"
Content-ID: <3222C3CEFFD7684F81B564232F4716B6@amazon.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg
bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2
IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy
IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJIZWx2ZXRp
Y2EgTmV1ZSI7DQoJcGFub3NlLTE6MiAwIDUgMyAwIDAgMCAyIDAgNDt9DQovKiBTdHlsZSBEZWZp
bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt
YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0K
CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBl
cmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNv
cmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQN
Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRp
b246dW5kZXJsaW5lO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1h
bDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv
Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy
Z2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki
LHNhbnMtc2VyaWY7fQ0Kc3Bhbi5hcHBsZS1zdHlsZS1zcGFuDQoJe21zby1zdHlsZS1uYW1lOmFw
cGxlLXN0eWxlLXNwYW47fQ0Kc3Bhbi5hcHBsZS10YWItc3Bhbg0KCXttc28tc3R5bGUtbmFtZTph
cHBsZS10YWItc3Bhbjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJz
b25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3
aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5
Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g
MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp
b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBs
YW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3Jk
U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hpbGUgdGhlcmUgaXMgYSBjZXJ0YWlu
IHNpbXBsaWNpdHkgaW4gaGF2aW5nIGEgc2luZ2xlIHByb3RvY29sIHdoZXJlIGFsbCByZXF1ZXN0
cyBhbmQgcmVzcG9uc2VzIGxvb2sgdGhlIHNhbWUsIHRoaXMgc2ltcGxpY2l0eSBpcyBzdXBlcmZp
Y2lhbDsgdGhpcyBwcm90b2NvbCBoYXMgYWxsIHRoZSBzYW1lIGNvbXBsZXhpdGllcyBhbmQgaW50
ZXJvcCBjaGFsbGVuZ2VzIGFzIHRoZSB0d28gcHJvdG9jb2wgYXBwcm9hY2gsDQogYWxiZWl0IGlu
IGRpZmZlcmVudCBmb3Jtcy4gQXMgd2l0aCBQdXNoL1BvbGwsIFNTVFAgYWxsb3dzIGFuIGV2ZW50
IHRyYW5zbWl0dGVyIHRvIHRyYW5zbWl0IHJlcXVlc3RzIGJ5IGFjdGluZyBhcyBhbiBIVFRQIGNs
aWVudCAoaS5lLiDigJxwdXNo4oCdKSBvciBhcyBhbiBIVFRQIHNlcnZlciAoaS5lLiDigJxwdWxs
4oCdKS4gSG93ZXZlciwgbmVpdGhlciBtb2RlIGlzIE1USSBmb3IgU1NUUCBzbyBzYXlpbmcgc2lt
cGx5IHRoYXQg4oCcSSBzdXBwb3J0IFNTVFDigJ0gaXMNCiBpbnN1ZmZpY2llbnQgdG8gaW5mb3Jt
IG90aGVycyBob3cgdG8gaW50ZWdyYXRlIHdpdGggeW91LiBUaGUgcXVlc3Rpb24gY2hhbmdlcyBm
cm9tIOKAnHdoaWNoIHByb3RvY29sIGRpZCB5b3UgaW1wbGVtZW50P+KAnSB0byDigJx3aGljaCBm
ZWF0dXJlcyBvZiB0aGUgcHJvdG9jb2wgZGlkIHlvdSBpbXBsZW1lbnQ/4oCdIGJ1dCB0aGUgcXVl
c3Rpb24gc3RpbGwgaGFzIHRvIGJlIGFuc3dlcmVkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5T
aW1pbGFybHkgSSB0aGluayBiaS1kaXJlY3Rpb25hbGl0eSBpcyBmYXIgbGVzcyB1c2VmdWwgaW4g
cHJhY3RpY2UgdGhhbiBpdCBtaWdodCBzZWVtLiBGb3IgdGhlIHVzZSBjYXNlcyB0aGF0IHdl4oCZ
dmUgYmVlbiBkaXNjdXNzaW5nIFNFVCByZWNlcHRpb24gaXMgbGlrZWx5IHRvIGJlIGNlbnRyYWxp
emVkLCBlaXRoZXIgYXMgYSBzaW5nbGUgZW5kcG9pbnQgdGhhdCByZWNlaXZlcyBTRVRzIG9yIGFz
IGEgc2luZ2xlDQogc3lzdGVtIHRoYXQgcG9sbHMgZm9yIFNFVHMsIGJ1dCBTRVQgZ2VuZXJhdGlv
biBpcyBsaWtlbHkgdG8gYmUgZGlzdHJpYnV0ZWQsIGFzIGRpZmZlcmVudCBldmVudHMgb2NjdXIg
aW4gZGlmZmVyZW50IHBsYWNlcyB3aXRoaW4gdGhlIGNsaWVudOKAmXMgYXJjaGl0ZWN0dXJlLiBB
IGNsaWVudCB3b3VsZCBoYXZlIHRvIHJlY29uY2lsZSB0aGlzIGNvbmZsaWN0IGluIG9yZGVyIGZv
ciB0aGVtIHRvIG1ha2UgdXNlIG9mIFNTVFDigJlzIGJpLWRpcmVjdGlvbmFsaXR5LA0KIGFuZCB0
aGF0IGFkZHMgc2lnbmlmaWNhbnQgY29tcGxleGl0eS4gRm9yIHRoZSBzZXJ2ZXIsIGl04oCZcyBu
b3QgcXVpdGUgc28gYmFkLiBTdXBwb3J0aW5nIGJpLWRpcmVjdGlvbmFsIFNTVFAgaXNu4oCZdCBt
dWNoIG1vcmUgY29tcGxleCB0aGFuIHN1cHBvcnRpbmcgSFRUUCBQb2xsLiBIb3dldmVyLCBpdCBk
b2VzIHRpZ2h0bHkgY291cGxlIHRoZSBzZXJ2ZXLigJlzIFNFVCB0cmFuc21pc3Npb24gYW5kIFNF
VCByZWNlcHRpb24gc3lzdGVtcyB0b2dldGhlciwNCiB3aGljaCBpbnRyb2R1Y2VzIHVubmVjZXNz
YXJ5IG9wZXJhdGlvbmFsIHJpc2sgZm9yIGJvdGggc3lzdGVtcy4gRnJvbSBhIGZ1bmN0aW9uYWwg
c3RhbmRwb2ludCwgdGhlcmUgaXMgbm8gcmVhc29uIHRoZXNlIHR3byBzeXN0ZW1zIG5lZWQgdG8g
ZGVwZW5kIG9uIG9uZSBhbm90aGVyLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv
bWFuJnF1b3Q7LHNlcmlmIj4tLSZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+QW5uYWJlbGxlIFJpY2hhcmQgQmFja21h
bjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90
OyxzZXJpZiI+QW1hem9uIOKAkyBJZGVudGl0eSBTZXJ2aWNlczxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk
ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+SWQtZXZlbnQgJmx0O2lkLWV2
ZW50LWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBQaGlsIEh1bnQgJmx0O3BoaWwu
aHVudEBvcmFjbGUuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UaHVyc2RheSwgTWFyY2ggMjIs
IDIwMTggYXQgMjowMCBQTTxicj4NCjxiPlRvOiA8L2I+SUQgRXZlbnRzIE1haWxpbmcgTGlzdCAm
bHQ7aWQtZXZlbnRAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPltJZC1ldmVudF0g
RndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWh1bnQtc2VjZXZlbnQtc3N0
cC0wMC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PGEgbmFtZT0iX01haWxPcmlnaW5hbEJvZHkiPkdpdmVuIHRoZSBkaXNjdXNzaW9uIGFy
b3VuZCBoYXZpbmcgYSBzaW5nbGUgTVRJIG1ldGhvZCBmb3IgU0VUIERlbGl2ZXJ5LCBhbmQgY29u
c2Vuc3VzIGlzc3VlIGVtZXJnaW5nIG9uIGNob29zaW5nIFBVU0ggb3IgUFVMTCBmb3IgTVRJLCB0
aGlzIGRyYWZ0IGlzIHN1Ym1pdHRlZCBhcyBhICpjb21wcm9taXNlKiB3aGljaCBtZXJnZXMgYm90
aCBtZXRob2RzIGludG8NCiBhIHNpbmdsZSDigJxzeW1tZXRyaWPigJ0gYXBwcm9hY2ggY2FwYWJs
ZSBvZiBhZGRyZXNzaW5nIGJvdGggY29tbXVuaXRpZXMgY29uY2VybnMgYW5kIGFsbCB1c2UgY2Fz
ZXMuIFRoZSBkcmFmdCBoYXMgMyBleGFtcGxlcyB3aGljaCBzaG93IGhvdyBQVUxMLW9ubHksIFBV
U0gtb25seSwgYW5kIGhvdyBQVVNILVBVTEwgbWF5IGJlIGFjY29tcGxpc2hlZCB1c2luZyB0aGUg
dW5pZmllZCBhcHByb2FjaC4NCjxvOnA+PC9vOnA+PC9hPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmln
aW5hbEJvZHkiPldoZXRoZXIg4oCccHVzaGluZ+KAnSAoZS5nLiBmcm9tIGFuIGlzc3VlciB0byBh
IHJlY2VpdmVyIEhUVFAgZW5kcG9pbnQpIG9yIOKAnHB1bGxpbmfigJ0gKGJ5IGEgcmVjZWl2ZXIg
ZnJvbSBhbiBpc3N1ZXIgSFRUUCBlbmRwb2ludCksIHRoZSBzYW1lIHRyYW5zZmVyIGFuZCByZXNw
b25zZSBtZXRob2RzIGFuZCBmb3JtYXRzIGFyZSBhbHdheXMgdXNlZC4NCiAmbmJzcDtCZWNhdXNl
IGRlbGl2ZXJ5IGNhbiBiZSBlaXRoZXIgZGlyZWN0aW9uIG9yIGJvdGggZGlyZWN0aW9ucywgdGhl
IHNlbmRlciBhbmQgcmVjZWl2ZXIgYXJlIGZyZWUgdG8gY2hvb3NlIHJvbGUgYXMgSFRUUCBDbGll
bnQgb3IgU2VydmVyIGJhc2VkIG9uIHRoZSBlbnZpcm9ubWVudGFsIGFuZCBuZXR3b3JrIHJlc3Ry
aWN0aW9ucyB0aGV5IGZhY2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdp
bmFsQm9keSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFs
Qm9keSI+V2hlcmUgcG9zc2libGUsIHdlIGhhdmUga2VwdCB0aGUgcHJvdG9jb2wgc2lnbmFsbGlu
ZyBhbmQgcmVzcG9uc2VzIHRoZSBzYW1lIG9yIHNpbXBsZXIuIFRocmVlIGNoYW5nZXMgaW4gcGFy
dGljdWxhcjombmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxC
b2R5Ij4qIFRyYW5zbWl0dGVyL3JlY2VpdmVyIHRlcm1pbm9sb2d5IGlzIGRyb3BwZWQgKGR1ZSB0
byBiaS1kaXJlY3Rpb25hbGl0eSkgYW5kIHJlcGxhY2VkIHdpdGggSFRUUCBDbGllbnQgdnMuIEhU
VFAvU1NUUCBTZXJ2ZXIuIChub24tbm9ybWF0aXZlKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21h
cms6X01haWxPcmlnaW5hbEJvZHkiPiogQm90aCBwdXNoZXJzIGFuZCBwdWxsZXJzIHVzZSB0aGUg
c2FtZSBtdWx0aS1TRVQgZm9ybWF0LiAmbmJzcDsobm9ybWF0aXZlIGNoYW5nZSBmb3IgUFVTSCk8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4qIFRoZSBmbGFn
IG1heEV2ZW50cz1OIGlzIG5vdyByZXBsYWNlZCB3aXRoIGEgc2ltcGxlIGJvb2xlYW4gcmV0dXJu
RXZlbnRzIGFuZCBub3cgYWxzbyBhbGxvd3MgdGhlIEhUVFAgY2xpZW50IHRvIGluZGljYXRlIGl0
IGRvZXMgbm90IHdhbnQgdG8gcHVsbCBldmVudHMmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJv
b2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2tt
YXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5QcmV2aW91cyBmZWF0dXJlcyBhbmQgY2FwYWJpbGl0eShz
dWNoIGFzIG11bHRpLXRocmVhZGluZykgY2hhcmFjdGVyaXN0aWNzIGhhdmUgYmVlbiBwcmVzZXJ2
ZWQuIEZvciBleGFtcGxlLCBlcnJvciBzaWduYWxsaW5nIHdhcyB0aGUgc2FtZSBmb3IgYm90aCBt
ZXRob2RzIGFuZCByZW1haW5zIHRoZSBzYW1lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6
X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01h
aWxPcmlnaW5hbEJvZHkiPlRvbnkgYW5kIEkgcmVjb2duaXplIHRoYXQgYXMgc2VwYXJhdGUgbWV0
aG9kcywgdGhlcmUgY291bGQgYmUgbW9yZSBvcHRpbWl6YXRpb24uIEZvciBleGFtcGxlLCBpbiBQ
VVNIIG1vZGUsIHJlY2VpdmVycyBub3cgaGF2ZSB0byBwcm9jZXNzIGEgSlNPTiBzdHJ1Y3R1cmUg
dGhhdCBjb250YWlucyBtdWx0aXBsZSBTRVRzIHZzLiBqdXN0DQogcGFyc2luZyBvbmUgc2V0LiBX
ZSBjb25zaWRlcmVkIHByZXNlcnZpbmcgc2luZ2xlLWV2ZW50IChhcHBsaWNhdGlvbi9qd3QpIGZv
cm1hdCwgYW5kIGNvdWxkIHN0aWxsIGRvIHNvLiBIb3dldmVyLCBoYXZpbmcgbXVsdGlwbGUgY29u
dGVudC10eXBlcyBzZWVtcyB0byBhZGQgdW5uZWNlc3NhcnkgY29tcGxleGl0eSBhbmQgbW9yZSBp
bXBsZW1lbnRlciBjb2RpbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdp
bmFsQm9keSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFs
Qm9keSI+QmVzdCBSZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmln
aW5hbEJvZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJr
Ol9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlBoaWw8bzpwPjwv
bzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5
bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFy
azpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5PcmFjbGUgQ29y
cG9yYXRpb24sIElkZW50aXR5IENsb3VkIFNlcnZpY2VzIEFyY2hpdGVjdDxvOnA+PC9vOnA+PC9z
cGFuPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iY29s
b3I6YmxhY2siPkBpbmRlcGVuZGVudGlkPG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21h
cms6X01haWxPcmlnaW5hbEJvZHkiPjwvc3Bhbj48YSBocmVmPSJodHRwOi8vd3d3LmluZGVwZW5k
ZW50aWQuY29tIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij53
d3cuaW5kZXBlbmRlbnRpZC5jb208L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFp
bE9yaWdpbmFsQm9keSI+PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWls
T3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFu
Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjwv
c3Bhbj48YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iPjxzcGFuIHN0eWxlPSJt
c28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9zcGFu
PjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjwvc3Bhbj48L2E+
PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9
ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5
Ij48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0i
bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5C
ZWdpbiBmb3J3YXJkZWQgbWVzc2FnZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5h
bEJvZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48Yj48
c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDsiPkZyb206
DQo8L3NwYW4+PC9iPjwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2lu
YWxCb2R5Ij48L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyI+
PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9
ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7Ij5pbnRlcm5ldC1kcmFmdHNA
aWV0Zi5vcmc8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmln
aW5hbEJvZHkiPjwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdp
bmFsQm9keSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+
PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7Ij5T
dWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWh1bnQtc2VjZXZlbnQt
c3N0cC0wMC50eHQ8L3NwYW4+PC9iPjwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9N
YWlsT3JpZ2luYWxCb2R5Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2lu
YWxCb2R5Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUm
cXVvdDsiPkRhdGU6DQo8L3NwYW4+PC9iPjwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJr
Ol9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0
aWNhIE5ldWUmcXVvdDsiPk1hcmNoIDIyLCAyMDE4IGF0IDExOjAwOjAxIEFNIEdNVDwvc3Bhbj48
L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD48
L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PGI+PHNwYW4gc3R5bGU9
ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7Ij5UbzoNCjwvc3Bhbj48L2I+
PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxzcGFu
IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OyI+JnF1b3Q7UGhp
bCBIdW50JnF1b3Q7ICZsdDs8L3NwYW4+PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRA
eWFob28uY29tIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48
c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDsiPnBoaWwu
aHVudEB5YWhvby5jb208L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01h
aWxPcmlnaW5hbEJvZHkiPjwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFp
bE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBO
ZXVlJnF1b3Q7Ij4mZ3Q7LA0KICZxdW90O0FudGhvbnkgTmFkYWxpbiZxdW90OyAmbHQ7PC9zcGFu
Pjwvc3Bhbj48YSBocmVmPSJtYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tIj48c3BhbiBzdHls
ZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1p
bHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDsiPnRvbnluYWRAbWljcm9zb2Z0LmNvbTwvc3Bh
bj48L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PC9z
cGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3Bh
biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDsiPiZndDs8L3Nw
YW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy
Z2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5h
bEJvZHkiPjxicj4NCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1odW50LXNlY2V2ZW50LXNz
dHAtMDAudHh0PGJyPg0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBQaGlsIEh1
bnQgYW5kIHBvc3RlZCB0byB0aGU8YnI+DQpJRVRGIHJlcG9zaXRvcnkuPGJyPg0KPGJyPg0KTmFt
ZTo8c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiA8L3NwYW4+ZHJhZnQtaHVudC1zZWNldmVu
dC1zc3RwPGJyPg0KUmV2aXNpb246PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4gPC9zcGFu
PjAwPGJyPg0KVGl0bGU6PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4gPC9zcGFuPlN5bW1l
dHJpYyBTRVQgVHJhbnNmZXIgUHJvdG9jb2w8YnI+DQpEb2N1bWVudCBkYXRlOjxzcGFuIGNsYXNz
PSJhcHBsZS10YWItc3BhbiI+IDwvc3Bhbj4yMDE4LTAzLTIyPGJyPg0KR3JvdXA6PHNwYW4gY2xh
c3M9ImFwcGxlLXRhYi1zcGFuIj4gPC9zcGFuPkluZGl2aWR1YWwgU3VibWlzc2lvbjxicj4NClBh
Z2VzOjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+IDwvc3Bhbj4yMzxicj4NClVSTDogJm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0
cy9kcmFmdC1odW50LXNlY2V2ZW50LXNzdHAtMDAudHh0Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2tt
YXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5odHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm
dHMvZHJhZnQtaHVudC1zZWNldmVudC1zc3RwLTAwLnR4dDwvc3Bhbj48c3BhbiBzdHlsZT0ibXNv
LWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJtc28t
Ym9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxicj4NClN0YXR1czogJm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8v
ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWh1bnQtc2VjZXZlbnQtc3N0cC8iPjxzcGFu
IHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPmh0dHBzOi8vZGF0YXRyYWNr
ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWh1bnQtc2VjZXZlbnQtc3N0cC88L3NwYW4+PHNwYW4gc3R5
bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PC9zcGFuPjwvYT48c3BhbiBzdHls
ZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48YnI+DQpIdG1saXplZDogJm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vdG9v
bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1odW50LXNlY2V2ZW50LXNzdHAtMDAiPjxzcGFuIHN0eWxl
PSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv
aHRtbC9kcmFmdC1odW50LXNlY2V2ZW50LXNzdHAtMDA8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1i
b29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJv
b2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48YnI+DQpIdG1saXplZDogJm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIu
aWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaHVudC1zZWNldmVudC1zc3RwIj48c3BhbiBzdHlsZT0i
bXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5odHRwczovL2RhdGF0cmFja2VyLmlldGYu
b3JnL2RvYy9odG1sL2RyYWZ0LWh1bnQtc2VjZXZlbnQtc3N0cDwvc3Bhbj48c3BhbiBzdHlsZT0i
bXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJt
c28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxicj4NCjxicj4NCjxicj4NCkFic3RyYWN0
Ojxicj4NCiZuYnNwOyZuYnNwO1RoaXMgc3BlY2lmaWNhdGlvbiBkZWZpbmVzIGhvdyBzZWN1cml0
eSBldmVudCB0b2tlbnMgKFNFVHMpIG1heSBiZTxicj4NCiZuYnNwOyZuYnNwO2V4Y2hhbmdlZCBi
ZXR3ZWVuIGEgY2xpZW50IGFuZCBzZXJ2aWNlIHByb3ZpZGVyIHVzaW5nIEhUVFAgUE9TVCBvdmVy
PGJyPg0KJm5ic3A7Jm5ic3A7VExTIHVzaW5nIGEgc3ltbWV0cmljIGZvcm1hdC4gJm5ic3A7VGhl
IHNwZWNpZmljYXRpb24gc3VwcG9ydHMgdGhyZWUgbW9kZXM8YnI+DQombmJzcDsmbmJzcDtvZiBv
cGVyYXRpb246ICZxdW90O3B1c2gmcXVvdDssICZxdW90O3B1bGwmcXVvdDssIGFuZCAmcXVvdDtw
dXNoLXB1bGwmcXVvdDsgYmktZGlyZWN0aW9uYWwgU0VUPGJyPg0KJm5ic3A7Jm5ic3A7ZXhjaGFu
Z2UuICZuYnNwO1RoZSBzcGVjaWZpY2F0aW9uIGFsc28gZGVmaW5lcyBhIHNpbXBsZSBhY2tub3ds
ZWRnZTxicj4NCiZuYnNwOyZuYnNwO21lY2hhbmlzbSBhbGxvd2luZyBwYXJ0aWVzIHRvIGNvbmZp
cm0gZGVsaXZlcnkuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KUGxlYXNlIG5vdGUgdGhh
dCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlz
c2lvbjxicj4NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFi
bGUgYXQgPC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZyI+PHNwYW4gc3R5bGU9
Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+dG9vbHMuaWV0Zi5vcmc8L3NwYW4+PHNw
YW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PC9zcGFuPjwvYT48c3Bh
biBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4uPGJyPg0KPGJyPg0KVGhl
IElFVEYgU2VjcmV0YXJpYXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
bXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_3EBBB75165D94E8AA0DB3FF014C97438amazoncom_--


From nobody Tue Mar 27 13:45:12 2018
Return-Path: 
X-Original-To: id-event@ietf.org
Delivered-To: id-event@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E8C012E878; Tue, 27 Mar 2018 13:44:55 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Russ Housley 
To: 
Cc: draft-ietf-secevent-token.all@ietf.org, ietf@ietf.org, id-event@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.76.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <152218349510.5239.9026903316972844190@ietfa.amsl.com>
Date: Tue, 27 Mar 2018 13:44:55 -0700
Archived-At: 
Subject: [Id-event] Secdir telechat review of draft-ietf-secevent-token-07
X-BeenThere: id-event@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 27 Mar 2018 20:45:03 -0000

Reviewer: Russ Housley
Review result: Has Issues

I reviewed this document as part of the Security Directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the Security Area
Directors.  Document authors, document editors, and WG chairs should
treat these comments just like any other IETF Last Call comments.

Document: draft-ietf-secevent-token-07
Reviewer: Russ Housley
Review Date: 2018-03-27
IETF LC End Date: unknown
IESG Telechat date: 2018-05-10

Summary: Has Issues

Process concern

A request for a telechat review of draft-ietf-secevent-token was
assigned to me.  However, there has not yet been an IETF Last Call
announced for this document.


Major Concerns

All of the examples in Section 2.1 are non-normative.  Instead of
staying that in each of the subsections, please add some text at the
top of Section 2.1 that says so.

I do not understand the first paragraph of Section 3.  I think you are
trying to impose some rules on future specifications that use SET to
define events.  Please reword.


Minor Concerns

The Abstract says:

   ...  This statement of fact
   represents an event that occurred to the security subject.  In some
   use cases, the security subject may be a digitial identity, but SETs
   are also applicable to non-identity use cases.  ...

Please correct the spelling of digital identity.

I do not think this tells the reader when they might want to employ this
specification.  The following sentence from the Introduction does a
better job:

   This specification is scoped to security and identity related events.


In Section 2, the last bullet on page 5 talks about the "events" JSON
object.  The last sentence caught me by surprise, and I had to read it a
few times to figure out the intent.  The events object cannot be "{}",
but the payload for an event in that object can be "{}".  I think that
a MUST statement about there being at least one URI string value would
have helped me.



From nobody Tue Mar 27 22:31:22 2018
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 56294124217; Tue, 27 Mar 2018 22:31:20 -0700 (PDT)
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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F4oIGeqGpY2p; Tue, 27 Mar 2018 22:31:18 -0700 (PDT)
Received: from aserp2130.oracle.com (aserp2130.oracle.com [141.146.126.79]) (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 39DBB1205D3; Tue, 27 Mar 2018 22:31:18 -0700 (PDT)
Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w2S5Kock054799; Wed, 28 Mar 2018 05:31:17 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2017-10-26; bh=UsBz8nUdUZ4XUf6K54P0TckaTCdi1ygu+vhya5PZyd0=; b=Bo9RTxhGfotud77BtRXZpWm9axeJL/fAKhMbmDQV6QLWU7YDLslH69S6Qxk3DTcQzQ6m 7sLeg+umiGWcV80UcteTg69zrLPSadmQpnDw+5SpFVHcMsTMYYLsohx2d/rOsxsOHABI Iqfu6OXeoFyrAHsrBoMDTglTMlGx6x7JbdMb5hIWwToSStQ4nOCZVuvSHd9ZTK6fkFrY 7XOjUP2g5MYUEQvI7lmmXUei/RoP4OMJ+/x/bs8y4yL6ejz0xfl3TT600wYlouYYZIde 4/46e1MqHIWH0TO6poTemY58yQ5wBUXzCMlosiX09rxyLyqwXaB6C31eBdhAX2MK2EDd wg== 
Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp2130.oracle.com with ESMTP id 2h04tu00nk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 28 Mar 2018 05:31:17 +0000
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 w2S5VG0R012429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 28 Mar 2018 05:31:16 GMT
Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w2S5VF5w009653; Wed, 28 Mar 2018 05:31:15 GMT
Received: from [192.168.1.70] (/108.172.184.55) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 27 Mar 2018 22:31:15 -0700
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Phil Hunt 
X-Mailer: iPhone Mail (15D100)
In-Reply-To: <152218349510.5239.9026903316972844190@ietfa.amsl.com>
Date: Tue, 27 Mar 2018 22:31:13 -0700
Cc: secdir@ietf.org, draft-ietf-secevent-token.all@ietf.org, ietf@ietf.org, id-event@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <0F1675A5-D2D0-425B-BB47-D2EC84B37AA6@oracle.com>
References: <152218349510.5239.9026903316972844190@ietfa.amsl.com>
To: Russ Housley 
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8845 signatures=668695
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803280054
Archived-At: 
Subject: Re: [Id-event] Secdir telechat review of draft-ietf-secevent-token-07
X-BeenThere: id-event@ietf.org
X-Mailman-Version: 2.1.22
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 Mar 2018 05:31:20 -0000

Russ

Thanks for your review. I am away on holiday but hope to find an opportunity=
 to get back to you on your review in the coming days.=20

Thanks,

Phil

> On Mar 27, 2018, at 1:44 PM, Russ Housley  wrote:
>=20
> Reviewer: Russ Housley
> Review result: Has Issues
>=20
> I reviewed this document as part of the Security Directorate's ongoing
> effort to review all IETF documents being processed by the IESG.  These
> comments were written primarily for the benefit of the Security Area
> Directors.  Document authors, document editors, and WG chairs should
> treat these comments just like any other IETF Last Call comments.
>=20
> Document: draft-ietf-secevent-token-07
> Reviewer: Russ Housley
> Review Date: 2018-03-27
> IETF LC End Date: unknown
> IESG Telechat date: 2018-05-10
>=20
> Summary: Has Issues
>=20
> Process concern
>=20
> A request for a telechat review of draft-ietf-secevent-token was
> assigned to me.  However, there has not yet been an IETF Last Call
> announced for this document.
>=20
>=20
> Major Concerns
>=20
> All of the examples in Section 2.1 are non-normative.  Instead of
> staying that in each of the subsections, please add some text at the
> top of Section 2.1 that says so.
>=20
> I do not understand the first paragraph of Section 3.  I think you are
> trying to impose some rules on future specifications that use SET to
> define events.  Please reword.
>=20
>=20
> Minor Concerns
>=20
> The Abstract says:
>=20
>   ...  This statement of fact
>   represents an event that occurred to the security subject.  In some
>   use cases, the security subject may be a digitial identity, but SETs
>   are also applicable to non-identity use cases.  ...
>=20
> Please correct the spelling of digital identity.
>=20
> I do not think this tells the reader when they might want to employ this
> specification.  The following sentence from the Introduction does a
> better job:
>=20
>   This specification is scoped to security and identity related events.
>=20
>=20
> In Section 2, the last bullet on page 5 talks about the "events" JSON
> object.  The last sentence caught me by surprise, and I had to read it a
> few times to figure out the intent.  The events object cannot be "{}",
> but the payload for an event in that object can be "{}".  I think that
> a MUST statement about there being at least one URI string value would
> have helped me.
>=20
>=20
> _______________________________________________
> Id-event mailing list
> Id-event@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma=
n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI=
_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DfnyJdKvhWPUuMKKzm5d=
_t3Zs2s0pL22w8NMEZhfDYj0&s=3D5bt_aLpKCABqLuxercRiolomH_tFBb33PQnY1KM3CuE&e=3D=



From nobody Wed Mar 28 05:59:09 2018
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 EFC3A126FDC; Wed, 28 Mar 2018 05:59:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level: 
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 zznqm9qUjedd; Wed, 28 Mar 2018 05:59:04 -0700 (PDT)
Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (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 039411242F7; Wed, 28 Mar 2018 05:59:03 -0700 (PDT)
X-AuditID: 12074422-49dff7000000583f-97-5abb91942575
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 dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 9C.A6.22591.5919BBA5; Wed, 28 Mar 2018 08:59:02 -0400 (EDT)
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 w2SCwuxa031086; Wed, 28 Mar 2018 08:58:58 -0400
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w2SCwq2v001828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 28 Mar 2018 08:58:55 -0400
Date: Wed, 28 Mar 2018 07:58:52 -0500
From: Benjamin Kaduk 
To: Russ Housley 
Cc: secdir@ietf.org, draft-ietf-secevent-token.all@ietf.org, id-event@ietf.org
Message-ID: <20180328125852.GC76724@kduck.kaduk.org>
References: <152218349510.5239.9026903316972844190@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <152218349510.5239.9026903316972844190@ietfa.amsl.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgleLIzCtJLcpLzFFi42IRYrdT0Z02cXeUwZfvwhZP5ixktXj14ia7 RceCbiaLDwsfsjiweCxZ8pPJY9WdL6wBTFFcNimpOZllqUX6dglcGT+2nmUqWCJa8XhOH0sD 416BLkZODgkBE4mG35NZuhi5OIQEFjNJTDnWwQrhbGSU+Lf9CjuEc5VJYtauJkaQFhYBVYme T/OYQGw2ARWJhu7LzCC2iIC6xN/5F9hBbGYBP4lDX5qBbA4OYQFnieeHLEHCvEDbfh7pBGsV EnCSOHNqMStEXFDi5MwnLBCtWhI3/r1kAmllFpCWWP6PAyTMCTSl/c9ENhBbVEBZYm/fIfYJ jAKzkHTPQtI9C6F7ASPzKkbZlNwq3dzEzJzi1GTd4uTEvLzUIl1TvdzMEr3UlNJNjODAdVHa wTjxn9chRgEORiUe3oKYXVFCrIllxZW5hxglOZiURHkl43ZHCfEl5adUZiQWZ8QXleakFh9i lOBgVhLhfa8BlONNSaysSi3Kh0lJc7AoifN6mGhHCQmkJ5akZqemFqQWwWRlODiUJHgbJgA1 ChalpqdWpGXmlCCkmTg4QYbzAA1vAanhLS5IzC3OTIfIn2LU5bjx4nUbsxBLXn5eqpQ47weQ IgGQoozSPLg5oIQjkb2/5hWjONBbwrwFIFU8wGQFN+kV0BImoCXbmnaALClJREhJNTBqG92R 2XQlxsBbZln2n+NPom92VLWla3x/1DLjb/eqhLtn0oN6th/4uT9fka3nUIbpXnkT3twr6q9m fyy6f5+je3t8/rcfrzWTi1Q2y9xzS71VbJvas3Vzm1Jl2+pLWrZfrzObc1+9tUVvl+0XvVnL N525+XHihYnfuxSZMsM/WGROPldYuUdYiaU4I9FQi7moOBEAH2oTDxMDAAA=
Archived-At: 
Subject: Re: [Id-event] Secdir telechat review of draft-ietf-secevent-token-07
X-BeenThere: id-event@ietf.org
X-Mailman-Version: 2.1.22
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 Mar 2018 12:59:07 -0000

Hi Russ,

On Tue, Mar 27, 2018 at 01:44:55PM -0700, Russ Housley wrote:
> Reviewer: Russ Housley
> Review result: Has Issues
> 
> I reviewed this document as part of the Security Directorate's ongoing
> effort to review all IETF documents being processed by the IESG.  These
> comments were written primarily for the benefit of the Security Area
> Directors.  Document authors, document editors, and WG chairs should
> treat these comments just like any other IETF Last Call comments.
> 
> Document: draft-ietf-secevent-token-07
> Reviewer: Russ Housley
> Review Date: 2018-03-27
> IETF LC End Date: unknown
> IESG Telechat date: 2018-05-10
> 
> Summary: Has Issues
> 
> Process concern
> 
> A request for a telechat review of draft-ietf-secevent-token was
> assigned to me.  However, there has not yet been an IETF Last Call
> announced for this document.

Thanks for the review, and for pointing out the process nit.
Getting on a telechat is pretty hard at the moment due to the large
spike in documents we saw prior to the IESG cutover.  I should still
have time to complete my AD review and issue the IETF LC with time
to spare before 2018-05-10, though.

Authors, please feel free to address Russ's comments in a new
revision if you can do so before the IETF LC is issued.

Thanks,

Ben

> 
> Major Concerns
> 
> All of the examples in Section 2.1 are non-normative.  Instead of
> staying that in each of the subsections, please add some text at the
> top of Section 2.1 that says so.
> 
> I do not understand the first paragraph of Section 3.  I think you are
> trying to impose some rules on future specifications that use SET to
> define events.  Please reword.
> 
> 
> Minor Concerns
> 
> The Abstract says:
> 
>    ...  This statement of fact
>    represents an event that occurred to the security subject.  In some
>    use cases, the security subject may be a digitial identity, but SETs
>    are also applicable to non-identity use cases.  ...
> 
> Please correct the spelling of digital identity.
> 
> I do not think this tells the reader when they might want to employ this
> specification.  The following sentence from the Introduction does a
> better job:
> 
>    This specification is scoped to security and identity related events.
> 
> 
> In Section 2, the last bullet on page 5 talks about the "events" JSON
> object.  The last sentence caught me by surprise, and I had to read it a
> few times to figure out the intent.  The events object cannot be "{}",
> but the payload for an event in that object can be "{}".  I think that
> a MUST statement about there being at least one URI string value would
> have helped me.
> 
> 


From nobody Thu Mar 29 22:17:15 2018
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 C7EC1124B0A for ; Thu, 29 Mar 2018 22:17:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.012
X-Spam-Level: 
X-Spam-Status: No, score=-2.012 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_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVjYAzEWQB8K for ; Thu, 29 Mar 2018 22:17:12 -0700 (PDT)
Received: from userp2120.oracle.com (userp2120.oracle.com [156.151.31.85]) (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 E1934126BF7 for ; Thu, 29 Mar 2018 22:17:12 -0700 (PDT)
Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w2U54HdB050970; Fri, 30 Mar 2018 05:17:11 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2017-10-26; bh=MMbuzyVqS7jVJ0epbBkvcPqR4X49nlWRLpqabyHbNy0=; b=lGkO2pcnFFH4Bb8fbQDf/ldlWdrMelHiX1xLDIvjui7LoZ0H+1nfBluYkkAz0ZrQkY2Y XC8Dipv6/9nSETSOttUq8EgmZtbSLsNvN8751DgNo0bNwgIHPs/yrvBC2pi3x3sV0yGY b1QR3eDP93a2O4Bfi6rlp9gcGeznGE6qGYmftUI85N4Tei6pvIMCgHQOtQmPQqOV7c9R QsvGQnUakDI5NrQzXH965CkFgjTNx4MkNtZoNBqmbBAZzJPkgDqXWPJJhGx5jHy64+I7 KdqudCdC++rJlm3a1FRxmPoN9Ukev/Hrcu0F5Ho//+Losd6rUWccQFPFarSi3ErcqXgi Rg== 
Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp2120.oracle.com with ESMTP id 2h1ee9r2f1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 30 Mar 2018 05:17:10 +0000
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w2U5EgLi028239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 30 Mar 2018 05:14:42 GMT
Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w2U5EgFv013891; Fri, 30 Mar 2018 05:14:42 GMT
Received: from [192.168.0.93] (/68.145.180.43) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Mar 2018 22:14:42 -0700
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Phil Hunt 
X-Mailer: iPhone Mail (15D100)
In-Reply-To: 
Date: Thu, 29 Mar 2018 23:14:39 -0600
Cc: SecEvent 
Content-Transfer-Encoding: quoted-printable
Message-Id: <09566560-11CA-435A-87F4-CFCBC6F889F3@oracle.com>
References: <02e701d3c299$9c421e40$d4c65ac0$@smyslov.net> 
To: Yaron Sheffer 
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8847 signatures=668697
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803300052
Archived-At: 
Subject: Re: [Id-event] SecEvent draft minutes - IETF-101 (London)
X-BeenThere: id-event@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 30 Mar 2018 05:17:15 -0000

Regarding the hums, I think they may be premature. In part, because there is=
 a unifying draft proposal available now.=20

When we formed the group the sole purpose was a common format and a single d=
elivery draft for all cases.=20

Several ietf people complained in Argentina about yet another pub sub system=
 the ietf does not need.=20

Another comment was made not to follow the route stix/taxii made in developi=
ng multiple incompatible methods of delivery.=20

If we split the draft we will have 3 methods not two(including Backchannel).=
=20

I worry this will lead to delay from rejection down the road. This should be=
 clarified first.=20

I worry with multiple methods, profilers will develop their own undermining t=
he point of this work.=20

Maybe I stand alone here, but I think splitting is a mistake.=20

Phil

> On Mar 24, 2018, at 8:00 AM, Yaron Sheffer  wrote:
>=20
> Thank you Valery for taking the minutes. All, please let us know if anythi=
ng is incorrect or missing.
>=20
> In addition, we had a series of hums on the SET Delivery draft. Per IETF p=
rocess, we need to validate them on the list. So if you weren't in the room a=
nd you have a major objection to the results of these hums, please speak up.=
 I do suggest that before doing so, you review the actual recorded meeting: h=
ttps://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.youtube.com_watch-=
3Fv-3Dr0hbpQqsN6s&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=
&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DbZnIUtQK2S3enqQ3E8wJZHx=
LExg0UyssjEM1UAJ18jw&s=3DVbJxhADDKAULj3hrOYI1cbC5A8hEmFIesTvuGzkkOP0&e=3D.
>=20
> IETF 101 London Friday 23 March 2018 9:30 - 11:30
>=20
> [Yaron] (WG status update, agenda bashing)
> [Annabelle] asks for 10 minutes for discussion
>=20
> [Mike] (presents Security Event Token draft update)
>=20
> [Annabelle] (presents SET Token delivery using HTTP draft)
> [Mike] Microsoft needs for both POLL and PUSH
> [Phil] Redefining smth in HTTP may cause problems
> [William] Return codes are only for browsers to display messages for users=

> [Phil] It's needed for resending in case of error (?)
> [Annabelle] What is MTI - push or poll?
> [Phil] With PUSH  happened immediately...
> [Leif] What is MTI for server or for client?
> [William] Each option has an explicit use case
> [Yaron (as chair)] We need to have only one preferred option
> [Phil] There are very different cases
> [Phil] Push is simple, but in terms of applicability it's not a long term u=
se case
> [Annabelle] There use cases for both
> [Phil] Take two and then abandon one
> [William] Why does the chair require a single MTI
> [Leif] It's from chair's experience, WG consensus needed
> [William] We have use cases for both
> [Mike] Procedurally it's better to keep both methods in one draft
> [Yaron] Having two methods complicates the description which method is for=
 which situation etc.
> [William] Still have interoperability issue for receiver
> [Yaron] Need to resolve this
> [Leif] WG should decide
> [Ben as AD] If the WG doesn't select a single method the IESG would probab=
ly object
> [Annabelle] SET will probably be profiled for different use cases
> [Yaron] Is going to make hums about selecting a single delivery method and=
 whether we need to split the draft
> [John] What is hum about - mandatory to implement or to deploy?
> [Leif] We should analyze scenarios
> [Annabelle] The protocol are unidirectional, so MTI for transmitter/receiv=
er is problematic
> [Justin] No negotiation, either it is or not, MTI for the receiver is
> dictated by what the receiver supports
> [Phil] They both must be able HTTP, the roles can be changed
> [Leif] Confusion between MTI and to deploy, a good question - select MTI f=
or transmitter
> [Annabelle] Every transmitter should have both
> [Tero] Minimal implementation requires one, bigger may have both, single M=
TI is better then two for limited devices
> [Annabelle] IoT implementers have special requirement
> [William] They are application specific, we expected profile this
> [Yaron] Hum if we need a single MTI for transmitter - silence
> Later edit: Clearly no support for a single MTI.
> [Justin] Hum must be for multiple discrete options
> [Yaron] Hum on use cases for two methods - some hums
> [Yaron] Hum if both should be MTI - some hums
> [Yaron] Hum if should not specify MTI - some hums
> Later edit: room was split between two MTIs and no MTIs.
> [Annabelle] We should split the spec
> [Justin] Agree to split the spec
> [Justin] I hummed for both MTI for transmitter, because they are not usual=
ly constrained
> [Annabelle] SET is possibly to be used w/o HTTP, this is only MTI for thos=
e using HTTP; both MTI is problematic because implementers will do unnecessa=
ry stuff
> [William] If both are MTI, we need 2 specs
> [John] Splitting the spec is the best way
> [Mike] If split, then the information for developers will be duplicated
> [Ben] Why single document better (?)
> [Mike] My experience with JOSE
> [Annabelle] Significant overlap between documents is SET, otherwise little=
 commonality
> Later edit: existing editors volunteered to take Push-specific doc, Annabe=
lle and Mike volunteered to work on Poll.
> [from jabber] Little commonality between two methods
> [Mike] We'll do both, we have use cases for both
> [Yaron] Hum if split documents - some long hums
> [Yaron] Hum if one document - some hums
> [Yaron] Room is in favor of splitting the documents
> [Yaron] Wrap up: no MTI, split the document into two, transmitter implemen=
ts either or both
>=20
> [Annabelle] (presenting Subject Identifier Types)
> [Mike] 3rd party specifications cannot establish IANA registry
> [Leif] IANA Expert?
> [Ben] FCFS, doesn't need Expert, or specification required
> [Leif] I support this idea
> [William] I also support
> [Yaron] Any objections to adopt this document? No objections, publish as W=
G document
>=20
> [Annabelle] Expiration ("exp") claim is not recommended; however it has so=
me value
> [Mike] It's a layering violation; problems with caching
> [Annabelle] We're not talking about caching, you don't want to grow anti-r=
eplay database forever, having expiration helps
> [Phil] The past doesn't expire, it's up to receiver how to use it, caching=
 doesn't make sense
> [Yaron] What about replay protection?
> [Mike] JTI helps to detect replay (?) [from jabber] Transport should deal w=
ith replay
> [John] Expiry is expected to mean that token should not be processed after=
 that, it's not an indication that information is no longer valid
> [Mike] It must not be mandatory
> [Annabelle] Currently the draft says it's not recommended
> [Mike] We have to allow it to be optional because of the need to distingui=
sh from access tokens.
> [Ben] Some use case when processing expired token (?)
> [John] Have an explicit expire for JTI, there are other solutions
> [Phil] I prefer to add a new attribute to SET, not changing ...
> [Yaron] The document in LC, smaller changes are OK without blocking the do=
c's progress.
> [Phil] Replay and caching are different for PUSH and POLL, prefer to see i=
n HTTP header
> [Brian] Expiration is not necessary, receiver has policy to follow
> [Annabelle] No-one is advocating using exp for caching
> [from jabber] JTI expiration belongs to JTI not to transport
> [Yaron] We're not ready to have hum, room thinks there is an issue, please=
 work through it on the list.
>=20
> [Phil] Presents his SSTP Delivery draft - symmetric transport protocol, pa=
rameters used in requests and response are same
> [Phil] We would change optionality from two methods to a single one, may b=
e a compromise
> [Yaron] The protocol was only published yesterday, so we are not ready to d=
iscuss now.
>=20
> [Meeting adjourned.]
>=20
> _______________________________________________
> Id-event mailing list
> Id-event@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma=
n_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI=
_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DbZnIUtQK2S3enqQ3E8w=
JZHxLExg0UyssjEM1UAJ18jw&s=3Dbm9Kqkwb8W8ClkdHFvnnH60BmArjysl02dP_3TAjwew&e=3D=



From nobody Fri Mar 30 03:53:31 2018
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 5054B12D77D for ; Fri, 30 Mar 2018 03:53:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 xA9p0gRxbYZF for ; Fri, 30 Mar 2018 03:53:27 -0700 (PDT)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0111.outbound.protection.outlook.com [104.47.33.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3419D1200A0 for ; Fri, 30 Mar 2018 03:53:27 -0700 (PDT)
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=LHTMwvTNJbM9jTXUUTrU80nnKjBjxQz2hLGQRTWCgyE=; b=lEGRA9tFWVQYVa3RLDVfmMK9h7Ob37luuhMBIyprQbIcJg+oLAKCoKfmsoxwXicvW7KhY16EFy2YcxAPN6QXbjaCwDfcB1iQnvKut9ubo6p1Lo9WQh6QinRXXsB7QfJ5mP3G7PIMFkninIXaDYt+aXAxkf9Xp+jqIyGKYUusufM=
Received: from MW2PR00MB0298.namprd00.prod.outlook.com (52.132.148.29) by MW2PR00MB0329.namprd00.prod.outlook.com (52.132.148.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.670.0; Fri, 30 Mar 2018 10:53:24 +0000
Received: from MW2PR00MB0298.namprd00.prod.outlook.com ([fe80::c922:3c06:8cca:e4a5]) by MW2PR00MB0298.namprd00.prod.outlook.com ([fe80::c922:3c06:8cca:e4a5%3]) with mapi id 15.20.0677.000; Fri, 30 Mar 2018 10:53:23 +0000
From: Mike Jones 
To: Phil Hunt , Yaron Sheffer 
CC: SecEvent 
Thread-Topic: [Id-event] SecEvent draft minutes - IETF-101 (London)
Thread-Index: AQHTw3iUU8x/h01Wak+Cn/InQN/SW6PoRRCAgABcuvA=
Date: Fri, 30 Mar 2018 10:53:23 +0000
Message-ID: 
References: <02e701d3c299$9c421e40$d4c65ac0$@smyslov.net>  <09566560-11CA-435A-87F4-CFCBC6F889F3@oracle.com>
In-Reply-To: <09566560-11CA-435A-87F4-CFCBC6F889F3@oracle.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [77.241.229.232]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; MW2PR00MB0329; 7:PP24EDsISq3ZDw8PUMjaefY1hWPLSHZIo8SlG80ZJQsiFV+Id8XlQIeXUdtc4bZ387Qmq3YYakd8i4YrW1CuKGZOYGL/3+v3731DNTLyGR+Rsh1r++CbU9JfyGpO9O/NxAfW5pnKuom7MsevVUEx5mLOjEfY9f3zHBtYvhe1HT0polVD4lXRW2Zk3s5zKMk6wrbFibmiXdyL/WTsQyzl9AdYNoGBveFRqigW6NVGp2Mji5o/ocIqlWE9ZhKuzgot; 20:22q/PF8PimZGQIi/OPkZu74ARS0Igmr0rRBcDiQzcylS4YCA9qcUOA/1MbWEvsY/HSRfS6/11HWO7M6U/BRJ2RGK9PRfppMurbIhEd+5/0Tx1nSE7q5JiYdI4Im33jRaY9VFpmmE8moyk8R8tKwUzIlA4bta54Mt3a22WekY/SQ=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 2151fa26-18b2-48b9-9d2b-08d5962c75a3
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:MW2PR00MB0329; 
x-ms-traffictypediagnostic: MW2PR00MB0329:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(158342451672863)(10436049006162)(192374486261705)(85827821059158)(100405760836317)(254730959083279);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040522)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(10201501046)(3231221)(944501327)(52105095)(6055026)(61426038)(61427038)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:MW2PR00MB0329; BCL:0; PCL:0; RULEID:; SRVR:MW2PR00MB0329; 
x-forefront-prvs: 06274D1C43
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(396003)(39380400002)(376002)(39860400002)(366004)(13464003)(199004)(189003)(305945005)(2906002)(97736004)(26005)(10090500001)(3660700001)(5660300001)(3846002)(8990500004)(6116002)(316002)(106356001)(561944003)(2900100001)(33656002)(55016002)(102836004)(6436002)(22452003)(9686003)(74316002)(7736002)(4326008)(186003)(66066001)(3280700002)(6306002)(10290500003)(6246003)(8936002)(72206003)(76176011)(53936002)(966005)(25786009)(68736007)(476003)(11346002)(14454004)(110136005)(6506007)(39060400002)(99286004)(229853002)(5250100002)(105586002)(86362001)(575784001)(486005)(478600001)(486005)(59450400001)(7696005)(8676002)(86612001)(53546011)(446003)(81166006)(81156014); DIR:OUT; SFP:1102; SCL:1; SRVR:MW2PR00MB0329; H:MW2PR00MB0298.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: ao8pai0jZRVlrBsC8yBlTC3eFIiRzoWuqCYdSSxzHGQQIqY8fSIc4DN7lsXNfTF9PQAe9G454TVu6Om8jsALzJiSScua40+n9jIE+Wb6NaWcX9bOwO8gNkTrwghHOeOKoMm8/pIYxrDjKtlKQ9kfus69pM6FtsE1poC2jU9CX0Mxg3OBU+5l+N/06z2QmuyRlO0LGeDk8GwM+KnDlj+w9fUfbEM5ecT94Bu+mQsfXMHwMuVyiPr4P3U6pNnkfHy0UvpsX8Z2cwvlAqtQ84EYkEP2kK5VKsZ4D2cRPGokEYLLjeiGIrWxi1yUMS+5tA50Ah0S2VvDK+bSd4OFvfXgt7U7Lx4+052cOY/1km0QcX0rkoX6PmFtd19ZFjFEVfoKhyUQ92/ISFwXAJwZb2u/iLj7cv2mrJma5uuxhMUjq3M=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2151fa26-18b2-48b9-9d2b-08d5962c75a3
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Mar 2018 10:53:23.8239 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR00MB0329
Archived-At: 
Subject: Re: [Id-event] SecEvent draft minutes - IETF-101 (London)
X-BeenThere: id-event@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 30 Mar 2018 10:53:30 -0000

I agree with Phil that having separate push and pull delivery drafts would =
be a mistake.  Many participants will end up implementing both modalities. =
 Having them both in one draft will help keep them as common as possible - =
preventing unnecessary and possibly unintended drift between them.

Also, as I said at the microphone in London, I think we'll have a much easi=
er time with the IESG taking one draft forward with two closely related del=
ivery modalities defined, rather that two different delivery drafts.  I fea=
r that if we try to get approval for two drafts, we might receive DISCUSS f=
eedback saying "pick one".

For what it's worth (and to inform people who weren't in the room), my pers=
onal sense was that the hums weren't conclusive.  Most of them had signific=
ant portions of people humming for both positions.  In short, my (personal)=
 sense was there wasn't clear consensus demonstrated to split the delivery =
draft.  I think the topic needs more discussion on the list.

				Best wishes,
				-- Mike

-----Original Message-----
From: Id-event  On Behalf Of Phil Hunt
Sent: Thursday, March 29, 2018 10:15 PM
To: Yaron Sheffer 
Cc: SecEvent 
Subject: Re: [Id-event] SecEvent draft minutes - IETF-101 (London)

Regarding the hums, I think they may be premature. In part, because there i=
s a unifying draft proposal available now.=20

When we formed the group the sole purpose was a common format and a single =
delivery draft for all cases.=20

Several ietf people complained in Argentina about yet another pub sub syste=
m the ietf does not need.=20

Another comment was made not to follow the route stix/taxii made in develop=
ing multiple incompatible methods of delivery.=20

If we split the draft we will have 3 methods not two(including Backchannel)=
.=20

I worry this will lead to delay from rejection down the road. This should b=
e clarified first.=20

I worry with multiple methods, profilers will develop their own undermining=
 the point of this work.=20

Maybe I stand alone here, but I think splitting is a mistake.=20

Phil

> On Mar 24, 2018, at 8:00 AM, Yaron Sheffer  wrote:
>=20
> Thank you Valery for taking the minutes. All, please let us know if anyth=
ing is incorrect or missing.
>=20
> In addition, we had a series of hums on the SET Delivery draft. Per IETF =
process, we need to validate them on the list. So if you weren't in the roo=
m and you have a major objection to the results of these hums, please speak=
 up. I do suggest that before doing so, you review the actual recorded meet=
ing: https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.youtube.com=
_watch-3Fv-3Dr0hbpQqsN6s&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65=
eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DbZnIUtQK2S3enq=
Q3E8wJZHxLExg0UyssjEM1UAJ18jw&s=3DVbJxhADDKAULj3hrOYI1cbC5A8hEmFIesTvuGzkkO=
P0&e=3D.
>=20
> IETF 101 London Friday 23 March 2018 9:30 - 11:30
>=20
> [Yaron] (WG status update, agenda bashing) [Annabelle] asks for 10=20
> minutes for discussion
>=20
> [Mike] (presents Security Event Token draft update)
>=20
> [Annabelle] (presents SET Token delivery using HTTP draft) [Mike]=20
> Microsoft needs for both POLL and PUSH [Phil] Redefining smth in HTTP=20
> may cause problems [William] Return codes are only for browsers to=20
> display messages for users [Phil] It's needed for resending in case of=20
> error (?) [Annabelle] What is MTI - push or poll?
> [Phil] With PUSH  happened immediately...
> [Leif] What is MTI for server or for client?
> [William] Each option has an explicit use case [Yaron (as chair)] We=20
> need to have only one preferred option [Phil] There are very different=20
> cases [Phil] Push is simple, but in terms of applicability it's not a=20
> long term use case [Annabelle] There use cases for both [Phil] Take=20
> two and then abandon one [William] Why does the chair require a single=20
> MTI [Leif] It's from chair's experience, WG consensus needed [William]=20
> We have use cases for both [Mike] Procedurally it's better to keep=20
> both methods in one draft [Yaron] Having two methods complicates the=20
> description which method is for which situation etc.
> [William] Still have interoperability issue for receiver [Yaron] Need=20
> to resolve this [Leif] WG should decide [Ben as AD] If the WG doesn't=20
> select a single method the IESG would probably object [Annabelle] SET=20
> will probably be profiled for different use cases [Yaron] Is going to=20
> make hums about selecting a single delivery method and whether we need=20
> to split the draft [John] What is hum about - mandatory to implement or t=
o deploy?
> [Leif] We should analyze scenarios
> [Annabelle] The protocol are unidirectional, so MTI for=20
> transmitter/receiver is problematic [Justin] No negotiation, either it=20
> is or not, MTI for the receiver is dictated by what the receiver=20
> supports [Phil] They both must be able HTTP, the roles can be changed=20
> [Leif] Confusion between MTI and to deploy, a good question - select=20
> MTI for transmitter [Annabelle] Every transmitter should have both=20
> [Tero] Minimal implementation requires one, bigger may have both,=20
> single MTI is better then two for limited devices [Annabelle] IoT=20
> implementers have special requirement [William] They are application=20
> specific, we expected profile this [Yaron] Hum if we need a single MTI=20
> for transmitter - silence Later edit: Clearly no support for a single MTI=
.
> [Justin] Hum must be for multiple discrete options [Yaron] Hum on use=20
> cases for two methods - some hums [Yaron] Hum if both should be MTI -=20
> some hums [Yaron] Hum if should not specify MTI - some hums Later=20
> edit: room was split between two MTIs and no MTIs.
> [Annabelle] We should split the spec
> [Justin] Agree to split the spec
> [Justin] I hummed for both MTI for transmitter, because they are not=20
> usually constrained [Annabelle] SET is possibly to be used w/o HTTP,=20
> this is only MTI for those using HTTP; both MTI is problematic because=20
> implementers will do unnecessary stuff [William] If both are MTI, we=20
> need 2 specs [John] Splitting the spec is the best way [Mike] If=20
> split, then the information for developers will be duplicated [Ben]=20
> Why single document better (?) [Mike] My experience with JOSE=20
> [Annabelle] Significant overlap between documents is SET, otherwise=20
> little commonality Later edit: existing editors volunteered to take Push-=
specific doc, Annabelle and Mike volunteered to work on Poll.
> [from jabber] Little commonality between two methods [Mike] We'll do=20
> both, we have use cases for both [Yaron] Hum if split documents - some=20
> long hums [Yaron] Hum if one document - some hums [Yaron] Room is in=20
> favor of splitting the documents [Yaron] Wrap up: no MTI, split the=20
> document into two, transmitter implements either or both
>=20
> [Annabelle] (presenting Subject Identifier Types) [Mike] 3rd party=20
> specifications cannot establish IANA registry [Leif] IANA Expert?
> [Ben] FCFS, doesn't need Expert, or specification required [Leif] I=20
> support this idea [William] I also support [Yaron] Any objections to=20
> adopt this document? No objections, publish as WG document
>=20
> [Annabelle] Expiration ("exp") claim is not recommended; however it=20
> has some value [Mike] It's a layering violation; problems with caching=20
> [Annabelle] We're not talking about caching, you don't want to grow=20
> anti-replay database forever, having expiration helps [Phil] The past=20
> doesn't expire, it's up to receiver how to use it, caching doesn't make s=
ense [Yaron] What about replay protection?
> [Mike] JTI helps to detect replay (?) [from jabber] Transport should=20
> deal with replay [John] Expiry is expected to mean that token should=20
> not be processed after that, it's not an indication that information=20
> is no longer valid [Mike] It must not be mandatory [Annabelle]=20
> Currently the draft says it's not recommended [Mike] We have to allow it =
to be optional because of the need to distinguish from access tokens.
> [Ben] Some use case when processing expired token (?) [John] Have an=20
> explicit expire for JTI, there are other solutions [Phil] I prefer to=20
> add a new attribute to SET, not changing ...
> [Yaron] The document in LC, smaller changes are OK without blocking the d=
oc's progress.
> [Phil] Replay and caching are different for PUSH and POLL, prefer to=20
> see in HTTP header [Brian] Expiration is not necessary, receiver has=20
> policy to follow [Annabelle] No-one is advocating using exp for=20
> caching [from jabber] JTI expiration belongs to JTI not to transport=20
> [Yaron] We're not ready to have hum, room thinks there is an issue, pleas=
e work through it on the list.
>=20
> [Phil] Presents his SSTP Delivery draft - symmetric transport=20
> protocol, parameters used in requests and response are same [Phil] We=20
> would change optionality from two methods to a single one, may be a compr=
omise [Yaron] The protocol was only published yesterday, so we are not read=
y to discuss now.
>=20
> [Meeting adjourned.]
>=20
> _______________________________________________
> Id-event mailing list
> Id-event@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail
> man_listinfo_id-2Devent&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB6=
5
> eapI_JnE&r=3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3DbZnIUtQK2S3e=
n
> qQ3E8wJZHxLExg0UyssjEM1UAJ18jw&s=3Dbm9Kqkwb8W8ClkdHFvnnH60BmArjysl02dP_3
> TAjwew&e=3D

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


From nobody Fri Mar 30 05:02:01 2018
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 907F7126BFD for ; Fri, 30 Mar 2018 05:02:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 7tQZP3r2pTSi for ; Fri, 30 Mar 2018 05:01:57 -0700 (PDT)
Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5869B12422F for ; Fri, 30 Mar 2018 05:01:57 -0700 (PDT)
Received: by mail-wr0-x22a.google.com with SMTP id u11so7848726wri.12 for ; Fri, 30 Mar 2018 05:01:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=nk3oDqweCcsZEWTHeL4DfEoblrg0ENUeRvmet2kXCRU=; b=nQJT5DABzLIqpmyFQl828KNyS4GrBJsj1Vx+Y4i0DS+fhQ+xDuHCiR8eXN72W6OHzT BvQPp2ym0CS0pfNif4UI9HR5fSGKNluNr1AWmuheER2nSTqkNzLaGp9Tw0ecydBCnmDc Q1CldUW6jsXCRF7wvCsfg3PuF47ZHG74rHDb0DupltrFztfW/VVAua7YaB2a2RK499BP f5wZf2/JoSnKMdScThWcgrhNCnUBX/x1+XzzRZO1L6RWzjhN7F3VA/Ai2w2ucLsRQMeA +3cYz2g432BZ+P8/0guKUiti30OAlIaNiLChGkXSBWskwFHkcr4fHwW79ce8SlvTu8rw Wh7Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=nk3oDqweCcsZEWTHeL4DfEoblrg0ENUeRvmet2kXCRU=; b=XJuNJw+7a7KevjKqW9W2khNkC9RbjuE1F1AMWTxBiyLPyLyNd6H7HeRpiOixKt6FLH 5OizwCPoDsg9dLlCO3xyW46Hn3myvO0vBFieBEfduvH3XlVSA+ayBQ9bzmUGqnnNbX/+ VJhY9TVAGcAr4fXWFxXyAuzTwiSsCqGb3ehCdOdQA5PD6G26zpsuJTbLP33/08u2GhRe A8OUDp7DFVP9eYCfAKRdV0IQmfOEQ64cS9XerR6ziiLkgi3zPAnO1rx2F+UvYQKQ6gpm 2TGQ35BUXaoBvtH324B2Bewbt4c8FRbObfz/MX0yGgFntBk3BvaM6zwkWQQE2yYQ7+vO oTGQ==
X-Gm-Message-State: AElRT7EZVKvoKopgCJZDO0dEsziXfWefgD5tGgTxWixYF2ZuOJuBPnhA yybr1CsSeGlJadKnEUlsbILI1otX
X-Google-Smtp-Source: AIpwx4/ePJuIOFWdG6Rc0BQXx6sNUr206aV1DkZ+Xx15owY1zpP1FSzOLNd23WhJ4evwYXamTLIoqw==
X-Received: by 10.223.219.10 with SMTP id s10mr9116806wri.241.1522411315543; Fri, 30 Mar 2018 05:01:55 -0700 (PDT)
Received: from [10.0.0.149] (bzq-79-182-28-178.red.bezeqint.net. [79.182.28.178]) by smtp.gmail.com with ESMTPSA id k18sm6448220wmd.4.2018.03.30.05.01.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 30 Mar 2018 05:01:52 -0700 (PDT)
To: Mike Jones , Phil Hunt 
Cc: SecEvent 
References: <02e701d3c299$9c421e40$d4c65ac0$@smyslov.net>  <09566560-11CA-435A-87F4-CFCBC6F889F3@oracle.com> 
From: Yaron Sheffer 
Message-ID: <8b106520-2b47-369f-dad5-613fb3cd56de@gmail.com>
Date: Fri, 30 Mar 2018 15:01:50 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Id-event] SecEvent draft minutes - IETF-101 (London)
X-BeenThere: id-event@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 30 Mar 2018 12:02:00 -0000

I would rather have people who were NOT in the room chime in regarding 
the hums. Otherwise this is the sense of the group. I don't see value in 
reopening a decision just weeks after it was made.

Thanks,
	Yaron

On 30/03/18 13:53, Mike Jones wrote:
> I agree with Phil that having separate push and pull delivery drafts would be a mistake.  Many participants will end up implementing both modalities.  Having them both in one draft will help keep them as common as possible - preventing unnecessary and possibly unintended drift between them.
> 
> Also, as I said at the microphone in London, I think we'll have a much easier time with the IESG taking one draft forward with two closely related delivery modalities defined, rather that two different delivery drafts.  I fear that if we try to get approval for two drafts, we might receive DISCUSS feedback saying "pick one".
> 
> For what it's worth (and to inform people who weren't in the room), my personal sense was that the hums weren't conclusive.  Most of them had significant portions of people humming for both positions.  In short, my (personal) sense was there wasn't clear consensus demonstrated to split the delivery draft.  I think the topic needs more discussion on the list.
> 
> 				Best wishes,
> 				-- Mike
> 
> -----Original Message-----
> From: Id-event  On Behalf Of Phil Hunt
> Sent: Thursday, March 29, 2018 10:15 PM
> To: Yaron Sheffer 
> Cc: SecEvent 
> Subject: Re: [Id-event] SecEvent draft minutes - IETF-101 (London)
> 
> Regarding the hums, I think they may be premature. In part, because there is a unifying draft proposal available now.
> 
> When we formed the group the sole purpose was a common format and a single delivery draft for all cases.
> 
> Several ietf people complained in Argentina about yet another pub sub system the ietf does not need.
> 
> Another comment was made not to follow the route stix/taxii made in developing multiple incompatible methods of delivery.
> 
> If we split the draft we will have 3 methods not two(including Backchannel).
> 
> I worry this will lead to delay from rejection down the road. This should be clarified first.
> 
> I worry with multiple methods, profilers will develop their own undermining the point of this work.
> 
> Maybe I stand alone here, but I think splitting is a mistake.
> 
> Phil
> 
>> On Mar 24, 2018, at 8:00 AM, Yaron Sheffer  wrote:
>>
>> Thank you Valery for taking the minutes. All, please let us know if anything is incorrect or missing.
>>
>> In addition, we had a series of hums on the SET Delivery draft. Per IETF process, we need to validate them on the list. So if you weren't in the room and you have a major objection to the results of these hums, please speak up. I do suggest that before doing so, you review the actual recorded meeting: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.youtube.com_watch-3Fv-3Dr0hbpQqsN6s&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=bZnIUtQK2S3enqQ3E8wJZHxLExg0UyssjEM1UAJ18jw&s=VbJxhADDKAULj3hrOYI1cbC5A8hEmFIesTvuGzkkOP0&e=.
>>
>> IETF 101 London Friday 23 March 2018 9:30 - 11:30
>>
>> [Yaron] (WG status update, agenda bashing) [Annabelle] asks for 10
>> minutes for discussion
>>
>> [Mike] (presents Security Event Token draft update)
>>
>> [Annabelle] (presents SET Token delivery using HTTP draft) [Mike]
>> Microsoft needs for both POLL and PUSH [Phil] Redefining smth in HTTP
>> may cause problems [William] Return codes are only for browsers to
>> display messages for users [Phil] It's needed for resending in case of
>> error (?) [Annabelle] What is MTI - push or poll?
>> [Phil] With PUSH  happened immediately...
>> [Leif] What is MTI for server or for client?
>> [William] Each option has an explicit use case [Yaron (as chair)] We
>> need to have only one preferred option [Phil] There are very different
>> cases [Phil] Push is simple, but in terms of applicability it's not a
>> long term use case [Annabelle] There use cases for both [Phil] Take
>> two and then abandon one [William] Why does the chair require a single
>> MTI [Leif] It's from chair's experience, WG consensus needed [William]
>> We have use cases for both [Mike] Procedurally it's better to keep
>> both methods in one draft [Yaron] Having two methods complicates the
>> description which method is for which situation etc.
>> [William] Still have interoperability issue for receiver [Yaron] Need
>> to resolve this [Leif] WG should decide [Ben as AD] If the WG doesn't
>> select a single method the IESG would probably object [Annabelle] SET
>> will probably be profiled for different use cases [Yaron] Is going to
>> make hums about selecting a single delivery method and whether we need
>> to split the draft [John] What is hum about - mandatory to implement or to deploy?
>> [Leif] We should analyze scenarios
>> [Annabelle] The protocol are unidirectional, so MTI for
>> transmitter/receiver is problematic [Justin] No negotiation, either it
>> is or not, MTI for the receiver is dictated by what the receiver
>> supports [Phil] They both must be able HTTP, the roles can be changed
>> [Leif] Confusion between MTI and to deploy, a good question - select
>> MTI for transmitter [Annabelle] Every transmitter should have both
>> [Tero] Minimal implementation requires one, bigger may have both,
>> single MTI is better then two for limited devices [Annabelle] IoT
>> implementers have special requirement [William] They are application
>> specific, we expected profile this [Yaron] Hum if we need a single MTI
>> for transmitter - silence Later edit: Clearly no support for a single MTI.
>> [Justin] Hum must be for multiple discrete options [Yaron] Hum on use
>> cases for two methods - some hums [Yaron] Hum if both should be MTI -
>> some hums [Yaron] Hum if should not specify MTI - some hums Later
>> edit: room was split between two MTIs and no MTIs.
>> [Annabelle] We should split the spec
>> [Justin] Agree to split the spec
>> [Justin] I hummed for both MTI for transmitter, because they are not
>> usually constrained [Annabelle] SET is possibly to be used w/o HTTP,
>> this is only MTI for those using HTTP; both MTI is problematic because
>> implementers will do unnecessary stuff [William] If both are MTI, we
>> need 2 specs [John] Splitting the spec is the best way [Mike] If
>> split, then the information for developers will be duplicated [Ben]
>> Why single document better (?) [Mike] My experience with JOSE
>> [Annabelle] Significant overlap between documents is SET, otherwise
>> little commonality Later edit: existing editors volunteered to take Push-specific doc, Annabelle and Mike volunteered to work on Poll.
>> [from jabber] Little commonality between two methods [Mike] We'll do
>> both, we have use cases for both [Yaron] Hum if split documents - some
>> long hums [Yaron] Hum if one document - some hums [Yaron] Room is in
>> favor of splitting the documents [Yaron] Wrap up: no MTI, split the
>> document into two, transmitter implements either or both
>>
>> [Annabelle] (presenting Subject Identifier Types) [Mike] 3rd party
>> specifications cannot establish IANA registry [Leif] IANA Expert?
>> [Ben] FCFS, doesn't need Expert, or specification required [Leif] I
>> support this idea [William] I also support [Yaron] Any objections to
>> adopt this document? No objections, publish as WG document
>>
>> [Annabelle] Expiration ("exp") claim is not recommended; however it
>> has some value [Mike] It's a layering violation; problems with caching
>> [Annabelle] We're not talking about caching, you don't want to grow
>> anti-replay database forever, having expiration helps [Phil] The past
>> doesn't expire, it's up to receiver how to use it, caching doesn't make sense [Yaron] What about replay protection?
>> [Mike] JTI helps to detect replay (?) [from jabber] Transport should
>> deal with replay [John] Expiry is expected to mean that token should
>> not be processed after that, it's not an indication that information
>> is no longer valid [Mike] It must not be mandatory [Annabelle]
>> Currently the draft says it's not recommended [Mike] We have to allow it to be optional because of the need to distinguish from access tokens.
>> [Ben] Some use case when processing expired token (?) [John] Have an
>> explicit expire for JTI, there are other solutions [Phil] I prefer to
>> add a new attribute to SET, not changing ...
>> [Yaron] The document in LC, smaller changes are OK without blocking the doc's progress.
>> [Phil] Replay and caching are different for PUSH and POLL, prefer to
>> see in HTTP header [Brian] Expiration is not necessary, receiver has
>> policy to follow [Annabelle] No-one is advocating using exp for
>> caching [from jabber] JTI expiration belongs to JTI not to transport
>> [Yaron] We're not ready to have hum, room thinks there is an issue, please work through it on the list.
>>
>> [Phil] Presents his SSTP Delivery draft - symmetric transport
>> protocol, parameters used in requests and response are same [Phil] We
>> would change optionality from two methods to a single one, may be a compromise [Yaron] The protocol was only published yesterday, so we are not ready to discuss now.
>>
>> [Meeting adjourned.]
>>
>> _______________________________________________
>> Id-event mailing list
>> Id-event@ietf.org
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
>> man_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65
>> eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=bZnIUtQK2S3en
>> qQ3E8wJZHxLExg0UyssjEM1UAJ18jw&s=bm9Kqkwb8W8ClkdHFvnnH60BmArjysl02dP_3
>> TAjwew&e=
> 
> _______________________________________________
> Id-event mailing list
> Id-event@ietf.org
> https://www.ietf.org/mailman/listinfo/id-event
>