Minutes 2021-08-25

meetings/2021-08-25.md

@@ -0,0 +1,220 @@
+# 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 where Ruben says if you are doing `PUT` (or `PATCH`) to create, you need `Write`, then you need `Append`.
+Is it WAC specific, or is it ACP specific?
+See: https://gitter.im/solid/authorization-panel?at=611916173eec6d41d159b789
+
+Matthieu: From ACPs perspective, access modes don't matter. It matters in the Solid protocol: it is up to server to enforce them.
+
+Elf: So ACP depends on another spec to be completed. 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 fulfill 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 is important to make sure the types of modes and agent classes are clear.
+For example, `wac:AuthenticatedAgent` is meaningless in terms of security.
+Anyone can easily create an identity at the turn of a hat.
+
+Matthieu: It becomes meaningful only when you combine it with, for example, requirements on the issuer.
+
+Barath: I agree, but we need to clarify the examples as they may give a false sense of security.
+
+Henry: `wac:AuthenticatedAgent` is especially important in that it shows us how 
+we can use `wac:agentClass` as an extension point. 
+It shows us that we can use subclasses of `foaf:Agent` as the range of `wac:agentClass`. 
+The `wac:AuthenticatedAgent` class is here not so much for security as to show us how that works. 
+We can thus use description Logic (OWL is a description logic) to create new classes of agents that have certain attributes, such as people under the age of 18. This will enable us to move towards attribute-based access control.
+We can create any description, including for example, as Matthieu was saying, describing Authenticated Agents who have a
+Credential signed by some set of authorities. 
+
+   ... On access modes, I guess it is good to be flexible with them. But it is a bit weird that the protocol is the one
+   defining these. I am not against, but we clearly have a lot to say on the issue: for example, that `wac:Control` is not needed. (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 dealing with modes and show how WAC, WAC+, and ACP 
+can implement them.  Perhaps there is no problem, and the use cases can be implemented with the modes as is. 
+Or perhaps there is a problem, and we do need something more fine grained. 
+
+Matthieu: I'll add an action for doing this.
+
+Justin: Maybe start with these:
+
+* 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 translate 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 using `POST` on new container requires access mode _x_.
+
+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 for `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 a resource to its access control resource, maybe even an endpoint which would provide access modes for a given resource.
+
+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 shortcomings in WAC that make it somewhat insecure.
+ACP is something we'll get through and review the draft; 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 are 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. The advantage of incremental extension is that there should be no or very little switching cost.
+
+Justin: We need to discuss the proposed set of draft specs at the protocol level.
+If another proposal is coming together, then we could start discussing that.
+But it would 
+
+Henry: I would be in favor of incremental improvements. And we're getting closer to that. Do we need `wac:Control`? Do we need every resource to have its own ACR as ACP suggests? I think we can find, for example, a good compromise there, 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). 
+That shows that with 2 Link relations, current servers can keep being deployed, and ones that would like ACP 
+functionality can gain them, too.
+
+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 were a draft.
+
+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 be an addendum to the main spec, specifying modes and articulating 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 recognized as insufficient.
+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.
+It is currently 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.
+