RFC042
Last updated
Last updated
Issue reference
#1+
Document status [draft/final]
Draft
With iSHARE has move to a federated model. This has led to changes in terminology being used for roles throughout the iSHARE Trust Framework and other iSHARE documentation or assets. Additionally, other initiatives like and the ,and new regulations like the have introduced terminology as well.
This RFC aims to clarify the terminology used for and map its alignment to the terminology used with other initiatives and regulations. It proposes the renaming of two iSHARE roles and proposes changes to align and clarify documentation.
It’s important to acknowledge that iSHARE provides a role framework that can be applied to legal entities. The roles should not be confused with the naming of technological solutions that are required to fulfill those roles. The iSHARE Framework does provide specifications on which technological aspects a role should implement (security requirements, API requirements), but it doesn’t specify what solution(s) should fulfill those. The following table presents the current names of iSHARE roles, in the second column in bold roles that will be renamed with the implementation of this RFC and in further columns a comparison with other initiative.
When drafting this impact analysis, we concluded that it was not possible to create a one-on-one mapping between iSHARE defined roles and roles used in other initiatives. This is caused by the fact that all initiatives have a different approach and look on the topic. Nevertheless the community involved in data space in general and trust in particular would benefit from an overview of how the different initiatives use roles as a concept, what the particular roles mean in all frameworks and how they are related to each other. The following table can form a starting point for such an analysis.
New name
Other names currently in use for this role
Service Consumer
Service Consumer
Data Consumer, Data User, Data Recipient
Data Consumer
Participant, fulfilling their technical requirements using a ParticipantAgent
Data user
Service Provider
Service Provider
Data Provider, Data Node
Data Provider
Participant, fulfilling their technical requirements using a ParticipantAgent
Data holder
Entitled Party
Entitled Party
Data Owner, Data Holder
Data Owner
Not present
Can be Data subject or data holder
New name
Other names currently in use for this role
Identity Provider
Identity Provider
Human Identity Provider
Not present
Not present
Not present
Identity Broker
Identity Broker
--
Not present
Not present
Not present
Not present
Authorisation Registry
Authorisation Registry
--
Not present
Not present
Part of a data intermediation service
Satellite
Participant Registry
--
Not present
Not present, this role will likely fulfill it’s technical requirements by using a Dataspace Registry (similar to the iSHARE Satellite reference implementation)
Competent Authorities for both data intermediation services and data altruism organisations
These roles are necessary in the framework and data spaces context however, they are not necessarily registered as participants. The roles will still be essential to enable trusted data sharing and governance around it.
New name
Other names currently in use for this role
Scheme Owner
Scheme owner
--
Not present
Not present
Not present*
Satellite Administrator
Participant Administrator
--
Certification Body And Evaluation Facilities
Not present, this role will likely fulfill it’s technical requirements by using a Dataspace Registry (similar to the iSHARE Satellite reference implementation)
Operational part of Competent Authorities
Satellite
Data Space Governance Body
Data Space Coordinator, Scheme Satellite, Data Space Governance Authority
Dataspace Authority
Dataspace Authority
May be considered equivalent to European Data Innovation Board (EDIB)
* In context of Data Governance Act European Commission could be considered Scheme owner (of Data Governance)
This RFC:
Renames the current role of iSHARE Satellite to Participant Registry (certified role). This role is fulfilled by the legal entity that is responsible for the operational processes as defined in a data space. This is a certified role and the Participant Registry must be certified by the Scheme Owner.
Legal entities can have both roles simultaneously, or a Data Space Governance Body could use (contract) a legal entity to fulfill the role of Participant Registry. To clarify that this role is not a formal part of the trust framework (although a relevant role), the role will be labeled as Other relevant role.
To align with the deprecation of the term Satellite, the role of Satellite Administrator will be renamed to:
Participant Administrator (other role): This can be a party (contractually) working under Participant Registry, facilitating the operational process execution. Note this is not a formal role, however, a Satellite/Participant Registry may choose to outsource parts of their execution responsibilities to a 3rd party: the Participant Administrator. From the framework perspective, the Participant Registry remains liable and responsible even for the outsourced parts.
These changes will be reflected in relevant documentations and communications going forward. Impact on the assets maintained by iSHARE Foundation is given in the next section. Participants are requested to adopt the updated naming conventions in their documentations and communications.
iSHARE Foundation will review all current assets and work on consistent use of roles as defined in this RFC. As the roles are heavily used throughout all of the documentation, the overall impact of this RFC is large.
The following assets are impacted:
Code that is published on Github:
The implementation of the iSHARE satellite for iSHARE as the Scheme Owner on https://sat.ishare.eu and https://sat.uat.isharetest.net
Internal documentation
iSHARE test satellite (used for conformance testing): https://scheme.isharetest.net/
The following assets are NOT impacted:
Code that is published on Github:
The expected implementation time is around 2-3 months after deciding on the implementation of this RFC.
The implementation of this RFC will be actively communicated with the community.
In
In
In
In the
Can be or
Can be or
In
In
In
In the
Not explicitly mentioned, but can be seen as a
Not explicitly mentioned, but can be seen as a
A combination and/or parts of
In
In
In
In the
Introduces the role of Data Space Governance Body (other role). This is a role (currently assumed to be taken by the Satellite) which is responsible for data space, including the defining, evolving & maintaining and governing of participant lifecycle processes. This role can be fulfilled by a legal entity or by a non legal entity (a group of parties with a certain governance). For reference, the definition of data spaces can be based on the and this body is responsible for defining, evolving and governing the building blocks there in.
The
The (as an extension of the iSHARE Trust Framework)
The OpenAPI definitions on
Example implementation in
The
The , tests listed on https://ctt.isharetest.net/admin/test-cases
iSHARE test certificate authority:
: a document will be created to explain the relationship between roles models of different initiatives