NIIS is thrilled to announce the start of a proof of concept to develop a new major version, X-Road 8 “Spaceship”, which nurtures the proven ecosystem model and security while it takes X-Road to the next level by providing a solid data space infrastructure.

With the proof of concept, NIIS aims to validate the feasibility of replacing X-Road’s custom protocol stack with standard data space protocols and align X-Road’s trust framework with the Gaia-X trust framework.

In this blog post, we explore the X-Road 8 “Spaceship” plans and the scope of the proof of concept. Are you ready for the launch?

The current state of X-Road

X-Road provides a secure and unified way to exchange data between X-Road member organisations. X-Road enables data exchange within one X-Road ecosystem and between two independent X-Road ecosystems through federation. Members of the federated ecosystems can publish and consume services with each other as if they were members of the same ecosystem.

The interoperability within one X-Road ecosystem and between two independent X-Road ecosystems is based on the X-Road protocols. X-Road defines and implements a set of protocols that guarantee the interoperability and security of the data exchange. Multiple standards are used in X-Road's implementation, but no X-Road protocols have been standardised.

X-Road’s source code and all X-Road protocols are open, and documentation is publicly available, so anyone is free to implement X-Road’s protocol stack. However, no other open-source products implement X-Road’s protocol specifications. Instead, one commercial data exchange solution implements X-Road protocols to some extent, but estimating how compatible the implementation is with X-Road isn't easy.

X-Road is being developed as a product, and the protocol specifications are adapted according to the needs coming through the product development. Also, the specifications include some product-specific details like component version numbers. Therefore, developing and maintaining another product implementing X-Road’s protocol specifications would be challenging since the specifications include product-specific details. In practice, it’s unlikely that alternative implementations of X-Road’s protocol specifications will be seen, and the specifications will remain specific to the X-Road product.

eDelivery for cross-border data exchange in Europe

eDelivery is a building block of the European Commission and is the default technology for cross-border data exchange in Europe. eDelivery is based on the AS4 specification, and multiple open-source and commercial solutions that conform to the specification are available. Therefore, users of eDelivery are free to choose any of the available solutions; alternatively, they can also decide to implement their own. Either way, interoperability between different solutions is based on the common AS4 specifications. The European Commission is coordinating the development of the specifications independently from any of the implementing products.

Since X-Road and eDelivery are based on different specifications, they’re not directly compatible with each other. Making X-Road and eDelivery compatible requires implementing a custom gateway component responsible for conversions between X-Road and eDelivery protocols. However, implementing one common gateway is not feasible because of the differences between various eDelivery ecosystems. Therefore, multiple gateway implementations are required. Even though eDelivery is based on the common AS4 specifications, the specifications leave room for ecosystem-specific differences in the implementation.

Data spaces enable data sharing and exchange within and across data ecosystems

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.

Multiple organisations are developing specifications and standards for data spaces, e.g., the International Data Spaces Association (IDSA), Gaia-X, Fiware, the Data Spaces Support Centre (DSSC) and the Data Spaces Business Alliance (DSBA). The organisations work together to keep the specifications and standards aligned and not create multiple overlapping or competing specifications.

Currently, connecting X-Road to a data space requires implementing a custom gateway component responsible for conversions between X-Road and data space protocols. The same approach applies to eDelivery and other data exchange ecosystems, too.

The target state with X-Road

Implementing custom gateway components that enable X-Road to communicate with other data exchange ecosystems is not a feasible solution in the long term. The number of gateway components that need to be developed and maintained grows over time, and achieving full compatibility through them is highly challenging. Therefore, a better approach for X-Road is to move from X-Road-specific protocols to the data space protocol stack.

In practice, 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.
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.

Replacing the current X-Road-specific protocols with the data space protocol stack would mean that the same protocols are used within one X-Road ecosystem, between two federated X-Road ecosystems and between X-Road and other data exchange ecosystems. That way, the same set of protocols is used for internal and external data exchange.

However, being interoperable with another data exchange ecosystem requires that the other ecosystem implements the same data space protocols, too. At least right now, some data exchange ecosystems call themselves data spaces even if they’re not using the data space protocol stack. Also, not all the data exchange ecosystems will start using the stack in the future either. In other words, the change doesn’t guarantee full interoperability with all different data exchange ecosystems. Still, at least it improves the current situation significantly and increases the level of standardisation in X-Road’s implementation.

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 and eDelivery, which both have their own transfer protocol.

Another difference is related to expressing and enforcing usage conditions and policies. In data spaces, they’re 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.

Many data space initiatives have trust frameworks based on technologies different from X-Road’s trust framework, e.g., Gaia-X. X-Road's current trust framework is compatible with the Gaia-X trust framework on some level. However, in practice, many additional steps are required for an X-Road member to become a member of a Gaia-X-compliant data space utilising the X-Road trust framework. Therefore, replacing X-Road’s trust framework with the trust framework of a selected data space initiative is required to maximise interoperability.

Implementing the change doesn’t mean having to build everything from scratch. Several well-established and conformant open-source solutions are already available that can be taken as a basis for the implementation, e.g., Eclipse Dataspace Components (EDC). Many of the solutions support or are going to support the data space protocol stack, which means that it would be enough to implement changes that enable current X-Road users an easy migration path to the new version. The goal would be minimising the changes the current X-Road users must implement.

NIIS is currently responsible for developing and maintaining the X-Road core and extensions. Despite the worldwide X-Road community, external contributions have remained low. Migrating to the data space protocol stack by taking an existing open-source solution as a basis would change the current situation.

It is fair to assume that the chosen open-source solution already has a well-established developer community contributing to the core solution's maintenance and development. For example, the EDC project is hosted and facilitated by the Eclipse Foundation AISBL. The foundation is a Europe-based not-for-profit organisation that acts as a steward of the Eclipse open-source software development community. When NIIS isn’t alone responsible for the core development and maintenance, it enables NIIS to concentrate on areas that bring the most value to the NIIS members.

The downside of the approach is that NIIS would lose some control over the direction of X-Road’s future development because various data space initiatives lead the development of different layers of the data space protocol stack. NIIS could contribute to the development and suggest changes as needed, but it wouldn’t have the power to make decisions alone as it has now. However, it is unlikely that NIIS members’ needs would differ significantly from the needs of others. Also, the development of the X-Road core would be partly in the hands of another open-source project, and NIIS would be one of the contributors instead of being the project owner.

Data Space Infrastructure for X-Road

Implementing X-Road on top of a well-known open-source project conforming to the data space protocol stack would make X-Road interoperable with other data exchange ecosystems using the same protocols. However, connecting X-Road to data exchange ecosystems following other specifications would still require custom gateway solutions. Connecting X-Road to any other data exchange ecosystem today requires a custom gateway solution, so being interoperable with many other ecosystems would significantly improve X-Road.

Another benefit of the new approach is more flexibility in supporting different data transfer protocols. Currently, adding support for new data transfer protocols requires a lot of effort and is challenging to implement in a backwards-compatible manner. Instead, the standard data space protocols enable using various data transfer protocols which allows X-Road to support new transfer protocols more easily, e.g., data streaming, asynchronous data exchange.

Choosing the right trust framework for X-Road is important. To maximise the benefits, the best alternative is to utilise and extend the trust framework of a selected data space initiative, e.g., Gaia-X. In that way, there's no need to maintain a fully X-Road-specific trust framework and make it interoperable with the trust frameworks of different data space initiatives. Also, available data space connectors that can be used as a basis for the X-Road implementation are designed to support different trust frameworks.

Overall, the new approach makes it easier for X-Road users to exchange data with other data exchange ecosystems. Also, it helps to keep X-Road aligned with European data exchange initiatives and policies and relevant for many years to come. Most likely, it would also encourage other countries to select X-Road as a solution compatible with the European infrastructure.

The X-Road 8 Proof of Concept in 2024

The changes to X-Road presented in this blog post are significant and the plan is to implement them in the next major version, X-Road 8 “Spaceship”. The very first step is to implement a proof of concept that is divided into two phases taking place in 2024.

The first phase takes place in H1/2024 and its aim is to validate the feasibility of the selected approach – replacing X-Road's custom protocol stack with the data space protocol stack. The project also tries to ensure smooth integration with previous X-Road versions for backwards compatibility, estimate the changes required for information systems when transitioning to X-Road 8, and assess potential changes to existing X-Road components.

The proof of concept results are expected for review in May 2024. The second half of the year will witness another project to test the results within Estonia’s X-Road ecosystem.

More blog posts about X-Road 8 and the proof of concept will follow. Stay tuned!