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.
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.The concepts specified by the ODRL Profile for Access Control are shown in the figure below.
| 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] |
| dcterms | http://purl.org/dc/terms/ | [dcterms] |
| 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] |
| dpv-tech | https://w3id.org/dpv/dpv-tech# | [dpv-tech] |
| acl | http://www.w3.org/ns/auth/acl# | [acl] |
| oac | https://w3id.org/oac# | [oac] |
| ex | https://example.com/ |
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, Technical and Organisational Measures, Technology and Identity Provider constraints (which will require the usage of DPV's taxonomies), new properties to specify policies for applications and services, Processing and Access actions, as well as Personal Data categories, and Entities.
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 properties to specify policies for services and applications, which are important stakeholders in decentralised systems.
| Label: | Preference |
|---|---|
| Identifier: | https://w3id.org/oac#Preference |
| Definition: | A Preference Policy is a soft policy 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:Requirement |
| Label: | Requirement |
|---|---|
| Identifier: | https://w3id.org/oac#Requirement |
| Definition: | A Requirement Policy is a hard policy 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:Preference |
| 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 |
| 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 |
| 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 |
| Label: | Service |
|---|---|
| Identifier: | https://w3id.org/oac#service |
| Definition: | Service used by the recipient of the Rule. |
| Example: | Method used to interact with the data, e.g., identity verification service, query service. |
| Domain: | odrl:Rule, odrl:Policy |
| Range: | dpv-tech:Service |
| Label: | Application |
|---|---|
| Identifier: | https://w3id.org/oac#application |
| Definition: | Application used by the recipient of the Rule. |
| Example: | Application used by the assignee to interact with the data, e.g., address book, game. |
| Domain: | odrl:Rule, odrl:Policy |
| Range: | dpv-tech:Application |
In this section, personal data is defined as an ODRL asset to define personal data-specific access policies.
| 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 |
| Parent class: | dpv:PersonalData |
In this section, access modes and processing operations are defined as ODRL actions to define access policies.
| 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 |
| Parent class: | acl:Access |
| 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 |
| Parent class: | dpv:Processing |
In this section, human and non-human entities are defined as an ODRL party to define user-specific access policies.
| 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, or authorities. |
| Instance of: | odrl:Party |
| Parent class: | dpv:Entity |
In this section, purposes, recipients, legal basis, technical and organisational measures, technologies and identity providers are defined as ODRL constraints to define constraint-restricted access policies.
| 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: ex:purposeConstraint a odrl:Constraint ; odrl:leftOperand oac:Purpose ;odrl:operator odrl:isA ;odrl:rightOperand dpv:ResearchAndDevelopment .indicates that the purpose for the processing of personal data is an instance of dpv:ResearchAndDevelopment. |
| Instance of: | odrl:LeftOperand |
| Parent class: | dpv:Purpose |
| 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: ex:recipientConstraint a odrl:Constraint ; odrl:leftOperand oac:Recipient ;odrl:operator odrl:neq ;odrl:rightOperand ex:UniversityA .indicates that the recipient of the personal data cannot be ex:UniversityA. |
| Instance of: | odrl:LeftOperand |
| Parent class: | dpv:Recipient |
| Label: | Legal Basis |
|---|---|
| Identifier: | https://w3id.org/oac#LegalBasis |
| Definition: | Constraint on the legal basis for which the processing of personal data is permitted or prohibited. |
| Example: | A legal basis can be consent, legitimate interest or contract perfomance or jurisdiction specific legal basis such as the ones provided in GDPR Article 6. |
| Note: | Only the odrl:isA, odrl:eq, odrl:neq, oac:isNotA, oac:subclass or oac:semantic operators SHOULD be used. Example: ex:legalBasisConstraint a odrl:Constraint ; odrl:leftOperand oac:LegalBasis ;odrl:operator odrl:isA ;odrl:rightOperand dpv:Consent .indicates that the legal basis for the processing should be an instance of dpv:Consent. |
| Instance of: | odrl:LeftOperand |
| Parent class: | dpv:LegalBasis |
| 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: ex:tomConstraint a odrl:Constraint ; odrl:leftOperand oac:TechnicalOrganisationalMeasure ;odrl:operator odrl:eq ;odrl:rightOperand dpv:AccessControlMethod .indicates that an access control method should be implemented for the processing to occur. |
| Instance of: | odrl:LeftOperand |
| Parent class: | dpv:TechnicalOrganisationalMeasure |
| Label: | Technology |
|---|---|
| Identifier: | https://w3id.org/oac#Technology |
| Definition: | Constraint on the technologies used for the processing of personal data. |
| Example: | Technologies include communication mechanisms such as WiFi or Bluetooth, security technologies such as PETS, data technologies, operational technologies, identity technologies, and so on. |
| Note: | Only the odrl:isA, odrl:eq, odrl:neq, oac:isNotA, oac:subclass or oac:semantic operators SHOULD be used. Example: ex:technologyConstraint a odrl:Constraint ; odrl:leftOperand oac:Technology ;odrl:operator odrl:isA ;odrl:rightOperand dpv-tech:PET .indicates that a PET should be used for the processing to occur. |
| Instance of: | odrl:LeftOperand |
| Parent class: | dpv:Technology |
| Label: | Identity Provider |
|---|---|
| Identifier: | https://w3id.org/oac#IdentityProvider |
| Definition: | Constraint on the identity provider service used to authenticate a user. |
| Example: | https://solidweb.me or https://login.inrupt.com are examples of Solid identity providers. |
| Note: | Only the odrl:eq, odrl:neq, odrl:isAnyOf or odrl:isNoneOf operators SHOULD be used. Example: ex:idpConstraint a odrl:Constraint ; odrl:leftOperand oac:IdentityProvider ;odrl:operator odrl:isAnyOf ;odrl:rightOperand <https://solidweb.me>, <https://login.inrupt.com> .indicates that used identity provider should be either the <https://solidweb.me> or <https://login.inrupt.com> services. |
| Instance of: | odrl:LeftOperand |
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.
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 .| ACL access mode | DPV processing |
|---|---|
| Read | Use, Collect |
| Write | Store, MakeAvailable |
| Append | ... |
| ... | Share, Transfer |
<https://example.com/agreement1> a odrl:Agreement ;
dcterms:description "Agreement to read behavioral data for research and development purposes" ;
dcterms:creator ex:userA ;
dcterms:issued "2022-11-08T18:13:37"^^xsd:dateTime ;
odrl:uid ex:agreement1 ;
dcterms: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 ] ] .
<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 .
<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
] .
User A issued a Preference that permits read access operations over its behavioral data for the purpose of research and development.
<https://example.com/preference1> a oac:Preference ;
dcterms:description "Preference to read behavioral data for research and development purposes" ;
dcterms:creator ex:userA ;
dcterms: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 ] ] .
User A issued a Requirement that obliges its assignee to read identifier data only for the purpose of identity verification.
<https://example.com/requirement1> a oac:Requirement ;
dcterms:description "Requirement to read identifier data for identity verification purposes" ;
dcterms:creator ex:userA ;
dcterms: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 ] ] .
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.
<https://example.com/offer1> a odrl:Offer ;
dcterms:description """Offer to read identifier data for identity verification
and behavioral data for research and development""" ;
dcterms:source ex:preference1, ex:requirement1 ;
dcterms:creator ex:userA ;
dcterms: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 [
dcterms: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 [
dcterms:title "Purpose for access is to verify the identity of the assigner." ;
odrl:leftOperand oac:Purpose ;
odrl:operator odrl:isA ;
odrl:rightOperand dpv:IdentityVerification ] ] .
User B makes a request to use behavioral data for research and development in the context of project X.
<https://example.com/request1> a odrl:Request;
dcterms:description "Request to use behavioral data for research and development purposes" ;
dcterms:creator ex:userB ;
dcterms: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 [
dcterms: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." .
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.
<https://example.com/agreement1> a odrl:Agreement ;
odrl:profile oac: ;
dcterms:description "Agreement to read behavioral data for research and development purposes" ;
dcterms:creator ex:userA ;
dcterms:issued "2022-11-08T18:13:37"^^xsd:dateTime ;
odrl:uid ex:agreement1 ;
dcterms: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 [
dcterms: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 ] ] .
User A prohibits write access operations over its browsing behavior data if the purpose is not commercial research.
<https://example.com/policy2> a oac:Preference ;
dcterms:description "Prohibition to write browsing behavior data if the purpose is not commercial research" ;
dcterms:creator ex:userA ;
dcterms: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:BrowsingBehavior ;
odrl:constraint [
odrl:leftOperand oac:Purpose ;
odrl:operator oac:isNotA ;
odrl:rightOperand dpv:CommercialResearch ] ] .
User A allows read access operations over its educational qualification data if the purpose is a subclass of research and development such as academic research, non-commercial research or commercial research.
<https://example.com/policy3> a oac:Preference ;
dcterms:description "Permission to read educational qualification data if the purpose is a subclass of research and development" ;
dcterms:creator ex:userA ;
dcterms:issued "2022-11-09T09:17:13"^^xsd:dateTime ;
odrl:uid ex:policy3 ;
odrl:profile oac: ;
odrl:permission [
odrl:assigner ex:userA ;
odrl:action oac:Read ;
odrl:target oac:EducationQualification ;
odrl:constraint [
odrl:leftOperand oac:Purpose ;
odrl:operator oac:subclass ;
odrl:rightOperand dpv:ResearchAndDevelopment ] ] .
User A allows write access operations over its TV viewing behavior data for the purpose
of academic research using https://example.com/serviceA .
<https://example.com/policy4> a oac:Preference ;
dcterms:description "Permission for service A to write TV viewing behavior data if the purpose is academic research" ;
dcterms:creator ex:userA ;
dcterms: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:TVViewingBehavior ;
odrl:constraint [
odrl:leftOperand oac:Purpose ;
odrl:operator odrl:isA ;
odrl:rightOperand dpv:AcademicResearch ] ] .
User A allows User B to perform write access operations over its location data for the purpose
of providing a service using https://example.com/applicationA .
<https://example.com/policy5> a oac:Preference ;
odrl:profile oac: ;
dcterms:description "Permission for User B to write location data using application A if the purpose is related to provide a service requested by the user" ;
dcterms:creator ex:userA ;
dcterms: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:Location ;
odrl:constraint [
odrl:leftOperand oac:Purpose ;
odrl:operator odrl:isA ;
odrl:rightOperand dpv:RequestedServiceProvision ] ] .
| 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? |
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.