Comprehensive Explanation

judge

Process Definition

A judge in the KERI ecosystem performs forensic analysis and validation of key event data structures to establish trustworthiness of identifier control. The judge examines entries from one or more Key Event Receipt Logs (KERLs) and Duplicitous Event Logs (DELs) for a given Autonomic Identifier (AID) to make authoritative determinations about key state validity.

Core Objectives

The judge accomplishes three primary objectives:

1. Validate Event History Integrity: Verify that the event sequence originates from a non-duplicitous controller by examining the cryptographic chain of key events
2. Assess Witness Attestations: Confirm that sufficient non-duplicitous witnesses have signed and receipted the events according to the identifier's threshold requirements
3. Determine Trustworthiness: Provide a trust determination to validators about whether the identifier's key state can be relied upon for making authorization or verification decisions

When Judges Are Used

Judges operate in KERI's indirect mode infrastructure, particularly in advanced deployment scenarios where:

• Multiple witnesses maintain Key Event Receipt Logs (KERLs) for an identifier
• Watchers have detected potential duplicity across witness sets
• Validators need authoritative determinations before accepting key state
• Recovery from key compromise requires adjudication of conflicting event histories
• High-stakes transactions require enhanced validation beyond basic witness consensus

Key Participants

The judge interacts with several ecosystem components:

• Controllers: Generate key events that judges must validate
• Witnesses: Provide signed receipts that judges examine for consistency
• Watchers: Observe event logs in promiscuous mode and report duplicity to judges
• Validators: Consume judge determinations to make final trust decisions
• Jurors: Perform the basic duplicity detection task that feeds into judge analysis

Process Flow

Step 1: KERL Collection

The judge begins by collecting Key Event Receipt Logs (KERLs) from the designated witness set for the identifier under examination. Each KERL contains:

• The complete Key Event Log (KEL) as witnessed by that specific witness
• Witness receipts (cryptographic signatures) from that witness for each event
• Potentially, receipts from other witnesses that have been shared

The judge must obtain KERLs from a sufficient number of witnesses to meet the identifier's Threshold of Accountable Duplicity (TOAD) requirement.

Step 2: Internal Consistency Verification

For each collected KERL, the judge performs internal consistency verification:

1. Cryptographic Chain Validation: Verify that each event's digest correctly chains to the previous event through the p (prior event digest) field
2. Signature Verification: Validate that each event is signed by the appropriate keys according to the key state at that sequence number
3. Pre-rotation Commitment Verification: Confirm that rotation events use keys whose digests were committed in the previous establishment event's n (next key digest) field
4. Threshold Compliance: Verify that the number of signatures meets the signing threshold specified in the current key state
5. Configuration Consistency: Ensure that configuration traits remain consistent or change only through valid establishment events

An internally inconsistent KERL fails validation immediately and cannot be used for trust decisions. Internal inconsistency indicates either:

• Corruption during transmission or storage
• Malicious tampering that broke cryptographic bindings
• Implementation errors in event generation

Step 3: External Consistency Analysis (Duplicity Detection)

After confirming internal consistency of individual KERLs, the judge performs external consistency analysis by comparing KERLs from different witnesses:

1. Event Sequence Comparison: Compare the sequence of events across all collected KERLs
2. First-Seen Analysis: Determine which events were "first seen" by each witness
3. Conflict Identification: Identify any sequence numbers where different witnesses have different events
4. Duplicity Classification: Classify conflicts as either:
   • Live attacks: Involving current signing keys
   • Dead attacks: Involving stale keys from superseded key states

The presence of externally inconsistent but internally valid KERLs indicates duplicity - the controller has created multiple conflicting versions of their event history.

Step 4: Witness Attestation Assessment

The judge evaluates the quality and sufficiency of witness attestations:

1. Witness Identity Verification: Confirm that receipts come from the designated witnesses for this identifier
2. Receipt Signature Validation: Verify cryptographic signatures on witness receipts
3. Witness Consistency: Assess whether witnesses have maintained consistent positions (no evidence of witness duplicity)
4. Threshold Achievement: Determine if sufficient non-duplicitous witnesses have attested to establish consensus

The judge applies the identifier's TOAD (Threshold of Accountable Duplicity) to determine if enough honest witnesses exist to make a reliable determination.

Step 5: Watcher Input Integration

Judges receive and integrate observations from watchers:

1. Duplicity Reports: Watchers report detected duplicity across the network
2. Juror Findings: Basic duplicity detection results from juror components
3. Network-Wide Consistency: Information about whether the same events are being propagated globally
4. Temporal Analysis: Timing information about when different versions appeared

Watchers operate in promiscuous mode, collecting all versions of events they encounter, providing judges with comprehensive duplicity evidence.

Step 6: Authoritative Key Set Determination

Based on the analysis, the judge determines the current authoritative key set for the identifier:

1. Valid Event Sequence: Identify the longest valid, non-duplicitous event sequence
2. Current Key State: Extract the current signing keys and next key digests from the latest valid establishment event
3. Witness Configuration: Determine the current witness set and thresholds
4. Recovery State: Identify if the identifier is in a recovery state due to detected compromise

Step 7: Trust Determination Output

The judge produces a trust determination that validators can consume:

• Trusted: The identifier's key state is valid, non-duplicitous, and sufficiently witnessed
• Untrusted: Duplicity detected, insufficient witness consensus, or other validation failures
• Conditional: Trust with caveats (e.g., recent rotation, recovery in progress)
• Unknown: Insufficient information to make a determination

This determination includes:

• The validated key state
• Evidence supporting the determination
• Confidence level based on witness consensus strength
• Any detected duplicity with forensic details

Technical Requirements

Cryptographic Requirements

Signature Verification Capabilities

Judges must support all derivation codes used in KERI for:

• Signing algorithms: Ed25519, ECDSA (secp256k1, secp256r1), etc.
• Digest algorithms: Blake3-256, SHA3-256, SHA2-512, Blake2b-256
• CESR encoding: Both text and binary domain primitives

The judge must correctly parse and verify signatures using the appropriate cryptographic primitives based on the derivation codes in the events.

Pre-Rotation Verification

Judges must verify pre-rotation commitments:

1. Extract the n (next key digest) field from establishment events
2. When a rotation occurs, verify that the new keys' digest matches the committed digest
3. Support both single-signature and multi-signature pre-rotation schemes
4. Handle partial rotation where some pre-rotated keys remain in reserve

Threshold Signature Validation

For multi-signature identifiers, judges must:

1. Parse threshold specifications (e.g., "2/3" meaning 2 of 3 signatures required)
2. Support weighted thresholds where different keys have different voting power
3. Validate that sufficient signatures exist to meet the threshold
4. Handle fractional weights in complex multi-sig configurations

Timing Considerations

Real-Time vs Batch Processing

Judges can operate in different temporal modes:

• Real-time judging: Immediate evaluation as events arrive, suitable for high-stakes transactions
• Batch judging: Periodic evaluation of accumulated events, suitable for lower-priority validations
• On-demand judging: Evaluation triggered by validator requests

The choice depends on the risk profile and performance requirements of the deployment.

First-Seen Immutability

Judges must respect the first-seen principle:

• Once a witness has receipted an event, that event is "first seen" and immutable from that witness's perspective
• Judges cannot "unsee" events - they can only detect duplicity when conflicting versions exist
• Timing of first-seen events across witnesses may vary, which is acceptable as long as the events themselves are consistent

Recovery Time Windows

When key compromise is detected, judges must:

1. Identify the point of compromise in the event sequence
2. Apply superseding recovery rules to determine valid recovery paths
3. Allow reasonable time for legitimate recovery operations
4. Distinguish between legitimate recovery and attacker attempts to exploit recovery mechanisms

Error Handling

Insufficient Witness Consensus

When judges cannot achieve sufficient witness consensus:

1. Report uncertainty: Clearly indicate that a determination cannot be made
2. Provide partial information: Share what is known (e.g., "3 of 5 witnesses agree")
3. Suggest remediation: Indicate what additional information would enable a determination
4. Escalate if necessary: In critical scenarios, trigger manual review or additional validation

Detected Duplicity

When duplicity is detected:

1. Preserve evidence: Maintain all conflicting versions for forensic analysis
2. Classify severity: Distinguish between minor inconsistencies and major attacks
3. Notify stakeholders: Alert the controller, validators, and potentially other ecosystem participants
4. Support recovery: Facilitate the recovery process if the controller is legitimate

Malformed or Invalid Events

When encountering invalid events:

1. Reject gracefully: Do not crash or enter undefined states
2. Log details: Record what made the event invalid for debugging
3. Continue processing: Attempt to validate other events in the log
4. Report to witnesses: Notify witnesses if they are serving invalid data

Network Failures

When unable to reach witnesses or watchers:

1. Retry with backoff: Implement exponential backoff for transient failures
2. Use cached data: Leverage previously validated state if available
3. Degrade gracefully: Provide lower-confidence determinations based on partial information
4. Monitor availability: Track witness/watcher availability for operational awareness

Usage Patterns

Typical Scenarios

Scenario 1: Routine Validation

In normal operations, judges perform routine validation:

1. Validator requests key state for an identifier
2. Judge collects KERLs from witnesses
3. All KERLs are consistent and properly witnessed
4. Judge returns "Trusted" determination with current key state
5. Validator proceeds with transaction

This is the most common scenario, representing the "happy path" where no duplicity exists.

Scenario 2: Duplicity Detection and Recovery

When a controller's keys are compromised:

1. Attacker creates conflicting events using compromised keys
2. Different witnesses see different versions (duplicity)
3. Watchers detect the duplicity and report to judges
4. Judge identifies the point of compromise
5. Legitimate controller performs recovery using pre-rotated keys
6. Judge validates the recovery and updates key state
7. Validators are notified of the recovery

This scenario demonstrates KERI's core security innovation: making duplicity evident and recoverable.

Scenario 3: Witness Rotation

When a controller rotates their witness set:

1. Controller issues a rotation event changing witness configuration
2. New witnesses begin receipting events
3. Judge must validate the transition from old to new witnesses
4. Judge ensures sufficient overlap for continuity
5. Judge updates its witness tracking for future validations

Witness rotation is a normal operational event that judges must handle smoothly.

Scenario 4: High-Stakes Transaction

For critical transactions requiring enhanced assurance:

1. Validator requests high-confidence determination
2. Judge collects KERLs from all available witnesses (not just threshold)
3. Judge queries multiple watchers for duplicity reports
4. Judge performs extended temporal analysis
5. Judge provides detailed confidence metrics with determination
6. Validator makes risk-based decision using enhanced information

This pattern trades performance for increased security assurance.

Best Practices

Judge Deployment Architecture

Distributed Judge Pools: Deploy multiple judges operated by different entities to avoid single points of failure. Even competitors in the same market space benefit from sharing duplicity detection infrastructure, similar to certificate transparency systems.

Separation of Concerns: Judges should be separate from witnesses and watchers to maintain independence. A judge operated by the same entity as a witness creates potential conflicts of interest.

Redundancy: Validators should consult multiple judges for critical decisions, especially when judges disagree.

Performance Optimization

Caching: Cache validated key states with appropriate TTLs to reduce repeated validation overhead.

Incremental Validation: When possible, validate only new events since the last validation rather than re-validating entire KERLs.

Parallel Processing: Validate multiple KERLs concurrently to reduce latency.

Witness Prioritization: Query witnesses in order of reliability/proximity to optimize response time.

Security Hardening

Input Validation: Rigorously validate all inputs (KERLs, receipts, watcher reports) to prevent injection attacks.

Rate Limiting: Implement rate limits to prevent denial-of-service attacks.

Audit Logging: Maintain comprehensive logs of all determinations for forensic analysis.

Secure Communication: Use KERI Request Authentication Method (KRAM) or similar mechanisms to authenticate communications with witnesses and watchers.

Integration Considerations

Validator Integration

Validators integrate with judges through:

1. Query Interface: Request key state determinations for specific identifiers
2. Subscription Model: Subscribe to updates for identifiers of interest
3. Batch Queries: Request determinations for multiple identifiers efficiently
4. Confidence Thresholds: Specify required confidence levels for determinations

Watcher Integration

Judges integrate with watchers through:

1. Duplicity Reports: Receive notifications of detected duplicity
2. Event Queries: Request specific events or event ranges from watcher archives
3. Network Topology: Understand watcher coverage to assess global consistency
4. Temporal Data: Obtain timing information about when events were first seen

Witness Integration

Judges integrate with witnesses through:

1. KERL Retrieval: Fetch complete or partial KERLs via OOBI endpoints
2. Receipt Verification: Validate witness signatures on receipts
3. Availability Monitoring: Track witness uptime and responsiveness
4. Configuration Updates: Detect when witness sets change

Ecosystem Cooperation

The source material emphasizes that even competitors benefit from sharing judge infrastructure:

"Even competitors in the same market space will want to share duplicity information across the entire ecosystem... Similar to certificate transparency systems in the internet hosting space, competitors share information with each other because it serves their best interest to eliminate fraud/duplicity."

This cooperative model enables:

• Network effects: Security improves as more participants validate
• Reduced costs: Shared infrastructure reduces individual operational burden
• Faster detection: More observers increase likelihood of early duplicity detection
• Ecosystem health: All participants benefit from reduced fraud

Advanced Topics

Judge and Jury Pools

In KERI's Advanced Indirect Mode, judges operate within judge and jury pools that provide enhanced duplicity detection:

• Jury: The set of entities acting as jurors, performing basic duplicity detection
• Judge Pool: Multiple judges that can be consulted for determinations
• Consensus Mechanisms: Judges may employ consensus algorithms to reconcile disagreements
• Dynamic Appraisal: Judges can adjust confidence levels based on current threat landscape

Graduated Trust Assessment

Judges can provide graduated trust assessments rather than binary trusted/untrusted:

• High Confidence: All witnesses agree, no duplicity detected, strong cryptographic validation
• Medium Confidence: Threshold met but some witnesses unavailable or minor inconsistencies
• Low Confidence: Minimal threshold met, recent changes, or limited witness history
• Untrusted: Duplicity detected, insufficient witnesses, or validation failures

This graduated approach allows validators to make risk-appropriate decisions.

Temporal Analysis

Sophisticated judges perform temporal analysis:

1. Event Timing: Analyze when events were created and witnessed
2. Propagation Delays: Understand normal vs abnormal propagation patterns
3. Attack Windows: Identify time periods when attacks may have occurred
4. Recovery Timing: Validate that recovery operations occur within reasonable timeframes

Temporal analysis helps distinguish legitimate operations from attacks.

Cross-Ecosystem Validation

Judges may validate identifiers across multiple KERI ecosystems:

1. Delegation Chains: Validate delegated identifiers across delegation boundaries
2. Cross-Witness Validation: Validate identifiers that use witnesses from different ecosystems
3. Interoperability: Support identifiers that bridge different governance frameworks (e.g., vLEI and other credential ecosystems)

This enables KERI's vision of a universal trust spanning layer.

Relationship to KERI Security Model

Judges are integral to KERI's duplicity evident security model:

Duplicity Evidence vs Prevention

KERI does not attempt to prevent duplicity (which would require distributed consensus). Instead, it makes duplicity evident through:

1. Cryptographic Binding: Events are cryptographically bound to previous events
2. Witness Attestation: Multiple independent witnesses receipt events
3. Watcher Observation: Watchers collect all versions of events
4. Judge Analysis: Judges detect inconsistencies across witnesses

This approach is more scalable and performant than consensus-based systems.

Attack Detection

The source material emphasizes:

"The only 'fault' that is apparent to judges is an attack on the KEL. Such attacks can only occur via key compromise. Therefore, a successful multi-threshold attack causing duplicity is the only condition that watchers are actively monitoring for, and judges transmit the 'judgement' of watchers concerning duplicity."

This focused threat model allows judges to be highly effective at their specific task.

Recovery Facilitation

When duplicity is detected, judges facilitate recovery:

1. Identify Compromise Point: Determine where in the event sequence compromise occurred
2. Validate Recovery: Verify that recovery uses legitimate pre-rotated keys
3. Update Key State: Propagate the recovered key state to validators
4. Maintain Evidence: Preserve duplicitous events for forensic analysis

This recovery capability is unique to KERI and enabled by pre-rotation.

Conclusion

Judges are critical components in KERI's distributed validation infrastructure, providing authoritative determinations about identifier key state by examining witness attestations and detecting duplicity. By operating in a cooperative ecosystem model where even competitors share duplicity information, judges enable scalable, secure, and recoverable decentralized identity systems. Their focused role—validating key state and detecting duplicity—allows them to be highly effective without requiring the complexity of distributed consensus mechanisms, making KERI suitable for internet-scale identity infrastructure.