RFC058: Introduce the concept of optional features in the framework

The original name of this RFC used "features" instead of "specifications". To better explain that the iSHARE framework holds specifications and not features, the name has been changed.

Background and rationale

The iSHARE Trust Framework currently defines a set of uniform specifications that all participants must comply with. This ensures that interoperability between different participants and data spaces is guaranteed, fostering consistent behavior and trust across the ecosystem (multiple iSHARE Data Spaces).

However, as the framework expands to accommodate a broader variety of services and domains, it becomes clear that not all requirements are equally relevant to all participants. Some specifications, while beneficial, may only be valuable for data spaces with more advanced policy requirements.

Proposed change

Purpose

To increase flexibility within the iSHARE Trust Framework by introducing a mechanism for optional specifications, thereby allowing participants to adopt functionalities that fit their needs and responsibilities without compromising interoperability or compliance. This approach supports data space diversity and different business models, and enables gradual adoption of specifications as needs evolve.

In some cases it can be helpful to promote, but not enforce interoperability of features. This could be because of varying requirements between data spaces, or because parties providing services might want to choose to provide a certain service or not. This RFC requests for the addition of optional features, so that parties that choose to implement those optional features still benefit from improved interoperability, but are more flexible in choosing to adopt certain features of the framework or not, while maintaining the assurance that the mandatory core of the framework remains consistent.

Example of an optional feature is:

Description and principles

The proposed change includes the introduction of an “optional” note on framework features. The core principles are:

  • Clear requirements: the framework clearly marks which part are optional. All other parts are considered mandatory.
  • Clear implementation: participants should be given clear guidance or requirements on how to state which optional features are implemented.
  • Compatibility Assurance: Optional features must not break interoperability for those who don’t implement them.

The Change Advisory Board has provided the following guidance on implementation (meeting of October 9, 2024). CAB suggests to refrain from using optional features too much, so the consistency throughout the framework is affected as less as possible. It should be a balance between impact on participants and consistency / interoperability across participants and data spaces. These things must be detailed out in the RFC impact analysis of introducing optional features.

Considerations and requirements

Discussion in CAB has resulted in the remark that using optional features should be avoided as much as possible. This must be taken into account when implementing this RFC.

Considered solutions

The iSHARE Framework contians:

  • Technical specifications
  • Non-technical specifications (operational, legal, etc.)

After consideration, the proposal is to apply optionality only to technical specifications and not to non-technical specifications. Technical specifications can be clearly declared as implemented or not (for instance via the /capabilities endpoint), and their implications are more easily isolated when not implemented.

Example use case

Anticipating on the implementation of this RFC, already one technical specification has been considered being 'optional': the /delegation_policy endpoint.

/delegation_policy endpoint This endpoint allows advanced handling of delegation based on policies (e.g., to support automated decision-making). It will be marked as optional and introduced in the developer portal accordingly.

Impact of Making /delegation_policy Optional

  • Flexibility: Service Providers and Authorization Registries that don’t require dynamic policy evaluation are not burdened with implementing it.
  • Interoperability: Participants that rely on this specification (e.g., advanced Service Consumers) must check if their counterpart supports it, using the discovery methods outlined below.
  • Transparency: As this is a technical specification, it can be clearly marked and declared in participant metadata and /capabilities.

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 No
Service Provider Potentially No
Entitled party No No
Authorization Registry Potentially No
Identity Provider Potentially No
Identity Broker Potentially No
Data Space Administrator No No
Participant Registry Potentially No
Data Space Governance Body No No

Impact iSHARE Foundation (Scheme Owner)

Implementation

Release schedule

This RFC will either be released as part of iSHARE 3.0.

Communication

No specific requirements.

Edited by athishare