GDPR compliance
Overview
The General Data Protection Regulation (GDPR) details rules and regulations all systems and applications must abide by. Read up on what GDPR is at gdpr.eu/what-is-gdpr/.
There are a large number of regulatory items determining what makes a particular system compliant. The main one to consider in the context of the NOUMENA platform is retention of Personally Identifiable Information (PII). When a system processes and stores PII, the GDPR requires that the system be able to remove PII at the request of the PII principal (person to whom the PII relates).
The NOUMENA platform provides the tooling to develop GDPR data retention compliant protocols.
Warning
It’s up to NPL system operators/administrators to use these tools in an effective and correct manner to create protocols that adhere to the solution’s data retention rules and GDPR requirements. NOUMENA provides some support for such compliance tasks, but does not take responsibility for particular solutions' GDPR compliance.
Data removal
There are two ways to handle data removal in order to make a system GDPR compliant: data deletion and data anonymization.
Data anonymization is defined according to the ISO standard ISO 29100:2011 as the:
process by which PII is irreversibly altered in such a way that a PII principal can no longer be identified directly or indirectly
There are two kinds of data in the platform in which PII can reside. These are current protocol states, and historical protocol states.
The approach we allow developers to take for current protocol states is to anonymize data. Data removal for historical protocol states is implemented as a deletion.
Examples
Current protocols
In order to allow NPL system operators/administrators to anonymize PII within current protocol states, the
Engine Admin API provides a POST anonymize
endpoint.
Consider the following NPL protocol.
package testpkg
@api
protocol[p] Anon() {
var textFieldName: Text = "personal data";
var numberFieldName: Number = 123;
var mapFieldName: Map<Text, Text> = mapOf<Text, Text>().with("key", "value");
};
The anonymize
endpoint allows the caller to overwrite the value of one or more top level protocol fields. The request
requires the ProtocolId
of the protocol in the url path, and a list of ApiMapValue
in the request body:
http://engine:12700/admin/engine/anonymize/{protocolId}
To anonymize the text field textFieldName
:
[
{
"typeName": "Map<Text, Text>",
"nplType": "map",
"value": [
{
"key": {
"nplType": "text",
"value": "textFieldName"
},
"value": {
"nplType": "text",
"value": "anonymizedFieldValue"
}
}
]
}
]
Each ApiMapValue
should be of a single type, so if you need to change fields of different types, such as a Text
field and a Number
field, the request would consist of the following two maps:
[
{
"typeName": "Map<Text, Text>",
"nplType": "map",
"value": [
{
"key": {
"nplType": "text",
"value": "textFieldName"
},
"value": {
"nplType": "text",
"value": "anonymizedFieldValue"
}
}
]
},
{
"typeName": "Map<Text, Number>",
"nplType": "map",
"value": [
{
"key": {
"nplType": "text",
"value": "numberFieldName"
},
"value": {
"nplType": "number",
"value": 1
}
}
]
}
]
The endpoint can also take more complex types, such as a Map
:
[
{
"typeName": "Map<Text, Map>",
"nplType": "map",
"value": [
{
"key": {
"nplType": "text",
"value": "mapFieldName"
},
"value": {
"typeName": "Map<Text, Text>",
"nplType": "map",
"value": [
{
"key": {
"nplType": "text",
"value": "anonymizedMapKey"
},
"value": {
"nplType": "text",
"value": "anonymizedMapValue"
}
}
]
}
}
]
}
]
What follows is a curl example of an anonymize
request to anonymize top level fields of a current protocol state.
curl -X POST 'http://localhost:12700/admin/engine/anonymize/<protocolId>' \
-H 'accept: application/json' \
-H 'Content-Type: application/json' \
-d '[
{
"typeName": "Map<Text, Text>",
"nplType": "map",
"value": [
{
"key": {
"nplType": "text",
"value": "textFieldName"
},
"value": {
"nplType": "text",
"value": "anonymizedFieldValue"
}
}
]
},
{
"typeName": "Map<Text, Number>",
"nplType": "map",
"value": [
{
"key": {
"nplType": "text",
"value": "numberFieldName"
},
"value": {
"nplType": "number",
"value": 1
}
}
]
},
{
"typeName": "Map<Text, Map>",
"nplType": "map",
"value": [
{
"key": {
"nplType": "text",
"value": "mapFieldName"
},
"value": {
"typeName": "Map<Text, Text>",
"nplType": "map",
"value": [
{
"key": {
"nplType": "text",
"value": "anonymizedMapKey"
},
"value": {
"nplType": "text",
"value": "anonymizedMapValue"
}
}
]
}
}
]
}
]'
Historical data (engine store)
In order to allow NPL system operators/administrators to delete PII in historical protocol states versions, the
Engine Admin API provides a DELETE anonymize
endpoint.
What follows is a curl example of an anonymize
request to delete historical protocol states (and related commands and
notifications) of a given protocol.
curl -X DELETE 'http://localhost:12700/admin/engine/anonymize/<protocolId>'
This endpoint also provides an optional dryRun
parameter, which will just perform a dry run version for the historical
protocol states deletion and will not delete any data.
The endpoint returns a response of type ApiDeleteResult
, indicating table rows counts (to be) deleted.
Historical data (history store)
The History Admin API provides a DELETE anonymize
endpoint to
delete all protocol states of a given protocol instance (and related commands and notifications) from the history
database store.
curl -X DELETE 'http://localhost:12710/admin/history/anonymize/<protocolId>'
This endpoint also provides an optional dryRun
parameter, which will not delete any data.
The endpoint returns a response of type ApiHistoryDeleteResult
, indicating table rows counts (to be) deleted.