# Solid Authorization Panel
December 9th, 2020

## Present

- Justin B
- Max Leonard
- Henry S
- Eric P
- elf Pavlik

## Agenda

* Update on Functional Requirements - Justin B
* How possession of specific VC impacts authN spec - e Pavlik
* [Consider Allowing ACRs on ACRs](https://github.com/solid/authorization-panel/issues/151)
* [RelBAC](https://github.com/solid/authorization-panel/issues/150)

## Minutes

### Update on functional requirements

Draft PR (Still in process - incomplete) - https://github.com/solid/authorization-panel/pull/152

Eric: Suggestion - consider formatting as table to break up a bit more.

| name | desc | refs |
| -- | -- | -- |
| **resource** | The system shall limit an agent’s ability to access a resource or collection | § 2.1 Basic resource access<br/>§ 2.2 Basic collection access |
| **identity** | The system shall allow access to be limited to an agent based on the identity of the agent. § 2.1 Basic resource access | § 2.2 Basic collection access |
| **group** | The system shall allow access to be limited to an agent based on the agent’s membership in a certain group of agents | § 2.1.7 Group access |
| **application** | The system shall allow access to be limited to an agent based on the application in use by the agent | § 2.5.1 Limiting access to trusted applications |
| **creator** | The system shall allow access to a certain resource to be limited to the agent that created that resource | § 2.2.4 Read-append-write access to a Collection |
|<span style="color: brown"> **verifiable credential** |<span style="color: brown"> The system shall allow access to be limited to an agent based on the agent’s possession of a certain verifiable credential |<span style="color: brown"> § 2.9.1 Possession of a verifiable credential (Future) |
| **unauth'd agent** | The system shall allow access to be limited to any unauthenticated agent | § 2.1.8 Public access |
| **auth'd agent** | The system shall allow access to be limited to any authenticated agent | § 2.1.9 Logged in access |
| **limit ACLs read** | The system shall limit the ability to read the access permissions associated with a certain resource | § 2.1.1 Control access |
| **limit ACLs write** | The system shall limit the ability to change the access permissions associated with a certain resource | § 2.1.1 Control access |
| **read** | The system shall limit the ability to read a certain resource | § 2.1.6 Read-only access, § 2.1.2 Read-write access, § 2.1.3 Read-append access |
| **write** | The system shall limit the ability to change any of the contents of a certain resource | § 2.1.2 Read-write access |
| **delete** | The system shall limit the ability to delete a certain resource. Corresponding use case needs to be added |
| **append-only** | The system shall limit the ability to change existing data in a certain resource, such that only new data can be added to it | § 2.1.4 Append-only access |

Pavlik: Be more specific in the piloted application requirement (#4)

Eric: Change "shall" to "MUST" for anyting related to conformance.

Dmitri: Adjust language on VC to be "possession of a verifiable credential or capability"

Pavlik: Look at UMA approach - authorization server associated with the resource w/ claims gathering step

Henry and Eric:
- Explain the process behind the Diff of ACL and ACP
(Henry: the idea is to try to find mappings, see if that works, then refine)
- An idea would be to make a table of of some sort (examples) of how one would express the same thing in ACL, ACP, RelBac, ...
- Acls on Acls: the issue would be: how does one specify that an ACL should have an ACL (create Foo.acl.acl)? (Henry: think about options and see if it makes sense. Perhaps it ends up making things more complicated?)