Everything in OpenAgent reduces to six ideas. Once these click, the rest of the documentation is combinations of them.

DIDs — identity without a registry

Decentralized Identifiers are cryptographically verifiable and decoupled from any centralized account system. OAS defines the independently published did:oas method against the W3C DID Core data model. Document signatures and fully bound lineage proofs can be checked from bundled evidence without a live network path; privileged authority still requires verifier trust anchors and fail-closed freshness policy.
  • Independently published did:oas method (designed against W3C DID Core; not a W3C endorsement or registry listing claim)
  • Ed25519 document signatures with deterministic canonicalization
  • Offline cryptographic checks when documents and anchors are bundled

Verifiable Credentials — claims that check out

Tamper-evident, cryptographically signed claims about an entity, verifiable by any party independently. OAS follows the W3C VC Data Model; verification is self-contained through the issuer’s DID Document, and revocation uses sparse Merkle trees. Agent-specific claim types cover capabilities, lineage, and conformance.
  • W3C VC Data Model
  • Self-contained verification via the issuer DID Document
  • Revocation via sparse Merkle trees
  • Agent claim types: capabilities, lineage, conformance

Lineage Chains — accountability, provably

Cryptographic proof chains tracing every agent back to a human root, so a human is accountable for everything an agent does. Authorizing verification uses typed verify APIs with verifier-supplied trust anchors; structural prechecks are internal and never authorize privilege.
  • Unbroken chain from agent to Human Root (HMR / MHR / ENR)
  • Fully bound proofs verified through typed authorizing APIs
  • Recursive verification at every level against resolved documents
  • Configurable max depth (recommended default: 8)
Cryptographic checks can run offline from bundled evidence. Authority — that the root is trusted and nothing is revoked — comes from an anchor backend and verifier policy: see lineage and the anchor policy. A valid root DID is not by itself a personhood or Sybil-resistance attestation.

Entity Kinds — eleven participants, one grammar

Eleven distinct entity types represent every participant in the agent ecosystem. The kind is encoded directly in the DID string, which binds type to identity at the syntax level and determines verification requirements and capability scoping.
  • HMR, MHR, ENR: trust-anchor root entities (single human, multi-human, organizational)
  • Agent, Tool, Skill, Workflow, Model, Dataset, Service, Agent Instance: derived entities
  • The DID string itself names the kind

Conformance — graduated verification

A graduated verification system from basic identity to full cryptographic verification:
  • L0: identifier parsing only
  • L1: Ed25519 signature verification
  • L2: anchored lineage path verification (anchor-backed; Sigil is the reference backend, and any LineageAnchor backend — EAS, a transparency log — can stand in)
  • L3: complete OAS operations, including FROST threshold

Crypto Primitives — a deliberately small suite

A carefully chosen set of primitives for identity, derivation, hashing, and threshold operations. Small on purpose: every additional primitive is a new way to be wrong.
  • Ed25519: 64-byte signatures, constant-time, formally verified
  • HKDF-SHA256: deterministic hierarchical key derivation
  • BLAKE3: 256-bit content hashing for integrity and addressing
  • FROST: t-of-n threshold signing for Multi-Human Roots

How these connect

DIDs × Entity Kinds. The entity kind is encoded directly in the DID string, binding type to identity at the syntax level. Lineage Chains × Conformance. Level 2 conformance requires the ability to verify complete lineage chains recursively — plus an anchor’s answer that the root exists and nothing is revoked. Crypto Primitives × Verifiable Credentials. Ed25519 signs credentials, BLAKE3 hashes content, HKDF derives issuer sub-keys.

Next