Re: existing identifiers for people

On June 12, 2018 02:08:21 pm PDT, "Stone, Matt" 
<matt.stone@pearson.com> wrote:

> 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

These are two key points.

For (2 - Verifiable Credentials must continue to verify even if the 
issuer goes away) it necessitates having a "Date of Issue" readily 
available as part of the proof. It also implies that there may be 
multiple proofs over time to declare that a statement still holds as 
far as the issuer is concerned. Such proofs essentially carry a 
statement forward in time.

Requiring a date to lock an entity in time is a common scenario. If for 
example, you want to use a DNS name to refer to a specific publisher 
without cryptography involved, it is useful to record DNS name + date 
which will allow a lookup as to the ownership of the DNS name at the 
time the statement was made any time in future.

Christoph



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

Received on Tuesday, 12 June 2018 21:34:15 UTC