---
# System prepended metadata

title: Solid Authorization Panel

---

# Solid Authorization Panel
November 11th, 2020

# Present
- HenryS
- ePavlik
- MartynasJ
- DmitriZ
- MatthieuB
- JustinB
- MaxL: Max Leonard 
- JoshC
- EmmetT
- ThomasP
- Sarven

# Agenda

- Context:
   Last Thursday At Solid World ACP was presented as
  being shipped for the Enterprise Server of Inrupt.
  What does this entail for the role of this Panel?
   
- Proposals
    - Emmet T - Access Control Policies - see https://github.com/solid/authorization-panel/blob/master/proposals/acp/index.md
- Issues
    - elf Pavlik - [UC: 2.5.2. Limiting application access while not acting as resource controller](https://solid.github.io/authorization-panel/wac-ucr/#uc-client-constraints)
      - how does it impact Authentication spec [Issue: Consider IdP to issue Identity Verifiable Credential rather than global access token #60](https://github.com/solid/authentication-panel/issues/60)
      - how does it leverage App Authorization from Interop Panel [PerformChart example from UC above](https://deploy-preview-70--data-interoperability-panel.netlify.app/primer/#performchartexample)

## Minutes

### Access Control Policies 

See https://github.com/solid/authorization-panel/blob/master/proposals/acp/index.md

HS: How does ACP being shipped with ESS affect the role of the panel?

ET: Current instantiation - proprietary way of doing access control that was needed for current requirements. Want it or a derivative to become a standard, as moved through the panel, and then would refactor their product to conform to the eventual outcome (assuming it is adopted).

EP: Use cases for Normal, Protected, Locked

ET: In collaborative scenarios with delegated control, the trust is not always binary. Trust someone to manage permissions for a certain part of the pod, but you might have pre-conditions saying "but these agents/groups should never have permission". Need a way to override or enforce this despite having delegated control.

HS: Is the ontology published somewhere? 

EP: How are "inherited" statements / rules differentiated between ones that are manually created?

ET: In the implementation the server is responsible for maintaining this knowledge

ET: How can this be augmented to be more clear?

### Action Items

- ACP: Use cases for inheritance
- ACP: Use cases related to Protected / Locked scenarios
- ACP: Where is the ontology published (now vs. permanent)
- ACP: How can the documentation be updated to be more clear?