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 protocol1 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
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 suficient. The first aspect
to overcome the limitations of current specifications is to use another standard which supports
ifne-grained conditions to declare and enforce policies such as the Open Digital Rights Language
(ODRL)4 W3C standard [
In this paper, we extend an open-source, rule-based Web agent [
Sambra et al. [
However, complying with the General Data Protection Regulation (GDPR) [
par 6.1 GET resource
6.2 return 8.1 GET resource 8.2 not Authorized 5.2 PUT ACR 7. PUT ACR
Solid Agent
UCP KG 3.1 Notify UCP 3.2 GET UCP 3.3 return 4. Reason over UCP + Rules 5.1 Identify executionable tasks 5.3 Cron Job
Resource Owner
2. POST UCP
(ODRL) [
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 flow 10 described at the beginning of this section and illustrated in 1.
ex:policy a odrl:Ofer;
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. 3.1. Materialization of the ODRL policy by the Solid Agent 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 plugins12 that execute Typescript13 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-source14, we chose to use a shorthand notation to make clear 10https://github.com/SolidLabResearch/Solid-Agent/tree/feat/sosy/documentation/sosy 11https://w3c.github.io/N3/spec/ 12https://github.com/eyereasoner/Koreografeye-Plugin 13https://www.typescriptlang.org/ 14https://github.com/SolidLabResearch/Solid-Agent/tree/feat/sosy/ 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 Plugin12 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: IF
1 THEN
Permission(S, A, R, p) ChangeAuthorization(Permission(S, A, R))
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. This results in ChangeAuthorization immediately adding Listing 2 to the Access Control Resource accompanying resource X and after 30 seconds removing Listing 2 again.
<#acr> a acp:AccessControlResource ; acp:resource ex:resourceX ; acp:accessControl <#bobReadAccess> . <#bobReadAccess> a acp:AccessControl ; 15The condition-action rule also maps ODRL Actions to ACP Granted Access Modes.
acp:apply [ a acp:Policy ; acp:allow acl:Read ; acp:anyOf [ a acp:Matcher ; acp:agent ex:Bob
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 ifrst 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. J. Theissen-Lipp, P. Colpaert, S. K. Sowe, E. Curry, S. Decker (Eds.), Proceedings of the Second International Workshop on Semantics in Dataspaces (SDS 2024), volume 3705 of CEUR Workshop Proceedings, CEUR, Hersonissos, Greece, 2024. URL: https://ceur-ws.org/ Vol-3705/#paper10, iSSN: 1613-0073. [11] J. Grau, S. Mayer, J. Strecker, K. Garcia, K. Bektas, Gaze-based Opportunistic Privacypreserving Human-Agent Collaboration, in: Extended Abstracts of the 2024 CHI Conference on Human Factors in Computing Systems, CHI EA ’24, Association for Computing Machinery, New York, NY, USA, 2024, pp. 1–6. URL: https://doi.org/10.1145/3613905.3651066. doi:10.1145/3613905.3651066. [12] P. Hochstenbach, R. Verborgh, H. V. d. Sompel, Using Event Notifications, Solid and Orchestration for Decentralizing and Decoupling Scholarly Communication, The Code4Lib Journal (2023). URL: https://journal.code4lib.org/articles/17823. [13] I. Akaichi, G. Flouris, I. Fundulaki, S. Kirrane, GUCON: A Generic Graph Pattern Based Policy Framework for Usage Control Enforcement, in: A. Fensel, A. Ozaki, D. Roman, A. Soylu (Eds.), Rules and Reasoning, volume 14244, Springer Nature Switzerland, Cham, 2023, pp. 34–53. URL: https://link.springer.com/10.1007/978-3-031-45072-3_3. doi:10.1007/978-3-031-45072-3_3, series Title: Lecture Notes in Computer Science.