LogoLogo
How to Build Dataspaces?Main IDSA AssetsOther ResourcesManifesto for International Data Spaces
IDS-G
IDS-G
  • Changelog
  • Code of Conduct
  • Contributing to IDS-G-pre
  • LICENSE
  • International Data Spaces Global (IDS-G)
  • Overview
    • Message Structure/Format
    • Message Types
    • media
    • Communication Protocols
      • IDS REST
        • header
        • IDS Linked Data Notification (IDS-LDN)
          • IDS-REST requests
            • IDS-LDN, send a PUT request
      • IDS Communication Protocol Version 2 (IDSCP2)
        • IDSCP2 Application Layer
          • Examples
        • IDSCP2 Transport Layer
          • Examples
      • multipart
    • sequence-diagrams
      • Message Flows for Connector to Clearing House Communication
      • IDS Connector Communication
        • images
      • IDS Metadata Broker Communication
  • Components
    • IDS App Store (IDS-CH)
    • ClearingHouse
    • IDS Connector
    • IDS Identity Provider
      • Connector Identifiers (Connector IDs)
      • Certificate Authority (CA)
      • Dynamic Attribute Provisioning Service (DAPS)
        • requests
          • DAPS DAT request (root POST)
      • ParIS
        • ParIS requests
          • IDS-ParIS GET root request
    • IDS Meta Data Broker
      • General Overview
      • Introduction
      • Annex
        • HTTP API
        • Removed Requirements
      • Functions and Correlated Messages
        • Messages received by a Broker
        • Messages send by a Broker as Response
      • IDS Meta Data Broker Profiles
        • Advanced Information Profile
        • Usage Control Profile
      • IDS Meta Data Broker Requirements
        • Behavioral Requirements
        • Business Requirements
        • Conditional Requirements
        • Connector Requirements
        • Functional Requirements
        • Informational Requirements
        • Interface Requirements
        • Message Requirements
        • Role of an IDS Meta Data Broker
      • IDS-MDB requests
        • IDS-MDB GET root request
  • Glossary
    • IDS Shortcuts
  • Handbook to IDS-G
    • Specification
  • IDS Information Model
    • ids:Message
      • DescriptionRequestMessage POST
      • Message requests
  • Overview of the IDS Architecture
    • References
    • Relevant Documents
      • IDS Repositories
  • IDS Usage Control
    • IDS Usage Control Contract
      • Policies
      • images
    • IDS Policy Enforcement
      • System Adapter Technical Documentation
      • Concepts
        • Concepts for Data Sharing
    • Specification
      • Concepts
        • Access Control for the Contract Metadata
        • T7_ODRL_policies
        • Interfaces Standardization for Context Information (PIPs) and Actions to be Performed (PXPs)
        • Concepts for Participant-restricted policies and reselling data
  • .github
    • ISSUE_TEMPLATE
      • content-change-request
      • epic
      • feature-request
      • topic--code
      • topic--documentation
      • topic--quickfix
      • topic--structure
Powered by GitBook

Links:

  • IDSA Website
  • IDSA Github
  • Legal Notice
  • Privacy Policy

© 2016 – 2025 | All Rights Reserved | International Data Spaces Association

On this page
  • Message Flows for Connector to Connector Communication
  • Connector Self-description Request
  • Usage Contract Negotiation
  • Requesting Data
  • Example for Combining the Flows
  • Conformance Requirements for the Connector to Connector Communication
Edit on GitHub
  1. Overview
  2. sequence-diagrams

IDS Connector Communication

Last updated 1 year ago


Message Flows for Connector to Connector Communication

Connector Self-description Request

Data_Interaction_pre_v5_Split_Con_Desc

Usage Contract Negotiation

The message flow of the usage contract negotiation is described in following sequence diagram.

Requesting Data

Note, that even though the diagram shows the artifact request is located right after one description request, there can be more than one request for a resource's self-description before sending an artifact request. Also, there can be more than one artifact request executed as long as the artifact URI is known, and an applicable contract agreement exists.

Example for Combining the Flows

One way to combine the flows is to first use the Connector Self-description Request sequence to request the self-description of the Provider Connector. The Consumer can then browse the offers of the Provider. After that, based on the requirements, it defines a contract request and starts the Usage Contract Negotiation flow. If this is successful, the Consumer is allowed to request specific data via the Requesting Data Flow.

Conformance Requirements for the Connector to Connector Communication

Key
Value

ID

ta-001

Product

Connector

Strictness level

MUST

Prerequisites

The self-description of a specific Connector is needed.

Behaviour

Terms

-

Key
Value

ID

ta-002

Product

Connector

Strictness level

MUST

Prerequisites

Behaviour

Validation of the received message.

Terms

Validation in this case means to ensure:

  • The message is not empty.

  • The message has the expected syntax.

  • The message contains a valid DAT.

  • The message version is supported.

Key
Value

ID

ta-003

Product

Connector

Strictness level

MUST

Prerequisites

Behaviour

Terms

see ta-002

Key
Value

ID

ta-004

Product

Connector

Strictness level

MUST

Prerequisites

Behaviour

Terms

Key
Value

ID

ta-005

Product

Connector

Strictness level

MUST

Prerequisites

The metadata of a specific offered resource is needed. The resource URI is known.

Behaviour

Terms

-

Key
Value

ID

ta-006

Product

Connector

Strictness level

MUST

Prerequisites

Behaviour

Validation of the received message.

Terms

see ta-002

Key
Value

ID

ta-007

Product

Connector

Strictness level

MUST

Prerequisites

Behaviour

Terms

The requested resource is the one with the matching resource URI.

Key
Value

ID

ta-008

Product

Connector

Strictness level

MUST

Prerequisites

Behaviour

Terms

Key
Value

ID

ta-009

Product

Connector

Strictness level

MUST

Prerequisites

Behaviour

Validation of the received message.

Terms

Validation in this case means to ensure:

  • see ta-002

Key
Value

ID

ta-010

Product

Connector

Strictness level

MUST

Prerequisites

The data of a specific artifact offered by a specific Connector is needed. The artifact URI is known. An applicable contract agreement has been negotiated.

Behaviour

Terms

-

Key
Value

ID

ta-011

Product

Connector

Strictness level

MUST

Prerequisites

Behaviour

Validation of the received message.

Terms

see ta-002

Key
Value

ID

ta-012

Product

Connector

Strictness level

MUST

Prerequisites

Behaviour

Terms

The requested artifact is the one with the matching artifact ID.

Key
Value

ID

ta-013

Product

Connector

Strictness level

MUST

Prerequisites

Behaviour

Terms

Key
Value

ID

ta-014

Product

Connector

Strictness level

MUST

Prerequisites

Behaviour

Validation of the received message.

Terms

Validation in this case means to ensure:

  • see ta-002

Key
Value

ID

ta-015

Product

Connector

Strictness level

MUST

Prerequisites

A contract agreement needs to be negotiated with a specific Connector.

Behaviour

Terms

-

Key
Value

ID

ta-016

Product

Connector

Strictness level

MUST

Prerequisites

Behaviour

Validate received message and check if the contract can be agreed upon.

Terms

see ta-002

Key
Value

ID

ta-017

Product

Connector

Strictness level

MUST

Prerequisites

Behaviour

Terms

-

Key
Value

ID

ta-018

Product

Connector

Strictness level

MUST

Prerequisites

Behaviour

Terms

-

Key
Value

ID

ta-019

Product

Connector

Strictness level

MUST

Prerequisites

Behaviour

Validation of the received message.

Terms

see ta-002

Key
Value

ID

ta-020

Product

Connector

Strictness level

MUST

Prerequisites

Behaviour

Return an ids:ContractAgreementMessage containing an ids:ContractAgreement to the requesting Connector.

Terms

-

Key
Value

ID

ta-021

Product

Connector

Strictness level

MUST

Prerequisites

Behaviour

Terms

-

Key
Value

ID

ta-022

Product

Connector

Strictness level

MUST

Prerequisites

Behaviour

Terms

-

Key
Value

ID

ta-023

Product

Connector

Strictness level

MUST

Prerequisites

Behaviour

Validation of the received message.

Terms

Validation in this case means to ensure:

  • see ta-002

Key
Value

ID

ta-024

Product

Connector

Strictness level

MUST

Prerequisites

Behaviour

Check the contract agreement.

Terms

Checking the contract agreement means to:

  • Check if the assigner is the expected one.

  • Check if the rules of the contract agreement match the offered ones.

Key
Value

ID

ta-025

Product

Connector

Strictness level

MUST

Prerequisites

Behaviour

Terms

-

Key
Value

ID

ta-026

Product

Connector

Strictness level

MUST

Prerequisites

Behaviour

Terms

-

Key
Value

ID

ta-027

Product

Connector

Strictness level

MUST

Prerequisites

Behaviour

Terms

-

Key
Value

ID

ta-028

Product

Connector

Strictness level

MUST

Prerequisites

Behaviour

Validation of the received message.

Terms

see ta-002

Key
Value

ID

ta-029

Product

Connector

Strictness level

MAY

Prerequisites

Behaviour

Terms

-

Key
Value

ID

ta-030

Product

Connector

Strictness level

MUST

Prerequisites

Behaviour

Terms

-

Key
Value

ID

ta-031

Product

Connector

Strictness level

MAY

Prerequisites

Behaviour

Validation of the received message.

Terms

see ta-002

Key
Value

ID

ta-32

Product

Connector

Strictness level

MAY

Prerequisites

Behaviour

Communication concludes.

Terms

-

To get the self-description of the Provider Connector, an is sent without the property ids:RequestedElement. This indicates that the Consumer wants to request the self-description of the Provider Connector and not of a specific element. The Provider validates this request and, if the message processing is successful, returns an containing the Provider Connector's self-description. In case of any errors during the message processing, the Provider returns an with a ids:RejectionReason indicating the error's cause.

Contract_Negotiation

First, the Data Consumer sends an containing a suggested contract (an instance of ids:ContractRequest) to the Data Provider. This ids:ContractRequest can differ from the Provider's previous contract offer. The Data Provider then processes the request and responds with an appropriate response message. Processing means to first validate the request and then check if the contract request's content of the Data Consumer complies with the contract offer by the Provider.

The Provider can do a counteroffer in form of an containing an ids:ContractOffer. Then, the Consumer Connector may respond with a counteroffer in form of an ids:ContractMessage as well. This can go back and forth an arbitrary number of times until one of the parties either rejects or accepts the contract, or an error occurs. In case of a rejection or an error, an that contains the rejection's reason is sent to the other party. If the contract is accepted, an including the ids:ContractAgreement is returned.

In this description, it is assumed that the Provider Connector is the one that ultimately gives in and sends the . If it was the other way around, the sequence after the optional block onwards would also be defined the other way around.

As soon as the Consumer receives the , it processes the agreement. While processing, the consumer checks whether the received agreement contains the correct assigner and whether it fits the suggested rules that where sent within the ids:ContractRequest or ids:ContractOffer. If the agreement is not valid, an error occurs, or if the Consumer rejects the agreement, an is returned.

Furthermore, the Consumer has the option to restart the negotiation process sending an with a modified ids:ContractOffer at any time. As marked as (1) in the sequence diagram, this would cause the process to jump to the offer exchange part again. If instead, the agreement is accepted, and the processing is successful, the Consumer returns an including the ids:ContractAgreement to the Provider to confirm the validity. If the Provider receives this , it finalizes the exchange from its side and marks the agreement as confirmed. Optionally, the contract agreement is sent to the Clearing House within an ids:LogMessage. If an error occurs during processing, the Consumer is informed via an . On success, the communication concludes with the Provider sending an to the Consumer, this is optional. The Consumer concludes with saving the agreement and setting the confirmed status to true.

Data_Interaction_pre_v5_Split_Res_Art_Desc

Based on the self-description of the Provider Connector and a negotiated contract, the Consumer Connector is able to request data. For this, the Consumer Connector sends an with the URI of the selected resource as the ids:RequestedElement to the Provider Connector. The Provider Connector first validates the message and then returns the metadata of the requested resource to the Consumer via an . In case of unsuccessful processing, the Provider returns an instead.

The Consumer Connector expects an as the response containing the metadata of the requested resource (an instance of ids:Resource). The Consumer validates the message and then stores the resource. In case of any occurring error, the communication is suspended. If not, the Consumer Connector is then able to choose a specific artifact that should be consumed.

In the third step, the Consumer Connector sends an including a set ids:RequestedArtifact and a reference to the applicable contract agreement as the ids:TransferContract to the Provider Connector. The Provider validates the message and the transfer contract. If an error occurs during processing, the Provider responds with an to the Consumer. If the message is valid, the Provider returns an containing the data. The Consumer Connector expects this and stores or further processes the attached data.

Send an to this specific Connector. The property ids:RequestedElement is not set.

Connector receives an without the property ids:RequestedElement.

Connector receives an without the property ids:RequestedElement. This message is successfully validated.

Get the self-description of type ids:InfrastructureComponent of the receiving Connector and return it within an to the requesting Connector.

Connector receives an without the property ids:RequestedElement set. This message is not successfully validated, or an error occurs during processing.

Return an containing the appropriate ids:RejectionReason.

Be able to send an to the offering Connector. The property ids:RequestedElement is filled with the specific resource URI.

Connector receives an with a resource URI as ids:RequestedElement.

Connector receives an with a resource URI as ids:RequestedElement. This message is successfully validated.

Get the metadata of the requested resource that is provided by the receiving Connector and send it within an to the requesting Connector.

Connector receives an with a resource URI as ids:RequestedElement. This message is not successfully validated, or an error occurs during processing.

Return an containing the appropriate ids:RejectionReason.

Connector receives an as a response to an .

The response message is of type

Be able to send an to this specific Connector. The property ids:RequestedArtifact is filled in with the specific artifact URI. The property ids:TransferContract is filled with a reference to the applicable contract agreement.

Connector receives an with an artifact URI as ids:RequestedArtifact. The property ids:TransferContract is filled with a reference to the applicable contract agreement.

Connector receives an with an artifact URI as ids:RequestedArtifact. The property ids:TransferContract is filled with a reference to the applicable contract agreement. Validation of the message is successful.

Get the data from the requested artifact and send it within an to the requesting entity.

Connector receives an with an artifact URI as ids:RequestedArtifact. The property ids:TransferContract is filled with a reference to the applicable contract agreement. Validation of the message is not successful, or an error occurs during processing.

Return an containing the appropriate ids:RejectionReason.

Connector receives an containing the requested data as the response to an .

That the response message is of type .

Be able to send an containing an ids:ContractRequest to this specific Connector.

Connector receives an containing an ids:ContractRequest.

Connector receives an containing an ids:ContractRequest. The validation of the message and the contract request is successful.

Return an containing an ids:ContractAgreement to the requesting Connector.

Connector receives an containing an ids:ContractRequest. The validation of the message and/or the contract request is not successful, and/or an error occurs during processing.

Return an containing the appropriate ids:RejectionReason.

Connector receives an containing an ids:ContractOffer.

Connector receives an containing an ids:ContractOffer. The validation of the message and the contract offer is successful.

Connector receives an containing an ids:ContractOffer. The validation of the message and/or contract offer is not successful, and/or an error occurs during processing.

Return an containing the appropriate ids:RejectionReason.

Connector receives an containing an ids:ContractOffer. The validation is successful. The contract should not be rejected, but a counter offer should be sent.

Return an containing an ids:ContractOffer to the requesting Connector.

Connector that has sent an or an receives an containing an ids:ContractAgreement as a response.

That the response message is of type .

Connector that has sent an or an receives an containing an ids:ContractAgreement as a response.

Connector that has sent an or an receives an containing an ids:ContractAgreement as a response. The validation is successful, and the checks result in accepting the contract agreement.

Return an containing the ids:ContractAgreement to the other Connector to confirm the contract agreement.

Connector that has sent an or an receives an containing an ids:ContractAgreement as a response. The validation is not successful, an error occurs, or the contract agreement should be rejected.

Return an containing the appropriate ids:RejectionReason.

Connector that has sent an or an receives an containing an ids:ContractAgreement as a response. The validation is successful. Some modifications to the contract are pending.

Return an containing an ids:ContractOffer to the other Connector.

Connector receives an containing an ids:ContractAgreement. The Connector has not sent an or an before.

Connector receives an containing an ids:ContractAgreement. The Connector has not sent an or an before. The validation of the message is successful.

Send an with the filled ids:CorrelationMessage to the Consumer Connector.

Connector receives an containing an ids:ContractAgreement. The Connector has not sent an or an before. The validation of the message is not successful, or an error occurs during processing.

Return an .

Connector that has sent an containing the ids:ContractAgreement to the other party to confirm the contact agreement receives an as a response.

Connector that has sent an containing the ids:ContractAgreement to the other party to confirm the contract agreement receives an as a response. The validation is successful.

ids:RejectionReason
ids:RejectionReason
ids:RejectionReason
ids:DescriptionRequestMessage
ids:DescriptionResponseMessage
ids:RejectionMessage
ids:ContractRequestMessage
ids:ContractOfferMessage
ids:ContractRejectionMessage
ids:ContractAgreementMessage
ids:ContractAgreementMessage
ids:ContractAgreementMessage
ids:ContractRejectionMessage
ids:ContractOfferMessage
ids:ContractAgreementMessage
ids:ContractAgreementMessage
ids:ContractRejectionMessage
ids:MessageProcessedNotificationMessage
ids:DescriptionRequestMessage
ids:DescriptionResponseMessage
ids:RejectionMessage
ids:DescriptionResponseMessage
ids:ArtifactRequestMessage
ids:RejectionMessage
ids:ArtifactResponseMessage
ids:ArtifactResponseMessage
ids:DescriptionRequestMessage
ids:DescriptionRequestMessage
ids:DescriptionRequestMessage
ids:DescriptionResponseMessage
ids:DescriptionRequestMessage
ids:RejectionMessage
ids:DescriptionRequestMessage
ids:DescriptionRequestMessage
ids:DescriptionRequestMessage
ids:DescriptionResponseMessage
ids:DescriptionRequestMessage
ids:RejectionMessage
ids:DescriptionResponseMessage
ids:DescriptionRequestMessage
ids:DescriptionResponseMessage
ids:ArtifactRequestMessage
ids:ArtifactRequestMessage
ids:ArtifactRequestMessage
ids:ArtifactResponseMessage
ids:ArtifactRequestMessage
ids:RejectionMessage
ids:ArtifactResponseMessage
ids:ArtifactRequestMessage
ids:ArtifactResponseMessage
ids:ContractRequestMessage
ids:ContractRequestMessage
ids:ContractRequestMessage
ids:ContractAgreementMessage
ids:ContractRequestMessage
ids:ContractRejectionMessage
ids:ContractOfferMessage
ids:ContractOfferMessage
ids:ContractOfferMessage
ids:ContractRejectionMessage
ids:ContractOfferMessage
ids:ContractOfferMessage
ids:ContractRequestMessage
ids:ContractOfferMessage
ids:ContractAgreementMessage
ids:ContractAgreementMessage
ids:ContractRequestMessage
ids:ContractOfferMessage
ids:ContractAgreementMessage
ids:ContractRequestMessage
ids:ContractOfferMessage
ids:ContractAgreementMessage
ids:ContractAgreementMessage
ids:ContractRequestMessage
ids:ContractOfferMessage
ids:ContractAgreementMessage
ids:ContractRejectionMessage
ids:ContractRequestMessage
ids:ContractOfferMessage
ids:ContractAgreementMessage
ids:ContractOfferMessage
ids:ContractAgreementMessage
ids:ContractRequestMessage
ids:ContractOfferMessage
ids:ContractAgreementMessage
ids:ContractRequestMessage
ids:ContractOfferMessage
ids:MessageProcessedNotificationMessage
ids:ContractAgreementMessage
ids:ContractRequestMessage
ids:ContractOfferMessage
ids:ContractRejectionMessage
ids:ContractAgreementMessage
ids:MessageProcessedNotificationMessage
ids:ContractAgreementMessage
ids:MessageProcessedNotificationMessage