LogoLogo
How to Build Dataspaces?Main IDSA AssetsOther ResourcesManifesto for International Data Spaces
Dataspace Protocol
Dataspace Protocol
  • Overview
    • Dataspace Protocol 2024-1
    • Terminology
    • Information Model
  • Common Functionalities
    • Specification
    • Binding: HTTPS
  • Catalog
    • Specification
    • Binding: HTTPS
  • Contract Negotiation
    • Specification
    • Binding: HTTPS
  • Transfer Process
    • Specification
    • Binding: HTTPS
  • List of Files
    • Common
    • Figures
    • Messages
    • Schemes
    • Shapes
  • Best Practices
    • Introduction
    • Related Documents
Powered by GitBook

Links:

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

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

On this page
  • 1 Introduction
  • 1.1 States
  • 1.2 State Machine
  • 2 Message Types
  • 2.1 Contract Request Message
  • 2.2 Contract Offer Message
  • 2.3 Contract Agreement Message
  • 2.4 Contract Agreement Verification Message
  • 2.5 Contract Negotiation Event Message
  • 2.6 Contract Negotiation Termination Message
  • 3 Response Types
  • 3.1 ACK - Contract Negotiation
  • 3.2 ERROR - Contract Negotiation Error
Edit on GitHub
  1. Contract Negotiation

Specification

Last updated 1 year ago

This document outlines the key elements of the . The used terms are described .

1 Introduction

1.1 States

The CN states are:

1.2 State Machine

The CN state machine is represented in the following diagram:

2 Message Types

The CN state machine is transitioned upon receipt and acknowledgement of a message. This section details those messages as abstract message types.

2.1 Contract Request Message

Sent by

Resulting state

REQUESTED, TERMINATED

Response

Schema

Example

Diagram(s)

2.2 Contract Offer Message

Sent by

Resulting state

OFFERED, TERMINATED

Response

Schema

Example

Diagram(s)

Initial message (note the missing consumerPid)

2.3 Contract Agreement Message

Sent by

Resulting state

AGREED, TERMINATED

Response

Schema

Example

Diagram(s)

  • The message must contain a consumerPid and a providerPid.

2.4 Contract Agreement Verification Message

Sent by

Resulting state

VERIFIED, TERMINATED

Response

Schema

Example

Diagram(s)

  • The message must contain a consumerPid and a providerPid.

2.5 Contract Negotiation Event Message

Sent by

Resulting state

FINALIZED, ACCEPTED, TERMINATED

Response

Schema

Example

Diagram(s)

  • Other event types may be defined in the future.

  • The message must contain a consumerPid and a providerPid.

2.6 Contract Negotiation Termination Message

Sent by

Resulting state

TERMINATED

Response

Schema

Example

Diagram(s)

  • The message must contain a consumerPid and a providerPid.

  • If an error is received in response to the message, the sending party may choose to ignore the error.

3 Response Types

The ACK and ERROR response types are mapped onto a protocol such as HTTPS. A description of an error might be provided in protocol-dependent forms, e.g., for an HTTPS binding in the request or response body.

3.1 ACK - Contract Negotiation

Sent by

Schema

Example

Diagram(s)

3.2 ERROR - Contract Negotiation Error

Sent by

Schema

Example

Diagram(s)

Field
Type
Description

consumerPid

UUID

providerPid

UUID

code

String

An optional implementation-specific error code.

reason

Array[object]

An optional array of implementation-specific error objects.

A (CN) involves two parties, a that offers one or more under a usage contract and that requests . A CN is uniquely identified through an . Each CN requires a newly generated IRI, which may not be used in a CN after a terminal state has been reached. A CN progresses through a series of states, which are tracked by the and using messages. A CN transitions to a state in response to an acknowledged message from the counter-party. Both parties have the same state of the CN. In case the states differ, the CN is terminated and a new CN has to be initiated.

REQUESTED: A contract for a has been requested by the based on an and the has sent an ACK response.

OFFERED: The has sent an to the and the has sent an ACK response.

ACCEPTED: The has accepted the latest and the has sent an ACK response.

AGREED: The has accepted the latest , sent an to the , and the has sent an ACK response.

VERIFIED: The has sent an verification to the and the has sent an ACK response.

FINALIZED: The has sent a finalization message including his own verification to the and the has sent an ACK response. Data is now available to the .

TERMINATED: The or has placed the CN in a terminated state. A termination message has been sent by either of the and the other has sent an ACK response. This is a terminal state.

Transitions marked with C indicate a message sent by the , transitions marked with P indicate a message. Terminal states are final; the state machine may not transition to another state. A new CN may be initiated if, for instance, the CN entered the TERMINATED state due to a network issue.

Concrete wire formats are defined by the protocol binding, e.g., ..

All types (, ) must contain an unique identifier in the form of a URI. GUIDs can also be used in the form of URNs, for instance following the pattern .

An must have a target property containing the id.

or

,

Initiating ,

The Contract Request Message is sent by a to initiate a CN or to respond to a sent by a .

The must include an offer property, which itself must have a @id property. If the message includes a providerPid property, the request will be associated with an existing CN and a will be created using either the offer or offer.@id properties. If the message does not include a providerPid, a new CN will be created on side using either the offer or offer.@id properties and the selects an appropriate providerPid.

An offer.@id will generally refer to an contained in a . If the is not aware of the offer.@id value, it must respond with an error message.

The callbackAddress is a URL indicating where messages to the should be sent in asynchronous settings. If the address is not understood, the MUST return an UNRECOVERABLE error.

Different to a or , the inside a must have an odrl:target attribute. However, it's contained Rules must not have any odrl:target attributes to prevent inconsistencies with the .

or

,

,

Message following a :

The Contract Offer Message is sent by a to initiate a CN or to respond to a sent by a .

If the message includes a consumerPid property, the request will be associated with an existing CN. If the message does not include a consumerPid, a new CN will be created on side and the selects an appropriate consumerPid.

The id is not required but can be included when the initiates a CN.

Different to a (see ), the Offer inside a ContractOfferMessage must have an odrl:target attribute. However, it's contained Rules must not have any odrl:target attributes to prevent inconsistencies with the .

or

,

The Contract Agreement Message is sent by a when it agrees to a contract. It contains the complete .

The message must contain an .

An must contain a timestamp property defined as an type.

An must contain an assigner and assignee. The contents of these properties are a dataspace-specific unique identifier of the parties. Note that these identifiers are not necessarily the same as the identifiers of the negotiating the contract (e.g., ).

An must contain a odrl:target property. None of its Rules, however, must have any odrl:target attributes to prevent inconsistencies with the .

or

,

The Contract Agreement Verification Message is sent by a to verify the acceptance of an .

A responds with an error if the contract cannot be validated or is incorrect.

,

or

,

When the Contract Negotiation Event Message is sent by a with an eventType property set to FINALIZED, an has been finalized and the associated is accessible. The state machine is transitioned to the FINALIZED state.

A responds with an error if the contract cannot be validated or is incorrect.

When the message is sent by a with an eventType set to ACCEPTED, the state machine is placed in the ACCEPTED state.

It is an error for a to send the message with an event type FINALIZED to the .

It is an error for a to send the message with an event type ACCEPTED to the .

Note that CN events are not intended for propagation of an state after a CN has entered a terminal state. It is considered an error for a or to send an event after the CN state machine has entered a terminal state.

,

or

,

The Contract Negotiation Termination Message is sent by a or indicating it has cancelled the CN sequence. The message can be sent at any state of a CN without providing an explanation. Nevertheless, the sender may provide a description to help the receiver.

Note that a CN may be terminated for a variety of reasons, for example, an unrecoverable error was encountered or one of the parties no longer wishes to continue. A operator may remove terminated CN resources after it has reached the terminated state.

,

,

The Contract Negotiation is an object returned by a or indicating a successful state change happened.

,

,

The Contract Negotiation Error is an object returned by a or indicating an error has occurred. It does not cause a state transition.

The CN unique id on side.

The CN unique id on side.

Contract Negotiation HTTPS Binding
ODRL Agreement
TTL Shape
JSON Schema
Message
Message
TTL Shape
JSON Schema
Example Initial Message
Example Message
TTL Shape
JSON Schema
Message
TTL Shape
JSON Schema
Message
TTL Shape
JSON Schema
Message
TTL Shape
JSON Schema
Message
TTL Shape
JSON Schema
Process
TTL Shape
JSON Schema
Error
ACK
ERROR
ACK
ERROR
Contract Request Message
ACK
ERROR
ACK
ERROR
ACK
ERROR
ACK
ERROR
here
Contract Negotiation Protocol
1 Introduction
1.1 States
1.2 State Machine
2 Message Types
2.1 Contract Request Message
2.2 Contract Offer Message
2.3 Contract Agreement Message
2.4 Contract Agreement Verification Message
2.5 Contract Negotiation Event Message
2.6 Contract Negotiation Termination Message
3 Response Types
3.1 ACK - Contract Negotiation
3.2 ERROR - Contract Negotiation Error
IRI
urn:uuid:{GUID}
ODRL Agreement
ODRL inferencing rules for compact policies
Contract Request Message
ODRL inferencing rules for compact policies
XSD DateTime
ODRL inferencing rules for compact policies
Contract Offer Message
Contract Request Message
Contract Negotiation Protocol
Contract Negotiation
Provider
Datasets
Consumer
Datasets
Provider
Consumer
Dataset
Consumer
Offer
Provider
Provider
Offer
Consumer
Consumer
Consumer
Offer
Provider
Provider
Offer
Agreement
Consumer
Consumer
Consumer
Agreement
Provider
Provider
Provider
Agreement
Consumer
Consumer
Consumer
Provider
Consumer
Participants
Consumer
Provider
Policy
Offer
Agreement
Dataset
Consumer
Provider
Consumer
Consumer
Offer
Provider
Provider
Offer
Catalog
Provider
Consumer
Provider
Catalog
Dataset
Offer
Provider
Consumer
Consumer
Consumer
Dataset
Provider
Provider
Agreement
Agreement
Agreement
Agreement
Participant Agents
Connectors
Agreement
Consumer
Agreement
Provider
Provider
Agreement
Dataset
Consumer
Consumer
Consumer
Provider
Provider
Consumer
Agreement
Consumer
Provider
Consumer
Provider
Connector's
Consumer
Provider
Consumer
Provider
Consumer
Provider
Provider
Consumer
Consumer
Provider
Consumer
Provider
Consumer
Provider
Consumer
Provider
Consumer
Provider
Dataset
DCAT Vocabulry Mapping