Issuer/Controller: The AID controller who originally issued the credential and maintains control authority over the credential's lifecycle through their KEL.

Registrars: Entities acting as backers for the VC TEL, analogous to witnesses in KELs. Registrars maintain copies of the TEL and provide independent validation of state changes.

Validators/Verifiers: Entities that query the registry to determine credential status before accepting credential presentations.

Process Flow

Step 1: Revocation Event Creation

The issuer creates a revocation event in the VC TEL with the following structure:

{
  "v": "KERI10JSON",
  "t": "brv",
  "d": "<SAID of this event>",
  "i": "<credential SAID>",
  "s": "<sequence number>",
  "p": "<prior event digest>",
  "ra": {
    "i": "<registry AID>",
    "s": "<registry sequence>",
    "d": "<registry event digest>"
  }
}

Key fields:

• t: Event type identifier "brv" (backed vc revoke)
• i: The SAID of the credential being revoked
• s: Monotonically increasing sequence number in the VC TEL
• p: Digest of the previous event in this VC TEL (typically the "bis" issuance event)
• ra: Registry anchor referencing the management TEL that governs this credential

Step 2: Digest Computation

The serialized revocation event content is hashed using a cryptographically strong digest algorithm (typically Blake3-256) to create a unique cryptographic commitment to the event. This digest serves as the event's SAID, which is placed in the d field following the standard SAID derivation algorithm:

1. Replace the d field with dummy # characters matching the digest length
2. Serialize the event in canonical form
3. Compute the digest over the serialized content
4. Replace the dummy characters with the computed digest

Step 3: KEL Anchoring via Event Source Seals

The revocation event is anchored to the issuer's KEL through an event source seal. The issuer creates either an interaction event (ixn) or rotation event (rot) in their KEL that includes a seal referencing the revocation event:

{
  "s": "<TEL sequence number>",
  "d": "<revocation event SAID>"
}

This seal is attached to the KEL event using CESR encoding as an event source seal triple:

-GAB
0AAAAAAAAAAAAAAAAAAAAAA<sequence>
<revocation event SAID>

The -GAB prefix is a CESR group framing code indicating an event source seal triple attachment.

Step 4: KEL Event Signing

The issuer signs the KEL event (containing the seal) with their current authoritative keypair. This signature creates a cryptographic commitment to the revocation event digest. Critically, the TEL revocation event itself does not require a signature—its authenticity derives from:

• The digest commitment in the KEL seal
• The non-repudiable signature on the KEL event
• The verifiable key state of the issuer's AID

Step 5: Registrar Distribution

The revocation event and its anchoring KEL event are distributed to the configured Registrars (backers) for the VC TEL. Registrars:

• Validate the cryptographic chain from KEL to TEL
• Verify the issuer's signatures on the KEL event
• Store the revocation event in their TEL copies
• Update the credential's state to "revoked"
• Provide independent validation for future queries

Step 6: State Verification

Validators querying the credential status:

1. Retrieve the VC TEL from Registrars
2. Verify the revocation event's digest matches the seal in the KEL
3. Validate the KEL event signatures using the issuer's key state
4. Confirm the event sequence is valid (no gaps or duplicity)
5. Determine the credential is revoked and reject presentations

Technical Requirements

Cryptographic Requirements

Digest Algorithm: The revocation event SAID must use a cryptographically strong hash function with sufficient collision resistance. KERI implementations typically use Blake3-256, providing 128-bit security against collision attacks.

Signature Verification: Validators must verify the digital signatures on the anchoring KEL event using the issuer's current authoritative public keys. This requires:

• Retrieving the issuer's KEL
• Computing the key state at the anchoring event
• Verifying signatures match the threshold requirements
• Confirming no duplicity exists in the KEL

CESR Encoding: All cryptographic primitives (digests, signatures, keys) must be encoded using CESR with appropriate derivation codes to ensure composability and self-framing properties.

Timing Considerations

Sequence Number Monotonicity: The s field in the revocation event must be strictly greater than the previous event's sequence number. For credential TELs, this is typically a simple increment (e.g., "0" for issuance, "1" for revocation).

KEL Synchronization: The anchoring KEL event must be properly sequenced in the issuer's KEL. Validators must have access to the KEL up to and including the anchoring event to verify the revocation.

Registrar Consensus: While not requiring Byzantine consensus, the system benefits from multiple Registrars reaching agreement on the revocation event. The backer threshold (bt) in the management TEL specifies the minimum number of Registrars required for authoritative state determination.

Grace Periods: Some implementations may define a grace period between revocation event creation and enforcement, allowing for operational considerations. However, cryptographically, the revocation is effective immediately upon anchoring to the KEL.

Error Handling

Missing Prior Events: If the revocation event references a prior event digest that cannot be found, validators must reject the revocation as invalid. This prevents attacks that skip issuance events.

KEL Anchoring Failures: If the seal in the KEL event does not match the revocation event digest, or if the KEL event signatures are invalid, the revocation must be rejected.

Duplicitous Revocations: If multiple conflicting revocation events exist for the same credential (detected through different digests at the same sequence number), this constitutes duplicity and must be reported. The first-seen policy typically determines which event is authoritative.

Registry Unavailability: If Registrars are unreachable, validators may need to implement fallback strategies, such as:

• Caching last-known-good state with timestamps
• Requiring minimum Registrar responses before accepting credentials
• Implementing watcher networks for redundant state tracking

Usage Patterns

Typical Scenarios

Employment Termination: An organization issues vLEI OOR credentials to employees. When an employee leaves, the organization executes a brv operation to revoke the credential, preventing the former employee from presenting it as proof of current employment.

Role Change: A legal entity issues an ECR credential for a specific engagement. When the engagement ends or the role changes, the issuer revokes the old credential before issuing a new one with updated attributes.

Security Compromise: If a credential's private keys are compromised or the credential is used fraudulently, the issuer can immediately revoke it through brv, invalidating all future presentations.

Regulatory Compliance: Governance frameworks may require periodic credential renewal. Expired credentials are revoked through brv operations, forcing credential holders to obtain updated credentials.

Best Practices

Atomic Operations: Combine the TEL revocation event creation and KEL anchoring in a single atomic operation to prevent inconsistent states where the revocation exists but is not anchored.

Registrar Redundancy: Configure multiple Registrars (typically 3-5) to ensure availability and prevent single points of failure. The backer threshold should be set to require supermajority agreement (e.g., 3 of 5).

Audit Trails: Maintain comprehensive logs of all revocation operations, including:

• Timestamp of revocation decision
• Reason for revocation (for internal governance)
• KEL event sequence number of anchoring
• Registrar confirmation receipts

Notification Mechanisms: While not part of the cryptographic protocol, implement out-of-band notification to credential holders when their credentials are revoked, allowing them to understand status changes.

Query Optimization: Implement efficient query mechanisms for validators to check credential status without retrieving entire TELs. Registrars should support queries by credential SAID that return current state.

Integration Considerations

IPEX Protocol: The brv operation integrates with IPEX (Issuance and Presentation Exchange) protocol flows. When a credential is revoked, subsequent presentation exchanges must fail validation when verifiers query the registry.

Management TEL Coordination: The revocation event's ra (registry anchor) field must reference a valid management TEL that governs the credential type. This creates a hierarchical structure:

• Management TEL (tracks Registrar list)
• VC TEL (tracks individual credential state)
• KEL (provides root of trust)

Multi-Credential Revocation: When revoking multiple credentials (e.g., all credentials for a terminated employee), each requires a separate brv event in its respective VC TEL. However, these can be anchored to a single KEL event through multiple seals, improving efficiency.

Delegation Hierarchies: In delegated identifier scenarios, revocation authority follows the delegation chain. A delegated issuer can revoke credentials they issued, but the delegating identifier retains ultimate authority through rotation of the delegated identifier.

Privacy Considerations: The brv operation is designed for public credentials where correlation is acceptable. For private credentials requiring selective disclosure, alternative revocation mechanisms (such as blinded revocation registries) should be used instead of public TELs.

Relationship to Other TEL Operations

The brv operation is part of a complete credential lifecycle:

vcp (vdr incept): Creates the management TEL and establishes the Registrar list

bis (backed vc issue): Issues the credential, creating the initial VC TEL event

brv (backed vc revoke): Revokes the credential, transitioning state from issued to revoked

vrt (vdr rotate): Rotates the Registrar list in the management TEL

These operations work together to provide complete, verifiable credential lifecycle management anchored to KERI's cryptographic infrastructure.

Security Properties

The brv operation inherits KERI's core security properties:

End-Verifiable: Any validator can independently verify the revocation by checking the cryptographic chain from KEL to TEL without trusting intermediaries.

Duplicity-Evident: Any attempt to present conflicting revocation states is cryptographically detectable through digest comparison.

Non-Repudiable: The issuer cannot deny revoking the credential due to the non-repudiable signature on the anchoring KEL event.

Ambient Verifiability: The revocation can be verified by anyone, anywhere, at any time with access to the KEL and TEL, supporting ambient verifiability.

Post-Quantum Resistant: When using post-quantum signature schemes in the KEL, the revocation inherits post-quantum security properties.

Testing Requirements

Comprehensive test suites should cover:

• Valid revocation event creation and anchoring
• Invalid sequence number handling
• Missing prior event detection
• Duplicitous revocation detection
• Registrar consensus scenarios
• KEL-TEL anchor verification
• CESR encoding/decoding round-trips