reading of ACL resource should be reduced to requiring client to have Read rights. #250
Conversation
acl:Control is about editability of a resource, not readability. There are use cases for making ACLs readable in order to guarantee [privacy of the client](https://solid.github.io/authorization-panel/authorization-ucr/#uc-minimalcredentials). There are ways to extend ACL so that ACLs become readable, see [ACLs on ACLs](solid/authorization-panel#189), and this is also needed by ACP. Having the default be as it currently is specified in WAC that ACLs be only visible to those who control them, is a default choice that can be defended. But closing doors to valid use cases is not.
create was too hastily removed.
|
To cover discoverability I would be fine with text such as the following:
|
bblfish
changed the title
|
My vote is also to have default behavior be that an acl is an acl of itself unless the acl has its own acl. (This is how our current acl algorithm is operating) |
|
@gibsonf1 I am in favor of having ACLs of ACLs and of an ACL being its own ACL :-) It would be useful to open a separate PR for that. I am not sure where though. Here I am just proposing to remove 2 words that could make it seem like the behavior you have implemented was not legal. |
|
Thanks for highlighting the problematic text and a clarification for it. Closing this PR as agreed in favour of #252 |
bblfish
changed the title
3 participants
The ACL ontology states:
This clearly gives read/write access to the controller. But that is different from disallowing read access to anyone else, which is what the removed text stated.
There are use cases for making ACLs readable in order to guarantee privacy of the client. There are ways to extend ACL so that ACLs become readable, see ACLs on ACLs, and this is also needed by ACP.
Having the default be as it currently is specified in WAC that ACLs be only visible to those who control them, when no other information is available, is a default choice that makes sense. But closing doors to valid use cases that would allow such extensions is not justifiable.