# Solid Authorization Panel
October 28th, 2020

## Present

- Justin B
- Martynas J
- Sarven C
- Eric P
- Henry S
- Dmitri Z
- Josh C
- Emmet T
- Matthieu B

## Agenda

- Approach to process authorization proposals
- Authorization proposal - ACP from Emmet Townsend / Inrupt

## Minutes

### How to process proposals

JB: As we now have proposals coming in, we'll need to work out the most constructive way to process and iterate upon them

SC: Important to understand deltas between WAC and new proposals. We can use the ACP proposal to inform how to process new proposals afterwards.

### ACP from Emmet

ET: ACP = Access Control Policies. Still resource centric. Each resource has access control metadata created for it. Lifecycle is managed by the server, not the client (same as WAC).

ET: Each ACR lets you specify policies. Can apply to resource itself, or members of that resource (if the resource is a container).

ET: ACR can have multiple policies. Any policy specifies the modes of access that are allowed, and what is denied. (Provides negatiion). Deny can override an allow from higher in the tree.

ET: Figuring out who the policy applies to are rules associated with a policy. Can also do things like apply all, some, no rules. Rules give extention points that would allow you to extend and do more things in the future like possesion of VC, time based, etc.

ET: When a policy is created or added to ACR for a container, and has applyMembers - the server is responsible for propagating those policies to those children resources. If a policy is removed from an ACR, the server is responsible for taking them away. When doing policy enforcement, you're only looking at the ACR associated with the resource. Every resource has an ACR resource.

EP: Do you need to propagate / pre-compile, or is that just for performance.

ET: You don't have to, but we do it that way for performance.

EP: Negative extensions - do you imagine cases where an older implementation migt let someone in because it didn't understand an extension a newer one would.

ET: Provides ability for forced inheritance

ET: Provides ability to use forced inheritance to identify an "owner" that cannot be locked out.

EP: In proposed text identify delta from WAC and/or why an alternative

SC: Need to have the discussion about whether a server would use WAC+ACP vs. WAC-only / ACP-only in the future.

## Action Item

- Add Emmet to github team for authz-panel - DONE
- Emmet to post proposal text into panel ahead of next session