Glossary

A DID-bearing identity node in the trust graph. A VTA can represent a person, an organization, a community, or an AI agent. VTAs are the vertices of the trust graph — every participant in the Decentralized Trust Graph is a VTA. VTAs, VTCs, and VRCs are defined by the Trust over IP Foundation architecture.

A governance-bounded cluster of VTAs with shared trust rules. A VTC defines who can join, what credentials are required for membership, and what actions members can take. VTCs are the communities of the trust graph — they can represent anything from a small family group to a large professional association or a decentralized autonomous organization.

A W3C Verifiable Credential that cryptographically proves a relationship between two VTAs. VRCs are bidirectional — both parties sign them — making them tamper-proof and non-repudiable. VRCs are the edges of the trust graph. They can encode membership, delegation, endorsement, employment, or any other trust relationship.

A cryptographically verifiable identifier for a VTA. In the current FPTS implementation, VIDs are did:peer:4 DIDs — self-certifying identifiers that embed the DID Document in the identifier itself. VIDs are the addresses used in TSP messages to identify senders and receivers.

A W3C standard for self-sovereign identity. A DID is a globally unique identifier controlled by its owner (not a registrar or platform), backed by cryptographic key material, and resolvable to a DID Document. DIDs are the foundation of VTAs in the FPTS.

A JSON-LD document that a DID resolves to. It describes the identity's public keys (for signing and encryption), service endpoints (for messaging and discovery), and verification methods. The DID Document is the public face of a VTA.

A self-certifying DID method where the DID Document is embedded in the identifier itself. Resolution and verification are fully offline — no network lookup required. Used in the current FPTS Layer 2 implementation for all development and testing. The identifier is derived from the SHA-256 hash of the encoded DID Document (numalgo4 encoding).

A self-certifying DID method used as the primary long-lived identity method in the FPTS. Each did:scid:vh carries its own cryptographic proof of provenance via a hash-chained verifiable history — no external ledger dependency. Supports built-in key pre-rotation and witness attestation via a decentralized Witness VTC. The SCID is derived deterministically from the initial DID Document using JCS canonicalization and Blake2b-256.

A DID-method-agnostic interface with create(), resolve(), verify(), and a supportsRotation flag. Agent and RelationshipManager depend on this interface rather than any specific DID method, so new implementations can be dropped in without changing either module's public API. Concrete implementations include ScidVhMethod, DidPeer4Method, and RotatingVidMethod.

A Verified Trust Community whose members act as witnesses for DID rotation events. Rather than a hosted watcher network the FPTS's native rotation mechanism has each rotation co-signed by M-of-N members of a decentralized Witness VTC, using the same issueVrc()/verifyVrc() primitive as any other VRC — the claim type is simply 'rotation-witness'. A fixed, documented "genesis" Witness VTC is shipped for development and early-adopter use; production deployments are expected to replace or supplement it.

An append-only, hash-chained log of a rotating VID's DID Document versions. Each entry pre-commits to the hash of the next signing key (pre-rotation) and is signed by the key it is rotating away from, so a compromise of the current key alone cannot forge a future rotation. The latest entry must also carry sufficient Witness VTC attestations to be trusted.

A W3C Verifiable Credential representing a VTA's public profile information. Supports per-claim disclosure control with four levels: always (publicly visible), discretionary (visible only to VTAs with an established relationship), never (never disclosed via R-Card), and zkp_only (disclosable only via zero-knowledge proof). Exported in JCard format for interoperability.

The Layer 2 protocol of the First Person Trust Stack. TSP defines the message format, signing, encryption, and relationship handshake for authenticated messaging between VTAs. TSP is transport-agnostic — it can run over libp2p, HTTP, Bluetooth, or any other channel. TSP is inclusive of DIDComm-like concepts but is not based on DIDComm.

A small JSON object containing a VTA's VID and transport address (libp2p PeerID + multiaddrs). OOBIs are shared out-of-band (via QR code, link, copy-paste) to bootstrap a relationship. The OOBI is not a secret — it is the equivalent of a business card for the trust graph.

The first message in the TSP relationship handshake. The initiating party sends a TSP_RFI containing a nonce and their full DID Document. The receiving party verifies the sender's VID and replies with a TSP_RFA.

The second message in the TSP relationship handshake. The receiving party sends a TSP_RFA containing the digest of the TSP_RFI and their own DID Document. After the RFA is received and verified, both parties have a bidirectional, verified relationship.

A signed, unencrypted TSP application message. The sender's Ed25519 key signs the message; the receiver verifies the signature against the sender's VID. Use TSP_GEN when confidentiality is not required but authenticity and integrity are.

An HPKE-Auth encrypted TSP application message. Uses DHKEM(X25519, HKDF-SHA256) + ChaCha20/Poly1305 for authenticated encryption. Only the intended recipient can decrypt; the sender's identity is cryptographically bound to the ciphertext. Use TSP_GEN_CONFIDENTIAL when both authenticity and confidentiality are required.

An authenticated public-key encryption scheme (RFC 9180). HPKE-Auth combines a key encapsulation mechanism (KEM) with an authenticated encryption scheme (AEAD) to provide both confidentiality and sender authentication. The FPTS uses DHKEM(X25519, HKDF-SHA256) with ChaCha20/Poly1305 for TSP_GEN_CONFIDENTIAL messages.

A binary-to-text encoding format used in the FPTS for TSP message framing. CESR encodes cryptographic primitives (public keys, signatures, digests, nonces) as short ASCII prefixes followed by base64url-encoded bytes. The FPTS uses a minimal CESR codec — not the full spec.

An elliptic curve digital signature algorithm used for signing TSP messages and DID Documents. Ed25519 keys are 32 bytes (public) and 64 bytes (private). All TSP messages are signed with the sender's Ed25519 key and verified against the sender's VID.

An elliptic curve Diffie-Hellman key agreement algorithm used for HPKE-Auth encryption. X25519 keys are derived from Ed25519 keys in the FPTS. The receiver's X25519 public key is used to encrypt TSP_GEN_CONFIDENTIAL messages.

A system that stores and serves DID Documents. VDRs are part of Layer 1 (Trust Support) infrastructure. The FPTS uses did:scid:vh (which requires no VDR — self-certifying with hash-chained history) as its primary method, and did:peer:4 (also ledger-free) for development. Other DID methods may use an external VDR.

A modular peer-to-peer networking library used as the transport layer in the current FPTS implementation. libp2p handles TCP connections, noise encryption, yamux stream multiplexing, and peer discovery. The FPTS wraps libp2p behind the TspTransport interface so that higher-level code never imports libp2p directly.

A TSP messaging mode where two VTAs communicate directly, without any intermediary nodes. Direct Mode is the first mode implemented in the FPTS and is complete, supporting VTA creation, relationship establishment (RFI/RFA), personhood ceremony, agent name registration, confidential messaging (HPKE-Auth), and R-Card retrieval. Routed Mode (through intermediaries) is planned for future development.

A planned TSP messaging mode where messages are routed through one or more intermediary nodes. Routed Mode provides metadata privacy (the intermediary does not know the final destination) and enables communication between VTAs that cannot connect directly. Not yet implemented.

A four-layer architecture for decentralized trust infrastructure, defined by the Trust over IP Foundation. The FPTS is organized around the ToIP model: Layer 1 (Trust Support), Layer 2 (Trust Spanning), Layer 3 (Trust Tasks), and Layer 4 (Trust Applications).