Configuration traits utilize a specialized CESR primitive called the Config Trait List Counter (mentioned in Doc 1, Doc 4). This counter code specifies the number of configuration trait strings in the list, enabling efficient parsing of the c field in serialized event streams.

CESR (Composable Event Streaming Representation) provides the encoding infrastructure for all KERI primitives, including configuration traits. The CESR specification (Doc 11) establishes that primitives must be self-framing—meaning the encoding itself contains sufficient information for a parser to extract the primitive atomically from a stream without external schema knowledge.

For configuration traits specifically:

• The Config Trait List Counter uses CESR's group framing code mechanism
• This allows the parser to determine how many trait strings follow
• Each trait string is represented as a text primitive within the CESR stream
• The entire configuration traits field can be parsed as a discrete unit within the larger establishment event structure

Role in Establishment Events

Inception Events

Configuration traits first appear in the inception event (Doc 5, Doc 6, Doc 20-22, Doc 25-28), which creates the AID and establishes its initial key state. The inception event structure includes:

v: version string (KERI10JSON)
t: "icp" (event type)
d: SAID of the event
i: identifier prefix
s: "0" (sequence number)
kt: current signing threshold
k: current key list
nt: next threshold
n: next key digest list
bt: witness threshold
b: witness backers
c: configuration traits array
a: seal array

The c field in the inception event establishes traits that define the identifier's operational behavior. Once set in inception, certain traits become immutable properties of the identifier throughout its lifecycle.

Rotation Events

Rotation events (Doc 5, Doc 6, Doc 30) can potentially modify configuration traits, though the specification does not explicitly detail which traits are mutable versus immutable in the provided excerpts. The rotation event structure mirrors inception with modifications:

v: version string
t: "rot" (event type)
d: SAID of the event
i: identifier prefix
s: sequence number (incremented)
p: prior event digest
kt: new current threshold
k: new current key list
nt: new next threshold
n: new next key digest list
bt: witness threshold
b: witness backers
c: configuration traits array
a: seal array

The presence of the c field in rotation events indicates that configuration traits are part of the mutable key state, though the constraints on what can change are not detailed in the available documentation.

Relationship to Key State and Validation

Configuration traits participate in KERI's event validation mechanism through several pathways:

Cryptographic Commitment

Configuration traits are cryptographically committed through the event's SAID (Self-Addressing IDentifier). The SAID derivation process (Doc 24) includes all top-level fields of the establishment event, including the c field. This creates an immutable cryptographic binding:

1. The configuration traits array is serialized as part of the event
2. The complete event is hashed to derive the SAID
3. The SAID is placed in the d field
4. The event (now containing its own digest) is signed by the controller

Any modification to configuration traits would change the SAID, invalidating the controller's signature and making tampering detectable.

Validator Requirements

Validators processing a KEL must:

• Parse configuration traits from establishment events
• Verify that subsequent events conform to constraints declared by the traits
• Maintain trait state as part of the current key state
• Apply trait-based validation rules when processing non-establishment events

The specification (Doc 5, Doc 6) emphasizes that validators perform end-to-end verification without relying on trusted intermediaries, meaning configuration traits must be self-describing and unambiguous.

Witness and Infrastructure Configuration

Configuration traits work in conjunction with witness-related fields to establish the identifier's infrastructure requirements. The witness configuration in establishment events includes:

• wt (witness threshold): Minimum number of witness receipts required
• w (witness list): Array of witness AIDs
• bt (backer threshold): For ledger-backed identifiers
• b (backer list): For ledger-backed identifiers

Configuration traits in the c field may interact with these witness fields to declare additional operational modes. For example, traits might specify:

• Whether the identifier requires witnesses (direct vs. indirect mode)
• Whether witnesses must provide receipts for all event types or only establishment events
• Whether the identifier supports delegation operations

The exact trait strings for these behaviors are not enumerated in the provided documentation.

Interaction with Other KERI Mechanisms

Delegation

Configuration traits may control delegation capabilities (mentioned conceptually in Docs 5-6, 12, 26-27, 30 regarding delegation mechanisms). KERI supports hierarchical identifier structures where one AID delegates authority to create other AIDs. Configuration traits would declare:

• Whether the identifier can act as a delegator
• Whether the identifier can be a delegate
• Constraints on delegation depth or structure

The partial rotation mechanism (Doc 30) enables sophisticated delegation scenarios, and configuration traits likely interact with this to define delegation boundaries.

Transferability

A fundamental distinction in KERI identifiers is transferability—whether the identifier supports key rotation. The specification (Doc 26, Doc 27, Doc 28) defines:

• Transferable identifiers: Support key rotation through establishment events containing next key commitments
• Non-transferable identifiers: Cannot rotate keys; the inception keys remain authoritative permanently

Configuration traits are the mechanism that declares this property. A non-transferable identifier would have traits indicating:

• No next key digest field (n) is present or it contains an empty commitment
• No rotation events are valid for this identifier
• The identifier is intended for ephemeral, single-use scenarios

The vLEI technical requirements (Doc 16, Doc 17) for GLEIF's implementation reference configuration traits in the context of establishing QVI (Qualified vLEI Issuer) identifiers and their delegated structures, though specific trait values are not provided.

Implementation Considerations

Parsing and Stream Processing

The CESR encoding of configuration traits enables efficient stream processing. The cesride Rust implementation (Doc 29) and KERIox changelog (Doc 31) demonstrate practical parsing requirements:

• Configuration traits appear as a counted array in the CESR stream
• The Config Trait List Counter precedes the trait strings
• Each trait string is a qualified CESR text primitive
• Parsers extract the count, then iterate to extract each trait string

The "sniffable" property of CESR streams (Doc 11) means parsers can detect the presence of configuration traits without pre-existing schema knowledge by examining the count code.

Database Storage

KERI implementations store configuration traits as part of the identifier's key state. The KERIox migration to redb (Doc 31) shows that configuration traits are:

• Stored with IdentifierState structures
• Serialized using rkyv traits for efficient binary representation
• Retrieved when reconstructing key state from stored events
• Used in validation logic when processing new events

Specification Status and Evolution

The configuration traits mechanism is defined in the core KERI specification maintained by the Trust Over IP Foundation (Doc 4, Doc 6, Doc 18, Doc 19, Doc 28). The specification is under active development:

• Version 0.9 Draft status as of the provided documentation
• Subject to 18-month backward compatibility requirements in vLEI governance (Doc 16, Doc 17)
• New configuration traits may be added through specification updates
• Implementations must handle unknown traits gracefully for forward compatibility

The vLEI governance framework (Doc 16, Doc 17) establishes that:

• KERI specification versions must be implemented within 12 months of approval
• Previous versions must be supported for 18 months
• This ensures configuration traits defined in older specifications remain valid during migration periods

Relationship to Standards and Interoperability

DID Method Integration

The did:keri method specification (Doc 22) establishes how KERI identifiers map to W3C Decentralized Identifiers. Configuration traits influence this mapping:

• Traits affect the DID Document structure generated from key state
• Traits determine service endpoint configurations
• Traits may control which verification methods appear in the DID Document

The did:keri method treats the KEL as authoritative, with DID Documents being derived representations. Configuration traits in the KEL therefore directly determine DID Document properties.

Transaction Event Logs (TELs)

Configuration traits may interact with TEL (Transaction Event Log) specifications (Doc 20, Doc 21). TELs anchor to KELs through cryptographic seals, and configuration traits could:

• Declare whether an identifier supports TEL issuance
• Specify TEL management policies
• Control credential registry behaviors

The public TEL specification (Doc 21) for verifiable credential registries relies on the KEL's establishment events, including configuration traits, to authorize TEL operations.

Limitations of Available Documentation

The provided documentation excerpts do not include:

• Complete enumeration of valid trait strings: The specific trait values (e.g., "EO" for establishment-only, "DND" for do-not-delegate) are not defined in the available text
• Trait semantics: Detailed behavioral specifications for each trait are referenced but not included
• Mutability rules: Which traits can be modified through rotation versus which are immutable after inception
• Validation algorithms: Step-by-step procedures for applying trait-based validation logic

These details are presumably contained in the "Configuration traits field" section referenced by the glossary entries (Docs 1-4) but not present in the provided excerpts. Implementers must consult the complete KERI specification at https://github.com/trustoverip/tswg-keri-specification for authoritative trait definitions.

Related Terms and Cross-References

• Key State: Configuration traits are a component of the overall key state that validators maintain
• Establishment Events: The only event types that can declare or modify configuration traits
• CESR Primitives: Configuration traits are encoded using CESR count codes and text primitives
• Witness Configuration: Configuration traits work alongside witness threshold and witness list fields
• Transferable Identifier: Transferability is declared through configuration traits
• Delegation: Delegation capabilities are controlled by configuration traits
• Key Event Log: Configuration traits represent a configuration of the KEL as stated in the definition

Conclusion

Configuration traits provide a declarative metadata mechanism for establishing operational characteristics of KERI identifiers. While the available documentation establishes the structural role and encoding of configuration traits within establishment events, the specific trait strings and their detailed semantics are not enumerated in the provided excerpts. Implementers should treat configuration traits as:

• Cryptographically committed: Through SAID binding and controller signatures
• Validator-enforced: Requiring consistent application of trait-based rules
• Infrastructure-defining: Controlling witness requirements and delegation capabilities
• Specification-defined: Requiring reference to the complete KERI specification for authoritative trait definitions

The Config Trait List Counter mechanism enables efficient CESR encoding and stream processing, while the integration with key state ensures configuration traits participate in KERI's end-to-end verifiability guarantees.