Digital Driving Licences – failing the test?

For several countries and jurisdictions, driving licences have become a de-facto identity document used for many more applications than just proving the right to drive a car. While car ownership patterns might change, right now driving licences are a go-to photo identity document. 

For the last few years around the world, jurisdictions have been rolling out digital driving licence solutions as an eventual replacement of their physical licence system.

Often part of an overall “digital strategy”, the design, build and deployment of a digital driving licence is highly visible and impactful to a large proportion of the population and hence presents a significant career opportunity (and risk) for the technologists, civil servants and politicians who work on these projects. Opportunity and risk since these projects don’t always work the way they are intended.

Digital Driving Licence programs can make and break careers – but what do they mean for the people who get to use digital driving licences?

This article considers several of the important decisions that are being made explicitly and implicitly in designing digital driving licences. It also considers a critical aspect of this digitisation: is it good for the user? Here I don’t just mean “more convenient”, but actually good, and preferably, better. If it is better, not only will we be able to do all we can with the old system, but we will have additional capabilities and no additional risks or unintended side-effects.

My observation is that many digital driving licence designs being rolled out right now fail on several of these “good/better” design checks, in fact, when closely examined, most are a step backwards not forwards despite their “look at me” quality for press releases.

A primary concern, and one that hampers providing a detailed review, is that few, if any, digital licence solutions describe “how” they work. There are no publicly available technical architectures, no peer-reviewed studies, no certificates of security, not even any whitepapers that can give confidence in the design. 

In the early days of these projects there will often be some announcements declaring the project and winning contractors, and sometimes these might mention underlying technologies (blockchain anyone?), but from then until the “tada” system launch, there is no release of information. Overall there is a scarcity of actual design documentation. 

As is often said, security by obscurity is no security at all.

This absence of documentation is a critical first weakness. Digital systems are fundamentally different from physical systems. Just because they sometimes mimic the physical look and feel, doesn’t mean that they behave in anything like the same way under the covers. By implementing a digital solution we may be introducing a fundamentally different interaction, security and privacy pattern – one that isn’t obvious from the superficial user experience. In the absence of design documentation and open peer reviews, we are being asked to “trust” a system in the presence of significant unknowns. Why this is considered “OK” is beyond me. Publishing a design does not weaken its security, rather it gives an opportunity for the security to be reviewed, critiqued and improved. If the design integrity relies on it remaining obscure, then it’s not a very good design.

Given the absence of public design documents, these notes are drawn from reverse engineering the designs through observation, from peering at the opaque workings from the outside, from reading online user and business guides, and in some cases from the efforts of those who have managed to reverse engineer the software and decipher the underlying behaviour of the consumer app.

Before we review the digital design, let’s first remind ourselves of what we had with physical licence systems. We’ll do this so that we can understand what we currently have, and how it “works”.

In the old physical world, we go through a number of checks before being issued with a full licence. In Australia these include basic medical requirements, road rules and theory examinations, 120 hours of supervised, logged, driving with ‘Learner’ plates, a hazard perception test, and, finally, a practical driving test. After all this, and assuming we pass, we get to have our photograph taken, a bunch of other data captured/confirmed, and a laminated hard-to-forge plastic card (or equivalent) is issued to us with many of these details visible, including a photo.

Cue young adult celebrations and parental trepidations.

All these steps (except the last one) would be the same for a digital licence of course. The requirements for licence attainment don’t change just because we’ve changed the format that the issued credential takes. In fact, the rigour required to obtain a licence, coupled with the details it contains, are what make it valuable as an identity document.

Now this physical credential can be used to prove many other things besides the right to drive a car. It can function as a photo-id, proof of age, proof of address, and even part of the “Know Your Customer” check for a bank account. How wonderfully useful.

Critically, these uses don’t usually require the receiving party (the one asking for photo id, proof of address, or proof of age) to check with the issuing authority, the driving licence body. The reason that this approach works is that:

There might be some instances where checking the validity of a driving licence as “a licence to drive” will make absolute sense (for example, renting a car), but surprisingly even these seldom result in checking the validity of a physical licence. The reason that rental car companies don’t do this when you rent a car is that knowing how to check all the possible licences in all the world is simply too hard for a rental car company and would take too long to process for a line of impatient people. Stopped by the police while driving? Well then ‘yes’, checking the licence validity makes absolute sense.

OK, so what can go wrong with the digital model, after all almost all our lives are now digital in one way or another, surely we’re getting good at this stuff now? 

Well let’s assume we’re doing one of the most simple use cases – using our licence to prove we’re old enough to buy alcohol in person at a licensed liquor store.

Having chosen our tipple and arriving at the counter, the retailer asks the reasonable question, “do you have any id?” (aka I need to know that you’re old enough to buy alcohol here). So now you go for your phone and “show them” your digital driving licence.

The key words here are “show them”. One of the design principles of many of these digital licence systems is that they replicate, sort-of, the existing physical licence. Cute, but a bit useless. Presenting a digital artefact visually is fraught because it is trivially simple to mock up an image that copies an existing licence, and replaces the photo with another face, or the data with other data. There are probably even apps for that… 

Sooo, designers rightly realise that they would need to secure the licence presentation. 

And that’s where some of the design challenges, mitigations, and problems start.

Firstly there is some trivial risk reduction stuff: most (all in all likelihood) will disable screen capture by the phone of the image presented when the licence is displayed. Pretty easy to circumvent, but it’s a start.

Secondly, some smart graphics capabilities might be included that are hard to replicate (hard, but when even deep fake technology has been put in the reach of the curious and mischievous, hardly impossible).

Thirdly, the retailer might ask to see you open the app – that might be intrusive, and I suspect a few people would feel uncomfortable showing an unknown retailer their phone as they open an app – but it would allow the retailer to see that an App that looks like the right app is opened in what looks like the right way.

Fourthly, they might ask you to refresh the screen display by triggering the app to update the presentation and the last update timestamp displayed (one of the proposed checks when visually verifying the NSW Digital Driving Licence).

You should ask yourself at this point, what happens when I do things like refresh the display? Is it all local, or does that send a message back to the central system? Is there some sort of log generated that can be used later (with or without my knowledge)? Let’s assume that the behaviour of the driving licence app aligns with a privacy best practice model and that informed consent was built into the design. One aspect of this might be that when you manually refresh the display, the app asks you if it is OK to contact the central system. It would do this to inform you that your action would trigger this response, and to let you decide if that was OK. Ideally the app would tell you how it will behave, how and when it will capture data and who it will share it with when you install it and before you activate it.

Then there are further digital defences. Sometimes there is a QR code displayed that gets updated every few seconds. This allows the verifying party (the retailer in our story), to check the licence by scanning the QR code. Typically the QR code contains a deep-link URL that when accessed provides the verifier some confirmation of the information presented on the screen. Perhaps a green tick or a red cross depending on whether the URL pointed to a valid driving licence and the date/time stamp was within the window. Or perhaps the name of the licence holder for that URL.

The “verification” processes may not explicitly link all the content displayed visually to the QR code. For example, a hacked presentation of a digital driving licence might display the image of “Alice” (the person holding the phone), display the name of “Beverly”, and have a QR code with a link to the valid driving licence of Beverly.

Checking the QR code based URL does more than just trigger a send of verification data to the verifier. It also provides the issuer with the knowledge that a specific licence has been checked at a specific time [from a verifier with a specific IP address]. The issuer has been notified that you’re using that licence. 

Again – the app should inform you that when your QR code is scanned, data is retrieved and captured centrally that includes (at least) that your licence was scanned at a specific date/time and data sent to a specific IP address.

Now the issuer might try to be a good privacy observing issuer, and they might try and “forget” that they learnt this. Or they might not. There might be a third party that demands that they keep records and make them accessible to them. Either way, the app should inform you about these practices and any legal requirements about data capture and sharing.

Now let’s consider the retailer’s systems (the one that did the scanning). Will the retailer’s system(s) discard the information returned by the scanning process, or not? How would the licence holder know if/how their data is going to be used and retained by the retailer?

[Note that this problem also exists in the physical world where too many establishments scan the physical licence (read the magnetic strip, use NFC if supported, or just copy the credential) when presented, with no consent requested and no policy shared about why they need to do so, and what they will do with the information. This issue recently came to light in one state of Australia when a data breach was found of 54,000 scanned driving licences]

Remember that driving licences, and hence their data, are considered the richest source of data for identity theft, the gold-standard if you will. Encouraging establishments to capture this data for no substantive reason introduces a personal and systemic risk.

Basically information about you is being captured and shared in additional ways that weren’t happening when you used a physical credential. And to make it worse, these additional ways are not immediately evident.

Not good. And it gets worse.

Let’s add in the unexpected inconvenience factor. Digital is easier, right? Well no, not always, in fact too often it’s not easier at all.

Because the digital designs have followed “some of” the existing user experience paradigm, “I know I’m showing my licence when I’m showing my licence”, we have some unintended side-effect stuff to deal with. 

[I like the conscious step of knowing when you’re showing or using your driving licence – I see it as an example of “good friction”, and an opportunity to ensure consent.]

Many Australian states make it illegal to touch your phone when in charge of your vehicle, even if you’re stopped. In fact even if you’ve been stopped by the police, you’re not allowed to touch your phone until your vehicle is parked, engine off, and you have been asked to access your phone. Now I understand why we’re not being encouraged not to use our phones when in control of a vehicle, at least not by touch, and I support that. But where is the convenience in the user experience when we have stopped, parked and have to show our digital licence? It would be easier to show the plastic card than the phone.

Then there’s the solution designer hubris – the desire to use the latest news and CV worthy technology. In many instances for the last few years, as soon as you start to talk about trustworthy, reliable, digital artefacts, people think “blockchain”, and in many instances this can be the right decision. Blockchain technology can offer some truly disruptive capabilities that can benefit all participants. My argument is that writing sensitive personal identifiable information to a public permanent ledger isn’t one of them. If your driving licence makes claims that it’s powered by blockchain technology, ask yourself what data is written with indelible ink to what chain, and how is it protected?

Let’s boil this down to a set of simple design principles that we can check or score a new digital driving licence solution against.

Answering only yes or no, consider the following questions on this list…

All ‘yes’? Brilliant. Remarkable. I congratulate you on building arguably the worlds best digital driving licence system.

Some ‘no’ answers? That’s pretty much where all current implementations fall. Could be kinda OK, maybe. Depends on what the no’s are…

Remember: just because it’s digital doesn’t mean it’s better.