Federated dataspaces rely on the Eclipse Dataspace Working Group (EDWG) specifications—Data Plane Signaling, the Eclipse Dataspace Protocol (DSP), the Eclipse Decentralized Claims Protocol (DCP), the Eclipse Data Rights Policies Profile (DRP), and the Eclipse Conformity Assessment Policy and Credential Profile (CAP)—together with W3C ODRL 2.2 and the Gaia-X Data Transfer Agent (DTA), to authenticate participants, verify credentials, negotiate usage agreements, and coordinate transfers across organizational boundaries.
Once a transfer is prepared and data enters a consumer's data plane and processing pipeline, consumers need a standardized, deterministic way to evaluate payload-observable constraints—such as structural schema rules, value bounds, aggregation thresholds, and ISO/IEC 25012 / ISO 8000-8 data quality checks—linked to the negotiated DSP agreement and transfer flow, and to record tamper-evident audit receipts of those checks. By design, Eclipse CAP explicitly places "Automated compliance or Compliance as Code" and "The management of the policies, the claims and the evidence" out of scope so it can focus on the ISO/IEC 17000 conformity-assessment ontology, while Eclipse DRP specifies that an accessSubject "MUST not process the resource" when environment license conditions are not met, leaving runtime evaluation to the consumer's processing environment.
The Eclipse ODGS Dataspace Bridge integrates directly with Data Plane Signaling, DSP, DCP, CAP, and DRP at the consumer data-plane boundary. Operating as (or behind) a consumer data plane, it retrieves negotiated DSP agreements for active data flows, evaluates payload-observable constraints prior to downstream processing, signals transfer suspension or termination back to the consumer control plane upon violation, and issues consumer-signed audit receipts (Semantic Certificates / S-Certs) that can be stored as W3C Verifiable Credentials (cap:Declaration) and presented via DCP—under an explicit first-party consumer audit record trust model.
Integration with the Eclipse Dataspace Working Group specifications (Data Plane Signaling, DSP, DCP, CAP, and DRP) is a primary goal of the project. The Eclipse ODGS Dataspace Bridge provides consumer-side data-plane constraint evaluation and cryptographic audit-receipt generation (S-Cert) connected directly to compliant dataspace control planes and credential services.
The scope of the Eclipse ODGS Dataspace Bridge project includes:
- Data Plane Signaling & Consumer Data-Plane Integration: Running as, or behind, a consumer data plane registered with a consumer control plane; handling DataFlowPrepareMessage and DataFlowStartMessage payloads carrying agreementId and dataFlowId (equal to the DSP transfer process ID); and retrieving the negotiated DSP agreement from the consumer control plane via the agreement retrieval endpoint (GET /transfers/:dataFlowId/agreement) to evaluate payload-observable constraints for the flow.
- DSP Agreement Binding & Violation Signaling: Compiling payload-observable clauses from negotiated DSP odrl:Agreement policies, W3C ODRL 2.2 rules, and Eclipse DRP delegationEvidence conditions into deterministic runtime checks bound to SHA-256 digests (semantic_hash) of the policy source; referencing agreementId and the DSP transfer process ID in emitted audit evidence; and signaling violations (HARD_STOP or SOFT_STOP) to the consumer control plane so it can suspend or terminate the transfer process and notify the provider via dspace:TransferSuspensionMessage or dspace:TransferTerminationMessage.
- DCP Credential Issuance, Storage & Presentation: Issuing runtime audit records (S-Certs, canonicalized via RFC 8785 JCS and signed via RFC 7515 JWS / Ed25519) as W3C Verifiable Credentials (cap:Declaration first-party declarations carrying cred:Evidence digests) signed with a key from the consumer's DID document (did:web), held in the consumer's credential service, and presented to providers through DCP presentation requests (PresentationQueryMessage / PresentationResponseMessage)—allowing providers to require prior audit credentials in policy as a condition for subsequent negotiations or transfers.
- Constraint Observability Classification & Standards Exporters: Classifying ODRL policy terms into payload-observable checks versus unobservable downstream usage constraints (inspect_odrl_constraint_observability), alongside lightweight Python and JavaScript/TypeScript evaluators and exporters for Eclipse CAP v2.2.1, Gaia-X DTA provenance digests, W3C PROV-O lineage graphs, NIST OSCAL v1.1.2 assessment findings, and LinkML / W3C OWL 2 schemas aligned with ISO/IEC 38505-1 and ISO/IEC 25012.
The following items are explicitly out of scope:
- Re-implementing Control-Plane or Identity Protocols: Re-implementing DSP catalog/contract-negotiation state machines, Data Plane Signaling control-plane orchestration, or DCP identity/transport infrastructure (this project integrates with compliant control planes and credential services, such as Eclipse EDC, rather than replacing them).
- Evaluating Non-Observable Downstream Usage Constraints: Enforcing or verifying behavioral constraints on use—such as purpose (odrl:purpose), retention (odrl:elapsedTime / odrl:dateTime), or onward sharing (odrl:distribute / odrl:share)—which cannot be observed by inspecting a payload prior to a processing step.
- Provider-Verifiable Remote Execution Proof: Hardware Trusted Execution Environment (TEE) remote attestation or provider-controlled sandboxes; S-Certs are explicitly scoped as consumer-signed first-party audit records, not provider-verifiable proof of policy enforcement.
- Redefining Standing Conformity or Delegation Schemas: Redefining ISO/IEC 17000 conformity-assessment ontologies (covered by Eclipse CAP) or pre-transfer delegation token schemas (covered by Eclipse DRP).
- Proprietary Policy Authoring or Legal Interpretation: Jurisdiction-specific legal advice, proprietary regulatory rulepacks, or commercial governance user interfaces.
Eclipse ODGS Dataspace Bridge provides an Apache-2.0 reference implementation, JSON/LinkML/OWL schemas, and CLI/SDK libraries (Python and Node.js) that connect dataspace control-plane agreements to consumer data-plane payload checks and structured audit records.
Trust Model & Constraint Observability
The project states its trust assumptions explicitly:
- First-Party Consumer Audit Record (Not Proof of Policy Enforcement): S-Certs (and projected cap:Declaration Verifiable Credentials) are produced and signed by the consumer as part of its processing pipeline from payload values provided by the consumer. ODRL constraints are evaluated only against fields of a payload supplied by the consumer.
- Observable vs. Unobservable Constraints: Structural, schema, value-range, and aggregation constraints (for example, minimum record aggregation counts or ISO/IEC 25012 quality bounds) can be evaluated on a payload before a processing step. Constraints on downstream use—such as purpose, retention, or onward sharing—cannot be observed by checking a payload prior to processing.
- Provider Verification Boundary: Consequently, ODRL policies are not enforced in a way that a provider can independently verify. An S-Cert records that the consumer reports having executed a deterministic check over a specific payload digest (payload_hash) and rule digest (semantic_hash) under a specific agreementId and transfer flow. While useful as a signed, structured audit record (aligned with ISO/IEC 17000 first-party cap:Declaration), S-Certs are not presented as proof of policy enforcement.
Concrete EDWG Integration Architecture & Roadmap
To progress from the initial contribution (odgs-dataspaces-bridge) to full end-to-end integration with the Eclipse Dataspace Working Group stack, the project follows three concrete milestones:
- Milestone 1 — Core Signaling, DSP & DCP Message Bindings (Initial Contribution): Reference DataPlaneSignalingBridge interface handling DataFlowPrepareMessage / DataFlowStartMessage and GET /transfers/:dataFlowId/agreement agreement resolution; ODRL observability classification (inspect_odrl_constraint_observability); DSP dspace:TransferSuspensionMessage (SOFT_STOP) and dspace:TransferTerminationMessage (HARD_STOP) generation bound to agreementId and dataFlowId; and DID-signed cap:Declaration VC issuance and DCP PresentationQueryMessage → PresentationResponseMessage handling.
- Milestone 2 — Consumer Data Plane HTTP Adapter for Control-Plane Registration: Standalone HTTP consumer data-plane service registering with a compliant consumer control plane (such as Eclipse EDC), executing live GET /transfers/:dataFlowId/agreement calls on flow preparation, evaluating streaming/batch payloads, and invoking control-plane transfer suspension/termination endpoints upon violation.
- Milestone 3 — DCP CredentialService Integration & Provider Policy Gate: End-to-end integration with an Eclipse DCP CredentialService storing DID-signed runtime audit VCs and presenting them via DCP presentation requests so a provider can evaluate prior audit records in policy during subsequent contract negotiations or transfers.
- Source Repository (Apache-2.0): https://github.com/MetricProvenance/odgs-dataspaces-bridge
- Core Protocol Repository (Apache-2.0): https://github.com/MetricProvenance/odgs-protocol
- Technical Documentation & LinkML/OWL Schemas: https://metricprovenance.github.io/odgs-dataspaces-bridge/
- Log in to post comments
I reviewed the proposal and…
Submitted by James Marino on Mon, 11/02/2026 - 10:32
I reviewed the proposal and the initial contribution ([odgs-dataspaces-bridge](https://github.com/MetricProvenance/odgs-dataspaces-bridge)). My comments concern the project's relationship to DSP, DCP, and Data Plane Signaling. I also have a comment about the presented trust model.
## Relationship to DSP, DCP and Data Plane Signaling
The proposal places DSP, DCP, and Data Plane Signaling out of scope and positions the project as the post-transfer step that follows them. The repository documentation describes the project as an integration with the Eclipse Dataspace Working Group specifications, including DSP and DCP, but the initial contribution has no connection to them today.
This raises a question about the project's intent: is integration with the dataspace specifications a goal of the project? If it is not a goal, that's fine, but the documentation should then avoid describing the project as an integration.
If integration is a goal, the proposal should map out the concrete steps for getting there. Here are some suggestions for doing so. These are only ideas, and I'm sure there are alternatives that could be pursued:
- **Data Plane Signaling.** The bridge could run as, or behind, a consumer data plane registered with the consumer control plane. The prepare message the control plane sends to the data plane contains the `agreementId` and the `dataFlowId`, which equals the DSP transfer process ID. The data plane can retrieve the DSP agreement from the control plane through the agreement retrieval endpoint (`GET /transfers/:dataFlowId/agreement`) and evaluate that agreement's constraints for the flow.
- **DSP.** Enforcement could be driven by the DSP agreement, and evidence could reference the `agreementId` and the transfer process. If the consumer control plane suspends or terminates the transfer process because of a violation, it notifies the provider with a `TransferSuspensionMessage` or `TransferTerminationMessage`.
- **DCP.** Runtime evidence could be issued as a Verifiable Credential signed with a key from the consumer's DID document, held in the consumer's credential service, and presented to the provider through a DCP presentation request. The provider could then require that credential in its policy, for example as a condition for a later negotiation or transfer.
## Trust model
S-Certs are produced and signed by the consumer as part of its processing pipeline from values it provides. ODRL constraints are evaluated against fields of a payload created by the consumer. It's important to note that constraints on use, such as purpose, retention, or onward sharing, cannot be observed by checking a payload before a processing step. As a result, ODRL policies are not enforced in a way the provider can verify. An S-Cert records that the consumer reports having run a check.
That can be useful as an audit record. The proposal should state this trust assumption explicitly and should not present S-Certs as proof of policy enforcement.
Thanks for reviewing both…
Submitted by Kartik Iyer on Tue, 11/10/2026 - 07:35
In reply to I reviewed the proposal and… by James Marino
Thanks for reviewing both the proposal and the repository. Both points are well made, and I have updated the Background, Scope, and Description sections above (as well as the repository and documentation at https://metricprovenance.github.io/odgs-dataspaces-bridge/eclipse-edwg/) to reflect them.
On the first point, integrating with the EDWG specifications is indeed the goal. I had initially listed DSP, DCP, and Data Plane Signaling under Out of Scope only to make clear that the project is not re-implementing a control plane or identity protocol, and I have now updated the scope and added a three-step roadmap following your suggestions for Data Plane Signaling (GET /transfers/:dataFlowId/agreement), DSP suspension/termination notifications, and DID-signed DCP credentials.
On the trust model, I take your point completely. Because checks run inside the consumer's pipeline on values it provides, and pre-processing checks cannot observe purpose, retention, or onward sharing, I have removed the "proof of policy enforcement" wording and stated explicitly that an S-Cert is a consumer-signed audit record (cap:Declaration) over payload-observable fields.