The Federal Department of Justice and Police (FDJP) presents three different technical scenarios in its “E-ID target picture” . One of them is an “E-ID solution by means of a central state identity provider”. We show from a technical point of view why a central “E-ID” login cannot advance digitisation in Switzerland.

The survey of the working group “Identity Management and E-ID” of the Swiss Informatics Conference SIK on the “Requirements for E-ID” has shown that many responsible persons from the official environment who potentially use E-ID services prefer a central identity provider (IdP). But does this solve the problem of digitalisation in e-government?

User group

A central identity provider would only make sense if the user group of the trusting services were congruent with that of the central identity provider. Every user who wants to log in to a trusted service and use its functionality can thus be authenticated by a central identity provider. But this is rarely the case. The following exceptions are worth mentioning:

• The E-ID is voluntary. Consequently, there will always be a number of citizens who do not have an E-ID. However, a trustworthy party must still be able to serve these citizens digitally. The exclusive use of such a central service would be tantamount to E-ID coercion.
• Ecosystems such as transport, higher education or the financial world do not only have customers from Switzerland. The Swiss E-ID is reserved exclusively for Swiss citizens and foreigners with a foreigner’s identity card.

If the user group is not congruent, there must be a second IdP for all users who do not have or do not want to use an E-ID. For both the service and the users, the existence of two different IdPs is intransparent and time-consuming. The user must remember which IdP he has used for which service. The service, on the other hand, must avoid users being able to log in with different identities and, if necessary, link identities. Often, in addition to attributes that are confirmed by the E-ID (basic identity), further functional attributes are needed to be able to control the access of users to a certain resource. These are so specific that they are usually stored in an identity management system (user administration) of the trusting service. This means that the service must maintain a corresponding service anyway.

Trust

Both the user and the service provider (trusting party) must fully trust the central identity provider. From the perspective of these two actors, this identity provider is a “trusted third party”. Such trusted third party systems are only suitable where privacy is not so important or where there is a basic trust, e.g. in an intranet.

Protection of privacy

A central identity provider is involved every time a user accesses an application. A solution with a central state identity provider is therefore not up-to-date and not privacy-compliant.

Figure 1: Central identity service

The vote on the e-ID law on 7 March 2021 also showed that citizens want a solution where no one can trace when they used which service.

Security

A central identity provider with identity data of Swiss citizens and foreigners living in Switzerland is also a sought-after target of attack and requires an ever-increasing effort to protect. As some examples in the past have shown, this leads to major data protection breaches if such attacks are successful, because even large identity services can fall victim to cybercrime.

Dependency

Even in a well-secured and strongly developed identity system, unplanned outages can occur, as the total failure of Facebook on 6 October 2021 showed. In the event of a failure of an identity infrastructure, such as Facebook, it is no longer possible for users to access the connected services, even if they were still available.

Compatibility with EUid

On 3 June 2021, the EU Commission published a draft for the further development of the eIDAS Regulation and the establishment of secure digital identities for EU citizens. The EU wants to leave the phase with central state identity providers behind and is now starting to develop the EUid, a digital identity for EU citizens that is not based on a central infrastructure but on decentralised, self-controlled identities. These will be stored in an EUid wallet and can be presented online or in the real world when needed.

Conclusion

A central state identity provider neither fulfils the expectations of the authorities to advance digitalisation in e-government, nor is it compatible with the latest developments in other European countries. A decentralised solution, e.g. by means of self-sovereign identities, as proposed in the “E-ID target image”, is therefore clearly to be preferred.