You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Event Stores are immutable. There are several techniques to protect sensitive information. Crypto Shredding is the process of encrypting sensitive data, associating it to a resource owner (the person who owns the data), and being able to dispose the encryption key when the person exercises the right to be forgotten.
Describe the solution you'd like
A built-in crypto-shredding mechanism where sensitive data in an event could be marked with a [PersonalData] attribute, or similar, and where the resource owner (e.g: the person Id) could be marked with a [DataSubjectId] attribute, or similar, would be ideal. It could follow a similar approach to this one
where the serialization process
Checks whether the event has a [DataSubjectId] attribute
If there is one, it retrieves a new or existing symmetric encryption key from a repository (AKS, in memory or whichever)
It looks for all the properties within the event, at root level or nested, with the [PersonalData] attribute, and it uses the encryption key to encrypt the value, so that it's stored as a string or base64 string property in the JSON. The encrypted value could have a specific suffix (e.g: '.crypto') which makes it explicit that the value is not the original one but the encrypted one.
It saves the DataSubjectId value as a key value pair entry in the event metadata, so that it comes handy later on when deserializing
and the deserialization process
Checks whether the event json has a DataSubjectId value in the metadata
It retrieves the encryption key from the repository
If the key exists, it decrypts every encrypted value (i.e: the values with suffix '.crypto') during deserialization
If the key does not exist, it sets the default value or masks it (e.g: "", "***" or null for strings, 0 for numbers, false for booleans, etc.)
Describe alternatives you've considered
An alternative would be to provide a contract IEventSerializer where we could register our own. But this IEventSerializer would need to also have access to write/read metadata for the above approach to work.
Then we could create serializers with Newtonsoft or System.Text Json
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
Event Stores are immutable. There are several techniques to protect sensitive information. Crypto Shredding is the process of encrypting sensitive data, associating it to a resource owner (the person who owns the data), and being able to dispose the encryption key when the person exercises the right to be forgotten.
Describe the solution you'd like
A built-in crypto-shredding mechanism where sensitive data in an event could be marked with a
[PersonalData]
attribute, or similar, and where the resource owner (e.g: the person Id) could be marked with a[DataSubjectId]
attribute, or similar, would be ideal. It could follow a similar approach to this onewhere the serialization process
[DataSubjectId]
attribute[PersonalData]
attribute, and it uses the encryption key to encrypt the value, so that it's stored as a string or base64 string property in the JSON. The encrypted value could have a specific suffix (e.g: '.crypto') which makes it explicit that the value is not the original one but the encrypted one.and the deserialization process
Describe alternatives you've considered
An alternative would be to provide a contract
IEventSerializer
where we could register our own. But thisIEventSerializer
would need to also have access to write/read metadata for the above approach to work.Then we could create serializers with Newtonsoft or System.Text Json
The text was updated successfully, but these errors were encountered: