Hi everyone - I'm excited to have Daniel Buchner discuss an initiative we've been working on (in partnership with Microsoft Research) to develop a new Zero-Knowledge Proof scheme that enhances user privacy and security for digital credential systems.
Cheers,
Pamela
------
While decentralized identity standards and technologies can be used in a wide array of use cases, ranging from authentication with Decentralized Identifiers (DIDs) to decentralized apps via DID-encrypted personal datastores, one of the initial use cases many of the decentralized identity ecosystem are focused on is the use of DIDs for Verifiable Credentials (VCs). Credentials are signed assertions from a DID owner (known as ‘Issuers’) to another entity they’re attesting some fact or proof about (known as ‘Subjects’). At the Subject’s election, they can choose to prove the facts contained in a credential by submitting credential proofs to other parties who can independently validate them (known as ‘Verifiers’). These credentials can stand for just about anything, from airplane tickets to diplomas, but the core concept is the same:
- The Issuer signs a credential for the Subject using the cryptographic keys associated with the Issuer’s DID.
- The Subject takes possession of Issuer-signed credential and stores it in their DID Wallet for use with Verifiers who may need proof of the facts the Issuer is attesting to.
- The Subject provides the signed credential, or some derived proof thereof, to a Verifier who validates the credential and uses the data it presents in its evaluation.
Credential use cases pose privacy and personal safety challenges
To understand the issues that arise in common credential use cases, let’s examine a real-life set of scenarios related to work history and job skills:
Publishing a resume on a career networking app is something hundreds of millions of people do every year. This represents an open disclosure of work history the user wants others in the wider business community to be aware of. The expectation of privacy for this information is inherently low, as the user intends for this information to be widely known and verified by all who see it. For this use case, we need a credential mechanism that can verify signed statements by an issuer that are verifiable by observers.
Once a user has shared their career-related credentials, verifiers may need to periodically check the current status of work history credentials (e.g. an employee leaves one job for another). These sorts of status checks on credentials are often programmatically run at intervals, which may occur when the user is not actively engaged in an app, outside of normal waking hours, or when the user is not connected to the internet. This use case underscores the need for a feature that allows verifying parties to check the status of a credential without requiring the user to connect to the site and perform an interactive task.
Similarly, interviewing for a new job can be stressful, and in many cases individuals do so while currently employed. While a user may not care if observers are able to validate the past work history they list on career networking sites, prospective employers often want to validate current employment, which likely includes checking the active status of the current employment credential an applicant presents. If the prospective employer is a competitor of the user's current employer, any check for active status that alerted the company to their employee's intentions could cause problems for the applicant. As such, we need a credential scheme that allows parties to verify active status of a credential without disclosing any information about the credential or its holder to the issuer.
Some credential schemes can expose users to privacy and personal safety risks
Equipped with a general awareness of how DID-based credentials are issued and used, and an understanding of the privacy concerns that arise in real-life credential use cases, it’s important to understand that credentials can come in different forms. Basic credentials are plaintext data objects that include one or more ‘claims’ an Issuer signs using the cryptographic keys linked to their DID. The same credential object is then presented to external parties who can see all the properties and values it contains. Basic credential schemes often incorporate revocation mechanisms where Verifiers ‘phone home’ to Issuers to check the status of a specific Subject’s credential (e.g. is a driver’s license active), providing Subject-identifying data in the process. Other credential schemes utilizing zero-knowledge features avoid some of these issues, but often introduce other tradeoffs, like requiring users to be involved in interactive flows to prove credential status.
The following privacy and tracking issues often arise from these types of credential schemes:
- Presenting the same credential bytes to multiple verifiers enables them to track its trail of usage. Schemes that try to remedy the presentation of the same credential bytes to multiple Verifiers by fetching unique copies of credentials just-in-time still disclose time of use and other trackable metadata to Issuers.
- Exposing raw credential values to Verifiers can needlessly expose sensitive information. For example: disclosing a Subject’s specific date of birth can have negative effects, especially when proving their age is greater than a certain threshold would suffice.
- Status check mechanisms that disclose Subject-identifying information enable Issuers to track how a Subject is using a credential. This is often the case in credential schemes that ‘phone home’ to check on credentials using a credential ID or other specifically identifying data.
There is also a set of desirable features existing credential schemes often lack:
- Generate uncorrelatable versions of a credential for each Verifier, without contacting the Issuer – a credential scheme should enable a Subject to generate uncorrelatable versions of a credential that doesn’t expose them to tracking by Issuers or Verifiers.
- Empower Subjects to only disclose the minimum necessary facts – instead of disclosing all the data a credential contains, or precise data values, a scheme should allow Subjects to prove any subset of facts a credential contains, at varying levels of granularity. For example: if a Subject has a credential that contains their exact age, among other things, the Subject should be able to generate a proof that only includes the fact that they over a certain age, without disclosing their date of birth.
- Enable credential status checks that don’t divulge Subject-identifying information to Issuers – Verifiers should be able to derive the status of a credential without divulging to the Issuer any information about the Subject or specific credential they’re checking.
- Enable Verifiers to check the status of a credential offline – Verifiers should be able to check the status of credentials based on proofs that can be cached for use when disconnected from the internet.
- Credential status checks shouldn’t require manual user participation – Subjects should not have to be actively connected to verification systems for Verifiers to check the status of a credential. For example: if a bank needs to run a monthly automated check for the status of a homeowner’s fire insurance policy, and that check runs at odd hours, the homeowner should not have to be involved in any way. (Some schemes require a user to engage software on their device to facilitate status checks for Verifiers, which makes many valid business scenarios infeasible.)
To summarize, existing credential schemes generally exhibit the following profile of issues, which we would like to solve:
Zero-Knowledge Proofs can enhance privacy and personal safety
The privacy and personal safety issues surrounding credential schemes have been known to members of the identity community for decades. Many past initiatives and groups have worked on solutions for these issues (including Microsoft’s U-Prove developments in the late aughts), but until the advent of cryptocurrencies and decentralized identity systems, there was not a pressing business need that required wide-scale deployment of solutions to these problems. In the years since, countless developers, academics, and organizations have been working on new schemes that incorporate a number of advanced cryptographic techniques to overcome the challenges outlined in the sections above. The most promising of these techniques are recent innovations in Zero-Knowledge Proofs cryptographic schemes, or ZKPs for short. ZKP schemes come in many flavors, each with unique trade-offs, features, and performance profiles, which can be tailored to particular use cases and requirements.
As we considered the wide range of scenarios we wanted to tackle, we felt we could make contributions in the area of privacy preserving credentials that could help advance the ecosystem. To that end, we began a joint initiative with our colleagues in Microsoft Research to develop a ZKP credential scheme that accounts for the range of features and use cases we seek to enable (as enumerated in the sections above). The following are notable technical details about the scheme we’ve been working on:
- The scheme is based on a transparent SNARK construction, Spartan (to be presented at the 40th Annual International Cryptology Conference), that does not require a trusted setup and offers faster prover and verification times than most equivalent schemes, with proof sizes that are smaller (when utilized for this purpose) than all schemes in this family, with the exception of Bulletproofs.
- The scheme supports a range of statement types, including predicate proofs, range checks, set membership, etc.
- For the encoding of zero-knowledge claims, the scheme employs Rank-1 Constraint Satisfiability (R1CS).
- Proving cost scales linearly with the number of R1CS-encoded constraints included in a program.
- Status checks can be proven with the user out-of-band, without requiring Subject interactivity.
From how credentials are issued, all the way through their revocation, we believe this scheme can fulfill the requirements we have laid out and address the issues we’ve identified. In the end, we believe we should be able to overcome the negatives we listed earlier and produce an implementation that exhibits the following profile:
We have contributed the whitepaper detailing our ZKP credential construction to the DIF ZKP credentials initiative, and will begin development of an open source reference implementation in DIF later this summer. We’d like to thank DIF, the wider community, and all those who have been working to advance privacy preserving credential technologies. Please join us in DIF and contribute to this initiative – it’s important that the identity community gets this right, and we need your help to do it.
Daniel Buchner
Decentralized Identity / Microsoft Identity
Image/Icon Credits:
prettycons from www.flaticon.com
Freepik from www.flaticon.com
Becris from www.flaticon.com
Smashicons from www.flaticon.com
Geotatah from www.flaticon.com
Monkik from www.flaticon.com
Darius Dan from www.flaticon.com