A core feature of the Solid ecosystem is enabling the sharing of data resources with other agents using access control policies. However, the decision of allowing access (or not) to a given data resource may not be final and might need to change over time. The Solid authorization specifications do not allow expressing and thus neither enforcing complex constraints (e.g., temporal) on access or more generally, usage policies. A policy language that does have the expressivity to declare permission rules, including temporal constraints, is the Open Digital Rights Language (ODRL) W3C standard. To support and enforce ODRL policies over Solid resources, we design and implement a Web agent-based solution where an agent (i) decomposes ODRL policies into actionable tasks (such as granting and retracting access to resources) using declarative condition-action rules and; (ii) takes care of executing such tasks. Usage control within Solid can be delegated to agents such that neither applications nor users within the ecosystem need to ensure that access permissions over their data resources are valid and up to date. We show how the expressivity limitations for usage control of the current Solid specifications could be addressed by supporting ODRL via long-running Web agents with the task of enforcement. Since currently all data-sharing actions within the Solid ecosystem are manually executed by the owner of the resource, future work includes automating policy-based negotiation processes among actors through Web agents.
The Solid protocol 1 is a Personal Data Store Web technology that enables individuals to store and govern data on their data space, in Solid terminology also referred to as pod. A Solid server must support at least one of the two authorization specifications, namely the Web Access 2nd Solid Symposium, 2-3 May 2024, Leuven * Corresponding author.
wout.slabbinck@ugent.be (W. Slabbinck); julianandres.rojasmelendez@ugent.be (J. A. Rojas); beatriz.esteves@UGent.be (B. Esteves); ruben.verborgh@ugent.be (R. Verborgh); pieter.colpaert@ugent.be (P. Colpaert) https://woutslabbinck.com/ (W. Slabbinck); https://julianrojas.org/ (J. A. Rojas); https://besteves4.github.io/ (B. Esteves); https://ruben.verborgh.org/ (R. Verborgh); https://pietercolpaert.be/ (P. Colpaert) 0000-0002-3287-7312 (W. Slabbinck); 0000-0002-6645-1264 (J. A. Rojas); 0000-0003-0259-7560 (B. Esteves); 0000-0002-8596-222X (R. Verborgh); 0000-0001-6917-2167 (P. Colpaert) Control (WAC) 2 specification and/or the Access Control Policy (ACP) Language 3 , such that a user can declare access control rules over resources in their pod. To this date, however, these specifications do not support fine-grained access rules with temporal conditions. As a result, users must either for revocation re-configure the access control resources again after access was granted, or use a Solid application that can perform the granting and revoking access. However, neither option is infallible. In the first option, users must adjust rules to revoke access, yet human forgetfulness may allow unintended authorizations to persist. For the second option, due to the Web-based nature of the Solid protocol, the application must remain open and active for revocation to occur. This means that a Web client application is not sufficient. The first aspect to overcome the limitations of current specifications is to use another standard which supports fine-grained conditions to declare and enforce policies such as the Open Digital Rights Language (ODRL) 4 W3C standard [1]. Since Solid only supports the aforementioned specifications, ODRL can not directly be enforced. However, it is possible to partially materialize ODRL to existing access rules that the Solid protocol can enforce. Furthermore, a continuously running Web service is required to overcome the manual and Web client revocation limitation.
In this paper, we extend an open-source, rule-based Web agent [2] to (i) perceive policies from an ODRL policy Knowledge Graph (KG), managed by the resource owner, (ii) interpret those ODRL policies and transform them to Access Control Resources (ACR) rules as defined by ACP, and (iii) perform long-running tasks to enforce temporal usage control policies.
Sambra et al. [3] introduced Solid with the aim of letting users control their data on the Web by decoupling data from applications. To reach this goal, the protocol builds upon existing W3C standards and specifications to define a data storage, commonly referred to as Solid pod despite the lack of a precise definition [4]. The Linked Data Platform5 (LDP) W3C standard [5] is leveraged in Solid to read and write to this storage, which consists of a collection of resources. An agent is identified through a WebID 6 and through Solid-OIDC 7 the claim of their identity can be verified by an authoritative Identity Provider (IDP). The current access control protocols, WAC and ACP, allow users to define which party (or agent) can act on a given resource.
However, complying with the General Data Protection Regulation (GDPR) [6] is impossible since extra requirements such as the purpose of data use (Article 13.1(c) and Article 14.1(c)) and retention period (Article 13.2(a) and Article 14.2(a)) can neither be encoded in WAC nor ACP. To overcome these challenges, Esteves et al. [7] introduced the ODRL Profile for Access Control 8 (OAC) which aims to align access and usage permissions with GDPR for Solid. This is achieved through modelling usage control policies with the Open Digital Rights Language 1), (ii) Alice updating the UCP KG with a duration-restricted policy ( 2), (iii) the agent listening and fetching the policy (3), planning its tasks through reasoning (4) and executing them (5,7), and (iv) Bob having access for 30 seconds (6,8).
(ODRL) [1] and using the Data Privacy Vocabulary (DPV) 9 [8] for representing data processing aspects. Usage control policies can model purpose and temporal constraints, where the latter could address the retention requirement. To the best of our knowledge, however, there is to this day no enforcement of ODRL policies and, by extension, no AOC enforcement mechanism. In general, Havur et al. [9] state that the enforcement of usage control in a decentralized setting is an open research challenge. Akaichi et al. contributed to this research problem by introducing a conceptual usage control framework to achieve continuous enforcement of usage control in a decentralized ecosystem [10].
An alternative approach for enforcing access control has been introduced by Grau et al. [11] through a demonstration of agent-based access control enforcement. However, this approach is limited by its reliance on ad-hoc rules tailored to their specific use case. Furthermore, it does not accommodate additional conditions such as the temporal domain.
To demonstrate the enforcement of a temporal ODRL policy, we elaborate the use case of a Solid pod owner, Alice, who wants to share resource X for a limited amount of time with another actor Bob. It is assumed she has a policy Knowledge Graph (KG) to which her Web agent is subscribed and that the Web agent has acl:Control permission to the resources in Alice her pod.
To start sharing resource X, Alice adds the data usage ODRL policy shown in Listing 1 to the KG: Alice gives read access to Bob for the duration of 30 seconds. Next, the agent is notified that the policy has been added to the Usage Control Policy (UCP) KG and the agent fetches this policy. The duration policy is passed to a reasoner, which results in an action plan with two concrete actions to be performed: (i) The authorization resource of X must be updated such that Bob has read access and (ii) In 30 seconds, the authorization resource of X must be updated such that Bob has no longer access. The agent performs (i) and starts a CronJob for 30 seconds to remove Bob's access to X. Finally, after 30 seconds have passed, the agent sends another request to the authorization resource of X such that Bob has no more access. A screencast in the open-source Solid Agent GitHub repository demonstrates the enforcement flow10 described at the beginning of this section and illustrated in 1.
ex:policy a odrl:Offer; odrl:permission ex:temporalPermission.
ex:temporalPermission a odrl:Permission ; odrl:action odrl:read ; odrl:constraint ex:durationConstraint ; odrl:target ex:resourceX ; odrl:assignee ex:Bob .
ex:durationConstraint odrl:leftOperand odrl:elapsedTime ; odrl:operator odrl:eq ; odrl:rightOperand "PT30S"^^xsd:duration .
Listing 1: A duration-restricted ODRL policy issued by Alice stating that Bob has read access to resource X for a duration of 30 seconds.
The Solid Agent operates in the environment of the UCP KG and the Solid pod of Alice. Where in the former, the agent listens to changes by being notified by the KG, it actuates in the latter through HTTPS requests to Access Control Resources. The actuations are driven by the input through condition-action rules. In the Solid Agent, these are implemented through Koreografeye [12], which separates the planning from the execution. In Koreografeye, reasoning over Notation311 (N3) rules is performed to generate a plan consisting of multiple tasks. In a second phase, these tasks are then executed through Koreografeye plugins 12 that execute Typescript 13 code. Since Koreografeye is domain-agnostic, it neither understands ODRL nor Solid, dedicated N3 rules and plugins are written to materialize a temporal ODRL policy to concrete Access Control Resource at the pod level. For brevity and due to the fact everything is open-source 14 , we chose to use a shorthand notation to make clear how the materialization process works and why rather than explain this via code, RDF and Notation3 rules.
• Deontic concept D: It is only possible for this to be instantiated as Permission or Prohibition since there is no concept of Duty or Dispensation in ACP. In ODRL this is represented by the class of a rule. • Subject S: The WebID of the party that is subject to the rule.
• Action A: The allowed action of a rule that a subject can execute on a resource. • Resource R: The target resource to which the subject of a rule is allowed to perform a given action. • Duration-restricted constraint p: The duration of how long the rule is active. This period is represented using an RDF literal of type xsd:duration. • Time t: A representation of time of type xsd:dateTime.
• A Koreografeye action Action: A Koreografeye Plugin 12 that performs a dedicated execution task.
Using the shorthand, a general duration-restricted ODRL Rule is D(S, A, R, p) and Permission(ex:Bob, odrl:read, ex:ResourceX, "PT30S"^^xsd:duration) is the instantiated example at Listing 1. The two actions the agent can perform are ChangeAuthorization(D(S, A, R)) and CronJob(t, Action). The former changes the authorization resource of R using the deontic concept, subject and action. The latter executes another action at time t. On a policy update at time 𝑡 1 , the agent thus performs the condition-action rule:
CronJob(𝑡 1 + p, ChangeAuthorization(Prohibition(S, A, R)))
Instantiated with Listing 1 at time "2024-06-05T12:00:00"^^xsd:dateTime, two actions need to be executed: (i) ChangeAuthorization(Permission(ex:Bob, acl:read, ex:resourceX)), and (ii) CronJob("2024-06-05T12:00:30"^^xsd:dateTime, ChangeAuthorization(Prohibition (ex:Bob, acl:read, ex:resourceX))) 15 Listing 2: The materialization as an Access Control Resource as defined by ACP of the duration ODRL Policy stating Bob has read access to resource X.
The demonstration shows an agent-based method of enforcing temporal usage control policies on Solid pods using ODRL without altering the Solid Protocol. This is achieved through materializing the ODRL to Solid authorization resources and demonstrated with ACP as it would also allow restricting the client and issuer of the assignee. For this, OAC has to be used as policy language as core ODRL does not define solid client and issuer restrictions. However, the Solid Agent solution for enforcing UCP policies comes with some limitations. A first limitation is the necessity that the agent has complete control over all the resources owned by the resource owner in order to alter the authorization resources. Resource owners must trust that the agent will not misuse its control authority. However, there are no guarantees that the agent would never modify authorization resources without the consent of the owner and refrain from accessing the contents of the resources themselves. Certification of agents could potentially resolve this issue. The UCP KG introduces a challenge where the agent executes all newly added policies directly, even those that conflict with existing policies, causing inconsistencies in authorization resources. To resolve this, approaches such as those suggested in GUCON [13] are crucial to prohibit conflicting policies from entering the UCP KG.
Finally, full core ODRL will never be possible to be supported using our presented enforcement mechanism. There are several ODRL constraint left operands such as cardinality (odrl:count) or purpose (odrl:purpose) that cannot be expressed in Solid. As a result, next to materialization, additional approaches need to be explored to support full ODRL enforcement over Solid resources.
In this paper, we demonstrate how temporal usage control policies can be enforced in the Solid ecosystem by employing ODRL and a Web agent. Adhering strictly to the Solid protocol reveals that only a limited amount of usage control policies can be enforced. Enforcing a larger set of policies will require changes to the way authorization is granted within Solid. To enforce ODRL in Solid, we decided how to interpret ODRL to materialize this in access control resources due to a lack of ODRL formalization. However, such formalization is essential for verifying Web agents and as a consequence ensuring trust. Future work may include negotiation over usage control policies with Web agents such that other actors can initiate asking permission.
Supported by SolidLab Vlaanderen (Flemish Government, EWI and RRF project VV023/10) and SYTADEL (SYnchromodal proTotype for Data Sharing and PLanning), c-SBO project( VIL, imec, UAntwerpen and Vlerick), funded by VLAIO. The authors would like to thank Ruben Dedecker, Patrick Hochstenbach and Jos De Roo for giving their insights and feedback regarding this work.