verification.md: format-versioning and verifier-compatibility obligations (evidence outlives verifiers)
Los mantenedores suelen responder en 1 día
@lywinged ya está trabajando en esto.
Desde el 7/9/2026.
Evaluación
Este issue todavía no se ha evaluado.
Descripción
Spec gap. Compliance evidence is verified years after issuance — the artifact routinely outlives the verifier build — and the profile/enum surface is already evolving pre-1.0 (#114 proposes a new profile URI precisely to avoid breaking existing verifiers). But verification.md currently has no normative statement of what a verifier must do about version skew. Without one, every future revision risks silently orphaning existing evidence — or worse, verifiers "helpfully" accepting artifacts under semantics they don't actually implement.
Production context: in our per-action receipt format the hash-computation order is load-bearing — any change orphans every previously issued artifact. What held up operationally: a mandatory format-version field, plus a verifier obligated to check every version it claims to support and to say which version it verified under in its output.
Proposed obligations for verification.md:
- Every record/receipt carries an explicit format/profile version (the profile-URI direction in #114 already implies this — this makes it a verifier obligation, not just an emitter convention).
- A conformant verifier declares the set of versions it supports and MUST refuse versions outside that set — refuse, not best-effort.
- The verification statement includes the version under which verification ran.
- Any downgrade/fallback behavior MUST be disclosed in the statement; silent fallback is non-conformant.
Conformance vectors for trace-tests:
- unknown-version artifact → must refuse (fail-open here is the dangerous default)
- known-version artifact → verified under correct semantics, version echoed in the statement
- downgrade-with-disclosure → conformant
- silent downgrade → must fail conformance
Happy to draft the section plus the vectors — this composes with the verifier-obligations ADR discussed in #66 and the offline verification statement discussed in #76.
- Lenguaje dominante
- Python
- Estrellas
- 37
- Forks
- 33
- Merge medio
- 1 d 4 h
- PR fusionados (30 d)
- 122
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de agentrust-io/trace-spec
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
agentrust-io/trace-spec#593 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
bug needs-review:HIGH
Dificultad 5/5 Más de una semana Aptitud para principiantes 20/100
agentrust-io/trace-spec#591 · 4 comentarios ·
Los mantenedores suelen responder en 1 día
-
prototype(manifest_requirements): resolve accepted_methods without duplicating bindings and reject unconfigured binding endpoints with ProfileErrorPosiblemente ocupada @drk-ram la tomó hace 1 día. Abierto
Dificultad 3/5 1-2 días Aptitud para principiantes 78/100
agentrust-io/trace-spec#580 ·
Los mantenedores suelen responder en 1 día
-
feat(delegation): add parent_record_hash, verify_delegation_link, and verify_delegation_chain to agentrust_tracePosiblemente ocupada @drk-ram la tomó hace 1 día. Abierto
Dificultad 4/5 3-5 días Aptitud para principiantes 58/100
agentrust-io/trace-spec#581 ·
Los mantenedores suelen responder en 1 día
-
revocation,trust-record-verify: implement es256 and es384 bundle verification and add EC revocation vectors (#448 items 1, 10)Posiblemente ocupada @drk-ram la tomó hace 1 día. Abierto
Dificultad 4/5 3-5 días Aptitud para principiantes 52/100
agentrust-io/trace-spec#584 ·
Los mantenedores suelen responder en 1 día
Todos los issues de agentrust-io/trace-spec
Issues similares
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
ansys/pyansys-common-mcp#213 ·
Los mantenedores suelen responder en 3 días
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 67/100
freedomofpress/dangerzone#1594 ·
Los mantenedores suelen responder en 3 días
-
priority:P1 status:in-review type:bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
randomparity/kdive#3317 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
area:ci
Dificultad 1/5 Menos de una hora Aptitud para principiantes 90/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 66/100
mesonbuild/meson#16281 ·
Los mantenedores suelen responder en 1 día