Data Exchange services

Gaia-X mission to foster data exchanges is articulated around the following needs:

  1. A set of common APIs for data exchange
  2. A set of common Domain Specific Languages (Rego, ORDL, …) for
    1. access rights
    2. usage policies
  3. A common schema for identity and attribute-based access

To address those needs, the following services are required:

  • A wallet to store credentials
  • A service or extension integrated into existing data endpoints to compute policies
  • A service to sign the computed policies result, plus additional terms & conditions is needed.
  • A service to store the signed policies result

Those services can be provided by a single component like a data connector or via a self-serve data infrastructure like defined in the Data Mesh article.

The above coupled with a decentralized data infrastructure will truly enable data mesh across organisations.

Another lead is to use data Pods as introduced in the W3C Solid project.


The Gaia-X Lab is prototyping the needs 1) and 2) via the Kalg project.


2 thoughts on “Data Exchange services”


    Hello all,
    the data connector, as not addressed by the current GXFS specifications, is an important component to reach the goals of Gaia-X. Without an external component that implements the data connector, any data space will need to invest 90% of their resources into setting up connection and exchange capabilities. This will let those projects fail.
    Just references to APIs or DSLs are not sufficient, they need a piece of software that is solving those tasks by standardizing the interfaces and how different aspects work together as ONE service. This has already been shown by preliminary work of the IDSA.
    Nevertheless, those aspects can (and should) be considered technology agnostic, since a federation should have the possibility to choose if they want to use Rego (OPA), ODRL or other DSL for Policies, specific data protocols and so on.
    The Lighthouse initiatives of Gaia-X will clearly bring that in as requirements together with the DSBC.

    One example of a technology agnostic implementation for data exchange is, as you know the Eclipse Dataspace Connector but there are other Connectors out there, as well.

    The DSBC will take responsibility to make statements on requirements and put something on this site. This list right now does not reflect customer needs and should not be published, before prior editing.

  2. Pierre Gronlier

    Thank you for your comment Stefan.
    Let us work in a community-based environment by sharing the actual requirements through the Portfolio Management process defined and managed by the DSBC. That way, we will continue growing in one direction.
    Best regards,

Leave a Comment

Your email address will not be published. Required fields are marked *