docs: add Signet to Tutorial 33 cross-implementation table

[willamhou]

Summary

• Add Signet to the cross-implementation interoperability table in Tutorial 33
• Signet supports both identity-binding modes: operator-signed (v1/v2) and authority-chain-referenced (v4 delegation)
• Update implementation count (four → five) and related references

Follows up on the merged Signet attestation example (#1196). Signet uses the same wire contract: JCS canonical payload, Ed25519 signature, SHA-256 parent hash.

Changes

• Add signet row to §6 implementation table (Rust / Python / TypeScript, bilateral co-signing + delegation chains)
• Add signet to both identity-binding mode descriptions
• Update "four" → "five" and "fifth" → "sixth" references

Test plan

• Verify markdown table renders correctly
• Confirm links resolve

Generated with Claude Code
via Happy

[tomjwxf]

Thanks @willamhou. The wire contract you describe (JCS canonical payload, Ed25519 signature, SHA-256 parent hash, operator-signed + authority-chain modes) maps directly onto draft-farley-acta-signed-receipts-01. Two quick questions that might save us all some fragmentation:

1. Are Signet receipts intended to be verifiable against @veritasacta/verify with no adapter? If yes, worth listing Signet as a conformant implementation in the IETF draft's appendix when -02 ships this week. Happy to handle the listing edit.

2. If there are deliberate deviations from the draft, those are exactly the kind of clarifications the IETF WG needs documented before -02 goes out. Cross-referencing them either way is useful.

Entirely fine to ship this PR as-is if Signet is its own thing. Just want to flag the convergence opportunity before we end up with two names for one spec. The five-implementation count (sb-runtime, protect-mcp, protect-mcp-adk, aps-governance-hook, plus Signet if conformant) is the procurement-credibility line I'd like the draft to cross at -02.

See also VeritasActa/agt-integration-profile for the conformance surface, which is where an additional implementer can self-certify via PR.

[willamhou]

Thanks @tomjwxf. The crypto primitives are identical (JCS RFC 8785, Ed25519, SHA-256 parent hash) — the gap is wire format only: field names and signature encoding differ (Signet uses prefixed base64; the draft uses hex).

An adapter is thin. We can build one.

Three paths, roughly in order of speed:

1. Self-certify with documented deviations via VeritasActa/agt-integration-profile now, with the field-mapping deltas listed explicitly. Gets Signet into the conversation before -02 ships.

2. Conformance adapter — a shim that translates Signet receipts to draft format for @veritasacta/verify. We'd open-source it.

3. Native alignment — if the WG is open to extension points for richer action payloads (tool identity, params hash, policy attestation), we'd align field names in a future release.

Happy to open a PR on agt-integration-profile this week. Let us know what -02's conformance bar looks like for partial implementers.

[tomjwxf]

Thanks William! The crypto shared ground you describe (JCS RFC 8785, Ed25519, SHA-256) matches exactly; the gap is wire format, which is adapter-addressable. Path 1 is the right opening move.

Instead of waiting on me to push, I pre-filled a conformance template so you have a canvas to work against: VeritasActa/agt-integration-profile#1

What's in it:

FIELD-MAPPING.md - every Signet receipt field mapped onto draft-02, populated from the public Signet source at crates/signet-core/src/. Entries with [CONFIRM] are my best guesses that need your sign-off; entries with [FILL] are things I could not infer from the public code.
DEVIATIONS.md - the four documented deltas I found (envelope shape, signature prefix, chain linkage by ID vs hash, key identifier format). All adapter-addressable; none are structural blockers.
ADAPTER.md - pseudocode sketch of a co-signer adapter, with open questions for you (live in Signet repo? out-of-tree crate? operator key-custody boundaries).

You can edit the PR directly or comment on the inferences, whichever is easier. Once you sign off on the mapping (or counter-propose where I got it wrong), I merge, update the IMPLEMENTATIONS.md row to "Self-certified", and add a Signet entry to the draft-02 Implementation Status appendix when it goes to datatracker this week.

Re Path 3 (native alignment): the draft already carries OPTIONAL fields for action_ref (cross-engine correlation anchor, direct match to your params_hash), policy_digest, attestation_mode, holder_binding, and extended decision enums. If any of those cover what you meant by "richer action payloads", aligning on them in a future Signet release is the cheapest route to native interop.

Happy to walk through field-by-field in the template PR or wherever - and keen to contribute to Signet too if anything I can do to be helpful.

Tutorial 33 independently a great addition to the tutorial regardless - thanks!

Best,
Tom

[imran-siddique]

Looks good — factual addition to the cross-implementation table. Signet's identity-binding modes (operator-signed v1/v2 and authority-chain v4) are correctly categorized.