This is the multi-page printable view of this section. Click here to print.
Blog
Management API upcoming versions
The current, stable Management API of EDC Connector version 3 has served well during the last 2 years, but changes in the underlying protocols and the solidification of the EDC-V concept demand new versions.
Rationale
There will be 2 new Management API version releases.
Version 4
Version 4, which is already in its beta phase (as you can check in the OpenAPI documentation, so you can test it out and provide feedback), has been introduced to better align with the DSP 2025-1 spec.
In that spec we can read:
All protocol messages are normatively defined by a json-schema. This specification also uses JSON-LD 1.1 and provides a JSON-LD context to serialize data structures and Message types as it facilitates extensibility. The JSON-LD context is designed to produce Message serializations using compaction that validate against the JSON Schema for the given Message type. This allows implementations to choose whether to process messages as plain JSON or as JSON-LD and maintain interoperability between those approaches.
This means that, despite the adoption of JSON-LD as done in the earliest versions of DSP, the specification describes the payloads with json schema documents, with the goal to have more tidy and simple messages and to avoid falling into the JSON-LD complexity.
JSON-LD is still there under the hood; in fact the way these messages can be expanded is described by the proper @context, so the semantic approach will be maintained.
EDC is going to follow the same approach: all the JSON payloads in the Management API will be described and validated
by json schema documents.
For example, here’s the TransferRequest type one: schema.
EDC already provides a common JSON-LD context that can be used, e.g.
{
"@context": "https://w3id.org/edc/connector/management/v2",
"@type": "TransferRequest",
"@id": "<uuid>",
...
}
The advantages of this approach are that those who need to use additional contexts to provide further semantics can do so, and also provide additional validation by just registering the related json schema file. Plus, client implementation will be much easier.
Version 5
Version 5 of the Management API will be pretty much the same as version 4 schema-wise, the only major change
will be in the path of the API: since the Virtual Connector will introduce the possibility to support multiple participants in the same runtime, the endpoint will need to contain the participantContextId, so an endpoint like /v4/assets/request could (just speculation, the format hasn’t been decided yet) become /v5/<participantContextId>/assets/request
Approach
The current plan is to promote v4 to stable with EDC release v0.17.0 and deprecate v3 at the same moment. Then v3 will be removed sometime after 3 months from the deprecation as stated in the “deprecation rules”.
At the moment there is no plan for v5 release.
Data Plane Signaling
Data Plane Signaling is a specification for interoperable communication between Dataspace Protocol Control Planes and Data Planes (github project).
We decided to fully adopt this specification and to deprecate the current approach. This will involve deprecating the current implementation of the communication layer between the Control Plane and Data Plane in addition to the EDC Data Plane Framework.
Rationale
The Data Plane Signaling specification addresses key architectural ambiguities by clearly delineating the roles of the Control Plane (orchestration and protocol-level authentication) and the Data Plane (actual data transfer and flow-specific authentication). This separation resolves design confusion, establishes symmetry between push and pull patterns, and, most importantly, creates a standard interface. This allows any application to become a compliant Data Plane, fostering innovation and moving the industry toward a future where data sharing is a seamless, integrated layer within sovereign applications, rather than a connector-centric task.
Approach
The implementation of the Data Plane Signaling protocol in the EDC Control Plane is already progressing (issue), we expect to have a fully compliant version as soon as a stable version of the Data Plane Signaling specification is released.
At that point, we will deprecate the EDC Data Plane Framework in its entirety, and after 2 releases, it will be eligible for removal from the codebase. If you are an EDC adopter, we recommend to start prototyping your Data Plane(s) following the current specification. The dataplane-signaling team is already providing SDKs library in different languages (Go, Rust, Java, .NET) to help with this transition.
Let’s see from the technical point of view what are the advantages brought by this approach.
How It Works Now
These diagrams are showing the current state-of-the-art; some details have been intentionally left out to focus on the scope of Control Plane and Data Plane interaction.
Two issues become apparent just by looking at the diagrams:
- Vertical grouping: The Data Plane is often considered part of the connector component together with the control plane. While this may not necessarily be an issue, it creates confusion for those building dataspace applications regarding the correct boundaries and leads to poor design.
- Lack of symmetry: The pull and push cases are handled quite differently on the consumer side, and the role of the consumer’s Data Plane/client is not as clear as it should be.
How It Will Work with Data Plane Signaling
Just a glance at the diagrams shows that a strong focus has been placed on separating the dataspace layer from the
“use case/application” layer.
This is not to say they were not separated before, but this specification formalizes it: the Control Plane and Data
Plane are two distinct architectural components serving different purposes.
While the Control Plane is responsible for wire protocol (DSP) communication and dataspace authentication, the Data
Plane handles the actual transfer and receipt of data, managing authentication for the chosen data flow protocol.
With this specification, any application meant to share data in a dataspace can implement the Data Plane Signaling specification and to become a Data Plane. This is the intended path forward: no more direct user-facing interaction with the connector, but rather an application layer that relies on the dataspace to provide sovereign data sharing.
Another interesting concept is that the data address is not managed by the Control Plane anymore: its creation and use happens completely in the Data Plane, while the control-plane just takes care to pass it to the counter-part through DSP.
References
The Path to Version 1 for the Eclipse Dataspace Components
The Eclipse Dataspace Components (EDC) project has evolved significantly since its initial release. What started as an experimental reference implementation for dataspace connectors has grown into a mature, modular framework used in a variety of production-grade data sharing environments.
Over the past few years, the project has continuously expanded its capabilities, aligned with emerging dataspace specifications, and improved its operational maturity. With these developments in place, the project is now approaching an important milestone: Version 1.0.
This blog post outlines what “Version 1” means for EDC, which milestones are currently in progress, and how these efforts shape the next phase of the project.
Why Version 1?
Reaching version 1 is not about introducing a completely new generation of features. Instead, it marks the completion of the foundational capabilities required for interoperable dataspaces, along with stable support for the core specifications (e.g. DSP, DCP) that underpin them.
The main goals of the Version 1 milestone are:
- Finalizing support for key dataspace protocols
- Consolidating architectural components developed across the ecosystem
- Aligning the APIs and operational maturity of the project
- Providing a clear baseline for adopters building dataspace infrastructures
In other words, Version 1 represents the point where the essential building blocks of EDC are considered complete and cohesive.
Important Disclaimer
Although the release will carry a 1.0 version tag, it will not be a Long-Term Support (LTS) release.
EDC Version 1 will follow the same release and deprecation strategy that applies to all other versions of the project. APIs and components may still evolve, and deprecated functionality will continue to follow the existing removal policy.
The Version 1 tag should therefore be understood primarily as a milestone for functional completeness and ecosystem alignment, rather than a guarantee of extended maintenance.
Milestones on the Road to Version 1
Several key initiatives are currently underway to finalize the core architecture of EDC before the Version 1 release.
Data Plane Signaling Integration
One important step is the integration of the Data Plane Signaling specification into the EDC data plane architecture.
The Data Plane Signaling specification defines how control planes communicate with data planes during data transfers. Integrating this specification enables:
- Standardized communication between control and data planes
- Improved interoperability between dataspace participants
- Better alignment with evolving dataspace standards
This work builds on the concepts described in our previous article about data plane signaling and brings the specification directly into the core implementation.
EDC-V as the Default Capability Set
Another major step toward Version 1 is the consolidation of capabilities introduced in EDC-V.
The EDC-V initiative introduced improved abstractions and architectural refinements for control planes adn their runtimes. These capabilities are now being merged with the legacy EDC repository and will become the default capability set.
The goal is to unify the project around a single, modernized architecture, simplifying both adoption and maintenance.
For users, this means:
- A consistent runtime architecture
- Reduced fragmentation between experimental and legacy components
- A clear path forward for building connectors
New Management API Versions
Another milestone involves updating the management APIs.
EDC currently exposes several APIs for connector configuration and operational control. As part of the Version 1 preparation, the project will transition to new management API versions, specifically:
- Management API v4
- Management API v5
The introduction of these versions improves:
- API consistency
- Long-term maintainability
- Alignment with the evolving EDC domain model
During the transition period, both versions will be supported to allow users to migrate gradually.
EDC Maturity Assessment
Finally, the project is undergoing a formal maturity assessment within the Eclipse Foundation ecosystem.
The Eclipse Foundation requires projects to demonstrate governance, development processes, and ecosystem stability before they can claim higher maturity levels.
Completing the EDC maturity assessment ensures that:
- Project governance and contribution processes are well established
- Documentation and development workflows meet Eclipse standards
- The project is ready for broader industry adoption
This step is an important signal that the project is moving beyond early-stage development into a fully established open-source infrastructure project.
What Happens After Version 1?
Version 1 should be seen as a foundation for future evolution, not the end of the roadmap. The EDC community will continue its iterative development approach, delivering improvements in regular releases.
You want to discuss new features or even contribute your ideas? Use the discussion page of the EDC project and check our guidelines in CONTRIBUTION.md.
Next Steps
Reaching Version 1 marks an important milestone for the Eclipse Dataspace Components project and its growing ecosystem.
Over the coming months, the community will continue working toward the milestones outlined above. As these pieces come together, we will get closer to officially tagging EDC Version 1.0.