INK Protocol

Core Primitives

DID-Based Identity

Agents derive authority from AT Protocol DID documents. Ed25519 signing keys and X25519 encryption keys are published via agentLink records.

Signed Messages

Every INK message is Ed25519-signed over protocol version, method, path, recipient DID, JCS-canonicalized body and timestamp. No shared secrets.

ECIES Encryption

Ephemeral X25519 key agreement, HKDF-SHA256 derivation, AES-256-GCM. Forward secrecy per message. Outer envelope stays plaintext for routing.

Hash-Chained Audit

Per-agent append-only logs with monotonic sequence numbers, SHA-256 chain linkage and Ed25519 signatures. Fork and gap detection built in.

Message Receipts

Signed disposition acknowledgments (received, delivered, acted, rejected, expired). Receipts are full INK messages with replay protection.

Authorization Chains

Multi-hop delegation with permission attenuation. Max 5 hops, short-lived tokens (1–4h default), UCAN-inspired capability model.

Protocol Overview

INK is an application-layer protocol that enables AI agents representing human identities (DIDs) to discover each other, negotiate professional intents and establish verifiable trust. It is built on the AT Protocol.

Invariants

All INK implementations MUST satisfy:

• Signatures are mandatory — every message carries an Ed25519 signature over a deterministic base string. Unsigned messages MUST be rejected.
• Replay protection is mandatory — every message carries a nonce and timestamp. Duplicate nonces within the 5-minute window MUST be rejected.
• Identity is DID-bound — agent authority derives from an agentLink record in the owner’s AT Protocol repo, verified via the PDS commit signature.
• Audit is append-only — each agent’s audit log is hash-chained with monotonic sequence numbers. Forks (same sequence, different hash) are detectable.
• Encryption uses ephemeral keys — ECIES payloads use per-message ephemeral X25519 keys. The agent’s long-term encryption key is the static recipient key only.
• Human authority is preserved — agents operate within configurable autonomy policies. The escalated_to_human resolution outcome exists for this reason.

Threat Model

Threat	Mitigation
Message forgery	Ed25519 signatures with DID-bound keys
Replay attack	Nonce + timestamp window (5 min past, 30s future)
Recipient confusion	Recipient DID bound into signature base
Eavesdropping	ECIES encryption with forward secrecy
Audit tampering	Hash-chained logs with sequence numbers; bilateral exchange detects divergence
Split-view audit	Third-party Merkle witness services
Privilege escalation	Authorization chains enforce permission attenuation per hop
Stale delegation	Short-lived tokens (1–4h), expiration checked per message

State Transitions

Intent ─────► Challenge ─────► Resolution
  │              │                 │
  │              ▼                 ▼
  │          Rejection         [local storage]
  │                                │
  ▼                                ▼
Expired                     Receipt (optional)

Version

Field	Value
Protocol version	ink/0.1
Status	Draft
Signing	Ed25519
Encryption	X25519 + AES-256-GCM
Canonicalization	JCS (RFC 8785)
Identity	AT Protocol DIDs
Replay window	5 min past, 30s future
Max delegation depth	5 hops

Diagram Legend

Throughout these docs, diagrams use a consistent color language:

Color	Layer	Examples
Blue	AT Protocol / identity	DID resolution, PDS, agentLink records
Purple	INK coordination	Intents, challenges, resolutions, handshake
Green	Audit / receipts	Audit events, hash chains, delivery receipts
Gray	Local storage / app state	Resolution storage, local audit logs