The public verifiable credential registry architecture is formally specified in:

• IETF Draft: Public Transaction Event Logs (PTEL) by Phil Feairheller (draft-pfeairheller-ptel)
• KERIpy TEL Reference Implementation (github:WebOfTrust/keripy/ref/tel.md)
• vLEI Ecosystem Governance Framework Technical Requirements Part 1 (KERI Infrastructure specifications)

These specifications establish the normative requirements for implementing public credential registries within the KERI protocol suite.

Critical Scope Limitation

The PTEL specification explicitly states: "This document addresses public VCs only. The use of hash digests of VC contents allows for correlation of VC uses." This design choice acknowledges that public registries sacrifice privacy for verifiability. The use of content digests as identifiers means that multiple presentations of the same credential can be correlated, making this architecture unsuitable for privacy-preserving credential use cases. For private credentials, alternative architectures using blinded revocation registries with salty nonce blinding factors are required.

Version History and Evolution

The public verifiable credential registry architecture evolved through several phases:

1. Initial KEL-only Phase: Early KERI focused solely on identifier control authority
2. TEL Introduction: Recognition that credential lifecycle management required separate event logs
3. Management/VC TEL Separation: Architectural refinement separating registry management from individual credential tracking
4. PTEL Standardization: Formalization of public registry patterns in IETF draft specifications
5. vLEI Implementation: Real-world deployment in GLEIF's verifiable Legal Entity Identifier ecosystem

The architecture continues to evolve with ongoing work on privacy-preserving variants and enhanced registry discovery mechanisms.

Protocol Architecture

Layered Architecture Model

The public verifiable credential registry implements a three-layer architecture that separates concerns between identifier control, registry management, and individual credential tracking:

Layer 1: Key Event Log (KEL) - Control Authority Layer

• Establishes cryptographic control over the issuing identifier (AID)
• Provides key rotation and delegation capabilities
• Signs TEL events and verifiable credentials
• Serves as the ultimate root of trust for the entire registry

Layer 2: Management TEL - Registry Infrastructure Layer

• Signals the creation of the verifiable credential registry (VCR)
• Tracks the list of Registrars (backers) for individual credential TELs
• Manages registry-level configuration and policies
• Provides the infrastructure foundation for credential tracking

Layer 3: VC TEL - Credential State Layer

• Tracks the issued or revoked state of each individual verifiable credential
• Contains references to the corresponding management TEL
• Implements the actual credential lifecycle state machine
• Provides the queryable interface for credential status verification

Component Organization

The registry architecture comprises several key components:

KEL Controller: The entity controlling the issuing AID, responsible for:

• Generating and signing key events
• Creating cryptographic commitments to TEL events via seals
• Maintaining the authoritative key state

Registrars (Backers): Analogous to witnesses in KERI KELs, registrars:

• Provide persistence and availability for TEL events
• Act as secondary roots of trust for credential state
• Enable distributed consensus on credential status
• Can be implemented using various backend technologies (witnesses, ledgers)

TEL Event Processors: Components that:

• Parse and validate TEL event streams
• Verify cryptographic anchoring to KELs
• Maintain current state views of credential registries
• Detect duplicity in credential state claims

Verifiers: External parties that:

• Query credential status from registries
• Validate cryptographic proofs of state
• Make trust decisions based on verified status

Data Flow Architecture

The data flow through a public verifiable credential registry follows this pattern:

1. Credential Issuance Flow:

   • Issuer creates credential and generates content digest
   • Issuer creates VC TEL inception event with credential identifier
   • Issuer creates KEL interaction/rotation event with seal to VC TEL event
   • Issuer signs KEL event, cryptographically committing to VC TEL event
   • Registrars receive and store both KEL and VC TEL events
   • Registry state transitions to "issued"

2. Credential Revocation Flow:

   • Issuer creates VC TEL revocation event
   • Issuer creates KEL event with seal to revocation event
   • Issuer signs KEL event, committing to revocation
   • Registrars update stored state
   • Registry state transitions to "revoked"

3. Credential Verification Flow:

   • Verifier receives credential presentation
   • Verifier queries registry for credential status
   • Verifier retrieves VC TEL and validates anchoring to KEL
   • Verifier validates KEL signatures and key state
   • Verifier determines current credential status

State Management Approach

The registry implements a deterministic state machine for credential lifecycle:

State Transitions:

• Unissued → Issued: Via VC TEL inception event
• Issued → Revoked: Via VC TEL revocation event
• Revoked → [Terminal]: Revocation is typically irreversible

State Representation:

• Current state is determined by replaying the VC TEL from inception
• Each event is cryptographically anchored to a KEL event
• State transitions are monotonic (no rollback without key compromise detection)
• State is eventually consistent across all registrars

State Verification:

• Verifiers independently compute state by replaying events
• Cryptographic anchoring ensures state authenticity
• Duplicity detection mechanisms identify conflicting state claims
• First-seen policies protect against certain attack vectors

Message Formats & Encoding

TEL Event Structure

All TEL events share a common structure with KEL events but serve different purposes. The fundamental fields are:

Common Fields (present in all TEL events):

• i (Identifier): The AID of the TEL controller (typically the credential issuer)
• s (Sequence Number): The sequence number in the TEL (independent of KEL sequence)
• t (Event Type): The type of TEL event (vcp, vrt, iss, rev, bis, brv)

Critical Distinction: The s field in TEL events represents a registry-specific "clock" rather than following KEL sequence numbering. Each registry maintains its own independent sequencing, which can be based on:

• Monotonically increasing integers (most common for credential registries)
• Bitcoin block height (for ledger-backed registries)
• Wall clock timestamps (for time-based registries)
• Other domain-specific ordering mechanisms

This independence allows TEL events to be anchored to any KEL event (interaction or rotation) without requiring strict sequence alignment.

Registry Management Event Types

The Management TEL uses specific event types for registry lifecycle management:

vcp (VDR Inception / Registry Inception):

{
  "v": "KERI10JSON000116_",
  "t": "vcp",
  "d": "ELvaU6Z-i0d8JJR2nmwyYAZAoTNZH3UfSVPzhzS6b5CM",
  "i": "EpDA1n-WiBA0A8YOqnKrB-wWQYYC49i5zY_qrIZIicQg",
  "ii": "EJJR2nmwyYAZAoTNZH3ULvaU6Z-i0d8fSVPzhzS6b5CM",
  "s": "0",
  "bt": "2",
  "b": [
    "BGKVzj4ve0VSd8z_AmvhLg4lqcC_9WF93Saq",
    "BuyRFMideczFZoapylLIyCjSdhtqVb2U_R"
  ],
  "c": ["NB"]
}

Key fields:

• ii: Issuer identifier (the AID that will issue credentials)
• bt: Backer threshold (number of registrars required)
• b: Backer list (registrar AIDs)
• c: Configuration traits (e.g., "NB" for non-backers allowed)

vrt (VDR Rotation / Registry Rotation): Allows rotation of the registrar set, similar to witness rotation in KELs.

Credential Lifecycle Event Types

The VC TEL uses event types specific to credential state management:

iss (Issuance Event - Non-Registry-Backed):

{
  "v": "KERI10JSON000116_",
  "t": "iss",
  "d": "E8JZAoTNZH3ULvaU6Z-i0d8fSVPzhzS6b5CMJR2nmwy",
  "i": "EpDA1n-WiBA0A8YOqnKrB-wWQYYC49i5zY_qrIZIicQg",
  "s": "0",
  "ri": "ELvaU6Z-i0d8JJR2nmwyYAZAoTNZH3UfSVPzhzS6b5CM",
  "dt": "2021-01-01T00:00:00.000000+00:00"
}

Key fields:

• ri: Registry identifier (SAID of the management TEL inception event)
• dt: Datetime of issuance (ISO 8601 format)

rev (Revocation Event - Non-Registry-Backed):

{
  "v": "KERI10JSON000116_",
  "t": "rev",
  "d": "EYOqnKrB-wWQYYC49i5zY_qrIZIicQgpDA1n-WiBA0A8",
  "i": "EpDA1n-WiBA0A8YOqnKrB-wWQYYC49i5zY_qrIZIicQg",
  "s": "1",
  "p": "E8JZAoTNZH3ULvaU6Z-i0d8fSVPzhzS6b5CMJR2nmwy",
  "dt": "2021-06-01T00:00:00.000000+00:00"
}

Key fields:

• p: Prior event digest (links to previous VC TEL event)
• dt: Datetime of revocation

bis (Backers Issuance - Registry-Backed): Similar to iss but includes registrar receipts for enhanced trust.

brv (Backers Revocation - Registry-Backed): Similar to rev but includes registrar receipts.

The distinction between registry-backed (bis/brv) and non-backed (iss/rev) events allows for flexible trust models where some credentials require distributed consensus while others rely solely on issuer authority.

Event Source Seals

TEL events are anchored to KEL events using Event Source Seals, which provide the cryptographic binding between the two log structures. The seal structure is:

JSON Representation:

{
  "s": "3",
  "d": "ELvaU6Z-i0d8JJR2nmwyYAZAoTNZH3UfSVPzhzS6b5CM"
}

Where:

• s: Sequence number of the TEL event being anchored
• d: SAID (digest) of the TEL event being anchored

CESR Encoding: Event source seals are delivered as attachments in CESR format using event source seal triples (duples of sequence number and digest):

-GAB
0AAAAAAAAAAAAAAAAAAAAAAw
ELvaU6Z-i0d8JJR2nmwyYAZAoTNZH3UfSVPzhzS6b5CM

Breakdown:

• -GAB: CESR group framing code indicating an event source seal triple attachment
• 0AAAAAAAAAAAAAAAAAAAAAAw: Base64 encoded sequence number ("3" in this example)
• ELvaU6Z...: CESR-encoded SAID of the TEL event

This encoding enables efficient streaming and parsing of seal attachments while maintaining composability with other CESR primitives.

CESR Serialization

All TEL events use CESR (Composable Event Streaming Representation) encoding, which provides:

Dual Text-Binary Encoding: Events can be serialized in either text (JSON) or binary (CBOR, MGPK) formats with full round-trip conversion capability.

Self-Framing: Each primitive includes type and size information, enabling stream parsing without external schema knowledge.

Composability: Multiple primitives can be concatenated and parsed as a group, supporting efficient pipelining.

Version Strings: Each event begins with a version string like KERI10JSON000116_ that encodes:

• Protocol version (KERI10)
• Serialization type (JSON)
• Event size in bytes (000116 hex = 278 decimal)
• Terminator character (_)

This self-describing format enables parsers to extract events from streams without prior knowledge of event structure.

Protocol Mechanics

Registry Initialization Sequence

The creation of a public verifiable credential registry follows a specific protocol sequence:

Step 1: Management TEL Inception

1. Controller creates management TEL inception event (vcp)
2. Event specifies registry identifier, backer threshold, and backer list
3. Event is serialized and a SAID is computed

Step 2: KEL Anchoring

1. Controller creates a KEL event (interaction or rotation)
2. Event includes an event source seal referencing the management TEL inception
3. KEL event is signed by current authoritative keys
4. Signature cryptographically commits to the management TEL event digest

Step 3: Registrar Distribution

1. Management TEL event and KEL event are distributed to registrars
2. Registrars validate the cryptographic anchoring
3. Registrars store both events and provide receipts
4. Registry becomes operational once threshold of registrars confirm

Step 4: VC TEL Creation For each credential to be issued:

1. Controller creates VC TEL inception event (iss or bis)
2. Event references the management TEL via ri field
3. Event is anchored to KEL via seal in KEL event
4. Registrars store VC TEL and provide receipts

Credential Issuance Protocol

The issuance of a credential through a public registry involves:

Phase 1: Credential Creation

1. Issuer generates credential content (ACDC structure)
2. Issuer computes SAID of credential content
3. SAID becomes the credential identifier

Phase 2: Registry Entry Creation

1. Issuer creates VC TEL inception event with credential SAID
2. Event includes issuance datetime and registry reference
3. Event is serialized and SAID is computed

Phase 3: Cryptographic Commitment

1. Issuer creates KEL event with seal to VC TEL inception
2. KEL event is signed with current authoritative keys
3. Signature binds the credential issuance to issuer's key state

Phase 4: Distribution and Confirmation

1. VC TEL event and KEL event are sent to registrars
2. Registrars validate anchoring and store events
3. Registrars provide receipts confirming storage
4. Credential becomes verifiable once threshold is met

Phase 5: Credential Delivery

1. Issuer delivers signed credential to holder
2. Holder can now present credential to verifiers
3. Verifiers can query registry for status verification

Credential Revocation Protocol

Revocation follows a similar but simpler pattern:

Phase 1: Revocation Decision

1. Issuer determines credential should be revoked
2. Issuer creates VC TEL revocation event (rev or brv)
3. Event references prior VC TEL event via p field

Phase 2: Cryptographic Commitment

1. Issuer creates KEL event with seal to revocation event
2. KEL event is signed with current authoritative keys
3. Signature commits to the revocation

Phase 3: Distribution and Confirmation

1. Revocation event and KEL event are sent to registrars
2. Registrars update stored state
3. Registrars provide receipts confirming revocation
4. Credential status transitions to "revoked"

Phase 4: Verification Impact

1. Subsequent verification queries return "revoked" status
2. Verifiers reject presentations of revoked credentials
3. Revocation is typically irreversible (monotonic state)

State Verification Protocol

Verifiers determine credential status through:

Step 1: Credential Receipt

1. Verifier receives credential presentation from holder
2. Credential includes registry identifier (ri field)
3. Verifier extracts credential SAID for registry query

Step 2: Registry Query

1. Verifier queries registrars for VC TEL events
2. Query uses credential SAID as identifier
3. Registrars return VC TEL event sequence

Step 3: Event Validation

1. Verifier validates each VC TEL event's anchoring to KEL
2. Verifier retrieves referenced KEL events
3. Verifier validates KEL signatures using key state
4. Verifier confirms cryptographic binding chain

Step 4: State Computation

1. Verifier replays VC TEL events in sequence order
2. Verifier applies state transition rules
3. Verifier determines current credential status
4. Verifier makes trust decision based on status

Timing and Ordering Requirements

Sequence Number Independence: TEL sequence numbers are independent of KEL sequence numbers. A single KEL event can anchor multiple TEL events, and TEL events can be anchored to any KEL event (interaction or rotation).

Monotonic State Transitions: Credential state transitions are monotonic - once revoked, a credential cannot be "un-revoked" without detecting key compromise and replaying from a trusted checkpoint.

Eventually Consistent: The registry achieves eventual consistency across registrars. Temporary inconsistencies may occur during network partitions but are resolved through duplicity detection and first-seen policies.

Grace Periods: The architecture supports "ghost credentials" - credentials in a grace period between revocation transaction creation and final booking to the registry. This allows for operational flexibility while maintaining security.

Timestamp Semantics: The dt (datetime) field in issuance and revocation events provides human-readable timestamps but is not used for cryptographic ordering. Sequence numbers provide the authoritative ordering.

Security Properties

Threat Model

The public verifiable credential registry architecture addresses several threat categories:

Threat 1: Unauthorized Credential Issuance

• Attack: Adversary attempts to issue credentials without controlling the issuing AID
• Mitigation: All issuance events must be anchored to KEL events signed by authoritative keys
• Detection: Verifiers validate KEL signatures and key state before accepting credentials

Threat 2: Unauthorized Credential Revocation

• Attack: Adversary attempts to revoke valid credentials
• Mitigation: Revocation events require KEL anchoring with valid signatures
• Detection: Same as unauthorized issuance - signature validation prevents unauthorized revocation

Threat 3: Registry State Manipulation

• Attack: Adversary attempts to modify registry state (e.g., un-revoke a credential)
• Mitigation: TEL events are append-only and cryptographically chained
• Detection: Verifiers detect inconsistencies through event replay and duplicity detection

Threat 4: Registrar Compromise

• Attack: Adversary compromises one or more registrars to provide false state
• Mitigation: Threshold-based consensus requires multiple registrars to agree
• Detection: Verifiers query multiple registrars and detect inconsistencies

Threat 5: Key Compromise

• Attack: Adversary compromises issuer's signing keys
• Mitigation: KERI's pre-rotation mechanism enables recovery
• Detection: Duplicity detection identifies conflicting KEL versions

Threat 6: Replay Attacks

• Attack: Adversary replays old registry state to hide revocations
• Mitigation: Sequence numbers and monotonic state transitions prevent rollback
• Detection: Verifiers detect sequence number inconsistencies

Threat 7: Eclipse Attacks

• Attack: Adversary isolates verifier from honest registrars
• Mitigation: Verifiers query multiple independent registrars
• Detection: Inconsistent responses from different registrars indicate attack

Security Guarantees

The architecture provides several formal security guarantees:

Authenticity Guarantee: All registry state transitions are cryptographically bound to the issuer's key state. Verifiers can independently verify that state changes were authorized by the entity controlling the issuing AID.

Integrity Guarantee: TEL events are cryptographically chained and anchored to KEL events. Any modification to event content invalidates the cryptographic binding, making tampering detectable.

Non-Repudiation Guarantee: Issuer signatures on KEL events provide non-repudiable proof of credential issuance and revocation. Issuers cannot deny having issued or revoked credentials without claiming key compromise.

Duplicity Evidence Guarantee: The architecture inherits KERI's duplicity-evident properties. If an issuer creates conflicting registry states, the conflict is cryptographically provable and detectable by any verifier.

Availability Guarantee: The use of multiple registrars provides redundancy. The registry remains available as long as the threshold number of registrars is reachable.

Consistency Guarantee: The deterministic state machine ensures that all honest verifiers computing state from the same event sequence reach the same conclusion about credential status.

Attack Resistance

Resistance to Dead Attacks: Dead attacks (attacks on stale key state) are prevented through KERI's pre-rotation mechanism. Even if old keys are compromised, they cannot be used to create valid new registry events because the next key digest was committed before compromise.

Resistance to Live Attacks: Live attacks (attacks on current key state) are detectable through duplicity detection. If an attacker compromises current keys and creates conflicting registry states, the conflict is evident to verifiers querying multiple registrars.

Resistance to Sybil Attacks: The registrar threshold mechanism prevents Sybil attacks where an adversary creates multiple fake registrars. The issuer explicitly designates trusted registrars, and verifiers validate registrar identities through their AIDs.

Resistance to Denial of Service: The distributed registrar architecture provides resilience against DoS attacks. Attackers must successfully DoS the threshold number of registrars to prevent registry access.

Resistance to Correlation Attacks: This is explicitly NOT a security property of public registries. The architecture acknowledges that public registries enable correlation of credential usage across presentations. This is an intentional design trade-off for public verifiability.

Cryptographic Foundations

The security of public verifiable credential registries rests on:

Hash Function Security: The architecture assumes collision-resistant hash functions (typically Blake3-256). Breaking this assumption would allow creation of conflicting events with the same SAID.

Digital Signature Security: The architecture assumes secure digital signature schemes (Ed25519, ECDSA secp256k1). Breaking this assumption would allow unauthorized state transitions.

Key Management Security: The architecture assumes secure key generation, storage, and rotation practices. Poor key management undermines all other security properties.

CESR Encoding Security: The architecture assumes CESR encoding is unambiguous and parseable. Encoding ambiguities could enable parsing attacks.

Interoperability

Dependencies on KERI Protocol Suite

Public verifiable credential registries are deeply integrated with the KERI protocol suite:

KEL Dependency: TELs fundamentally depend on KELs for:

• Establishing control authority over the issuing identifier
• Providing cryptographic anchoring for TEL events
• Enabling key rotation and recovery mechanisms
• Supplying the root of trust for the entire registry

Without a valid KEL, a TEL cannot be verified. The KEL provides the authoritative key state that validates TEL event signatures.

CESR Dependency: All events use CESR encoding for:

• Dual text-binary serialization
• Self-framing and composability
• Efficient streaming and parsing
• Cryptographic primitive encoding

CESR provides the foundational encoding layer that enables interoperability across different serialization formats.

SAID Dependency: The architecture relies on SAIDs for:

• Content-addressable event identification
• Cryptographic binding between events
• Compact references in seals and anchors
• Integrity verification

SAIDs provide the self-referential integrity mechanism that binds registry components together.

ACDC Dependency: While not strictly required, public registries are typically used with ACDCs:

• ACDCs provide the credential data structure
• Registry identifiers (ri field) link credentials to registries
• ACDC SAIDs serve as credential identifiers in VC TELs
• ACDC issuance and revocation align with TEL state transitions

Integration with ACDC Protocol

The integration between public registries and ACDCs follows specific patterns:

Registry Identifier Field: ACDCs include an ri field that references the management TEL:

{
  "v": "ACDC10JSON000116_",
  "d": "EpDA1n-WiBA0A8YOqnKrB-wWQYYC49i5zY_qrIZIicQg",
  "i": "ELvaU6Z-i0d8JJR2nmwyYAZAoTNZH3UfSVPzhzS6b5CM",
  "ri": "EYOqnKrB-wWQYYC49i5zY_qrIZIicQgpDA1n-WiBA0A8",
  "s": "E8JZAoTNZH3ULvaU6Z-i0d8fSVPzhzS6b5CMJR2nmwy",
  "a": { ... }
}

The ri field enables verifiers to locate the appropriate registry for status queries.

Credential Identifier Alignment: The ACDC's SAID (d field) serves as the credential identifier in the VC TEL. This creates a direct cryptographic binding between the credential content and its registry entry.

Issuance Workflow Integration: ACDC issuance and TEL issuance are coordinated:

1. Create ACDC structure
2. Compute ACDC SAID
3. Create VC TEL inception with ACDC SAID
4. Anchor VC TEL to KEL
5. Sign ACDC with issuer keys
6. Deliver ACDC to holder

Revocation Workflow Integration: ACDC revocation triggers TEL revocation:

1. Issuer decides to revoke ACDC
2. Create VC TEL revocation event
3. Anchor revocation to KEL
4. Registry state transitions to revoked
5. Subsequent ACDC presentations fail verification

Integration with Witness/Watcher Infrastructure

Public registries leverage KERI's witness and watcher infrastructure:

Witness Integration: Registrars can be implemented as KERI witnesses:

• Witnesses provide KEL witnessing services
• Same witnesses can provide TEL registrar services
• Unified infrastructure reduces operational complexity
• Witness receipts provide additional trust signals

Watcher Integration: Watchers monitor both KELs and TELs:

• Watchers detect duplicity in KELs and TELs
• Watchers provide independent verification of registry state
• Watchers enable ambient duplicity detection
• Watchers aggregate registry state for efficient queries

OOBI Integration: Out-Of-Band Introductions enable registry discovery:

• OOBIs provide registrar endpoint discovery
• OOBIs enable bootstrap of registry verification
• OOBIs support both public and private discovery patterns
• OOBIs integrate with KERI's percolation discovery model

Cross-Registry Interoperability

Multiple registries can coexist and interoperate:

Registry Namespacing: Each registry has a unique identifier (management TEL SAID), preventing namespace collisions.

Multi-Registry Credentials: A single credential can reference multiple registries for different purposes (e.g., issuance registry and revocation registry).

Registry Delegation: Registries can delegate authority to sub-registries, creating hierarchical registry structures.

Registry Federation: Multiple independent registries can be federated through shared registrars or watcher networks.

Implementation Considerations

Registry Initialization Challenges

Implementers face several challenges when initializing registries:

Registrar Selection: Choosing appropriate registrars requires considering:

• Trust relationships with registrar operators
• Geographic and jurisdictional distribution
• Availability and reliability requirements
• Performance and latency constraints
• Cost and operational overhead

Threshold Configuration: Setting the registrar threshold involves trade-offs:

• Higher thresholds increase security but reduce availability
• Lower thresholds increase availability but reduce security
• Threshold should account for expected registrar failures
• Threshold should prevent single points of failure

Bootstrap Coordination: Initial registry setup requires coordination:

• Registrars must be operational before registry creation
• KEL must be established before TEL creation
• OOBI distribution must enable registrar discovery
• Initial state must be consistently distributed

Performance Considerations

Query Latency: Registry queries involve multiple network round-trips:

• Query registrars for VC TEL events
• Retrieve referenced KEL events
• Validate cryptographic anchoring
• Compute current state from event sequence

Implementers should consider caching strategies and pre-computation of state to reduce verification latency.

Storage Requirements: Registries accumulate events over time:

• Each credential requires at least one VC TEL event
• Revoked credentials add additional events
• KEL events must be stored for anchoring validation
• Event storage grows linearly with credential volume

Implementers should plan for long-term storage scaling and archival strategies.

Bandwidth Optimization: Event distribution can consume significant bandwidth:

• Each event must be distributed to threshold registrars
• Verifiers must retrieve events from registrars
• CESR encoding provides compact representation
• Batch operations can amortize overhead

Implementers should consider event batching and compression techniques.

Operational Challenges

Registrar Maintenance: Operating registrars requires ongoing effort:

• Software updates and security patches
• Monitoring and alerting infrastructure
• Backup and disaster recovery procedures
• Key management for registrar AIDs

State Synchronization: Maintaining consistent state across registrars:

• Network partitions can cause temporary inconsistencies
• Registrar failures require state recovery
• Duplicity detection requires cross-registrar coordination
• Eventually consistent model requires careful handling

Revocation Timing: Managing revocation timing involves trade-offs:

• Immediate revocation may not propagate to all verifiers
• Grace periods allow operational flexibility
• Ghost credentials exist during grace periods
• Verifiers must handle timing edge cases

Privacy Considerations

While public registries explicitly sacrifice privacy for verifiability, implementers should consider:

Correlation Risks: Public registries enable correlation:

• Multiple presentations of the same credential are linkable
• Verifiers can track credential usage patterns
• Issuers can monitor verification queries
• Holders have limited privacy protection

Mitigation Strategies: Implementers can reduce correlation risks:

• Use private registries for sensitive credentials
• Implement blinded revocation registries
• Employ selective disclosure to minimize revealed attributes
• Use one-time-use credentials where appropriate

Regulatory Compliance: Public registries must consider:

• GDPR and data protection regulations
• Right to be forgotten vs. immutable logs
• Data minimization principles
• Consent and purpose limitation requirements

Scalability Strategies

Horizontal Scaling: Registries can scale horizontally:

• Add more registrars to increase capacity
• Partition credentials across multiple registries
• Use sharding strategies for large registries
• Employ load balancing across registrars

Vertical Scaling: Individual registrars can scale vertically:

• Optimize database performance
• Use caching for frequently queried credentials
• Pre-compute state for common queries
• Employ indexing strategies for efficient lookups

Hierarchical Registries: Large-scale deployments can use hierarchical structures:

• Root registry delegates to sub-registries
• Sub-registries handle specific credential types
• Hierarchical queries reduce load on root registry
• Delegation enables organizational boundaries

Testing and Validation

Implementers should thoroughly test:

Functional Testing: Verify correct protocol implementation:

• Registry initialization and configuration
• Credential issuance and revocation workflows
• State computation and verification
• Error handling and edge cases

Security Testing: Validate security properties:

• Unauthorized issuance/revocation attempts
• Cryptographic validation of all events
• Duplicity detection mechanisms
• Key compromise recovery procedures

Performance Testing: Measure system performance:

• Query latency under various loads
• Throughput for issuance/revocation operations
• Storage growth over time
• Network bandwidth consumption

Interoperability Testing: Ensure compatibility:

• Cross-implementation compatibility
• Different serialization formats (JSON, CBOR, MGPK)
• Various registrar implementations
• Integration with ACDC and KEL implementations

Performance Optimization

Implementers SHOULD optimize for performance:

• Cache frequently queried credential states
• Pre-compute state for common queries
• Use efficient database indexing strategies
• Batch event distribution to registrars
• Implement connection pooling for registrar queries

Error Handling

Implementers MUST handle error conditions:

• Missing or unavailable registrars
• Invalid cryptographic anchoring
• Sequence number gaps or conflicts
• Network timeouts and failures
• Malformed events or invalid signatures

Testing Requirements

Implementers SHOULD test:

• Registry initialization with various threshold configurations
• Credential issuance and revocation workflows
• State computation with complex event sequences
• Duplicity detection with conflicting states
• Performance under high load
• Recovery from registrar failures

Interoperability

Implementers MUST ensure interoperability:

• Support all CESR serialization formats (JSON, CBOR, MGPK)
• Validate against IETF PTEL specification
• Test with multiple KERI implementations
• Verify compatibility with ACDC credential format
• Ensure proper OOBI-based discovery