Re: existing identifiers for people

+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> 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>
> 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
>