X-Road 8 Data Spaces vs. X-Road 7 investigation

Scope: Comparison of xroad-develop (X-Road 8, develop branch, HEAD 001cb50ef3) against xroad-7 (tag 7.8.1, commit e93072e680), focused on data-spaces support, and its relationship to the GovStack Information Mediator building block specification (https://specs.govstack.global/information-mediator ).

Status caveat: X-Road 8 is unreleased and under active development on develop. The dataspace subsystem is opt-in and disabled by default (Helm replicas: 0, dataspace.enabled=false). Some integration points (notably "transparent" consumer-side routing) are still maturing and are documented here from code, not yet from published protocol specs. Treat this as a snapshot of intent and current implementation, not a final released contract.

1. Executive Summary

X-Road 7 (and the GovStack Information Mediator spec, which is modelled on X-Road 7) is a decentralized secure data exchange system: each organization's Security Server mediates service calls and responses between information systems, and data exchange happens directly between organizations' Security Servers as synchronous RPC — there are no intermediaries or message persistence in the data path. Trust and service discovery are centrally governed through a Central Server's global configuration, but the Central Server is never in the message flow itself. Identity is X.509 certificate-based; addressing uses the hierarchical X-Road identifier (instance/memberClass/member/subsystem/service).

X-Road 8 keeps all of that intact and layers a data space on top of it, implemented with the Eclipse Dataspace Components (EDC) 0.17.0 stack. It adds:

• Three new standalone services — Control Plane (ds-control-plane), Identity Hub (ds-identity-hub), and Issuer Service (ds-issuer-service) — plus a new proxy module (proxy-dsp-core).

• The Dataspace Protocol (DSP, 2025-1) for catalog discovery, contract negotiation, and transfer orchestration between participants.

• The Decentralized Claims Protocol (DCP) with W3C Verifiable Credentials and did:web Decentralized Identifiers as a second, claims-based trust layer alongside X.509.

• Mapping of existing X-Road services into EDC assets/catalog/policy sourced read-only from the existing serverconf/globalconf.

Crucially, X-Road 8 is backwards compatible: the classic message protocol is unchanged, dataspace is additive and off by default, and services are still addressed by X-Road identifiers (internally encoded as EDC asset IDs).

Implication for GovStack: the Information Mediator spec today describes the X-Road 7 world (REST/OpenAPI over the security server, certificate trust, central directory). It contains no notion of data spaces, DSP, verifiable credentials, DIDs, or federated catalogs. X-Road 8 introduces an entirely new interoperability paradigm that the current IM spec does not cover — see Section 6.

2. Structural Diff: What's New in the Tree

The ds-control-plane itself bundles sub-modules: ds-xroad-catalog (assets from serverconf), ds-xroad-control-plane-policy (X-Road ODRL constraints), ds-xroad-asset-access-api (negotiation/transfer orchestrator + gRPC), ds-xroad-dataplane-registrar (registers the proxy as the EDC data plane), ds-control-plane-db(EDC SQL stores), and ds-control-plane-tasks-store-poll-executor (task-based state machines).

3. Architecture: How Data Spaces Work in X-Road 8

3.1 The two trust/transport models side by side

X-Road 7 / classic (still present in 8):

Open

X-Road 8 dataspace overlay (opt-in):

Open

Note: In the Xrd-PULL transfer type, the "data plane" IS the existing X-Road mTLS serverproxy endpoint — the actual payload still flows over the classic signed/mTLS pipeline.

3.2 The three new services

• Control Plane (ds-control-plane) — Quarkus + EDC 0.17.0 connector. Orchestrates DSP. Exposes a management API, a DSP endpoint (/api/dsp), a control endpoint, and a gRPC asset-access service the proxy calls. Catalog/assets/policies are read-only projections of the existing X-Road serverconf + globalconf(XRoadServerConfCatalogExtension), so providers don't maintain a separate catalog — their registered services are the catalog (cached, default TTL 60s).

• Identity Hub (ds-identity-hub) — EDC Identity Hub. Manages per-participant did:web DIDs, stores credentials, and runs a Secure Token Service. A custom extension (XRoadClaimSignerExtension) signs an X-Road MemberId claim into each issued token using the member's X-Road sign key via the existing signer service over gRPC — binding dataspace identity to X-Road PKI identity.

• Issuer Service (ds-issuer-service) — Issues longer-lived X-Road Membership Verifiable Credentials (JWT format), again signed through the X-Road signer.

3.3 Standards / libraries adopted (all new in 8)

3.4 Data space concepts explained — purpose, DSP mechanics, and comparison to X-Road

The Dataspace Protocol (DSP) introduces a set of concepts that enable policy-governed, contract-based data sharing between autonomous organizations. Below, each concept is explained on its own terms, then mapped to what X-Road already does and what's different.

3.4.1 Asset

What it is: An asset is anything a provider makes available for sharing through the data space. The DSP specification is deliberately transport- and type-agnostic — an asset could be:

• A synchronous REST API endpoint

• A SOAP/XML-RPC service

• A bulk file (CSV, Parquet) stored in S3 or Azure Blob

• A streaming topic (Kafka, MQTT)

• A database query result set

• A static dataset for download

The asset itself is just an entry in the catalog with an identifier and metadata. How you access it is determined by the transfer type and the data plane that serves it. EDC ships with data plane implementations for HTTP endpoints, Amazon S3, Azure Storage, and Kafka — and custom data planes can be registered for anything else. The DSP standard doesn't constrain what "the data" is; it only governs the control flow (discovery, negotiation, authorization) that happens before data moves.

How DSP uses it: The provider's control plane maintains a catalog of assets. Each asset has:

• An ID (opaque string)

• Metadata (arbitrary key-value properties — format, quality, freshness, licensing terms, etc.)

• A data address (where/how to access the underlying data — URL, bucket path, topic name)

• Associated policies (who can see it, who can use it)

• Associated contract definitions (under what terms it's available)

In X-Road 8's implementation: assets are specifically X-Road services — synchronous REST or SOAP endpoints accessible through the Security Server proxy. The AssetIndexServerConfStore builds the asset list by iterating every service registered in serverconf, and the data address resolves to an HttpDataAddress (the service's URL routed through the proxy). The transfer type is Xrd-PULL — meaning the consumer fetches data via HTTP from the provider's mTLS serverproxy endpoint.

So while DSP/EDC could support Kafka streams, S3 buckets, or file dumps as assets, X-Road 8 scopes it to what X-Road already does: mediated, synchronous HTTP service calls. The data space layer here isn't expanding what kind of data flows — it's adding governance (catalog, policy, contracts) around the existing service call model.

X-Road 7 equivalent: An X-Road service (identified by instance/memberClass/member/subsystem/serviceCode/serviceVersion). In X-Road 8, the mapping is direct: each service registered in serverconf becomes an asset with its ID derived from serviceId.asEncodedId(). The existing X-Road service registry is the asset registry — no separate catalog needs to be maintained.

What's different: In X-Road 7, a service is simply "available" or "not available" — there's no metadata-rich description beyond the OpenAPI/WSDL. In the data space model, an asset can carry arbitrary metadata (data format, quality, freshness, licensing terms) that a consumer can evaluate programmatically before requesting access. And in the broader DSP ecosystem (outside X-Road), an "asset" could be something that isn't a service call at all — a static dataset, a data stream, or a bulk transfer — though X-Road 8 doesn't use those modes today.

3.4.2 Catalog

What it is: A catalog is the discoverable set of assets a provider offers, along with their metadata and the terms under which they're available. It's the answer to "what can I get from this provider?"

How DSP uses it: A consumer sends a Catalog Request message (DSP protocol) to a provider's control plane endpoint. The provider evaluates the request against policies (considering the requester's identity/credentials) and returns a Catalog Response — a JSON-LD document listing available datasets, each containing distributions (access methods) and associated contract offers. Crucially, the catalog can be policy-filtered: different consumers may see different assets depending on their credentials.

X-Road equivalent: In X-Road 7, discovery happens via the Service Metadata Protocol: listClients (what organizations exist), listMethods/allowedMethods (what services a provider offers / what the consumer has access to), and getOpenAPI (service specification). These are invoked as standard X-Road service calls or HTTP GET requests.

What's different:

• X-Road's discovery is flat and binary — you either see a service or you don't, based on whether you're in the access list. DSP catalog discovery is policy-driven — visibility can be based on credential claims (e.g., "only organizations with a HealthCare credential can see this dataset").

• X-Road's discovery requires being within the same trust federation (or federated instance). DSP catalog requests work across trust boundaries — any participant with a valid DID and credential can query any provider's catalog endpoint.

• X-Road returns service metadata (OpenAPI). DSP returns richer metadata plus contract terms in a machine-readable format.

3.4.3 Policy (ODRL)

What it is: A policy is a machine-readable set of rules (permissions, prohibitions, obligations) that governs access to assets. Policies answer: "under what conditions is this asset available?" They are expressed in ODRL (Open Digital Rights Language), a W3C standard for rights expressions.

How DSP uses it: Policies are evaluated at three decision points:

1. Catalog access — who can even discover/see an asset (e.g., "only members of group X can see this service in the catalog")

2. Contract negotiation — what conditions must be met to agree a contract (e.g., "only organizations with member ID matching ee/GOV/70001234 can contract for this asset")

3. Transfer authorization — what conditions apply when the data actually flows (e.g., "valid membership credential must be presented")

Policy constraints are evaluated by constraint functions — pluggable evaluators that check specific conditions. X-Road 8 registers custom constraint functions for X-Road-native conditions.

X-Road equivalent: In X-Road 7, access control is managed via ACL (access control lists) in serverconf. A provider explicitly adds a consumer (identified by their X-Road member/subsystem ID) to the allowed list for a specific service. Access can also be granted to local groups or global groups of members.

What's different:

• X-Road's ACL is binary and imperative — an admin manually adds/removes consumers. There's no machine-readable "why" — it's just "allowed" or "not allowed."

• ODRL policies are declarative, composable, and auditable — you express rules like "allow if member is in group HealthProviders AND credential type is XRoadMembership AND not expired." These can be evaluated automatically without admin intervention.

• ODRL policies enable purpose limitation and usage control (e.g., "data may only be used for statistical purposes") — concepts that don't exist in X-Road 7's ACL model.

• In X-Road 8's implementation, the ODRL constraints are actually evaluated using X-Road-native information (XRoadClientIdConstraintFunction, XRoadLocalGroupMemberConstraintFunction, XRoadGlobalGroupMemberConstraintFunction) — so the access decisions are the same as X-Road 7 would make, but expressed in a machine-readable, interoperable language.

3.4.4 Contract Negotiation

What it is: A two-party handshake where consumer and provider agree on the terms under which an asset will be shared. It produces a Contract Agreement — a signed record that both parties hold, binding them to the negotiated policy.

How DSP uses it: The negotiation follows a state machine:

1. Consumer sends a Contract Request (referencing an offer from the catalog)

2. Provider evaluates the request against its policies and the consumer's credentials

3. If acceptable, provider sends a Contract Agreement (signed by both control planes)

4. Both parties store the agreement — it's the basis for authorizing subsequent data transfers

The negotiation is asynchronous (state machine with callbacks) and can involve multiple rounds (offer → counter-offer → agreement), though in practice X-Road 8 does a single-round auto-accept if policies pass.

X-Road equivalent: In X-Road 7, there is no negotiation. The provider's admin grants access, and from that point the consumer can call the service. There's no per-interaction agreement, no record of terms, and no machine-readable contract between the parties. The closest analog is the act of adding a consumer to the ACL — but that's a unilateral provider decision, not a bilateral agreement.

What's different:

• Contract negotiation creates an auditable, bilateral record of agreement. In X-Road 7, the access decision is one-sided (provider grants) with no consumer acknowledgment of terms.

• Contracts can have temporal validity (expiration), meaning access can be time-bounded without manual ACL cleanup.

• Contracts are machine-readable and portable — a third party (auditor, regulator) can verify that a data transfer was authorized by examining the contract agreement.

• In X-Road 8, the negotiation is largely automatic (happens in milliseconds if policy passes) and transparent to end users — the proxy-dsp-core triggers it behind the scenes when a consumer calls a DSP-enabled service. The consumer app doesn't need to know about it.

3.4.5 Transfer Process

What it is: Once a contract is agreed, a transfer process governs the actual movement of data. It's separate from the contract: the contract says "you may access this," the transfer process says "here's how to get it right now."

How DSP uses it: The consumer's control plane sends a Transfer Request (referencing the contract agreement) to the provider's control plane. The provider validates the request, selects a data plane (the system that actually serves the data), and returns a Data Address — a URL plus optional authentication credentials for the consumer to use.

Transfer types:

• PUSH — the provider initiates the transfer (sends data to the consumer)

• PULL — the consumer initiates the transfer (fetches data from the provider's endpoint)

X-Road 8 uses Xrd-PULL: the provider returns its existing mTLS serverproxy endpoint as the data address, and the consumer's proxy sends the actual X-Road request there.

X-Road equivalent: In X-Road 7, there is no separate transfer process — once access is granted via ACL, the consumer simply sends a service request to its local Security Server, which routes it to the provider's Security Server. There's no "start transfer" step; every service call is self-contained and independently authorized by the ACL at message time.

What's different:

• In X-Road 7, each message is independently authorized (the provider's SS checks the ACL on every request). In DSP, the contract agreement pre-authorizes a class of transfers, and the transfer process grants a time-limited data address with an auth token — reducing per-message overhead for repeated access.

• The transfer process introduces an explicit data plane concept — separation between the orchestration ("can you access this?") and the actual data delivery ("here's the pipe"). In X-Road 7, these are unified in the single Security Server proxy.

• In X-Road 8's implementation, this separation is logical, not physical — the "data plane" is still the X-Road proxy itself (port 5590 Data Plane Signaling endpoint), and the actual data still flows over the standard mTLS pipeline. But the abstraction exists for future flexibility (e.g., bulk file transfer via a different data plane).

3.4.6 Verifiable Credentials (VCs) and Decentralized Identifiers (DIDs)

What they are:

• A Verifiable Credential (W3C standard) is a tamper-evident, cryptographically signed claim about a subject. Think of it as a digital certificate, but more flexible — it can assert anything ("this organization is an X-Road member," "this entity is a licensed healthcare provider") and be verified without contacting the issuer.

• A DID (Decentralized Identifier) is a URI that identifies a participant without depending on a central registry. The did:web scheme resolves to a URL where the participant's public keys are published (a DID Document). Example: did:web:security-server.example.com%3A10100.

How DSP uses them: The Decentralized Claims Protocol (DCP) adds VCs as the trust layer for DSP:

1. Each participant has a DID (published at their Identity Hub)

2. A trusted Issuer Service issues VCs asserting membership/capabilities (e.g., "XRoadMembershipCredential")

3. During contract negotiation, the consumer presents a VC proving their identity/membership

4. The provider's policy engine verifies the VC (signature valid? issuer trusted? claims match policy constraints?) and decides whether to proceed

X-Road equivalent: In X-Road 7, trust is established through the X.509 PKI managed by the Central Server:

• Each Security Server has an authentication certificate (for TLS channel establishment)

• Each organization has a signing certificate (for message signatures and non-repudiation)

• Trust anchors are centrally managed: only CAs listed in globalconf are trusted

• Identity is verified by checking that a certificate is issued by an approved CA and registered in globalconf

What's different:

• X.509 certificates identify infrastructure (a security server, an organization's signing key). VCs assert claims about properties ("this org is an X-Road member," "this org is in the HealthProviders group") — richer, more flexible.

• X.509 trust is centralized: a single CA hierarchy, governed by the Central Server. VC trust is federated/decentralized: any trusted issuer can issue credentials, and different data spaces can trust different issuers.

• X.509 certificate revocation (OCSP) is all-or-nothing: either the cert is valid or it isn't. VCs can have selective disclosure and graduated trust (e.g., an expired VC for catalog browsing but requiring a fresh one for transfer).

• DIDs enable cross-domain identity without shared infrastructure. In X-Road 7, cross-instance identity requires federation (shared globalconf). With DIDs, a participant can be identified by anyone who can resolve their DID — no shared Central Server needed.

• In X-Road 8, both coexist: the VC's X-Road MemberId claim is signed by the same key used for X-Road message signing (via the signer service), binding the new identity layer to the existing PKI. VCs don't replace X.509 — they extend it for cross-domain scenarios.

3.4.7 Summary: what the data space layer adds vs. what it replaces

The key design principle in X-Road 8: none of these concepts replace what X-Road already has. They are an interoperability overlay — projecting existing X-Road capabilities into the vocabulary and protocols that the broader European data space ecosystem speaks (DSP, ODRL, DCP, VCs). Internally, the same serverconf, the same signing keys, the same ACL decisions are used — they're just expressed in a standardized, machine-readable, cross-domain format.

3.5 Current limitation: X-Road 8 can only talk to other X-Road 8 instances via DSP

A critical question: can X-Road 8's data space layer interoperate with a non-X-Road DSP-compatible system (e.g., a standalone EDC connector, a GAIA-X participant, or another vendor's dataspace implementation)?

The answer today is no. The implementation is currently locked to X-Road-to-X-Road communication only, for several structural reasons:

1. Consumer-side provider lookup is hardcoded to X-Road Security Servers

The ConsumerSideDspProcessor resolves providers by querying globalconf for Security Servers hosting a given X-Road service, then maps the server's host-address to a DSP endpoint via a hardcoded map (CounterPartyTarget.defaultMap()). There is no mechanism to discover or address a non-X-Road DSP endpoint. The code itself acknowledges this: the map is annotated @Deprecated(forRemoval = true) with the comment "Planned: replace hardcoded map with config-driven counter-party resolution."

2. The consumer-side flow starts from an X-Road service identifier

The entry point is always an X-Road ServiceId (the hierarchical instance/class/member/subsystem/service identifier). The system derives an assetId from this and uses ProviderSecurityServerResolver (which queries X-Road's globalconf) to find candidate providers. There's no path to say "give me asset X from this DSP endpoint" — it always starts from "give me X-Road service Y."

3. Provider-side policies require an XRoadMembershipCredential

The policy constraint functions (XRoadClientIdConstraintFunction, group membership functions) extract the consumer's X-Road member identity from a Verifiable Credential of type XRoadMembershipCredential. A non-X-Road consumer — even one with a valid DID and its own VCs — wouldn't have this credential type, so policy evaluation would fail and the negotiation would be rejected.

4. The only transfer type is Xrd-PULL

The XRoadDataPlaneManager only handles Xrd-PULL transfers, where the "data plane" endpoint IS the X-Road mTLS serverproxy. A standard EDC HTTP data plane, S3 transfer, or Kafka data plane is not supported.

However: the wire protocol IS standard DSP 2025-1

Importantly, the actual DSP messages exchanged between two control planes are standards-compliant DSP 2025-1. The catalog requests, contract negotiations, and transfer messages use the standard JSON-LD format over HTTPS. If the surrounding assumptions (hardcoded lookup, X-Road credentials, Xrd-PULL transfer type) were relaxed, an X-Road control plane could theoretically negotiate with a vanilla EDC connector — the protocol is compatible at the wire level.

What this means for interoperability:

The current implementation achieves "X-Road speaks DSP to itself" — it uses the data space vocabulary and protocol between X-Road instances, which is a necessary first step. But it does not yet achieve the ultimate promise of data spaces: any DSP participant can interoperate with any other DSP participant regardless of implementation.For that, X-Road would need:

• A configurable/discoverable counter-party registry (not hardcoded)

• Support for standard EDC transfer types (HTTP-PULL, HTTP-PUSH) in addition to Xrd-PULL

• Policy evaluation that can accept non-X-Road credential types (or a credential mapping/translation layer)

• A way to address non-X-Road assets (assets that don't map to an X-Road ServiceId)

This gap is directly relevant to the IM spec discussion in Section 7 — and is what makes a standardized Gateway Interface important rather than optional.

4. Configuration Differences (Operator / Infrastructure)

X-Road 7.8.1 has none of the following. Enabling data spaces in X-Road 8 requires:

New services & packages

• Three systemd units: xroad-ds-control-plane, xroad-ds-identity-hub, xroad-ds-issuer-service (depend on xroad-base and a secret store service).