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
It is considered an anti-pattern for a client to perform those steps, however. A client may discover and load a document’s individual resource (for example, for the purposes of editing its permissions). If such a resource does not exist, a client SHOULD NOT search for, or interact with, the inherited ACLs from an upstream container.
This seems on the whole unjustified.
Why is it an anti-pattern? This is not explained. If the rule for the server is that access control rules must be applied in this way, then why can the client not follow the same pattern itself? (we can assume there is a Link relation to a container for example)
How is a client to know what the Access Control Rules for a resource is, if the access control Rule is not linked from the primary resource?
If the client cannot find out what the access control rule is, then either the client looses privacy by being forced to try out different credentials (see Minimal Credential Disclosure use case) or not knowing how to authenticate it may not be able to access a resource it has the right to access.
If access to a access-control resource is not ok, then one option would be to return all the access control information relevant to a resource in the returned 401. But that comes with its own problems, such as what mime-type to send the answer back in (e.g. on a 401 on a picture or video), or how this can play correctly with servers that wish to return a human readable response. Furthermore returning all the information in the response body means that one is not able to structure access levels to different parts of the Access-Control Rules, which is possible with linked-to resources. A simple example is given in the ACRs on ACRs comment which shows how one can have parts of an access control rule visible and others hidden.
Having linked access control rules allows one to have hierarchies of access to the rules. One ACR may require one prove that one is a Citizen of a certain country, the next that one is part of an institution (a bank, the army, ...) and the third level could state that one needs to prove the grade that one has in that organization. (say for security classified documents, where the fact that a document is secured should only be known to trusted members)
The limitations is currently unwarranted. If there are reasons as to why it is "bad practice" it should be discussed and clarified.
A better way to do this would be instead to have Access Control Resources link to the access control resources they inherit from explicitly. This follows the principle of client/server symmetry: if the server has rules on how to follow links, the client must be able to follow those same rules.
The text was updated successfully, but these errors were encountered:
Closing this issue as consensus is deemed to be captured in WAC Editor's Draft: https://solid.github.io/web-access-control-spec/ . See #effective-acl-resource-algorithm that can be used by clients and servers.
The WAC spec has the following text:
This seems on the whole unjustified.
If the client cannot find out what the access control rule is, then either the client looses privacy by being forced to try out different credentials (see Minimal Credential Disclosure use case) or not knowing how to authenticate it may not be able to access a resource it has the right to access.
If access to a access-control resource is not ok, then one option would be to return all the access control information relevant to a resource in the returned 401. But that comes with its own problems, such as what mime-type to send the answer back in (e.g. on a 401 on a picture or video), or how this can play correctly with servers that wish to return a human readable response. Furthermore returning all the information in the response body means that one is not able to structure access levels to different parts of the Access-Control Rules, which is possible with linked-to resources. A simple example is given in the ACRs on ACRs comment which shows how one can have parts of an access control rule visible and others hidden.
Having linked access control rules allows one to have hierarchies of access to the rules. One ACR may require one prove that one is a Citizen of a certain country, the next that one is part of an institution (a bank, the army, ...) and the third level could state that one needs to prove the grade that one has in that organization. (say for security classified documents, where the fact that a document is secured should only be known to trusted members)
The limitations is currently unwarranted. If there are reasons as to why it is "bad practice" it should be discussed and clarified.
A better way to do this would be instead to have Access Control Resources link to the access control resources they inherit from explicitly. This follows the principle of client/server symmetry: if the server has rules on how to follow links, the client must be able to follow those same rules.
The text was updated successfully, but these errors were encountered: