You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: proposals/evaluation/uc-3-inheritance.md
+79-27Lines changed: 79 additions & 27 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -45,7 +45,9 @@ Bob and Alice are part of the agent matcher `</acp/research#m1>`:
45
45
acp:agent ex:Bob, ex:Alice .
46
46
```
47
47
48
-
The research policy `</acp/research#p1>` gives read access to all agents matched by `</acp/research#m1>`:
48
+
`</acp/research>` is visible only to members of the research group.
49
+
50
+
The policy `</acp/research#p1>` gives read access to all agents matched by `</acp/research#m1>`:
49
51
50
52
```turtle
51
53
# Resource: </acp/research>
@@ -65,20 +67,29 @@ The access control `</weekly-status/.acp#ac1>` applies to all resources containe
65
67
acp:applyMembers </acp/research#p1> . # applies the policy to all resources contained by </weekly-status/>
66
68
```
67
69
68
-
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>`.
69
-
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.
70
+
#### a. Accessing `</weekly-status/>`
71
+
72
+
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>`.
73
+
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.
74
+
75
+
[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.
76
+
77
+
#### b. Accessing `</weekly-status/2021-04-28/report.md>`
70
78
71
-
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>`.
79
+
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>`.
80
+
If that actor makes a `GET` request to `<report.acp>` it will receive a graph isomorphic to:
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.
89
+
Note that the triples in `</weekly-status/2021-04-28/report.acp>` are generated from the statements in `</weekly-status/.acp>`.
90
+
All resources covered by an ACP have their own associated effective Access Control Resource.
91
+
92
+
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.
82
93
83
94
### WAC
84
95
@@ -92,7 +103,11 @@ Bob and Alice are members of the research group `</groups/research#g1>`:
92
103
vcard:hasMember ex:Alice .
93
104
```
94
105
95
-
The acl enabling read access to all resources contained by `</weekly-status/>` for all members of group `</groups/research#g1>` is:
106
+
This vcard is visible only to members of the research group.
107
+
108
+
#### a. Accessing `</weekly-status/>`
109
+
110
+
The acl enabling read access to all resources contained in `</weekly-status/>` for all members of group `</groups/research#g1>` is:
96
111
97
112
```turtle
98
113
# Resource: </weekly-status/.acl>
@@ -103,18 +118,29 @@ The acl enabling read access to all resources contained by `</weekly-status/>` f
103
118
acl:mode acl:Read .
104
119
```
105
120
106
-
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>`.
107
-
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.
121
+
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>`.
122
+
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.
123
+
124
+
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)).
125
+
126
+
#### b. Accessing `</weekly-status/2021-04-28/report.md>`
127
+
128
+
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:
As pointed out previously, only the controller and the resource guard can read those; all other actors (e.g., Alice or Bob) need undefined out-of-band knowledge to know how to authenticate. We are therefore limited to the controller actor.
134
+
135
+
In (1), the actor whose Principal is the Controller will be able to determine the credentials it can use from the `acl:default` rules.
108
136
109
-
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:
137
+
In (2), either the `acl` resource has already been created, in which case the default rule of `</weekly-status/.acl>`does not apply, or the `acl` resource has not yet been created, so the default applies, but the client cannot know what the default `acl` is.
110
138
111
-
1) a `Link` to `</weekly-status/.acl>`.
112
-
2) a `Link` to `</weekly-status/2021-04-28/report.acl>`
139
+
### WAC+ acls on acls or extension to modes
113
140
114
-
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.
141
+
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.
115
142
116
-
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.
117
-
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.
143
+
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).
118
144
119
145
## 2. Changing permissions to a subcollection
120
146
@@ -143,7 +169,9 @@ The research policy `</acp/research#p2>` gives read access to all agents matched
143
169
acp:allow acl:Read, acl:Write .
144
170
```
145
171
146
-
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>`:
172
+
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>`.
173
+
174
+
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:
147
175
148
176
```turtle
149
177
# 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
153
181
acp:applyMembers </acp/research#p1>, </acp/research#p2> . # applies the policy to all resources contained by </weekly-status/2021-04-28/>
154
182
```
155
183
184
+
156
185
### WAC
157
186
158
-
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/>`.
187
+
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/>`.
159
188
160
-
Todo: How does a client create a new acl if one does not exist before?
189
+
Todo: How does a client create a new acl if one does not exist before? This is not so easy, as the
190
+
`</weekly-status/2021-04-28/>` can contain one of the following headers
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>`.
195
+
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.
196
+
197
+
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.
163
198
164
199
```Turtle
165
200
# 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?
176
211
acl:mode acl:Read, acl:Write .
177
212
```
178
213
214
+
As soon as this ACL is created, the old ACL will no longer be authoritative.
215
+
216
+
The problem here is that we need to copy many of the statements from `</weekly-status/.acl>` into the new acl; this means that subsequent changes to the root acl will not get automatically propagated, and the more resources there are, the more places will need to be edited to carry through any future changes made to the root acl.
217
+
179
218
### WAC+ relaxing acl:default
180
219
220
+
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.
221
+
181
222
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`.
182
223
183
224
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
199
240
200
241
See also: https://github.com/solid/authorization-panel/pull/216#discussion_r665230245
201
242
243
+
As a result the ACLs 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.
202
244
203
245
### WAC+ ac:imports +acr
204
246
205
-
[WAC+:imports](https://github.com/solid/authorization-panel/issues/210) is explained most easily if we also require every
206
-
resource to link to its own ACR, as ACP does.
247
+
[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.
248
+
This makes it easy for a client to find out where the effective ACR is.
207
249
208
-
We keep `wac:default` working as currently specified.
250
+
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.
209
251
210
-
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/>`.
252
+
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>`.
253
+
When newly created, the container would contain the following triple:
254
+
255
+
```Turtle
256
+
# Resource: </weekly-status/2021-04-28/.ac>
257
+
258
+
<> ac:imports <../.acl> .
259
+
```
260
+
261
+
This allows any client (including the controller's client) to find the default rule by following their nose.
262
+
263
+
The current WAC inheritance algorithm states that the automatic inheritance no longer has effect for a resource that has an ACL, but that does not stop inheritance from from being explicitly used and defined using `ac:imports`.
211
264
212
-
If the client is the controller of the container, it can do a
213
-
PUT with the following rules:
265
+
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:
214
266
215
267
```Turtle
216
268
# Resource: </weekly-status/2021-04-28/.ac>
@@ -224,4 +276,4 @@ PUT with the following rules:
224
276
acl:mode acl:Read, acl:Write .
225
277
```
226
278
227
-
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.
279
+
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.
0 commit comments