RE: lack of common definition for "ZKP" in a VC context

> The short answer is that neither ZKP-based nor non-ZKP-based credentials automatically address all of Anil's question.

Agreed.

> Two sources of additional reading:

Thank you.

> Issuers are equally liable for what they've asserted in both ZKP-based and non-ZKP-based ecosystems.

So, issuers and holders are equally liable but what about the ‘thing in the middle’ ?

Given that the ‘thing in the middle’ i.e. the platform operator /the ZKP tech provider / the Identity Oracle is the entity that is technically enabling this capability and touches the issuer, the person and the verifier, I do think they have to be accountable, liable and responsible but how you apportion that is something we really have not thought through to reach any sense of clarity.

Hopefully, that is where that multi-party-can-be-understood-by-normal-people Trust Framework comes in : -)

BTW, this is not a new conversation and many people in our community, have spent a considerable time and energy in this particular area because of its promise. However, I do think that for more than 10 years (from when Bob Blakely originally floated the Identity Oracle idea) we as a community have spent more energy building beautiful machines, and less on defining and articulating the contractual and business process aspects of the relationships of the parties involved in a manner that enables:


  *   Privacy protection of both PII information as well as transactional information with visibility and control by the Person
  *   Allocation of responsibility and liability across Relying Parties, Identity Oracles and Persons.
  *   Ability to conduct transactions that require very high assurances of identity to completely anonymous
  *   Ability to conduct transactions across multiple modalities including in-person, internet/web, mobile devices and more

Best Regards,


  *   Anil

From: Daniel Hardman <daniel.hardman@evernym.com>
Sent: Monday, September 9, 2019 1:04 PM
To: John, Anil <anil.john@hq.dhs.gov>
Cc: Credentials Community Group <public-credentials@w3.org>
Subject: Re: lack of common definition for "ZKP" in a VC context

How does knowing the identity of the issuer help the relying party / validator / verifier ensure in a ZKP environment that Alice is indeed the carbon based lifeform making that attestation about herself?

Binding a credential to a holder is a vital question. Many use cases demand it. We just wrote about it at length at the latest Rebooting Web of Trust conference, where people from Microsoft, Blockcerts, ETH Zurich, and Mitre joined me to explore the threat model.

The short answer is that neither ZKP-based nor non-ZKP-based credentials automatically address all of Anil's question. In both cases, we sometimes have to bind the holder to the presenter-of-proof more strongly, using techniques such as FIDO2, biometrics, link secret bonds, and so forth. However, the good news is that answers do exist and they are not rocket science.

Two sources of additional reading:

The RWOT paper on malicious holders<https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/draft-documents/alice-attempts-abuse-verifiable-credential.md> (currently in draft form, but likely to be transferred to the final-documents folder soon)
Another RWOT topic paper on transferrability of ZKP credentials<https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/topics-and-advance-readings/zkp-safety.md>

A paper on the topic of how biometrics can be combined with VCs safely and robustly has been accepted for publication in the Dec special issue of IEEE Spectrum, so look for more on the biometric subtopic there.

Where does the liability and accountability reside in a ZKP ecosystem? With the issuer? With Alice? With the infrastructure provider that touches the issuer, Alice and the verifier?

Issuers are equally liable for what they've asserted in both ZKP-based and non-ZKP-based ecosystems.

Alice (Holder) can be held accountable for what she proves in several different ways, including: A) requiring her to generate a proof that is non-repudiable; B) requiring her to use a technique called "provisional anonymity", whereby her strong identifiers are held in escrow but able to be disclosed unilaterally by an arbitrator if she misbehaves; C) detecting link secret reuse; D) requiring Alice to post a bond against her good behavior, etc. This is not an exhaustive list, just a flavor of what's possible. I'll channel my inner Drummond Reed to note that the particular techniques that get used would be determined by a trust framework. :-)