Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Relationship between Usage Control and Access Control #67

Open
matgnt opened this issue Mar 14, 2023 · 8 comments
Open

Relationship between Usage Control and Access Control #67

matgnt opened this issue Mar 14, 2023 · 8 comments
Assignees
Labels
Best Practices Best Practices collection for the Dataspace Protocol

Comments

@matgnt
Copy link
Collaborator

matgnt commented Mar 14, 2023

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
Copy link

gbrost commented Mar 21, 2023

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
Copy link
Collaborator Author

matgnt commented Mar 25, 2023

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
Copy link

gbrost commented Mar 27, 2023

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
Copy link
Collaborator Author

matgnt commented Apr 3, 2023

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
Copy link

gbrost commented Apr 4, 2023

I commented there. I fully agree with Peter.

@ssteinbuss ssteinbuss added the Best Practices Best Practices collection for the Dataspace Protocol label Oct 26, 2023
@ssteinbuss ssteinbuss self-assigned this Oct 26, 2023
@ssteinbuss ssteinbuss added V1 pre-release These things must be fixed before pre-releasing V1 of the DSP and removed Best Practices Best Practices collection for the Dataspace Protocol labels Oct 26, 2023
@sebbader-sap
Copy link
Contributor

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
Copy link
Contributor

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

@ssteinbuss ssteinbuss added Best Practices Best Practices collection for the Dataspace Protocol and removed V1 pre-release These things must be fixed before pre-releasing V1 of the DSP labels Nov 9, 2023
@ssteinbuss
Copy link
Member

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

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Best Practices Best Practices collection for the Dataspace Protocol
Projects
None yet
Development

No branches or pull requests

4 participants