Overview

Explain the topic in 2 sentences

Dataspace consumers should be able to send feedback about consumed data to the respective data provider, via a proper back channel. This back channel is the counter part for the forward channel and should be contained within the same transfer process context (same contract agreement and transfer process).

What's the benefit?

Providers won't need to create specific offers just to allow consumers to send feedback.

What are the Risks/Dependencies ?

Some changes are required in the upstream EDC, but they are already aligned with the respective commiter group.

Detailed explanation

"Bidirectional data transfers involve transmissions that can be sent by either the provider or consumer during the transfer's lifetime. The provider sends data over a forward channel, while the client uses a response channel (back channel) to send data related to the forward transmission. For example, a provider sends parts data over the forward channel, while the consumer sends data related to errors in the forward transmission via the response channel."

Current implementation

No current implementation. Workarounds are in place.

Proposed improvements

The concept for bidirectional transfers was already presented in a previous CatenaX release. The goal of this task is to provide an implementation of the concept.

Feature Team

Contributor

@rafaelmag110
@bmg13

Committer

@paullatzelsperger
@jimmarino

User Stories

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

Acceptance Criteria

[ ] Dataset consumers can send feedback messages - over a back channel - to the dataset provider under the same transfer process context.

Test Cases

Test Case 1

Feedback can be sent over a back channel.

Steps

Given a Provider has created an offer and specified a data address for the back channel

Then a consumer:

Find and Negotiate the Offer
Obtain a valid contract agreement
Start a transfer process using the obtained contract agreement
Search and obtain the required information to send feedback over the transfer process back channel

Expected Result

From 4. 4.1. The required information can be located 4.2. The information can be used to relay feedback to the data provider over the back channel

Expectation

Architectural Relevance

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

[ ] 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)
- [ ] CX-0010 Business Partner Number
- [ ] CX-0013 Identity of Member Companies
- [ ] CX-0018 Data Space Connectivity (EDC)
- [ ] CX-0049 DID Document Schema
- [ ] CX-0050 Framework Agreement Credential
- [ ] 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)

eclipse-tractusx / sig-release

Draft: Support for Data Transfer Feedback via Backchannels #936