Verifiable Credentials Aren’t Credentials. They’re Containers.

Timothy Ruff

8 min readJul 14, 2020

Stack of three shipping containers of different colors

This is part 1 of a 3-part series:

Part 1: Verifiable Credentials Aren’t Credentials. They’re Containers.

Part 2: Like Shipping Containers, Verifiable Credentials Will Economically Transform the World

Part 3: How Verifiable Credentials Bridge Trust Domains

TL;DR:

Verifiable Credentials (VCs) aren’t actually credentials, they’re containers, like shipping containers for data.
Having containers inside of containers is a feature, not a bug.
Like physical credentials, the VC container is always verifiable, not its data payload.

The Credential That Isn’t

The word “Credential” with a line through it

Despite their name, Verifiable Credentials (VCs) aren’t really credentials; they are containers, much like shipping containers for data, which actually makes them more useful and powerful than if they were credentials.

NOTE: The comparison to shipping containers is more than a passing one, as shipping containers are the most impactful containers ever devised and VCs are strikingly similar to them, both functionally and economically. Details of these similarities and their potential ramifications are covered in parts 2 and 3 of this series.

Like a shipping container, there’s a sender, called the “issuer”, who packs a VC’s data contents. The receiver of the VC container, called the “verifier”, unpacks and verifies its payload (or a subset proof thereof). Between issuers and verifiers there is typically a human carrying the VC in a standardized SSI digital wallet, but VCs can also be transported in other ways, or stored in a relational database¹ or a distributed ledger².

The payload of a VC can be any kind of data and is not limited to what might normally be considered a credential.

In fact, the word “credential” is a holdover from the worlds of identity and academia, where VCs began their standardization journey and have many important use cases. But recently I’ve seen people in academia get confused when the payload inside a VC is what the academic world calls a credential — like a diploma or a transcript — resulting in a credential within a (verifiable) credential. Others get confused when the VC payload isn’t a credential, in either academic or identity parlance, but we still call the VC a credential.

Now that VCs have the global momentum they do, I feel we need to “open the aperture” beyond identity and credentials. Here are some example VC payloads not typically considered credentials, all of which become cryptographically verifiable when delivered as a payload within a VC:

Consent, permissions, votes, opinions
Balances, totals, deficits, ranges, statistics, source data
Statements, agreements, contracts, invoices, sources
Confirmations, acknowledgements, attestations, assertions, affidavits
The speed, trajectory, weight, temperature or location of anything
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
Tests, procedures, prescriptions, diagnoses

Of course, objects 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

It is true that the identity- and achievement-related use cases in this second list are those most actively being pursued in the VC space right now, and many in the first list cannot be realized until there’s broader adoption by issuers and verifiers. Still, the word “credential” has a specific meaning in several industries, and it is consistently confusing to VC noobs for one simple reason: it is an inaccurate term for what a VC really is and does.

Truly, “Verifiable Credentials” should be renamed to “Verifiable Containers.” I can’t think of anything important we lose by doing so, and can think of much clarity and other benefits (detailed in this series) that we would gain. Of all the gnarly terminology challenges we face in the SSI space, this one seems like a slam dunk to me.

Containers Inside of Containers Is a Feature, Not a Bug

Set of Russian dollas — http://www.rubylane.com/item/712219-T118-121814-3/Russian-Matryoshka-Dolls-Nesting-Dolls

On several occasions I’ve been asked something like: “We already have containers for learning achievements with Open Badges; why do we need another container?”

A fair question, but it presumes containers inside of containers aren’t useful or necessary for data, which isn’t necessarily the case.

Life is full of containers inside of containers. Products at the store come in boxes that arrived in larger boxes, stacked with other boxes onto a crate, which itself is another container, often shipped inside shipping containers, which are carried in/on the containers of ships, trains, and trucks. Data is stored inside files within folders, within other folders, inside of directories, inside of virtual machines, inside of partitions, inside a hard drive, within an enclosure, inside a computer, often on a shelf within a rack within a room inside a building.

You get the point.

Each level of container has a purpose and adds value and efficiency to the whole chain; try taking one away and it gets messy. Sub-specialties and entire industries are built up around the containers at each level, and they often don’t know much about the containers at the other levels. The people operating giant cranes at a port don’t know or care much about what’s inside the containers they’re moving, and they don’t need to.

Cranes loading containers at a shipping port — CREDIT: Cam Geer

Even though it is a container itself, like any file a VC must be held in another container: a database, blockchain, or preferably a standardized SSI wallet. If a wallet, that wallet must be held in another container that makes it usable, like a smartphone, a USB stick or even a chipped card.

A VC can hold any sort of data payload, even as simple as a clear-text “Yes” or “No” when granting or refusing consent. If the payload is more advanced, like an academic achievement, it should be encoded in a way that provides semantic meaning to a verifier, such as an IMS Comprehensive Learner Record (CLR). When a CLR is a VC’s payload, it’s an achievement inside of a CLR container inside of a VC container likely inside of a wallet. Take away the CLR container and you lose some semantic meaning for verifiers; take away the VC container and you lose the ability for CLRs to become portable alongside other, non-CLR payloads, forcing CLR users to adopt special capabilities unique to CLRs. If you repeat that specialized thinking for every kind of payload, from academia to healthcare to government, you quickly get back to a world full of bespoke containers and troublesome trust domains, right back where we started.

This is why a standardized shipping container for data is needed, and just as useful as its physical analog. Whether physical or digital, it’s Russian dolls everywhere you look, and that’s a good thing.

VC Containers Are Always Verifiable; Payloads Are Not

Man inspecting the label on a shipping container

As with any container, with VCs it’s GIGO: garbage in, garbage out. The only thing that’s always verifiable with a VC is the container itself, where a verifier can cryptographically verify its fidelity, but not always the veracity of the payload.

For example, ABC University could issue to you a VC with this statement: “blue is green.” Clearly blue is not green and someone was messing around, but we can still verify four elements of the VC’s fidelity:

ABCU issued it;
They issued it to you;
It has/hasn’t been tampered with since it was issued;
ABCU has/hasn’t revoked it.

Knowing who packed the container establishes the VC’s provenance to a specific issuer and directly influences a verifier’s willingness to rely on its payload, which is why many conflate this issue and believe that payloads are verifiable. But it is a significant distinction; a verifier can confirm that a VC container is authentic and from a trustworthy source, but still decide not to rely on its payload. (A payload can often be separately verifiable in some way, such as an Open Badge or even another VC, but that is beside the point here.)

This is how physical credentials work, too. A physical passport is a container that holds data (though only one type of highly regulated data); it is the physical container the airport verifies when you present it to them. Then, upon concluding the container is authentic, the airport usually proceeds to rely upon the data within the presented container. VCs function in the same manner but in the digital realm and capable of carrying any data payload, which makes them far more flexible, useful, and powerful overall than physical credentials.

Of course, you don’t need a battery to share your driver’s license, so there’s that. But then again your passport and driver’s license can — and I believe will — become chipped³ and carry VCs just as chipped EMV payment cards carry other bits of data, no batteries required, so there’s that, too.

In Conclusion

If it’s true that VCs aren’t really credentials, and that calling them credentials often confuses people coming into the space, then we should seriously consider not calling them credentials.

The fact that VCs are containers capable of carrying any sort of verifiable data payload isn’t just a good thing, it’s a great one. And as you’ll read in parts 2 and 3 of this series, it has the potential to change the world as much as the shipping container did, and that’s a big deal. A huge one.

Finally, it is useful to put other data containers inside of VCs, and maybe even containers inside of those containers, all riding along and benefiting from the portability between trust domains enabled by a Verifiable Credential.

Or should we say, “Verifiable Container”?

This article is part 1 of a 3-part series: