> For the complete documentation index, see [llms.txt](https://frameworks.greendealdata.eu/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://frameworks.greendealdata.eu/governnace-frameworks/gdds-rulebook/data-sovereignty-and-technical-governance/1.-data-access-and-usage-policy-governance.md). # 1. Data access and usage policy governance This subsection details the governance of data access and usage. It expands the Layer 2 Governance capabilities (see here) that list the requirements from the Use Cases for Data Sovereignty & Technical Governance into the governance rules that realise them and cross-references the Technical Framework (see Data Sovereignty & Trust — Access & Usage Policies Enforcement) for the enforcement mechanisms. This section also refers to the iSHARE Trust Framework. {% hint style="warning" %} *This section will be further modified, and additional information will be added to it after the development in WP4, WP3, and WP6. Therefore, this section is an initial draft.* {% endhint %} ## 1.1 Access is never implicit ### Rule Access to data in the GDDS is never implicit. A Data Provider, or the Data Rights Holder on whose behalf it acts, defines the access and usage conditions attaching to each data product, and those conditions govern every subsequent access. Data may be accessed, shared, or reused only within the limits the provider has set, and only by participants whose verified identity and attributes satisfy those conditions. ### Procedure Access and usage conditions are expressed as machine-readable policies attached to the data product and evaluated at the point of exchange against the requesting participant's verified identity and attributes. The attributes themselves are established under Trust & Participation Governance (identification and credential enrichment); this subsection governs how a provider's policies consume them. Access decisions rest on the verification of delegation evidence and claims against trusted registries and policies; the protocols, the policy-evaluation points, and the runtime evaluation of delegation evidence are specified in the Technical Framework (see [here](/12-data-sovereignty-and-trust/access-and-usage-policies-enforcement.md)). ### Responsible body The Data Provider / Data Rights Holder defines and maintains the conditions for its own data. The governance authority maintains the rules within which those conditions operate. The GDDS Operator and the relevant trust services (notably the Authorisation Registry) enforce them technically at the exchange. *** ## 1.2 Licensing models and the GDDS reference library ### Rule Licensing and usage rights must be clearly defined, accessible, and consistently applied across the data space. The GDDS supports multiple licensing models, and each carries enforceable usage conditions, not merely descriptive terms. ### Procedure The GDDS maintains a[ reference library](#user-content-fn-1)[^1] of licence templates and standard usage-policy types available to data holders, so that conditions are expressed consistently and are comparable across participants and sites. Standard usage conditions follow the iSHARE machine-readable licence model (for example: internal-use-only, resharing restricted to adhering parties, certification-linked, or country/sector-restricted). The GDDS may define additional licence types or constraints where Green Deal use cases require them. The encoding of these licences as machine-readable policies, and their evaluation at exchange, are specified in the Technical Framework (see [here](/12-data-sovereignty-and-trust/access-and-usage-policies-enforcement.md)). ### Responsible body The DSGA owns the GDDS reference licence library and approves additions to it. The Data Provider / Data Rights Holder selects and applies licences to its own data products. *** ## 1.3 Custom and conditional policies ### Rule Where the standard licence library is insufficient for a participant's needs, custom access policies are permitted, including conditional constraints such as time-bounding, purpose limitation, use-case scoping, and geofence-based (geographic) rules. Custom policies operate within limits set by GDDS governance and may not be used to circumvent baseline obligations. ### Procedure A participant requiring conditions beyond the reference library defines a custom policy, which is subject to the approval path and constraints set by the governance authority. Delegation may be conditional and may form hierarchical delegation chains, evaluated at runtime. The expression and runtime evaluation of conditional and custom policies are specified in the Technical Framework (see [here](/12-data-sovereignty-and-trust/access-and-usage-policies-enforcement.md)). ### Responsible body The DSGA defines the conditions under which custom policies are permitted and the approval path for them. The Data Provider / Data Rights Holder defines the custom policy for its own data. {% hint style="warning" %} *Note (decided / open): The Layer 2 capability for custom and geofence-based policies is confirmed as in scope. The approval path for custom policies (who reviews and authorises them, and against what criteria) is to be defined. Owner: WP4, with WP3 for technical feasibility.* {% endhint %} *** ## 1.4 Selective sharing and delegation of rights ### Rule Data owners may selectively share and delegate, access and usage rights over their data. Delegation transfers a defined, bounded permission to another participant; it does not transfer ownership or the underlying rights, and it remains subject to the data owner's conditions and to revocation. ### Procedure Delegation is expressed as verifiable delegation evidence and evaluated at runtime by the Data Provider through the Authorisation Registry. Delegation can be conditional and can form hierarchical chains. The technical representation and evaluation of delegation evidence are specified in the Technical Framework (see here); the special onboarding scenarios involving mandates and delegation of representation are addressed under Trust & Participation Governance, Stage 3 (see [here](/governnace-frameworks/gdds-rulebook/trust-and-participation-governance/stage-3-onboarding-and-assignment-of-roles-and-access-rights.md)). The governed form of a delegation is the delegation evidence itself: it carries a validity period, the issuer and the subject, a maximum delegation depth, and one or more policies specifying the target resources, the permitted actions, the applicable licences, and the conditions of use. A delegation may be presented by the consumer (which fetches the authorisation from the Authorisation Registry and presents it to the provider) or requested by the provider from the Authorisation Registry, and both machine-to-machine and human-to-machine patterns are supported. These structures and patterns are specified in the Technical Framework (see Data Sovereignty and Trust — Trust Framework, “Delegation evidence structure and authorisation patterns”). *Source: D3.1 GDDS first version report (WP3), §2.2.2 (Working Group 3).* ### Responsible body The Data Rights Holder grants and may revoke delegations over its data. The Authorisation Registry (a certified role) evaluates delegation evidence at the exchange. *** ## 1.5 Granular and tiered access control ### Rule Access control operates at a granular level, down to the data-asset level, using role-based (RBAC) and attribute-based (ABAC) models, so that permissions can be matched precisely to participant types, roles, and verified attributes. ### Procedure Secure authentication and role-based access control are enforced across all participant types as a baseline; attribute-based control enables finer-grained decisions based on enriched, verified credentials. The GDDS supports a progression from manual validation by data providers, used where automated attribute-based rules are not yet established, toward automated access control, with GDDS governance and technical support for that evolution. The access-control models, and encrypted access control and data segmentation at the technical layer, are specified in the Technical Framework (see [here](/12-data-sovereignty-and-trust/access-and-usage-policies-enforcement.md)). ### Responsible body The Data Provider / Data Rights Holder sets the access conditions for its own assets. The GDDS Operator and trust services enforce authentication and access control across the data space (see [here](/12-data-sovereignty-and-trust/access-and-usage-policies-enforcement.md)). *** ## 1.6 Access-policy filtering at discovery ### Rule Access conditions apply not only at the point of data exchange but also at discovery: a participant's view of available data products may be filtered according to its verified attributes, so that participants see and can request only what they are eligible to access. ### Procedure Discovery queries are filtered against consumer attributes, consistent with the access policies attached to each data product. The interaction between discovery filtering and the catalogue is addressed in subsection 4 ([Registry and discovery governance](/governnace-frameworks/gdds-rulebook/data-sovereignty-and-technical-governance/4.-registry-and-discovery-governance.md)); the technical filtering mechanism is specified in the Technical Framework (see [here](/13-data-value-creation-enablers/publication-and-discovery.md)). ### Responsible body The governance authority sets the rules linking discovery visibility to access policy. The GDDS Operator and catalogue services apply the filtering. {% hint style="warning" %} *Note (MVP applicability): As documented by Working Group 3 in D3.1 (§3, Catalogue and Data Brokerage services), attribute-based filtering of the catalogue view is not included in the minimum feature set of the initial GDDS release (MVP1). This rule therefore describes the target state foreseen for MVP2; during MVP1, its application is limited to what the deployed components support, and it may evolve with the MVP2 design. Source: D3.1 GDDS first version report (WP3).* {% endhint %} *** ## 1.7 Consent management ### Rule Where data exchange involves personal data, the data subject's consent (or another valid legal basis) governs processing, and consent must be managed transparently and be revocable. ### Procedure (to be developed) This provision will set out the governance rules for capturing, recording, and revoking consent, and the relationship between consent, the data usage contract, and the legal basis for processing. Consent-management mechanisms are specified in the Technical Framework, and the legal basis is addressed in the Legal Framework. {% hint style="warning" %} *Note (content gap — to be developed): Consent-management requirements are to be specified from the use cases and WP6.* {% endhint %} {% hint style="warning" %} *Open stakeholder questions to resolve here: the data-sharing agreement template and mandatory minimum clauses — licence, liability, observability, dispute resolution (raised by a a participant); how sensitive and commercial datasets are classified and governed (raised by a a participant); whether GDDS access control should coordinate with the EU Digital Product Passport access-control system to avoid duplication (raised by a a participant); and two-layer access control with role-change and leaver handling — institution authenticated by a governance body, individual by their organisation (raised by a a participant). Owner: WP4, with WP6 for UC consent requirements and WP4 for legal alignment.* {% endhint %} [^1]: to confirm do we use the ishare licences as referance or we actually going to have gdds library?