Implementing custom parameterized policies in EDC v0.6.0

[agmangas]

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.

Objective

My 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 ContractRequest from the consumer contains a policy that differs from the provider's, it results in an error in the ContractValidationService.

Proposed Approach

I plan to include custom parameters in the ContractOffer policy, which would then be accessed in the AtomicConstraintFunction implementing my custom policy. Specifically, I intend to retrieve these parameters from the ContractAgreement instance available via the PolicyContext when the constraint function is bound to the TRANSFER_SCOPE scope.

I've started reimplementing the ContractValidationService, but this seems a bit overkill, especially given that these modules are not intended for replacement.

Motivation

The motivation behind this extension originates from our data space's two-tiered identity system:

• Organization-level identity (all connector instances have such an identity)
• End-user-level identity (which may or may not be associated with an organization)

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.
Our goal would be to sometimes evaluate policies in the context of both identities:

• The consumer connector's identity
• The identity of the end-user initiating the contract negotiation via the web UI

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 🙇

[jimmarino]

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.

[agmangas]

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.