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

CX-0018 Dataspace Connectivity v.4.3.0

ABSTRACT​

This document specifies the communication requirements for data exchange between participants in the Catena-X data ecosystem. The aim is to ensure interoperability and data sovereignty at the same time.

1 INTRODUCTION​

1.1 AUDIENCE & SCOPE​

This section is non-normative

AUDIENCE​

The role definition is based on the definition of the CX Operating Model.

The standard is relevant for the following roles, as they must be certified against it:

  • Enablement Service Provider
  • Business Application Provider
  • Data Provider/Consumer

Note: The normative section of this standard uses the DSP-definitions of "Consumer" and "Provider". Any of the aforementioned Catena-X-roles can assume either DSP-role.

The standard is relevant for the following role, as they must certify against this standard:

  • Conformity Assessment Body

The standard is relevant for the following role, as they carry out their advisory on the basis of this standard.

  • Advisory Provider

SCOPE​

This document covers the requirements for dataspace connectivity. It describes

  • how communication between dataspace participants must take place,
  • which transfer type profiles have to be supported by any Provider or Consumer,
  • how communication with credential services must take place,
  • and which conventions apply to datasets.

1.2 CONTEXT AND ARCHITECTURE FIT​

This section is non-normative

The connector is the main technical component that implements dataspace connectivity including data sovereignty and interorganizational interoperability. It is part of the enablement services, which are intended to enable participation in the Catena-X ecosystem.

The following figure shows how the connector fits into the overall framework of Catena-X to exchange data.

Framework of data exchange

Figure 1: Framework of data exchange

1.3 CONFORMANCE AND PROOF OF CONFORMITY​

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words MAY, MUST, MUST NOT, OPTIONAL, RECOMMENDED, REQUIRED, SHOULD and SHOULD NOT in this document are to be interpreted as described in BCP 14 RFC2119, RFC8174 when, and only when, they appear in all capitals, as shown here.

1.4 TERMINOLOGY​

TermDescriptionReference
International Data Spaces Association (IDSAIDSA The IDSA is an organization working to create the future of the global digital economy with International Data Spaces (IDS): a secure, sovereign system of data sharing where participants can realize the full value of their data.)Organisation that provides standards and architecture solutions for secure, sovereign data sharing within so-called dataspaceshttps://internationaldataspaces.org
Eclipse Dataspace Working Group (EDWG)Eclipse Foundation Working Group that develops and maintains specifications for the data exchange within a dataspacehttps://dataspace.eclipse.org
Dataspace Protocol (DSP)Protocol specification, designed to facilitate interoperable data sharing within a dataspace, currently governed by the EDWGhttps://github.com/eclipse-dataspace-protocol-base/DataspaceProtocol
Decentralized Claims Protocol (DCP)Protocol specification for the exchange of verifiable credentials and presentations between a connector and a wallet as well as the issuance of such credentials by an Identity Providerhttps://github.com/eclipse-dataspace-dcp/decentralized-claims-protocol
Connector (or formal Participant Agent)(Catena-X) Technical component that allows business applications to interact with each other within a dataspacehttps://github.com/eclipse-tractusx/tractusx-edc
(Catena-X) Business Application.(Catena-X) Application that enable functionality of at least one use case and is hosted by a Business Application Providerhttps://eclipse-tractusx.github.io/developer
Catena-X MarketplaceThe Marketplace inside a portal, allowing participants of the Catena-X network to search and select Catena-X Business Applicationshttps://catena-x.net/en/offers/portal-marketplace
Open Data Rights Language (ODRL)Policy expression language that provides a flexible and interoperable information model, vocabulary, and encoding mechanisms for representing statements about the usage of content and serviceshttps://www.w3.org/TR/odrl-model, https://www.w3.org/TR/odrl-vocab, https://w3c.github.io/odrl/bp
  • The terms Consumer, Provider, Participant Agent are adopted from the DSP.
  • The term Credential Service is adopted from the DCP.
  • The terms Core Service Provider A/B (CSP A/B), Onboarding Service Provider (OSP), Enablement Service Provider (ESP), Business Application Provider (BAP), Advisory Provider (AP) and Conformity Assessment Body (CAB) are adopted from the CX Operating Model

2 MAIN CONTENT​

This section is normative

This section uses terms that are taken from the DSP context specified in "dspace": "https://w3id.org/dspace/2025/1/context.jsonld". Terms that are not defined in this context are provided in an expanded version.

2.1 Communication between Dataspace Participants​

Dataspace Participants exchange data via their Participant Agents which are a logical component that communicates via a set of well-defined messages.

Participant Agents MUST facilitate data exchange according to the HTTPSHTTP HTTP is an application-layer protocol for transmitting hypermedia documents (such as HTML). It was designed for communication between web browsers and web servers, but can also be used for other purposes. binding defined in the Dataspace Protocol.

Providers and Consumer MUST expose the specified endpoints for the

  • Catalog Protocol
  • Contract Negotiation Protocol
  • Transfer Process Protocol
  • Version Metadata

as specified in the HTTPSHTTP HTTP is an application-layer protocol for transmitting hypermedia documents (such as HTML). It was designed for communication between web browsers and web servers, but can also be used for other purposes. binding of the Dataspace Protocol.

2.1.1 Usage of DID in the data exchange​

A Participant Agent MUST use the DID as the Participant identifier. The DID refers to the DID document that holds the information needed to access the participant's Credential Service. This DID MUST be used in all protocol message properties that identify a Participant for both the Consumer and the Provider.

2.2 Transfer Type Profiles​

This section provides regulations for a non-exhaustive selection of Transfer Type Profiles. Further profiles can be defined by extensions to this standard. A Provider MAY offer as many Transfer Type Profiles as necessary to support all intended use cases.

Despite the IRIs of the currently used identifiers for transfer types are not yet included in the DSP-context, they will be used as preliminary identifiers.

Providers SHOULD be able to serve data according to that signal when data transfer is requested by a Consumer via a TransferRequestMessage.

2.2.1 HttpData-PULL​

A Provider MUST add a "format":"HttpData-PULL" to the Distribution of a Dataset in the Catalog response to indicate support for the HttpData-PULL transfer type.

A Consumer MUST send a TransferRequestMessage with "format":"HttpData-PULL" to start an HttpData-PULL transfer process. The dataAddress property is not required and won't be processed by the Provider.

A Provider MUST send a TransferStartMessage with sufficient information in the dataAddress property so that an HTTPHTTP HTTP is an application-layer protocol for transmitting hypermedia documents (such as HTML). It was designed for communication between web browsers and web servers, but can also be used for other purposes. request to the endpoint may succeed. The endpointType property MUST be https://w3id.org/idsa/v4.1/HTTP. The following endpointProperties MUST be added to the object as specified in the table below:

Namedescription
https://w3id.org/edc/v0.0.1/ns/endpointREQUIREDThe endpoint URL of the dataplane to access the data assetAsset On the Data Provider side, an Asset describes the data set which will be shared or can be consumed by a Data Consumer..
https://w3id.org/edc/v0.0.1/ns/authorizationREQUIREDThe access token to access data. To be included in the Authorization header of an ensuing HTTPHTTP HTTP is an application-layer protocol for transmitting hypermedia documents (such as HTML). It was designed for communication between web browsers and web servers, but can also be used for other purposes. request without any additions/modifications.
https://w3id.org/edc/v0.0.1/ns/authTypeOPTIONALHint for the authorization scheme expected by the endpoint. Clients are not required to process this property.
https://w3id.org/tractusx/auth/refreshEndpointOPTIONALEndpoint to refresh the access token using the refreshToken. It behaves as defined in RFC6749 section 6 using an STS-Token for authentication.
https://w3id.org/tractusx/auth/refreshTokenOPTIONALThe refresh token to present to the refreshEndpoint in conjunction with the old access token.
https://w3id.org/tractusx/auth/expiresInREQUIREDTime to live for the access token after issuance.

The url in the endpoint and the access token in the authorization property are the means for the Provider Participant Agent to furthermore control the access to the data. I.e., the endpoint SHOULD be limited to the relevant scope needed to fulfill the contract and the access token MUST contain necessary information, that allows the Business Application to make further authorization decisions concerning the request, i.e., to decide whether the resource requested is covered by the negotiated contract.

Which information is necessary for authorization decisions is an implementation detail of the Business Application and therefore not in scope of this standard!

2.2.2 AmazonS3-PUSH​

A Provider MUST add a "format":"AmazonS3-PUSH" to the Distribution of a Dataset in the Catalog response to indicate support for the AmazonS3-PUSH transfer type.

A Consumer MUST send a TransferRequestMessage with format:AmazonS3-PUSH and a dataAddress property to start an AmazonS3-PUSH transfer process. The dataAddress property MUST contain a endpointType property set to AmazonS3. The endpointType MUST be decorated with relevant endpointProperties as follows:

Namedescription
https://w3id.org/edc/v0.0.1/ns/typeREQUIREDDefines the AssetAsset On the Data Provider side, an Asset describes the data set which will be shared or can be consumed by a Data Consumer. type (AmazonS3)
https://w3id.org/edc/v0.0.1/ns/bucketNameREQUIREDDefines the name of the destination S3 bucket.
https://w3id.org/edc/v0.0.1/ns/regionREQUIREDDefines the region of the destination bucket (us-east-1, eu-west-1 ...)
https://w3id.org/edc/v0.0.1/ns/objectNameOPTIONALDefines the desired name of the S3 object in the destination bucket.
https://w3id.org/edc/v0.0.1/ns/folderNameOPTIONALDefines the desired folder name for S3 objects to be grouped (folderName/) in the destination bucket.
https://w3id.org/edc/v0.0.1/ns/secretREQUIREDDefines the Json object as a Json-escaped string holding "edctype": "dataspaceconnector:secrettoken" "accessKeyId":"<ACCESS_KEY_ID>", "secretAccessKey": "<SECRET_ACCESS_KEY>" and optionally for temporary access "sessionToken": "<SESSION_TOKEN>" and "expiration":"time-in-seconds" properties.

A Provider MUST send a TransferStartMessage with an empty dataAddress property. The Provider MUST execute a transfer as specified by the received request.

2.2.3 AzureStorage-PUSH​

A Provider MUST add a "format":"AzureStorage-PUSH" to the Distribution of a Dataset in the Catalog response to indicate support for the AzureStorage-PUSH transfer type.

A Consumer MUST send a TransferRequestMessage with format:AzureStorage-PUSH and a dataAddress property so that triggering a transfer to the endpoint may succeed. The endpointType property MUST be AzureStorage. The endpointType MUST be decorated with endpointProperties as follows:

Namedescription
https://w3id.org/edc/v0.0.1/ns/typeREQUIREDDefines the AssetAsset On the Data Provider side, an Asset describes the data set which will be shared or can be consumed by a Data Consumer. type (AzureStorage)
https://w3id.org/edc/v0.0.1/ns/accountREQUIREDDefines the name of the destination Azure Storage account.
https://w3id.org/edc/v0.0.1/ns/containerREQUIREDDefines the name of the destination Azure Storage container.
https://w3id.org/edc/v0.0.1/ns/blobNameOPTIONALDefines the desired name of the blob in the destination storage. The Data Provider might ignore that, if the data source contains multiple files.
https://w3id.org/edc/v0.0.1/ns/folderNameOPTIONALDefines the desired folder name for blobs to be grouped (folderName/) in the destination storage account.
https://w3id.org/edc/v0.0.1/ns/secretREQUIREDDefines the Json object as a Json-escaped string holding "edctype":"dataspaceconnector:azuretoken","sas":"<sas-token>" and "expiration":"time-in-seconds" properties.

A Provider MUST send a TransferStartMessage with an empty dataAddress property. The Provider MUST execute a transfer as specified by the received request.

2.3 Communication with a Credential Service​

This standard assumes that each Participant has been issued a set of Verifiable Credentials (VCs) according to the CX-0050 standard. These VCs are stored in a Credential Service.

A Consumer MUST be able to retrieve an appropriately scoped STS-Token according to the requirements of the Verifiable Presentation Protocol (VPP) (see Decentralized Claims Protocol (DCP)). This token MUST be included in the Authorization header in all DSP messages sent to the Provider (see DSP) and, in addition, in token refresh requests to the refreshEndpoint (see HttpData-PULL).

The scope of the token for requesting a Catalog MUST include the following credentials as defined in CX-0050:

  • Membership Credential
  • BPNBPN A BPN is the unique identifier of a partner within Catena-X. Credential
  • Framework Agreement Credential

A Provider MUST be able to receive and securely verify the sent STS-Token and derive information on a Consumer's Credential Service in order to execute the DCP VPP Request 6. This corresponds to the role of Verifier.

2.4 Policy Value to Verifiable Credential Mapping​

The conventions for policy constraints and the relevant constraints for Verifiable Credential checking are defined in the Catena-X standard CX-0152 Policy Constraints for Data Exchange. Based on this, the connector MUST support the verification of Verifiable Credential as described below.

The mapping between a policy constraint referencing a verifiable credential and the credential name depends on the type of credential.

  • For credentials requesting the rightOperand as active the leftOperand is the base for the credential name.
  • For other policy constraints referencing a verifiable credential, the rightOperand is the base for the credential name

Based on the corresponding base name of the credential, the following steps have to be applied:

  • The given base name potentially needs to be separated by the first “:” to separate the version term.

  • Thereafter, the term “Credential” needs to be appended to the base name.

  • If a version is available, the content has to be stored for credential evaluation purposes. The version is handled as a literal and can only be used for equality comparisons.

Example (rightOperand to Credential):

  • DataExchangeGovernance:x.x -> DataExchangeGovernanceCredential with version “x.x”

2.5 Conventions for Datasets​

A Provider MUST annotate all instances Dataset in a Catalog with the following properties:

  • http://purl.org/dc/terms/type holding an object with at least an @id property pointing to a concept describing what type of APIAPI An API is a way for two or more computer programs to communicate with each other. this Dataset represents, i.e., which protocol to use to interact with the Dataset. Subsequent standards define the exact value this property shall hold, depending on the business scenario. The set of concepts is maintained in the taxonomy https://w3id.org/catenax/taxonomy# and MUST extend the concept https://w3id.org/catenax/taxonomy#Asset.
  • https://w3id.org/catenax/ontology/common#version holding a string with SemVer semantics indicating the APIAPI An API is a way for two or more computer programs to communicate with each other. version of the APIAPI An API is a way for two or more computer programs to communicate with each other. that was typed by the http://purl.org/dc/terms/type property. It is allowed to use version information that is incomplete according to SemVer. Subsequent standards define the exact value this property shall hold, depending on the business scenario.

2.6 Participant Agent Management​

A Catalog offered by a Providers Participant Agent MUST provide only Dataset instances that can be negotiated with the same Participant Agent.

A Provider MUST publish all Participant Agents that should be detectable by a Consumer by specifying the participant's version endpoint address in the DID document as specified in the CX-0049 DID Document standard as an entry in the service section of type DataService. The endpoint address has to be a URL in the format https://subdomain.provider-domain.com/subpath/.well-known/dspace-version, with subpath being an arbitrary path below the Provider's chosen domain. The described endpoint represents a resource that when called with GET returns version metadata as defined in section Protocol Version Handling.

The path https://subdomain.provider-domain.com/subpath MUST be the path used for registration of the connector at the Core Service Provider B, i.e. it must be the path that when extended with /.well-known/dspace-version the resulting path represents the aforementioned version metadata resource.

The definition of the service reference reflects the section Discovery of Service Endpoints in the DSP spec.

2.7 Protocol Version Handling​

A Provider MUST provide the version metadata endpoint at the url https://subdomain.provider-domain.com/subpath/.well-known/dspace-version returning a response object as defined in the section on Exposure of version in the DSP spec. An example for the response object is:

{
  "protocolVersions": [
    {
      "version": "2025-1",
      "path": "/2025-1",
      "binding": "HTTPS"
    }
  ]
}

The reference point of the given relative path segments is the base path that hosts the version metadata endpoint, i.e., in the described case https://subdomain.provider-domain.com/subpath. For example, from the given information, the path to access the 2025-1 version of the catalog service is https://subdomain.provider-domain.com/subpath/2025-1/catalog.

A Consumer SHOULD evaluate the protocol versions supported by the targeted Provider and SHOULD limit the use of protocol versions to the latest offered by the Provider.

A Providers Participant Agent MUST be capable to identify by the called DSP apiAPI An API is a way for two or more computer programs to communicate with each other., which version the Consumer is using for the communication and MUST answer with the right response formats according to that version.

The definition of the version management reflects the section Exposure of versions in the DSP spec.

3 BACKWARD COMPATIBILITY​

Backward compatibility addresses interactions with Participant Agents following versions 4.1.x and 4.2.x of this standard. As no major changes have been applied, a Participant Agent following this version of the standard does not introduce any new features that prevent compatibility with a Participant Agent of those older versions.

4 REFERENCES​

4.1 NORMATIVE REFERENCES​

Dataspace Protocol​

The Dataspace Protocol is an external reference. A Participant Agent MUST implement the referenced version to comply to this standard version.

Decentralized Claims Protocol​

The Decentralized Claims Protocol is an external reference. A Participant Agent MUST implement the referenced version to comply to this standard version.

RFC 6749​

https://www.rfc-editor.org/rfc/rfc6749#section-6

Decentralized Identifiers (DID)​

CX-Specific Credentials​

DID Document​

Policy Constraints for Data Exchange​

CX Operating Model​

4.2 NON-NORMATIVE REFERENCES​

This section is non-normative

4.3 REFERENCE IMPLEMENTATIONS​

This section is non-normative

ANNEXES​

FIGURES​

Figure 1: Framework of data exchange

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