At the beginning of January 2024, NIIS kicked off a proof of concept (PoC) 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 the Dataspace Protocol (DSP) and align X-Road's trust framework with the Gaia-X trust framework. 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 PoC was completed at the end of May. In this blog post, we explore the outcome of the PoC project.
Getting started
The project was kicked off in January 2024, and it aimed to:
Validate the feasibility of replacing X-Road's custom protocol stack with the data space protocol stack.
Look into making X-Road's trust framework technically compatible with the Gaia-X trust framework.
One of the main drivers for the PoC was to better understand whether it's possible to implement the planned changes in a backwards-compatible manner. Since X-Road has a broad existing user base around the world, it's vital to understand the number of changes that the X-Road user organisations must implement for their information systems when migrating to X-Road 8. At the same time, new users starting with X-Road 8 shouldn’t have to deal with the details of the previous X-Road versions.
Since the previous blog posts provide detailed information about the monthly progress, I won't repeat their content here. Instead, I will give a high-level overview of the PoC project and its outcome. The previous blog posts are available here:
Support for the Dataspace Protocol
The PoC implemented support for the dataspace protocol. It was achieved by integrating the EDC Connector and Identity Hub into the X-Road 7 Security Server. In practice, the Security Server’s existing functionalities were extended by the EDC. This approach allowed us a working implementation from day one that was also backwards compatible with X-Road 7.
The first iteration completed in February already supported the dataspace protocol and X-Road’s custom protocol stack. The interfaces between connected information systems and the Security Server were fully backwards compatible. In other words, no changes to the information systems were required to move from X-Road 7 Security Server to X-Road 8 Security Server. However, many implementation details were still missing, e.g., authentication of the data exchange parties, access rights management, logging, and secure connections between the Security Servers.
During the following months, we worked individually on the missing features. The aim was to validate that the features could be implemented and recognise potential issues that needed to be investigated in more detail. For example, we looked into defining access rights using ODRL and implementing message logging in the context of the dataspace protocol. Several questions that required further investigation were raised, but fortunately, none of them turned out to be a show-stopper.
The dataspace protocol is divided into two layers: 1) the control plane and 2) the data plane. We decided to use the EDC's control plane implementation and concentrate on the X-Road-specific data plane(s). Also, our goal was to implement all the required changes by extending the EDC since we wanted to avoid forking and creating an X-Road-specific version. Implementing some changes took a lot of work, but eventually, we reached our goal without forking.
During the PoC, the following features were implemented:
Support for SOAP and REST services.
Support for signing, timestamping and logging messages.
Support for defining access permissions using ODRL (including migrating current access permissions to ODRL).
Support for TLS between the Security Servers (control + data plane).
Caching and reusing JWT tokens generated as a result of a successful contract negotiation phase.
Support for “light context” - consuming services without a Security Server on the consumer side.
Publishing DCAT service descriptions and collecting them centrally using the EDC Federated Catalog component.
Storing credentials in the EDC Identity Hub and using them in authentication and access control during the data exchange process.
Since the project aimed to validate if the selected approach could be implemented in the first place, the main focus was to test if and how different features could be implemented without paying too much attention to quality. Therefore, the quality of the PoC implementation is far from the production level. Also, many features require additional investigation since several details were left open during the PoC.
Support for Gaia-X trust framework
The PoC looked into making X-Road's trust framework technically compatible with the Gaia-X trust framework. In practice, X-Road 8 should be aligned with the technical specifications and meet the technical requirements of the Gaia-X trust framework.
However, making X-Road’s trust framework technically compatible and interoperable with the Gaia-X trust framework doesn’t automatically make all X-Road ecosystems and user organisations Gaia-X compliant. Instead, it makes X-Road user organisations technically compatible with Gaia-X, but being Gaia-X compliant requires that the user organisations meet the requirements of the Gaia-X Compliance rules.
The first step was to set up an instance of the Gaia-X Digital Clearing House (GXDCH) services for more flexibility. We also configured an instance of the X-Road Test CA as a trust anchor, enabling us to issue our own certificates trusted by the GXDCH services. These steps helped us issue Gaia-X credentials that we could use for testing purposes.
Once able to issue Gaia-X credentials using X-Road members' sign keys and certificates, the main challenge was utilising them in the data exchange process between two X-Road 8 Security Servers. The EDC Identity Hub was used to store the credentials, and the EDC Identity and Trust Protocol (IATP) was used to exchange them. However, the EDC components didn't provide off-the-shelf support for Gaia-X credentials, so the implementation was done by trial and error. Despite the challenges, the project implemented support for using Gaia-X credentials for authentication and access rights management in the data exchange process. However, it doesn’t mean full support for the whole Gaia-X trust framework yet.
In addition, an X-Road-specific credential was implemented in the project. The so-called "X-Road Compliance Credential" includes the X-Road member organisation's X-Road identifier and can be used for authentication and access rights management. However, the credential was just a quick technical experiment at the very end of the project, and therefore, a lot further work regarding the update of the X-Road trust framework is required.
Summary
At the beginning of the PoC project, the main question was: can X-Road be transformed into a data space technology in a backwards-compatible manner? Based on the outcome, the short answer is yes.
In practice, the answer means that the project didn't discover any significant roadblocks that would make reaching the goal impossible. Instead, the project discovered many questions and areas that require further investigation. In other words, it seems that the goal can be reached, but at this point, we don't know all the steps required to get there. Also, there are several areas that we haven’t looked into yet, e.g., federation, operational, and environmental monitoring.
Image 1. The data space protocol stack.
The aim is to make X-Road 8 compatible with the data space protocol stack. One of the challenges is that the stack is not stable yet, and many of the key specifications are currently being defined. It means waiting for the first stable version or using a draft version. Both alternatives come with some challenges. However, the positive thing is that it's still possible to contribute to developing the specifications by collaborating with the data spaces community. For example, NIIS is a Supporter Member of the Eclipse Dataspace Working Group that’s currently working on the following specifications:
Dataspace Protocol (DSP)
Interoperability within one data space and between different data spaces and data space technologies requires that the specifications be detailed enough and cover the key areas. Missing or vague specifications can lead to a situation where interoperability is not achieved. Also, having multiple competing and non-interoperable specifications leads to the same problem. Therefore, it is important to work together on common specifications and aim for technological convergence between various data space initiatives.
What’s next?
The first X-Road 8 PoC project was completed at the end of May, but the hard work is just beginning. We will continue to work with the topics discovered during the PoC and make more detailed plans for the production-level implementation. The X-Road JIRA has a more detailed list of ongoing tasks.
Also, another PoC within Estonia’s X-Road ecosystem is scheduled for the second half of 2024. The first beta version is expected in 2025, and the first production version is planned for 2026.
More blog posts about X-Road 8 will follow. Stay tuned!