Comprehensive Explanation

rotation-authority

Official Definition

Rotation authority is formally defined in the KERI protocol as the (exclusive) right to rotate the authoritative key pair and establish changed control authority over an AID (Autonomic Identifier). This authority represents one half of KERI's innovative split control authority model, where control over an identifier is divided between two distinct capabilities:

1. Signing Authority - The right to sign non-establishment events and perform day-to-day operations
2. Rotation Authority - The right to rotate keys and change the authoritative key set

This separation is not merely a convenience feature but a fundamental architectural innovation that enables secure delegation patterns while preserving controller sovereignty. The concept is canonically defined in the IETF-KERI draft specification by Samuel Smith and is central to KERI's approach to decentralized key management.

Canonical abbreviations: While "rotation authority" itself is not abbreviated, it is intrinsically linked to the pre-rotation mechanism and partial rotation capabilities that implement this authority separation.

Governance Context

Within the broader KERI and vLEI ecosystem governance structure, rotation authority plays a critical role in establishing ultimate control boundaries and delegation hierarchies:

vLEI Ecosystem Role

In the vLEI (verifiable Legal Entity Identifier) ecosystem governed by GLEIF, rotation authority determines:

• Who can revoke delegated credentials: Legal entities that retain rotation authority over their AIDs can unilaterally revoke credentials issued to representatives
• Service provider relationships: Organizations can delegate signing authority to QVIs (Qualified vLEI Issuers) or other service providers while retaining rotation authority
• Recovery mechanisms: In the event of key compromise or service provider failure, rotation authority enables recovery without requiring cooperation from potentially compromised or unavailable parties

GLEIF Context

GLEIF's governance framework recognizes rotation authority as the ultimate control mechanism for Legal Entity identifiers. The GLEIF External Delegated AID (GEDA) structure demonstrates this principle:

• GLEIF retains rotation authority over the root AID
• QVIs receive delegated signing authority for credential issuance
• GLEIF can rotate keys to revoke QVI authorization without QVI cooperation
• This preserves GLEIF's governance role while enabling distributed operations

Related Governance Entities

Rotation authority intersects with several governance entities:

• Controllers: The entities that hold rotation authority are the ultimate controllers
• Custodial Agents: Service providers that may hold signing authority but not rotation authority
• Witnesses: Infrastructure components that verify rotation events but do not hold rotation authority
• Delegates: Entities that may receive signing authority through delegation but typically not rotation authority

Roles & Responsibilities

Primary Responsibilities

An entity holding rotation authority has the following primary responsibilities:

1. Key Lifecycle Management

The rotation authority holder is responsible for:

• Generating and securely storing pre-rotated keys
• Executing rotation events when keys need to be changed
• Maintaining the cryptographic chain of authority through proper KEL (Key Event Log) management
• Ensuring rotation keys remain unexposed until needed

2. Security Incident Response

When signing keys are compromised:

• The rotation authority holder can execute emergency rotations
• New keys can be established without cooperation from compromised parties
• The identifier remains under legitimate control despite signing key compromise

3. Service Provider Management

For custodial arrangements:

• Rotation authority enables "firing" custodial agents by rotating to new keys
• Service provider relationships can be terminated unilaterally
• No vendor lock-in occurs because rotation authority remains with the original controller

4. Delegation Hierarchy Maintenance

In delegated identifier structures:

• Delegators retain rotation authority over delegated AIDs
• This enables revocation of delegation without delegate cooperation
• Hierarchical control structures remain enforceable

Authority and Permissions

Rotation authority specifically grants the permission to:

Execute Establishment Events

• Create rotation events that change the key state
• Modify the set of authoritative keypairs
• Update witness configurations
• Change thresholds for signing and rotation

Reveal Pre-Rotated Keys

• Expose keys that were previously committed to via digests
• Prove possession of keys committed to in prior events
• Establish continuity of control authority

Modify Control Structure

• Change from single-signature to multi-signature control
• Adjust threshold requirements
• Add or remove controlling parties in multi-sig arrangements

Revoke Delegations

• Terminate custodial arrangements
• Revoke delegated signing authority
• Reclaim full control over the identifier

Limitations

Rotation authority does not grant:

Signing Authority for Non-Establishment Events

• Cannot sign interaction events unless also holding signing authority
• Cannot issue credentials or make statements on behalf of the identifier
• Cannot perform day-to-day operational signing

Retroactive Changes

• Cannot modify past events in the KEL
• Cannot change historical key states
• Cannot undo previously signed statements

Arbitrary Key Selection

• Must reveal keys that match previously committed digests
• Cannot rotate to keys not pre-committed in prior events
• Bound by the pre-rotation mechanism

Witness Override

• Cannot force witnesses to accept invalid rotations
• Must satisfy witness thresholds defined in prior events
• Subject to duplicity detection by the witness network

Technical Implementation Architecture

Split Control Authority Mechanism

KERI implements rotation authority separation through a sophisticated dual-key architecture:

Current Key Set (Signing Authority)

• Used for signing non-establishment events
• May be held by custodial agents or delegates
• Exposed and actively used for operations
• Compromise does not grant rotation capability

Pre-Rotated Key Set (Rotation Authority)

• Committed to via cryptographic digests
• Kept unexposed until rotation event
• Held exclusively by the original controller
• Compromise before exposure does not enable unauthorized rotation

Threshold Configuration

The separation is enforced through careful threshold structuring:

Current Threshold (kt)

• Specifies how many current keys must sign non-establishment events
• Can be configured to enable custodial signing
• Example: "kt": "1" allows single custodian to sign

Next Threshold (nt)

• Specifies how many pre-rotated keys must sign rotation events
• Can be configured to require original controller participation
• Example: "nt": "1" requires controller's pre-rotated key for rotation

Witness Threshold (bt)

• Specifies how many witnesses must receipt events
• Applies to both signing and rotation events
• Provides distributed verification

Pre-Rotation Commitment Process

Rotation authority is established through the pre-rotation mechanism:

1. Key Generation

• Controller generates next rotation keypair
• Private key stored securely and kept unexposed
• Public key hashed to create commitment digest

2. Commitment Publication

• Digest included in current establishment event's n field
• Cryptographically binds future rotation to this key
• Cannot be changed without creating detectable duplicity

3. Key Revelation

• During rotation, pre-rotated public key is revealed
• Verifiers confirm it matches the committed digest
• Rotation event is signed with corresponding private key

4. New Commitment

• Rotation event includes new pre-rotation commitment
• Process repeats for subsequent rotations
• Maintains continuous chain of rotation authority

Custodial Rotation: Primary Use Case

The most significant practical application of rotation authority separation is custodial rotation, which enables secure service provider relationships:

Architecture Pattern

Controller Responsibilities

• Generates and stores pre-rotated keys securely
• Retains exclusive rotation authority
• Can terminate custodian relationship unilaterally

Custodian Responsibilities

• Holds current signing keys
• Performs day-to-day signing operations
• Provides infrastructure and availability
• Cannot prevent controller from rotating keys

Security Properties

Non-Cooperative Revocation

• Controller can "fire" custodian without custodian's permission
• Rotation event signed with controller's pre-rotated key
• Custodian's signing keys become invalid
• No vendor lock-in or service provider capture

Compromise Recovery

• If custodian's signing keys are compromised, controller rotates
• If custodian becomes malicious, controller rotates
• If custodian becomes unavailable, controller rotates
• Rotation authority provides ultimate recovery mechanism

Operational Flexibility

• Controllers can change service providers
• Multiple custodians can be used for different purposes
• Custodial arrangements can be temporary or permanent
• No loss of identifier continuity when changing custodians

Adoption Significance

Custodial rotation is considered essential for mainstream KERI adoption because:

Usability for Non-Technical Users

• 99% of users may not want to manage their own keys
• Professional custodians can provide user-friendly services
• Technical complexity is abstracted away
• Users still maintain ultimate control

Business Model Enablement

• Enables SaaS (Software-as-a-Service) business models
• Service providers can offer managed identity services
• Revenue models based on convenience, not control
• Competitive market for custodial services

Enterprise Adoption

• Organizations can delegate operations to IT departments
• Executive leadership retains rotation authority
• Separation of duties for compliance
• Audit trails for key management

Reserve Rotation: Advanced Use Case

Another important application of rotation authority is reserve rotation, enabled by partial rotation:

Concept

Controllers can pre-commit to multiple keys but only expose some during rotation:

• Some pre-rotated keys are revealed and become current signing keys
• Other pre-rotated keys remain unexposed and held in reserve
• Reserved keys can be used in future rotations
• Provides defense-in-depth for key management

Security Benefits

Reduced Exposure Surface

• Not all pre-committed keys are revealed simultaneously
• Limits attack surface for key compromise
• Provides backup keys if current keys are compromised

Emergency Recovery

• Reserved keys can be used if current keys are lost
• Multiple layers of recovery options
• Flexible response to different compromise scenarios

Threshold Flexibility

• Can adjust which keys are active without full rotation
• Enables dynamic security postures
• Supports complex multi-party control arrangements

Relationship to KERI Core Concepts

Key Event Log (KEL)

Rotation authority is exercised through the KEL:

• Rotation events are appended to the KEL
• Each rotation references prior event via digest
• KEL provides verifiable history of rotation authority exercise
• Duplicity detection prevents unauthorized rotations

Establishment Events

Rotation authority is defined and modified through establishment events:

• Inception events establish initial rotation authority
• Rotation events exercise and re-establish rotation authority
• Each establishment event commits to next rotation keys
• Threshold changes affect future rotation authority requirements

Witnesses and Watchers

Witnesses and watchers provide distributed verification:

• Witnesses receipt rotation events
• Watchers detect duplicitous rotation attempts
• KAACE algorithm establishes consensus on rotations
• Distributed infrastructure prevents single-point-of-failure

Delegation

Rotation authority interacts with delegation:

• Delegators typically retain rotation authority over delegated AIDs
• Delegates receive signing authority but not rotation authority
• Enables hierarchical control structures
• Supports organizational identity management

Security Considerations

Threat Model

Rotation authority addresses several attack scenarios:

Signing Key Compromise

• Attacker gains access to current signing keys
• Cannot rotate to their own keys without pre-rotated key
• Legitimate controller can rotate to revoke compromised keys
• Identifier remains under legitimate control

Custodian Compromise

• Malicious or compromised custodian attempts unauthorized actions
• Cannot prevent legitimate controller from rotating
• Controller can unilaterally terminate relationship
• No permanent damage to identifier

Service Provider Failure

• Custodian becomes unavailable or uncooperative
• Controller can rotate to new custodian
• Identifier portability preserved
• No vendor lock-in

Best Practices

Secure Pre-Rotated Key Storage

• Store pre-rotated keys separately from signing keys
• Use hardware security modules (HSMs) for high-value identifiers
• Implement multi-party control for organizational identifiers
• Regular key rotation schedules

Threshold Configuration

• Set rotation thresholds higher than signing thresholds for critical identifiers
• Use multi-signature rotation for high-security applications
• Balance security with operational requirements
• Document threshold rationale for governance

Witness Selection

• Choose diverse, independent witnesses
• Ensure witness availability for rotation events
• Monitor witness performance and reliability
• Plan for witness rotation if needed

Recovery Planning

• Document rotation procedures
• Test rotation processes regularly
• Maintain secure backups of pre-rotated keys
• Establish clear authority for emergency rotations

Related Governance Documents

KERI Specifications

IETF-KERI Draft Specification

• Formal definition of rotation authority
• Technical specification of rotation events
• Pre-rotation mechanism details
• Threshold and key list structures

KERI Whitepaper v2.x

• Conceptual foundation for rotation authority
• Security analysis of pre-rotation
• Use case descriptions
• Architectural rationale

vLEI Governance Framework

vLEI Ecosystem Governance Framework

• Defines rotation authority requirements for Legal Entity identifiers
• Specifies who holds rotation authority in delegation hierarchies
• Establishes recovery procedures
• Governance policies for key management

Qualified vLEI Issuer (QVI) Credential Governance Framework

• Defines GLEIF's rotation authority over QVI credentials
• Specifies QVI signing authority limitations
• Establishes revocation procedures
• Delegation and authority boundaries

Technical Specifications

CESR Specification

• Encoding of rotation events
• Cryptographic primitive representation
• Signature attachment formats
• Stream processing for rotation events

ACDC Specification

• Credential issuance using rotatable identifiers
• Issuer rotation implications
• Credential revocation through rotation
• Delegation and rotation authority in credentials

Conclusion

Rotation authority represents a fundamental innovation in decentralized key management, enabling secure delegation patterns while preserving controller sovereignty. By separating rotation authority from signing authority, KERI enables:

• Custodial services that don't compromise user control
• Enterprise adoption through flexible delegation
• Recovery mechanisms that don't require third-party cooperation
• Vendor independence through portable identifiers

This architectural pattern is essential for scaling decentralized identity systems to mainstream adoption while maintaining the security properties that make self-sovereign identity valuable. The rotation authority mechanism demonstrates that usability and security are not inherently in conflict when proper cryptographic foundations are established.