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> 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]
> *Sent:* Tuesday, June 12, 2018 4:00 PM
> *To:* Samantha Mathews <samantha@venn.agency>
> *Cc:* Jordan, John CITZ:EX <John.Jordan@gov.bc.ca>;
> 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>
> 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 <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
>
>
>
>
>