ODRL Profile for Access Control in Solid

1. Acknowledgments

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) and `Datos 4.0 Retos y Soluciones' (TIN2016-78011-C4-3-R). Harshvardhan J. Pandit is funded by the Irish Research Council Government of Ireland Postdoctoral Fellowship Grant#GOIPD/2020/790; European Union's Horizon 2020 research and innovation programme under NGI TRUST Grant#825618 for Project#3.40 Privacy-as-Expected: Consent Gateway; and by the ADAPT SFI Centre for Digital Media Technology which is funded by Science Foundation Ireland through the SFI Research Centres Programme and is co-funded under the European Regional Development Fund (ERDF) through Grant#13/RC/2106_P2.

2. Introduction

Solid is a specification [solid-protocol] for decentralised personal data stores (called `Pods') that uses linked data and Web standards to achieve user control and interoperability. The access to data stored within Solid Pods is governed by the Web Access Control (WAC) specification [wac] which uses IRIs to represent resources and agents, and stores authorisation statements within Access Control Lists (ACL) defined per resource or inherited from the parent resource. Therefore, in Solid, the user controlling the ACL is the entity responsible for deciding who has access to the data.

Given that Solid provides a way for personal data to be stored and managed by individuals, it is important to consider the impact and application of data protection and privacy laws such as the European General Data Protection Regulation (GDPR) that define specific concepts and obligations for how personal data can be collected, stored, used, and shared. In addition, such laws also specify various rights and the legal basis used to justify using the data and the conditions for their validity. In particular, GDPR's Articles 13 and 14 require controllers to provide information such as identity, purpose, personal data categories, legal basis, and recipients where they collect personal data directly or indirectly from individuals.

Applied to Solid, this information can be presented using conventional methods, such as a notice provided on the data requester's website, and the resulting authorisation decision made by the individual stored within the ACL. However, for individuals to control their data practices, the Solid Pod must contain this information as well so that the individual has the opportunity to:

(i) inspect their personal data within an environment under their control;

(ii) store it for accountability purposes;

(iii) determine their data sharing preferences; and

(iv) be assisted in expressing and enforcing their data sharing preferences.

To achieve these goals, the following requirements motivate our approach to extend Solid’s existing ACL mechanism using the ODRL Vocabulary and Expression specification to define ‘sticky policies’ that express permissions and / or prohibitions associated with data stored in a Solid Pod and utilises DPV as a controlled vocabulary for invoking privacy and data protection-specific terms.

R1. Support specifying user preferences as policies.

R2. Incorporate vocabulary specifying or aligned to legal concepts.

R3. Support specifying permissions and prohibitions at arbitrary granularity.

R4. Support identifying and resolving conflicts based on scope.

R5. Record (store) policies used to authorise access.

R6. Support querying policies and authorisations for introspection of data use.

2.2 Profile diagram

The concepts specified by the ODRL Profile for Access Control in Solid are shown in the figure below.

3. Profile specification

This ODRL profile relies on the invocation of legal concepts using DPV and ACL for the reference to access mode operations. Its core concepts are Purpose, Personal Data Categories, Processing, Access and Legal Entities.

4. Examples

4.1 User Preference 1 - Read-only policy for Contact for R&D Purposes

Anne, as identified by her WebID https://anne.databox.me/profile/card#me, permits read access operations over her contact data for the purpose of research and development.

        
          :example-4-1 a odrl:Policy ;
            odrl:profile oac: ;
            odrl:permission [
              a odrl:Permission ;
              odrl:assigner :anne ;
              odrl:target oac:Contact ;
              odrl:action oac:Read ;
              odrl:constraint [
                odrl:leftOperand oac:Purpose ;
                odrl:operator odrl:isA ;
                odrl:rightOperand dpv:ResearchAndDevelopment
              ] 
            ] .
      
          :anne a oac:DataSubject ;
            cert:key "https://anne.databox.me/profile/card#me" .
        
      

4.2 User Preference 2 - Prohibition to share resource /docs/file1 with third parties

Anne, as identified by her WebID https://anne.databox.me/profile/card#me, prohibits the sharing of a resource stored on her Pod, located at https://anne.databox.me/docs/file1, with more than 3 recipients.

        
          :example-4-2 a odrl:Policy ;
            odrl:profile oac: ;
            odrl:prohibition [
              a odrl:Prohibition ;
              odrl:assigner :anne ;
              odrl:target "https://beatriz.databox.me/docs/file1" ;
              odrl:action oac:Share ;
              odrl:constraint [
                odrl:leftOperand oac:Recipient ;
                odrl:operator odrl:gt ;
                odrl:rightOperand "3"^^xsd:integer
              ]
            ] .
      
          :anne a oac:DataSubject ;
            cert:key "https://anne.databox.me/profile/card#me" .
        
      

4.3 App Policy 1 - Request to use data for Registration purposes

App 1, as identified by their URL https://example-app-1.com, requests permission to use and store the email address and social network information of users for the purpose of registering and authenticating to their service.

        
          :example-4-3 a odrl:Policy ;
            odrl:profile oac: ;
            odrl:permission [
              a odrl:Permission ;
              odrl:assignee :app-1-controller ;
              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
              ]
            ] .
    
          :app-1-controller a oac:DataController ;
            cert:key "https://example-app-1.com" .
        
      

4.4 App Policy 2 - Request to collect and share anonymised Health Records

App 2, as identified by their URL https://example-app-2.com, requests permission to collect and produce a copy of the health records, medical prescriptions and health history of users for the purpose of performing academic research and make the anonymised information available to third parties.

        
          :example-4-4 a odrl:Policy ;
            odrl:profile oac: ;
            odrl:assignee :app-2-controller ;
            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
              ]
            ] .
        
          :app-2-controller a oac:DataController ;
            cert:key "https://example-app-2.com" .