Skip to main content
Release: CX-Io (preview)

CX-0018 Dataspace Connectivity v.3.2.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.

COMPARISON WITH THE PREVIOUS VERSION OF THE STANDARD​

  • Rename IATP to DCP
  • Improve the reference of external standards to clearly express the valid versions
  • Add quality checks of the previous Data Sovereignity quality gate checks as appropriate for this standard

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:

  • Core Service Provider (A/B)
  • 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,
  • which conventions apply with regard to policy constraints,
  • 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

Note: At time of the release, the Identity Wallet solution is not decentralized yet. However, this standard already provides most of the infrastructure to operate Wallets (DCP-Credential-Services) in a distributed manner. More information about the SSI-infrastructure can be found in the relevant standards.

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 (IDSA)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(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 Applications(Catena-X) Applications that enable functionality of different use cases, hosted by a data provider or consumer itself or 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
Business Partner Number (BPN)Every participant in the Catena-X network has a unique, unchangeable identifier, called business partner number (BPN). The legal entity of an organization is represented by the Business Partner Number Legal Entity (BPNL)CX - 0010 Business Partner Number
Data Catalog Vocabulary (DCAT)RDF vocabulary designed to facilitate interoperability between data catalogs published on the Webhttps://www.w3.org/TR/vocab-dcat-3
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 Connector, 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 the following prefixes as abbreviations for namespaces

  • "dct": "http://purl.org/dc/terms/"
  • "dspace": "https://w3id.org/dspace/2024/1/"
  • "odrl": "https://www.w3.org/ns/odrl/2/"
  • "dcat": "http://www.w3.org/ns/dcat#"

2.1 Communication between Dataspace Participants​

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

Participant Agents MUST facilitate data exchange according to the HTTPS 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 HTTPS binding of the Dataspace Protocol 2024-01.

2.1.1 Usage of BPNL in the data exchange​

A Participant Agent that provides data MUST use the BPNL of the respective Participant in any DSP request/response messages.

A Participant Agent that consumes data MUST use the BPNL of the respective Participant in any DSP request/response messages.

2.2 Transfer Type Profiles​

In their dcat:Catalog response to a dspace:CatalogRequestMessage, for each Dataset, a Provider MUST return a dcat:Distribution signifying what Transfer Profile a Consumer can use to obtain data.

Providers MUST be able to serve data according to that signal when data transfer is requested by a consumer via a dspace:TransferRequestMessage.

Despite the IRIs dspace:HttpData-PULL and dspace:AmazonS3-PUSH are not yet included in the DSP-context, they will be used as preliminary identifiers.

Providers MAY offer any of the following Transfer Type Profiles:

2.2.1 HttpData-PULL​

A Consumer MUST send a dspace:TransferRequestMessage with dct:format:dspace:HttpData-PULL and an empty dspace:dataAddress property.

A Provider MUST send a dspace:TransferStartMessage with sufficient information in the dspace:dataAddress property so that a request to the dspace:endpoint may succeed when decorated with HTTP-headers constructed from the dspace:endpointProperties' with dspace:name as key and dspace:value as value respectively.

A Provider Connector MUST ensure that the requested backend system has sufficient context from the negotiation to evaluate the legitimacy of the request.

A Consumer may then use the provided data to execute requests against the endpoint.

Despite the token, the endpoint still has the right to refuse serving a request. This may occur for instance when a consumer attempts to PUT against a resource but is only allowed to GET.

2.2.2 AmazonS3-PUSH​

A Consumer MUST send a dspace:TransferRequestMessage with dct:format:dspace:AmazonS3-PUSH and a dspace:dataAddress property so that triggering a transfer to the dspace:endpoint decorated with the data relevant dspace:endpointProperties may succeed.

A Provider MUST send a dspace:TransferStartMessage and an empty dspace:dataAddress property. He 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 relevant Catena-X standards. These VCs are stored in a Credential Service.

A Consumer MUST be able to retrieve an access token according to the Verifiable Presentation Protocol (VPP) that is part of the Decentralized Claims Protocol (DCP). This corresponds to Request 1 in the presentation flow where this Consumer acts as Client.

A Provider MUST be able to receive and securely verify an access token and derive information on a Consumer's Credential Service in order to execute the DCP VPP Request 4. This corresponds to the role of Verifier.

2.4 Conventions for Policy Constraints​

odrl:Offer objects contained in a dcat:Catalog SHOULD carry odrl:Constraints that are specified in the CX-ODRL-Profile. Subsequent standards are encouraged to specify further restrictions of said profile, especially on the odrl:rightOperands. The following list compiles a set of well-defined policies that Data Providers and Data Consumers SHOULD include in their offers and guidance on how to check them. Application Providers MUST support all constraints of the following table.

NameleftOperand (expanded IRI)operator
(compacted IRI)		valid rightOperands (literal)validation mechanism
MembershipConstrainthttps://w3id.org/catenax/policy/Membershipodrl:eqactiveMembership Credential (CX - 0149)
UseCaseConstraintshttps://w3id.org/catenax/policy/FrameworkAgreementodrl:eq[usecasename]:[version]UseCaseFrameworkAgreementCredential (CX - 0050)
The exact mapping logic is specified in the section Framework Agreement to Verifiable Credential Mapping
ContractReferenceConstrainthttps://w3id.org/catenax/policy/ContractReferenceodrl:eq[string]:[version]The value comparison necessary for validation SHOULD be based on CX-ODRL-Profile
UsagePurposeConstrainthttps://w3id.org/catenax/policy/UsagePurposeodrl:eq[string]:[version]The value comparison used necessary for validation SHOULD be based on CX-ODRL-Profile

Note: The list is available in machine-readable form with links to the respective legal documents in the CX-ODRL-Profile.

Each Data Offer visible in a Provider's dcat:Catalog MUST include at least an odrl:Constraint according to the definition of UseCaseContraint as defined above.

Providers SHOULD chain constraints (if necessary) via odrl:and. Examples can be found in CX-ODRL-Profile.

Providers MUST perform access control checks based on CX credentials on their data offers as a dcat:Catalog object may expose information restricted by governance and regulation.

Framework Agreement to Verifiable Credential Mapping​

The mapping between the rightOperands of a cx-policy:FrameworkAgreement to its referring Verifiable Credential (described in CX-0050) is done via the credential type and its version.

  • The given rightOperand needs to be separated by the first “:” to separate the version term. Only one separator is allowed.

  • Thereafter, the term “Credential” needs to be appended to identify the relevant credential via its credential type.

  • The version maps the “contractVersion” property inside the relevant credential.

Example (rightOperand to Credential):

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

Note: Versions are to be handled as strings / literals and do not require any semantic comparison.

Catena-X ODRL Profile​

To clearly identify the relevant Catena-X ODRL Profile, every policy (and their subclasses) MUST use the ODRL ‘profile’ property with an IRI referring to the Catena-X ODRL Profile as defined in ODRL policy The current version is: https://w3id.org/catenax/policy/profile2405 or in compact form: cx-policy:profile2405.

2.5 Conventions for Datasets​

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

  • dct:type holding an object with at least a @id property pointing to a concept describing what type of API this Dataset represents. 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.
  • cx-common:version holding a SemVer-conformant string indicating the API version of the API that was typed by the dct:type property. Subsequent standards define the exact value this property shall hold, depending on the Business scenario.

3 REFERENCES​

3.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.

Note: In the current version of specification, the protocol is still referenced under its previous name Identity and Trust Protocol (IATP).

Business Partner Number​

Framework Agreement Credential​

Verified Company Identity​

ODRL Profile​

CX Operating Model​

3.2 NON-NORMATIVE REFERENCES​

This section is non-normative

3.3 REFERENCE IMPLEMENTATIONS​

This section is non-normative

ANNEXES​

FIGURES​

Figure 1: Framework of data exchange