Re: existing identifiers for people

Agreed. If its private by default, it shouldn't limit my ability to
disclose as I see fit.

On Thu, Jun 14, 2018 at 8:38 AM, Challener, David C. <
David.Challener@jhuapl.edu> wrote:

> Ah – but I think it should be an individual decision. If I make my life
> easier by letting people know I am a celebrity (I am not), then that is my
> right.  I read a funny story about someone who thought they wanted to be
> anonymous as a celebrity, but after trying it for a bit decided they
> appreciated the perks they got when people did know it.   The point is,
> that we should not make decisions for other people “in their best
> interests” – unless they are our children.
>
>
>
> *From:* Mike Lodder [mailto:mike.lodder@evernym.com]
> *Sent:* Thursday, June 14, 2018 10:01 AM
> *To:* Challener, David C. <David.Challener@jhuapl.edu>
> *Cc:* Sam Smith <sam.smith@sovrin.org>; Jordan, John CITZ:EX <
> John.Jordan@gov.bc.ca>; Stone, Matt <matt.stone@pearson.com>; W3C
> Credentials Community Group <public-credentials@w3.org>
>
> *Subject:* Re: existing identifiers for people
>
>
>
> Well said Sam. Even if there is data I don't mind if others know, I might
> not want others to know because any information leakage could correlate me
> eventually (strong problem) but enhances limits in the short term or to
> those who don't have the resources to correlate me (weak problem).
>
>
>
> +1
>
>
>
> On Thu, Jun 14, 2018 at 7:24 AM, Challener, David C. <
> David.Challener@jhuapl.edu> wrote:
>
> Sam, I like what you say.
>
> I also think that there are different categories of things – some we don’t
> mind people knowing and some which we do.  That I graduated from a
> particular high school or have a PhD are not really privacy type things
> (You can look up someone’s thesis on the ‘net after all). But how much
> money I have is not something I would share generally. So labeling
> everything as being private data seems wrong.
>
>
>
> *From:* Sam Smith [mailto:sam.smith@sovrin.org]
> *Sent:* Wednesday, June 13, 2018 3:34 PM
> *To:* Challener, David C. <David.Challener@jhuapl.edu>
> *Cc:* Jordan, John CITZ:EX <John.Jordan@gov.bc.ca>; Stone, Matt <
> matt.stone@pearson.com>; W3C Credentials Community Group <
> public-credentials@w3.org>
>
>
> *Subject:* Re: existing identifiers for people
>
>
>
> In general privacy is an ephemeral quality.  It tends to decrease over
> time as diclosures or interactions happen.
>
> Its helpful to me to phrase it as the Strong Problem of privacy and the
> Weak Problem of Privacy.
>
>
>
> The strong problem is not solvable given correlators with essentially
> unlimited data storage and compute capability. Any set of disclosures may
> be correlated given enough time etc.
>
>
>
> The weak problem is solvable. The weak problem is that correlation has a
> cost. Building privacy systems such that the cost of correlation exceeds
> the value of the correlated data is a solvable problem.  Over time the
> value of correlation diminishes. Correlating what I did ten years ago in
> terms of privacy preservation is not nearly so important or harmful to me
> as correlating what I am doing now.   IMHO DIDs are meant to solve the weak
> problem.  Going down the rabbit hole of trying to solve the Strong problem
> usually does not end well.
>
>
>
>
>
> On 13 Jun 2018, at 07:54 , Challener, David C. <David.Challener@jhuapl.edu>
> wrote:
>
>
>
> You say: " Of course, issuers need to properly manage their keys,
> especially their private ones"
> And of course they should.  But if there is no list of things that are
> signed, it is not easily possible to TELL.  And that leads to the scenarios
> that are actually happening today, where supposed good keys are used to
> sign malware.
>
> -----Original Message-----
> From: Jordan, John CITZ:EX [mailto:John.Jordan@gov.bc.ca
> <John.Jordan@gov.bc.ca>]
> Sent: Wednesday, June 13, 2018 9:51 AM
> To: Challener, David C. <David.Challener@jhuapl.edu>
> Cc: Stone, Matt <matt.stone@pearson.com>; W3C Credentials Community Group
> <public-credentials@w3.org>
> Subject: Re: existing identifiers for people
>
> Ok ... I’m not an expert in crypto ... the point I was responding to was
> to be concerned about a surveillance pattern when citizens use their Govt
> issued identity. That is not trust building. Of course we are proceeding
> purposely and carefully and doing our work in the open so we can benefit
> from the community.
>
> I’m not sure the scenario you describe is applicable since we do know what
> our issuer service has signed and there will be a well known DID / DID doc
> under the control of the government ID issuing service that is presumable
> immutable given the properties of the decentralized ledger. If some bad
> actor tries to create fake ID then they should fail as verifiers should be
> aware of the authoritative DIDs for the issuers they trust. Of course,
> issuers need to properly manage their keys, especially their private ones.
>
> As far as weak crypto, my experience thus far is the community is being
> very deliberate about the algorithm and key specifications so this should
> be mitigated by properly vetted standards.
>
> On Jun 13, 2018, at 06:39, Challener, David C. <David.Challener@jhuapl.edu>
> wrote:
>
> I think if you explicitly exclude those types of things you are making a
> bad mistake.
> We currently have malware being signed by keys that are from device driver
> manufacturers.  It isn't clear if the private key was compromised, the key
> was weak, or someone was bribed, etc.   But this shows one of the main
> problems with certificates -- there is no authoritative list of what has
> been signed, so it is hard to determine that something is out there,
> purporting to have been signed, when in fact it was not signed with
> authority.
> If you make this an anti-pattern, it looks to me as though you have made
> it impossible to solve this problem.
> Since the signing authority presumably knows that it signed the
> certificate, all it is getting back is that the cert is being used. Where
> and how can be obscured.
>
> -----Original Message-----
> From: Jordan, John CITZ:EX [mailto:John.Jordan@gov.bc.ca
> <John.Jordan@gov.bc.ca>]
> Sent: Wednesday, June 13, 2018 9:34 AM
> To: Challener, David C. <David.Challener@jhuapl.edu>
> Cc: Stone, Matt <matt.stone@pearson.com>; W3C Credentials Community
> Group <public-credentials@w3.org>
> Subject: Re: existing identifiers for people
>
> For sure there is no ping back to the issuer at verification time
> (including revocation checks) ... that is an anti-pattern that we intend to
> be specifically including at our policy level when we evaluation these
> kinds of network based solutions.
>
> Interesting about the verification post the demise of an organization.
> Technically doable .. it will be a social level decision if those
> credentials have any weight depending on the context they were issued under
> I expect.
>
> As a side note, my colleague Stephen Curran has been working out how to do
> offline verification which we think is a reasonable and interesting use
> case for verifiable credentials.
>
> On Jun 13, 2018, at 06:26, Challener, David C. <David.Challener@jhuapl.edu
> <mailto:David.Challener@jhuapl.edu <David.Challener@jhuapl.edu>>> wrote:
>
> And the approach that was written up – that specifically had the
> credentialing authority check if the credential had been revoked doesn’t
> need (or observe) either 1 or 2, so if those are hard requirements then the
> use case fails.
>
> From: Stone, Matt [mailto:matt.stone@pearson.com <matt.stone@pearson.com>]
> Sent: Tuesday, June 12, 2018 5:06 PM
> To: Challener, David C.
> <David.Challener@jhuapl.edu<mailto:David.Challener@jhuapl.edu
> <David.Challener@jhuapl.edu>>>
> Cc: W3C Credentials Community Group
> <public-credentials@w3.org<mailto:public-credentials@w3.org
> <public-credentials@w3.org>>>
> Subject: Re: existing identifiers for people
>
> This approach speaks to a couple of requirements from the working group...
>
> 1.  Verifiable Credentials must be privacy respecting and support
> non-correlation  2.  Verifiable Credentials must continue to verify even
> if the issuer goes out of business, is non-functional, or unreachable.
>
>    *   unless a verifier needs a deeper proof, they don't have to call the
> state to see, and understand and trust a physical driver's license (and the
> state never knows it was presented)
> Both of these cases require that the VC verify w/out the issuer being
> party to the transaction.  If the VC validates, then the verifier can trust
> that the statement was made by that issuer on that date.  Whether it's
> still true today is another question entirely.  This will be solved by some
> protocol magic that isn't fully invented yet.  There is a simplistic
> placeholder in the data model spec that provides a revocation list - one
> that the issuer would maintain.  So in the engineer example, as the
> Verifier is verifying the VC, if the VC includes a URL to a revocation
> list, the verifier must/should/could check there also (the purpose of the
> verification and the needs of the verifier determines whether this is a
> MUST or optional step).
>
> The revocation list does open up a privacy question relating to
> non-correlation.  The sovereign foundation's approach support zero
> knowledge proofs deal with revoking and rescinding credentials in a
> different way - one that relies on both data and protocol implementation.
> This is out of scope of the Working Groups's current charter, but it's
> exciting to see it emerge.
>
> -stone
>
>
> =====
> Matt Stone
> 501-291-1599
>
>
> On Tue, Jun 12, 2018 at 2:09 PM, Challener, David C. <
> David.Challener@jhuapl.edu<mailto:David.Challener@jhuapl.edu
> <David.Challener@jhuapl.edu>>> wrote:
> What I don’t understand is the ability to revoke the credential appears to
> require the verifier to go back to the issuer to see if the credential is
> revoked. “the society can simply mark the DID as not active in some way on
> it’s end of the connection”
> If this is true, then I don’t understand why the verifier doesn’t go to
> the society to see if it is valid initially – “Here is a DiD. Are they
> credentialed?” instead of “Here is a credential. Is it valid?”
> It appears to entail less work, and additionally more secure, as the
> society would always have a list of credentialed DiDs, so if someone
> internally was bribed and got control of a private key, it would be obvious
> that an invalid credential had appeared.
>
> From: Stone, Matt
> [mailto:matt.stone@pearson.com <matt.stone@pearson.com><
> mailto:matt.stone@pearson.com <matt.stone@pearson.com>>]
> Sent: Tuesday, June 12, 2018 4:00 PM
> To: Samantha Mathews
> <samantha@venn.agency<mailto:samantha@venn.agency <samantha@venn.agency>>>
> Cc: Jordan, John CITZ:EX
> <John.Jordan@gov.bc.ca<mailto:John.Jordan@gov.bc.ca
> <John.Jordan@gov.bc.ca>>>;
> public-credentials@w3.org<mailto:public-credentials@w3.org
> <public-credentials@w3.org>>
>
> Subject: Re: existing identifiers for people
>
> Proving a representation of personal Idenitiy will likely have multiple
> mechanisms.
>
> *   The Civil Engineer, in this case must have a DID and convince the
> Engineering Society to issue the credential to that DID.
> *   The engineering society must have a process to confirm and trust that
> the DID is in fact owned and controlled by the Engineer who took the test
> and met the requirements for certification and licensure.
> *   Subsequently when the engineer presents the verifiable credential to
> the prospective employer for verifications, she must also provide proof
> that the she is the owner/controller of the DID in the credential, in other
> words, she much establish her digital identity w/ the employer before they
> could trust the credential is relevant to this transaction.
> Who or which organization(s), new or existing, will facilitate that
> specific coordination between physical and digital worlds?  In the physical
> world, we trust things like drivers's licenses and passports, so perhaps a
> regulatory body will continue to play that role, by issuing a verified
> credentials that validates the engineer's identity.  The engineer would
> include that in the application w/ the society and perhaps in the
> presentation to the employer.
>
> This  probably opens a new market place for physical identity
> verification, in the cases that require this level of proof.  The
> fundamental requirement is that the Verifier knows the mechanism that the
> Issuer used to validate the identity of the DID holder to whom the
> credential was issued, and agrees that this mechanism meets their
> requirements for the verification transaction.
>
> How will we express the rigor of identity check that a Verifiable
> Credential has undergone?  Is there such a thing as "rigor of identity
> check" or, simply another issuer that is "trustworthy"?
>
> -stone
>
>
> =====
> Matt Stone
> 501-291-1599
>
>
> On Tue, Jun 12, 2018 at 1:22 PM, Samantha Mathews <samantha@venn.agency<
> mailto:samantha@venn.agency <samantha@venn.agency>>> wrote:
> +1
> thank-you for explaining this, much clearer to me now.
>
> Samantha Mathews
> -------------------------------------------------------
> Co-Founder & CEO, Venn.Agency
> The best way to predict the future is to build it.
> Phone: 323-740-9425  Linkedin
> -------------------------------------------------------
> samantha@venn.agency<mailto:samantha@venn.agency <samantha@venn.agency>>
>
> On Tue, Jun 12, 2018 at 12:06 PM, Jordan, John CITZ:EX <
> John.Jordan@gov.bc.ca<mailto:John.Jordan@gov.bc.ca <John.Jordan@gov.bc.ca>>>
> wrote:
> So … I think there is a somewhat problematic conceptual issue here around
> what DIDs are and how they could be deployed.
>
> DIDs are not identifiers that directly map to a person or any other
> entity/thing … in fact I think that is a rather strong anti-pattern. DIDs,
> I think, are more accurately describable as an address to the DID Doc which
> itself tends to contain some form of public key material and an endpoint
> where a piece of software can be connected to.
>
> DIDs (and the DID Doc) enable a connection between two pieces of software
> that can negotiate a secure peer to peer channel. Those pieces of software
> could be under the control of a person representing themselves, or
> representing a legal entities such as a business or perhaps a thing. In any
> of these cases there is an exchange between the peers whereby the two
> pieces of software use a pair of DIDs (ideally unique to that particular
> connection but not necessarily) to create this connection using information
> contained in the DID Doc. The material in the DID Doc is cryptographic key
> material necessary to establish a one or two way signed authentication as
> well as the endpoint where the connection can be made.
>
> Once this secure digital channel is established … then the two pieces of
> software, under the direction of a human, or perhaps some rules that were
> configured/programmed by humans, engage in an exchange of data to create a
> relationship. This data exchange is what determines the nature of the
> relationship between the parties that are controlling the software.
>
> Consider the following pattern:
>
> Issuer <====> Holder <====> Verifier
>
> And let’s assume the Issuer is the Engineering Society, the Holder is an
> accredited Civil Engineer, and the Verifier is a person wanting to hire a
> Civil Engineer. For the sake of simplicity, we are leaving out that these
> folks all work for some form of legal entity. We will assume these are
> direct peer to peer interactions directly between people with appropriate
> software.
>
> In our scenario where, the verifier would like the engineer to prove to
> him that she is an accredited civil engineer so he can hire her. The
> engineer has a verifiable credential in her software that was issued to her
> by the engineering society and she would like to use that credential to
> prove she is an engineer so she can get the job.
>
> This is the realm of verifiable credentials … a new form of digital data
> and interactions where issuers (Engineering Society) can ofer a new form of
> data (verifiable credential) to a holder (our Civil Engineer) such that the
> Holder can share that credential with another party (Verifier). The
> verifier is then able to independently verify the integrity and source of
> this data without the involvement of the issuer.
>
> Verifiable credentials are possible because of DIDs and its associated DID
> Doc.
>
> In our scenario, the verifiable credential the engineer offers to her
> prospective employer is verifiable because the issuer has a publicly
> available DID and DID Doc which contains the cryptographic key material
> necessary to verify the credential in play in this interaction. The
> verifier knows this DID because it is embedded in the verifiable
> credential. Right here we can see that the issuer may now have at least two
> DIDs, its public DID (used to allow verifiers to verify credentials the
> Engineering Society issues) and potentially a different DID specific to the
> connection it has with the holder, our engineer. This way if the
> Engineering society wishes to disable the connection with the engineer, say
> our engineer decides to retire and not renew her status, the society can
> simply mark the DID as not active in some way on it’s end of the
> connection. The society would still have its public DID as presumably it is
> still issuing accreditation credentials to others.
>
> It is the nature of the verifiable credentials that determine the nature
> of the relationship. In our scenario, the verifying person looking to hire
> this engineer uses his software to verify the credential. However, it is a
> business decision by humans to decide if they give any trust to the
> credential based on their belief that the Engineering Society is a
> legitimate issuer of accreditations for engineers. Normally this is true in
> the case of engineers as there will be a law in the jurisdiction governing
> the society. In other cases, it could be another kind of specialized body
> that does the issuing such as a better business bureau, or a researcher
> network, etc.
>
> None of this trust has to do with the DID itself. The DID is simple the
> means by which the two pieces of software can reliably connect.
>
> What is think is happening in some of these discussions and DID use cases
> is there is a conflation of DID, Verifiable Credentials, and in some cases
> the “meaning” that can be conveyed in the human realm by what a Verifiable
> Credential(s) represent (eg an engineering accreditation issued by a
> legally authorized engineering society).
>
> John
>
>
>
>
> From: Phil Barker
> <phil.barker@pjjk.co.uk<mailto:phil.barker@pjjk.co.uk
> <phil.barker@pjjk.co.uk>>>
> Date: Tuesday, June 12, 2018 at 10:11 AM
> To: "public-credentials@w3.org<mailto:public-credentials@w3.org
> <public-credentials@w3.org>>"
> <public-credentials@w3.org<mailto:public-credentials@w3.org
> <public-credentials@w3.org>>>
> Subject: Re: existing identifiers for people
> Resent-From:
> <public-credentials@w3.org<mailto:public-credentials@w3.org
> <public-credentials@w3.org>>>
> Resent-Date: Tuesday, June 12, 2018 at 10:10 AM
>
>
> Presumably there is a use case for someone to be able to assert that their
> DID represents the same person as an ORCID or ISNI?
>
> Phil
>
> On 12/06/18 18:03, Steven Rowat wrote:
> On 2018-06-12 8:50 AM, Siegman, Tzviya wrote:
>
> Hi All,
>
> I’m seeing a lot of use cases for persistent identifiers for people. In
> the STEM world, the ORCID [1] is widely used. Some publishers (like the one
> I work for) require authors to have an ORCID. There is an overlapping
> system called ISNI [2]. These are real-world scenarios that already have
> ecosystems supporting them.
>
> That's very interesting, and the Wikipedia page for it shows that it's
> widespread and increasing rapidly.
> https://en.wikipedia.org/wiki/ORCID<https://urldefense.proofpoint.com/
> v2/url?u=https-3A__en.wikipedia.org_wiki_ORCID&d=DwMFaQ&c=0YLnzTkWOdJl
> ub_y7qAx8Q&r=KheINWPzU3x8Jj96NXLwS0k5Y5jGbk-Gi1U5Cdx5914&m=LxoFG_fvziQ
> 3r1xoEekGOmpx131G82wdxFZ-7BD1hSs&s=lD9XYwlyK_WRn8Q97uUKXw23NW_lZFAGuuJ
> eDLoFLeA&e=>
>
> But it seems to me that it's happening at a different logical layer than
> DID, and that DID will have different capabilities; and so both could be
> used together if DID becomes widespread.
>
> For example, the ORCHID doesn't appear to support pseudonymous use, or
> multiple use, or to be safe for web commerce (via public/private keys); or
> Self-Sovereign Identity in general; the control of the data is by the
> ORCHID organization, which is centralized.
>
> These are just first impressions; perhaps I'm mistaken. But I don't think
> it's solving the same problem DID can potentially solve. ORCHID appears to
> be for researchers embedded in institutions who are using publisher
> organizations, whereas DID is attempting to be useful -- though admittedly
> in a similar way at some points -- for everybody on the internet.
>
> Steven
>
>
>
>
> Tzviya
>
> [1]
> https://orcid.org/<https://urldefense.proofpoint.com/v2/url?u=https-3A
> __orcid.org_&d=DwMFaQ&c=0YLnzTkWOdJlub_y7qAx8Q&r=KheINWPzU3x8Jj96NXLwS
> 0k5Y5jGbk-Gi1U5Cdx5914&m=LxoFG_fvziQ3r1xoEekGOmpx131G82wdxFZ-7BD1hSs&s
> =KI1N-3aWjGWE1faJyA812OrASe5WEjy-NdUFZ3NKEHY&e=>
>
> [2]
> http://www.isni.org/<https://urldefense.proofpoint.com/v2/url?u=http-3
> A__www.isni.org_&d=DwMFaQ&c=0YLnzTkWOdJlub_y7qAx8Q&r=KheINWPzU3x8Jj96N
> XLwS0k5Y5jGbk-Gi1U5Cdx5914&m=LxoFG_fvziQ3r1xoEekGOmpx131G82wdxFZ-7BD1h
> Ss&s=RQlvMbU-sdcbPsXK5xqlBanIhTd01El7iEw78SQCloM&e=>
>
> *Tzviya Siegman*
>
> Information Standards Lead
>
> Wiley
>
> 201-748-6884
>
> tsiegman@wiley.com<mailto:tsiegman@wiley.com <tsiegman@wiley.com>><mailto:
> tsiegman@wiley.co <tsiegman@wiley.co>
> m<mailto:tsiegman@wiley.com <tsiegman@wiley.com>>>
> <mailto:tsiegman@wiley.com <tsiegman@wiley.com><mailto:tsiegman@wiley.com
> <tsiegman@wiley.com>>><mailto:tsiegman
> @wiley.com<mailto:tsiegman@wiley.com <tsiegman@wiley.com>>>
>
>
> --
>
> Phil
> Barker<http://people.pjjk.net/phil<https://urldefense.proofpoint.com/v
> 2/url?u=http-3A__people.pjjk.net_phil&d=DwMFaQ&c=0YLnzTkWOdJlub_y7qAx8
> Q&r=KheINWPzU3x8Jj96NXLwS0k5Y5jGbk-Gi1U5Cdx5914&m=LxoFG_fvziQ3r1xoEekG
> Ompx131G82wdxFZ-7BD1hSs&s=FNX_MNO5D0hI7Fd2uqE2Q28cIBIwY7jbP4sDJxjCT-k&
> e=>>.
> http://people.pjjk.net/phil<https://urldefense.proofpoint.com/v2/url?u
> =http-3A__people.pjjk.net_phil&d=DwMFaQ&c=0YLnzTkWOdJlub_y7qAx8Q&r=Khe
> INWPzU3x8Jj96NXLwS0k5Y5jGbk-Gi1U5Cdx5914&m=LxoFG_fvziQ3r1xoEekGOmpx131
> G82wdxFZ-7BD1hSs&s=FNX_MNO5D0hI7Fd2uqE2Q28cIBIwY7jbP4sDJxjCT-k&e=>
> PJJK Limited<https://www.pjjk.co.uk<https://urldefense.
> proofpoint.com/v2/url?u=https-3A__www.pjjk.co.uk&d=DwMFaQ&c=
> 0YLnzTkWOdJlub_y7qAx8Q&r=KheINWPzU3x8Jj96NXLwS0k5Y5jGbk
> -Gi1U5Cdx5914&m=LxoFG_fvziQ3r1xoEekGOmpx131G82wdxFZ-7BD1hSs&s=RG-
> OuBt9rq6fKKVBNxcf-LhfVaOUKyUUCD2F2PvTmsc&e=>>:
> <https://www.pjjk.co.uk%3chttps:/urldefense.proofpoint.com/v2/url?u=https-3A__www.pjjk.co.uk&d=DwMFaQ&c=0YLnzTkWOdJlub_y7qAx8Q&r=KheINWPzU3x8Jj96NXLwS0k5Y5jGbk-Gi1U5Cdx5914&m=LxoFG_fvziQ3r1xoEekGOmpx131G82wdxFZ-7BD1hSs&s=RG-OuBt9rq6fKKVBNxcf-LhfVaOUKyUUCD2F2PvTmsc&e=%3e%3e:>
> technology to enhance learning; information systems for education.
> CETIS LLP<https://www.cetis.org.uk<https://urldefense.proofpoint.
> com/v2/url?u=https-3A__www.cetis.org.uk&d=DwMFaQ&c=
> 0YLnzTkWOdJlub_y7qAx8Q&r=KheINWPzU3x8Jj96NXLwS0k5Y5jGbk
> -Gi1U5Cdx5914&m=LxoFG_fvziQ3r1xoEekGOmpx131G82wdxFZ-7BD1hSs&s=
> yt9rpvlI30b0gmx3zWVGH9bIMshJRncTkgMzql4cfpc&e=>>:
> <https://www.cetis.org.uk%3chttps:/urldefense.proofpoint.com/v2/url?u=https-3A__www.cetis.org.uk&d=DwMFaQ&c=0YLnzTkWOdJlub_y7qAx8Q&r=KheINWPzU3x8Jj96NXLwS0k5Y5jGbk-Gi1U5Cdx5914&m=LxoFG_fvziQ3r1xoEekGOmpx131G82wdxFZ-7BD1hSs&s=yt9rpvlI30b0gmx3zWVGH9bIMshJRncTkgMzql4cfpc&e=%3e%3e:>
> a cooperative consultancy for innovation in education technology.
>
> PJJK Limited is registered in Scotland as a private limited company,
> number SC569282.
> CETIS is a co-operative limited liability partnership, registered in
> England number OC399090
>
>
>
> Samuel M. Smith Ph.D.
>
> Technical Governance Board
>
> Sovrin Foundation
>
> mobile: 1.801.592.8230
>
> email: sam.smith@sovrin.org <sam.smith@sovrin.org>
>
>
>
>
>
>
>
> --
>
> Mike Lodder
>
> Senior Crypto Engineer
>
>
>
> [image: Image removed by sender.]
>



-- 
Mike Lodder
Senior Crypto Engineer