Data spaces are a hot topic right now in the field of data exchange and interoperability. However, it's not a new concept since its roots date back to 2005. The original definition was somewhat technical, but over the years, the term has expanded to cover all four layers of interoperability defined by the European Interoperability Framework (EIF).
Today, the term data space has several different definitions depending on whom you ask. Multiple international initiatives are working on data spaces to create common governance models, specifications, reference implementations, etc. Let's look at the definitions created by some of those initiatives.
”An infrastructure that enables data transactions between different data ecosystem parties based on the governance framework of that data space. Data space should be generic enough to support the implementation of multiple use cases.”
Source: Data Spaces Support Centre - DSSC Glossary - Version 1.0
”Decentralised, governed and standard-based structure to enable trustworthy data sharing between the data space participants on a voluntary basis. Data spaces may be purpose- or sector-specific, or cross-sectoral. Common European data spaces are a subset of data spaces within the scope of EU policies.”
Source: Gaia-X Glossary
”A Dataspace is a set of technical services that facilitate interoperable asset sharing between entities.”
Source: IDS Dataspace Protocol v0.8
”A data space is a federated data ecosystem within a certain application domain and based on shared policies and rules.”
Source: Sitra Rulebook for a Fair Data Economy
”A common European data space brings together relevant data infrastructures and governance frameworks in order to facilitate data pooling and sharing.”
Source: Commission Staff Working Document on Common European Data Spaces
When looking at the definitions, it’s clear that they are defining the same subject even though they’re approaching it from different angles. Also, it’s evident that data spaces are more than a technology since governance and policies play a significant role in the definitions.
The first version of X-Road was released in Estonia in 2001 – four years before the term data space appeared in an article for the first time. The technical implementation of X-Road has evolved and changed over the years, but the main concept has remained the same since the beginning. Also, X-Road is not only about technology; it also has an organisational model and trust framework. When comparing X-Road to the data space definitions, it’s easy to find many common factors and similarities. In fact, the definitions could very well be used to describe X-Road on a high level. But does that make X-Road a data space technology?
To answer the question, digging deeper into data spaces is necessary. Let's look at more detailed documentation and specifications to see how well X-Road is aligned with them.
The International Data Spaces Association
The International Data Spaces Association (IDSA) is a not-for-profit organisation aiming to create a global standard for international data spaces (IDS) and foster the global data spaces community. IDSA provides several data spaces related assets, for example:
Let’s study some of the assets provided by the IDSA and see how well X-Road is aligned with them. However, this will not be a complete comparison between the IDSA assets and X-Road. Instead, only selected parts of specific assets will be reviewed to highlight similarities and differences. Studying the source materials is recommended if you're interested in the topic in more detail.
Data space fundamentals
The IDS Rulebook defines foundational concepts of data space that seem to apply to X-Road on a high level:
Establishing trust
Data discoverability
Data contract negotiation
Data sharing & usage
Observability
Vocabularies and semantic models.
The IDS Rulebook and X-Road have the same vision of enabling data sovereignty and creating a trusted data-sharing ecosystem. They’re both based on the idea that trust is rooted in one or more trust anchors, trusted participants must meet specific policies that can vary between different ecosystems, and data sharing consists of peer-to-peer interactions between the participants.
Policies play an essential role in any data ecosystem. The IDS Rulebook defines multiple policy groups and the relationships between them. The same policy groups apply to X-Road, too, with the difference that X-Road doesn't define the structure and relationship of the policies or offer tools to express them. For example, the IDS specifications cover defining usage and contract policies and negotiating them as a part of the data exchange process. In X-Road, it’s up to the data exchange parties to agree on those policies using some external channel, e.g., email or service catalogue. Also, X-Road supports managing access to services. Still, the access policies are not technically associated with any other policies since the other policies are created and maintained outside of X-Road.
Operating models
Image 1. Data space operating models. Source.
The IDS Rulebook defines three different operating models for data spaces:
Centralised data space authority
Federated / distributed data space authority
Decentralised data space authority.
In the context of X-Road, the data space authority is equal to the X-Road Governing Authority. X-Road supports centralised and federated authority. Centralised authority is the most typical alternative for X-Road, and it's the model that a single X-Road ecosystem uses. Instead, when two X-Road ecosystems are federated, the responsibility can be considered distributed between the authorities of the federated ecosystems. However, even in a federated setup, the authorities only have control over their ecosystem.
Conceptual model
Image 2. Data space conceptual model. Source.
The conceptual model defined by the IDS Dataspace Protocol is very similar to X-Road’s conceptual model. Doing a mapping between the models is straightforward:
Dataspace – X-Road Ecosystem
Dataspace Authority – X-Road Governing Authority
Participant – Member
Participant Agent – Security Server
Identity Provider – Certificate Authority
Credential Issuer – N/A
Dataspace Registry – Central Server, Service Catalogue
The descriptions of the organisational entities (Dataspace Authority, Participant, Identity Provider) are pretty well aligned. Instead, there are differences in the descriptions of the technical entities (Participant Agent, Dataspace Registry). The technical differences are covered in the Components section.
Components
Image 3. Interaction between data space components. Source.
Comparing the components provides a good overview of the similarities and differences between the IDS-RAM and X-Road from a technical perspective. The IDS Identity Provider is not actively involved in the data exchange process, so it's omitted from the illustration.
IDS Identity Provider
The IDS Identity Provider consists of three complementary components:
Certificate Authorities (CAs) issue and manage technical identity claims.
The Dynamic Attribute Provisioning Service (DAPS) issues short-lived tokens providing information about Connectors.
The Participant Information Service (ParIS) provides business-related details on Participants.
The IDS Identity Provider combines X-Road's Certificate Authority and Central Server. In X-Road, the roles of the CA and DAPS are combined since Member and Security Server-related information is included in the certificates. At the same time, the IDS Identity Provider decouples the certificate and the associated information. In that way, it's possible to alter the attributes of a certificate, e.g., attach new attributes to a certificate, without reissuing the certificate.
In X-Road, the Central Server stores some business-related information about Members. In addition, the Service Catalogue is a complementary X-Road component that may provide additional information about Members. Therefore, the Central Server and Service Catalogue are equal to the ParIS.
IDS Metadata Broker
The IDS Metadata Broker is basically a registry of IDS Connectors, their capabilities, characteristics, and metadata of the data they offer. The IDS Metadata Broker provides endpoints for registering, publishing, maintaining, and querying the metadata. The X-Road Central Server has a similar role as a registry of Members and Security Servers, with the difference that the Central Server doesn't store any information about the data or services offered by Security Servers. Instead, the Service Catalogue is an optional X-Road component that provides information about the data and services.
IDS Connector
The IDS Connector is the point of access to a data space, providing standardised data exchange between Participants. The IDS Connector is connected to all the other data space components since it provides data and metadata to them. For example, the IDS Connector provides technical interface description, authentication mechanism, and associated data usage policies to the Metadata Broker and usage contracts to the Clearing House. Also, several other IDS components (App Sore, Metadata Broker, and Clearing House) are based on the IDS Connector architecture.
In X-Road, the component that provides access to an X-Road ecosystem is the Security Server. Like the IDS Connector, the Security Server provides secure and standardised data exchange between Members. The Security Server communicates with all the other components of an X-Road instance – either directly or indirectly.
IDS Clearing House
The IDS Clearing House provides a logging service that records relevant information for clearing, billing and usage control. For example, the information is used to provide a settlement service based on usage contracts which can help to automate payments between the data exchange parties. In addition, the logged usage control data can be used to validate access to resources. Technically, the IDS Clearing House consists of an IDS Connector.
X-Road doesn’t have a component that would be a direct match with the IDS Clearing House. However, the optional X-Road Metrics component provides some similar capabilities, e.g., collecting service usage statistics that can be used to automate payments, collecting service statistics. In addition, the Security Server provides a digitally signed and timestamped log record of each data exchange transaction that can be used to validate the transaction afterwards. However, the data exchange parties store the log records locally, and no third parties have access to them.
IDS App Store
The IDS App Store is a platform to distribute IDS Apps for IDS Connectors. Currently, X-Road doesn’t have a similar component.
IDS Vocabulary Hub
The IDS Vocabulary Hub is a vocabulary management platform for IDS use cases. It’s a platform to host, maintain, publish, and document vocabularies. It gives access to the vocabulary terms and their descriptions. The IDS Information Model is the lowest common denominator and can be extended with additional vocabularies. The IDS Vocabulary Hub communicates with IDS Connectors and infrastructure components.
The X-Road architecture doesn’t include a vocabulary component, but it goes without saying that interoperable data exchange requires semantic interoperability. Therefore, it’s up to the X-Road Governing Authority and data exchange parties to agree on where and how vocabularies are managed and stored. For example, the Finnish Digital Agency has developed an Interoperability Platform that can be used to maintain and publish common terminologies.
Conclusions
After comparing data spaces and X-Road from various aspects, they have a lot in common on a high level. However, looking into the details shows that they also have many differences.
For example, the IDS specifications cover various aspects of data exchange, e.g., usage conditions and policies, contract negotiation, and data transfer process. They do not set restrictions to the data transfer protocol or wire protocol – the protocol used to transfer the data. In other words, any existing transfer protocol can be used, which enables using existing solutions and supporting many different transfer protocols. This is a big difference compared to X-Road, which has its own transfer protocol. Also, X-Road doesn’t technically cover the before-mentioned aspects (usage conditions and policies, contract negotiation) covered by the IDS specifications.
Let's return to the original question – can X-Road be considered a data space technology? The answer is no if X-Road is strictly compared to the IDS specifications, despite the similarities. The IDSA has a certification scheme for the IDS components, and X-Road would not meet the certification requirements. The IDS Testbed is a platform that can be used to conduct evaluations that ensure that an IDS component is implemented securely and conform to the relevant specifications. Components that pass the evaluation receive certification and are approved in the IDS ecosystems.
On the other hand, the European Commission considers data exchange ecosystems to be data spaces even if they are not based on technologies conforming to the IDS specifications, for example, the Once-Only Technical System (OOTS) and European Health Data Space (EHDS). Those ecosystems align with the common definition and characteristics for data spaces, but the technologies they use in the implementation do not conform to the IDS specifications. With the same logic, an X-Road ecosystem could also be considered a data space.
Multiple organisations and initiatives are developing specifications and standards for data spaces, e.g., International Data Spaces Association (IDSA), Gaia-X, and Fiware. The initiatives work together, aiming to keep the specifications and standards aligned and not create multiple overlapping or competing specifications. However, the work is currently in progress, and not everything is fully ready and aligned yet. Therefore, it might be too early to define what is a data space and what’s not based on the deliverables of a single actor. Nevertheless, in the long-run, common standards and specifications are the only way to achieve interoperability within and between data spaces.