Store and maintain status of privacy requests from end user to services
Southbound requests are privacy requests that are triggered by the end user, via DPS, to the clients that are affected by the request.
These requests must be relayed to the clients that are affected by the request and need to take action on them. Southbound requests may generate equivalent responses from clients, affecting their status.
Northbound requests can be of two types:
Privacy requests initiated by clients to DPS (on behalf of a user)
Response to privacy requests previously initiated by the end user via DPS
Any privacy requests triggered or updated in DPS may trigger a notification to the parties affected so they can keep all their systems in sync. The main goal of the notification is not to provide state changes, but to notify clients that changes have happened and allow them to act on these changes.
This can happens in two ways:
Through a notification from DPS to the systems affected
Through API calls to DPS from the systems themselves
There are three basic patterns that can be used for notifications:
Our design decision for notifications have been to do Ping/Pull in this first iteration.
In future iterations we’ll might explore Push in 2 waves (Light payload then Full payload), based on the http://resthooks.org/ defined patterns.
In addition, clients themselves will also be able to do Polling via the APIs provided if Ping/Pull is not desired.
When a change or privacy request is triggered via the privacy API, the event is published on a topic per project for all the affected projects of that privacy request.
It then publishes a notification of that privacy request to one or many topics (per project + privacy request types)
The lambda function starts processing the notification
The lambda function then update status of the request based on the response from endpoint
The privacy request database will have the status from any initiated request processed or not processed by the lambda function. Failed and unacknowledged requests can then be processed separately (retry/abandon functionality). The same database is used to process southbound API requests from clients, for example when clients are updating the privacy requests status with completed.