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

Spec change proposal: resolve TRACE v0.2 verifier contradictions from #591

Open
  • Is something wrong?
#593 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Documentation
Clarity
Clearly specified
Activity status
Active
Tech stack
python
Domain
documentation, security

Research direction

Read the v0.2 text in §§3.1, 3.1.5, 3.2.2, and 3.3, then review the per-input study and reproduction linked in #591. The proposed text, schema descriptions, and tests are expected in a linked draft PR; use them to check that each reported contradiction has a testable resolution. Done means the proposal has been discussed through the required 30-day comment period and has organizational sponsorship and Project Lead approval.

Written by the indexing model from the issue text.

Description

Spec sections affected
§3.1 (base-record fields and conformance levels), §3.1.5 (platform measurement appraisal), §3.2.2 (embedded signature), and §3.3 (verification sequence).

Problem
Issue #591 reports four reproducible disagreements between the v0.2 text, schema, and reference verifier: whether a base record requires tool_transcript and transparency; whether a signature checked only against the record's own cnf key authenticates origin; whether the verifier rejects a signed platform appraisal about another runtime measurement; and whether JWT-context ES256 support defines an ES256 top-level embedded signature. The report does not establish a deployed vulnerability.

Proposed change

  1. In §3.1, mark tool_transcript optional in the base record and required for Level 2 transcript checks. Mark transparency optional below Level 2 and required for Level 2 anchoring checks. Omission makes no transcript commitment or anchoring claim.
  2. In §3.3, require an issuer key trusted independently of the incoming record, or a signature chain validated to an accepted root, before reporting authenticated origin or a verification pass. Verify the signature against that trusted key and confirm that it matches cnf. A self-key-only check is diagnostic internal consistency.
  3. Retain the §3.1.5 rule that signed appraisal.platform_measurement.measurement equals this record's runtime.measurement, and enforce it in the reference verifier and conformance suite.
  4. In §3.2.2, specify Ed25519 with an OKP/Ed25519 cnf.jwk and a 64-byte signature for the v0.2 base embedded form. A different embedded algorithm needs a separately defined profile. JWT-context algorithms and separately defined enveloping profiles are unaffected.

The proposed text, schema descriptions, and tests will be in a linked draft PR. This issue starts discussion; it is not a request for immediate acceptance.

Backward compatibility

  • Non-breaking (new optional field, informative addition)
  • Breaking (changes algorithm set or accepted records)

Existing top-level embedded records using ES256 or another non-Ed25519 algorithm would need to use Ed25519 or a separately defined profile/enveloping form. Verifiers that accept only a self-supplied cnf key as authenticated origin must instead obtain an independent trust anchor. A signed appraisal about a different measurement must be rejected. Level 2 still requires transcript and anchoring evidence; base records without those fields remain valid at lower levels. Existing Ed25519 records with matching appraisals and separately defined enveloping signatures are unaffected.

Motivation
Give independent implementers and the reference library one testable interpretation of the same v0.2 record. See the per-input study and reproduction linked in #591. The required 30-day comment period, organizational sponsorship, and Project Lead approval remain open before any merge.

Related issues or PRs
#591

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

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.