PlatformOperations & Walkthrough
Swarm
3-Vendor Walkthrough
One buyer composes three vendors into one refund. The artifacts each boundary produces, and the eleven checks an auditor runs over them afterwards.
Every value on this page comes out of the fixture
examples/chio-3vendor generates a committed proof corpus and verifies it. Two binaries drive it: generate-chio-proof-package prints the package or the verifier report, and generate-chio-three-vendor-fixtures rewrites the committed corpus (examples/chio-3vendor/Cargo.toml:14-20). The workflow is wf-chio-refund-001, the skill is refund-underwriting, and the identifiers below are the fixture’s own.# Print the buyer-auditor proof package JSON to stdout:
cargo run --bin generate-chio-proof-package --quiet
# Print the verifier report instead of the package:
cargo run --bin generate-chio-proof-package --quiet -- --report
# Write the full fixture corpus to a directory:
cargo run --bin generate-chio-proof-package --quiet -- --out-dir ./out
# Regenerate the committed three-vendor fixtures:
cargo run --bin generate-chio-three-vendor-fixturesThe flags are parsed positionally in Command::parse (examples/chio-3vendor/src/commands.rs:71-111), which also accepts --signed-negative-dir, --authority-input-dir, --pheromone-out-dir and two package-scoped variants of the last two.
Cast
| Kernel | Tool server | Tool | Role in the workflow |
|---|---|---|---|
did:chio:buyer-kernel | none | none | Owns the workflow root, issues the leases, signs the aggregate receipt. |
did:chio:vendor-a | vendor-a.files | read_refund_case | Reads the refund case file. Step 0. |
did:chio:vendor-b | vendor-b.kyc | verify_customer | Verifies the customer. Step 1. |
did:chio:vendor-c | vendor-c.payments | stage_refund | Stages the refund. Step 2, the destructive one. |
A fifth party never appears in the package and is the reason it exists: the auditor, who holds the trust bundle and the verification context and must reach a verdict without trusting any of the four unilaterally.
Before the workflow runs
Each of the four kernels pins the other three, and each pin carries a LadderManifestRef: a manifest id, a 64-hex digest of the governance ladder that kernel will enforce, and a validity window (chio-federation/src/trust_establishment.rs:74-82). The reference rides inside the signed handshake challenge (:240), so the governance contract is exchanged at pin time rather than argued about at invocation time. The package carries all four under peerLadderBindings:
"kernelId": "did:chio:vendor-c",
"publicKey": "31debe55d37c722768b137131caa6087080b2e0b60b94bd785d14575cfa498bc",
"ladderManifestRef": {
"manifestId": "ladder:vendor-c:refund:v1",
"sha256": "8ef4eaabdcbaeb55ab8b3c1cdfa52827e8c93d9870dc71dcabb09382dbaf9371",
"issuedAtUnixMs": 1765999940000,
"expiresAtUnixMs": 1766000060000
}Windows are two minutes wide in the fixture, and the strict verifier rechecks freshness on every bilateral invocation rather than only at handshake (chio-federation/src/bilateral_verifier/cosign.rs:118-119, 466-487). See Governance Ladder for what a manifest declares and how two of them fold.
The buyer then mints one workflow grant, cap-chio-workflow, which is the capability_id on the aggregate receipt and the workflowGrantId on every lease-scope binding. Three per-vendor leases hang off it, one per step.
What crosses one boundary
Each of the three steps produces the same four artifacts, and the destructive one produces a fifth. Taking step 0 as the shape:
- A capability lease, issued by
did:chio:buyer-kerneltodid:chio:vendor-a, narrowing the grant to one scope digest for one window. - A lease-scope binding (
chio.federation.lease-scope-binding.v1,chio-attest-buyer-core/src/claims.rs:10) tying that lease to a step index, a tool name, an action class and the canonical hash of the tool arguments. - A signed
ChioReceiptfrom the vendor kernel, recording the decision it reached. - A bilateral DSSE envelope binding both kernels to the invocation.
- A governance receipt, on step 2 only, authorising the destructive action.
The vendor receipt
A ChioReceipt is one flat record. There is no nested tool_invocation object and no workflow field: the tool server and tool name sit at the top level beside the digests, and attribution rides on actor_chain, a signed Vec<ActorRef>, rather than on a single agent id. The signing body carries 21 fields (chio-core-types/src/receipt/body.rs:113-144):
id, timestamp, capability_id, tool_server, tool_name, action, decision, receipt_kind, boundary_class, observation_outcome, tool_origin, redaction_mode, actor_chain, content_hash, policy_hash, evidence, metadata, trust_level, tenant_id, kernel_key, bbs_projection_versionThe wire record adds 3 fields the body does not sign (bbs_signature, algorithm, signature), and the id is derived from 20 of them (receipt/body.rs). Two shapes on that record catch people out. decision is a tagged enum, not a string: Decision carries #[serde(tag = "verdict")] (receipt/decision.rs:9-10), so an allow is {"verdict":"allow"}. And action is {parameters, parameter_hash}, which is where the tool arguments and their canonical digest live.
The fixture’s step-0 receipt reads "tool_server": "vendor-a.files", "tool_name": "read_refund_case", "capability_id": "lease-vendor-a-read", "receipt_kind": "mediated_decision", "trust_level": "mediated", and carries its kernel_key and signature as bare lowercase hex, 64 characters and 128 characters, with no algorithm prefix (chio-core-types/src/crypto.rs:575-583, 787-793).
The bilateral envelope
The vendor signs its own receipt. What binds the buyer to the same invocation is a DSSE envelope whose payloadType is application/vnd.in-toto+json (chio-federation/src/bilateral_dsse/types.rs:11) and whose payload is base64 of an in-toto Statement. That Statement names the receipt as its subject, prefixed chio-receipt: (:41), and declares "predicateType": "chio.bilateral-cosign-invocation.v1" (:19), which is the verifier-facing schema discriminator. The predicate itself is a BilateralPredicate (types.rs:122-162) carrying both kernel identities, the tool name, the canonical tool-args hash, the capability lease reference, both sides’ policy verdicts, and the ladder terms this class was admitted under: co_sign, consistency_model, cross_org_visibility and consistency_anchor.
Step 0’s predicate decodes to co_sign: bilateral_required, consistency_model: crdt-commutative, cross_org_visibility: federated, consistency_anchor: chio:consistency:wf-chio-refund-001:0, and a joint disposition of allow from two independently recorded verdicts, the buyer’s lease-bound and vendor A’s manifest-bound.
The crate ships a second co-signing form as well, for the case where both kernels sign the receipt directly rather than through in-toto:
/// A receipt co-signed by two kernels across a federation boundary.
///
/// * `body` -- the underlying `ChioReceipt` that both kernels agreed on.
/// * `org_a_signature` -- detached signature by the origin (Org A) kernel
/// over the canonical [`CoSigningBody`].
/// * `org_b_signature` -- detached signature by the tool-host (Org B) kernel
/// over the same canonical body.
///
/// The existing receipt's built-in `signature` and `kernel_key` fields are
/// unchanged: a classic verifier can still check the receipt in isolation,
/// while a federation-aware verifier additionally checks both detached
/// signatures via [`DualSignedReceipt::verify`].
#[derive(Debug, Clone, Serialize, Deserialize)]
#[serde(rename_all = "camelCase", deny_unknown_fields)]
pub struct DualSignedReceipt {
pub schema: String,
pub body: ChioReceipt,
pub org_a_kernel_id: String,
pub org_b_kernel_id: String,
pub org_a_signature: Signature,
pub org_b_signature: Signature,
}Both detached signatures cover the canonical bytes of a CoSigningBody, not the receipt JSON itself, so the two kernels sign exactly the bytes they each saw:
/// Canonical body that the local and remote kernels both sign. The bytes of
/// this structure (in canonical JSON) are the signed message for
/// [`DualSignedReceipt::org_a_signature`] and
/// [`DualSignedReceipt::org_b_signature`].
#[derive(Debug, Clone, PartialEq, Eq, Serialize, Deserialize)]
#[serde(rename_all = "camelCase", deny_unknown_fields)]
pub struct CoSigningBody {
pub schema: String,
/// Canonical JSON encoding of the underlying `ChioReceipt`, as a UTF-8
/// string. The string form (rather than a nested object) keeps signing
/// stable even if the receipt schema grows new `skip_serializing_if`
/// fields later: both kernels sign exactly the bytes they saw.
pub receipt_canonical_json: String,
pub org_a_kernel_id: String,
pub org_b_kernel_id: String,
}The destructive step
Step 2 stages a refund, so its lease is issued at the narrowest of the three action classes. CapabilityLeaseActionClass has exactly three values, scoped_observation, delegated_action and narrow_destructive (chio-governance/src/lease.rs:9-15); steps 0 and 1 take delegated_action and step 2 takes narrow_destructive.
pub struct CapabilityLeaseArtifact {
pub schema: String,
pub lease_id: String,
pub issuer: String,
pub subject: String,
pub scope_digest: String,
pub action_class: CapabilityLeaseActionClass,
pub issued_at_unix_ms: u64,
pub expires_at_unix_ms: u64,
}The lease body validates its own scopeDigest as 64 hex characters and requires a non-empty window (lease.rs:31-50). It travels inside a SignedCapabilityLease, which wraps the body with a signerKey and a signature (lease.rs:53).
A lease says the buyer may ask. A governance receipt says the buyer did authorise this exact step. Its caseKind enum has one variant, destructive_authorization (chio-governance/src/authorization.rs:9-13), and it names the lease, the workflow, and the hash of the step it covers:
pub struct GovernanceReceiptArtifact {
pub schema: String,
pub receipt_id: String,
pub authorizing_kernel: String,
pub case_kind: GovernanceReceiptCaseKind,
pub authorized_lease_id: String,
pub workflow_id: String,
pub step_sha256: String,
pub issued_at_unix_ms: u64,
pub expires_at_unix_ms: u64,
}In the fixture it is issued by a distinct kernel, did:chio:buyer-governance, rather than by the buyer kernel that issued the lease, and its window is forty seconds inside the lease’s sixty:
"governanceReceipts": [
{
"body": {
"schema": "chio.governance-receipt.v1",
"receiptId": "gov-refund-stage-authorization",
"authorizingKernel": "did:chio:buyer-governance",
"caseKind": "destructive_authorization",
"authorizedLeaseId": "lease-vendor-c-refund",
"workflowId": "wf-chio-refund-001",
"stepSha256": "31118bb62ec8d467670bfc3b8fc6ad88e6946380bdfb51486a0f2daa4781b3f9",
"issuedAtUnixMs": 1765999980000,
"expiresAtUnixMs": 1766000020000
},
"signerKey": "0b513ad9b4924015ca0902ed079044d3ac5dbec2306f06948c10da8eb6e39f2d",
"signature": "0e871e80b21e7dd57c46698168bc2ea993ce25130dff5cd0a90c7bb38cdc3cfa2e8ffcede775cdaf7f71db33544d54e225b5f0bd99a88634dcd6745927ea6809"
}
],The aggregate receipt
The buyer builds one chio.workflow-receipt.v1 over the three steps and signs it. Each StepRecord has fourteen fields, five of which are the cross-boundary bindings this walkthrough is about:
/// Record of a single step's execution within a workflow.
#[derive(Debug, Clone, Serialize, Deserialize)]
pub struct StepRecord {
/// Step index in the manifest.
pub step_index: usize,
/// Tool server.
pub server_id: String,
/// Tool name.
pub tool_name: String,
/// Whether this step was allowed.
pub allowed: bool,
/// Receipt ID for the underlying tool call (if it ran).
#[serde(default, skip_serializing_if = "Option::is_none")]
pub tool_receipt_id: Option<String>,
/// Step outcome.
pub outcome: StepOutcome,
/// Step duration in milliseconds.
pub duration_ms: u64,
/// Cost attributed to this step.
#[serde(default, skip_serializing_if = "Option::is_none")]
pub cost: Option<MonetaryAmount>,
/// SHA-256 hash of the step's output.
#[serde(default, skip_serializing_if = "Option::is_none")]
pub output_hash: Option<String>,
/// SHA-256 of the bilateral DSSE envelope for this step.
#[serde(default, skip_serializing_if = "Option::is_none")]
pub bilateral_dsse_sha256: Option<String>,
/// Governance receipt that authorizes this step when destructive.
#[serde(default, skip_serializing_if = "Option::is_none")]
pub governance_receipt_id: Option<String>,
/// SHA-256 of the preceding workflow or tool receipt.
#[serde(default, skip_serializing_if = "Option::is_none")]
pub parent_receipt_sha256: Option<String>,
/// Consistency anchor binding the step to a hash chain or external root.
#[serde(default, skip_serializing_if = "Option::is_none")]
pub consistency_anchor: Option<String>,
/// Whether this step performs a destructive action.
#[serde(default, skip_serializing_if = "Option::is_none")]
pub destructive: Option<bool>,
}Note what is not there. There is no lease_id: a step points at its governance receipt, and the lease is reached through that receipt’s authorizedLeaseId or through the lease-scope binding’s stepIndex. There is no settlement amount and no KYC tier; cost is the only monetary field, and it is a MonetaryAmount. And consistency_anchor is an opaque Option<String>, not a structured kind-and-value object.
"steps": [
{
"step_index": 0,
"server_id": "vendor-a.files",
"tool_name": "read_refund_case",
"allowed": true,
"tool_receipt_id": "ea1f74990eaef54beaac9d7af04893a2320390b773b556fbd310fa9246ed3b3d",
"outcome": "success",
"duration_ms": 12,
"cost": {
"units": 100,
"currency": "USD"
},
"output_hash": "6c7596557f061fb92c19195dd7184598e026bb5212185a1231f6bcefc6fee009",
"bilateral_dsse_sha256": "3e7ac510ae43d4668966534d81c7592d2c7bb62d10e7938e1bb7c9e477c49077",
"consistency_anchor": "chio:consistency:wf-chio-refund-001:0"
},
{
"step_index": 1,
"server_id": "vendor-b.kyc",
"tool_name": "verify_customer",
"allowed": true,
"tool_receipt_id": "cb31b1ffad667916f951842002f66c0357556ebe2dc58bb5664e920611516cfc",
"outcome": "success",
"duration_ms": 18,
"cost": {
"units": 200,
"currency": "USD"
},
"output_hash": "20d1a73014db4806b985f39c23c7391e269b66a7bfcbf13f014636c13146dd0f",
"bilateral_dsse_sha256": "bd3b5f81c03b8ba749a2a4b4af630787cf0a9716e464ad6bf136a3ac6ca8bee5",
"parent_receipt_sha256": "31b6b050e93f0bf36f3232d4f34b72222a879a3196f2c10d7d1607cbc3a0e5bb",
"consistency_anchor": "chio:consistency:wf-chio-refund-001:1"
},
{
"step_index": 2,
"server_id": "vendor-c.payments",
"tool_name": "stage_refund",
"allowed": true,
"tool_receipt_id": "d342a59dd9d25aa977b098b3f847b89d01ea11501f9ba3c99a4348156fba2e3f",
"outcome": "success",
"duration_ms": 12,
"cost": {
"units": 250,
"currency": "USD"
},
"output_hash": "c9abf68ae26e738826dabd29da7f6c623608221b253a70e6be1ec05bd9803987",
"bilateral_dsse_sha256": "c03843a008c00646de37e4006857b35fb0347827d1b8f4186ee87e0c0ecb97b6",
"governance_receipt_id": "gov-refund-stage-authorization",
"parent_receipt_sha256": "9cbe4438bc3128da868d1f207a74f7f112fb45c5f3565a635bc98886ad017121",
"consistency_anchor": "chio:consistency:wf-chio-refund-001:2",
"destructive": true
}
],The anchor values are chio:consistency:wf-chio-refund-001:{index}, and the package validator recomputes that string per step and refuses a mismatch (chio-attest-loopback/src/runtime_validation.rs:236-242). The three cost values are 100, 200 and 250 against a total_cost of 550. Those are minor units, not dollars:
/// A monetary amount with currency denomination.
///
/// Uses minor-unit integers to avoid floating-point precision issues.
/// For USD, 1 dollar = 100 units (cents). For JPY, 1 yen = 1 unit.
#[derive(Debug, Clone, PartialEq, Eq, Serialize, Deserialize)]
#[serde(deny_unknown_fields)]
pub struct MonetaryAmount {
/// Amount in the currency's smallest unit (e.g. cents for USD).
pub units: u64,
/// ISO 4217 currency code. Examples: "USD", "EUR", "JPY".
pub currency: String,
}So the run cost $5.50, in three steps of $1.00, $2.00 and $2.50. Reading units as a whole-currency amount is a hundredfold error in USD and a no-op in JPY, which is exactly the confusion the minor-unit convention exists to prevent.
The aggregate is signed by the buyer kernel and then co-signed by all three vendors: vendor_signatures carries three WorkflowVendorSignature entries, one per vendor, each a detached signature over the canonical body (chio-workflow/src/receipt.rs:49-51, 75-82). The vendors are not merely quoted in the buyer’s record; they endorse it.
What the chain actually hashes
Two digests link each step to something else, and they link to different things. bilateral_dsse_sha256 is the canonical SHA-256 of that step’s own DSSE envelope. parent_receipt_sha256 is the canonical SHA-256 of the previous StepRecord, not of the previous envelope and not of the previous receipt.
previous_step_sha256 = Some(canonical_sha256(&step)?);The generator sets it that way (package.rs:231, consumed at :217), the package validator enforces it with the message runtime step N parent hash does not match previous step (runtime_validation.rs:230-235), and the buyer-side report recomputes it independently (chio-attest-buyer-core/src/report.rs:695, 838). It is checkable from the committed fixture with nothing but jq and sha256sum, because RFC 8785 canonical JSON over these values is what jq -cS emits:
$ F=examples/chio-3vendor/fixtures/buyer-auditor-proof-package.json
$ for i in 0 1; do
$ printf 'sha256(canonical steps[%s]) %s\n' "$i" \
"$(jq -cSj ".workflowReceipt.steps[$i]" "$F" | sha256sum | cut -d' ' -f1)"
$ done
$ jq -r '.workflowReceipt.steps[1,2]
$ | "steps[\(.step_index)].parent_receipt_sha256 \(.parent_receipt_sha256)"' "$F"sha256(canonical steps[0]) 31b6b050e93f0bf36f3232d4f34b72222a879a3196f2c10d7d1607cbc3a0e5bb sha256(canonical steps[1]) 9cbe4438bc3128da868d1f207a74f7f112fb45c5f3565a635bc98886ad017121 steps[1].parent_receipt_sha256 31b6b050e93f0bf36f3232d4f34b72222a879a3196f2c10d7d1607cbc3a0e5bb steps[2].parent_receipt_sha256 9cbe4438bc3128da868d1f207a74f7f112fb45c5f3565a635bc98886ad017121
Hashing the step record rather than the envelope is what makes the chain cover the buyer’s own bookkeeping. A step’s cost, outcome, duration and governance-receipt pointer are all inside the hash the next step commits to, so reordering, re-pricing or silently dropping a governance receipt breaks the chain at the next link.
crates/platform/chio-workflow/src/receipt.rs:126-165crates/trust/chio-attest-loopback/src/runtime_validation.rs:223-242at fe56570Binding the pairs into one workflow
Three pairwise relationships do not by themselves say that one workflow happened. A chio.attest.workflow-intersection.v1 (chio-attest-buyer-core/src/claims.rs:9) is the record that says so. It names the workflow, the grant, one pairwise intersection reference per peer with that peer’s ladder manifest reference, the vendor signers a verifier should require, and the digest of the aggregate workflow receipt’s signing body (chio-attest-loopback/src/package.rs:304). Its step bindings map each step index to the action class the peer admitted:
"stepClassBindings": [
{
"stepIndex": 0,
"toolName": "read_refund_case",
"actionClassId": "read_refund_case",
"peerKernelId": "did:chio:vendor-a"
},
{
"stepIndex": 1,
"toolName": "verify_customer",
"actionClassId": "verify_customer",
"peerKernelId": "did:chio:vendor-b"
},
{
"stepIndex": 2,
"toolName": "stage_refund",
"actionClassId": "stage_refund",
"peerKernelId": "did:chio:vendor-c"
}
],Its aggregateWorkflowReceiptSha256 is 0a29c62e2ec376a12d147bd3f9ffdd332a19792ebd15d035ae5684bc894e4710, the same value the selective-disclosure proof carries as its subject_sha256_hex. Both are the canonical SHA-256 of the same WorkflowReceiptBody, so the intersection and the disclosure proof are provably about one workflow receipt, and the report re-derives the digest rather than trusting it (chio-attest-buyer-core/src/report.rs:515).
The intersection record is portable evidence, not a trust root. A verifier accepts it only when its own trust bundle lists the intersection id and digest, which the shipped bundle does under workflowIntersections.
The audit
The verifier takes the package, a trust bundle and a verification context, and returns a chio.attest.verifier-report.v1 (chio-attest-buyer-core/src/report.rs:31) with a verdict and one row per check. Eleven checks run, in this order:
$ cargo run -p chio-three-vendor-example --bin generate-chio-proof-package -- --report \
| jq -r '"accepted: \(.accepted) revocationEpochHeight: \(.revocationEpochHeight)",
$ (.checks[] | "\(if .passed then "pass" else "FAIL" end) \(.code)")'accepted: true revocationEpochHeight: 64 pass workflow.kernel_signature pass trust.package_hints pass workflow.intersection pass workflow.vendor_cosignatures pass workflow.step_links pass governance.lease_scope_bindings pass governance.capability_leases pass governance.receipts pass federation.strict_bilateral_invocations pass trust.bbs_issuer pass bbs.selective_disclosure
The report is the durable output, not the log line. It records the digests of all three inputs so a third party can tell which package was verified against which bundle:
{
"schema": "chio.attest.verifier-report.v1",
"packageSha256": "abdec15d672dce556c2879f05b6fd33320a7ed8ab96b08233a9f5a6154da378b",
"trustBundleSha256": "d87f8360b9350a613a7321ee3486032fabd83b9ecf10f1832af444268cda9bdb",
"contextSha256": "4758a93f2dbc16256105ce6d47a4efdd39d477733dcb2a5e80075a3e1aaddcce",
"revocationEpochHeight": 64,
"accepted": true,
"checks": [
{
"code": "workflow.kernel_signature",
"name": "workflow-kernel-signature",
"passed": true
},
{
"code": "trust.package_hints",
"name": "package-trust-hints",
"passed": true
},
{
"code": "workflow.intersection",
"name": "workflow-intersection",
"passed": true
},
{
"code": "workflow.vendor_cosignatures",
"name": "workflow-vendor-cosignatures",
"passed": true
},
{
"code": "workflow.step_links",
"name": "workflow-step-links",
"passed": true
},
{
"code": "governance.lease_scope_bindings",
"name": "lease-scope-bindings",
"passed": true
},
{
"code": "governance.capability_leases",
"name": "capability-leases",
"passed": true
},
{
"code": "governance.receipts",
"name": "governance-receipts",
"passed": true
},
{
"code": "federation.strict_bilateral_invocations",
"name": "strict-bilateral-invocations",
"passed": true
},
{
"code": "trust.bbs_issuer",
"name": "trusted-bbs-issuer",
"passed": true
},
{
"code": "bbs.selective_disclosure",
"name": "bbs-selective-disclosure",
"passed": true
}
]
}Reading the check list as a procedure: the first row establishes that the buyer signed the aggregate; the second that the package’s trust hints match the bundle; the third and fourth that the workflow intersection is trusted and that every required vendor actually co-signed; the fifth that the step chain links as above. Rows six to eight walk the governance artifacts, lease-scope bindings then leases then governance receipts. The ninth verifies the bilateral DSSE envelopes under the strict profile. The last two check that the BBS issuer is trusted and that the selective-disclosure proof verifies.
What the auditor is shown
The package ends with a selective-disclosure proof over the aggregate workflow receipt. It opens four of the projection’s fourteen messages, indices 4, 8, 9 and 10, which are id, session_id, skill_id and skill_version(chio-selective-disclosure/src/lib.rs:362-464). Everything else stays committed and unopened, including the steps message, which is where the per-step costs and the destructive flag live.
{
"schema": "chio.attest.selective-disclosure-proof.v1",
"projection_version": "chio.bbs-projection.workflow.v1",
"subject_sha256_hex": "0a29c62e2ec376a12d147bd3f9ffdd332a19792ebd15d035ae5684bc894e4710",
"ciphersuite": "BBS_BLS12381G1_XMD:SHA-256_SSWU_RO_",
"issuer_fingerprint": "70113a55c73186df1b5812a3c421f1ee8061acfda7fb4009f5a5432102ddaca3",
"issuer_public_key_hex": "ac96b29b82fd2aafa60ec4a4cf720073e1e8fe232f24cb0125b3e89397176e66c170794a6cec5b6440b00fdf88d5851b0d08d0a729499b56940e76cc1ae33e838602a52a3667f24ca9c0aeb1baeaccd972cc46eeb2d1f3755c6ed950c998c7d5",
"message_count": 14,
"disclosed_indices": [
4,
8,
9,
10
],
"disclosed": [
{
"index": 4,
"field": "id",
"encoding": "S",
"bytes_hex": "77662d6368696f2d726566756e642d303031"
},
{
"index": 8,
"field": "session_id",
"encoding": "Opt<S>",
"bytes_hex": "736573732d6368696f2d726566756e64"
},
{
"index": 9,
"field": "skill_id",
"encoding": "S",
"bytes_hex": "726566756e642d756e64657277726974696e67"
},
{
"index": 10,
"field": "skill_version",
"encoding": "S",
"bytes_hex": "302e312e30"
}
],
"proof_nonce_hex": "34373538613933663264626331363235363130356365366434376134656664643339643437373733336463623261356538303037356133653161616464636365",
"proof_bytes_hex": "816101387daa8084da8e7c7f08bf66252271a3f771419726d913b499ca40edea1c246d86fd676ac57697269fc9c970deadd8a9d51786475a7d82a1e8f3b4d146b24f4d17f8039fceab57aef8a4c2f18d8f81e267edc2b14adff08264aaa71a2a8e990cb3a4098e8701bf49603ba6018aaf629e55d0022446b0186d89519772c4aeaa52662c09f28e810fddd4fc09f27822624f5f95b2f775400c62fbdacb469aff1c06de7e5658cd9e453c3bbee96622643fe3357bf0fca3eaa88188885e2438565f1022b61bfa299ca0a96bddfa8c214497e492108a85f7377aab2bf03e4e7b95cbdc45526adcfa06cee2b5efbe5e174ffb690bbeade070fbf91419d4be5a8699079f26963253255adf990f5b3033ad3e58f5d34cb70f60746a554f81c5e40293c9c46c7c868f76bcf7ae824d9c1f7a291ff2ac6542e9304113eeda01f34c97bdf45055b55e1e599a31f80ac959ef2536f29ae76b32fdb81c066a33e009efdef7a56d67c8c985f5ae5092980f40f3a369d12e2f816b138cce34ca8f2c1e5c6f2a9cb3376e9998720967e51606e41051289556a7a251c915b0ad79b9f52713e97a5435f723b798964553bead8888bac602e1c3eed480589b3738c003e015e9822d935ab30e529996ab3b7f002252ae3267aac46f1e78d560b6e772fe4e1a60f866da43e6353750195eadcc6db1d173035d7d39f00ba7ba095663e106ebb82aaf5e7d1ef14f784f76895ac3697a82b9f811f5e9c9e31473cf73e61b7c058bb6f0df6d42d1334a53bdf93c8099fe5f63030a91196a429f99b1b5bed6d8e965b01b8aaf1ccfec40755d935e5a93243b9c76"
}This is a reveal set, not a predicate proof. The auditor learns that the buyer’s BBS issuer signed a fourteen-message vector whose subject digest matches the aggregate receipt, and reads four of those messages back. It does not learn a hidden comparison over the refund amount, and the package cannot claim to:
pub struct ChioProofClaims {
pub bbs_reveal_set: bool,
pub hidden_range_predicates: bool,
pub vc_data_integrity_bbs: bool,
pub zkvm: bool,
}validate_claims refuses a package whose bbsRevealSet is false and refuses one whose hiddenRangePredicates, vcDataIntegrityBbs or zkvm is true (chio-attest-buyer-core/src/proof_package.rs:52-71). The fixture’s block is {bbsRevealSet: true, hiddenRangePredicates: false, vcDataIntegrityBbs: false, zkvm: false}. See Selective Disclosure for the projection table and the manifest that constrains which slots a proof may open.
What the fixture demonstrates
- Attenuation across organisations. One workflow grant becomes three leases, each scoped to one subject, one scope digest and one sixty-second window, and the destructive one takes a strictly narrower action class than the other two.
- Ladder pinning that keeps biting. Every kernel’s governance contract is pinned by digest at handshake and rechecked for freshness on each bilateral invocation, so a lapsed ladder stops work rather than being noticed at the next handshake.
- Joint authorship at two layers. Each boundary produces a DSSE envelope binding both kernels, and the aggregate carries three detached vendor signatures over the same canonical body.
- A chain over the buyer’s own record. Each step commits to the canonical hash of the previous step record, so cost, outcome and governance pointers are inside the chain rather than beside it.
- Separation of authorising and issuing. The lease comes from
did:chio:buyer-kernel; the destructive authorisation comes fromdid:chio:buyer-governance, inside a shorter window, naming the step hash it covers. - A verdict a third party can reach. Eleven checks over one package, a trust bundle and a context, with all three digests recorded in the report.