DIDs — identity without a registry
Decentralized Identifiers are cryptographically verifiable and decoupled from any centralized account system. OAS defines the independently publisheddid: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:oasmethod (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)
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
LineageAnchorbackend — 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
- Key management — the custody lifecycle
- OAS overview — the specification these ideas form
- Anchors — where authority comes from