The distinction between transferable and non-transferable identifiers became particularly important with the development of Self-Sovereign Identity (SSI) systems, where different use cases require different persistence and control transfer properties.

KERI's Approach

Non-Transferable Identifiers in KERI

KERI explicitly supports non-transferable identifiers as a distinct identifier type with specific architectural characteristics. According to the KERI specification, a non-transferable identifier is created when:

• The inception event sets ncount=0 (zero next keys)
• The next threshold nsith=0 (zero rotation threshold)
• No pre-rotated keys are committed in the inception event

This configuration creates an AID (Autonomic Identifier) that is cryptographically bound to its initial key pair with no mechanism for key rotation. The identifier's KEL (Key Event Log) will contain only the inception event and any subsequent interaction events, but no rotation events.

Practical Characteristics

KERI's non-transferable identifiers exhibit several advantageous properties for specific use cases:

Short-lived: Designed for temporary interactions where long-term persistence is not required. The identifier can be safely discarded after its purpose is fulfilled without concern for key management or recovery.

Peer-to-peer: Ideal for direct entity-to-entity communications where the relationship is ephemeral and does not require persistent identity across sessions.

One-time use: Suitable for single-purpose scenarios such as:

• Temporary session identifiers
• Single-transaction authentication
• Ephemeral communication channels
• Disposable credentials for limited-scope interactions

Discardable: Can be abandoned without complex key revocation procedures. Since there's no rotation capability, there's no risk of unauthorized future use if the identifier is simply discarded.

Witness Infrastructure

Interestingly, KERI's witness infrastructure commonly uses non-transferable identifiers. According to the vLEI Ecosystem Governance Framework Technical Requirements, witnesses typically employ non-transferable AIDs because:

• Witness security relies on the witness pool threshold structure rather than individual key rotation
• The pool-based approach provides redundancy and fault tolerance
• Compromised witness identifiers can be removed from the pool without requiring rotation
• Simplified key management reduces operational complexity for witness operators

Identifier Abandonment

KERI also supports converting a transferable identifier into a non-transferable one through the abandoned identifier mechanism. An AID becomes abandoned when:

• A rotation event sets the next key digest list to empty (ndigers=0)
• The next threshold is set to zero (nsith=0)
• Any subsequent events after the abandonment are rejected by validators

This provides a cryptographically verifiable way to permanently terminate an identifier's lifecycle while maintaining the integrity of its historical event log.

Practical Implications

Use Cases for Non-Transferable Identifiers

1. Ephemeral Sessions

Non-transferable identifiers excel in scenarios requiring temporary authentication:

• Web session identifiers that expire after logout
• API tokens for single-use operations
• Temporary access credentials for time-limited resources

The lack of rotation capability is not a limitation here because the identifier's lifetime is intentionally brief.

2. Witness and Infrastructure Nodes

As noted in KERI's architecture, witness nodes benefit from non-transferable identifiers because:

• Security comes from pool-level redundancy rather than individual key rotation
• Simplified operations reduce attack surface
• Compromised witnesses can be replaced rather than rotated

3. Single-Purpose Credentials

Certain credentials are inherently non-transferable by design:

• Educational degrees (should not be transferred between individuals)
• Professional certifications (bound to specific persons)
• Membership credentials (non-assignable to others)

While the underlying identifier might be transferable, governance frameworks can enforce non-transferability at the credential level.

4. Privacy-Preserving Interactions

Non-transferable identifiers support privacy through:

• Pairwise identifiers for each relationship
• Disposable identifiers that prevent correlation across contexts
• Minimal persistent identity footprint

Benefits

Simplicity: Non-transferable identifiers have significantly simpler key management requirements. There's no need for:

• Pre-rotation key generation and secure storage
• Rotation event processing and validation
• Key recovery procedures
• Delegation hierarchies

Performance: Validation of non-transferable identifiers requires only:

• Verification of the inception event
• Signature validation against the single key pair
• No need to process rotation history

This makes verification faster and more efficient, particularly important for high-volume scenarios.

Security Model: For ephemeral use cases, non-transferability can enhance security:

• No long-term key storage requirements
• Reduced exposure window for key compromise
• Simplified threat model (no rotation attacks possible)

Trade-offs

No Recovery: If the private key is lost or compromised, the identifier is permanently unusable. There is no rotation mechanism to recover control.

Limited Lifespan: Non-transferable identifiers are unsuitable for long-term persistent identity where key rotation is a security necessity.

No Delegation: The lack of rotation capability also prevents delegation hierarchies, limiting organizational use cases.

Governance Constraints: For credentials that must remain valid over extended periods, non-transferable identifiers create challenges:

• Key compromise requires credential reissuance with new identifier
• No mechanism for cryptographic algorithm migration
• Vulnerable to long-term cryptographic advances (quantum computing)

Comparison with Transferable Identifiers

The choice between transferable and non-transferable identifiers represents a fundamental architectural decision:

Governance and Legal Considerations

Beyond technical non-transferability, governance frameworks can impose non-transferability requirements on otherwise transferable identifiers. The vLEI Ecosystem Governance Framework demonstrates this through:

Credential-Level Restrictions: Even though the underlying AIDs are transferable, certain vLEI credentials are designated as non-transferable:

• Legal Entity vLEI Credentials are bound to specific legal entities
• Official Organizational Role (OOR) credentials cannot be transferred between individuals
• Engagement Context Role (ECR) credentials are person-specific

Contractual Enforcement: The vLEI governance framework uses contractual mechanisms to enforce non-transferability:

• Chain-link confidentiality provisions
• Terms of use that prohibit credential transfer
• Revocation mechanisms for unauthorized transfers

This demonstrates that non-transferability can be a policy layer on top of technically transferable infrastructure, providing flexibility in governance models.

Conclusion

Non-transferable identifiers represent a fundamental primitive in KERI's composable architecture, optimized for ephemeral, single-purpose use cases where the complexity of key rotation is unnecessary or undesirable. By explicitly supporting both transferable and non-transferable identifier types, KERI enables developers to choose the appropriate security and persistence model for their specific requirements.

The distinction between transferable and non-transferable identifiers is not merely technical—it reflects different trust models, use cases, and governance requirements. Understanding when to use each type is essential for designing secure, efficient identity systems that balance security, usability, and operational complexity.

• Appropriate key storage security for the identifier's intended lifetime
• Clear key destruction procedures when identifier is discarded
• Monitoring for unauthorized use after intended expiration

Lifetime Management: Implement explicit lifetime tracking:

• Timestamp inception events
• Define maximum validity periods
• Implement automatic expiration mechanisms
• Clear disposal procedures for expired identifiers

Governance Integration

When implementing governance frameworks with non-transferable requirements:

• Distinguish between technical non-transferability (identifier level) and policy non-transferability (credential level)
• Implement contractual enforcement mechanisms for policy-level restrictions
• Use credential schemas that explicitly mark non-transferable credentials
• Implement revocation mechanisms for unauthorized transfers