Rotationauthority is the exclusive right to rotate the authoritativekey pairs of an AID and establish changed control authority, distinct from signing authority. This separation enables custodial arrangements where signing operations can be delegated while the original controller retains ultimate control through the ability to rotate keys.
Related Concepts
No related concepts available
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:
Signing Authority - The right to sign non-establishment events and perform day-to-day operations
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 and :
Implementation Notes
Implementation Considerations
Key Storage Architecture
Separation of Key Material
Store pre-rotated keys (rotation authority) separately from current signing keys
Use different security boundaries for different authority types
Consider hardware security modules (HSMs) for rotation authority keys
Implement access controls that reflect authority separation
Key Generation
Generate pre-rotated keys at inception or during rotation
Use cryptographically secure random number generators
Maintain sufficient entropy for quantum-resistant security
Document key generation procedures for audit
Threshold Configuration
Signing vs. Rotation Thresholds
Set kt (current threshold) for signing authority requirements
Set nt (next threshold) for rotation authority requirements
Rotation threshold should typically be equal to or higher than signing threshold
Document threshold rationale in governance policies
Multi-Signature Considerations
For custodial arrangements: kt may be lower to enable custodian signing
For rotation: nt should require original controller participation
Example: kt: "1" (custodian can sign), nt: "1" (only controller can rotate)
Event Processing
Rotation Event Validation
Verify revealed keys match committed digests from prior event
Track which keys have signing authority vs. rotation authority
Maintain current and next key states separately
Update authority mappings after successful rotation
Preserve historical authority records for audit
Custodial Integration
API Design
Separate endpoints for signing operations vs. rotation operations
Custodian APIs should not expose rotation capabilities
Controller APIs must authenticate rotation authority
ultimate control boundaries
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:
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 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.
Implement proper authorization checks for each authority type
Key Distribution
Securely provision signing keys to custodians
Never expose pre-rotated keys to custodians
Use secure channels for key material transfer
Implement key escrow procedures if required by governance
Security Monitoring
Rotation Detection
Monitor for unexpected rotation events
Alert on rotation attempts without proper authorization
Track rotation frequency and patterns
Implement anomaly detection for rotation behavior
Duplicity Detection
Compare rotation events across witnesses and watchers
Detect conflicting rotations to same sequence number
Implement automated duplicity reporting
Maintain duplicity evidence for dispute resolution