Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

test(conformance): portable PIC/TRACE bridge corpus and independent verifier

Open
  • Is something wrong?
#206 11 comments 0 reactions 1 assignee View on GitHub

Maintainers usually reply within 1 day

@coreytshaffer is already working on this.

Since Sep 7, 2026.

Assessment

This issue has not been assessed yet.

Description

needs-review:MEDIUM

Spec section affected

  • docs/integration/pic-trace-bridge-v1.md
  • Bridge verifier tests and the eventual conformance-corpus location

Problem

Issue #179 delivered the PIC/TRACE authorization bridge design, schema, reference verifier, and eight implementation tests. Its completion note records a narrower remaining gap: those tests use inline fixtures and are not a portable vector set that a second implementation can consume.

TRACE already has a general cross-language RFC 8785/JCS corpus from PR #126. The remaining gap is bridge-specific:

  • Can another verifier reproduce the bridge-specific signed bytes and digests while using PR #126 for shared canonicalizer conformance?
  • Does it reach the same result at trust-key, time-window, scope, digest, and transcript boundaries?
  • Does each negative case fail for the intended rule rather than an unrelated earlier error?

Proposed change

This would be a non-normative, informative conformance addition. I propose a versioned JSON corpus for pic-trace-bridge-v1, an independent verifier, and a differential runner.

The case contract would contain:

  • bridge artifact and trusted-authorizer JWK;
  • declaration and PIC verifier outputs;
  • tool call and optional transcript;
  • fixed verification time;
  • expected semantic result and stable reason code; and
  • bridge-specific canonical bytes and reproducibility metadata where relevant.

Vector families would cover:

  1. valid bound execution;
  2. malformed and unknown-field rejection;
  3. signature, trust-key, and authorizer_key_id failures;
  4. deny, not-yet-valid, invalid-window, and expiry behavior;
  5. tool and impact scope mismatch;
  6. PIC, declaration, and tool-call digest mismatch;
  7. missing, partial, or contradictory transcript evidence; and
  8. cross-language canonicalization by reference to PR #126, with new signed-object fixtures only where the bridge introduces an additional input or binding.

The independent verifier would not import agentrust_trace.intent_bridge. The runner would execute the corpus against both implementations and report agreement or a preserved ambiguity. A bounded mutation check would verify that each negative vector makes its named rule load-bearing.

I would appreciate maintainer guidance on whether the corpus should live beside the bridge in trace-spec, in trace-tests, or initially in a standalone repository until the case contract and outcomes are reviewed.

Backward compatibility

  • Non-breaking (informative conformance corpus and tooling)
  • Breaking

No change to the completed bridge schema or verification semantics is proposed. Any ambiguity found during differential testing would be raised for maintainer decision before becoming a claimed conformance rule.

Motivation

Agreement between a verifier and inline tests constructed in the same codebase does not establish cross-implementation agreement. A portable corpus would let a second implementation test trust configuration, temporal boundaries, scope, execution binding, and failure classification without inheriting the reference implementation's assumptions.

Reusing PR #126 keeps generic JCS portability in one place and makes this contribution specifically about the authorization-to-execution bridge. The documentation would continue to keep authorization, execution binding, runtime attestation, and real-world outcome verification separate.

Acceptance criteria

  • A clean offline checkout regenerates byte-identical vectors.
  • Test-only signing material and corpus hashes are published and clearly non-production.
  • Every case validates against the versioned schema before semantic verification.
  • The AgenTrust reference verifier and independent verifier agree on all settled cases.
  • Differences are reported for maintainer decision rather than silently normalized.
  • Shared RFC 8785 behavior is reused from PR #126; any new canonicalization fixture exercises a bridge-specific input.
  • The corpus is language-neutral and usable by a future TypeScript, Rust, or other SDK.
  • Documentation preserves the boundary between authorization, execution evidence, attestation, and outcome claims.

Non-goals

  • No redesign of the completed bridge semantics.
  • No PIC dependency in the TRACE Trust Record schema.
  • No runtime self-asserted authorization or embedded trust anchor.
  • No claim that a valid authorization proves execution, outcome correctness, or TRACE attestation.
  • No attempt to settle the gated step_up and defer design in #191.

Related issues or PRs

  • Design origin and recorded portability gap: #179
  • Existing portable RFC 8785/JCS corpus to reuse: #126
  • Adjacent gated-decision threat-model context: #191

Implementation offer and relevant work

I would like to contribute the initial case contract, deterministic generator, independent Python verifier, differential runner, and documentation. Relevant prior work:

Dominant language
Python
Stars
37
Forks
33
Avg merge
1d 4h
Merged PRs (30d)
120

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from agentrust-io/trace-spec

All issues in agentrust-io/trace-spec

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.