A registrar is an identifier that serves as a backer for transaction event logs (TELs), providing witnessing and verification services for credential lifecycle events. Registrars are analogous to witnesses in KERI KELs but operate specifically within the TEL infrastructure for tracking credential issuance and revocation states.
Related Concepts
No related concepts available
Comprehensive Explanation
registrar
Process Definition
A registrar in the KERI ecosystem is an AID (Autonomic Identifier) that functions as a backer for transaction event logs (TELs). Registrars provide secondary root-of-trust services specifically for credential lifecycle management, operating within the public verifiable credential registry infrastructure.
Core Functions
Registrars accomplish several critical functions:
TEL Backing: Provide witnessing and verification services for transaction event logs that track credential issuance and revocation states
State Persistence: Maintain copies of TEL events to ensure availability and verifiability
Consensus Participation: Participate in agreement protocols for TEL event validation
Discovery Support: Enable discovery of credential state information through various mechanisms
Credential lifecycle events (issuance, revocation) need to be tracked in a verifiable, distributed manner
High-availability access to credential state information is required
Implementation Notes
Critical Implementation Considerations
Registrar Identity Management
Registrars should use non-transferable AIDs for their own identifiers. This design choice means registrar security relies on pool-based threshold structures rather than individual key rotation. Implementers must:
Generate registrar AIDs with non-transferable derivation codes
Integrate with KERI DHT for decentralized discovery
Provide DID resolution endpoints if using DID-based identifiers
The credential ecosystem requires separation between key management (KEL) and credential state management (TEL)
Key Participants
The registrar process involves:
Credential Issuers: Controllers who create and manage credentials, anchoring TEL events to their KELs
Registrars: Identifiers designated to back specific TELs, providing witnessing services
Validators/Verifiers: Entities that query registrars to verify credential state
Management TEL Controllers: Entities that maintain the list of authorized registrars
Process Flow
Registry Initialization
The registrar process begins with the creation of a management TEL:
Management TEL Inception: The credential issuer creates a management TEL that signals the creation of a Virtual Credential Registry (VCR)
Registrar List Establishment: The management TEL includes an initial list of registrar AIDs that will serve as backers
KEL Anchoring: The management TEL inception event is anchored to the issuer's KEL through event source seals
Registrar Notification: Designated registrars are notified (typically via OOBI) of their role
Credential Lifecycle Management
For each credential issued:
VC TEL Creation: A VC TEL is created for the specific credential
Management TEL Reference: The VC TEL contains a reference to its corresponding management TEL
Issuance Event: An issuance event is created in the VC TEL and anchored to the issuer's KEL
Registrar Witnessing: Registrars designated in the management TEL receive and witness the VC TEL events
State Tracking: The VC TEL tracks state transitions (issued, revoked) for the credential
Registrar Rotation
The list of registrars can be updated:
Rotation Event Creation: The management TEL controller creates a rotation event specifying the new registrar list
KEL Anchoring: The rotation event is anchored to the controller's KEL
Registrar Transition: New registrars are onboarded while old registrars may be phased out
State Continuity: Existing VC TELs continue to reference the management TEL, which now points to the updated registrar list
State Verification
When a verifier needs to check credential state:
Registrar Discovery: The verifier discovers registrar endpoints through OOBIs, well-known URIs, or other discovery mechanisms
TEL Query: The verifier queries one or more registrars for the VC TEL associated with a specific credential
Event Validation: The verifier validates the TEL events by checking their anchoring to the issuer's KEL
State Determination: The verifier determines the current credential state (issued, revoked) based on the validated TEL
Technical Requirements
Cryptographic Requirements
Registrars must satisfy several cryptographic constraints:
Identifier Type: According to Document 30, registrars should use non-transferable AIDs (ephemeral identifiers) for their own identity. This design choice means registrar security relies on pool-based threshold structures rather than individual key rotation capabilities.
Cryptographic Strength: All registrar key-pairs must provide approximately 128 bits of cryptographic strength. Compliant algorithms include:
Ed25519 for digital signatures
EcDSASecp256k1 for ECDSA-based signatures
CESR-compatible encoding for all cryptographic primitives
Signature Verification Infrastructure: Registrars must implement robust signature verification for:
When registrars use distributed ledger technology (DLT) for TEL storage:
Approved DID Methods: According to Document 30, registrars must use GLEIF Approved DID Methods when operating as ledger backers. Approval is required down to the individual ledger implementation level, not just the DID method specification.
Single Registrar Recommendation: The specification states registrars should use only one Registrar per KEL when using ledger-based backing to maintain consistency and avoid synchronization complexity.
Ledger-Specific Security: Each ledger implementation must provide appropriate security guarantees for the use case, including:
Immutability of recorded TEL events
Availability of historical state information
Resistance to censorship or manipulation
Witness Pool Configuration
When registrars operate as traditional KERI witnesses (non-ledger mode):
Minimum Pool Size: Must use a minimum pool of 5 witnesses with KAACE (KERI's Agreement Algorithm for Control Establishment) sufficient majority threshold.
Access Control Independence: Registrars should use access control independent of the Controller keys for:
Configuring the registrar host infrastructure
Accepting events for witnessing
This prevents poisoning attacks if controller keys are compromised
Discovery Mechanisms: Registrars must publish their endpoints through multiple channels:
Well-Known URIs: Following IETF RFC-8615 on websites associated with the entity
KERI DHT: Distributed hash table for decentralized discovery
DID Resolvers: For DID-based identifier resolution
Ledgers: For ledger-backed registrar discovery
Timing Considerations
Event Queuing: According to Document 29, registrars should implement event queuing mechanisms that operate during a period of time to allow several block confirmations as a safety measure. This is particularly critical for ledger-based registrars to protect against blockchain reorganizations.
Confirmation Delays: The queuing system should wait for sufficient confirmations before events are considered stably anchored, protecting against:
Blockchain forks
Reorganizations that could affect event ordering
Temporary network partitions
Error Handling
Registrars must handle several error conditions:
Duplicity Detection: If a registrar receives conflicting TEL events for the same credential, it must:
Credential Presentation Workflows: During credential presentation:
Verifiers should query multiple registrars for redundancy
Implement caching strategies to reduce registrar query load
Support both synchronous and asynchronous verification patterns
Handle registrar unavailability gracefully with fallback mechanisms
Relationship to KERI Architecture
Registrars represent a parallel infrastructure component to the backer/witness model used in KELs, adapted specifically for transaction event logs that track credential issuance and revocation states. This architectural parallelism means:
KEL witnesses provide consensus for key state changes
TEL registrars provide consensus for credential state changes
Both use similar agreement algorithms and threshold structures
Both enable decentralized verification without centralized infrastructure
The separation between KEL and TEL infrastructure allows:
Independent scaling of key management and credential management
Different security models for keys versus credentials
Specialized optimization for each use case
Flexible deployment where KEL and TEL infrastructure can be co-located or separated
This design reflects KERI's broader philosophy of creating composable, modular infrastructure where each component serves a specific purpose while maintaining interoperability through standardized protocols and cryptographic verification mechanisms.
Implement high-availability infrastructure with appropriate redundancy
Performance Optimization
For production deployments:
Implement caching strategies for frequently queried credential states
Use database indexing on credential identifiers and registry identifiers
Support batch queries for verifiers checking multiple credentials
Implement rate limiting to prevent abuse
Monitor and log query patterns for capacity planning
Security Hardening
Implement KRAM (KERI Request Authentication Method) for all API endpoints to prevent replay attacks
Use MFA for administrative access to registrar infrastructure
Implement comprehensive audit logging of all TEL events witnessed
Regular security audits of registrar infrastructure
Incident response procedures for key compromise or service disruption
Interoperability
Ensure compatibility with the broader KERI ecosystem:
Use CESR encoding for all cryptographic primitives
Support KAPI (KERI Application Programming Interface) standards