Skip to content
Get started
Open Agent Specificationv1.2.0

The
Specification

A DID-based identity framework for autonomous agents, designed against W3C DID Core. DID method, 12 entity kinds, cryptographic lineage and document conformance profiles. The current SDK accepts approved owned or self roots; historical human-root profiles are not universal access tiers.

Read full specOpen SDK source
scroll to read
Developer toolsSmall pieces. A complete developer path.
§ 01
DID method

One URI,
four decisions.

The did:oas method defines a cryptographically signed identifier format for autonomous agents and their related entities.

Normative grammar in the DID Method chapter.

Fig. 01did:oas URI, decoded
did:oas:<namespace>:<kind>:<identifier>
Method

Always oas. Identifies this DID as conforming to the Open Agent Specification.

Namespace

The issuing authority or network. Examples: l1fe, acme, self.

Entity kind

One of 12 defined kinds. Determines the entity's role, capabilities, and lineage requirements.

Identifier

Globally unique identifier. Derived from the public key via multibase (base58btc) encoding.

Cryptographic foundation

Four fixed primitives. No algorithm negotiation, no downgrade surface.

SigningEd25519
Key derivationHKDF-SHA256
HashingBLAKE3
CanonicalizationJCS
§ 02
Taxonomy

12 kinds of entity

Every participant in the agent ecosystem has a typed identity. Three kinds are accountability roots; the other nine carry cryptographic lineage back to them.

Full URI patterns and lineage rules — entity kinds

01hmrrootHuman RootA single human-root keyholder — the lineage terminus (not a personhood attestation)
02mhrrootMulti-Human RootA threshold group of human-root keyholders (t-of-n) via FROST signatures
03enrrootEnterprise RootStable corporate identity governed by a rotating MHR
04aoAutonomous OrganizationAgents, tools, and workflows operating as a coherent unit
05agentAgentAutonomous software entity with independent decision-making
06agent:instanceAgent InstanceA specific running instance of an agent, identified by UUID
07toolToolA capability agents invoke to reach external systems
08skillSkillA composable, reusable unit of agent behavior
09workflowWorkflowA defined process executed by one or more agents
10modelModelA machine learning model with verified provenance
11datasetDatasetA data collection with verified provenance and lineage
12serviceServiceInfrastructure — compute, storage, networking — with verified identity
§ 03
Conformance

Three levels.
Each one adds.

Progressive identity maturity: start with a basic self-signed identity, add human accountability, then anchor it. Levels are strict supersets — what each level adds is the whole story.

Requirements in full — conformance levels

L0

Basic Identity

Minimum viable identity

A valid OAS Identity Document with a valid did:oas URI
At least one Ed25519 verification method
A valid entity kind from the 12-kind taxonomy
A self-signed document — signed by a key the document lists
L1⊇ L0

Accountable Identity

Historical owned-document profile

Owned-document profile: a complete chain to its active owner root
A valid humanRootDid
AgentLineageProof2025 at every link of the chain
Local signature checks plus fresh required authority and revocation
L2⊇ L1

Full Identity

Anchored and independently attested

The identity document hash anchored on a public ledger
At least one third-party attestation as a W3C Verifiable Credential
The attestation anchored the same way — tamper-evident, externally vouched
§ 04
Lineage

Every verifier chooses its trust roots

Owned identities carry a cryptographic path to their owner. The current SDK also accepts explicitly trusted self roots. Signatures prove integrity; receiver policy determines authority.

Derivation chain

Human root
did:oas:l1fe:hmr:alice
HKDF-SHA256-Ed25519 ( parent_key, "/agent-analyzer" ) → child_key
Agent
did:oas:l1fe:agent:analyzer
key z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK

The child key is derived from the parent key and the derivation path — so the proof binds mathematics, not paperwork. A verifier replays the derivation and checks the signature. No registry required.

AgentLineageProof2025 · wire format
{
  "type": "AgentLineageProof2025",
  "parentDid": "did:oas:l1fe:hmr:alice",
  "childDid": "did:oas:l1fe:agent:analyzer",
  "derivationPath": "/agent-analyzer",
  "algorithm": "HKDF-SHA256-Ed25519",
  "publicKeyMultibase": "z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK",
  "signature": "iQF3Bw6r8mVbq1t...9Rax7Qw"
}

Cryptographic checks can run from bundled evidence; privileged authority still requires typed lineage verification and verifier trust anchors.

Design property · authorizing verification
§ 05
Contents

Explore the specification

Each part of the spec has its own deep dive — the method, the taxonomy, the lineage math, the primitives, and the levels.

DID MethodThe five-segment did:oas URI, decoded, plus the full CRUD lifecycle.Entity KindsAll 12 typed identities, their URI patterns, and their lineage rules.Lineage ModelHKDF-SHA256 derivation chains from atomic key to organizational scale.CryptographyEd25519, BLAKE3, HKDF-SHA256, JCS, and FROST — and why only these.ConformanceThree graduated levels from basic identity to anchored attestation.ChangelogEvery normative revision, from the initial release to v1.2.0.