How about creating a "rolebook" to complement a "rulebook" to address these issues?

[viivilahteenoja]

          How about creating a "rolebook" to complement a "rulebook" to address these issues?

Originally posted by @viivilahteenoja in #53 (comment)

[viivilahteenoja]

sitra_towards_a_holistic_eu_data_governance-3.pdf
Online: https://media.sitra.fi/app/uploads/2023/09/sitra_towards_a_holistic_eu_data_governance-3.pdf

This publication includes the recommendation for a rolebook.

[PeterKoen-MSFT]

An entire Rolebook might be a bit overkill, but I would argue that this could be a dedicated chapter in the Rulebook.
We really need to get to the bottom of technical, business, legal role as there is so much confusion around that and it keeps coming back in so many discussions...

Do you want to start a fresh document on this that we can then later integrate in the Rulebook?
I think we could start with structure similar to this:

• Introduction

• Legal Roles

• list and explanation of Acts that we use as a basis

• legal roles, description and explanation with a reference to the source where they are mentioned

• Business Roles

• specific to a dataspace, what are their areas of responsibilities (define policies, list data, classify data protection, etc...)

• Technical Roles

• Participant

• Dataspace Governance Authority

• Examples

• Small/Medium Business

• Large/Complex Enterprise

• NGO/Data Altruism/Open Data

[PeterKoen-MSFT]

@viivilahteenoja are you still planning on drafting the roles document or can we close this issue?

[viivilahteenoja]

@PeterKoen-MSFT thanks for the nudge! This work has indeed found a home in the context of the DSSC rulebook project, so yes! I'll have a draft document this month.

[PeterKoen-MSFT]

Please, post a link here for review when it's available!
Thanks!

[viivilahteenoja]

Will do, would love your input @PeterKoen-MSFT esp. on the technical roles (although the perspective is mainly that of governance, it will include business, legal, and technical transaction participants and well as governance roles).

[PeterKoen-MSFT]

@viivilahteenoja - to share the latest role list/documentation from DSSC

We need to add a short explanation to the rulebook how this maps into IDSA understanding of roles vs participation

[viivilahteenoja]

From p. 48 onwards here: https://www.sitra.fi/wp/wp-content/uploads/2025/03/rulebook-model-for-a-fair-data-economy-part-2-v3d.pdf

[PeterKoen-MSFT]

Those roles are largely in the business domain and do not affect the technical setup of the dataspace. I would suggest to separate this from the IDSA definition of roles in a dataspace.

[mspiekermann]

IMHO on the technical level, we only have two mandatory roles, with provider and receiver* fulfilled by a participant (entity). Even the role of the governance authority is optional as provider and receiver might just bilaterally agree on rules. However as you mentioned there are several optional roles on other layers (business, legal, etc.) . I like the idea to have dedicated "papers" describing their role and impact as suggested in #64 for the intermediary.

For the Rulebook, we can highlight that it actually only takes a provider and consumer to make use of dataspace principles and further explain that there are other optional roles with references to the corresponding papers.

For newer versions of the Rulebook, one can propose additional roles by providing a description based on the initial examples (e.g. intermediaries, DSGA) and if accepted by IDSA community and TSC, it can be added in the role section as additional tuple of role and paper.

* there was the proposal to call it receiver in #74. However, I'd stick to consumer as it is common language for the general use of data. But, this discussion is independent from this issue.

[viivilahteenoja]

FWIW, this picture summarises my understanding of how data spaces in practice work and the kinds of roles involved.

[PeterKoen-MSFT]

This picture has several issues:

• The Governance Authority is not a container for Participants and Stakeholders. it's also rather a function than a role.
• The use cases are strictly bound to the economic/business and legal/regulatory layer of a dataspace. at the technical layer they are expressed through policies/claims and thus don't show up directly but are rather embedded in the contracts.
• At the technical level a dataspace has only 1 role: participants, who can have sub roles of provider and consumer
• A DSGA is a function/helper (to try to not have a confusing use of the term role) which aids in the setup of the governance model. A DSGA might be implemented by one participant, by a collection of participant, by an outsider (e.g. regulatory entity) or simply exist as a text file being passed on between participants that are interacting with each other.

Role is too universal as a verb and thus leads to the confusion of technical elements and business/regulatory elements. We need to find cleaner verbiage to help provide clarity.

[viivilahteenoja]

• The DSGA is indeed not a role, and I tried to indicate that roles are the grey boxes only.
• Indeed, this picture is not intended to be limited to the technical layer only, it intends to capture non-technical layers' roles as well.
• I think in this particular case our fundamental difference in view is that I see DSGA not as a function, but a body that has functions. As a body (made up of participants + optionally stakeholders) it by definition cannot be implemented itself, but each of its functions can be implemented by one or more participants, outsourced to non-participant service providers or other parties, or simply exist as a text file.

Hope that clarifies where I'm coming from!

[mspiekermann]

I tried to indicate that roles are the grey boxes only

Wouldn't still Service Provider, Offering Provider , and Offering consumer be just sub-roles of Participant, which should be reflected in the hierarchical illustration?

participants, who can have sub roles of provider and consumer

I'd say participant is the entity and provider and consumer are the roles. This would also be aligned with the DSP terminology. However, it might be again the issue with using the term entity, member (from DSP), role to too negligent. @ssteinbuss does ISO 20151 already have something concluded?