Events

A Key Event is an atomic transaction over the Key State of an Identifier. While all events have some semantic meaning within KERI, only a subset will change the keys in a Key State (rotation and delegated rotation).

Key Event Log

The Key Event Log is a type of hash-chained data structure from which the Key State of an Identifier can be derived. It can always be used to recreate the state at any point ("event-sourcing").

Key Event Receipt Log

The Key Event Receipt Logs are built from receipts of events signed by the witnesses of those events (these are called commitments); these are also append-only but not hash-chained.

Key State

Key State represents the current values for the keys, witnesses and thresholds for a given identifier, signed by a provider. The signature from the provider signifies that the provider has verified the KEL for the identifier and the result of that verification is the key state. The key state is represented in a Key State Notification Message detailed fully in Event Serialization Key State Messages. The following fields are defined for a Key State Notification Message:

• v: Version String
• i: Identifier Prefix
• s: Sequence Number
• t: Message Type
• d: Event Digest (Seal or Receipt)
• p: Prior Event Digest
• kt: Keys Signing Threshold
• k: List of Signing Keys (ordered key set)
• n: Next Key Set Commitment
• wt: Witnessing Threshold
• w: List of Witnesses (ordered witness set)
• wr: List of Witnesses to Remove (ordered witness set)
• wa: List of Witnesses to Add (ordered witness set)
• c: List of Configuration Traits/Modes
• a: List of Anchors (seals)
• da: Delegator Anchor Seal in Delegated Event (Location Seal)
• di: Delegator Identifier Prefix in Key State
• rd: Merkle Tree Root Digest
• e: Last received Event Map in Key State
• ee: Last Establishment Event Map in Key State
• vn: Version Number ("major.minor")

Key state notification messages differ depending on whether the signer is using a delegated identifier. The follow examples detail the fields needed for each permutation.

            {
              "v": "KERI10JSON00011c_",
              "i": "EaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM",
              "s": "2",
              "t": "ksn",
              "d": "EAoTNZH3ULvaU6JR2nmwyYAfSVPzhzZ-i0d8JZS6b5CM",
              "te": "rot",
              "kt": "1",
              "k": ["DaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM"],
              "n": "EZ-i0d8JZAoTNZH3ULvaU6JR2nmwyYAfSVPzhzS6b5CM",
              "wt": "1",
              "w": ["DnmwyYAfSVPzhzS6b5CMZ-i0d8JZAoTNZH3ULvaU6JR2"],
              "c": ["eo"],
              "ee":
                {
                  "s":  "1",
                  "d":  "EAoTNZH3ULvaU6JR2nmwyYAfSVPzhzZ-i0d8JZS6b5CM",
                  "wr": ["Dd8JZAoTNZH3ULvaU6JR2nmwyYAfSVPzhzS6b5CMZ-i0"],
                  "wa": ["DnmwyYAfSVPzhzS6b5CMZ-i0d8JZAoTNZH3ULvaU6JR2"]
                },
              "di": "EJZAoTNZH3ULvYAfSVPzhzS6b5CMaU6JR2nmwyZ-i0d8"
            }
        

            {
              "v": "KERI10JSON00011c_",
              "i": "EaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM",
              "s": "2",
              "t": "ksn",
              "d": "EAoTNZH3ULvaU6JR2nmwyYAfSVPzhzZ-i0d8JZS6b5CM",
              "te": "rot",
              "kt": "1",
              "k": ["DaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM"],
              "n": "EZ-i0d8JZAoTNZH3ULvaU6JR2nmwyYAfSVPzhzS6b5CM",
              "wt": "1",
              "w": ["DnmwyYAfSVPzhzS6b5CMZ-i0d8JZAoTNZH3ULvaU6JR2"],
              "c": ["eo"],
              "ee":
                {
                  "s":  "1",
                  "d":  "EAoTNZH3ULvaU6JR2nmwyYAfSVPzhzZ-i0d8JZS6b5CM",
                  "wr": ["Dd8JZAoTNZH3ULvaU6JR2nmwyYAfSVPzhzS6b5CMZ-i0"],
                  "wa": ["DnmwyYAfSVPzhzS6b5CMZ-i0d8JZAoTNZH3ULvaU6JR2"]
                },
              "di": "EJZAoTNZH3ULvYAfSVPzhzS6b5CMaU6JR2nmwyZ-i0d8"
            }
        

Resolver Metadata

did:keri defines keyState DID Document Metadata (see DID Document Metadata in [[?DID-RESOLUTION]]).

• keyState is the verified state of the KEL for the identifier represented by this DID Doc (See ).

        {
            "didDocument": DID_DOCUMENT_OBJECT,
            "didDocumentMetadata": {
                "keyState":  {
                  "v": "KERI10JSON00011c_",
                  "i": "EaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM",
                  "t": "ksn",
                  "kt": "1",
                  "k": ["DaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM"],
                  "n": "EZ-i0d8JZAoTNZH3ULvaU6JR2nmwyYAfSVPzhzS6b5CM",
                  "wt": "1",
                  "w": ["DnmwyYAfSVPzhzS6b5CMZ-i0d8JZAoTNZH3ULvaU6JR2"],
                  "c": ["eo"],
                  "e":
                    {
                      "s": "2",
                      "t": "rot",
                      "d": "EAoTNZH3ULvaU6JR2nmwyYAfSVPzhzZ-i0d8JZS6b5CM",
                    },
                  "ee":
                    {
                      "s": "1",
                      "d": "EAoTNZH3ULvaU6JR2nmwyYAfSVPzhzZ-i0d8JZS6b5CM",
                      "wr": ["Dd8JZAoTNZH3ULvaU6JR2nmwyYAfSVPzhzS6b5CMZ-i0"],
                      "wa": ["DnmwyYAfSVPzhzS6b5CMZ-i0d8JZAoTNZH3ULvaU6JR2"]
                    },
                  "di": "",
                  "a": {}
                }
            }
        }
        

Create

Creation of a did:keri DID is accomplished by creating, signing and publishing an Inception event. If witnesses are listed in the inception event, the receipts are also required for DID creation to be complete.

Detailed steps for prefix derivation are in [[KID0001]] and witness configuration in [[KID0009]]. Inception events are covered in [[KID0003]].

Read

Steps to resolve a `did:keri:$PREFIX` DID:

1. Find the Key Event Log for the prefix `$PREFIX`. The method for discovering the Key Event Log is outside the scope of this specification. Possible implementations include the use of a Distributed Hash Table (DHT), anchoring a KEL in a ledger or the use of a gossip protocol involving a witness network.
2. Process the KEL into a Key State, according to the state validation rules/semantics of KERI as defined in [[KID0008]]
3. Create a DID Document with the DID `did:keri:$PREF`
4. For each key K in the Key State, add a Verification Method to the DID Doc containing K and the appropriate type, with the ID of K being K's prefix form (alternatively, the ID could be an integer of K's index in the current signer list)
5. Add the Key State as DID Document Metadata as defined in

Establishment of control authority can be done independently of DID document contents, as long as the Key State is provided in the DID Document Metadata. See .

Update

Updating a did:keri DID is accomplished by publishing establishment events to the KEL for performing operations such as key rotation and updating signature thresholds, witnesses and delegates.

A detailed description of event types, their semantics and uses can be found in [[KID0003]].

Deactivate

Deactivation of a did:keri DID consists of rotation to 0 controlling keys, which terminates the ability to recover the identifier and indicates that the identifier has been abandoned. Identifiers which are delegated to by an abandoned Identifier are also considered abandoned (delegating Ixn events can no longer be created).

Detailed steps are specified in [[KID0003]].