Add the problem statement of the Data Holder to the IDSA Rulebook

The problem statement of the Data Holder should be included. Does this fit into the functional section?

Data Holders problem statement

With the launch of the European Data Governance Act, data Autonomy or sovereignty of organizations and persons across data providers has become a mandatory direction for data providers.

The Data Governance Act defines that Data Holders should be able to control what happens with their data registered at data service providers. This development provides a challenge to data service providers and existing connectors that are sharing data that is from another holder than the organization providing the data. Originally IDSA defined that the data provider is in complete control (data sovereignty) of what is happening with policies as it was the data provided by the data holder.

At the same time, the IDSA model considers organizations (participants) and the application context (Participant Agent / Connector) as relevant identities in an IDS Data Space. Individuals are currently not addressed in IDSA and the IDS Architecture. With the development and use of both Cloud service providers (SaaS) but also other Data Intermediaries like Utilities and many others, the situation where the data provider and the data holder are not the same entity will happen more and more.

The IDS architecture originated from the structure where data providers are the data holders since that makes a lot of sense in the Industry. A Service Provider may act on behalf of the Data Provider. But with the growing use of SaaS platforms and other service providers the Data Intermediary which operates data providers on behalf of the data holder and may act for multiple tenants on the same platform, urges for the introduction of a change to Policies Management.

Currently policies are stored within the Connector which is a good and secure structure. The connectors must respect policies and must handle them accordingly in their context, but also while redistributing data. But with the introduction of distributed policies, the need for a policy registry arises. In this registry, the data holder should be able to govern the data access and usage policies across multiple data providers ( connectors), which aligns with the direction in our original documentation on Usage and Access policies (link). To accommodate this need we are not reinventing the wheel with IDSA but aligning with the iSHARE framework where we align the legal, governance (ParIS), and authorization registry roles in iSHARE. This enables the IDSA community to benefit from the existing work and tools that are available already in the iSHARE framework. Where the Usage Control element still is in the Connector.

The role that will be added to the IDSA rulebook is the Authorization Registry that is supporting Data Holders to control their policies outside of the Connector, in case there are multiple connectors. The structure of Policies in IDSA and iSHARE align, both defining the same main components. But iSHARE adds a condition to the concept of the original usage control, which is the dynamic legal control and coverage with the use of the concept of Licences. These licences connect the Purpose of the data share to the usage rights. This is an enrichment to the IDS framework.

To follow this line of argumentation, the IDS concepts need to:

Add individuals (and their agents? IoT devices… smart meters) as manageable and identifiable entities in identity management, which is also relevant in the context of personal data spaces,
Consider Data Holders or entitle parties as a role in data spaces, (this term needs to be aligned with the DSSC Glossary)
Extend the Participant Information Service (ParIS) with additional functionality to handle individuals and the role of the data holders, (e.g. inform the data holder on data usage and request access)
Add the concept of the policy registry to the IDS concepts, which can act on behalf of the data holder to link between identifiable entities (individuals, organizations, connectors), data sets and related policies.

International-Data-Spaces-Association / IDSA-Rulebook

Add the problem statement of the Data Holder to the IDSA Rulebook #25