Comprehensive Explanation
signing-authority
Official Definition
Signing authority is formally defined in the KERI protocol as the authority to sign on behalf of the controller of an authoritative key pair. This authority is characterized as a limited right because it explicitly does not include rotation authority—the ability to rotate keys and change the key state of an AID (Autonomic Identifier).
The canonical definition establishes that signing authority represents permission to create digital signatures for non-establishment events and operational transactions, while rotation authority encompasses the more privileged capability to modify the controlling keys themselves through establishment events.
Source Governance Framework: This concept is foundational to the KERI Technical Specification maintained by the Trust Over IP Foundation and is implemented across the vLEI Ecosystem Governance Framework for organizational identity credentials.
Official Abbreviations: While "signing authority" has no standard abbreviation, it is often discussed in conjunction with "rotation authority" as part of KERI's split control authority architecture.
Governance Context
Role in the vLEI Ecosystem
Within the vLEI (verifiable Legal Entity Identifier) ecosystem, signing authority plays a critical role in enabling scalable credential issuance while maintaining security. The vLEI governance framework leverages signing authority separation to enable:
-
Operational Delegation: Legal Entity Authorized Representatives (LARs) can be granted signing authority to issue and present credentials on behalf of a legal entity, while the entity's root control (rotation authority) remains with designated officers.
-
Multi-Signature Coordination: In QVI (Qualified vLEI Issuer) operations, multiple authorized representatives may hold signing authority as part of a multi-sig group, with thresholds requiring cooperation for credential issuance, while rotation authority for the QVI's root AID remains with a separate governance body.
-
Service Provider Models: Organizations can delegate signing authority to managed service providers (custodial agents) for day-to-day credential operations without surrendering ultimate control over their organizational identifier.
GLEIF Context
The Global Legal Entity Identifier Foundation (GLEIF) implements signing authority separation in its root governance structure:
- GLEIF Root AID: The GLEIF Root AID has rotation authority held by GLEIF's highest governance body (Root GARs - GLEIF Authorized Representatives)
- GLEIF External Delegated AID (GEDA): The GEDA receives delegated signing authority to issue QVI credentials, while GLEIF retains rotation authority over the GEDA through the root
- Operational Separation: External GARs hold signing authority for GEDA operations, enabling QVI credential issuance without requiring Root GAR involvement in every transaction
This hierarchical authority structure enables GLEIF to scale credential issuance operations while maintaining cryptographic control over the root of trust.
Signing authority separation enables several key governance patterns:
- Custodial Agents: Third-party service providers that hold signing authority while clients retain rotation authority
- Delegated Identifiers: Child AIDs that receive signing authority from parent AIDs through delegation
- End Roles: Authorization credentials that grant specific signing authority for defined purposes
- Multi-Signature Groups: Distributed signing authority among multiple parties with threshold requirements
Roles & Responsibilities
Primary Responsibilities
An entity or agent holding signing authority has the following capabilities and responsibilities:
Operational Signing:
- Sign interaction events that anchor external data to the AID's KEL
- Create signatures for ACDC credential issuance and presentation
- Sign IPEX (Issuance and Presentation Exchange) messages
- Authenticate API requests using KRAM (KERI Request Authentication Method)
- Sign transaction event log entries for credential status management
Witness Coordination:
- Submit signed events to the AID's witness pool for receipt collection
- Coordinate with witnesses to achieve KAACE (KERI's Agreement Algorithm for Control Establishment) consensus
- Manage event escrow and confirmation workflows
Key Management Operations (Limited):
- Maintain custody of current signing keys
- Protect signing keys according to security policies
- Use signing keys within their authorized scope
- Report key compromise if detected
Authority and Permissions
Signing authority grants specific, limited permissions:
Permitted Actions:
- Non-Establishment Event Signing: Create signatures for interaction events that do not change key state
- Credential Operations: Issue, present, and verify credentials using the AID
- Data Anchoring: Create cryptographic commitments to external data through seals
- Message Authentication: Sign protocol messages for secure communication
- Witness Interaction: Submit events to witnesses and collect receipts
Threshold Participation:
- In multi-sig configurations, signing authority holders contribute signatures toward meeting the signing threshold
- Each holder's signature weight is defined in the current key state
- Threshold satisfaction requires cooperation among authorized signers
Limitations
Critically, signing authority does not include:
Prohibited Actions:
- Key Rotation: Cannot create rotation events that change the authoritative key set
- Threshold Modification: Cannot alter signing or rotation thresholds
- Witness Changes: Cannot modify the witness pool configuration
- Delegation: Cannot delegate the AID to create child identifiers
- Configuration Changes: Cannot modify AID configuration parameters
These limitations are enforced cryptographically—rotation events require signatures from keys committed to in the previous establishment event's next key digest list, which are distinct from the current signing keys.
Revocability:
- Signing authority can be revoked unilaterally by the rotation authority holder
- Revocation occurs through a rotation event that establishes new signing keys
- The signing authority holder cannot prevent or block this revocation
- This "fire the custodian" capability is fundamental to KERI's security model
Technical Implementation
Split Control Authority Architecture
KERI implements signing authority separation through a dual key set architecture:
First Key Set (Current Keys):
- Used for signing authority
- Exposed and active for operational signing
- Defined in the
k (keys) field of establishment events
- Subject to the
kt (current threshold) for signature validation
Second Key Set (Pre-Rotated Keys):
- Reserved for rotation authority
- Committed to via cryptographic digests in the
n (next) field
- Not exposed until needed for rotation
- Subject to the
nt (next threshold) for rotation validation
Partial Rotation Mechanism
The partial rotation mechanism enables signing authority delegation:
- Initial Setup: During inception or rotation, the controller commits to next keys via digests
- Authority Split: Current keys are distributed to signing authority holders; next keys remain with rotation authority holder
- Threshold Configuration: Signing threshold (
kt) and rotation threshold (nt) can be configured independently
- Operational Phase: Signing authority holders use current keys for day-to-day operations
- Revocation: Rotation authority holder can rotate to new keys without cooperation from signing authority holders
Custodial Rotation Pattern
The canonical use case for signing authority separation is custodial rotation:
Inception Event:
Current Keys (k): [custodian_key_1, custodian_key_2]
Current Threshold (kt): "2" // Requires both custodian signatures
Next Keys (n): [digest(owner_rotation_key)]
Next Threshold (nt): "1" // Owner can rotate alone
In this configuration:
- The custodian holds both current keys and can sign operational events
- The owner holds the pre-rotated key and can rotate without custodian cooperation
- If the custodian is compromised or needs to be replaced, the owner rotates to new keys
Key Event Log Structure
Signing authority is exercised through the KEL:
Interaction Events (Signed by Current Keys):
{
"v": "KERI10JSON000160_",
"t": "ixn",
"d": "EXq5YqaL6L48pf0fu7IUhL0JRaU2_RxFP0AL43wYn148",
"i": "EaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM",
"s": "3",
"p": "EULvaU6JR2nmwyYAfSVPzhzZ-i0d8JZAoTNZH3S6b5CM",
"a": [
{
"i": "EDP1vHcw_wc4M__Fj53-cJaBnZZASd-aMTaSyWEQ-PC2",
"s": "0",
"d": "EwmQtlcszNoEIDfqD-Zih3N6o5B3humRKvBBln2juTEM"
}
]
}
This interaction event:
- Is signed by current keys (signing authority)
- Anchors external data via the seal in the
a (anchors) field
- Does not change key state
- Requires signatures meeting the current threshold
Rotation Events (Require Next Keys):
{
"v": "KERI10JSON000190_",
"t": "rot",
"d": "E0d8JZAoTNZH3ULvYAfSVPzhzS6b5CMaU6JR2nmwyZ-i",
"i": "EaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM",
"s": "4",
"p": "EXq5YqaL6L48pf0fu7IUhL0JRaU2_RxFP0AL43wYn148",
"kt": "1",
"k": ["DaU6JR2nmwyZ-i0d8JZAoTNZH3ULvYAfSVPzhzS6b5CM"],
"nt": "1",
"n": ["EQtlcszNoEIDfqD-Zih3N6o5B3humRKvBBln2juTEM"],
"bt": "2",
"br": [],
"ba": [],
"a": []
}
This rotation event:
- Must be signed by keys from the previous event's
n field (rotation authority)
- Establishes new current keys in the
k field
- Commits to new next keys in the
n field
- Changes the key state and authority structure
Credential Lifecycle Integration
vLEI Credential Issuance
In the vLEI ecosystem, signing authority enables credential operations:
Legal Entity vLEI Credential Issuance:
- LAR Authorization: Legal Entity Authorized Representatives hold signing authority for the Legal Entity's AID
- Credential Request: LARs sign credential issuance requests using their signing authority
- Multi-Sig Coordination: Multiple LARs coordinate signatures to meet threshold requirements
- QVI Verification: The QVI verifies signatures against the Legal Entity's current key state
- Credential Issuance: Upon verification, the QVI issues the credential
Role Credential Issuance (OOR and ECR):
- LAR Signing: LARs use signing authority to issue role credentials to individuals
- Delegation Chain: Role credentials chain to the Legal Entity credential via ACDC edges
- Presentation: Role credential holders use their own signing authority to present credentials
Verification Procedures
Verifiers validate signing authority through:
- Key State Resolution: Query the AID's KEL to determine current authoritative keys
- Signature Verification: Verify signatures against current keys from key state
- Threshold Validation: Confirm sufficient signatures meet the current threshold
- Witness Confirmation: Verify witness receipts confirm the key state
- Duplicity Check: Ensure no conflicting key states exist
Revocation Conditions
Signing authority can be revoked through:
Key Rotation:
- Rotation authority holder creates rotation event with new current keys
- Previous signing authority holders' keys become stale
- New signing authority is established with the rotated keys
Credential Revocation:
- If signing authority was granted via a credential, revoking that credential terminates the authority
- Revocation is recorded in the TEL (Transaction Event Log)
- Verifiers check credential status before accepting signatures
KERI Technical Specifications
-
KERI Protocol Specification (Trust Over IP Foundation)
- Defines establishment events and key state management
- Specifies signing and rotation authority separation
- Details partial rotation mechanisms
-
IETF KERI Draft (Internet Engineering Task Force)
- Formal protocol specification
- Security properties and threat model
- Key management requirements
vLEI Governance Framework Documents
-
vLEI Ecosystem Governance Framework v3.0
- Overall governance structure
- Trust assurance framework
- Roles and responsibilities
-
GLEIF Identifier Governance Framework
- GLEIF Root AID management
- Delegated AID policies
- Key management requirements
-
Legal Entity vLEI Credential Governance Framework
- LAR authorization requirements
- Multi-signature policies
- Credential issuance procedures
-
QVI Qualification Agreement
- QVI signing authority scope
- Operational requirements
- Audit and compliance obligations
Technical Implementation Guides
-
KERIA Protocol Specification
- Client-agent signing authority delegation
- SKRAP authentication protocol
- Agent worker initialization
-
Signify Client Documentation
- Edge signing implementation
- Key management best practices
- Multi-signature coordination
-
KLI Operations Guide
- Command-line interface for key operations
- Delegation and rotation procedures
- Witness coordination
Security Considerations
Threat Model
Signing Key Compromise:
- If signing authority keys are compromised, attacker can sign unauthorized events
- However, attacker cannot rotate keys or change key state
- Rotation authority holder can revoke compromised signing keys
- Damage is limited to events signed before detection and rotation
Custodian Malfeasance:
- Malicious custodian with signing authority can sign unauthorized events
- Cannot prevent owner from rotating keys and revoking authority
- Cannot modify rotation keys or delegation structure
- Witness receipts provide audit trail of custodian actions
Collusion Attacks:
- In multi-sig scenarios, threshold prevents single-party abuse
- Collusion among signing authority holders can authorize events
- Rotation authority holder can still revoke all signing keys
- Witness network provides duplicity detection
Best Practices
- Separation of Duties: Keep signing and rotation keys on separate systems
- Threshold Configuration: Use multi-sig for signing authority when possible
- Key Rotation Schedule: Regularly rotate signing keys as a security hygiene practice
- Audit Logging: Monitor signing authority usage for anomalies
- Incident Response: Have procedures for rapid key rotation if compromise is detected
- Witness Selection: Choose witnesses that provide adequate duplicity detection
- Backup Rotation Keys: Securely store rotation authority keys with highest protection level
Adoption and Usability
Mainstream User Accessibility
Signing authority separation is considered critical for mainstream adoption of KERI-based identity systems because:
- Reduced Complexity: Users can delegate operational signing to managed services without surrendering control
- Professional Management: Service providers can offer secure key management without lock-in
- Recovery Options: Users retain ability to recover from custodian failure or compromise
- Familiar Model: Similar to banking relationships where users retain ultimate account control
Service Provider Business Models
Signing authority enables sustainable business models for identity service providers:
- Managed Services: Providers can offer signing-as-a-service with clear value proposition
- No Lock-In: Users can switch providers without losing their identifier
- Liability Management: Providers hold signing authority but not ultimate control
- Scalability: Providers can serve many users without requiring per-user infrastructure
Enterprise Adoption
For enterprises, signing authority separation enables:
- Operational Delegation: Day-to-day signing can be delegated to operational teams
- Governance Control: Executive or board-level control over rotation authority
- Compliance: Clear audit trails and separation of duties
- Disaster Recovery: Rotation authority can be held in secure offline storage
Conclusion
Signing authority represents a fundamental architectural innovation in KERI that enables practical, scalable, and secure identity systems. By separating operational signing capabilities from ultimate control authority, KERI provides a foundation for:
- Custodial services that don't create lock-in
- Delegation hierarchies that maintain security properties
- Enterprise governance with appropriate separation of duties
- Mainstream adoption through managed service models
This separation is not merely a convenience feature but a core security property that enables KERI to bridge the gap between self-sovereign principles and real-world usability requirements. The ability to delegate signing authority while retaining rotation authority provides users with both operational convenience and ultimate sovereignty—a combination that is essential for widespread adoption of decentralized identity systems.