On 7 March 2021, the BGEID, i.e. the Federal Act on Electronic Identification Services, will be voted on. In this two-part article, an overview of the handling of personal data in the E-ID ecosystem is given. Part 1 shows what data is held where and what it is used for.

Data in the FedPol information system

The trust anchor of the E-ID is the database with personal data at the Federal Office of Police (FedPol). This is fed with information from five existing federal registers (Art. 24 para. 3 BGEID). These five registers are

• the already existing identity card register of the FedPol,
• the civil status register
• the register for Swiss citizens abroad (Ordipro)
• the Register for Foreigners in Switzerland (ZEMIS)
• the central register of insured persons of the Central Compensation Office for the AHV.

Data verification procedures when applying for an E-ID

Anyone who wants an E-ID applies to an identity provider (IdP). The IdP forwards the request to the Federal Office of Police (FedPol). There, plausibility checks are carried out to determine whether the request matches the data in the FedPol database. The data submitted for plausibility checking are e.g. place of birth, mother’s maiden name, date of marriage, etc. The IdP is not involved in this process. The IdP is not involved in this process and does not receive the answers given by the user during the plausibility check. If the plausibility check is successful, an E-ID number is generated. The E-ID is thus created.

Data check processes during verification

The next step is to make the E-ID usable as a login in everyday life. The use of the E-ID in everyday life requires two things. On the one hand, the user must be provided with means of identification so that she can successfully complete the login process with the help of the IDP in the future. On the other hand, the E-ID must be linked to the user. To put it simply: the user must “show herself” once to the IdP so that in future she will no longer have to show herself to the offices or online services that rely on the E-ID (so-called Relying Parties). The verification is carried out by the IdP. This is where the three levels associated with the E-ID come into play for the first time: low, substantial and high. Depending on how much trust is conveyed, the verification process will be more elaborate or less elaborate:

• For the security level low, the IdP checks at least official documents (the NZZ cited the mobile phone bill or the tax bill as examples in its issue of 13.02.2021).
• For the security level substantial and high, the facial image can additionally be checked for verification.

It can be assumed that the ordinance will make further specifications on the verification steps. Ultimately, it is a matter of ensuring that the test steps are sufficiently robust to give the e-ID the trust that relying parties need.

Data handling at the IDP

The IdP receives a predetermined amount of personal data from the FedPol, precisely defined in the BGEID, and depending on the security level to which the user wants to use her E-ID, it is a matter of the following:

• Security level low: official name with first name(s) and date of birth
• Security level substantial: additionally gender, place of birth and nationality
• Security level high: additionally the facial image as stored in the FedPol database

In addition, the IdP receives the E-ID registration number, which he uses to organise his databases in a way that is resilient and traceable for possible checks. The IdP also receives the facial image for verification of the EID with a substantial level of security, but may not store it if the user does not also want to use the EID for the “high” purpose. The data mentioned in this section is called personal identification data (Art. 5 BGEID).

Processes involved in the use of the E-ID

If the user wants to log in to an office or an online service (Relying Party, referred to as “RP” in the following table) with the E-ID, the following happens: This procedure works as long as the IdP of the RP and the user are the same. If the IdPs do not match, further steps are required between the IdPs involved. How interoperability will effectively look depends on the implementation of the regulation and cannot yet be mapped definitively. *Note on step 7: The request must not go further than permitted. What is permissible is determined by the Data Protection Act, the BGEID regulation (which is currently still being drafted) and the affiliation agreement between IdP and Relying Party.

Machine view of data storage

Within the framework of the processes described above, further data is created in addition to the personal identification data already described. When describing the data situation, it is obvious to differentiate between the Relying Party (in the example: a commercial registry office) and the IdP. First, we describe the level of data storage, i.e. the mere machine view. Whether there are also persons who receive further information in addition to the machine view (data level) (plain text view or person view) will be dealt with later.

Data storage at the Relying Party

• Usage data: On the systems of the Relying Party (the Commercial Registry Office), data is generated on who (the user) interacts when and with whom (with the Commercial Registry Office itself).
• Content data: We refer to content data as the information that describes what the user communicates to the commercial registry office. The commercial registry office naturally has its own data (machine view) about why the user has interacted with it (e.g. formation of a limited liability company).
• Usage profile: If the user reports to the commercial registry office more than once in a recognisable way, the commercial registry office naturally receives something like a cross-sectional view of the user’s activities. For example, the fact that she is not only a shareholder in the limited company, but apparently also a member of the board of directors of X. AG, etc. One can call this overall or cross-sectional view a user profile. The commercial register has a machine view for this.

Data storage at the IdP

• Usage data: The IdP also has its own data on its systems that describe that the user interacted with the trade registry at a certain point in time.
• Content data: Unlike the Trade Registry, the IdP does not have its own data on its systems about what the user is interacting with the Trade Registry about.
• Usage profile: If the user uses the E-ID several times, the IdP also receives a data series that can be described as a usage profile. However, individual data points are only stored for a maximum of 6 months (depending on the use case, for a shorter period). Those who use the E-ID less often than once every six months can therefore prevent the creation of usage profiles at the IdP. The data points accruing at the IdP are narrower in content than those at the Relying Party. The IdP only receives data on who (the user) interacted with whom (the trade registry office) and when. As mentioned, the IdP does not receive content data and therefore cannot store such information in the usage profile.

Person’s view of data storage

Whether, beyond the machine view (data level), there is also a plain-text view of those persons who manage the IT systems concerned (i.e. staff of the Commercial Registry Office for its systems, on the one hand, and staff of the IdP, on the other hand, for its systems), is to be described below, again separately for the Relying Party and the IdP:

Plain Text View:

• At the Relying Party: Such plain text view only occurs if the Relying Party has no processes in place to prevent individuals from viewing the data. According to the revDSG, which will become relevant for the e-ID, the Relying Party must comply with requirements of Privacy by Design etc. and only allow plain text views to those who need them to perform their work (need-to-know principle). If the Relying Party is an official body, it usually needs a legal basis.
• For the IdP: The IdP is also subject to the revDSG. The IdP must therefore also comply with the principles of privacy by design (Art. 7 para. 1 revDSG). What is special is that the IdP may not make any assumptions about the user’s interactions with the Relying Party. That would be processing personal identification data. Such observations or assumptions are prohibited (Art. 9 para. 1 BGEID). An IdP who would make such observations would lose his licence.

Part 2 specifically addresses how personal data is protected EID ecosystem.