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 standard data space protocols 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.

In this blog post, we explore the current status of the PoC project.

Getting started

The PoC was kicked off at the beginning of January with an onboarding sprint whose aim was to look into existing data space initiatives and available open-source components and building blocks. Since the main challenge is to replace X-Road’s custom protocol stack with the data space protocol stack, we decided to start with integrating the standard dataspace protocol into X-Road and concentrate on the trust framework later.

First, we investigated available data space connectors and decided to focus on the Eclipse Dataspace Components (EDC) and the Tractus-X ConnectorKit. We were not looking for an off-the-shelf connector product but a customisable open-source framework that can be extended with additional features. Also, our focus was on Java-based building blocks since that’s the technology we’re the most familiar with. The EDC met these requirements well, while the Tractus-X ConnectorKit provided practical examples of implementing extensions on top of the EDC. Therefore, we decided to go with the EDC.

Let’s get working!

We decided to use the X-Road 7 Security Server as a starting point for the PoC and extend its current functionality by integrating the EDC into it. In this way, supporting existing functionalities together with the standard dataspace protocol is easier. The aim is to keep the interface between information systems and the Security Server as-is so that no changes to information systems are required. The interface between information systems and the Security Server is defined by the X-Road Message Protocol for REST and X-Road Message Protocol for SOAP.

In practice, the very first iteration of the X-Road 8 Security Server supports the standard dataspace protocol and X-Road's custom protocol stack. When two X-Road 8 Security Servers communicate, the standard dataspace 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. Whether the global configuration in its current form will be used in X-Road 8 remains to be seen. Still, a registry containing information about member organisations and Security Servers will be required. In the data space architecture, the component is called the Dataspace Registry.

The control plane and data plane

The standard dataspace protocol is divided into two different layers:

The control plane manages contract negotiation and controls the data transfer process. It is generic and sharable between different data spaces. The standard data space protocol defines it.
The data plane performs the actual data transfer. It reuses existing protocols and technologies and doesn't require defining a new data transfer protocol. Also, the data plane is typically use-case and/or data space-specific.

Since the control plane is standardised, the EDC provides the control plane implementation out of the box. However, the standard dataspace protocol specification is still a work in progress and has yet to reach a stable version. Nevertheless, we’re not going to touch the control plane implementation during the PoC but instead rely on the updates provided by the EDC. This approach enables the PoC to concentrate on implementing an X-Road-specific data plane.

X-Road data plane

The control plane discovery, contract negotiation and data transfer management processes are asynchronous and require multiple requests/responses between the data exchange parties. In the PoC, we have chosen to hide this complexity from the connected information systems, which makes it possible to keep the interface between them and the Security Server backwards compatible. Despite the contract negotiation process, a client information system needs to send a single request to the Security Server, and it will receive the requested data as a response. Diagram 1 provides a simplified version (despite the complexity, it's a streamlined version and doesn't include all the steps) of a data exchange process (e.g., a synchronous REST API call) using this approach.

So far, we have implemented the data exchange flow illustrated in Diagram 1 in a backwards-compatible way. However, the first version of the X-Road 8 data plane implementation still needs many critical features required for a production-level implementation. Despite a good start, it's still too early to say whether a fully backwards-compatible implementation is feasible. For example, the following features are missing:

Caching and reuse of contract negotiation results.
Define access permissions using the Open Digital Rights Language (ODRL).
Support for SOAP services.
Signing of messages.
Logging and timestamping.
Authentication and authorisation.
Support for operational and environmental monitoring.
Support for federation.

Light context

Also, we aim to look into providing support for the so-called "light context", which refers to a setup where the Security Server is required only on the service provider side. In other words, a service consumer could invoke services by connecting to the provider's Security Server directly without having a Security Server on the consumer side. Diagram 2 provides a simplified version of the scenario.

The idea is that the control plane phase would generate an API key or access token that could be utilised by a consumer information system operating in the light context. The API key or access token could be obtained from the service catalogue separately in advance so that the consumer information system could completely ignore the contract negotiation phase during a data transaction. This would make consuming X-Road services easier compared to the current situation being aligned with the standard dataspace protocol at the same time. The API key generation in the light context is ignored in Diagram 2. However, the light context requires compromises regarding the security guarantees X-Road provides.

What about the Gaia-X trust framework?

One goal of the PoC is to align X-Road’s trust framework with the Gaia-X trust framework. For now, we have used X-Road’s existing trust framework in the PoC since it enabled us to get started faster with the standard dataspace protocol-related changes. However, it doesn’t mean the Gaia-X trust framework has been forgotten.

So far, we have set up our instance of the Gaia-X Digital Clearing House (GXDCH) services. For clarification, our instance is for our internal testing and development purposes only – NIIS is not planning to become an official Gaia-X Digital Clearing House. The reason for setting up our instance instead of using the publicly available GXDCH instances is that it enables us to experiment more freely. For example, we are free to define our own trust anchors. Also, we have set up our instance of the Gaia-X Wizard.

The next step is building technical compatibility and interoperability with the Gaia-X trust framework. It means that X-Road should be aligned with the technical specifications and meet the technical requirements of the Gaia-X trust framework. This is an enormous change for X-Road since the current trust framework is based on X.509 certificates. In contrast, the Gaia-X trust framework is based on the Self-Sovereign Identity (SSI) principles and technologies like W3C Verified Credentials, Linked Data (RDF) and Decentralised Identifiers (DID).

Support for the Gaia-X trust framework can be achieved in different ways. For example, X-Road could continue to use its current trust framework and support the Gaia-X trust framework. Alternatively, X-Road's trust framework could be based on Gaia-X's technical specifications, making it technically interoperable with Gaia-X by default. A final decision hasn’t been taken yet, but at this point, making X-Road’s trust framework aligned with Gaia-X’s technical specifications is the more likely option. That’s the approach that will be investigated in the PoC.

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. In other words, using X-Road 8 doesn't automatically make an organisation a Gaia-X participant. Instead, X-Road 8 will provide the technical means to become a Gaia-X participant when an organisation meets the requirements of the Gaia-X Compliance rules.

What’s the relationship between X-Road 7 and X-Road 8?

The decision to use the X-Road 7 Security Server as a basis for the X-Road 8 PoC doesn’t mean that X-Road 8 will be based on X-Road 7. It might be that some X-Road 7 components will initially be included in X-Road 8 to make the upgrade from X-Road 7 to X-Road 8 smoother for existing users. Once the upgrade has been completed, the X-Road 7 components can be dropped from X-Road 8.

I also want to highlight that new X-Road ecosystems that will be set up using X-Road 8 don't have to deal with X-Road 7. If backwards compatibility with X-Road 7 is not required, X-Road 8 can be deployed without X-Road 7-related dependencies.

What’s next?

Currently, the PoC is divided into two work streams:

Support for the Standard Dataspace Protocol.
Support for Gaia-X trust framework.

Support for the Standard Dataspace Protocol work stream continues to work on the X-Road data plane and extend its functionalities. Next, we will look into supporting SOAP services, caching contract negotiation results, defining access permissions using ODRL and message signing and logging.

Instead, support for the Gaia-X trust framework work stream continues experimenting with the GXDCH services and the Gaia-X Wizard. Next, we plan to utilise existing sign keys and certificates of X-Road member organisations to create and sign Gaia-X Verifiable Credentials and Verifiable Presentations.

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