These systems share a common limitation: they require trust in the issuing authority and often lack verifiable audit trails for authority transfers.

Blockchain Confusion

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's Approach

Integration with ACDCs

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:

1. Proof-of-authorship layer: ACDCs establish a verifiable chain proving who originally created contained data through cryptographic signatures
2. Proof-of-authority layer: ACDCs carry verifiable authorizations, permissions, rights, or credentials that can be delegated through chained structures

Chained Authority Structures

KERI's approach enables chained (treed) proof-of-authority that supports:

• Delegation of authority: Rights can be transferred from one AID to another
• Delegated authorizations: Hierarchical permission structures where authority flows from root to leaves
• Verifiable credential chains: Each credential in a chain cryptographically references its authorizing parent

Cryptographic Binding

Proof-of-authority in KERI relies on:

• Digital signatures from authoritative key pairs controlled by AIDs
• SAIDs (Self-Addressing Identifiers) that cryptographically bind authority claims to specific data
• KEL anchoring that roots authority claims in verifiable key state history
• Seals that create cryptographic commitments linking authority events to establishment events

Provenance Through Combined Proofs

The combination of proof-of-authorship and proof-of-authority provides comprehensive provenance for:

• The ACDC data structure itself
• Any data conveyed by association with the ACDC
• The complete chain of authority from original creation through current control

Practical Example: Book Publishing Rights

The ACDC specification provides a concrete illustration:

1. Original creation: Author Terlalu Bonito writes a book
2. Initial ACDC: Contains the book data with anchoring digest signed by the author at publication date
3. Proof-of-authorship: Cryptographic signature establishes Terlalu as original creator (this never changes)
4. Rights transfer: Terlalu sells all publication rights to Liz Smiley
5. Proof-of-authority: A chained ACDC records the ownership transfer
6. Current state: The chain of ACDCs shows both original authorship (Terlalu) and current authority/control (Liz Smiley)

This demonstrates how proof-of-authority can transfer while proof-of-authorship remains immutable, with both being cryptographically verifiable through the ACDC chain.

Delegation Mechanisms

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.

Practical Implications

Use Cases

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:

• GLEIF delegates authority to Qualified vLEI Issuers (QVIs)
• QVIs delegate authority to issue specific credential types
• Legal entities delegate authority to representatives through role credentials

Supply chain custody: Proof-of-authority enables verifiable chain-of-custody tracking where:

• Original manufacturer establishes authorship of product data
• Authority transfers through distributors, retailers, and end users
• Each transfer is cryptographically verifiable
• Current authority holder can be definitively established

Digital rights management: For intellectual property and digital assets:

• Original creator establishes authorship
• Rights (reproduction, distribution, modification) can be separately delegated
• License transfers maintain verifiable audit trail
• Current rights holders can prove their authority

Delegated authorization: Enterprise and organizational scenarios:

• Root organizational AID delegates authority to departments
• Departments delegate to teams or individuals
• Each delegation level maintains cryptographic proof
• Revocation propagates through the delegation tree

Benefits

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:

• Original creators retain attribution while transferring rights
• Multiple parties hold different types of authority over the same data
• Authority can be time-limited or conditionally granted

Delegation without intermediaries: Hierarchical authority structures can be established and verified without requiring centralized delegation servers or permission management systems.

Trade-offs

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