## Background and rationale The current iSHARE Trust Framework, as published on <https://framework.ishare.eu>, serves as a unified basis for trust and interoperability across all iSHARE participants and data spaces. As the number and diversity of data spaces adopting the iSHARE Framework increases, so does the need for flexibility in implementations. However, without a clear distinction between framework elements that must be conserved and those that may be adapted or enhanced, there is a risk of: - Inconsistent interpretations - Diverging implementations - Decreased interoperability between data spaces This RFC proposes to introduce indicators within the framework to define whether a specific element: - Must not be overwritten - May only be improved - Optional ## Proposed change ### Purpose To maintain sufficient harmonisation and interoperability between data spaces that are based on iSHARE, it would help if in the framework it is more clearly defined what parts of the framework can be overwritten by implementing data spaces and what parts cannot. ### Considerations and requirements Idea is to mark all parts of the framework with one of the following: - Must not be overwritten: a dataspace cannot make changes to this part - May be overwritten: a dataspace can make changes to this part - May only be improved: a dataspace can improve this part (for instance the SLA: when iSHARE defines a required availability as 95%, a dataspace is allowed to define required availability as 99%, but not as 90%) ## Proposed change: option 1 ### Purpose To support harmonisation and interoperability between data spaces by clearly defining which parts of the iSHARE Trust Framework must not be overwritten, may be overwritten, or may only be improved. This distinction enables data spaces to innovate and customise their implementation without compromising the core principles of interoperability, trust, and compliance. ### Description and principles The proposed change introduces a classification system into the iSHARE Trust Framework using the following categories: #### Mandatory (must not be overwritten) This element is mandatory and must be implemented exactly as defined in the framework. No changes, deviations, or redefinitions are allowed. #### Optional As clarified in RFC058, optional elements in the iSHARE Framework apply only to specific components of the specifications. These elements are not subject to alteration or redefinition by a data space or participants. Rather, they are optional in the sense that they may be omitted entirely based on the requirements of the role. However, if implemented, they must conform fully to the specifications defined in the framework. This approach ensures consistent interpretation and interoperability across all iSHARE participants and data spaces. #### Enhanceable (may only be improved) This element must meet the baseline requirements defined in the framework. Data spaces may strengthen, extend, or enhance it, but the core functionality or principles must remain unchanged. ### Implementation strategy To ensure a smooth transition from the current framework, where everything is considered 'Mandatory,' it must be clear that all elements are to be interpreted as 'Mandatory' unless explicitly stated otherwise, with parts marked as 'Optional' or 'Enhanceable' clearly highlighted. iSHARE Foundation will do a page-by-page evaluation of the Framework to mark any part as Optional or Enhenceable where possible. In particular, areas of the framework where optionality currently exists such as the implementation of /capabilities endpoints or the use of additional trust services will be specified accordingly. These are not meant to be overwritten or modified. They are either implemented as specified or omitted entirely. In all such cases, if a data space or participant chooses to use the optional component, it must adhere strictly to the iSHARE specification for that component. ### Example use cases ### Mandatory Token issuance formats and JWT claim structures must follow the exact iSHARE definition across all roles to ensure interoperability. ### Optional The /capabilities endpoint is optional. A Service Provider may choose not to implement it, but if implemented, it must return information exactly as defined in the framework. ### Enhanceable A data space may require a 99.99% availability SLA for its Authorisation Registry (higher than the baseline), without breaking the iSHARE-defined functionality. ## Proposed change: option 2 In the co-creations it became clear that the above described implementation scenario could lead to complications in interoperability. After careful considerations it was also concluded that making parts 'optional' would be part of RFC058 and that only the SLA's part of the framework could be considered 'Enhanceable'. The suggested implementation approach would be to create a clarifying text in the framework part about SLA's that indicates that SLA's may be improved by data spaces. This option has been decided to be best for imlementation of this RFC and is taken as a basis for the rest of this impact analysis. ## 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 | Potentially | Potenially | | Service Provider | Potentially | Potentially | | Entitled party | Potentially | Potentially | | Authorization Registry | Potentially | Potentially | | Identity Provider | Potentially | Potentially | | Identity Broker | Potentially | Potentially | | Data Space Administrator | Potentially | Potentially | | Participant Registry | Potentially | Potentially | | Data Space Governance Body | Potentially | Potenially | Potentially in this case means that any role might be impacted by more specific data space requirements that deviate from standard iSHARE requirements through the use of improved SLA requirements. Potentially in the case of Data Space Governance Bodies means that these bodies will be able deviate from the iSHARE framework without loosing interoperability (but are not abliged to). ## Impact iSHARE Foundation (Scheme Owner): scenario 1 - The [iSHARE Trust Framework](https://framework.ishare.eu) - Yes: a text explaining that data spaces are allowed to improve SLA requirements. - The [developer documentation](https://dev.ishare.eu) (as an extension of the iSHARE Trust Framework) - No - The OpenAPI definitions on [Swaggerhub](https://app.swaggerhub.com/search?owner=iSHARE) - No - Example implementation in [Postman Collections](https://dev.ishare.eu/demo-and-testing/postman.html) - No - Code that is published on Github: - [iSHARE Satellite reference implementation](https://github.com/iSHAREScheme/iSHARESatellite) - No - [eSEAL certificate procurement guide](https://github.com/iSHAREScheme/eSEALsGuide) - No - [iSHARE.NET service consumer core components](https://github.com/iSHAREScheme/iSHARE.NET) - No - [Python iSHARE package](https://github.com/iSHAREScheme/python-ishare) - No - [iSHARE code snippets](https://github.com/iSHAREScheme/code-snippets) - Create code snippet for invoking CRUD actions on /parties endpoint (possibly) - [Reference implementation for Authorization Registry](https://github.com/iSHAREScheme/AuthorizationRegistry) - No - [Reference implementation for Service Provider](https://github.com/iSHAREScheme/ServiceProvider) - No - Onboarding portal - No - The implementation of the iSHARE satellite for iSHARE as the Scheme Owner on https://sat.ishare.eu and https://sat.uat.isharetest.net - No - The [public website](https://www.ishare.eu) - No - Internal documentation - Internal manuals where required - [Authorization Registry test implementation](https://ar.isharetest.net/) - No - The [Conformance Test Tool](https://ctt.isharetest.net/admin/account/login), tests listed on https://ctt.isharetest.net/admin/test-cases - No - iSHARE test satellite (used for conformance testing): https://scheme.isharetest.net/ - No - iSHARE test certificate authority: [EJBCA Public Web](https://ca7.isharetest.net:8442/ejbca/) - No - [iSHARE Change Management documentation](https://changes.ishare.eu) - No ## Implementation ### Release schedule This RFC will either be released as part of iSHARE 3.0. ### Communication No specific requirements.