ACT — Agent Capability Token. A short-lived, cryptographically signed token issued by Arsenal granting an agent specific capabilities for a bounded duration. Proof-of-possession binding, scoped to minimum permissions, one canonical wire format. See ACT tokens. AEGIS — Identity Verification and Authorization Framework. Implements the verification pipeline, challenge-response auth, delegation trees, and multi-dimensional policy enforcement. Between OAS and Arsenal in the stack. Anchor (LineageAnchor) — the backend supplying lineage authority: proof that a root exists, that nothing in a chain is revoked or superseded, and that the answer is final. Pluggable: Sigil GAL is the reference backend; EAS, transparency logs, or institutional notaries can stand in via the anchor policy. Anchor Reference (anchorRefs) — a document-carried pointer to an anchor: { scheme, locator, inclusionProof? }, namespaced (anchor:sigil:…, anchor:eas:…). Unknown schemes are additive, never breaking. Arsenal — Agent Key Management and Credential Proxy. Issues ACTs, manages an 11-step credential proxy pipeline with SSRF guards, provides human-in-the-loop consent. Platform-agnostic credential injection for any HTTP API. BLAKE3 — Cryptographic hash function for content hashing, Merkle trees, and content addressing in OAS. 256-bit output, significantly faster than SHA-256 with equivalent security. Used for document integrity and audit chains. Capability — A scoped, time-bounded permission granted to an entity, expressed as ACTs that can be delegated but never amplified. Least privilege applies at every level. Conformance Level — Graduated measure of implementation completeness. L0: identifier parsing. L1: signature verification. L2: anchored lineage path verification. L3: full operations including creation, delegation, revocation, and FROST. Core Protocol — The OpenAgent Core Protocol: transport-agnostic challenge-response authentication. An agent proves its identity by signing a server-issued challenge; no pre-registration, API keys, or OAuth flows. The one normative authentication protocol. Credential Proxy — Arsenal’s 11-step pipeline for secure credential injection into HTTP requests on behalf of agents: SSRF guards, DNS rebinding protection, request validation, credential retrieval, hash-chained audit logging. DID — Decentralized Identifier. Globally unique, self-sovereign, W3C-specified. In OAS: did:oas:<namespace>:<kind>:<identifier>, derived from an Ed25519 public key. Self-certifying, verifiable without any registry. DID Document — JSON document describing the entity behind a DID: verification methods (public keys), service endpoints, and metadata. Self-signed by the controller, extended with OAS entity kind and lineage fields. DID Resolution — Converting a DID string into its DID Document via the 8-stage pipeline: parse, cache, resolve, validate, verify, revocation, lineage, return. Designed for offline use when cached. Delegation — Granting a subset of capabilities to another entity via signed proofs. Each delegation narrows the parent’s capabilities; time-bounded and subject to the no-amplification rule. Ed25519 — Elliptic curve signature algorithm (EdDSA) for all OAS signatures. 64-byte signatures from 32-byte keys. Fast, timing-resistant, formally verified. RFC 8032. ENR — Enterprise Root. Entity kind representing an organizational entity governed by corporate policy. Trust anchor for enterprise deployments; delegates to agents, tools, and services. Entity Kind — One of 11 classifications encoded in the DID string. Roots (HMR, MHR, ENR) are trust anchors. Non-roots (Agent, Tool, Skill, Workflow, Model, Dataset, Service, Agent Instance) represent ecosystem roles. FROST — Flexible Round-Optimized Schnorr Threshold signatures. t-of-n key generation and signing for MHR entities; no single holder of the complete key. Ceremonies use Noise XX transport. HKDF — HMAC-based Key Derivation Function (RFC 5869). OAS uses HKDF-SHA256 for deterministic child key derivation: parent key + path produces child key pair. BIP-44/SLIP-0010 conventions. HMR — Human Root. Fundamental trust anchor representing a single human. Every lineage chain terminates at one. Provides human accountability for all downstream autonomous actions. JCS — JSON Canonicalization Scheme (RFC 8785). Deterministic JSON serialization ensuring the same logical document always produces identical bytes for signature computation. Lineage Chain — Unbroken sequence of signed proofs tracing an entity to a Human Root. Each proof: parent DID, child DID, purpose, constraints, signature. Ensures human accountability. Lineage Proof — Single signed attestation in a lineage chain: parent/child DIDs, purpose (creation/delegation/authorization), constraints, and an Ed25519 parent signature. Verified recursively. MHR — Multi-Human Root. Entity kind using FROST threshold signatures for t-of-n governance. Critical operations require a threshold of participant signatures without any single key holder. Multibase — Encoding format prefixing data with a character identifying the scheme. OAS uses the z prefix (base58btc) for Ed25519 public keys; multicodec prefix 0xed01 identifies the key type. No-Amplification Rule — Security invariant: a child entity can never possess more capabilities than its parent. Every delegation must narrow or equal the parent’s capabilities. Prevents privilege escalation. Resolver — Component implementing DID resolution: the 8-stage pipeline with multiple transport backends (HTTP, DHT, direct), a local cache with configurable TTLs, and negative caching. Revocation — Invalidating a DID, delegation, or credential. DID: deactivated flag. Delegations: sparse Merkle trees with cascading. Credentials: issuer-published revocation lists and superseding attestations. Service Endpoint — URL or address in a DID Document for interacting with the entity: API endpoints, messaging addresses, resolution endpoints, or any network-accessible resource. Sparse Merkle Tree — Data structure for efficient revocation checking: inclusion and exclusion proofs for a large key space with logarithmic proof sizes. Used for delegation and credential status. Threshold Signing — t-of-n participants required for a valid signature. OAS uses FROST for MHR; the resulting signature is indistinguishable from standard Ed25519.