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.

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

Support for the Dataspace Protocol

Since the April update, we have continued to work with message logging.

Message logging

In X-Road 7, message logging is implemented as a Security Server Proxy add-on. The Proxy is the Security Server component responsible for processing all the incoming and outgoing messages using the X-Road Message Transport Protocol. Instead, X-Road 8 will support the Dataspace Protocol, and the support will be implemented in a separate EDC-based (Eclipse Dataspace Components) component. In other words, X-Road 8 will have two components for processing messages: the Proxy component for the X-Road Message Transport Protocol and the EDC component for the Dataspace Protocol. In this way, X-Road 8 will be backwards compatible with X-Road 7.

A couple of architectural approaches were considered when implementing support for message logging for messages sent using the Dataspace Protocol. One alternative is to use the existing proxy add-on and integrate the EDC over gRPC, which is used for internal communication between different Security Server components. With this approach, the EDC sends all the messages to the add-on over gRPC, and the add-on logs them according to the Security Server's configuration. In this way, a single component is responsible for all the logging. However, the downside is that the messages to be logged may be huge, which might cause performance issues since they’re transferred over gRPC. Also, the whole message is always sent to the add-on, even if message body logging is disabled.

The second alternative is to implement message logging directly in the EDC component so that it's responsible for logging the messages that it processes. In this way, messages are not transferred over gRPC, which improves performance, and data that’s not going to be logged does not get transferred between different components. However, the downside is that message logging is done by two different components. Nevertheless, there’s a separate Proxy add-on that’s responsible for archiving all the messages.

The second alternative was implemented in the PoC, even if it meant having two components responsible for message logging. The main reason for the choice was better performance compared to the other option. However, ideally, only one component should be responsible for all the logging, without potential performance bottlenecks and data transfers between components when they are not required. Therefore, the selected approach will be refined in future development phases.

Nevertheless, the X-Road 8 PoC has a working message logging implementation now. Compared to X-Road 7, the main difference is that each message is signed separately instead of batch signing. Instead, batch timestamping is used, just like in X-Road 7. However, adding support for batch signing and updating the batch timestamping algorithm are both topics that will be revisited after the PoC. Also, the performance impact of signing each message separately requires further attention.

Support for Gaia-X Trust Framework

When joining Gaia-X and becoming a Gaia-X Participant, every organisation needs to get a Gaia-X Compliance Credential. Getting the credential requires submitting three credentials to the Gaia-X Compliance Service:

Registration Number Credential issued by the Gaia-X Notary Service
Legal Participant Credential self-issued by the Participant
Gaia-X Terms & Conditions Credential self-issued by the Participant.

Organisations must submit these three credentials to the Gaia-X Compliance Service, which does a minimum validation for them, e.g., the Registration Number Credential is issued by a Gaia-X approved Notary Service. If all three credentials satisfy the Gaia-X Compliance Rules, the Gaia-X Compliance Service issues a Gaia-X Compliance Credential. The organisation may then use the Compliance Credential to prove being a Gaia-X Participant and Gaia-X compliant.

The self-issued credentials must be signed using a certificate issued by a Gaia-X-approved trust anchor, e.g., an eIDAS-compliant Certificate Authority (CA). For X-Road Member organisations, this means that they can use their existing X-Road sign key and certificate to sign the credentials as long as the CA that issued the certificate is trusted by the Gaia-X Compliance Service.

In the PoC, we have set up our instance of the Gaia-X Digital Clearing House (GXDCH) services so that we’re free to define the trusted CAs. This enables us to use certificates issued by our internal X-Road Test CA - the same CA that we use to issue authentication and sign certificates for X-Road.

In the PoC, creating the credentials requires manual steps since the tools used to create them (e.g., the Gaia-X Wizard) are not connected to the X-Road Signer component that holds the sign key and certificate. In practice, the sign key and certificate must be exported from Signer, made available to the tools used in creating the credentials and stored in the EDC Identity Hub together with the credentials to enable their use during data exchange. In the future, the creation of the credentials will be a built-in feature of X-Road, and no external tools or exporting/importing keys and certificates will be required. During the PoC, utilising available 3rd party tools instead of building new X-Road-specific ones has been the fastest way to gain progress, and it has allowed us to concentrate on X-Road-specific questions.

After creating the Gaia-X credentials, they are stored in the EDC Identity Hub together with the X-Road member-specific sign key and certificate. This means the sign key and certificate are stored in the Signer and the Identity Hub. However, this is a temporary solution, and the long-term plan is to store the sign key and certificate in one place only.

Using VCs in data exchange

The Dataspace Protocol does not address how trust is established between data exchange parties. Therefore, a separate trust protocol is required to guarantee interoperability between data spaces on the trust plane level. The Eclipse Dataspace Working Group is working on the Eclipse Dataspace Decentralized Claims Protocol (DCP) that defines an interoperable overlay to the Dataspace Protocol for establishing trust. NIIS is a Supporter Member of the working group.

The group’s work is based on the protocol developed as part of the Eclipse Tractus-X Open Source Project. In addition to Tractus-X, the EDC Identity Hub implements the protocol too. The Eclipse Dataspace Working Group aims to develop the protocol specifications further and make them independent from individual data space implementation projects. In the PoC, the current version of the DCP implemented by the Identity Hub is used.

The credentials are used to authenticate the data exchange parties and can be used in defining access and usage policies. In other words, the data exchange parties exchange their credentials so that they can verify them and get access to their attributes. The Gaia-X Compliance Credential proves that an organisation is a Gaia-X Participant, and the other credentials contain additional information about the organisation. For example, in the PoC, the aim is to implement support for defining access policies using the Registration Number Credential that contains the organisation's registration number, e.g., VAT ID. In practice, the registration number can be used to define access rights to services just like the subsystem code is used now.

Using the registration number to define access rights to services is just a simple example. The credentials contain other information, and additional credentials can be supported, too. The benefit of using the information stored in different credentials over the subsystem code is that the credentials contain a more comprehensive set of information about the data exchange parties, and therefore, they provide a much more fine-grained way to define access and usage policies.

The aim is not to rely only on Gaia-X credentials but to look into implementing X-Road-specific credentials. For example, the information currently stored in the sign certificate could be stored in an X-Road-specific credential. There are already some initial plans for how the X-Road-specific credentials could look and what information they could contain. Also, the first tests with an X-Road-specific credential containing the X-Road identifier of an X-Road member organisation have already been implemented. However, before starting to work on more considerable changes to the current X-Road trust framework, we want to understand the Gaia-X Trust Framework better and have more practical experience in it and the technologies it's based on. The aim is to use the same technologies in X-Road’s trust framework too.

What’s next?

The main challenge continues to be integrating the Gaia-X trust framework with the EDC-based X-Road 8 Security Server. During the last month, we have gained progress, but we've also discovered some new issues. The good news is that despite the issues, we're only a minor step away from being able to utilise Gaia-X credentials for authentication and authorisation during the data exchange process between two Security Servers. The ongoing PoC will end at the end of May, but we're confident that the remaining issues will be resolved and we can reach the goal by then.

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