Decentralized interoperability and dataspaces

Mapping between X-Road terminology and Data Spaces terminology

Data space is a distributed system defined by a governance framework that enables secure and trustworthy data transactions between participants while supporting trust and data sovereignty. Data spaces enable data sharing and exchange within and across different data ecosystems. Just like eDelivery, data spaces are based on a set of common specifications and standards. Interoperability within and between data spaces requires following the same specifications and standards. Participants of different data spaces can choose the software products they use as long as the products implement the required standards.

For X-Road version 7, connecting X-Road to a data space requires implementing a custom gateway component responsible for conversions between X-Road and data space protocols.

Current state (for X-Road version 7.x and older):

Target state for X-Road v8: moving away from X-Road-specific protocols to the data spaces protocol stack to achieve full compatibility.

The protocols used in data spaces can be divided into three different layers:

• Trust plane manages participant identities and authentication. It can be sharable between different data spaces or data space-specific. 
  Currently, the X-Road trust framework is based on X.509 certificates. Instead, many data space initiatives, including Gaia-X, are basing their trust frameworks on W3C Verified Credentials (VC) and W3C Decentralised Identifiers (DID). In addition, a couple of alternative protocols define how credentials are exchanged between various data space components in different interactions.
  Since being technically interoperable with Gaia-X is in X-Road 8's scope, X-Road 8 must also support the aforementioned technologies. Instead of supporting multiple trust framework technology stacks in parallel, it's more efficient to try to limit and streamline the number of used technologies. Therefore, NIIS has been looking into migrating the X-Road trust framework from X.509 certificates to VCs and DIDs.

  The current plan is for X-Road 8 to use the DCP protocol for issuing and sharing verified credentials since the support comes with the EDC. In addition, the aim is to support the OID4VC protocol for verified credentials issuance. 

• Control plane manages contract negotiation and controls the data transfer process. It is generic and sharable between different data spaces. It’s defined by the standard data space protocol.

• Data plane performs the actual data transfer. It reuses existing protocols and technologies, and therefore, it doesn’t require defining a new data transfer protocol. Also, the data plane is typically use-case and/or data space specific.

Same protocols will be used both within one X-Road ecosystem, between two federated X-Road ecosystems and between X-Road and other data exchange ecosystems.

The data space protocol stack covers various aspects of data exchange, e.g., usage conditions and policies, contract negotiation, and data transfer process. They do not set restrictions to the actual data transfer protocol or wire protocol – the protocol that is used to transfer the data. In other words, any existing transfer protocol can be used, which enables the use of existing solutions and supports many different transfer protocols. This is a big difference compared to X-Road, which has its own transfer protocol.

Another difference is related to expressing and enforcing usage conditions and policies. In data spaces, they are expressed in human-readable and machine-readable ways, which can be enforced in organisational or technical manners. Instead, in X-Road, they’re expressed in a human-readable way, which can be enforced only in an organisational manner.

Trust framework is another crucial factor in interoperability within and between data spaces. Different data space initiatives have their own trust frameworks, but the initiatives are currently aligning their trust frameworks to avoid those becoming a blocker for interoperability between various data space initiatives.

How the Data Spaces concept is going to be supported in X-Road v8:

When two X-Road 8 Security Servers communicate, the standard data space protocol is used. Instead, when X-Road 8 and X-Road 7 Security Servers communicate, X-Road's custom protocol stack is used. Either way, information systems that exchange data over X-Road don’t know which protocol is used between Security Servers since the protocol between information systems and the Security Server has stayed the same.

Information about the protocols supported by a Security Server was added to the global configuration to enable the selection of the communication protocol between Security Servers. That way, the Security Server knows what protocols other Security Servers support. Therefore, the consumer Security Server can select a protocol the target Security Server supports.

The Eclipse Dataspace Connector (EDC) is an open-source implementation of a data space connector aligned with the International Data Spaces (IDS) and GAIA-X architectures. It's designed to:

• Manage data exchange policies and usage control

• Support sovereign data sharing between organizations

• Enforce contracts and consent

• Operate across federated trust domains

It handles:

• Data Offer / Request negotiation

• Policy enforcement

• Contract negotiation

• Metadata publishing

• Secure data transfer with logging and audit

When an organization wants to publish a dataset or API:

• X-Road registers the technical interface.

• EDC publishes it with metadata and policies in the data space.

When another organization wants access:

• EDCs negotiate a contract.

• X-Road delivers the data securely under that contract's terms.