---
# System prepended metadata

title: Solid Authorization Panel

---

# Solid Authorization Panel
October 21st, 2020

## Present

- Justin B
- elf Pavlik
- Henry S
- Sarven C
- Eric P
- Josh C

## Agenda

- Permissioning Applications / Client Constraining Access Control https://solid.github.io/authorization-panel/wac-ucr/#uc-client-constraints
- What permissions are required for delete - https://github.com/solid/specification/issues/197#issuecomment-700625490

## Minutes

### Permissioning Applications / Client Constraining Access Control

https://solid.github.io/authorization-panel/wac-ucr/#uc-client-constraints


PAVLIK: "Limiting application access when not acting as the resource controller"

PAVLIK: If a person has access to multiple projects on multiple resource servers, they should be able to say that a person can access projects i have access to, but i only want this application to be able to read that data (even though I have read/write permissions)

PAVLIK: In current approach, if a user doesn't have control access, they couldn't narrow those permissions on the resource server ACL aux. resources.

PAVLIK: Application could get a capability credential, and could present this to resource servers that would narrow the access.

PAVLIK: Would need to change the authentication spec, and in my opinion this is blocking to the authentication spec. Could document this approach as a proposal, which would require a specific change to the authorization document. Jackson has another proposal that would not 

JB: Expand on why it's a blocker to authn spec

PAVLIK: Access token is used purely for authentication - no scopes on the access token or anything like that. Since everything is signed and bound to the client, there's no way for the client to get another credential and bundle it. If the IdP manages this, there isn't as big of a deal. If two different parties need to do it, then we need a bigger change. Need to evaluation different approaches.

ERICP: If we're not shooting for forward compatibility does it matter

JB: Are we most concerned with modes of access vs. what is being accessed?

PAVLIK: More than just modes but also narrowing what kind of resources can be accessed.

HJS: I think the use case is good but the answer does not necessarily have to be that the resource
needs to know about those restrictions. The user can have an keychain app that only gives out tokens
of certain levels to each client. It could be that the file system metaphor confuses things, because in the File System the user space and the OS space tend to get confused. On the Web on the other hand they are necessarily disjoint.

PAVLIK: To unblock authn - provide some clear clarification to https://github.com/solid/authentication-panel/issues/60 that explains how things are decoupled.






