A namespace that is self-certifying and self-administrating, containing a self-certifying prefix that provides cryptographic verification of root control authority. All derived AIDs within the same autonomic namespace share the same root-of-trust, source-of-truth, and locus-of-control (RSL), with governance unified under the controller holding root authority.
Related Concepts
No related concepts available
Comprehensive Explanation
autonomic-namespace
Conceptual Definition
An autonomic namespace (AN) represents a fundamental architectural concept in KERI that establishes a cryptographically verifiable, self-governing domain for identifiers. The term "autonomic" derives from "auto nomos" (Greek for "self rule"), emphasizing the namespace's self-managing and self-administrating properties.
The core innovation of autonomic namespaces lies in their self-certifying prefix—a cryptographic identifier that enables anyone to verify the root control authority over the namespace using cryptography alone, without relying on external certificate authorities, registries, or trusted third parties. This self-certifying property eliminates the need for administrative intermediaries in establishing namespace authority.
A critical architectural principle is that all derived AIDs (Autonomic Identifiers) within the same AN share three unified properties:
Root-of-trust: The cryptographic foundation for verification
Source-of-truth: The authoritative source for namespace information
Locus-of-control: The point of control authority
These three properties are collectively referred to as RSL and represent the unified governance model of autonomic namespaces. The governance is consolidated into a single entity—the controller who holds root authority over the namespace—creating a cryptographically verifiable hierarchy where namespace control can be independently verified without external trust anchors.
Historical Context
Implementation Notes
Governance Considerations
Root Authority Management: The root controller of an autonomic namespace holds ultimate authority and must implement appropriate security measures:
Multi-signature schemes for root key operations
Hardware security modules (HSMs) for root key storage
Formal procedures for root key rotation
Disaster recovery planning for root key compromise
Delegation Policies: Organizations implementing autonomic namespaces should establish:
Clear policies for when and how delegation is granted
Criteria for delegate qualification and authorization
Procedures for delegation revocation
Monitoring and auditing of delegated authority usage
Namespace Design: When designing autonomic namespace hierarchies:
Consider organizational structure and authority flows
Plan for future growth and reorganization
Balance security requirements across hierarchy levels
Document delegation relationships and governance policies
Compromise Isolation: The hierarchical structure enables:
Revocation of compromised delegated identifiers
Traditional namespace systems rely on administrative trust models where centralized authorities manage identifier-to-key bindings:
DNS/Certificate Authority Model: The Domain Name System combined with Certificate Authorities represents the dominant namespace model for the internet. In this architecture:
Certificate Authorities serve as trusted third parties that vouch for identifier-to-key bindings
Namespace control depends on organizational policies and procedures
Verification requires trusting the CA infrastructure
Compromise of CA private keys can affect all identifiers under that authority
Namespace control is established through consensus algorithms
Identifiers are locked to specific blockchain infrastructure
Verification requires participation in or trust of the consensus mechanism
Portability is limited by dependence on the underlying ledger
Hierarchical PKI: Traditional Public Key Infrastructure uses hierarchical trust chains:
Root CAs delegate authority to intermediate CAs
Each level in the hierarchy requires trust in the parent authority
Revocation and key rotation create complex operational challenges
The trust model is fundamentally centralized despite distributed implementation
These traditional approaches share a common limitation: namespace authority cannot be verified through cryptography alone. Verification requires trusting external infrastructure, whether administrative (CAs), algorithmic (blockchains), or hierarchical (PKI chains).
KERI's Approach
KERI introduces autonomic namespaces as a cryptographic trust model that eliminates dependence on external authorities:
Self-Certifying Prefix Architecture
The autonomic namespace begins with a self-certifying identifier prefix derived from cryptographic key material through one-way functions. This prefix serves as the root of the namespace and provides:
Cryptographic Derivation: The prefix is generated from the controller's public key(s) using cryptographic hash functions, creating an identifier that is mathematically bound to the controlling key pair. Anyone can verify this binding by recomputing the derivation.
Inception Event Binding: The prefix is further bound to an inception event that establishes the initial key state and configuration. This event includes:
Current signing keys
Pre-rotated next key digests (for forward security)
Witness configuration
Threshold requirements
Other governance parameters
Key Event Log Foundation: The namespace's authority is maintained through a Key Event Log (KEL)—an append-only, cryptographically chained data structure that records all key state changes. The KEL provides:
Verifiable history of control authority
Duplicity detection capabilities
End-to-end verifiability without trusted intermediaries
Unified RSL Properties
The autonomic namespace architecture ensures that all derived AIDs share unified governance:
Root-of-Trust Unification: Every AID within the namespace traces its cryptographic verification back to the same root prefix. This creates a verifiable trust chain where:
The root prefix establishes the cryptographic foundation
Derived AIDs inherit this foundation through delegation mechanisms
Verification of any derived AID ultimately validates against the root
Source-of-Truth Consolidation: The namespace maintains a single authoritative source for all identifier state:
The root controller's KEL serves as the definitive record
Delegated AIDs reference the delegator's KEL for authorization
No external registries or databases are required
The source-of-truth is portable and self-contained
Locus-of-Control Centralization: Control authority is unified under the root controller:
The root controller holds ultimate authority over the namespace
Delegation enables distributed operations while maintaining root authority
Revocation of delegated authority flows from the root
The governance model is hierarchical but cryptographically verifiable
Coordination requirements between delegator and delegate
Witness Infrastructure: While portable, autonomic namespaces require:
Witness infrastructure for indirect mode operation
Coordination of witness pools
Monitoring of witness availability and reliability
Backup and redundancy planning
Despite these considerations, autonomic namespaces represent a fundamental advancement in identifier systems, providing cryptographically verifiable, portable, and self-sovereign namespace management that eliminates dependence on external authorities while enabling scalable hierarchical governance.
Isolation of compromise to specific branches
Recovery without affecting uncompromised portions
Maintenance of namespace integrity despite localized failures