Second-Generation Verifiable Credentials

The kind organizations will require.

The current Verifiable Credentials (VCs) data model originated in 2017, when it was called “Verifiable Claims”. There have been many sustaining innovations since that time but none disruptive¹ until now, for a new field of application for VCs: Organizational Identity (OI).

In The Dawn of Organizational Identity, Part 2: Credentials, Stephan Wolf, GLEIF’s CEO and the piece’s co-author, and I introduced what we consider to be second-generation VCs. We made the case why they’re ideally suited for Organizational Credentials (OCs), and why they’re required for many, if not most, of the use cases for organizations.

That argument is reproduced here, along with a few additions and modifications, as second-generation VCs represent an important advancement in verifiable credentials generally, separate from and in addition to their importance for OI and OCs.

Second-Generation Verifiable Credentials

First-generation VCs, like the current VC JSON-LD standard at W3C or the emerging JWT standard at IETF, were developed with utility for individuals in mind, for proving things like identity, age, and academic credentials. They were and are a major breakthrough in digital identity, they’re what make ‘self-sovereign identity’ actually self-sovereign and ‘decentralized identity’ actually decentralized, by giving individuals a high degree of digital autonomy for the first time.

Second-generation VCs were developed with organizational use cases in mind, with all the capabilities of first-generation credentials plus sophisticated new capabilities that individuals don’t often need but organizations typically do, such as key rotation and recovery, delegability, multi-signature (“multi-sig”), contractually protected disclosure, freedom from blockchain/‘ledger lock’, and more.

These new organizational capabilities are made possible by a form of VCs called “Authentic Chained Data Containers” (ACDCs), with signing and verification using an open key management protocol that replaces the need for blockchain or vulnerable web-based security: Key Event Receipt Infrastructure (KERI). These two decentralizing protocols together — ACDCs for VCs and KERI for signing — deliver significant advances for VCs, the kind that organizations require and that justify the ‘second-generation’ moniker.

Here are seven highlights:

1. Extraordinary advances in security:

• Recovery from private key compromise (suspected or actual) without reissuance of previously signed items*
• Key rotation without re-issuance of previously signed items*
• No reliance on web security
• Privacy-respecting verifiable revocation
• Non-repudiable signing with logging
• Post-quantum proof*
• Natively supports weighted ‘m-of-n’ multi-sig schemes with fractionally weighted thresholds (e.g., 2-of-3’, or 1-of-3 when the 1 has sufficient ‘weight’, etc.)

2. No reliance on blockchain (and its limitations: “ledger-lock”/centralization, scalability, cost, complexity, interoperability, performance, privacy, security, etc.)

3. Use of existing cloud infrastructure and APIs

4. Multi-level issuance with chaining and delegation (anyone having authority can delegate and extend a chain of authority, rather than all delegates returning to the ‘mother ship’ for single-level, single-signer issuance)

5. Extraordinary advances in privacy with graduated disclosure (granular, legally enforceable privacy and disclosure capabilities, covered in greater detail later in this article):

• Selective disclosure (with or without Zero Knowledge Proofs)*
• Ricardian Contract capabilities through contractually protected disclosure (counterparties verifiably consent to terms of disclosure prior to disclosure)
• Contingent disclosure (i.e., escrowed)

6. Interoperable with anything using the same underlying protocols (without sharing blockchains, vendors, registries, databases, etc.)

7. Simpler; technically lighter-weight (not verbose, compared to first-gen VCs)

*Individuals need these, too.

Security First, Always

With second-generation VCs, security comes first, always, no exceptions. The security advances with second-generation VCs are stunning when you consider that key recovery and rotation are still the Achilles Heel not only of first generation VCs, but also of blockchain and existing web infrastructure generally. Second-generation VCs using KERI don’t just fix security flaws for VCs (especially web-based VCs), they’re a significant advance in digital security, period.

Come on In, the Water’s Warm

There are no significant technical reasons we are aware of not to advance to second-generation VCs — no notable trade-offs other than familiarity and switching costs from legacy systems. In fact, the complexity of blockchain-based first-generation VCs may be at least an order of magnitude greater than the more elegant, advanced, and blockchain-less second-generation VCs.

That said, some will reasonably argue that a second-generation of VCs that doesn’t directly and fully interoperate with first-generation VCs — which is true — is a step backward rather than forward. However, we feel that achieving interoperability of VCs that are insecure, reliant on blockchain or web infrastructure, and not stress tested in production at scale is a hollow victory and premature; it is not meaningful interoperability. Security — in the form of proper key management — must come first, it cannot be bolted onto the current VC model just like it cannot be bolted onto the internet after the fact. There is no way around this.

However, the good news is, with second-generation VCs we can have all the robust security capabilities described above plus advances in privacy simply not possible with first-generation VCs, and gain real, global, fully decentralized interoperability that only standardized non-platform-based protocols can deliver. Even then, serious work on interoperability should be undertaken only after some use cases have made it into production and demonstrated that all these things work well, at scale. Otherwise that would be premature interoperability, too.

The Unprecedented Power of Organizational Credentials (OCs) Using Second-Generation VCs

Some of the dreamy use cases for OCs [listed in Part 2] are already possible, you say… but:

• Unlike most current identity technologies, including numerous high-profile implementations of first-gen VCs, OCs require no surveillance-enabling, privacy-killing ‘phone home’ to an intermediary for verification, do not rely on DNS/web security, and do not use shared ledgers/blockchains; OCs sacrifice neither security nor privacy.
• OCs can convey the full provenance and details of authority — unlimited levels — in-band with strong verification, proving not only the authority of the representative, but the full chain of authority and where it originated.
• OCs are B2C, helping prevent phishing by proving to customers and constituents that the company or government representative they’re interacting with really represents whom they claim to represent.
• OCs are C2B, enabling customers and constituents to prove their identity, status, and entitlements to the businesses and governments they’re aligned with when they call in, log in, or walk in.
• OCs can prove provenance not only back to the top of an organization, but to GLEIF (described in Part 1) and/or to any other chained root of trust such as a city, state, nation, or group of nations.
• OCs can also make verifiable any other analog identifiers in addition to or instead of the LEI. For example, a national ID, regional ID, local ID, employee ID, and any other identifiers could become cryptographically verifiable with OCs (provided their inclusion is governed by rules and safeguards similar to GLEIF’s Ecosystem Governance Framework, see Part 2 for more).

When an authorized representative of an organization delegates some authority to a person or a thing, whether an employee, director, contractor, partner, customer, constituent, device or piece of software — no matter how many levels deep in the organization — OCs enable that person or thing to prove it digitally, instantly, securely, and globally. OCs are a game-changer.

Proof of Delegated Authority

It’s one thing to have authority, quite another to prove it. OCs enable global verification of a representative’s delegated authority — through unlimited levels of delegation — using a powerful capability of second-generation VCs: chaining.

Chaining enables multiple levels of signatures for the same credential, and also for authority to be conveyed from signature to signature and/or credential to credential, enabling the very last link in the chain of delegated authority to be as strongly provable as the first.

A janitor can prove his authority with a cryptographic chain of delegated authority in the OC he carries. When verified by someone (or something) he’s presented his OC to, the chain might look like this:

• the janitor got his authority to do X and Y from
• the facilities manager, whose authority came from
• the regional manager, whose authority came from
• the vice president, whose authority came from
• the president/COO, whose authority came from
• the CEO, who was issued a vLEI credential* by
• the Qualified vLEI Issuer (QVI)* that vetted the organization, who was qualified by
• the Global Legal Entity Identifier Foundation (GLEIF), a global root of trust for legal entity identification.

* Described in Part 2.

The authority for the janitor begins with the CEO of the organization, originating from a special root-level OC that he/she holds, and not with GLEIF or its QVI. A CEO credential received from a QVI is not a delegation of authority; it is a digitally signed, non-repudiable attestation that the holder of that credential really is the CEO, issued by an accredited QVI or other reputable issuer after a rigorous vetting process. What the CEO does with the credential from thereon has nothing to do with the fact that an external entity asserts that he/she really is the CEO, and has digitally signed that assertion so that it’s verifiable anywhere.

OCs, Privacy, and Self-Sovereignty

Personal Privacy and Graduated Disclosure

With OCs the personal privacy of the holder — a representative of the organization — is of less relevance when that representative is an employee or contractor and they are acting within that context; the organization gets to decide what that representative should be disclosing or keeping private, which they can do quite powerfully with Graduated Disclosure as described below. When an OC holder is a customer or constituent, however, personal privacy becomes critically and legally important, magnifying the need for robust selective disclosure capabilities.

As with all ACDC VCs, OCs have three granular, legally enforceable “Graduated Disclosure” capabilities highly relevant to and needed by organizations:

Selective disclosure — the ability to provably disclose only some information without disclosing the rest, such as one’s authority but not their name, or their name but not their authority, or only one aspect of their authority such as their financial ceiling for signing purchase orders. This capability does not use Zero Knowledge Proofs (ZKPs) by default, but can take advantage of ZKPs when desired.

Contractually protected disclosure — when counterparties verifiably consent to the terms of disclosure prior to disclosure. The provided consent is non-repudiable, providing a path for recourse if the terms of disclosure are not honored.

Contingent disclosure — disclosure is possible only when certain conditions are met, such as keeping an identity encrypted and in a form of escrow for business purposes and interactions, but enabling that identity to be discoverable by law enforcement or regulators if it becomes necessary. Contingent disclosure solves tricky problems in telecommunications, for example, when the originator of a communication may not wish to be identifiable to network operators, but must become identifiable to authorities if their traffic turns out to be fraudulent or spam.

Self-Sovereignty

When employees or contractors are acting in representation of an organization, the org is sovereign and not the individual; there is no self-sovereignty in this situation. There is autonomy, as the person can choose to behave however they please regardless of rules or expectations, but not self-sovereignty. Like privacy, however, the principle changes when the representative is a customer or constituent; then the sovereignty of the OC’s holder becomes relevant. Still, the customer’s or constituent’s OC was issued by the organization and can be revoked at the organization’s discretion.

About Blockchain…

Blockchain, from a data standpoint, results from implementing a centralizing protocol, as it inescapably results in a single, master set of data that all counterparties must agree to (unlike TCP/IP, HTTP, etc.). While a blockchain’s data is physically replicated across many physical locations, the only semi-decentralized aspect of blockchain is its governance, but only when that governance is permissionless, and even then it is questionable². Every aspect of permissioned blockchains is centralized, putting all data into a single logical ledger and governance into the hands of a chosen few. The point here is, blockchains in all their flavors are platforms, not protocols, and always result in data centralization, the opposite of what’s needed for globally verifiable OCs.

(Learn more about the centralizing aspects of platforms and decentralizing aspects of protocols in the seminal essay “Protocols, Not Platforms”, by Mike Masnick.)

In Conclusion

For those who’ve been involved with Verifiable Credentials since their official beginning in 2017, and even before that as Timothy has, the idea that a particular new flavor of VCs calls itself “second generation” would seem presumptuous, as there are several competing data models, each with their own adherents and arguments, each feeling that their favored flavor is superior to the others for one reason or another.

In this piece we’ve made detailed arguments as to why ACDCs are at a new, generational level compared to all other existing VC data models, and we invite reasoned arguments to the contrary.

¹ See Harvard Business Review’s What is Disruptive Innovation?

² See Crypto isn’t decentralized, Blockchain is not decentralized, and Web3 is not decentralized