KID0009 - Indirect Mode & Witnesses

Navigation

Back to table of contents |Link|Commentary|Section |—|—|—| |0000|X|Glossary, overview, how to use| |0001|X|Prefixes, Derivation and derivation reference tables| |0002|X|Data model (field & event concepts and semantics)| |0003|X|Serialization| |0004|X|Key Configuration (Signing threshold & key set)| |0005|X|Next Key Commitment (Pre-Rotation)| |0006|X|Seals| |0007|X|Delegation (pending PR by Sam)| |0008|X|Key-Event State Machine| |0009|X|Indirect Mode & Witnesses| |0010||Recovery/consensus Algorithm (KAACE)| |0011||Database & Storage Considerations| |0097|n/a|Non-Normative Implementation Guidance| |0098|n/a|Use Cases| |0099|n/a|Test Vectors and Normative Statement Index|

Introduction

With indirect mode, the promulgation of events to a validator may happen even when the controller is not attached to the network and therefore not able to communicate directly with a validator. Indirect mode supports high (nearly continuous) availability of the key event history to any validator. This means that other components must be trusted to promulgate key events when the controller is not attached to the network.

Indirect mode is compatible with identifiers for one-to-many exchanges or any-wise relationships (a controller with any others). A single indirect mode identifier may be used for a public service or business or otherwise when that identifier is intended to be linked to a public brand and/or a reputation system. An indirect mode identifier may also be used for private one-to-one or select groups but not where intermittent availability is not tolerable. The assumption of high availability complicates the set of trusted support infrastructure needed to secure the identifier.

With indirect replay mode a validator may not be available either at the time of creation to receive and acknowledge an inception event or at some later time to receive and acknowledge any other key event. Consequently a later exploit of the associated key-pairs might allow an exploiter to establish an alternate key event history and provide that instead to a validator thereby preempting the original unexploited key event history. The exploiter could thereby more easily capture control of the identifier from the perspective of such a validator. The purpose of indirect mode is to provide a highly available trustworthy service for an identifier that thereby ensures that any validator may have access to a copy of the original version of the key event history.

Indirect Replay Overview

With indirect mode, the controller may designate a set of witnesses (replicas) that essentially store and forward key events to any requestor. This function of the witnesses may be called a “key event promulgation service”. It may provide fault tolerant, security, and availability of key events from the standpoint of the controller. A simplified diagram of such a service is shown as follows:

The set of witnesses, as a key event promulgation service, may provide some guarantees of fault-tolerant availability and security from the controller’s perspective. However, they may not be trusted by a validator because they are designated by the controller. The fact that events are end-verifiable means that the validator is free to 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 simplified diagram with both services is shown as follows

Although KERI may utilize simple witnesses, its portable designation support means that when appropriate or desirable more sophisticated witnesses may be used such as witnesses that are oracles to a distributed consensus ledger (i.e. a blockchain). In this case, the pool of nodes supporting the ledger may appear as one witness from the perspective of KERI. But that one witness may exhibit sufficiently high security and availability for the purposes of both the controller and validator. The controller may choose at any time to move to a different ledger or set of witnesses as desired. This means that the identifier is not ledger-locked. An example with a ledger oracle as a witness and a ledger oracle as a watcher is shown in the diagram below.

Indirect Replay Modes: A to Any

In more detail, the controller’s promulgation service can be defined as a finite set of N designated witnesses. Although the witnesses are explicitly designated by the controller, they may or may not be under the control of the controller. The designation is a cryptographic commitment to the witnesses via a verifiable statement included in an establishment event. The purpose of such a witness set is to better protect the service from faults, including Byzantine faults [36]. Thus the service employs a type of Byzantine Fault Tolerant (BFT) algorithm. We call this KERI’s Agreement Algorithm for Control Establishment (KA2CE), and explain it in the next section. {add link to next KID}.

Implementation Guidance: Designing Witness Lists

The primary purpose of the KA2CE algorithm is to protect the controller’s ability to promulgate the authoritative copy of its key event history despite potential external attacks. This includes maintaining a sufficient degree of availability such that any validator may obtain an authoritative copy on demand.

The reliance on a designated set of witnesses provides several advantages.

1. The identifier’s trust basis is not locked to any given witness or set of witnesses but may be transferred at the controller’s choosing. This provides portability.
2. The number and composition of witnesses is also at the controller’s choosing. The controller may change this in order to make trade-offs between performance, scalability, and security. This provides flexibility and adaptability.
3. The witnesses need not provide much more than verification and logging. This means that even highly cost- or performance-constrained applications may design witness lists accordingly.

Likewise, given any guarantees of accountability the controller may declare, a validator may provide itself with any degree of protection it deems necessary by designating a set of observers (watchers, jurors, and judges). Specifically, a validator may be protected by maintaining a copy of the key event history as first seen (received) by the validator or any other component trusted by the validator (watcher, juror, judge). This copy may be used to detect any alternate inconsistent (duplicitous) copies of the key event history. (See commentary)

A controller may designate its witness set in such a way as to provide any arbitrary degree of protection from external exploit. Nonetheless in the event of such an exploit a validator may choose either to hold that controller accountable as duplicitous and therefore stop trusting the identifier or to treat the validator’s copy of the key event history as authoritative (ignoring the exploited copy) and therefore continue trusting the identifier. This dependence on the validator’s choice in the event of detected duplicity both imperils any potential malicious controller and protects the validator. The details of KA2CE will be discussed in more detail in the next section.