UC3: fixes and add story for privacy

proposals/evaluation/uc-3-inheritance.md

@@ -45,7 +45,9 @@ Bob and Alice are part of the agent matcher `</acp/research#m1>`:
   acp:agent ex:Bob, ex:Alice .
 ```
 
-The research policy `</acp/research#p1>` gives read access to all agents matched by `</acp/research#m1>`:
+`</acp/research>` is visible only to members of the research group. 
+
+The policy `</acp/research#p1>` gives read access to all agents matched by `</acp/research#m1>`:
 
 ```turtle
 # Resource: </acp/research>
@@ -65,10 +67,17 @@ The access control `</weekly-status/.acp#ac1>` applies to all resources containe
   acp:applyMembers </acp/research#p1> . # applies the policy to all resources contained by </weekly-status/>
 ```
 
-An unauthenticated agent making a GET on `</weekly-status/>` container will receive a `Link: <.acp>; rel="acl"` header in the `401` response that points to the above `<.acp>`. 
-This relation is what makes the contents of `</weekly-status/.acp>` authoritative, and is therefore the information the client can use to decide what credentials to present.
+#### a. Accessing `</weekly-status/>`
+
+An unauthenticated agent making a GET on the `</weekly-status/>` container will receive a `Link: <.acp>; rel="acl"` header in the `401` response that points to the above `<.acp>`. 
+This relation makes the contents of `</weekly-status/.acp>` authoritative and is, therefore, the information the client can use to decide which credentials to present.
+
+[Actors](https://essif-lab.pages.grnet.gr/framework/docs/terms/actor) whose [principal](https://essif-lab.pages.grnet.gr/framework/docs/essifLab-glossary#principal) are not members of the research institute, will not have access to the policy `</acp/research#p1>` and so, not knowing what credential to present will stop there.
+
+#### b. Accessing `</weekly-status/2021-04-28/report.md>`
 
-A unauthenticated agent making a request to  `</weekly-status/2021-04-28/report.md>` will receive in the header of a 401 a link to `</weekly-status/2021-04-28/report.acp>`.
+Any [digital actor](https://essif-lab.pages.grnet.gr/framework/docs/terms/digital-actor) making a request to  `</weekly-status/2021-04-28/report.md>` will receive in the header of a 401 response, a link to `</weekly-status/2021-04-28/report.acp>`. 
+If that actor makes a `GET` request to `<report.acp>` it will receive a graph isomorphic to:
 
 ```turtle
 # Resource: </weekly-status/2021-04-28/report.acp>
@@ -79,6 +88,8 @@ A unauthenticated agent making a request to  `</weekly-status/2021-04-28/report.
 ```
 
 Note that `</weekly-status/2021-04-28/report.acp>` is basically a copy of `</weekly-status/.acp>`. In the current proposal, all resources in ACP have their own associated effective Access Control Resource.
+
+The same logic thus applies here as for access to the container. To know which credentials to present, a digital actor will need to know the contents of `</acp/research>`. But access to that is only granted to members of that research organization.
 
 ### WAC
 
@@ -92,7 +103,11 @@ Bob and Alice are members of the research group `</groups/research#g1>`:
   vcard:hasMember ex:Alice .
 ```
 
-The acl enabling read access to all resources contained by `</weekly-status/>` for all members of group `</groups/research#g1>` is:
+This vcard is visible only to members of the research group. 
+
+#### a. Accessing `</weekly-status/>`
+
+The acl enabling read access to all resources contained in `</weekly-status/>` for all members of group `</groups/research#g1>` is:
 
 ```turtle
 # Resource: </weekly-status/.acl>
@@ -103,18 +118,29 @@ The acl enabling read access to all resources contained by `</weekly-status/>` f
   acl:mode acl:Read .
 ```
 
-An unauthenticated client making a GET on the `</weekly-status/>` container will receive a `Link: <.acp>; rel="acl"` header in the `401` response that points to the above `<.acl>`. 
-This relation is what makes the contents of `</weekly-status/.acl>` authoritative, and is therefore the information the client can use to decide what credentials to present.
+Any agent making a GET on the `</weekly-status/>` container will receive a `Link: <.acp>; rel="acl"` header in the `401` response that points to the above `<.acl>`. 
+This relation makes the contents of `</weekly-status/.acl>` authoritative and is, therefore, the information the client must use to decide what credentials to present, and the resource's Guard to decide whether to accept those credentials.
+
+At present, though, only the controller of `</weekly-status/.acl>` can read that resource, as WAC does not have an option to make the ACL more widely readable. (Some proposals: adding a [ControlRead](https://github.com/solid/web-access-control-spec/issues/85) mode or [ACLs on ACLs](https://github.com/solid/authorization-panel/issues/189)).
+
+#### b. Accessing `</weekly-status/2021-04-28/report.md>`
+
+A unauthenticated client actor making a GET request to  `</weekly-status/2021-04-28/report.md>` may receive in the header of a `401`, either of the following: 
+
+1) `Link: </weekly-status/.acl>; rel=acl`. 
+2) `Link: </weekly-status/2021-04-28/report.acl>; rel=acl`
+
+As pointed out previously, only the controller and the resource guard can read those, all other actors (eg. Alice or Bob) need undefined out-of-band knowledge to know how to authenticate. So we are limited to the controller actor.
+
+In (1) the actor whose Principal is the Controller, will be able to determine using inheritance what credentials it can use. 
 
-A unauthenticated client making a GET request to  `</weekly-status/2021-04-28/report.md>` will receive in the header of a `401`, either of the following: 
+In (2) the resource may either be created already, in which case the default rule of `</weekly-status/.acl>` does not apply, or it is not created yet, and the default applies but the client cannot know what the default acl is.
 
-1) a `Link` to `</weekly-status/.acl>`. 
-2) a `Link` to `</weekly-status/2021-04-28/report.acl>`
+### WAC+ acls on acls or extension to modes
 
-In the case of (1) the client will be able to find out what identity to provide by looking at `</weekly-status/.acl>`. But if the controller wants to add a new editor to `<report.md>` then it will have to add that to the root `</weekly-status/.acl>` as there is no agreed way to create a new acl out of nothing.
+With [issue 189: ACLs on ACLs](https://github.com/solid/authorization-panel/issues/189) it becomes possible to make the ACLs more widely readable than the controller, which means that the clients of Bob and Alice can find out that they have access to the resource.
 
-In the case of (2) a controller with the contents of `</weekly-status/.acl>` will not be applicable, since by the fact of existing `</weekly-status/2021-04-28/report.acl>` will override the default. 
-As a result new access control rules will need to be placed in `</weekly-status/2021-04-28/report.acl>`, potentially duplicating what was in the default acl. 
+Another option is to extend the modes with a ControlRead mode [as mentioned in issue 85](https://github.com/solid/web-access-control-spec/issues/85). 
 
 ## 2. Changing permissions to a subcollection
 
@@ -143,7 +169,9 @@ The research policy `</acp/research#p2>` gives read access to all agents matched
   acp:allow acl:Read, acl:Write .
 ```
 
-The access control `</weekly-status/2021-04-28/.acp#ac1>` applies to all resources contained by `</weekly-status/2021-04-28/>` and, via policy `</acp/research#p2>`, enables read access for all agents matched by `</acp/research#m2>`:
+The access control resource `</weekly-status/2021-04-28/.acp#ac1>` initially starts off as containing relevant triples taken from the relevant `applyMembers` rules of `</weekly-status/.acp>`.
+
+To allow Carol to have access to `</weekly-status/2021-04-28/>` and children, the Controller of `2021-04-28/` needs to edit the rules in `</weekly-status/2021-04-28/.acp>` to something like:
 
 ```turtle
 # Resource: </weekly-status/2021-04-28/.acp>
@@ -153,13 +181,20 @@ The access control `</weekly-status/2021-04-28/.acp#ac1>` applies to all resourc
   acp:applyMembers </acp/research#p1>, </acp/research#p2> . # applies the policy to all resources contained by </weekly-status/2021-04-28/>
 ```
 
+
 ### WAC
 
-To give Carol read and write access to the `</weekly-status/2021-04-28/>` collection and its content, Bob must create a new effective ACL resource, `</weekly-status/2021-04-28/.acl>` which would express all permissions that are to govern access to `</weekly-status/2021-04-28/>`.
+To give Carol read and write access to the `</weekly-status/2021-04-28/>` collection and its content, Bob (todo: is bob the controller?) must create a new effective ACL resource, `</weekly-status/2021-04-28/.acl>` which would express all permissions that are to govern access to `</weekly-status/2021-04-28/>`.
 
-Todo: How does a client create a new acl if one does not exist before?
+Todo: How does a client create a new acl if one does not exist before? This is not so easy, as the 
+`</weekly-status/2021-04-28/>` can contain one of the following headers
+1. `Link: </weekly-status/.acl>; rel="acl"`
+2. `Link: </weekly-status/2021-04-28/.acl>; rel="acl"`
+3. no Link header
 
- In other words, to maintain the access permissions previously defined in `</weekly-status/.acl>`, Bob will need to include an authorization defining read access for the research group, along with an authorization defining read and write access for Carol, in the new `</weekly-status/2021-04-28/.acl>`.
+In case 2 the controller agent will know what to edit. But not in case 1 or 3. But since all 3 are left open by the WAC spec, the client cannot know without out-of-band knowledge which resource to edit.
+
+Given that out of band knowledge, the actor wanting to give access permissions to Carol to `</weekly-status/.acl>` resource, will need to copy the relevant rules from `</weekly-status/.acl>` to the newly created `</weekly-status/2021-04-28/.acl>` and include Carol too. 
 
 ```Turtle
 # Resource: </weekly-status/2021-04-28/.acl>
@@ -176,8 +211,14 @@ Todo: How does a client create a new acl if one does not exist before?
   acl:mode acl:Read, acl:Write .
 ```
 
+As soon as this ACL is created, the old ACL will no longer be authoritative. 
+
+The problem here is that we need to copy many of the statements from `</weekly-status/.acl>` in the new acl, which means that changes to the root acl do not get propagated, and the more changes there are, the more places will need to be edited to make any future changes.
+
 ### WAC+ relaxing acl:default
 
+If one were to want the `</weekly-status/2021-04-28/>` ACR to continue to use `</weekly-status/.acl>` then one could make the `acl:default` more flexible as follows.
+
 According to the [ACL ontology definition as of July 2021](https://github.com/solid/authorization-panel/pull/216#discussion_r665338497), the `acl:default` predicate is only effective in statements where the current container is the object; that is, the resource `</weekly-status/.acl>`, which is the direct effective access control list of `</weekly-status/>`, can only target that directory in statements using `acl:default`.
 
 However, if WAC's use of `acl:default` were to be relaxed as described in [issue 191](https://github.com/solid/authorization-panel/issues/191), then one could rely on the effective access control resource discovery mechanism and augment the content of `</weekly-status/.acl>`:
@@ -199,18 +240,29 @@ However, if WAC's use of `acl:default` were to be relaxed as described in [issue
 
 See also: https://github.com/solid/authorization-panel/pull/216#discussion_r665230245
 
+As a result the acl's for all the resources could be pointing to the root acl. But doing that will tend to place all the ACLs on a Pod together, giving anyone with access to that acl, visibility on all the access control rules of the Pod.
 
 ### WAC+ ac:imports +acr 
 
-[WAC+:imports](https://github.com/solid/authorization-panel/issues/210) is explained most easily if we also require every
-resource to link to its own ACR, as ACP does.
+[WAC+:imports](https://github.com/solid/authorization-panel/issues/210) is explained most easily if we also require every resource to link to its own ACR, as ACP does.
+This makes it easy for a client to find out where the effective ACR is.
 
-We keep `wac:default` working as currently specified.
+We keep `wac:default` working as currently specified. Note, that this proposal is also compatible with more flexible acl:defaults, and indeed with the use of general `wac:accessToClass` descriptions, such as classes of resources with a specific tag.
 
-A unauthenticated client that makes a GET on `</weekly-status/2021-04-28/>` and receives a `401` with a `Link` to `</weekly-status/2021-04-28/>`. 
+An unauthenticated client that makes a `GET` on `</weekly-status/2021-04-28/>` will receives a `401` with a `Link` to `</weekly-status/2021-04-28/.acl>`. 
+The  container when newly created would contain the following triple 
+
+```Turtle
+# Resource: </weekly-status/2021-04-28/.ac>
+
+<> ac:imports <../.acl> .
+```
+
+This allows any client (including the controller's client) to find the default rule by following their nose.
+
+The current WAC inheritance algorithm, states that the inheritance no longer works for a resource that has an ACL. But that does not stop inherticance from from being explicitly defined using `ac:imports`.
 
-If the client is the controller of the container, it can do a
-PUT with the following rules:
+The Actor for the Principal in control of the container can then  `PUT` the following rules to allow Carol to read and write to those containers:
 
 ```Turtle
 # Resource: </weekly-status/2021-04-28/.ac>
@@ -224,4 +276,4 @@ PUT with the following rules:
   acl:mode acl:Read, acl:Write .
 ```
 
-In other words, this removes the need to duplicate the `</weekly-status/.acl#authorization>` rule, so any future edits to that rule need only be done in one place.
+This removes the need to duplicate the `</weekly-status/.acl#authorization>` rule:  any future edits to that rule need only be done in one place.