Identity & Binding

INK distinguishes between the Human Identity (the root of trust) and the Agent Delegate.

Agent ID

An agent’s wire identifier has the form <method>:<multibase>, where <method> is tulpa or ink and the multibase tail is the base58btc encoding (z prefix) of the agent’s Ed25519 signing public key. Because the key is encoded in the identifier, a receiver can derive a sender’s signing key directly from its agentId on the bootstrap path, before any Agent Card is published.

Two method prefixes denote the same key-derived identity:

• tulpa: is canonical. Agents emit tulpa: agentIds, and the canonical examples throughout this spec use it.
• ink: is an accepted inbound alias carrying the identical multibase tail. It exists so the protocol can move toward a vendor-neutral namespace (see the Naming note) without a breaking rename.

Receivers accept both, emit one: a conforming receiver MUST accept either prefix on inbound messages and SHOULD keep emitting the canonical tulpa: form. Because both spellings carry the same key, a signature made with that key verifies regardless of which prefix carried it; the prefix is identity syntax, not signing authority.

Canonical principal

Since tulpa:zKEY and ink:zKEY are the same actor, a receiver MUST collapse them to a single, prefix-independent principal before making any security decision. All per-sender state — block lists, rate limits, duplicate-payload checks, cached verification keys, and connection identity — MUST key on that principal, never on the raw agentId string. Otherwise a sender could switch prefix to dodge a block or split a rate-limit window. DIDs (did:web:…, did:plc:…) are their own principal and are never aliased.

Trust Hierarchy

The Binding Record (network.tulpa.agentLink)

An agent’s authority is derived from a public record in the user’s PDS. The agentLink provides key material and delegation proof, it does NOT provide endpoint discovery (see Discovery).

• Collection: network.tulpa.agentLink
• Ownership: Self-signed by the human DID.
• Fields:
  • agentId: unique internal identifier for the agent instance.
  • signingKeyMultibase: Ed25519 public key used for INK message signing.
  • encryptionKeyMultibase: X25519 public key used for payload encryption and key agreement.
  • createdAt: ISO 8601 timestamp.

Delegation Proof

Agent delegation is proven by the agentLink record’s ATP repo commit signature, the same mechanism that authenticates all PDS record writes. Because the agentLink is written to the user’s own PDS repo, the repo’s rotating signing key already signs the commit that contains it. No additional proof field is needed.

A verifying agent MUST:

1. Resolve the sender’s DID → locate the agentLink record in their PDS via standard ATP record resolution.
2. Confirm the record is present in the current repo state. If the record exists at the current repo head, it is valid.
3. Confirm the agentId and key material in the record match the sender’s INK message.

In the default (PDS-trusting) mode, verifiers need not independently verify historical commit signatures or inspect the commit graph. ATP record resolution from the current repo head is the correct verification primitive.

PDS Trust Boundary

INK’s delegation model relies on the PDS to faithfully resolve records from the user’s repo. This means INK inherits ATP’s trust assumptions.

Threat model: A compromised or malicious PDS could serve a forged agentLink record, allowing an unauthorized agent to impersonate the user within INK.

Mitigations:

1. DID-anchored verification. The DID’s signing key is anchored in the DID document (resolved via PLC or web DID methods), not controlled by the PDS. Implementations MAY independently verify that the repo’s signing key matches a key authorized by the DID document.
2. Caching and cross-verification. Agents SHOULD cache resolved agentLink records and MAY cross-verify against multiple resolution paths.
3. Key pinning. After first successful verification, agents MAY pin the signingKeyMultibase for a DID and alert on unexpected changes.
4. Future: signed record proofs. When ATP content-addressed record proofs become available, INK implementations SHOULD adopt them.

Implementations MUST document which trust level they operate at.

Key Model

INK uses two distinct key pairs per agent:

Purpose	Algorithm	Published in agentLink	Usage
Signing	Ed25519	signingKeyMultibase	Sign all outbound INK messages, verify inbound messages
Key Agreement	X25519	encryptionKeyMultibase	ECDH key agreement for payload encryption

Ed25519 and X25519 are related curves but are NOT interchangeable. Implementations MUST maintain separate key pairs and MUST NOT derive one from the other.