Skip to content

Guiding questions — Trust framework#

Fork notice. The questions below are reproduced from the iSHARE Data Space Template page Trust framework → 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: Trust framework.

Building block T5 · owner(s) iSHARE · due no date set · 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.

1. Trust Entities & Roles#

Purpose: Define the roles and recognition of trust anchors, providers, and accredited entities in the data space.

  • Which Trust Anchors will the data space recognise (e.g., EU authorities, accredited certification bodies)?
  • What roles will Trust Service Providers play in the ecosystem?
  • Will the data space maintain its own accredited trust entities or federate from existing frameworks?

LDT answer DRAFTED · owner: iSHARE · due no date set

Decided Trust anchors recognised by the LDT: iSHARE Foundation as Scheme Owner, and eIDAS trust lists. The Trusted List and certification of parties are performed exclusively by iSHARE Foundation under the Consortium Agreement.

Decided The LDT federates from an existing framework rather than maintaining its own accredited trust entities. The trust layer is the iSHARE (DataRights) Trust Framework 3.x applied to the digital-twin domain — not a bespoke framework, and not a new accreditation regime.

Proposed Roles played by trust service providers in this ecosystem: credential issuance anchored by iSHARE; registry operation by iLabs; conformance testing by ITB-S; eIDAS-qualified providers where a participant already relies on one. Note that none of these is a new trust entity — they operate functions within an existing framework, which is the whole point of the choice above.

Proposed The open point recorded on the block page — whether any LDT-specific accredited trust entity is needed beyond the iSHARE anchors — should be closed as "no" at TIPS unless a use case produces a requirement none of the existing anchors meets. Nothing in the six use-case profiles currently does. Leaving the question open indefinitely costs more than deciding it.

2. Criteria & Rulebook Alignment#

Purpose: Specify baseline and sectoral criteria for trust entities, aligned with the data space rulebook.

  • What baseline criteria must a trust entity meet to be recognised in the data space?
  • How will sector-specific or regulation-driven trust requirements be added to the rulebook?
  • Will the data space adopt existing cross-sector rules (e.g., Gaia-X trust principles) or develop bespoke ones?
  • How will conformity with these criteria be evidenced (e.g., ISO/IEC 17000-based attestations, certificates)?

LDT answer DRAFTED · owner: iSHARE · due no date set

Decided Baseline criteria for recognition in the LDT, all of them already conditions of participation: verified legal identity on a registered identifier (EORI, or EUID where no EORI exists; party-identifier decision open with TIPS), a signed accession agreement, ITB-S conformance for the exchange paths used in production, valid credentials, and a registry entry in good standing.

Decided Conformity is evidenced through ITB-S testing, which produces technical evidence published to the registry. It is not certification: the iSHARE-compliant designation is granted only by iSHARE Foundation under its own scheme.

Proposed Cross-sector rules: the LDT adopts rather than develops. Gaia-X alignment is maintained at the descriptive level (offerings and self-descriptions) rather than by adopting Gaia-X trust principles wholesale, because the LDT's trust decisions are already made by the iSHARE framework and running two trust regimes would create ambiguity about which governs a given decision.

Proposed Sector-driven requirements enter the rulebook through the use-case layer, not by amending the baseline: a use-case group may be stricter than the scheme, never weaker. That is how the energy-market role requirement for PED grid interaction, or the public-authority status of the municipalities, becomes a trust criterion without becoming a universal one.

Proposed ISO/IEC 17000-based attestations are recognised where a participant already holds them.

3. Validation & Verification Processes#

Purpose: Establish how claims and attestations will be validated, exchanged, and revoked when necessary.

  • How will claims and attestations be collected, exchanged, and validated?
  • What technical standards (e.g., W3C VC, ISO CASCO) will the data space require for claims formatting?
  • How will revocation and suspension of trust entities or credentials be handled?
  • Will verification support dynamic attributes (e.g., DAT) where applicable to usage control?

LDT answer DRAFTED · owner: iSHARE · due no date set

Decided Claims are collected at onboarding and exchanged as W3C Verifiable Credentials presented over OpenID4VC, in JSON-LD, against iSHARE credential schemas. Validation is distributed: each verifier checks the presentation, the issuer's anchoring and the status list, and consults the Participant Registry for current state. No central verification service mediates transactions.

Decided Standards required for claims formatting: W3C VC and JSON-LD, with SHACL validation. ISO CASCO / ISO-IEC 17000 attestations are recognised where a participant holds them, rather than required of everyone.

Decided Revocation and suspension of credentials run through status lists plus registry state, propagating automatically to policy enforcement. Suspension is reversible; revocation is final; both are immediate in effect.

Proposed Dynamic attributes: verification does support attribute-based decisions through the policy information points — credential status, registry state and consent state are all evaluated at decision time rather than cached at onboarding, which is what makes revocation meaningful. Whether the LDT needs a Dynamic Attribute Token in the IDSA sense is a different question and the answer is no: the scheme's PIP model covers the requirement without adding a second token format.

Needs owner iSHARE: confirm, since the DAT question touches cross-framework interoperability with IDSA-based spaces.

4. Registry & Transparency#

Purpose: Create transparent, discoverable registries of trust entities to support verification and compliance.

  • What type of registry will store accredited and revoked trust entities?
  • How will participants and third parties discover and verify trust entities?
  • Will registry entries be machine-readable for automated compliance checks?

LDT answer DRAFTED · owner: iSHARE · due no date set

Decided The iSHARE Participant Registry, operated by iSHARE Foundation and the scheme's only authoritative trust anchor, stores accredited and revoked entities, with revoked and suspended status visible. It is machine-readable and supports automated compliance checks — this is a property the scheme depends on rather than a convenience, because policy decisions consult it at decision time. The Satellite admits the legal entity and issues the Participant Credential into the participant's own wallet; this is part of iSHARE's standing scheme operations rather than a pilot-specific service. iLabs operates the ITB-S conformance lab, the development sandbox and the reference trust gateway, and issues no credentials and provides no wallets. (Source: PD4 v1.0 §2 Table 1 and §3 — text as in PD4 v0.96, 29 Oct 2026.)

Decided Participants and third parties discover and verify through the registry plus the status lists; conformance evidence from the ITB-S is published there and surfaces in the Marketplace of the EU LDT Toolbox, where it gates certified badges.

Proposed Transparency boundary, which the scheme has not yet drawn and should: the fact of participation and current status should be visible to all participants, because a counterparty needs to verify who it is dealing with. Reasons for suspension or revocation should not be — publishing them turns the registry into a reputational sanction the scheme never agreed to impose, and the sanction ladder in Regulatory compliance does not include one.

Proposed Whether the registry is publicly readable or participants-only follows the same decision as the scheme's own publication. That scheme publication is currently public — the repository and the Pages site are readable without a login, checked 29 October 2026 — which makes a participants-only registry the harder position to hold rather than the default one. See Organisational form & governance authority section 3.5, where the ratification sits with TIPS.

Needs owner iSHARE: registry availability expectations and correction procedure for erroneous entries, both missing. The registry is operated by iSHARE Foundation per PD4 v1.0 §3, so these belong to the Scheme Owner rather than to the ITB-S operator.

5. Leveraging Existing Frameworks#

Purpose: Integrate and adapt existing trust frameworks to meet high-risk requirements.

  • Which existing trust frameworks will the data space leverage (Gaia-X, iSHARE, IDSA, domain-specific)?
  • How will the data space extend these frameworks for domain-specific needs?
  • Will stricter trust criteria be applied for high-risk data or sensitive transactions?
  • How will cross-framework interoperability be proven (conformance testing, cross-certification, or mapped profiles)?

LDT answer DRAFTED · owner: iSHARE · due no date set

Decided The LDT leverages the iSHARE (DataRights) Trust Framework 3.x as its trust layer, with eIDAS 2.0 for identity and credentials and Gaia-X alignment at the descriptive level. IDSA is not adopted; the LDT uses EDC as a connector, which is IDSA-adjacent technically, without adopting IDSA's trust model.

Decided Extension for domain-specific needs happens in three places, all recorded: Commons controls for citizen and community data, the Observer role, and non-EU credential flows for Aruba. These are the scheme's genuine extensions beyond the framework, and Alignment with the iSHARE Trust Framework requires each block to say which of adopted / profiled / extended applies to it.

Decided Stricter criteria for high-risk data are set per use-case profile on top of the baseline — citizen-related twin data and commercially sensitive operational data being the two categories in play.

Proposed Proving cross-framework interoperability: through ITB-S conformance testing for the technical layer, and through mapped profiles rather than cross-certification for the governance layer. Cross-certification would require the LDT to be a certifying body, which it is not and does not intend to become. For a counterparty on a different framework, the route is a recognition arrangement decided by iSHARE Foundation and TIPS.

Needs owner iSHARE: whether any such arrangement is anticipated within the pilot. Nothing in the use cases currently requires one.