Standards and interoperability

Audience: architects and developers · Read route: apply · Reflects specification v0.1 · Landscape reviewed August 2026

SDX, the Selective Disclosure Exchange Protocol, is a data-plane protocol: it defines how encrypted data moves directly between organisations and how each exchange becomes an independently verifiable record. This page maps it against the standards and frameworks that European data sharing already runs on: what each one is, where SDX touches it, what SDX adds, and, where applicable, what SDX deliberately does not adopt. Overlap with existing work is stated as overlap.

Three status words carry precise meaning throughout this page:

• Specified: the mechanism is written into the v0.1 specification and an implementer can build against it today. Where a specified mechanism has not yet been demonstrated against another party's implementation, the entry says so.
• Mapped: the alignment with another framework is designed and documented here, but not yet demonstrated end to end against that framework's reference implementation. A mapped claim is a design intention, not an achievement.
• Not adopted: SDX deliberately does not implement the mechanism, and the entry explains why and what it uses instead.

The landscape at a glance

Where SDX itself has intermediaries

A fair question to ask of any protocol that talks about direct exchange is where its own intermediaries sit. SDX has two, and neither needs to be trusted for integrity or confidentiality.

The overlay routing fabric admits records into topics, answers lookups and exposes a live tail. Any operator can run one, including the organisation itself; the fabric cannot read envelopes and cannot alter a record without that alteration being detectable, because integrity comes from the record's own signatures and its anchor. Switching operators changes nothing another party can verify.

The public audit layer is operated infrastructure as well: dedicated operators maintain its ordering. What the design removes is not the existence of operators but their discretionary power. No operator can alter or forge an anchored record undetectably, and no operator's cooperation is needed to verify one. The naming and anchoring mechanics of the settlement layer are under technical review as provisional item PROV-1 in the specification; this page inherits that caveat wherever it mentions anchoring.

Foundations SDX builds on

W3C Decentralized Identifiers and Verifiable Credentials

What they are. The W3C standards for globally unique, verifiable identifiers and machine-readable attestations. They are the identity foundation named by the DSSC Blueprint, the EUDI wallet architecture and most European data-space initiatives.

Where SDX touches them. The specification recommends (SHOULD-level) binding accounts and mandates to DIDs and Verifiable Credentials: a directory attestation can be expressed as a credential, and account identities are public-key bound in a way that maps directly onto DID documents.

What SDX adds. The runtime pins the actor's public key at mandate-grant time, so verification is local, with no resolution step on the hot path. A credential establishes who someone is; the anchored record accumulates what they did under it.

What SDX does not adopt. SDX does not mandate one DID method, and organisational flows work without any credential at all.

Status. Specified as an optional binding. See Identity and delegation.

SD-JWT and OpenID4VP / OpenID4VCI

What they are. The credential format and presentation protocols used by the EU digital identity wallet: selectively disclosable JWTs, issued and presented through OpenID flows.

Where SDX touches them. Mandates may optionally be issued as SD-JWT credentials and presented over OpenID4VP, so a mandate that lives in an EU wallet can authorise an SDX action.

What SDX adds. The grant and every use of the mandate are recorded on the audit layer, which gives wallet-issued authority an independently verifiable usage history.

What SDX does not adopt. Wallet presentation is not required for machine-to-machine flows; the credential path is optional by design.

Status. Specified as an optional binding; presentation against a production wallet has not yet been demonstrated, and diagrams on this site draw the wallet binding as planned rather than live.

eIDAS 2.0

What it is. The EU regulation on digital identity, Regulation (EU) 2024/1183 amending 910/2014, establishing digital identity wallets and a catalogue of trust services. New in 2.0: electronic attestations of attributes, and electronic ledgers as a recognised trust service for tamper-evident records.

Where SDX touches it. The SDX mandate mechanism (scoped, time-bounded, revocable, with grant and revocation recorded) is specified in v0.1, and its semantics are designed to line up with eIDAS mandate concepts. Payload signatures use ES256 on P-256, the signature scheme the wallet ecosystem uses; the key hierarchy covers both curves in use. The public audit layer sits in the category the electronic-ledger trust service describes: a tamper-evident, independently verifiable record.

What SDX adds. A concrete, open, rebuildable mechanism in that category, with the ETSI standardisation of electronic ledgers still maturing alongside it.

What SDX does not adopt. SDX does not claim qualified-trust-service status. That is a certification a deployment may pursue, not a property of the protocol.

Status. Mandate mechanism specified; the eIDAS alignment and the trust-service framing are mapped.

RFC 8949 deterministic CBOR encoding

What it is. The IETF standard for CBOR, whose section 4.2 defines deterministic encoding.

Where SDX touches it. Every envelope is deterministically encoded, so two independent implementations produce byte-identical output for the same record, and therefore identical commitments and identical proofs.

What SDX adds. Determinism is the property that lets a verifier reproduce a commitment from the payload independently; replay and drift detection depend on it.

Status. Specified as this protocol's own deterministic profile. It adopts RFC 8949's bytewise ordering rules and is deliberately narrower: integer inputs beyond the 53-bit safe range are refused, and decoding is tolerant rather than strict. The cbor-det-v1 test-vector suite pins the exact bytes.

C2PA

What it is. The Coalition for Content Provenance and Authenticity standard for binding provenance metadata to media, now also moving onto a formal standardisation track.

Where SDX touches it. The content authenticity protocol is designed so that its provenance claims can align with C2PA claim semantics, and anchoring lets authenticity survive the places where embedded metadata is routinely stripped.

What SDX does not adopt. The protocol explicitly does not claim certified C2PA conformance; its own specification states that rule, and version mapping is held as a provisional item there.

Status. Mapped.

Data-space frameworks

DSSC Blueprint v3.0

What it is. The Data Spaces Support Centre's reference architecture for European data spaces: standardised building blocks for identity and attestation, trust frameworks, and access and usage policies, resting on W3C Verifiable Credentials and related foundational standards.

Where SDX touches it. The Blueprint standardises the control plane, and describes the data plane as domain-specific, without prescribing a single transfer protocol. SDX is a data-plane protocol: it defines how the data itself moves and how the exchange becomes verifiable. It does not compete with the control plane; it is a candidate for the data-plane layer, where each data space's governance selects its protocols and where eDelivery and the Asset Administration Shell API are established choices today.

What SDX adds. The Blueprint's traceability building block asks for provenance and observability. An anchored record offers a different guarantee than logging: a log's integrity rests on the party keeping it, while an anchored record can be verified by a third party without trusting either endpoint or any operator.

What SDX does not adopt. Catalogues, policy negotiation and membership governance stay with the Blueprint's building blocks. A data space that runs those can use SDX underneath them unchanged.

Status. Mapped. Demonstrating the pairing against a reference control plane is future work.

Dataspace Protocol (DSP) 2025-1

What it is. The Eclipse-governed protocol for control-plane exchanges between data-space participants: catalogue, contract negotiation and transfer processes, with a conformance test kit, on a path toward ISO standardisation. In practice it is exercised through connectors such as the Eclipse Dataspace Components (EDC).

Where SDX touches it. A DSP transfer process names the transfer protocol the parties will use, and SDX is designed to be nameable there: negotiation stays under DSP, the transfer runs over SDX, and the negotiated exchange gains an anchored, independently verifiable record.

What SDX adds. The record of what the negotiated transfer did, verifiable after the fact by parties that were not on either end of it.

What SDX does not adopt. Contract negotiation and catalogue semantics; SDX does not replicate them.

Status. Mapped; no bridge implementation exists yet. The artefact that would settle this claim is a connector shim that declares this protocol as a transfer format on its offers and passes the protocol's conformance test kit for the negotiation flow. That test kit exercises the control plane only; demonstrating the data transfer itself is separate work, since the Dataspace Protocol leaves data-plane interfaces out of scope.

Gaia-X Trust Framework

What it is. Gaia-X's compliance machinery: participants present verifiable credentials about who they are and how they operate, validated by a network of clearing-house operators running a common compliance service, producing a compliance credential other parties can check. Loire remains the compliance baseline; the Danube platform, released November 2025, is being operationalised alongside it.

Where SDX touches it. SDX participant signatures use ES256, which is compatible with the credential formats the framework issues, and a Gaia-X compliance credential can serve as admission evidence when joining an SDX topic: the directory verifies the credential, then attests the binding on the audit layer.

What SDX adds. A compliance credential and an anchored record answer different questions and compose cleanly: the credential establishes the participant, the record accumulates the exchanges made under it.

What SDX does not adopt. SDX does not define a compliance scheme of its own; proving organisational compliance is Gaia-X's job.

Status. Mapped; obtaining and verifying a live compliance credential for an SDX reference deployment has not yet been done.

iSHARE

What it is. The Dutch-origin, EU-oriented trust framework for business-to-business data sharing: eIDAS-rooted certificates, an OAuth-based flow that lets parties who have never met transact, and delegation evidence from authorisation registries.

Where SDX touches it. iSHARE party identification can feed SDX directory attestations, and iSHARE delegation evidence expresses the same idea as an SDX mandate: scoped, delegated, revocable authority. A deployment inside an iSHARE scheme can translate delegation evidence into mandates at the boundary.

What SDX adds. In SDX the delegation, its use and its revocation are all recorded actions, so the authority trail itself is verifiable afterwards.

What SDX does not adopt. The scheme-owner and satellite governance model; SDX leaves participant governance to the schemes that have it.

Status. Mapped.

Federatief Datastelsel and FSC (Netherlands)

What they are. The Dutch government's federated data system, whose technical functions follow the DSSC building blocks, with FSC (Federated Service Connectivity) as its designated connectivity standard and Logboek Dataverwerkingen, a processing-log standard, still in development.

Where SDX touches them. An SDX endpoint can be published as an FSC service; FSC contracts and delegation can govern who may connect, with SDX carrying and anchoring the exchange itself.

What SDX adds. FSC's core leaves request logging to a separate extension RFC, and the processing-log standard is still in development, which leaves open how a log's integrity is assured across organisations. SDX's anchored record is a candidate implementation for that layer: logging whose integrity does not depend on the party keeping the log. The intent is to strengthen the standards the system designates, not to replace them.

What SDX does not adopt. FSC's contract and connectivity model stays FSC's; the system designates its own standards.

Status. Mapped. All government-adjacent work on this protocol is research and pilot work, and is labelled as such wherever it is described.

Adjacent infrastructure

eDelivery / AS4

What it is. The European Commission's building block for reliable, secure document exchange between access points, mandated in networks such as Peppol, customs and social security. Mature, widely deployed, and updated as eDelivery 2.0, adopted in December 2024.

Where SDX touches it. It does not, and does not need to: mandated AS4 flows stay AS4. SDX and AS4 are adjacent, with different guarantee scopes.

What SDX adds. In the four-corner model, the signature proves that an access point sent the message; the Commission's four-corner profile enhancement places end-to-end non-repudiation of origin for the original sender out of scope. SDX signs at the originator and anchors the commitment, so the recipient, and any auditor later, verifies the party rather than the transport. On confidentiality, the common four-corner deployment has the access point process the payload it forwards; SDX encrypts per field to the counterparty, so no routing party holds a key.

What SDX does not adopt. SOAP-based messaging and access-point accreditation. SDX exchanges also pass through infrastructure (the overlay fabric and the audit layer, described above), but those parties hold no keys and need no accreditation for the exchange to be verifiable.

Status. Not adopted; compared, not integrated. The full comparison, including what eDelivery does better and when each is the right choice, is at What this adds beyond eDelivery and AS4.

Also on the map

Entries a landscape scan should name, even where SDX has no direct touchpoint yet:

• IDSA and IDS-RAM. The lineage the DSSC Blueprint and DSP build on. SDX interacts with that lineage through DSP, not through IDS-RAM directly.
• IETF SCITT and transparency logs (including RFC 9162 style logs). The closest prior art to SDX's anchoring idea: independently verifiable statements on an append-only substrate. SDX differs in carrying encrypted payloads with per-field disclosure and mandate-bound signing in the same record.
• Simpl. The European Commission's middleware stack for common European data spaces; relevant as a deployment context for the control-plane standards above.
• Data Governance Act and Data Act. The legal instruments that regulate data intermediation and will shape what interoperability formally requires. Whether a given SDX deployment constitutes a data intermediation service depends on who operates what, and is a deployment question, not a protocol property.
• GDPR. Append-only records and erasure obligations meet in the erasable-mandate pattern held as provisional item PROV-4 in Identity and delegation: the record stays, the link to a natural person is erasable.

Governance and stewardship

Standards fail on governance more often than on technology, so the position here is stated plainly rather than discovered later. The specification is published for anyone to implement; the licence terms are on the licence page and the governance model on the governance page. The protocol currently has a single initiator, and the governance page states the hand-over triggers toward shared stewardship, including what happens once multiple parties are actively implementing. Critique of that setup is explicitly invited through the same page.

How to read this page over time

A mapped entry becomes credible in one way: a demonstrated artefact, named on this page, that anyone can reproduce. The first such artefact is the cbor-det-v1 test-vector suite, published September 2026 with 36 known-answer vectors that pin the deterministic encoding byte for byte. No other entry has its artefact yet. Until an entry has one, it stays labelled as a design intention.