From nobody Thu Oct 2 14:10:23 2014 Return-Path: X-Original-To: vot@ietfa.amsl.com Delivered-To: vot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7531ACD83 for ; Thu, 2 Oct 2014 14:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.393 X-Spam-Level: X-Spam-Status: No, score=-0.393 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786, TVD_PH_BODY_ACCOUNTS_PRE=2.393] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-dsJhHcIxxP for ; Thu, 2 Oct 2014 14:10:09 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id 04E3E1ACD7D for ; Thu, 2 Oct 2014 14:10:09 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A96683AE09B for ; Thu, 2 Oct 2014 17:10:08 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id 9E1143AE08A for ; Thu, 2 Oct 2014 17:10:08 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.195]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.03.0174.001; Thu, 2 Oct 2014 17:10:08 -0400 From: "Richer, Justin P." To: "vot@ietf.org" Thread-Topic: Vectors of Trust: A Strawman Thread-Index: AQHP3oU+4p9DXTurHEG17GSReQzTfA== Date: Thu, 2 Oct 2014 21:10:07 +0000 Message-ID: <42FAEF9E-37A4-4F3A-84C0-63C1FBC22EC6@mitre.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.4.54] Content-Type: multipart/alternative; boundary="_000_42FAEF9E37A44F3A84C063C1FBC22EC6mitreorg_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/vot/rsAmmJTRE9RaOV416_bOSXcmdXc Subject: [VoT] Vectors of Trust: A Strawman X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 21:10:19 -0000 --_000_42FAEF9E37A44F3A84C063C1FBC22EC6mitreorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, In Utrecht, many of us had a conversation about "Level of Assurance", its l= imitations, and where we thought we could take it. There was a pretty consi= stent notion that LoA as currently defined provides a handy shortcut but is= usually insufficient and more often than not is grossly misused. With that in mind, I would like to kick off this mailing list with a strawm= an proposal for an alternative: Vectors of Trust. The core idea here is to = factor out different aspects of what goes into the LoA calculation today an= d present them as orthogonal vectors. These vectors would need to be commun= icated in various protocols and environments. We would also need to have a = way of describing (and perhaps cataloguing) certain sets of vector values i= nto a single reference to be used in things like trust frameworks. The first question is what vectors should there be? Embedded in this is how= many there should be in the first place. Too few vectors and we end up wit= h the overly-simplified and usually-misused problem that LoA has today. Too= many vectors and we end up with an un-navigable set of values where everyb= ody's niche concern is a special snowflake. We need to stay allergic to bot= h cases and shoot for something "in the middle". In particular, my own pers= onal gut instinct says we should shoot for 3 to 5 vectors. I'm going to pro= pose 4 here, all of them linear scales. As a side note, it's a question whe= ther all of these are even linear scales, but I think it's important that w= e define comparison metrics on each vector element as well as the overall v= alues. So what vectors should we have? The LoA definition in 800-63 gives us a few= to work from as starting points, as well as some work that's been done in = the UK. These were captured from the discussion in the Utrecht meeting: Identity proofing: This covers how sure the IdP is of various attributes about the user on the= way in, and how much they're willing to vouch for those attributes. 0: self-asserted / anonymous / randomized / no idea 1: consistent over time / pseudonymous 2: proofed in person 3: contractually bound Credential strength: This covers how strongly bound the primary credential is to an individual p= resenter, and how easily spoofed or stolen it is. 0: no credential / public 1: shared secret / password 2: proof of key possession 3: multiple factors [and probably higher definitions here as well -- but we= want to avoid all the little bespoke 2FA companies getting to define a spe= cial snowflake "credential strength" value or else this becomes useless] Assertion presentation: This covers how much the federation protocol leaks information over the net= work to various parties, and how much of that information could be tampered= in transit without the RP noticing. 0: no protection / leaky 1: signed & verifiable through browser 2: signed & verifiable through back channel 3: target-encrypted to RP's own key Operational management: This covers a variety of information about the identity provider and its ho= st organization. What's the OpSec policy of the IdP? Is there disaster reco= very in place? How mature is the hosting organization? What kind of inciden= t response can be expected? How strongly bound is a particular attribute to= a particular credential [though maybe this fits under identity proofing]? = You'll note that already this feels a lot less linear and a lot less define= d than the other three. Next we need a way to combine and communicate these vectors across the wire= . I propose a simple method of assigning each category a marker letter and = each value within the category a numeric value, and combining them with a s= eparator, such as: pseudonymous, multi-factor, strong assertion =3D P1:C3:A2 It's compact and unambiguous, though it's not really making use of any exis= ting data structures languages like JSON. But I think there does need to be= a simple and parseable means to convey this info. This way, clients that n= eed information on a particular category can pull it out and ignore the oth= ers. We can present structures like this (especially if they serialize into= strings like this example) as part of the assertions in a variety of proto= cols. Say you've got an OpenID Connect access token, you can add a "vot" me= mber to the payload with "I1:C3:A2" as its value. Clients can parse or igno= re this as they see fit. Next, I think we need a good way to label and categorize these combined vec= tors, especially as exemplary use cases. A handful of examples from my own = deployment experience: P3:C2:A1 - OpenID 2.0 account provided to current employees and protected b= y domain password P1:C3:A2 - OpenID Connect account from dynamically introduced IdP bound to = a medical record in an out-of-band process P3:C3:A3 - Cross-domain OpenID Connect pilot (with contracts connecting the= two orgs to enforce the semantics) It is probably a mistake to try and smush these back into a linear scale li= ke LoA, since that's exactly what we're trying to get away from. However, i= t would probably be a good and enlightening exercise to map the existing Lo= A definitions into these vectors. Finally, I think we need to think about and discuss the notion of the asses= sment and trustmarks that would be powering the trust in all of these value= s. After all, if they're just self-asserted by the IdP, that doesn't really= help anyone. However, if we had a discovery mechanism whereby a trustmark = provider would be able to host a machine-readable definition of what vector= s a particular IdP has been proven to be able to claim for any transaction,= I think we've got a good leg up on the problem. First off, it would need t= o be discoverable from the IdP, so I'm proposing we add a component to the = discovery document. An OIDC example: { "iss": "https://idp.example.org/", "trustmark": "https://trustmark-provider.org/csp-123412" ... } The URI given in this document would contain information about which vector= s the IdP is allowed to claim, according to the trustmark provider: { "iss": "https://idp.example.org/", "P": [3], "C": [1, 2, 3], "A": [2, 3], "O": [1, 4] } Paranoid clients and clients dealing with many IdPs across an ecosystem wou= ld be able to grab the service discovery doc (step 1, and they probably nee= d it anyway) and then checking with a trusted third party, the trustmark pr= ovider, if the IdP is on the up-and-up. If a client gets a claim for a vect= or value that's not attested to by a known/trusted trustmark provider, it c= an call shenanigans. This is far from comprehensive, but I think this is a fairly decent strawma= n to start with. So let's burn this down and see what's left. Be sure to in= vite your friends to the bonfire! -- Justin --_000_42FAEF9E37A44F3A84C063C1FBC22EC6mitreorg_ Content-Type: text/html; charset="us-ascii" Content-ID: <784F1870E81E7A4C98E0EA9E8E45B610@imc.mitre.org> Content-Transfer-Encoding: quoted-printable Hi all,

In Utrecht, many of us had a conversation about "Level of Assuran= ce", its limitations, and where we thought we could take it. There was= a pretty consistent notion that LoA as currently defined provides a handy = shortcut but is usually insufficient and more often than not is grossly misused. 

With that in mind, I would like to kick off this mailing list with a s= trawman proposal for an alternative: Vectors of Trust. The core idea here i= s to factor out different aspects of what goes into the LoA calculation tod= ay and present them as orthogonal vectors. These vectors would need to be communicated in various protocols = and environments. We would also need to have a way of describing (and perha= ps cataloguing) certain sets of vector values into a single reference to be= used in things like trust frameworks.



The first question is what vectors should there be? Embedded in this i= s how many there should be in the first place. Too few vectors and we end u= p with the overly-simplified and usually-misused problem that LoA has today= . Too many vectors and we end up with an un-navigable set of values where everybody's niche concern is a sp= ecial snowflake. We need to stay allergic to both cases and shoot for somet= hing "in the middle". In particular, my own personal gut instinct= says we should shoot for 3 to 5 vectors. I'm going to propose 4 here, all of them linear scales. As a side note, it= 's a question whether all of these are even linear scales, but I think it's= important that we define comparison metrics on each vector element as well= as the overall values.



So what vectors should we have? The LoA definition in 800-63 gives us = a few to work from as starting points, as well as some work that's been don= e in the UK. These were captured from the discussion in the Utrecht meeting= :

Identity proofing: 

This covers how sure the IdP is of various attributes about the user o= n the way in, and how much they're willing to vouch for those attributes.&n= bsp;

0: self-asserted / anonymous / randomized / no idea
1: consistent over time / pseudonymous
2: proofed in person
3: contractually bound

Credential strength:

This covers how strongly bound the primary credential is to an individ= ual presenter, and how easily spoofed or stolen it is.

0: no credential / public
1: shared secret / password
2: proof of key possession
3: multiple factors [and probably higher definitions here as well -- b= ut we want to avoid all the little bespoke 2FA companies getting to define = a special snowflake "credential strength" value or else this beco= mes useless]

Assertion presentation:

This covers how much the federation protocol leaks information over th= e network to various parties, and how much of that information could be tam= pered in transit without the RP noticing. 

0: no protection / leaky
1: signed & verifiable through browser
2: signed & verifiable through back channel
3: target-encrypted to RP's own key

Operational management:

This covers a variety of information about the identity provider and i= ts host organization. What's the OpSec policy of the IdP? Is there disaster= recovery in place? How mature is the hosting organization? What kind of in= cident response can be expected? How strongly bound is a particular attribute to a particular credential [t= hough maybe this fits under identity proofing]? You'll note that already th= is feels a lot less linear and a lot less defined than the other three.&nbs= p;



Next we need a way to combine and communicate these vectors across the= wire. I propose a simple method of assigning each category a marker letter= and each value within the category a numeric value, and combining them wit= h a separator, such as:

  pseudonymous, multi-factor, strong assertion =3D P1:C3:A2

It's compact and unambiguous, though it's not really making use of any= existing data structures languages like JSON. But I think there does need = to be a simple and parseable means to convey this info. This way, clients t= hat need information on a particular category can pull it out and ignore the others. We can present structures = like this (especially if they serialize into strings like this example) as = part of the assertions in a variety of protocols. Say you've got an OpenID = Connect access token, you can add a "vot" member to the payload with "I1:C3:A2" as its v= alue. Clients can parse or ignore this as they see fit.


Next, I think we need a good way to label and categorize these combine= d vectors, especially as exemplary use cases. A handful of examples from my= own deployment experience:

P3:C2:A1 - OpenID 2.0 account provided to current employees and protec= ted by domain password

P1:C3:A2 - OpenID Connect account from dynamically introduced IdP boun= d to a medical record in an out-of-band process

P3:C3:A3 - Cross-domain OpenID Connect pilot (with contracts connectin= g the two orgs to enforce the semantics)

It is probably a mistake to try and smush these back into a linear sca= le like LoA, since that's exactly what we're trying to get away from. Howev= er, it would probably be a good and enlightening exercise to map the existi= ng LoA definitions into these vectors.



Finally, I think we need to think about and discuss the notion of the = assessment and trustmarks that would be powering the trust in all of these = values. After all, if they're just self-asserted by the IdP, that doesn't r= eally help anyone. However, if we had a discovery mechanism whereby a trustmark provider would be able to ho= st a machine-readable definition of what vectors a particular IdP has been = proven to be able to claim for any transaction, I think we've got a good le= g up on the problem. First off, it would need to be discoverable from the IdP, so I'm proposing we add a c= omponent to the discovery document. An OIDC example:

{
  "trustmark": "https://trustmark-provider.org/csp-123412"
  ...
}

The URI given in this document would contain information about which v= ectors the IdP is allowed to claim, according to the trustmark provider:

{
  "P": [3],
  "C": [1, 2, 3],
  "A": [2, 3],
  "O": [1, 4]
}

Paranoid clients and clients dealing with many IdPs across an ecosyste= m would be able to grab the service discovery doc (step 1, and they probabl= y need it anyway) and then checking with a trusted third party, the trustma= rk provider, if the IdP is on the up-and-up. If a client gets a claim for a vector value that's not attested= to by a known/trusted trustmark provider, it can call shenanigans. 



This is far from comprehensive, but I think this is a fairly decent st= rawman to start with. So let's burn this down and see what's left. Be sure = to invite your friends to the bonfire!

 -- Justin
--_000_42FAEF9E37A44F3A84C063C1FBC22EC6mitreorg_-- From nobody Thu Oct 2 15:07:52 2014 Return-Path: X-Original-To: vot@ietfa.amsl.com Delivered-To: vot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37A991ACE39 for ; Thu, 2 Oct 2014 15:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yc9rhe3VLIyl for ; Thu, 2 Oct 2014 15:07:46 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1C341ACE38 for ; Thu, 2 Oct 2014 15:07:42 -0700 (PDT) Received: from splunge.local ([12.250.97.26]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.3/8.14.3/Debian-9.4) with ESMTP id s92M7euX020883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 2 Oct 2014 15:07:41 -0700 Message-ID: <542DCCA7.8070308@bluepopcorn.net> Date: Thu, 02 Oct 2014 15:07:35 -0700 From: Jim Fenton User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: vot@ietf.org References: <42FAEF9E-37A4-4F3A-84C0-63C1FBC22EC6@mitre.org> In-Reply-To: <42FAEF9E-37A4-4F3A-84C0-63C1FBC22EC6@mitre.org> Content-Type: multipart/alternative; boundary="------------040400040708000208080101" Archived-At: http://mailarchive.ietf.org/arch/msg/vot/0vSjGBQUp7sQCsWisgsBi1YIEks Subject: Re: [VoT] Vectors of Trust: A Strawman X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 22:07:50 -0000 This is a multi-part message in MIME format. --------------040400040708000208080101 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Justin, Good kickoff! On 10/2/14 2:10 PM, Richer, Justin P. wrote: > > The first question is what vectors should there be? Embedded in this > is how many there should be in the first place. Too few vectors and we > end up with the overly-simplified and usually-misused problem that LoA > has today. Too many vectors and we end up with an un-navigable set of > values where everybody's niche concern is a special snowflake. We need > to stay allergic to both cases and shoot for something "in the > middle". In particular, my own personal gut instinct says we should > shoot for 3 to 5 vectors. I'm going to propose 4 here, all of them > linear scales. As a side note, it's a question whether all of these > are even linear scales, but I think it's important that we define > comparison metrics on each vector element as well as the overall values= =2E I'd suggest s/vectors/dimensions/ But what you're saying is that within each dimension, the relationships are well-ordered. > > > > So what vectors should we have? The LoA definition in 800-63 gives us > a few to work from as starting points, as well as some work that's > been done in the UK. A bit of history: 800-63 is a response to OMB M-04-04, which defined 4 levels of assurance. 800-63 is a response to the OMB document describing how each of the assurance levels should be achieved. During the 800-63-1 revision, there was some discussion about doing something different, particularly to support the NSTIC strategy's vision of separate identity and attribute providers. Also, it would have been a major change and it would have made it less clear how 800-63 is responsive to M-04-04, which is its primary official purpose. So a paragraph was added to the introduction (although it doesn't explicitly mention LoA): > Current government systems do not separate functions related to > identity proofing in registration from credential issuance. In some > applications, credentials (used in authentication) and attribute > information (established through identity proofing) could be provided > by different parties. While a simpler model is used in this document, > it does not preclude agencies from separating these functions. > > > *Identity proofing: * > > This covers how sure the IdP is of various attributes about the user > on the way in, and how much they're willing to vouch for those > attributes.=20 > > 0: self-asserted / anonymous / randomized / no idea > 1: consistent over time / pseudonymous > 2: proofed in person > 3: contractually bound "consistent over time/pseudonymous" is probably also self-asserted. I notice that you don't have a value for online identity proofing. Was that an intentional omission? I'm curious what "contractually bound" is beyond in-person proofing. > > *Credential strength:* > > This covers how strongly bound the primary credential is to an > individual presenter, and how easily spoofed or stolen it is. > > 0: no credential / public > 1: shared secret / password > 2: proof of key possession > 3: multiple factors [and probably higher definitions here as well -- > but we want to avoid all the little bespoke 2FA companies getting to > define a special snowflake "credential strength" value or else this > becomes useless] Anything here about how the secret key is protected? How about bearer assertions like cookies? > > *Assertion presentation:* > > This covers how much the federation protocol leaks information over > the network to various parties, and how much of that information could > be tampered in transit without the RP noticing.=20 > > 0: no protection / leaky > 1: signed & verifiable through browser > 2: signed & verifiable through back channel > 3: target-encrypted to RP's own key 3 seems like it's addressing a different problem (secrecy) rather than the verifiability of the assertion. > > *Operational management:* > > This covers a variety of information about the identity provider and > its host organization. What's the OpSec policy of the IdP? Is there > disaster recovery in place? How mature is the hosting organization? > What kind of incident response can be expected? How strongly bound is > a particular attribute to a particular credential [though maybe this > fits under identity proofing]? You'll note that already this feels a > lot less linear and a lot less defined than the other three. > It is probably a mistake to try and smush these back into a linear > scale like LoA, since that's exactly what we're trying to get away > from. However, it would probably be a good and enlightening exercise > to map the existing LoA definitions into these vectors. I think this is very important, to be able to use vectors of trust with legacy LOA-based systems. I made an effort to do a mapping like this a couple of years back, based on a somewhat different vector: http://www.slideshare.net/jim_fenton/nstic-loa (at slide 9). > > > > Finally, I think we need to think about and discuss the notion of the > assessment and trustmarks that would be powering the trust in all of > these values. After all, if they're just self-asserted by the IdP, > that doesn't really help anyone. However, if we had a discovery > mechanism whereby a trustmark provider would be able to host a > machine-readable definition of what vectors a particular IdP has been > proven to be able to claim for any transaction, I think we've got a > good leg up on the problem. Yes: it's essential that we address the accreditation of the authentication and attribute providers in this structure. It's not clear that they're additional dimensions, though: a level 3 assertion from an entity that's only accredited at level 2 should probably just be treated at the lower level unless there's an indication of fraud. It's also possible that some providers might be accredited at different levels for different purposes: perhaps they have an accreditation at level 3 from the financial community, but only level 2 for health care. We need to consider that. -Jim --------------040400040708000208080101 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hi Justin,

Good kickoff!

On 10/2/14 2:10 PM, Richer, Justin P. wrote:

The first question is what vectors should there be? Embedded in this is how many there should be in the first place. Too few vectors and we end up with the overly-simplified and usually-misused problem that LoA has today. Too many vectors and we end up with an un-navigable set of values where everybody's niche concern is a special snowflake. We need to stay allergic to both cases and shoot for something "in the middle". In particular, my own personal gut instinct says we should shoot for 3 to 5 vectors. I'm going to propose 4 here, all of them linear scales. As a side note, it's a question whether all of these are even linear scales, but I think it's important that we define comparison metrics on each vector element as well as the overall values.

I'd suggest s/vectors/dimensions/

But what you're saying is that within each dimension, the relationships are well-ordered.



So what vectors should we have? The LoA definition in 800-63 gives us a few to work from as starting points, as well as some work that's been done in the UK.

A bit of history: 800-63 is a response to OMB M-04-04, which defined 4 levels of assurance. 800-63 is a response to the OMB document describing how each of the assurance levels should be achieved. During the 800-63-1 revision, there was some discussion about doing something different, particularly to support the NSTIC strategy's vision of separate identity and attribute providers. Also, it would have been a major change and it would have made it less clear how 800-63 is responsive to M-04-04, which is its primary official purpose. So a paragraph was added to the introduction (although it doesn't explicitly mention LoA):

Current government systems do not separate functions related to identity proofing in registration from credential issuance. In some applications, credentials (used in authentication) and attribute information (established through identity proofing) could be provided by different parties. While a simpler model is used in this document, it does not preclude agencies from separating these functions.





Identity proofing: 

This covers how sure the IdP is of various attributes about the user on the way in, and how much they're willing to vouch for those attributes. 

0: self-asserted / anonymous / randomized / no idea
1: consistent over time / pseudonymous
2: proofed in person
3: contractually bound

"consistent over time/pseudonymous" is probably also self-asserted.

I notice that you don't have a value for online identity proofing. Was that an intentional omission?

I'm curious what "contractually bound" is beyond in-person proofing.

Credential strength:

This covers how strongly bound the primary credential is to an individual presenter, and how easily spoofed or stolen it is.

0: no credential / public
1: shared secret / password
2: proof of key possession
3: multiple factors [and probably higher definitions here as well -- but we want to avoid all the little bespoke 2FA companies getting to define a special snowflake "credential strength" value or else this becomes useless]

Anything here about how the secret key is protected? How about bearer assertions like cookies?

Assertion presentation:

This covers how much the federation protocol leaks information over the network to various parties, and how much of that information could be tampered in transit without the RP noticing. 

0: no protection / leaky
1: signed & verifiable through browser
2: signed & verifiable through back channel
3: target-encrypted to RP's own key

3 seems like it's addressing a different problem (secrecy) rather than the verifiability of the assertion.


Operational management:

This covers a variety of information about the identity provider and its host organization. What's the OpSec policy of the IdP? Is there disaster recovery in place? How mature is the hosting organization? What kind of incident response can be expected? How strongly bound is a particular attribute to a particular credential [though maybe this fits under identity proofing]? You'll note that already this feels a lot less linear and a lot less defined than the other three.

It is probably a mistake to try and smush these back into a linear scale like LoA, since that's exactly what we're trying to get away from. However, it would probably be a good and enlightening exercise to map the existing LoA definitions into these vectors.

I think this is very important, to be able to use vectors of trust with legacy LOA-based systems. I made an effort to do a mapping like this a couple of years back, based on a somewhat different vector: http://www.slideshare.net/jim_fenton/nstic-loa (at slide 9).




Finally, I think we need to think about and discuss the notion of the assessment and trustmarks that would be powering the trust in all of these values. After all, if they're just self-asserted by the IdP, that doesn't really help anyone. However, if we had a discovery mechanism whereby a trustmark provider would be able to host a machine-readable definition of what vectors a particular IdP has been proven to be able to claim for any transaction, I think we've got a good leg up on the problem.

Yes: it's essential that we address the accreditation of the authentication and attribute providers in this structure. It's not clear that they're additional dimensions, though: a level 3 assertion from an entity that's only accredited at level 2 should probably just be treated at the lower level unless there's an indication of fraud. It's also possible that some providers might be accredited at different levels for different purposes: perhaps they have an accreditation at level 3 from the financial community, but only level 2 for health care.  We need to consider that.

-Jim
--------------040400040708000208080101-- From nobody Thu Oct 2 16:36:09 2014 Return-Path: X-Original-To: vot@ietfa.amsl.com Delivered-To: vot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3CB71ACFA0 for ; Thu, 2 Oct 2014 16:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cexe8D1SbLGX for ; Thu, 2 Oct 2014 16:36:05 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF4291ACF9C for ; Thu, 2 Oct 2014 16:36:04 -0700 (PDT) Received: by mail-la0-f42.google.com with SMTP id mk6so120565lab.29 for ; Thu, 02 Oct 2014 16:36:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Yhuc1vN5M2PBLN66io/+FDxBKqX2iaKIiQWygXTI2pY=; b=g06aoOReob7YlfxDDP4u+1NMR+OQexB69/jPpV5AauH0XBtKAAxGFXWHQt0qyOLV3k ZiprCXErnpYXCWw4zWnplGs/BM46mLTWfXB1yvLtw6Q7EDoGUyHU5UNhhildqfmH/oQd m1QckgLTw0zg5+6Rc58CBztJ5V97yh4y0DxpbT0ZnRqDQnSh6FJjo8KW0f04HopcGESt bTwjbWNIgrU+uHM+M+a9VuIZvIAsDb0vQoyRAiefDwngfQpFYzXbmlei84Fymy/1ndSh 3nXMe014XZWsdFsjZ+jwJvlD00bZqyGVn82nq1ukDC8QtZvHuFhKZoptEAOemrNa++5i ji/w== MIME-Version: 1.0 X-Received: by 10.112.140.137 with SMTP id rg9mr1574022lbb.93.1412292963056; Thu, 02 Oct 2014 16:36:03 -0700 (PDT) Received: by 10.112.166.10 with HTTP; Thu, 2 Oct 2014 16:36:03 -0700 (PDT) In-Reply-To: <542DCCA7.8070308@bluepopcorn.net> References: <42FAEF9E-37A4-4F3A-84C0-63C1FBC22EC6@mitre.org> <542DCCA7.8070308@bluepopcorn.net> Date: Fri, 3 Oct 2014 08:36:03 +0900 Message-ID: From: Nat Sakimura To: Jim Fenton Content-Type: multipart/alternative; boundary=001a11c2b34661c33605047914f0 Archived-At: http://mailarchive.ietf.org/arch/msg/vot/J3oXV9WC6lVluXpZkjcpefOdmt0 Cc: vot@ietf.org Subject: Re: [VoT] Vectors of Trust: A Strawman X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 23:36:08 -0000 --001a11c2b34661c33605047914f0 Content-Type: text/plain; charset=UTF-8 2014-10-03 7:07 GMT+09:00 Jim Fenton : > Hi Justin, > > Good kickoff! > +1 > > > On 10/2/14 2:10 PM, Richer, Justin P. wrote: > > > The first question is what vectors should there be? Embedded in this is > how many there should be in the first place. Too few vectors and we end up > with the overly-simplified and usually-misused problem that LoA has today. > Too many vectors and we end up with an un-navigable set of values where > everybody's niche concern is a special snowflake. We need to stay allergic > to both cases and shoot for something "in the middle". In particular, my > own personal gut instinct says we should shoot for 3 to 5 vectors. I'm > going to propose 4 here, all of them linear scales. As a side note, it's a > question whether all of these are even linear scales, but I think it's > important that we define comparison metrics on each vector element as well > as the overall values. > > > I'd suggest s/vectors/dimensions/ > > But what you're saying is that within each dimension, the relationships > are well-ordered. > > > > > So what vectors should we have? The LoA definition in 800-63 gives us a > few to work from as starting points, as well as some work that's been done > in the UK. > > > A bit of history: 800-63 is a response to OMB M-04-04, which defined 4 > levels of assurance. 800-63 is a response to the OMB document describing > how each of the assurance levels should be achieved. During the 800-63-1 > revision, there was some discussion about doing something different, > particularly to support the NSTIC strategy's vision of separate identity > and attribute providers. Also, it would have been a major change and it > would have made it less clear how 800-63 is responsive to M-04-04, which is > its primary official purpose. So a paragraph was added to the introduction > (although it doesn't explicitly mention LoA): > > Current government systems do not separate functions related to identity > proofing in registration from credential issuance. In some applications, > credentials (used in authentication) and attribute information (established > through identity proofing) could be provided by different parties. While a > simpler model is used in this document, it does not preclude agencies from > separating these functions. > > > > > > > *Identity proofing: * > > This covers how sure the IdP is of various attributes about the user on > the way in, and how much they're willing to vouch for those attributes. > > 0: self-asserted / anonymous / randomized / no idea > 1: consistent over time / pseudonymous > 2: proofed in person > 3: contractually bound > > > "consistent over time/pseudonymous" is probably also self-asserted. > Not sure about it. There can be pseudonymous - time consistent identifier which is based on well vetted core identity. A prime example is Austrian eID. A sector specific pseudonym is generated from LoA4 Qualified Certificate. > > I notice that you don't have a value for online identity proofing. Was > that an intentional omission? > Right. Also, having proofed in person / online and the assurance level of the proofing is kind of orthogonal. There are many cases of lousy in-person proofing, and there are cases of excellent online proofing. The same is true for the contractual binding. It depends on the quality of contract. OK. I am running out of time. I will respond to the below at a later time. Cheers, Nat > > I'm curious what "contractually bound" is beyond in-person proofing. > > > *Credential strength:* > > This covers how strongly bound the primary credential is to an > individual presenter, and how easily spoofed or stolen it is. > > 0: no credential / public > 1: shared secret / password > 2: proof of key possession > 3: multiple factors [and probably higher definitions here as well -- but > we want to avoid all the little bespoke 2FA companies getting to define a > special snowflake "credential strength" value or else this becomes useless] > > > Anything here about how the secret key is protected? How about bearer > assertions like cookies? > > > *Assertion presentation:* > > This covers how much the federation protocol leaks information over the > network to various parties, and how much of that information could be > tampered in transit without the RP noticing. > > 0: no protection / leaky > 1: signed & verifiable through browser > 2: signed & verifiable through back channel > 3: target-encrypted to RP's own key > > > 3 seems like it's addressing a different problem (secrecy) rather than the > verifiability of the assertion. > > > > > *Operational management:* > > This covers a variety of information about the identity provider and its > host organization. What's the OpSec policy of the IdP? Is there disaster > recovery in place? How mature is the hosting organization? What kind of > incident response can be expected? How strongly bound is a particular > attribute to a particular credential [though maybe this fits under identity > proofing]? You'll note that already this feels a lot less linear and a lot > less defined than the other three. > > > It is probably a mistake to try and smush these back into a linear scale > like LoA, since that's exactly what we're trying to get away from. However, > it would probably be a good and enlightening exercise to map the existing > LoA definitions into these vectors. > > > I think this is very important, to be able to use vectors of trust with > legacy LOA-based systems. I made an effort to do a mapping like this a > couple of years back, based on a somewhat different vector: > http://www.slideshare.net/jim_fenton/nstic-loa (at slide 9). > > > > > Finally, I think we need to think about and discuss the notion of the > assessment and trustmarks that would be powering the trust in all of these > values. After all, if they're just self-asserted by the IdP, that doesn't > really help anyone. However, if we had a discovery mechanism whereby a > trustmark provider would be able to host a machine-readable definition of > what vectors a particular IdP has been proven to be able to claim for any > transaction, I think we've got a good leg up on the problem. > > > Yes: it's essential that we address the accreditation of the > authentication and attribute providers in this structure. It's not clear > that they're additional dimensions, though: a level 3 assertion from an > entity that's only accredited at level 2 should probably just be treated at > the lower level unless there's an indication of fraud. It's also possible > that some providers might be accredited at different levels for different > purposes: perhaps they have an accreditation at level 3 from the financial > community, but only level 2 for health care. We need to consider that. > > -Jim > > _______________________________________________ > vot mailing list > vot@ietf.org > https://www.ietf.org/mailman/listinfo/vot > > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001a11c2b34661c33605047914f0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


2014-10-03 7:07 GMT+09:00 Jim Fenton <fenton@bluepopcorn.net&= gt;:
=20 =20 =20
Hi Justin,

Good kickoff!

+1
=C2=A0


On 10/2/14 2:10 PM, Richer, Justin P. wrote:
=20
The first question is what vectors should there be? Embedded in this is how many there should be in the first place. Too few vectors and we end up with the overly-simplified and usually-misused problem that LoA has today. Too many vectors and we end up with an un-navigable set of values where everybody's niche concern is a special snowflake. We need to stay allergic to both cases and shoot for something "in the middle". In particular, my own personal gut instinct says we should shoot for 3 to 5 vectors. I'm going to propose 4 here, all of them linear scales. As a side note, it's a question whether all of these are even linear scales, but I think it's important that w= e define comparison metrics on each vector element as well as the overall values.

 I'd suggest s/vectors/dimensions/

But what you're saying is that within each dimension, the relationships are well-ordered.



So what vectors should we have? The LoA definition in 800-63 gives us a few to work from as starting points, as well as some work that's been done in the UK.

 A bit of history: 800-63 is a response to OMB M-04-04, which defined 4 levels of assurance. 800-63 is a response to the OMB document describing how each of the assurance levels should be achieved. During the 800-63-1 revision, there was some discussion about doing something different, particularly to support the NSTIC strategy's vision of separate identity and attribute providers. Also, it would have been a major change and it would have made it less clear how 800-63 is responsive to M-04-04, which is its primary official purpose. So a paragraph was added to the introduction (although it doesn't explicitly mention LoA):

Current government systems do not separate functions related to identity proofing in registration from credential issuance. In some applications, credentials (used in authentication) and attribute information (established through identity proofing) could be provided by different parties. While a simpler model is used in this document, it does not preclude agencies from separating these functions.





Identity proofing:=C2=A0

This covers how sure the IdP is of various attributes about the user on the way in, and how much they're willing to vouch for those attributes.=C2=A0

0: self-asserted / anonymous / randomized / no idea
1: consistent over time / pseudonymous
2: proofed in person
3: contractually bound

 "consistent over time/pseudonymous" is probably also self-ass= erted.

Not sure about it. There c= an be pseudonymous - time consistent identifier which is based on well vett= ed core identity. A prime example is Austrian eID. A sector specific pseudo= nym is generated from LoA4 Qualified Certificate.=C2=A0
=C2=A0

I notice that you don't have a value for online identity proofing. Was that an intentional omission?

=
Right. Also, having proofed in person / online and the assurance level= of the proofing is kind of orthogonal. There are many cases of lousy in-pe= rson proofing, and there are cases of excellent online proofing.=C2=A0

The same is true for the contractual binding. It depen= ds on the quality of contract.=C2=A0

OK. I am runn= ing out of time. I will respond to the below at a later time.=C2=A0

Cheers,=C2=A0

Nat
=C2= =A0

I'm curious what "contractually bound" is beyond in-perso= n proofing.

Credential strength:

This covers how strongly bound the primary credential is to an individual presenter, and how easily spoofed or stolen it is.

0: no credential / public
1: shared secret / password
2: proof of key possession
3: multiple factors [and probably higher definitions here as well -- but we want to avoid all the little bespoke 2FA companies getting to define a special snowflake "credential strength" value or else this becomes useless]

 Anything here about how the secret key is protected? How about bearer assertions like cookies?

Assertion presentation:

This covers how much the federation protocol leaks information over the network to various parties, and how much of that information could be tampered in transit without the RP noticing.=C2=A0

0: no protection / leaky
1: signed & verifiable through browser
2: signed & verifiable through back channel
3: target-encrypted to RP's own key

 3 seems like it's addressing a different problem (secrecy) rather than the verifiability of the assertion.

=C2=A0



Operational management:

This covers a variety of information about the identity provider and its host organization. What's the OpSec policy of the IdP? Is there disaster recovery in place? How mature is the hosting organization? What kind of incident response can be expected? How strongly bound is a particular attribute to a particular credential [though maybe this fits under identity proofing]? You'll note that already this feels a lot less linea= r and a lot less defined than the other three.

It is probably a mistake to try and smush these back into a linear scale like LoA, since that's exactly what we're tryi= ng to get away from. However, it would probably be a good and enlightening exercise to map the existing LoA definitions into these vectors.

 I think this is very important, to be able to use vectors of trust with legacy LOA-based systems. I made an effort to do a mapping like this a couple of years back, based on a somewhat different vector: http://www.slideshare.net/jim_fenton/nstic-loa (at slide 9).




Finally, I think we need to think about and discuss the notion of the assessment and trustmarks that would be powering the trust in all of these values. After all, if they're just self-asserted by the IdP, that doesn't really help anyone. However, if we had a discovery mechanism whereby a trustmark provider would be able to host a machine-readable definition of what vectors a particular IdP has been proven to be able to claim for any transaction, I think we've got a good leg up on the problem.

Yes: it's essential that we address the accreditation of the authentication and attribute providers in this structure. It's not clear that they're additional dimensions, though: a level 3 assertion from an entity that's only accredited at level 2 should probably just be treated at the lower level unless there's an indication of fraud. It's also possible that some providers might b= e accredited at different levels for different purposes: perhaps they have an accreditation at level 3 from the financial community, but only level 2 for health care.=C2=A0 We need to consider that.

-Jim

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




--
Nat Saki= mura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
--001a11c2b34661c33605047914f0-- From nobody Thu Oct 2 17:20:55 2014 Return-Path: X-Original-To: vot@ietfa.amsl.com Delivered-To: vot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1BE1ACF58 for ; Thu, 2 Oct 2014 17:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CV9pJUzxG9ky for ; Thu, 2 Oct 2014 17:20:54 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E1BE1A8836 for ; Thu, 2 Oct 2014 17:20:54 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s930KmTI011482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 2 Oct 2014 17:20:51 -0700 Message-ID: <542DEBDD.2060408@dcrocker.net> Date: Thu, 02 Oct 2014 17:20:45 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Jim Fenton , vot@ietf.org References: <42FAEF9E-37A4-4F3A-84C0-63C1FBC22EC6@mitre.org> <542DCCA7.8070308@bluepopcorn.net> In-Reply-To: <542DCCA7.8070308@bluepopcorn.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Thu, 02 Oct 2014 17:20:51 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/vot/R0GAANFmPD3iAkY-hotLUTHI460 Subject: Re: [VoT] Vectors of Trust: A Strawman X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 00:20:55 -0000 On 10/2/2014 3:07 PM, Jim Fenton wrote: > I'd suggest s/vectors/dimensions/ I kept reading the message as saying vectors of thrust. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Oct 2 23:16:12 2014 Return-Path: X-Original-To: vot@ietfa.amsl.com Delivered-To: vot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C66A91A008B for ; Thu, 2 Oct 2014 23:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NtWFlqicgJfh for ; Thu, 2 Oct 2014 23:16:03 -0700 (PDT) Received: from mxout11.cac.washington.edu (mxout11.cac.washington.edu [140.142.32.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F2881A0081 for ; Thu, 2 Oct 2014 23:16:03 -0700 (PDT) Received: from uwit-hub10.exchange.washington.edu (uwit-hub10.exchange.washington.edu [128.95.155.53]) by mxout11.cac.washington.edu (8.14.4+UW14.03/8.14.4+UW14.04) with ESMTP id s936F9Io026168 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Thu, 2 Oct 2014 23:15:09 -0700 Received: from UWIT-EX2K13-01.mso.uw.edu (128.95.155.33) by uwit-hub10.exchange.washington.edu (128.95.155.53) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 2 Oct 2014 23:15:09 -0700 Received: from UWIT-EX2K13-01.mso.uw.edu (128.95.155.33) by uwit-ex2k13-01.mso.uw.edu (128.95.155.33) with Microsoft SMTP Server (TLS) id 15.0.847.32; Thu, 2 Oct 2014 23:15:08 -0700 Received: from na01-by2-obe.outbound.protection.outlook.com (207.46.163.236) by UWIT-EX2K13-01.mso.uw.edu (128.95.155.33) with Microsoft SMTP Server (TLS) id 15.0.847.32 via Frontend Transport; Thu, 2 Oct 2014 23:15:08 -0700 Received: from BL2PR08MB241.namprd08.prod.outlook.com (10.242.199.12) by BL2PR08MB242.namprd08.prod.outlook.com (10.242.199.23) with Microsoft SMTP Server (TLS) id 15.0.1044.10; Fri, 3 Oct 2014 06:15:06 +0000 Received: from BL2PR08MB241.namprd08.prod.outlook.com ([169.254.10.121]) by BL2PR08MB241.namprd08.prod.outlook.com ([169.254.10.121]) with mapi id 15.00.1044.008; Fri, 3 Oct 2014 06:15:06 +0000 From: Brian Arkills To: "vot@ietf.org" Thread-Topic: [VoT] Vectors of Trust: A Strawman Thread-Index: AQHP3oU+4p9DXTurHEG17GSReQzTfJwdXX+AgAB+crA= Date: Fri, 3 Oct 2014 06:15:06 +0000 Message-ID: <277b9fa8ed8945cd919531b64834bb24@BL2PR08MB241.namprd08.prod.outlook.com> References: <42FAEF9E-37A4-4F3A-84C0-63C1FBC22EC6@mitre.org> <542DCCA7.8070308@bluepopcorn.net> In-Reply-To: <542DCCA7.8070308@bluepopcorn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [216.254.31.77] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2PR08MB242; x-forefront-prvs: 0353563E2B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(189002)(199003)(86362001)(4396001)(551934003)(110136001)(89122001)(88552001)(19300405004)(19625215002)(19580395003)(15975445006)(16236675004)(21056001)(561944003)(122386001)(97736003)(46102003)(74316001)(95666004)(90282001)(80022003)(2501002)(92566001)(85306004)(75432002)(64706001)(77096002)(106116001)(107046002)(20776003)(120916001)(106356001)(105586002)(76176999)(101416001)(108616004)(54356999)(50986999)(107886001)(33646002)(66066001)(76482002)(87936001)(99396003)(551544002)(85852003)(76576001)(2656002)(15202345003)(99286002)(10300001)(2351001)(31966008)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2PR08MB242; H:BL2PR08MB241.namprd08.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_277b9fa8ed8945cd919531b64834bb24BL2PR08MB241namprd08pro_" MIME-Version: 1.0 X-OriginatorOrg: uw.edu X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.10.3.60321 X-PMX-Server: mxout11.cac.washington.edu X-Uwash-Spam: Gauge=XI, Probability=11%, Report=' TO_IN_SUBJECT 0.5, HTML_50_70 0.1, RCVD_FROM_IP_DATE 0.1, SUPERLONG_LINE 0.05, BODYTEXTH_SIZE_10000_LESS 0, BODY_SIZE_10000_PLUS 0, ECARD_WORD 0, FROM_EDU_TLD 0, NO_URI_FOUND 0, SPF_NEUTRAL 0, WEBMAIL_SOURCE 0, WEBMAIL_XOIP 0, WEBMAIL_X_IP_HDR 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, __HAS_FROM 0, __HAS_HTML 0, __HAS_MSGID 0, __HAS_XOIP 0, __HTML_FONT_BLUE 0, __IN_REP_TO 0, __MIME_HTML 0, __MIME_VERSION 0, __SANE_MSGID 0, __STYLE_RATWARE_NEG 0, __SUBJ_ALPHA_END 0, __SUBJ_ALPHA_NEGATE 0, __TAG_EXISTS_HTML 0, __TO_IN_SUBJECT 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0' Archived-At: http://mailarchive.ietf.org/arch/msg/vot/jzHF_AwEOsNCbuy4zjOqaLZDeOw Subject: Re: [VoT] Vectors of Trust: A Strawman X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 06:16:08 -0000 --_000_277b9fa8ed8945cd919531b64834bb24BL2PR08MB241namprd08pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [BA] First, thanks a ton for putting this list together and hoisting a stra= wman to kick things off. I think a lot of people have been thinking about t= he ways in which the existing LoA fall short, and I'm glad to see a constru= ctive effort at moving things forward. :) I've got a couple initial responses to parts of the proposal below ... Credential strength: This covers how strongly bound the primary credential is to an individual p= resenter, and how easily spoofed or stolen it is. 0: no credential / public 1: shared secret / password 2: proof of key possession 3: multiple factors [and probably higher definitions here as well -- but we= want to avoid all the little bespoke 2FA companies getting to define a spe= cial snowflake "credential strength" value or else this becomes useless] Anything here about how the secret key is protected? How about bearer asser= tions like cookies? [BA] One of the stated aims of this vector is to reflect how easy it is to = steal the credential, but none of the values really represent that aspect. = One of the biggest security stories right now, the plethora of retailers wi= th credit card breaches over the past year, seem to share several common el= ements, one of which involves leveraging the NTLM pass the hash credential = replay. And if you've been following the NTLM pass the hash replay stuff, y= ou'll have taken note of the fact that enabling 2 factor on a given account= doesn't mitigate it at all. Of course, that replay is first dependent on c= ompromising a system which has the desired credential, but the fact that a = replay attack is part of the underlying credential design might mean your s= core should be lower here. You might have mitigations in place which partia= lly or totally neutralize that, in which case your score should be less aff= ected. I'm not yet sure how you'd represent this complexity in a better way= via the suggested description for the values but I did want to call this o= ut so better minds than mine could ponder it. :) Operational management: This covers a variety of information about the identity provider and its ho= st organization. What's the OpSec policy of the IdP? Is there disaster reco= very in place? How mature is the hosting organization? What kind of inciden= t response can be expected? How strongly bound is a particular attribute to= a particular credential [though maybe this fits under identity proofing]? = You'll note that already this feels a lot less linear and a lot less define= d than the other three. [BA] It seems that the operational management vector has intersections/over= laps with some of the other vectors, but maybe that's just imagined on my p= art. If the operators of the component allow their cert to expire that affe= cts some of the other vectors. Likewise, if they have very strong administr= ative practices, perhaps the credential strength is better than another pro= vider using the same technologies. I'm struggling with whether I think it's= good to represent this as a separate vector or if this is just an aspect w= hich influences the other vectors. Finally, I think we need to think about and discuss the notion of the asses= sment and trustmarks that would be powering the trust in all of these value= s. After all, if they're just self-asserted by the IdP, that doesn't really= help anyone. However, if we had a discovery mechanism whereby a trustmark = provider would be able to host a machine-readable definition of what vector= s a particular IdP has been proven to be able to claim for any transaction,= I think we've got a good leg up on the problem. Yes: it's essential that we address the accreditation of the authentication= and attribute providers in this structure. It's not clear that they're add= itional dimensions, though: a level 3 assertion from an entity that's only = accredited at level 2 should probably just be treated at the lower level un= less there's an indication of fraud. It's also possible that some providers= might be accredited at different levels for different purposes: perhaps th= ey have an accreditation at level 3 from the financial community, but only = level 2 for health care. We need to consider that. [BA] I also wonder about vectors of trust in chained assertion scenarios. Y= ou assert X, then I assert X based on your assertion (and my evaluation of = your assertion). Or do I somehow encapsulate your assertion inside mine and= consuming apps know how to deal with this? Does the assertion's strength c= hange when I assert it (or encapsulate it) based on who I am? Brian Arkills University of Washington --_000_277b9fa8ed8945cd919531b64834bb24BL2PR08MB241namprd08pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

[BA] First, thanks a ton for put= ting this list together and hoisting a strawman to kick things off. I think= a lot of people have been thinking about the ways in which the existing Lo= A fall short, and I’m glad to see a constructive effort at moving things forward. J

 

I’ve got a co= uple initial responses to parts of the proposal below …

 

Credential strength:

 

This covers how strongly bound the primary credentia= l is to an individual presenter, and how easily spoofed or stolen it is.

 

0: no credential / public

1: shared secret / password

2: proof of key possession

3: multiple factors [and probably higher definitions= here as well -- but we want to avoid all the little bespoke 2FA companies = getting to define a special snowflake "credential strength" value= or else this becomes useless]


Anything here about how the secret key is protected? How about bearer asser= tions like cookies?

[BA] One of the sta= ted aims of this vector is to reflect how easy it is to steal the credentia= l, but none of the values really represent that aspect. One of the biggest security stories right now, the plethora of retailers w= ith credit card breaches over the past year, seem to share several common e= lements, one of which involves leveraging the NTLM pass the hash credential= replay. And if you’ve been following the NTLM pass the hash replay stuff, you’ll have taken note of the f= act that enabling 2 factor on a given account doesn’t mitigate it at = all. Of course, that replay is first dependent on compromising a system whi= ch has the desired credential, but the fact that a replay attack is part of the underlying credential design might mea= n your score should be lower here. You might have mitigations in place whic= h partially or totally neutralize that, in which case your score should be = less affected. I’m not yet sure how you’d represent this complexity in a better way via the suggeste= d description for the values but I did want to call this out so better mind= s than mine could ponder it. J

 

Operational management:

 

This covers a variety of information about the ident= ity provider and its host organization. What's the OpSec policy of the IdP?= Is there disaster recovery in place? How mature is the hosting organizatio= n? What kind of incident response can be expected? How strongly bound is a particular attribute to a particu= lar credential [though maybe this fits under identity proofing]? You'll not= e that already this feels a lot less linear and a lot less defined than the= other three.

 

[BA] It seems that = the operational management vector has intersections/overlaps with some of t= he other vectors, but maybe that’s just imagined on my part. If the operators of the component allow their cert to expire that affects = some of the other vectors. Likewise, if they have very strong administrativ= e practices, perhaps the credential strength is better than another provide= r using the same technologies. I’m struggling with whether I think it’s good to represent this as a sep= arate vector or if this is just an aspect which influences the other vector= s.

 

Finally, I think we need to think about and discuss = the notion of the assessment and trustmarks that would be powering the trus= t in all of these values. After all, if they're just self-asserted by the I= dP, that doesn't really help anyone. However, if we had a discovery mechanism whereby a trustmark provider woul= d be able to host a machine-readable definition of what vectors a particula= r IdP has been proven to be able to claim for any transaction, I think we'v= e got a good leg up on the problem.


Yes: it's essential that we address the accreditation of the authentication= and attribute providers in this structure. It's not clear that they're add= itional dimensions, though: a level 3 assertion from an entity that's only = accredited at level 2 should probably just be treated at the lower level unless there's an indication of fraud. = It's also possible that some providers might be accredited at different lev= els for different purposes: perhaps they have an accreditation at level 3 f= rom the financial community, but only level 2 for health care.  We need to consider that.

[BA] I also wonder = about vectors of trust in chained assertion scenarios. You assert X, then I= assert X based on your assertion (and my evaluation of your assertion). Or do I somehow encapsulate your assertion inside mine an= d consuming apps know how to deal with this? Does the assertion’s str= ength change when I assert it (or encapsulate it) based on who I am?

 

Brian Arkills<= /o:p>

University of Washi= ngton

--_000_277b9fa8ed8945cd919531b64834bb24BL2PR08MB241namprd08pro_-- From nobody Thu Oct 2 23:27:51 2014 Return-Path: X-Original-To: vot@ietfa.amsl.com Delivered-To: vot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55B6A1A1BA4 for ; Thu, 2 Oct 2014 23:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.557 X-Spam-Level: X-Spam-Status: No, score=-1.557 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.786, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5p0d26DAy_Vp for ; Thu, 2 Oct 2014 23:27:47 -0700 (PDT) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (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 1E27E1A00C0 for ; Thu, 2 Oct 2014 23:27:46 -0700 (PDT) Received: from smtp1.sunet.se (smtp1.sunet.se [IPv6:2001:6b0:8:2::214]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id s936Ri11013276 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 3 Oct 2014 08:27:44 +0200 Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.7/8.14.7) with ESMTP id s936RfSC024411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 3 Oct 2014 08:27:44 +0200 (CEST) X-Footer: c3VuZXQuc2U= Received: from [193.10.94.39] ([193.10.94.39]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.2.4) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128 bits)) for vot@ietf.org; Fri, 3 Oct 2014 08:27:40 +0200 Message-ID: <542E41DC.6000701@sunet.se> Date: Fri, 03 Oct 2014 08:27:40 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: vot@ietf.org References: <42FAEF9E-37A4-4F3A-84C0-63C1FBC22EC6@mitre.org> <542DCCA7.8070308@bluepopcorn.net> <542DEBDD.2060408@dcrocker.net> In-Reply-To: <542DEBDD.2060408@dcrocker.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sunet-se:default, sunet-se:default, base:default, @@RPTN) X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=62.0000; longitude=15.0000; http://maps.google.com/maps?q=62.0000,15.0000&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 09MWurIOG - 8e15d937e77d - 20141003 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/vot/ZVVAP4DOOgyPg0cEf8Hwm7fSTAA Subject: Re: [VoT] Vectors of Trust: A Strawman X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 06:27:49 -0000 On 2014-10-03 02:20, Dave Crocker wrote: > On 10/2/2014 3:07 PM, Jim Fenton wrote: >> I'd suggest s/vectors/dimensions/ > > > I kept reading the message as saying vectors of thrust. > > d/ > It can be that too if you let it. From nobody Fri Oct 3 12:57:47 2014 Return-Path: X-Original-To: vot@ietfa.amsl.com Delivered-To: vot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24C6F1A88E1 for ; Fri, 3 Oct 2014 12:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.335 X-Spam-Level: ** X-Spam-Status: No, score=2.335 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DATE_IN_PAST_03_06=1.592, GB_I_LETTER=-2, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, TVD_PH_BODY_ACCOUNTS_PRE=2.393] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFSTasq7HnlJ for ; Fri, 3 Oct 2014 12:57:43 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9C571A88DF for ; Fri, 3 Oct 2014 12:57:42 -0700 (PDT) Received: from [195.50.142.210] (helo=[172.29.10.161]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84) (envelope-from ) id 1Xa8yv-0007lK-Ua; Fri, 03 Oct 2014 21:57:40 +0200 Content-Type: multipart/alternative; boundary=Apple-Mail-3F7D32ED-4087-4E37-93C4-1C0BE3481E13 Content-Transfer-Encoding: 7bit References: <42FAEF9E-37A4-4F3A-84C0-63C1FBC22EC6@mitre.org> From: Rainer Hoerbe In-Reply-To: <42FAEF9E-37A4-4F3A-84C0-63C1FBC22EC6@mitre.org> Message-Id: <578DFE15-222E-4C19-9E69-691F36EC42E0@hoerbe.at> Date: Fri, 3 Oct 2014 17:42:27 +0200 To: "Richer, Justin P." Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (12A405) X-Df-Sender: cmFpbmVyQGhvZXJiZS5hdA== Archived-At: http://mailarchive.ietf.org/arch/msg/vot/IXhERogeeRiV1oOCQKCWP1xDeM0 Cc: "vot@ietf.org" Subject: Re: [VoT] Vectors of Trust: A Strawman X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 19:57:47 -0000 --Apple-Mail-3F7D32ED-4087-4E37-93C4-1C0BE3481E13 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable A few observations: The scope of the VoT straw man is similar to 800-63: controls to mitigate an= RP's risk of identifying remote entities, limited to confidentiality and in= tegrity. Some risks are excluded, such as availability, binding strength bet= ween subject and session, the user's risk. This is fine, but it should be ma= de explicit that VoT does not cover all trust aspects between RP, user and I= AM infrastructure.=20 IMU the purpose of VoT is to allow more flexibility in mapping legacy and fu= ture RP policies to a common identity infrastructure (?). LoA being too infl= exible, the controls shall be split into non-overlapping areas/vectors that f= eature linear scales again.=20 In my experience from some mapping exercises I doubt, however, that linear s= cales will work at the level of IPV or credential strength. Some gross examp= les are remote IPV and KBA allowed LoA3 in the US, or SMS as 2nd factor at l= evel 4 in some European states. BTW the new EU payment services directive is= quite specific about the strengths and independence of factors for internet= banking from 2015 onwards.=20 =46rom a risk management perspective the prescription of controls is risk mi= tigation, which is one of several options. In commercial settings, at least,= risk transfer is much simpler, because the risk will be equated with a mone= y value, not with a set of controls. Enforcing specific controls is only ne= cessary where legally required, e.g. by AML regulations. Therefore, outside h= ighly regulated areas, liability and insurance arrangements are much more po= werful means to take out complexity from identity assurance.=20 Another point is, that since the invention of ISMSs the management system an= d risk management methodology are the leading concepts, whereas lists of con= trols are secondary. Considering that risk assessment in the enterprisy appr= oach is not feasible in a federated world, the reduction of risk to an amoun= t per login etc. should be investigated as an alternative method.=20 For the remaining set of controls (that cannot be taken care of with liabili= ty) I have been proposing a bottom-up approach instead of top-down. Standard= izing on a more granular level will not allow easy mapping at an LoA/VoT le= vel, which is likely to fail because of differing requirements; OTOH it shou= ld allow for an efficient partial mapping. That in turn can help IDPs to ide= ntify what additional measures would have to be implemented to serve new RPs= .=20 Rainer > Cought we could take it. There was a pretty consistent notion that LoA as c= urrently defined provides a handy shortcut but is usually insufficient and m= ore often than not is grossly misused.=20 >=20 > With that in mind, I would like to kick off this mailing list with a straw= man proposal for an alternative: Vectors of Trust. The core idea here is to f= actor out different aspects of what goes into the LoA calculation today and p= resent them as orthogonal vectors. These vectors would need to be communicat= ed in various protocols and environments. We would also need to have a way o= f describing (and perhaps cataloguing) certain sets of vector values into a s= ingle reference to be used in things like trust frameworks. >=20 >=20 >=20 > The first question is what vectors should there be? Embedded in this is ho= w many there should be in the first place. Too few vectors and we end up wit= h the overly-simplified and usually-misused problem that LoA has today. Too m= any vectors and we end up with an un-navigable set of values where everybody= 's niche concern is a special snowflake. We need to stay allergic to both ca= ses and shoot for something "in the middle". In particular, my own personal g= ut instinct says we should shoot for 3 to 5 vectors. I'm going to propose 4 h= ere, all of them linear scales. As a side note, it's a question whether all o= f these are even linear scales, but I think it's important that we define co= mparison metrics on each vector element as well as the overall values. >=20 >=20 >=20 > So what vectors should we have? The LoA definition in 800-63 gives us a fe= w to work from as starting points, as well as some work that's been done in t= he UK. These were captured from the discussion in the Utrecht meeting: >=20 > Identity proofing:=20 >=20 > This covers how sure the IdP is of various attributes about the user on th= e way in, and how much they're willing to vouch for those attributes.=20 >=20 > 0: self-asserted / anonymous / randomized / no idea > 1: consistent over time / pseudonymous > 2: proofed in person > 3: contractually bound >=20 > Credential strength: >=20 > This covers how strongly bound the primary credential is to an individual p= resenter, and how easily spoofed or stolen it is. >=20 > 0: no credential / public > 1: shared secret / password > 2: proof of key possession > 3: multiple factors [and probably higher definitions here as well -- but w= e want to avoid all the little bespoke 2FA companies getting to define a spe= cial snowflake "credential strength" value or else this becomes useless] >=20 > Assertion presentation: >=20 > This covers how much the federation protocol leaks information over the ne= twork to various parties, and how much of that information could be tampered= in transit without the RP noticing.=20 >=20 > 0: no protection / leaky > 1: signed & verifiable through browser > 2: signed & verifiable through back channel > 3: target-encrypted to RP's own key >=20 > Operational management: >=20 > This covers a variety of information about the identity provider and its h= ost organization. What's the OpSec policy of the IdP? Is there disaster reco= very in place? How mature is the hosting organization? What kind of incident= response can be expected? How strongly bound is a particular attribute to a= particular credential [though maybe this fits under identity proofing]? You= 'll note that already this feels a lot less linear and a lot less defined th= an the other three.=20 >=20 >=20 >=20 > Next we need a way to combine and communicate these vectors across the wir= e. I propose a simple method of assigning each category a marker letter and e= ach value within the category a numeric value, and combining them with a sep= arator, such as: >=20 > pseudonymous, multi-factor, strong assertion =3D P1:C3:A2 >=20 > It's compact and unambiguous, though it's not really making use of any exi= sting data structures languages like JSON. But I think there does need to be= a simple and parseable means to convey this info. This way, clients that ne= ed information on a particular category can pull it out and ignore the other= s. We can present structures like this (especially if they serialize into st= rings like this example) as part of the assertions in a variety of protocols= . Say you've got an OpenID Connect access token, you can add a "vot" member t= o the payload with "I1:C3:A2" as its value. Clients can parse or ignore this= as they see fit. >=20 >=20 > Next, I think we need a good way to label and categorize these combined ve= ctors, especially as exemplary use cases. A handful of examples from my own d= eployment experience: >=20 > P3:C2:A1 - OpenID 2.0 account provided to current employees and protected b= y domain password >=20 > P1:C3:A2 - OpenID Connect account from dynamically introduced IdP bound to= a medical record in an out-of-band process >=20 > P3:C3:A3 - Cross-domain OpenID Connect pilot (with contracts connecting th= e two orgs to enforce the semantics) >=20 > It is probably a mistake to try and smush these back into a linear scale l= ike LoA, since that's exactly what we're trying to get away from. However, i= t would probably be a good and enlightening exercise to map the existing LoA= definitions into these vectors. >=20 >=20 >=20 > Finally, I think we need to think about and discuss the notion of the asse= ssment and trustmarks that would be powering the trust in all of these value= s. After all, if they're just self-asserted by the IdP, that doesn't really h= elp anyone. However, if we had a discovery mechanism whereby a trustmark pro= vider would be able to host a machine-readable definition of what vectors a p= articular IdP has been proven to be able to claim for any transaction, I thi= nk we've got a good leg up on the problem. First off, it would need to be di= scoverable from the IdP, so I'm proposing we add a component to the discover= y document. An OIDC example: >=20 > { > "iss": "https://idp.example.org/", > "trustmark": "https://trustmark-provider.org/csp-123412" > ... > } >=20 > The URI given in this document would contain information about which vecto= rs the IdP is allowed to claim, according to the trustmark provider: >=20 > { > "iss": "https://idp.example.org/", > "P": [3], > "C": [1, 2, 3], > "A": [2, 3], > "O": [1, 4] > } >=20 > Paranoid clients and clients dealing with many IdPs across an ecosystem wo= uld be able to grab the service discovery doc (step 1, and they probably nee= d it anyway) and then checking with a trusted third party, the trustmark pro= vider, if the IdP is on the up-and-up. If a client gets a claim for a vector= value that's not attested to by a known/trusted trustmark provider, it can c= all shenanigans.=20 >=20 >=20 >=20 > This is far from comprehensive, but I think this is a fairly decent strawm= an to start with. So let's burn this down and see what's left. Be sure to in= vite your friends to the bonfire! >=20 > -- Justin > _______________________________________________ > vot mailing list > vot@ietf.org > https://www.ietf.org/mailman/listinfo/vot --Apple-Mail-3F7D32ED-4087-4E37-93C4-1C0BE3481E13 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
A few obs= ervations:

The scope of the VoT straw man is s= imilar to 800-63: controls to mitigate an RP's risk of identifying remote en= tities, limited to confidentiality and integrity. Some risks are excluded, s= uch as availability, binding strength between subject and session, the user'= s risk. This is fine, but it should be made explicit that VoT does not cover= all trust aspects between RP, user and IAM infrastructure. 
=
IMU the purpose of VoT is to allow more flexibility in mappin= g legacy and future RP policies to a common identity infrastructure (?). LoA= being too inflexible, the controls shall be split into non-overlapping area= s/vectors that feature linear scales again. 
In my experience= from some mapping exercises I doubt, however, that linear scales will work a= t the level of IPV or credential strength. Some gross examples are remote IP= V and KBA allowed LoA3 in the US, or SMS as 2nd factor at level 4 in some Eu= ropean states. BTW the new EU payment services directive is quite specific a= bout the strengths and independence of factors for internet banking from 201= 5 onwards. 

=46rom a risk management perspecti= ve the prescription of controls is risk mitigation, which is one of several o= ptions. In commercial settings, at least, risk transfer is much simpler, bec= ause the risk will be equated with a money value, not with a set of controls= .  Enforcing specific controls is only necessary where legally required= , e.g. by AML regulations. Therefore, outside highly regulated areas, liabil= ity and insurance arrangements are much more powerful means to take out comp= lexity from identity assurance. 

Another point= is, that since the invention of ISMSs the management system and risk manage= ment methodology are the leading concepts, whereas lists of controls are sec= ondary. Considering that risk assessment in the enterprisy approach is not f= easible in a federated world, the reduction of risk to an amount per login e= tc. should be investigated as an alternative method. 

For the remaining set of controls (that cannot be taken care of with= liability) I have been proposing a bottom-up approach instead of top-down. S= tandardizing on a more granular level  will not allow easy mapping at a= n LoA/VoT level, which is likely to fail because of differing requirements; O= TOH it should allow for an efficient partial mapping. That in turn can help I= DPs to identify what additional measures would have to be implemented to ser= ve new RPs. 

Rainer
Cought we could take it.= There was a pretty consistent notion that LoA as currently defined provides= a handy shortcut but is usually insufficient and more often than not is grossly misused. 

With that in mind, I would like to kick off this mailing list with a st= rawman proposal for an alternative: Vectors of Trust. The core idea here is t= o factor out different aspects of what goes into the LoA calculation today a= nd present them as orthogonal vectors. These vectors would need to be communicated in various protocols a= nd environments. We would also need to have a way of describing (and perhaps= cataloguing) certain sets of vector values into a single reference to be us= ed in things like trust frameworks.



The first question is what vectors should there be? Embedded in this is= how many there should be in the first place. Too few vectors and we end up w= ith the overly-simplified and usually-misused problem that LoA has today. To= o many vectors and we end up with an un-navigable set of values where everybody's niche concern is a spe= cial snowflake. We need to stay allergic to both cases and shoot for somethi= ng "in the middle". In particular, my own personal gut instinct says we shou= ld shoot for 3 to 5 vectors. I'm going to propose 4 here, all of them linear scales. As a side note, it'= s a question whether all of these are even linear scales, but I think it's i= mportant that we define comparison metrics on each vector element as well as= the overall values.



So what vectors should we have? The LoA definition in 800-63 gives us a= few to work from as starting points, as well as some work that's been done i= n the UK. These were captured from the discussion in the Utrecht meeting:

Identity proofing: 

This covers how sure the IdP is of various attributes about the user on= the way in, and how much they're willing to vouch for those attributes.&nbs= p;

0: self-asserted / anonymous / randomized / no idea
1: consistent over time / pseudonymous
2: proofed in person
3: contractually bound

Credential strength:

This covers how strongly bound the primary credential is to an individu= al presenter, and how easily spoofed or stolen it is.

0: no credential / public
1: shared secret / password
2: proof of key possession
3: multiple factors [and probably higher definitions here as well -- bu= t we want to avoid all the little bespoke 2FA companies getting to define a s= pecial snowflake "credential strength" value or else this becomes useless]

Assertion presentation:

This covers how much the federation protocol leaks information over the= network to various parties, and how much of that information could be tampe= red in transit without the RP noticing. 

0: no protection / leaky
1: signed & verifiable through browser
2: signed & verifiable through back channel
3: target-encrypted to RP's own key

Operational management:

This covers a variety of information about the identity provider and it= s host organization. What's the OpSec policy of the IdP? Is there disaster r= ecovery in place? How mature is the hosting organization? What kind of incid= ent response can be expected? How strongly bound is a particular attribute to a particular credential [th= ough maybe this fits under identity proofing]? You'll note that already this= feels a lot less linear and a lot less defined than the other three. <= /div>



Next we need a way to combine and communicate these vectors across the w= ire. I propose a simple method of assigning each category a marker letter an= d each value within the category a numeric value, and combining them with a s= eparator, such as:

  pseudonymous, multi-factor, strong assertion =3D P1:C3:A2

It's compact and unambiguous, though it's not really making use of any e= xisting data structures languages like JSON. But I think there does need to b= e a simple and parseable means to convey this info. This way, clients that n= eed information on a particular category can pull it out and ignore the others. We can present structures l= ike this (especially if they serialize into strings like this example) as pa= rt of the assertions in a variety of protocols. Say you've got an OpenID Con= nect access token, you can add a "vot" member to the payload with "I1:C3:A2" as its value. Clients can par= se or ignore this as they see fit.


Next, I think we need a good way to label and categorize these combined= vectors, especially as exemplary use cases. A handful of examples from my o= wn deployment experience:

P3:C2:A1 - OpenID 2.0 account provided to current employees and protect= ed by domain password

P1:C3:A2 - OpenID Connect account from dynamically introduced IdP bound= to a medical record in an out-of-band process

P3:C3:A3 - Cross-domain OpenID Connect pilot (with contracts connecting= the two orgs to enforce the semantics)

It is probably a mistake to try and smush these back into a linear scal= e like LoA, since that's exactly what we're trying to get away from. However= , it would probably be a good and enlightening exercise to map the existing L= oA definitions into these vectors.



Finally, I think we need to think about and discuss the notion of the a= ssessment and trustmarks that would be powering the trust in all of these va= lues. After all, if they're just self-asserted by the IdP, that doesn't real= ly help anyone. However, if we had a discovery mechanism whereby a trustmark provider would be able to hos= t a machine-readable definition of what vectors a particular IdP has been pr= oven to be able to claim for any transaction, I think we've got a good leg u= p on the problem. First off, it would need to be discoverable from the IdP, so I'm proposing we add a co= mponent to the discovery document. An OIDC example:

{
  ...
}

The URI given in this document would contain information about which ve= ctors the IdP is allowed to claim, according to the trustmark provider:

{
  "P": [3],
  "C": [1, 2, 3],
  "A": [2, 3],
  "O": [1, 4]
}

Paranoid clients and clients dealing with many IdPs across an ecosystem= would be able to grab the service discovery doc (step 1, and they probably n= eed it anyway) and then checking with a trusted third party, the trustmark p= rovider, if the IdP is on the up-and-up. If a client gets a claim for a vector value that's not attested t= o by a known/trusted trustmark provider, it can call shenanigans. 



This is far from comprehensive, but I think this is a fairly decent str= awman to start with. So let's burn this down and see what's left. Be sure to= invite your friends to the bonfire!

 -- Justin
____________________= ___________________________
vot mailing list
vot@ietf.org
https://www.ietf.org/mailman/lis= tinfo/vot
= --Apple-Mail-3F7D32ED-4087-4E37-93C4-1C0BE3481E13-- From nobody Mon Oct 6 07:23:44 2014 Return-Path: X-Original-To: vot@ietfa.amsl.com Delivered-To: vot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62EAB1A030A for ; Mon, 6 Oct 2014 07:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.015 X-Spam-Level: X-Spam-Status: No, score=0.015 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7oxoKkJOi5F for ; Mon, 6 Oct 2014 07:23:39 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id 4D38C1A0303 for ; Mon, 6 Oct 2014 07:23:39 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D51423AE01F; Mon, 6 Oct 2014 10:23:38 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id CA41D3AE06E; Mon, 6 Oct 2014 10:23:38 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.195]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.03.0174.001; Mon, 6 Oct 2014 10:23:38 -0400 From: "Richer, Justin P." To: Brian Arkills Thread-Topic: [VoT] Vectors of Trust: A Strawman Thread-Index: AQHP3oU+4p9DXTurHEG17GSReQzTfJwdoI6AgACINQCABT98gA== Date: Mon, 6 Oct 2014 14:23:37 +0000 Message-ID: <82008C35-9F54-4E07-A0F6-FD0AF4BEF263@mitre.org> References: <42FAEF9E-37A4-4F3A-84C0-63C1FBC22EC6@mitre.org> <542DCCA7.8070308@bluepopcorn.net> <277b9fa8ed8945cd919531b64834bb24@BL2PR08MB241.namprd08.prod.outlook.com> In-Reply-To: <277b9fa8ed8945cd919531b64834bb24@BL2PR08MB241.namprd08.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.15.56] Content-Type: multipart/alternative; boundary="_000_82008C359F544E07A0F6FD0AF4BEF263mitreorg_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/vot/qS2C6QjMRhoG6wC_z6NoPfzYvbk Cc: "vot@ietf.org" Subject: Re: [VoT] Vectors of Trust: A Strawman X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 14:23:42 -0000 --_000_82008C359F544E07A0F6FD0AF4BEF263mitreorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable [BA] It seems that the operational management vector has intersections/over= laps with some of the other vectors, but maybe that=92s just imagined on my= part. If the operators of the component allow their cert to expire that af= fects some of the other vectors. Likewise, if they have very strong adminis= trative practices, perhaps the credential strength is better than another p= rovider using the same technologies. I=92m struggling with whether I think = it=92s good to represent this as a separate vector or if this is just an as= pect which influences the other vectors. I agree that it's definitely different from the others, and originally I on= ly had the other three listed. The conversation in Utrecht had a lot of inp= ut into this though. I think an important metric might be "what do I care about this at runtime"= ? There are things in this space (like "disaster recovery") that an RP coul= d be able to discover ahead of time using a trust framework or assessor typ= e of setup (the last point in the strawman), but they're not going to ever = change on a per-transaction or per-user basis. Other items like credential = strength and proofing might be different each time though, depending on the= population of users being served. -- Justin On Oct 3, 2014, at 2:15 AM, Brian Arkills > wrote: [BA] First, thanks a ton for putting this list together and hoisting a stra= wman to kick things off. I think a lot of people have been thinking about t= he ways in which the existing LoA fall short, and I=92m glad to see a const= ructive effort at moving things forward. :) I=92ve got a couple initial responses to parts of the proposal below =85 Credential strength: This covers how strongly bound the primary credential is to an individual p= resenter, and how easily spoofed or stolen it is. 0: no credential / public 1: shared secret / password 2: proof of key possession 3: multiple factors [and probably higher definitions here as well -- but we= want to avoid all the little bespoke 2FA companies getting to define a spe= cial snowflake "credential strength" value or else this becomes useless] Anything here about how the secret key is protected? How about bearer asser= tions like cookies? [BA] One of the stated aims of this vector is to reflect how easy it is to = steal the credential, but none of the values really represent that aspect. = One of the biggest security stories right now, the plethora of retailers wi= th credit card breaches over the past year, seem to share several common el= ements, one of which involves leveraging the NTLM pass the hash credential = replay. And if you=92ve been following the NTLM pass the hash replay stuff,= you=92ll have taken note of the fact that enabling 2 factor on a given acc= ount doesn=92t mitigate it at all. Of course, that replay is first dependen= t on compromising a system which has the desired credential, but the fact t= hat a replay attack is part of the underlying credential design might mean = your score should be lower here. You might have mitigations in place which = partially or totally neutralize that, in which case your score should be le= ss affected. I=92m not yet sure how you=92d represent this complexity in a = better way via the suggested description for the values but I did want to c= all this out so better minds than mine could ponder it. :) Operational management: This covers a variety of information about the identity provider and its ho= st organization. What's the OpSec policy of the IdP? Is there disaster reco= very in place? How mature is the hosting organization? What kind of inciden= t response can be expected? How strongly bound is a particular attribute to= a particular credential [though maybe this fits under identity proofing]? = You'll note that already this feels a lot less linear and a lot less define= d than the other three. [BA] It seems that the operational management vector has intersections/over= laps with some of the other vectors, but maybe that=92s just imagined on my= part. If the operators of the component allow their cert to expire that af= fects some of the other vectors. Likewise, if they have very strong adminis= trative practices, perhaps the credential strength is better than another p= rovider using the same technologies. I=92m struggling with whether I think = it=92s good to represent this as a separate vector or if this is just an as= pect which influences the other vectors. Finally, I think we need to think about and discuss the notion of the asses= sment and trustmarks that would be powering the trust in all of these value= s. After all, if they're just self-asserted by the IdP, that doesn't really= help anyone. However, if we had a discovery mechanism whereby a trustmark = provider would be able to host a machine-readable definition of what vector= s a particular IdP has been proven to be able to claim for any transaction,= I think we've got a good leg up on the problem. Yes: it's essential that we address the accreditation of the authentication= and attribute providers in this structure. It's not clear that they're add= itional dimensions, though: a level 3 assertion from an entity that's only = accredited at level 2 should probably just be treated at the lower level un= less there's an indication of fraud. It's also possible that some providers= might be accredited at different levels for different purposes: perhaps th= ey have an accreditation at level 3 from the financial community, but only = level 2 for health care. We need to consider that. [BA] I also wonder about vectors of trust in chained assertion scenarios. Y= ou assert X, then I assert X based on your assertion (and my evaluation of = your assertion). Or do I somehow encapsulate your assertion inside mine and= consuming apps know how to deal with this? Does the assertion=92s strength= change when I assert it (or encapsulate it) based on who I am? Brian Arkills University of Washington _______________________________________________ vot mailing list vot@ietf.org https://www.ietf.org/mailman/listinfo/vot --_000_82008C359F544E07A0F6FD0AF4BEF263mitreorg_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

[BA] It seems that the operational management vector= has intersections/overlaps with some of the other vectors, but maybe that= =92s just imagined on my part. If the operators of the component allow their cert to expire that affects some of= the other vectors. Likewise, if they have very strong administrative pract= ices, perhaps the credential strength is better than another provider using= the same technologies. I=92m struggling with whether I think it=92s good to represent this as a separate vector or= if this is just an aspect which influences the other vectors.

I agree that it's definitely different from the others, and originally= I only had the other three listed. The conversation in Utrecht had a lot o= f input into this though.

I think an important metric might be "what do I care about this a= t runtime"? There are things in this space (like "disaster recove= ry") that an RP could be able to discover ahead of time using a trust = framework or assessor type of setup (the last point in the strawman), but they're not going to ever change on a per-transactio= n or per-user basis. Other items like credential strength and proofing migh= t be different each time though, depending on the population of users being= served.

 -- Justin



On Oct 3, 2014, at 2:15 AM, Brian Arkills <barkills@uw.edu> wrote:

[BA] First, thanks a ton for put= ting this list together and hoisting a strawman to kick things off. I think= a lot of people have been thinking about the ways in which the existing Lo= A fall short, and I=92m glad to see a constructive effort at moving things forward. J

 

I=92ve got a couple= initial responses to parts of the proposal below =85

 

Credential strength:

 

This covers how strongly bound the primary credentia= l is to an individual presenter, and how easily spoofed or stolen it is.

 

0: no credential / public

1: shared secret / password

2: proof of key possession

3: multiple factors [and probably higher definitions= here as well -- but we want to avoid all the little bespoke 2FA companies = getting to define a special snowflake "credential strength" value= or else this becomes useless]


Anything here about how the secret key is protected? How about bearer asser= tions like cookies?

[BA] One of the sta= ted aims of this vector is to reflect how easy it is to steal the credentia= l, but none of the values really represent that aspect. One of the biggest security stories right now, the plethora of retailers w= ith credit card breaches over the past year, seem to share several common e= lements, one of which involves leveraging the NTLM pass the hash credential= replay. And if you=92ve been following the NTLM pass the hash replay stuff, you=92ll have taken note of the fact = that enabling 2 factor on a given account doesn=92t mitigate it at all. Of = course, that replay is first dependent on compromising a system which has t= he desired credential, but the fact that a replay attack is part of the underlying credential design might mea= n your score should be lower here. You might have mitigations in place whic= h partially or totally neutralize that, in which case your score should be = less affected. I=92m not yet sure how you=92d represent this complexity in a better way via the suggested de= scription for the values but I did want to call this out so better minds th= an mine could ponder it. J

 

Operational management:

 

This covers a variety of information about the ident= ity provider and its host organization. What's the OpSec policy of the IdP?= Is there disaster recovery in place? How mature is the hosting organizatio= n? What kind of incident response can be expected? How strongly bound is a particular attribute to a particu= lar credential [though maybe this fits under identity proofing]? You'll not= e that already this feels a lot less linear and a lot less defined than the= other three.

 

[BA] It seems that = the operational management vector has intersections/overlaps with some of t= he other vectors, but maybe that=92s just imagined on my part. If the operators of the component allow their cert to expire that affects = some of the other vectors. Likewise, if they have very strong administrativ= e practices, perhaps the credential strength is better than another provide= r using the same technologies. I=92m struggling with whether I think it=92s good to represent this as a separat= e vector or if this is just an aspect which influences the other vectors.

 

Finally, I think we need to think about and discuss = the notion of the assessment and trustmarks that would be powering the trus= t in all of these values. After all, if they're just self-asserted by the I= dP, that doesn't really help anyone. However, if we had a discovery mechanism whereby a trustmark provider woul= d be able to host a machine-readable definition of what vectors a particula= r IdP has been proven to be able to claim for any transaction, I think we'v= e got a good leg up on the problem.


Yes: it's essential that we address the accreditation of the authentication= and attribute providers in this structure. It's not clear that they're add= itional dimensions, though: a level 3 assertion from an entity that's only = accredited at level 2 should probably just be treated at the lower level unless there's an indication of fraud. = It's also possible that some providers might be accredited at different lev= els for different purposes: perhaps they have an accreditation at level 3 f= rom the financial community, but only level 2 for health care.  We need to consider that.

[BA] I also wonder = about vectors of trust in chained assertion scenarios. You assert X, then I= assert X based on your assertion (and my evaluation of your assertion). Or do I somehow encapsulate your assertion inside mine an= d consuming apps know how to deal with this? Does the assertion=92s strengt= h change when I assert it (or encapsulate it) based on who I am?=

 

Brian Arkills<= /o:p>

University of Washi= ngton

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

--_000_82008C359F544E07A0F6FD0AF4BEF263mitreorg_-- From nobody Mon Oct 6 21:41:52 2014 Return-Path: X-Original-To: vot@ietfa.amsl.com Delivered-To: vot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04AEE1A9128 for ; Mon, 6 Oct 2014 21:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9wlmlK-Xv7F for ; Mon, 6 Oct 2014 21:41:43 -0700 (PDT) Received: from smtp1.csc.fi (smtp1.csc.fi [IPv6:2001:708:10:6004::14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BFF11A9125 for ; Mon, 6 Oct 2014 21:41:41 -0700 (PDT) Received: from tapir.csc.fi (tapir.csc.fi [86.50.27.201]) by smtp1.csc.fi (8.14.3/8.14.3/CSC) with ESMTP id s974fd6V006526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Oct 2014 07:41:39 +0300 Received: from tapir.csc.fi (localhost [127.0.0.1]) by tapir.csc.fi (Postfix) with ESMTPS id 1BE33BFA24; Tue, 7 Oct 2014 07:41:39 +0300 (EEST) Received: from localhost (localhost [127.0.0.1]) by tapir.csc.fi (Postfix) with ESMTP id 0EC8DBFA23; Tue, 7 Oct 2014 07:41:39 +0300 (EEST) Received: from tapir.csc.fi ([127.0.0.1]) by localhost (tapir.csc.fi [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id BMX3xiwHTjsL; Tue, 7 Oct 2014 07:41:38 +0300 (EEST) Received: from zebra.csc.fi (zebra.csc.fi [86.50.27.101]) by tapir.csc.fi (Postfix) with ESMTP id EB88BBFA22; Tue, 7 Oct 2014 07:41:38 +0300 (EEST) From: Mikael Linden To: "Richer, Justin P." , "Brian Arkills" References: <42FAEF9E-37A4-4F3A-84C0-63C1FBC22EC6@mitre.org> <542DCCA7.8070308@bluepopcorn.net> <277b9fa8ed8945cd919531b64834bb24@BL2PR08MB241.namprd08.prod.outlook.com> <82008C35-9F54-4E07-A0F6-FD0AF4BEF263@mitre.org> In-Reply-To: <82008C35-9F54-4E07-A0F6-FD0AF4BEF263@mitre.org> Date: Tue, 7 Oct 2014 07:41:38 +0300 (EEST) Message-ID: <35fb02f6.00001b38.0000000c@MLINDEN-X220.windows.csc.fi> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00BD_01CFE202.1EAAB670" X-Mailer: Microsoft Outlook 15.0 X-Mailer: Zimbra 8.5.0_GA_3047 (ZimbraConnectorForOutlook/8.0.6.1063) Content-Language: fi Thread-Index: a+vvD3Xi5fKFW1yLhicYulPn8Rx3RQ== X-Originating-IP: [77.95.242.33] Thread-Topic: Vectors of Trust: A Strawman X-CanIt-Geo: ip=86.50.27.201; country=FI; latitude=64.0000; longitude=26.0000; http://maps.google.com/maps?q=64.0000,26.0000&z=6 X-CanItPRO-Stream: 00_Opt_Out (inherits from default) X-Scanned-By: CanIt (www . roaringpenguin . com) on 86.50.27.145 Archived-At: http://mailarchive.ietf.org/arch/msg/vot/gGyY7gZJ1BHASBGKkkfVB-ThoxE Cc: vot@ietf.org Subject: Re: [VoT] Vectors of Trust: A Strawman X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 04:41:50 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00BD_01CFE202.1EAAB670 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit >There are things in this space (like "disaster recovery") that an RP could be able to discover ahead of time using a trust framework or assessor type of setup (the last point in the strawman), CERN and the grid folks are pushing a framework for incident handling in federations (A Security Incident Response Trust Framework for Federated Identity -- Sir-T-Fi). They would like to have some assurance that the IdP admin is reactive (answers to mail, phone etc.) when an RP has faced an incident and needs the IdP's co-operation to resolve it. Is this another dimension for VoT? Cheers, mikael From: vot [mailto:vot-bounces@ietf.org] On Behalf Of Richer, Justin P. Sent: 6. lokakuuta 2014 17:24 To: Brian Arkills Cc: vot@ietf.org Subject: Re: [VoT] Vectors of Trust: A Strawman [BA] It seems that the operational management vector has intersections/overlaps with some of the other vectors, but maybe that's just imagined on my part. If the operators of the component allow their cert to expire that affects some of the other vectors. Likewise, if they have very strong administrative practices, perhaps the credential strength is better than another provider using the same technologies. I'm struggling with whether I think it's good to represent this as a separate vector or if this is just an aspect which influences the other vectors. I agree that it's definitely different from the others, and originally I only had the other three listed. The conversation in Utrecht had a lot of input into this though. I think an important metric might be "what do I care about this at runtime"? There are things in this space (like "disaster recovery") that an RP could be able to discover ahead of time using a trust framework or assessor type of setup (the last point in the strawman), but they're not going to ever change on a per-transaction or per-user basis. Other items like credential strength and proofing might be different each time though, depending on the population of users being served. -- Justin On Oct 3, 2014, at 2:15 AM, Brian Arkills > wrote: [BA] First, thanks a ton for putting this list together and hoisting a strawman to kick things off. I think a lot of people have been thinking about the ways in which the existing LoA fall short, and I'm glad to see a constructive effort at moving things forward. :) I've got a couple initial responses to parts of the proposal below . Credential strength: This covers how strongly bound the primary credential is to an individual presenter, and how easily spoofed or stolen it is. 0: no credential / public 1: shared secret / password 2: proof of key possession 3: multiple factors [and probably higher definitions here as well -- but we want to avoid all the little bespoke 2FA companies getting to define a special snowflake "credential strength" value or else this becomes useless] Anything here about how the secret key is protected? How about bearer assertions like cookies? [BA] One of the stated aims of this vector is to reflect how easy it is to steal the credential, but none of the values really represent that aspect. One of the biggest security stories right now, the plethora of retailers with credit card breaches over the past year, seem to share several common elements, one of which involves leveraging the NTLM pass the hash credential replay. And if you've been following the NTLM pass the hash replay stuff, you'll have taken note of the fact that enabling 2 factor on a given account doesn't mitigate it at all. Of course, that replay is first dependent on compromising a system which has the desired credential, but the fact that a replay attack is part of the underlying credential design might mean your score should be lower here. You might have mitigations in place which partially or totally neutralize that, in which case your score should be less affected. I'm not yet sure how you'd represent this complexity in a better way via the suggested description for the values but I did want to call this out so better minds than mine could ponder it. :) Operational management: This covers a variety of information about the identity provider and its host organization. What's the OpSec policy of the IdP? Is there disaster recovery in place? How mature is the hosting organization? What kind of incident response can be expected? How strongly bound is a particular attribute to a particular credential [though maybe this fits under identity proofing]? You'll note that already this feels a lot less linear and a lot less defined than the other three. [BA] It seems that the operational management vector has intersections/overlaps with some of the other vectors, but maybe that's just imagined on my part. If the operators of the component allow their cert to expire that affects some of the other vectors. Likewise, if they have very strong administrative practices, perhaps the credential strength is better than another provider using the same technologies. I'm struggling with whether I think it's good to represent this as a separate vector or if this is just an aspect which influences the other vectors. Finally, I think we need to think about and discuss the notion of the assessment and trustmarks that would be powering the trust in all of these values. After all, if they're just self-asserted by the IdP, that doesn't really help anyone. However, if we had a discovery mechanism whereby a trustmark provider would be able to host a machine-readable definition of what vectors a particular IdP has been proven to be able to claim for any transaction, I think we've got a good leg up on the problem. Yes: it's essential that we address the accreditation of the authentication and attribute providers in this structure. It's not clear that they're additional dimensions, though: a level 3 assertion from an entity that's only accredited at level 2 should probably just be treated at the lower level unless there's an indication of fraud. It's also possible that some providers might be accredited at different levels for different purposes: perhaps they have an accreditation at level 3 from the financial community, but only level 2 for health care. We need to consider that. [BA] I also wonder about vectors of trust in chained assertion scenarios. You assert X, then I assert X based on your assertion (and my evaluation of your assertion). Or do I somehow encapsulate your assertion inside mine and consuming apps know how to deal with this? Does the assertion's strength change when I assert it (or encapsulate it) based on who I am? Brian Arkills University of Washington _______________________________________________ vot mailing list vot@ietf.org https://www.ietf.org/mailman/listinfo/vot ------=_NextPart_000_00BD_01CFE202.1EAAB670 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

>There = are things in this space (like "disaster recovery") that an RP = could be able to discover ahead of time using a trust framework or = assessor type of setup (the last point in the = strawman),

 

CERN and the grid folks are pushing a framework for = incident handling in federations (A Security Incident Response Trust =

Framework for Federated Identity -- = Sir-T-Fi). They would like to have some assurance that the IdP admin is = reactive (answers to mail, phone etc…) when an RP has faced an = incident and needs the IdP’s co-operation to resolve it. =

 

Is this another dimension for VoT?

 

Cheers,

mikael

 

From: vot [mailto:vot-bounces@ietf.org] On Behalf Of Richer, = Justin P.
Sent: 6. lokakuuta 2014 17:24
To: Brian = Arkills
Cc: vot@ietf.org
Subject: Re: [VoT] Vectors = of Trust: A Strawman

 

 

[BA] It seems that the operational management vector has = intersections/overlaps with some of the other vectors, but maybe = that’s just imagined on my part. If the operators of the component = allow their cert to expire that affects some of the other vectors. = Likewise, if they have very strong administrative practices, perhaps the = credential strength is better than another provider using the same = technologies. I’m struggling with whether I think it’s good = to represent this as a separate vector or if this is just an aspect = which influences the other = vectors.

 

I agree that it's definitely different from the = others, and originally I only had the other three listed. The = conversation in Utrecht had a lot of input into this = though.

 

I = think an important metric might be "what do I care about this at = runtime"? There are things in this space (like "disaster = recovery") that an RP could be able to discover ahead of time using = a trust framework or assessor type of setup (the last point in the = strawman), but they're not going to ever change on a per-transaction or = per-user basis. Other items like credential strength and proofing might = be different each time though, depending on the population of users = being served.

 

 -- Justin

 

 

 

On = Oct 3, 2014, at 2:15 AM, Brian Arkills <barkills@uw.edu> = wrote:



[BA] First, thanks a = ton for putting this list together and hoisting a strawman to kick = things off. I think a lot of people have been thinking about the ways in = which the existing LoA fall short, and I’m glad to see a = constructive effort at moving things forward. J

=

 

I’ve got a = couple initial responses to parts of the proposal below … =

 

Credential strength:

 

This covers how strongly bound the primary credential = is to an individual presenter, and how easily spoofed or stolen it = is.

 

0: no credential / public

1: shared secret / = password

2: proof of key = possession

3: multiple = factors [and probably higher definitions here as well -- but we want to = avoid all the little bespoke 2FA companies getting to define a special = snowflake "credential strength" value or else this becomes = useless]


Anything here = about how the secret key is protected? How about bearer assertions like = cookies?


[BA] One of the stated aims of this vector is to reflect how easy it = is to steal the credential, but none of the values really represent that = aspect. One of the biggest security stories right now, the plethora of = retailers with credit card breaches over the past year, seem to share = several common elements, one of which involves leveraging the NTLM pass = the hash credential replay. And if you’ve been following the NTLM = pass the hash replay stuff, you’ll have taken note of the fact = that enabling 2 factor on a given account doesn’t mitigate it at = all. Of course, that replay is first dependent on compromising a system = which has the desired credential, but the fact that a replay attack is = part of the underlying credential design might mean your score should be = lower here. You might have mitigations in place which partially or = totally neutralize that, in which case your score should be less = affected. I’m not yet sure how you’d represent this = complexity in a better way via the suggested description for the values = but I did want to call this out so better minds than mine could ponder = it. J

 

Operational = management:

 

This covers a variety of information about the = identity provider and its host organization. What's the OpSec policy of = the IdP? Is there disaster recovery in place? How mature is the hosting = organization? What kind of incident response can be expected? How = strongly bound is a particular attribute to a particular credential = [though maybe this fits under identity proofing]? You'll note that = already this feels a lot less linear and a lot less defined than the = other three.

 

[BA] It seems that the operational management vector has = intersections/overlaps with some of the other vectors, but maybe = that’s just imagined on my part. If the operators of the component = allow their cert to expire that affects some of the other vectors. = Likewise, if they have very strong administrative practices, perhaps the = credential strength is better than another provider using the same = technologies. I’m struggling with whether I think it’s good = to represent this as a separate vector or if this is just an aspect = which influences the other vectors.

 

Finally, I think we need to think about and discuss = the notion of the assessment and trustmarks that would be powering the = trust in all of these values. After all, if they're just self-asserted = by the IdP, that doesn't really help anyone. However, if we had a = discovery mechanism whereby a trustmark provider would be able to host a = machine-readable definition of what vectors a particular IdP has been = proven to be able to claim for any transaction, I think we've got a good = leg up on the problem.


Yes: it's essential that we address the = accreditation of the authentication and attribute providers in this = structure. It's not clear that they're additional dimensions, though: a = level 3 assertion from an entity that's only accredited at level 2 = should probably just be treated at the lower level unless there's an = indication of fraud. It's also possible that some providers might be = accredited at different levels for different purposes: perhaps they have = an accreditation at level 3 from the financial community, but only level = 2 for health care.  We need to consider = that.


[BA] I also wonder about vectors of trust in chained assertion = scenarios. You assert X, then I assert X based on your assertion (and my = evaluation of your assertion). Or do I somehow encapsulate your = assertion inside mine and consuming apps know how to deal with this? = Does the assertion’s strength change when I assert it (or = encapsulate it) based on who I am?

 

Brian Arkills

University of Washington

______________________________________________= _
vot mailing list
vot@ietf.org
https://www.ietf.org/m= ailman/listinfo/vot

 

------=_NextPart_000_00BD_01CFE202.1EAAB670-- From nobody Thu Oct 9 09:11:22 2014 Return-Path: X-Original-To: vot@ietfa.amsl.com Delivered-To: vot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 183891AD044 for ; Thu, 9 Oct 2014 09:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.123 X-Spam-Level: X-Spam-Status: No, score=0.123 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxYQI8xBDY_s for ; Thu, 9 Oct 2014 09:11:15 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F3B61AD000 for ; Thu, 9 Oct 2014 09:11:13 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id m15so1735489wgh.14 for ; Thu, 09 Oct 2014 09:11:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=Ra0S2+XtMN+FxR5NZ1YKhmD6THONx27LpHBuwmqiz7g=; b=kAG1TTos6jDf0OSdYI/cOPAISE28RMAMsSYRObLXMguGosMcsqBU/qRLfn1uZwmHNh LOclk1W7AySyn3DS7rDLPdz9husKwplmQ5R9Jr3wh8iDfgze6B95v98D4D1wqA0KNr9g A7T3cpqxLYOCiQDBJOlHiVl28yBgvx0j7npLuJSg76HjS1wL2qbyHrtwk3JIN3Tx82gZ 5D0j00h+ASp4xjetM8Knpv8Nyf52EJ/Sx8kaUTIAa0LoSl9lh0Yyg9z9flY5n18wel6k jxaDWaqG7ZW9hbRaXFhkjpFfb+f4KBHttYh8wra2xNgifQp1uWPh3dq8Js/qzG37r783 ak4A== X-Received: by 10.181.12.14 with SMTP id em14mr5432320wid.9.1412871071988; Thu, 09 Oct 2014 09:11:11 -0700 (PDT) MIME-Version: 1.0 Sender: jonibrennan@gmail.com Received: by 10.216.113.74 with HTTP; Thu, 9 Oct 2014 09:10:40 -0700 (PDT) In-Reply-To: <35fb02f6.00001b38.0000000c@MLINDEN-X220.windows.csc.fi> References: <42FAEF9E-37A4-4F3A-84C0-63C1FBC22EC6@mitre.org> <542DCCA7.8070308@bluepopcorn.net> <277b9fa8ed8945cd919531b64834bb24@BL2PR08MB241.namprd08.prod.outlook.com> <82008C35-9F54-4E07-A0F6-FD0AF4BEF263@mitre.org> <35fb02f6.00001b38.0000000c@MLINDEN-X220.windows.csc.fi> From: Joni Brennan Date: Thu, 9 Oct 2014 09:10:40 -0700 X-Google-Sender-Auth: neA3IDs5aso5kAlzF1iy3QH0y0s Message-ID: To: Mikael Linden Content-Type: multipart/alternative; boundary=f46d04388e695c06550504ffae9f Archived-At: http://mailarchive.ietf.org/arch/msg/vot/gviux3YOE3Q-NNeFOKOduM2b-Ac Cc: Brian Arkills , "Richer, Justin P." , vot@ietf.org Subject: Re: [VoT] Vectors of Trust: A Strawman X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 16:11:20 -0000 --f46d04388e695c06550504ffae9f Content-Type: text/plain; charset=ISO-8859-1 This has been a great thread. I will spend more time to respond more deeply... I suggest that incident response could be very reasonable for a VoT. Ideally we are not specifying the "how" but that there is a process with reasonable rigor in place. best, - Joni Best Regards, Joni Brennan Kantara Initiative | Executive Director voice:+1 732-266-8994 email: joni @ kantarainitiative.org Connecting Identity for a more trustworthy Internet - Overview On Mon, Oct 6, 2014 at 9:41 PM, Mikael Linden wrote: > >There are things in this space (like "disaster recovery") that an RP > could be able to discover ahead of time using a trust framework or assessor > type of setup (the last point in the strawman), > > > > CERN and the grid folks are pushing a framework for incident handling in > federations (A Security Incident Response Trust > > Framework for Federated Identity -- Sir-T-Fi). They would like to have > some assurance that the IdP admin is reactive (answers to mail, phone etc...) > when an RP has faced an incident and needs the IdP's co-operation to > resolve it. > > > > Is this another dimension for VoT? > > > > Cheers, > > mikael > > > > *From:* vot [mailto:vot-bounces@ietf.org] *On Behalf Of *Richer, Justin P. > *Sent:* 6. lokakuuta 2014 17:24 > *To:* Brian Arkills > *Cc:* vot@ietf.org > *Subject:* Re: [VoT] Vectors of Trust: A Strawman > > > > > > *[BA] It seems that the operational management vector has > intersections/overlaps with some of the other vectors, but maybe that's > just imagined on my part. If the operators of the component allow their > cert to expire that affects some of the other vectors. Likewise, if they > have very strong administrative practices, perhaps the credential strength > is better than another provider using the same technologies. I'm struggling > with whether I think it's good to represent this as a separate vector or if > this is just an aspect which influences the other vectors.* > > > > I agree that it's definitely different from the others, and originally I > only had the other three listed. The conversation in Utrecht had a lot of > input into this though. > > > > I think an important metric might be "what do I care about this at > runtime"? There are things in this space (like "disaster recovery") that an > RP could be able to discover ahead of time using a trust framework or > assessor type of setup (the last point in the strawman), but they're not > going to ever change on a per-transaction or per-user basis. Other items > like credential strength and proofing might be different each time though, > depending on the population of users being served. > > > > -- Justin > > > > > > > > On Oct 3, 2014, at 2:15 AM, Brian Arkills wrote: > > > > *[BA] **First, thanks a ton for putting this list together and hoisting a > strawman to kick things off. I think a lot of people have been thinking > about the ways in which the existing LoA fall short, and I'm glad to see a > constructive effort at moving things forward. **J* > > > > *I've got a couple initial responses to parts of the proposal below ... * > > > > *Credential strength:* > > > > This covers how strongly bound the primary credential is to an individual > presenter, and how easily spoofed or stolen it is. > > > > 0: no credential / public > > 1: shared secret / password > > 2: proof of key possession > > 3: multiple factors [and probably higher definitions here as well -- but > we want to avoid all the little bespoke 2FA companies getting to define a > special snowflake "credential strength" value or else this becomes useless] > > > Anything here about how the secret key is protected? How about bearer > assertions like cookies? > > > *[BA] One of the stated aims of this vector is to reflect how easy it is > to steal the credential, but none of the values really represent that > aspect. One of the biggest security stories right now, the plethora of > retailers with credit card breaches over the past year, seem to share > several common elements, one of which involves leveraging the NTLM pass the > hash credential replay. And if you've been following the NTLM pass the hash > replay stuff, you'll have taken note of the fact that enabling 2 factor on > a given account doesn't mitigate it at all. Of course, that replay is first > dependent on compromising a system which has the desired credential, but > the fact that a replay attack is part of the underlying credential design > might mean your score should be lower here. You might have mitigations in > place which partially or totally neutralize that, in which case your score > should be less affected. I'm not yet sure how you'd represent this > complexity in a better way via the suggested description for the values but > I did want to call this out so better minds than mine could ponder it. * > *J* > > > > *Operational management:* > > > > This covers a variety of information about the identity provider and its > host organization. What's the OpSec policy of the IdP? Is there disaster > recovery in place? How mature is the hosting organization? What kind of > incident response can be expected? How strongly bound is a particular > attribute to a particular credential [though maybe this fits under identity > proofing]? You'll note that already this feels a lot less linear and a lot > less defined than the other three. > > > > *[BA] It seems that the operational management vector has > intersections/overlaps with some of the other vectors, but maybe that's > just imagined on my part. If the operators of the component allow their > cert to expire that affects some of the other vectors. Likewise, if they > have very strong administrative practices, perhaps the credential strength > is better than another provider using the same technologies. I'm struggling > with whether I think it's good to represent this as a separate vector or if > this is just an aspect which influences the other vectors.* > > > > Finally, I think we need to think about and discuss the notion of the > assessment and trustmarks that would be powering the trust in all of these > values. After all, if they're just self-asserted by the IdP, that doesn't > really help anyone. However, if we had a discovery mechanism whereby a > trustmark provider would be able to host a machine-readable definition of > what vectors a particular IdP has been proven to be able to claim for any > transaction, I think we've got a good leg up on the problem. > > > Yes: it's essential that we address the accreditation of the > authentication and attribute providers in this structure. It's not clear > that they're additional dimensions, though: a level 3 assertion from an > entity that's only accredited at level 2 should probably just be treated at > the lower level unless there's an indication of fraud. It's also possible > that some providers might be accredited at different levels for different > purposes: perhaps they have an accreditation at level 3 from the financial > community, but only level 2 for health care. We need to consider that. > > > *[BA] I also wonder about vectors of trust in chained assertion scenarios. > You assert X, then I assert X based on your assertion (and my evaluation of > your assertion). Or do I somehow encapsulate your assertion inside mine and > consuming apps know how to deal with this? Does the assertion's strength > change when I assert it (or encapsulate it) based on who I am?* > > > > *Brian Arkills* > > *University of Washington* > > _______________________________________________ > vot mailing list > vot@ietf.org > https://www.ietf.org/mailman/listinfo/vot > > > > _______________________________________________ > vot mailing list > vot@ietf.org > https://www.ietf.org/mailman/listinfo/vot > > --f46d04388e695c06550504ffae9f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This has been a great thread.  I will spend= more time to respond more deeply... 

I suggest that incident = response could be very reasonable for a VoT.  Ideally we are not speci= fying the "how" but that there is a process with reasonable rigor= in place.

best,
- Joni

Best Regards,
=

Joni Brennan
Kantara Initiative | Executive Dire= ctor
voice:+1 732-266-8994
email: joni @ kantarainitiative.org

Conne= cting Identity for a more trustworthy Internet - Overview




On Mon, Oct 6, 2014 at 9:41 PM, Mikael Linde= n <mikael.linden@csc.fi> wrote:

>There are things in this space (like &quo= t;disaster recovery") that an RP could be able to discover ahead of ti= me using a trust framework or assessor type of setup (the last point in the= strawman),

 

CERN and the grid folks are pushing a framew= ork for incident handling in federations (A Security Incident Response Trus= t

Framework for Federated Identity= -- Sir-T-Fi). They would like to have some assurance that the IdP admin is= reactive (answers to mail, phone etc…) when an RP has faced an inci= dent and needs the IdP’s co-operation to resolve it.

 

Is = this another dimension for VoT?

=  

Cheers,

mikael

 

From: vot [mailto:vot-bounces@ietf.org] On Behalf Of Richer, Justin P.Sent: 6. lokakuuta 2014 17:24
To: Brian Arkills
Cc:= vot@ietf.org
= Subject: Re: [VoT] Vectors of Trust: A Strawman=

 =

 

[BA] It seems that the ope= rational management vector has intersections/overlaps with some of the othe= r vectors, but maybe that’s just imagined on my part. If the operator= s of the component allow their cert to expire that affects some of the othe= r vectors. Likewise, if they have very strong administrative practices, per= haps the credential strength is better than another provider using the same= technologies. I’m struggling with whether I think it’s good to= represent this as a separate vector or if this is just an aspect which inf= luences the other vectors.

 

I agree that it's definitely different from t= he others, and originally I only had the other three listed. The conversati= on in Utrecht had a lot of input into this though.

<= div>

 

I think an important metric might be "what do I care about t= his at runtime"? There are things in this space (like "disaster r= ecovery") that an RP could be able to discover ahead of time using a t= rust framework or assessor type of setup (the last point in the strawman), = but they're not going to ever change on a per-transaction or per-user b= asis. Other items like credential strength and proofing might be different = each time though, depending on the population of users being served.=

 

=

 -- Justin

 

 

 

On Oct 3, 2014, at 2:15 AM, Brian Ark= ills <barkills@uw.e= du> wrote:



=

<= div>

[BA] First, thanks a ton for putting this = list together and hoisting a strawman to kick things off. I think a lot of = people have been thinking about the ways in which the existing LoA fall sho= rt, and I’m glad to see a constructive effort at moving things forwar= d. J

 

I’ve got a couple initial responses to parts of = the proposal below …

 

Credential strength:

 

This covers how strongly bound the primary credential is to an individual= presenter, and how easily spoofed or stolen it is.

=

 

0: no credential / public

1: shared secret / password

2: proof of key possession

<= p class=3D"MsoNormal">3: multiple factors [and probably higher definitions = here as well -- but we want to avoid all the little bespoke 2FA companies g= etting to define a special snowflake "credential strength" value = or else this becomes useless]


Anything here about how the secret key is protected? How about bearer = assertions like cookies?


[BA] One of the stated aims of this vect= or is to reflect how easy it is to steal the credential, but none of the va= lues really represent that aspect. One of the biggest security stories righ= t now, the plethora of retailers with credit card breaches over the past ye= ar, seem to share several common elements, one of which involves leveraging= the NTLM pass the hash credential replay. And if you’ve been followi= ng the NTLM pass the hash replay stuff, you’ll have taken note of the= fact that enabling 2 factor on a given account doesn’t mitigate it a= t all. Of course, that replay is first dependent on compromising a system w= hich has the desired credential, but the fact that a replay attack is part = of the underlying credential design might mean your score should be lower h= ere. You might have mitigations in place which partially or totally neutral= ize that, in which case your score should be less affected. I’m not y= et sure how you’d represent this complexity in a better way via the s= uggested description for the values but I did want to call this out so bett= er minds than mine could ponder it. J<= u>

<= p class=3D"MsoNormal"> 

Operational management:

 

This = covers a variety of information about the identity provider and its host or= ganization. What's the OpSec policy of the IdP? Is there disaster recov= ery in place? How mature is the hosting organization? What kind of incident= response can be expected? How strongly bound is a particular attribute to = a particular credential [though maybe this fits under identity proofing]? Y= ou'll note that already this feels a lot less linear and a lot less def= ined than the other three.

 

[BA] It seems that th= e operational management vector has intersections/overlaps with some of the= other vectors, but maybe that’s just imagined on my part. If the ope= rators of the component allow their cert to expire that affects some of the= other vectors. Likewise, if they have very strong administrative practices= , perhaps the credential strength is better than another provider using the= same technologies. I’m struggling with whether I think it’s go= od to represent this as a separate vector or if this is just an aspect whic= h influences the other vectors.

 

Finally, I think we need to= think about and discuss the notion of the assessment and trustmarks that w= ould be powering the trust in all of these values. After all, if they'r= e just self-asserted by the IdP, that doesn't really help anyone. Howev= er, if we had a discovery mechanism whereby a trustmark provider would be a= ble to host a machine-readable definition of what vectors a particular IdP = has been proven to be able to claim for any transaction, I think we've = got a good leg up on the problem.


Yes: it's essential that we address the accredit= ation of the authentication and attribute providers in this structure. It&#= 39;s not clear that they're additional dimensions, though: a level 3 as= sertion from an entity that's only accredited at level 2 should probabl= y just be treated at the lower level unless there's an indication of fr= aud. It's also possible that some providers might be accredited at diff= erent levels for different purposes: perhaps they have an accreditation at = level 3 from the financial community, but only level 2 for health care.&nbs= p; We need to consider that.


[BA] I also wonder about vectors of = trust in chained assertion scenarios. You assert X, then I assert X based o= n your assertion (and my evaluation of your assertion). Or do I somehow enc= apsulate your assertion inside mine and consuming apps know how to deal wit= h this? Does the assertion’s strength change when I assert it (or enc= apsulate it) based on who I am?

 

Brian Arki= lls

University of Washington

<= /div>

______________= _________________________________
vot mailing list
vot@ietf.org
https://www.ietf.org/mailm= an/listinfo/vot

 

=

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


--f46d04388e695c06550504ffae9f-- From nobody Thu Oct 9 09:51:31 2014 Return-Path: X-Original-To: vot@ietfa.amsl.com Delivered-To: vot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7B761AD369 for ; Thu, 9 Oct 2014 09:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T7QXfvKffyaz for ; Thu, 9 Oct 2014 09:51:12 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E918B1AD363 for ; Thu, 9 Oct 2014 09:51:07 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id hi2so2003965wib.3 for ; Thu, 09 Oct 2014 09:51:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=Hv85E/ZhQVaCHmaoChWHfvebn8Xksd/BDF51iRVngo0=; b=CM5a8Xzcxkl8N5OGDpQBKDKpO0Y+ZE9LZO92d7zHuVZiW3XvT9Lw0DJKIJetvOB312 TfuunQfkku+xr7LfsWhNFzNsyiSLo5aXLVkW6ZrHCaodeKld4PbVv734tKzXvHEtWSKg lUYpcTO6spIh8hiUCcG753gqxx+2i1zxwHyj8S5eKdfkqIVYywhZNgLWO0x/RFuqcdfB Z6GINOBfP/2GWvN8qSemzjmfunKQ1zbOuj+jRjJ/qyb9fIxuzCIbWP4e4lLRphXeLsVz ssBtrqklwTQA25mgjA3OJWv18x29Npw8XQsbv9sRHkRAy3Ky7GQjImQMz3PrRh71MC4P MiVg== X-Gm-Message-State: ALoCoQkLGpw8aPwmGnGKRVYVcxlyuze/RnzKkrp8PLq6yHpQljdHmsX5yo47xKYwi8ib5Z1obwAg X-Received: by 10.180.21.227 with SMTP id y3mr5650423wie.54.1412873466377; Thu, 09 Oct 2014 09:51:06 -0700 (PDT) Received: from 192-87-30-176.terena.org (192-87-30-176.terena.org. [192.87.30.176]) by mx.google.com with ESMTPSA id hu3sm4148544wjb.17.2014.10.09.09.51.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 09 Oct 2014 09:51:05 -0700 (PDT) Message-ID: <5436BCF7.60507@terena.org> Date: Thu, 09 Oct 2014 17:51:03 +0100 From: Nicole Harris User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: vot@ietf.org References: <42FAEF9E-37A4-4F3A-84C0-63C1FBC22EC6@mitre.org> <542DCCA7.8070308@bluepopcorn.net> <277b9fa8ed8945cd919531b64834bb24@BL2PR08MB241.namprd08.prod.outlook.com> <82008C35-9F54-4E07-A0F6-FD0AF4BEF263@mitre.org> <35fb02f6.00001b38.0000000c@MLINDEN-X220.windows.csc.fi> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040104020903020001060406" Archived-At: http://mailarchive.ietf.org/arch/msg/vot/pxExtpR-Xk_N7T--eroIuBYB9i0 Subject: Re: [VoT] Vectors of Trust: A Strawman X-BeenThere: vot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Vectors of Trust discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 16:51:18 -0000 This is a multi-part message in MIME format. --------------040104020903020001060406 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The SIRTFI stuff is currently over here: https://wiki.refeds.org/display/GROUPS/SIRTFI. Note new shiny REFEDS wiki.=20 The thing I really like about this is that is totally use-case driven and focused in on the elements that a specific group really care about to provide an assurance profile approach that is likely to gain traction in the given community and that simply does not attempt to address other things that might typically cause problems in the whole level approach.=20 On 09/10/2014 17:10, Joni Brennan wrote: > This has been a great thread. I will spend more time to respond more > deeply... > > I suggest that incident response could be very reasonable for a VoT. > Ideally we are not specifying the "how" but that there is a process wit= h > reasonable rigor in place. > > best, > - Joni > > Best Regards, > > Joni Brennan > Kantara Initiative | Executive Director > voice:+1 732-266-8994 > email: joni @ kantarainitiative.org > > Connecting Identity for a more trustworthy Internet - Overview > > > > > > On Mon, Oct 6, 2014 at 9:41 PM, Mikael Linden wr= ote: > >>> There are things in this space (like "disaster recovery") that an RP >> could be able to discover ahead of time using a trust framework or ass= essor >> type of setup (the last point in the strawman), >> >> >> >> CERN and the grid folks are pushing a framework for incident handling = in >> federations (A Security Incident Response Trust >> >> Framework for Federated Identity -- Sir-T-Fi). They would like to have= >> some assurance that the IdP admin is reactive (answers to mail, phone = etc...) >> when an RP has faced an incident and needs the IdP's co-operation to >> resolve it. >> >> >> >> Is this another dimension for VoT? >> >> >> >> Cheers, >> >> mikael >> >> >> >> *From:* vot [mailto:vot-bounces@ietf.org] *On Behalf Of *Richer, Justi= n P. >> *Sent:* 6. lokakuuta 2014 17:24 >> *To:* Brian Arkills >> *Cc:* vot@ietf.org >> *Subject:* Re: [VoT] Vectors of Trust: A Strawman >> >> >> >> >> >> *[BA] It seems that the operational management vector has >> intersections/overlaps with some of the other vectors, but maybe that'= s >> just imagined on my part. If the operators of the component allow thei= r >> cert to expire that affects some of the other vectors. Likewise, if th= ey >> have very strong administrative practices, perhaps the credential stre= ngth >> is better than another provider using the same technologies. I'm strug= gling >> with whether I think it's good to represent this as a separate vector = or if >> this is just an aspect which influences the other vectors.* >> >> >> >> I agree that it's definitely different from the others, and originally= I >> only had the other three listed. The conversation in Utrecht had a lot= of >> input into this though. >> >> >> >> I think an important metric might be "what do I care about this at >> runtime"? There are things in this space (like "disaster recovery") th= at an >> RP could be able to discover ahead of time using a trust framework or >> assessor type of setup (the last point in the strawman), but they're n= ot >> going to ever change on a per-transaction or per-user basis. Other ite= ms >> like credential strength and proofing might be different each time tho= ugh, >> depending on the population of users being served. >> >> >> >> -- Justin >> >> >> >> >> >> >> >> On Oct 3, 2014, at 2:15 AM, Brian Arkills wrote: >> >> >> >> *[BA] **First, thanks a ton for putting this list together and hoistin= g a >> strawman to kick things off. I think a lot of people have been thinkin= g >> about the ways in which the existing LoA fall short, and I'm glad to s= ee a >> constructive effort at moving things forward. **J* >> >> >> >> *I've got a couple initial responses to parts of the proposal below ..= =2E * >> >> >> >> *Credential strength:* >> >> >> >> This covers how strongly bound the primary credential is to an individ= ual >> presenter, and how easily spoofed or stolen it is. >> >> >> >> 0: no credential / public >> >> 1: shared secret / password >> >> 2: proof of key possession >> >> 3: multiple factors [and probably higher definitions here as well -- b= ut >> we want to avoid all the little bespoke 2FA companies getting to defin= e a >> special snowflake "credential strength" value or else this becomes use= less] >> >> >> Anything here about how the secret key is protected? How about bearer >> assertions like cookies? >> >> >> *[BA] One of the stated aims of this vector is to reflect how easy it = is >> to steal the credential, but none of the values really represent that >> aspect. One of the biggest security stories right now, the plethora of= >> retailers with credit card breaches over the past year, seem to share >> several common elements, one of which involves leveraging the NTLM pas= s the >> hash credential replay. And if you've been following the NTLM pass the= hash >> replay stuff, you'll have taken note of the fact that enabling 2 facto= r on >> a given account doesn't mitigate it at all. Of course, that replay is = first >> dependent on compromising a system which has the desired credential, b= ut >> the fact that a replay attack is part of the underlying credential des= ign >> might mean your score should be lower here. You might have mitigations= in >> place which partially or totally neutralize that, in which case your s= core >> should be less affected. I'm not yet sure how you'd represent this >> complexity in a better way via the suggested description for the value= s but >> I did want to call this out so better minds than mine could ponder it.= * >> *J* >> >> >> >> *Operational management:* >> >> >> >> This covers a variety of information about the identity provider and i= ts >> host organization. What's the OpSec policy of the IdP? Is there disast= er >> recovery in place? How mature is the hosting organization? What kind o= f >> incident response can be expected? How strongly bound is a particular >> attribute to a particular credential [though maybe this fits under ide= ntity >> proofing]? You'll note that already this feels a lot less linear and a= lot >> less defined than the other three. >> >> >> >> *[BA] It seems that the operational management vector has >> intersections/overlaps with some of the other vectors, but maybe that'= s >> just imagined on my part. If the operators of the component allow thei= r >> cert to expire that affects some of the other vectors. Likewise, if th= ey >> have very strong administrative practices, perhaps the credential stre= ngth >> is better than another provider using the same technologies. I'm strug= gling >> with whether I think it's good to represent this as a separate vector = or if >> this is just an aspect which influences the other vectors.* >> >> >> >> Finally, I think we need to think about and discuss the notion of the >> assessment and trustmarks that would be powering the trust in all of t= hese >> values. After all, if they're just self-asserted by the IdP, that does= n't >> really help anyone. However, if we had a discovery mechanism whereby a= >> trustmark provider would be able to host a machine-readable definition= of >> what vectors a particular IdP has been proven to be able to claim for = any >> transaction, I think we've got a good leg up on the problem. >> >> >> Yes: it's essential that we address the accreditation of the >> authentication and attribute providers in this structure. It's not cle= ar >> that they're additional dimensions, though: a level 3 assertion from a= n >> entity that's only accredited at level 2 should probably just be treat= ed at >> the lower level unless there's an indication of fraud. It's also possi= ble >> that some providers might be accredited at different levels for differ= ent >> purposes: perhaps they have an accreditation at level 3 from the finan= cial >> community, but only level 2 for health care. We need to consider that= =2E >> >> >> *[BA] I also wonder about vectors of trust in chained assertion scenar= ios. >> You assert X, then I assert X based on your assertion (and my evaluati= on of >> your assertion). Or do I somehow encapsulate your assertion inside min= e and >> consuming apps know how to deal with this? Does the assertion's streng= th >> change when I assert it (or encapsulate it) based on who I am?* >> >> >> >> *Brian Arkills* >> >> *University of Washington* >> >> _______________________________________________ >> vot mailing list >> vot@ietf.org >> https://www.ietf.org/mailman/listinfo/vot >> >> >> >> _______________________________________________ >> vot mailing list >> vot@ietf.org >> https://www.ietf.org/mailman/listinfo/vot >> >> > > > _______________________________________________ > vot mailing list > vot@ietf.org > https://www.ietf.org/mailman/listinfo/vot --=20 ---------------- Project Development Officer TERENA Singel 468 D Amsterdam, 1017 AW The Netherlands T: +31(0)20 5304488 F: +31(0)20 5304499=20 mob: +31(0)646 105395 skype: harrisnv --------------040104020903020001060406 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit
The SIRTFI stuff is currently over here: https://wiki.refeds.org/display/GROUPS/SIRTFI.  Note new shiny REFEDS wiki. 

The thing I really like about this is that is totally use-case driven and focused in on the elements that a specific group really care about to provide an assurance profile approach that is likely to gain traction in the given community and that simply does not attempt to address other things that might typically cause problems in the whole level approach. 

On 09/10/2014 17:10, Joni Brennan wrote:
This has been a great thread.  I will spend more time to respond more
deeply...

I suggest that incident response could be very reasonable for a VoT.
Ideally we are not specifying the "how" but that there is a process with
reasonable rigor in place.

best,
- Joni

Best Regards,

Joni Brennan
Kantara Initiative | Executive Director
voice:+1 732-266-8994
email: joni @ kantarainitiative.org

Connecting Identity for a more trustworthy Internet - Overview
<http://www.slideshare.net/kantarainitiative/kantara-overview2014-37969351>




On Mon, Oct 6, 2014 at 9:41 PM, Mikael Linden <mikael.linden@csc.fi> wrote:


There are things in this space (like "disaster recovery") that an RP

could be able to discover ahead of time using a trust framework or assessor
type of setup (the last point in the strawman),



CERN and the grid folks are pushing a framework for incident handling in
federations (A Security Incident Response Trust

Framework for Federated Identity -- Sir-T-Fi). They would like to have
some assurance that the IdP admin is reactive (answers to mail, phone etc...)
when an RP has faced an incident and needs the IdP's co-operation to
resolve it.



Is this another dimension for VoT?



Cheers,

mikael



*From:* vot [mailto:vot-bounces@ietf.org] *On Behalf Of *Richer, Justin P.
*Sent:* 6. lokakuuta 2014 17:24
*To:* Brian Arkills
*Cc:* vot@ietf.org
*Subject:* Re: [VoT] Vectors of Trust: A Strawman





*[BA] It seems that the operational management vector has
intersections/overlaps with some of the other vectors, but maybe that's
just imagined on my part. If the operators of the component allow their
cert to expire that affects some of the other vectors. Likewise, if they
have very strong administrative practices, perhaps the credential strength
is better than another provider using the same technologies. I'm struggling
with whether I think it's good to represent this as a separate vector or if
this is just an aspect which influences the other vectors.*



I agree that it's definitely different from the others, and originally I
only had the other three listed. The conversation in Utrecht had a lot of
input into this though.



I think an important metric might be "what do I care about this at
runtime"? There are things in this space (like "disaster recovery") that an
RP could be able to discover ahead of time using a trust framework or
assessor type of setup (the last point in the strawman), but they're not
going to ever change on a per-transaction or per-user basis. Other items
like credential strength and proofing might be different each time though,
depending on the population of users being served.



 -- Justin







On Oct 3, 2014, at 2:15 AM, Brian Arkills <barkills@uw.edu> wrote:



*[BA] **First, thanks a ton for putting this list together and hoisting a
strawman to kick things off. I think a lot of people have been thinking
about the ways in which the existing LoA fall short, and I'm glad to see a
constructive effort at moving things forward. **J*



*I've got a couple initial responses to parts of the proposal below ... *



*Credential strength:*



This covers how strongly bound the primary credential is to an individual
presenter, and how easily spoofed or stolen it is.



0: no credential / public

1: shared secret / password

2: proof of key possession

3: multiple factors [and probably higher definitions here as well -- but
we want to avoid all the little bespoke 2FA companies getting to define a
special snowflake "credential strength" value or else this becomes useless]


Anything here about how the secret key is protected? How about bearer
assertions like cookies?


*[BA] One of the stated aims of this vector is to reflect how easy it is
to steal the credential, but none of the values really represent that
aspect. One of the biggest security stories right now, the plethora of
retailers with credit card breaches over the past year, seem to share
several common elements, one of which involves leveraging the NTLM pass the
hash credential replay. And if you've been following the NTLM pass the hash
replay stuff, you'll have taken note of the fact that enabling 2 factor on
a given account doesn't mitigate it at all. Of course, that replay is first
dependent on compromising a system which has the desired credential, but
the fact that a replay attack is part of the underlying credential design
might mean your score should be lower here. You might have mitigations in
place which partially or totally neutralize that, in which case your score
should be less affected. I'm not yet sure how you'd represent this
complexity in a better way via the suggested description for the values but
I did want to call this out so better minds than mine could ponder it. *
*J*



*Operational management:*



This covers a variety of information about the identity provider and its
host organization. What's the OpSec policy of the IdP? Is there disaster
recovery in place? How mature is the hosting organization? What kind of
incident response can be expected? How strongly bound is a particular
attribute to a particular credential [though maybe this fits under identity
proofing]? You'll note that already this feels a lot less linear and a lot
less defined than the other three.



*[BA] It seems that the operational management vector has
intersections/overlaps with some of the other vectors, but maybe that's
just imagined on my part. If the operators of the component allow their
cert to expire that affects some of the other vectors. Likewise, if they
have very strong administrative practices, perhaps the credential strength
is better than another provider using the same technologies. I'm struggling
with whether I think it's good to represent this as a separate vector or if
this is just an aspect which influences the other vectors.*



Finally, I think we need to think about and discuss the notion of the
assessment and trustmarks that would be powering the trust in all of these
values. After all, if they're just self-asserted by the IdP, that doesn't
really help anyone. However, if we had a discovery mechanism whereby a
trustmark provider would be able to host a machine-readable definition of
what vectors a particular IdP has been proven to be able to claim for any
transaction, I think we've got a good leg up on the problem.


Yes: it's essential that we address the accreditation of the
authentication and attribute providers in this structure. It's not clear
that they're additional dimensions, though: a level 3 assertion from an
entity that's only accredited at level 2 should probably just be treated at
the lower level unless there's an indication of fraud. It's also possible
that some providers might be accredited at different levels for different
purposes: perhaps they have an accreditation at level 3 from the financial
community, but only level 2 for health care.  We need to consider that.


*[BA] I also wonder about vectors of trust in chained assertion scenarios.
You assert X, then I assert X based on your assertion (and my evaluation of
your assertion). Or do I somehow encapsulate your assertion inside mine and
consuming apps know how to deal with this? Does the assertion's strength
change when I assert it (or encapsulate it) based on who I am?*



*Brian Arkills*

*University of Washington*

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



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




      

      

      

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


    

    

    

    
-- 
----------------
Project Development Officer
TERENA
Singel 468 D
Amsterdam, 1017 AW
The Netherlands

T: +31(0)20 5304488
F: +31(0)20 5304499 

mob: +31(0)646 105395
skype: harrisnv


  


--------------040104020903020001060406--


From nobody Thu Oct  9 13:19:03 2014
Return-Path: 
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 079AE1A7003 for ; Thu,  9 Oct 2014 13:18:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.401
X-Spam-Level: *
X-Spam-Status: No, score=1.401 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tHub7UYMkZoK for ; Thu,  9 Oct 2014 13:18:56 -0700 (PDT)
Received: from smtp85.iad3a.emailsrvr.com (smtp85.iad3a.emailsrvr.com [173.203.187.85]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D6891A6EFC for ; Thu,  9 Oct 2014 13:18:56 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp19.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id BB62F18038D for ; Thu,  9 Oct 2014 16:18:55 -0400 (EDT)
X-Virus-Scanned: OK
Received: from app34.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp19.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id A1B5F1802CE for ; Thu,  9 Oct 2014 16:18:55 -0400 (EDT)
X-Sender-Id: swilson@lockstep.com.au
Received: from app34.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.2.13); Thu, 09 Oct 2014 20:18:55 GMT
Received: from lockstep.com.au (localhost.localdomain [127.0.0.1]) by app34.wa-webapps.iad3a (Postfix) with ESMTP id 9066518009F for ; Thu,  9 Oct 2014 16:18:55 -0400 (EDT)
Received: by apps.rackspace.com (Authenticated sender: swilson@lockstep.com.au, from: swilson@lockstep.com.au)  with HTTP; Fri, 10 Oct 2014 07:18:55 +1100 (EST)
Date: Fri, 10 Oct 2014 07:18:55 +1100 (EST)
From: swilson@lockstep.com.au
To: vot@ietf.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_20141010071855000000_21842"
Importance: Normal
X-Priority: 3 (Normal)
X-Type: html
X-Auth-ID: swilson@lockstep.com.au
Message-ID: <1412885935.58929166@apps.rackspace.com>
X-Mailer: webmail7.0
Archived-At: http://mailarchive.ietf.org/arch/msg/vot/_mTAbi3nEHfL7d6XrOAGjNzbBoQ
Subject: [VoT] Foundational questions of principle
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Vectors of Trust discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Oct 2014 20:18:59 -0000

------=_20141010071855000000_21842
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=0A =0AFirst, to introduce myself, I am an identity and privacy researcher,=
 analyst and consultant.  I've been involved in this since 1995, when I cut=
 my teeth in PKI and smartcards (with the early companies that became Balti=
more Technologies). Since then I've worked on identity management framework=
s, regulations and standards.  =0A =0AI subscribe to the old Italian prover=
b: "it's nice to trust but better not to".  Words matter and I wonder if we=
 shouldn't be using the word trust so much.  =0A =0AMore pragmatically, I n=
ote the very strong "Attributes" push of the past 18 months.  Andrew Nash, =
Anil John, myself and others have written about this.  The FIDO Alliance is=
 all about authentication and attributes, and they purposefully leave "iden=
tity" as a matter for others to work out further up the stack. The OID Foun=
dation is promoting an Attributes Exchange Network "AXN" architecture.  New=
 entrants like id.me (an NSTIC pilot participant) talk about attributes and=
 avoid "identity". =0A =0AI mention all of this as a prelude to suggest tha=
t "vector of trust" is synonymous with "attribute". I wonder if it would be=
 clearer to use plain and current language rather than carry forward the fu=
zzy and I think overly ambitious idea of "trust"? =0A =0AFinally, I'd like =
to throw in my abiding concern that LOAs have foundered simply because it's=
 difficult to pigeonhole risk. One party's idea of "medium" risk for instan=
ce will rarely map precisely to another's. I think people have been misled =
into thinking that an "LOA 3" identity should be be able to be used on its =
face (i.e. will "interoperate") at any "LOA 3" RP. Risk management is not s=
o simple. =0A =0AThe LOA paradigm borrows from Risk Management standards li=
ke ISO 31000 which organisations use to plot their own risks internally typ=
ically on a five scale (eg Negligible / Low / Medium / High / Grave). But r=
isk management standards require that each organisation calibrates risk in =
its own business context and according to its own risk appetite. The risk o=
f a firewall breach for example at a startup social media company will be a=
ssessed differently by a big listed healthcare company. So organisation A c=
an say the risk of event X is Low but B can say the risk of the same event =
is Medium.  As a result, LOAs do not inter-operate. They are based on stand=
ards meant for intra-organisation risk management, not inter-organisation c=
ommunication of risk assessments. =0A =0ASo far with VoT we are adding more=
 dimensions to the RPs' generic risk management decision making, and that's=
 great.  But we are still pigeonholing the dimensions.=0A =0AI'm afraid the=
 reality is that risk management will always be done locally.  And so it sh=
ould be.  When an RP is making the decision to accept or reject a given sub=
ject, they will evaluate a range of attributes or signals.  The set of attr=
ibutes that matters varies from one RP to the next.  I think it's a great i=
dea indeed to create guidance for evaluating attributes, and to coach RPs t=
o look at all sorts of dimensions.  I just don't think it helps anyone to p=
igeonhole the risk ratings, because across organisations, arguments about t=
he boundaries between LOA 1/2/3/4 (that is, policy mapping) will undo any e=
fficiencies gained from the categorization.  =0A =0ACheers, =0A =0ASteve.=
=0A =0A =0AStephen Wilson=0AManaging Director=0ALockstep Group=0Ahttp://loc=
kstep.com.au=0ALockstep Consulting provides independent specialist advice a=
nd analysis =0Aon digital identity and privacy. Lockstep Technologies devel=
ops unique =0Anew smart ID solutions that enhance privacy and prevent ident=
ity theft.=0A =0A =0A 
------=_20141010071855000000_21842
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


 
=0A
First, to introduce myself, I am an identity and privacy researcher, an=
alyst and consultant.  I've been involved in this since 1995, when I c=
ut my teeth in PKI and smartcards (with the early companies that became Bal=
timore Technologies). Since then I've worked on identity management framewo=
rks, regulations and standards.  
=0A
 
=0A=

I subscribe to the old Italian proverb: "it's nice to trus=
t but better not to".  Words matter and I wonder if we shouldn't be us=
ing the word trust so much.  
=0A
 
=0A
More pragmatically, I note the very strong "Attributes" push o=
f the past 18 months.  Andrew Nash, Anil John, myself and others have =
written about this.  The FIDO Alliance is all about authentication and=
 attributes, and they purposefully leave "identity" as a matter for others =
to work out further up the stack. The OID Foundation is promoting an Attrib=
utes Exchange Network "AXN" architecture.  New entrants like id.me (an=
 NSTIC pilot participant) talk about attributes and avoid "identity". =

=0A
 
=0A
I mention all of this=
 as a prelude to suggest that "vector of trust" is synonymous with "attribu=
te". I wonder if it would be clearer to use plain and current language rath=
er than carry forward the fuzzy and I think overly ambitious idea of "trust=
"? 
=0A
 
=0A
Finally, I'd =
like to throw in my abiding concern that LOAs have foundered simply because=
 it's difficult to pigeonhole risk. One party's idea of "medium" risk for i=
nstance will rarely map precisely to another's. I think people have been mi=
sled into thinking that an "LOA 3" identity should be be able to be used on=
 its face (i.e. will "interoperate") at any "LOA 3" RP. Risk management is =
not so simple. 
=0A
 
=0A
T=
he LOA paradigm borrows from Risk Management standards like ISO 31000 which=
 organisations use to plot their own risks internally typica=
lly on a five scale (eg Negligible / Low / Medium / High / Grave). But=
 risk management standards require that each organisation calibra=
tes risk in its own business context and according to its own risk app=
etite. The risk of a firewall breach for example at a startup social media =
company will be assessed differently by a big listed healthcare company.&nb=
sp;So organisation A can say the risk of event X is Low but B can say =
the risk of the same event is Medium.  As a result, LOAs do not i=
nter-operate. They are based on standards meant for intra-organisation risk=
 management, not inter-organisation communication of risk assessments.=
 
=0A
 
=0A
So far with VoT=
 we are adding more dimensions to the RPs' generic risk management decision=
 making, and that's great.  But we are still pigeonholing the dimensio=
ns.
=0A
 
=0A
I'm afraid the rea=
lity is that risk management will always be done locally.  And so it s=
hould be.  When an RP is making the decision to accept or reject =
a given subject, they will evaluate a range of attributes or signals. =
 The set of attributes that matters varies from one RP to the next. &n=
bsp;I think it's a great idea indeed to create guidance for evaluating attr=
ibutes, and to coach RPs to look at all sorts of dimensions.  I just d=
on't think it helps anyone to pigeonhole the risk ratings, because across o=
rganisations, arguments about the boundaries between LOA 1/2/3/4 (that is, =
policy mapping) will undo any efficiencies gained from the categorizat=
ion.  
=0A
 
=0A
Cheers,&nb=
sp;
=0A
 
=0A
Steve.
=0A
 
=0A
 
=0A
Ste=
phen Wilson
Managing Director
Lockstep Group
http://lockstep=
.com.au
Lockstep Consulting provides independent specialist advice and=
 analysis 
on digital identity and privacy. Lockstep Technologies deve=
lops unique 
new smart ID solutions that enhance privacy and prevent i=
dentity theft.
=0A
 
=0A
 <=
/p>=0A
 

------=_20141010071855000000_21842--


From nobody Thu Oct  9 14:33:38 2014
Return-Path: 
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CFC61A88B8 for ; Thu,  9 Oct 2014 14:33:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.15
X-Spam-Level: *
X-Spam-Status: No, score=1.15 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HDjwzn-7XswV for ; Thu,  9 Oct 2014 14:33:30 -0700 (PDT)
Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B64A01A88B2 for ; Thu,  9 Oct 2014 14:33:29 -0700 (PDT)
Received: from [81.217.70.9] (helo=[192.168.1.33]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XcLKv-0006mr-Vv; Thu, 09 Oct 2014 23:33:26 +0200
Content-Type: multipart/alternative; boundary="Apple-Mail=_DE19C7E1-B344-4DFA-BC70-FA3D64EA0B4D"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Rainer Hoerbe 
X-Priority: 3 (Normal)
Date: Thu, 9 Oct 2014 23:33:24 +0200
Message-Id: 
References: <04CF3DDE-9FDF-499A-8093-3EC3CE84E4DF@identinetics.com>
To: Wilson Stephen 
X-Mailer: Apple Mail (2.1878.6)
X-Df-Sender: cmhAaWRlbnRpbmV0aWNzLmNvbQ==
Archived-At: http://mailarchive.ietf.org/arch/msg/vot/Hy8UVNDluKx0UYs6wD8fKPx-060
Cc: vot@ietf.org
Subject: [VoT] Fwd:  Foundational questions of principle
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Vectors of Trust discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Oct 2014 21:33:32 -0000

--Apple-Mail=_DE19C7E1-B344-4DFA-BC70-FA3D64EA0B4D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Am 09.10.2014 um 22:18 schrieb swilson@lockstep.com.au:

> Finally, I'd like to throw in my abiding concern that LOAs have =
foundered simply because it's difficult to pigeonhole risk. One party's =
idea of "medium" risk for instance will rarely map precisely to =
another's. I think people have been misled into thinking that an "LOA 3" =
identity should be be able to be used on its face (i.e. will =
"interoperate") at any "LOA 3" RP. Risk management is not so simple.=20
> =20
> The LOA paradigm borrows from Risk Management standards like ISO 31000 =
which organisations use to plot their own risks internally typically on =
a five scale (eg Negligible / Low / Medium / High / Grave). But risk =
management standards require that each organisation calibrates risk in =
its own business context and according to its own risk appetite. The =
risk of a firewall breach for example at a startup social media company =
will be assessed differently by a big listed healthcare company. So =
organisation A can say the risk of event X is Low but B can say the risk =
of the same event is Medium.  As a result, LOAs do not inter-operate. =
They are based on standards meant for intra-organisation risk =
management, not inter-organisation communication of risk assessments.=20
> =20
> So far with VoT we are adding more dimensions to the RPs' generic risk =
management decision making, and that's great.  But we are still =
pigeonholing the dimensions.
> =20
> I'm afraid the reality is that risk management will always be done =
locally.  And so it should be.  When an RP is making the decision to =
accept or reject a given subject, they will evaluate a range of =
attributes or signals.  The set of attributes that matters varies from =
one RP to the next.  I think it's a great idea indeed to create guidance =
for evaluating attributes, and to coach RPs to look at all sorts of =
dimensions.  I just don't think it helps anyone to pigeonhole the risk =
ratings, because across organisations, arguments about the boundaries =
between LOA 1/2/3/4 (that is, policy mapping) will undo any efficiencies =
gained from the categorization. =20

I agree in principle, but do not follow your conclusion that risk =
management is only local. Risk assessment is local only, but treatment =
has non-local properties.=20

I agree that the current system of LoAs is broken if used beyond a =
specific sector, because it is mostly an attempt to manage risk by =
controlling mitigation across organizations. The detailed obligation of =
controls between RPs and IDPs has too many permutations and VoT won't =
radically improve this.

However, a combination of risk transfer and risk mitigation can =
drastically reduce the number of controls contained in a LoA policy. =
This is straightforward in a plain commercial environment, less so in =
highly regulated areas. Laws will always require prescriptive controls, =
like anti-money laundry rules. The point is to tag a figure to the risk, =
and leave the details of risk mitigation to the IDP ("You are liable for =
this login with 100$").

So I am proposing a 3-step approach to resolve the LoA problem:
1. Replace controls by liability where possible
2. Standardize controls and their categories into a catalogue (something =
like the Kantara IAF service criteria)
3. Define sector-specific policies based on these standardized controls =
to match additional requirements (e.g. Payment Services Directive, =
HIPPA, Qualified Signature, you name it). These policies may be =
subdivided into  levels and vectors. While the policies will not match =
between sectors, their building block do, thus reducing the effort to =
map them.

Cheers, Rainer


--Apple-Mail=_DE19C7E1-B344-4DFA-BC70-FA3D64EA0B4D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


Am =
09.10.2014 um 22:18 schrieb swilson@lockstep.com.au:

Finally, I'd like to throw in my abiding =
concern that LOAs have foundered simply because it's difficult to =
pigeonhole risk. One party's idea of "medium" risk for instance will =
rarely map precisely to another's. I think people have been misled into =
thinking that an "LOA 3" identity should be be able to be used on its =
face (i.e. will "interoperate") at any "LOA 3" RP. Risk management is =
not so simple. 
 
The =
LOA paradigm borrows from Risk Management standards like ISO 31000 =
which organisations use to plot their own risks =
internally typically on a five scale (eg Negligible / Low / Medium / =
High / Grave). But risk management standards require that =
each organisation calibrates risk in its own business context and =
according to its own risk appetite. The risk of a firewall breach =
for example at a startup social media company will be assessed =
differently by a big listed healthcare company. So organisation =
A can say the risk of event X is Low but B can say the risk of the =
same event is Medium.  As a result, LOAs do not inter-operate. =
They are based on standards meant for intra-organisation risk =
management, not inter-organisation communication of risk =
assessments. 
 
So far with VoT we are adding more dimensions to =
the RPs' generic risk management decision making, and that's great. =
 But we are still pigeonholing the dimensions.
 
I'm =
afraid the reality is that risk management will always be done locally. =
 And so it should be.  When an RP is making the decision =
to accept or reject a given subject, they will evaluate a range of =
attributes or signals.  The set of attributes that matters =
varies from one RP to the next.  I think it's a great idea indeed =
to create guidance for evaluating attributes, and to coach RPs to look =
at all sorts of dimensions.  I just don't think it helps anyone to =
pigeonhole the risk ratings, because across organisations, arguments =
about the boundaries between LOA 1/2/3/4 (that is, policy mapping) =
will undo any efficiencies gained from the categorization. =
 

I agree in principle, but =
do not follow your conclusion that risk management is only local. Risk =
assessment is local only, but treatment has non-local =
properties. 

I agree that the current =
system of LoAs is broken if used beyond a specific sector, because it is =
mostly an attempt to manage risk by controlling mitigation across =
organizations. The detailed obligation of controls between RPs and IDPs =
has too many permutations and VoT won't radically improve =
this.

However, a combination of risk transfer =
and risk mitigation can drastically reduce the number of controls =
contained in a LoA policy. This is straightforward in a plain commercial =
environment, less so in highly regulated areas. Laws will always require =
prescriptive controls, like anti-money laundry rules. The point is to =
tag a figure to the risk, and leave the details of risk mitigation to =
the IDP ("You are liable for this login with =
100$").

So I am proposing a 3-step approach to =
resolve the LoA problem:
1. Replace controls by liability =
where possible
2. Standardize controls and their categories =
into a catalogue (something like the Kantara IAF service =
criteria)
3. Define sector-specific policies based on these =
standardized controls to match additional requirements (e.g. Payment =
Services Directive, HIPPA, Qualified Signature, you name it). These =
policies may be subdivided into  levels and vectors. While the =
policies will not match between sectors, their building block do, thus =
reducing the effort to map them.

Cheers, =
Rainer

=

--Apple-Mail=_DE19C7E1-B344-4DFA-BC70-FA3D64EA0B4D--


From nobody Thu Oct  9 16:17:05 2014
Return-Path: 
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39A741A8A92 for ; Thu,  9 Oct 2014 16:17:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.801
X-Spam-Level: 
X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9YJujDTgCfhR for ; Thu,  9 Oct 2014 16:16:58 -0700 (PDT)
Received: from smtp125.iad3a.emailsrvr.com (smtp125.iad3a.emailsrvr.com [173.203.187.125]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF01D1A1BC6 for ; Thu,  9 Oct 2014 16:16:58 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp24.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 086A7180424 for ; Thu,  9 Oct 2014 19:16:58 -0400 (EDT)
X-Virus-Scanned: OK
Received: from app17.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp24.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id E4B0F180415 for ; Thu,  9 Oct 2014 19:16:57 -0400 (EDT)
X-Sender-Id: swilson@lockstep.com.au
Received: from app17.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.2.13); Thu, 09 Oct 2014 23:16:57 GMT
Received: from lockstep.com.au (localhost.localdomain [127.0.0.1]) by app17.wa-webapps.iad3a (Postfix) with ESMTP id D4D45280071 for ; Thu,  9 Oct 2014 19:16:57 -0400 (EDT)
Received: by apps.rackspace.com (Authenticated sender: swilson@lockstep.com.au, from: swilson@lockstep.com.au)  with HTTP; Fri, 10 Oct 2014 10:16:57 +1100 (EST)
Date: Fri, 10 Oct 2014 10:16:57 +1100 (EST)
From: swilson@lockstep.com.au
To: vot@ietf.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_20141010101657000000_39998"
Importance: Normal
X-Priority: 3 (Normal)
X-Type: html
In-Reply-To: <04CF3DDE-9FDF-499A-8093-3EC3CE84E4DF@identinetics.com>
References: <1412885935.58929166@apps.rackspace.com>  <04CF3DDE-9FDF-499A-8093-3EC3CE84E4DF@identinetics.com>
X-Auth-ID: swilson@lockstep.com.au
Message-ID: <1412896617.869315461@apps.rackspace.com>
X-Mailer: webmail7.0
Archived-At: http://mailarchive.ietf.org/arch/msg/vot/tik9h0x_1sB2CCq_IrF8OUCQWjM
Subject: Re: [VoT] Foundational questions of principle
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Vectors of Trust discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Oct 2014 23:17:01 -0000

------=_20141010101657000000_39998
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=0A =0ARainer, =0A =0AI like your approach.  But I think we should review w=
hat the objective is of LOAs in general, and question whether or not labeli=
ng things by "level" is a useful idea. Yes we need to help organisations be=
tter understand and manage authentication risk, but is "LOA" is a necessary=
 output of that process?  Doesn't a four level label over simplify things? =
I find it's a misleading shorthand that leads people to believe that a give=
n identity can be used at a given RP without any further analysis.  =0A =0A=
We can do all the things you say below, but stop short of attaching the "le=
vel". =0A =0ACheers, =0A =0ASteve.=0A =0A =0A =0A =0A-----Original Message-=
----=0AFrom: "Rainer Hoerbe" =0ASent: Friday, 10 Octob=
er, 2014 8:24am=0ATo: "Wilson Stephen" =0ACc: vot@=
ietf.org=0ASubject: Re: [VoT] Foundational questions of principle=0A=0A=0AA=
m 09.10.2014 um 22:18 schrieb [ swilson@lockstep.com.au ]( mailto:swilson@l=
ockstep.com.au ):=0A=0A=0AFinally, I'd like to throw in my abiding concern =
that LOAs have foundered simply because it's difficult to pigeonhole risk. =
One party's idea of "medium" risk for instance will rarely map precisely to=
 another's. I think people have been misled into thinking that an "LOA 3" i=
dentity should be be able to be used on its face (i.e. will "interoperate")=
 at any "LOA 3" RP. Risk management is not so simple. =0A =0AThe LOA paradi=
gm borrows from Risk Management standards like ISO 31000 which organisation=
s use to plot their own risks internally typically on a five scale (eg Negl=
igible / Low / Medium / High / Grave). But risk management standards requir=
e that each organisation calibrates risk in its own business context and ac=
cording to its own risk appetite. The risk of a firewall breach for example=
 at a startup social media company will be assessed differently by a big li=
sted healthcare company. So organisation A can say the risk of event X is L=
ow but B can say the risk of the same event is Medium.  As a result, LOAs d=
o not inter-operate. They are based on standards meant for intra-organisati=
on risk management, not inter-organisation communication of risk assessment=
s. =0A =0ASo far with VoT we are adding more dimensions to the RPs' generic=
 risk management decision making, and that's great.  But we are still pigeo=
nholing the dimensions.=0A =0AI'm afraid the reality is that risk managemen=
t will always be done locally.  And so it should be.  When an RP is making =
the decision to accept or reject a given subject, they will evaluate a rang=
e of attributes or signals.  The set of attributes that matters varies from=
 one RP to the next.  I think it's a great idea indeed to create guidance f=
or evaluating attributes, and to coach RPs to look at all sorts of dimensio=
ns.  I just don't think it helps anyone to pigeonhole the risk ratings, bec=
ause across organisations, arguments about the boundaries between LOA 1/2/3=
/4 (that is, policy mapping) will undo any efficiencies gained from the cat=
egorization.  =0AI agree in principle, but do not follow your conclusion th=
at risk management is only local. Risk assessment is local only, but treatm=
ent has non-local properties. =0AYes, the current system of LoAs is broken =
if used beyond a specific sector, because it is mostly an attempt to manage=
 risk by mitigation. The detailed obligation of controls between RPs and ID=
Ps has too many permutations and VoT won't radically improve this.=0AHoweve=
r, a combination of risk transfer and risk mitigation can drastically reduc=
e the number of controls contained in a LoA policy, more in a common commer=
cial environment, less so in highly regulated areas. Laws will always requi=
re prescriptive controls, like anti-money laundry rules. The point is to ta=
g a figure to the risk, and leave the details of risk mitigation to the IDP=
. =0ASo I am proposing a 3-step approach to resolve the LoA problem:=0A1. R=
eplace controls by liability where possible=0A2. Standardize controls and t=
heir categories into a catalogue (something like the Kantara IAF service cr=
iteria)=0A3. Define sector-specific policies to match additional requiremen=
ts (e.g. Payment Services Directive, HIPPA, Qualified Signature, you name i=
t). These policies may be subdivided into  levels and vectors.=0ACheers, Ra=
iner
------=_20141010101657000000_39998
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


 
=0A
Rainer, 
=0A
 
=0A
I li=
ke your approach.  But I think we should review what the objective is =
of LOAs in general, and question whether or not labeling things by "level"&=
nbsp;is a useful idea. Yes we need to help organisations better understand =
and manage authentication risk, but is "LOA" is a necessary outpu=
t of that process?  Doesn't a four level label over simplify things?&n=
bsp;I find it's a misleading shorthand that leads people to believe th=
at a given identity can be used at a given RP without any further analysis.=
  
=0A
 
=0A
We can do all =
the things you say below, but stop short of attaching the "level". =0A
 
=0A
Cheers, 
=0A
 
=0A
Steve.
=0A
&n=
bsp;
=0A
 
=0A
 
=0A
 
=0A
-----Original Message-----
=
From: "Rainer Hoerbe" <rh@identinetics.com>
Sent: Friday, 10 Oct=
ober, 2014 8:24am
To: "Wilson Stephen" <swilson@lockstep.com.au>=

Cc: vot@ietf.org
Subject: Re: [VoT] Foundational questions of pr=
inciple

=0A
Am 09.10.2014 um=
 22:18 schrieb swilson@lockstep.=
com.au:
=0A
=0A
=0A
Finally, I'd like to throw in my a=
biding concern that LOAs have foundered simply because it's difficult to pi=
geonhole risk. One party's idea of "medium" risk for instance will rarely m=
ap precisely to another's. I think people have been misled into thinking th=
at an "LOA 3" identity should be be able to be used on its face (i.e. will =
"interoperate") at any "LOA 3" RP. Risk management is not so simple. <=
/span>
=0A
 
=0A
The LOA paradigm borrows from Risk Management standards l=
ike ISO 31000 which organisations use to plot their own risk=
s internally typically on a five scale (eg Negligible / Low / Medium / High=
 / Grave). But risk management standards require that each o=
rganisation calibrates risk in its own business context and according to it=
s own risk appetite. The risk of a firewall breach for example at a st=
artup social media company will be assessed differently by a big listed hea=
lthcare company. So organisation A can say the risk of event X is=
 Low but B can say the risk of the same event is Medium.  As a re=
sult, LOAs do not inter-operate. They are based on standards meant for intr=
a-organisation risk management, not inter-organisation communication of&nbs=
p;risk assessments. 
=0A
&=
nbsp;
=0A
So far with VoT we are adding more d=
imensions to the RPs' generic risk management decision making, and that's g=
reat.  But we are still pigeonholing the dimensions.
=0A
 
=0A
I'm=
 afraid the reality is that risk management will always be done locally. &n=
bsp;And so it should be.  When an RP is making the decision to ac=
cept or reject a given subject, they will evaluate a range of attributes or=
 signals.  The set of attributes that matters varies from one RP =
to the next.  I think it's a great idea indeed to create guidance for =
evaluating attributes, and to coach RPs to look at all sorts of dimensions.=
  I just don't think it helps anyone to pigeonhole the risk ratings, b=
ecause across organisations, arguments about the boundaries between LOA 1/2=
/3/4 (that is, policy mapping) will undo any efficiencies gained from =
the categorization.  
=0A
=0A
=0A
I agree in=
 principle, but do not follow your conclusion that risk management is only =
local. Risk assessment is local only, but treatment has non-local propertie=
s. 
=0A
Yes, the current system of LoAs is broken if used bey=
ond a specific sector, because it is mostly an attempt to manage risk by mi=
tigation. The detailed obligation of controls between RPs and IDPs has too =
many permutations and VoT won't radically improve this.
=0A
Howeve=
r, a combination of risk transfer and risk mitigation can drastically reduc=
e the number of controls contained in a LoA policy, more in a common commer=
cial environment, less so in highly regulated areas. Laws will always requi=
re prescriptive controls, like anti-money laundry rules. The point is to ta=
g a figure to the risk, and leave the details of risk mitigation to the IDP=
. 
=0A
So I am proposing a 3-step approach to resolve the LoA=
 problem:
=0A
1. Replace controls by liability where possible=0A
2. Standardize controls and their categories into a catalogue (som=
ething like the Kantara IAF service criteria)
=0A
3. Define sector=
-specific policies to match additional requirements (e.g. Payment Services =
Directive, HIPPA, Qualified Signature, you name it). These policies may be =
subdivided into  levels and vectors.
=0A
Cheers, Rainer
=
=0A

------=_20141010101657000000_39998--


From nobody Thu Oct  9 18:05:29 2014
Return-Path: 
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F8F01AD03A for ; Thu,  9 Oct 2014 18:05:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1keVxaS3b2fI for ; Thu,  9 Oct 2014 18:05:26 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0737.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:737]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52B411AD037 for ; Thu,  9 Oct 2014 18:05:26 -0700 (PDT)
Received: from BL2FFO11FD037.protection.gbl (10.173.160.32) by BL2FFO11HUB014.protection.gbl (10.173.160.106) with Microsoft SMTP Server (TLS) id 15.0.1039.16; Fri, 10 Oct 2014 01:05:03 +0000
Received: from cio-tnc-pf04.osuad.osu.edu (164.107.81.218) by BL2FFO11FD037.mail.protection.outlook.com (10.173.161.133) with Microsoft SMTP Server (TLS) id 15.0.1039.16 via Frontend Transport; Fri, 10 Oct 2014 01:05:03 +0000
Received: from CIO-TNC-HT05.osuad.osu.edu (cio-tnc-ht05.osuad.osu.edu [164.107.81.168]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by cio-tnc-pf04.osuad.osu.edu (Postfix) with ESMTPS id E8ED938005A; Thu,  9 Oct 2014 21:05:02 -0400 (EDT)
Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT05.osuad.osu.edu ([fe80::d0be:603:484c:5a2f%10]) with mapi id 14.03.0174.001; Thu, 9 Oct 2014 21:05:01 -0400
From: "Cantor, Scott" 
To: "swilson@lockstep.com.au" , "vot@ietf.org" 
Thread-Topic: [VoT] Foundational questions of principle
Thread-Index: AQHP4/5G4lDLBqwim0uOTbuH/sjzZJwoZk77gAAeJIA=
Date: Fri, 10 Oct 2014 01:05:01 +0000
Message-ID: 
References: <1412885935.58929166@apps.rackspace.com> <04CF3DDE-9FDF-499A-8093-3EC3CE84E4DF@identinetics.com> <1412896617.869315461@apps.rackspace.com>
In-Reply-To: <1412896617.869315461@apps.rackspace.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [128.146.14.94]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:164.107.81.218; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(979002)(6009001)(438002)(24454002)(51444003)(199003)(51704005)(377454003)(479174003)(189002)(23726002)(21056001)(107046002)(107886001)(31966008)(46406003)(106466001)(36756003)(54356999)(50986999)(95666004)(93346002)(97756001)(4396001)(87936001)(86362001)(76176999)(77096002)(2656002)(85852003)(90282001)(2501002)(20776003)(47776003)(92566001)(64706001)(66066001)(44976005)(6806004)(92726001)(88552001)(19580395003)(19580405001)(50466002)(85306004)(80022003)(109096001)(75432002)(46102003)(106116001)(76482002)(99396003)(120916001)(89122001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2FFO11HUB014; H:cio-tnc-pf04.osuad.osu.edu; FPR:; MLV:ovrnspm; PTR:cio-tnc-pf04.osuad.osu.edu; A:1; MX:1; LANG:en; 
X-Microsoft-Antispam: UriScan:;
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2FFO11HUB014;
X-Exchange-Antispam-Report-Test: UriScan:;
X-Forefront-PRVS: 03607C04F0
Received-SPF: Pass (protection.outlook.com: domain of osu.edu designates 164.107.81.218 as permitted sender) receiver=protection.outlook.com; client-ip=164.107.81.218; helo=cio-tnc-pf04.osuad.osu.edu;
Authentication-Results: spf=pass (sender IP is 164.107.81.218) smtp.mailfrom=cantor.2@osu.edu; 
X-OriginatorOrg: osu.edu
Archived-At: http://mailarchive.ietf.org/arch/msg/vot/AUw9t-LGpgR3z-4eS09yk25jU_I
Subject: Re: [VoT] Foundational questions of principle
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Vectors of Trust discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Oct 2014 01:05:28 -0000

On 10/9/14, 7:16 PM, "swilson@lockstep.com.au" 
wrote:

>
>=20
>I like your approach.  But I think we should review what the objective is
>of LOAs in general, and question whether or not labeling things by
>"level" is a useful idea. Yes we need to help organisations better
>understand and manage authentication risk, but is "LOA" is a necessary
>output of that process?  Doesn't a four level label over simplify things?
>I find it's a misleading shorthand that leads people to believe that a
>given identity can be used at a given RP without any further analysis.

I think that taking complex ideas and reducing them to levels is overly
simplifying, and it would be better to just define a schema for attribute
data to express in each area.

But my personal *experience* is that applications won't do the work of
building and enforcing polices around that fine-grained a way of
expressing the information. They don't do it well with user attributes, so
there's even less chance they'd do it with data that isn't even core to
their purpose.

Reducing to levels is a way of splitting the work and pushing more of it
to other parties that care enough to do the work.

Perhaps some of the "vectors" are more amenable to reduction to levels
than others. I tend to agree with others' comments that things like
incident response and the operational maturity issues probably don't
reduce well to levels. So maybe both approaches are needed if there are
concrete justifications for them.

And to be honest, I have a lot more concrete evidence that those
non-linear concepts are of interest to applications than I do most of the
traditional assurance-related vectors. And I think they're *more*
well-defined, not less. Most of the easily linear concepts seem like
solutions looking for a problem to me, with the exception of
authentication quality.

-- Scott


From nobody Thu Oct  9 18:30:28 2014
Return-Path: 
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAF5B1AD049 for ; Thu,  9 Oct 2014 18:30:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kl1zJR8o8-lN for ; Thu,  9 Oct 2014 18:30:26 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0701.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:701]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0BC21AD04A for ; Thu,  9 Oct 2014 18:30:25 -0700 (PDT)
Received: from BL2FFO11FD020.protection.gbl (10.173.160.33) by BL2FFO11HUB067.protection.gbl (10.173.161.167) with Microsoft SMTP Server (TLS) id 15.0.1039.16; Fri, 10 Oct 2014 01:29:56 +0000
Received: from cio-tnc-pf08.osuad.osu.edu (164.107.81.222) by BL2FFO11FD020.mail.protection.outlook.com (10.173.161.38) with Microsoft SMTP Server (TLS) id 15.0.1039.16 via Frontend Transport; Fri, 10 Oct 2014 01:29:57 +0000
Received: from CIO-TNC-HT07.osuad.osu.edu (cio-tnc-ht07.osuad.osu.edu [164.107.81.174]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by cio-tnc-pf08.osuad.osu.edu (Postfix) with ESMTPS id 774FD2E0076; Thu,  9 Oct 2014 21:29:56 -0400 (EDT)
Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT07.osuad.osu.edu ([fe80::3ca1:e895:a165:1359%10]) with mapi id 14.03.0174.001; Thu, 9 Oct 2014 21:29:55 -0400
From: "Cantor, Scott" 
To: "Richer, Justin P." , "vot@ietf.org" 
Thread-Topic: [VoT] Vectors of Trust: A Strawman
Thread-Index: AQHP5CmyMbnSVgj9dkKOx7btT3InPw==
Date: Fri, 10 Oct 2014 01:29:55 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [128.146.14.94]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <677944E37D876A4AAEEC3B317391EC54@osu.edu>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:164.107.81.222; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(377454003)(479174003)(24454002)(199003)(51704005)(189002)(2501002)(6806004)(19580395003)(64706001)(19580405001)(88552001)(90282001)(46406003)(4396001)(31966008)(89122001)(47776003)(36756003)(109096001)(551934003)(77096002)(20776003)(99396003)(23726002)(95666004)(75432002)(50986999)(97756001)(80022003)(46102003)(85852003)(21056001)(66066001)(86362001)(106466001)(85306004)(92566001)(50466002)(107046002)(107886001)(44976005)(106116001)(120916001)(2656002)(54356999)(87936001)(76482002)(93346002)(92726001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2FFO11HUB067; H:cio-tnc-pf08.osuad.osu.edu; FPR:; MLV:sfv; PTR:cio-tnc-pf08.osuad.osu.edu; A:1; MX:1; LANG:en; 
X-Microsoft-Antispam: UriScan:;
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2FFO11HUB067;
X-Forefront-PRVS: 03607C04F0
Received-SPF: Pass (protection.outlook.com: domain of osu.edu designates 164.107.81.222 as permitted sender) receiver=protection.outlook.com; client-ip=164.107.81.222; helo=cio-tnc-pf08.osuad.osu.edu;
Authentication-Results: spf=pass (sender IP is 164.107.81.222) smtp.mailfrom=cantor.2@osu.edu; 
X-OriginatorOrg: osu.edu
Archived-At: http://mailarchive.ietf.org/arch/msg/vot/vkaUqN2F2bat_f_WCMohNeQCmzo
Subject: Re: [VoT] Vectors of Trust: A Strawman
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Vectors of Trust discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Oct 2014 01:30:27 -0000

On 10/2/14, 5:10 PM, "Richer, Justin P."  wrote:

>I'm going to propose 4 here, all of them linear scales. As a side note,
>it's a question whether all of these are even linear scales, but I think
>it's important that we define comparison metrics on each vector element
>as well as the overall values.

As I said in another note, I'm not sure any of them are really linear or
that reducing them to that is an accurate way of communicating anything
useful, but I'm also not sure there's an alternative that's palatable.
It's a question of how lossy it's possible to be and not lose the signal I
guess.

>Identity proofing:
>
>This covers how sure the IdP is of various attributes about the user on
>the way in, and how much they're willing to vouch for those attributes.

Are we proposing that this is intrinsically per-attribute? Something that
people have been dancing around for years, really.

As others mentioned, I think it's even better to avoid the word identity
entirely. There is no well-defined notion of "physical identity" in the
digital space, only poorly expressed approximations. I think there are
only attributes.

>Credential strength:
>This covers how strongly bound the primary credential is to an individual
>presenter, and how easily spoofed or stolen it is.

Maybe the word "and" in that sentence demonstrates that there are multiple
vectors in play there.

>Assertion presentation:
>
>This covers how much the federation protocol leaks information over the
>network to various parties, and how much of that information could be
>tampered in transit without the RP noticing.
>
>0: no protection / leaky
>1: signed & verifiable through browser
>2: signed & verifiable through back channel
>3: target-encrypted to RP's own key

I think somebody else noted those are themselves orthogonal.
Confidentality and integrity/strength are tunable independently.


>Operational management:
>
>This covers a variety of information about the identity provider and its
>host organization. What's the OpSec policy of the IdP? Is there disaster
>recovery in place? How mature is the hosting organization? What kind of
>incident response can be expected?
> How strongly bound is a particular attribute to a particular credential
>[though maybe this fits under identity proofing]? You'll note that
>already this feels a lot less linear and a lot less defined than the
>other three.

It's much more well defined IMHO, but decidedly less linear.

>Finally, I think we need to think about and discuss the notion of the
>assessment and trustmarks that would be powering the trust in all of
>these values. After all, if they're just self-asserted by the IdP, that
>doesn't really help anyone. However, if we had a discovery mechanism
>whereby a trustmark provider would be able to host a machine-readable
>definition of what vectors a particular IdP has been proven to be able to
>claim for any transaction, I think we've got a good leg up on the problem.

Yes, we've been using SAML metadata to do these kinds of things for a
while now.

-- Scott


From nobody Thu Oct  9 18:41:53 2014
Return-Path: 
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F414B1AD051 for ; Thu,  9 Oct 2014 18:41:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level: 
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJ6scC7cqwMl for ; Thu,  9 Oct 2014 18:41:49 -0700 (PDT)
Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8286F1AD048 for ; Thu,  9 Oct 2014 18:41:49 -0700 (PDT)
Received: by mail-vc0-f175.google.com with SMTP id id10so1926724vcb.6 for ; Thu, 09 Oct 2014 18:41:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vAoCcB6FvtiLx0cyHiUekfrGlJJwUAv/eFVNT63uAiw=; b=MD7JbfkFumFRe89pnTrkmmuYE3Y2euRqEKYIq9LpkHR2+/+QOYhrHNCXC2h8F7gfoY fZJTALFwH8T+lYch5GobV5ZkBkZ7cljyj8J0cwHqqf+KwD1kHPyZTGxUviDH6yBTq6ZZ NmCpm9cnmoT/VUmaEqrBRm6ROARJVdKYsihp7/pKf3ijrfFuEVpubo0rNj3Za88RsW4L rV7bwWkMGNMpnk1WR19JJZEuzhezuyj25wuR5xojqgzu132/KZXps3WGYvuCgNVupqdA We3C4SKlpqyCZ9kfQw2RCuLjns9FAnGSEu9fK8lTaIOs5otYkNAFNwJ7NEfrGCmpxEmJ dAvA==
MIME-Version: 1.0
X-Received: by 10.220.185.72 with SMTP id cn8mr1976372vcb.26.1412905308715; Thu, 09 Oct 2014 18:41:48 -0700 (PDT)
Received: by 10.220.88.199 with HTTP; Thu, 9 Oct 2014 18:41:48 -0700 (PDT)
In-Reply-To: <1412885935.58929166@apps.rackspace.com>
References: <1412885935.58929166@apps.rackspace.com>
Date: Thu, 9 Oct 2014 21:41:48 -0400
Message-ID: 
From: Ken Dagg 
To: "swilson@lockstep.com.au" 
Content-Type: multipart/alternative; boundary=001a11c2c44a070a6d050507a7d3
Archived-At: http://mailarchive.ietf.org/arch/msg/vot/_M9xOFpnJZqsn3nx9OoMxFdds4U
Cc: "vot@ietf.org" 
Subject: Re: [VoT] Foundational questions of principle
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Vectors of Trust discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Oct 2014 01:41:52 -0000

--001a11c2c44a070a6d050507a7d3
Content-Type: text/plain; charset=UTF-8

Steve,

As we have communicated in the past, I am a strong believer the an LOA
designation is an indication of the processes/mechanisms that an IdP has
undertaken. In other words, it is a communication tool. The choice is the
RPs. That is, an assertion at a specific LOA by an IdP/CSP/AP is one of the
mechanisms a RP should use to offset the authentication risk it has
identified for the service it wants to deliver. In other words, it is the
risk of the RP that is paramount not the claims of
an identity/credential/attribute/token provider.

Like you, I am a strong believer that the determination of whether or not
an identity is good enough is the responsibility of the RP. In my
experience, they make that determination based upon a set of attributes
they believe are necessary. If they trust that an IdP's assertion of
identity covers the attributes they believe are required them they can
accept the assertion. If it doesn't then that have to implement additional
mechanisms to offset the residual risk.

With respect to vectors of trust, I am interested in exploring what they
are and how they can be applied.

Ken

On Thursday, October 9, 2014,  wrote:

>
>
> First, to introduce myself, I am an identity and privacy researcher,
> analyst and consultant.  I've been involved in this since 1995, when I cut
> my teeth in PKI and smartcards (with the early companies that became
> Baltimore Technologies). Since then I've worked on identity management
> frameworks, regulations and standards.
>
>
>
> I subscribe to the old Italian proverb: "it's nice to trust but better not
> to".  Words matter and I wonder if we shouldn't be using the word trust so
> much.
>
>
>
> More pragmatically, I note the very strong "Attributes" push of the past
> 18 months.  Andrew Nash, Anil John, myself and others have written about
> this.  The FIDO Alliance is all about authentication and attributes, and
> they purposefully leave "identity" as a matter for others to work out
> further up the stack. The OID Foundation is promoting an Attributes
> Exchange Network "AXN" architecture.  New entrants like id.me (an NSTIC
> pilot participant) talk about attributes and avoid "identity".
>
>
>
> I mention all of this as a prelude to suggest that "vector of trust" is
> synonymous with "attribute". I wonder if it would be clearer to use plain
> and current language rather than carry forward the fuzzy and I think overly
> ambitious idea of "trust"?
>
>
>
> Finally, I'd like to throw in my abiding concern that LOAs have foundered
> simply because it's difficult to pigeonhole risk. One party's idea of
> "medium" risk for instance will rarely map precisely to another's. I think
> people have been misled into thinking that an "LOA 3" identity should be be
> able to be used on its face (i.e. will "interoperate") at any "LOA 3" RP.
> Risk management is not so simple.
>
>
>
> The LOA paradigm borrows from Risk Management standards like ISO 31000
> which organisations use to plot their own risks internally typically on a
> five scale (eg Negligible / Low / Medium / High / Grave). But risk
> management standards require that each organisation calibrates risk in its
> own business context and according to its own risk appetite. The risk of a
> firewall breach for example at a startup social media company will be
> assessed differently by a big listed healthcare company. So organisation
> A can say the risk of event X is Low but B can say the risk of the same
> event is Medium.  As a result, LOAs do not inter-operate. They are based on
> standards meant for intra-organisation risk management, not
> inter-organisation communication of risk assessments.
>
>
>
> So far with VoT we are adding more dimensions to the RPs' generic risk
> management decision making, and that's great.  But we are still
> pigeonholing the dimensions.
>
>
>
> I'm afraid the reality is that risk management will always be done
> locally.  And so it should be.  When an RP is making the decision to accept
> or reject a given subject, they will evaluate a range of attributes
> or signals.  The set of attributes that matters varies from one RP to the
> next.  I think it's a great idea indeed to create guidance for evaluating
> attributes, and to coach RPs to look at all sorts of dimensions.  I just
> don't think it helps anyone to pigeonhole the risk ratings, because across
> organisations, arguments about the boundaries between LOA 1/2/3/4 (that is,
> policy mapping) will undo any efficiencies gained from the categorization.
>
>
>
> Cheers,
>
>
>
> Steve.
>
>
>
>
>
> Stephen Wilson
> Managing Director
> Lockstep Group
> http://lockstep.com.au
> Lockstep Consulting provides independent specialist advice and analysis
> on digital identity and privacy. Lockstep Technologies develops unique
> new smart ID solutions that enhance privacy and prevent identity theft.
>
>
>
>
>
>
>

--001a11c2c44a070a6d050507a7d3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Steve,

As we have communicated in=C2=A0the past, I am a =
strong believer the an LOA designation is an indication of the processes/me=
chanisms that an=C2=A0IdP has undertaken. In other words, it is a communica=
tion tool.=C2=A0The choice is the RPs. That is, an=C2=A0assertion at a spec=
ific LOA by an=C2=A0IdP/CSP/AP=C2=A0is one of the mechanisms a RP should us=
e to offset the authentication risk it has identified for the service it wa=
nts to deliver. In other words, it is the risk of the RP that is paramount =
not the claims of an=C2=A0identity/credential/attribute/token provider.

Like you, I am a strong believer that the determinati=
on of whether or not an identity is good enough is the responsibility of th=
e RP. In my experience, they make that determination based upon a set of at=
tributes they believe are necessary. If they trust that an IdP's assert=
ion of identity covers the attributes they believe are=C2=A0required them t=
hey can accept the assertion. If it doesn't then that have to implement=
 additional mechanisms to offset the residual risk.

With respect to vectors of trust, I am interested in exploring what they =
are and how they can be applied.

Ken

On Thu=
rsday, October 9, 2014,  <swi=
lson@lockstep.com.au> wrote:
=C2=A0


First, to introduce myself, I am an identity and privacy researc=
her, analyst and consultant.=C2=A0 I've been involved in this since 199=
5, when I cut my teeth in PKI and smartcards (with the early companies that=
 became Baltimore Technologies). Since then I've worked on identity man=
agement frameworks, regulations and standards. =C2=A0


=C2=A0


I subscribe to the old Italian proverb: "it's nice to t=
rust but better not to".=C2=A0 Words matter and I wonder if we shouldn=
't be using the word trust so much. =C2=A0


=C2=A0


More pragmatically, I note the very strong "Attributes"=
; push of the past 18 months.=C2=A0 Andrew Nash, Anil John, myself and othe=
rs have written about this.=C2=A0 The FIDO Alliance is all about authentica=
tion and attributes, and they purposefully leave "identity" as a =
matter for others to work out further up the stack. The OID Foundation is p=
romoting an Attributes Exchange Network "AXN" architecture.=C2=A0=
 New entrants like id.me (an=
 NSTIC pilot participant) talk about attributes and avoid "identity&qu=
ot;.=C2=A0


=C2=A0


I mention all of this as a prelude to suggest that "vector =
of trust" is synonymous with "attribute". I wonder if it wou=
ld be clearer to use plain and current language rather than carry forward t=
he fuzzy and I think overly ambitious idea of "trust"?=C2=A0


=C2=A0


Finally, I'd like to throw in my abiding concern that LOAs h=
ave foundered simply because it's difficult to pigeonhole risk. One par=
ty's idea of "medium" risk for instance will rarely map preci=
sely to another's. I think people have been misled into thinking that a=
n "LOA 3" identity should be be able to be used on its face (i.e.=
 will "interoperate") at any "LOA 3" RP. Risk managemen=
t is not so simple.=C2=A0


=C2=A0


The LOA paradigm borrows from Risk Management standards like ISO=
 31000 which=C2=A0organisations use to=C2=A0plot=C2=A0their own risks inter=
nally typically on a five scale (eg Negligible / Low / Medium / High / Grav=
e).=C2=A0But=C2=A0risk management=C2=A0standards require that each organisa=
tion calibrates risk in its own business context and according to its=C2=A0=
own risk appetite. The risk of a firewall breach for example at a startup s=
ocial media company will be assessed differently by a big listed healthcare=
 company.=C2=A0So organisation A=C2=A0can say the risk of event X is Low bu=
t B can say the risk of the same event is Medium.=C2=A0 As=C2=A0a result, L=
OAs do not inter-operate. They are based on standards meant for intra-organ=
isation risk management, not inter-organisation communication of=C2=A0risk =
assessments.=C2=A0


=C2=A0


So far with VoT we are adding more dimensions to the RPs' ge=
neric risk management decision making, and that's great.=C2=A0 But we a=
re still pigeonholing the dimensions.


=C2=A0


I'm afraid the reality is that risk management will always b=
e done locally.=C2=A0 And so it should be.=C2=A0 When an RP is making=C2=A0=
the decision to accept or reject a given subject, they will evaluate a rang=
e of attributes or=C2=A0signals.=C2=A0 The set of attributes that matters v=
aries from one RP to the next.=C2=A0 I think it's a great idea indeed t=
o create guidance for evaluating attributes, and to coach RPs to look at al=
l sorts of dimensions.=C2=A0 I just don't think it helps anyone to pige=
onhole the risk ratings, because across organisations, arguments about the =
boundaries between LOA 1/2/3/4 (that is, policy mapping) will=C2=A0undo any=
 efficiencies gained from the categorization. =C2=A0


=C2=A0


Cheers,=C2=A0


=C2=A0


Steve.


=C2=A0


=C2=A0


Stephen Wilson
Managing Director
Lockstep Group
http://lockstep.com.auLockstep Consulting provides independent specialist advice and analysis on digital identity and privacy. Lockstep Technologies develops unique new smart ID solutions that enhance privacy and prevent identity theft.

=C2=A0


=C2=A0


=C2=A0


--001a11c2c44a070a6d050507a7d3--


From nobody Fri Oct 10 00:08:31 2014
Return-Path: 
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A85D31A1A69 for ; Fri, 10 Oct 2014 00:08:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.55
X-Spam-Level: 
X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PuLpGoLO2GOw for ; Fri, 10 Oct 2014 00:08:24 -0700 (PDT)
Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A85861A1A29 for ; Fri, 10 Oct 2014 00:08:10 -0700 (PDT)
Received: from [81.217.70.9] (helo=[192.168.1.33]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XcUIy-0002uG-UO; Fri, 10 Oct 2014 09:08:01 +0200
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: multipart/alternative; boundary="Apple-Mail=_3656B784-3764-4352-9D20-4162C85D40CD"
From: Rainer Hoerbe 
X-Priority: 3 (Normal)
In-Reply-To: <1412896617.869315461@apps.rackspace.com>
Date: Fri, 10 Oct 2014 09:07:58 +0200
Message-Id: <789542E6-3D10-4364-8B22-BD30CD08F524@hoerbe.at>
References: <1412885935.58929166@apps.rackspace.com> <04CF3DDE-9FDF-499A-8093-3EC3CE84E4DF@identinetics.com> <1412896617.869315461@apps.rackspace.com>
To: Wilson Stephen 
X-Mailer: Apple Mail (2.1878.6)
X-Df-Sender: cmhAaWRlbnRpbmV0aWNzLmNvbQ==
Archived-At: http://mailarchive.ietf.org/arch/msg/vot/wAGAhy6jc4wrIyOqXtVTcNiW8ag
Cc: vot@ietf.org
Subject: Re: [VoT] Foundational questions of principle
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Vectors of Trust discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Oct 2014 07:08:26 -0000

--Apple-Mail=_3656B784-3764-4352-9D20-4162C85D40CD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Am 10.10.2014 um 01:16 schrieb swilson@lockstep.com.au:

> =20
> Rainer,=20
> =20
> I like your approach.  But I think we should review what the objective =
is of LOAs in general, and question whether or not labeling things by =
"level" is a useful idea. Yes we need to help organisations better =
understand and manage authentication risk, but is "LOA" is a necessary =
output of that process?  Doesn't a four level label over simplify =
things? I find it's a misleading shorthand that leads people to believe =
that a given identity can be used at a given RP without any further =
analysis. =20
> =20
> We can do all the things you say below, but stop short of attaching =
the "level".=20

We shouldn't condemn levels altogether. They do work reasonably well =
within sectors, such as specific supply chains, payment industry or =
government-to-government. It is the idea of a cross-sector interoperable =
LoA that does not scale. My experience from AT e-gov tells me that a =
larger part of RPs struggles with policies that are more complex than a =
few pages describing LoA 1-4.=20

- Rainer





--Apple-Mail=_3656B784-3764-4352-9D20-4162C85D40CD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Am =
10.10.2014 um 01:16 schrieb swilson@lockstep.com.au:

 
Rainer, 
 
I like =
your approach.  But I think we should review what the objective is =
of LOAs in general, and question whether or not labeling things by =
"level" is a useful idea. Yes we need to help organisations better =
understand and manage authentication risk, but is "LOA" is a =
necessary output of that process?  Doesn't a four level label =
over simplify things? I find it's a misleading shorthand that leads =
people to believe that a given identity can be used at a given RP =
without any further analysis.  
 
We can =
do all the things you say below, but stop short of attaching the =
"level". 

We shouldn't =
condemn levels altogether. They do work reasonably well within sectors, =
such as specific supply chains, payment industry or =
government-to-government. It is the idea of a cross-sector interoperable =
LoA that does not scale. My experience from AT e-gov tells me that a =
larger part of RPs struggles with policies that are more complex than a =
few pages describing LoA 1-4. 

- =
Rainer




=

--Apple-Mail=_3656B784-3764-4352-9D20-4162C85D40CD--


From nobody Fri Oct 10 07:51:42 2014
Return-Path: 
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 486B81ACE23 for ; Fri, 10 Oct 2014 07:51:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.69
X-Spam-Level: 
X-Spam-Status: No, score=-4.69 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, MISSING_MID=0.497, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zPoq_gic1aPu for ; Fri, 10 Oct 2014 07:51:37 -0700 (PDT)
Received: from EXT1.tbs-sct.gc.ca (ext1.tbs-sct.gc.ca [205.193.174.40]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B99B91A1A7D for ; Fri, 10 Oct 2014 07:51:36 -0700 (PDT)
From: "Bouma, Tim" 
To: Ken Dagg , "swilson@lockstep.com.au" 
Date: Fri, 10 Oct 2014 10:51:32 -0400
Thread-Topic: [VoT] Foundational questions of principle
Thread-Index: Ac/kK3gwc69YRrlYTk2mLUp1tu1IvAAa59Cg
References: <1412885935.58929166@apps.rackspace.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-tituslabs-classifications-30: TLPropertyRoot=TBSSCT;Classification=No Classification Selected;
x-titus-version: 3.5.30.1
x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IsCjFstXg0aV2KPh0b7iOMbQGGYonO+alj8mo8s0AtwJJn9OT+EUnErU+xl/6yA7ov4wQBeqr9ksI7zXtM9XexndS24Fo8QX7IqLhvu8y6M4zDD3+QdMA9jDoqYs0YkWVU6okMeK1T6tzOmIHa5s5c+Bdy3l8WJu5M2RDYGtWVJl/PtWW0KMsz7paNbFexB2Kpkv6JiqUlzfhIRapZ9+XHGi299YpouEnH6RvvMsNrpZ
x-secclass: CLASSN
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_B74E7D085FA151499EBC26F775ACC89D0A8ED5CCBBEXTBS3tbssctl_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/vot/AaqwIlRPmdA2eRWaj_GgRYMFHpU
Cc: "vot@ietf.org" 
Subject: Re: [VoT] Foundational questions of principle
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Vectors of Trust discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Oct 2014 14:51:40 -0000

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

SSBhZ3JlZSB3aXRoIEtlbiwNCg0KV2hlbiB3ZSBkZXZlbG9wZWQgbGV2ZWxzIG9mIGFzc3VyYW5j
ZSAoaGVyZSBpbiBDYW5hZGEpIHdlIGRpZCBzZXZlcmFsIHRoaW5nczoNCg0KDQrCtyAgICAgICAg
IFdlIGRlZmluZWQgdGhlbSBhcyBsZXZlbHMgb2YgY29uZmlkZW5jZSByZXF1aXJlZCAoTGV2ZWxz
IDEgdGhyb3VnaCA0KQ0KDQrCtyAgICAgICAgIFdlIG1hcHBlZCB0aGVzZSBsZXZlbHMgb2YgY29u
ZmlkZW5jZSB0byBhIHJhbmdlIG9mIGRlZ3JlZSBvZiBpbXBhY3RzLg0KDQrCtyAgICAgICAgIFdl
IHRoZW4gc3BlY2lmaWVkIHNlcGFyYXRlbHkgaWRlbnRpdHkgYXNzdXJhbmNlIGxldmVscyBhbmQg
Y3JlZGVudGlhbCBhc3N1cmFuY2UgbGV2ZWxzIChhbmQgZm9jdXNlZCBvbiBjcmVkZW50aWFsIGZp
cnN0KQ0KDQrCtyAgICAgICAgIFdlIGFsc28gZmFjdG9yZWQgb3V0IGxpa2VsaWhvb2QgaW4gdGhl
IGFzc3VyYW5jZSBsZXZlbCBhc3Nlc3NtZW50IHByb2Nlc3MuIFRoYXQgbWFkZSB0aGUgYXNzZXNz
bWVudHMgbXVjaCBsZXNzIHN1YmplY3RpdmUuDQoNCkF0IHRoZSBlbmQgb2YgdGhlIGRheSwgYXMg
S2VuIHN0YXRlcywgIGl04oCZcyB0aGUgam9iIHRoZSBSUCB0byB1bmRlcnN0YW5kIHRoZWlyIHJp
c2sgKGFsb25nIHdpdGggbGlrZWxpaG9vZCkgYW5kIHRvIGNvbW11bmljYXRlIGEgc3RhbmRhcmRp
emVkIHJlcXVpcmVtZW50IGJhY2sgdG8gYSBwcm92aWRlciAoQVApDQpUaGUgQVAgaXMgIGFjY291
bnRhYmxlIGZvciBwcm92aWRpbmcgYSB2ZXJ5IHByZXNjcmliZWQgY29tcG9uZW50IHRoYXQgZml0
cyBpbnRvIGEgbGFyZ2VyIHN5c3RlbSBhbmQgYSByaXNrIGVudmlyb25tZW50IHRoYXQgdGhleSBt
aWdodCBub3QgaGF2ZSBhIGZ1bGwgdmlldyBpbnRvLiBUaGUgUlAgbWF5IHB1dCBpbiBwcm92aXNp
b25zIHRvIHNoYXJlIHRoZSByaXNrIHdpdGggdGhlIEFQLCBvciBub3QgYnV0IHRoYXQgZW50aXJl
bHkgZGVwZW5kcyBvbiB0aGUgYXJyYW5nZW1lbnQsIGJ1dCBhdCBsZWFzdCB0aGUgUlAgYW5kIEFQ
IHVuZGVyc3RhbmQgd2hhdOKAmXMgb24gdGhlIHRhYmxlIGFzIGEgc3RhcnRpbmcgcG9pbnQuDQoN
CkluIENhbmFkYSwgd2UgZGlkIHRoYXQgd2l0aCB0aGUgY3JlZGVudGlhbCBmaXJzdCwgYW5kIGFy
ZSBub3cgZmlndXJpbmcgb3V0IGlkZW50aXR5IChtdWNoIGhhcmRlcikuDQoNCkkgYWxzbyBhZ3Jl
ZSB0aGF0IOKAmGlkZW50aXR54oCZIGlzIGp1c3QgYSBzZXQgb2YgYXR0cmlidXRlcyDigJNhbmQg
IHRoZXNlIGlkZW50aXR5IGF0dHJpYnV0ZXMgY2FuIHZhcnkgYmV0d2VlbiBvcmdhbml6YXRpb25z
IG9yIGp1cmlzZGljdGlvbnMsDQoNCkFzIGZvciB0aGUgdGVybSDigJh2ZWN0b3Jz4oCZLCBJIGdl
dCB0aGUgaWRlYSwgYnV0IEkgdGhpbmsgdGhlIGNvbW11bml0eSB3aWxsIHRoaW5rIGl04oCZcyB0
b28gdGVjaG5pY2FsIG9yIGVzb3RlcmljLiBJIGxpa2UgdG8gdGhpbmsgb2YgYSDigJhkaWdpdGFs
IGlkZW50aXR54oCZIChvciB3aGF0ZXZlciB5b3UgY2FsbCBpdCksIHdoZW4gaXQgc2hvd3MgdXAg
YXQgeW91ciBkaWdpdGFsIGZyb250IGRvb3IsIGl0IGlzIHRoZSBwcm9kdWN0IG9mIGEgdmVyeSBs
b25nLCBjb21wbGV4IHN1cHBseSBjaGFpbiwgZnJhdWdodCB3aXRoIG1hbnkgcmlza3MgYW5kIGNv
bXByb21pc2VzLiBJIG1heSBoYXZlIGNvbmZpZGVuY2UgaW4gY2VydGFpbiBwaWVjZXMgb2YsIGJ1
dCBvdGhlciBJIG1pZ2h0IG5vdCB0cnVzdCBhdCBhbGwuDQoNCg0KVGltDQoNCg0KRnJvbTogdm90
IFttYWlsdG86dm90LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBLZW4gRGFnZw0KU2Vu
dDogT2N0b2Jlci0wOS0xNCA5OjQyIFBNDQpUbzogc3dpbHNvbkBsb2Nrc3RlcC5jb20uYXUNCkNj
OiB2b3RAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbVm9UXSBGb3VuZGF0aW9uYWwgcXVlc3Rpb25z
IG9mIHByaW5jaXBsZQ0KDQpTdGV2ZSwNCg0KQXMgd2UgaGF2ZSBjb21tdW5pY2F0ZWQgaW4gdGhl
IHBhc3QsIEkgYW0gYSBzdHJvbmcgYmVsaWV2ZXIgdGhlIGFuIExPQSBkZXNpZ25hdGlvbiBpcyBh
biBpbmRpY2F0aW9uIG9mIHRoZSBwcm9jZXNzZXMvbWVjaGFuaXNtcyB0aGF0IGFuIElkUCBoYXMg
dW5kZXJ0YWtlbi4gSW4gb3RoZXIgd29yZHMsIGl0IGlzIGEgY29tbXVuaWNhdGlvbiB0b29sLiBU
aGUgY2hvaWNlIGlzIHRoZSBSUHMuIFRoYXQgaXMsIGFuIGFzc2VydGlvbiBhdCBhIHNwZWNpZmlj
IExPQSBieSBhbiBJZFAvQ1NQL0FQIGlzIG9uZSBvZiB0aGUgbWVjaGFuaXNtcyBhIFJQIHNob3Vs
ZCB1c2UgdG8gb2Zmc2V0IHRoZSBhdXRoZW50aWNhdGlvbiByaXNrIGl0IGhhcyBpZGVudGlmaWVk
IGZvciB0aGUgc2VydmljZSBpdCB3YW50cyB0byBkZWxpdmVyLiBJbiBvdGhlciB3b3JkcywgaXQg
aXMgdGhlIHJpc2sgb2YgdGhlIFJQIHRoYXQgaXMgcGFyYW1vdW50IG5vdCB0aGUgY2xhaW1zIG9m
IGFuIGlkZW50aXR5L2NyZWRlbnRpYWwvYXR0cmlidXRlL3Rva2VuIHByb3ZpZGVyLg0KDQpMaWtl
IHlvdSwgSSBhbSBhIHN0cm9uZyBiZWxpZXZlciB0aGF0IHRoZSBkZXRlcm1pbmF0aW9uIG9mIHdo
ZXRoZXIgb3Igbm90IGFuIGlkZW50aXR5IGlzIGdvb2QgZW5vdWdoIGlzIHRoZSByZXNwb25zaWJp
bGl0eSBvZiB0aGUgUlAuIEluIG15IGV4cGVyaWVuY2UsIHRoZXkgbWFrZSB0aGF0IGRldGVybWlu
YXRpb24gYmFzZWQgdXBvbiBhIHNldCBvZiBhdHRyaWJ1dGVzIHRoZXkgYmVsaWV2ZSBhcmUgbmVj
ZXNzYXJ5LiBJZiB0aGV5IHRydXN0IHRoYXQgYW4gSWRQJ3MgYXNzZXJ0aW9uIG9mIGlkZW50aXR5
IGNvdmVycyB0aGUgYXR0cmlidXRlcyB0aGV5IGJlbGlldmUgYXJlIHJlcXVpcmVkIHRoZW0gdGhl
eSBjYW4gYWNjZXB0IHRoZSBhc3NlcnRpb24uIElmIGl0IGRvZXNuJ3QgdGhlbiB0aGF0IGhhdmUg
dG8gaW1wbGVtZW50IGFkZGl0aW9uYWwgbWVjaGFuaXNtcyB0byBvZmZzZXQgdGhlIHJlc2lkdWFs
IHJpc2suDQoNCldpdGggcmVzcGVjdCB0byB2ZWN0b3JzIG9mIHRydXN0LCBJIGFtIGludGVyZXN0
ZWQgaW4gZXhwbG9yaW5nIHdoYXQgdGhleSBhcmUgYW5kIGhvdyB0aGV5IGNhbiBiZSBhcHBsaWVk
Lg0KDQpLZW4NCg0KT24gVGh1cnNkYXksIE9jdG9iZXIgOSwgMjAxNCwgPHN3aWxzb25AbG9ja3N0
ZXAuY29tLmF1PG1haWx0bzpzd2lsc29uQGxvY2tzdGVwLmNvbS5hdT4+IHdyb3RlOg0KDQoNCg0K
Rmlyc3QsIHRvIGludHJvZHVjZSBteXNlbGYsIEkgYW0gYW4gaWRlbnRpdHkgYW5kIHByaXZhY3kg
cmVzZWFyY2hlciwgYW5hbHlzdCBhbmQgY29uc3VsdGFudC4gIEkndmUgYmVlbiBpbnZvbHZlZCBp
biB0aGlzIHNpbmNlIDE5OTUsIHdoZW4gSSBjdXQgbXkgdGVldGggaW4gUEtJIGFuZCBzbWFydGNh
cmRzICh3aXRoIHRoZSBlYXJseSBjb21wYW5pZXMgdGhhdCBiZWNhbWUgQmFsdGltb3JlIFRlY2hu
b2xvZ2llcykuIFNpbmNlIHRoZW4gSSd2ZSB3b3JrZWQgb24gaWRlbnRpdHkgbWFuYWdlbWVudCBm
cmFtZXdvcmtzLCByZWd1bGF0aW9ucyBhbmQgc3RhbmRhcmRzLg0KDQoNCg0KSSBzdWJzY3JpYmUg
dG8gdGhlIG9sZCBJdGFsaWFuIHByb3ZlcmI6ICJpdCdzIG5pY2UgdG8gdHJ1c3QgYnV0IGJldHRl
ciBub3QgdG8iLiAgV29yZHMgbWF0dGVyIGFuZCBJIHdvbmRlciBpZiB3ZSBzaG91bGRuJ3QgYmUg
dXNpbmcgdGhlIHdvcmQgdHJ1c3Qgc28gbXVjaC4NCg0KDQoNCk1vcmUgcHJhZ21hdGljYWxseSwg
SSBub3RlIHRoZSB2ZXJ5IHN0cm9uZyAiQXR0cmlidXRlcyIgcHVzaCBvZiB0aGUgcGFzdCAxOCBt
b250aHMuICBBbmRyZXcgTmFzaCwgQW5pbCBKb2huLCBteXNlbGYgYW5kIG90aGVycyBoYXZlIHdy
aXR0ZW4gYWJvdXQgdGhpcy4gIFRoZSBGSURPIEFsbGlhbmNlIGlzIGFsbCBhYm91dCBhdXRoZW50
aWNhdGlvbiBhbmQgYXR0cmlidXRlcywgYW5kIHRoZXkgcHVycG9zZWZ1bGx5IGxlYXZlICJpZGVu
dGl0eSIgYXMgYSBtYXR0ZXIgZm9yIG90aGVycyB0byB3b3JrIG91dCBmdXJ0aGVyIHVwIHRoZSBz
dGFjay4gVGhlIE9JRCBGb3VuZGF0aW9uIGlzIHByb21vdGluZyBhbiBBdHRyaWJ1dGVzIEV4Y2hh
bmdlIE5ldHdvcmsgIkFYTiIgYXJjaGl0ZWN0dXJlLiAgTmV3IGVudHJhbnRzIGxpa2UgaWQubWU8
aHR0cDovL2lkLm1lPiAoYW4gTlNUSUMgcGlsb3QgcGFydGljaXBhbnQpIHRhbGsgYWJvdXQgYXR0
cmlidXRlcyBhbmQgYXZvaWQgImlkZW50aXR5Ii4NCg0KDQoNCkkgbWVudGlvbiBhbGwgb2YgdGhp
cyBhcyBhIHByZWx1ZGUgdG8gc3VnZ2VzdCB0aGF0ICJ2ZWN0b3Igb2YgdHJ1c3QiIGlzIHN5bm9u
eW1vdXMgd2l0aCAiYXR0cmlidXRlIi4gSSB3b25kZXIgaWYgaXQgd291bGQgYmUgY2xlYXJlciB0
byB1c2UgcGxhaW4gYW5kIGN1cnJlbnQgbGFuZ3VhZ2UgcmF0aGVyIHRoYW4gY2FycnkgZm9yd2Fy
ZCB0aGUgZnV6enkgYW5kIEkgdGhpbmsgb3Zlcmx5IGFtYml0aW91cyBpZGVhIG9mICJ0cnVzdCI/
DQoNCg0KDQpGaW5hbGx5LCBJJ2QgbGlrZSB0byB0aHJvdyBpbiBteSBhYmlkaW5nIGNvbmNlcm4g
dGhhdCBMT0FzIGhhdmUgZm91bmRlcmVkIHNpbXBseSBiZWNhdXNlIGl0J3MgZGlmZmljdWx0IHRv
IHBpZ2VvbmhvbGUgcmlzay4gT25lIHBhcnR5J3MgaWRlYSBvZiAibWVkaXVtIiByaXNrIGZvciBp
bnN0YW5jZSB3aWxsIHJhcmVseSBtYXAgcHJlY2lzZWx5IHRvIGFub3RoZXIncy4gSSB0aGluayBw
ZW9wbGUgaGF2ZSBiZWVuIG1pc2xlZCBpbnRvIHRoaW5raW5nIHRoYXQgYW4gIkxPQSAzIiBpZGVu
dGl0eSBzaG91bGQgYmUgYmUgYWJsZSB0byBiZSB1c2VkIG9uIGl0cyBmYWNlIChpLmUuIHdpbGwg
ImludGVyb3BlcmF0ZSIpIGF0IGFueSAiTE9BIDMiIFJQLiBSaXNrIG1hbmFnZW1lbnQgaXMgbm90
IHNvIHNpbXBsZS4NCg0KDQoNClRoZSBMT0EgcGFyYWRpZ20gYm9ycm93cyBmcm9tIFJpc2sgTWFu
YWdlbWVudCBzdGFuZGFyZHMgbGlrZSBJU08gMzEwMDAgd2hpY2ggb3JnYW5pc2F0aW9ucyB1c2Ug
dG8gcGxvdCB0aGVpciBvd24gcmlza3MgaW50ZXJuYWxseSB0eXBpY2FsbHkgb24gYSBmaXZlIHNj
YWxlIChlZyBOZWdsaWdpYmxlIC8gTG93IC8gTWVkaXVtIC8gSGlnaCAvIEdyYXZlKS4gQnV0IHJp
c2sgbWFuYWdlbWVudCBzdGFuZGFyZHMgcmVxdWlyZSB0aGF0IGVhY2ggb3JnYW5pc2F0aW9uIGNh
bGlicmF0ZXMgcmlzayBpbiBpdHMgb3duIGJ1c2luZXNzIGNvbnRleHQgYW5kIGFjY29yZGluZyB0
byBpdHMgb3duIHJpc2sgYXBwZXRpdGUuIFRoZSByaXNrIG9mIGEgZmlyZXdhbGwgYnJlYWNoIGZv
ciBleGFtcGxlIGF0IGEgc3RhcnR1cCBzb2NpYWwgbWVkaWEgY29tcGFueSB3aWxsIGJlIGFzc2Vz
c2VkIGRpZmZlcmVudGx5IGJ5IGEgYmlnIGxpc3RlZCBoZWFsdGhjYXJlIGNvbXBhbnkuIFNvIG9y
Z2FuaXNhdGlvbiBBIGNhbiBzYXkgdGhlIHJpc2sgb2YgZXZlbnQgWCBpcyBMb3cgYnV0IEIgY2Fu
IHNheSB0aGUgcmlzayBvZiB0aGUgc2FtZSBldmVudCBpcyBNZWRpdW0uICBBcyBhIHJlc3VsdCwg
TE9BcyBkbyBub3QgaW50ZXItb3BlcmF0ZS4gVGhleSBhcmUgYmFzZWQgb24gc3RhbmRhcmRzIG1l
YW50IGZvciBpbnRyYS1vcmdhbmlzYXRpb24gcmlzayBtYW5hZ2VtZW50LCBub3QgaW50ZXItb3Jn
YW5pc2F0aW9uIGNvbW11bmljYXRpb24gb2YgcmlzayBhc3Nlc3NtZW50cy4NCg0KDQoNClNvIGZh
ciB3aXRoIFZvVCB3ZSBhcmUgYWRkaW5nIG1vcmUgZGltZW5zaW9ucyB0byB0aGUgUlBzJyBnZW5l
cmljIHJpc2sgbWFuYWdlbWVudCBkZWNpc2lvbiBtYWtpbmcsIGFuZCB0aGF0J3MgZ3JlYXQuICBC
dXQgd2UgYXJlIHN0aWxsIHBpZ2VvbmhvbGluZyB0aGUgZGltZW5zaW9ucy4NCg0KDQoNCkknbSBh
ZnJhaWQgdGhlIHJlYWxpdHkgaXMgdGhhdCByaXNrIG1hbmFnZW1lbnQgd2lsbCBhbHdheXMgYmUg
ZG9uZSBsb2NhbGx5LiAgQW5kIHNvIGl0IHNob3VsZCBiZS4gIFdoZW4gYW4gUlAgaXMgbWFraW5n
IHRoZSBkZWNpc2lvbiB0byBhY2NlcHQgb3IgcmVqZWN0IGEgZ2l2ZW4gc3ViamVjdCwgdGhleSB3
aWxsIGV2YWx1YXRlIGEgcmFuZ2Ugb2YgYXR0cmlidXRlcyBvciBzaWduYWxzLiAgVGhlIHNldCBv
ZiBhdHRyaWJ1dGVzIHRoYXQgbWF0dGVycyB2YXJpZXMgZnJvbSBvbmUgUlAgdG8gdGhlIG5leHQu
ICBJIHRoaW5rIGl0J3MgYSBncmVhdCBpZGVhIGluZGVlZCB0byBjcmVhdGUgZ3VpZGFuY2UgZm9y
IGV2YWx1YXRpbmcgYXR0cmlidXRlcywgYW5kIHRvIGNvYWNoIFJQcyB0byBsb29rIGF0IGFsbCBz
b3J0cyBvZiBkaW1lbnNpb25zLiAgSSBqdXN0IGRvbid0IHRoaW5rIGl0IGhlbHBzIGFueW9uZSB0
byBwaWdlb25ob2xlIHRoZSByaXNrIHJhdGluZ3MsIGJlY2F1c2UgYWNyb3NzIG9yZ2FuaXNhdGlv
bnMsIGFyZ3VtZW50cyBhYm91dCB0aGUgYm91bmRhcmllcyBiZXR3ZWVuIExPQSAxLzIvMy80ICh0
aGF0IGlzLCBwb2xpY3kgbWFwcGluZykgd2lsbCB1bmRvIGFueSBlZmZpY2llbmNpZXMgZ2FpbmVk
IGZyb20gdGhlIGNhdGVnb3JpemF0aW9uLg0KDQoNCg0KQ2hlZXJzLA0KDQoNCg0KU3RldmUuDQoN
Cg0KDQoNCg0KU3RlcGhlbiBXaWxzb24NCk1hbmFnaW5nIERpcmVjdG9yDQpMb2Nrc3RlcCBHcm91
cA0KaHR0cDovL2xvY2tzdGVwLmNvbS5hdQ0KTG9ja3N0ZXAgQ29uc3VsdGluZyBwcm92aWRlcyBp
bmRlcGVuZGVudCBzcGVjaWFsaXN0IGFkdmljZSBhbmQgYW5hbHlzaXMNCm9uIGRpZ2l0YWwgaWRl
bnRpdHkgYW5kIHByaXZhY3kuIExvY2tzdGVwIFRlY2hub2xvZ2llcyBkZXZlbG9wcyB1bmlxdWUN
Cm5ldyBzbWFydCBJRCBzb2x1dGlvbnMgdGhhdCBlbmhhbmNlIHByaXZhY3kgYW5kIHByZXZlbnQg
aWRlbnRpdHkgdGhlZnQuDQoNCg0KDQoNCg0KDQo=

--_000_B74E7D085FA151499EBC26F775ACC89D0A8ED5CCBBEXTBS3tbssctl_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu
dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50
PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv
bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K
CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls
eTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNl
DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7
fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg
MyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N
c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w
MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu
Iiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y
aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp
c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5
Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNv
LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1y
aWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNt
Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNl
cmlmIjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29M
aXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsN
CgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2
LjBwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250
LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJ
e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi
c2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5
bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi
Ow0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz
aXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0
O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZp
bml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTA0MTYzMTM1NzsNCgltc28tbGlz
dC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTg2NTcyNDgyMCAyNjkwMjUy
ODEgMjY5MDI1MjgzIDI2OTAyNTI4NSAyNjkwMjUyODEgMjY5MDI1MjgzIDI2OTAyNTI4NSAyNjkw
MjUyODEgMjY5MDI1MjgzIDI2OTAyNTI4NTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVs
LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt
dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p
bmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJ
e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1z
by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN
Cgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxp
c3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2
ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl
ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2lu
Z2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs
ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z
by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZv
bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1m
b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v
bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w
cHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNv
LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t
bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ
dGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6
bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4
dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np
dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N
CkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv
LWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt
YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToi
Q291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h
dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l
Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0
Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1
bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48
eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv
eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg
djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh
cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9RU4tQ0EgbGluaz1i
bHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3Jt
YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz
YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5JIGFncmVlIHdpdGggS2VuLDxvOnA+PC9vOnA+PC9z
cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFG
NDk3RCc+V2hlbiB3ZSBkZXZlbG9wZWQgbGV2ZWxzIG9mIGFzc3VyYW5jZSAoaGVyZSBpbiBDYW5h
ZGEpIHdlIGRpZCBzZXZlcmFsIHRoaW5nczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9
TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp
YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J3RleHQtaW5kZW50Oi0xOC4wcHQ7
bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEnPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxl
PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xvcjojMUY0OTdEJz48c3Bh
biBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz7CtzxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1l
cyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSdmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3
RCc+V2UgZGVmaW5lZCB0aGVtIGFzIGxldmVscyBvZiBjb25maWRlbmNlIHJlcXVpcmVkIChMZXZl
bHMgMSB0aHJvdWdoIDQpPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJh
Z3JhcGggc3R5bGU9J3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEn
PjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OlN5bWJvbDtjb2xvcjojMUY0OTdEJz48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3Jl
Jz7CtzxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3Nw
YW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD
YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+V2UgbWFwcGVkIHRoZXNlIGxldmVs
cyBvZiBjb25maWRlbmNlIHRvIGEgcmFuZ2Ugb2YgZGVncmVlIG9mIGltcGFjdHMuPG86cD48L286
cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J3RleHQtaW5kZW50
Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEnPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxz
cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xvcjojMUY0
OTdEJz48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz7CtzxzcGFuIHN0eWxlPSdmb250Ojcu
MHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxl
PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s
b3I6IzFGNDk3RCc+V2UgdGhlbiBzcGVjaWZpZWQgc2VwYXJhdGVseSBpZGVudGl0eSBhc3N1cmFu
Y2UgbGV2ZWxzIGFuZCBjcmVkZW50aWFsIGFzc3VyYW5jZSBsZXZlbHMgKGFuZCBmb2N1c2VkIG9u
IGNyZWRlbnRpYWwgZmlyc3QpPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb0xpc3RQ
YXJhZ3JhcGggc3R5bGU9J3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxm
bzEnPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OlN5bWJvbDtjb2xvcjojMUY0OTdEJz48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdu
b3JlJz7CtzxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48
L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+V2UgYWxzbyBmYWN0b3JlZCBv
dXQgbGlrZWxpaG9vZCBpbiB0aGUgYXNzdXJhbmNlIGxldmVsIGFzc2Vzc21lbnQgcHJvY2Vzcy4g
VGhhdCBtYWRlIHRoZSBhc3Nlc3NtZW50cyBtdWNoIGxlc3Mgc3ViamVjdGl2ZS48bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y
OiMxRjQ5N0QnPkF0IHRoZSBlbmQgb2YgdGhlIGRheSwgYXMgS2VuIHN0YXRlcywgwqBpdOKAmXMg
dGhlIGpvYiB0aGUgUlAgdG8gdW5kZXJzdGFuZCB0aGVpciByaXNrIChhbG9uZyB3aXRoIGxpa2Vs
aWhvb2QpIGFuZCB0byBjb21tdW5pY2F0ZSBhIHN0YW5kYXJkaXplZCByZXF1aXJlbWVudCBiYWNr
IHRvIGEgcHJvdmlkZXIgKEFQKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt
YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz
YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5UaGUgQVAgaXMgwqBhY2NvdW50YWJsZSBmb3IgcHJv
dmlkaW5nIGEgdmVyeSBwcmVzY3JpYmVkIGNvbXBvbmVudCB0aGF0IGZpdHMgaW50byBhIGxhcmdl
ciBzeXN0ZW0gYW5kIGEgcmlzayBlbnZpcm9ubWVudCB0aGF0IHRoZXkgbWlnaHQgbm90IGhhdmUg
YSBmdWxsIHZpZXcgaW50by4gVGhlIFJQIG1heSBwdXQgaW4gcHJvdmlzaW9ucyB0byBzaGFyZSB0
aGUgcmlzayB3aXRoIHRoZSBBUCwgb3Igbm90IGJ1dCB0aGF0IGVudGlyZWx5IGRlcGVuZHMgb24g
dGhlIGFycmFuZ2VtZW50LCBidXQgYXQgbGVhc3QgdGhlIFJQIGFuZCBBUCB1bmRlcnN0YW5kIHdo
YXTigJlzIG9uIHRoZSB0YWJsZSBhcyBhIHN0YXJ0aW5nIHBvaW50LjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3
RCc+SW4gQ2FuYWRhLCB3ZSBkaWQgdGhhdCB3aXRoIHRoZSBjcmVkZW50aWFsIGZpcnN0LCBhbmQg
YXJlIG5vdyBmaWd1cmluZyBvdXQgaWRlbnRpdHkgKG11Y2ggaGFyZGVyKS48bzpwPjwvbzpwPjwv
c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx
RjQ5N0QnPkkgYWxzbyBhZ3JlZSB0aGF0IOKAmGlkZW50aXR54oCZIGlzIGp1c3QgYSBzZXQgb2Yg
YXR0cmlidXRlcyDigJNhbmQgwqB0aGVzZSBpZGVudGl0eSBhdHRyaWJ1dGVzIGNhbiB2YXJ5IGJl
dHdlZW4gb3JnYW5pemF0aW9ucyBvciBqdXJpc2RpY3Rpb25zLDxvOnA+PC9vOnA+PC9zcGFuPjwv
cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+
QXMgZm9yIHRoZSB0ZXJtIOKAmHZlY3RvcnPigJksIEkgZ2V0IHRoZSBpZGVhLCBidXQgSSB0aGlu
ayB0aGUgY29tbXVuaXR5IHdpbGwgdGhpbmsgaXTigJlzIHRvbyB0ZWNobmljYWwgb3IgZXNvdGVy
aWMuIEkgbGlrZSB0byB0aGluayBvZiBhIOKAmGRpZ2l0YWwgaWRlbnRpdHnigJkgKG9yIHdoYXRl
dmVyIHlvdSBjYWxsIGl0KSwgd2hlbiBpdCBzaG93cyB1cCBhdCB5b3VyIGRpZ2l0YWwgZnJvbnQg
ZG9vciwgaXQgaXMgdGhlIHByb2R1Y3Qgb2YgYSB2ZXJ5IGxvbmcsIGNvbXBsZXggc3VwcGx5IGNo
YWluLCBmcmF1Z2h0IHdpdGggbWFueSByaXNrcyBhbmQgY29tcHJvbWlzZXMuIEkgbWF5IGhhdmUg
Y29uZmlkZW5jZSBpbiBjZXJ0YWluIHBpZWNlcyBvZiwgYnV0IG90aGVyIEkgbWlnaHQgbm90IHRy
dXN0IGF0IGFsbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu
IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp
ZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z
b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy
aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5UaW08bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y
OiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+
PGEgbmFtZT0iX19fX19yZXBseXNlcGFyYXRvciI+PC9hPjxiPjxzcGFuIGxhbmc9RU4tVVMgc3R5
bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5G
cm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPiB2b3QgW21haWx0bzp2b3QtYm91bmNl
c0BpZXRmLm9yZ10gPGI+T24gQmVoYWxmIE9mIDwvYj5LZW4gRGFnZzxicj48Yj5TZW50OjwvYj4g
T2N0b2Jlci0wOS0xNCA5OjQyIFBNPGJyPjxiPlRvOjwvYj4gc3dpbHNvbkBsb2Nrc3RlcC5jb20u
YXU8YnI+PGI+Q2M6PC9iPiB2b3RAaWV0Zi5vcmc8YnI+PGI+U3ViamVjdDo8L2I+IFJlOiBbVm9U
XSBGb3VuZGF0aW9uYWwgcXVlc3Rpb25zIG9mIHByaW5jaXBsZTxvOnA+PC9vOnA+PC9zcGFuPjwv
cD48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9y
bWFsPlN0ZXZlLDxvOnA+PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkFzIHdlIGhhdmUgY29t
bXVuaWNhdGVkIGluJm5ic3A7dGhlIHBhc3QsIEkgYW0gYSBzdHJvbmcgYmVsaWV2ZXIgdGhlIGFu
IExPQSBkZXNpZ25hdGlvbiBpcyBhbiBpbmRpY2F0aW9uIG9mIHRoZSBwcm9jZXNzZXMvbWVjaGFu
aXNtcyB0aGF0IGFuJm5ic3A7SWRQIGhhcyB1bmRlcnRha2VuLiBJbiBvdGhlciB3b3JkcywgaXQg
aXMgYSBjb21tdW5pY2F0aW9uIHRvb2wuJm5ic3A7VGhlIGNob2ljZSBpcyB0aGUgUlBzLiBUaGF0
IGlzLCBhbiZuYnNwO2Fzc2VydGlvbiBhdCBhIHNwZWNpZmljIExPQSBieSBhbiZuYnNwO0lkUC9D
U1AvQVAmbmJzcDtpcyBvbmUgb2YgdGhlIG1lY2hhbmlzbXMgYSBSUCBzaG91bGQgdXNlIHRvIG9m
ZnNldCB0aGUgYXV0aGVudGljYXRpb24gcmlzayBpdCBoYXMgaWRlbnRpZmllZCBmb3IgdGhlIHNl
cnZpY2UgaXQgd2FudHMgdG8gZGVsaXZlci4gSW4gb3RoZXIgd29yZHMsIGl0IGlzIHRoZSByaXNr
IG9mIHRoZSBSUCB0aGF0IGlzIHBhcmFtb3VudCBub3QgdGhlIGNsYWltcyBvZiBhbiZuYnNwO2lk
ZW50aXR5L2NyZWRlbnRpYWwvYXR0cmlidXRlL3Rva2VuIHByb3ZpZGVyLjxvOnA+PC9vOnA+PC9w
PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2
PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkxpa2UgeW91LCBJIGFtIGEgc3Ryb25nIGJlbGlldmVy
IHRoYXQgdGhlIGRldGVybWluYXRpb24gb2Ygd2hldGhlciBvciBub3QgYW4gaWRlbnRpdHkgaXMg
Z29vZCBlbm91Z2ggaXMgdGhlIHJlc3BvbnNpYmlsaXR5IG9mIHRoZSBSUC4gSW4gbXkgZXhwZXJp
ZW5jZSwgdGhleSBtYWtlIHRoYXQgZGV0ZXJtaW5hdGlvbiBiYXNlZCB1cG9uIGEgc2V0IG9mIGF0
dHJpYnV0ZXMgdGhleSBiZWxpZXZlIGFyZSBuZWNlc3NhcnkuIElmIHRoZXkgdHJ1c3QgdGhhdCBh
biBJZFAncyBhc3NlcnRpb24gb2YgaWRlbnRpdHkgY292ZXJzIHRoZSBhdHRyaWJ1dGVzIHRoZXkg
YmVsaWV2ZSBhcmUmbmJzcDtyZXF1aXJlZCB0aGVtIHRoZXkgY2FuIGFjY2VwdCB0aGUgYXNzZXJ0
aW9uLiBJZiBpdCBkb2Vzbid0IHRoZW4gdGhhdCBoYXZlIHRvIGltcGxlbWVudCBhZGRpdGlvbmFs
IG1lY2hhbmlzbXMgdG8gb2Zmc2V0IHRoZSByZXNpZHVhbCByaXNrLjxvOnA+PC9vOnA+PC9wPjwv
ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2Pjxk
aXY+PHAgY2xhc3M9TXNvTm9ybWFsPldpdGggcmVzcGVjdCB0byB2ZWN0b3JzIG9mIHRydXN0LCBJ
IGFtIGludGVyZXN0ZWQgaW4gZXhwbG9yaW5nIHdoYXQgdGhleSBhcmUgYW5kIGhvdyB0aGV5IGNh
biBiZSBhcHBsaWVkLjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPktlbjxi
cj48YnI+T24gVGh1cnNkYXksIE9jdG9iZXIgOSwgMjAxNCwgJmx0OzxhIGhyZWY9Im1haWx0bzpz
d2lsc29uQGxvY2tzdGVwLmNvbS5hdSI+c3dpbHNvbkBsb2Nrc3RlcC5jb20uYXU8L2E+Jmd0OyB3
cm90ZTo8bzpwPjwvbzpwPjwvcD48cCBzdHlsZT0nbWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4w
MDAxcHQ7d29yZC13cmFwOmJyZWFrLXdvcmQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+PHAgc3R5bGU9J21hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0O3dvcmQtd3Jh
cDpicmVhay13b3JkJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi
QXJpYWwiLCJzYW5zLXNlcmlmIic+Rmlyc3QsIHRvIGludHJvZHVjZSBteXNlbGYsIEkgYW0gYW4g
aWRlbnRpdHkgYW5kIHByaXZhY3kgcmVzZWFyY2hlciwgYW5hbHlzdCBhbmQgY29uc3VsdGFudC4m
bmJzcDsgSSd2ZSBiZWVuIGludm9sdmVkIGluIHRoaXMgc2luY2UgMTk5NSwgd2hlbiBJIGN1dCBt
eSB0ZWV0aCBpbiBQS0kgYW5kIHNtYXJ0Y2FyZHMgKHdpdGggdGhlIGVhcmx5IGNvbXBhbmllcyB0
aGF0IGJlY2FtZSBCYWx0aW1vcmUgVGVjaG5vbG9naWVzKS4gU2luY2UgdGhlbiBJJ3ZlIHdvcmtl
ZCBvbiBpZGVudGl0eSBtYW5hZ2VtZW50IGZyYW1ld29ya3MsIHJlZ3VsYXRpb25zIGFuZCBzdGFu
ZGFyZHMuICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBzdHlsZT0nbWFyZ2luOjBjbTtt
YXJnaW4tYm90dG9tOi4wMDAxcHQ7d29yZC13cmFwOmJyZWFrLXdvcmQnPjxzcGFuIHN0eWxlPSdm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz4mbmJzcDs8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgc3R5bGU9J21hcmdpbjowY207bWFyZ2luLWJvdHRvbTou
MDAwMXB0O3dvcmQtd3JhcDpicmVhay13b3JkJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+SSBzdWJzY3JpYmUgdG8gdGhlIG9s
ZCBJdGFsaWFuIHByb3ZlcmI6ICZxdW90O2l0J3MgbmljZSB0byB0cnVzdCBidXQgYmV0dGVyIG5v
dCB0byZxdW90Oy4mbmJzcDsgV29yZHMgbWF0dGVyIGFuZCBJIHdvbmRlciBpZiB3ZSBzaG91bGRu
J3QgYmUgdXNpbmcgdGhlIHdvcmQgdHJ1c3Qgc28gbXVjaC4gJm5ic3A7PG86cD48L286cD48L3Nw
YW4+PC9wPjxwIHN0eWxlPSdtYXJnaW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdDt3b3JkLXdy
YXA6YnJlYWstd29yZCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
IkFyaWFsIiwic2Fucy1zZXJpZiInPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBzdHls
ZT0nbWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQ7d29yZC13cmFwOmJyZWFrLXdvcmQn
PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMt
c2VyaWYiJz5Nb3JlIHByYWdtYXRpY2FsbHksIEkgbm90ZSB0aGUgdmVyeSBzdHJvbmcgJnF1b3Q7
QXR0cmlidXRlcyZxdW90OyBwdXNoIG9mIHRoZSBwYXN0IDE4IG1vbnRocy4mbmJzcDsgQW5kcmV3
IE5hc2gsIEFuaWwgSm9obiwgbXlzZWxmIGFuZCBvdGhlcnMgaGF2ZSB3cml0dGVuIGFib3V0IHRo
aXMuJm5ic3A7IFRoZSBGSURPIEFsbGlhbmNlIGlzIGFsbCBhYm91dCBhdXRoZW50aWNhdGlvbiBh
bmQgYXR0cmlidXRlcywgYW5kIHRoZXkgcHVycG9zZWZ1bGx5IGxlYXZlICZxdW90O2lkZW50aXR5
JnF1b3Q7IGFzIGEgbWF0dGVyIGZvciBvdGhlcnMgdG8gd29yayBvdXQgZnVydGhlciB1cCB0aGUg
c3RhY2suIFRoZSBPSUQgRm91bmRhdGlvbiBpcyBwcm9tb3RpbmcgYW4gQXR0cmlidXRlcyBFeGNo
YW5nZSBOZXR3b3JrICZxdW90O0FYTiZxdW90OyBhcmNoaXRlY3R1cmUuJm5ic3A7IE5ldyBlbnRy
YW50cyBsaWtlIDxhIGhyZWY9Imh0dHA6Ly9pZC5tZSIgdGFyZ2V0PSJfYmxhbmsiPmlkLm1lPC9h
PiAoYW4gTlNUSUMgcGlsb3QgcGFydGljaXBhbnQpIHRhbGsgYWJvdXQgYXR0cmlidXRlcyBhbmQg
YXZvaWQgJnF1b3Q7aWRlbnRpdHkmcXVvdDsuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjxw
IHN0eWxlPSdtYXJnaW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdDt3b3JkLXdyYXA6YnJlYWst
d29yZCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwi
c2Fucy1zZXJpZiInPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBzdHlsZT0nbWFyZ2lu
OjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQ7d29yZC13cmFwOmJyZWFrLXdvcmQnPjxzcGFuIHN0
eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5J
IG1lbnRpb24gYWxsIG9mIHRoaXMgYXMgYSBwcmVsdWRlIHRvIHN1Z2dlc3QgdGhhdCAmcXVvdDt2
ZWN0b3Igb2YgdHJ1c3QmcXVvdDsgaXMgc3lub255bW91cyB3aXRoICZxdW90O2F0dHJpYnV0ZSZx
dW90Oy4gSSB3b25kZXIgaWYgaXQgd291bGQgYmUgY2xlYXJlciB0byB1c2UgcGxhaW4gYW5kIGN1
cnJlbnQgbGFuZ3VhZ2UgcmF0aGVyIHRoYW4gY2FycnkgZm9yd2FyZCB0aGUgZnV6enkgYW5kIEkg
dGhpbmsgb3Zlcmx5IGFtYml0aW91cyBpZGVhIG9mICZxdW90O3RydXN0JnF1b3Q7PyZuYnNwOzxv
OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBzdHlsZT0nbWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4w
MDAxcHQ7d29yZC13cmFwOmJyZWFrLXdvcmQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+PHAgc3R5bGU9J21hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0O3dvcmQtd3Jh
cDpicmVhay13b3JkJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi
QXJpYWwiLCJzYW5zLXNlcmlmIic+RmluYWxseSwgSSdkIGxpa2UgdG8gdGhyb3cgaW4gbXkgYWJp
ZGluZyBjb25jZXJuIHRoYXQgTE9BcyBoYXZlIGZvdW5kZXJlZCBzaW1wbHkgYmVjYXVzZSBpdCdz
IGRpZmZpY3VsdCB0byBwaWdlb25ob2xlIHJpc2suIE9uZSBwYXJ0eSdzIGlkZWEgb2YgJnF1b3Q7
bWVkaXVtJnF1b3Q7IHJpc2sgZm9yIGluc3RhbmNlIHdpbGwgcmFyZWx5IG1hcCBwcmVjaXNlbHkg
dG8gYW5vdGhlcidzLiBJIHRoaW5rIHBlb3BsZSBoYXZlIGJlZW4gbWlzbGVkIGludG8gdGhpbmtp
bmcgdGhhdCBhbiAmcXVvdDtMT0EgMyZxdW90OyBpZGVudGl0eSBzaG91bGQgYmUgYmUgYWJsZSB0
byBiZSB1c2VkIG9uIGl0cyBmYWNlIChpLmUuIHdpbGwgJnF1b3Q7aW50ZXJvcGVyYXRlJnF1b3Q7
KSBhdCBhbnkgJnF1b3Q7TE9BIDMmcXVvdDsgUlAuIFJpc2sgbWFuYWdlbWVudCBpcyBub3Qgc28g
c2ltcGxlLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBzdHlsZT0nbWFyZ2luOjBjbTtt
YXJnaW4tYm90dG9tOi4wMDAxcHQ7d29yZC13cmFwOmJyZWFrLXdvcmQnPjxzcGFuIHN0eWxlPSdm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz4mbmJzcDs8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgc3R5bGU9J21hcmdpbjowY207bWFyZ2luLWJvdHRvbTou
MDAwMXB0O3dvcmQtd3JhcDpicmVhay13b3JkJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+VGhlIExPQSBwYXJhZGlnbSBib3Jy
b3dzIGZyb20gUmlzayBNYW5hZ2VtZW50IHN0YW5kYXJkcyBsaWtlIElTTyAzMTAwMCB3aGljaCZu
YnNwO29yZ2FuaXNhdGlvbnMgdXNlIHRvJm5ic3A7cGxvdCZuYnNwO3RoZWlyIG93biByaXNrcyBp
bnRlcm5hbGx5IHR5cGljYWxseSBvbiBhIGZpdmUgc2NhbGUgKGVnIE5lZ2xpZ2libGUgLyBMb3cg
LyBNZWRpdW0gLyBIaWdoIC8gR3JhdmUpLiZuYnNwO0J1dCZuYnNwO3Jpc2sgbWFuYWdlbWVudCZu
YnNwO3N0YW5kYXJkcyByZXF1aXJlIHRoYXQgZWFjaCBvcmdhbmlzYXRpb24gY2FsaWJyYXRlcyBy
aXNrIGluIGl0cyBvd24gYnVzaW5lc3MgY29udGV4dCBhbmQgYWNjb3JkaW5nIHRvIGl0cyZuYnNw
O293biByaXNrIGFwcGV0aXRlLiBUaGUgcmlzayBvZiBhIGZpcmV3YWxsIGJyZWFjaCBmb3IgZXhh
bXBsZSBhdCBhIHN0YXJ0dXAgc29jaWFsIG1lZGlhIGNvbXBhbnkgd2lsbCBiZSBhc3Nlc3NlZCBk
aWZmZXJlbnRseSBieSBhIGJpZyBsaXN0ZWQgaGVhbHRoY2FyZSBjb21wYW55LiZuYnNwO1NvIG9y
Z2FuaXNhdGlvbiBBJm5ic3A7Y2FuIHNheSB0aGUgcmlzayBvZiBldmVudCBYIGlzIExvdyBidXQg
QiBjYW4gc2F5IHRoZSByaXNrIG9mIHRoZSBzYW1lIGV2ZW50IGlzIE1lZGl1bS4mbmJzcDsgQXMm
bmJzcDthIHJlc3VsdCwgTE9BcyBkbyBub3QgaW50ZXItb3BlcmF0ZS4gVGhleSBhcmUgYmFzZWQg
b24gc3RhbmRhcmRzIG1lYW50IGZvciBpbnRyYS1vcmdhbmlzYXRpb24gcmlzayBtYW5hZ2VtZW50
LCBub3QgaW50ZXItb3JnYW5pc2F0aW9uIGNvbW11bmljYXRpb24gb2YmbmJzcDtyaXNrIGFzc2Vz
c21lbnRzLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBzdHlsZT0nbWFyZ2luOjBjbTtt
YXJnaW4tYm90dG9tOi4wMDAxcHQ7d29yZC13cmFwOmJyZWFrLXdvcmQnPjxzcGFuIHN0eWxlPSdm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz4mbmJzcDs8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgc3R5bGU9J21hcmdpbjowY207bWFyZ2luLWJvdHRvbTou
MDAwMXB0O3dvcmQtd3JhcDpicmVhay13b3JkJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+U28gZmFyIHdpdGggVm9UIHdlIGFy
ZSBhZGRpbmcgbW9yZSBkaW1lbnNpb25zIHRvIHRoZSBSUHMnIGdlbmVyaWMgcmlzayBtYW5hZ2Vt
ZW50IGRlY2lzaW9uIG1ha2luZywgYW5kIHRoYXQncyBncmVhdC4mbmJzcDsgQnV0IHdlIGFyZSBz
dGlsbCBwaWdlb25ob2xpbmcgdGhlIGRpbWVuc2lvbnMuPG86cD48L286cD48L3NwYW4+PC9wPjxw
IHN0eWxlPSdtYXJnaW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdDt3b3JkLXdyYXA6YnJlYWst
d29yZCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwi
c2Fucy1zZXJpZiInPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBzdHlsZT0nbWFyZ2lu
OjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQ7d29yZC13cmFwOmJyZWFrLXdvcmQnPjxzcGFuIHN0
eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5J
J20gYWZyYWlkIHRoZSByZWFsaXR5IGlzIHRoYXQgcmlzayBtYW5hZ2VtZW50IHdpbGwgYWx3YXlz
IGJlIGRvbmUgbG9jYWxseS4mbmJzcDsgQW5kIHNvIGl0IHNob3VsZCBiZS4mbmJzcDsgV2hlbiBh
biBSUCBpcyBtYWtpbmcmbmJzcDt0aGUgZGVjaXNpb24gdG8gYWNjZXB0IG9yIHJlamVjdCBhIGdp
dmVuIHN1YmplY3QsIHRoZXkgd2lsbCBldmFsdWF0ZSBhIHJhbmdlIG9mIGF0dHJpYnV0ZXMgb3Im
bmJzcDtzaWduYWxzLiZuYnNwOyBUaGUgc2V0IG9mIGF0dHJpYnV0ZXMgdGhhdCBtYXR0ZXJzIHZh
cmllcyBmcm9tIG9uZSBSUCB0byB0aGUgbmV4dC4mbmJzcDsgSSB0aGluayBpdCdzIGEgZ3JlYXQg
aWRlYSBpbmRlZWQgdG8gY3JlYXRlIGd1aWRhbmNlIGZvciBldmFsdWF0aW5nIGF0dHJpYnV0ZXMs
IGFuZCB0byBjb2FjaCBSUHMgdG8gbG9vayBhdCBhbGwgc29ydHMgb2YgZGltZW5zaW9ucy4mbmJz
cDsgSSBqdXN0IGRvbid0IHRoaW5rIGl0IGhlbHBzIGFueW9uZSB0byBwaWdlb25ob2xlIHRoZSBy
aXNrIHJhdGluZ3MsIGJlY2F1c2UgYWNyb3NzIG9yZ2FuaXNhdGlvbnMsIGFyZ3VtZW50cyBhYm91
dCB0aGUgYm91bmRhcmllcyBiZXR3ZWVuIExPQSAxLzIvMy80ICh0aGF0IGlzLCBwb2xpY3kgbWFw
cGluZykgd2lsbCZuYnNwO3VuZG8gYW55IGVmZmljaWVuY2llcyBnYWluZWQgZnJvbSB0aGUgY2F0
ZWdvcml6YXRpb24uICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBzdHlsZT0nbWFyZ2lu
OjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQ7d29yZC13cmFwOmJyZWFrLXdvcmQnPjxzcGFuIHN0
eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz4m
bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgc3R5bGU9J21hcmdpbjowY207bWFyZ2luLWJv
dHRvbTouMDAwMXB0O3dvcmQtd3JhcDpicmVhay13b3JkJz48c3BhbiBzdHlsZT0nZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+Q2hlZXJzLCZuYnNwOzxv
OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBzdHlsZT0nbWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4w
MDAxcHQ7d29yZC13cmFwOmJyZWFrLXdvcmQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+PHAgc3R5bGU9J21hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0O3dvcmQtd3Jh
cDpicmVhay13b3JkJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi
QXJpYWwiLCJzYW5zLXNlcmlmIic+U3RldmUuPG86cD48L286cD48L3NwYW4+PC9wPjxwIHN0eWxl
PSdtYXJnaW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdDt3b3JkLXdyYXA6YnJlYWstd29yZCc+
PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1z
ZXJpZiInPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBzdHlsZT0nbWFyZ2luOjBjbTtt
YXJnaW4tYm90dG9tOi4wMDAxcHQ7d29yZC13cmFwOmJyZWFrLXdvcmQnPjxzcGFuIHN0eWxlPSdm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz4mbmJzcDs8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgc3R5bGU9J21hcmdpbjowY207bWFyZ2luLWJvdHRvbTou
MDAwMXB0O3dvcmQtd3JhcDpicmVhay13b3JkJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+U3RlcGhlbiBXaWxzb248YnI+TWFu
YWdpbmcgRGlyZWN0b3I8YnI+TG9ja3N0ZXAgR3JvdXA8YnI+PGEgaHJlZj0iaHR0cDovL2xvY2tz
dGVwLmNvbS5hdSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9sb2Nrc3RlcC5jb20uYXU8L2E+PGJy
PkxvY2tzdGVwIENvbnN1bHRpbmcgcHJvdmlkZXMgaW5kZXBlbmRlbnQgc3BlY2lhbGlzdCBhZHZp
Y2UgYW5kIGFuYWx5c2lzIDxicj5vbiBkaWdpdGFsIGlkZW50aXR5IGFuZCBwcml2YWN5LiBMb2Nr
c3RlcCBUZWNobm9sb2dpZXMgZGV2ZWxvcHMgdW5pcXVlIDxicj5uZXcgc21hcnQgSUQgc29sdXRp
b25zIHRoYXQgZW5oYW5jZSBwcml2YWN5IGFuZCBwcmV2ZW50IGlkZW50aXR5IHRoZWZ0LjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD48cCBzdHlsZT0nbWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAx
cHQ7d29yZC13cmFwOmJyZWFrLXdvcmQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+PHAgc3R5bGU9J21hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0O3dvcmQtd3JhcDpi
cmVhay13b3JkJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJp
YWwiLCJzYW5zLXNlcmlmIic+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjxwIHN0eWxlPSdt
YXJnaW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdDt3b3JkLXdyYXA6YnJlYWstd29yZCc+PHNw
YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJp
ZiInPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1s
Pg==

--_000_B74E7D085FA151499EBC26F775ACC89D0A8ED5CCBBEXTBS3tbssctl_--


From nobody Fri Oct 10 10:28:42 2014
Return-Path: 
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 274401A9008 for ; Fri, 10 Oct 2014 10:28:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.085
X-Spam-Level: 
X-Spam-Status: No, score=-2.085 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RP_MATCHES_RCVD=-0.786] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x07SsYAx7yEf for ; Fri, 10 Oct 2014 10:28:34 -0700 (PDT)
Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id C8A3C1A902A for ; Fri, 10 Oct 2014 10:28:33 -0700 (PDT)
Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6887872E0EE; Fri, 10 Oct 2014 13:28:33 -0400 (EDT)
Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id 94F0772E0FC; Fri, 10 Oct 2014 13:28:32 -0400 (EDT)
Received: from IMCMBX01.MITRE.ORG ([169.254.1.195]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.03.0174.001; Fri, 10 Oct 2014 13:28:31 -0400
From: "Richer, Justin P." 
To: "Bouma, Tim" 
Thread-Topic: [VoT] Foundational questions of principle
Thread-Index: AQHP4/5G3UR8veHy+0SPOFzGM7/3D5wo0ccAgADcpgCAACvnAA==
Date: Fri, 10 Oct 2014 17:28:30 +0000
Message-ID: <6A0CFC85-F8F5-43F5-B02F-09720E7164F4@mitre.org>
References: <1412885935.58929166@apps.rackspace.com>  <20141010145142.51DBE1A90E3@ietfa.amsl.com>
In-Reply-To: <20141010145142.51DBE1A90E3@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.146.15.56]
Content-Type: multipart/alternative; boundary="_000_6A0CFC85F8F543F5B02F09720E7164F4mitreorg_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/vot/1BWp0AcmsaFeQwUsNBh372WuTsA
Cc: Ken Dagg , "vot@ietf.org" , "swilson@lockstep.com.au" 
Subject: Re: [VoT] Foundational questions of principle
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Vectors of Trust discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Oct 2014 17:28:38 -0000

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

V2hhdCB3ZSdyZSB0cnlpbmcgdG8gZG8gd2l0aCB0aGUgIlZlY3RvcnMiIGFwcHJvYWNoIGhlcmUg
aXMgdG8gc3RyaWtlIGEgYmFsYW5jZSBiZXR3ZWVuIHRoZSBvdmVybHktc2ltcGxpc3RpYyAic2lu
Z2xlIHNldCBvZiBsaW5lYXIgbGV2ZWxzIiBhcHByb2FjaCB0aGF0IExvQSBnaXZlcyB1cyAodGhh
dCBub2JvZHkgb24gdGhpcyBsaXN0IGxpa2VzIGJ1dCBhbGwgYWdyZWUgdGhhdCBhcHBzIGNhbiBh
Y3R1YWxseSBkbyBzb21lIGxldmVsIG9mIHByb2Nlc3Npbmcgd2l0aCBpdCkgYW5kIHRoZSBvdmVy
bHktY29tcGxleCAidmVyeSBsb25nIGNvbXBsZXggc2V0IG9mIGF0dHJpYnV0ZXMiIGFwcHJvYWNo
IHRoYXQgVGltLCBTY290dCwgYW5kIG90aGVycyBoYXZlIGJyb3VnaHQgdXAgKHRoYXQgc2VlbXMg
bW9yZSBleHByZXNzaXZlIGFuZCBpZGVhbCBidXQgbm8gYXBwIGlzIGV2ZXIgZ29pbmcgdG8gbWFr
ZSBzZW5zZSBvZiwgb3IgZXZlbiB0cnkgdG8pLiBJIHRoaW5rIGl0J3Mgc2FmZSB0byBzYXkgdGhh
dCBuZWl0aGVyIGV4dHJlbWUgd29ya3MgYW5kIHRoYXQgYSByaWdodCBhbnN3ZXIgcHJvYmFibHkg
bGllcyBpbiB0aGUgbWlkZGxlLg0KDQpTbyB0aGF0J3Mgd2hhdCB0aGlzIHN0cmF3bWFuIGlzIC0t
IGl0J3Mgc2ltdWx0YW5lb3VzbHkgbGVzcyBjb21wbGV4IGFuZCBtb3JlIGNvbXBsZXggdGhhbiB0
aGUgYWx0ZXJuYXRpdmVzLiBJcyBpdCB0aGUgcmlnaHQgY3V0PyBQcm9iYWJseSBub3QsIGJ1dCBp
dCdzIGF0IGxlYXN0IGEgY3V0dGluZyBwb2ludCB0aGF0IHdlIGNhbiBwdXNoIHRvIGVpdGhlciBz
aWRlLiBXaGF0IEkgdGhpbmsgd2UgbmVlZCB0byBkdXRpZnVsbHkgYXZvaWQgaXMgcHVzaGluZyBp
dCBoYXJkIHRvIGVpdGhlciBlbmQuIEkgcmVhbGx5IGxpa2UgdGhlIG5vdGlvbiB0aGF0IGV2ZW4g
aWYgdGhlIGNvbWJpbmF0aW9ucyBvZiB0aGUgdmVjdG9yIHZhbHVlcyBhcmVuJ3QgZGlyZWN0bHkg
Y29tcGF0aWJsZSAoYXMgU3RldmUgc2F5cyksIHRoZW4gdGhlIGJ1aWxkaW5nIGJsb2NrcyB3b3Vs
ZCBhdCBsZWFzdCBiZSBjb21wYXJhYmxlLCBnaXZpbmcgYSBob3BlIG9mIGRlZmluaW5nIGEgcG9s
aWN5IHRvIHRyYW5zbGF0ZSBiZXR3ZWVuIHRoZW0gd2hlbiBuZWVkZWQuDQoNCkFsc28sIEkgd2Fu
dGVkIHRvIGtleSBpbnRvIHRoZSBmYWN0IHRoYXQgdGhlcmUgYXJlIHNldmVyYWwgaW5kZXBlbmRl
bnQgYW5kIG9ydGhvZ29uYWwgY29tcG9uZW50cyBoZXJlLiBNYXliZSBpdCdzIG5vdCBhIHNldCBv
ZiBsZXZlbHMgdGhhdCBhcmUgdGllZCB0b2dldGhlciwgYnV0IEkgdGhpbmsgaXQgaXMgaW4gc29t
ZXdheSBhIHNldCBvZiBpbmRlcGVuZGVudCAqdGhpbmdzKiB0aGF0IGFyZSB0aWVkIHRvZ2V0aGVy
Lg0KDQogLS0gSnVzdGluDQoNCk9uIE9jdCAxMCwgMjAxNCwgYXQgMTA6NTEgQU0sIEJvdW1hLCBU
aW0gPFRpbS5Cb3VtYUB0YnMtc2N0LmdjLmNhPG1haWx0bzpUaW0uQm91bWFAdGJzLXNjdC5nYy5j
YT4+IHdyb3RlOg0KDQpJIGFncmVlIHdpdGggS2VuLA0KDQpXaGVuIHdlIGRldmVsb3BlZCBsZXZl
bHMgb2YgYXNzdXJhbmNlIChoZXJlIGluIENhbmFkYSkgd2UgZGlkIHNldmVyYWwgdGhpbmdzOg0K
DQoNCsK3ICAgICAgICAgV2UgZGVmaW5lZCB0aGVtIGFzIGxldmVscyBvZiBjb25maWRlbmNlIHJl
cXVpcmVkIChMZXZlbHMgMSB0aHJvdWdoIDQpDQoNCsK3ICAgICAgICAgV2UgbWFwcGVkIHRoZXNl
IGxldmVscyBvZiBjb25maWRlbmNlIHRvIGEgcmFuZ2Ugb2YgZGVncmVlIG9mIGltcGFjdHMuDQoN
CsK3ICAgICAgICAgV2UgdGhlbiBzcGVjaWZpZWQgc2VwYXJhdGVseSBpZGVudGl0eSBhc3N1cmFu
Y2UgbGV2ZWxzIGFuZCBjcmVkZW50aWFsIGFzc3VyYW5jZSBsZXZlbHMgKGFuZCBmb2N1c2VkIG9u
IGNyZWRlbnRpYWwgZmlyc3QpDQoNCsK3ICAgICAgICAgV2UgYWxzbyBmYWN0b3JlZCBvdXQgbGlr
ZWxpaG9vZCBpbiB0aGUgYXNzdXJhbmNlIGxldmVsIGFzc2Vzc21lbnQgcHJvY2Vzcy4gVGhhdCBt
YWRlIHRoZSBhc3Nlc3NtZW50cyBtdWNoIGxlc3Mgc3ViamVjdGl2ZS4NCg0KQXQgdGhlIGVuZCBv
ZiB0aGUgZGF5LCBhcyBLZW4gc3RhdGVzLCAgaXTigJlzIHRoZSBqb2IgdGhlIFJQIHRvIHVuZGVy
c3RhbmQgdGhlaXIgcmlzayAoYWxvbmcgd2l0aCBsaWtlbGlob29kKSBhbmQgdG8gY29tbXVuaWNh
dGUgYSBzdGFuZGFyZGl6ZWQgcmVxdWlyZW1lbnQgYmFjayB0byBhIHByb3ZpZGVyIChBUCkNClRo
ZSBBUCBpcyAgYWNjb3VudGFibGUgZm9yIHByb3ZpZGluZyBhIHZlcnkgcHJlc2NyaWJlZCBjb21w
b25lbnQgdGhhdCBmaXRzIGludG8gYSBsYXJnZXIgc3lzdGVtIGFuZCBhIHJpc2sgZW52aXJvbm1l
bnQgdGhhdCB0aGV5IG1pZ2h0IG5vdCBoYXZlIGEgZnVsbCB2aWV3IGludG8uIFRoZSBSUCBtYXkg
cHV0IGluIHByb3Zpc2lvbnMgdG8gc2hhcmUgdGhlIHJpc2sgd2l0aCB0aGUgQVAsIG9yIG5vdCBi
dXQgdGhhdCBlbnRpcmVseSBkZXBlbmRzIG9uIHRoZSBhcnJhbmdlbWVudCwgYnV0IGF0IGxlYXN0
IHRoZSBSUCBhbmQgQVAgdW5kZXJzdGFuZCB3aGF04oCZcyBvbiB0aGUgdGFibGUgYXMgYSBzdGFy
dGluZyBwb2ludC4NCg0KSW4gQ2FuYWRhLCB3ZSBkaWQgdGhhdCB3aXRoIHRoZSBjcmVkZW50aWFs
IGZpcnN0LCBhbmQgYXJlIG5vdyBmaWd1cmluZyBvdXQgaWRlbnRpdHkgKG11Y2ggaGFyZGVyKS4N
Cg0KSSBhbHNvIGFncmVlIHRoYXQg4oCYaWRlbnRpdHnigJkgaXMganVzdCBhIHNldCBvZiBhdHRy
aWJ1dGVzIOKAk2FuZCAgdGhlc2UgaWRlbnRpdHkgYXR0cmlidXRlcyBjYW4gdmFyeSBiZXR3ZWVu
IG9yZ2FuaXphdGlvbnMgb3IganVyaXNkaWN0aW9ucywNCg0KQXMgZm9yIHRoZSB0ZXJtIOKAmHZl
Y3RvcnPigJksIEkgZ2V0IHRoZSBpZGVhLCBidXQgSSB0aGluayB0aGUgY29tbXVuaXR5IHdpbGwg
dGhpbmsgaXTigJlzIHRvbyB0ZWNobmljYWwgb3IgZXNvdGVyaWMuIEkgbGlrZSB0byB0aGluayBv
ZiBhIOKAmGRpZ2l0YWwgaWRlbnRpdHnigJkgKG9yIHdoYXRldmVyIHlvdSBjYWxsIGl0KSwgd2hl
biBpdCBzaG93cyB1cCBhdCB5b3VyIGRpZ2l0YWwgZnJvbnQgZG9vciwgaXQgaXMgdGhlIHByb2R1
Y3Qgb2YgYSB2ZXJ5IGxvbmcsIGNvbXBsZXggc3VwcGx5IGNoYWluLCBmcmF1Z2h0IHdpdGggbWFu
eSByaXNrcyBhbmQgY29tcHJvbWlzZXMuIEkgbWF5IGhhdmUgY29uZmlkZW5jZSBpbiBjZXJ0YWlu
IHBpZWNlcyBvZiwgYnV0IG90aGVyIEkgbWlnaHQgbm90IHRydXN0IGF0IGFsbC4NCg0KDQpUaW0N
Cg0KDQpGcm9tOiB2b3QgW21haWx0bzp2b3QtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m
IEtlbiBEYWdnDQpTZW50OiBPY3RvYmVyLTA5LTE0IDk6NDIgUE0NClRvOiBzd2lsc29uQGxvY2tz
dGVwLmNvbS5hdTxtYWlsdG86c3dpbHNvbkBsb2Nrc3RlcC5jb20uYXU+DQpDYzogdm90QGlldGYu
b3JnPG1haWx0bzp2b3RAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW1ZvVF0gRm91bmRhdGlvbmFs
IHF1ZXN0aW9ucyBvZiBwcmluY2lwbGUNCg0KU3RldmUsDQoNCkFzIHdlIGhhdmUgY29tbXVuaWNh
dGVkIGluIHRoZSBwYXN0LCBJIGFtIGEgc3Ryb25nIGJlbGlldmVyIHRoZSBhbiBMT0EgZGVzaWdu
YXRpb24gaXMgYW4gaW5kaWNhdGlvbiBvZiB0aGUgcHJvY2Vzc2VzL21lY2hhbmlzbXMgdGhhdCBh
biBJZFAgaGFzIHVuZGVydGFrZW4uIEluIG90aGVyIHdvcmRzLCBpdCBpcyBhIGNvbW11bmljYXRp
b24gdG9vbC4gVGhlIGNob2ljZSBpcyB0aGUgUlBzLiBUaGF0IGlzLCBhbiBhc3NlcnRpb24gYXQg
YSBzcGVjaWZpYyBMT0EgYnkgYW4gSWRQL0NTUC9BUCBpcyBvbmUgb2YgdGhlIG1lY2hhbmlzbXMg
YSBSUCBzaG91bGQgdXNlIHRvIG9mZnNldCB0aGUgYXV0aGVudGljYXRpb24gcmlzayBpdCBoYXMg
aWRlbnRpZmllZCBmb3IgdGhlIHNlcnZpY2UgaXQgd2FudHMgdG8gZGVsaXZlci4gSW4gb3RoZXIg
d29yZHMsIGl0IGlzIHRoZSByaXNrIG9mIHRoZSBSUCB0aGF0IGlzIHBhcmFtb3VudCBub3QgdGhl
IGNsYWltcyBvZiBhbiBpZGVudGl0eS9jcmVkZW50aWFsL2F0dHJpYnV0ZS90b2tlbiBwcm92aWRl
ci4NCg0KTGlrZSB5b3UsIEkgYW0gYSBzdHJvbmcgYmVsaWV2ZXIgdGhhdCB0aGUgZGV0ZXJtaW5h
dGlvbiBvZiB3aGV0aGVyIG9yIG5vdCBhbiBpZGVudGl0eSBpcyBnb29kIGVub3VnaCBpcyB0aGUg
cmVzcG9uc2liaWxpdHkgb2YgdGhlIFJQLiBJbiBteSBleHBlcmllbmNlLCB0aGV5IG1ha2UgdGhh
dCBkZXRlcm1pbmF0aW9uIGJhc2VkIHVwb24gYSBzZXQgb2YgYXR0cmlidXRlcyB0aGV5IGJlbGll
dmUgYXJlIG5lY2Vzc2FyeS4gSWYgdGhleSB0cnVzdCB0aGF0IGFuIElkUCdzIGFzc2VydGlvbiBv
ZiBpZGVudGl0eSBjb3ZlcnMgdGhlIGF0dHJpYnV0ZXMgdGhleSBiZWxpZXZlIGFyZSByZXF1aXJl
ZCB0aGVtIHRoZXkgY2FuIGFjY2VwdCB0aGUgYXNzZXJ0aW9uLiBJZiBpdCBkb2Vzbid0IHRoZW4g
dGhhdCBoYXZlIHRvIGltcGxlbWVudCBhZGRpdGlvbmFsIG1lY2hhbmlzbXMgdG8gb2Zmc2V0IHRo
ZSByZXNpZHVhbCByaXNrLg0KDQpXaXRoIHJlc3BlY3QgdG8gdmVjdG9ycyBvZiB0cnVzdCwgSSBh
bSBpbnRlcmVzdGVkIGluIGV4cGxvcmluZyB3aGF0IHRoZXkgYXJlIGFuZCBob3cgdGhleSBjYW4g
YmUgYXBwbGllZC4NCg0KS2VuDQoNCk9uIFRodXJzZGF5LCBPY3RvYmVyIDksIDIwMTQsIDxzd2ls
c29uQGxvY2tzdGVwLmNvbS5hdTxtYWlsdG86c3dpbHNvbkBsb2Nrc3RlcC5jb20uYXU+PiB3cm90
ZToNCg0KRmlyc3QsIHRvIGludHJvZHVjZSBteXNlbGYsIEkgYW0gYW4gaWRlbnRpdHkgYW5kIHBy
aXZhY3kgcmVzZWFyY2hlciwgYW5hbHlzdCBhbmQgY29uc3VsdGFudC4gIEkndmUgYmVlbiBpbnZv
bHZlZCBpbiB0aGlzIHNpbmNlIDE5OTUsIHdoZW4gSSBjdXQgbXkgdGVldGggaW4gUEtJIGFuZCBz
bWFydGNhcmRzICh3aXRoIHRoZSBlYXJseSBjb21wYW5pZXMgdGhhdCBiZWNhbWUgQmFsdGltb3Jl
IFRlY2hub2xvZ2llcykuIFNpbmNlIHRoZW4gSSd2ZSB3b3JrZWQgb24gaWRlbnRpdHkgbWFuYWdl
bWVudCBmcmFtZXdvcmtzLCByZWd1bGF0aW9ucyBhbmQgc3RhbmRhcmRzLg0KDQpJIHN1YnNjcmli
ZSB0byB0aGUgb2xkIEl0YWxpYW4gcHJvdmVyYjogIml0J3MgbmljZSB0byB0cnVzdCBidXQgYmV0
dGVyIG5vdCB0byIuICBXb3JkcyBtYXR0ZXIgYW5kIEkgd29uZGVyIGlmIHdlIHNob3VsZG4ndCBi
ZSB1c2luZyB0aGUgd29yZCB0cnVzdCBzbyBtdWNoLg0KDQpNb3JlIHByYWdtYXRpY2FsbHksIEkg
bm90ZSB0aGUgdmVyeSBzdHJvbmcgIkF0dHJpYnV0ZXMiIHB1c2ggb2YgdGhlIHBhc3QgMTggbW9u
dGhzLiAgQW5kcmV3IE5hc2gsIEFuaWwgSm9obiwgbXlzZWxmIGFuZCBvdGhlcnMgaGF2ZSB3cml0
dGVuIGFib3V0IHRoaXMuICBUaGUgRklETyBBbGxpYW5jZSBpcyBhbGwgYWJvdXQgYXV0aGVudGlj
YXRpb24gYW5kIGF0dHJpYnV0ZXMsIGFuZCB0aGV5IHB1cnBvc2VmdWxseSBsZWF2ZSAiaWRlbnRp
dHkiIGFzIGEgbWF0dGVyIGZvciBvdGhlcnMgdG8gd29yayBvdXQgZnVydGhlciB1cCB0aGUgc3Rh
Y2suIFRoZSBPSUQgRm91bmRhdGlvbiBpcyBwcm9tb3RpbmcgYW4gQXR0cmlidXRlcyBFeGNoYW5n
ZSBOZXR3b3JrICJBWE4iIGFyY2hpdGVjdHVyZS4gIE5ldyBlbnRyYW50cyBsaWtlIGlkLm1lPGh0
dHA6Ly9pZC5tZS8+IChhbiBOU1RJQyBwaWxvdCBwYXJ0aWNpcGFudCkgdGFsayBhYm91dCBhdHRy
aWJ1dGVzIGFuZCBhdm9pZCAiaWRlbnRpdHkiLg0KDQpJIG1lbnRpb24gYWxsIG9mIHRoaXMgYXMg
YSBwcmVsdWRlIHRvIHN1Z2dlc3QgdGhhdCAidmVjdG9yIG9mIHRydXN0IiBpcyBzeW5vbnltb3Vz
IHdpdGggImF0dHJpYnV0ZSIuIEkgd29uZGVyIGlmIGl0IHdvdWxkIGJlIGNsZWFyZXIgdG8gdXNl
IHBsYWluIGFuZCBjdXJyZW50IGxhbmd1YWdlIHJhdGhlciB0aGFuIGNhcnJ5IGZvcndhcmQgdGhl
IGZ1enp5IGFuZCBJIHRoaW5rIG92ZXJseSBhbWJpdGlvdXMgaWRlYSBvZiAidHJ1c3QiPw0KDQpG
aW5hbGx5LCBJJ2QgbGlrZSB0byB0aHJvdyBpbiBteSBhYmlkaW5nIGNvbmNlcm4gdGhhdCBMT0Fz
IGhhdmUgZm91bmRlcmVkIHNpbXBseSBiZWNhdXNlIGl0J3MgZGlmZmljdWx0IHRvIHBpZ2Vvbmhv
bGUgcmlzay4gT25lIHBhcnR5J3MgaWRlYSBvZiAibWVkaXVtIiByaXNrIGZvciBpbnN0YW5jZSB3
aWxsIHJhcmVseSBtYXAgcHJlY2lzZWx5IHRvIGFub3RoZXIncy4gSSB0aGluayBwZW9wbGUgaGF2
ZSBiZWVuIG1pc2xlZCBpbnRvIHRoaW5raW5nIHRoYXQgYW4gIkxPQSAzIiBpZGVudGl0eSBzaG91
bGQgYmUgYmUgYWJsZSB0byBiZSB1c2VkIG9uIGl0cyBmYWNlIChpLmUuIHdpbGwgImludGVyb3Bl
cmF0ZSIpIGF0IGFueSAiTE9BIDMiIFJQLiBSaXNrIG1hbmFnZW1lbnQgaXMgbm90IHNvIHNpbXBs
ZS4NCg0KVGhlIExPQSBwYXJhZGlnbSBib3Jyb3dzIGZyb20gUmlzayBNYW5hZ2VtZW50IHN0YW5k
YXJkcyBsaWtlIElTTyAzMTAwMCB3aGljaCBvcmdhbmlzYXRpb25zIHVzZSB0byBwbG90IHRoZWly
IG93biByaXNrcyBpbnRlcm5hbGx5IHR5cGljYWxseSBvbiBhIGZpdmUgc2NhbGUgKGVnIE5lZ2xp
Z2libGUgLyBMb3cgLyBNZWRpdW0gLyBIaWdoIC8gR3JhdmUpLiBCdXQgcmlzayBtYW5hZ2VtZW50
IHN0YW5kYXJkcyByZXF1aXJlIHRoYXQgZWFjaCBvcmdhbmlzYXRpb24gY2FsaWJyYXRlcyByaXNr
IGluIGl0cyBvd24gYnVzaW5lc3MgY29udGV4dCBhbmQgYWNjb3JkaW5nIHRvIGl0cyBvd24gcmlz
ayBhcHBldGl0ZS4gVGhlIHJpc2sgb2YgYSBmaXJld2FsbCBicmVhY2ggZm9yIGV4YW1wbGUgYXQg
YSBzdGFydHVwIHNvY2lhbCBtZWRpYSBjb21wYW55IHdpbGwgYmUgYXNzZXNzZWQgZGlmZmVyZW50
bHkgYnkgYSBiaWcgbGlzdGVkIGhlYWx0aGNhcmUgY29tcGFueS4gU28gb3JnYW5pc2F0aW9uIEEg
Y2FuIHNheSB0aGUgcmlzayBvZiBldmVudCBYIGlzIExvdyBidXQgQiBjYW4gc2F5IHRoZSByaXNr
IG9mIHRoZSBzYW1lIGV2ZW50IGlzIE1lZGl1bS4gIEFzIGEgcmVzdWx0LCBMT0FzIGRvIG5vdCBp
bnRlci1vcGVyYXRlLiBUaGV5IGFyZSBiYXNlZCBvbiBzdGFuZGFyZHMgbWVhbnQgZm9yIGludHJh
LW9yZ2FuaXNhdGlvbiByaXNrIG1hbmFnZW1lbnQsIG5vdCBpbnRlci1vcmdhbmlzYXRpb24gY29t
bXVuaWNhdGlvbiBvZiByaXNrIGFzc2Vzc21lbnRzLg0KDQpTbyBmYXIgd2l0aCBWb1Qgd2UgYXJl
IGFkZGluZyBtb3JlIGRpbWVuc2lvbnMgdG8gdGhlIFJQcycgZ2VuZXJpYyByaXNrIG1hbmFnZW1l
bnQgZGVjaXNpb24gbWFraW5nLCBhbmQgdGhhdCdzIGdyZWF0LiAgQnV0IHdlIGFyZSBzdGlsbCBw
aWdlb25ob2xpbmcgdGhlIGRpbWVuc2lvbnMuDQoNCkknbSBhZnJhaWQgdGhlIHJlYWxpdHkgaXMg
dGhhdCByaXNrIG1hbmFnZW1lbnQgd2lsbCBhbHdheXMgYmUgZG9uZSBsb2NhbGx5LiAgQW5kIHNv
IGl0IHNob3VsZCBiZS4gIFdoZW4gYW4gUlAgaXMgbWFraW5nIHRoZSBkZWNpc2lvbiB0byBhY2Nl
cHQgb3IgcmVqZWN0IGEgZ2l2ZW4gc3ViamVjdCwgdGhleSB3aWxsIGV2YWx1YXRlIGEgcmFuZ2Ug
b2YgYXR0cmlidXRlcyBvciBzaWduYWxzLiAgVGhlIHNldCBvZiBhdHRyaWJ1dGVzIHRoYXQgbWF0
dGVycyB2YXJpZXMgZnJvbSBvbmUgUlAgdG8gdGhlIG5leHQuICBJIHRoaW5rIGl0J3MgYSBncmVh
dCBpZGVhIGluZGVlZCB0byBjcmVhdGUgZ3VpZGFuY2UgZm9yIGV2YWx1YXRpbmcgYXR0cmlidXRl
cywgYW5kIHRvIGNvYWNoIFJQcyB0byBsb29rIGF0IGFsbCBzb3J0cyBvZiBkaW1lbnNpb25zLiAg
SSBqdXN0IGRvbid0IHRoaW5rIGl0IGhlbHBzIGFueW9uZSB0byBwaWdlb25ob2xlIHRoZSByaXNr
IHJhdGluZ3MsIGJlY2F1c2UgYWNyb3NzIG9yZ2FuaXNhdGlvbnMsIGFyZ3VtZW50cyBhYm91dCB0
aGUgYm91bmRhcmllcyBiZXR3ZWVuIExPQSAxLzIvMy80ICh0aGF0IGlzLCBwb2xpY3kgbWFwcGlu
Zykgd2lsbCB1bmRvIGFueSBlZmZpY2llbmNpZXMgZ2FpbmVkIGZyb20gdGhlIGNhdGVnb3JpemF0
aW9uLg0KDQpDaGVlcnMsDQoNClN0ZXZlLg0KDQoNClN0ZXBoZW4gV2lsc29uDQpNYW5hZ2luZyBE
aXJlY3Rvcg0KTG9ja3N0ZXAgR3JvdXANCmh0dHA6Ly9sb2Nrc3RlcC5jb20uYXU8aHR0cDovL2xv
Y2tzdGVwLmNvbS5hdS8+DQpMb2Nrc3RlcCBDb25zdWx0aW5nIHByb3ZpZGVzIGluZGVwZW5kZW50
IHNwZWNpYWxpc3QgYWR2aWNlIGFuZCBhbmFseXNpcw0Kb24gZGlnaXRhbCBpZGVudGl0eSBhbmQg
cHJpdmFjeS4gTG9ja3N0ZXAgVGVjaG5vbG9naWVzIGRldmVsb3BzIHVuaXF1ZQ0KbmV3IHNtYXJ0
IElEIHNvbHV0aW9ucyB0aGF0IGVuaGFuY2UgcHJpdmFjeSBhbmQgcHJldmVudCBpZGVudGl0eSB0
aGVmdC4NCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fDQp2b3QgbWFpbGluZyBsaXN0DQp2b3RAaWV0Zi5vcmc8bWFpbHRvOnZvdEBpZXRmLm9yZz4N
Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdm90DQoNCg==

--_000_6A0CFC85F8F543F5B02F09720E7164F4mitreorg_
Content-Type: text/html; charset="utf-8"
Content-ID: <9ABDBD6206030147A62DDEBE099BEDC6@imc.mitre.org>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiPg0KV2hhdCB3ZSdyZSB0cnlpbmcgdG8gZG8gd2l0aCB0
aGUgJnF1b3Q7VmVjdG9ycyZxdW90OyBhcHByb2FjaCBoZXJlIGlzIHRvIHN0cmlrZSBhIGJhbGFu
Y2UgYmV0d2VlbiB0aGUgb3Zlcmx5LXNpbXBsaXN0aWMgJnF1b3Q7c2luZ2xlIHNldCBvZiBsaW5l
YXIgbGV2ZWxzJnF1b3Q7IGFwcHJvYWNoIHRoYXQgTG9BIGdpdmVzIHVzICh0aGF0IG5vYm9keSBv
biB0aGlzIGxpc3QgbGlrZXMgYnV0IGFsbCBhZ3JlZSB0aGF0IGFwcHMgY2FuIGFjdHVhbGx5IGRv
IHNvbWUgbGV2ZWwgb2YgcHJvY2Vzc2luZw0KIHdpdGggaXQpIGFuZCB0aGUgb3Zlcmx5LWNvbXBs
ZXggJnF1b3Q7dmVyeSBsb25nIGNvbXBsZXggc2V0IG9mIGF0dHJpYnV0ZXMmcXVvdDsgYXBwcm9h
Y2ggdGhhdCBUaW0sIFNjb3R0LCBhbmQgb3RoZXJzIGhhdmUgYnJvdWdodCB1cCAodGhhdCBzZWVt
cyBtb3JlIGV4cHJlc3NpdmUgYW5kIGlkZWFsIGJ1dCBubyBhcHAgaXMgZXZlciBnb2luZyB0byBt
YWtlIHNlbnNlIG9mLCBvciBldmVuIHRyeSB0bykuIEkgdGhpbmsgaXQncyBzYWZlIHRvIHNheSB0
aGF0IG5laXRoZXINCiBleHRyZW1lIHdvcmtzIGFuZCB0aGF0IGEgcmlnaHQgYW5zd2VyIHByb2Jh
Ymx5IGxpZXMgaW4gdGhlIG1pZGRsZS4mbmJzcDsNCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlNv
IHRoYXQncyB3aGF0IHRoaXMgc3RyYXdtYW4gaXMgLS0gaXQncyBzaW11bHRhbmVvdXNseSBsZXNz
IGNvbXBsZXggYW5kIG1vcmUgY29tcGxleCB0aGFuIHRoZSBhbHRlcm5hdGl2ZXMuIElzIGl0IHRo
ZSByaWdodCBjdXQ/IFByb2JhYmx5IG5vdCwgYnV0IGl0J3MgYXQgbGVhc3QgYSBjdXR0aW5nIHBv
aW50IHRoYXQgd2UgY2FuIHB1c2ggdG8gZWl0aGVyIHNpZGUuIFdoYXQgSSB0aGluayB3ZSBuZWVk
IHRvIGR1dGlmdWxseSBhdm9pZCBpcw0KIHB1c2hpbmcgaXQgaGFyZCB0byBlaXRoZXIgZW5kLiBJ
IHJlYWxseSBsaWtlIHRoZSBub3Rpb24gdGhhdCBldmVuIGlmIHRoZSBjb21iaW5hdGlvbnMgb2Yg
dGhlIHZlY3RvciB2YWx1ZXMgYXJlbid0IGRpcmVjdGx5IGNvbXBhdGlibGUgKGFzIFN0ZXZlIHNh
eXMpLCB0aGVuIHRoZSBidWlsZGluZyBibG9ja3Mgd291bGQgYXQgbGVhc3QgYmUgY29tcGFyYWJs
ZSwgZ2l2aW5nIGEgaG9wZSBvZiBkZWZpbmluZyBhIHBvbGljeSB0byB0cmFuc2xhdGUgYmV0d2Vl
bg0KIHRoZW0gd2hlbiBuZWVkZWQuJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRp
dj5BbHNvLCBJIHdhbnRlZCB0byBrZXkgaW50byB0aGUgZmFjdCB0aGF0IHRoZXJlIGFyZSBzZXZl
cmFsIGluZGVwZW5kZW50IGFuZCBvcnRob2dvbmFsIGNvbXBvbmVudHMgaGVyZS4gTWF5YmUgaXQn
cyBub3QgYSBzZXQgb2YgbGV2ZWxzIHRoYXQgYXJlIHRpZWQgdG9nZXRoZXIsIGJ1dCBJIHRoaW5r
IGl0IGlzIGluIHNvbWV3YXkgYSBzZXQgb2YgaW5kZXBlbmRlbnQgKnRoaW5ncyogdGhhdCBhcmUg
dGllZCB0b2dldGhlci48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PiZuYnNwOy0tIEp1
c3RpbjwvZGl2Pg0KPGRpdj48YnI+DQo8ZGl2Pg0KPGRpdj5PbiBPY3QgMTAsIDIwMTQsIGF0IDEw
OjUxIEFNLCBCb3VtYSwgVGltICZsdDs8YSBocmVmPSJtYWlsdG86VGltLkJvdW1hQHRicy1zY3Qu
Z2MuY2EiPlRpbS5Cb3VtYUB0YnMtc2N0LmdjLmNhPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIg
Y2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0
ZSI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChm
aWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpA
Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAg
MCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9z
ZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxp
YnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9u
dC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0
eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y
bWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox
Mi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmss
IHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVl
Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVy
bGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJ
dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN
Cgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0
Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KcC5Nc29MaXN0UGFy
YWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28t
c3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsN
CgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJvdHRv
bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS
b21hbiIsInNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJz
b25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9y
OiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7
DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1sYW5n
dWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7
DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24x
DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGww
DQoJe21zby1saXN0LWlkOjEwNDE2MzEzNTc7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNv
LWxpc3QtdGVtcGxhdGUtaWRzOi04NjU3MjQ4MjAgMjY5MDI1MjgxIDI2OTAyNTI4MyAyNjkwMjUy
ODUgMjY5MDI1MjgxIDI2OTAyNTI4MyAyNjkwMjUyODUgMjY5MDI1MjgxIDI2OTAyNTI4MyAyNjkw
MjUyODU7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl
dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv
LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9u
dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv
cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u
ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw
dDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28t
bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s
ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0
ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDps
ZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0
Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0
aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K
QGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t
bGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i
ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJD
b3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0
OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7
DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7
DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwt
bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10
YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu
ZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7
bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNv
LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K
CXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlz
dCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl
bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy
LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5n
ZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTow
Y207fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs
dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t
W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk
bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu
ZGlmXS0tPg0KPGRpdiBsYW5nPSJFTi1DQSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8
ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgYWdyZWUgd2l0aCBLZW4sPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V2hlbiB3
ZSBkZXZlbG9wZWQgbGV2ZWxzIG9mIGFzc3VyYW5jZSAoaGVyZSBpbiBDYW5hZGEpIHdlIGRpZCBz
ZXZlcmFsIHRoaW5nczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4
LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCEtLVtpZiAhc3VwcG9ydExpc3RzXS0tPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xvcjojMUY0
OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250Ojcu
MHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IS0tW2VuZGlm
XS0tPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XZSBkZWZpbmVk
IHRoZW0gYXMgbGV2ZWxzIG9mIGNvbmZpZGVuY2UgcmVxdWlyZWQgKExldmVscyAxIHRocm91Z2gg
NCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5
bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhLS1baWYg
IXN1cHBvcnRMaXN0c10tLT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTpTeW1ib2w7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8
c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bh
bj48L3NwYW4+PCEtLVtlbmRpZl0tLT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
IzFGNDk3RCI+V2UgbWFwcGVkIHRoZXNlIGxldmVscyBvZiBjb25maWRlbmNlIHRvIGEgcmFuZ2Ug
b2YgZGVncmVlIG9mIGltcGFjdHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxl
dmVsMSBsZm8xIj48IS0tW2lmICFzdXBwb3J0TGlzdHNdLS0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJt
c28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3
IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhLS1bZW5kaWZdLS0+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldlIHRoZW4gc3BlY2lmaWVkIHNlcGFyYXRlbHkg
aWRlbnRpdHkgYXNzdXJhbmNlIGxldmVscyBhbmQgY3JlZGVudGlhbCBhc3N1cmFuY2UgbGV2ZWxz
IChhbmQgZm9jdXNlZCBvbiBjcmVkZW50aWFsIGZpcnN0KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDtt
c28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCEtLVtpZiAhc3VwcG9ydExpc3RzXS0tPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xvcjojMUY0OTdEIj48
c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZx
dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IS0tW2VuZGlmXS0tPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XZSBhbHNvIGZhY3RvcmVk
IG91dCBsaWtlbGlob29kIGluIHRoZSBhc3N1cmFuY2UgbGV2ZWwgYXNzZXNzbWVudCBwcm9jZXNz
LiBUaGF0IG1hZGUgdGhlIGFzc2Vzc21lbnRzIG11Y2ggbGVzcyBzdWJqZWN0aXZlLjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkF0IHRoZSBl
bmQgb2YgdGhlIGRheSwgYXMgS2VuIHN0YXRlcywgJm5ic3A7aXTigJlzIHRoZSBqb2IgdGhlIFJQ
IHRvIHVuZGVyc3RhbmQgdGhlaXIgcmlzayAoYWxvbmcgd2l0aCBsaWtlbGlob29kKSBhbmQgdG8g
Y29tbXVuaWNhdGUgYSBzdGFuZGFyZGl6ZWQgcmVxdWlyZW1lbnQgYmFjaw0KIHRvIGEgcHJvdmlk
ZXIgKEFQKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgQVAgaXMgJm5ic3A7YWNj
b3VudGFibGUgZm9yIHByb3ZpZGluZyBhIHZlcnkgcHJlc2NyaWJlZCBjb21wb25lbnQgdGhhdCBm
aXRzIGludG8gYSBsYXJnZXIgc3lzdGVtIGFuZCBhIHJpc2sgZW52aXJvbm1lbnQgdGhhdCB0aGV5
IG1pZ2h0IG5vdCBoYXZlIGEgZnVsbCB2aWV3DQogaW50by4gVGhlIFJQIG1heSBwdXQgaW4gcHJv
dmlzaW9ucyB0byBzaGFyZSB0aGUgcmlzayB3aXRoIHRoZSBBUCwgb3Igbm90IGJ1dCB0aGF0IGVu
dGlyZWx5IGRlcGVuZHMgb24gdGhlIGFycmFuZ2VtZW50LCBidXQgYXQgbGVhc3QgdGhlIFJQIGFu
ZCBBUCB1bmRlcnN0YW5kIHdoYXTigJlzIG9uIHRoZSB0YWJsZSBhcyBhIHN0YXJ0aW5nIHBvaW50
LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi
PkluIENhbmFkYSwgd2UgZGlkIHRoYXQgd2l0aCB0aGUgY3JlZGVudGlhbCBmaXJzdCwgYW5kIGFy
ZSBub3cgZmlndXJpbmcgb3V0IGlkZW50aXR5IChtdWNoIGhhcmRlcikuPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBhbHNvIGFncmVlIHRo
YXQg4oCYaWRlbnRpdHnigJkgaXMganVzdCBhIHNldCBvZiBhdHRyaWJ1dGVzIOKAk2FuZCAmbmJz
cDt0aGVzZSBpZGVudGl0eSBhdHRyaWJ1dGVzIGNhbiB2YXJ5IGJldHdlZW4gb3JnYW5pemF0aW9u
cyBvciBqdXJpc2RpY3Rpb25zLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOiMxRjQ5N0QiPkFzIGZvciB0aGUgdGVybSDigJh2ZWN0b3Jz4oCZLCBJIGdldCB0
aGUgaWRlYSwgYnV0IEkgdGhpbmsgdGhlIGNvbW11bml0eSB3aWxsIHRoaW5rIGl04oCZcyB0b28g
dGVjaG5pY2FsIG9yIGVzb3RlcmljLiBJIGxpa2UgdG8gdGhpbmsgb2YgYSDigJhkaWdpdGFsIGlk
ZW50aXR54oCZIChvcg0KIHdoYXRldmVyIHlvdSBjYWxsIGl0KSwgd2hlbiBpdCBzaG93cyB1cCBh
dCB5b3VyIGRpZ2l0YWwgZnJvbnQgZG9vciwgaXQgaXMgdGhlIHByb2R1Y3Qgb2YgYSB2ZXJ5IGxv
bmcsIGNvbXBsZXggc3VwcGx5IGNoYWluLCBmcmF1Z2h0IHdpdGggbWFueSByaXNrcyBhbmQgY29t
cHJvbWlzZXMuIEkgbWF5IGhhdmUgY29uZmlkZW5jZSBpbiBjZXJ0YWluIHBpZWNlcyBvZiwgYnV0
IG90aGVyIEkgbWlnaHQgbm90IHRydXN0IGF0IGFsbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG
NDk3RCI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi
PlRpbTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5
N0QiPiZuYnNwOzwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfX19f
X3JlcGx5c2VwYXJhdG9yIj48L2E+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7Ij4gdm90IFs8YSBocmVmPSJtYWlsdG86dm90LWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0
bzp2b3QtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPktlbiBEYWdn
PGJyPg0KPGI+U2VudDo8L2I+IE9jdG9iZXItMDktMTQgOTo0MiBQTTxicj4NCjxiPlRvOjwvYj4g
PGEgaHJlZj0ibWFpbHRvOnN3aWxzb25AbG9ja3N0ZXAuY29tLmF1Ij5zd2lsc29uQGxvY2tzdGVw
LmNvbS5hdTwvYT48YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzp2b3RAaWV0Zi5vcmci
PnZvdEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtWb1RdIEZvdW5kYXRp
b25hbCBxdWVzdGlvbnMgb2YgcHJpbmNpcGxlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij5TdGV2ZSw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFz
IHdlIGhhdmUgY29tbXVuaWNhdGVkIGluJm5ic3A7dGhlIHBhc3QsIEkgYW0gYSBzdHJvbmcgYmVs
aWV2ZXIgdGhlIGFuIExPQSBkZXNpZ25hdGlvbiBpcyBhbiBpbmRpY2F0aW9uIG9mIHRoZSBwcm9j
ZXNzZXMvbWVjaGFuaXNtcyB0aGF0IGFuJm5ic3A7SWRQIGhhcyB1bmRlcnRha2VuLiBJbiBvdGhl
ciB3b3JkcywgaXQgaXMgYSBjb21tdW5pY2F0aW9uIHRvb2wuJm5ic3A7VGhlIGNob2ljZSBpcyB0
aGUgUlBzLiBUaGF0IGlzLCBhbiZuYnNwO2Fzc2VydGlvbg0KIGF0IGEgc3BlY2lmaWMgTE9BIGJ5
IGFuJm5ic3A7SWRQL0NTUC9BUCZuYnNwO2lzIG9uZSBvZiB0aGUgbWVjaGFuaXNtcyBhIFJQIHNo
b3VsZCB1c2UgdG8gb2Zmc2V0IHRoZSBhdXRoZW50aWNhdGlvbiByaXNrIGl0IGhhcyBpZGVudGlm
aWVkIGZvciB0aGUgc2VydmljZSBpdCB3YW50cyB0byBkZWxpdmVyLiBJbiBvdGhlciB3b3Jkcywg
aXQgaXMgdGhlIHJpc2sgb2YgdGhlIFJQIHRoYXQgaXMgcGFyYW1vdW50IG5vdCB0aGUgY2xhaW1z
IG9mIGFuJm5ic3A7aWRlbnRpdHkvY3JlZGVudGlhbC9hdHRyaWJ1dGUvdG9rZW4NCiBwcm92aWRl
ci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
TGlrZSB5b3UsIEkgYW0gYSBzdHJvbmcgYmVsaWV2ZXIgdGhhdCB0aGUgZGV0ZXJtaW5hdGlvbiBv
ZiB3aGV0aGVyIG9yIG5vdCBhbiBpZGVudGl0eSBpcyBnb29kIGVub3VnaCBpcyB0aGUgcmVzcG9u
c2liaWxpdHkgb2YgdGhlIFJQLiBJbiBteSBleHBlcmllbmNlLCB0aGV5IG1ha2UgdGhhdCBkZXRl
cm1pbmF0aW9uIGJhc2VkIHVwb24gYSBzZXQgb2YgYXR0cmlidXRlcyB0aGV5IGJlbGlldmUgYXJl
IG5lY2Vzc2FyeS4NCiBJZiB0aGV5IHRydXN0IHRoYXQgYW4gSWRQJ3MgYXNzZXJ0aW9uIG9mIGlk
ZW50aXR5IGNvdmVycyB0aGUgYXR0cmlidXRlcyB0aGV5IGJlbGlldmUgYXJlJm5ic3A7cmVxdWly
ZWQgdGhlbSB0aGV5IGNhbiBhY2NlcHQgdGhlIGFzc2VydGlvbi4gSWYgaXQgZG9lc24ndCB0aGVu
IHRoYXQgaGF2ZSB0byBpbXBsZW1lbnQgYWRkaXRpb25hbCBtZWNoYW5pc21zIHRvIG9mZnNldCB0
aGUgcmVzaWR1YWwgcmlzay48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+V2l0aCByZXNwZWN0IHRvIHZlY3RvcnMgb2YgdHJ1c3QsIEkgYW0gaW50
ZXJlc3RlZCBpbiBleHBsb3Jpbmcgd2hhdCB0aGV5IGFyZSBhbmQgaG93IHRoZXkgY2FuIGJlIGFw
cGxpZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPktlbjxicj4NCjxicj4NCk9uIFRodXJzZGF5LCBPY3RvYmVyIDksIDIwMTQsICZsdDs8YSBo
cmVmPSJtYWlsdG86c3dpbHNvbkBsb2Nrc3RlcC5jb20uYXUiPnN3aWxzb25AbG9ja3N0ZXAuY29t
LmF1PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBj
bSAwY20gMC4wMDAxcHQ7IHdvcmQtd3JhcDogYnJlYWstd29yZDsiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFy
Z2luOiAwY20gMGNtIDAuMDAwMXB0OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7Ij48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7Ij5GaXJzdCwgdG8gaW50cm9kdWNlIG15c2VsZiwgSSBhbSBhbiBpZGVu
dGl0eSBhbmQgcHJpdmFjeSByZXNlYXJjaGVyLCBhbmFseXN0IGFuZCBjb25zdWx0YW50LiZuYnNw
OyBJJ3ZlIGJlZW4gaW52b2x2ZWQgaW4gdGhpcyBzaW5jZSAxOTk1LA0KIHdoZW4gSSBjdXQgbXkg
dGVldGggaW4gUEtJIGFuZCBzbWFydGNhcmRzICh3aXRoIHRoZSBlYXJseSBjb21wYW5pZXMgdGhh
dCBiZWNhbWUgQmFsdGltb3JlIFRlY2hub2xvZ2llcykuIFNpbmNlIHRoZW4gSSd2ZSB3b3JrZWQg
b24gaWRlbnRpdHkgbWFuYWdlbWVudCBmcmFtZXdvcmtzLCByZWd1bGF0aW9ucyBhbmQgc3RhbmRh
cmRzLiAmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjog
MGNtIDBjbSAwLjAwMDFwdDsgd29yZC13cmFwOiBicmVhay13b3JkOyI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJt
YXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IHdvcmQtd3JhcDogYnJlYWstd29yZDsiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDsiPkkgc3Vic2NyaWJlIHRvIHRoZSBvbGQgSXRhbGlhbiBwcm92ZXJi
OiAmcXVvdDtpdCdzIG5pY2UgdG8gdHJ1c3QgYnV0IGJldHRlciBub3QgdG8mcXVvdDsuJm5ic3A7
IFdvcmRzIG1hdHRlciBhbmQgSSB3b25kZXIgaWYgd2Ugc2hvdWxkbid0IGJlIHVzaW5nDQogdGhl
IHdvcmQgdHJ1c3Qgc28gbXVjaC4gJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2
IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IHdvcmQtd3JhcDogYnJlYWstd29yZDsi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvZGl2
Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyB3b3JkLXdyYXA6IGJyZWFr
LXdvcmQ7Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB
cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Nb3JlIHByYWdtYXRpY2FsbHksIEkg
bm90ZSB0aGUgdmVyeSBzdHJvbmcgJnF1b3Q7QXR0cmlidXRlcyZxdW90OyBwdXNoIG9mIHRoZSBw
YXN0IDE4IG1vbnRocy4mbmJzcDsgQW5kcmV3IE5hc2gsIEFuaWwgSm9obiwgbXlzZWxmIGFuZCBv
dGhlcnMgaGF2ZQ0KIHdyaXR0ZW4gYWJvdXQgdGhpcy4mbmJzcDsgVGhlIEZJRE8gQWxsaWFuY2Ug
aXMgYWxsIGFib3V0IGF1dGhlbnRpY2F0aW9uIGFuZCBhdHRyaWJ1dGVzLCBhbmQgdGhleSBwdXJw
b3NlZnVsbHkgbGVhdmUgJnF1b3Q7aWRlbnRpdHkmcXVvdDsgYXMgYSBtYXR0ZXIgZm9yIG90aGVy
cyB0byB3b3JrIG91dCBmdXJ0aGVyIHVwIHRoZSBzdGFjay4gVGhlIE9JRCBGb3VuZGF0aW9uIGlz
IHByb21vdGluZyBhbiBBdHRyaWJ1dGVzIEV4Y2hhbmdlIE5ldHdvcmsgJnF1b3Q7QVhOJnF1b3Q7
IGFyY2hpdGVjdHVyZS4mbmJzcDsNCiBOZXcgZW50cmFudHMgbGlrZSA8YSBocmVmPSJodHRwOi8v
aWQubWUvIiB0YXJnZXQ9Il9ibGFuayI+aWQubWU8L2E+IChhbiBOU1RJQyBwaWxvdCBwYXJ0aWNp
cGFudCkgdGFsayBhYm91dCBhdHRyaWJ1dGVzIGFuZCBhdm9pZCAmcXVvdDtpZGVudGl0eSZxdW90
Oy4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNt
IDBjbSAwLjAwMDFwdDsgd29yZC13cmFwOiBicmVhay13b3JkOyI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJn
aW46IDBjbSAwY20gMC4wMDAxcHQ7IHdvcmQtd3JhcDogYnJlYWstd29yZDsiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDsiPkkgbWVudGlvbiBhbGwgb2YgdGhpcyBhcyBhIHByZWx1ZGUgdG8gc3Vn
Z2VzdCB0aGF0ICZxdW90O3ZlY3RvciBvZiB0cnVzdCZxdW90OyBpcyBzeW5vbnltb3VzIHdpdGgg
JnF1b3Q7YXR0cmlidXRlJnF1b3Q7LiBJIHdvbmRlciBpZiBpdCB3b3VsZCBiZSBjbGVhcmVyDQog
dG8gdXNlIHBsYWluIGFuZCBjdXJyZW50IGxhbmd1YWdlIHJhdGhlciB0aGFuIGNhcnJ5IGZvcndh
cmQgdGhlIGZ1enp5IGFuZCBJIHRoaW5rIG92ZXJseSBhbWJpdGlvdXMgaWRlYSBvZiAmcXVvdDt0
cnVzdCZxdW90Oz8mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1h
cmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgd29yZC13cmFwOiBicmVhay13b3JkOyI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0
eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IHdvcmQtd3JhcDogYnJlYWstd29yZDsiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZpbmFsbHksIEknZCBsaWtlIHRvIHRocm93IGluIG15
IGFiaWRpbmcgY29uY2VybiB0aGF0IExPQXMgaGF2ZSBmb3VuZGVyZWQgc2ltcGx5IGJlY2F1c2Ug
aXQncyBkaWZmaWN1bHQgdG8gcGlnZW9uaG9sZSByaXNrLiBPbmUgcGFydHkncw0KIGlkZWEgb2Yg
JnF1b3Q7bWVkaXVtJnF1b3Q7IHJpc2sgZm9yIGluc3RhbmNlIHdpbGwgcmFyZWx5IG1hcCBwcmVj
aXNlbHkgdG8gYW5vdGhlcidzLiBJIHRoaW5rIHBlb3BsZSBoYXZlIGJlZW4gbWlzbGVkIGludG8g
dGhpbmtpbmcgdGhhdCBhbiAmcXVvdDtMT0EgMyZxdW90OyBpZGVudGl0eSBzaG91bGQgYmUgYmUg
YWJsZSB0byBiZSB1c2VkIG9uIGl0cyBmYWNlIChpLmUuIHdpbGwgJnF1b3Q7aW50ZXJvcGVyYXRl
JnF1b3Q7KSBhdCBhbnkgJnF1b3Q7TE9BIDMmcXVvdDsgUlAuIFJpc2sgbWFuYWdlbWVudCBpcyBu
b3QNCiBzbyBzaW1wbGUuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxl
PSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IHdvcmQtd3JhcDogYnJlYWstd29yZDsiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRp
diBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaGUgTE9BIHBhcmFkaWdtIGJvcnJvd3MgZnJv
bSBSaXNrIE1hbmFnZW1lbnQgc3RhbmRhcmRzIGxpa2UgSVNPIDMxMDAwIHdoaWNoJm5ic3A7b3Jn
YW5pc2F0aW9ucyB1c2UgdG8mbmJzcDtwbG90Jm5ic3A7dGhlaXIgb3duIHJpc2tzIGludGVybmFs
bHkgdHlwaWNhbGx5DQogb24gYSBmaXZlIHNjYWxlIChlZyBOZWdsaWdpYmxlIC8gTG93IC8gTWVk
aXVtIC8gSGlnaCAvIEdyYXZlKS4mbmJzcDtCdXQmbmJzcDtyaXNrIG1hbmFnZW1lbnQmbmJzcDtz
dGFuZGFyZHMgcmVxdWlyZSB0aGF0IGVhY2ggb3JnYW5pc2F0aW9uIGNhbGlicmF0ZXMgcmlzayBp
biBpdHMgb3duIGJ1c2luZXNzIGNvbnRleHQgYW5kIGFjY29yZGluZyB0byBpdHMmbmJzcDtvd24g
cmlzayBhcHBldGl0ZS4gVGhlIHJpc2sgb2YgYSBmaXJld2FsbCBicmVhY2ggZm9yIGV4YW1wbGUg
YXQgYSBzdGFydHVwDQogc29jaWFsIG1lZGlhIGNvbXBhbnkgd2lsbCBiZSBhc3Nlc3NlZCBkaWZm
ZXJlbnRseSBieSBhIGJpZyBsaXN0ZWQgaGVhbHRoY2FyZSBjb21wYW55LiZuYnNwO1NvIG9yZ2Fu
aXNhdGlvbiBBJm5ic3A7Y2FuIHNheSB0aGUgcmlzayBvZiBldmVudCBYIGlzIExvdyBidXQgQiBj
YW4gc2F5IHRoZSByaXNrIG9mIHRoZSBzYW1lIGV2ZW50IGlzIE1lZGl1bS4mbmJzcDsgQXMmbmJz
cDthIHJlc3VsdCwgTE9BcyBkbyBub3QgaW50ZXItb3BlcmF0ZS4gVGhleSBhcmUgYmFzZWQgb24g
c3RhbmRhcmRzDQogbWVhbnQgZm9yIGludHJhLW9yZ2FuaXNhdGlvbiByaXNrIG1hbmFnZW1lbnQs
IG5vdCBpbnRlci1vcmdhbmlzYXRpb24gY29tbXVuaWNhdGlvbiBvZiZuYnNwO3Jpc2sgYXNzZXNz
bWVudHMuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46
IDBjbSAwY20gMC4wMDAxcHQ7IHdvcmQtd3JhcDogYnJlYWstd29yZDsiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0i
bWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7Ij48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7Ij5TbyBmYXIgd2l0aCBWb1Qgd2UgYXJlIGFkZGluZyBtb3JlIGRp
bWVuc2lvbnMgdG8gdGhlIFJQcycgZ2VuZXJpYyByaXNrIG1hbmFnZW1lbnQgZGVjaXNpb24gbWFr
aW5nLCBhbmQgdGhhdCdzIGdyZWF0LiZuYnNwOyBCdXQgd2UgYXJlIHN0aWxsDQogcGlnZW9uaG9s
aW5nIHRoZSBkaW1lbnNpb25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0i
bWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7Ij48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYg
c3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgd29yZC13cmFwOiBicmVhay13b3JkOyI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SSdtIGFmcmFpZCB0aGUgcmVhbGl0eSBpcyB0aGF0
IHJpc2sgbWFuYWdlbWVudCB3aWxsIGFsd2F5cyBiZSBkb25lIGxvY2FsbHkuJm5ic3A7IEFuZCBz
byBpdCBzaG91bGQgYmUuJm5ic3A7IFdoZW4gYW4gUlAgaXMgbWFraW5nJm5ic3A7dGhlIGRlY2lz
aW9uDQogdG8gYWNjZXB0IG9yIHJlamVjdCBhIGdpdmVuIHN1YmplY3QsIHRoZXkgd2lsbCBldmFs
dWF0ZSBhIHJhbmdlIG9mIGF0dHJpYnV0ZXMgb3ImbmJzcDtzaWduYWxzLiZuYnNwOyBUaGUgc2V0
IG9mIGF0dHJpYnV0ZXMgdGhhdCBtYXR0ZXJzIHZhcmllcyBmcm9tIG9uZSBSUCB0byB0aGUgbmV4
dC4mbmJzcDsgSSB0aGluayBpdCdzIGEgZ3JlYXQgaWRlYSBpbmRlZWQgdG8gY3JlYXRlIGd1aWRh
bmNlIGZvciBldmFsdWF0aW5nIGF0dHJpYnV0ZXMsIGFuZCB0byBjb2FjaCBSUHMgdG8NCiBsb29r
IGF0IGFsbCBzb3J0cyBvZiBkaW1lbnNpb25zLiZuYnNwOyBJIGp1c3QgZG9uJ3QgdGhpbmsgaXQg
aGVscHMgYW55b25lIHRvIHBpZ2VvbmhvbGUgdGhlIHJpc2sgcmF0aW5ncywgYmVjYXVzZSBhY3Jv
c3Mgb3JnYW5pc2F0aW9ucywgYXJndW1lbnRzIGFib3V0IHRoZSBib3VuZGFyaWVzIGJldHdlZW4g
TE9BIDEvMi8zLzQgKHRoYXQgaXMsIHBvbGljeSBtYXBwaW5nKSB3aWxsJm5ic3A7dW5kbyBhbnkg
ZWZmaWNpZW5jaWVzIGdhaW5lZCBmcm9tIHRoZSBjYXRlZ29yaXphdGlvbi4NCiAmbmJzcDs8bzpw
PjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFw
dDsgd29yZC13cmFwOiBicmVhay13b3JkOyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5i
c3A7PG86cD48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20g
MC4wMDAxcHQ7IHdvcmQtd3JhcDogYnJlYWstd29yZDsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDsiPkNoZWVycywmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1h
cmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgd29yZC13cmFwOiBicmVhay13b3JkOyI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0
eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IHdvcmQtd3JhcDogYnJlYWstd29yZDsiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlN0ZXZlLjxvOnA+PC9vOnA+PC9zcGFuPjwvZGl2Pg0K
PGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyB3b3JkLXdyYXA6IGJyZWFrLXdv
cmQ7Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh
bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48
L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgd29yZC13cmFwOiBi
cmVhay13b3JkOyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48
L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IHdvcmQt
d3JhcDogYnJlYWstd29yZDsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlN0ZXBoZW4gV2ls
c29uPGJyPg0KTWFuYWdpbmcgRGlyZWN0b3I8YnI+DQpMb2Nrc3RlcCBHcm91cDxicj4NCjxhIGhy
ZWY9Imh0dHA6Ly9sb2Nrc3RlcC5jb20uYXUvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL2xvY2tz
dGVwLmNvbS5hdTwvYT48YnI+DQpMb2Nrc3RlcCBDb25zdWx0aW5nIHByb3ZpZGVzIGluZGVwZW5k
ZW50IHNwZWNpYWxpc3QgYWR2aWNlIGFuZCBhbmFseXNpcyA8YnI+DQpvbiBkaWdpdGFsIGlkZW50
aXR5IGFuZCBwcml2YWN5LiBMb2Nrc3RlcCBUZWNobm9sb2dpZXMgZGV2ZWxvcHMgdW5pcXVlIDxi
cj4NCm5ldyBzbWFydCBJRCBzb2x1dGlvbnMgdGhhdCBlbmhhbmNlIHByaXZhY3kgYW5kIHByZXZl
bnQgaWRlbnRpdHkgdGhlZnQuPG86cD48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJt
YXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IHdvcmQtd3JhcDogYnJlYWstd29yZDsiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBz
dHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7Ij48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2Rpdj4N
CjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgd29yZC13cmFwOiBicmVhay13
b3JkOyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp
YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+
PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXzxicj4NCnZvdCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVm
PSJtYWlsdG86dm90QGlldGYub3JnIj52b3RAaWV0Zi5vcmc8L2E+PGJyPg0KaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92b3Q8YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N
Cjxicj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_6A0CFC85F8F543F5B02F09720E7164F4mitreorg_--


From nobody Fri Oct 10 20:02:47 2014
Return-Path: 
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 382B91A1A3A for ; Fri, 10 Oct 2014 20:02:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Nr63wSHjz-x for ; Fri, 10 Oct 2014 20:02:41 -0700 (PDT)
Received: from smtp101.iad3a.emailsrvr.com (smtp101.iad3a.emailsrvr.com [173.203.187.101]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1539E1A1A2F for ; Fri, 10 Oct 2014 20:02:40 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp21.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 3EF17180205 for ; Fri, 10 Oct 2014 23:02:39 -0400 (EDT)
X-Virus-Scanned: OK
Received: from app39.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp21.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 26193180204 for ; Fri, 10 Oct 2014 23:02:38 -0400 (EDT)
X-Sender-Id: swilson@lockstep.com.au
Received: from app39.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.2.13); Sat, 11 Oct 2014 03:02:39 GMT
Received: from lockstep.com.au (localhost.localdomain [127.0.0.1]) by app39.wa-webapps.iad3a (Postfix) with ESMTP id 9B6A438004A for ; Fri, 10 Oct 2014 23:02:38 -0400 (EDT)
Received: by apps.rackspace.com (Authenticated sender: swilson@lockstep.com.au, from: swilson@lockstep.com.au)  with HTTP; Sat, 11 Oct 2014 14:02:38 +1100 (EST)
Date: Sat, 11 Oct 2014 14:02:38 +1100 (EST)
From: swilson@lockstep.com.au
To: vot@ietf.org
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Importance: Normal
X-Priority: 3 (Normal)
X-Type: plain
In-Reply-To: <20.D5.19194.872F7345@smtp13.gate.ord1b.rsapps.net>
References: <1412885935.58929166@apps.rackspace.com>    <20.D5.19194.872F7345@smtp13.gate.ord1b.rsapps.net>
X-Auth-ID: swilson@lockstep.com.au
Message-ID: <1412996558.634210347@apps.rackspace.com>
X-Mailer: webmail7.0
Archived-At: http://mailarchive.ietf.org/arch/msg/vot/NcU0Dtf2QY8dW3CGf84ZSzZlQj0
Subject: Re: [VoT] Foundational questions of principle
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Vectors of Trust discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 11 Oct 2014 03:02:45 -0000

=0AWe are all agreed of course that RPs need to understand their risks, det=
ermine what's needed from any external process of identification or attribu=
te attestation, communicate those needs to candidate APs, and from there, c=
ontract an acceptable provider. =0A=0AMy question is whether or not a pigeo=
nholed LOA helps at any point in this process.  =0A=0AThe devil is in the d=
etail.  To my mind, LOA is an intermediate step that takes a detailed risk =
analysis, squeezes it into a bin (losing lots of information as a result), =
which is then used to shortlist candidate providers, before going into deta=
iled due diligence where all those details need to be put back on the table=
. =0A=0AI think we all know by now of cases where RPs have looked at candid=
ate IdPs at a given LOA, and have come up with the request of "LOA two and =
a half" (this was mentioned at CIS 2014 more than once, and I have seen it =
first hand in the UK IDAP). =0A=0AClearly what's going on here is an RP's i=
dea of say "LOA 2" differs from a given IdP's idea of LOA 2.  Moreover, the=
 idea of LOA 2 must differ from one IdP to another IdP.  When people ask fo=
r "LOA 2.5" what they're asking for is a customised identification.  If LOA=
 2 isn't what it seems, then there cannot possibly be any such thing as a *=
standardised* LOA 2.5.  All we will get is fresh calls for "LOA 2.75 please=
". =0A=0AIf RPs need to do detailed analysis of authentication needs, and g=
et detailed verification of the actual ID proofing done by IdPs and APs, th=
en I just don't see any point attaching the LOA label along the way.  It's =
misleading. =0A=0ACheers, =0A=0ASteve.=0A=0AStephen Wilson=0ALockstep =0Aht=
tp://lockstep.com.au=0ALockstep Consulting provides independent specialist =
advice and analysis =0Aon digital identity and privacy.  Lockstep Technolog=
ies develops unique =0Anew smart ID solutions that enhance privacy and prev=
ent identity theft.=0A=0A=0A=0A-----Original Message-----=0AFrom: "Bouma, T=
im" =0ASent: Saturday, 11 October, 2014 1:51am=0AT=
o: "Ken Dagg" , "swilson@lockstep.com.au" =0ACc: "vot@ietf.org" =0ASubject: RE: [VoT] Fou=
ndational questions of principle=0A=0AI agree with Ken,=0A=0AWhen we develo=
ped levels of assurance (here in Canada) we did several things:=0A=0A=C2=B7=
         We defined them as levels of confidence required (Levels 1 through=
 4)=0A=C2=B7         We mapped these levels of confidence to a range of deg=
ree of impacts.=0A=C2=B7         We then specified separately identity assu=
rance levels and credential assurance levels (and focused on credential fir=
st)=0A=C2=B7         We also factored out likelihood in the assurance level=
 assessment process. That made the assessments much less subjective.=0A=0AA=
t the end of the day, as Ken states,  it=E2=80=99s the job the RP to unders=
tand their risk (along with likelihood) and to communicate a standardized r=
equirement back to a provider (AP)=0AThe AP is  accountable for providing a=
 very prescribed component that fits into a larger system and a risk enviro=
nment that they might not have a full view into. The RP may put in provisio=
ns to share the risk with the AP, or not but that entirely depends on the a=
rrangement, but at least the RP and AP understand what=E2=80=99s on the tab=
le as a starting point.=0A=0AIn Canada, we did that with the credential fir=
st, and are now figuring out identity (much harder).=0A=0AI also agree that=
 =E2=80=98identity=E2=80=99 is just a set of attributes =E2=80=93and  these=
 identity attributes can vary between organizations or jurisdictions,=0A=0A=
As for the term =E2=80=98vectors=E2=80=99, I get the idea, but I think the =
community will think it=E2=80=99s too technical or esoteric. I like to thin=
k of a =E2=80=98digital identity=E2=80=99 (or whatever you call it), when i=
t shows up at your digital front door, it is the product of a very long, co=
mplex supply chain, fraught with many risks and compromises. I may have con=
fidence in certain pieces of, but other I might not trust at all.=0A=0A=0AT=
im=0A=0A=0AFrom: vot [mailto:vot-bounces@ietf.org] On Behalf Of Ken Dagg=0A=
Sent: October-09-14 9:42 PM=0ATo: swilson@lockstep.com.au=0ACc: vot@ietf.or=
g=0ASubject: Re: [VoT] Foundational questions of principle=0A=0ASteve,=0A=
=0AAs we have communicated in the past, I am a strong believer the an LOA d=
esignation is an indication of the processes/mechanisms that an IdP has und=
ertaken. In other words, it is a communication tool. The choice is the RPs.=
 That is, an assertion at a specific LOA by an IdP/CSP/AP is one of the mec=
hanisms a RP should use to offset the authentication risk it has identified=
 for the service it wants to deliver. In other words, it is the risk of the=
 RP that is paramount not the claims of an identity/credential/attribute/to=
ken provider.=0A=0ALike you, I am a strong believer that the determination =
of whether or not an identity is good enough is the responsibility of the R=
P. In my experience, they make that determination based upon a set of attri=
butes they believe are necessary. If they trust that an IdP's assertion of =
identity covers the attributes they believe are required them they can acce=
pt the assertion. If it doesn't then that have to implement additional mech=
anisms to offset the residual risk.=0A=0AWith respect to vectors of trust, =
I am interested in exploring what they are and how they can be applied.=0A=
=0AKen=0A=0AOn Thursday, October 9, 2014, > wrote:=0A=0A=0A=0AFirst, to introduce myself, I am=
 an identity and privacy researcher, analyst and consultant.  I've been inv=
olved in this since 1995, when I cut my teeth in PKI and smartcards (with t=
he early companies that became Baltimore Technologies). Since then I've wor=
ked on identity management frameworks, regulations and standards.=0A=0A=0A=
=0AI subscribe to the old Italian proverb: "it's nice to trust but better n=
ot to".  Words matter and I wonder if we shouldn't be using the word trust =
so much.=0A=0A=0A=0AMore pragmatically, I note the very strong "Attributes"=
 push of the past 18 months.  Andrew Nash, Anil John, myself and others hav=
e written about this.  The FIDO Alliance is all about authentication and at=
tributes, and they purposefully leave "identity" as a matter for others to =
work out further up the stack. The OID Foundation is promoting an Attribute=
s Exchange Network "AXN" architecture.  New entrants like id.me (an NSTIC pilot participant) talk about attributes and avoid "identity".=
=0A=0A=0A=0AI mention all of this as a prelude to suggest that "vector of t=
rust" is synonymous with "attribute". I wonder if it would be clearer to us=
e plain and current language rather than carry forward the fuzzy and I thin=
k overly ambitious idea of "trust"?=0A=0A=0A=0AFinally, I'd like to throw i=
n my abiding concern that LOAs have foundered simply because it's difficult=
 to pigeonhole risk. One party's idea of "medium" risk for instance will ra=
rely map precisely to another's. I think people have been misled into think=
ing that an "LOA 3" identity should be be able to be used on its face (i.e.=
 will "interoperate") at any "LOA 3" RP. Risk management is not so simple.=
=0A=0A=0A=0AThe LOA paradigm borrows from Risk Management standards like IS=
O 31000 which organisations use to plot their own risks internally typicall=
y on a five scale (eg Negligible / Low / Medium / High / Grave). But risk m=
anagement standards require that each organisation calibrates risk in its o=
wn business context and according to its own risk appetite. The risk of a f=
irewall breach for example at a startup social media company will be assess=
ed differently by a big listed healthcare company. So organisation A can sa=
y the risk of event X is Low but B can say the risk of the same event is Me=
dium.  As a result, LOAs do not inter-operate. They are based on standards =
meant for intra-organisation risk management, not inter-organisation commun=
ication of risk assessments.=0A=0A=0A=0ASo far with VoT we are adding more =
dimensions to the RPs' generic risk management decision making, and that's =
great.  But we are still pigeonholing the dimensions.=0A=0A=0A=0AI'm afraid=
 the reality is that risk management will always be done locally.  And so i=
t should be.  When an RP is making the decision to accept or reject a given=
 subject, they will evaluate a range of attributes or signals.  The set of =
attributes that matters varies from one RP to the next.  I think it's a gre=
at idea indeed to create guidance for evaluating attributes, and to coach R=
Ps to look at all sorts of dimensions.  I just don't think it helps anyone =
to pigeonhole the risk ratings, because across organisations, arguments abo=
ut the boundaries between LOA 1/2/3/4 (that is, policy mapping) will undo a=
ny efficiencies gained from the categorization.=0A=0A=0A=0ACheers,=0A=0A=0A=
=0ASteve.=0A=0A=0A=0A=0A=0AStephen Wilson=0AManaging Director=0ALockstep Gr=
oup=0Ahttp://lockstep.com.au=0ALockstep Consulting provides independent spe=
cialist advice and analysis=0Aon digital identity and privacy. Lockstep Tec=
hnologies develops unique=0Anew smart ID solutions that enhance privacy and=
 prevent identity theft.=0A=0A=0A=0A=0A=0A=0A


From nobody Fri Oct 10 20:32:55 2014
Return-Path: 
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 427EA1A1A59 for ; Fri, 10 Oct 2014 20:32:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LCMb7cdEUI4g for ; Fri, 10 Oct 2014 20:32:48 -0700 (PDT)
Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FCF41A1A57 for ; Fri, 10 Oct 2014 20:32:47 -0700 (PDT)
Received: by mail-lb0-f176.google.com with SMTP id p9so3988180lbv.21 for ; Fri, 10 Oct 2014 20:32:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=lHE6fcPyRRlKDxGcImu2+/jU3/PiNF9oaDhJW13bUEc=; b=djIG2qp4doZWgjAwWpzN2oIBdwmd26dcoAzuqalr3wwwjO9YhfbwXMU8Y5oUE7jL6Y 4Nz4qHSmDmN6NFy/zHcXRZ1xl4al4CQ2z6isNPl8W8bU2F7o4uz1Vu+udr8uzXA9bVJ2 sx5MlcgazySz+H0MPC2ls4aWeiRiHbKyrDeFsEUQSPIU6z9ACw6xyj77gcuT+/xXCT8O nHZzuv/qDbnqegP07S7aBwgb8AnzT3Sz+Vg5ZdokHikLnlvOF3CL1kGbyaTOaCHS+YTF N5R8oSwuBJ07ackLu8jia3UvWWJyKVlrc7Kn9Rp6ZAbJy3sW2hjtONJBT6hTzgY/Lcny GR2w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=lHE6fcPyRRlKDxGcImu2+/jU3/PiNF9oaDhJW13bUEc=; b=eLhVEqKgJ+0N94K/ON7HEqYFhxfjdqzcNUD8Qx1ybSGReHdYErPuG+miJ+jHnxZx5/ HA6JZ+aYKNQUyVgBz5BetioyVPBVxEtvf54+w7jujEh/iMATxPcDvj+rZIsktZAmgen8 /xbptGCoFmhbshxQXzuBQfSOV8eOgfdbzECF5ZmrsYe/HMs9dwHudu4daIDeuq9lF4xL Qw7RzcAkc0Bk9z3hX/wc6yjfGgAzzdvD5vSvzGPrOnLUoFPfVWSKD5dzvfrYVyjlE2kj Oj7pso+z3C9RvH3VhLpWgQ1wo0mbQDbwQRb9RIA0j1rlKl1Xme2t1Ti1Z8c64o7xSfnf b8pw==
X-Received: by 10.112.65.5 with SMTP id t5mr306406lbs.82.1412998365560; Fri, 10 Oct 2014 20:32:45 -0700 (PDT)
Received: from mail-la0-f52.google.com (mail-la0-f52.google.com [209.85.215.52]) by mx.google.com with ESMTPSA id bk5sm2310788lbd.30.2014.10.10.20.32.44 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 10 Oct 2014 20:32:44 -0700 (PDT)
Received: by mail-la0-f52.google.com with SMTP id hz20so4224596lab.25 for ; Fri, 10 Oct 2014 20:32:43 -0700 (PDT)
X-Gm-Message-State: ALoCoQnt2Zu9/4xq0m5aRuaONe+jkgLvG3fo1za3lS44Ai7kcFHoP9kLuobOMQ+O80QKBlMwl2mW
X-Received: by 10.152.27.200 with SMTP id v8mr8898813lag.53.1412998363729; Fri, 10 Oct 2014 20:32:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.213.72 with HTTP; Fri, 10 Oct 2014 20:32:03 -0700 (PDT)
In-Reply-To: <1412996558.634210347@apps.rackspace.com>
References: <1412885935.58929166@apps.rackspace.com>  <20.D5.19194.872F7345@smtp13.gate.ord1b.rsapps.net> <1412996558.634210347@apps.rackspace.com>
From: Anil John 
Date: Fri, 10 Oct 2014 23:32:03 -0400
Message-ID: 
To: swilson@lockstep.com.au
Content-Type: multipart/alternative; boundary=089e0160a3be89ebb505051d515a
Archived-At: http://mailarchive.ietf.org/arch/msg/vot/gb4PREE5yVbKbfENm0cbuPwx2yo
Cc: vot@ietf.org
Subject: Re: [VoT] Foundational questions of principle
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Vectors of Trust discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 11 Oct 2014 03:32:52 -0000

--089e0160a3be89ebb505051d515a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

It may make sense to look at LOAs as something that is "coarse-grained" and
a starting point.

We all think it is not enough, but in the absence of the Borg showing up to
enforce a collective hive-mind across organizational boundaries, we can
live with it and use it as a starting point for the discussion "What more
do we need in order to let this person in the door?"

And that is where RP implemented compensating controls can play a part. The
challenge is that folks seem to conflate "things needed to ensure
confidence in an identity" with "things needed to mitigate risk in the
transaction" and who is (CSP or RP) responsible for what.

Regards,

- Anil

:- Anil John
:- Making Digital Services Secure and Trustworthy
:- https://blog.aniljohn.com


On Fri, Oct 10, 2014 at 11:02 PM,  wrote:

>
> We are all agreed of course that RPs need to understand their risks,
> determine what's needed from any external process of identification or
> attribute attestation, communicate those needs to candidate APs, and from
> there, contract an acceptable provider.
>
> My question is whether or not a pigeonholed LOA helps at any point in thi=
s
> process.
>
> The devil is in the detail.  To my mind, LOA is an intermediate step that
> takes a detailed risk analysis, squeezes it into a bin (losing lots of
> information as a result), which is then used to shortlist candidate
> providers, before going into detailed due diligence where all those detai=
ls
> need to be put back on the table.
>
> I think we all know by now of cases where RPs have looked at candidate
> IdPs at a given LOA, and have come up with the request of "LOA two and a
> half" (this was mentioned at CIS 2014 more than once, and I have seen it
> first hand in the UK IDAP).
>
> Clearly what's going on here is an RP's idea of say "LOA 2" differs from =
a
> given IdP's idea of LOA 2.  Moreover, the idea of LOA 2 must differ from
> one IdP to another IdP.  When people ask for "LOA 2.5" what they're askin=
g
> for is a customised identification.  If LOA 2 isn't what it seems, then
> there cannot possibly be any such thing as a *standardised* LOA 2.5.  All
> we will get is fresh calls for "LOA 2.75 please".
>
> If RPs need to do detailed analysis of authentication needs, and get
> detailed verification of the actual ID proofing done by IdPs and APs, the=
n
> I just don't see any point attaching the LOA label along the way.  It's
> misleading.
>
> Cheers,
>
> Steve.
>
> Stephen Wilson
> Lockstep
> http://lockstep.com.au
> Lockstep Consulting provides independent specialist advice and analysis
> on digital identity and privacy.  Lockstep Technologies develops unique
> new smart ID solutions that enhance privacy and prevent identity theft.
>
>
>
> -----Original Message-----
> From: "Bouma, Tim" 
> Sent: Saturday, 11 October, 2014 1:51am
> To: "Ken Dagg" , "swilson@lockstep.com.au" <
> swilson@lockstep.com.au>
> Cc: "vot@ietf.org" 
> Subject: RE: [VoT] Foundational questions of principle
>
> I agree with Ken,
>
> When we developed levels of assurance (here in Canada) we did several
> things:
>
> =C2=B7         We defined them as levels of confidence required (Levels 1
> through 4)
> =C2=B7         We mapped these levels of confidence to a range of degree =
of
> impacts.
> =C2=B7         We then specified separately identity assurance levels and
> credential assurance levels (and focused on credential first)
> =C2=B7         We also factored out likelihood in the assurance level
> assessment process. That made the assessments much less subjective.
>
> At the end of the day, as Ken states,  it=E2=80=99s the job the RP to und=
erstand
> their risk (along with likelihood) and to communicate a standardized
> requirement back to a provider (AP)
> The AP is  accountable for providing a very prescribed component that fit=
s
> into a larger system and a risk environment that they might not have a fu=
ll
> view into. The RP may put in provisions to share the risk with the AP, or
> not but that entirely depends on the arrangement, but at least the RP and
> AP understand what=E2=80=99s on the table as a starting point.
>
> In Canada, we did that with the credential first, and are now figuring ou=
t
> identity (much harder).
>
> I also agree that =E2=80=98identity=E2=80=99 is just a set of attributes =
=E2=80=93and  these
> identity attributes can vary between organizations or jurisdictions,
>
> As for the term =E2=80=98vectors=E2=80=99, I get the idea, but I think th=
e community will
> think it=E2=80=99s too technical or esoteric. I like to think of a =E2=80=
=98digital
> identity=E2=80=99 (or whatever you call it), when it shows up at your dig=
ital front
> door, it is the product of a very long, complex supply chain, fraught wit=
h
> many risks and compromises. I may have confidence in certain pieces of, b=
ut
> other I might not trust at all.
>
>
> Tim
>
>
> From: vot [mailto:vot-bounces@ietf.org] On Behalf Of Ken Dagg
> Sent: October-09-14 9:42 PM
> To: swilson@lockstep.com.au
> Cc: vot@ietf.org
> Subject: Re: [VoT] Foundational questions of principle
>
> Steve,
>
> As we have communicated in the past, I am a strong believer the an LOA
> designation is an indication of the processes/mechanisms that an IdP has
> undertaken. In other words, it is a communication tool. The choice is the
> RPs. That is, an assertion at a specific LOA by an IdP/CSP/AP is one of t=
he
> mechanisms a RP should use to offset the authentication risk it has
> identified for the service it wants to deliver. In other words, it is the
> risk of the RP that is paramount not the claims of an
> identity/credential/attribute/token provider.
>
> Like you, I am a strong believer that the determination of whether or not
> an identity is good enough is the responsibility of the RP. In my
> experience, they make that determination based upon a set of attributes
> they believe are necessary. If they trust that an IdP's assertion of
> identity covers the attributes they believe are required them they can
> accept the assertion. If it doesn't then that have to implement additiona=
l
> mechanisms to offset the residual risk.
>
> With respect to vectors of trust, I am interested in exploring what they
> are and how they can be applied.
>
> Ken
>
> On Thursday, October 9, 2014,  swilson@lockstep.com.au>> wrote:
>
>
>
> First, to introduce myself, I am an identity and privacy researcher,
> analyst and consultant.  I've been involved in this since 1995, when I cu=
t
> my teeth in PKI and smartcards (with the early companies that became
> Baltimore Technologies). Since then I've worked on identity management
> frameworks, regulations and standards.
>
>
>
> I subscribe to the old Italian proverb: "it's nice to trust but better no=
t
> to".  Words matter and I wonder if we shouldn't be using the word trust s=
o
> much.
>
>
>
> More pragmatically, I note the very strong "Attributes" push of the past
> 18 months.  Andrew Nash, Anil John, myself and others have written about
> this.  The FIDO Alliance is all about authentication and attributes, and
> they purposefully leave "identity" as a matter for others to work out
> further up the stack. The OID Foundation is promoting an Attributes
> Exchange Network "AXN" architecture.  New entrants like id.me
> (an NSTIC pilot participant) talk about attributes and avoid "identity".
>
>
>
> I mention all of this as a prelude to suggest that "vector of trust" is
> synonymous with "attribute". I wonder if it would be clearer to use plain
> and current language rather than carry forward the fuzzy and I think over=
ly
> ambitious idea of "trust"?
>
>
>
> Finally, I'd like to throw in my abiding concern that LOAs have foundered
> simply because it's difficult to pigeonhole risk. One party's idea of
> "medium" risk for instance will rarely map precisely to another's. I thin=
k
> people have been misled into thinking that an "LOA 3" identity should be =
be
> able to be used on its face (i.e. will "interoperate") at any "LOA 3" RP.
> Risk management is not so simple.
>
>
>
> The LOA paradigm borrows from Risk Management standards like ISO 31000
> which organisations use to plot their own risks internally typically on a
> five scale (eg Negligible / Low / Medium / High / Grave). But risk
> management standards require that each organisation calibrates risk in it=
s
> own business context and according to its own risk appetite. The risk of =
a
> firewall breach for example at a startup social media company will be
> assessed differently by a big listed healthcare company. So organisation =
A
> can say the risk of event X is Low but B can say the risk of the same eve=
nt
> is Medium.  As a result, LOAs do not inter-operate. They are based on
> standards meant for intra-organisation risk management, not
> inter-organisation communication of risk assessments.
>
>
>
> So far with VoT we are adding more dimensions to the RPs' generic risk
> management decision making, and that's great.  But we are still
> pigeonholing the dimensions.
>
>
>
> I'm afraid the reality is that risk management will always be done
> locally.  And so it should be.  When an RP is making the decision to acce=
pt
> or reject a given subject, they will evaluate a range of attributes or
> signals.  The set of attributes that matters varies from one RP to the
> next.  I think it's a great idea indeed to create guidance for evaluating
> attributes, and to coach RPs to look at all sorts of dimensions.  I just
> don't think it helps anyone to pigeonhole the risk ratings, because acros=
s
> organisations, arguments about the boundaries between LOA 1/2/3/4 (that i=
s,
> policy mapping) will undo any efficiencies gained from the categorization=
.
>
>
>
> Cheers,
>
>
>
> Steve.
>
>
>
>
>
> Stephen Wilson
> Managing Director
> Lockstep Group
> http://lockstep.com.au
> Lockstep Consulting provides independent specialist advice and analysis
> on digital identity and privacy. Lockstep Technologies develops unique
> new smart ID solutions that enhance privacy and prevent identity theft.
>
>
>
>
>
>
>
>
> _______________________________________________
> vot mailing list
> vot@ietf.org
> https://www.ietf.org/mailman/listinfo/vot
>

--089e0160a3be89ebb505051d515a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


It may make sense to look at LOAs as something that i=
s "coarse-grained" and a starting point.=C2=A0

We all think it is not enough, but in the absence of the Borg showin=
g up to enforce a collective hive-mind across organizational boundaries, we=
 can live with it and use it as a starting point for the discussion "W=
hat more do we need in order to let this person in the door?"

And that is where RP implemented compensating controls can=
 play a part. The challenge is that folks seem to conflate "things nee=
ded to ensure confidence in an identity" with "things needed to m=
itigate risk in the transaction" and who is (CSP or RP) responsible fo=
r what.

Regards,

- Anil

:- Anil John
<=
div dir=3D"ltr">
:- Making Digital Services Secure and Trustworthy




On Fri,=
 Oct 10, 2014 at 11:02 PM,  <swilson@lockstep.com.au> =
wrote:


We are all agreed of course that RPs need to understand their risks, determ=
ine what's needed from any external process of identification or attrib=
ute attestation, communicate those needs to candidate APs, and from there, =
contract an acceptable provider.



My question is whether or not a pigeonholed LOA helps at any point in this =
process.



The devil is in the detail.=C2=A0 To my mind, LOA is an intermediate step t=
hat takes a detailed risk analysis, squeezes it into a bin (losing lots of =
information as a result), which is then used to shortlist candidate provide=
rs, before going into detailed due diligence where all those details need t=
o be put back on the table.



I think we all know by now of cases where RPs have looked at candidate IdPs=
 at a given LOA, and have come up with the request of "LOA two and a h=
alf" (this was mentioned at CIS 2014 more than once, and I have seen i=
t first hand in the UK IDAP).



Clearly what's going on here is an RP's idea of say "LOA 2&quo=
t; differs from a given IdP's idea of LOA 2.=C2=A0 Moreover, the idea o=
f LOA 2 must differ from one IdP to another IdP.=C2=A0 When people ask for =
"LOA 2.5" what they're asking for is a customised identificat=
ion.=C2=A0 If LOA 2 isn't what it seems, then there cannot possibly be =
any such thing as a *standardised* LOA 2.5.=C2=A0 All we will get is fresh =
calls for "LOA 2.75 please".



If RPs need to do detailed analysis of authentication needs, and get detail=
ed verification of the actual ID proofing done by IdPs and APs, then I just=
 don't see any point attaching the LOA label along the way.=C2=A0 It=
9;s misleading.



Cheers,



Steve.



Stephen Wilson

Lockstep

http://lockstep.com.au=


Lockstep Consulting provides independent specialist advice and analysis

on digital identity and privacy.=C2=A0 Lockstep Technologies develops uniqu=
e

new smart ID solutions that enhance privacy and prevent identity theft.







-----Original Message-----

From: "Bouma, Tim" <Tim.Bouma@tbs-sct.gc.ca>

Sent: Saturday, 11 October, 2014 1:51am

To: "Ken Dagg" <kendag=
gtbs@gmail.com>, "sw=
ilson@lockstep.com.au" <swilson@lockstep.com.au>

Cc: "vot@ietf.org" <vot@ietf.org>

Subject: RE: [VoT] Foundational questions of principle



I agree with Ken,



When we developed levels of assurance (here in Canada) we did several thing=
s:



=C2=B7=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0We defined them as levels of confid=
ence required (Levels 1 through 4)

=C2=B7=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0We mapped these levels of confidenc=
e to a range of degree of impacts.

=C2=B7=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0We then specified separately identi=
ty assurance levels and credential assurance levels (and focused on credent=
ial first)

=C2=B7=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0We also factored out likelihood in =
the assurance level assessment process. That made the assessments much less=
 subjective.



At the end of the day, as Ken states,=C2=A0 it=E2=80=99s the job the RP to =
understand their risk (along with likelihood) and to communicate a standard=
ized requirement back to a provider (AP)

The AP is=C2=A0 accountable for providing a very prescribed component that =
fits into a larger system and a risk environment that they might not have a=
 full view into. The RP may put in provisions to share the risk with the AP=
, or not but that entirely depends on the arrangement, but at least the RP =
and AP understand what=E2=80=99s on the table as a starting point.



In Canada, we did that with the credential first, and are now figuring out =
identity (much harder).



I also agree that =E2=80=98identity=E2=80=99 is just a set of attributes =
=E2=80=93and=C2=A0 these identity attributes can vary between organizations=
 or jurisdictions,



As for the term =E2=80=98vectors=E2=80=99, I get the idea, but I think the =
community will think it=E2=80=99s too technical or esoteric. I like to thin=
k of a =E2=80=98digital identity=E2=80=99 (or whatever you call it), when i=
t shows up at your digital front door, it is the product of a very long, co=
mplex supply chain, fraught with many risks and compromises. I may have con=
fidence in certain pieces of, but other I might not trust at all.





Tim





From: vot [mailto:vot-bounces@ietf.=
org] On Behalf Of Ken Dagg

Sent: October-09-14 9:42 PM

To: swilson@lockstep.com.au<=
br>
Cc: vot@ietf.org

Subject: Re: [VoT] Foundational questions of principle



Steve,



As we have communicated in the past, I am a strong believer the an LOA desi=
gnation is an indication of the processes/mechanisms that an IdP has undert=
aken. In other words, it is a communication tool. The choice is the RPs. Th=
at is, an assertion at a specific LOA by an IdP/CSP/AP is one of the mechan=
isms a RP should use to offset the authentication risk it has identified fo=
r the service it wants to deliver. In other words, it is the risk of the RP=
 that is paramount not the claims of an identity/credential/attribute/token=
 provider.



Like you, I am a strong believer that the determination of whether or not a=
n identity is good enough is the responsibility of the RP. In my experience=
, they make that determination based upon a set of attributes they believe =
are necessary. If they trust that an IdP's assertion of identity covers=
 the attributes they believe are required them they can accept the assertio=
n. If it doesn't then that have to implement additional mechanisms to o=
ffset the residual risk.



With respect to vectors of trust, I am interested in exploring what they ar=
e and how they can be applied.



Ken



On Thursday, October 9, 2014, <swilson@lockstep.com.au<mailto:swilson@lockstep.com.au>> wrote:







First, to introduce myself, I am an identity and privacy researcher, analys=
t and consultant.=C2=A0 I've been involved in this since 1995, when I c=
ut my teeth in PKI and smartcards (with the early companies that became Bal=
timore Technologies). Since then I've worked on identity management fra=
meworks, regulations and standards.







I subscribe to the old Italian proverb: "it's nice to trust but be=
tter not to".=C2=A0 Words matter and I wonder if we shouldn't be u=
sing the word trust so much.







More pragmatically, I note the very strong "Attributes" push of t=
he past 18 months.=C2=A0 Andrew Nash, Anil John, myself and others have wri=
tten about this.=C2=A0 The FIDO Alliance is all about authentication and at=
tributes, and they purposefully leave "identity" as a matter for =
others to work out further up the stack. The OID Foundation is promoting an=
 Attributes Exchange Network "AXN" architecture.=C2=A0 New entran=
ts like id.me<http://id.me> (an NSTIC pilot partic=
ipant) talk about attributes and avoid "identity".







I mention all of this as a prelude to suggest that "vector of trust&qu=
ot; is synonymous with "attribute". I wonder if it would be clear=
er to use plain and current language rather than carry forward the fuzzy an=
d I think overly ambitious idea of "trust"?







Finally, I'd like to throw in my abiding concern that LOAs have founder=
ed simply because it's difficult to pigeonhole risk. One party's id=
ea of "medium" risk for instance will rarely map precisely to ano=
ther's. I think people have been misled into thinking that an "LOA=
 3" identity should be be able to be used on its face (i.e. will "=
;interoperate") at any "LOA 3" RP. Risk management is not so=
 simple.







The LOA paradigm borrows from Risk Management standards like ISO 31000 whic=
h organisations use to plot their own risks internally typically on a five =
scale (eg Negligible / Low / Medium / High / Grave). But risk management st=
andards require that each organisation calibrates risk in its own business =
context and according to its own risk appetite. The risk of a firewall brea=
ch for example at a startup social media company will be assessed different=
ly by a big listed healthcare company. So organisation A can say the risk o=
f event X is Low but B can say the risk of the same event is Medium.=C2=A0 =
As a result, LOAs do not inter-operate. They are based on standards meant f=
or intra-organisation risk management, not inter-organisation communication=
 of risk assessments.







So far with VoT we are adding more dimensions to the RPs' generic risk =
management decision making, and that's great.=C2=A0 But we are still pi=
geonholing the dimensions.







I'm afraid the reality is that risk management will always be done loca=
lly.=C2=A0 And so it should be.=C2=A0 When an RP is making the decision to =
accept or reject a given subject, they will evaluate a range of attributes =
or signals.=C2=A0 The set of attributes that matters varies from one RP to =
the next.=C2=A0 I think it's a great idea indeed to create guidance for=
 evaluating attributes, and to coach RPs to look at all sorts of dimensions=
.=C2=A0 I just don't think it helps anyone to pigeonhole the risk ratin=
gs, because across organisations, arguments about the boundaries between LO=
A 1/2/3/4 (that is, policy mapping) will undo any efficiencies gained from =
the categorization.







Cheers,







Steve.











Stephen Wilson

Managing Director

Lockstep Group

http://lockstep.com.au=


Lockstep Consulting provides independent specialist advice and analysis

on digital identity and privacy. Lockstep Technologies develops unique

new smart ID solutions that enhance privacy and prevent identity theft.

















_______________________________________________

vot mailing list

vot@ietf.org

htt=
ps://www.ietf.org/mailman/listinfo/vot





--089e0160a3be89ebb505051d515a--


From nobody Sun Oct 12 12:18:31 2014
Return-Path: 
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC9561A854D for ; Sun, 12 Oct 2014 12:18:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.402
X-Spam-Level: *
X-Spam-Status: No, score=1.402 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, MSGID_FROM_MTA_HEADER=0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id buKKqZ4381tG for ; Sun, 12 Oct 2014 12:18:23 -0700 (PDT)
Received: from smtp.safecom.net.nz (smtp.safecom.net.nz [125.236.41.139]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B084F1A8547 for ; Sun, 12 Oct 2014 12:18:22 -0700 (PDT)
Received: from s111-0006-lnv01 (Not Verified[127.0.0.1]) by smtp.safecom.net.nz (using TLS: SSLv23) id ; Mon, 13 Oct 2014 08:14:37 +1300
Message-ID: <147EE18440E5AF44834B220ED35BA530D32F0A2E@WLGPRDMBX01.dia.govt.nz>
MIME-Version: 1.0
X-MessageIsInfected: false
Received: from 161-65-142-21.ip.fx.net.nz (EHLO WLGPRDMM01.dia.govt.nz) ([127.0.0.1]) by s111-0006-lnv01 (JAMES SMTP Server ) with ESMTP ID 1234762122 for ; Mon, 13 Oct 2014 08:18:18 +1300 (NZDT)
Received: from WLGPRDCAS02.dia.govt.nz (Not Verified[127.0.0.1]) by WLGPRDMM01.dia.govt.nz with MailMarshal (v7, 1, 1, 5205) (using TLS: SSLv23) id ; Mon, 13 Oct 2014 08:16:47 +1300
Received: from WLGPRDMBX01.dia.govt.nz ([fe80::13e:8e96:252b:e0d1]) by WLGPRDCAS02.dia.govt.nz ([127.0.0.1]) with mapi id 14.03.0146.000; Mon, 13 Oct 2014 08:18:18 +1300
From: Colin Wallis 
To: "vot@ietf.org" 
Thread-Topic: [VoT] Foundational questions of principle
Thread-Index: AQHP4/5Iig05S+YmNEKjLvPcZpUGz5wo0ccAgADcpgCAACvnAIAC9xoQ
Date: Sun, 12 Oct 2014 19:16:46 +0000
References: <1412885935.58929166@apps.rackspace.com>  <20141010145142.51DBE1A90E3@ietfa.amsl.com> <6A0CFC85-F8F5-43F5-B02F-09720E7164F4@mitre.org>
In-Reply-To: <6A0CFC85-F8F5-43F5-B02F-09720E7164F4@mitre.org>
Accept-Language: en-US, en-NZ
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.29.0.162]
Content-Type: multipart/alternative; boundary="_000_147EE18440E5AF44834B220ED35BA530D32F0A2EWLGPRDMBX01diag_"
X-sdp.mm2006: true
Archived-At: http://mailarchive.ietf.org/arch/msg/vot/fOn_PLqjVU9KvlYzJj5IE4T0UU4
Subject: Re: [VoT] Foundational questions of principle
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Vectors of Trust discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 12 Oct 2014 19:18:27 -0000

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

UHV0dGluZyB0aGlzIHNwbGl0LCBiYWNrIGludG8gb25lIHRocmVhZC4uDQrigKYgIGFuZCBwbGVh
ZGluZyB0byBmb2xrcyB0byBmb2N1cyBiYWNrIG9uIHRoZSB2ZWN0b3JzLCBvciBhc3BlY3RzLCBv
ciDigJh0aGluZ3PigJkgLSB3aGF0ZXZlciB3ZSBjYWxsIHRoZW0g4oCTIHRoYXQgdGhlIFJQIGhh
cyBhbiBpbnRlcmVzdCBpbi4NCkp1c3RpbiBpcyB2YWxpYW50bHkgdHJ5aW5nIHRvIHJlLXN0YXRl
IHRoZSBwdXJwb3NlIG9mIGhpcyBvcGVuaW5nIOKAmHZlY3RvcnPigJkgc3RyYXdtYW4g4oCTIGFs
d2F5cyB1c2VmdWwgdG8gcmVmcmVzaCBvbmXigJlzIG1lbW9yeSBieSBnb2luZyBiYWNrIHRvIGxv
b2sgYXQgdGhlbS4uLg0KSGlzIHN0YXJ0aW5nIGxpc3Qgb2YgdmVjdG9ycyB3YXM6DQpJZGVudGl0
eSBQcm9vZmluZw0KQ3JlZGVudGlhbCBTdHJlbmd0aA0KQXNzZXJ0aW9uIFByZXNlbnRhdGlvbg0K
T3BlcmF0aW9uYWwgTWFuYWdlbWVudA0KDQpJZiB0aGUgZGlzY3Vzc2lvbiBvbiBMb0FzIG9mZmVy
cyBhbnkgdmFsdWUgaGVyZSwgaXQgd291bGQgYmUgdG8gYWRkIHNvbWUgZmluZXIgZ3JhaW5lZCBh
ZGRpdGlvbiB0byB0aGUgYWJvdmUgKGZhaXJseSBjb2Fyc2UtZ3JhaW5lZCkgbGlzdC4NCg0KVGhl
cmXigJlzIGFscmVhZHkgYW4gYWNrbm93bGVkZ21lbnQgdGhhdCBPcGVyYXRpb25hbCBNYW5hZ2Vt
ZW50IG1heSBiZSBjb21wb3NlZCBvZiBhIHJhbmdlIG9mIGNvbmNlcm5zIOKAkyBhIG1peCBvZiBj
b250ZXh0IGRlcGVuZGVudCwgdGVtcG9yYWwgYW5kIHN0YXRpYyAobW9yZSB2ZWN0b3JzPykg4oCT
IHRoYXQgaW5mbHVlbmNlIHRoZSBSUOKAmXMgZGVjaXNpb24gdG8gYWNjZXB0IG9yIG90aGVyd2lz
ZSwgYW4gYXV0aGVudGljYXRlZCBpZGVudGl0eS4NCg0KSWYgd2UgZ290IHRvIGEgcG9pbnQgd2hl
cmUgd2UgY291bGQgYWdyZWUgb24gd2hhdCB0aGVzZSB2ZWN0b3JzIGFyZSwgdGhlbiB3ZSBjYW4g
aGF2ZSB0aGUgKHNlcGFyYXRlKSBkZWJhdGUgYWJvdXQgd2hldGhlciBjb21iaW5pbmcgdGhlbS9k
ZWxpbmVhdGluZyB0aGVtIGluIHNvbWUgd2F5IGlzIHVzZWZ1bC9oZWxwZnVsLCBvciBub3QuDQoN
CkNoZWVycw0KQ29saW4NCg0KRnJvbTogdm90IFttYWlsdG86dm90LWJvdW5jZXNAaWV0Zi5vcmdd
IE9uIEJlaGFsZiBPZiBSaWNoZXIsIEp1c3RpbiBQLg0KU2VudDogU2F0dXJkYXksIDExIE9jdG9i
ZXIgMjAxNCA2OjI5IGEubS4NClRvOiBCb3VtYSwgVGltDQpDYzogS2VuIERhZ2c7IHZvdEBpZXRm
Lm9yZzsgc3dpbHNvbkBsb2Nrc3RlcC5jb20uYXUNClN1YmplY3Q6IFJlOiBbVm9UXSBGb3VuZGF0
aW9uYWwgcXVlc3Rpb25zIG9mIHByaW5jaXBsZQ0KDQpXaGF0IHdlJ3JlIHRyeWluZyB0byBkbyB3
aXRoIHRoZSAiVmVjdG9ycyIgYXBwcm9hY2ggaGVyZSBpcyB0byBzdHJpa2UgYSBiYWxhbmNlIGJl
dHdlZW4gdGhlIG92ZXJseS1zaW1wbGlzdGljICJzaW5nbGUgc2V0IG9mIGxpbmVhciBsZXZlbHMi
IGFwcHJvYWNoIHRoYXQgTG9BIGdpdmVzIHVzICh0aGF0IG5vYm9keSBvbiB0aGlzIGxpc3QgbGlr
ZXMgYnV0IGFsbCBhZ3JlZSB0aGF0IGFwcHMgY2FuIGFjdHVhbGx5IGRvIHNvbWUgbGV2ZWwgb2Yg
cHJvY2Vzc2luZyB3aXRoIGl0KSBhbmQgdGhlIG92ZXJseS1jb21wbGV4ICJ2ZXJ5IGxvbmcgY29t
cGxleCBzZXQgb2YgYXR0cmlidXRlcyIgYXBwcm9hY2ggdGhhdCBUaW0sIFNjb3R0LCBhbmQgb3Ro
ZXJzIGhhdmUgYnJvdWdodCB1cCAodGhhdCBzZWVtcyBtb3JlIGV4cHJlc3NpdmUgYW5kIGlkZWFs
IGJ1dCBubyBhcHAgaXMgZXZlciBnb2luZyB0byBtYWtlIHNlbnNlIG9mLCBvciBldmVuIHRyeSB0
bykuIEkgdGhpbmsgaXQncyBzYWZlIHRvIHNheSB0aGF0IG5laXRoZXIgZXh0cmVtZSB3b3JrcyBh
bmQgdGhhdCBhIHJpZ2h0IGFuc3dlciBwcm9iYWJseSBsaWVzIGluIHRoZSBtaWRkbGUuDQoNClNv
IHRoYXQncyB3aGF0IHRoaXMgc3RyYXdtYW4gaXMgLS0gaXQncyBzaW11bHRhbmVvdXNseSBsZXNz
IGNvbXBsZXggYW5kIG1vcmUgY29tcGxleCB0aGFuIHRoZSBhbHRlcm5hdGl2ZXMuIElzIGl0IHRo
ZSByaWdodCBjdXQ/IFByb2JhYmx5IG5vdCwgYnV0IGl0J3MgYXQgbGVhc3QgYSBjdXR0aW5nIHBv
aW50IHRoYXQgd2UgY2FuIHB1c2ggdG8gZWl0aGVyIHNpZGUuIFdoYXQgSSB0aGluayB3ZSBuZWVk
IHRvIGR1dGlmdWxseSBhdm9pZCBpcyBwdXNoaW5nIGl0IGhhcmQgdG8gZWl0aGVyIGVuZC4gSSBy
ZWFsbHkgbGlrZSB0aGUgbm90aW9uIHRoYXQgZXZlbiBpZiB0aGUgY29tYmluYXRpb25zIG9mIHRo
ZSB2ZWN0b3IgdmFsdWVzIGFyZW4ndCBkaXJlY3RseSBjb21wYXRpYmxlIChhcyBTdGV2ZSBzYXlz
KSwgdGhlbiB0aGUgYnVpbGRpbmcgYmxvY2tzIHdvdWxkIGF0IGxlYXN0IGJlIGNvbXBhcmFibGUs
IGdpdmluZyBhIGhvcGUgb2YgZGVmaW5pbmcgYSBwb2xpY3kgdG8gdHJhbnNsYXRlIGJldHdlZW4g
dGhlbSB3aGVuIG5lZWRlZC4NCg0KQWxzbywgSSB3YW50ZWQgdG8ga2V5IGludG8gdGhlIGZhY3Qg
dGhhdCB0aGVyZSBhcmUgc2V2ZXJhbCBpbmRlcGVuZGVudCBhbmQgb3J0aG9nb25hbCBjb21wb25l
bnRzIGhlcmUuIE1heWJlIGl0J3Mgbm90IGEgc2V0IG9mIGxldmVscyB0aGF0IGFyZSB0aWVkIHRv
Z2V0aGVyLCBidXQgSSB0aGluayBpdCBpcyBpbiBzb21ld2F5IGEgc2V0IG9mIGluZGVwZW5kZW50
ICp0aGluZ3MqIHRoYXQgYXJlIHRpZWQgdG9nZXRoZXIuDQoNCiAtLSBKdXN0aW4NCuKApuKApuKA
puKApuKApuKApuKApuKApuKApuKApuKApuKApuKApuKApuKApuKApuKApuKApuKApuKApuKApuKA
pi4NCg0KSXQgbWF5IG1ha2Ugc2Vuc2UgdG8gbG9vayBhdCBMT0FzIGFzIHNvbWV0aGluZyB0aGF0
IGlzICJjb2Fyc2UtZ3JhaW5lZCIgYW5kIGEgc3RhcnRpbmcgcG9pbnQuDQoNCldlIGFsbCB0aGlu
ayBpdCBpcyBub3QgZW5vdWdoLCBidXQgaW4gdGhlIGFic2VuY2Ugb2YgdGhlIEJvcmcgc2hvd2lu
ZyB1cCB0byBlbmZvcmNlIGEgY29sbGVjdGl2ZSBoaXZlLW1pbmQgYWNyb3NzIG9yZ2FuaXphdGlv
bmFsIGJvdW5kYXJpZXMsIHdlIGNhbiBsaXZlIHdpdGggaXQgYW5kIHVzZSBpdCBhcyBhIHN0YXJ0
aW5nIHBvaW50IGZvciB0aGUgZGlzY3Vzc2lvbiAiV2hhdCBtb3JlIGRvIHdlIG5lZWQgaW4gb3Jk
ZXIgdG8gbGV0IHRoaXMgcGVyc29uIGluIHRoZSBkb29yPyINCg0KQW5kIHRoYXQgaXMgd2hlcmUg
UlAgaW1wbGVtZW50ZWQgY29tcGVuc2F0aW5nIGNvbnRyb2xzIGNhbiBwbGF5IGEgcGFydC4gVGhl
IGNoYWxsZW5nZSBpcyB0aGF0IGZvbGtzIHNlZW0gdG8gY29uZmxhdGUgInRoaW5ncyBuZWVkZWQg
dG8gZW5zdXJlIGNvbmZpZGVuY2UgaW4gYW4gaWRlbnRpdHkiIHdpdGggInRoaW5ncyBuZWVkZWQg
dG8gbWl0aWdhdGUgcmlzayBpbiB0aGUgdHJhbnNhY3Rpb24iIGFuZCB3aG8gaXMgKENTUCBvciBS
UCkgcmVzcG9uc2libGUgZm9yIHdoYXQuDQoNClJlZ2FyZHMsDQoNCi0gQW5pbA0KDQo6LSBBbmls
IEpvaG4NCjotIE1ha2luZyBEaWdpdGFsIFNlcnZpY2VzIFNlY3VyZSBhbmQgVHJ1c3R3b3J0aHkN
CjotIGh0dHBzOi8vYmxvZy5hbmlsam9obi5jb20NCg0KDQpPbiBGcmksIE9jdCAxMCwgMjAxNCBh
dCAxMTowMiBQTSwgPHN3aWxzb25AbG9ja3N0ZXAuY29tLmF1PG1haWx0bzpzd2lsc29uQGxvY2tz
dGVwLmNvbS5hdT4+IHdyb3RlOg0KDQpXZSBhcmUgYWxsIGFncmVlZCBvZiBjb3Vyc2UgdGhhdCBS
UHMgbmVlZCB0byB1bmRlcnN0YW5kIHRoZWlyIHJpc2tzLCBkZXRlcm1pbmUgd2hhdCdzIG5lZWRl
ZCBmcm9tIGFueSBleHRlcm5hbCBwcm9jZXNzIG9mIGlkZW50aWZpY2F0aW9uIG9yIGF0dHJpYnV0
ZSBhdHRlc3RhdGlvbiwgY29tbXVuaWNhdGUgdGhvc2UgbmVlZHMgdG8gY2FuZGlkYXRlIEFQcywg
YW5kIGZyb20gdGhlcmUsIGNvbnRyYWN0IGFuIGFjY2VwdGFibGUgcHJvdmlkZXIuDQoNCk15IHF1
ZXN0aW9uIGlzIHdoZXRoZXIgb3Igbm90IGEgcGlnZW9uaG9sZWQgTE9BIGhlbHBzIGF0IGFueSBw
b2ludCBpbiB0aGlzIHByb2Nlc3MuDQoNClRoZSBkZXZpbCBpcyBpbiB0aGUgZGV0YWlsLiAgVG8g
bXkgbWluZCwgTE9BIGlzIGFuIGludGVybWVkaWF0ZSBzdGVwIHRoYXQgdGFrZXMgYSBkZXRhaWxl
ZCByaXNrIGFuYWx5c2lzLCBzcXVlZXplcyBpdCBpbnRvIGEgYmluIChsb3NpbmcgbG90cyBvZiBp
bmZvcm1hdGlvbiBhcyBhIHJlc3VsdCksIHdoaWNoIGlzIHRoZW4gdXNlZCB0byBzaG9ydGxpc3Qg
Y2FuZGlkYXRlIHByb3ZpZGVycywgYmVmb3JlIGdvaW5nIGludG8gZGV0YWlsZWQgZHVlIGRpbGln
ZW5jZSB3aGVyZSBhbGwgdGhvc2UgZGV0YWlscyBuZWVkIHRvIGJlIHB1dCBiYWNrIG9uIHRoZSB0
YWJsZS4NCg0KSSB0aGluayB3ZSBhbGwga25vdyBieSBub3cgb2YgY2FzZXMgd2hlcmUgUlBzIGhh
dmUgbG9va2VkIGF0IGNhbmRpZGF0ZSBJZFBzIGF0IGEgZ2l2ZW4gTE9BLCBhbmQgaGF2ZSBjb21l
IHVwIHdpdGggdGhlIHJlcXVlc3Qgb2YgIkxPQSB0d28gYW5kIGEgaGFsZiIgKHRoaXMgd2FzIG1l
bnRpb25lZCBhdCBDSVMgMjAxNCBtb3JlIHRoYW4gb25jZSwgYW5kIEkgaGF2ZSBzZWVuIGl0IGZp
cnN0IGhhbmQgaW4gdGhlIFVLIElEQVApLg0KDQpDbGVhcmx5IHdoYXQncyBnb2luZyBvbiBoZXJl
IGlzIGFuIFJQJ3MgaWRlYSBvZiBzYXkgIkxPQSAyIiBkaWZmZXJzIGZyb20gYSBnaXZlbiBJZFAn
cyBpZGVhIG9mIExPQSAyLiAgTW9yZW92ZXIsIHRoZSBpZGVhIG9mIExPQSAyIG11c3QgZGlmZmVy
IGZyb20gb25lIElkUCB0byBhbm90aGVyIElkUC4gIFdoZW4gcGVvcGxlIGFzayBmb3IgIkxPQSAy
LjUiIHdoYXQgdGhleSdyZSBhc2tpbmcgZm9yIGlzIGEgY3VzdG9taXNlZCBpZGVudGlmaWNhdGlv
bi4gIElmIExPQSAyIGlzbid0IHdoYXQgaXQgc2VlbXMsIHRoZW4gdGhlcmUgY2Fubm90IHBvc3Np
Ymx5IGJlIGFueSBzdWNoIHRoaW5nIGFzIGEgKnN0YW5kYXJkaXNlZCogTE9BIDIuNS4gIEFsbCB3
ZSB3aWxsIGdldCBpcyBmcmVzaCBjYWxscyBmb3IgIkxPQSAyLjc1IHBsZWFzZSIuDQoNCklmIFJQ
cyBuZWVkIHRvIGRvIGRldGFpbGVkIGFuYWx5c2lzIG9mIGF1dGhlbnRpY2F0aW9uIG5lZWRzLCBh
bmQgZ2V0IGRldGFpbGVkIHZlcmlmaWNhdGlvbiBvZiB0aGUgYWN0dWFsIElEIHByb29maW5nIGRv
bmUgYnkgSWRQcyBhbmQgQVBzLCB0aGVuIEkganVzdCBkb24ndCBzZWUgYW55IHBvaW50IGF0dGFj
aGluZyB0aGUgTE9BIGxhYmVsIGFsb25nIHRoZSB3YXkuICBJdCdzIG1pc2xlYWRpbmcuDQoNCkNo
ZWVycywNCg0KU3RldmUuDQoNClN0ZXBoZW4gV2lsc29uDQpMb2Nrc3RlcA0KaHR0cDovL2xvY2tz
dGVwLmNvbS5hdQ0KTG9ja3N0ZXAgQ29uc3VsdGluZyBwcm92aWRlcyBpbmRlcGVuZGVudCBzcGVj
aWFsaXN0IGFkdmljZSBhbmQgYW5hbHlzaXMNCm9uIGRpZ2l0YWwgaWRlbnRpdHkgYW5kIHByaXZh
Y3kuICBMb2Nrc3RlcCBUZWNobm9sb2dpZXMgZGV2ZWxvcHMgdW5pcXVlDQpuZXcgc21hcnQgSUQg
c29sdXRpb25zIHRoYXQgZW5oYW5jZSBwcml2YWN5IGFuZCBwcmV2ZW50IGlkZW50aXR5IHRoZWZ0
Lg0KDQoNCk9uIE9jdCAxMCwgMjAxNCwgYXQgMTA6NTEgQU0sIEJvdW1hLCBUaW0gPFRpbS5Cb3Vt
YUB0YnMtc2N0LmdjLmNhPG1haWx0bzpUaW0uQm91bWFAdGJzLXNjdC5nYy5jYT4+IHdyb3RlOg0K
DQoNCkkgYWdyZWUgd2l0aCBLZW4sDQoNCldoZW4gd2UgZGV2ZWxvcGVkIGxldmVscyBvZiBhc3N1
cmFuY2UgKGhlcmUgaW4gQ2FuYWRhKSB3ZSBkaWQgc2V2ZXJhbCB0aGluZ3M6DQoNCg0KwrcgICAg
ICAgICBXZSBkZWZpbmVkIHRoZW0gYXMgbGV2ZWxzIG9mIGNvbmZpZGVuY2UgcmVxdWlyZWQgKExl
dmVscyAxIHRocm91Z2ggNCkNCg0KwrcgICAgICAgICBXZSBtYXBwZWQgdGhlc2UgbGV2ZWxzIG9m
IGNvbmZpZGVuY2UgdG8gYSByYW5nZSBvZiBkZWdyZWUgb2YgaW1wYWN0cy4NCg0KwrcgICAgICAg
ICBXZSB0aGVuIHNwZWNpZmllZCBzZXBhcmF0ZWx5IGlkZW50aXR5IGFzc3VyYW5jZSBsZXZlbHMg
YW5kIGNyZWRlbnRpYWwgYXNzdXJhbmNlIGxldmVscyAoYW5kIGZvY3VzZWQgb24gY3JlZGVudGlh
bCBmaXJzdCkNCg0KwrcgICAgICAgICBXZSBhbHNvIGZhY3RvcmVkIG91dCBsaWtlbGlob29kIGlu
IHRoZSBhc3N1cmFuY2UgbGV2ZWwgYXNzZXNzbWVudCBwcm9jZXNzLiBUaGF0IG1hZGUgdGhlIGFz
c2Vzc21lbnRzIG11Y2ggbGVzcyBzdWJqZWN0aXZlLg0KDQpBdCB0aGUgZW5kIG9mIHRoZSBkYXks
IGFzIEtlbiBzdGF0ZXMsICBpdOKAmXMgdGhlIGpvYiB0aGUgUlAgdG8gdW5kZXJzdGFuZCB0aGVp
ciByaXNrIChhbG9uZyB3aXRoIGxpa2VsaWhvb2QpIGFuZCB0byBjb21tdW5pY2F0ZSBhIHN0YW5k
YXJkaXplZCByZXF1aXJlbWVudCBiYWNrIHRvIGEgcHJvdmlkZXIgKEFQKQ0KVGhlIEFQIGlzICBh
Y2NvdW50YWJsZSBmb3IgcHJvdmlkaW5nIGEgdmVyeSBwcmVzY3JpYmVkIGNvbXBvbmVudCB0aGF0
IGZpdHMgaW50byBhIGxhcmdlciBzeXN0ZW0gYW5kIGEgcmlzayBlbnZpcm9ubWVudCB0aGF0IHRo
ZXkgbWlnaHQgbm90IGhhdmUgYSBmdWxsIHZpZXcgaW50by4gVGhlIFJQIG1heSBwdXQgaW4gcHJv
dmlzaW9ucyB0byBzaGFyZSB0aGUgcmlzayB3aXRoIHRoZSBBUCwgb3Igbm90IGJ1dCB0aGF0IGVu
dGlyZWx5IGRlcGVuZHMgb24gdGhlIGFycmFuZ2VtZW50LCBidXQgYXQgbGVhc3QgdGhlIFJQIGFu
ZCBBUCB1bmRlcnN0YW5kIHdoYXTigJlzIG9uIHRoZSB0YWJsZSBhcyBhIHN0YXJ0aW5nIHBvaW50
Lg0KDQpJbiBDYW5hZGEsIHdlIGRpZCB0aGF0IHdpdGggdGhlIGNyZWRlbnRpYWwgZmlyc3QsIGFu
ZCBhcmUgbm93IGZpZ3VyaW5nIG91dCBpZGVudGl0eSAobXVjaCBoYXJkZXIpLg0KDQpJIGFsc28g
YWdyZWUgdGhhdCDigJhpZGVudGl0eeKAmSBpcyBqdXN0IGEgc2V0IG9mIGF0dHJpYnV0ZXMg4oCT
YW5kICB0aGVzZSBpZGVudGl0eSBhdHRyaWJ1dGVzIGNhbiB2YXJ5IGJldHdlZW4gb3JnYW5pemF0
aW9ucyBvciBqdXJpc2RpY3Rpb25zLA0KDQpBcyBmb3IgdGhlIHRlcm0g4oCYdmVjdG9yc+KAmSwg
SSBnZXQgdGhlIGlkZWEsIGJ1dCBJIHRoaW5rIHRoZSBjb21tdW5pdHkgd2lsbCB0aGluayBpdOKA
mXMgdG9vIHRlY2huaWNhbCBvciBlc290ZXJpYy4gSSBsaWtlIHRvIHRoaW5rIG9mIGEg4oCYZGln
aXRhbCBpZGVudGl0eeKAmSAob3Igd2hhdGV2ZXIgeW91IGNhbGwgaXQpLCB3aGVuIGl0IHNob3dz
IHVwIGF0IHlvdXIgZGlnaXRhbCBmcm9udCBkb29yLCBpdCBpcyB0aGUgcHJvZHVjdCBvZiBhIHZl
cnkgbG9uZywgY29tcGxleCBzdXBwbHkgY2hhaW4sIGZyYXVnaHQgd2l0aCBtYW55IHJpc2tzIGFu
ZCBjb21wcm9taXNlcy4gSSBtYXkgaGF2ZSBjb25maWRlbmNlIGluIGNlcnRhaW4gcGllY2VzIG9m
LCBidXQgb3RoZXIgSSBtaWdodCBub3QgdHJ1c3QgYXQgYWxsLg0KDQoNClRpbQ0KDQoNCkZyb206
IHZvdCBbbWFpbHRvOnZvdC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgS2VuIERhZ2cN
ClNlbnQ6IE9jdG9iZXItMDktMTQgOTo0MiBQTQ0KVG86IHN3aWxzb25AbG9ja3N0ZXAuY29tLmF1
PG1haWx0bzpzd2lsc29uQGxvY2tzdGVwLmNvbS5hdT4NCkNjOiB2b3RAaWV0Zi5vcmc8bWFpbHRv
OnZvdEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbVm9UXSBGb3VuZGF0aW9uYWwgcXVlc3Rpb25z
IG9mIHByaW5jaXBsZQ0KDQpTdGV2ZSwNCg0KQXMgd2UgaGF2ZSBjb21tdW5pY2F0ZWQgaW4gdGhl
IHBhc3QsIEkgYW0gYSBzdHJvbmcgYmVsaWV2ZXIgdGhlIGFuIExPQSBkZXNpZ25hdGlvbiBpcyBh
biBpbmRpY2F0aW9uIG9mIHRoZSBwcm9jZXNzZXMvbWVjaGFuaXNtcyB0aGF0IGFuIElkUCBoYXMg
dW5kZXJ0YWtlbi4gSW4gb3RoZXIgd29yZHMsIGl0IGlzIGEgY29tbXVuaWNhdGlvbiB0b29sLiBU
aGUgY2hvaWNlIGlzIHRoZSBSUHMuIFRoYXQgaXMsIGFuIGFzc2VydGlvbiBhdCBhIHNwZWNpZmlj
IExPQSBieSBhbiBJZFAvQ1NQL0FQIGlzIG9uZSBvZiB0aGUgbWVjaGFuaXNtcyBhIFJQIHNob3Vs
ZCB1c2UgdG8gb2Zmc2V0IHRoZSBhdXRoZW50aWNhdGlvbiByaXNrIGl0IGhhcyBpZGVudGlmaWVk
IGZvciB0aGUgc2VydmljZSBpdCB3YW50cyB0byBkZWxpdmVyLiBJbiBvdGhlciB3b3JkcywgaXQg
aXMgdGhlIHJpc2sgb2YgdGhlIFJQIHRoYXQgaXMgcGFyYW1vdW50IG5vdCB0aGUgY2xhaW1zIG9m
IGFuIGlkZW50aXR5L2NyZWRlbnRpYWwvYXR0cmlidXRlL3Rva2VuIHByb3ZpZGVyLg0KDQpMaWtl
IHlvdSwgSSBhbSBhIHN0cm9uZyBiZWxpZXZlciB0aGF0IHRoZSBkZXRlcm1pbmF0aW9uIG9mIHdo
ZXRoZXIgb3Igbm90IGFuIGlkZW50aXR5IGlzIGdvb2QgZW5vdWdoIGlzIHRoZSByZXNwb25zaWJp
bGl0eSBvZiB0aGUgUlAuIEluIG15IGV4cGVyaWVuY2UsIHRoZXkgbWFrZSB0aGF0IGRldGVybWlu
YXRpb24gYmFzZWQgdXBvbiBhIHNldCBvZiBhdHRyaWJ1dGVzIHRoZXkgYmVsaWV2ZSBhcmUgbmVj
ZXNzYXJ5LiBJZiB0aGV5IHRydXN0IHRoYXQgYW4gSWRQJ3MgYXNzZXJ0aW9uIG9mIGlkZW50aXR5
IGNvdmVycyB0aGUgYXR0cmlidXRlcyB0aGV5IGJlbGlldmUgYXJlIHJlcXVpcmVkIHRoZW0gdGhl
eSBjYW4gYWNjZXB0IHRoZSBhc3NlcnRpb24uIElmIGl0IGRvZXNuJ3QgdGhlbiB0aGF0IGhhdmUg
dG8gaW1wbGVtZW50IGFkZGl0aW9uYWwgbWVjaGFuaXNtcyB0byBvZmZzZXQgdGhlIHJlc2lkdWFs
IHJpc2suDQoNCldpdGggcmVzcGVjdCB0byB2ZWN0b3JzIG9mIHRydXN0LCBJIGFtIGludGVyZXN0
ZWQgaW4gZXhwbG9yaW5nIHdoYXQgdGhleSBhcmUgYW5kIGhvdyB0aGV5IGNhbiBiZSBhcHBsaWVk
Lg0KDQpLZW4NCg0KT24gVGh1cnNkYXksIE9jdG9iZXIgOSwgMjAxNCwgPHN3aWxzb25AbG9ja3N0
ZXAuY29tLmF1PG1haWx0bzpzd2lsc29uQGxvY2tzdGVwLmNvbS5hdT4+IHdyb3RlOg0KDQpGaXJz
dCwgdG8gaW50cm9kdWNlIG15c2VsZiwgSSBhbSBhbiBpZGVudGl0eSBhbmQgcHJpdmFjeSByZXNl
YXJjaGVyLCBhbmFseXN0IGFuZCBjb25zdWx0YW50LiAgSSd2ZSBiZWVuIGludm9sdmVkIGluIHRo
aXMgc2luY2UgMTk5NSwgd2hlbiBJIGN1dCBteSB0ZWV0aCBpbiBQS0kgYW5kIHNtYXJ0Y2FyZHMg
KHdpdGggdGhlIGVhcmx5IGNvbXBhbmllcyB0aGF0IGJlY2FtZSBCYWx0aW1vcmUgVGVjaG5vbG9n
aWVzKS4gU2luY2UgdGhlbiBJJ3ZlIHdvcmtlZCBvbiBpZGVudGl0eSBtYW5hZ2VtZW50IGZyYW1l
d29ya3MsIHJlZ3VsYXRpb25zIGFuZCBzdGFuZGFyZHMuDQoNCkkgc3Vic2NyaWJlIHRvIHRoZSBv
bGQgSXRhbGlhbiBwcm92ZXJiOiAiaXQncyBuaWNlIHRvIHRydXN0IGJ1dCBiZXR0ZXIgbm90IHRv
Ii4gIFdvcmRzIG1hdHRlciBhbmQgSSB3b25kZXIgaWYgd2Ugc2hvdWxkbid0IGJlIHVzaW5nIHRo
ZSB3b3JkIHRydXN0IHNvIG11Y2guDQoNCk1vcmUgcHJhZ21hdGljYWxseSwgSSBub3RlIHRoZSB2
ZXJ5IHN0cm9uZyAiQXR0cmlidXRlcyIgcHVzaCBvZiB0aGUgcGFzdCAxOCBtb250aHMuICBBbmRy
ZXcgTmFzaCwgQW5pbCBKb2huLCBteXNlbGYgYW5kIG90aGVycyBoYXZlIHdyaXR0ZW4gYWJvdXQg
dGhpcy4gIFRoZSBGSURPIEFsbGlhbmNlIGlzIGFsbCBhYm91dCBhdXRoZW50aWNhdGlvbiBhbmQg
YXR0cmlidXRlcywgYW5kIHRoZXkgcHVycG9zZWZ1bGx5IGxlYXZlICJpZGVudGl0eSIgYXMgYSBt
YXR0ZXIgZm9yIG90aGVycyB0byB3b3JrIG91dCBmdXJ0aGVyIHVwIHRoZSBzdGFjay4gVGhlIE9J
RCBGb3VuZGF0aW9uIGlzIHByb21vdGluZyBhbiBBdHRyaWJ1dGVzIEV4Y2hhbmdlIE5ldHdvcmsg
IkFYTiIgYXJjaGl0ZWN0dXJlLiAgTmV3IGVudHJhbnRzIGxpa2UgaWQubWU8aHR0cDovL2lkLm1l
Lz4gKGFuIE5TVElDIHBpbG90IHBhcnRpY2lwYW50KSB0YWxrIGFib3V0IGF0dHJpYnV0ZXMgYW5k
IGF2b2lkICJpZGVudGl0eSIuDQoNCkkgbWVudGlvbiBhbGwgb2YgdGhpcyBhcyBhIHByZWx1ZGUg
dG8gc3VnZ2VzdCB0aGF0ICJ2ZWN0b3Igb2YgdHJ1c3QiIGlzIHN5bm9ueW1vdXMgd2l0aCAiYXR0
cmlidXRlIi4gSSB3b25kZXIgaWYgaXQgd291bGQgYmUgY2xlYXJlciB0byB1c2UgcGxhaW4gYW5k
IGN1cnJlbnQgbGFuZ3VhZ2UgcmF0aGVyIHRoYW4gY2FycnkgZm9yd2FyZCB0aGUgZnV6enkgYW5k
IEkgdGhpbmsgb3Zlcmx5IGFtYml0aW91cyBpZGVhIG9mICJ0cnVzdCI/DQoNCkZpbmFsbHksIEkn
ZCBsaWtlIHRvIHRocm93IGluIG15IGFiaWRpbmcgY29uY2VybiB0aGF0IExPQXMgaGF2ZSBmb3Vu
ZGVyZWQgc2ltcGx5IGJlY2F1c2UgaXQncyBkaWZmaWN1bHQgdG8gcGlnZW9uaG9sZSByaXNrLiBP
bmUgcGFydHkncyBpZGVhIG9mICJtZWRpdW0iIHJpc2sgZm9yIGluc3RhbmNlIHdpbGwgcmFyZWx5
IG1hcCBwcmVjaXNlbHkgdG8gYW5vdGhlcidzLiBJIHRoaW5rIHBlb3BsZSBoYXZlIGJlZW4gbWlz
bGVkIGludG8gdGhpbmtpbmcgdGhhdCBhbiAiTE9BIDMiIGlkZW50aXR5IHNob3VsZCBiZSBiZSBh
YmxlIHRvIGJlIHVzZWQgb24gaXRzIGZhY2UgKGkuZS4gd2lsbCAiaW50ZXJvcGVyYXRlIikgYXQg
YW55ICJMT0EgMyIgUlAuIFJpc2sgbWFuYWdlbWVudCBpcyBub3Qgc28gc2ltcGxlLg0KDQpUaGUg
TE9BIHBhcmFkaWdtIGJvcnJvd3MgZnJvbSBSaXNrIE1hbmFnZW1lbnQgc3RhbmRhcmRzIGxpa2Ug
SVNPIDMxMDAwIHdoaWNoIG9yZ2FuaXNhdGlvbnMgdXNlIHRvIHBsb3QgdGhlaXIgb3duIHJpc2tz
IGludGVybmFsbHkgdHlwaWNhbGx5IG9uIGEgZml2ZSBzY2FsZSAoZWcgTmVnbGlnaWJsZSAvIExv
dyAvIE1lZGl1bSAvIEhpZ2ggLyBHcmF2ZSkuIEJ1dCByaXNrIG1hbmFnZW1lbnQgc3RhbmRhcmRz
IHJlcXVpcmUgdGhhdCBlYWNoIG9yZ2FuaXNhdGlvbiBjYWxpYnJhdGVzIHJpc2sgaW4gaXRzIG93
biBidXNpbmVzcyBjb250ZXh0IGFuZCBhY2NvcmRpbmcgdG8gaXRzIG93biByaXNrIGFwcGV0aXRl
LiBUaGUgcmlzayBvZiBhIGZpcmV3YWxsIGJyZWFjaCBmb3IgZXhhbXBsZSBhdCBhIHN0YXJ0dXAg
c29jaWFsIG1lZGlhIGNvbXBhbnkgd2lsbCBiZSBhc3Nlc3NlZCBkaWZmZXJlbnRseSBieSBhIGJp
ZyBsaXN0ZWQgaGVhbHRoY2FyZSBjb21wYW55LiBTbyBvcmdhbmlzYXRpb24gQSBjYW4gc2F5IHRo
ZSByaXNrIG9mIGV2ZW50IFggaXMgTG93IGJ1dCBCIGNhbiBzYXkgdGhlIHJpc2sgb2YgdGhlIHNh
bWUgZXZlbnQgaXMgTWVkaXVtLiAgQXMgYSByZXN1bHQsIExPQXMgZG8gbm90IGludGVyLW9wZXJh
dGUuIFRoZXkgYXJlIGJhc2VkIG9uIHN0YW5kYXJkcyBtZWFudCBmb3IgaW50cmEtb3JnYW5pc2F0
aW9uIHJpc2sgbWFuYWdlbWVudCwgbm90IGludGVyLW9yZ2FuaXNhdGlvbiBjb21tdW5pY2F0aW9u
IG9mIHJpc2sgYXNzZXNzbWVudHMuDQoNClNvIGZhciB3aXRoIFZvVCB3ZSBhcmUgYWRkaW5nIG1v
cmUgZGltZW5zaW9ucyB0byB0aGUgUlBzJyBnZW5lcmljIHJpc2sgbWFuYWdlbWVudCBkZWNpc2lv
biBtYWtpbmcsIGFuZCB0aGF0J3MgZ3JlYXQuICBCdXQgd2UgYXJlIHN0aWxsIHBpZ2VvbmhvbGlu
ZyB0aGUgZGltZW5zaW9ucy4NCg0KSSdtIGFmcmFpZCB0aGUgcmVhbGl0eSBpcyB0aGF0IHJpc2sg
bWFuYWdlbWVudCB3aWxsIGFsd2F5cyBiZSBkb25lIGxvY2FsbHkuICBBbmQgc28gaXQgc2hvdWxk
IGJlLiAgV2hlbiBhbiBSUCBpcyBtYWtpbmcgdGhlIGRlY2lzaW9uIHRvIGFjY2VwdCBvciByZWpl
Y3QgYSBnaXZlbiBzdWJqZWN0LCB0aGV5IHdpbGwgZXZhbHVhdGUgYSByYW5nZSBvZiBhdHRyaWJ1
dGVzIG9yIHNpZ25hbHMuICBUaGUgc2V0IG9mIGF0dHJpYnV0ZXMgdGhhdCBtYXR0ZXJzIHZhcmll
cyBmcm9tIG9uZSBSUCB0byB0aGUgbmV4dC4gIEkgdGhpbmsgaXQncyBhIGdyZWF0IGlkZWEgaW5k
ZWVkIHRvIGNyZWF0ZSBndWlkYW5jZSBmb3IgZXZhbHVhdGluZyBhdHRyaWJ1dGVzLCBhbmQgdG8g
Y29hY2ggUlBzIHRvIGxvb2sgYXQgYWxsIHNvcnRzIG9mIGRpbWVuc2lvbnMuICBJIGp1c3QgZG9u
J3QgdGhpbmsgaXQgaGVscHMgYW55b25lIHRvIHBpZ2VvbmhvbGUgdGhlIHJpc2sgcmF0aW5ncywg
YmVjYXVzZSBhY3Jvc3Mgb3JnYW5pc2F0aW9ucywgYXJndW1lbnRzIGFib3V0IHRoZSBib3VuZGFy
aWVzIGJldHdlZW4gTE9BIDEvMi8zLzQgKHRoYXQgaXMsIHBvbGljeSBtYXBwaW5nKSB3aWxsIHVu
ZG8gYW55IGVmZmljaWVuY2llcyBnYWluZWQgZnJvbSB0aGUgY2F0ZWdvcml6YXRpb24uDQoNCkNo
ZWVycywNCg0KU3RldmUuDQoNCg0KU3RlcGhlbiBXaWxzb24NCk1hbmFnaW5nIERpcmVjdG9yDQpM
b2Nrc3RlcCBHcm91cA0KaHR0cDovL2xvY2tzdGVwLmNvbS5hdTxodHRwOi8vbG9ja3N0ZXAuY29t
LmF1Lz4NCkxvY2tzdGVwIENvbnN1bHRpbmcgcHJvdmlkZXMgaW5kZXBlbmRlbnQgc3BlY2lhbGlz
dCBhZHZpY2UgYW5kIGFuYWx5c2lzDQpvbiBkaWdpdGFsIGlkZW50aXR5IGFuZCBwcml2YWN5LiBM
b2Nrc3RlcCBUZWNobm9sb2dpZXMgZGV2ZWxvcHMgdW5pcXVlDQpuZXcgc21hcnQgSUQgc29sdXRp
b25zIHRoYXQgZW5oYW5jZSBwcml2YWN5IGFuZCBwcmV2ZW50IGlkZW50aXR5IHRoZWZ0Lg0KDQoN
Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnZvdCBt
YWlsaW5nIGxpc3QNCnZvdEBpZXRmLm9yZzxtYWlsdG86dm90QGlldGYub3JnPg0KaHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92b3QNCg0K

--_000_147EE18440E5AF44834B220ED35BA530D32F0A2EWLGPRDMBX01diag_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9
DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg
MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl
LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv
Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJn
aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt
ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv
LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy
bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl
LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l
O30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv
Ow0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy
Z2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l
dyBSb21hbiIsInNlcmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29B
Y2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v
biBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv
bnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KcC5N
c29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFw
aA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJp
Z2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFy
Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp
bWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUt
dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv
bG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJh
bGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp
bms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30N
CnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv
bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNv
Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu
MHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJn
aW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn
ZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNv
LWxpc3QtaWQ6MTA0MTYzMTM1NzsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10
ZW1wbGF0ZS1pZHM6LTg2NTcyNDgyMCAyNjkwMjUyODEgMjY5MDI1MjgzIDI2OTAyNTI4NSAyNjkw
MjUyODEgMjY5MDI1MjgzIDI2OTAyNTI4NSAyNjkwMjUyODEgMjY5MDI1MjgzIDI2OTAyNTI4NTt9
DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z
by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt
bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWls
eTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1
bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z
by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZv
bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1u
dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh
Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k
ZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0K
CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K
CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm
dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs
MDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10
ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np
dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg
TmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0
Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t
bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250
LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXIt
Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w
Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x
OC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2
ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt
dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p
bmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxl
dmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6
74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp
b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9
DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQot
LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4
dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl
IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl
eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+
DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1OWiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+
DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlB1dHRpbmcgdGhpcyBzcGxpdCwg
YmFjayBpbnRvIG9uZSB0aHJlYWQuLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj7igKYg
Jm5ic3A7YW5kIHBsZWFkaW5nIHRvIGZvbGtzIHRvIGZvY3VzIGJhY2sgb24gdGhlIHZlY3RvcnMs
IG9yIGFzcGVjdHMsIG9yIOKAmHRoaW5nc+KAmSAtIHdoYXRldmVyIHdlIGNhbGwgdGhlbSDigJMg
dGhhdCB0aGUgUlAgaGFzIGFuIGludGVyZXN0IGluLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx
RjQ5N0QiPkp1c3RpbiBpcyB2YWxpYW50bHkgdHJ5aW5nIHRvIHJlLXN0YXRlIHRoZSBwdXJwb3Nl
IG9mIGhpcyBvcGVuaW5nIOKAmHZlY3RvcnPigJkgc3RyYXdtYW4g4oCTIGFsd2F5cyB1c2VmdWwg
dG8gcmVmcmVzaCBvbmXigJlzIG1lbW9yeSBieSBnb2luZyBiYWNrIHRvIGxvb2sgYXQgdGhlbS4u
LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaXMgc3RhcnRpbmcgbGlzdCBvZiB2ZWN0
b3JzIHdhczo8L3NwYW4+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3
RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklkZW50aXR5IFByb29maW5nPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNyZWRlbnRpYWwgU3RyZW5ndGg8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzFGNDk3RCI+QXNzZXJ0aW9uIFByZXNlbnRhdGlvbjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjojMUY0OTdEIj5PcGVyYXRpb25hbCBNYW5hZ2VtZW50PG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JZiB0aGUgZGlz
Y3Vzc2lvbiBvbiBMb0FzIG9mZmVycyBhbnkgdmFsdWUgaGVyZSwgaXQgd291bGQgYmUgdG8gYWRk
IHNvbWUgZmluZXIgZ3JhaW5lZCBhZGRpdGlvbiB0byB0aGUgYWJvdmUgKGZhaXJseSBjb2Fyc2Ut
Z3JhaW5lZCkgbGlzdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZXJl4oCZcyBhbHJlYWR5IGFuIGFja25vd2xlZGdt
ZW50IHRoYXQgT3BlcmF0aW9uYWwgTWFuYWdlbWVudCBtYXkgYmUgY29tcG9zZWQgb2YgYSByYW5n
ZSBvZiBjb25jZXJucyDigJMgYSBtaXggb2YgY29udGV4dCBkZXBlbmRlbnQsIHRlbXBvcmFsIGFu
ZCBzdGF0aWMgKG1vcmUNCiB2ZWN0b3JzPykg4oCTIHRoYXQgaW5mbHVlbmNlIHRoZSBSUOKAmXMg
ZGVjaXNpb24gdG8gYWNjZXB0IG9yIG90aGVyd2lzZSwgYW4gYXV0aGVudGljYXRlZCBpZGVudGl0
eS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklmIHdlIGdvdCB0byBhIHBvaW50IHdoZXJl
IHdlIGNvdWxkIGFncmVlIG9uIHdoYXQgdGhlc2UgdmVjdG9ycyBhcmUsIHRoZW4gd2UgY2FuIGhh
dmUgdGhlIChzZXBhcmF0ZSkgZGViYXRlIGFib3V0IHdoZXRoZXIgY29tYmluaW5nIHRoZW0vZGVs
aW5lYXRpbmcgdGhlbSBpbg0KIHNvbWUgd2F5IGlzIHVzZWZ1bC9oZWxwZnVsLCBvciBub3QuPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
MUY0OTdEIj5DaGVlcnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q29saW4NCjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu
MHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+
PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+
PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gdm90IFttYWlsdG86dm90
LWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlJpY2hlciwgSnVzdGluIFAu
PGJyPg0KPGI+U2VudDo8L2I+IFNhdHVyZGF5LCAxMSBPY3RvYmVyIDIwMTQgNjoyOSBhLm0uPGJy
Pg0KPGI+VG86PC9iPiBCb3VtYSwgVGltPGJyPg0KPGI+Q2M6PC9iPiBLZW4gRGFnZzsgdm90QGll
dGYub3JnOyBzd2lsc29uQGxvY2tzdGVwLmNvbS5hdTxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog
W1ZvVF0gRm91bmRhdGlvbmFsIHF1ZXN0aW9ucyBvZiBwcmluY2lwbGU8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGF0IHdlJ3JlIHRyeWluZyB0byBkbyB3
aXRoIHRoZSAmcXVvdDtWZWN0b3JzJnF1b3Q7IGFwcHJvYWNoIGhlcmUgaXMgdG8gc3RyaWtlIGEg
YmFsYW5jZSBiZXR3ZWVuIHRoZSBvdmVybHktc2ltcGxpc3RpYyAmcXVvdDtzaW5nbGUgc2V0IG9m
IGxpbmVhciBsZXZlbHMmcXVvdDsgYXBwcm9hY2ggdGhhdCBMb0EgZ2l2ZXMgdXMgKHRoYXQgbm9i
b2R5IG9uIHRoaXMgbGlzdCBsaWtlcyBidXQgYWxsIGFncmVlIHRoYXQgYXBwcyBjYW4gYWN0dWFs
bHkNCiBkbyBzb21lIGxldmVsIG9mIHByb2Nlc3Npbmcgd2l0aCBpdCkgYW5kIHRoZSBvdmVybHkt
Y29tcGxleCAmcXVvdDt2ZXJ5IGxvbmcgY29tcGxleCBzZXQgb2YgYXR0cmlidXRlcyZxdW90OyBh
cHByb2FjaCB0aGF0IFRpbSwgU2NvdHQsIGFuZCBvdGhlcnMgaGF2ZSBicm91Z2h0IHVwICh0aGF0
IHNlZW1zIG1vcmUgZXhwcmVzc2l2ZSBhbmQgaWRlYWwgYnV0IG5vIGFwcCBpcyBldmVyIGdvaW5n
IHRvIG1ha2Ugc2Vuc2Ugb2YsIG9yIGV2ZW4gdHJ5IHRvKS4gSSB0aGluaw0KIGl0J3Mgc2FmZSB0
byBzYXkgdGhhdCBuZWl0aGVyIGV4dHJlbWUgd29ya3MgYW5kIHRoYXQgYSByaWdodCBhbnN3ZXIg
cHJvYmFibHkgbGllcyBpbiB0aGUgbWlkZGxlLiZuYnNwOw0KPG86cD48L286cD48L3A+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbyB0aGF0J3Mgd2hhdCB0aGlzIHN0cmF3bWFuIGlz
IC0tIGl0J3Mgc2ltdWx0YW5lb3VzbHkgbGVzcyBjb21wbGV4IGFuZCBtb3JlIGNvbXBsZXggdGhh
biB0aGUgYWx0ZXJuYXRpdmVzLiBJcyBpdCB0aGUgcmlnaHQgY3V0PyBQcm9iYWJseSBub3QsIGJ1
dCBpdCdzIGF0IGxlYXN0IGEgY3V0dGluZyBwb2ludCB0aGF0IHdlIGNhbiBwdXNoIHRvIGVpdGhl
ciBzaWRlLiBXaGF0IEkgdGhpbmsgd2UgbmVlZCB0byBkdXRpZnVsbHkNCiBhdm9pZCBpcyBwdXNo
aW5nIGl0IGhhcmQgdG8gZWl0aGVyIGVuZC4gSSByZWFsbHkgbGlrZSB0aGUgbm90aW9uIHRoYXQg
ZXZlbiBpZiB0aGUgY29tYmluYXRpb25zIG9mIHRoZSB2ZWN0b3IgdmFsdWVzIGFyZW4ndCBkaXJl
Y3RseSBjb21wYXRpYmxlIChhcyBTdGV2ZSBzYXlzKSwgdGhlbiB0aGUgYnVpbGRpbmcgYmxvY2tz
IHdvdWxkIGF0IGxlYXN0IGJlIGNvbXBhcmFibGUsIGdpdmluZyBhIGhvcGUgb2YgZGVmaW5pbmcg
YSBwb2xpY3kgdG8gdHJhbnNsYXRlDQogYmV0d2VlbiB0aGVtIHdoZW4gbmVlZGVkLiZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbHNv
LCBJIHdhbnRlZCB0byBrZXkgaW50byB0aGUgZmFjdCB0aGF0IHRoZXJlIGFyZSBzZXZlcmFsIGlu
ZGVwZW5kZW50IGFuZCBvcnRob2dvbmFsIGNvbXBvbmVudHMgaGVyZS4gTWF5YmUgaXQncyBub3Qg
YSBzZXQgb2YgbGV2ZWxzIHRoYXQgYXJlIHRpZWQgdG9nZXRoZXIsIGJ1dCBJIHRoaW5rIGl0IGlz
IGluIHNvbWV3YXkgYSBzZXQgb2YgaW5kZXBlbmRlbnQgKnRoaW5ncyogdGhhdCBhcmUgdGllZCB0
b2dldGhlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+Jm5ic3A7LS0gSnVzdGluPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+4oCm4oCm4oCm4oCm
4oCm4oCm4oCm4oCm4oCm4oCm4oCm4oCm4oCm4oCm4oCm4oCm4oCm4oCm4oCm4oCm4oCm4oCmLjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBtYXkgbWFrZSBzZW5zZSB0byBsb29rIGF0IExPQXMg
YXMgc29tZXRoaW5nIHRoYXQgaXMgJnF1b3Q7Y29hcnNlLWdyYWluZWQmcXVvdDsgYW5kIGEgc3Rh
cnRpbmcgcG9pbnQuJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIGFsbCB0aGluayBp
dCBpcyBub3QgZW5vdWdoLCBidXQgaW4gdGhlIGFic2VuY2Ugb2YgdGhlIEJvcmcgc2hvd2luZyB1
cCB0byBlbmZvcmNlIGEgY29sbGVjdGl2ZSBoaXZlLW1pbmQgYWNyb3NzIG9yZ2FuaXphdGlvbmFs
IGJvdW5kYXJpZXMsIHdlIGNhbiBsaXZlIHdpdGggaXQgYW5kIHVzZSBpdCBhcyBhIHN0YXJ0aW5n
IHBvaW50IGZvciB0aGUgZGlzY3Vzc2lvbiAmcXVvdDtXaGF0IG1vcmUgZG8gd2UgbmVlZCBpbg0K
IG9yZGVyIHRvIGxldCB0aGlzIHBlcnNvbiBpbiB0aGUgZG9vcj8mcXVvdDs8bzpwPjwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+QW5kIHRoYXQgaXMgd2hlcmUgUlAgaW1wbGVtZW50ZWQgY29tcGVuc2F0aW5n
IGNvbnRyb2xzIGNhbiBwbGF5IGEgcGFydC4gVGhlIGNoYWxsZW5nZSBpcyB0aGF0IGZvbGtzIHNl
ZW0gdG8gY29uZmxhdGUgJnF1b3Q7dGhpbmdzIG5lZWRlZCB0byBlbnN1cmUgY29uZmlkZW5jZSBp
biBhbiBpZGVudGl0eSZxdW90OyB3aXRoICZxdW90O3RoaW5ncyBuZWVkZWQgdG8gbWl0aWdhdGUg
cmlzayBpbiB0aGUgdHJhbnNhY3Rpb24mcXVvdDsgYW5kIHdobyBpcw0KIChDU1Agb3IgUlApIHJl
c3BvbnNpYmxlIGZvciB3aGF0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzLDxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj4tIEFuaWw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Oi0gQW5p
bCBKb2huPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj46LSBNYWtpbmcgRGln
aXRhbCBTZXJ2aWNlcyBTZWN1cmUgYW5kIFRydXN0d29ydGh5PG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj46LSA8YSBocmVmPSJodHRwczovL2Jsb2cuYW5pbGpvaG4uY29tIj5o
dHRwczovL2Jsb2cuYW5pbGpvaG4uY29tPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgT2N0IDEwLCAy
MDE0IGF0IDExOjAyIFBNLCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN3aWxzb25AbG9ja3N0ZXAuY29t
LmF1IiB0YXJnZXQ9Il9ibGFuayI+c3dpbHNvbkBsb2Nrc3RlcC5jb20uYXU8L2E+Jmd0OyB3cm90
ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCldlIGFyZSBhbGwg
YWdyZWVkIG9mIGNvdXJzZSB0aGF0IFJQcyBuZWVkIHRvIHVuZGVyc3RhbmQgdGhlaXIgcmlza3Ms
IGRldGVybWluZSB3aGF0J3MgbmVlZGVkIGZyb20gYW55IGV4dGVybmFsIHByb2Nlc3Mgb2YgaWRl
bnRpZmljYXRpb24gb3IgYXR0cmlidXRlIGF0dGVzdGF0aW9uLCBjb21tdW5pY2F0ZSB0aG9zZSBu
ZWVkcyB0byBjYW5kaWRhdGUgQVBzLCBhbmQgZnJvbSB0aGVyZSwgY29udHJhY3QgYW4gYWNjZXB0
YWJsZSBwcm92aWRlci48YnI+DQo8YnI+DQpNeSBxdWVzdGlvbiBpcyB3aGV0aGVyIG9yIG5vdCBh
IHBpZ2VvbmhvbGVkIExPQSBoZWxwcyBhdCBhbnkgcG9pbnQgaW4gdGhpcyBwcm9jZXNzLjxicj4N
Cjxicj4NClRoZSBkZXZpbCBpcyBpbiB0aGUgZGV0YWlsLiZuYnNwOyBUbyBteSBtaW5kLCBMT0Eg
aXMgYW4gaW50ZXJtZWRpYXRlIHN0ZXAgdGhhdCB0YWtlcyBhIGRldGFpbGVkIHJpc2sgYW5hbHlz
aXMsIHNxdWVlemVzIGl0IGludG8gYSBiaW4gKGxvc2luZyBsb3RzIG9mIGluZm9ybWF0aW9uIGFz
IGEgcmVzdWx0KSwgd2hpY2ggaXMgdGhlbiB1c2VkIHRvIHNob3J0bGlzdCBjYW5kaWRhdGUgcHJv
dmlkZXJzLCBiZWZvcmUgZ29pbmcgaW50byBkZXRhaWxlZCBkdWUgZGlsaWdlbmNlDQogd2hlcmUg
YWxsIHRob3NlIGRldGFpbHMgbmVlZCB0byBiZSBwdXQgYmFjayBvbiB0aGUgdGFibGUuPGJyPg0K
PGJyPg0KSSB0aGluayB3ZSBhbGwga25vdyBieSBub3cgb2YgY2FzZXMgd2hlcmUgUlBzIGhhdmUg
bG9va2VkIGF0IGNhbmRpZGF0ZSBJZFBzIGF0IGEgZ2l2ZW4gTE9BLCBhbmQgaGF2ZSBjb21lIHVw
IHdpdGggdGhlIHJlcXVlc3Qgb2YgJnF1b3Q7TE9BIHR3byBhbmQgYSBoYWxmJnF1b3Q7ICh0aGlz
IHdhcyBtZW50aW9uZWQgYXQgQ0lTIDIwMTQgbW9yZSB0aGFuIG9uY2UsIGFuZCBJIGhhdmUgc2Vl
biBpdCBmaXJzdCBoYW5kIGluIHRoZSBVSyBJREFQKS48YnI+DQo8YnI+DQpDbGVhcmx5IHdoYXQn
cyBnb2luZyBvbiBoZXJlIGlzIGFuIFJQJ3MgaWRlYSBvZiBzYXkgJnF1b3Q7TE9BIDImcXVvdDsg
ZGlmZmVycyBmcm9tIGEgZ2l2ZW4gSWRQJ3MgaWRlYSBvZiBMT0EgMi4mbmJzcDsgTW9yZW92ZXIs
IHRoZSBpZGVhIG9mIExPQSAyIG11c3QgZGlmZmVyIGZyb20gb25lIElkUCB0byBhbm90aGVyIElk
UC4mbmJzcDsgV2hlbiBwZW9wbGUgYXNrIGZvciAmcXVvdDtMT0EgMi41JnF1b3Q7IHdoYXQgdGhl
eSdyZSBhc2tpbmcgZm9yIGlzIGEgY3VzdG9taXNlZCBpZGVudGlmaWNhdGlvbi4mbmJzcDsNCiBJ
ZiBMT0EgMiBpc24ndCB3aGF0IGl0IHNlZW1zLCB0aGVuIHRoZXJlIGNhbm5vdCBwb3NzaWJseSBi
ZSBhbnkgc3VjaCB0aGluZyBhcyBhICpzdGFuZGFyZGlzZWQqIExPQSAyLjUuJm5ic3A7IEFsbCB3
ZSB3aWxsIGdldCBpcyBmcmVzaCBjYWxscyBmb3IgJnF1b3Q7TE9BIDIuNzUgcGxlYXNlJnF1b3Q7
Ljxicj4NCjxicj4NCklmIFJQcyBuZWVkIHRvIGRvIGRldGFpbGVkIGFuYWx5c2lzIG9mIGF1dGhl
bnRpY2F0aW9uIG5lZWRzLCBhbmQgZ2V0IGRldGFpbGVkIHZlcmlmaWNhdGlvbiBvZiB0aGUgYWN0
dWFsIElEIHByb29maW5nIGRvbmUgYnkgSWRQcyBhbmQgQVBzLCB0aGVuIEkganVzdCBkb24ndCBz
ZWUgYW55IHBvaW50IGF0dGFjaGluZyB0aGUgTE9BIGxhYmVsIGFsb25nIHRoZSB3YXkuJm5ic3A7
IEl0J3MgbWlzbGVhZGluZy48YnI+DQo8YnI+DQpDaGVlcnMsPGJyPg0KPGJyPg0KU3RldmUuPGJy
Pg0KPGJyPg0KU3RlcGhlbiBXaWxzb248YnI+DQpMb2Nrc3RlcDxicj4NCjxhIGhyZWY9Imh0dHA6
Ly9sb2Nrc3RlcC5jb20uYXUiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vbG9ja3N0ZXAuY29tLmF1
PC9hPjxicj4NCkxvY2tzdGVwIENvbnN1bHRpbmcgcHJvdmlkZXMgaW5kZXBlbmRlbnQgc3BlY2lh
bGlzdCBhZHZpY2UgYW5kIGFuYWx5c2lzPGJyPg0Kb24gZGlnaXRhbCBpZGVudGl0eSBhbmQgcHJp
dmFjeS4mbmJzcDsgTG9ja3N0ZXAgVGVjaG5vbG9naWVzIGRldmVsb3BzIHVuaXF1ZTxicj4NCm5l
dyBzbWFydCBJRCBzb2x1dGlvbnMgdGhhdCBlbmhhbmNlIHByaXZhY3kgYW5kIHByZXZlbnQgaWRl
bnRpdHkgdGhlZnQuPGJyPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5PbiBPY3QgMTAsIDIwMTQsIGF0IDEwOjUxIEFNLCBCb3VtYSwgVGltICZs
dDs8YSBocmVmPSJtYWlsdG86VGltLkJvdW1hQHRicy1zY3QuZ2MuY2EiPlRpbS5Cb3VtYUB0YnMt
c2N0LmdjLmNhPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6IzFGNDk3RCI+SSBhZ3JlZSB3aXRoIEtlbiw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO
LUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxz
cGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5
N0QiPldoZW4gd2UgZGV2ZWxvcGVkIGxldmVscyBvZiBhc3N1cmFuY2UgKGhlcmUgaW4gQ2FuYWRh
KSB3ZSBkaWQgc2V2ZXJhbCB0aGluZ3M6PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIg
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBs
YW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJh
Z3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8y
Ij48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtZmFt
aWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0i
Zm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFb
ZW5kaWZdPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG
NDk3RCI+V2UgZGVmaW5lZCB0aGVtIGFzIGxldmVscyBvZiBjb25maWRlbmNlIHJlcXVpcmVkIChM
ZXZlbHMgMSB0aHJvdWdoIDQpPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50
Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxz
cGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1mYW1pbHk6U3ltYm9sIj48c3BhbiBzdHlsZT0i
bXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5l
dyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tQ0Ei
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XZSBtYXBwZWQgdGhlc2UgbGV2
ZWxzIG9mIGNvbmZpZGVuY2UgdG8gYSByYW5nZSBvZiBkZWdyZWUgb2YgaW1wYWN0cy48L3NwYW4+
PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29M
aXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZl
bDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJm
b250LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4g
c3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9z
cGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMxRjQ5N0QiPldlIHRoZW4gc3BlY2lmaWVkIHNlcGFyYXRlbHkgaWRlbnRpdHkgYXNzdXJh
bmNlIGxldmVscyBhbmQgY3JlZGVudGlhbCBhc3N1cmFuY2UgbGV2ZWxzIChhbmQgZm9jdXNlZCBv
biBjcmVkZW50aWFsIGZpcnN0KTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVu
dDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48
c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9
Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBO
ZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLUNB
IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V2UgYWxzbyBmYWN0b3JlZCBv
dXQgbGlrZWxpaG9vZCBpbiB0aGUgYXNzdXJhbmNlIGxldmVsIGFzc2Vzc21lbnQgcHJvY2Vzcy4g
VGhhdCBtYWRlIHRoZSBhc3Nlc3NtZW50cyBtdWNoIGxlc3Mgc3ViamVjdGl2ZS48L3NwYW4+PHNw
YW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3
RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkF0IHRoZSBlbmQgb2YgdGhlIGRheSwgYXMgS2VuIHN0YXRl
cywgJm5ic3A7aXTigJlzIHRoZSBqb2IgdGhlIFJQIHRvIHVuZGVyc3RhbmQgdGhlaXIgcmlzayAo
YWxvbmcgd2l0aCBsaWtlbGlob29kKSBhbmQgdG8gY29tbXVuaWNhdGUgYSBzdGFuZGFyZGl6ZWQg
cmVxdWlyZW1lbnQNCiBiYWNrIHRvIGEgcHJvdmlkZXIgKEFQKTwvc3Bhbj48c3BhbiBsYW5nPSJF
Ti1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
bGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgQVAg
aXMgJm5ic3A7YWNjb3VudGFibGUgZm9yIHByb3ZpZGluZyBhIHZlcnkgcHJlc2NyaWJlZCBjb21w
b25lbnQgdGhhdCBmaXRzIGludG8gYSBsYXJnZXIgc3lzdGVtIGFuZCBhIHJpc2sgZW52aXJvbm1l
bnQgdGhhdCB0aGV5IG1pZ2h0IG5vdCBoYXZlDQogYSBmdWxsIHZpZXcgaW50by4gVGhlIFJQIG1h
eSBwdXQgaW4gcHJvdmlzaW9ucyB0byBzaGFyZSB0aGUgcmlzayB3aXRoIHRoZSBBUCwgb3Igbm90
IGJ1dCB0aGF0IGVudGlyZWx5IGRlcGVuZHMgb24gdGhlIGFycmFuZ2VtZW50LCBidXQgYXQgbGVh
c3QgdGhlIFJQIGFuZCBBUCB1bmRlcnN0YW5kIHdoYXTigJlzIG9uIHRoZSB0YWJsZSBhcyBhIHN0
YXJ0aW5nIHBvaW50Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0Ei
PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9
IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SW4gQ2FuYWRhLCB3
ZSBkaWQgdGhhdCB3aXRoIHRoZSBjcmVkZW50aWFsIGZpcnN0LCBhbmQgYXJlIG5vdyBmaWd1cmlu
ZyBvdXQgaWRlbnRpdHkgKG11Y2ggaGFyZGVyKS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO
LUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxz
cGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5
N0QiPkkgYWxzbyBhZ3JlZSB0aGF0IOKAmGlkZW50aXR54oCZIGlzIGp1c3QgYSBzZXQgb2YgYXR0
cmlidXRlcyDigJNhbmQgJm5ic3A7dGhlc2UgaWRlbnRpdHkgYXR0cmlidXRlcyBjYW4gdmFyeSBi
ZXR3ZWVuIG9yZ2FuaXphdGlvbnMgb3IganVyaXNkaWN0aW9ucyw8L3NwYW4+PHNwYW4gbGFuZz0i
RU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7
PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMxRjQ5N0QiPkFzIGZvciB0aGUgdGVybSDigJh2ZWN0b3Jz4oCZLCBJIGdldCB0aGUgaWRl
YSwgYnV0IEkgdGhpbmsgdGhlIGNvbW11bml0eSB3aWxsIHRoaW5rIGl04oCZcyB0b28gdGVjaG5p
Y2FsIG9yIGVzb3RlcmljLiBJIGxpa2UgdG8gdGhpbmsgb2YgYSDigJhkaWdpdGFsIGlkZW50aXR5
4oCZDQogKG9yIHdoYXRldmVyIHlvdSBjYWxsIGl0KSwgd2hlbiBpdCBzaG93cyB1cCBhdCB5b3Vy
IGRpZ2l0YWwgZnJvbnQgZG9vciwgaXQgaXMgdGhlIHByb2R1Y3Qgb2YgYSB2ZXJ5IGxvbmcsIGNv
bXBsZXggc3VwcGx5IGNoYWluLCBmcmF1Z2h0IHdpdGggbWFueSByaXNrcyBhbmQgY29tcHJvbWlz
ZXMuIEkgbWF5IGhhdmUgY29uZmlkZW5jZSBpbiBjZXJ0YWluIHBpZWNlcyBvZiwgYnV0IG90aGVy
IEkgbWlnaHQgbm90IHRydXN0IGF0IGFsbC48L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNB
IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFu
IGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi
PiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojMUY0OTdEIj5UaW08L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxh
bmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu
YnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX19fX19yZXBseXNlcGFyYXRvciI+PC9hPjxiPjxz
cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxz
cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHZvdCBbPGEgaHJlZj0ibWFp
bHRvOnZvdC1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86dm90LWJvdW5jZXNAaWV0Zi5vcmc8L2E+
XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5LZW4gRGFnZzxicj4NCjxiPlNlbnQ6PC9iPiBPY3RvYmVy
LTA5LTE0IDk6NDIgUE08YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzpzd2lsc29uQGxv
Y2tzdGVwLmNvbS5hdSI+c3dpbHNvbkBsb2Nrc3RlcC5jb20uYXU8L2E+PGJyPg0KPGI+Q2M6PC9i
PiA8YSBocmVmPSJtYWlsdG86dm90QGlldGYub3JnIj52b3RAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+
U3ViamVjdDo8L2I+IFJlOiBbVm9UXSBGb3VuZGF0aW9uYWwgcXVlc3Rpb25zIG9mIHByaW5jaXBs
ZTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj5TdGV2ZSw8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu
Zz0iRU4tQ0EiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj5BcyB3ZSBoYXZlIGNvbW11bmlj
YXRlZCBpbiZuYnNwO3RoZSBwYXN0LCBJIGFtIGEgc3Ryb25nIGJlbGlldmVyIHRoZSBhbiBMT0Eg
ZGVzaWduYXRpb24gaXMgYW4gaW5kaWNhdGlvbiBvZiB0aGUgcHJvY2Vzc2VzL21lY2hhbmlzbXMg
dGhhdCBhbiZuYnNwO0lkUCBoYXMgdW5kZXJ0YWtlbi4gSW4gb3RoZXIgd29yZHMsIGl0IGlzIGEg
Y29tbXVuaWNhdGlvbiB0b29sLiZuYnNwO1RoZSBjaG9pY2UgaXMgdGhlDQogUlBzLiBUaGF0IGlz
LCBhbiZuYnNwO2Fzc2VydGlvbiBhdCBhIHNwZWNpZmljIExPQSBieSBhbiZuYnNwO0lkUC9DU1Av
QVAmbmJzcDtpcyBvbmUgb2YgdGhlIG1lY2hhbmlzbXMgYSBSUCBzaG91bGQgdXNlIHRvIG9mZnNl
dCB0aGUgYXV0aGVudGljYXRpb24gcmlzayBpdCBoYXMgaWRlbnRpZmllZCBmb3IgdGhlIHNlcnZp
Y2UgaXQgd2FudHMgdG8gZGVsaXZlci4gSW4gb3RoZXIgd29yZHMsIGl0IGlzIHRoZSByaXNrIG9m
IHRoZSBSUCB0aGF0IGlzIHBhcmFtb3VudCBub3QgdGhlDQogY2xhaW1zIG9mIGFuJm5ic3A7aWRl
bnRpdHkvY3JlZGVudGlhbC9hdHRyaWJ1dGUvdG9rZW4gcHJvdmlkZXIuPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i
RU4tQ0EiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj5MaWtlIHlvdSwgSSBhbSBhIHN0cm9u
ZyBiZWxpZXZlciB0aGF0IHRoZSBkZXRlcm1pbmF0aW9uIG9mIHdoZXRoZXIgb3Igbm90IGFuIGlk
ZW50aXR5IGlzIGdvb2QgZW5vdWdoIGlzIHRoZSByZXNwb25zaWJpbGl0eSBvZiB0aGUgUlAuIElu
IG15IGV4cGVyaWVuY2UsIHRoZXkgbWFrZSB0aGF0IGRldGVybWluYXRpb24gYmFzZWQgdXBvbiBh
IHNldCBvZiBhdHRyaWJ1dGVzIHRoZXkNCiBiZWxpZXZlIGFyZSBuZWNlc3NhcnkuIElmIHRoZXkg
dHJ1c3QgdGhhdCBhbiBJZFAncyBhc3NlcnRpb24gb2YgaWRlbnRpdHkgY292ZXJzIHRoZSBhdHRy
aWJ1dGVzIHRoZXkgYmVsaWV2ZSBhcmUmbmJzcDtyZXF1aXJlZCB0aGVtIHRoZXkgY2FuIGFjY2Vw
dCB0aGUgYXNzZXJ0aW9uLiBJZiBpdCBkb2Vzbid0IHRoZW4gdGhhdCBoYXZlIHRvIGltcGxlbWVu
dCBhZGRpdGlvbmFsIG1lY2hhbmlzbXMgdG8gb2Zmc2V0IHRoZSByZXNpZHVhbCByaXNrLjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIGxhbmc9IkVOLUNBIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+V2l0aCByZXNwZWN0
IHRvIHZlY3RvcnMgb2YgdHJ1c3QsIEkgYW0gaW50ZXJlc3RlZCBpbiBleHBsb3Jpbmcgd2hhdCB0
aGV5IGFyZSBhbmQgaG93IHRoZXkgY2FuIGJlIGFwcGxpZWQuPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0Ei
PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj5LZW48YnI+DQo8YnI+DQpPbiBUaHVyc2RheSwg
T2N0b2JlciA5LCAyMDE0LCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN3aWxzb25AbG9ja3N0ZXAuY29t
LmF1Ij5zd2lsc29uQGxvY2tzdGVwLmNvbS5hdTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIg
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Rmlyc3QsIHRvIGludHJvZHVj
ZSBteXNlbGYsIEkgYW0gYW4gaWRlbnRpdHkgYW5kIHByaXZhY3kgcmVzZWFyY2hlciwgYW5hbHlz
dCBhbmQgY29uc3VsdGFudC4mbmJzcDsgSSd2ZSBiZWVuIGludm9sdmVkIGluIHRoaXMgc2luY2Ug
MTk5NSwgd2hlbiBJIGN1dCBteSB0ZWV0aCBpbiBQS0kNCiBhbmQgc21hcnRjYXJkcyAod2l0aCB0
aGUgZWFybHkgY29tcGFuaWVzIHRoYXQgYmVjYW1lIEJhbHRpbW9yZSBUZWNobm9sb2dpZXMpLiBT
aW5jZSB0aGVuIEkndmUgd29ya2VkIG9uIGlkZW50aXR5IG1hbmFnZW1lbnQgZnJhbWV3b3Jrcywg
cmVndWxhdGlvbnMgYW5kIHN0YW5kYXJkcy4gJm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNB
Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFu
PjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90OyI+SSBzdWJzY3JpYmUgdG8gdGhlIG9sZCBJdGFsaWFuIHByb3ZlcmI6ICZxdW90O2l0J3Mg
bmljZSB0byB0cnVzdCBidXQgYmV0dGVyIG5vdCB0byZxdW90Oy4mbmJzcDsgV29yZHMgbWF0dGVy
IGFuZCBJIHdvbmRlciBpZiB3ZSBzaG91bGRuJ3QgYmUgdXNpbmcgdGhlIHdvcmQgdHJ1c3Qgc28g
bXVjaC4gJm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1D
QSIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+TW9yZSBwcmFnbWF0aWNh
bGx5LCBJIG5vdGUgdGhlIHZlcnkgc3Ryb25nICZxdW90O0F0dHJpYnV0ZXMmcXVvdDsgcHVzaCBv
ZiB0aGUgcGFzdCAxOCBtb250aHMuJm5ic3A7IEFuZHJldyBOYXNoLCBBbmlsIEpvaG4sIG15c2Vs
ZiBhbmQgb3RoZXJzIGhhdmUgd3JpdHRlbiBhYm91dCB0aGlzLiZuYnNwOyBUaGUgRklETw0KIEFs
bGlhbmNlIGlzIGFsbCBhYm91dCBhdXRoZW50aWNhdGlvbiBhbmQgYXR0cmlidXRlcywgYW5kIHRo
ZXkgcHVycG9zZWZ1bGx5IGxlYXZlICZxdW90O2lkZW50aXR5JnF1b3Q7IGFzIGEgbWF0dGVyIGZv
ciBvdGhlcnMgdG8gd29yayBvdXQgZnVydGhlciB1cCB0aGUgc3RhY2suIFRoZSBPSUQgRm91bmRh
dGlvbiBpcyBwcm9tb3RpbmcgYW4gQXR0cmlidXRlcyBFeGNoYW5nZSBOZXR3b3JrICZxdW90O0FY
TiZxdW90OyBhcmNoaXRlY3R1cmUuJm5ic3A7IE5ldyBlbnRyYW50cyBsaWtlDQo8YSBocmVmPSJo
dHRwOi8vaWQubWUvIiB0YXJnZXQ9Il9ibGFuayI+aWQubWU8L2E+IChhbiBOU1RJQyBwaWxvdCBw
YXJ0aWNpcGFudCkgdGFsayBhYm91dCBhdHRyaWJ1dGVzIGFuZCBhdm9pZCAmcXVvdDtpZGVudGl0
eSZxdW90Oy4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO
LUNBIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0Ei
PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JIG1lbnRpb24gYWxs
IG9mIHRoaXMgYXMgYSBwcmVsdWRlIHRvIHN1Z2dlc3QgdGhhdCAmcXVvdDt2ZWN0b3Igb2YgdHJ1
c3QmcXVvdDsgaXMgc3lub255bW91cyB3aXRoICZxdW90O2F0dHJpYnV0ZSZxdW90Oy4gSSB3b25k
ZXIgaWYgaXQgd291bGQgYmUgY2xlYXJlciB0byB1c2UgcGxhaW4gYW5kIGN1cnJlbnQgbGFuZ3Vh
Z2UNCiByYXRoZXIgdGhhbiBjYXJyeSBmb3J3YXJkIHRoZSBmdXp6eSBhbmQgSSB0aGluayBvdmVy
bHkgYW1iaXRpb3VzIGlkZWEgb2YgJnF1b3Q7dHJ1c3QmcXVvdDs/Jm5ic3A7PC9zcGFuPjxzcGFu
IGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+
Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90OyI+RmluYWxseSwgSSdkIGxpa2UgdG8gdGhyb3cgaW4gbXkgYWJpZGlu
ZyBjb25jZXJuIHRoYXQgTE9BcyBoYXZlIGZvdW5kZXJlZCBzaW1wbHkgYmVjYXVzZSBpdCdzIGRp
ZmZpY3VsdCB0byBwaWdlb25ob2xlIHJpc2suIE9uZSBwYXJ0eSdzIGlkZWEgb2YgJnF1b3Q7bWVk
aXVtJnF1b3Q7IHJpc2sgZm9yDQogaW5zdGFuY2Ugd2lsbCByYXJlbHkgbWFwIHByZWNpc2VseSB0
byBhbm90aGVyJ3MuIEkgdGhpbmsgcGVvcGxlIGhhdmUgYmVlbiBtaXNsZWQgaW50byB0aGlua2lu
ZyB0aGF0IGFuICZxdW90O0xPQSAzJnF1b3Q7IGlkZW50aXR5IHNob3VsZCBiZSBiZSBhYmxlIHRv
IGJlIHVzZWQgb24gaXRzIGZhY2UgKGkuZS4gd2lsbCAmcXVvdDtpbnRlcm9wZXJhdGUmcXVvdDsp
IGF0IGFueSAmcXVvdDtMT0EgMyZxdW90OyBSUC4gUmlzayBtYW5hZ2VtZW50IGlzIG5vdCBzbyBz
aW1wbGUuJm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1D
QSIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VGhlIExPQSBwYXJhZGln
bSBib3Jyb3dzIGZyb20gUmlzayBNYW5hZ2VtZW50IHN0YW5kYXJkcyBsaWtlIElTTyAzMTAwMCB3
aGljaCZuYnNwO29yZ2FuaXNhdGlvbnMgdXNlIHRvJm5ic3A7cGxvdCZuYnNwO3RoZWlyIG93biBy
aXNrcyBpbnRlcm5hbGx5IHR5cGljYWxseSBvbiBhIGZpdmUgc2NhbGUgKGVnDQogTmVnbGlnaWJs
ZSAvIExvdyAvIE1lZGl1bSAvIEhpZ2ggLyBHcmF2ZSkuJm5ic3A7QnV0Jm5ic3A7cmlzayBtYW5h
Z2VtZW50Jm5ic3A7c3RhbmRhcmRzIHJlcXVpcmUgdGhhdCBlYWNoIG9yZ2FuaXNhdGlvbiBjYWxp
YnJhdGVzIHJpc2sgaW4gaXRzIG93biBidXNpbmVzcyBjb250ZXh0IGFuZCBhY2NvcmRpbmcgdG8g
aXRzJm5ic3A7b3duIHJpc2sgYXBwZXRpdGUuIFRoZSByaXNrIG9mIGEgZmlyZXdhbGwgYnJlYWNo
IGZvciBleGFtcGxlIGF0IGEgc3RhcnR1cCBzb2NpYWwgbWVkaWENCiBjb21wYW55IHdpbGwgYmUg
YXNzZXNzZWQgZGlmZmVyZW50bHkgYnkgYSBiaWcgbGlzdGVkIGhlYWx0aGNhcmUgY29tcGFueS4m
bmJzcDtTbyBvcmdhbmlzYXRpb24gQSZuYnNwO2NhbiBzYXkgdGhlIHJpc2sgb2YgZXZlbnQgWCBp
cyBMb3cgYnV0IEIgY2FuIHNheSB0aGUgcmlzayBvZiB0aGUgc2FtZSBldmVudCBpcyBNZWRpdW0u
Jm5ic3A7IEFzJm5ic3A7YSByZXN1bHQsIExPQXMgZG8gbm90IGludGVyLW9wZXJhdGUuIFRoZXkg
YXJlIGJhc2VkIG9uIHN0YW5kYXJkcyBtZWFudCBmb3INCiBpbnRyYS1vcmdhbmlzYXRpb24gcmlz
ayBtYW5hZ2VtZW50LCBub3QgaW50ZXItb3JnYW5pc2F0aW9uIGNvbW11bmljYXRpb24gb2YmbmJz
cDtyaXNrIGFzc2Vzc21lbnRzLiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48
L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBs
YW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlNv
IGZhciB3aXRoIFZvVCB3ZSBhcmUgYWRkaW5nIG1vcmUgZGltZW5zaW9ucyB0byB0aGUgUlBzJyBn
ZW5lcmljIHJpc2sgbWFuYWdlbWVudCBkZWNpc2lvbiBtYWtpbmcsIGFuZCB0aGF0J3MgZ3JlYXQu
Jm5ic3A7IEJ1dCB3ZSBhcmUgc3RpbGwgcGlnZW9uaG9saW5nIHRoZSBkaW1lbnNpb25zLjwvc3Bh
bj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t
Q0EiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkknbSBhZnJhaWQgdGhlIHJlYWxpdHkgaXMgdGhhdCBy
aXNrIG1hbmFnZW1lbnQgd2lsbCBhbHdheXMgYmUgZG9uZSBsb2NhbGx5LiZuYnNwOyBBbmQgc28g
aXQgc2hvdWxkIGJlLiZuYnNwOyBXaGVuIGFuIFJQIGlzIG1ha2luZyZuYnNwO3RoZSBkZWNpc2lv
biB0byBhY2NlcHQgb3IgcmVqZWN0IGEgZ2l2ZW4NCiBzdWJqZWN0LCB0aGV5IHdpbGwgZXZhbHVh
dGUgYSByYW5nZSBvZiBhdHRyaWJ1dGVzIG9yJm5ic3A7c2lnbmFscy4mbmJzcDsgVGhlIHNldCBv
ZiBhdHRyaWJ1dGVzIHRoYXQgbWF0dGVycyB2YXJpZXMgZnJvbSBvbmUgUlAgdG8gdGhlIG5leHQu
Jm5ic3A7IEkgdGhpbmsgaXQncyBhIGdyZWF0IGlkZWEgaW5kZWVkIHRvIGNyZWF0ZSBndWlkYW5j
ZSBmb3IgZXZhbHVhdGluZyBhdHRyaWJ1dGVzLCBhbmQgdG8gY29hY2ggUlBzIHRvIGxvb2sgYXQg
YWxsIHNvcnRzIG9mIGRpbWVuc2lvbnMuJm5ic3A7DQogSSBqdXN0IGRvbid0IHRoaW5rIGl0IGhl
bHBzIGFueW9uZSB0byBwaWdlb25ob2xlIHRoZSByaXNrIHJhdGluZ3MsIGJlY2F1c2UgYWNyb3Nz
IG9yZ2FuaXNhdGlvbnMsIGFyZ3VtZW50cyBhYm91dCB0aGUgYm91bmRhcmllcyBiZXR3ZWVuIExP
QSAxLzIvMy80ICh0aGF0IGlzLCBwb2xpY3kgbWFwcGluZykgd2lsbCZuYnNwO3VuZG8gYW55IGVm
ZmljaWVuY2llcyBnYWluZWQgZnJvbSB0aGUgY2F0ZWdvcml6YXRpb24uICZuYnNwOzwvc3Bhbj48
c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0Ei
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDsiPkNoZWVycywmbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4t
Q0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3Nw
YW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7Ij5TdGV2ZS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO
LUNBIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0Ei
PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+
PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7Ij5TdGVwaGVuIFdpbHNvbjxicj4NCk1hbmFnaW5nIERpcmVjdG9yPGJyPg0KTG9ja3N0ZXAg
R3JvdXA8YnI+DQo8YSBocmVmPSJodHRwOi8vbG9ja3N0ZXAuY29tLmF1LyIgdGFyZ2V0PSJfYmxh
bmsiPmh0dHA6Ly9sb2Nrc3RlcC5jb20uYXU8L2E+PGJyPg0KTG9ja3N0ZXAgQ29uc3VsdGluZyBw
cm92aWRlcyBpbmRlcGVuZGVudCBzcGVjaWFsaXN0IGFkdmljZSBhbmQgYW5hbHlzaXMgPGJyPg0K
b24gZGlnaXRhbCBpZGVudGl0eSBhbmQgcHJpdmFjeS4gTG9ja3N0ZXAgVGVjaG5vbG9naWVzIGRl
dmVsb3BzIHVuaXF1ZSA8YnI+DQpuZXcgc21hcnQgSUQgc29sdXRpb25zIHRoYXQgZW5oYW5jZSBw
cml2YWN5IGFuZCBwcmV2ZW50IGlkZW50aXR5IHRoZWZ0Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1D
QSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bh
bj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t
Q0EiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+
PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X188YnI+DQp2b3QgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnZvdEBpZXRmLm9y
ZyI+dm90QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h
aWxtYW4vbGlzdGluZm8vdm90Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L3ZvdDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_147EE18440E5AF44834B220ED35BA530D32F0A2EWLGPRDMBX01diag_--


From nobody Sun Oct 12 14:40:48 2014
Return-Path: 
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 559FC1A90FD for ; Sun, 12 Oct 2014 14:40:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.301
X-Spam-Level: *
X-Spam-Status: No, score=1.301 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpGBWTnu4b_n for ; Sun, 12 Oct 2014 14:40:43 -0700 (PDT)
Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88F061A9106 for ; Sun, 12 Oct 2014 14:40:43 -0700 (PDT)
Received: by mail-vc0-f173.google.com with SMTP id ij19so4994217vcb.4 for ; Sun, 12 Oct 2014 14:40:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=blvf+VR5R5MDK/WWRze6Yon2dvhlmosFhzhHRXsdmVQ=; b=cBaAbFZNw7bo2sMdpY85bE+y75glbP3N5F2x8vCAzP6B4SdhE6n9LFWKMyO6KUa8c3 sPJ9hNrWKJwvOPWA1t6HXFiLNWqOHbhHGNc+46BWsPWk9Zw+EShy4WJ2fnVOmUmnQ2g9 UVba3UPm3az8WuXrMLTiNQjuNVUjdzTYoNC2SVGNO1nAu3fo+t5I9Nnt05A6QVx96P+1 7yQk6E+NY83gSARXLdla7gdnGVZLekx0ZjYNDvZJSwZkZwbh5Aq73WqEcL9U5I6OSeGh shgqowP8nFMkiMPY+afGFThU0zk2zqiz9gx/xbNIaU4vegbhP5ZsdrN8lKAGCYItNCgO 4N0g==
MIME-Version: 1.0
X-Received: by 10.220.100.10 with SMTP id w10mr16978790vcn.2.1413150042482; Sun, 12 Oct 2014 14:40:42 -0700 (PDT)
Received: by 10.220.88.199 with HTTP; Sun, 12 Oct 2014 14:40:42 -0700 (PDT)
In-Reply-To: <147EE18440E5AF44834B220ED35BA530D32F0A2E@WLGPRDMBX01.dia.govt.nz>
References: <1412885935.58929166@apps.rackspace.com>  <20141010145142.51DBE1A90E3@ietfa.amsl.com> <6A0CFC85-F8F5-43F5-B02F-09720E7164F4@mitre.org> <147EE18440E5AF44834B220ED35BA530D32F0A2E@WLGPRDMBX01.dia.govt.nz>
Date: Sun, 12 Oct 2014 17:40:42 -0400
Message-ID: 
From: Ken Dagg 
To: Colin Wallis 
Content-Type: multipart/alternative; boundary=001a11c2dba44bee26050540a2a1
Archived-At: http://mailarchive.ietf.org/arch/msg/vot/SydIR4lBUBo1Rc3dvgRkoTElxC0
Cc: "vot@ietf.org" 
Subject: Re: [VoT] Foundational questions of principle
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Vectors of Trust discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 12 Oct 2014 21:40:47 -0000

--001a11c2dba44bee26050540a2a1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Colin,

Good point to move the thread back to its original topic.

I would suggest that there is one more vector: token proofing. This vector
would be similar in nature to the identity proofing vector only focused on
the token rather than the identity.

I have not had a chance to review the original paper to know what it says
about the other vectors (I am supposed to be on holidays). I am assuming
that Identity Proofing deals with how an Identity is proofed, Credential
Strength deals with the binding of an identity to a token, and Assertion
Presentation deals with what the IdP goes through in order to issue an
assertion. What I believe is interesting is that these vectors are
applicable to any entity that does the work. What is of potential interest
is how they apply to the entity that is the recipient of the output of the
work.

I agree that Operational Management is an interesting, but extremely
important, vector that could have many sub-vectors.

While the LoA discussion seemed to be off track, I would suggest that it is
part of the discussion because LoA (regardless of how many levels) should
be a measure of and a means of communicating how much effort has undertaken
by the party doing the work to the entity that is receiving the output of
that work.

Ken


On Sunday, October 12, 2014, Colin Wallis  wrote:

>  Putting this split, back into one thread..
>
> =E2=80=A6  and pleading to folks to focus back on the vectors, or aspects=
, or
> =E2=80=98things=E2=80=99 - whatever we call them =E2=80=93 that the RP ha=
s an interest in.
>
> Justin is valiantly trying to re-state the purpose of his opening
> =E2=80=98vectors=E2=80=99 strawman =E2=80=93 always useful to refresh one=
=E2=80=99s memory by going back to
> look at them...
>
> His starting list of vectors was:
>
> Identity Proofing
>
> Credential Strength
>
> Assertion Presentation
>
> Operational Management
>
>
>
> If the discussion on LoAs offers any value here, it would be to add some
> finer grained addition to the above (fairly coarse-grained) list.
>
>
>
> There=E2=80=99s already an acknowledgment that Operational Management may=
 be
> composed of a range of concerns =E2=80=93 a mix of context dependent, tem=
poral and
> static (more vectors?) =E2=80=93 that influence the RP=E2=80=99s decision=
 to accept or
> otherwise, an authenticated identity.
>
>
>
> If we got to a point where we could agree on what these vectors are, then
> we can have the (separate) debate about whether combining them/delineatin=
g
> them in some way is useful/helpful, or not.
>
>
>
> Cheers
>
> Colin
>
>
>
> *From:* vot [mailto:vot-bounces@ietf.org
> ] *On Behalf Of *Ri=
cher,
> Justin P.
> *Sent:* Saturday, 11 October 2014 6:29 a.m.
> *To:* Bouma, Tim
> *Cc:* Ken Dagg; vot@ietf.org
> ; swilson@lockstep.com.au
> 
> *Subject:* Re: [VoT] Foundational questions of principle
>
>
>
> What we're trying to do with the "Vectors" approach here is to strike a
> balance between the overly-simplistic "single set of linear levels"
> approach that LoA gives us (that nobody on this list likes but all agree
> that apps can actually do some level of processing with it) and the
> overly-complex "very long complex set of attributes" approach that Tim,
> Scott, and others have brought up (that seems more expressive and ideal b=
ut
> no app is ever going to make sense of, or even try to). I think it's safe
> to say that neither extreme works and that a right answer probably lies i=
n
> the middle.
>
>
>
> So that's what this strawman is -- it's simultaneously less complex and
> more complex than the alternatives. Is it the right cut? Probably not, bu=
t
> it's at least a cutting point that we can push to either side. What I thi=
nk
> we need to dutifully avoid is pushing it hard to either end. I really lik=
e
> the notion that even if the combinations of the vector values aren't
> directly compatible (as Steve says), then the building blocks would at
> least be comparable, giving a hope of defining a policy to translate
> between them when needed.
>
>
>
> Also, I wanted to key into the fact that there are several independent an=
d
> orthogonal components here. Maybe it's not a set of levels that are tied
> together, but I think it is in someway a set of independent *things* that
> are tied together.
>
>
>
>  -- Justin
>
> =E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=
=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=
=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6.
>
>
>
> It may make sense to look at LOAs as something that is "coarse-grained"
> and a starting point.
>
>
>
> We all think it is not enough, but in the absence of the Borg showing up
> to enforce a collective hive-mind across organizational boundaries, we ca=
n
> live with it and use it as a starting point for the discussion "What more
> do we need in order to let this person in the door?"
>
>
>
> And that is where RP implemented compensating controls can play a part.
> The challenge is that folks seem to conflate "things needed to ensure
> confidence in an identity" with "things needed to mitigate risk in the
> transaction" and who is (CSP or RP) responsible for what.
>
>
>
> Regards,
>
>
>
> - Anil
>
>
>
> :- Anil John
>
> :- Making Digital Services Secure and Trustworthy
>
> :- https://blog.aniljohn.com
>
>
>
>
>
> On Fri, Oct 10, 2014 at 11:02 PM,  > wrote:
>
>
> We are all agreed of course that RPs need to understand their risks,
> determine what's needed from any external process of identification or
> attribute attestation, communicate those needs to candidate APs, and from
> there, contract an acceptable provider.
>
> My question is whether or not a pigeonholed LOA helps at any point in thi=
s
> process.
>
> The devil is in the detail.  To my mind, LOA is an intermediate step that
> takes a detailed risk analysis, squeezes it into a bin (losing lots of
> information as a result), which is then used to shortlist candidate
> providers, before going into detailed due diligence where all those detai=
ls
> need to be put back on the table.
>
> I think we all know by now of cases where RPs have looked at candidate
> IdPs at a given LOA, and have come up with the request of "LOA two and a
> half" (this was mentioned at CIS 2014 more than once, and I have seen it
> first hand in the UK IDAP).
>
> Clearly what's going on here is an RP's idea of say "LOA 2" differs from =
a
> given IdP's idea of LOA 2.  Moreover, the idea of LOA 2 must differ from
> one IdP to another IdP.  When people ask for "LOA 2.5" what they're askin=
g
> for is a customised identification.  If LOA 2 isn't what it seems, then
> there cannot possibly be any such thing as a *standardised* LOA 2.5.  All
> we will get is fresh calls for "LOA 2.75 please".
>
> If RPs need to do detailed analysis of authentication needs, and get
> detailed verification of the actual ID proofing done by IdPs and APs, the=
n
> I just don't see any point attaching the LOA label along the way.  It's
> misleading.
>
> Cheers,
>
> Steve.
>
> Stephen Wilson
> Lockstep
> http://lockstep.com.au
> Lockstep Consulting provides independent specialist advice and analysis
> on digital identity and privacy.  Lockstep Technologies develops unique
> new smart ID solutions that enhance privacy and prevent identity theft.
>
>
>
> On Oct 10, 2014, at 10:51 AM, Bouma, Tim  > wrote:
>
>
>
>  I agree with Ken,
>
>
>
> When we developed levels of assurance (here in Canada) we did several
> things:
>
>
>
> =C2=B7         We defined them as levels of confidence required (Levels 1
> through 4)
>
> =C2=B7         We mapped these levels of confidence to a range of degree =
of
> impacts.
>
> =C2=B7         We then specified separately identity assurance levels and
> credential assurance levels (and focused on credential first)
>
> =C2=B7         We also factored out likelihood in the assurance level
> assessment process. That made the assessments much less subjective.
>
>
>
> At the end of the day, as Ken states,  it=E2=80=99s the job the RP to und=
erstand
> their risk (along with likelihood) and to communicate a standardized
> requirement back to a provider (AP)
>
> The AP is  accountable for providing a very prescribed component that fit=
s
> into a larger system and a risk environment that they might not have a fu=
ll
> view into. The RP may put in provisions to share the risk with the AP, or
> not but that entirely depends on the arrangement, but at least the RP and
> AP understand what=E2=80=99s on the table as a starting point.
>
>
>
> In Canada, we did that with the credential first, and are now figuring ou=
t
> identity (much harder).
>
>
>
> I also agree that =E2=80=98identity=E2=80=99 is just a set of attributes =
=E2=80=93and  these
> identity attributes can vary between organizations or jurisdictions,
>
>
>
> As for the term =E2=80=98vectors=E2=80=99, I get the idea, but I think th=
e community will
> think it=E2=80=99s too technical or esoteric. I like to think of a =E2=80=
=98digital
> identity=E2=80=99 (or whatever you call it), when it shows up at your dig=
ital front
> door, it is the product of a very long, complex supply chain, fraught wit=
h
> many risks and compromises. I may have confidence in certain pieces of, b=
ut
> other I might not trust at all.
>
>
>
>
>
> Tim
>
>
>
>
>
> *From:* vot [mailto:vot-bounces@ietf.org
> ] *On Behalf Of *Ke=
n
> Dagg
> *Sent:* October-09-14 9:42 PM
> *To:* swilson@lockstep.com.au
> 
> *Cc:* vot@ietf.org 
> *Subject:* Re: [VoT] Foundational questions of principle
>
>
>
> Steve,
>
>
>
> As we have communicated in the past, I am a strong believer the an LOA
> designation is an indication of the processes/mechanisms that an IdP has
> undertaken. In other words, it is a communication tool. The choice is the
> RPs. That is, an assertion at a specific LOA by an IdP/CSP/AP is one of t=
he
> mechanisms a RP should use to offset the authentication risk it has
> identified for the service it wants to deliver. In other words, it is the
> risk of the RP that is paramount not the claims of
> an identity/credential/attribute/token provider.
>
>
>
> Like you, I am a strong believer that the determination of whether or not
> an identity is good enough is the responsibility of the RP. In my
> experience, they make that determination based upon a set of attributes
> they believe are necessary. If they trust that an IdP's assertion of
> identity covers the attributes they believe are required them they can
> accept the assertion. If it doesn't then that have to implement additiona=
l
> mechanisms to offset the residual risk.
>
>
>
> With respect to vectors of trust, I am interested in exploring what they
> are and how they can be applied.
>
>
>
> Ken
>
> On Thursday, October 9, 2014,  > wrote:
>
>
>
> First, to introduce myself, I am an identity and privacy researcher,
> analyst and consultant.  I've been involved in this since 1995, when I cu=
t
> my teeth in PKI and smartcards (with the early companies that became
> Baltimore Technologies). Since then I've worked on identity management
> frameworks, regulations and standards.
>
>
>
> I subscribe to the old Italian proverb: "it's nice to trust but better no=
t
> to".  Words matter and I wonder if we shouldn't be using the word trust s=
o
> much.
>
>
>
> More pragmatically, I note the very strong "Attributes" push of the past
> 18 months.  Andrew Nash, Anil John, myself and others have written about
> this.  The FIDO Alliance is all about authentication and attributes, and
> they purposefully leave "identity" as a matter for others to work out
> further up the stack. The OID Foundation is promoting an Attributes
> Exchange Network "AXN" architecture.  New entrants like id.me (an NSTIC
> pilot participant) talk about attributes and avoid "identity".
>
>
>
> I mention all of this as a prelude to suggest that "vector of trust" is
> synonymous with "attribute". I wonder if it would be clearer to use plain
> and current language rather than carry forward the fuzzy and I think over=
ly
> ambitious idea of "trust"?
>
>
>
> Finally, I'd like to throw in my abiding concern that LOAs have foundered
> simply because it's difficult to pigeonhole risk. One party's idea of
> "medium" risk for instance will rarely map precisely to another's. I thin=
k
> people have been misled into thinking that an "LOA 3" identity should be =
be
> able to be used on its face (i.e. will "interoperate") at any "LOA 3" RP.
> Risk management is not so simple.
>
>
>
> The LOA paradigm borrows from Risk Management standards like ISO 31000
> which organisations use to plot their own risks internally typically on a
> five scale (eg Negligible / Low / Medium / High / Grave). But risk
> management standards require that each organisation calibrates risk in it=
s
> own business context and according to its own risk appetite. The risk of =
a
> firewall breach for example at a startup social media company will be
> assessed differently by a big listed healthcare company. So organisation
> A can say the risk of event X is Low but B can say the risk of the same
> event is Medium.  As a result, LOAs do not inter-operate. They are based =
on
> standards meant for intra-organisation risk management, not
> inter-organisation communication of risk assessments.
>
>
>
> So far with VoT we are adding more dimensions to the RPs' generic risk
> management decision making, and that's great.  But we are still
> pigeonholing the dimensions.
>
>
>
> I'm afraid the reality is that risk management will always be done
> locally.  And so it should be.  When an RP is making the decision to acce=
pt
> or reject a given subject, they will evaluate a range of attributes
> or signals.  The set of attributes that matters varies from one RP to the
> next.  I think it's a great idea indeed to create guidance for evaluating
> attributes, and to coach RPs to look at all sorts of dimensions.  I just
> don't think it helps anyone to pigeonhole the risk ratings, because acros=
s
> organisations, arguments about the boundaries between LOA 1/2/3/4 (that i=
s,
> policy mapping) will undo any efficiencies gained from the categorization=
.
>
>
>
> Cheers,
>
>
>
> Steve.
>
>
>
>
>
> Stephen Wilson
> Managing Director
> Lockstep Group
> http://lockstep.com.au
> Lockstep Consulting provides independent specialist advice and analysis
> on digital identity and privacy. Lockstep Technologies develops unique
> new smart ID solutions that enhance privacy and prevent identity theft.
>
>
>
>
>
>
>
> _______________________________________________
> vot mailing list
> vot@ietf.org 
> https://www.ietf.org/mailman/listinfo/vot
>
>
>

--001a11c2dba44bee26050540a2a1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Colin,

Good point to move the thread back to its origina=
l topic.

I would suggest that there is one more ve=
ctor: token proofing. This vector would be similar in nature to the identit=
y proofing vector only focused on the token rather than the identity.
=


I=C2=A0have not had a chance to review the original pap=
er to know what it says about the other vectors (I am supposed=C2=A0to be o=
n holidays). I am assuming that Identity Proofing deals with how an Identit=
y is proofed,=C2=A0Credential Strength deals with the binding of an identit=
y to a=C2=A0token, and=C2=A0Assertion Presentation deals with what the IdP =
goes through in order to issue an assertion. What I believe is interesting =
is that these vectors are applicable to any entity that does the work. What=
 is of potential interest is how they apply to the entity that is the recip=
ient of the output of the work.

I agree that Operational Management =
is an interesting, but extremely important,=C2=A0vector that could have man=
y sub-vectors.

While the LoA discussion seemed to =
be off track, I would suggest that it is part of the discussion because LoA=
 (regardless of how many levels)=C2=A0should be a measure of and a means of=
 communicating how much effort has undertaken by the party doing the work t=
o the entity that is receiving the output of that work.

Ken


On Sunday, October 12, 2014, Colin Wallis <Colin.Wallis@dia.govt.nz> wrote=
:











Putting this split, back =
into one thread..


=E2=80=A6 =C2=A0and plead=
ing to folks to focus back on the vectors, or aspects, or =E2=80=98things=
=E2=80=99 - whatever we call them =E2=80=93 that the RP has an interest in.



Justin is valiantly tryin=
g to re-state the purpose of his opening =E2=80=98vectors=E2=80=99 strawman=
 =E2=80=93 always useful to refresh one=E2=80=99s memory by going back to l=
ook at them...


His starting list of vect=
ors was:



Identity Proofing<=
u>


Credential Strength


Assertion Presentation=



Operational Management=



=C2=A0


If the discussion on LoAs=
 offers any value here, it would be to add some finer grained addition to t=
he above (fairly coarse-grained) list.


=C2=A0


There=E2=80=99s already a=
n acknowledgment that Operational Management may be composed of a range of =
concerns =E2=80=93 a mix of context dependent, temporal and static (more
 vectors?) =E2=80=93 that influence the RP=E2=80=99s decision to accept or =
otherwise, an authenticated identity.


=C2=A0=C2=A0=C2=A0=C2=A0<=
u>


If we got to a point wher=
e we could agree on what these vectors are, then we can have the (separate)=
 debate about whether combining them/delineating them in
 some way is useful/helpful, or not.


=C2=A0


Cheers


Colin



=C2=A0






From: vot [mailto:vot-bounces@ietf.=
org]
On Behalf Of Richer, Justin P.

Sent: Saturday, 11 October 2014 6:29 a.m.

To: Bouma, Tim

Cc: Ken Dagg; vot@ietf.org; swilson@lockstep.com.au

Subject: Re: [VoT] Foundational questions of principle=







=C2=A0


What we're trying to do with the "Vectors&q=
uot; approach here is to strike a balance between the overly-simplistic &qu=
ot;single set of linear levels" approach that LoA gives us (that nobod=
y on this list likes but all agree that apps can actually
 do some level of processing with it) and the overly-complex "very lon=
g complex set of attributes" approach that Tim, Scott, and others have=
 brought up (that seems more expressive and ideal but no app is ever going =
to make sense of, or even try to). I think
 it's safe to say that neither extreme works and that a right answer pr=
obably lies in the middle.=C2=A0





=C2=A0






So that's what this strawman is -- it's simu=
ltaneously less complex and more complex than the alternatives. Is it the r=
ight cut? Probably not, but it's at least a cutting point that we can p=
ush to either side. What I think we need to dutifully
 avoid is pushing it hard to either end. I really like the notion that even=
 if the combinations of the vector values aren't directly compatible (a=
s Steve says), then the building blocks would at least be comparable, givin=
g a hope of defining a policy to translate
 between them when needed.=C2=A0






=C2=A0






Also, I wanted to key into the fact that there are s=
everal independent and orthogonal components here. Maybe it's not a set=
 of levels that are tied together, but I think it is in someway a set of in=
dependent *things* that are tied together.






=C2=A0






=C2=A0-- Justin


=E2=80=A6=E2=80=A6=E2=80=
=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=
=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=
=80=A6=E2=80=A6=E2=80=A6.


=C2=A0


It may make sense to look at LOAs as something that =
is "coarse-grained" and a starting point.=C2=A0


=C2=A0


We all think it is not enough, but in the absence of=
 the Borg showing up to enforce a collective hive-mind across organizationa=
l boundaries, we can live with it and use it as a starting point for the di=
scussion "What more do we need in
 order to let this person in the door?"


=C2=A0


And that is where RP implemented compensating contro=
ls can play a part. The challenge is that folks seem to conflate "thin=
gs needed to ensure confidence in an identity" with "things neede=
d to mitigate risk in the transaction" and who is
 (CSP or RP) responsible for what.


=C2=A0


Regards,


=C2=A0


- Anil


=C2=A0


:- Anil John


:- Making Digital Services Secure and Trustworthy=



:- https://blog.aniljohn.com


=C2=A0


=C2=A0


On Fri, Oct 10, 2014 at 11:02 PM, <swilson@lockstep.com.au> wrote:




We are all agreed of course that RPs need to understand their risks, determ=
ine what's needed from any external process of identification or attrib=
ute attestation, communicate those needs to candidate APs, and from there, =
contract an acceptable provider.



My question is whether or not a pigeonholed LOA helps at any point in this =
process.



The devil is in the detail.=C2=A0 To my mind, LOA is an intermediate step t=
hat takes a detailed risk analysis, squeezes it into a bin (losing lots of =
information as a result), which is then used to shortlist candidate provide=
rs, before going into detailed due diligence
 where all those details need to be put back on the table.



I think we all know by now of cases where RPs have looked at candidate IdPs=
 at a given LOA, and have come up with the request of "LOA two and a h=
alf" (this was mentioned at CIS 2014 more than once, and I have seen i=
t first hand in the UK IDAP).



Clearly what's going on here is an RP's idea of say "LOA 2&quo=
t; differs from a given IdP's idea of LOA 2.=C2=A0 Moreover, the idea o=
f LOA 2 must differ from one IdP to another IdP.=C2=A0 When people ask for =
"LOA 2.5" what they're asking for is a customised identificat=
ion.=C2=A0
 If LOA 2 isn't what it seems, then there cannot possibly be any such t=
hing as a *standardised* LOA 2.5.=C2=A0 All we will get is fresh calls for =
"LOA 2.75 please".



If RPs need to do detailed analysis of authentication needs, and get detail=
ed verification of the actual ID proofing done by IdPs and APs, then I just=
 don't see any point attaching the LOA label along the way.=C2=A0 It=
9;s misleading.



Cheers,



Steve.



Stephen Wilson

Lockstep

http://lockstep.com.au=


Lockstep Consulting provides independent specialist advice and analysis

on digital identity and privacy.=C2=A0 Lockstep Technologies develops uniqu=
e

new smart ID solutions that enhance privacy and prevent identity theft.










=C2=A0






On Oct 10, 2014, at 10:51 AM, Bouma, Tim <Tim.Bouma@tbs-sct.gc.ca> wrote:












I agree wi=
th Ken,


=C2=A0


When we de=
veloped levels of assurance (here in Canada) we did several things:<=
span lang=3D"EN-CA">


=C2=A0


=C2=B7=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0
We de=
fined them as levels of confidence required (Levels 1 through 4)


=C2=B7=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0
We ma=
pped these levels of confidence to a range of degree of impacts.


=C2=B7=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0
We th=
en specified separately identity assurance levels and credential assurance =
levels (and focused on credential first)=



=C2=B7=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0
We al=
so factored out likelihood in the assurance level assessment process. That =
made the assessments much less subjective.


=C2=A0


At the end=
 of the day, as Ken states, =C2=A0it=E2=80=99s the job the RP to understand=
 their risk (along with likelihood) and to communicate a standardized requi=
rement
 back to a provider (AP)

The AP is =
=C2=A0accountable for providing a very prescribed component that fits into =
a larger system and a risk environment that they might not have
 a full view into. The RP may put in provisions to share the risk with the =
AP, or not but that entirely depends on the arrangement, but at least the R=
P and AP understand what=E2=80=99s on the table as a starting point.=



=C2=A0


In Canada,=
 we did that with the credential first, and are now figuring out identity (=
much harder).


=C2=A0


I also agr=
ee that =E2=80=98identity=E2=80=99 is just a set of attributes =E2=80=93and=
 =C2=A0these identity attributes can vary between organizations or jurisdic=
tions,


=C2=A0


As for the=
 term =E2=80=98vectors=E2=80=99, I get the idea, but I think the community =
will think it=E2=80=99s too technical or esoteric. I like to think of a =E2=
=80=98digital identity=E2=80=99
 (or whatever you call it), when it shows up at your digital front door, it=
 is the product of a very long, complex supply chain, fraught with many ris=
ks and compromises. I may have confidence in certain pieces of, but other I=
 might not trust at all.

=C2=A0


=C2=A0


Tim=



=C2=A0


=C2=A0


From: vot [mailto:vot-bounces@ietf.org]
On Behalf Of Ken Dagg

Sent: October-09-14 9:42 PM

To: swilson@lockstep.com.au

Cc: vot@ietf.org

Subject: Re: [VoT] Foundational questions of principle


=C2=A0


Steve,




=C2=A0






As we have communicated in=C2=
=A0the past, I am a strong believer the an LOA designation is an indication=
 of the processes/mechanisms that an=C2=A0IdP has undertaken. In other word=
s, it is a communication tool.=C2=A0The choice is the
 RPs. That is, an=C2=A0assertion at a specific LOA by an=C2=A0IdP/CSP/AP=C2=
=A0is one of the mechanisms a RP should use to offset the authentication ri=
sk it has identified for the service it wants to deliver. In other words, i=
t is the risk of the RP that is paramount not the
 claims of an=C2=A0identity/credential/attribute/token provider.<=
/u>






=C2=A0






Like you, I am a strong believe=
r that the determination of whether or not an identity is good enough is th=
e responsibility of the RP. In my experience, they make that determination =
based upon a set of attributes they
 believe are necessary. If they trust that an IdP's assertion of identi=
ty covers the attributes they believe are=C2=A0required them they can accep=
t the assertion. If it doesn't then that have to implement additional m=
echanisms to offset the residual risk.






=C2=A0






With respect to vectors of trus=
t, I am interested in exploring what they are and how they can be applied.<=
u>






=C2=A0






Ken



On Thursday, October 9, 2014, <swilson@lockst=
ep.com.au> wrote:




=C2=A0






First, to introduce myself=
, I am an identity and privacy researcher, analyst and consultant.=C2=A0 I&=
#39;ve been involved in this since 1995, when I cut my teeth in PKI
 and smartcards (with the early companies that became Baltimore Technologie=
s). Since then I've worked on identity management frameworks, regulatio=
ns and standards. =C2=A0





=C2=A0






I subscribe to the old Ita=
lian proverb: "it's nice to trust but better not to".=C2=A0 W=
ords matter and I wonder if we shouldn't be using the word trust so muc=
h. =C2=A0






=C2=A0






More pragmatically, I note=
 the very strong "Attributes" push of the past 18 months.=C2=A0 A=
ndrew Nash, Anil John, myself and others have written about this.=C2=A0 The=
 FIDO
 Alliance is all about authentication and attributes, and they purposefully=
 leave "identity" as a matter for others to work out further up t=
he stack. The OID Foundation is promoting an Attributes Exchange Network &q=
uot;AXN" architecture.=C2=A0 New entrants like
id.me (an NSTIC pilot parti=
cipant) talk about attributes and avoid "identity".=C2=A0<=
span lang=3D"EN-CA">






=C2=A0






I mention all of this as a=
 prelude to suggest that "vector of trust" is synonymous with &qu=
ot;attribute". I wonder if it would be clearer to use plain and curren=
t language
 rather than carry forward the fuzzy and I think overly ambitious idea of &=
quot;trust"?=C2=A0





=C2=A0






Finally, I'd like to t=
hrow in my abiding concern that LOAs have foundered simply because it's=
 difficult to pigeonhole risk. One party's idea of "medium" r=
isk for
 instance will rarely map precisely to another's. I think people have b=
een misled into thinking that an "LOA 3" identity should be be ab=
le to be used on its face (i.e. will "interoperate") at any "=
;LOA 3" RP. Risk management is not so simple.=C2=A0






=C2=A0






The LOA paradigm borrows f=
rom Risk Management standards like ISO 31000 which=C2=A0organisations use t=
o=C2=A0plot=C2=A0their own risks internally typically on a five scale (eg
 Negligible / Low / Medium / High / Grave).=C2=A0But=C2=A0risk management=
=C2=A0standards require that each organisation calibrates risk in its own b=
usiness context and according to its=C2=A0own risk appetite. The risk of a =
firewall breach for example at a startup social media
 company will be assessed differently by a big listed healthcare company.=
=C2=A0So organisation A=C2=A0can say the risk of event X is Low but B can s=
ay the risk of the same event is Medium.=C2=A0 As=C2=A0a result, LOAs do no=
t inter-operate. They are based on standards meant for
 intra-organisation risk management, not inter-organisation communication o=
f=C2=A0risk assessments.=C2=A0






=C2=A0






So far with VoT we are add=
ing more dimensions to the RPs' generic risk management decision making=
, and that's great.=C2=A0 But we are still pigeonholing the dimensions.=







=C2=A0






I'm afraid the reality=
 is that risk management will always be done locally.=C2=A0 And so it shoul=
d be.=C2=A0 When an RP is making=C2=A0the decision to accept or reject a gi=
ven
 subject, they will evaluate a range of attributes or=C2=A0signals.=C2=A0 T=
he set of attributes that matters varies from one RP to the next.=C2=A0 I t=
hink it's a great idea indeed to create guidance for evaluating attribu=
tes, and to coach RPs to look at all sorts of dimensions.=C2=A0
 I just don't think it helps anyone to pigeonhole the risk ratings, bec=
ause across organisations, arguments about the boundaries between LOA 1/2/3=
/4 (that is, policy mapping) will=C2=A0undo any efficiencies gained from th=
e categorization. =C2=A0





=C2=A0






Cheers,=C2=A0






=C2=A0






Steve.






=C2=A0






=C2=A0






Stephen Wilson

Managing Director

Lockstep Group

http://lockstep.com.a=
u

Lockstep Consulting provides independent specialist advice and analysis 
on digital identity and privacy. Lockstep Technologies develops unique 

new smart ID solutions that enhance privacy and prevent identity theft.






=C2=A0






=C2=A0






=C2=A0








_______________________________________________

vot mailing list

vot@ietf.org

htt=
ps://www.ietf.org/mailman/listinfo/vot




=C2=A0











--001a11c2dba44bee26050540a2a1--


From nobody Sun Oct 12 16:23:20 2014
Return-Path: 
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3AC81A01A8 for ; Sun, 12 Oct 2014 16:23:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.301
X-Spam-Level: *
X-Spam-Status: No, score=1.301 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8o7LopWIINJ for ; Sun, 12 Oct 2014 16:23:15 -0700 (PDT)
Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 959BD1A0171 for ; Sun, 12 Oct 2014 16:23:14 -0700 (PDT)
Received: by mail-lb0-f177.google.com with SMTP id w7so5465054lbi.8 for ; Sun, 12 Oct 2014 16:23:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=BpZW2mzVkCdokIMqfYEGwMKtNtHuhJdH+1fFxF8yQSQ=; b=RAj7RvZNQVL43XCPOGxGvDAfkLbeTR25x/lIR8yT1Z6uoNPQMr34d1nxEgvYDGQv+j 6p+mn0ADjz3LfRNrYJdroHQBhjpz8zzbI3gUK9oEB3Y51E8v30y/DPKK1lsfTVnYCeUq 5x67/e3Cx5hL9dNIYobJPTsd+CZ1SQlW+zZ0YwlQ/9Zn77Q4gvUMugXcj3reJt5Rf3b9 Pa+RDSaWgtgyZvb43VrTpWeQoYrO/LvcRccxpvRwgfshlJ+trJx8HS/HnvVIfFbdNY9D eyah9Fmtng3blqF1YX3DcsIrg2msa0oPU+PC/HgjO8ZJa2HNJ5wKvOkSgICna+c/uF5f TtrA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=BpZW2mzVkCdokIMqfYEGwMKtNtHuhJdH+1fFxF8yQSQ=; b=kzpXNwebb378Da2di0ZCZ/vwNE4+FdcKKCH2JVbuBUtFjWQvBVWCnAp1NBdnnwjhy+ E3ksjB8ClXTXQDm2lQpZ6K7COZZZkPVl5tJZHHxdzKfhwXvK6UZRWpWt9k96140p+vvr vzZ1KrdL5X1QzDs5CQNX5r75sQCJ0peZl1TzkhA1ENUZD6Y3ixEXlr9FJy0pYsAlQX0e eZeypMiO7Ulo0CwPOeK1pWIGYPFw9VEjd7WwKTGEE8bG9d51DmhG89xXz5MwoHkDJdKS TWNVXUDapRrz0tTAFOfXZyRn0Ldf0RXG1ednQ4SCfa9vC2NFjrDyoaw4woarRexiWNmb 40JQ==
X-Received: by 10.112.125.131 with SMTP id mq3mr20211212lbb.20.1413156192795;  Sun, 12 Oct 2014 16:23:12 -0700 (PDT)
Received: from mail-la0-f52.google.com (mail-la0-f52.google.com [209.85.215.52]) by mx.google.com with ESMTPSA id w10sm4025506laz.28.2014.10.12.16.23.10 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 12 Oct 2014 16:23:10 -0700 (PDT)
Received: by mail-la0-f52.google.com with SMTP id hz20so5917473lab.11 for ; Sun, 12 Oct 2014 16:23:10 -0700 (PDT)
X-Gm-Message-State: ALoCoQmmpNhmphW5IrFc8UELlhodtLgXQpKaVB7p6dHZAF02wtNU7t5MMQbWvqE7H1iKqvzqe0kE
X-Received: by 10.152.36.195 with SMTP id s3mr20184902laj.81.1413156190546; Sun, 12 Oct 2014 16:23:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.213.72 with HTTP; Sun, 12 Oct 2014 16:22:30 -0700 (PDT)
In-Reply-To: <147EE18440E5AF44834B220ED35BA530D32F0A2E@WLGPRDMBX01.dia.govt.nz>
References: <1412885935.58929166@apps.rackspace.com>  <20141010145142.51DBE1A90E3@ietfa.amsl.com> <6A0CFC85-F8F5-43F5-B02F-09720E7164F4@mitre.org> <147EE18440E5AF44834B220ED35BA530D32F0A2E@WLGPRDMBX01.dia.govt.nz>
From: Anil John 
Date: Sun, 12 Oct 2014 19:22:30 -0400
Message-ID: 
To: "vot@ietf.org" 
Content-Type: multipart/alternative; boundary=089e0158aee8c0002005054210a6
Archived-At: http://mailarchive.ietf.org/arch/msg/vot/fQocQcDy_-88Dp6hNxO75J0C-KE
Subject: Re: [VoT] Foundational questions of principle
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Vectors of Trust discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 12 Oct 2014 23:23:19 -0000

--089e0158aee8c0002005054210a6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Thank you Colin for herding the cats (Including myself there)!

I would recommend splitting up the 'Identity Proofing' vector into its
component bits, rather than treating it like the current amorphous blob
that it is right now:


   1. *Identity Resolution* - Establishing the uniqueness of an individual
   within a population
   2. *Identity Validation* - Confirming the accuracy of identity
   information claimed by an individual
   3. *Identity Verification* - Confirming that the claimed identity
   information is linked to the individual making the claim


Regards,

- Anil

:- Anil John
:- Making Digital Services Secure and Trustworthy
:- https://blog.aniljohn.com


On Sun, Oct 12, 2014 at 3:16 PM, Colin Wallis 
wrote:

>  Putting this split, back into one thread..
>
> =E2=80=A6  and pleading to folks to focus back on the vectors, or aspects=
, or
> =E2=80=98things=E2=80=99 - whatever we call them =E2=80=93 that the RP ha=
s an interest in.
>
> Justin is valiantly trying to re-state the purpose of his opening
> =E2=80=98vectors=E2=80=99 strawman =E2=80=93 always useful to refresh one=
=E2=80=99s memory by going back to
> look at them...
>
> His starting list of vectors was:
>
> Identity Proofing
>
> Credential Strength
>
> Assertion Presentation
>
> Operational Management
>
>
>
> If the discussion on LoAs offers any value here, it would be to add some
> finer grained addition to the above (fairly coarse-grained) list.
>
>
>
> There=E2=80=99s already an acknowledgment that Operational Management may=
 be
> composed of a range of concerns =E2=80=93 a mix of context dependent, tem=
poral and
> static (more vectors?) =E2=80=93 that influence the RP=E2=80=99s decision=
 to accept or
> otherwise, an authenticated identity.
>
>
>
> If we got to a point where we could agree on what these vectors are, then
> we can have the (separate) debate about whether combining them/delineatin=
g
> them in some way is useful/helpful, or not.
>
>
>
> Cheers
>
> Colin
>
>
>
> *From:* vot [mailto:vot-bounces@ietf.org] *On Behalf Of *Richer, Justin P=
.
> *Sent:* Saturday, 11 October 2014 6:29 a.m.
> *To:* Bouma, Tim
> *Cc:* Ken Dagg; vot@ietf.org; swilson@lockstep.com.au
> *Subject:* Re: [VoT] Foundational questions of principle
>
>
>
> What we're trying to do with the "Vectors" approach here is to strike a
> balance between the overly-simplistic "single set of linear levels"
> approach that LoA gives us (that nobody on this list likes but all agree
> that apps can actually do some level of processing with it) and the
> overly-complex "very long complex set of attributes" approach that Tim,
> Scott, and others have brought up (that seems more expressive and ideal b=
ut
> no app is ever going to make sense of, or even try to). I think it's safe
> to say that neither extreme works and that a right answer probably lies i=
n
> the middle.
>
>
>
> So that's what this strawman is -- it's simultaneously less complex and
> more complex than the alternatives. Is it the right cut? Probably not, bu=
t
> it's at least a cutting point that we can push to either side. What I thi=
nk
> we need to dutifully avoid is pushing it hard to either end. I really lik=
e
> the notion that even if the combinations of the vector values aren't
> directly compatible (as Steve says), then the building blocks would at
> least be comparable, giving a hope of defining a policy to translate
> between them when needed.
>
>
>
> Also, I wanted to key into the fact that there are several independent an=
d
> orthogonal components here. Maybe it's not a set of levels that are tied
> together, but I think it is in someway a set of independent *things* that
> are tied together.
>
>
>
>  -- Justin
>
> =E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=
=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=
=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6.
>
>
>
> It may make sense to look at LOAs as something that is "coarse-grained"
> and a starting point.
>
>
>
> We all think it is not enough, but in the absence of the Borg showing up
> to enforce a collective hive-mind across organizational boundaries, we ca=
n
> live with it and use it as a starting point for the discussion "What more
> do we need in order to let this person in the door?"
>
>
>
> And that is where RP implemented compensating controls can play a part.
> The challenge is that folks seem to conflate "things needed to ensure
> confidence in an identity" with "things needed to mitigate risk in the
> transaction" and who is (CSP or RP) responsible for what.
>
>
>
> Regards,
>
>
>
> - Anil
>
>
>
> :- Anil John
>
> :- Making Digital Services Secure and Trustworthy
>
> :- https://blog.aniljohn.com
>
>
>
>
>
> On Fri, Oct 10, 2014 at 11:02 PM,  wrote:
>
>
> We are all agreed of course that RPs need to understand their risks,
> determine what's needed from any external process of identification or
> attribute attestation, communicate those needs to candidate APs, and from
> there, contract an acceptable provider.
>
> My question is whether or not a pigeonholed LOA helps at any point in thi=
s
> process.
>
> The devil is in the detail.  To my mind, LOA is an intermediate step that
> takes a detailed risk analysis, squeezes it into a bin (losing lots of
> information as a result), which is then used to shortlist candidate
> providers, before going into detailed due diligence where all those detai=
ls
> need to be put back on the table.
>
> I think we all know by now of cases where RPs have looked at candidate
> IdPs at a given LOA, and have come up with the request of "LOA two and a
> half" (this was mentioned at CIS 2014 more than once, and I have seen it
> first hand in the UK IDAP).
>
> Clearly what's going on here is an RP's idea of say "LOA 2" differs from =
a
> given IdP's idea of LOA 2.  Moreover, the idea of LOA 2 must differ from
> one IdP to another IdP.  When people ask for "LOA 2.5" what they're askin=
g
> for is a customised identification.  If LOA 2 isn't what it seems, then
> there cannot possibly be any such thing as a *standardised* LOA 2.5.  All
> we will get is fresh calls for "LOA 2.75 please".
>
> If RPs need to do detailed analysis of authentication needs, and get
> detailed verification of the actual ID proofing done by IdPs and APs, the=
n
> I just don't see any point attaching the LOA label along the way.  It's
> misleading.
>
> Cheers,
>
> Steve.
>
> Stephen Wilson
> Lockstep
> http://lockstep.com.au
> Lockstep Consulting provides independent specialist advice and analysis
> on digital identity and privacy.  Lockstep Technologies develops unique
> new smart ID solutions that enhance privacy and prevent identity theft.
>
>
>
> On Oct 10, 2014, at 10:51 AM, Bouma, Tim  wrote:
>
>
>
>  I agree with Ken,
>
>
>
> When we developed levels of assurance (here in Canada) we did several
> things:
>
>
>
> =C2=B7         We defined them as levels of confidence required (Levels 1
> through 4)
>
> =C2=B7         We mapped these levels of confidence to a range of degree =
of
> impacts.
>
> =C2=B7         We then specified separately identity assurance levels and
> credential assurance levels (and focused on credential first)
>
> =C2=B7         We also factored out likelihood in the assurance level
> assessment process. That made the assessments much less subjective.
>
>
>
> At the end of the day, as Ken states,  it=E2=80=99s the job the RP to und=
erstand
> their risk (along with likelihood) and to communicate a standardized
> requirement back to a provider (AP)
>
> The AP is  accountable for providing a very prescribed component that fit=
s
> into a larger system and a risk environment that they might not have a fu=
ll
> view into. The RP may put in provisions to share the risk with the AP, or
> not but that entirely depends on the arrangement, but at least the RP and
> AP understand what=E2=80=99s on the table as a starting point.
>
>
>
> In Canada, we did that with the credential first, and are now figuring ou=
t
> identity (much harder).
>
>
>
> I also agree that =E2=80=98identity=E2=80=99 is just a set of attributes =
=E2=80=93and  these
> identity attributes can vary between organizations or jurisdictions,
>
>
>
> As for the term =E2=80=98vectors=E2=80=99, I get the idea, but I think th=
e community will
> think it=E2=80=99s too technical or esoteric. I like to think of a =E2=80=
=98digital
> identity=E2=80=99 (or whatever you call it), when it shows up at your dig=
ital front
> door, it is the product of a very long, complex supply chain, fraught wit=
h
> many risks and compromises. I may have confidence in certain pieces of, b=
ut
> other I might not trust at all.
>
>
>
>
>
> Tim
>
>
>
>
>
> *From:* vot [mailto:vot-bounces@ietf.org ] *On
> Behalf Of *Ken Dagg
> *Sent:* October-09-14 9:42 PM
> *To:* swilson@lockstep.com.au
> *Cc:* vot@ietf.org
> *Subject:* Re: [VoT] Foundational questions of principle
>
>
>
> Steve,
>
>
>
> As we have communicated in the past, I am a strong believer the an LOA
> designation is an indication of the processes/mechanisms that an IdP has
> undertaken. In other words, it is a communication tool. The choice is the
> RPs. That is, an assertion at a specific LOA by an IdP/CSP/AP is one of t=
he
> mechanisms a RP should use to offset the authentication risk it has
> identified for the service it wants to deliver. In other words, it is the
> risk of the RP that is paramount not the claims of
> an identity/credential/attribute/token provider.
>
>
>
> Like you, I am a strong believer that the determination of whether or not
> an identity is good enough is the responsibility of the RP. In my
> experience, they make that determination based upon a set of attributes
> they believe are necessary. If they trust that an IdP's assertion of
> identity covers the attributes they believe are required them they can
> accept the assertion. If it doesn't then that have to implement additiona=
l
> mechanisms to offset the residual risk.
>
>
>
> With respect to vectors of trust, I am interested in exploring what they
> are and how they can be applied.
>
>
>
> Ken
>
> On Thursday, October 9, 2014,  wrote:
>
>
>
> First, to introduce myself, I am an identity and privacy researcher,
> analyst and consultant.  I've been involved in this since 1995, when I cu=
t
> my teeth in PKI and smartcards (with the early companies that became
> Baltimore Technologies). Since then I've worked on identity management
> frameworks, regulations and standards.
>
>
>
> I subscribe to the old Italian proverb: "it's nice to trust but better no=
t
> to".  Words matter and I wonder if we shouldn't be using the word trust s=
o
> much.
>
>
>
> More pragmatically, I note the very strong "Attributes" push of the past
> 18 months.  Andrew Nash, Anil John, myself and others have written about
> this.  The FIDO Alliance is all about authentication and attributes, and
> they purposefully leave "identity" as a matter for others to work out
> further up the stack. The OID Foundation is promoting an Attributes
> Exchange Network "AXN" architecture.  New entrants like id.me (an NSTIC
> pilot participant) talk about attributes and avoid "identity".
>
>
>
> I mention all of this as a prelude to suggest that "vector of trust" is
> synonymous with "attribute". I wonder if it would be clearer to use plain
> and current language rather than carry forward the fuzzy and I think over=
ly
> ambitious idea of "trust"?
>
>
>
> Finally, I'd like to throw in my abiding concern that LOAs have foundered
> simply because it's difficult to pigeonhole risk. One party's idea of
> "medium" risk for instance will rarely map precisely to another's. I thin=
k
> people have been misled into thinking that an "LOA 3" identity should be =
be
> able to be used on its face (i.e. will "interoperate") at any "LOA 3" RP.
> Risk management is not so simple.
>
>
>
> The LOA paradigm borrows from Risk Management standards like ISO 31000
> which organisations use to plot their own risks internally typically on a
> five scale (eg Negligible / Low / Medium / High / Grave). But risk
> management standards require that each organisation calibrates risk in it=
s
> own business context and according to its own risk appetite. The risk of =
a
> firewall breach for example at a startup social media company will be
> assessed differently by a big listed healthcare company. So organisation
> A can say the risk of event X is Low but B can say the risk of the same
> event is Medium.  As a result, LOAs do not inter-operate. They are based =
on
> standards meant for intra-organisation risk management, not
> inter-organisation communication of risk assessments.
>
>
>
> So far with VoT we are adding more dimensions to the RPs' generic risk
> management decision making, and that's great.  But we are still
> pigeonholing the dimensions.
>
>
>
> I'm afraid the reality is that risk management will always be done
> locally.  And so it should be.  When an RP is making the decision to acce=
pt
> or reject a given subject, they will evaluate a range of attributes
> or signals.  The set of attributes that matters varies from one RP to the
> next.  I think it's a great idea indeed to create guidance for evaluating
> attributes, and to coach RPs to look at all sorts of dimensions.  I just
> don't think it helps anyone to pigeonhole the risk ratings, because acros=
s
> organisations, arguments about the boundaries between LOA 1/2/3/4 (that i=
s,
> policy mapping) will undo any efficiencies gained from the categorization=
.
>
>
>
> Cheers,
>
>
>
> Steve.
>
>
>
>
>
> Stephen Wilson
> Managing Director
> Lockstep Group
> http://lockstep.com.au
> Lockstep Consulting provides independent specialist advice and analysis
> on digital identity and privacy. Lockstep Technologies develops unique
> new smart ID solutions that enhance privacy and prevent identity theft.
>
>
>
>
>
>
>
> _______________________________________________
> vot mailing list
> vot@ietf.org
> https://www.ietf.org/mailman/listinfo/vot
>
>
>
> _______________________________________________
> vot mailing list
> vot@ietf.org
> https://www.ietf.org/mailman/listinfo/vot
>
>

--089e0158aee8c0002005054210a6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Thank you Colin for herding the cats (Including myself the=
re)!

I would recommend splitting up the 'Identity Pr=
oofing' vector into its component bits, rather than treating it like th=
e current amorphous blob that it is right now:

  • Identity Resolution=C2=A0-=C2=A0Esta=
blishing the uniqueness of an individual within a population
  • Identity Validation=C2=A0-=C2=A0Confirming the accuracy of ident=
ity information claimed by an individual
  • Identity Verificat=
ion=C2=A0-=C2=A0Confirming that the claimed identity information i=
s linked to the individual making the claim=C2=A0

    • Regards,

    - Anil

    :- Anil John
    :- Making Digital Services Secure and Trustwort=
hy

    

    On Sun, Oct 12, 2014 at 3:16 PM, Colin Walli=
s <Colin.Wallis@dia.govt.nz> wrote:
    






    

    

    Putting this split, back =
into one thread..
    

    =E2=80=A6 =C2=A0and plead=
ing to folks to focus back on the vectors, or aspects, or =E2=80=98things=
=E2=80=99 - whatever we call them =E2=80=93 that the RP has an interest in.

    

    Justin is valiantly tryin=
g to re-state the purpose of his opening =E2=80=98vectors=E2=80=99 strawman=
 =E2=80=93 always useful to refresh one=E2=80=99s memory by going back to l=
ook at them...
    

    His starting list of vect=
ors was:

    

    Identity Proofing<=
u>
    

    Credential Strength
    

    Assertion Presentation=

    

    Operational Management=

    

    =C2=A0
    

    If the discussion on LoAs=
 offers any value here, it would be to add some finer grained addition to t=
he above (fairly coarse-grained) list.
    

    =C2=A0
    

    There=E2=80=99s already a=
n acknowledgment that Operational Management may be composed of a range of =
concerns =E2=80=93 a mix of context dependent, temporal and static (more
 vectors?) =E2=80=93 that influence the RP=E2=80=99s decision to accept or =
otherwise, an authenticated identity.
    

    =C2=A0=C2=A0=C2=A0=C2=A0<=
u>
    

    If we got to a point wher=
e we could agree on what these vectors are, then we can have the (separate)=
 debate about whether combining them/delineating them in
 some way is useful/helpful, or not.
    

    =C2=A0
    

    Cheers
    

    Colin

    

    =C2=A0
    

    

    

    From: vot [mailto:vot-bounces@ietf.org]
On Behalf Of Richer, Justin P.
    
Sent: Saturday, 11 October 2014 6:29 a.m.
    
To: Bouma, Tim
    
Cc: Ken Dagg; vot@=
ietf.org; =
swilson@lockstep.com.au
    
Subject: Re: [VoT] Foundational questions of principle=

    

    

    

    =C2=A0
    

    What we're trying to do with the "Vectors&q=
uot; approach here is to strike a balance between the overly-simplistic &qu=
ot;single set of linear levels" approach that LoA gives us (that nobod=
y on this list likes but all agree that apps can actually
 do some level of processing with it) and the overly-complex "very lon=
g complex set of attributes" approach that Tim, Scott, and others have=
 brought up (that seems more expressive and ideal but no app is ever going =
to make sense of, or even try to). I think
 it's safe to say that neither extreme works and that a right answer pr=
obably lies in the middle.=C2=A0

    

    

    =C2=A0
    

    

    

    So that's what this strawman is -- it's simu=
ltaneously less complex and more complex than the alternatives. Is it the r=
ight cut? Probably not, but it's at least a cutting point that we can p=
ush to either side. What I think we need to dutifully
 avoid is pushing it hard to either end. I really like the notion that even=
 if the combinations of the vector values aren't directly compatible (a=
s Steve says), then the building blocks would at least be comparable, givin=
g a hope of defining a policy to translate
 between them when needed.=C2=A0
    

    

    

    =C2=A0
    

    

    

    Also, I wanted to key into the fact that there are s=
everal independent and orthogonal components here. Maybe it's not a set=
 of levels that are tied together, but I think it is in someway a set of in=
dependent *things* that are tied together.
    

    

    

    =C2=A0
    

    

    

    =C2=A0-- Justin
    

    =E2=80=A6=E2=80=A6=E2=80=
=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=
=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=
=80=A6=E2=80=A6=E2=80=A6.
    

    =C2=A0
    

    It may make sense to look at LOAs as something that =
is "coarse-grained" and a starting point.=C2=A0
    

    =C2=A0
    

    We all think it is not enough, but in the absence of=
 the Borg showing up to enforce a collective hive-mind across organizationa=
l boundaries, we can live with it and use it as a starting point for the di=
scussion "What more do we need in
 order to let this person in the door?"
    

    =C2=A0
    

    And that is where RP implemented compensating contro=
ls can play a part. The challenge is that folks seem to conflate "thin=
gs needed to ensure confidence in an identity" with "things neede=
d to mitigate risk in the transaction" and who is
 (CSP or RP) responsible for what.
    

    =C2=A0
    

    Regards,
    

    =C2=A0
    

    - Anil
    

    =C2=A0
    

    :- Anil John
    

    :- Making Digital Services Secure and Trustworthy=

    

    :- https://blog.aniljohn.com
    

    =C2=A0
    

    =C2=A0
    

    On Fri, Oct 10, 2014 at 11:02 PM, <swilson@lockstep.com.au&=
gt; wrote:
    


    
We are all agreed of course that RPs need to understand their risks, determ=
ine what's needed from any external process of identification or attrib=
ute attestation, communicate those needs to candidate APs, and from there, =
contract an acceptable provider.
    

    
My question is whether or not a pigeonholed LOA helps at any point in this =
process.
    

    
The devil is in the detail.=C2=A0 To my mind, LOA is an intermediate step t=
hat takes a detailed risk analysis, squeezes it into a bin (losing lots of =
information as a result), which is then used to shortlist candidate provide=
rs, before going into detailed due diligence
 where all those details need to be put back on the table.
    

    
I think we all know by now of cases where RPs have looked at candidate IdPs=
 at a given LOA, and have come up with the request of "LOA two and a h=
alf" (this was mentioned at CIS 2014 more than once, and I have seen i=
t first hand in the UK IDAP).
    

    
Clearly what's going on here is an RP's idea of say "LOA 2&quo=
t; differs from a given IdP's idea of LOA 2.=C2=A0 Moreover, the idea o=
f LOA 2 must differ from one IdP to another IdP.=C2=A0 When people ask for =
"LOA 2.5" what they're asking for is a customised identificat=
ion.=C2=A0
 If LOA 2 isn't what it seems, then there cannot possibly be any such t=
hing as a *standardised* LOA 2.5.=C2=A0 All we will get is fresh calls for =
"LOA 2.75 please".
    

    
If RPs need to do detailed analysis of authentication needs, and get detail=
ed verification of the actual ID proofing done by IdPs and APs, then I just=
 don't see any point attaching the LOA label along the way.=C2=A0 It=
9;s misleading.
    

    
Cheers,
    

    
Steve.
    

    
Stephen Wilson
    
Lockstep
    
http://lockstep.com.au=

    
Lockstep Consulting provides independent specialist advice and analysis
    
on digital identity and privacy.=C2=A0 Lockstep Technologies develops uniqu=
e
    
new smart ID solutions that enhance privacy and prevent identity theft.
    

    

    

    

    

    =C2=A0
    

    

    

    On Oct 10, 2014, at 10:51 AM, Bouma, Tim <Tim.Bouma@tbs-sct.gc.=
ca> wrote:
    

    


    

    

    

    

    I agree wi=
th Ken,
    

    =C2=A0
    

    When we de=
veloped levels of assurance (here in Canada) we did several things:<=
span lang=3D"EN-CA">
    

    =C2=A0
    

    =C2=B7=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0
We de=
fined them as levels of confidence required (Levels 1 through 4)
    

    =C2=B7=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0
We ma=
pped these levels of confidence to a range of degree of impacts.
    

    =C2=B7=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0
We th=
en specified separately identity assurance levels and credential assurance =
levels (and focused on credential first)=

    

    =C2=B7=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0
We al=
so factored out likelihood in the assurance level assessment process. That =
made the assessments much less subjective.
    

    =C2=A0
    

    At the end=
 of the day, as Ken states, =C2=A0it=E2=80=99s the job the RP to understand=
 their risk (along with likelihood) and to communicate a standardized requi=
rement
 back to a provider (AP)

    The AP is =
=C2=A0accountable for providing a very prescribed component that fits into =
a larger system and a risk environment that they might not have
 a full view into. The RP may put in provisions to share the risk with the =
AP, or not but that entirely depends on the arrangement, but at least the R=
P and AP understand what=E2=80=99s on the table as a starting point.=

    

    =C2=A0
    

    In Canada,=
 we did that with the credential first, and are now figuring out identity (=
much harder).
    

    =C2=A0
    

    I also agr=
ee that =E2=80=98identity=E2=80=99 is just a set of attributes =E2=80=93and=
 =C2=A0these identity attributes can vary between organizations or jurisdic=
tions,
    

    =C2=A0
    

    As for the=
 term =E2=80=98vectors=E2=80=99, I get the idea, but I think the community =
will think it=E2=80=99s too technical or esoteric. I like to think of a =E2=
=80=98digital identity=E2=80=99
 (or whatever you call it), when it shows up at your digital front door, it=
 is the product of a very long, complex supply chain, fraught with many ris=
ks and compromises. I may have confidence in certain pieces of, but other I=
 might not trust at all.

    =C2=A0
    

    =C2=A0
    

    Tim=

    

    =C2=A0
    

    =C2=A0
    

    From: vot [mailto:vot-bounces@ietf.org]
On Behalf Of Ken Dagg
    
Sent: October-09-14 9:42 PM
    
To: swi=
lson@lockstep.com.au
    
Cc: vot@ietf.org
    
Subject: Re: [VoT] Foundational questions of principle
    

    =C2=A0
    

    Steve,
    

    

    =C2=A0
    

    

    

    As we have communicated in=C2=
=A0the past, I am a strong believer the an LOA designation is an indication=
 of the processes/mechanisms that an=C2=A0IdP has undertaken. In other word=
s, it is a communication tool.=C2=A0The choice is the
 RPs. That is, an=C2=A0assertion at a specific LOA by an=C2=A0IdP/CSP/AP=C2=
=A0is one of the mechanisms a RP should use to offset the authentication ri=
sk it has identified for the service it wants to deliver. In other words, i=
t is the risk of the RP that is paramount not the
 claims of an=C2=A0identity/credential/attribute/token provider.<=
/u>
    

    

    

    =C2=A0
    

    

    

    Like you, I am a strong believe=
r that the determination of whether or not an identity is good enough is th=
e responsibility of the RP. In my experience, they make that determination =
based upon a set of attributes they
 believe are necessary. If they trust that an IdP's assertion of identi=
ty covers the attributes they believe are=C2=A0required them they can accep=
t the assertion. If it doesn't then that have to implement additional m=
echanisms to offset the residual risk.
    

    

    

    =C2=A0
    

    

    

    With respect to vectors of trus=
t, I am interested in exploring what they are and how they can be applied.<=
u>
    

    

    

    =C2=A0
    

    

    

    Ken
    

    
On Thursday, October 9, 2014, <    swilson@lockstep.com.au> wrote:
    

    

    =C2=A0
    

    

    

    First, to introduce myself=
, I am an identity and privacy researcher, analyst and consultant.=C2=A0 I&=
#39;ve been involved in this since 1995, when I cut my teeth in PKI
 and smartcards (with the early companies that became Baltimore Technologie=
s). Since then I've worked on identity management frameworks, regulatio=
ns and standards. =C2=A0

    

    

    =C2=A0
    

    

    

    I subscribe to the old Ita=
lian proverb: "it's nice to trust but better not to".=C2=A0 W=
ords matter and I wonder if we shouldn't be using the word trust so muc=
h. =C2=A0
    

    

    

    =C2=A0
    

    

    

    More pragmatically, I note=
 the very strong "Attributes" push of the past 18 months.=C2=A0 A=
ndrew Nash, Anil John, myself and others have written about this.=C2=A0 The=
 FIDO
 Alliance is all about authentication and attributes, and they purposefully=
 leave "identity" as a matter for others to work out further up t=
he stack. The OID Foundation is promoting an Attributes Exchange Network &q=
uot;AXN" architecture.=C2=A0 New entrants like
id.me (an NSTIC pilot parti=
cipant) talk about attributes and avoid "identity".=C2=A0<=
span lang=3D"EN-CA">
    

    

    

    =C2=A0
    

    

    

    I mention all of this as a=
 prelude to suggest that "vector of trust" is synonymous with &qu=
ot;attribute". I wonder if it would be clearer to use plain and curren=
t language
 rather than carry forward the fuzzy and I think overly ambitious idea of &=
quot;trust"?=C2=A0

    

    

    =C2=A0
    

    

    

    Finally, I'd like to t=
hrow in my abiding concern that LOAs have foundered simply because it's=
 difficult to pigeonhole risk. One party's idea of "medium" r=
isk for
 instance will rarely map precisely to another's. I think people have b=
een misled into thinking that an "LOA 3" identity should be be ab=
le to be used on its face (i.e. will "interoperate") at any "=
;LOA 3" RP. Risk management is not so simple.=C2=A0
    

    

    

    =C2=A0
    

    

    

    The LOA paradigm borrows f=
rom Risk Management standards like ISO 31000 which=C2=A0organisations use t=
o=C2=A0plot=C2=A0their own risks internally typically on a five scale (eg
 Negligible / Low / Medium / High / Grave).=C2=A0But=C2=A0risk management=
=C2=A0standards require that each organisation calibrates risk in its own b=
usiness context and according to its=C2=A0own risk appetite. The risk of a =
firewall breach for example at a startup social media
 company will be assessed differently by a big listed healthcare company.=
=C2=A0So organisation A=C2=A0can say the risk of event X is Low but B can s=
ay the risk of the same event is Medium.=C2=A0 As=C2=A0a result, LOAs do no=
t inter-operate. They are based on standards meant for
 intra-organisation risk management, not inter-organisation communication o=
f=C2=A0risk assessments.=C2=A0
    

    

    

    =C2=A0
    

    

    

    So far with VoT we are add=
ing more dimensions to the RPs' generic risk management decision making=
, and that's great.=C2=A0 But we are still pigeonholing the dimensions.=

    

    

    

    =C2=A0
    

    

    

    I'm afraid the reality=
 is that risk management will always be done locally.=C2=A0 And so it shoul=
d be.=C2=A0 When an RP is making=C2=A0the decision to accept or reject a gi=
ven
 subject, they will evaluate a range of attributes or=C2=A0signals.=C2=A0 T=
he set of attributes that matters varies from one RP to the next.=C2=A0 I t=
hink it's a great idea indeed to create guidance for evaluating attribu=
tes, and to coach RPs to look at all sorts of dimensions.=C2=A0
 I just don't think it helps anyone to pigeonhole the risk ratings, bec=
ause across organisations, arguments about the boundaries between LOA 1/2/3=
/4 (that is, policy mapping) will=C2=A0undo any efficiencies gained from th=
e categorization. =C2=A0

    

    

    =C2=A0
    

    

    

    Cheers,=C2=A0
    

    

    

    =C2=A0
    

    

    

    Steve.
    

    

    

    =C2=A0
    

    

    

    =C2=A0
    

    

    

    Stephen Wilson
    
Managing Director
    
Lockstep Group
    
http://lockstep.com.a=
u
    
Lockstep Consulting provides independent specialist advice and analysis 
on digital identity and privacy. Lockstep Technologies develops unique 
    
new smart ID solutions that enhance privacy and prevent identity theft.
    

    

    

    =C2=A0
    

    

    

    =C2=A0
    

    

    

    =C2=A0
    

    

    

    

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

    

    =C2=A0
    

    

    

    


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


    

--089e0158aee8c0002005054210a6--


From nobody Sun Oct 12 16:28:34 2014
Return-Path: 
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7769F1A0233 for ; Sun, 12 Oct 2014 16:28:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.301
X-Spam-Level: *
X-Spam-Status: No, score=1.301 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5I5pG_9esHn for ; Sun, 12 Oct 2014 16:28:27 -0700 (PDT)
Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7BCE1A01A9 for ; Sun, 12 Oct 2014 16:28:26 -0700 (PDT)
Received: by mail-vc0-f174.google.com with SMTP id hq12so5099422vcb.33 for ; Sun, 12 Oct 2014 16:28:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VDV73xZc/1MOYaxsYS8joJZJ9agEUvSbJ4uQtzS4sWw=; b=nxCNFISK4wi9oayzZqQ270vnlQ0973JSJB0JOc0A+Z5/8AgbykWL+KXz5wdmNjf5sf /6Ycyy1pSuslMPsJzNVLoranVNgOrwz4At01FpT0AFmwVU3rT1uxVY1i11x4qfogr+OY LgvuhijgCqhjcj46qJOcrFDNAuswiIoZw9mKmoNI7SN2LmdAxS+/fBX8kkVZ7IJxW98E 0FF7bs3yJP7oi6eAooVEy5joc5V5UGzlCMHdF9ZzMb+PgRdfWYlhLI5+WtPA1VvLP5Af L/3odbP8rfIZ66vzzYvnajagmV6XM2OR2E/iDW50IMeJr4aGemSnD8CNAptAiCl20ppv 76cw==
MIME-Version: 1.0
X-Received: by 10.220.200.74 with SMTP id ev10mr17251110vcb.1.1413156505902; Sun, 12 Oct 2014 16:28:25 -0700 (PDT)
Received: by 10.220.88.199 with HTTP; Sun, 12 Oct 2014 16:28:25 -0700 (PDT)
In-Reply-To: 
References: <1412885935.58929166@apps.rackspace.com>  <20141010145142.51DBE1A90E3@ietfa.amsl.com> <6A0CFC85-F8F5-43F5-B02F-09720E7164F4@mitre.org> <147EE18440E5AF44834B220ED35BA530D32F0A2E@WLGPRDMBX01.dia.govt.nz> 
Date: Sun, 12 Oct 2014 19:28:25 -0400
Message-ID: 
From: Ken Dagg 
To: Anil John 
Content-Type: multipart/alternative; boundary=047d7b6776568be4580505422307
Archived-At: http://mailarchive.ietf.org/arch/msg/vot/SkHNQ4M2W1mCMkg9e5Sltxn_eVw
Cc: "vot@ietf.org" 
Subject: Re: [VoT] Foundational questions of principle
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Vectors of Trust discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 12 Oct 2014 23:28:31 -0000

--047d7b6776568be4580505422307
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Anil,
Do you think that these could be sub vectors of the Identity Proofing
vector?
Ken

On Monday, October 13, 2014, Anil John  wrote:

> Thank you Colin for herding the cats (Including myself there)!
>
> I would recommend splitting up the 'Identity Proofing' vector into its
> component bits, rather than treating it like the current amorphous blob
> that it is right now:
>
>
>    1. *Identity Resolution* - Establishing the uniqueness of an
>    individual within a population
>    2. *Identity Validation* - Confirming the accuracy of identity
>    information claimed by an individual
>    3. *Identity Verification* - Confirming that the claimed identity
>    information is linked to the individual making the claim
>
>
> Regards,
>
> - Anil
>
> :- Anil John
> :- Making Digital Services Secure and Trustworthy
> :- https://blog.aniljohn.com
>
>
> On Sun, Oct 12, 2014 at 3:16 PM, Colin Wallis  > wrote:
>
>>  Putting this split, back into one thread..
>>
>> =E2=80=A6  and pleading to folks to focus back on the vectors, or aspect=
s, or
>> =E2=80=98things=E2=80=99 - whatever we call them =E2=80=93 that the RP h=
as an interest in.
>>
>> Justin is valiantly trying to re-state the purpose of his opening
>> =E2=80=98vectors=E2=80=99 strawman =E2=80=93 always useful to refresh on=
e=E2=80=99s memory by going back to
>> look at them...
>>
>> His starting list of vectors was:
>>
>> Identity Proofing
>>
>> Credential Strength
>>
>> Assertion Presentation
>>
>> Operational Management
>>
>>
>>
>> If the discussion on LoAs offers any value here, it would be to add some
>> finer grained addition to the above (fairly coarse-grained) list.
>>
>>
>>
>> There=E2=80=99s already an acknowledgment that Operational Management ma=
y be
>> composed of a range of concerns =E2=80=93 a mix of context dependent, te=
mporal and
>> static (more vectors?) =E2=80=93 that influence the RP=E2=80=99s decisio=
n to accept or
>> otherwise, an authenticated identity.
>>
>>
>>
>> If we got to a point where we could agree on what these vectors are, the=
n
>> we can have the (separate) debate about whether combining them/delineati=
ng
>> them in some way is useful/helpful, or not.
>>
>>
>>
>> Cheers
>>
>> Colin
>>
>>
>>
>> *From:* vot [mailto:vot-bounces@ietf.org
>> ] *On Behalf Of *R=
icher,
>> Justin P.
>> *Sent:* Saturday, 11 October 2014 6:29 a.m.
>> *To:* Bouma, Tim
>> *Cc:* Ken Dagg; vot@ietf.org
>> ; swilson@lockstep.com.au
>> 
>> *Subject:* Re: [VoT] Foundational questions of principle
>>
>>
>>
>> What we're trying to do with the "Vectors" approach here is to strike a
>> balance between the overly-simplistic "single set of linear levels"
>> approach that LoA gives us (that nobody on this list likes but all agree
>> that apps can actually do some level of processing with it) and the
>> overly-complex "very long complex set of attributes" approach that Tim,
>> Scott, and others have brought up (that seems more expressive and ideal =
but
>> no app is ever going to make sense of, or even try to). I think it's saf=
e
>> to say that neither extreme works and that a right answer probably lies =
in
>> the middle.
>>
>>
>>
>> So that's what this strawman is -- it's simultaneously less complex and
>> more complex than the alternatives. Is it the right cut? Probably not, b=
ut
>> it's at least a cutting point that we can push to either side. What I th=
ink
>> we need to dutifully avoid is pushing it hard to either end. I really li=
ke
>> the notion that even if the combinations of the vector values aren't
>> directly compatible (as Steve says), then the building blocks would at
>> least be comparable, giving a hope of defining a policy to translate
>> between them when needed.
>>
>>
>>
>> Also, I wanted to key into the fact that there are several independent
>> and orthogonal components here. Maybe it's not a set of levels that are
>> tied together, but I think it is in someway a set of independent *things=
*
>> that are tied together.
>>
>>
>>
>>  -- Justin
>>
>> =E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=
=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=
=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6.
>>
>>
>>
>> It may make sense to look at LOAs as something that is "coarse-grained"
>> and a starting point.
>>
>>
>>
>> We all think it is not enough, but in the absence of the Borg showing up
>> to enforce a collective hive-mind across organizational boundaries, we c=
an
>> live with it and use it as a starting point for the discussion "What mor=
e
>> do we need in order to let this person in the door?"
>>
>>
>>
>> And that is where RP implemented compensating controls can play a part.
>> The challenge is that folks seem to conflate "things needed to ensure
>> confidence in an identity" with "things needed to mitigate risk in the
>> transaction" and who is (CSP or RP) responsible for what.
>>
>>
>>
>> Regards,
>>
>>
>>
>> - Anil
>>
>>
>>
>> :- Anil John
>>
>> :- Making Digital Services Secure and Trustworthy
>>
>> :- https://blog.aniljohn.com
>>
>>
>>
>>
>>
>> On Fri, Oct 10, 2014 at 11:02 PM, > > wrote:
>>
>>
>> We are all agreed of course that RPs need to understand their risks,
>> determine what's needed from any external process of identification or
>> attribute attestation, communicate those needs to candidate APs, and fro=
m
>> there, contract an acceptable provider.
>>
>> My question is whether or not a pigeonholed LOA helps at any point in
>> this process.
>>
>> The devil is in the detail.  To my mind, LOA is an intermediate step tha=
t
>> takes a detailed risk analysis, squeezes it into a bin (losing lots of
>> information as a result), which is then used to shortlist candidate
>> providers, before going into detailed due diligence where all those deta=
ils
>> need to be put back on the table.
>>
>> I think we all know by now of cases where RPs have looked at candidate
>> IdPs at a given LOA, and have come up with the request of "LOA two and a
>> half" (this was mentioned at CIS 2014 more than once, and I have seen it
>> first hand in the UK IDAP).
>>
>> Clearly what's going on here is an RP's idea of say "LOA 2" differs from
>> a given IdP's idea of LOA 2.  Moreover, the idea of LOA 2 must differ fr=
om
>> one IdP to another IdP.  When people ask for "LOA 2.5" what they're aski=
ng
>> for is a customised identification.  If LOA 2 isn't what it seems, then
>> there cannot possibly be any such thing as a *standardised* LOA 2.5.  Al=
l
>> we will get is fresh calls for "LOA 2.75 please".
>>
>> If RPs need to do detailed analysis of authentication needs, and get
>> detailed verification of the actual ID proofing done by IdPs and APs, th=
en
>> I just don't see any point attaching the LOA label along the way.  It's
>> misleading.
>>
>> Cheers,
>>
>> Steve.
>>
>> Stephen Wilson
>> Lockstep
>> http://lockstep.com.au
>> Lockstep Consulting provides independent specialist advice and analysis
>> on digital identity and privacy.  Lockstep Technologies develops unique
>> new smart ID solutions that enhance privacy and prevent identity theft.
>>
>>
>>
>> On Oct 10, 2014, at 10:51 AM, Bouma, Tim > > wrote:
>>
>>
>>
>>  I agree with Ken,
>>
>>
>>
>> When we developed levels of assurance (here in Canada) we did several
>> things:
>>
>>
>>
>> =C2=B7         We defined them as levels of confidence required (Levels =
1
>> through 4)
>>
>> =C2=B7         We mapped these levels of confidence to a range of degree=
 of
>> impacts.
>>
>> =C2=B7         We then specified separately identity assurance levels an=
d
>> credential assurance levels (and focused on credential first)
>>
>> =C2=B7         We also factored out likelihood in the assurance level
>> assessment process. That made the assessments much less subjective.
>>
>>
>>
>> At the end of the day, as Ken states,  it=E2=80=99s the job the RP to un=
derstand
>> their risk (along with likelihood) and to communicate a standardized
>> requirement back to a provider (AP)
>>
>> The AP is  accountable for providing a very prescribed component that
>> fits into a larger system and a risk environment that they might not hav=
e a
>> full view into. The RP may put in provisions to share the risk with the =
AP,
>> or not but that entirely depends on the arrangement, but at least the RP
>> and AP understand what=E2=80=99s on the table as a starting point.
>>
>>
>>
>> In Canada, we did that with the credential first, and are now figuring
>> out identity (much harder).
>>
>>
>>
>> I also agree that =E2=80=98identity=E2=80=99 is just a set of attributes=
 =E2=80=93and  these
>> identity attributes can vary between organizations or jurisdictions,
>>
>>
>>
>> As for the term =E2=80=98vectors=E2=80=99, I get the idea, but I think t=
he community will
>> think it=E2=80=99s too technical or esoteric. I like to think of a =E2=
=80=98digital
>> identity=E2=80=99 (or whatever you call it), when it shows up at your di=
gital front
>> door, it is the product of a very long, complex supply chain, fraught wi=
th
>> many risks and compromises. I may have confidence in certain pieces of, =
but
>> other I might not trust at all.
>>
>>
>>
>>
>>
>> Tim
>>
>>
>>
>>
>>
>> *From:* vot [mailto:vot-bounces@ietf.org
>> ] *On Behalf Of *K=
en
>> Dagg
>> *Sent:* October-09-14 9:42 PM
>> *To:* swilson@lockstep.com.au
>> 
>> *Cc:* vot@ietf.org 
>> *Subject:* Re: [VoT] Foundational questions of principle
>>
>>
>>
>> Steve,
>>
>>
>>
>> As we have communicated in the past, I am a strong believer the an LOA
>> designation is an indication of the processes/mechanisms that an IdP has
>> undertaken. In other words, it is a communication tool. The choice is th=
e
>> RPs. That is, an assertion at a specific LOA by an IdP/CSP/AP is one of =
the
>> mechanisms a RP should use to offset the authentication risk it has
>> identified for the service it wants to deliver. In other words, it is th=
e
>> risk of the RP that is paramount not the claims of
>> an identity/credential/attribute/token provider.
>>
>>
>>
>> Like you, I am a strong believer that the determination of whether or no=
t
>> an identity is good enough is the responsibility of the RP. In my
>> experience, they make that determination based upon a set of attributes
>> they believe are necessary. If they trust that an IdP's assertion of
>> identity covers the attributes they believe are required them they can
>> accept the assertion. If it doesn't then that have to implement addition=
al
>> mechanisms to offset the residual risk.
>>
>>
>>
>> With respect to vectors of trust, I am interested in exploring what they
>> are and how they can be applied.
>>
>>
>>
>> Ken
>>
>> On Thursday, October 9, 2014, > > wrote:
>>
>>
>>
>> First, to introduce myself, I am an identity and privacy researcher,
>> analyst and consultant.  I've been involved in this since 1995, when I c=
ut
>> my teeth in PKI and smartcards (with the early companies that became
>> Baltimore Technologies). Since then I've worked on identity management
>> frameworks, regulations and standards.
>>
>>
>>
>> I subscribe to the old Italian proverb: "it's nice to trust but better
>> not to".  Words matter and I wonder if we shouldn't be using the word tr=
ust
>> so much.
>>
>>
>>
>> More pragmatically, I note the very strong "Attributes" push of the past
>> 18 months.  Andrew Nash, Anil John, myself and others have written about
>> this.  The FIDO Alliance is all about authentication and attributes, and
>> they purposefully leave "identity" as a matter for others to work out
>> further up the stack. The OID Foundation is promoting an Attributes
>> Exchange Network "AXN" architecture.  New entrants like id.me (an NSTIC
>> pilot participant) talk about attributes and avoid "identity".
>>
>>
>>
>> I mention all of this as a prelude to suggest that "vector of trust" is
>> synonymous with "attribute". I wonder if it would be clearer to use plai=
n
>> and current language rather than carry forward the fuzzy and I think ove=
rly
>> ambitious idea of "trust"?
>>
>>
>>
>> Finally, I'd like to throw in my abiding concern that LOAs have foundere=
d
>> simply because it's difficult to pigeonhole risk. One party's idea of
>> "medium" risk for instance will rarely map precisely to another's. I thi=
nk
>> people have been misled into thinking that an "LOA 3" identity should be=
 be
>> able to be used on its face (i.e. will "interoperate") at any "LOA 3" RP=
.
>> Risk management is not so simple.
>>
>>
>>
>> The LOA paradigm borrows from Risk Management standards like ISO 31000
>> which organisations use to plot their own risks internally typically on =
a
>> five scale (eg Negligible / Low / Medium / High / Grave). But risk
>> management standards require that each organisation calibrates risk in i=
ts
>> own business context and according to its own risk appetite. The risk of=
 a
>> firewall breach for example at a startup social media company will be
>> assessed differently by a big listed healthcare company. So organisation
>> A can say the risk of event X is Low but B can say the risk of the same
>> event is Medium.  As a result, LOAs do not inter-operate. They are based=
 on
>> standards meant for intra-organisation risk management, not
>> inter-organisation communication of risk assessments.
>>
>>
>>
>> So far with VoT we are adding more dimensions to the RPs' generic risk
>> management decision making, and that's great.  But we are still
>> pigeonholing the dimensions.
>>
>>
>>
>> I'm afraid the reality is that risk management will always be done
>> locally.  And so it should be.  When an RP is making the decision to acc=
ept
>> or reject a given subject, they will evaluate a range of attributes
>> or signals.  The set of attributes that matters varies from one RP to th=
e
>> next.  I think it's a great idea indeed to create guidance for evaluatin=
g
>> attributes, and to coach RPs to look at all sorts of dimensions.  I just
>> don't think it helps anyone to pigeonhole the risk ratings, because acro=
ss
>> organisations, arguments about the boundaries between LOA 1/2/3/4 (that =
is,
>> policy mapping) will undo any efficiencies gained from the categorizatio=
n.
>>
>>
>>
>> Cheers,
>>
>>
>>
>> Steve.
>>
>>
>>
>>
>>
>> Stephen Wilson
>> Managing Director
>> Lockstep Group
>> http://lockstep.com.au
>> Lockstep Consulting provides independent specialist advice and analysis
>> on digital identity and privacy. Lockstep Technologies develops unique
>> new smart ID solutions that enhance privacy and prevent identity theft.
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> vot mailing list
>> vot@ietf.org 
>> https://www.ietf.org/mailman/listinfo/vot
>>
>>
>>
>> _______________________________________________
>> vot mailing list
>> vot@ietf.org 
>> https://www.ietf.org/mailman/listinfo/vot
>>
>>
>

--047d7b6776568be4580505422307
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Anil,
    Do you think that these could be sub vectors of the Identity Proo=
fing vector?
    Ken

    On Monday, October 13, 2014, Anil John &l=
t;aniltj@gmail.com> wrote:
    Thank you Colin for herding t=
he cats (Including myself there)!

    I would recommend spli=
tting up the 'Identity Proofing' vector into its component bits, ra=
ther than treating it like the current amorphous blob that it is right now:=


    1. Identity Resolut=
ion=C2=A0-=C2=A0Establishing the uniqueness of an individual withi=
n a population
    2. Identity Validation=C2=A0-=C2=A0Con=
firming the accuracy of identity information claimed by an individual
      3. <=
li>Identity Verification=C2=A0-=C2=A0Confirming that the c=
laimed identity information is linked to the individual making the claim=C2=
=A0

    Regards,

    - Anil<=
/div>

    :- Anil John
    :- Making Digital=
 Services Secure and Trustworthy
    <=
div>
    

    On Sun, Oct 12, 2014 at 3:16 PM, Colin Walli=
s <Colin.Wallis@dia.govt.n=
z> wrote:
    






    

    

    Putting this split, back =
into one thread..
    

    =E2=80=A6 =C2=A0and plead=
ing to folks to focus back on the vectors, or aspects, or =E2=80=98things=
=E2=80=99 - whatever we call them =E2=80=93 that the RP has an interest in.

    

    Justin is valiantly tryin=
g to re-state the purpose of his opening =E2=80=98vectors=E2=80=99 strawman=
 =E2=80=93 always useful to refresh one=E2=80=99s memory by going back to l=
ook at them...
    

    His starting list of vect=
ors was:

    

    Identity Proofing<=
u>
    

    Credential Strength
    

    Assertion Presentation=

    

    Operational Management=

    

    =C2=A0
    

    If the discussion on LoAs=
 offers any value here, it would be to add some finer grained addition to t=
he above (fairly coarse-grained) list.
    

    =C2=A0
    

    There=E2=80=99s already a=
n acknowledgment that Operational Management may be composed of a range of =
concerns =E2=80=93 a mix of context dependent, temporal and static (more
 vectors?) =E2=80=93 that influence the RP=E2=80=99s decision to accept or =
otherwise, an authenticated identity.
    

    =C2=A0=C2=A0=C2=A0=C2=A0<=
u>
    

    If we got to a point wher=
e we could agree on what these vectors are, then we can have the (separate)=
 debate about whether combining them/delineating them in
 some way is useful/helpful, or not.
    

    =C2=A0
    

    Cheers
    

    Colin

    

    =C2=A0
    

    

    

    From: vot [mailto:vot-bounces@ietf.=
org]
On Behalf Of Richer, Justin P.
    
Sent: Saturday, 11 October 2014 6:29 a.m.
    
To: Bouma, Tim
    
Cc: Ken Dagg; vot@ietf.org; swilson@lockstep.com.au
    
Subject: Re: [VoT] Foundational questions of principle=

    

    

    

    =C2=A0
    

    What we're trying to do with the "Vectors&q=
uot; approach here is to strike a balance between the overly-simplistic &qu=
ot;single set of linear levels" approach that LoA gives us (that nobod=
y on this list likes but all agree that apps can actually
 do some level of processing with it) and the overly-complex "very lon=
g complex set of attributes" approach that Tim, Scott, and others have=
 brought up (that seems more expressive and ideal but no app is ever going =
to make sense of, or even try to). I think
 it's safe to say that neither extreme works and that a right answer pr=
obably lies in the middle.=C2=A0

    

    

    =C2=A0
    

    

    

    So that's what this strawman is -- it's simu=
ltaneously less complex and more complex than the alternatives. Is it the r=
ight cut? Probably not, but it's at least a cutting point that we can p=
ush to either side. What I think we need to dutifully
 avoid is pushing it hard to either end. I really like the notion that even=
 if the combinations of the vector values aren't directly compatible (a=
s Steve says), then the building blocks would at least be comparable, givin=
g a hope of defining a policy to translate
 between them when needed.=C2=A0
    

    

    

    =C2=A0
    

    

    

    Also, I wanted to key into the fact that there are s=
everal independent and orthogonal components here. Maybe it's not a set=
 of levels that are tied together, but I think it is in someway a set of in=
dependent *things* that are tied together.
    

    

    

    =C2=A0
    

    

    

    =C2=A0-- Justin
    

    =E2=80=A6=E2=80=A6=E2=80=
=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=
=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=
=80=A6=E2=80=A6=E2=80=A6.
    

    =C2=A0
    

    It may make sense to look at LOAs as something that =
is "coarse-grained" and a starting point.=C2=A0
    

    =C2=A0
    

    We all think it is not enough, but in the absence of=
 the Borg showing up to enforce a collective hive-mind across organizationa=
l boundaries, we can live with it and use it as a starting point for the di=
scussion "What more do we need in
 order to let this person in the door?"
    

    =C2=A0
    

    And that is where RP implemented compensating contro=
ls can play a part. The challenge is that folks seem to conflate "thin=
gs needed to ensure confidence in an identity" with "things neede=
d to mitigate risk in the transaction" and who is
 (CSP or RP) responsible for what.
    

    =C2=A0
    

    Regards,
    

    =C2=A0
    

    - Anil
    

    =C2=A0
    

    :- Anil John
    

    :- Making Digital Services Secure and Trustworthy=

    

    :- https://blog.aniljohn.com
    

    =C2=A0
    

    =C2=A0
    

    On Fri, Oct 10, 2014 at 11:02 PM, <swilson@lockstep.com.au> wrote:
    


    
We are all agreed of course that RPs need to understand their risks, determ=
ine what's needed from any external process of identification or attrib=
ute attestation, communicate those needs to candidate APs, and from there, =
contract an acceptable provider.
    

    
My question is whether or not a pigeonholed LOA helps at any point in this =
process.
    

    
The devil is in the detail.=C2=A0 To my mind, LOA is an intermediate step t=
hat takes a detailed risk analysis, squeezes it into a bin (losing lots of =
information as a result), which is then used to shortlist candidate provide=
rs, before going into detailed due diligence
 where all those details need to be put back on the table.
    

    
I think we all know by now of cases where RPs have looked at candidate IdPs=
 at a given LOA, and have come up with the request of "LOA two and a h=
alf" (this was mentioned at CIS 2014 more than once, and I have seen i=
t first hand in the UK IDAP).
    

    
Clearly what's going on here is an RP's idea of say "LOA 2&quo=
t; differs from a given IdP's idea of LOA 2.=C2=A0 Moreover, the idea o=
f LOA 2 must differ from one IdP to another IdP.=C2=A0 When people ask for =
"LOA 2.5" what they're asking for is a customised identificat=
ion.=C2=A0
 If LOA 2 isn't what it seems, then there cannot possibly be any such t=
hing as a *standardised* LOA 2.5.=C2=A0 All we will get is fresh calls for =
"LOA 2.75 please".
    

    
If RPs need to do detailed analysis of authentication needs, and get detail=
ed verification of the actual ID proofing done by IdPs and APs, then I just=
 don't see any point attaching the LOA label along the way.=C2=A0 It=
9;s misleading.
    

    
Cheers,
    

    
Steve.
    

    
Stephen Wilson
    
Lockstep
    
http://lockstep.com.au=

    
Lockstep Consulting provides independent specialist advice and analysis
    
on digital identity and privacy.=C2=A0 Lockstep Technologies develops uniqu=
e
    
new smart ID solutions that enhance privacy and prevent identity theft.
    

    

    

    

    

    =C2=A0
    

    

    

    On Oct 10, 2014, at 10:51 AM, Bouma, Tim <Tim.Bouma@tbs-sct.gc.ca> wrote:

    


    

    

    

    

    I agree wi=
th Ken,
    

    =C2=A0
    

    When we de=
veloped levels of assurance (here in Canada) we did several things:<=
span lang=3D"EN-CA">
    

    =C2=A0
    

    =C2=B7=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0
We de=
fined them as levels of confidence required (Levels 1 through 4)
    

    =C2=B7=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0
We ma=
pped these levels of confidence to a range of degree of impacts.
    

    =C2=B7=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0
We th=
en specified separately identity assurance levels and credential assurance =
levels (and focused on credential first)=

    

    =C2=B7=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0
We al=
so factored out likelihood in the assurance level assessment process. That =
made the assessments much less subjective.
    

    =C2=A0
    

    At the end=
 of the day, as Ken states, =C2=A0it=E2=80=99s the job the RP to understand=
 their risk (along with likelihood) and to communicate a standardized requi=
rement
 back to a provider (AP)

    The AP is =
=C2=A0accountable for providing a very prescribed component that fits into =
a larger system and a risk environment that they might not have
 a full view into. The RP may put in provisions to share the risk with the =
AP, or not but that entirely depends on the arrangement, but at least the R=
P and AP understand what=E2=80=99s on the table as a starting point.=

    

    =C2=A0
    

    In Canada,=
 we did that with the credential first, and are now figuring out identity (=
much harder).
    

    =C2=A0
    

    I also agr=
ee that =E2=80=98identity=E2=80=99 is just a set of attributes =E2=80=93and=
 =C2=A0these identity attributes can vary between organizations or jurisdic=
tions,
    

    =C2=A0
    

    As for the=
 term =E2=80=98vectors=E2=80=99, I get the idea, but I think the community =
will think it=E2=80=99s too technical or esoteric. I like to think of a =E2=
=80=98digital identity=E2=80=99
 (or whatever you call it), when it shows up at your digital front door, it=
 is the product of a very long, complex supply chain, fraught with many ris=
ks and compromises. I may have confidence in certain pieces of, but other I=
 might not trust at all.

    =C2=A0
    

    =C2=A0
    

    Tim=

    

    =C2=A0
    

    =C2=A0
    

    From: vot [mailto:vot-b=
ounces@ietf.org]
On Behalf Of Ken Dagg
    
Sent: October-09-14 9:42 PM
    
To: swilson@lockstep.com.au
    
Cc: vot@ietf.org
    
Subject: Re: [VoT] Foundational questions of principle
    

    =C2=A0
    

    Steve,
    

    

    =C2=A0
    

    

    

    As we have communicated in=C2=
=A0the past, I am a strong believer the an LOA designation is an indication=
 of the processes/mechanisms that an=C2=A0IdP has undertaken. In other word=
s, it is a communication tool.=C2=A0The choice is the
 RPs. That is, an=C2=A0assertion at a specific LOA by an=C2=A0IdP/CSP/AP=C2=
=A0is one of the mechanisms a RP should use to offset the authentication ri=
sk it has identified for the service it wants to deliver. In other words, i=
t is the risk of the RP that is paramount not the
 claims of an=C2=A0identity/credential/attribute/token provider.<=
/u>
    

    

    

    =C2=A0
    

    

    

    Like you, I am a strong believe=
r that the determination of whether or not an identity is good enough is th=
e responsibility of the RP. In my experience, they make that determination =
based upon a set of attributes they
 believe are necessary. If they trust that an IdP's assertion of identi=
ty covers the attributes they believe are=C2=A0required them they can accep=
t the assertion. If it doesn't then that have to implement additional m=
echanisms to offset the residual risk.
    

    

    

    =C2=A0
    

    

    

    With respect to vectors of trus=
t, I am interested in exploring what they are and how they can be applied.<=
u>
    

    

    

    =C2=A0
    

    

    

    Ken
    

    
On Thursday, October 9, 2014, <swilson@lockst=
ep.com.au> wrote:
    

    

    =C2=A0
    

    

    

    First, to introduce myself=
, I am an identity and privacy researcher, analyst and consultant.=C2=A0 I&=
#39;ve been involved in this since 1995, when I cut my teeth in PKI
 and smartcards (with the early companies that became Baltimore Technologie=
s). Since then I've worked on identity management frameworks, regulatio=
ns and standards. =C2=A0

    

    

    =C2=A0
    

    

    

    I subscribe to the old Ita=
lian proverb: "it's nice to trust but better not to".=C2=A0 W=
ords matter and I wonder if we shouldn't be using the word trust so muc=
h. =C2=A0
    

    

    

    =C2=A0
    

    

    

    More pragmatically, I note=
 the very strong "Attributes" push of the past 18 months.=C2=A0 A=
ndrew Nash, Anil John, myself and others have written about this.=C2=A0 The=
 FIDO
 Alliance is all about authentication and attributes, and they purposefully=
 leave "identity" as a matter for others to work out further up t=
he stack. The OID Foundation is promoting an Attributes Exchange Network &q=
uot;AXN" architecture.=C2=A0 New entrants like
id.me (an NSTIC pilot parti=
cipant) talk about attributes and avoid "identity".=C2=A0<=
span lang=3D"EN-CA">
    

    

    

    =C2=A0
    

    

    

    I mention all of this as a=
 prelude to suggest that "vector of trust" is synonymous with &qu=
ot;attribute". I wonder if it would be clearer to use plain and curren=
t language
 rather than carry forward the fuzzy and I think overly ambitious idea of &=
quot;trust"?=C2=A0

    

    

    =C2=A0
    

    

    

    Finally, I'd like to t=
hrow in my abiding concern that LOAs have foundered simply because it's=
 difficult to pigeonhole risk. One party's idea of "medium" r=
isk for
 instance will rarely map precisely to another's. I think people have b=
een misled into thinking that an "LOA 3" identity should be be ab=
le to be used on its face (i.e. will "interoperate") at any "=
;LOA 3" RP. Risk management is not so simple.=C2=A0
    

    

    

    =C2=A0
    

    

    

    The LOA paradigm borrows f=
rom Risk Management standards like ISO 31000 which=C2=A0organisations use t=
o=C2=A0plot=C2=A0their own risks internally typically on a five scale (eg
 Negligible / Low / Medium / High / Grave).=C2=A0But=C2=A0risk management=
=C2=A0standards require that each organisation calibrates risk in its own b=
usiness context and according to its=C2=A0own risk appetite. The risk of a =
firewall breach for example at a startup social media
 company will be assessed differently by a big listed healthcare company.=
=C2=A0So organisation A=C2=A0can say the risk of event X is Low but B can s=
ay the risk of the same event is Medium.=C2=A0 As=C2=A0a result, LOAs do no=
t inter-operate. They are based on standards meant for
 intra-organisation risk management, not inter-organisation communication o=
f=C2=A0risk assessments.=C2=A0
    

    

    

    =C2=A0
    

    

    

    So far with VoT we are add=
ing more dimensions to the RPs' generic risk management decision making=
, and that's great.=C2=A0 But we are still pigeonholing the dimensions.=

    

    

    

    =C2=A0
    

    

    

    I'm afraid the reality=
 is that risk management will always be done locally.=C2=A0 And so it shoul=
d be.=C2=A0 When an RP is making=C2=A0the decision to accept or reject a gi=
ven
 subject, they will evaluate a range of attributes or=C2=A0signals.=C2=A0 T=
he set of attributes that matters varies from one RP to the next.=C2=A0 I t=
hink it's a great idea indeed to create guidance for evaluating attribu=
tes, and to coach RPs to look at all sorts of dimensions.=C2=A0
 I just don't think it helps anyone to pigeonhole the risk ratings, bec=
ause across organisations, arguments about the boundaries between LOA 1/2/3=
/4 (that is, policy mapping) will=C2=A0undo any efficiencies gained from th=
e categorization. =C2=A0

    

    

    =C2=A0
    

    

    

    Cheers,=C2=A0
    

    

    

    =C2=A0
    

    

    

    Steve.
    

    

    

    =C2=A0
    

    

    

    =C2=A0
    

    

    

    Stephen Wilson
    
Managing Director
    
Lockstep Group
    
http://lockstep.com.a=
u
    
Lockstep Consulting provides independent specialist advice and analysis 
on digital identity and privacy. Lockstep Technologies develops unique 
    
new smart ID solutions that enhance privacy and prevent identity theft.
    

    

    

    =C2=A0
    

    

    

    =C2=A0
    

    

    

    =C2=A0
    

    

    

    

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

    

    =C2=A0
    

    

    

    


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


    

    

--047d7b6776568be4580505422307--


From nobody Sun Oct 12 16:37:12 2014
Return-Path: 
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD131A0069 for ; Sun, 12 Oct 2014 16:37:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.301
X-Spam-Level: *
X-Spam-Status: No, score=1.301 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vjqFLbhQ6m6X for ; Sun, 12 Oct 2014 16:37:04 -0700 (PDT)
Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0866C1A0323 for ; Sun, 12 Oct 2014 16:37:03 -0700 (PDT)
Received: by mail-la0-f49.google.com with SMTP id q1so5767339lam.22 for ; Sun, 12 Oct 2014 16:37:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=F1lvvhPImiNFRe0e9dMNs/Jqj31SxsQSN0cuIIWzDL0=; b=qGGfMHpjMcvGS/9lqJx8M7Fvots/gAuBfh1J5xiVrIHNCZyS2v9OcLxtcyIwyyI9U2 Wo1/Ya7QRt88McnPeWg2ttBhDBIliZN5+Pj6L6VXspw3yn6EKAIgccSzKqhcMkfWUaAj W0KbEWhgwAL75l+TQ2Uf4kaT09z98jc55QiDQzsgrJe+rl/OoCryQukII9hBwc6pwpob XyEs0OnJ3g0vh3Ot5mSuCrj2WLVQqhKjIzcOpuBCU0TtjVXKYV7D97hYm9atAtQMlHMc 4+OS9+iCt1hkG4jImQ4C5lOeslff1bxTtSUlNHIavN1tpMZirq91H5v94CR96GOhFa5S 8VTg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=F1lvvhPImiNFRe0e9dMNs/Jqj31SxsQSN0cuIIWzDL0=; b=FtFkyiREr9s8U22AbpHP5+McC48wSm6//qaHyVRYE9qVglThQ/FoeK9ffkJuDBi1Mt oOTZb0FdccCnG7L+ca7pXenkgAIpRR8H3HmlDamYULdkBXcUd4fhHf8j270T8SGwysMm W45hZdDKkze30wLG43sLWETzyEqpXac0NcoPq761rD6+4Oav7jC7SvNFtKjWtmM2P9r4 Y45sPqQ+f16WwxWXLvVprCIQXybJs/Fo7Yg/0W322wFQt3EsZtQNHSXl37DoH/xL/XzL +7Rg8IC3FON9/jPj6WjUXnP5GlndoBMHNJtbp77DX1V+6pl6L3TkM3sEKFawNpth2iHy 6NXQ==
X-Received: by 10.152.23.99 with SMTP id l3mr20241056laf.39.1413157022281; Sun, 12 Oct 2014 16:37:02 -0700 (PDT)
Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) by mx.google.com with ESMTPSA id or5sm4023125lbb.42.2014.10.12.16.37.00 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 12 Oct 2014 16:37:00 -0700 (PDT)
Received: by mail-lb0-f174.google.com with SMTP id p9so5678368lbv.33 for ; Sun, 12 Oct 2014 16:37:00 -0700 (PDT)
X-Gm-Message-State: ALoCoQkB7UiS/L7Qxhkv8DKW98GuyBM5xl5kocYZFc5isQiftDPlcCgB5MotcLzTg/8j60RkSAUa
X-Received: by 10.153.11.166 with SMTP id ej6mr20464779lad.80.1413157020278; Sun, 12 Oct 2014 16:37:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.213.72 with HTTP; Sun, 12 Oct 2014 16:36:20 -0700 (PDT)
In-Reply-To: 
References: <1412885935.58929166@apps.rackspace.com>  <20141010145142.51DBE1A90E3@ietfa.amsl.com> <6A0CFC85-F8F5-43F5-B02F-09720E7164F4@mitre.org> <147EE18440E5AF44834B220ED35BA530D32F0A2E@WLGPRDMBX01.dia.govt.nz>  
From: Anil John 
Date: Sun, 12 Oct 2014 19:36:20 -0400
Message-ID: 
To: Ken Dagg , "vot@ietf.org" 
Content-Type: multipart/alternative; boundary=001a1134650634b5cf05054242be
Archived-At: http://mailarchive.ietf.org/arch/msg/vot/sh-RToMDwyjFWV7_lU1JNzRGnPM
Subject: Re: [VoT] Foundational questions of principle
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Vectors of Trust discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 12 Oct 2014 23:37:09 -0000

--001a1134650634b5cf05054242be
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Ken,

I think it depends on if the intention is to keep the 'vectors' flat or
they can have some sort of an hierarchy.  If the latter, sure.

Regards,

- Anil

Regards,

- Anil

:- Anil John
:- Making Digital Services Secure and Trustworthy
:- https://blog.aniljohn.com


On Sun, Oct 12, 2014 at 7:28 PM, Ken Dagg  wrote:

> Anil,
> Do you think that these could be sub vectors of the Identity Proofing
> vector?
> Ken
>
>
> On Monday, October 13, 2014, Anil John  wrote:
>
>> Thank you Colin for herding the cats (Including myself there)!
>>
>> I would recommend splitting up the 'Identity Proofing' vector into its
>> component bits, rather than treating it like the current amorphous blob
>> that it is right now:
>>
>>
>>    1. *Identity Resolution* - Establishing the uniqueness of an
>>    individual within a population
>>    2. *Identity Validation* - Confirming the accuracy of identity
>>    information claimed by an individual
>>    3. *Identity Verification* - Confirming that the claimed identity
>>    information is linked to the individual making the claim
>>
>>
>> Regards,
>>
>> - Anil
>>
>> :- Anil John
>> :- Making Digital Services Secure and Trustworthy
>> :- https://blog.aniljohn.com
>>
>>
>> On Sun, Oct 12, 2014 at 3:16 PM, Colin Wallis 
>> wrote:
>>
>>>  Putting this split, back into one thread..
>>>
>>> =E2=80=A6  and pleading to folks to focus back on the vectors, or aspec=
ts, or
>>> =E2=80=98things=E2=80=99 - whatever we call them =E2=80=93 that the RP =
has an interest in.
>>>
>>> Justin is valiantly trying to re-state the purpose of his opening
>>> =E2=80=98vectors=E2=80=99 strawman =E2=80=93 always useful to refresh o=
ne=E2=80=99s memory by going back to
>>> look at them...
>>>
>>> His starting list of vectors was:
>>>
>>> Identity Proofing
>>>
>>> Credential Strength
>>>
>>> Assertion Presentation
>>>
>>> Operational Management
>>>
>>>
>>>
>>> If the discussion on LoAs offers any value here, it would be to add som=
e
>>> finer grained addition to the above (fairly coarse-grained) list.
>>>
>>>
>>>
>>> There=E2=80=99s already an acknowledgment that Operational Management m=
ay be
>>> composed of a range of concerns =E2=80=93 a mix of context dependent, t=
emporal and
>>> static (more vectors?) =E2=80=93 that influence the RP=E2=80=99s decisi=
on to accept or
>>> otherwise, an authenticated identity.
>>>
>>>
>>>
>>> If we got to a point where we could agree on what these vectors are,
>>> then we can have the (separate) debate about whether combining
>>> them/delineating them in some way is useful/helpful, or not.
>>>
>>>
>>>
>>> Cheers
>>>
>>> Colin
>>>
>>>
>>>
>>> *From:* vot [mailto:vot-bounces@ietf.org] *On Behalf Of *Richer, Justin
>>> P.
>>> *Sent:* Saturday, 11 October 2014 6:29 a.m.
>>> *To:* Bouma, Tim
>>> *Cc:* Ken Dagg; vot@ietf.org; swilson@lockstep.com.au
>>> *Subject:* Re: [VoT] Foundational questions of principle
>>>
>>>
>>>
>>> What we're trying to do with the "Vectors" approach here is to strike a
>>> balance between the overly-simplistic "single set of linear levels"
>>> approach that LoA gives us (that nobody on this list likes but all agre=
e
>>> that apps can actually do some level of processing with it) and the
>>> overly-complex "very long complex set of attributes" approach that Tim,
>>> Scott, and others have brought up (that seems more expressive and ideal=
 but
>>> no app is ever going to make sense of, or even try to). I think it's sa=
fe
>>> to say that neither extreme works and that a right answer probably lies=
 in
>>> the middle.
>>>
>>>
>>>
>>> So that's what this strawman is -- it's simultaneously less complex and
>>> more complex than the alternatives. Is it the right cut? Probably not, =
but
>>> it's at least a cutting point that we can push to either side. What I t=
hink
>>> we need to dutifully avoid is pushing it hard to either end. I really l=
ike
>>> the notion that even if the combinations of the vector values aren't
>>> directly compatible (as Steve says), then the building blocks would at
>>> least be comparable, giving a hope of defining a policy to translate
>>> between them when needed.
>>>
>>>
>>>
>>> Also, I wanted to key into the fact that there are several independent
>>> and orthogonal components here. Maybe it's not a set of levels that are
>>> tied together, but I think it is in someway a set of independent *thing=
s*
>>> that are tied together.
>>>
>>>
>>>
>>>  -- Justin
>>>
>>> =E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=
=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=
=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6.
>>>
>>>
>>>
>>> It may make sense to look at LOAs as something that is "coarse-grained"
>>> and a starting point.
>>>
>>>
>>>
>>> We all think it is not enough, but in the absence of the Borg showing u=
p
>>> to enforce a collective hive-mind across organizational boundaries, we =
can
>>> live with it and use it as a starting point for the discussion "What mo=
re
>>> do we need in order to let this person in the door?"
>>>
>>>
>>>
>>> And that is where RP implemented compensating controls can play a part.
>>> The challenge is that folks seem to conflate "things needed to ensure
>>> confidence in an identity" with "things needed to mitigate risk in the
>>> transaction" and who is (CSP or RP) responsible for what.
>>>
>>>
>>>
>>> Regards,
>>>
>>>
>>>
>>> - Anil
>>>
>>>
>>>
>>> :- Anil John
>>>
>>> :- Making Digital Services Secure and Trustworthy
>>>
>>> :- https://blog.aniljohn.com
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Oct 10, 2014 at 11:02 PM,  wrote:
>>>
>>>
>>> We are all agreed of course that RPs need to understand their risks,
>>> determine what's needed from any external process of identification or
>>> attribute attestation, communicate those needs to candidate APs, and fr=
om
>>> there, contract an acceptable provider.
>>>
>>> My question is whether or not a pigeonholed LOA helps at any point in
>>> this process.
>>>
>>> The devil is in the detail.  To my mind, LOA is an intermediate step
>>> that takes a detailed risk analysis, squeezes it into a bin (losing lot=
s of
>>> information as a result), which is then used to shortlist candidate
>>> providers, before going into detailed due diligence where all those det=
ails
>>> need to be put back on the table.
>>>
>>> I think we all know by now of cases where RPs have looked at candidate
>>> IdPs at a given LOA, and have come up with the request of "LOA two and =
a
>>> half" (this was mentioned at CIS 2014 more than once, and I have seen i=
t
>>> first hand in the UK IDAP).
>>>
>>> Clearly what's going on here is an RP's idea of say "LOA 2" differs fro=
m
>>> a given IdP's idea of LOA 2.  Moreover, the idea of LOA 2 must differ f=
rom
>>> one IdP to another IdP.  When people ask for "LOA 2.5" what they're ask=
ing
>>> for is a customised identification.  If LOA 2 isn't what it seems, then
>>> there cannot possibly be any such thing as a *standardised* LOA 2.5.  A=
ll
>>> we will get is fresh calls for "LOA 2.75 please".
>>>
>>> If RPs need to do detailed analysis of authentication needs, and get
>>> detailed verification of the actual ID proofing done by IdPs and APs, t=
hen
>>> I just don't see any point attaching the LOA label along the way.  It's
>>> misleading.
>>>
>>> Cheers,
>>>
>>> Steve.
>>>
>>> Stephen Wilson
>>> Lockstep
>>> http://lockstep.com.au
>>> Lockstep Consulting provides independent specialist advice and analysis
>>> on digital identity and privacy.  Lockstep Technologies develops unique
>>> new smart ID solutions that enhance privacy and prevent identity theft.
>>>
>>>
>>>
>>> On Oct 10, 2014, at 10:51 AM, Bouma, Tim 
>>> wrote:
>>>
>>>
>>>
>>>  I agree with Ken,
>>>
>>>
>>>
>>> When we developed levels of assurance (here in Canada) we did several
>>> things:
>>>
>>>
>>>
>>> =C2=B7         We defined them as levels of confidence required (Levels=
 1
>>> through 4)
>>>
>>> =C2=B7         We mapped these levels of confidence to a range of degre=
e of
>>> impacts.
>>>
>>> =C2=B7         We then specified separately identity assurance levels a=
nd
>>> credential assurance levels (and focused on credential first)
>>>
>>> =C2=B7         We also factored out likelihood in the assurance level
>>> assessment process. That made the assessments much less subjective.
>>>
>>>
>>>
>>> At the end of the day, as Ken states,  it=E2=80=99s the job the RP to u=
nderstand
>>> their risk (along with likelihood) and to communicate a standardized
>>> requirement back to a provider (AP)
>>>
>>> The AP is  accountable for providing a very prescribed component that
>>> fits into a larger system and a risk environment that they might not ha=
ve a
>>> full view into. The RP may put in provisions to share the risk with the=
 AP,
>>> or not but that entirely depends on the arrangement, but at least the R=
P
>>> and AP understand what=E2=80=99s on the table as a starting point.
>>>
>>>
>>>
>>> In Canada, we did that with the credential first, and are now figuring
>>> out identity (much harder).
>>>
>>>
>>>
>>> I also agree that =E2=80=98identity=E2=80=99 is just a set of attribute=
s =E2=80=93and  these
>>> identity attributes can vary between organizations or jurisdictions,
>>>
>>>
>>>
>>> As for the term =E2=80=98vectors=E2=80=99, I get the idea, but I think =
the community
>>> will think it=E2=80=99s too technical or esoteric. I like to think of a=
 =E2=80=98digital
>>> identity=E2=80=99 (or whatever you call it), when it shows up at your d=
igital front
>>> door, it is the product of a very long, complex supply chain, fraught w=
ith
>>> many risks and compromises. I may have confidence in certain pieces of,=
 but
>>> other I might not trust at all.
>>>
>>>
>>>
>>>
>>>
>>> Tim
>>>
>>>
>>>
>>>
>>>
>>> *From:* vot [mailto:vot-bounces@ietf.org] *On Behalf Of *Ken Dagg
>>> *Sent:* October-09-14 9:42 PM
>>> *To:* swilson@lockstep.com.au
>>> *Cc:* vot@ietf.org
>>> *Subject:* Re: [VoT] Foundational questions of principle
>>>
>>>
>>>
>>> Steve,
>>>
>>>
>>>
>>> As we have communicated in the past, I am a strong believer the an LOA
>>> designation is an indication of the processes/mechanisms that an IdP ha=
s
>>> undertaken. In other words, it is a communication tool. The choice is t=
he
>>> RPs. That is, an assertion at a specific LOA by an IdP/CSP/AP is one of=
 the
>>> mechanisms a RP should use to offset the authentication risk it has
>>> identified for the service it wants to deliver. In other words, it is t=
he
>>> risk of the RP that is paramount not the claims of
>>> an identity/credential/attribute/token provider.
>>>
>>>
>>>
>>> Like you, I am a strong believer that the determination of whether or
>>> not an identity is good enough is the responsibility of the RP. In my
>>> experience, they make that determination based upon a set of attributes
>>> they believe are necessary. If they trust that an IdP's assertion of
>>> identity covers the attributes they believe are required them they can
>>> accept the assertion. If it doesn't then that have to implement additio=
nal
>>> mechanisms to offset the residual risk.
>>>
>>>
>>>
>>> With respect to vectors of trust, I am interested in exploring what the=
y
>>> are and how they can be applied.
>>>
>>>
>>>
>>> Ken
>>>
>>> On Thursday, October 9, 2014,  wrote:
>>>
>>>
>>>
>>> First, to introduce myself, I am an identity and privacy researcher,
>>> analyst and consultant.  I've been involved in this since 1995, when I =
cut
>>> my teeth in PKI and smartcards (with the early companies that became
>>> Baltimore Technologies). Since then I've worked on identity management
>>> frameworks, regulations and standards.
>>>
>>>
>>>
>>> I subscribe to the old Italian proverb: "it's nice to trust but better
>>> not to".  Words matter and I wonder if we shouldn't be using the word t=
rust
>>> so much.
>>>
>>>
>>>
>>> More pragmatically, I note the very strong "Attributes" push of the pas=
t
>>> 18 months.  Andrew Nash, Anil John, myself and others have written abou=
t
>>> this.  The FIDO Alliance is all about authentication and attributes, an=
d
>>> they purposefully leave "identity" as a matter for others to work out
>>> further up the stack. The OID Foundation is promoting an Attributes
>>> Exchange Network "AXN" architecture.  New entrants like id.me (an NSTIC
>>> pilot participant) talk about attributes and avoid "identity".
>>>
>>>
>>>
>>> I mention all of this as a prelude to suggest that "vector of trust" is
>>> synonymous with "attribute". I wonder if it would be clearer to use pla=
in
>>> and current language rather than carry forward the fuzzy and I think ov=
erly
>>> ambitious idea of "trust"?
>>>
>>>
>>>
>>> Finally, I'd like to throw in my abiding concern that LOAs have
>>> foundered simply because it's difficult to pigeonhole risk. One party's
>>> idea of "medium" risk for instance will rarely map precisely to another=
's.
>>> I think people have been misled into thinking that an "LOA 3" identity
>>> should be be able to be used on its face (i.e. will "interoperate") at =
any
>>> "LOA 3" RP. Risk management is not so simple.
>>>
>>>
>>>
>>> The LOA paradigm borrows from Risk Management standards like ISO 31000
>>> which organisations use to plot their own risks internally typically on=
 a
>>> five scale (eg Negligible / Low / Medium / High / Grave). But risk
>>> management standards require that each organisation calibrates risk in =
its
>>> own business context and according to its own risk appetite. The risk o=
f a
>>> firewall breach for example at a startup social media company will be
>>> assessed differently by a big listed healthcare company. So organisatio=
n
>>> A can say the risk of event X is Low but B can say the risk of the same
>>> event is Medium.  As a result, LOAs do not inter-operate. They are base=
d on
>>> standards meant for intra-organisation risk management, not
>>> inter-organisation communication of risk assessments.
>>>
>>>
>>>
>>> So far with VoT we are adding more dimensions to the RPs' generic risk
>>> management decision making, and that's great.  But we are still
>>> pigeonholing the dimensions.
>>>
>>>
>>>
>>> I'm afraid the reality is that risk management will always be done
>>> locally.  And so it should be.  When an RP is making the decision to ac=
cept
>>> or reject a given subject, they will evaluate a range of attributes
>>> or signals.  The set of attributes that matters varies from one RP to t=
he
>>> next.  I think it's a great idea indeed to create guidance for evaluati=
ng
>>> attributes, and to coach RPs to look at all sorts of dimensions.  I jus=
t
>>> don't think it helps anyone to pigeonhole the risk ratings, because acr=
oss
>>> organisations, arguments about the boundaries between LOA 1/2/3/4 (that=
 is,
>>> policy mapping) will undo any efficiencies gained from the categorizati=
on.
>>>
>>>
>>>
>>> Cheers,
>>>
>>>
>>>
>>> Steve.
>>>
>>>
>>>
>>>
>>>
>>> Stephen Wilson
>>> Managing Director
>>> Lockstep Group
>>> http://lockstep.com.au
>>> Lockstep Consulting provides independent specialist advice and analysis
>>> on digital identity and privacy. Lockstep Technologies develops unique
>>> new smart ID solutions that enhance privacy and prevent identity theft.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> vot mailing list
>>> vot@ietf.org
>>> https://www.ietf.org/mailman/listinfo/vot
>>>
>>>
>>>
>>> _______________________________________________
>>> vot mailing list
>>> vot@ietf.org
>>> https://www.ietf.org/mailman/listinfo/vot
>>>
>>>
>>

--001a1134650634b5cf05054242be
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


    Ken,

    I think it depends on if the inten=
tion is to keep the 'vectors' flat or they can have some sort of an=
 hierarchy.=C2=A0 If the latter, sure.

    Regards,

    - Anil

    Regards,

    - Anil

    :- Anil John
    :- Making Digital Ser=
vices Secure and Trustworthy
    =

    

    On Sun, Oct 12, 2014 at 7:28 PM, Ken Dagg <kendaggtbs@gmail.com> wrote:
    Anil,
    Do you think that these could be sub vectors of the Identity=
 Proofing vector?
    =
Ken


    On Monday, October 13, 2014=
, Anil John <anilt=
j@gmail.com> wrote:
    Thank you Colin for herding the cats (Including myself there)!

    <=
/div>
    I would recommend splitting up the 'Identity Proofing' ve=
ctor into its component bits, rather than treating it like the current amor=
phous blob that it is right now:

    1. Identity Resolution=C2=A0-=C2=A0Establishing the u=
niqueness of an individual within a population
    2. Identity Val=
idation=C2=A0-=C2=A0Confirming the accuracy of identity informatio=
n claimed by an individual
    3. Identity Verification=
=C2=A0-=C2=A0Confirming that the claimed identity information is linked to =
the individual making the claim=C2=A0

    Rega=
rds,

    - Anil

    :- =
Anil John
    :- Making Digital Services Secure and Trustworthy
    :- https://blog.an=
iljohn.com

    

    On Sun, Oct 12, 2014 at 3:16 PM, Colin Walli=
s <Colin.Wallis@dia.govt.nz> wrote:
    






    

    

    Putting this split, back =
into one thread..
    

    =E2=80=A6 =C2=A0and plead=
ing to folks to focus back on the vectors, or aspects, or =E2=80=98things=
=E2=80=99 - whatever we call them =E2=80=93 that the RP has an interest in.

    

    Justin is valiantly tryin=
g to re-state the purpose of his opening =E2=80=98vectors=E2=80=99 strawman=
 =E2=80=93 always useful to refresh one=E2=80=99s memory by going back to l=
ook at them...
    

    His starting list of vect=
ors was:

    

    Identity Proofing<=
u>
    

    Credential Strength
    

    Assertion Presentation=

    

    Operational Management=

    

    =C2=A0
    

    If the discussion on LoAs=
 offers any value here, it would be to add some finer grained addition to t=
he above (fairly coarse-grained) list.
    

    =C2=A0
    

    There=E2=80=99s already a=
n acknowledgment that Operational Management may be composed of a range of =
concerns =E2=80=93 a mix of context dependent, temporal and static (more
 vectors?) =E2=80=93 that influence the RP=E2=80=99s decision to accept or =
otherwise, an authenticated identity.
    

    =C2=A0=C2=A0=C2=A0=C2=A0<=
u>
    

    If we got to a point wher=
e we could agree on what these vectors are, then we can have the (separate)=
 debate about whether combining them/delineating them in
 some way is useful/helpful, or not.
    

    =C2=A0
    

    Cheers
    

    Colin

    

    =C2=A0
    

    

    

    From: vot [mailto:vot-bounces@ietf.org]
On Behalf Of Richer, Justin P.
    
Sent: Saturday, 11 October 2014 6:29 a.m.
    
To: Bouma, Tim
    
Cc: Ken Dagg; vot@ietf.org; swilson@lockstep.com.au
    
Subject: Re: [VoT] Foundational questions of principle=

    

    

    

    =C2=A0
    

    What we're trying to do with the "Vectors&q=
uot; approach here is to strike a balance between the overly-simplistic &qu=
ot;single set of linear levels" approach that LoA gives us (that nobod=
y on this list likes but all agree that apps can actually
 do some level of processing with it) and the overly-complex "very lon=
g complex set of attributes" approach that Tim, Scott, and others have=
 brought up (that seems more expressive and ideal but no app is ever going =
to make sense of, or even try to). I think
 it's safe to say that neither extreme works and that a right answer pr=
obably lies in the middle.=C2=A0

    

    

    =C2=A0
    

    

    

    So that's what this strawman is -- it's simu=
ltaneously less complex and more complex than the alternatives. Is it the r=
ight cut? Probably not, but it's at least a cutting point that we can p=
ush to either side. What I think we need to dutifully
 avoid is pushing it hard to either end. I really like the notion that even=
 if the combinations of the vector values aren't directly compatible (a=
s Steve says), then the building blocks would at least be comparable, givin=
g a hope of defining a policy to translate
 between them when needed.=C2=A0
    

    

    

    =C2=A0
    

    

    

    Also, I wanted to key into the fact that there are s=
everal independent and orthogonal components here. Maybe it's not a set=
 of levels that are tied together, but I think it is in someway a set of in=
dependent *things* that are tied together.
    

    

    

    =C2=A0
    

    

    

    =C2=A0-- Justin
    

    =E2=80=A6=E2=80=A6=E2=80=
=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=
=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=
=80=A6=E2=80=A6=E2=80=A6.
    

    =C2=A0
    

    It may make sense to look at LOAs as something that =
is "coarse-grained" and a starting point.=C2=A0
    

    =C2=A0
    

    We all think it is not enough, but in the absence of=
 the Borg showing up to enforce a collective hive-mind across organizationa=
l boundaries, we can live with it and use it as a starting point for the di=
scussion "What more do we need in
 order to let this person in the door?"
    

    =C2=A0
    

    And that is where RP implemented compensating contro=
ls can play a part. The challenge is that folks seem to conflate "thin=
gs needed to ensure confidence in an identity" with "things neede=
d to mitigate risk in the transaction" and who is
 (CSP or RP) responsible for what.
    

    =C2=A0
    

    Regards,
    

    =C2=A0
    

    - Anil
    

    =C2=A0
    

    :- Anil John
    

    :- Making Digital Services Secure and Trustworthy=

    

    :- https://blog.aniljohn.com
    

    =C2=A0
    

    =C2=A0
    

    On Fri, Oct 10, 2014 at 11:02 PM, <swilson@loc=
kstep.com.au> wrote:
    


    
We are all agreed of course that RPs need to understand their risks, determ=
ine what's needed from any external process of identification or attrib=
ute attestation, communicate those needs to candidate APs, and from there, =
contract an acceptable provider.
    

    
My question is whether or not a pigeonholed LOA helps at any point in this =
process.
    

    
The devil is in the detail.=C2=A0 To my mind, LOA is an intermediate step t=
hat takes a detailed risk analysis, squeezes it into a bin (losing lots of =
information as a result), which is then used to shortlist candidate provide=
rs, before going into detailed due diligence
 where all those details need to be put back on the table.
    

    
I think we all know by now of cases where RPs have looked at candidate IdPs=
 at a given LOA, and have come up with the request of "LOA two and a h=
alf" (this was mentioned at CIS 2014 more than once, and I have seen i=
t first hand in the UK IDAP).
    

    
Clearly what's going on here is an RP's idea of say "LOA 2&quo=
t; differs from a given IdP's idea of LOA 2.=C2=A0 Moreover, the idea o=
f LOA 2 must differ from one IdP to another IdP.=C2=A0 When people ask for =
"LOA 2.5" what they're asking for is a customised identificat=
ion.=C2=A0
 If LOA 2 isn't what it seems, then there cannot possibly be any such t=
hing as a *standardised* LOA 2.5.=C2=A0 All we will get is fresh calls for =
"LOA 2.75 please".
    

    
If RPs need to do detailed analysis of authentication needs, and get detail=
ed verification of the actual ID proofing done by IdPs and APs, then I just=
 don't see any point attaching the LOA label along the way.=C2=A0 It=
9;s misleading.
    

    
Cheers,
    

    
Steve.
    

    
Stephen Wilson
    
Lockstep
    
http://lockstep.com.au=

    
Lockstep Consulting provides independent specialist advice and analysis
    
on digital identity and privacy.=C2=A0 Lockstep Technologies develops uniqu=
e
    
new smart ID solutions that enhance privacy and prevent identity theft.
    

    

    

    

    

    =C2=A0
    

    

    

    On Oct 10, 2014, at 10:51 AM, Bouma, Tim <Tim.=
Bouma@tbs-sct.gc.ca> wrote:
    

    


    

    

    

    

    I agree wi=
th Ken,
    

    =C2=A0
    

    When we de=
veloped levels of assurance (here in Canada) we did several things:<=
span lang=3D"EN-CA">
    

    =C2=A0
    

    =C2=B7=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0
We de=
fined them as levels of confidence required (Levels 1 through 4)
    

    =C2=B7=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0
We ma=
pped these levels of confidence to a range of degree of impacts.
    

    =C2=B7=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0
We th=
en specified separately identity assurance levels and credential assurance =
levels (and focused on credential first)=

    

    =C2=B7=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0
We al=
so factored out likelihood in the assurance level assessment process. That =
made the assessments much less subjective.
    

    =C2=A0
    

    At the end=
 of the day, as Ken states, =C2=A0it=E2=80=99s the job the RP to understand=
 their risk (along with likelihood) and to communicate a standardized requi=
rement
 back to a provider (AP)

    The AP is =
=C2=A0accountable for providing a very prescribed component that fits into =
a larger system and a risk environment that they might not have
 a full view into. The RP may put in provisions to share the risk with the =
AP, or not but that entirely depends on the arrangement, but at least the R=
P and AP understand what=E2=80=99s on the table as a starting point.=

    

    =C2=A0
    

    In Canada,=
 we did that with the credential first, and are now figuring out identity (=
much harder).
    

    =C2=A0
    

    I also agr=
ee that =E2=80=98identity=E2=80=99 is just a set of attributes =E2=80=93and=
 =C2=A0these identity attributes can vary between organizations or jurisdic=
tions,
    

    =C2=A0
    

    As for the=
 term =E2=80=98vectors=E2=80=99, I get the idea, but I think the community =
will think it=E2=80=99s too technical or esoteric. I like to think of a =E2=
=80=98digital identity=E2=80=99
 (or whatever you call it), when it shows up at your digital front door, it=
 is the product of a very long, complex supply chain, fraught with many ris=
ks and compromises. I may have confidence in certain pieces of, but other I=
 might not trust at all.

    =C2=A0
    

    =C2=A0
    

    Tim=

    

    =C2=A0
    

    =C2=A0
    

    From: vot [mailto:vot-bounc=
es@ietf.org]
On Behalf Of Ken Dagg
    
Sent: October-09-14 9:42 PM
    
To: swilson@lockstep.com.au
    
Cc: vot@ietf.org
    
Subject: Re: [VoT] Foundational questions of principle
    

    =C2=A0
    

    Steve,
    

    

    =C2=A0
    

    

    

    As we have communicated in=C2=
=A0the past, I am a strong believer the an LOA designation is an indication=
 of the processes/mechanisms that an=C2=A0IdP has undertaken. In other word=
s, it is a communication tool.=C2=A0The choice is the
 RPs. That is, an=C2=A0assertion at a specific LOA by an=C2=A0IdP/CSP/AP=C2=
=A0is one of the mechanisms a RP should use to offset the authentication ri=
sk it has identified for the service it wants to deliver. In other words, i=
t is the risk of the RP that is paramount not the
 claims of an=C2=A0identity/credential/attribute/token provider.<=
/u>
    

    

    

    =C2=A0
    

    

    

    Like you, I am a strong believe=
r that the determination of whether or not an identity is good enough is th=
e responsibility of the RP. In my experience, they make that determination =
based upon a set of attributes they
 believe are necessary. If they trust that an IdP's assertion of identi=
ty covers the attributes they believe are=C2=A0required them they can accep=
t the assertion. If it doesn't then that have to implement additional m=
echanisms to offset the residual risk.
    

    

    

    =C2=A0
    

    

    

    With respect to vectors of trus=
t, I am interested in exploring what they are and how they can be applied.<=
u>
    

    

    

    =C2=A0
    

    

    

    Ken
    

    
On Thursday, October 9, 2014, <swilson@lockstep.com.au> wrote:=

    

    

    =C2=A0
    

    

    

    First, to introduce myself=
, I am an identity and privacy researcher, analyst and consultant.=C2=A0 I&=
#39;ve been involved in this since 1995, when I cut my teeth in PKI
 and smartcards (with the early companies that became Baltimore Technologie=
s). Since then I've worked on identity management frameworks, regulatio=
ns and standards. =C2=A0

    

    

    =C2=A0
    

    

    

    I subscribe to the old Ita=
lian proverb: "it's nice to trust but better not to".=C2=A0 W=
ords matter and I wonder if we shouldn't be using the word trust so muc=
h. =C2=A0
    

    

    

    =C2=A0
    

    

    

    More pragmatically, I note=
 the very strong "Attributes" push of the past 18 months.=C2=A0 A=
ndrew Nash, Anil John, myself and others have written about this.=C2=A0 The=
 FIDO
 Alliance is all about authentication and attributes, and they purposefully=
 leave "identity" as a matter for others to work out further up t=
he stack. The OID Foundation is promoting an Attributes Exchange Network &q=
uot;AXN" architecture.=C2=A0 New entrants like
id.me (an NSTIC pilot parti=
cipant) talk about attributes and avoid "identity".=C2=A0<=
span lang=3D"EN-CA">
    

    

    

    =C2=A0
    

    

    

    I mention all of this as a=
 prelude to suggest that "vector of trust" is synonymous with &qu=
ot;attribute". I wonder if it would be clearer to use plain and curren=
t language
 rather than carry forward the fuzzy and I think overly ambitious idea of &=
quot;trust"?=C2=A0

    

    

    =C2=A0
    

    

    

    Finally, I'd like to t=
hrow in my abiding concern that LOAs have foundered simply because it's=
 difficult to pigeonhole risk. One party's idea of "medium" r=
isk for
 instance will rarely map precisely to another's. I think people have b=
een misled into thinking that an "LOA 3" identity should be be ab=
le to be used on its face (i.e. will "interoperate") at any "=
;LOA 3" RP. Risk management is not so simple.=C2=A0
    

    

    

    =C2=A0
    

    

    

    The LOA paradigm borrows f=
rom Risk Management standards like ISO 31000 which=C2=A0organisations use t=
o=C2=A0plot=C2=A0their own risks internally typically on a five scale (eg
 Negligible / Low / Medium / High / Grave).=C2=A0But=C2=A0risk management=
=C2=A0standards require that each organisation calibrates risk in its own b=
usiness context and according to its=C2=A0own risk appetite. The risk of a =
firewall breach for example at a startup social media
 company will be assessed differently by a big listed healthcare company.=
=C2=A0So organisation A=C2=A0can say the risk of event X is Low but B can s=
ay the risk of the same event is Medium.=C2=A0 As=C2=A0a result, LOAs do no=
t inter-operate. They are based on standards meant for
 intra-organisation risk management, not inter-organisation communication o=
f=C2=A0risk assessments.=C2=A0
    

    

    

    =C2=A0
    

    

    

    So far with VoT we are add=
ing more dimensions to the RPs' generic risk management decision making=
, and that's great.=C2=A0 But we are still pigeonholing the dimensions.=

    

    

    

    =C2=A0
    

    

    

    I'm afraid the reality=
 is that risk management will always be done locally.=C2=A0 And so it shoul=
d be.=C2=A0 When an RP is making=C2=A0the decision to accept or reject a gi=
ven
 subject, they will evaluate a range of attributes or=C2=A0signals.=C2=A0 T=
he set of attributes that matters varies from one RP to the next.=C2=A0 I t=
hink it's a great idea indeed to create guidance for evaluating attribu=
tes, and to coach RPs to look at all sorts of dimensions.=C2=A0
 I just don't think it helps anyone to pigeonhole the risk ratings, bec=
ause across organisations, arguments about the boundaries between LOA 1/2/3=
/4 (that is, policy mapping) will=C2=A0undo any efficiencies gained from th=
e categorization. =C2=A0

    

    

    =C2=A0
    

    

    

    Cheers,=C2=A0
    

    

    

    =C2=A0
    

    

    

    Steve.
    

    

    

    =C2=A0
    

    

    

    =C2=A0
    

    

    

    Stephen Wilson
    
Managing Director
    
Lockstep Group
    
http://lockstep.com.a=
u
    
Lockstep Consulting provides independent specialist advice and analysis 
on digital identity and privacy. Lockstep Technologies develops unique 
    
new smart ID solutions that enhance privacy and prevent identity theft.
    

    

    

    =C2=A0
    

    

    

    =C2=A0
    

    

    

    =C2=A0
    

    

    

    

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

    

    =C2=A0
    

    

    

    


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


    

    


    

--001a1134650634b5cf05054242be--


From nobody Sun Oct 12 18:52:31 2014
Return-Path: 
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BDB51A9166 for ; Sun, 12 Oct 2014 18:52:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.598
X-Spam-Level: 
X-Spam-Status: No, score=-0.598 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, MSGID_FROM_MTA_HEADER=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNJF55VKcKHG for ; Sun, 12 Oct 2014 18:52:22 -0700 (PDT)
Received: from smtp.safecom.net.nz (smtp.safecom.net.nz [125.236.41.139]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D6761A9218 for ; Sun, 12 Oct 2014 18:52:21 -0700 (PDT)
Received: from s111-0006-lnv01 (Not Verified[127.0.0.1]) by smtp.safecom.net.nz (using TLS: SSLv23) id ; Mon, 13 Oct 2014 14:48:37 +1300
Message-ID: <147EE18440E5AF44834B220ED35BA530D32F0CAF@WLGPRDMBX01.dia.govt.nz>
MIME-Version: 1.0
X-MessageIsInfected: false
Received: from 161-65-142-21.ip.fx.net.nz (EHLO WLGPRDMM01.dia.govt.nz) ([127.0.0.1]) by s111-0006-lnv01 (JAMES SMTP Server ) with ESMTP ID 308495443; Mon, 13 Oct 2014 14:52:18 +1300 (NZDT)
Received: from WLGPRDCAS02.dia.govt.nz (Not Verified[127.0.0.1]) by WLGPRDMM01.dia.govt.nz with MailMarshal (v7, 1, 1, 5205) (using TLS: SSLv23) id ; Mon, 13 Oct 2014 14:50:45 +1300
Received: from WLGPRDMBX01.dia.govt.nz ([fe80::13e:8e96:252b:e0d1]) by WLGPRDCAS02.dia.govt.nz ([127.0.0.1]) with mapi id 14.03.0146.000; Mon, 13 Oct 2014 14:52:17 +1300
From: Colin Wallis 
To: 'Anil John' , Ken Dagg , "vot@ietf.org" 
Thread-Topic: [VoT] Foundational questions of principle
Thread-Index: AQHP4/5Iig05S+YmNEKjLvPcZpUGz5wo0ccAgADcpgCAACvnAIAC9xoQ//9zcACAAAGngIAAAjcAgADx8zA=
Date: Mon, 13 Oct 2014 01:50:44 +0000
References: <1412885935.58929166@apps.rackspace.com>  <20141010145142.51DBE1A90E3@ietfa.amsl.com> <6A0CFC85-F8F5-43F5-B02F-09720E7164F4@mitre.org> <147EE18440E5AF44834B220ED35BA530D32F0A2E@WLGPRDMBX01.dia.govt.nz>   
In-Reply-To: 
Accept-Language: en-US, en-NZ
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.29.0.162]
Content-Type: multipart/alternative; boundary="_000_147EE18440E5AF44834B220ED35BA530D32F0CAFWLGPRDMBX01diag_"
X-sdp.mm2006: true
Archived-At: http://mailarchive.ietf.org/arch/msg/vot/Kb-dDqu2HuK4HBCkzSRYenEEASU
Subject: Re: [VoT] Foundational questions of principle
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Vectors of Trust discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Oct 2014 01:52:29 -0000

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

PDxJIHRoaW5rIGl0IGRlcGVuZHMgb24gaWYgdGhlIGludGVudGlvbiBpcyB0byBrZWVwIHRoZSAn
dmVjdG9ycycgZmxhdCBvciB0aGV5IGNhbiBoYXZlIHNvbWUgc29ydCBvZiBhbiBoaWVyYXJjaHk+
Pi4NCkkgdGhpbmsgdGhhdCBpcyBhIOKAmHRiZOKAmSBBbmlsLg0KV2UgbWF5IGhhdmUgYSBiZXR0
ZXIgaWRlYSBvbmNlIHRoZSBjb25jZXB0IGlzIGRldmVsb3BlZCBhIGJpdCBmdXJ0aGVyLg0KR29v
ZCBmaW5lIGdyYWluaW5nIG9uIElkZW50aXR5IFByb29maW5nIHRoZXJlLi4gIHVzZWZ1bC4NCg0K
TG9va2luZyBiZWxvdyBhdCBLZW7igJlzIHJlc3BvbnNlOg0KVG8gS2Vu4oCZcyBzdWdnZXN0aW9u
IHF1YWxpZmllZCBieSBoaXMgcXVlc3Rpb24vYXNzdW1wdGlvbi4uDQo8PCBDcmVkZW50aWFsIFN0
cmVuZ3RoIGRlYWxzIHdpdGggdGhlIGJpbmRpbmcgb2YgYW4gaWRlbnRpdHkgdG8gYSB0b2tlbj4+
DQouLiBpcyBhbG9uZyB0aGUgbGluZXMgSnVzdGluIGRlc2NyaWJlZCBpdCBJTUhPLCBzbyB5ZWEs
IEkgdGhpbmsg4oCYdG9rZW4gcHJvb2ZpbmfigJkgY291bGQgYmUgYW5vdGhlciB2ZWN0b3Ivc3Vi
IHZlY3Rvci4NCg0KVG8gdGhlIGNvbW1lbnQgYWJvdXQgdGhlIHZhbHVlIG9mL21lYXN1cmVtZW50
IG9mIHZlY3RvcnMgYW5kLg0KPDxob3cgdGhleSBhcHBseSB0byB0aGUgZW50aXR5IHRoYXQgaXMg
dGhlIHJlY2lwaWVudCBvZiB0aGUgb3V0cHV0IG9mIHRoZSB3b3JrPj4NCi4uKHR5cGljYWxseSB0
aGUgUlAgSSBndWVzcykgdGhlbiB3ZSBjb21lIGJhY2sgdG8gc29tZSBtYWNoaW5lIHByb2Nlc3Mt
YWJsZSB3YXkgdGhhdCB0aGUgUlAgY2FuIGV4cHJlc3MgdGhlIHZlY3RvciB2YWx1ZXMgb2YgdGhl
IHJpc2sgb2YgdGhhdCBhdXRoZW50aWNhdGlvbiBpbnN0YW5jZS9zZXJ2aWNlL3RyYW5zYWN0aW9u
IHdoaWNoLCBhcyBTdGV2ZSBpbmRpY2F0ZXMsIG1pZ2h0IHBvc3NpYmx5IGJlIGRpZmZlcmVudCBm
b3IgZWFjaCBhbmQgZXZlcnkgdHJhbnNhY3Rpb24vbG9jYXRpb24vY29udGV4dC4NCg0KSnVzdGlu
IG9mZmVyZWQgdXAgYSBraW5kIG9mIGNvZGlmaWVkIHdheSBvZiBleHByZXNzaW5nIHNwZWNpZmlj
IHZlY3RvciB2YWx1ZXMgd2l0aCBhIG1hcmtlciBsZXR0ZXIgYW5kIGNhdGVnb3J5IG51bWJlciAo
c2FtbCBtZCBpb3AgaGFzIGZvciBzb21lIHRpbWUgbm93IGFzIFNjb3R0IG1lbnRpb25lZCksIGJ1
dCB0aGUgdHJpY2sgd291bGQgYmUgIHRvIG1ha2UgYSBkaXN0aW5jdGlvbiBiZXR3ZWVuIHdoYXQg
dmVjdG9yIHZhbHVlcyB0aGUgUlAgcmVxdWlyZXMgKGEgdmVjdG9yL3N1YiB2ZWN0b3IpLCBhbmQg
d2hhdCBpcyDigJhvbiBvZmZlcuKAmSBmcm9tIHByb3ZpZGVyIHBhcnRpZXMgKGFub3RoZXIgdmVj
dG9yL3N1YiB2ZWN0b3IpLCBidXQgc3RpbGwgaW4gYSBjb2RpZmllZCB3YXkgY29uc3VtYWJsZSBi
eSBhbGwgcGFydGllcy4gUmVkdWNpbmcgdGhpcyBkb3duIGZyb20gYSBjb21wbGV4IHNldCBvZiB2
YWx1ZXMsIHRvIDMtNSBWZWN0b3JzLCB3aXRoIG11bHRpcGxlIHN1YiB2ZWN0b3JzICphbmQqIG1h
a2UgaXQgbWVhbmluZ2Z1bCBhbmQgcHJvY2Vzcy1hYmxlLCBpcyBvbmUgbW90aGVyIG9mIGEgY2hh
bGxlbmdlLi4NCg0KQnV0IGFscmVhZHkgd2UgaGF2ZSBtb3ZlZCBiZXlvbmQgdGhlIHByZXR0eSBi
bHVudCBpbnN0cnVtZW50IHRoYXQgaXMgTG9BLi4gYW5kIGhhdmUgbm90IHlldCBnb25lIHRvIHRo
ZSBvdGhlciBleHRyZW1lIGVuZCBvZiB0aGUgKOKAmGFsbCBmaW5lIGdyYWluZWQvZGUtY29tcG9z
ZWTigJkpIHNwZWN0cnVtLCBzbyB0aGF0IGlzIGdvb2QuDQoNCldobyBrbm93cyBob3cgbXVjaCBw
cm9ncmVzcyB3ZSBjb3VsZCBtYWtlIGlmIHdlIGtlZXAgdGhpbmtpbmfigKYg4pi6DQoNCkNoZWVy
cw0KQ29saW4NCg0KRnJvbTogdm90IFttYWlsdG86dm90LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl
aGFsZiBPZiBBbmlsIEpvaG4NClNlbnQ6IE1vbmRheSwgMTMgT2N0b2JlciAyMDE0IDEyOjM2IHAu
bS4NClRvOiBLZW4gRGFnZzsgdm90QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1ZvVF0gRm91bmRh
dGlvbmFsIHF1ZXN0aW9ucyBvZiBwcmluY2lwbGUNCg0KS2VuLA0KDQpJIHRoaW5rIGl0IGRlcGVu
ZHMgb24gaWYgdGhlIGludGVudGlvbiBpcyB0byBrZWVwIHRoZSAndmVjdG9ycycgZmxhdCBvciB0
aGV5IGNhbiBoYXZlIHNvbWUgc29ydCBvZiBhbiBoaWVyYXJjaHkuICBJZiB0aGUgbGF0dGVyLCBz
dXJlLg0KDQpSZWdhcmRzLA0KDQotIEFuaWwNCg0KUmVnYXJkcywNCg0KLSBBbmlsDQoNCjotIEFu
aWwgSm9obg0KOi0gTWFraW5nIERpZ2l0YWwgU2VydmljZXMgU2VjdXJlIGFuZCBUcnVzdHdvcnRo
eQ0KOi0gaHR0cHM6Ly9ibG9nLmFuaWxqb2huLmNvbQ0KDQoNCk9uIFN1biwgT2N0IDEyLCAyMDE0
IGF0IDc6MjggUE0sIEtlbiBEYWdnIDxrZW5kYWdndGJzQGdtYWlsLmNvbTxtYWlsdG86a2VuZGFn
Z3Ric0BnbWFpbC5jb20+PiB3cm90ZToNCkFuaWwsDQpEbyB5b3UgdGhpbmsgdGhhdCB0aGVzZSBj
b3VsZCBiZSBzdWIgdmVjdG9ycyBvZiB0aGUgSWRlbnRpdHkgUHJvb2ZpbmcgdmVjdG9yPw0KS2Vu
DQoNCg0KT24gTW9uZGF5LCBPY3RvYmVyIDEzLCAyMDE0LCBBbmlsIEpvaG4gPGFuaWx0akBnbWFp
bC5jb208bWFpbHRvOmFuaWx0akBnbWFpbC5jb20+PiB3cm90ZToNClRoYW5rIHlvdSBDb2xpbiBm
b3IgaGVyZGluZyB0aGUgY2F0cyAoSW5jbHVkaW5nIG15c2VsZiB0aGVyZSkhDQoNCkkgd291bGQg
cmVjb21tZW5kIHNwbGl0dGluZyB1cCB0aGUgJ0lkZW50aXR5IFByb29maW5nJyB2ZWN0b3IgaW50
byBpdHMgY29tcG9uZW50IGJpdHMsIHJhdGhlciB0aGFuIHRyZWF0aW5nIGl0IGxpa2UgdGhlIGN1
cnJlbnQgYW1vcnBob3VzIGJsb2IgdGhhdCBpdCBpcyByaWdodCBub3c6DQoNCg0KICAxLiAgSWRl
bnRpdHkgUmVzb2x1dGlvbiAtIEVzdGFibGlzaGluZyB0aGUgdW5pcXVlbmVzcyBvZiBhbiBpbmRp
dmlkdWFsIHdpdGhpbiBhIHBvcHVsYXRpb24NCiAgMi4gIElkZW50aXR5IFZhbGlkYXRpb24gLSBD
b25maXJtaW5nIHRoZSBhY2N1cmFjeSBvZiBpZGVudGl0eSBpbmZvcm1hdGlvbiBjbGFpbWVkIGJ5
IGFuIGluZGl2aWR1YWwNCiAgMy4gIElkZW50aXR5IFZlcmlmaWNhdGlvbiAtIENvbmZpcm1pbmcg
dGhhdCB0aGUgY2xhaW1lZCBpZGVudGl0eSBpbmZvcm1hdGlvbiBpcyBsaW5rZWQgdG8gdGhlIGlu
ZGl2aWR1YWwgbWFraW5nIHRoZSBjbGFpbQ0KDQpSZWdhcmRzLA0KDQotIEFuaWwNCg0KOi0gQW5p
bCBKb2huDQo6LSBNYWtpbmcgRGlnaXRhbCBTZXJ2aWNlcyBTZWN1cmUgYW5kIFRydXN0d29ydGh5
DQo6LSBodHRwczovL2Jsb2cuYW5pbGpvaG4uY29tDQoNCkNvbGluLA0KDQpHb29kIHBvaW50IHRv
IG1vdmUgdGhlIHRocmVhZCBiYWNrIHRvIGl0cyBvcmlnaW5hbCB0b3BpYy4NCg0KSSB3b3VsZCBz
dWdnZXN0IHRoYXQgdGhlcmUgaXMgb25lIG1vcmUgdmVjdG9yOiB0b2tlbiBwcm9vZmluZy4gVGhp
cyB2ZWN0b3Igd291bGQgYmUgc2ltaWxhciBpbiBuYXR1cmUgdG8gdGhlIGlkZW50aXR5IHByb29m
aW5nIHZlY3RvciBvbmx5IGZvY3VzZWQgb24gdGhlIHRva2VuIHJhdGhlciB0aGFuIHRoZSBpZGVu
dGl0eS4NCg0KSSBoYXZlIG5vdCBoYWQgYSBjaGFuY2UgdG8gcmV2aWV3IHRoZSBvcmlnaW5hbCBw
YXBlciB0byBrbm93IHdoYXQgaXQgc2F5cyBhYm91dCB0aGUgb3RoZXIgdmVjdG9ycyAoSSBhbSBz
dXBwb3NlZCB0byBiZSBvbiBob2xpZGF5cykuIEkgYW0gYXNzdW1pbmcgdGhhdCBJZGVudGl0eSBQ
cm9vZmluZyBkZWFscyB3aXRoIGhvdyBhbiBJZGVudGl0eSBpcyBwcm9vZmVkLCBDcmVkZW50aWFs
IFN0cmVuZ3RoIGRlYWxzIHdpdGggdGhlIGJpbmRpbmcgb2YgYW4gaWRlbnRpdHkgdG8gYSB0b2tl
biwgYW5kIEFzc2VydGlvbiBQcmVzZW50YXRpb24gZGVhbHMgd2l0aCB3aGF0IHRoZSBJZFAgZ29l
cyB0aHJvdWdoIGluIG9yZGVyIHRvIGlzc3VlIGFuIGFzc2VydGlvbi4gV2hhdCBJIGJlbGlldmUg
aXMgaW50ZXJlc3RpbmcgaXMgdGhhdCB0aGVzZSB2ZWN0b3JzIGFyZSBhcHBsaWNhYmxlIHRvIGFu
eSBlbnRpdHkgdGhhdCBkb2VzIHRoZSB3b3JrLiBXaGF0IGlzIG9mIHBvdGVudGlhbCBpbnRlcmVz
dCBpcyBob3cgdGhleSBhcHBseSB0byB0aGUgZW50aXR5IHRoYXQgaXMgdGhlIHJlY2lwaWVudCBv
ZiB0aGUgb3V0cHV0IG9mIHRoZSB3b3JrLg0KDQpJIGFncmVlIHRoYXQgT3BlcmF0aW9uYWwgTWFu
YWdlbWVudCBpcyBhbiBpbnRlcmVzdGluZywgYnV0IGV4dHJlbWVseSBpbXBvcnRhbnQsIHZlY3Rv
ciB0aGF0IGNvdWxkIGhhdmUgbWFueSBzdWItdmVjdG9ycy4NCg0KV2hpbGUgdGhlIExvQSBkaXNj
dXNzaW9uIHNlZW1lZCB0byBiZSBvZmYgdHJhY2ssIEkgd291bGQgc3VnZ2VzdCB0aGF0IGl0IGlz
IHBhcnQgb2YgdGhlIGRpc2N1c3Npb24gYmVjYXVzZSBMb0EgKHJlZ2FyZGxlc3Mgb2YgaG93IG1h
bnkgbGV2ZWxzKSBzaG91bGQgYmUgYSBtZWFzdXJlIG9mIGFuZCBhIG1lYW5zIG9mIGNvbW11bmlj
YXRpbmcgaG93IG11Y2ggZWZmb3J0IGhhcyB1bmRlcnRha2VuIGJ5IHRoZSBwYXJ0eSBkb2luZyB0
aGUgd29yayB0byB0aGUgZW50aXR5IHRoYXQgaXMgcmVjZWl2aW5nIHRoZSBvdXRwdXQgb2YgdGhh
dCB3b3JrLg0KDQpLZW4NCg0KDQpPbiBTdW4sIE9jdCAxMiwgMjAxNCBhdCAzOjE2IFBNLCBDb2xp
biBXYWxsaXMgPENvbGluLldhbGxpc0BkaWEuZ292dC5uejxtYWlsdG86Q29saW4uV2FsbGlzQGRp
YS5nb3Z0Lm56Pj4gd3JvdGU6DQpQdXR0aW5nIHRoaXMgc3BsaXQsIGJhY2sgaW50byBvbmUgdGhy
ZWFkLi4NCuKApiAgYW5kIHBsZWFkaW5nIHRvIGZvbGtzIHRvIGZvY3VzIGJhY2sgb24gdGhlIHZl
Y3RvcnMsIG9yIGFzcGVjdHMsIG9yIOKAmHRoaW5nc+KAmSAtIHdoYXRldmVyIHdlIGNhbGwgdGhl
bSDigJMgdGhhdCB0aGUgUlAgaGFzIGFuIGludGVyZXN0IGluLg0KSnVzdGluIGlzIHZhbGlhbnRs
eSB0cnlpbmcgdG8gcmUtc3RhdGUgdGhlIHB1cnBvc2Ugb2YgaGlzIG9wZW5pbmcg4oCYdmVjdG9y
c+KAmSBzdHJhd21hbiDigJMgYWx3YXlzIHVzZWZ1bCB0byByZWZyZXNoIG9uZeKAmXMgbWVtb3J5
IGJ5IGdvaW5nIGJhY2sgdG8gbG9vayBhdCB0aGVtLi4uDQpIaXMgc3RhcnRpbmcgbGlzdCBvZiB2
ZWN0b3JzIHdhczoNCklkZW50aXR5IFByb29maW5nDQpDcmVkZW50aWFsIFN0cmVuZ3RoDQpBc3Nl
cnRpb24gUHJlc2VudGF0aW9uDQpPcGVyYXRpb25hbCBNYW5hZ2VtZW50DQoNCklmIHRoZSBkaXNj
dXNzaW9uIG9uIExvQXMgb2ZmZXJzIGFueSB2YWx1ZSBoZXJlLCBpdCB3b3VsZCBiZSB0byBhZGQg
c29tZSBmaW5lciBncmFpbmVkIGFkZGl0aW9uIHRvIHRoZSBhYm92ZSAoZmFpcmx5IGNvYXJzZS1n
cmFpbmVkKSBsaXN0Lg0KDQpUaGVyZeKAmXMgYWxyZWFkeSBhbiBhY2tub3dsZWRnbWVudCB0aGF0
IE9wZXJhdGlvbmFsIE1hbmFnZW1lbnQgbWF5IGJlIGNvbXBvc2VkIG9mIGEgcmFuZ2Ugb2YgY29u
Y2VybnMg4oCTIGEgbWl4IG9mIGNvbnRleHQgZGVwZW5kZW50LCB0ZW1wb3JhbCBhbmQgc3RhdGlj
IChtb3JlIHZlY3RvcnM/KSDigJMgdGhhdCBpbmZsdWVuY2UgdGhlIFJQ4oCZcyBkZWNpc2lvbiB0
byBhY2NlcHQgb3Igb3RoZXJ3aXNlLCBhbiBhdXRoZW50aWNhdGVkIGlkZW50aXR5Lg0KDQpJZiB3
ZSBnb3QgdG8gYSBwb2ludCB3aGVyZSB3ZSBjb3VsZCBhZ3JlZSBvbiB3aGF0IHRoZXNlIHZlY3Rv
cnMgYXJlLCB0aGVuIHdlIGNhbiBoYXZlIHRoZSAoc2VwYXJhdGUpIGRlYmF0ZSBhYm91dCB3aGV0
aGVyIGNvbWJpbmluZyB0aGVtL2RlbGluZWF0aW5nIHRoZW0gaW4gc29tZSB3YXkgaXMgdXNlZnVs
L2hlbHBmdWwsIG9yIG5vdC4NCg0KQ2hlZXJzDQpDb2xpbg0KDQpGcm9tOiB2b3QgW21haWx0bzp2
b3QtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJpY2hlciwgSnVzdGluIFAuDQpTZW50
OiBTYXR1cmRheSwgMTEgT2N0b2JlciAyMDE0IDY6MjkgYS5tLg0KVG86IEJvdW1hLCBUaW0NCkNj
OiBLZW4gRGFnZzsgdm90QGlldGYub3JnPG1haWx0bzp2b3RAaWV0Zi5vcmc+OyBzd2lsc29uQGxv
Y2tzdGVwLmNvbS5hdTxtYWlsdG86c3dpbHNvbkBsb2Nrc3RlcC5jb20uYXU+DQpTdWJqZWN0OiBS
ZTogW1ZvVF0gRm91bmRhdGlvbmFsIHF1ZXN0aW9ucyBvZiBwcmluY2lwbGUNCg0KV2hhdCB3ZSdy
ZSB0cnlpbmcgdG8gZG8gd2l0aCB0aGUgIlZlY3RvcnMiIGFwcHJvYWNoIGhlcmUgaXMgdG8gc3Ry
aWtlIGEgYmFsYW5jZSBiZXR3ZWVuIHRoZSBvdmVybHktc2ltcGxpc3RpYyAic2luZ2xlIHNldCBv
ZiBsaW5lYXIgbGV2ZWxzIiBhcHByb2FjaCB0aGF0IExvQSBnaXZlcyB1cyAodGhhdCBub2JvZHkg
b24gdGhpcyBsaXN0IGxpa2VzIGJ1dCBhbGwgYWdyZWUgdGhhdCBhcHBzIGNhbiBhY3R1YWxseSBk
byBzb21lIGxldmVsIG9mIHByb2Nlc3Npbmcgd2l0aCBpdCkgYW5kIHRoZSBvdmVybHktY29tcGxl
eCAidmVyeSBsb25nIGNvbXBsZXggc2V0IG9mIGF0dHJpYnV0ZXMiIGFwcHJvYWNoIHRoYXQgVGlt
LCBTY290dCwgYW5kIG90aGVycyBoYXZlIGJyb3VnaHQgdXAgKHRoYXQgc2VlbXMgbW9yZSBleHBy
ZXNzaXZlIGFuZCBpZGVhbCBidXQgbm8gYXBwIGlzIGV2ZXIgZ29pbmcgdG8gbWFrZSBzZW5zZSBv
Ziwgb3IgZXZlbiB0cnkgdG8pLiBJIHRoaW5rIGl0J3Mgc2FmZSB0byBzYXkgdGhhdCBuZWl0aGVy
IGV4dHJlbWUgd29ya3MgYW5kIHRoYXQgYSByaWdodCBhbnN3ZXIgcHJvYmFibHkgbGllcyBpbiB0
aGUgbWlkZGxlLg0KDQpTbyB0aGF0J3Mgd2hhdCB0aGlzIHN0cmF3bWFuIGlzIC0tIGl0J3Mgc2lt
dWx0YW5lb3VzbHkgbGVzcyBjb21wbGV4IGFuZCBtb3JlIGNvbXBsZXggdGhhbiB0aGUgYWx0ZXJu
YXRpdmVzLiBJcyBpdCB0aGUgcmlnaHQgY3V0PyBQcm9iYWJseSBub3QsIGJ1dCBpdCdzIGF0IGxl
YXN0IGEgY3V0dGluZyBwb2ludCB0aGF0IHdlIGNhbiBwdXNoIHRvIGVpdGhlciBzaWRlLiBXaGF0
IEkgdGhpbmsgd2UgbmVlZCB0byBkdXRpZnVsbHkgYXZvaWQgaXMgcHVzaGluZyBpdCBoYXJkIHRv
IGVpdGhlciBlbmQuIEkgcmVhbGx5IGxpa2UgdGhlIG5vdGlvbiB0aGF0IGV2ZW4gaWYgdGhlIGNv
bWJpbmF0aW9ucyBvZiB0aGUgdmVjdG9yIHZhbHVlcyBhcmVuJ3QgZGlyZWN0bHkgY29tcGF0aWJs
ZSAoYXMgU3RldmUgc2F5cyksIHRoZW4gdGhlIGJ1aWxkaW5nIGJsb2NrcyB3b3VsZCBhdCBsZWFz
dCBiZSBjb21wYXJhYmxlLCBnaXZpbmcgYSBob3BlIG9mIGRlZmluaW5nIGEgcG9saWN5IHRvIHRy
YW5zbGF0ZSBiZXR3ZWVuIHRoZW0gd2hlbiBuZWVkZWQuDQoNCkFsc28sIEkgd2FudGVkIHRvIGtl
eSBpbnRvIHRoZSBmYWN0IHRoYXQgdGhlcmUgYXJlIHNldmVyYWwgaW5kZXBlbmRlbnQgYW5kIG9y
dGhvZ29uYWwgY29tcG9uZW50cyBoZXJlLiBNYXliZSBpdCdzIG5vdCBhIHNldCBvZiBsZXZlbHMg
dGhhdCBhcmUgdGllZCB0b2dldGhlciwgYnV0IEkgdGhpbmsgaXQgaXMgaW4gc29tZXdheSBhIHNl
dCBvZiBpbmRlcGVuZGVudCAqdGhpbmdzKiB0aGF0IGFyZSB0aWVkIHRvZ2V0aGVyLg0KDQogLS0g
SnVzdGluDQrigKbigKbigKbigKbigKbigKbigKbigKbigKbigKbigKbigKbigKbigKbigKbigKbi
gKbigKbigKbigKbigKbigKYuDQoNCkl0IG1heSBtYWtlIHNlbnNlIHRvIGxvb2sgYXQgTE9BcyBh
cyBzb21ldGhpbmcgdGhhdCBpcyAiY29hcnNlLWdyYWluZWQiIGFuZCBhIHN0YXJ0aW5nIHBvaW50
Lg0KDQpXZSBhbGwgdGhpbmsgaXQgaXMgbm90IGVub3VnaCwgYnV0IGluIHRoZSBhYnNlbmNlIG9m
IHRoZSBCb3JnIHNob3dpbmcgdXAgdG8gZW5mb3JjZSBhIGNvbGxlY3RpdmUgaGl2ZS1taW5kIGFj
cm9zcyBvcmdhbml6YXRpb25hbCBib3VuZGFyaWVzLCB3ZSBjYW4gbGl2ZSB3aXRoIGl0IGFuZCB1
c2UgaXQgYXMgYSBzdGFydGluZyBwb2ludCBmb3IgdGhlIGRpc2N1c3Npb24gIldoYXQgbW9yZSBk
byB3ZSBuZWVkIGluIG9yZGVyIHRvIGxldCB0aGlzIHBlcnNvbiBpbiB0aGUgZG9vcj8iDQoNCkFu
ZCB0aGF0IGlzIHdoZXJlIFJQIGltcGxlbWVudGVkIGNvbXBlbnNhdGluZyBjb250cm9scyBjYW4g
cGxheSBhIHBhcnQuIFRoZSBjaGFsbGVuZ2UgaXMgdGhhdCBmb2xrcyBzZWVtIHRvIGNvbmZsYXRl
ICJ0aGluZ3MgbmVlZGVkIHRvIGVuc3VyZSBjb25maWRlbmNlIGluIGFuIGlkZW50aXR5IiB3aXRo
ICJ0aGluZ3MgbmVlZGVkIHRvIG1pdGlnYXRlIHJpc2sgaW4gdGhlIHRyYW5zYWN0aW9uIiBhbmQg
d2hvIGlzIChDU1Agb3IgUlApIHJlc3BvbnNpYmxlIGZvciB3aGF0Lg0KDQpSZWdhcmRzLA0KDQot
IEFuaWwNCg0KOi0gQW5pbCBKb2huDQo6LSBNYWtpbmcgRGlnaXRhbCBTZXJ2aWNlcyBTZWN1cmUg
YW5kIFRydXN0d29ydGh5DQo6LSBodHRwczovL2Jsb2cuYW5pbGpvaG4uY29tDQoNCg0KT24gRnJp
LCBPY3QgMTAsIDIwMTQgYXQgMTE6MDIgUE0sIDxzd2lsc29uQGxvY2tzdGVwLmNvbS5hdTxtYWls
dG86c3dpbHNvbkBsb2Nrc3RlcC5jb20uYXU+PiB3cm90ZToNCg0KV2UgYXJlIGFsbCBhZ3JlZWQg
b2YgY291cnNlIHRoYXQgUlBzIG5lZWQgdG8gdW5kZXJzdGFuZCB0aGVpciByaXNrcywgZGV0ZXJt
aW5lIHdoYXQncyBuZWVkZWQgZnJvbSBhbnkgZXh0ZXJuYWwgcHJvY2VzcyBvZiBpZGVudGlmaWNh
dGlvbiBvciBhdHRyaWJ1dGUgYXR0ZXN0YXRpb24sIGNvbW11bmljYXRlIHRob3NlIG5lZWRzIHRv
IGNhbmRpZGF0ZSBBUHMsIGFuZCBmcm9tIHRoZXJlLCBjb250cmFjdCBhbiBhY2NlcHRhYmxlIHBy
b3ZpZGVyLg0KDQpNeSBxdWVzdGlvbiBpcyB3aGV0aGVyIG9yIG5vdCBhIHBpZ2VvbmhvbGVkIExP
QSBoZWxwcyBhdCBhbnkgcG9pbnQgaW4gdGhpcyBwcm9jZXNzLg0KDQpUaGUgZGV2aWwgaXMgaW4g
dGhlIGRldGFpbC4gIFRvIG15IG1pbmQsIExPQSBpcyBhbiBpbnRlcm1lZGlhdGUgc3RlcCB0aGF0
IHRha2VzIGEgZGV0YWlsZWQgcmlzayBhbmFseXNpcywgc3F1ZWV6ZXMgaXQgaW50byBhIGJpbiAo
bG9zaW5nIGxvdHMgb2YgaW5mb3JtYXRpb24gYXMgYSByZXN1bHQpLCB3aGljaCBpcyB0aGVuIHVz
ZWQgdG8gc2hvcnRsaXN0IGNhbmRpZGF0ZSBwcm92aWRlcnMsIGJlZm9yZSBnb2luZyBpbnRvIGRl
dGFpbGVkIGR1ZSBkaWxpZ2VuY2Ugd2hlcmUgYWxsIHRob3NlIGRldGFpbHMgbmVlZCB0byBiZSBw
dXQgYmFjayBvbiB0aGUgdGFibGUuDQoNCkkgdGhpbmsgd2UgYWxsIGtub3cgYnkgbm93IG9mIGNh
c2VzIHdoZXJlIFJQcyBoYXZlIGxvb2tlZCBhdCBjYW5kaWRhdGUgSWRQcyBhdCBhIGdpdmVuIExP
QSwgYW5kIGhhdmUgY29tZSB1cCB3aXRoIHRoZSByZXF1ZXN0IG9mICJMT0EgdHdvIGFuZCBhIGhh
bGYiICh0aGlzIHdhcyBtZW50aW9uZWQgYXQgQ0lTIDIwMTQgbW9yZSB0aGFuIG9uY2UsIGFuZCBJ
IGhhdmUgc2VlbiBpdCBmaXJzdCBoYW5kIGluIHRoZSBVSyBJREFQKS4NCg0KQ2xlYXJseSB3aGF0
J3MgZ29pbmcgb24gaGVyZSBpcyBhbiBSUCdzIGlkZWEgb2Ygc2F5ICJMT0EgMiIgZGlmZmVycyBm
cm9tIGEgZ2l2ZW4gSWRQJ3MgaWRlYSBvZiBMT0EgMi4gIE1vcmVvdmVyLCB0aGUgaWRlYSBvZiBM
T0EgMiBtdXN0IGRpZmZlciBmcm9tIG9uZSBJZFAgdG8gYW5vdGhlciBJZFAuICBXaGVuIHBlb3Bs
ZSBhc2sgZm9yICJMT0EgMi41IiB3aGF0IHRoZXkncmUgYXNraW5nIGZvciBpcyBhIGN1c3RvbWlz
ZWQgaWRlbnRpZmljYXRpb24uICBJZiBMT0EgMiBpc24ndCB3aGF0IGl0IHNlZW1zLCB0aGVuIHRo
ZXJlIGNhbm5vdCBwb3NzaWJseSBiZSBhbnkgc3VjaCB0aGluZyBhcyBhICpzdGFuZGFyZGlzZWQq
IExPQSAyLjUuICBBbGwgd2Ugd2lsbCBnZXQgaXMgZnJlc2ggY2FsbHMgZm9yICJMT0EgMi43NSBw
bGVhc2UiLg0KDQpJZiBSUHMgbmVlZCB0byBkbyBkZXRhaWxlZCBhbmFseXNpcyBvZiBhdXRoZW50
aWNhdGlvbiBuZWVkcywgYW5kIGdldCBkZXRhaWxlZCB2ZXJpZmljYXRpb24gb2YgdGhlIGFjdHVh
bCBJRCBwcm9vZmluZyBkb25lIGJ5IElkUHMgYW5kIEFQcywgdGhlbiBJIGp1c3QgZG9uJ3Qgc2Vl
IGFueSBwb2ludCBhdHRhY2hpbmcgdGhlIExPQSBsYWJlbCBhbG9uZyB0aGUgd2F5LiAgSXQncyBt
aXNsZWFkaW5nLg0KDQpDaGVlcnMsDQoNClN0ZXZlLg0KDQpTdGVwaGVuIFdpbHNvbg0KTG9ja3N0
ZXANCmh0dHA6Ly9sb2Nrc3RlcC5jb20uYXUNCkxvY2tzdGVwIENvbnN1bHRpbmcgcHJvdmlkZXMg
aW5kZXBlbmRlbnQgc3BlY2lhbGlzdCBhZHZpY2UgYW5kIGFuYWx5c2lzDQpvbiBkaWdpdGFsIGlk
ZW50aXR5IGFuZCBwcml2YWN5LiAgTG9ja3N0ZXAgVGVjaG5vbG9naWVzIGRldmVsb3BzIHVuaXF1
ZQ0KbmV3IHNtYXJ0IElEIHNvbHV0aW9ucyB0aGF0IGVuaGFuY2UgcHJpdmFjeSBhbmQgcHJldmVu
dCBpZGVudGl0eSB0aGVmdC4NCg0KT24gT2N0IDEwLCAyMDE0LCBhdCAxMDo1MSBBTSwgQm91bWEs
IFRpbSA8VGltLkJvdW1hQHRicy1zY3QuZ2MuY2E8bWFpbHRvOlRpbS5Cb3VtYUB0YnMtc2N0Lmdj
LmNhPj4gd3JvdGU6DQoNCkkgYWdyZWUgd2l0aCBLZW4sDQoNCldoZW4gd2UgZGV2ZWxvcGVkIGxl
dmVscyBvZiBhc3N1cmFuY2UgKGhlcmUgaW4gQ2FuYWRhKSB3ZSBkaWQgc2V2ZXJhbCB0aGluZ3M6
DQoNCg0K4oCiICAgICAgICAgV2UgZGVmaW5lZCB0aGVtIGFzIGxldmVscyBvZiBjb25maWRlbmNl
IHJlcXVpcmVkIChMZXZlbHMgMSB0aHJvdWdoIDQpDQoNCuKAoiAgICAgICAgIFdlIG1hcHBlZCB0
aGVzZSBsZXZlbHMgb2YgY29uZmlkZW5jZSB0byBhIHJhbmdlIG9mIGRlZ3JlZSBvZiBpbXBhY3Rz
Lg0KDQrigKIgICAgICAgICBXZSB0aGVuIHNwZWNpZmllZCBzZXBhcmF0ZWx5IGlkZW50aXR5IGFz
c3VyYW5jZSBsZXZlbHMgYW5kIGNyZWRlbnRpYWwgYXNzdXJhbmNlIGxldmVscyAoYW5kIGZvY3Vz
ZWQgb24gY3JlZGVudGlhbCBmaXJzdCkNCg0K4oCiICAgICAgICAgV2UgYWxzbyBmYWN0b3JlZCBv
dXQgbGlrZWxpaG9vZCBpbiB0aGUgYXNzdXJhbmNlIGxldmVsIGFzc2Vzc21lbnQgcHJvY2Vzcy4g
VGhhdCBtYWRlIHRoZSBhc3Nlc3NtZW50cyBtdWNoIGxlc3Mgc3ViamVjdGl2ZS4NCg0KQXQgdGhl
IGVuZCBvZiB0aGUgZGF5LCBhcyBLZW4gc3RhdGVzLCAgaXTigJlzIHRoZSBqb2IgdGhlIFJQIHRv
IHVuZGVyc3RhbmQgdGhlaXIgcmlzayAoYWxvbmcgd2l0aCBsaWtlbGlob29kKSBhbmQgdG8gY29t
bXVuaWNhdGUgYSBzdGFuZGFyZGl6ZWQgcmVxdWlyZW1lbnQgYmFjayB0byBhIHByb3ZpZGVyIChB
UCkNClRoZSBBUCBpcyAgYWNjb3VudGFibGUgZm9yIHByb3ZpZGluZyBhIHZlcnkgcHJlc2NyaWJl
ZCBjb21wb25lbnQgdGhhdCBmaXRzIGludG8gYSBsYXJnZXIgc3lzdGVtIGFuZCBhIHJpc2sgZW52
aXJvbm1lbnQgdGhhdCB0aGV5IG1pZ2h0IG5vdCBoYXZlIGEgZnVsbCB2aWV3IGludG8uIFRoZSBS
UCBtYXkgcHV0IGluIHByb3Zpc2lvbnMgdG8gc2hhcmUgdGhlIHJpc2sgd2l0aCB0aGUgQVAsIG9y
IG5vdCBidXQgdGhhdCBlbnRpcmVseSBkZXBlbmRzIG9uIHRoZSBhcnJhbmdlbWVudCwgYnV0IGF0
IGxlYXN0IHRoZSBSUCBhbmQgQVAgdW5kZXJzdGFuZCB3aGF04oCZcyBvbiB0aGUgdGFibGUgYXMg
YSBzdGFydGluZyBwb2ludC4NCg0KSW4gQ2FuYWRhLCB3ZSBkaWQgdGhhdCB3aXRoIHRoZSBjcmVk
ZW50aWFsIGZpcnN0LCBhbmQgYXJlIG5vdyBmaWd1cmluZyBvdXQgaWRlbnRpdHkgKG11Y2ggaGFy
ZGVyKS4NCg0KSSBhbHNvIGFncmVlIHRoYXQg4oCYaWRlbnRpdHnigJkgaXMganVzdCBhIHNldCBv
ZiBhdHRyaWJ1dGVzIOKAk2FuZCAgdGhlc2UgaWRlbnRpdHkgYXR0cmlidXRlcyBjYW4gdmFyeSBi
ZXR3ZWVuIG9yZ2FuaXphdGlvbnMgb3IganVyaXNkaWN0aW9ucywNCg0KQXMgZm9yIHRoZSB0ZXJt
IOKAmHZlY3RvcnPigJksIEkgZ2V0IHRoZSBpZGVhLCBidXQgSSB0aGluayB0aGUgY29tbXVuaXR5
IHdpbGwgdGhpbmsgaXTigJlzIHRvbyB0ZWNobmljYWwgb3IgZXNvdGVyaWMuIEkgbGlrZSB0byB0
aGluayBvZiBhIOKAmGRpZ2l0YWwgaWRlbnRpdHnigJkgKG9yIHdoYXRldmVyIHlvdSBjYWxsIGl0
KSwgd2hlbiBpdCBzaG93cyB1cCBhdCB5b3VyIGRpZ2l0YWwgZnJvbnQgZG9vciwgaXQgaXMgdGhl
IHByb2R1Y3Qgb2YgYSB2ZXJ5IGxvbmcsIGNvbXBsZXggc3VwcGx5IGNoYWluLCBmcmF1Z2h0IHdp
dGggbWFueSByaXNrcyBhbmQgY29tcHJvbWlzZXMuIEkgbWF5IGhhdmUgY29uZmlkZW5jZSBpbiBj
ZXJ0YWluIHBpZWNlcyBvZiwgYnV0IG90aGVyIEkgbWlnaHQgbm90IHRydXN0IGF0IGFsbC4NCg0K
DQpUaW0NCg0KDQpGcm9tOiB2b3QgW21haWx0bzp2b3QtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo
YWxmIE9mIEtlbiBEYWdnDQpTZW50OiBPY3RvYmVyLTA5LTE0IDk6NDIgUE0NClRvOiBzd2lsc29u
QGxvY2tzdGVwLmNvbS5hdTxtYWlsdG86c3dpbHNvbkBsb2Nrc3RlcC5jb20uYXU+DQpDYzogdm90
QGlldGYub3JnPG1haWx0bzp2b3RAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW1ZvVF0gRm91bmRh
dGlvbmFsIHF1ZXN0aW9ucyBvZiBwcmluY2lwbGUNCg0KU3RldmUsDQoNCkFzIHdlIGhhdmUgY29t
bXVuaWNhdGVkIGluIHRoZSBwYXN0LCBJIGFtIGEgc3Ryb25nIGJlbGlldmVyIHRoZSBhbiBMT0Eg
ZGVzaWduYXRpb24gaXMgYW4gaW5kaWNhdGlvbiBvZiB0aGUgcHJvY2Vzc2VzL21lY2hhbmlzbXMg
dGhhdCBhbiBJZFAgaGFzIHVuZGVydGFrZW4uIEluIG90aGVyIHdvcmRzLCBpdCBpcyBhIGNvbW11
bmljYXRpb24gdG9vbC4gVGhlIGNob2ljZSBpcyB0aGUgUlBzLiBUaGF0IGlzLCBhbiBhc3NlcnRp
b24gYXQgYSBzcGVjaWZpYyBMT0EgYnkgYW4gSWRQL0NTUC9BUCBpcyBvbmUgb2YgdGhlIG1lY2hh
bmlzbXMgYSBSUCBzaG91bGQgdXNlIHRvIG9mZnNldCB0aGUgYXV0aGVudGljYXRpb24gcmlzayBp
dCBoYXMgaWRlbnRpZmllZCBmb3IgdGhlIHNlcnZpY2UgaXQgd2FudHMgdG8gZGVsaXZlci4gSW4g
b3RoZXIgd29yZHMsIGl0IGlzIHRoZSByaXNrIG9mIHRoZSBSUCB0aGF0IGlzIHBhcmFtb3VudCBu
b3QgdGhlIGNsYWltcyBvZiBhbiBpZGVudGl0eS9jcmVkZW50aWFsL2F0dHJpYnV0ZS90b2tlbiBw
cm92aWRlci4NCg0KTGlrZSB5b3UsIEkgYW0gYSBzdHJvbmcgYmVsaWV2ZXIgdGhhdCB0aGUgZGV0
ZXJtaW5hdGlvbiBvZiB3aGV0aGVyIG9yIG5vdCBhbiBpZGVudGl0eSBpcyBnb29kIGVub3VnaCBp
cyB0aGUgcmVzcG9uc2liaWxpdHkgb2YgdGhlIFJQLiBJbiBteSBleHBlcmllbmNlLCB0aGV5IG1h
a2UgdGhhdCBkZXRlcm1pbmF0aW9uIGJhc2VkIHVwb24gYSBzZXQgb2YgYXR0cmlidXRlcyB0aGV5
IGJlbGlldmUgYXJlIG5lY2Vzc2FyeS4gSWYgdGhleSB0cnVzdCB0aGF0IGFuIElkUCdzIGFzc2Vy
dGlvbiBvZiBpZGVudGl0eSBjb3ZlcnMgdGhlIGF0dHJpYnV0ZXMgdGhleSBiZWxpZXZlIGFyZSBy
ZXF1aXJlZCB0aGVtIHRoZXkgY2FuIGFjY2VwdCB0aGUgYXNzZXJ0aW9uLiBJZiBpdCBkb2Vzbid0
IHRoZW4gdGhhdCBoYXZlIHRvIGltcGxlbWVudCBhZGRpdGlvbmFsIG1lY2hhbmlzbXMgdG8gb2Zm
c2V0IHRoZSByZXNpZHVhbCByaXNrLg0KDQpXaXRoIHJlc3BlY3QgdG8gdmVjdG9ycyBvZiB0cnVz
dCwgSSBhbSBpbnRlcmVzdGVkIGluIGV4cGxvcmluZyB3aGF0IHRoZXkgYXJlIGFuZCBob3cgdGhl
eSBjYW4gYmUgYXBwbGllZC4NCg0KS2VuDQoNCk9uIFRodXJzZGF5LCBPY3RvYmVyIDksIDIwMTQs
IDxzd2lsc29uQGxvY2tzdGVwLmNvbS5hdTxtYWlsdG86c3dpbHNvbkBsb2Nrc3RlcC5jb20uYXU+
PiB3cm90ZToNCg0KRmlyc3QsIHRvIGludHJvZHVjZSBteXNlbGYsIEkgYW0gYW4gaWRlbnRpdHkg
YW5kIHByaXZhY3kgcmVzZWFyY2hlciwgYW5hbHlzdCBhbmQgY29uc3VsdGFudC4gIEkndmUgYmVl
biBpbnZvbHZlZCBpbiB0aGlzIHNpbmNlIDE5OTUsIHdoZW4gSSBjdXQgbXkgdGVldGggaW4gUEtJ
IGFuZCBzbWFydGNhcmRzICh3aXRoIHRoZSBlYXJseSBjb21wYW5pZXMgdGhhdCBiZWNhbWUgQmFs
dGltb3JlIFRlY2hub2xvZ2llcykuIFNpbmNlIHRoZW4gSSd2ZSB3b3JrZWQgb24gaWRlbnRpdHkg
bWFuYWdlbWVudCBmcmFtZXdvcmtzLCByZWd1bGF0aW9ucyBhbmQgc3RhbmRhcmRzLg0KDQpJIHN1
YnNjcmliZSB0byB0aGUgb2xkIEl0YWxpYW4gcHJvdmVyYjogIml0J3MgbmljZSB0byB0cnVzdCBi
dXQgYmV0dGVyIG5vdCB0byIuICBXb3JkcyBtYXR0ZXIgYW5kIEkgd29uZGVyIGlmIHdlIHNob3Vs
ZG4ndCBiZSB1c2luZyB0aGUgd29yZCB0cnVzdCBzbyBtdWNoLg0KDQpNb3JlIHByYWdtYXRpY2Fs
bHksIEkgbm90ZSB0aGUgdmVyeSBzdHJvbmcgIkF0dHJpYnV0ZXMiIHB1c2ggb2YgdGhlIHBhc3Qg
MTggbW9udGhzLiAgQW5kcmV3IE5hc2gsIEFuaWwgSm9obiwgbXlzZWxmIGFuZCBvdGhlcnMgaGF2
ZSB3cml0dGVuIGFib3V0IHRoaXMuICBUaGUgRklETyBBbGxpYW5jZSBpcyBhbGwgYWJvdXQgYXV0
aGVudGljYXRpb24gYW5kIGF0dHJpYnV0ZXMsIGFuZCB0aGV5IHB1cnBvc2VmdWxseSBsZWF2ZSAi
aWRlbnRpdHkiIGFzIGEgbWF0dGVyIGZvciBvdGhlcnMgdG8gd29yayBvdXQgZnVydGhlciB1cCB0
aGUgc3RhY2suIFRoZSBPSUQgRm91bmRhdGlvbiBpcyBwcm9tb3RpbmcgYW4gQXR0cmlidXRlcyBF
eGNoYW5nZSBOZXR3b3JrICJBWE4iIGFyY2hpdGVjdHVyZS4gIE5ldyBlbnRyYW50cyBsaWtlIGlk
Lm1lPGh0dHA6Ly9pZC5tZS8+IChhbiBOU1RJQyBwaWxvdCBwYXJ0aWNpcGFudCkgdGFsayBhYm91
dCBhdHRyaWJ1dGVzIGFuZCBhdm9pZCAiaWRlbnRpdHkiLg0KDQpJIG1lbnRpb24gYWxsIG9mIHRo
aXMgYXMgYSBwcmVsdWRlIHRvIHN1Z2dlc3QgdGhhdCAidmVjdG9yIG9mIHRydXN0IiBpcyBzeW5v
bnltb3VzIHdpdGggImF0dHJpYnV0ZSIuIEkgd29uZGVyIGlmIGl0IHdvdWxkIGJlIGNsZWFyZXIg
dG8gdXNlIHBsYWluIGFuZCBjdXJyZW50IGxhbmd1YWdlIHJhdGhlciB0aGFuIGNhcnJ5IGZvcndh
cmQgdGhlIGZ1enp5IGFuZCBJIHRoaW5rIG92ZXJseSBhbWJpdGlvdXMgaWRlYSBvZiAidHJ1c3Qi
Pw0KDQpGaW5hbGx5LCBJJ2QgbGlrZSB0byB0aHJvdyBpbiBteSBhYmlkaW5nIGNvbmNlcm4gdGhh
dCBMT0FzIGhhdmUgZm91bmRlcmVkIHNpbXBseSBiZWNhdXNlIGl0J3MgZGlmZmljdWx0IHRvIHBp
Z2VvbmhvbGUgcmlzay4gT25lIHBhcnR5J3MgaWRlYSBvZiAibWVkaXVtIiByaXNrIGZvciBpbnN0
YW5jZSB3aWxsIHJhcmVseSBtYXAgcHJlY2lzZWx5IHRvIGFub3RoZXIncy4gSSB0aGluayBwZW9w
bGUgaGF2ZSBiZWVuIG1pc2xlZCBpbnRvIHRoaW5raW5nIHRoYXQgYW4gIkxPQSAzIiBpZGVudGl0
eSBzaG91bGQgYmUgYmUgYWJsZSB0byBiZSB1c2VkIG9uIGl0cyBmYWNlIChpLmUuIHdpbGwgImlu
dGVyb3BlcmF0ZSIpIGF0IGFueSAiTE9BIDMiIFJQLiBSaXNrIG1hbmFnZW1lbnQgaXMgbm90IHNv
IHNpbXBsZS4NCg0KVGhlIExPQSBwYXJhZGlnbSBib3Jyb3dzIGZyb20gUmlzayBNYW5hZ2VtZW50
IHN0YW5kYXJkcyBsaWtlIElTTyAzMTAwMCB3aGljaCBvcmdhbmlzYXRpb25zIHVzZSB0byBwbG90
IHRoZWlyIG93biByaXNrcyBpbnRlcm5hbGx5IHR5cGljYWxseSBvbiBhIGZpdmUgc2NhbGUgKGVn
IE5lZ2xpZ2libGUgLyBMb3cgLyBNZWRpdW0gLyBIaWdoIC8gR3JhdmUpLiBCdXQgcmlzayBtYW5h
Z2VtZW50IHN0YW5kYXJkcyByZXF1aXJlIHRoYXQgZWFjaCBvcmdhbmlzYXRpb24gY2FsaWJyYXRl
cyByaXNrIGluIGl0cyBvd24gYnVzaW5lc3MgY29udGV4dCBhbmQgYWNjb3JkaW5nIHRvIGl0cyBv
d24gcmlzayBhcHBldGl0ZS4gVGhlIHJpc2sgb2YgYSBmaXJld2FsbCBicmVhY2ggZm9yIGV4YW1w
bGUgYXQgYSBzdGFydHVwIHNvY2lhbCBtZWRpYSBjb21wYW55IHdpbGwgYmUgYXNzZXNzZWQgZGlm
ZmVyZW50bHkgYnkgYSBiaWcgbGlzdGVkIGhlYWx0aGNhcmUgY29tcGFueS4gU28gb3JnYW5pc2F0
aW9uIEEgY2FuIHNheSB0aGUgcmlzayBvZiBldmVudCBYIGlzIExvdyBidXQgQiBjYW4gc2F5IHRo
ZSByaXNrIG9mIHRoZSBzYW1lIGV2ZW50IGlzIE1lZGl1bS4gIEFzIGEgcmVzdWx0LCBMT0FzIGRv
IG5vdCBpbnRlci1vcGVyYXRlLiBUaGV5IGFyZSBiYXNlZCBvbiBzdGFuZGFyZHMgbWVhbnQgZm9y
IGludHJhLW9yZ2FuaXNhdGlvbiByaXNrIG1hbmFnZW1lbnQsIG5vdCBpbnRlci1vcmdhbmlzYXRp
b24gY29tbXVuaWNhdGlvbiBvZiByaXNrIGFzc2Vzc21lbnRzLg0KDQpTbyBmYXIgd2l0aCBWb1Qg
d2UgYXJlIGFkZGluZyBtb3JlIGRpbWVuc2lvbnMgdG8gdGhlIFJQcycgZ2VuZXJpYyByaXNrIG1h
bmFnZW1lbnQgZGVjaXNpb24gbWFraW5nLCBhbmQgdGhhdCdzIGdyZWF0LiAgQnV0IHdlIGFyZSBz
dGlsbCBwaWdlb25ob2xpbmcgdGhlIGRpbWVuc2lvbnMuDQoNCkknbSBhZnJhaWQgdGhlIHJlYWxp
dHkgaXMgdGhhdCByaXNrIG1hbmFnZW1lbnQgd2lsbCBhbHdheXMgYmUgZG9uZSBsb2NhbGx5LiAg
QW5kIHNvIGl0IHNob3VsZCBiZS4gIFdoZW4gYW4gUlAgaXMgbWFraW5nIHRoZSBkZWNpc2lvbiB0
byBhY2NlcHQgb3IgcmVqZWN0IGEgZ2l2ZW4gc3ViamVjdCwgdGhleSB3aWxsIGV2YWx1YXRlIGEg
cmFuZ2Ugb2YgYXR0cmlidXRlcyBvciBzaWduYWxzLiAgVGhlIHNldCBvZiBhdHRyaWJ1dGVzIHRo
YXQgbWF0dGVycyB2YXJpZXMgZnJvbSBvbmUgUlAgdG8gdGhlIG5leHQuICBJIHRoaW5rIGl0J3Mg
YSBncmVhdCBpZGVhIGluZGVlZCB0byBjcmVhdGUgZ3VpZGFuY2UgZm9yIGV2YWx1YXRpbmcgYXR0
cmlidXRlcywgYW5kIHRvIGNvYWNoIFJQcyB0byBsb29rIGF0IGFsbCBzb3J0cyBvZiBkaW1lbnNp
b25zLiAgSSBqdXN0IGRvbid0IHRoaW5rIGl0IGhlbHBzIGFueW9uZSB0byBwaWdlb25ob2xlIHRo
ZSByaXNrIHJhdGluZ3MsIGJlY2F1c2UgYWNyb3NzIG9yZ2FuaXNhdGlvbnMsIGFyZ3VtZW50cyBh
Ym91dCB0aGUgYm91bmRhcmllcyBiZXR3ZWVuIExPQSAxLzIvMy80ICh0aGF0IGlzLCBwb2xpY3kg
bWFwcGluZykgd2lsbCB1bmRvIGFueSBlZmZpY2llbmNpZXMgZ2FpbmVkIGZyb20gdGhlIGNhdGVn
b3JpemF0aW9uLg0KDQpDaGVlcnMsDQoNClN0ZXZlLg0KDQoNClN0ZXBoZW4gV2lsc29uDQpNYW5h
Z2luZyBEaXJlY3Rvcg0KTG9ja3N0ZXAgR3JvdXANCmh0dHA6Ly9sb2Nrc3RlcC5jb20uYXU8aHR0
cDovL2xvY2tzdGVwLmNvbS5hdS8+DQpMb2Nrc3RlcCBDb25zdWx0aW5nIHByb3ZpZGVzIGluZGVw
ZW5kZW50IHNwZWNpYWxpc3QgYWR2aWNlIGFuZCBhbmFseXNpcw0Kb24gZGlnaXRhbCBpZGVudGl0
eSBhbmQgcHJpdmFjeS4gTG9ja3N0ZXAgVGVjaG5vbG9naWVzIGRldmVsb3BzIHVuaXF1ZQ0KbmV3
IHNtYXJ0IElEIHNvbHV0aW9ucyB0aGF0IGVuaGFuY2UgcHJpdmFjeSBhbmQgcHJldmVudCBpZGVu
dGl0eSB0aGVmdC4NCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fDQp2b3QgbWFpbGluZyBsaXN0DQp2b3RAaWV0Zi5vcmc8bWFpbHRvOnZvdEBpZXRm
Lm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdm90DQoNCg0KX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnZvdCBtYWlsaW5n
IGxpc3QNCnZvdEBpZXRmLm9yZzxtYWlsdG86dm90QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92b3QNCg0KDQo=

--_000_147EE18440E5AF44834B220ED35BA530D32F0CAFWLGPRDMBX01diag_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9
DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg
MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl
LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv
Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJn
aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt
ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv
LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy
bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl
LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l
O30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv
Ow0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy
Z2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l
dyBSb21hbiIsInNlcmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29B
Y2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v
biBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv
bnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bh
bi5ob2VuemINCgl7bXNvLXN0eWxlLW5hbWU6aG9lbnpiO30NCnNwYW4uQmFsbG9vblRleHRDaGFy
DQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9y
aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJU
YWhvbWEiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1OWjt9DQpzcGFu
LkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh
bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERl
ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGli
cmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBX
b3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4w
cHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x
O30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjIwOTgz
NTY0MDI7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi04MDc2MDcwMzg7fQ0Kb2wNCgl7bWFyZ2lu
LWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+PC9zdHlsZT48IS0t
W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt
YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N
CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh
PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv
ZHkgbGFuZz0iRU4tTloiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i
V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZsdDsmbHQ7SSB0aGluayBpdCBk
ZXBlbmRzIG9uIGlmIHRoZSBpbnRlbnRpb24gaXMgdG8ga2VlcCB0aGUgJ3ZlY3RvcnMnIGZsYXQg
b3IgdGhleSBjYW4gaGF2ZSBzb21lIHNvcnQgb2YgYW4gaGllcmFyY2h5Jmd0OyZndDsuPHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMUY0OTdEIj5JIHRoaW5rIHRoYXQgaXMgYSDigJh0YmTigJkgQW5pbC48bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzFGNDk3RCI+V2UgbWF5IGhhdmUgYSBiZXR0ZXIgaWRlYSBvbmNlIHRoZSBjb25j
ZXB0IGlzIGRldmVsb3BlZCBhIGJpdCBmdXJ0aGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0
OTdEIj5Hb29kIGZpbmUgZ3JhaW5pbmcgb24gSWRlbnRpdHkgUHJvb2ZpbmcgdGhlcmUuLiAmbmJz
cDt1c2VmdWwuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkxvb2tpbmcgYmVsb3cgYXQgS2Vu4oCZcyByZXNwb25zZTo8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VG8gS2Vu4oCZcyBzdWdnZXN0aW9uIHF1YWxp
ZmllZCBieSBoaXMgcXVlc3Rpb24vYXNzdW1wdGlvbi4uPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx
RjQ5N0QiPiZsdDsmbHQ7PC9zcGFuPiBDcmVkZW50aWFsIFN0cmVuZ3RoIGRlYWxzIHdpdGggdGhl
IGJpbmRpbmcgb2YgYW4gaWRlbnRpdHkgdG8gYSZuYnNwO3Rva2VuJmd0OyZndDs8bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi4uIGlzIGFsb25nIHRoZSBsaW5lcyBKdXN0aW4g
ZGVzY3JpYmVkIGl0IElNSE8sIHNvIHllYSwgSSB0aGluayDigJh0b2tlbiBwcm9vZmluZ+KAmSBj
b3VsZCBiZSBhbm90aGVyIHZlY3Rvci9zdWIgdmVjdG9yLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij5UbyB0aGUgY29tbWVudCBhYm91dCB0aGUgdmFsdWUgb2YvbWVhc3VyZW1lbnQgb2YgdmVjdG9y
cyBhbmQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbHQ7Jmx0O2hvdyB0
aGV5IGFwcGx5IHRvIHRoZSBlbnRpdHkgdGhhdCBpcyB0aGUgcmVjaXBpZW50IG9mIHRoZSBvdXRw
dXQgb2YgdGhlIHdvcmsmZ3Q7Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+Li4odHlwaWNhbGx5IHRoZSBSUCBJIGd1ZXNzKSB0aGVuIHdlIGNvbWUgYmFjayB0byBzb21l
IG1hY2hpbmUgcHJvY2Vzcy1hYmxlIHdheSB0aGF0IHRoZSBSUCBjYW4gZXhwcmVzcyB0aGUgdmVj
dG9yIHZhbHVlcyBvZiB0aGUgcmlzayBvZiB0aGF0IGF1dGhlbnRpY2F0aW9uIGluc3RhbmNlL3Nl
cnZpY2UvdHJhbnNhY3Rpb24gd2hpY2gsIGFzIFN0ZXZlIGluZGljYXRlcywgbWlnaHQgcG9zc2li
bHkgYmUgZGlmZmVyZW50DQogZm9yIGVhY2ggYW5kIGV2ZXJ5IHRyYW5zYWN0aW9uL2xvY2F0aW9u
L2NvbnRleHQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkp1c3RpbiBvZmZlcmVkIHVwIGEga2lu
ZCBvZiBjb2RpZmllZCB3YXkgb2YgZXhwcmVzc2luZyBzcGVjaWZpYyB2ZWN0b3IgdmFsdWVzIHdp
dGggYSBtYXJrZXIgbGV0dGVyIGFuZCBjYXRlZ29yeSBudW1iZXIgKHNhbWwgbWQgaW9wIGhhcyBm
b3Igc29tZSB0aW1lIG5vdyBhcyBTY290dCBtZW50aW9uZWQpLCBidXQgdGhlIHRyaWNrIHdvdWxk
IGJlICZuYnNwO3RvIG1ha2UgYSBkaXN0aW5jdGlvbiBiZXR3ZWVuIHdoYXQgdmVjdG9yDQogdmFs
dWVzIHRoZSBSUCByZXF1aXJlcyAoYSB2ZWN0b3Ivc3ViIHZlY3RvciksIGFuZCB3aGF0IGlzIOKA
mG9uIG9mZmVy4oCZIGZyb20gcHJvdmlkZXIgcGFydGllcyAoYW5vdGhlciB2ZWN0b3Ivc3ViIHZl
Y3RvciksIGJ1dCBzdGlsbCBpbiBhIGNvZGlmaWVkIHdheSBjb25zdW1hYmxlIGJ5IGFsbCBwYXJ0
aWVzLiBSZWR1Y2luZyB0aGlzIGRvd24gZnJvbSBhIGNvbXBsZXggc2V0IG9mIHZhbHVlcywgdG8g
My01IFZlY3RvcnMsIHdpdGggbXVsdGlwbGUgc3ViDQogdmVjdG9ycyAqPGI+YW5kPC9iPiogbWFr
ZSBpdCBtZWFuaW5nZnVsIGFuZCBwcm9jZXNzLWFibGUsIGlzIG9uZSBtb3RoZXIgb2YgYSBjaGFs
bGVuZ2UuLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CdXQgYWxyZWFkeSB3ZSBoYXZlIG1vdmVk
IGJleW9uZCB0aGUgcHJldHR5IGJsdW50IGluc3RydW1lbnQgdGhhdCBpcyBMb0EuLiBhbmQgaGF2
ZSBub3QgeWV0IGdvbmUgdG8gdGhlIG90aGVyIGV4dHJlbWUgZW5kIG9mIHRoZSAo4oCYYWxsIGZp
bmUgZ3JhaW5lZC9kZS1jb21wb3NlZOKAmSkgc3BlY3RydW0sIHNvIHRoYXQgaXMgZ29vZC4mbmJz
cDsNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaG8ga25vd3MgaG93IG11Y2ggcHJvZ3Jlc3Mg
d2UgY291bGQgbWFrZSBpZiB3ZSBrZWVwIHRoaW5raW5n4oCmDQo8c3BhbiBzdHlsZT0iZm9udC1m
YW1pbHk6V2luZ2RpbmdzIj5KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DaGVlcnM8
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNvbGluICZuYnNwOyZuYnNwOyZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90OyI+IHZvdCBbbWFpbHRvOnZvdC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxm
IE9mIDwvYj5BbmlsIEpvaG48YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCAxMyBPY3RvYmVyIDIw
MTQgMTI6MzYgcC5tLjxicj4NCjxiPlRvOjwvYj4gS2VuIERhZ2c7IHZvdEBpZXRmLm9yZzxicj4N
CjxiPlN1YmplY3Q6PC9iPiBSZTogW1ZvVF0gRm91bmRhdGlvbmFsIHF1ZXN0aW9ucyBvZiBwcmlu
Y2lwbGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5LZW4sPG86cD48L286
cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIGl0IGRlcGVuZHMg
b24gaWYgdGhlIGludGVudGlvbiBpcyB0byBrZWVwIHRoZSAndmVjdG9ycycgZmxhdCBvciB0aGV5
IGNhbiBoYXZlIHNvbWUgc29ydCBvZiBhbiBoaWVyYXJjaHkuJm5ic3A7IElmIHRoZSBsYXR0ZXIs
IHN1cmUuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+LSBBbmlsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnIgY2xlYXI9ImFsbCI+DQo8bzpw
PjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7Ij5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m
YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+LSBBbmlsPG86
cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij46LSBBbmlsIEpvaG48bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90OyI+Oi0gTWFraW5nIERpZ2l0YWwgU2VydmljZXMgU2VjdXJlIGFuZCBU
cnVzdHdvcnRoeTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij46LSA8YSBocmVmPSJodHRwczovL2Jsb2cuYW5pbGpvaG4u
Y29tIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL2Jsb2cuYW5pbGpvaG4uY29tPC9hPjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBTdW4sIE9jdCAx
MiwgMjAxNCBhdCA3OjI4IFBNLCBLZW4gRGFnZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtlbmRhZ2d0
YnNAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+a2VuZGFnZ3Ric0BnbWFpbC5jb208L2E+Jmd0
OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuaWwsPG86cD48
L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RG8geW91IHRoaW5rIHRoYXQg
dGhlc2UgY291bGQgYmUgc3ViIHZlY3RvcnMgb2YgdGhlIElkZW50aXR5IFByb29maW5nIHZlY3Rv
cj88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIGNsYXNzPSJob2VuemIiPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij5LZW48L3NwYW4+
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48YnI+DQo8YnI+DQpPbiBNb25kYXksIE9jdG9iZXIgMTMsIDIwMTQsIEFuaWwgSm9obiAmbHQ7
PGEgaHJlZj0ibWFpbHRvOmFuaWx0akBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5hbmlsdGpA
Z21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+VGhhbmsgeW91IENvbGluIGZvciBoZXJkaW5nIHRoZSBjYXRzIChJbmNsdWRp
bmcgbXlzZWxmIHRoZXJlKSE8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPkkgd291bGQgcmVjb21tZW5kIHNwbGl0dGluZyB1cCB0aGUgJ0lkZW50aXR5IFByb29m
aW5nJyB2ZWN0b3IgaW50byBpdHMgY29tcG9uZW50IGJpdHMsIHJhdGhlciB0aGFuIHRyZWF0aW5n
IGl0IGxpa2UgdGhlIGN1cnJlbnQgYW1vcnBob3VzIGJsb2IgdGhhdCBpdCBpcyByaWdodCBub3c6
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxvbCBzdGFydD0iMSIgdHlwZT0iMSI+
DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOiMzMzMzMzM7bXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bGluZS1oZWlnaHQ6MTUuMHB0
O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDsiPklkZW50aXR5IFJlc29sdXRpb248L3NwYW4+PC9zdHJvbmc+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDsiPiZuYnNwOy0mbmJzcDtFc3RhYmxpc2hpbmcgdGhlIHVuaXF1ZW5lc3Mgb2Yg
YW4gaW5kaXZpZHVhbCB3aXRoaW4gYSBwb3B1bGF0aW9uPG86cD48L286cD48L3NwYW4+PC9saT48
bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOiMzMzMzMzM7bXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bGluZS1oZWlnaHQ6MTUuMHB0O21z
by1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDsiPklkZW50aXR5IFZhbGlkYXRpb248L3NwYW4+PC9zdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDsiPiZuYnNwOy0mbmJzcDtDb25maXJtaW5nIHRoZSBhY2N1cmFjeSBvZiBpZGVudGl0
eSBpbmZvcm1hdGlvbiBjbGFpbWVkIGJ5IGFuIGluZGl2aWR1YWw8bzpwPjwvbzpwPjwvc3Bhbj48
L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6IzMzMzMzMzttc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztsaW5lLWhlaWdodDoxNS4w
cHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90OyI+SWRlbnRpdHkgVmVyaWZpY2F0aW9uPC9zcGFuPjwvc3Ryb25nPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDstJm5ic3A7Q29uZmlybWluZyB0aGF0IHRoZSBjbGFpbWVk
IGlkZW50aXR5IGluZm9ybWF0aW9uIGlzIGxpbmtlZCB0byB0aGUgaW5kaXZpZHVhbCBtYWtpbmcN
CiB0aGUgY2xhaW0mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvb2w+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPi0gQW5pbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls
eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90OyI+Oi0gQW5pbCBKb2huPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjotIE1h
a2luZyBEaWdpdGFsIFNlcnZpY2VzIFNlY3VyZSBhbmQgVHJ1c3R3b3J0aHk8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+
Oi0gPGEgaHJlZj0iaHR0cHM6Ly9ibG9nLmFuaWxqb2huLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPg0K
aHR0cHM6Ly9ibG9nLmFuaWxqb2huLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Db2xpbiw8bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+R29vZCBwb2ludCB0byBtb3ZlIHRoZSB0aHJlYWQgYmFjayB0byBpdHMgb3JpZ2lu
YWwgdG9waWMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgd291bGQgc3VnZ2VzdCB0aGF0IHRo
ZXJlIGlzIG9uZSBtb3JlIHZlY3RvcjogdG9rZW4gcHJvb2ZpbmcuIFRoaXMgdmVjdG9yIHdvdWxk
IGJlIHNpbWlsYXIgaW4gbmF0dXJlIHRvIHRoZSBpZGVudGl0eSBwcm9vZmluZyB2ZWN0b3Igb25s
eSBmb2N1c2VkIG9uIHRoZSB0b2tlbiByYXRoZXIgdGhhbiB0aGUgaWRlbnRpdHkuPG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPkkmbmJzcDtoYXZlIG5vdCBoYWQgYSBjaGFuY2UgdG8gcmV2aWV3IHRo
ZSBvcmlnaW5hbCBwYXBlciB0byBrbm93IHdoYXQgaXQgc2F5cyBhYm91dCB0aGUgb3RoZXIgdmVj
dG9ycyAoSSBhbSBzdXBwb3NlZCZuYnNwO3RvIGJlIG9uIGhvbGlkYXlzKS4gSSBhbSBhc3N1bWlu
ZyB0aGF0IElkZW50aXR5IFByb29maW5nIGRlYWxzIHdpdGggaG93IGFuIElkZW50aXR5IGlzIHBy
b29mZWQsJm5ic3A7Q3JlZGVudGlhbCBTdHJlbmd0aCBkZWFscyB3aXRoDQogdGhlIGJpbmRpbmcg
b2YgYW4gaWRlbnRpdHkgdG8gYSZuYnNwO3Rva2VuLCBhbmQmbmJzcDtBc3NlcnRpb24gUHJlc2Vu
dGF0aW9uIGRlYWxzIHdpdGggd2hhdCB0aGUgSWRQIGdvZXMgdGhyb3VnaCBpbiBvcmRlciB0byBp
c3N1ZSBhbiBhc3NlcnRpb24uIFdoYXQgSSBiZWxpZXZlIGlzIGludGVyZXN0aW5nIGlzIHRoYXQg
dGhlc2UgdmVjdG9ycyBhcmUgYXBwbGljYWJsZSB0byBhbnkgZW50aXR5IHRoYXQgZG9lcyB0aGUg
d29yay4gV2hhdCBpcyBvZiBwb3RlbnRpYWwNCiBpbnRlcmVzdCBpcyBob3cgdGhleSBhcHBseSB0
byB0aGUgZW50aXR5IHRoYXQgaXMgdGhlIHJlY2lwaWVudCBvZiB0aGUgb3V0cHV0IG9mIHRoZSB3
b3JrLjxicj4NCjxicj4NCkkgYWdyZWUgdGhhdCBPcGVyYXRpb25hbCBNYW5hZ2VtZW50IGlzIGFu
IGludGVyZXN0aW5nLCBidXQgZXh0cmVtZWx5IGltcG9ydGFudCwmbmJzcDt2ZWN0b3IgdGhhdCBj
b3VsZCBoYXZlIG1hbnkgc3ViLXZlY3RvcnMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoaWxl
IHRoZSBMb0EgZGlzY3Vzc2lvbiBzZWVtZWQgdG8gYmUgb2ZmIHRyYWNrLCBJIHdvdWxkIHN1Z2dl
c3QgdGhhdCBpdCBpcyBwYXJ0IG9mIHRoZSBkaXNjdXNzaW9uIGJlY2F1c2UgTG9BIChyZWdhcmRs
ZXNzIG9mIGhvdyBtYW55IGxldmVscykmbmJzcDtzaG91bGQgYmUgYSBtZWFzdXJlIG9mIGFuZCBh
IG1lYW5zIG9mIGNvbW11bmljYXRpbmcgaG93IG11Y2ggZWZmb3J0IGhhcyB1bmRlcnRha2VuIGJ5
IHRoZSBwYXJ0eQ0KIGRvaW5nIHRoZSB3b3JrIHRvIHRoZSBlbnRpdHkgdGhhdCBpcyByZWNlaXZp
bmcgdGhlIG91dHB1dCBvZiB0aGF0IHdvcmsuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPktlbjxi
cj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFN1biwgT2N0IDEyLCAyMDE0IGF0
IDM6MTYgUE0sIENvbGluIFdhbGxpcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOkNvbGluLldhbGxpc0Bk
aWEuZ292dC5ueiI+Q29saW4uV2FsbGlzQGRpYS5nb3Z0Lm56PC9hPiZndDsgd3JvdGU6PG86cD48
L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlB1dHRpbmcgdGhpcyBzcGxpdCwgYmFj
ayBpbnRvIG9uZSB0aHJlYWQuLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPuKApiAm
bmJzcDthbmQgcGxlYWRpbmcgdG8gZm9sa3MgdG8gZm9jdXMgYmFjayBvbiB0aGUgdmVjdG9ycywg
b3IgYXNwZWN0cywgb3Ig4oCYdGhpbmdz4oCZIC0gd2hhdGV2ZXIgd2UgY2FsbA0KIHRoZW0g4oCT
IHRoYXQgdGhlIFJQIGhhcyBhbiBpbnRlcmVzdCBpbi4gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
IzFGNDk3RCI+SnVzdGluIGlzIHZhbGlhbnRseSB0cnlpbmcgdG8gcmUtc3RhdGUgdGhlIHB1cnBv
c2Ugb2YgaGlzIG9wZW5pbmcg4oCYdmVjdG9yc+KAmSBzdHJhd21hbiDigJMgYWx3YXlzIHVzZWZ1
bA0KIHRvIHJlZnJlc2ggb25l4oCZcyBtZW1vcnkgYnkgZ29pbmcgYmFjayB0byBsb29rIGF0IHRo
ZW0uLi48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaXMgc3RhcnRpbmcgbGlzdCBv
ZiB2ZWN0b3JzIHdhczo8L3NwYW4+DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklkZW50aXR5
IFByb29maW5nPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q3JlZGVudGlhbCBTdHJl
bmd0aDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFzc2VydGlvbiBQcmVzZW50YXRp
b248L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5PcGVyYXRpb25hbCBNYW5hZ2VtZW50
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6IzFGNDk3RCI+SWYgdGhlIGRpc2N1c3Npb24gb24gTG9BcyBvZmZlcnMgYW55IHZhbHVl
IGhlcmUsIGl0IHdvdWxkIGJlIHRvIGFkZCBzb21lIGZpbmVyIGdyYWluZWQgYWRkaXRpb24gdG8N
CiB0aGUgYWJvdmUgKGZhaXJseSBjb2Fyc2UtZ3JhaW5lZCkgbGlzdC48L3NwYW4+PG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5U
aGVyZeKAmXMgYWxyZWFkeSBhbiBhY2tub3dsZWRnbWVudCB0aGF0IE9wZXJhdGlvbmFsIE1hbmFn
ZW1lbnQgbWF5IGJlIGNvbXBvc2VkIG9mIGEgcmFuZ2Ugb2YgY29uY2VybnMNCiDigJMgYSBtaXgg
b2YgY29udGV4dCBkZXBlbmRlbnQsIHRlbXBvcmFsIGFuZCBzdGF0aWMgKG1vcmUgdmVjdG9ycz8p
IOKAkyB0aGF0IGluZmx1ZW5jZSB0aGUgUlDigJlzIGRlY2lzaW9uIHRvIGFjY2VwdCBvciBvdGhl
cndpc2UsIGFuIGF1dGhlbnRpY2F0ZWQgaWRlbnRpdHkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
IzFGNDk3RCI+SWYgd2UgZ290IHRvIGEgcG9pbnQgd2hlcmUgd2UgY291bGQgYWdyZWUgb24gd2hh
dCB0aGVzZSB2ZWN0b3JzIGFyZSwgdGhlbiB3ZSBjYW4gaGF2ZSB0aGUgKHNlcGFyYXRlKQ0KIGRl
YmF0ZSBhYm91dCB3aGV0aGVyIGNvbWJpbmluZyB0aGVtL2RlbGluZWF0aW5nIHRoZW0gaW4gc29t
ZSB3YXkgaXMgdXNlZnVsL2hlbHBmdWwsIG9yIG5vdC48L3NwYW4+PG86cD48L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
MUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5DaGVlcnM8L3Nw
YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Db2xpbg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5
bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu
MHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gbGFuZz0i
RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0i
RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gdm90DQogWzxhIGhyZWY9Im1haWx0bzp2b3Qt
Ym91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnZvdC1ib3VuY2VzQGlldGYub3JnPC9hPl0gPGI+T24g
QmVoYWxmIE9mDQo8L2I+UmljaGVyLCBKdXN0aW4gUC48YnI+DQo8Yj5TZW50OjwvYj4gU2F0dXJk
YXksIDExIE9jdG9iZXIgMjAxNCA2OjI5IGEubS48YnI+DQo8Yj5Ubzo8L2I+IEJvdW1hLCBUaW08
YnI+DQo8Yj5DYzo8L2I+IEtlbiBEYWdnOyA8YSBocmVmPSJtYWlsdG86dm90QGlldGYub3JnIj52
b3RAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86c3dpbHNvbkBsb2Nrc3RlcC5jb20uYXUi
Pg0Kc3dpbHNvbkBsb2Nrc3RlcC5jb20uYXU8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBb
Vm9UXSBGb3VuZGF0aW9uYWwgcXVlc3Rpb25zIG9mIHByaW5jaXBsZTwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5XaGF0IHdlJ3JlIHRyeWluZyB0byBk
byB3aXRoIHRoZSAmcXVvdDtWZWN0b3JzJnF1b3Q7IGFwcHJvYWNoIGhlcmUgaXMgdG8gc3RyaWtl
IGEgYmFsYW5jZSBiZXR3ZWVuIHRoZSBvdmVybHktc2ltcGxpc3RpYyAmcXVvdDtzaW5nbGUgc2V0
IG9mIGxpbmVhciBsZXZlbHMmcXVvdDsgYXBwcm9hY2ggdGhhdCBMb0EgZ2l2ZXMgdXMgKHRoYXQg
bm9ib2R5DQogb24gdGhpcyBsaXN0IGxpa2VzIGJ1dCBhbGwgYWdyZWUgdGhhdCBhcHBzIGNhbiBh
Y3R1YWxseSBkbyBzb21lIGxldmVsIG9mIHByb2Nlc3Npbmcgd2l0aCBpdCkgYW5kIHRoZSBvdmVy
bHktY29tcGxleCAmcXVvdDt2ZXJ5IGxvbmcgY29tcGxleCBzZXQgb2YgYXR0cmlidXRlcyZxdW90
OyBhcHByb2FjaCB0aGF0IFRpbSwgU2NvdHQsIGFuZCBvdGhlcnMgaGF2ZSBicm91Z2h0IHVwICh0
aGF0IHNlZW1zIG1vcmUgZXhwcmVzc2l2ZSBhbmQgaWRlYWwgYnV0IG5vIGFwcA0KIGlzIGV2ZXIg
Z29pbmcgdG8gbWFrZSBzZW5zZSBvZiwgb3IgZXZlbiB0cnkgdG8pLiBJIHRoaW5rIGl0J3Mgc2Fm
ZSB0byBzYXkgdGhhdCBuZWl0aGVyIGV4dHJlbWUgd29ya3MgYW5kIHRoYXQgYSByaWdodCBhbnN3
ZXIgcHJvYmFibHkgbGllcyBpbiB0aGUgbWlkZGxlLiZuYnNwOw0KPG86cD48L286cD48L3A+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+U28gdGhhdCdzIHdoYXQgdGhpcyBzdHJh
d21hbiBpcyAtLSBpdCdzIHNpbXVsdGFuZW91c2x5IGxlc3MgY29tcGxleCBhbmQgbW9yZSBjb21w
bGV4IHRoYW4gdGhlIGFsdGVybmF0aXZlcy4gSXMgaXQgdGhlIHJpZ2h0IGN1dD8gUHJvYmFibHkg
bm90LCBidXQgaXQncyBhdCBsZWFzdCBhIGN1dHRpbmcgcG9pbnQNCiB0aGF0IHdlIGNhbiBwdXNo
IHRvIGVpdGhlciBzaWRlLiBXaGF0IEkgdGhpbmsgd2UgbmVlZCB0byBkdXRpZnVsbHkgYXZvaWQg
aXMgcHVzaGluZyBpdCBoYXJkIHRvIGVpdGhlciBlbmQuIEkgcmVhbGx5IGxpa2UgdGhlIG5vdGlv
biB0aGF0IGV2ZW4gaWYgdGhlIGNvbWJpbmF0aW9ucyBvZiB0aGUgdmVjdG9yIHZhbHVlcyBhcmVu
J3QgZGlyZWN0bHkgY29tcGF0aWJsZSAoYXMgU3RldmUgc2F5cyksIHRoZW4gdGhlIGJ1aWxkaW5n
IGJsb2NrcyB3b3VsZA0KIGF0IGxlYXN0IGJlIGNvbXBhcmFibGUsIGdpdmluZyBhIGhvcGUgb2Yg
ZGVmaW5pbmcgYSBwb2xpY3kgdG8gdHJhbnNsYXRlIGJldHdlZW4gdGhlbSB3aGVuIG5lZWRlZC4m
bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPkFsc28sIEkgd2FudGVkIHRvIGtleSBpbnRvIHRoZSBmYWN0IHRoYXQgdGhlcmUgYXJl
IHNldmVyYWwgaW5kZXBlbmRlbnQgYW5kIG9ydGhvZ29uYWwgY29tcG9uZW50cyBoZXJlLiBNYXli
ZSBpdCdzIG5vdCBhIHNldCBvZiBsZXZlbHMgdGhhdCBhcmUgdGllZCB0b2dldGhlciwgYnV0IEkg
dGhpbmsgaXQgaXMgaW4NCiBzb21ld2F5IGEgc2V0IG9mIGluZGVwZW5kZW50ICp0aGluZ3MqIHRo
YXQgYXJlIHRpZWQgdG9nZXRoZXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDstLSBKdXN0aW48bzpwPjwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx
RjQ5N0QiPuKApuKApuKApuKApuKApuKApuKApuKApuKApuKApuKApuKApuKApuKApuKApuKApuKA
puKApuKApuKApuKApuKApi48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8
L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkl0IG1heSBtYWtl
IHNlbnNlIHRvIGxvb2sgYXQgTE9BcyBhcyBzb21ldGhpbmcgdGhhdCBpcyAmcXVvdDtjb2Fyc2Ut
Z3JhaW5lZCZxdW90OyBhbmQgYSBzdGFydGluZyBwb2ludC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPldlIGFsbCB0aGluayBpdCBpcyBub3QgZW5vdWdoLCBidXQgaW4gdGhlIGFi
c2VuY2Ugb2YgdGhlIEJvcmcgc2hvd2luZyB1cCB0byBlbmZvcmNlIGEgY29sbGVjdGl2ZSBoaXZl
LW1pbmQgYWNyb3NzIG9yZ2FuaXphdGlvbmFsIGJvdW5kYXJpZXMsIHdlIGNhbiBsaXZlIHdpdGgg
aXQgYW5kIHVzZSBpdCBhcyBhDQogc3RhcnRpbmcgcG9pbnQgZm9yIHRoZSBkaXNjdXNzaW9uICZx
dW90O1doYXQgbW9yZSBkbyB3ZSBuZWVkIGluIG9yZGVyIHRvIGxldCB0aGlzIHBlcnNvbiBpbiB0
aGUgZG9vcj8mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i
c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFuZCB0aGF0IGlzIHdo
ZXJlIFJQIGltcGxlbWVudGVkIGNvbXBlbnNhdGluZyBjb250cm9scyBjYW4gcGxheSBhIHBhcnQu
IFRoZSBjaGFsbGVuZ2UgaXMgdGhhdCBmb2xrcyBzZWVtIHRvIGNvbmZsYXRlICZxdW90O3RoaW5n
cyBuZWVkZWQgdG8gZW5zdXJlIGNvbmZpZGVuY2UgaW4gYW4gaWRlbnRpdHkmcXVvdDsgd2l0aCAm
cXVvdDt0aGluZ3MNCiBuZWVkZWQgdG8gbWl0aWdhdGUgcmlzayBpbiB0aGUgdHJhbnNhY3Rpb24m
cXVvdDsgYW5kIHdobyBpcyAoQ1NQIG9yIFJQKSByZXNwb25zaWJsZSBmb3Igd2hhdC48bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij4tIEFuaWw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjotIEFuaWwgSm9objxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj46LSBNYWtpbmcgRGlnaXRhbCBTZXJ2aWNl
cyBTZWN1cmUgYW5kIFRydXN0d29ydGh5PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPjotDQo8YSBocmVmPSJodHRwczovL2Jsb2cuYW5pbGpvaG4uY29tIiB0YXJnZXQ9Il9i
bGFuayI+aHR0cHM6Ly9ibG9nLmFuaWxqb2huLmNvbTwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBG
cmksIE9jdCAxMCwgMjAxNCBhdCAxMTowMiBQTSwgJmx0OzxhIGhyZWY9Im1haWx0bzpzd2lsc29u
QGxvY2tzdGVwLmNvbS5hdSI+c3dpbHNvbkBsb2Nrc3RlcC5jb20uYXU8L2E+Jmd0OyB3cm90ZTo8
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KV2UgYXJlIGFsbCBhZ3JlZWQg
b2YgY291cnNlIHRoYXQgUlBzIG5lZWQgdG8gdW5kZXJzdGFuZCB0aGVpciByaXNrcywgZGV0ZXJt
aW5lIHdoYXQncyBuZWVkZWQgZnJvbSBhbnkgZXh0ZXJuYWwgcHJvY2VzcyBvZiBpZGVudGlmaWNh
dGlvbiBvciBhdHRyaWJ1dGUgYXR0ZXN0YXRpb24sIGNvbW11bmljYXRlIHRob3NlIG5lZWRzIHRv
IGNhbmRpZGF0ZSBBUHMsIGFuZCBmcm9tIHRoZXJlLCBjb250cmFjdCBhbiBhY2NlcHRhYmxlIHBy
b3ZpZGVyLjxicj4NCjxicj4NCk15IHF1ZXN0aW9uIGlzIHdoZXRoZXIgb3Igbm90IGEgcGlnZW9u
aG9sZWQgTE9BIGhlbHBzIGF0IGFueSBwb2ludCBpbiB0aGlzIHByb2Nlc3MuPGJyPg0KPGJyPg0K
VGhlIGRldmlsIGlzIGluIHRoZSBkZXRhaWwuJm5ic3A7IFRvIG15IG1pbmQsIExPQSBpcyBhbiBp
bnRlcm1lZGlhdGUgc3RlcCB0aGF0IHRha2VzIGEgZGV0YWlsZWQgcmlzayBhbmFseXNpcywgc3F1
ZWV6ZXMgaXQgaW50byBhIGJpbiAobG9zaW5nIGxvdHMgb2YgaW5mb3JtYXRpb24gYXMgYSByZXN1
bHQpLCB3aGljaCBpcyB0aGVuIHVzZWQgdG8gc2hvcnRsaXN0IGNhbmRpZGF0ZSBwcm92aWRlcnMs
IGJlZm9yZSBnb2luZyBpbnRvIGRldGFpbGVkIGR1ZSBkaWxpZ2VuY2UNCiB3aGVyZSBhbGwgdGhv
c2UgZGV0YWlscyBuZWVkIHRvIGJlIHB1dCBiYWNrIG9uIHRoZSB0YWJsZS48YnI+DQo8YnI+DQpJ
IHRoaW5rIHdlIGFsbCBrbm93IGJ5IG5vdyBvZiBjYXNlcyB3aGVyZSBSUHMgaGF2ZSBsb29rZWQg
YXQgY2FuZGlkYXRlIElkUHMgYXQgYSBnaXZlbiBMT0EsIGFuZCBoYXZlIGNvbWUgdXAgd2l0aCB0
aGUgcmVxdWVzdCBvZiAmcXVvdDtMT0EgdHdvIGFuZCBhIGhhbGYmcXVvdDsgKHRoaXMgd2FzIG1l
bnRpb25lZCBhdCBDSVMgMjAxNCBtb3JlIHRoYW4gb25jZSwgYW5kIEkgaGF2ZSBzZWVuIGl0IGZp
cnN0IGhhbmQgaW4gdGhlIFVLIElEQVApLjxicj4NCjxicj4NCkNsZWFybHkgd2hhdCdzIGdvaW5n
IG9uIGhlcmUgaXMgYW4gUlAncyBpZGVhIG9mIHNheSAmcXVvdDtMT0EgMiZxdW90OyBkaWZmZXJz
IGZyb20gYSBnaXZlbiBJZFAncyBpZGVhIG9mIExPQSAyLiZuYnNwOyBNb3Jlb3ZlciwgdGhlIGlk
ZWEgb2YgTE9BIDIgbXVzdCBkaWZmZXIgZnJvbSBvbmUgSWRQIHRvIGFub3RoZXIgSWRQLiZuYnNw
OyBXaGVuIHBlb3BsZSBhc2sgZm9yICZxdW90O0xPQSAyLjUmcXVvdDsgd2hhdCB0aGV5J3JlIGFz
a2luZyBmb3IgaXMgYSBjdXN0b21pc2VkIGlkZW50aWZpY2F0aW9uLiZuYnNwOw0KIElmIExPQSAy
IGlzbid0IHdoYXQgaXQgc2VlbXMsIHRoZW4gdGhlcmUgY2Fubm90IHBvc3NpYmx5IGJlIGFueSBz
dWNoIHRoaW5nIGFzIGEgKnN0YW5kYXJkaXNlZCogTE9BIDIuNS4mbmJzcDsgQWxsIHdlIHdpbGwg
Z2V0IGlzIGZyZXNoIGNhbGxzIGZvciAmcXVvdDtMT0EgMi43NSBwbGVhc2UmcXVvdDsuPGJyPg0K
PGJyPg0KSWYgUlBzIG5lZWQgdG8gZG8gZGV0YWlsZWQgYW5hbHlzaXMgb2YgYXV0aGVudGljYXRp
b24gbmVlZHMsIGFuZCBnZXQgZGV0YWlsZWQgdmVyaWZpY2F0aW9uIG9mIHRoZSBhY3R1YWwgSUQg
cHJvb2ZpbmcgZG9uZSBieSBJZFBzIGFuZCBBUHMsIHRoZW4gSSBqdXN0IGRvbid0IHNlZSBhbnkg
cG9pbnQgYXR0YWNoaW5nIHRoZSBMT0EgbGFiZWwgYWxvbmcgdGhlIHdheS4mbmJzcDsgSXQncyBt
aXNsZWFkaW5nLjxicj4NCjxicj4NCkNoZWVycyw8YnI+DQo8YnI+DQpTdGV2ZS48YnI+DQo8YnI+
DQpTdGVwaGVuIFdpbHNvbjxicj4NCkxvY2tzdGVwPGJyPg0KPGEgaHJlZj0iaHR0cDovL2xvY2tz
dGVwLmNvbS5hdSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9sb2Nrc3RlcC5jb20uYXU8L2E+PGJy
Pg0KTG9ja3N0ZXAgQ29uc3VsdGluZyBwcm92aWRlcyBpbmRlcGVuZGVudCBzcGVjaWFsaXN0IGFk
dmljZSBhbmQgYW5hbHlzaXM8YnI+DQpvbiBkaWdpdGFsIGlkZW50aXR5IGFuZCBwcml2YWN5LiZu
YnNwOyBMb2Nrc3RlcCBUZWNobm9sb2dpZXMgZGV2ZWxvcHMgdW5pcXVlPGJyPg0KbmV3IHNtYXJ0
IElEIHNvbHV0aW9ucyB0aGF0IGVuaGFuY2UgcHJpdmFjeSBhbmQgcHJldmVudCBpZGVudGl0eSB0
aGVmdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+T24gT2N0IDEwLCAyMDE0LCBhdCAxMDo1MSBBTSwgQm91bWEsIFRpbSAmbHQ7PGEgaHJl
Zj0ibWFpbHRvOlRpbS5Cb3VtYUB0YnMtc2N0LmdjLmNhIj5UaW0uQm91bWFAdGJzLXNjdC5nYy5j
YTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw
YW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGFn
cmVlIHdpdGggS2VuLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE
Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz
cGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V2hl
biB3ZSBkZXZlbG9wZWQgbGV2ZWxzIG9mIGFzc3VyYW5jZSAoaGVyZSBpbiBDYW5hZGEpIHdlIGRp
ZCBzZXZlcmFsIHRoaW5nczo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG
NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tQ0Ei
IHN0eWxlPSJmb250LWZhbWlseTpTeW1ib2wiPsK3PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIiBz
dHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldlIGRlZmluZWQgdGhlbSBhcyBsZXZlbHMgb2YgY29uZmlk
ZW5jZSByZXF1aXJlZCAoTGV2ZWxzIDEgdGhyb3VnaCA0KTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjxwPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1mYW1pbHk6U3ltYm9sIj7Ctzwvc3Bh
bj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gbGFuZz0i
RU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XZSBtYXBwZWQgdGhl
c2UgbGV2ZWxzIG9mIGNvbmZpZGVuY2UgdG8gYSByYW5nZSBvZiBkZWdyZWUgb2YgaW1wYWN0cy48
L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQt
ZmFtaWx5OlN5bWJvbCI+wrc8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNp
emU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
Ow0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
IzFGNDk3RCI+V2UgdGhlbiBzcGVjaWZpZWQgc2VwYXJhdGVseSBpZGVudGl0eSBhc3N1cmFuY2Ug
bGV2ZWxzIGFuZCBjcmVkZW50aWFsIGFzc3VyYW5jZSBsZXZlbHMgKGFuZCBmb2N1c2VkIG9uIGNy
ZWRlbnRpYWwgZmlyc3QpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4t
Q0EiIHN0eWxlPSJmb250LWZhbWlseTpTeW1ib2wiPsK3PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNB
IiBzdHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldlIGFsc28gZmFjdG9yZWQgb3V0IGxpa2VsaWhvb2Qg
aW4gdGhlIGFzc3VyYW5jZSBsZXZlbCBhc3Nlc3NtZW50IHByb2Nlc3MuIFRoYXQgbWFkZSB0aGUg
YXNzZXNzbWVudHMgbXVjaCBsZXNzIHN1YmplY3RpdmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMUY0OTdEIj5BdCB0aGUgZW5kIG9mIHRoZSBkYXksIGFzIEtlbiBzdGF0ZXMsICZu
YnNwO2l04oCZcyB0aGUgam9iIHRoZSBSUCB0byB1bmRlcnN0YW5kIHRoZWlyIHJpc2sNCiAoYWxv
bmcgd2l0aCBsaWtlbGlob29kKSBhbmQgdG8gY29tbXVuaWNhdGUgYSBzdGFuZGFyZGl6ZWQgcmVx
dWlyZW1lbnQgYmFjayB0byBhIHByb3ZpZGVyIChBUCk8L3NwYW4+PG86cD48L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIEFQIGlzICZuYnNwO2FjY291bnRhYmxlIGZvciBwcm92
aWRpbmcgYSB2ZXJ5IHByZXNjcmliZWQgY29tcG9uZW50IHRoYXQgZml0cyBpbnRvIGEgbGFyZ2Vy
DQogc3lzdGVtIGFuZCBhIHJpc2sgZW52aXJvbm1lbnQgdGhhdCB0aGV5IG1pZ2h0IG5vdCBoYXZl
IGEgZnVsbCB2aWV3IGludG8uIFRoZSBSUCBtYXkgcHV0IGluIHByb3Zpc2lvbnMgdG8gc2hhcmUg
dGhlIHJpc2sgd2l0aCB0aGUgQVAsIG9yIG5vdCBidXQgdGhhdCBlbnRpcmVseSBkZXBlbmRzIG9u
IHRoZSBhcnJhbmdlbWVudCwgYnV0IGF0IGxlYXN0IHRoZSBSUCBhbmQgQVAgdW5kZXJzdGFuZCB3
aGF04oCZcyBvbiB0aGUgdGFibGUgYXMgYSBzdGFydGluZw0KIHBvaW50Ljwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SW4gQ2FuYWRhLCB3ZSBkaWQgdGhhdCB3aXRoIHRo
ZSBjcmVkZW50aWFsIGZpcnN0LCBhbmQgYXJlIG5vdyBmaWd1cmluZyBvdXQgaWRlbnRpdHkNCiAo
bXVjaCBoYXJkZXIpLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE
Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz
cGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBh
bHNvIGFncmVlIHRoYXQg4oCYaWRlbnRpdHnigJkgaXMganVzdCBhIHNldCBvZiBhdHRyaWJ1dGVz
IOKAk2FuZCAmbmJzcDt0aGVzZSBpZGVudGl0eSBhdHRyaWJ1dGVzDQogY2FuIHZhcnkgYmV0d2Vl
biBvcmdhbml6YXRpb25zIG9yIGp1cmlzZGljdGlvbnMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMUY0OTdEIj5BcyBmb3IgdGhlIHRlcm0g4oCYdmVjdG9yc+KAmSwgSSBnZXQgdGhl
IGlkZWEsIGJ1dCBJIHRoaW5rIHRoZSBjb21tdW5pdHkgd2lsbCB0aGluayBpdOKAmXMNCiB0b28g
dGVjaG5pY2FsIG9yIGVzb3RlcmljLiBJIGxpa2UgdG8gdGhpbmsgb2YgYSDigJhkaWdpdGFsIGlk
ZW50aXR54oCZIChvciB3aGF0ZXZlciB5b3UgY2FsbCBpdCksIHdoZW4gaXQgc2hvd3MgdXAgYXQg
eW91ciBkaWdpdGFsIGZyb250IGRvb3IsIGl0IGlzIHRoZSBwcm9kdWN0IG9mIGEgdmVyeSBsb25n
LCBjb21wbGV4IHN1cHBseSBjaGFpbiwgZnJhdWdodCB3aXRoIG1hbnkgcmlza3MgYW5kIGNvbXBy
b21pc2VzLiBJIG1heSBoYXZlIGNvbmZpZGVuY2UNCiBpbiBjZXJ0YWluIHBpZWNlcyBvZiwgYnV0
IG90aGVyIEkgbWlnaHQgbm90IHRydXN0IGF0IGFsbC48L3NwYW4+PG86cD48L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMUY0OTdEIj5UaW08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3
RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48
c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu
YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGEgbmFt
ZT0iMTQ5MDZiMTBmYjIxNWE1Zl8xNDkwNmFjNmI0YWMxYzdhXzE0OTA2YSI+PC9hPjxiPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU
YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU
YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+DQogdm90IFs8YSBocmVmPSJtYWls
dG86dm90LWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzp2b3QtYm91bmNlc0BpZXRmLm9yZzwvYT5d
IDxiPk9uIEJlaGFsZiBPZg0KPC9iPktlbiBEYWdnPGJyPg0KPGI+U2VudDo8L2I+IE9jdG9iZXIt
MDktMTQgOTo0MiBQTTxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnN3aWxzb25AbG9j
a3N0ZXAuY29tLmF1Ij5zd2lsc29uQGxvY2tzdGVwLmNvbS5hdTwvYT48YnI+DQo8Yj5DYzo8L2I+
IDxhIGhyZWY9Im1haWx0bzp2b3RAaWV0Zi5vcmciPnZvdEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5T
dWJqZWN0OjwvYj4gUmU6IFtWb1RdIEZvdW5kYXRpb25hbCBxdWVzdGlvbnMgb2YgcHJpbmNpcGxl
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n
PSJFTi1DQSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj48c3BhbiBsYW5nPSJFTi1DQSI+U3RldmUsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tQ0EiPiZuYnNwOzwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
PHNwYW4gbGFuZz0iRU4tQ0EiPkFzIHdlIGhhdmUgY29tbXVuaWNhdGVkIGluJm5ic3A7dGhlIHBh
c3QsIEkgYW0gYSBzdHJvbmcgYmVsaWV2ZXIgdGhlIGFuIExPQSBkZXNpZ25hdGlvbiBpcyBhbiBp
bmRpY2F0aW9uIG9mIHRoZSBwcm9jZXNzZXMvbWVjaGFuaXNtcyB0aGF0IGFuJm5ic3A7SWRQIGhh
cyB1bmRlcnRha2VuLiBJbg0KIG90aGVyIHdvcmRzLCBpdCBpcyBhIGNvbW11bmljYXRpb24gdG9v
bC4mbmJzcDtUaGUgY2hvaWNlIGlzIHRoZSBSUHMuIFRoYXQgaXMsIGFuJm5ic3A7YXNzZXJ0aW9u
IGF0IGEgc3BlY2lmaWMgTE9BIGJ5IGFuJm5ic3A7SWRQL0NTUC9BUCZuYnNwO2lzIG9uZSBvZiB0
aGUgbWVjaGFuaXNtcyBhIFJQIHNob3VsZCB1c2UgdG8gb2Zmc2V0IHRoZSBhdXRoZW50aWNhdGlv
biByaXNrIGl0IGhhcyBpZGVudGlmaWVkIGZvciB0aGUgc2VydmljZSBpdCB3YW50cyB0byBkZWxp
dmVyLiBJbiBvdGhlcg0KIHdvcmRzLCBpdCBpcyB0aGUgcmlzayBvZiB0aGUgUlAgdGhhdCBpcyBw
YXJhbW91bnQgbm90IHRoZSBjbGFpbXMgb2YgYW4mbmJzcDtpZGVudGl0eS9jcmVkZW50aWFsL2F0
dHJpYnV0ZS90b2tlbiBwcm92aWRlci48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUNBIj4mbmJzcDs8L3Nw
YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PjxzcGFuIGxhbmc9IkVOLUNBIj5MaWtlIHlvdSwgSSBhbSBhIHN0cm9uZyBiZWxpZXZlciB0aGF0
IHRoZSBkZXRlcm1pbmF0aW9uIG9mIHdoZXRoZXIgb3Igbm90IGFuIGlkZW50aXR5IGlzIGdvb2Qg
ZW5vdWdoIGlzIHRoZSByZXNwb25zaWJpbGl0eSBvZiB0aGUgUlAuIEluIG15IGV4cGVyaWVuY2Us
IHRoZXkgbWFrZQ0KIHRoYXQgZGV0ZXJtaW5hdGlvbiBiYXNlZCB1cG9uIGEgc2V0IG9mIGF0dHJp
YnV0ZXMgdGhleSBiZWxpZXZlIGFyZSBuZWNlc3NhcnkuIElmIHRoZXkgdHJ1c3QgdGhhdCBhbiBJ
ZFAncyBhc3NlcnRpb24gb2YgaWRlbnRpdHkgY292ZXJzIHRoZSBhdHRyaWJ1dGVzIHRoZXkgYmVs
aWV2ZSBhcmUmbmJzcDtyZXF1aXJlZCB0aGVtIHRoZXkgY2FuIGFjY2VwdCB0aGUgYXNzZXJ0aW9u
LiBJZiBpdCBkb2Vzbid0IHRoZW4gdGhhdCBoYXZlIHRvIGltcGxlbWVudCBhZGRpdGlvbmFsDQog
bWVjaGFuaXNtcyB0byBvZmZzZXQgdGhlIHJlc2lkdWFsIHJpc2suPC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF
Ti1DQSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1DQSI+V2l0aCByZXNwZWN0IHRvIHZlY3Rv
cnMgb2YgdHJ1c3QsIEkgYW0gaW50ZXJlc3RlZCBpbiBleHBsb3Jpbmcgd2hhdCB0aGV5IGFyZSBh
bmQgaG93IHRoZXkgY2FuIGJlIGFwcGxpZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1DQSI+Jm5ic3A7
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj48c3BhbiBsYW5nPSJFTi1DQSI+S2VuPGJyPg0KPGJyPg0KT24gVGh1cnNkYXksIE9jdG9i
ZXIgOSwgMjAxNCwgJmx0OzxhIGhyZWY9Im1haWx0bzpzd2lsc29uQGxvY2tzdGVwLmNvbS5hdSI+
c3dpbHNvbkBsb2Nrc3RlcC5jb20uYXU8L2E+Jmd0OyB3cm90ZTo8L3NwYW4+PG86cD48L286cD48
L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90OyI+Rmlyc3QsIHRvIGludHJvZHVjZSBteXNlbGYsIEkgYW0gYW4gaWRlbnRpdHkg
YW5kIHByaXZhY3kgcmVzZWFyY2hlciwgYW5hbHlzdCBhbmQgY29uc3VsdGFudC4mbmJzcDsgSSd2
ZSBiZWVuDQogaW52b2x2ZWQgaW4gdGhpcyBzaW5jZSAxOTk1LCB3aGVuIEkgY3V0IG15IHRlZXRo
IGluIFBLSSBhbmQgc21hcnRjYXJkcyAod2l0aCB0aGUgZWFybHkgY29tcGFuaWVzIHRoYXQgYmVj
YW1lIEJhbHRpbW9yZSBUZWNobm9sb2dpZXMpLiBTaW5jZSB0aGVuIEkndmUgd29ya2VkIG9uIGlk
ZW50aXR5IG1hbmFnZW1lbnQgZnJhbWV3b3JrcywgcmVndWxhdGlvbnMgYW5kIHN0YW5kYXJkcy4g
Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SSBzdWJzY3JpYmUg
dG8gdGhlIG9sZCBJdGFsaWFuIHByb3ZlcmI6ICZxdW90O2l0J3MgbmljZSB0byB0cnVzdCBidXQg
YmV0dGVyIG5vdCB0byZxdW90Oy4mbmJzcDsgV29yZHMgbWF0dGVyIGFuZCBJDQogd29uZGVyIGlm
IHdlIHNob3VsZG4ndCBiZSB1c2luZyB0aGUgd29yZCB0cnVzdCBzbyBtdWNoLiAmbmJzcDs8L3Nw
YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu
IGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB
cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Nb3JlIHByYWdtYXRpY2FsbHksIEkg
bm90ZSB0aGUgdmVyeSBzdHJvbmcgJnF1b3Q7QXR0cmlidXRlcyZxdW90OyBwdXNoIG9mIHRoZSBw
YXN0IDE4IG1vbnRocy4mbmJzcDsgQW5kcmV3IE5hc2gsIEFuaWwNCiBKb2huLCBteXNlbGYgYW5k
IG90aGVycyBoYXZlIHdyaXR0ZW4gYWJvdXQgdGhpcy4mbmJzcDsgVGhlIEZJRE8gQWxsaWFuY2Ug
aXMgYWxsIGFib3V0IGF1dGhlbnRpY2F0aW9uIGFuZCBhdHRyaWJ1dGVzLCBhbmQgdGhleSBwdXJw
b3NlZnVsbHkgbGVhdmUgJnF1b3Q7aWRlbnRpdHkmcXVvdDsgYXMgYSBtYXR0ZXIgZm9yIG90aGVy
cyB0byB3b3JrIG91dCBmdXJ0aGVyIHVwIHRoZSBzdGFjay4gVGhlIE9JRCBGb3VuZGF0aW9uIGlz
IHByb21vdGluZyBhbiBBdHRyaWJ1dGVzIEV4Y2hhbmdlDQogTmV0d29yayAmcXVvdDtBWE4mcXVv
dDsgYXJjaGl0ZWN0dXJlLiZuYnNwOyBOZXcgZW50cmFudHMgbGlrZSA8YSBocmVmPSJodHRwOi8v
aWQubWUvIiB0YXJnZXQ9Il9ibGFuayI+DQppZC5tZTwvYT4gKGFuIE5TVElDIHBpbG90IHBhcnRp
Y2lwYW50KSB0YWxrIGFib3V0IGF0dHJpYnV0ZXMgYW5kIGF2b2lkICZxdW90O2lkZW50aXR5JnF1
b3Q7LiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZu
YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkkgbWVudGlv
biBhbGwgb2YgdGhpcyBhcyBhIHByZWx1ZGUgdG8gc3VnZ2VzdCB0aGF0ICZxdW90O3ZlY3RvciBv
ZiB0cnVzdCZxdW90OyBpcyBzeW5vbnltb3VzIHdpdGggJnF1b3Q7YXR0cmlidXRlJnF1b3Q7Lg0K
IEkgd29uZGVyIGlmIGl0IHdvdWxkIGJlIGNsZWFyZXIgdG8gdXNlIHBsYWluIGFuZCBjdXJyZW50
IGxhbmd1YWdlIHJhdGhlciB0aGFuIGNhcnJ5IGZvcndhcmQgdGhlIGZ1enp5IGFuZCBJIHRoaW5r
IG92ZXJseSBhbWJpdGlvdXMgaWRlYSBvZiAmcXVvdDt0cnVzdCZxdW90Oz8mbmJzcDs8L3NwYW4+
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz
cGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh
bmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh
bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5GaW5hbGx5LCBJJ2QgbGlrZSB0byB0aHJv
dyBpbiBteSBhYmlkaW5nIGNvbmNlcm4gdGhhdCBMT0FzIGhhdmUgZm91bmRlcmVkIHNpbXBseSBi
ZWNhdXNlIGl0J3MgZGlmZmljdWx0DQogdG8gcGlnZW9uaG9sZSByaXNrLiBPbmUgcGFydHkncyBp
ZGVhIG9mICZxdW90O21lZGl1bSZxdW90OyByaXNrIGZvciBpbnN0YW5jZSB3aWxsIHJhcmVseSBt
YXAgcHJlY2lzZWx5IHRvIGFub3RoZXIncy4gSSB0aGluayBwZW9wbGUgaGF2ZSBiZWVuIG1pc2xl
ZCBpbnRvIHRoaW5raW5nIHRoYXQgYW4gJnF1b3Q7TE9BIDMmcXVvdDsgaWRlbnRpdHkgc2hvdWxk
IGJlIGJlIGFibGUgdG8gYmUgdXNlZCBvbiBpdHMgZmFjZSAoaS5lLiB3aWxsICZxdW90O2ludGVy
b3BlcmF0ZSZxdW90OykgYXQgYW55ICZxdW90O0xPQQ0KIDMmcXVvdDsgUlAuIFJpc2sgbWFuYWdl
bWVudCBpcyBub3Qgc28gc2ltcGxlLiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDsiPlRoZSBMT0EgcGFyYWRpZ20gYm9ycm93cyBmcm9tIFJpc2sgTWFuYWdlbWVudCBz
dGFuZGFyZHMgbGlrZSBJU08gMzEwMDAgd2hpY2gmbmJzcDtvcmdhbmlzYXRpb25zIHVzZSB0byZu
YnNwO3Bsb3QmbmJzcDt0aGVpcg0KIG93biByaXNrcyBpbnRlcm5hbGx5IHR5cGljYWxseSBvbiBh
IGZpdmUgc2NhbGUgKGVnIE5lZ2xpZ2libGUgLyBMb3cgLyBNZWRpdW0gLyBIaWdoIC8gR3JhdmUp
LiZuYnNwO0J1dCZuYnNwO3Jpc2sgbWFuYWdlbWVudCZuYnNwO3N0YW5kYXJkcyByZXF1aXJlIHRo
YXQgZWFjaCBvcmdhbmlzYXRpb24gY2FsaWJyYXRlcyByaXNrIGluIGl0cyBvd24gYnVzaW5lc3Mg
Y29udGV4dCBhbmQgYWNjb3JkaW5nIHRvIGl0cyZuYnNwO293biByaXNrIGFwcGV0aXRlLiBUaGUg
cmlzayBvZiBhIGZpcmV3YWxsDQogYnJlYWNoIGZvciBleGFtcGxlIGF0IGEgc3RhcnR1cCBzb2Np
YWwgbWVkaWEgY29tcGFueSB3aWxsIGJlIGFzc2Vzc2VkIGRpZmZlcmVudGx5IGJ5IGEgYmlnIGxp
c3RlZCBoZWFsdGhjYXJlIGNvbXBhbnkuJm5ic3A7U28gb3JnYW5pc2F0aW9uIEEmbmJzcDtjYW4g
c2F5IHRoZSByaXNrIG9mIGV2ZW50IFggaXMgTG93IGJ1dCBCIGNhbiBzYXkgdGhlIHJpc2sgb2Yg
dGhlIHNhbWUgZXZlbnQgaXMgTWVkaXVtLiZuYnNwOyBBcyZuYnNwO2EgcmVzdWx0LCBMT0FzIGRv
IG5vdCBpbnRlci1vcGVyYXRlLg0KIFRoZXkgYXJlIGJhc2VkIG9uIHN0YW5kYXJkcyBtZWFudCBm
b3IgaW50cmEtb3JnYW5pc2F0aW9uIHJpc2sgbWFuYWdlbWVudCwgbm90IGludGVyLW9yZ2FuaXNh
dGlvbiBjb21tdW5pY2F0aW9uIG9mJm5ic3A7cmlzayBhc3Nlc3NtZW50cy4mbmJzcDs8L3NwYW4+
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz
cGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh
bmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh
bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5TbyBmYXIgd2l0aCBWb1Qgd2UgYXJlIGFk
ZGluZyBtb3JlIGRpbWVuc2lvbnMgdG8gdGhlIFJQcycgZ2VuZXJpYyByaXNrIG1hbmFnZW1lbnQg
ZGVjaXNpb24gbWFraW5nLCBhbmQNCiB0aGF0J3MgZ3JlYXQuJm5ic3A7IEJ1dCB3ZSBhcmUgc3Rp
bGwgcGlnZW9uaG9saW5nIHRoZSBkaW1lbnNpb25zLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDsiPkknbSBhZnJhaWQgdGhlIHJlYWxpdHkgaXMgdGhhdCByaXNrIG1hbmFnZW1l
bnQgd2lsbCBhbHdheXMgYmUgZG9uZSBsb2NhbGx5LiZuYnNwOyBBbmQgc28gaXQgc2hvdWxkIGJl
LiZuYnNwOyBXaGVuDQogYW4gUlAgaXMgbWFraW5nJm5ic3A7dGhlIGRlY2lzaW9uIHRvIGFjY2Vw
dCBvciByZWplY3QgYSBnaXZlbiBzdWJqZWN0LCB0aGV5IHdpbGwgZXZhbHVhdGUgYSByYW5nZSBv
ZiBhdHRyaWJ1dGVzIG9yJm5ic3A7c2lnbmFscy4mbmJzcDsgVGhlIHNldCBvZiBhdHRyaWJ1dGVz
IHRoYXQgbWF0dGVycyB2YXJpZXMgZnJvbSBvbmUgUlAgdG8gdGhlIG5leHQuJm5ic3A7IEkgdGhp
bmsgaXQncyBhIGdyZWF0IGlkZWEgaW5kZWVkIHRvIGNyZWF0ZSBndWlkYW5jZSBmb3IgZXZhbHVh
dGluZyBhdHRyaWJ1dGVzLA0KIGFuZCB0byBjb2FjaCBSUHMgdG8gbG9vayBhdCBhbGwgc29ydHMg
b2YgZGltZW5zaW9ucy4mbmJzcDsgSSBqdXN0IGRvbid0IHRoaW5rIGl0IGhlbHBzIGFueW9uZSB0
byBwaWdlb25ob2xlIHRoZSByaXNrIHJhdGluZ3MsIGJlY2F1c2UgYWNyb3NzIG9yZ2FuaXNhdGlv
bnMsIGFyZ3VtZW50cyBhYm91dCB0aGUgYm91bmRhcmllcyBiZXR3ZWVuIExPQSAxLzIvMy80ICh0
aGF0IGlzLCBwb2xpY3kgbWFwcGluZykgd2lsbCZuYnNwO3VuZG8gYW55IGVmZmljaWVuY2llcyBn
YWluZWQNCiBmcm9tIHRoZSBjYXRlZ29yaXphdGlvbi4gJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF
Ti1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1DQSIg
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90OyI+Q2hlZXJzLCZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tQ0Ei
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDsiPlN0ZXZlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlN0
ZXBoZW4gV2lsc29uPGJyPg0KTWFuYWdpbmcgRGlyZWN0b3I8YnI+DQpMb2Nrc3RlcCBHcm91cDxi
cj4NCjxhIGhyZWY9Imh0dHA6Ly9sb2Nrc3RlcC5jb20uYXUvIiB0YXJnZXQ9Il9ibGFuayI+aHR0
cDovL2xvY2tzdGVwLmNvbS5hdTwvYT48YnI+DQpMb2Nrc3RlcCBDb25zdWx0aW5nIHByb3ZpZGVz
IGluZGVwZW5kZW50IHNwZWNpYWxpc3QgYWR2aWNlIGFuZCBhbmFseXNpcyA8YnI+DQpvbiBkaWdp
dGFsIGlkZW50aXR5IGFuZCBwcml2YWN5LiBMb2Nrc3RlcCBUZWNobm9sb2dpZXMgZGV2ZWxvcHMg
dW5pcXVlIDxicj4NCm5ldyBzbWFydCBJRCBzb2x1dGlvbnMgdGhhdCBlbmhhbmNlIHByaXZhY3kg
YW5kIHByZXZlbnQgaWRlbnRpdHkgdGhlZnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXzxicj4NCnZvdCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86
dm90QGlldGYub3JnIj52b3RAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92b3QiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3ZvdDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t
OjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX188YnI+DQp2b3QgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnZvdEBpZXRm
Lm9yZyI+dm90QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vdm90IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby92b3Q8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_147EE18440E5AF44834B220ED35BA530D32F0CAFWLGPRDMBX01diag_--


From nobody Mon Oct 13 03:19:03 2014
Return-Path: 
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B8E41A0300 for ; Mon, 13 Oct 2014 03:19:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.399
X-Spam-Level: 
X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ArO_wiBA75pP for ; Mon, 13 Oct 2014 03:18:52 -0700 (PDT)
Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E18C1A0085 for ; Mon, 13 Oct 2014 03:18:52 -0700 (PDT)
Received: by mail-vc0-f176.google.com with SMTP id hq11so5484865vcb.7 for ; Mon, 13 Oct 2014 03:18:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ogQwWbgYh+yWQcplC+UTYwOIaSqqV3MKzhFsZt8Up0c=; b=iVtxMlMusGc8+UrZVRmlixpaB4+Am231oCdy8hQR3h1LUDS3ShHDhqmAOxogCP8tGj i1OGdXrESt0eZRtN5JRkBUXtIrVCkc7furUUSLZ0M+y2t9u5N0e71qWHj10T73ypP1wE O0DJzcX2dJKr5/TIsam3y3rXwjwIk2H+2G+h9TVcuBq3mCb4Fk0HXQEiqbYh7Y0GcXr1 ELNaHtamwDNqVa0PQGpvl/mWlt2z7uBKmJTRo8wb1v4VMcQAuuTawrOVwdw2empUAJWv gFms+s3rSDu4tNweRzhXBhEBdxTZk6mN6cD7fdWnsjjrOjcwvlGl0Ls2gdlUkiCrtMw4 kwMA==
MIME-Version: 1.0
X-Received: by 10.220.167.9 with SMTP id o9mr19332972vcy.22.1413195531175; Mon, 13 Oct 2014 03:18:51 -0700 (PDT)
Received: by 10.220.88.199 with HTTP; Mon, 13 Oct 2014 03:18:51 -0700 (PDT)
In-Reply-To: <147EE18440E5AF44834B220ED35BA530D32F0CAF@WLGPRDMBX01.dia.govt.nz>
References: <1412885935.58929166@apps.rackspace.com>  <20141010145142.51DBE1A90E3@ietfa.amsl.com> <6A0CFC85-F8F5-43F5-B02F-09720E7164F4@mitre.org> <147EE18440E5AF44834B220ED35BA530D32F0A2E@WLGPRDMBX01.dia.govt.nz>    <147EE18440E5AF44834B220ED35BA530D32F0CAF@WLGPRDMBX01.dia.govt.nz>
Date: Mon, 13 Oct 2014 06:18:51 -0400
Message-ID: 
From: Ken Dagg 
To: Colin Wallis 
Content-Type: multipart/alternative; boundary=089e01536688a24b4105054b394f
Archived-At: http://mailarchive.ietf.org/arch/msg/vot/y98mhEoZnKZhJn5H6D_F-K0VaaM
Cc: "vot@ietf.org" , Anil John 
Subject: Re: [VoT] Foundational questions of principle
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Vectors of Trust discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Oct 2014 10:19:00 -0000

--089e01536688a24b4105054b394f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Colin,
See in line.
Ken

On Monday, October 13, 2014, Colin Wallis  wrote:

>  < or they can have some sort of an hierarchy>>.
>
> I think that is a =E2=80=98tbd=E2=80=99 Anil.
>
> We may have a better idea once the concept is developed a bit further.
>
> Good fine graining on Identity Proofing there..  useful.
>
>
>
> Looking below at Ken=E2=80=99s response:
>
> To Ken=E2=80=99s suggestion qualified by his question/assumption..
>
> << Credential Strength deals with the binding of an identity to a token>>
>
> .. is along the lines Justin described it IMHO, so yea, I think =E2=80=98=
token
> proofing=E2=80=99 could be another vector/sub vector.
>
>
>
> To the comment about the value of/measurement of vectors and.
>
> < work>>
>
> ..(typically the RP I guess) [[KD: my reason for using entity was that RP
> is often seen as the service delivery agent. I wanted to be sure that an
> IdP that is relying on an AP is also included.]] then we come back to som=
e
> machine process-able way that the RP can express the vector values of the
> risk of that authentication instance/service/transaction which, as Steve
> indicates, might possibly be different for each and every
> transaction/location/context.
>
>
>
> Justin offered up a kind of codified way of expressing specific vector
> values with a marker letter and category number (saml md iop has for some
> time now as Scott mentioned), but the trick would be  to make a distincti=
on
> between what vector values the RP requires (a vector/sub vector), and wha=
t
> is =E2=80=98on offer=E2=80=99 from provider parties (another vector/sub v=
ector), but still
> in a codified way consumable by all parties. Reducing this down from a
> complex set of values, to 3-5 Vectors, with multiple sub vectors **and**
> make it meaningful and process-able, is one mother of a challenge..
>
>
>
> But already we have moved beyond the pretty blunt instrument that is LoA.=
.
> and have not yet gone to the other extreme end of the (=E2=80=98all fine
> grained/de-composed=E2=80=99) spectrum, so that is good.
>
>
>
> Who knows how much progress we could make if we keep thinking=E2=80=A6 J
>
>
>
> Cheers
>
> Colin
>
>
>
> *From:* vot [mailto:vot-bounces@ietf.org
> ] *On Behalf Of *An=
il
> John
> *Sent:* Monday, 13 October 2014 12:36 p.m.
> *To:* Ken Dagg; vot@ietf.org
> 
> *Subject:* Re: [VoT] Foundational questions of principle
>
>
>
> Ken,
>
>
>
> I think it depends on if the intention is to keep the 'vectors' flat or
> they can have some sort of an hierarchy.  If the latter, sure.
>
>
>
> Regards,
>
>
>
> - Anil
>
>
>   Regards,
>
>
>
> - Anil
>
>
>
> :- Anil John
>
> :- Making Digital Services Secure and Trustworthy
>
> :- https://blog.aniljohn.com
>
>
>
>
>
> On Sun, Oct 12, 2014 at 7:28 PM, Ken Dagg  > wrote:
>
> Anil,
>
> Do you think that these could be sub vectors of the Identity Proofing
> vector?
>
> Ken
>
>
>
> On Monday, October 13, 2014, Anil John  > wrote:
>
> Thank you Colin for herding the cats (Including myself there)!
>
>
>
> I would recommend splitting up the 'Identity Proofing' vector into its
> component bits, rather than treating it like the current amorphous blob
> that it is right now:
>
>
>
>    1. *Identity Resolution* - Establishing the uniqueness of an
>    individual within a population
>    2. *Identity Validation* - Confirming the accuracy of identity
>    information claimed by an individual
>    3. *Identity Verification* - Confirming that the claimed identity
>    information is linked to the individual making the claim
>
>
>
> Regards,
>
>
>
> - Anil
>
>
>
> :- Anil John
>
> :- Making Digital Services Secure and Trustworthy
>
> :- https://blog.aniljohn.com
>
>
>
> Colin,
>
>
>
> Good point to move the thread back to its original topic.
>
>
>
> I would suggest that there is one more vector: token proofing. This vecto=
r
> would be similar in nature to the identity proofing vector only focused o=
n
> the token rather than the identity.
>
>
>
> I have not had a chance to review the original paper to know what it says
> about the other vectors (I am supposed to be on holidays). I am assuming
> that Identity Proofing deals with how an Identity is proofed, Credential
> Strength deals with the binding of an identity to a token, and Assertion
> Presentation deals with what the IdP goes through in order to issue an
> assertion. What I believe is interesting is that these vectors are
> applicable to any entity that does the work. What is of potential interes=
t
> is how they apply to the entity that is the recipient of the output of th=
e
> work.
>
> I agree that Operational Management is an interesting, but extremely
> important, vector that could have many sub-vectors.
>
>
>
> While the LoA discussion seemed to be off track, I would suggest that it
> is part of the discussion because LoA (regardless of how many
> levels) should be a measure of and a means of communicating how much effo=
rt
> has undertaken by the party doing the work to the entity that is receivin=
g
> the output of that work.
>
>
>
> Ken
>
>
>
> On Sun, Oct 12, 2014 at 3:16 PM, Colin Wallis  > wrote:
>
> Putting this split, back into one thread..
>
> =E2=80=A6  and pleading to folks to focus back on the vectors, or aspects=
, or
> =E2=80=98things=E2=80=99 - whatever we call them =E2=80=93 that the RP ha=
s an interest in.
>
> Justin is valiantly trying to re-state the purpose of his opening
> =E2=80=98vectors=E2=80=99 strawman =E2=80=93 always useful to refresh one=
=E2=80=99s memory by going back to
> look at them...
>
> His starting list of vectors was:
>
> Identity Proofing
>
> Credential Strength
>
> Assertion Presentation
>
> Operational Management
>
>
>
> If the discussion on LoAs offers any value here, it would be to add some
> finer grained addition to the above (fairly coarse-grained) list.
>
>
>
> There=E2=80=99s already an acknowledgment that Operational Management may=
 be
> composed of a range of concerns =E2=80=93 a mix of context dependent, tem=
poral and
> static (more vectors?) =E2=80=93 that influence the RP=E2=80=99s decision=
 to accept or
> otherwise, an authenticated identity.
>
>
>
> If we got to a point where we could agree on what these vectors are, then
> we can have the (separate) debate about whether combining them/delineatin=
g
> them in some way is useful/helpful, or not.
>
>
>
> Cheers
>
> Colin
>
>
>
> *From:* vot [mailto:vot-bounces@ietf.org
> ] *On Behalf Of *Ri=
cher,
> Justin P.
> *Sent:* Saturday, 11 October 2014 6:29 a.m.
> *To:* Bouma, Tim
> *Cc:* Ken Dagg; vot@ietf.org
> ; swilson@lockstep.com.au
> 
> *Subject:* Re: [VoT] Foundational questions of principle
>
>
>
> What we're trying to do with the "Vectors" approach here is to strike a
> balance between the overly-simplistic "single set of linear levels"
> approach that LoA gives us (that nobody on this list likes but all agree
> that apps can actually do some level of processing with it) and the
> overly-complex "very long complex set of attributes" approach that Tim,
> Scott, and others have brought up (that seems more expressive and ideal b=
ut
> no app is ever going to make sense of, or even try to). I think it's safe
> to say that neither extreme works and that a right answer probably lies i=
n
> the middle.
>
>
>
> So that's what this strawman is -- it's simultaneously less complex and
> more complex than the alternatives. Is it the right cut? Probably not, bu=
t
> it's at least a cutting point that we can push to either side. What I thi=
nk
> we need to dutifully avoid is pushing it hard to either end. I really lik=
e
> the notion that even if the combinations of the vector values aren't
> directly compatible (as Steve says), then the building blocks would at
> least be comparable, giving a hope of defining a policy to translate
> between them when needed.
>
>
>
> Also, I wanted to key into the fact that there are several independent an=
d
> orthogonal components here. Maybe it's not a set of levels that are tied
> together, but I think it is in someway a set of independent *things* that
> are tied together.
>
>
>
>  -- Justin
>
> =E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=
=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=
=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6.
>
>
>
> It may make sense to look at LOAs as something that is "coarse-grained"
> and a starting point.
>
>
>
> We all think it is not enough, but in the absence of the Borg showing up
> to enforce a collective hive-mind across organizational boundaries, we ca=
n
> live with it and use it as a starting point for the discussion "What more
> do we need in order to let this person in the door?"
>
>
>
> And that is where RP implemented compensating controls can play a part.
> The challenge is that folks seem to conflate "things needed to ensure
> confidence in an identity" with "things needed to mitigate risk in the
> transaction" and who is (CSP or RP) responsible for what.
>
>
>
> Regards,
>
>
>
> - Anil
>
>
>
> :- Anil John
>
> :- Making Digital Services Secure and Trustworthy
>
> :- https://blog.aniljohn.com
>
>
>
>
>
> On Fri, Oct 10, 2014 at 11:02 PM,  > wrote:
>
>
> We are all agreed of course that RPs need to understand their risks,
> determine what's needed from any external process of identification or
> attribute attestation, communicate those needs to candidate APs, and from
> there, contract an acceptable provider.
>
> My question is whether or not a pigeonholed LOA helps at any point in thi=
s
> process.
>
> The devil is in the detail.  To my mind, LOA is an intermediate step that
> takes a detailed risk analysis, squeezes it into a bin (losing lots of
> information as a result), which is then used to shortlist candidate
> providers, before going into detailed due diligence where all those detai=
ls
> need to be put back on the table.
>
> I think we all know by now of cases where RPs have looked at candidate
> IdPs at a given LOA, and have come up with the request of "LOA two and a
> half" (this was mentioned at CIS 2014 more than once, and I have seen it
> first hand in the UK IDAP).
>
> Clearly what's going on here is an RP's idea of say "LOA 2" differs from =
a
> given IdP's idea of LOA 2.  Moreover, the idea of LOA 2 must differ from
> one IdP to another IdP.  When people ask for "LOA 2.5" what they're askin=
g
> for is a customised identification.  If LOA 2 isn't what it seems, then
> there cannot possibly be any such thing as a *standardised* LOA 2.5.  All
> we will get is fresh calls for "LOA 2.75 please".
>
> If RPs need to do detailed analysis of authentication needs, and get
> detailed verification of the actual ID proofing done by IdPs and APs, the=
n
> I just don't see any point attaching the LOA label along the way.  It's
> misleading.
>
> Cheers,
>
> Steve.
>
> Stephen Wilson
> Lockstep
> http://lockstep.com.au
> Lockstep Consulting provides independent specialist advice and analysis
> on digital identity and privacy.  Lockstep Technologies develops unique
> new smart ID solutions that enhance privacy and prevent identity theft.
>
>
>
> On Oct 10, 2014, at 10:51 AM, Bouma, Tim  > wrote:
>
>
>
> I agree with Ken,
>
>
>
> When we developed levels of assurance (here in Canada) we did several
> things:
>
>
>
> =C2=B7         We defined them as levels of confidence required (Levels 1
> through 4)
>
> =C2=B7         We mapped these levels of confidence to a range of degree =
of
> impacts.
>
> =C2=B7         We then specified separately identity assurance levels and
> credential assurance levels (and focused on credential first)
>
> =C2=B7         We also factored out likelihood in the assurance level
> assessment process. That made the assessments much less subjective.
>
>
>
> At the end of the day, as Ken states,  it=E2=80=99s the job the RP to und=
erstand
> their risk (along with likelihood) and to communicate a standardized
> requirement back to a provider (AP)
>
> The AP is  accountable for providing a very prescribed component that fit=
s
> into a larger system and a risk environment that they might not have a fu=
ll
> view into. The RP may put in provisions to share the risk with the AP, or
> not but that entirely depends on the arrangement, but at least the RP and
> AP understand what=E2=80=99s on the table as a starting point.
>
>
>
> In Canada, we did that with the credential first, and are now figuring ou=
t
> identity (much harder).
>
>
>
> I also agree that =E2=80=98identity=E2=80=99 is just a set of attributes =
=E2=80=93and  these
> identity attributes can vary between organizations or jurisdictions,
>
>
>
> As for the term =E2=80=98vectors=E2=80=99, I get the idea, but I think th=
e community will
> think it=E2=80=99s too technical or esoteric. I like to think of a =E2=80=
=98digital
> identity=E2=80=99 (or whatever you call it), when it shows up at your dig=
ital front
> door, it is the product of a very long, complex supply chain, fraught wit=
h
> many risks and compromises. I may have confidence in certain pieces of, b=
ut
> other I might not trust at all.
>
>
>
>
>
> Tim
>
>
>
>
>
> *From:* vot [mailto:vot-bounces@ietf.org
> ] *On Behalf Of *Ke=
n
> Dagg
> *Sent:* October-09-14 9:42 PM
> *To:* swilson@lockstep.com.au
> 
> *Cc:* vot@ietf.org 
> *Subject:* Re: [VoT] Foundational questions of principle
>
>
>
> Steve,
>
>
>
> As we have communicated in the past, I am a strong believer the an LOA
> designation is an indication of the processes/mechanisms that an IdP has
> undertaken. In other words, it is a communication tool. The choice is the
> RPs. That is, an assertion at a specific LOA by an IdP/CSP/AP is one of t=
he
> mechanisms a RP should use to offset the authentication risk it has
> identified for the service it wants to deliver. In other words, it is the
> risk of the RP that is paramount not the claims of
> an identity/credential/attribute/token provider.
>
>
>
> Like you, I am a strong believer that the determination of whether or not
> an identity is good enough is the responsibility of the RP. In my
> experience, they make that determination based upon a set of attributes
> they believe are necessary. If they trust that an IdP's assertion of
> identity covers the attributes they believe are required them they can
> accept the assertion. If it doesn't then that have to implement additiona=
l
> mechanisms to offset the residual risk.
>
>
>
> With respect to vectors of trust, I am interested in exploring what they
> are and how they can be applied.
>
>
>
> Ken
>
> On Thursday, October 9, 2014,  > wrote:
>
>
>
> First, to introduce myself, I am an identity and privacy researcher,
> analyst and consultant.  I've been involved in this since 1995, when I cu=
t
> my teeth in PKI and smartcards (with the early companies that became
> Baltimore Technologies). Since then I've worked on identity management
> frameworks, regulations and standards.
>
>
>
> I subscribe to the old Italian proverb: "it's nice to trust but better no=
t
> to".  Words matter and I wonder if we shouldn't be using the word trust s=
o
> much.
>
>
>
> More pragmatically, I note the very strong "Attributes" push of the past
> 18 months.  Andrew Nash, Anil John, myself and others have written about
> this.  The FIDO Alliance is all about authentication and attributes, and
> they purposefully leave "identity" as a matter for others to work out
> further up the stack. The OID Foundation is promoting an Attributes
> Exchange Network "AXN" architecture.  New entrants like id.me (an NSTIC
> pilot participant) talk about attributes and avoid "identity".
>
>
>
> I mention all of this as a prelude to suggest that "vector of trust" is
> synonymous with "attribute". I wonder if it would be clearer to use plain
> and current language rather than carry forward the fuzzy and I think over=
ly
> ambitious idea of "trust"?
>
>
>
> Finally, I'd like to throw in my abiding concern that LOAs have foundered
> simply because it's difficult to pigeonhole risk. One party's idea of
> "medium" risk for instance will rarely map precisely to another's. I thin=
k
> people have been misled into thinking that an "LOA 3" identity should be =
be
> able to be used on its face (i.e. will "interoperate") at any "LOA 3" RP.
> Risk management is not so simple.
>
>
>
> The LOA paradigm borrows from Risk Management standards like ISO 31000
> which organisations use to plot their own risks internally typically on a
> five scale (eg Negligible / Low / Medium / High / Grave). But risk
> management standards require that each organisation calibrates risk in it=
s
> own business context and according to its own risk appetite. The risk of =
a
> firewall breach for example at a startup social media company will be
> assessed differently by a big listed healthcare company. So organisation
> A can say the risk of event X is Low but B can say the risk of the same
> event is Medium.  As a result, LOAs do not inter-operate. They are based =
on
> standards meant for intra-organisation risk management, not
> inter-organisation communication of risk assessments.
>
>
>
> So far with VoT we are adding more dimensions to the RPs' generic risk
> management decision making, and that's great.  But we are still
> pigeonholing the dimensions.
>
>
>
> I'm afraid the reality is that risk management will always be done
> locally.  And so it should be.  When an RP is making the decision to acce=
pt
> or reject a given subject, they will evaluate a range of attributes
> or signals.  The set of attributes that matters varies from one RP to the
> next.  I think it's a great idea indeed to create guidance for evaluating
> attributes, and to coach RPs to look at all sorts of dimensions.  I just
> don't think it helps anyone to pigeonhole the risk ratings, because acros=
s
> organisations, arguments about the boundaries between LOA 1/2/3/4 (that i=
s,
> policy mapping) will undo any efficiencies gained from the categorization=
.
>
>
>
> Cheers,
>
>
>
> Steve.
>
>
>
>
>
> Stephen Wilson
> Managing Director
> Lockstep Group
> http://lockstep.com.au
> Lockstep Consulting provides independent specialist advice and analysis
> on digital identity and privacy. Lockstep Technologies develops unique
> new smart ID solutions that enhance privacy and prevent identity theft.
>
>
>
>
>
>
>
> _______________________________________________
> vot mailing list
> vot@ietf.org 
> https://www.ietf.org/mailman/listinfo/vot
>
>
>
>
> _______________________________________________
> vot mailing list
> vot@ietf.org 
> https://www.ietf.org/mailman/listinfo/vot
>
>
>
>
>

--089e01536688a24b4105054b394f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Colin,
    See in line.
    

--089e01536688a24b4105054b394f--


From nobody Wed Oct 15 06:08:08 2014
Return-Path: 
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E9D71A1AAB for ; Wed, 15 Oct 2014 06:08:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.449
X-Spam-Level: *
X-Spam-Status: No, score=1.449 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1jMRR4BPrQtF for ; Wed, 15 Oct 2014 06:07:59 -0700 (PDT)
Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.29.23]) (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 BAD1F1A1A95 for ; Wed, 15 Oct 2014 06:07:57 -0700 (PDT)
Received: from [81.217.70.9] (helo=[192.168.1.33]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XeOJ1-00029A-Gu for vot@ietf.org; Wed, 15 Oct 2014 15:07:55 +0200
From: Rainer Hoerbe 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Message-Id: 
Date: Wed, 15 Oct 2014 15:07:54 +0200
To: vot@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
X-Df-Sender: cmhAaWRlbnRpbmV0aWNzLmNvbQ==
Archived-At: http://mailarchive.ietf.org/arch/msg/vot/caMBXl063TBhCqn7VYKeBTR2VBk
Subject: [VoT] =?windows-1252?q?VoT_=96_Strawman_B?=
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Vectors of Trust discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 13:08:02 -0000

So far some respondees questioned the viability of a model with =
orthogonal vectors in principle. To integrate ideas from Justin=92 =
document with those thoughts I am proposing an alternative VoT strawman, =
which can be developed and discussed in parallel.
To keep things simple I am delineating a contrasting approach =96 later =
mergers and confluences are possible and wanted.
=20
First thing to note is that I am missing a write-up of the Terms of =
Reference for VoT. Taking statements from the workshop notes and the =
preceeding contributions on the list I think that the ToR would contain =
this:
1) Federation should extend trust beyond the local jurisdiction or =
community
2) Assurance using LoA (for entity authentication assurance) is =
operational in some pretty large federations, but rare to be common =
accross the boundaries mentioned in (1)
3) At the same time the perception is that LoA does not accommodate =
=84cross border/sector federation=93 because RPs require different =
controls.
4) Related topics need to be solved as well, such as common terminology =
and attribute assurance.
=20
So what vectors should we have? Instead of refining the LoA definition =
in 800-63 VoT shall have only 2 vectors:
a) Liability
b) LoA
=20
a) Trust because of liability
Liability has to be defined on a contractual base for a service that the =
RP has with an IDP (or however represents a federation). In practical =
terms such a contract could look like this:
=84RP buys 100,000 assertions for 0,10=80/transaction with a liability =
limit of 50=80 per assertion. Each assertion shall assure that whoever =
can proof to own the authentication factor(s) will be issued with the =
registered attributes of a targeted identifier, first and last name, =
gender and DoB=93.
There might be liability limitations, such as gross negligence by the =
end-user or non-fatal spelling errors in attributes, but in principle =
the IDP should take the complete risk of identifying the user to the RP.
=20
The idea behind this scheme is twofold: (i) The IDP has skin in the =
game, and will optimize rules and procedures to match liability =
requirements. E.g., if document fraud would suddenly rise significantly, =
better training for ROs or additional background checks could be =
deployed quickly and on a flexible basis, i.e. without a slow agreement =
processes. (ii) Liability amounts are very easy to communicate, and do =
not suffer from the unorthogonality of a bag of controls. I think that =
money is a truly linear scale.
=20
IDPs can base a business model on liability. At the basic level, there =
is no liability, only reputation, as it is practice in the R&E =
federations. At higher levels RPs can negotiate how much risk they need =
to transfer.
If the RP=92s asset at risk has a value of 1m=80, the RP might require a =
liability of 10k=80 and keep 990k=80 as residual risk, considering that =
10k=80 liabilty per transaction will motivate the IDP=92s liability =
insurance to require proper controls.
=20
b) LoA for legally required controls
A RP cannot translate mandatory controls into a monetary risk. E.g. =
Anti-Money-Laundering rules require payment providers to enforce certain =
KYC rules. Or some jurisdictions require a car rental service to give a =
car only to persons with a valid driving license. Therefore IDPs must =
follow certain vetting procedures or other controls.
=20
This kind of LoA might have a similar granularity as ISO29115 or 800-63. =
It could consist of conformance requirements by broadly available =
security regimes, such as ECB Payment Service Directive, eIDAS/high or =
800-63.
=20
It might turn out that RPs have quite different policy requirements. In =
this case the complexity of policy negotiation could be significantly =
reduced by having trust in the liabilty regime. In addition only a =
minimal set of mandatory controls needs to be imposed in the IDP.
=20
=20
Issues to be discussed:
-       Is certification better than liability?
-       How would organizations be handled who are authoritative, but =
reject to take any liabilty identification or attributes? (Like =
goverment bodies, doctor=92s professional organizations, chambers of =
commerces)

Regards, Rainer=


From nobody Wed Oct 15 12:10:48 2014
Return-Path: 
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 054411A9167 for ; Wed, 15 Oct 2014 12:10:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.722
X-Spam-Level: 
X-Spam-Status: No, score=0.722 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-TH_xjLrRoF for ; Wed, 15 Oct 2014 12:10:43 -0700 (PDT)
Received: from mail-ob0-f174.google.com (mail-ob0-f174.google.com [209.85.214.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46D5E1A6F99 for ; Wed, 15 Oct 2014 12:10:43 -0700 (PDT)
Received: by mail-ob0-f174.google.com with SMTP id wp18so1597690obc.19 for ; Wed, 15 Oct 2014 12:10:42 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=wFR/lEapvpnHA7A9tPUQ9utPLLYUzUK9gaOwXFytZ+k=; b=ipcXpPVOqkHj6onjyO0W0n3mNAXDy1+NIvQEhDt9cAj2DVGobKQGGqnWmjY5jyU7Mp V7gVGtkauR708uguahUxC+kidpXDo05c1ek7aUv2Rbr6ej7z0pjLpbT3V6Ik/q85se1b NUc4Osdor2+eVyEUtO1WHpDrhq9qmW7YiVbe4lG30zeZnfzvBCF8mjvqQ0CvAVytRqqe TOdbS2nlH3mHGFqdjNlR/tgbC2asN1hrc+PluIn8o6iPSxbCR8/F2AR2jwA9uekagGD3 Ac8zruD/iKjYnc5FTXbLrloK1PzYJDLjNMRJqOxq7SMTX4gRwoGHWYO+WlfTXfMGO0SP Gb3w==
X-Gm-Message-State: ALoCoQnzDG5T4wUsfDW3mecQY/24IqhC2tomog7b2pd3BARnYIzjWNngCC0ueOlHJz5+xeclR3vR
MIME-Version: 1.0
X-Received: by 10.202.102.162 with SMTP id m34mr11933188oik.37.1413400242631;  Wed, 15 Oct 2014 12:10:42 -0700 (PDT)
Received: by 10.202.5.132 with HTTP; Wed, 15 Oct 2014 12:10:42 -0700 (PDT)
In-Reply-To: 
References: 
Date: Wed, 15 Oct 2014 15:10:42 -0400
Message-ID: 
From: Peter Alterman 
To: vot@ietf.org
Content-Type: multipart/alternative; boundary=001a1140a9be63778c05057ae334
Archived-At: http://mailarchive.ietf.org/arch/msg/vot/Pd8bceA_Tw6Hv60e0oRQx7KYsaA
Subject: Re: [VoT] vot Digest, Vol 2, Issue 20
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Vectors of Trust discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Oct 2014 19:10:47 -0000

--001a1140a9be63778c05057ae334
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hello, folks.

eIDAS high is QCP, e.g., PKI comparable to somewhere between FBCA Basic and
FBCA Medium (last time I looked).

Another point that's been sticking in my mind: token/credential strength
must must must include the policies and practices around management of
same. It's not just the binding of the identity proofing outcome.

Every single process for assigning trustworthiness (rat hole alert) is
based on a risk/mitigation determination, both on the issuance/management
side and on the authentication/consumption side, so between 29115 and
800-53 there is a basal affinity and each promotes a path towards
quantifying risk and mitigation.If vot were to focus on teasing out the
terms of that affinity and standardize agreement on same, that would be a
major accomplishment.  Looked at this way, liability is simply another risk
mitigation strategy, albeit a fairly complex, non-technical one.

Peter

------------------------------------------------------------
Peter Alterman, Ph.D.
Chief Operating Officer
SAFE-BioPharma Association
cell: 301-943-7452


On Wed, Oct 15, 2014 at 3:01 PM,  wrote:

> Send vot mailing list submissions to
>         vot@ietf.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www.ietf.org/mailman/listinfo/vot
> or, via email, send a message with subject or body 'help' to
>         vot-request@ietf.org
>
> You can reach the person managing the list at
>         vot-owner@ietf.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of vot digest..."
>
> Today's Topics:
>
>    1. VoT ? Strawman B (Rainer Hoerbe)
>
>
> ---------- Forwarded message ----------
> From: Rainer Hoerbe 
> To: vot@ietf.org
> Cc:
> Date: Wed, 15 Oct 2014 15:07:54 +0200
> Subject: [VoT] VoT =E2=80=93 Strawman B
> So far some respondees questioned the viability of a model with orthogona=
l
> vectors in principle. To integrate ideas from Justin=E2=80=99 document wi=
th those
> thoughts I am proposing an alternative VoT strawman, which can be develop=
ed
> and discussed in parallel.
> To keep things simple I am delineating a contrasting approach =E2=80=93 l=
ater
> mergers and confluences are possible and wanted.
>
> First thing to note is that I am missing a write-up of the Terms of
> Reference for VoT. Taking statements from the workshop notes and the
> preceeding contributions on the list I think that the ToR would contain
> this:
> 1) Federation should extend trust beyond the local jurisdiction or
> community
> 2) Assurance using LoA (for entity authentication assurance) is
> operational in some pretty large federations, but rare to be common accro=
ss
> the boundaries mentioned in (1)
> 3) At the same time the perception is that LoA does not accommodate =E2=
=80=9Ecross
> border/sector federation=E2=80=9C because RPs require different controls.
> 4) Related topics need to be solved as well, such as common terminology
> and attribute assurance.
>
> So what vectors should we have? Instead of refining the LoA definition in
> 800-63 VoT shall have only 2 vectors:
> a) Liability
> b) LoA
>
> a) Trust because of liability
> Liability has to be defined on a contractual base for a service that the
> RP has with an IDP (or however represents a federation). In practical ter=
ms
> such a contract could look like this:
> =E2=80=9ERP buys 100,000 assertions for 0,10=E2=82=AC/transaction with a =
liability limit
> of 50=E2=82=AC per assertion. Each assertion shall assure that whoever ca=
n proof to
> own the authentication factor(s) will be issued with the registered
> attributes of a targeted identifier, first and last name, gender and DoB=
=E2=80=9C.
> There might be liability limitations, such as gross negligence by the
> end-user or non-fatal spelling errors in attributes, but in principle the
> IDP should take the complete risk of identifying the user to the RP.
>
> The idea behind this scheme is twofold: (i) The IDP has skin in the game,
> and will optimize rules and procedures to match liability requirements.
> E.g., if document fraud would suddenly rise significantly, better trainin=
g
> for ROs or additional background checks could be deployed quickly and on =
a
> flexible basis, i.e. without a slow agreement processes. (ii) Liability
> amounts are very easy to communicate, and do not suffer from the
> unorthogonality of a bag of controls. I think that money is a truly linea=
r
> scale.
>
> IDPs can base a business model on liability. At the basic level, there is
> no liability, only reputation, as it is practice in the R&E federations. =
At
> higher levels RPs can negotiate how much risk they need to transfer.
> If the RP=E2=80=99s asset at risk has a value of 1m=E2=82=AC, the RP migh=
t require a
> liability of 10k=E2=82=AC and keep 990k=E2=82=AC as residual risk, consid=
ering that 10k=E2=82=AC
> liabilty per transaction will motivate the IDP=E2=80=99s liability insura=
nce to
> require proper controls.
>
> b) LoA for legally required controls
> A RP cannot translate mandatory controls into a monetary risk. E.g.
> Anti-Money-Laundering rules require payment providers to enforce certain
> KYC rules. Or some jurisdictions require a car rental service to give a c=
ar
> only to persons with a valid driving license. Therefore IDPs must follow
> certain vetting procedures or other controls.
>
> This kind of LoA might have a similar granularity as ISO29115 or 800-63.
> It could consist of conformance requirements by broadly available securit=
y
> regimes, such as ECB Payment Service Directive, eIDAS/high or 800-63.
>
> It might turn out that RPs have quite different policy requirements. In
> this case the complexity of policy negotiation could be significantly
> reduced by having trust in the liabilty regime. In addition only a minima=
l
> set of mandatory controls needs to be imposed in the IDP.
>
>
> Issues to be discussed:
> -       Is certification better than liability?
> -       How would organizations be handled who are authoritative, but
> reject to take any liabilty identification or attributes? (Like goverment
> bodies, doctor=E2=80=99s professional organizations, chambers of commerce=
s)
>
> Regards, Rainer
>
>
> _______________________________________________
> vot mailing list
> vot@ietf.org
> https://www.ietf.org/mailman/listinfo/vot
>
>

--001a1140a9be63778c05057ae334
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


    He=
llo, folks.
    eIDAS high =
is QCP, e.g., PKI comparable to somewhere between FBCA Basic and FBCA Mediu=
m (last time I looked).

    Another point that's been sticking in my mind: token/credential streng=
th must must must include the policies and practices around management of s=
ame. It's not just the binding of the identity proofing outcome.=C2=A0<=
/div>

    Every single process fo=
r assigning trustworthiness (rat hole alert) is based on a risk/mitigation =
determination, both on the issuance/management side and on the authenticati=
on/consumption side, so between 29115 and 800-53 there is a basal affinity =
and each promotes a path towards quantifying risk and mitigation.If vot wer=
e to focus on teasing out the terms of that affinity and standardize agreem=
ent on same, that would be a major accomplishment.=C2=A0=C2=A0Looked at thi=
s way, liability is simply another risk mitigation strategy, albeit a fairl=
y complex, non-technical one.=C2=A0

    Peter

    =

    --------------------------------------=
----------------------
    Peter Alterman, Ph.D.
    Chief Operat=
ing Officer
    SAFE-BioPharma Association
    cell: 301-943-7452
    

    On Wed, Oct 15, 2014 at 3:01 PM,  <vot-=
request@ietf.org> wrote:
    Se=
nd vot mailing list submissions to
    
=C2=A0 =C2=A0 =C2=A0 =C2=A0 vot@ietf.org
    

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

    
You can reach the person managing the list at
    
=C2=A0 =C2=A0 =C2=A0 =C2=A0 vot-owner=
@ietf.org
    

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

    Today's Topics:
    

    
=C2=A0 =C2=A01. VoT ? Strawman B (Rainer Hoerbe)
    


    ---------- Forwarded message ----------
    From:=C2=A0Rainer Hoerbe=
 <rainer@hoerbe.at>
    To:=C2=
=A0vot@ietf.org
    Cc:=C2=A0
    Date:=
=C2=A0Wed, 15 Oct 2014 15:07:54 +0200
    Subject:=C2=A0[VoT] VoT =E2=80=93 =
Strawman B
    So far some respondees questioned the viability of a model wi=
th orthogonal vectors in principle. To integrate ideas from Justin=E2=80=99=
 document with those thoughts I am proposing an alternative VoT strawman, w=
hich can be developed and discussed in parallel.
    
To keep things simple I am delineating a contrasting approach =E2=80=93 lat=
er mergers and confluences are possible and wanted.
    

    
First thing to note is that I am missing a write-up of the Terms of Referen=
ce for VoT. Taking statements from the workshop notes and the preceeding co=
ntributions on the list I think that the ToR would contain this:
    
1) Federation should extend trust beyond the local jurisdiction or communit=
y
    
2) Assurance using LoA (for entity authentication assurance) is operational=
 in some pretty large federations, but rare to be common accross the bounda=
ries mentioned in (1)
    
3) At the same time the perception is that LoA does not accommodate =E2=80=
=9Ecross border/sector federation=E2=80=9C because RPs require different co=
ntrols.
    
4) Related topics need to be solved as well, such as common terminology and=
 attribute assurance.
    

    
So what vectors should we have? Instead of refining the LoA definition in 8=
00-63 VoT shall have only 2 vectors:
    
a) Liability
    
b) LoA
    

    
a) Trust because of liability
    
Liability has to be defined on a contractual base for a service that the RP=
 has with an IDP (or however represents a federation). In practical terms s=
uch a contract could look like this:
    
=E2=80=9ERP buys 100,000 assertions for 0,10=E2=82=AC/transaction with a li=
ability limit of 50=E2=82=AC per assertion. Each assertion shall assure tha=
t whoever can proof to own the authentication factor(s) will be issued with=
 the registered attributes of a targeted identifier, first and last name, g=
ender and DoB=E2=80=9C.
    
There might be liability limitations, such as gross negligence by the end-u=
ser or non-fatal spelling errors in attributes, but in principle the IDP sh=
ould take the complete risk of identifying the user to the RP.
    

    
The idea behind this scheme is twofold: (i) The IDP has skin in the game, a=
nd will optimize rules and procedures to match liability requirements. E.g.=
, if document fraud would suddenly rise significantly, better training for =
ROs or additional background checks could be deployed quickly and on a flex=
ible basis, i.e. without a slow agreement processes. (ii) Liability amounts=
 are very easy to communicate, and do not suffer from the unorthogonality o=
f a bag of controls. I think that money is a truly linear scale.
    

    
IDPs can base a business model on liability. At the basic level, there is n=
o liability, only reputation, as it is practice in the R&E federations.=
 At higher levels RPs can negotiate how much risk they need to transfer.
If the RP=E2=80=99s asset at risk has a value of 1m=E2=82=AC, the RP might =
require a liability of 10k=E2=82=AC and keep 990k=E2=82=AC as residual risk=
, considering that 10k=E2=82=AC liabilty per transaction will motivate the =
IDP=E2=80=99s liability insurance to require proper controls.
    

    
b) LoA for legally required controls
    
A RP cannot translate mandatory controls into a monetary risk. E.g. Anti-Mo=
ney-Laundering rules require payment providers to enforce certain KYC rules=
. Or some jurisdictions require a car rental service to give a car only to =
persons with a valid driving license. Therefore IDPs must follow certain ve=
tting procedures or other controls.
    

    
This kind of LoA might have a similar granularity as ISO29115 or 800-63. It=
 could consist of conformance requirements by broadly available security re=
gimes, such as ECB Payment Service Directive, eIDAS/high or 800-63.
    

    
It might turn out that RPs have quite different policy requirements. In thi=
s case the complexity of policy negotiation could be significantly reduced =
by having trust in the liabilty regime. In addition only a minimal set of m=
andatory controls needs to be imposed in the IDP.
    

    

    
Issues to be discussed:
    
-=C2=A0 =C2=A0 =C2=A0 =C2=A0Is certification better than liability?
    
-=C2=A0 =C2=A0 =C2=A0 =C2=A0How would organizations be handled who are auth=
oritative, but reject to take any liabilty identification or attributes? (L=
ike goverment bodies, doctor=E2=80=99s professional organizations, chambers=
 of commerces)
    

    
Regards, Rainer
    

    

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


    

--001a1140a9be63778c05057ae334--


From nobody Thu Oct 16 05:40:39 2014
Return-Path: 
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFED51A1AA6 for ; Thu, 16 Oct 2014 05:40:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.611
X-Spam-Level: 
X-Spam-Status: No, score=-1.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8vsU5gvUBjqM for ; Thu, 16 Oct 2014 05:40:35 -0700 (PDT)
Received: from smtp1.csc.fi (smtp1.csc.fi [IPv6:2001:708:10:6004::14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4FCF1A0360 for ; Thu, 16 Oct 2014 05:40:34 -0700 (PDT)
Received: from tapir.csc.fi (tapir.csc.fi [86.50.27.201]) by smtp1.csc.fi (8.14.3/8.14.3/CSC) with ESMTP id s9GCeUmr010520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Oct 2014 15:40:30 +0300
Received: from tapir.csc.fi (localhost [127.0.0.1]) by tapir.csc.fi (Postfix) with ESMTPS id 0C8A2BFA24; Thu, 16 Oct 2014 15:40:30 +0300 (EEST)
Received: from localhost (localhost [127.0.0.1]) by tapir.csc.fi (Postfix) with ESMTP id F36EEBFA23; Thu, 16 Oct 2014 15:40:29 +0300 (EEST)
Received: from tapir.csc.fi ([127.0.0.1]) by localhost (tapir.csc.fi [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id cAevZObRcZUj; Thu, 16 Oct 2014 15:40:29 +0300 (EEST)
Received: from zebra.csc.fi (zebra.csc.fi [86.50.27.101]) by tapir.csc.fi (Postfix) with ESMTP id DE6DFBFA22; Thu, 16 Oct 2014 15:40:29 +0300 (EEST)
From: Mikael Linden 
To: "Rainer Hoerbe" , 
References: 
In-Reply-To: 
Date: Thu, 16 Oct 2014 15:40:29 +0300 (EEST)
Message-ID: <5a7fe797.00001160.00000010@MLINDEN-X220.windows.csc.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
X-Mailer: Microsoft Outlook 15.0
X-Mailer: Zimbra 8.5.0_GA_3047 (ZimbraConnectorForOutlook/8.0.6.1063)
Thread-Index: xYMU5zEHw3HGDgqOMtYn4+wEUnH0FQ==
Content-Language: fi
X-Originating-IP: [193.166.16.221]
Thread-Topic: VoT =?utf-8?Q?=E2=80=93_Strawman?= B
Content-Transfer-Encoding: quoted-printable
X-CanIt-Geo: ip=86.50.27.201; country=FI; latitude=64.0000; longitude=26.0000;  http://maps.google.com/maps?q=64.0000,26.0000&z=6
X-CanItPRO-Stream: 00_Opt_Out (inherits from default)
X-Scanned-By: CanIt (www . roaringpenguin . com) on 86.50.27.145
Archived-At: http://mailarchive.ietf.org/arch/msg/vot/-_pqdDylINKrzhreLERDRFOvbvM
Subject: Re: [VoT] =?utf-8?q?VoT_=E2=80=93_Strawman_B?=
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Vectors of Trust discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Oct 2014 12:40:38 -0000

Hi,
I'm afraid there is a cultural difference here between the non-profit=20
Research&Education federations and the commercial federations/IdPs.=20
Liability is the commercial world's approach to trust metrics. Universiti=
es=20
become IdPs to enable their employees/students to do their job/studies mo=
re=20
easily. Becoming liable for it may make the universities to withdraw from=
=20
their role as an IdP.

The R&E federation policies that I know exclude liabilities to the extent=
=20
possible. In general, liability is not seen as an LoA issue in R&E=20
federations.

Cheers,
mikael

-----Original Message-----
From: vot [mailto:vot-bounces@ietf.org] On Behalf Of Rainer Hoerbe
Sent: 15. lokakuuta 2014 16:08
To: vot@ietf.org
Subject: [VoT] VoT =E2=80=93 Strawman B

So far some respondees questioned the viability of a model with orthogona=
l=20
vectors in principle. To integrate ideas from Justin=E2=80=99 document wi=
th those=20
thoughts I am proposing an alternative VoT strawman, which can be develop=
ed=20
and discussed in parallel.
To keep things simple I am delineating a contrasting approach =E2=80=93 l=
ater=20
mergers and confluences are possible and wanted.

First thing to note is that I am missing a write-up of the Terms of=20
Reference for VoT. Taking statements from the workshop notes and the=20
preceeding contributions on the list I think that the ToR would contain=20
this:
1) Federation should extend trust beyond the local jurisdiction or commun=
ity
2) Assurance using LoA (for entity authentication assurance) is operation=
al=20
in some pretty large federations, but rare to be common accross the=20
boundaries mentioned in (1)
3) At the same time the perception is that LoA does not accommodate =E2=80=
=9Ecross=20
border/sector federation=E2=80=9C because RPs require different controls.
4) Related topics need to be solved as well, such as common terminology a=
nd=20
attribute assurance.

So what vectors should we have? Instead of refining the LoA definition in=
=20
800-63 VoT shall have only 2 vectors:
a) Liability
b) LoA

a) Trust because of liability
Liability has to be defined on a contractual base for a service that the =
RP=20
has with an IDP (or however represents a federation). In practical terms=20
such a contract could look like this:
=E2=80=9ERP buys 100,000 assertions for 0,10=E2=82=AC/transaction with a =
liability limit of=20
50=E2=82=AC per assertion. Each assertion shall assure that whoever can p=
roof to own=20
the authentication factor(s) will be issued with the registered attribute=
s=20
of a targeted identifier, first and last name, gender and DoB=E2=80=9C.
There might be liability limitations, such as gross negligence by the=20
end-user or non-fatal spelling errors in attributes, but in principle the=
=20
IDP should take the complete risk of identifying the user to the RP.

The idea behind this scheme is twofold: (i) The IDP has skin in the game,=
=20
and will optimize rules and procedures to match liability requirements.=20
E.g., if document fraud would suddenly rise significantly, better trainin=
g=20
for ROs or additional background checks could be deployed quickly and on =
a=20
flexible basis, i.e. without a slow agreement processes. (ii) Liability=20
amounts are very easy to communicate, and do not suffer from the=20
unorthogonality of a bag of controls. I think that money is a truly linea=
r=20
scale.

IDPs can base a business model on liability. At the basic level, there is=
 no=20
liability, only reputation, as it is practice in the R&E federations. At=20
higher levels RPs can negotiate how much risk they need to transfer.
If the RP=E2=80=99s asset at risk has a value of 1m=E2=82=AC, the RP migh=
t require a=20
liability of 10k=E2=82=AC and keep 990k=E2=82=AC as residual risk, consid=
ering that 10k=E2=82=AC=20
liabilty per transaction will motivate the IDP=E2=80=99s liability insura=
nce to=20
require proper controls.

b) LoA for legally required controls
A RP cannot translate mandatory controls into a monetary risk. E.g.=20
Anti-Money-Laundering rules require payment providers to enforce certain =
KYC=20
rules. Or some jurisdictions require a car rental service to give a car o=
nly=20
to persons with a valid driving license. Therefore IDPs must follow certa=
in=20
vetting procedures or other controls.

This kind of LoA might have a similar granularity as ISO29115 or 800-63. =
It=20
could consist of conformance requirements by broadly available security=20
regimes, such as ECB Payment Service Directive, eIDAS/high or 800-63.

It might turn out that RPs have quite different policy requirements. In t=
his=20
case the complexity of policy negotiation could be significantly reduced =
by=20
having trust in the liabilty regime. In addition only a minimal set of=20
mandatory controls needs to be imposed in the IDP.


Issues to be discussed:
-       Is certification better than liability?
-       How would organizations be handled who are authoritative, but rej=
ect=20
to take any liabilty identification or attributes? (Like goverment bodies=
,=20
doctor=E2=80=99s professional organizations, chambers of commerces)

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


From nobody Thu Oct 16 07:14:33 2014
Return-Path: 
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 423241A1A52 for ; Thu, 16 Oct 2014 07:14:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.251
X-Spam-Level: 
X-Spam-Status: No, score=-1.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02yKyiHqQClc for ; Thu, 16 Oct 2014 07:14:23 -0700 (PDT)
Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.94]) (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 0DAA21A1A6C for ; Thu, 16 Oct 2014 07:14:22 -0700 (PDT)
Received: from [81.217.70.9] (helo=[192.168.1.33]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1Xeloq-0005iT-JM; Thu, 16 Oct 2014 16:14:20 +0200
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Rainer Hoerbe 
In-Reply-To: <5a7fe797.00001160.00000010@MLINDEN-X220.windows.csc.fi>
Date: Thu, 16 Oct 2014 16:14:18 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <8A3D22DF-C795-41DB-8505-6334E5CC80E4@hoerbe.at>
References:  <5a7fe797.00001160.00000010@MLINDEN-X220.windows.csc.fi>
To: Mikael Linden 
X-Mailer: Apple Mail (2.1878.6)
X-Df-Sender: cmhAaWRlbnRpbmV0aWNzLmNvbQ==
Archived-At: http://mailarchive.ietf.org/arch/msg/vot/UAq5H6Ng8qovLmXcT4Jch33giNk
Cc: vot@ietf.org
Subject: Re: [VoT] =?windows-1252?q?VoT_=96_Strawman_B?=
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Vectors of Trust discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Oct 2014 14:14:30 -0000

Hi Mikael,

I do not see a conflict there, liability =3D 0=80 ist just the lowest =
level of the scale, where only reputation is left to underpin trust. I =
think that I took care of this with the phrase "At the basic level, =
there is no liability, only reputation, as it is practice in the R&E =
federations".

Cheers, Rainer


Am 16.10.2014 um 14:40 schrieb Mikael Linden :

> Hi,
> I'm afraid there is a cultural difference here between the non-profit=20=

> Research&Education federations and the commercial federations/IdPs.=20
> Liability is the commercial world's approach to trust metrics. =
Universities=20
> become IdPs to enable their employees/students to do their job/studies =
more=20
> easily. Becoming liable for it may make the universities to withdraw =
from=20
> their role as an IdP.
>=20
> The R&E federation policies that I know exclude liabilities to the =
extent=20
> possible. In general, liability is not seen as an LoA issue in R&E=20
> federations.
>=20
> Cheers,
> mikael
>=20
> -----Original Message-----
> From: vot [mailto:vot-bounces@ietf.org] On Behalf Of Rainer Hoerbe
> Sent: 15. lokakuuta 2014 16:08
> To: vot@ietf.org
> Subject: [VoT] VoT =96 Strawman B
>=20
> So far some respondees questioned the viability of a model with =
orthogonal=20
> vectors in principle. To integrate ideas from Justin=92 document with =
those=20
> thoughts I am proposing an alternative VoT strawman, which can be =
developed=20
> and discussed in parallel.
> To keep things simple I am delineating a contrasting approach =96 =
later=20
> mergers and confluences are possible and wanted.
>=20
> First thing to note is that I am missing a write-up of the Terms of=20
> Reference for VoT. Taking statements from the workshop notes and the=20=

> preceeding contributions on the list I think that the ToR would =
contain=20
> this:
> 1) Federation should extend trust beyond the local jurisdiction or =
community
> 2) Assurance using LoA (for entity authentication assurance) is =
operational=20
> in some pretty large federations, but rare to be common accross the=20
> boundaries mentioned in (1)
> 3) At the same time the perception is that LoA does not accommodate =
=84cross=20
> border/sector federation=93 because RPs require different controls.
> 4) Related topics need to be solved as well, such as common =
terminology and=20
> attribute assurance.
>=20
> So what vectors should we have? Instead of refining the LoA definition =
in=20
> 800-63 VoT shall have only 2 vectors:
> a) Liability
> b) LoA
>=20
> a) Trust because of liability
> Liability has to be defined on a contractual base for a service that =
the RP=20
> has with an IDP (or however represents a federation). In practical =
terms=20
> such a contract could look like this:
> =84RP buys 100,000 assertions for 0,10=80/transaction with a liability =
limit of=20
> 50=80 per assertion. Each assertion shall assure that whoever can =
proof to own=20
> the authentication factor(s) will be issued with the registered =
attributes=20
> of a targeted identifier, first and last name, gender and DoB=93.
> There might be liability limitations, such as gross negligence by the=20=

> end-user or non-fatal spelling errors in attributes, but in principle =
the=20
> IDP should take the complete risk of identifying the user to the RP.
>=20
> The idea behind this scheme is twofold: (i) The IDP has skin in the =
game,=20
> and will optimize rules and procedures to match liability =
requirements.=20
> E.g., if document fraud would suddenly rise significantly, better =
training=20
> for ROs or additional background checks could be deployed quickly and =
on a=20
> flexible basis, i.e. without a slow agreement processes. (ii) =
Liability=20
> amounts are very easy to communicate, and do not suffer from the=20
> unorthogonality of a bag of controls. I think that money is a truly =
linear=20
> scale.
>=20
> IDPs can base a business model on liability. At the basic level, there =
is no=20
> liability, only reputation, as it is practice in the R&E federations. =
At=20
> higher levels RPs can negotiate how much risk they need to transfer.
> If the RP=92s asset at risk has a value of 1m=80, the RP might require =
a=20
> liability of 10k=80 and keep 990k=80 as residual risk, considering =
that 10k=80=20
> liabilty per transaction will motivate the IDP=92s liability insurance =
to=20
> require proper controls.
>=20
> b) LoA for legally required controls
> A RP cannot translate mandatory controls into a monetary risk. E.g.=20
> Anti-Money-Laundering rules require payment providers to enforce =
certain KYC=20
> rules. Or some jurisdictions require a car rental service to give a =
car only=20
> to persons with a valid driving license. Therefore IDPs must follow =
certain=20
> vetting procedures or other controls.
>=20
> This kind of LoA might have a similar granularity as ISO29115 or =
800-63. It=20
> could consist of conformance requirements by broadly available =
security=20
> regimes, such as ECB Payment Service Directive, eIDAS/high or 800-63.
>=20
> It might turn out that RPs have quite different policy requirements. =
In this=20
> case the complexity of policy negotiation could be significantly =
reduced by=20
> having trust in the liabilty regime. In addition only a minimal set of=20=

> mandatory controls needs to be imposed in the IDP.
>=20
>=20
> Issues to be discussed:
> -       Is certification better than liability?
> -       How would organizations be handled who are authoritative, but =
reject=20
> to take any liabilty identification or attributes? (Like goverment =
bodies,=20
> doctor=92s professional organizations, chambers of commerces)
>=20
> Regards, Rainer
> _______________________________________________
> vot mailing list
> vot@ietf.org
> https://www.ietf.org/mailman/listinfo/vot


From nobody Thu Oct 16 09:40:24 2014
Return-Path: 
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A08131A004B for ; Thu, 16 Oct 2014 09:40:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.55
X-Spam-Level: 
X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NVsd7Hkg0HeU for ; Thu, 16 Oct 2014 09:40:17 -0700 (PDT)
Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.42]) (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 226E21A004C for ; Thu, 16 Oct 2014 09:40:16 -0700 (PDT)
Received: from [81.217.70.9] (helo=[192.168.1.33]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1Xeo62-0001Nv-Qo; Thu, 16 Oct 2014 18:40:14 +0200
Content-Type: multipart/alternative; boundary="Apple-Mail=_E19CF6E1-AE54-4BAF-83C7-A0B422A1F605"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Rainer Hoerbe 
In-Reply-To: <47EE3523-2DAD-4070-B169-2DC99510C7F4@identinetics.com>
Date: Thu, 16 Oct 2014 18:40:13 +0200
Message-Id: 
References:   <47EE3523-2DAD-4070-B169-2DC99510C7F4@identinetics.com>
To: Peter Alterman 
X-Mailer: Apple Mail (2.1878.6)
X-Df-Sender: cmhAaWRlbnRpbmV0aWNzLmNvbQ==
Archived-At: http://mailarchive.ietf.org/arch/msg/vot/pHn2Ut_yeKFKXsMcnwQrgEVxmvk
Cc: vot@ietf.org
Subject: Re: [VoT] vot Digest, Vol 2, Issue 20
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Vectors of Trust discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Oct 2014 16:40:20 -0000

--Apple-Mail=_E19CF6E1-AE54-4BAF-83C7-A0B422A1F605
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Am 15.10.2014 um 21:10 schrieb Peter Alterman =
:

> Hello, folks.
>=20
> Every single process for assigning trustworthiness (rat hole alert) is =
based on a risk/mitigation determination,
Yes, trust is just a floppy word for risk management in this context. =
That should go into the ToR.

> both on the issuance/management side and on the =
authentication/consumption side, so between 29115 and 800-53 there is a =
basal affinity and each promotes a path towards quantifying risk and =
mitigation.If vot were to focus on teasing out the terms of that =
affinity and standardize agreement on same, that would be a major =
accomplishment.  Looked at this way, liability is simply another risk =
mitigation strategy, albeit a fairly complex, non-technical one.=20
Liability may be more complex than LoA or not, but it is a much simpler =
interface between IPD and RP, which is key to scalability.

Complexity is not the only problem. LoA policy adoption is a slow =
multi-stakeholder process, but threats appear fast. Also there is very =
little data to justify particular controls, because breach notification =
is hard to do outside organizations.

- Rainer

>=20
> Peter
>=20
>=20
> ---------- Forwarded message ----------
> From: Rainer Hoerbe 
> To: vot@ietf.org
> Cc:=20
> Date: Wed, 15 Oct 2014 15:07:54 +0200
> Subject: [VoT] VoT =96 Strawman B
> So far some respondees questioned the viability of a model with =
orthogonal vectors in principle. To integrate ideas from Justin=92 =
document with those thoughts I am proposing an alternative VoT strawman, =
which can be developed and discussed in parallel.
> To keep things simple I am delineating a contrasting approach =96 =
later mergers and confluences are possible and wanted.
>=20
> First thing to note is that I am missing a write-up of the Terms of =
Reference for VoT. Taking statements from the workshop notes and the =
preceeding contributions on the list I think that the ToR would contain =
this:
> 1) Federation should extend trust beyond the local jurisdiction or =
community
> 2) Assurance using LoA (for entity authentication assurance) is =
operational in some pretty large federations, but rare to be common =
accross the boundaries mentioned in (1)
> 3) At the same time the perception is that LoA does not accommodate =
=84cross border/sector federation=93 because RPs require different =
controls.
> 4) Related topics need to be solved as well, such as common =
terminology and attribute assurance.
>=20
> So what vectors should we have? Instead of refining the LoA definition =
in 800-63 VoT shall have only 2 vectors:
> a) Liability
> b) LoA
>=20
> a) Trust because of liability
> Liability has to be defined on a contractual base for a service that =
the RP has with an IDP (or however represents a federation). In =
practical terms such a contract could look like this:
> =84RP buys 100,000 assertions for 0,10=80/transaction with a liability =
limit of 50=80 per assertion. Each assertion shall assure that whoever =
can proof to own the authentication factor(s) will be issued with the =
registered attributes of a targeted identifier, first and last name, =
gender and DoB=93.
> There might be liability limitations, such as gross negligence by the =
end-user or non-fatal spelling errors in attributes, but in principle =
the IDP should take the complete risk of identifying the user to the RP.
>=20
> The idea behind this scheme is twofold: (i) The IDP has skin in the =
game, and will optimize rules and procedures to match liability =
requirements. E.g., if document fraud would suddenly rise significantly, =
better training for ROs or additional background checks could be =
deployed quickly and on a flexible basis, i.e. without a slow agreement =
processes. (ii) Liability amounts are very easy to communicate, and do =
not suffer from the unorthogonality of a bag of controls. I think that =
money is a truly linear scale.
>=20
> IDPs can base a business model on liability. At the basic level, there =
is no liability, only reputation, as it is practice in the R&E =
federations. At higher levels RPs can negotiate how much risk they need =
to transfer.
> If the RP=92s asset at risk has a value of 1m=80, the RP might require =
a liability of 10k=80 and keep 990k=80 as residual risk, considering =
that 10k=80 liabilty per transaction will motivate the IDP=92s liability =
insurance to require proper controls.
>=20
> b) LoA for legally required controls
> A RP cannot translate mandatory controls into a monetary risk. E.g. =
Anti-Money-Laundering rules require payment providers to enforce certain =
KYC rules. Or some jurisdictions require a car rental service to give a =
car only to persons with a valid driving license. Therefore IDPs must =
follow certain vetting procedures or other controls.
>=20
> This kind of LoA might have a similar granularity as ISO29115 or =
800-63. It could consist of conformance requirements by broadly =
available security regimes, such as ECB Payment Service Directive, =
eIDAS/high or 800-63.
>=20
> It might turn out that RPs have quite different policy requirements. =
In this case the complexity of policy negotiation could be significantly =
reduced by having trust in the liabilty regime. In addition only a =
minimal set of mandatory controls needs to be imposed in the IDP.
>=20
>=20
> Issues to be discussed:
> -       Is certification better than liability?
> -       How would organizations be handled who are authoritative, but =
reject to take any liabilty identification or attributes? (Like =
goverment bodies, doctor=92s professional organizations, chambers of =
commerces)
>=20
> Regards, Rainer
>=20
>=20
> _______________________________________________
> vot mailing list
> vot@ietf.org
> https://www.ietf.org/mailman/listinfo/vot
>=20
>=20
> _______________________________________________
> vot mailing list
> vot@ietf.org
> https://www.ietf.org/mailman/listinfo/vot



--Apple-Mail=_E19CF6E1-AE54-4BAF-83C7-A0B422A1F605
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252


    Am 15.10.2014 um 21:10 schrieb Peter Alterman =
<palterman@safe-biopharma.org<=
/a>>:

    both on the =
issuance/management side and on the authentication/consumption side, so =
between 29115 and 800-53 there is a basal affinity and each promotes a =
path towards quantifying risk and mitigation.If vot were to focus on =
teasing out the terms of that affinity and standardize agreement on =
same, that would be a major accomplishment.  Looked at this =
way, liability is simply another risk mitigation strategy, albeit a =
fairly complex, non-technical =
one. 
    Liability may be more complex =
than LoA or not, but it is a much simpler interface between IPD and RP, =
which is key to scalability.

    Complexity is not =
the only problem. LoA policy adoption is a slow multi-stakeholder =
process, but threats appear fast. Also there is very little data to =
justify particular controls, because breach notification is hard to do =
outside organizations.

    - =
Rainer


    Peter


    ---------- =
Forwarded message ----------
    From: Rainer Hoerbe <    rainer@hoerbe.at>
    To: vot@ietf.org
    Cc: 
    Date: W=
ed, 15 Oct 2014 15:07:54 +0200
    Subject: [VoT] VoT =96 Strawman =
B
    So far some respondees questioned the viability of a model with =
orthogonal vectors in principle. To integrate ideas from Justin=92 =
document with those thoughts I am proposing an alternative VoT strawman, =
which can be developed and discussed in parallel.
    
To keep things simple I am delineating a contrasting approach =96 later =
mergers and confluences are possible and wanted.
    

    
First thing to note is that I am missing a write-up of the Terms of =
Reference for VoT. Taking statements from the workshop notes and the =
preceeding contributions on the list I think that the ToR would contain =
this:
    
1) Federation should extend trust beyond the local jurisdiction or =
community
    
2) Assurance using LoA (for entity authentication assurance) is =
operational in some pretty large federations, but rare to be common =
accross the boundaries mentioned in (1)
    
3) At the same time the perception is that LoA does not accommodate =
=84cross border/sector federation=93 because RPs require different =
controls.
    
4) Related topics need to be solved as well, such as common terminology =
and attribute assurance.
    

    
So what vectors should we have? Instead of refining the LoA definition =
in 800-63 VoT shall have only 2 vectors:
    
a) Liability
    
b) LoA
    

    
a) Trust because of liability
    
Liability has to be defined on a contractual base for a service that the =
RP has with an IDP (or however represents a federation). In practical =
terms such a contract could look like this:
    
=84RP buys 100,000 assertions for 0,10=80/transaction with a liability =
limit of 50=80 per assertion. Each assertion shall assure that whoever =
can proof to own the authentication factor(s) will be issued with the =
registered attributes of a targeted identifier, first and last name, =
gender and DoB=93.
    
There might be liability limitations, such as gross negligence by the =
end-user or non-fatal spelling errors in attributes, but in principle =
the IDP should take the complete risk of identifying the user to the =
RP.
    

    
The idea behind this scheme is twofold: (i) The IDP has skin in the =
game, and will optimize rules and procedures to match liability =
requirements. E.g., if document fraud would suddenly rise significantly, =
better training for ROs or additional background checks could be =
deployed quickly and on a flexible basis, i.e. without a slow agreement =
processes. (ii) Liability amounts are very easy to communicate, and do =
not suffer from the unorthogonality of a bag of controls. I think that =
money is a truly linear scale.
    

    
IDPs can base a business model on liability. At the basic level, there =
is no liability, only reputation, as it is practice in the R&E =
federations. At higher levels RPs can negotiate how much risk they need =
to transfer.
    
If the RP=92s asset at risk has a value of 1m=80, the RP might require a =
liability of 10k=80 and keep 990k=80 as residual risk, considering that =
10k=80 liabilty per transaction will motivate the IDP=92s liability =
insurance to require proper controls.
    

    
b) LoA for legally required controls
    
A RP cannot translate mandatory controls into a monetary risk. E.g. =
Anti-Money-Laundering rules require payment providers to enforce certain =
KYC rules. Or some jurisdictions require a car rental service to give a =
car only to persons with a valid driving license. Therefore IDPs must =
follow certain vetting procedures or other controls.
    

    
This kind of LoA might have a similar granularity as ISO29115 or 800-63. =
It could consist of conformance requirements by broadly available =
security regimes, such as ECB Payment Service Directive, eIDAS/high or =
800-63.
    

    
It might turn out that RPs have quite different policy requirements. In =
this case the complexity of policy negotiation could be significantly =
reduced by having trust in the liabilty regime. In addition only a =
minimal set of mandatory controls needs to be imposed in the IDP.
    

    

    
Issues to be discussed:
    
-       Is certification better than liability?
    
-       How would organizations be handled who are =
authoritative, but reject to take any liabilty identification or =
attributes? (Like goverment bodies, doctor=92s professional =
organizations, chambers of commerces)
    

    
Regards, Rainer
    

    

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


    
_______________________________________________
    vot mailing =
list
    vot@ietf.org
    https://www.ietf.org/ma=
ilman/listinfo/vot


    =

--Apple-Mail=_E19CF6E1-AE54-4BAF-83C7-A0B422A1F605--


From nobody Sun Oct 19 11:03:03 2014
Return-Path: 
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7DD31A1A19 for ; Sun, 19 Oct 2014 11:03:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.699
X-Spam-Level: 
X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fa5s4DAeaUTN for ; Sun, 19 Oct 2014 11:02:56 -0700 (PDT)
Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25C431A1A15 for ; Sun, 19 Oct 2014 11:02:54 -0700 (PDT)
Received: by mail-la0-f50.google.com with SMTP id s18so2819221lam.23 for ; Sun, 19 Oct 2014 11:02:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=DMKvwxgBwVIwUzW42jB+JuTa7/A0vd1dM8fWV6vSV94=; b=br3969PAvyo6V81mi/hTQB+Mq5PIiotf67kd/h1HPh1iBby7tl9yvxwQYWaX/sm2UY ZTgjGSu6NO/2XXVyDoZjMfsc6j2HyrufHAK9QB3pw1HuWekIs4HrKQ3CpbBwMZGkCPIz aB5ACCE8eEpG8QEZKCdxF1CviiP68nqqhHvNPzHiQ3MNjGSM/geqvDYabTQaIifGQ0iw NSm4a0fCuOLG9ajHqKi3zST7HmYLPEvRriQ1TKqsTORXU+4XQfPsk4KmmPQUm3h0DI6E va1swkwdAAbxyCAmlOeNF4F/L/Mgh95FX9FXsfhFkkBNdmoKe3qYCB1B7gl5Wc008aa4 4TWw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=DMKvwxgBwVIwUzW42jB+JuTa7/A0vd1dM8fWV6vSV94=; b=iNxWgjhUXmnRyJh4we1TbEpXh2PWmtxOrYOI8bEepr6OB7XwM3+Q4V7FfNchyiDra4 fPbsTvaRms2O5hx4HwZdCQ2+kXpgIGJEOrzYSSUWrbijMPWeyyrNagMQv+tzKXg/myQb vCudTjqnAZNqaEhzCxPgEgtPRg/qbs9X3JCpqNYESY7XIMXtTkWBgLo9lBEYhxzwROA+ t/QmBA6MwOdPgV7nc0ZeDcK8wqj5+EcHdVjTyICG6jutExiTc5XFUfIVyzL+jURag3YS 06351j5o9UFSzg2tv/cId3FKZspCm8CoJnmMqncsJ4C6WNkSApNjDycUB856KKD/hqI1 0KXQ==
X-Received: by 10.112.210.102 with SMTP id mt6mr5407149lbc.73.1413741772815; Sun, 19 Oct 2014 11:02:52 -0700 (PDT)
Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com. [209.85.217.177]) by mx.google.com with ESMTPSA id z10sm2413310lbo.33.2014.10.19.11.02.51 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 19 Oct 2014 11:02:51 -0700 (PDT)
Received: by mail-lb0-f177.google.com with SMTP id w7so2730472lbi.8 for ; Sun, 19 Oct 2014 11:02:50 -0700 (PDT)
X-Gm-Message-State: ALoCoQn5KmcnzjVTMwIQ0c2gZ0IHkntIFyPFb+00VQ+AONVpVAXk7LS5QFz7/T/IDtU+tT+7PSrd
X-Received: by 10.112.94.133 with SMTP id dc5mr22339818lbb.11.1413741770638; Sun, 19 Oct 2014 11:02:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.134.6 with HTTP; Sun, 19 Oct 2014 11:02:10 -0700 (PDT)
In-Reply-To: 
References: <1412885935.58929166@apps.rackspace.com>  <20141010145142.51DBE1A90E3@ietfa.amsl.com> <6A0CFC85-F8F5-43F5-B02F-09720E7164F4@mitre.org> <147EE18440E5AF44834B220ED35BA530D32F0A2E@WLGPRDMBX01.dia.govt.nz>    <147EE18440E5AF44834B220ED35BA530D32F0CAF@WLGPRDMBX01.dia.govt.nz> 
From: Anil John 
Date: Sun, 19 Oct 2014 14:02:10 -0400
Message-ID: 
To: "vot@ietf.org" 
Content-Type: multipart/alternative; boundary=001a1135e5ee0b1de80505ca6808
Archived-At: http://mailarchive.ietf.org/arch/msg/vot/bqZVuqcJL8cy_8AZW6mbKJyudko
Subject: Re: [VoT] Foundational questions of principle
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Vectors of Trust discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 19 Oct 2014 18:03:02 -0000

--001a1135e5ee0b1de80505ca6808
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

At the level of 'foundational principles' which should be delivery channel
and technology neutral while being relevant across jurisdictions, this
simple framework by Tim Bouma which focuses on 'What is a Trusted Identity
and What does it take to Federate it?' may be helpful:

https://blog.aniljohn.com/2014/10/a-simple-framework-for-trusted-identities=
.html

Regards,

- Anil

:- Anil John
:- Making Digital Services Secure and Trustworthy
:- https://blog.aniljohn.com


On Mon, Oct 13, 2014 at 6:18 AM, Ken Dagg  wrote:

> Colin,
> See in line.
> Ken
>
> On Monday, October 13, 2014, Colin Wallis 
> wrote:
>
>>  <> or they can have some sort of an hierarchy>>.
>>
>> I think that is a =E2=80=98tbd=E2=80=99 Anil.
>>
>> We may have a better idea once the concept is developed a bit further.
>>
>> Good fine graining on Identity Proofing there..  useful.
>>
>>
>>
>> Looking below at Ken=E2=80=99s response:
>>
>> To Ken=E2=80=99s suggestion qualified by his question/assumption..
>>
>> << Credential Strength deals with the binding of an identity to a token>=
>
>>
>> .. is along the lines Justin described it IMHO, so yea, I think =E2=80=
=98token
>> proofing=E2=80=99 could be another vector/sub vector.
>>
>>
>>
>> To the comment about the value of/measurement of vectors and.
>>
>> <> work>>
>>
>> ..(typically the RP I guess) [[KD: my reason for using entity was that R=
P
>> is often seen as the service delivery agent. I wanted to be sure that an
>> IdP that is relying on an AP is also included.]] then we come back to so=
me
>> machine process-able way that the RP can express the vector values of th=
e
>> risk of that authentication instance/service/transaction which, as Steve
>> indicates, might possibly be different for each and every
>> transaction/location/context.
>>
>>
>>
>> Justin offered up a kind of codified way of expressing specific vector
>> values with a marker letter and category number (saml md iop has for som=
e
>> time now as Scott mentioned), but the trick would be  to make a distinct=
ion
>> between what vector values the RP requires (a vector/sub vector), and wh=
at
>> is =E2=80=98on offer=E2=80=99 from provider parties (another vector/sub =
vector), but still
>> in a codified way consumable by all parties. Reducing this down from a
>> complex set of values, to 3-5 Vectors, with multiple sub vectors **and**
>> make it meaningful and process-able, is one mother of a challenge..
>>
>>
>>
>> But already we have moved beyond the pretty blunt instrument that is
>> LoA.. and have not yet gone to the other extreme end of the (=E2=80=98al=
l fine
>> grained/de-composed=E2=80=99) spectrum, so that is good.
>>
>>
>>
>> Who knows how much progress we could make if we keep thinking=E2=80=A6 J
>>
>>
>>
>> Cheers
>>
>> Colin
>>
>>
>>
>> *From:* vot [mailto:vot-bounces@ietf.org] *On Behalf Of *Anil John
>> *Sent:* Monday, 13 October 2014 12:36 p.m.
>> *To:* Ken Dagg; vot@ietf.org
>> *Subject:* Re: [VoT] Foundational questions of principle
>>
>>
>>
>> Ken,
>>
>>
>>
>> I think it depends on if the intention is to keep the 'vectors' flat or
>> they can have some sort of an hierarchy.  If the latter, sure.
>>
>>
>>
>> Regards,
>>
>>
>>
>> - Anil
>>
>>
>>   Regards,
>>
>>
>>
>> - Anil
>>
>>
>>
>> :- Anil John
>>
>> :- Making Digital Services Secure and Trustworthy
>>
>> :- https://blog.aniljohn.com
>>
>>
>>
>>
>>
>> On Sun, Oct 12, 2014 at 7:28 PM, Ken Dagg  wrote:
>>
>> Anil,
>>
>> Do you think that these could be sub vectors of the Identity Proofing
>> vector?
>>
>> Ken
>>
>>
>>
>> On Monday, October 13, 2014, Anil John  wrote:
>>
>> Thank you Colin for herding the cats (Including myself there)!
>>
>>
>>
>> I would recommend splitting up the 'Identity Proofing' vector into its
>> component bits, rather than treating it like the current amorphous blob
>> that it is right now:
>>
>>
>>
>>    1. *Identity Resolution* - Establishing the uniqueness of an
>>    individual within a population
>>    2. *Identity Validation* - Confirming the accuracy of identity
>>    information claimed by an individual
>>    3. *Identity Verification* - Confirming that the claimed identity
>>    information is linked to the individual making the claim
>>
>>
>>
>> Regards,
>>
>>
>>
>> - Anil
>>
>>
>>
>> :- Anil John
>>
>> :- Making Digital Services Secure and Trustworthy
>>
>> :- https://blog.aniljohn.com
>>
>>
>>
>> Colin,
>>
>>
>>
>> Good point to move the thread back to its original topic.
>>
>>
>>
>> I would suggest that there is one more vector: token proofing. This
>> vector would be similar in nature to the identity proofing vector only
>> focused on the token rather than the identity.
>>
>>
>>
>> I have not had a chance to review the original paper to know what it say=
s
>> about the other vectors (I am supposed to be on holidays). I am assuming
>> that Identity Proofing deals with how an Identity is proofed, Credential
>> Strength deals with the binding of an identity to a token, and Assertion
>> Presentation deals with what the IdP goes through in order to issue an
>> assertion. What I believe is interesting is that these vectors are
>> applicable to any entity that does the work. What is of potential intere=
st
>> is how they apply to the entity that is the recipient of the output of t=
he
>> work.
>>
>> I agree that Operational Management is an interesting, but extremely
>> important, vector that could have many sub-vectors.
>>
>>
>>
>> While the LoA discussion seemed to be off track, I would suggest that it
>> is part of the discussion because LoA (regardless of how many
>> levels) should be a measure of and a means of communicating how much eff=
ort
>> has undertaken by the party doing the work to the entity that is receivi=
ng
>> the output of that work.
>>
>>
>>
>> Ken
>>
>>
>>
>> On Sun, Oct 12, 2014 at 3:16 PM, Colin Wallis 
>> wrote:
>>
>> Putting this split, back into one thread..
>>
>> =E2=80=A6  and pleading to folks to focus back on the vectors, or aspect=
s, or
>> =E2=80=98things=E2=80=99 - whatever we call them =E2=80=93 that the RP h=
as an interest in.
>>
>> Justin is valiantly trying to re-state the purpose of his opening
>> =E2=80=98vectors=E2=80=99 strawman =E2=80=93 always useful to refresh on=
e=E2=80=99s memory by going back to
>> look at them...
>>
>> His starting list of vectors was:
>>
>> Identity Proofing
>>
>> Credential Strength
>>
>> Assertion Presentation
>>
>> Operational Management
>>
>>
>>
>> If the discussion on LoAs offers any value here, it would be to add some
>> finer grained addition to the above (fairly coarse-grained) list.
>>
>>
>>
>> There=E2=80=99s already an acknowledgment that Operational Management ma=
y be
>> composed of a range of concerns =E2=80=93 a mix of context dependent, te=
mporal and
>> static (more vectors?) =E2=80=93 that influence the RP=E2=80=99s decisio=
n to accept or
>> otherwise, an authenticated identity.
>>
>>
>>
>> If we got to a point where we could agree on what these vectors are, the=
n
>> we can have the (separate) debate about whether combining them/delineati=
ng
>> them in some way is useful/helpful, or not.
>>
>>
>>
>> Cheers
>>
>> Colin
>>
>>
>>
>> *From:* vot [mailto:vot-bounces@ietf.org] *On Behalf Of *Richer, Justin
>> P.
>> *Sent:* Saturday, 11 October 2014 6:29 a.m.
>> *To:* Bouma, Tim
>> *Cc:* Ken Dagg; vot@ietf.org; swilson@lockstep.com.au
>> *Subject:* Re: [VoT] Foundational questions of principle
>>
>>
>>
>> What we're trying to do with the "Vectors" approach here is to strike a
>> balance between the overly-simplistic "single set of linear levels"
>> approach that LoA gives us (that nobody on this list likes but all agree
>> that apps can actually do some level of processing with it) and the
>> overly-complex "very long complex set of attributes" approach that Tim,
>> Scott, and others have brought up (that seems more expressive and ideal =
but
>> no app is ever going to make sense of, or even try to). I think it's saf=
e
>> to say that neither extreme works and that a right answer probably lies =
in
>> the middle.
>>
>>
>>
>> So that's what this strawman is -- it's simultaneously less complex and
>> more complex than the alternatives. Is it the right cut? Probably not, b=
ut
>> it's at least a cutting point that we can push to either side. What I th=
ink
>> we need to dutifully avoid is pushing it hard to either end. I really li=
ke
>> the notion that even if the combinations of the vector values aren't
>> directly compatible (as Steve says), then the building blocks would at
>> least be comparable, giving a hope of defining a policy to translate
>> between them when needed.
>>
>>
>>
>> Also, I wanted to key into the fact that there are several independent
>> and orthogonal components here. Maybe it's not a set of levels that are
>> tied together, but I think it is in someway a set of independent *things=
*
>> that are tied together.
>>
>>
>>
>>  -- Justin
>>
>> =E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=
=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=
=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6.
>>
>>
>>
>> It may make sense to look at LOAs as something that is "coarse-grained"
>> and a starting point.
>>
>>
>>
>> We all think it is not enough, but in the absence of the Borg showing up
>> to enforce a collective hive-mind across organizational boundaries, we c=
an
>> live with it and use it as a starting point for the discussion "What mor=
e
>> do we need in order to let this person in the door?"
>>
>>
>>
>> And that is where RP implemented compensating controls can play a part.
>> The challenge is that folks seem to conflate "things needed to ensure
>> confidence in an identity" with "things needed to mitigate risk in the
>> transaction" and who is (CSP or RP) responsible for what.
>>
>>
>>
>> Regards,
>>
>>
>>
>> - Anil
>>
>>
>>
>> :- Anil John
>>
>> :- Making Digital Services Secure and Trustworthy
>>
>> :- https://blog.aniljohn.com
>>
>>
>>
>>
>>
>> On Fri, Oct 10, 2014 at 11:02 PM,  wrote:
>>
>>
>> We are all agreed of course that RPs need to understand their risks,
>> determine what's needed from any external process of identification or
>> attribute attestation, communicate those needs to candidate APs, and fro=
m
>> there, contract an acceptable provider.
>>
>> My question is whether or not a pigeonholed LOA helps at any point in
>> this process.
>>
>> The devil is in the detail.  To my mind, LOA is an intermediate step tha=
t
>> takes a detailed risk analysis, squeezes it into a bin (losing lots of
>> information as a result), which is then used to shortlist candidate
>> providers, before going into detailed due diligence where all those deta=
ils
>> need to be put back on the table.
>>
>> I think we all know by now of cases where RPs have looked at candidate
>> IdPs at a given LOA, and have come up with the request of "LOA two and a
>> half" (this was mentioned at CIS 2014 more than once, and I have seen it
>> first hand in the UK IDAP).
>>
>> Clearly what's going on here is an RP's idea of say "LOA 2" differs from
>> a given IdP's idea of LOA 2.  Moreover, the idea of LOA 2 must differ fr=
om
>> one IdP to another IdP.  When people ask for "LOA 2.5" what they're aski=
ng
>> for is a customised identification.  If LOA 2 isn't what it seems, then
>> there cannot possibly be any such thing as a *standardised* LOA 2.5.  Al=
l
>> we will get is fresh calls for "LOA 2.75 please".
>>
>> If RPs need to do detailed analysis of authentication needs, and get
>> detailed verification of the actual ID proofing done by IdPs and APs, th=
en
>> I just don't see any point attaching the LOA label along the way.  It's
>> misleading.
>>
>> Cheers,
>>
>> Steve.
>>
>> Stephen Wilson
>> Lockstep
>> http://lockstep.com.au
>> Lockstep Consulting provides independent specialist advice and analysis
>> on digital identity and privacy.  Lockstep Technologies develops unique
>> new smart ID solutions that enhance privacy and prevent identity theft.
>>
>>
>>
>> On Oct 10, 2014, at 10:51 AM, Bouma, Tim  wrote=
:
>>
>>
>>
>> I agree with Ken,
>>
>>
>>
>> When we developed levels of assurance (here in Canada) we did several
>> things:
>>
>>
>>
>> =C2=B7         We defined them as levels of confidence required (Levels =
1
>> through 4)
>>
>> =C2=B7         We mapped these levels of confidence to a range of degree=
 of
>> impacts.
>>
>> =C2=B7         We then specified separately identity assurance levels an=
d
>> credential assurance levels (and focused on credential first)
>>
>> =C2=B7         We also factored out likelihood in the assurance level
>> assessment process. That made the assessments much less subjective.
>>
>>
>>
>> At the end of the day, as Ken states,  it=E2=80=99s the job the RP to un=
derstand
>> their risk (along with likelihood) and to communicate a standardized
>> requirement back to a provider (AP)
>>
>> The AP is  accountable for providing a very prescribed component that
>> fits into a larger system and a risk environment that they might not hav=
e a
>> full view into. The RP may put in provisions to share the risk with the =
AP,
>> or not but that entirely depends on the arrangement, but at least the RP
>> and AP understand what=E2=80=99s on the table as a starting point.
>>
>>
>>
>> In Canada, we did that with the credential first, and are now figuring
>> out identity (much harder).
>>
>>
>>
>> I also agree that =E2=80=98identity=E2=80=99 is just a set of attributes=
 =E2=80=93and  these
>> identity attributes can vary between organizations or jurisdictions,
>>
>>
>>
>> As for the term =E2=80=98vectors=E2=80=99, I get the idea, but I think t=
he community will
>> think it=E2=80=99s too technical or esoteric. I like to think of a =E2=
=80=98digital
>> identity=E2=80=99 (or whatever you call it), when it shows up at your di=
gital front
>> door, it is the product of a very long, complex supply chain, fraught wi=
th
>> many risks and compromises. I may have confidence in certain pieces of, =
but
>> other I might not trust at all.
>>
>>
>>
>>
>>
>> Tim
>>
>>
>>
>>
>>
>> *From:* vot [mailto:vot-bounces@ietf.org] *On Behalf Of *Ken Dagg
>> *Sent:* October-09-14 9:42 PM
>> *To:* swilson@lockstep.com.au
>> *Cc:* vot@ietf.org
>> *Subject:* Re: [VoT] Foundational questions of principle
>>
>>
>>
>> Steve,
>>
>>
>>
>> As we have communicated in the past, I am a strong believer the an LOA
>> designation is an indication of the processes/mechanisms that an IdP has
>> undertaken. In other words, it is a communication tool. The choice is th=
e
>> RPs. That is, an assertion at a specific LOA by an IdP/CSP/AP is one of =
the
>> mechanisms a RP should use to offset the authentication risk it has
>> identified for the service it wants to deliver. In other words, it is th=
e
>> risk of the RP that is paramount not the claims of
>> an identity/credential/attribute/token provider.
>>
>>
>>
>> Like you, I am a strong believer that the determination of whether or no=
t
>> an identity is good enough is the responsibility of the RP. In my
>> experience, they make that determination based upon a set of attributes
>> they believe are necessary. If they trust that an IdP's assertion of
>> identity covers the attributes they believe are required them they can
>> accept the assertion. If it doesn't then that have to implement addition=
al
>> mechanisms to offset the residual risk.
>>
>>
>>
>> With respect to vectors of trust, I am interested in exploring what they
>> are and how they can be applied.
>>
>>
>>
>> Ken
>>
>> On Thursday, October 9, 2014,  wrote:
>>
>>
>>
>> First, to introduce myself, I am an identity and privacy researcher,
>> analyst and consultant.  I've been involved in this since 1995, when I c=
ut
>> my teeth in PKI and smartcards (with the early companies that became
>> Baltimore Technologies). Since then I've worked on identity management
>> frameworks, regulations and standards.
>>
>>
>>
>> I subscribe to the old Italian proverb: "it's nice to trust but better
>> not to".  Words matter and I wonder if we shouldn't be using the word tr=
ust
>> so much.
>>
>>
>>
>> More pragmatically, I note the very strong "Attributes" push of the past
>> 18 months.  Andrew Nash, Anil John, myself and others have written about
>> this.  The FIDO Alliance is all about authentication and attributes, and
>> they purposefully leave "identity" as a matter for others to work out
>> further up the stack. The OID Foundation is promoting an Attributes
>> Exchange Network "AXN" architecture.  New entrants like id.me (an NSTIC
>> pilot participant) talk about attributes and avoid "identity".
>>
>>
>>
>> I mention all of this as a prelude to suggest that "vector of trust" is
>> synonymous with "attribute". I wonder if it would be clearer to use plai=
n
>> and current language rather than carry forward the fuzzy and I think ove=
rly
>> ambitious idea of "trust"?
>>
>>
>>
>> Finally, I'd like to throw in my abiding concern that LOAs have foundere=
d
>> simply because it's difficult to pigeonhole risk. One party's idea of
>> "medium" risk for instance will rarely map precisely to another's. I thi=
nk
>> people have been misled into thinking that an "LOA 3" identity should be=
 be
>> able to be used on its face (i.e. will "interoperate") at any "LOA 3" RP=
.
>> Risk management is not so simple.
>>
>>
>>
>> The LOA paradigm borrows from Risk Management standards like ISO 31000
>> which organisations use to plot their own risks internally typically on =
a
>> five scale (eg Negligible / Low / Medium / High / Grave). But risk
>> management standards require that each organisation calibrates risk in i=
ts
>> own business context and according to its own risk appetite. The risk of=
 a
>> firewall breach for example at a startup social media company will be
>> assessed differently by a big listed healthcare company. So organisation
>> A can say the risk of event X is Low but B can say the risk of the same
>> event is Medium.  As a result, LOAs do not inter-operate. They are based=
 on
>> standards meant for intra-organisation risk management, not
>> inter-organisation communication of risk assessments.
>>
>>
>>
>> So far with VoT we are adding more dimensions to the RPs' generic risk
>> management decision making, and that's great.  But we are still
>> pigeonholing the dimensions.
>>
>>
>>
>> I'm afraid the reality is that risk management will always be done
>> locally.  And so it should be.  When an RP is making the decision to acc=
ept
>> or reject a given subject, they will evaluate a range of attributes
>> or signals.  The set of attributes that matters varies from one RP to th=
e
>> next.  I think it's a great idea indeed to create guidance for evaluatin=
g
>> attributes, and to coach RPs to look at all sorts of dimensions.  I just
>> don't think it helps anyone to pigeonhole the risk ratings, because acro=
ss
>> organisations, arguments about the boundaries between LOA 1/2/3/4 (that =
is,
>> policy mapping) will undo any efficiencies gained from the categorizatio=
n.
>>
>>
>>
>> Cheers,
>>
>>
>>
>> Steve.
>>
>>
>>
>>
>>
>> Stephen Wilson
>> Managing Director
>> Lockstep Group
>> http://lockstep.com.au
>> Lockstep Consulting provides independent specialist advice and analysis
>> on digital identity and privacy. Lockstep Technologies develops unique
>> new smart ID solutions that enhance privacy and prevent identity theft.
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> vot mailing list
>> vot@ietf.org
>> https://www.ietf.org/mailman/listinfo/vot
>>
>>
>>
>>
>> _______________________________________________
>> vot mailing list
>> vot@ietf.org
>> https://www.ietf.org/mailman/listinfo/vot
>>
>>
>>
>>
>>
>

--001a1135e5ee0b1de80505ca6808
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


    At the level of 'foundational=C2=A0principles' whi=
ch should be delivery channel and technology neutral while being relevant a=
cross jurisdictions, this simple framework by Tim Bouma which focuses on &#=
39;What is a Trusted Identity and What does it take to Federate it?' ma=
y be helpful:


    

    On Mon, Oct 13, 2014 at 6:18 AM, Ken Dagg <kendaggtbs@gmail.com> wrote:
    Colin,See in line.
    Ken

    On Monday, October 13, 2014, Coli=
n Wallis <=
Colin.Wallis@dia.govt.nz> wrote:
    






    

    

    <<I think it depends on if the intention is to=
 keep the 'vectors' flat or they can have some sort of an hierarchy=
>>.
    

    I think that is a =E2=80=98tbd=E2=80=99 Anil=
.
    

    We may have a better idea once the concept i=
s developed a bit further.
    

    Good fine graining on Identity Proofing ther=
e.. =C2=A0useful.

    

    =C2=A0
    

    Looking below at Ken=E2=80=99s response:<=
/u>
    

    To Ken=E2=80=99s suggestion qualified by his=
 question/assumption..
    

    << Credential Strength deals wi=
th the binding of an identity to a=C2=A0token>>
    

    .. is along the lines Justin described it IMHO, so y=
ea, I think =E2=80=98token proofing=E2=80=99 could be another vector/sub ve=
ctor.
    

    =C2=A0
    

    To the comment about the value of/measurement of vec=
tors and.
    

    <<how they apply to the entity that is the rec=
ipient of the output of the work>>
    

    ..(typically the RP I guess) [[KD: my reason =
for using entity was that RP is often seen as the service delivery agent. I=
 wanted to be sure that an IdP that is relying on an AP is also included.]]=
=C2=A0then we come back to some machine process-able way that the RP can ex=
press the vector values of the risk of that authentication instance/service=
/transaction which, as Steve indicates, might possibly be different
 for each and every transaction/location/context.
    

    =C2=A0
    

    Justin offered up a kind of codified way of expressi=
ng specific vector values with a marker letter and category number (saml md=
 iop has for some time now as Scott mentioned), but the trick would be =C2=
=A0to make a distinction between what vector
 values the RP requires (a vector/sub vector), and what is =E2=80=98on offe=
r=E2=80=99 from provider parties (another vector/sub vector), but still in =
a codified way consumable by all parties. Reducing this down from a complex=
 set of values, to 3-5 Vectors, with multiple sub
 vectors *and* make it meaningful and process-able, is one mother of=
 a challenge..
    

    =C2=A0
    

    But already we have moved beyond the pretty blunt in=
strument that is LoA.. and have not yet gone to the other extreme end of th=
e (=E2=80=98all fine grained/de-composed=E2=80=99) spectrum, so that is goo=
d.=C2=A0

    

    =C2=A0
    

    Who knows how much progress we could make if we keep=
 thinking=E2=80=A6
J
    

    =C2=A0
    

    Cheers
    

    Colin =C2=A0=C2=A0=C2=A0
    

    =C2=A0
    

    From: vot [mailto:vot-bounces@iet=
f.org]
On Behalf Of Anil John
    
Sent: Monday, 13 October 2014 12:36 p.m.
    
To: Ken Dagg; vot@ietf.org
    
Subject: Re: [VoT] Foundational questions of principle=

    

    =C2=A0
    

    

    Ken,
    

    

    =C2=A0
    

    

    

    I think it depends on if the intention is to keep th=
e 'vectors' flat or they can have some sort of an hierarchy.=C2=A0 =
If the latter, sure.
    

    

    

    =C2=A0
    

    

    

    Regards,
    

    

    

    =C2=A0
    

    

    

    - Anil
    

    

    

    

    

    


    

    

    

    

    

    Regards=
,
    

    

    

    =
=C2=A0
    

    

    

    - Anil<=
u>
    

    

    

    =
=C2=A0
    

    

    

    :- Anil=
 John
    

    

    

    

    

    

    :- Maki=
ng Digital Services Secure and Trustworthy
    

    


    

    

    

    =
=C2=A0
    

    

    

    

    

    =C2=A0
    

    

    On Sun, Oct 12, 2014 at 7:28 PM, Ken Dagg <ken=
daggtbs@gmail.com> wrote:
    

    Anil,
    

    

    Do you think that these could be sub vectors of the =
Identity Proofing vector?
    

    

    

    Ken
    

    

    


    

    
On Monday, October 13, 2014, Anil John <aniltj@gmail.com> wrot=
e:
    

    

    Thank you Colin for herding the cats (Including myse=
lf there)!
    

    

    =C2=A0
    

    

    

    I would recommend splitting up the 'Identity Pro=
ofing' vector into its component bits, rather than treating it like the=
 current amorphous blob that it is right now:
    

    

    

    =C2=A0
    

    

    

      

    1. 
Iden=
tity Resolution=C2=A0-=C2=A0Establishing the uniqueness of an individua=
l within a population
    2. 
Iden=
tity Validation=C2=A0-=C2=A0Confirming the accuracy of identity informa=
tion claimed by an individual
    3. 
Iden=
tity Verification=C2=A0-=C2=A0Confirming that the claimed identity info=
rmation is linked to the individual making
 the claim=C2=A0
    

    

    =C2=A0
    

    

    

    Regards,
    

    

    

    

    

    

    

    =
=C2=A0
    

    

    

    - Anil<=
u>
    

    

    

    =
=C2=A0
    

    

    

    :- Anil=
 John
    

    

    

    

    

    

    :- Maki=
ng Digital Services Secure and Trustworthy
    

    


    

    

    

    =C2=A0
    

    Colin,
    

    =C2=A0
    

    Good point to move the thread back to its original t=
opic.
    

    =C2=A0
    

    I would suggest that there is one more vector: token=
 proofing. This vector would be similar in nature to the identity proofing =
vector only focused on the token rather than the identity.

    =C2=A0
    

    I=C2=A0have not had a chance to review the original =
paper to know what it says about the other vectors (I am supposed=C2=A0to b=
e on holidays). I am assuming that Identity Proofing deals with how an Iden=
tity is proofed,=C2=A0Credential Strength deals with
 the binding of an identity to a=C2=A0token, and=C2=A0Assertion Presentatio=
n deals with what the IdP goes through in order to issue an assertion. What=
 I believe is interesting is that these vectors are applicable to any entit=
y that does the work. What is of potential
 interest is how they apply to the entity that is the recipient of the outp=
ut of the work.
    

    
I agree that Operational Management is an interesting, but extremely import=
ant,=C2=A0vector that could have many sub-vectors.
    

    =C2=A0
    

    While the LoA discussion seemed to be off track, I w=
ould suggest that it is part of the discussion because LoA (regardless of h=
ow many levels)=C2=A0should be a measure of and a means of communicating ho=
w much effort has undertaken by the party
 doing the work to the entity that is receiving the output of that work.=

    

    =C2=A0
    

    Ken
    

    

    

    

    

    

    

    =C2=A0
    

    

    On Sun, Oct 12, 2014 at 3:16 PM, Colin Wallis <Colin.Wallis@dia.govt.nz> wrote:
    

    

    

    Putting this split, back into one thread..
    

    =E2=80=A6 =C2=A0and pleading to folks to foc=
us back on the vectors, or aspects, or =E2=80=98things=E2=80=99 - whatever =
we call
 them =E2=80=93 that the RP has an interest in. 
    

    Justin is valiantly trying to re-state the p=
urpose of his opening =E2=80=98vectors=E2=80=99 strawman =E2=80=93 always u=
seful
 to refresh one=E2=80=99s memory by going back to look at them...=

    

    His starting list of vectors was:

    

    Identity Proofing
    

    Credential Strength
    

    Assertion Presentation<=
/p>

    Operational Management<=
/p>

    =C2=A0
    

    If the discussion on LoAs offers any value h=
ere, it would be to add some finer grained addition to
 the above (fairly coarse-grained) list.
    

    =C2=A0
    

    There=E2=80=99s already an acknowledgment th=
at Operational Management may be composed of a range of concerns
 =E2=80=93 a mix of context dependent, temporal and static (more vectors?) =
=E2=80=93 that influence the RP=E2=80=99s decision to accept or otherwise, =
an authenticated identity.
    

    =C2=A0=C2=A0=C2=A0=C2=A0
    

    If we got to a point where we could agree on=
 what these vectors are, then we can have the (separate)
 debate about whether combining them/delineating them in some way is useful=
/helpful, or not.
    

    =C2=A0
    

    Cheers
    

    Colin

    

    =C2=A0
    

    

    

    From: vot
 [mailto:vot-bounces@ietf.org] On Behalf Of
Richer, Justin P.
    
Sent: Saturday, 11 October 2014 6:29 a.m.
    
To: Bouma, Tim
    
Cc: Ken Dagg; vot@ietf.org; 
swilson@lockstep.com.au
    
Subject: Re: [VoT] Foundational questions of principle    =

    

    

    

    =C2=A0
    

    What we're trying to do with the "Vectors&q=
uot; approach here is to strike a balance between the overly-simplistic &qu=
ot;single set of linear levels" approach that LoA gives us (that nobod=
y
 on this list likes but all agree that apps can actually do some level of p=
rocessing with it) and the overly-complex "very long complex set of at=
tributes" approach that Tim, Scott, and others have brought up (that s=
eems more expressive and ideal but no app
 is ever going to make sense of, or even try to). I think it's safe to =
say that neither extreme works and that a right answer probably lies in the=
 middle.=C2=A0

    

    

    =C2=A0
    

    

    

    So that's what this strawman is -- it's simu=
ltaneously less complex and more complex than the alternatives. Is it the r=
ight cut? Probably not, but it's at least a cutting point
 that we can push to either side. What I think we need to dutifully avoid i=
s pushing it hard to either end. I really like the notion that even if the =
combinations of the vector values aren't directly compatible (as Steve =
says), then the building blocks would
 at least be comparable, giving a hope of defining a policy to translate be=
tween them when needed.=C2=A0
    

    

    

    =C2=A0
    

    

    

    Also, I wanted to key into the fact that there are s=
everal independent and orthogonal components here. Maybe it's not a set=
 of levels that are tied together, but I think it is in
 someway a set of independent *things* that are tied together.
    

    

    

    =C2=A0
    

    

    

    =C2=A0-- Justin
    

    =E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=
=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=
=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=
=80=A6.
    

    =C2=A0
    

    It may make sense to look at LOAs as something that =
is "coarse-grained" and a starting point.=C2=A0
    

    =C2=A0
    

    We all think it is not enough, but in the absence of=
 the Borg showing up to enforce a collective hive-mind across organizationa=
l boundaries, we can live with it and use it as a
 starting point for the discussion "What more do we need in order to l=
et this person in the door?"
    

    =C2=A0
    

    And that is where RP implemented compensating contro=
ls can play a part. The challenge is that folks seem to conflate "thin=
gs needed to ensure confidence in an identity" with "things
 needed to mitigate risk in the transaction" and who is (CSP or RP) re=
sponsible for what.
    

    =C2=A0
    

    Regards,
    

    =C2=A0
    

    - Anil
    

    =C2=A0
    

    :- Anil John
    

    :- Making Digital Services Secure and Trustworthy=

    

    :-
https://blog.aniljo=
hn.com
    

    =C2=A0
    

    =C2=A0
    

    On Fri, Oct 10, 2014 at 11:02 PM, <swilson@loc=
kstep.com.au> wrote:
    


    
We are all agreed of course that RPs need to understand their risks, determ=
ine what's needed from any external process of identification or attrib=
ute attestation, communicate those needs to candidate APs, and from there, =
contract an acceptable provider.
    

    
My question is whether or not a pigeonholed LOA helps at any point in this =
process.
    

    
The devil is in the detail.=C2=A0 To my mind, LOA is an intermediate step t=
hat takes a detailed risk analysis, squeezes it into a bin (losing lots of =
information as a result), which is then used to shortlist candidate provide=
rs, before going into detailed due diligence
 where all those details need to be put back on the table.
    

    
I think we all know by now of cases where RPs have looked at candidate IdPs=
 at a given LOA, and have come up with the request of "LOA two and a h=
alf" (this was mentioned at CIS 2014 more than once, and I have seen i=
t first hand in the UK IDAP).
    

    
Clearly what's going on here is an RP's idea of say "LOA 2&quo=
t; differs from a given IdP's idea of LOA 2.=C2=A0 Moreover, the idea o=
f LOA 2 must differ from one IdP to another IdP.=C2=A0 When people ask for =
"LOA 2.5" what they're asking for is a customised identificat=
ion.=C2=A0
 If LOA 2 isn't what it seems, then there cannot possibly be any such t=
hing as a *standardised* LOA 2.5.=C2=A0 All we will get is fresh calls for =
"LOA 2.75 please".
    

    
If RPs need to do detailed analysis of authentication needs, and get detail=
ed verification of the actual ID proofing done by IdPs and APs, then I just=
 don't see any point attaching the LOA label along the way.=C2=A0 It=
9;s misleading.
    

    
Cheers,
    

    
Steve.
    

    
Stephen Wilson
    
Lockstep
    
http://lockstep.com.au=

    
Lockstep Consulting provides independent specialist advice and analysis
    
on digital identity and privacy.=C2=A0 Lockstep Technologies develops uniqu=
e
    
new smart ID solutions that enhance privacy and prevent identity theft.<=
/u>
    

    

    

    =C2=A0
    

    

    

    On Oct 10, 2014, at 10:51 AM, Bouma, Tim <Tim.=
Bouma@tbs-sct.gc.ca> wrote:
    

    

    =C2=A0

    

    I agree with Ken,
    

    =C2=A0

    When we developed levels of a=
ssurance (here in Canada) we did several things:
    

    =C2=A0

    =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0
We defined them as levels of confidence requi=
red (Levels 1 through 4)
    

    =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0
We mapped these levels of confidence to a ran=
ge of degree of impacts.
    

    =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0
We then specified separately identity assuran=
ce levels and credential assurance levels (and focused on credential first)=

    

    =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0
We also factored out likelihood in the assura=
nce level assessment process. That made the assessments much less subjectiv=
e.
    

    =C2=A0

    At the end of the day, as Ken=
 states, =C2=A0it=E2=80=99s the job the RP to understand their risk
 (along with likelihood) and to communicate a standardized requirement back=
 to a provider (AP)
    

    The AP is =C2=A0accountable f=
or providing a very prescribed component that fits into a larger
 system and a risk environment that they might not have a full view into. T=
he RP may put in provisions to share the risk with the AP, or not but that =
entirely depends on the arrangement, but at least the RP and AP understand =
what=E2=80=99s on the table as a starting
 point.
    

    =C2=A0

    In Canada, we did that with t=
he credential first, and are now figuring out identity
 (much harder).
    

    =C2=A0

    I also agree that =E2=80=98id=
entity=E2=80=99 is just a set of attributes =E2=80=93and =C2=A0these identi=
ty attributes
 can vary between organizations or jurisdictions,
    

    =C2=A0

    As for the term =E2=80=98vect=
ors=E2=80=99, I get the idea, but I think the community will think it=E2=80=
=99s
 too technical or esoteric. I like to think of a =E2=80=98digital identity=
=E2=80=99 (or whatever you call it), when it shows up at your digital front=
 door, it is the product of a very long, complex supply chain, fraught with=
 many risks and compromises. I may have confidence
 in certain pieces of, but other I might not trust at all.=

    

    =C2=A0

    =C2=A0

    Tim
    

    =C2=A0

    =C2=A0

    From:
 vot [mailto:vot-bounces@ietf.org] On Behalf Of
Ken Dagg
    
Sent: October-09-14 9:42 PM
    
To: swilson@lockstep.com.au
    
Cc: vot@ietf.org
    
Subject: Re: [VoT] Foundational questions of principle    =

    

    =C2=A0
    

    Steve,
    

    

    =C2=A0
    

    

    

    As we have communicated in=C2=
=A0the past, I am a strong believer the an LOA designation is an indication=
 of the processes/mechanisms that an=C2=A0IdP has undertaken. In
 other words, it is a communication tool.=C2=A0The choice is the RPs. That =
is, an=C2=A0assertion at a specific LOA by an=C2=A0IdP/CSP/AP=C2=A0is one o=
f the mechanisms a RP should use to offset the authentication risk it has i=
dentified for the service it wants to deliver. In other
 words, it is the risk of the RP that is paramount not the claims of an=C2=
=A0identity/credential/attribute/token provider.
    

    

    

    =C2=A0
    

    

    

    Like you, I am a strong believe=
r that the determination of whether or not an identity is good enough is th=
e responsibility of the RP. In my experience, they make
 that determination based upon a set of attributes they believe are necessa=
ry. If they trust that an IdP's assertion of identity covers the attrib=
utes they believe are=C2=A0required them they can accept the assertion. If =
it doesn't then that have to implement additional
 mechanisms to offset the residual risk.
    

    

    

    =C2=A0
    

    

    

    With respect to vectors of trus=
t, I am interested in exploring what they are and how they can be applied.<=
/span>
    

    

    

    =C2=A0
    

    

    

    Ken
    

    
On Thursday, October 9, 2014, <swilson@lockstep.com.au> wrote:=

    

    

    =C2=A0
    

    

    

    First, to introduce myself, I am an identity and pri=
vacy researcher, analyst and consultant.=C2=A0 I've been
 involved in this since 1995, when I cut my teeth in PKI and smartcards (wi=
th the early companies that became Baltimore Technologies). Since then I=
9;ve worked on identity management frameworks, regulations and standards. =
=C2=A0
    

    

    

    =C2=A0
    

    

    

    I subscribe to the old Italian proverb: "it'=
;s nice to trust but better not to".=C2=A0 Words matter and I
 wonder if we shouldn't be using the word trust so much. =C2=A0<=
u>
    

    

    

    =C2=A0
    

    

    

    More pragmatically, I note the very strong "Att=
ributes" push of the past 18 months.=C2=A0 Andrew Nash, Anil
 John, myself and others have written about this.=C2=A0 The FIDO Alliance i=
s all about authentication and attributes, and they purposefully leave &quo=
t;identity" as a matter for others to work out further up the stack. T=
he OID Foundation is promoting an Attributes Exchange
 Network "AXN" architecture.=C2=A0 New entrants like 
id.me (an NSTIC pilot participant) talk about attributes and avoid &quo=
t;identity".=C2=A0
    

    

    

    =C2=A0
    

    

    

    I mention all of this as a prelude to suggest that &=
quot;vector of trust" is synonymous with "attribute".
 I wonder if it would be clearer to use plain and current language rather t=
han carry forward the fuzzy and I think overly ambitious idea of "trus=
t"?=C2=A0
    

    

    

    =C2=A0
    

    

    

    Finally, I'd like to throw in my abiding concern=
 that LOAs have foundered simply because it's difficult
 to pigeonhole risk. One party's idea of "medium" risk for in=
stance will rarely map precisely to another's. I think people have been=
 misled into thinking that an "LOA 3" identity should be be able =
to be used on its face (i.e. will "interoperate") at any "LO=
A
 3" RP. Risk management is not so simple.=C2=A0

    

    

    =C2=A0
    

    

    

    The LOA paradigm borrows from Risk Management standa=
rds like ISO 31000 which=C2=A0organisations use to=C2=A0plot=C2=A0their
 own risks internally typically on a five scale (eg Negligible / Low / Medi=
um / High / Grave).=C2=A0But=C2=A0risk management=C2=A0standards require th=
at each organisation calibrates risk in its own business context and accord=
ing to its=C2=A0own risk appetite. The risk of a firewall
 breach for example at a startup social media company will be assessed diff=
erently by a big listed healthcare company.=C2=A0So organisation A=C2=A0can=
 say the risk of event X is Low but B can say the risk of the same event is=
 Medium.=C2=A0 As=C2=A0a result, LOAs do not inter-operate.
 They are based on standards meant for intra-organisation risk management, =
not inter-organisation communication of=C2=A0risk assessments.=C2=A0=

    

    

    

    =C2=A0
    

    

    

    So far with VoT we are adding more dimensions to the=
 RPs' generic risk management decision making, and
 that's great.=C2=A0 But we are still pigeonholing the dimensions.
    

    

    

    =C2=A0
    

    

    

    I'm afraid the reality is that risk management w=
ill always be done locally.=C2=A0 And so it should be.=C2=A0 When
 an RP is making=C2=A0the decision to accept or reject a given subject, the=
y will evaluate a range of attributes or=C2=A0signals.=C2=A0 The set of att=
ributes that matters varies from one RP to the next.=C2=A0 I think it's=
 a great idea indeed to create guidance for evaluating attributes,
 and to coach RPs to look at all sorts of dimensions.=C2=A0 I just don'=
t think it helps anyone to pigeonhole the risk ratings, because across orga=
nisations, arguments about the boundaries between LOA 1/2/3/4 (that is, pol=
icy mapping) will=C2=A0undo any efficiencies gained
 from the categorization. =C2=A0
    

    

    

    =C2=A0
    

    

    

    Cheers,=C2=A0
    

    

    

    =C2=A0
    

    

    

    Steve.
    

    

    

    =C2=A0
    

    

    

    =C2=A0
    

    

    

    Stephen Wilson
    
Managing Director
    
Lockstep Group
    
http://lockstep.com.a=
u
    
Lockstep Consulting provides independent specialist advice and analysis 
on digital identity and privacy. Lockstep Technologies develops unique 
    
new smart ID solutions that enhance privacy and prevent identity theft.
    

    

    

    =C2=A0
    

    

    

    =C2=A0
    

    

    

    =C2=A0
    

    

    

    

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

    

    =C2=A0
    

    

    

    


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

    

    =C2=A0
    

    

    

    

    

    

    

    =C2=A0
    

    

    

    


    


    Ken

    On Monday, October 13, 2014, C=
olin Wallis <Colin.Wallis@di=
a.govt.nz> wrote:
    






    

    

    <<I think it depends on if the intention is to=
 keep the 'vectors' flat or they can have some sort of an hierarchy=
>>.
    

    I think that is a =E2=80=
=98tbd=E2=80=99 Anil.
    

    We may have a better idea=
 once the concept is developed a bit further.
    

    Good fine graining on Ide=
ntity Proofing there.. =C2=A0useful.

    

    =C2=A0
    

    Looking below at Ken=E2=
=80=99s response:
    

    To Ken=E2=80=99s suggesti=
on qualified by his question/assumption..
    

    << Credentia=
l Strength deals with the binding of an identity to a=C2=A0token>>=

    

    .. is along the lines Justin described it IMHO, so y=
ea, I think =E2=80=98token proofing=E2=80=99 could be another vector/sub ve=
ctor.
    

    =C2=A0
    

    To the comment about the value of/measurement of vec=
tors and.
    

    <<how they apply to the entity that is the rec=
ipient of the output of the work>>
    

    ..(typically the RP I guess) [[KD: my reason for usi=
ng entity was that RP is often seen as the service delivery agent. I wanted=
 to be sure that an IdP that is relying on an AP is also included.]]=C2=A0t=
hen we come back to some machine process-able way that the RP can express t=
he vector values of the risk of that authentication instance/service/transa=
ction which, as Steve indicates, might possibly be different
 for each and every transaction/location/context.
    

    =C2=A0
    

    Justin offered up a kind of codified way of expressi=
ng specific vector values with a marker letter and category number (saml md=
 iop has for some time now as Scott mentioned), but the trick would be =C2=
=A0to make a distinction between what vector
 values the RP requires (a vector/sub vector), and what is =E2=80=98on offe=
r=E2=80=99 from provider parties (another vector/sub vector), but still in =
a codified way consumable by all parties. Reducing this down from a complex=
 set of values, to 3-5 Vectors, with multiple sub
 vectors *and* make it meaningful and process-able, is one mother of=
 a challenge..
    

    =C2=A0
    

    But already we have moved beyond the pretty blunt in=
strument that is LoA.. and have not yet gone to the other extreme end of th=
e (=E2=80=98all fine grained/de-composed=E2=80=99) spectrum, so that is goo=
d.=C2=A0

    

    =C2=A0
    

    Who knows how much progress we could make if we keep=
 thinking=E2=80=A6
J
    

    =C2=A0
    

    Cheers
    

    Colin =C2=A0=C2=A0=C2=A0
    

    =C2=A0
    

    From: vot [mailto:vot-bounces@ietf.=
org]
On Behalf Of Anil John
    
Sent: Monday, 13 October 2014 12:36 p.m.
    
To: Ken Dagg; vot@ietf.org
    
Subject: Re: [VoT] Foundational questions of principle=

    

    =C2=A0
    

    

    Ken,
    

    

    =C2=A0
    

    

    

    I think it depends on if the intention is to keep th=
e 'vectors' flat or they can have some sort of an hierarchy.=C2=A0 =
If the latter, sure.
    

    

    

    =C2=A0
    

    

    

    Regards,
    

    

    

    =C2=A0
    

    

    

    - Anil
    

    

    

    

    

    


    

    

    

    

    

    Regards,
    

    

    

    =C2=A0
    

    

    

    - Anil
    

    

    

    =C2=A0
    

    

    

    :- Anil John
    

    

    

    

    

    

    :- Making Digital Services Secure and Trustworthy
    

    


    

    

    

    =C2=A0
    

    

    

    

    

    =C2=A0
    

    

    On Sun, Oct 12, 2014 at 7:28 PM, Ken Dagg <kendaggtbs@gmail.com> wrote:
    

    Anil,
    

    

    Do you think that these could be sub vectors of the =
Identity Proofing vector?
    

    

    

    Ken
    

    

    


    

    
On Monday, October 13, 2014, Anil John <aniltj@gmail=
.com> wrote:
    

    

    Thank you Colin for herding the cats (Including myse=
lf there)!
    

    

    =C2=A0
    

    

    

    I would recommend splitting up the 'Identity Pro=
ofing' vector into its component bits, rather than treating it like the=
 current amorphous blob that it is right now:
    

    

    

    =C2=A0
    

    

    

      

    1. 
Identity Resolution=C2=A0-=
=C2=A0Establishing the uniqueness of an individual within a population
    2. 
Identity Validation=C2=A0-=
=C2=A0Confirming the accuracy of identity information claimed by an individ=
ual
    3. 
Identity Verification=C2=A0=
-=C2=A0Confirming that the claimed identity information is linked to the in=
dividual making
 the claim=C2=A0
    

    

    =C2=A0
    

    

    

    Regards,
    

    

    

    

    

    

    

    =C2=A0
    

    

    

    - Anil
    

    

    

    =C2=A0
    

    

    

    :- Anil John
    

    

    

    

    

    

    :- Making Digital Services Secure and Trustworthy
    

    


    

    

    

    =C2=A0
    

    Colin,
    

    =C2=A0
    

    Good point to move the thread back to its original t=
opic.
    

    =C2=A0
    

    I would suggest that there is one more vector: token=
 proofing. This vector would be similar in nature to the identity proofing =
vector only focused on the token rather than the identity.

    =C2=A0
    

    I=C2=A0have not had a chance to review the original =
paper to know what it says about the other vectors (I am supposed=C2=A0to b=
e on holidays). I am assuming that Identity Proofing deals with how an Iden=
tity is proofed,=C2=A0Credential Strength deals with
 the binding of an identity to a=C2=A0token, and=C2=A0Assertion Presentatio=
n deals with what the IdP goes through in order to issue an assertion. What=
 I believe is interesting is that these vectors are applicable to any entit=
y that does the work. What is of potential
 interest is how they apply to the entity that is the recipient of the outp=
ut of the work.
    

    
I agree that Operational Management is an interesting, but extremely import=
ant,=C2=A0vector that could have many sub-vectors.
    

    =C2=A0
    

    While the LoA discussion seemed to be off track, I w=
ould suggest that it is part of the discussion because LoA (regardless of h=
ow many levels)=C2=A0should be a measure of and a means of communicating ho=
w much effort has undertaken by the party
 doing the work to the entity that is receiving the output of that work.=

    

    =C2=A0
    

    Ken
    

    

    

    

    

    

    

    =C2=A0
    

    

    On Sun, Oct 12, 2014 at 3:16 PM, Colin Wallis <Colin.Wallis@dia.govt.nz> wrote:=

    

    

    

    Putting this split, back =
into one thread..
    

    =E2=80=A6 =C2=A0and plead=
ing to folks to focus back on the vectors, or aspects, or =E2=80=98things=
=E2=80=99 - whatever we call
 them =E2=80=93 that the RP has an interest in. 
    

    Justin is valiantly tryin=
g to re-state the purpose of his opening =E2=80=98vectors=E2=80=99 strawman=
 =E2=80=93 always useful
 to refresh one=E2=80=99s memory by going back to look at them...=

    

    His starting list of vect=
ors was:

    

    Identity Proofing<=
u>
    

    Credential Strength
    

    Assertion Presentation
    

    Operational Management
    

    =C2=A0
    

    If the discussion on LoAs=
 offers any value here, it would be to add some finer grained addition to
 the above (fairly coarse-grained) list.
    

    =C2=A0
    

    There=E2=80=99s already a=
n acknowledgment that Operational Management may be composed of a range of =
concerns
 =E2=80=93 a mix of context dependent, temporal and static (more vectors?) =
=E2=80=93 that influence the RP=E2=80=99s decision to accept or otherwise, =
an authenticated identity.
    

    =C2=A0=C2=A0=C2=A0=C2=A0<=
/span>
    

    If we got to a point wher=
e we could agree on what these vectors are, then we can have the (separate)
 debate about whether combining them/delineating them in some way is useful=
/helpful, or not.
    

    =C2=A0
    

    Cheers
    

    Colin

    

    =C2=A0
    

    

    

    From: vot
 [mailto:vot-bounces@ietf.org] On Behalf Of
Richer, Justin P.
    
Sent: Saturday, 11 October 2014 6:29 a.m.
    
To: Bouma, Tim
    
Cc: Ken Dagg; vot@ietf.org; 
swilson@lockstep.com.au
    
Subject: Re: [VoT] Foundational questions of principle    =

    

    

    

    =C2=A0
    

    What we're trying to do with the "Vectors&q=
uot; approach here is to strike a balance between the overly-simplistic &qu=
ot;single set of linear levels" approach that LoA gives us (that nobod=
y
 on this list likes but all agree that apps can actually do some level of p=
rocessing with it) and the overly-complex "very long complex set of at=
tributes" approach that Tim, Scott, and others have brought up (that s=
eems more expressive and ideal but no app
 is ever going to make sense of, or even try to). I think it's safe to =
say that neither extreme works and that a right answer probably lies in the=
 middle.=C2=A0

    

    

    =C2=A0
    

    

    

    So that's what this strawman is -- it's simu=
ltaneously less complex and more complex than the alternatives. Is it the r=
ight cut? Probably not, but it's at least a cutting point
 that we can push to either side. What I think we need to dutifully avoid i=
s pushing it hard to either end. I really like the notion that even if the =
combinations of the vector values aren't directly compatible (as Steve =
says), then the building blocks would
 at least be comparable, giving a hope of defining a policy to translate be=
tween them when needed.=C2=A0
    

    

    

    =C2=A0
    

    

    

    Also, I wanted to key into the fact that there are s=
everal independent and orthogonal components here. Maybe it's not a set=
 of levels that are tied together, but I think it is in
 someway a set of independent *things* that are tied together.
    

    

    

    =C2=A0
    

    

    

    =C2=A0-- Justin
    

    =E2=80=A6=E2=80=A6=E2=80=
=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=
=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=
=80=A6=E2=80=A6=E2=80=A6.
    

    =C2=A0
    

    It may make sense to look at LOAs as something that =
is "coarse-grained" and a starting point.=C2=A0
    

    =C2=A0
    

    We all think it is not enough, but in the absence of=
 the Borg showing up to enforce a collective hive-mind across organizationa=
l boundaries, we can live with it and use it as a
 starting point for the discussion "What more do we need in order to l=
et this person in the door?"
    

    =C2=A0
    

    And that is where RP implemented compensating contro=
ls can play a part. The challenge is that folks seem to conflate "thin=
gs needed to ensure confidence in an identity" with "things
 needed to mitigate risk in the transaction" and who is (CSP or RP) re=
sponsible for what.
    

    =C2=A0
    

    Regards,
    

    =C2=A0
    

    - Anil
    

    =C2=A0
    

    :- Anil John
    

    :- Making Digital Services Secure and Trustworthy=

    

    :-
https://blog.aniljo=
hn.com
    

    =C2=A0
    

    =C2=A0
    

    On Fri, Oct 10, 2014 at 11:02 PM, <swilson@lockstep.com.au> wrote:
    


    
We are all agreed of course that RPs need to understand their risks, determ=
ine what's needed from any external process of identification or attrib=
ute attestation, communicate those needs to candidate APs, and from there, =
contract an acceptable provider.
    

    
My question is whether or not a pigeonholed LOA helps at any point in this =
process.
    

    
The devil is in the detail.=C2=A0 To my mind, LOA is an intermediate step t=
hat takes a detailed risk analysis, squeezes it into a bin (losing lots of =
information as a result), which is then used to shortlist candidate provide=
rs, before going into detailed due diligence
 where all those details need to be put back on the table.
    

    
I think we all know by now of cases where RPs have looked at candidate IdPs=
 at a given LOA, and have come up with the request of "LOA two and a h=
alf" (this was mentioned at CIS 2014 more than once, and I have seen i=
t first hand in the UK IDAP).
    

    
Clearly what's going on here is an RP's idea of say "LOA 2&quo=
t; differs from a given IdP's idea of LOA 2.=C2=A0 Moreover, the idea o=
f LOA 2 must differ from one IdP to another IdP.=C2=A0 When people ask for =
"LOA 2.5" what they're asking for is a customised identificat=
ion.=C2=A0
 If LOA 2 isn't what it seems, then there cannot possibly be any such t=
hing as a *standardised* LOA 2.5.=C2=A0 All we will get is fresh calls for =
"LOA 2.75 please".
    

    
If RPs need to do detailed analysis of authentication needs, and get detail=
ed verification of the actual ID proofing done by IdPs and APs, then I just=
 don't see any point attaching the LOA label along the way.=C2=A0 It=
9;s misleading.
    

    
Cheers,
    

    
Steve.
    

    
Stephen Wilson
    
Lockstep
    
http://lockstep.com.au=

    
Lockstep Consulting provides independent specialist advice and analysis
    
on digital identity and privacy.=C2=A0 Lockstep Technologies develops uniqu=
e
    
new smart ID solutions that enhance privacy and prevent identity theft.<=
/u>
    

    

    

    =C2=A0
    

    

    

    On Oct 10, 2014, at 10:51 AM, Bouma, Tim <Tim.Bouma@tbs-sct.gc.ca> wrote:

    

    =C2=A0<=
/p>

    

    I agree wi=
th Ken,
    

    =C2=A0
    

    When we de=
veloped levels of assurance (here in Canada) we did several things:<=
u>
    

    =C2=A0
    

    =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0
We defined them as levels =
of confidence required (Levels 1 through 4)
    

    =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0
We mapped these levels of =
confidence to a range of degree of impacts.
    

    =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0
We then specified separate=
ly identity assurance levels and credential assurance levels (and focused o=
n credential first)
    

    =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0
We also factored out likel=
ihood in the assurance level assessment process. That made the assessments =
much less subjective.
    

    =C2=A0
    

    At the end=
 of the day, as Ken states, =C2=A0it=E2=80=99s the job the RP to understand=
 their risk
 (along with likelihood) and to communicate a standardized requirement back=
 to a provider (AP)
    

    The AP is =
=C2=A0accountable for providing a very prescribed component that fits into =
a larger
 system and a risk environment that they might not have a full view into. T=
he RP may put in provisions to share the risk with the AP, or not but that =
entirely depends on the arrangement, but at least the RP and AP understand =
what=E2=80=99s on the table as a starting
 point.
    

    =C2=A0
    

    In Canada,=
 we did that with the credential first, and are now figuring out identity
 (much harder).
    

    =C2=A0
    

    I also agr=
ee that =E2=80=98identity=E2=80=99 is just a set of attributes =E2=80=93and=
 =C2=A0these identity attributes
 can vary between organizations or jurisdictions,
    

    =C2=A0
    

    As for the=
 term =E2=80=98vectors=E2=80=99, I get the idea, but I think the community =
will think it=E2=80=99s
 too technical or esoteric. I like to think of a =E2=80=98digital identity=
=E2=80=99 (or whatever you call it), when it shows up at your digital front=
 door, it is the product of a very long, complex supply chain, fraught with=
 many risks and compromises. I may have confidence
 in certain pieces of, but other I might not trust at all.=

    

    =C2=A0
    

    =C2=A0
    

    Tim=

    

    =C2=A0
    

    =C2=A0
    

    From:
 vot [mailto:vot-bounces@ietf.org] On Behalf=
 Of
Ken Dagg
    
Sent: October-09-14 9:42 PM
    
To: swilson@lockstep.com.au
    
Cc: vot@ietf.org
    
Subject: Re: [VoT] Foundational questions of principle    =

    

    =C2=A0
    

    Steve,
    

    

    =C2=A0
    

    

    

    As we have communicated in=C2=
=A0the past, I am a strong believer the an LOA designation is an indication=
 of the processes/mechanisms that an=C2=A0IdP has undertaken. In
 other words, it is a communication tool.=C2=A0The choice is the RPs. That =
is, an=C2=A0assertion at a specific LOA by an=C2=A0IdP/CSP/AP=C2=A0is one o=
f the mechanisms a RP should use to offset the authentication risk it has i=
dentified for the service it wants to deliver. In other
 words, it is the risk of the RP that is paramount not the claims of an=C2=
=A0identity/credential/attribute/token provider.
    

    

    

    =C2=A0
    

    

    

    Like you, I am a strong believe=
r that the determination of whether or not an identity is good enough is th=
e responsibility of the RP. In my experience, they make
 that determination based upon a set of attributes they believe are necessa=
ry. If they trust that an IdP's assertion of identity covers the attrib=
utes they believe are=C2=A0required them they can accept the assertion. If =
it doesn't then that have to implement additional
 mechanisms to offset the residual risk.
    

    

    

    =C2=A0
    

    

    

    With respect to vectors of trus=
t, I am interested in exploring what they are and how they can be applied.<=
/span>
    

    

    

    =C2=A0
    

    

    

    Ken
    

    
On Thursday, October 9, 2014, <swilson@lockst=
ep.com.au> wrote:
    

    

    =C2=A0
    

    

    

    First, to introduce myself=
, I am an identity and privacy researcher, analyst and consultant.=C2=A0 I&=
#39;ve been
 involved in this since 1995, when I cut my teeth in PKI and smartcards (wi=
th the early companies that became Baltimore Technologies). Since then I=
9;ve worked on identity management frameworks, regulations and standards. =
=C2=A0
    

    

    

    =C2=A0
    

    

    

    I subscribe to the old Ita=
lian proverb: "it's nice to trust but better not to".=C2=A0 W=
ords matter and I
 wonder if we shouldn't be using the word trust so much. =C2=A0<=
u>
    

    

    

    =C2=A0
    

    

    

    More pragmatically, I note=
 the very strong "Attributes" push of the past 18 months.=C2=A0 A=
ndrew Nash, Anil
 John, myself and others have written about this.=C2=A0 The FIDO Alliance i=
s all about authentication and attributes, and they purposefully leave &quo=
t;identity" as a matter for others to work out further up the stack. T=
he OID Foundation is promoting an Attributes Exchange
 Network "AXN" architecture.=C2=A0 New entrants like 
id.me (an NSTIC pilot participant) talk about attributes and avoid &quo=
t;identity".=C2=A0
    

    

    

    =C2=A0
    

    

    

    I mention all of this as a=
 prelude to suggest that "vector of trust" is synonymous with &qu=
ot;attribute".
 I wonder if it would be clearer to use plain and current language rather t=
han carry forward the fuzzy and I think overly ambitious idea of "trus=
t"?=C2=A0
    

    

    

    =C2=A0
    

    

    

    Finally, I'd like to t=
hrow in my abiding concern that LOAs have foundered simply because it's=
 difficult
 to pigeonhole risk. One party's idea of "medium" risk for in=
stance will rarely map precisely to another's. I think people have been=
 misled into thinking that an "LOA 3" identity should be be able =
to be used on its face (i.e. will "interoperate") at any "LO=
A
 3" RP. Risk management is not so simple.=C2=A0

    

    

    =C2=A0
    

    

    

    The LOA paradigm borrows f=
rom Risk Management standards like ISO 31000 which=C2=A0organisations use t=
o=C2=A0plot=C2=A0their
 own risks internally typically on a five scale (eg Negligible / Low / Medi=
um / High / Grave).=C2=A0But=C2=A0risk management=C2=A0standards require th=
at each organisation calibrates risk in its own business context and accord=
ing to its=C2=A0own risk appetite. The risk of a firewall
 breach for example at a startup social media company will be assessed diff=
erently by a big listed healthcare company.=C2=A0So organisation A=C2=A0can=
 say the risk of event X is Low but B can say the risk of the same event is=
 Medium.=C2=A0 As=C2=A0a result, LOAs do not inter-operate.
 They are based on standards meant for intra-organisation risk management, =
not inter-organisation communication of=C2=A0risk assessments.=C2=A0=

    

    

    

    =C2=A0
    

    

    

    So far with VoT we are add=
ing more dimensions to the RPs' generic risk management decision making=
, and
 that's great.=C2=A0 But we are still pigeonholing the dimensions.
    

    

    

    =C2=A0
    

    

    

    I'm afraid the reality=
 is that risk management will always be done locally.=C2=A0 And so it shoul=
d be.=C2=A0 When
 an RP is making=C2=A0the decision to accept or reject a given subject, the=
y will evaluate a range of attributes or=C2=A0signals.=C2=A0 The set of att=
ributes that matters varies from one RP to the next.=C2=A0 I think it's=
 a great idea indeed to create guidance for evaluating attributes,
 and to coach RPs to look at all sorts of dimensions.=C2=A0 I just don'=
t think it helps anyone to pigeonhole the risk ratings, because across orga=
nisations, arguments about the boundaries between LOA 1/2/3/4 (that is, pol=
icy mapping) will=C2=A0undo any efficiencies gained
 from the categorization. =C2=A0
    

    

    

    =C2=A0
    

    

    

    Cheers,=C2=A0
    

    

    

    =C2=A0
    

    

    

    Steve.
    

    

    

    =C2=A0
    

    

    

    =C2=A0
    

    

    

    Stephen Wilson
    
Managing Director
    
Lockstep Group
    
http://lockstep.com.a=
u
    
Lockstep Consulting provides independent specialist advice and analysis 
on digital identity and privacy. Lockstep Technologies develops unique 
    
new smart ID solutions that enhance privacy and prevent identity theft.
    

    

    

    =C2=A0
    

    

    

    =C2=A0
    

    

    

    =C2=A0
    

    

    

    

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

    

    =C2=A0
    

    

    

    


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

    

    =C2=A0
    

    

    

    

    

    

    

    =C2=A0
    

    

    

    


    

--001a1135e5ee0b1de80505ca6808--


From nobody Wed Oct 22 13:15:20 2014
Return-Path: 
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21D5E1A1AD5 for ; Wed, 22 Oct 2014 13:15:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.619
X-Spam-Level: 
X-Spam-Status: No, score=0.619 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_SE=0.35, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5Syhpido6Ay for ; Wed, 22 Oct 2014 13:15:06 -0700 (PDT)
Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (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 C703F1A1AD7 for ; Wed, 22 Oct 2014 13:15:05 -0700 (PDT)
Received: from smtp1.sunet.se (smtp1.sunet.se [IPv6:2001:6b0:8:2::214]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id s9MKF3gX032494 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 22 Oct 2014 22:15:03 +0200
Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.7/8.14.7) with ESMTP id s9MKF0nW013424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 22 Oct 2014 22:15:03 +0200 (CEST)
X-Footer: c3VuZXQuc2U=
Received: from [10.0.0.116] ([62.102.145.131]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.3.3) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256 bits)) for vot@ietf.org; Wed, 22 Oct 2014 22:14:59 +0200
Message-ID: <54481043.2090002@sunet.se>
Date: Wed, 22 Oct 2014 22:14:59 +0200
From: Leif Johansson 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: vot@ietf.org
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sunet-se:default, sunet-se:default, base:default, @@RPTN)
X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=62.0000; longitude=15.0000; http://maps.google.com/maps?q=62.0000,15.0000&z=6
X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default)
X-Canit-Stats-ID: 09N6kf3LO - 47e96cff64af - 20141022
X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw
X-Scanned-By: CanIt (www . roaringpenguin . com)
Archived-At: http://mailarchive.ietf.org/arch/msg/vot/wAsSqmyJQeWSs4aXOB42oz9kAIk
Subject: [VoT] Bar bof in hawaii?
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Vectors of Trust discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 20:15:09 -0000

Is anyone up for an informal discussion at the IETF meeting in Hawaii?
	
	Cheers Leif


From nobody Wed Oct 22 14:19:04 2014
Return-Path: 
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 618F61A1B34 for ; Wed, 22 Oct 2014 14:19:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O0IsEY1B53Fe for ; Wed, 22 Oct 2014 14:19:00 -0700 (PDT)
Received: from out41-ams.mf.surf.net (out41-ams.mf.surf.net [145.0.1.41]) (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 769F81A1B19 for ; Wed, 22 Oct 2014 14:19:00 -0700 (PDT)
Received: from teletubbie.het.net.je (teletubbie.het.net.je [192.87.110.29]) by outgoing2-ams.mf.surf.net (8.14.4/8.14.4/Debian-4) with ESMTP id s9MLIu85028741; Wed, 22 Oct 2014 23:18:57 +0200
Received: from [2001:420:109:1264:d9d2:1f57:5931:1138] by teletubbie.het.net.je with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1Xh3GM-000873-OB; Wed, 22 Oct 2014 23:16:10 +0200
Content-Type: multipart/signed; boundary="Apple-Mail=_BF916906-93E3-4A29-B47B-6FEEC88D82C3"; protocol="application/pgp-signature"; micalg=pgp-sha1
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Klaas Wierenga 
In-Reply-To: <54481043.2090002@sunet.se>
Date: Wed, 22 Oct 2014 14:18:28 -0700
Message-Id: <4829698E-1E0D-454E-8DD3-1F2731154F20@wierenga.net>
References: <54481043.2090002@sunet.se>
To: Leif Johansson 
X-Mailer: Apple Mail (2.1878.6)
X-Antivirus: no malware found
X-Bayes-Prob: 0.0001 (Score 0, tokens from: p-out:default, p:default, base:default, @@RPTN)
X-CanIt-Geo: ip=192.87.110.29; country=NL; latitude=52.5000; longitude=5.7500;  http://maps.google.com/maps?q=52.5000,5.7500&z=6
X-CanItPRO-Stream: p-out:default (inherits from p:default,base:default)
X-Canit-Stats-ID: 0vN6liUFr - 27684ec85ad7 - 20141022 (trained as not-spam)
X-Scanned-By: CanIt (www . roaringpenguin . com)
Archived-At: http://mailarchive.ietf.org/arch/msg/vot/DhmD2zbVL5AfYDxMFho17VwEp4k
Cc: vot@ietf.org
Subject: Re: [VoT] Bar bof in hawaii?
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Vectors of Trust discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 21:19:02 -0000

--Apple-Mail=_BF916906-93E3-4A29-B47B-6FEEC88D82C3
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii


On 22 Oct 2014, at 13:14, Leif Johansson  wrote:

> 
> Is anyone up for an informal discussion at the IETF meeting in Hawaii?

sure

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


--Apple-Mail=_BF916906-93E3-4A29-B47B-6FEEC88D82C3
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iEYEARECAAYFAlRIHyQACgkQH2Wy/p4XeFImQACgwhzZbUvKn895ARETFOs/kmTA
AG8An2JmWNDWpwU10lpehTt2UFyRDX6Q
=yF9n
-----END PGP SIGNATURE-----

--Apple-Mail=_BF916906-93E3-4A29-B47B-6FEEC88D82C3--


From nobody Wed Oct 22 14:20:13 2014
Return-Path: 
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AABF61A1B7C for ; Wed, 22 Oct 2014 14:20:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZvaybRbUculD for ; Wed, 22 Oct 2014 14:20:01 -0700 (PDT)
Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A39981A1B78 for ; Wed, 22 Oct 2014 14:20:01 -0700 (PDT)
Received: by mail-pd0-f172.google.com with SMTP id ft15so4262594pdb.17 for ; Wed, 22 Oct 2014 14:20:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=wZ15HT6YnKXZ7R7pgKQtyIeu45l39mgOOzUT7gDUx+g=; b=CwiVHir8RkTEyDo8IszIbMncVBm2EwRp16cAoJunje6UiYELAeO+Wt2zJDyD3g9TSz hIBJ2hjLc0FMNSN36RgY1i2OFBdmcHg/nwYA62SXDZytrnUQCacfTMaKGJlLGBi3vWt3 jcI73uNoKGftcMG0FLYjYRGCHleFCeaZJ2ETOA00BpAFlAyL3SIlztPmoNFhl+3uj8EE 2Pth6zIf6LCaF+pH5qz8Dx6W+gCVWTI1aEwRtd8RyoJ/cOXUCrFhxwGEmrV8OcDAluT4 OVn0zdhsQ8MC2zkhXkF7NDttp+710Kdf7S88C1q9gtotokSXlgfnzdCsRyJDHsk3lran CBpA==
X-Received: by 10.66.66.229 with SMTP id i5mr417222pat.137.1414012801292; Wed, 22 Oct 2014 14:20:01 -0700 (PDT)
Received: from Heathers-MacBook-Pro.local ([98.125.191.165]) by mx.google.com with ESMTPSA id f12sm15227469pat.36.2014.10.22.14.19.59 for  (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Oct 2014 14:20:00 -0700 (PDT)
Message-ID: <54481F8F.8020702@gmail.com>
Date: Wed, 22 Oct 2014 14:20:15 -0700
From: Heather Flanagan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: vot@ietf.org
References: <54481043.2090002@sunet.se>
In-Reply-To: <54481043.2090002@sunet.se>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/vot/W7PnX4xWF2dD84q-tJq_QDpgIek
Subject: Re: [VoT] Bar bof in hawaii?
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Vectors of Trust discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 21:20:05 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/22/14 1:14 PM, Leif Johansson wrote:
> 
> Is anyone up for an informal discussion at the IETF meeting in
> Hawaii?
> 

If I'm available during whatever time slot is chosen, I'll be there.

- -Heather


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJUSB+PAAoJEBTitMubYA+R5hkIAI7r9GBcAEv9z90HoENrK18r
OFfo9bJFZmMy7jOu+ppifYoKGoLVz2pNTw1uV6vFyKTJhstsfIprOrgqcIJLPG7I
lZAHJh4tEVqOKdnbP9nAF1ZOZrkWgxdaNIc6A8nt52Vj85wgqAFiD+J3BN3xlML/
AcVQ6LkGwDuaIArTNSYLBYrkw5T8TlvFNknoAhwaGpo769Qw843nodiCnY5iAjnv
UjoepXBkrirmB5UExc35nbILGWkHJkn2q8Rk2AvZhY5VCmOtEf8q424M/YRc+k+F
gqDso10L9b0fBPof3/XHCEVVA6lQC6055ZLBXv2VHHR0ZVOS396RWfxueOrG0AI=
=m/d5
-----END PGP SIGNATURE-----


From nobody Wed Oct 22 15:19:00 2014
Return-Path: 
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0280D1A1B4F for ; Wed, 22 Oct 2014 15:18:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A4XcDBuJsvof for ; Wed, 22 Oct 2014 15:18:55 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0068.outbound.protection.outlook.com [65.55.169.68]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD8DE1A1AFD for ; Wed, 22 Oct 2014 15:18:54 -0700 (PDT)
Received: from [192.168.1.138] (74.214.41.17) by DM2PR06MB591.namprd06.prod.outlook.com (10.141.176.154) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Wed, 22 Oct 2014 22:18:51 +0000
Message-ID: <54482D46.8070301@isoc.org>
Date: Wed, 22 Oct 2014 18:18:46 -0400
From: Karen ODonoghue 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: 
References: <54481043.2090002@sunet.se> <54481F8F.8020702@gmail.com>
In-Reply-To: <54481F8F.8020702@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [74.214.41.17]
X-ClientProxiedBy: BLUPR05CA0070.namprd05.prod.outlook.com (10.141.20.40) To DM2PR06MB591.namprd06.prod.outlook.com (10.141.176.154)
X-Microsoft-Antispam: UriScan:;
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR06MB591;
X-Exchange-Antispam-Report-Test: UriScan:;
X-Forefront-PRVS: 037291602B
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6009001)(6049001)(189002)(54524002)(199003)(479174003)(377454003)(24454002)(66066001)(64706001)(105586002)(47776003)(2351001)(107046002)(107886001)(102836001)(4396001)(101416001)(36756003)(33656002)(99396003)(83506001)(122386002)(64126003)(20776003)(19580395003)(65956001)(92566001)(106356001)(95666004)(15975445006)(19580405001)(42186005)(31966008)(80022003)(16601075003)(23756003)(76482002)(85306004)(59896002)(87976001)(21056001)(120916001)(87266999)(77096002)(54356999)(117156001)(99136001)(50466002)(15202345003)(86362001)(97736003)(85852003)(65816999)(76176999)(50986999)(92726001)(46102003)(575784001)(110136001)(40100003); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR06MB591; H:[192.168.1.138]; FPR:; MLV:sfv;  PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
X-OriginatorOrg: isoc.org
Archived-At: http://mailarchive.ietf.org/arch/msg/vot/fe93fol0h4Q-gLQwsOW9VgpM890
Subject: Re: [VoT] Bar bof in hawaii?
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Vectors of Trust discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 22:18:57 -0000

I'm interested/available depending on time slot clashes .

On 10/22/14, 5:20 PM, Heather Flanagan wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 10/22/14 1:14 PM, Leif Johansson wrote:
>> Is anyone up for an informal discussion at the IETF meeting in
>> Hawaii?
>>
> If I'm available during whatever time slot is chosen, I'll be there.
>
> - -Heather
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
> Comment: GPGTools - http://gpgtools.org
>
> iQEcBAEBAgAGBQJUSB+PAAoJEBTitMubYA+R5hkIAI7r9GBcAEv9z90HoENrK18r
> OFfo9bJFZmMy7jOu+ppifYoKGoLVz2pNTw1uV6vFyKTJhstsfIprOrgqcIJLPG7I
> lZAHJh4tEVqOKdnbP9nAF1ZOZrkWgxdaNIc6A8nt52Vj85wgqAFiD+J3BN3xlML/
> AcVQ6LkGwDuaIArTNSYLBYrkw5T8TlvFNknoAhwaGpo769Qw843nodiCnY5iAjnv
> UjoepXBkrirmB5UExc35nbILGWkHJkn2q8Rk2AvZhY5VCmOtEf8q424M/YRc+k+F
> gqDso10L9b0fBPof3/XHCEVVA6lQC6055ZLBXv2VHHR0ZVOS396RWfxueOrG0AI=
> =m/d5
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> vot mailing list
> vot@ietf.org
> https://www.ietf.org/mailman/listinfo/vot


From nobody Wed Oct 22 15:19:37 2014
Return-Path: 
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1A91A1B95 for ; Wed, 22 Oct 2014 15:19:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.791
X-Spam-Level: 
X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wo_5Uor0mXig for ; Wed, 22 Oct 2014 15:19:35 -0700 (PDT)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.246.244]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FCAC1A1B4F for ; Wed, 22 Oct 2014 15:19:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default;  h=Content-Type:MIME-Version:To:From:Message-ID:Subject:Date; bh=BBA5NA3LWDM4bwIjdHTjWuGGIO9E2MweUUtkVHIER8s=;  b=Gor3uAHRL2RNWLR6duuyEBn+6+XVOYTqv4/+854FpS/HofvlM2PzhIbV7sjR/D0Hf4UFw6a3KNkNBQ/UikOXwZFZwU2lSxlzROa4NKNFPsaSgGXVN0PjnZ1S6vJB7c3ijsr6ak2MltsIpWNGRazcCqPf+skYElD7AFztDL8eOHg=;
Received: from 185.sub-70-192-197.myvzw.com ([70.192.197.185]:5724 helo=[10.188.210.156]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.82) (envelope-from ) id 1Xh4Fc-0005Jy-4N; Wed, 22 Oct 2014 15:19:33 -0700
Date: Wed, 22 Oct 2014 18:19:27 -0400
Message-ID: 
Importance: normal
From: Eric Burger 
To: Heather Flanagan , vot@ietf.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--_com.android.email_12782451610190"
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Archived-At: http://mailarchive.ietf.org/arch/msg/vot/bWqfsZU4JdgjDSgx9yrobP-b89A
Subject: Re: [VoT] Bar bof in hawaii?
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Vectors of Trust discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 22:19:36 -0000

----_com.android.email_12782451610190
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64

U3VyZS4gSSdtIGdldHRpbmcgaW4gdmVyeSBsYXRlIGluIHRoZSB3ZWVrLCBzbyBkb24ndCB3YWl0
IGZvciBtZS7CoAoKClNlbnQgZnJvbSBteSBtb2JpbGUgZGV2aWNlLiBUaGFua3MgYmUgdG8gTEVN
T05BREU6IGh0dHA6Ly93d3cuc3RhbmRhcmRzdHJhY2suY29tL2lldGYvbGVtb25hZGUKCjxkaXY+
LS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLTwvZGl2PjxkaXY+RnJvbTogSGVhdGhl
ciBGbGFuYWdhbiA8aGxmbGFuYWdhbkBnbWFpbC5jb20+IDwvZGl2PjxkaXY+RGF0ZToxMC8yMi8y
MDE0ICA1OjIwIFBNICAoR01ULTA1OjAwKSA8L2Rpdj48ZGl2PlRvOiB2b3RAaWV0Zi5vcmcgPC9k
aXY+PGRpdj5TdWJqZWN0OiBSZTogW1ZvVF0gQmFyIGJvZiBpbiBoYXdhaWk/IDwvZGl2PjxkaXY+
CjwvZGl2Pi0tLS0tQkVHSU4gUEdQIFNJR05FRCBNRVNTQUdFLS0tLS0KSGFzaDogU0hBMQoKT24g
MTAvMjIvMTQgMToxNCBQTSwgTGVpZiBKb2hhbnNzb24gd3JvdGU6Cj4gCj4gSXMgYW55b25lIHVw
IGZvciBhbiBpbmZvcm1hbCBkaXNjdXNzaW9uIGF0IHRoZSBJRVRGIG1lZXRpbmcgaW4KPiBIYXdh
aWk/Cj4gCgpJZiBJJ20gYXZhaWxhYmxlIGR1cmluZyB3aGF0ZXZlciB0aW1lIHNsb3QgaXMgY2hv
c2VuLCBJJ2xsIGJlIHRoZXJlLgoKLSAtSGVhdGhlcgoKCi0tLS0tQkVHSU4gUEdQIFNJR05BVFVS
RS0tLS0tClZlcnNpb246IEdudVBHL01hY0dQRzIgdjIuMC4yMiAoRGFyd2luKQpDb21tZW50OiBH
UEdUb29scyAtIGh0dHA6Ly9ncGd0b29scy5vcmcKCmlRRWNCQUVCQWdBR0JRSlVTQitQQUFvSkVC
VGl0TXViWUErUjVoa0lBSTdyOUdCY0FFdjl6OTBIb0VOcksxOHIKT0ZmbzliSkZabU15N2pPdStw
cGlmWW9LR29MVnoycE5UdzF1VjZ2RnlLVEpoc3RzZklwck9yZ3FjSUpMUEc3SQpsWkFISmg0dEVW
cU9LZG5iUDluQUYxWk9acmtXZ3hkYU5JYzZBOG50NTJWajg1d2dxQUZpRCtKM0JOM3hsTUwvCkFj
VlE2TGtHd0R1YUlBclROU1lMQllya3c1VDhUbHZGTmtub0Fod2FHcG83NjlRdzg0M25vZGlDblk1
aUFqbnYKVWpvZXBYQmtyaXJtQjVVRXhjMzVuYklMR1drSEprbjJxOFJrMkF2WmhZNVZDbU90RWY4
cTQyNE0vWVJjK2srRgpncURzbzEwTDliMGZCUG9mMy9YSENFVlZBNmxRQzYwNTVaTEJYdjJWSEhS
MFpWT1MzOTZSV2Z4dWVPckcwQUk9Cj1tL2Q1Ci0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQoK
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18Kdm90IG1haWxp
bmcgbGlzdAp2b3RAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by92b3QK

----_com.android.email_12782451610190
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64

PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0
L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+PGRpdj5TdXJlLiBJJ20gZ2V0dGlu
ZyBpbiB2ZXJ5IGxhdGUgaW4gdGhlIHdlZWssIHNvIGRvbid0IHdhaXQgZm9yIG1lLiZuYnNwOzwv
ZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PlNlbnQgZnJvbSBteSBtb2JpbGUgZGV2
aWNlLiBUaGFua3MgYmUgdG8gTEVNT05BREU6IGh0dHA6Ly93d3cuc3RhbmRhcmRzdHJhY2suY29t
L2lldGYvbGVtb25hZGU8YnI+PGJyPjxkaXY+LS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0t
LS0tLTwvZGl2PjxkaXY+RnJvbTogSGVhdGhlciBGbGFuYWdhbiA8aGxmbGFuYWdhbkBnbWFpbC5j
b20+IDwvZGl2PjxkaXY+RGF0ZToxMC8yMi8yMDE0ICA1OjIwIFBNICAoR01ULTA1OjAwKSA8L2Rp
dj48ZGl2PlRvOiB2b3RAaWV0Zi5vcmcgPC9kaXY+PGRpdj5TdWJqZWN0OiBSZTogW1ZvVF0gQmFy
IGJvZiBpbiBoYXdhaWk/IDwvZGl2PjxkaXY+PGJyPjwvZGl2Pi0tLS0tQkVHSU4gUEdQIFNJR05F
RCBNRVNTQUdFLS0tLS08YnI+SGFzaDogU0hBMTxicj48YnI+T24gMTAvMjIvMTQgMToxNCBQTSwg
TGVpZiBKb2hhbnNzb24gd3JvdGU6PGJyPiZndDsgPGJyPiZndDsgSXMgYW55b25lIHVwIGZvciBh
biBpbmZvcm1hbCBkaXNjdXNzaW9uIGF0IHRoZSBJRVRGIG1lZXRpbmcgaW48YnI+Jmd0OyBIYXdh
aWk/PGJyPiZndDsgPGJyPjxicj5JZiBJJ20gYXZhaWxhYmxlIGR1cmluZyB3aGF0ZXZlciB0aW1l
IHNsb3QgaXMgY2hvc2VuLCBJJ2xsIGJlIHRoZXJlLjxicj48YnI+LSAtSGVhdGhlcjxicj48YnI+
PGJyPi0tLS0tQkVHSU4gUEdQIFNJR05BVFVSRS0tLS0tPGJyPlZlcnNpb246IEdudVBHL01hY0dQ
RzIgdjIuMC4yMiAoRGFyd2luKTxicj5Db21tZW50OiBHUEdUb29scyAtIGh0dHA6Ly9ncGd0b29s
cy5vcmc8YnI+PGJyPmlRRWNCQUVCQWdBR0JRSlVTQitQQUFvSkVCVGl0TXViWUErUjVoa0lBSTdy
OUdCY0FFdjl6OTBIb0VOcksxOHI8YnI+T0ZmbzliSkZabU15N2pPdStwcGlmWW9LR29MVnoycE5U
dzF1VjZ2RnlLVEpoc3RzZklwck9yZ3FjSUpMUEc3STxicj5sWkFISmg0dEVWcU9LZG5iUDluQUYx
Wk9acmtXZ3hkYU5JYzZBOG50NTJWajg1d2dxQUZpRCtKM0JOM3hsTUwvPGJyPkFjVlE2TGtHd0R1
YUlBclROU1lMQllya3c1VDhUbHZGTmtub0Fod2FHcG83NjlRdzg0M25vZGlDblk1aUFqbnY8YnI+
VWpvZXBYQmtyaXJtQjVVRXhjMzVuYklMR1drSEprbjJxOFJrMkF2WmhZNVZDbU90RWY4cTQyNE0v
WVJjK2srRjxicj5ncURzbzEwTDliMGZCUG9mMy9YSENFVlZBNmxRQzYwNTVaTEJYdjJWSEhSMFpW
T1MzOTZSV2Z4dWVPckcwQUk9PGJyPj1tL2Q1PGJyPi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0t
LTxicj48YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188
YnI+dm90IG1haWxpbmcgbGlzdDxicj52b3RAaWV0Zi5vcmc8YnI+aHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby92b3Q8YnI+PC9ib2R5Pg==

----_com.android.email_12782451610190--



From nobody Wed Oct 22 15:25:35 2014
Return-Path: 
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4984C1A8765 for ; Wed, 22 Oct 2014 15:25:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ABxQLDoqAN4 for ; Wed, 22 Oct 2014 15:25:30 -0700 (PDT)
Received: from hans.rg.net (hans.rg.net [IPv6:2001:418:1::42]) by ietfa.amsl.com (Postfix) with ESMTP id B5ECA1A87A8 for ; Wed, 22 Oct 2014 15:25:30 -0700 (PDT)
Received: from hans.rg.net (hans.rg.net [IPv6:2001:418:1::42]) (authenticated bits=0) by hans.rg.net (8.14.9/8.14.7) with ESMTP id s9MMPT3x015216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Oct 2014 22:25:29 GMT (envelope-from llynch@civil-tongue.net)
Date: Wed, 22 Oct 2014 22:25:29 +0000 (UTC)
From: Lucy Lynch 
X-X-Sender: llynch@hans.rg.net
To: Leif Johansson 
In-Reply-To: <54481043.2090002@sunet.se>
Message-ID: 
References: <54481043.2090002@sunet.se>
User-Agent: Alpine 2.11 (BSF 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Archived-At: http://mailarchive.ietf.org/arch/msg/vot/2COQ8XHctYfXKmfd7wLbaLAZQy8
Cc: vot@ietf.org
Subject: Re: [VoT] Bar bof in hawaii?
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Vectors of Trust discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 22:25:32 -0000

On Wed, 22 Oct 2014, Leif Johansson wrote:

>
> Is anyone up for an informal discussion at the IETF meeting in Hawaii?

count me in - and I'm counting on a real bar - with umbrella drinks!

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


From nobody Wed Oct 22 16:24:28 2014
Return-Path: 
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E8A61A8781 for ; Wed, 22 Oct 2014 16:24:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-JRnytwz9Be for ; Wed, 22 Oct 2014 16:24:24 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0077.outbound.protection.outlook.com [65.55.169.77]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDE361A874C for ; Wed, 22 Oct 2014 16:24:23 -0700 (PDT)
Received: from BLUPR06MB243.namprd06.prod.outlook.com (10.242.191.154) by BLUPR06MB241.namprd06.prod.outlook.com (10.242.191.148) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Wed, 22 Oct 2014 23:24:21 +0000
Received: from BLUPR06MB243.namprd06.prod.outlook.com ([169.254.7.100]) by BLUPR06MB243.namprd06.prod.outlook.com ([169.254.7.100]) with mapi id 15.00.1054.004; Wed, 22 Oct 2014 23:24:20 +0000
From: Steve Olshansky 
To: "vot@ietf.org" 
Thread-Topic: [VoT] Bar bof in hawaii?
Thread-Index: AQHP7jTp/eMWbLrjRkOzVRMdWyW6d5w8scGAgAAQcQA=
Date: Wed, 22 Oct 2014 23:24:20 +0000
Message-ID: <69AA9C73-6D7A-4D35-BEEA-351F07451A89@isoc.org>
References: <54481043.2090002@sunet.se> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [70.59.7.227]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB241;
x-exchange-antispam-report-test: UriScan:;
x-forefront-prvs: 037291602B
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(189002)(377454003)(199003)(24454002)(19580395003)(19580405001)(46102003)(97736003)(2501002)(87936001)(2656002)(15975445006)(33656002)(101416001)(66066001)(64706001)(20776003)(36756003)(110136001)(50986999)(99936001)(120916001)(107046002)(2351001)(107886001)(76176999)(77096002)(99396003)(106356001)(92726001)(92566001)(31966008)(54356999)(85852003)(4396001)(85306004)(122556002)(80022003)(105586002)(21056001)(99286002)(106116001)(86362001)(95666004)(40100003)(76482002)(15974865002)(104396001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB241; H:BLUPR06MB243.namprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
Content-Type: multipart/signed; boundary="Apple-Mail=_7C9AA813-E4E2-43DA-9B89-295462A21CB4"; protocol="application/pgp-signature"; micalg=pgp-sha1
MIME-Version: 1.0
X-OriginatorOrg: isoc.org
Archived-At: http://mailarchive.ietf.org/arch/msg/vot/7cEoOYeeRlul5GXSY07F8lK2Oq0
Subject: Re: [VoT] Bar bof in hawaii?
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Vectors of Trust discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Oct 2014 23:24:26 -0000

--Apple-Mail=_7C9AA813-E4E2-43DA-9B89-295462A21CB4
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii

I am in as well, barring conflicts I cannot dodge.
	Steve

--
Steve Olshansky
Trust & Identity Program Lead
Internet Society
www.internetsociety.org

On Oct 22, 2014, at 4:25 PM, Lucy Lynch  wrote:

> On Wed, 22 Oct 2014, Leif Johansson wrote:
> 
>> 
>> Is anyone up for an informal discussion at the IETF meeting in Hawaii?
> 
> count me in - and I'm counting on a real bar - with umbrella drinks!
> 
>> 	Cheers Leif
>> 
>> _______________________________________________
>> vot mailing list
>> vot@ietf.org
>> https://www.ietf.org/mailman/listinfo/vot
>> 
>> 
> 
> _______________________________________________
> vot mailing list
> vot@ietf.org
> https://www.ietf.org/mailman/listinfo/vot


--Apple-Mail=_7C9AA813-E4E2-43DA-9B89-295462A21CB4
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="signature.asc"
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----

iQEcBAEBAgAGBQJUSDykAAoJEOJO4+877g3HnEQIAIhQdRVzi8EtJuC7xj5V4aJl
ol8cDODGjEEEBwzUd28oKGmx5wVctLHjZ39RBEvkwOR3/GcC+/0KoBdV2rZnK7tX
XUeuOi0tY5IkDeR3KF4IkrOiVz3OJkK+YzHJTFVF89yg78DdCx2FptCMCCGS/po5
o9OtO8mUGoKD3SvDfjThUCx/maHKE79HGzdakFNRihu3q+GC0fBWQk/k5Hy0LNKc
YaHSamPgU++hRhlVwAUnjrxndDnRgm45nBIZGrsBanVyjEVkweD7b9u/S+Y4DutJ
zdprwat3GqCBB2ffDGHWcRGwBy0gRMdPBp0/0Nk/k6b0eCfYCzKa+B5QlMKwenI=
=QZfv
-----END PGP SIGNATURE-----

--Apple-Mail=_7C9AA813-E4E2-43DA-9B89-295462A21CB4--


From nobody Wed Oct 22 23:51:20 2014
Return-Path: 
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 708941A8908 for ; Wed, 22 Oct 2014 23:51:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.619
X-Spam-Level: 
X-Spam-Status: No, score=0.619 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_SE=0.35, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BqDhxmmnLkl5 for ; Wed, 22 Oct 2014 23:51:17 -0700 (PDT)
Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (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 D5B7B1A88E5 for ; Wed, 22 Oct 2014 23:51:16 -0700 (PDT)
Received: from smtp1.sunet.se (smtp1.sunet.se [IPv6:2001:6b0:8:2::214]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id s9N6pESQ001040 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 23 Oct 2014 08:51:14 +0200
Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.7/8.14.7) with ESMTP id s9N6pCHc026728 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 23 Oct 2014 08:51:14 +0200 (CEST)
X-Footer: c3VuZXQuc2U=
Received: from [193.10.94.8] ([193.10.94.8]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.3.3) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256 bits)) for vot@ietf.org; Thu, 23 Oct 2014 08:51:10 +0200
Message-ID: <5448A55E.10200@sunet.se>
Date: Thu, 23 Oct 2014 08:51:10 +0200
From: Leif Johansson 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: vot@ietf.org
References: <54481043.2090002@sunet.se>
In-Reply-To: <54481043.2090002@sunet.se>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sunet-se:default, sunet-se:default, base:default, @@RPTN)
X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=62.0000; longitude=15.0000; http://maps.google.com/maps?q=62.0000,15.0000&z=6
X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default)
X-Canit-Stats-ID: 09N6uPeUC - 9844fa13828c - 20141023
X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw
X-Scanned-By: CanIt (www . roaringpenguin . com)
Archived-At: http://mailarchive.ietf.org/arch/msg/vot/m0yhf9Om420-SXYMQFe40lkt3rs
Subject: Re: [VoT] Bar bof in hawaii?
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Vectors of Trust discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Oct 2014 06:51:18 -0000

On 2014-10-22 22:14, Leif Johansson wrote:
> 
> Is anyone up for an informal discussion at the IETF meeting in Hawaii?
> 	

so when would be a good time? unless folks are planning to attend the
social, the hotel bar will probably be less full than usual that night..


From nobody Thu Oct 23 04:30:13 2014
Return-Path: 
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34C181A8AC2 for ; Thu, 23 Oct 2014 04:30:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOYxu4QC9A4c for ; Thu, 23 Oct 2014 04:30:10 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0656.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::656]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 744FF1A8AC1 for ; Thu, 23 Oct 2014 04:30:10 -0700 (PDT)
Received: from BN1PR06MB119.namprd06.prod.outlook.com (10.255.204.25) by BN1PR06MB118.namprd06.prod.outlook.com (10.255.204.20) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Thu, 23 Oct 2014 11:29:45 +0000
Received: from BN1PR06MB119.namprd06.prod.outlook.com ([169.254.14.200]) by BN1PR06MB119.namprd06.prod.outlook.com ([169.254.14.200]) with mapi id 15.00.1054.004; Thu, 23 Oct 2014 11:29:45 +0000
From: Robin Wilton 
To: "vot@ietf.org" 
Thread-Topic: vot Digest, Vol 2, Issue 24
Thread-Index: AQHP7k9XtfhezFxL40ClupFTOUb/Mpw9jP+A
Date: Thu, 23 Oct 2014 11:29:45 +0000
Message-ID: <70E8358B-EC84-4780-92BD-F5E457B4CE52@isoc.org>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [94.174.34.240]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR06MB118;
x-exchange-antispam-report-test: UriScan:;
x-forefront-prvs: 0373D94D15
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(51414003)(189002)(10533002)(199003)(18543002)(5403001)(110136001)(107886001)(106116001)(64706001)(31966008)(2351001)(4396001)(95666004)(20776003)(77096002)(107046002)(105586002)(66066001)(2656002)(83716003)(122556002)(40100003)(76176999)(54356999)(99936001)(82746002)(21056001)(50986999)(46102003)(33656002)(85306004)(80022003)(92566001)(85852003)(86362001)(106356001)(120916001)(99286002)(87936001)(99396003)(36756003)(76482002)(2501002)(92726001)(101416001)(97736003)(558084003)(104396001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR06MB118; H:BN1PR06MB119.namprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:3; A:1; LANG:en; 
Content-Type: multipart/signed; boundary="Apple-Mail=_09E26862-2D4D-403C-9FC3-CA54CD0AB5BE"; protocol="application/pgp-signature"; micalg=pgp-sha1
MIME-Version: 1.0
X-OriginatorOrg: isoc.org
Archived-At: http://mailarchive.ietf.org/arch/msg/vot/MIB7ODdXl2aTRzf8MUkU83tHXPU
Subject: Re: [VoT] vot Digest, Vol 2, Issue 24
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Vectors of Trust discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Oct 2014 11:30:12 -0000

--Apple-Mail=_09E26862-2D4D-403C-9FC3-CA54CD0AB5BE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Really sorry I won=92t be there.

I look forward to an equally paradisical bar-BoF in=85 ?Dallas? *cough*

--Apple-Mail=_09E26862-2D4D-403C-9FC3-CA54CD0AB5BE
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="signature.asc"
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----

iEYEARECAAYFAlRI5u8ACgkQx1kEWLxmyT2TrQCdEauZqq0fafZPE8g8m4wGeXU2
M90Anjtoar5YNElpkIfgNSDhIk0QEqHZ
=eKLo
-----END PGP SIGNATURE-----

--Apple-Mail=_09E26862-2D4D-403C-9FC3-CA54CD0AB5BE--


From nobody Thu Oct 23 07:08:53 2014
Return-Path: 
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 409841A90E3 for ; Thu, 23 Oct 2014 07:08:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sj79Qbnc0LNa for ; Thu, 23 Oct 2014 07:08:29 -0700 (PDT)
Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id 20DF41A8AFE for ; Thu, 23 Oct 2014 07:08:28 -0700 (PDT)
Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9597BB2F8BD; Thu, 23 Oct 2014 10:08:27 -0400 (EDT)
Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id 8C0A6B2F8BB; Thu, 23 Oct 2014 10:08:27 -0400 (EDT)
Received: from IMCMBX01.MITRE.ORG ([169.254.1.78]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.03.0174.001; Thu, 23 Oct 2014 10:08:27 -0400
From: "Richer, Justin P." 
To: Leif Johansson 
Thread-Topic: [VoT] Bar bof in hawaii?
Thread-Index: AQHP7jTmhT4eFOiLH0C5EuJX/PxB0pw9/EiA
Date: Thu, 23 Oct 2014 14:08:26 +0000
Message-ID: <70695956-9072-4646-BE24-1C915046353E@mitre.org>
References: <54481043.2090002@sunet.se>
In-Reply-To: <54481043.2090002@sunet.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.63.245]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <6E8C04CF8812A648A375634180FDB570@imc.mitre.org>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/vot/52fe2HUjtXdcRaPj2tBP_ty2ulA
Cc: "vot@ietf.org" 
Subject: Re: [VoT] Bar bof in hawaii?
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Vectors of Trust discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Oct 2014 14:08:42 -0000

Sounds like a good idea, I'll be there.

 -- Justin

On Oct 22, 2014, at 4:14 PM, Leif Johansson  wrote:

>=20
> Is anyone up for an informal discussion at the IETF meeting in Hawaii?
> =09
> 	Cheers Leif
>=20
> _______________________________________________
> vot mailing list
> vot@ietf.org
> https://www.ietf.org/mailman/listinfo/vot


From nobody Thu Oct 23 10:25:57 2014
Return-Path: 
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 457BB1ACDA8 for ; Thu, 23 Oct 2014 10:25:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PYgS2LXe2EVJ for ; Thu, 23 Oct 2014 10:25:48 -0700 (PDT)
Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B5611ACD9C for ; Thu, 23 Oct 2014 10:25:47 -0700 (PDT)
Received: by mail-pd0-f180.google.com with SMTP id fp1so1400614pdb.11 for ; Thu, 23 Oct 2014 10:25:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=WSHkYVOdrhZjghvG3qb8+0po076J5Y/ROC57Q2A97RM=; b=OSAM/nMM7cHk3+huQ/hP3pMFGWdWmxAHqjanGW2mjQVWvOd/Aab4on1eYSUPcih19Q UoE1T/sFUlJtKTt5F4wal5f7Spy37alzn4l9h5CS2fHxAFyNWop9fR+b/SLdpAxjDnmC KPiTGrgzxV/QF1KRS2QwQpiTV+8CcOfTK2HKkpJ5hNk9QuV7pTbqLEuKtwXnxv0Ukx2N scGMVSk0AU8AX8O3j34IoXqDPq4OigdPTyNr/MUg1Wu2E80+50diTTGgTO6g19iNAsDW 5D2RH7brURlB9hV4GbjzpfVkAzJlHD6Zfkq5CWaiKmoIrnkxVwK2Iv0Lc/USBq5eViVk vogA==
X-Received: by 10.70.15.228 with SMTP id a4mr6336934pdd.77.1414085145686; Thu, 23 Oct 2014 10:25:45 -0700 (PDT)
Received: from Heathers-MacBook-Pro.local ([98.125.191.165]) by mx.google.com with ESMTPSA id uw1sm2010894pab.30.2014.10.23.10.25.44 for  (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Oct 2014 10:25:44 -0700 (PDT)
Message-ID: <54493A2A.3080008@gmail.com>
Date: Thu, 23 Oct 2014 10:26:02 -0700
From: Heather Flanagan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: vot@ietf.org
References: <54481043.2090002@sunet.se> <5448A55E.10200@sunet.se>
In-Reply-To: <5448A55E.10200@sunet.se>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/vot/5gOCHHrWcqJOURMROk5H3R26Iy8
Subject: Re: [VoT] Bar bof in hawaii?
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Vectors of Trust discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Oct 2014 17:25:53 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/22/14 11:51 PM, Leif Johansson wrote:
> On 2014-10-22 22:14, Leif Johansson wrote:
>> 
>> Is anyone up for an informal discussion at the IETF meeting in
>> Hawaii? 
> 
> so when would be a good time? unless folks are planning to attend
> the social, the hotel bar will probably be less full than usual
> that night..
> 

After the Admin plenary on Wednesday?  After an hour or so of luau on
Tuesday?

- -Heather


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJUSToqAAoJEBTitMubYA+RO/IH/1YJlvvO47qVnirNV+7D+DE6
+dZyc54NiYj+uU3PRdLWU9fo2Prw8ubccxEEaNAVhq/ttUU4yj5AT0/f58QD+vmz
YdRKJyRp2+Y8VP607b37SKcCPrAYd9wOtmp5qxs7GdcnF9ydKKw3pYTv1QOdA1jx
IryPeqlBhOZq/jA1j7ksxPASEVsjK4b3tNmxe7cX+vHerdefLhdJSLxmYBRlrpr9
XidYhLR95VEd8KfxqmVaBBbvF2+ocUMey7YCjrwOnRx86mkskDjszI8mCE8DyiVW
YU1C0CO6BDlb9f8OHifaOGrYI0GCfsybFpRyqnbRdV3pNN0r1RUf0I1NigHsjMk=
=SqHy
-----END PGP SIGNATURE-----


From nobody Thu Oct 23 10:27:49 2014
Return-Path: 
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFE7F1ACD46 for ; Thu, 23 Oct 2014 10:27:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VXnWDBN6BS3m for ; Thu, 23 Oct 2014 10:27:45 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0713.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::713]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 059A51AD424 for ; Thu, 23 Oct 2014 10:27:40 -0700 (PDT)
Received: from BLUPR09MB0165.namprd09.prod.outlook.com (10.255.216.19) by BLUPR09MB0165.namprd09.prod.outlook.com (10.255.216.19) with Microsoft SMTP Server (TLS) id 15.0.1054.13; Thu, 23 Oct 2014 17:27:17 +0000
Received: from BLUPR09MB0165.namprd09.prod.outlook.com ([10.255.216.19]) by BLUPR09MB0165.namprd09.prod.outlook.com ([10.255.216.19]) with mapi id 15.00.1054.004; Thu, 23 Oct 2014 17:27:17 +0000
From: "Grassi, Paul A." 
To: Heather Flanagan 
Thread-Topic: [VoT] Bar bof in hawaii?
Thread-Index: AQHP7jTomdLcgF3kVU2eFlH4gPf4n5w9PwoAgACxYQCAAABaoQ==
Date: Thu, 23 Oct 2014 17:27:17 +0000
Message-ID: <30709F91-519C-49C1-B163-FF1B30D93F6E@nist.gov>
References: <54481043.2090002@sunet.se> <5448A55E.10200@sunet.se>,<54493A2A.3080008@gmail.com>
In-Reply-To: <54493A2A.3080008@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [2600:1003:b116:b3bb:5b9:a4ea:3ac1:3f48]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR09MB0165;
x-exchange-antispam-report-test: UriScan:;
x-forefront-prvs: 0373D94D15
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(189002)(377424004)(24454002)(199003)(479174003)(377454003)(110136001)(95666004)(83716003)(4396001)(97736003)(15202345003)(122556002)(40100003)(99396003)(82746002)(85306004)(120916001)(15975445006)(76482002)(16601075003)(1411001)(87936001)(575784001)(99286002)(2656002)(92726001)(107046002)(92566001)(33656002)(105586002)(106356001)(21056001)(101416001)(19580405001)(19580395003)(106116001)(54356999)(20776003)(86362001)(46102003)(80022003)(31966008)(50986999)(76176999)(36756003)(85852003)(64706001)(104396001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR09MB0165; H:BLUPR09MB0165.namprd09.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
Archived-At: http://mailarchive.ietf.org/arch/msg/vot/DHjAyzHa3LYMDzh-P3qOM72bv58
Cc: "vot@ietf.org" 
Subject: Re: [VoT] Bar bof in hawaii?
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Vectors of Trust discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Oct 2014 17:27:47 -0000

You guys are making me jealous. =20

> On Oct 23, 2014, at 1:26 PM, "Heather Flanagan"  wr=
ote:
>=20
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>=20
>> On 10/22/14 11:51 PM, Leif Johansson wrote:
>>> On 2014-10-22 22:14, Leif Johansson wrote:
>>>=20
>>> Is anyone up for an informal discussion at the IETF meeting in
>>> Hawaii?
>>=20
>> so when would be a good time? unless folks are planning to attend
>> the social, the hotel bar will probably be less full than usual
>> that night..
>=20
> After the Admin plenary on Wednesday?  After an hour or so of luau on
> Tuesday?
>=20
> - -Heather
>=20
>=20
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
> Comment: GPGTools - http://gpgtools.org
>=20
> iQEcBAEBAgAGBQJUSToqAAoJEBTitMubYA+RO/IH/1YJlvvO47qVnirNV+7D+DE6
> +dZyc54NiYj+uU3PRdLWU9fo2Prw8ubccxEEaNAVhq/ttUU4yj5AT0/f58QD+vmz
> YdRKJyRp2+Y8VP607b37SKcCPrAYd9wOtmp5qxs7GdcnF9ydKKw3pYTv1QOdA1jx
> IryPeqlBhOZq/jA1j7ksxPASEVsjK4b3tNmxe7cX+vHerdefLhdJSLxmYBRlrpr9
> XidYhLR95VEd8KfxqmVaBBbvF2+ocUMey7YCjrwOnRx86mkskDjszI8mCE8DyiVW
> YU1C0CO6BDlb9f8OHifaOGrYI0GCfsybFpRyqnbRdV3pNN0r1RUf0I1NigHsjMk=3D
> =3DSqHy
> -----END PGP SIGNATURE-----
>=20
> _______________________________________________
> vot mailing list
> vot@ietf.org
> https://www.ietf.org/mailman/listinfo/vot


From nobody Thu Oct 23 12:15:52 2014
Return-Path: 
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C96BD1ACDBC for ; Thu, 23 Oct 2014 12:15:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level: 
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TlLCC2prnRgH for ; Thu, 23 Oct 2014 12:15:49 -0700 (PDT)
Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BD0D1ACD58 for ; Thu, 23 Oct 2014 12:15:48 -0700 (PDT)
Received: by mail-wg0-f49.google.com with SMTP id x12so1826690wgg.8 for ; Thu, 23 Oct 2014 12:15:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=caZ98piIVpiVHlDnNmPN3TwI0cztQ6MyrpRhiK8LLHk=; b=mEl1Z25CNGLtLHpEHoOKCHd5NmrygYCKNl+GzQH0EeWDOZNRoz+JWcop414SxM2h26 VoORUP1zISkUK8TsFh6YfaIvq25319apGxvpYxaltw8tcY8fzG13qit3JxhWL+PHZjye JGVm63YELlrNpwTftraKvD988W9DZHOThWMcRLQhWOMmotlo5UOR27vw6zlDh10MOI7X jBPoiIOY0exn7OVSbeNoPixmE1S6t03hpgzVJcH3cLZ1Pt4DzKtnoFvAep4iPAVA9uR7 ohmgW3XUyucLFlE7cDo7YKiocEGbOUcoJw8OAkeBGZbJnrezYBTyty4Ce0N2E7JsPb/Z u69A==
X-Received: by 10.194.143.8 with SMTP id sa8mr5114188wjb.130.1414091747673; Thu, 23 Oct 2014 12:15:47 -0700 (PDT)
MIME-Version: 1.0
Sender: jonibrennan@gmail.com
Received: by 10.216.113.74 with HTTP; Thu, 23 Oct 2014 12:15:17 -0700 (PDT)
In-Reply-To: <70E8358B-EC84-4780-92BD-F5E457B4CE52@isoc.org>
References:  <70E8358B-EC84-4780-92BD-F5E457B4CE52@isoc.org>
From: Joni Brennan 
Date: Thu, 23 Oct 2014 12:15:17 -0700
X-Google-Sender-Auth: LgoyIFEs53PU-y8oaI7_UfsUtLw
Message-ID: 
To: Robin Wilton 
Content-Type: multipart/alternative; boundary=089e0122ef044cd14705061be469
Archived-At: http://mailarchive.ietf.org/arch/msg/vot/62kyuNsKEGhweQAZ3fX6y9lGmEk
Cc: "vot@ietf.org" 
Subject: Re: [VoT] vot Digest, Vol 2, Issue 24
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Vectors of Trust discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Oct 2014 19:15:51 -0000

--089e0122ef044cd14705061be469
Content-Type: text/plain; charset=ISO-8859-1

I too am sorry that I won't be there.  Robin and I may meet at the virtual
skype-bar in the interim.

Have a great meeting.

Best Regards,

Joni Brennan
Kantara Initiative | Executive Director
voice:+1 732-266-8994
email: joni @ kantarainitiative.org

Connecting Identity for a more trustworthy Internet - Overview





On Thu, Oct 23, 2014 at 4:29 AM, Robin Wilton  wrote:

> Really sorry I won't be there.
>
> I look forward to an equally paradisical bar-BoF in... ?Dallas? *cough*
>
> _______________________________________________
> vot mailing list
> vot@ietf.org
> https://www.ietf.org/mailman/listinfo/vot
>
>

--089e0122ef044cd14705061be469
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


    I too am sorry that I won't be there.  Robin and =
I may meet at the virtual skype-bar in the interim.  

    Have a gr=
eat meeting. 

    Best Regards,

    Joni Bren=
nan
    Kantara Initiative | Executive Director
    voice:+1 732-266-8994
    =
email: joni @ ka=
ntarainitiative.org

    Connecting Identity for a more trustwo=
rthy Internet - Overview

    


    

    On Thu, Oct 23, 2014 at 4:29 AM, Robin Wilto=
n <wilton@isoc.org> wrote:
    R=
eally sorry I won’t be there.
    

    
I look forward to an equally paradisical bar-BoF in… ?Dallas? *cough=
*
    

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


    

--089e0122ef044cd14705061be469--


From nobody Thu Oct 23 12:16:25 2014
Return-Path: 
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 396471ACE6E for ; Thu, 23 Oct 2014 12:16:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.781
X-Spam-Level: 
X-Spam-Status: No, score=-0.781 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QgWRMxcfaQkd for ; Thu, 23 Oct 2014 12:16:22 -0700 (PDT)
Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (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 802F61ACD58 for ; Thu, 23 Oct 2014 12:16:22 -0700 (PDT)
Received: from smtp1.sunet.se (smtp1.sunet.se [IPv6:2001:6b0:8:2::214]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id s9NJGKwL027940 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 23 Oct 2014 21:16:20 +0200
Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.7/8.14.7) with ESMTP id s9NJGHQ0019627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 23 Oct 2014 21:16:20 +0200 (CEST)
X-Footer: c3VuZXQuc2U=
Received: from [10.0.0.116] ([62.102.145.131]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.3.3) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256 bits)) for vot@ietf.org; Thu, 23 Oct 2014 21:16:16 +0200
Message-ID: <54495400.3070203@sunet.se>
Date: Thu, 23 Oct 2014 21:16:16 +0200
From: Leif Johansson 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: vot@ietf.org
References: <54481043.2090002@sunet.se> <5448A55E.10200@sunet.se>, <54493A2A.3080008@gmail.com> <30709F91-519C-49C1-B163-FF1B30D93F6E@nist.gov>
In-Reply-To: <30709F91-519C-49C1-B163-FF1B30D93F6E@nist.gov>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sunet-se:default, sunet-se:default, base:default, @@RPTN)
X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=62.0000; longitude=15.0000; http://maps.google.com/maps?q=62.0000,15.0000&z=6
X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default)
X-Canit-Stats-ID: 09N6HgkA5 - d8f99ecab224 - 20141023
X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw
X-Scanned-By: CanIt (www . roaringpenguin . com)
Archived-At: http://mailarchive.ietf.org/arch/msg/vot/hBgd_0wPEF9x_4gWk2XOaS56his
Subject: Re: [VoT] Bar bof in hawaii?
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Vectors of Trust discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Oct 2014 19:16:24 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2014-10-23 19:27, Grassi, Paul A. wrote:
> You guys are making me jealous.
> 

We're saving you a seat Paul ...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAlRJVAAACgkQ8Jx8FtbMZnfxoACeNBHS9/IzYr8lbsEUmIlzvAln
H68AoMF+Ir4EbCORrK0mlWJyEYHvHDJN
=HT/h
-----END PGP SIGNATURE-----


From nobody Fri Oct 24 01:22:36 2014
Return-Path: 
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43FF91A891E for ; Fri, 24 Oct 2014 01:22:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z2-tzNUScjME for ; Fri, 24 Oct 2014 01:22:31 -0700 (PDT)
Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AC831AD5A5 for ; Fri, 24 Oct 2014 01:22:31 -0700 (PDT)
Received: by mail-wg0-f47.google.com with SMTP id x13so544246wgg.18 for ; Fri, 24 Oct 2014 01:22:30 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=nveNjXR3yUOZpQED53clo8nvfcObqmZmAYV/kWNn1xk=; b=d5CS+ZjAmPAwcVn6qL46Yirb/Dpagc8IuUNJsliU/6K3rjdIFfD07Hx9qUwM1jnDyR iZIRqN+SbLDi+Dz7l85PWAqOn5cfDwxVrHd9ISl10odX9VC9qW10MdNamqnTKOl6YvfN m8uCZHkJhQJnmVsSMdm/eZ6eA7Xmwu4yT4PbYJzyXjrs9xOnijuSdJpH5aVQ3LzICpLy uBrnPBNHdfT76XH5HGCBR9lR1OM2myOEM7KHJ4ZDPQjLpeB+FJ/V3FSPCXCX0bDs8EiI 5liJzv1XgzsgYJaBn16P5687YE1iyFdQPTpJfcy++uVIbHGKYJWHufr0Yw2Mw1CsEZRa hKAQ==
X-Gm-Message-State: ALoCoQlssVU6yNnUbO2UenIr3PjC7FV7oqN8YTQgX8xnVsAvxMXgZu003hrNDkggYVgPmDXYQkUj
X-Received: by 10.180.205.171 with SMTP id lh11mr2467526wic.66.1414138949911;  Fri, 24 Oct 2014 01:22:29 -0700 (PDT)
Received: from macbookirharris.home (host31-50-189-50.range31-50.btcentralplus.com. [31.50.189.50]) by mx.google.com with ESMTPSA id wc7sm4801264wjc.8.2014.10.24.01.22.28 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 24 Oct 2014 01:22:29 -0700 (PDT)
Message-ID: <544A0C43.7060101@terena.org>
Date: Fri, 24 Oct 2014 09:22:27 +0100
From: Nicole Harris 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: vot@ietf.org
References:  <70E8358B-EC84-4780-92BD-F5E457B4CE52@isoc.org> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------050106010506040305080205"
Archived-At: http://mailarchive.ietf.org/arch/msg/vot/3ObR9UxglFhn4FWonw7YmdWVJsc
Subject: Re: [VoT] vot Digest, Vol 2, Issue 24
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Vectors of Trust discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Oct 2014 08:22:34 -0000

This is a multi-part message in MIME format.
--------------050106010506040305080205
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

virtual bar for me also :-)

On 23/10/2014 20:15, Joni Brennan wrote:
> I too am sorry that I won't be there.  Robin and I may meet at the virtual
> skype-bar in the interim.
>
> Have a great meeting.
>
> Best Regards,
>
> Joni Brennan
> Kantara Initiative | Executive Director
> voice:+1 732-266-8994
> email: joni @ kantarainitiative.org
>
> Connecting Identity for a more trustworthy Internet - Overview
> 
>
>
>
>
> On Thu, Oct 23, 2014 at 4:29 AM, Robin Wilton  wrote:
>
>> Really sorry I won't be there.
>>
>> I look forward to an equally paradisical bar-BoF in... ?Dallas? *cough*
>>
>> _______________________________________________
>> vot mailing list
>> vot@ietf.org
>> https://www.ietf.org/mailman/listinfo/vot
>>
>>
>
>
> _______________________________________________
> vot mailing list
> vot@ietf.org
> https://www.ietf.org/mailman/listinfo/vot


-- 
----------------
Project Development Officer
TERENA
Singel 468 D
Amsterdam, 1017 AW
The Netherlands

T: +31(0)20 5304488
F: +31(0)20 5304499 

mob: +31(0)646 105395
skype: harrisnv


--------------050106010506040305080205
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
    virtual bar for me also :-) 
    
      
    
      On 23/10/2014 20:15, Joni Brennan wrote:
    
    
    
    
    
      
    I too am sorry that I won't be there.  Robin and I may meet at the virtual
skype-bar in the interim.

Have a great meeting.

Best Regards,

Joni Brennan
Kantara Initiative | Executive Director
voice:+1 732-266-8994
email: joni @ kantarainitiative.org

Connecting Identity for a more trustworthy Internet - Overview
<http://www.slideshare.net/kantarainitiative/kantara-overview2014-37969351>




On Thu, Oct 23, 2014 at 4:29 AM, Robin Wilton <wilton@isoc.org> wrote:


    
      
    
        
    Really sorry I won't be there.

I look forward to an equally paradisical bar-BoF in... ?Dallas? *cough*

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



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

    
    
    
    
    
    
    
    
    -- 
----------------
Project Development Officer
TERENA
Singel 468 D
Amsterdam, 1017 AW
The Netherlands

T: +31(0)20 5304488
F: +31(0)20 5304499 

mob: +31(0)646 105395
skype: harrisnv

    
  


--------------050106010506040305080205--


From nobody Sun Oct 26 06:26:14 2014
Return-Path: 
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 992741A8733 for ; Sun, 26 Oct 2014 06:26:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.919
X-Spam-Level: **
X-Spam-Status: No, score=2.919 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_SUMOF=1, HELO_EQ_SE=0.35, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZpqOiPDLEhyi for ; Sun, 26 Oct 2014 06:26:07 -0700 (PDT)
Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (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 092D21A8738 for ; Sun, 26 Oct 2014 06:25:12 -0700 (PDT)
Received: from smtp1.sunet.se (smtp1.sunet.se [IPv6:2001:6b0:8:2::214]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id s9QDPA6V025188 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 26 Oct 2014 14:25:10 +0100
Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.7/8.14.7) with ESMTP id s9QDP7sV013249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 26 Oct 2014 14:25:10 +0100 (CET)
X-Footer: c3VuZXQuc2U=
Received: from [162.244.109.116] ([162.244.109.116]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.3.3) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256 bits)) for vot@ietf.org; Sun, 26 Oct 2014 14:25:05 +0100
Message-ID: <544CF630.8020209@sunet.se>
Date: Sun, 26 Oct 2014 14:25:04 +0100
From: Leif Johansson 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: vot@ietf.org
References: <1412885935.58929166@apps.rackspace.com> <04CF3DDE-9FDF-499A-8093-3EC3CE84E4DF@identinetics.com> <1412896617.869315461@apps.rackspace.com> <789542E6-3D10-4364-8B22-BD30CD08F524@hoerbe.at>
In-Reply-To: <789542E6-3D10-4364-8B22-BD30CD08F524@hoerbe.at>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sunet-se:default, sunet-se:default, base:default, @@RPTN)
X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=62.0000; longitude=15.0000; http://maps.google.com/maps?q=62.0000,15.0000&z=6
X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default)
X-Canit-Stats-ID: 09N7NpaPg - 87ef089f9c75 - 20141026
X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw
X-Scanned-By: CanIt (www . roaringpenguin . com)
Archived-At: http://mailarchive.ietf.org/arch/msg/vot/HeXqPR-HTi8NoGsX2GrRMnDhGDM
Subject: Re: [VoT] Foundational questions of principle
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Vectors of Trust discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 26 Oct 2014 13:26:09 -0000

> We shouldn't condemn levels altogether. They do work reasonably well
> within sectors, such as specific supply chains, payment industry or
> government-to-government. It is the idea of a cross-sector interoperable
> LoA that does not scale. My experience from AT e-gov tells me that a
> larger part of RPs struggles with policies that are more complex than a
> few pages describing LoA 1-4. 

One of the many upsides of the Justin Richer proposal is that it allows
both aggregated "levels" as well as expressions of level-by-vector.

The name "vectors of trust" was chosen with a tip-o-the-hat to a part
of mathematics called linear algebra.

For those of you who remember your college math, a vector is the sum of
linear eigenvectors: v = t*x + s*y. In our world the x and y are Justins
base criteria (identity proofing, credential strength etc) and v becomes
the aggregate level.

Don't beat me up over the math now folks, its an analogy !

We should be thinking about this as a meta-model for assurance to be
extended both by organizations like Kantara and NIST who will craft
audit criteria to go with the eigenvectors but also probably by groups
that want to add additional *dimensions* to the algebra of trust.
	
	Cheers Leif


From nobody Mon Oct 27 09:01:27 2014
Return-Path: 
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D141D1A88F8 for ; Mon, 27 Oct 2014 09:01:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.8
X-Spam-Level: *
X-Spam-Status: No, score=1.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8,  GB_SUMOF=1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRBSUsKhflLp for ; Mon, 27 Oct 2014 09:01:16 -0700 (PDT)
Received: from smtp101.iad3a.emailsrvr.com (smtp101.iad3a.emailsrvr.com [173.203.187.101]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C88B11ACE40 for ; Mon, 27 Oct 2014 09:01:13 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp5.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id ED267807F3 for ; Mon, 27 Oct 2014 12:01:12 -0400 (EDT)
X-Virus-Scanned: OK
Received: from app60.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp5.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id CA9CB807E0 for ; Mon, 27 Oct 2014 12:01:12 -0400 (EDT)
X-Sender-Id: swilson@lockstep.com.au
Received: from app60.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.3.2); Mon, 27 Oct 2014 16:01:12 GMT
Received: from lockstep.com.au (localhost.localdomain [127.0.0.1]) by app60.wa-webapps.iad3a (Postfix) with ESMTP id A56B3280067 for ; Mon, 27 Oct 2014 12:01:12 -0400 (EDT)
Received: by apps.rackspace.com (Authenticated sender: swilson@lockstep.com.au, from: swilson@lockstep.com.au)  with HTTP; Tue, 28 Oct 2014 03:01:12 +1100 (EST)
Date: Tue, 28 Oct 2014 03:01:12 +1100 (EST)
From: swilson@lockstep.com.au
To: vot@ietf.org
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Importance: Normal
X-Priority: 3 (Normal)
X-Type: plain
In-Reply-To: <544CF630.8020209@sunet.se>
References: <1412885935.58929166@apps.rackspace.com>  <04CF3DDE-9FDF-499A-8093-3EC3CE84E4DF@identinetics.com>  <1412896617.869315461@apps.rackspace.com>  <789542E6-3D10-4364-8B22-BD30CD08F524@hoerbe.at>  <544CF630.8020209@sunet.se>
X-Auth-ID: swilson@lockstep.com.au
Message-ID: <1414425672.6768107@apps.rackspace.com>
X-Mailer: webmail7.0
Archived-At: http://mailarchive.ietf.org/arch/msg/vot/fyGa-eUC2ydSUCY5iZIGoPNmooI
Subject: Re: [VoT] Foundational questions of principle
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Vectors of Trust discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Oct 2014 16:01:18 -0000

=0AI definitely agree that the things we need to know about someone in orde=
r to create an "identification" in a particular context are vector-like. Th=
at's a much better way of thinking about things than the old one dimensiona=
l (scalar) LOA. =0A=0AI have written about this previously, invoking spider=
 diagrams to illustrate the "surface" created by a digital identity when co=
mposed of a set of attributes:=0A=0Ahttp://lockstep.com.au/blog/2012/08/25/=
surfacing-identity=0A=0AI just don't think it's useful to label these thing=
s "vectors of trust" when they're attributes.  There is a strong push towar=
ds attributes thinking across the identity community.  I think "vectors of =
trust" is potentially confusing, when the great ideas under VoT could get e=
ven more traction if the words you used resonated with current developments=
 in FIDO, AXN etc.   =0A=0ACheers, =0A=0ASteve.=0A=0AStephen Wilson=0AManag=
ing Director=0ALockstep Group=0APhone +61 (0)414 488 851=0Ahttp://lockstep.=
com.au=0ALockstep Consulting provides independent specialist advice and ana=
lysis =0Aon digital identity and privacy.  Lockstep Technologies develops u=
nique =0Anew smart ID solutions that enhance privacy and prevent identity t=
heft.=0A=0A=0A =0A=0A-----Original Message-----=0AFrom: "Leif Johansson" =0ASent: Monday, 27 October, 2014 12:25am=0ATo: vot@ietf.org=
=0ASubject: Re: [VoT] Foundational questions of principle=0A=0A=0A> We shou=
ldn't condemn levels altogether. They do work reasonably well=0A> within se=
ctors, such as specific supply chains, payment industry or=0A> government-t=
o-government. It is the idea of a cross-sector interoperable=0A> LoA that d=
oes not scale. My experience from AT e-gov tells me that a=0A> larger part =
of RPs struggles with policies that are more complex than a=0A> few pages d=
escribing LoA 1-4. =0A=0AOne of the many upsides of the Justin Richer propo=
sal is that it allows=0Aboth aggregated "levels" as well as expressions of =
level-by-vector.=0A=0AThe name "vectors of trust" was chosen with a tip-o-t=
he-hat to a part=0Aof mathematics called linear algebra.=0A=0AFor those of =
you who remember your college math, a vector is the sum of=0Alinear eigenve=
ctors: v =3D t*x + s*y. In our world the x and y are Justins=0Abase criteri=
a (identity proofing, credential strength etc) and v becomes=0Athe aggregat=
e level.=0A=0ADon't beat me up over the math now folks, its an analogy !=0A=
=0AWe should be thinking about this as a meta-model for assurance to be=0Ae=
xtended both by organizations like Kantara and NIST who will craft=0Aaudit =
criteria to go with the eigenvectors but also probably by groups=0Athat wan=
t to add additional *dimensions* to the algebra of trust.=0A=09=0A=09Cheers=
 Leif=0A=0A_______________________________________________=0Avot mailing li=
st=0Avot@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/vot=0A


From nobody Mon Oct 27 10:05:21 2014
Return-Path: 
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B26971A1B93 for ; Mon, 27 Oct 2014 10:05:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fmmxw3tTPWj5 for ; Mon, 27 Oct 2014 10:05:13 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0730.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::730]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D20A1A0102 for ; Mon, 27 Oct 2014 10:05:13 -0700 (PDT)
Received: from BL2FFO11FD014.protection.gbl (10.173.160.30) by BL2FFO11HUB039.protection.gbl (10.173.160.245) with Microsoft SMTP Server (TLS) id 15.0.1049.20; Mon, 27 Oct 2014 17:04:50 +0000
Received: from cio-tnc-pf04.osuad.osu.edu (164.107.81.218) by BL2FFO11FD014.mail.protection.outlook.com (10.173.160.222) with Microsoft SMTP Server (TLS) id 15.0.1049.20 via Frontend Transport; Mon, 27 Oct 2014 17:04:50 +0000
Received: from CIO-TNC-HT06.osuad.osu.edu (cio-tnc-ht06.osuad.osu.edu [164.107.81.171]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by cio-tnc-pf04.osuad.osu.edu (Postfix) with ESMTPS id 3FC8E380035; Mon, 27 Oct 2014 13:04:50 -0400 (EDT)
Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT06.osuad.osu.edu ([fe80::3d16:84bd:8d88:7cfd%12]) with mapi id 14.03.0174.001; Mon, 27 Oct 2014 13:04:49 -0400
From: "Cantor, Scott" 
To: "swilson@lockstep.com.au" , "vot@ietf.org" 
Thread-Topic: [VoT] Foundational questions of principle
Thread-Index: AQHP4/5G4lDLBqwim0uOTbuH/sjzZJwoZk77gADGmwCAGY6pAIABvfQA///OtoA=
Date: Mon, 27 Oct 2014 17:04:48 +0000
Message-ID: 
References: <1412885935.58929166@apps.rackspace.com> <04CF3DDE-9FDF-499A-8093-3EC3CE84E4DF@identinetics.com> <1412896617.869315461@apps.rackspace.com> <789542E6-3D10-4364-8B22-BD30CD08F524@hoerbe.at> <544CF630.8020209@sunet.se> <1414425672.6768107@apps.rackspace.com>
In-Reply-To: <1414425672.6768107@apps.rackspace.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [128.146.14.34]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:164.107.81.218; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(479174003)(377454003)(189002)(51704005)(24454002)(199003)(106466001)(85852003)(88552001)(107886001)(46102003)(76482002)(20776003)(50986999)(54356999)(76176999)(21056001)(2501002)(47776003)(66066001)(23726002)(109096001)(75432002)(46406003)(120916001)(93886004)(90282001)(80022003)(92566001)(107046002)(89122001)(99396003)(85306004)(97756001)(50466002)(19580395003)(19580405001)(86362001)(92726001)(106116001)(31966008)(2656002)(87936001)(77096002)(93346002)(36756003)(95666004)(6806004)(44976005)(64706001)(4396001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2FFO11HUB039; H:cio-tnc-pf04.osuad.osu.edu; FPR:; MLV:sfv; PTR:cio-tnc-pf04.osuad.osu.edu; MX:1; A:1; LANG:en; 
X-Microsoft-Antispam: UriScan:;
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2FFO11HUB039;
X-Forefront-PRVS: 0377802854
Received-SPF: Pass (protection.outlook.com: domain of osu.edu designates 164.107.81.218 as permitted sender) receiver=protection.outlook.com; client-ip=164.107.81.218; helo=cio-tnc-pf04.osuad.osu.edu;
Authentication-Results: spf=pass (sender IP is 164.107.81.218) smtp.mailfrom=cantor.2@osu.edu; 
X-OriginatorOrg: osu.edu
Archived-At: http://mailarchive.ietf.org/arch/msg/vot/mDAydJ_Hm5PJGZc5FPzVLJndDuQ
Subject: Re: [VoT] Foundational questions of principle
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Vectors of Trust discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Oct 2014 17:05:17 -0000

On 10/27/14, 12:01 PM, "swilson@lockstep.com.au" 
wrote:
>
>I just don't think it's useful to label these things "vectors of trust"
>when they're attributes.  There is a strong push towards attributes
>thinking across the identity community.  I think "vectors of trust" is
>potentially confusing, when the great ideas under VoT could get even more
>traction if the words you used resonated with current developments in
>FIDO, AXN etc.  =20

Even a simple number or a simply-encoded set of scalars is an attribute in
the most general sense. But if you're saying that developers are
increasingly wanting and willing to consume very fine grained information
about people and context, I can't match that with my experiences dealing
with vendors and developers.

-- Scott


From nobody Mon Oct 27 10:25:31 2014
Return-Path: 
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CBD61A6FF6 for ; Mon, 27 Oct 2014 10:25:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P3bg7s37hRyU for ; Mon, 27 Oct 2014 10:25:14 -0700 (PDT)
Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id 60B3E1A0183 for ; Mon, 27 Oct 2014 10:25:07 -0700 (PDT)
Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E168EB2E143; Mon, 27 Oct 2014 13:25:06 -0400 (EDT)
Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id CE4B8B2E135; Mon, 27 Oct 2014 13:25:06 -0400 (EDT)
Received: from IMCMBX01.MITRE.ORG ([169.254.1.78]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.03.0174.001; Mon, 27 Oct 2014 13:25:06 -0400
From: "Richer, Justin P." 
To: "Cantor, Scott" 
Thread-Topic: [VoT] Foundational questions of principle
Thread-Index: AQHP8SBqE0XqsgFSsEOTM+CkBuRkVpxEX0IAgAARxQCAAAWmgA==
Date: Mon, 27 Oct 2014 17:25:05 +0000
Message-ID: <01DD7D1A-E684-4DA6-A1FF-3449A057063B@mitre.org>
References: <1412885935.58929166@apps.rackspace.com> <04CF3DDE-9FDF-499A-8093-3EC3CE84E4DF@identinetics.com> <1412896617.869315461@apps.rackspace.com> <789542E6-3D10-4364-8B22-BD30CD08F524@hoerbe.at> <544CF630.8020209@sunet.se> <1414425672.6768107@apps.rackspace.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.10.222]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <87B17475532ED749AFC5874BD2531CEA@imc.mitre.org>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/vot/lkLrlZR-3pDYi41iUUUTQlFA3DY
Cc: "vot@ietf.org" , "swilson@lockstep.com.au" 
Subject: Re: [VoT] Foundational questions of principle
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Vectors of Trust discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Oct 2014 17:25:17 -0000

I agree with Scott -- using the "attributes" language directly here makes i=
t too easy to just throw bags of values around in a way that's completely o=
verwhelming and not interoperable. I think we need something between the si=
ngle scalar of LoA and the "anything goes here" world of ABAC-in-extremis. =
Something that developers can actually do some processing on.

 -- Justin

On Oct 27, 2014, at 1:04 PM, Cantor, Scott  wrote:

> On 10/27/14, 12:01 PM, "swilson@lockstep.com.au" 
> wrote:
>>=20
>> I just don't think it's useful to label these things "vectors of trust"
>> when they're attributes.  There is a strong push towards attributes
>> thinking across the identity community.  I think "vectors of trust" is
>> potentially confusing, when the great ideas under VoT could get even mor=
e
>> traction if the words you used resonated with current developments in
>> FIDO, AXN etc.  =20
>=20
> Even a simple number or a simply-encoded set of scalars is an attribute i=
n
> the most general sense. But if you're saying that developers are
> increasingly wanting and willing to consume very fine grained information
> about people and context, I can't match that with my experiences dealing
> with vendors and developers.
>=20
> -- Scott
>=20
> _______________________________________________
> vot mailing list
> vot@ietf.org
> https://www.ietf.org/mailman/listinfo/vot


From nobody Mon Oct 27 10:27:32 2014
Return-Path: 
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEF081A701F for ; Mon, 27 Oct 2014 10:27:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level: 
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHoBK7rOWGnM for ; Mon, 27 Oct 2014 10:27:20 -0700 (PDT)
Received: from smtp109.iad3a.emailsrvr.com (smtp109.iad3a.emailsrvr.com [173.203.187.109]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 126BF1A0187 for ; Mon, 27 Oct 2014 10:27:20 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp6.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 5D15F1802BA for ; Mon, 27 Oct 2014 13:27:19 -0400 (EDT)
X-Virus-Scanned: OK
Received: from app20.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp6.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 40F2718066E for ; Mon, 27 Oct 2014 13:27:19 -0400 (EDT)
X-Sender-Id: swilson@lockstep.com.au
Received: from app20.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.3.2); Mon, 27 Oct 2014 17:27:19 GMT
Received: from lockstep.com.au (localhost.localdomain [127.0.0.1]) by app20.wa-webapps.iad3a (Postfix) with ESMTP id 2F05380062 for ; Mon, 27 Oct 2014 13:27:19 -0400 (EDT)
Received: by apps.rackspace.com (Authenticated sender: swilson@lockstep.com.au, from: swilson@lockstep.com.au)  with HTTP; Tue, 28 Oct 2014 04:27:19 +1100 (EST)
Date: Tue, 28 Oct 2014 04:27:19 +1100 (EST)
From: swilson@lockstep.com.au
To: "vot@ietf.org" 
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Importance: Normal
X-Priority: 3 (Normal)
X-Type: plain
In-Reply-To: 
References: <1412885935.58929166@apps.rackspace.com>  <04CF3DDE-9FDF-499A-8093-3EC3CE84E4DF@identinetics.com>  <1412896617.869315461@apps.rackspace.com>  <789542E6-3D10-4364-8B22-BD30CD08F524@hoerbe.at>  <544CF630.8020209@sunet.se> <1414425672.6768107@apps.rackspace.com>  
X-Auth-ID: swilson@lockstep.com.au
Message-ID: <1414430839.190810632@apps.rackspace.com>
X-Mailer: webmail7.0
Archived-At: http://mailarchive.ietf.org/arch/msg/vot/9wprF2hz6UFbPxJsjgiRXBr-6Oc
Subject: Re: [VoT] Foundational questions of principle
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Vectors of Trust discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Oct 2014 17:27:24 -0000

=0AScott, =0A=0AI certainly wouldn't disagree with your experience, if you =
say you don't see developers wanting to consumer fine grained information a=
bout users. =0A=0AWhat developers *want* is simple signals, like "you can t=
rust Alice because IdP A says she's been identified". =0A=0ABut these deter=
minations by IdPs are breaking down, because the fine grained information t=
hat the IdPs consumes in order to make an "identification" doesn't align wi=
th what RPs really need to know.  *Someone* needs to look at the fine grain=
ed information.  "Policy mapping" is the exercise that's been tried over an=
d over through history, where typically an IdP tries to make a generic exam=
ination of fine grained information sufficient on behalf of a whole class o=
f RPs and applications.  But the devil is in the detail, and for higher ris=
k transactions (classically "LOA 3" or "LOA 4") generic Policy Mapping prov=
es impossible. So LOA 4 RPs tend to issue and use identities themselves.  (=
if there is an example of an LOA 4 RP accepting an LOA 4 identity on its fa=
ce, I have yet to see it).  The time it would take to painstakingly review =
an IdP's fine grained information and sign off that what the IdP does is fi=
t for the RP's purpose is simply greater than the effort of the RP doing th=
e identity checking for itself. =0A=0AI conclude that the only practical wa=
y to externalise Identity proofing for higher risk transactions will be to =
look at the fine grained attributes and federate them at a lower level (see=
 my CIS 2014 talk http://lockstep.com.au/library/identity_authentication/au=
thn-family-tree). =0A=0AAll of which is to say I agree wholeheartedly with =
the thrust of the VoT work.  We do need to expose the fine grained informat=
ion that goes into identity determinations.  I just wish we would all congr=
egate around the idea of attributes.  It was one of the best things in the =
Laws of Identity - the definition of Identity as a set of attributes.  Let'=
s stick to that concept. =0A=0ACheers =0A=0ASteve.=0A=0A   =0A=0A-----Origi=
nal Message-----=0AFrom: "Cantor, Scott" =0ASent: Tuesday=
, 28 October, 2014 4:04am=0ATo: "swilson@lockstep.com.au" , "vot@ietf.org" =0ASubject: Re: [VoT] Foundational q=
uestions of principle=0A=0AOn 10/27/14, 12:01 PM, "swilson@lockstep.com.au"=
 =0Awrote:=0A>=0A>I just don't think it's useful t=
o label these things "vectors of trust"=0A>when they're attributes.  There =
is a strong push towards attributes=0A>thinking across the identity communi=
ty.  I think "vectors of trust" is=0A>potentially confusing, when the great=
 ideas under VoT could get even more=0A>traction if the words you used reso=
nated with current developments in=0A>FIDO, AXN etc.   =0A=0AEven a simple =
number or a simply-encoded set of scalars is an attribute in=0Athe most gen=
eral sense. But if you're saying that developers are=0Aincreasingly wanting=
 and willing to consume very fine grained information=0Aabout people and co=
ntext, I can't match that with my experiences dealing=0Awith vendors and de=
velopers.=0A=0A-- Scott=0A=0A______________________________________________=
_=0Avot mailing list=0Avot@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo=
/vot=0A


From nobody Mon Oct 27 10:35:31 2014
Return-Path: 
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8759A1A00D6 for ; Mon, 27 Oct 2014 10:35:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GxDopmnoYTVy for ; Mon, 27 Oct 2014 10:35:27 -0700 (PDT)
Received: from smtp125.iad3a.emailsrvr.com (smtp125.iad3a.emailsrvr.com [173.203.187.125]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2AC71A00AF for ; Mon, 27 Oct 2014 10:35:26 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp16.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 52FA2180502 for ; Mon, 27 Oct 2014 13:35:26 -0400 (EDT)
X-Virus-Scanned: OK
Received: from app11.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp16.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 1E46918041C for ; Mon, 27 Oct 2014 13:35:25 -0400 (EDT)
X-Sender-Id: swilson@lockstep.com.au
Received: from app11.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.3.2); Mon, 27 Oct 2014 17:35:26 GMT
Received: from lockstep.com.au (localhost.localdomain [127.0.0.1]) by app11.wa-webapps.iad3a (Postfix) with ESMTP id 50AA0380066 for ; Mon, 27 Oct 2014 13:35:25 -0400 (EDT)
Received: by apps.rackspace.com (Authenticated sender: swilson@lockstep.com.au, from: swilson@lockstep.com.au)  with HTTP; Tue, 28 Oct 2014 04:35:25 +1100 (EST)
Date: Tue, 28 Oct 2014 04:35:25 +1100 (EST)
From: swilson@lockstep.com.au
To: vot@ietf.org
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Importance: Normal
X-Priority: 3 (Normal)
X-Type: plain
In-Reply-To: <01DD7D1A-E684-4DA6-A1FF-3449A057063B@mitre.org>
References: <1412885935.58929166@apps.rackspace.com>  <04CF3DDE-9FDF-499A-8093-3EC3CE84E4DF@identinetics.com>  <1412896617.869315461@apps.rackspace.com>  <789542E6-3D10-4364-8B22-BD30CD08F524@hoerbe.at>  <544CF630.8020209@sunet.se> <1414425672.6768107@apps.rackspace.com>    <01DD7D1A-E684-4DA6-A1FF-3449A057063B@mitre.org>
X-Auth-ID: swilson@lockstep.com.au
Message-ID: <1414431325.328614122@apps.rackspace.com>
X-Mailer: webmail7.0
Archived-At: http://mailarchive.ietf.org/arch/msg/vot/ZwnZ4dHZAOywNF-hGxQFx9ZMhRA
Subject: Re: [VoT] Foundational questions of principle
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Vectors of Trust discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Oct 2014 17:35:29 -0000

=0AI wrote a long response to Scott's point while you were responding. =0A=
=0AI won't say much more except to observe that interoperability of what an=
 IdP says about a Subject and what the RP needs to know about that Subject =
only occurs at the lower attribute level.  So somewhere in the attributes/i=
dentity supply chain, detailed examination does have to take place.  The id=
ea of vectors shows that there are a great many things to look at.  That's =
goodness.  I get that developers don't want to do the examination but someo=
ne has to, and for high risk transactions, someone representing the RP need=
s to sign off at design time on the actual attribute choice (that is, the R=
P needs to sign off that the way "identification" is done by IdP A is okay)=
. =0A=0AI wonder if perhaps "attributes" is loaded with meanings that I hav=
en't come across myself.  The term as matter of plain English, and as used =
in the Laws of Identity, seems fine to me. =0A=0AI haven't had to work much=
 in ABAC.  Justin, the way you refer to it suggests maybe it's become a pro=
blem?=0A=0ACheers, =0A=0ASteve.=0A=0AStephen Wilson=0ALockstep =0Ahttp://lo=
ckstep.com.au=0ALockstep Consulting provides independent specialist advice =
and analysis =0Aon digital identity and privacy.  Lockstep Technologies dev=
elops unique =0Anew smart ID solutions that enhance privacy and prevent ide=
ntity theft.=0A=0A-----Original Message-----=0AFrom: "Richer, Justin P." =0ASent: Tuesday, 28 October, 2014 4:25am=0ATo: "Cantor, S=
cott" =0ACc: "vot@ietf.org" , "swilson@lock=
step.com.au" =0ASubject: Re: [VoT] Foundational qu=
estions of principle=0A=0AI agree with Scott -- using the "attributes" lang=
uage directly here makes it too easy to just throw bags of values around in=
 a way that's completely overwhelming and not interoperable. I think we nee=
d something between the single scalar of LoA and the "anything goes here" w=
orld of ABAC-in-extremis. Something that developers can actually do some pr=
ocessing on.=0A=0A -- Justin=0A=0AOn Oct 27, 2014, at 1:04 PM, Cantor, Scot=
t  wrote:=0A=0A> On 10/27/14, 12:01 PM, "swilson@lockstep=
.com.au" =0A> wrote:=0A>> =0A>> I just don't think=
 it's useful to label these things "vectors of trust"=0A>> when they're att=
ributes.  There is a strong push towards attributes=0A>> thinking across th=
e identity community.  I think "vectors of trust" is=0A>> potentially confu=
sing, when the great ideas under VoT could get even more=0A>> traction if t=
he words you used resonated with current developments in=0A>> FIDO, AXN etc=
.   =0A> =0A> Even a simple number or a simply-encoded set of scalars is an=
 attribute in=0A> the most general sense. But if you're saying that develop=
ers are=0A> increasingly wanting and willing to consume very fine grained i=
nformation=0A> about people and context, I can't match that with my experie=
nces dealing=0A> with vendors and developers.=0A> =0A> -- Scott=0A> =0A> __=
_____________________________________________=0A> vot mailing list=0A> vot@=
ietf.org=0A> https://www.ietf.org/mailman/listinfo/vot=0A=0A_______________=
________________________________=0Avot mailing list=0Avot@ietf.org=0Ahttps:=
//www.ietf.org/mailman/listinfo/vot=0A


From geszes@gmail.com  Tue Oct 28 12:34:41 2014
Return-Path: 
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB72E1ACD10 for ; Tue, 28 Oct 2014 12:34:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.7
X-Spam-Level: 
X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3FmpMxFAv_04 for ; Tue, 28 Oct 2014 12:34:39 -0700 (PDT)
Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A33CC1ACD04 for ; Tue, 28 Oct 2014 12:34:32 -0700 (PDT)
Received: by mail-qg0-f41.google.com with SMTP id q107so1114085qgd.14 for ; Tue, 28 Oct 2014 12:34:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=ReKD3VorXcOyVsjH+qMypiqr/xBK1P29igegW6ddPvU=; b=wJvTK1Sdk/MxXOcuzqUuVMxkidRzJ79BIe4IBSLRilPn8wNeJsaxshvrp5EBlZz6hv fyzX90N3tZ2GzdSSQaQ0keXQoRLqfKKiQsCRuLwktpmGO7q94S9CEQhOaIU5K4vrR3Wk slw3lTrB5xGeyJnucLq+dMx5zB1P42STOhy8uPHlmv0lOfrjRDZT+hiwVDOKoPQfhtRk gycD11fhyjNOk/CZahqiEDL1udLqarfz/8Na2NTWtiyc+NEZRBmAuqhSjT+ix2RywzYh IOgnzmsDrvTnIRbJ0UZPUuL0QTk4BOTAZ2vBUlJQymYL6nRg9+IW7dOcIpeRceyEhQLT /xng==
MIME-Version: 1.0
X-Received: by 10.140.109.244 with SMTP id l107mr7750719qgf.80.1414524864593;  Tue, 28 Oct 2014 12:34:24 -0700 (PDT)
Received: by 10.229.154.139 with HTTP; Tue, 28 Oct 2014 12:34:24 -0700 (PDT)
In-Reply-To: 
References: 
Date: Tue, 28 Oct 2014 15:34:24 -0400
Message-ID: 
From: Gabor Eszes 
To: vot@ietf.org
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/vot/_3K9AcLJmBn5uvBQf35gVNV4hq8
X-Mailman-Approved-At: Wed, 29 Oct 2014 11:37:58 -0700
Subject: [VoT] Fwd: IdWeek ACAMP discussion
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Vectors of Trust discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 16:22:18 -0000

Notes from the discussion on Vectors of Trust on 2014-10-28 at
InCommon Identity Week are available at the InCommon wiki:

https://spaces.internet2.edu/display/ACAMP2014/Home

The direct link to the Google Doc at the time of writing was:

https://docs.google.com/document/d/12tfT2r8RvuOr7Rwq5fQyU33WyUbt0uMgY1zXQkg-71g/edit?usp=sharing

I may have been the sole note-taker, revisions are welcome.


Gabor Eszes
IAM & Middleware
Old Dominion University


From nobody Wed Oct 29 14:07:35 2014
Return-Path: 
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C5981A8AD1 for ; Wed, 29 Oct 2014 14:07:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.619
X-Spam-Level: 
X-Spam-Status: No, score=0.619 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_SE=0.35, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qwNB3V-CNS4k for ; Wed, 29 Oct 2014 14:07:29 -0700 (PDT)
Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (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 B46F51A8AE6 for ; Wed, 29 Oct 2014 14:07:28 -0700 (PDT)
Received: from smtp1.sunet.se (smtp1.sunet.se [IPv6:2001:6b0:8:2::214]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id s9TL7Qh1020992 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 29 Oct 2014 22:07:26 +0100
Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.7/8.14.7) with ESMTP id s9TL7NNS029888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 29 Oct 2014 22:07:26 +0100 (CET)
X-Footer: c3VuZXQuc2U=
Received: from [162.244.105.92] ([162.244.105.92]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.3.3) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256 bits)) for vot@ietf.org; Wed, 29 Oct 2014 22:07:21 +0100
Message-ID: <54515707.3050704@sunet.se>
Date: Wed, 29 Oct 2014 22:07:19 +0100
From: Leif Johansson 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: vot@ietf.org
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sunet-se:default, sunet-se:default, base:default, @@RPTN)
X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=62.0000; longitude=15.0000; http://maps.google.com/maps?q=62.0000,15.0000&z=6
X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default)
X-Canit-Stats-ID: 09N997qMU - 78e6f8d92c43 - 20141029
X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw
X-Scanned-By: CanIt (www . roaringpenguin . com)
Archived-At: http://mailarchive.ietf.org/arch/msg/vot/H8A1AeYfezCP33b26qK4OPgZSyA
Subject: [VoT] bar-bof @ IETF90
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Vectors of Trust discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 21:07:32 -0000

Here are the possibilities I can see:

1. Monday night after the technical plenary (~19).
2. Tuesday instead of the social.
3. Wednesday night after the admin plenary (or instead of part of it maybe)
4. Thursday afternoon before bits-n-bites (18:30 maybe)

I think 1 or 4 would be the best option.

Thoughts?

	Cheers Leif


From nobody Wed Oct 29 14:18:55 2014
Return-Path: 
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3DE81A9044 for ; Wed, 29 Oct 2014 14:18:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.118
X-Spam-Level: *
X-Spam-Status: No, score=1.118 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_SE=0.35, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWoVv5reqyDb for ; Wed, 29 Oct 2014 14:18:50 -0700 (PDT)
Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (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 3664C1A6F6F for ; Wed, 29 Oct 2014 14:18:50 -0700 (PDT)
Received: from smtp1.sunet.se (smtp1.sunet.se [IPv6:2001:6b0:8:2::214]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id s9TLImX2024188 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 29 Oct 2014 22:18:48 +0100
Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.7/8.14.7) with ESMTP id s9TLIjp5006362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 29 Oct 2014 22:18:48 +0100 (CET)
X-Footer: c3VuZXQuc2U=
Received: from [109.58.142.210] ([109.58.142.210]) by kerio.sunet.se (Kerio Connect 8.3.3) for vot@ietf.org; Wed, 29 Oct 2014 22:18:44 +0100
From: "Leif Johansson" 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
Message-Id: <7B384730-5281-4EDB-BDE8-0BE4CBF3469C@sunet.se>
Date: Wed, 29 Oct 2014 17:18:38 -0400
References: <54515707.3050704@sunet.se>
To: "vot@ietf.org" 
In-Reply-To: <54515707.3050704@sunet.se>
X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sunet-se:default, sunet-se:default, base:default, @@RPTN)
X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=62.0000; longitude=15.0000; http://maps.google.com/maps?q=62.0000,15.0000&z=6
X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default)
X-Canit-Stats-ID: 09N99iMXz - 560c30b8ecf6 - 20141029
X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw
X-Scanned-By: CanIt (www . roaringpenguin . com)
Archived-At: http://mailarchive.ietf.org/arch/msg/vot/SWmTlmjNOIQAC2YbzGA_6g3vLzA
Subject: Re: [VoT] bar-bof @ IETF90
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Vectors of Trust discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 21:18:52 -0000

> 29 okt 2014 kl. 17:09 skrev Leif Johansson :
> 
> 
> 
> Here are the possibilities I can see:
> 
> 1. Monday night after the technical plenary (~19).

ftr this would be my personal preference...

> 2. Tuesday instead of the social.
> 3. Wednesday night after the admin plenary (or instead of part of it maybe)
> 4. Thursday afternoon before bits-n-bites (18:30 maybe)
> 
> I think 1 or 4 would be the best option.
> 
> Thoughts?
> 
>    Cheers Leif
> 
> _______________________________________________
> vot mailing list
> vot@ietf.org
> https://www.ietf.org/mailman/listinfo/vot


From nobody Wed Oct 29 14:22:31 2014
Return-Path: 
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 489291A9046 for ; Wed, 29 Oct 2014 14:22:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.701
X-Spam-Level: 
X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XHahN2Oz8G-K for ; Wed, 29 Oct 2014 14:22:23 -0700 (PDT)
Received: from out27-ams.mf.surf.net (out27-ams.mf.surf.net [145.0.1.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 665761A038A for ; Wed, 29 Oct 2014 14:22:23 -0700 (PDT)
Received: from teletubbie.het.net.je (teletubbie.het.net.je [192.87.110.29]) by outgoing1-ams.mf.surf.net (8.14.4/8.14.4/Debian-4) with ESMTP id s9TLO8Sc022381; Wed, 29 Oct 2014 22:24:08 +0100
Received: from 52d9613c.cm-11-1b.dynamic.ziggo.nl ([82.217.97.60] helo=[192.168.4.3]) by teletubbie.het.net.je with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1XjaeL-000502-7N; Wed, 29 Oct 2014 22:19:25 +0100
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Klaas Wierenga 
X-Mailer: iPhone Mail (12B411)
In-Reply-To: <7B384730-5281-4EDB-BDE8-0BE4CBF3469C@sunet.se>
Date: Wed, 29 Oct 2014 22:22:19 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <1FC55179-A286-4DB3-A16D-AE2F43B6D343@wierenga.net>
References: <54515707.3050704@sunet.se> <7B384730-5281-4EDB-BDE8-0BE4CBF3469C@sunet.se>
To: Leif Johansson 
X-Antivirus: no malware found
X-Bayes-Prob: 0.0001 (Score 0, tokens from: p-out:default, p:default, base:default, @@RPTN)
X-CanIt-Geo: ip=192.87.110.29; country=NL; latitude=52.5000; longitude=5.7500;  http://maps.google.com/maps?q=52.5000,5.7500&z=6
X-CanItPRO-Stream: p-out:default (inherits from p:default,base:default)
X-Canit-Stats-ID: 0uN99o82X - 2dbc5763ee31 - 20141029 (trained as not-spam)
X-Scanned-By: CanIt (www . roaringpenguin . com)
Archived-At: http://mailarchive.ietf.org/arch/msg/vot/WyF04Y2PxOvRKu8rMGfGNTJeqeM
Cc: "vot@ietf.org" 
Subject: Re: [VoT] bar-bof @ IETF90
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Vectors of Trust discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 21:22:27 -0000

I think i can do all except 2

Sent from my iPhone

> On 29 Oct 2014, at 22:18, Leif Johansson  wrote:
>=20
>=20
>=20
>=20
>=20
>> 29 okt 2014 kl. 17:09 skrev Leif Johansson :
>>=20
>>=20
>>=20
>> Here are the possibilities I can see:
>>=20
>> 1. Monday night after the technical plenary (~19).
>=20
> ftr this would be my personal preference...
>=20
>> 2. Tuesday instead of the social.
>> 3. Wednesday night after the admin plenary (or instead of part of it mayb=
e)
>> 4. Thursday afternoon before bits-n-bites (18:30 maybe)
>>=20
>> I think 1 or 4 would be the best option.
>>=20
>> Thoughts?
>>=20
>>   Cheers Leif
>>=20
>> _______________________________________________
>> vot mailing list
>> vot@ietf.org
>> https://www.ietf.org/mailman/listinfo/vot
>=20
> _______________________________________________
> vot mailing list
> vot@ietf.org
> https://www.ietf.org/mailman/listinfo/vot


From nobody Wed Oct 29 14:35:55 2014
Return-Path: 
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 796511A90B1 for ; Wed, 29 Oct 2014 14:35:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.781
X-Spam-Level: 
X-Spam-Status: No, score=-0.781 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RvuIrMortria for ; Wed, 29 Oct 2014 14:35:52 -0700 (PDT)
Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (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 895EC1A90B3 for ; Wed, 29 Oct 2014 14:35:52 -0700 (PDT)
Received: from smtp1.sunet.se (smtp1.sunet.se [IPv6:2001:6b0:8:2::214]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id s9TLZokS028317 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 29 Oct 2014 22:35:50 +0100
Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.7/8.14.7) with ESMTP id s9TLZlhh016736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Oct 2014 22:35:50 +0100 (CET)
X-Footer: c3VuZXQuc2U=
Received: from [38.123.9.3] ([38.123.9.3]) by kerio.sunet.se (Kerio Connect 8.3.3); Wed, 29 Oct 2014 22:35:46 +0100
From: "Leif Johansson" 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
Message-Id: <76EFAB58-BAFE-4A62-BCCB-B19AF8C9DDD1@sunet.se>
Date: Wed, 29 Oct 2014 17:35:47 -0400
References: <54515707.3050704@sunet.se> <7B384730-5281-4EDB-BDE8-0BE4CBF3469C@sunet.se> <1FC55179-A286-4DB3-A16D-AE2F43B6D343@wierenga.net>
To: Klaas Wierenga 
In-Reply-To: <1FC55179-A286-4DB3-A16D-AE2F43B6D343@wierenga.net>
X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sunet-se:default, sunet-se:default, base:default, @@RPTN)
X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=62.0000; longitude=15.0000; http://maps.google.com/maps?q=62.0000,15.0000&z=6
X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default)
X-Canit-Stats-ID: 09N99zO9N - 5234920873e9 - 20141029
X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw
X-Scanned-By: CanIt (www . roaringpenguin . com)
Archived-At: http://mailarchive.ietf.org/arch/msg/vot/oRmR5xbjRfR0ElB-wvOMVscM78I
Cc: "vot@ietf.org" 
Subject: Re: [VoT] bar-bof @ IETF90
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Vectors of Trust discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 21:35:54 -0000

> 29 okt 2014 kl. 17:23 skrev Klaas Wierenga :
>=20
> I think i can do all except 2

And I just had to take 3 off the table so we're down to 1 & 4.

>=20
> Sent from my iPhone
>=20
>> On 29 Oct 2014, at 22:18, Leif Johansson  wrote:
>>=20
>>=20
>>=20
>>=20
>>=20
>>> 29 okt 2014 kl. 17:09 skrev Leif Johansson :
>>>=20
>>>=20
>>>=20
>>> Here are the possibilities I can see:
>>>=20
>>> 1. Monday night after the technical plenary (~19).
>>=20
>> ftr this would be my personal preference...
>>=20
>>> 2. Tuesday instead of the social.
>>> 3. Wednesday night after the admin plenary (or instead of part of it may=
be)
>>> 4. Thursday afternoon before bits-n-bites (18:30 maybe)
>>>=20
>>> I think 1 or 4 would be the best option.
>>>=20
>>> Thoughts?
>>>=20
>>>  Cheers Leif
>>>=20
>>> _______________________________________________
>>> vot mailing list
>>> vot@ietf.org
>>> https://www.ietf.org/mailman/listinfo/vot
>>=20
>> _______________________________________________
>> vot mailing list
>> vot@ietf.org
>> https://www.ietf.org/mailman/listinfo/vot
>=20
> _______________________________________________
> vot mailing list
> vot@ietf.org
> https://www.ietf.org/mailman/listinfo/vot


From nobody Wed Oct 29 15:23:17 2014
Return-Path: 
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2744D1A1B5C for ; Wed, 29 Oct 2014 15:23:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l3O8yjpqt-fD for ; Wed, 29 Oct 2014 15:23:13 -0700 (PDT)
Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id 18D7C1A9110 for ; Wed, 29 Oct 2014 15:23:12 -0700 (PDT)
Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 4C8E9B2E3B9; Wed, 29 Oct 2014 18:23:12 -0400 (EDT)
Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id 438D7B2E3BD; Wed, 29 Oct 2014 18:23:12 -0400 (EDT)
Received: from IMCMBX01.MITRE.ORG ([169.254.1.78]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.03.0174.001; Wed, 29 Oct 2014 18:23:12 -0400
From: "Richer, Justin P." 
To: Leif Johansson 
Thread-Topic: [VoT] bar-bof @ IETF90
Thread-Index: AQHP87xdBGQrbEx7g0+r4AV0TUo2UZxH12QAgAABCICAAAPDgIAADUaA
Date: Wed, 29 Oct 2014 22:23:11 +0000
Message-ID: <2B8556F1-10C4-4AF6-AE76-E7BECF637B1D@mitre.org>
References: <54515707.3050704@sunet.se> <7B384730-5281-4EDB-BDE8-0BE4CBF3469C@sunet.se> <1FC55179-A286-4DB3-A16D-AE2F43B6D343@wierenga.net> <76EFAB58-BAFE-4A62-BCCB-B19AF8C9DDD1@sunet.se>
In-Reply-To: <76EFAB58-BAFE-4A62-BCCB-B19AF8C9DDD1@sunet.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.34.189]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/vot/04HGI_VJbLst-s1ye7wWKnTREsA
Cc: "vot@ietf.org" , Klaas Wierenga 
Subject: Re: [VoT] bar-bof @ IETF90
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Vectors of Trust discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 22:23:15 -0000

I'm fine with either of these and slightly preferential toward 1.=20

 -- Justin

On Oct 29, 2014, at 5:35 PM, Leif Johansson  wrote:

>=20
>=20
>=20
>=20
>> 29 okt 2014 kl. 17:23 skrev Klaas Wierenga :
>>=20
>> I think i can do all except 2
>=20
> And I just had to take 3 off the table so we're down to 1 & 4.
>=20
>>=20
>> Sent from my iPhone
>>=20
>>> On 29 Oct 2014, at 22:18, Leif Johansson  wrote:
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>>> 29 okt 2014 kl. 17:09 skrev Leif Johansson :
>>>>=20
>>>>=20
>>>>=20
>>>> Here are the possibilities I can see:
>>>>=20
>>>> 1. Monday night after the technical plenary (~19).
>>>=20
>>> ftr this would be my personal preference...
>>>=20
>>>> 2. Tuesday instead of the social.
>>>> 3. Wednesday night after the admin plenary (or instead of part of it m=
aybe)
>>>> 4. Thursday afternoon before bits-n-bites (18:30 maybe)
>>>>=20
>>>> I think 1 or 4 would be the best option.
>>>>=20
>>>> Thoughts?
>>>>=20
>>>> Cheers Leif
>>>>=20
>>>> _______________________________________________
>>>> vot mailing list
>>>> vot@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/vot
>>>=20
>>> _______________________________________________
>>> vot mailing list
>>> vot@ietf.org
>>> https://www.ietf.org/mailman/listinfo/vot
>>=20
>> _______________________________________________
>> vot mailing list
>> vot@ietf.org
>> https://www.ietf.org/mailman/listinfo/vot
>=20
> _______________________________________________
> vot mailing list
> vot@ietf.org
> https://www.ietf.org/mailman/listinfo/vot


From nobody Wed Oct 29 15:27:35 2014
Return-Path: 
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F282B1A90F5 for ; Wed, 29 Oct 2014 15:27:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ym4fHC-oN7kk for ; Wed, 29 Oct 2014 15:27:29 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0065.outbound.protection.outlook.com [207.46.100.65]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24E771ABD3C for ; Wed, 29 Oct 2014 15:27:29 -0700 (PDT)
Received: from BY2PR06MB582.namprd06.prod.outlook.com (10.141.221.148) by BY2PR06MB026.namprd06.prod.outlook.com (10.242.45.12) with Microsoft SMTP Server (TLS) id 15.1.6.9; Wed, 29 Oct 2014 22:27:27 +0000
Received: from ISOC-REM-MBA2187.local (50.200.68.226) by BY2PR06MB582.namprd06.prod.outlook.com (10.141.221.148) with Microsoft SMTP Server (TLS) id 15.1.6.9; Wed, 29 Oct 2014 22:27:24 +0000
Message-ID: <545169C6.7050105@isoc.org>
Date: Wed, 29 Oct 2014 15:27:18 -0700
From: Karen ODonoghue 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: 
References: <54515707.3050704@sunet.se> <7B384730-5281-4EDB-BDE8-0BE4CBF3469C@sunet.se> <1FC55179-A286-4DB3-A16D-AE2F43B6D343@wierenga.net> <76EFAB58-BAFE-4A62-BCCB-B19AF8C9DDD1@sunet.se> <2B8556F1-10C4-4AF6-AE76-E7BECF637B1D@mitre.org>
In-Reply-To: <2B8556F1-10C4-4AF6-AE76-E7BECF637B1D@mitre.org>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [50.200.68.226]
X-ClientProxiedBy: BN1PR02CA0047.namprd02.prod.outlook.com (10.141.56.47) To BY2PR06MB582.namprd06.prod.outlook.com (10.141.221.148)
X-MS-Exchange-Transport-FromEntityHeader: Hosted
X-Microsoft-Antispam: UriScan:;UriScan:;
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BY2PR06MB582;
X-Forefront-PRVS: 03793408BA
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6009001)(377454003)(479174003)(51704005)(24454002)(189002)(199003)(76176999)(86362001)(120916001)(15975445006)(101416001)(83506001)(110136001)(31966008)(77096002)(50986999)(19580395003)(19580405001)(92566001)(65816999)(80316001)(33656002)(23756003)(21056001)(97736003)(36756003)(87266999)(42186005)(54356999)(76482002)(59896002)(4396001)(46102003)(80022003)(106356001)(66066001)(65956001)(105586002)(107886001)(20776003)(85306004)(93886004)(64706001)(95666004)(47776003)(85852003)(87976001)(2351001)(92726001)(107046002)(40100003)(50466002)(122386002)(99396003)(65806001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR06MB582; H:ISOC-REM-MBA2187.local; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BY2PR06MB026;
X-OriginatorOrg: isoc.org
Archived-At: http://mailarchive.ietf.org/arch/msg/vot/uiWNYW0UA7A4IshXEfp-2o9a-k8
Subject: Re: [VoT] bar-bof @ IETF90
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Vectors of Trust discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 22:27:31 -0000

I also can do either with a slight preference for 1.

On 10/29/14, 3:23 PM, Richer, Justin P. wrote:
> I'm fine with either of these and slightly preferential toward 1.
>
>   -- Justin
>
> On Oct 29, 2014, at 5:35 PM, Leif Johansson  wrote:
>
>>
>>
>>
>>> 29 okt 2014 kl. 17:23 skrev Klaas Wierenga :
>>>
>>> I think i can do all except 2
>> And I just had to take 3 off the table so we're down to 1 & 4.
>>
>>> Sent from my iPhone
>>>
>>>> On 29 Oct 2014, at 22:18, Leif Johansson  wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> 29 okt 2014 kl. 17:09 skrev Leif Johansson :
>>>>>
>>>>>
>>>>>
>>>>> Here are the possibilities I can see:
>>>>>
>>>>> 1. Monday night after the technical plenary (~19).
>>>> ftr this would be my personal preference...
>>>>
>>>>> 2. Tuesday instead of the social.
>>>>> 3. Wednesday night after the admin plenary (or instead of part of it maybe)
>>>>> 4. Thursday afternoon before bits-n-bites (18:30 maybe)
>>>>>
>>>>> I think 1 or 4 would be the best option.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> Cheers Leif
>>>>>
>>>>> _______________________________________________
>>>>> vot mailing list
>>>>> vot@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/vot
>>>> _______________________________________________
>>>> vot mailing list
>>>> vot@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/vot
>>> _______________________________________________
>>> vot mailing list
>>> vot@ietf.org
>>> https://www.ietf.org/mailman/listinfo/vot
>> _______________________________________________
>> vot mailing list
>> vot@ietf.org
>> https://www.ietf.org/mailman/listinfo/vot
> _______________________________________________
> vot mailing list
> vot@ietf.org
> https://www.ietf.org/mailman/listinfo/vot


From nobody Wed Oct 29 15:32:19 2014
Return-Path: 
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D15391AC3B1 for ; Wed, 29 Oct 2014 15:32:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4QjscBM747sn for ; Wed, 29 Oct 2014 15:32:16 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0075.outbound.protection.outlook.com [207.46.100.75]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 365A71AC3AE for ; Wed, 29 Oct 2014 15:32:16 -0700 (PDT)
Received: from BLUPR06MB243.namprd06.prod.outlook.com (10.242.191.154) by BLUPR06MB225.namprd06.prod.outlook.com (10.242.191.139) with Microsoft SMTP Server (TLS) id 15.1.11.14; Wed, 29 Oct 2014 22:32:14 +0000
Received: from BLUPR06MB243.namprd06.prod.outlook.com (10.242.191.154) by BLUPR06MB243.namprd06.prod.outlook.com (10.242.191.154) with Microsoft SMTP Server (TLS) id 15.1.6.9; Wed, 29 Oct 2014 22:32:08 +0000
Received: from BLUPR06MB243.namprd06.prod.outlook.com ([169.254.7.249]) by BLUPR06MB243.namprd06.prod.outlook.com ([169.254.7.249]) with mapi id 15.01.0006.000; Wed, 29 Oct 2014 22:32:08 +0000
From: Steve Olshansky 
To: "vot@ietf.org" 
Thread-Topic: [VoT] bar-bof @ IETF90
Thread-Index: AQHP87xeWLZxfBhB3EKvam80/ChUnpxHlFYAgAABCICAAAPDgIAADT6AgAABJwCAAAFYgA==
Date: Wed, 29 Oct 2014 22:32:08 +0000
Message-ID: <3E8A42F6-0567-48FC-AC28-F7713E2411BD@isoc.org>
References: <54515707.3050704@sunet.se> <7B384730-5281-4EDB-BDE8-0BE4CBF3469C@sunet.se> <1FC55179-A286-4DB3-A16D-AE2F43B6D343@wierenga.net> <76EFAB58-BAFE-4A62-BCCB-B19AF8C9DDD1@sunet.se> <2B8556F1-10C4-4AF6-AE76-E7BECF637B1D@mitre.org> <545169C6.7050105@isoc.org>
In-Reply-To: <545169C6.7050105@isoc.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [38.123.9.3]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB243;UriScan:;
x-exchange-antispam-report-test: UriScan:;
x-forefront-prvs: 03793408BA
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(24454002)(51704005)(199003)(479174003)(189002)(377454003)(83716003)(64706001)(99936001)(92726001)(85852003)(86362001)(120916001)(80022003)(36756003)(31966008)(2656002)(87936001)(99396003)(106116001)(20776003)(50986999)(93886004)(19580405001)(106356001)(85306004)(46102003)(76176999)(19580395003)(101416001)(97736003)(99286002)(105586002)(4396001)(110136001)(33656002)(2351001)(54356999)(122556002)(92566001)(21056001)(77096002)(2501002)(82746002)(95666004)(76482002)(66066001)(107886001)(15974865002)(107046002)(15975445006)(40100003)(104396001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB243; H:BLUPR06MB243.namprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
Content-Type: multipart/signed; boundary="Apple-Mail=_B6B5A74A-3196-44B1-8E6F-4A92E90370D4"; protocol="application/pgp-signature"; micalg=pgp-sha1
MIME-Version: 1.0
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR06MB225;
X-OriginatorOrg: isoc.org
Archived-At: http://mailarchive.ietf.org/arch/msg/vot/TVJbqh-zuYjGItu2dHZBqgGowNo
Subject: Re: [VoT] bar-bof @ IETF90
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Vectors of Trust discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Oct 2014 22:32:18 -0000

--Apple-Mail=_B6B5A74A-3196-44B1-8E6F-4A92E90370D4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Same - Monday or Thursday with a slight preference for Monday.=09
	Steve

--
Steve Olshansky
Trust & Identity Program Lead
Internet Society
www.internetsociety.org

On Oct 29, 2014, at 6:27 PM, Karen ODonoghue  wrote:

> I also can do either with a slight preference for 1.
>=20
> On 10/29/14, 3:23 PM, Richer, Justin P. wrote:
>> I'm fine with either of these and slightly preferential toward 1.
>>=20
>>  -- Justin
>>=20
>> On Oct 29, 2014, at 5:35 PM, Leif Johansson  wrote:
>>=20
>>>=20
>>>=20
>>>=20
>>>> 29 okt 2014 kl. 17:23 skrev Klaas Wierenga :
>>>>=20
>>>> I think i can do all except 2
>>> And I just had to take 3 off the table so we're down to 1 & 4.
>>>=20
>>>> Sent from my iPhone
>>>>=20
>>>>> On 29 Oct 2014, at 22:18, Leif Johansson  wrote:
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>> 29 okt 2014 kl. 17:09 skrev Leif Johansson :
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> Here are the possibilities I can see:
>>>>>>=20
>>>>>> 1. Monday night after the technical plenary (~19).
>>>>> ftr this would be my personal preference...
>>>>>=20
>>>>>> 2. Tuesday instead of the social.
>>>>>> 3. Wednesday night after the admin plenary (or instead of part of =
it maybe)
>>>>>> 4. Thursday afternoon before bits-n-bites (18:30 maybe)
>>>>>>=20
>>>>>> I think 1 or 4 would be the best option.
>>>>>>=20
>>>>>> Thoughts?
>>>>>>=20
>>>>>> Cheers Leif
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> vot mailing list
>>>>>> vot@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/vot
>>>>> _______________________________________________
>>>>> vot mailing list
>>>>> vot@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/vot
>>>> _______________________________________________
>>>> vot mailing list
>>>> vot@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/vot
>>> _______________________________________________
>>> vot mailing list
>>> vot@ietf.org
>>> https://www.ietf.org/mailman/listinfo/vot
>> _______________________________________________
>> vot mailing list
>> vot@ietf.org
>> https://www.ietf.org/mailman/listinfo/vot
>=20
> _______________________________________________
> vot mailing list
> vot@ietf.org
> https://www.ietf.org/mailman/listinfo/vot


--Apple-Mail=_B6B5A74A-3196-44B1-8E6F-4A92E90370D4
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="signature.asc"
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----

iQEcBAEBAgAGBQJUUWrnAAoJEOJO4+877g3HFjUIALSo7KiRbeY83YSSnBv1gkHn
+Yjorex8OOD0o42UsUbCA6dZhmwaEAs+CSVir+cgvuYnNE9KU1mBZGXJixF1XEdd
5Nkbf4f2XDvxdH+ZD2JkCytoddmtm7Us/GVnsnhU9FtIALrmWi2iBj77d+oqqOG6
DF7O4kmm4mDa09FdPVQT7OrPU5gfKfynhVSuDWzm5/8nTSq+ML6PL3px+kDqdv5F
hhOsGSkP4n0FgXLtW1yNL24aAbneDOnDeHRfgSOJ4NNcTiIHsdeyJmEzxivtOh0z
SaWp8EXunG7lQe73y1yDiMCs+SLB+xMGQFRDKqnHrVtI0Q3emR/HaZjpDzNoNqI=
=bzC5
-----END PGP SIGNATURE-----

--Apple-Mail=_B6B5A74A-3196-44B1-8E6F-4A92E90370D4--


From nobody Wed Oct 29 17:37:46 2014
Return-Path: 
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A77F71ACE74 for ; Wed, 29 Oct 2014 17:37:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.781
X-Spam-Level: 
X-Spam-Status: No, score=-0.781 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8WycXsPpqhYt for ; Wed, 29 Oct 2014 17:37:43 -0700 (PDT)
Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (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 1C09E1ACE82 for ; Wed, 29 Oct 2014 17:37:42 -0700 (PDT)
Received: from smtp1.sunet.se (smtp1.sunet.se [IPv6:2001:6b0:8:2::214]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id s9U0be0n031618 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 30 Oct 2014 01:37:41 +0100
Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.7/8.14.7) with ESMTP id s9U0bccJ010405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 30 Oct 2014 01:37:40 +0100 (CET)
X-Footer: c3VuZXQuc2U=
Received: from [192.168.0.100] ([38.123.9.3]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.3.3) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256 bits)) for vot@ietf.org; Thu, 30 Oct 2014 01:37:36 +0100
Message-ID: <5451884E.6010702@sunet.se>
Date: Thu, 30 Oct 2014 01:37:34 +0100
From: Leif Johansson 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: vot@ietf.org
References: <54515707.3050704@sunet.se> <7B384730-5281-4EDB-BDE8-0BE4CBF3469C@sunet.se> <1FC55179-A286-4DB3-A16D-AE2F43B6D343@wierenga.net> <76EFAB58-BAFE-4A62-BCCB-B19AF8C9DDD1@sunet.se> <2B8556F1-10C4-4AF6-AE76-E7BECF637B1D@mitre.org> <545169C6.7050105@isoc.org> <3E8A42F6-0567-48FC-AC28-F7713E2411BD@isoc.org>
In-Reply-To: <3E8A42F6-0567-48FC-AC28-F7713E2411BD@isoc.org>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-sunet-se:default, sunet-se:default, base:default, @@RPTN)
X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=62.0000; longitude=15.0000; http://maps.google.com/maps?q=62.0000,15.0000&z=6
X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default)
X-Canit-Stats-ID: 09N9cBFP3 - e59ad234dde6 - 20141030
X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw
X-Scanned-By: CanIt (www . roaringpenguin . com)
Archived-At: http://mailarchive.ietf.org/arch/msg/vot/Vw479niZ8OanD2TaOP04L3CNs9Q
Subject: Re: [VoT] bar-bof @ IETF90
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Vectors of Trust discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Oct 2014 00:37:44 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2014-10-29 23:32, Steve Olshansky wrote:
> Same - Monday or Thursday with a slight preference for Monday. 
> Steve

That settles it - monday night it is. Lets meet by the registration
after the plenary.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAlRRiEkACgkQ8Jx8FtbMZnf1CwCgmlOQHkblNVhzGPWKyGks56y9
nscAnRGolTmt/n8p96mhhwua3YqPyiJ6
=BoVu
-----END PGP SIGNATURE-----