Consider adding acl:originGroup

[michielbdejong]

Just a thought, for symmetry with how acl:agentGroup can be used as a level of indirection between the ACL doc and the list of actual acl:agent webid's, maybe it would be powerful to have a similar level of indirection between the ACL doc and the list of actual acl:origin apps.

[kjetilk]

Yeah, but aren't we trying to move away from origins as a basis for app identification?

[zenomt]

the authorization and access control panel has been exploring the general problem of app permissions, including that the user should be free to choose which apps to use (or not use) to access different classes of resources, that the user can potentially lie to a resource server about what app she's using, that the resource owner classifies her resources, and that the resource server enforces access controls.

i have proposed one possible solution to this problem space in that panel where the resource owner assigns "scope tag patterns" (which will probably be URIs but can also use wildcards) to different permission modes for resources, and the user assigns scope tag patterns to her different apps, on a per-resource-origin (including a default) and per-permission-mode basis (read to the end of the Issue for that part). to be determined in this proposal is how the user learns what tag vocabularies are used at an origin in order to manage her app privileges.

[elf-pavlik]

Yeah, but aren't we trying to move away from origins as a basis for app identification?

👍

Since we talk about OAuth2 Clients we could generally talk about client and clientGroup. To further distinguish software agents (OAuth Clients) from social agents (User / OAuth Resource Owners) we could talk in terms:

• user and userGroup - social agents
• client and clientGroup - software agents

On the social layer, users would give access to other users and groups of users (eg. organizations), which requires acl:Control access to the resource. On the software layer users could independently delegate some subset of their access to clients of their choice, which should not require acl:Control mode on the resource and possibly would get managed by user associated authorization server.