Signed cross-org listings
The Data Exchange is a marketplace between organizations that do not share a secret. What crosses that boundary is not data and not a database row. It is a signed attestation that anyone holding the publisher's public key can verify, including with no network at all.
A listing is an attestation, not a row
When an organization publishes an offer, the platform mints a cross-org offer listing: a signed attestation that binds
- the offer's identity (publisher, product, offer, version),
- a content fingerprint, a hash of what is on offer,
- its reach,
- an attenuating scope cap, and
- a validity window.
It is signed with the publishing org's private key and is verifiable offline by anyone holding only that org's public key. Crucially, the data never crosses; only the signed listing does. The offer is discovered and its authenticity is checked before any data changes hands.
*Figure C8: what crosses the org boundary, and what does not. The data stays with the publisher (amber, held apart, no edge leaves Org A). Only the signed cross-org listing (green, sealed) crosses: a post-quantum hybrid attestation (Ed25519 + ML-DSA-65), domain-separated and scope-attenuating. The recipient (who shares no secret with the publisher) verifies it offline holding only Org A's public key. A dropped, nulled, or substituted post-quantum half, a wrong key, or any tamper is refused (red): it fails closed on any downgrade.
Table equivalent
| Element | Crosses the boundary? | State (meaning) |
|---|---|---|
| The data itself | No: held with the publisher | refusal / held-apart (amber) |
| Signed cross-org listing (Ed25519 + ML-DSA-65, domain-separated, scope-attenuating, validity window) | Yes: only the listing crosses | verified / signed (green, seal) |
| Offline verification with the publisher's public key | The recipient checks it locally, no network | verified (green) |
| Dropped/nulled/substituted PQ half, wrong key, or tamper | Rejected | deny / refuses-closed (red) |
Post-quantum hybrid, failing closed on downgrade
Each listing is signed with a hybrid construction. Ed25519 today and ML-DSA-65 for the post-quantum era, with the two signatures carried together and the post-quantum half independently pinned.
A verifier that has pinned a publisher to hybrid refuses a listing that drops, nulls, or substitutes the post-quantum half: there is no downgrade path. A cell without post-quantum support can still sign classically, and that stays a first-class mode, but a verifier pinned to hybrid will not silently accept a weaker signature in its place. This fail-closed-on-downgrade behavior is the same principle described in Signing & cryptography.
Cross-org offer listings are signed with a post-quantum hybrid construction (Ed25519 + ML-DSA-65), domain-separated and scope-attenuating, and verify offline on an air-gapped cell, trust crosses the org boundary cryptographically, with no vendor control plane. The cloud data platforms verify cross-org trust through their own control plane; this verifies it on the cell, offline, against a clock the verifier supplies.
Domain separation
The signing input is domain-separated, the signed message is prefixed with a purpose-specific separator before signing. As a result a listing signature can never be replayed as a receipt, a grant, or a package signature. A signature means exactly the one thing it was signed to mean.
The attenuating scope cap
Authority in a listing can only ever shrink relative to the ceiling the importer pinned for that publisher. It can never grow. An importer pins a maximum scope for a peer, and any listing that peer sends is checked to be a subset of that ceiling. A listing that tries to claim more scope than the pin allows is refused. (An absent ceiling is the empty, deny-closed ceiling.) This is the same "authority can only shrink" rule the platform applies to delegated grants, applied at the organization boundary.
Provenance checked twice
Every listing is verified both when it is rendered for a visitor and when it is ingested. A foreign, tampered, wrong-key, or forged listing is rejected against real cryptography, deny-closed. There is no rendered-but-unverified state and no ingest-without-verify path.
Across the deployment matrix
- Single-cell and multi-cell, a listing is verified per cell against pinned peer keys.
- Sovereign / air-gapped, verification needs no network and no coordinator; see offline verification.
- Cloud-enabled, the same listing verifies the same way, online or off.