related_claims: carry the claim-vs-referenced-proof comparison result inside the proof? (proposal, from #279)

Abierto
  • ¿Algo no está bien?
#398 11 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
python
Área
security

Línea de trabajo

Start by reading the discussion on #279 and the existing proof_chain_check.py example to understand the current comparison and the unresolved design question. The issue asks whether TRACE should record the comparison result in the proof; implementation is conditional on that decision. If accepted, done means a new policy version records the result and vectors and negative cases cover the listed scenarios.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

needs-review:HIGH

Opened at @imran-siddique's invitation on #279 (separate item; opening it does not mean TRACE agrees to add anything). This is a proposal, not shipped: the accepted context-provenance example shows where the gap is, this asks whether TRACE wants it closed inside the proof.

The example that exists today

Outer event 303c3d928a60ee55d15f33cf66d5b75f6e3434c6dc4e1775a12c017cfc4d6a31 references inner event 7aa10c9783ef2e96d33d8edb383583d126b6240589f824b39933600e79587002 through related_decision_ref (in the signed preimage). The caller's context is a fixed-grammar sentence in disclosed_summary restating the inner proof's artifact_hash, verdict, verified_at, policy_version, decision_ref and event id. A stdlib checker (proof_chain_check.py, 10 checks, 24 negative cases; you ran it at 2883f1b) parses each named field and compares exact values. Anything outside the grammar is CANNOT_ESTABLISH.

The gap that example leaves

The comparison lives in the verifier's script. The server verified the referenced proof and bound related_decision_ref, but it did not itself check the caller's claim against that proof, and the check result is not in the proof. So the proof cannot say "the claim matched" by itself, and a verifier that skips the script gets the reference without the comparison.

Proposal

A caller-supplied related_claims object ({artifact_hash, verdict, verified_at, policy_version, decision_ref}), compared by the server against the referenced proof it already re-verifies, with the result (matched | mismatched | not_supplied) bound into the preimage next to related_decision_ref. It is a policy-version change (new field list entry, registered per version), and a mismatch never upgrades context_provenance.

What a checker could establish

  • Exact equality of the named fields between the claim and the referenced proof, recomputed offline from the two events (the script above, unchanged), plus that the recorded result equals what that comparison gives.
  • That a claim which does not match is recorded as mismatched, not dropped.

What would remain unknown (stated so it is not oversold)

  • That the referenced verdict supports the action or the text of this call. Equality of restated fields says the restatement is faithful, not that it is relevant or sufficient. You made this point on the thread and it is not addressed by this proposal.
  • Anything about the referenced proof's own truth beyond its signature and decision_ref.
  • Retention: the referenced proof must still be obtainable; our store lost its events on 2026-09-20 (cause and fix on #279), which is why examples live in the repo and not only on the API.

Ask

Does TRACE want the comparison result carried inside the proof, or is a verifier-side script the right place for it? If inside, I will implement it behind a new policy version with vectors and negative cases (changed field, swapped slots, claim omitted, mismatch must not upgrade the label) before anyone is asked to rely on it. If not, I will leave the script as the reference and not add the field.

Lenguaje dominante
Python
Estrellas
37
Forks
33
Merge medio
1 d 18 h
PR fusionados (30 d)
118

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de agentrust-io/trace-spec

Todos los issues de agentrust-io/trace-spec

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.