As a Resource Owner/Controller,
I want to hide my (high-level) policies from the Resource User,
So that malicious actors cannot use such info to make targeted attacks.

Preconditions:

• A Resource Owner/Controller can manage policies over some resources on an LWS-compatible resource server.
• The Authorization System can perform policy instantiation: deriving concrete policies from abstract/templated ones, to apply to specific acces requests.
• The policy instantiation algorithm takes into account the acceptable level of privacy requirements for policy instantiation.

Trigger:

The Resource User requests access to a resource protected by one or more (abstract/templated) policies of the RO/RC.

Actors:

• [Primary] The Resource User (RU) (~ 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).
• [Secondary] The Resource Owner/Controller (RO/RC) (~ Data Holder/Supplier): an agent who has partial/delegated (controller) or ultimate (owner) control over policies concerning certain resources.
• [Technical] The Authorization Service: the access management system used by the RO/RC to protect their resources on the Resource Server (RS).

Distinction:

The policy instantiation algorithm must translate a (set of) generic policies into a specific instantiated policy that provides enough information for auditing purposes while remaining privacy aware to an acceptable degree.

Scenario:

1. The RU makes a request to a protected resource of the RO/RC
2. The Authorization Service of the RS analyzes the incoming request and matches it with the relevant policies stored available to the authorization services.
3. Based on the policies matching the request, an instantiation algorithm is executed to create an instantiated policy that only includes relevant requirements for the request and converts generic requirements to the specific parameters of the incoming request.
4. Based on this instantiated policy, the Authorization Service can negotiate access.
5. On acceptance, the instantiated policy can be signed, and is provided to the RU together with the data.

Alternative case(s):

• The negotiation can be done based on the matched policies, and only upon acceptance the policy instantiation algorithm is executed to create a policy with the specific usage requirements for the interaction.
• Instantiations of policies can be pre-made and/or cached for recurring access requests.

Error scenario:

NA

Acceptance Criteria:

• The RU only receives request-specific policy requirements during access negotiation.
• The RU receives an instantiated policy when a data request is accepted, detailing the usage control requirements for the data received in the specific request.