The organization name deliberately evokes the cryptographic concept while representing a modern approach to decentralized trust infrastructure that fundamentally differs from traditional web-of-trust architectures.

Historical Context: Traditional Web of Trust

Zimmermann's 1992 innovation addressed several critical limitations of centralized Public Key Infrastructure (PKI) systems:

• Single points of failure: Compromise of a certificate authority affects all certificates it issued
• Institutional dependency: Users must trust the certificate authority's validation procedures
• Limited flexibility: Hierarchical models don't accommodate peer relationships well
• Vulnerability to coercion: Centralized authorities can be compelled to issue fraudulent certificates

The web of trust model spread through the PGP ecosystem and was later formalized in the OpenPGP standard. It became particularly important in communities requiring strong privacy guarantees and resistance to institutional control, such as cryptography researchers, privacy advocates, and secure communications users.

Traditional web of trust operations involve:

1. Key signing parties: Participants meet in person to verify identities and sign each other's keys
2. Trust path evaluation: Users assess the strength of trust in any particular key based on:
   • The number of trust paths connecting them to the key owner
   • The trustworthiness of intermediary nodes in those paths
   • The depth and diversity of the trust network
   • Personal trust settings and policies
3. Signature chains: Trust propagates through networks of users who have validated each other's keys

KERI as an Alternative Architecture

KERI represents a fundamentally different approach to establishing trust in digital identifiers, rather than an evolution of traditional web-of-trust models. The relationship between KERI and traditional web-of-trust is one of architectural divergence addressing the same underlying problem—establishing verifiable identity—through incompatible mechanisms.

Core Architectural Differences

Self-Certifying Foundation: KERI identifiers (AIDs) are cryptographically derived from keys using one-way functions, creating an unbreakable mathematical binding between identifier and key. This eliminates the fundamental problem that traditional web-of-trust addresses: establishing that a particular key belongs to a particular identity. In KERI, the identifier is a cryptographic transformation of the key, making the binding mathematically verifiable rather than socially validated.

Key Event Logs vs. Signature Chains: Traditional web-of-trust relies on chains of user signatures attesting to key ownership. KERI uses Key Event Logs (KELs)—append-only, cryptographically verifiable records of key events—to establish authoritative key state. KELs provide:

• Verifiable history: Complete audit trail from inception to current state
• Cryptographic integrity: Hash-chained events prevent tampering
• Self-authentication: No external validation required
• Key rotation support: Built-in mechanism for updating keys while maintaining identifier continuity

Witness Networks vs. Personal Trust: Traditional web-of-trust depends on personal trust judgments about other users' validation practices. KERI introduces witnesses—designated entities that provide key event receipts—operating under the KAACE algorithm (KERI's Agreement Algorithm for Control Establishment). Witnesses:

• Provide cryptographic proof of event observation and ordering
• Do not make trust judgments (unlike web-of-trust signers)
• Enable duplicity detection rather than trust assertion
• Operate under threshold schemes for Byzantine fault tolerance

Duplicity Detection vs. Trust Accumulation: The most profound difference is in security model. Traditional web-of-trust accumulates trust through signature chains—more signatures from trusted parties increase confidence. KERI achieves security through ambient duplicity detection—the ability for anyone, anywhere, at any time to detect if a controller has created conflicting versions of their key event history. This shifts the security guarantee from "many people trust this key" to "any attempt to use different keys for the same identifier will be cryptographically detectable."

End-Verifiability vs. Transitive Trust: Traditional web-of-trust requires trusting intermediary nodes in trust paths. KERI provides end-to-end verifiable validation where validators can cryptographically verify the entire chain of control authority from inception to current state without trusting any intermediaries. The KEL itself is the authoritative source of truth.

What KERI Does Not Eliminate

While KERI replaces traditional web-of-trust mechanisms for establishing key-to-identifier bindings, it does not eliminate all trust relationships:

Witness Selection: Controllers choose which witnesses to designate in their KEL configuration. This represents a form of trust, though more limited than traditional web-of-trust:

• Witnesses cannot forge events (they only observe and receipt)
• Threshold configurations protect against Byzantine witnesses
• Duplicity detection reveals misbehaving witnesses
• Controllers can rotate witness sets

Watcher Networks: Validators may rely on watchers—entities that monitor KELs for duplicity. Choosing which watchers to trust represents a decision point, though watchers cannot forge events, only report observed duplicity.

Credential Issuers: ACDC credentials create trust relationships between issuers and verifiers. While KERI provides cryptographic verifiability of the credential itself, determining which issuers to trust for particular claims remains a policy decision.

OOBI Trust Bootstrap: Out-Of-Band Introductions (OOBIs) provide initial discovery of service endpoints. The OOBI itself is not trusted—it merely bootstraps discovery that is subsequently verified through KERI mechanisms—but the source of the OOBI represents a trust decision point.

Renewing the Web of Trust

Document 73 references "Renewing the Web of Trust" as a KERI presentation title, which reflects KERI's position relative to traditional web-of-trust concepts. KERI renews rather than extends the web of trust by:

Preserving Core Values:

• Decentralization: No central authority controls identifier validation
• User sovereignty: Individuals control their own identifiers
• Peer relationships: Direct cryptographic relationships without institutional intermediaries
• Resistance to coercion: No centralized chokepoints for compromise

Replacing Technical Mechanisms:

• Cryptographic proofs replace social validation
• Mathematical binding replaces signature accumulation
• Duplicity detection replaces trust paths
• Event logs replace signature chains

Solving Historical Problems:

• Complexity: KERI's self-certifying identifiers are simpler to verify than evaluating multi-hop trust paths
• Scalability: KEL verification is computationally efficient compared to trust path evaluation
• Cold start: New identifiers are immediately usable without accumulating trust signatures
• Consistency: Cryptographic verification provides uniform security guarantees rather than variable trust judgments

Practical Implications in the KERI Ecosystem

vLEI Credential Infrastructure

The vLEI (verifiable Legal Entity Identifier) ecosystem demonstrates how KERI replaces traditional web-of-trust for enterprise identity:

Traditional Approach: Organizations might accumulate trust through certificates from multiple authorities, with verifiers evaluating which certificate authorities they trust and how many independent validations exist.

KERI/vLEI Approach:

• GLEIF Root AID serves as cryptographically verifiable root of trust
• Delegation chains create verifiable hierarchies from GLEIF to QVIs to Legal Entities
• ACDC credentials provide cryptographically signed attestations
• TEL (Transaction Event Log) enables public verifiability of credential status
• No signature accumulation required: Single valid credential with verifiable chain to GLEIF root is sufficient

Developer Infrastructure

The WebOfTrust GitHub organization structure reflects the architectural departure from traditional web-of-trust:

Modular Protocol Suite: Rather than a single monolithic web-of-trust implementation, the organization maintains separate but interoperable protocols:

• KERI: Core identifier and key event infrastructure
• ACDC: Credential container format
• CESR: Encoding for composable streaming
• OOBI: Discovery protocol
• IPEX: Credential exchange protocol

This modularity enables independent verification of each component while maintaining composability across the ecosystem.

Multiple Implementations: The organization supports implementations in multiple languages (Python KERIpy, TypeScript SignifyTS, Rust KERIox), enabling:

• Protocol correctness verification through independent implementations
• Ecosystem diversity reducing monoculture risks
• Language-appropriate tooling for different deployment contexts

Trust Models in Practice

Direct Mode: KERI supports a direct mode where validators have direct (albeit intermittent) contact with identifier controllers. This is analogous to traditional web-of-trust direct key validation but with cryptographic rather than social validation.

Indirect Mode: The indirect mode uses witnesses and KERLs (Key Event Receipt Logs) as secondary roots of trust. Unlike traditional web-of-trust transitive trust, this provides cryptographic guarantees through:

• Threshold signatures from witness pools
• Duplicity evident logs that reveal conflicting events
• Byzantine fault tolerance through KAACE algorithm

Registry-Backed Credentials: Public Transaction Event Logs (PTELs) provide verifiable credential registries that are:

• Anchored to KELs for cryptographic verification
• Publicly auditable for duplicity detection
• Self-validating without trusted registries

This contrasts with traditional approaches requiring trusted certificate revocation lists or OCSP responders.

Benefits Over Traditional Web-of-Trust

Security Guarantees:

• Cryptographic certainty: Mathematical proof rather than accumulated trust
• Duplicity evidence: Automatic detection of conflicting claims
• No trusted intermediaries: Direct cryptographic verification
• Byzantine fault tolerance: Formal guarantees through witness thresholds

Operational Advantages:

• Immediate usability: New identifiers work without trust accumulation
• Efficient verification: O(log n) KEL verification vs. trust path exploration
• Automated validation: No human judgment required for basic verification
• Key rotation support: Built-in mechanism maintaining identifier continuity

Ecosystem Benefits:

• Interoperability: Standard protocols across implementations
• Composability: Modular components combine for complex use cases
• Scalability: Efficient verification enables high-volume applications
• Privacy preservation: Selective disclosure through ACDCs

Limitations and Trade-offs

Cold Start Discovery: KERI identifiers require OOBI for initial service endpoint discovery. Traditional web-of-trust benefits from existing email/keyserver infrastructure, though OOBI provides simpler bootstrap.

Human-Meaningful Identifiers: KERI AIDs are cryptographic strings, not human-meaningful names. The aid|lid couplet model addresses this through verifiable authorization binding AIDs to human-meaningful identifiers, but requires additional infrastructure.

Witness Infrastructure: KERI requires witness infrastructure for indirect mode operation. Traditional web-of-trust requires no additional infrastructure beyond key servers, though witness services provide stronger guarantees.

Learning Curve: Understanding KERI's event-sourced architecture, cryptographic primitives, and protocol interactions requires significant technical knowledge. Traditional web-of-trust concepts map more directly to existing mental models of trust and social validation.

Conclusion: Complementary Mental Models

The term "web-of-trust" in the KERI ecosystem context serves dual purposes:

1. Historical reference: Acknowledging the decentralized trust principles established by Zimmermann's original web-of-trust concept
2. Architectural contrast: Highlighting how KERI provides an alternative technical approach to the same fundamental challenge

KERI does not implement a web-of-trust in the traditional PGP sense. Instead, it creates a cryptographic web of verifiable events where:

• Mathematical proofs replace social validation
• Event logs replace signature chains
• Duplicity detection replaces trust accumulation
• Cryptographic binding replaces key-to-identity association

The WebOfTrust GitHub organization name reflects this philosophy: preserving the decentralized, peer-to-peer ethos of the original web of trust while providing fundamentally different—and arguably stronger—technical mechanisms for establishing verifiable digital identity.

For developers working in the KERI ecosystem, "web-of-trust" should be understood as:

• The organizational context (GitHub organization)
• The philosophical foundation (decentralized trust)
• The historical reference point (what KERI provides an alternative to)
• Not the technical implementation (KERI uses different mechanisms)

This understanding helps position KERI correctly in the broader identity ecosystem: not as an incremental improvement to PGP-style web-of-trust, but as a fundamentally different architecture achieving similar goals through cryptographic rather than social mechanisms.