Skip to content

Intermediaries & operators#

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

Purpose#

Intermediaries provide enabling services — onboarding, identity validation, registry operations, policy enforcement. Operators coordinate the data-space infrastructure and participant engagement.

LDT instantiation — where we stand#

Function Operated by
Scheme framework, Satellite, trusted list, certification iSHARE Foundation (exclusive, per Consortium Agreement) — Scheme Owner; single authoritative trust anchor
ITB-S conformance lab, development sandbox, reference trust gateway iLabs Technologies, with Ayra Association as subcontractor per the Pilot Grant Agreement; work-order scope to be confirmed — tests issuers, wallets and verifiers; the Scheme Owner decides on listing
Marketplace of the EU LDT Toolbox Nunsys (WP6), for the project duration — catalogue, ordering, verified impact claims
CO₂ credential issuance Accredited issuer per credential type (initially LogiNex, FHC Corp, Almelo Energie, the cities) — issuer of record; liable for credential content
Site-level twin operation each site owner (cities, FHC, port)

Source: PD4 v1.0 §2, Table 1 — text as in PD4 v0.95_merged (28 Oct 2026).

Neutrality rule: operators act under the scheme's rules and TIPS oversight; operator failure/continuity arrangements belong in the contractual framework. A party that tests components (iLabs) does not take listing decisions; listing and delisting are decided by the Scheme Owner on the basis of test reports, which keeps conformance testing neutral (PD4 v1.0 §2).

Operating conditions (PD4 §3)#

Satellite (iSHARE Foundation). The Satellite verifies legal entities by a registered identifier (EORI, or EUID where no EORI exists), admits them as adhering participants and issues the Participant Credential into the participant’s own wallet. This is part of iSHARE’s standing scheme operations, not a pilot-specific service, and is the most important continuity guarantee of the scheme. The iSHARE Participant Registry is the scheme’s only authoritative trust anchor. The party-identifier decision (iSHARE DID as key, EUID/EORI associated) is open with TIPS (PD4 Table 3, target M8).

ITB-S conformance lab (iLabs). 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. 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. iLabs tests and does not certify; it issues no CO₂ or Participant Credentials and provides no organisational wallets, so that its testing stays neutral. Interconnection with other trust registries and integration of the Ayra conformance suite with the ITB-S are carried out with Ayra Association as subcontractor, as set out in the Pilot GA; work-order scope to be confirmed.

Reference trust gateway (iLabs). Relying parties can use a gateway instead of integrating every wallet, issuer, status list and licence policy themselves: an API gateway as policy enforcement point, OIDC and machine-to-machine authentication, an OpenID4VP verifier and a policy decision point that evaluates the scheme’s ODRL licence catalogue. All components run on EU-hosted infrastructure under EU control.

Marketplace of the EU LDT Toolbox (Nunsys), credential issuers and sites. Nunsys hosts and operates the Marketplace of the EU LDT Toolbox for the duration of the project. At project completion, responsibility for the Marketplace and its assets, services and results is proposed to transfer to CitiVERSE EDIC or another entity designated by the Contracting Authority, so that a single EU LDT Marketplace serves the wider ecosystem (to be agreed with the Contracting Authority). (Revised 28 Oct 2026 following Nunsys, e-mail of 26 Oct 2026; tracked change in PD4 v0.95_merged.) Each accredited issuer operates its own issuance service, or uses issuance infrastructure provided by iLabs as technical operator (processor) while remaining the issuer of record. Wallets are organisational wallets held and controlled by the participants; there is no central wallet infrastructure. The sites operate their own digital twins and source systems; for Aruba, FHC coordinates integration within its agreed scope, Qwihi supports the wallet and credential components, and each source-system operator maintains its own infrastructure and controls access to its data.

Maintenance. Each operator maintains its own component; the governance framework is maintained by the Scheme Owner under version management, with changes through the TIPS change procedure. 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.

Source: PD4 v1.0 §3 — text as in PD4 v0.95_merged (28 Oct 2026).

🧩 Building block requested — Owner: iLabs (with Ayra Association)#

What we need: the ITB-S operator profile: onboarding-support services, registry operations (availability, SLA), conformance-testing process, and continuity/fallback arrangements. Confirm the Ayra work-order scope.

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

Financing the interoperability layer (PD4 §6)#

Following the monetisation options in the European Commission’s Business Models Study for the EUDI Wallet ecosystem, the layer is financed by those who benefit from not integrating bilaterally: technical integration fees per conformance cycle for wallet providers and issuers (option C); a subscription for relying parties using the trust gateway (option D, access fees), moving to privacy-preserving per-verification fees once volumes justify it (option A); set-up and operation fees for issuance infrastructure (C); and onboarding fees or public funding for replicating cities (C/E). The more issuers and wallets the scheme accepts, the stronger this model becomes, which aligns iLabs’ commercial interest with an open, multi-issuer, multi-wallet scheme.

Source: PD4 v1.0 §6 — text as in PD4 v0.95_merged (28 Oct 2026). Reference: European Commission — Business Models Study Report: EUDI Wallet Ecosystem Sustainability and Business Models (catalogue no. KK0126130ENN).

Guiding questions#

All 17 of the template's questions for this block, with the 6 LDT answer slots to fill, are on data-space-intermediaries-and-operators/guiding-questions.md. The digest below is the subset that most shapes this block.

  • Who matches providers with consumers, and how do intermediary services scale as participation grows?
  • How is neutrality ensured while operators enforce the rules; what governance rules apply to operators?
  • What contingency measures guarantee continuity if an operator fails, and how are dependency risks mitigated?

PD4 mapping#

Feeds PD4 v1.0 §2 (Table 1, role separation), §3 (operating conditions) and §6 (interoperability-layer financing).