By Brent Zundel, Chief Cryptography Architect
I began at Evernym in the summer of 2017. It was my first startup and I sincerely wondered what I was getting myself into. I didn’t know the digital identity space. My schooling had focused on computer science and cryptography. Evernym hired me as a Crypto Engineer. What was this all going to be about?
During my interviews, I came to suspect that perhaps the folks at Evernym had taken on quite a challenge for themselves. They wanted to completely change how people interact digitally. They believed that if people and companies were given the tools to shift personal data from the companies who held the data to the people whose data it was, they just might change the world.
This was an audacious vision. People controlling their own data and deciding whom to share it with, and how much of it to share, rather than being the product for an out of control surveillance economy.
I was hooked. From the beginning my days were filled with new ideas and terminology: anonymous credentials; issuers, holders, and verifiers; DIDs and DID documents; distributed key management systems; selective disclosure, predicates, wallets, zero-knowledge proofs, elliptic curves, encryption, and so many signatures.
In late 2018, I got an email telling me that I needed to prepare to attend the meetings of the Verifiable Claims Working Group at TPAC in Lyon, France. To begin, I looked up Lyon on the map. Then I looked up TPAC and discovered it was an annual conference held by the World Wide Web Consortium. Then I looked up the Verifiable Claims Working Group and discovered I had already been made a participant by the same person who had sent the email. So I started attending meetings and was introduced to the world of open standards development.
My primary purpose in joining the group was to make sure zero-knowledge proofs were included in the standard. This was where I first encountered people who, in the friendliest way possible, thought Evernym might be just a bit too fanatical about things. Others frankly thought we were downright crazy.
We had implemented a scheme called Anonymous Credentials, based on Camenisch-Lysyanskaya signatures. They included support for selective disclosure, signature blinding, predicate proofs, link secrets, and had a neat revocation capability built into the protocol. The library was open source at Hyperledger. It worked for issuing and verifying credentials, and it worked for keeping information private.
Time and time again, I was told that zero-knowledge proofs (ZKPs) for credentials were just too hard. I would glance in disbelief at the open source code that seemed to indicate otherwise, then shrug and continue trying to convince people that ZKP-capable verifiable credentials were not only possible, they were inevitable.
Why? From Evernym’s point of view, the answer was obvious: how could any system that enables digital credentials to be issued directly to individuals—to put in their own personal digital wallets to use any way they choose—and which might contain the very most sensitive personal data such as health records or financial records—not make use of every possible piece of privacy-preserving technology available?
This is not to pretend there aren’t problems with Anonymous Credentials. Many of these are described in the excellent Verifiable Credential Flavors Explained paper by Kaliya “Identity Woman” Young published by the COVID-19 Credential Initiative (CCI).
To begin with, they are big—big keys, big credentials, great big tails files for revocation. They are based on CL signatures, which are based on RSA. Generation of signing keys for an issuer takes a really long time (at least in computer time, 10-20 seconds), as the process requires finding a large set of random prime numbers with just the right qualities. From the beginning, we knew it would be necessary to move to something else at some point; to upgrade to an anonymous credentials solution that was smaller and more efficient. The problem was finding one that had all the characteristics of Anonymous Credentials that we felt were important:
We didn’t want to lose these characteristics in a move to another signature scheme, even one which allowed for smaller size and greater efficiency. We had even implemented a pairings-based signature scheme for use with our revocation system. It produced smaller signatures and was faster than CL signatures—but we didn’t want to move to this for Anonymous Credentials because it didn’t support predicates.
Why were predicates so important? At the time, we didn’t even question their importance. Look no further than the canonical use case almost everyone uses to explain the value of ZKP-capable credentials:
Imagine going to a bar, but instead of showing your ID, which reveals everything, you only prove that you are old enough to get in—without even needing to reveal your birth date!
This use case requires predicate-based proofs—a cryptographic solution to proving something about an item of data without revealing the data itself. In this case—that your age is over or under a certain number.
Predicates were the story of Anonymous Credentials. It seemed inconceivable to move to a scheme that didn’t support them.
By the end of 2019, the Verifiable Credentials Data Model v1.0 specification became an official W3C Recommendation. Those of us who had worked so hard to finish it were excited. The road to Recommendation status had not been easy, but in the end we had used hard work and tenacity to accomplish something together. Now, the question was, could it actually be used to interoperate?
One thing I learned about my fellow participants was that they had an earnestness similar to that which first attracted me to Evernym. They believed in the goal of interoperability the same way Evernym believed in a future where privacy was the norm. But while Anonymous Credentials complied with the W3C VC data model, that alone would not guarantee interoperability with other schemes. (On a side note, the VC standard work had been so satisfying that I soon accepted the invitation to co-chair the W3C Decentralized Identifier Working Group, which many members of the VCWG were also participating in.)
My next work project was a joint effort with staff at the Sovrin Foundation called Rich Schemas. The primary goal of the project was to find a way to ease the tension between interoperability and privacy. Specifically by:
1. Bringing the open source codebase at Hyperledger Indy and Aries (much of which Evernym had written and which we relied on for our products) into compliance with the Verifiable Credentials Data Model.
2. Making it possible for Anonymous Credentials to use JSON-LD schemas and take advantage of the shared semantic meaning they enable.
To achieve these goals, Rich Schemas introduced additional transactions for the Hyperledger Indy distributed ledger project and a new interface for the Hyperledger Aries agent/wallet project. They tried to address a wide array of concerns including:
And more. In short, Rich Schemas were complex.
This complexity introduced additional possibilities: reuse of presentation definitions, a wider range of possible predicate operations, content-based decentralized identifiers, multi-ledger anchoring, and so on. Although it was shaping up to be a large body of work, the benefits seemed more than worth it.
At the same time, I was working with other staff at the Sovrin Foundation on the specifications for Anonymous Credentials v2.0. After evaluating a number of different pairings-based signatures, we settled on the one referred to in the literature as BBS+ (named after the original authors Boneh, Boyen, and Shacham). The resulting credentials were much smaller, and the signatures were much faster, than Anonymous Credentials v1.0. We also described a way to do predicate operations using Bulletproofs, and a way to do revocation using SNARKS circuits and Merkle trees.
The combination of Rich Schemas and Anonymous Credentials v2.0 seemed to promise a breakthrough advancement in the technology without sacrificing any of our requirements for privacy and user empowerment. Unfortunately Rich Schemas proved to be too big a hill to climb for others in the Hyperledger community. The excitement of the proposing group was not shared by others. At the same time, Anonymous Credentials v2.0 was suffering. It was difficult to come to agreement on the additional pieces, especially around revocation.
The bottom line is that features that are not supported by a significant portion of an open source community often don’t get implemented.
Still, several good things came out of the Rich Schema effort:
1. The goal of compliance with the Verifiable Credentials Data Model v1.0 remained and a desire to use JSON-LD schemas had been introduced to the community.
2. The goal of defining an interoperable VC presentation format found a home at the Decentralized Identity Foundation and ultimately became a Presentation Definition, described in the Presentation Exchange specification.
3. The open source code for BBS+ signatures was written and contributed to Hyperledger Ursa.
Just as I was pushing internally for Evernym to take on implementation of Rich Schemas and Anoncreds v2.0, the world went into quarantine. Many of us feared that the world of SSI and verifiable credentials would be suspended along with many other facets of the world economy.
But the opposite happened. Suddenly the Anonymous Credentials v1.0 solution that we had built and open sourced was being rapidly adopted by real customers in the real world for COVID-19-related applications. And this quickly produced a different problem.
As many in the software world know, shifting existing customers to new tech is difficult. For a modest-sized started up like Evernym, supporting existing customers and maintaining the products they use takes a lot of effort. Doing so while also building brand-new tech is next to impossible. Doing so early in a global pandemic was unthinkable. So our survival as a company required us to make a number of painful sacrifices and focus entirely on our customers’ current needs.
It was a scary and disappointing time for many. The Sovrin Foundation had to let go of their full-time staff, and Hyperledger Aries and Indy communities were shaken as members had to focus on doing what they could to survive. Those of us who remained wondered whether, even if we had been able to implement all of the features of Rich Schemas and Anonymous Credentials 2.0—would anyone outside of our community want to use it?
Then, at the Fall 2020 Internet Identity Workshop (IIW), MATTR made an announcement about BBS+ LD-Proofs. They had taken the code in Hyperledger Ursa and described how to use it with JSON-LD—while at the same time producing credentials compatible with the W3C Verifiable Credentials Data Model v1.0 specification.
In all honesty, I was almost too jealous to be excited. They had met the primary goals of Rich Schemas—plus much of the core goodness of Anonymous Credentials v2.0. The reaction to the announcement by others at IIW was the magical part. People who had previously said that ZKP-capable credentials were a dangerous pipe dream were suddenly voicing their excitement at the prospect of using BBS+ LD-Proofs.
BBS+ LD-Proofs use JSON-LD schemas, so credentials that use them can have a rich, hierarchical set of attributes. Instead of the heavy-handed mechanism for the encoding and canonicalization of attributes values that we’d imagined for Rich Schemas, they use RDF canonicalization and a hash function. Rather than expanding the credential definition, they discarded it, taking advantage of some properties of BBS+ keys which allow for deterministic expansion.
People loved it. I knew they would. Hats off to MATTR.
How had they succeeded where I had failed? Two things became clear over time:
1. They recognized the truth about distributed ledgers and VCs.
2. They let go of ZKP predicates.
The truth is, a ledger isn’t necessary to use verifiable credentials. It all comes down to the root of trust question. In conventional PKI, certificate authorities (CAs) are the root of trust. Each of our browsers carries a list of ~200 CAs around the world that are the roots of trust (which means that ~five browser vendors around the world are the real roots of trust for Web PKI).
A distributed public ledger represents a distributed root of trust. Many feel that such distributed roots of trust will be absolutely necessary for VCs to become ubiquitous, used daily by millions without thought just like Web PKI. This was the vision that launched the Sovrin Foundation to govern a “global public utility for SSI.”
However the truth is that many trust frameworks (aka governance frameworks) do not require a global root of trust, at least not initially. Many verifiable credentials in production today are issued by one small set of companies and verified by another small set. In these digital trust ecosystems, the verifiers know the issuers, so small sets of “trust lists” are sufficient. Global verifiability is only actually required in a relatively few use cases at this early stage (such as digital health passes), though we expect it will ultimately be required for almost any widely-used VC.
BBS+ LD-Proofs reduce dependency on a ledger by discarding the credential definition. The only call to a ledger is to retrieve the issuer’s DID document.
More importantly, MATTR’s solution let go of predicates. It took me time to accept this. Weren’t predicate proofs the heart of ZKP-capable credentials? But when it came down to it, predicates were the ZKP capability everyone talked about but no one was actually using—yet.
Yes, Evernym has customers who absolutely intend to use them—at some point. Remember, support for predicates had complicated Anonymous Credentials v2.0 by requiring the use of Bulletproofs and Merkle trees. We said Merkle trees were needed for revocation, but in my heart I wanted them for set-membership proofs. However predicates had also complicated Rich Schemas by requiring encoding methods and custom canonicalization.
In short, while I still haven’t let go of my hopes that predicate support will be added soon, for right now, dropping predicates is a brilliant move. Because with BBS+ with LD-Proofs, the other vital privacy-respecting features of ZKP creds—selective disclosure and non-linkability of VC signatures and credential holders—are fully supported.
The competing pressures of interoperability and privacy preservation have finally found a middle ground that implementers can rally around. By putting together the best of JSON-LD and ZKP signatures, others could finally be pulled onto the ZKP bandwagon that Evernym has been steadfastly pulling since Day 1.
Suddenly folks were talking about selective disclosure and blinded signatures as obvious requirements for their use cases. And because ZKP creds support 100% of the same use cases as non-privacy-respecting credential formats/signatures—including use cases where a verifier can legitimately request a holder to show 100% of the data issued in a credential—the conclusion is clear: BBS+ LD Proofs is the one privacy-preserving VC format/signature suite that everyone should implement regardless of what other formats/signatures your implementation supports. It is the “highest common denominator,” if you will.
While the excitement around BBS+ signatures is well-deserved, and a number of different implementations have already shown they can interoperate, production-level BBS+ VCs are not here yet. There is more work that needs to be done. From my perspective, the following are need to be accomplished before BBS+ credentials reach that milestone:
1. The BBS+ signature implementation in Hyperledger Ursa needs more eyes on it. This implementation sits at the heart of a number of implementations of BBS+ LD-Proofs, so it is vital that this library be more thoroughly reviewed. Ursa itself could use some help making it truly “production-level,” as the library has yet to do a v1.0 release.
2. The BBS+ LD-Proofs specification that so many are implementing against needs to be finished. This is the formal definition of the BBS+ LD-Proofs scheme MATTR announced. It is currently a work item of the Credentials Community Group at the W3C.
3. The consequences of using BBS+ LD-Proofs in conjunction with other LD-Signatures needs to be formally explored, especially how this may affect the privacy properties of BBS+ LD-Proofs.
4. The strategy for adding predicate proofs compatible with BBS+ signatures needs to be decided. There are a number of good options. The community needs to settle on a strategy, implement it, and determine the consequences of using predicates within the BBS+ LD-Proofs framework.
5. A privacy-respecting revocation strategy also needs to be decided. The solution should prohibit a holder from making proofs with a revoked credential, but not reveal to the credential issuer that the holder is using the credential.
Evernym’s customers with VCs already in production will need a clear strategy for working with both ZKP-CL credentials and BBS+ credentials and a clear path for migration to the new signatures. The fact that both are ZKP-capable means that changes in protocols or user experience should be minimal. After all, we already have support for the privacy-respecting features. We will provide that guidance to all our customers as we bring support for BBS+ LD-Proofs into our product stack this year, and maintain our commitment to shield our customers from most of this underlying complexity.
Continuing the tradition of advancing the state of the art at IIW, those of us supporting BBS+ are planning a session at the upcoming IIW (April 20-22) called Convergence on BBS+ Verifiable Credentials. We highly encourage you to attend and join us and the rest of the SSI and VC community in forging this convergence.
I also invite you to attend Evernym’s next webinar, on April 1, where we’ll dive deeper into many of the topics explored in this post and discuss what convergence on BBS+ means from an interoperability perspective.