-
Dear EDC community, I'm working on implementing an extension to enforce custom policies in the EDC Connector v0.6.0, but I've encountered some challenges. After exploring a few approaches that didn't pan out, I'm reaching out for your insights. ObjectiveMy objective is to allow end-users interacting with the connector via the Management API to parameterize the contract offer. However, I'm aware that the consumer's contract offer must match the provider's offer. Specifically, if the Proposed ApproachI plan to include custom parameters in the I've started reimplementing the MotivationThe motivation behind this extension originates from our data space's two-tiered identity system:
There's a bespoke dashboard (web UI) in our data space that has its own connector instance. End-users access the data space via this dashboard and are not required to obtain an organization-level identity nor deploy their own connector instances.
By extending the properties in the contract request, our policies could provide the Policy Decision Point (PDP) with sufficient context to make decisions on allowing or rejecting requests. I'd greatly appreciate your thoughts on this challenge and any suggestions for alternative solutions. Of course, it could very well be that I'm approaching this from the wrong direction, so please feel free to suggest other designs that are not based on custom policies. Thanks a lot in advance 🙇 |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments
-
Hi, The issue you are running into is related to how you are modeling the problem. First, please make sure you are familiar with the DSP Information Model. A connector is a participant agent and represents a single identity in the dataspace. The identity is typically an organization, but it could be individuals. Whatever the identity represents must be consistent, i.e., homogenous. Note that this does not mean a runtime process only hosts one connector. A contract agreement is between exactly two participants in a dataspace. If you want to restrict access to data within an organization, you should implement it out-of-band from the connector on the consumer side. For example, using some type of access control mechanism. In other words, don't mix the concept of a data user (principal) with a dataspace participant. Presumably, this out-of-band system would have a UI that data users log into, which then uses a connector instance to negotiate contracts and deliver data to the user that requests it. |
Beta Was this translation helpful? Give feedback.
-
Thank you! I was afraid that this problem was indeed badly conceived from the foundation, and that we were trying to fit the end-user-level identity in a way that didn't make much sense. We'll go back to the drawing board. Once again, thanks for your quick response. It's much appreciated. |
Beta Was this translation helpful? Give feedback.
Hi,
The issue you are running into is related to how you are modeling the problem. First, please make sure you are familiar with the DSP Information Model.
A connector is a participant agent and represents a single identity in the dataspace. The identity is typically an organization, but it could be individuals. Whatever the identity represents must be consistent, i.e., homogenous. Note that this does not mean a runtime process only hosts one connector. A contract agreement is between exactly two participants in a dataspace.
If you want to restrict access to data within an organization, you should implement it out-of-band from the connector on the consumer side. For example, using some ty…