This proposal has been approved and the Eclipse Dataspace Decentralized Claims Protocol project has been created.
Visit the project page for the latest information and development.

Eclipse Dataspace Decentralized Claims Protocol

Thursday, March 7, 2024 - 16:00 by James Marino
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
Proposal State
Created
Background

This proposal is for a new specification project covering the Eclipse Dataspace Decentralized Claims Protocol (DCP). DCP defines an interoperable overlay to the Dataspace Protocol (DSP) Specifications for conveying organizational identities and establishing trust in a way that preserves privacy and limits the possibility of network disruption. 

The Dataspace Protocol Specifications(https://github.com/International-Data-Spaces-Association/ids-specification) do not address how participant identities are determined or trust is verified, instead leaving it to individual dataspaces to determine a system that best suits their individual requirements. DCP defines an overlay protocol that allows for multiple trust anchors (credential issuers) and avoids the need for third-party verification. This increases the dataspace network's robustness and limits third parties' ability to eavesdrop on private communications between participants. It also places data-sharing decisions firmly in the orbit of the participants, who remain in technical control of their identities and credentials.

The DCP protocol has been developed as part of the Eclipse Tractus-X Open Source Project (https://github.com/eclipse-tractusx/identity-trust). 

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) DCP has been adopted by the Catena-X and EONA-X dataspaces, which are contributing to EDC Identity Hub development. 

In alignment with the charter of the Eclipse Dataspace Working Group, It should now be contributed as a specification project for further work and improvement and to make it more independent from individual dataspace implementation projects. 

Scope

The Eclipse Dataspace Decentralized Claims Protocol (DCP) defines an interoperable overlay to the Dataspace Protocol (DSP) Specifications for conveying organizational identities and establishing trust in a way that preserves privacy and limits the possibility of network disruption. 

The scope of Eclipse DCP specification includes:

- Specifying a format for self-issued identity tokens
- Defining a protocol for storing and presenting Verifiable Credentials and other identity-related resources
- Defining a protocol for parties to request credentials from a credential issuer

Eclipse DCP supports multiple trust anchors and allow participants to manage and verify presentations without needing third-party systems outside their control. Note that it is not a requirement for Eclipse DCP to specify a decentralized or "self-sovereign" identity protocol, but it may be based on it.  

The following are out-of-scope for Eclipse DCP:

- The definition of verifiable credentials types and schemas. This work should be done by other expert groups aligned with industry and use-case-specific requirements.   
- The definition of semantic models for trust. The creation of semantic trust models should be done by other expert groups and aligned with DCP through the *W3C Verifiable Credential Data Model*.
- The definition of specific ODRL policy vocabularies. This work should be done by other expert groups aligned with industry and use-case-specific requirements.    

 

Description

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
 

Why Here?

DCP has a natural affinity with other Eclipse projects, including the Dataspace Protocol Specification, Eclipse Dataspace Components, and Tractus-X. 

Future Work

We plan to further refine the specification, develop a compatibility test kit, and foster implementations both in the Eclipse Dataspace Components and Tractus-X projects.

Project Scheduling

We want to start work immediately.

Initial Contribution

The initial contribution will be the Tractus-X repository: https://github.com/eclipse-tractusx/identity-trust

Source Repository Type