The concept is inspired by existing software solutions in the field of e-governance, such as X-Road from Estonia and XDatenschutzcockpit, which is currently being developed in Germany for access control of citizen data. Both systems have an embedded logging system that monitors access data. Since they are tied to the specific context in which they are used, the idea of a Data Privacy Cockpit (DPC) will be ported to the Solid ecosystem.

When applying the concept to the Solid context, two fundamental software components can be identified to solve the problems under the given premises:

The concept idea’s data capturing unit, the DPC Middleware, will be implemented as a proxy to meet the requirements of vendor-agnostic software that is secure from updates, as criticized in ISSUE-3, ISSUE-4, and ISSUE-5. However, this requires the application to be a Solid application, as it communicates over HTTP APIs with the actual Solid Provider. Since every request passes through the reverse proxy, there is a high risk of resulting in an inefficient software solution.

Upon reflection on the prototype, two central issues of the concept emerge instantly. The first is the manner in which the data is captured by the DPC Middleware. The second is the means by which the DPC Client is aware of the owner or potential accessor of the data captured.

The tension between vendor-agnostic software and efficiency is a key consideration for the solution’s requirements, particularly in non-functional requirements. However, the functional requirements are straightforward.

In the context of a data-driven web-based system, the interaction of the system is further concretized. The system must interact via data APIs over the network. This is sometimes referred to as Resource-Oriented Architecture (ROA), as defined by Richardson & Ruby (2007). ROAs are designed to facilitate the manipulation of resources through four operations: creation, reading, updating, and deletion (CRUD). In this architecture, the CRUD operations are mapped to the following HTTP request methods:

The HTTP/1.1 specifies additional request methods that may be relevant for the individual system, such as CONNECT, HEAD, OPTIONS, and TRACE ^[10].

When applying the CRUD network interfaces to a single resource lifecycle, every achievable state (created, read, updated, and deleted) is reached by an ingoing CRUD transition. The starting state, however, must be the created state in order to have an initial resource to work with. Until its deletion, the same resource cannot be created again. New resources, however, can be created at any time. All other states (read, updated, and deleted) are accessible from the created state as well as the updated and read state, including self-transitions. When the deleted state is the current state of the resource, the only possible transition is the recreation of the resource. This behavior is displayed in Figure 1.

It is recommended that a sequence of CRUD requests, utilising states and transitions as previously described, be executed in a sequential order. Certain sequences may allow parallel execution, however, it can lead to errors due to the occurrence of illegal transitions. An illustrative example of transitions that are executable in parallel is a sequence of only read transitions on an existing resource. These transitions should be executable in parallel without any issues, as a situation where a resource is attempted to be read before its creation cannot occur.

Another scenario to be considered is the utilisation of resources with a deeper hierarchical depth, which are typically designated with a backslash in the URL. In such instances, the resource container can be treated as ordinary resources, with a CRUD network interface and the corresponding lifecycle. However, it is not possible for a resource to exist independently of a parent container resource in the created, updated, or read state.

It is important to note that each state of the state machine can be a final state. The transitions in this context are translated with different frequencies. For instance, read transitions appear more often than others. This segmentation is represented as a probability in this work.

The internet operates on the Client-Server model, where a client requests a resource from the server, which responds accordingly. Introducing a proxy to this model involves adding another server. This proxy server accepts requests and delegates them to the actual server. The response is then forwarded to the requesting party. However, this offers the opportunity for a proxy to isolate either the client or the server from the network. When referring to a server-side proxy, isolation of the server is described, as shown in Figure 2 (Luotonen & Altis, 1994).

In addition to its position within the network, the Proxy can also have a position in the OSI model. The model describes how data will be transported in seven layers, each with different functions. Every layer can only communicate with its closest layer, starting with the physical layer that transmits a raw bitstream over a physical medium, up to the seventh layer, the application layer. This is the human interaction layer, through which applications can access network services. An Application Layer Proxy operates within this layer.

For the sake of simplicity, the term "proxy" will be used in the following text. Despite the abbreviated term, all properties of a server-side application layer proxy will be fulfilled.

The Solid Protocol employs a specific model of the relationships between resources on the Web and the types of these relationships. These are exposed as HTTP headers, linking to the related resource, as defined by Nottingham (2017).

HTTP Link headers are conventional HTTP headers, with the header field Link and a value separated by a colon. Within the header value, the uri-reference points to the related resource, while the attribute value pair defines the relation. This is demonstrated in Listing 1.

In the event that multiple header values are to be applied, the values may be separated by a comma.

The Solid Protocol employs a variety of resource definitions, which are constructed upon one another in a hierarchical manner. These definitions either extend or restrict the previous definition, thereby forming a structured system.

The resources listed below are the most common resources in Solid and in the web in general:

Storages are spaces of URIs that affords agents controlled access to resources. The storage resource, however, is the root container for all of its contained resources and is owned by an agent (Sarven et al., 2022).

Storage resources are defined by a specific HTTP Link header that is used to mark a given container resource as a storage resource. This is achieved by including the rel attribute with the value type, along with a URI reference that matches pim:Storage. The owner of this storage can be made available optionally by including the rel attribute with the value solid:owner. This is demonstrated in Listing 2, where additional headers and the response have been omitted in the listening (ibid.).

As the storage resource is a top-level resource in the container resource hierarchy, all containing resources belong to a storage resource. The containing storage resource is not directly accessible via an HTTP header or any other means. However, the hierarchy can be traversed until the highest level is reached in order to identify the containing storage resource (ibid.).

Description resources represent a distinct category of auxiliary resources. These resources provide a description of a subject resource, which is referenced by a HTTP Link header. The rel attribute is used with the value describedby to indicate this relationship. This is also illustrated in Listing 2 (ibid.).

The representation of resources is primarily in the form of RDF documents. Bergwinkl et al. (2019) introduced the Dataset specification, which represents the contents of these documents as ECMAScript objects. The Inrupt JavaScript Client Libraries^[12] refined this further and introduced the terms SolidDataset and Thing. In order to facilitate the interpretation of the RDF documents, the following definitions will be used, based on the definitions mentioned:

In a decentralized platform, it is essential to have identifiable. Solid accomplishes this with WebIDs and the WebID Profile, which is associated with it (Sambra et al., 2014).

The authentication process in Solid is based on OAuth 2.0^[13] and OpenID Connect Core 1.0^[14], with certain enhancements. In order for the resource servers and authorization servers to function, they must have a trust relationship with the identity providers. Furthermore, ephemeral clients are intended to be the primary use case (Coburn et al., 2022).

The authentication is mainly expected to be authorized via the Authorization Code Flow^[15]. However, as it is built on top of OIDC, the Client Credentials Flow^[16] is a viable option in the majority of implementations, such as CSS^[17].

In both cases, an access token will be returned to the authenticating client. Which usually is a Bearer Token in OIDC Sessions. Solid-OIDC however, depends on DPoP tokens. DPoP tokens ensure that third-party web applications can not use the token, as the are protected by a a public and private key pair (Coburn et al., 2022; Fett et al., 2023).

Authorization is a fundamental aspect of Solid. Each WebID-owned resource must be authorized, with either or both WAC and ACP publishing mechanisms as specified. This even applies to resources that are publicly accessible and that permit unauthenticated requests. Both mechanisms utilize ACL to grant access to a resource, for a selected agent with defined access privileges. The possible privileges for a resource are read, append, and write access, as well as control access, which is used to manage the access privileges (Sarven et al., 2022; Capadisli, 2022).

In a container-based arrangement, all data pertaining to multiple agents is stored in a single storage resource. A mechanism must be in place or established to enable the agent with the requisite privileges to access the data. With WAC, two main options exist for defining an Access Object. In this context, the acl:accessTo option denotes the resource to which access is being granted, whereas the acl:default option denotes the container resource whose authorization can be applied to a resource lower in the collection hierarchy. Consequently, the location and structure of the storage resource are publicly visible, thereby increasing the risk of information disclosure vulnerabilities. The process of creating a new container resource however, is well part of the Solid Protocol and thereby the usage is unified. The process of creating a new container resource, however, is a fundamental aspect of the Solid Protocol, thereby ensuring unified usage. An illustrative example can be found in Listing 3 (Capadisli, 2022).

The implementation of custom mechanisms to expose data to associated agents may eliminate information disclosure vulnerabilities. However, when bypassing the authorization mechanism provided by Solid, the risk of inadvertently exposing data to an agent that does not have the appropriate permissions increases.

A storage-based approach to data storage for agents is a convenient method, as it encapsulates the data for an agent in a data space of their own. This approach ensures that no unnecessary information is shown to the public and that the data is stored in a secure context. As this is the purpose of a storage container, there is no individual mechanism required to ensure that the data is accidentally exposed to an agent that does not have any privileges to that data. The acl:accessTo and acl:default mechanisms, which have been applicable in a Container-Based Storage context, can also be applied here. However, there is a significant disadvantage to this approach over the Container-Based Storage approach. Namely, there is no unified API in the specification. While the creation of container resources is defined in the Solid Protocol, the creation of storage resources differs for each implementation. CSS for instance, requests a process in multiple steps, with the final step shown in Listing 4^[21].

In contrast, Inrupt’s ESS, as an alternative Solid Provider, only requires a simple authorized POST request as shown in Listing 5^[22].

The component cohesion represent general approaches to system design, as defined by Martin (2018). It is used to specifiy components that are ment to be gouped in one package or service. In order to accive that three principles are needed to be satisfied by the system, the Reuse/Release Equivalence Principle, the Common Closure Principle, and the Common Reuse Principle.

The principles outlined here are intended for object-oriented programming, but they are also generic concepts that can be applied to any top-level view of a system, as will be in this context. Therefore, each subsystem of the proposed system will be treated as a package in the object-oriented paradigm.

The external relationships of a component, namely the connections between one component and another, are referred to as coupling. Four principles are relevant to this matter: the Acyclic Dependencies Principle, Top-Down Design, Stable Dependencies Principle, and Stable Abstractions Principle (Martin, 2018).

These principles are to be taken into consideration when software components are aligned to each other on a top-level view. In addition to the Component Cohesion Principles, they also represent a part of the spectrum of a macroarchitectural view.

The system components consist of three main parts: the client, the proxy, and the Solid Provider as the server. The client does not require any concept-specific logic and will be omitted from the system component view. Clients can access the public endpoint without any changes to the API. The Solid Provider should also remain unaffected and only be accessed through its HTTP APIs. When accessing the storages that exist in the Solid Provider, it is important to divide them by ownership. This approach results in two different orchestrations of the system components: one where the captured data is held in trust, and another where the data is owned by the client.

The Entity-Relationship Model is based on the Solid Application Interoperability specification and describes the logical arrangement of the system’s data. This selected part of the specification can be used without further modification while the specification is still a draft. However, the current state of the specification does not fully satisfy the needs of a claiming mechanism. Figure 6 illustrates the additions to the model that are necessary to enable this mechanism. The full model can be found in Appendix A.

The model meets the requirements of the Solid Application Interoperability Specification, which is omitted in Figure 6. However, as described in Solid Application Interoperability, the data discovery will begin from the personal profile document. This document declares an interop:Agent, which refers to a registry set. This declaration informs agents that the data model will be modeled according to the specification. The registry set contains a list of all references to data registrations. A data registration is a resource container that contains all resources in a given tree^[24] and shape^[25].

As the interoperability specification does not address the handling of multi-agent data or require agents to participate in the specification, some enhancements have been made to the data model. In Figure 6, the highlighted additions (bold) to the model include the requirement that Things contained by the registry set must have a unique identifier based on the claimed item, which in this case is the hashed (SHAKE256) storage URL. The Thing’s type is claim:Registry, a newly introduced Claim Vocabulary that will be explained in detail in the Custom Vocabulary section.

The claim:Verification is a resource within the observed storage that serves to verify using a verification code. This code must correspond to the verification code within the claim:Registry to authorize the trustee’s access to the claimed data.

The vocabulary provided by the Solid Ecosystem does not cover all the necessary information that has been introduced in the data model. An custom RDF vocabulary for the claim process and logging of access has been introduced to support this.

The DPC agent captures, manages, and presents client data. Data can only be retrieved through the DPC agent. Figure 6 shows five paths through the data structure. Two of the paths are alternative paths that lead to the same leaf of the graph. The resulting data that can be received is:

The bracketed numbers indicate which branch to follow to access the described data.

Before looking at the serialized model, it is important to understand the structure of the HTTP endpoints. The storage URLs for the HTTP APIs will begin with a storage identifier added as a suffix to the base URL. Figure 7 shows the storage URLs at the second level. The data of the corresponding agent will be represented below this node.

The two most commonly used serialization formats for RDF-based data in data-driven web-based systems are text/turtle and application/ld+json. This inspection does not focus on data storage, as the Solid Provider is considered replaceable. However, HTTP APIs use Turtle as the exchange format for communication, which will be displayed below. As part of the structural hierarchy shown in Figure 7, all resources and listings refer to the data model shown in Figure 6.

There are three main behaviors that reflect interactions that can be executed directly or indirectly by the client: CRUD requests to a given resource, claiming log data, and discovering this data. The reference section defines subsequences that may be used in each of these interactions.

The project was created as a multi-package repository, with pnpm ^[33] serving as the package manager for Node.js-based projects. A multi-package repository is a repository that is used to group a variety of packages and artifacts that are maintained in a single repository.

The initial two levels of the project directory, including the packages contained within this project repository, are illustrated in Figure 23. Metadata directories and files are excluded from this diagram. Node child packages are stored in the ./apps directory, the ./packages directory, and the ./tests/benchmark directory. These directories contain the source code for the experimental prototype. The ./docs directory contains all documents related to the research. The ./scripts directory contains custom build scripts that are used to produce the project’s artifacts. The ./tests/http directory contains simple HTTP test files, which are used for singular tests.

The Node.js packages contained in the ./packages folder are generic source code fragments utilized in the ./apps packages. The ./packages/core folder contains the most basic data, which is used in nearly every package. In contrast, the ./packages/ui folder contains data relevant to the user interface or general view logic. These packages are required by the ./apps/client and ./apps/dpc packages, as they represent applications that an actual user can interact with. The ./apps/client package can be used to test client requests, while the ./apps/dpc package is used to view the monitoring data captured by the DPC middleware. The middleware, however, is part of the ./apps/proxy package, which delegates the ./apps/server package, a wrapper package for the CSS, to the Node.js process. The ./tests/benchmark package is a wrapper package for Apache JMeter, which is called from the Node.js process.

A variety of packages are utilised in the experimental prototype, with two packages of particular significance for this study: the Community Solid Server^[34] and Inrupt JavaScript Client Libraries^[35].

The Community Solider Server is a modular implementation of the Solid Protocol, which allows for a variety of configuration options due to its modularity. With the exception of the configurations that must be changed for the Experiments, the default configurations have been applied, as generated by the Community Solider Server configuration generator^[36]. The configuration options that have a particular influence on the tested scenario are data management and account management options. The data storage component of data management is configured as the file system by default, which may have an impact on performance due to the necessity of writing files to the hard drive. Similarly, locks are stored in the file system and are used to prevent simultaneous write operations on the same resource. The default authorization mechanism is WAC. With regard to account management, it is important to note that suffixes are used as storage container URLs, rather than subdomains. Furthermore, account management includes the identity provider, which uses OIDC. The complete configuration file can be accessed in Appendix B.

At the client side, the Inrupt JavaScript Client Library is used to access RDF resources in a uniformed way. Consequently, it is almost impossible to use CSS vendor APIs.

The network protocol HTTP is employed for all operations in this research. Security measures such as HTTPS are not considered in this analysis. Similarly, the Solid Provider has not been tested in an isolated network with a proxy, which must be the only public-accessible instance for a secure run in production environments. This potential issue has been tested with Docker^[37], but it did not affect the research scenario.

The scenarios to be tested on this system will cover CRUD operations on RDF resources, as these are the most common for ROAs and Solid applications, respectively. As suggested in the System section, a CRUD sequence will be built based on the CRUD resource lifecycle state machine described there. To generate a sequence that represents the behavior of an actual agent, a probability must be applied to all possible transitions :

Table 2 lists the assumptions for all possible transitions. It considers that the amount of read operations is significantly higher than other operations. Updates to and deletions of existing resources occur with greater frequency than the initial creation of a resource. Furthermore, the spreading of probability values occurs with the smallest probability when a resource is created.

The create transition can only be applied to deleted resources and to new resources. When a create transition is determined, another probability process will delegate it equally to the deleted resources or create a new resource. In order to ascertain which resource is affected by the CRUD operation, a subscript index is applied to the transition identifier. For example, the following notation is used: C₀ R₁ U₀ D₀. The uppercase letters represent the first character of the CRUD operations in any order, run sequentially. The container resources are organized in a collection hierarchy, with the default depth set to 1. In the context of the configurations of CSS, this equates to the storage resource, for example, http://proxy.localhost:4000/client/. Deeper hierarchies, such as URLs that are based on the aforementioned example, are ignored in the tested scenarios.

The DPC has three states that are considered configuration parameters. One state is that of a claimed storage container, which monitors the corresponding resources in the storage. In contrast, the second state is that of a non-claimed storage container, which will not monitor any requests to the storage. However, this state still needs to determine if it is in the list of storage containers to be tracked. The third state is that of a configuration that bypasses the proxy module and skips the logging process of the middleware. This is necessary because there is no existing benchmark against which the DPC configuration can be compared. In order to ascertain the extent of the increase in network load, it is essential to measure the bypassed scenario, which will serve as a reference value against which the other DPC configurations can be compared.

The bypass scenario utilizes the bypass mechanism of Forwarded Requests, which is used for internal self requests. The mechanism in adds a randomized header hash to the request, which is read during the request process in order to disable the DPC on self-calling. This is demonstrated in Listing 20.

A new environment variable has been introduced for testing purposes, which allows the automatic generation of the hash value to be static value to be used instead. This is demonstrated in Listing 21.

The Solid Protocol and Solid Application Interoperability permit two primary components to scale continuously within a running and growing Solid Provider. These components are the amount of storages managed by the Solid Provider and the registered ShapeTrees. For the purpose of mass testing, the client storage resources will have an additional amount. The amount will be applied to client storages (e.g., client42), resulting in a client storage resource such as http://proxy.localhost:4000/client42/. In the context of a test case where this client has a claimed storage resource, all client storages between client1 and the given index are considered claimed as well. The index also determines the storage container in which the CRUD operations will be executed. This is necessary to validate the edge cases with a large amount of storages. The same logic will apply to the ShapeTrees. Consequently, it is necessary to register a greater amount of ShapeTrees before the actual required ShapeTree appears in the register.

In order to perform the tests, version 5.6.3 of Apache JMeter^[48] was utilized. According to Nevedrov (2006), JMeter has three relevant test parameters that are contained by a thread group: the number of threads, the ramp-up time, and the loop count.

In addition to the thread group, there are samplers, which are configurable requests to the server, such as HTTP requests. Each of these HTTP samplers represents a transition in the CRUD sequence. Specifically, C_i is mapped to a PUT, R_i to a GET, U_i to a PUT, and D_i to a DELETE method in the request. The POST API, as an alternative to C_i, was not considered in the tested scenarios. In order to enforce a sequential run, independent of the execution time, thread group and loop, these values are applied to the resource name, as shown in Listing 22.

The body of the HTTP request is a minimal RDF triple (<ex:s> <ex:p> <ex:o>.), which is relevant for the creation and updating of resources utilizing the PUT method.

This section presents a comprehensive list of selected test parameters, organized by context. The aggregation of each parameter into a test plan is summarized in Table 7 at the end of this section.

Each execution of a test plan involves a preparation phase, which precedes the actual execution of the test plan. A general preparation step is to seed all client storage containers into the Solid Provider before executing the test plan. Similarly, DPC registries, claim data containers, and ShapeTrees are preproduced. Prior to each test run, the registry corresponding to the test case will be patched in the DPC social agent. The authorization will also occur outside of the actual execution of the test plan.

Table 3 presents the selection of Network Parameters utilized in the test plans, as detailed in Table 7. The ID column serves as a unique identifier for this parameter set. The CRUD sequence column indicates the CRUD operations that are executed during the test run. The run mode determines the order in which the operations are executed, either sequentially or in parallel. The hierarchical depth column indicates the depth of the resource container in which the operations are executed.

Table 4 presents the selection of Data Privacy Cockpit Parameters utilized in the test plans, as detailed in Table 7. The ID column serves as a unique identifier for this parameter. The description column provides an overview of the configuration applied to the module prior to the execution of the test run.

Table 5 presents the selection of Solid Ecosystem Parameters utilized in the test plans, as detailed in Table 7. The ID column serves as a unique identifier for this parameter set. The Storage Amount column refers to the amount and current index of storages used in the Solid Provider. Likewise, the ShapeTree Amount column defines the amount and index of ShapeTrees which are operated with. It should be noted that the selection of Data Privacy Cockpit Parameters may have an effect on this parameter. If the proxy module is bypassed, the Solid Ecosystem Parameters may become obsolete, as the DPC storage resource is not used. However, it is possible that this may have an influence on the performance of the Solid Provider.

Table 6 presents the selection of Apache JMeter Parameters utilized in the test plans, as detailed in Table 7. The ID column serves as a unique identifier for this parameter set. The number of threads column specifies the number of users engaged in the web service. The ramp-up period has been fixed at 10 seconds. This value is a rounded estimate derived from the initial transition of the CRUD sequence, which is C₀, and takes approximately 8 seconds. The initial transition will create the dynamic resources once, after which the system will be considered to be in a steady state. Given the results of previous testing, the loop count has been set to 10, which is a relatively small number of test runs for simple tests with one thread only. Nevertheless, this results in a considerable increase in the duration of the tests when the number of threads is augmented.

Table 7 presents the aggregation of configurable options to be tested as test plans. The schema column serves as a generic identifier for all parameterized test plans. The experiment column denotes the experiment in which a test plan was executed. The value of that cell is an incrementing natural number, starting at 1. The Network Parameters column refers to the ID column of Table 3. The Data Privacy Cockpit Parameters column refers to the ID column of Table 4. The Solid Ecosystem Parameters column refers to the ID column of Table 5. The Apache JMeter Parameters column refers to the ID column of Table 6.

The RRP that proposes that the granularity of reuse is identical to that of release is not applicable to the system design and subsystem arrangement. From the perspective of the project, each module can be reused at any time, either as it is contained by a shared package or can be moved there. This is because the project is arranged as a multi-package repository, as described in the Project Structure. From the perspective of HTTP APIs, this is not a problem, as the logic behind the request handlers is delegated to packages within the multi-package repository. However, currently, the shared packages relevant for central aspects of the system are only separated into core and ui. The core package contains global functions that are needed in all types of packages and applications, while the ui contains the parts that are used in graphical user interfaces and generic view logic. Nevertheless, the core package could be divided into multiple packages, as not all of its functions are necessary in all dependent packages. This would prevent the unnecessary release of packages if they were released separately.

According to the CCP, each component must change for the same reasons and at the same time. However, this is not feasible with the system design. For example, if the RDF vocabulary changes, every subsystem of the proposed system is affected, including the Solid Provider, the DPC middleware, and the DPC application. The Solid Provider must update the already persisted data structure if it is changed to an incompatible vocabulary. The DPC middleware produces new data in the form of the changed vocabulary, and the DPC application must be able to interpret and display the new data format if it requires custom view logic. Considering the related requirements of the Single Responsibility Principle, which states that each component should provide a service to a single actor, this appears to be a feasible solution. This is a satisfactory concern for both the DPC application and the middleware, since actors are defined as a group of one or more users. In this case, all Solid Provider users are grouped as an actor. The DPC application serves only as a user interface for handling access logs. The middleware is a proxy module that monitors traffic to the web server and creates the necessary resources if all conditions are met. However, complex scenarios where a single proxy module is responsible for multiple changes would violate the above rule.

The CRP demands that the components of a system should not impose unnecessary dependencies on others. The scenario is analogous to the one described in the RRP Analysis. From a Project Structure perspective, there are potential areas for improvement, but there are no violations on a conceptual level. However, when considering the HTTP APIs, there are relevant differences. With regard to component orchestration, it is possible to utilise the concept illustrated in Figure 4 in place of that in Figure 5. This would result in a reduction in the required storage containers, with the system becoming dependent on the client storage container alone. If the drawback to the system design is tolerable, the dependency on the module storage container could be regarded as an unnecessary dependency.

The ADP requires that no cyclical dependencies should be part of the system’s design. However, this is a component coupling principle that is not satisfied with the proposed approach. When a Forwarded Request is used, referred from the proxy as an actor, the proxy will request itself, meaning it has a dependency on itself and thereby a cyclic dependency. Even when a proxy is not requesting itself and requests are forwarded using forwarded headers, as illustrated in Listing 23, the server would still have a cyclic dependency. This is because the CSS requires the proxy hostname to be the base URL. Consequently, when Solid Provider verifies an agent from its own instance, it will still request itself through the proxy, which is then cyclic again.

The TDD proposes that the structural composition of a system cannot be predetermined at its inception. Instead, it is expected that this structure will naturally evolve as the system itself progresses. This is, in fact, an inherent aspect of proposed system development. It appears to be resolvable within the modular framework of a proxy, as illustrated in Figure 5 and Figure 4. Indeed, new proxy modules, such as the middleware component of the DPC, are added as additional middlewares, all of which are processed one after another.

Each variant of the Component Orchestration fulfills the need SDP, which requires that every component relies on a stable component. Given that the change of data does not affect the change frequency, the Solid Provider subsystem has the lowest change frequency. Given the conceptual purpose of the proposed system, all changes, including those made to the Solid Protocol, are handled in the proxy subsystem. Consequently, the changes are delegated to the proxy, which results in the higher change frequency being outsourced to it. Consequently, as the proxy is dependent on the server, the stable dependency requirement is satisfied. Any potential users of the public endpoint, such as the DPC application or any other HTTP client, are reliant on the stable proxy-server construct. As they are not responsible for any relevant application logic, they are free to modify their functionality as often as necessary.

The SAP is a principle that aims to separate high-level policies from the other functionalities of a system. If RDF, as a basis of Solid Ecosystem, is taken seriously, this is an inherent concept of it and thereby a satisfiable quality criterion without any additional design considerations. This is the case, as the full information structure and thereby the application logic is encapsulated in RDF data, although the processing needs to be implemented. The Solid Application Interoperability specification unifies a significant portion of this functionality.

The pretest is a single Authorised CRUD Request, which creates a resource on the webserver as this will always be the first request of a Resource CRUD Lifecycle . It will demonstrate how a request will effectively influence the overall system, particularly in terms of the multiplication of requests. A behavior that comes with the vendor-agnostic approach of the DPC Middleware when the Data Privacy Cockpit Parameter is set to C. The Solid Ecosystem Parameters are set to 1. The corresponding request to the pretest is presented in Listing 24.

The first run of the pretest is PRE1.1 as shown in Table 7. It uses the request shown in Listing 24. The corresponding console output when the request is executed is shown in Listing 25. As can be seen in the output, the proxy receives a total of 30 requests, all of which are triggered by the DPC Middleware or the Solid Provider.

Follow-up requests (PRE1.2) have significantly fewer total requests. A total of 12, as presented in Listing 26. It is less because the DPC agent running in the DPC Middleware has already established a session, which only needs to be done once. The same applies to the Authorization of the requesting agent, which in both cases is the owner of the storage resource.

The initial experiment was designed to provide an overview of a greater number of tests, with parameters that were not intended to create a critical load on the system. The objective was to identify potential areas of heavy load and to produce detailed insight based on these initial results.

Further analysis of the performance efficiency has been omitted due to the invalidity of the test reports that were created. Despite the completion of the experiment, all tests have been flagged as invalid due to the inability to determine the exact time of occurrence of errors in the proposed system.

The second experiment was planed with the same intend as the initial experiment, with a smaller scope, that only tackles the edge cases and brings less reports to analyse. The primary concern however was to get valid results and to overcome the error that has been found in the first experiment.

Further analysis of the performance efficiency has been omitted due to the invalidity of the test reports that were created. Despite the completion of the experiment, all tests have been flagged as invalid due to the inability to determine the exact time of occurrence of errors in the proposed system.

The erroneous behavior observed in Experiment 1 was not accidental, as verified in Experiment 2. Consequently, the third experiment was conducted under the assumption that an error would occur at some point, resulting in the loss of relevant data. To further investigate this error, individual tests were run to examine the specific edge cases that led to these critical errors.

A detailed analysis reveals three errors that occur internally while processing requests. The most significant differences relate to the storage amount (p) and the amount of ShapeTrees (q). However, a strict behavior could not be determined. It appears that test plans executed with lower values for p and/or q than those used in other tests within this experiment result in an error message indicating that a file for the locking system of the Solid Provider is requested that does not exist. This error resulted in the immediate termination of the process (exit code 1). This is a unique function of the CSS as described in Third-Party Software. The corresponding error message is shown in Listing 1.

Tests conducted with p and/or q values that were higher than those of other tests resulted in a fetch exception when attempting to locate storage resources. This aligns with the results observed in Experiment 1 and 2. An example of this error is shown in Listing 28. The error did not result in the immediate termination of the process.

The third error, which occurred during the processing of the requests, was a "header has already been sent" error. In such a case, the responseInterceptor, which is employed in the context of Forwarded Requests, attempts to modify the response object before returning it to the original requester. The error did not result in the immediate termination of the process.

This experiment aimed to tackle the locking issue found in Experiment 3. As previously stated in the Test Environment section, for testing purposes, the lifetime of locks has been increased to 172800 seconds, in order to be capable of handling long-running requests. In order to verify that this is not a miss configuration, the configuration has been reset to its default for this experiment.

The initial test scenarios were designed with considerably elevated numeric test parameters. Upon consideration of the assumptions presented in Experiment 3, it becomes evident that a solution to the deletion of the .meta resource, as outlined in Experiment 1, is necessary. The most trivial solution for that is to create the required files with a user with more privileges. As the files are persisted as files, these files are replaced by the same files created with a sudo user. This effectively prohibits the application, which is executed with current user privileges only, from deleting the resource.

The error message displayed in Listing 29 indicates that the Solid Provider lacks the necessary permissions to access the relevant resources. The intention was to prevent the deletion of this resource. However, the actual result was that the server process lacked sufficient privileges for read-only purposes.

As an alternative to Experiment 4 and Experiment 5, the objective of this experiment was to address the third issue identified in Experiment 3. This was achieved by deactivating the selfHandleResponse and responseInterceptor properties in the proxy. By doing so, all post-processing of requests from the proxy to the server was handled by the proxy library. This should prevent any manipulation of the response object, as the response has already been sent.

The straightforward solutions proposed in Experiments 4, 5, and 6 did not result in any improvement in the errors identified in Experiment 3. Consequently, patches^[53] to the applications have been implemented in order to address the aforementioned errors. The errors that have been identified thus far suggest that the proxy module is unable to handle the volume of requests it receives without causing errors. In particular, the issue of writing to the same file appears to be problematic, potentially leading to the locking issue. The DPC Middleware is configured to write logs on a daily basis, which means that a single file will be written in every request. This modification was implemented in this experiment with the intention of ensuring that a new log is written per request. Furthermore, the Create Dynamic Namespace process has been replaced with static paths, as this could also be handled in a bootstrapping step, which might lead to unnecessary requests. At last, the version of the Node.js Test Environment has been reduced to 20.14.0, the current LTS version. This was done as it is the preferred version of the oidc-provider^[54], a CSS inherent module^[55].

In Experiment 8, the limitations of the r value, which represents the number of threads, are examined based on the assumptions of Experiment 7. These assumptions posit that concurrency represents a significant challenge for the proposed approach. The value was incremented until the first error occurred, with the step width set to 1, starting at 1. This process was repeated until an erroneous test run was observed. In order to extend the runtime, the loop count, as part of the Apache JMeter Parameters, has been set to 1. Furthermore, the modifications to the application introduced in Experiment 7 have also been applied in this experiment.

The objective of this experiment was to determine whether the observed behavior in Experiment 8 would also manifest with a loop count of 10. In this experiment, the number of threads was limited to 7. Furthermore, the modifications to the application introduced in Experiment 7 have also been applied in this experiment.

The 10th and final experiment was intended to run in a larger context, to receive comparable results within the limits discovered in previous experiments. Furthermore, the modifications to the application introduced in Experiment 7 have also been applied in this experiment.

Table 8, Table 9, and Table 10 summarize of the test runs for TP1.10-i-10-10-r, with i in {B, C} and r in {1, 2}. They provide an overview of how the system behaves at different loads and configurations. The first column of the tables refers to the test plan that was carried out, followed by the i value of this test. The next column contains the corresponding p, q, and r values. Table headers that appear below these variables indicate the configuration of these variables.

The Test Run Error Summary is presented in Table 8. Its shows the percent of failed requests, returning a network status code^[60] greater or equals 400. Other requests are considered successful, in a network status code range 100-399.

It can be observed that the complexity of the test run is directly proportional to the number of failed requests, even with a limited number of results. When the Data Privacy Cockpit Parameters are set to C, the failed requests are on average 2.92% higher than when the proxy module is bypassed B. Furthermore, the erroneous requests also increase when the number of threads (r) is increased. It is noteworthy that the number of errors also increases in bypassed cases, despite the original request not triggering any subprocesses.

Table 9 presents the averaged response time in seconds, rounded to two decimals. The standard deviation of B is 0,31681 s, the standard deviation of C is 5,560185 s.

The values presented are consistent with the results presented in Table 8. A higher complexity results in a higher average reaction time. The values of the B column are still below 1 second, which is the maximum limit that can cause a delay in the user’s cognitive process. The C column, on the other hand, dramatically increases the amount of time a potential user can focus on a process. Based on the observations of Nielsen (1993), the value is limited to 10 seconds, which is exceeded by about 4 times even with the lowest possible r value of 1. With this value set to 2, it is exceeded by about 5 times the recommended limit.

The overall performance of the proposed system is quantified by the throughput measurements presented in Table 10. The values listed are in transactions per second. The standard deviation of B is 12,87 Transactions/s, the standard deviation of C is 0,005 Transactions/s.

As observed in the measurements shown in Table 8 and Table 9, the throughput drops significantly when the complexity of the system and the amount of threads increases. The average decline in transactions per second is 13.29. In considering the aspects identified by IBM as influencing throughput, namely processing overhead in the software, the degree of parallelism supported by the software, and the types of transactions processed, it appears that these factors may be plausible causes of the issues that have been found.