Every entity except a root has a parent. Lineage is the unbroken chain of cryptographic proofs from any entity back to a human root — the mechanism that makes a human accountable for everything an agent does, without a phone call home for every check. Lineage verification has been hardened so that only typed authorizing APIs establish authority. Shape-only (structural) checks remain internal and never authorize a privileged path.

​
Authorizing surface

Use the typed lineage verification APIs in each SDK language (for example Rust verify_lineage with VerifyConfig, TypeScript/Python/Go/Swift/Kotlin typed verify-request equivalents). Those APIs:
  • select parent keys from validated parent DID documents (not from the proof’s embedded key alone);
  • require verifier-supplied trust anchors for human roots;
  • bind proof type, algorithm, canonicalization, proof purpose, parent and child verification methods and keys, derivation path, and generation;
  • reject legacy unbound three-field proofs as non-authorizing.
Structural / shape-only prechecks may run inside the authorizing verifier. They are not a public authorizing API and must not be treated as a privilege gate.

​
The proof chain

Each parent-child pair is bound by an AgentLineageProof2025: the parent’s Ed25519 signature over a fully bound canonical payload, with the HKDF-SHA256 derivation path recorded. The lineage section of a document carries:
  • humanRootDid — the ultimate root (HMR, MHR, or ENR)
  • creatorDid — the direct parent
  • generation — derivation steps from the root (0 = direct child)
  • derivationProof — the signed link
  • humanRootChain — ordered DIDs from this entity to the root
  • orgInclusionProof — optional Merkle proof binding this entity to the creator’s org root
  • anchorRefs — optional anchor references (see anchors)
Authorizing verification walks the resolved chain from child to root, checking each signature against externally validated parent keys and verifier trust policy.

​
Verification rules

  • Typed authorization — only the typed verify APIs may authorize; structural prechecks never grant privilege
  • Chain completeness — every link must resolve; a broken link means rejection
  • Key binding — the proof’s parent key must match the key authorized on the parent document (capabilityDelegation); child keys bind to the child document
  • Generation consistency — generation equals chain length minus one
  • Human root termination — the chain must end at hmr, mhr, or enr present in the verifier’s trust anchors (ENR chains additionally verify the governance section)
  • Immutability — lineage never changes after establishment; rotation is a new document, not an edit
  • Revocation cascades — a revoked ancestor poisons the whole tree below it

​
Derivation

Child identities derive deterministically: HKDF-SHA256 from the parent key plus a derivation path (BIP-44/SLIP-0010 conventions). The derived key signs nothing until the parent signs the lineage proof binding the child to the chain — proof first, use second. Public verifiers do not recompute child secret material from a parent public key. Authorizing verification checks the signed, fully bound proof against resolved documents and trust policy.

​
Org inclusion

Entities created under an organization (MHR/ENR) bind to the org’s lineage root with a Merkle inclusion proof: the org commits a root over its members, and each entity carries its path. When the anchor backend has an OrgLineageRoot for the creator, the proof is required at resolution; when it has none (e.g., an HMR creator), the check is skipped — present versus absent is data, not policy.

​
Proofs offline, authority anchored

A complete, signature-valid chain proves structure under the authorizing verifier contract. It cannot prove the negative: that the root was ever registered, or that nothing in the chain has been revoked or superseded since. That answer is authority, and it comes from the anchor backend.
  • Cryptographic checks can run offline when documents and anchors are bundled.
  • Privileged paths — sessions, credentials, org membership, wallet authority — require the anchor’s answer too, and fail closed when there is none.
  • Trusted anchor schemes are verifier policy (anchor policy); documents declare refs, verifiers choose.
A syntactically valid HMR (or other root) is a cryptographic control surface. It is not by itself a personhood, legal-identity, uniqueness, or Sybil-resistance attestation. Those claims, when needed, come from external assurance credentials under verifier-owned policy.

​
Depth and performance

Chains are capped (recommended default MAX_GENERATION = 16, spec minimum support 10): verification is sequential resolution of ancestors, so pathologically deep chains degrade every verifier that meets them. Timeouts are enforced per-resolution (5s) and per-chain (30s) — a timeout reports unverifiable, never invalid.

​
Next