Buggy Law 8: eIDAS as Software Engineering
Can legislation have bugs? In a series of posts we have examined eIDAS, the EU law that controls online identification and online signatures for the public sector in EU states. If this legislation is viewed as a software development project – how does it measure up against the state of the art in software engineering?
eIDAS is EU-wide legislation, but its subject is computer systems. Online identification and online signatures is delivered by sizable and sophisticated computer software. It is possible to view eIDAS as a software development project. Here are some characteristics of this project.
Waterfall. Development starts from a fixed requirement specification, the eIDAS legislation. The subsequent process is completely top-down. The model is called “waterfall” development and was common in early days of software engineering. In comparison, all modern system development is iterative. The buzz word is “agile”. Is there anything agile about eIDAS?
2.0 Syndrome. The first EU legislation concerning online identification and online signatures was stated on 9 pages in 1999 and was successful. eIDAS is a follow-up to that directive. The “2.0 syndrome” refers to the phenomenon that the second version of a successful product has a tendency to become so bloated with features that development staggers under their weight. eIDAS is codified on 42 pages and contains a number of major new features.
No feedback loop. In order to be iterative a development process has to include a feedback loop. For instance, market acceptance provides important feedback for a product. As an example of managing large-scale systems, significant parts of the world-wide internet are specified in “Requests For Comments” (RFC). eIDAS, on the other hand, actively suppresses comments by its very nature of being law. Its “market” is given a single option: use the product.
Specify How rather than What. The eIDAS legislation may be regarded as a requirement specification for software performing online identification and online signatures. A requirement specification should specify what to achieve, but not how. All the same, eIDAS specifies the “how” of qualified signatures. It really shouldn’t, it goes against basic rules of software engineering. These parts should not be set in stone as law.
Neglect user experience. The term “user experience” or “UX” is the current term for how a system interacts with its users, an important design element. For eIDAS the largest group of users is millions of ordinary citizens. Their experience is completely neglected. In actual products one may even detect a measure of arrogance towards users, somewhat like, “Don’t try to understand this, just click OK.” Citizens are treated like cattle, shoved here and there without explanation. The overbearing attitude of their digital authorities may cause them to deal the ultimate blow: Reverting to paper forms. Lawmakers beware.
In my opinion, eIDAS as a software development project suffers from issues that modern practices have learnt to avoid. Accountability is weak in the public sector. It is often possible to get away with very costly mistakes.
A question arises from the topic of this post: Is eIDAS law or technology? This will be the subjecct of the next (and probably final) post in this series.
Comments are closed due to the spam factor. You may respond by email to
blog AT soderstrom DOT se