What’s actually inside a connector?
§1 of 4 · ~3 min read
Every dataspace participant runs a connector. The connector is the thing that enforces the shared rulebook on their side: identity, policy, contract negotiation, and the actual data transfer. Inside it are four components.
The four parts
Control plane
The brain of the connector. It holds the catalogue of what the participant has on offer, evaluates incoming requests against local policy, negotiates contracts with peer connectors over DSP, and signs off on transfers once both sides agree. Policy enforcement happens here, not in the data plane: by the time bytes start moving, the contract is already binding.
Data plane
The muscle. It moves the bytes. Once the two control planes have negotiated a contract through DSP, the data plane pulls data from the provider’s backend systems and delivers it to the consumer under the agreed policy. Without a functioning data plane, a connector can negotiate agreements but cannot move data. Currently runs on upstream Eclipse EDC components, with a multi-tenant Rust replacement on the roadmap (see the DSP Data Plane page).
Identity wallet
The connector’s passport. It holds the verifiable credentials that prove who the participant is in this dataspace (“Acme GmbH, registered in Catena-X, with these permissions, signed by these issuers”). During contract negotiation, the peer’s control plane checks the wallet contents against its policy. The wallet is what makes Tier 1 §2’s first primitive (org-level identity) actually enforceable on the wire.
Credential issuer
The authority that signs the wallet’s contents. Run by an entity the regulator trusts: a consortium (Catena-X), a public institution, or a sovereign agency. Each issued credential is a verifiable claim that survives cross-organisation checks because the signature, not the issuing platform, is the proof. When Acme’s wallet says “registered in Catena-X”, the credential issuer is the one that put that line there and signed it.
A single transfer, end to end
Six steps, in plain prose:
- Acme’s connector publishes a catalogue. “We have these emissions datasets, available under these policies, to participants that hold these credentials.”
- An OEM’s connector requests an offer. Its control plane reads Acme’s catalogue, picks the dataset it needs, and proposes a contract.
- Both control planes negotiate over DSP. Acme’s control plane checks the OEM’s wallet (Catena-X registration, OEM role, valid policy framework). The OEM checks Acme’s catalogue terms. They settle on an ODRL policy that captures the agreed use, retention, and audit requirements.
- The contract is signed. Both wallets countersign. The signed contract becomes the authoritative reference for everything that follows.
- Acme’s data plane sends bytes to the OEM’s data plane. Over HTTP, framed by the DSP transfer process. The data plane refuses any transfer the control plane has not approved; the OEM’s data plane refuses any incoming bytes outside the signed contract.
- Both control planes log the transfer. The audit trail is mutual: either side can produce a record that the other side can verify, and a regulator can reconcile both records without seeing the underlying data.
That is one transfer. Multiply by every dataspace participant on every working day, and the four components are the operating surface that makes the whole thing run.
Why these four, specifically
Control plane is where policy enforcement lives. Data plane is where bytes move. Wallet is the passport. Issuer is the authority that signs the passport. Each of the three Tier 1 §2 primitives is one component’s job: identity is the wallet plus issuer, policy is the control plane, audit is the negotiation log mutual to both control planes. The fourth component (the data plane) is what turns the negotiated agreement into actual movement. Take any one out and the other three stop being useful.
Previous: ← Going deeper Next: §2 How identity and policy actually work →