|
1 | 1 | # Introduction |
2 | 2 |
|
3 | | -The __Dataspace Protocol__ is used in the context of [=Dataspaces=] as described and defined in the subsequent sections |
4 | | -with the purpose to support interoperability. |
5 | | -In this context, the specification provides fundamental technical interoperability for [=Participants=] |
6 | | -in [=Dataspaces=]. |
7 | | -Beyond the technical interoperability measures described in this specification, semantic interoperability should also be |
8 | | -addressed by the [=Participants=]. On the perspective of the [=Dataspace=], interoperability needs to be addressed also |
9 | | -on the level of trust, on organizational levels, and on legal levels. |
10 | | -The aspect of cross-dataspace communication is not subject of this document, as this is addressed by the [=Dataspaces=]' |
11 | | -organizational and legal agreements. |
| 3 | +The __Dataspace Protocol__ is used in the context of [=Dataspaces=] as described and defined in the subsequent sections with the purpose to support _interoperability_. In this context, the specification provides fundamental technical interoperability for [=Participants=] in [=Dataspaces=]. |
12 | 4 |
|
13 | | -The interaction of [=Participants=] in a [=Dataspace=] is conducted by the [=Participant Agents=], |
14 | | -so-called [=Connectors=], which implement the protocols described above. |
15 | | -While most interactions take place between [=Connectors=], some interactions with other systems are required. |
16 | | -The figure below provides an overview on the context of this specification. |
| 5 | +This specification builds on protocols located in the [ISO OSI model (ISO/IEC 7498-1:1994)](https://www.iso.org/standard/20269.html) layers, like HTTPS. The purpose of this specification is to define interactions between systems independent of such protocols, but describing how to implement it in an unambiguous and extensible way. To do so, the [=Messages=] that are exchanged during the process are described in this specification and the states and their transitions are specified as state machines, based on the key terms and concepts of a [=Dataspace=]. On this foundation the bindings to data transfer protocols, like HTTPS, are described. |
17 | 6 |
|
18 | | -An [=Identity Provider=] realizes the required interfaces and provides required information to implement the Trust |
19 | | -Framework of a [=Dataspace=]. |
20 | | -The validation of the identity of a given [=Participant Agent=] and the validation of additional claims is a fundamental |
21 | | -mechanism. The structure and content of such claims and identities may, however, vary between different [=Dataspaces=], |
22 | | -as well as the structure of such an [=Identity Provider=], e.g. a centralized system, a decentralized system or a |
23 | | -federated system. Other specifications define the respective functions. |
| 7 | +_Note: This specification does not cover the data transfer as such. While this is controlled by the [=Transfer Process Protocol=], e.g., the initiation of the transfer channels or their decomissioning, the data transfer itself and especially the handling of technical exceptions is an obligation to the transport protocol._ |
24 | 8 |
|
25 | | -A [=Connector=] will implement additional internal functionalities, like monitoring or policy engines, as appropriate. |
26 | | -It is not covered by this specification if a [=Connector=] implements such or how. |
| 9 | +The classes and definitions used in this specification are reused from different standards and specifications as much as possible, in particular, DCAT [[?vocab-dcat-3]] and ODRL [[?odrl-model]]. As, however, the external definitions allow different interpretations or provide more attributes than required, this specification is leveraging _profiles_ of the original definitions rather than the complete original expressiveness. A _profile_ in this sense is a restriction or subset of an external definition, enforcing that every occurrence of an externally defined class is always conformant with the original definition. However, not every standard-compliant class might be compliant to the [=Dataspace=] profile. The profiles are not separate artifacts but implicitly contained in the JSON schemas for the [=Message Types=] of this specification. |
27 | 10 |
|
28 | | -The same applies for the actual data that is transferred between the systems. While this document does not define the |
29 | | -transport protocol, the structure, syntax or semantics of the data, a specification for those aspects is required and |
30 | | -subject to the agreements of the [=Participants=] or the [=Dataspace=]. |
| 11 | +This specification is organized into the following documents: |
31 | 12 |
|
32 | | - |
| 13 | +* [[[#terminology]]] documents define key terms. |
| 14 | +* [[[#requirements]]] declares cross-cutting functions as, e.g., the declaration of supported versions of this protocol and common data processing rules. |
| 15 | +* [[[#catalog-protocol]]] and [[[#catalog-http]]] define how [=Catalogs=] are published and accessed as HTTPS endpoints respectively. |
| 16 | +* [[[#negotiation-protocol]]] and [[[#negotiation-http]]] documents that define how [=Contract Negotiations=] are conducted and requested via HTTPS endpoints. |
| 17 | +* [[[#transfer-protocol]]] and [[[#transfer-http]]] documents that define how [=Transfer Processes=] using a given data transfer protocol are governed via HTTPS endpoints. |
0 commit comments