Service architecture

Connector-centric design

RUN-DSP is the integration point for all dataspace communication. Every DSP message (catalogue query, contract negotiation step, transfer request) passes through RUN-DSP. Other services do not communicate with the dataspace directly.

Hook-based extensibility

RUN-DSP delegates two categories of decisions to external services via gRPC hooks:

Authentication hook: On every incoming DSP request, RUN-DSP calls the configured authentication handler to verify the requester's identity. The hook can approve or reject the request. The Signature-Auth-Handler is the production implementation; the Reference Authentication Service is the demo implementation.

Contract hook: At each contract negotiation state transition, RUN-DSP calls the configured contract service to determine whether to proceed. The Reference Contract Service is the demo implementation. In production, this hook should be wired to a policy-enforcing service.

This pattern means that auth logic and contract policy logic are not coupled to the connector core. They can be replaced or extended without modifying RUN-DSP.

Sidecar pattern

In the reference Kubernetes deployment, the authentication handler (Signature-Auth-Handler) and DID hosting service (HST-DID) run as sidecar containers in the same pod as RUN-DSP. This co-location reduces network latency for the gRPC calls from RUN-DSP to the auth handler, and allows the sidecars to share TLS certificates via a shared volume.

gRPC as the internal protocol

All interfaces between RUN-DSP and its backend services are gRPC. The proto definitions are published in the run-dsrpc repository and versioned independently of the connector. This allows data service authors to implement the interface in any language supported by the Protocol Buffers ecosystem.