About four years ago, when I was still CEO at Evernym and before Credential Master existed, some of the Evernym team was involved in terminology discussions with others in the SSI community regarding Verifiable Credentials (VCs).
At the time, we didn’t call VCs Verifiable “Credentials”, we called them Verifiable “Claims,” borrowing from Kim Cameron’s (former Principal Identity Architect at Microsoft) seminal “7 Laws of Identity” from 2009. Kim’s thinking was that a person makes a claim about their identity, and it isn’t more than that until the Verifier accepts it as valid. “Claim” was a broadly useful term because it wasn’t necessarily about identity or credentials; it could be anything the Holder wanted to prove was authentic, which is exactly what VCs enable.
But for reasons I cannot now remember, others in the early VC community strongly favored the term “credential”. After some vigorous internal discussion, we agreed to abandon claim in favor of credential to bring Evernym’s terminology in line with the rest of the burgeoning SSI community, despite our misgivings.
In hindsight, this capitulation was a mistake; Kim was right. “Credentials” narrowed the perceived scope of the technology to identity- and entitlement-related use cases when a VC is really an authenticatable data container that’s entirely agnostic to its payload, as I explain below. “Credentials” has caused unnecessary confusion when explaining VCs, especially when the data payload isn’t what one would typically refer to as a credential, which is actually the far larger set of use cases. And when a VC newcomer goes to explain their newfound understanding to someone else, things often go further downhill. As Warren Buffet says, “when I don’t understand something, I don’t invest.”
Through trial and error, I’ve found success explaining VCs using the metaphor of a shipping container, and wrote a Medium article about it last summer. The metaphor worked well for me, and most importantly, for those explaining it second-hand. So in this blog post, I’m updating things for a broader audience and adding some new insights discovered along the way.
Verifiable Credentials are Containers, Not Credentials
First and foremost, despite their name, VCs aren’t credentials. VCs are containers, much like shipping containers for data, which actually makes them more useful and powerful than if they were just credentials.
Like a shipping container, there’s an originator who packs the VC’s contents, called the “Issuer”. The receiver of the VC container, called the “Verifier”, authenticates the container and unpacks its payload. Between Issuers and Verifiers, there is typically a “Holder” that acts like a courier for the data: a human or thing carrying the VC in some form of a digital wallet.
The payload of a VC can be any kind of data and is not limited to what might normally be considered a credential. Here are some examples of useful VC payloads not typically considered “credentials”:
- Consent, permissions, votes, opinions
- Tests, procedures, results, prescriptions, diagnoses
- Balances, totals, deficits, ranges, statistics, source data
- Statements, agreements, contracts, invoices, sources
- Confirmations, acknowledgments, attestations, assertions, affidavits
- Date, time, location, speed, trajectory, weight, temperature
- Laws, regulations, statutes, rules, orders, decrees, declarations
- Photos, videos, music, messages
- Software code, hashes, files, the state of a database at a given point in time
- And on and on.
Of course, data typically considered credentials make ideal VC payloads:
- Identities, names, addresses, usernames, titles, attributes, profiles, bios
- Licenses, passports, visas, permits, tickets, coupons, vouchers, receipts
- Skills, competencies, certificates, badges, diplomas, degrees, achievements, awards
- Identifiers, codes, account numbers, ticket numbers
Adding these lists together and realizing that VCs carry no constraint on the type of data they carry, it becomes apparent that VCs are far more flexible than what’s implied by the word “credential.”
The VC Container Is Authenticatable, Its Payload Is Not
As with any container, with VCs, it’s garbage in, garbage out. The only thing that’s always authenticatable with a VC, cryptographically, is the container itself.
For example, ABC University could issue to you a VC containing this attestation: “blue is green.” While blue is clearly not green, we can still authenticate four elements of this VC’s fidelity:
- ABCU issued it.
- They issued it to you. (optional element)
- It hasn’t been tampered with.
- It hasn’t been revoked.
While this VC container is provably authentic, it does not mean that the payload is true, that blue is green. This is a significant distinction; a Verifier can confirm that a VC container is authentic and from a particular source but choose not to rely on its payload. (A payload can also be separately verifiable in some way, such as an Open Badge or even another VC.)
This is how physical credentials work, too. A physical passport is a container that holds data, though constrained to only one type of highly regulated data. After the airport concludes that the physical ‘container’ you’ve presented is authentic, they can proceed to rely upon the data within it.
“Verifiable” Is Also Problematic
“Verify” is as problematic a word as “credential,” if not more so. The word “verify” could mean any business process, and it typically does not mean a cryptographic operation as with “Verifiable Credentials.” When applying for a loan or having a ticket and passport inspected at an airport, there’s a process that involves simple database lookups and/or people communicating with other people; that is the common understanding of “verify.”
More importantly, the big breakthrough with VCs is that they solve the “phone home” problem endemic to digital identity — the need to separately confirm things with the source — because VCs can be authenticated on the spot, without “phoning home” and even without internet access. “Verifiable” conveys exactly the opposite, incorrect impression: that such a step remains necessary.
“Authenticatable Data Containers”?
Alternatively, “authentic” means “genuine” and “having an origin of unquestionable evidence,” which is precisely what we want to convey about VCs. Ideally, VCs would’ve been named “authenticatable data containers” or “authenticatable containers,” but that ship may have sailed, that horse left the barn. Plus, “authenticatable” is a mouthful, and I think few would favor renaming the role of “Verifier” to “Authenticator,” though stranger things have happened.
In time even poorly named things, in the literal sense, come to mean what’s commonly understood about what they do, and the literal meaning becomes forgotten. So this issue is hopefully only a temporary obstacle.
So, VCs aren’t necessarily credentials and they’re not verifiable in the way most would think. When you hear the term “VC” or “Verifiable Credential”, think “authenticatable data container” and you’ll be closer to the truth, plus you’ll be more effective in explaining VCs to the next person. (Especially useful when that next person is your boss.)
VCs can carry any sort of data payload, and that isn’t just a good thing, it’s a great one. Part two of my container series covers how such fluid data portability could economically affect cyberspace to a degree comparable to how shipping containers affected global trade. That would be a very big deal indeed.