Creation Review

Type
Creation
State
Successful
End Date of the Review Period

Reviews run for a minimum of one week. The outcome of the review is decided on this date. This is the last day to make comments or ask questions about this review.

Proposal

Eclipse Dataspace Protocol

Friday, February 16, 2024 - 03:05 by Sebastian Steinbuss
This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the community. Please login and add your feedback in the comments section.
Is this a specification project?
Patent License
Implementation Patent License
Parent Project
Working Group
Proposal State
Created
Background

The need and structure of the Eclipse Dataspace Protocol follows the work done by the International Data Spaces Association and its main deliverables IDS-Reference Architecture Model and IDSA Rulebook. The various implementations of Data Spaces require a need for a strong standardization of Data Space fundamentals as conducted in ISO/IEC JTC1 SC38 and with the Eclipse Dataspace Protocol in the Eclipse Foundation.

Scope

The Eclipse Dataspace Protocol provides a set of specifications designed to facilitate interoperable data sharing between entities governed by usage control and based on Web technologies. These specifications define the schemas and protocols required for entities to publish data, negotiate usage agreements, and access data as part of a federation of technical systems termed a dataspace.

Sharing data between autonomous entities requires the provision of metadata to facilitate the transfer of assets by making use of a data transfer (or application layer) protocol. The Eclipse Dataspace Protocol defines how this metadata is provisioned:

  1. How data assets are deployed as DCAT Catalogs and usage control is expressed as ODRL Policies.
  2. How contract agreements that govern data usage are syntactically expressed and electronically negotiated.
  3. How data assets are accessed using data transfer protocols.

These specifications build on protocols located in the ISO OSI model (ISO/IEC 7498-1:1994) layers, like HTTPS. The purpose of this specification is to define interactions between systems independent of such protocols but describing how to implement it in an unambiguous and extensible way. To do so, the messages that are exchanged during the process are described in this specification and the states and their transitions are specified as state machines, based on the key terms and concepts of a data space. On this foundation the binding to data transfer protocols, like HTTPS, is described.

The specifications are organized into the following documents:

  • Dataspace Model and Dataspace Terminology documents that define key terms.
  • Catalog Protocol and Catalog HTTPS Binding documents that define how DCAT Catalogs are published and accessed as HTTPS endpoints respectively.
  • Contract Negotiation Protocol and Contract Negotiation HTTPS Binding documents that define how contract negotiations are conducted and requested via HTTPS endpoints.
  • Transfer Process Protocol and Transfer Process HTTPS Binding documents that define how transfer processes using a given data transfer protocol are governed via HTTPS endpoints.

This specification does not cover the data transfer process as such. While the data transfer is controlled by the Transfer Process Protocol mentioned above, the data transfer itself and especially the handling of technical exceptions is an obligation to the Transport Protocol. As an implication, the data transfer can be conducted in a separated process if required, as long as this process is to the specified extend controlled by the Transfer Process Protocol.

Why Here?

The Eclipse Foundation provides the Eclipse Dataspace Working Group including the Eclipse Governance Framework a good foundation to create an Eclipse Specification in a Specification Project that combines the required assets, the specification document, a TCK, and a compliant implementation. The Eclipse Dataspace Components project aims at implementing the Dataspace Protocol and supporting the activities already.

Project Scheduling
  • Initial contribution of specification document in Q1 2024
  • Initial contribution of TCK in Q1 2024
  • Association of compliant Implementation, e.g. EDC in Q1 2024
  • Association with EDWG in Q1 2024
Future Work
  • Finalize the Specification document until summer 2024
  • Finalize the TCK until late summer 2024
  • Compliant Implementation of the Specification in EDC until late summer 2024
  • PAS Submission to ISO after Summer 2024
  • Associate with the EDWG to promote the project(s) as soon as possible
  • Support by International Data Space Association to socialize the project (as done so far)
Description

The Eclipse Dataspace Protocol is used in the context of data spaces as described and defined in the subsequent sections with the purpose to support interoperability. In this context, the specification provides fundamental technical interoperability for participants in data spaces and therefore the protocol specified here is required to join any data space as specified here. Beyond the technical interoperability measures described in this specification, semantic interoperability should also be addressed by the participants. From the perspective of the data space, interoperability needs to be addressed also on the level of trust, on organizational level and on legal level. The aspect of cross data space communication is not subject of this document, as this is addressed by the data spaces' organizational and legal agreements.

The interaction of participants in a data space is conducted by the participant agents, so-called Connectors, which implement the protocols described above. While most interactions take place between Connectors, some interactions with other systems are required. The figure below provides an overview on the context of this specification.

An Identity Provider realizes the required interfaces and provides required information to implement Trust Framework of a data space. The validation of the identity of a given participant agent and the validation of additional claims is the fundamental mechanism. The structure and content of such claims and identity may vary between different data spaces, as well as the structure of such an Identity Provider, e.g. a centralized system, a decentralized system or a federated system.

A connector will implement additional internal functionalities, like monitoring or Policy Engines, as appropriate. It is not covered by this specification, if a connector implements such or how.

The same applies for the data, which is transferred between the systems. While this document does not define the transport protocol, the structure, syntax and semantics of the data, a specification for those aspects is required and subject to the agreements of the participants or the data space.

Project Leads
Interested Parties

International Data Spaces Association, iSHARE, Fraunhofer, Microsoft, Bosch, SAP, Tecnalia, Bosch, Catena-X, Data Spaces Support Centre, TNO.

Initial Contribution

The Dataspace Protocol is an existing activity of the International Data Spaces Association e.V. All content was created by the IDSA members under the IP control and governance of International Data Spaces Association. The International Data Space Association holds the copyright of the repository. The contributors to the document will join the Eclipse Specification Project as contributors and will continue to work on the Specification Document, the Technology Compliance Kit and compliant implementations.

The current repository contains the specification document which is written text in English and is complemented by schema files in json and turtle. Additional some GitHub actions are used to generate GitHub pages.

Source Repository Type

+1

The Dataspace Protocol is key to achieve interoperability within and cross dataspace environments. The current version by IDSA are a sophisticated point to start further developments.  It is focusing on the technical specifications and thus would make a lot of sense to transfer it to the Eclipse Foundation to leverage the conceptual work of DS initiatives.