Skip to main content
Release: CX-Neptune (Preview)

How: Data Space Operations

This chapter provides an overview of operational key processes and compliance requirements within the Catena-X data space. It serves as a binding reference for all stakeholders involved in the application, operation, governance, and continuous evolution of these processes.

The objective of this chapter is to ensure a consistent understanding and implementation of operational procedures by documenting current best practices, responsibilities, and process descriptions.

Onboarding Process​

The onboarding process enables prospective participants to join the Catena-X data space in a structured, standardized, and trust-based manner. Organizations intending to participate in the Catena-X data space in a role that requires onboarding MUST complete the onboarding process defined in the related standard CX-0006 Registration and Initial Onboarding. The process ensures that each participant is uniquely identifiable, successfully verified, and established as a trusted member of the data space before being authorized to engage in data transactions. It further defines the responsibilities of the involved actors and the mandatory sequence of activities required to establish participation.

Implementation of the Self Sovereign Identity Concept​

Self-Sovereign Identity (SSI) is the next step beyond user-centric identity, and that means it begins at the same place: the user must be central to the administration of identity. That requires not just the interoperability of a user's identity across multiple locations, with the user's consent, but also true user control of that digital identity, creating user autonomy. In Catena-X there are several different components to implement the SSI approach. This includes the Issuer Component and the BPNBPN A BPN is the unique identifier of a partner within Catena-X. DID Resolution Service (BDRS) which is currently classified as Core Service B due to the current state of our technical architecture, and is accordingly also managed by the CSP-B. In addition to the Issuer Component, the CSP-B also operates an Identity Wallet and the Authority Schema Registry. The Authority Schema Registry is managed by the Catena-X Association, which has nominated and commissioned the CSP-B to operate this service. To enable a stable and secure operation, the CSP-B can put the schemas in a dedicated repository. The CSP-B must use the currently operational version in the Catena-X data space. All the components can be seen in the Service Map (see Chapter What: Service Map) This concept will evolve in future releases, the details of which can be found in Chapter Further Integration of SSI Technologies.

Data Exchange based on SSI​

The processes to participate in a use case as well as to offer, exchange, and use data are defined as follows (see Figure Data Exchange Process):

Data Exchange Process Data Exchange Process

Note: the flow is a comprehensive picture of the actual interactions taking place. It covers the presentation flow. The issuance flow is not visualized.

  1. Initiate Secure Token Creation

    Retrieve a One-Time-Token (OTT) to allow the provider to request Verifiable Presentations (VP) within a pre-defined, authorized scope.

  2. Query catalog/offers

    With the query of the data provider catalog, the consumer EDC submits the previously generated one-time token to allow the provider to call the VP under #3.

  3. Query VP

    The provider calls the consumer wallet with the provided One-Time-Pad (OTP). The consumer wallet validates the (One-Time-Token) OTT and if successful, submits the VP.

  4. Validate VP

    The provider connector validates the VP and matches the consumer VP scope with the available data offer policy rules configured.

  5. Submit catalog

    Upon successful validation (by the provider EDC), all data offers, where the data access policies set by the provider match the verified credentials owned by the data consumer, are sent to the customerCustomer In the context of OSim, the receiver of produced goods from a supplier.. Any data offers that require verified credentials that the data consumer does not have will not be sent/published to the data consumer. Participation in a Catena-X Use Case requires the selection of at least one standardized purpose. The list of standardized Catena-X purposes can be found in the official Catena-X Open Digital Rights Language (ODRL) profile.

  6. Manual checking of data offering policies

    Configured data offer policies must be manually checked by the data consumer.

    • If a purpose is specified, the purpose must be validated internally by the data consumer. The purpose may refer to an individual contract concluded between the data consumer and the data provider. The data consumer must review the contract and decide whether the policies are acceptable for the specific data offering based on the established policies (see next step 7).
    • If no purpose is specified, the negotiation can start immediately, as the access and usage policies are automatically technically enforced and validated by the connectors.

  7. Decision on the purpose of the data offer

    Based on step 6 individual data contract validation, the data consumer must decide whether to proceed with the negotiation or whether to disagree with the individual purpose. If there is disagreement, the negotiation should not be started. If there is consent, the data consumer can start the negotiation.

  8. Contract negotiation

    The data consumer starts the contract negotiation by sending a request for an agreement/contract.

  9. Contract conclusion/success

    The connector of the data provider receives the negotiation requests, validates the access and usage policies of the specific data offer requested by the data provider, and matches it with the VP of the data consumer. If the data consumer has all relevant credentials, the agreement is successfully concluded, and an agreement log is stored in both connectors.

  10. Data transfer

    Data transmission/access by the data consumer can take place as long as the contract is active.

EDC Deployment and Usage Premises​

Each data space participant has its own organizational structure, consisting of different legal entities and/or subsidiaries. Depending on the organizational structures, data space participants must consider how to organize the representation of their organization in the Catena-X data space. This includes considerations for setting up connector instances regarding organizational, technical, and legal conditions. The following premises apply:

  • The data exchange always takes place between two legal entities, as only their representatives can sign legally binding contracts.
  • Legal entities must be registered and known in the data space.
  • To represent a legal entity in the data space, an associated business partner number (BPNLBPNL The unique identifier of a legal entity of a partner within Catena-X (e.g., a company).) is required.
  • The deployment and use of at least one connector (e.g., EDC) per company (i.e. legal entity) for data exchange is mandatory.
  • To minimize effort and costs, it is recommended that a parent company provides a connector that can also be used by subsidiaries. A technical description of this will follow soon.
  • The connector negotiates data usage between endpoints (data plane) by synchronizing access and usage policies between data providers and data consumers.
  • There is no data processing or reviewing of data within the connector itself.
  • Data usage takes place instead at the endpoints of the data providers or data consumers, respectively.
  • Data usage with respect to location and assignment to computer instances/platforms is independent of the runtime environment of the connector itself.

There are various options for organizational structures and data exchange scenarios such as "one legal entity and one site in one country", "one legal entity and multiple sites in one country" or "one legal entity and multiple sites in different countries". For more details on possible connector usage scenarios, please refer to our Onboarding Guide. This includes also the different options to obtain a connector, e.g., it can be acquired via an ESP, it can be self-developed or adapted from open-source, or it can be part of a business application from a BAP. If the data exchange does not take place between several legal entities within Catena-X as defined above, no EDC is required. An example would be the connection of the CSP-B to the GXDCH. For this connection no connector is needed, because this is not an exchange of data between two legal entities within Catena-X.

Supply Chain Visibility (BETA)​

This chapter is released as beta, which therefore is as of now not normative and may change significantly in subsequent iterations. The aim is to provide a definition and a guideline for 1U1D. In doing so, we want to start the review of the definition - so that we have long-term an overview of which use case has which requirement.

Catena-X is committed to making sovereign data exchange easy to use. This includes not just technical aspects but also support compliance scenarios, for example in terms of anti-trust legislation, confidentiality clauses in supply contracts, etc..

The resulting guideline for supply chain visibility in Catena-X data space is known as the "One Up / One Down Rule" (1U1D-Rule). This means that each company in the supply chain can only use and share data with its direct suppliersSupplier In the context of OSim, the producer of goods. (One Down / N+1) and customersCustomer In the context of OSim, the receiver of produced goods from a supplier. (One Up / N-1). It ensures that companies receive enough information to fulfill their specific tasks and to enable Catena-X to fulfill use cases throughout the entire value chain, but at the same time retain control over access to sensitive data.

In practice, the situation is more complex. For example, a legal entity may have other subsidiaries that are part of the same value chain or there may be various assembly steps before a product is handed over to the customerCustomer In the context of OSim, the receiver of produced goods from a supplier.. Therefore, there are two possibilities in Catena-X to apply the 1U1D rule in this case, part-based visibility and entity-based visibility.

Data Exchange Process
1U1D visibility

The figure shows a generic section of the value chain. The basic principle - one up (N-1) exchange data with the customerCustomer In the context of OSim, the receiver of produced goods from a supplier. and one down (N+1) exchange data with the supplierSupplier In the context of OSim, the producer of goods. is generally valid. The number of external legal entities depends on the respective business relationships starting from the Tier-N. The orange box represents the Tier-N, including all internal value creation processes and all internal subsidiaries. The individual parts show the process by which they are sourced from different suppliersSupplier In the context of OSim, the producer of goods. and assembled into a new product. The green box shows which information can be used by the external parties.

Besides this implementation suppliersSupplier In the context of OSim, the producer of goods. and customersCustomer In the context of OSim, the receiver of produced goods from a supplier. have to agree on how the 1U1D-Rule applies to their specific contractual agreement and use case. For example, if there are agreements in place to handle directed parts or ad-hoc agreements to handle a critical supply situation, supply chain visibility may be extended.

The default standard for part relationships is defined in Catena-X Standards CX-0126 and CX-0127. An overarching explanation can be found in the Tractus-X KITS.

Part-based visibility​

Part-based visibility makes a more granular distinction in data exchange than the entity-based approach, as it differentiates between the individual components. For example, only data about the part that is directly related to an external legal entity is provided or requested. This means that the entire value chain is not transparent. For the functionality of the use cases in Catena-X, the relationship between the various parts must still be known, even if not all of them are provided. In this figure, data is exchanged with Tier-X-1 (1Up) only via the part that has a direct relationship with it.

Entity-based visibility​

In comparison to part-based visibility, entity-based visibility does not differentiate between the individual subcomponentsSubcomponent A Subcomponent is a separate product that can be assembled into a customer product. or the assemblies. This means that all subparts and process steps of the respective other legal entity (One Up / N-1) or (One Down / N+1) are provided. In this figure, data is exchanged with Tier-X-1 (1Up) about the part that has a direct relationship with it and the assemblies. It is recommended that supply chain visibility respects symmetrical relationships where granularity of data visibility is equivalent on supplierSupplier In the context of OSim, the producer of goods. and customerCustomer In the context of OSim, the receiver of produced goods from a supplier. side.

Copyright © 2026 Catena-X Automotive Network e.V. All rights reserved. For more information, please see Catena-X Copyright Notice.