Minutes 2021-07-21

meetings/2021-07-21.md

@@ -0,0 +1,176 @@
+# 2021-07-21 Solid Authorization
+
+https://meet.jit.si/solid-authorization
+
+
+## Agenda
+
+* Minutes - https://github.com/solid/authorization-panel/pull/238
+* UC1 - https://github.com/solid/authorization-panel/pull/215
+* UC3 - https://github.com/solid/authorization-panel/pull/216
+* Closing outdated UCR issues?
+    * #87 - https://github.com/solid/authorization-panel/issues/87
+    * #89 - https://github.com/solid/authorization-panel/issues/89
+* Transfer of issue 191 - https://github.com/solid/authorization-panel/issues/191
+
+## Present
+
+* Henry Story
+* Justin Bingham
+* Elf Pavlik
+* Matthieu B
+
+
+## Minutes
+
+### ACP UC3
+
+Henry: I don't think there is a way to build Solid without allowing global read to ACRs. There has to be some document that tells you how to authenticate. Now, it is true that there is a privacy problem with people putting all access control statements in one ACL (a problem that the current WAC `:default` behavior leads to) as there is no way then to set access control rules on the rules. But that problem can be made to disappear, as shown in [comment on issue 189](https://github.com/solid/authorization-panel/issues/189#issuecomment-797638239). If the client cannot know what the rules are, it cannot know how to access a resource. This would then be a major missing piece for Solid to work at all.  If we don't see this as working, we would need to invent a whole new access control system. 
+
+But we are getting there. This is why it is important to go through those Use Cases.
+I don't think we want to go through all Use Cases though, as that will take too much time. They were developed before we went through this process. 
+I don't see that the [latest comment on UC3](https://github.com/solid/authorization-panel/pull/216#discussion_r673945084) is a problem; it is up to Elf to put a proposition forward to deal with credentials requirement discovery.
+
+The default is that you have to read the access control. (EDIT: I later add some nuance to this; this is not to say that the ACL has to by default have public access — it may be important to explicitly state so)
+What happens if you don't get access to the ACL? You don't know how to authenticate; therefore, you don't have access.  You would be left with guessing, which is not acceptable for privacy reasons on the client.
+
+Matthieu: But it is a security issue to have ACRs readable publicly by default.
+
+Henry: It depends how it is done. 
+It can be done right, and in my view, far from being an exceptional case, it is going to be the majority of cases that do this.
+
+Justin: I think we're conflating a real problem that needs to be solved, which is understanding what a given agent has access to.  An access control system should just be telling us whether you have access to something or not. But there are other out-of-band ways to give agents a list of what they have access to.
+There aren't patterns to tell an agent what they have access to.
+I personally don't believe that the best way to deliver that information is through the ACL resources. I'm happy to be proven wrong.
+I see it as a separate type of flow.
+In other areas which aren't Solid specific, but if your control rules are set up (OAuth, Firewalls, ...).
+I'm wondering what is the minimum amount that people need to know.
+We have precedent with WAC-ALLOW in Solid.
+Using a follow your nose mechanism (that is, requiring the dereferencing of access control resources for clients to understand access requirements) would be pretty problematic, because you don't want to potentially leak information that should be private.
+
+Matthieu: There are two problems here:
+1. how does an agent know all the resources it has access to
+2. how does an agent know which credentials to present to access a resource
+
+Justin: Absolutely, application workflows are much richer than access to this or that. Pavlik and I specifically worked on it a lot with the interop work we've been doing. So we might have a more acute feeling for what is required.
+
+Elf: We have to make a pragmatic approach towards how to approach those UCs. For ACP, my understanding is that the access control resource is not accessible unless there is an access control rule. 
+
+Matthieu: It was also my understanding for WAC (not readable by default).
+Maybe raise one more issue to make it explicit whether WAC resources are accessible by default.
+
+Elf: Even though ACP could make it accessible to the public. Why is it required for this use case?
+Let's not make it required for this use case.
+
+Matthieu: I see here three questions that I would like
+
+Henry: I need to nuance my previous statement: Unless the ACL states that it is publicly readable, it should not be readable.
+That is a limitation of WAC currently that doesn't allow just public read to ACLs. (or even anything other than access to the controller)
+
+Matthieu: There is a proposal to extend access control modes including `ControlRead`.
+
+Henry: Link me to it. ACP does something like that too. And I had a proposal for [ACRs on ACRs](https://github.com/solid/authorization-panel/issues/189). It would be good to contrast and compare them.
+
+Matthieu: I think I agree. If we were to adopt extended access modes, maybe we wouldn't have to use so many different predicates to apply policies in ACP.
+
+Henry: I'll try to review that for next week.
+We have a use case for shopping and buying music. It seems that, in that case, everybody should know the price and that would not create a privacy problem. We could have an access control rule saying that, on proof of payment, you can download this music.
+
+Matthieu: You mean that the access control would allow you to infer that in order to read the music, you need to show that you need to pay for something.
+
+Henry: yes, we even have a use case for that [Conditional Access by Payment](https://solid.github.io/authorization-panel/authorization-ucr/#conditional-payment). That is the same thing for say being a university member.
+To get back to our use case: I am happy to just have the resource describing the Group Bob & Alice be private to them. The access control rule can link to the group, but only they know they are part of it. I can make a PR for that.
+
+Matthieu: This sounds like a classic verifiable credential/key-based access where you just need to prove what set you pertain to.
+
+
+### PR Workflow
+
+Pavlik: There is a bit of a problem regarding who works on pull requests and who has to approve them. But it's pretty clear that ACP would be Matthieu, WAC Sarven, WAC+ Henry, but it would be good to have 1 person leading the proposal.
+
+Matthieu: That sounds good, but what do you think would be necessary to make things clearer?
+
+Henry: I think that's more or less what we've been doing.
+
+Pavlik: We could have separate PRs for separate proposals.
+
+Matthieu: I would prefer keeping a PR per use case. I think the current flow does work well to compare the implementation details.
+
+Justin: +1 Pavlik's point or the spirit of it.
+I feel like we needed the specs yesterday and I can't build what I want with the current state of WAC.
+We need to optimize our workflow to get the proposal to a finished state; we need to get there fast.
+The ecosystem needs us to get to a better more robust access control system sooner rather than later.
+
+Henry: I agree that WAC got stuck where it was for 5 to 6 years.
+At least now, the simple Use Cases help us show the limitations of WAC and get feedback, e.g., from Sarven.
+Comparing it to ACP is helping us tweak things a little bit.
+We write out detail by detail the things and figure out problems as we go along.
+We seem to have, for example, noticed a problem with ACP and WAC both having to copy data. This allows us to figure out the problems and disadvantages of each, how to solve them, and perhaps even end up with one system.
+We have not been putting enough time in it, which is why it's very slow. 
+We had the vacations slowing us down right now, and before that we spent 3 weeks discussing [UMA](https://github.com/solid/authorization-panel/blob/main/meetings/2021-06-09.md).
+I suggest we commit this PR and continue with new PRs to continue building on it.
+Matthieu reminded me right before Elf and Justin joined, that [two weeks ago](https://github.com/solid/authorization-panel/commit/e0b77c5976056c42ab7018ade0e766c1fec78d0b) we already agreed to merge and incrementally improve the UC3 PR.
+
+WAC is very easy to implement which is good at the beginning. It has been advertised as a good decentralised access control solution, and it is if we tackle a few issues so that it meets expectations.
+
+Justin: It is a way and beneficial.
+But the best way is to have something in the field and get it used in the field.
+We need value from real, "in the field" implementations and use.
+We need to see value from there.
+That's an essential part of maturing specs and getting them to completion to have something out there that is close to completion.
+I wanna ideally try to get there.
+
+Henry: That's what I was doing 7 years ago in a startup I was with. I had built a server and clients . But the startup did not work out. Then it took a long time because something got stuck at MIT.
+
+If you look at this UC3 PR, then you can see that WAC+ import solves a lot of issues.
+And it might help solve things on the ACP side too.
+It helps you avoid copying lots of data around.
+And answers many questions, such as "If you change the root ACR, do changes take effect everywhere else?...
+
+Matthieu: I agree with Henry. I think it is problematic that some fundamental issues have not been formulated clearly in the past and that the fact that we're doing it proves that we're doing something right.
+
+Justin: Yes. More than anything, I just want to understand how do we optimize what we have left to do?
+How do we get back from implementation?
+
+Henry: Maybe we need 1 or 1.5 days a week for Matthieu and I to move along.
+These UC cases are very much like an implementation. It is backed by experience.
+I agree we need to move faster on this.
+
+Matthieu: I agree with Henry's assessment that we need more time aside mostly. There was also a problem of fluency and getting up to speed with the entire Solid ecosystem and state of the discussion on my side as well. But with my current understanding of WAC and Solid, we seem to move along much faster. I also agree that we want to get to implementation feedback as early as possible, but that the use cases are adequately filling a bit of that space for now.
+
+Justin: Absolutely.
+
+Pavlik: Yes. Another part of my suggestion is not expecting someone else from commenting on your PRs to make progress.
+
+Matthieu: Yes, you're perfectly right, that has been problematic in the past, I'll try to adjust to make faster progress and focus on important issues and questions during the panel.
+
+Henry: Adjusting expectations of comments to move along faster sounds good. We'll keep it in check so that it doesn't get out of control.
+Let's not lose the benefit of questions and feedback.
+
+Matthieu: +1
+
+### Closing outdated UCR issues
+
+Justin: +1
+
+Henry: I'll follow up on it on GitHub
+
+### Transfer of issue 191
+
+Justin: I might have permission to do it.
+
+Matthieu: I'll ask Sarven otherwise.
+
+
+## Actions
+
+* Matthieu to submit UC0 on effective access control resource discovery.
+* Matthieu to create issues:
+    * How does an agent know all the resources it has access to?
+    * How can an agent discover which credentials are required to access a resource?
+    * Using extended access modes (control read, control write...) instead of `apply` + `access` predicates in ACP.
+* Matthieu to clarify whether WAC's ACLs are private by default.
+* Matthieu to point Henry to the extended access control modes issue/proposal and Henry to review it.
+* Henry and Matthieu to bootstrap the use case on privacy.
+* Henry to follow up on GitHub on outdated issues #87 and #89
+* Matthieu to follow up on transfer of https://github.com/solid/authorization-panel/issues/191