Level 0 — Cryptographic Primitives
The cryptographic bedrock. Deliberately small: every additional primitive is a new way to be wrong.- Ed25519 (RFC 8032) — signatures
- SHA-256 (HKDF extraction) — key derivation
- BLAKE3 — content hashing
- JCS (RFC 8785) — canonical JSON serialization
- Noise XX — transport during FROST ceremonies
- Multibase / Multicodec — key encoding
Level 1 — Key Management
Ed25519 key generation and management, HKDF-SHA256 hierarchical derivation, BIP-44/SLIP-0010 derivation paths, and FROST threshold signing for multi-human roots. All key material usesZeroizeOnDrop; all signing is
constant-time. See key management.
- Ed25519 key pairs
- HKDF-SHA256 derivation
- BIP-44 / SLIP-0010 paths
- FROST threshold DKG
ZeroizeOnDropkey material- Constant-time operations
Level 2 — Identity (OAS)
The Open Agent Specification itself: a W3C DID-based identity standard defining thedid:oas method, 11 entity kinds, the lineage claim model,
the DID Document structure, and conformance levels. Fully vendor-neutral —
the spec contains zero product imports.
did:oasmethod specification- 11 entity kinds
- Lineage claim model
- DID Document schema
- Conformance level system
- Vendor-neutral standard
Level 3 — Lineage Authority
Canonical lineage authority for privileged operations: root anchors, org lineage roots, revocation records, and finalized block state, so verifiers can confirm authority paths across humans, agents, organizations, and services. Lineage proofs verify offline at level 2; this level answers “does the root exist, and is anything revoked?” The backend is pluggable through theLineageAnchor trait: Sigil GAL
is the reference backend (typed edges, shard topology, publisher bonds,
generation-decay economics), and any conforming backend — EAS, a
transparency log, an institutional notary — can stand in via the
anchor policy.
- Typed lineage edges
- HMR / MHR / ENR anchors
- Org lineage roots
- Revocation-first reads
- Finalized block sequence
- Anchor references in the document (
anchorRefs)
Level 4 — Verification & Policy (AEGIS)
Identity verification and authorization: resolves OAS documents, reconstructs required authority paths from the anchor backend, performs challenge-response authentication, and enforces multi-dimensional policy under the no-amplification rule.- 7-step verification pipeline
- Challenge-response auth
- Anchored lineage verification
- No-amplification rule
- Multi-dimensional policy engine
- Revocation checking
Level 5 — Credentials & Access (Arsenal)
Agent key management and credential proxy. Issues Agent Capability Tokens (ACTs) with short TTLs against a canonical wire format, manages an 11-step credential proxy pipeline with SSRF guards, and provides human-in-the-loop consent.- Agent Capability Tokens (ACTs) — canonical format
- 11-step credential proxy
- SSRF guard (DNS rebinding protection)
- HITL consent service
- Hash-chained audit logging
- Platform-agnostic credential injection
Level 6 — Adapters & the SDK
HTTP, MCP, wallet, and runtime adapters consume the identity and capability contracts without becoming identity roots themselves — and the OpenAgent SDK is the front door over all of it, in six languages.- HTTP route guards (Express, FastAPI, Axum, net/http, Ktor)
- The Core Protocol challenge-response binding
@openagentid/sdk— façade, ACT verification, key custody- MCP and deployment adapters
- Conformance vectors gating every language
The load-bearing rules
- Vendor neutrality at level 2. OAS never imports a product. Products implement the standard; the standard never implements a product.
- Key material lives only at level 1. Everything above uses public keys, DIDs, and proofs.
- Authority is pluggable; proofs are not. Proof formats are frozen contracts; anchor backends are policy.
- One wire format per artifact. The ACT has exactly one canonical
encoding, owned by the
agent-capability-tokencrate, and every language is gated on the same vectors.
Next
- Core concepts — the six ideas these layers implement
- ACT tokens — level 5 in depth
- Anchors — level 3 in depth