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:
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 ,
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]
and 4. Analog calls like 1 and 2 if negotiation is triggered
and 6. Analog calls like 1 and 2 if data access token is refreshed is triggered
and 8. Analog calls like 1 and 2 if data are accessed and transferred
[ ] 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)
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:
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 ,
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]
and 4. Analog calls like 1 and 2 if negotiation is triggered
and 6. Analog calls like 1 and 2 if data access token is refreshed is triggered
and 8. Analog calls like 1 and 2 if data are accessed and transferred
Links:
Configuration should be done
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
Committer
User Stories
Acceptance Criteria
Test Cases
Test Case 1
Steps
Expected Result
Architectural Relevance
The following items are ensured (answer: yes) after this issue is implemented:
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
[1]