Self-sovereign identity: Legal compliance and the involvement of governments
This article describes how governments of sovereign states might be involved in building identity ecosystems based on self-sovereign principles and how regulatory conformity of such ecosystems can be achieved.
When it comes to identity management the involvement of the government can be a tricky topic. It needs to be involved to enable access to public services, adapt legislature and guarantee equal access for its citizens. However, it should not be able to control or monitor all aspects and activities of its citizens. Self-sovereign identity (SSI) might for some imply, that a citizen is suddenly able to issue his own ID-card, which isn’t the case. Governments are still the primary source of foundational identities.
The government as issuer of foundational identities
While individuals gain more autonomy with SSI the issuance of national IDs is still the responsibility of the public administration. The Pan Canadian Trust Framework (PCTF) differentiates between foundational and contextual identities.
“A foundational identity is an identity that has been established or changed as a result of a foundational event (e.g., birth, person legal name change, immigration, legal residency, naturalized citizenship, death, organization legal name registration, organization legal name change, or bankruptcy).” PCTF [1]
Hence, the government continues to be the issuer of foundational identities and still holds the authority to revoke these credentials when necessary. However, SSI also enables the usage of other identity providers, which are context dependent — leading to a contextual identity as further explained within the PCTF.
“A Contextual Identity is an identity that is used for a specific purpose within a specific identity context (e.g., banking, business permits, health services, drivers licensing, or social media). Depending on the identity context, a contextual identity may be tied to a foundational identity (e.g., a drivers licence) or may not be tied to a foundational identity (e.g., a social media profile).“ [1]
This means a customer of a bank can use his verified bank ID to identify himself at a credit bureau. Since the bank ID is based on a foundational identity, the contextual identity provided by the bank can be sufficient in this particular use-case given the regulatory environment allows such a usage. However, a contextual identity can, but doesn’t have to be based on a foundational identity.
The European Commission supports the continued usage of contextual identities online and only demands the usage of foundational identities when required by law as stated in the eIDAS public consultation [2] regarding the option to extend the regulation for the public sector:
“A European identity solution enabling trusted identification of citizens and companies in their digital interactions to access public or private online services (e.g. e- commerce), should be entirely voluntary for users to adhere to and fully protect data and privacy. Anonymity of the internet should be ensured at all times by allowing solutions for anonymous authentication anonymously where user identification is not required for the provision of the service.“ [2]
Regulatory compliancy
When dealing with personally identifiable information (PII) all involved stakeholders need to adhere to a certain set of laws, which dictate the usage of the such data. These laws highly depend on the citizenship of the data subject (the individual the PII is about) among other important factors. Although the following paragraphs are specifically devoted to the laws of the European Union, the conclusion might also be applied to similar laws such as the California Consumer Privacy Act (CCPA) or the Indian Personal Data Protection Bill (DPA).
Within the European Union, there are two laws, which have a significant influence on identity frameworks. The General Data Protection Regulation, better known as GDPR, determines how personal data from EU citizens can be collected and used. The other important law is the Electronic IDentification, Authentication and trust Services (eIDAS) provision specified in N°910/2014 [3]. It constitutes the main electronic identification trust framework in the EU and is an elemental building block of the digital single market.
GDPR — General Data Protection Regulation
The EBSI GDPR assessment [4] notes that
“According to this Regulation, there are two types of actors whose key role in data processing and whose relationship to the data within the data processing environment leads the European legislator to attribute them a set of obligations and responsibilities. Thus, these liable actors are subject to data protection rules.“ [4]
These are data controllers, which are defined in article 4(7) GDPR [5] as
“the natural or legal person, public authority, agency or other body which, alone or jointly with others, determines the purposes and means of the processing of personal data; where the purposes and means of such processing are determined by Union or Member State law, the controller or the specific criteria for its nomination may be provided for by Union or Member State law” [5]
which
“have to take all necessary measures so that data subjects are sufficiently informed and have the ability to exercise their data protection rights.“ [4]
The other actor is the data processor who acts as delegate of the data controller and is a separate legal entity according to the opinion 1/2010 of the Data protection working party. [6] With multiple nodes running a decentralized network every node acts as a data processor or data controller depending on if the node operator is processing the data as a delegate or not. The EBSI GDPR report further notes:
“in case of joint controllership, data controllers can contractually assign partial responsibility based on distinct stages of data processing.“ While an agreement between these data processors can regulate the responsibilities, “data subjects will have ot (sic!) be able to exercise their rights against every joint controller“ and “nodes that add and process the on-chain ledger data in order to maintain the consensus will be individually qualified as joint data controllers and this, regardless of a contractual relationship stating the contrary.“ [4]
For public blockchains with permissionless write access such as Bitcoin or Ethereum, this means, that every miner, which is participating in the proof of work consensus is regarded as data processor given there is an unintentional personal data leakage or correlation with an URL (Uniform resource locator) of a service endpoint within DID Documents as pointed out as critical to keep PII private by the DID specification of the W3C in section 10.1.[7] This threat in addition of the numerous other correlation risks mentioned in section 10.2 and 10.3 of said specification make the current implementation of SSI based on permissionless blockchains, which inhibit the capability for natural persons to write a anywise DID on the ledger, a daunting privacy challenge.
Another important aspect is the question if credentials (or any other form of PII) is stored as hash on the verifiable data registry. A hash is a data digest and is considered a one-way function, which in theory leads to an anonymization of the original information. The debate around the question if a hash constitutes PII is likely to continue, since national data protection agencies are struggling to clearly define if the hashing can be considered an anonymization or pseudonymization.
“According to the Spanish DPA (Data protection agency), hashing can at times be considered as anonymization or pseudonymization depending on a variety of factors varying from the entities involved to the type of the data at hand.“ [4]
Even if the hash constitutes a one-way obfuscation technique, which anonymizes PII, it I) requires a transaction on a public ledger and II) it puts data controllers in a higher risk position with the obligation to avoid correlation of individuals. Risk minimizing obligations for data controllers are easier to implement when there is no hash of a verified credential or verified presentation stored on a public ledger.
When it comes to the wallet itself the EBSI GDPR report notes that
“there is growing consensus about the possibility of data subjects to being simultaneously considered as data controllers for the data that refer to themselves“. The report provides the recommendation that “the privacy preserving technical and organisational measures of the wallet and the personal data transmissions should ensure that the necessary safeguards are in place in order to not limit the empowerment of the data subject through the DLT chosen model.“ [4]
The report concludes, that data within the wallet application is considered personal data and therefor is subject to the data protection regulation.
While there is a general assumption that e.g. Hyperledger Indy implementations are GDPR compliant [8], ultimately courts have to decide if that claim holds up based on a case by case evaluation on the particular implementation. Nevertheless, avoiding the exposure of PII on the verifiable data registry, by I) not allowing natural persons to write public DIDs and II) not storing PII in hashed form on the verifiable data registry facilitate the GDPR compliance obligations.
eIDAS:
The eIDAS regulation [3] is concerned with two distinct topics. One part is concerned with trust services for private businesses such as electronic signatures, seal, time stamps etc. The other part is regulating the mutual recognition among member states of national implementations of electronic identification (eID) for the public sector. Is a technology neutral approach, which has a strong influence on the international regulatory space. The main goal of mutual recognition of eID is to enable EU citizens access to cross-border public services with their own national eID means. The implementation of eID schemes vary from member state to member state and not all member states have notified an eID scheme as illustrated by the overview of pre-notified and notified eID schemes [9] under eIDAS.
There are three levels of assurance specified for eIDs under eIDAS referring to the degree of confidence in the claimed identity of a person, which include detailed criteria allowing member states to map their eID means against a benchmark (low, substantial and high). Current SSI implementations have the objective to be recognized with a level of assurance specified as substantial.
It’s currently possible to be eIDAS compliant with SSI by leveraging one out of five scenarios described in the SSI eIDAS legal report by Dr. Ignacio Alamillo Domingo [10]. Especially interesting is the SSI eIDAS bridge, which adds legal value to verified credentials with the use of electronic certificates and electronic seals. However, it’s also possible to derive national eIDs notified in eIDAS, which are eIDAS linked by deriving a national eID by issuing a verifiable credential with a qualified certificate according to the technical specification.[12]
Nevertheless, there are also hindrances in the process of creating a qualified certificate with the derived national identity, because of the way the regulation is defining a qualified signature. Another issue is that national eID schemes require the keys to be in a secure element. However, current SSI wallets only offer software keys and do not leverage the security benefits of a hardware element. Furthermore, the eIDAS regulation doesn’t regulate the case of a private entity issuing an eID attribute to a natural person for the usage of it in other private interactions.
Furthermore, the authentication process to achieve the recognition of notified eIDAS schemes by other member states requires a national node, which provides the authentication service. While aimed to be technology neutral, the obligation to provide this authentication service as delegated authentication component has several drawbacks and also hinders the potential adoption of SSI. The EU has already identified the need to re-evaluate the policies set by eIDAS.
“Fundamental changes in the overall societal context suggest a revision of the eIDAS Regulation. These include a dramatic increase in the use of novel technologies, such as distributed-ledger based solutions, the Internet of Thing, Artificial Intelligence and biometrics, changes in the market structure where few players with significant market power increasingly act as digital identity ‘gatekeepers’, changes in user behavior with increasing demand for instant, convenient and secure identification and the evolution of EU Data Protection legislation” [2]
The consultation continues with its target:
“The objective of this initiative is, first of all, to provide a future proof regulatory framework to support an EU-wide, simple, trusted and secure system to manage identities in the digital space, covering identification, authentication and the provision of attributes, credentials and attestations. Secondly, the initiative aims at creating a universal pan-European single digital ID. These objectives could be achieved through an overhaul of the eIDAS system, an extension of eIDAS to the private sector, the introduction of a European Digital Identity (EUid) building on the eIDAS system or combination of both.” [2]
In an private interview for an academic study Dr. Ignacio Alamillo Domingo suggested embodying new technologies such as SSI into the revised regulation e.g. by not mandating the provision of an authentication facility and creating new trust services such as electronic identification. In another private interview Luca Boldrin suggested keeping national identity systems as they are but use a derivation of national identity for cross-border context for public and private businesses in parallel to current node implementation to enable a European identity.
Dr. Ignacio Alamillo Domingo argues that having derived national eIDs and eID trust services has the benefit of increased privacy by using a peer to peer authentication instead of a delegated authentication model (the national eIDAS node). This also leads to less liability issues by shifting the authentication part to private providers as well as less costs associated with running authentication infrastructure for governments, because these are provided by Distributed Public Key Infrastructure (DPKI) instead of national eIDAS nodes. These DPKI systems also have the benefits of being more resilient to attacks compared to a single node, which represents a single point of failure. However, regulating eID as trust service also means opening up identification for the private market, which might not be in the interest of national governments.
Disclaimer: This article does not represent the official view of any entity, which is mentioned in this article or which is affiliated with the author. It solely represents the opinion of the author.
SSI Ambassador
Adrian Doerk
Own your keys
Sources:
[1] PSP PCTF Working Group. ‘Pan Canadian Trust Framework (PCTF) V1.1’. GitHub, 2. June 2020. Accessed 22. June 2020. https://github.com/canada-ca/PCTF- CCP/blob/master/Version1_1/PSP-PCTF-V1.1-Consultation-Draft.pdf
[2] European Commission, ‘EU Digital ID Scheme for Online Transactions across Europe, Public Consultation, Inception Impact Assessment — Ares(2020)3899583’ Accessed 23. August 2020
[3] European parliament and the council of the European union. REGULATION (EU) No 910/2014 on electronic identification and trust services for electronic transactions in the internal market and repealing Directive 1999/93/EC (2014). Accessed 20. September 2020. https://ec.europa.eu/futurium/en/system/files/ged/eidas_regulation.pdf
[4] CEF Digital, University of Amsterdam. ‘EBSI GDPR Assessment, Report on Data Protection within the EBSI Version 1.0 Infrastructure.’ CEF Digital, April 2020. Accessed 18. August 2020. https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITALEBSI/Legal+Assessment+Reports
[5] ‘REGULATION (EU) 2016/679 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL (GDPR)’, 2016. Accessed 5. September 2020. https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32016R0679
[6] Working Party up under Article 29 of Directive 95/46/EC. ‘Article 29 Data Protection Working Party, “Opinion 1/2010 on the Concepts of ‘Controller’ and ‘Processor’” (2010)’, 16 February 2010. Accessed 5. September 2020. https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2010/wp169_en.pdf
[7] World Wide Web Consortium (W3C), ‘Decentralized Identifiers (DIDs) v1.0’. Accessed 18. August 2020. https://www.w3.org/TR/did-core/
[8] Sovrin Foundation. ‘GDPR Position Paper: Innovation Meets Compliance’, January 2020. Accessed 5. September 2020. https://sovrin.org/wp-content/uploads/GDPR-Paper_V1.pdf
[9] CEF Digital ‘Overview of Pre-Notified and Notified EID Schemes under EIDAS’, 2. January 2019. Accessed 6. September 2020. https://ec.europa.eu/cefdigital/wiki/display/EIDCOMMUNITY/Overview+of+pre- notified+and+notified+eID+schemes+under+eIDAS
[10] Dr. Ignacio Alamillo Domingo. ‘SSI EIDAS Legal Report’, April 2020, 150. Accessed 14. September 2020. https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITALEBSI/Legal+Assessment+Reports
[11] EBSI, ESSIF. ‘Technical Specification (15) — EIDAS Bridge for VC-ESealing’. CEF Digital, n.d. Accessed 2. September 2020. https://ec.europa.eu/cefdigital/wiki/cefdigital/wiki/display/CEFDIGITALEBSI/Technical+Specification+%2815%29+-+eIDAS+bridge+for+VC-eSealing
