Skip to content

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)

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.

Edited by athishare