Skip to content

Guiding questions — Access & usage policies enforcement#

Fork notice. The questions below are reproduced from the iSHARE Data Space Template page Access & usage policies enforcement → 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: Access & usage policies enforcement.

Building block T6 · owner(s) iSHARE + HyEnSys (sign-off: cities) · 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. Policy Scope & Governance#

Purpose: Define common baseline policies while allowing participants to set stricter rules within their domains.

  • Which common access and usage policies will the data space enforce platform-wide?
  • What is the minimum baseline for policy enforcement (security, privacy, sustainability criteria)?
  • Can participants define stricter policies within their own DUGs?

LDT answer DRAFTED · owner: iSHARE + HyEnSys (sign-off: cities) · due 26 Sep 2026

Decided Platform-wide enforcement uses the iSHARE ODRL profile, with usage terms bound to offerings through the iSHARE Licence Catalog (licenses.ishare.eu, binding artefact). Policies are machine-enforceable by design, with RBAC and ABAC.

Proposed The minimum baseline every exchange is subject to, regardless of offering:

  • Authenticated participant with a valid credential and registry status in good standing;
  • A licence and an ODRL policy attached — an offering without them is not listable, let alone transferable;
  • Declared purpose, carried in the request and evaluated;
  • No re-identification of individuals from any tier, including open;
  • Audit entry per decision;
  • Onward-sharing default is deny — redistribution requires explicit permission in the policy.

Decided Yes, participants may define stricter policies within their own use-case groups: the scheme sets the baseline, use-case groups (LEZ, PED, airport, Marketplace of the EU LDT Toolbox) may tighten it, and Commons controls govern citizen and community data on top. Weaker is never permitted, which is the rule that lets four very different sites share one baseline.

2. Policy Information Points (PIPs)#

Purpose: Specify shared registries and consent points that integrate with identity and trust services.

  • Which shared PIPs should the data space maintain (e.g., GDPR consent registry)?
  • How will PIPs integrate with the Trust Framework and Identity Management?
  • Should sector-specific consent management be centralised or left to DUGOs?

LDT answer DRAFTED · owner: iSHARE + HyEnSys (sign-off: cities) · due 26 Sep 2026

Decided Shared PIPs the scheme maintains: the Participant Registry (identity, role, status) and credential status (status lists). Both are consulted at decision time rather than cached, which is what makes revocation take effect immediately.

Decided Consent state is a PIP input where citizen data is in scope, with GDPR consent handling following PD1 rather than being re-specified here.

Proposed Integration with trust and identity is the point of the design: a policy decision evaluates the credential presented, the registry state of its holder and the policy attached to the asset, so identity, trust and policy are one decision rather than three systems that must agree. This is the main argument for not running a separate access-control regime alongside the trust framework.

Proposed Centralised or DUGO-level consent management: decentralised, with a scheme-level interface. Consent for Aadorp household data is mediated by the community through Almelo Energie and the Commons controls; consent for Cartagena LEZ data sits with the city. Centralising consent would put the scheme between a community and its own data, which is exactly what the Commons model exists to avoid. What the scheme standardises is the interface — how a consent state is expressed as an ODRL constraint — not the consent itself.

Needs owner HyEnSys — the Commons-controls 🧩, which is the specification this answer depends on and which does not exist yet.

3. Policy Lifecycle & Negotiation#

Purpose: Enable machine-readable policy agreements, revocations, and checks throughout the data lifecycle.

  • How will machine-readable agreements be negotiated (ODRL templates, bilateral APIs)?
  • At what points in the data transaction lifecycle will policy checks occur?
  • How will policy revocations be propagated across participants?

LDT answer DRAFTED · owner: iSHARE + HyEnSys (sign-off: cities) · due 26 Sep 2026

Decided Agreements are machine-readable by construction: an offering carries a licence reference plus an ODRL policy, and the EDC control plane negotiates against them. Standard terms cover standard cases; bilateral annexes exist for genuinely bespoke situations and should stay rare.

Proposed Negotiation uses ODRL templates derived from the Licence Catalog rather than free-form policy drafting. A participant selects terms; it does not author them. This is what keeps policies comparable across four sites and what makes automated evaluation possible at all — a data space where every policy is bespoke has machine-readable policies and no interoperability.

Proposed Policy checks occur at four points, and naming all four matters because missing any one of them opens a gap: catalogue visibility (what a participant may see), contract negotiation (what may be agreed), transfer initiation (what may be sent), and continuously for long-lived transfers (subscriptions and streams re-evaluated on credential or policy change).

Decided Revocation propagates through registry status change and status lists, automatically, to every enforcement point.

Proposed The known weakness, which PD4 should state rather than let an auditor find: revocation stops future access, it does not recall data already transferred. That is why usage policies must survive exit contractually (Contractual framework section 3).

4. Enforcement Architecture#

Purpose: Design a distributed or centralised enforcement system using standard policy decision and enforcement points.

  • Will the data space operate a central policy engine or federate enforcement to participants?
  • How will the PEP/PDP/PIP/PAP architecture be implemented in multi-cloud or hybrid environments?
  • What contextual data (identity, contract terms, asset metadata) will be required for decisions?

LDT answer DRAFTED · owner: iSHARE + HyEnSys (sign-off: cities) · due 26 Sep 2026

Decided Federated, not central. A PEP/PDP pattern at the connectors (EDC with the iSHARE extension), with the Participant Registry and credential status as shared PIPs. There is no central policy engine.

Proposed The reasoning belongs in PD4 because it is a governance choice presented as a technical one: a central engine would make one operator a chokepoint for every exchange in the data space, a single point of failure, and a party with visibility over every transaction between every participant. Federation costs consistency — each connector must evaluate the same policy the same way — and that cost is paid by the ITB-S, which tests exactly that.

Proposed Across multi-cloud and hybrid deployments the pattern holds because the PDP travels with the connector: each site runs its own, against shared PIPs. The PAP — where policies are authored and distributed — is the piece the scheme has not located: policies originate with the offering, but no component is named as the authoring and distribution point.

Decided Contextual data required for a decision: the presented credential and its status, registry state and role, the asset's metadata including its attached policy and licence, the declared purpose, and consent state where citizen data is in scope.

Needs owner iLabs: name the PAP, and confirm how policy updates reach every PDP.

5. Compliance Tracking & Proof#

Purpose: Provide audit trails, retention rules, and real-time alerts to ensure accountable policy enforcement.

  • How will audit trails be generated, stored, and accessed?
  • What is the retention period for enforcement proof?
  • How will the data space support real-time policy breach alerts?
  • Will conformance evidence (logs, proofs, certificates) be published to support audits and marketplace listing requirements?

LDT answer DRAFTED · owner: iSHARE + HyEnSys (sign-off: cities) · due 26 Sep 2026

Decided Every policy decision leaves an audit-trail entry; generation, storage and access follow Provenance, traceability & observability. Control-plane records are held at the registry and connector layer rather than only by participants, so the evidence survives a participant's exit.

Proposed Retention of enforcement proof: five years, anchored to the grant rules, consistent with the retention decision in the provenance block. Access is bounded — a participant reads entries concerning its own data and actions; the WP4 lead and TIPS read across participants only for a defined investigation.

Proposed Real-time breach alerts: the scheme should distinguish a denied request, which is the system working correctly and needs no alert, from a pattern — repeated denials against one asset, a surge from one participant, a policy failing open — which does. Alerting on every denial would make the signal useless within a week. Pattern detection feeds the monthly trust-signal report to TIPS, with immediate escalation to the WP4 lead for compromise indicators.

Decided Conformance evidence is published to the registry and affects marketplace listing, including certified badges.

Needs owner iLabs: whether pattern detection exists or is aspirational. This answer specifies a requirement, not an implemented capability.

6. Interlinkages & Dependencies#

Purpose: Align policies with trust, identity, and legal frameworks to create a coherent enforcement ecosystem.

  • How will Access & Usage Policies integrate with the Trust Framework?
  • How will identity attestations influence policy enforcement?
  • Which parts of the Legal Building Blocks must be mirrored technically here?
  • How will policy outcomes be reflected in discovery/marketplace visibility (e.g., eligibility, access tiers)?

LDT answer DRAFTED · owner: iSHARE + HyEnSys (sign-off: cities) · due 26 Sep 2026

Decided Integration with the trust framework is structural rather than an interface: a policy decision evaluates credential, registry state and attached policy together — see section 2. Identity attestations influence enforcement directly, since role, membership and conformance credentials are the attributes the ODRL constraints are written against.

Proposed Parts of the legal building blocks that must be mirrored technically here — this is the list that makes the scheme's "machine-enforceable where possible" rule concrete:

Legal provision Technical mirror
Licence terms per offering ODRL policy from the Licence Catalog
Purpose limitation declared purpose evaluated at the PDP
Aggregation floors, no re-identification ODRL constraints on citizen-related data
Onward-sharing restrictions redistribution denied by default
Non-EU transfer conditions (Aruba) policy constraint on the receiving participant's jurisdiction
Suspension and termination registry status change and credential revocation
Audit obligation audit entry per decision

What cannot be mirrored, and is therefore a contract clause by the scheme's own ground rule: what a participant does with data it already holds, and the survival of obligations after exit.

Decided Policy outcomes reach discovery directly: listing requires a policy-complete description, and conformance evidence gates certified badges in the marketplace (Publication & discovery).