VCs: The Right Starting Point For SSI

The VC Stack results when considering verifiable credentials (VCs) as the foundational element for self-sovereign identity (SSI) rather than identity, blockchain, or even the underlying cryptographic protocols that make SSI possible. It is conceived from the perspective of an organization adopting VCs, and does not touch on ecosystem-level considerations such as standards, governance frameworks, schema, etc.

As VCs are a digital equivalent to physical shipping containers, the other elements of SSI should adapt to VCs rather than the other way around. In fact, in the physical world it was the practice of adapting containers to their means of transport that made the movement of goods so incredibly inefficient for thousands of years. In 1956 the switch to consistent shipping containers began, and it changed the physical world profoundly; the switch to consistent, authenticatable digital data containers will do the same for cyberspace.

To make that switch for data, VCs must come first, then all other functions must adapt.


Within The VC Stack, all of the cryptographic operations for VCs, such as their actual issuance, verification, revocation, and peer-to-peer communication, are grouped into a single layer: “Processing.”

Without Processing we don’t have VCs, full stop. But VCs aren’t one-and-done, they have a lifecycle that must be anticipated and managed before, during and after Processing. There’s source and other data beyond what finally goes into a VC that must be managed somewhere, somehow; there’s communications and interactions with Holders that must be tracked, controlled, and recorded, for as long as they’re Holders; there’s ID proofing to be done before issuance can begin; there’s policy, schema, and credential definitions to build before either issuance or verification can take place; and much more.

Four ‘Functions’

The VC Stack organizes working with VCs into four essential functions, or layers: Storage, Processing, Management, and Applications. Typically, all four functions continue to operate during the lifespan of a VC, however long that may be. In fact, VCs often utilize all four functions concurrently, as issuance, verification, and communication originate at the Application layer when triggered by human input, and involve every other layer while executing.

All four functions can be provided within a single integrated product from a single vendor, by four different products from four different vendors, by homegrown solutions using open standards and source code, or any combination.

All four functions are required for VCs to be usable, though they can be streamlined and/or combined with other functions to better fit particular use cases. For example, a VC wallet can be embedded within an existing app, simplified Management can be built into a Processing service or within an Application, and Processing can be embedded within a Management product.

In this post I’ll describe the purpose of each function and how it works with the others to enable the magic of VCs.

Not Just W3C

The VC Stack encompasses all forms of digital verifiable credentials that use issue-hold-verify, and not just the W3C Variety. While I predict that an increasing requirement for interoperability will eventually lead to convergence around VC standards like W3C, the W3C specification is not yet final or widely adopted, and different approaches are emerging to fill the vacuum. Examples include VCI, EU Digital COVID Certificate (“GreenPass”), IBM Digital Health Pass, and the exciting new European Digital Identity Wallet (specs TBD but it is clearly issue-hold-verify). The market is young, and there will be experimentation with VC features and properties; as the market matures, so will the degree of standardization.

Though these non-W3C VC variants are limited in their interoperability, or may even be proprietary, if they operate on the issue-hold-verify model they’ll require all four layers of The VC Stack, one way or another. Eventually, even proprietary VC variants will be obliged to adopt standards for interoperability or be faced with technical isolation; data portability is of limited utility if the same vendor or platform must be used in order for it to be portable, and portability is kinda the whole idea of VCs in the first place.

Layer 1: Storage

After issuance a VC must be held somewhere; this is Storage. Storage can be a traditional database or a blockchain, but is typically a digital wallet. A VC not issued to a particular person or entity—such as Ford issuing a VC about each truck they manufacture—can be held just about anywhere and even copied without losing authenticatability. For VCs issued to people, organizations or things, a digital wallet is usually needed.

A digital wallet can take several forms: stand-alone/general purpose like those offered by Evernym or Trinsic, customized for a specific use case like the IATA Travel Pass, or embedded into another application, where it might even be hidden from a user’s view. It can be a personal wallet for holding VCs issued personally, or an organizational wallet for holding organizational credentials, whether issued to people, things, or the organization itself.

Some wallets are proprietary and work only with a particular company’s products, like device-native wallets from Apple and Google, while others can work with any service that utilizes the same underlying protocol. Regardless, the purpose of the wallet is to hold VCs securely until they are needed, and make them available to applications that can make use of them.

Layer 2: Processing

Cryptographic Operations

Processing includes all VC cryptographic operations, such as issuance, verification, revocation, connection, and more. (The VC Stack’s Processing layer encompasses both layers 2 and 3 of the ToIP stack.) The Processing layer is where VCs are actually created and later verified, even when these operations are triggered in the layers above. Hosted agent services, where VC-related cryptographic functions are performed by a custodial service provider, are also a part of Processing.

Key Management

Key management is a core part of VC Processing. Key management includes PKI key pair (public, private) creation, key storage, key rotation, using private keys for signing, and using public keys for signature verification. Keys that must be managed include the keys Issuers use to sign VCs when issued, and the keys Holders use to sign VCs to authenticate themselves when presenting a VC for verification. Ultimately the point of key management is to ensure that a Verifier has the correct public keys when verifying signatures—that “magic moment” that makes SSI possible—whether using blockchain, KERI, or peer-to-peer key exchange. Processing includes other key management functions such as delegation and multi-signature schemes.

(A side note about KERI: typically key management is a bespoke process of the processor that involves blockchain, but with KERI it becomes an open, standard, interoperable protocol with all the good (hard to do) stuff baked in, no blockchain necessary. I believe that KERI is the future of VC processing.)

Interactions with Holders

Because peer-to-peer interactions with Holders are cryptographically authenticated and encrypted, all actual communication and interactions between an organization and VC Holders, whether during issuance, verification, or communications in-between, occur in the Processing layer. Applications and user interfaces for utilizing these communication channels will typically manifest in other layers, however.

Integration with Other Layers

Like the other functions of the stack, Processing can be integrated with any of the other functions. By its mathematical nature, Processing is not something that can or needs to be seen, either by users or practitioners, and so requires at least a basic UI at the Management or Application layers. Processing acts as a bit of a ‘black box’ that should be independently audited to ensure expected operation. Its complexity requires special expertise, and its security is of the greatest importance of the VC Stack.

Layer 3: Management

The Management layer addresses the business side of things for Issuers and Verifiers, like CRM for VCs. It encompasses all administrative aspects before, during, and after issuing and verifying VCs, but none of the cryptographic operations (Processing), though these could be embedded within a single product offering.

For effective Management there are five elements to consider:

  1. Permissioning & Auditing: Which employees, departments, or systems can issue which kinds of VCs? Who can make which kinds of changes? Who did what, when? 
  2. Staging: Where is the source data for each type of VC and how will it be accessed? How will Holders be ID proofed prior to issuance? Which policies will be used and how will they be managed? Which Processing service(s) will be used?
  3. Workflow Automation: How will you batch/automate offering, issuance, revocation, reissuance and more at scale? How will you handle exceptions, rejections, and expirations? Which processes must remain manual, and which can be automated, especially at scale?
  4. Interactions With Holders: How will you communicate with Holders, and help those having problems? How will you permission, track, and control communications with Holders, across departments and employees? How might VCs authenticate employees and customers when they call in, log in, or walk in?
  5. Recording, Reporting, & Analytics: Where will you record and manage all Holder-related data and interactions, such as personal info, source data, VCs issued, verifications, communications, revocations? How will you report and analyze your event data? How will you discover which VCs are up for renewal next month?

As mentioned above, VC standards and technologies are still being solidified. Because the Management layer is abstracted from the Processing and Storage layers where changes in these standards would have a direct impact, a dedicated VC management system can enable organizations to get started with VCs sooner rather than later and navigate changes as they occur, mitigating interoperability differences between non-uniform standards and technologies. This separation also helps avoid vendor and technology lock-in at the Processing and Storage layers.

Layer 4: Applications

As with the internet, the Applications layer sits atop all others, providing the user interface humans need to utilize the layers underneath. Also like the internet, this layer is likely where most of the business value VCs bring will be created, and captured.

The EU Identity Wallet announcement has a great list of capabilities that will be powered by some form of VC, including easy-to-envision Applications. For each use case taken from the announcement, it’s easy to envision the various applications needed by Issuers, Holders, and Verifiers:

  • public services such as requesting birth certificates, medical certificates, reporting a change of address
  • opening a bank account 
  • filing tax returns
  • applying for a university, at home or in another Member State
  • storing a medical prescription that can be used anywhere in Europe 
  • proving your age
  • renting a car using a digital driving license
  • checking in to a hotel 

In each use case, to provide the best possible experience for Holders and those that serve them, a superior application UI will hide the complexities of all other VC functions.

Years ago, we called a gaming company that used the internet within its game an “internet gaming company”. Now internet utilization is expected, and it’s just a “gaming company” again. The same will happen with VCs: the first VC-enabled applications will be new and different from other applications until they’re not, when VC-powered trust and security will become table stakes and mostly hidden from view.

In Conclusion

We’ve already used this VC Stack extensively in conversations with customers, prospective customers, partners, and VC experts, and the feedback has been universal: it is very helpful in clarifying how VCs work, and what services different vendors provide and how they work together.

The VC Stack is not part of any standard specification or official pronouncement from some global consortium like W3C, ToIP or DIF; it is something we conceived to help explain the different roles we see in the VC ecosystem and how they work together. We welcome any and all feedback and suggestions for improvement.

Share this post

Share on facebook
Share on google
Share on twitter
Share on linkedin
Share on pinterest
Share on print
Share on email