Configurable Event Sink / Clearing House Endpoint for Eclipse EDC

[danibelver]

Hello EDC community,

At the moment, Eclipse EDC components natively persist all lifecycle information (contract negotiations, agreements, and transfer processes) in the connector’s local database. While this is technically sufficient, in industrial and regulated environments there is often a strong need to continuously forward this information to a trusted third-party system, such as a clearing house, audit service, or governance platform.

Proposal

We propose introducing a native, configurable “event sink” or “clearing house endpoint” in Eclipse EDC.
Operators would be able to define one or more external URLs in the connector configuration (properties or environment variables), to which the connector would automatically forward all relevant lifecycle events and state changes, for example:

• Contract negotiation events
• Agreement creation and termination
• Transfer process lifecycle events
• Policy evaluation and access decisions (where applicable)

This endpoint would act as a generic, technology-agnostic integration point, allowing organizations to plug in clearing houses, provenance services, or governance platforms without modifying connector internals.

Example Configuration (Conceptual)

edc.events.sink.urls=https://clearinghouse.example.com/events,https://audit.example.com/edc
edc.events.sink.enabled=true
edc.events.sink.format=json

Benefits

• Preserves the decentralized nature of EDC while enabling trusted third-party oversight
• Standardizes integration with clearing houses and governance platforms
• Reduces the need for custom extensions and database-level integrations
• Improves auditability, traceability, and compliance readiness

Questions for the community

• Is there any existing SPI, extension point, or roadmap item that could be leveraged to implement this kind of event sink?
• Would maintainers be open to discussing a standardized event model or payload format for this endpoint?
• Are there similar initiatives or patterns already used in other EDC deployments?

We would be happy to contribute with design discussions, a reference implementation, or documentation if this aligns with the project’s vision and roadmap.

Best regards,

[wolf4ood]

Hi @danibelver

this is already possible with the current EDC architecture. There is a eventing system in the EDC where you can plug and notify externals systems.

There are already avalable generic extensions that does this:

• events-could-http
  -callback-statick-endpoint

Or you can register anEventSubscriber into the EventRouter with an extension and do your logic

[paullatzelsperger]

To expand on @wolf4ood's answer:
We cannot replace our internal database for reasons that are hopefully obvious. What you are asking (forwarding particular events) to wherever is already possible in EDC. It's in the documentation.

In addition, many SPIs can be extended (again, documentation) and extension points exist, I'll not list them here. After all, the autodoc feature exists which gives you that exact information.

I cannot speak for all EDC committers, so take this for what it is, which is my personal opinion, but I don't think discussing a "standardized" event payload makes sense. EDC is not an "application" but a toolbox of components, so there is no point in having a globally standardized payload. Every installation (or dataspace) will want to define this individually.

Beyond what is already possible (events, callbacks), why not implement tooling that operates directly on the database to create audit reports etc.

[ndr-brt]

In addition to what my colleagues said:
please note that centralizing connector events on a third party system, apart from the obvious fact that you are trying to centralize a decentralized architecture (and so you could ask yourselves: do we really need a dataspace for that?), that could not address your audit needs anyway unless you can force all your participant to use a particular connector distribution with your eventing extension baked in and you are 100% sure that nobody manipulates it in a way that the published events are not reflecting the reality.

I'm seeing different dataspace projects that are smashing their head against this and nobody has been able to come up with a proper solution. There's the need to change the mindset to accept decentralization.

I usually tend to ask people why do they need to track internal domain events (like negotiation and transfers), since these are information relative and relevant only to the interaction communication between two dataspace participants.

There could be some form of auditing put in place on applicative level by checking the actual data flowing, e.g.:

• in a use case, the data is shared through message brokers, so the "dataspace governance" becomes a consumer of the data itself so they can subscribe to the topic/queue and actually track all the data that is flowing on a particular contract offer, and eventually reward prolific data providers. plus they can check data-quality and so on
• in another use case, the dataspace governance is the gateway of the data, so all the participant need to negotiate a contract with the authority to interact with their API. this way all the data passes to a central point and audit can be made (this pattern is still "centralization over dataspace", so it does not scale very well)

[jimmarino]

My opinion:

Introducing external calls like this would not scale in a production environment and would result in brittle systems. For example, what happens when the external endpoint (inevitably) goes down?

At an architectural level, "Clearing Houses" have little place in a modern, decentralized dataspace architecture. The design of DSP is explicit about this: contract negotiations are privately conducted between two parties. All elements of a dataspace are designed to maintain this privacy. For example, there is no central Identity Provider that can eavesdrop on transactions. Introducing a Clearing House that receives connector events like this will violate the confidentiality design of DSP-based dataspaces, since a third party will become privy to contract negotiations between two participants. It also won't handle things like non-repudiation since there is no way to prove the other party consented to an action without some form of correlation like as verifiable credentials.

As others have pointed out, please read the documentation on the eventing system. There are numerous examples in the codebase. If you need such a capability, use that to persist an entry in an event table as part of the same transaction and have a separate mechanism that reads the events and processes them from that table. That will scale better and can provide reliability guarantees.

[danibelver]

Thx everyone for the valuable feedback and perspectives. Much appreciated — this has been very helpful for us