Skip to content

INTEROPERABILITY.md

Latest commit

 

History

History
129 lines (78 loc) · 2.9 KB

INTEROPERABILITY.md

File metadata and controls

129 lines (78 loc) · 2.9 KB

CVS Interoperability

This document defines how independent implementations of the Cryptographic Verification Sidecar (CVS) verify, exchange, and validate evidence without shared control or coordination.

The canonical CVS specification is defined by:

  • CVS_ARCHITECTURE_v2.7.md
  • CVS_IMPLEMENTATION_v2.2.md

If conflict exists, the canonical specification governs.

This document is normative where RFC-2119 language appears.

Design Objective

CVS interoperability ensures that:

  • independent operators can verify evidence without trust,
  • multiple implementations can coexist,
  • evidence remains portable across systems,
  • no central authority is required.

Interoperability preserves independence.

Evidence Portability

A CVS-Conforming implementation MUST:

  • serialize Evidence Objects deterministically,
  • preserve canonical field ordering,
  • disclose hash algorithms used,
  • expose verification instructions sufficient for third-party validation.

Evidence must be interpretable without proprietary tooling.

Cross-Implementation Verification

Independent implementations MUST be able to:

  • validate evidence chains generated by other CVS-Conforming systems,
  • detect alteration or omission,
  • verify settlement anchoring proofs.

Verification MUST NOT depend on shared infrastructure or shared operators.

Settlement Neutrality

Settlement-layer choice MUST NOT affect:

  • Evidence Object structure,
  • hash chaining integrity,
  • independent verification capability.

Implementations MAY support multiple settlement profiles, provided canonical evidence structure remains unchanged.

Disclosure Compatibility

Selective disclosures MUST:

  • preserve chain continuity,
  • reveal scope boundaries clearly,
  • enable independent verification of disclosed segments.

Disclosures from different implementations must remain verifiable using publicly documented rules.

Version Identification

Implementations SHOULD:

  • declare the CVS canonical version they implement,
  • document supported algorithm profiles,
  • disclose any optional extensions.

Version transparency prevents ambiguity.

Extension Boundaries

Optional extensions MAY exist provided they:

  • do not alter canonical Evidence Object semantics,
  • do not introduce hidden authority,
  • do not compromise independent verification.

Extensions must be clearly identified as non-canonical.

Non-Conformant Interoperability Patterns

The following patterns undermine interoperability:

  • proprietary evidence formats,
  • undocumented hash algorithms,
  • opaque verification requirements,
  • mandatory reliance on centralized services.

Such systems should not be described as CVS-Conforming.

Scope Limitation

This document defines interoperability requirements.

It does not:

  • certify compatibility,
  • guarantee legal sufficiency,
  • mandate cross-organizational integration.

Interoperability is technical, not institutional.