From rolf.brugger@switch.ch Thu Mar 10 08:51:13 2016 Return-Path: X-Original-To: vot@ietfa.amsl.com Delivered-To: vot@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0E8C12D716 for ; Thu, 10 Mar 2016 08:51:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.867 X-Spam-Level: X-Spam-Status: No, score=-1.867 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FILL_THIS_FORM=0.001, FILL_THIS_FORM_FRAUD_PHISH=0.334, FILL_THIS_FORM_LONG=2, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HqlENyoDD-BF for ; Thu, 10 Mar 2016 08:51:09 -0800 (PST) Received: from iberico.switch.ch (iberico.switch.ch [IPv6:2001:620:0:1002::27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5088512D715 for ; Thu, 10 Mar 2016 08:51:08 -0800 (PST) Received: from surlej.switch.ch (surlej.switch.ch [IPv6:2001:620:0:1001::69]) by iberico.switch.ch (8.14.4/8.14.4/Debian-4) with ESMTP id u2AGp5ie002929 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 10 Mar 2016 17:51:06 +0100 Received: from macrb.switch.ch ([2001:620:0:44:426c:8fff:fe37:cd48]) by surlej.switch.ch with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1ae3nl-0005yQ-7B for vot@ietf.org; Thu, 10 Mar 2016 17:51:05 +0100 To: vot@ietf.org From: Rolf Brugger Message-ID: <56E1A5F8.3090201@switch.ch> Date: Thu, 10 Mar 2016 17:51:04 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-CanIt-Geo: ip=2001:620:0:1001::69; country=CH; region=Zurich; city=Zurich; latitude=47.3720; longitude=8.5413; http://maps.google.com/maps?q=47.3720,8.5413&z=6 X-CanItPRO-Stream: switch-ch:outbound (inherits from switch-ch:default, base:default) X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: Subject: [VoT] How to express duplicate checks with VoT? X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 17:00:53 -0000 Hi all, I'm new to this list and I hope my question is not totally irrelevant here. We have plenty of use cases where RPs need to have confidence, that a person does not have multiple identities in one IdP. I don't see how this aspect of identity quality can be expressed, and I believe it is pretty orthogonal to the P, C, M and A dimensions that are currently specified in the VoT draft. We could imagine multiple ways to gradually prove that an identity has been checked against duplicates. The most straightforward approach would be to make sure that unique personal attributes are used only once within one IdP or an IdP federation, like - email address(es) - mobile phone number - home postal address - social security number - ID / passport number - the combination of name and birth date - etc. Would it make sense to express this in VoT? best regards Rolf -- SWITCH -------------------------- Rolf Brugger, project Swiss edu-ID Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland phone +41 44 268 15 15, direct +41 44 268 15 89 rolf.brugger@switch.ch, http://www.switch.ch From nobody Thu Mar 10 10:57:53 2016 Return-Path: X-Original-To: vot@ietfa.amsl.com Delivered-To: vot@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C913B12DBD6 for ; Thu, 10 Mar 2016 10:57:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.822 X-Spam-Level: X-Spam-Status: No, score=-2.822 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nptMijsPt0uw for ; Thu, 10 Mar 2016 10:57:49 -0800 (PST) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C0C412DBD7 for ; Thu, 10 Mar 2016 10:57:49 -0800 (PST) X-AuditID: 1209190d-e37ff70000004dee-88-56e1c3ac0a67 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 80.FB.19950.CA3C1E65; Thu, 10 Mar 2016 13:57:48 -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 u2AIvlko013706; Thu, 10 Mar 2016 13:57:48 -0500 Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u2AIvjL5015542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 10 Mar 2016 13:57:46 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Justin Richer In-Reply-To: <56E1A5F8.3090201@switch.ch> Date: Thu, 10 Mar 2016 13:57:44 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56E1A5F8.3090201@switch.ch> To: Rolf Brugger X-Mailer: Apple Mail (2.2104) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOIsWRmVeSWpSXmKPExsUixG6norvm8MMwg5OLZCyaevawWzT8fMDq wOSxZMlPJo/2IxPYA5iiuGxSUnMyy1KL9O0SuDLOPLYseMBbcX39JeYGxibuLkZODgkBE4m/ hz+zdjFycQgJtDFJ3Dk2hx3C2cgo8bD5HguE85BJ4vSci+wgLcwC6hJ/5l1iBrF5BfQkXt26 zApiCwvYSJxvP8IGYrMJqEpMX9PCBGJzCmhKrPr5AqyGBSg+YdUKFog5AhJzD01jgrC1JZYt fA0100qiY9dOoDkcQIs1JN5NtQYJiwCNufP7ECvE1bISu38/YprAKDALyUWzkFw0C8nUBYzM qxhlU3KrdHMTM3OKU5N1i5MT8/JSi3SN9HIzS/RSU0o3MYLClFOSdwfjv7tehxgFOBiVeHgF ah6ECbEmlhVX5h5ilORgUhLlXbP/YZgQX1J+SmVGYnFGfFFpTmrxIUYJDmYlEV7/tUA53pTE yqrUonyYlDQHi5I4b8zNo2FCAumJJanZqakFqUUwWQ0ODoEZ5+ZOZ5JiycvPS1WS4LU+BDRE sCg1PbUiLTOnBKGUiYMTZBEP0CJfkBre4oLE3OLMdIj8KUZFKXFeLZCEAEgiozQPrheUXhLe HjZ9xSgO9JYwbyxIFQ8wNcF1vwIazAQ0+EXrPZDBJYkIKakGxrJ/d/59TA2pmckkt7l8754k RpFc5m8SnZJr2S2Wqiv9NOxYM6Fhs6Ewy8c473aZ+a9ezmvYKzWjYqXHV3fpwB0lK7ifZjDG +D3L3/BaM5fxed4nA+NiXpuoS5e37lbvuLJj3lx+27/OmrVzjKfuTrP3fLepYcEDq7ziooS+ ZQXRGV/r9mzfpcRSnJFoqMVcVJwIAJe/WmwKAwAA Archived-At: Cc: vot@ietf.org Subject: Re: [VoT] How to express duplicate checks with VoT? X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 18:57:52 -0000 This would probably be another category/dimension, I think. Unless you = wanted to wrap it into your own definitions of the =E2=80=9CP=E2=80=9D = dimension, where there=E2=80=99d be a =E2=80=9CPu=E2=80=9D for = =E2=80=9Cproofed unique=E2=80=9D that could be added to that category.=20= =E2=80=94 Justin > On Mar 10, 2016, at 11:51 AM, Rolf Brugger = wrote: >=20 > Hi all, >=20 > I'm new to this list and I hope my question is not totally irrelevant = here. >=20 > We have plenty of use cases where RPs need to have confidence, that a = person does not have multiple identities in one IdP. I don't see how = this aspect of identity quality can be expressed, and I believe it is = pretty orthogonal to the P, C, M and A dimensions that are currently = specified in the VoT draft. >=20 > We could imagine multiple ways to gradually prove that an identity has = been checked against duplicates. The most straightforward approach would = be to make sure that unique personal attributes are used only once = within one IdP or an IdP federation, like > - email address(es) > - mobile phone number > - home postal address > - social security number > - ID / passport number > - the combination of name and birth date > - etc. >=20 > Would it make sense to express this in VoT? >=20 > best regards >=20 > Rolf >=20 >=20 > --=20 > SWITCH > -------------------------- > Rolf Brugger, project Swiss edu-ID > Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland > phone +41 44 268 15 15, direct +41 44 268 15 89 > rolf.brugger@switch.ch, http://www.switch.ch >=20 > _______________________________________________ > vot mailing list > vot@ietf.org > https://www.ietf.org/mailman/listinfo/vot From nobody Thu Mar 10 11:27:45 2016 Return-Path: X-Original-To: vot@ietfa.amsl.com Delivered-To: vot@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D34B712DC02 for ; Thu, 10 Mar 2016 11:27:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FfqOcf1Dfner for ; Thu, 10 Mar 2016 11:27:41 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0057.outbound.protection.outlook.com [65.55.169.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9914E12DBFD for ; Thu, 10 Mar 2016 11:27:41 -0800 (PST) Received: from BN3PR0601MB1956.namprd06.prod.outlook.com (10.165.119.146) by BN3PR0601MB1955.namprd06.prod.outlook.com (10.165.119.145) with Microsoft SMTP Server (TLS) id 15.1.434.16; Thu, 10 Mar 2016 19:27:39 +0000 Received: from BN3PR0601MB1956.namprd06.prod.outlook.com ([10.165.119.146]) by BN3PR0601MB1956.namprd06.prod.outlook.com ([10.165.119.146]) with mapi id 15.01.0434.016; Thu, 10 Mar 2016 19:27:39 +0000 From: Eric Goodman To: "vot@ietf.org" Thread-Topic: [VoT] How to express duplicate checks with VoT? Thread-Index: AQHRev7BCw/Ruv/PkE24C055dh5VIJ9TDuLQ Date: Thu, 10 Mar 2016 19:27:39 +0000 Message-ID: References: <56E1A5F8.3090201@switch.ch> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ucop.edu; x-originating-ip: [128.48.44.96] x-ms-office365-filtering-correlation-id: c1dd3b52-3b9b-4a14-00e5-08d3491a0b4e x-microsoft-exchange-diagnostics: 1; BN3PR0601MB1955; 5:HlcyWV8cNY9cYc2epmOAjAH4o7g22Hx/FvzUaFZiGImQnH/ddwOagNba0YyaAWw8aDSRq+4ewaX3dQ2Whakn/LxnLYbgyQ6GksJL9DxEbMiyKO5q7x65BABHcbHKdFcVn0GtEzSE0eNVOY0IFT7Mkw==; 24:I5rhkXFmUu51BwXG52fMNsCiFPo9XOJ6cP4+fpe2yz00MH932B1WG0rlnmjxTyxjts2bgK2PjwzfdM48PMiggYJj9pOjiosfXsM4Ai5L/Lc= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0601MB1955; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:BN3PR0601MB1955; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0601MB1955; x-forefront-prvs: 08770259B4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(53754006)(24454002)(13464003)(377454003)(5004730100002)(50986999)(3280700002)(89122001)(2351001)(110136002)(107886002)(87936001)(450100001)(189998001)(2906002)(74316001)(1096002)(1220700001)(3660700001)(76576001)(86362001)(2501003)(33656002)(81166005)(122556002)(5640700001)(66066001)(5002640100001)(6116002)(54356999)(1730700002)(102836003)(3846002)(586003)(90282001)(76176999)(2900100001)(106116001)(77096005)(5003600100002)(75432002)(10400500002)(5008740100001)(92566002)(19580395003)(2950100001)(15975445007)(11100500001)(19580405001)(99286002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR0601MB1955; H:BN3PR0601MB1956.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ucop.edu X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Mar 2016 19:27:39.5604 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6737ae8b-7f79-4cda-90a2-1861f16fa830 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0601MB1955 Archived-At: Subject: Re: [VoT] How to express duplicate checks with VoT? X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 19:27:44 -0000 VGhpcyBzZWVtcyBsaWtlIGl0IHdvdWxkIGJlIHJlYWxseSBoYXJkIHRvIHNwZWNpZnksIHVubGVz cyB5b3Ugc2NvcGUgaXQgcHJldHR5IGNsZWFybHkuDQoNCiJQcm9vZmVkIHVuaXF1ZSBhbW9uZyBh Y2NvdW50cyB3aXRoIGlkZW50aXR5IHZldHRpbmcgbGV2ZWwgKG1vZGVyYXRlIG9yIGhpZ2hlciki IHNlZW1zIGxpa2UgaXQgbWlnaHQgYmUgYWNoaWV2YWJsZSAoYW5kIG1heWJlIGlzIHdoYXQgeW91 IGhhdmUgaW4gbWluZCkuICJQcm9vZmVkIHVuaXF1ZSIgbGl0ZXJhbGx5IHNlZW1zIG5lYXJseSBp bXBvc3NpYmxlLiBIb3cgd291bGQgeW91IHByb3ZlIHNvbWVvbmUgZGlkbid0IGdldCBhIGxvdy12 YWx1ZSBhY2NvdW50IG9uIHRoZSBzYW1lIElkUD8gDQoNClRoZSBjaGFsbGVuZ2UgdG8gbWUgd291 bGQgYmUgZGVmaW5pbmcgdGhlIHNjb3BlIGluIGEgd2F5IHRoYXQgaXMgdW5kZXJzdGFuZGFibGUg YW5kIGFncmVlYWJsZS4NCg0KLS0tIEVyaWMNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IHZvdCBbbWFpbHRvOnZvdC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSnVz dGluIFJpY2hlcg0KU2VudDogVGh1cnNkYXksIE1hcmNoIDEwLCAyMDE2IDEwOjU4IEFNDQpUbzog Um9sZiBCcnVnZ2VyDQpDYzogdm90QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1ZvVF0gSG93IHRv IGV4cHJlc3MgZHVwbGljYXRlIGNoZWNrcyB3aXRoIFZvVD8NCg0KVGhpcyB3b3VsZCBwcm9iYWJs eSBiZSBhbm90aGVyIGNhdGVnb3J5L2RpbWVuc2lvbiwgSSB0aGluay4gVW5sZXNzIHlvdSB3YW50 ZWQgdG8gd3JhcCBpdCBpbnRvIHlvdXIgb3duIGRlZmluaXRpb25zIG9mIHRoZSDigJxQ4oCdIGRp bWVuc2lvbiwgd2hlcmUgdGhlcmXigJlkIGJlIGEg4oCcUHXigJ0gZm9yIOKAnHByb29mZWQgdW5p cXVl4oCdIHRoYXQgY291bGQgYmUgYWRkZWQgdG8gdGhhdCBjYXRlZ29yeS4gDQoNCiDigJQgSnVz dGluDQoNCj4gT24gTWFyIDEwLCAyMDE2LCBhdCAxMTo1MSBBTSwgUm9sZiBCcnVnZ2VyIDxyb2xm LmJydWdnZXJAc3dpdGNoLmNoPiB3cm90ZToNCj4gDQo+IEhpIGFsbCwNCj4gDQo+IEknbSBuZXcg dG8gdGhpcyBsaXN0IGFuZCBJIGhvcGUgbXkgcXVlc3Rpb24gaXMgbm90IHRvdGFsbHkgaXJyZWxl dmFudCBoZXJlLg0KPiANCj4gV2UgaGF2ZSBwbGVudHkgb2YgdXNlIGNhc2VzIHdoZXJlIFJQcyBu ZWVkIHRvIGhhdmUgY29uZmlkZW5jZSwgdGhhdCBhIHBlcnNvbiBkb2VzIG5vdCBoYXZlIG11bHRp cGxlIGlkZW50aXRpZXMgaW4gb25lIElkUC4gSSBkb24ndCBzZWUgaG93IHRoaXMgYXNwZWN0IG9m IGlkZW50aXR5IHF1YWxpdHkgY2FuIGJlIGV4cHJlc3NlZCwgYW5kIEkgYmVsaWV2ZSBpdCBpcyBw cmV0dHkgb3J0aG9nb25hbCB0byB0aGUgUCwgQywgTSBhbmQgQSBkaW1lbnNpb25zIHRoYXQgYXJl IGN1cnJlbnRseSBzcGVjaWZpZWQgaW4gdGhlIFZvVCBkcmFmdC4NCj4gDQo+IFdlIGNvdWxkIGlt YWdpbmUgbXVsdGlwbGUgd2F5cyB0byBncmFkdWFsbHkgcHJvdmUgdGhhdCBhbiBpZGVudGl0eSBo YXMgDQo+IGJlZW4gY2hlY2tlZCBhZ2FpbnN0IGR1cGxpY2F0ZXMuIFRoZSBtb3N0IHN0cmFpZ2h0 Zm9yd2FyZCBhcHByb2FjaCANCj4gd291bGQgYmUgdG8gbWFrZSBzdXJlIHRoYXQgdW5pcXVlIHBl cnNvbmFsIGF0dHJpYnV0ZXMgYXJlIHVzZWQgb25seSANCj4gb25jZSB3aXRoaW4gb25lIElkUCBv ciBhbiBJZFAgZmVkZXJhdGlvbiwgbGlrZQ0KPiAtIGVtYWlsIGFkZHJlc3MoZXMpDQo+IC0gbW9i aWxlIHBob25lIG51bWJlcg0KPiAtIGhvbWUgcG9zdGFsIGFkZHJlc3MNCj4gLSBzb2NpYWwgc2Vj dXJpdHkgbnVtYmVyDQo+IC0gSUQgLyBwYXNzcG9ydCBudW1iZXINCj4gLSB0aGUgY29tYmluYXRp b24gb2YgbmFtZSBhbmQgYmlydGggZGF0ZQ0KPiAtIGV0Yy4NCj4gDQo+IFdvdWxkIGl0IG1ha2Ug c2Vuc2UgdG8gZXhwcmVzcyB0aGlzIGluIFZvVD8NCj4gDQo+IGJlc3QgcmVnYXJkcw0KPiANCj4g Um9sZg0KPiANCj4gDQo+IC0tDQo+IFNXSVRDSA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KPiBSb2xmIEJydWdnZXIsIHByb2plY3QgU3dpc3MgZWR1LUlEDQo+IFdlcmRzdHJhc3NlIDIs IFAuTy4gQm94LCA4MDIxIFp1cmljaCwgU3dpdHplcmxhbmQgcGhvbmUgKzQxIDQ0IDI2OCAxNSAN Cj4gMTUsIGRpcmVjdCArNDEgNDQgMjY4IDE1IDg5IHJvbGYuYnJ1Z2dlckBzd2l0Y2guY2gsIA0K PiBodHRwOi8vd3d3LnN3aXRjaC5jaA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gdm90IG1haWxpbmcgbGlzdA0KPiB2b3RAaWV0Zi5vcmcN Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92b3QNCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnZvdCBtYWlsaW5nIGxpc3QN CnZvdEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92b3QN Cg== From nobody Thu Mar 10 17:57:04 2016 Return-Path: X-Original-To: vot@ietfa.amsl.com Delivered-To: vot@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A89A12DF99 for ; Thu, 10 Mar 2016 17:57:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nz.smxemail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ePjC-q1rvO7Y for ; Thu, 10 Mar 2016 17:57:00 -0800 (PST) Received: from out1101.nz.smxemail.com (out1101.nz.smxemail.com [203.84.134.32]) (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 4058212D978 for ; Thu, 10 Mar 2016 17:56:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=nz.smxemail.com; s=alpha; c=relaxed/relaxed; q=dns/txt; i=@nz.smxemail.com; t=1457661418; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc; bh=svNOGPzh556RjmnwJopWwEH7PISWKo7JzfTZXKOyDO0=; b=xn9pWmkG3sG82HrvJ1nGMnTtUWXVcuZ/3lcwnJB5g7jinpeu7kKqDAjADtix53kC InROGFne2NwOlmCRaIu9ukp6lWJZtV2ZnDJdOTfDiK0UjyyQeSkLjLeJWFXL4y2i FhPaumTsQni97FVtGtIdIyCiDuLicgAtSPQC96uDrw4=; Received: from s111-0006-lnv01 ([131.203.48.73]) by omr.nz.smxemail.com with ESMTP (using TLSv1 with cipher AES256-SHA (256/256 bits)) id 56E225E9-C8192065@mta1102.omr; Fri, 11 Mar 2016 01:56:58 +0000 Message-ID: <569AD906E45DB44A8AFF11D61F5DA7910155C7D4F2@AKLDRMBX03.dia.govt.nz> MIME-Version: 1.0 X-MessageIsInfected: false Received: from 161-65-142-21.ip.fx.net.nz (EHLO WLGPRDMM01.dia.govt.nz) ([161.65.142.21]) by s111-0006-lnv01 (JAMES SMTP Server ) with ESMTP ID 259634431; Fri, 11 Mar 2016 14:56:55 +1300 (NZDT) Received: from AKLDRCAS01.dia.govt.nz (Not Verified[10.104.240.45]) by WLGPRDMM01.dia.govt.nz with MailMarshal (v7, 1, 1, 5205) (using TLS: SSLv23) id ; Fri, 11 Mar 2016 14:56:56 +1300 Received: from AKLDRMBX03.dia.govt.nz ([fe80::d1c1:15a7:3e85:ac71]) by AKLDRCAS01.dia.govt.nz ([10.104.240.45]) with mapi id 14.03.0279.002; Fri, 11 Mar 2016 14:56:54 +1300 From: Joanne Knight To: 'Rolf Brugger' , "vot@ietf.org" Thread-Topic: [VoT] How to express duplicate checks with VoT? Thread-Index: AQHRewefr30T8sn2a0aikcEmelKPBJ9TcuzA Date: Fri, 11 Mar 2016 01:56:54 +0000 References: <56E1A5F8.3090201@switch.ch> In-Reply-To: <56E1A5F8.3090201@switch.ch> Accept-Language: en-NZ, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailadviser: Confirmation not required x-originating-ip: [10.220.229.74] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [VoT] How to express duplicate checks with VoT? X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 01:57:03 -0000 SGkgQWxsDQoNClRoZXJlIGFyZSB0aHJlZSBhc3BlY3Qgb3IgbGV2ZWxzIHdoZW4gbG9va2luZyBh dCB1bmlxdWVuZXNzIHRvIGJlIGNvbnNpZGVyZWQuDQoNCkZpcnN0IGxldmVsIGlzIHRoYXQgdGhl IGlkZW50aXR5IGlzIHVuaXF1ZSAtIHRoYXQgaXMsIHdpdGhpbiBhIGNvbnRleHQgdGhlcmUgaXMg YSBzZXQgb2YgYXR0cmlidXRlcyB0aGF0IGFyZSB1bmlxdWUgZm9yIGVhY2ggaWRlbnRpdHkgcmVn aXN0ZXJlZC4NCg0KU2Vjb25kIGxldmVsIGlzIHNvbGUgY2xhaW1hbnQgLSB0aGlzIGlzIGEgY2hl Y2sgdGhhdCBvbmx5IG9uZSBlbnRpdHkgaGFzIGNsYWltZWQgYSBwYXJ0aWN1bGFyIHNldCBvZiBh dHRyaWJ1dGVzLiBBdCB0aGUgaGlnaGVyIGxldmVscyBvZiBpZGVudGl0eSBwcm9vZmluZyB3aGVy ZSBhdXRob3JpdGF0aXZlIHNvdXJjZXMgYXJlIHVzZWQgaXQgbWF5IGJlIHBvc3NpYmxlIHRvIGFj aGlldmUgdGhpcy4gVGhpcyBpcyBzdWZmaWNpZW50IGluIG1vc3QgUlBzIGNhc2VzLiBBdCB0aGlz IGxldmVsIHdoaWxlIGl0IGlzIHBvc3NpYmxlIGZvciBhIHNpbmdsZSBlbnRpdHkgdG8gY2xhaW0g bW9yZSB0aGFuIG9uZSBpZGVudGl0eSwgdGhleSBkbyBzbyBhdCB0aGUgcmlzayBvZiBjYXVzaW5n IGEgY291bnRlci1mcmF1ZCBmbGFnIHNob3VsZCB0aGUgcmVhbCBvd25lciAob3IgYW55IG90aGVy IHBhcnR5KSBhbHNvIGF0dGVtcHQgdG8gY2xhaW0gdGhlIGlkZW50aXR5Lg0KDQpUaGUgZmluYWwg bGV2ZWwgaXMgb25lIGFuZCBvbmx5IG9uZSAtIFRoaXMgaXMgYSBjaGVjayAtIHVzdWFsbHkgYmlv bWV0cmljIC0gdGhhdCBhbiBlbnRpdHkgaGFzIG9ubHkgb25lIGNsYWltIGluIHRoZSBjb250ZXh0 LiBUaGlzIGlzIHVzdWFsbHkgb25seSByZXNlcnZlZCBmb3IgdGhlIGhpZ2hlc3QgbGV2ZWwgb2Yg aWRlbnRpdHkgYW5kIHdvdWxkIGFsc28gcmVxdWlyZSBlcXVhbGx5IGhpZ2ggbGV2ZWxzIG9mIGNy ZWRlbnRpYWwgYW5kIGNyZWRlbnRpYWwgaXNzdWFuY2UgcHJvY2Vzc2VzLg0KDQpBcyB0byBob3cg dGhpcyByZWxhdGVzIHRvIFZvVCAtIA0KVGhlIGZpcnN0IHNob3VsZCBiZSBpbm5hdGVseSBidWls dCBpbnRvIGFsbCBsZXZlbHMgb2YgUCAtIGl0IGlzIHRoZSBzb2xlIHJlcXVpcmVtZW50IG9mIGFs bCBsZXZlbHMNCg0KVGhlIHNlY29uZCBjb3VsZCBiZSBidWlsdCBpbnRvIFAzIGlmIHRoZSB3b3Jk aW5nIHdhcyBhbWVuZGVkIHNsaWdodGx5Lg0KDQpUaGUgbGFzdCBpdGVtIG9ubHkgaXMgc3Vic3Rh bnRpdmVseSBtaXNzaW5nIGFuZCB0byBkYXRlIChpbiB0aGUgY29udmVyc2F0aW9ucyBJIGhhdmUg YmVlbiBoYXZpbmcgZWxzZXdoZXJlKSB0aGVyZSBoYXMgYmVlbiBpbnN1ZmZpY2llbnQgYXBwZXRp dGUgdG8gYWRkIGl0IGFzIGFuIGV4cGxpY2l0IHJlcXVpcmVtZW50LiANCg0KU2hvdWxkIHdlIGhh dmUgYSBQVT8gTWF5YmUsIGJ1dCBzdGVlciBjbGVhciBvZiB0aGUgdGVybSAndW5pcXVlJw0KSWYg d2UgZG8sIGluIG15IG1pbmQgaXQgd291bGQgb25seSBoYXZlIHR3byB2YWx1ZXMgLSBQPzAgLSBD bGFpbXMgcGVyIGVudGl0eSBub3QgY2hlY2tlZCwgUD8xIC0gQ2xhaW1zIHBlciBlbnRpdHkgcmVz dHJpY3RlZCB0byBvbmUuDQoNCkpvYW5uZQ0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiBSb2xmIEJydWdnZXIgW21haWx0bzpyb2xmLmJydWdnZXJAc3dpdGNoLmNoXSANClNl bnQ6IEZyaWRheSwgMTEgTWFyY2ggMjAxNiA1OjUxIGEubS4NClRvOiB2b3RAaWV0Zi5vcmcNClN1 YmplY3Q6IFtWb1RdIEhvdyB0byBleHByZXNzIGR1cGxpY2F0ZSBjaGVja3Mgd2l0aCBWb1Q/DQoN CkhpIGFsbCwNCg0KSSdtIG5ldyB0byB0aGlzIGxpc3QgYW5kIEkgaG9wZSBteSBxdWVzdGlvbiBp cyBub3QgdG90YWxseSBpcnJlbGV2YW50IGhlcmUuDQoNCldlIGhhdmUgcGxlbnR5IG9mIHVzZSBj YXNlcyB3aGVyZSBSUHMgbmVlZCB0byBoYXZlIGNvbmZpZGVuY2UsIHRoYXQgYSBwZXJzb24gZG9l cyBub3QgaGF2ZSBtdWx0aXBsZSBpZGVudGl0aWVzIGluIG9uZSBJZFAuIEkgZG9uJ3Qgc2VlIGhv dyB0aGlzIGFzcGVjdCBvZiBpZGVudGl0eSBxdWFsaXR5IGNhbiBiZSBleHByZXNzZWQsIGFuZCBJ IGJlbGlldmUgaXQgaXMgcHJldHR5IG9ydGhvZ29uYWwgdG8gdGhlIFAsIEMsIE0gYW5kIEEgZGlt ZW5zaW9ucyB0aGF0IGFyZSBjdXJyZW50bHkgc3BlY2lmaWVkIGluIHRoZSBWb1QgZHJhZnQuDQoN CldlIGNvdWxkIGltYWdpbmUgbXVsdGlwbGUgd2F5cyB0byBncmFkdWFsbHkgcHJvdmUgdGhhdCBh biBpZGVudGl0eSBoYXMgYmVlbiBjaGVja2VkIGFnYWluc3QgZHVwbGljYXRlcy4gVGhlIG1vc3Qg c3RyYWlnaHRmb3J3YXJkIGFwcHJvYWNoIHdvdWxkIGJlIHRvIG1ha2Ugc3VyZSB0aGF0IHVuaXF1 ZSBwZXJzb25hbCBhdHRyaWJ1dGVzIGFyZSB1c2VkIG9ubHkgb25jZSB3aXRoaW4gb25lIElkUCBv ciBhbiBJZFAgZmVkZXJhdGlvbiwgbGlrZQ0KLSBlbWFpbCBhZGRyZXNzKGVzKQ0KLSBtb2JpbGUg cGhvbmUgbnVtYmVyDQotIGhvbWUgcG9zdGFsIGFkZHJlc3MNCi0gc29jaWFsIHNlY3VyaXR5IG51 bWJlcg0KLSBJRCAvIHBhc3Nwb3J0IG51bWJlcg0KLSB0aGUgY29tYmluYXRpb24gb2YgbmFtZSBh bmQgYmlydGggZGF0ZQ0KLSBldGMuDQoNCldvdWxkIGl0IG1ha2Ugc2Vuc2UgdG8gZXhwcmVzcyB0 aGlzIGluIFZvVD8NCg0KYmVzdCByZWdhcmRzDQoNClJvbGYNCg0KDQotLQ0KU1dJVENIDQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KUm9sZiBCcnVnZ2VyLCBwcm9qZWN0IFN3aXNzIGVkdS1J RA0KV2VyZHN0cmFzc2UgMiwgUC5PLiBCb3gsIDgwMjEgWnVyaWNoLCBTd2l0emVybGFuZCBwaG9u ZSArNDEgNDQgMjY4IDE1IDE1LCBkaXJlY3QgKzQxIDQ0IDI2OCAxNSA4OSByb2xmLmJydWdnZXJA c3dpdGNoLmNoLCBodHRwOi8vd3d3LnN3aXRjaC5jaA0KDQoNCg== From nobody Fri Mar 11 10:46:18 2016 Return-Path: X-Original-To: vot@ietfa.amsl.com Delivered-To: vot@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EBBE12DA43 for ; Fri, 11 Mar 2016 10:46:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.123 X-Spam-Level: X-Spam-Status: No, score=-1.123 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ucaid.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYiho-DPVXcE for ; Fri, 11 Mar 2016 10:46:10 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0101.outbound.protection.outlook.com [207.46.100.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A31212DA3D for ; Fri, 11 Mar 2016 10:46:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ucaid.onmicrosoft.com; s=selector1-internet2-edu; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=0d2ICaGSyxcqI+Is3snMdsv45sVKAsh7yVuH8hAFaYU=; b=R4MHOL0sxC2Du88G09c0y9fv3Ds590qhY40AyYLmXbzhxM6KTy0s6dHYqLKlpMBHiAF3xIWpnQyRg3v/xkGzHejQQo9ywdM+p1H3Vc9qp23E1KLEH/+Oe9VuCDsq4z5Jd80VRUXGUTVpvD+x5hloAxBcFpX8J6BTl6Ufu0aZf8s= Received: from SN2PR0801MB558.namprd08.prod.outlook.com (10.160.15.148) by SN2PR0801MB557.namprd08.prod.outlook.com (10.160.15.147) with Microsoft SMTP Server (TLS) id 15.1.427.16; Fri, 11 Mar 2016 18:46:07 +0000 Received: from SN2PR0801MB558.namprd08.prod.outlook.com ([10.160.15.148]) by SN2PR0801MB558.namprd08.prod.outlook.com ([10.160.15.148]) with mapi id 15.01.0427.020; Fri, 11 Mar 2016 18:46:07 +0000 From: Nick Roy To: Joanne Knight , 'Rolf Brugger' , "vot@ietf.org" Thread-Topic: [VoT] How to express duplicate checks with VoT? Thread-Index: AQHReu5sFTVOaoCnpU27iqOSviuFLp9TfLUAgACknwA= Date: Fri, 11 Mar 2016 18:46:07 +0000 Message-ID: References: <56E1A5F8.3090201@switch.ch> <569AD906E45DB44A8AFF11D61F5DA7910155C7D4F2@AKLDRMBX03.dia.govt.nz> In-Reply-To: <569AD906E45DB44A8AFF11D61F5DA7910155C7D4F2@AKLDRMBX03.dia.govt.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dia.govt.nz; dkim=none (message not signed) header.d=none;dia.govt.nz; dmarc=none action=none header.from=internet2.edu; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2601:283:4202:d50:756b:2df:437f:a10c] x-ms-office365-filtering-correlation-id: 422bde18-2ade-4612-cb86-08d349dd6841 x-microsoft-exchange-diagnostics: 1; SN2PR0801MB557; 5:JuwH/gPuvmydrwWZid/DMOA4x8noND+GqOaYN3cEa/V7QYaD69d5K7nbqGTdF95aiQV4hRvEUyUsRcuAvfiFbbuJjL+8g+2V+SilVWskBhw69PGr23Wp7icmk6ifRUKcmsfhbhmRTsLPMxwB1l2SMA==; 24:kG9iY72rIM9qgE+ZqCR6MTFmsmfKjGztXqI96grXWzBACzrKDxoE0Flo80UYU0w6rArkdsUJcZvbQ2NVJUlr3ojwzjAkjlIJBlfTXGgK5yc= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN2PR0801MB557; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:SN2PR0801MB557; BCL:0; PCL:0; RULEID:; SRVR:SN2PR0801MB557; x-forefront-prvs: 087894CD3C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(479174004)(377454003)(13464003)(53754006)(24454002)(83716003)(106116001)(189998001)(5001770100001)(107886002)(75432002)(19580395003)(99286002)(82746002)(88552002)(19580405001)(2906002)(122556002)(10400500002)(33656002)(90282001)(77096005)(2950100001)(15975445007)(1096002)(2900100001)(3280700002)(1220700001)(3660700001)(36756003)(5008740100001)(87936001)(11100500001)(92566002)(6116002)(102836003)(586003)(54356999)(86362001)(16601075003)(81166005)(2501003)(50986999)(5002640100001)(76176999)(5004730100002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR0801MB557; H:SN2PR0801MB558.namprd08.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <2737D1646A85F04C8641F479F7538783@namprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: internet2.edu X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Mar 2016 18:46:07.3083 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 78ea4b46-9f08-4ef5-949b-2dae057c55d8 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR0801MB557 Archived-At: Subject: Re: [VoT] How to express duplicate checks with VoT? X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 18:46:15 -0000 Um9sZiwgYXJlIHlvdXIgUlBzIHVzZSBjYXNlcyBldmVyIGFwcHJvYWNoaW5nIHRoZSBsYXN0IGxl dmVsIHRoYXQgSm9hbm5lIG1lbnRpb25zIGJlbG93PyAgSG9wZWZ1bGx5IG5vdC4uLg0KDQpOaWNr DQoNCg0KDQoNCk9uIDMvMTAvMTYsIDY6NTYgUE0sICJ2b3Qgb24gYmVoYWxmIG9mIEpvYW5uZSBL bmlnaHQiIDx2b3QtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgSm9hbm5lLktuaWdodEBk aWEuZ292dC5uej4gd3JvdGU6DQoNCj5IaSBBbGwNCj4NCj5UaGVyZSBhcmUgdGhyZWUgYXNwZWN0 IG9yIGxldmVscyB3aGVuIGxvb2tpbmcgYXQgdW5pcXVlbmVzcyB0byBiZSBjb25zaWRlcmVkLg0K Pg0KPkZpcnN0IGxldmVsIGlzIHRoYXQgdGhlIGlkZW50aXR5IGlzIHVuaXF1ZSAtIHRoYXQgaXMs IHdpdGhpbiBhIGNvbnRleHQgdGhlcmUgaXMgYSBzZXQgb2YgYXR0cmlidXRlcyB0aGF0IGFyZSB1 bmlxdWUgZm9yIGVhY2ggaWRlbnRpdHkgcmVnaXN0ZXJlZC4NCj4NCj5TZWNvbmQgbGV2ZWwgaXMg c29sZSBjbGFpbWFudCAtIHRoaXMgaXMgYSBjaGVjayB0aGF0IG9ubHkgb25lIGVudGl0eSBoYXMg Y2xhaW1lZCBhIHBhcnRpY3VsYXIgc2V0IG9mIGF0dHJpYnV0ZXMuIEF0IHRoZSBoaWdoZXIgbGV2 ZWxzIG9mIGlkZW50aXR5IHByb29maW5nIHdoZXJlIGF1dGhvcml0YXRpdmUgc291cmNlcyBhcmUg dXNlZCBpdCBtYXkgYmUgcG9zc2libGUgdG8gYWNoaWV2ZSB0aGlzLiBUaGlzIGlzIHN1ZmZpY2ll bnQgaW4gbW9zdCBSUHMgY2FzZXMuIEF0IHRoaXMgbGV2ZWwgd2hpbGUgaXQgaXMgcG9zc2libGUg Zm9yIGEgc2luZ2xlIGVudGl0eSB0byBjbGFpbSBtb3JlIHRoYW4gb25lIGlkZW50aXR5LCB0aGV5 IGRvIHNvIGF0IHRoZSByaXNrIG9mIGNhdXNpbmcgYSBjb3VudGVyLWZyYXVkIGZsYWcgc2hvdWxk IHRoZSByZWFsIG93bmVyIChvciBhbnkgb3RoZXIgcGFydHkpIGFsc28gYXR0ZW1wdCB0byBjbGFp bSB0aGUgaWRlbnRpdHkuDQo+DQo+VGhlIGZpbmFsIGxldmVsIGlzIG9uZSBhbmQgb25seSBvbmUg LSBUaGlzIGlzIGEgY2hlY2sgLSB1c3VhbGx5IGJpb21ldHJpYyAtIHRoYXQgYW4gZW50aXR5IGhh cyBvbmx5IG9uZSBjbGFpbSBpbiB0aGUgY29udGV4dC4gVGhpcyBpcyB1c3VhbGx5IG9ubHkgcmVz ZXJ2ZWQgZm9yIHRoZSBoaWdoZXN0IGxldmVsIG9mIGlkZW50aXR5IGFuZCB3b3VsZCBhbHNvIHJl cXVpcmUgZXF1YWxseSBoaWdoIGxldmVscyBvZiBjcmVkZW50aWFsIGFuZCBjcmVkZW50aWFsIGlz c3VhbmNlIHByb2Nlc3Nlcy4NCj4NCj5BcyB0byBob3cgdGhpcyByZWxhdGVzIHRvIFZvVCAtIA0K PlRoZSBmaXJzdCBzaG91bGQgYmUgaW5uYXRlbHkgYnVpbHQgaW50byBhbGwgbGV2ZWxzIG9mIFAg LSBpdCBpcyB0aGUgc29sZSByZXF1aXJlbWVudCBvZiBhbGwgbGV2ZWxzDQo+DQo+VGhlIHNlY29u ZCBjb3VsZCBiZSBidWlsdCBpbnRvIFAzIGlmIHRoZSB3b3JkaW5nIHdhcyBhbWVuZGVkIHNsaWdo dGx5Lg0KPg0KPlRoZSBsYXN0IGl0ZW0gb25seSBpcyBzdWJzdGFudGl2ZWx5IG1pc3NpbmcgYW5k IHRvIGRhdGUgKGluIHRoZSBjb252ZXJzYXRpb25zIEkgaGF2ZSBiZWVuIGhhdmluZyBlbHNld2hl cmUpIHRoZXJlIGhhcyBiZWVuIGluc3VmZmljaWVudCBhcHBldGl0ZSB0byBhZGQgaXQgYXMgYW4g ZXhwbGljaXQgcmVxdWlyZW1lbnQuIA0KPg0KPlNob3VsZCB3ZSBoYXZlIGEgUFU/IE1heWJlLCBi dXQgc3RlZXIgY2xlYXIgb2YgdGhlIHRlcm0gJ3VuaXF1ZScNCj5JZiB3ZSBkbywgaW4gbXkgbWlu ZCBpdCB3b3VsZCBvbmx5IGhhdmUgdHdvIHZhbHVlcyAtIFA/MCAtIENsYWltcyBwZXIgZW50aXR5 IG5vdCBjaGVja2VkLCBQPzEgLSBDbGFpbXMgcGVyIGVudGl0eSByZXN0cmljdGVkIHRvIG9uZS4N Cj4NCj5Kb2FubmUNCj4NCj4NCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IFJv bGYgQnJ1Z2dlciBbbWFpbHRvOnJvbGYuYnJ1Z2dlckBzd2l0Y2guY2hdIA0KPlNlbnQ6IEZyaWRh eSwgMTEgTWFyY2ggMjAxNiA1OjUxIGEubS4NCj5Ubzogdm90QGlldGYub3JnDQo+U3ViamVjdDog W1ZvVF0gSG93IHRvIGV4cHJlc3MgZHVwbGljYXRlIGNoZWNrcyB3aXRoIFZvVD8NCj4NCj5IaSBh bGwsDQo+DQo+SSdtIG5ldyB0byB0aGlzIGxpc3QgYW5kIEkgaG9wZSBteSBxdWVzdGlvbiBpcyBu b3QgdG90YWxseSBpcnJlbGV2YW50IGhlcmUuDQo+DQo+V2UgaGF2ZSBwbGVudHkgb2YgdXNlIGNh c2VzIHdoZXJlIFJQcyBuZWVkIHRvIGhhdmUgY29uZmlkZW5jZSwgdGhhdCBhIHBlcnNvbiBkb2Vz IG5vdCBoYXZlIG11bHRpcGxlIGlkZW50aXRpZXMgaW4gb25lIElkUC4gSSBkb24ndCBzZWUgaG93 IHRoaXMgYXNwZWN0IG9mIGlkZW50aXR5IHF1YWxpdHkgY2FuIGJlIGV4cHJlc3NlZCwgYW5kIEkg YmVsaWV2ZSBpdCBpcyBwcmV0dHkgb3J0aG9nb25hbCB0byB0aGUgUCwgQywgTSBhbmQgQSBkaW1l bnNpb25zIHRoYXQgYXJlIGN1cnJlbnRseSBzcGVjaWZpZWQgaW4gdGhlIFZvVCBkcmFmdC4NCj4N Cj5XZSBjb3VsZCBpbWFnaW5lIG11bHRpcGxlIHdheXMgdG8gZ3JhZHVhbGx5IHByb3ZlIHRoYXQg YW4gaWRlbnRpdHkgaGFzIGJlZW4gY2hlY2tlZCBhZ2FpbnN0IGR1cGxpY2F0ZXMuIFRoZSBtb3N0 IHN0cmFpZ2h0Zm9yd2FyZCBhcHByb2FjaCB3b3VsZCBiZSB0byBtYWtlIHN1cmUgdGhhdCB1bmlx dWUgcGVyc29uYWwgYXR0cmlidXRlcyBhcmUgdXNlZCBvbmx5IG9uY2Ugd2l0aGluIG9uZSBJZFAg b3IgYW4gSWRQIGZlZGVyYXRpb24sIGxpa2UNCj4tIGVtYWlsIGFkZHJlc3MoZXMpDQo+LSBtb2Jp bGUgcGhvbmUgbnVtYmVyDQo+LSBob21lIHBvc3RhbCBhZGRyZXNzDQo+LSBzb2NpYWwgc2VjdXJp dHkgbnVtYmVyDQo+LSBJRCAvIHBhc3Nwb3J0IG51bWJlcg0KPi0gdGhlIGNvbWJpbmF0aW9uIG9m IG5hbWUgYW5kIGJpcnRoIGRhdGUNCj4tIGV0Yy4NCj4NCj5Xb3VsZCBpdCBtYWtlIHNlbnNlIHRv IGV4cHJlc3MgdGhpcyBpbiBWb1Q/DQo+DQo+YmVzdCByZWdhcmRzDQo+DQo+Um9sZg0KPg0KPg0K Pi0tDQo+U1dJVENIDQo+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj5Sb2xmIEJydWdnZXIs IHByb2plY3QgU3dpc3MgZWR1LUlEDQo+V2VyZHN0cmFzc2UgMiwgUC5PLiBCb3gsIDgwMjEgWnVy aWNoLCBTd2l0emVybGFuZCBwaG9uZSArNDEgNDQgMjY4IDE1IDE1LCBkaXJlY3QgKzQxIDQ0IDI2 OCAxNSA4OSByb2xmLmJydWdnZXJAc3dpdGNoLmNoLCBodHRwOi8vd3d3LnN3aXRjaC5jaA0KPg0K Pg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+dm90 IG1haWxpbmcgbGlzdA0KPnZvdEBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vdm90DQo= From nobody Thu Mar 17 03:34:55 2016 Return-Path: X-Original-To: vot@ietfa.amsl.com Delivered-To: vot@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D7F312D711 for ; Thu, 17 Mar 2016 03:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDgemcG1qkt2 for ; Thu, 17 Mar 2016 03:34:50 -0700 (PDT) Received: from iberico.switch.ch (iberico.switch.ch [IPv6:2001:620:0:1002::27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14D1112D636 for ; Thu, 17 Mar 2016 03:34:49 -0700 (PDT) Received: from surlej.switch.ch (surlej.switch.ch [IPv6:2001:620:0:1001::69]) by iberico.switch.ch (8.14.4/8.14.4/Debian-4) with ESMTP id u2HAYkXo014970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 17 Mar 2016 11:34:47 +0100 Received: from macrb.switch.ch ([2001:620:0:44:426c:8fff:fe37:cd48]) by surlej.switch.ch with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1agVGP-0007Yf-U4 for vot@ietf.org; Thu, 17 Mar 2016 11:34:45 +0100 To: vot@ietf.org References: <56E1A5F8.3090201@switch.ch> <569AD906E45DB44A8AFF11D61F5DA7910155C7D4F2@AKLDRMBX03.dia.govt.nz> From: Rolf Brugger Message-ID: <56EA8845.3040503@switch.ch> Date: Thu, 17 Mar 2016 11:34:45 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <569AD906E45DB44A8AFF11D61F5DA7910155C7D4F2@AKLDRMBX03.dia.govt.nz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CanIt-Geo: ip=2001:620:0:1001::69; country=CH; region=Zurich; city=Zurich; latitude=47.3720; longitude=8.5413; http://maps.google.com/maps?q=47.3720,8.5413&z=6 X-CanItPRO-Stream: switch-ch:outbound (inherits from switch-ch:default, base:default) X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: Subject: Re: [VoT] How to express duplicate checks with VoT? X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 10:34:54 -0000 Hi all, Thanks for all your responses and ideas. We have discussed your inputs in our project team (which is why it took me some time to respond) I was wondering what actually the differences are between the three levels of uniqueness described by Joanne. In each of the three levels a set of attributes is used to determine if an identity is unique within a population of identities. The difference is 1) what exact set of attributes is used in each level and 2) the vetting level of the attributes. Right? A concrete example might be First level: - attributes: Name, email, phone number - vetting level: P1 Second level: - attributes: Name, email, phone number, social security number - vetting level: P2 Third level: - attributes: finger print or retina scan - vetting level: P3 The appropriate set of attributes to be used in each level is certainly context-specific. As Eric points out it will be difficult to define and agree on a generic definition of the scope. Maybe it's time to describe our use cases here. In the IdM service we are planning individuals self-register their identities. With such an identity, individuals can register for studies at a university. But one individual may only register once at the same university. Another case is a user's library account that was blocked because of violations of the library's usage terms. Such a user should not be able to just create a new account to use the library services again. With Justin's suggestion of a Pu category, the requirements in our use cases could be expressed as P1.Pu or P2.Pu. The semantics of "P2.Pu" would then be: Proofed unique based on an attribute set with the vetting level P2. cheers Rolf On 11.03.16 02:56, Joanne Knight wrote: > Hi All > > There are three aspect or levels when looking at uniqueness to be > considered. > > First level is that the identity is unique - that is, within a > context there is a set of attributes that are unique for each > identity registered. > > Second level is sole claimant - this is a check that only one entity > has claimed a particular set of attributes. At the higher levels of > identity proofing where authoritative sources are used it may be > possible to achieve this. This is sufficient in most RPs cases. At > this level while it is possible for a single entity to claim more > than one identity, they do so at the risk of causing a counter-fraud > flag should the real owner (or any other party) also attempt to claim > the identity. > > The final level is one and only one - This is a check - usually > biometric - that an entity has only one claim in the context. This is > usually only reserved for the highest level of identity and would > also require equally high levels of credential and credential > issuance processes. > > As to how this relates to VoT - The first should be innately built > into all levels of P - it is the sole requirement of all levels > > The second could be built into P3 if the wording was amended > slightly. > > The last item only is substantively missing and to date (in the > conversations I have been having elsewhere) there has been > insufficient appetite to add it as an explicit requirement. > > Should we have a PU? Maybe, but steer clear of the term 'unique' If > we do, in my mind it would only have two values - P?0 - Claims per > entity not checked, P?1 - Claims per entity restricted to one. > > Joanne > > > -----Original Message----- From: Rolf Brugger > [mailto:rolf.brugger@switch.ch] Sent: Friday, 11 March 2016 5:51 > a.m. To: vot@ietf.org Subject: [VoT] How to express duplicate checks > with VoT? > > Hi all, > > I'm new to this list and I hope my question is not totally irrelevant > here. > > We have plenty of use cases where RPs need to have confidence, that a > person does not have multiple identities in one IdP. I don't see how > this aspect of identity quality can be expressed, and I believe it is > pretty orthogonal to the P, C, M and A dimensions that are currently > specified in the VoT draft. > > We could imagine multiple ways to gradually prove that an identity > has been checked against duplicates. The most straightforward > approach would be to make sure that unique personal attributes are > used only once within one IdP or an IdP federation, like - email > address(es) - mobile phone number - home postal address - social > security number - ID / passport number - the combination of name and > birth date - etc. > > Would it make sense to express this in VoT? > > best regards > > Rolf > > > -- SWITCH -------------------------- Rolf Brugger, project Swiss > edu-ID Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland phone +41 44 > 268 15 15, direct +41 44 268 15 89 rolf.brugger@switch.ch, > http://www.switch.ch > > > _______________________________________________ vot mailing list > vot@ietf.org https://www.ietf.org/mailman/listinfo/vot > -- SWITCH -------------------------- Rolf Brugger, project Swiss edu-ID Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland phone +41 44 268 15 15, direct +41 44 268 15 89 rolf.brugger@switch.ch, http://www.switch.ch From nobody Thu Mar 17 14:49:32 2016 Return-Path: X-Original-To: vot@ietfa.amsl.com Delivered-To: vot@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E896712DAAB for ; Thu, 17 Mar 2016 14:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nz.smxemail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ePvZKiCW24G2 for ; Thu, 17 Mar 2016 14:49:28 -0700 (PDT) Received: from out1102.nz.smxemail.com (out1102.nz.smxemail.com [203.84.134.33]) (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 C6D8812DCB0 for ; Thu, 17 Mar 2016 14:49:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=nz.smxemail.com; s=alpha; c=relaxed/relaxed; q=dns/txt; i=@nz.smxemail.com; t=1458251365; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc; bh=i4gU4oMpgmANoxZklCWPgoBgHBIHnBmEx3GSwgwfn4M=; b=cQHfiem7rU+ulOrGNckfZby5Q4Qh8YtDbpae9OWqQyyXD13lLTxxRj81JYk5GZ3N wuFOwpd0xZjAEXdLXrWtn1+1llM3pbC1/R3VOioe3d+CbOCvsJlQlYYV+uKU6aQT swVBd5Vglza0MP+HGrfsA9ptbyLXCtPi7o8vynpQFg8=; Received: from smtp.dia.govt.nz ([131.203.48.73]) by omr.nz.smxemail.com with ESMTP (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) id 56EB2664-E8A7229D@mta1103.omr; Thu, 17 Mar 2016 21:49:25 +0000 Received: from 161-65-142-21.ip.fx.net.nz (EHLO WLGPRDMM01.dia.govt.nz) ([161.65.142.21]) by s111-0006-lnv01 (Liverton Technology Group - SmartGate) with ESMTP ID 1526770832; Fri, 18 Mar 2016 10:49:22 +1300 (NZDT) Received: from AklDrCas02.dia.govt.nz (Not Verified[10.104.240.112]) by WLGPRDMM01.dia.govt.nz with MailMarshal (v7, 1, 1, 5205) (using TLS: SSLv23) id ; Fri, 18 Mar 2016 10:49:22 +1300 Received: from AKLDRMBX03.dia.govt.nz ([fe80::d1c1:15a7:3e85:ac71]) by AklDrCas02.dia.govt.nz ([::1]) with mapi id 14.03.0279.002; Fri, 18 Mar 2016 10:49:21 +1300 From: Joanne Knight To: 'Rolf Brugger' , "vot@ietf.org" Thread-Topic: [VoT] How to express duplicate checks with VoT? Thread-Index: AQHRewefr30T8sn2a0aikcEmelKPBJ9eF5ww Date: Thu, 17 Mar 2016 21:49:20 +0000 Message-ID: <569AD906E45DB44A8AFF11D61F5DA7910155C80A34@AKLDRMBX03.dia.govt.nz> References: <56E1A5F8.3090201@switch.ch> <569AD906E45DB44A8AFF11D61F5DA7910155C7D4F2@AKLDRMBX03.dia.govt.nz> <56EA8845.3040503@switch.ch> In-Reply-To: <56EA8845.3040503@switch.ch> Accept-Language: en-NZ, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailadviser: Confirmation not required x-originating-ip: [10.220.229.74] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [VoT] How to express duplicate checks with VoT? X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 21:49:31 -0000 The short answer to your question - No. Your use case is silent on the level of vetting required (how real does the= identity have to be). You can have any level of identity and still collect= a biometric for the purposes of one and only one uniqueness. I would pose = however that it is very unusual for one and only one assurance to be requir= ed without some other driver requiring an elevated level of realness.=20 In your use case I would suggest that there is also a requirement that a qu= alification is issued to=20 a) the person carrying out the study and=20 b) an identity of such rigour that their (or the university's) eligibility = for public funding can be established and=20 c) an identity that is going to be tested by future employers. Therefore you are probably looking at P2 or P3 depending on the level/type = of qualification. (I might want P3 if the qualification is for brain surgeo= n or commercial pilot). As one and only one is really only able to be achieved through the use of a= biometric, we now have to consider 'acceptability'. Does the collection of a biometric (and all that it entails - cost, privacy= , security, user acceptance etc.) outweigh the impact caused by a duplicate= entity in the system? In other words, do you really need one and only one (the 3rd level of uniqu= eness) or could sufficient singularity be gained from leveraging the social= security number's uniqueness and an equivalent level of validation and own= ership test (the 2nd level of uniqueness) i.e. no Pu? We must remember the mutual exclusivity between attributes collected, vetti= ng under taken and level of uniqueness.=20 Happy to discuss further if this makes no sense. Cheers -----Original Message----- From: Rolf Brugger [mailto:rolf.brugger@switch.ch]=20 Sent: Thursday, 17 March 2016 11:35 p.m. To: vot@ietf.org Subject: Re: [VoT] How to express duplicate checks with VoT? Hi all, Thanks for all your responses and ideas. We have discussed your inputs in o= ur project team (which is why it took me some time to respond) I was wondering what actually the differences are between the three levels = of uniqueness described by Joanne. In each of the three levels a set of att= ributes is used to determine if an identity is unique within a population o= f identities. The difference is 1) what exact set of attributes is used in = each level and 2) the vetting level of the attributes. Right? A concrete example might be First level: - attributes: Name, email, phone number - vetting level: P1 Second level: - attributes: Name, email, phone number, social security number - vetting level: P2 Third level: - attributes: finger print or retina scan - vetting level: P3 The appropriate set of attributes to be used in each level is certainly con= text-specific. As Eric points out it will be difficult to define and agree = on a generic definition of the scope. Maybe it's time to describe our use cases here. In the IdM service we are p= lanning individuals self-register their identities. With such an identity, = individuals can register for studies at a university. But one individual ma= y only register once at the same university. Another case is a user's libra= ry account that was blocked because of violations of the library's usage te= rms. Such a user should not be able to just create a new account to use the= library services again. With Justin's suggestion of a Pu category, the requirements in our use case= s could be expressed as P1.Pu or P2.Pu. The semantics of "P2.Pu"=20 would then be: Proofed unique based on an attribute set with the vetting le= vel P2. cheers Rolf On 11.03.16 02:56, Joanne Knight wrote: > Hi All > > There are three aspect or levels when looking at uniqueness to be=20 > considered. > > First level is that the identity is unique - that is, within a context=20 > there is a set of attributes that are unique for each identity=20 > registered. > > Second level is sole claimant - this is a check that only one entity=20 > has claimed a particular set of attributes. At the higher levels of=20 > identity proofing where authoritative sources are used it may be=20 > possible to achieve this. This is sufficient in most RPs cases. At=20 > this level while it is possible for a single entity to claim more than=20 > one identity, they do so at the risk of causing a counter-fraud flag=20 > should the real owner (or any other party) also attempt to claim the=20 > identity. > > The final level is one and only one - This is a check - usually=20 > biometric - that an entity has only one claim in the context. This is=20 > usually only reserved for the highest level of identity and would also=20 > require equally high levels of credential and credential issuance=20 > processes. > > As to how this relates to VoT - The first should be innately built=20 > into all levels of P - it is the sole requirement of all levels > > The second could be built into P3 if the wording was amended slightly. > > The last item only is substantively missing and to date (in the=20 > conversations I have been having elsewhere) there has been=20 > insufficient appetite to add it as an explicit requirement. > > Should we have a PU? Maybe, but steer clear of the term 'unique' If we=20 > do, in my mind it would only have two values - P?0 - Claims per entity=20 > not checked, P?1 - Claims per entity restricted to one. > > Joanne > > > -----Original Message----- From: Rolf Brugger=20 > [mailto:rolf.brugger@switch.ch] Sent: Friday, 11 March 2016 5:51 a.m.=20 > To: vot@ietf.org Subject: [VoT] How to express duplicate checks with=20 > VoT? > > Hi all, > > I'm new to this list and I hope my question is not totally irrelevant=20 > here. > > We have plenty of use cases where RPs need to have confidence, that a=20 > person does not have multiple identities in one IdP. I don't see how=20 > this aspect of identity quality can be expressed, and I believe it is=20 > pretty orthogonal to the P, C, M and A dimensions that are currently=20 > specified in the VoT draft. > > We could imagine multiple ways to gradually prove that an identity has=20 > been checked against duplicates. The most straightforward approach=20 > would be to make sure that unique personal attributes are used only=20 > once within one IdP or an IdP federation, like - email > address(es) - mobile phone number - home postal address - social=20 > security number - ID / passport number - the combination of name and=20 > birth date - etc. > > Would it make sense to express this in VoT? > > best regards > > Rolf > > > -- SWITCH -------------------------- Rolf Brugger, project Swiss=20 > edu-ID Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland phone +41 44 > 268 15 15, direct +41 44 268 15 89 rolf.brugger@switch.ch,=20 > http://www.switch.ch > > > _______________________________________________ vot mailing list=20 > vot@ietf.org https://www.ietf.org/mailman/listinfo/vot > -- SWITCH -------------------------- Rolf Brugger, project Swiss edu-ID Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland phone +41 44 268 15 15, d= irect +41 44 268 15 89 rolf.brugger@switch.ch, http://www.switch.ch From nobody Fri Mar 18 06:19:53 2016 Return-Path: X-Original-To: vot@ietfa.amsl.com Delivered-To: vot@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45DE312D6F3 for ; Fri, 18 Mar 2016 06:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nu-d.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PlWRHfaJ1aeB for ; Fri, 18 Mar 2016 06:19:45 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::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 50CA612D51A for ; Fri, 18 Mar 2016 06:19:45 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id l68so68566249wml.0 for ; Fri, 18 Mar 2016 06:19:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nu-d.com; s=nud; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+P7B5O3qp4DGXI+s+fqCTu6HjR8Sr49CYCROxV49UrA=; b=DmIYto2nlrC/1VjF5QJcfpIecP9URHcJSx+tHHK55j3bzXRypEtOCt/0RYbHoRTHq2 IY4+B3YkhHwz0/P206PpqTbHUskLgxviBvz85h8HOpb5t/I+1Pkc5BkDT/OaKq3lwUbf C5FrGluzXCkcBoKtfqRTjUClhCG5Wfn3q2zSg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+P7B5O3qp4DGXI+s+fqCTu6HjR8Sr49CYCROxV49UrA=; b=RJvW3DNeh2Cbqh/NGRKFNLB3uYt1iwZ25wO5aisDew8yXmlAf79+pGFGvY43saNweM E7KJkOH3PnwR3XOJIG410PXHqhK3slFjBHfFvrKNQdg6FK91F2X8cCGfKboB2SRQouQa LJsWJNxO/J24KA3cck9Hj9tuua2n5MYOKd5YOS9uhFd77e3AUyIz/YEAkpGrFi4uEUpv sL+vbakIq8lPGQRIfyiJR62KrOIpT0JQkLZ5/z/tg8LJfz2gxmgeitMdcsYKm5m5oQj+ BbHNWhJDWB8neCdQTF6oBV//zKqrVzl7BZG9Kneqv7hkXufJbmoLqhZpZqgbgjvYALHx 3TBQ== X-Gm-Message-State: AD7BkJIM2qxId6lD1Mfv1/BvTGmVzngtBAwOET2YUanw3FnQSDgaVRFnFJSFl5ta/FlVOQ9GlQOroVFWZpqoHZ9w X-Received: by 10.28.111.12 with SMTP id k12mr16582465wmc.35.1458307183601; Fri, 18 Mar 2016 06:19:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.121.7 with HTTP; Fri, 18 Mar 2016 06:19:23 -0700 (PDT) In-Reply-To: <569AD906E45DB44A8AFF11D61F5DA7910155C80A34@AKLDRMBX03.dia.govt.nz> References: <56E1A5F8.3090201@switch.ch> <569AD906E45DB44A8AFF11D61F5DA7910155C7D4F2@AKLDRMBX03.dia.govt.nz> <56EA8845.3040503@switch.ch> <569AD906E45DB44A8AFF11D61F5DA7910155C80A34@AKLDRMBX03.dia.govt.nz> From: Julian White Date: Fri, 18 Mar 2016 13:19:23 +0000 Message-ID: To: Joanne Knight Content-Type: multipart/alternative; boundary=001a1146b240a70b9e052e5299a5 Archived-At: Cc: Rolf Brugger , "vot@ietf.org" Subject: Re: [VoT] How to express duplicate checks with VoT? X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2016 13:19:50 -0000 --001a1146b240a70b9e052e5299a5 Content-Type: text/plain; charset=UTF-8 I would say, as I have in the ISO 29003 discussions, that uniqueness is in fact irrelevant in terms of the level of proofing. I see no need to know whether that set of attributes is proven to be unique by the proofing provider. Uniqueness is highly dependent on the context, which raises all sorts of problems if you have an identity federation (how do I know its unique across the federation? If, as an RP, I can can cope with non-uniqueness across the federation then non-uniqueness within the proofing provider is also not a problem). In my view it is for the RP, or identity federation scheme, to decide which attributes are required in their context. They select sufficient attributes that give them uniqueness (in their context) if that is required, e.g. SSN for some services (though I would advise against it!). The purpose of the proofing process is to express to what level of confidence that those attributes are true and belong to the person presenting them, be they name, address, dob, email address, SSN etc. In my dealings with RPs they are confused about this and ask for "uniqueness", this is usually followed up with "because we can't let people register multiple identities". There is a lack of understanding that, assuming the proofing process is working correctly, it doesn't matter how many times you enrol you are proven to be the same person each time; i.e. multiple enrolments lead to the identification of the same person being bound to the same attributes. Therefore it isn't actually a problem in terms of uniqueness. More often than not the ask for uniqueness is really an expression of how well the system defends itself against impostors (different people registering for the same attributes) which is actually the point of the different levels of proofing (the higher the levels of proofing the harder this should become). Demanding uniqueness doesn't actually fix the impostor problem, you just introduce a time trial to the process; the first person to get bound to those attributes locks out other people; if the first person to claim them was the impostor you've now locked out the genuine person - they now have a hell of time unpicking a mess not of their making. If the system defends against impostors properly at the higher levels then the uniqueness adds little value since I can only bind those attributes to the correct person anyway. The thing that may need to be unique is the account/record at the RP, and its the RP's responsibility to manage that. This is a problem they have regardless of whether the proofing provider tells them its unique or not because they often have multiple on-line and offline channels that deal with their customers, this forces them to understand how to match different representations of the identity to the same account which tends to work across channel and within the same channel. So in summary it doesn't drive any real value in the proofing provider to do this, its just a cost of effort for little gain that the RP is going to repeat regardless if they care about uniqueness. Regards, Julian. On 17 March 2016 at 21:49, Joanne Knight wrote: > The short answer to your question - No. > > Your use case is silent on the level of vetting required (how real does > the identity have to be). You can have any level of identity and still > collect a biometric for the purposes of one and only one uniqueness. I > would pose however that it is very unusual for one and only one assurance > to be required without some other driver requiring an elevated level of > realness. > > In your use case I would suggest that there is also a requirement that a > qualification is issued to > a) the person carrying out the study and > b) an identity of such rigour that their (or the university's) eligibility > for public funding can be established and > c) an identity that is going to be tested by future employers. > > Therefore you are probably looking at P2 or P3 depending on the level/type > of qualification. (I might want P3 if the qualification is for brain > surgeon or commercial pilot). > > As one and only one is really only able to be achieved through the use of > a biometric, we now have to consider 'acceptability'. > Does the collection of a biometric (and all that it entails - cost, > privacy, security, user acceptance etc.) outweigh the impact caused by a > duplicate entity in the system? > In other words, do you really need one and only one (the 3rd level of > uniqueness) or could sufficient singularity be gained from leveraging the > social security number's uniqueness and an equivalent level of validation > and ownership test (the 2nd level of uniqueness) i.e. no Pu? > > We must remember the mutual exclusivity between attributes collected, > vetting under taken and level of uniqueness. > > Happy to discuss further if this makes no sense. > > Cheers > > > > -----Original Message----- > From: Rolf Brugger [mailto:rolf.brugger@switch.ch] > Sent: Thursday, 17 March 2016 11:35 p.m. > To: vot@ietf.org > Subject: Re: [VoT] How to express duplicate checks with VoT? > > Hi all, > > Thanks for all your responses and ideas. We have discussed your inputs in > our project team (which is why it took me some time to respond) > > I was wondering what actually the differences are between the three levels > of uniqueness described by Joanne. In each of the three levels a set of > attributes is used to determine if an identity is unique within a > population of identities. The difference is 1) what exact set of attributes > is used in each level and 2) the vetting level of the attributes. Right? > > A concrete example might be > > First level: > - attributes: Name, email, phone number > - vetting level: P1 > > Second level: > - attributes: Name, email, phone number, social security number > - vetting level: P2 > > Third level: > - attributes: finger print or retina scan > - vetting level: P3 > > The appropriate set of attributes to be used in each level is certainly > context-specific. As Eric points out it will be difficult to define and > agree on a generic definition of the scope. > > Maybe it's time to describe our use cases here. In the IdM service we are > planning individuals self-register their identities. With such an identity, > individuals can register for studies at a university. But one individual > may only register once at the same university. Another case is a user's > library account that was blocked because of violations of the library's > usage terms. Such a user should not be able to just create a new account to > use the library services again. > > With Justin's suggestion of a Pu category, the requirements in our use > cases could be expressed as P1.Pu or P2.Pu. The semantics of "P2.Pu" > would then be: Proofed unique based on an attribute set with the vetting > level P2. > > cheers > > Rolf > > > > On 11.03.16 02:56, Joanne Knight wrote: > > Hi All > > > > There are three aspect or levels when looking at uniqueness to be > > considered. > > > > First level is that the identity is unique - that is, within a context > > there is a set of attributes that are unique for each identity > > registered. > > > > Second level is sole claimant - this is a check that only one entity > > has claimed a particular set of attributes. At the higher levels of > > identity proofing where authoritative sources are used it may be > > possible to achieve this. This is sufficient in most RPs cases. At > > this level while it is possible for a single entity to claim more than > > one identity, they do so at the risk of causing a counter-fraud flag > > should the real owner (or any other party) also attempt to claim the > > identity. > > > > The final level is one and only one - This is a check - usually > > biometric - that an entity has only one claim in the context. This is > > usually only reserved for the highest level of identity and would also > > require equally high levels of credential and credential issuance > > processes. > > > > As to how this relates to VoT - The first should be innately built > > into all levels of P - it is the sole requirement of all levels > > > > The second could be built into P3 if the wording was amended slightly. > > > > The last item only is substantively missing and to date (in the > > conversations I have been having elsewhere) there has been > > insufficient appetite to add it as an explicit requirement. > > > > Should we have a PU? Maybe, but steer clear of the term 'unique' If we > > do, in my mind it would only have two values - P?0 - Claims per entity > > not checked, P?1 - Claims per entity restricted to one. > > > > Joanne > > > > > > -----Original Message----- From: Rolf Brugger > > [mailto:rolf.brugger@switch.ch] Sent: Friday, 11 March 2016 5:51 a.m. > > To: vot@ietf.org Subject: [VoT] How to express duplicate checks with > > VoT? > > > > Hi all, > > > > I'm new to this list and I hope my question is not totally irrelevant > > here. > > > > We have plenty of use cases where RPs need to have confidence, that a > > person does not have multiple identities in one IdP. I don't see how > > this aspect of identity quality can be expressed, and I believe it is > > pretty orthogonal to the P, C, M and A dimensions that are currently > > specified in the VoT draft. > > > > We could imagine multiple ways to gradually prove that an identity has > > been checked against duplicates. The most straightforward approach > > would be to make sure that unique personal attributes are used only > > once within one IdP or an IdP federation, like - email > > address(es) - mobile phone number - home postal address - social > > security number - ID / passport number - the combination of name and > > birth date - etc. > > > > Would it make sense to express this in VoT? > > > > best regards > > > > Rolf > > > > > > -- SWITCH -------------------------- Rolf Brugger, project Swiss > > edu-ID Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland phone +41 44 > > 268 15 15, direct +41 44 268 15 89 rolf.brugger@switch.ch, > > http://www.switch.ch > > > > > > _______________________________________________ vot mailing list > > vot@ietf.org https://www.ietf.org/mailman/listinfo/vot > > > > -- > SWITCH > -------------------------- > Rolf Brugger, project Swiss edu-ID > Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland phone +41 44 268 15 15, > direct +41 44 268 15 89 rolf.brugger@switch.ch, http://www.switch.ch > > > _______________________________________________ > vot mailing list > vot@ietf.org > https://www.ietf.org/mailman/listinfo/vot > --001a1146b240a70b9e052e5299a5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I would say, as I have in the ISO 29003 dis= cussions, that uniqueness is in fact irrelevant in terms of the level of pr= oofing. I see no need to know whether that set of attributes is proven to b= e unique by the proofing provider. Uniqueness is highly dependent on the co= ntext, which raises all sorts of problems if you have an identity federatio= n (how do I know its unique across the federation? If, as an RP, I can can = cope with non-uniqueness across the federation then=C2=A0non-uniqueness=C2= =A0within the proofing provider is also not a problem).

= In my view it is for the RP, or identity federation scheme, to decide which= attributes are required in their context. They select sufficient attribute= s that give them uniqueness (in their context) if that is required, e.g. SS= N for some services (though I would advise against it!). The purpose of the= proofing process is to express to what level of confidence that those attr= ibutes are true and belong to the person presenting them, be they name, add= ress, dob, email address, SSN etc.

In my dealings = with RPs they are confused about this and ask for "uniqueness", t= his is usually followed up with "because we can't let people regis= ter multiple identities". There is a lack of understanding that, assum= ing the proofing process is working correctly, it doesn't matter how ma= ny times you enrol you are proven to be the same person each time; i.e. mul= tiple enrolments lead to the identification of the same person being bound = to the same attributes. Therefore it isn't actually a problem in terms = of uniqueness.=C2=A0

More often than not the ask f= or uniqueness is really an expression of how well the system defends itself= against impostors (different people registering for the same attributes) w= hich is actually the point of the different levels of proofing (the higher = the levels of proofing the harder this should become). Demanding uniqueness= doesn't actually fix the impostor problem, you just introduce a time t= rial to the process; the first person to get bound to those attributes lock= s out other people; if the first person to claim them was the impostor you&= #39;ve now locked out the genuine person - they now have a hell of time unp= icking a mess not of their making. If the system defends against impostors = properly at the higher levels then the uniqueness adds little value since I= can only bind those attributes to the correct person anyway.
The thing that may need to be unique is the account/record at t= he RP, and its the RP's responsibility to manage that. This is a proble= m they have regardless of whether the proofing provider tells them its uniq= ue or not because they often have multiple on-line and offline channels tha= t deal with their customers, this forces them to understand how to match di= fferent representations of the identity to the same account which tends to = work across channel and within the same channel.

S= o in summary it doesn't drive any real value in the proofing provider t= o do this, its just a cost of effort for little gain that the RP is going t= o repeat regardless if they care about uniqueness.

Regards,

Julian.




On 17 March 2016 at 21:49, Joanne Knight <Joanne.Knight@dia= .govt.nz> wrote:
The shor= t answer to your question - No.

Your use case is silent on the level of vetting required (how real does the= identity have to be). You can have any level of identity and still collect= a biometric for the purposes of one and only one uniqueness. I would pose = however that it is very unusual for one and only one assurance to be requir= ed without some other driver requiring an elevated level of realness.

In your use case I would suggest that there is also a requirement that a qu= alification is issued to
a) the person carrying out the study and
b) an identity of such rigour that their (or the university's) eligibil= ity for public funding can be established and
c) an identity that is going to be tested by future employers.

Therefore you are probably looking at P2 or P3 depending on the level/type = of qualification. (I might want P3 if the qualification is for brain surgeo= n or commercial pilot).

As one and only one is really only able to be achieved through the use of a= biometric, we now have to consider 'acceptability'.
Does the collection of a biometric (and all that it entails - cost, privacy= , security, user acceptance etc.) outweigh the impact caused by a duplicate= entity in the system?
In other words, do you really need one and only one (the 3rd level of uniqu= eness) or could sufficient singularity be gained from leveraging the social= security number's uniqueness and an equivalent level of validation and= ownership test (the 2nd level of uniqueness) i.e. no Pu?

We must remember the mutual exclusivity between attributes collected, vetti= ng under taken and level of uniqueness.

Happy to discuss further if this makes no sense.

Cheers



-----Original Message-----
From: Rolf Brugger [mailto:rolf.b= rugger@switch.ch]
Sent: Thursday, 17 March 201= 6 11:35 p.m.
To: vot@ietf.org
Subject: Re: [VoT] How to express duplicate checks with VoT?

Hi all,

Thanks for all your responses and ideas. We have discussed your inputs in o= ur project team (which is why it took me some time to respond)

I was wondering what actually the differences are between the three levels = of uniqueness described by Joanne. In each of the three levels a set of att= ributes is used to determine if an identity is unique within a population o= f identities. The difference is 1) what exact set of attributes is used in = each level and 2) the vetting level of the attributes. Right?

A concrete example might be

First level:
- attributes: Name, email, phone number
- vetting level: P1

Second level:
- attributes: Name, email, phone number, social security number
- vetting level: P2

Third level:
- attributes: finger print or retina scan
- vetting level: P3

The appropriate set of attributes to be used in each level is certainly con= text-specific. As Eric points out it will be difficult to define and agree = on a generic definition of the scope.

Maybe it's time to describe our use cases here. In the IdM service we a= re planning individuals self-register their identities. With such an identi= ty, individuals can register for studies at a university. But one individua= l may only register once at the same university. Another case is a user'= ;s library account that was blocked because of violations of the library= 9;s usage terms. Such a user should not be able to just create a new accoun= t to use the library services again.

With Justin's suggestion of a Pu category, the requirements in our use = cases could be expressed as P1.Pu or P2.Pu. The semantics of "P2.Pu&qu= ot;
would then be: Proofed unique based on an attribute set with the vetting le= vel P2.

cheers

Rolf



On 11.03.16 02:56, Joanne Knight wrote:
> Hi All
>
> There are three aspect or levels when looking at uniqueness to be
> considered.
>
> First level is that the identity is unique - that is, within a context=
> there is a set of attributes that are unique for each identity
> registered.
>
> Second level is sole claimant - this is a check that only one entity > has claimed a particular set of attributes. At the higher levels of > identity proofing where authoritative sources are used it may be
> possible to achieve this. This is sufficient in most RPs cases. At
> this level while it is possible for a single entity to claim more than=
> one identity, they do so at the risk of causing a counter-fraud flag > should the real owner (or any other party) also attempt to claim the > identity.
>
> The final level is one and only one - This is a check - usually
> biometric - that an entity has only one claim in the context. This is<= br> > usually only reserved for the highest level of identity and would also=
> require equally high levels of credential and credential issuance
> processes.
>
> As to how this relates to VoT - The first should be innately built
> into all levels of P - it is the sole requirement of all levels
>
> The second could be built into P3 if the wording was amended slightly.=
>
> The last item only is substantively missing and to date (in the
> conversations I have been having elsewhere) there has been
> insufficient appetite to add it as an explicit requirement.
>
> Should we have a PU? Maybe, but steer clear of the term 'unique= 9; If we
> do, in my mind it would only have two values - P?0 - Claims per entity=
> not checked, P?1 - Claims per entity restricted to one.
>
> Joanne
>
>
> -----Original Message----- From: Rolf Brugger
> [mailto:rolf.brugger@switch.= ch] Sent: Friday, 11 March 2016 5:51 a.m.
> To: vot@ietf.org Subject: [VoT] Ho= w to express duplicate checks with
> VoT?
>
> Hi all,
>
> I'm new to this list and I hope my question is not totally irrelev= ant
> here.
>
> We have plenty of use cases where RPs need to have confidence, that a<= br> > person does not have multiple identities in one IdP. I don't see h= ow
> this aspect of identity quality can be expressed, and I believe it is<= br> > pretty orthogonal to the P, C, M and A dimensions that are currently > specified in the VoT draft.
>
> We could imagine multiple ways to gradually prove that an identity has=
> been checked against duplicates. The most straightforward approach
> would be to make sure that unique personal attributes are used only > once within one IdP or an IdP federation, like - email
> address(es) - mobile phone number - home postal address - social
> security number - ID / passport number - the combination of name and > birth date - etc.
>
> Would it make sense to express this in VoT?
>
> best regards
>
> Rolf
>
>
> -- SWITCH -------------------------- Rolf Brugger, project Swiss
> edu-ID Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland phone +41 44<= br> > 268 15 15, direct +41 44 268 15 89 rolf.brugger@switch.ch,
> = http://www.switch.ch
>
>
> _______________________________________________ vot mailing list
> vot@ietf.org https= ://www.ietf.org/mailman/listinfo/vot
>

--
SWITCH
--------------------------
Rolf Brugger, project Swiss edu-ID
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland phone +41 44 268 15 15, direct= +41 44 2= 68 15 89 rolf.brugger@switch.= ch, http://www.switch.ch


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

--001a1146b240a70b9e052e5299a5-- From nobody Fri Mar 18 10:38:58 2016 Return-Path: X-Original-To: vot@ietfa.amsl.com Delivered-To: vot@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E44612D58B for ; Fri, 18 Mar 2016 10:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 8K8e--FYDPxc for ; Fri, 18 Mar 2016 10:38:52 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::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 957DA12D5AC for ; Fri, 18 Mar 2016 10:38:52 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id w20so38983895oia.2 for ; Fri, 18 Mar 2016 10:38:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=OqOVrJZIjBDhNDCw73iBBGWcgnTJwnO3cuCXUdhVAOs=; b=igZWVWESNnodyYbGjXaEGguflvEkeDMOqqgiSjMj99LunYynmYAOCmmyxxV2+fa88f daUx0upI2VcSCn5N1DFeRNxltT2F7SG2uJsDjc0fvwEnlB/8ueFEb+dljw5+g9TVAuIb zQo6jYJQ66PyTmmgPzknEuEX63GSBJ1piZVKuCrY9bGE4i9F49fktLhVN3j1ymuzSyCa wlt1XdfOk3p8zbrlgZt97V/w4BqIJbXsqShkyoWrSCzmv7UAHd4LJ3Ha77I7fT47CKmP SQAHi2YGAAixDprCJkSDhnJ4FEfA41CMQr74HeoHxtFS4HyZ0v+k64NBPWooDG8DMRce PrTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=OqOVrJZIjBDhNDCw73iBBGWcgnTJwnO3cuCXUdhVAOs=; b=YqTfbojjmmJ5M3FW+j/YzHPsCN73PefIKgiac5LvQlTOCJOCjahtoBOQvrpPI5LDBR VZ7h0JfDuYXdJgcKGRE6/UQy7RFqxJOeIEYgGoODG/FVnCj8RJ3mq+Gyog323Z0q/HvE nWM+id+zZ/io3R/kpX7FvMZR/Wu3zvpH5fwHIlNM4yZFV3OPrNvVPOnwYG5toBtAfl6B 70WCcOe91uKFONsAb6Vx6IXXtpyunk8sOhP1VDOg0phY/VJ3/4t60L/yKFQYxO1jSMHr LlvxqC61w0VmK5bDqBZwclPii/Ee8J/jz37DElnZfwbgEVQejUdNuocYRFskQF+9vJ8Z NmRQ== X-Gm-Message-State: AD7BkJLTzI1tSp9ANpa0sVsNm1Wn44Pq+nW0b7mEAHg+JDpoxXoR9CTlu53UKLblBdHtVOoR/glknMlB45v36g== MIME-Version: 1.0 X-Received: by 10.202.92.69 with SMTP id q66mr9369188oib.41.1458322731949; Fri, 18 Mar 2016 10:38:51 -0700 (PDT) Received: by 10.202.200.206 with HTTP; Fri, 18 Mar 2016 10:38:51 -0700 (PDT) In-Reply-To: References: <56E1A5F8.3090201@switch.ch> <569AD906E45DB44A8AFF11D61F5DA7910155C7D4F2@AKLDRMBX03.dia.govt.nz> <56EA8845.3040503@switch.ch> <569AD906E45DB44A8AFF11D61F5DA7910155C80A34@AKLDRMBX03.dia.govt.nz> Date: Fri, 18 Mar 2016 13:38:51 -0400 Message-ID: From: Ken Dagg To: Julian White Content-Type: multipart/alternative; boundary=001a113d608667e362052e563894 Archived-At: Cc: Rolf Brugger , "vot@ietf.org" , Joanne Knight Subject: Re: [VoT] How to express duplicate checks with VoT? X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2016 17:38:57 -0000 --001a113d608667e362052e563894 Content-Type: text/plain; charset=UTF-8 Here, here!!! I have been a lurker on this group for a while but felt compelled to add my to cents to this discussion as it is, I believe, an important point to scoping the discussion as it proceeds. I agree fully that determining the uniqueness of a subject is totally the responsibility of the RP. It is their service delivery and they have to determine what they require in order for them to be assured that they are dealing with a unique subject. I use subject in order to include the IOT in the possible solution. If I'm reading what you say correctly, one of the considerations that a RP might use to determine uniqueness is the level of proofing they require on 1) each of the attributes and 2) the set of attributes. My experience with RPs aligns with Julian's. While RPs usually ask for uniqueness from their digital supplier they do not do so in the manual world. My tactic has been to ask why they are asking for it in the digital world and not in the manual world. The discussion around this question (usually around 1) their perceived benefit and 2) the additional cost versus their perceived benefit) leads to them dropping that requirement from their digital supplier. The "imposter" discussion usually takes the same path. Asking the RP how they deal with imposters in the manual world usually leads to a conclusion that they can employ the same tactics and processes only using digital data. Cost effectiveness is usually a big part of the discussion. This should not be likened to paving the cow path. What usually happens is that they realize that, in the digital world, they might be able to detect an imposter faster because they have faster access to the data they use to detect imposters. In some cases, they may realize improved detection because the proofing data is likely better than they have available in the manual world. It is my opinion that, as their processes evolve in the digital world, they will become faster at imposter detection and resolution. It is also my opinion that prevention of imposters before they happen, like the totally secure system, is, if not impossible, not a cost effective goal to achieve. Ken Dagg On Friday, 18 March 2016, Julian White wrote: > > I would say, as I have in the ISO 29003 discussions, that uniqueness is in > fact irrelevant in terms of the level of proofing. I see no need to know > whether that set of attributes is proven to be unique by the proofing > provider. Uniqueness is highly dependent on the context, which raises all > sorts of problems if you have an identity federation (how do I know its > unique across the federation? If, as an RP, I can can cope with > non-uniqueness across the federation then non-uniqueness within the > proofing provider is also not a problem). > > In my view it is for the RP, or identity federation scheme, to decide > which attributes are required in their context. They select sufficient > attributes that give them uniqueness (in their context) if that is > required, e.g. SSN for some services (though I would advise against it!). > The purpose of the proofing process is to express to what level of > confidence that those attributes are true and belong to the person > presenting them, be they name, address, dob, email address, SSN etc. > > In my dealings with RPs they are confused about this and ask for > "uniqueness", this is usually followed up with "because we can't let people > register multiple identities". There is a lack of understanding that, > assuming the proofing process is working correctly, it doesn't matter how > many times you enrol you are proven to be the same person each time; i.e. > multiple enrolments lead to the identification of the same person being > bound to the same attributes. Therefore it isn't actually a problem in > terms of uniqueness. > > More often than not the ask for uniqueness is really an expression of how > well the system defends itself against impostors (different people > registering for the same attributes) which is actually the point of the > different levels of proofing (the higher the levels of proofing the harder > this should become). Demanding uniqueness doesn't actually fix the impostor > problem, you just introduce a time trial to the process; the first person > to get bound to those attributes locks out other people; if the first > person to claim them was the impostor you've now locked out the genuine > person - they now have a hell of time unpicking a mess not of their making. > If the system defends against impostors properly at the higher levels then > the uniqueness adds little value since I can only bind those attributes to > the correct person anyway. > > The thing that may need to be unique is the account/record at the RP, and > its the RP's responsibility to manage that. This is a problem they have > regardless of whether the proofing provider tells them its unique or not > because they often have multiple on-line and offline channels that deal > with their customers, this forces them to understand how to match different > representations of the identity to the same account which tends to work > across channel and within the same channel. > > So in summary it doesn't drive any real value in the proofing provider to > do this, its just a cost of effort for little gain that the RP is going to > repeat regardless if they care about uniqueness. > > Regards, > > Julian. > > > > > On 17 March 2016 at 21:49, Joanne Knight > wrote: > >> The short answer to your question - No. >> >> Your use case is silent on the level of vetting required (how real does >> the identity have to be). You can have any level of identity and still >> collect a biometric for the purposes of one and only one uniqueness. I >> would pose however that it is very unusual for one and only one assurance >> to be required without some other driver requiring an elevated level of >> realness. >> >> In your use case I would suggest that there is also a requirement that a >> qualification is issued to >> a) the person carrying out the study and >> b) an identity of such rigour that their (or the university's) >> eligibility for public funding can be established and >> c) an identity that is going to be tested by future employers. >> >> Therefore you are probably looking at P2 or P3 depending on the >> level/type of qualification. (I might want P3 if the qualification is for >> brain surgeon or commercial pilot). >> >> As one and only one is really only able to be achieved through the use of >> a biometric, we now have to consider 'acceptability'. >> Does the collection of a biometric (and all that it entails - cost, >> privacy, security, user acceptance etc.) outweigh the impact caused by a >> duplicate entity in the system? >> In other words, do you really need one and only one (the 3rd level of >> uniqueness) or could sufficient singularity be gained from leveraging the >> social security number's uniqueness and an equivalent level of validation >> and ownership test (the 2nd level of uniqueness) i.e. no Pu? >> >> We must remember the mutual exclusivity between attributes collected, >> vetting under taken and level of uniqueness. >> >> Happy to discuss further if this makes no sense. >> >> Cheers >> >> >> >> -----Original Message----- >> From: Rolf Brugger [mailto:rolf.brugger@switch.ch >> ] >> Sent: Thursday, 17 March 2016 11:35 p.m. >> To: vot@ietf.org >> Subject: Re: [VoT] How to express duplicate checks with VoT? >> >> Hi all, >> >> Thanks for all your responses and ideas. We have discussed your inputs in >> our project team (which is why it took me some time to respond) >> >> I was wondering what actually the differences are between the three >> levels of uniqueness described by Joanne. In each of the three levels a set >> of attributes is used to determine if an identity is unique within a >> population of identities. The difference is 1) what exact set of attributes >> is used in each level and 2) the vetting level of the attributes. Right? >> >> A concrete example might be >> >> First level: >> - attributes: Name, email, phone number >> - vetting level: P1 >> >> Second level: >> - attributes: Name, email, phone number, social security number >> - vetting level: P2 >> >> Third level: >> - attributes: finger print or retina scan >> - vetting level: P3 >> >> The appropriate set of attributes to be used in each level is certainly >> context-specific. As Eric points out it will be difficult to define and >> agree on a generic definition of the scope. >> >> Maybe it's time to describe our use cases here. In the IdM service we are >> planning individuals self-register their identities. With such an identity, >> individuals can register for studies at a university. But one individual >> may only register once at the same university. Another case is a user's >> library account that was blocked because of violations of the library's >> usage terms. Such a user should not be able to just create a new account to >> use the library services again. >> >> With Justin's suggestion of a Pu category, the requirements in our use >> cases could be expressed as P1.Pu or P2.Pu. The semantics of "P2.Pu" >> would then be: Proofed unique based on an attribute set with the vetting >> level P2. >> >> cheers >> >> Rolf >> >> >> >> On 11.03.16 02:56, Joanne Knight wrote: >> > Hi All >> > >> > There are three aspect or levels when looking at uniqueness to be >> > considered. >> > >> > First level is that the identity is unique - that is, within a context >> > there is a set of attributes that are unique for each identity >> > registered. >> > >> > Second level is sole claimant - this is a check that only one entity >> > has claimed a particular set of attributes. At the higher levels of >> > identity proofing where authoritative sources are used it may be >> > possible to achieve this. This is sufficient in most RPs cases. At >> > this level while it is possible for a single entity to claim more than >> > one identity, they do so at the risk of causing a counter-fraud flag >> > should the real owner (or any other party) also attempt to claim the >> > identity. >> > >> > The final level is one and only one - This is a check - usually >> > biometric - that an entity has only one claim in the context. This is >> > usually only reserved for the highest level of identity and would also >> > require equally high levels of credential and credential issuance >> > processes. >> > >> > As to how this relates to VoT - The first should be innately built >> > into all levels of P - it is the sole requirement of all levels >> > >> > The second could be built into P3 if the wording was amended slightly. >> > >> > The last item only is substantively missing and to date (in the >> > conversations I have been having elsewhere) there has been >> > insufficient appetite to add it as an explicit requirement. >> > >> > Should we have a PU? Maybe, but steer clear of the term 'unique' If we >> > do, in my mind it would only have two values - P?0 - Claims per entity >> > not checked, P?1 - Claims per entity restricted to one. >> > >> > Joanne >> > >> > >> > -----Original Message----- From: Rolf Brugger >> > [mailto:rolf.brugger@switch.ch >> ] Sent: Friday, >> 11 March 2016 5:51 a.m. >> > To: vot@ietf.org >> Subject: [VoT] How to express duplicate checks with >> > VoT? >> > >> > Hi all, >> > >> > I'm new to this list and I hope my question is not totally irrelevant >> > here. >> > >> > We have plenty of use cases where RPs need to have confidence, that a >> > person does not have multiple identities in one IdP. I don't see how >> > this aspect of identity quality can be expressed, and I believe it is >> > pretty orthogonal to the P, C, M and A dimensions that are currently >> > specified in the VoT draft. >> > >> > We could imagine multiple ways to gradually prove that an identity has >> > been checked against duplicates. The most straightforward approach >> > would be to make sure that unique personal attributes are used only >> > once within one IdP or an IdP federation, like - email >> > address(es) - mobile phone number - home postal address - social >> > security number - ID / passport number - the combination of name and >> > birth date - etc. >> > >> > Would it make sense to express this in VoT? >> > >> > best regards >> > >> > Rolf >> > >> > >> > -- SWITCH -------------------------- Rolf Brugger, project Swiss >> > edu-ID Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland phone +41 44 >> > 268 15 15, direct +41 44 268 15 89 rolf.brugger@switch.ch >> , >> > http://www.switch.ch >> > >> > >> > _______________________________________________ vot mailing list >> > vot@ietf.org >> https://www.ietf.org/mailman/listinfo/vot >> > >> >> -- >> SWITCH >> -------------------------- >> Rolf Brugger, project Swiss edu-ID >> Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland phone +41 44 268 15 15, >> direct +41 44 268 15 89 rolf.brugger@switch.ch >> , >> http://www.switch.ch >> >> >> _______________________________________________ >> vot mailing list >> vot@ietf.org >> https://www.ietf.org/mailman/listinfo/vot >> > > -- Kenneth Dagg Independent Consultant Identification and Authentication 613-825-2091 kendaggtbs@gmail.com --001a113d608667e362052e563894 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Here, here!!!

I have been a lurker on this gr= oup for a while but felt compelled to add my to cents to this discussion as= it is, I believe, an important point to scoping the discussion as it proce= eds.

I agree fully that determining the uniqueness= of a subject is totally the responsibility of the RP. It is their service = delivery and they have to determine what they require in order for them to = be assured that they are dealing with a unique subject. I use subject in or= der to include the IOT in the possible solution. If I'm reading what yo= u say correctly, one of the considerations that a RP might use to determine= uniqueness is the level of proofing they require on 1) each of the attribu= tes and 2) the set of attributes.

My experience wi= th RPs aligns with=C2=A0Julian's.=C2=A0While RPs=C2=A0usually ask for u= niqueness from their digital supplier they do not do so in the manual world= . My tactic has been to ask why they are asking for it in the digital world= and not in the manual world. The discussion around this question (usually = around 1) their perceived benefit and=C2=A02) the additional cost versus th= eir perceived benefit) leads to them dropping that requirement from their d= igital supplier.

The "imposter" discussi= on usually takes the same path. Asking the RP how they deal with imposters = in the manual world usually leads to a conclusion that they can employ the = same tactics and processes only using digital data. Cost effectiveness is u= sually a big part of the discussion. This should not be likened to paving t= he cow path. What usually happens is that they realize that, in the digital= world, they might be able to detect an imposter faster because they have f= aster access to the data they use to detect imposters. In some cases, they = may realize improved detection because the proofing data is likely better t= han they have available in the manual world.=C2=A0

It is my opinion that, as their processes evolve in the digital world, the= y will become faster at imposter detection and resolution. It is also my op= inion that prevention of imposters before they happen, like the totally sec= ure system, is, if not impossible, not=C2=A0a cost effective goal to achiev= e.

Ken Dagg


On Friday, 18 March 2016, Julian White <jwhite@nu-d.com> wrote:

I would say, as I have in the ISO 29003 discussio= ns, that uniqueness is in fact irrelevant in terms of the level of proofing= . I see no need to know whether that set of attributes is proven to be uniq= ue by the proofing provider. Uniqueness is highly dependent on the context,= which raises all sorts of problems if you have an identity federation (how= do I know its unique across the federation? If, as an RP, I can can cope w= ith non-uniqueness across the federation then=C2=A0non-uniqueness=C2=A0with= in the proofing provider is also not a problem).

In my v= iew it is for the RP, or identity federation scheme, to decide which attrib= utes are required in their context. They select sufficient attributes that = give them uniqueness (in their context) if that is required, e.g. SSN for s= ome services (though I would advise against it!). The purpose of the proofi= ng process is to express to what level of confidence that those attributes = are true and belong to the person presenting them, be they name, address, d= ob, email address, SSN etc.

In my dealings with RP= s they are confused about this and ask for "uniqueness", this is = usually followed up with "because we can't let people register mul= tiple identities". There is a lack of understanding that, assuming the= proofing process is working correctly, it doesn't matter how many time= s you enrol you are proven to be the same person each time; i.e. multiple e= nrolments lead to the identification of the same person being bound to the = same attributes. Therefore it isn't actually a problem in terms of uniq= ueness.=C2=A0

More often than not the ask for uniq= ueness is really an expression of how well the system defends itself agains= t impostors (different people registering for the same attributes) which is= actually the point of the different levels of proofing (the higher the lev= els of proofing the harder this should become). Demanding uniqueness doesn&= #39;t actually fix the impostor problem, you just introduce a time trial to= the process; the first person to get bound to those attributes locks out o= ther people; if the first person to claim them was the impostor you've = now locked out the genuine person - they now have a hell of time unpicking = a mess not of their making. If the system defends against impostors properl= y at the higher levels then the uniqueness adds little value since I can on= ly bind those attributes to the correct person anyway.

=
The thing that may need to be unique is the account/record at the RP, = and its the RP's responsibility to manage that. This is a problem they = have regardless of whether the proofing provider tells them its unique or n= ot because they often have multiple on-line and offline channels that deal = with their customers, this forces them to understand how to match different= representations of the identity to the same account which tends to work ac= ross channel and within the same channel.

So in su= mmary it doesn't drive any real value in the proofing provider to do th= is, its just a cost of effort for little gain that the RP is going to repea= t regardless if they care about uniqueness.

Regard= s,

Julian.




= On 17 March 2016 at 21:49, Joanne Knight <Joanne.Knight@dia.govt.nz> wrote:
The short answer to your question - No.

Your use case is silent on the level of vetting required (how real does the= identity have to be). You can have any level of identity and still collect= a biometric for the purposes of one and only one uniqueness. I would pose = however that it is very unusual for one and only one assurance to be requir= ed without some other driver requiring an elevated level of realness.

In your use case I would suggest that there is also a requirement that a qu= alification is issued to
a) the person carrying out the study and
b) an identity of such rigour that their (or the university's) eligibil= ity for public funding can be established and
c) an identity that is going to be tested by future employers.

Therefore you are probably looking at P2 or P3 depending on the level/type = of qualification. (I might want P3 if the qualification is for brain surgeo= n or commercial pilot).

As one and only one is really only able to be achieved through the use of a= biometric, we now have to consider 'acceptability'.
Does the collection of a biometric (and all that it entails - cost, privacy= , security, user acceptance etc.) outweigh the impact caused by a duplicate= entity in the system?
In other words, do you really need one and only one (the 3rd level of uniqu= eness) or could sufficient singularity be gained from leveraging the social= security number's uniqueness and an equivalent level of validation and= ownership test (the 2nd level of uniqueness) i.e. no Pu?

We must remember the mutual exclusivity between attributes collected, vetti= ng under taken and level of uniqueness.

Happy to discuss further if this makes no sense.

Cheers



-----Original Message-----
From: Rolf Brugger [mailto:rolf.brugger@switch.ch= ]
Sent: Thursday, 17 March 2016 11:35 p.m.
To: vot@ietf.org
Subject: Re: [VoT] How to express duplicate checks with VoT?

Hi all,

Thanks for all your responses and ideas. We have discussed your inputs in o= ur project team (which is why it took me some time to respond)

I was wondering what actually the differences are between the three levels = of uniqueness described by Joanne. In each of the three levels a set of att= ributes is used to determine if an identity is unique within a population o= f identities. The difference is 1) what exact set of attributes is used in = each level and 2) the vetting level of the attributes. Right?

A concrete example might be

First level:
- attributes: Name, email, phone number
- vetting level: P1

Second level:
- attributes: Name, email, phone number, social security number
- vetting level: P2

Third level:
- attributes: finger print or retina scan
- vetting level: P3

The appropriate set of attributes to be used in each level is certainly con= text-specific. As Eric points out it will be difficult to define and agree = on a generic definition of the scope.

Maybe it's time to describe our use cases here. In the IdM service we a= re planning individuals self-register their identities. With such an identi= ty, individuals can register for studies at a university. But one individua= l may only register once at the same university. Another case is a user'= ;s library account that was blocked because of violations of the library= 9;s usage terms. Such a user should not be able to just create a new accoun= t to use the library services again.

With Justin's suggestion of a Pu category, the requirements in our use = cases could be expressed as P1.Pu or P2.Pu. The semantics of "P2.Pu&qu= ot;
would then be: Proofed unique based on an attribute set with the vetting le= vel P2.

cheers

Rolf



On 11.03.16 02:56, Joanne Knight wrote:
> Hi All
>
> There are three aspect or levels when looking at uniqueness to be
> considered.
>
> First level is that the identity is unique - that is, within a context=
> there is a set of attributes that are unique for each identity
> registered.
>
> Second level is sole claimant - this is a check that only one entity > has claimed a particular set of attributes. At the higher levels of > identity proofing where authoritative sources are used it may be
> possible to achieve this. This is sufficient in most RPs cases. At
> this level while it is possible for a single entity to claim more than=
> one identity, they do so at the risk of causing a counter-fraud flag > should the real owner (or any other party) also attempt to claim the > identity.
>
> The final level is one and only one - This is a check - usually
> biometric - that an entity has only one claim in the context. This is<= br> > usually only reserved for the highest level of identity and would also=
> require equally high levels of credential and credential issuance
> processes.
>
> As to how this relates to VoT - The first should be innately built
> into all levels of P - it is the sole requirement of all levels
>
> The second could be built into P3 if the wording was amended slightly.=
>
> The last item only is substantively missing and to date (in the
> conversations I have been having elsewhere) there has been
> insufficient appetite to add it as an explicit requirement.
>
> Should we have a PU? Maybe, but steer clear of the term 'unique= 9; If we
> do, in my mind it would only have two values - P?0 - Claims per entity=
> not checked, P?1 - Claims per entity restricted to one.
>
> Joanne
>
>
> -----Original Message----- From: Rolf Brugger
> [mailto:rolf.brugger@switch.ch] Sent: Fr= iday, 11 March 2016 5:51 a.m.
> To: vot@ietf.org Subject: [VoT] How to express dup= licate checks with
> VoT?
>
> Hi all,
>
> I'm new to this list and I hope my question is not totally irrelev= ant
> here.
>
> We have plenty of use cases where RPs need to have confidence, that a<= br> > person does not have multiple identities in one IdP. I don't see h= ow
> this aspect of identity quality can be expressed, and I believe it is<= br> > pretty orthogonal to the P, C, M and A dimensions that are currently > specified in the VoT draft.
>
> We could imagine multiple ways to gradually prove that an identity has=
> been checked against duplicates. The most straightforward approach
> would be to make sure that unique personal attributes are used only > once within one IdP or an IdP federation, like - email
> address(es) - mobile phone number - home postal address - social
> security number - ID / passport number - the combination of name and > birth date - etc.
>
> Would it make sense to express this in VoT?
>
> best regards
>
> Rolf
>
>
> -- SWITCH -------------------------- Rolf Brugger, project Swiss
> edu-ID Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland phone +41 44<= br> > 268 15 15, direct +41 44 268 15 89 rolf.brugger@switch.ch,
> = http://www.switch.ch
>
>
> _______________________________________________ vot mailing list
> vot@ietf.org https://www.ietf.org/= mailman/listinfo/vot
>

--
SWITCH
--------------------------
Rolf Brugger, project Swiss edu-ID
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland phone +41 44 268= 15 15, direct +41 44 268 15 89 = rolf.brugger@switch.ch, http://www.switch.ch


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



--
Kenneth Dagg
Independent Consultant
Ident= ification and Authentication
613-825-2091
kendaggtbs@gmail.com
--001a113d608667e362052e563894-- From nobody Fri Mar 18 11:32:51 2016 Return-Path: X-Original-To: vot@ietfa.amsl.com Delivered-To: vot@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 917F212D8B7 for ; Fri, 18 Mar 2016 11:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ucofficeofthepresident.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EzqHj6kmBWph for ; Fri, 18 Mar 2016 11:32:46 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0658.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::658]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DDFF12D780 for ; Fri, 18 Mar 2016 11:32:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ucofficeofthepresident.onmicrosoft.com; s=selector1-ucop-edu; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vdCOG2MwtYj2GHUsuTgoReaFSl55dzIvXIyMA1WdvqY=; b=M49aZUanWKnwAhzR9zh6eMkt6Uf6SkAUVTiC523Ipc9zq0M1JcXozseORJ2QyopB27/911+h4bmQlpmss6NFeQFThPi3NkLvsP326VYWLMcZmEcPmQOgCkc7u60UtGWNec5o95sgnCTAtPJqzCN0ad/bhaPLnI06nSD/DDM+FiM= Received: from BN3PR0601MB1956.namprd06.prod.outlook.com (10.165.119.146) by BN3PR0601MB1954.namprd06.prod.outlook.com (10.165.119.144) with Microsoft SMTP Server (TLS) id 15.1.434.16; Fri, 18 Mar 2016 18:32:25 +0000 Received: from BN3PR0601MB1956.namprd06.prod.outlook.com ([10.165.119.146]) by BN3PR0601MB1956.namprd06.prod.outlook.com ([10.165.119.146]) with mapi id 15.01.0434.021; Fri, 18 Mar 2016 18:32:25 +0000 From: Eric Goodman To: "vot@ietf.org" Thread-Topic: [VoT] How to express duplicate checks with VoT? Thread-Index: AQHRgRjd7B/eYhgAUEWWABVUKcD48Z9fguaw Date: Fri, 18 Mar 2016 18:32:25 +0000 Message-ID: References: <56E1A5F8.3090201@switch.ch> <569AD906E45DB44A8AFF11D61F5DA7910155C7D4F2@AKLDRMBX03.dia.govt.nz> <56EA8845.3040503@switch.ch> <569AD906E45DB44A8AFF11D61F5DA7910155C80A34@AKLDRMBX03.dia.govt.nz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ucop.edu; x-originating-ip: [128.48.44.96] x-ms-office365-filtering-correlation-id: ab4fadbc-8843-413c-a964-08d34f5ba732 x-microsoft-exchange-diagnostics: 1; BN3PR0601MB1954; 5:eztg7I9xgBGwAWpuadLfTG690cKk5BiaMx5+DE9KS65peQYPfmbEVvio2sUe1cBbfn4PKgiRdMVaFp2sYmv1W5GzFCobmxkVescp/BfcuKqShXq8FRSjiUxW4DR8xFSH6y+jvky7M/D/KZmlJDpCdw==; 24:Rwoy+UzazLIXF/c4uOrqV2kdwhRURGq6xKguIBuanr5fu7D74MhDSG7AKWDjEhIG6iMVNuy2fOW+dHMybsmj6izTLYEWSI0grYDWaIFB/A4= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0601MB1954; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BN3PR0601MB1954; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0601MB1954; x-forefront-prvs: 088552DE73 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(69224002)(24454002)(377454003)(13464003)(53754006)(19609705001)(81166005)(19580405001)(5002640100001)(19580395003)(92566002)(3280700002)(76576001)(5630700001)(3660700001)(75432002)(106116001)(5640700001)(76176999)(90282001)(99286002)(54356999)(2501003)(50986999)(19617315012)(16236675004)(74316001)(19300405004)(88552002)(450100001)(586003)(6116002)(102836003)(3846002)(2900100001)(790700001)(16601075003)(87936001)(5004730100002)(5003600100002)(1220700001)(107886002)(5008740100001)(122556002)(110136002)(10400500002)(1730700002)(11100500001)(1096002)(189998001)(93886004)(66066001)(2906002)(2351001)(33656002)(86362001)(106356001)(15975445007)(19625215002)(89122001)(77096005)(2950100001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR0601MB1954; H:BN3PR0601MB1956.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR0601MB1956E6B81FD35211464C2032FB8C0BN3PR0601MB1956_" MIME-Version: 1.0 X-OriginatorOrg: ucop.edu X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Mar 2016 18:32:25.3153 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6737ae8b-7f79-4cda-90a2-1861f16fa830 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0601MB1954 Archived-At: Subject: Re: [VoT] How to express duplicate checks with VoT? X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2016 18:32:50 -0000 --_000_BN3PR0601MB1956E6B81FD35211464C2032FB8C0BN3PR0601MB1956_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB3b3VsZCBleHBlY3QgKHRob3VnaCBjb3VsZCBiZSB3cm9uZykgdGhhdCB0aGUgaXNzdWUgaXNu 4oCZdCBqdXN0IGltcG9zdGVycywgYnV0IGFzIG11Y2ggYWJvdXQgZW5mb3JjZW1lbnQgb2Ygc2Vw YXJhdGlvbiBvZiBkdXRpZXMgZm9yIHRoZSBzYW1lIGVudGl0eS4gSWYgSSBnaXZlIG9uZSBvZiB5 b3VyIGFjY291bnRzIHJldmlldyByaWdodHMgYW5kIGFub3RoZXIgYXBwcm92YWwgcmlnaHRzLCB0 aGVuIHRoZXJl4oCZcyBhbiBTb0QgaXNzdWUuDQoNClNvIHRoZSBvbmx5IHRoaW5nIEkgd2FzIHRo aW5raW5nIHdvdWxkIGJlIHdvcnRoIG1lYXN1cmluZyB3aXRoaW4gdGhlIElkUCBpcyB3aGV0aGVy IHRoZSBMb0EgcmVnaXN0cmF0aW9uIHByb2Nlc3MgaW5jbHVkZXMgZHVwbGljYXRlIHJlc29sdXRp b24uIEkgZG9u4oCZdCBrbm93IHRoYXQgYW55IGFzc3VyYW5jZSBwcm9maWxlcy9Wb1TigJlzIEni gJl2ZSBzZWVuIGluY2x1ZGUgdGhhdCBhcyBhbiBleHBsaWNpdCByZXF1aXJlbWVudC4gSS5lLiwg d2hhdOKAmXMgdG8gc3RvcCBtZSBmcm9tIGhhdmluZyB0d28gYWNjb3VudHMgYm90aCB2ZXR0ZWQg dG8gYSBzdHJvbmcgZGVncmVlIGFuZCB0aGUgSWRQIGRvZXNu4oCZdCByZWNvZ25pemUgdGhlbSBh cyB0aGUgc2FtZSBwZXJzb24uDQoNCkJ1dCB5b3VyIHBvaW50IGlzIGNvbXBlbGxpbmc6IElzIGlk ZW50aXR5IG1hdGNoaW5nIGludGVybmFsIHRvIGFuIElkUCB0ZXJyaWJseSBpcnJlbGV2YW50IGlu IGEgZmVkZXJhdGVkIHdvcmxkPyBXaGF0IHZhbHVlIGRvZXMgYW4gUlAgZ2V0IGJ5IGtub3dpbmcg dGhhdCB0aGlzIGlkZW50aXR5IHdhcyBjaGVja2VkIGFnYWluc3QgZHVwbGljYXRpb24gd2l0aGlu IGFuIElkUCBpZiBJIGNhbiBzZXBhcmF0ZWx5IGNyZWF0ZSBhbiBhY2NvdW50ICh3aXRoIGFuIGVx dWFsbHkgaGlnaCBMb0EpIHRocm91Z2ggYSBjb21wbGV0ZWx5IGRpZmZlcmVudCBJZFA/IEkgZG9u 4oCZdCBzZWUgd2hhdCBJZFAtbWFuYWdlZCB0cnVzdCBtZWFzdXJlL2luZGljYXRvciBpcyBnb2lu ZyB0byBoZWxwIHVubGVzcyB5b3UgbGltaXQgeW91ciB1c2UgY2FzZXMgdG8gdGhvc2UgaW52b2x2 aW5nIGEgc2luZ2xlIElkUCwgaW4gd2hpY2ggY2FzZSB0aGUgbmVlZCBmb3IgYSBwcm9maWxlIGFu ZCBzdGFuZGFyZGl6YXRpb24gaXMgbGVzcyBwcmVzc2luZy4NCg0KLS0tIEVyaWMNCg0KDQoNCkZy b206IHZvdCBbbWFpbHRvOnZvdC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSnVsaWFu IFdoaXRlDQpTZW50OiBGcmlkYXksIE1hcmNoIDE4LCAyMDE2IDY6MTkgQU0NClRvOiBKb2FubmUg S25pZ2h0DQpDYzogUm9sZiBCcnVnZ2VyOyB2b3RAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbVm9U XSBIb3cgdG8gZXhwcmVzcyBkdXBsaWNhdGUgY2hlY2tzIHdpdGggVm9UPw0KDQoNCkkgd291bGQg c2F5LCBhcyBJIGhhdmUgaW4gdGhlIElTTyAyOTAwMyBkaXNjdXNzaW9ucywgdGhhdCB1bmlxdWVu ZXNzIGlzIGluIGZhY3QgaXJyZWxldmFudCBpbiB0ZXJtcyBvZiB0aGUgbGV2ZWwgb2YgcHJvb2Zp bmcuIEkgc2VlIG5vIG5lZWQgdG8ga25vdyB3aGV0aGVyIHRoYXQgc2V0IG9mIGF0dHJpYnV0ZXMg aXMgcHJvdmVuIHRvIGJlIHVuaXF1ZSBieSB0aGUgcHJvb2ZpbmcgcHJvdmlkZXIuIFVuaXF1ZW5l c3MgaXMgaGlnaGx5IGRlcGVuZGVudCBvbiB0aGUgY29udGV4dCwgd2hpY2ggcmFpc2VzIGFsbCBz b3J0cyBvZiBwcm9ibGVtcyBpZiB5b3UgaGF2ZSBhbiBpZGVudGl0eSBmZWRlcmF0aW9uIChob3cg ZG8gSSBrbm93IGl0cyB1bmlxdWUgYWNyb3NzIHRoZSBmZWRlcmF0aW9uPyBJZiwgYXMgYW4gUlAs IEkgY2FuIGNhbiBjb3BlIHdpdGggbm9uLXVuaXF1ZW5lc3MgYWNyb3NzIHRoZSBmZWRlcmF0aW9u IHRoZW4gbm9uLXVuaXF1ZW5lc3Mgd2l0aGluIHRoZSBwcm9vZmluZyBwcm92aWRlciBpcyBhbHNv IG5vdCBhIHByb2JsZW0pLg0KDQpJbiBteSB2aWV3IGl0IGlzIGZvciB0aGUgUlAsIG9yIGlkZW50 aXR5IGZlZGVyYXRpb24gc2NoZW1lLCB0byBkZWNpZGUgd2hpY2ggYXR0cmlidXRlcyBhcmUgcmVx dWlyZWQgaW4gdGhlaXIgY29udGV4dC4gVGhleSBzZWxlY3Qgc3VmZmljaWVudCBhdHRyaWJ1dGVz IHRoYXQgZ2l2ZSB0aGVtIHVuaXF1ZW5lc3MgKGluIHRoZWlyIGNvbnRleHQpIGlmIHRoYXQgaXMg cmVxdWlyZWQsIGUuZy4gU1NOIGZvciBzb21lIHNlcnZpY2VzICh0aG91Z2ggSSB3b3VsZCBhZHZp c2UgYWdhaW5zdCBpdCEpLiBUaGUgcHVycG9zZSBvZiB0aGUgcHJvb2ZpbmcgcHJvY2VzcyBpcyB0 byBleHByZXNzIHRvIHdoYXQgbGV2ZWwgb2YgY29uZmlkZW5jZSB0aGF0IHRob3NlIGF0dHJpYnV0 ZXMgYXJlIHRydWUgYW5kIGJlbG9uZyB0byB0aGUgcGVyc29uIHByZXNlbnRpbmcgdGhlbSwgYmUg dGhleSBuYW1lLCBhZGRyZXNzLCBkb2IsIGVtYWlsIGFkZHJlc3MsIFNTTiBldGMuDQoNCkluIG15 IGRlYWxpbmdzIHdpdGggUlBzIHRoZXkgYXJlIGNvbmZ1c2VkIGFib3V0IHRoaXMgYW5kIGFzayBm b3IgInVuaXF1ZW5lc3MiLCB0aGlzIGlzIHVzdWFsbHkgZm9sbG93ZWQgdXAgd2l0aCAiYmVjYXVz ZSB3ZSBjYW4ndCBsZXQgcGVvcGxlIHJlZ2lzdGVyIG11bHRpcGxlIGlkZW50aXRpZXMiLiBUaGVy ZSBpcyBhIGxhY2sgb2YgdW5kZXJzdGFuZGluZyB0aGF0LCBhc3N1bWluZyB0aGUgcHJvb2Zpbmcg cHJvY2VzcyBpcyB3b3JraW5nIGNvcnJlY3RseSwgaXQgZG9lc24ndCBtYXR0ZXIgaG93IG1hbnkg dGltZXMgeW91IGVucm9sIHlvdSBhcmUgcHJvdmVuIHRvIGJlIHRoZSBzYW1lIHBlcnNvbiBlYWNo IHRpbWU7IGkuZS4gbXVsdGlwbGUgZW5yb2xtZW50cyBsZWFkIHRvIHRoZSBpZGVudGlmaWNhdGlv biBvZiB0aGUgc2FtZSBwZXJzb24gYmVpbmcgYm91bmQgdG8gdGhlIHNhbWUgYXR0cmlidXRlcy4g VGhlcmVmb3JlIGl0IGlzbid0IGFjdHVhbGx5IGEgcHJvYmxlbSBpbiB0ZXJtcyBvZiB1bmlxdWVu ZXNzLg0KDQpNb3JlIG9mdGVuIHRoYW4gbm90IHRoZSBhc2sgZm9yIHVuaXF1ZW5lc3MgaXMgcmVh bGx5IGFuIGV4cHJlc3Npb24gb2YgaG93IHdlbGwgdGhlIHN5c3RlbSBkZWZlbmRzIGl0c2VsZiBh Z2FpbnN0IGltcG9zdG9ycyAoZGlmZmVyZW50IHBlb3BsZSByZWdpc3RlcmluZyBmb3IgdGhlIHNh bWUgYXR0cmlidXRlcykgd2hpY2ggaXMgYWN0dWFsbHkgdGhlIHBvaW50IG9mIHRoZSBkaWZmZXJl bnQgbGV2ZWxzIG9mIHByb29maW5nICh0aGUgaGlnaGVyIHRoZSBsZXZlbHMgb2YgcHJvb2Zpbmcg dGhlIGhhcmRlciB0aGlzIHNob3VsZCBiZWNvbWUpLiBEZW1hbmRpbmcgdW5pcXVlbmVzcyBkb2Vz bid0IGFjdHVhbGx5IGZpeCB0aGUgaW1wb3N0b3IgcHJvYmxlbSwgeW91IGp1c3QgaW50cm9kdWNl IGEgdGltZSB0cmlhbCB0byB0aGUgcHJvY2VzczsgdGhlIGZpcnN0IHBlcnNvbiB0byBnZXQgYm91 bmQgdG8gdGhvc2UgYXR0cmlidXRlcyBsb2NrcyBvdXQgb3RoZXIgcGVvcGxlOyBpZiB0aGUgZmly c3QgcGVyc29uIHRvIGNsYWltIHRoZW0gd2FzIHRoZSBpbXBvc3RvciB5b3UndmUgbm93IGxvY2tl ZCBvdXQgdGhlIGdlbnVpbmUgcGVyc29uIC0gdGhleSBub3cgaGF2ZSBhIGhlbGwgb2YgdGltZSB1 bnBpY2tpbmcgYSBtZXNzIG5vdCBvZiB0aGVpciBtYWtpbmcuIElmIHRoZSBzeXN0ZW0gZGVmZW5k cyBhZ2FpbnN0IGltcG9zdG9ycyBwcm9wZXJseSBhdCB0aGUgaGlnaGVyIGxldmVscyB0aGVuIHRo ZSB1bmlxdWVuZXNzIGFkZHMgbGl0dGxlIHZhbHVlIHNpbmNlIEkgY2FuIG9ubHkgYmluZCB0aG9z ZSBhdHRyaWJ1dGVzIHRvIHRoZSBjb3JyZWN0IHBlcnNvbiBhbnl3YXkuDQoNClRoZSB0aGluZyB0 aGF0IG1heSBuZWVkIHRvIGJlIHVuaXF1ZSBpcyB0aGUgYWNjb3VudC9yZWNvcmQgYXQgdGhlIFJQ LCBhbmQgaXRzIHRoZSBSUCdzIHJlc3BvbnNpYmlsaXR5IHRvIG1hbmFnZSB0aGF0LiBUaGlzIGlz IGEgcHJvYmxlbSB0aGV5IGhhdmUgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIHRoZSBwcm9vZmluZyBw cm92aWRlciB0ZWxscyB0aGVtIGl0cyB1bmlxdWUgb3Igbm90IGJlY2F1c2UgdGhleSBvZnRlbiBo YXZlIG11bHRpcGxlIG9uLWxpbmUgYW5kIG9mZmxpbmUgY2hhbm5lbHMgdGhhdCBkZWFsIHdpdGgg dGhlaXIgY3VzdG9tZXJzLCB0aGlzIGZvcmNlcyB0aGVtIHRvIHVuZGVyc3RhbmQgaG93IHRvIG1h dGNoIGRpZmZlcmVudCByZXByZXNlbnRhdGlvbnMgb2YgdGhlIGlkZW50aXR5IHRvIHRoZSBzYW1l IGFjY291bnQgd2hpY2ggdGVuZHMgdG8gd29yayBhY3Jvc3MgY2hhbm5lbCBhbmQgd2l0aGluIHRo ZSBzYW1lIGNoYW5uZWwuDQoNClNvIGluIHN1bW1hcnkgaXQgZG9lc24ndCBkcml2ZSBhbnkgcmVh bCB2YWx1ZSBpbiB0aGUgcHJvb2ZpbmcgcHJvdmlkZXIgdG8gZG8gdGhpcywgaXRzIGp1c3QgYSBj b3N0IG9mIGVmZm9ydCBmb3IgbGl0dGxlIGdhaW4gdGhhdCB0aGUgUlAgaXMgZ29pbmcgdG8gcmVw ZWF0IHJlZ2FyZGxlc3MgaWYgdGhleSBjYXJlIGFib3V0IHVuaXF1ZW5lc3MuDQoNClJlZ2FyZHMs DQoNCkp1bGlhbi4NCg0KDQoNCg0KT24gMTcgTWFyY2ggMjAxNiBhdCAyMTo0OSwgSm9hbm5lIEtu aWdodCA8Sm9hbm5lLktuaWdodEBkaWEuZ292dC5uejxtYWlsdG86Sm9hbm5lLktuaWdodEBkaWEu Z292dC5uej4+IHdyb3RlOg0KVGhlIHNob3J0IGFuc3dlciB0byB5b3VyIHF1ZXN0aW9uIC0gTm8u DQoNCllvdXIgdXNlIGNhc2UgaXMgc2lsZW50IG9uIHRoZSBsZXZlbCBvZiB2ZXR0aW5nIHJlcXVp cmVkIChob3cgcmVhbCBkb2VzIHRoZSBpZGVudGl0eSBoYXZlIHRvIGJlKS4gWW91IGNhbiBoYXZl IGFueSBsZXZlbCBvZiBpZGVudGl0eSBhbmQgc3RpbGwgY29sbGVjdCBhIGJpb21ldHJpYyBmb3Ig dGhlIHB1cnBvc2VzIG9mIG9uZSBhbmQgb25seSBvbmUgdW5pcXVlbmVzcy4gSSB3b3VsZCBwb3Nl IGhvd2V2ZXIgdGhhdCBpdCBpcyB2ZXJ5IHVudXN1YWwgZm9yIG9uZSBhbmQgb25seSBvbmUgYXNz dXJhbmNlIHRvIGJlIHJlcXVpcmVkIHdpdGhvdXQgc29tZSBvdGhlciBkcml2ZXIgcmVxdWlyaW5n IGFuIGVsZXZhdGVkIGxldmVsIG9mIHJlYWxuZXNzLg0KDQpJbiB5b3VyIHVzZSBjYXNlIEkgd291 bGQgc3VnZ2VzdCB0aGF0IHRoZXJlIGlzIGFsc28gYSByZXF1aXJlbWVudCB0aGF0IGEgcXVhbGlm aWNhdGlvbiBpcyBpc3N1ZWQgdG8NCmEpIHRoZSBwZXJzb24gY2Fycnlpbmcgb3V0IHRoZSBzdHVk eSBhbmQNCmIpIGFuIGlkZW50aXR5IG9mIHN1Y2ggcmlnb3VyIHRoYXQgdGhlaXIgKG9yIHRoZSB1 bml2ZXJzaXR5J3MpIGVsaWdpYmlsaXR5IGZvciBwdWJsaWMgZnVuZGluZyBjYW4gYmUgZXN0YWJs aXNoZWQgYW5kDQpjKSBhbiBpZGVudGl0eSB0aGF0IGlzIGdvaW5nIHRvIGJlIHRlc3RlZCBieSBm dXR1cmUgZW1wbG95ZXJzLg0KDQpUaGVyZWZvcmUgeW91IGFyZSBwcm9iYWJseSBsb29raW5nIGF0 IFAyIG9yIFAzIGRlcGVuZGluZyBvbiB0aGUgbGV2ZWwvdHlwZSBvZiBxdWFsaWZpY2F0aW9uLiAo SSBtaWdodCB3YW50IFAzIGlmIHRoZSBxdWFsaWZpY2F0aW9uIGlzIGZvciBicmFpbiBzdXJnZW9u IG9yIGNvbW1lcmNpYWwgcGlsb3QpLg0KDQpBcyBvbmUgYW5kIG9ubHkgb25lIGlzIHJlYWxseSBv bmx5IGFibGUgdG8gYmUgYWNoaWV2ZWQgdGhyb3VnaCB0aGUgdXNlIG9mIGEgYmlvbWV0cmljLCB3 ZSBub3cgaGF2ZSB0byBjb25zaWRlciAnYWNjZXB0YWJpbGl0eScuDQpEb2VzIHRoZSBjb2xsZWN0 aW9uIG9mIGEgYmlvbWV0cmljIChhbmQgYWxsIHRoYXQgaXQgZW50YWlscyAtIGNvc3QsIHByaXZh Y3ksIHNlY3VyaXR5LCB1c2VyIGFjY2VwdGFuY2UgZXRjLikgb3V0d2VpZ2ggdGhlIGltcGFjdCBj YXVzZWQgYnkgYSBkdXBsaWNhdGUgZW50aXR5IGluIHRoZSBzeXN0ZW0/DQpJbiBvdGhlciB3b3Jk cywgZG8geW91IHJlYWxseSBuZWVkIG9uZSBhbmQgb25seSBvbmUgKHRoZSAzcmQgbGV2ZWwgb2Yg dW5pcXVlbmVzcykgb3IgY291bGQgc3VmZmljaWVudCBzaW5ndWxhcml0eSBiZSBnYWluZWQgZnJv bSBsZXZlcmFnaW5nIHRoZSBzb2NpYWwgc2VjdXJpdHkgbnVtYmVyJ3MgdW5pcXVlbmVzcyBhbmQg YW4gZXF1aXZhbGVudCBsZXZlbCBvZiB2YWxpZGF0aW9uIGFuZCBvd25lcnNoaXAgdGVzdCAodGhl IDJuZCBsZXZlbCBvZiB1bmlxdWVuZXNzKSBpLmUuIG5vIFB1Pw0KDQpXZSBtdXN0IHJlbWVtYmVy IHRoZSBtdXR1YWwgZXhjbHVzaXZpdHkgYmV0d2VlbiBhdHRyaWJ1dGVzIGNvbGxlY3RlZCwgdmV0 dGluZyB1bmRlciB0YWtlbiBhbmQgbGV2ZWwgb2YgdW5pcXVlbmVzcy4NCg0KSGFwcHkgdG8gZGlz Y3VzcyBmdXJ0aGVyIGlmIHRoaXMgbWFrZXMgbm8gc2Vuc2UuDQoNCkNoZWVycw0KDQoNCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFJvbGYgQnJ1Z2dlciBbbWFpbHRvOnJvbGYu YnJ1Z2dlckBzd2l0Y2guY2g8bWFpbHRvOnJvbGYuYnJ1Z2dlckBzd2l0Y2guY2g+XQ0KU2VudDog VGh1cnNkYXksIDE3IE1hcmNoIDIwMTYgMTE6MzUgcC5tLg0KVG86IHZvdEBpZXRmLm9yZzxtYWls dG86dm90QGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtWb1RdIEhvdyB0byBleHByZXNzIGR1cGxp Y2F0ZSBjaGVja3Mgd2l0aCBWb1Q/DQoNCkhpIGFsbCwNCg0KVGhhbmtzIGZvciBhbGwgeW91ciBy ZXNwb25zZXMgYW5kIGlkZWFzLiBXZSBoYXZlIGRpc2N1c3NlZCB5b3VyIGlucHV0cyBpbiBvdXIg cHJvamVjdCB0ZWFtICh3aGljaCBpcyB3aHkgaXQgdG9vayBtZSBzb21lIHRpbWUgdG8gcmVzcG9u ZCkNCg0KSSB3YXMgd29uZGVyaW5nIHdoYXQgYWN0dWFsbHkgdGhlIGRpZmZlcmVuY2VzIGFyZSBi ZXR3ZWVuIHRoZSB0aHJlZSBsZXZlbHMgb2YgdW5pcXVlbmVzcyBkZXNjcmliZWQgYnkgSm9hbm5l LiBJbiBlYWNoIG9mIHRoZSB0aHJlZSBsZXZlbHMgYSBzZXQgb2YgYXR0cmlidXRlcyBpcyB1c2Vk IHRvIGRldGVybWluZSBpZiBhbiBpZGVudGl0eSBpcyB1bmlxdWUgd2l0aGluIGEgcG9wdWxhdGlv biBvZiBpZGVudGl0aWVzLiBUaGUgZGlmZmVyZW5jZSBpcyAxKSB3aGF0IGV4YWN0IHNldCBvZiBh dHRyaWJ1dGVzIGlzIHVzZWQgaW4gZWFjaCBsZXZlbCBhbmQgMikgdGhlIHZldHRpbmcgbGV2ZWwg b2YgdGhlIGF0dHJpYnV0ZXMuIFJpZ2h0Pw0KDQpBIGNvbmNyZXRlIGV4YW1wbGUgbWlnaHQgYmUN Cg0KRmlyc3QgbGV2ZWw6DQotIGF0dHJpYnV0ZXM6IE5hbWUsIGVtYWlsLCBwaG9uZSBudW1iZXIN Ci0gdmV0dGluZyBsZXZlbDogUDENCg0KU2Vjb25kIGxldmVsOg0KLSBhdHRyaWJ1dGVzOiBOYW1l LCBlbWFpbCwgcGhvbmUgbnVtYmVyLCBzb2NpYWwgc2VjdXJpdHkgbnVtYmVyDQotIHZldHRpbmcg bGV2ZWw6IFAyDQoNClRoaXJkIGxldmVsOg0KLSBhdHRyaWJ1dGVzOiBmaW5nZXIgcHJpbnQgb3Ig cmV0aW5hIHNjYW4NCi0gdmV0dGluZyBsZXZlbDogUDMNCg0KVGhlIGFwcHJvcHJpYXRlIHNldCBv ZiBhdHRyaWJ1dGVzIHRvIGJlIHVzZWQgaW4gZWFjaCBsZXZlbCBpcyBjZXJ0YWlubHkgY29udGV4 dC1zcGVjaWZpYy4gQXMgRXJpYyBwb2ludHMgb3V0IGl0IHdpbGwgYmUgZGlmZmljdWx0IHRvIGRl ZmluZSBhbmQgYWdyZWUgb24gYSBnZW5lcmljIGRlZmluaXRpb24gb2YgdGhlIHNjb3BlLg0KDQpN YXliZSBpdCdzIHRpbWUgdG8gZGVzY3JpYmUgb3VyIHVzZSBjYXNlcyBoZXJlLiBJbiB0aGUgSWRN IHNlcnZpY2Ugd2UgYXJlIHBsYW5uaW5nIGluZGl2aWR1YWxzIHNlbGYtcmVnaXN0ZXIgdGhlaXIg aWRlbnRpdGllcy4gV2l0aCBzdWNoIGFuIGlkZW50aXR5LCBpbmRpdmlkdWFscyBjYW4gcmVnaXN0 ZXIgZm9yIHN0dWRpZXMgYXQgYSB1bml2ZXJzaXR5LiBCdXQgb25lIGluZGl2aWR1YWwgbWF5IG9u bHkgcmVnaXN0ZXIgb25jZSBhdCB0aGUgc2FtZSB1bml2ZXJzaXR5LiBBbm90aGVyIGNhc2UgaXMg YSB1c2VyJ3MgbGlicmFyeSBhY2NvdW50IHRoYXQgd2FzIGJsb2NrZWQgYmVjYXVzZSBvZiB2aW9s YXRpb25zIG9mIHRoZSBsaWJyYXJ5J3MgdXNhZ2UgdGVybXMuIFN1Y2ggYSB1c2VyIHNob3VsZCBu b3QgYmUgYWJsZSB0byBqdXN0IGNyZWF0ZSBhIG5ldyBhY2NvdW50IHRvIHVzZSB0aGUgbGlicmFy eSBzZXJ2aWNlcyBhZ2Fpbi4NCg0KV2l0aCBKdXN0aW4ncyBzdWdnZXN0aW9uIG9mIGEgUHUgY2F0 ZWdvcnksIHRoZSByZXF1aXJlbWVudHMgaW4gb3VyIHVzZSBjYXNlcyBjb3VsZCBiZSBleHByZXNz ZWQgYXMgUDEuUHUgb3IgUDIuUHUuIFRoZSBzZW1hbnRpY3Mgb2YgIlAyLlB1Ig0Kd291bGQgdGhl biBiZTogUHJvb2ZlZCB1bmlxdWUgYmFzZWQgb24gYW4gYXR0cmlidXRlIHNldCB3aXRoIHRoZSB2 ZXR0aW5nIGxldmVsIFAyLg0KDQpjaGVlcnMNCg0KUm9sZg0KDQoNCg0KT24gMTEuMDMuMTYgMDI6 NTYsIEpvYW5uZSBLbmlnaHQgd3JvdGU6DQo+IEhpIEFsbA0KPg0KPiBUaGVyZSBhcmUgdGhyZWUg YXNwZWN0IG9yIGxldmVscyB3aGVuIGxvb2tpbmcgYXQgdW5pcXVlbmVzcyB0byBiZQ0KPiBjb25z aWRlcmVkLg0KPg0KPiBGaXJzdCBsZXZlbCBpcyB0aGF0IHRoZSBpZGVudGl0eSBpcyB1bmlxdWUg LSB0aGF0IGlzLCB3aXRoaW4gYSBjb250ZXh0DQo+IHRoZXJlIGlzIGEgc2V0IG9mIGF0dHJpYnV0 ZXMgdGhhdCBhcmUgdW5pcXVlIGZvciBlYWNoIGlkZW50aXR5DQo+IHJlZ2lzdGVyZWQuDQo+DQo+ IFNlY29uZCBsZXZlbCBpcyBzb2xlIGNsYWltYW50IC0gdGhpcyBpcyBhIGNoZWNrIHRoYXQgb25s eSBvbmUgZW50aXR5DQo+IGhhcyBjbGFpbWVkIGEgcGFydGljdWxhciBzZXQgb2YgYXR0cmlidXRl cy4gQXQgdGhlIGhpZ2hlciBsZXZlbHMgb2YNCj4gaWRlbnRpdHkgcHJvb2Zpbmcgd2hlcmUgYXV0 aG9yaXRhdGl2ZSBzb3VyY2VzIGFyZSB1c2VkIGl0IG1heSBiZQ0KPiBwb3NzaWJsZSB0byBhY2hp ZXZlIHRoaXMuIFRoaXMgaXMgc3VmZmljaWVudCBpbiBtb3N0IFJQcyBjYXNlcy4gQXQNCj4gdGhp cyBsZXZlbCB3aGlsZSBpdCBpcyBwb3NzaWJsZSBmb3IgYSBzaW5nbGUgZW50aXR5IHRvIGNsYWlt IG1vcmUgdGhhbg0KPiBvbmUgaWRlbnRpdHksIHRoZXkgZG8gc28gYXQgdGhlIHJpc2sgb2YgY2F1 c2luZyBhIGNvdW50ZXItZnJhdWQgZmxhZw0KPiBzaG91bGQgdGhlIHJlYWwgb3duZXIgKG9yIGFu eSBvdGhlciBwYXJ0eSkgYWxzbyBhdHRlbXB0IHRvIGNsYWltIHRoZQ0KPiBpZGVudGl0eS4NCj4N Cj4gVGhlIGZpbmFsIGxldmVsIGlzIG9uZSBhbmQgb25seSBvbmUgLSBUaGlzIGlzIGEgY2hlY2sg LSB1c3VhbGx5DQo+IGJpb21ldHJpYyAtIHRoYXQgYW4gZW50aXR5IGhhcyBvbmx5IG9uZSBjbGFp bSBpbiB0aGUgY29udGV4dC4gVGhpcyBpcw0KPiB1c3VhbGx5IG9ubHkgcmVzZXJ2ZWQgZm9yIHRo ZSBoaWdoZXN0IGxldmVsIG9mIGlkZW50aXR5IGFuZCB3b3VsZCBhbHNvDQo+IHJlcXVpcmUgZXF1 YWxseSBoaWdoIGxldmVscyBvZiBjcmVkZW50aWFsIGFuZCBjcmVkZW50aWFsIGlzc3VhbmNlDQo+ IHByb2Nlc3Nlcy4NCj4NCj4gQXMgdG8gaG93IHRoaXMgcmVsYXRlcyB0byBWb1QgLSBUaGUgZmly c3Qgc2hvdWxkIGJlIGlubmF0ZWx5IGJ1aWx0DQo+IGludG8gYWxsIGxldmVscyBvZiBQIC0gaXQg aXMgdGhlIHNvbGUgcmVxdWlyZW1lbnQgb2YgYWxsIGxldmVscw0KPg0KPiBUaGUgc2Vjb25kIGNv dWxkIGJlIGJ1aWx0IGludG8gUDMgaWYgdGhlIHdvcmRpbmcgd2FzIGFtZW5kZWQgc2xpZ2h0bHku DQo+DQo+IFRoZSBsYXN0IGl0ZW0gb25seSBpcyBzdWJzdGFudGl2ZWx5IG1pc3NpbmcgYW5kIHRv IGRhdGUgKGluIHRoZQ0KPiBjb252ZXJzYXRpb25zIEkgaGF2ZSBiZWVuIGhhdmluZyBlbHNld2hl cmUpIHRoZXJlIGhhcyBiZWVuDQo+IGluc3VmZmljaWVudCBhcHBldGl0ZSB0byBhZGQgaXQgYXMg YW4gZXhwbGljaXQgcmVxdWlyZW1lbnQuDQo+DQo+IFNob3VsZCB3ZSBoYXZlIGEgUFU/IE1heWJl LCBidXQgc3RlZXIgY2xlYXIgb2YgdGhlIHRlcm0gJ3VuaXF1ZScgSWYgd2UNCj4gZG8sIGluIG15 IG1pbmQgaXQgd291bGQgb25seSBoYXZlIHR3byB2YWx1ZXMgLSBQPzAgLSBDbGFpbXMgcGVyIGVu dGl0eQ0KPiBub3QgY2hlY2tlZCwgUD8xIC0gQ2xhaW1zIHBlciBlbnRpdHkgcmVzdHJpY3RlZCB0 byBvbmUuDQo+DQo+IEpvYW5uZQ0KPg0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSBG cm9tOiBSb2xmIEJydWdnZXINCj4gW21haWx0bzpyb2xmLmJydWdnZXJAc3dpdGNoLmNoPG1haWx0 bzpyb2xmLmJydWdnZXJAc3dpdGNoLmNoPl0gU2VudDogRnJpZGF5LCAxMSBNYXJjaCAyMDE2IDU6 NTEgYS5tLg0KPiBUbzogdm90QGlldGYub3JnPG1haWx0bzp2b3RAaWV0Zi5vcmc+IFN1YmplY3Q6 IFtWb1RdIEhvdyB0byBleHByZXNzIGR1cGxpY2F0ZSBjaGVja3Mgd2l0aA0KPiBWb1Q/DQo+DQo+ IEhpIGFsbCwNCj4NCj4gSSdtIG5ldyB0byB0aGlzIGxpc3QgYW5kIEkgaG9wZSBteSBxdWVzdGlv biBpcyBub3QgdG90YWxseSBpcnJlbGV2YW50DQo+IGhlcmUuDQo+DQo+IFdlIGhhdmUgcGxlbnR5 IG9mIHVzZSBjYXNlcyB3aGVyZSBSUHMgbmVlZCB0byBoYXZlIGNvbmZpZGVuY2UsIHRoYXQgYQ0K PiBwZXJzb24gZG9lcyBub3QgaGF2ZSBtdWx0aXBsZSBpZGVudGl0aWVzIGluIG9uZSBJZFAuIEkg ZG9uJ3Qgc2VlIGhvdw0KPiB0aGlzIGFzcGVjdCBvZiBpZGVudGl0eSBxdWFsaXR5IGNhbiBiZSBl eHByZXNzZWQsIGFuZCBJIGJlbGlldmUgaXQgaXMNCj4gcHJldHR5IG9ydGhvZ29uYWwgdG8gdGhl IFAsIEMsIE0gYW5kIEEgZGltZW5zaW9ucyB0aGF0IGFyZSBjdXJyZW50bHkNCj4gc3BlY2lmaWVk IGluIHRoZSBWb1QgZHJhZnQuDQo+DQo+IFdlIGNvdWxkIGltYWdpbmUgbXVsdGlwbGUgd2F5cyB0 byBncmFkdWFsbHkgcHJvdmUgdGhhdCBhbiBpZGVudGl0eSBoYXMNCj4gYmVlbiBjaGVja2VkIGFn YWluc3QgZHVwbGljYXRlcy4gVGhlIG1vc3Qgc3RyYWlnaHRmb3J3YXJkIGFwcHJvYWNoDQo+IHdv dWxkIGJlIHRvIG1ha2Ugc3VyZSB0aGF0IHVuaXF1ZSBwZXJzb25hbCBhdHRyaWJ1dGVzIGFyZSB1 c2VkIG9ubHkNCj4gb25jZSB3aXRoaW4gb25lIElkUCBvciBhbiBJZFAgZmVkZXJhdGlvbiwgbGlr ZSAtIGVtYWlsDQo+IGFkZHJlc3MoZXMpIC0gbW9iaWxlIHBob25lIG51bWJlciAtIGhvbWUgcG9z dGFsIGFkZHJlc3MgLSBzb2NpYWwNCj4gc2VjdXJpdHkgbnVtYmVyIC0gSUQgLyBwYXNzcG9ydCBu dW1iZXIgLSB0aGUgY29tYmluYXRpb24gb2YgbmFtZSBhbmQNCj4gYmlydGggZGF0ZSAtIGV0Yy4N Cj4NCj4gV291bGQgaXQgbWFrZSBzZW5zZSB0byBleHByZXNzIHRoaXMgaW4gVm9UPw0KPg0KPiBi ZXN0IHJlZ2FyZHMNCj4NCj4gUm9sZg0KPg0KPg0KPiAtLSBTV0lUQ0ggLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0gUm9sZiBCcnVnZ2VyLCBwcm9qZWN0IFN3aXNzDQo+IGVkdS1JRCBXZXJkc3Ry YXNzZSAyLCBQLk8uIEJveCwgODAyMSBadXJpY2gsIFN3aXR6ZXJsYW5kIHBob25lICs0MSA0NA0K PiAyNjggMTUgMTUsIGRpcmVjdCArNDEgNDQgMjY4IDE1IDg5PHRlbDolMkI0MSUyMDQ0JTIwMjY4 JTIwMTUlMjA4OT4gcm9sZi5icnVnZ2VyQHN3aXRjaC5jaDxtYWlsdG86cm9sZi5icnVnZ2VyQHN3 aXRjaC5jaD4sDQo+IGh0dHA6Ly93d3cuc3dpdGNoLmNoDQo+DQo+DQo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIHZvdCBtYWlsaW5nIGxpc3QNCj4gdm90 QGlldGYub3JnPG1haWx0bzp2b3RAaWV0Zi5vcmc+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vdm90DQo+DQoNCi0tDQpTV0lUQ0gNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQpSb2xmIEJydWdnZXIsIHByb2plY3QgU3dpc3MgZWR1LUlEDQpXZXJkc3RyYXNzZSAyLCBQ Lk8uIEJveCwgODAyMSBadXJpY2gsIFN3aXR6ZXJsYW5kIHBob25lICs0MSA0NCAyNjggMTUgMTU8 dGVsOiUyQjQxJTIwNDQlMjAyNjglMjAxNSUyMDE1PiwgZGlyZWN0ICs0MSA0NCAyNjggMTUgODk8 dGVsOiUyQjQxJTIwNDQlMjAyNjglMjAxNSUyMDg5PiByb2xmLmJydWdnZXJAc3dpdGNoLmNoPG1h aWx0bzpyb2xmLmJydWdnZXJAc3dpdGNoLmNoPiwgaHR0cDovL3d3dy5zd2l0Y2guY2gNCg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kdm90IG1haWxp bmcgbGlzdA0Kdm90QGlldGYub3JnPG1haWx0bzp2b3RAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3ZvdA0KDQo= --_000_BN3PR0601MB1956E6B81FD35211464C2032FB8C0BN3PR0601MB1956_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uaW0NCgl7bXNvLXN0eWxlLW5hbWU6aW07fQ0Kc3Bhbi5FbWFpbFN0eWxl MTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJU YWhvbWEiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgd291bGQgZXhwZWN0ICh0aG91 Z2ggY291bGQgYmUgd3JvbmcpIHRoYXQgdGhlIGlzc3VlIGlzbuKAmXQganVzdCBpbXBvc3RlcnMs IGJ1dCBhcyBtdWNoIGFib3V0IGVuZm9yY2VtZW50IG9mIHNlcGFyYXRpb24gb2YgZHV0aWVzIGZv ciB0aGUgc2FtZSBlbnRpdHkuIElmIEkNCiBnaXZlIG9uZSBvZiB5b3VyIGFjY291bnRzIHJldmll dyByaWdodHMgYW5kIGFub3RoZXIgYXBwcm92YWwgcmlnaHRzLCB0aGVuIHRoZXJl4oCZcyBhbiBT b0QgaXNzdWUuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNvIHRoZSBvbmx5IHRoaW5nIEkgd2FzIHRoaW5raW5nIHdv dWxkIGJlIHdvcnRoIG1lYXN1cmluZyB3aXRoaW4gdGhlIElkUCBpcyB3aGV0aGVyIHRoZSBMb0Eg cmVnaXN0cmF0aW9uIHByb2Nlc3MgaW5jbHVkZXMgZHVwbGljYXRlIHJlc29sdXRpb24uIEkgZG9u 4oCZdCBrbm93DQogdGhhdCBhbnkgYXNzdXJhbmNlIHByb2ZpbGVzL1ZvVOKAmXMgSeKAmXZlIHNl ZW4gaW5jbHVkZSB0aGF0IGFzIGFuIGV4cGxpY2l0IHJlcXVpcmVtZW50LiBJLmUuLCB3aGF04oCZ cyB0byBzdG9wIG1lIGZyb20gaGF2aW5nIHR3byBhY2NvdW50cyBib3RoIHZldHRlZCB0byBhIHN0 cm9uZyBkZWdyZWUgYW5kIHRoZSBJZFAgZG9lc27igJl0IHJlY29nbml6ZSB0aGVtIGFzIHRoZSBz YW1lIHBlcnNvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJ1dCB5b3VyIHBvaW50IGlzIGNvbXBlbGxpbmc6IElzIGlk ZW50aXR5IG1hdGNoaW5nIGludGVybmFsIHRvIGFuIElkUCB0ZXJyaWJseSBpcnJlbGV2YW50IGlu IGEgZmVkZXJhdGVkIHdvcmxkPyBXaGF0IHZhbHVlIGRvZXMgYW4gUlAgZ2V0IGJ5IGtub3dpbmcg dGhhdCB0aGlzDQogaWRlbnRpdHkgd2FzIGNoZWNrZWQgYWdhaW5zdCBkdXBsaWNhdGlvbiB3aXRo aW4gYW4gSWRQIGlmIEkgY2FuIHNlcGFyYXRlbHkgY3JlYXRlIGFuIGFjY291bnQgKHdpdGggYW4g ZXF1YWxseSBoaWdoIExvQSkgdGhyb3VnaCBhIGNvbXBsZXRlbHkgZGlmZmVyZW50IElkUD8gSSBk b27igJl0IHNlZSB3aGF0IElkUC1tYW5hZ2VkIHRydXN0IG1lYXN1cmUvaW5kaWNhdG9yIGlzIGdv aW5nIHRvIGhlbHAgdW5sZXNzIHlvdSBsaW1pdCB5b3VyIHVzZSBjYXNlcw0KIHRvIHRob3NlIGlu dm9sdmluZyBhIHNpbmdsZSBJZFAsIGluIHdoaWNoIGNhc2UgdGhlIG5lZWQgZm9yIGEgcHJvZmls ZSBhbmQgc3RhbmRhcmRpemF0aW9uIGlzIGxlc3MgcHJlc3NpbmcuDQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi0tLSBF cmljPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+IHZvdCBbbWFpbHRvOnZvdC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9m IDwvYj5KdWxpYW4gV2hpdGU8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBNYXJjaCAxOCwgMjAx NiA2OjE5IEFNPGJyPg0KPGI+VG86PC9iPiBKb2FubmUgS25pZ2h0PGJyPg0KPGI+Q2M6PC9iPiBS b2xmIEJydWdnZXI7IHZvdEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1ZvVF0g SG93IHRvIGV4cHJlc3MgZHVwbGljYXRlIGNoZWNrcyB3aXRoIFZvVD88bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgd291bGQgc2F5LCBhcyBJIGhhdmUgaW4gdGhlIElT TyAyOTAwMyBkaXNjdXNzaW9ucywgdGhhdCB1bmlxdWVuZXNzIGlzIGluIGZhY3QgaXJyZWxldmFu dCBpbiB0ZXJtcyBvZiB0aGUgbGV2ZWwgb2YgcHJvb2ZpbmcuIEkgc2VlIG5vIG5lZWQgdG8ga25v dyB3aGV0aGVyIHRoYXQgc2V0IG9mIGF0dHJpYnV0ZXMgaXMgcHJvdmVuIHRvIGJlIHVuaXF1ZSBi eSB0aGUgcHJvb2ZpbmcgcHJvdmlkZXIuIFVuaXF1ZW5lc3MNCiBpcyBoaWdobHkgZGVwZW5kZW50 IG9uIHRoZSBjb250ZXh0LCB3aGljaCByYWlzZXMgYWxsIHNvcnRzIG9mIHByb2JsZW1zIGlmIHlv dSBoYXZlIGFuIGlkZW50aXR5IGZlZGVyYXRpb24gKGhvdyBkbyBJIGtub3cgaXRzIHVuaXF1ZSBh Y3Jvc3MgdGhlIGZlZGVyYXRpb24/IElmLCBhcyBhbiBSUCwgSSBjYW4gY2FuIGNvcGUgd2l0aCBu b24tdW5pcXVlbmVzcyBhY3Jvc3MgdGhlIGZlZGVyYXRpb24gdGhlbiZuYnNwO25vbi11bmlxdWVu ZXNzJm5ic3A7d2l0aGluIHRoZQ0KIHByb29maW5nIHByb3ZpZGVyIGlzIGFsc28gbm90IGEgcHJv YmxlbSkuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBt eSB2aWV3IGl0IGlzIGZvciB0aGUgUlAsIG9yIGlkZW50aXR5IGZlZGVyYXRpb24gc2NoZW1lLCB0 byBkZWNpZGUgd2hpY2ggYXR0cmlidXRlcyBhcmUgcmVxdWlyZWQgaW4gdGhlaXIgY29udGV4dC4g VGhleSBzZWxlY3Qgc3VmZmljaWVudCBhdHRyaWJ1dGVzIHRoYXQgZ2l2ZSB0aGVtIHVuaXF1ZW5l c3MgKGluIHRoZWlyIGNvbnRleHQpIGlmIHRoYXQgaXMgcmVxdWlyZWQsIGUuZy4gU1NOIGZvciBz b21lDQogc2VydmljZXMgKHRob3VnaCBJIHdvdWxkIGFkdmlzZSBhZ2FpbnN0IGl0ISkuIFRoZSBw dXJwb3NlIG9mIHRoZSBwcm9vZmluZyBwcm9jZXNzIGlzIHRvIGV4cHJlc3MgdG8gd2hhdCBsZXZl bCBvZiBjb25maWRlbmNlIHRoYXQgdGhvc2UgYXR0cmlidXRlcyBhcmUgdHJ1ZSBhbmQgYmVsb25n IHRvIHRoZSBwZXJzb24gcHJlc2VudGluZyB0aGVtLCBiZSB0aGV5IG5hbWUsIGFkZHJlc3MsIGRv YiwgZW1haWwgYWRkcmVzcywgU1NOIGV0Yy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gbXkgZGVhbGluZ3Mgd2l0aCBSUHMgdGhleSBhcmUg Y29uZnVzZWQgYWJvdXQgdGhpcyBhbmQgYXNrIGZvciAmcXVvdDt1bmlxdWVuZXNzJnF1b3Q7LCB0 aGlzIGlzIHVzdWFsbHkgZm9sbG93ZWQgdXAgd2l0aCAmcXVvdDtiZWNhdXNlIHdlIGNhbid0IGxl dCBwZW9wbGUgcmVnaXN0ZXIgbXVsdGlwbGUgaWRlbnRpdGllcyZxdW90Oy4gVGhlcmUgaXMgYSBs YWNrIG9mIHVuZGVyc3RhbmRpbmcgdGhhdCwgYXNzdW1pbmcgdGhlIHByb29maW5nIHByb2Nlc3MN CiBpcyB3b3JraW5nIGNvcnJlY3RseSwgaXQgZG9lc24ndCBtYXR0ZXIgaG93IG1hbnkgdGltZXMg eW91IGVucm9sIHlvdSBhcmUgcHJvdmVuIHRvIGJlIHRoZSBzYW1lIHBlcnNvbiBlYWNoIHRpbWU7 IGkuZS4gbXVsdGlwbGUgZW5yb2xtZW50cyBsZWFkIHRvIHRoZSBpZGVudGlmaWNhdGlvbiBvZiB0 aGUgc2FtZSBwZXJzb24gYmVpbmcgYm91bmQgdG8gdGhlIHNhbWUgYXR0cmlidXRlcy4gVGhlcmVm b3JlIGl0IGlzbid0IGFjdHVhbGx5IGEgcHJvYmxlbQ0KIGluIHRlcm1zIG9mIHVuaXF1ZW5lc3Mu Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk1vcmUgb2Z0ZW4gdGhhbiBub3QgdGhlIGFzayBmb3IgdW5pcXVlbmVzcyBpcyByZWFsbHkg YW4gZXhwcmVzc2lvbiBvZiBob3cgd2VsbCB0aGUgc3lzdGVtIGRlZmVuZHMgaXRzZWxmIGFnYWlu c3QgaW1wb3N0b3JzIChkaWZmZXJlbnQgcGVvcGxlIHJlZ2lzdGVyaW5nIGZvciB0aGUgc2FtZSBh dHRyaWJ1dGVzKSB3aGljaCBpcyBhY3R1YWxseSB0aGUgcG9pbnQgb2YgdGhlIGRpZmZlcmVudCBs ZXZlbHMgb2YgcHJvb2ZpbmcNCiAodGhlIGhpZ2hlciB0aGUgbGV2ZWxzIG9mIHByb29maW5nIHRo ZSBoYXJkZXIgdGhpcyBzaG91bGQgYmVjb21lKS4gRGVtYW5kaW5nIHVuaXF1ZW5lc3MgZG9lc24n dCBhY3R1YWxseSBmaXggdGhlIGltcG9zdG9yIHByb2JsZW0sIHlvdSBqdXN0IGludHJvZHVjZSBh IHRpbWUgdHJpYWwgdG8gdGhlIHByb2Nlc3M7IHRoZSBmaXJzdCBwZXJzb24gdG8gZ2V0IGJvdW5k IHRvIHRob3NlIGF0dHJpYnV0ZXMgbG9ja3Mgb3V0IG90aGVyIHBlb3BsZTsgaWYNCiB0aGUgZmly c3QgcGVyc29uIHRvIGNsYWltIHRoZW0gd2FzIHRoZSBpbXBvc3RvciB5b3UndmUgbm93IGxvY2tl ZCBvdXQgdGhlIGdlbnVpbmUgcGVyc29uIC0gdGhleSBub3cgaGF2ZSBhIGhlbGwgb2YgdGltZSB1 bnBpY2tpbmcgYSBtZXNzIG5vdCBvZiB0aGVpciBtYWtpbmcuIElmIHRoZSBzeXN0ZW0gZGVmZW5k cyBhZ2FpbnN0IGltcG9zdG9ycyBwcm9wZXJseSBhdCB0aGUgaGlnaGVyIGxldmVscyB0aGVuIHRo ZSB1bmlxdWVuZXNzIGFkZHMgbGl0dGxlDQogdmFsdWUgc2luY2UgSSBjYW4gb25seSBiaW5kIHRo b3NlIGF0dHJpYnV0ZXMgdG8gdGhlIGNvcnJlY3QgcGVyc29uIGFueXdheS48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHRoaW5nIHRoYXQg bWF5IG5lZWQgdG8gYmUgdW5pcXVlIGlzIHRoZSBhY2NvdW50L3JlY29yZCBhdCB0aGUgUlAsIGFu ZCBpdHMgdGhlIFJQJ3MgcmVzcG9uc2liaWxpdHkgdG8gbWFuYWdlIHRoYXQuIFRoaXMgaXMgYSBw cm9ibGVtIHRoZXkgaGF2ZSByZWdhcmRsZXNzIG9mIHdoZXRoZXIgdGhlIHByb29maW5nIHByb3Zp ZGVyIHRlbGxzIHRoZW0gaXRzIHVuaXF1ZSBvciBub3QgYmVjYXVzZSB0aGV5IG9mdGVuDQogaGF2 ZSBtdWx0aXBsZSBvbi1saW5lIGFuZCBvZmZsaW5lIGNoYW5uZWxzIHRoYXQgZGVhbCB3aXRoIHRo ZWlyIGN1c3RvbWVycywgdGhpcyBmb3JjZXMgdGhlbSB0byB1bmRlcnN0YW5kIGhvdyB0byBtYXRj aCBkaWZmZXJlbnQgcmVwcmVzZW50YXRpb25zIG9mIHRoZSBpZGVudGl0eSB0byB0aGUgc2FtZSBh Y2NvdW50IHdoaWNoIHRlbmRzIHRvIHdvcmsgYWNyb3NzIGNoYW5uZWwgYW5kIHdpdGhpbiB0aGUg c2FtZSBjaGFubmVsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5TbyBpbiBzdW1tYXJ5IGl0IGRvZXNuJ3QgZHJpdmUgYW55IHJlYWwgdmFsdWUg aW4gdGhlIHByb29maW5nIHByb3ZpZGVyIHRvIGRvIHRoaXMsIGl0cyBqdXN0IGEgY29zdCBvZiBl ZmZvcnQgZm9yIGxpdHRsZSBnYWluIHRoYXQgdGhlIFJQIGlzIGdvaW5nIHRvIHJlcGVhdCByZWdh cmRsZXNzIGlmIHRoZXkgY2FyZSBhYm91dCB1bmlxdWVuZXNzLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5KdWxpYW4uPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDE3 IE1hcmNoIDIwMTYgYXQgMjE6NDksIEpvYW5uZSBLbmlnaHQgJmx0OzxhIGhyZWY9Im1haWx0bzpK b2FubmUuS25pZ2h0QGRpYS5nb3Z0Lm56IiB0YXJnZXQ9Il9ibGFuayI+Sm9hbm5lLktuaWdodEBk aWEuZ292dC5uejwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhlIHNob3J0IGFuc3dlciB0byB5b3VyIHF1ZXN0aW9uIC0gTm8uPGJyPg0KPGJyPg0K WW91ciB1c2UgY2FzZSBpcyBzaWxlbnQgb24gdGhlIGxldmVsIG9mIHZldHRpbmcgcmVxdWlyZWQg KGhvdyByZWFsIGRvZXMgdGhlIGlkZW50aXR5IGhhdmUgdG8gYmUpLiBZb3UgY2FuIGhhdmUgYW55 IGxldmVsIG9mIGlkZW50aXR5IGFuZCBzdGlsbCBjb2xsZWN0IGEgYmlvbWV0cmljIGZvciB0aGUg cHVycG9zZXMgb2Ygb25lIGFuZCBvbmx5IG9uZSB1bmlxdWVuZXNzLiBJIHdvdWxkIHBvc2UgaG93 ZXZlciB0aGF0IGl0IGlzIHZlcnkgdW51c3VhbA0KIGZvciBvbmUgYW5kIG9ubHkgb25lIGFzc3Vy YW5jZSB0byBiZSByZXF1aXJlZCB3aXRob3V0IHNvbWUgb3RoZXIgZHJpdmVyIHJlcXVpcmluZyBh biBlbGV2YXRlZCBsZXZlbCBvZiByZWFsbmVzcy48YnI+DQo8YnI+DQpJbiB5b3VyIHVzZSBjYXNl IEkgd291bGQgc3VnZ2VzdCB0aGF0IHRoZXJlIGlzIGFsc28gYSByZXF1aXJlbWVudCB0aGF0IGEg cXVhbGlmaWNhdGlvbiBpcyBpc3N1ZWQgdG88YnI+DQphKSB0aGUgcGVyc29uIGNhcnJ5aW5nIG91 dCB0aGUgc3R1ZHkgYW5kPGJyPg0KYikgYW4gaWRlbnRpdHkgb2Ygc3VjaCByaWdvdXIgdGhhdCB0 aGVpciAob3IgdGhlIHVuaXZlcnNpdHkncykgZWxpZ2liaWxpdHkgZm9yIHB1YmxpYyBmdW5kaW5n IGNhbiBiZSBlc3RhYmxpc2hlZCBhbmQ8YnI+DQpjKSBhbiBpZGVudGl0eSB0aGF0IGlzIGdvaW5n IHRvIGJlIHRlc3RlZCBieSBmdXR1cmUgZW1wbG95ZXJzLjxicj4NCjxicj4NClRoZXJlZm9yZSB5 b3UgYXJlIHByb2JhYmx5IGxvb2tpbmcgYXQgUDIgb3IgUDMgZGVwZW5kaW5nIG9uIHRoZSBsZXZl bC90eXBlIG9mIHF1YWxpZmljYXRpb24uIChJIG1pZ2h0IHdhbnQgUDMgaWYgdGhlIHF1YWxpZmlj YXRpb24gaXMgZm9yIGJyYWluIHN1cmdlb24gb3IgY29tbWVyY2lhbCBwaWxvdCkuPGJyPg0KPGJy Pg0KQXMgb25lIGFuZCBvbmx5IG9uZSBpcyByZWFsbHkgb25seSBhYmxlIHRvIGJlIGFjaGlldmVk IHRocm91Z2ggdGhlIHVzZSBvZiBhIGJpb21ldHJpYywgd2Ugbm93IGhhdmUgdG8gY29uc2lkZXIg J2FjY2VwdGFiaWxpdHknLjxicj4NCkRvZXMgdGhlIGNvbGxlY3Rpb24gb2YgYSBiaW9tZXRyaWMg KGFuZCBhbGwgdGhhdCBpdCBlbnRhaWxzIC0gY29zdCwgcHJpdmFjeSwgc2VjdXJpdHksIHVzZXIg YWNjZXB0YW5jZSBldGMuKSBvdXR3ZWlnaCB0aGUgaW1wYWN0IGNhdXNlZCBieSBhIGR1cGxpY2F0 ZSBlbnRpdHkgaW4gdGhlIHN5c3RlbT88YnI+DQpJbiBvdGhlciB3b3JkcywgZG8geW91IHJlYWxs eSBuZWVkIG9uZSBhbmQgb25seSBvbmUgKHRoZSAzcmQgbGV2ZWwgb2YgdW5pcXVlbmVzcykgb3Ig Y291bGQgc3VmZmljaWVudCBzaW5ndWxhcml0eSBiZSBnYWluZWQgZnJvbSBsZXZlcmFnaW5nIHRo ZSBzb2NpYWwgc2VjdXJpdHkgbnVtYmVyJ3MgdW5pcXVlbmVzcyBhbmQgYW4gZXF1aXZhbGVudCBs ZXZlbCBvZiB2YWxpZGF0aW9uIGFuZCBvd25lcnNoaXAgdGVzdCAodGhlIDJuZCBsZXZlbCBvZiB1 bmlxdWVuZXNzKQ0KIGkuZS4gbm8gUHU/PGJyPg0KPGJyPg0KV2UgbXVzdCByZW1lbWJlciB0aGUg bXV0dWFsIGV4Y2x1c2l2aXR5IGJldHdlZW4gYXR0cmlidXRlcyBjb2xsZWN0ZWQsIHZldHRpbmcg dW5kZXIgdGFrZW4gYW5kIGxldmVsIG9mIHVuaXF1ZW5lc3MuPGJyPg0KPGJyPg0KSGFwcHkgdG8g ZGlzY3VzcyBmdXJ0aGVyIGlmIHRoaXMgbWFrZXMgbm8gc2Vuc2UuPGJyPg0KPGJyPg0KQ2hlZXJz PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPHNwYW4gY2xhc3M9ImltIj4tLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLTwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iaW0iPkZyb206IFJvbGYgQnJ1Z2dl ciBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpyb2xmLmJydWdnZXJAc3dpdGNoLmNoIj5yb2xmLmJy dWdnZXJAc3dpdGNoLmNoPC9hPl08L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNlbnQ6IFRodXJzZGF5LCAxNyBNYXJjaCAyMDE2IDExOjM1 IHAubS48YnI+DQpUbzogPGEgaHJlZj0ibWFpbHRvOnZvdEBpZXRmLm9yZyI+dm90QGlldGYub3Jn PC9hPjxicj4NClN1YmplY3Q6IFJlOiBbVm9UXSBIb3cgdG8gZXhwcmVzcyBkdXBsaWNhdGUgY2hl Y2tzIHdpdGggVm9UPzxicj4NCjxicj4NCkhpIGFsbCw8YnI+DQo8YnI+DQpUaGFua3MgZm9yIGFs bCB5b3VyIHJlc3BvbnNlcyBhbmQgaWRlYXMuIFdlIGhhdmUgZGlzY3Vzc2VkIHlvdXIgaW5wdXRz IGluIG91ciBwcm9qZWN0IHRlYW0gKHdoaWNoIGlzIHdoeSBpdCB0b29rIG1lIHNvbWUgdGltZSB0 byByZXNwb25kKTxicj4NCjxicj4NCkkgd2FzIHdvbmRlcmluZyB3aGF0IGFjdHVhbGx5IHRoZSBk aWZmZXJlbmNlcyBhcmUgYmV0d2VlbiB0aGUgdGhyZWUgbGV2ZWxzIG9mIHVuaXF1ZW5lc3MgZGVz Y3JpYmVkIGJ5IEpvYW5uZS4gSW4gZWFjaCBvZiB0aGUgdGhyZWUgbGV2ZWxzIGEgc2V0IG9mIGF0 dHJpYnV0ZXMgaXMgdXNlZCB0byBkZXRlcm1pbmUgaWYgYW4gaWRlbnRpdHkgaXMgdW5pcXVlIHdp dGhpbiBhIHBvcHVsYXRpb24gb2YgaWRlbnRpdGllcy4gVGhlIGRpZmZlcmVuY2UgaXMNCiAxKSB3 aGF0IGV4YWN0IHNldCBvZiBhdHRyaWJ1dGVzIGlzIHVzZWQgaW4gZWFjaCBsZXZlbCBhbmQgMikg dGhlIHZldHRpbmcgbGV2ZWwgb2YgdGhlIGF0dHJpYnV0ZXMuIFJpZ2h0Pzxicj4NCjxicj4NCkEg Y29uY3JldGUgZXhhbXBsZSBtaWdodCBiZTxicj4NCjxicj4NCkZpcnN0IGxldmVsOjxicj4NCi0g YXR0cmlidXRlczogTmFtZSwgZW1haWwsIHBob25lIG51bWJlcjxicj4NCi0gdmV0dGluZyBsZXZl bDogUDE8YnI+DQo8YnI+DQpTZWNvbmQgbGV2ZWw6PGJyPg0KLSBhdHRyaWJ1dGVzOiBOYW1lLCBl bWFpbCwgcGhvbmUgbnVtYmVyLCBzb2NpYWwgc2VjdXJpdHkgbnVtYmVyPGJyPg0KLSB2ZXR0aW5n IGxldmVsOiBQMjxicj4NCjxicj4NClRoaXJkIGxldmVsOjxicj4NCi0gYXR0cmlidXRlczogZmlu Z2VyIHByaW50IG9yIHJldGluYSBzY2FuPGJyPg0KLSB2ZXR0aW5nIGxldmVsOiBQMzxicj4NCjxi cj4NClRoZSBhcHByb3ByaWF0ZSBzZXQgb2YgYXR0cmlidXRlcyB0byBiZSB1c2VkIGluIGVhY2gg bGV2ZWwgaXMgY2VydGFpbmx5IGNvbnRleHQtc3BlY2lmaWMuIEFzIEVyaWMgcG9pbnRzIG91dCBp dCB3aWxsIGJlIGRpZmZpY3VsdCB0byBkZWZpbmUgYW5kIGFncmVlIG9uIGEgZ2VuZXJpYyBkZWZp bml0aW9uIG9mIHRoZSBzY29wZS48YnI+DQo8YnI+DQpNYXliZSBpdCdzIHRpbWUgdG8gZGVzY3Jp YmUgb3VyIHVzZSBjYXNlcyBoZXJlLiBJbiB0aGUgSWRNIHNlcnZpY2Ugd2UgYXJlIHBsYW5uaW5n IGluZGl2aWR1YWxzIHNlbGYtcmVnaXN0ZXIgdGhlaXIgaWRlbnRpdGllcy4gV2l0aCBzdWNoIGFu IGlkZW50aXR5LCBpbmRpdmlkdWFscyBjYW4gcmVnaXN0ZXIgZm9yIHN0dWRpZXMgYXQgYSB1bml2 ZXJzaXR5LiBCdXQgb25lIGluZGl2aWR1YWwgbWF5IG9ubHkgcmVnaXN0ZXIgb25jZSBhdCB0aGUg c2FtZQ0KIHVuaXZlcnNpdHkuIEFub3RoZXIgY2FzZSBpcyBhIHVzZXIncyBsaWJyYXJ5IGFjY291 bnQgdGhhdCB3YXMgYmxvY2tlZCBiZWNhdXNlIG9mIHZpb2xhdGlvbnMgb2YgdGhlIGxpYnJhcnkn cyB1c2FnZSB0ZXJtcy4gU3VjaCBhIHVzZXIgc2hvdWxkIG5vdCBiZSBhYmxlIHRvIGp1c3QgY3Jl YXRlIGEgbmV3IGFjY291bnQgdG8gdXNlIHRoZSBsaWJyYXJ5IHNlcnZpY2VzIGFnYWluLjxicj4N Cjxicj4NCldpdGggSnVzdGluJ3Mgc3VnZ2VzdGlvbiBvZiBhIFB1IGNhdGVnb3J5LCB0aGUgcmVx dWlyZW1lbnRzIGluIG91ciB1c2UgY2FzZXMgY291bGQgYmUgZXhwcmVzc2VkIGFzIFAxLlB1IG9y IFAyLlB1LiBUaGUgc2VtYW50aWNzIG9mICZxdW90O1AyLlB1JnF1b3Q7PGJyPg0Kd291bGQgdGhl biBiZTogUHJvb2ZlZCB1bmlxdWUgYmFzZWQgb24gYW4gYXR0cmlidXRlIHNldCB3aXRoIHRoZSB2 ZXR0aW5nIGxldmVsIFAyLjxicj4NCjxicj4NCmNoZWVyczxicj4NCjxicj4NClJvbGY8YnI+DQo8 YnI+DQo8YnI+DQo8YnI+DQpPbiAxMS4wMy4xNiAwMjo1NiwgSm9hbm5lIEtuaWdodCB3cm90ZTo8 YnI+DQomZ3Q7IEhpIEFsbDxicj4NCiZndDs8YnI+DQomZ3Q7IFRoZXJlIGFyZSB0aHJlZSBhc3Bl Y3Qgb3IgbGV2ZWxzIHdoZW4gbG9va2luZyBhdCB1bmlxdWVuZXNzIHRvIGJlPGJyPg0KJmd0OyBj b25zaWRlcmVkLjxicj4NCiZndDs8YnI+DQomZ3Q7IEZpcnN0IGxldmVsIGlzIHRoYXQgdGhlIGlk ZW50aXR5IGlzIHVuaXF1ZSAtIHRoYXQgaXMsIHdpdGhpbiBhIGNvbnRleHQ8YnI+DQomZ3Q7IHRo ZXJlIGlzIGEgc2V0IG9mIGF0dHJpYnV0ZXMgdGhhdCBhcmUgdW5pcXVlIGZvciBlYWNoIGlkZW50 aXR5PGJyPg0KJmd0OyByZWdpc3RlcmVkLjxicj4NCiZndDs8YnI+DQomZ3Q7IFNlY29uZCBsZXZl bCBpcyBzb2xlIGNsYWltYW50IC0gdGhpcyBpcyBhIGNoZWNrIHRoYXQgb25seSBvbmUgZW50aXR5 PGJyPg0KJmd0OyBoYXMgY2xhaW1lZCBhIHBhcnRpY3VsYXIgc2V0IG9mIGF0dHJpYnV0ZXMuIEF0 IHRoZSBoaWdoZXIgbGV2ZWxzIG9mPGJyPg0KJmd0OyBpZGVudGl0eSBwcm9vZmluZyB3aGVyZSBh dXRob3JpdGF0aXZlIHNvdXJjZXMgYXJlIHVzZWQgaXQgbWF5IGJlPGJyPg0KJmd0OyBwb3NzaWJs ZSB0byBhY2hpZXZlIHRoaXMuIFRoaXMgaXMgc3VmZmljaWVudCBpbiBtb3N0IFJQcyBjYXNlcy4g QXQ8YnI+DQomZ3Q7IHRoaXMgbGV2ZWwgd2hpbGUgaXQgaXMgcG9zc2libGUgZm9yIGEgc2luZ2xl IGVudGl0eSB0byBjbGFpbSBtb3JlIHRoYW48YnI+DQomZ3Q7IG9uZSBpZGVudGl0eSwgdGhleSBk byBzbyBhdCB0aGUgcmlzayBvZiBjYXVzaW5nIGEgY291bnRlci1mcmF1ZCBmbGFnPGJyPg0KJmd0 OyBzaG91bGQgdGhlIHJlYWwgb3duZXIgKG9yIGFueSBvdGhlciBwYXJ0eSkgYWxzbyBhdHRlbXB0 IHRvIGNsYWltIHRoZTxicj4NCiZndDsgaWRlbnRpdHkuPGJyPg0KJmd0Ozxicj4NCiZndDsgVGhl IGZpbmFsIGxldmVsIGlzIG9uZSBhbmQgb25seSBvbmUgLSBUaGlzIGlzIGEgY2hlY2sgLSB1c3Vh bGx5PGJyPg0KJmd0OyBiaW9tZXRyaWMgLSB0aGF0IGFuIGVudGl0eSBoYXMgb25seSBvbmUgY2xh aW0gaW4gdGhlIGNvbnRleHQuIFRoaXMgaXM8YnI+DQomZ3Q7IHVzdWFsbHkgb25seSByZXNlcnZl ZCBmb3IgdGhlIGhpZ2hlc3QgbGV2ZWwgb2YgaWRlbnRpdHkgYW5kIHdvdWxkIGFsc288YnI+DQom Z3Q7IHJlcXVpcmUgZXF1YWxseSBoaWdoIGxldmVscyBvZiBjcmVkZW50aWFsIGFuZCBjcmVkZW50 aWFsIGlzc3VhbmNlPGJyPg0KJmd0OyBwcm9jZXNzZXMuPGJyPg0KJmd0Ozxicj4NCiZndDsgQXMg dG8gaG93IHRoaXMgcmVsYXRlcyB0byBWb1QgLSBUaGUgZmlyc3Qgc2hvdWxkIGJlIGlubmF0ZWx5 IGJ1aWx0PGJyPg0KJmd0OyBpbnRvIGFsbCBsZXZlbHMgb2YgUCAtIGl0IGlzIHRoZSBzb2xlIHJl cXVpcmVtZW50IG9mIGFsbCBsZXZlbHM8YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGUgc2Vjb25kIGNv dWxkIGJlIGJ1aWx0IGludG8gUDMgaWYgdGhlIHdvcmRpbmcgd2FzIGFtZW5kZWQgc2xpZ2h0bHku PGJyPg0KJmd0Ozxicj4NCiZndDsgVGhlIGxhc3QgaXRlbSBvbmx5IGlzIHN1YnN0YW50aXZlbHkg bWlzc2luZyBhbmQgdG8gZGF0ZSAoaW4gdGhlPGJyPg0KJmd0OyBjb252ZXJzYXRpb25zIEkgaGF2 ZSBiZWVuIGhhdmluZyBlbHNld2hlcmUpIHRoZXJlIGhhcyBiZWVuPGJyPg0KJmd0OyBpbnN1ZmZp Y2llbnQgYXBwZXRpdGUgdG8gYWRkIGl0IGFzIGFuIGV4cGxpY2l0IHJlcXVpcmVtZW50Ljxicj4N CiZndDs8YnI+DQomZ3Q7IFNob3VsZCB3ZSBoYXZlIGEgUFU/IE1heWJlLCBidXQgc3RlZXIgY2xl YXIgb2YgdGhlIHRlcm0gJ3VuaXF1ZScgSWYgd2U8YnI+DQomZ3Q7IGRvLCBpbiBteSBtaW5kIGl0 IHdvdWxkIG9ubHkgaGF2ZSB0d28gdmFsdWVzIC0gUD8wIC0gQ2xhaW1zIHBlciBlbnRpdHk8YnI+ DQomZ3Q7IG5vdCBjaGVja2VkLCBQPzEgLSBDbGFpbXMgcGVyIGVudGl0eSByZXN0cmljdGVkIHRv IG9uZS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBKb2FubmU8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4N CiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gRnJvbTogUm9sZiBCcnVnZ2VyPGJyPg0K Jmd0OyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpyb2xmLmJydWdnZXJAc3dpdGNoLmNoIj5yb2xm LmJydWdnZXJAc3dpdGNoLmNoPC9hPl0gU2VudDogRnJpZGF5LCAxMSBNYXJjaCAyMDE2IDU6NTEg YS5tLjxicj4NCiZndDsgVG86IDxhIGhyZWY9Im1haWx0bzp2b3RAaWV0Zi5vcmciPnZvdEBpZXRm Lm9yZzwvYT4gU3ViamVjdDogW1ZvVF0gSG93IHRvIGV4cHJlc3MgZHVwbGljYXRlIGNoZWNrcyB3 aXRoPGJyPg0KJmd0OyBWb1Q/PGJyPg0KJmd0Ozxicj4NCiZndDsgSGkgYWxsLDxicj4NCiZndDs8 YnI+DQomZ3Q7IEknbSBuZXcgdG8gdGhpcyBsaXN0IGFuZCBJIGhvcGUgbXkgcXVlc3Rpb24gaXMg bm90IHRvdGFsbHkgaXJyZWxldmFudDxicj4NCiZndDsgaGVyZS48YnI+DQomZ3Q7PGJyPg0KJmd0 OyBXZSBoYXZlIHBsZW50eSBvZiB1c2UgY2FzZXMgd2hlcmUgUlBzIG5lZWQgdG8gaGF2ZSBjb25m aWRlbmNlLCB0aGF0IGE8YnI+DQomZ3Q7IHBlcnNvbiBkb2VzIG5vdCBoYXZlIG11bHRpcGxlIGlk ZW50aXRpZXMgaW4gb25lIElkUC4gSSBkb24ndCBzZWUgaG93PGJyPg0KJmd0OyB0aGlzIGFzcGVj dCBvZiBpZGVudGl0eSBxdWFsaXR5IGNhbiBiZSBleHByZXNzZWQsIGFuZCBJIGJlbGlldmUgaXQg aXM8YnI+DQomZ3Q7IHByZXR0eSBvcnRob2dvbmFsIHRvIHRoZSBQLCBDLCBNIGFuZCBBIGRpbWVu c2lvbnMgdGhhdCBhcmUgY3VycmVudGx5PGJyPg0KJmd0OyBzcGVjaWZpZWQgaW4gdGhlIFZvVCBk cmFmdC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBXZSBjb3VsZCBpbWFnaW5lIG11bHRpcGxlIHdheXMg dG8gZ3JhZHVhbGx5IHByb3ZlIHRoYXQgYW4gaWRlbnRpdHkgaGFzPGJyPg0KJmd0OyBiZWVuIGNo ZWNrZWQgYWdhaW5zdCBkdXBsaWNhdGVzLiBUaGUgbW9zdCBzdHJhaWdodGZvcndhcmQgYXBwcm9h Y2g8YnI+DQomZ3Q7IHdvdWxkIGJlIHRvIG1ha2Ugc3VyZSB0aGF0IHVuaXF1ZSBwZXJzb25hbCBh dHRyaWJ1dGVzIGFyZSB1c2VkIG9ubHk8YnI+DQomZ3Q7IG9uY2Ugd2l0aGluIG9uZSBJZFAgb3Ig YW4gSWRQIGZlZGVyYXRpb24sIGxpa2UgLSBlbWFpbDxicj4NCiZndDsgYWRkcmVzcyhlcykgLSBt b2JpbGUgcGhvbmUgbnVtYmVyIC0gaG9tZSBwb3N0YWwgYWRkcmVzcyAtIHNvY2lhbDxicj4NCiZn dDsgc2VjdXJpdHkgbnVtYmVyIC0gSUQgLyBwYXNzcG9ydCBudW1iZXIgLSB0aGUgY29tYmluYXRp b24gb2YgbmFtZSBhbmQ8YnI+DQomZ3Q7IGJpcnRoIGRhdGUgLSBldGMuPGJyPg0KJmd0Ozxicj4N CiZndDsgV291bGQgaXQgbWFrZSBzZW5zZSB0byBleHByZXNzIHRoaXMgaW4gVm9UPzxicj4NCiZn dDs8YnI+DQomZ3Q7IGJlc3QgcmVnYXJkczxicj4NCiZndDs8YnI+DQomZ3Q7IFJvbGY8YnI+DQom Z3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgLS0gU1dJVENIIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tIFJvbGYgQnJ1Z2dlciwgcHJvamVjdCBTd2lzczxicj4NCiZndDsgZWR1LUlEIFdlcmRzdHJh c3NlIDIsIFAuTy4gQm94LCA4MDIxIFp1cmljaCwgU3dpdHplcmxhbmQgcGhvbmUgJiM0Mzs0MSA0 NDxicj4NCiZndDsgMjY4IDE1IDE1LCBkaXJlY3QgPGEgaHJlZj0idGVsOiUyQjQxJTIwNDQlMjAy NjglMjAxNSUyMDg5Ij4mIzQzOzQxIDQ0IDI2OCAxNSA4OTwvYT4NCjxhIGhyZWY9Im1haWx0bzpy b2xmLmJydWdnZXJAc3dpdGNoLmNoIj5yb2xmLmJydWdnZXJAc3dpdGNoLmNoPC9hPiw8YnI+DQom Z3Q7IDxhIGhyZWY9Imh0dHA6Ly93d3cuc3dpdGNoLmNoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDov L3d3dy5zd2l0Y2guY2g8L2E+PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIHZvdCBtYWlsaW5nIGxpc3Q8 YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzp2b3RAaWV0Zi5vcmciPnZvdEBpZXRmLm9yZzwvYT4g PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92b3QiIHRhcmdl dD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdm90PC9h Pjxicj4NCiZndDs8YnI+DQo8YnI+DQotLTxicj4NClNXSVRDSDxicj4NCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tPGJyPg0KUm9sZiBCcnVnZ2VyLCBwcm9qZWN0IFN3aXNzIGVkdS1JRDxicj4N CldlcmRzdHJhc3NlIDIsIFAuTy4gQm94LCA4MDIxIFp1cmljaCwgU3dpdHplcmxhbmQgcGhvbmUg PGEgaHJlZj0idGVsOiUyQjQxJTIwNDQlMjAyNjglMjAxNSUyMDE1Ij4NCiYjNDM7NDEgNDQgMjY4 IDE1IDE1PC9hPiwgZGlyZWN0IDxhIGhyZWY9InRlbDolMkI0MSUyMDQ0JTIwMjY4JTIwMTUlMjA4 OSI+JiM0Mzs0MSA0NCAyNjggMTUgODk8L2E+DQo8YSBocmVmPSJtYWlsdG86cm9sZi5icnVnZ2Vy QHN3aXRjaC5jaCI+cm9sZi5icnVnZ2VyQHN3aXRjaC5jaDwvYT4sIDxhIGhyZWY9Imh0dHA6Ly93 d3cuc3dpdGNoLmNoIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vd3d3LnN3aXRjaC5jaDwvYT48 YnI+DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCnZvdCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86dm90QGll dGYub3JnIj52b3RAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby92b3QiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3ZvdDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BN3PR0601MB1956E6B81FD35211464C2032FB8C0BN3PR0601MB1956_-- From nobody Sun Mar 20 12:46:32 2016 Return-Path: X-Original-To: vot@ietfa.amsl.com Delivered-To: vot@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A06812D611 for ; Sun, 20 Mar 2016 12:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nz.smxemail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44zh9nBbfDHl for ; Sun, 20 Mar 2016 12:46:28 -0700 (PDT) Received: from out1103.nz.smxemail.com (out1103.nz.smxemail.com [203.84.134.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 73C3A12D547 for ; Sun, 20 Mar 2016 12:46:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=nz.smxemail.com; s=alpha; c=relaxed/relaxed; q=dns/txt; i=@nz.smxemail.com; t=1458503185; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC; bh=2SleVPePu+fqS1o7Wq52l4FwSOjHthdM6d8+nof0ZIc=; b=S16c+gh3j0+8TIN/5bZotJjs8/ZGyXLclTKmAEreT+hpLaAM9uVt+qWyvDeVq+LV MVbboFrHOmNdCb6kAV9aa1bxynQ35Qu+l2B4cuNzIKBy8xJ9sCQm4oz7WObJcKMM 7JGLQGswk298BKjK5aoYBPE4+G4cMtEcRPt4bMeeCww=; Received: from smtp.dia.govt.nz ([131.203.48.73]) by omr.nz.smxemail.com with ESMTP (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) id 56EEFE0F-63E40E25@mta1103.omr; Sun, 20 Mar 2016 19:46:23 +0000 Received: from 161-65-142-21.ip.fx.net.nz (EHLO WLGPRDMM01.dia.govt.nz) ([161.65.142.21]) by s111-0006-lnv01 (Liverton Technology Group - SmartGate) with ESMTP ID 2074008838; Mon, 21 Mar 2016 08:46:20 +1300 (NZDT) Received: from AklDrCas02.dia.govt.nz (Not Verified[10.104.240.112]) by WLGPRDMM01.dia.govt.nz with MailMarshal (v7, 1, 1, 5205) (using TLS: SSLv23) id ; Mon, 21 Mar 2016 08:46:20 +1300 Received: from AKLDRMBX03.dia.govt.nz ([fe80::d1c1:15a7:3e85:ac71]) by AklDrCas02.dia.govt.nz ([::1]) with mapi id 14.03.0279.002; Mon, 21 Mar 2016 08:46:19 +1300 From: Joanne Knight To: 'Ken Dagg' , Julian White Thread-Topic: [VoT] How to express duplicate checks with VoT? Thread-Index: AQHRewefr30T8sn2a0aikcEmelKPBJ9eF5wwgABJ+YCAAEh/gIAEIabA Date: Sun, 20 Mar 2016 19:46:18 +0000 Message-ID: <569AD906E45DB44A8AFF11D61F5DA7910155C81DA5@AKLDRMBX03.dia.govt.nz> References: <56E1A5F8.3090201@switch.ch> <569AD906E45DB44A8AFF11D61F5DA7910155C7D4F2@AKLDRMBX03.dia.govt.nz> <56EA8845.3040503@switch.ch> <569AD906E45DB44A8AFF11D61F5DA7910155C80A34@AKLDRMBX03.dia.govt.nz> In-Reply-To: Accept-Language: en-NZ, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailadviser: Confirmation not required x-originating-ip: [10.220.229.74] Content-Type: multipart/alternative; boundary="_000_569AD906E45DB44A8AFF11D61F5DA7910155C81DA5AKLDRMBX03dia_" MIME-Version: 1.0 Archived-At: Cc: Rolf Brugger , "vot@ietf.org" Subject: Re: [VoT] How to express duplicate checks with VoT? X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2016 19:46:31 -0000 --_000_569AD906E45DB44A8AFF11D61F5DA7910155C81DA5AKLDRMBX03dia_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGZpcnN0IHBvaW50IG9mIHNjb3BpbmcgSSB3b3VsZCBzdWdnZXN0IGlzIHRvIGRldGVybWlu ZSBpZiB5b3UgYXJlIHRhbGtpbmcgYWJvdXQgdW5pcXVlbmVzcyBvZiB0aGUgaWRlbnRpdHkgb3Ig dW5pcXVlbmVzcyBvZiB0aGUgZW50aXR5Lg0KDQpGcm9tOiBLZW4gRGFnZyBbbWFpbHRvOmtlbmRh Z2d0YnNAZ21haWwuY29tXQ0KU2VudDogU2F0dXJkYXksIDE5IE1hcmNoIDIwMTYgNjozOSBhLm0u DQpUbzogSnVsaWFuIFdoaXRlDQpDYzogSm9hbm5lIEtuaWdodDsgUm9sZiBCcnVnZ2VyOyB2b3RA aWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbVm9UXSBIb3cgdG8gZXhwcmVzcyBkdXBsaWNhdGUgY2hl Y2tzIHdpdGggVm9UPw0KDQpIZXJlLCBoZXJlISEhDQoNCkkgaGF2ZSBiZWVuIGEgbHVya2VyIG9u IHRoaXMgZ3JvdXAgZm9yIGEgd2hpbGUgYnV0IGZlbHQgY29tcGVsbGVkIHRvIGFkZCBteSB0byBj ZW50cyB0byB0aGlzIGRpc2N1c3Npb24gYXMgaXQgaXMsIEkgYmVsaWV2ZSwgYW4gaW1wb3J0YW50 IHBvaW50IHRvIHNjb3BpbmcgdGhlIGRpc2N1c3Npb24gYXMgaXQgcHJvY2VlZHMuDQoNCkkgYWdy ZWUgZnVsbHkgdGhhdCBkZXRlcm1pbmluZyB0aGUgdW5pcXVlbmVzcyBvZiBhIHN1YmplY3QgaXMg dG90YWxseSB0aGUgcmVzcG9uc2liaWxpdHkgb2YgdGhlIFJQLiBJdCBpcyB0aGVpciBzZXJ2aWNl IGRlbGl2ZXJ5IGFuZCB0aGV5IGhhdmUgdG8gZGV0ZXJtaW5lIHdoYXQgdGhleSByZXF1aXJlIGlu IG9yZGVyIGZvciB0aGVtIHRvIGJlIGFzc3VyZWQgdGhhdCB0aGV5IGFyZSBkZWFsaW5nIHdpdGgg YSB1bmlxdWUgc3ViamVjdC4gSSB1c2Ugc3ViamVjdCBpbiBvcmRlciB0byBpbmNsdWRlIHRoZSBJ T1QgaW4gdGhlIHBvc3NpYmxlIHNvbHV0aW9uLiBJZiBJJ20gcmVhZGluZyB3aGF0IHlvdSBzYXkg Y29ycmVjdGx5LCBvbmUgb2YgdGhlIGNvbnNpZGVyYXRpb25zIHRoYXQgYSBSUCBtaWdodCB1c2Ug dG8gZGV0ZXJtaW5lIHVuaXF1ZW5lc3MgaXMgdGhlIGxldmVsIG9mIHByb29maW5nIHRoZXkgcmVx dWlyZSBvbiAxKSBlYWNoIG9mIHRoZSBhdHRyaWJ1dGVzIGFuZCAyKSB0aGUgc2V0IG9mIGF0dHJp YnV0ZXMuDQoNCk15IGV4cGVyaWVuY2Ugd2l0aCBSUHMgYWxpZ25zIHdpdGggSnVsaWFuJ3MuIFdo aWxlIFJQcyB1c3VhbGx5IGFzayBmb3IgdW5pcXVlbmVzcyBmcm9tIHRoZWlyIGRpZ2l0YWwgc3Vw cGxpZXIgdGhleSBkbyBub3QgZG8gc28gaW4gdGhlIG1hbnVhbCB3b3JsZC4gTXkgdGFjdGljIGhh cyBiZWVuIHRvIGFzayB3aHkgdGhleSBhcmUgYXNraW5nIGZvciBpdCBpbiB0aGUgZGlnaXRhbCB3 b3JsZCBhbmQgbm90IGluIHRoZSBtYW51YWwgd29ybGQuIFRoZSBkaXNjdXNzaW9uIGFyb3VuZCB0 aGlzIHF1ZXN0aW9uICh1c3VhbGx5IGFyb3VuZCAxKSB0aGVpciBwZXJjZWl2ZWQgYmVuZWZpdCBh bmQgMikgdGhlIGFkZGl0aW9uYWwgY29zdCB2ZXJzdXMgdGhlaXIgcGVyY2VpdmVkIGJlbmVmaXQp IGxlYWRzIHRvIHRoZW0gZHJvcHBpbmcgdGhhdCByZXF1aXJlbWVudCBmcm9tIHRoZWlyIGRpZ2l0 YWwgc3VwcGxpZXIuDQoNClRoZSAiaW1wb3N0ZXIiIGRpc2N1c3Npb24gdXN1YWxseSB0YWtlcyB0 aGUgc2FtZSBwYXRoLiBBc2tpbmcgdGhlIFJQIGhvdyB0aGV5IGRlYWwgd2l0aCBpbXBvc3RlcnMg aW4gdGhlIG1hbnVhbCB3b3JsZCB1c3VhbGx5IGxlYWRzIHRvIGEgY29uY2x1c2lvbiB0aGF0IHRo ZXkgY2FuIGVtcGxveSB0aGUgc2FtZSB0YWN0aWNzIGFuZCBwcm9jZXNzZXMgb25seSB1c2luZyBk aWdpdGFsIGRhdGEuIENvc3QgZWZmZWN0aXZlbmVzcyBpcyB1c3VhbGx5IGEgYmlnIHBhcnQgb2Yg dGhlIGRpc2N1c3Npb24uIFRoaXMgc2hvdWxkIG5vdCBiZSBsaWtlbmVkIHRvIHBhdmluZyB0aGUg Y293IHBhdGguIFdoYXQgdXN1YWxseSBoYXBwZW5zIGlzIHRoYXQgdGhleSByZWFsaXplIHRoYXQs IGluIHRoZSBkaWdpdGFsIHdvcmxkLCB0aGV5IG1pZ2h0IGJlIGFibGUgdG8gZGV0ZWN0IGFuIGlt cG9zdGVyIGZhc3RlciBiZWNhdXNlIHRoZXkgaGF2ZSBmYXN0ZXIgYWNjZXNzIHRvIHRoZSBkYXRh IHRoZXkgdXNlIHRvIGRldGVjdCBpbXBvc3RlcnMuIEluIHNvbWUgY2FzZXMsIHRoZXkgbWF5IHJl YWxpemUgaW1wcm92ZWQgZGV0ZWN0aW9uIGJlY2F1c2UgdGhlIHByb29maW5nIGRhdGEgaXMgbGlr ZWx5IGJldHRlciB0aGFuIHRoZXkgaGF2ZSBhdmFpbGFibGUgaW4gdGhlIG1hbnVhbCB3b3JsZC4N Cg0KSXQgaXMgbXkgb3BpbmlvbiB0aGF0LCBhcyB0aGVpciBwcm9jZXNzZXMgZXZvbHZlIGluIHRo ZSBkaWdpdGFsIHdvcmxkLCB0aGV5IHdpbGwgYmVjb21lIGZhc3RlciBhdCBpbXBvc3RlciBkZXRl Y3Rpb24gYW5kIHJlc29sdXRpb24uIEl0IGlzIGFsc28gbXkgb3BpbmlvbiB0aGF0IHByZXZlbnRp b24gb2YgaW1wb3N0ZXJzIGJlZm9yZSB0aGV5IGhhcHBlbiwgbGlrZSB0aGUgdG90YWxseSBzZWN1 cmUgc3lzdGVtLCBpcywgaWYgbm90IGltcG9zc2libGUsIG5vdCBhIGNvc3QgZWZmZWN0aXZlIGdv YWwgdG8gYWNoaWV2ZS4NCg0KS2VuIERhZ2cNCg0KDQoNCk9uIEZyaWRheSwgMTggTWFyY2ggMjAx NiwgSnVsaWFuIFdoaXRlIDxqd2hpdGVAbnUtZC5jb208bWFpbHRvOmp3aGl0ZUBudS1kLmNvbT4+ IHdyb3RlOg0KDQpJIHdvdWxkIHNheSwgYXMgSSBoYXZlIGluIHRoZSBJU08gMjkwMDMgZGlzY3Vz c2lvbnMsIHRoYXQgdW5pcXVlbmVzcyBpcyBpbiBmYWN0IGlycmVsZXZhbnQgaW4gdGVybXMgb2Yg dGhlIGxldmVsIG9mIHByb29maW5nLiBJIHNlZSBubyBuZWVkIHRvIGtub3cgd2hldGhlciB0aGF0 IHNldCBvZiBhdHRyaWJ1dGVzIGlzIHByb3ZlbiB0byBiZSB1bmlxdWUgYnkgdGhlIHByb29maW5n IHByb3ZpZGVyLiBVbmlxdWVuZXNzIGlzIGhpZ2hseSBkZXBlbmRlbnQgb24gdGhlIGNvbnRleHQs IHdoaWNoIHJhaXNlcyBhbGwgc29ydHMgb2YgcHJvYmxlbXMgaWYgeW91IGhhdmUgYW4gaWRlbnRp dHkgZmVkZXJhdGlvbiAoaG93IGRvIEkga25vdyBpdHMgdW5pcXVlIGFjcm9zcyB0aGUgZmVkZXJh dGlvbj8gSWYsIGFzIGFuIFJQLCBJIGNhbiBjYW4gY29wZSB3aXRoIG5vbi11bmlxdWVuZXNzIGFj cm9zcyB0aGUgZmVkZXJhdGlvbiB0aGVuIG5vbi11bmlxdWVuZXNzIHdpdGhpbiB0aGUgcHJvb2Zp bmcgcHJvdmlkZXIgaXMgYWxzbyBub3QgYSBwcm9ibGVtKS4NCg0KSW4gbXkgdmlldyBpdCBpcyBm b3IgdGhlIFJQLCBvciBpZGVudGl0eSBmZWRlcmF0aW9uIHNjaGVtZSwgdG8gZGVjaWRlIHdoaWNo IGF0dHJpYnV0ZXMgYXJlIHJlcXVpcmVkIGluIHRoZWlyIGNvbnRleHQuIFRoZXkgc2VsZWN0IHN1 ZmZpY2llbnQgYXR0cmlidXRlcyB0aGF0IGdpdmUgdGhlbSB1bmlxdWVuZXNzIChpbiB0aGVpciBj b250ZXh0KSBpZiB0aGF0IGlzIHJlcXVpcmVkLCBlLmcuIFNTTiBmb3Igc29tZSBzZXJ2aWNlcyAo dGhvdWdoIEkgd291bGQgYWR2aXNlIGFnYWluc3QgaXQhKS4gVGhlIHB1cnBvc2Ugb2YgdGhlIHBy b29maW5nIHByb2Nlc3MgaXMgdG8gZXhwcmVzcyB0byB3aGF0IGxldmVsIG9mIGNvbmZpZGVuY2Ug dGhhdCB0aG9zZSBhdHRyaWJ1dGVzIGFyZSB0cnVlIGFuZCBiZWxvbmcgdG8gdGhlIHBlcnNvbiBw cmVzZW50aW5nIHRoZW0sIGJlIHRoZXkgbmFtZSwgYWRkcmVzcywgZG9iLCBlbWFpbCBhZGRyZXNz LCBTU04gZXRjLg0KDQpJbiBteSBkZWFsaW5ncyB3aXRoIFJQcyB0aGV5IGFyZSBjb25mdXNlZCBh Ym91dCB0aGlzIGFuZCBhc2sgZm9yICJ1bmlxdWVuZXNzIiwgdGhpcyBpcyB1c3VhbGx5IGZvbGxv d2VkIHVwIHdpdGggImJlY2F1c2Ugd2UgY2FuJ3QgbGV0IHBlb3BsZSByZWdpc3RlciBtdWx0aXBs ZSBpZGVudGl0aWVzIi4gVGhlcmUgaXMgYSBsYWNrIG9mIHVuZGVyc3RhbmRpbmcgdGhhdCwgYXNz dW1pbmcgdGhlIHByb29maW5nIHByb2Nlc3MgaXMgd29ya2luZyBjb3JyZWN0bHksIGl0IGRvZXNu J3QgbWF0dGVyIGhvdyBtYW55IHRpbWVzIHlvdSBlbnJvbCB5b3UgYXJlIHByb3ZlbiB0byBiZSB0 aGUgc2FtZSBwZXJzb24gZWFjaCB0aW1lOyBpLmUuIG11bHRpcGxlIGVucm9sbWVudHMgbGVhZCB0 byB0aGUgaWRlbnRpZmljYXRpb24gb2YgdGhlIHNhbWUgcGVyc29uIGJlaW5nIGJvdW5kIHRvIHRo ZSBzYW1lIGF0dHJpYnV0ZXMuIFRoZXJlZm9yZSBpdCBpc24ndCBhY3R1YWxseSBhIHByb2JsZW0g aW4gdGVybXMgb2YgdW5pcXVlbmVzcy4NCg0KTW9yZSBvZnRlbiB0aGFuIG5vdCB0aGUgYXNrIGZv ciB1bmlxdWVuZXNzIGlzIHJlYWxseSBhbiBleHByZXNzaW9uIG9mIGhvdyB3ZWxsIHRoZSBzeXN0 ZW0gZGVmZW5kcyBpdHNlbGYgYWdhaW5zdCBpbXBvc3RvcnMgKGRpZmZlcmVudCBwZW9wbGUgcmVn aXN0ZXJpbmcgZm9yIHRoZSBzYW1lIGF0dHJpYnV0ZXMpIHdoaWNoIGlzIGFjdHVhbGx5IHRoZSBw b2ludCBvZiB0aGUgZGlmZmVyZW50IGxldmVscyBvZiBwcm9vZmluZyAodGhlIGhpZ2hlciB0aGUg bGV2ZWxzIG9mIHByb29maW5nIHRoZSBoYXJkZXIgdGhpcyBzaG91bGQgYmVjb21lKS4gRGVtYW5k aW5nIHVuaXF1ZW5lc3MgZG9lc24ndCBhY3R1YWxseSBmaXggdGhlIGltcG9zdG9yIHByb2JsZW0s IHlvdSBqdXN0IGludHJvZHVjZSBhIHRpbWUgdHJpYWwgdG8gdGhlIHByb2Nlc3M7IHRoZSBmaXJz dCBwZXJzb24gdG8gZ2V0IGJvdW5kIHRvIHRob3NlIGF0dHJpYnV0ZXMgbG9ja3Mgb3V0IG90aGVy IHBlb3BsZTsgaWYgdGhlIGZpcnN0IHBlcnNvbiB0byBjbGFpbSB0aGVtIHdhcyB0aGUgaW1wb3N0 b3IgeW91J3ZlIG5vdyBsb2NrZWQgb3V0IHRoZSBnZW51aW5lIHBlcnNvbiAtIHRoZXkgbm93IGhh dmUgYSBoZWxsIG9mIHRpbWUgdW5waWNraW5nIGEgbWVzcyBub3Qgb2YgdGhlaXIgbWFraW5nLiBJ ZiB0aGUgc3lzdGVtIGRlZmVuZHMgYWdhaW5zdCBpbXBvc3RvcnMgcHJvcGVybHkgYXQgdGhlIGhp Z2hlciBsZXZlbHMgdGhlbiB0aGUgdW5pcXVlbmVzcyBhZGRzIGxpdHRsZSB2YWx1ZSBzaW5jZSBJ IGNhbiBvbmx5IGJpbmQgdGhvc2UgYXR0cmlidXRlcyB0byB0aGUgY29ycmVjdCBwZXJzb24gYW55 d2F5Lg0KDQpUaGUgdGhpbmcgdGhhdCBtYXkgbmVlZCB0byBiZSB1bmlxdWUgaXMgdGhlIGFjY291 bnQvcmVjb3JkIGF0IHRoZSBSUCwgYW5kIGl0cyB0aGUgUlAncyByZXNwb25zaWJpbGl0eSB0byBt YW5hZ2UgdGhhdC4gVGhpcyBpcyBhIHByb2JsZW0gdGhleSBoYXZlIHJlZ2FyZGxlc3Mgb2Ygd2hl dGhlciB0aGUgcHJvb2ZpbmcgcHJvdmlkZXIgdGVsbHMgdGhlbSBpdHMgdW5pcXVlIG9yIG5vdCBi ZWNhdXNlIHRoZXkgb2Z0ZW4gaGF2ZSBtdWx0aXBsZSBvbi1saW5lIGFuZCBvZmZsaW5lIGNoYW5u ZWxzIHRoYXQgZGVhbCB3aXRoIHRoZWlyIGN1c3RvbWVycywgdGhpcyBmb3JjZXMgdGhlbSB0byB1 bmRlcnN0YW5kIGhvdyB0byBtYXRjaCBkaWZmZXJlbnQgcmVwcmVzZW50YXRpb25zIG9mIHRoZSBp ZGVudGl0eSB0byB0aGUgc2FtZSBhY2NvdW50IHdoaWNoIHRlbmRzIHRvIHdvcmsgYWNyb3NzIGNo YW5uZWwgYW5kIHdpdGhpbiB0aGUgc2FtZSBjaGFubmVsLg0KDQpTbyBpbiBzdW1tYXJ5IGl0IGRv ZXNuJ3QgZHJpdmUgYW55IHJlYWwgdmFsdWUgaW4gdGhlIHByb29maW5nIHByb3ZpZGVyIHRvIGRv IHRoaXMsIGl0cyBqdXN0IGEgY29zdCBvZiBlZmZvcnQgZm9yIGxpdHRsZSBnYWluIHRoYXQgdGhl IFJQIGlzIGdvaW5nIHRvIHJlcGVhdCByZWdhcmRsZXNzIGlmIHRoZXkgY2FyZSBhYm91dCB1bmlx dWVuZXNzLg0KDQpSZWdhcmRzLA0KDQpKdWxpYW4uDQoNCg0KDQoNCk9uIDE3IE1hcmNoIDIwMTYg YXQgMjE6NDksIEpvYW5uZSBLbmlnaHQgPEpvYW5uZS5LbmlnaHRAZGlhLmdvdnQubno8amF2YXNj cmlwdDpfZSglN0IlN0QsJ2N2bWwnLCdKb2FubmUuS25pZ2h0QGRpYS5nb3Z0Lm56Jyk7Pj4gd3Jv dGU6DQpUaGUgc2hvcnQgYW5zd2VyIHRvIHlvdXIgcXVlc3Rpb24gLSBOby4NCg0KWW91ciB1c2Ug Y2FzZSBpcyBzaWxlbnQgb24gdGhlIGxldmVsIG9mIHZldHRpbmcgcmVxdWlyZWQgKGhvdyByZWFs IGRvZXMgdGhlIGlkZW50aXR5IGhhdmUgdG8gYmUpLiBZb3UgY2FuIGhhdmUgYW55IGxldmVsIG9m IGlkZW50aXR5IGFuZCBzdGlsbCBjb2xsZWN0IGEgYmlvbWV0cmljIGZvciB0aGUgcHVycG9zZXMg b2Ygb25lIGFuZCBvbmx5IG9uZSB1bmlxdWVuZXNzLiBJIHdvdWxkIHBvc2UgaG93ZXZlciB0aGF0 IGl0IGlzIHZlcnkgdW51c3VhbCBmb3Igb25lIGFuZCBvbmx5IG9uZSBhc3N1cmFuY2UgdG8gYmUg cmVxdWlyZWQgd2l0aG91dCBzb21lIG90aGVyIGRyaXZlciByZXF1aXJpbmcgYW4gZWxldmF0ZWQg bGV2ZWwgb2YgcmVhbG5lc3MuDQoNCkluIHlvdXIgdXNlIGNhc2UgSSB3b3VsZCBzdWdnZXN0IHRo YXQgdGhlcmUgaXMgYWxzbyBhIHJlcXVpcmVtZW50IHRoYXQgYSBxdWFsaWZpY2F0aW9uIGlzIGlz c3VlZCB0bw0KYSkgdGhlIHBlcnNvbiBjYXJyeWluZyBvdXQgdGhlIHN0dWR5IGFuZA0KYikgYW4g aWRlbnRpdHkgb2Ygc3VjaCByaWdvdXIgdGhhdCB0aGVpciAob3IgdGhlIHVuaXZlcnNpdHkncykg ZWxpZ2liaWxpdHkgZm9yIHB1YmxpYyBmdW5kaW5nIGNhbiBiZSBlc3RhYmxpc2hlZCBhbmQNCmMp IGFuIGlkZW50aXR5IHRoYXQgaXMgZ29pbmcgdG8gYmUgdGVzdGVkIGJ5IGZ1dHVyZSBlbXBsb3ll cnMuDQoNClRoZXJlZm9yZSB5b3UgYXJlIHByb2JhYmx5IGxvb2tpbmcgYXQgUDIgb3IgUDMgZGVw ZW5kaW5nIG9uIHRoZSBsZXZlbC90eXBlIG9mIHF1YWxpZmljYXRpb24uIChJIG1pZ2h0IHdhbnQg UDMgaWYgdGhlIHF1YWxpZmljYXRpb24gaXMgZm9yIGJyYWluIHN1cmdlb24gb3IgY29tbWVyY2lh bCBwaWxvdCkuDQoNCkFzIG9uZSBhbmQgb25seSBvbmUgaXMgcmVhbGx5IG9ubHkgYWJsZSB0byBi ZSBhY2hpZXZlZCB0aHJvdWdoIHRoZSB1c2Ugb2YgYSBiaW9tZXRyaWMsIHdlIG5vdyBoYXZlIHRv IGNvbnNpZGVyICdhY2NlcHRhYmlsaXR5Jy4NCkRvZXMgdGhlIGNvbGxlY3Rpb24gb2YgYSBiaW9t ZXRyaWMgKGFuZCBhbGwgdGhhdCBpdCBlbnRhaWxzIC0gY29zdCwgcHJpdmFjeSwgc2VjdXJpdHks IHVzZXIgYWNjZXB0YW5jZSBldGMuKSBvdXR3ZWlnaCB0aGUgaW1wYWN0IGNhdXNlZCBieSBhIGR1 cGxpY2F0ZSBlbnRpdHkgaW4gdGhlIHN5c3RlbT8NCkluIG90aGVyIHdvcmRzLCBkbyB5b3UgcmVh bGx5IG5lZWQgb25lIGFuZCBvbmx5IG9uZSAodGhlIDNyZCBsZXZlbCBvZiB1bmlxdWVuZXNzKSBv ciBjb3VsZCBzdWZmaWNpZW50IHNpbmd1bGFyaXR5IGJlIGdhaW5lZCBmcm9tIGxldmVyYWdpbmcg dGhlIHNvY2lhbCBzZWN1cml0eSBudW1iZXIncyB1bmlxdWVuZXNzIGFuZCBhbiBlcXVpdmFsZW50 IGxldmVsIG9mIHZhbGlkYXRpb24gYW5kIG93bmVyc2hpcCB0ZXN0ICh0aGUgMm5kIGxldmVsIG9m IHVuaXF1ZW5lc3MpIGkuZS4gbm8gUHU/DQoNCldlIG11c3QgcmVtZW1iZXIgdGhlIG11dHVhbCBl eGNsdXNpdml0eSBiZXR3ZWVuIGF0dHJpYnV0ZXMgY29sbGVjdGVkLCB2ZXR0aW5nIHVuZGVyIHRh a2VuIGFuZCBsZXZlbCBvZiB1bmlxdWVuZXNzLg0KDQpIYXBweSB0byBkaXNjdXNzIGZ1cnRoZXIg aWYgdGhpcyBtYWtlcyBubyBzZW5zZS4NCg0KQ2hlZXJzDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogUm9sZiBCcnVnZ2VyIFttYWlsdG86cm9sZi5icnVnZ2VyQHN3aXRj aC5jaDxqYXZhc2NyaXB0Ol9lKCU3QiU3RCwnY3ZtbCcsJ3JvbGYuYnJ1Z2dlckBzd2l0Y2guY2gn KTs+XQ0KU2VudDogVGh1cnNkYXksIDE3IE1hcmNoIDIwMTYgMTE6MzUgcC5tLg0KVG86IHZvdEBp ZXRmLm9yZzxqYXZhc2NyaXB0Ol9lKCU3QiU3RCwnY3ZtbCcsJ3ZvdEBpZXRmLm9yZycpOz4NClN1 YmplY3Q6IFJlOiBbVm9UXSBIb3cgdG8gZXhwcmVzcyBkdXBsaWNhdGUgY2hlY2tzIHdpdGggVm9U Pw0KDQpIaSBhbGwsDQoNClRoYW5rcyBmb3IgYWxsIHlvdXIgcmVzcG9uc2VzIGFuZCBpZGVhcy4g V2UgaGF2ZSBkaXNjdXNzZWQgeW91ciBpbnB1dHMgaW4gb3VyIHByb2plY3QgdGVhbSAod2hpY2gg aXMgd2h5IGl0IHRvb2sgbWUgc29tZSB0aW1lIHRvIHJlc3BvbmQpDQoNCkkgd2FzIHdvbmRlcmlu ZyB3aGF0IGFjdHVhbGx5IHRoZSBkaWZmZXJlbmNlcyBhcmUgYmV0d2VlbiB0aGUgdGhyZWUgbGV2 ZWxzIG9mIHVuaXF1ZW5lc3MgZGVzY3JpYmVkIGJ5IEpvYW5uZS4gSW4gZWFjaCBvZiB0aGUgdGhy ZWUgbGV2ZWxzIGEgc2V0IG9mIGF0dHJpYnV0ZXMgaXMgdXNlZCB0byBkZXRlcm1pbmUgaWYgYW4g aWRlbnRpdHkgaXMgdW5pcXVlIHdpdGhpbiBhIHBvcHVsYXRpb24gb2YgaWRlbnRpdGllcy4gVGhl IGRpZmZlcmVuY2UgaXMgMSkgd2hhdCBleGFjdCBzZXQgb2YgYXR0cmlidXRlcyBpcyB1c2VkIGlu IGVhY2ggbGV2ZWwgYW5kIDIpIHRoZSB2ZXR0aW5nIGxldmVsIG9mIHRoZSBhdHRyaWJ1dGVzLiBS aWdodD8NCg0KQSBjb25jcmV0ZSBleGFtcGxlIG1pZ2h0IGJlDQoNCkZpcnN0IGxldmVsOg0KLSBh dHRyaWJ1dGVzOiBOYW1lLCBlbWFpbCwgcGhvbmUgbnVtYmVyDQotIHZldHRpbmcgbGV2ZWw6IFAx DQoNClNlY29uZCBsZXZlbDoNCi0gYXR0cmlidXRlczogTmFtZSwgZW1haWwsIHBob25lIG51bWJl ciwgc29jaWFsIHNlY3VyaXR5IG51bWJlcg0KLSB2ZXR0aW5nIGxldmVsOiBQMg0KDQpUaGlyZCBs ZXZlbDoNCi0gYXR0cmlidXRlczogZmluZ2VyIHByaW50IG9yIHJldGluYSBzY2FuDQotIHZldHRp bmcgbGV2ZWw6IFAzDQoNClRoZSBhcHByb3ByaWF0ZSBzZXQgb2YgYXR0cmlidXRlcyB0byBiZSB1 c2VkIGluIGVhY2ggbGV2ZWwgaXMgY2VydGFpbmx5IGNvbnRleHQtc3BlY2lmaWMuIEFzIEVyaWMg cG9pbnRzIG91dCBpdCB3aWxsIGJlIGRpZmZpY3VsdCB0byBkZWZpbmUgYW5kIGFncmVlIG9uIGEg Z2VuZXJpYyBkZWZpbml0aW9uIG9mIHRoZSBzY29wZS4NCg0KTWF5YmUgaXQncyB0aW1lIHRvIGRl c2NyaWJlIG91ciB1c2UgY2FzZXMgaGVyZS4gSW4gdGhlIElkTSBzZXJ2aWNlIHdlIGFyZSBwbGFu bmluZyBpbmRpdmlkdWFscyBzZWxmLXJlZ2lzdGVyIHRoZWlyIGlkZW50aXRpZXMuIFdpdGggc3Vj aCBhbiBpZGVudGl0eSwgaW5kaXZpZHVhbHMgY2FuIHJlZ2lzdGVyIGZvciBzdHVkaWVzIGF0IGEg dW5pdmVyc2l0eS4gQnV0IG9uZSBpbmRpdmlkdWFsIG1heSBvbmx5IHJlZ2lzdGVyIG9uY2UgYXQg dGhlIHNhbWUgdW5pdmVyc2l0eS4gQW5vdGhlciBjYXNlIGlzIGEgdXNlcidzIGxpYnJhcnkgYWNj b3VudCB0aGF0IHdhcyBibG9ja2VkIGJlY2F1c2Ugb2YgdmlvbGF0aW9ucyBvZiB0aGUgbGlicmFy eSdzIHVzYWdlIHRlcm1zLiBTdWNoIGEgdXNlciBzaG91bGQgbm90IGJlIGFibGUgdG8ganVzdCBj cmVhdGUgYSBuZXcgYWNjb3VudCB0byB1c2UgdGhlIGxpYnJhcnkgc2VydmljZXMgYWdhaW4uDQoN CldpdGggSnVzdGluJ3Mgc3VnZ2VzdGlvbiBvZiBhIFB1IGNhdGVnb3J5LCB0aGUgcmVxdWlyZW1l bnRzIGluIG91ciB1c2UgY2FzZXMgY291bGQgYmUgZXhwcmVzc2VkIGFzIFAxLlB1IG9yIFAyLlB1 LiBUaGUgc2VtYW50aWNzIG9mICJQMi5QdSINCndvdWxkIHRoZW4gYmU6IFByb29mZWQgdW5pcXVl IGJhc2VkIG9uIGFuIGF0dHJpYnV0ZSBzZXQgd2l0aCB0aGUgdmV0dGluZyBsZXZlbCBQMi4NCg0K Y2hlZXJzDQoNClJvbGYNCg0KDQoNCk9uIDExLjAzLjE2IDAyOjU2LCBKb2FubmUgS25pZ2h0IHdy b3RlOg0KPiBIaSBBbGwNCj4NCj4gVGhlcmUgYXJlIHRocmVlIGFzcGVjdCBvciBsZXZlbHMgd2hl biBsb29raW5nIGF0IHVuaXF1ZW5lc3MgdG8gYmUNCj4gY29uc2lkZXJlZC4NCj4NCj4gRmlyc3Qg bGV2ZWwgaXMgdGhhdCB0aGUgaWRlbnRpdHkgaXMgdW5pcXVlIC0gdGhhdCBpcywgd2l0aGluIGEg Y29udGV4dA0KPiB0aGVyZSBpcyBhIHNldCBvZiBhdHRyaWJ1dGVzIHRoYXQgYXJlIHVuaXF1ZSBm b3IgZWFjaCBpZGVudGl0eQ0KPiByZWdpc3RlcmVkLg0KPg0KPiBTZWNvbmQgbGV2ZWwgaXMgc29s ZSBjbGFpbWFudCAtIHRoaXMgaXMgYSBjaGVjayB0aGF0IG9ubHkgb25lIGVudGl0eQ0KPiBoYXMg Y2xhaW1lZCBhIHBhcnRpY3VsYXIgc2V0IG9mIGF0dHJpYnV0ZXMuIEF0IHRoZSBoaWdoZXIgbGV2 ZWxzIG9mDQo+IGlkZW50aXR5IHByb29maW5nIHdoZXJlIGF1dGhvcml0YXRpdmUgc291cmNlcyBh cmUgdXNlZCBpdCBtYXkgYmUNCj4gcG9zc2libGUgdG8gYWNoaWV2ZSB0aGlzLiBUaGlzIGlzIHN1 ZmZpY2llbnQgaW4gbW9zdCBSUHMgY2FzZXMuIEF0DQo+IHRoaXMgbGV2ZWwgd2hpbGUgaXQgaXMg cG9zc2libGUgZm9yIGEgc2luZ2xlIGVudGl0eSB0byBjbGFpbSBtb3JlIHRoYW4NCj4gb25lIGlk ZW50aXR5LCB0aGV5IGRvIHNvIGF0IHRoZSByaXNrIG9mIGNhdXNpbmcgYSBjb3VudGVyLWZyYXVk IGZsYWcNCj4gc2hvdWxkIHRoZSByZWFsIG93bmVyIChvciBhbnkgb3RoZXIgcGFydHkpIGFsc28g YXR0ZW1wdCB0byBjbGFpbSB0aGUNCj4gaWRlbnRpdHkuDQo+DQo+IFRoZSBmaW5hbCBsZXZlbCBp cyBvbmUgYW5kIG9ubHkgb25lIC0gVGhpcyBpcyBhIGNoZWNrIC0gdXN1YWxseQ0KPiBiaW9tZXRy aWMgLSB0aGF0IGFuIGVudGl0eSBoYXMgb25seSBvbmUgY2xhaW0gaW4gdGhlIGNvbnRleHQuIFRo aXMgaXMNCj4gdXN1YWxseSBvbmx5IHJlc2VydmVkIGZvciB0aGUgaGlnaGVzdCBsZXZlbCBvZiBp ZGVudGl0eSBhbmQgd291bGQgYWxzbw0KPiByZXF1aXJlIGVxdWFsbHkgaGlnaCBsZXZlbHMgb2Yg Y3JlZGVudGlhbCBhbmQgY3JlZGVudGlhbCBpc3N1YW5jZQ0KPiBwcm9jZXNzZXMuDQo+DQo+IEFz IHRvIGhvdyB0aGlzIHJlbGF0ZXMgdG8gVm9UIC0gVGhlIGZpcnN0IHNob3VsZCBiZSBpbm5hdGVs eSBidWlsdA0KPiBpbnRvIGFsbCBsZXZlbHMgb2YgUCAtIGl0IGlzIHRoZSBzb2xlIHJlcXVpcmVt ZW50IG9mIGFsbCBsZXZlbHMNCj4NCj4gVGhlIHNlY29uZCBjb3VsZCBiZSBidWlsdCBpbnRvIFAz IGlmIHRoZSB3b3JkaW5nIHdhcyBhbWVuZGVkIHNsaWdodGx5Lg0KPg0KPiBUaGUgbGFzdCBpdGVt IG9ubHkgaXMgc3Vic3RhbnRpdmVseSBtaXNzaW5nIGFuZCB0byBkYXRlIChpbiB0aGUNCj4gY29u dmVyc2F0aW9ucyBJIGhhdmUgYmVlbiBoYXZpbmcgZWxzZXdoZXJlKSB0aGVyZSBoYXMgYmVlbg0K PiBpbnN1ZmZpY2llbnQgYXBwZXRpdGUgdG8gYWRkIGl0IGFzIGFuIGV4cGxpY2l0IHJlcXVpcmVt ZW50Lg0KPg0KPiBTaG91bGQgd2UgaGF2ZSBhIFBVPyBNYXliZSwgYnV0IHN0ZWVyIGNsZWFyIG9m IHRoZSB0ZXJtICd1bmlxdWUnIElmIHdlDQo+IGRvLCBpbiBteSBtaW5kIGl0IHdvdWxkIG9ubHkg aGF2ZSB0d28gdmFsdWVzIC0gUD8wIC0gQ2xhaW1zIHBlciBlbnRpdHkNCj4gbm90IGNoZWNrZWQs IFA/MSAtIENsYWltcyBwZXIgZW50aXR5IHJlc3RyaWN0ZWQgdG8gb25lLg0KPg0KPiBKb2FubmUN Cj4NCj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gRnJvbTogUm9sZiBCcnVnZ2VyDQo+ IFttYWlsdG86cm9sZi5icnVnZ2VyQHN3aXRjaC5jaDxqYXZhc2NyaXB0Ol9lKCU3QiU3RCwnY3Zt bCcsJ3JvbGYuYnJ1Z2dlckBzd2l0Y2guY2gnKTs+XSBTZW50OiBGcmlkYXksIDExIE1hcmNoIDIw MTYgNTo1MSBhLm0uDQo+IFRvOiB2b3RAaWV0Zi5vcmc8amF2YXNjcmlwdDpfZSglN0IlN0QsJ2N2 bWwnLCd2b3RAaWV0Zi5vcmcnKTs+IFN1YmplY3Q6IFtWb1RdIEhvdyB0byBleHByZXNzIGR1cGxp Y2F0ZSBjaGVja3Mgd2l0aA0KPiBWb1Q/DQo+DQo+IEhpIGFsbCwNCj4NCj4gSSdtIG5ldyB0byB0 aGlzIGxpc3QgYW5kIEkgaG9wZSBteSBxdWVzdGlvbiBpcyBub3QgdG90YWxseSBpcnJlbGV2YW50 DQo+IGhlcmUuDQo+DQo+IFdlIGhhdmUgcGxlbnR5IG9mIHVzZSBjYXNlcyB3aGVyZSBSUHMgbmVl ZCB0byBoYXZlIGNvbmZpZGVuY2UsIHRoYXQgYQ0KPiBwZXJzb24gZG9lcyBub3QgaGF2ZSBtdWx0 aXBsZSBpZGVudGl0aWVzIGluIG9uZSBJZFAuIEkgZG9uJ3Qgc2VlIGhvdw0KPiB0aGlzIGFzcGVj dCBvZiBpZGVudGl0eSBxdWFsaXR5IGNhbiBiZSBleHByZXNzZWQsIGFuZCBJIGJlbGlldmUgaXQg aXMNCj4gcHJldHR5IG9ydGhvZ29uYWwgdG8gdGhlIFAsIEMsIE0gYW5kIEEgZGltZW5zaW9ucyB0 aGF0IGFyZSBjdXJyZW50bHkNCj4gc3BlY2lmaWVkIGluIHRoZSBWb1QgZHJhZnQuDQo+DQo+IFdl IGNvdWxkIGltYWdpbmUgbXVsdGlwbGUgd2F5cyB0byBncmFkdWFsbHkgcHJvdmUgdGhhdCBhbiBp ZGVudGl0eSBoYXMNCj4gYmVlbiBjaGVja2VkIGFnYWluc3QgZHVwbGljYXRlcy4gVGhlIG1vc3Qg c3RyYWlnaHRmb3J3YXJkIGFwcHJvYWNoDQo+IHdvdWxkIGJlIHRvIG1ha2Ugc3VyZSB0aGF0IHVu aXF1ZSBwZXJzb25hbCBhdHRyaWJ1dGVzIGFyZSB1c2VkIG9ubHkNCj4gb25jZSB3aXRoaW4gb25l IElkUCBvciBhbiBJZFAgZmVkZXJhdGlvbiwgbGlrZSAtIGVtYWlsDQo+IGFkZHJlc3MoZXMpIC0g bW9iaWxlIHBob25lIG51bWJlciAtIGhvbWUgcG9zdGFsIGFkZHJlc3MgLSBzb2NpYWwNCj4gc2Vj dXJpdHkgbnVtYmVyIC0gSUQgLyBwYXNzcG9ydCBudW1iZXIgLSB0aGUgY29tYmluYXRpb24gb2Yg bmFtZSBhbmQNCj4gYmlydGggZGF0ZSAtIGV0Yy4NCj4NCj4gV291bGQgaXQgbWFrZSBzZW5zZSB0 byBleHByZXNzIHRoaXMgaW4gVm9UPw0KPg0KPiBiZXN0IHJlZ2FyZHMNCj4NCj4gUm9sZg0KPg0K Pg0KPiAtLSBTV0lUQ0ggLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gUm9sZiBCcnVnZ2VyLCBw cm9qZWN0IFN3aXNzDQo+IGVkdS1JRCBXZXJkc3RyYXNzZSAyLCBQLk8uIEJveCwgODAyMSBadXJp Y2gsIFN3aXR6ZXJsYW5kIHBob25lICs0MSA0NA0KPiAyNjggMTUgMTUsIGRpcmVjdCArNDEgNDQg MjY4IDE1IDg5PHRlbDolMkI0MSUyMDQ0JTIwMjY4JTIwMTUlMjA4OT4gcm9sZi5icnVnZ2VyQHN3 aXRjaC5jaDxqYXZhc2NyaXB0Ol9lKCU3QiU3RCwnY3ZtbCcsJ3JvbGYuYnJ1Z2dlckBzd2l0Y2gu Y2gnKTs+LA0KPiBodHRwOi8vd3d3LnN3aXRjaC5jaA0KPg0KPg0KPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyB2b3QgbWFpbGluZyBsaXN0DQo+IHZvdEBp ZXRmLm9yZzxqYXZhc2NyaXB0Ol9lKCU3QiU3RCwnY3ZtbCcsJ3ZvdEBpZXRmLm9yZycpOz4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92b3QNCj4NCg0KLS0NClNXSVRDSA0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClJvbGYgQnJ1Z2dlciwgcHJvamVjdCBTd2lzcyBl ZHUtSUQNCldlcmRzdHJhc3NlIDIsIFAuTy4gQm94LCA4MDIxIFp1cmljaCwgU3dpdHplcmxhbmQg cGhvbmUgKzQxIDQ0IDI2OCAxNSAxNTx0ZWw6JTJCNDElMjA0NCUyMDI2OCUyMDE1JTIwMTU+LCBk aXJlY3QgKzQxIDQ0IDI2OCAxNSA4OTx0ZWw6JTJCNDElMjA0NCUyMDI2OCUyMDE1JTIwODk+IHJv bGYuYnJ1Z2dlckBzd2l0Y2guY2g8amF2YXNjcmlwdDpfZSglN0IlN0QsJ2N2bWwnLCdyb2xmLmJy dWdnZXJAc3dpdGNoLmNoJyk7PiwgaHR0cDovL3d3dy5zd2l0Y2guY2gNCg0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kdm90IG1haWxpbmcgbGlzdA0K dm90QGlldGYub3JnPGphdmFzY3JpcHQ6X2UoJTdCJTdELCdjdm1sJywndm90QGlldGYub3JnJyk7 Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92b3QNCg0KDQoNCi0tDQpL ZW5uZXRoIERhZ2cNCkluZGVwZW5kZW50IENvbnN1bHRhbnQNCklkZW50aWZpY2F0aW9uIGFuZCBB dXRoZW50aWNhdGlvbg0KNjEzLTgyNS0yMDkxDQprZW5kYWdndGJzQGdtYWlsLmNvbTxtYWlsdG86 a2VuZGFnZ3Ric0BnbWFpbC5jb20+DQo= --_000_569AD906E45DB44A8AFF11D61F5DA7910155C81DA5AKLDRMBX03dia_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29u IFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC YWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjsNCgltc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1OWjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0 IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLU5aIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+VGhlIGZpcnN0IHBvaW50IG9mIHNjb3BpbmcgSSB3b3VsZCBzdWdnZXN0 IGlzIHRvIGRldGVybWluZSBpZiB5b3UgYXJlIHRhbGtpbmcgYWJvdXQgdW5pcXVlbmVzcyBvZiB0 aGUgaWRlbnRpdHkgb3IgdW5pcXVlbmVzcyBvZiB0aGUgZW50aXR5LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBLZW4g RGFnZyBbbWFpbHRvOmtlbmRhZ2d0YnNAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFNh dHVyZGF5LCAxOSBNYXJjaCAyMDE2IDY6MzkgYS5tLjxicj4NCjxiPlRvOjwvYj4gSnVsaWFuIFdo aXRlPGJyPg0KPGI+Q2M6PC9iPiBKb2FubmUgS25pZ2h0OyBSb2xmIEJydWdnZXI7IHZvdEBpZXRm Lm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1ZvVF0gSG93IHRvIGV4cHJlc3MgZHVwbGlj YXRlIGNoZWNrcyB3aXRoIFZvVD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5IZXJlLCBoZXJlISEhPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkkgaGF2ZSBiZWVuIGEgbHVya2VyIG9uIHRoaXMgZ3JvdXAgZm9yIGEgd2hp bGUgYnV0IGZlbHQgY29tcGVsbGVkIHRvIGFkZCBteSB0byBjZW50cyB0byB0aGlzIGRpc2N1c3Np b24gYXMgaXQgaXMsIEkgYmVsaWV2ZSwgYW4gaW1wb3J0YW50IHBvaW50IHRvIHNjb3BpbmcgdGhl IGRpc2N1c3Npb24gYXMgaXQgcHJvY2VlZHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYWdyZWUgZnVsbHkgdGhhdCBkZXRlcm1pbmluZyB0 aGUgdW5pcXVlbmVzcyBvZiBhIHN1YmplY3QgaXMgdG90YWxseSB0aGUgcmVzcG9uc2liaWxpdHkg b2YgdGhlIFJQLiBJdCBpcyB0aGVpciBzZXJ2aWNlIGRlbGl2ZXJ5IGFuZCB0aGV5IGhhdmUgdG8g ZGV0ZXJtaW5lIHdoYXQgdGhleSByZXF1aXJlIGluIG9yZGVyIGZvciB0aGVtIHRvIGJlIGFzc3Vy ZWQgdGhhdCB0aGV5IGFyZSBkZWFsaW5nIHdpdGggYSB1bmlxdWUNCiBzdWJqZWN0LiBJIHVzZSBz dWJqZWN0IGluIG9yZGVyIHRvIGluY2x1ZGUgdGhlIElPVCBpbiB0aGUgcG9zc2libGUgc29sdXRp b24uIElmIEknbSByZWFkaW5nIHdoYXQgeW91IHNheSBjb3JyZWN0bHksIG9uZSBvZiB0aGUgY29u c2lkZXJhdGlvbnMgdGhhdCBhIFJQIG1pZ2h0IHVzZSB0byBkZXRlcm1pbmUgdW5pcXVlbmVzcyBp cyB0aGUgbGV2ZWwgb2YgcHJvb2ZpbmcgdGhleSByZXF1aXJlIG9uIDEpIGVhY2ggb2YgdGhlIGF0 dHJpYnV0ZXMgYW5kDQogMikgdGhlIHNldCBvZiBhdHRyaWJ1dGVzLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NeSBleHBlcmllbmNlIHdpdGgg UlBzIGFsaWducyB3aXRoJm5ic3A7SnVsaWFuJ3MuJm5ic3A7V2hpbGUgUlBzJm5ic3A7dXN1YWxs eSBhc2sgZm9yIHVuaXF1ZW5lc3MgZnJvbSB0aGVpciBkaWdpdGFsIHN1cHBsaWVyIHRoZXkgZG8g bm90IGRvIHNvIGluIHRoZSBtYW51YWwgd29ybGQuIE15IHRhY3RpYyBoYXMgYmVlbiB0byBhc2sg d2h5IHRoZXkgYXJlIGFza2luZyBmb3IgaXQgaW4gdGhlIGRpZ2l0YWwgd29ybGQgYW5kIG5vdCBp biB0aGUNCiBtYW51YWwgd29ybGQuIFRoZSBkaXNjdXNzaW9uIGFyb3VuZCB0aGlzIHF1ZXN0aW9u ICh1c3VhbGx5IGFyb3VuZCAxKSB0aGVpciBwZXJjZWl2ZWQgYmVuZWZpdCBhbmQmbmJzcDsyKSB0 aGUgYWRkaXRpb25hbCBjb3N0IHZlcnN1cyB0aGVpciBwZXJjZWl2ZWQgYmVuZWZpdCkgbGVhZHMg dG8gdGhlbSBkcm9wcGluZyB0aGF0IHJlcXVpcmVtZW50IGZyb20gdGhlaXIgZGlnaXRhbCBzdXBw bGllci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+VGhlICZxdW90O2ltcG9zdGVyJnF1b3Q7IGRpc2N1c3Npb24gdXN1YWxseSB0YWtlcyB0aGUg c2FtZSBwYXRoLiBBc2tpbmcgdGhlIFJQIGhvdyB0aGV5IGRlYWwgd2l0aCBpbXBvc3RlcnMgaW4g dGhlIG1hbnVhbCB3b3JsZCB1c3VhbGx5IGxlYWRzIHRvIGEgY29uY2x1c2lvbiB0aGF0IHRoZXkg Y2FuIGVtcGxveSB0aGUgc2FtZSB0YWN0aWNzIGFuZCBwcm9jZXNzZXMgb25seSB1c2luZyBkaWdp dGFsIGRhdGEuIENvc3QgZWZmZWN0aXZlbmVzcw0KIGlzIHVzdWFsbHkgYSBiaWcgcGFydCBvZiB0 aGUgZGlzY3Vzc2lvbi4gVGhpcyBzaG91bGQgbm90IGJlIGxpa2VuZWQgdG8gcGF2aW5nIHRoZSBj b3cgcGF0aC4gV2hhdCB1c3VhbGx5IGhhcHBlbnMgaXMgdGhhdCB0aGV5IHJlYWxpemUgdGhhdCwg aW4gdGhlIGRpZ2l0YWwgd29ybGQsIHRoZXkgbWlnaHQgYmUgYWJsZSB0byBkZXRlY3QgYW4gaW1w b3N0ZXIgZmFzdGVyIGJlY2F1c2UgdGhleSBoYXZlIGZhc3RlciBhY2Nlc3MgdG8gdGhlIGRhdGEg dGhleQ0KIHVzZSB0byBkZXRlY3QgaW1wb3N0ZXJzLiBJbiBzb21lIGNhc2VzLCB0aGV5IG1heSBy ZWFsaXplIGltcHJvdmVkIGRldGVjdGlvbiBiZWNhdXNlIHRoZSBwcm9vZmluZyBkYXRhIGlzIGxp a2VseSBiZXR0ZXIgdGhhbiB0aGV5IGhhdmUgYXZhaWxhYmxlIGluIHRoZSBtYW51YWwgd29ybGQu Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkl0IGlzIG15IG9waW5pb24gdGhhdCwgYXMgdGhlaXIgcHJvY2Vzc2VzIGV2b2x2ZSBpbiB0 aGUgZGlnaXRhbCB3b3JsZCwgdGhleSB3aWxsIGJlY29tZSBmYXN0ZXIgYXQgaW1wb3N0ZXIgZGV0 ZWN0aW9uIGFuZCByZXNvbHV0aW9uLiBJdCBpcyBhbHNvIG15IG9waW5pb24gdGhhdCBwcmV2ZW50 aW9uIG9mIGltcG9zdGVycyBiZWZvcmUgdGhleSBoYXBwZW4sIGxpa2UgdGhlIHRvdGFsbHkgc2Vj dXJlIHN5c3RlbSwNCiBpcywgaWYgbm90IGltcG9zc2libGUsIG5vdCZuYnNwO2EgY29zdCBlZmZl Y3RpdmUgZ29hbCB0byBhY2hpZXZlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5LZW4gRGFnZzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KT24gRnJpZGF5LCAxOCBNYXJjaCAyMDE2LCBKdWxp YW4gV2hpdGUgJmx0OzxhIGhyZWY9Im1haWx0bzpqd2hpdGVAbnUtZC5jb20iPmp3aGl0ZUBudS1k LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SSB3b3VsZCBzYXksIGFzIEkgaGF2ZSBpbiB0aGUgSVNPIDI5MDAzIGRpc2N1c3Np b25zLCB0aGF0IHVuaXF1ZW5lc3MgaXMgaW4gZmFjdCBpcnJlbGV2YW50IGluIHRlcm1zIG9mIHRo ZSBsZXZlbCBvZiBwcm9vZmluZy4gSSBzZWUgbm8gbmVlZCB0byBrbm93IHdoZXRoZXIgdGhhdCBz ZXQgb2YgYXR0cmlidXRlcyBpcyBwcm92ZW4gdG8gYmUgdW5pcXVlIGJ5IHRoZSBwcm9vZmluZyBw cm92aWRlci4gVW5pcXVlbmVzcw0KIGlzIGhpZ2hseSBkZXBlbmRlbnQgb24gdGhlIGNvbnRleHQs IHdoaWNoIHJhaXNlcyBhbGwgc29ydHMgb2YgcHJvYmxlbXMgaWYgeW91IGhhdmUgYW4gaWRlbnRp dHkgZmVkZXJhdGlvbiAoaG93IGRvIEkga25vdyBpdHMgdW5pcXVlIGFjcm9zcyB0aGUgZmVkZXJh dGlvbj8gSWYsIGFzIGFuIFJQLCBJIGNhbiBjYW4gY29wZSB3aXRoIG5vbi11bmlxdWVuZXNzIGFj cm9zcyB0aGUgZmVkZXJhdGlvbiB0aGVuJm5ic3A7bm9uLXVuaXF1ZW5lc3MmbmJzcDt3aXRoaW4g dGhlDQogcHJvb2ZpbmcgcHJvdmlkZXIgaXMgYWxzbyBub3QgYSBwcm9ibGVtKS48bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIG15IHZpZXcgaXQgaXMgZm9y IHRoZSBSUCwgb3IgaWRlbnRpdHkgZmVkZXJhdGlvbiBzY2hlbWUsIHRvIGRlY2lkZSB3aGljaCBh dHRyaWJ1dGVzIGFyZSByZXF1aXJlZCBpbiB0aGVpciBjb250ZXh0LiBUaGV5IHNlbGVjdCBzdWZm aWNpZW50IGF0dHJpYnV0ZXMgdGhhdCBnaXZlIHRoZW0gdW5pcXVlbmVzcyAoaW4gdGhlaXIgY29u dGV4dCkgaWYgdGhhdCBpcyByZXF1aXJlZCwgZS5nLiBTU04gZm9yIHNvbWUNCiBzZXJ2aWNlcyAo dGhvdWdoIEkgd291bGQgYWR2aXNlIGFnYWluc3QgaXQhKS4gVGhlIHB1cnBvc2Ugb2YgdGhlIHBy b29maW5nIHByb2Nlc3MgaXMgdG8gZXhwcmVzcyB0byB3aGF0IGxldmVsIG9mIGNvbmZpZGVuY2Ug dGhhdCB0aG9zZSBhdHRyaWJ1dGVzIGFyZSB0cnVlIGFuZCBiZWxvbmcgdG8gdGhlIHBlcnNvbiBw cmVzZW50aW5nIHRoZW0sIGJlIHRoZXkgbmFtZSwgYWRkcmVzcywgZG9iLCBlbWFpbCBhZGRyZXNz LCBTU04gZXRjLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JbiBteSBkZWFsaW5ncyB3aXRoIFJQcyB0aGV5IGFyZSBjb25mdXNlZCBhYm91dCB0 aGlzIGFuZCBhc2sgZm9yICZxdW90O3VuaXF1ZW5lc3MmcXVvdDssIHRoaXMgaXMgdXN1YWxseSBm b2xsb3dlZCB1cCB3aXRoICZxdW90O2JlY2F1c2Ugd2UgY2FuJ3QgbGV0IHBlb3BsZSByZWdpc3Rl ciBtdWx0aXBsZSBpZGVudGl0aWVzJnF1b3Q7LiBUaGVyZSBpcyBhIGxhY2sgb2YgdW5kZXJzdGFu ZGluZyB0aGF0LCBhc3N1bWluZyB0aGUgcHJvb2ZpbmcgcHJvY2Vzcw0KIGlzIHdvcmtpbmcgY29y cmVjdGx5LCBpdCBkb2Vzbid0IG1hdHRlciBob3cgbWFueSB0aW1lcyB5b3UgZW5yb2wgeW91IGFy ZSBwcm92ZW4gdG8gYmUgdGhlIHNhbWUgcGVyc29uIGVhY2ggdGltZTsgaS5lLiBtdWx0aXBsZSBl bnJvbG1lbnRzIGxlYWQgdG8gdGhlIGlkZW50aWZpY2F0aW9uIG9mIHRoZSBzYW1lIHBlcnNvbiBi ZWluZyBib3VuZCB0byB0aGUgc2FtZSBhdHRyaWJ1dGVzLiBUaGVyZWZvcmUgaXQgaXNuJ3QgYWN0 dWFsbHkgYSBwcm9ibGVtDQogaW4gdGVybXMgb2YgdW5pcXVlbmVzcy4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TW9yZSBvZnRlbiB0 aGFuIG5vdCB0aGUgYXNrIGZvciB1bmlxdWVuZXNzIGlzIHJlYWxseSBhbiBleHByZXNzaW9uIG9m IGhvdyB3ZWxsIHRoZSBzeXN0ZW0gZGVmZW5kcyBpdHNlbGYgYWdhaW5zdCBpbXBvc3RvcnMgKGRp ZmZlcmVudCBwZW9wbGUgcmVnaXN0ZXJpbmcgZm9yIHRoZSBzYW1lIGF0dHJpYnV0ZXMpIHdoaWNo IGlzIGFjdHVhbGx5IHRoZSBwb2ludCBvZiB0aGUgZGlmZmVyZW50IGxldmVscyBvZiBwcm9vZmlu Zw0KICh0aGUgaGlnaGVyIHRoZSBsZXZlbHMgb2YgcHJvb2ZpbmcgdGhlIGhhcmRlciB0aGlzIHNo b3VsZCBiZWNvbWUpLiBEZW1hbmRpbmcgdW5pcXVlbmVzcyBkb2Vzbid0IGFjdHVhbGx5IGZpeCB0 aGUgaW1wb3N0b3IgcHJvYmxlbSwgeW91IGp1c3QgaW50cm9kdWNlIGEgdGltZSB0cmlhbCB0byB0 aGUgcHJvY2VzczsgdGhlIGZpcnN0IHBlcnNvbiB0byBnZXQgYm91bmQgdG8gdGhvc2UgYXR0cmli dXRlcyBsb2NrcyBvdXQgb3RoZXIgcGVvcGxlOyBpZg0KIHRoZSBmaXJzdCBwZXJzb24gdG8gY2xh aW0gdGhlbSB3YXMgdGhlIGltcG9zdG9yIHlvdSd2ZSBub3cgbG9ja2VkIG91dCB0aGUgZ2VudWlu ZSBwZXJzb24gLSB0aGV5IG5vdyBoYXZlIGEgaGVsbCBvZiB0aW1lIHVucGlja2luZyBhIG1lc3Mg bm90IG9mIHRoZWlyIG1ha2luZy4gSWYgdGhlIHN5c3RlbSBkZWZlbmRzIGFnYWluc3QgaW1wb3N0 b3JzIHByb3Blcmx5IGF0IHRoZSBoaWdoZXIgbGV2ZWxzIHRoZW4gdGhlIHVuaXF1ZW5lc3MgYWRk cyBsaXR0bGUNCiB2YWx1ZSBzaW5jZSBJIGNhbiBvbmx5IGJpbmQgdGhvc2UgYXR0cmlidXRlcyB0 byB0aGUgY29ycmVjdCBwZXJzb24gYW55d2F5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgdGhpbmcgdGhhdCBtYXkgbmVlZCB0byBiZSB1 bmlxdWUgaXMgdGhlIGFjY291bnQvcmVjb3JkIGF0IHRoZSBSUCwgYW5kIGl0cyB0aGUgUlAncyBy ZXNwb25zaWJpbGl0eSB0byBtYW5hZ2UgdGhhdC4gVGhpcyBpcyBhIHByb2JsZW0gdGhleSBoYXZl IHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciB0aGUgcHJvb2ZpbmcgcHJvdmlkZXIgdGVsbHMgdGhlbSBp dHMgdW5pcXVlIG9yIG5vdCBiZWNhdXNlIHRoZXkgb2Z0ZW4NCiBoYXZlIG11bHRpcGxlIG9uLWxp bmUgYW5kIG9mZmxpbmUgY2hhbm5lbHMgdGhhdCBkZWFsIHdpdGggdGhlaXIgY3VzdG9tZXJzLCB0 aGlzIGZvcmNlcyB0aGVtIHRvIHVuZGVyc3RhbmQgaG93IHRvIG1hdGNoIGRpZmZlcmVudCByZXBy ZXNlbnRhdGlvbnMgb2YgdGhlIGlkZW50aXR5IHRvIHRoZSBzYW1lIGFjY291bnQgd2hpY2ggdGVu ZHMgdG8gd29yayBhY3Jvc3MgY2hhbm5lbCBhbmQgd2l0aGluIHRoZSBzYW1lIGNoYW5uZWwuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvIGlu IHN1bW1hcnkgaXQgZG9lc24ndCBkcml2ZSBhbnkgcmVhbCB2YWx1ZSBpbiB0aGUgcHJvb2Zpbmcg cHJvdmlkZXIgdG8gZG8gdGhpcywgaXRzIGp1c3QgYSBjb3N0IG9mIGVmZm9ydCBmb3IgbGl0dGxl IGdhaW4gdGhhdCB0aGUgUlAgaXMgZ29pbmcgdG8gcmVwZWF0IHJlZ2FyZGxlc3MgaWYgdGhleSBj YXJlIGFib3V0IHVuaXF1ZW5lc3MuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkp1bGlhbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMTcgTWFyY2ggMjAxNiBhdCAy MTo0OSwgSm9hbm5lIEtuaWdodCAmbHQ7PGEgaHJlZj0iamF2YXNjcmlwdDpfZSglN0IlN0QsJ2N2 bWwnLCdKb2FubmUuS25pZ2h0QGRpYS5nb3Z0Lm56Jyk7IiB0YXJnZXQ9Il9ibGFuayI+Sm9hbm5l LktuaWdodEBkaWEuZ292dC5uejwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VGhlIHNob3J0IGFuc3dlciB0byB5b3VyIHF1ZXN0aW9uIC0gTm8uPGJy Pg0KPGJyPg0KWW91ciB1c2UgY2FzZSBpcyBzaWxlbnQgb24gdGhlIGxldmVsIG9mIHZldHRpbmcg cmVxdWlyZWQgKGhvdyByZWFsIGRvZXMgdGhlIGlkZW50aXR5IGhhdmUgdG8gYmUpLiBZb3UgY2Fu IGhhdmUgYW55IGxldmVsIG9mIGlkZW50aXR5IGFuZCBzdGlsbCBjb2xsZWN0IGEgYmlvbWV0cmlj IGZvciB0aGUgcHVycG9zZXMgb2Ygb25lIGFuZCBvbmx5IG9uZSB1bmlxdWVuZXNzLiBJIHdvdWxk IHBvc2UgaG93ZXZlciB0aGF0IGl0IGlzIHZlcnkgdW51c3VhbA0KIGZvciBvbmUgYW5kIG9ubHkg b25lIGFzc3VyYW5jZSB0byBiZSByZXF1aXJlZCB3aXRob3V0IHNvbWUgb3RoZXIgZHJpdmVyIHJl cXVpcmluZyBhbiBlbGV2YXRlZCBsZXZlbCBvZiByZWFsbmVzcy48YnI+DQo8YnI+DQpJbiB5b3Vy IHVzZSBjYXNlIEkgd291bGQgc3VnZ2VzdCB0aGF0IHRoZXJlIGlzIGFsc28gYSByZXF1aXJlbWVu dCB0aGF0IGEgcXVhbGlmaWNhdGlvbiBpcyBpc3N1ZWQgdG88YnI+DQphKSB0aGUgcGVyc29uIGNh cnJ5aW5nIG91dCB0aGUgc3R1ZHkgYW5kPGJyPg0KYikgYW4gaWRlbnRpdHkgb2Ygc3VjaCByaWdv dXIgdGhhdCB0aGVpciAob3IgdGhlIHVuaXZlcnNpdHkncykgZWxpZ2liaWxpdHkgZm9yIHB1Ymxp YyBmdW5kaW5nIGNhbiBiZSBlc3RhYmxpc2hlZCBhbmQ8YnI+DQpjKSBhbiBpZGVudGl0eSB0aGF0 IGlzIGdvaW5nIHRvIGJlIHRlc3RlZCBieSBmdXR1cmUgZW1wbG95ZXJzLjxicj4NCjxicj4NClRo ZXJlZm9yZSB5b3UgYXJlIHByb2JhYmx5IGxvb2tpbmcgYXQgUDIgb3IgUDMgZGVwZW5kaW5nIG9u IHRoZSBsZXZlbC90eXBlIG9mIHF1YWxpZmljYXRpb24uIChJIG1pZ2h0IHdhbnQgUDMgaWYgdGhl IHF1YWxpZmljYXRpb24gaXMgZm9yIGJyYWluIHN1cmdlb24gb3IgY29tbWVyY2lhbCBwaWxvdCku PGJyPg0KPGJyPg0KQXMgb25lIGFuZCBvbmx5IG9uZSBpcyByZWFsbHkgb25seSBhYmxlIHRvIGJl IGFjaGlldmVkIHRocm91Z2ggdGhlIHVzZSBvZiBhIGJpb21ldHJpYywgd2Ugbm93IGhhdmUgdG8g Y29uc2lkZXIgJ2FjY2VwdGFiaWxpdHknLjxicj4NCkRvZXMgdGhlIGNvbGxlY3Rpb24gb2YgYSBi aW9tZXRyaWMgKGFuZCBhbGwgdGhhdCBpdCBlbnRhaWxzIC0gY29zdCwgcHJpdmFjeSwgc2VjdXJp dHksIHVzZXIgYWNjZXB0YW5jZSBldGMuKSBvdXR3ZWlnaCB0aGUgaW1wYWN0IGNhdXNlZCBieSBh IGR1cGxpY2F0ZSBlbnRpdHkgaW4gdGhlIHN5c3RlbT88YnI+DQpJbiBvdGhlciB3b3JkcywgZG8g eW91IHJlYWxseSBuZWVkIG9uZSBhbmQgb25seSBvbmUgKHRoZSAzcmQgbGV2ZWwgb2YgdW5pcXVl bmVzcykgb3IgY291bGQgc3VmZmljaWVudCBzaW5ndWxhcml0eSBiZSBnYWluZWQgZnJvbSBsZXZl cmFnaW5nIHRoZSBzb2NpYWwgc2VjdXJpdHkgbnVtYmVyJ3MgdW5pcXVlbmVzcyBhbmQgYW4gZXF1 aXZhbGVudCBsZXZlbCBvZiB2YWxpZGF0aW9uIGFuZCBvd25lcnNoaXAgdGVzdCAodGhlIDJuZCBs ZXZlbCBvZiB1bmlxdWVuZXNzKQ0KIGkuZS4gbm8gUHU/PGJyPg0KPGJyPg0KV2UgbXVzdCByZW1l bWJlciB0aGUgbXV0dWFsIGV4Y2x1c2l2aXR5IGJldHdlZW4gYXR0cmlidXRlcyBjb2xsZWN0ZWQs IHZldHRpbmcgdW5kZXIgdGFrZW4gYW5kIGxldmVsIG9mIHVuaXF1ZW5lc3MuPGJyPg0KPGJyPg0K SGFwcHkgdG8gZGlzY3VzcyBmdXJ0aGVyIGlmIHRoaXMgbWFrZXMgbm8gc2Vuc2UuPGJyPg0KPGJy Pg0KQ2hlZXJzPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS08YnI+DQpGcm9tOiBSb2xmIEJydWdnZXIgW21haWx0bzo8YSBocmVmPSJqYXZhc2NyaXB0Ol9l KCU3QiU3RCwnY3ZtbCcsJ3JvbGYuYnJ1Z2dlckBzd2l0Y2guY2gnKTsiIHRhcmdldD0iX2JsYW5r Ij5yb2xmLmJydWdnZXJAc3dpdGNoLmNoPC9hPl08bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2VudDogVGh1cnNkYXksIDE3IE1hcmNoIDIwMTYgMTE6 MzUgcC5tLjxicj4NClRvOiA8YSBocmVmPSJqYXZhc2NyaXB0Ol9lKCU3QiU3RCwnY3ZtbCcsJ3Zv dEBpZXRmLm9yZycpOyIgdGFyZ2V0PSJfYmxhbmsiPnZvdEBpZXRmLm9yZzwvYT48YnI+DQpTdWJq ZWN0OiBSZTogW1ZvVF0gSG93IHRvIGV4cHJlc3MgZHVwbGljYXRlIGNoZWNrcyB3aXRoIFZvVD88 YnI+DQo8YnI+DQpIaSBhbGwsPGJyPg0KPGJyPg0KVGhhbmtzIGZvciBhbGwgeW91ciByZXNwb25z ZXMgYW5kIGlkZWFzLiBXZSBoYXZlIGRpc2N1c3NlZCB5b3VyIGlucHV0cyBpbiBvdXIgcHJvamVj dCB0ZWFtICh3aGljaCBpcyB3aHkgaXQgdG9vayBtZSBzb21lIHRpbWUgdG8gcmVzcG9uZCk8YnI+ DQo8YnI+DQpJIHdhcyB3b25kZXJpbmcgd2hhdCBhY3R1YWxseSB0aGUgZGlmZmVyZW5jZXMgYXJl IGJldHdlZW4gdGhlIHRocmVlIGxldmVscyBvZiB1bmlxdWVuZXNzIGRlc2NyaWJlZCBieSBKb2Fu bmUuIEluIGVhY2ggb2YgdGhlIHRocmVlIGxldmVscyBhIHNldCBvZiBhdHRyaWJ1dGVzIGlzIHVz ZWQgdG8gZGV0ZXJtaW5lIGlmIGFuIGlkZW50aXR5IGlzIHVuaXF1ZSB3aXRoaW4gYSBwb3B1bGF0 aW9uIG9mIGlkZW50aXRpZXMuIFRoZSBkaWZmZXJlbmNlIGlzDQogMSkgd2hhdCBleGFjdCBzZXQg b2YgYXR0cmlidXRlcyBpcyB1c2VkIGluIGVhY2ggbGV2ZWwgYW5kIDIpIHRoZSB2ZXR0aW5nIGxl dmVsIG9mIHRoZSBhdHRyaWJ1dGVzLiBSaWdodD88YnI+DQo8YnI+DQpBIGNvbmNyZXRlIGV4YW1w bGUgbWlnaHQgYmU8YnI+DQo8YnI+DQpGaXJzdCBsZXZlbDo8YnI+DQotIGF0dHJpYnV0ZXM6IE5h bWUsIGVtYWlsLCBwaG9uZSBudW1iZXI8YnI+DQotIHZldHRpbmcgbGV2ZWw6IFAxPGJyPg0KPGJy Pg0KU2Vjb25kIGxldmVsOjxicj4NCi0gYXR0cmlidXRlczogTmFtZSwgZW1haWwsIHBob25lIG51 bWJlciwgc29jaWFsIHNlY3VyaXR5IG51bWJlcjxicj4NCi0gdmV0dGluZyBsZXZlbDogUDI8YnI+ DQo8YnI+DQpUaGlyZCBsZXZlbDo8YnI+DQotIGF0dHJpYnV0ZXM6IGZpbmdlciBwcmludCBvciBy ZXRpbmEgc2Nhbjxicj4NCi0gdmV0dGluZyBsZXZlbDogUDM8YnI+DQo8YnI+DQpUaGUgYXBwcm9w cmlhdGUgc2V0IG9mIGF0dHJpYnV0ZXMgdG8gYmUgdXNlZCBpbiBlYWNoIGxldmVsIGlzIGNlcnRh aW5seSBjb250ZXh0LXNwZWNpZmljLiBBcyBFcmljIHBvaW50cyBvdXQgaXQgd2lsbCBiZSBkaWZm aWN1bHQgdG8gZGVmaW5lIGFuZCBhZ3JlZSBvbiBhIGdlbmVyaWMgZGVmaW5pdGlvbiBvZiB0aGUg c2NvcGUuPGJyPg0KPGJyPg0KTWF5YmUgaXQncyB0aW1lIHRvIGRlc2NyaWJlIG91ciB1c2UgY2Fz ZXMgaGVyZS4gSW4gdGhlIElkTSBzZXJ2aWNlIHdlIGFyZSBwbGFubmluZyBpbmRpdmlkdWFscyBz ZWxmLXJlZ2lzdGVyIHRoZWlyIGlkZW50aXRpZXMuIFdpdGggc3VjaCBhbiBpZGVudGl0eSwgaW5k aXZpZHVhbHMgY2FuIHJlZ2lzdGVyIGZvciBzdHVkaWVzIGF0IGEgdW5pdmVyc2l0eS4gQnV0IG9u ZSBpbmRpdmlkdWFsIG1heSBvbmx5IHJlZ2lzdGVyIG9uY2UgYXQgdGhlIHNhbWUNCiB1bml2ZXJz aXR5LiBBbm90aGVyIGNhc2UgaXMgYSB1c2VyJ3MgbGlicmFyeSBhY2NvdW50IHRoYXQgd2FzIGJs b2NrZWQgYmVjYXVzZSBvZiB2aW9sYXRpb25zIG9mIHRoZSBsaWJyYXJ5J3MgdXNhZ2UgdGVybXMu IFN1Y2ggYSB1c2VyIHNob3VsZCBub3QgYmUgYWJsZSB0byBqdXN0IGNyZWF0ZSBhIG5ldyBhY2Nv dW50IHRvIHVzZSB0aGUgbGlicmFyeSBzZXJ2aWNlcyBhZ2Fpbi48YnI+DQo8YnI+DQpXaXRoIEp1 c3RpbidzIHN1Z2dlc3Rpb24gb2YgYSBQdSBjYXRlZ29yeSwgdGhlIHJlcXVpcmVtZW50cyBpbiBv dXIgdXNlIGNhc2VzIGNvdWxkIGJlIGV4cHJlc3NlZCBhcyBQMS5QdSBvciBQMi5QdS4gVGhlIHNl bWFudGljcyBvZiAmcXVvdDtQMi5QdSZxdW90Ozxicj4NCndvdWxkIHRoZW4gYmU6IFByb29mZWQg dW5pcXVlIGJhc2VkIG9uIGFuIGF0dHJpYnV0ZSBzZXQgd2l0aCB0aGUgdmV0dGluZyBsZXZlbCBQ Mi48YnI+DQo8YnI+DQpjaGVlcnM8YnI+DQo8YnI+DQpSb2xmPGJyPg0KPGJyPg0KPGJyPg0KPGJy Pg0KT24gMTEuMDMuMTYgMDI6NTYsIEpvYW5uZSBLbmlnaHQgd3JvdGU6PGJyPg0KJmd0OyBIaSBB bGw8YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGVyZSBhcmUgdGhyZWUgYXNwZWN0IG9yIGxldmVscyB3 aGVuIGxvb2tpbmcgYXQgdW5pcXVlbmVzcyB0byBiZTxicj4NCiZndDsgY29uc2lkZXJlZC48YnI+ DQomZ3Q7PGJyPg0KJmd0OyBGaXJzdCBsZXZlbCBpcyB0aGF0IHRoZSBpZGVudGl0eSBpcyB1bmlx dWUgLSB0aGF0IGlzLCB3aXRoaW4gYSBjb250ZXh0PGJyPg0KJmd0OyB0aGVyZSBpcyBhIHNldCBv ZiBhdHRyaWJ1dGVzIHRoYXQgYXJlIHVuaXF1ZSBmb3IgZWFjaCBpZGVudGl0eTxicj4NCiZndDsg cmVnaXN0ZXJlZC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBTZWNvbmQgbGV2ZWwgaXMgc29sZSBjbGFp bWFudCAtIHRoaXMgaXMgYSBjaGVjayB0aGF0IG9ubHkgb25lIGVudGl0eTxicj4NCiZndDsgaGFz IGNsYWltZWQgYSBwYXJ0aWN1bGFyIHNldCBvZiBhdHRyaWJ1dGVzLiBBdCB0aGUgaGlnaGVyIGxl dmVscyBvZjxicj4NCiZndDsgaWRlbnRpdHkgcHJvb2Zpbmcgd2hlcmUgYXV0aG9yaXRhdGl2ZSBz b3VyY2VzIGFyZSB1c2VkIGl0IG1heSBiZTxicj4NCiZndDsgcG9zc2libGUgdG8gYWNoaWV2ZSB0 aGlzLiBUaGlzIGlzIHN1ZmZpY2llbnQgaW4gbW9zdCBSUHMgY2FzZXMuIEF0PGJyPg0KJmd0OyB0 aGlzIGxldmVsIHdoaWxlIGl0IGlzIHBvc3NpYmxlIGZvciBhIHNpbmdsZSBlbnRpdHkgdG8gY2xh aW0gbW9yZSB0aGFuPGJyPg0KJmd0OyBvbmUgaWRlbnRpdHksIHRoZXkgZG8gc28gYXQgdGhlIHJp c2sgb2YgY2F1c2luZyBhIGNvdW50ZXItZnJhdWQgZmxhZzxicj4NCiZndDsgc2hvdWxkIHRoZSBy ZWFsIG93bmVyIChvciBhbnkgb3RoZXIgcGFydHkpIGFsc28gYXR0ZW1wdCB0byBjbGFpbSB0aGU8 YnI+DQomZ3Q7IGlkZW50aXR5Ljxicj4NCiZndDs8YnI+DQomZ3Q7IFRoZSBmaW5hbCBsZXZlbCBp cyBvbmUgYW5kIG9ubHkgb25lIC0gVGhpcyBpcyBhIGNoZWNrIC0gdXN1YWxseTxicj4NCiZndDsg YmlvbWV0cmljIC0gdGhhdCBhbiBlbnRpdHkgaGFzIG9ubHkgb25lIGNsYWltIGluIHRoZSBjb250 ZXh0LiBUaGlzIGlzPGJyPg0KJmd0OyB1c3VhbGx5IG9ubHkgcmVzZXJ2ZWQgZm9yIHRoZSBoaWdo ZXN0IGxldmVsIG9mIGlkZW50aXR5IGFuZCB3b3VsZCBhbHNvPGJyPg0KJmd0OyByZXF1aXJlIGVx dWFsbHkgaGlnaCBsZXZlbHMgb2YgY3JlZGVudGlhbCBhbmQgY3JlZGVudGlhbCBpc3N1YW5jZTxi cj4NCiZndDsgcHJvY2Vzc2VzLjxicj4NCiZndDs8YnI+DQomZ3Q7IEFzIHRvIGhvdyB0aGlzIHJl bGF0ZXMgdG8gVm9UIC0gVGhlIGZpcnN0IHNob3VsZCBiZSBpbm5hdGVseSBidWlsdDxicj4NCiZn dDsgaW50byBhbGwgbGV2ZWxzIG9mIFAgLSBpdCBpcyB0aGUgc29sZSByZXF1aXJlbWVudCBvZiBh bGwgbGV2ZWxzPGJyPg0KJmd0Ozxicj4NCiZndDsgVGhlIHNlY29uZCBjb3VsZCBiZSBidWlsdCBp bnRvIFAzIGlmIHRoZSB3b3JkaW5nIHdhcyBhbWVuZGVkIHNsaWdodGx5Ljxicj4NCiZndDs8YnI+ DQomZ3Q7IFRoZSBsYXN0IGl0ZW0gb25seSBpcyBzdWJzdGFudGl2ZWx5IG1pc3NpbmcgYW5kIHRv IGRhdGUgKGluIHRoZTxicj4NCiZndDsgY29udmVyc2F0aW9ucyBJIGhhdmUgYmVlbiBoYXZpbmcg ZWxzZXdoZXJlKSB0aGVyZSBoYXMgYmVlbjxicj4NCiZndDsgaW5zdWZmaWNpZW50IGFwcGV0aXRl IHRvIGFkZCBpdCBhcyBhbiBleHBsaWNpdCByZXF1aXJlbWVudC48YnI+DQomZ3Q7PGJyPg0KJmd0 OyBTaG91bGQgd2UgaGF2ZSBhIFBVPyBNYXliZSwgYnV0IHN0ZWVyIGNsZWFyIG9mIHRoZSB0ZXJt ICd1bmlxdWUnIElmIHdlPGJyPg0KJmd0OyBkbywgaW4gbXkgbWluZCBpdCB3b3VsZCBvbmx5IGhh dmUgdHdvIHZhbHVlcyAtIFA/MCAtIENsYWltcyBwZXIgZW50aXR5PGJyPg0KJmd0OyBub3QgY2hl Y2tlZCwgUD8xIC0gQ2xhaW1zIHBlciBlbnRpdHkgcmVzdHJpY3RlZCB0byBvbmUuPGJyPg0KJmd0 Ozxicj4NCiZndDsgSm9hbm5lPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tIEZyb206IFJvbGYgQnJ1Z2dlcjxicj4NCiZndDsgW21haWx0bzo8 YSBocmVmPSJqYXZhc2NyaXB0Ol9lKCU3QiU3RCwnY3ZtbCcsJ3JvbGYuYnJ1Z2dlckBzd2l0Y2gu Y2gnKTsiIHRhcmdldD0iX2JsYW5rIj5yb2xmLmJydWdnZXJAc3dpdGNoLmNoPC9hPl0gU2VudDog RnJpZGF5LCAxMSBNYXJjaCAyMDE2IDU6NTEgYS5tLjxicj4NCiZndDsgVG86IDxhIGhyZWY9Imph dmFzY3JpcHQ6X2UoJTdCJTdELCdjdm1sJywndm90QGlldGYub3JnJyk7IiB0YXJnZXQ9Il9ibGFu ayI+dm90QGlldGYub3JnPC9hPiBTdWJqZWN0OiBbVm9UXSBIb3cgdG8gZXhwcmVzcyBkdXBsaWNh dGUgY2hlY2tzIHdpdGg8YnI+DQomZ3Q7IFZvVD88YnI+DQomZ3Q7PGJyPg0KJmd0OyBIaSBhbGws PGJyPg0KJmd0Ozxicj4NCiZndDsgSSdtIG5ldyB0byB0aGlzIGxpc3QgYW5kIEkgaG9wZSBteSBx dWVzdGlvbiBpcyBub3QgdG90YWxseSBpcnJlbGV2YW50PGJyPg0KJmd0OyBoZXJlLjxicj4NCiZn dDs8YnI+DQomZ3Q7IFdlIGhhdmUgcGxlbnR5IG9mIHVzZSBjYXNlcyB3aGVyZSBSUHMgbmVlZCB0 byBoYXZlIGNvbmZpZGVuY2UsIHRoYXQgYTxicj4NCiZndDsgcGVyc29uIGRvZXMgbm90IGhhdmUg bXVsdGlwbGUgaWRlbnRpdGllcyBpbiBvbmUgSWRQLiBJIGRvbid0IHNlZSBob3c8YnI+DQomZ3Q7 IHRoaXMgYXNwZWN0IG9mIGlkZW50aXR5IHF1YWxpdHkgY2FuIGJlIGV4cHJlc3NlZCwgYW5kIEkg YmVsaWV2ZSBpdCBpczxicj4NCiZndDsgcHJldHR5IG9ydGhvZ29uYWwgdG8gdGhlIFAsIEMsIE0g YW5kIEEgZGltZW5zaW9ucyB0aGF0IGFyZSBjdXJyZW50bHk8YnI+DQomZ3Q7IHNwZWNpZmllZCBp biB0aGUgVm9UIGRyYWZ0Ljxicj4NCiZndDs8YnI+DQomZ3Q7IFdlIGNvdWxkIGltYWdpbmUgbXVs dGlwbGUgd2F5cyB0byBncmFkdWFsbHkgcHJvdmUgdGhhdCBhbiBpZGVudGl0eSBoYXM8YnI+DQom Z3Q7IGJlZW4gY2hlY2tlZCBhZ2FpbnN0IGR1cGxpY2F0ZXMuIFRoZSBtb3N0IHN0cmFpZ2h0Zm9y d2FyZCBhcHByb2FjaDxicj4NCiZndDsgd291bGQgYmUgdG8gbWFrZSBzdXJlIHRoYXQgdW5pcXVl IHBlcnNvbmFsIGF0dHJpYnV0ZXMgYXJlIHVzZWQgb25seTxicj4NCiZndDsgb25jZSB3aXRoaW4g b25lIElkUCBvciBhbiBJZFAgZmVkZXJhdGlvbiwgbGlrZSAtIGVtYWlsPGJyPg0KJmd0OyBhZGRy ZXNzKGVzKSAtIG1vYmlsZSBwaG9uZSBudW1iZXIgLSBob21lIHBvc3RhbCBhZGRyZXNzIC0gc29j aWFsPGJyPg0KJmd0OyBzZWN1cml0eSBudW1iZXIgLSBJRCAvIHBhc3Nwb3J0IG51bWJlciAtIHRo ZSBjb21iaW5hdGlvbiBvZiBuYW1lIGFuZDxicj4NCiZndDsgYmlydGggZGF0ZSAtIGV0Yy48YnI+ DQomZ3Q7PGJyPg0KJmd0OyBXb3VsZCBpdCBtYWtlIHNlbnNlIHRvIGV4cHJlc3MgdGhpcyBpbiBW b1Q/PGJyPg0KJmd0Ozxicj4NCiZndDsgYmVzdCByZWdhcmRzPGJyPg0KJmd0Ozxicj4NCiZndDsg Um9sZjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAtLSBTV0lUQ0ggLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0gUm9sZiBCcnVnZ2VyLCBwcm9qZWN0IFN3aXNzPGJyPg0KJmd0OyBlZHUt SUQgV2VyZHN0cmFzc2UgMiwgUC5PLiBCb3gsIDgwMjEgWnVyaWNoLCBTd2l0emVybGFuZCBwaG9u ZSAmIzQzOzQxIDQ0PGJyPg0KJmd0OyAyNjggMTUgMTUsIGRpcmVjdCA8YSBocmVmPSJ0ZWw6JTJC NDElMjA0NCUyMDI2OCUyMDE1JTIwODkiIHRhcmdldD0iX2JsYW5rIj4mIzQzOzQxIDQ0IDI2OCAx NSA4OTwvYT4NCjxhIGhyZWY9ImphdmFzY3JpcHQ6X2UoJTdCJTdELCdjdm1sJywncm9sZi5icnVn Z2VyQHN3aXRjaC5jaCcpOyIgdGFyZ2V0PSJfYmxhbmsiPg0Kcm9sZi5icnVnZ2VyQHN3aXRjaC5j aDwvYT4sPGJyPg0KJmd0OyA8YSBocmVmPSJodHRwOi8vd3d3LnN3aXRjaC5jaCIgdGFyZ2V0PSJf YmxhbmsiPmh0dHA6Ly93d3cuc3dpdGNoLmNoPC9hPjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0K Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyB2b3Qg bWFpbGluZyBsaXN0PGJyPg0KJmd0OyA8YSBocmVmPSJqYXZhc2NyaXB0Ol9lKCU3QiU3RCwnY3Zt bCcsJ3ZvdEBpZXRmLm9yZycpOyIgdGFyZ2V0PSJfYmxhbmsiPnZvdEBpZXRmLm9yZzwvYT4NCjxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdm90IiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92b3Q8L2E+PGJy Pg0KJmd0Ozxicj4NCjxicj4NCi0tPGJyPg0KU1dJVENIPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS08YnI+DQpSb2xmIEJydWdnZXIsIHByb2plY3QgU3dpc3MgZWR1LUlEPGJyPg0KV2Vy ZHN0cmFzc2UgMiwgUC5PLiBCb3gsIDgwMjEgWnVyaWNoLCBTd2l0emVybGFuZCBwaG9uZSA8YSBo cmVmPSJ0ZWw6JTJCNDElMjA0NCUyMDI2OCUyMDE1JTIwMTUiIHRhcmdldD0iX2JsYW5rIj4NCiYj NDM7NDEgNDQgMjY4IDE1IDE1PC9hPiwgZGlyZWN0IDxhIGhyZWY9InRlbDolMkI0MSUyMDQ0JTIw MjY4JTIwMTUlMjA4OSIgdGFyZ2V0PSJfYmxhbmsiPg0KJiM0Mzs0MSA0NCAyNjggMTUgODk8L2E+ IDxhIGhyZWY9ImphdmFzY3JpcHQ6X2UoJTdCJTdELCdjdm1sJywncm9sZi5icnVnZ2VyQHN3aXRj aC5jaCcpOyIgdGFyZ2V0PSJfYmxhbmsiPg0Kcm9sZi5icnVnZ2VyQHN3aXRjaC5jaDwvYT4sIDxh IGhyZWY9Imh0dHA6Ly93d3cuc3dpdGNoLmNoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy5z d2l0Y2guY2g8L2E+PGJyPg0KPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQp2b3QgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0i amF2YXNjcmlwdDpfZSglN0IlN0QsJ2N2bWwnLCd2b3RAaWV0Zi5vcmcnKTsiIHRhcmdldD0iX2Js YW5rIj52b3RAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby92b3QiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3ZvdDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQotLSA8YnI+DQpLZW5uZXRoIERh Z2c8YnI+DQpJbmRlcGVuZGVudCBDb25zdWx0YW50PGJyPg0KSWRlbnRpZmljYXRpb24gYW5kIEF1 dGhlbnRpY2F0aW9uPGJyPg0KNjEzLTgyNS0yMDkxPGJyPg0KPGEgaHJlZj0ibWFpbHRvOmtlbmRh Z2d0YnNAZ21haWwuY29tIj5rZW5kYWdndGJzQGdtYWlsLmNvbTwvYT48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_569AD906E45DB44A8AFF11D61F5DA7910155C81DA5AKLDRMBX03dia_-- From nobody Wed Mar 30 08:12:07 2016 Return-Path: X-Original-To: vot@ietfa.amsl.com Delivered-To: vot@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C8F012D161 for ; Wed, 30 Mar 2016 08:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nu-d.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MaTxLIioqLpB for ; Wed, 30 Mar 2016 08:12:01 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::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 6036812D108 for ; Wed, 30 Mar 2016 08:12:01 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id 127so101479703wmu.1 for ; Wed, 30 Mar 2016 08:12:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nu-d.com; s=nud; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=evFNYxY+IzIvEMZdjVib1836cV7qpNq5os4T4DU3XOQ=; b=ln5nVIAr8CKnLIY/7UnITkk5Kq21pBOy+pQeNRgbgvoNhvcohFIVbAgWUyaWo2759N Dyh2ed3kOhwSk47JRvvAwhy0zCHJ7fNYe48UIVIY6cFv1BBOIE8My9YovNa41x9FDkCw 7Qe6YjBTcLkmOSnHQ3/uJ//ucgnvnjaF9pvkw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=evFNYxY+IzIvEMZdjVib1836cV7qpNq5os4T4DU3XOQ=; b=SNMeJL//ztVaCMwfatvlI5KAxJ0Gir2xrexCDorl+moKq2HGCkXBySgQozXMmTbxRv LC1a/4bQA6WTUOtPX9j4OaSoo5hSmkQMIY2mswlED/IxLwTb5zHxwheHukFDwvptfKRZ WHQRn1jilqDQLkqWiuhByiKIhr4k1isDwNiX9A865/e8sCscetJMaFj13TEJc9KacOjG BfoBqoaehhY7L24Zss0evJusU7V/OVJkBuhjccotxe4b4Cykc7GRwpKBM1W2nKOFQ/3U ep+o6c8VFbyNzz1tGHXgd5V3tpOkyd/WzGkzbySIAMKARlvXBGDUc3QtBHHpQF9LfsAj j+7g== X-Gm-Message-State: AD7BkJK3CWr4RE4MrjscH9+FHRZ8CfksC4WVfte2LeS0jONt3+V6SHURNW4+HNfgBOnVnpLE+AEzXjUMKPbkWyuR X-Received: by 10.194.184.38 with SMTP id er6mr9722596wjc.93.1459350719400; Wed, 30 Mar 2016 08:11:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.121.7 with HTTP; Wed, 30 Mar 2016 08:11:39 -0700 (PDT) In-Reply-To: <569AD906E45DB44A8AFF11D61F5DA7910155C81DA5@AKLDRMBX03.dia.govt.nz> References: <56E1A5F8.3090201@switch.ch> <569AD906E45DB44A8AFF11D61F5DA7910155C7D4F2@AKLDRMBX03.dia.govt.nz> <56EA8845.3040503@switch.ch> <569AD906E45DB44A8AFF11D61F5DA7910155C80A34@AKLDRMBX03.dia.govt.nz> <569AD906E45DB44A8AFF11D61F5DA7910155C81DA5@AKLDRMBX03.dia.govt.nz> From: Julian White Date: Wed, 30 Mar 2016 16:11:39 +0100 Message-ID: To: Joanne Knight Content-Type: multipart/alternative; boundary=047d7ba97a1c3baaef052f4591ca Archived-At: Cc: Ken Dagg , Rolf Brugger , "vot@ietf.org" Subject: Re: [VoT] How to express duplicate checks with VoT? X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2016 15:12:06 -0000 --047d7ba97a1c3baaef052f4591ca Content-Type: text/plain; charset=UTF-8 Uniqueness of the entity is a whole world of hurt that may or may not be important, which is dependent on the RP service. On 20 March 2016 at 19:46, Joanne Knight wrote: > The first point of scoping I would suggest is to determine if you are > talking about uniqueness of the identity or uniqueness of the entity. > > > > *From:* Ken Dagg [mailto:kendaggtbs@gmail.com] > *Sent:* Saturday, 19 March 2016 6:39 a.m. > *To:* Julian White > *Cc:* Joanne Knight; Rolf Brugger; vot@ietf.org > > *Subject:* Re: [VoT] How to express duplicate checks with VoT? > > > > Here, here!!! > > > > I have been a lurker on this group for a while but felt compelled to add > my to cents to this discussion as it is, I believe, an important point to > scoping the discussion as it proceeds. > > > > I agree fully that determining the uniqueness of a subject is totally the > responsibility of the RP. It is their service delivery and they have to > determine what they require in order for them to be assured that they are > dealing with a unique subject. I use subject in order to include the IOT in > the possible solution. If I'm reading what you say correctly, one of the > considerations that a RP might use to determine uniqueness is the level of > proofing they require on 1) each of the attributes and 2) the set of > attributes. > > > > My experience with RPs aligns with Julian's. While RPs usually ask for > uniqueness from their digital supplier they do not do so in the manual > world. My tactic has been to ask why they are asking for it in the digital > world and not in the manual world. The discussion around this question > (usually around 1) their perceived benefit and 2) the additional cost > versus their perceived benefit) leads to them dropping that requirement > from their digital supplier. > > > > The "imposter" discussion usually takes the same path. Asking the RP how > they deal with imposters in the manual world usually leads to a conclusion > that they can employ the same tactics and processes only using digital > data. Cost effectiveness is usually a big part of the discussion. This > should not be likened to paving the cow path. What usually happens is that > they realize that, in the digital world, they might be able to detect an > imposter faster because they have faster access to the data they use to > detect imposters. In some cases, they may realize improved detection > because the proofing data is likely better than they have available in the > manual world. > > > > It is my opinion that, as their processes evolve in the digital world, > they will become faster at imposter detection and resolution. It is also my > opinion that prevention of imposters before they happen, like the totally > secure system, is, if not impossible, not a cost effective goal to achieve. > > > > Ken Dagg > > > > > > > On Friday, 18 March 2016, Julian White wrote: > > > > I would say, as I have in the ISO 29003 discussions, that uniqueness is in > fact irrelevant in terms of the level of proofing. I see no need to know > whether that set of attributes is proven to be unique by the proofing > provider. Uniqueness is highly dependent on the context, which raises all > sorts of problems if you have an identity federation (how do I know its > unique across the federation? If, as an RP, I can can cope with > non-uniqueness across the federation then non-uniqueness within the > proofing provider is also not a problem). > > > > In my view it is for the RP, or identity federation scheme, to decide > which attributes are required in their context. They select sufficient > attributes that give them uniqueness (in their context) if that is > required, e.g. SSN for some services (though I would advise against it!). > The purpose of the proofing process is to express to what level of > confidence that those attributes are true and belong to the person > presenting them, be they name, address, dob, email address, SSN etc. > > > > In my dealings with RPs they are confused about this and ask for > "uniqueness", this is usually followed up with "because we can't let people > register multiple identities". There is a lack of understanding that, > assuming the proofing process is working correctly, it doesn't matter how > many times you enrol you are proven to be the same person each time; i.e. > multiple enrolments lead to the identification of the same person being > bound to the same attributes. Therefore it isn't actually a problem in > terms of uniqueness. > > > > More often than not the ask for uniqueness is really an expression of how > well the system defends itself against impostors (different people > registering for the same attributes) which is actually the point of the > different levels of proofing (the higher the levels of proofing the harder > this should become). Demanding uniqueness doesn't actually fix the impostor > problem, you just introduce a time trial to the process; the first person > to get bound to those attributes locks out other people; if the first > person to claim them was the impostor you've now locked out the genuine > person - they now have a hell of time unpicking a mess not of their making. > If the system defends against impostors properly at the higher levels then > the uniqueness adds little value since I can only bind those attributes to > the correct person anyway. > > > > The thing that may need to be unique is the account/record at the RP, and > its the RP's responsibility to manage that. This is a problem they have > regardless of whether the proofing provider tells them its unique or not > because they often have multiple on-line and offline channels that deal > with their customers, this forces them to understand how to match different > representations of the identity to the same account which tends to work > across channel and within the same channel. > > > > So in summary it doesn't drive any real value in the proofing provider to > do this, its just a cost of effort for little gain that the RP is going to > repeat regardless if they care about uniqueness. > > > > Regards, > > > > Julian. > > > > > > > > > > On 17 March 2016 at 21:49, Joanne Knight > wrote: > > The short answer to your question - No. > > Your use case is silent on the level of vetting required (how real does > the identity have to be). You can have any level of identity and still > collect a biometric for the purposes of one and only one uniqueness. I > would pose however that it is very unusual for one and only one assurance > to be required without some other driver requiring an elevated level of > realness. > > In your use case I would suggest that there is also a requirement that a > qualification is issued to > a) the person carrying out the study and > b) an identity of such rigour that their (or the university's) eligibility > for public funding can be established and > c) an identity that is going to be tested by future employers. > > Therefore you are probably looking at P2 or P3 depending on the level/type > of qualification. (I might want P3 if the qualification is for brain > surgeon or commercial pilot). > > As one and only one is really only able to be achieved through the use of > a biometric, we now have to consider 'acceptability'. > Does the collection of a biometric (and all that it entails - cost, > privacy, security, user acceptance etc.) outweigh the impact caused by a > duplicate entity in the system? > In other words, do you really need one and only one (the 3rd level of > uniqueness) or could sufficient singularity be gained from leveraging the > social security number's uniqueness and an equivalent level of validation > and ownership test (the 2nd level of uniqueness) i.e. no Pu? > > We must remember the mutual exclusivity between attributes collected, > vetting under taken and level of uniqueness. > > Happy to discuss further if this makes no sense. > > Cheers > > > > -----Original Message----- > From: Rolf Brugger [mailto:rolf.brugger@switch.ch] > > Sent: Thursday, 17 March 2016 11:35 p.m. > To: vot@ietf.org > Subject: Re: [VoT] How to express duplicate checks with VoT? > > Hi all, > > Thanks for all your responses and ideas. We have discussed your inputs in > our project team (which is why it took me some time to respond) > > I was wondering what actually the differences are between the three levels > of uniqueness described by Joanne. In each of the three levels a set of > attributes is used to determine if an identity is unique within a > population of identities. The difference is 1) what exact set of attributes > is used in each level and 2) the vetting level of the attributes. Right? > > A concrete example might be > > First level: > - attributes: Name, email, phone number > - vetting level: P1 > > Second level: > - attributes: Name, email, phone number, social security number > - vetting level: P2 > > Third level: > - attributes: finger print or retina scan > - vetting level: P3 > > The appropriate set of attributes to be used in each level is certainly > context-specific. As Eric points out it will be difficult to define and > agree on a generic definition of the scope. > > Maybe it's time to describe our use cases here. In the IdM service we are > planning individuals self-register their identities. With such an identity, > individuals can register for studies at a university. But one individual > may only register once at the same university. Another case is a user's > library account that was blocked because of violations of the library's > usage terms. Such a user should not be able to just create a new account to > use the library services again. > > With Justin's suggestion of a Pu category, the requirements in our use > cases could be expressed as P1.Pu or P2.Pu. The semantics of "P2.Pu" > would then be: Proofed unique based on an attribute set with the vetting > level P2. > > cheers > > Rolf > > > > On 11.03.16 02:56, Joanne Knight wrote: > > Hi All > > > > There are three aspect or levels when looking at uniqueness to be > > considered. > > > > First level is that the identity is unique - that is, within a context > > there is a set of attributes that are unique for each identity > > registered. > > > > Second level is sole claimant - this is a check that only one entity > > has claimed a particular set of attributes. At the higher levels of > > identity proofing where authoritative sources are used it may be > > possible to achieve this. This is sufficient in most RPs cases. At > > this level while it is possible for a single entity to claim more than > > one identity, they do so at the risk of causing a counter-fraud flag > > should the real owner (or any other party) also attempt to claim the > > identity. > > > > The final level is one and only one - This is a check - usually > > biometric - that an entity has only one claim in the context. This is > > usually only reserved for the highest level of identity and would also > > require equally high levels of credential and credential issuance > > processes. > > > > As to how this relates to VoT - The first should be innately built > > into all levels of P - it is the sole requirement of all levels > > > > The second could be built into P3 if the wording was amended slightly. > > > > The last item only is substantively missing and to date (in the > > conversations I have been having elsewhere) there has been > > insufficient appetite to add it as an explicit requirement. > > > > Should we have a PU? Maybe, but steer clear of the term 'unique' If we > > do, in my mind it would only have two values - P?0 - Claims per entity > > not checked, P?1 - Claims per entity restricted to one. > > > > Joanne > > > > > > -----Original Message----- From: Rolf Brugger > > [mailto:rolf.brugger@switch.ch] Sent: Friday, 11 March 2016 5:51 a.m. > > To: vot@ietf.org Subject: [VoT] How to express duplicate checks with > > VoT? > > > > Hi all, > > > > I'm new to this list and I hope my question is not totally irrelevant > > here. > > > > We have plenty of use cases where RPs need to have confidence, that a > > person does not have multiple identities in one IdP. I don't see how > > this aspect of identity quality can be expressed, and I believe it is > > pretty orthogonal to the P, C, M and A dimensions that are currently > > specified in the VoT draft. > > > > We could imagine multiple ways to gradually prove that an identity has > > been checked against duplicates. The most straightforward approach > > would be to make sure that unique personal attributes are used only > > once within one IdP or an IdP federation, like - email > > address(es) - mobile phone number - home postal address - social > > security number - ID / passport number - the combination of name and > > birth date - etc. > > > > Would it make sense to express this in VoT? > > > > best regards > > > > Rolf > > > > > > -- SWITCH -------------------------- Rolf Brugger, project Swiss > > edu-ID Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland phone +41 44 > > 268 15 15, direct +41 44 268 15 89 rolf.brugger@switch.ch, > > http://www.switch.ch > > > > > > _______________________________________________ vot mailing list > > vot@ietf.org https://www.ietf.org/mailman/listinfo/vot > > > > -- > SWITCH > -------------------------- > Rolf Brugger, project Swiss edu-ID > Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland phone +41 44 268 15 15, > direct +41 44 268 15 89 rolf.brugger@switch.ch, http://www.switch.ch > > > _______________________________________________ > vot mailing list > vot@ietf.org > https://www.ietf.org/mailman/listinfo/vot > > > > > > -- > Kenneth Dagg > Independent Consultant > Identification and Authentication > 613-825-2091 > kendaggtbs@gmail.com > --047d7ba97a1c3baaef052f4591ca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Uniqueness of the entity is a whole world o= f hurt that may or may not be important, which is dependent on the RP servi= ce.

On 20 Ma= rch 2016 at 19:46, Joanne Knight <Joanne.Knight@dia.govt.nz>= ; wrote:

The first point of scopin= g I would suggest is to determine if you are talking about uniqueness of th= e identity or uniqueness of the entity.

=C2=A0

From: Ken Dagg [mailto:kendaggtbs@gmail.com]
Sent: Saturday, 19 March 2016 6:39 a.m.
To: Julian White
Cc: Joanne Knight; Rolf Brugger; vot@ietf.org


Subject: Re: [VoT] How to express duplicate checks with VoT?<= u>

=C2=A0

Here, here!!!

=C2=A0

I have been a lurker on this group for a while but f= elt compelled to add my to cents to this discussion as it is, I believe, an= important point to scoping the discussion as it proceeds.

=C2=A0

I agree fully that determining the uniqueness of a s= ubject is totally the responsibility of the RP. It is their service deliver= y and they have to determine what they require in order for them to be assu= red that they are dealing with a unique subject. I use subject in order to include the IOT in the possible solutio= n. If I'm reading what you say correctly, one of the considerations tha= t a RP might use to determine uniqueness is the level of proofing they requ= ire on 1) each of the attributes and 2) the set of attributes.

=C2=A0

My experience with RPs aligns with=C2=A0Julian's= .=C2=A0While RPs=C2=A0usually ask for uniqueness from their digital supplie= r they do not do so in the manual world. My tactic has been to ask why they= are asking for it in the digital world and not in the manual world. The discussion around this question (usually around 1) their= perceived benefit and=C2=A02) the additional cost versus their perceived b= enefit) leads to them dropping that requirement from their digital supplier= .

=C2=A0

The "imposter" discussion usually takes th= e same path. Asking the RP how they deal with imposters in the manual world= usually leads to a conclusion that they can employ the same tactics and pr= ocesses only using digital data. Cost effectiveness is usually a big part of the discussion. This should not be likened to pav= ing the cow path. What usually happens is that they realize that, in the di= gital world, they might be able to detect an imposter faster because they h= ave faster access to the data they use to detect imposters. In some cases, they may realize improved detectio= n because the proofing data is likely better than they have available in th= e manual world.=C2=A0

=C2=A0

It is my opinion that, as their processes evolve in = the digital world, they will become faster at imposter detection and resolu= tion. It is also my opinion that prevention of imposters before they happen= , like the totally secure system, is, if not impossible, not=C2=A0a cost effective goal to achieve.

=C2=A0

Ken Dagg

=C2=A0

=C2=A0


On Friday, 18 March 2016, Julian White <jwhite@nu-d.com> wrote:

=C2=A0

I would say, as I have in the ISO 29003 discussions,= that uniqueness is in fact irrelevant in terms of the level of proofing. I= see no need to know whether that set of attributes is proven to be unique = by the proofing provider. Uniqueness is highly dependent on the context, which raises all sorts of problems if = you have an identity federation (how do I know its unique across the federa= tion? If, as an RP, I can can cope with non-uniqueness across the federatio= n then=C2=A0non-uniqueness=C2=A0within the proofing provider is also not a problem).

=C2=A0

In my view it is for the RP, or identity federation = scheme, to decide which attributes are required in their context. They sele= ct sufficient attributes that give them uniqueness (in their context) if th= at is required, e.g. SSN for some services (though I would advise against it!). The purpose of the proofing = process is to express to what level of confidence that those attributes are= true and belong to the person presenting them, be they name, address, dob,= email address, SSN etc.

=C2=A0

In my dealings with RPs they are confused about this= and ask for "uniqueness", this is usually followed up with "= ;because we can't let people register multiple identities". There = is a lack of understanding that, assuming the proofing process is working correctly, it doesn't matter how many times you enrol you a= re proven to be the same person each time; i.e. multiple enrolments lead to= the identification of the same person being bound to the same attributes. = Therefore it isn't actually a problem in terms of uniqueness.=C2=A0

=C2=A0

More often than not the ask for uniqueness is really= an expression of how well the system defends itself against impostors (dif= ferent people registering for the same attributes) which is actually the po= int of the different levels of proofing (the higher the levels of proofing the harder this should become). Demandi= ng uniqueness doesn't actually fix the impostor problem, you just intro= duce a time trial to the process; the first person to get bound to those at= tributes locks out other people; if the first person to claim them was the impostor you've now locked out = the genuine person - they now have a hell of time unpicking a mess not of t= heir making. If the system defends against impostors properly at the higher= levels then the uniqueness adds little value since I can only bind those attributes to the correct person anyway.=

=C2=A0

The thing that may need to be unique is the account/= record at the RP, and its the RP's responsibility to manage that. This = is a problem they have regardless of whether the proofing provider tells th= em its unique or not because they often have multiple on-line and offline channels that deal with their customers,= this forces them to understand how to match different representations of t= he identity to the same account which tends to work across channel and with= in the same channel.

=C2=A0

So in summary it doesn't drive any real value in= the proofing provider to do this, its just a cost of effort for little gai= n that the RP is going to repeat regardless if they care about uniqueness.<= u>

=C2=A0

Regards,

=C2=A0

Julian.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On 17 March 2016 at 21:49, Joanne Knight <Joan= ne.Knight@dia.govt.nz> wrote:

The short answer to your question - No.

Your use case is silent on the level of vetting required (how real does the= identity have to be). You can have any level of identity and still collect= a biometric for the purposes of one and only one uniqueness. I would pose = however that it is very unusual for one and only one assurance to be required without some other driver re= quiring an elevated level of realness.

In your use case I would suggest that there is also a requirement that a qu= alification is issued to
a) the person carrying out the study and
b) an identity of such rigour that their (or the university's) eligibil= ity for public funding can be established and
c) an identity that is going to be tested by future employers.

Therefore you are probably looking at P2 or P3 depending on the level/type = of qualification. (I might want P3 if the qualification is for brain surgeo= n or commercial pilot).

As one and only one is really only able to be achieved through the use of a= biometric, we now have to consider 'acceptability'.
Does the collection of a biometric (and all that it entails - cost, privacy= , security, user acceptance etc.) outweigh the impact caused by a duplicate= entity in the system?
In other words, do you really need one and only one (the 3rd level of uniqu= eness) or could sufficient singularity be gained from leveraging the social= security number's uniqueness and an equivalent level of validation and= ownership test (the 2nd level of uniqueness) i.e. no Pu?

We must remember the mutual exclusivity between attributes collected, vetti= ng under taken and level of uniqueness.

Happy to discuss further if this makes no sense.

Cheers



-----Original Message-----
From: Rolf Brugger [mailto:rolf.brugger@switch.ch]

Sent: Thursday, 17 March 2016 11:35 p.m.
To: vot@ietf.org
Subject: Re: [VoT] How to express duplicate checks with VoT?

Hi all,

Thanks for all your responses and ideas. We have discussed your inputs in o= ur project team (which is why it took me some time to respond)

I was wondering what actually the differences are between the three levels = of uniqueness described by Joanne. In each of the three levels a set of att= ributes is used to determine if an identity is unique within a population o= f identities. The difference is 1) what exact set of attributes is used in each level and 2) the vetting l= evel of the attributes. Right?

A concrete example might be

First level:
- attributes: Name, email, phone number
- vetting level: P1

Second level:
- attributes: Name, email, phone number, social security number
- vetting level: P2

Third level:
- attributes: finger print or retina scan
- vetting level: P3

The appropriate set of attributes to be used in each level is certainly con= text-specific. As Eric points out it will be difficult to define and agree = on a generic definition of the scope.

Maybe it's time to describe our use cases here. In the IdM service we a= re planning individuals self-register their identities. With such an identi= ty, individuals can register for studies at a university. But one individua= l may only register once at the same university. Another case is a user's library account that was blocked = because of violations of the library's usage terms. Such a user should = not be able to just create a new account to use the library services again.=

With Justin's suggestion of a Pu category, the requirements in our use = cases could be expressed as P1.Pu or P2.Pu. The semantics of "P2.Pu&qu= ot;
would then be: Proofed unique based on an attribute set with the vetting le= vel P2.

cheers

Rolf



On 11.03.16 02:56, Joanne Knight wrote:
> Hi All
>
> There are three aspect or levels when looking at uniqueness to be
> considered.
>
> First level is that the identity is unique - that is, within a context=
> there is a set of attributes that are unique for each identity
> registered.
>
> Second level is sole claimant - this is a check that only one entity > has claimed a particular set of attributes. At the higher levels of > identity proofing where authoritative sources are used it may be
> possible to achieve this. This is sufficient in most RPs cases. At
> this level while it is possible for a single entity to claim more than=
> one identity, they do so at the risk of causing a counter-fraud flag > should the real owner (or any other party) also attempt to claim the > identity.
>
> The final level is one and only one - This is a check - usually
> biometric - that an entity has only one claim in the context. This is<= br> > usually only reserved for the highest level of identity and would also=
> require equally high levels of credential and credential issuance
> processes.
>
> As to how this relates to VoT - The first should be innately built
> into all levels of P - it is the sole requirement of all levels
>
> The second could be built into P3 if the wording was amended slightly.=
>
> The last item only is substantively missing and to date (in the
> conversations I have been having elsewhere) there has been
> insufficient appetite to add it as an explicit requirement.
>
> Should we have a PU? Maybe, but steer clear of the term 'unique= 9; If we
> do, in my mind it would only have two values - P?0 - Claims per entity=
> not checked, P?1 - Claims per entity restricted to one.
>
> Joanne
>
>
> -----Original Message----- From: Rolf Brugger
> [mailto:rolf.brugger@switch.ch] Sent: Friday, 11 March 2016 5:5= 1 a.m.
> To: vot@ietf.org Subject: [VoT] How to express duplicate checks= with
> VoT?
>
> Hi all,
>
> I'm new to this list and I hope my question is not totally irrelev= ant
> here.
>
> We have plenty of use cases where RPs need to have confidence, that a<= br> > person does not have multiple identities in one IdP. I don't see h= ow
> this aspect of identity quality can be expressed, and I believe it is<= br> > pretty orthogonal to the P, C, M and A dimensions that are currently > specified in the VoT draft.
>
> We could imagine multiple ways to gradually prove that an identity has=
> been checked against duplicates. The most straightforward approach
> would be to make sure that unique personal attributes are used only > once within one IdP or an IdP federation, like - email
> address(es) - mobile phone number - home postal address - social
> security number - ID / passport number - the combination of name and > birth date - etc.
>
> Would it make sense to express this in VoT?
>
> best regards
>
> Rolf
>
>
> -- SWITCH -------------------------- Rolf Brugger, project Swiss
> edu-ID Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland phone +41 44<= br> > 268 15 15, direct +41 44 268 15 89 rolf.brugger@switch.ch,
> http://www.switch.c= h
>
>
> _______________________________________________ vot mailing list
> vot@ietf.org htt= ps://www.ietf.org/mailman/listinfo/vot
>

--
SWITCH
--------------------------
Rolf Brugger, project Swiss edu-ID
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland phone +41 44 268 15 15, direct +41 44 268 15 89 rolf.brugger@switch.ch, http://www.switch.ch


_______________________________________________
vot mailing list
vot@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/vot

=C2=A0



--
Kenneth Dagg
Independent Consultant
Identification and Authentication
613-8= 25-2091
kendaggtbs@gmail.= com


--047d7ba97a1c3baaef052f4591ca--