# Authorization Use Cases
## Notation
Each use case include a hierarchy of resources already existing in the pod and a table which describes the effective access right, i.e. who has what access to what resource.
| agent | privs | resources |
| -- | -- | -- |
| `</Alice>` | R/W | `</Photos/{,IMG-{1009,1103,1289}}>` |
This says that Alice has read/write priveleges to the container `Photos/` and the three contained resources `IMG-1009`, `IMG-1103` and `IMG-1289`. It does *not* capture what access Alice will have to future resources in that container (though conventional WAC would give her the same access to new resources as she has to `Photos/`).
This is followed by a series of bulleted actions and their effect on the effective ACLs. Some include conventional WAC as examples or to illustrate how WAC does not currenlty meet the use case.
## Inheritance
### Adding permissions to inherited permissions
**Initial Resource Hierarchy**
```
Photots/
├── IMG-1009
├── IMG-1103
└── IMG-1289
```
* Resource controller Zac wishes to grant acl:Read, acl:Write access to Alice and Bob to all resources in Photos, and all resources that will be added to that container in the future.
| agent | privs | resources |
| -- | -- | -- |
| `</Alice>` | R/W | `</Photots/{,IMG-{1009,1103,1289}}>` |
| `</Bob>` | R/W | `</Photots/{,IMG-{1009,1103,1289}}>` |
* Zac also grants Claire acl:Read, acl:Write to IMG-1009 and IMG-1103
* Effective access to IMG-1009 and IMG-1103 should be that Alice, Bob, and Claire have acl:Read, acl:Write. Claire has no access to IMG-1289.
| agent | privs | resources |
| -- | -- | -- |
| `</Alice>` | R/W | `</Photots/{,IMG-{1009,1103,1289}}>` |
| `</Bob>` | R/W | `</Photots/{,IMG-{1009,1103,1289}}>` |
| `</Claire>` | R/W | `</Photos/IMG-{1009,1103}>` |
* Alice and Bob would automatically have access to subsequent resources (e.g. IMG-1321, ...) when they are created. Claire would continue to only have access to IMG-1009 and IMG-1103.
``` http
POST /Photos
slug: <IMG-1321>
```
| agent | privs | resources |
| -- | -- | -- |
| `</Alice>` | R/W | `</Photots/{,IMG-{1009,1103,1289,1321}}>` |
| `</Bob>` | R/W | `</Photots/{,IMG-{1009,1103,1289,1321}}>` |
| `</Claire>` | R/W | `</Photos/IMG-{1009,1103}>` |
**Conventional WAC**
Photos ACL:
``` turtle
# current WAC
<Photos/.acl#r1> a acl:Rule ;
acl:agent </Alice>, </Bob>;
acl:mode acl:Read, acl:Write;
acl:accessTo <Photos/> .
```
├── IMG-1009 ACL:
``` turtle
</Photos/resource1#r2> a acl:Rule ;
acl:agent </Claire> ;
acl:mode acl:Read, acl:Write ;
acl:accessTo </Photos/IMG-1009> .
```
└── IMG-1103 ACL:
``` turtle
</Photos/resource2#r2> a acl:Rule ;
acl:agent </Claire> ;
acl:mode acl:Read, acl:Write ;
acl:accessTo </Photos/IMG-1103> .
```
**Issue**: server won't look to </Photos/.acl#r1> to grant Alice and Bob access.
### Removing permissions from inherited permissions
**Initial Resource Hierarchy**
```
Photots/
├── IMG-1009
├── IMG-1103
└── IMG-1289
```
* Resource controller wishes to grant acl:Read, acl:Write access to Alice and Bob to all resources in Photos, and all resources that will be added to that container in the future.
| agent | privs | resources |
| -- | -- | -- |
| `</Alice>` | R/W | `</Photots/{,IMG-{1009,1103,1289}}>` |
| `</Bob>` | R/W | `</Photots/{,IMG-{1009,1103,1289}}>` |
* 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 IMG-1103.
| agent | privs | resources |
| -- | -- | -- |
| `</Alice>` | R/W | `</Photots/{,IMG-{1009,1103,1289}}>` |
| `</Bob>` | R/W | `</Photots/{,IMG-{1009,1289}}>` |
* Alice and Bob would automatically have access to subsequent resources (e.g. IMG-1321, ...) when they are created.
``` http
POST /Photos
slug: "IMG-1321"
```
| agent | privs | resources |
| -- | -- | -- |
| `</Alice>` | R/W | `</Photots/{,IMG-{1009,1103,1289,1321}}>` |
| `</Bob>` | R/W | `</Photots/{,IMG-{1009,1289,1321}}>` |
### Manage accessors by group
**Initial Resource Hierarchy**
```
Photots/
├── IMG-1009
├── IMG-1103
└── IMG-1289
```
* Resource controller Zac creates a group `ShutterBugs` and adds Alice and Bob to it.
* Zac grants R/W access to ShutterBugs (and thereby Alice and Bob).
| agent | privs | resources |
| -- | -- | -- |
| `</Alice>` | R/W | `</Photots/{,IMG-{1009,1103,1289}}>` |
| `</Bob>` | R/W | `</Photots/{,IMG-{1009,1103,1289}}>` |
* Zac adds Claire to ShutterBugs.
| agent | privs | resources |
| -- | -- | -- |
| `</Alice>` | R/W | `</Photots/{,IMG-{1009,1103,1289}}>` |
| `</Bob>` | R/W | `</Photots/{,IMG-{1009,1103,1289}}>` |
| `</Claire>` | R/W | `</Photos/IMG-{1009,1103,1289}>` |
* Zac creates IMG-1321.
``` http
POST /Photos
slug: <IMG-1321>
```
| agent | privs | resources |
| -- | -- | -- |
| `</Alice>` | R/W | `</Photots/{,IMG-{1009,1103,1289,1321}}>` |
| `</Bob>` | R/W | `</Photots/{,IMG-{1009,1103,1289,1321}}>` |
| `</Claire>` | R/W | `</Photots/{,IMG-{1009,1103,1289,1321}}>` |
* Zac removes Alice from ShutterBugs
| agent | privs | resources |
| -- | -- | -- |
| `</Bob>` | R/W | `</Photots/{,IMG-{1009,1103,1289,1321}}>` |
| `</Claire>` | R/W | `</Photots/{,IMG-{1009,1103,1289,1321}}>` |
### Piloted agent restricts privs
**Initial Resource Hierarchy**
```
PhotoAlbums/
└── WorkTrip-AMIA2019
├── session-1-slide3
├── session-1-slide4
├── bar-photo-mojito
├── bar-photo-margarita
└── session-2-slide5
```
| agent | privs | resources |
| -- | -- | -- |
| `</WorkGroup>` | R | `<PhotoAlbums/WorkTrip-AMIA2019/*>` |
| `</MyPhotoApp>` | R/W/C | `<PhotoAlbums/WorkTrip-AMIA2019/>` |
* Zac (resource controller) uses MyPhoto (directly or via requests to an authorization agent) to revoke `</WorkGroup>`'s read access to the bar photos.
| agent | privs | resources |
| -- | -- | -- |
| `</WorkGroup>` | R | `<PhotoAlbums/WorkTrip-AMIA2019/* - bar-photo-*>` |
| `</MyPhotoApp>` | R/W/C | `<PhotoAlbums/WorkTrip-AMIA2019/>` |
**Conventional WAC**
An agent's privilenge to change ACLs is expressed as acl:Control:
``` turtle
# current WAC
<PhotoAlbuns/WorkTrip-AMIA2019/.acl#r1> a acl:Rule ;
acl:agent </WorkGroup>, </FriendsGroup> ;
acl:mode acl:Read ;
acl:accessTo <PhotoAlbuns/WorkTrip-AMIA2019/> .
<PhotoAlbuns/WorkTrip-AMIA2019/.acl#r2> a acl:Rule ;
acl:agent <//MyPhotoApp> ;
acl:mode acl:Read, acl:Write, acl:Control ;
acl:accessTo <PhotoAlbuns/WorkTrip-AMIA2019/> .
```
**Issue**: Control does not appear to have a boundary on it. For instance, it does not prevent the agent from granting access to arbitrary webids.
### Autonomous agent expands privs
**Initial Resource Hierarchy**
```
Appointments/
└── familyDoctor-2020-07-09
```
* `MedManagerApp` has control to automate medical tasks for Zac
| agent | privs | resources |
| -- | -- | -- |
| `</familyDoctor>` | R/@ | `<Appointments/*>` |
| `</MedManagerApp>` | R/W/C | `<Appointments/>` |
* Zac's hospital synchronizes with POD, adding a new cardiology appointment
``` http
POST /Appointments
slug: "cardiologist-2020-07-12"
```
The MedManagerApp sees that the appointment is with Pierre de Fib and automatically gives him write privs
| agent | privs | resources |
| -- | -- | -- |
| `</familyDoctor>` | R/W | `<Appointments/*>` |
| `</MedManagerApp>` | R/W/C | `<Appointments/>` |
| `</PierredeFib>` | R/W | `<Appointments/cardiologist-2020-07-12>` |
### Separate permissions for containers and novel resources
**Initial Resource Hierarchy**
```
Appointments/
└── familyDoctor-2020-07-09
```
* `MedManager` stores synchronization details in body of the the Appointments container.
* Zac grants his family doctor R/W access to current and future resources in Appointments, but R to the Appointments container.
**Issue**: ACLs on `</Photos/>` conflates 1. access to container and 2. default access to nested resources.
## Sandboxing
The above use cases assume a simple Control (C\) privilege. Sandbox use cases explore predicated control, limiting the ability to change ACLs.
### Sandboxed autonomous agent not allowed to expand some privs
**Initial Resource Hierarchy**
```
Appointments/
└── familyDoctor-2020-07-09
```
* `MedManagerApp` has control to automate medical tasks for Zac but only to extend access to
* his family group
* his visiting nurse
| agent or sandbox | privs | resources | controlling sandbox |
| -- | -- | -- | -- |
| `</familyDoctor>` | R/W | `<Appointments/*>` |
| `</MedManagerApp>` | R/W/C* | `<Appointments/>` | Sandbox1 |
| `</FamilyGroup>` | R/W | Sandbox1 | |
| `</nurseWalkder>` | R/W | Sandbox1 | |
* Zac's hospital synchronizes with POD, adding a new cardiology appointment
``` http
POST /Appointments
slug: "cardiologist-2020-07-12"
```
* `MedManagerApp` sees that the appointment is with Pierre de Fib, attempts to give him write privs, and gets rejected. No change to ACLs.
## Tagging
### Agent UI applies tags
**Initial resource hierarchy**
```
data/
├── PhotoAlbums/
│ └── WorkTrip-AMIA2019/
│ ├── bar-photo-margarita
│ ├── bar-photo-mojito
│ ├── session-1-slide3
│ ├── session-1-slide4
│ └── session-2-slide5
└── Recipies/
└── strawberry daquari
```
* Alice tags `bar-photo-*` with `me:boozing`
| tag | resources |
| -- | -- |
| `me:boozing` | `<PhotoAlbums/WorkTrip-AMIA2019/bar-photo-*>` |
| `me:boozing` | `<PhotoAlbums/daves-bar-and-grill/*>` |
| `me:boozing` | `<Recipes/strawberry daquari>` |
* Zac (resource controller) uses MyPhoto (directly or via requests to an authorization agent) to revoke `</WorkGroup>`'s read access to `me:boozing`, but shares those with other boozers within `PhotoAlbums/WorkTrip-AMIA2019`
| agent | privs | resources |
| -- | -- | -- |
| **PhotoAlbums/WorkTrip-AMIA2019 rules** |
| `</WorkGroup>` | R | `<PhotoAlbums/WorkTrip-AMIA2019/* - me:boozing>` |
| `</BoozersGroup>` | R | `me:boozing` |
| `</MyPhotoApp>` | R/W/C | `<PhotoAlbums/WorkTrip-AMIA2019/>` |
* Zac decides that the boozers group gets access to *all* `me:boozing` resources
| agent | privs | resources |
| -- | -- | -- |
| **PhotoAlbums/WorkTrip-AMIA2019 rules** |
| `</WorkGroup>` | R | `<PhotoAlbums/WorkTrip-AMIA2019/* - me:boozing>` |
| `</MyPhotoApp>` | R/W/C | `<PhotoAlbums/WorkTrip-AMIA2019/>` |
| **global rules** |
| `</BoozersGroup>` | R | `me:boozing` |
## Features
* principal - an entity identified by a webid to who privileges are granted for some resources.
* group - recursive hierarchy of principals.
* tag - recursive hierarchy of resources.
* acl:Rule - grant principal or group some privileges to a container, resource or tag.
* Control - the privilege to create/change/delete acl:Rules.
* sandbox - restrictions on Control privileges.
* autonomy - the ability of a app or person to data and ACLs without intervention by the POD owner.
* piloting - explicit real-time choices made by the POD ownder.
Sign in with Wallet
Connect another wallet