A solution for privacy-preserving Verifiable Credentials
The recent ratification of Verifiable Credentials (VCs) as a new standard at the W3C defines a powerful new data model for interoperability of identity technologies. As a standard it also represents a disruptive shift in the future design options of digital systems, towards ones that feature more portable and user-centric digital identity, often referred to as ‘self-sovereign’ or ‘decentralized identity’.
The basic data model of verifiable credentials may be familiar to developers and architects that are used to working with attribute-based credentials and data technologies. The issuer, or the authority on some information about a subject (e.g a person), issues a credential containing this information in the form of claims to a holder. The holder is responsible for storing and managing that credential, and in most instances is a piece of software that acts on behalf of the subject such as a digital wallet. When a verifier, sometimes referred to as a relying party, needs to validate some information, they can request from the holder some data to meet their verification requirements. Depending on the capabilities of the underlying technology, the holder is free to present the claims contained in their verifiable credentials using any number of techniques to preserve their privacy.
The concept of issuing authorities and verifiers or relying parties has been around on the web for quite a long time. It is a model adopted by certificate authorities which are used to securely browse websites as well as protocols like OpenID Connect that are used to manage identity claims about a subject. The real innovation of the verifiable credentials standard is that it pushes for the introduction of a layer between relying parties or verifiers and issuing authorities — what’s known in the VC data model as a ‘holder’. The introduction of this layer signals a shift towards a new paradigm, giving users greater control over their own information and also making it more convenient for a user to manage their digital identity.
One of the important principles that we want to achieve when designing any system that involves handling PII is to minimize the data disclosed in a given interaction. When users share information, they should be able to choose what and how much they share on a case-by-case basis (often referred to as selective disclosure), while the relying parties receiving the information must be able to maintain assurances about the presented information’s origin and integrity. As technologists, by having solutions that easily achieve selective disclosure, we can drive a culture based on the minimum information exchange required to enhance user privacy. When it comes to solutions, there are many different ways to tackle this problem, but three of the most common are:
- Just in time issuance — Contact the issuer at request time either directly or indirectly for a tailored assertion containing only the information required by the relying party.
- Trusted witness — Use a trusted witness between the prover and the relying party to mediate the information disclosure.
- Cryptographic solutions — Use a cryptographic technique to disclose a subset of information from a larger assertion.
While each solution is perfectly valid in different scenarios, these approaches have some important trade-offs.
Just in time issuance, a model made popular by OpenID Connect, assumes the issuer is highly available, which imposes an infrastructure burden on the issuer that is proportional to the number of subjects they have information for and where those subjects use their information. Furthermore, in most instances of this model, the issuer learns where a subject is using their identity information, which can be a serious privacy problem.
Trusted witness shifts this problem to be more of a presentation concern, where a witness de-anonymizes the subject presenting the information and presents an assertion with only the information required by the relying party. Again, this model requires a highly available party other than the holder and relying party present when a subject wants to present information, one that must be highly trusted and one that bears witness to a lot of PII on the subject, leading to privacy concerns.
Cryptographic solutions offer an alternative to these approaches by solving the selective disclosure problem directly at the core data model layer of the VC, providing a simpler and more flexible method of preserving user privacy.
There are a variety of ways that cryptography can be used to achieve selective disclosure or data minimization, but perhaps the most popular approach is using a branch of cryptography known as Zero-Knowledge Proofs, or ZKPs. The emergent feature of this technology is that a prover can prove knowledge of some data without exposing any additional data.
Naturally, there has been a lot of interest in combining verifiable credentials with zero-knowledge proofs. Some promising implementations of ZKPs have emerged in the open-source digital identity community based on the usage of CL-signatures and zk-SNARKs. While these approaches have provided a lot of thought-leadership in the VC ecosystem, they have traditionally come with their own set of notable drawbacks. These include new cryptography, new infrastructure dependencies, as well as an increase in the computational effort required to implement them.
Here at MATTR, we are piloting an approach to ZKPs based on BBS+ signatures. Beyond the privacy and security benefits of ZKPs in general, this approach has a number of additional benefits compared to the ZKP implementations that exist today.
- Highly performant and compact
- Minimal pre-setup or external dependencies (such as credential definitions)
- Interoperable with existing schema technologies
- Compliant with emerging standards
To expand on these ideas, we believe that ZKPs when applied in the context of verifiable credentials, can and should be implemented in one of the two existing assertion formats that are defined for use within the standard today, namely JSON-LD and JWTs. It has often been said in the community that there are three ‘types’ of verifiable credentials: JWTs, Linked Data Proofs, and ZKP-based credentials. This is a false equivalence. While the first two are assertion formats, which are essentially alternative ways to represent the same information, ZKPs are not, instead they are a capability afforded by a particular branch of cryptography. In truth, ZKP-capable verifiable credentials are best characterized as an emergent feature of the kind of digital signatures they use, rather than being regarded as their own distinct ‘type’ of credential. More information on this topic can be found here.
Beyond the need to avoid unnecessary complexity associated with creating another ‘type’ of credential, there are a number of benefits ZKP-based credentials can gain from utilizing the JSON-LD data model the way it was originally designed. There has been some effort in the community to get CL-signatures-based VCs to work with JSON-LD, however this approach still relies on a separate resource called a ‘credential definition’ which is stored on a decentralized ledger. Very few ledgers support this kind of object, which limits the utility of this solution. In our approach, the entire context of the credential, including its associated schemas, is included in the VC via JSON-LD. In essence, data schemas in the VC ecosystem are only useful if they are strongly reused by many different parties in the ecosystem. By utilizing JSON-LD according to current specification definitions, our approach enables us not only to use existing JSON-LD schemas, but to utilize the mechanism defined by JSON-LD to create and share new schemas as well. To a large extent this is what JSON-LD was designed for: the adoption and reuse of common data vocabularies.
There is a strong need for privacy which has motivated much of the development around ZKPs. On the other side of the spectrum, there is the strong need for semantic interoperability which can make VCs more broadly useful. Our ZKP implementation exists at the intersection of these often competing goals. We want to create an approach to achieving selective disclosure which is highly-performant, minimal in size, cryptographically secure, and most importantly, compatible with existing standards.
As shown above, this solution relies on the underlying cryptography of BBS+ signatures. While the cryptography is readily available for anyone to use today (even for use outside of verifiable credentials), what we have done is create an approach which combines Linked Data Proofs with BBS+ signatures. This solution is defined in a new specification as well as a new cryptographic signature suite. The new signature suite will be added to the Linked Data Cryptosuite Registry to maintain interoperability with existing Linked Data Signature schemes. We can also envision a similar specification and cryptographic suite that would combine JWT/JWS with BBS+ signatures. For the sake of completeness and further interoperability, we would encourage this approach to be developed in parallel with the linked data approach we are using. There is nothing about the BBS+ digital signature scheme that mandates the use of a particular VC format, or, indeed, the use of a VC at all. We have found great synergy by combining these technologies together, however there is nothing to prevent them from being used as modular or interchangeable components.
Our implementation is ready to be utilized as-is with existing JSON-LD libraries and processors. We invite developers and architects to collaborate with us in further developing this emerging work around ZKPs. You can get involved in a number of different ways: by reading the specification and providing feedback in the form of issues and comments; developing open source libraries that utilize and consume the JSON-LD based crypto suite; and contributing examples of ZKP-based VCs to the W3C VC Examples repository, to name a few. We have published multiple open-source libraries ready to be used with VC-JS, an open-source JavaScript library for working with verifiable credentials.
We are excited to bring the power of ZKPs to the rest of the credential ecosystem, and we hope that this work enables the broad usage of privacy-preserving technologies.
Specifications:
- JSON-LD BBS+ specification: https://w3c-ccg.github.io/ldp-bbs2020/
- BBS+ signature scheme: https://mattrglobal.github.io/bbs-signatures-spec/
- BBS+ cryptography: https://eprint.iacr.org/2016/663.pdf
Open-source libraries:
- node-bbs-signatures: https://github.com/mattrglobal/node-bbs-signatures
- jsonld-bbs-signatures: https://github.com/mattrglobal/jsonld-signatures-bbs
- vc-js: https://github.com/digitalbazaar/vc-js
