​
What is the Open Agent Specification?

OAS is a vendor-neutral, W3C DID-based identity standard for autonomous entities. It defines the did:oas method for creating, resolving, and verifying decentralized identifiers for agents, tools, models, services, and the humans who create them — portable cryptographic identity, lineage claims, and capability-scoped access contracts. Privileged authority is confirmed through a pluggable anchor backend (Sigil is the reference implementation).

​
How does OAS differ from other DID methods?

OAS is purpose-built for agents. While did:web, did:key, and did:ion provide general-purpose identity, OAS adds 11 entity kinds for the agent ecosystem, structured lineage claims, and a conformance-level system for declaring verification depth. In production trust paths, those claims must resolve to an anchored, finalized lineage before authority is accepted.

​
Is OAS truly vendor-neutral?

Yes. The specification and its SDKs contain zero product imports — the standard is the standard. Implementations (OpenAgentID and anyone else’s) plug into it, not the reverse.

​
What license is OAS published under?

The specification, documentation, reference SDKs, and OpenAgentID code are dual-licensed Apache-2.0 OR MIT under L1fe Labs, Inc. No patent encumbrances or royalty requirements for implementing the specification.

​
What are entity kinds and why do they matter?

OAS defines 11 entity kinds: HMR, MHR, ENR, Agent, Tool, Skill, Workflow, Model, Dataset, Service, and Agent Instance. Encoded in the DID string itself (did:oas:ns:agent:z6Mk…), they determine verification requirements, lifecycle rules, and capability scoping — verifiers classify entities before resolving.

​
What is a lineage chain and why is it required?

A lineage chain is the authority path connecting humans, agents, organizations, tools, and services: an unbroken sequence of signed proofs tracing an entity back to a human root, so a human is accountable for everything an agent does. Proofs verify offline; authority (the root exists, nothing is revoked) is confirmed against an anchor backend before any privileged action.

​
What cryptographic algorithms does OAS use?

Ed25519 for all signatures (fast, compact, formally verified), HKDF-SHA256 for hierarchical key derivation, BLAKE3 for content hashing, JCS (RFC 8785) for deterministic serialization, and FROST for threshold signing in MHR scenarios. All constant-time with zeroed key material.

​
Can OAS identities work offline?

Base identity checks work offline: a verifier can validate a DID Document, Ed25519 key, canonicalized payload, and signature with no network call. Privileged authority, revocation, and lineage-finality checks require an anchor backend answer — and fail closed when that state cannot be verified, because an unreachable anchor cannot prove the negative.

​
What is FROST and how is it used?

FROST (Flexible Round-Optimized Schnorr Threshold) enables t-of-n key generation and signing for Multi-Human Root (MHR) entities, where multiple humans share identity control. No single participant holds the complete key. Ceremonies use Noise XX transport.

​
How does key rotation work?

The old key signs a rotation proof authorizing the new key, and the DID Document is updated with the new verification method. The DID itself does not change. Old keys remain valid for historical verification, with a configurable grace period for verifiers to discover rotations.

​
What happens if a private key is lost?

Three recovery mechanisms: social recovery via pre-designated guardians (t-of-n threshold), FROST reconstruction from threshold shares for MHR entities, and HSM-backed recovery via hardware attestation. All rate-limited with audit trails.

​
What are conformance levels?

A graduated verification system. L0: parse DIDs, no crypto. L1: signature verification. L2: anchored lineage-path verification for privileged contexts. L3: complete OAS operations including lifecycle, anchored lineage proofs, delegation, revocation, and threshold signing. Implementations declare capabilities; verifiers set minimums.

​
How does OAS relate to AEGIS, Arsenal, and OATS?

OAS is the foundational identity layer. The anchor backend is the canonical lineage-authority layer (Sigil is the reference backend; EAS and others plug in). AEGIS verifies OAS documents against that authority and applies policy. Arsenal issues ACTs and manages credentials only after that verification. OATS adds trust and audit signals for reputation decisions.

​
Can I use OAS without the other layers?

Yes, for standalone identity: create DIDs, build Documents, sign, and verify using only the OAS SDK. Privileged OpenAgent services require the authority path to be anchored and verified before capabilities are issued.

​
What SDKs are available?

The OpenAgent SDK ships in six languages: TypeScript, Rust, Python, Go, Swift, and Kotlin — verify-first everywhere, full façade in TypeScript, Rust, and Python, and middleware in every language. Every SDK passes the same 13 canonical ACT conformance vectors in CI. See the quickstart and the libraries catalog.

​
How do I get started?

Verify an ACT in five minutes with act.verify() (or the Verifier in your language), guard a route with one middleware line, then create an agent and broker a credential when you need identity. The quickstart covers the complete path.