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
31 stars 14 forks source link

docs: State security considerations for ID tokens and security tokens #53

Closed milux closed 1 year ago

milux commented 1 year ago

As mentioned in #52, this PR tries to introduce necessary security advice for safe use of ID tokens and security tokens.

I tried to be as open and generic as possible, whilst providing high-level binding-specific hints for HTTPS.

Realized, though, that there is a lot of duplication across all the binding docs. @juliapampus Should common sections for the HTTPS binding be refactored into one common document? WDYT?

juliapampus commented 1 year ago

Refactoring the binding documents in a way that common sections are extracted into a separate document could be a nice idea, I agree. Has this been discussed in some Thursday round? Maybe it's not that urgent right now, but depending on how much we want to elaborate on the documents, this could simplify maintenance.

ssteinbuss commented 1 year ago

We should reiterate this text to clarify if those things are normative or not. Please rediscuss in one of the next calls @milux

ssteinbuss commented 1 year ago

Let's have a dedicated file/section with security considerations, that sum up the aspects shortly. We can reference from the sections to this new one and use it to link other resources, like the Best Practices (see #104 )

milux commented 1 year ago

Let's have a dedicated file/section with security considerations, that sum up the aspects shortly.

Done. Please review this and let me know if it is consistent with what we agreed to in discussion last week.

milux commented 1 year ago

OK, we agreed that this aspects will go to the RAM and implementation examples like OAuth2, did:web etc. should be removed from the spec. A separate cleanup PR will be created for this.

PeterKoen-MSFT commented 1 year ago

As agreed in a discussion in our weekly call today this discussion is better suited for the RAM as it's related to solution implementation decisions and thus better suited to be discussed in the Reference Architecture. To make the separation between the protocol and the reference architecture cleaner we need to remove mention of specific identity technologies from the protocol and leave the discussion of various technologies and token formats to the Architecture WG to be added to the RAM. We also discussed the need to eventually follow up the reference solution architecture with potential recommendation for Management Systems for Dataspaces to enable the creation of Management System Standards for operations of Dataspace Authorities as well as Dataspace Connectors.

jimmarino commented 1 year ago

As agreed in a discussion in our weekly call today this discussion is better suited for the RAM as it's related to solution implementation decisions and thus better suited to be discussed in the Reference Architecture. To make the separation between the protocol and the reference architecture cleaner we need to remove mention of specific identity technologies from the protocol and leave the discussion of various technologies and token formats to the Architecture WG to be added to the RAM. We also discussed the need to eventually follow up the reference solution architecture with potential recommendation for Management Systems for Dataspaces to enable the creation of Management System Standards for operations of Dataspace Authorities as well as Dataspace Connectors.

I agree with most of this except for the need for "Management Systems Standards" if that entails defining an API to manage the operations of "connectors" (or broadly, "participant agent systems"). IMO this is too implementation and deployment-specific. We should also be careful to limit what we attempt to standardize until we have sufficient implementation experience.

gbrost commented 1 year ago

I totally agree that the protocol should not impose an implementation of any identity or remote attestation scheme. However, I am convinced that we should at least mention these procedures and integrate a modular "placeholder" for authentication and remote attestation. Since TEEs are gaining traction (e.g., EDC in SGX deployments start to happen), it would be useful to have an additional state machine that supports these modes of attestation. What do you think?

PeterKoen-MSFT commented 1 year ago

The attestation would be a private detail of the implementation of an Enclave based Connector and not a core functionality of the Dataspace Protocol. Therefore it should be specified in the design document for the implementation but not in here.

Also, as a side note: I do not think that building the entire connector as an enclave is a good design. What should be an enclave is the data plane.

The control plane is a public endpoint. Only a data plane should be a (semi-) private endpoint with protection in an enclave. The attestation state machine would then be part of the design of the enclave based data plane.

This would not change the dataspace protocol for the data transfer. Ensuring that an enclave data plane is instantiated and checking its attestation would be part of the provisioning service which needs to check for the attributes of the data plane anyways. an attestation would simply be another policy for a data plane.

gbrost commented 1 year ago

Thanks for getting back to me. The question is to me if the control plane is in possession of private keys that give access to data plane assets or the control plane is able to configure the data plane that grants access. Would this not be an assets that could require additional protection? I agree that it would not be a wise choice to deploy a large monolithic software artefact into an enclave or a protected VM. But maybe this is valid for specific aspects.

The contracts will need to support these concepts in the long run, anyway.

PeterKoen-MSFT commented 1 year ago

As it's possible to encrypt keys or config information in a way that it can only be decrypted by the data plane I see absolutely no need to run the control plane in an enclave.

Setting up the exchange of encrypted information between the data sender and the receiving data plane would be part of the data plane design as it would happen after the provisioning of the data plane. After the data plane is up and running it can simply send encryption information to the data provider, who then uses that to encrypt the access data or the actual data asset in a way that only that specific enclave can decrypt it.