# Solid Authorization Panel

## Attendees

- Justin B
- Henry Story
- Sarven C
- Jackson M
- Dmitri Z
- elf Pavlik

## Agenda

- Read-append-delete use case - https://github.com/solid/authorization-panel/pull/94
- Minimal disclosure - https://github.com/solid/authorization-panel/pull/95
- High confidentiality - https://github.com/solid/authorization-panel/pull/96
- Discuss Inheritance - https://github.com/solid/authorization-panel/issues/91

## Minutes

### Read-append-delete use case - https://github.com/solid/authorization-panel/pull/94

- Pavlik: why only delete but not write?
- Justin: some systems may not let you edit comments but only delete them
- Sarven: What permisson do you expect on collection and what on appended resource?
- Justin: I moved it between different section, it depends how you approach it. When I create resource in collection it inherits permission that creator has write (or just delete) access to that resource.
- Sarven: It sounds like you need append on collection. As well as write access for crator to delete it.
- Justin: Likely need to isolate the creator of the resource so it can be included in rules
- Henry: Also consider time expiration with a trigger when time expire
- Pavlik: Can some of these use cases be handled by bots subscribing to access control changes? Point being not everything needs to be handled in a declarative way.
- Sarven: Would this be handled by `acl:defaultModes` like concept. Could we work with something like that.
- Justin: Is acl:default sufficient for that in current spec (i don't think so)
- Sarven: acl:default seems it may be buggy
- Pavlik: Inheritance use case and removing implicit inheritence is important factor here.
- ACTION ITEM: adjust this use case from delete to write
- Justin: Any objections to this use case?
- Sarven: I think we should break down use cases into simplest possible ones.
- Justin: Most use cases are written this way. How would you apply it to this specific use case?
- Sarven: I agree, we possibly can't brake this one down any further. Maybe we would only have append on collection and write by creator on specific resource. Not sure if we need the read part here.
- Justin: I think read here is important here to keep use case realistic.
- Sarven: Bottom line here seems like different agents having different access.
- Justin: In collaborative use, one wants to create rules which stand on their own and don't require manual modification all the time.

### Minimal Disclosure - https://github.com/solid/authorization-panel/pull/95

HS: Related to privacy of the person wanting to read a resource. For example, if they needed to try all of their different credentials, they would be revealing all of their available credentials to the resource server.

Justin: I don't see fundamental difference in those use cases. They both seem to suggest that user accessing resource doesn't want to iteratively disclose all the credentials available to them.

Henry: First use case builds on top of another existing use case. Second adds Friend of a Friend (of a Friend) scenario. Here async sharing data over channels doesn't seem to cover it.

Sarven: Why credentials are related to access rules?

Henry: Some rules may specify "only members for this organization" have specific access. They may present membership credential.

Sarven: That sounds like specifying a class of agents, possibly using 'property paths'. Not sure how you extend current rules to implement it.