---
# System prepended metadata

title: 2020-07-01 Authorization Panel

---

# 2020-07-01 Authorization Panel


# Agenda

* [Handle User-Focused Client Constraining Access Control via the ACL #68](https://github.com/solid/authorization-and-access-control-panel/issues/68)
* Talk about WAC spec in context of Solid vs alternative approaches to using the ACL vocab with own mechanism ( https://github.com/solid/web-access-control-spec/issues/51#issuecomment-496465059 )
* Use Cases and Requirements
* [Next week agenda](https://hackmd.io/P3YdZ9RGT2OZo44xPhOVNA)

# Attendees

* Justin B
* Jackson M
* Sarven C
* Henry S
* Dmitri Z

# Minutes

### Discussing: https://github.com/solid/authorization-and-access-control-panel/issues/68

JM: Prevent clients from being able to access certain data. Proposal to do this by extending WAC. Depends on the existence of an authorization agent that can manage ACLs for someone.
- Adds an acl:Client mode to the ACL document. This is an ACL control for clients. This mode allows for the addition of clients (acl:apps) that can access a document, not agents.

SC: Consider looking at `acl:delegates`

HS: 1. I like the idea of extending the wACLs 
    2. The use case of limiting apps is a good one
    3. One would need to compare it to other methods of getting the same effect. Where this proposal is server side, an equivalent way of doing this would be client side. It seems to me that the responsibility here is on the client, so this is where the control and responsibility should lie. The [Launcher App](https://github.com/bblfish/LauncherApp/wiki/Where-To%3F) approach is a client side proposal to limit from the client which apps can access to a resource. Note: These proposals are not exclusive. 
    
JB: Comes down to whether we want to add this additional mode, and do we get into a pattern where we have many more modes (slippery slope)? Can same be accomplished with current modes and additional context in a given statement?

HS: If the acl gives Control to a client and it can edit in order to restrict access,
then it would make sense to add a subclass of foaf:Agent, call if foaf:Persona, that would be a person using an agent. We can find such ideas already in the 1991 famous paper [A Calculus for Access Control in Distributed Systems](https://link.springer.com/chapter/10.1007/3-540-46766-1_1) which has evolved a lot. You'll find the notion of SpeaksFor there, which seems similar to such a Persona. I would need to think about it more. Also see [Logic in Access Control (Tutorial Notes)](https://link.springer.com/chapter/10.1007/978-3-642-03829-7_5)

### Talk about WAC spec in context of Solid vs alternative approaches to using the ACL vocab with own mechanism ( https://github.com/solid/web-access-control-spec/issues/51#issuecomment-496465059 )

SC: Concern that Solid's WAC implementation might conflict and/or fragment with other WAC implementations that use common vocabularies with different schemes. Can we take the best parts of all of these and publish one document?

JB: Would worry about trying to bring together different schemes that function differently to do different things but share same vocab. Are these really flavors of WAC or different things that use same vocab?

SC: It may not be appropriate to talk about WAC generally, but Solid-WAC.
    - Can solid specific acl terms get added to current acl ns
    
HS: If ACLs are mostly private this should not be so controversial

JB: Should we incorporate non-Solid use cases into our UCR initiatives?

