The eSSIF-Lab framework established a foundational definition: validation is "the act, by or on behalf of a party, of determining whether or not data is valid to be used for some specific purpose(s) of that party." This definition emphasizes the contextual, purpose-driven nature of validation - data validity is not absolute but relative to specific use cases and party requirements.

NIST standards complemented this with a more formal definition: "Confirmation, through the provision of objective evidence, that the requirements for a specific intended use or application have been fulfilled." This highlights the need for objective evidence and requirement fulfillment as validation criteria.

KERI's Approach

KERI implements a sophisticated multi-stage validation architecture that separates concerns while maintaining cryptographic rigor:

Validator Role and Responsibilities

In KERI, a validator is "any entity or agent that evaluates whether or not a given signed statement as attributed to an identifier is valid at the time of its issuance." This role involves determining the current authoritative key set for an identifier from at least one key event log, then applying additional criteria to assess validity for specific use cases.

The validation process follows a clear hierarchy:

1. Cryptographic Verification: The validator must first act as a verifier to establish the root authoritative set of keys through signature validation
2. Structural Validation: Checking that key event logs comply with KERI protocol rules (proper sequencing, hash chaining, threshold satisfaction)
3. Policy Application: Applying use-case-specific criteria or constraints to determine validity
4. Duplicity Detection: Evaluating whether multiple versions of a KEL exist (external inconsistency)

KEL Validation Specifics

For Key Event Logs, validation involves evaluating whether the log can be trusted for establishing control authority. A valid KEL must be:

• Internally consistent: Proper backward/forward chaining, valid signatures, correct sequence numbers
• Externally consistent: No duplicitous versions exist (or duplicity is detected and handled)
• Threshold-satisfying: Sufficient witness receipts or validator confirmations
• Policy-compliant: Meets any additional requirements for the specific use case

Critically, KERI's duplicity detection mechanisms enable validators to identify when a controller has published multiple inconsistent versions of their KEL. This "duplicity evident" property allows validators to make informed trust decisions even in adversarial scenarios.

ACDC Credential Validation

For Authentic Chained Data Containers (ACDCs), validation extends to:

• Schema compliance: Credentials must validate against their declared JSON Schema
• Chain integrity: Edge properties linking credentials must reference valid parent credentials
• Revocation status: Checking Transaction Event Logs (TELs) for credential revocation
• Authorization chains: Verifying that issuers have proper authority through credential chains
• Attribute constraints: Ensuring credential attributes meet verifier requirements

The ACDC specification's authorization system demonstrates this layered approach. The Authorizer class implements four filter types (credential filters, chain filters, edge filters, attribute filters) that progressively validate credentials beyond basic cryptographic verification.

Watcher-Based Validation

KERI's watcher infrastructure provides ambient validation capabilities. Watchers maintain copies of KELs and apply the "first-seen wins" rule, enabling validators to:

• Query multiple watchers for KEL consistency
• Detect duplicity through comparison of watcher-held logs
• Establish confidence levels based on watcher agreement
• Implement threshold-based validation policies

This distributed validation model removes single points of failure while maintaining cryptographic verifiability.

Practical Implications

The distinction between validation and verification has significant practical consequences:

Use Case: Credential Presentation

When a holder presents an ACDC credential to a verifier:

1. Verification confirms: signatures are cryptographically valid, SAIDs match content, schema structure is correct
2. Validation determines: is this credential type acceptable? Is the issuer authorized? Are attribute values within acceptable ranges? Has the credential been revoked?

A credential can be perfectly verified (cryptographically sound) yet invalid for a specific use case (wrong issuer, expired, insufficient attributes).

Use Case: AID Control Authority

When establishing control authority over an AID:

1. Verification proves: the KEL is internally consistent, signatures are valid, events are properly chained
2. Validation assesses: is there duplicity? Do sufficient witnesses confirm? Does the key state meet security requirements for this transaction?

A validator might accept a KEL for low-stakes interactions but require additional witness confirmations for high-value transactions - same verification, different validation criteria.

Benefits

• Separation of concerns: Cryptographic operations separated from policy decisions
• Flexibility: Different validators can apply different policies to the same verified data
• Auditability: Validation criteria can be explicitly documented and evaluated
• Scalability: Verification can be cached while validation adapts to changing requirements

Trade-offs

• Complexity: Implementers must understand both verification and validation requirements
• Performance: Multi-stage validation adds computational overhead
• Policy management: Validation policies require governance and maintenance
• Interoperability: Different validators may reach different conclusions about the same data

Implementation Considerations

KERI implementations must carefully distinguish validation from verification in their APIs and documentation. The validator role requires access to:

• KEL processing capabilities for key state determination
• Watcher networks for duplicity detection
• Policy engines for use-case-specific evaluation
• TEL registries for credential status checking

The validation process should be transparent and auditable, with clear documentation of which criteria were applied and why specific validation decisions were made. This transparency enables trust without requiring trust in the validator itself - the validation logic can be independently verified.