Eclipse Dataspace Connector

• Eclipse Dataspace Connector is an open-source, modular implementation facilitating sovereign, decentralized exchange through policy-bound asset publication and contract negotiation.
• It separates control and data planes to manage catalogs, contract negotiations, and secure data or service transfers under ODRL-based policies.
• EDC aligns with IDSA and Gaia‑X standards, integrating federated catalogs and decentralized identities to enhance inter-organizational trust.

Searching arXiv for the cited EDC-related papers to ground the article in the current literature. The Eclipse Dataspace Components (EDC) Connector is an open-source, modular connector implementation governed by the Eclipse Foundation for sovereign, trusted, and decentralized exchange in dataspaces. It aligns with IDSA and Gaia‑X specifications and implements the Dataspace Protocol (DSP) for inter-connector communication. In the contemporary dataspace stack, the connector is the technical locus for catalog publication, contract negotiation, policy-bound exchange, and inter-organizational trust mediation; recent research extends that role toward richer discovery infrastructures, continuous access control, and service invocation semantics beyond data transfer alone (Arnold et al., 10 Jul 2025).

1. Position within dataspace ecosystems

Dataspaces are designed to support sovereign, trusted, decentralized exchange among ecosystem participants. Sovereignty denotes retention of provider control over access and usage; trust is established through standardized identity and policy mechanisms; decentralization is realized through peer-to-peer interaction via connectors rather than centralized brokers. Within that architecture, connectors mediate discovery, policy negotiation, and controlled exchange, making them the core runtime element of the dataspace interaction model (Arnold et al., 10 Jul 2025).

A 2023 survey positioned the Eclipse Dataspace Connector project as an open-source solution at the Eclipse Foundation whose goals include a concrete implementation of IDS standard protocols and alignment with Gaia‑X requirements. The same survey described a broader Eclipse Dataspace Components framework and noted a consortium including Microsoft, BMW, and SAP. It also emphasized EDC’s orientation toward decentralized identity via DIDs and VCs and toward federated catalogs, while retaining compatibility with IDSA-based components such as DAPS and the Metadata Broker (Dam et al., 2023).

EDC has been adopted or discussed in several sectoral settings, including mobility, manufacturing, tourism, and culture. In the German Culture Dataspace, for example, it functions as the organization’s gateway into the dataspace and is integrated with complementary catalog infrastructure for richer trustable discovery. This suggests that EDC’s significance lies not only in protocol conformance, but also in its role as the interoperability boundary between organizational IT and cross-organizational governance mechanisms (Arnold et al., 24 Jan 2025).

2. Connector architecture and resource model

In current architectural descriptions, EDC separates a control plane from a data plane. The control plane manages catalogs, offers, contract negotiation, and orchestration. The data plane executes transfers such as HTTP and S3, including parameterized REST transfers and a newer back-channel for feedback. EDC’s core exchange model is built around assets, policies, contracts, and controlled transfer under policy constraints (Arnold et al., 10 Jul 2025).

The asset model couples public metadata with private connector-local properties. For data exchange, this includes asset modeling with metadata and private data-access properties; for policy governance, usage policies are typically expressed in ODRL; and for execution, contract agreement authorizes controlled data transfer. A historical description in the survey literature characterized EDC assets as symbolic links to datasets and described contract definitions and contract offers as staged artifacts in the exchange lifecycle. That terminology is important because EDC preserves IDS-aligned conceptual structure while introducing “assets” as the operational handle exposed through connector APIs (Dam et al., 2023).

Earlier survey work listed EDC components as a Connector, a Federated Catalog Node, a Federated Catalog Crawler, a Policy Management, a Data Asset Management, an Identity Hub, and a Registration Service. Later work offers a more explicit operational decomposition around the control-plane/data-plane split. Taken together, these descriptions indicate architectural continuity: catalog federation, policy management, participant identity, and asset management remain central concerns, but are increasingly described in terms of concrete runtime boundaries and extension points rather than only high-level component names (Arnold et al., 10 Jul 2025).

3. Catalogues, metadata, and discovery

EDC exposes organizational resources by modeling each resource as an asset that couples human- and machine-readable metadata, such as API URLs, with usage policies. These assets are published through the EDC catalogue using DSP and are represented in a DCAT JSON-LD structure. In that sense, EDC provides the organization-facing publication and negotiation interface of the dataspace (Arnold et al., 24 Jan 2025).

Research on the Eclipse Cross Federation Services Components (XFSC) Catalogue treats EDC’s built-in federated catalogue as semantically limited and introduces a complementary trust-enforcing metadata directory. In that integration, a “Broker EDC” acts as a façade: it speaks DSP and DCAT to other EDCs, periodically crawls participant catalogues, maps each dcat:Dataset plus policies and dcat:DataService context into a Gaia‑X Resource Self-Description, assembles a Verifiable Presentation, and submits it to the XFSC Catalogue. The catalogue then performs JSON‑LD and VCDM syntax checks, cryptographic verification of VCs and the enclosing VP using URDNA2015 normalization, participant ID consistency checks, and SHACL validation against the union of loaded shapes before indexing claims into Neo4j via a labeled property graph and exposing openCypher-based discovery (Arnold et al., 24 Jan 2025).

This integration clarifies a recurrent misconception: EDC’s catalogue mechanism is not, by itself, a complete trustable metadata system for semantically rich discovery. The XFSC architecture assigns EDC the role of publishing and consuming DCAT/DSP catalogues, while centralized trustable discovery, lifecycle management, schema validation, and graph querying are delegated to a specialized service. The resulting operational flow preserves EDC interoperability for participants while adding cryptographic and semantic enforcement at the metadata layer (Arnold et al., 24 Jan 2025).

4. Policy enforcement, identity, and access control

EDC’s policy model is ODRL-based. Policies are sets of rules specifying allowed, disallowed, or required actions of a consumer for requested assets: permissions define allowed actions and can include conditions; prohibitions disallow specific actions; obligations require the consumer to perform certain actions. In survey literature, example policies are shown both as ODRL-compliant JSON-LD and as programmatically assembled Java artifacts that permit READ and prohibit DISTRIBUTE for a target asset (Dam et al., 2023).

Identity and trust can be organized in either centralized or decentralized forms. EDC is described as supporting IDSA-based components such as DAPS and the Metadata Broker, while also aiming at decentralized identity management via DIDs and VCs. In the decentralized description, a connector needs a DID anchored in a trust framework and a self-description that includes member attributes, a list of verifiable credentials, a pointer to the identity hub, a pointer to claims and proofs, and URLs of required endpoints. In newer service-oriented work, the service layer explicitly does not extend OAuth2, DAPS, or VC specifics, but instead relies on EDC’s existing trust and authorization infrastructure (Arnold et al., 10 Jul 2025).

A distinct research line extends EDC toward continuous, semantics-aware access control. That work defines a capability-style decision function

$$\text{Decide}(Consumer_{id}, operation, URL) \rightarrow \{true, false\}$$

and introduces URL-containment semantics over NGSI‑LD type, object, and attribute URLs. It maps the usual access-control roles onto EDC as follows: a PEP can be implemented as EDC’s data-plane proxy or as an external HTTP proxy; a PDP maps to or augments EDC’s PolicyEngine and authorization layer; and a PIP becomes a new EDC service that queries an NGSI‑LD broker to resolve object types and attributes. The same work observes that EDC’s ongoing usage-control enforcement is limited out-of-the-box and proposes extensions such as a UsageControlMonitor, TransferProcessManager hooks, a custom NgsiUrlContains constraint, OID4VCI/OID4VP integration, a TrustedIssuerRegistry, and VC Status List v2021 refreshers (Fotiou et al., 18 Apr 2025).

The resulting picture is that EDC already provides the contractual and policy-bound skeleton of dataspace exchange, but finer-grained continuous evaluation—especially for long-lived subscriptions and semantics-aware requests—requires explicit augmentation. This suggests that EDC’s policy model is structurally extensible, yet not semantically exhaustive for every dataspace domain without domain-specific PIP/PDP logic (Fotiou et al., 18 Apr 2025).

5. From data assets to service invocation

Standard dataspace technology and EDC focus on data assets and data transfer. Services such as data transformation, inference, or query execution are not first-class citizens in that model, and current workarounds wrap services into data-transfer patterns with significant effort and inadequate semantics. The proposed service architecture for EDC addresses this gap by modeling a service offering as a first-class connector asset representing a callable function

$f:(x_1,\ldots,x_n)\rightarrow y$

with a defined argument list and return type, governed by policies and contracts (Arnold et al., 10 Jul 2025).

The architecture introduces several abstractions. A service asset, or service descriptor, is the connector-local asset entry that advertises the service in the catalogue, with public metadata such as argument types and return type and a private binding to the service implementation through serviceId. A service policy reuses EDC’s ODRL-based access and usage policy model. A service contract is a negotiated agreement identified by contractId. Service invocation is then a policy-compliant remote execution whose state is tracked asynchronously across connectors until completion or closure (Arnold et al., 10 Jul 2025).

On the consumer side, EDC is extended with management API endpoints for starting invocations, checking status, and retrieving results. On the provider side, it exposes a Service interface with getMetadata(), loadArgs(args: Array<String>?), and execute(). Inter-connector coordination is performed by DSP-based signals such as ServiceInvocationSignal, ServiceInitializedSignal, ServiceExecutionSignal, ServiceRunningSignal, ServiceFailedSignal, and ServiceFinishedSignal. Invocation state is persisted in a relational database and reflected through states INITIALIZING, INITIALIZED, INVALID, STARTING, RUNNING, FAILED, FINISHED, and CLOSED, while arguments and results are cached in memory on the consumer side (Arnold et al., 10 Jul 2025).

Endpoint	Semantics	Result
POST /serviceinvocation/invoke	Starts invocation with contractId, args, optional callbackUrl	invocationId
GET /serviceinvocation/status?invocationId=...	Returns current invocation state	State enum
GET /serviceinvocation/result?invocationId=...	Retrieves result payload and type, or an error	Success/error payload

A notable architectural decision is that the data plane is not used for payload transfer in the service model. Service results are sent through control-plane signaling and connector APIs, thereby avoiding the construction of data-plane transfers for service calls. Provider-side restarts invalidate incoming invocations that are not CLOSED, marking them INVALID and notifying the consumer because arguments and execution state are lost. Accounting and billing are not covered in the current design. These details indicate that the service layer is not merely an API wrapper, but a connector-native execution protocol with its own state machine, persistence model, and policy binding (Arnold et al., 10 Jul 2025).

6. Performance, deployment patterns, and open issues

The service architecture was evaluated with an MNIST CNN service of approximately 1.2M parameters executed on server CPU, with the consumer connector and web backend on one hosted VM and the provider connector plus MNIST service on another hosted VM; all components were dockerized. In a hot setup over 10 runs, EDC-mediated invocation achieved mean times of approximately 245.0 ms from start until FINISHED, 14.7 ms from FINISHED until result requested, 8.5 ms from result requested until retrieved, and 268.2 ms total start to result, with the reported standard deviations. Direct HTTP invocation had mean 25.2 ms, and inference alone had mean 7.7 ms. The paper interprets this as an overhead factor of about 10.6, attributable to signaling, state management, and additional network hops, while noting that the relative overhead diminishes for more complex or longer-running services such as SQL queries or LLM calls (Arnold et al., 10 Jul 2025).

Adjacent deployment research in Multi-access Edge Computing does not implement EDC directly—the prototype uses the Fraunhofer/IDSA Dataspace Connector—but it maps the architecture into typical EDC building blocks: a managed connector instance corresponds to the EDC control plane; an attached proxy corresponds to the EDC data plane; identity and trust correspond to EDC’s OAuth2, DAPS, or VC integrations; and each connector exposes catalog and contract APIs. That work discusses deployment patterns such as a sidecar per MEC application, a shared connector per edge node, and a centralized control plane with per-node data planes. Although this is not an EDC evaluation, it is a useful architectural analogue for EDC-oriented edge deployments (Kalogeropoulos et al., 2023).

Manufacturing-X research further extends EDC operationalization through a DSL and unifying metamodel spanning EDC, OPC UA, and AAS/ID-Link. In that approach, IdentificationData and AssetMetaData compile into EDC assets, EDCUsage compiles into DataAddress and endpoint configuration, AccessPolicy.usagePolicy compiles into PolicyDefinition, and contractOffer compiles into ContractDefinition. The paper formalizes policy evaluation in ABAC style as a policy

$P=(S,R,A,C,D)$

with an evaluation function

$$E(s,r,a,ctx)\rightarrow \{\text{permit},\text{deny}\},$$

using deny-overrides as the default conflict strategy. It also notes that a full code generator is planned rather than implemented, and that the paper does not report performance benchmarks (Pfeiffer et al., 27 Nov 2025).

Several limitations remain stable across the literature. The 2023 survey emphasized fragmented documentation and the absence of detailed descriptions for Policy Management and Data Asset Management at that time, framing this as a risk for uptake and as evidence of relatively low technical readiness or maturity in documentation terms (Dam et al., 2023). The service extension identifies further open issues: service signaling is not yet standardized in DSP; the prototype relied on a messenger library with licensing constraints; result caching is in-memory on the consumer side rather than persistent; automated type validation beyond argument count is absent; provider restarts invalidate in-progress incoming invocations; and service offer creation requires multiple API calls and lacks dedicated UI (Arnold et al., 10 Jul 2025).

Taken together, the literature presents the EDC Connector as a connector-centric runtime for dataspace exchange whose canonical strengths are policy-bound asset publication, contract negotiation, and decentralized trust integration. It is simultaneously a moving target for extension: semantically richer discovery is being layered through complementary catalogues, continuous usage control through PEP/PDP/PIP patterns and VC-based authorization, and service execution through first-class service assets and DSP-based signaling. A plausible implication is that EDC’s long-term trajectory is not away from its asset-and-contract core, but toward a broader connector substrate in which data, metadata, and callable services are all governed through the same sovereign exchange primitives (Arnold et al., 24 Jan 2025).