This work will investigate a way to increase the trustworthiness of online applications. The focus will be on the addition of mutual non-repudiation to this kind of applications. Mutual non-repudiation offers both the user and the organization behind the application indisputable proof, confirming the execution and contents of transactions in the application. Mutual non-repudiation will be correctly defined, followed by an investigation on how non-repudiation can be achieved. To achieve non-repudiation, a non-repudiation protocol will have to be executed. There are numerous non-repudiation protocols available, all with different properties. To be able to select an appropriate non-repudiation protocol, these protocols will have to be compared somehow. Therefore, we have introduced an evaluation system, using weighted scores, which will evaluate each protocol on a number of properties. These properties do not only include technical protocol properties, but also factors such as deployment, maintenance and future dispute resolution. Based on this evaluation system, we have a foundation to select an appropriate protocol, based on the properties that are important in our specific scenario.
To be able to investigate the requirements of a middleware service for non-repudiation, an architecture for an online application is needed. The typical architectural model for this kind of applications is a 4-tier model. Following this model, we have designed an online banking system. We have also provided a partial implementation of this architecture.
We investigate and describe the requirements of a solution that integrates non-repudiation in a 4-tier architecture. Due to the lack of adequate existing solutions that offer such services, a custom non-repudiation middleware service is designed and developed. During the design of the service, the proposed requirements are taken into account as much as possible. The non-repudiation middleware service will actually be integrated into the online banking application. This integration process, together with the proposed requirements, will serve as the evaluation criteria for the non-repudiation middleware service.
Finally, we have described two patterns discussing the integration of non-repudiation in application architectures. A first pattern, the NON-REPUDIATION pattern discusses the integration of non-repudiation in a generic architecture, without focusing on a specific model. The WEB CONTEXT NON-REPUDIATION pattern will extend the NON-REPUDIATION pattern and focus on the 4-tier architecture model. These patterns also include two implementation scenario’s. One scenario describes how to apply the pattern to a middleware service, while the other does the same for direct integration into a new architecture.