X-Road 7.8.0 Is Here

During the second half of 2025, the development of X-Road 8 “Spaceship” and X-Road 7 “Unicorn” continued in parallel. The available development resources have been divided between the two major versions, and both have made good progress.

X-Road 7.8.0 was released at the beginning of February 2026. Let’s see what the highlights of the new version are! The full release notes are available here.

Support for selecting between free and paid trust service providers

Starting from version 7.8.0, X-Road supports defining cost-related metadata for trust service providers. Central Server administrators can define OCSP and timestamping services as free or paid, which makes the cost impact of different configuration options more transparent to Security Server administrators.

The metadata is shown in the Security Server UI, and Security Server administrators can configure their Security Servers to prefer one option over another. The available strategies are:

• NONE (default) - uses the same logic as earlier versions

• ONLY_FREE - only use services marked as free and ignore the rest

• FREE_FIRST - use free services first, fall back to paid services and then undefined ones

• ONLY_PAID - only use services marked as paid and ignore the rest

• PAID_FIRST - use paid services first, fall back to free services and then undefined ones.

The Security Server administrators can configure these strategies using the “message-log.timestamping-prioritization-strategy” and “signer.ocsp-prioritization-strategy” properties. By default, their value is NONE. The strategies define which trust services the Security Server uses during its operations.

Support for automatically selecting the supported Certificate Sign Request (CSR) format

Starting from version 7.8.0, X-Road supports defining the supported Certificate Signing Request (CSR) format for each trusted Certificate Authority (CA). Central Server administrators can set the supported format for each CA on the Central Server, and the format is automatically selected on the Security Server when a new CSR is generated. As a result, Security Server administrators no longer need to know which CSR format is supported by the CA they are using.

When the format is automatically selected on the Security Server, the CSR format menu becomes read-only, and its value cannot be manually changed. Automatic selection is enabled when a supported CSR format is defined for the selected CA on the Central Server. The feature applies to both manually generated CSRs and certificates ordered using ACME.

New tools for connection debugging

Version 7.8.0 provides new tools for testing connections to the Central Server, the management Security Server, and other Security Servers. These features make it easy to test connectivity between different X-Road components without any additional tools.

The Central Server connection tests support checking connectivity for downloading the global configuration and for sending authentication certificate registration requests. These tests can be used to verify that all required firewall configurations are in place between the Central Server and the source Security Server.

In addition, connection tests with other Security Servers allow Security Server administrators to verify connections to other Security Servers and clients. It is possible to select the target client and, if the target client is registered on multiple Security Servers, also the target Security Server. If a connection test fails, an error message providing more detailed information about the issue is shown in the UI. However, in some cases, it may still be necessary to consult the Security Server logs for additional details.

Support for multiple tokens in the autologin script

The autologin script enables the Security Server PIN code to be entered automatically after startup. Before version 7.8.0, the script supported only one token, which was the software token. Starting from version 7.8.0, the script supports multiple tokens, allowing both software and hardware tokens to be logged in automatically.

The original behaviour of the script is still supported: if there is only one line in the “/etc/xroad/autologin” file, it is used as the PIN code for the software token. If the file contains multiple lines in the format “token_id:pin_code”, the new behaviour is applied.

Other improvements and updates

In addition to the already mentioned features, version 7.8.0 includes several minor improvements and updates. These include, for example, support for hardware tokens with the Security Server Sidecar, the ability to customize the ACME HTTP challenge port on the Security Server, a new version of the basic certificate profile that supports ACME, updates to the Estonian and Portuguese translations, and support for defining the admin user password as a hash using an environment variable when starting a Security Server Sidecar container.

Once again, we received several contributions from members of the X-Road Community. It is great to see the number of community contributions remaining steady, and we hope this trend continues. Thank you to all the contributors—your efforts are highly appreciated!

Please review the release notes document to understand fully all the changes in version 7.8.0.

What’s next?

This is the last new-feature release for X-Road 7. In practice, this means that new feature development for X-Road 7 will stop after version 7.8.0.

In the future, X-Road 7 development will continue in maintenance mode, focusing on minor bug fixes and technical maintenance (for example, updating third-party dependencies). Naturally, additional releases addressing critical security vulnerabilities in X-Road 7 will be published if necessary.

The overall duration of the X-Road 7 maintenance period has not yet been decided. However, the intention is to continue X-Road 7 maintenance beyond 2026.

From now on, the main focus of X-Road development is on developing the next major version, X-Road 8 “Spaceship”. More news regarding X-Road 8 will be published regularly. Stay tuned!

On the Launch Pad – X-Road 8 “Spaceship” Beta Prepares for Takeoff

The X-Road 8 “Spaceship” development started in January 2024 with a proof of concept (PoC) that was completed in five months. 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 was yes.

After the initial phase, the development work concentrated on topics and areas identified during the PoC that required further investigation. The work continued through the second half of 2024. This phase was necessary to ensure that the actual implementation phase could begin with sufficient knowledge of the various technical implementation details.

The actual implementation phase was kicked off at the beginning of 2025. In practice, this meant abandoning the PoC phase code base that had been used to experiment with different approaches and solutions. As a result, the PoC deliverables were less suitable as a basis for a production-level implementation. Therefore, the production-level implementation was initiated by taking the latest X-Road 7 release version (X-Road 7.6.0 at the time) as the foundation and implementing the required changes on top of it.

As of October 2025, X-Road 8 “Spaceship” has reached its first significant milestone — the release of the first X-Road 8 beta version. The official release date is October 23, 2025. The beta includes all the changes implemented so far, but it is still far from the planned feature set of the first X-Road 8 production release. Next, let’s take a closer look at the changes included in the beta!

What’s new in the beta?

The most visible change in the beta is the new UI style. The visual design of the Central Server and Security Server UIs has been updated according to the X-Road 8 visual style guide. The main logic and task flows have remained the same, but the navigation system has been updated, and the overall look and feel has been refreshed.

The most significant changes have taken place under the hood. The beta introduces a more modular software architecture designed for the cloud. The new architecture provides better support for containerised deployments in cloud environments. At the same time, all previous deployment options remain supported, meaning no one is forced to migrate to the cloud with X-Road 8. However, in the beta, support for containerised deployments is limited to the Security Server only. The Central Server, on the other hand, supports only Ubuntu-based deployments.

Better support for containers

In the beta, different Security Server modules are deployed to separate containers, enabling more flexible deployment and scalability options. In practice, a Security Server instance consists of multiple containers that communicate with each other over gRPC:

• Configuration Client

• Proxy

• Signer

• Proxy UI API

• Backup Manager

• Environmental Monitoring

• Operational Monitoring

• Open Bao

Running the Security Server requires an external database since the database is not included in the X-Road 8 containers. The external database can be a separate database container or some managed database service in the cloud. The setup can be orchestrated using Kubernetes-based container management tools, e.g., k8s.

Supporting Kubernetes for containerised deployments

Kubernetes has been chosen as the orchestration platform supported by X-Road 8. This decision is based on the fact that Kubernetes is the most widely supported container orchestration platform, and several Kubernetes-based services and products are available (e.g., Kubernetes (K8s), Amazon Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS), Google Kubernetes Engine (GKE), Red Hat OpenShift).

Some X-Road features (e.g., backup and restore) require that the X-Road application is able to interact with the orchestration platform via its APIs to manage the application containers. Unfortunately, there are no unified standards for the APIs, and therefore, each platform has its own implementation, e.g., stopping and starting containers is handled differently by Kubernetes and Docker Compose.

Nevertheless, the X-Road Docker images can be run anywhere, but there are Kubernetes-specific features that will limit X-Road's ease of use with other orchestrators. For example, deploying the Security Server using some other orchestrator is possible, but the application-level backup/restore features are unavailable, and the administrator must implement the backup/restore using different tools.

Changes to the Security Server add-ons

The Security Server supports add-ons that provide additional features on top of the core functionality, e.g., message logging and environmental and operational monitoring are all Security Server add-ons. In X-Road 7, add-ons are implemented as separate add-on packages that can be installed separately. In X-Road 8, separate add-on packages are removed, and all add-ons are packaged with the Security Server core. In this way, Security Server administrators can turn add-ons on/off by updating Security Server's configuration instead of having to install/remove packages. The change simplifies managing add-ons and enables using the same approach in add-on management regardless of the Security Server deployment model (native / container).

Moving configuration data to the database

In the beta, all the possible configuration data has been moved from the filesystem to the database to simplify the backup and restore process of the containerised deployment. This includes configuration properties, signer data, keys, configuration anchor file, etc. Also, PostgreSQL is used as a storage backend for locally deployed OpenBao (OpenBao is used as a secure secret storage in X-Road 8). In this way, the backup of the containerised deployment consists only of the database dump. Instead, in the native deployment, the backup still includes configuration files from the /etc/xroad folder.

What about data spaces?

We decided to carry out the production-level implementation in multiple phases. First, we started by making changes to the existing X-Road architecture and implementing improved support for containers. In addition, the visual layout of the Central Server and Security Server UIs has been updated according to the X-Road 8 visual style guide. After refactoring the foundation, we will add support for the data space protocol stack and the Gaia-X Trust Framework. This approach helps us avoid implementing too many major changes in parallel and allows us to focus more effectively on the ongoing tasks. We are still working on the architectural changes, but the plan is to begin work on data space protocol support within the next few months.

What’s missing from the beta?

Compared to a regular X-Road 7 production release, the beta version lacks some of the usual features. In addition to the data space protocol support, the following features are not supported in the beta:

• Central Server and Security Server clustering

• Migrating from Security Server Sidecar to X-Road 8 containerised deployment

• Upgrading native versions (Ubuntu + RHEL) from X-Road 7 to X-Road 8 beta

• Upgrading between different X-Road 8 beta versions

In other words, the beta supports fresh single-instance (non-clustered) installations of the Central Server and Security Server. The Central Server supports Ubuntu 24, while the Security Server supports Ubuntu 24 and containerised deployment on Kubernetes. Also, the beta Security Server is compatible with the X-Road 7 Central Server, which means it can be registered to an existing X-Road 7 instance for testing purposes.

More detailed information on features and limitations will be included in the X-Road 8 beta release notes.

What’s next?

All in all, the development of X-Road 8 is progressing nicely, and we're on track to publish the first production version of X-Road 8 "Spaceship" in 2026, as planned.

Currently, we’re in the first phase of our implementation plan — implementing changes to the existing X-Road architecture. We expect to begin the second phase — adding support for the data space protocol stack and the Gaia-X Trust Framework — in a few months. As the implementation progresses and new milestones are achieved, additional beta versions will be published throughout 2026.

The main reason for publishing this beta version is to allow the X-Road community to try the new version and provide feedback on the implemented changes. Please check the beta version and share your thoughts through your preferred feedback channel. This way, we can ensure that the implemented changes align with the community’s needs and expectations.

More blog posts about X-Road 8 will follow later this year. Stay tuned!

X-Road 7.7.0 Is Here

The development of X-Road 8 “Spaceship” and further enhancing the X-Road 7 “Unicorn” has continued in parallel. The available development resources have been divided between the two major versions, but despite that, both versions have gained good progress. In May, the allocation of development resources was adjusted towards the X-Road 8 development team.

This blog post focuses on the latest changes in X-Road 7. A separate blog post about the latest developments in X-Road 8 was published recently.

X-Road version 7.7.0 was released in July 2025. Let’s see what the new version highlights are! The full release notes are available here.

Support for automatic activation of authentication and sign certificates

Since version 7.5.0, automating parts of the Security Server authentication and sign certificate management using the Automatic Certificate Management Environment (ACME) protocol has been possible. In version 7.6.0, support for automatic renewal of authentication and sign certificates originally issued using ACME was added.

In versions 7.5.0 and 7.6.0, the certificate management process is not fully automated, yet certificates ordered or renewed using ACME need to be manually activated by the Security Server administrator. Instead, version 7.7.0 adds support for the automatic activation of certificates that are ordered or renewed using ACME. In this way, the whole certificate renewal process can be fully automated.

Automatic activation is disabled by default, and the Security Server administrator can enable it. If email notifications are enabled, the Security Server administrator receives an email notification when a certificate is activated. Before a certificate is activated, the Security Server verifies that the certificate has a valid OCSP response. This applies to manual and automatic activation and prevents activating a certificate with a missing or invalid OCSP response.

Automatic activation can be turned on and off separately for authentication and sign certificates. When automatic activation of authentication certificates is enabled, manually ordered authentication certificates are also activated automatically once registered on the Central Server.

Instead, the automatic activation configuration of the sign certificate only affects sign certificates ordered using ACME. Manually ordered sign certificates are always activated automatically when imported to the Security Server, regardless of the automatic activation configuration status of the sign certificate. This behavior existed already before ACME support was initially added in version 7.4.0 and adding ACME support hasn’t introduced any changes to it.

More details are available in the Security Server User Guide.

Support for defining a full name for subsystems

Starting from version 7.7.0, X-Road supports defining a full name for subsystems. The name can be defined in a single language using the Central Server and Security Server UIs. Until now, a subsystem has been defined by a subsystem code—a technical identifier that must be unique within the scope of the owning member. In other words, the subsystem code isn’t usually very descriptive for users outside of the owning organisation, and therefore, additional metadata is needed to describe the subsystem.

When upgrading to version 7.7.0 from an earlier version, the subsystem code is initially used as the default name for each subsystem. The name can be defined on the Security Server by the Security Server administrator or on the Central Server by the Central Server administrator. When updating the name of a subsystem that's registered on multiple Security Servers, it's enough to update it once on one of the Security Servers where it's registered or on the Central Server.

When a subsystem is renamed on the Security Server, an update request is sent to the Central Server using a management service. The request is approved automatically by the Central Server, and the new subsystem name will become visible on Security Servers as soon as they download an updated version of the global configuration from the Central Server. In other words, the new subsystem name is not visible in the Security Server UI immediately after sending the update request. Instead, it will become visible within a couple of minutes.

To enable renaming subsystems in an X-Road ecosystem, the Central Server administrator must refresh the management service WSDL on the management Security Server(s) after upgrading to version 7.7.0. The new management service clientRename must be added to the management Security Server(s).

Putting a Security Server into maintenance mode

Starting from version 7.4.0, it has been possible to temporarily disable a subsystem on the Security Server. However, putting an entire Security Server into maintenance mode previously required disabling all subsystems individually—a process that is inconvenient for Security Servers hosting dozens of subsystems. To address this, version 7.7.0 introduces the ability to put an entire Security Server into maintenance mode with a single action.

When a Security Server is in maintenance mode, it will not accept requests from other Security Servers. An attempt to send a request to a server in maintenance mode will result in an error. This error may include an optional message configured by the administrator of the target Security Server. Suppose the target service is also registered on another Security Server that is not in maintenance mode. In that case, a client Security Server running X-Road version >= 7.7.0 will send the request to one of the available Security Servers. Instead, an older client Security Server cannot pick up an optional target Security Server, and the request will fail.

The Security Server administrator can turn maintenance mode on or off as needed. However, a Security Server that provides management services cannot be placed into maintenance mode. In such cases, the maintenance mode feature is entirely disabled.

When turning maintenance mode on or off on a Security Server, the maintenance mode status changes within a couple of minutes. The Security Server sends a maintenance mode activation/deactivation request to the Central Server through management services, and the request is approved automatically. The Security Server status is updated to the global configuration by the Central Server and once the updated global configuration has reached all the Security Servers, the new maintenance mode status has been fully applied.

To enable putting a Security Server into maintenance mode in an X-Road ecosystem, the Central Server administrator must refresh the management service WSDL on the management Security Server(s) after upgrading to version 7.7.0. The new management services maintenanceModeEnable and maintenanceModeDisable must be added to the management Security Server(s).

Visualise subsystem and service usage metrics in the Security Server UI

Starting from version 7.7.0, viewing different usage metrics in the Security Server UI is possible. The Diagnostics view will provide a new section that visually represents traffic passing through the Security Server. The page supports filtering traffic data by time frame, role (consumer/provider), subsystem code, service code, and message status (success/failure). This means viewing the traffic metrics doesn't require invoking the Operational Monitoring SOAP interface anymore.

Traffic data is available only if the Operational Monitoring add-on is installed on the Security Server. For example, the Security Server Sidecar Docker image's slim variants don't include the add-on, so the feature is not available on them.

Also, the available time frame depends on the configuration of the Operational Monitoring add-on. By default, the add-on retains operational monitoring data for seven days, meaning that older data is unavailable in the usage metrics view. The retention period can be adjusted using the op-monitor.keep-records-for-days property on the Security Server. However, before increasing the value, please consider the associated increase in the need for operational monitoring of the database's disk space.

Other improvements and updates

Besides the already-mentioned features, version 7.7.0 includes many other minor improvements and updates. For example, support for removing HSM tokens using the Security Server UI and REST management API, support for automatically adjusting the memory allocation of the Security Server’s proxy component, support for the proxy component's memory-related warnings via the health check interface, support for reserving X-Road meta service codes and support for Brazilian Portuguese in the Central Server and Security Server UIs.

This time, we also received several contributions from members of the X-Road Community. It's great to see the number of community contributions increasing, and we hope this trend continues. Thank you to all the contributors—your efforts are highly appreciated!

Please review the release notes document to understand fully all the changes in version 7.7.0.

Towards the X-Road 8 "Spaceship"

Version 7.8.0 will support sending email notifications about technical issues on the Security Server. Other changes that will be introduced in version 7.8.0 include, but are not limited to, support for selecting between free and paid timestamping services on the Security Server, support for automatically picking up the supported Certificate Signing Request (CSR) format (pem / der) for the selected CA when generating a CSR for authentication or sign certificate on the Security Server and streamlining the Security Server configuration during the installation. Version 7.8.0 will be released during Q4 in 2025.

At the same time, when developing X-Road 7, NIIS continues to work on the next X-Road major version – X-Road 8 “Spaceship”. More news regarding X-Road 8 will be published regularly. Stay tuned!

Making of X-Road 8 - June 2025 Status Update

The X-Road 8 “Spaceship” development continued fully during the first half of 2025, even though the previous status update was published in December 2024. Regardless of the pause in X-Road 8-related blog posts, we haven't been resting on our laurels. Monthly status updates are also available in the X-Road Community Expert Group meeting minutes.

This blog post explores what has happened in the X-Road 8 development during the last six months.

Starting the production-level implementation

In 2024, we implemented a PoC which verified that X-Road could be transformed into a data space technology in a backwards-compatible manner. That included experimenting with different approaches and solutions, which caused the PoC deliverables to be less optimal as the basis of a production-level implementation. Therefore, we decided to kick off the production-level implementation by taking the latest X-Road 7 release version (X-Road 7.6.0 at the time) as a basis and start implementing the required changes on top of it. In practice, the X-Road 8 development on GitHub was moved from the edc-poc branch to the develop-8.x branch.

We decided to work with the production-level implementation in multiple phases. First, we start with the changes to the existing X-Road architecture and implement improved support for containers. In addition, the visual layout of the Central Server and Security Server UIs will be updated according to the X-Road 8 visual style guide. Then, after refactoring the foundation, we add support for the data space protocol stack and the Gaia-X Trust Framework. In this way, we avoid implementing too many significant parallel changes and focus better on the ongoing tasks. So far, this has proven to be a good choice.

Better support for containers

In X-Road 7, the Security Server already supports containerised deployment, but the current implementation has certain limitations. For example, all the Security Server modules are deployed to a single container, and splitting them into multiple containers is not supported.

In X-Road 8, different Security Server modules will be deployed to separate containers, enabling more flexible deployment and scalability options. Now, the Security Server containerisation has reached the point when it's possible to run a Security Server instance consisting of multiple containers:

• Configuration Client

• Proxy

• Signer

• Proxy UI API

• Backup Manager

• Environmental Monitoring

• Operational Monitoring

• Messagelog Archiver

• Open Bao

Running the Security Server will require an external database since the database is not included in the X-Road 8 containers. The external database can be a separate database container or some managed database service in the cloud. The setup can be orchestrated using Kubernetes-based container management tools, e.g., k8s. Nevertheless, the containerisation-related work has not yet been completed since there are still open questions that need to be resolved.

Supporting Kubernetes for containerised deployments

The aim is for the containerised version of X-Road 8 to be deployed on various container orchestration platforms. However, implementing fully automated backup and restore requires that the X-Road application is able to interact with the orchestration platform via its APIs to manage the application containers. Unfortunately, there are no unified standards for the APIs, and therefore, each platform has its own implementation, e.g., stopping and starting containers is handled differently by Kubernetes and Docker Compose.

Supporting fully automated backup and restore process requires including container orchestration platform-specific details in X-Road's implementation. Since Kubernetes is the most widely supported container orchestration platform and there are several Kubernetes-based services and products available (e.g., Kubernetes (K8s), Amazon Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS), Google Kubernetes Engine (GKE), Red Hat OpenShift), it has been chosen as the orchestration platform supported by X-Road 8. This means that even if the X-Road Docker images can be run anywhere, there are Kubernetes-specific features that will limit X-Road's ease of use with other orchestrators. For example, deploying the Security Server using some other orchestrator is possible, but the application-level backup/restore features are unavailable, and the administrator must implement the backup/restore using different tools.

Improvements to the signer's scalability

The signer is currently one of the Security Server's known performance bottlenecks. Therefore, the signer architecture and source code have been refactored to improve performance.

The signer has been made more modular by separating signer management and processing signing operations. Signer management is always run in a single instance, and multiple instances can perform signing operations. Nevertheless, it's still possible to run a single signer instance that's responsible for both management and signing. In addition, the implementation has been refactored to allow multiple parallel non-modifying operations (e.g., signing messages) while only one operation at a time was allowed before.

When we started working with X-Road 8, most of the signer code was from 2014-2015, when X-Road 6 was implemented. During the X-Road 8 implementation project, over 30% of the signer code has been changed, and more changes are expected until the work is completed. The new implementation is expected to improve the signer's performance and contribute positively to the overall performance of the Security Server.

Changes to the Security Server add-ons

The Security Server supports add-ons that provide additional features on top of the core functionality, e.g., message logging and environmental and operational monitoring are all Security Server add-ons. In X-Road 7, add-ons are implemented as separate add-on packages that can be installed separately. In X-Road 8, separate add-on packages will be removed, and all add-ons will be packaged with the Security Server core. In this way, Security Server administrators can turn add-ons on/off by updating Security Server's configuration instead of having to install/remove packages. The change simplifies managing add-ons and enables using the same approach in add-on management regardless of the Security Server deployment model (native / container).

Moving configuration data to the database

In X-Road 7, configuration data is stored in the filesystem (e.g., /etc/xroad) and the database. This means that the backup and restore processes must be able to access both locations. It is not an issue when all the components run on the same host and share the same file system. Instead, the situation becomes more complicated when different components are not deployed together, and the configuration files included in the backup don't reside on the same file system. For example, this is the case with X-Road 8 containerised deployment, where every component is deployed in a separate container.

All the possible configuration data is moved from the filesystem to the database to simplify the backup and restore process of the containerised deployment in X-Road 8. This includes configuration properties, signer data, keys, configuration anchor file, etc. Also, PostgreSQL is used as a storage backend for locally deployed OpenBao (OpenBao is used as a secure secret storage in X-Road 8). In this way, the backup of the containerised deployment consists only of the database dump. Instead, in the native deployment, the backup still includes configuration files from the /etc/xroad folder.

New Backup Manager module

In X-Road 8, all the backup and restore-related logic is moved to a new Backup Manager module. The module is present in all deployment types (native, containerised), but the implementation of different operations (e.g., backup, restore) varies between them. For example, in containerised deployments, only configuration data from the database is backed up, while in native deployments, specific configuration files are also included. The module exposes gRPC endpoints for the Admin UI module to trigger backup/restore processes.

In addition, other backup-related tasks that were earlier implemented in different modules have been moved to the Backup Manager module. For example, automatic backup creation has been moved from the Configuration Client module, and automatic removal of old backup files has been moved from the Proxy module.

What about data spaces?

As mentioned earlier, during the first half of 2025, our primary focus has been implementing changes to the existing X-Road architecture. However, that doesn't mean we've forgotten data spaces or haven't been following the latest developments in different data space initiatives. NIIS is a member of the Gaia-X European Association for Data and Cloud AISBL, International Data Spaces Association (IDSA) and Eclipse Dataspace Working Group (EDWG), which makes it an active participant in various data space activities. Also, the goal regarding X-Road and data spaces hasn’t changed – to transform X-Road into a data space technology in a backwards-compatible manner and make X-Road technically interoperable with the Gaia-X Trust Framework.

Meanwhile, different data space-related protocols are evolving and getting closer to their release versions. The Data Space Protocol (DSP) and Decentralised Claims Protocol (DCP) by the EDWG are estimated to reach release version 1 in H2 / 2025. Instead, the DSP submission to become an ISO standard is scheduled for Q4 / 2025. The Eclipse Dataspace Components (EDC) project will implement both protocols, and it's expected to provide a stable implementation of DSP and DCP release version 1 in Q4 / 2025. The schedule is well aligned with the X-Road 8 development since the stable EDC version should be available by the time the X-Road architecture-related changes have been completed.

In addition to DCP, there’s also another protocol for issuing and sharing verified credentials that can be used in the context of data spaces - the OpenID for Verified Credentials (OID4VC) protocol. In the data space community, there’s an ongoing discussion about the protocols and their use for different use cases in various data space initiatives. 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. Nevertheless, we're actively following activities related to the topic and are ready to review and update our plans if needed. For X-Road 8, the main goal is to be interoperable with different data space initiatives and enable cross-data space interoperability. 

What’s next?

 All in all, the development of X-Road 8 is progressing nicely, and we're on track to publish the first production version of X-Road 8 "Spaceship" in 2026, as planned.

Currently, we’re in the first phase of our implementation plan—implementing changes to the existing X-Road architecture. We have also just started to work on updating the Central Server and Security Server UIs according to the X-Road 8 visual style guide. This means that the implemented changes become more visible to the X-Road users since they’re not only about technical and architectural changes under the hood anymore. We expect the current development activities to continue at least until Q4 of 2025. After that we will continue to the second phase - add support for the data space protocol stack and the Gaia-X Trust Framework.

The X-Road 8 beta version will be published in Q4 / 2025. It will include all the architectural changes implemented until then and updated UIs with a new look and feel aligned with the X-Road 8 "Spaceship" visual style. The beta version will allow for testing the Security Server's new, more modular architecture and a new approach to containerised deployments in practice. We would like to receive feedback about the changes from the community to ensure that the implemented changes align with the community's needs and expectations.

 Instead, the beta version will not include new data space-related features yet. Their implementation may start before the beta is released, but it's unlikely they will reach sufficient maturity to be included in the beta. An updated version of the beta—or beta 2—will be released sometime in 2026 so that the X-Road community can test new data space-related changes in practice before the first production release.

 More blog posts about X-Road 8 will follow later this year. Stay tuned!

Making of X-Road 8 - December 2024 Status Update

During the second half of 2024, the X-Road 8 “Spaceship” development continued nonstop after the initial proof of concept (PoC) was completed at the end of May. 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 was yes.

In practice, the answer means that the PoC project didn't discover any significant roadblocks that would make reaching the goal impossible. Instead, it discovered many questions and areas that require further investigation. Since completing the project at the end of May, we have continued to work with the identified questions and challenges and dig deeper into various areas of the implementation.

In this blog post, we explore what has happened after completing the initial PoC project at the end of May.

Changes to the X-Road architecture

X-Road 8 will provide improved cloud compatibility and make using X-Road easier in the cloud. In practice, X-Road 8 will be designed and built to leverage the capabilities and advantages of cloud computing environments. X-Road 8 will be built to run in cloud infrastructures and take advantage of cloud platforms' scalability, flexibility, and resilience. For example, it supports scaling the Security Server on a module level (e.g., signer, proxy) and enables the use of services offered by cloud platforms (e.g., secret storage, configuration management). These goals can only be achieved with changes to the X-Road's architecture.

The aim is to make X-Road more modular so that different modules can be deployed on separate hosts (or containers) and scaled independently. X-Road’s modules are made more loosely coupled, isolated, and configurable to enable this. For example, on a more concrete level:

• Different modules communicate with each other over gRPC interfaces rather than sharing the same data files on the file system.

• Enable the use of external configuration management services instead of storing configuration files locally on the Security Server.

• Migrate configuration from ini files to yaml files.

• Instead of hardcoding the location of other modules in the source code, it's possible to configure each module's address using configuration properties.

Some changes may already be introduced in X-Road 7, and they don't affect existing users. For example, make some currently hard-coded configuration items configurable using the current hard-coded values as defaults.

Better support for containers

 In X-Road 7, the Security Server already supports containerised deployment, but the current implementation has certain limitations. For example, all the Security Server modules are deployed to a single container, and splitting them up into multiple containers is not supported.

In X-Road 8, different Security Server modules will be deployed to separate containers, enabling more flexible deployment and scalability options. For example, scaling out can be implemented by scaling out an individual module causing a bottleneck rather than scaling out the whole Security Server instance.

Although X-Road 8 has made great efforts to provide better support for cloud platforms and containers, it will continue to support the current native Linux-based (Ubuntu + RHEL) deployment options. Therefore, users are not forced to migrate to the cloud and/or containers when upgrading to X-Road 8.

New modules for the Central Server and the Security Server

Designing and implementing the X-Road 8 architecture is still a work in progress, and further changes are to be expected, but some new modules have already been implemented. However, the implementation of the new modules has yet to be on a production level, and some of them have been implemented as mock services. Nevertheless, here's a more detailed description of the new Central Server and Security Server modules.

The new Central Server modules are:

• Catalog Service (xroad-ds-catalog-service)

  • Collects service metadata in Data Catalog Vocabulary (DCAT) format from Security Servers, stores it centrally and provides an API to query the metadata. Similar to the existing X-Road Catalog extension, but the implementation is based on different metadata standards and protocol specifications.

• Credential Service (xroad-ds-credential-service)

  • Issues X-Road compliance (and other) credentials to X-Road member organisations. The credentials are based on the W3C Verified Credentials Data Model v2.0 specification.

• Identity Hub (xroad-ds-identity-hub)

  • Hosts X-Road Operator’s DID document and stores verifiable credentials. Implements the Decentralised Claims Protocol (DCP) specification.

• Secret storage (xroad-secret-store-<local|remote>)

  • Secure storage to store application secrets, e.g., gRPC keys and certificates. Uses a local or remote installation of the OpenBao open-source product.

The new Security Server modules are:

• Control Plane (xroad-ds-control-plane)

  • Service discovery and contract negotiation. Implements the Data Space Protocol (DSP) specification.

• Data Plane (xroad-ds-data-plane)

  • Actual data transfer based on the X-Road Message Transport Protocol.

• Identity Hub (xroad-ds-identity-hub)

  • Hosts X-Road member organisations’ DID documents and stores their verifiable credentials. Implements the Decentralised Claims Protocol (DCP).

• Secret storage (xroad-secret-store-<local|remote>)

  • Secure storage to store application secrets, e.g., gRPC keys and certificates. Uses a local or remote installation of the OpenBao open-source product.

Changes to message signatures

X-Road 7 uses batch signatures to sign all the messages exchanged between X-Road member organisations. The Security Server is responsible for producing and verifying the signatures and logging the messages. Batch signatures perform better than non-batch signatures, but the downside is that they do not fully conform to the eIDAS technical specifications. Therefore, X-Road 8 will support fully eIDAS conformant non-batch signatures and batch signatures. Also, X-Road 8 will support fully eIDAS-conformant ASIC-E containers for archiving the message logs.

Supporting non-batch signatures in X-Road 8 requires changes to X-Road 7 to guarantee interoperability between the two major versions. In other words, backwards compatibility requires adding partial support for non-batch signatures in X-Road 7. In practice, version 7 Security Server must be able to verify non-batch signatures and log all the message parts included in the signature. The required changes are implemented in X-Road version 7.6.0 and don't affect the behaviour or performance of X-Road 7 Security Servers. Thanks to the changes, X-Road 8 will be backwards compatible with X-Road 7 starting from version 7.6.0.

Trust framework

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, we've been looking into migrating the X-Road trust framework from X.509 certificates to VCs and DIDs.

So far, we have implemented an experimental X-Road member credential that can be used to prove that an organisation is a member of a specific X-Road ecosystem. The X-Road operator issues the credential when a new member joins the X-Road ecosystem. Nevertheless, every member organisation still needs a sign certificate issued by a trusted Certificate Authority (CA) since the X-Road member identifier in the credential must match the member identifier in the sign certificate. Also, every member still needs to be able to sign their messages, which is why the sign certificate is still required. Instead, the credential can be used to authenticate members during data transactions and control access to services.

At first glance, the X-Road member credential doesn’t provide much new compared to the existing sign certificate. However, the data space protocol stack is leaning towards credentials, which is why X-Road 8 should also support them. In addition, supporting credentials opens many new opportunities for X-Road. The use of credentials doesn't have to be limited to the X-Road member credential, and there could be various other credentials, too.

For example, the X-Road operator could conduct automated port scanning of all the Security Servers registered in the ecosystem and issue a security credential to every Security Server that meets the security requirements. In this way, X-Road member organisations could prove to other members that their Security Server meets the security requirements of the ecosystem and that information could be utilised when granting access to services. In addition, credentials could also be issued by other parties and not just the X-Road operator, which increases the number of possibilities significantly.

What’s next?

During the second half of 2024, the main focus of X-Road 8 development activities was X-Road-related topics. In addition, we are continuously working with the Eclipse Dataspace Components (EDC). Still, the work is more about better integrating the EDC into X-Road, utilising its extensibility and applying its concepts rather than working on implementing the Data Space Protocol (DSP) or the Decentralised Claims Protocol (DCP). When it comes to implementing the data space protocol stack, X-Road is utilising the implementation coming from the EDC master repository. Also, we’re continuously evaluating the development of the data space protocol stack and considering available options for the different layers of the stack. For example, on the trust layer, X-Road is currently using the DSP, but we’re also looking into OpenID for Verifiable Credentials (OID4VC) as a potential alternative.

Many of the topics discussed in this blog post are very complex and wide, and therefore, we will continue to work on them in the near future. None of the areas have a production-level implementation available yet, so there's still plenty of work to be done. Also, there are several areas that we haven’t even looked into yet, e.g., federation, operational, and environmental monitoring.

The changes in X-Road 8 are not limited to protocols and technical changes under the hood. Instead, the Central Server and Security Server UIs will be updated, too. The main logic of the UIs will remain the same, but they will have a new look and feel aligned with the X-Road 8 "Spaceship" visual style. The new UIs will probably be introduced when the X-Road 8 beta version is published in 2025.

More blog posts about X-Road 8 will follow in 2025. Stay tuned!

X-Road 7.6.0 Is Here

During the second half of 2024, the development of X-Road 8 “Spaceship” and X-Road 7 “Unicorn” has continued in parallel. Dividing the available development resources between two major versions isn't easy, but despite that, both versions have gained good progress. Also, some minor technical changes under the hood initially implemented for X-Road 8 have already been included in X-Road 7. Nevertheless, this blog post focuses on the latest changes in X-Road 7. Instead, there will be another blog post about the latest news regarding X-Road 8 soon.

X-Road version 7.6.0 is released in December 2024. Let’s see what the new version highlights are! The full release notes are available here.

Support for automatic renewal of authentication and sign certificates

Since version 7.5.0, automating the Security Server authentication and sign certificate management using the Automatic Certificate Management Environment (ACME) protocol has been possible. However, the initial support didn’t cover automatic certificate renewal, which has now been added to version 7.6.0.

Starting from version 7.6.0, authentication and sign certificates issued by a CA that supports ACME can be automatically renewed. Automatic renewal is enabled by default, but the Security Server administrator can turn it off.

The Security Server runs the renewal job regularly and tries to renew certificates ready for renewal. If the server supports the ACME ARI extension, the time when a certificate is ready for renewal is determined by the ACME server. Otherwise, the time is defined by a configuration property on the Security Server. The default value of the property is 14 days, which means that the Security Server starts trying to renew a certificate 14 days before it expires. The Security Server administrator can change the value.

After a certificate has been renewed, it still needs to be activated on the Security Server. The Security Server starts using the new certificate only after activation. In version 7.6.0, activating a certificate is a manual process that needs to be done by the Security Server administrator. Support for automatic activation will be added in version 7.7.0. Instead, the authentication certificate registration request is sent automatically when an authentication certificate is renewed using ACME. In this way, activating the certificate is the only manual step required after a successful certificate renewal. If email notifications are enabled, the administrator receives an email notification when a certificate is ready for activation.

More details are available in the Security Server User Guide.

Support for sending email notifications

Starting from version 7.6.0, the Security Server supports sending email notifications on ACME-related events. Notifications are sent in case of authentication and sign certificate renewal success and failure and authentication certificate registration success. They are sent to a member-specific email address defined by the Security Server administrator in a specific configuration file on the Security Server.

Success and failure notifications can be turned on and off separately with their configuration properties. By default, both notifications are enabled. However, for the email notifications to work, an external mail server needs to be configured, and the Security Server must be able to communicate with it. The configuration can be tested using the Security Server's Diagnostics view, which provides a feature for sending test emails. The configuration details are available in the Security Server User Guide.

Support for Elliptic Curve Cryptography (ECC)

Before version 7.6.0, X-Road only supported RSA cryptography for the Security Server authentication and sign keys, as well as for signing and verifying the global configuration. Starting from version 7.6.0, Elliptic Curve Cryptography (ECC) and ECDSA keys are also supported. To guarantee full backwards compatibility with the previous X-Road versions, support for ECC keys is disabled by default, and it must be enabled separately for different features, e.g., authentication keys, sign keys, and signing global configuration. More information about switching to ECC is available in the Security Server User Guide and Central Server User Guide.

Support for multiple languages

Over the years, support for additional languages besides English has been requested frequently. Starting from version 7.6.0, the Central Server and Security Server UIs support multiple languages. The default language is still English, but the user can select any available languages using the language menu in the UIs. The additional supported languages are Spanish for the Central Server and the Security Server, and Estonian for the Security Server. The technical implementation for the support and the additional languages were received as contributions from the community. Thank you to the contributors – your effort is highly appreciated!

Remove support for Ubuntu 20.04 LTS and Red Hat Enterprise Linux 7 (RHEL7)

Starting from version 7.6.0, the Central Server, Security Server, and Configuration Proxy support Ubuntu 22.04 LTS and 24.04 LTS, while support for Ubuntu 20.04 LTS has been dropped. Instead, the Security Server also supports RHEL8 and RHEL9, while support for RHEL7 has been dropped. If you need to upgrade from Ubuntu 20.04 LTS or RHEL7 to a newer OS version, the X-Road Knowledge Base provides multiple migration guides.

Other improvements and updates

Besides the already-mentioned features, version 7.6.0 includes many other minor improvements and updates. For example, support for collecting operational monitoring data on the REST endpoint level, showing more information about information system TLS certificates in the subsystem internal servers view on the Security Server, support for logging the Common Name (CN) field of the client certificate used by a consumer information system, and upgrade from Java 17 to Java 21.

In addition, version 7.6.0 adds support for verifying and logging messages with non-batch signatures, while batch signatures continue to be used by default. Instead, X-Road 8 will also support generating non-batch signatures, and therefore, being able to verify and log them is required for X-Road 7 to be interoperable with X-Road 8. In other words, based on current knowledge, X-Road 7 is interoperable with X-Road 8 starting from version 7.6.0.

To fully understand all the changes in version 7.6.0, please review the release notes document.

What’s next? 

Version 7.7.0 will support automatic activation of authentication and sign certificates that have been renewed using ACME. Other changes that will be introduced in version 7.7.0 include but are not limited to, support for defining a full name for subsystems, support for removing HSM tokens using the Security Server UI and REST management API, support for disabling all subsystems of a Security Server together and putting a Security Server in a maintenance mode. Version 7.7.0 will be released during Q2 in 2025.

At the same time, when developing X-Road 7, NIIS continues to work on the next X-Road major version – X-Road 8 “Spaceship”. More news regarding X-Road 8 will be published regularly. Stay tuned!

X-Road 7.5.0 Is Here

During the first half of 2024, the focus on X-Road development shifted towards X-Road 8 “Spaceship”, and we've put much effort into X-Road 8-related development activities. Nevertheless, X-Road 7 hasn't been forgotten either, and we've worked on various improvements included in X-Road 7.5.0, released at the beginning of July. Let’s see what the highlights of the new version are! The full release notes are available here.

Support for automated authentication and sign certificate management

Until now, managing the Security Server authentication and sign certificates has been an entirely manual process. The Security Server administrator must create a new key pair, generate certificate signing requests (CSRs), send the CSRs to a Certificate Authority (CA) for signing, import and configure the issued certificates. Depending on the X-Road ecosystem and the CA, completing the whole process may take several days.

Starting from version 7.5.0, the Security Server authentication and sign certificate management can be automated using the Automatic Certificate Management Environment (ACME) protocol. At this point, the automation covers the most time-consuming part of the process – sending the CSR to the CA for signing, issuing the certificate and importing it to the Security Server. In other words, the Security Server administrator still needs to create a new key pair manually, provide the information included in the CSR, start the ACME process and activate the imported certificate. However, the whole process is now completed in minutes instead of days.

Using ACME on the Security Server requires at least one available CA that supports the ACME protocol. The X-Road Operator defines the CAs supporting ACME on the Central Server. In addition, depending on the CA, using ACME may require additional configuration on the Security Server, e.g., using ACME requires authentication, and the authentication credentials must be added to the Security Server’s configuration. The configuration is member-specific. The Security Server documentation provides more detailed information about the required configuration. Please note that the configuration may vary between CAs and X-Road ecosystems. Therefore, always consult your own X-Road Operator in ACME-related questions.

The ACME HTTP challenge communication port is one configuration detail shared between different CAs and X-Road ecosystems. According to the ACME protocol, the ACME server communicates with the Security Server using port 80 when verifying the ownership of the domain included in the certificate using the HTTP challenge. Therefore, the Security Server must allow incoming connections to port 80 from the ACME server. Similarly, outgoing connections from the Security Server to the ACME server must also be allowed. All the required firewall configurations can be found in the Security Server installation guide.

In version 7.4.0, the default client information system inbound communication ports on Ubuntu-based security servers were changed from 80 to 8080 and 443 to 8443. Instead, the port must be manually changed before using ACME on older Ubuntu-based Security Servers, where port 80 is still used as a client information system inbound communication port.

Version 7.5.0 doesn’t yet support automatic renewal of authentication and sign certificates using ACME, but this support will be added in version 7.6.0. In version 7.5.0, the renewal must be initiated manually by the Security Server administrator, but starting from version 7.6.0, the Security Server will try to renew the certificates automatically before their expiration date.

Support for Ubuntu 24.04 LTS

Starting from version 7.5.0, the Central Server, Security Server, and Configuration Proxy support the latest Ubuntu 24.04 LTS version. The support includes installation packages and instructions for fresh installation and migration from Ubuntu 22.04 LTS. In addition to version 24.04 LTS, versions 22.04 LTS and 20.04 LTS are also supported. However, Ubuntu 20.04 LTS is only supported to provide an easier upgrade path to Ubuntu 24.04 LTS. It’s strongly recommended that production environments use Ubuntu 22.04 LTS or Ubuntu 24.04 LTS.

Support for Red Hat Enterprise Linux 9 (RHEL9)

Starting from version 7.5.0, the Security Server supports the latest RHEL9 version. The support includes installation packages and instructions for fresh installation and migration from RHEL7 and RHEL8. In addition to RHEL9, RHEL8 and RHEL7 are also supported. However, RHEL7 is only supported to provide an easier upgrade path to RHEL9. It’s strongly recommended that production environments use RHEL8 or RHEL9.

Adding/removing Central Server cluster nodes

The Central Server cluster node connection details are included in the configuration anchor imported to the Security Server. Using the information in the anchor, the Security Server can connect to the nodes. Suppose cluster nodes are added/removed. In that case, a new configuration anchor must be generated on the Central Server, distributed to all the Security Server administrators through an external channel (e.g., email), and imported to each Security Server. Only after that are the changes applied by each Security Server.

Starting from version 7.5.0, the Central Server cluster node connection details are included in the global configuration. Thanks to this, adding/removing cluster nodes is possible without importing a new version of the configuration anchor to each Security Server. Instead, the Security Server gets the updated configuration information from the global configuration directly and applies it immediately.

However, the changed cluster node details are not updated to the configuration anchor on the Security Server. Instead, the information is only present in the global configuration. Suppose the Security Server's local copy of the global configuration expires. In that case, the Security Server returns using the connection details from the local configuration anchor – potentially the one uploaded to the Security Server when it was originally initialised. Therefore, if the Security Server's local copy of the global configuration is expired, importing a new version of the configuration anchor is required if the current connection details don't include any Central Server node from the local configuration anchor (=the address of every Central Server node has changed since the Security Server was initialised).

The same logic applies to rotating global configuration sign keys included in the global configuration since version 7.4.0. The new sign keys are not updated to the configuration anchor stored on the Security Server. Instead, they're only present in the global configuration.

Security Server Sidecar instructions for Microsoft Azure

The Kubernetes Security Server Sidecar User Guide and Kubernetes Security Server Sidecar Security User Guide have been updated to provide instructions on running the Security Server Sidecar using Azure Kubernetes Service (AKS). The user guides now cover AKS and Amazon Elastic Kubernetes Service (Amazon EKS).

Other improvements and updates

Besides the already-mentioned features, version 7.5.0 includes many other minor improvements and updates. For example, improve warning messages when adding new OpenAPI services to the Security Server, improve dialogue navigation in the Central Server UI, allow defining additional options for PostgreSQL CLI tools used in the Security Server and Central Server processes, bump the Security Server sidecar Docker images to Ubuntu 24.04, and many more. To fully understand all the changes, please review the release notes document.

What’s next?

Version 7.6.0 will support the automatic renewal of authentication and sign certificates using ACME. Other changes that will be introduced in version 7.6.0 include, but are not limited to, support for defining a full name for subsystems, support for getting operational metrics on a REST service endpoint level (not just on a service level), support for Elliptic Curve (EC) cryptography. Version 7.6.0 will be released during Q4 in 2024.

At the same time, when developing X-Road 7, NIIS continues to work on the next X-Road major version – X-Road 8 “Spaceship”. Updates regarding X-Road 8 development are published regularly. Stay tuned!

Making of X-Road 8 – PoC June Status Update

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:

• January

• February

• March

• April

• May

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 Decentralized Claims Protocol (DCP)

• Data Rights Policies Profile (DRP)

• 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!

Making of X-Road 8 – PoC May Status Update

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.

Image 1. The dataspace protocol layers.

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!

Making of X-Road 8 – PoC April Status Update

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.

Support for the standard dataspace protocol

Since the March update, we have continued to work with message signing, logging and service catalog.

Message signing

In March, support for message signatures was already implemented in the PoC. The implementation utilises the Digital Signature Services (DSS) Java library provided by the European Commission. Initially, the PoC implementation used the JSON-based JAdES-B-LT signatures instead of the XML-based XADeS signatures used by X-Road 7.

In April, the signing implementation was reverted to the XML-based XADeS signatures. The change was because the Security Server produces ASiC-E containers that contain archived message log records. Unfortunately, according to AsiC-E specifications, only XadES and CAdES signatures are supported. Instead, according to the DSS library documentation, the CAdES signatures do not support signing multiple documents, which the Security Server requires when signing REST messages since the message body and HTTP headers are signed separately. Therefore, the only remaining option was to use the XAdES signatures already used in X-Road 7.

The downside of the XAdES signatures compared to the JAdES-B-LT signatures is that they’re more complicated to implement and require more space, affecting performance. However, the good thing is that keeping the message log functionality backwards compatible is easier since X-Road 7 also uses the XAdES signatures.

Another factor that affects the performance is the lack of support for batch signatures by the DSS library. However, that doesn’t directly depend on the used signature algorhithm. Instead, X-Road 7 supports batch signatures, but the implementation includes some non-standard X-Road-specific steps that DSS does not cover. And why would it cover them since the customisations are X-Road-specific?

The aim is to get rid of non-standard X-Road-specific details in X-Road 8. Therefore, in the PoC, each message is signed separately, negatively impacting the Security Server performance. However, updating the signer implementation may resolve the performance issues or at least reduce the impact. Therefore, evaluating and redesigning the signer architecture and implementation is a high priority in the X-Road 8 backlog.

Message logging

Once the signature algorithm has been reverted to XAdES, the PoC project can support message logging. This means messages sent using the standard data space protocol can be logged just like those sent using X-Road 7. However, there's at least one remaining issue with logging that's related to batch timestamping. 

Batch timestamping works so that messages processed by the Security Server are timestamped in groups according to the interval defined in the Security Server’s configuration (by default, once in a minute). When batch timestamping is executed, all the messages that have been processed since the previous timestamping transaction and haven't been timestamped yet are timestamped as a single group. Batch timestamping works asynchronously in the background and doesn't directly affect the message throughput.

In X-Road 8, the aim is to replace the current batch timestamping implementation with the DSS library. The issue with the current implementation is that it includes some non-standard X-Road-specific steps. However, it should be possible to make the batch timestamping implementation conform to the ASiC-E specifications using DSS, but some changes to the current implementation are required. Nevertheless, those changes are outside the PoC's scope and will be implemented after the PoC. Therefore, the current batch timestamping implementation is used in the PoC.

Service catalog 

The standard dataspace protocol defines a catalog protocol that can be used to query metadata about available assets from a service provider. The metadata includes information about datasets and usage control policies. The protocol uses Data Catalog Vocabulary (DCAT) v3 to define datasets while usage control is expressed as Open Digital Rights Language (ODRL) policies.

Federated Catalog is an EDC component that utilises the catalog protocol to collect metadata from different service providers and store it centrally. In that way, the metadata of all the services provided by various service providers is available from a single place. However, the Federated Catalog doesn’t provide a web UI to access the data. Instead, the data can only be accessed over an API, enabling alternative presentation layers to be built.

The Federated Catalog is very similar to the X-Road Catalog component. The X-Road Catalog is an X-Road extension that collects information on members, subsystems and services from an X-Road ecosystem and provides REST and SOAP interfaces to access the data. The X-Road Catalog uses the X-Road service metadata protocol to access the information stored on Security Servers. Currently, X-Road services are described using WSDL and OpenAPI specification.

In April, we deployed the Federated Catalog component to understand better how describing services could work in X-Road 8 and the relationship between DCAT, WSDL and OpenAPI specification. The catalog protocol provides metadata about services using DCAT, while the X-Road service metadata protocol provides detailed API specifications using WSDL and OpenAPI specification. Therefore, DCAT is not a replacement for WSDL and OpenAPI specification. Instead, they rather complement each other. Also, DCAT supports a property for endpoint descriptions that can be used to reference external service descriptions. The property can be used to create a link from DCAT to existing WSDL and OpenAPI service descriptions.

By default, the Federated Catalog supports only a limited amount of DCAT properties. Fortunately, enriching the catalog response with additional DCAT properties is supported. However, implementing a custom data mapper is required, which could affect interoperability with other connectors that do not support the customisations. Therefore, extending the supported DCAT properties and how they affect interoperability requires further studying during the subsequent phases of X-Road 8 development.

Also, having separate components for collecting DCAT, WSDL and OpenAPI specification documents from the ecosystem is not optimal. Instead, combining the Federated Catalog and X-Road Catalog into one component is a better approach.

Support for Gaia-X trust framework

Already in March, we had set up an internal instance of the Gaia-X Digital Clearing House (GXDCH) services to have more flexibility. The instance includes Gaia-X Registry, Gaia-X Compliance, Gaia-X Notary and Gaia-X Wizard. Also, we had 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. Since then, we’ve been able to issue Gaia-X credentials that we can use for testing purposes.

Support for the Identity Hub

Supporting the Gaia-X trust framework requires that X-Road member organisations have a credential repository (such as a digital wallet) for storing Verified Credentials (VCs) and sharing Verifiable Presentations (VPs). When an organisation becomes a Gaia-X participant, a Gaia-X Compliance Credential is issued to the organisation by the Gaia-X Compliance Service. The organisation stores the credentials in its credential repository. Instead, when the organisation needs to prove that it's a Gaia-X Participant (e.g., authentication during a data transaction between participants), it generates a VP that includes the Gaia-X Compliance Credential and shares it with a verifier (e.g., a data exchange partner). Identity Hub is an EDC component that stores VCs and composes VCs into VPs.

In the EDC sample implementation, Minimum Viable Dataspace (MVD), Identity Hub and connector are embedded in a single component. In the case of X-Road, it meant that the Identity Hub was embedded in the Security Server. To make the implementation more modular, we split the Identity Hub into a separate component that communicates with the Security Server over interfaces.

In the PoC, each Security Server must have its own Identity Hub instance. However, the plan is to support sharing the same Identity Hub instance between multiple Security Servers in the future. In this way, a member organisation may have one Identity Hub instance or an Identity Hub cluster that’s shared by all the Security Servers used by the organisation.

The Identity Hub does not currently support participant onboarding, the protocol to issue VCs. According to the information in the EDC’s Discord channel, planning and designing the implementation should begin during the second half of 2024. Therefore, in the PoC, VCs are created using other tools and stored manually in the Identity Hub.

Using VCs in data exchange

The PoC aims to use VCs and VPs in data exchange to authenticate the message exchange parties and authorise access to services. The MVD provides a sample implementation, but it's currently based on older EDC and Gaia-X trust framework versions. Therefore, changes were required to support the latest EDC and Gaia-X trust framework versions.

Making the latest EDC version (0.6.2) work with the latest Gaia-X trust framework version has been more challenging than expected. This is because many of the technologies used in the implementation are relatively new to the PoC team and because the aim is to integrate the technologies into X-Road. In addition, we have discovered some bugs that have slowed the progress.

For example, we experienced an issue with VC verification – the EDC failed to verify VCs issued by the Gaia-X Compliance Service. It turned out that a transitive dependency used to normalise JSON-LD documents in the EDC had a bug in the normalisation algorithm that caused the normalisation to produce incorrect results. Consequently, the verification always failed for VCs created using another library. Fortunately, the solution was as simple as bumping the transitive dependency to the latest version, where the problem is already fixed. However, debugging the issue and discovering the root cause was time-consuming.

What’s next?

The main challenge continues to be integrating the Gaia-X trust framework with the EDC-based X-Road 8 Security Server. The integration includes looking into supporting X-Road's current trust framework and Gaia-X trust framework in parallel since backwards compatibility is required.

Even if the main challenge continues to be the same as in March, the PoC has gained a lot of progress in April. Currently, the PoC is not far from utilising Gaia-X credentials for authentication and authorisation during data exchange. However, we're talking about an initial implementation that is not production-ready. In the PoC, the aim is to have an implementation that works, but several things may still be missing, e.g., proper verification and validation of credentials. Once a working implementation is available, the focus will shift to the backward compatibility of the trust framework. Regardless of minor delays, we’re confident that the main goals will be achieved within the project timeline - by the end of May.

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