Is Self Sovereign Identity compliant with the GDPR?
Self-Sovereign Identity (SSI) is a new concept of digital identity management that aims to give individuals full control over their own data on the internet. The concept is based on several emerging technologies such as distributed ledgers and decentralized identifiers.
The General Data Protection Regulation (GDPR) is a globally recognized EU regulation concerning the protection of individuals’ personal data. The concepts and terminology of the GDPR were created in the spirit of the then prevailing centralized identity models. Contrary to that, the novel concept of SSI is based on a decentralized architecture. SSI significantly differs from previous identity management systems. The question therefore arises whether SSI is compatible with the GDPR.
There are plenty of scientific articles [1], guides [2] or fantastic books like [3] explaining the concept, most widely used architecture and technologies of SSI systems. In this article some knowledge of SSI and the GDPR will be assumed. I am going to address 6 problem areas that SSI systems might face with respect to the GDPR and give some remarks on why they are deemed problematic. Those problem areas are the ones I repeatedly encountered across the scientific literature of the field. At the end of this article, you can find a list of good resources regarding GDPR and SSI.
Is personal data being processed in SSI systems? Is the GDPR applicable?
Since the GDPR only applies to processing of personal data it first needs to be settled whether such personal data processing even takes place in SSI systems. SSI implementations vary greatly in the amount and manner of personal data processing.
Credentials and revocations of credentials usually concern natural persons, so the GDPR is applicable to the processing of these data types in an SSI system. Encryption does not suffice to make personal data anonymous but rather pseudonymizes it. According to the GDPR, pseudonymous data is considered personal data hence the GDPR also applies to encrypted personal data. Most scholars argue that private keys and public keys concerning natural persons must also be included in the definition of personal data.
So according to most experts in the field, the GDPR is applicable to SSI systems to at least some extent because of personal data being processed.
Is consent to process personal data obtained in SSI systems?
Explicit consent is the most frequently used legal basis for the processing of a data subject’s personal data under the GDPR. It must therefore be possible for users to clearly express for which data sets consent to process is given.
It’s the very core idea of SSI to give users interfaces that enable them to keep their data by themselves and actively agree to any processing activities. Developers of SSI wallets need to make the handling of applications simple and clear, so no data is mistakenly shared. Giving consent is built into the SSI system, which makes obtaining consent more efficient than in previous identity management solutions.
Who is the controller in SSI systems?
Controllers determine the means and purposes of the processing of personal data. Assessing who is the controller in an SSI system proves difficult. Regarding the trust triangle of holder, issuer and verifier, in most cases the role of the controller can be assigned as follows.
Some scholars argue that in SSI systems the holder has the power over what data to share, with whom, for which purposes. Unless the SSI system is offered as the only way to achieve a particular goal (e.g., enrolling at a university), the holder is also free to connect to an issuer or not. Accordingly, holders can be described as ‘in charge of their own data’ in SSI systems.
Given the logic of the GDPR however, two separate entities need to be present, namely data controllers and data subjects, to make the regulation applicable. It can be argued that GDPR and SSI are therefore entirely incompatible since the regulation should not apply in the SSI case of data subjects being the actual controllers of their personal data. Most experts argue however that though holders oversee their own data they should not be considered as controllers in the sense of the GDPR (exceptions: household exception, holding data for own children, acting as legal guardian).
Issuers and verifiers of a transaction can likely act as controllers. Issuers who offer to issue VCs specify the means (specific SSI-network) and the ends (e.g. issuing a VC after completing an online course). Similarly, Verifiers who wish to verify a claim specify the means (SSI-network) and the ends (basis for decision whether to trust certain data) of the data processing.
The controller must demonstrate compliance with the principles of the GDPR. The question of who acts as controller is therefore highly important in any transaction in an SSI system. Whether the obligations associated with being the controller can be met at all times must be investigated based on the specific implementations and cases. In some implementations there might also be additional actors in the system that could qualify as controllers.
Who is the processor in SSI systems?
By GDPR definition a processor works on behalf of a controller. It has already been established that a holder cannot act as controller of his or her own data because it goes against the logic inherent to the GDPR. However, most scholars agree that although the holder does not constitute a controller, the actor assigned a processing task from the holder is not exempt from the GDPR and can nevertheless be understood as processor.
So, regarding the roles of the actors in the trust triangle, an issuer can be a processor if he or she issues a VC at the request of a holder. There might be other actors in specific networks that can constitute a processor.
The controller must ensure that the chosen processor complies with the principles of Privacy by Design and Privacy by Default. The question of who is assigned the processing task is therefore vital to assess compliance with the GDPR. Again, whether the obligations are met can only be assessed with a case-by-case analysis within a specific SSI implementation.
Can SSI systems guarantee a subject’s ‘right to be forgotten’?
Per GDPR data subjects can request the controller to delete their data if there exists no other legal basis for processing. This right is called ‘right to erasure’ or ‘right to be forgotten’.
The right to be forgotten is the most frequently discussed problem area of SSI with respect to the GDPR since most SSI implementations are based on blockchain technology. Blockchain technology has the property of immutability, which means that no entry stored on the blockchain can be changed after it was once written. According to its proponents, blockchain technology can nevertheless provide the best GDPR-compliant solution for digital identities despite its immutability. This is the so-called “GDPR Blockchain Paradox”. According to proponents, the paradox is solved by storing all sensitive data “off-chain” and only associated proofs “on-chain”.
The question of whether an SSI implementation can guarantee the right to erasure is thus equivalent to the question of whether on-chain data in an SSI system can be considered personal data and if there is a way to render that on-chain data anonymous or worthless.
Usually, the right to be forgotten can be guaranteed since SSI Governance Frameworks (e.g. Sovrin) disallow writing personal data to the public ledger directly. Even in cases where private DIDs are written to a public ledger, the right can be enforced by simply deleting the associated DID document. However, if, for example, Verifiable Credentials that make a natural person identifiable end up on a public SSI ledger, the right to erasure is no longer guaranteed due to the immutability of the blockchain.
Do SSI systems comply with the principle of data minimization?
Any blockchain-based SSI system could potentially contradict the principle of data minimization since blockchains are globally replicated, append-only databases. Additionally, data minimization means storing personal data only as briefly as necessary to serve the specific purpose. The purpose of transactions in SSI systems is most frequently authentication which is completed in the blink of an eye. Thus, any personal data would have to be deleted right after the purpose has been served to comply with the principle of data minimization. Some scholars deem compliance with data minimization difficult.
Contrary to that, the point can be made, that data stored on-chain cannot be further minimized since it would lose its very purpose. Furthermore, in many implementations on-chain data does not constitute personal data. The GDPR principle of minimization therefore does not have to be complied with on the ledger in those cases.
It can be argued that SSI systems enable a significant reduction of the amount of personal data currently stored in organizations’ data siloes. Personal data in SSI systems is ideally stored and managed only by the holder of the identity using wallet software. Organizations (like companies) can repeatedly request and delete users’ personal data if they need it multiple times. Theoretically, the amount of personal data stored in organizations’ databanks can be minimized to storing just DIDs to be able to reidentify users in case of repeated contact.
The principle of data minimization is therefore likely better met in SSI systems than in any previous identity management systems.
A complete assessment of whether an SSI system is compliant with the GDPR can only be made case-by-case within a specific implementation. The questions listed above nevertheless give a concise overview of the most relevant problem areas.
I would be happy to hear your thoughts on the matter in the comments or on twitter @stidl_jun.
Here’s a list of great (scientific) readings on the topic:
[1] A. Mühle, A. Grüner, T. Gayvoronskaya, and C. Meinel, “A survey on essential components of a self-sovereign identity,” Comput Sci Rev, vol. 30, pp. 80–86, Nov. 2018, doi: 10.1016/j.cosrev.2018.10.002.
[2] “Self-Sovereign Identity: The Ultimate Guide 2022,” 2022. https://www.dock.io/post/self-sovereign-identity (accessed Nov. 21, 2022).
[3] A. Preukschat and D. Reed, Self-sovereign identity. Manning Publications, 2021. Accessed: Dec. 14, 2022. [Online]. Available: https://books.google.at/books?hl=de&lr=&id=BfQ1EAAAQBAJ&oi=fnd&pg=PA1&dq=preukschat+reed+self+sovereign+identity&ots=iCKzsz5qUt&sig=4KJKyk1n5DRCdHeKCkm1REWJTvY
[4] G. Kondova and J. Erbguth, “Self-sovereign identity on public blockchains and the GDPR,” Proceedings of the ACM Symposium on Applied Computing, pp. 342–345, Mar. 2020, doi: 10.1145/3341105.3374066.
[5] N. Naik and P. Jenkins, “Your Identity is Yours: Take Back Control of Your Identity Using GDPR Compatible Self-Sovereign Identity,” in Proceedings of 2020 7th IEEE International Conference on Behavioural and Social Computing, BESC 2020, Nov. 2020. doi: 10.1109/BESC51023.2020.9348298.
[6] A. Chomczyk Penedo, “Self-Sovereign Identity Systems and European Data Protection Regulations: an analysis of roles and responsibilities.,” Open Identity Summit 2021 , pp. 95–106, 2021.
[7] Bilgesu Sumer, “Can Self-Sovereign Identity (SSI) fit within the GDPR? : a Conceptual Data Protection Analysis (Part II) — CITIP blog,” Jun. 03, 2022. https://www.law.kuleuven.be/citip/blog/can-self-sovereign-identity-ssi-fit-within-the-gdpr-part-ii/ (accessed Nov. 12, 2022).
[8] Sovrin Foundation, “Innovation Meets Compliance Data Privacy Regulation and Distributed Ledger Technology,” Jan. 2020. Accessed: Nov. 22, 2022. [Online]. Available: https://sovrin.org/wp-content/uploads/GDPR-Paper_V1.pdf
