KERI: A more Performant Ledger for Trusted Identities
Securing the control of decentralized identifiers at the root with ambient verifiability
One of the fundamental problems of blockchain-based business models is that there are inescapable technical complexities at the root of every business decision. The complex relationship between decentralized identity and blockchains is no exception. This article sets out to explain why many functions of decentralized identity systems can be moved off-chain and onto a more lightweight consensus network called KERI, which will make the identity systems that use it simpler, more modular, easier to secure, and faster to scale. The explanation is unavoidably a little technical, but the business value is indisputable.
“I am thrilled that Spherity is contributing substantially to the implementation of the core KERI libraries being open-sourced through the Decentralized Identity Foundation. It has been a pleasure working with Carsten over the years on writing projects and I am glad to see this new project bring that collaboration into the practical realm.”
— Sam Smith, General Partner at Digital Trust Ventures and author of the KERI whitepaper
When blockchain is a problem, not a solution
There is an idea that circulates widely, particularly in the cryptocurrency press and the social media communities around it, which defines “decentralized identity” as a way of getting identity assurances “from and for” blockchains. According to this definition, the primary function of decentralized identifiers and credentials is to bind cryptocurrency addresses to real-life people more reliably.
At Spherity, we find this definition a little reductive and misleading. Instead, we like to say that although blockchain is a crucial ingredient, decentralized identity systems should treat each blockchain the way they treat any other silo, platform, or system. Open identity systems should stay agnostic to all silos and blockchains, treading lightly to keep all their options open and minimize their dependencies. Blockchain-style ledgers and DAGs are important infrastructural primitives, alongside other consensus networks, zero-trust clouds, and open protocols; all have their limits and are better suited for some use-cases than for others.
By most bearish interpretations of the GDPR, identifiers used by humans are Personally Identifiable Information (PII) insofar as they can be correlated. Depending on how optimistic or pessimistic you are about the mechanisms of correlation and tracking, even an identifier bound to a vehicle but controlled by a human could be PII by this logic. When DID documents for either a human or a privately-owned, -held or -used thing such as a vehicle, e-Bike, smart home appliance or smart meter are anchored on an immutable blockchain, it is still a matter of heated debate whether this anchoring is free from the correlation liability that risks these documents being classed as PII.
This article tries to overview some specific requirements of identity systems, particularly high-security enterprise identity systems, for which blockchains are too expensive, too complex, too hard to scale, and too slow-moving in their governance. Designing secure, performant systems, there are many pressing reasons not to rely too heavily on blockchains:
- to avoid “vendor-lock-in” or infrastructural “sunk cost” calculations that can be just as limiting;
- to outlive a blockchain that might fork for fail;
- to strike a nuanced balance between mutability and immutability of key data;
- to avoid forcing customers or business partners to share infrastructure costs which can be hard to predict and control.
Most importantly, however, blockchains are expensive and slow because they solve very hard engineering problems (the so-called “global double spend” and “global ordering” problems), which are universal in currency systems but rare in identity systems. In identity systems, we do not need global ordering. Decentralized identity systems just need a cryptographically secure local ordering of key rotation, identifier inception and configuration update events. This cryptographically secure ordering can be achieved with simple chained cryptographic data structures built upon very efficient and lightweight protocols. In identity systems, maximizing trust while minimizing immutability and correlation risk are actually the primary system-wide design challenges.
A new mechanism is needed to build security and portability into a blockchain identity system with only certain key functions restrained by a blockchain; many other functions are best done more lightweight and flexible forms of consensus infrastructure. The Key Event Receipt Infrastructure (KERI) mechanism is designed in accordance with zero trust security best practices and end-to-end verifiability. This design choice makes KERI very robust for enterprise use cases including critical infrastructure. We believe that this technology is especially useful for securing cyber-physical value chains in cloud-edge infrastructures.
Note: explaining KERI is beyond the scope of a single Medium article, so instead we will try to outline the importance of KERI functionally, looking separately at four major capabilities KERI adds to decentralized identity systems. For a more thorough, bottoms-up explanation of how the system is engineered and its inner workings, Sam Smith has published and socialized the concepts extensively in many forms: has been iterating his whitepaper since mid 2019, as well as convening information/recruiting sessions at the semiannual IIW conference and giving a webinar on SSIMeetup.org.
1.) How a “Control Layer” for Makes DID Systems Safer
Knowing that KERI stands for Key Event Receipt Infrastructure does not make immediately clear what KERI is or why decentralized identity needs it. The most illuminating place to begin might be to explain where these key events happen, and where the receipts live. “Key events” refers to the creation and rotation of decentralized identifiers, which provide records for all kinds of security and control checks. In today’s decentralized systems, these events take the form of data written to a blockchain, and KERI provides a security “overlay” sitting on top of that blockchain to keep it honest.
What KERI provides is a layer on top of the underlying blockchain where these events are logged, offering a kind of “security log” of the history of a DID. Each key event receipt contains less information than was written to the blockchain, and importantly, no information about the contents of the DID Document. It might seem redundant to have both a lightweight and a verbose version of the DID’s current state, but this lightweight version allows an entity to prove control of a decentralized identifier at the KERI layer, aka the “control layer”, sparing the more feature-rich and resource-intensive lower layers significant traffic and risk. Dealing exclusively with cryptographic key information makes this control overlay a “thin layer” in software engineering terms, minimizing its complexity and leaving all privacy/data leakage risks at higher and lower layers.
This thin layer can be deployed in multiple ways, depending on the identity system and context. In “indirect mode,” a collective KERL (key event receipt log) gets built up across consenting nodes, creating a chronological log of rotation events for DID keys. If key rotation events are also registered on the blockchain, this redundancy layer can act as a security log for the complex software handling identifiers and writing their proofs to the blockchain. Any time a discrepancy arises between the information-rich operations of the identity system and the more predictable and deterministic workings of the dedicated cryptography-only layer, this discrepancy signals a bug or a breach!
2.) “Quantum-hardening” and Scaleable Division of Labor
Key event receipt logs (KERLs) do not need to be passive security logs, however; they can be configured as an active component in an identity system, taking over some of the duties from the base layer such as a distributed ledger. In this form of KERI-powered DID methods, the KERL is made authoritative for “key state,” meaning that it can be queried instead of the blockchain to prove control of an identity. Depending on the context and level of trust, this query can also ask for proof linking the current key state back to a “genesis event” published to a ledger, or even bypass the ledger entirely.
This more autonomous and proactive role for KERI is particularly powerful for engineering high-security systems where public keys are rotated on each usage, which among other benefits also mitigates so-called “quantum risk.” This refers to the threat posed by “quantum computing,” an alternate architecture for building supercomputers that might soon provide astronomically more compute force for certain kinds of mathematical operations. These operations include the brute-force guesswork that could theoretically break or circumvent much of today’s strongest asymmetrical encryption mechanisms, particularly in cases where a public key has been “exposed” (i.e. used publicly) multiple times.
Within cryptography circles, there is a tendency to see public key exposure as an inherent risk, not just to quantum computing, but also to what privacy engineers call “correlation risk”. This led to the shielding of public keys behind an extra layer of hashing obfuscation in the core code of the bitcoin mainnet since 2009. KERI provides a similarly lightweight mechanism for deriving a disposable (but provably linked) public key for each exposure, rather than exposing public keys.
One crucial side-effect of moving these operations to a separate, thin layer is that the lion’s share of the traffic-load that identity systems put on their underlying blockchains is moved to a dedicated layer with massive efficiency gains. This makes blockchain-rooted identity systems significantly more scalable and cost-efficient, since really only genesis events justify the cost of a blockchain transaction. Particularly in public blockchains still operating on a cost-of-work basis, the real-world consequences of this efficiency gain, particular for blockchain’s carbon footprint, are hard to overstate.
3.) How a Second Consensus Layer Delivers DID Portability
Before turning to the third way KERI can relate to the blockchain layer beneath it, it is important to mention one crucial technical detail about how KERL logs work — like modern “NoDB” file systems, the are replicated and synchronized by consensus across a variable-sized cloud of nodes. Unlike blockchains, however, the stakes are lower as there is no double-spend problem to be solved: the size of the node cluster can grow or shrink, propagation can be fast or slow, and immutable, unanimous shared state is not required. Every event-chain does not need to reach every node, and overlapped networks of nodes can mutually reinforce each other even if they do not replicate 100% of each other’s logs.
This architecture flexibility around scope and domain can be a little hard to wrap one’s head around, but in plain language, it can be seen as a bridging technology between the stricter consensus systems that govern blockchains. This allows the verifications and assurances of different trust domains to be linked to one another, and allows individual identities to travel between them with more security. As one important feature of KERI is ledger-portability it mitigates the risk of a ledger lock-in when anchoring decentralized identifiers to a given chain. As key event logs can be stored on paper, on edge devices or in cloud infrastructures, KERI provides an instrument for ambient verifiability of an identifier.
If a given identifier or cluster of related identifiers spans multiple blockchains or “trust domains,” this history is thus verifiable and “unified” across both, even if they use different cryptography and different forms of verification. Even if a blockchain or ledger “dies,” its orphaned identifiers can move to another one and verifiably stitch together these two trails of receipts. For this reason, there is some discussion in the KERI developer community about making a meta-DID method called DID:uni for bridging and providing equivalence between more fully-functional DID methods.
KERI enables a kind of equivalence between DID methods that could be very powerful. Sam and I like to call KERI a general unified DID Method (as an analogy to the General Unified Theory (GUT) in physics). The KERI DID method, DID:uni, could end up being the bridge between all the more complex DID methods, offering both shared security and portability.
4.) Identifier Portability beyond DIDs
One powerful application of this “unified” DID method is that it can even be used to “upgrade” some kinds of existing traditional identifiers to a decentralized identifier registered to a blockchain. Conversely, this bridging function can run in the other direction as well, generating a so-called “self-certifying” identifier linked to a full-featured DID.
These “self-certifying identifiers” are important in decentralized networking and zero-trust routing systems, and have some features of DIDs but are simpler and more useful for many non-human use cases, including IoT use cases. They could also prove essential to some forms of decentralized data exchange. These more experimental and still largely theoretical applications are admittedly quite far in the future given that KERI is still in an early phase of development, the urgency of bringing KERI to production is that it helps secure a future-proof and widely-interoperable position for DIDs in the decentralized future of IT.
Last and definitely not least from a European point of view, KERI can also be used in so-called “direct mode” to maintain a private one-to-one “ephemeral connections” that leave no immutable traces by design. Combined with the crucial distinction that KERL logs do not need to be immutable, KERI opens up new forms of GDPR liability management and privacy-engineering (including the right to be forgotten).
In some use cases, this ephemerality of completely off-chain pseudonyms linked mutably to other identities is paramount for privacy, particularly for human privacy. In other cases, cybersecurity is more important, since the elimination of the need for a third-party to register and vouchsafe these ephemeral connections greatly reduced attack vectors for private communications. In this regard, KERI can play a similar and perhaps complementary role to the Peer:DID work spearheaded by Evernym CTO Daniel Hardman, being developed in the open through the Decentralized Identity Foundation in the coming months. Aligning these various sub-DID primitives and ephemeral DID methods is a major priority for the remainder of 2020 in the DIF’s interoperability working group.
The Business Case for KERI-backed Identity
Overviewing at such a high level the technical possibilities of DID systems backed by KERL logs, it can be easy to lose sight of the many consequences for the bottom-line. Technically, it might sound like KERI introduces a lot of complexity and redundancy, but the counterintuitive net result of this added complexity is that it spreads cybersecurity risks and infrastructure costs across two overlapping but distinct consensus networks. The new, fit-for-purpose control layer is far cheaper and less complex per transaction, making the whole system markedly more scalable and secure at a lower net price. In this sense, we could call it a very cost-effective security layer.
For Spherity’s high-value use-cases in the the highly-regulated industries, the division of labor between an ultimate trust basis (the blockchain system) and the secondary trust layer (the network of KERI nodes) works to lower infrastructure costs overall and allow greater trust across organizational boundaries and identity system boundaries. Open standards guarantee theoretical equivalence and portability between decentralized identity systems based on different blockchains, but KERI provides an open-source, bare-minimum mechanism by which to make this promise of equivalence and portability concrete. By introducing a shared, open-source portability layer across the major players in the decentralized identity space, it greatly amplifies the network effects and adoption curve of decentralized identity as a whole.
Lastly, was could also call KERI an efficiency layer, scaling up growth at lower cost in much the same way blockchains can greatly boost their scale and efficiency by moving traffic to “Layer 2” and sidechains. By leaving the “Layer 1” of blockchain out of most identity transactions and ephemeral or private relationships, the lion’s share of infrastructure can operate much more efficiently, but still inheriting the trust of the underlying ledger and its public, immutable transactions.
The KERI work is ongoing, open-source, and starting this month, supported by the European Commission with a small grant in recognition of its role as a multiplier of European business adoption of decentralized identity technologies. To see what decentralized identity can do for your business, with or without a KERI-powered “Layer 2”, contact our business developers or proceed straight to booking a demo of our cloud wallet. Also feel free to subscribe to our newsletter.
If you have any questions, feel free to reach out or book a demo of our Cloud Identity Wallet directly. You can also follow us here, or on LinkedIn, or sign up for our newsletter.
