# Solid Authorization Panel

June 10th, 2020

## Present

* @justinwb
* @joshdcollins
* @bblfish
* @elf-pavlik

## Agenda

### Purpose of the panel

- Justin: it seems that panel had identity crisis for a while. It started with App Authorization Panel than changed to Authorization and Access Control.
- Henry: I think client needs to know what rules server has so it can follow thoser rules.
- Justin: The best way to get this going is to work on use cases and environments. There is a lot that can fall under auhorization and authentication, use cases are going to put them together.
- Justin: I think app authorization panel is a narrow scope for gitter channel name. I think we can't rename channel on gitter.
- we need to change name of panel properties to be accurate
- Henry: I think we need to start from architecture of Solid. We start with one application following links and trying to access any resource. Client ...
- Pavlik: Focus on what we already have - extract requirements from ecosystem proposal use case in the interoperability panel, and clear extensions (i.e. client constraints) - JB +1
- Pavlik:

### Action Items

- Document the purpose / focus of the panel
- Ensure the panel name is reflective of the purpose / focus, and update channels, repos, etc to use the agreed-upon panel name
- Agree on prioritized initiatives
- Authorization use cases. Extract individual requirements from use cases.
- Pavlik: client constraints set by user
- Justin: normative draft of wac specification
- Justin: extensions to wac specification (i.e. tagging, shape filtering, verifiable credentials)

- Use Cases:
- management of acls easy
- shape filters

### [Ecosystem draft in interop panel](https://solid.github.io/data-interoperability-panel/ecosystem.html)

- Pavlik: it relates to Jackson's idea described in https://github.com/solid/authorization-and-access-control-panel/issues/68

- Pavlik: can you get the user consent screen related sections into your ecosystem draft?
- Justin: I should have progress on that by this time next week.
- Justin: I see two key initiatives in front of us. Getting normative draft of WAC is important. It shouldn't have gaps and things open for interpretation. It should go into solid/specifications repo. Authorizations workflows go right after that.
- Justin: Existing draft https://github.com/solid/web-access-control-spec didn't go through editorial proces. We have feedback that implementations had different interpretations due to gaps in that draft.
- Henry: In my opinion server shouldn't restrict what client can access.
- Pavlik: Key question is who enforces it. user (via some mechanism) or resource server.
- Henry: Yes that is the right question
- Henry: Agree we need to illustrate the use cases and prioritize them
- Henry: We need to make sure that we focus on secure authorization statements
- Justin: Need to include efforts on how these statements are validated and any additional logic that should be applied.

Ahead of next week:
- Justin: Create issues for panel purpose, name, and initiatives in github, and will work towards getting rough consensus before next meeting
- Pavlik: drafting use cases for client constraining
- Henry: Review above issues and use cases as they're produced