Design Principles

INK’s design is guided by these principles, in priority order:

1. Self-Certifying Identity

The identity root is a key, held by the agent. An INK principal is either key-derived, a tulpa: or ink: agentId whose multibase tail is the agent’s genesis Ed25519 key, or a did:web identity whose DID document roots the key. A key-derived principal identifies exactly the holder of the embedded private key and nothing else: there is no directory, registry or issuer behind it, creating one needs nobody’s permission and no third party can revoke one.

Binding an agent to a human owner is a separate, optional layer. INK defines no proof over it, a verifier MUST NOT authorize on a card’s owner fields and no counterparty may be required to carry one. See Identity & Binding.

The cost is stated where the benefit is: a key-derived identity is exactly as unrecoverable as its key material, and INK will not tell you which human is behind an agent.

2. Cryptographic Verifiability

Trust claims are provable, not asserted. Ed25519 signatures bind every message to a specific agent. Hash-chained audit logs make tampering detectable. ECIES encryption keeps sensitive payloads confidential in transit; it is ephemeral-static against the recipient’s long-term key, so it is not forward secrecy and is not claimed as such. See Encryption.

3. Bilateral Accountability

Both parties in a INK exchange can independently verify what happened. Signed receipts, hash-chained audit events and mutual audit exchange create a shared, non-repudiable record of the interaction.

4. Progressive Trust

INK does not require pre-existing trust. Agents can coordinate with strangers through the handshake protocol, and a receiver builds confidence in a sender from its own interaction history rather than from anything the protocol asserts.

5. Privacy by Default

Sensitive data is encrypted in transit. Audit trails are access-controlled (only message parties can query). Third-party audit witnesses see only tree hashes, never content.

6. Graceful Degradation

Every extension (receipts, audit exchange, authorization chains, third-party audit) is optional. A minimal INK implementation needs only the core handshake. Agents advertise capabilities in their Agent Card and respect what the other party supports.

7. No Mandatory Substrate

Participation requires a keypair and an HTTP endpoint. INK mandates no network to join, no registry to appear in and no directory to resolve through, because an identity layer that requires membership in one ecosystem puts that ecosystem’s governance, availability and account policy upstream of the protocol.

A deployment that already runs an identity system is free to reuse it. AT Protocol is one such integration, used for owner linkage, and did:web is another way to root keys. Both are layered on top of a protocol that works without either.