KID0008 - Key-Event State Machine

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|

Editorial Notes

• Jan 5 - KID should include:
  • Replay Logic
  • Asynchronous operation
  • Escrow (normative) - (Sam after implementing in Py)
  • Implementation choices re: Escrow (Non-normative)

(^ Also appears in commentary to this section)

Replay logic (from whitepaper)

Replay logic:

In this protocol, all the primary activities that protect a validator when engaging with some other controller’s identifier, be it verification, control authority establishment, or duplicity detection, are based on an ability to replay the sequence of key events (key event history or log) of that identifier. There are two main operational modes for providing this replay capability that are distinguished by the degree of availability of the identifier’s controller when creating and promulgating the key events: direct replay mode and indirect mode (covered in the next section)

In direct mode, the promulgation of events to a validator does not happen unless the controller is attached to the network and able to communicate directly with a validator. Direct mode assumes that the controller may have intermittent network availability. This does not preclude the use of network buffers, caches, and other such mechanisms that mitigate temporary communications connectivity issues, but it does assume that these mechanism may not be trusted in any persistent sense to promulgate key events. Nonetheless, direct mode is important as it is compatible with the use of mobile internet devices such as cell-phones. The assumption of intermittent availability means that in order for a validator to access the key event history of an identifier (not its own) that validator must directly receive those events from the identifier’s controller. Direct mode is compatible with identifiers for one-to-one exchanges or pair-wise relationships (one identifier per relationship). A single direct mode identifier may be re-used in multiple oneto-one relationships as part of a select group. The assumption of direct communication with intermittent availability simplifies the set of trusted support infrastructure needed to secure the identifier.