Skip to content

Data exchange#

Part of the LDT Governance and Trust Framework — instantiates the iSHARE Data Space Template block Data exchange (© iSHARE Foundation, see Legal notices).

Purpose#

Once meaning is agreed, participants need a secure, reliable, standards-based way to exchange data — typically via APIs.

LDT instantiation — where we stand#

  • Connector layer: Eclipse Dataspace Components (EDC) with the EDC iSHARE extension (iSHARE open source) for trust-framework-aware exchange; iSHARE-compliant APIs (openapi.ishare.eu) for authorisation flows. PD4 v1.0 §3 pins the trust and exchange profile (protocols, credential formats, status lists, policy enforcement at the gateway) and does not pin a connector implementation, so the EDC choice sits under that profile rather than beside it.
  • City twins: NGSI-LD context brokers (MIM2-compliant) expose dynamic city data; OGC services remain available for geo layers — with non-ESRI interoperability explicitly required (funder recommendation, Annex 9).
  • Conformance: every exchange path is validated in the ITB-S before production use; PD2 interoperability scores depend on it. A passing conformance report is required before a component moves to APPROVED and before a participant goes live, and is re-run on every release. Reports are stored per component in the governance repository (PD4 v1.0 §3).

Pilot exchange profile (PD4 §3)#

The pilot profile is: OAuth 2.0 machine-to-machine per iSHARE Trust Framework 3.0; client authentication with a signed JWT (OAuth 2.0 client credentials, private_key_jwt, RFC 7523); OpenID4VCI 1.0 and OpenID4VP 1.0; SD-JWT VC with ES256 and did:web or did:jwk keys; IETF Token Status List; ODRL 2.2 licence terms compiled to executable policies and enforced at the gateway; and the Marketplace catalogue model (PD4 section 4). Profile versions are pinned and change only through the TIPS change procedure.

iLabs operates an instance of the EC Interoperability Test Bed with test suites for credential issuance (OpenID4VCI 1.0), presentation (OpenID4VP 1.0 with DCQL), SD-JWT VC validation (ES256, holder key binding), status checking (IETF Token Status List) and iSHARE machine-to-machine token flows.

Source: PD4 v1.0 §3 — text as in PD4 v0.95_merged (28 Oct 2026); client authentication added 28 Oct 2026 (Nunsys proposal of 19 Oct, supported by iLabs on 22 Oct).

🧩 Building block requested — Owner: iLabs (input: FHC for Aruba, HyEnSys for PED integration)#

What we need: the protocol set per use case: push/pull/streaming choices, API specifications and versioning rules, error-handling and reconnection policy, and the ITB-S conformance procedure that gates production onboarding.

Format: Markdown section in this page (merge request) · Due: 26 Sep 2026 (v0.5) · Status: OPEN

Guiding questions#

All 13 of the template's questions for this block, with the 5 LDT answer slots to fill, are on data-exchange/guiding-questions.md. The digest below is the subset that most shapes this block.

  • Which generic protocols (REST/HTTP, NGSI-LD, LDES, MQTT) are adopted; which domain-specific APIs are required; is there a preferred protocol set for faster onboarding?
  • Push, pull or both; which scenarios need streaming vs batch; how are real-time and triggered exchanges handled?
  • How do protocols link to the semantic models and how are API specs published for discovery?
  • How are completeness, error handling and version compatibility ensured; how is interoperability with other EU data spaces maintained?

PD4 mapping#

Feeds PD4 v1.0 §3 — Operating conditions (exchange protocols, ITB-S conformance).