# W3C Solid Community Group: Authorization Panel

* Date: 2021-11-24T14:00:00Z
* Call: https://meet.jit.si/solid-authorization
* Chat: https://gitter.im/solid/authorization-panel
* Repository: https://github.com/solid/authorization-panel

## Present
* e Pavlik
* Henry S
* Matthieu B
* Barath
* Justin B

---

## 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
* Elf Pavlik - makes PR and creates next week pad

---

## Topics

### Previous meeting minutes

Merged :white_check_mark:

### ACP Draft design flaw

URL: [solid/authorization-panel#277](https://github.com/solid/authorization-panel/issues/277).

* Justin: Let's start with the design flaw.
* ...: I think that I wanna start with the comment we saw from Aaron that this change may create a problem with existing implemetnations. I just want to start acknowledging that my work/organisation don't really have this issue. but Aaron brings up that the proposed adjustment is going to break some existing client/server implementations that currently use ACP (on pod spaces with ESS). Anytime there is potential for breakage, we should keep that in mind.
* ...: So how serious of an impact do you think it might have on any existing user base? If people use Pod Spaces which is free do we have to keep that in mind? When you're a bit ahead of the spec, sometimes, this can happen and it's not a reason to not make the spec as good as we can.
* ...: But that comment made me realise that it could affect real users (sorry it's not substantial but I wanted to bring it up).
* Henry: Good point. That makes me wonder who is implementing what... Matthieu and Aaron? Anyone else? What is the size? That would be useful to know.
* Justin: I don't know. I think it mostly affects Pod Spaces.
* Matthieu:F I don't have numbers, and don't know what the current impact of the such a change would be. But the change Aaron is talking about is changing `acp:apply` to `acp:policy` (? is that it?) One could deprecate `acp:apply` before moving to `acp:policy`. The big problem is not in the naming but in giving up `acp:access`. But the problems of `acp:access` is big enough to make the change worthwhile.
* Barath: It seems like a simple renaming, is it a matter of search and replace? If that is what needs to be changed it does seem minor...
* Matthieu: It might be a bit more than just a search and replace, but I don't think it is a particularly challenging migration (renaming of `acp:apply`). The dropping of `acp:access` is more challenging, but in substance I believe is justified.
* Henry: It's interesting your question Barath, because as you say in the old days of the semantic web, that's really what it amounted to. And it really shows why inferencing is really important. Say with inferencing, you'd just add a rule to your client or server that the new predicate is equivalent and you have a transition.
* Pavlik: I think that most people don't implement code with inferencing built in. I doubt if Aaron's implementation does it. I don't think yours Matthieu does.
* Matthieu: For me the problem is inferencing in JS, on the other hand Java for example has really good support for it.
* Henry: For example we have vcard and foaf on the web. A client may want to use both. If it doesn't it is restricted just to part of the data. Of course you can start by hardcoding the inferencing by hand. The people who invented the semantic web were developing common sense reasoning for computers (billion dollars projects called [CYC](https://en.wikipedia.org/wiki/Cyc)), they already had 20 years of experience with it and it's why they managed to distill it into those nice elements that are usable on the Web. I thought it's worth mentioning why it's done.
* Matthieu: I think hard-coding inferencing is a good way to start with. Justin do you have comments about the substance?
* Justin: I like the simplification and I agree that it is source of confusion. Any time in an authz system you can remove things, you reduce the opportunity for bad authz that doesn't do what the user expects. So generally I'm very much in favour of the simplification, but I'd like to take more time going through the feedback. Make sure I keep all that in mind. But TLDR; I think the simplification is nice. The bit I mentionned at the front is not necessarily something that affects me but may affect others, so I'd like to hear more context about how others might be affected. It feels like not such a hard migration path. But migrations are migrations. But hearing from a purely draft standpoint is good.
* Henry: It seems to me that the simplification is useful. I personally got stuck on that aspect and having the simplification makes it clearer. It also seems compatible with ACR on ACR so it sounds good to me.
* Matthieu: One more thing that might be worth mentioning is that I think we can and should align on the access modes and if everyone agrees that we need ControlRead, we can push it on the Solid Protocol level as entailing specific operations.
* Pavlik: I have a question on auxiliary resources. I understand that only aux resources have a control on them. Is there a case on controlling an
* If we say there is a special access mode that refers to an auxiliary resource. It sounds to me like this approach is not using ACR on auxiliary resource. You would still need that path.
* Matthieu: Are you asking if we have a way currently in Solid to define ACRs on ACRs?
* Pavlik: Say you have controlRead on resource A, then you have a custom access mode to target the ACR. It doesn't apply to resource A it applies to the ACR of resource A.
* Matthieu: My short answer is that it is not up to ACP to define the mechanism you are proposing. ACP has a simple extension point, which is access modes. Those access modes are not defined by ACP but by the protocol. The Solid Protocol says that in order to be able to edit an auxiliary resource you need an access mode acl:Control. So solid says you need ACL control to edit the auxiliary resource.
* Barath: Can you be in a situation where your permissions would allow you to delete a resource but not its auxiliary control resource?
* Matthieu: First, That is in my opinion something that the SOlid Protocol should define precisely. Moreover, I think in order to delete a resource as defined in the Solid Protocol currently you need acl:Control on both the resource and its container. So short answer, it should not be possible.
* Henry: There is actually quite a few other good things that can happen from this change. Let me think... I think what Matthieu is saying is that one could open another use case for defining ACLs on ACLs rather than control. I think that someone was arguing giving access control to sub-parts of a graph. Even though it wasn't mentionned.
* Matthieu: I could have a go at describing this. This change highlights the difference between a Solid Resource which is a document and resources as defined by RDF (whether just part of a representation, dereferenceable via 200 or 303)...
* Henry: From the client's perspective, it can follow links and arrive on an ACR. From a client's perspective there is no reason why you should differentiate between an ACL and another resource. This is why you should be able to define that every single resource on the web has an access control rule. So we're just defining an ontology that defines that.
* Elf: Why couldn't we just use the Read control mode instead of ControlRead.
* Henry: It's a legacy.
* Elf: But at this time we just use control read to say it applies to the auxiliary resource. If we use control read we don't target the acr, we target the resource that ACR is auxiliary of. Do you see the difference?
* Henry: That's why control is weird. You only need read and write. The client needs a way to define that. And it is part of another proposal, not the one Matthieu is putting forward. All you would have to do is follow the link header and it could be the same resource.
* Elf: If you have access control for the resource and sometimes by the acr.
* Matthieu: My argument is to say that this needs to be defined at solid protocol level. ACP gives a confusing way to define access control over access control resource. What you are described is possible as of today.
* Barath: is the discussion about what is syntatically possible and what is semantically possible.
* Henry: It's good progress. I think it is good that we bring up the ACRs on ACRs point. If you think about it, the complexity is quite big. You have default rules for access control resources.

### Agent + Client matchers in ACP

URL: https://github.com/solid/authorization-panel/pull/278

RESOLUTION: text

ACTION: text