Glossary

A curated index of the terms that matter when you implement an INK sender or receiver. Each entry is a short orientation, not the normative definition: the canonical rules live on the linked spec page, and that page wins on any conflict.

Agent Card

The public, self-describing document an agent publishes at GET /ink/v1/{agentId}/agent.json. It carries the agent’s signing and encryption keys, capabilities, visibility, and supportedProtocolVersions. Receivers fetch it to learn how to verify and reach a sender. See Agent Card.

agentId

An agent’s stable identifier of the form <method>:<multibase(Ed25519 public key)>. Because the key is encoded in the identifier, a receiver can derive a sender’s signing key directly from its agentId when no card is published yet (the bootstrap path). The canonical method prefix is tulpa: (the form agents emit); ink: is an accepted inbound alias carrying the same key. Receivers accept both and collapse them to one prefix-independent principal for all security state. See Identity.

Body signature

The Ed25519 signature over the message payload, carried in the envelope’s signature field. Distinct from the transport-auth signature. Its signing domain is version-keyed: ink/sign\n for ink/0.2, tulpa/sign\n for ink/0.1 (see ink/sign vs tulpa/sign). See Authentication.

Canonicalization (JCS)

The deterministic JSON serialization (RFC 8785, JSON Canonicalization Scheme) applied before hashing or signing, so both parties sign byte-identical bytes regardless of key order or whitespace. Any divergence breaks signature verification. See Canonicalization.

correlationId

An identifier shared by the messages of one exchange. Request/response intent pairs echo the same correlationId so both sides can thread a conversation and so handshake budgets can be scoped per exchange. See Intent Types.

DID

Decentralized Identifier. INK agents use the tulpa: method (key-derived, see agentId); foreign senders may present other methods such as did:web or did:key. The identifier is what a signature is ultimately bound to. See Identity.

ECIES

The hybrid encryption scheme used for encrypted payloads: an ephemeral X25519 ECDH, HKDF-SHA256 key derivation, and AES-256-GCM. Required for sensitive intents (for example schedule_meeting, context_share). See Encryption.

Envelope

The signed outer structure that wraps every message: protocol version, sender and recipient, identifiers, timestamp, nonce, intent, payload, and signature. A receiver verifies the envelope before interpreting the intent payload inside it. See Wire Types.

Handshake

The bounded state machine that follows an intent: optional challenge, then resolution or rejection. Per-exchange budgets cap how many transitions and challenges are allowed. See Handshake.

ink/sign vs tulpa/sign

The two body-signature domains, selected from the signed protocol field: ink/sign\n for ink/0.2, the legacy tulpa/sign\n for ink/0.1. A signature minted under one domain never verifies under the other, so relabelling a message across versions invalidates it. See Versioning & Compatibility.

Intent

The intent field that selects what a message means and which payload schema applies. Payload schemas are strict: receivers reject unknown fields. The fifteen intents and their schemas are listed in Intent Types.

Multibase

The self-describing base-encoding (here base58btc, z prefix) used to represent public keys as strings in agentIds and Agent Cards. The prefix tells a parser how to decode the bytes that follow. See Identity.

Nonce

A single-use random value carried by every message. Receivers record seen nonces within the freshness window and reject repeats, which blocks replay of a captured-but-valid message. See Replay Protection.

Payload

The intent-specific body inside the envelope, validated against the strict schema for that intent. The envelope is verified first; only then is the payload interpreted. See Wire Types.

TOFU

Trust On First Use: how a receiver resolves an unknown sender’s signing key on first contact. It fetches the sender’s Agent Card; if none is published (404) it falls back to deriving the key from the sender’s agentId. See Discovery.

Transport auth

The Ed25519 signature in the Authorization: INK-Ed25519 <sig> header that authenticates the HTTP request itself, separate from the body signature. Its signature base is the same across wire versions. See Authentication.

Wire version

The ink/<major>.<minor> string in a message’s protocol field. ink/0.2 is current; ink/0.1 remains supported. A receiver gates on the major version and accepts any minor within it. See Versioning & Compatibility.

Witness

A third-party transparency log that records hash-chained audit events and issues Merkle-tree (RFC 6962) inclusion proofs, so a counterparty can later verify an exchange happened without trusting either agent’s word. See Witness and Third-Party Audit.