LogoLogo
How to Build Dataspaces?Main IDSA AssetsOther ResourcesManifesto for International Data Spaces
IDS-RAM 4
IDS-RAM 4
  • README
  • Front Matter
    • Front Matter
    • Contributing Projects
  • Introduction
    • 1. Introduction
      • 1.1 Goals of the International Data Spaces
      • 1.2 Purpose and Structure of the Reference Architecture
      • 1.3 Relation to other IDSA assets
  • Context of the International Data Spaces
    • 2. Context of the International Data Spaces
      • 2.1 Data-Driven Business Ecosystems
      • 2.2 Data Sovereignty as a Key Capability
      • 2.3 Data as an Economic Good
      • 2.4 Data Exchange and Data Sharing
      • 2.5 Meaningful data
      • 2.6 Industrial Cloud Platforms
      • 2.7 Big Data and Artificial Intelligence
      • 2.8 The Internet of Things and the Industrial Internet of Things
      • 2.9 Blockchain
      • 2.10 Federated frameworks for data sharing agreements and terms of use
      • 2.11 General Data Protection Regulation
      • 2.12 Contribution of the International Data Spaces to Industry 4.0 and the Data Economy
      • 2.13 Privacy in the connected world
  • Layers of the Reference Architecture Model
    • 3 Layers of the Reference Architecture Model
      • 3.1 Business Layer
        • 3.1.1 Roles in the International Data Spaces
        • 3.1.2 Interaction of Roles
        • 3.1.3 Digital Identities
        • 3.1.4 Usage Contracts
      • 3.2 Functional Layer
      • 3.3 Information Layer
      • 3.4 Process Layer
        • 3.4.1 Onboarding
        • 3.4.2 Data Offering
        • 3.4.3 Contract Negotiation
        • 3.4.4 Exchanging Data
        • 3.4.5 Publishing and using Data Apps
        • 3.4.6 Policy Enforcement
      • 3.5 System Layer
        • 3.5.1 Identity Provider
        • 3.5.2 IDS Connector
        • 3.5.3 App Store and App Ecosystem
        • 3.5.4 Metadata Broker
        • 3.5.5 Clearing House
        • 3.5.6 Vocabulary Hub
  • Perspectives of the Reference Architecture Model
    • 4 Perspectives of the Reference Architecture Model
      • 4.1 Security Perspective
        • 4.1.1 Security Aspects addressed by the different Layers
        • 4.1.2 Identity and Trust Management
        • 4.1.3 Securing the Platform
        • 4.1.4 Securing Applications
        • 4.1.5 Securing Interactions between IDS components
        • 4.1.6 Usage Control
      • 4.2 Certification Perspective
        • 4.2.1 Certification Aspects Addressed by the Different Layers of the IDS-RAM
        • 4.2.2 Roles
        • 4.2.3 Operational Environment Certification
        • 4.2.4 Component Certification
        • 4.2.5 Processes
      • 4.3 Data Governance Perspective
        • 4.3.1 Governance Aspects Addressed by the Different Layers of the IDS-RAM
        • 4.3.2 Data Governance Model
        • 4.3.3 Data as an Economic Good
        • 4.3.4 Data Ownership
        • 4.3.5 Data Sovereignty
        • 4.3.6 Data Quality
        • 4.3.7 Data Provenance
        • 4.3.8 Data Space Instances
        • 4.3.9 IDS Rulebook
        • 4.3.10 Privacy Perspective
        • 4.3.11 Governance for Vocabularies
Powered by GitBook
On this page
  • Basic Flow
  • Figure 3.4.3.1: Simple Contract Negotiation
  • Clearing House
  • Figure 3.4.3.2: Contract Agreement with Clearing House Involvement
  • Reversed Sequence
  • Figure 3.4.3.3: Contract Negotiation - Initiation by Data Provider
  • Counter Offers
  • Figure 3.4.3.4: Contract Negotiation - Counter Offers
Edit on GitHub
  1. Layers of the Reference Architecture Model
  2. 3 Layers of the Reference Architecture Model
  3. 3.4 Process Layer

3.4.3 Contract Negotiation

Last updated 2 years ago

Links:

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

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

While a Connector Self-Description basically contains descriptive information about available data assets, these also include Usage Control information in form of a Contract Offer. A Contract Offer describes under what conditions the Data Provider is willing to make its data available to the Data Consumer. This can range from simple access restrictions to complex pre- and post-duties. See more details in Section .

In a (semi-)automated negotiation process performed by the Usage Control frameworks of the participating IDS Connectors, the Data Consumer and the Data Provider need to agree on a Data Usage Contract, respectively Contract Agreement. The following sequence diagrams visualize this process in more detail.

Basic Flow

Figure 3.4.3.1 shows the most simple version of the sequence that is at least necessary to reach a Contract Agreement. In advance, the Data Provider has attached a Contract Offer to a data offer. As described in Section , this is returned to the Data Consumer as part of the IDS Connector's Self-Description. However, the Data Consumer can submit a Contract Request at any time, even if no Contract Offer exists yet.

Please note, as this is a technology-independent message flow, appropriate responses were not considered. The illustrated processes can run synchronously as well as asynchronously, and can be cancelled at any time.

Figure 3.4.3.1: Simple Contract Negotiation

In Figure 3.4.3.1, the negotiation sequence is initiated by the Data Consumer's IDS Connector sending a Contract Request to the Data Provider. The content of this Contract Request can differ from the Contract Offer, or it can adopt it as it is. The meta-information in the contract is modified accordingly (e.g., the date, the term, or the signature). As soon as the Data Provider's IDS Connector receives the Contract Request, its validity is checked by means of syntax, content, and signature. As Figure 3.4.3.1 concentrates on the simple flow, it covers no counter Contract Offers. Thus, the Contract Request is either rejected or accepted.

In the case of a Contract Agreement, this is also signed by the Data Provider's IDS Connector and, for confirmation, the Data Consumer is informed about the Contract Agreement. Again, content and signature are validated. If this fails, the Data Consumer simply does not invoke any subsequent Data Operations referring to this Contract Agreement (see Section 3.4.4).

As soon as a Contract Agreement has been reached, this is instantiated and deployed inside both IDS Connectors. This means it needs to be persisted on both sides. This way, both IDS Connectors have all necessary information for later Policy Enforcement.

If, at any time during the sequence, a participant does not agree with the shared content, the Contract can be rejected. In the case of a Contract Rejection, the sequence is aborted. Connected systems or users are notified and previously saved Contract Agreements are revoked. A negotiation sequence is never reactivated, but a new one can be started at any time.

Clearing House

In addition, for separate trust or for regulation in some data spaces, the approval of a Contract Request or Offer may be extended by involving the Clearing House. After a successful Contract Request validation, the Data Provider signed and stored the Contract Agreement locally. Next, this is additionally sent to the Clearing House (as shown in Figure 3.4.3.2).

After receiving the Contract Agreement from the Data Provider, the Clearing House first checks the signature of both involved Connectors and then signs the Contract Agreement itself. The Provider Connector returns the triple signed Contract Agreement to the Data Consumer, that can finally check all signatures to be sure that the Contract Agreement contains the requested content.

Figure 3.4.3.2: Contract Agreement with Clearing House Involvement

Reversed Sequence

Figure 3.4.3.3 depicts the simple negotiation flow of Figure 3.4.3.1. In this case, however, the sequence is reversed and the Data Provider initiates the negotiation. Nevertheless, it should be noted that, since the Data Provider is the one who makes the data offer, it is always the one who signs the Contract Agreement last, and sends it to the Clearing House if this is involved (as described in the previous subsection).

Figure 3.4.3.3: Contract Negotiation - Initiation by Data Provider

Counter Offers

Figure 3.4.3.4 illustrates a more complex negotiation flow that covers counter Contract Offers and external input. As soon as the Data Provider's IDS Connector receives a valid Contract Request, it may notify interested users or systems and provide an interface for input. Thus, the IDS Connector, if it does not already do so by default, can be extended by the functionality to automatically negotiate contracts within a certain range (e.g., using an AI service). Alternatively, a service or a user can interact and directly affect the negotiation by rejecting or agreeing to the received Contracts as well as proposing counter Contract Offers or Requests. Further steps take place as already described above: Incoming Contracts are validated and as soon as a Contract Agreement has been reached, it is persisted and enforced by both IDS Connectors. How this Policy Enforcement will be ensured is explained in Section 3.4.6.

Figure 3.4.3.4: Contract Negotiation - Counter Offers

3.4.4.2
Simple Contract Negotiation
Clearing House Involvement
Contract Negotiation: Initiation by Data Provider
Contract Negotiation: Counter Offers
3.3