[UC] Automated Access and Usage Control

[termontwouter]

As an Authorization Service Provider,
I want to be able to automate aspects of access control, based on less/non-interactive legal grounds,
So that I can provide users with a smooth, automated, hands-off policy management experience.

Preconditions:

• The Resource Owner/Controller can manage its policies and through them express preferences regarding automation of access and usage control, including in which context(s) it is desirable for them.
• Resource Users must be able to make claims that support their request, including the legal ground for data access/usage, and fulfil the preferences of the RO/RC.
• The Authorization Service must be able to automate access/usage control while fulfilling both legal requirements, e.g., there are legal grounds that do not allow full automation (see [UC] Support for Different Legal Grounds #80), and RO/RC preferences.

Trigger:

A Resource User requests access to the RO/RC's resource(s).

Actors:

• [Primary] The Resource Owner/Controller (~ Data Holder/Supplier): an agent who has partial/delegated (controller) or ultimate (owner) control over policies concerning certain resources and wants to have certain controls in place to automate access/usage control in particular contexts.

• [Secondary] The Resource User (~ Data User/Customer): an agent who wants to access resources that are under the control of the RO/RC in an automated manner, typically through a certain Client Application (~ Data Consumer), and as such should present valid claims to do so.

• [Technical] The Resource Server (~ Data Provider): the LWS-compatible system that technically provides the resources.

• [Technical] The Authorization Service: the access management system used by the RO/RC to protect their resources on the RS.

Distinction:

ROs/RCs should be able to express their desired levels of automation for RUs to access/use their resources, e.g., fully automated access for research purposes or for particular types of data. This can, for example, be done through instantiatable policy templates. Moreover, RUs should be able to benefit from automated access/use of resources (while complying with regulatory requirements), as long as a compliant legal ground is presented to access/use the resources. Therefore, the authorization service must be able to support the usage of policy languages that allow ROs/RCs and RUs to define policies with this aspect, allowing for different levels of control over the access/usage of data.

Scenario:

1. The RO/RC accesses their Authorization Service, and creates/updates policies specifying the level of automation, depending on contextual information such as the purpose for access/usage, under which RUs are allowed to access/use their resources.
2. When a RU requests access to a resource, it must provide the necessary claims to allow the automated access to a resource.
3. Comparing the RU request and the RO/RC preferences, the Authorization Service grants or denies the RU access in an automated manner.

Alternative case(s):

NA

Error scenario:

Not all legal grounds allow full automation (e.g. consent for personal data, certain types of sensitive data etc.). They require the interaction of the RO/RC. The Authorization Service should be able to distinguish these, and request RO/RC interaction where needed.

Acceptance Criteria:

• The RO/RC can define abstract policies, leaving certain parameters open to be automatically filled in during a concrete access request.
• The Authorization Service can automatically enforce certain policies, without interaction from the RO/RC.
• Different levels of automation can be handled by the Authorization Service.

References:

This use case would be implemented in the imec.icon project PACSOI (https://www.imec-int.com/en/research-portfolio/pacsoi) and in the SolidLab project (https://solidlab.be/).