[SCITT] Re: Verifier conformance behind the decision record: draft-correctover-ccs and a negative-test floor for pre-execution verification

[Walter Hawkins <[e-mail]>]

Doug, Guigui,

Agreed. Framing (1) as the baseline requirement and (2) as an attestation
profile keeps the abstraction boundary clean.

Making the join explicit in the evidence envelope so relying parties can
distinguish between a static build-to-conformance claim vs. a
hardware-attested runtime execution avoids collapsing distinct assurance
grades into a monolithic "conformant" label. Completely aligned.


Walter

On Mon, Sep 14, 2026 at 12:03 PM Douglas Wadkins <
[e-mail]> wrote:

> Walter,
>
> Thanks. This is the right shape, and your (1) is the piece I didn't state
> clearly enough. A signed statement binding a build digest to the
> conformance floor and vector set is the missing join. I think that is the
> requirement.
>
> I would separate (2) from it though as I don't think the two bindings
> eliminate the third-party trust problem. The conformance statement is still
> signed by somebody. The relying party still has to decide who that issuer
> is, what authority they have, and whether the statement applied at T. RFC
> 9943 leaves that trust decision to the relying party.
>
> The hardware doesn't remove that and it strengthens the other half. The
> attestation can bind this particular decision to the measured instance at
> T. But the measurement doesn't establish that the build passed Guigui's
> eleven vectors. That claim still comes from the signed conformance
> statement. So I would rather not make the TEE the answer. It is a strong
> construction where both sides can appraise it, but it shouldn't be the
> requirement.
>
> I think the requirement is that the evidence makes the join explicit. A
> relying party should be able to tell whether it has a signed
> build-to-conformance binding, that plus runtime attestation, or something
> weaker. Those shouldn't all just look like "conformant."
>
> So (1), yes, stated as the requirement. (2) as one way to make the runtime
> side stronger.
>
> Doug
>
>
> *From: *Walter Hawkins <[e-mail]>
> *Date: *Saturday, September 12, 2026 at 06:41
> *To: *Douglas Wadkins <[e-mail]>
> *Cc: *Guigui Wang <wangguigui=[e-mail]>,
> [e-mail] <[e-mail]>
> *Subject: *Re: [SCITT] Re: Verifier conformance behind the decision
> record: draft-correctover-ccs and a negative-test floor for pre-execution
> verification
>
> Doug, Guigui,
>
> This thread hits the exact structural boundary that needs formalizing.
>
> Doug's framing of the join is spot on:
> > "At T+n, how does a relying party independently determine that the
> verifier instance that signed this particular receipt was the
> implementation that satisfied the cited conformance floor and that the
> tested or audited code and configuration were actually the ones in force at
> T?"
>
> `config_hash` and `issuer` URIs identify policy and identity, but they
> cannot prove execution integrity at evaluation time. A software-only
> verifier can claim it ran negative vector set v1.2 while silently running
> an unpatched binary.
>
> To make the join independently determinable at T+n without introducing
> trusted third-party auditors into the loop, two bindings are required:
>
> 1. **Static Conformance Statement:** A signed endorsement (or registered
> SCITT statement) linking a specific build digest (code measurement / image
> hash) to the evaluated negative-vector floor (e.g. Guigui's 11 CCS vectors).
> 2. **Instance Hardware Measurement Binding:** The running evaluator
> executes inside a hardware-isolated confidential environment (e.g. TEE).
> The hardware attestation quote embeds the measurement of the running binary
> (e.g. MRTD/PCR values) and binds the RFC 8785 receipt hash directly into
> its attested user-data field (`reportData`).
>
> When relying parties evaluate the receipt at T+n, the verification is
> closed:
> - The receipt binds the event and verdict (Permit / Capsule).
> - The hardware measurement in the receipt matches the build digest in the
> registered conformance statement.
> - The conformance statement attests that this exact build passed the
> negative vector floor.
>
> This keeps Guigui's 7-dimension evaluation floor and Doug's lifecycle
> layers clean, while grounding the evaluator's runtime truth in verifiable
> cryptographic hardware rather than administrative trust.
>
> Walter
>
> On Thu, Sep 10, 2026 at 11:06 AM Douglas Wadkins <
> [e-mail]> wrote:
>
> Guigui,
>
> Useful framing and I think the gap is real but I would describe it a bit
> different.
>
> The negative vectors establish a property of an implementation and given
> those cases a conformant verifier must reject them. The receipt establishes
> a property of a particular event and this verifier says it evaluated this
> request under this configuration and reached this verdict.
>
> CCS already binds the request, parameters, runtime context, rule summary
> and configuration, so the missing piece is not another policy or input
> identifier. The remaining question is the join between those two claims.
>
> At T+n, how does a relying party independently determine that the verifier
> instance that signed this particular receipt was the implementation that
> satisfied the cited conformance floor and that the tested or audited code
> and configuration were actually the ones in force at T?
>
> config_hash does real work as it prevents a verifier from being
> reconfigured after issuing a receipt. What it doesn't do is show that the
> configuration it commits to is the one that was tested. And issuer is a
> Verifier URI, so the receipt identifies which verifier answered, not which
> build answered. A conformance run or audit tells me what an implementation
> did when tested. Neither, by itself, binds this decision to that tested
> evaluator.
>
> So the useful companion is a binding from the decision receipt to a signed
> conformance or attestation statement. That statement would identify the
> verifier implementation, the conformance level and vector-set version, and
> the configuration or policy floor to which the result applies. Stronger
> assurance could additionally bind a measurement of the running instance.
>
> This leaves the layers clean: Permit records the pre-execution decision,
> CCS defines the verifier floor, and the additional binding makes the
> relationship between the two independently determinable later.
>
> Doug
>
> *From: *Guigui Wang <wangguigui=[e-mail]>
> *Date: *Thursday, September 10, 2026 at 01:21
> *To: *[e-mail] <[e-mail]>
> *Subject: *[SCITT] Verifier conformance behind the decision record:
> draft-correctover-ccs and a negative-test floor for pre-execution
> verification
>
> Hi SCITT WG,
>
> Following the agent-action evidence work here and on agent2agent - the
> Permit profile (draft-munoz-scitt-permit-profile), Agent Action Capsules
> (draft-mih-scitt-agent-action-capsule), the NOA SCITT agent-receipt
> profile, and the AgentInteractionRecord profile - I would like to share an
> adjacent individual draft and ask where it might usefully fit.
>
> These profiles do a thorough job on the form of evidence: a signed,
> registered, independently verifiable record of a pre-execution decision
> (Permit) or of a post-execution action (Capsule / AIR / NOA), bound to
> request bytes, with authority lineage and transparency receipts. Each also
> explicitly stops short of the decision's content. The Permit profile does
> not specify "a policy language or evaluation engine," and a Capsule
> Constraint Record binds a pass/fail verdict while the actual predicate,
> evidence schema, and thresholds remain in the producer's own manifest.
>
> That leaves a gap at the verifier itself. A gate that always returns
> "allow" emits perfectly conformant Permits and Capsules. The envelope
> proves that a decision was made and which bytes it authorized; by itself it
> cannot show that the verifier actually evaluated the things that make an
> allow/deny trustworthy - it does not, on its own, address the omission
> case: a check that should have fired and did not.
>
> draft-correctover-ccs-08 (Correctover Conformance Shape; an individual
> Internet-Draft submitted to the Independent Submissions Editor for
> consideration - not an RFC and not an IETF endorsement) is aimed at that
> layer: the verifier rather than the record.
>
> - Seven runtime-verification dimensions evaluated on every tool call:
> Structure, Schema, Latency, Cost, Identity, Integrity, and Security - the
> Security dimension carrying semantics-aware checks for command injection,
> SSRF, and credential exfiltration rather than keyword matching.
> - A fail-closed verdict model (allow / deny / escalate): "no evidence, no
> execution."
> - Eleven negative test cases (attacks and tamperings that a conformant
> verifier MUST block) plus Level 0-4 conformance with a verifier policy
> floor - a falsifiable definition of "the gate fires," which is the
> complement a "capsule on every verdict" record needs in order to mean
> anything.
> - Ed25519 detached signatures over RFC 8785 (JCS) receipts, and two
> independent interoperable implementations sharing a conformance vector
> format (Section 21).
>
> The intended relationship is compositional, not competitive. CCS defines
> no envelope, transparency log, authority lineage, or request/closure
> binding - those are SCITT, Permit, and Capsule. The natural seams are:
>
> 1. a CCS-conformant verifier's receipt as the evaluation-sufficiency
> evidence behind a Permit - the "policy/evaluation engine" the Permit
> profile deliberately leaves open - with the CCS negative vectors serving as
> an anti-omission floor;
> 2. the CCS verdict and rule summary as an interoperable form for what a
> Capsule Constraint Record commits to (shared check categories and a
> conformance floor, rather than producer-local check ids).
>
> I would be glad to contribute the negative test vectors and verifier-floor
> material to whichever may-layer draft the WG prefers, and I am fully open
> to being told this overlaps more than I think with in-flight work. Pointers
> and corrections are very welcome.
>
> Thanks,
> Guigui Wang
> Correctover - AI Reliability
> draft: https://datatracker.ietf.org/doc/draft-correctover-ccs/
> (individual submission, not an RFC or IETF endorsement)
>
> --
> SCITT mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> --
> SCITT mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
>