Skip to content

Guiding questions — Data space intermediaries & operators#

Fork notice. The questions below are reproduced from the iSHARE Data Space Template page Data space intermediaries & operators → Guiding questions — © iSHARE Foundation, used under the EUTwinLink Consortium Agreement (see Legal notices). The template's question text is carried over unchanged so this fork stays comparable to its upstream.

Everything between the LDT answer markers is the EUTwinLink instantiation — that is what partners fill in. Decisions already taken live on the block page: Data space intermediaries & operators.

Building block B4 · owner(s) iLabs Technologies + iSHARE · due 26 Sep 2026 · block status DRAFTED · see the Building-block register.

Answer provenance. Every answer below is tagged with where it comes from, because a governance scheme that cannot be traced is not a governance scheme:

  • Decided — already fixed by the Grant Agreement, the Consortium Agreement or a recorded decision elsewhere in this scheme. Change it only through the change procedure.
  • Proposed — a defensible default, derived from the iSHARE Trust Framework, the DSSC Blueprint and the decisions this scheme has already taken. Drafted for the owner to confirm, correct or reject at TIPS. It is not an agreed position until TIPS approves it.
  • Needs owner — cannot be answered without the named owner: a fact about their systems, their legal position or their commercial intent. The text states what is needed and why.

Open points across the whole scheme are collected in Open questions for partners.

Purpose of this Building Block Component: Intermediaries and operators play a crucial enabling role, making data accessible, trustworthy, and compliant with EU regulations. They help reduce complexity and lower barriers to entry for participants. Key responsibilities may include: * Identity and access management (e.g. authenticating participants, issuing credentials) * Service brokerage (e.g. data search and matchmaking) * Compliance assurance (e.g. ensuring data usage aligns with CSRD, EPBD, or GDPR) * Onboarding and support for participants, especially SMEs and municipalities Operators might include neutral industry bodies, domain-specific hubs, or trusted IT providers. Multiple operators can coexist under federated rules, enabling sectoral specialisation while ensuring interoperability through shared frameworks.

1. Identity & Access Management#

Purpose: Authentication mechanisms (e.g., credentials issuance, federated logins). Clear participant identity verification.

  • How will participants be authenticated (federated identity, credentials)?
  • What trust anchors or standards will be used?

LDT answer DRAFTED · owner: iLabs Technologies + iSHARE · due 26 Sep 2026

Decided Authentication is federated, not operator-held: participants authenticate with W3C Verifiable Credentials presented over OpenID4VC, anchored by iSHARE Foundation, with legal-entity identification by a registered identifier (EORI, or EUID where no EORI exists) and DIDs where wallet flows require them; the party-identifier decision (iSHARE DID as key, EUID/EORI associated) is open with TIPS (PD4 Table 3, target M8). Operators verify credentials; they do not issue identities, and no operator holds a password database for the data space.

Decided Trust anchors: iSHARE Foundation as Scheme Owner, plus eIDAS trust lists. The Trusted List and certification of parties are performed exclusively by iSHARE Foundation under the Consortium Agreement. Standards: W3C VC with JSON-LD data models, OpenID4VC for issuance and presentation, iSHARE credential schemas (schemas.ishare.eu) as the base, eIDAS-recognised PKI profiles for transport security, and status lists plus Participant Registry state for revocation.

Detail is in Identity & attestation management; this block records only that intermediaries consume that layer rather than operating one of their own.

2. Service Brokerage#

Purpose: Data discovery and matchmaking between providers and users. Efficient search and service recommendation systems.

  • Which discovery functionalities are critical for initial use cases?
  • Who is responsible for matching data providers with data consumers?
  • How can intermediaries ensure services scale as participation grows?
  • How can intermediaries’ models align with overall data space goals?

LDT answer DRAFTED · owner: iLabs Technologies + iSHARE · due 26 Sep 2026

Decided The catalogue of the Marketplace of the EU LDT Toolbox (Nunsys, WP6) is the LDT's primary discovery surface. Listing requires a valid participant credential, a policy-complete description, and — for certified badges — ITB-S conformance evidence.

Proposed Discovery functionality that the initial use cases actually need, which is less than a general marketplace implies: search by domain and geography (cross-site benchmarking between Cartagena, Almelo and Hamburg is a stated requirement), filter by access tier, and visibility of the attached policy before a request is made. That last one carries most of the weight — a consumer that can read the terms before negotiating avoids most failed requests.

Proposed Matching is not brokered by a person. Nobody in the LDT is responsible for pairing providers with consumers; the catalogue plus the use-case profiles do that work, and the profiles are the better signal because they state what each site needs from the others. Scaling concerns therefore land on the catalogue and the registry rather than on a brokerage function.

Alignment with data-space goals is contractual: operators act under the scheme's rules and TIPS oversight, with their business model separated from the trust layer (Organisational form 1.3).

Needs owner Nunsys: which of these functions WP6 actually delivers, and when.

3. Compliance Assurance#

Purpose: Ensuring data transactions align with regulatory frameworks (CSRD, EPBD, GDPR). Data governance and audit trail management.

  • How will operators enforce compliance (policy engine, audit trails)?
  • Who will validate that data usage aligns with EU and national regulations?
  • How can neutrality be ensured while operators comply with rules?

LDT answer DRAFTED · owner: iLabs Technologies + iSHARE · due 26 Sep 2026

Decided Operators enforce through the federated PEP/PDP pattern at the connectors (EDC with the iSHARE extension), with the Participant Registry and credential status as shared policy information points. There is no central policy engine — a deliberate choice, because a central engine would make one operator a chokepoint and a single point of failure for every exchange in the data space.

Audit trails are generated at each policy decision and at control-plane events; see Provenance, traceability & observability.

Proposed Who validates lawful usage: nobody validates it continuously, and the scheme should not claim otherwise. What exists is (a) policy checks that enforce the declared terms automatically, and (b) an audit trail that makes after-the-fact review possible. Judging whether a declared purpose is lawful is the participant's responsibility, with TIPS as the forum when it is disputed.

Decided Neutrality rule: operators act under the scheme's rules and TIPS oversight, and the scheme's governance is separated from its operations — TIPS governs, operators operate, iSHARE owns the framework. An operator cannot change the rules it enforces.

4. Onboarding & Participant Support#

Purpose: Dedicated support structures for smooth onboarding. Special focus on SMEs, municipalities, and smaller participants.

  • Which resources or tools facilitate onboarding, especially for smaller or less digitally mature participants?
  • Who handles participant support, and how is quality assured?

LDT answer DRAFTED · owner: iLabs Technologies + iSHARE · due 26 Sep 2026

Decided The ITB-S (iLabs, WP2) is both the conformance gate and the integration sandbox, so the environment a participant tests against is the environment that certifies it. For smaller or less digitally mature participants that matters more than documentation does: they can fail safely and repeatedly before production.

Proposed Resources that lower the barrier, in order of effect: the ITB-S sandbox; reference EDC connector configurations with the iSHARE extension pre-wired; the standard licence and ODRL templates, so a participant chooses terms rather than drafting them; and the Observer role, which lets an organisation join the LDT without passing a conformance test at all.

Proposed Support is operator-provided within scope (iLabs for registry and ITB-S, Nunsys for the marketplace) and bounded by the service agreements. Quality assurance is through the monthly operational report to TIPS rather than a separate SLA regime.

Needs owner iLabs — the open 🧩 on the block page asks for exactly this: onboarding-support services, registry availability and SLA, the conformance process, and continuity arrangements. Everything above is a drafting position, and the throughput times the scheme needs in order to promise anything are still unknown.

5. Federation & Specialisation#

Purpose: Sectoral or regional hubs enable specialisation, while interoperability among multiple operators is ensured through common rules.

  • Will multiple domain-specific operators exist? What are their defined roles?
  • What mechanisms will ensure interoperability among the federated operators?
  • What contingency measures ensure continuity if an operator fails?
  • How can dependency risks be mitigated across multiple services?

LDT answer DRAFTED · owner: iLabs Technologies + iSHARE · due 26 Sep 2026

Decided Multiple operators already exist, with distinct and non-overlapping functions: iSHARE Foundation (scheme, Satellite, Trusted List, certification; the iSHARE Participant Registry as the only authoritative trust anchor), iLabs Technologies with Ayra Association as subcontractor per the Pilot Grant Agreement; work-order scope to be confirmed (ITB-S conformance lab, development sandbox, reference trust gateway; trust-registry interconnection), Nunsys (marketplace), and each site owner for its own twin. No operator performs two functions that should check each other.

Proposed Interoperability among them is maintained by shared artefacts rather than by coordination meetings: the same credential schemas, the same ODRL profile, the same registry as the authoritative participant state, and ITB-S validation of every exchange path. An operator that diverges fails the test rather than being talked back into line.

Proposed Continuity is designed per component, as stated in PD4 v1.0 §3 and §6: each operator maintains its own component, and scheme ownership, the trusted list, certification and the Satellite continue as part of iSHARE Foundation’s standing operations. The iSHARE Participant Registry is the scheme’s only authoritative trust anchor, and iLabs issues no CO₂ or Participant Credentials and provides no organisational wallets. The remaining operator dependency is on the components iLabs operates — the ITB-S conformance lab, development sandbox and reference trust gateway — and on the trust-registry interconnection carried out with Ayra Association as subcontractor. For each component the operating arrangements record the hosting provider, support contacts, maintenance and recovery responsibilities, incident escalation, and responsibility for credential updates and revocation.

Decided The intended scope is on the record in the signed application, which lists Ayra Association as a Letter-of-Support stakeholder to be sub-contracted under WP2 and WP4, to "enable trustworthy interconnect across trust registries (trust lists) supporting organisational and legal interoperability, integrate Ayra Test Conformance Suite with ITB". (Source: EUTwinLink LDT4SSC WS1 Application Form, Annex 4 to the Pilot Grant Agreement.)

Needs owner iLabs: the executed work order against that scope (PD4 v1.0 Table 3, target M7). Risk: the trust-registry interconnection and the ITB-S integration depend on a subcontract that is described in the application but not yet placed. Mitigation: place it; iLabs remains the accountable operator of the ITB-S conformance lab, development sandbox and reference trust gateway whatever the final scope.

6. Governance and Trust#

Purpose: Transparent operational standards ensuring neutrality and trustworthiness of operators.

  • What governance rules apply to operators? Are these clearly documented?
  • How is neutrality and fairness guaranteed across operators?

LDT answer DRAFTED · owner: iLabs Technologies + iSHARE · due 26 Sep 2026

Decided Governance rules applying to operators: they act under the scheme's rules and TIPS oversight; they do not change the rules they enforce; their function is recorded in Intermediaries & operators; and continuity and failure arrangements belong in the service agreements under the Contractual framework.

Proposed Documented clearly? Partly — and the honest answer belongs in PD4. The allocation of functions is documented here; the obligations attaching to each (availability, response times, hand-over, escalation) live in service agreements that are not yet written. Until they are, operator governance is a table of names rather than a set of commitments.

Proposed Neutrality and fairness are guaranteed structurally where possible and contractually where not:

  • Structural — the trust layer is non-commercial and separated from the commercial service layer; the registry is machine-readable so its state can be checked independently; enforcement is federated, so no operator mediates others' exchanges.
  • Contractual — the neutrality rule in the service agreement, with TIPS as the forum for a complaint.

The residual risk is that Nunsys both operates the marketplace and sells services on it. That is manageable and should be named rather than left implicit: listing eligibility rules must be objective and applied equally, and a dispute about a listing decision goes to TIPS, not to Nunsys.

Needs owner Nunsys + iSHARE: confirm that framing, and state how a rejected listing can be appealed.