Add ComputeID AgentPassport TRACE adapter (community tier)

[trustedaicompute-ops]

Adds a community-tier integration mapping ComputeID AgentPassport /verify evidence into a TRACE v0.2-shaped record, via the third-party-control-plane / external-evidence-source path.

Honest, current result: FAIL at Level 0, 4 of 8 checks fail (missing cnf/proof-of-possession binding, and no policy/appraisal fields, since ComputeID is an identity-issuance system, not an execution-attestation runtime). No trace_conformance_level is declared for this reason. Full result and reasoning in CONFORMANCE.md.

Includes real, reproducible evidence: a genuine, unmodified ComputeID /verify response, an offline verifier requiring zero network calls, and a separate audit-chain integrity tool. The two hardest cryptographic checks (classical RSA-SHA256 and post-quantum ML-DSA-65 signature verification) pass and were adversarially tested (correctly fail against a fake CA certificate).

Will open a separate spec issue on trace-spec for the cnf/proof-of-possession gap and its relation to our existing DPoP support, as requested.

[imran-siddique]

Thanks for the submission, and for keeping the Level 0 failure and the software-bound scope in the package rather than around it.

I ran the package: convert-to-trace.js against evidence/opaque-diligence-demo-fresh.json, agentrust-trace-tests 0.5.1 from PyPI, and the schema at your pinned commit 3a561d84. The evidence is genuine. Recomputing independently of your code: RSA-SHA256 over signed_payload against public_key verifies, and ML-DSA-65 over the same bytes against pq_public_key verifies with @noble/post-quantum 0.4.1 (pk 1952 bytes, sig 3309 bytes) and fails on a modified payload. The receipt signature verifies against the included ca-cert.pem.

Six changes before this can be listed.

1. CI, two failures are yours to fix.

• validate: marketplace.category: "Identity and access" is not in the enum. Use Identity & trust.
• links: repository: https://github.com/trustedaicompute-ops/computeid-backend returns 404. Point it at a reachable URL.
• (gate is waiting on maintainer approval, not on you.)

2. The documented result does not reproduce. README says FAIL (8 checks, 4 failure(s)). Running 0.5.1 at Level 0 today:

  TR-ENV  PASS        eat_profile sentinel matches
  TR-ENV  FAIL        TR-ENV-002: record is stale: iat 1788607112 is 299155s old, exceeding the maximum allowed age of 86400s
  TR-ENV  PASS        subject is a valid workload identity URI
  TR-ENV  FAIL        cnf must contain jwk with kty
  TR-SIG  FAIL        TR-SIG-004: cnf.jwk.kty is missing
  TR-SIG  UNVERIFIED  TR-SIG-005: no signature present; this record is NOT cryptographically verified
  TR-POL  FAIL        TR-POL-001: policy field is missing or not an object

Result: FAIL  (7 checks, 4 failure(s), 0 skipped)

Two problems. TR-APR-001 is cited in CONFORMANCE.md but does not exist in 0.5.1; the modules are ANC, ENV, POL, RTE, SCA, SIG, TXN. (appraisal is required by the schema, which is a different statement, and worth making in those terms.) And the result is clock-dependent: iat is fixed in a static bundle, so TR-ENV-002 fires once the capture is over 86400s old. Please regenerate against the pinned version, paste verbatim output, and record the capture time and the --max-age used.

3. The emitted record fails the schema at your own pinned commit. 31 errors, 10 of them from references: items require rel, id, resolver, and name/value are rejected as additional properties. TRACE-MAPPING.md §4 already describes the correct pointer shape; the adapter does not emit it. §4 also turns the outcomes into claims rather than pointers, which is the thing §3.1.2 is trying to prevent.

TRACE-MAPPING.md §7 is stale: it still says the mapping "has not been run through, and has not passed, the TRACE conformance suite" and reports 1185 passed, 1 skipped, which is the suite's own self-test, not your result. Delete or rewrite it so it agrees with CONFORMANCE.md.

4. offline-verifier.js does not verify the passport signatures. It reads bundle.signature_valid and bundle.pq_signature_valid from the service response and reshapes them. Its only cryptographic operation is checkIssuerTrusted. So the "independently computed" and "adversarially tested" framing does not describe the shipped code, even though the underlying evidence supports it (see above). Move those two computations into the verifier and the claim becomes true.

Related: verify-audit-chain.js requires pg, and there is no package.json or install step in the directory.

5. The receipt does not bind the passport keys. The receipt payload is:

{"expires_at":"...","issued_at":"...","key_id":"ebb276c2f18ed34f","passport_id":"f5d6cf87-...","signature_valid":true,"status":"active"}

It does not cover public_key, pq_public_key, or signed_payload. So the CA signature attests that ComputeID asserts this passport verified, not that these are the keys ComputeID issued for this subject. An offline verifier still has to trust the assertion for key binding. This is the question from my note of September 2 about how the two public keys are bound to the same subject and lifecycle, and it sits upstream of the cnf gap. Please carry it into the spec issue rather than filing cnf alone.

6. The record is unsigned. TR-SIG-005 reports it as not cryptographically verified. You already sign with two algorithms, so signing the emitted record is the shortest path to moving a check.

Not blocking, and correctly handled: no trace_conformance_level declared, runtime.platform: software-only, origin.kind: third-party-control-plane, and the hardware-attestation scope statement.

Community listing follows CI passing and a maintainer review of the revised package. Verified status requires us to run the integration end to end.

[imran-siddique]

Starting with the part that decides whether this gets listed at all: you declared your own failure. The metadata description says the adapter "does not currently pass TRACE conformance at any level", the PR body states FAIL at Level 0 with four of eight checks failing and gives the reason, no trace_conformance_level is claimed, and offline-verifier.js carries a note saying the wrapper only reshapes fields the live endpoint genuinely computes. A community-tier entry that publishes its own shortfall is worth more to a reader than one that passes quietly, because the catalog is only useful if an entry's claims can be believed.

Your CI had never actually run. Eight workflow runs were sitting in action_required, so the two checks you could see were not a verdict. They are released now and there are exactly two failures, both one line in integration.yaml, neither touching the adapter itself.

validate, on the schema enum:

marketplace: {category: "Identity and access", mark: CID}

Identity and access is not one of the eight permitted categories. The one you want is Identity & trust. Full set: Compliance, Developer tools, Evidence & receipts, Frameworks, Identity & trust, Model & weight custody, Observability, Security & policy.

links, one 404:

repository: https://github.com/trustedaicompute-ops/computeid-backend

That repository does not resolve. Your public repositories include computeid-passport, computeid-sdk, computeid-cli and computeid-mcp-gateway, so I expect this is a rename or a private repository rather than a wrong claim. Point it at something a reader can open; a maintainer cannot verify a listing whose source is unreachable.

Everything else is green: check, ruff and all four verify jobs.

One note, not blocking. tested_against pins agentrust-trace: "0.5.1" and the current release is 0.10.0. Recording the version you actually tested is correct and I would not have you change it to a version you did not run; it is worth knowing whether the mapping still holds on 0.10.0 before this is cited anywhere.

Your #307 in trace-spec is the substantive half of this and I have read it. It is a different conversation from the two lines above and will get its own answer there rather than here, so this PR is not waiting on it.