---
# System prepended metadata

title: 2020-06-24 Authorization Panel

---

# 2020-06-24 Authorization Panel

## Agenda

* Discuss approach to populate use cases and requirements
* [Handle User-Focused Client Constraining Access Control via the ACL #68](https://github.com/solid/authorization-and-access-control-panel/issues/68)
* Proposed initiatives that weren't voted on in last session
* [Reorganize panel #76](https://github.com/solid/authorization-panel/pull/76)
* [Next week agenda](https://hackmd.io/MM8lrTvHTRyS37NobicY5w)
    * Add https://github.com/solid/specification/issues/183

## Present

* Justin Bingham
* Dmitri Zagidulin
* Sarven Capadisli
* Jackson Morgan
* elf Pavlik
* Henry Story

## Minutes

### [Reorganize panel #76](https://github.com/solid/authorization-panel/pull/76)
- JM+, EP+

### Discuss approach to populate use cases and requirements

JB: In interop panel we work on template for use cases and requirements
JB: WAC it will be separate document, should it have it's own UCR document? Authorization has so many variations, going into all those cases may take over all the UCR document.
SC: We have an issue in specifications repo that each spec should have their own UCR document. For now what we discuss seems all solid centric, I think we can keep those use cases in one document.
HS: Have UC doc point to the bigger (e.g. Solid UC Doc)
EP: Propose focusing on one UCR document for Solid
DZ: Wants to bring WAC from Solid as an authz candidate to SDS WG

Standalone document: DZ+1, JB+1, HS+1, EP-0, JM0, SC+1(*)

SC - *Any new document should link back to something already defined. Make sure we aren't creating diverging information*.

EP - Need to extract authz use cases and requirements from ecosystem proposal at interop panel

JM - We should try to avoid spending meeting time on organization discussions like where to put documents (EP+1, SC+1, DZ+1)

### [Handle User-Focused Client Constraining Access Control via the ACL #68](https://github.com/solid/authorization-and-access-control-panel/issues/68)

JM: This proposal suggests to just expand wac to satisfy CCAC requirements. And offloads work to Authorization Agent from Justin's Ecosystem proposal.
JB: Do we talk about adding predicate to WAC vocab to include client? Token provided should include id of the client.
JM: You can think of it as evolution of the `acl:origin`, which has many flaws. When I send request to a server, it represents me as user and client I use to make request. When it comes to setting client rules, at this moment it's all bundled under `acl:control` access mode.
JM: Example use case. As admin of the forum I give access to specific people I want to participate. At the same time I want them to grant access to clients they want to use.
JB: Would this aditional mode allow modifications to app id statements. 

## Actions

SC: Need to ensure that panels are incorporating discussions that are happening elsewhere. Output should address existing things out there, and not just where the panel happens to start.

