eID: A suggestion for improvement

For years, the identity card in Germany has offered the possibility to identify and authenticate oneself digitally (see Federal Ministry of the Interior, 2021). Unfortunately, the procedure is rarely used and is hardly known among the population. Therefore, in this blog post, I would like to illustrate how electronic authentication with the identity card could be made user-friendly.

How does the electronic identity work?

The electronic identity card (eID) is, from a technical perspective, a Near Field Communication (NFC) chip that is embedded in the identity card. This NFC chip stores the data that is also present on the identity card. Through certain authentication procedures, this data can be read and transmitted to an authority or another service.

Necessary for use are, on one hand, of course, a current identity card, an application on the desktop PC or laptop, and either the AusweisApp2 on the smartphone or tablet or a card reader. If a service now requests authentication, as may be necessary for online applications, the identity card must be held to the card reader or smartphone. This allows the data from the identity card to be read. With a self-chosen PIN, the user then releases this data for use by the application. This process is illustrated in Figure 2.1.

Since all communication is encrypted end-to-end, the data cannot be intercepted. Additionally, the user can choose which data to share with which service. Thus, it is theoretically possible to sign documents according to the requirements of a qualified electronic signature.

What are the problems with the current procedure?

It is noticeable that authentication with the eID differs significantly from the usual methods, such as logging in to well-known online services. Primarily, the concept is focused on data security to ensure that the owner of the identity card is the one performing the authentication. The problem that arises from this is that the concept is no longer user-friendly.

The biggest obstacle to this procedure is the high access restrictions. The application that actually transmits the data must be installed on a computer running Microsoft Windows or MacOS. This excludes individuals who do not wish to or cannot use these systems. Even more serious, however, is the requirement for a card reader or the need to pair one's smartphone with the computer.

For this purpose, very few people are likely to purchase a card reader, as it not only costs money but also takes time to order and set up. Pairing the smartphone with the PC presents a significant technical hurdle for many people. It can also be assumed that most individuals do not want to take the time to set up the software accordingly.

How could these hurdles be overcome?

To make the procedure more user-friendly, one can utilize methods that are already widely used in other web applications. Most major services that offer a so-called Single Sign-On (SSO) rely on Open Authorization 2.0 (OAuth 2.0) (see Siriwardena, 2020, p. 81). OAuth 2.0 thus serves as a de facto standard for the authentication and authorization of individuals.

In short, the method works as follows: The user wants to authenticate and log into an application. For the login, they are redirected to the authentication server, so the client cannot read the login credentials. Once the authorization server has validated the login, the client receives an authorization code, which can then be used to obtain the token. With the token, the client can access the resource from the resource server, which validates the token using the authorization server (see Boyd, 2012, p. 14). This is how logins with Google or Facebook work with third-party providers, for example.

This approach can be adapted: If the AusweisApp2 is used, the authentication server could provide a QR code that represents the authentication process. With the AusweisApp2, the user scans this QR code and then has the option to scan their identity card and enter the PIN. This data is transmitted to the authentication server, which then issues the authorization code. Alternatively, the process can also be completed with the PC application and a card reader. The communication between the authorization server and the app or card reader remains end-to-end encrypted, of course.

This means that the user only needs either the AusweisApp2 or a card reader on the PC, no longer both. This eliminates the cumbersome setups, such as pairing the smartphone with the PC. Furthermore, it allows the user to authenticate with the identity card on mobile devices and gives individuals who do not use Windows or MacOS the opportunity to participate in the procedure. It should be noted that Android is open source, and therefore this app is not tied to Google's version of the operating system. The process is illustrated in Figure 4.2.

The process would therefore be as follows:

1. The user opens the online application.
2. The user wants to sign electronically.
3. The online application redirects the user to the authorization server.
4. The authorization server establishes an encrypted connection to the AusweisApp2 or the card reader.
5. The user scans his ID.
6. The user enters his PIN.
7. The authorization server issues the authorization code.
8. The online application uses this authorization code to retrieve the token from the authorization server.
9. The online application uses the token to access the resource server, in this case the singing key service.
10. The online application signs using the keys.

Whether the online application is allowed to retrieve signature keys is regulated by the client scopes. This means that in OAuth 2.0, it is predetermined which data a client is theoretically allowed to request. Technically, it is also possible to define these scopes for each request, allowing the user to choose which accesses the client should receive for each operation. However, it should be noted again that the user wants simplicity and is likely to release more data because making a selection takes time.

Conclusion

The current procedure surrounding the eID is too cumbersome to enjoy a broad user base. However, it is relatively easy to switch to a secure method like OAuth 2.0. Technically, not much would need to be changed, as the communication between the card reader or smartphone and the authorization server would still occur directly. However, various technical hurdles would be eliminated, which currently certainly reduce acceptance.

Unfortunately, it is currently unclear whether anything will change in this area in the near future. We can only hope that the Federal Ministry of the Interior will make adjustments, as electronic identity verification has a lot of potential that is currently being wasted.

Literature

[Boyd 2012]
Boyd, Ryan: Getting Started with OAuth 2.0. O’Reilly, 2012

[Bundesinnenministerium 2021]
Bundesinnenministerium: Der Online-Ausweis.
Website. 2021. – URL https://www.personalausweisportal.de/Webs/PA/DE/
buergerinnen-und-buerger/online-ausweisen/online-ausweisen-node.html

[Siriwardena 2020] Siriwardena, Prabath: Advanced API Security: OAuth 2.0 and
Beyond. 2. Apress, 2020

Abbreviations

eID Electronic ID
NFC Near Field Communication
OAuth 2.0 Open Authorization 2.0
SSO Single-Sign-On