[R25.03] [Architecture] Propose a B2C tech solution to enable public access of cx-data maintaining Data Sovereignty & CX Values

[matbmoser]

Overview

As we got to know by the VDA Verband der Automobilindustrie e. V. one of the requirements from the regulations is that a part of the "Battery Passports", "Digital Product Passports" and other products like the PCF Aspect' data MUST be accessed not in B2B by any public consumer in a B2C exchange. It was noted during a meeting with the Digital Product Pass Expert group and the sustainability domain that Catena-X has currenltly no plan or solution to tackle that.

I have something in mind already, but I would like to propose it formally and discuss it with the architecture committee first

Context

We need to start discussing this topic and decide how we can address this issue that affects DPP Expert Group, SSI, Data Sov, PCF. This is published in the regulations and if we want companies that join and use Catena-X "comply by design" (one of our golden rules) we need to address and give an answer to this topic.

Motivation

• I want to find how big is the problem, and what are the actual requirements on this topic, talking with the expert groups and discussion possible solutions.
• I want that people do not need to use two dataspaces or not use catena-x at all because this feature is not clarified or available.
• I want that manufacturers can provide this solution to their clients in a harmonized way, so that users can scan the qr code and with the browser retrieve the data from the manufacturer, or other manufacturers.
• I want that Catena-X can provide an answer to this topic so that companies choose Catena-X as a "complete" solution for complying with the regulations.
• I want to make it easy for people to access public data in Catena-X while still following standards.

Objectives

One possible solution

• Enabled a public access "Access & Usage Purpose" that any "self-deployed unauthorized" EDC can retrieve.
• In this way the protocol is still followed and just the "authorization" is skipped for public data.
• Acceptance of data usage conditions would be like the "cookies" acceptance banners we have today in most websites. The conditions shall mirror the regulations.
• And the EDCs can be found in the "DID:WEB" placed in the batterypass/dpp qr code.
• The security and data sovereighty would be not in the "data exchange level" but in the "data" level using Verifiable Credentials and Verifiable Presentations as proposed in this catena-x dpp verification whitepaper:
  • https://github.com/eclipse-tractusx/digital-product-pass/tree/main/dpp-verification
• No digital twin would be needed.

Explain the topic in 2 sentences

There MUST be a solution that allows end users to view data from OEMs. Currently, Catena-X supports only, B2B and not B2C because the EDC requires companies to be onboarded in Catena-X.

I want to propose and analyze the impact of enabling a tech solution for B2C interaction while still maintaining the Data Sovereighty, increasing the interoperability with other non-edc dataspaces.

What's the benefit?

Enables any users to use Catena-X Standards and Values (Data Sov, Decentrality, Interoperability, Secure) to retrieve data from B2C.
Increasing also the interoperability with multiple networks which do not use the EDC connector.

What are the Risks/Dependencies ?

• Architecture Committee
• Digital Product Pass Expert Group -> Problem Description
• Sustainability Committee
• Data Sovereighty Expert Group
• Certification Expert Group
• SSI Expert Group

Detailed explanation

I have drafted a proposal on how can Catena-X maintain their data sovereighty concept, and still be able to handover data throught the EDC to other non-edc dataspaces. Also providing a "public interface" for Customers to retrieve a limited set of data which lies behind the EDC in a Data Source.

This is mandated by regulation, so many organizations are implementing central solutions to enable this kind of behavior. So the idea here is to decentralize the public data provision and enable data sovereignty concepts using SSI.

In this way that the "complete" set of data would be shared via the "EDC" and the regulatory public data using another interface which needs to be proposed and discussed in this feature.

Current implementation

1. Eclipse Data Space Connectors (EDC) supports only B2B connections by design.
2. Catena-X is using just the EDC to retrieve and provide data for companies.
3. The EU regulations mandate that economic operator companies provide public data to customers.
4. Currently, Authorities and Customers are not allowed to retrieve data

Proposed improvements

1. Catena-X propose a standard for providing public data (B2C) with data sovereighty. Provides simple reference implementation.
2. Authorities and Consumers can retrieve a set of partial data using catena-x B2C interface and visualize the data.
3. Catena-X will help companies comply with the regulations and it will have success in the market
4. Companies that require more than just "public" data can use the "Connector" and the policies to retrieve the complete set of data.

Feature Team

Contributor

• @MariusPohl

• @hillgach

• @stanfaldin

• Per Hendrik

Committer

• @matbmoser

User Stories

• Issue 1: Document and Specify the problem
• Issue 2: Draft a technical concept which gives a solution to the B2C public data access problem
• Issue 3: Create a whitepaper with the Architecture Committe in sig-architecture
• Issue 4: Present to the respective committees and expert groups, aligning the perspectives.

Acceptance Criteria

• The problem statement is cleary defined
• The technical solution is drafted and clear
• Consensus from the Architecture Committee is granted
• A white paper document in Github must be generated to document this proposal sig-architecture

Test Cases

None

Expected Result

• Catena-X has at least a draft solution for B2C at the Architecture Committee publishing whitepaper
• Feedback is gathered from all the interested expert groups
• Catena-X Expert Groups (DPP, PCF, ESG, etc..) can propose a standard for this use case

Examples

• https://thebatterypass.io/en/did:web:acme.battery.pass:0226151e-949c-d067-8ef3-162431e28976
• https://vera-staging.dpp.spherity.dev/?did=did:web:api-rcs.susi.spherity.dev:did-registry:acme-power-drive-x-1000-3985-cb-1739186-d-8-d
• https://youtu.be/_-eDg3dO7Yo?si=nhni1KIMBkoaCQxA&t=663

Architectural Relevance

It will enable Catena-X to do B2C data exchanges, maintaining data sovereignty and increasing interoperability.

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: This feature will be proposed in the Architecture Management committee

Additional information

• 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)

Other Possible Solutions

• Enable DID:WEB interface that is able to retrieve public data from an EDC connector.
  • 
  • Maybe the Web App in the consumer side is an "not authenticated connector?"
  • Maybe this connector can have a "self issued credential? by default?" so anyone can deploy it in their local and retrieve public data???
  • How would catena-x specify this public data agreement
• Create a new type of "operating"/"certified" company which is allowed to provide public data to the external world using an application without login.
  • 

[matbmoser]

@lgblaumeiser now that I am not inside yet of the Architecture Committee can you let them aware that there is this problem, I have found it yesterday in a meeting with @stanfaldin and the VDA.

I want to take this topic and discuss with them together once I join Catena-X.

[matbmoser]

I would like to create a "sig-architecture" so we can centralize and publish this topics. @stephanbcbauer what do you think about that?

[matbmoser]

Maybe place the dpp in Cofinity-X? And all then Cofinity-X would enable a public interface, retrieving data from the edcs from companies.

Maybe we could add a new operator company type, which are certified or allowed to provide public data from Catena-X.

Maybe like this:

[matbmoser]

I have added a new diagram to explain what is my first solution proposal...

-> Notes:

Advantages:

• Acceptance terms shall be like the "cookies" acceptance banner we use in most of the the websites now a days.
• Anyone can deploy their own Tractus-X EDC and retrieve public available data without a "membership" (which requires you to be a company to join a dataspace)
• I would trust what is signed by the data provider, whatever is not signed and presented could in theory have been random generated. What is signed brings trust that it comes from the right font.
• The data provider can still setup their own usage policies (which shall mirror the regulations)
• The data in transit could be encrypted with the public key from the first did document... Only the one that has the "did:web" can retrieve the data.
• You could retrieve by yourself the public battery pass data from your own car then...

Disavantages:

• Still has complexity in the consumer side if data wants to be "trusted".
  • But it can be reduced with an simple "open source" application
• There is no way to know if the consumer is "trustable"
  • But is public data anyway, it adds only more layers of security over a HTTPs connection.
• Not everyone could deploy and configure an EDC by themselves.
  - Maybe they could have a simple "mobile app" that can install that?

[matbmoser]

The new Volvo has it already https://youtu.be/_-eDg3dO7Yo?si=nhni1KIMBkoaCQxA&t=663 and you are able to access with your phone. That's a B2C connection that can be done for other manufacturers with Catena-X. The technical "stardards" or ground for this connection also needs to be defined, so other economic operators can also reuse this.

Great job Volvo and Circulor!

[stephanbcbauer]

Some hints from Release Management (@ther3sa) and Tractus-X Project Lead (@stephanbcbauer)

• Status currently in Inbox. ⇾ Only features with status backlog are considered in open planning
• Please add missing sections from the feature template, or fill them out

[matbmoser]

The idea here is also that the QR Codes that are in thar Car can remain the same, but the way how you access and ammount of data you get will vary on the "access type" if public it will be limited and if private and using Catena-X it would retrieve the ammount of data you can see.

[matbmoser]

Ideas

• Define clear scope for the use case
• Data Exchange KIT?
• Because is public it does not mean that the governance over the data shall be given away:
  • Implement a cookie acceptance governance??
  • Using the Catena-X Data Certification and Verification Framework to assure the data sovereignty of data once it leaves catena-x premises

[mhellmeier]

Thank you for the detailed description!

Some hints and thoughts from my side:

I want to propose and analyze the impact of enabling a tech solution for B2C interaction while still maintaining the Data Sovereighty, increasing the interoperability with other non-edc dataspaces.

I would always change the wording from "EDC" to "Dataspace Protocol" (DSP). The EDC is just one possible reference implementation based on the protocol. Since nearly all dataspaces are under the umbrella of the International Data Spaces Association (IDSA), we should have an eye on those other data spaces. A good overview is the Dataspace Radar. Historically, the Connector and the Protocol also started at the IDSA and are pushing to bring all dataspaces to the DSP.

Increasing also the interoperability with multiple networks which do not use the EDC connector.

Do you know another non-Catena-X company or dataspace that is interested in this? We should collaborate with them to prevent building a solution that doesn't fit the market.

• Acceptance of data usage conditions would be like the "cookies" acceptance banners we have today in most websites. The conditions shall mirror the regulations.

If we talk about publicly available data that everyone can view and use, we do not need specific usage conditions. Therefore, we don't need those acceptance banners.

• I want that manufacturers can provide this solution to their clients in a harmonized way, so that users can scan the qr code and with the browser retrieve the data from the manufacturer, or other manufacturers.

There is another standard for this called EPCIS from GS1 (these are the guys that generate the barcodes on all consumer products). This standard is made for traceability so that customers can get information about their products. In this area, the food industry is way ahead of us (if you buy a fish in the supermarket, you can trace it back to the angler and the ocean). Maybe we can get some inspiration from them.

[matbmoser]

Thank you for the detailed description!

Some hints and thoughts from my side:

I want to propose and analyze the impact of enabling a tech solution for B2C interaction while still maintaining the Data Sovereighty, increasing the interoperability with other non-edc dataspaces.

I would always change the wording from "EDC" to "Dataspace Protocol" (DSP). The EDC is just one possible reference implementation based on the protocol. Since nearly all dataspaces are under the umbrella of the International Data Spaces Association (IDSA), we should have an eye on those other data spaces. A good overview is the Dataspace Radar. Historically, the Connector and the Protocol also started at the IDSA and are pushing to bring all dataspaces to the DSP.

Increasing also the interoperability with multiple networks which do not use the EDC connector.

Do you know another non-Catena-X company or dataspace that is interested in this? We should collaborate with them to prevent building a solution that doesn't fit the market.

• Acceptance of data usage conditions would be like the "cookies" acceptance banners we have today in most websites. The conditions shall mirror the regulations.

If we talk about publicly available data that everyone can view and use, we do not need specific usage conditions. Therefore, we don't need those acceptance banners.

• I want that manufacturers can provide this solution to their clients in a harmonized way, so that users can scan the qr code and with the browser retrieve the data from the manufacturer, or other manufacturers.

There is another standard for this called EPCIS from GS1 (these are the guys that generate the barcodes on all consumer products). This standard is made for traceability so that customers can get information about their products. In this area, the food industry is way ahead of us (if you buy a fish in the supermarket, you can trace it back to the angler and the ocean). Maybe we can get some inspiration from them.

Thank you @mhellmeier for your feedback.

I would always change the wording from "EDC" to "Dataspace Protocol" (DSP). The EDC is just one possible reference implementation based on the protocol. Since nearly all dataspaces are under the umbrella of the International Data Spaces Association (IDSA), we should have an eye on those other data spaces. A good overview is the Dataspace Radar. Historically, the Connector and the Protocol also started at the IDSA and are pushing to bring all dataspaces to the DSP.

Forgive my unprecision with the "terms", please not understand me wrong when I say "change" the edc, is just one of the possible solutions we could propose, to improve the public data access using the edc, and not changing the protocol, it would be something additional or like an extension. Lets talk more about it in person, when we will try to find a way forward.

Increasing also the interoperability with multiple networks which do not use the EDC connector.

Do you know another non-Catena-X company or dataspace that is interested in this? We should collaborate with them to prevent building a solution that doesn't fit the market.

-> Factory-X said they need this feature + CX-NEXT also...
And this is "MANDATORY" by the regulations, and if we want to comply by design we should give at least an answer..
->Battery Pass EU Consortium (which is already in colaboration with us somehow)
-> ID Union was interested once in this technology and data access (still need to confirm)

There is another standard for this called EPCIS from GS1 (these are the guys that generate the barcodes on all consumer products). This standard is made for traceability so that customers can get information about their products. In this area, the food industry is way ahead of us (if you buy a fish in the supermarket, you can trace it back to the angler and the ocean). Maybe we can get some inspiration from them.

Good idea, my point is that the "id" should always remain the same and the "access" for it shall be defining the amount of data you should get.
-> Thx for the hint, but note that the GS1 is a proprietary solutions and we from the DPP group have decided not to use it, because we have not the rights. But lets talk about it.

• Acceptance of data usage conditions would be like the "cookies" acceptance banners we have today in most websites. The conditions shall mirror the regulations.
  If we talk about publicly available data that everyone can view and use, we do not need specific usage conditions. Therefore, we don't need those acceptance banners.

Because a data is "public" accesible and viewable, does not mean that you need to loose the data sovereignty over it. Just because is public and you can see it as a consumer does not means that is yours.
-> And here I want to bring the value of Catena-X Certified data.

@mhellmeier lets discuss this further together with the Architecture Committee ;)

[nd-circulor]

Please consider as well, that "external" data access is also required for restriced data in a battery DPP for persons with legitimate interest (e.g. recyclers) as well as authorities who are not necessarily onboarded on CATENA-X as well. So it should be considered that role-based data access policies on attribute level are available as well for external data access. Detailed definition of access groups for the battery passport are part of future secondary legislation. Which data points are restricted in the battery passport is described in the battery regulation and concluded here (refer to column O "access rights"): https://thebatterypass.eu/assets/images/content-guidance/pdf/2023_Battery_Passport_Data_Attributes.xlsx

[matbmoser]

I have found that if Consumers want to retrieve data from Catena-X or any other dataspace based on Tractus-X, they need to have a deployed EDC and application available. To help them to use a possible "Tractus-X" browser as a application to consumer the data from the EDC, an easy approach to reduce complexity would be to use a pattern like this one: eclipse-tractusx/sig-architecture#5

Which is being drafted by me, and also proofed to be working. Allowing data exchanges to be fast and simple for the application.

[matbmoser]

I have created the first pull request with the draft for the Dataspace Usage Pattern Connect & Exchange:
eclipse-tractusx/sig-architecture#6

The Idea is to merge it and let the community give the feedback to it and improve it, since is open source.