Skip to content

prior-art: group based access policies #31

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
elf-pavlik wants to merge 3 commits into from
Closed

prior-art: group based access policies #31

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
9a17db3
prior-art: group based access policies
elf-pavlik Jul 25, 2025
7914ea6
Apply suggestions from code review
elf-pavlik Jul 28, 2025
24ff7eb
Update prior-art/authorization.md
elf-pavlik Jul 28, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
29 changes: 29 additions & 0 deletions prior-art/authorization.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,29 @@
## Solid CG

### Groups

#### Member list

* [WAC `acl:agentGroup`](https://solidproject.org/TR/wac#acl-agentgroup) relies on `vcard:hasMember` to list all members. It has limited applicability to situations where those listings are publicly readable.
* [Members of private group can't access it CSS#1442](https://github.com/CommunitySolidServer/CommunitySolidServer/issues/1442)
* ACP could have reusable matchers that act as group listings (local to the ACP server).
* SAI has a proposal for roles/teams, in which group listings are also local to the security domain.

#### Verifiable Credentials

When listings of group members are not publicly readable, VC representing group membership could be used. In this case, access policy would specify the WebID of a group and the type of a VC (`ex:MembershipCredential`). It would require that the group can issue VCs, and clients used by members can present them to the AS in security domain of a protected resource (for example UMA claims). Authorization system would need to verify that presented credentials were issued by the group designated in the access policy.

#### Delegation

This approach doesn't rely on group membership listings being publicly readable. Authorization policy is set to some group, and that group can delegate it using its internal policies. This approach is also more flexible than a predetermined *member* list or *membership credential*. At least two approaches are bring explored.
* [MANDAT using proxies](https://github.com/w3c/lws-ucs/issues/27)
* SAI using delegated access grants. This includes the following two variants:
* [Support longer delegation chains #222
](https://github.com/solid/data-interoperability-panel/issues/222)
/ [Endpoint to notify the data owner of a new Delegated Data Grant SAI#328
](https://github.com/solid/data-interoperability-panel/issues/328) — ongoing
implementation in https://sai.js.org and https://activitypods.org
* Presenting delegation
as [VC/VP](https://kyledenhartog.com/delegation-in-verifiable-credentials/)
or [ZCAP-LD](https://w3c-ccg.github.io/zcap-spec/)