Access by server to group listing is not on behalf od user

[timbl]

The current text:

"WebID-TLS Delegation. If your implementation uses the WebID-TLS authentication method, it also needs to implement the ability to delegate its requests on behalf of the original user."

The original user (the one requesting the resource whose access is to be checked, I assume) is not the one accessing the group file. The server itself needs to get access. It could have its own webid. You can imagine situations where the person accessing the resource does so because she is a Student but she does not have access to the list of all people in class Student.

Even the person writing the ACL could give access to people in class Student without being able to read the list. (We could decide to not support that feature, and make the server's access deemed to be a delegation of the resource owner's access. We could require the person setting the ACL to get a signed copy of the list -- signed by the owner of the file -- and hand it to the data store which then keeps it.)

Other possibilities are for servers to trust each other. Or for group lists to be copies by client code onto many servers.....

[dmitrizagidulin]

As discussed with @timbl today at lunch, this is a non-trivial design challenge, with an unclear solution. Our plan is to currently implement a group listing prototype with the assumption that group lists on remote servers will be public for the moment.

[elf-pavlik]

The server itself needs to get access. It could have its own webid.

👍

App creating ACL and using acl:agentGroup could attempt non authenticated request to WebID of a group and in case of receiving 401 response warn the person about it. For non publicly visible groups often agent which wants to add group to the ACL also will have control over profile of that group and its ACL so can create authorization for the server agent to access profile of the group.