User Story: Evaluation of "Access by Policy" not set by the Resource Owner to allow access to Vetted Agents required by local law

[uvdsl]

User Story

As a resource controller, i.e., an agent that is able to set and modify access control rules on particular (sets of) resources, I need to allow a certain defined set of agents to access the resource (potentially "overruling" access control rules set by a resource owner).

[uvdsl]

I would like to share a user story from my practical experience. I would like to challenge my understanding of my solution to this using WAC. If this use case is a duplicate or use cases for WAC are better documented elsewhere, I'd appreciate a pointer.

Context

In the use case that this user story stems from, the resource owner itself has certain control rights. To comply with local law, use-case dependent resources MUST be available to use-case dependent (vetted and thus trusted) agents. Therefore, the sponsors of this user study see the requirement to "overrule" a resource owner's set of access control rules.

Please note that the fact that such a functionality might be desired or necessary for a particular use case does not mean that this functionaltiy is applicable to or should be used in any and all use cases or deployments of WAC.

Solution using WAC

I believe WAC is quite easily able to satisfy this use case.

Rather than thinking of this functionality as "overruling" a set of user defined rules, I suggest to consider that this particular user story first of all considers extending the set of agents that are allowed to access particular (sets of) resources.

This means that the set of access control rules, which is maintained by the resource controller (with full control rights) and where the resource owner only has limited rights to update rules, can include rules like the following.

Using acl:agentGroup to link to the group of vetted and thus trusted agents, which can of course be cached and updated using pull or push mechanisms:

# example access control rule to satisfy access policy requirement
<#byControllerForAgentsByPolicy>
    a acl:Authorization;
    acl:agentGroup <https://official.example.org/policy123#conformingAgentsGroup>;
    acl:accessTo <./resource>;
    acl:mode acl:Read .

Using acl:agentClass to link to the group of vetted and thus trusted agents, where additional evaluation logic is required to determine whether a requesting agent is or can be considered a member of that vetted and trusted agent class (e.g., using a custom claim in the access token):

# example access control rule to satisfy access policy requirement
<#byControllerForAgentsByPolicy>
    a acl:Authorization;
    acl:agentClass <https://official.example.org/policy123#conformingAgents>;
    acl:accessTo <./resource>;
    acl:mode acl:Read .

I believe it is worth noting that the particular setup in this use case requires that the resource owner only has limited access rights to the effective ACL of the resources in question. To allow for that, a particular subclass of acl:Control might express exactly such limited control rights (https://solidproject.org/TR/wac#access-mode-extensions), e.g., ex:ResourceOwnerControl.

As far as I understand,

• this is allowed by WAC,
• how a system decides to validate an agent's request to update/modify effective ACL resources (or only parts thereof) is not restricted by WAC,
• this poses merely a system design decision to satisfy a particular use case.

If my understanding of the above is incorrect, I'd appreciate a constructive correction!