prior-art: group based access policies

[elf-pavlik]

Followup to #18 (comment)

It mostly captures what I can recall on group access based policies that was discussed in Solid CG. Most likely incompeate but I hope still useful.

[TallTed]

Editorial, relatively minor

[gibsonf1]

@TallTed for Wac groups, the predicate is vcard:hasMember, and there is no need for that to be public (TrinPod only makes those triples public if user wants them public)

[elf-pavlik]

for Wac groups, the predicate is vcard:hasMember, and there is no need for that to be public (TrinPod only makes those triples public if user wants them public)

@gibsonf1 are you refering to the case where groups are used as local groups within a security domain?

In general case we can have a Vcard group which is hosted on one server, for example https://acme.trinpod.us now Alice on https://alice.solidcommunity.net sets access policy using that ACME group. When Bob, who's member of ACME group, makes a request to let's say https://alice.solidcommunity.net/surprise, how solidcommunity.net is supposed to verify that Bob is a member of ACME if https://acme.trinpod.us doesn't publicly list all the members?

[gibsonf1]

for Wac groups, the predicate is vcard:hasMember, and there is no need for that to be public (TrinPod only makes those triples public if user wants them public)

@gibsonf1 are you refering to the case where groups are used as local groups within a security domain?

In general case we can have a Vcard group which is hosted on one server, for example https://acme.trinpod.us now Alice on https://alice.solidcommunity.net sets access policy using that ACME group. When Bob, who's member of ACME group, makes a request to let's say https://alice.solidcommunity.net/surprise, how solidcommunity.net is supposed to verify that Bob is a member of ACME if https://acme.trinpod.us doesn't publicly list all the members?

@elf-pavlik After consultation on the matrix specification channel a couple years ago, we were advised to use vcard:hasMember to capture group members and hierarchies of groups for group access. For example, this group: https://solid-practioners.trinpod.us/i has group members that are not public. In this implementation case (TrinPod), triples are a resource so can have their own acl, and by default triples are private unless given another acl.

[elf-pavlik]

@gibsonf1 I understad, still if I set access policy somewhere on https://elf-pavlik.solidcommunity.net based on https://solid-practioners.trinpod.us/i. When a gruop member, who is not publicly listed, tries to access that protected resource, their access will be denied since solidcommunity.net will not be able to verify their membership in the group.

[TallTed]

@gibsonf1 — re: #31 (comment) — I'm not sure what writing of mine you were responding to. I had fixed some typos, grammar, and the like, in ways that I did not intend to change meaning. If you can point out the specific change to which you were responding, I can review it more carefully.

[gibsonf1]

@elf-pavlik

@gibsonf1 I understad, still if I set access policy somewhere on https://elf-pavlik.solidcommunity.net based on https://solid-practioners.trinpod.us/i. When a gruop member, who is not publicly listed, tries to access that protected resource, their access will be denied since solidcommunity.net will not be able to verify their membership in the group.

This is a good point - simple solution, when https://elf-pavlik.solidcommunity.net does an authenticated fetch on the resource server, the server could simply include a link in the header indicating whether authenticated user is a member of the group (if this is the case)

@gibsonf1 — re: #31 (comment) — I'm not sure what writing of mine you were responding to. I had fixed some typos, grammar, and the like, in ways that I did not intend to change meaning. If you can point out the specific change to which you were responding, I can review it more carefully.

@TallTed this: "WAC acl:agentGroup relies on vcard:Group to list all members." should be "...relies on vcard:hasMember

[TallTed]

[@gibsonf1] @TallTed this: "WAC acl:agentGroup relies on vcard:Group to list all members." should be "...relies on vcard:hasMember

Ah, OK. I just fixed the obvious typo of vcard:Groupa to vcard:Group in what was originally text from @elf-pavlik. I'll add your fix to the stack.

[elf-pavlik]

This is a good point - simple solution, when https://elf-pavlik.solidcommunity.net does an authenticated fetch on the resource server, the server could simply include a link in the header indicating whether authenticated user is a member of the group (if this is the case)

What you suggested doesn't seem to align with the scenario I presented. We probably should check if use cases have similar scenario for group based access policies captured and add olne in case it's missing.

I'm just trying to document prior-art in this PR. Not find a solution for long know issues with WAC and group based policies.

[gibsonf1]

I'm just trying to document prior-art in this PR. Not find a solution for long know issues with WAC and group based policies.

No worries @elf-pavlik , but I think the server reporting if a requestor is a member of a group or not is broader than WAC and not something specific to it. And the issue of members of a group being public or not is also not specific to WAC, but to the implementation.

[elf-pavlik]

And the issue of members of a group being public or not is also not specific to WAC, but to the implementation.

If authorization system relies on verifying group membership this way, it seems to me a part of interop, not an implementation choice.

[gibsonf1]

And the issue of members of a group being public or not is also not specific to WAC, but to the implementation.

If authorization system relies on verifying group membership this way, it seems to me a part of interop, not an implementation choice.

I would chalk it down as a part of interop that was not worked out yet. (But needs to be) As right now, we (TrinPod) use vcard:hasMember hierarchies to work out permissions and group membership in production, but only on pods that use TrinPod servers as there is no interop yet worked out between server providers.

[elf-pavlik]

Those notes are related to this use case: https://w3c.github.io/lws-ucs/spec/#dfn-group-sharing