Loading vLEI.wiki
Fetching knowledge base...
Fetching knowledge base...
This comprehensive explanation has been generated from 28 GitHub source documents. All source documents are searchable here.
Last updated: October 7, 2025
This content is meant to be consumed by AI agents via MCP. Click here to get the MCP configuration.
Note: In rare cases it may contain LLM hallucinations.
For authoritative documentation, please consult the official GLEIF vLEI trainings and the ToIP Glossary.
Proof-of-authority is cryptographic evidence that an entity possesses specific rights, permissions, or authorizations over data, distinct from proof-of-authorship which establishes original creation. In KERI/ACDC systems, proof-of-authority enables verifiable delegation chains, credentials, and authorization transfers through chained data structures.
Proof-of-authority establishes verifiable evidence that an entity has specific rights, permissions, or authorizations associated with data or digital assets. This concept is fundamentally distinct from proof-of-authorship, which concerns the original creator of data. While proof-of-authorship answers "who created this?", proof-of-authority answers "who has rights to act on this?"
The core properties of proof-of-authority include:
The scope encompasses any scenario where authorization, permission, or credential verification is required, from simple access control to complex multi-party delegation chains.
Traditional authorization systems rely on centralized registries or trusted intermediaries to verify permissions. Examples include:
Implementing proof-of-authority requires careful governance design:
Authority scope definition: Clearly define what rights, permissions, or authorizations are being proven. The vLEI ecosystem provides examples through distinct credential types for different authority scopes (OOR vs ECR).
Delegation policies: Establish rules for who can delegate authority to whom, under what conditions, and with what limitations. The QVI authorization framework demonstrates multi-level delegation policies.
Revocation mechanisms: Design TEL-based revocation registries that enable timely authority revocation while maintaining verifiability of historical authority states.
Chain-link confidentiality: Consider implementing chain-link confidential disclosure to protect sensitive authority relationships while maintaining verifiability for authorized parties.
Verifying proof-of-authority requires:
The IPEX protocol provides standardized mechanisms for proof-of-authority presentation:
Graduated disclosure: Present minimal authority proof initially, revealing additional delegation chain details only as needed
Contractual protection: Use Ricardian contracts in ACDC rules sections to establish legal obligations around authority use
These systems share a common limitation: they require trust in the issuing authority and often lack verifiable audit trails for authority transfers.
An important disambiguation: "Proof of Authority" is also the name of a blockchain consensus algorithm that uses identity-based stake for validator selection and fast transaction processing. This blockchain consensus meaning is NOT what is meant in SSI, KERI, and ACDC contexts. The KERI/ACDC proof-of-authority concerns verifiable data rights and authorizations, not distributed ledger consensus mechanisms.
KERI implements proof-of-authority through Authentic Chained Data Containers (ACDCs), which provide both proof-of-authorship and proof-of-authority in a unified framework. The ACDC specification describes how "with a little additional syntactic sugar" the core proof-of-authorship facility extends to support "chained (treed) verifiable authentic proof-of-authority."
Dual-proof architecture:
KERI's approach enables chained (treed) proof-of-authority that supports:
Proof-of-authority in KERI relies on:
The combination of proof-of-authorship and proof-of-authority provides comprehensive provenance for:
The ACDC specification provides a concrete illustration:
This demonstrates how proof-of-authority can transfer while proof-of-authorship remains immutable, with both being cryptographically verifiable through the ACDC chain.
KERI supports multiple delegation patterns for proof-of-authority:
Cooperative delegation: Both delegator and delegate must contribute cryptographic commitments to establish the delegation relationship. The delegator creates a commitment in a rotation or interaction event via a seal, while the delegate creates a commitment in its establishment event.
Nested delegation trees: Delegations can be recursive, forming arbitrarily complex hierarchical structures. Each level in the tree maintains cryptographic verifiability back to the root authority.
Partial rotation: Enables separation of signing authority from rotation authority, supporting custodial arrangements where a designated agent holds signing authority while the original controller retains exclusive rotation authority.
Verifiable credentials: The primary use case is implementing verifiable credentials where proof-of-authority establishes that an issuer has the right to make specific claims. The vLEI ecosystem exemplifies this, where:
Supply chain custody: Proof-of-authority enables verifiable chain-of-custody tracking where:
Digital rights management: For intellectual property and digital assets:
Delegated authorization: Enterprise and organizational scenarios:
End-verifiable authorization: Any party can cryptographically verify current authority without requiring access to centralized registries or trusted intermediaries. This eliminates single points of failure and reduces dependency on third-party infrastructure.
Portable authority: Proof-of-authority is bound to AIDs rather than platform-specific identifiers, enabling authority to be verified across different systems and contexts without re-issuance.
Audit trails: The chained structure of ACDCs creates immutable audit trails showing the complete history of authority transfers from original creation through current state.
Separation of concerns: Distinguishing proof-of-authority from proof-of-authorship enables complex scenarios where:
Delegation without intermediaries: Hierarchical authority structures can be established and verified without requiring centralized delegation servers or permission management systems.
Complexity: Implementing proof-of-authority chains requires understanding KERI key management, ACDC structures, and delegation mechanisms. This represents a steeper learning curve than simple bearer tokens.
Storage requirements: Maintaining verifiable chains requires storing the complete delegation path from root authority to current holder. For deep delegation trees, this can result in significant data storage.
Revocation challenges: While authority can be revoked through TEL registries, ensuring all verifiers have current revocation state requires robust infrastructure for registry discovery and synchronization.
Governance complexity: Establishing clear policies for who can delegate what authority requires careful governance framework design. The vLEI ecosystem demonstrates this complexity through multiple governance documents defining delegation rules.
Performance considerations: Verifying deep delegation chains requires validating each link in the chain, which can impact performance in resource-constrained environments or high-throughput scenarios.
Challenge-response: Implement challenge-response protocols to verify that the presenter controls the AID claiming authority