A Policy-Oriented Architecture for Enforcing Consent in Solid

COnSeNT 2022 • 26 April 2022

A Policy-Oriented Architecture for Enforcing Consent in Solid

Laurens Debackere, Pieter Colpaert, Ruben Taelman, Ruben Verborgh

Overview

1. An introduction to Solid
   • What is Solid?
   • Authorization in Solid
2. Problem Statement
3. An architecture for enforcing data protection in Solid
4. Discussion
5. Conclusion

An introduction to the Solid project

• Restoring end-users' control over their data
• Brainchild of Sir Tim-Berners Lee
  (cfr. Three Challenges for the Web, 2017)
• Goal: Develop a specification for decentralized personal data storage servers (Pods)

What is Solid?

Graphic by Ruben Verborgh, from Web Fundamentals

• A new way of building applications and services on the Web
  • Separating apps and data
• A new model for data governance
  • Returning user choice to the Web
• By building upon existing Web standards

The Solid specification¹

Linked Data Platform
• Read/write-access to resources
• Specific affordances for handling Linked Data

WebID & Solid OIDC
• Identification and authentication
• In a decentralized manner

Web Access Control
• Define Access Control policy over resources
• Based on Access Control Lists
• Expressed as Linked Data

¹: Based on the Solid Protocol, version 0.9

Authorization in Solid: Web Access Control

Uses concept of WebID to authorize access to resources
• Access control rules at Web Scale
• Works reasonably well in social interactions
Authorization on single resource or folder (container)
• Similar to sharing features in e.g. Google Drive, Dropbox, ...
• Inheritance of permissions

Authorization in Solid: Limitations

• IRIs to identify resources and authorized parties.
  • Resource naming strategy is mostly arbitrary (developer's choice)
  • How does one verify WebID of an agent? (cfr. phishing)
• Inheritance mechanism
  • Can be counter-intuitive
  • Lead to unintended information disclosure
• Ad-hoc nature of permissions ⇒ increase in complexity for end-user

Web Access Control: Example

            @prefix acl: <http://www.w3.org/ns/auth/acl#>.
            # Your doctor has Read & Write Access to your Medical Records
            <#records> a acl:Authorization;
                acl:agent <https://nhs.gov.uk/id/123#me>;
                acl:default <./MedicalRecords/>;
                acl:mode acl:Read, acl:Write.
        

Web Access Control: Example

            @prefix acl: <http://www.w3.org/ns/auth/acl#>.
            # Your doctor has Read & Write Access to your Medical Records
            <#records> a acl:Authorization;
                acl:agent <https://nhs.gov.uk/id/123#me>;
                acl:default <./MedicalRecords/>;
                acl:mode acl:Read, acl:Write.
        

Problem Statement

Web Access Control as an Access Control policy language
• Suited for simple use cases
• Lacks expressivity & interpretability in data processing applications
Limited research into implemention of data sharing patterns in Solid
• With required legal and technical safeguards
Prior research^{1, 2} on applying more expressive policy languages in Solid (i.e. ODRL, SPECIAL, ...)
• Further work needed to integrate these languages into Solid

Research Objective

Identifying shortcomings of Solid's existing Access Control mechanism
• And specifically how it is used by developers.
Reference architecture for complex data processing applications in Solid
• Reconciling end-user and legal requirements for data processing
• Through abstractions built on Solid's existing authorization model
Implementation of this architecture

Related Work

Data Privacy Vocabulary
• Linked Data vocabulary modeling information related to processing of personal data
• Based on requirements from Data Protection regulations
ODRL: The Open Digital Rights Language
• Language for expressing policies using deontic concepts (permission, prohibitions, obligation).
• ODRL profile was proposed, as an extension to Solid's Access Control mechanism
SPECIAL: The SPECIAL policy language
• Research project with the goal of reconciling big data applications with regulatory requirements

Architecture: Background

• Solid's Data Interoperability Panel
  • Objective of enabling safe and effective interoperability
  • Through abstraction of resource organization (Shape Trees)
  • And by standardizing the mechanics of requesting and granting access (Application Interop)
  • Introduces the concept of a trusted "Authorization Agent"
• Linked Data Integrity & Authentication
  • Introduces authentication and data integrity capabilities to Linked Data

Architecture: Vision

End-User Realm
• Governed by Access Management apps
• Higher-level abstractions for classifying data
  (e.g. Personal Data Categories)
• Validating data processing request coming from data controller
• Decision is stored in the subject's Solid Pod

Technical Realm
• Governed by the Authorization Agent
• Resource organization using Shape Trees
• Handles access needs of specific agents
• Based on prior approval through Access Management apps

Architecture: Proposal

• Access Management app delivers Processing Grant
  • Matching against preferences, legal requirements, ...
• Central: Data Subject's Solid Server
  • Personal data organized using Shape Trees
  • Processing Grants by the Access Management app
• Authorization Agent receives concrete Access Needs
  • In terms of Shape Trees
  • Matches these against Processing Grants

Discussion

• Avoids introduction of legal or business concepts into low-level authorization mechanism
  • Layered abstractions on top of Access Control
  • Reduced assumptions on features supported by Solid Pod
• Efficiency of evaluating policies
  • Introduction of an out-of-band negotiation step
  • No additional policy evaluation required during requests
• However, challenges still exist
  • Ex-post compliance checking on Access Control Lists, defining a suitable policy language, ...

Conclusion

• Architecture as a foundation for research into access control and data usage policies
• Built on top of the Solid specification through abstractions
• And some of the more recent community proposals
• Further work is needed from technical, legal and user experience perspectives.

A Policy-Oriented Architecture for Enforcing Consent in Solid