As a (not tech-savvy) Resource Owner/Controller,
I want to set policies on data types (e.g., photo album, contact info, heart rate measurement),
So that I can manage access across resources, based on an intuitive conceptual model, without any technical knowledge.

Preconditions:

• The Resource Owner/Controller can manage policies over some resources on an LWS-compatible resource server.
• The Authorization Service, and possibly the LWS RS, are aware of a certain characteristics of resources, such as their data type/shape.

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. 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).

• [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:

Any non-trivial access/usage control scenario will involve managing policies over a large amount of resources. Being able to define policies that target groups of resources, rather than individual ones, is therefore a must. This use-case highlights the need for an intuitive conceptualisation of such groups, which will seem most natural to the typical RO/RC, such as a categorisation based on data type.

Technical challenges:

• Linking a machine-readable delineation of a data type (e.g., a file format, SHACL shape …) with a human-readable description of it (without opening up human-centered attack vectors).
• Providing sufficient information for an intuitive interface that allows non-technical users to set access policies.

Scenario:

1. The Resource Owner/Controller accesses the Authorization Service, either by their own initiative or in response to some notification.
2. They select the intuitive data group (e.g., data type) they want to set policies/templates for, and specify who can access such data and under what conditions.
3. The system applies these policies to all access requests concerning resources of the selected data type.

Alternative case(s):

• The Resource Owner/Controller reacts to an access request notification by their Authorization Service, which already includes a data group/type to which the Resource User requests access. The RO/RC can accept or deny the request, or set additional constraints.
• For certain resources that are of the same data type, the RO/RC uses this feature to apply the same policies to any new resource of that type that is created in the future.
• For other resources that are of the same data type, the RO/RC uses this feature to apply the policies only to the currently existing resources.

Error scenario:

• The Authorization Service fails to recognize a data type, either of a resource under its protection or as part of an access request, or it does not succeed in presenting it in an understandable way to the RO/RC.
• Some resources could be classified in multiple different groups/types, which could lead to conflicting policies.

Acceptance Criteria:

• The Resource Owner/Controller can easily set and manage access policies based on data types without needing technical knowledge.
• Relying Parties can request access to data of a certain type.
• The Authorization Service correctly enforces the policies across all resources of the selected data type.

References:

Bingham, Justin, Eric Prud'hommeaux, and elf Pavlik (eds.). 2024. ‘Access Descriptions'. In Solid Application Interoperability (W3C Solid CG Draft CGR). https://solid.github.io/data-interoperability-panel/specification/#access-descriptions
Knublauch, Holger, and Dimitris Kontokostas (eds.). 2017. Shapes Constraint Language (SHACL) (W3C Recommendation). https://www.w3.org/TR/shacl/
Prud'hommeaux, Eric, et al. 2019. Shape Expressions Language 2.1 (W3C Shex CG Final CGR). https://shex.io/shex-semantics/