Glossary
Standard Dataspace Protocol terminology (Catalogue, Offer, Agreement, Contract Negotiation, Transfer Process, and others) is defined in the IDSA Dataspace Protocol terminology reference. This glossary covers dataLOFT-specific terms, platform roles, and components.
| Term |
Definition |
| Data Owner |
An individual whose data is held by a provider. The data owner can grant or withhold consent for sharing their data. In the healthcare context, this is typically a patient. |
| Data Provider |
An organisation that holds data belonging to data owners and shares it via the platform. Examples: a hospital or GP practice. |
| Data Consumer |
An organisation that requests and uses data from providers. Examples: a research institute running a clinical study. |
| Federator |
The operator of the management services. The Federator enables data exchange but does not participate in it directly. |
| Orchestrator |
A neutral actor with a coordinating and regulatory function in the data space, responsible for ensuring participants comply with its conventions. |
| Term |
Definition |
| Management Services |
The control plane of the dataLOFT platform. They handle identity, catalogue, contract negotiation, and transfer coordination. They do not process the data being shared. |
| Data Services |
Services built on top of management services by data providers. They implement domain-specific data access logic and connect to RUN-DSP via the run-dsrpc gRPC interface. |
| Contract hook |
A gRPC extension point in RUN-DSP. At each contract negotiation state transition, RUN-DSP calls the configured contract service to determine whether to proceed. |
| Auth hook |
A gRPC extension point in RUN-DSP. On every incoming DSP request, RUN-DSP calls the configured authentication handler to verify the requester's identity. |
| PublishInfo |
The object returned by RUN-DSP to a consumer application after a transfer is started. Contains the file URL, auth token, and transfer ID needed to retrieve or upload data. |
Components
| Term |
Definition |
| RUN-DSP |
The core connector of the dataLOFT platform. A Go binary implementing the IDSA Dataspace Protocol with multi-tenancy support. Published at codeberg.org/go-dataspace/run-dsp. |
| run-dsrpc |
The gRPC interface definition (Protocol Buffers) for RUN-DSP provider and consumer backends. Published at codeberg.org/go-dataspace/run-dsrpc. |
| FC-Service |
The federated catalogue of the dataLOFT platform. Stores participant self-descriptions and service offerings. Based on the Eclipse FC Service. |
| Signature-Auth-Handler |
A NestJS service that validates DPoP tokens, resolves did:web documents, and verifies participant registration in FC-Service. Runs as a RUN-DSP sidecar. |
| HST-DID |
A NestJS service that hosts did:web documents for dataLOFT participants. Runs as a RUN-DSP sidecar. |
| Consent Management App (CMA) |
The application through which data owners manage consent for access to their data. Consists of a mobile frontend and a backend service. |
| Reference Contract Service |
A reference implementation of the RUN-DSP contract hook. Accepts all transitions without policy enforcement. For demonstration purposes only. |
| rdsp-s3 |
The reference provider backend for RUN-DSP. Written in Rust, it serves file data from an S3-compatible object store via the run-dsrpc gRPC interface. |
| r-squared |
The reference data service for the dataLOFT platform. An ECG analysis demonstration built with Kotlin and Quarkus. |
External standards
| Term |
Reference |
| IDSA Dataspace Protocol (DSP) |
docs.internationaldataspaces.org |
| Gaia-X Trust Framework |
docs.gaia-x.eu |
| DPoP (RFC 7800) |
Demonstration of Proof-of-Possession. Binds a token to a private key. Used in the dataLOFT auth subsystem with did:web as the issuer. RFC 7800 |
| did:web |
A DID method that resolves a decentralised identifier by fetching a JSON document from a well-known URL. W3C DID spec |
| Verifiable Credential (VC) |
A cryptographically signed claim conforming to the W3C VC Data Model. Used in Gaia-X self-descriptions. W3C VC spec |