Untitled-2.6.3

Updated with revised KSN key state notice message based on issue decentralized-identity#130

kids/kid0003.md

@@ -57,7 +57,8 @@ In the following specifications the element sets are expressed in JSON format. B
 |i| Identifier Prefix|  |
 |s| Sequence Number|  |
 |t| Message Type| |
-|d| Event Digest (Seal or Receipt) ||
+|te| Last received Event Message Type in Key State Notice | |
+|d| Event Digest (Seal or Receipt or Key State Notice) ||
 |p| Prior Event Digest | |
 |kt| Keys Signing Threshold ||
 |k| List of Signing Keys (ordered key set)| |
@@ -71,7 +72,6 @@ In the following specifications the element sets are expressed in JSON format. B
 |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")  | exact scheme tbd |
 
@@ -290,88 +290,78 @@ Last  Establishment Event Reference in KeyState has 2 elements
 }
 ```
 
-## Key State Notificaion Messages
+## Key State Notice Messages
 
 While the actual Key State only needs the version number, that message itself needs the full version string so that it can be parsed when sent over the wire using low level TCP etc to support all the serializations.  A different version of the message could be used with a higher level transport such as JSON only ReST. In that case then the "v" could be replaced with "vn" = "1.0" for example.
 
-The message type is `ksn` for Key State Notification message.
+The message type is `ksn` for Key State Notice message.
 Delegated key state notification messages have a non-empty `di` field for the delegator's fully qualified identifier prefix.
 
-The `e` block or map means last received event in key state.
 The `ee` block or map means last received establishment event in key state. It includes the witness remove, `wr`, and witness add, `wa` lists from that establishment event. This is to enable promulgation and confirmation that any rotated out witnesses also witness the event that rotates them out from being a witness.
 
 Each key state notification message is signed by the entity providing the key state. The entity providing the key state may not necessarily be the controlling entity of the associate KEL for that key state. Essentially the signature on a key state notification message acts as
-and endorsement of that key state message by the provider. It is signifying that the endorsing provider has verified a given KEL and the result of its verification is the provided key state. Because the key state message is thusly signed any duplicity on the part of the endorsing provider (signer) now becomes detectable and provable. As a result duplicitous endorsers (signers) may therefore not be trusted by any validator that detects such duplicity.
+an endorsement of that key state message by the provider. It is signifying that the endorsing provider has verified a given KEL and the result of its verification is the provided key state. Because the key state message is thusly signed any duplicity on the part of the endorsing provider (signer) now becomes detectable and provable. As a result duplicitous endorsers (signers) may therefore not be trusted by any validator that detects such duplicity.
 
 When the endorser has a nontransferable identifier then the attached signatures consist of a receipt couple count code plus one or more receipt couples. A receipt couple consists of a fully qualified non-transferable identifier followed by a fully qualified non-indexed signature. The full attachment may also include prelude pipeline count codes. Multiple receipt couples may occur if a given key state came from a cluster of watchers/or witnesses where each mutually consistent individual key state messages from were merged into one message with all their receipts attached in a group.
 
-When the endorser has a transferable identifier then the key state message includes an event seal to the establishment event in the signers KEL that was the authoritative establishment event used at the time of its endorsement. The key list of this establishment event provides the set of public keys for the attached indexed signatures. The index corresponds to the offset of the public key in the key list.
-An event seal is included in the `a` fieldof the key state message to indicate the event in the endorsers KEL from which its key list may be obtained. The event seal includes the identifier of the endorser, the sequence number of the authoritative event in the endorser's KEL, and the digest of the authoritative event in the endorser's KEL. The attachments include an indexed signature group counter and one or more indexed signatures each corresponding a public key in the associated key list. The attachments may also include prelude pipeline count codes.
+When the endorser has a transferable identifier then the attached signatures consist of a transferable indexed signature group count code plus one or more complex indexed signature groups. The full attachments may also include prelude pipeline count codes. Each transferable indexed signature group consists of a triple of pre+snu+dig corresponding to the (i, s, d) of the establishment event from the endorser that was authoritative at the time of the endorsement. The key list of this establishment event provides the set of public keys for the attached indexed signatures. This triple is followed by a controller indexed signature count code and one or more indexed signatures corresponding to the keys from the establishment event of the preceding triple.  The index in each signature corresponds to the offset of the public key in the key list. 
 
 
-### Non-transferable Prefix Signer Key State Message
+### Key State Notice (Non-Delegated)
 
 
 
 ```json
 {
   "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"],
-  "e":
-    {
-      "s": "2",
-      "t": "rot",
-      "d": "EAoTNZH3ULvaU6JR2nmwyYAfSVPzhzZ-i0d8JZS6b5CM",
-    },
   "ee":
     {
-      "s": "1",
-      "d": "EAoTNZH3ULvaU6JR2nmwyYAfSVPzhzZ-i0d8JZS6b5CM",
+      "s":  "1",
+      "d":  "EAoTNZH3ULvaU6JR2nmwyYAfSVPzhzZ-i0d8JZS6b5CM",
       "wr": ["Dd8JZAoTNZH3ULvaU6JR2nmwyYAfSVPzhzS6b5CMZ-i0"],
       "wa": ["DnmwyYAfSVPzhzS6b5CMZ-i0d8JZAoTNZH3ULvaU6JR2"]
     },
-  "di": "",
-  "a": {}
+  "di": "EJZAoTNZH3ULvYAfSVPzhzS6b5CMaU6JR2nmwyZ-i0d8"
 }
 
 ```
 
-### Delegated Non-transferable Prefix Signer Key State Message
+### Key State Notice
 
 
 ```json
 {
   "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"],
-  "e":
-    {
-      "s": "2",
-      "t": "rot",
-      "d": "EAoTNZH3ULvaU6JR2nmwyYAfSVPzhzZ-i0d8JZS6b5CM",
-    },
   "ee":
     {
-      "s": "1",
-      "d": "EAoTNZH3ULvaU6JR2nmwyYAfSVPzhzZ-i0d8JZS6b5CM",
+      "s":  "1",
+      "d":  "EAoTNZH3ULvaU6JR2nmwyYAfSVPzhzZ-i0d8JZS6b5CM",
       "wr": ["Dd8JZAoTNZH3ULvaU6JR2nmwyYAfSVPzhzS6b5CMZ-i0"],
       "wa": ["DnmwyYAfSVPzhzS6b5CMZ-i0d8JZAoTNZH3ULvaU6JR2"]
     },
   "di": "EJZAoTNZH3ULvYAfSVPzhzS6b5CMaU6JR2nmwyZ-i0d8"
-  "a": {}
 }
 
 ```
@@ -460,7 +450,7 @@ An event seal is included in the `a` fieldof the key state message to indicate t
 
 The "c" element in inception and delegated inception events is a list strings specifying optional configuration data/traits/modes/options  . The presence of a string in this list indicates a configuration option for the Key Events. The string values are provided in the following table. The order in which the string values appear in the trait list is normative. They must appear when present in the order in the following table. To clarify, when present `EO` must be first. When both `EO` and `DND` are present then `EO` must precede `DND`. If `EO` is not present then `DND`
 may be first in the list. Subsequent additions to the following table must follow that same precedence ordering rule. The reason for the rule is
-to ensure consistency (reproducibility) in the key state notification 
+to ensure consistency (reproducability) in the key state notification message.
 
 |Option|Description|Notes|
 |---|---|---|