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

[gibsonf1]

For the case of a group and members being stored on another LWS server:

LWS server A has permissions on a server A resource (ACL) set against a group URI which is for a group resource stored on LWS server B. If the membership of the group resource on server B is private, then how would LWS server A be able to confirm whether a particular agent is in that group to apply the local resource ACL?.

With LWS as currently specified, can server A perform an authenticated fetch using the agent token it has with server B to GET the private group resource?

[elf-pavlik]

With LWS as currently specified, can server A perform an authenticated fetch using the agent token it has with server B to GET the private group resource?

In theory there could be a way that as part of setting acess policy on server A using private group hosted on server B, server A would send an access request to server B, possibly with some purpose. Then this request could be approved or rejected and then the policy on server A could be applied or withdrawn.

This adds quite a bit of extra choreography and could IMO be proposed as one of possible approaches. Hopefully closely evaluated side by side with other approaches for example based on delegation.

This PR doesn't propose any specific approach and only intends to document prior-work that I was able to recall.

If you want you can suggest change that captures this possible approach you are mentioning.

Again @jeswr suggested that I PR notes about prior-art here #18 (comment)

[gibsonf1]

With LWS as currently specified, can server A perform an authenticated fetch using the agent token it has with server B to GET the private group resource?

In theory there could be a way that as part of setting acess policy on server A using private group hosted on server B, server A would send an access request to server B, possibly with some purpose. Then this request could be approved or rejected and then the policy on server A could be applied or withdrawn.

When you say "access policy" here, you are talking about something other than WAC, such as ACP?

[elf-pavlik]

When you say "access policy" here, you are talking about something other than WAC, such as ACP?

No I'm just using a general term, but since ACP at this moment doesn't have direct equivalent of WAC's acl:agentGroup we could just keep this specific issue focused on WAC if you prefer. Especially given that this PR talks about prior-art and not possible future prospects.