We propose the Rights Delegation Proxy to check and execute delegations in dataspaces building on the Social Linked Data project (Solid). The Rights Delegation Proxy ensures privacy by keeping delegation details hidden and validates delegated actions against policies for legitimacy. We show our implemented architecture in a loan contract scenario, where a person signs a contract on behalf of a company with a bank. Additionally, we analyze the flow of our architecture for privacy and legitimacy using formal models.
• Delegator: an agent that defines a policy for a delegate to act in the delegator’s name An example of a delegation is a company SME (delegator) that grants its employee Alice (delegate) the right to sign contracts on its behalf (policy) with BigBank (afiliate). Considering the requirements delegators have for a delegation, we obtain three basic points: R1 Privacy: An afiliate shall not necessarily be informed, whether a delegation has happened and who is the delegate.
R2 Legitimacy: Every taken action by the delegate shall be validated against the policies as defined by the delegator and only approved actions may happen.
R3 Completeness: Every initiated action by a potential delegate shall receive a response.
A conventional delegation process in SDS may use access and manipulation rights for resources based on Web Access Control (WAC)1, e.g. read, write, append rights based on Access Control Lists (ACL). While ACLs ensure that at least authenticated or specified agents may use the granted rights, only small extensions for more complex agent structures are possible by using vCard groups2 in Solid. With groups, the hierarchy has to stay flat as no nesting of groups and rights is possible, while the members of a group need to be shared with external afiliates who need to check if acting agents are part of a group defined in the ACL.
The conventional delegation process is even less attractive when considering privacy issues
(cf. General Data Protection Regulation [
Dataspace proposals like the International Data Space (IDS) [
As we see the SDS approach as the most promising to realize dataspaces, because of the SDS
foundation on Web standards, easy adoption, interoperability, and inherently decentralized
architecture, we propose to extend Solid’s architecture on the dataspace application layer, where
currently aspects of certification and policy enforcement are lacking [
Alice (delegate)
SME (delegator)
BigBank (affiliate) 2
Sign document 1
Furthermore, the overall architecture shall be compatible with the inherently decentralized style of the Web and allow automated validation and execution of actions in a delegation. Our contributions are: • We present the architecture of the Rights Delegation Proxy and its implementation to extend Solid dataspaces that enable privacy and legitimacy for delegations among agents • We give formal proof to show that our architecture fulfills the requirements of privacy and legitimacy for delegations among agents and compare our architecture formally to a conventional delegation process based on the example of a loan signature delegation
We explain our running example, where two legal entities, the banking institution BigBank and the enterprise SME, and the natural person Alice interact. We show a simplified, conventional delegation process for a loan contract that contains a delegation (see also Fig. 1): Example 1 Because of a previous business relation, SME received a loan ofer from BigBank. Today, the ofer has to be signed such that SME gets the loan. SME defines a policy that its employee Alice has the right to sign loan ofers from BigBank and informs BigBank about the policy (1). Alice concludes that the ofer is beneficial for SME and gives her signature as "on behalf of SME, Alice" (2). The contract is sent back to BigBank (3) and some days later, SME receives the details to access their money.
SME and BigBank are legal entities that cannot act on their own - a natural person has to act "on behalf of" them via a delegation. Here, the natural person Alice acts on behalf of SME where Alice is accepting the ofer by giving her signature (that is acting) for SME. Similarly, but not shown here, BigBank has to delegate its actions, e.g. ofering the loan contract. Consider the implications that the example loan process hides in terms of delegation: • SME (the delegator) defines a right to sign loan ofers (a policy) for Alice (the delegate) via her role in the organization and thus creates a delegation. • The delegation to Alice is an SME internal step that is shared externally, here with BigBank (an afiliate). The loss of privacy is necessary to declare that Alice may sign on behalf of SME, otherwise BigBank would receive a signature from an unknown natural person called Alice who only claims to act on behalf of SME. • Alice could have signed even if she did not receive a delegation. Although the misconduct could be detected later on, loss of reputation and money can be the consequence.
Solid is a collection of technological specifications for read/write Linked Data supported by
authentication and authorization [
WebID6, including a profile to uniquely describe the denoted agent.
The idea of dataspaces shall help to manage multiple data sources with multiple schemas [
Concerning the power of attorney, an agent (called delegate or attorney-in-fact) may be granted
the authority to act on behalf of someone else (called delegator or principal) [
We assume that all involved roles are represented as authenticated Solid agents (see Sec. 3.1). We do not make assumptions on how delegator and delegate share their delegation, or how afiliate and delegator agree on granted rights for the prepared location and regard this communication as domain dependent and thus out of scope.
Afiliate The afiliate stores web resources on a Solid storage that the delegator may access or manipulate. Thus, the afiliate needs to know the delegator’s WebID to define ACLs for the Web resource with respective rights for the delegator.
Delegator The delegator defines policies that connect the delegate’s WebID and the afiliate’s web resource, so the delegator knows the delegate’s WebID as well as which applicable rights shall be granted to the delegate. The granted rights may include all or a subset of the delegator’s rights towards the afiliate. Additionally, the delegator uses and authorizes an RDP, e.g. as an own service or hosted by a provider, and shares where policies and logs are stored. Delegate The delegate ideally (but not necessarily) knows the delegator’s granted rights, the URI of the afiliate’s web resource that shall be accessed or manipulated, and the RDP’s URI such that the delegation may be enacted.
Compared to the conventional delegation process of Sec. 2, our architecture uses the Solid dataspace where an Rights Delegation Proxy acts as a mediator between the legal entities and natural persons. Again, Alice shall sign a loan contract with BigBank for SME (see also Fig. 2): Example 2 SME has to sign a loan ofer from BigBank to get the loan. To receive the signature, BigBank prepared a resource https://bankpod.net/signHere that shall hold the digital signature. 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, is authenticated by her WebID https://alice.solidcommunity.net, has the right to sign loan offers from BigBank (1). Alice sends an HTTP PUT request to the RDP pointing to https://bankpod.net/signHere to give the signature (2). The RDP receives Alice’s authenticated request and her WebID. RDP gets (3) and checks (4) the SME’s defined policies if Alice’s WebID has a granted delegation for https://bankpod.net/signHere, and logs the received request (5). alice.solidcommunity.net (delegate) rdp.org (RDP) Existing business relation PUT /signHere?uri=bankpod.net
2 204 No Content 8
Authorize proxy
3 GET /policies
200 OK evaluate 4 policy 5 PUT /logs/2024-01-01 201 Created smepod.net (delegator) 1
Define policy 4
GET /signHere
200 OK 6 PUT /signHere 204 No Content 7
As Alice fulfills the policy, RDP forwards Alice’s request to the specified https://bankpod.net/signHere (6), but changes the authentication to SME. At BigBank, an authenticated request arrives from SME’s WebID. As the ACL is set for SME’s WebID the signature is created to accept the loan (7), and the response forwarded to Alice (8).
From BigBank’s perspective, only SME was involved as the request came from SME’s WebID. But while the legal body of SME could still not act on its own, Alice initiated the action which resulted in an accepted ofer. Again, we consider the implications: • SME delegates to sign the contract with BigBank to Alice via a defined policy. The delegation is not shared with BigBank. • BigBank knows and anticipates only SME, so the ACL lets only SME interact with the protected resource, but not Alice. • The signature comes from SME directly after being checked against the policies. SME has thus been informed and approved of the interaction. • Alice may only sign after SME defines and approves the delegation via a policy. Without a valid policy, the RDP does not forward Alice’s request. A request from Alice directly to BigBank would be blocked as unauthorized from the ACL.
Below, we present an overview of the interactions between the Solid agents and the RDP during the delegation process. We use Fig. 2 to illustrate how the delegation works for our running example from Sec. 4.2. 1. The delegator defines a policy that states the delegate’s rights of transactions towards the afiliate. We discern two types of policies that are evaluated: pre-conditions and post-conditions. • Pre-conditions define how a to-be-accessed resource has to look like before the delegate may access it.
• Post-conditions define how a resource has to look like after the delegate accessed it. LoanContractShape LoanContractSignedShape ea<xL[:oefoaxr:nLCCouoasnntCtormoancettrSr[ahscamtp]ee}:>mCe]L;OSED{ eea<xxL[::oefsoaixgr:nLnCCoeuoadsnnt[Ctotrmroaunceettr]Sr[ai}gscmnt]ee;d: mShea];pe> CLOSED{
The afiliate created a resource at https://bankpod.net/signHere together with an ACL with read and write rights for SME: https://bankpod.net/signHere https://bankpod.net/signHere.acl
@prefix acl: <https://www.w3.org/ns/auth/acl#> . <> a ex:LoanContract ; <> a acl:Authorization ; ex:forCustomer acl:accessTo <./signHere> ; <https://smepod.net/profile/card#me> . acl:agent <https://smepod.net/profile/card#me> ; acl:mode acl:Read, acl:Write . 2. The delegate makes an authenticated HTTP request to the Rights Delegation Proxy, where the accessed path is equal to the web resource at the afiliate and the query contains the host of the afiliate’s URI.
Fig. 2, step 2: Alice is authenticated as https://alice.solidcommunity.net/profile/card#me and sends a PUT request to the RDP at https://rdp.org/signHere?uri=https://bankpod.net as Alice wants to access https://bankpod.net/signHere as a delegate. To sign the contract, the message body contains: 3. The RDP receives the request, verifies the delegate’s identity using the Solid-OIDC WebID claim, 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.
Fig. 2, step 3: The RDP receives the HTTP PUT request from https://alice.solidcommunity.net/profile/card#me, verifies the identity, and retrieves defined policies from https://smepod.net/policies for Alice’s WebID. 4. The RDP evaluates if the delegate’s request is valid concerning the policy’s conditions. • To check a pre-condition, the RDP does a "preflight GET request" to the requested resource and evaluates if the response matches the pre-condition. If not, the RDP responds to the delegate with a 403 Forbidden. • 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 the post-condition does not hold, the RDP responds with 403 Forbidden.
Fig. 2, step 4: In the retrieved policy, RDP finds two ShEx shapes as pre- and post-condition. For the pre-condition, RDP does a "preflight" GET request to https://bankpod.net/signHere, validates the retrieved state with LoanContractShape, and finds it valid. For the post-condition, RDP extracts the content of the PUT request, validates it with LoanContractSignedShape, and ifnds it valid, too. 5. After checking the request, the RDP logs the applied policy, its result as well as time, content, accessed resource, and requesting WebID at a location defined by the delegator.
Fig. 2, step 5: The RDP logs Alice’s request to https://bankpod.net/signHere at https://smepod.net/logs/2024-01-01 with: <> a ex:Log ; ex:checkedPolicy (<LoanContractShape> <LoanContractSignedShape>); ex:forAgent <https://alice.solidcommunity.net/profile/card#me> ; ex:forRessource <https://bankpod.net/signHere> . 6. The RDP authenticates as delegator to forward the checked request to the resource as specified by the delegate in the query string.
Fig. 2, step 6: The RDP authenticates as https://smepod.net/profile/card#me via Solid OIDC and forwards Alice’s HTTP PUT request to https://bankpod.net/signHere such that the state is now: 7. The afiliate responds to the RDP as the sender of the forwarded request. The RDP logs the response.
Fig. 2, step 7 : The afiliate https://bankpod.net responds to the RDP https://rdp.org with 204 No Content as the HTTP PUT was enacted as requested. 8. The RDP sends the afiliate’s response to the delegate and concludes the flow of messages for the initiated request.
Fig. 2, step 8: The RDP https://rdp.org sends the afiliate’s response 204 No Content back to Alice.
As a remark, if the afiliate responds with error codes, e.g. 500 Internal Server Error, the RDP forwards the messages to the client and logs the error.
Our implementation for the RDP is available online 8. We use node.js9 and express.js10 as a web framework for the RDP server side and use the OIDC library Jose 11 to handle the Solid authentication. We use ShEx12 to express pre- and post-conditions of policies.
We used ProVerif [
8https://github.com/wintechis/delegation-proxy 9https://nodejs.org/en 10https://expressjs.com/ 11https://github.com/cisco/node-jose 12https://shex.io/ 13https://solidproject.org/TR/oidc 14https://github.com/wintechis/delegation-proxy
We assume the following processes that represent the roles and agents in a delegation: clients , the RDP , the delegator , and the afiliate .
We define a client as a process that wants to send an operation to the afiliate. In case a client received a delegation before, it is also considered a delegate: we instantiate two clients with a to-be-performed operation , the client (that is also a delegate) and the client (that is not a delegate), where is initialized with a name and is initialized with . regards as delegate and knows the client’s together with an allowed operation which defines the policy. knows the delegator’s , also with an allowed operation . only knows the delegator’s name.
We give the system with the RDP in the style of ProVerif15, where for two processes and we call | a parallel composition of and (processes run in parallel), and ! an infinite composition | | . . . , which denotes an unbounded number of processes: !( ( , )| ( , )|( )|( , )|( , ))
In Sec. 1 we identified three requirements for delegations from which we derive goals to prove in ProVerif:
R1 Privacy: afiliates shall not know whether a delegation has happened R2 Legitimacy: all delegate actions are validated against delegator’s policies R3 Completeness: clients shall receive a response to all of their requests
The following goals shall ensure that the delegation process is correct. Each goal G1-3 maps directly to the corresponding requirement R1-3:
G1 The afiliate will never get to know a client ’s name, regardless of whether ’s name was a delegate or not according to the delegator .
G2 For all messages a client or sends to the afiliate (possibly using the RDP ), the delegator ’s policies have been validated.
G3 For all messages a client or sends to the afiliate (possibly using the RDP ), the client will receive a response afterwards.
Thus, we define events that may occur during the exchange: • - event emitted by a client after sending a message • - event emitted by a client after receiving a response • - event emitted by the delegator after providing policies for validation • affReceivesMsg - event emitted by afiliate after accepting a message
We represent our goals as injective correspondences in ProVerif where →− is true for two events and if and only if when there is an occurrence of , then there is a distinct earlier occurrence of before that is and have a one-to-one-relationship. For a fact , e.g. a name, we check with attacker( ) if is accessible on a public channel. Here, we check for facts arriving at the afiliate (see Sec. 5.3). We want the following goals to hold as true. 15https://bblanche.gitlabpages.inria.fr/proverif/manual.pdf G1 ¬attacker( ) and ¬attacker( ) G2 affReceivesMsg→−
G3 →−
We give the processes of Sec. 5.1 in detail, as used in ProVerif. With Solid OIDC, we assume the channels between clien→t← RDP, RDP→← delegator, and RD→P← afiliate as private. Sending a name via a channel is equal to being authenticated via the name’s respective identity provider.
Note that we create a at the client at the beginning of the process, similar to a session ID. While there is no explicit nonce in the RDP, we use it in our model to check for the injective correspondence of events. It serves no further purpose. 5.3.1. Client The client sends its name and used operator via channel to the RDP and expects an answer at channel . let client(clientname:Name, op:bitstring) = new nonce:bitstring; let m0 = (clientname, op, nonce) in event clientSendName(nonce) ; out(cout, m0); in(cin, m4:bitstring) ; let (resp:bitstring,nonce2:bitstring) = m4 in if nonce = nonce2 then event clientReceiveResponse(nonce) .
The RDP receives a name and desired operator of the clients on channel . The RDP sends the client’s name to the delegator via channel to receive a policy as the answer on channel . If the policy matches the client name and operator, the delegator’s name and operator are sent to the afiliate on channel affin and the response received on channel affout. The client receives the response to its request on channel . let rdp(orgName:Name) = in(cout, m0:bitstring) ; let (xname:Name , xop:bitstring, nonce:bitstring) = m0 in let m1 = (xname, nonce) in out(orgin, m1) ; (* send Name to delegator *) in(orgout, m2:bitstring) ; let (polName:Name, polOp:bitstring, nonce2:bitstring) = m2 in if (xname, xop, nonce) = (polName, polOp, nonce2) then let m3 = (orgName, xop, nonce) in out(affin, m3 ); in(affout, m4:bitstring); (* proxy response*) let (resp:bitstring,nonce3:bitstring) = m4 in if nonce = nonce3 then event rdpWasSuccessful(nonce); out(cin, m4) . 5.3.3. Delegator The delegator receives requests from the RDP via channel . The RDP receives a response via channel , depending on the relayed name being equal to the initialized value of the delegator that is if it matches a policy. let delegator(okName:Name, okOp:bitstring) = in(orgin, m1:bitstring ) ; let (yname:Name, nonce:bitstring) = m1 in if yname = okName then event orgOK(nonce) ; let m2 = (okName, okOp, nonce) in out(orgout, m2) . 5.3.4. Afiliate The afiliate receives a name and operation from the RDP via the channel affin and checks if the name is equal to the known delegator name as well as the operation being allowed. The afiliate responds via channel affout and sends the received name to a public channel . We use the public channel functionality of ProVerif to check which name reaches the afiliate and which does not (see Sec. 5.2). Note that a client sending a request directly to will always result in a negative response, as only accepts requests carrying the delegator’s name. let affiliate(orgName:Name, op:bitstring) = in(affin, m3:bitstring) ; let (zname:Name, zop:bitstring, nonce:bitstring) = m3 in if (zname, zop) = (orgName, op) then event affReceivesMsg(nonce) ; let m4 = (OK,nonce) in out(affout,m4) ; out(pub,zname) . (* check if affiliate received client Name*)
ProVerif proved that for the presented architecture of Sec. 5.3 that indeed
G1 ¬attacker( ) = true and ¬attacker( ) = true G2 affReceivesMsg→− = true
G3 →− = true meaning that the afiliate will not get to know a client’s or delegate’s name, that a delegate’s message using the RDP will always reviewed by the delegator, and that any client will receive a response to a request. These proofs are independent of a client being a delegate.
For comparison, we analyzed a conventional delegation without an RDP, based on Fig. 1, with !( ( , )|( , )|( , )|( , )) where sends its policy with the delegate’s to (similar to setting ACLs to include the delegate), and clients send their name and operation directly to . We find that in the conventional delegation
G1 ¬attacker( ) = false and ¬attacker( ) = false G2 affReceivesMsg→− = true
G3 →− = true meaning that a client’s or delegate’s name does not stay hidden from the afiliate after receiving a message, that a delegate’s message is only accepted after the delegator informs the afiliate of the applied policy, and that any client will receive a response to a request.
We proposed the RDP to address the gap of more complex delegations in Solid dataspaces. Up to now, only basic possibilities exist to define delegated actions, but with the RDP, we extend the architecture by introducing an active component that checks the actions of delegates while keeping their privacy and still makes sure that every tracked, forwarded action on the delegator’s behalf is legitimate.
The RDP acts in its presented state as a necessary medium between the explicitly separated agents delegator, delegate, and afiliate. As all actions of the delegate have to go through the RDP and the RDP can authenticate (like a Solid App) as the delegator, the RDP is a component with high responsibility and no delegated action may happen without it. 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 and nobody else. The delegate powers are (rightfully) limited to exist only in the defined policies. The enhanced responsibility of RDP thus solves the privacy problem straightforwardly: with authentication as delegator (comparable to the usage of a Solid App through the delegator), there is no diferentiation of the action’s origins towards a third party, while the delegate’s identity is obfuscated. Solid OIDC establishes an authenticated and trusted connection between agents in our architecture.
Admittedly, the RDP as presented in our example appears a centralized component that
manages all incoming delegated requests, which presents a bottleneck and a potential single
point of failure [
For illustration, our example in Sec. 4.3.1 uses a simplistic, custom approach with ShEx
shapes for policies. The specific implementation is of course subject to the applied use case of
the RDP, but we see huge potential for other approaches that make complex, custom policies
for large organizations possible: the Open Rights Digital Language16 may be used to define
post-condition via obligations and pre-conditions via constraints. SPARQL17 ASK queries can
be used instead of shapes to evaluate the pre- and post-conditions. If the specified conditions
in the query are met (as with shapes), the delegate request is forwarded. As organizations
often use Business Process Model and Notation (BPMN) to describe more complex workflows
(e.g. a contract may only be signed after an accountant agrees), ontologies like WiLD [
All in all, we argue that our presented approach to extend the Solid dataspace with an Rights Delegation Proxy component leads to a more flexible, privacy-respecting, secure delegation mechanism that builds directly on existing Web standards.
We present a solution for the gap of possible delegation between agents in the Solid dataspace which we call the Rights Delegation Proxy (RDP). With the Rights Delegation Proxy, a delegating party can define and check policies over actions while a delegate can exercise rights with their privacy respected. An afiliate that receives these actions can still ensure that the actions are taken by the delegating party, as opposed to conventional delegation processes. We base our approach on Solid, Linked Data, and Web technologies to describe and implement an RDP that checks, logs, and forwards HTTP requests of delegates to an afiliate for defined policies by the delegator. We show the system in the context of our running example, a loan contract scenario where a natural person signs a contract on behalf of a company.
In the future, we want to extend the RDP towards more sophisticated policies to define delegations, which includes the possible use of SPARQL ASK queries and reasoning to distinguish internal and external relationships in organizations.
This work is partially funded by the German Federal Ministry of Education and Research via the MANDAT project (FKZ 16DTM107A). The authors thank Christoph H.-J. Braun for his advice regarding ProVerif and the models.
16https://www.w3.org/TR/odrl-model/ 17https://www.w3.org/TR/sparql11-overview/ 18https://www.w3.org/TR/vocab-org/