Re: existing identifiers for people

Matt .. what you are generally referring to when you ask the important question “How will we express the rigor of identity check that a Verifiable Credential has undergone?”  is a trust framework. This is an overly fancy term for … what are the processes behind the issuance of a verifiable credential and do I believe they meet my needs.

When a person presents proof of identity in the physical world, as you describe, they present something like a drivers licence or passport. Implicitly most of us trust these documents because they are “government issued”. “Government issued” means we believe that the government is a recognized authority to make statements about personal identity and they are appropriately managing the processes associated with issuance.

This is exactly the same for digital identity. In Canada, where our provinces are generally responsible for foundational identity events (birth) and the federal government is responsible for citizenship (immigration from abroad), we are working on this exact scenario. We are jointly describing a set of trusted processes which pertain to the issuance of digital identity. We call this the Verified Person component of the Pan-Canadian Trust Framework<https://github.com/canada-ca/PCTF>. The Verified Person Component ensures that an individual has been properly verified and ensures that he or she is the right recipient of program, service or transaction. Within this component a series of processes are described which describe the steps from foundational data (birth, immigration) to digital identity issuance that we hope all jurisdiction in Canada will all implement in some way. If this happens then we can mutually recognize and trust these “Government Issued” digital identities and we can bring to the digital economy a new level of trust which we think can surpasses what we have in the physical world. Why surpass? Well, it is a lot easier to forge a document than it is to forge a verifiable credential that makes use of the kinds of cryptographic technique enabled by DIDs and the fancy math!

So when our civil engineer connects to the Engineering Societies issuance service, the society should request some evidence of who that person is and perhaps their engineering degree from an accredited institution. That is the societies process for issuance. Our engineer should then be able to offer a government issued digital identity and a digital representation of her degree to the society which it can then verify digitally AND decide if those issuers are “trusted”. Trust is at least two parts here .. the ability to transmit bits between the two peers in a trustworthy way (from issuer to holder and unaltered) AND the trust that must exist in the human/social realm between the entities based on law, trusted processes, or whatever other appropriate means.

All kinds of other “identity” attributes can be issued and verified from other sources that could range from your local sports club to a university or so on. I think this article<http://www.windley.com/archives/2018/05/multi-source_identity.shtml> by Phil Windley is a nice description of this “multi-source identity” world. I believe this describes the other part of your email where a human has a number of different facets to their “identity” they need to prove in a particular service context.

All of these credentials are issued to a specific holder … who is making use of DIDs underlying all of these issuance and proving actions. The implementations of which (e.g. Sovrin/Indy, Veres One, uPort, DIF ID Hubs, etc) should mathematically allow the holder to demonstrate control over the credentials (and underlying DIDs) such that a verifier can be sure that the holder was issued the credentials from the issuer.

Hope that is helpful.
Have a great day.
John




From: "Stone, Matt" <matt.stone@pearson.com>
Date: Tuesday, June 12, 2018 at 1:00 PM
To: Samantha Mathews <samantha@venn.agency>
Cc: John Jordan <John.Jordan@gov.bc.ca>, "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>> 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

On Tue, Jun 12, 2018 at 12:06 PM, Jordan, John CITZ:EX <John.Jordan@gov.bc.ca<mailto: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>>
Date: Tuesday, June 12, 2018 at 10:11 AM
To: "public-credentials@w3.org<mailto:public-credentials@w3.org>" <public-credentials@w3.org<mailto:public-credentials@w3.org>>
Subject: Re: existing identifiers for people
Resent-From: <public-credentials@w3.org<mailto: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=0YLnzTkWOdJlub_y7qAx8Q&r=KheINWPzU3x8Jj96NXLwS0k5Y5jGbk-Gi1U5Cdx5914&m=LxoFG_fvziQ3r1xoEekGOmpx131G82wdxFZ-7BD1hSs&s=lD9XYwlyK_WRn8Q97uUKXw23NW_lZFAGuuJeDLoFLeA&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=KheINWPzU3x8Jj96NXLwS0k5Y5jGbk-Gi1U5Cdx5914&m=LxoFG_fvziQ3r1xoEekGOmpx131G82wdxFZ-7BD1hSs&s=KI1N-3aWjGWE1faJyA812OrASe5WEjy-NdUFZ3NKEHY&e=>

[2] http://www.isni.org/<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.isni.org_&d=DwMFaQ&c=0YLnzTkWOdJlub_y7qAx8Q&r=KheINWPzU3x8Jj96NXLwS0k5Y5jGbk-Gi1U5Cdx5914&m=LxoFG_fvziQ3r1xoEekGOmpx131G82wdxFZ-7BD1hSs&s=RQlvMbU-sdcbPsXK5xqlBanIhTd01El7iEw78SQCloM&e=>

*Tzviya Siegman*

Information Standards Lead

Wiley

201-748-6884

tsiegman@wiley.com<mailto:tsiegman@wiley.com><mailto:tsiegman@wiley.com<mailto:tsiegman@wiley.com>> <mailto:tsiegman@wiley.com<mailto:tsiegman@wiley.com>><mailto:tsiegman@wiley.com<mailto:tsiegman@wiley.com>>


--

Phil Barker<http://people.pjjk.net/phil<https://urldefense.proofpoint.com/v2/url?u=http-3A__people.pjjk.net_phil&d=DwMFaQ&c=0YLnzTkWOdJlub_y7qAx8Q&r=KheINWPzU3x8Jj96NXLwS0k5Y5jGbk-Gi1U5Cdx5914&m=LxoFG_fvziQ3r1xoEekGOmpx131G82wdxFZ-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=KheINWPzU3x8Jj96NXLwS0k5Y5jGbk-Gi1U5Cdx5914&m=LxoFG_fvziQ3r1xoEekGOmpx131G82wdxFZ-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=>>: 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=>>: 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

Received on Tuesday, 12 June 2018 20:45:20 UTC