Historically, trust domains were established through administrative authorities such as:

• DNS/Certificate Authority (CA) systems: Organizations like DigiCert or Let's Encrypt serve as trusted third parties that bind domain names to public keys through X.509 certificates
• Corporate identity systems: Enterprise directories (Active Directory, LDAP) that define trust boundaries within organizations
• Federated identity: Systems like SAML or OAuth where identity providers establish trust domains that relying parties accept

These administrative trust domains suffer from several limitations:

• Centralized points of failure: Compromise of the authority compromises the entire domain
• Platform lock-in: Identifiers cannot be moved between trust domains without losing their trust properties
• Vulnerability to attacks: DNS hijacking and BGP hijacking can compromise domain verification
• Limited portability: Trust relationships don't transfer across organizational boundaries

Algorithmic Trust Domains

Blockchain and distributed ledger technologies introduced algorithmic trust domains where:

• Shared consensus: Trust is established through distributed agreement protocols
• Ledger-locked identifiers: Identifiers are bound to specific blockchain infrastructures
• Algorithmic verification: Trust derives from computational proof rather than institutional authority

While algorithmic trust domains provide stronger security than administrative approaches, they create new limitations:

• Infrastructure dependency: Identifiers cannot function independently of their originating ledger
• Scalability constraints: Global consensus mechanisms limit transaction throughput
• Governance challenges: Shared ledgers require coordinated governance across all participants

KERI's Approach

KERI introduces autonomic trust domains that fundamentally differ from both administrative and algorithmic approaches. The key innovation is establishing trust domains through cryptographic self-certification rather than external authorities or shared infrastructure.

Autonomic Trust Basis

KERI trust domains are built on Autonomic Identifiers (AIDs) that provide:

• Self-certifying root-of-trust: The identifier is cryptographically derived from the controller's key material
• Portable trust: Trust properties remain intact when moving between infrastructures
• Independent verification: Any party can verify statements without accessing shared infrastructure
• Key rotation support: Control authority can be transferred securely through pre-rotation

The autonomic trust basis creates what KERI terms a cryptographic root-of-trust—a foundation for trust that requires no external validation or shared consensus. This is achieved through:

1. Self-certifying identifier derivation: The identifier prefix is generated from public key material using one-way cryptographic functions
2. Key Event Logs (KELs): Append-only, cryptographically chained logs that prove the history of key state changes
3. Witness infrastructure: Designated entities that provide duplicity detection without requiring shared consensus
4. End-verifiable proofs: Any validator can independently verify the complete chain of control authority

Trust Domain Establishment

When an AID is created through an inception event, it simultaneously establishes a new trust domain. This trust domain:

• Encompasses all statements signed by the AID's controlling keys: Any message, credential, or transaction signed with the current authoritative keys belongs to this trust domain
• Extends through delegation: The AID controller can delegate authority to create sub-domains with their own identifiers
• Supports legitimized identifiers: Human-meaningful identifiers can be secured within the trust domain through legitimized human meaningful identifiers (LIDs)
• Enables credential chains: ACDCs (Authentic Chained Data Containers) can form verifiable chains within and across trust domains

Spanning Trust Domains

A critical advantage of KERI's approach is enabling trust spanning—the ability to establish verifiable trust relationships across different trust domains without requiring those domains to share infrastructure or governance. This is achieved through:

• Cryptographic verification: Trust can be verified through cryptographic proofs rather than institutional relationships
• OOBI (Out-Of-Band Introduction): Discovery mechanism that enables trust domain bridging
• Portable identifiers: AIDs maintain their trust properties when referenced from different domains
• Verifiable credential chains: ACDCs can create proof-of-authority chains that span multiple trust domains

The Trust Spanning Protocol (TSP) concept extends this further, envisioning a universal layer where every internet message carries cryptographic proof of its origin, effectively creating a global trust domain built from interoperable local trust domains.

Trust Domain Context

KERI recognizes that trust domains provide context for interpretation. The same identifier or credential may have different meanings or authority levels in different trust domains. For example:

• An aid|lid couplet where the AID establishes the trust domain and the LID provides human-meaningful context within that domain
• A vLEI credential that has specific meaning within the GLEIF trust domain but can be verified by parties outside that domain
• Delegated identifiers that inherit trust properties from their delegator's trust domain

Practical Implications

Use Cases

Enterprise Identity Management: Organizations can establish their own trust domains using KERI AIDs as root identifiers, then delegate authority to departments, systems, and individuals. Unlike traditional enterprise directories, these trust domains remain verifiable even when employees interact with external parties.

Supply Chain Verification: Each participant in a supply chain can operate within their own trust domain while creating verifiable links to other participants' domains through ACDC credential chains. This enables end-to-end provenance tracking without requiring all parties to use the same infrastructure.

Cross-Border Credentials: The GLEIF vLEI ecosystem demonstrates trust domains spanning jurisdictions. GLEIF establishes a root trust domain, delegates to Qualified vLEI Issuers (QVIs) who create their own trust domains, and legal entities receive credentials that are verifiable globally despite originating from jurisdiction-specific issuers.

Decentralized Applications: Applications can establish trust domains for their users without requiring centralized identity providers. Users control their own AIDs and can interact across multiple application trust domains while maintaining consistent identity.

Benefits

Eliminates Platform Lock-in: Trust domains based on cryptographic self-certification are portable across platforms. An identifier established in one trust domain can be verified in any other domain without requiring permission or coordination.

Enables Zero-Trust Architecture: Because trust domains provide end-verifiable proofs, systems can implement true zero-trust security models where "never trust, always verify" is cryptographically enforceable.

Supports Graduated Trust: Different trust domains can implement different security policies and verification requirements. High-stakes interactions can require stronger evidence while routine interactions can use lighter-weight verification.

Facilitates Interoperability: Trust domains can interoperate through cryptographic verification without requiring shared governance, infrastructure, or business relationships. This enables ecosystem growth without coordination overhead.

Trade-offs

Complexity vs. Flexibility: Establishing and managing trust domains requires understanding cryptographic concepts and key management practices. This complexity is the price of flexibility and security.

Discovery Challenges: While trust within a domain is cryptographically verifiable, discovering which trust domains are relevant for a given interaction remains a social/technical challenge. OOBI provides mechanisms but doesn't eliminate the discovery problem entirely.

Governance Boundaries: Trust domains must establish clear governance policies for key management, delegation, and revocation. Different domains may have incompatible policies, requiring careful design of cross-domain interactions.

Context Dependency: The meaning and authority of identifiers and credentials can vary across trust domains. Systems must carefully manage context to avoid misinterpretation of cross-domain references.

Relationship to Other Trust Models

KERI trust domains coexist with and can bridge to other trust models:

• Administrative trust domains (DNS/CA): KERI can use these for discovery (via OOBI) while not depending on them for verification
• Algorithmic trust domains (blockchains): KERI identifiers can be anchored to ledgers for additional guarantees while remaining independently verifiable
• Federated trust domains: KERI AIDs can serve as the cryptographic foundation for federation protocols, providing stronger security than traditional federation

This flexibility enables gradual adoption and integration with existing systems while providing a path toward fully autonomous, cryptographically-grounded trust domains.