The Dataspace Protocol (DSP) is a specification for interoperable data sharing between organizations under usage control, built on Web technologies. It defines the schemas and protocols for participants to publish data in catalogs, negotiate contract agreements over an offer’s usage policy, and run the transfer that gives access to the data — the federation of systems it serves is called a dataspace. Developed by the International Data Spaces Association through 2024-1 and by the Eclipse Dataspace Working Group since; the stable release is 2025-1, latest errata 2025-1-err2 (September 2026). Apache 2.0.
Dataspace Protocol
The Dataspace Protocol is the interoperability layer underneath Europe’s data spaces: how one organization finds data another offers, agrees the terms it may be used under, and gets access to it — with the usage policy carried through every step. It began as the International Data Spaces Association’s specification (releases 0.8 and 2024-1), which the IDSA contributed to the Eclipse Dataspace Protocol project under the Eclipse Dataspace Working Group. Release 2025-1 shipped on 29 August 2025 and is declared stable — “further changes shall not affect conformity” — with errata 2025-1-err1 (November 2025) and 2025-1-err2 (11 September 2026). Sector data spaces such as Catena-X build their connectivity on it.
- Three protocols, each with an HTTPS binding - Catalog (publish and query what a participant offers), Contract Negotiation (offer, request, agreement, verification, as a state machine) and Transfer Process (push and pull transfers, as a state machine). Each defines its messages abstractly and binds them to HTTPS separately.
- Normative JSON Schemas - Every protocol message is normatively defined by a
JSON Schema; the schemas ship in the repository under
artifacts/src/main/resources/{catalog,negotiation,transfer,common}/. - JSON-LD that still validates - A JSON-LD 1.1 context is designed so that compacted messages validate against the JSON Schemas, keeping JSON-only and linked-data implementations interoperable.
- Policy-first - Offers and agreements carry usage policies expressed in ODRL, and catalogs describe datasets with DCAT vocabulary — the agreement, not the transfer, is the center of the protocol.
- A well-known version endpoint - Every implementation MUST serve
/.well-known/dspace-versionso a counterpart can find which protocol versions and paths it supports. - DID-based discovery - A participant MAY advertise its connectors and catalog services in a Decentralized Identifier document, with a published schema for the service entry.