From nobody Wed Sep 13 10:01:30 2017 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 836651323B8 for ; Wed, 13 Sep 2017 10:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLiXniOFFdBm for ; Wed, 13 Sep 2017 10:01:16 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B455713292D for ; Wed, 13 Sep 2017 10:01:16 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v8DH1G9u015304 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 13 Sep 2017 17:01:16 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v8DH1GH4019086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 13 Sep 2017 17:01:16 GMT Received: from ubhmp0019.oracle.com (ubhmp0019.oracle.com [156.151.24.72]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v8DH1G2M017932 for ; Wed, 13 Sep 2017 17:01:16 GMT Received: from [10.0.1.37] (/24.86.190.97) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 13 Sep 2017 17:01:15 +0000 From: Phil Hunt Content-Type: multipart/alternative; boundary="Apple-Mail=_601DE6A5-5CD9-4DA8-88BE-5C0A9186C6BB" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 13 Sep 2017 10:01:14 -0700 Message-Id: To: vot@ietf.org X-Mailer: Apple Mail (2.3273) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Subject: [VoT] VoT Identity Proofing and individual claims X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 17:01:23 -0000 --Apple-Mail=_601DE6A5-5CD9-4DA8-88BE-5C0A9186C6BB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Section 3.1 Does 3.1 apply to the identifier issued, to the whole assertion?=20 An Identity is usually an identifier and a set of claims. So what about claims? Some claims may be issued by a provider (and = thus are P3) while others may be provided as self asserted by the = subject. Some, as in banking may have involved a physical documents or = other mechanism and thus all claims are not equal. I have trouble determining the affect of P0-P3 and worry that privilege = escalation will occur since not all claims are equal. There isn=E2=80=99t= really a way to say =E2=80=9CWe=E2=80=99re confident this is Justin, = we=E2=80=99re just not so sure about his medical degree=E2=80=9D. Consider a university knows student numbers and degrees and courses = completed. Is it authoritative over nationality, residence, addresses? = Maybe. Maybe not. Consider a social network. In many cases they can be considered = authoritative over the social network identity (P3) but know nothing = about most users. I=E2=80=99m just not sure identity proofing as expressed is actually = useful. Phil Oracle Corporation, Identity Cloud Services Architect @independentid www.independentid.com = phil.hunt@oracle.com = --Apple-Mail=_601DE6A5-5CD9-4DA8-88BE-5C0A9186C6BB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Section 3.1

Does 3.1 apply to the identifier = issued, to the whole assertion? 

An Identity is usually an identifier = and a set of claims.

So what about claims?   Some claims may be issued by a = provider (and thus are P3) while others may be provided as self asserted = by the subject.  Some, as in banking may have involved a physical = documents or other mechanism and thus all claims are not = equal.

I have = trouble determining the affect of P0-P3 and worry that privilege = escalation will occur since not all claims are equal.  There = isn=E2=80=99t really a way to say =E2=80=9CWe=E2=80=99re confident this = is Justin, we=E2=80=99re just not so sure about his medical = degree=E2=80=9D.

Consider a university knows student numbers and degrees and = courses completed. Is it authoritative over nationality, residence, = addresses?  Maybe. Maybe not.

Consider a social network. In many = cases they can be considered authoritative over the social network = identity (P3) but know nothing about most users.

I=E2=80=99m just not sure identity = proofing as expressed is actually useful.

Phil

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

= --Apple-Mail=_601DE6A5-5CD9-4DA8-88BE-5C0A9186C6BB-- From nobody Wed Sep 13 10:57:57 2017 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 958A0132EC4 for ; Wed, 13 Sep 2017 10:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sImuI1RFyW9n for ; Wed, 13 Sep 2017 10:57:53 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86A96133035 for ; Wed, 13 Sep 2017 10:57:53 -0700 (PDT) X-AuditID: 1209190e-b33ff700000005aa-87-59b9719f3a66 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 70.BD.01450.F9179B95; Wed, 13 Sep 2017 13:57:52 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id v8DHvoN4023280; Wed, 13 Sep 2017 13:57:51 -0400 Received: from [192.168.1.7] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v8DHvmEJ013392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 Sep 2017 13:57:50 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_7431D66D-CA6B-4AD1-8415-D2AF9C514EE2" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 13 Sep 2017 13:57:48 -0400 In-Reply-To: Cc: vot@ietf.org To: Phil Hunt References: X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJKsWRmVeSWpSXmKPExsUixCmqrLugcGekQc9rJosF8xvZLRp+PmB1 YPJYsuQnk8fHp7dYApiiuGxSUnMyy1KL9O0SuDLW7JzEWnCrsmJl70zGBsYVGV2MnBwSAiYS f88tYuxi5OIQEljMJNF/ZiM7SEJIYCOjxP5XWRD2NSaJu81FIDabgKrE9DUtTCA2r4CVRHPL YWYQm1kgSaJ7zSvWLkYOoLi+RO9zRpCwsICdxME5f8BsFqDWX7cXg5VzAsXPPD7PAtEqIDH3 0DSwkSICKhLfrl5nhFhrK/Hl7XMmiDtlJW7NvsQ8gZF/FpJtsxC2QYS1JZYtfM0MYWtK7O9e zoIpriHR+W0i6wJGtlWMsim5Vbq5iZk5xanJusXJiXl5qUW6xnq5mSV6qSmlmxjBIS3Jt4Nx UoP3IUYBDkYlHt4HljsjhVgTy4orcw8xSnIwKYny7tUFCvEl5adUZiQWZ8QXleakFh9ilOBg VhLhTcwAyvGmJFZWpRblw6SkOViUxHnFNRojhATSE0tSs1NTC1KLYLIyHBxKEryzC4AaBYtS 01Mr0jJzShDSTBycIMN5gIZbgtTwFhck5hZnpkPkTzFacnTcvPuHiWMDmNwHIoVY8vLzUqXE eQ/mAzUIgDRklObBzQSlKPd1dhavGMWBXhTmXQcylgeY3uCmvgJayAS08MzpHSALSxIRUlIN jDekJ83Tbbx3IrGMNfbv+pfGepzVFV2vRT3ee6bNT99ar3dNdO2NsIszVA/P/n6ZaY7MahnO O3ISL14d6J01/5lJ2mtBoQiNggu/FQXWNHSs4uEVWqc4t7h4rdfOKeq8k2dfUpq+YEvNkYYt e2/wKH+5PJmzcLuQ2q15Vy7z29o960o7au9/IVCJpTgj0VCLuag4EQA51qIuLAMAAA== Archived-At: Subject: Re: [VoT] VoT Identity Proofing and individual claims X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 17:57:56 -0000 --Apple-Mail=_7431D66D-CA6B-4AD1-8415-D2AF9C514EE2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 It applies to the IdP=E2=80=99s judgement across the entire assertion. = How that=E2=80=99s calculated when the trust in different attributes = differs will vary depending on the IdP, and probably defined by rules = within the trust framework that defines the vector values themselves. = NIST 800-63-3 volume A, for example, is very clear about how to handle = all the attributes collected at different levels. If you were using = NIST=E2=80=99s encoding of VoT, specified in the upcoming volume D of = that document, then you=E2=80=99d be bound by those rules as an IdP. A = university group, like you=E2=80=99re talking about below, might have = different rules under its own trust framework and vector component = definitions. It looks like you might be asking if this is about per-attribute = metadata. If you read the introduction, we explicitly state that we=E2=80=99= re not trying to solve per-attribute metadata. If you=E2=80=99d like = that kind of data, you=E2=80=99re looking for a different kind of = solution, of which there have been numerous attempts over the years. = Generally speaking, attribute metadata systems look great on paper but = are incredibly complicated for RP=E2=80=99s to implement. When we wrote = VoT, we directly decided to take a different approach, something between = the granularity of attributes and the single-scale of LOA.=20 This level of granularity is very, very useful in the real world, = otherwise we wouldn=E2=80=99t have dozens of international trust = frameworks based around the concept of proofing an individual and tying = that account to a set of proofed attributes. There isn=E2=80=99t an easy = way to express something complex as =E2=80=9CWe=E2=80=99re sure this is = Justin but aren=E2=80=99t sure about his medical degree=E2=80=9D in any = VoT implementation that I=E2=80=99ve seen to date, and especially not in = the example values given in the spec itself. But if you really wanted = to, you could have something like: - P3: High level of confidence in individual=E2=80=99s name, address, = phone, eye color, and shoe size - Pm: In person verification of a medical degree by making the claimant = perform surgery on the verifier. So if you wanted to express that, you could say =E2=80=9CP3.Pm=E2=80=9D = or just =E2=80=9CP3=E2=80=9D if you weren=E2=80=99t so sure about that = medical degree. However, like I described above, I don=E2=80=99t think = this is a good solution for that as you=E2=80=99d need to get really = specific with each attribute. If you really need that level of = expressiveness, you=E2=80=99ll want a different solution and VoT = doesn=E2=80=99t work for you. However, just because it doesn=E2=80=99t = solve this use case doesn=E2=80=99t mean it=E2=80=99s not useful in many = others. VoT is a tool fit for a purpose that we tried to express in the = intro text, it fits in between attribute metadata and single scalar = measurements. And in fact, you could use it side by side in the same = system, and I see no conflict in this. Don=E2=80=99t deny the world a hammer just because you think you need a = screwdriver. =E2=80=94 Justin > On Sep 13, 2017, at 1:01 PM, Phil Hunt wrote: >=20 > Section 3.1 >=20 > Does 3.1 apply to the identifier issued, to the whole assertion?=20 >=20 > An Identity is usually an identifier and a set of claims. >=20 > So what about claims? Some claims may be issued by a provider (and = thus are P3) while others may be provided as self asserted by the = subject. Some, as in banking may have involved a physical documents or = other mechanism and thus all claims are not equal. >=20 > I have trouble determining the affect of P0-P3 and worry that = privilege escalation will occur since not all claims are equal. There = isn=E2=80=99t really a way to say =E2=80=9CWe=E2=80=99re confident this = is Justin, we=E2=80=99re just not so sure about his medical degree=E2=80=9D= . >=20 > Consider a university knows student numbers and degrees and courses = completed. Is it authoritative over nationality, residence, addresses? = Maybe. Maybe not. >=20 > Consider a social network. In many cases they can be considered = authoritative over the social network identity (P3) but know nothing = about most users. >=20 > I=E2=80=99m just not sure identity proofing as expressed is actually = useful. >=20 > Phil >=20 > Oracle Corporation, Identity Cloud Services Architect > @independentid > www.independentid.com = phil.hunt@oracle.com = > _______________________________________________ > vot mailing list > vot@ietf.org > https://www.ietf.org/mailman/listinfo/vot --Apple-Mail=_7431D66D-CA6B-4AD1-8415-D2AF9C514EE2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 It applies to the IdP=E2=80=99s judgement across the entire = assertion. How that=E2=80=99s calculated when the trust in different = attributes differs will vary depending on the IdP, and probably defined = by rules within the trust framework that defines the vector values = themselves. NIST 800-63-3 volume A, for example, is very clear about how = to handle all the attributes collected at different levels. If you were = using NIST=E2=80=99s encoding of VoT, specified in the upcoming volume D = of that document, then you=E2=80=99d be bound by those rules as an IdP. = A university group, like you=E2=80=99re talking about below, might have = different rules under its own trust framework and vector component = definitions.

It = looks like you might be asking if this is about per-attribute metadata. = If you read the introduction, we explicitly state that we=E2=80=99re not = trying to solve per-attribute metadata. If you=E2=80=99d like that kind = of data, you=E2=80=99re looking for a different kind of solution, of = which there have been numerous attempts over the years. Generally = speaking, attribute metadata systems look great on paper but are = incredibly complicated for RP=E2=80=99s to implement. When we wrote VoT, = we directly decided to take a different approach, something between the = granularity of attributes and the single-scale of LOA. 

This level of = granularity is very, very useful in the real world, otherwise we = wouldn=E2=80=99t have dozens of international trust frameworks based = around the concept of proofing an individual and tying that account to a = set of proofed attributes. There isn=E2=80=99t an easy way to express = something complex as =E2=80=9CWe=E2=80=99re sure this is Justin but = aren=E2=80=99t sure about his medical degree=E2=80=9D in any VoT = implementation that I=E2=80=99ve seen to date, and especially not in the = example values given in the spec itself. But if you really wanted to, = you could have something like:

 - P3: High level of confidence in = individual=E2=80=99s name, address, phone, eye color, and shoe = size
 - Pm: In person verification of a = medical degree by making the claimant perform surgery on the = verifier.

So = if you wanted to express that, you could say =E2=80=9CP3.Pm=E2=80=9D or = just =E2=80=9CP3=E2=80=9D if you weren=E2=80=99t so sure about that = medical degree. However, like I described above, I don=E2=80=99t think = this is a good solution for that as you=E2=80=99d need to get really = specific with each attribute. If you really need that level of = expressiveness, you=E2=80=99ll want a different solution and VoT = doesn=E2=80=99t work for you. However, just because it doesn=E2=80=99t = solve this use case doesn=E2=80=99t mean it=E2=80=99s not useful in many = others. VoT is a tool fit for a purpose that we tried to express in the = intro text, it fits in between attribute metadata and single scalar = measurements. And in fact, you could use it side by side in the same = system, and I see no conflict in this.

Don=E2=80=99t deny the world a hammer = just because you think you need a screwdriver.

 =E2=80=94 Justin

On Sep 13, 2017, at 1:01 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Section 3.1

Does 3.1 apply to the identifier issued, to the whole = assertion? 

An Identity is usually an identifier and a set of = claims.

So = what about claims?   Some claims may be issued by a provider (and = thus are P3) while others may be provided as self asserted by the = subject.  Some, as in banking may have involved a physical = documents or other mechanism and thus all claims are not = equal.

I have = trouble determining the affect of P0-P3 and worry that privilege = escalation will occur since not all claims are equal.  There = isn=E2=80=99t really a way to say =E2=80=9CWe=E2=80=99re confident this = is Justin, we=E2=80=99re just not so sure about his medical = degree=E2=80=9D.

Consider a university knows student numbers and degrees and = courses completed. Is it authoritative over nationality, residence, = addresses?  Maybe. Maybe not.

Consider a social network. In many = cases they can be considered authoritative over the social network = identity (P3) but know nothing about most users.

I=E2=80=99m just not sure identity = proofing as expressed is actually useful.

Phil

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

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

= --Apple-Mail=_7431D66D-CA6B-4AD1-8415-D2AF9C514EE2-- From nobody Wed Sep 13 12:10:08 2017 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 B8FA7132EDC for ; Wed, 13 Sep 2017 12:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZfJD3R3BvXEb for ; Wed, 13 Sep 2017 12:10:05 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD327132EBB for ; Wed, 13 Sep 2017 12:10:04 -0700 (PDT) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v8DJA3mn005691 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 13 Sep 2017 19:10:04 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v8DJA3jM005479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 13 Sep 2017 19:10:03 GMT Received: from ubhmp0016.oracle.com (ubhmp0016.oracle.com [156.151.24.69]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v8DJA25b013287; Wed, 13 Sep 2017 19:10:03 GMT Received: from [10.0.1.37] (/24.86.190.97) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 13 Sep 2017 19:10:02 +0000 From: Phil Hunt Message-Id: <52A72F41-557D-4B73-BF06-FAB8362DB31F@oracle.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_71E93C0C-A728-460C-8E90-4EEEF80FD69F" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 13 Sep 2017 12:09:59 -0700 In-Reply-To: Cc: vot@ietf.org To: Justin Richer References: X-Mailer: Apple Mail (2.3273) X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Subject: Re: [VoT] VoT Identity Proofing and individual claims X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 19:10:08 -0000 --Apple-Mail=_71E93C0C-A728-460C-8E90-4EEEF80FD69F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Justin, I don=E2=80=99t believe making things arbitrarily out of scope helps = simplify. In this case, I believe it complicates matters. Firstly, missing from the spec=E2=80=A6.a definition of Identity. > 2.1 = = . Identity Proofing >=20 > The Identity Proofing dimension defines, overall, how strongly the > set of identity attributes have been verified and vetted. In other > words, this dimension describes how likely it is that a given = digital > identity transaction corresponds to a particular (real-world) > identity subject. >=20 > This dimension SHALL be represented by the "P" demarcator and a > single-character level value, such as "P0", "P1", etc. Most > definitions of identity proofing will have a natural ordering, as > more or less stringent proofing can be applied to an individual. = In > such cases it is RECOMMENDED that a digit style value be used for > this component. What is meant by overall? Is it an average? The lowest value of all of = the attributes (claims)? What is meant by a real world identity subject? Do you mean a legal = person? Do you mean a device/thing? An overall level of confidence in how strongly a transaction corresponds = to a particular identity subject sounds an awful lot like authentication = confidence. I can see how you might arrive at this definition looking an an internal = data system like a payroll system. You can assess the procedures and = establish an overall confidence level in the quality of data. But as = soon as you want to share that payroll data with other systems. =20 I began my experience in Identity management building large scale = meta-directories. We once assumed business systems like payroll systems = were authoritative over things like employee addresses. Turns out we = were wrong. Payroll doesn=E2=80=99t care about addresses, they care = about bank account deposit numbers. =20 Conclusion: Just because the payroll department has a high level of = confidence in the attributes they have *internally*, it does not mean = there is high confidence for secondary uses. If you ask payroll about = sharing data, they might only share employee number, salary, and bank = accounts as being accurate (assuming there was a valid reason to share). = Should an IDP based on payroll only assert high level data? Can they = assert low-level data for the purpose of correlation/confirmation? Another case, look at Facebook and Twitter. They have variable = assertions as well. Some users are verified and some are not. What = does that mean? How would VoT help in this case? Would it mean that the = out of scope information in the name claim is deemed accurate? Are we = talking about the same Michael Douglas or are we talking about Michael = Keaton (Michael Keaton=E2=80=99s real name is Michael Douglas). Phil Oracle Corporation, Identity Cloud Services Architect @independentid www.independentid.com = phil.hunt@oracle.com = > On Sep 13, 2017, at 10:57 AM, Justin Richer wrote: >=20 > It applies to the IdP=E2=80=99s judgement across the entire assertion. = How that=E2=80=99s calculated when the trust in different attributes = differs will vary depending on the IdP, and probably defined by rules = within the trust framework that defines the vector values themselves. = NIST 800-63-3 volume A, for example, is very clear about how to handle = all the attributes collected at different levels. If you were using = NIST=E2=80=99s encoding of VoT, specified in the upcoming volume D of = that document, then you=E2=80=99d be bound by those rules as an IdP. A = university group, like you=E2=80=99re talking about below, might have = different rules under its own trust framework and vector component = definitions. >=20 > It looks like you might be asking if this is about per-attribute = metadata. If you read the introduction, we explicitly state that we=E2=80=99= re not trying to solve per-attribute metadata. If you=E2=80=99d like = that kind of data, you=E2=80=99re looking for a different kind of = solution, of which there have been numerous attempts over the years. = Generally speaking, attribute metadata systems look great on paper but = are incredibly complicated for RP=E2=80=99s to implement. When we wrote = VoT, we directly decided to take a different approach, something between = the granularity of attributes and the single-scale of LOA.=20 >=20 > This level of granularity is very, very useful in the real world, = otherwise we wouldn=E2=80=99t have dozens of international trust = frameworks based around the concept of proofing an individual and tying = that account to a set of proofed attributes. There isn=E2=80=99t an easy = way to express something complex as =E2=80=9CWe=E2=80=99re sure this is = Justin but aren=E2=80=99t sure about his medical degree=E2=80=9D in any = VoT implementation that I=E2=80=99ve seen to date, and especially not in = the example values given in the spec itself. But if you really wanted = to, you could have something like: >=20 > - P3: High level of confidence in individual=E2=80=99s name, address, = phone, eye color, and shoe size > - Pm: In person verification of a medical degree by making the = claimant perform surgery on the verifier. >=20 > So if you wanted to express that, you could say =E2=80=9CP3.Pm=E2=80=9D = or just =E2=80=9CP3=E2=80=9D if you weren=E2=80=99t so sure about that = medical degree. However, like I described above, I don=E2=80=99t think = this is a good solution for that as you=E2=80=99d need to get really = specific with each attribute. If you really need that level of = expressiveness, you=E2=80=99ll want a different solution and VoT = doesn=E2=80=99t work for you. However, just because it doesn=E2=80=99t = solve this use case doesn=E2=80=99t mean it=E2=80=99s not useful in many = others. VoT is a tool fit for a purpose that we tried to express in the = intro text, it fits in between attribute metadata and single scalar = measurements. And in fact, you could use it side by side in the same = system, and I see no conflict in this. >=20 > Don=E2=80=99t deny the world a hammer just because you think you need = a screwdriver. >=20 > =E2=80=94 Justin >=20 >> On Sep 13, 2017, at 1:01 PM, Phil Hunt > wrote: >>=20 >> Section 3.1 >>=20 >> Does 3.1 apply to the identifier issued, to the whole assertion?=20 >>=20 >> An Identity is usually an identifier and a set of claims. >>=20 >> So what about claims? Some claims may be issued by a provider (and = thus are P3) while others may be provided as self asserted by the = subject. Some, as in banking may have involved a physical documents or = other mechanism and thus all claims are not equal. >>=20 >> I have trouble determining the affect of P0-P3 and worry that = privilege escalation will occur since not all claims are equal. There = isn=E2=80=99t really a way to say =E2=80=9CWe=E2=80=99re confident this = is Justin, we=E2=80=99re just not so sure about his medical degree=E2=80=9D= . >>=20 >> Consider a university knows student numbers and degrees and courses = completed. Is it authoritative over nationality, residence, addresses? = Maybe. Maybe not. >>=20 >> Consider a social network. In many cases they can be considered = authoritative over the social network identity (P3) but know nothing = about most users. >>=20 >> I=E2=80=99m just not sure identity proofing as expressed is actually = useful. >>=20 >> Phil >>=20 >> Oracle Corporation, Identity Cloud Services Architect >> @independentid >> www.independentid.com = phil.hunt@= oracle.com >> _______________________________________________ >> vot mailing list >> vot@ietf.org >> https://www.ietf.org/mailman/listinfo/vot >=20 --Apple-Mail=_71E93C0C-A728-460C-8E90-4EEEF80FD69F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Justin,

I don=E2=80=99t believe making things = arbitrarily out of scope helps simplify.  In this case, I believe = it complicates matters.

Firstly, missing from the spec=E2=80=A6.a definition of = Identity.

2.1.  =
Identity Proofing


   The Identity Proofing dimension defines, overall, how strongly the
   set of identity attributes have been verified and vetted.  In other
   words, this dimension describes how likely it is that a given digital
   identity transaction corresponds to a particular (real-world)
   identity subject.

   This dimension SHALL be represented by the "P" demarcator and a
   single-character level value, such as "P0", "P1", etc.  Most
   definitions of identity proofing will have a natural ordering, as
   more or less stringent proofing can be applied to an individual.  In
   such cases it is RECOMMENDED that a digit style value be used for
   this component.

What is meant by overall? =  Is it an average?  The lowest value of all of the attributes = (claims)?

What = is meant by a real world identity subject?  Do you mean a legal = person?  Do you mean a device/thing?

An overall level of confidence in how = strongly a transaction corresponds to a particular identity subject = sounds an awful lot like authentication confidence.

I can see how you might = arrive at this definition looking an an internal data system like a = payroll system. You can assess the procedures and establish an overall = confidence level in the quality of data.  But as soon as you want = to share that payroll data with other systems.  

I began my experience in = Identity management building large scale meta-directories. We once = assumed business systems like payroll systems were authoritative over = things like employee addresses.  Turns out we were wrong. =  Payroll doesn=E2=80=99t care about addresses, they care about bank = account deposit numbers.  

Conclusion:  Just because the = payroll department has a high level of confidence in the attributes they = have *internally*, it does not mean there is high confidence for = secondary uses.  If you ask payroll about sharing data, they might = only share employee number, salary, and bank accounts as being accurate = (assuming there was a valid reason to share).  Should an IDP based = on payroll only assert high level data?  Can they assert low-level = data for the purpose of correlation/confirmation?
Another case, look at Facebook and = Twitter. They have variable assertions as well.  Some users are = verified and some are not.  What does that mean? How would VoT help = in this case?  Would it mean that the out of scope information in = the name claim is deemed accurate?  Are we talking about the same = Michael Douglas or are we talking about Michael Keaton (Michael = Keaton=E2=80=99s real name is Michael Douglas).

Phil

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

On Sep 13, 2017, at 10:57 AM, Justin Richer <jricher@mit.edu> = wrote:

It applies to the = IdP=E2=80=99s judgement across the entire assertion. How that=E2=80=99s = calculated when the trust in different attributes differs will vary = depending on the IdP, and probably defined by rules within the trust = framework that defines the vector values themselves. NIST 800-63-3 = volume A, for example, is very clear about how to handle all the = attributes collected at different levels. If you were using NIST=E2=80=99s= encoding of VoT, specified in the upcoming volume D of that document, = then you=E2=80=99d be bound by those rules as an IdP. A university = group, like you=E2=80=99re talking about below, might have different = rules under its own trust framework and vector component = definitions.

It = looks like you might be asking if this is about per-attribute metadata. = If you read the introduction, we explicitly state that we=E2=80=99re not = trying to solve per-attribute metadata. If you=E2=80=99d like that kind = of data, you=E2=80=99re looking for a different kind of solution, of = which there have been numerous attempts over the years. Generally = speaking, attribute metadata systems look great on paper but are = incredibly complicated for RP=E2=80=99s to implement. When we wrote VoT, = we directly decided to take a different approach, something between the = granularity of attributes and the single-scale of LOA. 

This level of = granularity is very, very useful in the real world, otherwise we = wouldn=E2=80=99t have dozens of international trust frameworks based = around the concept of proofing an individual and tying that account to a = set of proofed attributes. There isn=E2=80=99t an easy way to express = something complex as =E2=80=9CWe=E2=80=99re sure this is Justin but = aren=E2=80=99t sure about his medical degree=E2=80=9D in any VoT = implementation that I=E2=80=99ve seen to date, and especially not in the = example values given in the spec itself. But if you really wanted to, = you could have something like:

 - P3: High level of confidence in = individual=E2=80=99s name, address, phone, eye color, and shoe = size
 - Pm: In person verification of a = medical degree by making the claimant perform surgery on the = verifier.

So = if you wanted to express that, you could say =E2=80=9CP3.Pm=E2=80=9D or = just =E2=80=9CP3=E2=80=9D if you weren=E2=80=99t so sure about that = medical degree. However, like I described above, I don=E2=80=99t think = this is a good solution for that as you=E2=80=99d need to get really = specific with each attribute. If you really need that level of = expressiveness, you=E2=80=99ll want a different solution and VoT = doesn=E2=80=99t work for you. However, just because it doesn=E2=80=99t = solve this use case doesn=E2=80=99t mean it=E2=80=99s not useful in many = others. VoT is a tool fit for a purpose that we tried to express in the = intro text, it fits in between attribute metadata and single scalar = measurements. And in fact, you could use it side by side in the same = system, and I see no conflict in this.

Don=E2=80=99t deny the world a hammer = just because you think you need a screwdriver.

 =E2=80=94 Justin

On Sep 13, 2017, at 1:01 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Section= 3.1

Does 3.1 = apply to the identifier issued, to the whole assertion? 

An Identity is usually = an identifier and a set of claims.

So what about claims?   Some = claims may be issued by a provider (and thus are P3) while others may be = provided as self asserted by the subject.  Some, as in banking may = have involved a physical documents or other mechanism and thus all = claims are not equal.

I have trouble determining the affect of P0-P3 and worry that = privilege escalation will occur since not all claims are equal. =  There isn=E2=80=99t really a way to say =E2=80=9CWe=E2=80=99re = confident this is Justin, we=E2=80=99re just not so sure about his = medical degree=E2=80=9D.

Consider a university knows student numbers and degrees and = courses completed. Is it authoritative over nationality, residence, = addresses?  Maybe. Maybe not.

Consider a social network. In many = cases they can be considered authoritative over the social network = identity (P3) but know nothing about most users.

I=E2=80=99m just not sure identity = proofing as expressed is actually useful.

Phil

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

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


= --Apple-Mail=_71E93C0C-A728-460C-8E90-4EEEF80FD69F-- From nobody Wed Sep 13 14:00:09 2017 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 CCCDA13305C for ; Wed, 13 Sep 2017 14:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.189 X-Spam-Level: X-Spam-Status: No, score=-4.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3N3PW0CEzeVt for ; Wed, 13 Sep 2017 14:00:03 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAA8313293A for ; Wed, 13 Sep 2017 14:00:02 -0700 (PDT) X-AuditID: 12074425-c95ff70000007029-f7-59b99c50e963 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id FD.05.28713.05C99B95; Wed, 13 Sep 2017 17:00:00 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id v8DL00S1031093; Wed, 13 Sep 2017 17:00:00 -0400 Received: from [192.168.1.7] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v8DKxwj3020077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 Sep 2017 16:59:59 -0400 From: Justin Richer Message-Id: <554CC2F4-D359-4534-8526-8B28B1E14589@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_F4C4DAEE-29D6-48EA-A47F-058A1D180D57" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 13 Sep 2017 16:59:57 -0400 In-Reply-To: <52A72F41-557D-4B73-BF06-FAB8362DB31F@oracle.com> Cc: vot@ietf.org To: Phil Hunt References: <52A72F41-557D-4B73-BF06-FAB8362DB31F@oracle.com> X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMKsWRmVeSWpSXmKPExsUixG6nohswZ2ekwcNVFhYL5jeyWzT8fMDq wOSxZMlPJo+PT2+xBDBFcdmkpOZklqUW6dslcGXcufCereDNTaaKDW3LmBsY7y5j6mLk4JAQ MJE4u7m+i5GLQ0hgMZPE4VntLBDORkaJO72bGSGca0wSjX1LmbsYOTnYBFQlpq9pYQKxeQWs JL51f2EDsZkFkiQ2b+tiBJnKK6Av0fucESQsLGAncXDOHzCbBah179vNLCA2J1C84+k+RohW AYm5h6aBjRQRUJH4dvU61N5FjBJfTz5jB0lICMhK3Jp9iXkCI/8sJOtmIayDCGtLLFv4mhnC 1pTY372cBVNcQ6Lz20TWBYxsqxhlU3KrdHMTM3OKU5N1i5MT8/JSi3Qt9HIzS/RSU0o3MYJD 20V1B+Ocv16HGAU4GJV4eB9Y7owUYk0sK67MPcQoycGkJMq7VxcoxJeUn1KZkVicEV9UmpNa fIhRgoNZSYT3ZgtQjjclsbIqtSgfJiXNwaIkziuu0RghJJCeWJKanZpakFoEk5Xh4FCS4DWb DdQoWJSanlqRlplTgpBm4uAEGc4DNPznLJDhxQWJucWZ6RD5U4z2HCce3v7DxNFx8y6Q3AAm 94FIIZa8/LxUKXHeNpDRAiBtGaV5cJNBact9nZ3FK0ZxoEeFebVBqniAKQ9u9iugtUxAa8+c 3gGytiQRISXVwNjLxT3/UcrkHdGT/eYfit1wr2+HOZ9FtHYpxwutKbJzF7RzHxHaV6tY8eeD zpadfbOdFmqaM39yfvIwN+1MaihHxr8JP+NPWbzmNo+ct8N9vXMXp5lVYJC1wF7966znDiVu ecKYsN3/0td9a6pL5254cHr+0xT5uUt31LBHPKnSXdyzoG2HwDslluKMREMt5qLiRAC3WrWp NgMAAA== Archived-At: Subject: Re: [VoT] VoT Identity Proofing and individual claims X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 21:00:08 -0000 --Apple-Mail=_F4C4DAEE-29D6-48EA-A47F-058A1D180D57 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Phil, responses inline. > On Sep 13, 2017, at 3:09 PM, Phil Hunt wrote: >=20 > Justin, >=20 > I don=E2=80=99t believe making things arbitrarily out of scope helps = simplify. In this case, I believe it complicates matters. >=20 I don=E2=80=99t understand your argument. We=E2=80=99re solving one = problem, but not the problem you=E2=80=99re trying to solve. It feels = complicated because you=E2=80=99re trying to use a tool that=E2=80=99s = not fit for the problem you=E2=80=99re presenting. That doesn=E2=80=99t = mean that it=E2=80=99s complicated for the problem the tool is designed = for. Keeping other things out of scope is exactly making this a = tractable problem within particular boundaries. This decision of scope = for this work is hardly arbitrary or ill-informed, so dismissing it as = such is both misunderstanding the work and not helpful in the = conversation.=20 > Firstly, missing from the spec=E2=80=A6.a definition of Identity. We didn=E2=80=99t try to define =E2=80=9Cidentity=E2=80=9D as a term = because there is no one single agreed-upon definition of identity, and = yet it is understood broadly as a concept enough to make identity = systems work, isn=E2=80=99t it? We do have a discussion of our identity = model at play in section 1.2 though. I=E2=80=99m assuming you=E2=80=99ve = read that, so please submit text that would improve that section. >=20 >> 2.1 = = . Identity Proofing >>=20 >> The Identity Proofing dimension defines, overall, how strongly the >> set of identity attributes have been verified and vetted. In = other >> words, this dimension describes how likely it is that a given = digital >> identity transaction corresponds to a particular (real-world) >> identity subject. >>=20 >> This dimension SHALL be represented by the "P" demarcator and a >> single-character level value, such as "P0", "P1", etc. Most >> definitions of identity proofing will have a natural ordering, as >> more or less stringent proofing can be applied to an individual. = In >> such cases it is RECOMMENDED that a digit style value be used for >> this component. >=20 > What is meant by overall? Is it an average? The lowest value of all = of the attributes (claims)? >=20 Again, that depends on the specific trust framework that defines what = the values mean. For NIST, for example, there are baseline proofings = required for all mentioned attributes at a given IAL. If you don=E2=80=99t= meet that level for all of those attributes, then you don=E2=80=99t = meet that IAL. Other frameworks could provide something else, but I=E2=80=99= ve yet to see a different approach. Do you know of a trust framework = that defines an =E2=80=9Caverage=E2=80=9D proofing level for a user=E2=80=99= s attributes?=20 Also interesting to note: if you=E2=80=99re providing additional = attributes that aren=E2=80=99t listed in the framework, like =E2=80=9Chas = a medical degree=E2=80=9D, then you=E2=80=99re on your own as the = framework doesn=E2=80=99t address those. If you need to address those = separately, you=E2=80=99ll need a framework (and vector definitions) = that cover those.=20 And if you want to have different sets of information for each = attribute, then you=E2=80=99ll want a different solution that=E2=80=99s = not VoT. > What is meant by a real world identity subject? Do you mean a legal = person? Do you mean a device/thing? Sure, those would all work. All depends on what the IdP is providing = identity assertions for. We=E2=80=99re not going to artificially limit = that, though we do have "a person using a computer system=E2=80=9D = generally in mind. Again, see section 1.2 for more details on that = model.=20 >=20 > An overall level of confidence in how strongly a transaction = corresponds to a particular identity subject sounds an awful lot like = authentication confidence. An overall confidence would be that, but this isn=E2=80=99t what we=E2=80=99= re saying: it=E2=80=99s how much the attributes are tied to a real = person. How strongly that gets tied to the transaction is subject to the = other vector components, such as authentication credentials and = assertions. That=E2=80=99s the whole reason of splitting it out = separately. So yes, it=E2=80=99s not as granular as individual = attributes, which you=E2=80=99re asking about below, but it=E2=80=99s = more granular than a single level of confidence that you have stated = here. It=E2=80=99s in between, like we say in the introduction.=20 >=20 > I can see how you might arrive at this definition looking an an = internal data system like a payroll system. You can assess the = procedures and establish an overall confidence level in the quality of = data. But as soon as you want to share that payroll data with other = systems. =20 >=20 > I began my experience in Identity management building large scale = meta-directories. We once assumed business systems like payroll systems = were authoritative over things like employee addresses. Turns out we = were wrong. Payroll doesn=E2=80=99t care about addresses, they care = about bank account deposit numbers. =20 Then, by your trust framework and context, you wouldn=E2=80=99t ask = payroll for addresses, right? So if your trust framework requires you to = verify the address at, say, P3, but you don=E2=80=99t do that, then = you=E2=80=99re not doing P3 for those. And if you need to split out = classes of users where you=E2=80=99ve got =E2=80=9Cauthoritative bank = account numbers=E2=80=9D and =E2=80=9Cauthoritative bank account numbers = AND addresses=E2=80=9D, then you define two different categories to = represent those classes of users. If you want a system that can describe = the assurance of an arbitrary attribute for a given transaction, then = VoT doesn=E2=80=99t work for you. Go find a screwdriver and stop trying = to figure out why this hammer doesn=E2=80=99t work for you. >=20 > Conclusion: Just because the payroll department has a high level of = confidence in the attributes they have *internally*, it does not mean = there is high confidence for secondary uses. If you ask payroll about = sharing data, they might only share employee number, salary, and bank = accounts as being accurate (assuming there was a valid reason to share). = Should an IDP based on payroll only assert high level data? Can they = assert low-level data for the purpose of correlation/confirmation? >=20 > Another case, look at Facebook and Twitter. They have variable = assertions as well. Some users are verified and some are not. What = does that mean? How would VoT help in this case? Would it mean that the = out of scope information in the name claim is deemed accurate? Are we = talking about the same Michael Douglas or are we talking about Michael = Keaton (Michael Keaton=E2=80=99s real name is Michael Douglas). VoT would help in exactly this case by being able to assert different = proofing based on different accounts. But it all comes down to what you = trust the IdP to assert given its trust framework context =E2=80=94 if = they agreed to proof the name, and they say they did, and you trust them = to make that claim, well then you=E2=80=99re all set. If they don=E2=80=99= t agree to that (as in it=E2=80=99s not stipulated in the trust = agreements) , or they agreed to it and lied about it, or they did it but = you don=E2=80=99t trust them to say it =E2=80=A6 then I can=E2=80=99t = really help you with this.=20 In the end, VoT is all about one simple thing: conveying bundles of = information about mostly-orthogonal aspects of an identity transaction. = It=E2=80=99s about an IdP telling an RP: =E2=80=9CI did the following = things from a list of things that we agreed upon=E2=80=9D. Just like = saying =E2=80=9CLOA3=E2=80=9D in the US Government context meant = something pretty specific, saying =E2=80=9CP2.Cc.Ab=E2=80=9D also means = something specific in that kind of context. But saying =E2=80=9CLOA3=E2=80= =9D in Canada means something a little bit different, and saying = =E2=80=9CLOA3=E2=80=9D elsewhere could be completely unrelated to either = case. In all of these, both the LoA and VoT versions, interpretation of = the result to a particular real-world meaning is outside the conveyance = protocol or encoding. There=E2=80=99s a massive amount of context that = is taken into account, and that context will tell you if you can trust = the name or the address or anything else when you get a particular = value. You=E2=80=99re trying to fit it into something it=E2=80=99s not meant = for and not good at, and asking why it doesn=E2=80=99t work; to me, = it=E2=80=99s no surprise that it doesn=E2=80=99t work for that. VoT does = not do what you=E2=80=99re describing, and that=E2=80=99s by design. = That part is spelled out in the introduction. On the same token, your = lawnmower makes a pretty bad toothbrush. But like I keep reiterating: if = you have a different problem, use a different tool. I am perfectly happy = with this technology not being a silver bullet or panacea or what have = you. There are a lot of people who seem to have the problem that this = tool solves, so we=E2=80=99re going to keep going with solving those = problems. I look forward to seeing your solutions for attribute trust = and metadata in the future. Thanks, =E2=80=94 Justin >=20 > Phil >=20 > Oracle Corporation, Identity Cloud Services Architect > @independentid > www.independentid.com = phil.hunt@oracle.com = >> On Sep 13, 2017, at 10:57 AM, Justin Richer > wrote: >>=20 >> It applies to the IdP=E2=80=99s judgement across the entire = assertion. How that=E2=80=99s calculated when the trust in different = attributes differs will vary depending on the IdP, and probably defined = by rules within the trust framework that defines the vector values = themselves. NIST 800-63-3 volume A, for example, is very clear about how = to handle all the attributes collected at different levels. If you were = using NIST=E2=80=99s encoding of VoT, specified in the upcoming volume D = of that document, then you=E2=80=99d be bound by those rules as an IdP. = A university group, like you=E2=80=99re talking about below, might have = different rules under its own trust framework and vector component = definitions. >>=20 >> It looks like you might be asking if this is about per-attribute = metadata. If you read the introduction, we explicitly state that we=E2=80=99= re not trying to solve per-attribute metadata. If you=E2=80=99d like = that kind of data, you=E2=80=99re looking for a different kind of = solution, of which there have been numerous attempts over the years. = Generally speaking, attribute metadata systems look great on paper but = are incredibly complicated for RP=E2=80=99s to implement. When we wrote = VoT, we directly decided to take a different approach, something between = the granularity of attributes and the single-scale of LOA.=20 >>=20 >> This level of granularity is very, very useful in the real world, = otherwise we wouldn=E2=80=99t have dozens of international trust = frameworks based around the concept of proofing an individual and tying = that account to a set of proofed attributes. There isn=E2=80=99t an easy = way to express something complex as =E2=80=9CWe=E2=80=99re sure this is = Justin but aren=E2=80=99t sure about his medical degree=E2=80=9D in any = VoT implementation that I=E2=80=99ve seen to date, and especially not in = the example values given in the spec itself. But if you really wanted = to, you could have something like: >>=20 >> - P3: High level of confidence in individual=E2=80=99s name, = address, phone, eye color, and shoe size >> - Pm: In person verification of a medical degree by making the = claimant perform surgery on the verifier. >>=20 >> So if you wanted to express that, you could say =E2=80=9CP3.Pm=E2=80=9D= or just =E2=80=9CP3=E2=80=9D if you weren=E2=80=99t so sure about that = medical degree. However, like I described above, I don=E2=80=99t think = this is a good solution for that as you=E2=80=99d need to get really = specific with each attribute. If you really need that level of = expressiveness, you=E2=80=99ll want a different solution and VoT = doesn=E2=80=99t work for you. However, just because it doesn=E2=80=99t = solve this use case doesn=E2=80=99t mean it=E2=80=99s not useful in many = others. VoT is a tool fit for a purpose that we tried to express in the = intro text, it fits in between attribute metadata and single scalar = measurements. And in fact, you could use it side by side in the same = system, and I see no conflict in this. >>=20 >> Don=E2=80=99t deny the world a hammer just because you think you need = a screwdriver. >>=20 >> =E2=80=94 Justin >>=20 >>> On Sep 13, 2017, at 1:01 PM, Phil Hunt > wrote: >>>=20 >>> Section 3.1 >>>=20 >>> Does 3.1 apply to the identifier issued, to the whole assertion?=20 >>>=20 >>> An Identity is usually an identifier and a set of claims. >>>=20 >>> So what about claims? Some claims may be issued by a provider (and = thus are P3) while others may be provided as self asserted by the = subject. Some, as in banking may have involved a physical documents or = other mechanism and thus all claims are not equal. >>>=20 >>> I have trouble determining the affect of P0-P3 and worry that = privilege escalation will occur since not all claims are equal. There = isn=E2=80=99t really a way to say =E2=80=9CWe=E2=80=99re confident this = is Justin, we=E2=80=99re just not so sure about his medical degree=E2=80=9D= . >>>=20 >>> Consider a university knows student numbers and degrees and courses = completed. Is it authoritative over nationality, residence, addresses? = Maybe. Maybe not. >>>=20 >>> Consider a social network. In many cases they can be considered = authoritative over the social network identity (P3) but know nothing = about most users. >>>=20 >>> I=E2=80=99m just not sure identity proofing as expressed is actually = useful. >>>=20 >>> Phil >>>=20 >>> Oracle Corporation, Identity Cloud Services Architect >>> @independentid >>> www.independentid.com = phil.hunt@= oracle.com >>> _______________________________________________ >>> vot mailing list >>> vot@ietf.org >>> https://www.ietf.org/mailman/listinfo/vot = >>=20 >=20 --Apple-Mail=_F4C4DAEE-29D6-48EA-A47F-058A1D180D57 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Phil, responses inline.


On = Sep 13, 2017, at 3:09 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Justin,

I don=E2=80=99t believe making things arbitrarily out of = scope helps simplify.  In this case, I believe it complicates = matters.


I= don=E2=80=99t understand your argument. We=E2=80=99re solving one = problem, but not the problem you=E2=80=99re trying to solve. It feels = complicated because you=E2=80=99re trying to use a tool that=E2=80=99s = not fit for the problem you=E2=80=99re presenting. That doesn=E2=80=99t = mean that it=E2=80=99s complicated for the problem the tool is designed = for. Keeping other things out of scope is exactly making this a = tractable problem within particular boundaries. This decision of scope = for this work is hardly arbitrary or ill-informed, so dismissing it as = such is both misunderstanding the work and not helpful in the = conversation. 

Firstly, missing from the spec=E2=80=A6.a = definition of Identity.

We didn=E2=80=99t try to define =E2=80=9Cidentity=E2= =80=9D as a term because there is no one single agreed-upon definition = of identity, and yet it is understood broadly as a concept enough to = make identity systems work, isn=E2=80=99t it? We do have a discussion of = our identity model at play in section 1.2 though. I=E2=80=99m assuming = you=E2=80=99ve read that, so please submit text that would improve that = section.


2.1.  Identity =
Proofing


   The Identity Proofing dimension defines, overall, how strongly the
   set of identity attributes have been verified and vetted.  In other
   words, this dimension describes how likely it is that a given digital
   identity transaction corresponds to a particular (real-world)
   identity subject.

   This dimension SHALL be represented by the "P" demarcator and a
   single-character level value, such as "P0", "P1", etc.  Most
   definitions of identity proofing will have a natural ordering, as
   more or less stringent proofing can be applied to an individual.  In
   such cases it is RECOMMENDED that a digit style value be used for
   this component.

What is meant by overall? =  Is it an average?  The lowest value of all of the attributes = (claims)?


Again, that depends on the specific trust = framework that defines what the values mean. For NIST, for example, = there are baseline proofings required for all mentioned attributes at a = given IAL. If you don=E2=80=99t meet that level for all = of those attributes, then you don=E2=80=99t meet that IAL. Other = frameworks could provide something else, but I=E2=80=99ve yet to see a = different approach. Do you know of a trust framework that defines an = =E2=80=9Caverage=E2=80=9D proofing level for a user=E2=80=99s = attributes? 

Also interesting = to note: if you=E2=80=99re providing additional attributes that aren=E2=80= =99t listed in the framework, like =E2=80=9Chas a medical degree=E2=80=9D,= then you=E2=80=99re on your own as the framework doesn=E2=80=99t = address those. If you need to address those separately, you=E2=80=99ll = need a framework (and vector definitions) that cover = those. 

And if you want to have = different sets of information for each attribute, then you=E2=80=99ll = want a different solution that=E2=80=99s not VoT.

What = is meant by a real world identity subject?  Do you mean a legal = person?  Do you mean a = device/thing?

Sure, those would all work. All depends on what = the IdP is providing identity assertions for. We=E2=80=99re not going to = artificially limit that, though we do have "a person using a computer = system=E2=80=9D generally in mind. Again, see section 1.2 for more = details on that model. 


An = overall level of confidence in how strongly a transaction corresponds to = a particular identity subject sounds an awful lot like authentication = confidence.

An overall confidence would be that, but this = isn=E2=80=99t what we=E2=80=99re saying: it=E2=80=99s how much the = attributes are tied to a real person. How strongly that gets tied to the = transaction is subject to the other vector components, such as = authentication credentials and assertions. That=E2=80=99s the whole = reason of splitting it out separately. So yes, it=E2=80=99s not as = granular as individual attributes, which you=E2=80=99re asking about = below, but it=E2=80=99s more granular than a single level of confidence = that you have stated here. It=E2=80=99s in between, like we say in the = introduction. 


I can = see how you might arrive at this definition looking an an internal data = system like a payroll system. You can assess the procedures and = establish an overall confidence level in the quality of data.  But = as soon as you want to share that payroll data with other systems. =  

I began = my experience in Identity management building large scale = meta-directories. We once assumed business systems like payroll systems = were authoritative over things like employee addresses.  Turns out = we were wrong.  Payroll doesn=E2=80=99t care about addresses, they = care about bank account deposit numbers. =  

Then, = by your trust framework and context, you wouldn=E2=80=99t ask payroll = for addresses, right? So if your trust framework requires you to verify = the address at, say, P3, but you don=E2=80=99t do that, then you=E2=80=99r= e not doing P3 for those. And if you need to split out classes of users = where you=E2=80=99ve got =E2=80=9Cauthoritative bank account numbers=E2=80= =9D and =E2=80=9Cauthoritative bank account numbers AND addresses=E2=80=9D= , then you define two different categories to represent those classes of = users. If you want a system that can describe the assurance of an = arbitrary attribute for a given transaction, then VoT doesn=E2=80=99t = work for you. Go find a screwdriver and stop trying to figure out why = this hammer doesn=E2=80=99t work for you.


Conclusion:  Just because the payroll department has a = high level of confidence in the attributes they have *internally*, it = does not mean there is high confidence for secondary uses.  If you = ask payroll about sharing data, they might only share employee number, = salary, and bank accounts as being accurate (assuming there was a valid = reason to share).  Should an IDP based on payroll only assert high = level data?  Can they assert low-level data for the purpose of = correlation/confirmation?

Another case, look at Facebook and Twitter. They have = variable assertions as well.  Some users are verified and some are = not.  What does that mean? How would VoT help in this case? =  Would it mean that the out of scope information in the name claim = is deemed accurate?  Are we talking about the same Michael Douglas = or are we talking about Michael Keaton (Michael Keaton=E2=80=99s real = name is Michael Douglas).

VoT would help in exactly this case by being able = to assert different proofing based on different accounts. But it all = comes down to what you trust the IdP to assert given its trust framework = context =E2=80=94 if they agreed to proof the name, and they say they = did, and you trust them to make that claim, well then you=E2=80=99re all = set. If they don=E2=80=99t agree to that (as in it=E2=80=99s not = stipulated in the trust agreements) , or they agreed to it and lied = about it, or they did it but you don=E2=80=99t trust them to say it =E2=80= =A6 then I can=E2=80=99t really help you with this. 

In the end, VoT is all about one simple thing: = conveying bundles of information about mostly-orthogonal aspects of an = identity transaction. It=E2=80=99s about an IdP telling an RP: =E2=80=9CI = did the following things from a list of things that we agreed upon=E2=80=9D= . Just like saying =E2=80=9CLOA3=E2=80=9D in the US Government context = meant something pretty specific, saying =E2=80=9CP2.Cc.Ab=E2=80=9D also = means something specific in that kind of context. But saying =E2=80=9CLOA3= =E2=80=9D in Canada means something a little bit different, and saying = =E2=80=9CLOA3=E2=80=9D elsewhere could be completely unrelated to either = case. In all of these, both the LoA and VoT versions, interpretation of = the result to a particular real-world meaning is outside the conveyance = protocol or encoding. There=E2=80=99s a massive amount of context that = is taken into account, and that context will tell you if you can trust = the name or the address or anything else when you get a particular = value.

You=E2=80=99re trying to fit = it into something it=E2=80=99s not meant for and not good at, and asking = why it doesn=E2=80=99t work; to me, it=E2=80=99s no surprise that it = doesn=E2=80=99t work for that. VoT does not do what you=E2=80=99re = describing, and that=E2=80=99s by design. That part is spelled out in = the introduction. On the same token, your lawnmower makes a pretty bad = toothbrush. But like I keep reiterating: if you have a = different problem, use a different tool. I am = perfectly happy with this technology not being a silver bullet or = panacea or what have you. There are a lot of people who seem to have the = problem that this tool solves, so we=E2=80=99re going to keep going with = solving those problems. I look forward to seeing your solutions for = attribute trust and metadata in the future.

Thanks,
 =E2=80=94 Justin


Phil

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

On Sep 13, 2017, at 10:57 AM, Justin Richer <jricher@mit.edu> = wrote:

It applies to the = IdP=E2=80=99s judgement across the entire assertion. How that=E2=80=99s = calculated when the trust in different attributes differs will vary = depending on the IdP, and probably defined by rules within the trust = framework that defines the vector values themselves. NIST 800-63-3 = volume A, for example, is very clear about how to handle all the = attributes collected at different levels. If you were using NIST=E2=80=99s= encoding of VoT, specified in the upcoming volume D of that document, = then you=E2=80=99d be bound by those rules as an IdP. A university = group, like you=E2=80=99re talking about below, might have different = rules under its own trust framework and vector component = definitions.

It = looks like you might be asking if this is about per-attribute metadata. = If you read the introduction, we explicitly state that we=E2=80=99re not = trying to solve per-attribute metadata. If you=E2=80=99d like that kind = of data, you=E2=80=99re looking for a different kind of solution, of = which there have been numerous attempts over the years. Generally = speaking, attribute metadata systems look great on paper but are = incredibly complicated for RP=E2=80=99s to implement. When we wrote VoT, = we directly decided to take a different approach, something between the = granularity of attributes and the single-scale of LOA. 

This level of = granularity is very, very useful in the real world, otherwise we = wouldn=E2=80=99t have dozens of international trust frameworks based = around the concept of proofing an individual and tying that account to a = set of proofed attributes. There isn=E2=80=99t an easy way to express = something complex as =E2=80=9CWe=E2=80=99re sure this is Justin but = aren=E2=80=99t sure about his medical degree=E2=80=9D in any VoT = implementation that I=E2=80=99ve seen to date, and especially not in the = example values given in the spec itself. But if you really wanted to, = you could have something like:

 - P3: High level of confidence in = individual=E2=80=99s name, address, phone, eye color, and shoe = size
 - Pm: In person verification of a = medical degree by making the claimant perform surgery on the = verifier.

So = if you wanted to express that, you could say =E2=80=9CP3.Pm=E2=80=9D or = just =E2=80=9CP3=E2=80=9D if you weren=E2=80=99t so sure about that = medical degree. However, like I described above, I don=E2=80=99t think = this is a good solution for that as you=E2=80=99d need to get really = specific with each attribute. If you really need that level of = expressiveness, you=E2=80=99ll want a different solution and VoT = doesn=E2=80=99t work for you. However, just because it doesn=E2=80=99t = solve this use case doesn=E2=80=99t mean it=E2=80=99s not useful in many = others. VoT is a tool fit for a purpose that we tried to express in the = intro text, it fits in between attribute metadata and single scalar = measurements. And in fact, you could use it side by side in the same = system, and I see no conflict in this.

Don=E2=80=99t deny the world a hammer = just because you think you need a screwdriver.

 =E2=80=94 Justin

On Sep 13, 2017, at 1:01 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Section= 3.1

Does 3.1 = apply to the identifier issued, to the whole assertion? 

An Identity is usually = an identifier and a set of claims.

So what about claims?   Some = claims may be issued by a provider (and thus are P3) while others may be = provided as self asserted by the subject.  Some, as in banking may = have involved a physical documents or other mechanism and thus all = claims are not equal.

I have trouble determining the affect of P0-P3 and worry that = privilege escalation will occur since not all claims are equal. =  There isn=E2=80=99t really a way to say =E2=80=9CWe=E2=80=99re = confident this is Justin, we=E2=80=99re just not so sure about his = medical degree=E2=80=9D.

Consider a university knows student numbers and degrees and = courses completed. Is it authoritative over nationality, residence, = addresses?  Maybe. Maybe not.

Consider a social network. In many = cases they can be considered authoritative over the social network = identity (P3) but know nothing about most users.

I=E2=80=99m just not sure identity = proofing as expressed is actually useful.

Phil

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

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



= --Apple-Mail=_F4C4DAEE-29D6-48EA-A47F-058A1D180D57-- From nobody Wed Sep 13 14:32:17 2017 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 7D878132F63 for ; Wed, 13 Sep 2017 14:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.999 X-Spam-Level: X-Spam-Status: No, score=-4.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3kjYhRxjEXbx for ; Wed, 13 Sep 2017 14:32:12 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 086C2132F87 for ; Wed, 13 Sep 2017 14:32:11 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v8DLWA6D021494 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 13 Sep 2017 21:32:10 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v8DLW9Fm028418 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 13 Sep 2017 21:32:10 GMT Received: from ubhmp0011.oracle.com (ubhmp0011.oracle.com [156.151.24.64]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v8DLW8fu003804; Wed, 13 Sep 2017 21:32:08 GMT Received: from [10.224.66.212] (/24.244.32.167) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 13 Sep 2017 21:32:08 +0000 Content-Type: multipart/alternative; boundary=Apple-Mail-E6173B20-2A40-4207-9B4F-A1CEA8602490 Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (14G60) In-Reply-To: <554CC2F4-D359-4534-8526-8B28B1E14589@mit.edu> Date: Wed, 13 Sep 2017 14:32:07 -0700 Cc: vot@ietf.org Content-Transfer-Encoding: 7bit Message-Id: References: <52A72F41-557D-4B73-BF06-FAB8362DB31F@oracle.com> <554CC2F4-D359-4534-8526-8B28B1E14589@mit.edu> To: Justin Richer X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Subject: Re: [VoT] VoT Identity Proofing and individual claims X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 21:32:15 -0000 --Apple-Mail-E6173B20-2A40-4207-9B4F-A1CEA8602490 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I am saying you cannot and must not solve the problem you are solving withou= t dealing with the individual claims and how they combine to form an overall= proof. Leaving proofing undefined moves to a situation worse than depending on Leve= l of authentication alone.=20 Phil > On Sep 13, 2017, at 1:59 PM, Justin Richer wrote: >=20 > Phil, responses inline. >=20 >=20 >> On Sep 13, 2017, at 3:09 PM, Phil Hunt wrote: >>=20 >> Justin, >>=20 >> I don=E2=80=99t believe making things arbitrarily out of scope helps simp= lify. In this case, I believe it complicates matters. >>=20 >=20 > I don=E2=80=99t understand your argument. We=E2=80=99re solving one proble= m, but not the problem you=E2=80=99re trying to solve. It feels complicated b= ecause you=E2=80=99re trying to use a tool that=E2=80=99s not fit for the pr= oblem you=E2=80=99re presenting. That doesn=E2=80=99t mean that it=E2=80=99s= complicated for the problem the tool is designed for. Keeping other things o= ut of scope is exactly making this a tractable problem within particular bou= ndaries. This decision of scope for this work is hardly arbitrary or ill-inf= ormed, so dismissing it as such is both misunderstanding the work and not he= lpful in the conversation.=20 >=20 >> Firstly, missing from the spec=E2=80=A6.a definition of Identity. >=20 > We didn=E2=80=99t try to define =E2=80=9Cidentity=E2=80=9D as a term becau= se there is no one single agreed-upon definition of identity, and yet it is u= nderstood broadly as a concept enough to make identity systems work, isn=E2=80= =99t it? We do have a discussion of our identity model at play in section 1.= 2 though. I=E2=80=99m assuming you=E2=80=99ve read that, so please submit te= xt that would improve that section. >=20 >>=20 >>> 2.1. Identity Proofing >>>=20 >>> The Identity Proofing dimension defines, overall, how strongly the >>> set of identity attributes have been verified and vetted. In other >>> words, this dimension describes how likely it is that a given digital= >>> identity transaction corresponds to a particular (real-world) >>> identity subject. >>>=20 >>> This dimension SHALL be represented by the "P" demarcator and a >>> single-character level value, such as "P0", "P1", etc. Most >>> definitions of identity proofing will have a natural ordering, as >>> more or less stringent proofing can be applied to an individual. In >>> such cases it is RECOMMENDED that a digit style value be used for >>> this component. >>=20 >> What is meant by overall? Is it an average? The lowest value of all of t= he attributes (claims)? >>=20 >=20 > Again, that depends on the specific trust framework that defines what the v= alues mean. For NIST, for example, there are baseline proofings required for= all mentioned attributes at a given IAL. If you don=E2=80=99t meet that lev= el for all of those attributes, then you don=E2=80=99t meet that IAL. Other f= rameworks could provide something else, but I=E2=80=99ve yet to see a differ= ent approach. Do you know of a trust framework that defines an =E2=80=9Caver= age=E2=80=9D proofing level for a user=E2=80=99s attributes?=20 >=20 > Also interesting to note: if you=E2=80=99re providing additional attribute= s that aren=E2=80=99t listed in the framework, like =E2=80=9Chas a medical d= egree=E2=80=9D, then you=E2=80=99re on your own as the framework doesn=E2=80= =99t address those. If you need to address those separately, you=E2=80=99ll n= eed a framework (and vector definitions) that cover those.=20 >=20 > And if you want to have different sets of information for each attribute, t= hen you=E2=80=99ll want a different solution that=E2=80=99s not VoT. >=20 >> What is meant by a real world identity subject? Do you mean a legal pers= on? Do you mean a device/thing? >=20 > Sure, those would all work. All depends on what the IdP is providing ident= ity assertions for. We=E2=80=99re not going to artificially limit that, thou= gh we do have "a person using a computer system=E2=80=9D generally in mind. A= gain, see section 1.2 for more details on that model.=20 >=20 >>=20 >> An overall level of confidence in how strongly a transaction corresponds t= o a particular identity subject sounds an awful lot like authentication conf= idence. >=20 > An overall confidence would be that, but this isn=E2=80=99t what we=E2=80=99= re saying: it=E2=80=99s how much the attributes are tied to a real person. H= ow strongly that gets tied to the transaction is subject to the other vector= components, such as authentication credentials and assertions. That=E2=80=99= s the whole reason of splitting it out separately. So yes, it=E2=80=99s not a= s granular as individual attributes, which you=E2=80=99re asking about below= , but it=E2=80=99s more granular than a single level of confidence that you h= ave stated here. It=E2=80=99s in between, like we say in the introduction.=20= >=20 >>=20 >> I can see how you might arrive at this definition looking an an internal d= ata system like a payroll system. You can assess the procedures and establis= h an overall confidence level in the quality of data. But as soon as you wa= nt to share that payroll data with other systems. =20 >>=20 >> I began my experience in Identity management building large scale meta-di= rectories. We once assumed business systems like payroll systems were author= itative over things like employee addresses. Turns out we were wrong. Payr= oll doesn=E2=80=99t care about addresses, they care about bank account depos= it numbers. =20 >=20 > Then, by your trust framework and context, you wouldn=E2=80=99t ask payrol= l for addresses, right? So if your trust framework requires you to verify th= e address at, say, P3, but you don=E2=80=99t do that, then you=E2=80=99re no= t doing P3 for those. And if you need to split out classes of users where yo= u=E2=80=99ve got =E2=80=9Cauthoritative bank account numbers=E2=80=9D and =E2= =80=9Cauthoritative bank account numbers AND addresses=E2=80=9D, then you de= fine two different categories to represent those classes of users. If you wa= nt a system that can describe the assurance of an arbitrary attribute for a g= iven transaction, then VoT doesn=E2=80=99t work for you. Go find a screwdriv= er and stop trying to figure out why this hammer doesn=E2=80=99t work for yo= u. >=20 >>=20 >> Conclusion: Just because the payroll department has a high level of conf= idence in the attributes they have *internally*, it does not mean there is h= igh confidence for secondary uses. If you ask payroll about sharing data, t= hey might only share employee number, salary, and bank accounts as being acc= urate (assuming there was a valid reason to share). Should an IDP based on p= ayroll only assert high level data? Can they assert low-level data for the p= urpose of correlation/confirmation? >>=20 >> Another case, look at Facebook and Twitter. They have variable assertions= as well. Some users are verified and some are not. What does that mean? H= ow would VoT help in this case? Would it mean that the out of scope informa= tion in the name claim is deemed accurate? Are we talking about the same Mi= chael Douglas or are we talking about Michael Keaton (Michael Keaton=E2=80=99= s real name is Michael Douglas). >=20 > VoT would help in exactly this case by being able to assert different proo= fing based on different accounts. But it all comes down to what you trust th= e IdP to assert given its trust framework context =E2=80=94 if they agreed t= o proof the name, and they say they did, and you trust them to make that cla= im, well then you=E2=80=99re all set. If they don=E2=80=99t agree to that (a= s in it=E2=80=99s not stipulated in the trust agreements) , or they agreed t= o it and lied about it, or they did it but you don=E2=80=99t trust them to s= ay it =E2=80=A6 then I can=E2=80=99t really help you with this.=20 >=20 > In the end, VoT is all about one simple thing: conveying bundles of inform= ation about mostly-orthogonal aspects of an identity transaction. It=E2=80=99= s about an IdP telling an RP: =E2=80=9CI did the following things from a lis= t of things that we agreed upon=E2=80=9D. Just like saying =E2=80=9CLOA3=E2=80= =9D in the US Government context meant something pretty specific, saying =E2= =80=9CP2.Cc.Ab=E2=80=9D also means something specific in that kind of contex= t. But saying =E2=80=9CLOA3=E2=80=9D in Canada means something a little bit d= ifferent, and saying =E2=80=9CLOA3=E2=80=9D elsewhere could be completely un= related to either case. In all of these, both the LoA and VoT versions, inte= rpretation of the result to a particular real-world meaning is outside the c= onveyance protocol or encoding. There=E2=80=99s a massive amount of context t= hat is taken into account, and that context will tell you if you can trust t= he name or the address or anything else when you get a particular value. >=20 > You=E2=80=99re trying to fit it into something it=E2=80=99s not meant for a= nd not good at, and asking why it doesn=E2=80=99t work; to me, it=E2=80=99s n= o surprise that it doesn=E2=80=99t work for that. VoT does not do what you=E2= =80=99re describing, and that=E2=80=99s by design. That part is spelled out i= n the introduction. On the same token, your lawnmower makes a pretty bad too= thbrush. But like I keep reiterating: if you have a different problem, use a= different tool. I am perfectly happy with this technology not being a silve= r bullet or panacea or what have you. There are a lot of people who seem to h= ave the problem that this tool solves, so we=E2=80=99re going to keep going w= ith solving those problems. I look forward to seeing your solutions for attr= ibute trust and metadata in the future. >=20 > Thanks, > =E2=80=94 Justin >=20 >>=20 >> Phil >>=20 >> Oracle Corporation, Identity Cloud Services Architect >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>> On Sep 13, 2017, at 10:57 AM, Justin Richer wrote: >>>=20 >>> It applies to the IdP=E2=80=99s judgement across the entire assertion. H= ow that=E2=80=99s calculated when the trust in different attributes differs w= ill vary depending on the IdP, and probably defined by rules within the trus= t framework that defines the vector values themselves. NIST 800-63-3 volume A= , for example, is very clear about how to handle all the attributes collecte= d at different levels. If you were using NIST=E2=80=99s encoding of VoT, spe= cified in the upcoming volume D of that document, then you=E2=80=99d be boun= d by those rules as an IdP. A university group, like you=E2=80=99re talking a= bout below, might have different rules under its own trust framework and vec= tor component definitions. >>>=20 >>> It looks like you might be asking if this is about per-attribute metadat= a. If you read the introduction, we explicitly state that we=E2=80=99re not t= rying to solve per-attribute metadata. If you=E2=80=99d like that kind of da= ta, you=E2=80=99re looking for a different kind of solution, of which there h= ave been numerous attempts over the years. Generally speaking, attribute met= adata systems look great on paper but are incredibly complicated for RP=E2=80= =99s to implement. When we wrote VoT, we directly decided to take a differen= t approach, something between the granularity of attributes and the single-s= cale of LOA.=20 >>>=20 >>> This level of granularity is very, very useful in the real world, otherw= ise we wouldn=E2=80=99t have dozens of international trust frameworks based a= round the concept of proofing an individual and tying that account to a set o= f proofed attributes. There isn=E2=80=99t an easy way to express something c= omplex as =E2=80=9CWe=E2=80=99re sure this is Justin but aren=E2=80=99t sure= about his medical degree=E2=80=9D in any VoT implementation that I=E2=80=99= ve seen to date, and especially not in the example values given in the spec i= tself. But if you really wanted to, you could have something like: >>>=20 >>> - P3: High level of confidence in individual=E2=80=99s name, address, p= hone, eye color, and shoe size >>> - Pm: In person verification of a medical degree by making the claimant= perform surgery on the verifier. >>>=20 >>> So if you wanted to express that, you could say =E2=80=9CP3.Pm=E2=80=9D o= r just =E2=80=9CP3=E2=80=9D if you weren=E2=80=99t so sure about that medica= l degree. However, like I described above, I don=E2=80=99t think this is a g= ood solution for that as you=E2=80=99d need to get really specific with each= attribute. If you really need that level of expressiveness, you=E2=80=99ll w= ant a different solution and VoT doesn=E2=80=99t work for you. However, just= because it doesn=E2=80=99t solve this use case doesn=E2=80=99t mean it=E2=80= =99s not useful in many others. VoT is a tool fit for a purpose that we trie= d to express in the intro text, it fits in between attribute metadata and si= ngle scalar measurements. And in fact, you could use it side by side in the s= ame system, and I see no conflict in this. >>>=20 >>> Don=E2=80=99t deny the world a hammer just because you think you need a s= crewdriver. >>>=20 >>> =E2=80=94 Justin >>>=20 >>>> On Sep 13, 2017, at 1:01 PM, Phil Hunt wrote: >>>>=20 >>>> Section 3.1 >>>>=20 >>>> Does 3.1 apply to the identifier issued, to the whole assertion?=20 >>>>=20 >>>> An Identity is usually an identifier and a set of claims. >>>>=20 >>>> So what about claims? Some claims may be issued by a provider (and th= us are P3) while others may be provided as self asserted by the subject. So= me, as in banking may have involved a physical documents or other mechanism a= nd thus all claims are not equal. >>>>=20 >>>> I have trouble determining the affect of P0-P3 and worry that privilege= escalation will occur since not all claims are equal. There isn=E2=80=99t r= eally a way to say =E2=80=9CWe=E2=80=99re confident this is Justin, we=E2=80= =99re just not so sure about his medical degree=E2=80=9D. >>>>=20 >>>> Consider a university knows student numbers and degrees and courses com= pleted. Is it authoritative over nationality, residence, addresses? Maybe. M= aybe not. >>>>=20 >>>> Consider a social network. In many cases they can be considered authori= tative over the social network identity (P3) but know nothing about most use= rs. >>>>=20 >>>> I=E2=80=99m just not sure identity proofing as expressed is actually us= eful. >>>>=20 >>>> Phil >>>>=20 >>>> Oracle Corporation, Identity Cloud Services Architect >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>>=20 >>>> _______________________________________________ >>>> vot mailing list >>>> vot@ietf.org >>>> https://www.ietf.org/mailman/listinfo/vot >>>=20 >>=20 >=20 > _______________________________________________ > vot mailing list > vot@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_vot&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=3D= JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=3DYA2JdBOYM3SQx_1fv088j5CyhfvT= mnNkKzLEMsXgaWg&s=3DQaJdlNrWPDiVCUqj1JxH47PsYrKlCK7y_cZGiMQ0_mY&e=3D=20 --Apple-Mail-E6173B20-2A40-4207-9B4F-A1CEA8602490 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I am saying you cannot and must not so= lve the problem you are solving without dealing with the individual claims a= nd how they combine to form an overall proof.

Leaving proofing undefined mo= ves to a situation worse than depending on Level of authentication alone.&nb= sp;

Phil

On Sep 13, 20= 17, at 1:59 PM, Justin Richer <jricher= @mit.edu> wrote:

Phil, responses inline.


On Sep 13, 2017, at 3:09 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Justin,

I don=E2=80=99t believe making t= hings arbitrarily out of scope helps simplify.  In this case, I believe= it complicates matters.


I don=E2=80=99t understand yo= ur argument. We=E2=80=99re solving one problem, but not the problem you=E2=80= =99re trying to solve. It feels complicated because you=E2=80=99re trying to= use a tool that=E2=80=99s not fit for the problem you=E2=80=99re presenting= . That doesn=E2=80=99t mean that it=E2=80=99s complicated for the problem th= e tool is designed for. Keeping other things out of scope is exactly making t= his a tractable problem within particular boundaries. This decision of scope= for this work is hardly arbitrary or ill-informed, so dismissing it as such= is both misunderstanding the work and not helpful in the conversation. = ;

<= div style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-b= reak: after-white-space;" class=3D"">
Firstly, missing from t= he spec=E2=80=A6.a definition of Identity.

We didn=E2=80=99t try to define =E2=80=9Cidentit= y=E2=80=9D as a term because there is no one single agreed-upon definition o= f identity, and yet it is understood broadly as a concept enough to make ide= ntity systems work, isn=E2=80=99t it? We do have a discussion of our identit= y model at play in section 1.2 though. I=E2=80=99m assuming you=E2=80=99ve r= ead that, so please submit text that would improve that section.


2.1.  Identity Proofing


   The Identity Proofing dimension defines, overall, how strongly the
   set of identity attributes have been verified and vetted.  In other
   words, this dimension describes how likely it is that a given digital
   identity transaction corresponds to a particular (real-world)
   identity subject.

   This dimension SHALL be represented by the "P" demarcator and a
   single-character level value, such as "P0", "P1", etc.  Most
   definitions of identity proofing will have a natural ordering, as
   more or less stringent proofing can be applied to an individual.  In
   such cases it is RECOMMENDED that a digit style value be used for
   this component.

What is meant by overall?  Is it an average?  = The lowest value of all of the attributes (claims)?

Ag= ain, that depends on the specific trust framework that defines what the valu= es mean. For NIST, for example, there are baseline proofings required for al= l mentioned attributes at a given IAL. If you don=E2=80=99t meet that level f= or all of those attributes, then you don=E2=80=99t meet th= at IAL. Other frameworks could provide something else, but I=E2=80=99ve yet t= o see a different approach. Do you know of a trust framework that defines an= =E2=80=9Caverage=E2=80=9D proofing level for a user=E2=80=99s attributes?&n= bsp;

Also interesting to note: if you=E2= =80=99re providing additional attributes that aren=E2=80=99t listed in the f= ramework, like =E2=80=9Chas a medical degree=E2=80=9D, then you=E2=80=99re o= n your own as the framework doesn=E2=80=99t address those. If you need to ad= dress those separately, you=E2=80=99ll need a framework (and vector definiti= ons) that cover those. 

And if you w= ant to have different sets of information for each attribute, then you=E2=80= =99ll want a different solution that=E2=80=99s not VoT.

=
What is meant by a real world identity subjec= t?  Do you mean a legal person?  Do you mean a device/thing?
=

Sure, those would al= l work. All depends on what the IdP is providing identity assertions for. We= =E2=80=99re not going to artificially limit that, though we do have "a perso= n using a computer system=E2=80=9D generally in mind. Again, see section 1.2= for more details on that model. 


An overall level of confide= nce in how strongly a transaction corresponds to a particular identity subje= ct sounds an awful lot like authentication confidence.

An overall confidence would be that,= but this isn=E2=80=99t what we=E2=80=99re saying: it=E2=80=99s how much the= attributes are tied to a real person. How strongly that gets tied to the tr= ansaction is subject to the other vector components, such as authentication c= redentials and assertions. That=E2=80=99s the whole reason of splitting it o= ut separately. So yes, it=E2=80=99s not as granular as individual attributes= , which you=E2=80=99re asking about below, but it=E2=80=99s more granular th= an a single level of confidence that you have stated here. It=E2=80=99s in b= etween, like we say in the introduction. 


I can see how you= might arrive at this definition looking an an internal data system like a p= ayroll system. You can assess the procedures and establish an overall confid= ence level in the quality of data.  But as soon as you want to share th= at payroll data with other systems.  

I began my experience in Identity management buildi= ng large scale meta-directories. We once assumed business systems like payro= ll systems were authoritative over things like employee addresses.  Tur= ns out we were wrong.  Payroll doesn=E2=80=99t care about addresses, th= ey care about bank account deposit numbers.  

Then, by your trust framework and contex= t, you wouldn=E2=80=99t ask payroll for addresses, right? So if your trust f= ramework requires you to verify the address at, say, P3, but you don=E2=80=99= t do that, then you=E2=80=99re not doing P3 for those. And if you need to sp= lit out classes of users where you=E2=80=99ve got =E2=80=9Cauthoritative ban= k account numbers=E2=80=9D and =E2=80=9Cauthoritative bank account numbers A= ND addresses=E2=80=9D, then you define two different categories to represent= those classes of users. If you want a system that can describe the assuranc= e of an arbitrary attribute for a given transaction, then VoT doesn=E2=80=99= t work for you. Go find a screwdriver and stop trying to figure out why this= hammer doesn=E2=80=99t work for you.


Conclusion:  Just beca= use the payroll department has a high level of confidence in the attributes t= hey have *internally*, it does not mean there is high confidence for seconda= ry uses.  If you ask payroll about sharing data, they might only share e= mployee number, salary, and bank accounts as being accurate (assuming there w= as a valid reason to share).  Should an IDP based on payroll only asser= t high level data?  Can they assert low-level data for the purpose of c= orrelation/confirmation?

Another case, look at Facebook and Twitter. They have variable assert= ions as well.  Some users are verified and some are not.  What doe= s that mean? How would VoT help in this case?  Would it mean that the o= ut of scope information in the name claim is deemed accurate?  Are we t= alking about the same Michael Douglas or are we talking about Michael Keaton= (Michael Keaton=E2=80=99s real name is Michael Douglas).
<= /blockquote>

VoT would help in exactly this ca= se by being able to assert different proofing based on different accounts. B= ut it all comes down to what you trust the IdP to assert given its trust fra= mework context =E2=80=94 if they agreed to proof the name, and they say they= did, and you trust them to make that claim, well then you=E2=80=99re all se= t. If they don=E2=80=99t agree to that (as in it=E2=80=99s not stipulated in= the trust agreements) , or they agreed to it and lied about it, or they did= it but you don=E2=80=99t trust them to say it =E2=80=A6 then I can=E2=80=99= t really help you with this. 

In th= e end, VoT is all about one simple thing: conveying bundles of information a= bout mostly-orthogonal aspects of an identity transaction. It=E2=80=99s abou= t an IdP telling an RP: =E2=80=9CI did the following things from a list of t= hings that we agreed upon=E2=80=9D. Just like saying =E2=80=9CLOA3=E2=80=9D i= n the US Government context meant something pretty specific, saying =E2=80=9C= P2.Cc.Ab=E2=80=9D also means something specific in that kind of context. But= saying =E2=80=9CLOA3=E2=80=9D in Canada means something a little bit differ= ent, and saying =E2=80=9CLOA3=E2=80=9D elsewhere could be completely unrelat= ed to either case. In all of these, both the LoA and VoT versions, interpret= ation of the result to a particular real-world meaning is outside the convey= ance protocol or encoding. There=E2=80=99s a massive amount of context that i= s taken into account, and that context will tell you if you can trust the na= me or the address or anything else when you get a particular value.

You=E2=80=99re trying to fit it into something i= t=E2=80=99s not meant for and not good at, and asking why it doesn=E2=80=99t= work; to me, it=E2=80=99s no surprise that it doesn=E2=80=99t work for that= . VoT does not do what you=E2=80=99re describing, and that=E2=80=99s by desi= gn. That part is spelled out in the introduction. On the same token, your la= wnmower makes a pretty bad toothbrush. But like I keep rei= terating: if you have a different problem, use a different too= l. I am perfectly happy with this technology not being a silver bul= let or panacea or what have you. There are a lot of people who seem to have t= he problem that this tool solves, so we=E2=80=99re going to keep going with s= olving those problems. I look forward to seeing your solutions for attribute= trust and metadata in the future.

Thank= s,
 =E2=80=94 Justin


Phil

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

On Sep 13, 2017, at 10:57 AM, Justin Richer <jricher@mit.edu> wrote:

It applies to the IdP=E2=80=99s judgement across the entire assertion. Ho= w that=E2=80=99s calculated when the trust in different attributes differs w= ill vary depending on the IdP, and probably defined by rules within the trus= t framework that defines the vector values themselves. NIST 800-63-3 volume A= , for example, is very clear about how to handle all the attributes collecte= d at different levels. If you were using NIST=E2=80=99s encoding of VoT, spe= cified in the upcoming volume D of that document, then you=E2=80=99d be boun= d by those rules as an IdP. A university group, like you=E2=80=99re talking a= bout below, might have different rules under its own trust framework and vec= tor component definitions.

It looks like you might be asking if this is about per-attribute metadata= . If you read the introduction, we explicitly state that we=E2=80=99re not t= rying to solve per-attribute metadata. If you=E2=80=99d like that kind of da= ta, you=E2=80=99re looking for a different kind of solution, of which there h= ave been numerous attempts over the years. Generally speaking, attribute met= adata systems look great on paper but are incredibly complicated for RP=E2=80= =99s to implement. When we wrote VoT, we directly decided to take a differen= t approach, something between the granularity of attributes and the single-s= cale of LOA. 

This l= evel of granularity is very, very useful in the real world, otherwise we wou= ldn=E2=80=99t have dozens of international trust frameworks based around the= concept of proofing an individual and tying that account to a set of proofe= d attributes. There isn=E2=80=99t an easy way to express something complex a= s =E2=80=9CWe=E2=80=99re sure this is Justin but aren=E2=80=99t sure about h= is medical degree=E2=80=9D in any VoT implementation that I=E2=80=99ve seen t= o date, and especially not in the example values given in the spec itself. B= ut if you really wanted to, you could have something like:

 - P3: High level of confidence= in individual=E2=80=99s name, address, phone, eye color, and shoe size
 - Pm: In person verification of a medical degree by m= aking the claimant perform surgery on the verifier.
So if you wanted to express that, you coul= d say =E2=80=9CP3.Pm=E2=80=9D or just =E2=80=9CP3=E2=80=9D if you weren=E2=80= =99t so sure about that medical degree. However, like I described above, I d= on=E2=80=99t think this is a good solution for that as you=E2=80=99d need to= get really specific with each attribute. If you really need that level of e= xpressiveness, you=E2=80=99ll want a different solution and VoT doesn=E2=80=99= t work for you. However, just because it doesn=E2=80=99t solve this use case= doesn=E2=80=99t mean it=E2=80=99s not useful in many others. VoT is a tool f= it for a purpose that we tried to express in the intro text, it fits in betw= een attribute metadata and single scalar measurements. And in fact, you coul= d use it side by side in the same system, and I see no conflict in this.

Don=E2=80=99t deny th= e world a hammer just because you think you need a screwdriver.

 =E2=80=94 Justin

On Sep 13, 2017, at 1:01 PM, Phil Hunt <phil.hunt@oracle.com> wrote:<= /div>
Section 3.1

Does 3.1 apply to the identif= ier issued, to the whole assertion? 

An Identity is usually an identifier and a set of cl= aims.

So what abou= t claims?   Some claims may be issued by a provider (and thus are P3) w= hile others may be provided as self asserted by the subject.  Some, as i= n banking may have involved a physical documents or other mechanism and thus= all claims are not equal.

I have trouble determining the affect of P0-P3 and worry that privi= lege escalation will occur since not all claims are equal.  There isn=E2= =80=99t really a way to say =E2=80=9CWe=E2=80=99re confident this is Justin,= we=E2=80=99re just not so sure about his medical degree=E2=80=9D.

Consider a university knows= student numbers and degrees and courses completed. Is it authoritative over= nationality, residence, addresses?  Maybe. Maybe not.

Consider a social network. In many c= ases they can be considered authoritative over the social network identity (= P3) but know nothing about most users.

<= /div>
I=E2=80=99m just not sure identity proofing as expresse= d is actually useful.

Phil

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

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



= --Apple-Mail-E6173B20-2A40-4207-9B4F-A1CEA8602490-- From nobody Wed Sep 13 17:57:04 2017 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 8C5E0132F70 for ; Wed, 13 Sep 2017 17:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jz70_SoXrn1o for ; Wed, 13 Sep 2017 17:56:59 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (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 EDD2C132F69 for ; Wed, 13 Sep 2017 17:56:58 -0700 (PDT) X-AuditID: 12074423-b03ff70000006fff-2d-59b9d3d89610 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id C0.1D.28671.8D3D9B95; Wed, 13 Sep 2017 20:56:56 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id v8E0uu6M028581; Wed, 13 Sep 2017 20:56:56 -0400 Received: from [IPv6:2607:fb90:68b1:ef2a:394e:9fea:dca5:8432] ([172.58.217.68]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v8E0urJr010507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 13 Sep 2017 20:56:55 -0400 Message-Id: <201709140056.v8E0urJr010507@outgoing.mit.edu> Date: Wed, 13 Sep 2017 20:56:50 -0400 Importance: normal From: Justin Richer To: "Phil Hunt (IDM)" Cc: vot@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_1360276214889210" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCKsWRmVeSWpSXmKPExsUixG6nonvj8s5Ig9sLLSwWzG9kt2j4+YDV gcljyZKfTB4fn95iCWCK4rJJSc3JLEst0rdL4Mr4fuUWS8Gi98wVtxZOZW1g3PCIuYuRk0NC wERi2b1T7CC2kMBiJom5W1i6GLmA7I2MEmvW/GWHcM4wSUz6v4cFpIpXwEri0topYB0sAqoS rZdng9nCAnYSB+f8Yexi5ODgFBCS6NolARJmAyqZvqaFCcQWEdCRWHDvLlg5s4CAxNxD05gg RgpKnJz5hAUiHivx/elm9gmMvLOQpGYhSUHY6hJ/5l1ihrAVJaZ0PwSKcwDZahLLWpWQhRcw sq1ilE3JrdLNTczMKU5N1i1OTszLSy3SNdPLzSzRS00p3cQIDlQX5R2ML/u8DzEKcDAq8fA+ sNwZKcSaWFZcmXuIUZKDSUmUd68uUIgvKT+lMiOxOCO+qDQntfgQowQHs5IIr9J6oBxvSmJl VWpRPkxKmoNFSZxXXKMxQkggPbEkNTs1tSC1CCYrw8GhJMG74RJQo2BRanpqRVpmTglCmomD E2Q4D9Bwicsgw4sLEnOLM9Mh8qcYIzlOPLz9h4ljxs27QHIDmNwHJp9cm/eXSYglLz8vVUqc twRkgQBIc0ZpHtx8JSEhATX23xMyNr7XsvSb/+rO0hYjUOJaY3XT5RWjODAIhHnPgHTyAJMe 3NZXQAcxAR105vQOkINKEhFSUg2MvOcfb9vDcKNjb8G7P8xHt3wPSxZPf8o163fr1rk2bFXJ t5QX36x/seQyuxdL4Im5AiEmylqizqGbzzEx7Xj9NdQ5JCLeurohtJEtyMqmvWJRxJ1dr3qm blhj9lEuZrVO+Nn/DF2yp/7fEb6/P/eP3vvjW7e+ueu83utymc7nM3HL/eUSwn+8VWIpzkg0 1GIuKk4EAB4pTCE3AwAA Archived-At: Subject: Re: [VoT] VoT Identity Proofing and individual claims X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Sep 2017 00:57:02 -0000 ----_com.samsung.android.email_1360276214889210 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SSBjb21wbGV0ZWx5IGRpc2FncmVlIHdpdGggdGhhdCBzdGF0ZW1lbnQuIExpa2UgSSd2ZSBzYWlk IHNldmVyYWwgdGltZXMsIHRoZSB0cnVzdCBmcmFtZXdvcmtzIHRoYXQgZGVmaW5lIHRoZSB2ZWN0 b3IgY29tcG9uZW50cyB3aWxsIGRvIHRoYXQgcGFydCwgbGlrZSB0aGUgTklTVCBkb2N1bWVudCBk b2VzIGFscmVhZHkuIEkgdW5kZXJzdGFuZCB3aGF0IHlvdSdyZSBzYXlpbmc6IHlvdSBjYW4ndCB0 YWtlIGEgYnVuZGxlIG9mIGF0dHJpYnV0ZXMgYW5kIGp1c3QgYXNzdW1lIHRoZXkncmUgYWxsIGVx dWFsbHkgdmFsaWQsIHdpdGhvdXQgYW55IG90aGVyIGNvbnRleHQuIEkgYWdyZWUgd2l0aCB0aGlz LiBIb3dldmVyLCBpdCdzIG5vdCB0aGUgZ29hbCBvZiBWb1QgdG8gY29tbXVuaWNhdGUgdGhhdCBn cmFudWxhcml0eSBvZiBpbmZvcm1hdGlvbiB3aXRoaW4gdGhlIHZlY3RvciwgYW5kIGluIGZhY3Qg ZG9pbmcgc28gd2FzIGFuIGV4cGxpY2l0IGFudGktZ29hbC4gVGhpcyB3YXMgYnJvdWdodCB1cCB5 ZWFycyBhZ28gd2hlbiBJIGZpcnN0IHByb3Bvc2VkIHRoaXMsIGFuZCBpdCdzIGluIHRoZSBsaXN0 IGFyY2hpdmVzLsKgCkZ1cnRoZXJtb3JlOiBXZSBkb24ndCBsZWF2ZSBwcm9vZmluZyB1bmRlZmlu ZWQgZW50aXJlbHksIGFzIHlvdSBjbGFpbSwgaXQncyBqdXN0IGRlZmluZWQgYnkgYSBkaWZmZXJl bnQgcGllY2UgdGhhdCBzbG90cyBpbnRvIHRoaXMgdG8gbWFrZSBhIHdhbGwgd29ya2luZyBzeXN0 ZW0uIEZvciBOSVNULCB0aGlzIGlzIDgwMC02M0EuIFRoZW4gODAwLTYzRCBkZWZpbmVzIHZlY3Rv ciBjb21wb25lbnQgdmFsdWVzIHRoYXQgcmVmZXJlbmNlIHRoYXQgZnJhbWV3b3JrLCBhbmQgdGhp cyBWb1QgZHJhZnQgZGVmaW5lcyBob3cgdGhvc2UgZ28gdG9nZXRoZXIgYW5kIGdldCBleHByZXNz ZWQgaW4gdGhlIGF1dGhlbnRpY2F0aW9uIHByb3RvY29sLsKgCllvdSBjYW4gdXNlIFZvVCB3aXRo b3V0IHRoZSBOSVNUIGZyYW1ld29yaywgeW91IGNvdWxkIGV2ZW4gdXNlIGl0IHdpdGhvdXQgcHJv b2ZpbmcgdmFsdWVzIGF0IGFsbC4gSXQncyBhIG1lY2hhbmlzbSBmb3IgY29udmV5aW5nIHRoaXMg aW5mb3JtYXRpb24uIElmIHRoZXJlJ3MgYSB3YXkgdG8gYmV0dGVyIHN0YXRlIHRoaXMsIHBsZWFz ZSBzdWdnZXN0IHRleHQgdGhhdCBoZWxwcyBjb252ZXkgdGhhdCB3ZSdyZSBub3QgY292ZXJpbmcg dGhhdCBoZXJlIGluIFZvVC7CoArCoElmIGluc3RlYWQgeW91J3JlIGNvbmNlcm5lZCB3aXRoIGhv dyB0aGUgdmVjdG9yIGNvbXBvbmVudHMgYXJlIGludGVycHJldGVkLCB0aGVuIHRoYXQncyBub3Qg cmVhbGx5IGFwcHJvcHJpYXRlIHRvIGJlIGNvdmVyZWQgaGVyZS4gUmF0aGVyLCBpdCdzIGEgY29t bWVudCBmb3IgdGhlIGRvY3VtZW50IHRoYXQgZGVmaW5lcyB0aGVtLiBJIHdvdWxkIHN1Z2dlc3Qg c3RhcnRpbmcgd2l0aCB0aGUgTklTVCBkb2N1bWVudCwgd2hpY2ggaXMgZ29pbmcgdG8gYmUgb25l IG9mIHRoZSBmaXJzdCBvbmVzIGluIHVzZSBieSBpR292IGltcGxlbWVudGF0aW9ucyAod2hpY2gg c3RhcnRlZCB0aGlzIHdob2xlIGRpc2N1c3Npb24pLsKgCi0tSnVzdGluCsKgU2VudCBmcm9tIG15 IHBob25lCi0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS1Gcm9tOiAiUGhpbCBIdW50 IChJRE0pIiA8cGhpbC5odW50QG9yYWNsZS5jb20+IERhdGU6IDkvMTMvMTcgIDU6MzIgUE0gIChH TVQtMDU6MDApIFRvOiBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU+IENjOiB2b3RAaWV0 Zi5vcmcgU3ViamVjdDogUmU6IFtWb1RdIFZvVCBJZGVudGl0eSBQcm9vZmluZyBhbmQgaW5kaXZp ZHVhbCBjbGFpbXMgCkkgYW0gc2F5aW5nIHlvdSBjYW5ub3QgYW5kIG11c3Qgbm90IHNvbHZlIHRo ZSBwcm9ibGVtIHlvdSBhcmUgc29sdmluZyB3aXRob3V0IGRlYWxpbmcgd2l0aCB0aGUgaW5kaXZp ZHVhbCBjbGFpbXMgYW5kIGhvdyB0aGV5IGNvbWJpbmUgdG8gZm9ybSBhbiBvdmVyYWxsIHByb29m LgpMZWF2aW5nIHByb29maW5nIHVuZGVmaW5lZCBtb3ZlcyB0byBhIHNpdHVhdGlvbiB3b3JzZSB0 aGFuIGRlcGVuZGluZyBvbiBMZXZlbCBvZiBhdXRoZW50aWNhdGlvbiBhbG9uZS7CoApQaGlsCk9u IFNlcCAxMywgMjAxNywgYXQgMTo1OSBQTSwgSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1 PiB3cm90ZToKClBoaWwsIHJlc3BvbnNlcyBpbmxpbmUuCgpPbiBTZXAgMTMsIDIwMTcsIGF0IDM6 MDkgUE0sIFBoaWwgSHVudCA8cGhpbC5odW50QG9yYWNsZS5jb20+IHdyb3RlOgoKSnVzdGluLApJ IGRvbuKAmXQgYmVsaWV2ZSBtYWtpbmcgdGhpbmdzIGFyYml0cmFyaWx5IG91dCBvZiBzY29wZSBo ZWxwcyBzaW1wbGlmeS4gwqBJbiB0aGlzIGNhc2UsIEkgYmVsaWV2ZSBpdCBjb21wbGljYXRlcyBt YXR0ZXJzLgoKSSBkb27igJl0IHVuZGVyc3RhbmQgeW91ciBhcmd1bWVudC4gV2XigJlyZSBzb2x2 aW5nIG9uZSBwcm9ibGVtLCBidXQgbm90IHRoZSBwcm9ibGVtIHlvdeKAmXJlIHRyeWluZyB0byBz b2x2ZS4gSXQgZmVlbHMgY29tcGxpY2F0ZWQgYmVjYXVzZSB5b3XigJlyZSB0cnlpbmcgdG8gdXNl IGEgdG9vbCB0aGF04oCZcyBub3QgZml0IGZvciB0aGUgcHJvYmxlbSB5b3XigJlyZSBwcmVzZW50 aW5nLiBUaGF0IGRvZXNu4oCZdCBtZWFuIHRoYXQgaXTigJlzIGNvbXBsaWNhdGVkIGZvciB0aGUg cHJvYmxlbSB0aGUgdG9vbCBpcyBkZXNpZ25lZCBmb3IuIEtlZXBpbmcgb3RoZXIgdGhpbmdzIG91 dCBvZiBzY29wZSBpcyBleGFjdGx5IG1ha2luZyB0aGlzIGEgdHJhY3RhYmxlIHByb2JsZW0gd2l0 aGluIHBhcnRpY3VsYXIgYm91bmRhcmllcy4gVGhpcyBkZWNpc2lvbiBvZiBzY29wZSBmb3IgdGhp cyB3b3JrIGlzIGhhcmRseSBhcmJpdHJhcnkgb3IgaWxsLWluZm9ybWVkLCBzbyBkaXNtaXNzaW5n IGl0IGFzIHN1Y2ggaXMgYm90aCBtaXN1bmRlcnN0YW5kaW5nIHRoZSB3b3JrIGFuZCBub3QgaGVs cGZ1bCBpbiB0aGUgY29udmVyc2F0aW9uLsKgCkZpcnN0bHksIG1pc3NpbmcgZnJvbSB0aGUgc3Bl Y+KApi5hIGRlZmluaXRpb24gb2YgSWRlbnRpdHkuCldlIGRpZG7igJl0IHRyeSB0byBkZWZpbmUg 4oCcaWRlbnRpdHnigJ0gYXMgYSB0ZXJtIGJlY2F1c2UgdGhlcmUgaXMgbm8gb25lIHNpbmdsZSBh Z3JlZWQtdXBvbiBkZWZpbml0aW9uIG9mIGlkZW50aXR5LCBhbmQgeWV0IGl0IGlzIHVuZGVyc3Rv b2QgYnJvYWRseSBhcyBhIGNvbmNlcHQgZW5vdWdoIHRvIG1ha2UgaWRlbnRpdHkgc3lzdGVtcyB3 b3JrLCBpc27igJl0IGl0PyBXZSBkbyBoYXZlIGEgZGlzY3Vzc2lvbiBvZiBvdXIgaWRlbnRpdHkg bW9kZWwgYXQgcGxheSBpbiBzZWN0aW9uIDEuMiB0aG91Z2guIEnigJltIGFzc3VtaW5nIHlvdeKA mXZlIHJlYWQgdGhhdCwgc28gcGxlYXNlIHN1Ym1pdCB0ZXh0IHRoYXQgd291bGQgaW1wcm92ZSB0 aGF0IHNlY3Rpb24uCgoyLjEuICBJZGVudGl0eSBQcm9vZmluZwoKICAgVGhlIElkZW50aXR5IFBy b29maW5nIGRpbWVuc2lvbiBkZWZpbmVzLCBvdmVyYWxsLCBob3cgc3Ryb25nbHkgdGhlCiAgIHNl dCBvZiBpZGVudGl0eSBhdHRyaWJ1dGVzIGhhdmUgYmVlbiB2ZXJpZmllZCBhbmQgdmV0dGVkLiAg SW4gb3RoZXIKICAgd29yZHMsIHRoaXMgZGltZW5zaW9uIGRlc2NyaWJlcyBob3cgbGlrZWx5IGl0 IGlzIHRoYXQgYSBnaXZlbiBkaWdpdGFsCiAgIGlkZW50aXR5IHRyYW5zYWN0aW9uIGNvcnJlc3Bv bmRzIHRvIGEgcGFydGljdWxhciAocmVhbC13b3JsZCkKICAgaWRlbnRpdHkgc3ViamVjdC4KCiAg IFRoaXMgZGltZW5zaW9uIFNIQUxMIGJlIHJlcHJlc2VudGVkIGJ5IHRoZSAiUCIgZGVtYXJjYXRv ciBhbmQgYQogICBzaW5nbGUtY2hhcmFjdGVyIGxldmVsIHZhbHVlLCBzdWNoIGFzICJQMCIsICJQ MSIsIGV0Yy4gIE1vc3QKICAgZGVmaW5pdGlvbnMgb2YgaWRlbnRpdHkgcHJvb2Zpbmcgd2lsbCBo YXZlIGEgbmF0dXJhbCBvcmRlcmluZywgYXMKICAgbW9yZSBvciBsZXNzIHN0cmluZ2VudCBwcm9v ZmluZyBjYW4gYmUgYXBwbGllZCB0byBhbiBpbmRpdmlkdWFsLiAgSW4KICAgc3VjaCBjYXNlcyBp dCBpcyBSRUNPTU1FTkRFRCB0aGF0IGEgZGlnaXQgc3R5bGUgdmFsdWUgYmUgdXNlZCBmb3IKICAg dGhpcyBjb21wb25lbnQuCldoYXQgaXMgbWVhbnQgYnkgb3ZlcmFsbD8gwqBJcyBpdCBhbiBhdmVy YWdlPyDCoFRoZSBsb3dlc3QgdmFsdWUgb2YgYWxsIG9mIHRoZSBhdHRyaWJ1dGVzIChjbGFpbXMp PwoKQWdhaW4sIHRoYXQgZGVwZW5kcyBvbiB0aGUgc3BlY2lmaWMgdHJ1c3QgZnJhbWV3b3JrIHRo YXQgZGVmaW5lcyB3aGF0IHRoZSB2YWx1ZXMgbWVhbi4gRm9yIE5JU1QsIGZvciBleGFtcGxlLCB0 aGVyZSBhcmUgYmFzZWxpbmUgcHJvb2ZpbmdzIHJlcXVpcmVkIGZvciBhbGwgbWVudGlvbmVkIGF0 dHJpYnV0ZXMgYXQgYSBnaXZlbiBJQUwuIElmIHlvdSBkb27igJl0IG1lZXQgdGhhdCBsZXZlbCBm b3IgYWxsIG9mIHRob3NlIGF0dHJpYnV0ZXMsIHRoZW4geW91IGRvbuKAmXQgbWVldCB0aGF0IElB TC4gT3RoZXIgZnJhbWV3b3JrcyBjb3VsZCBwcm92aWRlIHNvbWV0aGluZyBlbHNlLCBidXQgSeKA mXZlIHlldCB0byBzZWUgYSBkaWZmZXJlbnQgYXBwcm9hY2guIERvIHlvdSBrbm93IG9mIGEgdHJ1 c3QgZnJhbWV3b3JrIHRoYXQgZGVmaW5lcyBhbiDigJxhdmVyYWdl4oCdIHByb29maW5nIGxldmVs IGZvciBhIHVzZXLigJlzIGF0dHJpYnV0ZXM/wqAKQWxzbyBpbnRlcmVzdGluZyB0byBub3RlOiBp ZiB5b3XigJlyZSBwcm92aWRpbmcgYWRkaXRpb25hbCBhdHRyaWJ1dGVzIHRoYXQgYXJlbuKAmXQg bGlzdGVkIGluIHRoZSBmcmFtZXdvcmssIGxpa2Ug4oCcaGFzIGEgbWVkaWNhbCBkZWdyZWXigJ0s IHRoZW4geW914oCZcmUgb24geW91ciBvd24gYXMgdGhlIGZyYW1ld29yayBkb2VzbuKAmXQgYWRk cmVzcyB0aG9zZS4gSWYgeW91IG5lZWQgdG8gYWRkcmVzcyB0aG9zZSBzZXBhcmF0ZWx5LCB5b3Xi gJlsbCBuZWVkIGEgZnJhbWV3b3JrIChhbmQgdmVjdG9yIGRlZmluaXRpb25zKSB0aGF0IGNvdmVy IHRob3NlLsKgCkFuZCBpZiB5b3Ugd2FudCB0byBoYXZlIGRpZmZlcmVudCBzZXRzIG9mIGluZm9y bWF0aW9uIGZvciBlYWNoIGF0dHJpYnV0ZSwgdGhlbiB5b3XigJlsbCB3YW50IGEgZGlmZmVyZW50 IHNvbHV0aW9uIHRoYXTigJlzIG5vdCBWb1QuCldoYXQgaXMgbWVhbnQgYnkgYSByZWFsIHdvcmxk IGlkZW50aXR5IHN1YmplY3Q/IMKgRG8geW91IG1lYW4gYSBsZWdhbCBwZXJzb24/IMKgRG8geW91 IG1lYW4gYSBkZXZpY2UvdGhpbmc/ClN1cmUsIHRob3NlIHdvdWxkIGFsbCB3b3JrLiBBbGwgZGVw ZW5kcyBvbiB3aGF0IHRoZSBJZFAgaXMgcHJvdmlkaW5nIGlkZW50aXR5IGFzc2VydGlvbnMgZm9y LiBXZeKAmXJlIG5vdCBnb2luZyB0byBhcnRpZmljaWFsbHkgbGltaXQgdGhhdCwgdGhvdWdoIHdl IGRvIGhhdmUgImEgcGVyc29uIHVzaW5nIGEgY29tcHV0ZXIgc3lzdGVt4oCdIGdlbmVyYWxseSBp biBtaW5kLiBBZ2Fpbiwgc2VlIHNlY3Rpb24gMS4yIGZvciBtb3JlIGRldGFpbHMgb24gdGhhdCBt b2RlbC7CoAoKQW4gb3ZlcmFsbCBsZXZlbCBvZiBjb25maWRlbmNlIGluIGhvdyBzdHJvbmdseSBh IHRyYW5zYWN0aW9uIGNvcnJlc3BvbmRzIHRvIGEgcGFydGljdWxhciBpZGVudGl0eSBzdWJqZWN0 IHNvdW5kcyBhbiBhd2Z1bCBsb3QgbGlrZSBhdXRoZW50aWNhdGlvbiBjb25maWRlbmNlLgpBbiBv dmVyYWxsIGNvbmZpZGVuY2Ugd291bGQgYmUgdGhhdCwgYnV0IHRoaXMgaXNu4oCZdCB3aGF0IHdl 4oCZcmUgc2F5aW5nOiBpdOKAmXMgaG93IG11Y2ggdGhlIGF0dHJpYnV0ZXMgYXJlIHRpZWQgdG8g YSByZWFsIHBlcnNvbi4gSG93IHN0cm9uZ2x5IHRoYXQgZ2V0cyB0aWVkIHRvIHRoZSB0cmFuc2Fj dGlvbiBpcyBzdWJqZWN0IHRvIHRoZSBvdGhlciB2ZWN0b3IgY29tcG9uZW50cywgc3VjaCBhcyBh dXRoZW50aWNhdGlvbiBjcmVkZW50aWFscyBhbmQgYXNzZXJ0aW9ucy4gVGhhdOKAmXMgdGhlIHdo b2xlIHJlYXNvbiBvZiBzcGxpdHRpbmcgaXQgb3V0IHNlcGFyYXRlbHkuIFNvIHllcywgaXTigJlz IG5vdCBhcyBncmFudWxhciBhcyBpbmRpdmlkdWFsIGF0dHJpYnV0ZXMsIHdoaWNoIHlvdeKAmXJl IGFza2luZyBhYm91dCBiZWxvdywgYnV0IGl04oCZcyBtb3JlIGdyYW51bGFyIHRoYW4gYSBzaW5n bGUgbGV2ZWwgb2YgY29uZmlkZW5jZSB0aGF0IHlvdSBoYXZlIHN0YXRlZCBoZXJlLiBJdOKAmXMg aW4gYmV0d2VlbiwgbGlrZSB3ZSBzYXkgaW4gdGhlIGludHJvZHVjdGlvbi7CoAoKSSBjYW4gc2Vl IGhvdyB5b3UgbWlnaHQgYXJyaXZlIGF0IHRoaXMgZGVmaW5pdGlvbiBsb29raW5nIGFuIGFuIGlu dGVybmFsIGRhdGEgc3lzdGVtIGxpa2UgYSBwYXlyb2xsIHN5c3RlbS4gWW91IGNhbiBhc3Nlc3Mg dGhlIHByb2NlZHVyZXMgYW5kIGVzdGFibGlzaCBhbiBvdmVyYWxsIGNvbmZpZGVuY2UgbGV2ZWwg aW4gdGhlIHF1YWxpdHkgb2YgZGF0YS4gwqBCdXQgYXMgc29vbiBhcyB5b3Ugd2FudCB0byBzaGFy ZSB0aGF0IHBheXJvbGwgZGF0YSB3aXRoIG90aGVyIHN5c3RlbXMuIMKgCkkgYmVnYW4gbXkgZXhw ZXJpZW5jZSBpbiBJZGVudGl0eSBtYW5hZ2VtZW50IGJ1aWxkaW5nIGxhcmdlIHNjYWxlIG1ldGEt ZGlyZWN0b3JpZXMuIFdlIG9uY2UgYXNzdW1lZCBidXNpbmVzcyBzeXN0ZW1zIGxpa2UgcGF5cm9s bCBzeXN0ZW1zIHdlcmUgYXV0aG9yaXRhdGl2ZSBvdmVyIHRoaW5ncyBsaWtlIGVtcGxveWVlIGFk ZHJlc3Nlcy4gwqBUdXJucyBvdXQgd2Ugd2VyZSB3cm9uZy4gwqBQYXlyb2xsIGRvZXNu4oCZdCBj YXJlIGFib3V0IGFkZHJlc3NlcywgdGhleSBjYXJlIGFib3V0IGJhbmsgYWNjb3VudCBkZXBvc2l0 IG51bWJlcnMuIMKgClRoZW4sIGJ5IHlvdXIgdHJ1c3QgZnJhbWV3b3JrIGFuZCBjb250ZXh0LCB5 b3Ugd291bGRu4oCZdCBhc2sgcGF5cm9sbCBmb3IgYWRkcmVzc2VzLCByaWdodD8gU28gaWYgeW91 ciB0cnVzdCBmcmFtZXdvcmsgcmVxdWlyZXMgeW91IHRvIHZlcmlmeSB0aGUgYWRkcmVzcyBhdCwg c2F5LCBQMywgYnV0IHlvdSBkb27igJl0IGRvIHRoYXQsIHRoZW4geW914oCZcmUgbm90IGRvaW5n IFAzIGZvciB0aG9zZS4gQW5kIGlmIHlvdSBuZWVkIHRvIHNwbGl0IG91dCBjbGFzc2VzIG9mIHVz ZXJzIHdoZXJlIHlvdeKAmXZlIGdvdCDigJxhdXRob3JpdGF0aXZlIGJhbmsgYWNjb3VudCBudW1i ZXJz4oCdIGFuZCDigJxhdXRob3JpdGF0aXZlIGJhbmsgYWNjb3VudCBudW1iZXJzIEFORCBhZGRy ZXNzZXPigJ0sIHRoZW4geW91IGRlZmluZSB0d28gZGlmZmVyZW50IGNhdGVnb3JpZXMgdG8gcmVw cmVzZW50IHRob3NlIGNsYXNzZXMgb2YgdXNlcnMuIElmIHlvdSB3YW50IGEgc3lzdGVtIHRoYXQg Y2FuIGRlc2NyaWJlIHRoZSBhc3N1cmFuY2Ugb2YgYW4gYXJiaXRyYXJ5IGF0dHJpYnV0ZSBmb3Ig YSBnaXZlbiB0cmFuc2FjdGlvbiwgdGhlbiBWb1QgZG9lc27igJl0IHdvcmsgZm9yIHlvdS4gR28g ZmluZCBhIHNjcmV3ZHJpdmVyIGFuZCBzdG9wIHRyeWluZyB0byBmaWd1cmUgb3V0IHdoeSB0aGlz IGhhbW1lciBkb2VzbuKAmXQgd29yayBmb3IgeW91LgoKQ29uY2x1c2lvbjogwqBKdXN0IGJlY2F1 c2UgdGhlIHBheXJvbGwgZGVwYXJ0bWVudCBoYXMgYSBoaWdoIGxldmVsIG9mIGNvbmZpZGVuY2Ug aW4gdGhlIGF0dHJpYnV0ZXMgdGhleSBoYXZlICppbnRlcm5hbGx5KiwgaXQgZG9lcyBub3QgbWVh biB0aGVyZSBpcyBoaWdoIGNvbmZpZGVuY2UgZm9yIHNlY29uZGFyeSB1c2VzLiDCoElmIHlvdSBh c2sgcGF5cm9sbCBhYm91dCBzaGFyaW5nIGRhdGEsIHRoZXkgbWlnaHQgb25seSBzaGFyZSBlbXBs b3llZSBudW1iZXIsIHNhbGFyeSwgYW5kIGJhbmsgYWNjb3VudHMgYXMgYmVpbmcgYWNjdXJhdGUg KGFzc3VtaW5nIHRoZXJlIHdhcyBhIHZhbGlkIHJlYXNvbiB0byBzaGFyZSkuIMKgU2hvdWxkIGFu IElEUCBiYXNlZCBvbiBwYXlyb2xsIG9ubHkgYXNzZXJ0IGhpZ2ggbGV2ZWwgZGF0YT8gwqBDYW4g dGhleSBhc3NlcnQgbG93LWxldmVsIGRhdGEgZm9yIHRoZSBwdXJwb3NlIG9mIGNvcnJlbGF0aW9u L2NvbmZpcm1hdGlvbj8KQW5vdGhlciBjYXNlLCBsb29rIGF0IEZhY2Vib29rIGFuZCBUd2l0dGVy LiBUaGV5IGhhdmUgdmFyaWFibGUgYXNzZXJ0aW9ucyBhcyB3ZWxsLiDCoFNvbWUgdXNlcnMgYXJl IHZlcmlmaWVkIGFuZCBzb21lIGFyZSBub3QuIMKgV2hhdCBkb2VzIHRoYXQgbWVhbj8gSG93IHdv dWxkIFZvVCBoZWxwIGluIHRoaXMgY2FzZT8gwqBXb3VsZCBpdCBtZWFuIHRoYXQgdGhlIG91dCBv ZiBzY29wZSBpbmZvcm1hdGlvbiBpbiB0aGUgbmFtZSBjbGFpbSBpcyBkZWVtZWQgYWNjdXJhdGU/ IMKgQXJlIHdlIHRhbGtpbmcgYWJvdXQgdGhlIHNhbWUgTWljaGFlbCBEb3VnbGFzIG9yIGFyZSB3 ZSB0YWxraW5nIGFib3V0IE1pY2hhZWwgS2VhdG9uIChNaWNoYWVsIEtlYXRvbuKAmXMgcmVhbCBu YW1lIGlzIE1pY2hhZWwgRG91Z2xhcykuClZvVCB3b3VsZCBoZWxwIGluIGV4YWN0bHkgdGhpcyBj YXNlIGJ5IGJlaW5nIGFibGUgdG8gYXNzZXJ0IGRpZmZlcmVudCBwcm9vZmluZyBiYXNlZCBvbiBk aWZmZXJlbnQgYWNjb3VudHMuIEJ1dCBpdCBhbGwgY29tZXMgZG93biB0byB3aGF0IHlvdSB0cnVz dCB0aGUgSWRQIHRvIGFzc2VydCBnaXZlbiBpdHMgdHJ1c3QgZnJhbWV3b3JrIGNvbnRleHQg4oCU IGlmIHRoZXkgYWdyZWVkIHRvIHByb29mIHRoZSBuYW1lLCBhbmQgdGhleSBzYXkgdGhleSBkaWQs IGFuZCB5b3UgdHJ1c3QgdGhlbSB0byBtYWtlIHRoYXQgY2xhaW0sIHdlbGwgdGhlbiB5b3XigJly ZSBhbGwgc2V0LiBJZiB0aGV5IGRvbuKAmXQgYWdyZWUgdG8gdGhhdCAoYXMgaW4gaXTigJlzIG5v dCBzdGlwdWxhdGVkIGluIHRoZSB0cnVzdCBhZ3JlZW1lbnRzKSAsIG9yIHRoZXkgYWdyZWVkIHRv IGl0IGFuZCBsaWVkIGFib3V0IGl0LCBvciB0aGV5IGRpZCBpdCBidXQgeW91IGRvbuKAmXQgdHJ1 c3QgdGhlbSB0byBzYXkgaXQg4oCmIHRoZW4gSSBjYW7igJl0IHJlYWxseSBoZWxwIHlvdSB3aXRo IHRoaXMuwqAKSW4gdGhlIGVuZCwgVm9UIGlzIGFsbCBhYm91dCBvbmUgc2ltcGxlIHRoaW5nOiBj b252ZXlpbmcgYnVuZGxlcyBvZiBpbmZvcm1hdGlvbiBhYm91dCBtb3N0bHktb3J0aG9nb25hbCBh c3BlY3RzIG9mIGFuIGlkZW50aXR5IHRyYW5zYWN0aW9uLiBJdOKAmXMgYWJvdXQgYW4gSWRQIHRl bGxpbmcgYW4gUlA6IOKAnEkgZGlkIHRoZSBmb2xsb3dpbmcgdGhpbmdzIGZyb20gYSBsaXN0IG9m IHRoaW5ncyB0aGF0IHdlIGFncmVlZCB1cG9u4oCdLiBKdXN0IGxpa2Ugc2F5aW5nIOKAnExPQTPi gJ0gaW4gdGhlIFVTIEdvdmVybm1lbnQgY29udGV4dCBtZWFudCBzb21ldGhpbmcgcHJldHR5IHNw ZWNpZmljLCBzYXlpbmcg4oCcUDIuQ2MuQWLigJ0gYWxzbyBtZWFucyBzb21ldGhpbmcgc3BlY2lm aWMgaW4gdGhhdCBraW5kIG9mIGNvbnRleHQuIEJ1dCBzYXlpbmcg4oCcTE9BM+KAnSBpbiBDYW5h ZGEgbWVhbnMgc29tZXRoaW5nIGEgbGl0dGxlIGJpdCBkaWZmZXJlbnQsIGFuZCBzYXlpbmcg4oCc TE9BM+KAnSBlbHNld2hlcmUgY291bGQgYmUgY29tcGxldGVseSB1bnJlbGF0ZWQgdG8gZWl0aGVy IGNhc2UuIEluIGFsbCBvZiB0aGVzZSwgYm90aCB0aGUgTG9BIGFuZCBWb1QgdmVyc2lvbnMsIGlu dGVycHJldGF0aW9uIG9mIHRoZSByZXN1bHQgdG8gYSBwYXJ0aWN1bGFyIHJlYWwtd29ybGQgbWVh bmluZyBpcyBvdXRzaWRlIHRoZSBjb252ZXlhbmNlIHByb3RvY29sIG9yIGVuY29kaW5nLiBUaGVy ZeKAmXMgYSBtYXNzaXZlIGFtb3VudCBvZiBjb250ZXh0IHRoYXQgaXMgdGFrZW4gaW50byBhY2Nv dW50LCBhbmQgdGhhdCBjb250ZXh0IHdpbGwgdGVsbCB5b3UgaWYgeW91IGNhbiB0cnVzdCB0aGUg bmFtZSBvciB0aGUgYWRkcmVzcyBvciBhbnl0aGluZyBlbHNlIHdoZW4geW91IGdldCBhIHBhcnRp Y3VsYXIgdmFsdWUuCllvdeKAmXJlIHRyeWluZyB0byBmaXQgaXQgaW50byBzb21ldGhpbmcgaXTi gJlzIG5vdCBtZWFudCBmb3IgYW5kIG5vdCBnb29kIGF0LCBhbmQgYXNraW5nIHdoeSBpdCBkb2Vz buKAmXQgd29yazsgdG8gbWUsIGl04oCZcyBubyBzdXJwcmlzZSB0aGF0IGl0IGRvZXNu4oCZdCB3 b3JrIGZvciB0aGF0LiBWb1QgZG9lcyBub3QgZG8gd2hhdCB5b3XigJlyZSBkZXNjcmliaW5nLCBh bmQgdGhhdOKAmXMgYnkgZGVzaWduLiBUaGF0IHBhcnQgaXMgc3BlbGxlZCBvdXQgaW4gdGhlIGlu dHJvZHVjdGlvbi4gT24gdGhlIHNhbWUgdG9rZW4sIHlvdXIgbGF3bm1vd2VyIG1ha2VzIGEgcHJl dHR5IGJhZCB0b290aGJydXNoLiBCdXQgbGlrZSBJIGtlZXAgcmVpdGVyYXRpbmc6IGlmIHlvdSBo YXZlIGEgZGlmZmVyZW50IHByb2JsZW0sIHVzZSBhIGRpZmZlcmVudCB0b29sLsKgSSBhbSBwZXJm ZWN0bHkgaGFwcHkgd2l0aCB0aGlzIHRlY2hub2xvZ3kgbm90IGJlaW5nIGEgc2lsdmVyIGJ1bGxl dCBvciBwYW5hY2VhIG9yIHdoYXQgaGF2ZSB5b3UuIFRoZXJlIGFyZSBhIGxvdCBvZiBwZW9wbGUg d2hvIHNlZW0gdG8gaGF2ZSB0aGUgcHJvYmxlbSB0aGF0IHRoaXMgdG9vbCBzb2x2ZXMsIHNvIHdl 4oCZcmUgZ29pbmcgdG8ga2VlcCBnb2luZyB3aXRoIHNvbHZpbmcgdGhvc2UgcHJvYmxlbXMuIEkg bG9vayBmb3J3YXJkIHRvIHNlZWluZyB5b3VyIHNvbHV0aW9ucyBmb3IgYXR0cmlidXRlIHRydXN0 IGFuZCBtZXRhZGF0YSBpbiB0aGUgZnV0dXJlLgpUaGFua3MswqDigJQgSnVzdGluCgoKUGhpbApP cmFjbGUgQ29ycG9yYXRpb24sIElkZW50aXR5IENsb3VkIFNlcnZpY2VzIEFyY2hpdGVjdEBpbmRl cGVuZGVudGlkd3d3LmluZGVwZW5kZW50aWQuY29tcGhpbC5odW50QG9yYWNsZS5jb20KCgpPbiBT ZXAgMTMsIDIwMTcsIGF0IDEwOjU3IEFNLCBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU+ IHdyb3RlOgpJdCBhcHBsaWVzIHRvIHRoZSBJZFDigJlzIGp1ZGdlbWVudCBhY3Jvc3MgdGhlIGVu dGlyZSBhc3NlcnRpb24uIEhvdyB0aGF04oCZcyBjYWxjdWxhdGVkIHdoZW4gdGhlIHRydXN0IGlu IGRpZmZlcmVudCBhdHRyaWJ1dGVzIGRpZmZlcnMgd2lsbCB2YXJ5IGRlcGVuZGluZyBvbiB0aGUg SWRQLCBhbmQgcHJvYmFibHkgZGVmaW5lZCBieSBydWxlcyB3aXRoaW4gdGhlIHRydXN0IGZyYW1l d29yayB0aGF0IGRlZmluZXMgdGhlIHZlY3RvciB2YWx1ZXMgdGhlbXNlbHZlcy4gTklTVCA4MDAt NjMtMyB2b2x1bWUgQSwgZm9yIGV4YW1wbGUsIGlzIHZlcnkgY2xlYXIgYWJvdXQgaG93IHRvIGhh bmRsZSBhbGwgdGhlIGF0dHJpYnV0ZXMgY29sbGVjdGVkIGF0IGRpZmZlcmVudCBsZXZlbHMuIElm IHlvdSB3ZXJlIHVzaW5nIE5JU1TigJlzIGVuY29kaW5nIG9mIFZvVCwgc3BlY2lmaWVkIGluIHRo ZSB1cGNvbWluZyB2b2x1bWUgRCBvZiB0aGF0IGRvY3VtZW50LCB0aGVuIHlvdeKAmWQgYmUgYm91 bmQgYnkgdGhvc2UgcnVsZXMgYXMgYW4gSWRQLiBBIHVuaXZlcnNpdHkgZ3JvdXAsIGxpa2UgeW91 4oCZcmUgdGFsa2luZyBhYm91dCBiZWxvdywgbWlnaHQgaGF2ZSBkaWZmZXJlbnQgcnVsZXMgdW5k ZXIgaXRzIG93biB0cnVzdCBmcmFtZXdvcmsgYW5kIHZlY3RvciBjb21wb25lbnQgZGVmaW5pdGlv bnMuCkl0IGxvb2tzIGxpa2UgeW91IG1pZ2h0IGJlIGFza2luZyBpZiB0aGlzIGlzIGFib3V0IHBl ci1hdHRyaWJ1dGUgbWV0YWRhdGEuIElmIHlvdSByZWFkIHRoZSBpbnRyb2R1Y3Rpb24sIHdlIGV4 cGxpY2l0bHkgc3RhdGUgdGhhdCB3ZeKAmXJlIG5vdCB0cnlpbmcgdG8gc29sdmUgcGVyLWF0dHJp YnV0ZSBtZXRhZGF0YS4gSWYgeW914oCZZCBsaWtlIHRoYXQga2luZCBvZiBkYXRhLCB5b3XigJly ZSBsb29raW5nIGZvciBhIGRpZmZlcmVudCBraW5kIG9mIHNvbHV0aW9uLCBvZiB3aGljaCB0aGVy ZSBoYXZlIGJlZW4gbnVtZXJvdXMgYXR0ZW1wdHMgb3ZlciB0aGUgeWVhcnMuIEdlbmVyYWxseSBz cGVha2luZywgYXR0cmlidXRlIG1ldGFkYXRhIHN5c3RlbXMgbG9vayBncmVhdCBvbiBwYXBlciBi dXQgYXJlIGluY3JlZGlibHkgY29tcGxpY2F0ZWQgZm9yIFJQ4oCZcyB0byBpbXBsZW1lbnQuIFdo ZW4gd2Ugd3JvdGUgVm9ULCB3ZSBkaXJlY3RseSBkZWNpZGVkIHRvIHRha2UgYSBkaWZmZXJlbnQg YXBwcm9hY2gsIHNvbWV0aGluZyBiZXR3ZWVuIHRoZSBncmFudWxhcml0eSBvZiBhdHRyaWJ1dGVz IGFuZCB0aGUgc2luZ2xlLXNjYWxlIG9mIExPQS7CoApUaGlzIGxldmVsIG9mIGdyYW51bGFyaXR5 IGlzIHZlcnksIHZlcnkgdXNlZnVsIGluIHRoZSByZWFsIHdvcmxkLCBvdGhlcndpc2Ugd2Ugd291 bGRu4oCZdCBoYXZlIGRvemVucyBvZiBpbnRlcm5hdGlvbmFsIHRydXN0IGZyYW1ld29ya3MgYmFz ZWQgYXJvdW5kIHRoZSBjb25jZXB0IG9mIHByb29maW5nIGFuIGluZGl2aWR1YWwgYW5kIHR5aW5n IHRoYXQgYWNjb3VudCB0byBhIHNldCBvZiBwcm9vZmVkIGF0dHJpYnV0ZXMuIFRoZXJlIGlzbuKA mXQgYW4gZWFzeSB3YXkgdG8gZXhwcmVzcyBzb21ldGhpbmcgY29tcGxleCBhcyDigJxXZeKAmXJl IHN1cmUgdGhpcyBpcyBKdXN0aW4gYnV0IGFyZW7igJl0IHN1cmUgYWJvdXQgaGlzIG1lZGljYWwg ZGVncmVl4oCdIGluIGFueSBWb1QgaW1wbGVtZW50YXRpb24gdGhhdCBJ4oCZdmUgc2VlbiB0byBk YXRlLCBhbmQgZXNwZWNpYWxseSBub3QgaW4gdGhlIGV4YW1wbGUgdmFsdWVzIGdpdmVuIGluIHRo ZSBzcGVjIGl0c2VsZi4gQnV0IGlmIHlvdSByZWFsbHkgd2FudGVkIHRvLCB5b3UgY291bGQgaGF2 ZSBzb21ldGhpbmcgbGlrZToKwqAtIFAzOiBIaWdoIGxldmVsIG9mIGNvbmZpZGVuY2UgaW4gaW5k aXZpZHVhbOKAmXMgbmFtZSwgYWRkcmVzcywgcGhvbmUsIGV5ZSBjb2xvciwgYW5kIHNob2Ugc2l6 ZcKgLSBQbTogSW4gcGVyc29uIHZlcmlmaWNhdGlvbiBvZiBhIG1lZGljYWwgZGVncmVlIGJ5IG1h a2luZyB0aGUgY2xhaW1hbnQgcGVyZm9ybSBzdXJnZXJ5IG9uIHRoZSB2ZXJpZmllci4KU28gaWYg eW91IHdhbnRlZCB0byBleHByZXNzIHRoYXQsIHlvdSBjb3VsZCBzYXkg4oCcUDMuUG3igJ0gb3Ig anVzdCDigJxQM+KAnSBpZiB5b3Ugd2VyZW7igJl0IHNvIHN1cmUgYWJvdXQgdGhhdCBtZWRpY2Fs IGRlZ3JlZS4gSG93ZXZlciwgbGlrZSBJIGRlc2NyaWJlZCBhYm92ZSwgSSBkb27igJl0IHRoaW5r IHRoaXMgaXMgYSBnb29kIHNvbHV0aW9uIGZvciB0aGF0IGFzIHlvdeKAmWQgbmVlZCB0byBnZXQg cmVhbGx5IHNwZWNpZmljIHdpdGggZWFjaCBhdHRyaWJ1dGUuIElmIHlvdSByZWFsbHkgbmVlZCB0 aGF0IGxldmVsIG9mIGV4cHJlc3NpdmVuZXNzLCB5b3XigJlsbCB3YW50IGEgZGlmZmVyZW50IHNv bHV0aW9uIGFuZCBWb1QgZG9lc27igJl0IHdvcmsgZm9yIHlvdS4gSG93ZXZlciwganVzdCBiZWNh dXNlIGl0IGRvZXNu4oCZdCBzb2x2ZSB0aGlzIHVzZSBjYXNlIGRvZXNu4oCZdCBtZWFuIGl04oCZ cyBub3QgdXNlZnVsIGluIG1hbnkgb3RoZXJzLiBWb1QgaXMgYSB0b29sIGZpdCBmb3IgYSBwdXJw b3NlIHRoYXQgd2UgdHJpZWQgdG8gZXhwcmVzcyBpbiB0aGUgaW50cm8gdGV4dCwgaXQgZml0cyBp biBiZXR3ZWVuIGF0dHJpYnV0ZSBtZXRhZGF0YSBhbmQgc2luZ2xlIHNjYWxhciBtZWFzdXJlbWVu dHMuIEFuZCBpbiBmYWN0LCB5b3UgY291bGQgdXNlIGl0IHNpZGUgYnkgc2lkZSBpbiB0aGUgc2Ft ZSBzeXN0ZW0sIGFuZCBJIHNlZSBubyBjb25mbGljdCBpbiB0aGlzLgpEb27igJl0IGRlbnkgdGhl IHdvcmxkIGEgaGFtbWVyIGp1c3QgYmVjYXVzZSB5b3UgdGhpbmsgeW91IG5lZWQgYSBzY3Jld2Ry aXZlci4KwqDigJQgSnVzdGluCk9uIFNlcCAxMywgMjAxNywgYXQgMTowMSBQTSwgUGhpbCBIdW50 IDxwaGlsLmh1bnRAb3JhY2xlLmNvbT4gd3JvdGU6CgpTZWN0aW9uIDMuMQpEb2VzIDMuMSBhcHBs eSB0byB0aGUgaWRlbnRpZmllciBpc3N1ZWQsIHRvIHRoZSB3aG9sZSBhc3NlcnRpb24/wqAKQW4g SWRlbnRpdHkgaXMgdXN1YWxseSBhbiBpZGVudGlmaWVyIGFuZCBhIHNldCBvZiBjbGFpbXMuClNv IHdoYXQgYWJvdXQgY2xhaW1zPyDCoCBTb21lIGNsYWltcyBtYXkgYmUgaXNzdWVkIGJ5IGEgcHJv dmlkZXIgKGFuZCB0aHVzIGFyZSBQMykgd2hpbGUgb3RoZXJzIG1heSBiZSBwcm92aWRlZCBhcyBz ZWxmIGFzc2VydGVkIGJ5IHRoZSBzdWJqZWN0LiDCoFNvbWUsIGFzIGluIGJhbmtpbmcgbWF5IGhh dmUgaW52b2x2ZWQgYSBwaHlzaWNhbCBkb2N1bWVudHMgb3Igb3RoZXIgbWVjaGFuaXNtIGFuZCB0 aHVzIGFsbCBjbGFpbXMgYXJlIG5vdCBlcXVhbC4KSSBoYXZlIHRyb3VibGUgZGV0ZXJtaW5pbmcg dGhlIGFmZmVjdCBvZiBQMC1QMyBhbmQgd29ycnkgdGhhdCBwcml2aWxlZ2UgZXNjYWxhdGlvbiB3 aWxsIG9jY3VyIHNpbmNlIG5vdCBhbGwgY2xhaW1zIGFyZSBlcXVhbC4gwqBUaGVyZSBpc27igJl0 IHJlYWxseSBhIHdheSB0byBzYXkg4oCcV2XigJlyZSBjb25maWRlbnQgdGhpcyBpcyBKdXN0aW4s IHdl4oCZcmUganVzdCBub3Qgc28gc3VyZSBhYm91dCBoaXMgbWVkaWNhbCBkZWdyZWXigJ0uCkNv bnNpZGVyIGEgdW5pdmVyc2l0eSBrbm93cyBzdHVkZW50IG51bWJlcnMgYW5kIGRlZ3JlZXMgYW5k IGNvdXJzZXMgY29tcGxldGVkLiBJcyBpdCBhdXRob3JpdGF0aXZlIG92ZXIgbmF0aW9uYWxpdHks IHJlc2lkZW5jZSwgYWRkcmVzc2VzPyDCoE1heWJlLiBNYXliZSBub3QuCkNvbnNpZGVyIGEgc29j aWFsIG5ldHdvcmsuIEluIG1hbnkgY2FzZXMgdGhleSBjYW4gYmUgY29uc2lkZXJlZCBhdXRob3Jp dGF0aXZlIG92ZXIgdGhlIHNvY2lhbCBuZXR3b3JrIGlkZW50aXR5IChQMykgYnV0IGtub3cgbm90 aGluZyBhYm91dCBtb3N0IHVzZXJzLgpJ4oCZbSBqdXN0IG5vdCBzdXJlIGlkZW50aXR5IHByb29m aW5nIGFzIGV4cHJlc3NlZCBpcyBhY3R1YWxseSB1c2VmdWwuCgpQaGlsCk9yYWNsZSBDb3Jwb3Jh dGlvbiwgSWRlbnRpdHkgQ2xvdWQgU2VydmljZXMgQXJjaGl0ZWN0QGluZGVwZW5kZW50aWR3d3cu aW5kZXBlbmRlbnRpZC5jb21waGlsLmh1bnRAb3JhY2xlLmNvbQoKCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCnZvdCBtYWlsaW5nIGxpc3QKdm90QGlldGYu b3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdm90CgoKCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCnZvdCBtYWlsaW5nIGxpc3QK dm90QGlldGYub3JnCmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1o dHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fdm90JmQ9RHdJQ0FnJmM9Um9Q MVl1bUNYQ2dhV0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZyPUpCbTViaVJyS3VnQ0gw RmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJR2smbT1ZQTJKZEJPWU0zU1F4XzFmdjA4OGo1Q3lo ZnZUbW5Oa0t6TEVNc1hnYVdnJnM9UWFKZGxOcldQRGlWQ1VxajFKeEg0N1BzWXJLbENLN3lfY1pH aU1RMF9tWSZlPSAK ----_com.samsung.android.email_1360276214889210 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT48ZGl2PkkgY29tcGxldGVseSBkaXNh Z3JlZSB3aXRoIHRoYXQgc3RhdGVtZW50LiBMaWtlIEkndmUgc2FpZCBzZXZlcmFsIHRpbWVzLCB0 aGUgdHJ1c3QgZnJhbWV3b3JrcyB0aGF0IGRlZmluZSB0aGUgdmVjdG9yIGNvbXBvbmVudHMgd2ls bCBkbyB0aGF0IHBhcnQsIGxpa2UgdGhlIE5JU1QgZG9jdW1lbnQgZG9lcyBhbHJlYWR5LiBJIHVu ZGVyc3RhbmQgd2hhdCB5b3UncmUgc2F5aW5nOiB5b3UgY2FuJ3QgdGFrZSBhIGJ1bmRsZSBvZiBh dHRyaWJ1dGVzIGFuZCBqdXN0IGFzc3VtZSB0aGV5J3JlIGFsbCBlcXVhbGx5IHZhbGlkLCB3aXRo b3V0IGFueSBvdGhlciBjb250ZXh0LiBJIGFncmVlIHdpdGggdGhpcy4gSG93ZXZlciwgaXQncyBu b3QgdGhlIGdvYWwgb2YgVm9UIHRvIGNvbW11bmljYXRlIHRoYXQgZ3JhbnVsYXJpdHkgb2YgaW5m b3JtYXRpb24gd2l0aGluIHRoZSB2ZWN0b3IsIGFuZCBpbiBmYWN0IGRvaW5nIHNvIHdhcyBhbiBl eHBsaWNpdCBhbnRpLWdvYWwuIFRoaXMgd2FzIGJyb3VnaHQgdXAgeWVhcnMgYWdvIHdoZW4gSSBm aXJzdCBwcm9wb3NlZCB0aGlzLCBhbmQgaXQncyBpbiB0aGUgbGlzdCBhcmNoaXZlcy4mbmJzcDs8 L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PkZ1cnRoZXJtb3JlOiBXZSBkb24ndCBsZWF2ZSBwcm9v ZmluZyB1bmRlZmluZWQgZW50aXJlbHksIGFzIHlvdSBjbGFpbSwgaXQncyBqdXN0IGRlZmluZWQg YnkgYSBkaWZmZXJlbnQgcGllY2UgdGhhdCBzbG90cyBpbnRvIHRoaXMgdG8gbWFrZSBhIHdhbGwg d29ya2luZyBzeXN0ZW0uIEZvciBOSVNULCB0aGlzIGlzIDgwMC02M0EuIFRoZW4gODAwLTYzRCBk ZWZpbmVzIHZlY3RvciBjb21wb25lbnQgdmFsdWVzIHRoYXQgcmVmZXJlbmNlIHRoYXQgZnJhbWV3 b3JrLCBhbmQgdGhpcyBWb1QgZHJhZnQgZGVmaW5lcyBob3cgdGhvc2UgZ28gdG9nZXRoZXIgYW5k IGdldCBleHByZXNzZWQgaW4gdGhlIGF1dGhlbnRpY2F0aW9uIHByb3RvY29sLiZuYnNwOzwvZGl2 PjxkaXY+PGJyPjwvZGl2PjxkaXY+WW91IGNhbiB1c2UgVm9UIHdpdGhvdXQgdGhlIE5JU1QgZnJh bWV3b3JrLCB5b3UgY291bGQgZXZlbiB1c2UgaXQgd2l0aG91dCBwcm9vZmluZyB2YWx1ZXMgYXQg YWxsLiBJdCdzIGEgbWVjaGFuaXNtIGZvciBjb252ZXlpbmcgdGhpcyBpbmZvcm1hdGlvbi4gSWYg dGhlcmUncyBhIHdheSB0byBiZXR0ZXIgc3RhdGUgdGhpcywgcGxlYXNlIHN1Z2dlc3QgdGV4dCB0 aGF0IGhlbHBzIGNvbnZleSB0aGF0IHdlJ3JlIG5vdCBjb3ZlcmluZyB0aGF0IGhlcmUgaW4gVm9U LiZuYnNwOzwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+Jm5ic3A7SWYgaW5zdGVhZCB5b3UncmUg Y29uY2VybmVkIHdpdGggaG93IHRoZSB2ZWN0b3IgY29tcG9uZW50cyBhcmUgaW50ZXJwcmV0ZWQs IHRoZW4gdGhhdCdzIG5vdCByZWFsbHkgYXBwcm9wcmlhdGUgdG8gYmUgY292ZXJlZCBoZXJlLiBS YXRoZXIsIGl0J3MgYSBjb21tZW50IGZvciB0aGUgZG9jdW1lbnQgdGhhdCBkZWZpbmVzIHRoZW0u IEkgd291bGQgc3VnZ2VzdCBzdGFydGluZyB3aXRoIHRoZSBOSVNUIGRvY3VtZW50LCB3aGljaCBp cyBnb2luZyB0byBiZSBvbmUgb2YgdGhlIGZpcnN0IG9uZXMgaW4gdXNlIGJ5IGlHb3YgaW1wbGVt ZW50YXRpb25zICh3aGljaCBzdGFydGVkIHRoaXMgd2hvbGUgZGlzY3Vzc2lvbikuJm5ic3A7PC9k aXY+PGRpdj48YnI+PC9kaXY+PGRpdiBpZD0iY29tcG9zZXJfc2lnbmF0dXJlIj48bWV0YSBodHRw LWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1VVEYtOCI+ PGRpdiBzdHlsZT0iZm9udC1zaXplOjg1JTtjb2xvcjojNTc1NzU3Ij4tLUp1c3RpbjwvZGl2Pjxk aXYgc3R5bGU9ImZvbnQtc2l6ZTo4NSU7Y29sb3I6IzU3NTc1NyI+PGJyPjwvZGl2PjxkaXYgc3R5 bGU9ImZvbnQtc2l6ZTo4NSU7Y29sb3I6IzU3NTc1NyI+Jm5ic3A7PGk+U2VudCBmcm9tIG15IHBo b25lPC9pPjwvZGl2PjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTox MDAlO2NvbG9yOiMwMDAwMDAiPjwhLS0gb3JpZ2luYWxNZXNzYWdlIC0tPjxkaXY+LS0tLS0tLS0g T3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLTwvZGl2PjxkaXY+RnJvbTogIlBoaWwgSHVudCAoSURN KSIgJmx0O3BoaWwuaHVudEBvcmFjbGUuY29tJmd0OyA8L2Rpdj48ZGl2PkRhdGU6IDkvMTMvMTcg IDU6MzIgUE0gIChHTVQtMDU6MDApIDwvZGl2PjxkaXY+VG86IEp1c3RpbiBSaWNoZXIgJmx0O2py aWNoZXJAbWl0LmVkdSZndDsgPC9kaXY+PGRpdj5DYzogdm90QGlldGYub3JnIDwvZGl2PjxkaXY+ U3ViamVjdDogUmU6IFtWb1RdIFZvVCBJZGVudGl0eSBQcm9vZmluZyBhbmQgaW5kaXZpZHVhbCBj bGFpbXMgPC9kaXY+PGRpdj48YnI+PC9kaXY+PC9kaXY+PGRpdj5JIGFtIHNheWluZyB5b3UgY2Fu bm90IGFuZCBtdXN0IG5vdCBzb2x2ZSB0aGUgcHJvYmxlbSB5b3UgYXJlIHNvbHZpbmcgd2l0aG91 dCBkZWFsaW5nIHdpdGggdGhlIGluZGl2aWR1YWwgY2xhaW1zIGFuZCBob3cgdGhleSBjb21iaW5l IHRvIGZvcm0gYW4gb3ZlcmFsbCBwcm9vZi48L2Rpdj48ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1 cmUiPjxicj48L2Rpdj48ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPkxlYXZpbmcgcHJvb2Zp bmcgdW5kZWZpbmVkIG1vdmVzIHRvIGEgc2l0dWF0aW9uIHdvcnNlIHRoYW4gZGVwZW5kaW5nIG9u IExldmVsIG9mIGF1dGhlbnRpY2F0aW9uIGFsb25lLiZuYnNwOzwvZGl2PjxkaXYgaWQ9IkFwcGxl TWFpbFNpZ25hdHVyZSI+PGJyPlBoaWw8L2Rpdj48ZGl2Pjxicj5PbiBTZXAgMTMsIDIwMTcsIGF0 IDE6NTkgUE0sIEp1c3RpbiBSaWNoZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqcmljaGVyQG1pdC5l ZHUiPmpyaWNoZXJAbWl0LmVkdTwvYT4mZ3Q7IHdyb3RlOjxicj48YnI+PC9kaXY+PGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSI+PGRpdj48ZGl2IGNsYXNzPSIiPlBoaWwsIHJlc3BvbnNlcyBpbmxpbmUu PC9kaXY+PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+PC9kaXY+PGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+PGRpdj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj48ZGl2IGNsYXNz PSIiPk9uIFNlcCAxMywgMjAxNywgYXQgMzowOSBQTSwgUGhpbCBIdW50ICZsdDs8YSBocmVmPSJt YWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIGNsYXNzPSIiPnBoaWwuaHVudEBvcmFjbGUuY29t PC9hPiZndDsgd3JvdGU6PC9kaXY+PGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5l Ij48ZGl2IGNsYXNzPSIiPgo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJr aXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFj ZTsiIGNsYXNzPSIiPjxkaXYgY2xhc3M9IiI+SnVzdGluLDwvZGl2PjxkaXYgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPjwvZGl2PjxkaXYgY2xhc3M9IiI+SSBkb27igJl0IGJlbGlldmUgbWFraW5nIHRo aW5ncyBhcmJpdHJhcmlseSBvdXQgb2Ygc2NvcGUgaGVscHMgc2ltcGxpZnkuICZuYnNwO0luIHRo aXMgY2FzZSwgSSBiZWxpZXZlIGl0IGNvbXBsaWNhdGVzIG1hdHRlcnMuPC9kaXY+PGRpdiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+PC9kaXY+PC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjxkaXY+PGJy IGNsYXNzPSIiPjwvZGl2PjxkaXY+SSBkb27igJl0IHVuZGVyc3RhbmQgeW91ciBhcmd1bWVudC4g V2XigJlyZSBzb2x2aW5nIG9uZSBwcm9ibGVtLCBidXQgbm90IHRoZSBwcm9ibGVtIHlvdeKAmXJl IHRyeWluZyB0byBzb2x2ZS4gSXQgZmVlbHMgY29tcGxpY2F0ZWQgYmVjYXVzZSB5b3XigJlyZSB0 cnlpbmcgdG8gdXNlIGEgdG9vbCB0aGF04oCZcyBub3QgZml0IGZvciB0aGUgcHJvYmxlbSB5b3Xi gJlyZSBwcmVzZW50aW5nLiBUaGF0IGRvZXNu4oCZdCBtZWFuIHRoYXQgaXTigJlzIGNvbXBsaWNh dGVkIGZvciB0aGUgcHJvYmxlbSB0aGUgdG9vbCBpcyBkZXNpZ25lZCBmb3IuIEtlZXBpbmcgb3Ro ZXIgdGhpbmdzIG91dCBvZiBzY29wZSBpcyBleGFjdGx5IG1ha2luZyB0aGlzIGEgdHJhY3RhYmxl IHByb2JsZW0gd2l0aGluIHBhcnRpY3VsYXIgYm91bmRhcmllcy4gVGhpcyBkZWNpc2lvbiBvZiBz Y29wZSBmb3IgdGhpcyB3b3JrIGlzIGhhcmRseSBhcmJpdHJhcnkgb3IgaWxsLWluZm9ybWVkLCBz byBkaXNtaXNzaW5nIGl0IGFzIHN1Y2ggaXMgYm90aCBtaXN1bmRlcnN0YW5kaW5nIHRoZSB3b3Jr IGFuZCBub3QgaGVscGZ1bCBpbiB0aGUgY29udmVyc2F0aW9uLiZuYnNwOzwvZGl2PjxiciBjbGFz cz0iIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj48ZGl2IGNsYXNzPSIiPjxkaXYg c3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAt d2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+PGRpdiBjbGFz cz0iIj5GaXJzdGx5LCBtaXNzaW5nIGZyb20gdGhlIHNwZWPigKYuYSBkZWZpbml0aW9uIG9mIElk ZW50aXR5LjwvZGl2PjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48ZGl2PjxiciBjbGFzcz0iIj48 L2Rpdj48ZGl2PldlIGRpZG7igJl0IHRyeSB0byBkZWZpbmUg4oCcaWRlbnRpdHnigJ0gYXMgYSB0 ZXJtIGJlY2F1c2UgdGhlcmUgaXMgbm8gb25lIHNpbmdsZSBhZ3JlZWQtdXBvbiBkZWZpbml0aW9u IG9mIGlkZW50aXR5LCBhbmQgeWV0IGl0IGlzIHVuZGVyc3Rvb2QgYnJvYWRseSBhcyBhIGNvbmNl cHQgZW5vdWdoIHRvIG1ha2UgaWRlbnRpdHkgc3lzdGVtcyB3b3JrLCBpc27igJl0IGl0PyBXZSBk byBoYXZlIGEgZGlzY3Vzc2lvbiBvZiBvdXIgaWRlbnRpdHkgbW9kZWwgYXQgcGxheSBpbiBzZWN0 aW9uIDEuMiB0aG91Z2guIEnigJltIGFzc3VtaW5nIHlvdeKAmXZlIHJlYWQgdGhhdCwgc28gcGxl YXNlIHN1Ym1pdCB0ZXh0IHRoYXQgd291bGQgaW1wcm92ZSB0aGF0IHNlY3Rpb24uPC9kaXY+PGJy IGNsYXNzPSIiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPjxkaXYgY2xhc3M9IiI+ PGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3Bh Y2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj48ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj48L2Rpdj48ZGl2IGNsYXNzPSIiPjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiIGNsYXNzPSIiPjxwcmUgY2xhc3M9Im5ld3BhZ2UiIHN0eWxlPSJmb250LXNpemU6 IDEzLjMzMzMzMzAxNTQ0MTg5NXB4OyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBw eDsgYnJlYWstYmVmb3JlOiBwYWdlOyI+PHNwYW4gY2xhc3M9ImgzIiBzdHlsZT0ibGluZS1oZWln aHQ6IDBwdDsgZGlzcGxheTogaW5saW5lOyBmb250LXNpemU6IDFlbTsgZm9udC13ZWlnaHQ6IGJv bGQ7Ij48aDMgc3R5bGU9ImxpbmUtaGVpZ2h0OiAwcHQ7IGRpc3BsYXk6IGlubGluZTsgZm9udC1z aXplOiAxZW07IiBjbGFzcz0iIj48YSBjbGFzcz0ic2VsZmxpbmsiIG5hbWU9InNlY3Rpb24tMi4x IiBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMt M0FfX3Rvb2xzLmlldGYub3JnX2h0bWxfZHJhZnQtMkRyaWNoZXItMkR2ZWN0b3JzLTJEb2YtMkR0 cnVzdC0yRDA1LTIzc2VjdGlvbi0yRDIuMSZhbXA7ZD1Ed01GYVEmYW1wO2M9Um9QMVl1bUNYQ2dh V0h2bFpZUjhQUWN4QktDWDVZVHBrS1kwNTdTYksxMCZhbXA7cj1KQm01YmlSckt1Z0NIMEZrSVRT ZUdKeFBFaXZ6ald3bE5LZTRDX2xMSUdrJmFtcDttPVlBMkpkQk9ZTTNTUXhfMWZ2MDg4ajVDeWhm dlRtbk5rS3pMRU1zWGdhV2cmYW1wO3M9bGwtWXFLUzBVamdwaU83VEtqODZwQ0FuRXVGQTJKaXlv aHJ3amJvWmZWTSZhbXA7ZT0iIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246IG5vbmU7Ij4yLjE8L2E+ LiAgSWRlbnRpdHkgUHJvb2Zpbmc8L2gzPjwvc3Bhbj4KCiAgIFRoZSBJZGVudGl0eSBQcm9vZmlu ZyBkaW1lbnNpb24gZGVmaW5lcywgb3ZlcmFsbCwgaG93IHN0cm9uZ2x5IHRoZQogICBzZXQgb2Yg aWRlbnRpdHkgYXR0cmlidXRlcyBoYXZlIGJlZW4gdmVyaWZpZWQgYW5kIHZldHRlZC4gIEluIG90 aGVyCiAgIHdvcmRzLCB0aGlzIGRpbWVuc2lvbiBkZXNjcmliZXMgaG93IGxpa2VseSBpdCBpcyB0 aGF0IGEgZ2l2ZW4gZGlnaXRhbAogICBpZGVudGl0eSB0cmFuc2FjdGlvbiBjb3JyZXNwb25kcyB0 byBhIHBhcnRpY3VsYXIgKHJlYWwtd29ybGQpCiAgIGlkZW50aXR5IHN1YmplY3QuCgogICBUaGlz IGRpbWVuc2lvbiBTSEFMTCBiZSByZXByZXNlbnRlZCBieSB0aGUgIlAiIGRlbWFyY2F0b3IgYW5k IGEKICAgc2luZ2xlLWNoYXJhY3RlciBsZXZlbCB2YWx1ZSwgc3VjaCBhcyAiUDAiLCAiUDEiLCBl dGMuICBNb3N0CiAgIGRlZmluaXRpb25zIG9mIGlkZW50aXR5IHByb29maW5nIHdpbGwgaGF2ZSBh IG5hdHVyYWwgb3JkZXJpbmcsIGFzCiAgIG1vcmUgb3IgbGVzcyBzdHJpbmdlbnQgcHJvb2Zpbmcg Y2FuIGJlIGFwcGxpZWQgdG8gYW4gaW5kaXZpZHVhbC4gIEluCiAgIHN1Y2ggY2FzZXMgaXQgaXMg UkVDT01NRU5ERUQgdGhhdCBhIGRpZ2l0IHN0eWxlIHZhbHVlIGJlIHVzZWQgZm9yCiAgIHRoaXMg Y29tcG9uZW50LjwvcHJlPjwvYmxvY2txdW90ZT48ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj48 L2Rpdj48L2Rpdj48ZGl2IGNsYXNzPSIiPldoYXQgaXMgbWVhbnQgYnkgb3ZlcmFsbD8gJm5ic3A7 SXMgaXQgYW4gYXZlcmFnZT8gJm5ic3A7VGhlIGxvd2VzdCB2YWx1ZSBvZiBhbGwgb2YgdGhlIGF0 dHJpYnV0ZXMgKGNsYWltcyk/PC9kaXY+PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+PC9kaXY+ PC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjxkaXY+PGJyIGNsYXNzPSIiPjwvZGl2PjxkaXY+QWdh aW4sIHRoYXQgZGVwZW5kcyBvbiB0aGUgc3BlY2lmaWMgdHJ1c3QgZnJhbWV3b3JrIHRoYXQgZGVm aW5lcyB3aGF0IHRoZSB2YWx1ZXMgbWVhbi4gRm9yIE5JU1QsIGZvciBleGFtcGxlLCB0aGVyZSBh cmUgYmFzZWxpbmUgcHJvb2ZpbmdzIHJlcXVpcmVkIGZvciBhbGwgbWVudGlvbmVkIGF0dHJpYnV0 ZXMgYXQgYSBnaXZlbiBJQUwuIElmIHlvdSBkb27igJl0IG1lZXQgdGhhdCBsZXZlbCBmb3IgPGIg Y2xhc3M9IiI+YWxsPC9iPiBvZiB0aG9zZSBhdHRyaWJ1dGVzLCB0aGVuIHlvdSBkb27igJl0IG1l ZXQgdGhhdCBJQUwuIE90aGVyIGZyYW1ld29ya3MgY291bGQgcHJvdmlkZSBzb21ldGhpbmcgZWxz ZSwgYnV0IEnigJl2ZSB5ZXQgdG8gc2VlIGEgZGlmZmVyZW50IGFwcHJvYWNoLiBEbyB5b3Uga25v dyBvZiBhIHRydXN0IGZyYW1ld29yayB0aGF0IGRlZmluZXMgYW4g4oCcYXZlcmFnZeKAnSBwcm9v ZmluZyBsZXZlbCBmb3IgYSB1c2Vy4oCZcyBhdHRyaWJ1dGVzPyZuYnNwOzwvZGl2PjxkaXY+PGJy IGNsYXNzPSIiPjwvZGl2PjxkaXY+QWxzbyBpbnRlcmVzdGluZyB0byBub3RlOiBpZiB5b3XigJly ZSBwcm92aWRpbmcgYWRkaXRpb25hbCBhdHRyaWJ1dGVzIHRoYXQgYXJlbuKAmXQgbGlzdGVkIGlu IHRoZSBmcmFtZXdvcmssIGxpa2Ug4oCcaGFzIGEgbWVkaWNhbCBkZWdyZWXigJ0sIHRoZW4geW91 4oCZcmUgb24geW91ciBvd24gYXMgdGhlIGZyYW1ld29yayBkb2VzbuKAmXQgYWRkcmVzcyB0aG9z ZS4gSWYgeW91IG5lZWQgdG8gYWRkcmVzcyB0aG9zZSBzZXBhcmF0ZWx5LCB5b3XigJlsbCBuZWVk IGEgZnJhbWV3b3JrIChhbmQgdmVjdG9yIGRlZmluaXRpb25zKSB0aGF0IGNvdmVyIHRob3NlLiZu YnNwOzwvZGl2PjxkaXY+PGJyIGNsYXNzPSIiPjwvZGl2PjxkaXY+QW5kIGlmIHlvdSB3YW50IHRv IGhhdmUgZGlmZmVyZW50IHNldHMgb2YgaW5mb3JtYXRpb24gZm9yIGVhY2ggYXR0cmlidXRlLCB0 aGVuIHlvdeKAmWxsIHdhbnQgYSBkaWZmZXJlbnQgc29sdXRpb24gdGhhdOKAmXMgbm90IFZvVC48 L2Rpdj48YnIgY2xhc3M9IiI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+PGRpdiBj bGFzcz0iIj48ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1t b2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNz PSIiPjxkaXYgY2xhc3M9IiI+V2hhdCBpcyBtZWFudCBieSBhIHJlYWwgd29ybGQgaWRlbnRpdHkg c3ViamVjdD8gJm5ic3A7RG8geW91IG1lYW4gYSBsZWdhbCBwZXJzb24/ICZuYnNwO0RvIHlvdSBt ZWFuIGEgZGV2aWNlL3RoaW5nPzwvZGl2PjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48ZGl2Pjxi ciBjbGFzcz0iIj48L2Rpdj48ZGl2PlN1cmUsIHRob3NlIHdvdWxkIGFsbCB3b3JrLiBBbGwgZGVw ZW5kcyBvbiB3aGF0IHRoZSBJZFAgaXMgcHJvdmlkaW5nIGlkZW50aXR5IGFzc2VydGlvbnMgZm9y LiBXZeKAmXJlIG5vdCBnb2luZyB0byBhcnRpZmljaWFsbHkgbGltaXQgdGhhdCwgdGhvdWdoIHdl IGRvIGhhdmUgImEgcGVyc29uIHVzaW5nIGEgY29tcHV0ZXIgc3lzdGVt4oCdIGdlbmVyYWxseSBp biBtaW5kLiBBZ2Fpbiwgc2VlIHNlY3Rpb24gMS4yIGZvciBtb3JlIGRldGFpbHMgb24gdGhhdCBt b2RlbC4mbmJzcDs8L2Rpdj48YnIgY2xhc3M9IiI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xh c3M9IiI+PGRpdiBjbGFzcz0iIj48ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13 ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1z cGFjZTsiIGNsYXNzPSIiPjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPjwvZGl2PjxkaXYgY2xh c3M9IiI+QW4gb3ZlcmFsbCBsZXZlbCBvZiBjb25maWRlbmNlIGluIGhvdyBzdHJvbmdseSBhIHRy YW5zYWN0aW9uIGNvcnJlc3BvbmRzIHRvIGEgcGFydGljdWxhciBpZGVudGl0eSBzdWJqZWN0IHNv dW5kcyBhbiBhd2Z1bCBsb3QgbGlrZSBhdXRoZW50aWNhdGlvbiBjb25maWRlbmNlLjwvZGl2Pjwv ZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48ZGl2PjxiciBjbGFzcz0iIj48L2Rpdj48ZGl2PkFuIG92 ZXJhbGwgY29uZmlkZW5jZSB3b3VsZCBiZSB0aGF0LCBidXQgdGhpcyBpc27igJl0IHdoYXQgd2Xi gJlyZSBzYXlpbmc6IGl04oCZcyBob3cgbXVjaCB0aGUgYXR0cmlidXRlcyBhcmUgdGllZCB0byBh IHJlYWwgcGVyc29uLiBIb3cgc3Ryb25nbHkgdGhhdCBnZXRzIHRpZWQgdG8gdGhlIHRyYW5zYWN0 aW9uIGlzIHN1YmplY3QgdG8gdGhlIG90aGVyIHZlY3RvciBjb21wb25lbnRzLCBzdWNoIGFzIGF1 dGhlbnRpY2F0aW9uIGNyZWRlbnRpYWxzIGFuZCBhc3NlcnRpb25zLiBUaGF04oCZcyB0aGUgd2hv bGUgcmVhc29uIG9mIHNwbGl0dGluZyBpdCBvdXQgc2VwYXJhdGVseS4gU28geWVzLCBpdOKAmXMg bm90IGFzIGdyYW51bGFyIGFzIGluZGl2aWR1YWwgYXR0cmlidXRlcywgd2hpY2ggeW914oCZcmUg YXNraW5nIGFib3V0IGJlbG93LCBidXQgaXTigJlzIG1vcmUgZ3JhbnVsYXIgdGhhbiBhIHNpbmds ZSBsZXZlbCBvZiBjb25maWRlbmNlIHRoYXQgeW91IGhhdmUgc3RhdGVkIGhlcmUuIEl04oCZcyBp biBiZXR3ZWVuLCBsaWtlIHdlIHNheSBpbiB0aGUgaW50cm9kdWN0aW9uLiZuYnNwOzwvZGl2Pjxi ciBjbGFzcz0iIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj48ZGl2IGNsYXNzPSIi PjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNw YWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+PGRp diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+PC9kaXY+PGRpdiBjbGFzcz0iIj5JIGNhbiBzZWUgaG93 IHlvdSBtaWdodCBhcnJpdmUgYXQgdGhpcyBkZWZpbml0aW9uIGxvb2tpbmcgYW4gYW4gaW50ZXJu YWwgZGF0YSBzeXN0ZW0gbGlrZSBhIHBheXJvbGwgc3lzdGVtLiBZb3UgY2FuIGFzc2VzcyB0aGUg cHJvY2VkdXJlcyBhbmQgZXN0YWJsaXNoIGFuIG92ZXJhbGwgY29uZmlkZW5jZSBsZXZlbCBpbiB0 aGUgcXVhbGl0eSBvZiBkYXRhLiAmbmJzcDtCdXQgYXMgc29vbiBhcyB5b3Ugd2FudCB0byBzaGFy ZSB0aGF0IHBheXJvbGwgZGF0YSB3aXRoIG90aGVyIHN5c3RlbXMuICZuYnNwOzwvZGl2PjxkaXYg Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPjwvZGl2PjxkaXYgY2xhc3M9IiI+SSBiZWdhbiBteSBleHBl cmllbmNlIGluIElkZW50aXR5IG1hbmFnZW1lbnQgYnVpbGRpbmcgbGFyZ2Ugc2NhbGUgbWV0YS1k aXJlY3Rvcmllcy4gV2Ugb25jZSBhc3N1bWVkIGJ1c2luZXNzIHN5c3RlbXMgbGlrZSBwYXlyb2xs IHN5c3RlbXMgd2VyZSBhdXRob3JpdGF0aXZlIG92ZXIgdGhpbmdzIGxpa2UgZW1wbG95ZWUgYWRk cmVzc2VzLiAmbmJzcDtUdXJucyBvdXQgd2Ugd2VyZSB3cm9uZy4gJm5ic3A7UGF5cm9sbCBkb2Vz buKAmXQgY2FyZSBhYm91dCBhZGRyZXNzZXMsIHRoZXkgY2FyZSBhYm91dCBiYW5rIGFjY291bnQg ZGVwb3NpdCBudW1iZXJzLiAmbmJzcDs8L2Rpdj48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PGRp dj48YnIgY2xhc3M9IiI+PC9kaXY+PGRpdj5UaGVuLCBieSB5b3VyIHRydXN0IGZyYW1ld29yayBh bmQgY29udGV4dCwgeW91IHdvdWxkbuKAmXQgYXNrIHBheXJvbGwgZm9yIGFkZHJlc3Nlcywgcmln aHQ/IFNvIGlmIHlvdXIgdHJ1c3QgZnJhbWV3b3JrIHJlcXVpcmVzIHlvdSB0byB2ZXJpZnkgdGhl IGFkZHJlc3MgYXQsIHNheSwgUDMsIGJ1dCB5b3UgZG9u4oCZdCBkbyB0aGF0LCB0aGVuIHlvdeKA mXJlIG5vdCBkb2luZyBQMyBmb3IgdGhvc2UuIEFuZCBpZiB5b3UgbmVlZCB0byBzcGxpdCBvdXQg Y2xhc3NlcyBvZiB1c2VycyB3aGVyZSB5b3XigJl2ZSBnb3Qg4oCcYXV0aG9yaXRhdGl2ZSBiYW5r IGFjY291bnQgbnVtYmVyc+KAnSBhbmQg4oCcYXV0aG9yaXRhdGl2ZSBiYW5rIGFjY291bnQgbnVt YmVycyBBTkQgYWRkcmVzc2Vz4oCdLCB0aGVuIHlvdSBkZWZpbmUgdHdvIGRpZmZlcmVudCBjYXRl Z29yaWVzIHRvIHJlcHJlc2VudCB0aG9zZSBjbGFzc2VzIG9mIHVzZXJzLiBJZiB5b3Ugd2FudCBh IHN5c3RlbSB0aGF0IGNhbiBkZXNjcmliZSB0aGUgYXNzdXJhbmNlIG9mIGFuIGFyYml0cmFyeSBh dHRyaWJ1dGUgZm9yIGEgZ2l2ZW4gdHJhbnNhY3Rpb24sIHRoZW4gVm9UIGRvZXNu4oCZdCB3b3Jr IGZvciB5b3UuIEdvIGZpbmQgYSBzY3Jld2RyaXZlciBhbmQgc3RvcCB0cnlpbmcgdG8gZmlndXJl IG91dCB3aHkgdGhpcyBoYW1tZXIgZG9lc27igJl0IHdvcmsgZm9yIHlvdS48L2Rpdj48YnIgY2xh c3M9IiI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+PGRpdiBjbGFzcz0iIj48ZGl2 IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsg LXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPjxkaXYgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPjwvZGl2PjxkaXYgY2xhc3M9IiI+Q29uY2x1c2lvbjogJm5ic3A7 SnVzdCBiZWNhdXNlIHRoZSBwYXlyb2xsIGRlcGFydG1lbnQgaGFzIGEgaGlnaCBsZXZlbCBvZiBj b25maWRlbmNlIGluIHRoZSBhdHRyaWJ1dGVzIHRoZXkgaGF2ZSAqaW50ZXJuYWxseSosIGl0IGRv ZXMgbm90IG1lYW4gdGhlcmUgaXMgaGlnaCBjb25maWRlbmNlIGZvciBzZWNvbmRhcnkgdXNlcy4g Jm5ic3A7SWYgeW91IGFzayBwYXlyb2xsIGFib3V0IHNoYXJpbmcgZGF0YSwgdGhleSBtaWdodCBv bmx5IHNoYXJlIGVtcGxveWVlIG51bWJlciwgc2FsYXJ5LCBhbmQgYmFuayBhY2NvdW50cyBhcyBi ZWluZyBhY2N1cmF0ZSAoYXNzdW1pbmcgdGhlcmUgd2FzIGEgdmFsaWQgcmVhc29uIHRvIHNoYXJl KS4gJm5ic3A7U2hvdWxkIGFuIElEUCBiYXNlZCBvbiBwYXlyb2xsIG9ubHkgYXNzZXJ0IGhpZ2gg bGV2ZWwgZGF0YT8gJm5ic3A7Q2FuIHRoZXkgYXNzZXJ0IGxvdy1sZXZlbCBkYXRhIGZvciB0aGUg cHVycG9zZSBvZiBjb3JyZWxhdGlvbi9jb25maXJtYXRpb24/PC9kaXY+PGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+PC9kaXY+PGRpdiBjbGFzcz0iIj5Bbm90aGVyIGNhc2UsIGxvb2sgYXQgRmFj ZWJvb2sgYW5kIFR3aXR0ZXIuIFRoZXkgaGF2ZSB2YXJpYWJsZSBhc3NlcnRpb25zIGFzIHdlbGwu ICZuYnNwO1NvbWUgdXNlcnMgYXJlIHZlcmlmaWVkIGFuZCBzb21lIGFyZSBub3QuICZuYnNwO1do YXQgZG9lcyB0aGF0IG1lYW4/IEhvdyB3b3VsZCBWb1QgaGVscCBpbiB0aGlzIGNhc2U/ICZuYnNw O1dvdWxkIGl0IG1lYW4gdGhhdCB0aGUgb3V0IG9mIHNjb3BlIGluZm9ybWF0aW9uIGluIHRoZSBu YW1lIGNsYWltIGlzIGRlZW1lZCBhY2N1cmF0ZT8gJm5ic3A7QXJlIHdlIHRhbGtpbmcgYWJvdXQg dGhlIHNhbWUgTWljaGFlbCBEb3VnbGFzIG9yIGFyZSB3ZSB0YWxraW5nIGFib3V0IE1pY2hhZWwg S2VhdG9uIChNaWNoYWVsIEtlYXRvbuKAmXMgcmVhbCBuYW1lIGlzIE1pY2hhZWwgRG91Z2xhcyku PC9kaXY+PC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjxkaXY+PGJyIGNsYXNzPSIiPjwvZGl2Pjxk aXY+Vm9UIHdvdWxkIGhlbHAgaW4gZXhhY3RseSB0aGlzIGNhc2UgYnkgYmVpbmcgYWJsZSB0byBh c3NlcnQgZGlmZmVyZW50IHByb29maW5nIGJhc2VkIG9uIGRpZmZlcmVudCBhY2NvdW50cy4gQnV0 IGl0IGFsbCBjb21lcyBkb3duIHRvIHdoYXQgeW91IHRydXN0IHRoZSBJZFAgdG8gYXNzZXJ0IGdp dmVuIGl0cyB0cnVzdCBmcmFtZXdvcmsgY29udGV4dCDigJQgaWYgdGhleSBhZ3JlZWQgdG8gcHJv b2YgdGhlIG5hbWUsIGFuZCB0aGV5IHNheSB0aGV5IGRpZCwgYW5kIHlvdSB0cnVzdCB0aGVtIHRv IG1ha2UgdGhhdCBjbGFpbSwgd2VsbCB0aGVuIHlvdeKAmXJlIGFsbCBzZXQuIElmIHRoZXkgZG9u 4oCZdCBhZ3JlZSB0byB0aGF0IChhcyBpbiBpdOKAmXMgbm90IHN0aXB1bGF0ZWQgaW4gdGhlIHRy dXN0IGFncmVlbWVudHMpICwgb3IgdGhleSBhZ3JlZWQgdG8gaXQgYW5kIGxpZWQgYWJvdXQgaXQs IG9yIHRoZXkgZGlkIGl0IGJ1dCB5b3UgZG9u4oCZdCB0cnVzdCB0aGVtIHRvIHNheSBpdCDigKYg dGhlbiBJIGNhbuKAmXQgcmVhbGx5IGhlbHAgeW91IHdpdGggdGhpcy4mbmJzcDs8L2Rpdj48ZGl2 PjxiciBjbGFzcz0iIj48L2Rpdj48ZGl2PkluIHRoZSBlbmQsIFZvVCBpcyBhbGwgYWJvdXQgb25l IHNpbXBsZSB0aGluZzogY29udmV5aW5nIGJ1bmRsZXMgb2YgaW5mb3JtYXRpb24gYWJvdXQgbW9z dGx5LW9ydGhvZ29uYWwgYXNwZWN0cyBvZiBhbiBpZGVudGl0eSB0cmFuc2FjdGlvbi4gSXTigJlz IGFib3V0IGFuIElkUCB0ZWxsaW5nIGFuIFJQOiDigJxJIGRpZCB0aGUgZm9sbG93aW5nIHRoaW5n cyBmcm9tIGEgbGlzdCBvZiB0aGluZ3MgdGhhdCB3ZSBhZ3JlZWQgdXBvbuKAnS4gSnVzdCBsaWtl IHNheWluZyDigJxMT0Ez4oCdIGluIHRoZSBVUyBHb3Zlcm5tZW50IGNvbnRleHQgbWVhbnQgc29t ZXRoaW5nIHByZXR0eSBzcGVjaWZpYywgc2F5aW5nIOKAnFAyLkNjLkFi4oCdIGFsc28gbWVhbnMg c29tZXRoaW5nIHNwZWNpZmljIGluIHRoYXQga2luZCBvZiBjb250ZXh0LiBCdXQgc2F5aW5nIOKA nExPQTPigJ0gaW4gQ2FuYWRhIG1lYW5zIHNvbWV0aGluZyBhIGxpdHRsZSBiaXQgZGlmZmVyZW50 LCBhbmQgc2F5aW5nIOKAnExPQTPigJ0gZWxzZXdoZXJlIGNvdWxkIGJlIGNvbXBsZXRlbHkgdW5y ZWxhdGVkIHRvIGVpdGhlciBjYXNlLiBJbiBhbGwgb2YgdGhlc2UsIGJvdGggdGhlIExvQSBhbmQg Vm9UIHZlcnNpb25zLCBpbnRlcnByZXRhdGlvbiBvZiB0aGUgcmVzdWx0IHRvIGEgcGFydGljdWxh ciByZWFsLXdvcmxkIG1lYW5pbmcgaXMgb3V0c2lkZSB0aGUgY29udmV5YW5jZSBwcm90b2NvbCBv ciBlbmNvZGluZy4gVGhlcmXigJlzIGEgbWFzc2l2ZSBhbW91bnQgb2YgY29udGV4dCB0aGF0IGlz IHRha2VuIGludG8gYWNjb3VudCwgYW5kIHRoYXQgY29udGV4dCB3aWxsIHRlbGwgeW91IGlmIHlv dSBjYW4gdHJ1c3QgdGhlIG5hbWUgb3IgdGhlIGFkZHJlc3Mgb3IgYW55dGhpbmcgZWxzZSB3aGVu IHlvdSBnZXQgYSBwYXJ0aWN1bGFyIHZhbHVlLjwvZGl2PjxkaXY+PGJyIGNsYXNzPSIiPjwvZGl2 PjxkaXY+WW914oCZcmUgdHJ5aW5nIHRvIGZpdCBpdCBpbnRvIHNvbWV0aGluZyBpdOKAmXMgbm90 IG1lYW50IGZvciBhbmQgbm90IGdvb2QgYXQsIGFuZCBhc2tpbmcgd2h5IGl0IGRvZXNu4oCZdCB3 b3JrOyB0byBtZSwgaXTigJlzIG5vIHN1cnByaXNlIHRoYXQgaXQgZG9lc27igJl0IHdvcmsgZm9y IHRoYXQuIFZvVCBkb2VzIG5vdCBkbyB3aGF0IHlvdeKAmXJlIGRlc2NyaWJpbmcsIGFuZCB0aGF0 4oCZcyBieSBkZXNpZ24uIFRoYXQgcGFydCBpcyBzcGVsbGVkIG91dCBpbiB0aGUgaW50cm9kdWN0 aW9uLiBPbiB0aGUgc2FtZSB0b2tlbiwgeW91ciBsYXdubW93ZXIgbWFrZXMgYSBwcmV0dHkgYmFk IHRvb3RoYnJ1c2guIEJ1dCBsaWtlIEkgPGIgY2xhc3M9IiI+a2VlcDwvYj4gcmVpdGVyYXRpbmc6 IGlmIHlvdSBoYXZlIGEgZGlmZmVyZW50IHByb2JsZW0sIDxpIGNsYXNzPSIiPnVzZSBhIGRpZmZl cmVudCB0b29sLjwvaT4mbmJzcDtJIGFtIHBlcmZlY3RseSBoYXBweSB3aXRoIHRoaXMgdGVjaG5v bG9neSBub3QgYmVpbmcgYSBzaWx2ZXIgYnVsbGV0IG9yIHBhbmFjZWEgb3Igd2hhdCBoYXZlIHlv dS4gVGhlcmUgYXJlIGEgbG90IG9mIHBlb3BsZSB3aG8gc2VlbSB0byBoYXZlIHRoZSBwcm9ibGVt IHRoYXQgdGhpcyB0b29sIHNvbHZlcywgc28gd2XigJlyZSBnb2luZyB0byBrZWVwIGdvaW5nIHdp dGggc29sdmluZyB0aG9zZSBwcm9ibGVtcy4gSSBsb29rIGZvcndhcmQgdG8gc2VlaW5nIHlvdXIg c29sdXRpb25zIGZvciBhdHRyaWJ1dGUgdHJ1c3QgYW5kIG1ldGFkYXRhIGluIHRoZSBmdXR1cmUu PC9kaXY+PGRpdj48YnIgY2xhc3M9IiI+PC9kaXY+PGRpdj5UaGFua3MsPC9kaXY+PGRpdj4mbmJz cDvigJQgSnVzdGluPC9kaXY+PGJyIGNsYXNzPSIiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNs YXNzPSIiPjxkaXYgY2xhc3M9IiI+PGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAt d2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUt c3BhY2U7IiBjbGFzcz0iIj48ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj48L2Rpdj48ZGl2IGNs YXNzPSIiPjxkaXYgY2xhc3M9IiI+CjxkaXYgc3R5bGU9ImxldHRlci1zcGFjaW5nOiBub3JtYWw7 IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9u ZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9k ZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0i Ij48ZGl2IHN0eWxlPSJsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsg dGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3Jt YWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHdv cmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxp bmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+PGRpdiBzdHlsZT0ibGV0dGVy LXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRl eHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBw eDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7 IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0 ZS1zcGFjZTsiIGNsYXNzPSIiPjxkaXYgc3R5bGU9ImxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRl eHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsg d2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTog c3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj48 ZGl2IHN0eWxlPSJsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4 dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7 IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHdvcmQt d3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUt YnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+PGRpdiBzdHlsZT0ibGV0dGVyLXNw YWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQt dHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsg LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13 ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1z cGFjZTsiIGNsYXNzPSIiPjxkaXYgc3R5bGU9ImxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQt YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hp dGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3Bh Y2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj48ZGl2 IHN0eWxlPSJsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1p bmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdv cmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHdvcmQtd3Jh cDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJl YWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+PGRpdiBzdHlsZT0ibGV0dGVyLXNwYWNp bmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJh bnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdl YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJr aXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFj ZTsiIGNsYXNzPSIiPjxkaXYgc3R5bGU9ImxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxp Z246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUt c3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lk dGg6IDBweDsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7 IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj48ZGl2IHN0 eWxlPSJsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRl bnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQt c3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHdvcmQtd3JhcDog YnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6 IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+PGRpdiBzdHlsZT0ibGV0dGVyLXNwYWNpbmc6 IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNm b3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQt bmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsi IGNsYXNzPSIiPjxkaXYgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIHN0 eWxlPSJib3JkZXItY29sbGFwc2U6IHNlcGFyYXRlOyBsaW5lLWhlaWdodDogbm9ybWFsOyBib3Jk ZXItc3BhY2luZzogMHB4OyI+PGRpdiBjbGFzcz0iIiBzdHlsZT0id29yZC13cmFwOiBicmVhay13 b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXIt d2hpdGUtc3BhY2U7Ij48ZGl2IGNsYXNzPSIiPjxkaXYgY2xhc3M9IiI+PGRpdiBjbGFzcz0iIj5Q aGlsPC9kaXY+PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+PC9kaXY+PGRpdiBjbGFzcz0iIj5P cmFjbGUgQ29ycG9yYXRpb24sIElkZW50aXR5IENsb3VkIFNlcnZpY2VzIEFyY2hpdGVjdDwvZGl2 PjxkaXYgY2xhc3M9IiI+QGluZGVwZW5kZW50aWQ8L2Rpdj48ZGl2IGNsYXNzPSIiPjxhIGhyZWY9 Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX193d3cu aW5kZXBlbmRlbnRpZC5jb21fJmFtcDtkPUR3TUZhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllS OFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJmFtcDtyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVp dnpqV3dsTktlNENfbExJR2smYW1wO209WUEySmRCT1lNM1NReF8xZnYwODhqNUN5aGZ2VG1uTmtL ekxFTXNYZ2FXZyZhbXA7cz00ZlB2RTZITEhSU04yOHZmZm1rVTQ2UnNLWU55NmlTRGc1Uzl5VTB3 Z0xvJmFtcDtlPSIgY2xhc3M9IiI+d3d3LmluZGVwZW5kZW50aWQuY29tPC9hPjwvZGl2PjwvZGl2 PjwvZGl2PjwvZGl2Pjwvc3Bhbj48YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20i IGNsYXNzPSIiIHN0eWxlPSJvcnBoYW5zOiAyOyB3aWRvd3M6IDI7Ij5waGlsLmh1bnRAb3JhY2xl LmNvbTwvYT48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48 L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj4KPC9kaXY+CjxiciBjbGFzcz0iIj48ZGl2IGNs YXNzPSIiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPjxkaXYgY2xhc3M9IiI+T24g U2VwIDEzLCAyMDE3LCBhdCAxMDo1NyBBTSwgSnVzdGluIFJpY2hlciAmbHQ7PGEgaHJlZj0ibWFp bHRvOmpyaWNoZXJAbWl0LmVkdSIgY2xhc3M9IiI+anJpY2hlckBtaXQuZWR1PC9hPiZndDsgd3Jv dGU6PC9kaXY+PGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj48ZGl2IGNsYXNz PSIiPjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6 IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+ SXQgYXBwbGllcyB0byB0aGUgSWRQ4oCZcyBqdWRnZW1lbnQgYWNyb3NzIHRoZSBlbnRpcmUgYXNz ZXJ0aW9uLiBIb3cgdGhhdOKAmXMgY2FsY3VsYXRlZCB3aGVuIHRoZSB0cnVzdCBpbiBkaWZmZXJl bnQgYXR0cmlidXRlcyBkaWZmZXJzIHdpbGwgdmFyeSBkZXBlbmRpbmcgb24gdGhlIElkUCwgYW5k IHByb2JhYmx5IGRlZmluZWQgYnkgcnVsZXMgd2l0aGluIHRoZSB0cnVzdCBmcmFtZXdvcmsgdGhh dCBkZWZpbmVzIHRoZSB2ZWN0b3IgdmFsdWVzIHRoZW1zZWx2ZXMuIE5JU1QgODAwLTYzLTMgdm9s dW1lIEEsIGZvciBleGFtcGxlLCBpcyB2ZXJ5IGNsZWFyIGFib3V0IGhvdyB0byBoYW5kbGUgYWxs IHRoZSBhdHRyaWJ1dGVzIGNvbGxlY3RlZCBhdCBkaWZmZXJlbnQgbGV2ZWxzLiBJZiB5b3Ugd2Vy ZSB1c2luZyBOSVNU4oCZcyBlbmNvZGluZyBvZiBWb1QsIHNwZWNpZmllZCBpbiB0aGUgdXBjb21p bmcgdm9sdW1lIEQgb2YgdGhhdCBkb2N1bWVudCwgdGhlbiB5b3XigJlkIGJlIGJvdW5kIGJ5IHRo b3NlIHJ1bGVzIGFzIGFuIElkUC4gQSB1bml2ZXJzaXR5IGdyb3VwLCBsaWtlIHlvdeKAmXJlIHRh bGtpbmcgYWJvdXQgYmVsb3csIG1pZ2h0IGhhdmUgZGlmZmVyZW50IHJ1bGVzIHVuZGVyIGl0cyBv d24gdHJ1c3QgZnJhbWV3b3JrIGFuZCB2ZWN0b3IgY29tcG9uZW50IGRlZmluaXRpb25zLjxkaXYg Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPjwvZGl2PjxkaXYgY2xhc3M9IiI+SXQgbG9va3MgbGlrZSB5 b3UgbWlnaHQgYmUgYXNraW5nIGlmIHRoaXMgaXMgYWJvdXQgcGVyLWF0dHJpYnV0ZSBtZXRhZGF0 YS4gSWYgeW91IHJlYWQgdGhlIGludHJvZHVjdGlvbiwgd2UgZXhwbGljaXRseSBzdGF0ZSB0aGF0 IHdl4oCZcmUgbm90IHRyeWluZyB0byBzb2x2ZSBwZXItYXR0cmlidXRlIG1ldGFkYXRhLiBJZiB5 b3XigJlkIGxpa2UgdGhhdCBraW5kIG9mIGRhdGEsIHlvdeKAmXJlIGxvb2tpbmcgZm9yIGEgZGlm ZmVyZW50IGtpbmQgb2Ygc29sdXRpb24sIG9mIHdoaWNoIHRoZXJlIGhhdmUgYmVlbiBudW1lcm91 cyBhdHRlbXB0cyBvdmVyIHRoZSB5ZWFycy4gR2VuZXJhbGx5IHNwZWFraW5nLCBhdHRyaWJ1dGUg bWV0YWRhdGEgc3lzdGVtcyBsb29rIGdyZWF0IG9uIHBhcGVyIGJ1dCBhcmUgaW5jcmVkaWJseSBj b21wbGljYXRlZCBmb3IgUlDigJlzIHRvIGltcGxlbWVudC4gV2hlbiB3ZSB3cm90ZSBWb1QsIHdl IGRpcmVjdGx5IGRlY2lkZWQgdG8gdGFrZSBhIGRpZmZlcmVudCBhcHByb2FjaCwgc29tZXRoaW5n IGJldHdlZW4gdGhlIGdyYW51bGFyaXR5IG9mIGF0dHJpYnV0ZXMgYW5kIHRoZSBzaW5nbGUtc2Nh bGUgb2YgTE9BLiZuYnNwOzxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPjwvZGl2PjxkaXYgY2xh c3M9IiI+VGhpcyBsZXZlbCBvZiBncmFudWxhcml0eSBpcyB2ZXJ5LCB2ZXJ5IHVzZWZ1bCBpbiB0 aGUgcmVhbCB3b3JsZCwgb3RoZXJ3aXNlIHdlIHdvdWxkbuKAmXQgaGF2ZSBkb3plbnMgb2YgaW50 ZXJuYXRpb25hbCB0cnVzdCBmcmFtZXdvcmtzIGJhc2VkIGFyb3VuZCB0aGUgY29uY2VwdCBvZiBw cm9vZmluZyBhbiBpbmRpdmlkdWFsIGFuZCB0eWluZyB0aGF0IGFjY291bnQgdG8gYSBzZXQgb2Yg cHJvb2ZlZCBhdHRyaWJ1dGVzLiBUaGVyZSBpc27igJl0IGFuIGVhc3kgd2F5IHRvIGV4cHJlc3Mg c29tZXRoaW5nIGNvbXBsZXggYXMg4oCcV2XigJlyZSBzdXJlIHRoaXMgaXMgSnVzdGluIGJ1dCBh cmVu4oCZdCBzdXJlIGFib3V0IGhpcyBtZWRpY2FsIGRlZ3JlZeKAnSBpbiBhbnkgVm9UIGltcGxl bWVudGF0aW9uIHRoYXQgSeKAmXZlIHNlZW4gdG8gZGF0ZSwgYW5kIGVzcGVjaWFsbHkgbm90IGlu IHRoZSBleGFtcGxlIHZhbHVlcyBnaXZlbiBpbiB0aGUgc3BlYyBpdHNlbGYuIEJ1dCBpZiB5b3Ug cmVhbGx5IHdhbnRlZCB0bywgeW91IGNvdWxkIGhhdmUgc29tZXRoaW5nIGxpa2U6PC9kaXY+PGRp diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+PC9kaXY+PGRpdiBjbGFzcz0iIj4mbmJzcDstIFAzOiBI aWdoIGxldmVsIG9mIGNvbmZpZGVuY2UgaW4gaW5kaXZpZHVhbOKAmXMgbmFtZSwgYWRkcmVzcywg cGhvbmUsIGV5ZSBjb2xvciwgYW5kIHNob2Ugc2l6ZTwvZGl2PjxkaXYgY2xhc3M9IiI+Jm5ic3A7 LSBQbTogSW4gcGVyc29uIHZlcmlmaWNhdGlvbiBvZiBhIG1lZGljYWwgZGVncmVlIGJ5IG1ha2lu ZyB0aGUgY2xhaW1hbnQgcGVyZm9ybSBzdXJnZXJ5IG9uIHRoZSB2ZXJpZmllci48L2Rpdj48ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj48L2Rpdj48ZGl2IGNsYXNzPSIiPlNvIGlmIHlvdSB3YW50 ZWQgdG8gZXhwcmVzcyB0aGF0LCB5b3UgY291bGQgc2F5IOKAnFAzLlBt4oCdIG9yIGp1c3Qg4oCc UDPigJ0gaWYgeW91IHdlcmVu4oCZdCBzbyBzdXJlIGFib3V0IHRoYXQgbWVkaWNhbCBkZWdyZWUu IEhvd2V2ZXIsIGxpa2UgSSBkZXNjcmliZWQgYWJvdmUsIEkgZG9u4oCZdCB0aGluayB0aGlzIGlz IGEgZ29vZCBzb2x1dGlvbiBmb3IgdGhhdCBhcyB5b3XigJlkIG5lZWQgdG8gZ2V0IHJlYWxseSBz cGVjaWZpYyB3aXRoIGVhY2ggYXR0cmlidXRlLiBJZiB5b3UgcmVhbGx5IG5lZWQgdGhhdCBsZXZl bCBvZiBleHByZXNzaXZlbmVzcywgeW914oCZbGwgd2FudCBhIGRpZmZlcmVudCBzb2x1dGlvbiBh bmQgVm9UIGRvZXNu4oCZdCB3b3JrIGZvciB5b3UuIEhvd2V2ZXIsIGp1c3QgYmVjYXVzZSBpdCBk b2VzbuKAmXQgc29sdmUgdGhpcyB1c2UgY2FzZSBkb2VzbuKAmXQgbWVhbiBpdOKAmXMgbm90IHVz ZWZ1bCBpbiBtYW55IG90aGVycy4gVm9UIGlzIGEgdG9vbCBmaXQgZm9yIGEgcHVycG9zZSB0aGF0 IHdlIHRyaWVkIHRvIGV4cHJlc3MgaW4gdGhlIGludHJvIHRleHQsIGl0IGZpdHMgaW4gYmV0d2Vl biBhdHRyaWJ1dGUgbWV0YWRhdGEgYW5kIHNpbmdsZSBzY2FsYXIgbWVhc3VyZW1lbnRzLiBBbmQg aW4gZmFjdCwgeW91IGNvdWxkIHVzZSBpdCBzaWRlIGJ5IHNpZGUgaW4gdGhlIHNhbWUgc3lzdGVt LCBhbmQgSSBzZWUgbm8gY29uZmxpY3QgaW4gdGhpcy48L2Rpdj48ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj48L2Rpdj48ZGl2IGNsYXNzPSIiPkRvbuKAmXQgZGVueSB0aGUgd29ybGQgYSBoYW1t ZXIganVzdCBiZWNhdXNlIHlvdSB0aGluayB5b3UgbmVlZCBhIHNjcmV3ZHJpdmVyLjwvZGl2Pjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPjwvZGl2PjxkaXYgY2xhc3M9IiI+Jm5ic3A74oCUIEp1 c3RpbjwvZGl2PjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPjxkaXYgY2xhc3M9IiI+PGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+PGRpdiBjbGFzcz0iIj5PbiBTZXAgMTMsIDIwMTcs IGF0IDE6MDEgUE0sIFBoaWwgSHVudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFj bGUuY29tIiBjbGFzcz0iIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2 PjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+PGRpdiBjbGFzcz0iIj4KPGRp diBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7 IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj48ZGl2IGNs YXNzPSIiPlNlY3Rpb24gMy4xPC9kaXY+PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+PC9kaXY+ PGRpdiBjbGFzcz0iIj5Eb2VzIDMuMSBhcHBseSB0byB0aGUgaWRlbnRpZmllciBpc3N1ZWQsIHRv IHRoZSB3aG9sZSBhc3NlcnRpb24/Jm5ic3A7PC9kaXY+PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9 IiI+PC9kaXY+PGRpdiBjbGFzcz0iIj5BbiBJZGVudGl0eSBpcyB1c3VhbGx5IGFuIGlkZW50aWZp ZXIgYW5kIGEgc2V0IG9mIGNsYWltcy48L2Rpdj48ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj48 L2Rpdj48ZGl2IGNsYXNzPSIiPlNvIHdoYXQgYWJvdXQgY2xhaW1zPyAmbmJzcDsgU29tZSBjbGFp bXMgbWF5IGJlIGlzc3VlZCBieSBhIHByb3ZpZGVyIChhbmQgdGh1cyBhcmUgUDMpIHdoaWxlIG90 aGVycyBtYXkgYmUgcHJvdmlkZWQgYXMgc2VsZiBhc3NlcnRlZCBieSB0aGUgc3ViamVjdC4gJm5i c3A7U29tZSwgYXMgaW4gYmFua2luZyBtYXkgaGF2ZSBpbnZvbHZlZCBhIHBoeXNpY2FsIGRvY3Vt ZW50cyBvciBvdGhlciBtZWNoYW5pc20gYW5kIHRodXMgYWxsIGNsYWltcyBhcmUgbm90IGVxdWFs LjwvZGl2PjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPjwvZGl2PjxkaXYgY2xhc3M9IiI+SSBo YXZlIHRyb3VibGUgZGV0ZXJtaW5pbmcgdGhlIGFmZmVjdCBvZiBQMC1QMyBhbmQgd29ycnkgdGhh dCBwcml2aWxlZ2UgZXNjYWxhdGlvbiB3aWxsIG9jY3VyIHNpbmNlIG5vdCBhbGwgY2xhaW1zIGFy ZSBlcXVhbC4gJm5ic3A7VGhlcmUgaXNu4oCZdCByZWFsbHkgYSB3YXkgdG8gc2F5IOKAnFdl4oCZ cmUgY29uZmlkZW50IHRoaXMgaXMgSnVzdGluLCB3ZeKAmXJlIGp1c3Qgbm90IHNvIHN1cmUgYWJv dXQgaGlzIG1lZGljYWwgZGVncmVl4oCdLjwvZGl2PjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi PjwvZGl2PjxkaXYgY2xhc3M9IiI+Q29uc2lkZXIgYSB1bml2ZXJzaXR5IGtub3dzIHN0dWRlbnQg bnVtYmVycyBhbmQgZGVncmVlcyBhbmQgY291cnNlcyBjb21wbGV0ZWQuIElzIGl0IGF1dGhvcml0 YXRpdmUgb3ZlciBuYXRpb25hbGl0eSwgcmVzaWRlbmNlLCBhZGRyZXNzZXM/ICZuYnNwO01heWJl LiBNYXliZSBub3QuPC9kaXY+PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+PC9kaXY+PGRpdiBj bGFzcz0iIj5Db25zaWRlciBhIHNvY2lhbCBuZXR3b3JrLiBJbiBtYW55IGNhc2VzIHRoZXkgY2Fu IGJlIGNvbnNpZGVyZWQgYXV0aG9yaXRhdGl2ZSBvdmVyIHRoZSBzb2NpYWwgbmV0d29yayBpZGVu dGl0eSAoUDMpIGJ1dCBrbm93IG5vdGhpbmcgYWJvdXQgbW9zdCB1c2Vycy48L2Rpdj48ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj48L2Rpdj48ZGl2IGNsYXNzPSIiPknigJltIGp1c3Qgbm90IHN1 cmUgaWRlbnRpdHkgcHJvb2ZpbmcgYXMgZXhwcmVzc2VkIGlzIGFjdHVhbGx5IHVzZWZ1bC48L2Rp dj48ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj48L2Rpdj48ZGl2IGNsYXNzPSIiPjxkaXYgY2xh c3M9IiI+CjxkaXYgc3R5bGU9ImxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0 YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6 IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBw eDsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJr aXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj48ZGl2IHN0eWxlPSJs ZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBw eDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2lu ZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHdvcmQtd3JhcDogYnJlYWst d29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVy LXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+PGRpdiBzdHlsZT0ibGV0dGVyLXNwYWNpbmc6IG5vcm1h bDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBu b25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0 LXN0cm9rZS13aWR0aDogMHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1t b2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNz PSIiPjxkaXYgc3R5bGU9ImxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0 OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5v cm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsg d29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQt bGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj48ZGl2IHN0eWxlPSJsZXR0 ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsg dGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzog MHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHdvcmQtd3JhcDogYnJlYWstd29y ZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdo aXRlLXNwYWNlOyIgY2xhc3M9IiI+PGRpdiBzdHlsZT0ibGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg dGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25l OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0 cm9rZS13aWR0aDogMHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2Rl OiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIi PjxkaXYgc3R5bGU9ImxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0 ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1h bDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgd29y ZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGlu ZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj48ZGl2IHN0eWxlPSJsZXR0ZXIt c3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4 dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4 OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHdvcmQtd3JhcDogYnJlYWstd29yZDsg LXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRl LXNwYWNlOyIgY2xhc3M9IiI+PGRpdiBzdHlsZT0ibGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4 dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3 aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBz cGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPjxk aXYgc3R5bGU9ImxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0 LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsg d29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgd29yZC13 cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1i cmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj48ZGl2IHN0eWxlPSJsZXR0ZXItc3Bh Y2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10 cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAt d2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHdvcmQtd3JhcDogYnJlYWstd29yZDsgLXdl YmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNw YWNlOyIgY2xhc3M9IiI+PGRpdiBzdHlsZT0ibGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1h bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0 ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFj ZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPjxkaXYg Y2xhc3M9IiI+PHNwYW4gY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIHN0eWxlPSJib3JkZXItY29s bGFwc2U6IHNlcGFyYXRlOyBsaW5lLWhlaWdodDogbm9ybWFsOyBib3JkZXItc3BhY2luZzogMHB4 OyI+PGRpdiBjbGFzcz0iIiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5i c3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7Ij48 ZGl2IGNsYXNzPSIiPjxkaXYgY2xhc3M9IiI+PGRpdiBjbGFzcz0iIj5QaGlsPC9kaXY+PGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+PC9kaXY+PGRpdiBjbGFzcz0iIj5PcmFjbGUgQ29ycG9yYXRp b24sIElkZW50aXR5IENsb3VkIFNlcnZpY2VzIEFyY2hpdGVjdDwvZGl2PjxkaXYgY2xhc3M9IiI+ QGluZGVwZW5kZW50aWQ8L2Rpdj48ZGl2IGNsYXNzPSIiPjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVm ZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX193d3cuaW5kZXBlbmRlbnRpZC5j b21fJmFtcDtkPUR3TUZhUSZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZsWllSOFBRY3hCS0NYNVlUcGtL WTA1N1NiSzEwJmFtcDtyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4UEVpdnpqV3dsTktlNENfbExJ R2smYW1wO209VklrdlN1X1NVa0s2ak9TR1BwZHc1Tl9xT0NZVG1YZllESTBGcnpjNnd6SSZhbXA7 cz1VX3JjdTItZkgybHFFTG5oaWNsYnA3aWh0TWltODNKWXpwekw0NEFVelprJmFtcDtlPSIgY2xh c3M9IiI+d3d3LmluZGVwZW5kZW50aWQuY29tPC9hPjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2Pjwv c3Bhbj48YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIGNsYXNzPSIiIHN0eWxl PSJvcnBoYW5zOiAyOyB3aWRvd3M6IDI7Ij5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT48L2Rpdj48 L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rp dj48L2Rpdj48L2Rpdj4KPC9kaXY+CjxiciBjbGFzcz0iIj48L2Rpdj48L2Rpdj5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj52b3QgbWFp bGluZyBsaXN0PGJyIGNsYXNzPSIiPjxhIGhyZWY9Im1haWx0bzp2b3RAaWV0Zi5vcmciIGNsYXNz PSIiPnZvdEBpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZl bnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1h bl9saXN0aW5mb192b3QmYW1wO2Q9RHdNRmFRJmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFj eEJLQ1g1WVRwa0tZMDU3U2JLMTAmYW1wO3I9SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empX d2xOS2U0Q19sTElHayZhbXA7bT1ZQTJKZEJPWU0zU1F4XzFmdjA4OGo1Q3loZnZUbW5Oa0t6TEVN c1hnYVdnJmFtcDtzPVFhSmRsTnJXUERpVkNVcWoxSnhINDdQc1lyS2xDSzd5X2NaR2lNUTBfbVkm YW1wO2U9IiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Zv dDwvYT48YnIgY2xhc3M9IiI+PC9kaXY+PC9ibG9ja3F1b3RlPjwvZGl2PjxiciBjbGFzcz0iIj48 L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9kaXY+PGJyIGNsYXNzPSIiPjwv ZGl2PjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48YnIgY2xhc3M9IiI+PC9kaXY+PC9k aXY+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxkaXY+PHNwYW4+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+PGJyPjxzcGFu PnZvdCBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyPjxzcGFuPjxhIGhyZWY9Im1haWx0bzp2b3RAaWV0 Zi5vcmciPnZvdEBpZXRmLm9yZzwvYT48L3NwYW4+PGJyPjxzcGFuPjxhIGhyZWY9Imh0dHBzOi8v dXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3Jn X21haWxtYW5fbGlzdGluZm9fdm90JmFtcDtkPUR3SUNBZyZhbXA7Yz1Sb1AxWXVtQ1hDZ2FXSHZs WllSOFBRY3hCS0NYNVlUcGtLWTA1N1NiSzEwJmFtcDtyPUpCbTViaVJyS3VnQ0gwRmtJVFNlR0p4 UEVpdnpqV3dsTktlNENfbExJR2smYW1wO209WUEySmRCT1lNM1NReF8xZnYwODhqNUN5aGZ2VG1u TmtLekxFTXNYZ2FXZyZhbXA7cz1RYUpkbE5yV1BEaVZDVXFqMUp4SDQ3UHNZcktsQ0s3eV9jWkdp TVEwX21ZJmFtcDtlPSI+aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91 PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb192b3QmYW1wO2Q9RHdJQ0Fn JmFtcDtjPVJvUDFZdW1DWENnYVdIdmxaWVI4UFFjeEJLQ1g1WVRwa0tZMDU3U2JLMTAmYW1wO3I9 SkJtNWJpUnJLdWdDSDBGa0lUU2VHSnhQRWl2empXd2xOS2U0Q19sTElHayZhbXA7bT1ZQTJKZEJP WU0zU1F4XzFmdjA4OGo1Q3loZnZUbW5Oa0t6TEVNc1hnYVdnJmFtcDtzPVFhSmRsTnJXUERpVkNV cWoxSnhINDdQc1lyS2xDSzd5X2NaR2lNUTBfbVkmYW1wO2U9PC9hPiA8L3NwYW4+PGJyPjwvZGl2 PjwvYmxvY2txdW90ZT48L2JvZHk+PC9odG1sPg== ----_com.samsung.android.email_1360276214889210--