CESR 2.00 Code Tables

[SmithSamuelM]

CESR 2.00 Code Tables

More correctly maybe CESR 2.0.0 if adhere to strict semantic versioning

Universal Selector Codes and Encoding Schemes

Encoding Scheme Table

The following table summarizes the T domain coding schemes by selector code for the 13 code tables defined above.

Universal Selector	Selector	Type Chars	Value Size Chars	Code Size	Lead Bytes	Pad Size	Format
[A-Z,a-z]		1*	0	1	0	1	$&&&
0		1	0	2	0	2	*$&&
1		3	0	4	0	0	*$$$&&&&
2		3	0	4	1	1	*$$$%&&&
3		3	0	4	2	2	*$$$%%&&
4		1	2	4	0	0	*$##&&&&
5		1	2	4	1	1	*$##%&&&
6		1	2	4	2	2	*$##%%&&
7		3	4	8	0	0	*$$$####&&&&
8		3	4	8	1	1	*$$$####%&&&
9		3	4	8	2	2	*$$$####%%&&
-	[A-Z,a-z]	1*	0	4	0	0	*$##
-	0	1	0	8	0	0	**$#####
-	-	1	0	8	0	0	**$$$###
-	[1-9,_]	TBD	TBD	TBD	TBD	TBD	**
_		TBD	TBD	TBD	TBD	TBD	*

Encoding Scheme Symbols

The following table defines the meaning of the symbols used in the encoding scheme table

Symbol	Description
*	selector-code character also provides the type
$	type-code character from subset of Base64 [A-Z,a-z,0-9,-,_]
%	lead byte where pre-converted binary includes the number of lead bytes shown
#	Base64 digit as part of a base 64 integer. When part of primitive determines the number of following quadlets or triplets. When part of a count code determines the count of the following primitives or groups of primitives
&	Base64 value characters that represent the converted raw binary value. The actual number of characters is determined by the prepended text code. Shown is the minimum number of value characters.
TBD	to be determined, reserved for future

Universal Code table genus/version codes

Code	Description	Code Length	Count Length	Total Length
	Genus Version Codes
--AAA###	KERI/ACDC stack code table at genus AAA	8	5	8

Master code table for genus/version --AAACAA (KERI/ACDC protocol stack version 2.00)

This master table includes both the primitive and count code types for the KERI/ACDC protocol stack. The types are separated by headers. This table only provides the codes for the KERI/ACDC protocol stack code table genus AAA at version 2.00 given by the genus/version code = --AAACAA KERI/ACDC 2.00. After some thought and discussion, there does not seem to be a valid use case for a full semantic versioning using major, minor, and patch version numbers. In general, patch is meant for minor changes such as bug fixes, changes to doc strings, or tests that do not affect core feature functionality. Whereas, minor is meant for feature changes that are backwards compatible, and major is meant for backwards breaking changes. Any addition of a new code to the code table is backward breaking in a least one direction so its a feature change in a least one direction. New implementations with the new codes can accept streams from old implementations, but old implementations will break if they receive the new codes. So we have to define what major and minor mean specifically with regard code changes. A major change means a code's meaning has changed. This means it breaks in both directions i.e. sender and receiver. A minor change happens when a code is added; this only breaks backward compatibility when a new sender sends to an an old receiver, but a new sender will still correctly process a stream sent from an old receiver. Since code additions will be common compared to code changes, it would be beneficial to have more room for minor vs. major. Given there are three Base64 characters for the version, the first character will be for major version of which there are 64 total. It is anticipated that the code tables for the KERI/ACDC/TSP protocol stack will not change much in the future after the 1.00 to 2.00 change proposed here. This leaves 2 Base64 characters for minor version or 64^2 = 4096 minor versions per major version. Largely these will be infrequent and batched. Each time a new batch of codes are added to the table with accompanying implementation, the minor version will be incremented. Hopefully, there is never a version 3.00 because 2.00 was designed properly.

All count codes except the genus/version code are pipelineable because they count the number of quadlets/triplets in the count group. A quadlet is four Base64 characters in the text domain. A triplet is three B2 bytes in the binary domain. The count is invariant in either domain. This allows a stream parser to extract the count number of characters/bytes in a group from the stream without parsing the contents of the group. By making all count codes pipelineable, the stream parser can be optimized in a granular way. This includes granular core affinity.

The table has 5 columns. These are as follows:

1. The Base64 stable (hard) text code itself.
2. A description of what is encoded or appended to the code.
3. The length in characters of the code.
4. the length in characters of the count portion of the code
5. The length in characters of the fully qualified primitive, including code and its appended material or the number of elements in the group. This is empty when variable length.

Code	Description	Code Length	Count Length	Total Length
	Counter Codes
	Universal Genus Version Codes
--AAABAA	KERI/ACDC protocol stack code table at genus AAA and version 1.00	8	5	8
--AAACAA	KERI/ACDC protocol stack code table at genus AAA and version 2.00	8	5	8
	Universal counter codes that allow genus/version override
-A##	Generic pipeline group up to 4,095 quadlets/triplets	4	2	4
-0A#####	Generic pipeline group up to 1,073,741,823 quadlets/triplets	8	5	8
-B##	Message + attachments group up to 4,095 quadlets/triplets	4	2	4
-0A#####	Message + attachments group up to 1,073,741,823 quadlets/triplets	8	5	8
-C##	Attachments only group up to 4,095 quadlets/triplets	4	2	4
-0C#####	Attachments only group up to 1,073,741,823 quadlets/triplets	8	5	8
	Universal counter codes that do not allow genus/version override
-D##	Datagram Stream Segment up to 4,095 quadlets/triplets	4	2	4
-0D#####	Datagram Stream Segment up to 1,073,741,823 quadlets/triplets	8	5	8
-E##	ESSR (TSP) wrapper signable up to 4,095 quadlets/triplets	4	2	4
-0E#####	ESSR (TSP) wrapper signable up to 1,073,741,823 quadlets/triplets	8	5	8
-F##	CESR native message top-level fixed field signable up to 4,095 quadlets/triplets	4	2	4
-0F#####	CESR native message top-level fixed field signable up to 1,073,741,823 quadlets/triplets	8	5	8
-G##	CESR native message top-level field map signable up to 4,095 quadlets/triplets	4	2	4
-0G#####	CESR native message top-level field map signable up to 1,073,741,823 quadlets/triplets	8	5	8
-H##	Generic field map mixed types up to 4,095 quadlets/triplets	4	2	4
-0H#####	Generic field map mixed types up to 1,073,741,823 quadlets/triplets	8	5	8
-I##	Generic list mixed types up to 4,095 quadlets/triplets	4	2	4
-0I#####	Generic list mixed types up to 1,073,741,823 quadlets/triplets	8	5	8
	Genus Specific Counter Codes
-J##	Indexed controller signature group up to 4,095 quadlets/triplets	4	2	4
-0J#####	Indexed controller signature group up to 1,073,741,823 quadlets/triplets	8	5	8
-K##	Indexed witness signature group up to 4,095 quadlets/triplets	4	2	4
-0K#####	Indexed witness signature group up to 1,073,741,823 quadlets/triplets	8	5	8
-L##	Nontransferable identifier receipt couples pre+sig up to 4,095 quadlets/triplets	4	2	4
-0L#####	Nontransferable identifier receipt couples pre+sig up to 1,073,741,823 quadlets/triplets	8	5	8
-M##	Transferable identifier receipt quadruples pre+snu+dig+sig up to 4,095 quadlets/triplets	4	2	4
-0M#####	Transferable identifier receipt quadruples pre+snu+dig+sig up to 1,073,741,823 quadlets/triplets	8	5	8
-N##	First seen replay couples fnu+dt up to 4,095 quadlets/triplets	4	2	4
-0N#####	First seen replay couples fnu+dt up to 1,073,741,823 quadlets/triplets	8	5	8
-O##	Transferable indexed sig group pre+snu+dig+idx-controller-sig-groups up to 4,095 quadlets/triplets	4	2	4
-0O#####	Transferable indexed sig group pre+snu+dig+idx-controller-sig-groups up to 1,073,741,823 quadlets/triplets	8	5	8
-P##	Transferable last indexed sig group pre+idx-controller-sig-groups up to 4,095 quadlets/triplets	4	2	4
-0P#####	Transferable last indexed sig group pre+idx-controller-sig-groups up to 1,073,741,823 quadlets/triplets	8	5	8
-Q##	Issuer/Delegator/Transaction event seal source couple snu+dig up to 4,095 quadlets/triplets	4	2	4
-0Q#####	Issuer/Delegator/Transaction event seal source couple snu+dig up to 1,073,741,823 quadlets/triplets	8	5	8
-R##	Anchoring event seal source triple pre+snu+dig up to 4,095 quadlets/triplets	4	2	4
-0R#####	Anchoring event seal source triple pre+snu+dig up to 1,073,741,823 quadlets/triplets	8	5	8
-S##	Pathed material group path+mixed-types up to 4,095 quadlets/triplets	4	2	4
-0S#####	Pathed material group path+mixed-types up to 1,073,741,823 quadlets/triplets	8	5	8
-T##	SAD path signature group path+idx-controller-sig-groups up to 4,095 quadlets/triplets	4	2	4
-0T#####	SAD path signature group path+idx-controller-sig-groups up to 1,073,741,823 quadlets/triplets	8	5	8
-U##	SAD root path signature group rootpath+path-sig-groups up to 4,095 quadlets/triplets	4	2	4
-0U#####	SAD root path signature group rootpath+path-sig-groups up to 1,073,741,823 quadlets/triplets	8	5	8
-V##	Digest seal singles dig up to 4,095 quadlets/triplets	4	2	4
-0V#####	Digest seal singles dig up to 1,073,741,823 quadlets/triplets	8	5	8
-W##	Merkle Tree Root seal singles rdig up to 4,095 quadlets/triplets	4	2	4
-0W#####	Merkle Tree Root seal singles rdig up to 1,073,741,823 quadlets/triplets	8	5	8
-X##	Backer registrar identifier seal couples brid+dig up to 4,095 quadlets/triplets	4	2	4
-0X#####	Backer registrar identifier seal couples brid+dig up to 1,073,741,823 quadlets/triplets	8	5	8
-Y##	Last event seal source singles aid+dig up to 4,095 quadlets/triplets	4	2	4
-0Y#####	Last event seal source singles aid+dig up to 1,073,741,823 quadlets/triplets	8	5	8
-Z##	ESSR (TSP) Payload version+messagtype+... up to 4,095 quadlets/triplets	4	2	4
-0Z#####	ESSR (TSP) Payload version+messagtype+... up to 1,073,741,823 quadlets/triplets	8	5	8
	Operation Codes
_	Reserved TBD
	Primitive Matter Codes
	Basic One Character Codes
A	Seed of Ed25519 private key	1		44
B	Ed25519 non-transferable prefix public verification key	1		44
C	X25519 public encryption key, may be converted from Ed25519 public key	1		44
D	Ed25519 public verification key	1		44
E	Blake3-256 Digest	1		44
F	Blake2b-256 Digest	1		44
G	Blake2s-256 Digest	1		44
H	SHA3-256 Digest	1		44
I	SHA2-256 Digest	1		44
J	Seed of ECDSA secp256k1 private key	1		44
K	Seed of Ed448 private key	1		76
L	X448 public encryption key	1		76
M	Short number 2 byte b2	1		4
N	Big number 8 byte b2	1		12
O	X25519 private decryption key/seed may be converted from Ed25519 key/seed	1		44
P	X25519 124 char qb64 Cipher of 44 char qb64 Seed	1		124
Q	ECDSA secp256r1 256 bit random Seed for private key	1		44
R	Tall 5 byte b2 number	1		8
S	Large 11 byte b2 number	1		16
T	Great 14 byte b2 number	1		20
U	Vast 17 byte b2 number	1		24
V	Label1 as one char (bytes) field map label lead size 1	1		4
W	Label2 as two char (bytes) field map label lead size 0	1		4
X	Tag3 3 B64 encoded chars for field tag or packet type, semver, trait like 'DND'	1		4
Y	Tag7 7 B64 encoded chars for field tag or packet kind and version KERIVVV	1		8
Z	Blinding factor 256 bits, Cryptographic strength deterministically generated from random salt	1		44
Basic Two Character Codes
0A	Random salt, seed, nonce, private key, or sequence number of length 128 bits	2		24
0B	Ed25519 signature	2		88
0C	ECDSA secp256k1 signature	2		88
0D	Blake3-512 Digest	2		88
0E	Blake2b-512 Digest	2		88
0F	SHA3-512 Digest	2		88
0G	SHA2-512 Digest	2		88
0H	Long number 4 byte b2	2		8
0I	ECDSA secp256r1 signature	2		88
0J	Tag1 1 B64 encoded char with pre pad for field tag	1		4
0K	Tag2 2 B64 encoded chars for field tag or version VV or trait like 'EO'	2		4
0L	Tag5 5 B64 encoded chars with pre pad for field tag	2		8
0M	Tag6 6 B64 encoded chars for field tag	2		8
0N	Tag10 10 B64 encoded chars for field tag or version PPPMmmMmm	2		12
	Basic Four Character Codes
1AAA	ECDSA secp256k1 non-transferable prefix public verification key	4		48
1AAB	ECDSA secp256k1 public verification or encryption key	4		48
1AAC	Ed448 non-transferable prefix public verification key	4		80
1AAD	Ed448 public verification key	4		80
1AAE	Ed448 signature	4		156
1AAF	Tag4 4 B64 encoded chars for field tag or message kind	4		8
1AAG	DateTime Base64 custom encoded 32 char ISO-8601 DateTime	4		36
1AAH	X25519 100 char b64 Cipher of 24 char qb64 Salt	4		100
1AAI	ECDSA secp256r1 verification key non-transferable, basic derivation	4		48
1AAJ	ECDSA secp256r1 verification or encryption key, basic derivation	4		48
1AAK	Null None or empty value	4		4
1AAL	Yes truthy boolean value	4		8
1AAM	No falsey boolean value	4		8
	Variable Raw Size Codes
4A	String Base64 Only Lead Size 0	4	2
5A	String Base64 Only Lead Size 1	4	2
6A	String Base64 Only Lead Size 2	4	2
7AAA	String Big Base64 Only Lead Size 0	8	4
8AAA	String Big Base64 Only Lead Size 1	8	4
7AAA	String Big Base64 Only Lead Size 2	8	4
4B	Bytes Lead Size 0	4	2
5B	Bytes Lead Size 1	4	2
6B	Bytes Lead Size 2	4	2
7AAB	Bytes Big Lead Size 0	8	4
8AAB	Bytes Big Lead Size 1	8	4
9AAB	Bytes Big Lead Size 2	8	4
4C	X25519 sealed box cipher bytes of sniffable plaintext lead size 0	4	2
5C	X25519 sealed box cipher bytes of sniffable plaintext lead size 1	4	2
6C	X25519 sealed box cipher bytes of sniffable plaintext lead size 2	4	2
7AAC	X25519 sealed box cipher bytes of sniffable plaintext big lead size 0	8	4
8AAC	X25519 sealed box cipher bytes of sniffable plaintext big lead size 1	8	4
9AAC	X25519 sealed box cipher bytes of sniffable plaintext big lead size 2	8	4
4D	X25519 sealed box cipher bytes of QB64 plaintext lead size 0	4	2
5D	X25519 sealed box cipher bytes of QB64 plaintext lead size 1	4	2
6D	X25519 sealed box cipher bytes of QB64 plaintext lead size 2	4	2
7AAD	X25519 sealed box cipher bytes of QB64 plaintext big lead size 0	8	4
8AAD	X25519 sealed box cipher bytes of QB64 plaintext big lead size 1	8	4
9AAD	X25519 sealed box cipher bytes of QB64 plaintext big lead size 2	8	4
4E	X25519 sealed box cipher bytes of QB2 plaintext lead size 0	4	2
5E	X25519 sealed box cipher bytes of QB2 plaintext lead size 1	4	2
6E	X25519 sealed box cipher bytes of QB2 plaintext lead size 2	4	2
7AAE	X25519 sealed box cipher bytes of QB2 plaintext big lead size 0	8	4
8AAE	X25519 sealed box cipher bytes of QB2 plaintext big lead size 1	8	4
9AAE	X25519 sealed box cipher bytes of QB2 plaintext big lead size 2	8	4

[SmithSamuelM]

Native CESR Messages

KERI Protocol Top Level Fixed Field Packets

With CESR native top-level fixed field messages the actual top-level field labels never appear but we still denote the fields by their label equivalents used by the JSON, CBOR, and MGPK variants. The order of appearance of fields is strict in all variants.

Key Event Messages

These have the packet types icp, rot, ixn, dip, drt

Inception icp

Field order by label: v, t, d, i , s, kt, k, nt, n, bt, b, c, a.

Field Label	Value	Description
NA	-F## or -0F#####	Count code for CESR native top-level fixed field signable message
v	Y&&&&### e.g. YKERICAA	Protocol Version primitive (KERI 2.00)
t	X&&& e.g. Xicp	Packet Type (inception)
d	EBabiu_JCkE0GbiglDXNB5C4NQq-hiGgxhHKXBxkiojg	SAID of event message
i	EBabiu_JCkE0GbiglDXNB5C4NQq-hiGgxhHKXBxkiojg	AID of controller of event message KEL
s	M&&& e.g. MAAA	Sequence Number of Event
kt	M&&& e.g. MAAB	Signing Threshold, either number or fractional weight qb64 variable length string (1)
k	-I## or -I#####	Count code for Signing Key List
0th element	DN6WBhWqp6wC08no2iWhgFYTaUgrasnqz6llSvWQTWZN	Public Key of signer 0
nt	M&&& e.g. MAAB	Rotation Threshold, either number or fractional weight qb64 variable length string (1)
n	-I## or -I#####	Count code for Rotation Key Digest List
0th element	EDDOarj1lzr8pqG5a-SSnM2cc_3JgstRRjmzrrA_Bibg	Digest of Public Key of rotator 0
bt	M&&& e.g. MAAC	Rotation Threshold, either number or fractional weight qb64 variable length string (2)
b	-I## or -I#####	Count code for Backer AID List
0th element	BCuDiSPCTq-qBBFDHkhf1_kmysrH8KSsFvoaOSgEbx-X	AID of backer 0
1th element	BH8KSsFvoaOSgEbx-XCuDiSPCTq-qBBFDHkhf1_kmysr	AID of backer 1
2th element	BBBFDHkhf1_kmysrH8KSsFvoaOSgEbx-XCuDiSPCTq-q	AID of backer 2
c	-I## or -I#####	Count code for Config Trait List
0th element	XDND	Config trait 0 DND
a	-I## or -I#####	Count code for Anchored Seal List
0th element	-H## or -H#####	Count code for field map of Seal 0
0.0th label	0J_& e.g. 0J_i	Label of field 0 of Seal 0 i
0.0th value	EC4NQq-hiGgxhHKXBxkiojgBabiu_JCkE0GbiglDXNB5	Value of field 0 of Seal 0 AID
0.1th label	0J_s	Label of field 1 of Seal 0 s
0.1th value	MAAC	Value of field 1 of Seal 0 Sequence Number
0.2th label	0J_d	Label of field 2 of Seal 0 d
0.2th value	EiGgxhHKXBxkiojgBabiu_JCkE0GbiglDXNB5C4NQq-h	Value of field 2 of Seal 0 SAID
1th element	-R## or -R#####`	Count code for value of Seal 1 (event seal triple)
1.1th value	EHKXBxkiojgBaC4NQq-hiGCkE0GbiglDXNB5gxhbiu_JMAADEBxkiojgiGgxhHKXBDXNB5C4NQq-habiu_JCkE0Gbigl	Value of of Seal 1 (event seal triple) pre+snu+dig

Rotation rot

Field order by label: v, t, d, i , s, p, kt, k, nt, n, bt, br, ba, c, a.

Field Label	Value	Description
NA	-F## or -0F#####	Count code for CESR native top-level fixed field signable message
v	YKERIBAA	Protocol Version primitive (KERI 2.00)
t	Xrot	Packet Type (inception)
d	EC4NQq-hiGgbiglDXNB5xhHKXBxkiojgBabiu_JCkE0G	SAID of event message
i	EBabiu_JCkE0GbiglDXNB5C4NQq-hiGgxhHKXBxkiojg	AID of controller of event message KEL
s	MAAB	Sequence Number of Event
p	EBabiu_JCkE0GbiglDXNB5C4NQq-hiGgxhHKXBxkiojg	Prior event SAID
kt	MAAB	Signing Threshold, either number or fractional weight qb64 variable length string (1)
k	-I## or -I#####	Count code for Signing Key List
0th element	DC08no2iWhgFYTaUgrasnqz6llSvWQTWZNN6WBhWqp6w	Public Key of signer 0
nt	MAAB	Rotation Threshold, either number or fractional weight qb64 variable length string (1)
n	-I## or -I#####	Count code for Rotation Key Digest List
0th element	EM2cc_3JgstRRjmzrrA_BibgDDOarj1lzr8pqG5a-SSn	Digest of Public Key of rotator 0
bt	MAAC	Rotation Threshold, either number or fractional weight qb64 variable length string (2)
br	-I## or -I#####	Count code for Backer Remove (cuts) AID List
0th element	BCuDiSPCTq-qBBFDHkhf1_kmysrH8KSsFvoaOSgEbx-X	AID of backer cut 0
ba	-I## or -I#####	Count code for Backer Add (adds) AID List
0th element	BDiSPCTq-qBBFDHkhf1_kmysrH8KSsFvoaOSgEbx-XCu	AID of backer add 0
c	-I## or -I#####	Count code for Config Trait List
0th element	XDND	Config trait 0 DND
a	-I## or -I#####	Count code for Anchored Seal List
0th element	-H## or -H#####	Count code for field map of Seal 0
0.0th label	0J_i	Label of field 0 of Seal 0 i
0.0th value	EC4NQq-hiGgxhHKXBxkiojgBabiu_JCkE0GbiglDXNB5	Value of field 0 of Seal 0 AID
0.1th label	0J_s	Label of field 1 of Seal 0 s
0.1th value	MAAC	Value of field 1 of Seal 0 Sequence Number
0.2th label	0J_d	Label of field 2 of Seal 0 d
0.2th value	EiGgxhHKXBxkiojgBabiu_JCkE0GbiglDXNB5C4NQq-h	Value of field 2 of Seal 0 SAID
1th element	-R## or -R#####`	Count code for value of Seal 1 (event seal triple)
1.1th value	EHKXBxkiojgBaC4NQq-hiGCkE0GbiglDXNB5gxhbiu_JMAADEBxkiojgiGgxhHKXBDXNB5C4NQq-habiu_JCkE0Gbigl	Value of of Seal 1 (event seal triple) pre+snu+dig

Interaction ixn

Field order by label: v, t, d, i , s, p, a.

Field Label	Value	Description
NA	-F## or -0F#####	Count code for CESR native top-level fixed field signable message
v	YKERIBAA	Protocol Version primitive (KERI 2.00)
t	Xixn	Packet Type (inception)
d	EGgbiglDXNE0GC4NQq-hiB5xhHKXBxkiojgBabiu_JCk	SAID of event message
i	EBabiu_JCkE0GbiglDXNB5C4NQq-hiGgxhHKXBxkiojg	AID of controller of event message KEL
s	MAAC	Sequence Number of Event
p	EC4NQq-hiGgbiglDXNB5xhHKXBxkiojgBabiu_JCkE0G	Prior event SAID
a	-I## or -I#####	Count code for Anchored Seal List
0th element	-H## or -H#####	Count code for field map of Seal 0
0.0th label	0J_i	Label of field 0 of Seal 0 i
0.0th value	EC4NQq-hiGgxhHKXBxkiojgBabiu_JCkE0GbiglDXNB5	Value of field 0 of Seal 0 AID
0.1th label	0J_s	Label of field 1 of Seal 0 s
0.1th value	MAAC	Value of field 1 of Seal 0 Sequence Number
0.2th label	0J_d	Label of field 2 of Seal 0 d
0.2th value	EiGgxhHKXBxkiojgBabiu_JCkE0GbiglDXNB5C4NQq-h	Value of field 2 of Seal 0 SAID
1th element	-R## or -R#####`	Count code for value of Seal 1 (event seal triple)
1.1th value	EHKXBxkiojgBaC4NQq-hiGCkE0GbiglDXNB5gxhbiu_JMAADEBxkiojgiGgxhHKXBDXNB5C4NQq-habiu_JCkE0Gbigl	Value of of Seal 1 (event seal triple) pre+snu+dig

Delegated Inception dip

Field order by label: v, t, d, i , s, kt, k, nt, n, bt, b, c, a, di.

Field Label	Value	Description
NA	-F## or -0F#####	Count code for CESR native top-level fixed field signable message
v	YKERIBAA	Protocol Version primitive (KERI 2.00)
t	Xdip	Packet Type (inception)
d	EBabiu_JCkE0GbiglDXNB5C4NQq-hiGgxhHKXBxkiojg	SAID of event message
i	EBabiu_JCkE0GbiglDXNB5C4NQq-hiGgxhHKXBxkiojg	AID of controller of event message KEL
s	MAAA	Sequence Number of Event
kt	MAAB	Signing Threshold, either number or fractional weight qb64 variable length string (1)
k	-I## or -I#####	Count code for Signing Key List
0th element	DN6WBhWqp6wC08no2iWhgFYTaUgrasnqz6llSvWQTWZN	Public Key of signer 0
nt	MAAB	Rotation Threshold, either number or fractional weight qb64 variable length string (1)
n	-I## or -I#####	Count code for Rotation Key Digest List
0th element	EDDOarj1lzr8pqG5a-SSnM2cc_3JgstRRjmzrrA_Bibg	Digest of Public Key of rotator 0
bt	MAAC	Rotation Threshold, either number or fractional weight qb64 variable length string (2)
b	-I## or -I#####	Count code for Backer AID List
0th element	BCuDiSPCTq-qBBFDHkhf1_kmysrH8KSsFvoaOSgEbx-X	AID of backer 0
1th element	BH8KSsFvoaOSgEbx-XCuDiSPCTq-qBBFDHkhf1_kmysr	AID of backer 1
2th element	BBBFDHkhf1_kmysrH8KSsFvoaOSgEbx-XCuDiSPCTq-q	AID of backer 2
c	-I## or -I#####	Count code for Config Trait List
0th element	XDND	Config trait 0 DND
a	-I## or -I#####	Count code for Anchored Seal List
0th element	-H## or -H#####	Count code for field map of Seal 0
0.0th label	0J_i	Label of field 0 of Seal 0 i
0.0th value	EC4NQq-hiGgxhHKXBxkiojgBabiu_JCkE0GbiglDXNB5	Value of field 0 of Seal 0 AID
0.1th label	0J_s	Label of field 1 of Seal 0 s
0.1th value	MAAC	Value of field 1 of Seal 0 Sequence Number
0.2th label	0J_d	Label of field 2 of Seal 0 d
0.2th value	EiGgxhHKXBxkiojgBabiu_JCkE0GbiglDXNB5C4NQq-h	Value of field 2 of Seal 0 SAID
1th element	-R## or -R#####`	Count code for value of Seal 1 (event seal triple)
1.1th value	EHKXBxkiojgBaC4NQq-hiGCkE0GbiglDXNB5gxhbiu_JMAADEBxkiojgiGgxhHKXBDXNB5C4NQq-habiu_JCkE0Gbigl	Value of of Seal 1 (event seal triple) pre+snu+dig
di	EFXNB5C4NQq-hiGgxhHKXBxkiojgabiu_JCkE0GbiglD	AID of delegating controller

Delegated Rotation drt

Field order by label: v, t, d, i , s, p, kt, k, nt, n, bt, br, ba, c, a, di.

Field Label	Value	Description
NA	-F## or -0F#####	Count code for CESR native top-level fixed field signable message
v	YKERIBAA	Protocol Version primitive (KERI 2.00)
t	Xdrt	Packet Type (inception)
d	EC4NQq-hiGgbiglDXNB5xhHKXBxkiojgBabiu_JCkE0G	SAID of event message
i	EBabiu_JCkE0GbiglDXNB5C4NQq-hiGgxhHKXBxkiojg	AID of controller of event message KEL
s	MAAB	Sequence Number of Event
p	EBabiu_JCkE0GbiglDXNB5C4NQq-hiGgxhHKXBxkiojg	Prior event SAID
kt	MAAB	Signing Threshold, either number or fractional weight qb64 variable length string (1)
k	-I## or -I#####	Count code for Signing Key List
0th element	DC08no2iWhgFYTaUgrasnqz6llSvWQTWZNN6WBhWqp6w	Public Key of signer 0
nt	MAAB	Rotation Threshold, either number or fractional weight qb64 variable length string (1)
n	-I## or -I#####	Count code for Rotation Key Digest List
0th element	EM2cc_3JgstRRjmzrrA_BibgDDOarj1lzr8pqG5a-SSn	Digest of Public Key of rotator 0
bt	MAAC	Rotation Threshold, either number or fractional weight qb64 variable length string (2)
br	-I## or -I#####	Count code for Backer Remove (cuts) AID List
0th element	BCuDiSPCTq-qBBFDHkhf1_kmysrH8KSsFvoaOSgEbx-X	AID of backer cut 0
ba	-I## or -I#####	Count code for Backer Add (adds) AID List
0th element	BDiSPCTq-qBBFDHkhf1_kmysrH8KSsFvoaOSgEbx-XCu	AID of backer add 0
c	-I## or -I#####	Count code for Config Trait List
0th element	XDND	Config trait 0 DND
a	-I## or -I#####	Count code for Anchored Seal List
0th element	-H## or -H#####	Count code for field map of Seal 0
0.0th label	0J_i	Label of field 0 of Seal 0 i
0.0th value	EC4NQq-hiGgxhHKXBxkiojgBabiu_JCkE0GbiglDXNB5	Value of field 0 of Seal 0 AID
0.1th label	0J_s	Label of field 1 of Seal 0 s
0.1th value	MAAC	Value of field 1 of Seal 0 Sequence Number
0.2th label	0J_d	Label of field 2 of Seal 0 d
0.2th value	EiGgxhHKXBxkiojgBabiu_JCkE0GbiglDXNB5C4NQq-h	Value of field 2 of Seal 0 SAID
1th element	-R## or -R#####`	Count code for value of Seal 1 (event seal triple)
1.1th value	EHKXBxkiojgBaC4NQq-hiGCkE0GbiglDXNB5gxhbiu_JMAADEBxkiojgiGgxhHKXBDXNB5C4NQq-habiu_JCkE0Gbigl	Value of of Seal 1 (event seal triple) pre+snu+dig
di	EFXNB5C4NQq-hiGgxhHKXBxkiojgabiu_JCkE0GbiglD	AID of delegating controller

Receipt Message

This message has packet type rct

KERI support Messages

These have the packet types qry, rpy, pro, bar, exn

[SmithSamuelM]

TSP (SPAC) Support

There are several ways to support the TSP with CESR. The TSP is a tunneling routing protocol that would be largely transparent to any other message protocol that is tunneled and routed as a payload of the TSP. Also, viewed from the perspective of the tunneled protocol, the TSP is all overhead, so the TSP wants to be very efficient. The most efficient approach as shown below is for TSP specific fields to be native CESR only. To clarify TSP native payloads for control messages like hop and relationship formation are fully CESR native field values.

The tunneled payload messages (i.e. non-native TSP payload) are represented ad sniffable CESR streams. This allows tunneled non-native TSP payloads to include JSON, CBOR, or MGPK because CESR streams supports those as interleavable with native CESR encoded primitives and CESR groups.

TSP Structure

A TSP wrapper can be modeled with three parts: Head, Body, Tail.

Head

The Head needs to include information that indicates that its a TSP wrapper head part, the version of TSP, the size of the wrapper, and the source and destination VIDS. The head is always plain text. I don't believe there is any need to have more than one head type. This is by design so that the head contains no correlatble metadata besides the source and destination VIDS.

Body

The Body can be composed of two parts: a plaintext portion and a ciphertext portion. The body part, therefore, needs a body type indicator so it can be parsed unambiguously. This allows semantics for the body fields. This body type might be recursively nestable because the ciphertext part may differ for the same plaintext part type. The ciphertext body part must always include the source VID for ESSR. The plaintext body part does not.

Padding Control Message Payloads

One source of meta-data correlation is packet size. To protect against this type of correlation every TSP control message payload includes a trailing padding field. The padding may be of minimum length, essentially a variable length primitive code with zero content length, i.e., code only with empty contents.
The padding primitive is one of the variable length byte string codes as follows:

Bytes_L0:             str = '4B'  # Byte String lead size 0
Bytes_L1:             str = '5B'  # Byte String lead size 1
Bytes_L2:             str = '6B'  # Byte String lead size 2
Bytes_Big_L0:         str = '7AAB'  # Byte String big lead size 0
Bytes_Big_L1:         str = '8AAB'  # Byte String big lead size 1
Bytes_Big_L2:         str = '9AAB'  # Byte String big lead size 2

Theses codes are followed by length characters designated with a #. For example, 4B## has two length characters that indicate the length of the associated bytestring in quadlets in text or Base64 mode. For example, the eight character Base64 string 'abcdefghwould be encoded in CESR as4BACabcdefghi`. The padding should be a random set of characters to minimize correlatability.

Because the TSP control payloads are fixed field with no labels, the padding field must always be present. Empty padding is indicated with the presence of primitive code with zero length contents, that is, 4BAA.

Examples:
Empty Padding Content:
4BAA

Non-Empty Padding Content:
4BACabcdefghi

Tail

The Tail part consists of the attached signature(s) using the source VID. These may be anchored as well. In general, these look pretty much like KERI/ACDC attachments.

Proposed Encoding

TSP ESSR Wrapper

All messages start with a count code. This makes is sniffable in a stream.
The next field is a protocol type and version field.
The protocol has four characters, TSP— and the version 3 characters AAB = 0.01. This will enable variants of the TSP that use ESSR Wrappers but may have different payload types. It also provides future support for other private or closed protocols to add protocol-specific payload types.

TSP ESSR Wrapper	Protocol+Version	Src VID	Dst VID	Ciphertext Payload	Attachment Group	Idx Sig Group	Signature
-E##	YTSP-AAB	did:webs:ELC5L3...	did:webs:EAzjKx...	4C##BacD...	-C##	-0J##	AACZ0j...

TSP ESSR Payload

Plaintext of Ciphertext as Routing Message with Routed Nested ESSR Wrapper

The payload above is ciphertext. In order for the unencrypted plaintext of the payload to be a parsable CESR stream, i.e. sniffable, the payload plaintext must start with (be encapsulated in) a group (count) code. Shown here is the TSP ESSR payload group. The Plaintext has a message type so that a parser can parse the fixed field formatted messages. This allows a virtually unlimited number of payload message types.

TSP Payload Group	Payload Type	Src VID	Hop List Group	Hop VID	Hop VID	Padding	TSP ESSR Wrapper	Protocol+Version	Src VID	Dst VID	Ciphertext Payload	Attachment Group	Idx Sig Group	Signature
-Z##	XHOP	did:webs:ELC5L3...	-I##	did:webs:EAzjKx...	did:webs:EBak1C...	4B##	-E##	YTSP-ABA	did:webs:EG2erX...	EBe1rj...	did:webs:4C##CefH...	-C##	-0J##	AAEbw3...

[SmithSamuelM]

Open vs Closed Mode

TSP Wrapper in Open Mode

With TSP Protocol+Version

TSP ESSR Wrapper	Protocl+Version	Src VID	Dst VID	Ciphertext Payload	Attachment Group	Idx Sig Group	Signature
-E##	YTSP-AAB	did:webs:...	did:webs:...	4C##BacD...	-C##	-0J##	AACZ0j...

TSP ESSR Payload

With Payload type for given Protocol Type version.

Hop Payload with tunneled ESSR in Open Mode

TSP Payload Group	Message Type	Src VID	Hop List Group	Hop VID	Hop VID	Padding	TSP ESSR Wrapper	Version	Src VID	Dst VID	Ciphertext Payload	Attachment Group	Idx Sig Group	Signature
-Z##	XHOP	did:webs:...	-I##	did:webs:...	did:webs:...	4B##	-E##	XABA	did:webs:...	did:webs...	4C##CefH...	-C##	-0J##	AAEbw3...

Closed Mode

ESSR Wrapper in closed mode

TSP ESSR Wrapper	Protocl+Version	Src VID	Dst VID	Ciphertext Payload	Attachment Group	Idx Sig Group	Signature
-E##	YTSP-AAB	EAAABBBCCC...	EAAADDD...	4C##BacD...	-C##	-0J##	AACZ0j...

Hop Payload with tunneled ESSR in closed Mode

TSP Payload Group	Message Type	Src VID	Hop List Group	Hop VID	Hop VID	Padding	TSP ESSR Wrapper	Version	Src VID	Dst VID	Ciphertext Payload	Attachment Group	Idx Sig Group	Signature
-Z##	XHOP	did:webs:...	-I##	EAzei...	ECkel....	4B##	-E##	XABA	EBcde...	EBkms..	4C##CefH...	-C##	-0J##	AAEbw3...

[SmithSamuelM]

Proposed: support two namespaces in open mode in version 1.
URN and DID
Closed mode: rules if do not understand closed mode vid type than silently drop

[SmithSamuelM]

Parsing Logic:

VID fields in Open Mode

The variable length UTF-8 encoded text strings (bytes) that contain the VIDs use one of the following 6 CESR codes in Base64:

    Bytes_L0:             str = '4B'  # Byte String lead size 0
    Bytes_L1:             str = '5B'  # Byte String lead size 1
    Bytes_L2:             str = '6B'  # Byte String lead size 2
    Bytes_Big_L0:         str = '7AAB'  # Byte String big lead size 0
    Bytes_Big_L1:         str = '8AAB'  # Byte String big lead size 1
    Bytes_Big_L2:         str = '9AAB'  # Byte String big lead size 2

If not one of these codes then the VID field is erroneous and the packet may be silently dropped.

VID Fields in Closed Mode

The CESR encoding of the VID field in closed mode is whatever that particular closed mode decides to use by pre-agreement.
For example, native KERI AIDs could appear as is (CESR encoded Digest or Public Key) without being encoded into a did:keri or did:webs namespace.

TSP ESSR Wrapper Payload field

Determining if field value is a CESR primitive or CESR group

In any CESR stream, the rule is that all primitives and encapsulated groups that appear within an encapsulating group must appear in the same CESR domain as the group code for the encapsulating group. The two domains are (TEXT=Base64 or BINARY=Base2). A stream may have interleaved groups that are in different domains at the top level but not nested within a any given group.

The group codes are sniffable (the first tritet (3) of bits is unique relative to anything else that may appear at the top level (these other things include JSON, CBOR, MGPK, and Annotated streams). So, a parser can determine the start of a group and which domain the group appears in (TEXT or BINARY) merely by sniffing (peeking) at the first three bits of a stream at the top level. Subsequently, when parsing the encapsulated contents of the group, the parser may assume unambiguously that all its contents appear in the same domain (TEXT or BINARY) as the encapsulating group (count) code. Each field of contents are either a nested group or a primitive.

All group codes start with the charater - in TEXT domain (Base64) and the bits 111110 in the BINARY domain (Base2). The parser only has to look at the first character when in TEXT domain or the first six bits when in Binary domain in order to determine if the payload field is a plain text sniffable group or an encrypted primitive. The parser can then dispatch the correct sub-parser for each case.

Payload Field as Group

The payload field must be either an encrypted primitive or an unencrypted TSP Payload group that starts with group code -Z##.

Payload Field as Encrypted sniffable CESR Stream

The CESR codes for libsodium sealed box sniffable streams in the TEXT Domain are as follows:

X25519_Cipher_L0:     str = '4C'  # X25519 sealed box cipher bytes of sniffable stream plaintext lead size 0
X25519_Cipher_L1:     str = '5C'  # X25519 sealed box cipher bytes of sniffable stream plaintext lead size 1
X25519_Cipher_L2:     str = '6C'  # X25519 sealed box cipher bytes of sniffable stream plaintext lead size 2
X25519_Cipher_Big_L0: str = '7AAC'  # X25519 sealed box cipher bytes of sniffable stream plaintext big lead size 0
X25519_Cipher_Big_L1: str = '8AAC'  # X25519 sealed box cipher bytes of sniffable stream plaintext big lead size 1
X25519_Cipher_Big_L2: str = '9AAC'  # X25519 sealed box cipher bytes of sniffable stream plaintext big lead size 2
HPKEBase_Cipher_L0:     str = '4F'  # HPKE Base cipher bytes of sniffable stream plaintext lead size 0
HPKEBase_Cipher_L1:     str = '5F'  # HPKE Base cipher bytes of sniffable stream plaintext lead size 1
HPKEBase_Cipher_L2:     str = '6F'  # HPKE Base cipher bytes of sniffable stream plaintext lead size 2
HPKEBase_Cipher_Big_L0: str = '7AAF'  # HPKE Base cipher bytes of sniffable stream plaintext big lead size 0
HPKEBase_Cipher_Big_L1: str = '8AAF'  # HPKE Base cipher bytes of sniffable stream plaintext big lead size 1
HPKEBase_Cipher_Big_L2: str = '9AAF'  # HPKE Base cipher bytes of sniffable stream plaintext big lead size 2
HPKEAuth_Cipher_L0:     str = '4G'  # HPKE Auth cipher bytes of sniffable stream plaintext lead size 0
HPKEAuth_Cipher_L1:     str = '5G'  # HPKE Auth cipher bytes of sniffable stream plaintext lead size 1
HPKEAuth_Cipher_L2:     str = '6G'  # HPKE Auth cipher bytes of sniffable stream plaintext lead size 2
HPKEAuth_Cipher_Big_L0: str = '7AAG'  # HPKE Auth cipher bytes of sniffable stream plaintext big lead size 0
HPKEAuth_Cipher_Big_L1: str = '8AAG'  # HPKE Auth cipher bytes of sniffable stream plaintext big lead size 1 
HPKEAuth_Cipher_Big_L2: str = '9AAG'  # HPKE Auth cipher bytes of sniffable stream plaintext big lead size 2

The CESR code is prepended to the encrypted payload. The code is not itself encrypted.

CESR codes for other sniffable stream HPKE encryption formats have yet to be defined

When the TSP ESSR Wrapper that contains that payload field is in the TEXT Domain

The parser can read the first character of the payload field and if it's - then the payload is plain text payload group that may be recursively parsed. If not - then the payload must be an encrypted sniffable CESR stream and must use one of the codes above. This is becaue none of the codes above in the text domain start with -.

When the TSP ESSR Wrapper that contains that payload field is in the Binary Domain

The parser can read the first two tritets (6 bits) of the payload field and if it's 111110 then the payload is a plain text payload group in the BINARY domain and this may be recursively parsed. If not 111110, then the payload must be an encrypted sniffable CESR stream primitive but in the BINARY domain and must use one of the codes above but in Binary Domain. This is because none of the codes above when converted to the binary domain, starts with 111110.

[SmithSamuelM]

@iFergal

Payload Message Type Table

Currently the only defined TSP payload message type is HOP which is CESR encoded as XHOP.

Proposed below are two additional TSP payload message types. REL for relationship formation message and SCS for sniffable CESR stream.

Additionally, a useful set of message types for those using the TSP with KERI is to tunnel KERI messages as TSP ESSR payloads. A convenient way to do this would be to have a TSP payload message type for each KERI message type. Because KERI message types are exactly three base 64 characters, we can seamlessly use the same exact message types for both. In addition, KERI message types are all lowercase. If we adopt the convention that native TSP message types be uppercase then we make it easy to avoid collisions.
For KERI messages using these TSP codes the message is the message body plus any attachments. So a parser needs to be capable of parsing the attachments as well.

This same convention can be used for the new ACDC version two message types (see ACDC Protocol Top Level) below.

Below is a proposed TSP Payload Message type table.

Code	Protocol	Description
XHOP	TSP	hop list tunneled payload
XRFI	TSP	relationship formation invite payload
XRFA	TSP	relationship formation accept payload
XRFD	TSP	relationship formation decline payload
XSCS	TSP	sniffable CESR stream as payload
Xxip	KERI	exchange inception message as payload
Xexn	KERI	exchange message as payload
Xqry	KERI	query message as payload
Xrpy	KERI	reply message as payload
Xpro	KERI	prod message as payload
Xbar	KERI	bare message as payload
Xicp	KERI	inception message as payload
Xrot	KERI	rotation message as payload
Xixn	KERI	interaction message as payload
Xdip	KERI	delegated inception message as payload
Xdrt	KERI	delegated rotation message as payload
Xrip	ACDC	registry inception message as payload
Xupd	ACDC	registry state update message as payload
Xacd	ACDC	ACDC message as payload
Xsch	ACDC	ACDC schema section message as payload
Xatt	ACDC	ACDC attribute section message as payload
Xagg	ACDC	ACDC attribute aggregate section message as payload
Xedg	ACDC	ACDC edge section message as payload
Xrul	ACDC	ACDC rule section message as payload

Examples

KERI exn Payload

TSP Payload Group	Message Type	Src VID	exn message	Padding
-Z##	Xexn	EAABCD...	exn message	4B##

[SmithSamuelM]

ACDC Protocol Top Level

The default ACDC message protocol packet does not currently include a packet type field version 2 adds optional packet type field t to ACDC messages. With a type field then other formats for specific variants of ACDC messages would be possible. For example, top-level fixed field public and private compact ACDCs could be supported because the packet type field would enable a parser to look up the top-level list of fixed fields. Packet types could also be used to send independently the expanded non-compact sections from a compact ACDC that includes only the SAIDs of the sections. Commonly reused sections like the schema section could then only be sent once to more efficiently stream a bunch of ACDCs that each share the same schema but have different field values in the other

These have the packet types rip, upd, acd, sch, att, agg, edg, rul

With CESR native top-level field map messages the actual top-level field labels appear as labels in a field map. These correspond to the same labels used by the JSON, CBOR, and MGPK variants. The order of appearance of fields is strict in all variants.

ACDC Protocol Top Level Field Map Packets

ACDC Message (no packet type)

Field order by label: v, t, d, u, i , rd, s, a, A, e, r.
Required field order by label: v, d, i , s.

Compact Private ACDC

Included fields: v, d, u, i , rd, s, a, e, r.

Field Label	Label Value	Field or Count Value	Description
NA	NA	-G## or -0G#####	Count code for CESR native top-level field map signable message
v	0J_v	YACDCBAA	Protocol Version primitive (ACDC 2.00)
d	0J_d	EGgbiglDXNE0GC4NQq-hiB5xhHKXBxkiojgBabiu_JCk	SAID of ACDC packet
u	0J_u	0AGC4NQq-hiB5xhHKXBxkiK	UUID (salt) of ACDC packet
i	0J_i	EBabiu_JCkE0GbiglDXNB5C4NQq-hiGgxhHKXBxkiojg	AID of issuer of ACDC
rd	0Krd	ECkE0GbiglDXNB5C4NQq-hiGgxhHKXBxkiojgBabiu_J	SAID of revocation registry for ACDC
s	0J_s	EDXNB5C4NQq-hiGgxhHKXBxkiojgBabiu_JCkE0Gbigl	SAID of schema section of ACDC packet
a	0J_a	EC4NQq-hiGgbiglDXNB5xhHKXBxkiojgBabiu_JCkE0G	SAID of schema of attribute section of ACDC packet
e	0J_e	EFXBxkiojgBabiu_JCkE0GC4NQq-hiGgbiglDXNB5xhH	SAID of schema of edge section of ACDC packet
r	0J_r	EMiGgbiglDXNB5xhHFXBxkiojgBabiu_JCkE0GC4NQq-	SAID of schema of rule section ACDC packet

sections.

[2byrds]

Should the SAID of revocation registry be different than the AID of issuer of ACDC?

[SmithSamuelM]

Yes that was a typo now fixed

[SmithSamuelM]

obsolete

[SmithSamuelM]

TSP Payload Types

Code	Protocol	Description
XHOP	TSP	hop list tunneled payload
XRFI	TSP	relationship formation invite payload
XRFA	TSP	relationship formation accept payload
XRFD	TSP	relationship formation decline payload
XSCS	TSP	sniffable CESR stream as payload
XPAD	TSP	padding payload to minimize metadata correlation based on departure and arrival times

Relationship Formation (Sub) Protocol

Relationship Formation Invitation (RFI )Payload in Open Mode

TSP Payload Group	Message Type	Source VID	RFI SAID (RF IID)	Salty Nonce	New Rel iVID	Idx Sig Group	Signature iVID	Padding
-Z##	XRFI	did:webs:src_VID	EBa...	Abcd...	did:webs:new_iVID	-0J##	AAEaz4...	4B##

Relationship Formation Acceptance (RFA) Payload in Open Mode

TSP Payload Group	Message Type	Source VID	RFA SAID	Salty Nonce	RFI SAID (RF IID)	New Rel aVID	Idx Sig Group	Signature aVID	Padding
-Z##	XRFA	did:webs:src_VID	EAz...	Aevg...	EBa...	did:webs:new_aVID	-0J##	AAEbw3...	4B##

Relationship Formation Decline (RFD) Payload in Open Mode

TSP Payload Group	Message Type	Source VID	RF IID	Padding
-Z##	XRFD	did:webs:src_VID	EBa...	4B##

Each relationship formation protocol payload is embedded in an TSP ESSR wrapper payload

The wrapper payload uses an existing relationship X0 and Y0.

Should X0 wish to form a new relationship with Y0 with a new VID that X0 controls, say X1. Then X0 sends and ESSR Wrapped packet to Y0 with an RFI payload. The source VID in the RFI payload is X0.

The RFI is X0 inviting Y0 to form a new relationship with X1 == the new iVID in the RFI payload. X1 is controlled by X0. This invitation must be signed by the key(s) for X1 so that Y0 knows that invite comes from the controller of X1 via X0.

If Y0 wishes to accept the invite then Y0 responds with an RFA payload wrapped in a TSP ESSR wrapper Y0 to X0.
The RFA is Y0 accepting the invite to form a new relationship with between X1 and Y1 where Y1 == new aVID in the RFA payload. Y1 is controlled by Y0. This acceptance must be signed by Y1 so that X0 knows that acceptance comes from the controller of Y1 via Y0. The source VID in the RFA payload is Y0.

If Y0 choses not to accept the invite, Then Y0 sends an TSP ESSR wrapped packet from Y0 to X0 with payload RFD. This payload includes the iSAID IID from the RFI payload. The source VID in the RFA payload is Y0.

The iSAID is computed over the non-attachment portion of the RFI payload
The aSAID is computed over the non-attachment portion of the RFA payload

Replay Attack

A reply attack mechanism is not required as long as relationship formations are treated a idempotent actions. The pair of cryptographically derived VIDs in a relationships form a univerally unique pairing. Therefore the formation of the pairing can be treated as idempotent in that a replay attack is just treated as redundant or duplicate formation attempt that does not change the state of the relationship once formed. This means that a stale decline (RFD) is ignored for any previously accepted relationships.

Salty Nonce

The salty nonce field in the RFI and RFA payloads protects against a rainbow table attack that could correlate the embedded
new VID to the SAID of the payload. This assumes that the unencrypted SAID of the payload or the Signature of the payload is/are leaked in some way, and the encrypted payload is also leaked. When this happens SaltyNonce ensures that the encrypted payload includes enough entropy to prevent correlating the unleaked new VID to the leaked SAID or Signature.

Relationship Formation Invitation (RFI )Payload in Closed Mode

TSP Payload Group	Message Type	Source VID	RFI SAID (RF IID)	Salty Nonce	New Rel iVID	Idx Sig Group	Signature iVID	Padding
-Z##	XRFI	EAmn_src_VID.	EBa...	Azbef...	ECdh_new_iVID	-0J##	AAEbw3...	4B##

Relationship Formation Acceptance (RFA) Payload in Closed Mode

TSP Payload Group	Message Type	Source VID	RFA SAID	Salty Nonce	RFI SAID (RF IID)	New Rel aVID	Idx Sig Group	Signature aVID	Padding
-Z##	XRFA	EArs_src_VID.	ECh....	Aklmj...	EBa...	EDab_new_aVID	-0J##	AAEbw3...	4B##

Relationship Formation Decline (RFD) Payload in Closed Mode

TSP Payload Group	Message Type	Source VID	RF IID	Padding
-Z##	XRFD	EArs_src_VID.	EBa...	4B##

Generic Payloads as Sniffable CESR Streams.

When not used for TSP native control messages, the embedded payload of a TSP tunnel is entirely application-specific. Sniffable CESR streams can accommodate virtually any data format. The XSCs is the generic payload type meant to ecapsulate application-specific payloads to be delivered to layers on top of the TSP. These would include any trust task payloads. In CESR the -A## and -0A##### group codes are meant for generic pipeline able groups of other group or primitive codes. This enables parseable delimitation of a perfectly generic payload.

Generic payload as sniffable CESR stream in Open Mode

| TSP Payload Group | Message Type | Source VID | CESR Stream | Padding |
|:--------:|:--------:|:-------|:------------|
| -Z## | XSCS | did:webs:src_VID | -A##.... | 4B## |

Generic payload as sniffable CESR stream in Closed Mode

| TSP Payload Group | Message Type | Source VID | CESR Stream | Padding |
|:--------:|:--------:|:-------|:------------|
| -Z## | XSCS | EAcs_src_VID. | -A##.... | 4B## |

Pad Payloads

Metadata that can be used by a surveillor to correlate source and final destination of routed packets are packet size as well as the time-of-departure (TOD) and the time-of-arrival (TOD) at the final destination. The padding field in the TSP payloads enables a given source to pad all packets to the same length to minimize correlation on packet size. But this does not address TOA and TOD correlation. One way to minimize TOD/TOA correlation is to whiten the stream of packets by injecting pad packets so that there is a uniform distribution of packets over time. When a source does not have any material data to send, it just pads its stream with pad packets so that a correlator always sees a uniformly distributed in time set of packets. The XPAD packet payload has the following fields:

Pad Payload in Open Mode

TSP Payload Group	Message Type	Source VID	Padding
-Z##	XPAD	did:webs:src_VID	4B##

The pad field in the XPAD payload type has the same semantics as the pad field in the other payload types. The Source VID is the source VID as per the ESSR format, i.e. encrypt source.

Pad Payload in Closed Mode

TSP Payload Group	Message Type	Source VID	Padding
-Z##	XPAD	EAfg_src_VID	4B##

[SmithSamuelM]

obsolete