Loading vLEI.wiki
Fetching knowledge base...
Fetching knowledge base...
This comprehensive explanation has been generated from 76 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.
A transferable identifier is a persistent identifier whose control authority can be transferred to new cryptographic keys through key rotation, enabling the identifier to maintain continuity despite changes in its controlling key pairs.
A transferable identifier represents a fundamental primitive in KERI's composable identifier architecture, distinguished by its capacity to maintain persistent identity while enabling secure transfer of control authority through key rotation. Unlike non-transferable identifiers that are permanently bound to their initial key pairs, transferable identifiers support the evolution of their cryptographic key state over time without changing the identifier itself.
The core properties of transferable identifiers include:
The scope of transferability encompasses the complete lifecycle management of cryptographic control, from inception through multiple rotations to potential abandonment. The boundary condition is that transferability applies specifically to control authority over the identifier—not to the identifier string itself, which remains immutable.
The concept of transferable identifiers emerged from addressing a fundamental limitation in basic self-certifying identifiers (SCIDs). Traditional SCIDs, while providing strong cryptographic binding between identifiers and public keys, suffered from a critical weakness: they were . Once the controlling private key became compromised or weakened through exposure, the entire identifier had to be abandoned, as there was no mechanism to rotate to new keys while maintaining identifier continuity.
Implementing transferable identifiers requires careful attention to key management practices:
Key Separation: Current signing keys and pre-rotated keys must be stored separately with different access controls. Pre-rotated keys should be stored in more secure, less accessible locations (e.g., cold storage, hardware security modules) since they are only needed for rotation events.
Backup Procedures: Both current and pre-rotated keys must be backed up securely. Loss of pre-rotated keys means loss of rotation capability, effectively converting the identifier to non-transferable.
Rotation Policies: Organizations should establish clear policies for when rotation occurs (scheduled intervals, security events, personnel changes) and who has authority to initiate rotations.
For indirect mode operation, transferable identifiers typically use witnesses to provide availability and duplicity detection:
Witness Selection: Choose witnesses based on availability, reliability, and independence. The threshold of accountable duplicity (TOAD) determines how many witnesses must confirm events.
Witness Rotation: The witness set itself can be rotated through rotation events, allowing the identifier to change its infrastructure providers without changing the identifier.
KEL Processing: Verifiers must process the complete KEL to determine current key state. Implementations should cache key state and only process new events incrementally.
Duplicity Detection: Verifiers should compare KELs from multiple sources (witnesses, watchers) to detect potential duplicity where a controller creates conflicting versions of their KEL.
Performance: For identifiers with many rotations, KEL processing can become computationally expensive. Consider using Key Event Receipt Logs (KERLs) with witness receipts to reduce verification overhead.
Pre-rotation Timing: Generate and secure pre-rotated keys immediately after each rotation, not at the time of the next rotation. This ensures the keys are available if rotation becomes necessary due to compromise.
Threshold Schemes: For high-security applications, use multi-signature configurations with threshold requirements (e.g., 2-of-3) for both signing and rotation authority.
This ephemeral nature created significant practical problems:
Traditional PKI systems addressed key rotation through certificate authorities that could issue new certificates binding the same identity to new keys. However, this approach introduced centralized trust dependencies and administrative overhead that KERI's design explicitly seeks to eliminate.
Blockchain-based identifier systems attempted to solve this through on-chain transactions that update key bindings, but this created infrastructure lock-in and dependency on specific ledger consensus mechanisms.
KERI's solution to creating transferable identifiers centers on the pre-rotation mechanism combined with the Key Event Log (KEL) data structure. This approach provides transferability while maintaining the self-certifying and decentralized properties that make KERI identifiers powerful.
The revolutionary aspect of KERI's transferable identifiers is pre-rotation—a cryptographic commitment scheme where each establishment event (inception or rotation) includes a cryptographic digest of the next set of rotation keys. This pre-commitment has profound security implications:
The pre-rotation mechanism creates a cryptographic chain where each rotation event proves legitimate control by revealing the pre-committed keys from the previous event and establishing new pre-commitments for the next rotation.
Transferable identifiers maintain their complete control history in a KEL—an append-only, cryptographically chained log of key events. For transferable identifiers, the KEL contains:
Each event in the KEL includes:
This structure enables any verifier to cryptographically validate the complete control history and determine the current authoritative key set without requiring trust in external infrastructure.
KERI's transferable identifiers differ fundamentally from traditional approaches:
vs. Certificate Authority Systems:
vs. Blockchain-Based DIDs:
vs. Basic Self-Certifying Identifiers:
The KERI approach to transferable identifiers provides:
Transferable identifiers are essential for scenarios requiring:
Long-lived organizational identity: Legal entities, businesses, and institutions that need persistent identifiers for building reputation, brand recognition, and trust relationships over years or decades. The vLEI (verifiable Legal Entity Identifier) system uses transferable identifiers to represent organizations with verifiable credentials.
High-security applications: Systems where key rotation is a security requirement rather than an option. Financial services, healthcare systems, and government applications benefit from the ability to rotate keys on regular schedules or in response to security events.
Multi-signature governance: Organizations with complex governance structures can use transferable identifiers with threshold signature schemes, rotating the composition of signers as organizational roles change.
Delegated authority hierarchies: Through delegation, transferable identifiers enable scalable authorization structures where parent identifiers delegate authority to child identifiers, with the ability to rotate keys at any level of the hierarchy.
The practical benefits of transferable identifiers include:
Operational continuity: Organizations can maintain the same identifier through personnel changes, security incidents, and infrastructure migrations. This continuity is critical for maintaining trust relationships and avoiding the disruption of identifier changes.
Security hygiene: Regular key rotation limits the exposure window for any given key pair. Even if keys are eventually compromised, the damage is limited to the period when those keys were active.
Cryptographic agility: As cryptographic algorithms evolve, transferable identifiers can migrate to stronger algorithms through rotation. This future-proofs identity systems against advances in cryptanalysis and quantum computing.
Disaster recovery: If signing keys are lost or compromised, the identifier can be recovered using pre-rotated keys that were stored separately. This provides a recovery mechanism without requiring external authorities.
Transferable identifiers involve important trade-offs:
Complexity vs. simplicity: Transferable identifiers require more complex key management than non-transferable identifiers. Organizations must securely manage both current signing keys and pre-rotated keys, implementing proper separation and backup procedures.
Governance overhead: The ability to rotate keys requires governance decisions about when and how to rotate, who has authority to initiate rotations, and what threshold requirements apply. This governance complexity is unnecessary for ephemeral identifiers.
Storage requirements: The complete KEL must be maintained and made available for verification. While individual KELs are compact, systems managing many transferable identifiers must account for storage and retrieval infrastructure.
Verification cost: Verifying a transferable identifier requires processing its complete KEL to establish current key state. For identifiers with many rotations, this verification cost is higher than for non-transferable identifiers that require only the inception event.
Key management burden: Secure management of pre-rotated keys requires careful operational procedures. These keys must be protected from compromise while remaining accessible for legitimate rotations—a challenging balance in practice.
Despite these trade-offs, transferable identifiers represent the appropriate choice for any scenario requiring persistent identity with long-term security. The additional complexity is justified by the security and operational benefits they provide. For short-lived, ephemeral use cases, non-transferable identifiers offer a simpler alternative without rotation capabilities.
Audit Trails: Maintain detailed logs of all key management operations, including key generation, storage, access, and rotation events. These logs are critical for security audits and incident response.
Compromise Response: If signing keys are compromised, immediately rotate using pre-rotated keys. If both signing and pre-rotated keys are compromised, the identifier may be unrecoverable, emphasizing the importance of proper key separation.