Minutes 2021-08-25

meetings/2021-08-25.md

@@ -0,0 +1,214 @@
+# 2021-08-25 Solid Authorization
+
+https://meet.jit.si/solid-authorization
+
+
+## Agenda
+
+* [Minutes 2021-08-18](https://github.com/solid/authorization-panel/pull/250)
+* [Delegation use case](https://github.com/solid/authorization-panel/pull/249)
+* Access Modes currently used by: WAC, ACP (5min)
+  * Creating new contained resources in the container - mode on container or members?
+  * Does Write or Append on container imply Create new contained resources
+* [Access Modes if Requesting Party is creator of the resource](https://solid.github.io/authorization-panel/authorization-ucr/#collection-readcreatedelete)
+* [ACP ready for review](https://github.com/solid/authorization-panel/pull/183) (2min)
+* Reliance on client interpreting IRIs (aka. `/` hierarchy): WAC, ACP (5min)
+
+## Present
+
+* Barath
+* Elf Pavlik
+* Henry Story
+* Matthieu Bosquet
+* Justin Bingham
+
+
+## Minutes
+
+### Access Modes currently used by: WAC, ACP
+
+Elf: I want to clarify how access modes are used by WAC and ACP as of today, especially how to create new resources in a container.
+There is some conversation in the spec that Ruben says if you are doing PUT to create you need Write and if you're doing PATCH, then you need Append.
+Is it WAC specific or is it ACP?
+See: https://gitter.im/solid/authorization-panel?at=611916173eec6d41d159b789
+
+Matthieu: From ACP perspective access modes don't matter. It matters in solid protocol, it's up to server to enforce them.
+
+Elf: You cannot just implement ACP, you need to implement it in Solid for it to be complete. The specification of the access modes is required. It is an ingredient.
+
+Matthieu: I don't think it is incomplete. It is the purpose of the Solid protocol to define which operations can be performed depending on granted access modes.
+
+Elf: What access modes would you need for resource access?
+
+Matthieu: Same as WAC.
+
+Elf: So you need the access modes to be defined in the spec.
+
+Matthieu: There is a part in the spec that says ACP doesn't define its own access modes.
+
+Elf: It seems like an elegant approach, maybe it needs clarification in the spec.
+
+Justin: In main protocol spec we need to have section on access modes that authorization systems support.
+The context for Pavlik raising this is that the current set of modes doesn't fullfil the use cases, it overloads capabilities of certain modes.
+For example, with write, you can create, delete, modify. But in some cases I want someone to only create and not delete.
+Currently the modes are not granular enough.
+We could over-permission an agent and they might create havock as a result.
+If this isn't a what mode does ACP use?
+We need to look at the modes the protocol is using so that we can always provide the most specific amount of privilege.
+
+Barath: It's important to make sure the types of modes and agents is clear.
+For example, authenticated agent is meaningless.
+
+Matthieu: It becomes meaningful only when you combine it with for example the issuer.
+
+Barath: I agree, but we need to clear the meaningless examples where it's not and gives a false sense of security.
+
+Henry: In WAC, you can create subclasses of agent. The authenticated agent example is not here for security, it is to show that a system works.
+The agent class relation where you describe people under the age of 18 you can move slowly towards attribute based access control.
+Seeing those as logic you can start understanding how powerful they are.
+I guess it is good to be flexible with access modes. It is a bit weird that the protocol would have anything to do on this.
+I have an issue to say that WAC control could be removed. (see [#94 on WAC](https://github.com/solid/web-access-control-spec/issues/94))
+I'm happy that we try to be backward compatible as far as possible, but relevant access modes should be defined by us, or at least we should have some serious input into what those are.
+We could try to see which modes are required.
+
+Justin: The modes don't go in the authorization system, they have to go in the protocol document. I don't care where they go, but I agree that it sounds elegant. The modes that Solid supports will need to go in the main SOlid protocol document anyway.
+The use cases have been written with the same modes I have in mind. That is, write doesn't entail delete and the use cases are specific about it.
+Today, with write on a container, you can add; remove; modify... In terms of backwards compatibility, there is a backward compatible path where the larger conflated permissions still exist, but you have more granular modes added.
+The protocol doesn't have to force modes to be so wide.
+
+Barath: It sounds like what you're saying is pretty aligned with what ACP is saying.
+
+Justin: What I want is nothing fancy. Just having granular operations aligning to the use cases.
+We wanted the limitations to be highlighted. I'm confident that ACP is aligned with that.
+We could still have ACP with this mega write access.
+
+Matthieu: There is a specific issue on GitHub about creating more granular access modes
+
+
+...: Access modes need to be defined on the protocol level. Protocol describes how to read and write resources, it doesn't make sense to me to define access modes separately. If modes are defined outside of protocol they would still need to be matched to how protocol works.
+
+Henry: In the evaluation section we would need to take one of those use cases and show what is required in terms of modes. 
+Perhaps there is no problem or perhaps there is. I.e. perhaps one can implement those use cases using WAC modes as they are. And perhaps we do need something more fine grained. 
+
+Matthieu: I'll add an action for doing this.
+
+Justin: Maybe start with those:
+
+    https://solid.github.io/authorization-panel/authorization-ucr/#req-collections
+    https://solid.github.io/authorization-panel/authorization-ucr/#req-resources
+
+Elf: I agree that protocol is a good place to define access modes. The access modes translating to methods on the request.
+In ACP if we say the protocol defines the access modes and we talk about creating a new resource, then use POST on new container access mode x is required.
+
+Matthieu: How does that differ from the rest?
+
+Elf: With Put, you create something new, what happens?
+
+Matthieu: ACRs are server managed, when you create a new resource, the server is expected to create the ACR.
+
+Elf: What would be the access modes present in apply members?
+Create a resource with PUT or PATCH, what would be the created access modes?
+
+Matthieu: The newly created resources need to include all inherited access controls.
+That means there is one predicate linking an ACR to access controls. And another predicate - member access control.
+
+Elf: Would you consider adding this description on one of the use cases on PUT to show how it works.
+Currently, the protocol says servers have to support WAC. What is the process to adjust that?
+If it is externalised and it's a different spec how do we proceed?
+
+Matthieu: We may need a standard interface to link resource to access control resource, maybe even an endpoint which would for resource provide access modes.
+
+Justin: I don't think there is a well established voice as to how to deal with this from the protocol spec's perspective.
+I can say it is not good for implementers to have to implement multiple authorization systems in their systems and there are shortcommings in WAC that make it somewhat insecure.
+ACP is something we'll get through and review the draft and it has the strongest potential right now to succeed.
+We're gonna have to determine at the protocol level whether to tell people to implement two systems and that might mean giving preference for one system over the other.
+I think in a perfect world, what you describe Matthieu having an interface between the authorization system and Solid, would be great, but WAC can't do everything that ACP can do in its current state either. 
+I think that at the protocol level we can't even get to this discussion until there is a proposed alternative to WAC.
+To have a proposed alternative, we need a draft spec and an implementation that is open and can be evaluated to have those discussions.
+It is not like we're just waiting with the answer.
+We're stuck until we have a candidate.
+
+Barath: I think Matthieu, you're pretty close to that and it will be good to get there soon.
+...: I agree with Justin, supporting two at the same time might be difficult to require from implementers.
+
+Henry: I would argue that there is not two options but three 1. doing WAC; 2. ACP; 3. Extending WAC
+It would be good to prove me wrong if extending WAC is impossible. I am not yet convinced there is a need to move to something completely different.
+
+Justin: What we need to have the discussion at the protocol level is proposed set of draft specs and discuss it at the protocol level.
+If another proposal is coming together, then we could start discussing that.
+But it would 
+
+Henry: I would be in favour of incremental improvements. And we're getting closer to that. Do we need Control? Do we need every resource to have its own ACR> When you think about it carefully enough, then we can gain consensus without breaking with the previous one, as I suggest in the [WAC issue 99: Effective ACL Resource discovery requires 2n+1 request](https://github.com/solid/web-access-control-spec/issues/99).
+
+Elf: I completely agree with Justin that we need an editor's draft and hopefully we can merge ACP soon.
+WAC+ is not ready, it would be better if there is a 
+Are there
+
+Barath: What does it mean for an authorization thing to be client side?
+
+Elf: The server creates the default ACR and then you need a client library to actually create policies.
+
+Barath: You're refering to a client side library that gives you convenience to edit the access controls.
+
+Elf: Yes.
+
+Justin: [There is the Inrupt SDK](https://docs.inrupt.com/developer-tools/javascript/client-libraries/tutorial/manage-acp/). Maybe the current draft spec has some modifications, but that should be pretty good. 
+
+Matthieu: It's pretty close.
+
+Henry: We should have TBL come here and suggest whether we need a big change or small incremental ones;
+
+Matthieu: I think that the most important part is defining common interface between solid server and authorization system. Deployment should be able to run authorization system as part of the server or as external service.
+
+
+### ACP ready for review
+
+Matthieu: ACP is ready for review and [can be conveniently seen at htmlpreview.github.io](https://htmlpreview.github.io/?https://github.com/solid/authorization-panel/blob/initial-acp-spec/proposals/acp-specification/index.html).
+The proposal is missing the bibliography section but that doesn't affect the spec. I also want to add a primer but it would be a separate document and I think we can start discussing the proposal in its current form nonetheless.
+
+...: It also is missing test suite.
+
+Henry: We should have a way to form consensus about need for specific modes. Say COntrol is not needed or Delete is required. Perhaps we should get the other people building servers to join. There's really only the open source and the Java one.
+
+Matthieu: I think you're right Henry, it would be great if this group could come through with a justification for required access modes and feedback to the protocol.
+
+Justin: +1
+
+Elf: +1 on proposing an access modes section to the protocol panel.
+
+Elf: I think we need to merge ACP before even primer.
+And with that draft, we can have better arguments for specific modes.
+
+Justin: +1
+What's gonna come in ACP proposal, there's not gonna be modes which I completely agree.
+We may need a draft spec that could adendum to the main spec speicfying modes and articulate things in terms of a standard interface.
+That may be something we need to take in parallel.
+Minimum modes, interface that makes sense and submit to the spec.
+It's not just ACP or WAC+.
+It's access modes recognised as insuficient.
+And that piece needs to be submitted.
+
+Henry: When does the spec group meet?
+
+Justin: Every week on Tuesday.
+Core protocol spec. It is before the interop panel.
+The way it is configured is editors only. But for a given topic like this we can invite people to talk about those items. I can talk to the other editors about the open item agendas.
+Now it is Tuesday 8am ET (2PM central euro/1PM UK).
+We need a proposal to review in order to discuss it specifically in a meeting with the issue clearly formulated ahead of time.
+
+Henry: Does WAC also have an editor's meeting? I'm wondering if we're hanging out in a group here and things are decided elsewhere.
+
+Justin:We're not discussing that in protocol.
+
+Barath: WAC was classified a long time ago.
+
+Justin: Yes, for the authorization systems in Solid, this is the correct forum.
+
+
+## Actions
+
+* Matthieu or Henry to start an evaluation of modes required for a couple of relevant use cases. Maybe Justin to link to the straight requirements. Justin suggests:
+    * https://solid.github.io/authorization-panel/authorization-ucr/#req-collections
+    * https://solid.github.io/authorization-panel/authorization-ucr/#req-resources
+* Matthieu to create an ACP description of how resource creation with PUT would work in terms of initiating a new ACR.
+