Skip to content
Tenzro
← All posts
Blog

TDIP: one identity protocol for humans and machines

Humans, delegated agents and autonomous agents under one W3C DID method, with keys rooted in passkeys and device hardware. Why agents need an identity of their own.

Tenzro Foundation

An agent that acts on your behalf needs more than an API key. It needs an identity: something a counterparty can verify, something the chain can authorise, and something that carries the limits its controller set. The Tenzro Decentralized Identity Protocol (TDIP) gives humans and machines the same shape: a DID, keys rooted in hardware, verifiable credentials and a delegation scope.

Three classes, one protocol

Human. A did:tenzro:human: identifier, derived from the person's passkey. It carries a display name, a verification tier and the list of machines the person controls.

Delegated agent. A did:tenzro:machine: identifier that names a controller. It carries capabilities, the controller's DID, a delegation scope and a reputation. It acts on behalf of a named person or organisation.

Autonomous agent. The same shape with no controller. It acts as a principal in its own right.

The difference between delegated and autonomous matters for policy enforcement, so it is explicit in every identity document.

Keys rooted in hardware

Every identity's keys are rooted in hardware. A person's identity is derived from a passkey with user verification required. A machine's identity is derived from the device key in its TPM 2.0 or Secure Enclave. There are no key files and no seed phrases.

Every passkey operation is a hybrid P-256 plus ML-DSA-65 signature, so identities are ready for a post-quantum world. People can link more devices to the same identity, and recover access with a second passkey or with guardians under a timelock and veto. Synced passkeys are accepted at a lower tier and are never the sole root of an account. See Device linking and recovery.

The account is bound to the DID, so the identity registry is the canonical lookup: pass a DID, get back the address.

Delegation scope

The part that matters most for agents is the delegation scope. It is structured, not a free-form access list:

  • max_transaction_value
  • max_daily_spend
  • allowed_operations: typed verbs
  • allowed_contracts: an address allowlist
  • allowed_payment_protocols: for example x402, MPP or AP2
  • allowed_chains: CAIP-2 identifiers
  • time_bound: not-before and not-after

Every payment an agent makes is checked against its scope, and a violation is rejected with a typed reason. ERC-7579 validator modules on the agent's smart account, such as session keys and spending limits, enforce the same limits at signing time, so an agent that skips an off-chain check is still stopped on chain. See Smart account policies.

W3C interop

TDIP exports W3C DID Documents and W3C Verifiable Credentials, and did:tenzro resolves through a standard universal resolver endpoint. Revocation cascades, trust chains are walked with cycle detection, and verification tiers change only on presentation of a valid credential. See Credentials.