In ACDC credentials, SCIDs serve as issuer identifiers (i field) and holder identifiers, providing cryptographic attribution for credential issuance and presentation.

Type Classification

SCIDs exist in multiple variants:

Basic SCID: The identifier directly includes or is derived from the public key with a derivation code prepended.

Self-Addressing SCID: Uses a cryptographic digest of inception data (including the public key and configuration) as the identifier.

Multi-Sig Self-Addressing: Supports multiple controlling keypairs with threshold signature schemes.

Delegated Self-Addressing: Enables hierarchical delegation relationships.

Autonomic Identifiers (AIDs): Enhanced SCIDs that support key rotation through pre-rotation mechanisms, making them persistent rather than ephemeral.

Cryptographic Properties

Underlying Algorithms

SCIDs leverage asymmetric cryptography (public-key cryptography) with several supported signature schemes:

Ed25519: The most common algorithm in KERI implementations

• Elliptic curve digital signature algorithm
• 32-byte (256-bit) public keys
• 64-byte signatures
• High performance and security

ECDSA secp256k1: Bitcoin-compatible signature scheme

• 33-byte compressed public keys
• Variable-length signatures

Ed448: Higher security variant

• 57-byte public keys
• 114-byte signatures

Derivation Process

The SCID derivation follows this cryptographic chain:

1. Entropy Generation: High-entropy random seed (minimum 128 bits of cryptographic strength)
2. Key Derivation: Seed → Private Key → One-Way Function → Public Key
3. Identifier Formation: Public Key → Derivation Code + Base64 Encoding → SCID

For self-addressing variants:

1. Inception Data Assembly: Public key + configuration + metadata
2. Digest Computation: One-way hash function (Blake3, SHA3, etc.) → Digest
3. Identifier Formation: Derivation Code + Base64(Digest) → SCID

Security Properties

Collision Resistance: The one-way functions used provide approximately 128 bits of cryptographic strength, making identifier collisions computationally infeasible.

Binding Strength: The cryptographic binding between identifier and key is as strong as the underlying hash function or signature scheme, typically providing 128-256 bits of security.

Uniqueness: Global uniqueness is achieved through cryptographic entropy rather than centralized coordination.

Non-Transferability (Basic SCIDs): Basic SCIDs are ephemeral—they cannot support key rotation. If the controlling private key is compromised, the identifier must be abandoned. This is a fundamental limitation that AIDs overcome through pre-rotation.

Verifiability: Any party can independently verify the identifier-to-key binding using only the identifier and the public key, without requiring access to external infrastructure.

Key/Output Sizes

Typical SCID sizes in CESR encoding:

• Ed25519 Basic SCID: 44 characters (1 derivation code + 43 Base64 characters)
• Blake3-256 Self-Addressing: 44 characters
• Multi-sig identifiers: Variable length depending on threshold configuration

Data Format & Encoding

CESR Encoding Format

All SCIDs in KERI are encoded using CESR (Composable Event Streaming Representation), which provides:

Qualified Representation: Every SCID includes a prepended derivation code that specifies the cryptographic algorithm used.

Composability: SCIDs can be concatenated with other primitives and converted between text and binary domains without loss.

Self-Framing: The derivation code indicates the length and type of the identifier, enabling parsers to extract it from streams without external delimiters.

Text Domain Representation

In the text domain, SCIDs use Base64 URL-safe encoding (RFC 4648):

Character Set: [A-Z, a-z, 0-9, -, _] (no padding = character)

Structure: <derivation-code><base64-encoded-key-or-digest>

Example: BF5pxRJP6THrUtlDdhh07hJEDKrJxkcR9m5u1xs33bhp

• B: Derivation code indicating Ed25519 non-transferable prefix
• Remaining 43 characters: Base64-encoded public key

Binary Domain Representation

In the binary domain, SCIDs are encoded as raw bytes:

Structure: <derivation-code-bytes><raw-key-or-digest-bytes>

Alignment: All primitives align on 24-bit boundaries (3 bytes) to enable lossless text-binary conversion.

Derivation Codes

Common derivation codes for SCIDs:

• B: Ed25519 non-transferable prefix (basic SCID)
• D: Ed25519 public verification key
• E: Blake3-256 digest (self-addressing)
• F: Blake2b-256 digest
• 1AAA: ECDSA secp256k1 non-transferable prefix
• 1AAC: Ed448 non-transferable prefix

The derivation code enables cryptographic agility—the system can support multiple algorithms while maintaining unambiguous verification.

Prefix Structure

The SCID serves as a prefix in KERI, establishing the identifier's cryptographic foundation. The prefix structure creates a binding between:

1. The derivation process (algorithm)
2. The public key material
3. The resulting identifier

This binding is fundamental to KERI's self-certifying property.

Usage in KERI/ACDC

In Key Event Logs (KELs)

Inception Events: The SCID is established in the inception event, which is the first entry in a KEL. For basic SCIDs, the identifier prefix is derived directly from the initial public key. For self-addressing SCIDs, the identifier is the digest of the entire inception event.

Identifier Field (i): Every key event includes the i field containing the SCID, establishing which identifier the event pertains to.

Controller Identification: The SCID identifies the controller of the identifier throughout the KEL's history.

In ACDC Credentials

Issuer Identifier (i field): The SCID of the credential issuer, enabling cryptographic verification of the issuer's identity and authority.

Holder/Issuee Identifier: In targeted credentials, the SCID identifies the credential subject.

Chaining: SCIDs enable ACDC chaining through cryptographic references, forming verifiable provenance chains.

Common Usage Patterns

Direct Mode: In KERI's direct mode, two controllers exchange key events directly, with each controller's SCID serving as the cryptographic anchor for verification.

Indirect Mode: In indirect mode, witnesses and watchers verify events associated with SCIDs, providing distributed consensus.

Delegation: SCIDs can be delegated, creating hierarchical trust structures where a parent SCID delegates authority to child SCIDs.

Multi-Signature: Multiple SCIDs can collectively control a single identifier through threshold signature schemes.

Verification Procedures

Basic SCID Verification:

1. Extract the derivation code from the identifier
2. Decode the Base64-encoded public key
3. Verify that signatures on events validate against the extracted public key
4. Confirm the identifier matches the expected derivation from the public key

Self-Addressing SCID Verification:

1. Retrieve the inception event data
2. Compute the digest of the inception event using the algorithm specified by the derivation code
3. Verify the computed digest matches the identifier
4. Verify event signatures using the public key(s) from the inception event

AID Verification (for transferable identifiers):

1. Verify the inception event establishes the initial SCID
2. Process the KEL sequentially, verifying each rotation event
3. Confirm pre-rotation commitments are properly revealed
4. Verify the current key state matches the latest establishment event

Related Primitives

Autonomic Identifiers (AIDs)

AIDs are enhanced SCIDs that overcome the ephemeral limitation through key rotation support. The relationship:

SCID + Key Event Log = AID

AIDs maintain the self-certifying property while adding:

• Pre-rotation for key recovery
• Persistent control despite key compromise
• Transferable control authority

Self-Addressing Identifiers (SAIDs)

SAIDs are content-addressable identifiers where the identifier is a digest of the data it identifies. SCIDs can be self-addressing when the identifier is derived from a digest of inception data rather than directly from the public key.

Cryptonyms

SCIDs are a specific type of cryptonym—cryptographic pseudonymous identifiers. All SCIDs are cryptonyms, but not all cryptonyms are necessarily self-certifying.

Prefixes

In KERI terminology, SCIDs serve as prefixes that establish the cryptographic foundation for identifiers. The prefix includes both the derivation code and the key material.

Composition Patterns

Delegation Chains: SCIDs can form hierarchical structures where parent SCIDs delegate authority to child SCIDs, creating verifiable delegation trees.

Multi-Signature Composition: Multiple SCIDs can be composed into threshold signature schemes, requiring M-of-N signatures for valid operations.

Credential Chains: In ACDC systems, SCIDs link credentials together, forming verifiable provenance chains from root issuers through intermediaries to end holders.

Implementation Notes

Key Generation Requirements

Entropy Sources: Use cryptographically secure random number generators (CSPRNG) with at least 128 bits of entropy for seed generation.

Key Derivation: Follow standard cryptographic practices for deriving keypairs from seeds. For hierarchical deterministic keys, use established standards like BIP32/BIP39.

Storage Security: Private keys must be stored securely, ideally in hardware security modules (HSMs) or trusted execution environments (TEEs) for high-value identifiers.

Identifier Creation

Derivation Code Selection: Choose the appropriate derivation code based on:

• Security requirements (key size, algorithm strength)
• Interoperability needs (common algorithms vs. specialized)
• Performance constraints (signature generation/verification speed)

Inception Event Construction: For self-addressing SCIDs, carefully construct the inception event to include all necessary configuration data before computing the digest.

Witness Configuration: For AIDs, configure witness pools during inception to enable indirect mode operation.

Verification Implementation

Caching: Implement caching for verified SCIDs to avoid redundant cryptographic operations, but ensure cache invalidation on key rotations.

Error Handling: Distinguish between:

• Invalid signatures (cryptographic failure)
• Incorrect identifier derivation (malformed SCID)
• Missing or inaccessible key material (operational failure)

Performance Optimization: Batch verification operations when processing multiple events or credentials to amortize cryptographic overhead.

Security Considerations

Key Compromise Detection: For basic SCIDs, any compromise of the private key is catastrophic—the identifier must be abandoned. Implement monitoring for unauthorized signatures.

Upgrade Path: Basic SCIDs cannot be upgraded to AIDs. Plan identifier lifecycle from inception, choosing transferable identifiers when long-term persistence is required.

Delegation Security: When implementing delegated SCIDs, ensure both delegator and delegate participate in the delegation event (cooperative delegation).

Witness Selection: For AIDs, carefully select witnesses to ensure:

• Geographic and jurisdictional diversity
• Independent operation (no collusion)
• Adequate threshold of accountable duplicity (TOAD)

Interoperability

DID Methods: SCIDs can be represented as DIDs using methods like did:keri and did:webs, enabling interoperability with W3C DID infrastructure.

CESR Compatibility: Ensure all SCID implementations properly support CESR encoding for interoperability across KERI implementations (keripy, keriox, keride).

Schema Validation: When using SCIDs in ACDC credentials, validate against the appropriate JSON Schema to ensure structural correctness.

Testing Strategies

Test Vectors: Use standardized test vectors to verify correct SCID derivation across implementations.

Fuzzing: Fuzz parsers with malformed SCIDs to ensure robust error handling.

Interoperability Testing: Cross-test SCID generation and verification across different KERI implementations to ensure compatibility.

Performance Benchmarking: Measure signature generation/verification throughput to ensure acceptable performance for target use cases.

CESR Compliance: Strictly adhere to CESR encoding rules to ensure interoperability across KERI implementations. Test with multiple implementations (keripy, keriox, keride).

DID Method Mapping: When exposing SCIDs as DIDs, use did:keri for KERI-native identifiers or did:webs for web-hosted identifiers with KERI security.

Schema Validation: Validate SCID structure against CESR specifications before use in KELs or ACDCs to catch encoding errors early.

Testing Requirements

Test Vector Validation: Use official KERI test vectors to verify correct SCID derivation and verification across implementations.

Fuzzing: Fuzz SCID parsers with malformed inputs to ensure robust error handling and prevent crashes or security vulnerabilities.

Cross-Implementation Testing: Verify that SCIDs generated by one implementation can be verified by others to ensure ecosystem interoperability.