If a web application wants to use the E-ID (according to the law), it has to overcome some challenges. This compilation is intended to help clarify the conditions or raise questions about how such a connection could be made in the future This document does not claim to be complete, as some implementation details are still unclear and based on assumptions. The aim is simply to show how a state identity can be integrated into an existing ecosystem. The ordinance on the Federal Law on Electronic Identification Services (BGEID)[1] is expected to be published at the end of March 2021. This ordinance will hopefully provide more clarity on what conditions are attached to an identity provider (IdP) and an identity consumer (online service provider). The explanations to the law (which are not expected until the end of 2021) should narrow down the provisions even more concretely. This article examines the following questions:

• What identity data can a company or authority obtain from the E-ID?
• For which lines of business is it worth using the E-ID?
• What does an online service provider have to consider if he wants to use the E-ID?

This document is not intended to make any judgement regarding responsibilities (private or state). Moreover, it does not consider the relationship between the state and a state-recognised IdP, but only between such an IdP and an operator of an e-ID-using service (BvD).

What identity data can a company or authority obtain from the E-ID?

As the publication of the Federal Office of Justice^[2] a rough distinction can be made between two types of e-ID-using services. Those that obtain the E-ID registration number (E-ID-RN)^[3] from the state-recognised identity services (IdP) and those which are not allowed to do so. These include all other online service providers who are to receive a customer number (K-NR) instead of the E-ID-RN. This is calculated specifically for an online service provider (or the ecosystem) and does not allow the provider to draw any conclusions about the person or the E-ID-RN. This means that each online service provider receives a different number, which makes it impossible to easily compare the online service providers (unlinkability). As described in Figure 1, the State Identity Service (SID) provides official personal data of a user^[4] of a user. The personal data that can be passed from a state-approved identity service provider (IdP) to a BvD depends on the security level of the identity data (low, substantial, high) and the type of BvD. An IdP can enrich the personal data from the state with further information (attributes) of the user from other sources and thus provide a total package (user information) to the requesting BvD. The user must, of course, first give his consent to a BvD for the release of this data. All these processes generate usage and metadata, which the SID could track when converting the E-ID-RN into an AHVN13.

Figure 1: Data from an E-ID-IdP

For which business sectors is it worth using the E-ID?

In addition to security requirements, which can also be a decision criterion, the main issue here is the circle of users or customers. If the user base of an online service provider coincides with that of the E-ID, it makes perfect sense to leave part of the user management to the state and use the E-ID service. For both user registration and recurrent authentication, an online service provider can use a certified e-ID IDP in this scenario. This does relieve the BvD by not having to offer a secure login process itself, store login data and secure itself against misuse. Since an online service provider can conveniently delegate all this to the EID-IdP. But on the other hand, he loses control over his users to a large extent (see next chapter). The user has the advantage that he can log in to the BvD’s web service with a login used elsewhere. The latter is one of the main arguments for the use of an E-ID. But here, too, caution is called for, because if the login process does not have a certain level of security, misuse can quickly have far-reaching consequences. Such solution variants lend themselves to public authorities or elementary schools, for example. A BvD cannot delegate everything to the E-ID, however, because it must nevertheless maintain a user database – albeit without login data – in order to be able to store business data of its customers or users. As soon as users who do not have an E-ID want to register and log in – for example, in the university environment when foreign persons want to register for a course of study or, for example, for shopping tourists who want to use Swiss public transport – this makes little sense, since the BvD must nevertheless maintain a full user management, including authentication procedures, for these user categories. However, there are also users who want to use services that do not require verification. For this group of users, no E-ID verification is necessary. Nevertheless, the company must provide these users with an account with login data.

What must an online service provider take into account if it wants to use the E-ID?

As already shown in the last chapter, it only makes sense for an online service provider to use the E-ID fully and alone in a few cases. There are also other criteria that call into question the usefulness of the E-ID for companies. Most companies in Switzerland allow access to their content not only via a browser, which displays the content of their website, but also via mobile apps. Apps for common smartphone platforms are common today. With such mobile apps, a good balance between simplicity and reach can be offered. The user logs in once and then stays connected to the company for a longer period of time. For security reasons, a company will only allow this if authentication and access can be controlled from internal instances. The company determines what the user and the app are allowed to do and can, for example, block access immediately in the event of misuse. In principle, it would be possible to build an app in such a way that the user could authenticate directly with another IdP (e.g. with an EID-IdP) and continue to use services of the company. But for security reasons, such an IdP mixup[5] is rather frowned upon and does not seem to be forward-looking.

Conclusion

The above criteria lead to the following recommendation for the use of E-ID from the perspective of a company or an entire ecosystem. In most cases, an online service provider must maintain a fully comprehensive user management and thus maintain an IdP with self-issued identities. This allows the enterprise to better control access to its own resources, especially from mobile apps, and to guarantee security and privacy. If it wants to connect to the E-ID, it also needs a kind of “identity broker” component in its infrastructure.

Figure 2: Registration and login of a user

Accordingly, it seems to make sense to use the E-ID only for the registration (onboarding) of a user and not for recurring logins. The E-ID should only support a BvD in verifying user information. As shown in Figure 2, in this scenario, a mapping of the identity in the BvD IDP and the identities provided by the E-ID (e.g. K-NR) and the person information takes place as part of the ‘onboarding’ process. This ‘onboarding’ process should only be performed once by the BvD. It can be repeated if the user explicitly requests a repetition. This is precisely the biggest advantage for a BvD, as it can receive authenticated information from the online user from the state, which it does not have to verify itself at great expense. However, a BvD still handles the user’s login itself using the latest technologies (e.g. “passwordless login” with FIDO2 tokens). In this way, it can use currently standardised protocols (OIDC/OAuth2) to ensure that an app can still access its resources securely without interaction from the user. Since querying the status of an e-ID account (or updating the e-ID personal data) by a BvD is very cumbersome and time-consuming, a BvD has to rely on a standard protocol^[6]a BvD must be able to rely on the status of the user in its own IdP. The standardisation efforts of OIDC^[7] and OAuth^[8] will show in which direction a future-oriented integration of the E-ID could go.

References

1] https://www.fedlex.admin.ch/eli/fga/2019/2311/de ^[2] https://www.bj.admin.ch/bj/de/home/staat/gesetzgebung/e-id/technische-informationen.html ^[3] These also include actors who are entitled to have the E-ID-RN converted into an insured person number (AHVN13) by the state. ^[4] From the existing state registers of the Confederation [5] See: https://tools.ietf.org/html/draft-ietf-oauth-mix-up-mitigation-01 and the preceding discussion: https://mailarchive.ietf.org/arch/msg/oauth/JIVxFBGsJBVtm7ljwJhPUm3Fr-w ^[6] “Authorisation Code Flow” proposal by fedpol of 14.8.2020 ^[7] https://openid.net ^[8] https://oauth.net and https://tools.ietf.org/html/rfc6749