Proposals

Technical Details

DCP defines the following protocol flows.

1. Base Identity Protocol (BIP)

The *Base Identity Protocol* defines how to obtain and communicate participant identities and claims using self-issued security tokens. BIP defines:

- A format for self-issued tokens based on the Decentralized Identifiers (DIDs) v1.0
(https://www.w3.org/TR/did-core, did:web Method (https://w3c-ccg.github.io/did-method-web/) and Self-Issued OpenID Provider v2 (https://openid.net/specs/openid-connect-self-issued-v2-1_0.html) specifications. 

- Endpoints and a flow to obtain self-issued security tokens.

2. Verifiable Presentation Protocol (VPP)

The *Verifiable Presentation Protocol*  defines a protocol for storing and presenting Verifiable Credentials (VC) and other identity-related
resources. The Verifiable Presentation Protocol (VPP) covers the following aspects:

- Endpoints and message types for storing identity resources belonging to a holder
- Endpoints and message types for resolving identity resources
- Secure token exchange for restricting access to identity resource endpoints

The VPP makes use of the following standards (among others):

- Verifiable Credentials Data Model v1.1 (https://www.w3.org/TR/vc-data-model/)
- DIF Presentation Exchange (https://identity.foundation/presentation-exchange/spec/v2.0.0).
- Jason Web Token (JWT) (https://www.rfc-editor.org/info/rfc7519)

The VPP is designed to make integrating existing software wallets and identity systems easy. 

3. Credential Issuance Protocol (CIP)

Verifiable Credentials enable a holder to present claims directly to a Relying Party (RP) without
the involvement or knowledge of the `Credential Issuer`. The *Credential Issuance Protocol* (CIP) provides an interoperable mechanism for parties (potential holders) to request credentials from a `Credential Issuer.` Specifically:

- Formats and profiles for verifiable credentials based on 
- The protocol defines the endpoints and message types for requesting credentials to be issued from a `Credential Issuer.`
- The protocol is designed to handle use cases where credentials can automatically be issued and a manual workflow is required. 

Use of Relevant Standards

DCP is based on relevant existing standards where possible. See the above description for specific examples. 

Integration with Identity-related projects

DCP is designed to integrate existing wallet and identity systems. For example, Catena-X has integrated [Keycloak](https://www.keycloak.org/) with the Verifiable Presentation Protocol as a token issuer.  Existing wallets and credential issuance systems can support VPP and CIP endpoints.

Open Source Implementations and Industry Adoption

Two open-source Eclipse projects are currently implementing the specifications, the EDC Identity Hub (https://github.com/eclipse-edc/IdentityHub) and the Tractus-X Managed Identity Wallet (https://github.com/eclipse-tractusx/managed-identity-wallet). 

A TCK is currently planned and will be based on the [Dataspace TCK Framework](https://github.com/eclipse-dataspacetck)

Dataspaces that use DCP

Eona-X | EONA-X is a dataspace in the domain of Mobility, Transport and Tourism. It leverages EDC capabilities to power data exchanges between its participants.

Contact: phebant[@]amadeus[.]com

Catena-X | Catena-X is offering the first open and collaborative data space for the automotive industry to boost business processes using data-driven value chains.

Contact: info[@]catena-x[.]net
 

Eclipse Zenoh-Flow aims at simplifying and structuring (i) the declaration, (ii) the deployment and (iii) the writing of complex and, potentially, safety-critical applications that can span from the Cloud to the Microcontroller.

To these ends, Eclipse Zenoh-Flow leverages the data flow programming model — where applications are viewed as a directed graph of computing units, and Eclipse Zenoh — an Edge-native, data-centric, location transparent, communication middleware. This makes for a powerful combination as Zenoh offers flexibility and extensibility while data flow programming structures computations. The main benefit of this approach is that this allows us to separate the applications from the underlying infrastructure: data are published and subscribed to (automatically with Zenoh-Flow) without the need to know where they are actually located.

Eclipse Zenoh-Flow further separates the business logic contained within each computing unit from the constraints of the overall application. An application is described in a descriptor file that groups together the different blocks that compose it as well as (i) how these blocks are connected, (ii) how they should be deployed on the infrastructure and (iii) possible execution constraints (e.g. time requirements or execution order).

As Eclipse Zenoh-Flow is also targeting safety-critical applications, it leverages the Rust programming language for its core. It also offers bindings in other languages to facilitate integration with existing software.

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.

This proposal contributes to implements an end-to-end holistic approach to seamlessly integrate, anchor, and enforce negotiated data exchange agreements throughout the underlying infrastructure, encompassing processes related to data processing, storage, and transfer.

Conformity assessment is one of the industry answers to handle risk management, yet there is no commonly accepted specification for interoperable conformity assessment.

This specification goal is to combine the existing world of conformity assessment and the needs for a Provider and a Consumer to reach an agreement based on a common understanding using existing claims and evidence.

Examples:

• How can Provider express that an unknown Consumer shall only process data on ISO 27001 certified services ?
• How does the Consumer demonstrate such requirement ?

To demonstrate the viability of the current proposal, Gaia-X used this specification to build the Gaia-X Compliance and an open-source implementation of the elements described in the Scope section has been done https://gitlab.com/gaia-x/lab/compliance

The Gaia-X compliance and its implementation based on the current specification proposal is being used by several dataspaces such as Catena-X, Eona-X, Prometheus-X, Agdatahub, ...

The implementation used to validate the current specification is based on:

• W3C Verifiable Credential, W3C SHACL and W3C SPARQL for the validation and verification of the models mentioned in the Scope section.
• W3C DID, X509 and JOSE for the cryptographic chains of trust.
• ETSI TS 119 312 and EBSI APIs for the presentations of the trust anchors.
• OIDC4VCi and OIDC4VP for the exchange of W3C Verifiable Credentials.
• TRAIN to discover the ecosystem rules and trust anchors.

Eclipse CANought offers the automotive-specific capabilities to enhance the Eclipse Kanto project to offer a comprehensive solution focused on the automotive industry. Eclipse CANought provides extensions to the Eclipse Kanto project focused on automotive market segment capabilities by standardizing and securing CAN communications. 

It is critical that Automotive IoT applications have a standardized and secure solution for CAN communications with embedded controllers. The Eclipse CANought extensions will make Eclipse Kanto more appropriate for automotive-focused implementations.

The Eclipse CSI project combines technologies and practices for security Eclipse Foundation Project Software Supply Chain.

The Eclipse Cardinal Program has identified areas where template and process documents would add value to legal processes involved in technology, specifically in the areas of procurement and M&A activities involving open source software.

The documents will be hosted in a git-based repository enabling open source development techniques and methodologies to be used. Anyone can raise issues with the documents, fork the documents (for example to create jurisdiction-specific versions of them), and issue pull/merge requests.

Release versions of the documents will be made available in markdown, docx and plain text formats, through a simple and clear web frontend, meaning that users who don’t wish to engage with the development process can easily access them directly. The liberal licensing model will allow unrestricted use, modification and re-distribution.

Overview

The initial set of documents was developed by Moorcrofts LLP, a law firm based near London, in England in association with Orcro Limited, an Open Source Consultancy, also based in the UK. Moorcrofts and Orcro are both OpenChain partner organisations (openchainproject.org) and have been working in that capacity to develop:-

1. a due diligence questionnaire and set of warranties for acquiring software from a developer using open source software; and

2. a due diligence questionnaire and set of warranties for use in M&A transactions involving a target which develops software using open source.

These will be hosted by the Eclipse Cardinal Program from day one. We also have a suite of documents drafted to facilitate the supply of services over the internet using microtransaction architectures, which have also been developed by specialist law firms in a number of jurisdictions worldwide. The roadmap includes the development of software intended to facilitate the drafting, assembly, storage and analysis of legal documents. For example, since drafting contracts shares many characteristics with writing software, we propose developing a module for the Eclipse IDE which facilitates this.

Due diligence and warranties for open source development: procurement and M&A

The open source procurement and M&A process has historically focussed on specific releases of supplied software (for example, by analysing the composition of that release, and reviewing the licences for each component within the release). This is becoming less and less effective as a means of analysing and determining compliance risk as software development moves to a CI/CD model (continuous integration/continuous deployment/development).

A much more effective approach is to focus the warranties on the development process itself, and the processes, policies and procedures which the developing organisation uses to manage that development process. An ISO standard, ISO5230:2020 (OpenChain) defines the characteristics that a development program must have in order to manage open source compliance risk effectively, and the standard lends itself to a framework both for due diligence, and for warranties, both in procurement and M&A. The beauty of this approach is that it does not require that the target is compliant with, or even aware of, ISO5230:2020 (but it does mean that applying the process to a compliant organisation is that much more straightforward).

The initial set of due diligence questions for procurement has been developed using the ISO5230 framework, with the input from many active members of the OpenChain project, and the procurement terms have themselves been adapted to form the M&A due diligence and warranty suite.

Eclipse FA³ST aims to provide an implementation of the re-active (or type 2) Asset Administration Shell according to the Asset Administration Shell (AAS) specification by Plattform Industrie 4.0.  In contrast to other implementations such as Eclipse BaSyx, Eclipse FA³ST will focus on the deployment at edge-level rather than cloud-level, meaning that its primary focus will be on asset connectivity rather than scalability. Other expected key features are

• Easy to set-up & use
• Open architecture which enables easy customization and extension
• Implementation of API for HTTP and OPC UA
• Protocol-agnostic synchronization with assets
• Usage via command-line interface, docker container, and as embedded library

Eclipse WattAdvisor provides a Python library that consists of several functions and classes to build and solve a linear optimization model based on certain input data and parameters. The optimization model represents a local energy system composed of different energy components to produce, store, or transform energy.

Input data can contain information about the following aspects of the local energy system:

• geographical location
• annual energy demands per energy type
• Installed power and/or capacity per energy component already existing in the system
• Potential power per energy component that can be added to the system at maximum
• Custom cost parameters per energy component
• Prices of tariffs to purchase energy from external sources for the energy system

With this input data, a predefined function to start the automatic processing of the model can be called. At first, it builds a generic optimization model formulated with the Python library Pyomo and parameterizes it according to the input data to create a specific optimization problem. Here, the target function to minimize equals the sum of the total cost of all components to be used for the component composition. The total cost per component consists of at most:

• Investment costs converted into annual costs by an annuity factor based on the expected lifespan of the component
• Annual operational cost
• Annual energy purchase cost

Investment and operational costs are calculated by applying specific cost factors of a component, while annual operational costs are determined using the expected amount of energy purchased by the component and energy tariff prices given as input. It should be mentioned that the total cost of each component is formed by an individual combination of the three possible cost factors, e.g., the total cost of an energy purchase component consists only of the annual energy purchase cost. 

The optimization problem is then passed to an open-source solver to create a solution. This leads to a solution that follows the fundamental target function to find the cost-minimal composition of energy components and remaining energy purchases to supply the parameterized demands.

After a valid solution is found, the relevant result data is exported either in machine-readable (JSON) or human-readable (Excel) format.

Energy balances are formulated in the model for these energy carriers:

• Electrical energy
• Thermal energy
• Natural gas

Currently, classes to implement the following component groups are predefined and available in the project:

• Combined heat and power plant
  • Transforming natural gas into electrical energy
• Electrical energy storage
  • Storing electrical energy
• Energy demand
  • Consuming energy for the system
  • Can be parameterized for all energy carriers
• Energy feed-in
  • Consuming energy from the system and generating income
  • Can be parameterized only for electrical energy
• Energy purchase
  • Producing energy for the system
  • Can be parameterized for all energy carriers
• Gas boiler
  • Transforming natural gas into thermal energy
• Heat pump
  • Transforming electrical energy into thermal energy
  • Efficiency estimation by the usage of historical air or ground temperature weather data
• Photovoltaic plant
  • Roof surface
  • Free field
  • Producing electrical energy for the system
  • Energy production estimation by the usage of historical solar radiation weather data
• Solar thermal energy plant
  • Producing thermal energy for the system
  • Energy production estimation by the usage of historical solar radiation weather data
• Thermal energy storage
  • Storing thermal energy
• Wind power plant
  • Producing electrical energy for the system
  • Energy production estimation by the usage of historical wind speed weather data

By adding new component groups, this list can be extended, which in turn contributes to extending the scope and applicability of the model.

Eclipse Data Analysis Services (Daanse) is an open source software designed to analyze large amounts of data and extract valuable insights from it. With a steady rise of digital data production in business, science and technology, the importance of data analysis has grown tremendously. Data Analysis Services offers a wide range of tools, technologies and expertise to interpret data in meaningful ways and help decision makers formulate strategies and identify patterns and trends. There are several important features of Data Analysis Services: Data cleansing and integration: One of the crucial steps in data analysis is the preparation of the data. Often data are flawed or incomplete. Data Analysis Services helps to clean, transform and bring data into a unified form to enable sound analysis. Data Visualisation: Data can be complex and numbers alone are sometimes not enough to convey information. Data Analysis Services uses visualisation tools to present data in the form of charts, graphs and interactive dashboards. This simplifies the communication of results and insights. Statistical Analysis: Data Analysis Services uses statistical methods and models to analyse data and identify patterns, correlations or significance. This includes descriptives, inferential statistics, regression analysis, time series analysis and more. Business Intelligence: Data Analysis Services helps management to extract business-critical insights that help improve business processes, optimise resources and identify new business opportunities. Big Data Analysis: In a world characterised by huge amounts of data, Big Data analysis is an integral part of Data Analysis Services. Processing and analysing large and complex data sets require specialised tools and technologies.

Eclipse Daanse combines the following technologies to cover different applications scopes:

XMLA (XML for Analysis)

XMLA provides a detailed specification for accessing analytical data sources. This specification describes the structure of XMLA messages and the supported operations for accessing OLAP data sources. The Test and Compatibility Kit (TCK) can be used to check compliance of different implementations with the XMLA specification and to ensure interoperability between systems. Eclipse Daanse offers a Java API via Jakarta XML Bind and flexible customisable SOAP messages.

MDX (Multidimensional Expressions):

MDX is a query language for multidimensional data sources and is closely related to XMLA. The scope and delimitation of MDX are as follows: Stringd can be converted into an implementation or API model using parsers.



OLAP

OLAP (Online Analytical Processing) is a powerful technology widely used in data analysis and reporting. It is based on several important components: The DataCube Provider makes it possible to create and provide multidimensional data cubes that offer efficient and flexible data organisation for complex analyses. OLAP's Access and Security Model regulates access rights to data sources and ensures that only authorised users can access the information they need, while sensitive data remains protected. The Calculation Model enables complex calculations and aggregations to be performed on the multidimensional data. This enables the creation of meaningful reports and analyses that provide deeper insights into the data. OLAP's Dynamic Function Model allows dynamic functions to be used to respond to changes in data sources or query results. This allows users to customise analyses and include real-time data in their reports. Parts of this implementation are a Fork ot the Pentaho  Mondrian Project

Databases:

Different databases can be integrated via JDBC (Java Database Connectivity) which allows developers to interact with different databases by providing a standardised method for connecting and querying. The JDBC Database Dialect Abstraction Layer makes it possible to work with different databases without having to worry about the specific syntax differences. OLAP data can thus also be accessed by means of OLAP database-schema mapping.



Clients:

Eclipse Daanse enables access to analytical data sources from various client applications: In addition to the possibility of integrating your own applications using the client libraries (in several languages like Java and Typescript), Eclipse Daanse includes its own web client for tables, charts and maps as well as dashboards. In addition, further reporting tools can be connected via adapters and templates.



Dashboards:

In addition to XMLA data sources, the Eclipse Daanse client's dashboard engine enables other data sources such as SensorThingsAPI, REST and OCG (WMS, WFS) to be connected and merged with each other. These data sources can feed a variety of visualisations such as charts, tables, maps, infographics ,texts and more. Visualisations can be combined to different widgets and designed interactively via input and control options such as (fields, buttons, sliders, map events ... ). In addition to classic dashboards, interactive maps, infographics or interfaces for e.g. building management systems can also be realised in this way.