Identity & Binding

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

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.