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

Relationship between Usage Control and Access Control #67

Open matgnt opened 1 year ago

matgnt commented 1 year ago

image

As a reminder to what we discussed during the sync call 2 weeks ago. Is Access Control really part of Usage Control?

Seems to appear in multiple documents, e.g. https://internationaldataspaces.org/wp-content/uploads/dlm_uploads/IDSA-Position-Paper-Data-Sovereignty-Requirements-Analysis-of-Manufacturing-Use-Cases.pdf Page 10.

It should be discussed whether:

"Usage control is an extension to traditional access control"

should be changed to:

"Usage control is an *addition* to traditional access control"

for more clarity. I think "extension could be still fine, if not the picture would direct into the idea that one was "contained in" the other.

gbrost commented 1 year ago

Hi, this concept evolved from some major publications in the area of usage control. The idea: Usage control takes access control and extends it to another security context (e.g., a machine outside of your organisation) or some other dimension such as time (use only for a week). The baseline is still an access control decision: May the user x access data item y with action z? This is why this is contained. Does this make sense? Can we somehow rephrase to make that more clear?

matgnt commented 1 year ago

Hi Gerd,

Usage control takes access control and extends it to another security context (e.g., a machine outside of your organisation)

that is an interesting point. If I try to apply this, would it mean that any kind of such usage policy is ONLY possible WITH some kind of technical enforcement? Or how would you describe usage policy (security context outside my own organization...) in case NO technical enforcement was possible?

gbrost commented 1 year ago

Hi Matthias,

I do agree. Without technical enforcement you have "just" a legal agreement in the best case. And indeed, technical enforcement is not trivial. This is also why we focus on Trusted Execution Environments so much from a security point of view. We did build systems based on Trusted Platform Modules, but reliably securing the full software stack is quite challenging.

With a working remote attestation mechanisms and TEEs you could have technical enforcement and a reliable way to prove f the deployed software artefact is what you expect.

matgnt commented 1 year ago

Without technical enforcement you have "just" a legal agreement in the best case.

And that would raise the question that I asked in #75

Would you say that such a 'legal agreement' is a license?

gbrost commented 1 year ago

I commented there. I fully agree with Peter.

sebbader-sap commented 8 months ago

From a plain protocol perspective, this is not anything which needs to be specified by us here. However, we (the DSP working group) proposes to explain the relationship between Usage/Access/etc. Control to the policy/contract data object in the Best Practice document.

sebbader-sap commented 8 months ago

Therefore, I propose to remove the "V1 pre-release" label @ssteinbuss

ssteinbuss commented 7 months ago

Therefore, I propose to remove the "V1 pre-release" label @ssteinbuss

Ack, changed label from "V1 pre-release" to "Best Practices"