diff --git a/proposals/evaluation/uc-3-inheritance.md b/proposals/evaluation/uc-3-inheritance.md new file mode 100644 index 00000000..b07dc88f --- /dev/null +++ b/proposals/evaluation/uc-3-inheritance.md @@ -0,0 +1,227 @@ +# Access Inheritance Use Cases + +This is part 3 of the [implementation specific use cases comparison](./use-cases.md). + +See also: [UCR 2.3 Collection resource inherited access](https://solid.github.io/authorization-panel/authorization-ucr/#uc-inheritance) + + +## Setup + +The Weekly status collection is an `ldp:BasicContainer`, which contains other `ldp:BasicContainers`, one for each weekly meeting, into which further documents can be placed. + +```turtle +# Resource: +<.> + a ldp:BasicContainer ; + ldp:contains <2021-04-28/>, <2021-05-05/>, <2021-05-12/> . +``` + +We have the following hierarchy of resources (shown in more detail in the UCR): + +``` + + + + + + + +``` + +We omit here the access-control resources as those are proposal specific. + +## 1. Read access to a group on a collection of resources + +We want to enable read access to all resources contained in `` for a group of people (`ex:Alice` & `ex:Bob`). + +### ACP + +Bob and Alice are part of the agent matcher ``: + +```turtle +# Resource: +<#m1> + a acp:AgentMatcher ; + acp:agent ex:Bob, ex:Alice . +``` + +The research policy `` gives read access to all agents matched by ``: + +```turtle +# Resource: +<#p1> + a acp:Policy ; + acp:anyOf <#m1> ; + acp:allow acl:Read . +``` + +The access control `` applies to all resources contained in `` and enables read access to all agents matched by `` via policy ``: + +```turtle +# Resource: +<#ac1> + a acp:AccessControl ; + acp:apply ; # applies the policy to the container resource + acp:applyMembers . # applies the policy to all resources contained by +``` + +An unauthenticated agent making a GET on `` 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 `` authoritative, and is therefore the information the client can use to decide what credentials to present. + +A unauthenticated agent making a request to `` will receive in the header of a 401 a link to ``. + +```turtle +# Resource: +<#ac1> + a acp:AccessControl ; + acp:apply ; + acp:applyMembers . +``` + +Note that `` is basically a copy of ``. In the current proposal, all resources in ACP have their own associated effective Access Control Resource. + +### WAC + +Bob and Alice are members of the research group ``: + +```turtle +# Resource: +<#g1> + a vcard:Group ; + vcard:hasMember ex:Bob ; + vcard:hasMember ex:Alice . +``` + +The acl enabling read access to all resources contained by `` for all members of group `` is: + +```turtle +# Resource: +<#authorization> + a acl:Authorization ; + acl:agentGroup ; + acl:default <.> ; + acl:mode acl:Read . +``` + +An unauthenticated client making a GET on the `` 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 `` authoritative, and is therefore the information the client can use to decide what credentials to present. + +A unauthenticated client making a GET request to `` will receive in the header of a `401`, either of the following: + +1) a `Link` to ``. +2) a `Link` to `` + +In the case of (1) the client will be able to find out what identity to provide by looking at ``. But if the controller wants to add a new editor to `` then it will have to add that to the root `` as there is no agreed way to create a new acl out of nothing. + +In the case of (2) a controller with the contents of `` will not be applicable, since by the fact of existing `` will override the default. +As a result new access control rules will need to be placed in ``, potentially duplicating what was in the default acl. + +## 2. Changing permissions to a subcollection + +Bob wants to give Carol read/write access to the "2021-04-28" weekly status, and nothing more; that is, to the collection `` and every resource it contains, but not to any other resource in the collection ``. + +(What example from the UCR does this correspond to best?) + +### ACP + +Carol is part of the agent matcher ``: + +```turtle +# Resource: +<#m2> + a acp:AgentMatcher ; + acp:agent ex:Carol . +``` + +The research policy `` gives read access to all agents matched by ``: + +```turtle +# Resource: +<#p2> + a acp:Policy ; + acp:anyOf <#m2> ; + acp:allow acl:Read, acl:Write . +``` + +The access control `` applies to all resources contained by `` and, via policy ``, enables read access for all agents matched by ``: + +```turtle +# Resource: +<#ac1> + a acp:AccessControl ; + acp:apply , ; + acp:applyMembers , . # applies the policy to all resources contained by +``` + +### WAC + +To give Carol read and write access to the `` collection and its content, Bob must create a new effective ACL resource, `` which would express all permissions that are to govern access to ``. + +Todo: How does a client create a new acl if one does not exist before? + + In other words, to maintain the access permissions previously defined in ``, 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 ``. + +```Turtle +# Resource: +<#authorization> + a acl:Authorization ; + acl:agentGroup ; + acl:default <.> ; + acl:mode acl:Read . + +<#new-authorization> + a acl:Authorization ; + acl:agent ex:Carol ; + acl:default <.> ; + acl:mode acl:Read, acl:Write . +``` + +### WAC+ relaxing acl:default + +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 ``, which is the direct effective access control list of ``, 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 ``: + +```Turtle +# Resource: +<#authorization> + a acl:Authorization ; + acl:agentGroup ; + acl:default <.> ; + acl:mode acl:Read . + +<#new-authorization> + a acl:Authorization ; + acl:agent ex:Carol ; + acl:default <./2021-04-28/> ; + acl:mode acl:Read, acl:Write . +``` + +See also: https://github.com/solid/authorization-panel/pull/216#discussion_r665230245 + + +### 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. + +We keep `wac:default` working as currently specified. + +A unauthenticated client that makes a GET on `` and receives a `401` with a `Link` to ``. + +If the client is the controller of the container, it can do a +PUT with the following rules: + +```Turtle +# Resource: +<> + ac:imports <../.acl> . + +<#new-authorization> + a acl:Authorization ; + acl:agent ex:Carol ; + acl:default <.> ; + acl:mode acl:Read, acl:Write . +``` + +In other words, this removes the need to duplicate the `` rule, so any future edits to that rule need only be done in one place. diff --git a/proposals/evaluation/use-cases.md b/proposals/evaluation/use-cases.md new file mode 100644 index 00000000..18150247 --- /dev/null +++ b/proposals/evaluation/use-cases.md @@ -0,0 +1,19 @@ +# Use cases implementation specific comparison + +Within the use cases, the following namespace prefix bindings are used: + +| Prefix | Namespace | +| --------- | ----------------------------------- | +| `acl` | `http://www.w3.org/ns/auth/acl#` | +| `ac` | WAC+ namespace, undetermined | +| `acp` | `http://www.w3.org/ns/solid/acp#` | +| `ex` | `https://example.com/` | +| `ldp` | `http://www.w3.org/ns/ldp#` | +| `vcard` | `http://www.w3.org/2006/vcard/ns#` | + +It is assumed in the example solutions to use cases for both WAC and ACP that +the effective access control resource is represented. + +1. [Resource Access](#) +2. [Collection Access](#) +3. [Access Inheritance Use Cases](./uc-3-inheritance.md)