Minutes 2022-01-26

meetings/2022-01-26.md

@@ -0,0 +1,97 @@
+# W3C Solid Community Group: Authorization Panel
+
+* Date: 2022-01-26T14:00:00Z
+* Call: https://meet.jit.si/solid-authorization
+* Chat: https://gitter.im/solid/authorization-panel
+* Repository: https://github.com/solid/authorization-panel
+
+
+## Present
+* Matthieu Bosquet
+* Elf Pavlik
+* Wouter Termont
+* Tom Haegemans
+* Barath
+
+---
+
+## Announcements
+
+### Meeting Recordings and Transcripts
+* No audio or video recording, or automated transcripts without consent. Meetings are transcribed and made public. If consent is withheld by anyone, recording/retention must not occur.
+* Use panel chat and repository. Queue in call to talk.
+
+
+### Participation and Code of Conduct
+* [Join the W3C Solid Community Group](https://www.w3.org/community/solid/join), [W3C Account Request](http://www.w3.org/accounts/request), [W3C Community Contributor License Agreement](https://www.w3.org/community/about/agreements/cla/)
+* [Solid Code of Conduct](https://github.com/solid/process/blob/master/code-of-conduct.md), [Positive Work Environment at W3C: Code of Ethics and Professional Conduct](https://www.w3.org/Consortium/cepc/)
+* If this is your first time, welcome! please introduce yourself.
+
+
+### Scribes
+* Matthieu Bosquet
+* Wouter Termont
+
+
+### Introductions
+* Tom Haegemans: One of the co-founders of Digita and would like get more involved in the specification process
+
+---
+
+## Topics
+
+* Policies enforceable only by law https://github.com/solid/authorization-panel/issues/286
+*
+
+### Policies enforceable only by law
+
+* Matthieu: I think it is out of scope for WAC and ACP.
+* Elf: I think I agree, WAC and ACP would only cover the path that is enforced programatically. But maybe Data grants for example could cover some of it.
+* Matthieu: You're proposing that Data grants could be a good place to express permissions that are not programmatically enforceable?
+* ELf: Yes, something at least available to the grantee so they can understand how they would be allowed to delegate their access. We need to understand what different authorization systems can do, and make it user friendly to understand permissions. I don't think users should interact with ACLs (WAC or ACP). We should be careful that people are not misled and don't mistakenly over-permission.
+* Tom: I agree that it's good to have a nice user experience, but also, giving feedback to the user is not necessarily sufficient; it doesn't address the problem of malicious apps. What I see as very useful would be some sort of report on how one's data has been accessed.
+* Elf: Yes, when we have some kind of policy, we should indeed have some kind of report/timeline (as feedback).
+* Tom: Yes, I've been looking into data protection research; for example, Anna Riselman(?)... Step away from consent, and analyse what happens after a user has given consent. Consent can only go so far because the user needs to be able to understand what they're consenting to (let's say, for example, in the terms of use, everyone just clicks ok). It is a real problem. By the way, I also shared [a blogpost that I wrote on the subject a few years ago](https://www.digita.ai/news/2020/2/25/why-consent-is-flawed-and-what-organisations-can-do-about-it)
+* Matthieu: While I think this is all interesting/important, I'm not sure finding a solution to such a (social) problem is in scope of the authorization panel.
+* Elf: What about, we focus on the `acl:Control` problem? If you give someone access, we cannot control impersonation.
+* Matthieu: That's exactly what I'm talking about; there is no technical way to prevent social engineering (since it is based on trust). We will not *solve* this issue.
+* Elf: You still have a kind of delegated control (controlled impersonation). The notion of `acl:Control` may mislead the user into thinking that unless this is given/delegated, they cannot share that access.
+* Matthieu: Do you suggest that sharing access to a resource would never happen? You would just share read, write and append access, and not let other people share access further? Wouldn't a collaborative environment be just copies of copies of access?
+* Elf: You enable people to clearly delegate access. In this way, you can have clear (reportable, cf. infra: logs of who does what on whose behalf) chains. This does not have the same misleading aspect. You just need a specified way to do delegation.
+* Matthieu: How would the delegation chain show up in an access token for example?
+* Elf: In short, there would be 2 ways:
+    * Relying on back-channel (see https://github.com/solid/data-interoperability-panel/issues/222). In the end, there are some race conditions. In the end, the RS would have simple ACL rules on the resource.
+    * Relying on signatures and signature chains, using pushed claims to the AS: downstream signatures would be on the claim.
+* Matthieu: That doesn't necessarily take away the need for a Control mode. People should be able to set, e.g., rules of which issuer could access which resource, etc., on a Solid server. This more "standard" way of giving control seems to be a better way. Maybe on the ACL level you still want something specific.
+* Elf: There is an issue on ACP access, which would simply be access to the ACR itself. Only the AS should be able to set these, so we could configure this access (of the AS) on a higher level in the RS. So there is no need to set access on ACRs (at least not to respond to requests).
+* Matthieu: For me, this is more of a data modeling issue, but in the end we are on the same page.
+* Wouter: While I do agree that the questions about legally enforcing policies are not in the scope of the panel, is there a place where we could dive in the boundaries between the technical and legal aspect?
+* Elf: I'm not sure, but I'm also interested.
+* Wouter: Maybe we can look into that.
+* Tom: I've thought about that a lot in the past, and the goal in the panels is to provide something that is privacy compliant. It might be hard to enforce, but if we could at least providing adequate tooling for the willing, that would be great. Maybe a data-protection panel? It might not be an issue on the technical level, but on the user level.
+* Elf: Maybe we could start talking about this in the interop panel. It seems that the themes overlap. Access/Consent/Data grants are in the same space. I'd like to propose it as a next item on the interop panel.
+* Matthieu: I think maybe there *is* a technical aspect about it, i.e., qua data modeling what we should use (e.g., ODRL). Maybe in such a data-protection panel we could research and decide on such a common way to handle non-technologically enforceable rules.
+* Tom: I've also been working on that for the last few years. We need to distinguish giving access to data from giving consent to use data. Almost all organisations will process your data based on consent. Giving access to data is not the same as giving consent to use it. A company given consent can process your data. Giving access is sometimes less permissive. A company or a bank might be legally obliged to keep and process data about you regardless of your consent. In addition you have to keep in mind that these legal obligations are subject to change. Access and consent are related, but not the same. We should focus on access control, not on legalities.
+* Mathieu: Now that you mention it, these legal reasons will also differ from (legal) framework to framework.
+* Tom: Exactly, and Matthieu's consent should not be conflated with consent from a legal perspective.
+* Matthieu: When it comes from a user, we try to use "consent" to indicate "from the will of the user", but maybe "access" is a more neutral term.
+* Tom: Yes, for example, "permits" or "permission" could work, but I would avoid using the word "consent".
+* Wouter: I think last week in the interop panel, the difference between "access" and "consent" was mentioned. Sharing information in an "access consent" registry would provide a way for us to inform legal concerns.
+* Elf: The name "access consent" was mostly driven by the fact it's derived from the "consent screen" on the application. I'm open to renaming it. But if you look at the application, it can be broad enough to encompass data you have access to coming from different resource owners. It is setting a policy about data coming from different resource owners. But you cannot go beyond single storage. That's the kind of issue we address. It can issue data grants that are more granular and could output ACLs. https://github.com/solid/authorization-panel/discussions/281
+* Matthieu: I think you said you cannot give access to resources on multiple servers with WAC/ACP; I think this is not necessarily so. For example, in ACP, if you started to share policies and have one policy enforced on multiple servers, you could still have some cross-pod (global) policies.
+* Elf: Okay, I see that, how policies could be reused accross multiple pod servers.
+* Matthieu: Who should we talk to about a separate spec, or where else to discuss this (legal aspects)?
+* Elf: I think we need to be careful not to create too many panels, to keep the Solid specs compliant with each other. I'd say let's bring it up next Tuesday, and see where we go from there.
+* Elf: I was focusing on getting out of the "common access mode" questions. For example, to be Creating contained elements, separately from updating the description of elements in a container, or Deleting resources.
+* Wouter: I also raised an issue about how one could share partial access (delegate only my read access).
+* Elf: From the delegation I'm exploring, you could delegate read-only in a data-grant for example. The effective access delegated can be granular.
+* Matthieu: How much do you think this overlaps with Verifiable Credentials?
+* Elf: I think it depends. Here, something like a zero knowledge proof might be required. More thinking is required. There is another spec called ZCAP coming from the same group as VCs. I don't think VCs should be used for access. Do you have a specific use case required to VCs?
+* Matthieu: Not specifically, but it seems to me that the delegation of authority problem space that VC addresses sounds similar to the data-grant solution you talk about.
+
+
+
+#### Access Modes
+
+ACTION: Pavlik - compile pros/cons of Control Access mode, including delegation pattern
+ACTION: Pavlik - propose technically enforceable policies and legally enforceable ones