[UC] (Micro-)Contract-based Compensation for Access

[termontwouter]

As a Resource Owner/Controller,
I want to allow access to resources based on (micro-)contracts,
So that I can exchange resource access for something else, e.g., a financial compensation.

Preconditions:

• The Resource Owner/Controller can manage its policies and allow access to resources, based on a contract, in exchange for compensation, e.g., financial, access to a service, etc.
• Resource Users must establish the compensation they are willing to provide.
• The Authorization Service is aware of the compensations which might be requested/provided to have access to resources.

Trigger:

• A Resource User requests access to the RO/RC's resource(s);
• the RO/RC themselves want to grant access to the RU; or
• the RO/RC wants to set up a general policy (template).

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 exchange resource access for something else, i.e., compensation. For this use case, the RO/RC is a person with no significant technical skills, managing their policies through a graphical interface.

• [Secondary] The Resource User (~ Data User/Customer): an agent who wants to access resources that are under the control of the RO/RC, typically through a certain Client Application (~ Data Consumer), and is willing to provide compensation for such access.

• [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 receive compensation for RUs to access their resources in certain scenarios. For example, under the General Data Protection Regulation (GDPR), if the resource contains personal data, the access is possible using contract as the legal ground, however not possible if the legal ground justifying the access is consent. As such, in the context of resources containing personal data, this issue has a connection with issue #80. Therefore, the authorization service must be able to support the usage of policy languages that allow ROs/RCs to define different types of compensation that they are willing to receive and RUs to fulfil in order to have access to the resource. Moreover, RUs must be able to provide proof of the fulfilment of the compensation, whether it is done ex-ante, e.g., pay a fee to have access to the resource, or ex-post, e.g., return the results of the usage of the resource for something.

Scenario:

1. The RO/RC accesses their Authorization Service, and creates/updates policies specifying which compensation they are expecting for RUs to access/use their resources.
2. When a RU requests access to a resource, it must declare the compensation that it will provide to have access to the resource.
3. If the compensation declared by the RU fulfills the RO/RC expectations, then RU is granted access to the resource and RO/RC receives proof of the fulfilment of the compensation; if not, RO/RC and RU need to negotiate an acceptable compensation for both parties.

Alternative case(s):

In cases where negotiation of compensation conditions is not possible, if RU does not fulfill the RO/RC expectations, then access is not granted.

Error scenario:

NA

Acceptance Criteria:

• The RO/RC can define its own policies, e.g., through templates.
• Different compensation types can be handled by the Authorization Service.
• The Authorization Service correctly enforces the policies across all resources, interfaces/protocols, and (aggregated/derived) views.

References: