
With the reform (i.e. the new version) of the Online Access Act (OZG), bund.id is being introduced as the mandatory online access account, including a mailbox function. That’s how it’s put in the German Federal Ministry of the Interior’s “Eckpunkte fΓΌr eine moderne und zukunftsgerichtete Verwaltung” (“Key Points for a Modern and Future-Oriented Administration”) (eckpunkte-ozg.pdf):
The digital proof of identity (electronic ID card) is the key to government (but also private-sector) services, and is being established user-friendly through concrete use cases.
What’s new in the OZG is that, instead of various state-specific service accounts, bund.id is now meant to become mandatory for all procedures β whether federal, state, or municipal. bund.id has several trust levels, including a so-called high trust level that allows for legally binding identity verification. For this, either an ID document with an eID function (the “online ID card”) is currently used, or an Elster certificate originating from the tax domain.
Handling it is still demanding. It’s true that you no longer need a separate card reader to read the data from your “online ID card” β a current smartphone with NFC reading capability is enough. Even so, the process is still hard to follow, not least perhaps because it simply hasn’t been learned yet. Among other things, you have to install an extra app (see, for example, Filing a claim - instructions (einmalzahlung200.de)). If you use a laptop and a smartphone in parallel, it gets even more complicated.
For the β¬200 one-off payment for students, bund.id was used as the login account, and often also as a second factor for identity verification (disclaimer: I worked on this project for the BMBF as an internally consulting architect).
A quick recap on the one-off payment: the challenge for the einmalzahlung200.de project was that neither the personal data nor the bank account data of those entitled to the payment was available. Since waiting 18 months was not an option (calculations on merging tax ID and IBAN - FragDenStaat), a multi-stage procedure was developed together with the lead state and the service provider:
- Educational institutions upload encrypted lists of the people at their institution who are entitled to apply into an online system.
- They send each entitled applicant a locally generated access token. This token temporarily allows the online procedure to access the encrypted data.
- The applicant submits an online application. In doing so, they provide the account number (IBAN) to which the amount should be transferred. This is automatically checked and, in the normal case, automatically scheduled for payout.
- To secure the procedure, identity has to be established in addition to the access token. This happens via the information linked through bund.id, from either the online ID card or the Elster certificate. Alternatively, a second PIN could be used for this, generated by the educational institution β which had to ensure that access was only given to the entitled person. This could happen, for instance, by handing it out in person at the school office (against presentation of an ID) or by using locally available secure systems.
As far as I know, this procedure was the first OZG procedure to fully implement the EfA (“Einer fΓΌr Alle” / “One for All”) principle, since not only the application procedure but also the processing of applications (the so-called specialist procedure) was provided by the lead state and used by all federal states.
At least the revised bund.id user interface was published just in time, so visually you were pulled out of the 90s and into the present.
One should, incidentally, take a critical look at the practice β creeping in here β of working with separate top-level domains. While the BSI recommends at the working level always using trustworthy top-level domains such as bund.de (i.e., something like antraege.bildung.bund.de), that failed here because there is no such domain that includes both the federal government and the states.
As of the end of May 2023, more than 2,500,000 applications had been successfully paid out through this procedure (source: einmalzahlung.de). At the same time, this was a booster for the adoption of bund.id. Even though the bund.id servers briefly buckled at the start of the procedure (even though such infrastructure really should be designed for scalability at its core), the use of bund.id drove the number of users past a critical mass β before that it had still been languishing at around 100,000 (source: Personalausweisportal - homepage - 100,000 accounts in the federal user account). (Disclaimer: the application procedure’s infrastructure was also not particularly scalable, since the software solution used in the background had licensing limitations, and the procedure also ran in a data center operated by the service provider rather than in a β not yet existing β highly scalable administrative cloud (Deutsche Verwaltungscloud (dataport.de)).
But let’s now look ahead and see what demands (not exhaustively) the education sector should place on bund.id:
Usability: bund.id should be developed continuously and with users at the center. This can happen, for example, in the existing digital-identity projects at GovLab (GovLabDE | Collaboration Platform of the Federal Government), but what matters here, in my view, is that two things are understood:
- Digitizing public administration has to be measured against market standards. As long as logging in with bund.id is more complicated than, say, logging in with an Apple ID, this won’t work. It needs to be examined where more pragmatic thinking is possible. Could online identification, for example, also be done (additionally) via existing infrastructures such as banks, where a verified identity already exists? Other countries have done this successfully.
- At the same time, requirements that still stem from an analog administrative mindset need to be phased out. The requirement for written form is one example worth naming here. Digitizing public administration can only succeed with the right framework conditions and a changed mindset within the administration itself. That also applies to how projects are implemented β not law first, then implementation, but cross-functional, interdisciplinary teams and early, collaborative engagement with all stakeholders from the start. That, in turn, requires a massive build-up of digital competence within the individual departments.
Data protection and data sovereignty must be central tasks of further development. Tools such as data protection dashboards, which show who accessed which data and when, need to be understandable for the broad mass of users, too. GDPR functions such as viewing, correcting, and deleting data need to be usable with a low barrier to entry.
At the same time, the various initiatives need to be consistently brought together. This includes, for example, the upcoming EU wallet (European Digital Identity (europa.eu)), which also includes identification functions.
The same applies to projects such as the Digital Education Space / National Education Platform (NBP) (Nationale Bildungsplattform - Produktentwicklung - Digitaler Bildungsraum), which comes with its own proprietary wallet. This is admittedly much more than an ID wallet β it understands itself as the connecting element of a networking infrastructure for education β but that doesn’t contradict a holistic approach. The same goes for the web-based wallet of Europass (Europass and European Digital Credentials for Learning | Europass), where I can store digitally verifiable credentials.
What is missing is an open, societally anchored discourse on the fundamental architectural questions. This applies, for example, to how decentralized (on-device) wallets, web wallets, and registers interact with β or are delineated from β one another. What advantages and risks do decentralized wallets like the NBP’s, for instance, bring?
Right now, the EU broadly seems to be setting the pace (SDG, eIDAS2) β and this happens with intensive participation from the member states, but bringing this together with the numerous national initiatives and showcase projects seems to work more through networking and participation than through corresponding permanent structures. Especially for the education sector, new structures are needed here: from cross-jurisdictional standardization questions, to jointly developed and internationally connectable interoperable IT architectures that capture synergies, all the way to participation structures for projects like the NBP, as called for, for instance, here (Konzeptstudie Werte und Strukturen der Nationalen Bildungsplattform.pdf) (Transparency disclaimer: until recently I was employed at the BMBF as an advisor in the project group responsible for this).
And finally, there should be pragmatic thinking about new use cases. If, for instance, we now have a service account with a mailbox through bund.id, why not extend that with a function that lets, say, educational institutions send certificates into that inbox, defined so that they cannot be altered (immutable) or deleted for a certain period of time? If these are then also made shareable (which is coming anyway with the EU wallet, ideally with data-minimizing verifiable presentations too), you not only get a merge with the wallets, but also save educational institutions the trouble of archiving these documents locally.