Re: existing identifiers for people

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>
Date: Tuesday, June 12, 2018 at 10:11 AM
To: "public-credentials@w3.org" <public-credentials@w3.org>
Subject: Re: existing identifiers for people
Resent-From: <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


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/


[2] http://www.isni.org/


*Tzviya Siegman*

Information Standards Lead

Wiley

201-748-6884

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


--

Phil Barker<http://people.pjjk.net/phil>. http://people.pjjk.net/phil

PJJK Limited<https://www.pjjk.co.uk>: technology to enhance learning; information systems for education.
CETIS LLP<https://www.cetis.org.uk>: 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 19:07:12 UTC