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