Guiding questions — Participation management#

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

Building block G3 · owner(s) iSHARE + iLabs (input: HyEnSys, Aegean, Almelo Energie) · 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.

1. Defining Participant Roles#

Purpose: Clarify the entities and actors engaging in the data space, their categories, rights, and responsibilities.

1.1 Participant Categories#

Who are the Data Providers, Data Users, Data Rights Holders, Intermediaries, and Operators?
Should additional roles, such as Data Space Members or Governance Authority Members, be defined?
How should intermediary and operator roles be formally defined?
What are the distinctions in access, rights, and obligations among different roles?

LDT answer DRAFTED · owner: iSHARE + iLabs (input: HyEnSys, Aegean, Almelo Energie) · due 26 Sep 2026

Decided The LDT uses the iSHARE Trust Framework role model, with one addition:

Role	In the LDT
Data Provider	cities, FHC Corp, Hamburg Port, LogiNex, Almelo Energie
Data Consumer / User	any participant consuming under a policy; service providers acting for one
Data Rights Holder	including citizens for community and movement data (Aadorp PED, Cartagena LEZ)
Service Provider	Nunsys (Marketplace of the EU LDT Toolbox), LogiNex (analytics), HyEnSys, Aegean
Scheme Owner	iSHARE Foundation — exclusive
Registry / Operator	iSHARE Foundation (Satellite, iSHARE Participant Registry — the only authoritative trust anchor), iLabs (ITB-S conformance lab, development sandbox, reference trust gateway), Nunsys (Marketplace of the EU LDT Toolbox)
Observer	LDT-specific: cities and organisations following via dashboards or the AI observer chatbot without contributing data

Proposed No further roles are created. The template asks after "Data Space Member" and "Governance Authority Member" as separate categories; in the LDT, membership is an attribute of a participant (it holds a valid accession agreement and a participant credential) rather than a role of its own, and governance participation follows from being a consortium partner. Inventing roles that carry no distinct rights would make the credential model harder without making anything clearer.

Distinctions in access and obligation are expressed as credentials and policies, not as prose: a role is meaningful in this scheme precisely to the extent that a PDP can act on it.

1.2 Role-Specific Responsibilities#

What responsibilities do different participant types hold regarding data quality, compliance, and technical readiness?
How will intermediary services (e.g. service brokers, trust anchors) be governed as participants?

LDT answer DRAFTED · owner: iSHARE + iLabs (input: HyEnSys, Aegean, Almelo Energie) · due 26 Sep 2026

Proposed Responsibilities by role, stated so each is checkable:

Data Provider — accurate description (policy-complete, per Descriptions), a lawful basis for what it contributes, a stated quality level and update frequency, and an ODRL policy that actually expresses its terms.
Data Consumer — honours the policy attached to data it receives, including after transfer; no re-identification where aggregation floors apply; keeps credentials valid.
Data Rights Holder — exercises rights through the Commons controls or directly; carries no technical obligation.
Service Provider — documented and auditable methodology where it makes claims (CO₂ savings above all), and data access through the scheme's enforcement layer rather than around it.
All — maintain valid credentials, pass ITB-S conformance for production exchange paths, and accept the audit trail.

Decided Intermediaries and operators are governed as participants and as operators: they hold the same accession obligations, plus a service agreement and TIPS oversight, plus the neutrality rule — they act under the scheme's rules, not their own. Operator continuity and failure arrangements sit in the Contractual framework.

1.3 Additional: Strategic Questions#

Who are the internal and external stakeholders affected by the data space?
How can underrepresented stakeholders be included in decision-making?
What roles will each stakeholder assume within the data space?
How will participant roles be formalised in the Rulebook?

LDT answer DRAFTED · owner: iSHARE + iLabs (input: HyEnSys, Aegean, Almelo Energie) · due 26 Sep 2026

Proposed Internal stakeholders are the 11 consortium partners. External stakeholders affected without being participants are the ones worth naming, because the scheme has obligations toward them and they have no seat: residents of Aadorp and Cartagena whose data the twins carry, grid parties in the PED case, regional and national authorities receiving evidence from the twins, and supporters such as Hamburg Port Authority (supporting stakeholder, letter of support) and Esri (letter of support, 9 January 2026; intended subcontractor to iLabs, subject to procurement).

Underrepresented stakeholders — citizens, in practice — are included through two mechanisms rather than consultation alone: the Commons controls, which give communities a say in how their data is used, and the engagement work by the University of the Aegean. Whether that amounts to real inclusion is a fair challenge, and PD4 should not claim more than it can show.

Roles are formalised in this scheme by being made enforceable: a role in the rulebook corresponds to a credential type, a registry entry and a policy attribute. See Identity & attestation.

Needs owner HyEnSys + Almelo Energie + Aegean: how community representatives are mandated, and how a Commons decision maps onto a scheme role. This is the open 🧩 on the block page and the main unanswered question in this block.

2. Onboarding Procedures#

Purpose: Ensure structured and transparent integration of new participants.

2.1 General Terms and Conditions#

What common terms (admission criteria, rights, duties, access policies) apply to all participants
How are terms tailored based on data type (e.g., environmental, personal, sensitive) and regulation?

LDT answer DRAFTED · owner: iSHARE + iLabs (input: HyEnSys, Aegean, Almelo Energie) · due 26 Sep 2026

Decided Common terms apply to every participant through the accession agreement regardless of role: admission criteria, maintenance of valid credentials, honouring attached policies, acceptance of the audit trail, and the dispute ladder. One signature, all layers.

Proposed Terms are tailored by data type rather than by participant, which is what lets a single accession agreement serve a municipality and a commercial operator:

Data type	Additional terms
Open / public-tier	publication conditions, attribution, no re-identification attempts
Restricted (consortium or use-case)	purpose limitation, onward-sharing prohibition, derived-indicator rights
Commercial	marketplace ToU, transaction terms, confidentiality
Personal / citizen-related	GDPR basis per PD1, Commons mediation, aggregation floors, consent state as a policy input
Non-EU transfer (Aruba)	transfer mechanism and applicable-law clauses

Each row attaches as an annex module, so a participant signs only what it incurs.

2.2 Pre-Conditions for Entry#

What eligibility criteria must be met (e.g., compliance checks, identity verification, technical requirements)?
What attestation mechanisms will be used (first-, second-, or third-party)?

LDT answer DRAFTED · owner: iSHARE + iLabs (input: HyEnSys, Aegean, Almelo Energie) · due 26 Sep 2026

Decided Four conditions, all verifiable before admission:

Legal identity — the Satellite verifies the legal entity by a registered identifier (EORI, or EUID where no EORI exists); DIDs where wallet flows require them. Open: the party-identifier decision (iSHARE DID as key, EUID/EORI associated) is open with TIPS (PD4 Table 3, target M8).
Signed accession agreement, plus the annexes for the activities undertaken.
Technical conformance — ITB-S validation of the exchange paths to be used in production.
Role eligibility — the attestations the role requires.

Proposed Attestation mixes all three parties the template distinguishes, by risk:

First-party (self-declaration) — sufficient for low-risk attributes: contact points, declared purpose, open-tier publication intent.
Second-party — iSHARE Foundation and iLabs verify identity, registry status and ITB-S conformance. This is the default for the LDT.
Third-party — required where an external regime already governs the claim: eIDAS trust lists for legal identity, and accredited certification where a participant asserts it.

Needs owner iSHARE legal: whether baseline legal compliance (a GDPR posture statement, say) should be an entry requirement or a contractual warranty. The scheme currently assumes the latter; that assumption has not been tested.

2.3 Onboarding Process#

Will onboarding be application-based or automatic upon fulfilling conditions?
How will conformity be assessed? What mechanisms verify adherence to governance policies?
How will candidates be notified of approval or rejection?

LDT answer DRAFTED · owner: iSHARE + iLabs (input: HyEnSys, Aegean, Almelo Energie) · due 26 Sep 2026

Decided Onboarding is application-based, not automatic. The flow: application → eligibility check per role → ITB-S conformance test → registration in the Participant Registry → credential issuance as verifiable credentials → listing on the Trusted List where applicable.

Automatic admission on fulfilling conditions was considered and is not adopted: the scheme admits participants who will hold municipal and citizen-related data, and a human decision point before that is proportionate.

Proposed Conformity is assessed in two distinct places, which should not be conflated in PD4 — ITB-S tests the technical exchange and produces evidence; the registry records the administrative state. Neither constitutes iSHARE certification, which only iSHARE Foundation grants under its own scheme.

Notification: the applicant is informed of approval or rejection with a reason, and a rejection names the condition that failed and whether it is remediable. An applicant rejected without a reason has no route to fix anything, which is a participation barrier disguised as rigour.

Needs owner iLabs: expected throughput times per step. The register's 🧩 asks for exactly this, and without it the scheme promises a process whose duration nobody can state.

2.4 Post-Onboarding Support#

How will access credentials be issued?
What technical support will be provided to ensure seamless integration?
How will continuous monitoring and feedback loops be implemented?

LDT answer DRAFTED · owner: iSHARE + iLabs (input: HyEnSys, Aegean, Almelo Energie) · due 26 Sep 2026

Decided Credentials are issued as W3C Verifiable Credentials over OpenID4VC, anchored by iSHARE Foundation via the iSHARE credential-issuer components, with revocation through status lists plus Participant Registry state.

Proposed Technical support during integration comes from iLabs via the ITB-S, which doubles as the sandbox a new participant tests against before production — the test environment is the support mechanism, which keeps the burden proportionate.

Continuous monitoring uses the trust signals already defined for Provenance, traceability & observability: conformance status, policy-check outcomes and incident statistics, reported to TIPS monthly. No separate monitoring regime is created.

Feedback loops: participants raise issues against the scheme in this repository, and the WP4 lead brings recurring ones to TIPS. That is the same channel partners use to contribute building blocks, deliberately — one route in, not two.

Needs owner iLabs + Nunsys: what support you can actually commit to, and with what response expectation. The service agreements, not this page, are where that becomes binding.

2.5 Additional Strategic Questions#

What rules and mechanisms ensure onboarding supports legal compliance (e.g. GDPR)?
How is access managed and monitored post-onboarding?
How can onboarding lower participation barriers while maintaining data quality?

LDT answer DRAFTED · owner: iSHARE + iLabs (input: HyEnSys, Aegean, Almelo Energie) · due 26 Sep 2026

Proposed Onboarding supports legal compliance by making the lawful-basis question unavoidable at the point of entry rather than at the point of incident: a participant declares, per offering, the basis on which it contributes and the policy under which it may be used, and that declaration is part of the description the scheme validates. GDPR specifics follow PD1 and are cross-referenced.

Post-onboarding access is managed through credentials and registry state rather than through access lists: revocation or a status change propagates automatically to policy enforcement, so removing access is one action rather than a sweep across systems. Monitoring is the audit trail.

Lowering barriers without losing quality — the honest answer is that the LDT lowers barriers for Observers and keeps them high for Data Providers, which is the right asymmetry. An organisation that only wants to follow the twins should not have to pass a conformance test; an organisation publishing data that will inform municipal policy should. The Observer role exists precisely so that the scheme can say yes to the first without weakening the second.

Decided Hamburg Port was the live test of this, and PD4 §2 resolves it without a new instrument: Hamburg Port Authority supports EUTwinLink through a letter of support and interconnects its own LDT with the network at its own expense; it is not a funded partner, and the deliverable records no obligations for it beyond that letter. A supporter in that position needs no accession document, because it takes on no scheme obligations — the asymmetry above is enough. The lightweight Observer/associate accession therefore stays a design option for a future supporter that does want scheme-backed rights, rather than an outstanding deliverable. (Source: PD4 v1.0 §2 — text as in PD4 v0.96, 29 Oct 2026.)

3. Data Transaction Enablement#

Purpose: Facilitate secure, interoperable data sharing among participants.

3.1 Operational Enablement#

How are participants technically enabled to publish or consume data services/products?
How are mismatches between supply and demand identified and addressed?

LDT answer DRAFTED · owner: iSHARE + iLabs (input: HyEnSys, Aegean, Almelo Energie) · due 26 Sep 2026

Decided A participant is technically enabled to publish or consume through the stack the scheme already fixes: an EDC connector with the iSHARE extension for exchange, a policy-complete DCAT-AP description carrying its ODRL policy, a marketplace listing for discovery, and a participant credential that the PDPs can act on. City twins publish dynamic data through NGSI-LD brokers (MIM2); geo layers remain available over OGC services, non-ESRI-portable.

Proposed Supply–demand mismatches surface in two places and should be read together: the marketplace, where searches that return nothing are the cheapest signal a data space gets, and the use-case profiles, where each profile lists the sharing rules it needs from the scheme. A rule a profile needs and the scheme does not provide is a mismatch in the governance layer rather than the data layer, and it is the kind this scheme is responsible for closing.

Needs owner Nunsys: whether the marketplace can report unmatched searches at all. The mechanism above assumes it can.

3.2 Governance Adaptation#

What feedback mechanisms exist to update governance rules as the ecosystem scales?
How are new sectors, countries, or regulatory updates incorporated?

LDT answer DRAFTED · owner: iSHARE + iLabs (input: HyEnSys, Aegean, Almelo Energie) · due 26 Sep 2026

Proposed Three feedback routes, each with a named destination rather than a general invitation:

From operations — trust signals and incident statistics to TIPS monthly; a recurring policy failure is a governance defect, not an operational one.
From use cases — each profile's "sharing rules this use case needs from the scheme" is a standing requirements list; an unmet entry is an open item against the responsible block.
From upstream — template and framework drift, detected in CI and taken to TIPS block by block (Alignment with the iSHARE Trust Framework).

New sectors, countries and regulatory updates enter through the same change procedure. The LDT already has the hard version of this problem in miniature: Aruba is a non-EU jurisdiction inside the pilot, so the scheme cannot treat cross-jurisdiction participation as a future concern — it is a present one, handled in Regulatory compliance.

3.3 Additional Strategic Questions#

How does the governance authority promote seamless data transactions?
What procedures exist to attract new participants based on ecosystem gaps?
How is the Rulebook updated to reflect evolving business, technical, or legal needs?

LDT answer DRAFTED · owner: iSHARE + iLabs (input: HyEnSys, Aegean, Almelo Energie) · due 26 Sep 2026

Proposed The governance authority promotes transactions mainly by removing the need to negotiate each one: standard licences from the iSHARE Licence Catalog, standard ODRL templates, and a single accession agreement mean two participants who have both joined can exchange data without drafting anything. Bilateral annexes exist for genuinely bespoke cases and should stay rare — every annex is a transaction cost the scheme failed to absorb.

Attracting participants to fill ecosystem gaps is not yet a defined activity and should not be claimed as one. The known gaps are visible in the use-case profiles: grid-party involvement in the PED case is marked unconfirmed, and the Hamburg interconnection lacks an owner.

Rulebook updates follow the change procedure, with the standing rule that silence is not approval: a block left OPEN past its due date is escalated by the WP4 lead at the next TIPS rather than quietly carried forward.

Needs owner ERTICO + iSHARE: participant recruitment after the pilot belongs to the exploitation case and has no owner in the register today.

4. Offboarding Procedures#

Purpose: Ensure smooth and secure participant exits while safeguarding ecosystem integrity.

4.1 Exit Scenarios#

What are the valid reasons for offboarding (voluntary, non-compliance, insolvency)?
How are these scenarios managed differently?

LDT answer DRAFTED · owner: iSHARE + iLabs (input: HyEnSys, Aegean, Almelo Energie) · due 26 Sep 2026

Proposed Four valid exit scenarios, handled differently because the risk differs:

Scenario	Handling
Voluntary withdrawal	notice period; obligations toward data already shared survive exit; orderly credential expiry
Non-compliance	suspension first (credential status change, listing withdrawn), with a remediation window; termination only if remediation fails
Insolvency or dissolution	immediate suspension of access; continuity of any operator function it performed invoked under the service agreement
End of the pilot	not an exit at participant level — it is a question about the scheme's continuation, see Organisational form

The distinction that matters operationally: suspension is reversible and fast; termination is final and slow. Collapsing them into one action would mean the scheme either over-reacts to a lapsed credential or under-reacts to a real breach.

Decided The durations are in the Consortium Agreement. The remediation window is 30 calendar days from receipt of the Coordinator's written notice; after that the General Assembly may declare the party a Defaulting Party. Meeting notice is 45 calendar days for an ordinary General Assembly and 15 for an extraordinary one, and a decision taken without a meeting binds once the chair notifies acceptance. (Source: LDT4SSC–EUTwinLink pilot Consortium Agreement, signed by all eleven parties.)

Needs owner iSHARE legal: the same durations for a scheme participant that is not a consortium party — the accession agreement has to carry its own, and whether it mirrors the 30 days is a drafting choice nobody has made.

4.2 Offboarding Process#

What formal steps must participants follow to exit the data space?
How are obligations verified (e.g., contractual closure, data deletion, financial settlement)?
What support is provided during the offboarding transition?

LDT answer DRAFTED · owner: iSHARE + iLabs (input: HyEnSys, Aegean, Almelo Energie) · due 26 Sep 2026

Proposed Formal steps: notice to the WP4 lead and the registry operator → settlement of outstanding obligations (contractual closure, financial settlement where the marketplace is involved, data handling per the terms under which data was received) → registry status change → credential revocation → withdrawal of marketplace listings → notification of counterparties.

Decided Obligations on exit are set by the Contractual framework, not by this page. The scheme's part is mechanical: revocation and registry status change propagate automatically to policy enforcement, so an exited participant loses access without anyone sweeping systems by hand.

Proposed Support during transition is deliberately modest — export of the participant's own catalogue entries and a record of the policies under which it received data, so it can evidence its own compliance afterwards. A participant that cannot show what it was permitted to do with data it still holds is a liability to itself and to the scheme.

Needs owner The hard case nobody has addressed: data already transferred cannot be recalled. What survives exit — deletion duties, retention for audit, continued honouring of usage policies — is a contract question for iSHARE legal, and the answer should be written into the accession agreement rather than inferred.

4.3 Post-Exit Oversight#

How are affected parties notified?
How is identity and access removed from registries and systems?
How are participant credentials managed after exit (revocation, expiration)

LDT answer DRAFTED · owner: iSHARE + iLabs (input: HyEnSys, Aegean, Almelo Energie) · due 26 Sep 2026

Proposed Affected parties are notified through the registry rather than by correspondence: the Participant Registry is the authoritative source of participant state, it is machine-readable, and counterparties' PDPs consult it. Direct notice goes to parties in an active data-sharing relationship, identified from the audit trail.

Decided Identity and access removal: registry status change plus credential revocation via status lists. Both propagate to policy enforcement automatically — this is the same mechanism as suspension, at a different status.

Proposed Credentials after exit are revoked, not merely expired. Expiry would leave a window in which a departed participant still presents a valid credential, and the length of that window would be an accident of issuance dates. Revocation entries are retained after exit, because an audit covering a past period needs to show that the credential was valid then — deleting the record would destroy the evidence the audit trail exists to provide.

Retention of the exited participant's audit entries follows the scheme's general retention rule (5-year grant anchor), not the participant's wishes.

4.4 Additional Strategic Questions#

What rules define contract and data handling obligations upon exit?
How are security and data sovereignty ensured during offboarding?
How frequently is the offboarding framework reviewed and updated?

LDT answer DRAFTED · owner: iSHARE + iLabs (input: HyEnSys, Aegean, Almelo Energie) · due 26 Sep 2026

Proposed Contract and data-handling obligations on exit are set in the accession agreement and the data-sharing terms; this block provides the mechanism, not the obligation. The principle: policies attached to data survive the exit of the party that received it, because the alternative is that leaving the scheme launders the terms.

Security and sovereignty during offboarding rest on the propagation path being automatic and on revocation rather than expiry (see 4.3). The residual risk is data already held, which no technical control reaches — that is why it is a contract clause.

Review frequency: the offboarding framework is reviewed at TIPS annually, and after any actual offboarding, whichever comes first. The LDT has not offboarded anyone, so none of this has been tested against reality.

Needs owner iSHARE legal + iLabs jointly: this whole section is drafted from the scheme's own logic rather than from a decision. The offboarding path is the least exercised part of the participation model and the one most likely to be wrong.

5. Additional Strategic Questions#

To support stakeholder co-creation and governance design.

How will participation policies foster inclusivity and trust while maintaining regulatory rigour?
What role does the Rulebook play in managing expectations across use cases and participant types?
How can the governance authority continuously improve the efficiency of onboarding and offboarding processes?
How are external stakeholders’ concerns incorporated, even if they are not direct participants?
What mechanisms exist for conflict resolution between participants during their lifecycle?
How can collaboration be strengthened across the ecosystem?
Which mechanisms encourage active engagement from all participant types?

LDT answer DRAFTED · owner: iSHARE + iLabs (input: HyEnSys, Aegean, Almelo Energie) · due 26 Sep 2026

Proposed Taking the template's seven questions together, the honest summary of the LDT's position:

Inclusivity with rigour — handled by role asymmetry: low barriers for Observers, high barriers for Data Providers (see 2.5). Citizens participate through the Commons controls rather than through membership.
What the rulebook manages — expectations across very different participants: two municipalities, a non-EU airport, a port, commercial service providers and a citizen community. The scheme's answer is a common baseline plus stricter use-case layers, never weaker ones.
Improving onboarding efficiency — measured through the trust signals and throughput times, once iLabs has stated them. Currently unmeasurable.
External stakeholders' concerns — residents through Commons and the Aegean engagement work; supporters through the Observer role; authorities through the evidence the twins publish. None of these groups has a vote, and PD4 should say so plainly rather than describe consultation as governance.
Conflict resolution during the lifecycle — the Consortium Agreement ladder, extended to non-CA participants through the accession agreement (see Organisational form 2.4).
Strengthening collaboration and encouraging engagement — the pilot's real mechanism is the co-creation process itself: partners write the rules they will operate under. Its effectiveness is testable and currently untested — 0 of 125 answer slots were filled by the v0.5 deadline of 26 September 2026, which is the most useful engagement signal the scheme has produced so far and belongs in the PD4 lessons-learned rather than being left out of it.