RFC046: Define Dataspace Self Description to improve discoverability

Background and rationale

iSHARE trust framework provides for and supports the across interoperability for dataspaces. The scope of the iSHARE Trust Framework is defined as Identification, Authentication and Authorisation for data exchange. Currently, discovering and understanding the specific characteristics of different data spaces within the iSHARE ecosystem can be challenging. This lack of readily available information hinders interoperability and makes it difficult for participants to identify suitable data spaces that meet their needs. This RFC aims to address this challenge by introducing a standardised method for describing data spaces, thereby making them more discoverable and understandable. Supporting this scope it standardises for discoverability aspects of:

  1. Discoverability of participants: by defining the /parties endpoint for iSHARE Satellites, the iSHARE Framework facilitates participants to discover and verify adherence and dataspace(s)-membership of other participants.
  2. Discoverability of dataspaces: by defining the /dataspaces endpoint for iSHARE Satellites, the iSHARE Framework facilitates participants to discover available dataspaces.
  3. Discoverability of capabilities: by defining the /capabilities endpoint for iSHARE participants, the iSHARE Framework facilitates participants to discover services that are provided in the context of an iSHARE compliant manner.

This RFC aims to improve the discoverability aspects and interoperability aspects thereby lowering the barrier for adoption and enabling more automated straight through processing.

This RFC is covering topic 2. Topic 3 has been covered in RFC047.

Proposed change: purpose

This RFC focuses on improving the discoverability of dataspaces aspects. Where other initiatives (IDSA, Gaia-X, DSSC) have been working on the topic of modelling of dataspaces aspects, we aim to improve the automated discovery of dataspaces aspects_, by defining a format in which dataspaces aspects are excahnged: the so-called Dataspace Self Description or the capabilities of a dataspace. This will enable automated discovery of services and standards used in other data spaces, particularly when a participant wants to share data with another participant. This is crucial for interoperability and scaling cross-domain data exchange.

Proposed change: considerations and requirements

The /dataspaces endpoint already contains a property called dataspacedef_url that prepares for providing a URL pointing at the dataspace self description. To align better with common terminology, it is proposed to rename this property to dspace_self_desc.

Furthermore a JSON-based response model will be defined in which the dataspace self description can be represented in a standardised manner to other participants. This is similar to /capabilities endpoint of a participant where services itself are not defined by the framework, but pointers to it are presented in a standardised manner. Topics that must be covered in the self-description are based on the building blocks of dataspace; for example:

  • Underlying trust framework = iSHARE Framework
  • data models = Open Trip Model, GS1
  • etc.

The dataspace self description is proposed to be aligned with the Dataspaces Blueprint, as defined by the DSSC. A iSHARE based Dataspace Template, which aligns iSHARE specifications with the Dataspaces Blueprint topics is developed which provides in a way a human readable variant of the dataspace self description.

Description and principles

This RFC proposes the creation of a data space self-description document in JSON format. The self-description will include information on the data space's interoperability, data sovereignty and trust mechanisms, value creation aspects, and organizational and business building blocks. The design principles for this format are:

  • Standardization: Aligning with existing standards like the Dataspaces Blueprint.
  • Completeness: Covering all essential aspects of a data space.
  • Machine-readability: Using JSON for easy parsing and interpretation by machines.
  • Human-readability: Providing clear and understandable information for users.

The dataspace self description will be in the form of a predefined JSON structure that is published by the Data Space Governance Body. The Data Space Governance Body can request the Scheme Owner (in charge of maintaining the list of data spaces) to configure the location to the data space self description. The location will be configured in the dataspacedef_url attribute of a dataspace, as already defined in the /dataspaces endpoint. To align with terminology (and camelCase transition), the attribute will be renamed to dataSpaceSelfDescriptionUrl

An example of the JSON containing the data space self description is available here.

The Data Space Self Description will be published as a JSON document, referenced to from the existing data->dataspacedef_url in the /dataspaces endpoint of the Participant Registry.

Example use cases

  • A Service Provider wants to join a data space that uses specific data models and interoperability standards. The data space self-description allows them to quickly identify compatible data spaces.
  • A Service Consumer needs to understand the access and usage policies of a data space before accessing its data. The self-description provides this information in a clear and concise manner.
  • A developer needs to integrate their application with a data space. The self-description provides the necessary technical details, such as API endpoints and data formats.

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

Optional: if a participant chooses to use the data space self description, impact is expected.

The Data Space Governance body must publish the data space self description JSON and the URL to that description must be configured by the Scheme Owner (in charge of maintaining the list of data spaces).

Impact iSHARE Foundation (Scheme Owner)

Implementation

Release schedule

The release of this RFC should be coordinated with other relevant RFCs and initiatives to ensure a smooth transition and avoid conflicts. The timeframe for implementation will depend on the complexity of the changes and the availability of resources. Aim should be a release in iSHARE version 3.0.

Communication

The iSHARE Foundation should communicate this change to the iSHARE community through various channels, such as the iSHARE website, newsletters, and community forums. Clear and concise documentation should be provided to explain the changes and their impact on the ecosystem.

Edited by athishare