verification: successful results can collapse distinct decision-relevant verifier contexts

[altrudev]

Reproduced on frozen TRACE revision 6737005e1feefa5739d971a2b71ac123a4235220 using governed DSR job fe2b6851dcb866fb0ddcb43d639d8a10 on worker vps-377a113a.

Observed behavior

For the same signed TRACE v0.2 record and same trusted key:

• max_age_seconds=86400 vs max_age_seconds=None -> identical successful VerificationResult
• max_future_skew_seconds=300 vs 3600 -> identical successful VerificationResult
• now=iat+60 vs now=iat+120 -> identical successful VerificationResult

The result object contains only:

revocation
trusted_key_thumbprint

Control: revocation context is preserved. No revocation source yields no_check_performed; an empty consulted store yields verified, so those results differ.

Opposite-direction control: age policy is decision-relevant. At now=iat+86401, max_age_seconds=86400 rejects as stale while max_age_seconds=None accepts.

DSR output:

{
  "age_policy_collision": true,
  "skew_policy_collision": true,
  "verification_time_collision": true,
  "age_policy_semantically_live": true,
  "revocation_noncollision_control": true,
  "result_fields": ["revocation", "trusted_key_thumbprint"]
}

DSR status: PASS, exit 0, radial ALLOW, Parallax shadow ALLOW, signed worker result and DDC Action Receipt present.

Internal consistency point

TRACE's own non-normative docs/verification-outcome-statements.md says that, for a "Verified at the required floor" statement, evidence worth retaining includes:

• the record itself;
• the trusted-key thumbprint used;
• the freshness bounds applied;
• revocation evidence when consulted;
• the complete appraisal.

VerificationResult currently preserves the trusted-key thumbprint and revocation result, but not the freshness bounds or verification time used to reach the successful decision.

That does not prove the result type is wrong by itself: the page is informative, and a caller could retain verifier context separately. It does show that the repository already treats freshness configuration as part of the evidence needed to interpret a retained verification statement.

Governing invariant

If changing a verifier-side input can change the verification decision for the same signed record, that input is decision-relevant.

A successful result does not have to serialize every verifier input. But if a decision-relevant input is omitted from the retained result, then at least one of these has to be true for a later consumer to interpret the result without silently widening it:

1. the input is recoverable from a stable policy/configuration identifier or version carried with the result;
2. the input is retained in an external evidence statement explicitly bound to that result; or
3. the result is documented as process-local / context-dependent and must not be treated as a context-independent assurance statement.

Otherwise two successful verifications reached under materially different appraisal frames can collapse to the same retained value even though those frames are capable of producing different decisions.

Why this is not just timestamp logging

now is not interesting merely because the wall clock changed. It matters because the same record can move from accepted to stale under the same age policy. Likewise, max_age_seconds and max_future_skew_seconds are not metadata about the process; they are decision functions over the signed iat.

The counterexample therefore does not rely on two results merely occurring at different times. It relies on verifier-side inputs whose values are semantically live in the acceptance boundary.

Question

What is the intended contract of a successful VerificationResult?

• If it is only an immediate, process-local API return, should the documentation explicitly say that callers must retain the decision-relevant verifier context separately before turning it into a durable assurance statement?
• If it is intended to support retained/reproducible assurance statements, which decision-relevant inputs belong in the result itself, and which should be represented by a stable policy/configuration identity?

This seems adjacent to, but distinct from, #190 (unresolvable citations), #116 (version skew), #66 (verification axes), and #332/#338 (transition closure).

RATS/RFC 9334 treats a verifier as consuming Evidence, Reference Values, Endorsements, and an Appraisal Policy to produce Attestation Results; current EAR work also carries appraisal-context information. I am not proposing that TRACE copy EAR here. The repo-local issue is narrower: TRACE already says freshness bounds are evidence worth retaining, while the current success result does not retain or identify them.

Non-goals

This issue is not proposing:

• that every verify_record argument be copied into VerificationResult;
• that wall-clock time alone become an assurance field;
• a schema change to the signed Trust Record;
• a universal appraisal-policy format;
• that equal successful outcomes under different policies are themselves erroneous.

The question is only whether a retained success needs enough binding to its decision-relevant appraisal frame that a downstream consumer cannot mistake "verified under these conditions" for an unconditional verification fact.

AI-assisted research and falsification design; I remain responsible for the contribution.

[github-actions]

🔴 Contributor Check: HIGH

Check	Result
Profile	HIGH
Credential	LOW
Overall	HIGH

Automated check by AgenTrust Contributor Check.

[altrudev]

@imran-siddique following up on this one now that the adjacent runtime-evidence work has moved forward.

The question here is still intentionally narrower than a schema proposal: should a successful VerificationResult be treated only as an immediate/process-local outcome, or as something that can safely support a retained assurance statement?

The reproduced case is that decision-relevant freshness inputs can change the accept/reject boundary for the same signed record, while successful results reached under different values currently collapse to the same retained result. I am not suggesting every verifier input be serialized; a stable policy/config identity or an explicitly bound external appraisal statement would also preserve the distinction.

If the intended contract is process-local, I think a documentation clarification may be enough. If retained/reproducible use is intended, I can turn the existing reproduction into a narrowly scoped fixture/proposal around whichever binding model you prefer.

No urgency — I mainly want to avoid building the wrong abstraction before maintainer intent is clear.

[imran-siddique]

@altrudev the result should be read as the outcome of that verification call, under the inputs supplied to it. By itself, it is not a complete assurance statement that someone can save and interpret independently later.

Current main now retains profile and accepted_profiles, so the result has grown since your reproduction. Your freshness point still holds: it does not retain the record-age limit, clock-skew limit or verification time.

Let’s start with the documentation clarification. For later use, callers should retain those effective values alongside the exact record and result, including an explicit value when the age check was disabled. A policy version can identify the configured bounds if that version remains retrievable; the actual verification time still needs recording.

That follows the existing guidance in docs/verification-outcome-statements.md. A small example would make it concrete. We can consider additions to the result type separately, without changing the signed Trust Record.