# 2020-07-08 Authorization Panel

## Agenda

* Use Cases and Requirements
* Proposed use case: [Dependent resources](https://github.com/solid/specification/issues/183)
* Proposed use case: Capability links (Sharing a resource via a 'share link', with a person who does not yet have a WebID/DID).
* [Next week agenda](https://hackmd.io/7O05oVzeRwWMVQhhLFhM3Q)

## Present

* Dmitri Zagidulin
* Eric Prud'hommeaux
* Jackson Morgan
* Justin Bingham
* elf Pavlik
* Josh Collins

## Minutes

### Use Cases and Requirements
For reference: UCR Rendered at https://solid.github.io/authorization-panel/wac-ucr/

- Justin: We should submit new use cases via pull request. This one is call WAC Use Cases. In Authorization you can lump in a lot of things. WAC has specific problems, we need to get to normative WAC draft which addresses those issues.

- No Issues with UCR Template

### Proposed use case: Inheritance - Adding permissions to inherited permissions

- Justin: In current Ecosystem draft we run into issue related to WAC inheritance.

* Given a collection of resources (/collection) containing resources:
* /collection/resource1
* /collection/resource2
* /collection/resource3

* Resource controller wishes to grant acl:Read, acl:Write access to Alice and Bob to all resources in that container, and all resources that will be added to that container in the future

* Resource controller also wishes to grant acl:Read, acl:Write to Claire to resource1 and resource2 specifically

* Effective access to resource1 and resource2 should be that Alice, Bob, and Claire have acl:Read, acl:Write. Claire has no access to resource3.

* Alice and Bob would automatically have access to subsequent resources (i.e. resource4, ...) when they are created. Claire would continue to only have access to resource1 and resource2.

### Proposed use case: Inheritance - Removing permissions from inherited permissions

* Given a container (/container) containing resources:
* /container/resource1
* /container/resource2
* /container/resource3

* Resource controller wishes to grant acl:Read, acl:Write access to Alice and Bob to all resources in that container, and all resources that will be added to that container in the future.
* Resource controller then decides that resource2 contains sensitive information that should not be shared with Bob.
* Effective access to resource1 and resource3 should be that Alice and Bob have acl:Read, acl:Write. Only Alice would have access to resource2.
* Alice and Bob would automatically have access to subsequent resources (i.e. resource4, ...) when they are created.

- Jackson: RDF is additive, adding a statement doesn't remove other existing statement.
- Justin: If you look at firewall model you just walking down the chain.

- Dmitri: Tension between triples and quads

- Jackson: Question on assumptions - assumes a container based structure that dictates auth.
- Dmitri: We are familiar with WAC and you expalined it on this call. I would propose to put it as use case and if people ask for clarifications we can adjust it. JB + 1

- Annotated version with added wac examples: https://hackmd.io/HW_5HEd5Qqy7hpZ-vigfmw

- Eric: always ensure that any subset of a graph leads to same conclusion. If you have two versions of a file, you don't want them to present inconsistent world views. It is all around how you build extensible systems where you don't know what inferences you will have. In real world people make decisions based on existance or absence of data. As long as we don't rely in inference we shouldn't hit any problems here.
- Justin: We should state that in authorative spec.

Action Item: Justin to submit use cases above and associated reqs/
- Note Pavliks point about making resource names reflect real worl better (e.g. /notebooks/note1, ...)

### Proposed use case: [Dependent resources](https://github.com/solid/specification/issues/183)

- Dmitri: In many situations we have primary resource and dependent resource which permissions should stay the same as primary resource. While we may want to have possibility to set specific permissions on dependant resources, often we just want to have them tied to primary resource.
- ...: What I suggest in the issue it allows inheritance across containers.
- ...: We can have another case like todo's with tasks on it
- Pavlik: I would suggest that we take it as guideline to have everything explicit and don't leave anything to implicit.

### Proposed use case: Capability links (Sharing a resource via a 'share link', with a person who does not yet have a WebID/DID).

(from Dmitri):

- Typically done in google docs with capability link
- might be a standin if the user registers later
- Explore placeholder ids, and capability links
- Pavlik: Ruben had smilar UC where he wants to share calendars in a way where non solid (auth) applications can access them.
- Justin: Can also benefit from expiration statement

### Proposed use case: Expiring permissions

- User creates a permission that should only live for a certain period of time before deactivating

- [Linked Data Capabilities](https://w3c-ccg.github.io/zcap-ld/)