RFC062: Improve section 'Levels of Participation' and rename to 'Criteria for participation'
Background and rationale
The current iSHARE Framework includes variations of levels of participation (compliance) to the framework.
Proposed change
Purpose
From an interoperability perspective it is complicated to allow parties with different levels of compliance. This RFC aims to improve interoperability of participants across data spaces by clarifying that this section describes the different criteria for participation instead of levels of participation.
Description and principles
Proposed change is to improve the named section and clarify how the section is related to different attributes of the party model as described in the /parties and /parties/{party_id} endpoints. These screenshots illustrate how the attributes are included in the /parties model speciication on the dev portal and in the reference implementation of the Participant Registry.
Considered solutions
Removal of the section
The initial RFC proposed the complete removal of this section. This would resolve the possibility of having parties with different levels of compliance. While researching however it was found that the different sections of the mentioned paragraph related to radio buttons in the reference implementation of the Participant Registry and attributes of the party model.
Transform into explanation of party attributes
After this discovery it was decided to research the option to convert this paragraph into a paragraph which explains the criteria for participation and with this explains the attributes and radio buttons. The name of the RFC was changed into a name that depicts this solution scenario.
The existing part 'Identity verification level' will still be removed, because it has not been implemented anywhere and limits interoperability.
Solution specifics
The paragraph will be rewritten into the following.
### Criteria for participation <a href="#admission-levelsofparticipation" id="admission-levelsofparticipation"></a>
All participants must be assessed on adherence to criteria set for participation in this admission process. To accodomodate step-by-step onboarding, the following criteria are available.
#### Legal adherence <a href="#admission-legaladherence" id="admission-legaladherence"></a>
This adherence criterium is available under role->legal adherence.
* Legal adherence (YES)
The Participant has signed the iSHARE Accession Agreement, including the iSHARE Terms of Use.
* No legal adherence (NO)
The Participant has not yet signed the necessary agreements.
#### Technical compliance <a href="#admission-technicalcompliance" id="admission-technicalcompliance"></a>
This adherence criterium is available under role->compliance verified.
* Full technical compliance (YES)
Technical compliance was verified by providing a successful test report of iSHARE certification tool.
* No technical compliance (NO)
Technical Compliance has not been verified. Note that this indication will limit the available options for data sharing for this participant within the iSHARE network, because the participant must use another (compliant) participant to handle exchanges on his behalf.
Impact on the ecosystem
The following table lists the impact of this RFC on the formal iSHARE roles (excluding the Scheme Owner role).
| Formal role | Technical impact | Business / legal / functional / operational impact |
|---|---|---|
| Service Consumer | No | No |
| Service Provider | No | No |
| Entitled party | No | No |
| Authorization Registry | No | No |
| Identity Provider | No | No |
| Identity Broker | No | No |
| Data Space Administrator | No | No |
| Participant Registry | No | Clarifying compliance criteria |
| Data Space Governance Body | No | No |
Impact iSHARE Foundation (Scheme Owner)
- The iSHARE Trust Framework
- On the mentioned page
All other assets are not touched.
Implementation
Release schedule
This RFC will either be released as part of iSHARE 3.0.
Communication
No specific requirements.