ODRL Profile for Expressing Consent through Granular Access Control Policies in Solid

Solid, the emerging technology for organizing data in decentralized stores, relies on a simple authorization mechanism for granting access to data. Solid's personal online datastores (Pods) are ideal for keeping personal data, as they allow individuals to represent the access permissions in a very simple manner using Access Control Language (ACL) expressions. Whereas these expressions suffice for yes/no and read/write permissions, they cannot represent more complex rules nor invoke regulation-specific concepts.
This work describes an extension of the ACL language and the algorithm to implement consent and data requests. This extension is based on the Open Digital Rights Language (ODRL) policy language, which allows expressing rich rules, and the Data Privacy Vocabulary (DPV), which permits invoking privacy and data protection-specific terms.

Motivation

Legal compliance
a) Document activities and maintain provenance regarding personal data processing, requests for access, notices and subsequent use logs to conduct a GDPR Data Audit;
b) Determine applicable rights, obligations, and requirements based on jurisdictional laws or contextually e.g. specific categories of personal data;
c) Evaluate, assess, or validate if obligations and requirements are fulfilled;
d) Implement GDPR security requirements.
about
about
User-defined preferences for data sharing and use
a) Express human-centric preferences e.g. willingness to share particular data for research, or prohibition of profiling and surveillance;
b) Granularity for specifying broad permissions, e.g. permit data use for scientific research, or prohibit any third party data collection;
c) Granularity for specifying narrow permissions, e.g. permit sharing contact details for a specific app, prohibit accessing a confidential resource;
d) Conflict resolution going from local to global, e.g. generally prohibiting sharing of location, but making an exception for specific services.
Transparency of data practices
a) Individuals want to know who is using which data categories, for what purposes, sharing it with whom, and under what legal basis;
b) Individuals want to understand permissions/authorisations they already have provided based on self-defined context, e.g. for specific services or organisations, or based on purposes, or categories of personal data;
c) Organisations may want to specify their data policies in machine-readable forms that can be accessed by users.
about

Competency Questions

ODRL Profile for Access Control in Solid
1. Purpose
The purpose of this profile of ODRL is to support policies determining the access control to personal data stored in Solid pods.
2. Scope
The scope of this profile is limited to the definition of an ODRL Profile for Access Control in Solid. In particular, the introduced elements will serve one of these purposes: (i) define actions supporting enforcement of current ACL verbs, (ii) define data protection-related actions and restrictions defined in GDPR, (iii) any vocabulary element to support policy patterns that can be anticipated to be common, and (iv) elements necessary to support the authorization reasoning decision.
3. Implementation Language
OWL
4. Intended End-Users
Developers of Solid servers and Solid clients.
5. Intended Uses
Use 1. Declaration of a policy by an individual storing personal data in a pod.
Use 2. Request of data made by a person or application to gain access to the data in different modalities.
Use 3. Contextual elements to be considered in the authorization decision.
Use 4. Explanation of the authorization decision.
6. Ontology Requirements
a. Non-Functional Requirements
NFR 1. The ontology shall be published online with standard documentation.
b. Functional Requirements: Groups of Competency Question
CQG1. Related to authorization CQG2. Related to GDPR
CQ1. Which actions are to be authorized?
CQ2. Which requirements are to be authorized?
CQ3. Who are the parties intervening in policy?
CQ4. Which is the priority of a certain policy?
CQ5. Which are the contextual elements to be considered in the authorization decision?
CQ6. Which obligations and requirements, and information about personal data and its processing are necessary?
CQ7. Which is the legal identification of the policy parties?

Resources

Solid

Solid is a specification and implementation of decentralized data stores, which decouples data from applications, based on interoperable data formats and protocols.

Solid Technical Reports

ODRL

Rights expression language that provides a model and vocabulary to express information about permissions, prohibitions and duties related to digital assets.

Information Model Vocabulary & Expression

DPV

Data privacy vocabulary that provides a taxonomy of terms to annotate and categorize the handling of personal data in accordance with established data protection regulations.

DPV specification DPV-GDPR extension

ODRL Profile

diagram

Examples

Request to use data for Registration purposes
:app-1 a odrl:Policy ;
odrl:profile oac: ;
odrl:permission [
a odrl:Permission ;
odrl:assignee [
a oac:DataController ;
cert:key <https://example-app-1.com>
] ;
odrl:target oac:EmailAddress, oac:SocialNetwork ;
odrl:action oac:Use, oac:Store ;
odrl:constraint [
odrl:leftOperand oac:Purpose ;
odrl:operator odrl:isA ;
odrl:rightOperand dpv:RegistrationAuthentication
]
] .
Read-only policy for Contact for R&D Purposes
:policy-1 a odrl:Policy ;
odrl:profile oac: ;
odrl:permission [
a odrl:Permission ;
odrl:assigner [
a oac:DataSubject ;
cert:key <https://anne.databox.me/profile/card#me>
] ;
odrl:target oac:Contact ;
odrl:action oac:Read ;
odrl:constraint [
odrl:leftOperand oac:Purpose ;
odrl:operator odrl:isA ;
odrl:rightOperand dpv:ResearchAndDevelopment
]
] .
Request to collect and share anonymised Health Records
:app-2 a odrl:Policy ;
odrl:profile oac: ;
odrl:assignee [
a oac:DataController ;
cert:key <https://example-app-2.com>
] ;
odrl:target oac:HealthRecord, oac:Prescription, oac:HealthHistory ;
odrl:permission [
a odrl:Permission ;
odrl:action oac:Collect, oac:Copy ;
odrl:constraint [
odrl:leftOperand oac:Purpose ;
odrl:operator odrl:isA ;
odrl:rightOperand dpv:AcademicResearch
]
] ;
odrl:permission [
a odrl:Permission ;
odrl:action oac:Anonymise, oac:MakeAvailable ;
odrl:constraint [
odrl:leftOperand oac:Recipient ;
odrl:operator odrl:isA ;
odrl:rightOperand dpv:ThirdParty
]
] .
Prohibition to share resource /docs/file1 with more than 3 third parties
:policy-2 a odrl:Policy ;
odrl:profile oac: ;
odrl:prohibition [
a odrl:Prohibition ;
odrl:assigner [
a oac:DataSubject ;
cert:key <https://anne.databox.me/profile/card#me> ;
] ;
odrl:target <https://anne.databox.me/docs/file1> ;
odrl:action oac:Share ;
odrl:constraint [
odrl:leftOperand oac:Recipient ;
odrl:operator odrl:gt ;
odrl:rightOperand "3"^^xsd:integer
]
] .

Demo

testimonial-1

Beatriz Esteves

PhD Candidate at Ontology Engineering Group, Universidad Politécnica de Madrid, Spain

testimonial-2

Harshvardhan J. Pandit

Research Fellow at ADAPT Centre, Trinity College Dublin, Ireland

testimonial-3

Víctor Rodríguez-Doncel

Associate Professor at Ontology Engineering Group, Universidad Politécnica de Madrid, Spain

Acknowledgements

This research has been supported by European Union’s Horizon 2020 research and innovation programme under the Marie Skłodowska-Curie grant agreement No 813497 (PROTECT).