Whitelist/Approval process should control the destinations a data plane can write to

[alpercem70]

Right now, any arbitrary source/S3 bucket can be given to a control plane’s management API via transfer process endpoint. Whitelisting and approval processes need to exist to create a secure boundary on the consumer side and prevent bad actors and erroneous activity from exfiltrating data to an unwanted destination.

[rafaelmag110]

Hi Alper, could you provide more details about how this whitelisting and approval process could look like? It could help me understand the idea better...

[alpercem70]

Hi Rafael, as part of a S3 data transfer the consumer is putting the destination S3 bucket as part of the payload to, but at the moment EDCs don't restrict what this data destination can be. What I'm suggesting is to cross check this destination with a set of approved/whitelisted sources on the provider EDC and reject the transfer request otherwise. Same kind of restrictions can be applied to other sources as well.

[jimmarino]

Hi,

I don't understand the problem. In a push scenario where the provider sends data (via S3 or some other transport), the consumer selects the endpoint address. The provider can guard against malicious actors by not concluding a contract agreement. When an agreement is made, a trust relationship is established, which is verified when a transfer process request is initiated.

Since a provider does not necessarily have a relationship established with a consumer before this, I don't see how a whitelist of destinations is relevant.

[rafaelmag110]

Hi @jimmarino
I spoke with Alper to undertand the problem better and this discussion is indeed lacking details.

The current behaviour Alper is trying to avoid is the one where multiple actors inside of the same company (same BPNL) can have unintended access to information. An example can be given when Company A makes an offer for Company B and restricts the offer using BPNL groups, for example. Every connector within company B can have access and obtain a valid agreement for the offer of company A. If this offer contains sensitive and critical information, actors on company A might not want everyone from company B to access it.

At the moment we have no way to prevent this.

[jimmarino]

A participant identity is a single concept in a dataspace - there is no such thing as hierarchical identities. This is by design, both in the DSP standards and the EDC. Either a company will have independent identities (and EDC deployments), or other additional security infrastructure outside the scope of EDC will need to be added.

[rafaelmag110]

@alpercem70 For the S3 case, can't you shape your S3 bucket policy to restrict putObject actions only to specific buckets?