Key Event Log (KEL) Structure: A non-transferable identifier's KEL has a minimal structure:

• Exactly one establishment event (the inception event)
• Zero or more interaction events for anchoring external data
• No rotation events (by definition)

The inception event for a non-transferable identifier includes:

{
  "v": "KERI10JSON00011c_",
  "t": "icp",
  "d": "EXq5YqaL6L48pf0fu7IUhL0JRaU2_RxFP0AL43wYn148",
  "i": "BXq5YqaL6L48pf0fu7IUhL0JRaU2_RxFP0AL43wYn148",
  "s": "0",
  "kt": "1",
  "k": ["DXq5YqaL6L48pf0fu7IUhL0JRaU2_RxFP0AL43wYn148"],
  "nt": "0",
  "n": [],
  "bt": "0",
  "b": [],
  "c": [],
  "a": []
}

Key structural elements:

• nt: "0" indicates zero next key threshold (no rotation capability)
• n: Empty array (no pre-rotated key commitments)
• kt: Current key threshold (typically "1" for single-sig)
• k: Array of current public keys

Key Components

Derivation Code: The derivation code in the prefix explicitly signals non-transferability. Common codes include:

• B: Ed25519 non-transferable prefix
• 1AAA: ECDSA secp256k1 non-transferable prefix
• 1AAC: Ed448 non-transferable prefix

These codes are distinct from transferable identifier codes (like E for self-addressing transferable identifiers), allowing verifiers to immediately recognize the identifier's transferability status from the prefix alone.

Inception Configuration: The inception event's configuration fields establish the non-transferable nature:

• Next threshold (nt): Set to "0" or omitted
• Next keys (n): Empty array
• Witness configuration: May be empty (no witnesses required for non-transferable identifiers)

Control Authority: Control authority is permanently vested in the private key(s) corresponding to the public key(s) in the inception event. Loss or compromise of these keys results in permanent loss of control, as no recovery mechanism exists.

Data Format

Field Definitions

The inception event for a non-transferable identifier contains the following critical fields:

Version String (v): Specifies the KERI protocol version and serialization format (e.g., KERI10JSON00011c_)

Event Type (t): Always icp (inception) for the first and only establishment event

Event Digest (d): SAID of the inception event itself, providing content-addressability

Identifier Prefix (i): The non-transferable AID prefix, derived from the public key(s)

Sequence Number (s): Always "0" for inception

Current Key Threshold (kt): Number or fractional weight of signatures required from current keys

Current Keys (k): Array of qualified Base64-encoded public keys

Next Key Threshold (nt): Must be "0" for non-transferable identifiers

Next Keys (n): Must be empty array for non-transferable identifiers

Witness Threshold (bt): Number of witness receipts required (often "0" for non-transferable)

Witnesses (b): Array of witness AIDs (often empty for non-transferable)

Configuration Traits (c): Array of configuration strings (e.g., ["EO"] for establishment-only)

Anchors (a): Array of seals for anchoring external data

Encoding Format

Non-transferable identifiers use CESR (Composable Event Streaming Representation) encoding for all cryptographic primitives:

Text Domain: The identifier prefix in text domain uses Base64 URL-safe encoding:

BXq5YqaL6L48pf0fu7IUhL0JRaU2_RxFP0AL43wYn148

• First character B is the derivation code
• Remaining 43 characters encode the Ed25519 public key
• Total length: 44 characters (aligned to 24-bit boundaries)

Binary Domain: The same identifier in binary domain:

0x053e6b96a6ab8be3c65fd1fbbb2148b4d0945a536fd1c453f400b8e7c189f5f3

• First byte 0x05 encodes the derivation code
• Remaining 32 bytes are the raw Ed25519 public key
• Total length: 33 bytes

Serialization: The inception event can be serialized in multiple formats:

• JSON: Human-readable, used for debugging and text-based protocols
• CBOR: Compact binary format for efficient transmission
• MessagePack (MGPK): Alternative binary format

All serializations maintain field ordering for deterministic SAID computation.

Size and Constraints

Prefix Length: Varies by cryptographic algorithm:

• Ed25519 (code B): 44 characters (text) / 33 bytes (binary)
• ECDSA secp256k1 (code 1AAA): 48 characters (text) / 35 bytes (binary)
• Ed448 (code 1AAC): 80 characters (text) / 59 bytes (binary)

KEL Size: Minimal compared to transferable identifiers:

• Single inception event: ~200-400 bytes (JSON)
• Each interaction event: ~150-300 bytes (JSON)
• No rotation events (zero bytes)

Key Material:

• Ed25519: 32-byte private key, 32-byte public key
• ECDSA secp256k1: 32-byte private key, 33-byte compressed public key
• Ed448: 57-byte private key, 57-byte public key

Constraints:

• No key rotation: nt must be "0", n must be empty
• No delegation: Non-transferable identifiers cannot be delegated
• No recovery: Lost keys mean permanent loss of control
• Witness independence: Witnesses are optional and provide no recovery mechanism

Operations

Creation and Initialization

Key Generation: The first step in creating a non-transferable identifier is generating the cryptographic key pair:

import keri.core.coring as coring
import keri.core.eventing as eventing

# Generate a random salt for deterministic key derivation
salt = coring.Salter().qb64

# Create a key manager with the salt
mgr = keeping.Manager(ks=keystore, salt=salt)

# Generate key pair (icount=1 for single key, ncount=0 for no rotation keys)
verfers, digers, cst, nst = mgr.incept(icount=1, ncount=0)

The ncount=0 parameter explicitly signals that no pre-rotated keys should be generated, making this a non-transferable identifier.

Inception Event Creation: With the key pair generated, create the inception event:

# Create inception event with non-transferable configuration
srdr = eventing.incept(
    keys=[verfers[0].qb64],  # Current public key
    code=coring.MtrDex.Ed25519_Seed,  # Derivation code for Ed25519
    nxt="",  # Empty next key digest (non-transferable)
    toad=0,  # No witnesses required
    wits=[]  # No witness list
)

# The resulting prefix is non-transferable
aid_prefix = srdr.ked['i']  # e.g., "BXq5YqaL6L48pf0fu7IUhL0JRaU2_RxFP0AL43wYn148"

Keystore Storage: The private key must be securely stored:

# Store in encrypted keystore
keystore.put(keys=[(aid_prefix, verfers[0].qb64, signers[0].qb64)])

KEL Initialization: The inception event becomes the first and only establishment event in the KEL:

# Add inception event to KEL database
kever = eventing.Kever(serder=srdr, sigers=[siger], db=database)

Updates and Modifications

Interaction Events: While non-transferable identifiers cannot rotate keys, they can create interaction events to anchor external data:

# Create interaction event
ixn_srdr = eventing.interact(
    pre=aid_prefix,  # Identifier prefix
    dig=last_event_digest,  # Digest of previous event
    sn=sequence_number,  # Incremented sequence number
    data=[seal]  # Seal anchoring external data
)

# Sign the interaction event
siger = signers[0].sign(ser=ixn_srdr.raw, index=0)

# Append to KEL
kever.update(serder=ixn_srdr, sigers=[siger])

Interaction events maintain the KEL's append-only property and enable non-transferable identifiers to participate in KERI's data anchoring mechanisms without changing key state.

No Rotation Operations: Attempting to create a rotation event for a non-transferable identifier will fail validation:

# This will raise an error
try:
    rot_srdr = eventing.rotate(
        pre=aid_prefix,
        keys=[new_verfer.qb64],
        dig=last_event_digest,
        sn=sequence_number,
        nxt=next_key_digest
    )
except ValueError as e:
    print(f"Rotation not allowed: {e}")
    # Error: Non-transferable identifier cannot rotate keys

Abandonment: A non-transferable identifier can be explicitly abandoned by creating a final interaction event with specific configuration, though this is rarely necessary since the identifier is already non-transferable:

# Create abandonment interaction event
abandon_srdr = eventing.interact(
    pre=aid_prefix,
    dig=last_event_digest,
    sn=sequence_number,
    data=[],
    config=["EO"]  # Establishment-only configuration
)

Verification and Validation

Prefix Validation: Verifiers must check that the prefix correctly derives from the public key:

def verify_non_transferable_prefix(prefix: str, public_key: str) -> bool:
    """
    Verify that a non-transferable prefix correctly derives from its public key.
    """
    # Extract derivation code
    code = prefix[0]
    
    # Verify it's a non-transferable code
    if code not in ['B', '1AAA', '1AAC']:  # Non-transferable codes
        return False
    
    # Recompute prefix from public key
    verfer = coring.Verfer(qb64=public_key)
    computed_prefix = verfer.qb64
    
    # Compare with provided prefix
    return prefix == computed_prefix

Inception Event Validation: Verify the inception event structure:

def validate_non_transferable_inception(event: dict) -> bool:
    """
    Validate that an inception event creates a non-transferable identifier.
    """
    # Check event type
    if event['t'] != 'icp':
        return False
    
    # Check sequence number
    if event['s'] != '0':
        return False
    
    # Check next key threshold is zero
    if event['nt'] != '0':
        return False
    
    # Check next keys array is empty
    if len(event['n']) != 0:
        return False
    
    # Verify prefix derives from keys
    prefix = event['i']
    keys = event['k']
    
    # For single-sig, prefix should match first key
    if len(keys) == 1:
        return verify_non_transferable_prefix(prefix, keys[0])
    
    return True

Signature Verification: Verify signatures on events:

def verify_event_signature(event_serder, siger, verfer):
    """
    Verify a signature on a non-transferable identifier event.
    """
    # Verify signature using public key
    return verfer.verify(sig=siger.raw, ser=event_serder.raw)

KEL Validation: Validate the entire KEL for a non-transferable identifier:

def validate_non_transferable_kel(kel: list) -> bool:
    """
    Validate a complete KEL for a non-transferable identifier.
    """
    if len(kel) == 0:
        return False
    
    # First event must be inception
    if not validate_non_transferable_inception(kel[0]):
        return False
    
    # Extract prefix and keys from inception
    prefix = kel[0]['i']
    keys = kel[0]['k']
    
    # Verify no rotation events exist
    for event in kel[1:]:
        if event['t'] == 'rot':
            return False  # Rotation not allowed
        
        # Verify event prefix matches
        if event['i'] != prefix:
            return False
        
        # Verify sequence numbers increment
        # Verify digest chaining
        # Verify signatures
    
    return True

Usage Context

In Which Protocols

KERI Core Protocol: Non-transferable identifiers are fundamental primitives in KERI, used for:

1. Witness Identifiers: Witnesses in KERI typically use non-transferable identifiers because:
   • Witnesses are infrastructure components with stable endpoints
   • Security comes from the witness pool threshold, not individual key rotation
   • Simplifies witness management and reduces operational complexity

# Create witness with non-transferable identifier
witness_verfers, _, _, _ = mgr.incept(icount=1, ncount=0)
witness_srdr = eventing.incept(
    keys=[witness_verfers[0].qb64],
    code=coring.MtrDex.Ed25519,
    nxt="",
    toad=0,
    wits=[]
)
witness_aid = witness_srdr.ked['i']

2. Ephemeral Session Identifiers: For temporary peer-to-peer connections:

   • Short-lived communication sessions
   • One-time authentication tokens
   • Temporary service endpoints

3. Device-Specific Identifiers: For IoT devices or hardware tokens:

   • Bound to specific hardware security modules
   • No need for key rotation if device is replaced rather than updated
   • Simplified key management for constrained devices

ACDC (Authentic Chained Data Container): Non-transferable identifiers can serve as:

1. Credential Subjects: When the credential subject is ephemeral:

{
  "v": "ACDC10JSON00011c_",
  "d": "EXq5YqaL6L48pf0fu7IUhL0JRaU2_RxFP0AL43wYn148",
  "i": "BIssuerAID...",
  "s": "ESchemaAID...",
  "a": {
    "d": "EAttributeBlockSAID...",
    "i": "BNonTransferableSubjectAID...",
    "dt": "2024-01-15T12:00:00.000000+00:00",
    "LEI": "254900OPPU84GM83MG36"
  }
}

2. Temporary Issuers: For one-time credential issuance scenarios

OOBI (Out-Of-Band Introduction): Non-transferable identifiers in OOBI:

# OOBI for non-transferable witness
oobi = {
    "eid": "BNonTransferableWitnessAID...",
    "scheme": "http",
    "url": "http://witness.example.com:5642/"
}

DID:WEBS Method: Non-transferable identifiers can be used in did:webs for:

• Service endpoint identifiers
• Temporary delegation targets
• Witness pool members

Lifecycle Management

Creation Phase:

1. Generate cryptographic key pair
2. Create inception event with nt=0 and empty n array
3. Sign inception event
4. Store private key securely
5. Publish inception event (if using witnesses)

Active Phase:

1. Use identifier for intended purpose (authentication, signing, etc.)
2. Create interaction events as needed for data anchoring
3. Maintain private key security
4. Monitor for key compromise

Termination Phase:

1. Stop using the identifier
2. Optionally create final interaction event signaling abandonment
3. Securely delete private key material
4. Archive KEL for audit purposes

Key Compromise Handling:

Unlike transferable identifiers, non-transferable identifiers have no recovery mechanism from key compromise:

def handle_non_transferable_compromise(aid_prefix: str):
    """
    Handle compromise of non-transferable identifier keys.
    """
    # 1. Immediately stop using the identifier
    revoke_identifier_usage(aid_prefix)
    
    # 2. Notify relying parties (out-of-band)
    notify_relying_parties(aid_prefix, "COMPROMISED")
    
    # 3. Create new non-transferable identifier
    new_aid = create_new_non_transferable_identifier()
    
    # 4. Migrate to new identifier
    migrate_to_new_identifier(old_aid=aid_prefix, new_aid=new_aid)
    
    # 5. Securely delete compromised keys
    secure_delete_keys(aid_prefix)
    
    return new_aid

This lack of recovery is a fundamental trade-off: non-transferable identifiers are simpler and more efficient, but require replacement rather than rotation when compromised.

Related Structures

Transferable Identifiers: The complementary identifier type that supports key rotation:

• Use transferable identifiers for long-lived, high-value identities
• Use non-transferable identifiers for ephemeral, low-risk scenarios

Delegated Identifiers: Non-transferable identifiers can be delegation targets, but cannot themselves delegate:

# A transferable identifier can delegate to a non-transferable identifier
delegation_seal = {
    "i": "BNonTransferableDelegate...",
    "s": "0",
    "d": "EDelegateInceptionDigest..."
}

# But the non-transferable identifier cannot further delegate

Multi-Sig Identifiers: Non-transferable identifiers can use multi-sig:

# Create multi-sig non-transferable identifier
verfers, _, _, _ = mgr.incept(icount=3, ncount=0)  # 3 keys, no rotation
srdr = eventing.incept(
    keys=[v.qb64 for v in verfers],
    code=coring.MtrDex.Ed25519,
    nxt="",
    toad=0,
    wits=[],
    isith="2"  # 2-of-3 threshold
)

Witness Pools: Non-transferable identifiers typically don't use witnesses, but can:

# Non-transferable identifier with witnesses (rare)
srdr = eventing.incept(
    keys=[verfers[0].qb64],
    code=coring.MtrDex.Ed25519,
    nxt="",
    toad=2,  # Require 2 witness receipts
    wits=["BWitness1...", "BWitness2...", "BWitness3..."]
)

However, witnesses provide no additional security for non-transferable identifiers since there's no key rotation to witness.

Security Considerations

Threat Model

Key Compromise: The primary security risk for non-transferable identifiers:

• No recovery mechanism: Compromised keys mean permanent loss of control
• Mitigation: Use for low-value, short-lived scenarios only
• Detection: Monitor for unauthorized signatures or events

Impersonation Attacks: Attackers cannot create valid events without the private key:

• Protection: Cryptographic signatures prevent forgery
• Verification: All events must be signed by the inception key(s)

Replay Attacks: Old events could be replayed:

• Protection: Sequence numbers and digest chaining prevent replay
• Verification: Check event ordering and digest chain integrity

Best Practices

1. Use Case Selection: Only use non-transferable identifiers when:

   • The identifier is truly ephemeral (hours to days)
   • Key compromise risk is acceptable
   • Replacement is easier than rotation
   • Simplicity is more important than persistence

2. Key Management:

   • Generate keys with sufficient entropy (128+ bits)
   • Store private keys in secure enclaves when possible
   • Delete keys immediately after identifier abandonment
   • Never reuse keys across identifiers

3. Operational Security:

   • Monitor for unexpected events in the KEL
   • Implement key compromise detection mechanisms
   • Have incident response procedures for compromise
   • Maintain audit logs of identifier usage

4. Architecture Decisions:

   • Use transferable identifiers for organizational identities
   • Use non-transferable identifiers for infrastructure components
   • Consider delegation from transferable to non-transferable for operational flexibility
   • Document the rationale for choosing non-transferable

Performance Characteristics

Creation Speed: Non-transferable identifiers are faster to create:

• No pre-rotation key generation required
• Simpler inception event structure
• Typically 20-30% faster than transferable identifier creation

Verification Speed: Verification is simpler:

• No need to walk rotation history
• Single key state to verify
• Faster signature verification (no threshold calculations)

Storage Efficiency: Minimal storage requirements:

• Single inception event (~200-400 bytes)
• No rotation events
• Smaller KEL overall

Network Efficiency: Reduced bandwidth:

• Smaller KEL to transmit
• No witness coordination for rotations
• Simpler OOBI resolution

Comparison with Transferable Identifiers

Conclusion

Non-transferable identifiers represent a fundamental trade-off in KERI's design: simplicity and efficiency in exchange for persistence and recoverability. They are essential for scenarios where identifiers are truly ephemeral, where replacement is preferable to rotation, or where the operational complexity of key rotation is unjustified by the security requirements.

The key insight is that not all identifiers need to be persistent. By providing both transferable and non-transferable identifier types as composable primitives, KERI enables architects to choose the appropriate identifier type for each use case, optimizing the balance between security, complexity, and operational efficiency.

For production systems, the general guidance is:

• Use transferable identifiers for any identity that represents a persistent entity (person, organization, long-lived service)
• Use non-transferable identifiers for infrastructure components (witnesses), ephemeral sessions, or scenarios where identifier replacement is acceptable
• Consider delegation from transferable to non-transferable identifiers to combine the benefits of both approaches

Understanding non-transferable identifiers is essential for KERI developers, as they form one of the three core identifier primitives (along with transferable and delegated identifiers) that compose KERI's flexible, scalable key management infrastructure.

Performance Optimization

Non-transferable identifiers enable several optimizations:

1. Skip rotation history - No need to walk establishment event subsequence
2. Cache key state - Single key state never changes
3. Simplified verification - No threshold calculations or witness coordination
4. Reduced storage - Minimal KEL size

Security Considerations

Key Compromise: The primary risk is that compromised keys cannot be rotated:

• Mitigation: Use only for low-value, short-lived scenarios
• Detection: Implement monitoring for unexpected events
• Response: Have incident response procedures for immediate identifier replacement

Use Case Selection: Only use non-transferable identifiers when:

• The identifier is truly ephemeral (hours to days, not months to years)
• Key compromise risk is acceptable for the use case
• Replacement is operationally simpler than rotation
• The simplicity benefits outweigh the lack of persistence

Witness Configuration

While non-transferable identifiers CAN use witnesses, this is rarely beneficial:

• Witnesses provide no rotation security - Since rotation is not possible
• Witnesses add complexity - Without corresponding security benefit
• Typical configuration: toad=0, wits=[] (no witnesses)
• Exception: When witnesses are used for event promulgation, not security

Delegation Considerations

Non-transferable identifiers have limited delegation capabilities:

• Can be delegation targets - A transferable identifier can delegate to a non-transferable one
• Cannot delegate further - Non-transferable identifiers cannot be delegators
• Use case: Operational keys delegated from organizational identifiers

Testing Requirements

Implementations should include tests for:

1. Prefix derivation - Verify correct derivation codes are used
2. Inception validation - Verify nt=0 and n=[] constraints
3. Rotation rejection - Verify rotation events are rejected
4. Interaction events - Verify interaction events work correctly
5. Key compromise scenarios - Verify proper handling of compromised keys
6. Multi-sig configurations - Verify threshold signatures work correctly

Common Pitfalls

1. Using transferable derivation codes - Accidentally using E instead of B for Ed25519
2. Not validating nt=0 - Allowing inception events with non-zero next threshold
3. Attempting rotation - Trying to rotate keys on non-transferable identifiers
4. Over-using non-transferable - Using for long-lived identities that should be transferable
5. Under-securing keys - Not protecting private keys adequately despite lack of rotation

Migration Strategies

When migrating from a non-transferable to a transferable identifier:

1. Create new transferable identifier - Cannot convert existing non-transferable
2. Establish delegation - Optionally delegate from new transferable to old non-transferable
3. Migrate data - Update references to point to new identifier
4. Notify relying parties - Communicate identifier change
5. Abandon old identifier - Securely delete old keys after migration

Interoperability

When implementing non-transferable identifiers for interoperability:

• Follow KERI specification - Ensure compliance with KERI protocol
• Use standard derivation codes - Don't invent custom codes
• Validate strictly - Reject non-compliant inception events
• Document usage - Clearly document when non-transferable identifiers are used
• Test cross-implementation - Verify interoperability with other KERI implementations