search

International-Data-Spaces-Association / ids-specification

The Dataspace Protocol is a set of specifications designed to facilitate interoperable data sharing between entities governed by usage control and based on Web technologies. These specifications define the schemas and protocols required for entities to publish data, negotiate Agreements, and access data in a data space
https://docs.internationaldataspaces.org/dataspace-protocol/
Apache License 2.0
34 stars 16 forks source link

Trust dimension of Data Connector interactions #50

Closed gbrost closed 1 year ago

gbrost commented 1 year ago

I would like to try to map the protocol discussion and focus with my personal view of the world:

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:

These means need to be facilitated to establish trust between parties. We assume the data transaction relationships as sketched in the next section:

Assumed data workflow / component interaction

trust_negotiation drawio

  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.

gbrost commented 1 year ago

Opened a discussion in the edc repos, since this is a different layer: https://github.com/eclipse-edc/Connector/discussions/2868