Update dataspace section #13
Conversation
|
"The rest of the community" is a bold statement, as the IDSA's definition is consistent with ISO 20151 and the EDWG's perspective. |
| Dataspaces are designed to enable software agents representing participants to negotiate data sharing contracts and to execute on those. A data sharing contract might represent a one-time data transfer, a continuous stream of data, or a regularly recurring event (e.g. regulatory data sharing obligations). Many of these activities will need to be automated to a degree where thousands of those negotiations and/or contract validations can happen in seconds. Take for example the use case of Manufacturing-X mentioned above: every single part of a car, plane, train, ship or sufficiently complex industrial goods needs to be accompanied by a Digital Product Passport, which needs to be shared throughout the supply chain and can benefit from full end-to-end traceability, keeping human-in-the-loop for consent when required and be fully automated between machine-to-machine otherwise. | ||
|
|
||
| Dataspaces are designed to enable software agents representing organizations to negotiate data sharing contracts and to execute on those. A data sharing contract might represent a one-time data transfer, a continuous stream of data, or a regularly recurring event (e.g. regulatory data sharing obligations). Many of these activities will need to be automated to a degree where thousands of those negotiations and/or contract validations can happen in seconds. Take for example the use case of Manufacturing-X mentioned above. If every single part of a car, plane, train, ship or sufficiently complex industrial goods needs to be accompanied by a Digital Product Passport, which needs to be shared throughout the supply chain it will be prohibitively expensive and slow to have each and every sharing contract agreed upon and approved by humans. Especially as the legal entities participating are companies and the human end user requesting the setup of a data sharing contract is at best metadata information to tie the contract negotiation to a legal representative of the organization. However, even in those cases the human end-user doesn’t need to be represented in the data sharing contract as a credentialed identity, as it’s always the organization that is the entity which needs identification and credentials. | ||
| To be noted that in many dataspace such as Health, Finance, Education&Skills, the policy, claims and evidences exchanged using verifiable credentials, can be bound to a human which is not necessarly a legal representative of a organisation. |
There was a problem hiding this comment.
#4 includes the discussion and explains how end users fit into the dataspace concept.
There was a problem hiding this comment.
The replies on #4 seems to reduce and limit dataspace to B2B, forcing natural person to go through a data intermediary or organisation's platform, like a proxy.
Considering the unbalanced power of economic or power asymmetries in negotiation between a natural Person and an organisation capable of providing such services , forbidding a natural Person to have direct participation in a dataspace and mandating the natural person to engage only via organisations, is a form of platform lock-in which is contradicting the vision of future fair and trustworthy data transactions for dataspaces.
The reasoning that managing personal data or sensitive data (as defined by GDPR and many other regulations outside of EU) is too complex to be part of a dataspace, and that dataspace actors should be limited to organisation or its representatives, does not represent everyone's view of what and who can participate in a dataspace.
I would agree that my statement are not suited for the EDWG/IDSA definition of dataspace if this paper starts with the definitions given for example by @PeterKoen-MSFT in #4 , otherwise a reader might conclude that ALL dataspaces are limited to B2B/organisations only.
EDWG/IDSA Dataspaces as a technical Design Pattern that enables trusted data sharing between organizations in a business & governance model neutral way.
Actors in EDWG/IDSA Dataspaces are Software Agents representing the organization participating in a EDWG/IDSA Dataspace.
Would such a clarification in the introduction of the paper be possible ?
There was a problem hiding this comment.
This paper is going to be published by IDSA. It will be unnecessary redundant to call out EDWG/IDSA everywhere, where Dataspaces are mentioned. Other organizations that disagree with the IDSA view are free to publish their own texts and to harmonize those texts with international standards, such as ISO20151
| As such, a dataspace gouvernance that does not require, rights delegation, consent management, mandate, nor any form of legally relevant claims and evidence traceability, can use DCP. | ||
|
|
||
| For other data space governances where end-to-end tracability of policy, claims and evidence are required, either due to policy compliance or regulatory compliance, the OID4VC protocol is better suited. | ||
|
|
There was a problem hiding this comment.
The used perspective on dataspaces within this IDSA's definition is consistent with ISO 20151 and the EDWG's perspective. This is not even contradicting the discussed concepts of Data Spaces Support Center, CEN/CENELEC Trusted Data Transaction, FIWARE, Gaia-X, it is just not mixing different perspectives and separates technology, business, and regulation layers.
I am not against highlighting the different perspectives (we again just have to refer #4 ) , but the statements made here in the PR are just wrong.
There was a problem hiding this comment.
@ticapix Also to clarify: You envision an environment where natural persons individually are operating and maintaining their technologies and applications for sharing data on their own? I doubt it!
Managing consent thus is not the responsibility of the underlying dataspace technology and provider of such need to enable the end user to do so.
IDSA has a clear picture of above mentioned layers and what they can bring to streamline such interactions.
Further publications about the identity and end-user perspective are upcoming. Your contribution ofc is welcome, at best within the corresponding working groups.
There was a problem hiding this comment.
@ticapix Also to clarify: You envision an environment where natural persons individually are operating and maintaining their technologies and applications for sharing data on their own? I doubt it!
Without going from one extreme (nothing) to another (full DIY), enabling natural person to directly interact in a dataspace doesn't prevent the natural person to optionally delegate rights to a service provider to act it on its behalf.
Using IAM definition, the natural person remains the principal.
That's also very close to what Self Sovereign Identity (SSI) is about.
Managing consent thus is not the responsibility of underlying dataspace technology and provider of such need to enable the end user to do so.
That's an important statement that must to put in the introduction part of the document.
There was a problem hiding this comment.
If a natural person operates/controls a dataspace connector they will be acting as a legal person in the context of the dataspace. There is no problem in a legal person participating through software agents. However, at the technical level of the dataspace the identity of the natural person becomes an attribute of the negotiated data sharing contract, not the impersonated identity of the software agent. Those are two different things. A natural person would log in to some kind of software that manages the access to the dataspace connector. At that level it uses credentials attached to a natural person. at the layer of the dataspace connector those credentials become an attribute of the contract and are not used for direct interaction with the other software agents. There is nothing in the DSP/DCP protocols that would prohibit a natural person to participate in the dataspace. The question is rather what is the appropriate protocol to provide this information. OID is not suited for automated processing by software agents. It is designed for the Human2System interaction layer, not for the System2System interaction.
There was a problem hiding this comment.
Maybe it is a misunderstanding that can be resolved easily?
A natural person interacts with the Business Layer of the dataspaces. Thus participating in the business processes of a dataspace.
At the technical level of the connector the natural person is only indirectly relevant as an attribute in a contract negotiation. The identity required for two connectors to negotiate is a legal person identity.
If a natural person wants to control all the interaction in the dataspace it also needs to be a legal person and be technically able to deploy and operate the required software stack.
3 participants
in the context of #8
highlight the major different between the definition of a dataspace by IDSA and the rest of the community.