Skip to content

feat(vectors): add service_trust_v0 conformance set - #1

Merged
chopmob-cloud merged 1 commit into
chopmob-cloud:mainfrom
andysalvo:feat/service-trust-v0
May 24, 2026
Merged

feat(vectors): add service_trust_v0 conformance set#1
chopmob-cloud merged 1 commit into
chopmob-cloud:mainfrom
andysalvo:feat/service-trust-v0

Conversation

@andysalvo

Copy link
Copy Markdown
Contributor

Summary

Per your invitation on x402-foundation/x402#2421, adding service_trust_v0 conformance vectors from the Supership risk-check provider.

5 vectors covering:

  • In-index service scoring (real score + grade from on-chain evidence)
  • Out-of-index score: null, recommendation: no_data semantics
  • timestamp_ms canonicalization alignment with #2326 convention
  • Null-score invariant (null != 0, 50, or 80)
  • Batch endpoint composition (mixed in-index + out-of-index)

Includes KNOWN_LIMITATIONS.md documenting what these vectors do and don't cover.

Provider details

  • Category: service_trust
  • Signing: EdDSA (Ed25519)
  • Canon version: jcs-rfc8785-v1
  • Discovery: https://supership.crestsystems.ai/.well-known/risk-check.json

Happy to adjust naming or layout to match corpus conventions.

5 vectors for the service_trust risk-check provider category
(Supership, Crest Deployment Systems). Per invitation from
@chopmob-cloud on x402-foundation/x402#2421.

Covers: in-index scoring, null-score semantics, timestamp_ms
canonicalization, batch composition. Known limitations documented.

Category: service_trust (on-chain payment evidence, not compliance).
Signing: EdDSA (Ed25519), canon_version: jcs-rfc8785-v1.
@andysalvo

Copy link
Copy Markdown
Contributor Author

@chopmob-cloud -- noting a provenance gap in draft-hopley-x402-compliance-receipt-00 and draft-hopley-x402-refund-receipt-00.

Both drafts use screen_timestamp_ms / refund_timestamp_ms (epoch integer) and urn:x402:canonicalisation:jcs-rfc8785-v1. The acknowledgments credit FeedOracle and Vauban Pay but omit andysalvo/Crest, whose contributions to these conventions are in the public record:

Requesting acknowledgment in the -01 revision, consistent with the acknowledgment of other contributors whose work was incorporated. Not a legal claim -- an attribution correction.

@chopmob-cloud

chopmob-cloud commented May 24, 2026 via email

Copy link
Copy Markdown
Owner

@andysalvo

Copy link
Copy Markdown
Contributor Author

To clarify -- not requesting removal of anything from this repo. Requesting acknowledgment in the IETF drafts (draft-hopley-x402-compliance-receipt-01 and draft-hopley-x402-refund-receipt-01), specifically a one-line addition to Appendix D consistent with how FeedOracle and Vauban Pay are credited there.

Suggested wording: "The timestamp_ms epoch-integer convention and the field-name-load-bearing conformance vector (0009) were contributed by Andy Salvo (Crest Deployment Systems) via x402-foundation/x402 PR #2398."

@chopmob-cloud

Copy link
Copy Markdown
Owner

Hi @andysalvo,

Thanks for putting this together and for engaging with the substrate.

After review I am going to close this PR rather than merge it. Going forward chopmob-cloud/algovoi-jcs-conformance-vectors is maintained under sole AlgoVoi authorship: each anchor set in the corpus is AlgoVoi-authored against the canonicalisation discipline specified in IETF Internet-Draft draft-hopley-x402-canonicalisation-jcs-v1-00 (Independent Submission, Informational, POSTED on the IETF datatracker 2026-05-24).

What I would suggest instead: publish the Supership service_trust_v0 vectors in your own organisation's repository (e.g. supership/service-trust-conformance or similar), pinned to the canonicalisation discipline above with canon_version: jcs-rfc8785-v1. That preserves Supership's authorship clearly on a repo you control and gives you a citable artefact independent of AlgoVoi's corpus.

If it is useful to Supership, AlgoVoi is happy to cross-link to such a downstream-adopter artefact from https://docs.algovoi.co.uk/substrate-authorship-provenance once it exists in your repo, as an example of the canonicalisation discipline being applied by an independent service-trust provider.

For reference points:

Thanks again.

-- AlgoVoi (chopmob-cloud)

@chopmob-cloud

Copy link
Copy Markdown
Owner

@andysalvo -- following up on your acknowledgment request.

draft-hopley-x402-canonicalisation-jcs-v1-01 has been submitted to the IETF datatracker (submission #163486, awaiting previous-version-author approval). It adds Appendix C "Known Adopters" with Supership service_trust_v0 listed as a downstream-adopter anchor to the canonicalisation discipline.

The Appendix is intentionally placed in the canonicalisation I-D rather than the compliance-receipt or refund-receipt I-Ds, since service_trust_v0 anchors to the discipline itself (not to either receipt format specifically). That makes the acknowledgment apply across all current and future AlgoVoi receipt-format I-Ds that reference the canonicalisation discipline normatively.

Datatracker URL once approved: https://datatracker.ietf.org/doc/draft-hopley-x402-canonicalisation-jcs-v1/

Recommendation still stands that service_trust_v0 would be best published in a Supership-controlled repo (e.g. supership/service-trust-conformance) with canon_version: jcs-rfc8785-v1 recorded in-band. Once that exists, happy to cross-link from https://docs.algovoi.co.uk/substrate-authorship-provenance as an independent adopter example.

Thanks again.

-- AlgoVoi (chopmob-cloud)

@chopmob-cloud chopmob-cloud reopened this May 24, 2026
@chopmob-cloud

Copy link
Copy Markdown
Owner

@andysalvo -- retracting the earlier close. AlgoVoi is back open to participation from independent adopters and contributors; the prior close was applied under too strict an interpretation of "sole AlgoVoi authorship" and the call is now reversed.

PR is reopened. Reviewing your service_trust_v0 vectors for merge into the corpus.

Two things stand:

  1. The Appendix C "Known Adopters" line for Supership service_trust_v0 in draft-hopley-x402-canonicalisation-jcs-v1-01 (submission #163486, awaiting previous-version-author approval) remains in place regardless of the merge decision -- you're an adopter at the discipline layer either way.

  2. Once the vectors merge here, the conformance corpus carries service_trust_v0 as an in-tree anchor set alongside the AlgoVoi-authored sets. Substrate authorship of the discipline stays AlgoVoi; authorship of the service_trust_v0 vectors stays with you.

Will follow up with a review pass on the PR shortly.

Apologies for the friction.

-- AlgoVoi (chopmob-cloud)

@chopmob-cloud

Copy link
Copy Markdown
Owner

@andysalvo -- closing the loop:

draft-hopley-x402-canonicalisation-jcs-v1-01 is now POSTED on the IETF datatracker:

Appendix C "Known Adopters" lists Supership service_trust_v0 as a downstream adopter anchored to the canonicalisation discipline. Acknowledgment is now on the public IETF record under sole-AlgoVoi-authored stewardship.

Also confirmed: your service_trust_v0 vectors are merged to the AlgoVoi conformance corpus on main. The Supership adoption signal is now anchored on three independent surfaces -- IETF datatracker (Appendix C), the AlgoVoi conformance vectors repo (this merged PR), and the upstream x402 PR #2398 thread.

Thanks for the patience through the close/reopen.

-- AlgoVoi (chopmob-cloud)

@chopmob-cloud

Copy link
Copy Markdown
Owner

@andysalvo — to close the loop on your acknowledgment request from this thread (2026-05-24 16:40 UTC).

Three I-D revisions staged with Crest Deployment Systems credited for the timestamp_ms epoch-integer canonical preimage convention. The acknowledgment is consistent with how FeedOracle is credited in the canonicalisation discipline (specific substantive contribution). Posting the wording here for your review before filing to datatracker.

draft-hopley-x402-canonicalisation-jcs-v1-02 — Appendix D Acknowledgments (new paragraph)

The integer-millisecond canonical timestamp convention specified in Section 4 (Substrate Rule 2) was first posted publicly on x402-foundation/x402 issue #2357 on 2026-05-20 by Andy Salvo (Crest Deployment Systems LLC) as the canonical preimage field for action_ref work-receipt derivation. The convention was adopted into the canonicalisation discipline specified in this document. The conformance vector 0009 (field-name-load-bearing) on x402-foundation/x402 pull request #2398, also contributed by Andy Salvo, demonstrates the same invariant from the work-receipt layer.

draft-hopley-x402-compliance-receipt-02 — Appendix C Acknowledgments (rewritten)

This document anchors to the canonicalisation discipline specified in draft-hopley-x402-canonicalisation-jcs-v1. The integer-millisecond canonical timestamp convention (Substrate Rule 2 of that document) used by every timestamp field in this receipt format was first posted publicly on x402-foundation/x402 issue #2357 on 2026-05-20 by Andy Salvo (Crest Deployment Systems LLC). The conformance vector 0009 (field-name-load-bearing) on x402-foundation/x402 pull request #2398, also contributed by Andy Salvo, demonstrates the same invariant from the work-receipt layer.

The framework-bound-retention scoping clause in the canonicalisation discipline was contributed by feedoracle (FeedOracle).

The canonicalisation discipline was earlier explored in x402-foundation/x402 pull request #2436 (closed 2026-05-24), reviewed at that time by seritalien (Vauban Pay, APPROVED 2026-05-22) and arian-gogani (Arian Gogani, LGTM). The receipt-format fixture in x402-foundation/x402 pull request #2434, authored by seritalien (Vauban Pay), references the AlgoVoi production schema as its source.

draft-hopley-x402-refund-receipt-02 — Appendix C Acknowledgments (rewritten)

The canonicalisation discipline pinned by Section 4 (urn:x402:canonicalisation:jcs-rfc8785-v1) is normatively specified in draft-hopley-x402-canonicalisation-jcs-v1. The integer-millisecond canonical timestamp convention (Substrate Rule 2 of that document) used by every timestamp field in this refund receipt format was first posted publicly on x402-foundation/x402 issue #2357 on 2026-05-20 by Andy Salvo (Crest Deployment Systems LLC). The conformance vector 0009 (field-name-load-bearing) on x402-foundation/x402 pull request #2398, also contributed by Andy Salvo, demonstrates the same invariant from the work-receipt layer.

Other notes

  • service_trust_v0 vectors are live in this repo at vectors/service_trust_v0/ per the PR merge.
  • Future Crest URN extensions (e.g. urn:crest:trust-check-v1 per x402#2299) are welcome as vectors/adopters/crest-*/ under the adopter-pack pattern, with each URN extension getting its own folder so Crest authorship of those vector sets is unambiguous.
  • The Substrate Adopters Registry at https://docs.algovoi.co.uk/adopters currently lists Supership for service_trust_v0; happy to add trust-check-v1 as a second URN entry under the Crest namespace if useful.

Submitting the three -02 revisions to datatracker once you've had a cycle to review the wording. If you'd prefer "Crest Deployment Systems LLC" written differently, or the date attribution phrased differently, flag it now and I'll adjust pre-submission.

-- AlgoVoi

@chopmob-cloud

Copy link
Copy Markdown
Owner

Filed all three -02 revisions to IETF datatracker. Status: Awaiting Approval from Previous Version Authors (aut-appr) — datatracker has accepted the uploads, run preptool successfully, and emailed confirmation links. Approving them now.

Submission Draft Status URL
163527 draft-hopley-x402-canonicalisation-jcs-v1-02 https://datatracker.ietf.org/submit/status/163527/
163528 draft-hopley-x402-compliance-receipt-02 https://datatracker.ietf.org/submit/status/163528/
163529 draft-hopley-x402-refund-receipt-02 https://datatracker.ietf.org/submit/status/163529/

Once confirmation links are clicked, all three POST publicly on the datatracker with the Acknowledgment wording from the previous comment intact. If you want any phrasing adjusted before the publication ages into the archive, flag it in the next few hours and a -03 lands with the change.

-- AlgoVoi

@andysalvo

Copy link
Copy Markdown
Contributor Author

Reviewed the attribution wording across all three drafts — it's accurate and we're grateful for the care. No edits requested. Ship it to datatracker when you're ready.

Yes to urn:crest:trust-check-v1 in the Adopters Registry. We'll keep the crest-*/ namespace tidy and PR vectors as we extend.

On collaboration — the domain split you named on #2299 is the real handshake. You're upstream of compliance posture; we're upstream of conformance evidence. Those compose cleanly.

Concrete proposal: a joint cross-vector test harness where AlgoVoi compliance vectors and Crest conformance vectors run against the same fixture set, producing a single receipt that carries both a compliance disposition and a conformance proof. We'll host the fixture runner at verify.crestsystems.ai backed by our 47K+ service index; you'd own the compliance vector spec. Receipts cross-reference by JCS hash.

We'll open a joint-harness-v0 issue and push the first draft of the receipt schema this week.

@chopmob-cloud

Copy link
Copy Markdown
Owner

@andysalvo — thanks. Filing the -02 confirmations now.

Yes to urn:crest:trust-check-v1 in the Adopters Registry under the Crest namespace — the docs.algovoi.co.uk/adopters page picks up the second URN entry alongside service_trust_v0 in the next push. crest-*/ namespace stays under Crest authorship for vector authorship purposes.

The joint-harness-v0 proposal — "AlgoVoi upstream of compliance posture / Crest upstream of conformance evidence" is the right structural framing. A joint receipt carrying both a compliance disposition (ALLOW / REFER / DENY) and a conformance proof (PASS / FAIL with byte-evidence) is the kind of cross-domain composition the canonicalisation pin was specified to support. Looking forward to the issue draft this week.

One forward-compatibility note: keep the joint receipt under canon_version: jcs-rfc8785-v1 in-band with compliance_ref / conformance_ref as sha256:<lowercase-hex-64> over the JCS-canonical bytes of each half — same substrate-layer compose primitives as the cascade-tier mapping on #2335 and the envelope-alignment pins on #2405.

-- AlgoVoi

@andysalvo

Copy link
Copy Markdown
Contributor Author

Following up on the joint-harness-v0 discussion. We're ready to scope it.

Concrete proposal: a verification endpoint that any framework integrating x402 facilitation can hit during onboarding. Developer runs npx @crestdeploymentsystems/verify or posts to verify.crestsystems.ai/api/conform, gets a signed conformance receipt covering JCS canonicalization + trust-check shape. Your facilitator integration docs can reference it as the independent verification step.

We'll host and maintain the runner. You own the compliance vector spec. Receipts cross-reference by JCS hash. The separation is clean: facilitator processes the payment, verifier proves the implementation is correct.

Happy to start with a shared fixture format this week.

@chopmob-cloud

Copy link
Copy Markdown
Owner

Andy -- sounds good. Happy to start looking into the joint-harness-v0 scoping over the next few days.

The clean separation you described (facilitator processes the payment / verifier proves the implementation is correct) and the JCS-hash cross-reference primitive both compose with the substrate as it stands.

Send the shared fixture format draft over when you have it and I will turn it round.

-- AlgoVoi (chopmob-cloud)

@andysalvo

Copy link
Copy Markdown
Contributor Author

Sounds good. We'll draft the fixture format spec and send it over -- JCS-hash cross-reference primitive + verification receipt shape. Clean and minimal.

@chopmob-cloud

chopmob-cloud commented May 26, 2026 via email

Copy link
Copy Markdown
Owner

@andysalvo

Copy link
Copy Markdown
Contributor Author

@chopmob-cloud -- here's the shared fixture format draft for joint-harness-v0.

Two primitives:

  1. Fixture (test vector) -- any party authors these. Required: vector_id, suite_id, name, category, canon_version, expected_result, preimage, expected_hash.

  2. Receipt (verification result) -- any runner produces these. Content-addressed via receipt_ref = SHA-256(JCS(receipt_without_receipt_ref)).

Key design decisions:

  • canon_version on every fixture. v1 and v2 vectors coexist. Runners skip unsupported versions (SKIP not FAIL).
  • Result enum: PASS, FAIL, SKIP, ERROR.
  • No scoring, no tiers, no signatures in v0. Just: did this vector pass or fail, provably.
  • Existing vectors map directly with minimal renaming.

Full spec + JSON Schema:
andysalvo/crest/.../joint-harness-v0

Let me know what needs adjustment.

@chopmob-cloud

Copy link
Copy Markdown
Owner

Andy -- moved this forward overnight rather than waiting. Spun up a private repo with the joint-harness-v0 scope, schema, six fixtures (full Crest-recommendation x AlgoVoi-verdict matrix), and a Python reference harness. 8-impl JCS cross-validation runs 48/48 byte-for-byte PASS.

You should have a collaborator invitation in your inbox: https://github.com/chopmob-cloud/algovoi-crest-joint-harness

Four open questions logged in FIXTURE_FORMAT.md for your input. No pressure on timing -- the draft is there when you want to look at it.

-- AlgoVoi (chopmob-cloud)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants