Draft: Make any places in Tractus-X EDC which hardcode specific CX Verifiable Credentials configurable

[DanielaWuensch]

Overview

Currently, the process of data sovereignty is bound to a predefined set of ODRL policies and Verifiable Credentials - the Catena-X Policy Profile. This concept and the reference implementation should be enabled to be reused by other data spaces such as Factory-X or other Manufacturing-X dataspaces. Furthermore, it should be easy to include additional VCs, e.g. for Company Certificates. This requires a flexible and configurable reference implementation, which enables any Verifiable Credentials or any ODRL policies to be maintained, negotiated and verified.

Explain the topic in 2 sentences

Transform the hardcoded references to CX Credentials from the edc-extension to configurable one, which can be configured for a deployed EDC initially and updated at a later point in time after a restart without any data loss.

What's the benefit?

ODRL policy framework based on Verifiable Credentials can be easily extended and applied to other data spaces.

What are the Risks/Dependencies ?

It must not influence existing deployments to ensure that running Catena-X data exchange still works as before.

Detailed explanation

Current implementation

Hardcoded reference to CX Verifiable Credentials

Proposed improvements

At the following steps in E2E negotiation and data transfer processes, CX VCs are hardcoded in Tractus-X EDC implementation:

1. on Data Consumer Side: Initial call from EDC to Wallet: get STS Token uses deployment variable default-sts-scope... = e.g. https//w3id.org/catenax/DataExchangeGovernanceCredential , https//w3id.org/catenax/MembershipCredential , https//w3id.org/catenax/DismantlerCredential , https//w3id.org/catenax/BPNCredential ,

2. on Data Provider Side: after catalog request by Data Consumer and get Verifiable Presentation by Data Provider: check of Verifiable Presentation content against ODRL constraints (credentialResult) like in examples [1]

3. and 4. Analog calls like 1 and 2 if negotiation is triggered

4. and 6. Analog calls like 1 and 2 if data access token is refreshed is triggered

5. and 8. Analog calls like 1 and 2 if data are accessed and transferred

Links:

• MembershipCredentialConstraintFunction,
• FrameworkAgreementCredentialConstraintFunction
• DismantlerCredentialConstraintFunction

Configuration should be done

• at deployment
• at a later point in time without any data loss

Most likely this means it will happen in Helm Chart but further proposals are welcome.

Most likely only provider side need to be adapted. Consumer side uses in scope already the VCs based on configuration before.

Out of scope

...

Feature Team

Contributor

• @hemantxpatel
• Axel Albrecht as representative

Committer

• @arnoweiss
• Committer 2

User Stories

• Issue 1, linked to specific repository
• Issue 2, linked to another specific repository

Acceptance Criteria

• [ ] Concept how to do the flexible configuration in a discussion in Tractus-X EDC
• [ ] Tractus-X EDC: https://github.com/eclipse-tractusx/tractusx-edc/blob/main/edc-extensions/cx-policy/src/main/java/org/eclipse/tractusx/edc/policy/cx/ adapted to a configurable framework

Test Cases

Test Case 1

Steps

1. Do something
2. Click something
3. Add something

Expected Result

1. Expectation
2. Expectation
3. Expectation

Architectural Relevance

The following items are ensured (answer: yes) after this issue is implemented:

• [x] This feature aligns with our current architectural guidelines
  • Data Sovereignty: All data sharing activities across company boundaries follow the Catena-X Regulatory Framework, in particular the Data Exchange Governance, and the Dataspace Protocol via a compliant Connector (like the tractusx-edc or similar, see Connector KIT)
  • [x] CX-0010 Business Partner Number
  • [x] CX-0013 Identity of Member Companies
  • [x] CX-0018 Data Space Connectivity (EDC)
  • [x] CX-0049 DID Document Schema
  • [x] CX-0050 Framework Agreement Credential
  • [x] CX-0149 Verified Company Identity
  • Interoperability: Digital Twins are used (compliant to the Digital Twin KIT and the Industry Core KIT)
  • [ ] CX-0001 EDC Discovery API
  • [ ] CX-0002 Digital Twins in Catena-X
  • [ ] CX-0018 Data Space Connectivity (EDC)
  • Data Format:
  • [ ] The data model is based on a published Semantic Model
• [ ] The impact on the overall system architecture has been assessed. The Feature does not require changes to the architecture or any existing standard? Please have a look here on the overarching architecture
• [ ] Potential risks or conflicts with existing architecture has been assessed

Justification: (Fill this out, if at least one of the checkboxes above cannot be ticked. Contact the Architecture Management Committee to get an approval for the justification)

Additional information

• [x] I am aware that my request may not be developed if no developer can be found for it. I'll try to contribute a developer (bring your own developer)

[1]

Constraint (in Policy)	VC Type	claim	value
```json { "leftOperand": "cx-policy:FrameworkAgreement", "operator": "eq", "rightOperand": "DataExchangeGovernance:1.0" } ```	DataExchangeGovernanceCredential	type & credentialSubject.contractVersion	DataExchangeGovernanceCredential & 1.0
```json { "leftOperand": "Membership", "operator": "eq", "rightOperand": "active" } ```	MembershipCredential	type	MembershipCredential
```json { "leftOperand": "BusinessPartner", "operator": "eq", "rightOperand": "BPNLPLACEHOLDER" } ```	MembershipCredential	credentialSubject.holderIdentifier	BPNLPLACEHOLDER

[DanielaWuensch]

Refinement in progress. Refinement will be ready for review only by Nov 6, 2024. Please do not review this issue now.

[axelalbrechtatsap]

I like to contribute

[jimmarino]

These aren't hardcoded, except for potentially the Membership Credential mapping, but there are definitely a number of things that can be improved. The "EDC way" of doing things is to create an extension per dataspace for handling policies and credentials as opposed to runtime configuration. With this in mind:

• Check to ensure the Membership Credential is not automatically used in a "core" TX module
• Ensure all C-X policy and credential support are in identifiable extensions that can be excluded from another dataspace deployment

Note that a lot of additional items are required for the TX distribution to be usable outside of C-X:

• No use of BPNs
• No use of the EDC Discovery Service.

If the above are followed, another dataspace can use the core TX distribution without the C-X specific extensions.

It may be worth refining this issue to be "Separate C-X specific functionality and extensions in TX EDC"

[DanielaWuensch]

Based on proposal to create dedicated EDC extensions per Verifiable Credential, new sig-release issue will be planned based on this decision if first additional VC are known. This issue will not be planned for 2503