This project is a Basic system to gather and store consent from users regarding various permissions. The system offers strong audit guarantees through its architecture
This project aims to offer a solution that can help partner platforms and APICURON maintain compliance with GDPR regulations, streamlining compliance and reducing risk factors when sharing personal data.
The APICURON Consent Management Platform is designed to be an infrastructure component deployed on the scientific resource's infrastructure, making compliance a more straightforward, default approach.
In accordance with the regulation mentioned above, this section will outline the specifications that need to be aligned to offer proper, reasonable mechanisms enabling compliance.
- Storage System
- Includes auditing features to be used for demonstrating compliance
- A user interface for providing and withdrawing consent
- Integrates a mechanism to present the privacy policy documents to users.
- Collects informed, explicit, and unambiguous consent.
- An application programming interface
- Gives secure access to consent-related data
- Offers means to react to consent withdrawals (e.g, webhooks) actively
- Portability
This system needs to be easily portable and deployable on various infrastructure environments (on-prem, cloud, etc).
The specification mentioned above does help apply GDPR principles and comply with regulations. This does not mean that this tool is a complete solution for GDPR compliance. On two main axes, the storage abstraction layer and the full extent of GDPR regulation.
- In the storage abstraction, this tool offers a way to prevent the application itself from deleting data or tampering but does not prevent the underlying infrastructure layer, (filesystem, diskI/O) from tampering, ensuring the compliance of these storage infrastructure layers is at the responsibility of the hosting organization.
- Complete Compliance: Here are some examples of articles where the specification above is not fit to assist in compliance.
-
Article 15 Right of access by the data subject
The specification includes a system that only stores consent and does not fall within other personal data that may be stored on different infrastructure components. -
Article 17 Right to erasure
The specification describes only a system to store consent data, which does not fall within the right to erasure, as it is a necessary processing of data to demonstrate compliance with the regulation. Any other personal data outside the scope of the specification is subject to this regulation.
Following the technical specification mentioned above. This section will describe the concrete decisions that are taken. The solution is only composed of three components: a web server, a database, and a web component.
The web component is a user interface component that users can use to state their consent explicitly. This component is supposed to be easily embedded in the scientific resource’s web interface with little effort and configuration. When the user explicitly gives their consent, this component would send a request to the web server in this system.
Tools used: Angular, Angular Elements
The web server acts as the core of the system. Once the web component submits consent data (either offer or withdrawal of consent), the web server stores the information in the database before propagating this information to the relevant parties.
Tools used: Node.js
The choice of KurrentDB (formerly EventStoreDB) is critical as its Event Sourcing pattern inherently provides a verifiable, anti-tampering audit trail by design. This native feature directly supports the GDPR's Demonstration of Compliance obligation
The Event Sourcing pattern defines an approach to handling operations on data that's driven by a sequence of events, each of which is recorded in an append-only store. Application code raises events that imperatively describe the action taken on the object.
Although the Event Sourcing pattern was initially developed to improve scalability in microservices by handling concurrent update operations, this pattern serves the aim of this project case by offering an audit trail by design, which is necessary to comply with regulations requiring verifiable, anti-tampering records for consent storage. These guarantees are essential in this case. Although traditional relational databases can offer an audit trail, they require advanced configurations that can become difficult to maintain & reproduce in different environments or through database versions.
Tools used: KurrentDB![][image1]Figure depicting Event Sourcing pattern architecture, source: azure
After identifying the elements of the system, this section will elaborate on the interactions of these elements within and outside the system. Of course, these interactions independently describe very little. Therefore, this section will describe these interactions through workflows with overlapping logical components and implementations that all serve different purposes based on the workflow.
Using the web component, users can offer or withdraw consent. The web component would make API calls to the consent management web server, which performs multiple actions in parallel.
- Update the event log in the database with the new event
- Publish a new state in the API, which means that every subscriber on the web API can get an event about the updated consent of the user, which includes APICURON & partner resources.
The system architecture mandates that the Web Server function as the authoritative Query Interface for consent data. This interface facilitates the synchronous retrieval of the aggregated consent state for a specified data subject. Critically, this function is designed to operate independently of the system's asynchronous event-driven workflows (e.g., consent recording or update propagation). This design ensures that partner resources, utilizing this API endpoint, can consistently and immediately access the most recent, consolidated consent record necessary for lawful data processing.