Use case: group membership vc

[elf-pavlik]

This use case presents scenario of group based access which doesn't require public group member list. Neither party granting access maintaining their own list of members in group they grant access to.

EDIT: https://solid.github.io/authorization-panel/wac-ucr/#capabilities-vc provides more complicated use case which depends on existence of broader trust network. Use case in this PR only requires membership credential issued by a known party. It also directly addresses known issues with group based access where list of group members is not accessible to the guard enforcing access policy.

[justinwb]

Really good use case, just a few nitpicky grammar suggestions

[elf-pavlik]

Once we have this UC merged I will create Issue where we can iron out how Credentials and Capabilities could interplay in this scenario.

[bblfish]

In the discussion on capabilities in issue 160 @elf-pavlik made a refinement to the use case which improves it a lot.

@elf-pavlik wrote:

Thinking about variations of #157, Omni Corp. could grant read/write (not control) access to Acme Corp. for project A, B and C. Now Acme wants to delegate read/write access for Project A to team X and read/write access to Project B to team Y.

I responded:

These restrictions are starting to make more sense of your Acme use case. Without them it sounds like Omni is giving access to the entirety of its web site to Acme Corp, suggesting a takeover had just happened.

[elf-pavlik]

I've changed store front to projects A, B and C to make it little more specific and fit other project oriented scenarios.

In #160 we are also discussing it with variant of Acme having distinct teams and wanting to have granular control which Acme team can access which Omni project.