notes: research/papers/papers-tsp-cesr-implementation-details

This data as json

path title type status classification words body
research/papers/papers-tsp-cesr-implementation-details TSP CESR Implementation Details summary v0.1 — 2026-10-15: drafted by Claude from the markdown file in the Papers repository; unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only partner 608 # TSP CESR Implementation Details **Abstract.** A technical proposal for encoding the Trust Spanning Protocol (TSP) wrappers and payloads with Composable Event Streaming Representation (CESR) primitives and groups. It defines open and closed modes for verifiable identifier (VID) encoding, the head, body and tail of the TSP ESSR (encrypt-sender-sign-receiver) wrapper, native payload types including hop and relationship formation, and a proposed table for tunneling KERI and ACDC messages as TSP payloads. For implementers of TSP and CESR. ## Summary The document starts from the premise that TSP is a tunneling and routing protocol meant to be transparent to the protocols it carries, so its overhead should be minimal. TSP-native fields and control payloads are therefore fixed-field CESR primitives, while tunneled payloads are sniffable CESR streams that may interleave JSON, CBOR (Concise Binary Object Representation) and MessagePack. VIDs are encoded in one of two modes. In open mode, every VID is a URN or DID (decentralized identifier) carried as a variable-length CESR byte string, with six codes covering three lead-pad sizes in small and big forms; the document gives the padding formula. In closed mode, VIDs follow a pre-agreed CESR encoding, for example native KERI AIDs (Autonomic Identifiers) with no did:keri or did:webs namespace. A wrapper has a head, body and tail. The head is always plaintext: an ESSR count code, a protocol type and version field (`TSP_` plus three Base64 version characters, encoded as `YTSP_AAB` for version 0.1), and source and destination VIDs, so that the head carries no correlatable metadata beyond the two VIDs. The body is either HPKE (Hybrid Public Key Encryption) ciphertext, encoded with dedicated CESR codes, or a plaintext payload typed as control, hop, relationship formation invite, accept or decline, pad, or sniffable CESR stream. The tail carries the signature attachment group. Later sections specify each payload: hop lists (with a proposed variant encrypted to the final destination), the relationship formation sub-protocol, in which an existing VID pair is used to invite and accept a new pair with signatures from the new VIDs, idempotence in place of replay protection, and a salty nonce against rainbow-table correlation; padding payloads; and how a parser tells ciphertext from plaintext in the text and binary domains. A final section proposes TSP payload type codes for each KERI and ACDC message type, with native TSP types in upper case and KERI types in lower case to avoid collisions. ## Key terms TSP, ESSR wrapper, VID, open mode, closed mode, sniffable CESR stream, HPKE, hop payload, relationship formation (RFI, RFA, RFD), salty nonce, payload message type table ## Claims and their evidence - Encoding TSP fields as CESR primitives is the most efficient approach for a protocol that should be transparent to tunneled payloads. [informative] - A uniform plaintext head keeps correlatable metadata to the source and destination VIDs. [informative] - Relationship formation needs no replay protection if treated as idempotent, since a VID pair is universally unique. [informative] - A salty nonce in RFI and RFA payloads prevents correlating a leaked new VID with a leaked payload SAID or signature. [informative] ## Related Trust Spanning Protocol specification (Trust over IP), CESR specification, KERI specification, ACDC specification. ## Provenance Drafted by Claude on 2026-10-15 from the markdown file `whitepapers/TSP_CESR_Implementation.md`: the introduction, VID, structure, relationship formation and payload-type sections read in full, encoding examples skimmed. The document names no author or date; it is attributed to Samuel M. Smith by the repository and dated by its commits (April to July 2025). The expansion of ESSR is not given in the document; it is supplied by Claude from the Trust Spanning Protocol specification and is unverified here. Not yet read by Mark.

Links from other tables