Proposal: TRACE-v0.2 runtime governance attestation type + governed-agent registry federation

[imran-siddique]

Context

The ARD spec's trustManifest.attestations array is designed for extensible attestation types. The current examples cover compliance certifications (SOC2-Type2, HIPAA-Audit) and identity proofs (SPIFFE-X509). This issue proposes adding runtime governance attestations as a recognized category, with TRACE-v0.2 as the first defined type.

The gap

Compliance certifications prove what an organization claims about its practices. Runtime governance attestations prove what an agent actually did during execution — the session evidence, not the audit. These are complementary, not competing.

Today there is no recognized attestation type in ARD that captures:

• Which Cedar/OPA policy was in force (and its exact hash)
• Whether the agent ran inside a verifiable hardware environment (TEE measurement)
• A signed tool-call transcript that an auditor can verify offline
• A SCITT-anchored record for append-only audit history

TRACE-v0.2 covers all of these.

TRACE overview

TRACE (Trust Runtime Attestation and Compliance Evidence) is an open EAT-profile (RFC 9711) standard for AI agent governance records.

• Spec + docs: https://agentrust-io.github.io/trace-spec/
• GitHub: https://github.com/agentrust-io/trace-spec
• Developed alongside AGT (microsoft/agent-governance-toolkit, 4,200+ stars, 100+ contributors, accepted ADR: docs/adr/0032)
• Targeting AAIF / Linux Foundation for long-term stewardship
• Launching at Confidential Computing Summit June 23 2026

Proposed changes (see PR #6)

1. §5.2 — add TRACE-v0.2 to the attestation type field description
2. §5.2.1 Runtime Governance Attestations (new section) — TRACE-v0.2 spec, example entry, discovery filter
3. examples/agentrust-io-catalog.json — reference ai-catalog.json for a governed-agent registry

agentrust.io as a governed-agent federated registry

Beyond the spec change, we're proposing that agentrust.io operate as a specialized ARD federated registry indexed under:

urn:ai:agentrust.io:registry:governed-agents

This registry returns only TRACE-attested, policy-governed agents. ARD registries can route queries with trustManifest.attestations.type: ["TRACE-v0.2"] to agentrust.io via federation referrals, without embedding trust logic in the originating registry.

Connection to ARDS authors

R.V.Guha (co-author) and the AGT team both have Microsoft ties. Happy to discuss through any channel — this is a genuine architectural complement, not a competing proposal.

Feedback welcome

• Should runtime governance attestations be a separate subsection from compliance certifications? Or a note inline?
• Is there a preferred way to register new attestation types formally?
• Interested in agentrust.io contributing a reference ARD registry implementation?

[vaaraio]

Author of SEP-2828 here, the post-execution receipt work in the MCP process. The TRACE-v0.2 split is the right one. A compliance cert says what an org claims. A runtime governance attestation says what the agent actually did. Complementary, as you put it.

Two notes from having built the second half:

Make the policy-in-force hash and the enclave measurement recomputable, not just signed. A signature proves the producer asserted "Cedar policy X was live." A content-addressed record lets a third party recompute that the bytes that ran hash to X, with no trust in the producer's log. For a regulator that distinction is the point of the attestation.

For the hardware leg: an fTPM or SEV-SNP quote over the session record binds the evidence to a measured boot and a specific policy digest, so "ran inside a verifiable enclave" becomes a checkable claim rather than a label. Vaara emits this shape today (policy digest plus a hardware-rooted quote over the session record, independently re-verifiable) under SEP-2828, with implementations on PyPI and npm and conformance vectors an outside implementer recomputed this week. If a reference TRACE type would help, I can point you at the record shape and the verifier.

[litzki-systems]

Proposed Architectural Extension: Bridging Infrastructure Integrity with Runtime Governance

The current discourse distinguishing between compliance certifications and runtime governance attestations addresses the core challenge of regulatory trust. @vaaraio correctly identifies the shift from static claims to recomputable, content-addressed records as the critical pivot point for verifiable agentic systems.

I propose a fundamental architectural expansion to this framework: Deterministic Ingress Validation.

While TRACE-v0.2 and SEP-2828 effectively capture execution-time events, they rely on the assumption of a pre-established integrity environment. Within the context of the EU AI Act, DORA, and NIS2, proving policy-compliant execution remains complete only when the underlying digital infrastructure (the Layer 0 environment) meets deterministic, auditable baseline requirements at the moment of ingress.

The Sovereign Validation Protocol (SOVP) — currently under IETF-Draft (draft-litzki-sovp-03) — acts as the essential pre-execution counterpart to runtime attestations:

• Deterministic Baseline: Prior to a TRACE-attested session, SOVP provides a 265+ parameter snapshot of infrastructure integrity in 18 different cluster. This cryptographically bound, quarterly certificate (90-day validity) serves as proof that the infrastructure is hardened against the risk vectors that TRACE policies mitigate.
• Regulatory Interoperability: A runtime governance record (TRACE) paired with corresponding infrastructure validation (SOVP) closes existing compliance gaps. A governed agent achieves optimal efficacy when originating from a proven, compliant infrastructure.
• Schema Alignment: I propose extending the trustManifest.attestations array to incorporate the SOVP-v1 attestation type. This allows ARD registries to verify that an agent behaves correctly (via TRACE) while simultaneously confirming its provenance from a validated, sovereign infrastructure (via SOVP).

I am prepared to contribute a reference implementation for the SOVP-v1 type, designed for seamless integration with the ai-catalog.json federation model. A fully auditable Agentic Web demands an end-to-end compliance-to-execution pipeline:

Validated Environment (SOVP) → Governed Execution (TRACE) → Verifiable Receipt (SEP-2828).

I welcome the opportunity to discuss the integration of these attestation types into the current specification.

[imran-siddique]

@vaaraio -- both notes are exactly right.

On recomputable vs. signed: this is the core of why TRACE-v0.2 uses content-addressed records rather than just signed blobs. The digest field in the attestation entry (sha256:<hash>) is over the full EAT payload, so a third party can fetch the record from the uri, hash it independently, and confirm it matches -- no trust in the producer's log required. The signature is a second layer (producer assertion), not a substitute for the content-address. We've been sloppy about making this distinction visible in the spec text and I'll tighten that in the PR.

On the hardware leg: AGT's TEE integration (AMD SEV-SNP / Intel TDX) emits exactly the shape you describe -- the Cedar policy digest is measured into the enclave's PCRs at policy-load time, and the session record includes the SNP report over {policy_digest, session_hash}. A verifier can independently confirm that the bytes that ran hash to the policy the operator declared, with hardware as the root of trust. The quote pins it to a measured boot, not just a label.

I wasn't aware SEP-2828 had reached that point -- conformance vectors independently recomputed is significant. I'd like to cross-reference it in the TRACE-v0.2 spec section as a compatible receipt format. Would you be open to a normative "see also" or would you prefer we coordinate on a shared schema for the receipt portion so the two formats are interoperable at the record level? Either works; I want to avoid forking the receipt shape if we can align.

[imran-siddique]

@litzki-systems -- the pipeline you're describing (validated environment -> governed execution -> verifiable receipt) maps cleanly onto what we see in practice. You're right that TRACE's value is contingent on the pre-execution environment: a governance record produced by a compromised or unconfigured host is weaker evidence than one produced from a measured, policy-hardened baseline.

SOVP-v1 as a pre-execution counterpart is an interesting layer. A few questions to understand the fit:

1. Is draft-litzki-sovp-03 public on the IETF datatracker? I want to read the parameter model before commenting on schema alignment.
2. The 90-day certificate cycle -- is that a validity window on the infrastructure snapshot, or does each agent invocation reference the current certificate at call time? For session-level binding we'd need a reference that pins to a specific infrastructure state, not just "the current cert."
3. Does SOVP emit a content-addressable record (hash + uri) that can be included in the trustManifest.attestations array the same way TRACE does? If so the schema fit is already there.

That said, this issue is scoped to TRACE-v0.2 so we can move quickly on that part. If you're willing to do the legwork on the SOVP side, opening a parallel issue for SOVP-v1 would let both proposals advance without blocking each other. Happy to reference it from this issue once it's open.

[imran-siddique]

@rvguha -- would love your input here when you have a moment, particularly on the two architectural questions:

1. Should runtime governance attestations (what an agent did) be a distinct subsection from compliance certifications (what an org claims), or is a note inline under the existing attestation type field sufficient?
2. Is there a preferred process for registering new attestation type strings formally, or is the spec intentionally open on that?

For context on where this is coming from: I'm the creator of AGT (microsoft/agent-governance-toolkit), which is the runtime that produces TRACE Trust Records. I've been building this at Microsoft and am now taking it forward through agentrust.io. The TRACE spec and reference runtime are documented at https://agentrust-io.com/ -- the attestation type we're proposing here is the ARD-facing surface of that work.

The connection to ARDS feels natural: AGT governs what agents do at runtime; ARD governs how agents are discovered. A governed-agent registry that filters on trustManifest.attestations.type: ["TRACE-v0.2"] is a clean way to let discovery-time trust signal that an agent has runtime governance in place, not just a compliance cert.

[Rul1an]

Keeping attestation.type open-ended rather than enumerating named schemes is the right call, and to me it makes the consumer-interpretation side more important to get right, not less.

The distinction I would want explicit somewhere in the spec text is that a registry filter over an attestation type means "this entry links to evidence of this kind," never "this agent is safe, compliant, or governed." That second reading is a decision the consumer makes after it dereferences and verifies the evidence, not something the presence of a type in the registry can carry on its own.

For a runtime-governance attestation specifically, the minimal contract that keeps that honest is fairly small. The type names the evidence family, not a verdict. The uri points at the concrete artifact. The digest is taken over the exact artifact bytes, so a consumer can recompute it before trusting any producer signature rather than taking the entry's word for it. And the artifact itself should carry enough scope and freshness to be interpretable at all: which session, which policy bytes, which environment measurement, and what runtime surface was actually observed, since an absence only means something against a declared boundary.

That keeps TRACE, SOVP, and receipt-style records composable without ARD having to standardize anyone's internals. ARD stays the discovery layer; verification and policy reduction stay downstream with the consumer. It also keeps runtime governance cleanly distinct from compliance certification: a certification says what an organization claims about its practices, while a runtime attestation links to bounded evidence about one execution or class of executions.

[vaaraio]

The normative see-also works, and I'd rather not fork the receipt shape either; I don't think we have to.

The cleanest interop is the one you and @Rul1an are already converging on. TRACE's attestation entry names the evidence family in type, the uri dereferences to the concrete record, and the digest is over that record's exact bytes, so a consumer recomputes before trusting any producer signature. A vaara.receipt/v1 record drops into that entry as the artifact the uri points at. Neither format changes; the interop lives at the record reference, not a merged schema. That also keeps the registry honest the way Rul1an wants: the type says evidence of this kind exists here, never that the agent is governed. The verdict is whatever the consumer derives after it dereferences and recomputes.

On the bounded-artifact contract Rul1an spelled out (which session, which policy bytes, which environment measurement, what runtime surface was observed, and absence only meaning something against a declared boundary), that maps onto fields the receipt already carries, so TRACE does not have to define them:

• session and policy bytes: backLink binds the receipt to the attestation it followed by attestationDigest; the policy digest rides in the decision payload.
• environment measurement: the hardware quote over the session record, the SEV-SNP or TDX shape you described, re-verifiable against the measured boot.
• runtime surface observed: a coverage block names the boundary, the serverFingerprint (the exact capability surface, manifest:sha256(JCS(tools)) or a command hash), and a scope literal stating only calls through that boundary are in scope.
• absence against a boundary: a completeness block carries a per-boundary monotonic seq and a signed runningCount, both under the receipt signature. A dropped record is then a missing sequence number any holder detects by recomputation, with no issuer access and no external witness. That is the part that turns "we saw nothing" into checkable evidence rather than silence.

This shipped as vaara.receipt/v1, released on PyPI and npm, with the conformance vectors (coverage, completeness, the attestation binding) recomputable by an outside implementer. I can give you a stable, vendor-neutral reference for the record shape to cite in the spec section, so the see-also points at the format rather than at any one vendor's repo.

Time anchoring is a timestampAnchors array on the record for external time attestations, if TRACE wants freshness pinned independently of the producer's clock.

[Rul1an]

One useful test for the "stable, vendor-neutral reference" point may be whether the reference is neutral only in wording, or neutral at the producer/carrier layer too.

For this particular contract, I would expect a neutral reference shape to demonstrate that the same bounded evidence can be verified by digest across more than one producer or carrier, with the consumer deriving meaning from the artifact rather than from the issuer namespace. That keeps the ARD entry as a pointer to evidence, not a dependency on one receipt implementation.

There is a worked example in Rul1an/observed-effect-v0 that may be useful as a neutral comparison point: multiple carriers, one content address, and an independent reproducer/verifier. I do not think ARD needs to standardize that format either, but it gives the "see also" discussion a vendor-agnostic baseline for the record-reference contract: artifact bytes, digest, scope, freshness, and downstream consumer verification.

That seems compatible with citing implementation-specific receipt formats as examples, while avoiding the impression that one vendor receipt namespace owns the evidence envelope.

[vaaraio]

@Rul1an That is the right test, and it is the one I built for, so let me answer at the producer/carrier layer rather than in principle.

A vaara.receipt/v1 record is canonicalized with JCS (RFC 8785) before hashing, so the digest is over the artifact bytes, not over anything an issuer wraps around them. Verification is offline and issuer-free: a consumer recomputes the canonical bytes, checks the digest, and reads meaning off the artifact. There is no callback to any Vaara service, and no dependency on the vaara.receipt/v1 string beyond reading it as a version tag. The namespace is a format identifier, not an issuer you have to trust.

The cross-producer property is structural, not something I am asking you to take on trust. Because the digest is taken over the JCS-canonical bytes, any producer that emits the same record reaches the same content address, and any consumer reproduces that address without the issuer in the loop. Section 4 states the check directly: recompute the digest, with no access to the issuer.

The vendor-neutral reference I offered is now posted, so the see-also can point at a fixed handle instead of a repo file:

https://datatracker.ietf.org/doc/draft-sirkkavaara-vaara-receipt/

It is an individual Internet-Draft (Informational, no working-group standing), but the datatracker URL plus draft-sirkkavaara-vaara-receipt-NN versioning give the see-also a citable target that stays put. Section 4 (evidenceRef) and Section 6 (profiles) are the record-reference parts to cross-reference. That keeps the ARD entry a pointer to evidence: the spec cites the record-reference contract, and any conforming receipt format, including the worked example you linked, is an instance of it rather than the envelope itself.

If a specific see-also wording would help, I can propose one.

[Rul1an]

That answers the format level well, and the JCS-canonical, issuer-free recompute is the right property to state plainly in the draft.

The distinction I was reaching for sits one level up. A format being internally issuer-free shows that format is neutral; the record-reference contract being neutral is a different claim, that the same bounded evidence under the same content address can be produced and verified across more than one independent format, with the consumer deriving meaning from the artifact rather than from the namespace that emitted it. That is a property of the contract, not of any one receipt.

So the cleanest see-also may be to cite the contract itself as a short set of checkable properties (artifact bytes, a content-address digest over them, scope and freshness enough to interpret it, meaning derived downstream by the consumer), then name the conforming instances under it as examples rather than electing one as the reference: the vaara-receipt draft, the observed-effect-v0 worked example, and TRACE's own records, each an instance, none the envelope. That keeps the ARD entry a pointer to evidence under a format-agnostic contract, avoids any single receipt namespace (mine included) reading as the owner, and keeps TRACE, the draft, and the worked example as peers. The normative text could be the contract properties, with every named format cited non-normatively as an instance.

[litzki-systems]

@imran-siddique Thanks for the direct questions. Let me answer each in turn.

1. Is draft-litzki-sovp-03 public on the IETF datatracker?
   Yes. The current revision is -03, published June 9, 2026:
   https://datatracker.ietf.org/doc/draft-litzki-sovp/

2. The 90-day certificate cycle
   The validity window is part of the operational deployment layer. The current draft specifies the cryptographic verification procedure and the sovp-identity.json record structure. Session-binding and validity period mechanics are addressed in the operational sections of -03. Each agent invocation references the current certificate at call time. The record includes a created timestamp. A verifier can confirm the certificate was valid at the moment of the session.

3. Does SOVP emit a content-addressable record?
   Yes. SOVP emits a JCS-canonicalized (RFC 8785), Ed25519-signed identity record. The digest is recomputable from the artifact bytes, without issuer involvement. That maps directly onto the trustManifest.attestations pattern: type, uri, and a digest over the exact artifact bytes.
   The fit for a SOVP-v1 attestation type is structural. I am happy to open a parallel issue once you have had a chance to review the draft. That keeps both proposals moving without coupling them.

[mikeslone]

Chiming in from the implementation side. We run a conforming ARD registry for the ski/snow + travel vertical — 6 independent did:web publishers, ~40 signed entries, live and serving agent traffic — and we built exactly the property this thread is converging on, so a few data points from production:

On issuer-free recompute (@vaaraio, @Rul1an): our trust path is the same shape. Each catalog entry carries a detached JWS (RFC 7515, EdDSA) over the JCS-canonicalized (RFC 8785) entry with only trustManifest.signature removed — so the signature commits to the entry's identifier/type/url/capabilities, not an issuer-wrapped envelope. The registry resolves the key from the publisher's did:web and recomputes the canonical bytes before trusting; there's no callback to any of our services. Verification is fully offline and issuer-free, which matches the digest/uri contract you're describing for attestations.

On "a type filter links to evidence, not a safety claim" (@Rul1an): strongly agree, and it matters operationally. Our registry treats a verified entry as "the publisher's identity and bytes check out" and ranks verified above listed — but it asserts nothing about the resource being safe, compliant, or governed. That judgment stays with the consumer after it dereferences and verifies. Stating that distinction plainly in the spec text would stop registries from over-reading a type filter.

On producer/carrier neutrality (@Rul1an's test): happy to be a second, independent data point for it. Our entry-bound JWS-over-JCS verifies by digest against a published did:web key with no dependence on our namespace or any carrier — so the same bounded evidence under the same content address verifies across producers. If useful, we can publish a worked example (signed entry + did.json + a standalone zero-dependency verifier) so the cross-producer recompute can be demonstrated end-to-end against a live deployment, not just in principle.

Either way — glad to see the issuer-free, recompute-first direction; it's the right one, and it's what we're running in production today.

[Rul1an]

mikeslone's registry is a good datapoint to have land right here, because it turns the producer-neutral question from something argued into something you can actually run: can a consumer verify the bounded artifact from its bytes and digest without leaning on the issuer, and can more than one producer shape be exercised against the same contract. The offer to publish a signed entry plus a standalone verifier is what would make that concrete, so I read it as a second test vector worth taking up rather than a settled result. The cross-producer recompute becomes real once that example is public alongside vaara's and the observed-effect-v0 worked example, not before.

The part I would pin as normative is the contract rather than any single envelope. A record carries canonical bytes with a content-address digest taken over exactly those bytes, and it declares its evidence family, schema, scope, and freshness boundary so it stays interpretable on its own. The type routes a consumer to the evidence family without standing in as a safety or compliance verdict, a downstream consumer can recompute the claimed result from the bytes rather than trust the issuer's assertion, and missing coverage is stated explicitly so that "not checked" never quietly reads as "clean."

With that as the core, vaara-receipt, observed-effect-v0, TRACE's own records, and mikeslone's did:web entries all sit under it as non-normative instances, each a concrete shape to test against, none of them the envelope. It keeps ARD from blessing one carrier while still giving implementers real things to build on, and it leaves the verdict downstream with the consumer after it dereferences and recomputes. If it helps, that middle paragraph is meant to drop straight into the section you mentioned tightening.

[mikeslone]

Agreed on pinning the contract rather than the envelope — that's the right cut, and it's how our entries are already built, so I'm glad to have them sit underneath as a non-normative instance rather than a candidate carrier.

To make it concrete rather than a settled result, here's the public worked example, runnable today:

Signed entries: https://www.snowsure.ai/.well-known/ai-catalog.json — each host + entry carries an Ed25519 detached JWS (RFC 7515) over the JCS-canonicalized (RFC 8785) object minus only its own trustManifest.signature, so the signature is bound to exactly those bytes (identifier, type, url, capabilities, and trust identity). Identity is did:web, with no issuer endpoint in the trust path.

Standalone verifier: https://www.snowsure.ai/ard-verify.mjs — dependency-free, Node ≥ 18, no SnowSure deps. It takes only the published bytes, resolves the did:web Document itself, re-canonicalizes, content-addresses the entry (SHA-256 over exactly those bytes), and checks the JWS. It never calls back to us to ask "is this valid" — that's the verify-from-bytes-and-digest-without-leaning-on-the-issuer property.

curl -s https://www.snowsure.ai/ard-verify.mjs | node - https://www.snowsure.ai/.well-known/ai-catalog.json

It's deliberately producer-agnostic — the same script verifies other producers' catalogs against the same contract, e.g. node - https://lux.ski/.well-known/ai-catalog.json and node - https://afo.re/.well-known/ai-catalog.json, each resolving its own did:web key. So the cross-producer recompute you describe is something anyone can run now, and tampering with any signed field fails closed.

On the fields you'd pin normative — evidence family / schema / scope / freshness, and explicit missing-coverage — we're aligned. Our manifest already separates Listed (valid catalog) from Verified (signed + DID-resolvable), and the verify guard fails closed so "not checked" can't quietly read as "clean." Happy to map our field names onto whatever you settle as the canonical contract so the recompute stays apples-to-apples across producers (alongside vaara-receipt and the observed-effect-v0 worked example).

Treat it as a second test vector, not a verdict. Tell me the canonical-bytes / digest conventions you want the worked examples to share, and I'll match them exactly.

Full source of ard-verify.mjs (also hosted at the URL above — paste-and-run, no install)

#!/usr/bin/env node
/**
 * ard-verify.mjs — a standalone, dependency-free ARD trust verifier.
 *
 * Given the URL of an ai-catalog.json, this script recomputes each trust
 * manifest's signature FROM THE PUBLISHED BYTES and checks it against the
 * issuer's did:web public key — which it resolves itself. It never trusts the
 * issuer's assertion of validity: it re-canonicalizes the entry, content-
 * addresses it (SHA-256 over exactly those bytes), resolves the DID Document
 * independently, and verifies the Ed25519 detached JWS.
 *
 * Signing contract (must match the publisher's signer):
 *   - payload   = JCS-canonicalized (RFC 8785) object (host or entry) with only
 *                 `trustManifest.signature` removed.
 *   - signature = EdDSA/Ed25519 DETACHED JWS (RFC 7515), compact, payload omitted,
 *                 over `base64url(protectedHeader) + "." + base64url(payload)`.
 *   - identity  = `trustManifest.identity` as a did:web DID; public key resolved
 *                 from that DID Document's verificationMethod.
 *
 * Usage:
 *   node ard-verify.mjs                  # defaults to snowsure.ai
 *   node ard-verify.mjs <catalog-url>
 *
 * Requires only Node >= 18 (global fetch + node:crypto). No npm install.
 * Exit code 0 = all signed manifests verified; 1 = any failure.
 */
import crypto from 'node:crypto'

const DEFAULT_CATALOG = 'https://www.snowsure.ai/.well-known/ai-catalog.json'
const catalogUrl = process.argv[2] || DEFAULT_CATALOG

const b64url = (buf) =>
  Buffer.from(buf).toString('base64').replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '')
const fromB64url = (s) => Buffer.from(s.replace(/-/g, '+').replace(/_/g, '/'), 'base64')

// RFC 8785 JCS (sufficient for ai-catalog metadata; sorts object keys).
function jcs(value) {
  if (value === null || typeof value !== 'object') return JSON.stringify(value)
  if (Array.isArray(value)) return '[' + value.map(jcs).join(',') + ']'
  const keys = Object.keys(value).sort()
  return '{' + keys.map((k) => JSON.stringify(k) + ':' + jcs(value[k])).join(',') + '}'
}

// Canonical signed payload: the FULL object minus only trustManifest.signature.
function canonicalPayload(obj) {
  const clone = JSON.parse(JSON.stringify(obj))
  if (clone.trustManifest) delete clone.trustManifest.signature
  return jcs(clone)
}

// Resolve a did:web identifier to its DID Document URL (W3C did:web method).
function didWebToUrl(did) {
  if (!did?.startsWith('did:web:')) throw new Error(`not a did:web identity: ${did}`)
  const parts = did.slice('did:web:'.length).split(':').map(decodeURIComponent)
  const host = parts.shift()
  return parts.length
    ? `https://${host}/${parts.join('/')}/did.json`
    : `https://${host}/.well-known/did.json`
}

async function getJson(url) {
  const res = await fetch(url, { redirect: 'follow' })
  if (!res.ok) throw new Error(`${res.status} ${res.statusText} fetching ${url}`)
  return res.json()
}

// Pick the Ed25519 public key, preferring the one whose id matches the JWS kid.
function publicKeyFromDidDoc(didDoc, kid) {
  const vms = didDoc.verificationMethod ?? []
  const vm = (kid && vms.find((m) => m.id === kid)) || vms[0]
  const jwk = vm?.publicKeyJwk
  if (!jwk?.x) throw new Error('DID Document has no Ed25519 publicKeyJwk')
  return crypto.createPublicKey({ key: jwk, format: 'jwk' })
}

const didCache = new Map()
async function resolveDid(did) {
  if (!didCache.has(did)) didCache.set(did, await getJson(didWebToUrl(did)))
  return didCache.get(did)
}

async function verifyTarget(name, obj) {
  const tm = obj.trustManifest
  if (!tm?.signature) return { name, status: 'unsigned' }
  const payload = canonicalPayload(obj)
  const digest = crypto.createHash('sha256').update(Buffer.from(payload)).digest('hex')
  const [protectedB64, , sigB64] = tm.signature.split('.')
  let kid
  try { kid = JSON.parse(fromB64url(protectedB64).toString('utf8')).kid } catch {}
  const didDoc = await resolveDid(tm.identity)
  const publicKey = publicKeyFromDidDoc(didDoc, kid)
  const signingInput = Buffer.from(`${protectedB64}.${b64url(payload)}`)
  const valid = crypto.verify(null, signingInput, publicKey, fromB64url(sigB64))
  return { name, status: valid ? 'valid' : 'INVALID', identity: tm.identity, digest, didUrl: didWebToUrl(tm.identity) }
}

const catalog = await getJson(catalogUrl)
console.log(`\nard-verify — ${catalogUrl}`)
console.log(`specVersion: ${catalog.specVersion ?? '(none)'}  |  entries: ${(catalog.entries ?? []).length}\n`)

const targets = [
  ...(catalog.host?.trustManifest ? [['host', catalog.host]] : []),
  ...(catalog.entries ?? []).filter((e) => e.trustManifest).map((e) => [e.identifier ?? e.displayName, e]),
]

let failures = 0, verified = 0
for (const [name, obj] of targets) {
  try {
    const r = await verifyTarget(name, obj)
    if (r.status === 'valid') {
      verified++
      console.log(`  ✓ ${r.name}`)
      console.log(`      identity: ${r.identity}  (resolved: ${r.didUrl})`)
      console.log(`      content digest (sha256 of canonical bytes): ${r.digest}`)
    } else if (r.status === 'unsigned') {
      console.log(`  – ${r.name}  (no signature)`)
    } else {
      failures++
      console.log(`  ✗ ${r.name}  SIGNATURE INVALID`)
    }
  } catch (e) {
    failures++
    console.log(`  ✗ ${name}  error: ${e.message}`)
  }
}

console.log(`\n${verified} verified, ${failures} failed, ${targets.length} signed target(s).`)
process.exit(failures ? 1 : 0)