KERI jargon in a nutshell. Part 1: KERI and AID.

Photo by Markus Spiske on Unsplash

Key Event Receipt Infrastructure (KERI) is a novel approach to decentralized key management and identifier systems. Since its initial publication in 2019, KERI has become a promising alternative to a distributed consensus ledger (i.e. a blockchain) for self-sovereign identities (SSI). The KERI community has also been growing rapidly in the past few years, spawning several open-source projects, such as WebOfTrust, as well as getting a major adoption by the Global Legal Entity Identifier Foundation (GLEIF) in the form of verifiable LEI (vLEI).

I was first introduced to KERI by Sam Smith, i.e. the author himself, in one of the Internet Identity Workshops in 2020, and my first impression of KERI was:

Holy cow, that’s a lot of jargon.

As someone without a background in cybersecurity, KERI was definitely not an easy concept to grasp. It also contains a huge collection of newly defined terms, making a steep learning curve for all but a few cybersecurity professionals and computer scientists. However, as I went down the KERI rabbit hole, I slowly became convinced that KERI is one of the most elegant, if not the most elegant, implementations for identity systems to date.

Hence, I would like to write an introduction to important jargon for understanding KERI. This introduction is divided into five parts, as follows

• Part 1 deals with the term related to Autonomic Identifier (AID) as well as operations and data structures defined in KERI. It also, in a way, provides a summary of the KERI whitepaper.
• Part 2 deals with the term related to Self-Addressing Identifier (SAID) and Authentic Chained Data Container (ACDC).
• Part 3 deals with the term related to Out-of-Band Introduction (OOBI) and Issuance and Presentation Exchange Protocol (IPEX)
• Part 4 deals with the term related to Composable Event Streaming Representation (CESR) and CESR-Proof Signatures.
• Part 5 deals with the term related to Transaction Event Log (TEL) and Public Transaction Event Log (PTEL)

Note that this blog does not aim to be comprehensive and only introduces each term at its surface level. For more comprehensive materials, I recommend the following:

• KERI Whitepaper (https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/KERI_WP_2.x.web.pdf)
• KERI Presentation by Sam Smith at SSI Meetup, https://ssimeetup.org/key-event-receipt-infrastructure-keri-secure-identifier-overlay-internet-sam-smith-webinar-58/
• KERI Community main repository, https://github.com/WebOfTrust/keri
• Trust Over IP ACDC wiki, https://github.com/trustoverip/acdc/wiki/

Table of Contents

· Root of Trust
· Identity Architecture
· SCID (Self-Certifying Identifier)
· AID (Autonomic Identifier)
∘ AN (Autonomic Namespace)
∘ Basic Prefix
∘ Self-Addressing Prefix
∘ KERI DID Method
· Pre-Rotation
∘ Partial Pre-Rotation
· KERI (Key Event Receipt Infrastructure)
∘ Establishment Event
∘ Non-Establishment Event
∘ Key Event Ilk
∘ Interaction Event
∘ Extended Rotation Event
∘ Key Event Sequence
∘ KEL (Key Event Log)
∘ Key Event Receipt
∘ KERL (Key Event Receipt Log)
∘ Duplicity
∘ DEL (Duplicitous Event Log)
· Protocol Operational Modes
∘ Direct Replay Mode
∘ Indirect Replay Mode
· Related Entities
∘ Controller
∘ Verifier
∘ Validator
∘ Witness
∘ Watcher
∘ Juror
∘ Judge
∘ Resolver
· KA2CE (KERI’S Agreement Algorithm for Control Establishment)
· Cooperative Delegation

Root of Trust

A Root of Trust is defined as a component or process of the system upon which other components rely on. In an identity system, it is something on which the security of the system is dependent, and great care must be taken to design and implement a root of trust. There are two main types of roots of trust, namely primary and secondary roots of trust:

• A primary root of trust is irreplaceable and provides trust that is uniquely necessary to the system. Any compromise on the primary root of trust also compromises the trustworthiness of the entire identity system. In a blockchain-based identity system, the primary root of trust is the blockchain. In KERI, on the other hand, the primary root of trust is in a self-certifying identifier — called an autonomic identifier (AID) — that is purely cryptographic and is under the control of an end user.
• A secondary root of trust is replaceable and provides trust that may be also provided redundantly by another component. In a KERI-based identity system, a Key Event Log (KEL) is considered a secondary root of trust.

Note 1: A blockchain may be used with KERI and an autonomic identifier (AID). In this case, the blockchain serves as a secondary root of trust for the AID.

Note 2: KERI also has additional supporting mechanisms that serve as secondary roots of trust, including a Key Event Receipt Log (KERL), witnesses, watchers, etc.

Identity Architecture

An identity system requires a mechanism to uniquely identify each entity that participates in all transactions.​ To achieve this requirement, the architecture of identity systems has three common components: (1) a controller (i.e., an end-user), (2) a public-private key pair, and (3) an identifier that uniquely identifies the controller. A key pair allows a controller to create a digital signature that cryptographically proves the authenticity of a transaction. An identity system binds the three components, and any weak link in such a system presents a vulnerability to cyberattacks.

Binding of a controller, authentication factors, and identifiers in identity systems.

The binding between a controller and a key pair can be easily made strong by using a cryptographically secure pseudorandom number generator (CSPRNG), which collects sufficient entropy to generate a key pair. As long as the controller can keep the private key secure, such binding is considered strong. However, how the controller and the key pair are bound to an identifier depends on the types of identity architectures. In The Architecture of Identity Systems by Phil Windley, three types of identity architectures are defined: namely Administrative, Algorithmic, and Autonomic architectures.

• An Administrative Architecture relies on an administrator—which is a person or an organization—to be the primary root of trust. The administrator binds an identifier to a key pair of the controller. Such bindings are considered weak as it is inherently vulnerable to faulty operational administration. A classic example of this architecture is the Domain Name System (DNS) with Certificate Authorities (CAs), which suffers from security exploits such as DNS hijacking and requires additional infrastructure to mitigate the risk.
• An Algorithmic Architecture relies on a blockchain to be the primary root of trust that registers and strongly binds a public key to an identifier. In a system where the identifier is cryptographically derived from the public key, all three bindings are considered strong. Here, the controller of the key pair can assert control over the identifier, and anyone with access to the ledger can algorithmically verify the controller-identifier binding. Most SSI implementations that are built on blockchains fall into this category.
• An Autonomic Architecture is similar to an algorithmic architecture where a controller generates a key pair and derives an identifier, providing strong bindings to all components. The difference is that, in an autonomic architecture, the controller is the primary root of trust. The controller records the binding between the key pair and the identifier in a local Key Event Log (KEL), instead of recording such binding in a globally shared ledger. KERI is an autonomic identity architecture.

In summary, the main difference between KERI and blockchain is that blockchain relies on a network of validators while KERI requires only local operation by a controller.

Here, we specifically refer to the term “blockchain” as a “distributed consensus ledger” with a global ordering of records.

SCID (Self-Certifying Identifier)

A SCID (Self-Certifying Identifier) is an identifier that is uniquely and cryptographically derived (e.g. by using a hash function) from a public key of a key pair. It is self-certifying (or more precisely self-authenticating) because it does not rely on any trusted third party. The controller of the SCID can cryptographically prove their control by using the private key of the same key pair to generate a digital signature on a message, and the verifier may extract the public key from the SCID itself to verify the signature.

In a basic SCID, the mapping between an identifier and its controlling public key is self-contained in the identifier itself. A basic SCID is ephemeral/non-transferable, i.e., 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.

Cryptographic binding between a public key and a self-certifying identifier (SCID).

AID (Autonomic Identifier)

Formally, an AID (Autonomic Identifier) is a self-certifying identifier that is the primary root of trust in KERI. An AID can be considered a variant of a decentralized identifier that does not rely on a blockchain. An essential property of an AID is that 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 AID.

A key state of an AID refers to the set of currently authoritative and pre-rotated key pairs.

There are two types of AIDs, namely transferable and non-transferable AIDs.

• A Non-transferable AID—which is also known as an ephemeral AID—is cryptographically bound to a single key pair that is not rotatable. This type of AID is not meant for long-term persistent use and should be abandoned/replaced after its private key becomes compromised. Within KERI, the primary use for non-transferable AIDs is for AIDs of witnesses and other supporting roles.
• A Transferable AID is cryptographically bound to two sets of key pairs where one is called the current key pair and the other is called the next key pair. The controller can rotate the key pairs while retaining control over the AID. This process is called pre-rotation and is discussed in more detail later.

Simple examples of non-transferable and transferable AIDs (using a single-signature scheme).

AN (Autonomic Namespace)

In an identity system, a namespace is defined as a grouping of identifiers for a set of related resources and their attributes. In other words, a namespace provides a systematic way of organizing identifiers by employing some scheme for assigning identifiers to the elements of the namespace.

A name-spacing scheme uses a prefix or prefixes hierarchically to compose identifiers. The following is an example of a namespace scheme for addresses within the USA that uses a hierarchy of prefixes:

state.county.city.zip.street.number

An AN (Autonomic Namespace) is a namespace that has a self-certifying prefix that can be cryptographically verified as a root control authority over its namespace. Each identifier (i.e., an AID) from an autonomic namespace includes a prefix that is either the public key or is uniquely derived from the public key(s) of the incepting key pair(s). The associated private key may then be used by the controller to authoritatively sign statements that authenticate itself and authorize the use of the AID.

The following is the Autonomic Namespace Syntax and an example from the KERI whitepaper:

aid:prefix[:options][/path][?query][#fragment]

aid:BXq5YqaL6L48pf0fu7IUhL0JRaU2_RxFP0AL43wYn148/path/to/
resource?name=secure#really

Here, “BXq5YqaL6L48pf0fu7IUhL0JRaU2_RxFP0AL43wYn148” is the AID prefix.

Basic Prefix

A basic AID includes a prefix that is composed of a Base-64 (URL safe) derivation code prepended to Base-64 encoding of a public digital signing key. The derivation code is a special character that encodes the derivation process. Abstractly the prefix may be represented as follows:

Basic Prefix. (Reference: KERI Whitepaper.)

Self-Addressing Prefix

A basic prefix is bound to a single key pair, which makes the AID non-transferable. For transferable AIDs, it is more useful to bind the identifier to the content digest (i.e. a cryptographic hash) of the inception statement. The inception statement includes the derivation code, the public key, the configuration, and the signature as shown below.

An inception statement for an inception event. (Reference: KERI Whitepaper.)

Abstractly the prefix for an AID may be represented as follows:

Self-Addressing Prefix. (Reference: KERI Whitepaper.)

There are also variants of self-addressing prefixes including:

• Multi-Sig Self-Addressing Prefix where the inception statement contains multiple sets of public keys (and the digests of multiple pre-committed keys) for a multi-signature scheme.
• Delegated Self-Addressing Prefix, which involves two AIDs—namely a delegating AID and a delegated AID. A delegated AID prefix may be created by including the delegating prefix in the delegated prefix inception configuration data.

Pre-Rotation

A transferable AID is cryptographically bound to two sets of key pairs, each of which plays a role that together establishes complete control authority over the AID. In this case, the control authority over the AID is split between the two sets, as follows:

• The Current Key Pair(s) holds the signing authority.
• The Next Key Pair(s) holds the rotation authority.

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.

For simplicity, let’s assume that single key pairs (i.e. using a single-signature scheme) are used for the current and next key pairs.

The current key pair may be used for the day-to-day operation of the AID, such as digitally signing documents and authenticating the AID’s controller via challenge-response protocols. The public key of the current key pair is revealed to external parties so that they can be used to verify signatures.

On the other hand, the public key of the next key pair is only pre-committed and hidden by a cryptographic digest (hash). The next key pair — both private and public keys— must be kept secure 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 simply 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.

In the example below, an AID is derived from the 1st key event that includes the 1st pubic key (current key) and the digest of the 2nd key (pre-committed next key). Once the 1st key pair is rotated, the 2nd public key is exposed and becomes the new current key. Here, the 3rd key pair is also generated, and the digest of the 3rd public key is included in the 2nd key event as the new next key.

A simple example of pre-rotation for a transferable AID (using a single-signature scheme).

Pre-rotation gives the controller of an AID the ability to recover their authority over the AID even if the current private key becomes compromised or lost.

Note 1: The `new` current key in an establishment event may not necessarily be the same key as the next key from the `previous` establishment event. In other words, during rotation, the controller may assign a new key pair to be the current key instead of using the previously pre-committed key pair.

Note 2: A controller may choose not to replace the next key pair during rotation. In this case, the AID becomes non-transferable.

Note 3: Pre-rotation makes KERI post-quantum secure. Although Shor’s algorithm can break public key cryptography in poly-logarithmic time, cryptographic hashes are considered quantum-safe. Even if someone may break the current key pair of an AID, the controller of the AID can still recover the control authority by using the next key pair that is hidden by a cryptographic hash.

Partial Pre-Rotation

When a multi-signature scheme is used to manage an AID, pre-rotation becomes slightly more complicated as multiple key pairs are required to establish signing and rotation authorities. A rotation event on a set of pre-rotated keys may keep some keys in reserve (i.e. unexposed) while exposing others as needed. This is known as partial pre-rotation.

For example, the inception of an AID has three current key pairs called [A0, A2, A3] and three next key pairs called [A3, A4, A5], which are pre-rotated by hashes [H(A3), H(A4), H(A5)]. Here, Ai represents a public key and [H(Ai)] represents a hash of a public key Ai. The key state at the inception of the AID can be shown as follows:

• The current keys: A0, A1, A2
• Hashes of the next keys: H(A3), H(A4), H(A5)

A rotation event may expose [A3, A4] while reserving [A5] as well as generating [A6] to be a new signing key and [A7, A8, A9] to be new pre-rotated keys. The key state of the AID after the rotation can be shown as follows:

• The current keys: A3, A6
• Hashes of the next keys: H(A5), H(A7), H(A8), H(A9)

A simple example of reserved (partial) rotation.

This example is also known as reserve rotation. There are two main types of partial rotations, namely reserve and custodial rotation.

• Reserve Rotation enables pre-rotated key pairs designated in one establishment event to be held in reserve and not exposed at the next (immediately subsequent) establishment event.
• Custodial Rotation involves another entity, called a custodial agent, whose role is to hold signing authority (current keys) while the original controller can hold exclusive rotation authority (next keys). The holder of the rotation authority can then at any time without the cooperation of the custodial agent if need be revoke the agent’s signing authority and assign it to some other agent or return that authority to itself.

KERI (Key Event Receipt Infrastructure)

The Key Event Receipt Infrastructure (KERI) is a decentralized public key infrastructure for secure self-certifying identifiers (i.e., AIDs) that aims at minimum sufficiency and maximum security.

KERI uses a hash-chain data structure for managing public keys and AIDs, so it may be considered a type of “blockchain”. However, unlike traditional blockchains, KERI is not globally ordered and does not have a distributed consensus mechanism. As a result, KERI is not double-spending-proof and cannot be directly used as an infrastructure for crypto-currency or other crypto-assets. On the other hand, KERI is specifically made to be an infrastructure for identity systems and is often considered more scalable, more performant, and more decentralized—compared to blockchains.

A traditional blockchain with a distributed consensus mechanism is globally ordered in the sense that all participating nodes (validators or miners) share an identical ledger, which is an ordered list of transactions.

Each word in KERI has the following meaning:

• Key — asymmetric key cryptography.
• Event—a series of key events that are related to the management of public keys and identifiers, including key rotations.
• Receipt—signed receipts from witnesses of key events that provide an additional threshold structure
• Infrastructure—an open-source framework for building decentralized identity systems.

As its name suggests, KERI is all about key events, which are related to the management of persistent self-certifying identifiers (i.e., AIDs). A data structure that represents a key event—including signatures on its body—is called a Key Event Message. There are two types of key events in KERI, namely Establishment and Non-Establishment events.

Establishment Event

An Establishment Event is a key event that `establishes` changes in the key state of an AID, which includes the current set of authoritative and pre-committed key pairs for an AID. There are two sub-types of establishment events, namely inception and rotation events.

• An Inception Event is an establishment event that provides the incepting information needed to derive an AID and establish its initial key state.
• A Rotation Event is an establishment event that provides the information needed to change the key state which includes a change to the set of authoritative key pairs for an AID.

An establishment event message may contain the current key(s) and the digest of the next key(s), signature(s), and other metadata.

Establishment Event Message. (Reference: KERI Whitepaper.)

Non-Establishment Event

A Non-Establishment Event is a key event that does not change the current key state for an AID. Typically the purpose of a non-establishment event is to anchor external data to the current key state of the AID, as established by the most recent prior establishment event.

A non-establishment event message contains the seals of the anchored external data and signatures, which are signed by the current key(s).

Basic Non-Establishment Event Message. (Reference: KERI Whitepaper.)

In KERI, there are four types of seals:

• A Digest Seal is a simple digest (cryptographic hash) of external data.
• A Root Seal is a hash tree root (the Merkle tree) of external data.
• An Event Seal includes the AID prefix, sequence number, and digest of a key event in a Key Event Log (KEL). An event seal anchors one key event to another key event, which may or may not be from the same key event sequence.
• A Location Seal includes the AID prefix, sequence number, “ilk” and prior digest from a key event. A location seal is used when two seals in two different events are cross-anchoring each other. This provides a cross reference of one event to another where the other event’s digest must include the seal in the event contents so it cannot contain the first event’s digest but the digest of the preceding event.

Key Event Ilk

Note that the key event ilk—or simply ilk—indicates the type of the key event. There are 7 types of ilks defined in the KERI whitepaper:

• “icp” for an inception event
• “rot” for a rotation event.
• “ixn” for interaction event
• “dip” for delegated inception event
• “drt” for delegated rotation event
• “rct” for event receipt message
• “vrc” for validator event receipt message

Specific applications may use other event ilk values. The definitions and discussions of receipt and validator will be given later below.

Interaction Event

An Interaction Event is a type of non-establishment event that is interleaved into the key event history along with establishment events. An interaction event includes an event-specific interaction data payload in the form of an array of one or more seals.

The purpose of an interaction event is to enable interactions between a controller and validator that are not expressly establishment. Interaction events are signed with the current signing key.

A Delegating Interaction Event is an example of an interaction event where an AID delegates an establishment event (called a Delegated Establishment Event) of another AID, either inception or rotation.

Extended Rotation Event

An Extended Rotation Event is a special type of a rotation event that contains interaction event data. Hence, it anchors external data to the AID while also rotating its key state. In other words, it is a key event that combines a rotation event and an interaction event in the same key event message.

An extended rotation event provides enhanced security to normal (non-establishment) interaction events since the signing key is rotated immediately after it is used to sign the key event message.

Key Event Sequence

A Key Event Sequence is a uniquely ordered sequence of key event messages that are chained together via the digest of the immediately preceding key event message. A key event sequence consists of two key event subsequences, namely an establishment subsequence and a non-establishment subsequence.

Key Event Sequence. Sequence composed of interleaved establishment (inception, rotation) and non-establishment (interaction) events. (Reference: KERI Whitepaper.)

KEL (Key Event Log)

Formally, a Key Event Log (KEL) is an append-only verifiable data structure that represents a full key event sequence for an AID. It is an ordered chained record of the key event messages created by the controller of an AID. The key events are chained in such a way that each event message (besides the inception event) includes a cryptographic digest (hash)of the preceding event message. A KEL includes both establishment and non-establishment events, which are interleaved in the key event sequence.

A verifier may verify the authority of a controller over an AID or the authenticity of signed data by replaying the subsequence of establishment events in a valid KEL.

Note 1: 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.

Note 2: A KEL is considered a secondary root of trust in KERI. The primary root of trust is its AID and the entropy from which the AID is derived.

Key Event Receipt

A Key Event Receipt is a message whose body references a key event of an AID and includes one or more signatures on that key event.

For example, a key event receipt may be signed by witnesses to provide fault tolerance, security, and availability of key events. (More detail about the witnesses is given later.)

KERL (Key Event Receipt Log)

A Key Event Receipt Log (KERL) is a KEL that also includes all the consistent key event receipt messages created by witnesses. Each witness’ KERL for an AID is an append-only event log of first-seen verified consistent events. A witness only keeps consistent events and receipts of those consistent events.

A verifier may verify the authority of a controller over an AID by replaying the subsequence of establishment events in a valid KERL.

A KERL is also considered a secondary root of trust in KERI.

Duplicity

For a given AID, Duplicity refers to the existence of two or more versions of inconsistent instances of a KEL. Since every event in a KEL must be signed with non-repudiable signatures, any inconsistency between any two instances of the KEL is provable evidence of duplicity on the part of the signer(s), i.e. the controller of the AID.

Duplicity could be caused by a misbehaving/malicious controller or by an attacker that gains access to the controller’s private key(s). In the latter case, if only the current (signing) key(s) are compromised, the controller may recover their authority by rotating the compromised key(s).

Note: A shorter KEL—which does not differ in any of its events with respect to another but longer KEL—is not duplicitous but merely incomplete.

DEL (Duplicitous Event Log)

A Duplicitous Event Log (DEL) is a record of duplicitous events with respect to a given KERL. The duplicitous events are indexed to the corresponding event in a KERL.

Protocol Operational Modes

In the KERI protocol, there are two operational modes that define how key events can be conveyed between the controller of an AID and its validator. These modes are direct and indirect replay modes.

Here, we may make a reasonable assumption that the controller of an AID is honest as it is usually in the best interests of the controller to act in a trustworthy manner. This is because each key event must be non-repudiably signed by the controller, and any inconsistent alternate version of a key event may be eventually detectable by any validator once given access to both versions. Such “duplicity” may destroy the trustworthiness of the controller and their AID.

Direct Replay Mode

In the Direct Replay Mode, the controller and the validator exchange the KEL of the AID directly.

First, the validator must validate that the AID is really under the control of the controller. Since the AID is bound to one or more key pairs, the controller may establish control by sending the inception event message of the AID signed with the corresponding private keys. This inception event establishes the controller’s initial authority over the AID at issuance. This control authority can be subsequently maintained via successive rotation events. As long as the validator maintains a copy of the original event sequence—i.e., the key event log (KEL)—as first received, the validator will be able to detect any later exploit that attempts to change any of the events in that sequence, i.e., duplicity detection.

Upon reception of a key event, the validator sends a key event receipt message, which includes the validator’s signature, as an acknowledgment. The controller now has a signed receipt that attests that the validator received and verified the key event message. Hence, the validator also acts as a witness to this key event. The controller can keep the receipt in a key event receipt log (KERL). 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 could establish its own AID for use with the other in this pair-wise interaction. Each party would thereby in turn be the controller for its own AID and the validator and witness for the other’s AID. Each could maintain a KEL for the other’s AID and KERL from the other for its own AID. This allows each party to be invulnerable to subsequent exploitation with respect to this pairwise interaction.

A direct replay mode between Entity A and Entity B in a pairwise interaction.

Indirect Replay Mode

In the Indirect Replay Mode, the promulgation of key events to a validator may happen even when the controller of an AID is not online and therefore not able to communicate directly with the validator. The purpose of the indirect mode is to provide a highly available trustworthy service for an AID that thereby ensures that any validator may have access to a copy of the original version of the key event history.

The controller may designate a set of witnesses, called a witness pool, that essentially stores and forward key events to any requestor. This function of the witnesses is called a key event promulgation service. The witnesses also sign the key events to create receipts and keep them in their KERLs.

Note 1: A witness may also send its receipt to other witnesses. This might be with a broadcast or gossip protocol or not at all.

Note 2: It is possible that witnesses may receive inconsistent key events. In general, the witnessing policy of the witnesses is that the first seen version of an event always wins, that is, the first verified version is witnessed (signed, stored, acknowledged, and maybe disseminated) and all other versions are discarded. The exception to this general rule is that an establishment event may recover following a set of exploited non-establishment events. The recovery process may fork off a branch from the recovered trunk.

An example of the indirect replay mode with a set of witnesses that are designated by the controller is shown below.

An indirect replay mode via witnesses.

Since the witnesses are designated by the controller, they may not be trusted by a validator. Hence, the validator may designate its own set of Watchers that may provide high availability and security from the validator’s perspective. This watcher service may be called a Key Event Confirmation Service. A simple example where both services are used is shown below:

An indirect replay mode via witnesses and watchers.

The validator’s confirmation service may be further enhanced to provide duplicity detection and other protections as needed. Additional roles for the key event confirmation service include a Judge and Juror(s).

• the Juror(s) performs duplicity detection on key events and key event receipts as well as keeps a duplicitous event log (DEL) for the AID.
• the Judge examines KERLs and DELs from witnesses, watchers, and jurors to determine if the controller is trustworthy.

An indirect replay mode via witnesses, watchers, jurors and judge.

Related Entities

The KERI protocol defines a number of entities that are involved in the management and usage of an AID, some of which have already been mentioned briefly.

Here, an “Entity” could be a person, organization, autonomous software, or thing, such as an IoT device.

Controller

A Controller of an AID is a controlling entity that can cryptographically prove the control authority (signing and rotation) over the AID, as well as make changes on the associated KEL. In the case where a multi-signature scheme is used, the controller consists of multiple controlling entities.

Normally, the controller holds both signing and rotation authorities over the AID. However, the controller may grant its authority to third parties. An example is custodial rotation where the controller grants its signing authority to a custodial agent.

Verifier

A Verifier of an AID is an entity that cryptographically verifies the signature(s) on an event message related to the AID.

Validator

A Validator of an AID is an entity that determines that a given signed statement associated with the AID was valid at the time of its issuance.

Note that a validator must first act as a verifier in order to determine the authoritative key set for verifying/validating the signed statement from the KEL of the AID.

Witness

A Witness of an AID is an entity that is designated (trusted) by the controller of the AID. The primary role of a witness is to verify, sign, and keep the key events associated with the AID. Designation of witnesses is included in key establishment events. As a result, the role of a witness may be verified using the KEL and KERL of the AID. When designated, a Witness becomes part of the supporting infrastructure for maintaining and verifying the AID.

Note 1: As a special case, the controller may serve as its own witness.

Note 2: Witnesses are used in a group, called a witness pool. The pool forms a threshold structure that provides protection from the exploitation of a minority of the key- pairs of the ephemeral Witness AIDs in the pool.

Note 3: the initial set of designated witnesses is specified in the inception event and then may be changed by a rotation event.

Watcher

The Watcher of an AID is an entity that keeps a copy of a KERL. A set of watchers may be used as a supporting infrastructure for a validator. Unlike witnesses, watchers are not designated by the controller.

Juror

The Juror of an AID is an entity that performs duplicity detection on key events and key event receipts. Once duplicity is detected, the Juror creates a digital signature on the duplicitous key events.

Each juror keeps a duplicitous event log (DEL) for each controller and all designated witnesses with respect to a KERL. Any validator may confirm duplicity by examining a DEL.

Judge

The Judge of an AID is an entity that examines the entries of one or more KERLs and DELs to validate that the event history of the AID is from a non-duplicitous controller and has been witnessed by a sufficient number of non-duplicitous witnesses such that it may be trusted or conversely not-trusted by a validator.

Resolver

The Resolver of an AID is an entity that provides discovery for the AID.

KA2CE (KERI’S Agreement Algorithm for Control Establishment)

The key event promulgation service for an AID is provided by a set of witnesses (witness pool) that employs a type of Byzantine Fault Tolerant (BFT) algorithm, called KERI’s Agreement Algorithm for Control Establishment (KA2CE). KA2CE provides a service for the key event history of the AID via a KERL (Key Event Receipt Log). The controller must designate a threshold number where a subset of witnesses may at any time be faulty. The objective of the service is to provide a verifiable KERL to any validator on demand.

In this algorithm, an agreement consists of a specific version of a key event with verifiable receipts (signatures) from the controller and the designated witnesses. An agreement means that each witness in that set has witnessed the same version of that event and each witness’ receipt in that set has been promulgated to every other witness in that set.

The purpose of using multiple designated witnesses in KERI is to ensure both the availability and the security of the service in the event of faulty witnesses. In addition to faults such as unresponsiveness and network interruptions, allowed faults include what are commonly known as Byzantine faults such as dishonest/malicious witnesses.

Cooperative Delegation

A controller of an AID may authorize some degree of control authority to another AID. This process is known as delegation.

A delegation operation involves a pair of events by the delegating and delegated AIDs. Such operation is cooperative in KERI as it requires a cryptographic commitment from both the delegator and the delegate, as follows.

• The delegating event contains an “event seal” that includes a digest of the delegated event
• The delegated event contains a “location seal” that includes the unique location of the delegating event.

The pair of seals cross-reference the two events participating in the cooperative delegation operation. The delegating AID performs an establishment operation (inception or rotation) on a delegated identifier, as illustrated below.

Cooperative delegation. (Reference: KERI Whitepaper.)