We focus on the problem how delegations in dataspaces building on Solid are realized. For this, we propose to use the Rights Delegation Proxy that shall ensure on the one hand privacy by keeping delegation details hidden, and on the other hand validate delegated actions against defined policies for legitimacy. We showcase our architecture in a scenario for giving a signature for a loan contract, where a natural person is delegated signature rights on behalf of an enterprise.
the requirements delegators have for a delegation, a delegation should be (
Approaches exist to bring delegations to the Web, with a public online registry, e.g. the German Commercial Registry1, where companies as delegators publish information on their delegates, and afiliate look up the information at any time. Closer to dataspaces, an approach for the International Data Space (IDS) [6] proposed the use of Verifiable Credentials [ 7], where the delegator issues Verifiable Credentials for a delegate’s claim to act on behalf of the delegate, with the evaluation of the claim done by the afiliate via cryptographic proof. In both cases the delegate’s identity is made known to the afiliate to ensure a legitimate delegation.
To describe data access and sharing in Solid, the most basic way uses access rights for resources based on Access Control Lists2 (ACL) to ensure that specifically stated agents may use the granted rights. Groups of agents can be described by using vCard groups3, but the hierarchy stays flat to avoid nesting, while group members need to be shared to check for their membership. A currently developed approaches for Solid is the Solid Application Interoperability4 that uses an Authorization Agent to manage requests of agents based on ShapeTrees. If an agent’s intention has to be captured, Open Digital Rights Language5 or Policy Language for Solid’s Metadatabased Access Control (PLASMA) [8] can be used. Overall, considering privacy issues with General Data Protection Regulation [9], a delegate’s identity and the delegation are revealed to an afiliate to set the corresponding ACLs, despite the delegate’s potential interest to stay hidden.
As we see the SDS approach as promising to realize dataspaces, as Solid builds on Web standards, is easily adopted, interoperable, and inherently decentralized, we propose to extend Solid’s architecture on the dataspace application layer, where currently aspects of certification and policy enforcement are lacking [5]: we propose the Rights Delegation Proxy (RDP) as an approach for private and legitimate data sharing and delegations, where the overall architecture shall be compatible with the architecture of the Web and allow automated validation and execution of actions in a delegation. Our implementation of the RDP is available online 6.
Consider the following example with the banking institution BigBank and the enterprise SME, both as legal entities, and Alice, a natural person. The three actors are represented as authenticated Solid agents and the delegation from SME to Alice is realized using the Rights Delegation Proxy. The overall flow of messages is shown in Fig. 1.
1https://www.handelsregister.de/ 2https://solidproject.org/TR/wac 3https://www.w3.org/2006/vcard/ns#Group 4https://solid.github.io/data-interoperability-panel/specification/ 5ODRL: https://www.w3.org/TR/odrl-model/ 6https://github.com/wintechis/delegation-proxy alice.solidcommunity.net (delegate) rdp.org (RDP) PUT /signHere?uri=bankpod.net 2
Authorize proxy
3 GET /policies 200 OK s(mdeelepgoadt.onre)t ba(nakffpilioadte.n)et
Existing business relation 1 pDoelfiicnye Example: SME has to sign a loan ofer from BigBank. To receive the signature, BigBank prepared a resource https://bankpod.net/signHere. As BigBank expects SME to sign the contract, BigBank created an ACL signHere.acl with acl:Read and acl:Write rights exclusively for SME’s WebID https://smepod.net/profile/card#me.
SME defines a policy at https://smepod.net/policies that Alice, authenticated by her
WebID https://alice.solidcommunity.net/profile/card#me, has the right to sign
loan ofers from BigBank (
Alice sends an HTTP PUT request to the RDP pointing to
https://bankpod.net/signHere to give the signature (
We present an overview of the interactions between the Solid agents and the Rights Delegation Proxy during the delegation process. Fig. 2 and 3 show illustrative data used during the delegation with respect to the example scenario in Sec. 2: 1. The delegator defines a policy that states the delegate’s rights of transactions towards https://bankpod.net/signHere.acl <> a acl:Authorization ; acl:accessTo <./signHere> ; acl:agent sme:me ; acl:mode acl:Write . https://bankpod.net/signHere <> rdf:type ex:LoanContract ; ex:forCustomer sme:me .
GET https://smepod.net/policies 3
GET /signHere (authenticated as sme:me) 4 200 OK
Evaluate policies
5 rdp.org <LoanContractShape> CLOSED{ ex:forCustomer [sme:me]; rdf:type [ex:LoanContract] } <LoanContractSignedShape> CLOSED{ ex:forCustomer [sme:me]; rdf:type [ex:LoanContract]; ex:signed [true] } 2 PUT /sige<nx>H:freodrrfeC:t?yuupsretio=emhxtet:pLrsos:am//nbeCa:monnkept;roadc.tn;et https://alpicroef.isleo/lcidacrodm#mmeunity.net/ ex:signed true .
the afiliate. We discern pre-conditions and post-conditions that are evaluated, where pre-conditions define how a resource has to look like before the delegate may access it, and post-conditions define how a resource has to look like after the delegate accessed it. 2. The delegate makes an HTTP request to the RDP, where the accessed path is equal to the resource at the afiliate and the query contains the host of the afiliate’s URI. 3. The RDP receives the request, checks that the delegate’s WebID is authenticated, and extracts the afiliate’s URI as well as the path to the web resource. The RDP looks up suiting policies at the delegator depending on the WebID or web resource. 4. The RDP does a "preflight GET request" to the requested resource. 5. The RDP evaluates if the delegate’s request is valid concerning the policies. Therefore the preflight response is checked against the pre-condition. To check a post-condition, the RDP evaluates if the message body, which contains the to-be-expected resource state, adheres to the post-condition. If a condition does not hold, the RDP responds with 403 Forbidden. 6. After checking the request, the RDP logs the result as well as time, content, accessed resource, and requesting WebID at a location defined by the delegator. 7. The RDP authenticates as delegator to forward the checked request to the resource as specified by the delegate in the query string. 8. The afiliate responds to the RDP, and the RDP logs the response. 9. The RDP sends the afiliate’s response to the delegate and concludes the flow of messages for the initiated request.
Finally, we analyse the requirements for the roles of afiliate, delegator, and delegate to take part in the RDP system. Note that we do not make assupmtions in our system on how a delegate is informed about the delegation coming from a delegator, or how the range of rights shall be defined between afiliate and delegator. https://bankpod.net/signHere.acl <> a acl:Authorization ; acl:accessTo <./signHere> ; acl:agent sme:me ; acl:mode acl:Write . https://bankpod.net/signHere <> rdf:type ex:LoanContract ; ex:forCustomer sme:me; ex:signed true .
6 7 PUT /signHere (authenticated as sme:me) <> rdf:type ex:LoanContract ; ex:forCustomer sme:me;
ex:signed true . 8 204 No Content ./logs <> a ex:Policy ; ex:forAgent alice:me ; ex:forRessource bank:signHere; ex:preCondition <LoanContractShape> ; ex:postCondition <LoanContractSignedShape> .
<LoanContractShape> <LoanContractSignedShape> PUT https://smepod.net/logs/2024-01-01 <> rdf:type ex:Log ; ex:forAgent alice:me ; ex:forRessource bank:signHere .
Evaluate policies rdp.org
Afiliate As the afiliate is aware of the existing business relation, the afiliate knows the delegator’s identity and thus the WebID. With the WebID, the afiliacte can define an appropriate ACL including permissions for the Web resource on on Solid Storage that shall be accesses by the delegator.
Delegator As the delegator is aware of the business relation with the afiliate, too, the delegator knows the location where the afiliate stores the shared Web resource and ideally the rights that are granted by the afiliate. To define a delegation, the delegator has to know the delegate’s Web ID and define policies that associate the delegate with the afiliate, e.g. via explicitly stating the Web resource as permitted for the delegate. The rights granted by the policy may include all or a subset of the delegator’s rights with respect to the afiliate - of course rights that go further than the one’s granted by the afiliate will not have an efect, if the afiliate did not grant them. To realize the actions, the delegator has to use and authorize an RDP, e.g. hosted as its own service or by a provider, and configure the RDP with the locations on where to find policies and store logs, e.g. the delegator’s own Soldi storage.
Delegate As recipient of the delegator’s policy, the delegate ideally (but not necessarily) knows which rights are granted by the delegator. Again, if the delegate would try to use rights that go further than the one’s defined in the policy, the RDP would refuse to perform the action. To realize the delegation and act on behalf of the delegator, the delegate has to know how and where to act, that is the delegate needs to know the afiliate’s Web resource, e.g. via the URI, and the URI of the RDP to realize the action authorized as delegator, so that the action can be executed at the afiliate.
We propose the RDP as a medium between the agents delegator, delegate, and afiliate. As all delegated actions go through the RDP, which authenticates as the delegator, the RDP is a component with high responsibility. As a consequence, we shift the power over actions to the delegator by having exclusive control over policies, while shifting responsibility away from the afiliate, who has to know only the delegator. The delegate powers are limited to exist only in the defined policies, so the RDP solves the privacy problem straightforwardly: with authentication as delegator (like a Solid App), there is no diference of the action’s origins towards an afiliate, while the delegate’s identity is obfuscated.
As of now, the RDP is a centralized component that manages all incoming delegated requests, which poses a bottleneck and single point of failure [10]. Handling a single request, however, is independent of other occurring requests such that multiple instances of an RDP may be run in parallel. Here, a load balancer may distribute incoming requests to several RDP instances.
Policy implementation is subject to the applied use case, but we see huge potential for complex, custom policies for large organizations to be possible: to evaluate the pre- and post-conditions e.g. ShEx can define the expected structural data of resource, or SPARQL 8 ASK queries can be used instead. If the conditions in the query are met (as with shapes), the delegate request is forwarded. Extension to use more complex workflows are also possible, e.g. to use Business Process Model and Notation (BPMN) to be close to processes in organizations, e.g. contracts may only be signed after an accountant agreed, or ontologies like WiLD [11] to represent and monitor workflows similarly.
This work is partially funded by the German Federal Ministry of Education and Research via the MANDAT project (FKZ 16DTM107A).