DEV Community

correctover
correctover

Posted on

Two Independent CCS Implementations Achieve 14/14 Interoperability

#ai #security #mcp #ietf

The Correctover Conformance Shape (CCS) specification — IETF Internet-Draft draft-correctover-ccs-06, Experimental status — defines a runtime verification framework for AI agent tool calls across seven dimensions: Structure, Schema, Latency, Cost, Identity, Integrity, and Security.

As of August 2026, two independent implementations from separate codebases now pass all 14 conformance checks. This post documents what was achieved and what it means.

The Two Implementations

Correctover Reference Implementation

  • npm package correctover at version 2.4.9
  • ccs-verifier Python package
  • Serves as the reference implementation accompanying the draft

EMILIA Protocol Independent Implementation

The EMILIA runner is located at conformance/composition/ccs-v13-aeb-v1 in the emilia-protocol repository.

The 14 Conformance Checks

The EMILIA runner passes all 14 checks:

  1. Source pin — SHA-256 of the draft bytes
  2. Structural separation from v1.1 shape
  3. Live response binding
  4. Ed25519 verification
  5. Exact-action CAID mapping
  6. Signature mutation detection
  7. Untrusted key rejection
  8. Audience binding
  9. Freshness
  10. Parameter substitution detection
  11. Full-digest substitution (16-hex params_hash)
  12. Consumed status
  13. Unavailable status
  14. Native deny non-authorizing

Technical Details

The v1.3 receipt contains 22 fields. A detached Ed25519 signature is computed over the RFC 8785 canonical JSON serialization of fields 1–21. Field 22 carries the signature itself and is excluded from the signing input.

Key mechanisms:

  • CAID (Correctover Action ID) provides exact-action mapping, ensuring each verified receipt corresponds to a specific tool action rather than a loose category.
  • AEB (Admission Enforcement Boundary) defines the enforcement point where conformance is checked before execution proceeds — the boundary between admission and execution.
  • The signature construction uses JCS (JSON Canonicalization Scheme per RFC 8785) with ensure_ascii=False to maintain proper Unicode handling during canonicalization.

What Changed in draft-06

The -06 revision includes several substantive clarifications:

  • AEB and CAID promoted to Normative References — they are no longer illustrative appendices but normative components of the specification.
  • Detached Ed25519 signature construction specified normatively — the exact construction of the signing input and detached signature is now a normative requirement rather than descriptive text.
  • JCS serialization corrected — ensure_ascii=False is required for RFC 8785 compliance; the previous text did not make this explicit.
  • Receipt lifecycle clarified as two-phase — pre-execution admission durability (the receipt is persisted before the action runs) followed by post-execution finalization with response_hash (the receipt is updated with the response digest after the action completes).
  • Field 22 clarified as Ed25519-only for v1.3 — the signature field carries an Ed25519 detached signature; other signature types are not in scope for this version.

What This Means (and What It Doesn't)

The IETF's founding principle is "rough consensus and running code." Two independent implementations from separate codebases achieving 14/14 on the conformance suite is the strongest available evidence that the specification text is sufficient to build an interoperable implementation without reference to the author's own code. This is the bar for an Experimental RFC: demonstrate that the protocol can be built independently and that independent builds agree.

It is important to be precise about scope:

  • These are conformance and reference implementations, not production deployments.
  • CCS is an IETF Experimental protocol published as an Internet-Draft, not an IETF standard.
  • The value here is interoperability evidence, not market adoption claims.

Interoperability testing confirms that the specification is implementable from the text alone. It does not, by itself, prove production readiness, security at scale, or real-world deployment. Those are separate questions that require separate evidence.

Links

Top comments (0)