Jump to Table of Contents Collapse Sidebar

ODRL Profile for Access Control

Draft release

Version: 0.2
Latest editor's draft:
https://w3id.org/oac
Editors:
(Ontology Engineering Group, Universidad Politécnica de Madrid)
(ADAPT Centre, Trinity College Dublin)
(Ontology Engineering Group, Universidad Politécnica de Madrid)
Previous versions:
v.01
Participate:
GitHub profile
File a bug
Commit history
Pull requests
Download serialization:
TTL
License:
CC-BY 4.0

Abstract

This document presents a new profile, the ODRL Profile for Access Control (OAC), that extends the WAC access control list mechanism by using the Open Digital Rights Language (ODRL) to define access control policies that express permissions and / or prohibitions associated with data stored in a decentralised storage environment and utilises the Data Privacy Vocabulary (DPV) as a controlled vocabulary for invoking privacy and data protection-specific terms.

1. Introduction

The Web Access Control (WAC) specification [wac] is a "decentralized cross-domain access control system" that uses Linked Data [ld] and URIs to store authorisation conditions within Access Control Lists (ACL) to define access of Web agents to Web resources. Amongst other uses, it is used in the Solid ecosystem as a tool to determine the access to data stored within Solid Pods - therefore, in Solid the user controlling the ACL is the entity responsible for deciding who has access to the data. Solid is a specification [solid-protocol] for decentralised personal data stores (called `Pods') that uses Web standards and semantic technologies to achieve user control and interoperability. Therefore, the usage of the ODRL profile for Access Control (OAC) will be demonstrated through the Solid ecosystem as it is an example implementation of a decentralised environment for the sharing of personal data. However, it should be clear that OAC is not Solid-dependent and can be deployed in other environments as it does not rely in any Solid-specific vocabularies.

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) [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 when 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 through 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 the existing ACL mechanism using the ODRL Vocabulary and Expression [odrl-vocab] specification to define access control policies that express permissions and / or prohibitions associated with data stored in a decentralised storage system such as Solid Pods and utilises the Data Privacy Vocabulary (DPV) [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.

Therefore, these policies will add a new layer to decentralised storage systems, which is currently missing from the Solid ecosystem for instance, that will be placed below the access authorisation layer in order to provide a richer access control mechanism to such systems.

1.1 Profile diagram

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

ODRL Profile for Access Control

1.2 Document Conventions

Prefix Namespace Description
odrl http://www.w3.org/ns/odrl/2/ [odrl-vocab] [odrl-model]
rdf http://www.w3.org/1999/02/22-rdf-syntax-ns# [rdf11-concepts]
rdfs http://www.w3.org/2000/01/rdf-schema# [rdf-schema]
owl http://www.w3.org/2002/07/owl# [owl2-overview]
dct http://purl.org/dc/terms/ [dct]
vann http://purl.org/vocab/vann/ [vann]
xsd http://www.w3.org/2001/XMLSchema# [xsd]
skos http://www.w3.org/2004/02/skos/core# [skos]
dpv https://w3id.org/dpv# [dpv]
dpv-pd https://w3id.org/dpv/dpv-pd# [dpv-pd]
acl http://www.w3.org/ns/auth/acl# [acl]
oac https://w3id.org/oac# [oac]
ex https://example.com/

2. 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 the Preference and Requirement policies, a new set of operators to constraint the defined Purposes, Recipients, Legal Basis and Technical and Organisational Measures constraints (which will require the usage of DPV's taxonomies), new party roles to specify policies for applications and services, Processing and Access actions, as well as Personal Data Categories, and Legal Entities.

2.1 Base Concepts

In this section, two new types of policies are specified to deal with the requirements of users which wish to define rules for the processing of their personal data, as well as a set of three new ODRL operators which we believe are currently missing from the ODRL Core vocabulary and two new party roles to specify policies for services and applications, which are important stakeholders in decentralised systems.

2.1.1 Policies

2.1.1.1 Preference
Label: Preference Policy
Identifier: https://w3id.org/oac#PreferencePolicy
Definition: A Preference Policy is a soft rule that expresses the assigner's preferences over an Asset which MAY not be satisfied.
Note: A Preference Policy MUST contain at least one Permission or Prohibition rule, an Action, a target Asset and a Party with Assigner function (in the same Permission or Prohibition). The Preference Policy MAY contain a Party with Assignee, Application and/or Service functions, but MUST not grant any privileges to those Parties.
Example: If a preference policy set by a party A does not match a request policy from party B, the request can still be accepted if party A accepts party B's request conditions.
Parent class: odrl:Policy
Disjoint classes: odrl:Agreement, odrl:Offer, odrl:Privacy, odrl:Request, odrl:Ticket, odrl:Assertion, oac:RequirementPolicy
2.1.1.2 Requirement
Label: Requirement Policy
Identifier: https://w3id.org/oac#RequirementPolicy
Definition: A Requirement Policy is a hard rule that expresses the assigner's preferences over an Asset which MUST be satisfied.
Note: A Requirement Policy MUST contain at least one Permission or Prohibition rule, an Action, a target Asset and a Party with Assigner function (in the same Permission or Prohibition). The Requirement Policy MAY contain a Duty, Party with Assignee, Application and/or Service functions, but MUST not grant any privileges to those Parties.
Example: If a requirement policy set by a party A does not match a request policy from party B, the request must be denied even if party A accepts party B's request conditions.
Parent class: odrl:Policy
Disjoint classes: odrl:Agreement, odrl:Offer, odrl:Privacy, odrl:Request, odrl:Ticket, odrl:Assertion, oac:PreferencePolicy

2.1.2 Operators

2.1.2.1 Is not a
Label: Is not a
Identifier: https://w3id.org/oac#isNotA
Definition: Indicates that a given Left Operand is not an instance of the Right Operand of the Constraint.
Example: The purpose constraint of a rule can not be an instance of a academic research.
Instance of: odrl:Operator
2.1.2.2 Subclass
Label: Subclass
Identifier: https://w3id.org/oac#subclass
Definition: Indicates that a given Left Operand is a subclass of the Right Operand of the Constraint.
Example: The purpose constraint of a rule can be a subclass of research and development such as academic research, non-commercial research or commercial research.
Instance of: odrl:Operator
2.1.2.3 Semantic
Label: Semantic
Identifier: https://w3id.org/oac#semantic
Definition: Indicates that a given Left Operand is equal to, an instance or a subclass of the Right Operand of the Constraint.
Example: The purpose constraint of a rule can be research and development, an instance of research and development or one of its subclasses such as academic research, non-commercial research or commercial research.
Instance of: odrl:Operator

2.1.3 Party roles

2.1.3.1 Service
Label: Service
Identifier: https://w3id.org/oac#service
Definition: The Party is the service used by the recipient of the Rule.
Example: Method used to interact with the data, e.g., identity verification service, query service.
Parent property: odrl:function
2.1.3.2 Application
Label: Application
Identifier: https://w3id.org/oac#application
Definition: The Party is the application used by the recipient of the Rule.
Example: Application used by the assignee to interact with the data, e.g., address book, game.
Parent property: odrl:function

2.2 Personal Data

Label: Personal Data
Identifier: https://w3id.org/oac#PersonalData
Definition: Data directly or indirectly associated or related to an individual.
Example: Data assets related to an individual include financial data such as credit card or account numbers, social data such as marital status or friends, health data such as health records or blood type and so on.
Instance of: odrl:Asset, dpv:PersonalData

2.3 Actions

2.3.1 Access

Label: Access
Identifier: https://w3id.org/oac#Access
Definition: Modes used to access resources, e.g. stored in Solid Pods.
Example: The ACL vocabulary includes Read, Write and Append access modes.
Instance of: odrl:Action, acl:Access

2.3.2 Processing

Label: Processing
Identifier: https://w3id.org/oac#Processing
Definition: Processing operations performed on personal data.
Example: DPV includes processing operations such as use, collect, adapt or infer.
Instance of: odrl:Action, dpv:Processing

2.4 Entities

Label: Entity
Identifier: https://w3id.org/oac#Entity
Definition: A human or non-human party that constitutes an entity.
Example: Entities can refer to individuals, organisations, institutions, authorities, or non-human parties such as services or applications.
Subclass of: odrl:Party, dpv:Entity

2.5 Constraints

2.5.1 Purpose

Label: Purpose
Identifier: https://w3id.org/oac#Purpose
Definition: Constraint on the purpose for which the processing of personal data is permitted or prohibited.
Example: DPV includes purposes such as academic research, customer care or identity verification.
Note: Only the odrl:isA, odrl:eq, odrl:neq, oac:isNotA, oac:subclass or oac:semantic operators SHOULD be used. Example: oac:Purpose odrl:isA dpv:ResearchAndDevelopment indicates that the purpose for the processing of personal data is an instance of dpv:ResearchAndDevelopment.
Instance of: odrl:LeftOperand, dpv:Purpose

2.5.2 Recipient

Label: Recipient
Identifier: https://w3id.org/oac#Recipient
Definition: Constraint on the recipients that may receive the results of the processing of personal data.
Example: A recipient can be any entity receiving personal data, including data subjects, controllers, non profit organisations or non governmental organisations.
Note: Only the odrl:isA, odrl:eq, odrl:neq, oac:isNotA, oac:subclass or oac:semantic operators SHOULD be used. Example: oac:Recipient odrl:neq ex:UniversityA indicates that the recipient of the personal data cannot be ex:UniversityA.
Instance of: odrl:LeftOperand, dpv:Recipient

2.5.4 Technical and Organisational Measure

Label: Technical and Organisational Measure
Identifier: https://w3id.org/oac#TechnicalOrganisationalMeasure
Definition: Constraint on the technical and/or organisational measures used to ensure a secure processing of personal data.
Example: Technical measures include access control methods, encryption and other security protocols. Organisational measures include notices, guidelines, policies, agreements and other organisational procedures.
Note: Only the odrl:isA, odrl:eq, odrl:neq, oac:isNotA, oac:subclass or oac:semantic operators SHOULD be used. Example: oac:TechnicalOrganisationalMeasure odrl:eq dpv:AccessControlMethod indicates that an access control method should be implemented for the processing to occur.
Instance of: odrl:LeftOperand, dpv:TechnicalOrganisationalMeasure

3. Validation of policies with SHACL

4. Matching requests for data

In this section, the followed architecture to implement the usage of OAC in Solid is discussed.

The SOPE (Solid's ODRL access control Policies Editor) application can be used to automatically generate OAC policies and store them in a specific container of a Solid Pod.

To match data requests for specific data types, when an app, service or user generates and stores data in a Pod, in addition to the storage operation, needs to label the generated resources with the data type they contain. For this, we suggest the usage of the Extended Personal Data categories for DPV (DPV-PD) specification, which contains a set of more than 200 personal data types.

Matching sequence diagram

4.1 Associate resources with DPV-PD types

Using DPV-PD it is possible to associate Solid Pod resources with the data type they contain.

<https://my-solid-pod/private/health/file1> dpv:hasPersonalData dpv-pd:HealthHistory .
NOTE: More instructions in this procedure will be added in the near future.

4.2 Mapping ACL verbs to DPV processing

ACL access mode DPV processing
Read Use, Collect
Write Store, MakeAvailable
Append ...
... Share, Transfer
The Solid WAC specification has a proposal to include new ACL verbs: acl:Update, acl:Create, acl:Delete - see solid/web-access-control-spec/issues/85
Issue in the Solid WAC specification to remove acl:Control access mode - see solid/web-access-control-spec/issues/94

4.3 Mapping results of the matching with ACP/ACL

new properties might be needed in ACP/ACL to connect the granted authorization with the users policies, app request, …
Agreement
    
<https://example.com/agreement1> a odrl:Agreement ;
dct:description "Agreement to read behavioral data for research and development purposes" ;
dct:creator ex:userA ;
dct:issued "2022-11-08T18:13:37"^^xsd:dateTime ;
odrl:uid ex:agreement1 ;
dct:references ex:offer1, ex:request1 ;
odrl:profile oac: ;
odrl:permission [
  odrl:assigner ex:userA ;
  odrl:assignee ex:userB ;
  odrl:action oac:Read ;
  odrl:target oac:Behavioral ;
  odrl:constraint [
    odrl:leftOperand oac:Purpose ;
    odrl:operator odrl:isA ;
    odrl:rightOperand dpv:ResearchAndDevelopment ] ] .
    
Derived ACL authorization
    
<https://example.com/aclAuthorization1> a acl:Authorization ;
  acl:accessTo :TemplateResource ; # find resources that contain dpv-pd:Behavioral
  acl:agent ex:userB ;
  acl:mode acl:Read .
  
Derived ACP grant
    
<https://example.com/acpGrant1> a acp:AccessGrant ;
  acp:grant acl:Read ;
  acp:context [
    acp:agent ex:userB ;
    acp:target :TemplateResource ; # find resources that contain dpv-pd:Behavioral
    acp:mode acl:Read
  ] .

5. Examples

5.1 Preference policy

User A issued a Preference that permits read access operations over its behavioral data for the purpose of research and development.

Example 5.1
<https://example.com/preference1> a oac:PreferencePolicy ;
  dct:description "Preference to read behavioral data for research and development purposes" ;
  dct:creator ex:userA ;
  dct:issued "2022-11-02T11:08:05"^^xsd:dateTime ;
  odrl:uid ex:preference1 ;
  odrl:profile oac: ;
  odrl:permission [
    odrl:assigner ex:userA ;
    odrl:target oac:Behavioral ;
    odrl:action oac:Read ;
    odrl:constraint [
      odrl:leftOperand oac:Purpose ;
      odrl:operator odrl:isA ;
      odrl:rightOperand dpv:ResearchAndDevelopment ] ] .
      

5.2 Requirement policy

User A issued a Requirement that obliges its assignee to read identifier data only for the purpose of identity verification.

Example 5.2
<https://example.com/requirement1> a oac:RequirementPolicy ;
  dct:description "Requirement to read identifier data for identity verification purposes" ;
  dct:creator ex:userA ;
  dct:issued "2022-11-08T16:30:15"^^xsd:dateTime ;
  odrl:uid ex:requirement1 ;
  odrl:profile oac: ;
  odrl:permission [
    odrl:assigner ex:userA ;
    odrl:target oac:Identifier ;
    odrl:action oac:Read ;
    odrl:constraint [
      odrl:leftOperand oac:Purpose ;
      odrl:operator odrl:isA ;
      odrl:rightOperand dpv:IdentityVerification ] ] .
      

5.3 Offer policy

User A issued an Offer that requires its assignee to read identifier data only for identity verification and allows read access operations over its behavioral data for research and development. This offer is a combination that derives from the https://example.com/preference1 and https://example.com/requirement1 policies as indicated by the dct:source property.

Example 5.3
    
<https://example.com/offer1> a odrl:Offer ;
  dct:description """Offer to read identifier data for identity verification 
      and behavioral data for research and development""" ;
  dct:source ex:preference1, ex:requirement1 ;
  dct:creator ex:userA ;
  dct:issued "2022-11-08T17:26:35"^^xsd:dateTime ;
  odrl:uid ex:offer1 ;
  odrl:profile oac: ;
  odrl:permission [
    dpv:hasContext dpv:Optional ;
    odrl:assigner ex:userA ;
    odrl:target oac:Behavioral ;
    odrl:action oac:Read ;
    odrl:constraint [
      dct:title "Purpose for access is to conduct research and development." ;
      odrl:leftOperand oac:Purpose ;
      odrl:operator odrl:isA ;
      odrl:rightOperand dpv:ResearchAndDevelopment ] ] ;
  odrl:permission [
    dpv:hasContext dpv:Required ;
    odrl:assigner ex:userA ;
    odrl:target oac:Identifier ;
    odrl:action oac:Read ;
    odrl:constraint [
      dct:title "Purpose for access is to verify the identity of the assigner." ;  
      odrl:leftOperand oac:Purpose ;
      odrl:operator odrl:isA ;
      odrl:rightOperand dpv:IdentityVerification ] ] .
      

5.4 Request policy

User B makes a request to use behavioral data for research and development in the context of project X.

Example 5.4
    
<https://example.com/request1> a odrl:Request;
  dct:description "Request to use behavioral data for research and development purposes" ;
  dct:creator ex:userB ;
  dct:issued "2022-11-08T17:58:31"^^xsd:dateTime ;
  odrl:uid ex:request1;
  odrl:profile oac: ;
  odrl:permission [
    odrl:assignee ex:userB ;
    odrl:action oac:Use ;
    odrl:target oac:Behavioral ;
    odrl:constraint [
      dct:title "Purpose for processing is to conduct research in the R&D project X." ;
      odrl:leftOperand oac:Purpose ;
      odrl:operator odrl:eq ;
      odrl:rightOperand ex:RDProjectX ] ] .

ex:RDProjectX a dpv:ResearchAndDevelopment ;
  rdfs:label "Conduct research in the R&D project X." .
      

5.5 Agreement policy

User A and B agree to allow read access over user A's behavioral data for research and development. This agreement is the result of the matching of https://example.com/offer1 and https://example.com/request1, as indicated by the dct:references property.

Example 5.5
    
<https://example.com/agreement1> a odrl:Agreement ;
  odrl:profile oac: ;  
  dct:description "Agreement to read behavioral data for research and development purposes" ;
  dct:creator ex:userA ;
  dct:issued "2022-11-08T18:13:37"^^xsd:dateTime ;
  odrl:uid ex:agreement1 ;
  dct:references ex:offer1, ex:request1 ;
  dpv:hasDataSubject ex:userA ;
  dpv:hasDataController ex:userB ;
  dpv:hasLegalBasis dpv:Consent ;
  odrl:permission [
    odrl:assigner ex:userA ;
    odrl:assignee ex:userB ;
    odrl:action oac:Read ;
    odrl:target oac:Behavioral ;
    odrl:constraint [
      dct:title "Purpose for processing is to conduct research in the R&D project X." ;
      odrl:leftOperand oac:Purpose ;
      odrl:operator odrl:eq ;
      odrl:rightOperand ex:RDProjectX ] ] .
      

5.6 Policy with is not a operator

User A prohibits write access operations over its behavioral data if the purpose is not commercial research.

Example 5.6
    
<https://example.com/policy2> a oac:PreferencePolicy ;
  dct:description "Prohibition to write behavioral data if the purpose is not commercial research" ;
  dct:creator ex:userA ;
  dct:issued "2022-11-09T09:14:10"^^xsd:dateTime ;
  odrl:uid ex:policy2 ;
  odrl:profile oac: ;
  odrl:permission [
    odrl:assigner ex:userA ;
    odrl:action oac:Write ;
    odrl:target oac:Behavioral ;
    odrl:constraint [
      odrl:leftOperand oac:Purpose ;
      odrl:operator oac:isNotA ;
      odrl:rightOperand dpv:CommercialResearch ] ] .
      

5.7 Policy with subclass operator

User A allows write access operations over its behavioral data if the purpose is a subclass of research and development such as academic research, non-commercial research or commercial research.

Example 5.7
    
<https://example.com/policy3> a oac:PreferencePolicy ;
  dct:description "Permission to write behavioral data if the purpose is a subclass of research and development" ;
  dct:creator ex:userA ;
  dct:issued "2022-11-09T09:17:13"^^xsd:dateTime ;
  odrl:uid ex:policy3 ;
  odrl:profile oac: ;
  odrl:permission [
    odrl:assigner ex:userA ;
    odrl:action oac:Write ;
    odrl:target oac:Behavioral ;
    odrl:constraint [
      odrl:leftOperand oac:Purpose ;
      odrl:operator oac:subclass ;
      odrl:rightOperand dpv:ResearchAndDevelopment ] ] .
      

5.8 Policy with service party

User A allows write access operations over its behavioral data for the purpose of research and development using https://example.com/serviceA .

Example 5.8
    
<https://example.com/policy4> a oac:PreferencePolicy ;
  dct:description "Permission to write behavioral data if the purpose research and development using service A" ;
  dct:creator ex:userA ;
  dct:issued "2022-11-09T09:22:42"^^xsd:dateTime ;
  odrl:uid ex:policy4 ;
  odrl:profile oac: ;
  odrl:permission [
    odrl:assigner ex:userA ;
    oac:service ex:serviceA ;
    odrl:action oac:Write ;
    odrl:target oac:Behavioral ;
    odrl:constraint [
      odrl:leftOperand oac:Purpose ;
      odrl:operator odrl:isA ;
      odrl:rightOperand dpv:ResearchAndDevelopment ] ] .
      

5.9 Policy with application and assignee parties

User A allows User B to perform write access operations over its behavioral data for the purpose of research and development using https://example.com/applicationA .

Example 5.9
    
<https://example.com/policy5> a oac:PreferencePolicy ;
  odrl:profile oac: ;
  dct:description "Permission for User B to write behavioral data if the purpose research and development using application A" ;
  dct:creator ex:userA ;
  dct:issued "2022-11-17T12:32:18"^^xsd:dateTime ;
  odrl:uid ex:policy5 ;
  odrl:permission [
    odrl:assigner ex:userA ;
    odrl:assignee ex:userB ;
    oac:application ex:applicationA ;
    odrl:action oac:Write ;
    odrl:target oac:Behavioral ;
    odrl:constraint [
      odrl:leftOperand oac:Purpose ;
      odrl:operator odrl:isA ;
      odrl:rightOperand dpv:ResearchAndDevelopment ] ] .
      

A Ontology Requirement Specification Document

TODO: update ORSD
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
RDF, RDFS
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?

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

C. References

[acl]
Basic Access Control ontology . 2009. URL: http://www.w3.org/ns/auth/acl#
[dct]
DCMI Metadata Terms . DCMI Usage Board. DCMI. 20 January 2020. DCMI Recommendation. URL: https://www.dublincore.org/specifications/dublin-core/dcmi-terms/
[dpv]
Data Privacy Vocabulary (DPV) version 1. Axel Polleres; Beatriz Esteves; Bert Bos; Bud Bruegger; David Hickey; Elmar Kiesling; Eva Schlehahn; Fajar J. Ekaputra; Georg P. Krog; Harshvardhan J. Pandit; Javier D. Fernández; Julian Flake; Mark Lizar; Paul Ryan; Piero Bonatti; Ramisa Gachpaz Hamed; Rigo Wenning; Rob Brennan; Simon Steyskal. 5 December 2022. URL: https://w3id.org/dpv
[dpv-pd]
DPV-PD: Extended Personal Data categories for DPV version 1. Axel Polleres; Beatriz Esteves; Bert Bos; Bud Bruegger; David Hickey; Elmar Kiesling; Eva Schlehahn; Fajar J. Ekaputra; Georg P. Krog; Harshvardhan J. Pandit; Javier D. Fernández; Julian Flake; Mark Lizar; Paul Ryan; Piero Bonatti; Ramisa Gachpaz Hamed; Rigo Wenning; Rob Brennan; Simon Steyskal. 5 December 2022. URL: https://w3id.org/dpv/dpv-pd
[gdpr]
Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation). URL: https://eur-lex.europa.eu/eli/reg/2016/679/oj
[ld]
Linked Data . Tim Berners-Lee. 18 June 2009. URL: https://www.w3.org/DesignIssues/LinkedData.html
[odrl-model]
ODRL Information Model 2.2 . Renato Iannella; Serena Villata. W3C. 15 February 2018. W3C Recommendation. URL: https://www.w3.org/TR/odrl-model/
[odrl-vocab]
ODRL Vocabulary & Expression 2.2 . Renato Iannella; Michael Steidl; Stuart Myles; Víctor Rodríguez-Doncel. W3C. 15 February 2018. W3C Recommendation. URL: https://www.w3.org/TR/odrl-vocab/
[owl2-overview]
OWL 2 Web Ontology Language Document Overview (Second Edition) . W3C OWL Working Group. W3C. 11 December 2012. W3C Recommendation. URL: https://www.w3.org/TR/owl2-overview/
[rdf-schema]
RDF Schema 1.1 . Dan Brickley; Ramanathan Guha. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf-schema/
[rdf11-concepts]
RDF 1.1 Concepts and Abstract Syntax . Richard Cyganiak; David Wood; Markus Lanthaler. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf11-concepts/
[skos]
SKOS Simple Knowledge Organization System Reference . Alistair Miles; Sean Bechhofer. W3C. 18 August 2009. W3C Recommendation. URL: https://www.w3.org/TR/skos-reference/
[xsd]
W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes . David Peterson; Sandy Gao; Ashok Malhotra; Michael Sperberg-McQueen; Henry Thompson; Paul V. Biron et al. W3C. 5 April 2012. W3C Recommendation. URL: https://www.w3.org/TR/xmlschema11-2/
[solid-protocol]
Solid Protocol . Sarven Capadisli; Tim Berners-Lee; Ruben Verborgh; Kjetil Kjernsmo; Justin Bingham; Dmitri Zagidulin. 7 July 2021. URL: https://solidproject.org/TR/protocol
[vann]
VANN: A vocabulary for annotating vocabulary descriptions . Ian Davis. 1 April 2005. URL: http://purl.org/vocab/vann/
[wac]
Web Access Control . Sarven Capadisli. 11 July 2021. URL: https://solid.github.io/web-access-control-spec/