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!