RE: existing identifiers for people

You say: " Of course, issuers need to properly manage their keys, especially their private ones"
And of course they should.  But if there is no list of things that are signed, it is not easily possible to TELL.  And that leads to the scenarios that are actually happening today, where supposed good keys are used to sign malware. 

-----Original Message-----
From: Jordan, John CITZ:EX [mailto:John.Jordan@gov.bc.ca] 
Sent: Wednesday, June 13, 2018 9:51 AM
To: Challener, David C. <David.Challener@jhuapl.edu>
Cc: Stone, Matt <matt.stone@pearson.com>; W3C Credentials Community Group <public-credentials@w3.org>
Subject: Re: existing identifiers for people

Ok ... I’m not an expert in crypto ... the point I was responding to was to be concerned about a surveillance pattern when citizens use their Govt issued identity. That is not trust building. Of course we are proceeding purposely and carefully and doing our work in the open so we can benefit from the community. 

I’m not sure the scenario you describe is applicable since we do know what our issuer service has signed and there will be a well known DID / DID doc under the control of the government ID issuing service that is presumable immutable given the properties of the decentralized ledger. If some bad actor tries to create fake ID then they should fail as verifiers should be aware of the authoritative DIDs for the issuers they trust. Of course, issuers need to properly manage their keys, especially their private ones. 

As far as weak crypto, my experience thus far is the community is being very deliberate about the algorithm and key specifications so this should be mitigated by properly vetted standards. 

> On Jun 13, 2018, at 06:39, Challener, David C. <David.Challener@jhuapl.edu> wrote:
> 
> I think if you explicitly exclude those types of things you are making a bad mistake.
> We currently have malware being signed by keys that are from device driver manufacturers.  It isn't clear if the private key was compromised, the key was weak, or someone was bribed, etc.   But this shows one of the main problems with certificates -- there is no authoritative list of what has been signed, so it is hard to determine that something is out there, purporting to have been signed, when in fact it was not signed with authority. 
> If you make this an anti-pattern, it looks to me as though you have made it impossible to solve this problem.
> Since the signing authority presumably knows that it signed the certificate, all it is getting back is that the cert is being used. Where and how can be obscured. 
> 
> -----Original Message-----
> From: Jordan, John CITZ:EX [mailto:John.Jordan@gov.bc.ca]
> Sent: Wednesday, June 13, 2018 9:34 AM
> To: Challener, David C. <David.Challener@jhuapl.edu>
> Cc: Stone, Matt <matt.stone@pearson.com>; W3C Credentials Community 
> Group <public-credentials@w3.org>
> Subject: Re: existing identifiers for people
> 
> For sure there is no ping back to the issuer at verification time (including revocation checks) ... that is an anti-pattern that we intend to be specifically including at our policy level when we evaluation these kinds of network based solutions.
> 
> Interesting about the verification post the demise of an organization. Technically doable .. it will be a social level decision if those credentials have any weight depending on the context they were issued under I expect.
> 
> As a side note, my colleague Stephen Curran has been working out how to do offline verification which we think is a reasonable and interesting use case for verifiable credentials.
> 
> On Jun 13, 2018, at 06:26, Challener, David C. <David.Challener@jhuapl.edu<mailto:David.Challener@jhuapl.edu>> wrote:
> 
> And the approach that was written up – that specifically had the credentialing authority check if the credential had been revoked doesn’t need (or observe) either 1 or 2, so if those are hard requirements then the use case fails.
> 
> From: Stone, Matt [mailto:matt.stone@pearson.com]
> Sent: Tuesday, June 12, 2018 5:06 PM
> To: Challener, David C. 
> <David.Challener@jhuapl.edu<mailto:David.Challener@jhuapl.edu>>
> Cc: W3C Credentials Community Group 
> <public-credentials@w3.org<mailto:public-credentials@w3.org>>
> Subject: 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<mailto: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<mailto:matt.stone@pearson.com>]
> Sent: Tuesday, June 12, 2018 4:00 PM
> To: Samantha Mathews 
> <samantha@venn.agency<mailto:samantha@venn.agency>>
> Cc: Jordan, John CITZ:EX 
> <John.Jordan@gov.bc.ca<mailto:John.Jordan@gov.bc.ca>>; 
> public-credentials@w3.org<mailto: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<mailto: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<mailto:samantha@venn.agency>
> 
> On Tue, Jun 12, 2018 at 12:06 PM, Jordan, John CITZ:EX <John.Jordan@gov.bc.ca<mailto: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<mailto:phil.barker@pjjk.co.uk>>
> Date: Tuesday, June 12, 2018 at 10:11 AM
> To: "public-credentials@w3.org<mailto:public-credentials@w3.org>" 
> <public-credentials@w3.org<mailto:public-credentials@w3.org>>
> Subject: Re: existing identifiers for people
> Resent-From: 
> <public-credentials@w3.org<mailto: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=0YLnzTkWOdJl
> ub_y7qAx8Q&r=KheINWPzU3x8Jj96NXLwS0k5Y5jGbk-Gi1U5Cdx5914&m=LxoFG_fvziQ
> 3r1xoEekGOmpx131G82wdxFZ-7BD1hSs&s=lD9XYwlyK_WRn8Q97uUKXw23NW_lZFAGuuJ
> eDLoFLeA&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=KheINWPzU3x8Jj96NXLwS
> 0k5Y5jGbk-Gi1U5Cdx5914&m=LxoFG_fvziQ3r1xoEekGOmpx131G82wdxFZ-7BD1hSs&s
> =KI1N-3aWjGWE1faJyA812OrASe5WEjy-NdUFZ3NKEHY&e=>
> 
> [2] 
> http://www.isni.org/<https://urldefense.proofpoint.com/v2/url?u=http-3

> A__www.isni.org_&d=DwMFaQ&c=0YLnzTkWOdJlub_y7qAx8Q&r=KheINWPzU3x8Jj96N
> XLwS0k5Y5jGbk-Gi1U5Cdx5914&m=LxoFG_fvziQ3r1xoEekGOmpx131G82wdxFZ-7BD1h
> Ss&s=RQlvMbU-sdcbPsXK5xqlBanIhTd01El7iEw78SQCloM&e=>
> 
> *Tzviya Siegman*
> 
> Information Standards Lead
> 
> Wiley
> 
> 201-748-6884
> 
> tsiegman@wiley.com<mailto:tsiegman@wiley.com><mailto:tsiegman@wiley.co
> m<mailto:tsiegman@wiley.com>> 
> <mailto: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/v

> 2/url?u=http-3A__people.pjjk.net_phil&d=DwMFaQ&c=0YLnzTkWOdJlub_y7qAx8
> Q&r=KheINWPzU3x8Jj96NXLwS0k5Y5jGbk-Gi1U5Cdx5914&m=LxoFG_fvziQ3r1xoEekG
> Ompx131G82wdxFZ-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=Khe
> INWPzU3x8Jj96NXLwS0k5Y5jGbk-Gi1U5Cdx5914&m=LxoFG_fvziQ3r1xoEekGOmpx131
> G82wdxFZ-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 Wednesday, 13 June 2018 13:54:55 UTC