ids-specification
ids-specification copied to clipboard
International-Data-Spaces-Association
Relationship between Usage Control and Access Control
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.
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?
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?
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.
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?
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.
Therefore, I propose to remove the "V1 pre-release" label @ssteinbuss
Ack, changed label from "V1 pre-release" to "Best Practices"
