The Hitchhiker’s Guide to KERI. Part 2: What exactly is KERI?
TLDR: KERI is a decentralized management protocol for persistent self-certifying identifiers, called Autonomic Identifiers (AIDs), using novel key pre-rotation mechanisms. KERI utilizes hash-chain verifiable data structures, called Key Event Logs (KELs), without a total-ordered globally distributed consensus mechanism.
This blog is the second part of a three-part series, the Hitchhiker’s Guide to KERI:
- Part 1: Why should you adopt KERI?
- Part 2: What exactly is KERI?
- Part 3: How do you use KERI?
This part explains only essential components that constitute the KERI protocol while not going into deep technical details.
An Identity Overlay for the Internet
Fragmentation in the decentralized identity ecosystem
As outlined in a recent “Wallet Strategy” series by Dan Robertson, one of the biggest problems in the decentralized identity space is its presently fragmented ecosystems. This is an extremely complex issue that involves many business and technical aspects—including credential formats, credential exchange protocols, and many more. This blog limits the scope of the discussion to identifiers and key management, also known as the DID methods.
As of March 2024, there are a total of 189 DID methods registered in the W3C DID Specification Registries. This number has been increasing steadily since the registry was created in 2020, and there are likely a hundred more DID methods out there in the wild, which have not yet been registered.
Although a large proportion of these methods are experimental, some of which have no longer been maintained, this number has raised significant concern among many members of the digital identity ecosystems. In the past few years, this topic has also been the subject of heated debates. While some argue that the abundance of DID methods is a sign of a thriving ecosystem, many contend that the sheer diversity has spawned considerable interoperability challenges.
While this blog shall not take part in the debate, one cannot help but wonder “Could there possibly be a unifying DID method that covers the use cases of all others?” This is precisely what KERI attempts to be.
An elephant in the room
However, we have to address a big elephant in the room before we continue.
KERI is indeed a DID method that was designed to be the “one universal standard that covers everyone’s use case”. However, adding one more DID method to the ever-growing list does not necessarily mitigate the situation, and it remains uncertain if KERI will ever achieve widespread adoption.
Putting all that aside, KERI provides unique properties and benefits not found in other DID methods, as elaborated in Part 1 of this series. What makes KERI special is also the fact that it is not just another DID method. The KERI protocol has a grander vision of being the identity overlay for the internet.
KERI is a decentralized identity protocol designed to be a secure identity overlay for the internet.
An Identity Overlay for the Internet
The internet is arguably one of the most important inventions in human history, enabling instant connections between everyone across the globe. The success of the Internet is attributed to its hourglass model where the Internet Protocol (IP) is the one common protocol for all supporting protocols below it and all applying protocols above it, i.e., the IP protocol being the spanning layer of the Internet.
Unfortunately, as the late Kim Cameron once wrote in The Laws of Identity in 2005, “The Internet was built without an identity layer.” Given the immense complexity and widespread usage of the Internet, attempting to reconstruct its infrastructure to integrate such a layer is simply unfeasible. Hence, the development of an identity solution must be overlaid on the existing Internet framework. To achieve global interoperability, such an identity overlay must also embody an hourglass shape, serving as a trust-spanning protocol that seamlessly links all Web2 and Web3 applications.
The Trust Spanning Protocol Task Force (TSPTF) under the Trust Over IP (ToIP) Foundation is currently developing the trust spanning protocol where KERI is used as one of its candidate protocols for Verifiable Identifiers (VIDs).
Foundational Components of KERI
The previous section explains what KERI is at the conceptual level where it is designed to be the identity overlay for the internet and is also a variant of DPKI. To get deeper into the technical details,
KERI is a decentralized management protocol for persistent self-certifying identifiers, called Autonomic Identifiers (AIDs), using novel key pre-rotation mechanisms. KERI utilizes hash-chain verifiable data structures, called Key Event Logs (KELs), without a total-ordered globally distributed consensus mechanism.
There are four foundational components for the KERI protocol as follows:
- Autonomic Identifier (AID)
- Pre-rotation
- Key Event
- Key Event Receipt
1. Autonomic Identifier (AID)
The KERI protocol is dedicated to the long-term management of a special class of identifiers that are both self-certifying and persistent. These identifiers are called autonomic identifiers (AIDs) in the KERI protocol.
Note: The word “autonomic” is an adjective that means self-ruling, self-governing, or self-regulating.
Self-Certifying Identifier (SCID)
A Self-Certifying Identifier (SCID) is an identifier that is uniquely and cryptographically derived from one or more key pairs. It is self-certifying—i.e., self-authenticating—since the controller of the SCID who holds the private could cryptographically verify their control by digitally signing a message, e.g., via a challenge-response protocol. The mapping between an identifier and its controlling key(s) is self-contained in the identifier itself. Hence, a SCID is considered a decentralized identifier as it does not rely on any trusted third party to generate or manage.
Note: An entity that holds an authoritative set of private keys is called a controller of an AID.
Basic SCID
A basic SCID is a variant of SCIDs that is cryptographically generated and bound to a single key pair. A basic SCID is ephemeral/non-transferable since it does not support the rotation of its key pair and therefore must be abandoned once the controlling private key becomes weakened or compromised from exposure. Hence, a basic is not persistent and is not suitable for long-term use.
The figure below demonstrates a process for creating a SCID, the controller captures sufficient entropy—e.g., using random noise from electronic equipment— to generate a key pair. A common basic SCID could be generated by using a hash digest of the public key.
AIDs are Persistent SCIDs
An AID is a variant of a SCID is that persistent as it may persist despite the evolution of its key state. In other words, the controller of an AID is capable of rotating their key pair while retaining the same AID. The mechanism for evolving the AID’s key state is called pre-rotation.
An AID is a primary root of trust in KERI
A root of trust is defined as a component or process of the system upon which other components rely. An AID is also a primary root of trust in the KERI protocol, which is purely cryptographic and decentralized, not relying on any centralized entity or even any blockchain network.
An AID is used as a primary root of trust in the KERI protocol that is purely cryptographic. As a consequence, the security of KERI-based identity systems only relies on cryptography, requiring no trust in external entities or even any blockchain network.
2. Pre-rotation
In the KERI protocol, the mechanism used to evolve a key state of an AID is known as pre-rotation. Except for a few special cases, an AID is cryptographically bound to at least two sets of key pairs, each of which holds different control authorities over the AID:
- The first set is called the current key(s), which holds the signing authority. The current key(s) of an AID can be used to, for instance, sign arbitrary messages such as verifiable credentials, authenticate the AID’s controller, and anchor external data to KERI’s ledgers, called key event logs.
- The second set is called the next key(s), which holds the rotation authority. The next key(s) of an AID can be used to change the key state of the AID, including changing the current keys, that is, transferring the signing authority to another set of key(s).
Here, the “s” refers to the case where a multi-signature scheme is employed, where multiple key pairs are required to establish signing and rotation authorities.
Pre-commitment
When an AID is created (i.e., incepted), the controller of the AID makes a pre-commitment to the next key(s) that hold rotation authority over the AID. The next key(s) are hidden using a cryptographic hash function, and they are only revealed at the moment the key state of the AID is rotated.
The next key pair — both private and public keys — must be kept secure and hidden until a key rotation is required. The rotation event revokes the current key pairs that hold signing authority as well as replacing the next key pairs that hold rotation authority.
This process is called pre-rotation since the next key pair is pre-committed for rotation while the actual rotation event may occur at a later time.
Formally, pre-rotation is a cryptographic pre-commitment of an AID to the next key pair(s) for key rotation.
Recovery from Quantum Attack
As pre-rotated next key(s) are hidden by a cryptographic hash function, the next key(s) are thus resistant to quantum attack. This is because hash functions are not vulnerable to the Quantum Shor’s Algorithm.
Unfortunately, the current key of an AID could still be broken by a quantum attack, allowing a threat actor with access to a quantum computer to gain the signing authority over the AID. However, the legitimate controller of the AID could still regain control over the AID by using the next key(s) to rotate the AID’s key state, perhaps using a quantum-safe algorithm for the new set of current keys.
Hence, the use of pre-rotation in the KERI protocol makes it quantum-recoverable.
3. Key Event
The key state of an AID is determined by a data structure called a key event that consists of the current key(s) and pre-rotated next key(s) as well as other configurations for the AID.
Note: The key state of an AID is defined as a set of currently authoritative key pairs for the AID and any other information necessary to secure or establish control authority over an AID.
Key Inception Event
The AID is itself cryptographically derived from its very first key event, called an inception event, thus giving the AID its self-certifying property. The inception event must also be cryptographically signed by the current keys.
The example below demonstrates a scenario where an AID has single key pairs for its current and next keys. An AID is derived and bound to the key inception event, which includes:
- the first public key, which is used as the current key,
- the digest of the second public key, which is used as the pre-rotated next key.
The first public key could be revealed to other entities while the pre-rotated second public key must be kept hidden.
Key Rotation Event
The pre-rotated next key(s) of an AID may be used to create a subsequent key event, called a rotation event, that changes the AID’s key state. The rotation event must be signed by the next key(s), revealing the next key(s). Hence, the next key(s) can be used for rotation only once, after which the next keys must be either discarded or repurposed as members of the new set of subsequent current key(s). The controller of the AID must also assign a new set of pre-rotated next key(s) in the rotation event.
Following the example above, the AID could be rotated to revoke the signing authority of the first key pair by using the private key of the pre-rotated second public key to sign a rotation event. In the rotation event,
- the second public key is now repurposed to be the new current key,
- a new key pair, the third public key, is pre-committing to the future rotation of the AID.
Key Event Log (KEL)
As the key state of an AID evolves, the key events are cryptographically linked in a hash chain that provides a key history for the AID. Such a data structure is called a Key Event Log (KEL).
Formally, a KEL is a hash-chain verifiable data structure used to verify the key state of an AID as it evolves through its lifecycle. A KEL could be compared to a transaction ledger in a traditional blockchain, where key events are transactions in the KERI protocol.
Following the example above, the KEL of the example AID starts with the inception event with the first public key and the hash digest of the second key. The inception event is chained to subsequent rotation events via the pre-rotation mechanism.
Hence, the control authorities — both signing and rotation — of the AID at any point in the KEL can be validated in a self-contained manner by verifying the signatures and recalculating the hashes that connect the key events in the KEL, all the way back to the inception event.
Note: A KEL is technically a type of “blockchain” in the traditional sense of an ordered list of records that are securely linked together via cryptographic hashes.
4. Key Event Receipt
At its core, the KERI protocol establishes an infrastructure facilitating the exchange of key events as well as key event receipts. This highlights the protocol’s designation as the “Key Event Receipt Infrastructure.”
The exchange of key events and key event receipts could carried either directly between controllers of AIDs or indirectly through supporting infrastructures.
Key Event Receipt
In the KERI protocol, communications and transactions revolve around the exchange of key events among controllers of AIDs. When a controller receives a key event, they can sign it using the key associated with their AID. This signed key event is called a key event receipt, which provides a non-repudiable proof that the recipient has received—i.e., witnessed—the key event.
Key Event Receipt Log (KERL)
Key event receipts of an AID could be recorded in a verifiable data structure called a key event receipt log (KERL). A KERL contains the signed key event history of an AID. A verifier of an AID may verify the AID’s key state by using a KERL.
Direct mode
Key events and key event receipts can be exchanged directly between two controllers. This is known as the direct mode in the KERI protocol.
In the direct mode, a controller of an AID may send its KEL to another controller, called a validator of the AID. Upon reception of a key event, the validator signs the received key events to generate a key event receipt and subsequently returns it to the controller as an acknowledgment. The controller now has a signed receipt that attests that the validator received and verified the key event message. This provides a trust basis for transactions between the controller and the validator. The validator may not later repudiate its signed receipts nor refer to a different key event history in interactions with the controller without detection by the controller.
Each party would thereby in turn be the controller for their AID and the validator for the other’s AID. Each could maintain a KEL of their own AID as well as a KERL of the other’s AID. This allows each party to be trusted with respect to this pairwise interaction.
Indirect mode
Since a controller of an AID may not always be online. The controller may designate witnesses that store and forward key events to any requestor. This is known as the indirect mode in the KERI protocol.
The purpose of the indirect mode is to provide a highly available trustworthy service for discovering the KEL of an AID. The witnesses also sign the key events to create witnessed key event receipts.
An example of the indirect replay mode with a set of witnesses that are designated by the controller is shown below.
Additional Infrastructures
Since the witnesses are designated by the controller of the AID, they may not be entirely trusted by validators of the AID. For example, the AID and its witnesses could be compromised or behave maliciously such that the witnesses provide inconsistent key event histories, called duplicity.
Consequently, a validator of the AID could designate additional infrastructure to detect duplicity of the AID’s key event history. These additional infrastructures include watchers, jurors, and judges. The infrastructures may be designated a validator or a group of validators to “watch” the witnesses to detect any duplicity in the AID’s key event history as well as make decisions on the validity of the AID’s KEL.
Blockchain as KERI witnesses and watchers
As discussed in Part 1, while the KERI protocol does not necessarily rely on a blockchain, KERI may leverage blockchain for the discovery and verification of KELs. In other words, blockchains could be utilized in a KERI-based identity system practically taking the roles of KERI witnesses and watchers. Hence, you could have the best of both worlds, obtaining the advantages that traditional blockchains offer. Since the root of trust in the KERI protocol is within the AIDs themselves, the AIDs could be migrated from one blockchain network to another, avoiding the ledger-locked problem that plagues most blockchain-based DID methods.
KERI in a Nutshell
Conceptually, the Key Event Receipt Infrastructure (KERI) protocol is a decentralized identity protocol designed to be an identity overlay for the Internet. Each word in KERI has the following meanings:
- Key refers to asymmetric key cryptography that is used to control persistent self-certifying identifiers, called Autonomic Identifiers (AIDs).
- Event refers to a series of Key Events in a hash-chain verifiable data structure called Key Event Logs (KELs) that record the key-state evolution of AIDs via the Pre-Rotation mechanism.
- Receipt refers to signed receipts of key events, called Key Event Receipts that provide non-repudiable proof while exchanging key events between AIDs.
- Infrastructure refers to the protocol for exchanging non-repudiable key event receipts, including the designation of Witnesses, Watchers, Jurors, and Judges.
The next part of the series discusses “How do you use KERI?” which includes references to other introductory materials and a collection of open-source implementations, standards, and whitepapers.
