Trust (negotiation) dimension of Data Connector interactions

[gbrost]

Since the protocol specification in ids-protocol is progressing, I would like to bring up some aspects regarding trust negotiation between control and data plane components.

Trust setup and negotiation in the IDS (or other data spaces) - Connector centric view

Introduction

To establish trust into data exchange processes, several means of secure deployment, security features and certification aspects can be facilitated:

• Secure deployment in a Trusted Execution Environment such as AMD SEV-SNP or Intel SGX (TDX).
  • Verification via Remote attestation of trust properties towards external parties.
• Establishment of Secure Boot via TPM
  • Verification via Remote attestation of trust properties towards external parties.
• Verification of the issued certification level (Such as C5 cloud certification) by verifying the identity properties of a service.
• Storage of data on encrypted volumes, storing private keys in HSMs, ...

These means need to be facilitated to establish trust between parties, or at least to satisfy security requirements that can be part of the usage contracts.

##Assumed data workflow / component interaction

We assume the data transaction relationships as sketched here:

1. An Identity Provider (IdP) issues trust related claims to IDS Connector. In IDS context, this is currently the combination of CA and DAPS. Trust related claims are issued by the DAPS.
2. Data Connector A is looking for specific data. Metadata includes:

• Data characteristics.
• Contract conditions (e.g., C5 cloud certification, execution environment preconditions)
• Connector address offering data offering (Data Connnector B)
• Owner

3. Both parties negotiate a usage contract. This could include:

• "Only process on a specific container or processing context"
• "Only process in a Trusted Execution Environment"
• "Do not forward to another party"

4. Both connectors set up the data workflow
5. Data is exchanged.

Trust implications

Several implications arise fom this:

1. Both parties trust the same IdP (no matter of how centralized or de-centralized). So we have a trust relationship between Connector A/B and the IdP.Identity claims such as certification level or hardware trust anchor support need to be verified between both Data Connectors.
2. Metadata is potentially untrusted. Metadata and identity claim validation has to be done between Data Connectors.
3. Both Data Connectors trust that the other parties Data Connector is "trustworthy":

• Both Data Connectors are deployed in a secure deployment environment.
• Both Data Connectors are configured properly.
• Both Data Connectors are not tampered with.

4. Data Connectors configure data sink and data source to grant access and acquire data for the specified data workflow. Data Connectors have privileged access to data sink and data source. (Remark: This is why in the IDS concepts, we have an overarching trust entity between data services and the Connector Core Services and see this overarching entity as a "Connector".)
5. Data Service associated with Data Connector A consumes data Data Service defined by Data Connector B. This second trust relationship requires verififcation of negotiated trust properties between services.

Proposal for trust integration

The current protocols are useful and needed. However, trust is omitted from the discussions so far. We believe that trust implication are associated with every step as discussed above. The specification so far is deliberately abstract. But we believe that these topics should at least be addressed in an explanatory section stating that these topics need do be defined in another spec. At some point, some extensions or detailing needs to be done:

1. Trust related claims need to be verified on Control plane level as well as Data plane level, since both are involded in trustworthy data transer setup and data exchange.
2. Trust negotiation needs to be part of Data Connector contract negotiation.
3. Trust negotiation needs to be part of the Data Plane interaction.

I would be happy to hear your thoughts. E.g., @ma3u @ralfNeu

[mspiekermann]

For all the people who end up here after time has passed: The Dataspace Protocol has evolved and was openly discussed in IDSA's working group resulting in a release 01-2024. Future specification work will be done in the Eclipse Foundation and the corresponding specification project. All related discussions should be opened there in the future.