search

solid / authorization-panel

Github repository for the Solid Authorization Panel
MIT License
19 stars 20 forks source link

Use case: group membership vc #157

Closed elf-pavlik closed 3 years ago

elf-pavlik commented 3 years ago

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.

elf-pavlik commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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.