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.

Sign up for GitHub

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

Meeting 2021-09-29 patches #264

Merged
merged 1 commit into from
Sep 29, 2021
Merged

Meeting 2021-09-29 patches #264

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
73 changes: 43 additions & 30 deletions meetings/2021-09-29.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -68,17 +68,25 @@ RESOLUTION: Matthieu as Editor of ACP work item.

### giving rights to the creator of a resource
URL: https://github.com/solid/authorization-panel/discussions/261
* Henry: Trying to discuss about the modes, a proposed use case would be: "people can only delete comments they've posted on a blog".
* ...: For this type of thing, you'd need n3 rules. It doesn't need to be implemented straight away.
* ...: For people deciding to edit their comments, you would need some form of reasoning.
* Henry: Following on the discussion about the modes available in WAC, a use case was
* proposed that amounts to having rules of the form: "people can only delete comments they've created" - think of a blog".
* ...: I thought about how to model this, and it looks like one needs n3 rules, or it is easiest to express
* it that way.
* We would not necessarily want to implement it that way, but at least we can start
* seeing what logical level of expressiveness we find ourselves at.
* ...: The use case is definitely very good and would be very common one, but oddly
* enough we end up with some reasoning there. So I wonder what the long term view of N3 in Solid was.
* ...
* Tim: I think Ruben and I for example were thinking about the architecture of Solid in the future, the emphasis would be on data and relationships and simple shapes.
* ... We'd get a point where having gentle very simple inference. For example RDFS would solve a lot of ontology mismatch problems.
* ... We'd get a point where we would gently add very simple inference. For example RDFS would solve a lot of ontology mismatch problems.
*...The moment you start looking at sorting emails and things like that (such as photographs albums), creating rules and having a rule engine inside Solid in the future would be very handy.
*... There is an argument to say deriving the class of entity interacting with content in order to enforce access control would be very handy (parent of x...).
* Henry: how can i present something logicallyt that fits with the sw. the n3 rule gives me an idea where it ends up in 10 years time.. then we are thinking about ti straight.. and finding little ways.. hacking it or finding the sweet spots where we don't need reasoning.
*...I'll paste the rule in the Scribe doc:
* Henry: I find that I am also looking to make sure that what we produce can be explained in logically terms hat fit with semantic
* web stack such as N3. The N3 rule gives me an idea where it ends up in 10 years time... (hopefully earlier) then we are thinking about how
* to simplify the problem in one way or another and find ways to get there piecemeal or finding the sweet spots where we don't need reasoning (yet).
* Anyway, bizarely enough we find that a rule ends up being needed here.

```
```turtle
{ ?i a foaf:Agent } => {
[] a :Authorization;
:accessToClass [
Expand All @@ -90,43 +98,48 @@ URL: https://github.com/solid/authorization-panel/discussions/261
}
```


### ODRL in Solid
URL: https://github.com/solid/authorization-panel/issues/55
* SC: Beatriz Esteves to present ODRL Profile for Access Control in Solid https://w3id.org/oac/
* Beatriz: Hi everyone. I'm a PhD student funded by the Protect project.
* ...: My PhD research will be around developing machine readable policies in the context of SOlid. It is motivated by GDPR in Europe (article 14 & 15), a lot of info about hte user (identity/purpose...) will need to be available.
* ...: How to store info in a manner compliant with GDPR?
* ...: What we already started is building an ODRL projfile which extends the Solid mechanism to express access control using the Data Privacy Vocabulary. The profile is at w3id.org/oac/
* ...: My PhD research will be around developing machine readable policies in the context of Solid. It is motivated by GDPR in Europe (article 14 & 15), a lot of info about hte user (identity/purpose...) will need to be available.
* ...: How to store info in a manner compliant with the GDPR?
* ...: What we already started is building an ODRL profile which extends the Solid mechanism to express
* ...: access control using the Data Privacy Vocabulary. The profile is at https://w3id.org/oac/
* ...: For this profile we had prerequisites in mind:
- policies should support expressing preferences and data access requests
- specify different levels of granularity in policies for specific container/resources or broader for specific types of personal data
* ..: There is an example of policy expressed using the odrl profile in the slide as well as a link to the simple consent demo we built.
* Pavlik: How to enforce those policies? Currently, the resource server would enforce. With those policies, it sounds like legal enforcement rather than software?
* Beatriz: It's something we're still debating. To start we could define constraints with SHACL shapes for example to constrain what type of policy a user can define also if you define something for a container, you can use the ACL file but if you wanna be broader, you'd need a standard way to understand which data is of a certain type.
* ..: There is an example of policy expressed using the odrl profile in [the slide](https://www.slideshare.net/BeatrizEsteves23/consent-2021-odrl-profile-for-expressing-consent-through-granular-access-control-policies-in-solid) as well as a link to the simple consent demo we built.
* Pavlik: How does one enforce those policies? Currently, the resource server would enforce access control. Yet, these policies sounds like legal enforcement rather than software?
* Beatriz: It's something we're still debating. To start we could define constraints with SHACL shapes for example to constrain what type of policy a user can define also if you define something for a container, you can use the ACL file but if you want to be broader, you'd need a standard way to understand which data is of a certain type.
* Pavlik: We have work under way to classify types of data in interop pannel. But how could that purpose be enforced on the server level?
* Beatriz: perhaps academic research is not the best example. solid apps will have these policies in the dev of their apps.. when user authorizes.
* Henry: I thought about this because Oshani Seneviratne at MIT was working on something similar. THere id a level of access control in there because the server can look at the WebId of the app and see if it understands the vocabulary. If it doesn't, the client is deaf. If the client understands, then you're legally bound.
* ...: now, what does it mean to be legally bound? If it's the client who wants to legally bind the server to not disclose the data, then you might be interested to know in which country the server is for example.
* ...: Which legel system is the server bound to? If it's an island in the middle of the Pacific, you don't need to abide by any law.
* Tim: Back to the original question. How do you enforce. Simply, phylosifically, you never can. If I give you data, it won't turn bad if you try using it for the wrong purpose. But large companies can be prosecuted if they make unlawful use of data.
* Henry: I thought about this because Oshani Seneviratne at MIT was working on something similar. There is a level of access control when the server can look at the WebId of the App and see if it declares itself to be an understander of the (policy) vocabulary. If the App does not declare itself to be, the server could conclude that the client is deaf to such policies. If the client publishes that it understands, then it is legally bound.
* ...: Mind you this may reveal a difference between her work and Beatriz's. Oshani was trying to set policies on client use of server content, whereas from the talk of GDPR, Beatriz is looking at clients wanting to limit what the server does with the data they give it.
* ...: Still similar tricks may apply.
* ...: What does it mean to be legally bound? If it's the client who wants to legally bind the server to not disclose the data, then you might be interested to know in which country the server is for example.
* ...: Which legal system is the server bound to? If it's an island in the middle of the Pacific, it might not need to abide by any law.
* Tim: Back to the original question. How do you enforce. Simply, philosophically, you never can. If I give you data, it won't turn bad if you try using it for the wrong purpose. But large companies can be prosecuted if they make unlawful use of data.
* ...: Say you use some data for a diagnostic. A hospital's information system could easily enforce agreed purpose. In order for my medical data to be used for research, it should be agreed upon specifically.
* SC: Oshani's: http://dig.csail.mit.edu/2010/Papers/IAB-privacy/httpa.pdf
* Justin: Really interesting work. Something Pavlik mentionned: if you wanna apply somethin to a particular resource, fine, but in reality, you have data spread accross multiple resources and containers and whatever does authz needs to understand that. It is implicitly understood that applications need to understand and agree on what they're working with. You can use the same approach for validation as when you try to determine the type of data.
* SC: Oshani's paper [HTTPa: Accountable HTTP](http://dig.csail.mit.edu/2010/Papers/IAB-privacy/httpa.pdf)
* Justin: Really interesting work. Something Pavlik mentioned: if you want to apply something to a particular resource, fine, but in reality, you have data spread across multiple resources and containers and whatever does authz needs to understand that. It is implicitly understood that applications need to understand and agree on what they're working with. You can use the same approach for validation as when you try to determine the type of data.
* ...: There is a solution in Shape trees that could be applied to both enforcing access control and get a machine to machine understanding of types of data to enforce purpose.
* Davi: Someone who crosses the Pacific will need to abide if you're sailing under a US flag. Open waters doesn't mean lawless. There are complicated rules about open water lawful enforcement involving cross countries/international agreements.
* Henry: The [web of nations](https://medium.com/@bblfish/use-cases-for-the-web-of-nations-361c24d5eaee) tries to deal with that problem by allowing visible diplomatic relations and treaties on the web.
* ...: There is something similar to what you're doing. We're thinking of allowing access control to get apps ... say you have a banking app, then you should restrain where and what it can write. It might fit in your work.
* Beatriz: For the GDPR doesn't talk about access modes but more about hte processing that is done on the data. We should map those operations to GDPR and some terms are not translatable. How to map WAC to sharing the data with a differnet recipient. The issue is not esily addressed. We need to map operations to access control classes.
* Pavlik: Somethimes we conflate the client and the end user (social agent/legal person), we don't expect the software to have legal binding, we expect the legal agent to provide or request consent. Teh end user of a client application is commiting to respect a policy, not the software itself, is that correct?
* Davi: Someone who crosses the Pacific will need to abide by the law if you're sailing under a US flag. Open waters doesn't mean lawlessness. There are complicated rules about open water lawful enforcement involving cross countries/international agreements.
* Henry: The law tends to be territorial. See the paper [Extraterritoral Jurisdiction to enforce in cyberspace? Bodin, Schmitt, Grotius in cyberspace](https://www.utpjournals.press/doi/abs/10.3138/utlj.1119) by Prof Mireille Hildebrandt, author of [Law for Computer Scientists](https://lawforcomputerscientists.pubpub.org),
* ... : which I mention in the [web of nations use cases](https://medium.com/@bblfish/use-cases-for-the-web-of-nations-361c24d5eaee). The WoN tries to deal with that problem by allowing visible diplomatic relations and treaties on the web. So in a way that
* ... : would be helpful to allow the client understand what legal space the server is located in: what legal recourse could the user have? What diplomatic relations does
* ... : that country have with her country. Those are a much larger picture I think that is worth having in mind.
* ...: Mind you, there is something else similar to what you're doing. We're thinking of using the Web Access Control Ontology to authorize apps to authenticate. [Use WAC ontology for authorizing authentication](https://github.com/solid/authorization-panel/discussions/258)... Example would wanting to restrict where a banking App can write. It might fit in your work.
* Beatriz: For the GDPR doesn't talk about access modes but more about the processing that is done on the data. We should map those operations to GDPR and some terms are not translatable. How to map WAC to sharing the data with a different recipient. The issue is not esily addressed. We need to map operations to access control classes.
* Pavlik: Sometimes we conflate the client and the end user (social agent/legal person), we don't expect the software to have legal binding, we expect the legal agent to provide or request consent. The end user of a client application is committing to respect a policy, not the software itself, is that correct?
* Beatriz: Yes
* Tim: When I give the NHS acess to data? I was impressed because they ask what type of organisation is involved? Typically, applications and software are terrible at capturing the intent of granted operations. In SOlid, the access can be linked and bound to standard intent. It would be very valuable for us to actually talk about differnet uses of purpose in access managemnt. In fact we already have some useful use cases.
* Pavlik: I thought it's really great to have a strong foundationfor policies that would not be enforced at the software level, but rather legally binding. A person who has access can delegate it because they can for example setup a proxy; this kind of control restriction does fit better to those use cases because as soon as someone can read information, there is an opportunity for them to share that info. When you want to enforce more than read and go into restraining sharing, you want to go into purpose which is more of a legal than a technical restriction. https://solid.github.io/authorization-panel/authorization-ucr/#uc-delegation-subset
* Tim: When I give the NHS access to data? I was impressed because they ask what type of organisation is involved? Typically, applications and software are terrible at capturing the intent of granted operations. In Solid, the access can be linked and bound to standard intent. It would be very valuable for us to actually talk about different uses of purpose in access management. In fact we already have some useful use cases.
* Pavlik: I thought it's really great to have a strong foundation for policies that would not be enforced at the software level, but rather legally binding. A person who has access can delegate it because they can for example setup a proxy; this kind of control restriction does fit better to those use cases because as soon as someone can read information, there is an opportunity for them to share that info. When you want to enforce more than read and go into restraining sharing, you want to go into purpose which is more of a legal than a technical restriction. https://solid.github.io/authorization-panel/authorization-ucr/#uc-delegation-subset
* Beatriz: to be in compliance with GDPR, you need this.
* Tim: Yes, delegation is a good case to highlight the differnce between legal and technical restrictions.
* SC: Next steps/interest for ODRL-OAC-and-friends in Solid.. Should a pannel tackle this? Do people see this as worthwhile for Solid?
* Tim: Yes, delegation is a good case to highlight the difference between legal and technical restrictions.
* SC: Next steps/interest for ODRL-OAC-and-friends in Solid.. Should a panel tackle this? Do people see this as worthwhile for Solid?
* Justin: Absolutely relevant and important. In interop we have a framework for expressing needs, consent and delegation. TBD is dropping in some sound legal structure into consent. We have a good foundation programmatically but having a legal hindsight on which to collaborate with Beatriz would be great. https://solid.github.io/data-interoperability-panel/specification/#consents
* Eric P: Tim do you remember some work happening on a EUrop commision grant where they were talking about watermarking the data to find out whether they violated intent of share.
* Eric P: Tim do you remember some work happening on a European commission grant where they were talking about watermarking the data to find out whether they violated intent of share.
* Tim: I don't have a specific recollection of how data watermarking might work.
* Eric: It might not be watermarking, I'll find out what this was.
* Sarven: I'd like to hear from Tim. How should we proceed on the ecosystem?
Expand Down