There’s a right way and a wrong way to do verifiable credentials (VCs).
The right way maximizes choices, and therefore power, for every legitimate party in the ecosystem: large and small businesses, governments, ordinary people with modest access to tech, IoT devices… The right way is safe. It produces good accountability. It stimulates a wide variety of wonderful user experiences. It is synergistic and collaborative and human-centric. It builds organic trust.
The wrong way neuters VCs into a blunt instrument. It is bureaucratic. It forces people to adapt to technology in awkward ways, which creates behavior gaps where hackers and criminals thrive. It makes auditing problematic. It adds risk and compliance burdens for institutions. It feeds lawyers and the surveillance economy. It is, in short, a train wreck.
photo credit: Don O’Brien, Flickr, CC-By 2.0
An approach to VCs goes wrong when it makes either or both of these dangerous assumptions:
Assumption 1: You show an issued credential when you give evidence.
Assumption 2: Verifiers are institutions.
Both of these assumptions seem plausible. Both may sometimes be true. What’s wrong is to expect them to be true all the time. Let’s look at why.
The Danger in Assumption 1
Suppose Alice is a young woman who gets a COVID-19 antibody test result, packaged as a VC. Maybe it gives her name, address, and phone number, plus the lab’s identity and an indicator of antibodies that suggest[1] her immunity. She shows this to her employer to resume work at the office.
Now she needs to take a rideshare from work to the daycare facility where her daughter is waiting. The driver wants to know that she’s immune before he lets her in the back seat. Should she prove it by showing her credential? Remember that it contains personal details; she might not mind her employer seeing that data, but she’s just read an article in the Boston Globe about revealing too much to a driver:
Alice’s quandary isn’t limited to personal safety. Notice the GDPR or HIPAA implications it has for the driver or for the rideshare company. Notice how it might predict the reboot of a post-pandemic economy…
Verifiers of credential data, too, have compelling reasons to query exactly and only what they need. Anything extra has ramifications for risk, compliance, and cybersecurity. Consider another aspect of ridesharing for a moment. In legal jurisdictions where the rideshare company is viewed as an employer, it may have to prove it isn’t biased on the basis of national origin as it hires. So what if the same credential that proves a driver’s privilege to work also reveals their national origin, which the company cannot legally query or retain? What if they’re holding unnecessary data like this and it’s leaked in a data breach? What will auditors and insurers and courts think of their data collection practices? What if they get a national security letter demanding documentation on all people of national origin X that they employ in city Y?
Clumsy whole-credential sharing isn’t a problem if Alice flashes paper at her driver, or if the driver shows paper to an HR person; unimportant details are rapidly forgotten by a human. But in a world where credentials are evaluated and stored by tech, we can’t be so careless. Inherently, different credential fields entail different considerations for use, and the tech demands pondering. Some fields might, in some circumstances, raise issues such as libel, copyright, conflict of interest. or intellectual property, Others might hold personally identifiable information (PII) about the holder, and thus be of interest to privacy regulations. Still other fields might contain information about third parties who need to consent if their data is shared. A system that assumes the sharing of a whole credential rather than just relevant parts narrows addressable use cases to only the least common denominator where all fields are treated equally. And this narrowing gets worse if evidence has to come from multiple credentials, because the intersection of compatible considerations shrinks further.
Some issuers of credentials suppress PII because of these very issues. But subtracting such data early is a kludge; scenarios requiring PII are just as reasonable. The plain fact is that credential usage is not predictable at issuance time. We need a solution that adapts itself to the circumstances of each proving interaction. Anything else will proliferate unhandled corner cases and social friction.
The sharing of whole credentials has an even darker drawback. Even if no extra data is revealed, every issued credential is unique by virtue of the digital signature from its issuer. When a credential is shared directly, that signature can be used as a perfect correlator of the holder. Alice may not just get her rideshare driver as a stalker; the driver can post the signature on the dark web, and Alice can now be correlated anywhere in the world, by anybody who sees that same signature or looks it up. No fancy machine intelligence is needed to correlate this uniqueness; it’s a simple binary query in a database. This is a godsend for surveillance capitalism and criminals, and for identity theft monitoring services who now get hundreds of new identifiers to monitor on top of emails and driver’s license numbers and phone numbers. It’s a nightmare for innocent holders — all the more insidious because most holders of credentials will not realize it’s happening.
The VC standard describes a mechanism to solve these issues. It’s called a verifiable presentation (VP). A presentation is supposed to contain arbitrary evidence assembled from one or more issued credentials, and it can hide signature values. Unfortunately, VPs are the ugly stepchild of the VC spec. The only variant of a VP that most VC practitioners advocate is one which exactly wraps an issued credential, exposing the digital signatures that correlate. The interoperability frame they prefer focuses on credential format at issuance, not presentation. When they talk of “selective disclosure,” they’re imagining clunky workarounds, like asking the issuer to issue new permutations of subsets of credential data on demand. This produces workflows that are impractical, expensive, and risky. It sucks choice out of the ecosystem and defeats the whole flexibility goal. And the root cause is Assumption 1. If, instead, they focused on presentations, and built tech that generated novel subsets of credentials on the fly, with safe signature handling, the future of VCs would be radically different.
Do not settle for soft, hand-wavy assurances that “we support presentations” or “privacy’s on the roadmap” or “we’re interoperable because of our credential format.” Here’s a checklist of specifics that reveal whether a VC solution is truly healthy (answer=yes), or is mired in Assumption 1 (answer=no).
- Verifiers can ask for pieces of data smaller than a single credential, and see exactly and only the data they ask for. They can show it to an auditor without apology, and if it leaks in a hack, at least it’s already minimized.
- Holders don’t have the Hobson’s choice between revealing too much and not proving at all, just because their credential contains extra data. They can precisely address use cases that span different quantities and qualities of disclosure with a few high-value credentials that are stable across reuse.
- Issuers can be offline or out of business when a proving interaction occurs.
- Issuers can analyze only their own use cases, and still generate huge value for verifiers they know nothing about.
- The focus of interoperability is on presentations at proving time, not on issued credentials.
- It is practical, easy, and fully supported to present evidence from multiple credentials and multiple issuers in a single presentation.
- Holders don’t emit unnecessary correlators every time they prove something.
The Danger in Assumption 2
It’s natural to think of verifiers as institutions. Most COVID-19 use cases in the news today cast a government or a healthcare institution in the role of enforcer. Financial services companies pay to build and deploy VC tech to eliminate fraud and help their own bottom line. Schools and employers invest to safeguard their reputations and comply with the law.
But if we build a system that is too confident of the verifier = institution equivalence, we create deep problems.
In our rideshare scenario, shouldn’t the driver have to prove he’s immune to Alice, too? And shouldn’t Alice be able to verify the immunity of the babysitter she’s hoping to hire when daycare is closed over the weekend? Credentials that can only be checked by institutions are credentials that lose much of their decentralized goodness, and much of their ability to reboot an economy reeling from a pandemic. Ordinary people need trust, too.
Many who build VC tech today would nod their heads eagerly at the assertions above, yet they advocate solutions that are subtly or explicitly governed by Assumption 2.
One way to do this is to describe all interactions as web APIs. The web is great, and web APIs are intuitive and powerful. Most parties who are investing in VC tech also employ developers who know how to use such APIs. But such an approach requires at least one side of each interaction to run a web server, and if that side is a verifier, we’ve effectively assumed the verifier is an institution, because that’s who runs always-on web servers with public reputation. We’ve also encouraged centralization by rendezvousing around a server.
Alice doesn’t want to run a web server to verify her potential babysitter’s immunity; she wants to use a mobile app, or she wants to verify over email or chat. And an IoT device might not be able to run a web server to be a verifier, either. Yet there are people who want to standardize web APIs for verifiers. Institutions who are investing in VC tech will of course support such standards, since they cover their own use cases. But who advocates for a standard for the interaction patterns of verifiers who aren’t institutions? Nobody. The end result will be well supported, interoperable behavior for institutional verifiers, and nothing for anybody else. No, what we need instead is a standard that supports all types of verifiers, including but not limited to the ones that want to operate on the web.
A subtler way to go wrong with Assumption 2 is to lean on regulation as the answer to the disclosure problems of Assumption 1: “It’s okay if we disclose too much data. GDPR will require the verifier to handle it responsibly and in accordance with instructions from the prover.” See the problem? GDPR doesn’t regulate the activities of private individuals, and even if it did, enforcement would be wholly impractical. Those who say such things are casting only institutions as verifiers.
Do not settle for soft, hand-wavy assurances that “anybody can verify our credentials” or “we’re interoperable because we have a standard web API for verification.” Here’s a checklist of specifics that reveal whether a VC solution is truly healthy (answer=yes), or is mired in Assumption 2 (answer=no).
- A farmer in the highlands of Bolivia with a cheap phone and spotty internet access can verify credential material from an equally modest user of tech at the local market — using exactly the same standard as an internet giant would use to verify.
- The farmer doesn’t have to subscribe to a web server in the cloud to do it.
- Verification can be done even if both parties are never online at the same time.
- Safeguards do not depend on verifiers being regulated institutions.
A call for safe credentials
When we design credentials in a way that maximizes choice—that is, when verifiers can choose how few or how many attributes to request and when verification isn’t limited to organizations—we end up with a capability that is truly revolutionary.
At Evernym, we’ve been referring to these as ‘safe credentials,’ and we’ve put together a series of five safeness tests to help organizations evaluate just how well their credential architecture upholds privacy, security, portability, interoperability, and flexibility.
For organizations, the use of safe credentials minimizes liability, enables cross-silo data flows, and powers superior customer experiences. It means an end to the overcollection of data, and all of the security concerns that come with a large centralized data trove.
For individuals, safe credentials mean digital empowerment. They provide tools to verify the identities or attributes of those we interact with. They let us take strong proofs about ourselves wherever we go. They give us confidence that our data is under our control.
The field of verifiable credentials is still relatively new, but we envision a future where safe credentials become the new norm and where consumers won’t settle for anything less.
For more on safe credentials, watch the recording of our recent panel webinar, where we invested experts from CULedger and Mastercard to share their thoughts on designing for privacy and security.
Endnotes
[1] Science has not yet demonstrated that significant Immunity to COVID-19 is predictable by the presence of antibodies. However, we pick this example because it’s under active discussion throughout the VC community.
